You are of course familiar with the project triangle, where SCOPE, TIME and COST represent a side each (feel free to substitute these with parameters GOOD, FAST, CHEAP or SCOPE, SCHEDULE, COST. Good, Fast and Cheap are usally used as an educational tool to describe that you cannot have all three. Select any two and forget about the third).
Anyway, all three parameters involved in the project triangle are uncertainties to be delivered in a very change-prone place called the future. So we are asked to bring out the old crystal ball and look into this future. And if this advanced guess-work turns out to be less than accurate, we call our project a failure. Let me rephrase that for the sake of clarity: the failure lies in us not guessing well enough. Isn’t that weird? Sure, there are techniques for estimating, often based on past performance, such as measuring team velocity or average cycle time, but even so that’s past performance (history) and we are headed into the unknown (the future). I have previously made my feelings about this clear.
It is important to recognize that all three parameters in the project triangle are burdened with uncertainty, and we need a release valve somewhere. Think of your project triangle and imagine it to be a steam engine. All that uncertainty boiling inside. If you don’t let out steam it’s gonna blow. This is where Agile comes in, and in the following example more specifically Scrum.
In a Scrum project we open up the scope side of the triangle to let out some steam. We let the customer adapt to the reality of our progress and cut features if we see that we cannot possibly finish the whole thing on time. In typical Scrum you cannot touch the TIME-side of the triangle. The one holy idea is to deliver value at a certain set point in time, and the negotiable parameter is scope, i.e “what value do we deliver”. That’s the M.O of typical Scrum. But it is of course also quite possible to attack other sides of the triangle. This means COST (spend more money) or TIME (spend more time).
Which side of the triangle to attack is determined by your circumstances, but at least one of the sides must be allowed to slide somewhat to adjust your plan to reality. This is because we need to make crucial decisions when we have more information, rather than when we have no information. This again, is Just-In-Time-thinking.
Furthermore, information theory states that the value of information created by failure is very, very high. We also know that changes in projects are more expensive the longer a project runs, which causes a lot of people to think that we need to get it right from the get go. The opposite is true, we need not get it right from the start, rather, we need to fail early. This is why iterations are used in processes that involve great uncertainty. Working in iterations is basically a way of saying “let’s try stuff out and see what happens”. Whatever happens (success or failure) we have generated information that we did not have when we started. And if we succeed we have learned a lot less than we would have learned if we would have failed. You see, as Nassim Nicholas Taleb among others has pointed out, humans have a tendency to attribute success to skill (when it could just as well be luck), and failure to external factors such as bad luck (when it could just as well be incompetence). We need to stop doing that. Right now.
Basically project management in 2010 is more about rolling with the punches than sticking to a plan. Change readiness in all parts of your project and process is more important than accurate estimating. And we serve our purpose better focusing our effort on activities that produce information early, than fooling ourselves that we can accurately look into the future. The challenge now is to communicate this to our stakeholders.