What are some of the main causes behind estimating errors?
There are several causes behind estimating errors. Some of them are:
1) Not enough information or data collected to create an accurate estimate.
Executives, clients, and managers want to see progress quickly. Gathering the data and information to create an accurate estimate, budget and schedule is a time-consuming effort with little visible, tangible result. People want to move into the “action” portion quickly – because that’s where you can “see” and report progress. Therefore, people are in a rush to create project schedules, because they believe they can not start the project without estimates and schedules.
At the end of the day — since they don’t have enough information to say that the schedule is “unreasonable” — they agree to it.
2) Domino affect on trying to make the schedule “look good” versus “accurate”.
Often times, because we don’t really have the proper data to give an accurate estimate. We are rushed to provide numbers that we aren’t really invested in. If this is a leading-edge technology or next generation service, we also do not have any previous experience to base our estimates on.
We think it may take us 8 weeks to do something but we are not sure. It could easily take us 6 weeks – we just don’t know. We don’t really have the data to believe in either number. Therefore, give the number that we “think” our manager will like better. For instance, if your original estimate is 8 weeks on a software coding project, might say — but if I work a few extra hours on it, over the weekend and everything goes smoothly — I think I can do it in 6 weeks. The developer may report to his/her manager that he/she “could” get it done in 6 weeks (but they don’t have any real data to support it). Their manager may then think — well if we work extra hours and weekends, then we can probably get it done in 5 weeks. Or the manager may feel that the developer is padding the estimates (because they can not provide any real data to support the estimate). So the manager reports a number that looks better to their manager.
3) Ignoring the inevitable speed bumps or the unexpected.
Often times, managers and developers create estimates on how long they think it will take “them” to develop or create. They don’t incorporate issues like: vacation, sick days, equipment failure, construction delays, contract delays, legal/license issues, resource issues, maintenance emergency on another line or product, client issues, or other “unexpected” issues that arises in the natural flow of a project. Because of these unexpected things, the person actually assigned to that “item” may not have the same experience as the person that created the original estimate.
Although you can not know exactly what will happen, you do know something will happen. Therefore, you really do need to expect the unexpected. And your project planning needs a way to handle these things.
And what specific steps can project managers can take to increase the accuracy of estimations?
1) Adopt the idea of “progressive refinement”.
Project Management isn’t about defining an accurate estimate or schedule at the start of a project. Project Management is about “managing” the natural flow of a project. One way is to adopt the attitude of “progressive refinement”. Define a rough skeleton of your project plan with the data that you current have. You then separate your projects in manageable iterations or segments. Each segment is a “mini-project”. Each “mini-project” has a variety of deliverable components to your clients, stakeholders and team mates. You focus on collecting the proper estimates and budget for the items scheduled for Iteration 1 (or segment 1). Iteration 1 (or segment 1) of your project will have clear deliverables and time tables for those goals, but Iteration 2, 3, and 4 may still have some fuzzy estimates because you haven’t collected enough data to accurately estimate those segments yet. As your team is working and delivering on their Iteration 1 items, you are collected the required data for your Iteration 2 items. If some features originally scheduled for Iteration 1 (segment 1) are falling short in quality or completion, they are quickly reassigned for Iteration 2 delivery (and iteration 2 feature lists are scoped appropriately).
This allows you to create accurate estimates as you progress through the project. This also allows you to deliver portions of the project throughout the development life cycle (at each segment). Clients, executives, and other stakeholders will be receiving tangible evidence of your work throughout the project lifecycle. You will also be receiving feedback on each segment to incorporate into the next iteration or segment.
2) Agree to a Protocol Recovery plan at the start of a project
All projects will hit some unexpected issues. By discussing a “protocol recovery plan” at the start of the project, the team will understand how to proceed when time is running out. A “protocol recovery plan” is like a “fire escape route”. At the start of the project, your project sponsors and stakeholder agree in the order to do these things: Add Resources, Remove Features, Change Schedule, Reduce Quality. The idea is to agree up-front (before the project starts) which order you will do them – if/when you hit a snag. For example: If you team agrees up front that the recovery protocol will be in the below order:
- Add Resources
- Remove Features
- Lower Quality Standard
- Change Schedule
Then the group understands from the start that the SCHEDULE is the main priority and last to be modified. They also understand the order in which the other items will be attacked. If your group agrees upfront that “QUALITY Standards will be the last to change — then folks understand that the schedule will change to support the agreed quality compliance. Whatever the team decides, it’s known upfront, before the project starts.
For instance, the team can agree to Add Resources (until it doesn’t make sense to add resources anymore). Once you have reached the point where more resources will not help, you agree that the next step will be to start removing features. At the start of the project, you need to understand the minimum set of features or services that make the project worthwhile to the client (with many other “nice-to-have” features or enhancements as well). If you understand the minimum MUST HAVE feature set, you can then start removing or rescheduling the “nice-to-have” items to the next release. Once you have removed all the “nice-to-have” items and are only left with the MUST HAVE, then you look back at your protocol recovery chart to find out what you to do next.
If you have this outlined and approved at the start of the program, then you don’t have people complaining that you’re sacrificing QUALITY in order the make the date. Or that you are cutting his/her features, etc. This is all understood before the project starts.
3) Release early and often
Adopt an attitude of continuous releases. Features or services that do not make it in this release are merely scheduled for the next one. There’s always the next train. Focus on getting early versions out for customer’s feedback and continually improve as you go along. Not everyone needs the product at the same feature set or quality. Allow people to use the product to get to their “next steps” accomplished. Often times the product doesn’t have to be perfect or complete — for the client to make use of it. Focus on the features and quality level that is actually required for the client to get “their job” done. The client’s focus isn’t really a “perfect product from you” or a product that “you” feel has “all the bells and whistles” or is the best on the market. The client’s focus is how to get “their job done” quickly and easily.
Conclusion:
Statistics show that only 36% of products feature are ever really used by the end-clients. Using that logic, only 36% of your feature set really need to be working effectively. So, as long as you are helping the client “get their work done” — you’re doing the right thing. Understanding what your clients need and how they work, will allow you to focus on just the features and quality level that will be of value to them. Providing a method to get them exactly what they need in a timely fashion will prove advantageous to you.
