The previous post mentioned several books that should be mandatory reading for anyone in the project success prediction business. I've acquired another book that is one of those "paradigm shifting" texts. Reasoning about Uncertainty, Joseph Y. Halpren, MIT Press, 2003.
It's a book about how to think about the underlying processes of uncertainty. Since MANAGING IN THE PRESENCE OF UNCERTAINTY is the role of the project management and her team, this book speaks to the theory behind that approach to Project Management.
As an aside, when people speak about the failure of the Waterfall methods, Critical Path Method (CPM), PERT, GANTT and the other core processes of management projects - they usually fail to consider that managing in the presence of uncertainty is the "norm" in mature project management organizations. In fact it is mandated by DID 81650 on government procurement projects. Anyone NOT considering the underlying probabilistic nature of a network of project activities is not actually "managing" the project, but simply observing the project pass them by and most likely go directly to the ditch.
So why is Reasoning about Uncertainty interesting?
- It describes the underlying processes of "many worlds" - this is the many possibilities that may occur in a single collection of activities. The probabilistic nature of nature.
- Measuring the attributes of this probabilistic nature is simple at first. But then Mr. Bayes is introduced and the world get more complex. Much closer to reality.
What struck me most was the concept that "simple minded" approaches to probability and statistics work for "simple minded" problems. The real world of course is not "simple minded." This book along with Terry Williams' Modelling Complex Projects, John Wiley & Sons are good starting points for programmatic risk analysis that is the foundation of large complex projects in construction, aerospace and enterprise systems.
For example:
- "What is the completion confidence for flying to the International Space Station in 2014?"
- "What is the cost confidence in rolling out 54 SAP sites across the enterprise for under $235M?"
- "What is the probability that we won't need to have a second set of engineering development units for the light rail systems between Boulder and Denver?"
Now these all sound very esoteric for many in the code development business. But how about:
- What is the confidence that the features needs in the first release will earn their keep in the business 90 days after they are available to the order entry staff?
- What is the confidence that we'll spend less than $250,000 on the needed capabilities described in the Statement of Work for the sales order entry system?
The traditional agile approach is to push these questions to the customer, then use velocity or some other "driving in the rear view mirror" approach to inform the customer how much money has been spent and how many features made it into the current release. All interesting things to cost accountants. But not that useful for forecasting the credibility of the plan, compliance with the "not to exceed" budget and the probability of fulfilling the business case on the "go live" date.
