1.
1/27

2.
 Mike Cohn’s presentation at:
http://www.mountaingoatsoftware.com/system/presen
tation/file/123/Cohn-Agile-and-Deadly-Sins-of-Project-
Management.pdf
 Mike raises some interesting questions about
applying “agile” to development projects.
 His approach, however of replacing bad project
management with agile is not new, but it’s also
not correct.
 Fix the broken process, before replacing it with
another.
2/27

3.
3/27

4.
 Agile has very useful software development
practices.
 But the notion that Agile is the answer to bad
project management is a common starting
point for some agilest.
 The problems (the sins) mentioned in Mike’s
presentation are just “bad” project
management.
Don’t Do Stupid Things on Purpose
4/27

5.
 “Good” project management is always the
first (and many times best) antidote to “Bad”
project management.
 Failure to apply “Good” project management
usually leads to “Bad” projects.
 This choice is sometimes made intentionally
followed by complaints that the PM method
didn’t work.
Don’t Do Stupid Things on Purpose
5/27

6.
No matter what project, what project method, what business domain, or what
context inside that business domain – there are 5 Immutable Principles of PM
6/27

7.
 As Project Managers and Developers, Do we …
 Know Where Are We Going?
 How Are We Going To Get There?
 Have Enough Time, Resources, And Money To Get
There?
 Know What Impediments Will We Encounter Along
The Way?
 Know If We Are Making Progress?
 If not, we’re doing “bad” Project Management.
7/27

8.
1. Where Are We Going?
Eliciting Requirements Is Domain Dependent
Implement the 8 stories for our new “Design and integrate 18 major weapon systems and platforms
warehouse inventory package tracking simultaneously within strict size and weight limitations, while
system using the existing web site synchronizing the development, demonstration, and production of as
platform as a starting point. many as 157 complementary systems with the Future Combat System
content and schedule.” (This is an actual requirement)
8/27

9.
2. How Do We Get There?
Some problems respond
to lightweight This approach works
approaches, like well when we don’t
Scrum, DSDM, Crystal, know what “done” looks
and XP as product like with enough clarity
development methods.
Others require more
complex approaches, like
a System of Systems
(SoS) spiral development
processes. So
In all cases a disciplined Does
approach increases the This!
probability of success – no
matter the complexity of
the problem or the
solution.
9/27

10.
3. Do We Have Enough Time, Money, And
Resources To Get To DONE?
A Common Problem A Simple Solution
 Using the Integrated Master Plan and Integrated
master Schedule, construct a network of Work
We have undue optimism of our Packages describing the flow of work.
capacity for work  Use documented procedures – no matter the
method – for estimating and planning using
historical data.
 Understand and prioritize risks for each critical
We attempt to avoid risk and component empowers management and staff.
uncertainty
 Use this knowledge to control your optimism.
 Simple statistical models are more often correct
We rely too much on intuitive than the human judgment.
judgment
 Have this number to back up your intuition.
The Rational Planning of (Software) Projects, Mark C. Paulk, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA 15213–3890
10/27

11.
4. What Impediments Will We Encounter
Along The Way To DONE?
Risk Management
Is How Adults
Manage Projects
‒ Tim Lister
11/27

12.
5. How Do We Know If We Are Making
Progress As Planned?
The only measure of progress is the Physical Percent
A
Complete for the planned deliverables.
Physical Percent Complete means tangible evidence of the
B outcomes that were planned – measured at the time they
were planned to be delivered.
This is the basis for full Earned Value Management with
physical percent complete.
C
This is also a natural a fit with the agile approaches to
software development.
All successful methods measure the evidentiary outcomes in
D units meaningful to the stakeholders.
These units are usually “money” and “time.” 12/27

13.
Sins Virtue
Lust Chastity
Gluttony Temperance
Greed Charity
Sloth Diligence
Anger Patience
Envy Kindness
Pride Humility
13/27

14.
Sins Virtue
Gluttony Temperance
Lust Chastity
Sloth Diligence
Opaqueness Visibility
Pride Feedback
Wastefulness Conservation
Myopia Foresight
14/27

15.
Mike’s Agile Counter Example Virtue of Deliverables Based Planning®
Fixing all dimensions – scope,  Measures of Effectiveness (MoE) and Measures of
schedule, and quality. Performance (MoP) defined the parameters of
Technical Performance Measures (TPM).
Impossible schedules.  Probabilistic cost and schedule margins (DID
81650 in the defense business).
Death marches.  Pace the work into Work Package and Planning
Packages within “rolling waves.”
 Always have a defined outcome within the period
of performance that has a “sensible” horizon.
Trying to do too much for the  Resource management plans tied to measures of
resources available. Physical Percent Complete
Cutting quality to meet other  Quality is a Technical Performance Measure.
goals.  Make compliance with TPM’s visible to senior
management
15/27

16.
Mike’s Agile Counter Example Virtue of Deliverables Based Planning®
 Defined capabilities, traceable to requirements,
traceable to deliverables produced by Work
Intense or unrestrained craving Packages in the Integrated Master Schedule.
for features.  Trace requirements to needed capabilities.
 Answer every request with a mandatory trade-
space assessment. Why do we need this?
Trying to put too many features  Monetizing each deliverable against the Budgeted
into a product during the time Cost for Work Scheduled (BCWS)
allowed.
 Paired Comparison or Borda Ranking of features.
Treating all features as
 Analysis of Alternative (AoA).
“critical.”
 “Trade Space” analysis of each feature.
 Understanding the “capacity for work.”
Overtime, reduced quality,
 Managed resource plans based on this capacity
surprises.
and the feedback from measurable performance
16/27

17.
Mike’s Agile Counter Example Virtue of Deliverables Based Planning®
 Measures of Effectiveness and Performance
Failing to do high quality work
connected to Technical Performance Measures
at all times.
defined as part of the “narrative” of the work.
 Technical Performance Measures for each major
deliverable.
 Measure compliance with these.
Testing quality at the end.  Adjust forecast of future performance based on
past performance.
 Use only tangible evidentiary materials to measure
performance.
 Use what ever method you need to confirm
Instability during
working product on a daily, weekly, or no more that
development.
every other week basis.
Big delays.  Provide cost, schedule, and technical margins.
Unpredictable schedules.  Execute according to plan.
17/27

18.
Mike’s Agile Counter Example Virtue of Deliverables Based Planning®
 Measures of physical percent complete based on
planned physical percent complete establish the
Obscuring progress, quality, or
“credibility” of progress.
other attributes of a project.
 Measuring actuals against plan on fine grained
boundaries keeps every one honest
 The true state of the project is comparison of
actuals with the plan for cost, schedule, and
Not knowing the true state of
technical performance
the project.
 Cost, Schedule, and Technical performance
measures on fine grained boundaries.
 Ask “How Long Are You Willing To Wait BeforeYou
Surprises Find Out You’re Late?
 Measure at least at ½ that duration.
 Start making decisions on actionable information
Poor decisions
from the performance measures.
18/27

19.
Mike’s Agile Counter Example Virtue of Deliverables Based Planning®
 No one knows everything - period. Stop trying.
Believing that we know  This is why there are rolling waves, spirals, drops in
everything to build the large complex programs.
product.  Realistic development is part of all “good” project
management.
 This is a “business management” issue.
A lack of stakeholder and user
 Why would you spend someone else's money and
involvement.
not have them involved in that process?
 Feedback comes at least monthly on large
government programs.
 Feedback is always measured in units meaningful
Failure to solicit feedback.
to the participants.
 To do otherwise is not allowed in DoD, DOE, NHS –
why do IT projects continue to put up with this?
 Learned orgs survive, others don’t – find better
Failure to learn.
projects to work on.
19/27

20.
Mike’s Agile Counter Example Virtue of Deliverables Based Planning®
 Failure to manage resources violates at least 4
Chapters and dozens of sections of PMBOK.
Misuse of critical resources
 Why is this allowed – it’s “bad” project
management.
 Management is a verb.
Losses of creativity, motivation,
 Do good management.
and time
 Stop doing stupid things on purpose.
 The role of management is to lead.
Project malaise  Start leading.
 The Marines can figure this out, why can’t you?
 Plan the work – work the plan.
Delays
 Late starts = Late Finishes.
 Be a manager, stop being stupid.
Doing it the same way (again)
 Come on folks “nut up or shut up”.
20/27

21.
Mike’s Agile Counter Example Virtue of Deliverables Based Planning®
Not seeing beyond your own  Integrated Master Plan
work
Teams who don’t see the big  Integrated Master Schedule
picture
 Integrated Master Schedule, with “giver/receiver”
Individuals who work only
links, traceable vertical and horizontal paths to the
within their roles.
deliverables
 Design to, Build to, Test to specification.
 Use “Test as you Fly” paradigm. This means full
Unsuccessful products.
fidelity test environment.
 100% evaluation of all deliverables.
 There is a fundamental law of physics for projects –
Delays.
Late Starts = Late Finishes.
21/27

22.
22/27

23.
23/27

24.
24/27

25.
Developing software based products is not the same as managing the development of
software based products.
A good example of why is found in the CMMI DEV 1.2 table.
25/27

26.
Why is Software Development not the
Same as Project Management?
Process Management Acronym Level 2 Level 3 Level 4 Level 5
Organization Process Focus OPF  CMMI-DEV 1.2
Organization Process Definition OPD 
Organization Training OT  Separates
Organization Process Performance OPP
Organizational Innovation and Deployment OID


“Engineering”
Project Management Level 2 Level 3 Level 4 Level 5 from the
Project Planning PP 
Project Monitoring and Control PMC  management
Supplier Agreement Management SAM 
Integrated Project Management IPM  of Engineering
Risk Management RSKM 
Quantitative Project Management QPM 
for a simple
Engineering Level 2 Level 3 Level 4 Level 5 reason …
Requirements Management RM 
Requirements Development RD 
Technical Solution TS 
Product Integration PI  “Doing, is not
Verification VER 
Validation VAL 
the same as
Support
Configuration Management CM
Level 2

Level 3 Level 4 Level 5 management
Process and Product Quality Assurance PPQA  of the Doing”
Measurement and Analysis MA 
Decision Analysis and Resolution DAR 
Causal Analysis and Resolution CAR  26/27

27.
Process Management Acronym Level 2 Level 3 Level 4 Level 5
Organization Process Focus OPF   Agile methods
Organization Process Definition OPD 
Organization Training OT 
include a few
Organization Process Performance OPP  process areas
Organizational Innovation and Deployment OID 
Project Management Level 2 Level 3 Level 4 Level 5
outside
Project Planning PP  “Engineering.”
Project Monitoring and Control PMC 
Supplier Agreement Management SAM 
 But there remains
Integrated Project Management IPM  many other PA’s
Risk Management RSKM 
Quantitative Project Management QPM 
not included in
Engineering Level 2 Level 3 Level 4 Level 5 Agile, that are
Requirements Management RM 
Requirements Development RD  part of developing
Technical Solution TS  software based
Product Integration PI 
Verification VER  products.
Validation VAL 
Support Level 2 Level 3 Level 4 Level 5
Configuration Management CM 
Process and Product Quality Assurance PPQA 
Measurement and Analysis MA 
Decision Analysis and Resolution DAR 
Causal Analysis and Resolution CAR 
27/27