There’s a fallacy used by some in the software development business, that estimates are not needed to make decisions in the presence of uncertainty. It turns ourt of course, this can only be true if the world we live in is deterministic.
But we don’t live in a deterministic world, we live in a non-deterministic world. Determinism was debunked long ago. But that determinism was built on a house of sand, the originators of determinism just didn’t know it. In the same way those suggesting we don’t need to estimate, while spending other people’s money is a house built on sand.
Leibniz (1702): “There is no doubt that a man could make a machine which was capable of walking around a town for a time, and of turning precisely at the corners of certain streets. And an incomparably more perfect, although still limited, mind could foresee and avoid an incomparably greater number of obstacles. And this being so, if this world were, as some think it is, only a combination of a finite number of atoms which interact in accordance with mechanical laws, it is certain that a finite mind could be sufficiently exalted as to understand and predict with certainty everything that will happen in a given period. This mind could then not only make a ship capable of getting itself to a certain port, by first giving it the route, the direction, and the requisite equipment, but it could also build a body capable of simulating a man.”
Of course, Laplace had on math to support his position, that came later in the form of differential equations. But Laplace’s statements are the foundation of classical mechanics.
For each system in classical mechanics, there are equations of motions of the form:
d2r / dt2 = F(r)
which have a unique solution for given initial conditions:
(r(t0) = r0 and dr/dt (t0) = v0
Before moving on, the phrase about a machine capable of walking around town has come to pass. So now what about determinism and the machine.
Of course, the machine in the video wouldn’t be able to take a step without falling if it didn’t have a probabilistic feedforward adaptive closed loop control system. Closed-loop control systems actively control the system based on state feedback. Open-loop control systems execute a fixed sequence of control inputs without any feedback. Here’s a nice paper as an example of control systems, « A Probabilistic Approach to Mixed Open-loop and Closed-loop Control, with Application to Extreme Autonomous Driving. »
Putting this to work on Projects
In our domain, the role I usually participate in is called Program Planning and Controls. These planning and controls activities always take place in the presence of uncertainty, which of course creates risk. The presence of uncertainty makes the system indeterminate. And of course to manage in the presence of uncertainty and the resulting risks we need specific processes and practices based on principles.
Since all project work operates in the presence of uncertainty – reducible and irreducible – and the managers of these projects need to make decisions in the presence of these uncertainties, we need to make estimates to inform our decision-making process.
Here’s an example of the probability distribution of a cost estimate for a project.
The 50th percentile cost is $2,296,898. That means there is a 50/50 chance the project will cost more than that or less than that. That number is the median – the middle of the range. If we want to know what the number is with an 80% confidence than it is $2,333,153. That says there is an 80% confidence that the cost of the project will be $2.3M or less.
When we speak about the schedule, we can use the same terminology. In this case, there is an 80% confidence the project will complete on or before 11/06/2015.
These graphs are generated from a Monte Carlo simulation tool applied to a resource loaded Integrated Master Schedule (IMS). If there is any doubt as to why you MUST create a resource loaded schedule, please please put those doubts away. These two graphs are the source for the Joint Confidence Level showing the overall probability distributions for both cost and schedule for the project.
This picture should convince anyone that the « joint » probability of completing on or before the target date (I didn’t say what that was) and at or below that planned budget (didn’t say what that was either) needs to be modeled in a way that would be considered credible.
Outside of a small domain of trained and experienced risk analyst, this is rarely if ever done. Most IT projects have some made up budget and schedule. Their strategy is based almost entirely on HOPE with no underlying assessment of the statistical and probabilistic drivers of the cost and schedule, let alone the technical aspects coupled with risk.
And we wonder why IT projects come in late and over budget
Turns out of course large IT programs have the same problem – poor estimating, politically motivated estimating, naive estimating, etc. But they are required to produce data like this, so we know it is bogus sometimes early enough to fix it – sometimes not.
We only wish it were as simple as many would have us believe. But sadly it is one of those wicked problems that we simply have to manage in the presence of uncertainty.
But no credible decision can be made in the presence of uncertainty without making an estimate of the outcome of that decision.
Laisser un commentaire
Participez-vous à la discussion?N'hésitez pas à contribuer!