Project Planning: Integration and Scope Management Flashcards
Why planning?
-Planning should guide execution : to guide projet to be successful and realistic
But is often the most difficult and unappreciated process in project management
–> theory and practice show that good planning is crucial to good execution
Project Integration Management
involves coordinating all the project management knowledge areas (“overarching picture”) throughout a project’s life span
–> output is a project management plan
Project management plan (PMP)
The document that describes how the project will be executed, monitored
and controlled, and closed”
Type of content in a PMP
-Introduction/overview of the project
-Project organization
-Management and technical processes (including project lifecycle description and development approach, as applicable)
-Work to be performed (scope)
-Schedule information
-Budget information
-References to other project planning documents
A project management plan should be..
-dynamic
-flexible
-receptive to change
=when the environment or the project change
Why is important to tailor every planning project?
-every project is unique
-fit the need of specific project
Definition scope
refers to all the work involved in creating the products of the project and the processes used to
create them
–> create an insight what need to be done
a deliverable
is a product produced as part of a project, such as hardware or software, planning documents, or meeting minutes
Project scope management
includes the processes involved in defining and controlling what is or is not included in a project
why do we need a project scope management
-is to determine how the project scope will be defined, validated, and controlled
–> how are we going to do it ?
collect requirement
defining and documenting the features and functions of the products produced
during the project
–> a condition or capability that is necessary to be present in a product, service, or result to satisfy a business need
–> How are we going to do it? What do we need ?
Create WBS
subdividing the major project deliverables into smaller, more manageable components
–> Detain an overview of what we are going to work at
Validate scope
formalizing acceptance of the project deliverables
–> When is it good ?
Control scope
controlling changes to project scope throughout the life of the project
–> dealing with the changes
Different steps in project scope management : (6)
-Planning scope management
-Collect requirements:
-Define scope
-Create WBS
-Validate scope
-Control scope
Methods for collecting requirement
-interviewing
-Focus group and facilitated workshops
-Using group creativity and decision-making techniques
-Questionnaires and surveys
-Observation
-Prototyping
-Benchmarking
Project scope statement definition
The description of project scope, major deliverables, assumptions, and
constraints.
Content of a project scope statement
-Objectives: Why do we need the project.
-Scope description: What is within the scope of your project.
-Deliverables: List out the deliverables your team members need to produce in order to meet business objectives.
-Constraints and assumptions: Time, money, risk, customers, legislations, regulations, availability of key stakeholders, etc.
-Risks: Potential risks that can affect your project.
-Approval: Signatures from key stakeholders.
–> supporting document references
WBS definition
is a project management technique that involves breaking down a parent project into child tasks, which in turn are divided into sub-tasks
Creating an WBS
- Using guidelines: Some organizations provide guidelines for preparing WBSs (e.g. defense departments, government
projects, etc.) - Analogy approach: Review WBSs of similar projects and tailor to your project
- Top-down approach: Start with the largest items of the project and break them down
- Bottom-up approach: Start with the specific tasks
- Mind mapping: Uses branches radiating out from a core idea to structure thoughts and ideas
WBS dictionary
is a document that describes the deliverables on the WBS in more detail
–> may also include who owns the work package, estimated cost and schedule information, contract information if outsourced, specific quality requirements, technical and performance requirements, etc.
Advice for creating a WBS and WBS dictionary
-Unit of work should appear at only one place in the WBS
-Work content of a WBS item is the sum of the WBS items below it
-WBS item is the responsibility of only one individual, even though many people may be working on it
-Project team members should be involved in developing the WBS to ensure consistency and buy-in
-Each WBS item must be documented in a WBS dictionary to ensure accurate understanding of the scope of work included and not included
-WBS must be a flexible tool to accommodate inevitable changes while properly maintaining control of the work content in the project according to the scope statement
Integration Planning for an Agile/Hybrid Project
-Only high-level planning in the beginning
-Less documentation (Write down only what is necessary, Have discussions to ensure common understanding)
-More details for the in short-term
-Requirements change after each iteration
Scope planning for an Agile / Hybrid Project
-Scope is not completely known until the end of the project
-Customer / Client can add and remove features at the start of every iteration.
-During backlog refinement teams progressively elaborate and reprioritize the work to determine what can be accomplished during that iteration.
-New features can be added at any time to ensure that projects deliver the most value.
Hierarchy for VBS (Value breakdown Structure
with an initiative at the top (like level 1 in a WBS)then epics (level 2), and then stories (level 3)Value breakdown Structure (VBS)
Epics
are large bodies of work that can be broken down into a number of smaller tasks (called stories)
Stories
‘user stories,’ are short requirements or requests written from the perspective of an end user.
MSCW (Moscow method)
-Must have: Non-negotiable product needs that are mandatory for the team
-Should have: Important items that add significant value
-Could have: Nice to have items that we will have a small impact if not provided
-Will not have: Items that are not a priority for this specific frame
Story card
contain information about user stories written on an index card or typed in software to facilitate planning and discussion.
Stories should use the INVEST rule and be:
-Independent: Can be completed on its own
-Negotiable: One or two sentences long. Details can be worked out through discussion
-Valuable: Provide value to the customer
-Estimable: A good approximation
-Small: Can be completed within one iteration
-Testable: Know when it is complete
agile approach project
planning remains at a high-level for the long-term, but more detailed plans are created for the short-term. Teams refine the product backlog during sprint planning for each iteration and often break epics into user stories. Teams can use story cards to document requirements.
