CMU Talk - PM Paradigm

The Project Management Paradigm
Carnegie Mellon University, Silicon Valley

The term Project Management means many things to many people. For
software development, managing the project means having the
customer agree you are Done in measures meaningful to the customer.

What are the Primary
Measures of Success for a
Project?

Are We Done?
When will we be Done?
What will it cost to be
Done?

 What does Done look like for
the customer?
 How can we recognize Done
when it arrives?
 How can we be sure we can
get to from hereDone?
 What are the impediments to
getting to done?
2/12
Deliverables Based Planning Handbook for A&D, Copyright © 2008, 2009, Lewis & Fowler

What Others Have Seen
The quality of a software system is
governed by the quality of the process used
to develop it.‖
— Watts Humphrey

If you can't describe what you are doing as
a process, you don't know what you're
doing.
— W. Edwards Deming

When you can measure what you are
speaking about, and express it in
numbers, you know something about it; but
when you cannot measure it, when you
cannot express it in numbers, your
knowledge is of a meager and
unsatisfactory kind; it may be the beginning
of knowledge, but you have scarcely in your
thoughts advanced to the stage of science.
— Lord Kelvin

In theory there is no difference between
theory and practice. In practice there is.
— Yogi Berra

Frameworks
for PM
 PMI PMBOK®
– This is not a
method
 CMMI–DEV
– This is not a
method
 Prince2
– This is a
method
• Scrum
– Project
Management
of Software
Development?

Groups Monitoring &
Initiating Planning Executing Close Out
Knowledge Areas  Controlling
PMI’s PMBOK Structure  Monitor and Control
 Project  Close project or
Work
Integration  Charter  Manage Execution
 Integrated Change
Management Plan phase
Control
 Collect
 Verify Scope
Requirements
Scope
 Define Scope  Control Scope
 Create WBS
 Define activities
 Sequence Activities
 Estimate
 Control Schedule
Time
Resources
 Estimate Duration
 Develop Schedule
 Estimate Costs
 Control costs
Cost
 Determine Budget
 Perform Quality  Perform Quality
 Plan Quality
Quality
Assurance Control
 Acquire Team
 Develop HR Plan  Develop Team
Human Resources
 Manage Team
 Identify
Communications
Stakeholders
 Risk Plan
 Identify Risk
 Monitor and Control
 Qualitative Risk
Risk
Risks
 Quantitative Risk
 Risk Responses
 Conduct  Administer  Close
Procurement
 Plan procurement 5
procurement procurement procurements
Copyright © 2008, Lewis & Fowler

The CMMI–DEV Model
Maturity Level Process Areas
5 – Optimizing Organizational Causal Analysis
Innovation & and Resolution
Deployment (CAR)
(OID)
4 – Quantitatively Organizational Quantitative
Managed Process Project
Performance Management
(OPF) (QPM)
3 – Defined Organizational Organizational Organizational Integrated Risk Decision Requirements
Process Focus Process Training Project Management Analysis and Development
Definition Management Resolution
(OPF) (OPD) (OT) (IPM) (RSKM) (DAR) (RD)
Technical Product Verification Validation
Solution Integration

(TS) (PI) (VER) (VAL)
2 – Managed Requirements Project Project Supplier Measurement Process and Configuration
Management Planning Monitoring and Agreement and Analysis Product Quality Management
Control Management Assurance
(RM) (PP) (PMC) (SAM) (MA) (PPQA) (CM)

6

Prince2 Process Model

7

Scrum Software Development Process Model

Roles Key Artifacts Key Meetings Development Process
Product Backlog Sprint Planning Meeting Product Increment
•List of requirements & issues •Hosted by ScrumMaster; ½-1 day Backlog
PO •Owned by Product Owner •In: Product Backlog, existing
•Anybody can add to it pro-duct, business & technology
•Only Product Owner prioritizes conditions
Product Owner:
1. Select highest priority items in
Set priorities Sprint:
Product Backlog; declare Sprint Goal
30 days each
2. Team turns selected items into Sprint Planning Meeting
Sprint Goal
Sprint Backlog
•One-sentence summary
•Out:: Sprint Goal, Sprint Backlog
SM •Declared by Product Owner Sprint
•Accepted by team Goal
Daily Scrum
ScrumMaster: Sprint
•Hosted by ScrumMaster
Backlog
Daily Scrum
Manage process, •Attended by all, but Stakeholders
Sprint Backlog
don’t speak
re--move blocks •List of tasks Blocks
•Same time every day
•Owned by team List
Daily Work
•Answer: 1) What did you do
•Only team modifies it
Product
yesterday? 2) What will you do
today? 3) What’s in your way?
T
•Team updates Sprint Backlog;
Blocks List ScrumMaster updates Blocks List
•List of blocks & unmade Increment’
Team: Develop decisions
product Sprint Review Meeting
•Owned by ScrumMaster
•Hosted by ScrumMaster
•Updated daily Sprint Review Meeting
•Attended by all
•Informal, 4-hour, informational
SH •Team demos Increment
Increment Product
•All discuss
•Version of the product Backlog’
•Hold retrospective
Stakeholders: •Shippable functionality (tested,
•Announce next Sprint Planning
documented, etc.)
observe & advise Meeting

Copyright 2004, William C. Wake, William.Wake@acm.org, www.xp123.com
Free for non-commercial use. 1-25-04

8/12

So What Are Some Common Themes
Between This Approaches?

 Identify the work
 Plan the work
Remember, a

Method and a
Cost the work
Process Model
are not the
 Execute the work
same thing.


CMMI, PMBOK
Measure cost, schedule, and
are process
quality
models.
Scrum and
 Adjust the plan
Prince2 are
methods
 Keep the stakeholders in the loop

A Core Question:
What’s the Difference Between Project
Management and Agile Project Management?

Agile (verb): The ability to rapidly respond to change
Characterized by:
 Quickness, lightness, and ease of movement;
 Nimble;
 Moving quickly and lightly;

11/12

Some Notions of Agile
 Self Organizing
 Limits on external control
 Collective abilities
 Unpredictability
 Changing conditions

Adaptive is a repeated theme.
Agile project management needs
to adapt to the changing aspects
of the project, in some self
organizing way to address
unpredictability.

12/12

The Problem with
the Agile Project
Management
Discussion

Agile software development
is about ―engineering‖ the
product.
Project management is about
the ―processes‖ around
engineering the product.


To avoid this, we need to
understand both engineering
and management are needed

Overlap is present, but separation of
concerns is also present.
So back to the core principles of project
management – what does agile say
about:
 Integration
 Scope
 Time
 Cost
 Quality
 Human Resources
 Communications
 Risk
 Procurement

14/12

A General Framework for Managing
Projects of all Types

Deliverables Based Planning, identifies, plans, costs, executes,
measures, adjusts and engages the stakeholders in the production of
deliverables

But First an Observation about the
―method‖ discussion
 The theme of simplicity and parsimony
gets mangled
When we talk
 Methods and process frameworks are
about project
management confused
and especially
 When ―agile‖ speaks about project
Agile project
management management, they usually speak about
activities around developing software
 Some of these are project
management, some are engineering
activities

Four Key Element of Managing a Project

1. What business capabilities
will we need to satisfy the
customer?
2. What technical requirements
must be fulfilled to enable
these business capabilities
3. What is the plan for
delivering these technical
requirements?
4. How can we credibly execute
the plan to be on-schedule,
on-budget, and assure that
product or service meets the
requirements?
17/12

Capabilities provide the business with the ―ability‖ to perform a function

These capabilities should be described in business process terms, not technical
requirements terms:
 We need the capability to integrate our top 10% suppliers in the Accounts Payable
system, 90 after merging two business units.
 We need the capability to scale our claims processing system 250% in 4 calendar
weeks during a national disaster.
 We need the capability of providing a 200% increase in bandwidth during a major
sporting event.

18/12

The Plan Is A Strategy For The
Successful Completion Of The Project
The Plan describes where we are going, the various paths we can take to
reach our destination, and the assessment points along the way to assure we
are making progress.
These assessment points measures the ―maturity‖ of the product or service
against the planned maturity. This is the measure of progress – not the
passage of time or consumption of money.

19/12

The Performance Measurement Baseline is a time–phased schedule of all
the work to be performed, the budgeted cost for this work, and the
organizational elements that produce the deliverables from this work.

20/12

Execution is about performing the planned work, while assuring all
performance assessment represent physical percent complete.
Delivering On-Time, On-Budget, and On-Specification is the core concept for
successful execution.

21/12

So What Are The
Common Themes?

 Identify the work
 Schedule the work
 Cost the work
 Execute the work
 Measure cost, schedule,
and quality (Technical
Performance)
 Adjustments the plan
with these
measurements
 Keep the everyone in the
loop

The 4 Practice Areas of Deliverables Based Planningsm
1
10 Organizing Principles of Deliverables Based Planningsm

Identify Business
1 Why Needs
Operational
Needs

Capabilities
Based Plan
2 System Value
2
Stream
Identify
3
Requirements
What
4 Baseline Technical
Technical
Performance
Requirements
5 Measures

3 Establish a
Performance
6 PMB
Measurement
7 Baseline
Technical
8 Performance
How
Measures Earned Value
Where
9 Performance
4 Execute the
When 0% /100%
10 Performance
Who
Measurement
Baseline
Changes to Changes to Changes to
business strategy requirements project plan

Embedded Risk Management

23/12

Putting The Four Core Processes of
Deliverables Based Planningsm to Work
1 Define the set of capabilities needed to achieve the program objectives or the particular end
Identify Needed state for a specific scenario. Using the ConOps, define the details of who, where, and how it
System is to be accomplished, employed and executed.
Capabilities
What capabilities are needed to fulfill the ConOps and System Requirements?

Define the technical and operational requirements that must be in place for the system
2
capabilities to be fulfilled. First, define these requirements in terms that are isolated from any
Establish the
Requirements implementation technical products. Only then bound the requirements with technology.
Baseline
What technical and operational requirements are needed to fulfill these capabilities?

Build a time–phased network of schedule activities describing the work to be performed, the
3
Establish the
budgeted cost for this work, the organizational elements that produce the deliverables, and
Performance
the performance measures showing this work is proceeding according to plan.
Measurement
Baseline
What is the schedule that delivers product or services that meet the requirements?

Execute work packages, while assuring all performance assessment are 0%/100%
4
Execute the
complete before proceeding. No rework, no forward transfer of activities to the future.
Performance
Assure every requirement is traceable to work and all work is traceable to requirements.
Measurement
Baseline
What are the periodic measures of physical percent complete?
24/132

Deliverables Based Planningsm Overview

25/132

How you perform these four
processes is not as important
as having the four processes
be performed

Without the presence of these four
processes, the project is in jeopardy
not matter what engineering method
you use.
Test the method – the practice –
against the principles to confirm there
is coverage.
If parts are missing, determine if they
are important to the project

26/12

Project Management is
about answering these
questions with
confidence

 Do we know what done looks like
in terms meaningful to the
customer? «Capabilities»
 What are the technical aspects of
being done? «Requirements»
 What is the path to getting to
done? «Performance
Measurement Baseline»
 How long will it take to get to
done? «Project Execution»
 What are the impediments to
getting done? «Continuous Risk
Management»
27/12

CMU Talk - PM Paradigm

Recomendados

Recomendados

Mais conteúdo relacionado

Mais de Glen Alleman

Mais de Glen Alleman (20)

Último

Último (20)

CMU Talk - PM Paradigm