The Mathematics of Project Management

I've an interesting exchange of sorts on Jurgen Appelo's blog. It started with me making a comment about the application of Complex Adaptive Systems to projects and software development. I've somewhat familiar with CAS through several channels - my physics background tool me into deep inelastic scattering in the late 70's.This the use of electrons to look inside protons to see what they contain.

They contain quarks of course, but in those days how many, what are doing in there, and what can we learn from them was still emerging. My job as a lowly grad study was to write FORTRAN code to decipher the pictures on film from the camera. I also worker from there in defense, since I did not have any original ideas required to be a post-doc. Missiles flying at hypersonic speed through varying air densities is sorta like compressible fluid flow, which is a cousin of the math found in CAS adaptive systems.

Of course the science around CAS is not a single science, it is many sciences. Some are physics - compressible fluid flow and turbulence, some is biology, some is social science, and some is the co-opted terms used in the agile community. As you move from left to right in that list, the science is diminished and the hand waving increased. I usually loose interest right at the boundary of the compressible fluid flow equations and the start of hand waving.

So when I mentioned that the application of CAS to projects and software development was "sketchy" in my experience, the agilest on that blog came out and started down the normal path of "how could mathematics possibly be used to manage projects?"

Well here's how math is used to answer several questions:

• When will this project be done?
• What will it cost when it is done?
• What are the "hot" spots in the schedule that we need to look after while we're trying to get done on time?
• What confidence do we have that the cost and schedule numbers are credible?
• How does that credibility increase with the passage of time?
• What can we do to assure the credibility is actually increasing with time?

The answers to these and other question like these starts with a Monte Carlo Simulation (MCS) tool. Monte Carlo tools are probabilistic assessments of dynamic systems. The first Monte Carlo simulations in the modern ear came from nuclear weapons research during WWII. Ulam, Fermi, von Neumann, and Metropolis developed an algorithm to simulate the collisions of neutrons inside the atomic bomb, without having to actual explode the bomb.

The MCS approach to schedule simulation goes like this:

1. Construct a well formed activities network. This means no widows or orphans. Every task has a predecessor and successor, except the first and last task. These are usually Authorization to Process and Program Termination.
2. Assign a probability distribution to the duration of each task. This usually starts with a Triangle Distribution is there is no information about the task. Other distributions can be used is there is knowledge.
3. Assign the Most Likely duration. This is the duration that is "most likely" to take place. This value can be derived in a variety of ways. Too many for this post
4. Assign the Lowest and Highest durations around the Most Likely.
5. Indicate which tasks you'd like to learn something about.
6. Run the Monte Carlo Simulator. We use Risk+ and @Risk for Project. PERTMaster is another.
7. The "watched" tasks create a sampling of completion times through the following means:

• A random duration value is drawn from under the curve for each task.
• This number is entered into the DURATION field of MSFT Project
• Do this for all the Tasks
• "Push" F9 to calculate the network
• Record the finish date for the "watched" tasks in a histogram
• Do this 500 to 5,000 times

After the selected number of "runs" build a histogram of how many times a specific date came up. This is the Probability Density Function showing the confidence that the watched task will complete "On or Before" a specific date.

This approach can show the project management team the confidence in the schedule. If the plan - with the schedule margin - is to complete on or before 10 Nov 2009, and the MCS shows a 14% confidence of completing on or before 10 Nov 2009 - we need to talk.

That's all there is "talk." The MCS doesn't fix this. The MCS doesn't solve the problem. What it does is provide an assessment of the confidence of meeting the planned completion date.

For cost the work is similar. Build a probabilistic model of the cost for each work element. ONLY in LEVEL OF EFFORT projects does Time = Money.
    This is the hidden outcome of agile project management.

• Time boxed scheduling - fixed iterations
• Fixed resource loads - the same number of people for each iteration
• Fungible resources - everyone does more of less the same job

Time = Money.

This is rarely true on any non-trivial project.

Finally the MCS tools can tell us how much margin (cost and schedule) is needed to raise the confidence to say 80%.

1. Build a schedule with no margin tasks on the critical path
2. Run the MCS
3. Determine where the 80% confidence end date is
4. IF the end date is to the left of the planned for (hoped for) date, then see what that gap is.
5. IF it is something non-trivial - say 45 days for a year long project, then you need 45 days worth of margin tasks to hold the planned completion date.

Of this is a notional explanation. Real projects, with real costs and schedule, real risks, and real changing requirements will require more work. But this approach is used every week on aerospace and defense programs that are software and hardware intensive.

So to answer the question on the Blog - where the math model. It's mandated by DID-81650 and several other DFARs (Defense Federal Acquisition Regulations) for programs we work.