The five irreducible principles of project management are: 1) Define the end goal. 2) Create a plan to reach the goal. 3) Understand the resources needed to execute the plan. 4) Identify and address impediments along the way. 5) Measure progress against the plan.

1. I’d like to thank Martin for inviting me again to speak to you about project management.
My contribution is from the point of view of a program manager in the aerospace and
defense business, rather than a software development manager. The programs we work
are software intensive, but not in the way commercial software projects are. The software
on our programs is embedded in other systems – avionics, flight controls, ground
management systems of aircraft and spacecraft.
1

2. There are three outcomes for this talk.
1. I’m going the suggest there is common misunderstanding that software development
and project management are the same thing.
2. There are 5 irreducible principles for managing any project, no matter the domain or
the context.
3. And, as software developers, along with the project manager, you are not answering
the questions from these irreducible principles, you re probably doing project
the questions from these irreducible principles, you’re probably doing project
management and your project is in jeopardy and you may not know it.
2

3. The amount of risk a project can tolerate is directly related to the business domain and the
context of the project within that domain.
Understanding this tolerance for these risk levels are critical to choosing and applying any
software development method.
However, the five immutable principles presented here are juts that, immutable. There
must be present in some form no matter the software development method, the level of
risk tolerance of the domain and the context within that domain.
The risk tolerance for cost is defined as the ability to the customer to absorb changes in the
planned cost through management reserve and the application of additional funds.
The risk tolerance for schedule slippage is defined as the ability to still produce value for
the customer in the presence of a late or slipping schedule.
The risk tolerance for Technical Performance means the customer is willing to accept
tec ca capab t es t at a e ess t a p a ed
technical capabilities that are less than planned.
3

4. As a framework for defining the process areas of a software development project, CMMI
DEV V1.2 is a good starting point.
Not that we are suggesting CMMI DEV be applied to your projects, just that if we need a list
of the processes that should be found on a project, this is a one.
Note that the Engineering Process Areas are where software development activities are
found. There are other process areas in the CMMI model, needed for project success.
4

5. Colorado Springs PMI
Risk Management in Five Easy Pieces
Colorado Springs, Colorado May 8th , 2008
The five irreducible principles of project management are:
1. Know where you are going by defining “done” at some point inf the future. This point
may be far in the future – months or years from now. Or closer in the future days or
weeks from now.
2. Have some kind of plan to get to where you are going. This plan can be simple or it can
be complex. The fidelity of the plan depends on the tolerance for risk by the users of
the plan.
3. Understand the resources needed to execute the plan. How much time and money is
needed to reach the destination. This can be fixed or it can be variable.
4. Identify the impediments to progress along the way to the destination. Have some
means of removing, avoiding, or ignoring these impediments.
5. Have some way to measure your planned progress, not just your progress. Progress to
Plan must be measured in units of physical percent complete.
a ust be easu ed u ts o p ys ca pe ce t co p ete
5

6. When we speak about project management in the context of product development or
service providing, we apply these 5 questions to the “project” as a whole. Ignoring for a
minute the development method used to actually produce the product or the service.
If we start with the method, then we will miss the critical success factors for the project
and focus on the means rather than the end.
6

7. The key here is that requirements tell us something about where we are going.
But requirements come in all shapes and sizes.
Here’s a sample of two extremes.
A small project and a not‐small project.
The small project is straight forward in terms of requirements. There is a list of them on the
flip chart. They are likely well understood. They probably can be estimated in terms to cost
an schedule. And most importantly the interactions between the requirements can be
an schedule And most importantly the interactions between the requirements can be
intuited with a little effort.
The project on the right is a different class of effort. This is the top level component (if you
can call them that) arrange of the Future Combat System. It’s a $35B, that’s billion with a B
program to restructure the entire US Army Battle Space Management processes.
I help one of the teams – the Class I team – build their Performance Measurement Baseline
and get that information into a cost and schedule management system, so they can use
and get that information into a cost and schedule management system so they can use
Earned Value Management to “manage” their program.
FCS is a software intensive system, where software is in everything from small hand held
devices to major buildings housing the “battle space management command.”
Software doesn’t work, the FCS doesn’t work. Soldiers can’t do their job. Soldiers can’t o
their job – BIG PROBLEM.
7

8. Now that we know where we want to go, the next question is how to get there.
How do we build the products or provide the services needed to reach the end of our
project.
There are numerous choices, depending on the domain and the context of the project in
that domain.
For the software domain there are many context’s. Using the example on the previous
page, let s look at two methods. These are the extreme ends of the spectrum of contexts
page, let’s look at two methods. These are the extreme ends of the spectrum of contexts
and methods. They can serve to focus the discussion on project management rather than
product development methods, by hopefully disconnecting project management from
product development so we can look at them separately.
In the first software development context – a list of features, SCRUM is a popular approach.
But there are many more software based project, possibly more complex than the example
from the previous page to the “wickedly” complex program also shown on the previous
o t e p e ous page to t e c ed y co p e p og a a so s o o t e p e ous
page.
The SCRUM method is shown in its common diagram. But below it is the method used for
product development in the US Department of Defense – DoD 5000.02. The products are
not actually developed by the DoD (except in rare cases). But are instead, procured. So
acquisition management is guided by this process. While few here – I’ll assume work in the
DoD 5000.02 context, there are direct connections between SCRUM and this approach.
Both are iterative, both are incremental, both can deal with emerging requirements, both
make use of “test driven planning,” and both have clear and concise measures of physical
percent complete.
8

9. No that we know where we’re going and how to get there – do we have all we need to
reach the end?
Staff, time, money, the necessary skill and experience and the proper management
support.
These are all obvious on any project – at least any well managed project.
But there are always underlying issues with answering these questions.
The first is that management as well as the development organization are always optimistic
The first is that management as well as the development organization are always optimistic
about the outcome. This is the very nature of project management. Why be pessimistic?
Well maybe not pessimistic, but how about realistic? What do we mean when we say
realistic? One good word is credible. Credible could be optimistically credible or
pessimistically credible. But either way we have a credible understanding of what it takes to
reach the end.
One part of credible is knowing what the risks and uncertainties are and how we are going
One part of credible is knowing what the risks and uncertainties are and how we are going
to dealing with them. Managing in the Presence of these uncertainties is critical to reaching
our goal. Risk and uncertainty never go away. They are always there. They are unavoidable.
9

10. There are many phrases about managing in the presence of risk.
Tim Lister’s is a good one. Another is Kent Beck’s
Optimism is the disease of software development, feedback is the cure.
Getting feedback is built into Scrum. It is also built into DoD 5000.02. The two opposite
ends of the development method spectrum – both share the same core values.
10

11. If risk management is how adults manage projects, here are some principles (sub
irreducible principles) of project management.
These five principles are simple, obvious, but difficult to implement. This reason they’re
difficult is that most people shy away from risk. Managing in the presence of risk does not
come naturally.
It is a learned behavior. And once learned it has to be practiced. But before it can be
learned and then practiced, “managing in the presence of risk,” must become part of the
business cultural.
Some cultures doe this better than others. NASA is probably better than others. But even
NASA has moved a risk adverse culture in the past decades.
1. Hoping that something positive will result is not a very good strategy. Preparing for
success is the basis of success.
2. Single point estimates are no better than 50/50 guesses in the absence of knowledge of
S g e po t est ates a e o bette t a 50/50 guesses t e abse ce o o edge o
the standard deviation of the underlying distribution.
3. Without connecting cost, schedule, and technical performance of the effort to produce
the product or service the connection to value cannot be made.
4. Risk management is not an ad hoc processes that you can make up as you go. A formal
foundation for risk management is needed.
5. Identifying risks without communication them is a waste of time.
5 Identifying risks without communication them is a waste of time
11

12. With the information from the previous 4 irreducible principles, we now need to confirm
we are making progress. The key principle here is “planned progress.” We must pre‐define
what progress we must make at any specific point in the project, otherwise all we can
determine is the passage of time and the consumption of money. Preplanning the progress
is the basis of “performance based” measurement for both project processes and technical
products.
Like Kent Beck’s advice we need feedback on our progress.
There is only one kind of feedback for projects – measures of physical percent complete.
No soft touchy feely measures of progress. No hand waving measures. Physical, tangible
evidence of progress.
Something that can be physically shown to the customer. Something that is compliant with
the planned technical outcomes at this point in the plan.
Sc u does t s by p ede
Scrum does this by predefining the outcomes of the iteration. DoD 5000.02 does this as
g t e outco es o t e te at o o 5000 0 does t s as
well with the Integrated Master Plan and Integrated Master Schedule.
So looking two extremes of the spectrum – one a software development method and the
other a mega‐program procurement method. Both share the same principles and
outcomes. Something that is tangible and measurable at incremental steps along the way
to “done.”
12

13. Project management means being able to say these any time someone asks you “are you
managing the project?”
If you can say this with a straight face, then you need to take action to start to move in that
direction.
13

14. So let’s look at how these 5 irreducible principles can be connected to some software
development methods.
I’ve picked 4 development methods that I’ve familiar with and used on real projects.
For agile, I’ll assume the usual suspects – Scrum, XP, Crystal, DSDM. These all have
methods, very formal methods by th way, of capturing what the customer wants to have
done, planning that work – using a time boxed, level loaded staffing profile. The
measurement of progress is again time boxed with the notion of “velocity” used to forecast
the next period of performance. Just as an aside “velocity” is a unitless measure and not
tied to any actual business metric, money for example. There is literature in CrossTalk
about connecting Agile with Earned Value. I’ve presented papers and so has Paul Solomon
– Performance Based Earned Value and the former EVM Director on B‐2, about EV and
agile. it is a “must read” set of papers.
The IMP/IMS method is a DoD planning, scheduling, cost management, and technical
performance management method that can be applied to every project. Agile shares many
f t th d th t b li d t j t A il h
of the attributes with IMP/IMS.
RUP has formal and informal processes that cover all 5 of the principles and of course
Prince2 does as well
So if your only speaking about software development methods then the principles can be
covered. But of course you’ll be missing the other non‐irreducible measures of project
management. But that a story for another time
t B t th t t f th ti
14

15. After discovering that time is not money and money is not time, the next eye opener for all
project work is there is a natural statistical variability of the time elements.
So no matter what software development method you are applying inside a project
management set of processes, you must come to grips with the statistical nature of cost,
schedule, and technical performance.
This area is called Programmatic Risk and its cousin Technical Risk. The Programmatic Risk
concept is not well understood outside the defense and space business. There it is
mandated that Programmatic Risk be managed – DID 81650 describes this mandate.
The Monte Carlo simulation method is the way to assess the behavior of the network of
activities, but there subtleties beyond just the simulation of the network.
The Monte Carlo tools don’t easily model the coupling and correlations between the work
activities in a proactive manner. There are other tools for modeling the network, but they
are also outside this presentation.
15

16. There are also a few “laws of physics” for projects. The first is late starts mean late finishes.
If you start late you’ll likely finish late if you don’t have schedule margin. How much
schedule margin is needed? Good question. There are ways to find out. Some fancy some
simple. But for sure if you have no margin and you start late you're late.
Same goes for budget.
While we said before we need to measure progress as physical percent complete, the units
of measure must be meaningful to the stakeholders. As an undergraduate physics major we
used to play a joke on our TA – which I got back in spades a few later when I was a TA. The
joke in classical mechanics is to do all the calculations in the right units of measure –
Standard International (SI) units. Then convert those to olde English measures. Volume in
cubic meters can be converted to Hogs Heads. Or kilometers per hour to furlongs per
fortnight.
So we need to consider what the stakeholders really want to know. This turns into a metrics
problem and is outside the scope of this brief talk, but it must be addressed if you’re really
bl di t id th f thi b i f t lk b t it t b dd d if ’ ll
managing the project. But as the bullet says – time and money – are good starting points.
Finally a universally applicable principle is to never confuse effort with results. The
customer paid for results.
16

17. So we’ve arrived at the end of our short time here. What did we learn?
There are 5 irreducible principles of project management, no matter the project domain
and context.
We need to confirm are project is applying these principles, and look for the evidence in
the form of practices for each principle.
Hopefully I’ve conveyed the notion that project management not the same as product
development.
Both are needed, some times more than the other depending on the context and the
domain.
If I’m building a web site I approach the project management and development method
differently than if I’m build the terminal guidance control software for an autonomous Mars
Lander
17