All project elements are actually random variables. Funding, productivity, quality, efficiency, cost, schedule, risk, reliability - all the illities actually. All the independent and dependent variables of any project. The project can be a construction project - pouring concrete and welding pipe. It can be a software project - developing a capability used by an internal IT customer, all the way to a game used by millions on their smart phones. Or a project flying to Mars with intensive technologies of hardware, software, and even inventing new physics.
Walts paper speaks to how statistical process control can improve the software development process. This process does not assume what development method you are using.
Since all the elements of the project interact in some way, many times in a non-linear way, most times stochastically (statistical dependencies), we need to not just acknowledge this but be able to manage in the presence of the uncertainties that result from these underlying stochastic processes. As well these processes may not be stationary, they may change as a function of time, as a function of other changes, or just randomly change - stuff happens.
So what does this mean in practice:
- No single point estimate can be credible without its variance being known.
- No estimates can be credible without the knowledge of how one estimate is coupled to other elements of the project.
- All forecasts of future behavior are probabilistic, driven by the underlying statistical processes of the mechanics of the project. These mechanics can be physical mechanics, the people, processes, and politics of the participants.
Since there are connections between all the elements, the first connection - the one most interesting to those paying for the project are the cost and technical risk connections. I know you may think the produced products are the most important - the production of working software for example. But that software appears from the project through the expenditure of time and money. And without knowing how much time and money is needed to produce that outcome - to some level of confidence - all the modern product development techniques are going to help. Why you say? 'Cause you've got no money.
In the end software intensive projects - enterprise class software intensive projects - are complex systems. Projects where all project participants are in the same room, with the shared vision of the outcome - not so complex. But that's not where the bulk of the IT spend lives. As well the notion - perhaps naive - that complex projects can be broken down into simple projects ignore the core principle of all complex systems. The coupling and cohesion of the system elements may not be known upfront and in fact may not be knowable until it is too late. If we look at the primary driver of project failure - the people problem - we can see that Coupling and Cohesion is the primary source of difficulties.
So In The End
To increase our probability of project success we must learn to manage in the presence of uncertainty. This uncertainty is created by either the lack of knowledge (Epistemic uncertainty) or the statistical uncertainty created by the naturally occurring variances in the processes (Aleatory uncertainty).
Both these uncertainties create risk to the project variables - cost, schedule, technical performance. These uncertainties directly participate in the estimating and forecasting processes designed to seek out possible future behaviour. Attempts to control the behaviour that results from the aleatory uncertainty is fruitless. Muda. A waste of time. The only way to protect against the aleatory uncertainties is with margin. Cost margine, schedule margin, technical margin.
The epistemic uncertainty can be addressed by spending money to buy knowledge. This is the definition of epistemic - Epistemology. We can spend money upfront to reduce the uncertainty - this is the basis of all iterative and incremental development systems, be they Scrum or DOD 5000.02. Or we can hold in reserve, money, time, capacity to address problems when they come true probabilistically.
Pay me know or pay me later.
So Now What?
To have any hope of success we must have some level of confidence that all the probabilistic processes, driven by their underlying statistical processes have some level of understanding. Blindly pulling work off a queue, without knowing the arrival rate to the queue, the throughput of the processes servicing the queue, the quality of the products produced by that servicing, and the acceptance rate of the resulting products by the consumer - naive at best and simply bad management at worst.
