It seems like everyone has a different view of the role that contingency should play on projects. While some recommend removing it so as to not inflate the cost of features, others feel it is a critical element in the estimation of the project. Some people feel it is best to hide it away in the features themselves, while others like it explicitly separated for clear communication.
One thing is clear to me after many projects that have gone well and poorly. Contingency is required. Contingency is required to portray a realistic image of how the project will go. While many people try to remove Contingency to not inflate the cost of a project, it actually reflects reality.
Contingency is the cost factor of likely issues that the project will hit based upon the experience of the team and company executing the project. To remove contingency would be ignoring the past.
Even the noble attempt to remove contingency and work solely with feature velocity so that the team and the client can jointly work on the prioritization of features is misplaced. Removing that contingency will change the decisions made by the business early on. Without the contingency , the client may feel that they will get more done and will add more scope. Then once issues start being encountered, it becomes very apparent that the client won’t get everything they need because they added items early on based on the perceived velocity and lack of need of contingency.
For example, Let us say we have 100 features that we need to accomplish and based on the first month we determine we appear to have a velocity of 20 features a month. The project is required to go live in 6 months. This appears to be a solid 5 month project. Early on in the project we encounter 12 features that the client would also like to have. So we add them since we have an extra month. What we find a couple of months in is our velocity is really 16 not 20. (as we encounter some more difficult features) Now we determine we will only be able to complete 96 out of the 112 features we have. Although we are working in priority sequence, there probably are some features that the client can’t go live without.
We have a pickle. All because we didn’t use contingency to reserve budget and schedule based on realities.
To me No Estimates sometimes feels like doing Physics problems without friction. While the equations hold and produce logical results, they don’t reflect reality. And once you add friction to the equations, the change in the results can be quite dramatic. If No Estimates work for you, then you are probably more in the product rather than project space and I’m envious. 🙂
But for the most part most of us need to deal with friction.
While No Estimates is intriguing, the removal of the analysis and incorporation of contingency is dangerous and can be deadly. While past velocity is an important factor, future planning and learning from the past is equally important. To manage mathematically based on past history is overlooking one very key factor – prior projects and experience. As we know most of the issues happen later on the projects. Contingency isn’t linear. Planning with only velocity requires contingency to be linear. In reality, we adapt to early velocity and make scope decisions based on that. They when issues hit that require contingency, it is no longer there as we have made decisions based upon what we think we can do based on past velocity.
Contingency isn’t evil or bad. It doesn’t inflate the cost of a project. If anything, it is the one thing that takes a paper plan and makes it real. Leave it out at your own peril.