Planning a project and keeping it on track can sometimes be a hard thing to do, due to the inherent uncertainty in real life. Anyone who has ever had a brush with the construction industry – from large projects like Crossrail, down to small projects like an extension on a house – will have seen how wildly off the original estimate can have been from reality, and how this can have a dramatic effect on time, cost, and quality. Uncertainty is a fact of life, but there are many tools and techniques to help us deal with it.
In the world of navigation an elegant solution has been created to solve the problem of uncertainty in predictions and measurements. If you are driving a car with a satnav running, there are many occasions where you may not get the good, constant, GPS signal reception that is needed to take navigation measurements – yet these days you often as a user will never realise that this has happened.
If the satnav relied exclusively on a good, constant, connection to the satellites to make an estimate of your position, you would find it very annoying to use whenever the signal was even slightly degraded. Your displayed position would jump around and freeze as signal came and went, as the only information being used for a position estimate is a snapshot observation with no consideration for current velocities or the laws of physics.
To provide a much more realistic model of your position, the software within a satnav is using a form of predictor-corrector algorithm to predict where you are. Without diving very deeply into the mathematics behind it (search online for ‘Kalman filter’ if you would like to) it can be broken into the two steps of its name – a prediction of where the satnav models that your vehicle should be at any given point, and then a correction from an observed measurement made by signals received from GPS satellites.
The prediction part of the algorithm applies the classical rules of physics to the vehicle, estimating where you could be based on your last observed position. It will make various assumptions, for example that you are likely to continue at the same speed and stick to a road if there is a bend in it, and not swerve off into a field. As time without an observed GPS measurements increases, the algorithm also begins to trust this prediction less and less, and it includes this level of uncertainty as a data point too.
The corrector part of the algorithm takes a snapshot observation of your actual position from a GPS signal. To measure your position by GPS, your satnav needs to be able to receive a signal from enough satellites to make a good measurement and iron out any errors or inaccuracies. No observation of reality is perfect, and so this part of the algorithm too includes a level of its uncertainty as a data point.
The algorithm then combines the two parts – its prediction of where it thinks you could be based on sensible logic but no observation, and a correction from an observation of where you probably actually are but without any prior consideration of where you could be. It weighs up the uncertainty data point in each part to decide which part to believe more to resolve any discrepancies, and then repeats the process.
So, can this same elegant solution to the uncertainty in navigation be used to solve the problems of uncertainty in project management?
Waterfall project management methodologies, favoured often in the construction industry, are focused at making a prediction of how long something will take from a start point. This will be based on what needs to be done in a logical order and following the laws of physics and reality. These laws include the obvious, such as you must build the walls of a house before you can put the roof on, and the less obvious, such as a bricklayer will probably lay about 600 bricks a day. In such a manner a project manager can make a prediction as to how long a project could take.
Agile project management methodologies, favoured often in the software industry, are focused at looking at the problems of here and now. This works well as often there is not as rigid a workflow in software development – there may be no roof which can only be built once the walls to be built – and so the most pressing issues can be considered over a short ‘sprint’, before then again looking at what the next big issues are.
For projects that are not as clear cut as simple construction or software bug resolution, neither method in isolation is perfect. Neat waterfall methodologies fall down in the same way our satnav’s predictor algorithm does – they are very sensible and logical, but their predictions become more uncertain as time goes by without a correction. Neat Agile methodologies also suffer from the same problems as a GPS correction – though it takes in a lot of input to give a good observation of the current situation, it does not focus on making a future prediction and so without a constant update it can give a very uncertain estimate of what is left to be done – and is also in danger of making jumps off the obvious road ahead.
Consequently, many project managers favour a hybrid approach which functions as a predictor-corrector. The predictor stage is to predict what is likely to happen by setting up a project using a waterfall method, and then the corrector is to use Agile to update and correct the plan as the project progresses. Waterfall gives us the products managers love – a Gantt chart showing dependencies, resource requirements, and some milestones to worry about – and then Agile sprints allow us to monitor the progress of each task, letting us know quickly if we wildly overestimated or underestimated the amount of work it would take. Conversely, waterfall also helps us keep Agile observations from ‘swerving off the road and into a field’ as we can see the task dependencies and help steer work away from constant refinement and towards bigger issues.
As a satnav uses various tools to predict and correct its model of where a car is to reduce uncertainty and help a driver complete their journey on time, so too a project manager uses various methodologies to predict and correct a model of where a project is to reduce uncertainty and help a team complete it on time, to cost, and to quality.