Realistic Software Project Estimation

Why can’t we make project estimates stick? Or, maybe a better question to ask is, “Can we ever make project estimates stick?” Since software project estimation is inherently a predictive activity, estimation will always be fraught with inaccuracies. Accepting this assumption is the first step towards producing estimates that have a greater probability of sticking, otherwise you'll have to respond to negative risks extra carefully. But then, don't you already do that! Another problem with inaccurate estimates is that the critical path identified might not actually be the critical path, which in turn, can't be consoled by impeccable risk management.

In traditional software project estimation, the ScrumMaster, Project Manager, or the Architect are responsible for producing estimates. Project activities are then allocated and project team members start working on the tasks or stories. As the developers start the work, they realize the initial software project estimate was wrong. If the push-back culture doesn’t exist in the organization, developers will deliver something, regardless of the quality, usually by burning the midnight oil. Everybody is happy on meeting the deadline…until the client sends a stinker! The team members that worked on the task will be taken to the cleaners, and so will the Project Manager.

click to enlarge

The problem with this scenario is that no one asked the people who are in-charge of doing the task for their estimates. If they did, then maybe the extended hours would have been avoided. Maybe, the client would have got her money's worth.

Another reason for project software estimation goes wrong is that resources are fixed, but a deadline is set. The Triangle of Constraints states that in a project there are three constraints, Scope, Time, and Cost, if one of the constraints changes, then so will the others. In this case, if the deadline is set, time is fixed. Therefore, either Scope has to be reduced or the cost needs to go up or maybe both scope and cost will change.

Mentioned below are techniques that’ll help your estimates stick:

• People who do the work, should participate in the project estimation: This is especially true when you estimate at the task level. In Agile projects, everyone must participate. This ensures greater ownership. It is required for the Agile team's DNA.
• Bring in the experts: Expert judgment is critical to project success. Therefore, if required, hire consultants. However, take care not to follow their estimates blindly. Leverage the team.
• Estimate large pieces as a range: Your project estimate for cooking rice will be more accurate than the project estimate for cooking a meal for 10 people. This is because the latter is more complex and comprised of several tasks. Estimates get more accurate when the task is small. For activities that have several tasks, you should use a range. For example, cooking a meal for 10 will take between 8 to 12 hours. This best practice is especially useful early on in the project when you need to create a high-level plan.
• Use the Delphi Technique: This is a method that helps converge opinions of the team should there be a conflict in software project estimation.

For more on project cost estimation, read Project Cost Estimation Techniques.