Based on my experience working for different organizations, multiple software solutions and many customers across a variety of industry verticals, I have found that more projects are doomed due to poor estimates and unreasonable schedules than succumb to technical, political or development team issues. Inaccurate estimates can result in long hours, poor quality and missed customer expectations—failure.

Estimating software projects is not art. It is not science. It is a combination of both. It is possible to consistently provide reasonably accurate estimates for software development costs and schedules. Of course, that accuracy depends on the completeness of the requirements, the project phase at which estimation is done, the quality of the method or methods being used, and the experience of the team putting the estimate together.

As many may already know, the earlier in the project or relationship with the stakeholders, the less accurate the estimate. In studies such as “Reasons for Software Effort Estimation Error: Impact of Respondent Role, Information Collection Approach, and Data Analysis Method” it was found through a review of surveys on software estimation, that the average effort overrun of software projects seems to be in the range 30% to 40%. I would add from my own experience that this percentage varies when looking at which phase of the project the estimating occurs. I suggest that estimates can be off by 50% in the earliest phase of a project or relationship, decreasing to 25% at planning and finally to as low as 10% during the execution or supporting phases. These numbers are modified, regardless of project, when the estimating team’s experience with the software and knowledge of its functional use within the organization increases. The “Cone of Uncertainty” is one way of illustrating this improved ability to estimate as time goes on.

If you get a group of project managers and software developers into a room together and ask each how each would estimate a specific project, you will probably get as many answers as there are people in the room. However, they could all most likely be categorized into one of the following methods:

1. Experience – Typically a project team approach using their experience with an understanding of the project requirements to come to a consensus. Very useful in the absence of empirical data, however it is hard to document the factors used to derive the numbers and the results are often biased.
2. Project Comparison – Derived by comparing the proposed project to previous projects. This method uses actual historical data and the estimators experience to identify and quantify differences. This is very similar to how a real estate appraiser values a property for a mortgage using comparables and adjusting factors to come to the value. However, the challenge with this method is determining the value of the differences and their impact on the estimate.
3. Top-Down – High level requirements are used to identify the main components of the project. This approach focuses on the system level activities including customizations, configuration, integration, training, testing and documentation. Many of the other estimating methods miss the cost of these activities. This method requires minimal project detail and is usually faster to complete, but often overlooks low-level problems that may escalate costs. In addition, this method does not provide a detailed basis for justifying the estimate.
4. Bottom-Up – A more traditional approach, this method requires detailed and historic knowledge and is often expected if the estimator has been working with the project stakeholders for a period of time. It may also be expected if a detailed discovery was performed prior to the estimate exercise. Use Case Points (functionality seen by the user) or Function Points (how the user interacts with the system) are often the basis for this type of estimating. Points are identified then categorized. By creating the estimate to this level of detail, errors in estimating have a chance to balance out within the project. However, this method often overlooks the system level effort. Accuracy of this method decreases the earlier in the project it is performed.

In summary, all of these methods have strengths and weaknesses, and can be complimentary to each other. A combination of two or more should be used to get the most accurate estimate and project plan. In the end, the best estimating process should:

1. Not depend on a single method;
2. Compare and contrast differing results determining the reason for differences;
3. Document assumptions;
4. Be monitored throughout the project for accuracy and false assumptions;
5. Provide historical data to be used for project updates and to increase the accuracy of future estimates.

What is the best way to present the estimate information to the project stakeholder? As in the actual estimating process itself, there is no “one size fits all.”

Managers tend to view estimates as final numbers. To counter this and as a protective measure, the tendency is to present the estimates in summary and/or as a range. Early in the process or where limited knowledge of the software, and/or the project requirements are known, this may be acceptable. However, in later stages of the project or the later stages of the relationship with the organization and project stakeholders, this method may seem inadequate. Lack of documentation may start debates or discussions that would otherwise be avoided if more detail or a more concise estimate existed.

Even early estimates with their higher percentage of inaccuracy are more understandable when the process behind the numbers is exposed in greater detail including assumptions and out-of-scope. When the estimate is reviewed and discussed with the project stakeholders, they may provide more or different information allowing the estimate to be corrected and additional work or requirements identified. The added documentation and transparency makes the estimates more trustworthy. This can be very valuable in the early stages of a project for not only the obvious reasons, but also because stakeholders become more involved in the process reducing the “us and them” mentality and fostering a more complete team approach between the development team and the project stakeholders.

No matter the approach taken, it is important that the estimate include all the information needed for the stakeholders to make an informed decision. This includes an Executive Summary, Project Objectives, Success Criteria, Key Deliverables, Scope, Change Management, Risks, Quality Statement, Project Management, Roles and Responsibilities, Other Considerations, Project Timeline and of course the Project Estimate with supporting documentation.

In conclusion, estimating is a mix of art and science. No two people will estimate in the same way. Good project managers know how to estimate using experience, common sense, various methods, best practices and a team effort to come up with a project plan the stakeholders will understand, embrace and recognize as just that – an estimate.

Reference“Reasons for Software Effort Estimation Error: Impact of Respondent Role, Information Collection Approach, and Data Analysis Method”, Magne Jørgensen and Kjetil Moløkken-Østvold IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 30, NO. 12, DECEMBER 2004.

Other resources include personal experience and the following:“Software Estimation – A guide for PRACTITIONERS” (11/7/13) Compiled by Santosh Ramachandran published through LinkedIn and SlideShare http://www.slideshare.net/santoshr25/guide-to-software-estimation“Software Estimation using a Combination of Techniques” by Klaus Neilson, MBA, PNI-ACP, PMI-RMP, PMP – PMI Virtual Library | www.PMI.org | © 2013 Klaus Nielsen https://www.pmi.org/~/media/PDF/Knowledge-Shelf/Nielsen_2013.ashx