Making decisions in the presence of this uncertainty is part of our job as project managers, engineers, developers on behave of those paying for our work.
It's also the job of the business, whose money is being spent on the projects to produce tangible value in exchange for that money.
From the introduction of the book to the left...
Science and engineering, our modern ways of understanding and altering the world, are said to be about accuracy and precision. Yet we best master the complexity of our world by cultivating insight rather than precision. We need insight because our minds are but a small part of the world. An insight unifies fragments of knowledge into a compact picture that fits in our minds. But precision can overflow our mental registers, washing away the understanding brought by insight. This book shows you how to build insight and understanding first, so that you do not drown in complexity.
So what does this mean for our project world?
- The future is uncertain. It is alway uncertain. It can't be anything but uncertain. Assuming certainty, is a waste of time. Managing in the presence of uncertanity is unavoidable. To do this we must estimate. This is unavoidable. To suggest otherwise willfully ignore the basis of all management practices
- This uncertainty creates risk to our project. Cost, schedule, and risks to the delivered capabilities of the project or product development. To manage in with closed loop process, estimates are needed. This is unavoidable as well.
- Uncertainty is either reducible or irreducible
In both these conditions we need to get organized in order to address the underlying uncertainties. We need to put structure in place in some manner. Decomposing the work is a common way in the project domain. From a Work Breakdown Structure to simple sticky notes on the wall, breaking problems down into smaller parts is a known successful way to address a problem.
With this decomposition, now comes the hard part. Making decisions in the presence of this uncertainty.
Reasoning about things that are uncertain is done with probability and statistics. Probability is a degree of belief.
I believe we have a 80% probability of completing on or before the due date for the migration of SQL Server 2008 to SQL Server 2012.
Why do we have this belief? Is it based on our knowledge from past experience. Is this knowledge sufficient to establish that 80% confidence?
- Do we have some external model of the work effort needed to perform the task?
- Is there a parametric model of similar work that can be applied to this work?
- Could we decompose the work to smaller chunks that could then be used to model the larger set of tasks?
- Could I conduct some experiments to improve my knowledge?
- Could I build a model from intuition that could be used to test the limits of my confidence?
The answers to each of these informs our belief.
Chaos, Complexity, Complex, Structured?
A well known agile thought leader made a statement today
I support total chaos in every domain
This is unlikely going to result in sound business decisions in the presence of uncertainty. Although there may be domains where chaos might produce usable results, when some degree of confidence that the money being spent will produce the needed capabilities, on of before the need date, at of below the budget needed to be profitable, and with the collection of all the needed capability to accomplish the mission or meet the business case, we're going to need to know how to manage our work to achieve those outcomes.
So let's assume - with a high degree of confidence - that we need to manage in the presence of uncertainty, but we have little interest in encouraging chaos, here's one approach.
So In The End
Since all the worlds a set of statistical processes, producing probabilistic outcome, which in turn create risk to any expected results is not addressed properly - the notion that decisions can be made in the presence of this condition can only be explained by the willful ignore of the basic facts of the physic of project work.