Gathering detailed requirements is the first part of the project lifecycle
Project managers are expected to present a detailed estimate of project work when the charter and schedule are created. However, since the detailed requirements have not been gathered yet, how are you supposed to estimate the work?
It seems like a valid question. Yet when we talk about gathering detailed requirements, we’re usually talking about the Analysts Phase of a project lifecycle, not the up-front project management work of defining and planning the project.
However, it’s not really practical to hold off committing to an estimate for the work until you have the detailed requirements. Here’s why: Let’s say you have a typical IT development project. The project might last six months and the requirements gathering process might last six to eight weeks (or more) of that overall timeframe. If you hold off on the project estimates until the requirements are gathered and approved, the project might be one-third complete before you’re validating the overall project costs and deadline. If the project doesn’t make sense from a cost-benefit perspective, you might have already spent a significant amount of money. In my opinion, this is much too late, and it’s the reason most project management methodologies don’t include the gathering of detailed business requirements
Also if you use this same argument, you might say that you still are not confident to estimate the work without first doing the design, and then you are not confident to estimate the work until you have the construction work done, etc. You see that this same logic can be taken to an extreme.
To me, the following options make the most sense. (I am very aware of agile and iterative techniques where you gather the requirements in an iterative manner. But let’s assume for now that you are doing traditional waterfall project model where you are gathering the requirements up-front.)
- Estimate the work to within 10 percent when you charter and schedule the project. To me, this is the traditional approach, and I believe in most cases it is still viable. However, there is an underlying assumption that the project manager and/or the project team have done this kind of work before and are therefore able to estimate the work within 10 percent based on the high-level requirements that were gathered a s a part of creating the project charter. The caveat to this approach is that if you discover that you have estimated incorrectly after the requirements are gathered, you have to raise a flag at that time and ask for more money. Of course this same check needs to be done at the end of every project phase regardless of the techniques used.
- Break the work down into smaller pieces. If you don’t feel comfortable providing an overall project estimate within 10 percent, then you can break the larger project into multiple smaller projects. When you use this technique, you usually end up chartering a project for gathering the requirements. You should be able to estimate this requirements gathering project to within 10 percent. After this requirements project is complete, you can use the information to charter a second project to perform the rest of the work. Hopefully now you are able to estimate the remainder of the work to within 10 percent. When you’re done, the final deliverables will have been created through two projects, each of which was estimated and managed to within 10 percent of budget and schedule.
- “Guestimate” the schedule and budget first and then firm up after the requirements are gathered. This is a variation on the first technique above. In this approach, the project manager provides a “best guess” estimate of the work at the same time the charter and schedule are created. However, based on the rules of the organization, this is not the estimate for which the project manager is accountable (unlike the first option above). This estimate is just the best guess given the information at the time. After the requirements are completed, the project manager provides a more detailed estimate of the work within 10 percent. This is the number that the project manager is held accountable for.
As I mentioned earlier, many of you may think that the best approach is to gather the requirement iteratively. However, the iterative lifecycle does not provide the answer in terms of how you estimate the project to within 10 percent. In fact, iterative approaches might make this level of accuracy even harder to estimate, while Agile techniques usually refer to address the estimating at all–preferring instead to deliver working code in iterative sprints until the customer is satisfied with the end result or runs out of money.
The three solutions above provide a more viable set of techniques for estimating the work to within 10 percent before you start. Do you have other ideas that are effective in your organization?