Chapter 4: Project Planning -> scope management & integration management Flashcards
Why “planning”?
*Many people have heard the following sayings:
-If you fail to plan you plain to fail
-If you don’t know where you are going any
road will take you there
-What gets measures get’s done
*Succesful project managers know how important it is to develop, refine and follow plans to meet project goals
*People are more likely to perform well if they know what they are supposed to do and when
Planning should guide the execution
*Planning is often the most difficult and unappreciated process in the project management
*Often, people do not want to take the time to plan well, but theory and practice show that good planning is crucial to good execution
*The main purpose of project planning is to guide prodject execution, so project plans must be realistic and useful.
*Often project fails at the end not the beginning
Project Integration Definition
Project Integration Management involves coordinating all project management knowledge areas throughout a project’s life span
Project Management Plan
*The project Management Plan is the document that describes how the project will be executed, monitored, controlled, and closed.
*Typical content of a Project Management Plan
-Introduction/overview of the project
-Project Organization
-Management and technical processes
-Work to be performed
-Schedule Information
-Budget Information
-References to other project planning
documents
*Project management plans should be:
-dynamic
-flexible
-receptive to change in the environment or
project
Scope
Scope refers to all the work involved in creating the products of the project and the processes used to create them
Deliverable Definition
A deliverable is a product produced as a part of a project, such as hardware or software, planning documents, or meeting minutes
Project Scope Management Definition
Project Scope Management includes the processes involved in defining and controlling what is or is not included in a project
Project Scope Management Process
1- Plan Scope Management: determine how the project scope will be defined, validated, and controlled (How are we going to do it?)
2- Collect requirements: defining and documenting the features and functions of the products produced during the project (How are we going to do it? What to we need?)
3- Define Scope: reviewing the project charter, requirements documents, etc. to create a scope starement (Creating an insight of what needs to be done)
4- Create WBS: subdividing the major project deliverables into smaller, more manageable components (Detail an overview of what we are going to work out)
5- Validate scope: formalizing acceptance of the project deliverables (When is it good?)
6- Control scope: controlling changes to project scope throughout the life of the project (Dealing with changes)
Requirement definition
A condition that is necessary to be present in a product, service or result to satisfy a business need.
Methods for collecting requirements
- Methods (7)
-Interviewing
-Focus groups and facilitated workshops
-Using group creativity and decision-making
techniques
-Questionnaire and surveys
-Observation
-Prototyping
-Benchmarking
*Collection of requirements is industry specific
Requirements traceability matrix
*A table that lists requirements, various attributes of each requirement, and the status of the requirements to ensure that all of them are adressed.
Project Scope Statement
- Definition: The description of project scope, major deliverables, assumptions, and constraints
*Content of a project scope
-Objectives
-Scope
-Deliverables
-Constraints
-Risks
-Approval
Work Breakdown Structure
*Work Breakdown Structure (WBS) is a deliverable-oriented grouping of the work involved in a project that defines the total scope of the project
*Foundation document that provides the basis for planning and managing project schedules, costs, resources, and changes
*Work package: task at the lower level of the
WBS
-Work package has one owner
-Work package can be considered by its
owner as a project in itself
*Outputs of creating the WBS are the scope baseline and project document updates
-Scope baseline includes the approved
project scope statement and its
associated WBS and WBS dictionary
Creating a WBS
*Using guidelines: some organizations provide
guidelines for preparing WBS
*Analogy approach: review WBS of similar projects and tailor it to your project
*Top-down approach: start with the largest
item 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 dictionnary
*A WBS dictionary is a document that describes the deliverables on the WBS in more detail
*Format can vary based on project needs
*It may also include who owns the work package, estimated cost & schedule information, contract information if outsourced, specific quality requirements, technical and performance requirements
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.
Themes, Initiatives, Epics, and Story Cards
*Instead of a work breakdown structure, some experts suggest developing a Value Breakdown Structure (VBS). The hierarchy of VBS is made of three items:
-initiative: collections of epics that drive
toward a common goal
-epics: large bodies of work that can be
broken down into a number of smaller tasks
(called stories)
-stories or user stories: short requirements
or requests written from the perspective of
an end user
*MoSCoW prioritization methode
-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 will have
a small impact if not provided
-will not have: items that are not a priority for
this specific time frame
Story Cards
- Story cards 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:
-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’s complete
