There is concern from many project managers that they are expected to present a detailed estimate of the project work when the charter and schedule are created. However, the detailed requirements have not been gathered yet. So how are you supposed to estimate the work without having captured the detailed requirements? It seems like a valid question. Yet, when you talk about gathering detailed requirements, you are usually talking about the Analysts Phase of a project lifecycle, not the up-front project management work of defining and planning the project.
Your first thought might be that perhaps you should have the detailed requirements before you commit to an estimate for the work. However, is that really practical? Let’s say you have a process improvement project. The project might last six months and the requirements gathering process might last six weeks (or more) of that overall timeframe. So, should you really hold off on the project estimates until the requirements are gathered and approved? If so, the project might be one-third complete before you are validating the overall project costs and deadline. If the project does not make sense from a cost-benefit perspective, you might have already spent a significant amount of money. This is much too late, and it is 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.
The following three approaches will allow you to estimate the work before you have gathered the detailed business requirements. (These assume that you are gathering requirements as the first step of project execution. This is also called a waterfall model. If you use agile or iterative techniques you can gather the requirements in an iterative manner throughout the project.)
Estimate the work to within 15% when you charter and schedule the project. This is the traditional approach, and in many/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 15% based on the high-level requirements that were gathered as a part of creating the project charter. 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 to provide an overall project estimate within 15%, then you can break the larger project into multiple smaller projects. When you use this technique, you usually end up chartering a project to do gather the requirements. You should be able to estimate this requirements gathering project to within 15%. 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 15%. When you are done, the final deliverables will have been created through two projects, each of which was estimated and managed to within 15% of budget and schedule.
Estimate the work at a higher level 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. This estimate may be within +-25%. However, based on the rules of the organization, this is not the estimate where the project manager is accountable (unlike the first option above). This estimate is just 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 15%. This is the number that the project manager is held accountable for.
Many project managers 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 15%. In fact, iterative approaches might make this level of accuracy even harder to estimate since you are only gathering a subset of requirements in each iteration. The three solutions above provide a more viable set of techniques for estimating the work to within 15% before you start.