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

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

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 technical capabilities that are less than planned.tec ca capab t es t at a e ess t a p a ed

3

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

Colorado Springs PMIRisk Management in Five Easy PiecesColorado 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

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

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 bean 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 useand 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

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 ouspage.

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

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 optimisticThe 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 goingOne 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

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

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 othe 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 time5. Identifying risks without communication them is a waste of time.

11

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‐definewhat 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.

Scrum does this by predefining the outcomes of the iteration. DoD 5000.02 does this as Sc u does t s by p ede g t e outco es o t e te at o o 5000 0 does t s aswell 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

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

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 CrossTalkabout 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 f t th d th t b li d t j t A il hperformance management method that can be applied to every project. Agile shares many 

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 

t B t th t t f th timanagement. But that a story for another time

14

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

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 bl d i t id th f thi b i f t lk b t it t b dd d if ’ llproblem and is outside the scope of this brief talk, but it must be addressed if you’re really 

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

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. 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