Project Planning: A 12 Step Program: 1) Set Goal and Scope

You might also like

Download as pdf or txt
Download as pdf or txt
You are on page 1of 34

Project Planning: A 12 Step Program

1) Set goal and scope 7) Identify tasks


2) Select lifecycle 8) Identify task
3) Set organization/team dependencies
form 9) Estimate size
4) Start team selection 10) Estimate effort
5) Determine risks 11) Assign resources
6) Create WBS 12) Schedule work
Project scope management
Scope Planning
Project Requirements
Define Scope
Creating the Work Breakdown Structure
(WBS)

January 25, 2017 SE 477: Lecture 4 2 of 101


Scope
 Project scope management is one of the most critical
project management knowledge (skill) areas
 Scope defines
 All the work that is required to complete the project
successfully and
 Only the work that is required, no more, no less

 This latter point is critical: project scope management


defines and controls what is and is not part of the project
work
Scope planning
 Scope planning is concerned with choosing the most
appropriate, most effective approach to managing the scope
of the project
 Scope planning defines how to:
 Define the scope
 Develop the detailed project scope statement
 Define and develop the WBS
 Verify project scope
 Control project scope
 Scope planning takes two primary inputs: the project charter
and the preliminary project scope statement
 Scope planning results in a project scope management plan

January 25, 2017 SE 477: Lecture 4 4 of 101


Plan Scope Management: Data Flow Diagram

January 25, 2017 SE 477: Lecture 4 5 of 101


Inputs, tools & techniques, and outputs

January 25, 2017 SE 477: Lecture 4 6 of 101


Overview
 The Define Scope process develops a detailed description
of the project and product
 Implicit (and stated) in the Define Scope process is the
assumption that not all of the requirements collected in the
Collect Requirements process may be included in the
project
 Though compatible with an adaptive/agile methodology, this
assumption represents a less-flexible approach to managing
requirements and scope
 The Project Scope Statement describes the project scope,
major deliverables, assumptions, and constraints

January 25, 2017 SE 477: Lecture 4 7 of 101


Tools and techniques
 Product analysis. Product analysis is the process of
translating high-level product descriptions into tangible
deliverables. Product analysis in IT includes techniques
such as:
 System analysis
 Requirements analysis
 Systems engineering
 Alternatives identification. Attempts to uncover alternative
approaches to executing and performing the project work,
using techniques such as brainstorming and mind mapping
 Alternatives provide contrasting options to the planned approach,
allowing better definition of scope

January 25, 2017 SE 477: Lecture 4 8 of 101


Project scope statement
 The project scope statement documents the entire scope, including
project and product scope
 Project scope encompasses product scope plus the work required to
create the product: any project-related activities, such as
documentation delivery and training
 Product scope encompasses the functional and non-functional
requirements for the final project deliverable
 The project scope statement provides a common understanding of the
project scope among project stakeholders
 The project scope statement may contain explicit scope exclusions that
can help to manage stakeholder expectations
 This can prevent the project from straying from the original vision in
all project methodologies: sequential, iterative/incremental, and
adaptive/agile

January 25, 2017 SE 477: Lecture 4 9 of 101


Project scope statement
 Project scope statement. The project scope statement
contents include:
 Product scope description. Progressively elaborates the
characteristics of the product described in the project charter and
requirements
 Product acceptance criteria. Conditions required for acceptance of
deliverables
 Project deliverables. Deliverables include both product outputs and
project outputs, such as project reports and documentation
 Project exclusions. Identifies what is excluded from project
 Project constraints. Lists and describes anything that limits the
project team's options, such as budget, imposed schedule,
milestones, etc.
 Project assumptions. Lists and describes anything assumed to be
true with respect to the scope and impact if these prove to be false

January 25, 2017 SE 477: Lecture 4 10 of 101


Project document updates
 Results of the Define Scope process may affect other
project documents, including:
 Stakeholder register
 Requirements documentation
 Requirements traceability matrix [not discussed]

January 25, 2017 SE 477: Lecture 4 11 of 101


Work Breakdown Structure (WBS)
 Recall the definition from the PMBOK Guide:
“The WBS is a deliverable-oriented hierarchical

decomposition of the work to be executed by the project
team to accomplish the project objectives and create the
required deliverables.”
 WBS is the primary tool for managing the scope of a project
 Work in the WBS is within scope
 Work not in the WBS is out of scope
 Though relatively simple, considered the single most
important project management tool
 In WBS, levels represent different levels of project
decomposition

January 25, 2017 SE 477: Lecture 4 12 of 101


WBS – Basis of Many Things
 Network scheduling
 Costing GOAL

 Risk analysis
 Organizational structure Activity Activity Activity Level 1
 Control
 Measurement
LEVEL ELEMENT Activity Activity Activity Level 2
DESCRIPTION
1 Project
2 Category
3 Subcategory Activity
Task #1 Task #2 Task #3 Task #4…Task #n
4 Sub-
Subcategory
5 Work Package

January 25, 2017 SE 477: Lecture 4 13 of 101


Process: Create WBS
 WBS – Work Breakdown Structure. Technique for
describing all work in a project.
 PERT – Program Evaluation and Review Technique. A well-
entrenched technique for scheduling.
 CPM – Critical Path Method. Used with PERT to determine
problems in scheduling.
 Gantt Charts – bar chart that graphically displays project
schedule

January 25, 2017 SE 477: Lecture 4 14 of 101


Conventional WBS levels
 Level 1
Note that conventional WBS
Project name decomposition levels are
 Level 2 product-oriented

 Major subsystems of the project


 Level 3
 Components/task activities of subsystems at Level 2
 Level 4
 Subcomponents/subtasks of components/tasks at Level 3
 Level 5
 Work packages for subcomponents/subtasks at Level 4
 Work packages are where the actual work takes place
 Assigned to a person and given a schedule and budget

January 25, 2017 SE 477: Lecture 4 15 of 101


Six Criteria to Test for Completeness in the WBS
 The WBS is developed as part of a Joint Planning session.
But how do you know that you've done this right? Each
activity must possess six characteristics to be considered
complete – that is, completely decomposed. The six
characteristics are
1. Status/completion is measurable
2. Start/end events are clearly defined
3. Activity has a deliverable
4. Time/cost is easily estimated
5. Activity duration is within acceptable limits
6. Work assignments are independent

» Let us review each one in detail …


January 25, 2017 SE 477: Lecture 4 16 of 101
The WBS Should Follow the Work
Package Concept
Example of WBS

holiday

travel
documents booking household

passport tickets choose confirm


resort cat!

insurance
brochures

Chapter 5 Planning 18
Work Breakdown Structure

1. Breaks project into a hierarchy.


2. Creates a clear project structure.
3. Avoids risk of missing project
elements.
4. Enables clarity of high level planning.
E-Comerce Bank Project
Intranet Project

21
22
23
Responsibility Matrix

• Intersection of WBS and organization


structure
• Rows = persons or functional positions
• Columns = work tasks or packages for which
each personnel is responsible
• Useful for monitoring and control
24
25
26
27
Estimation Techniques
- The Project Management Approach

• Guesstimating
• Delphi Technique
• Time Boxing
• Top-Down
• Bottom Up
• Analogous Estimates (Past experiences)
• Parametric Modeling (Statistical)
Project Estimation
• Guesstimating
– Based on feeling and not facts
– Not a good method for estimating but often used by
inexperienced project managers

• Delphi Technique
– Involves multiple, anonymous experts
– Each expert makes an estimate
– Estimates compared
• If close, can be averaged
• Another iteration until consensus is reached
Project Estimation

• Time Boxing
– A “box” of time is allocated for a specific activity,
task, or deliverable
– Can focus a team if used effectively
– Can demoralize a team if used too often or
ineffectively because of the increased stress or
pressure on the project team to get things done
Project Estimation
• Top-Down Estimating
– Top and middle managers determine overall project
schedule and/or cost.
– Lower level managers are expected to breakdown
schedule/budget estimates into specific activities (WBS).
– Often couched in terms of what a project should cost and
how long it should take as decreed by a member of top
management who thinks those parameters are
appropriate.
– May be a response to the business environment.
– May lead to a death march project.
Project Estimation

• Bottom-Up Estimating
– Most common form of project estimation
– Schedules & budgets are constructed from the
WBS
– Starts with people who will be doing the work
– Schedules & budgets are the aggregate of
detailed activities & costs
Project Estimation

• Analogous estimating
– based on similarity between current projects and
others
– Use information from previous, similar projects as
a basis for estimation
Project Estimation

• Parametric Modeling
– Use project characteristics (parameters) in a
mathematical model to estimate

– Example: $50/ LOC based on:


• Programming language
• Level of expertise
• Size & complexity

You might also like