Estimating Techniques for Schedule and Budget

2.2.1.2T Estimating Techniques for Schedule and Budget

Estimating Techniques (2.2.1.2T.P1)

There are five-day classes that focus on teaching people good estimating techniques. Some of these techniques are based on advanced statistics and scientific formulas that are way outside the scope of the TenStep process. Many of the basic estimating techniques are more familiar and easier to understand.

The following techniques can be used at the project level or activity level, or for any sized work in-between. For instance, an expert opinion can be used to help guide the estimate for an entire project or a specific piece of work. The high-level estimating techniques are typically referred to as top-down techniques. Top-down techniques include prior history, analogy and ratio. Overall estimates that rely on a more thorough breakdown of the work are called bottom-up. The WBS technique, for example, is a bottom-up technique.

Top-down estimates are typically quicker and easier to put together, since you are estimating at the overall project level. They are usually less precise as well, except for estimates based on previous history and analogy on similar projects. If possible, you should utilize multiple estimating techniques for a project, especially if you are using a quick top-down technique.

Previous History. This is by far the best way to estimate work. If your organization keeps track of actual effort hours from previous projects, you may have information that will help you estimate new work. In this method, the characteristics of the prior work, along with the actual effort hours, are saved in a spreadsheet, database or other medium that could be searched for new projects. A person that is estimating new work could describe the characteristics of his project to see if similar work was done in the past. If so, he could review prior results to get a good idea of the effort required to do the new work.
Analogy. Even if you do not keep actual effort hours from previous projects, you may still be able to leverage previous work. Analogy means that you find similar projects, even if the project team did not collect actual effort hours worked. The prior project manager should have at least had an original estimate of effort and duration. Although he did not track the actual effort hours, he should know the actual duration. If the actual duration hit the estimated duration, you may be able to assume that the effort hours were close as well. On the other hand, if the project ended with a 20% overage in duration, you may be able to estimate that the effort hours were 20% over as well.

For example, let’s say a prior project was estimated to take six months and 2000 hours to complete. If the project actually was completed in six months, there is a good likelihood that the project also took approximately 2000 hours of effort. On the other hand, if the project was fully staffed and took seven months to complete, you might estimate that the project took around 2300 hours to complete.

This is probably the most common technique for estimating work. You estimate future work based on your knowledge of having done similar work in the past.

Ratio. Ratio is similar to analogy except that you have some basis for comparing work that has similar characteristics, but on a larger or smaller scale. For instance, you may find that the effort required to complete a financial audit for the Miami office was 500 hours and that one of the big drivers for the effort is the number of people at the remote office. If there are twice as many people in the Chicago office, you may be able to conclude the work may take 1000 hours there.
Expert Opinion. In many cases you may need to go to an internal or external expert to get help estimating the work. For instance, if this is the first time you have used a new technology, you may need the help of an outside research firm to provide estimating information. Many times these estimates are based on what other companies in the industry are experiencing. You may also have an internal expert who can help. Although this may be your first time estimating a certain piece of work, perhaps someone else has done it many times.
Delphi. The Delphi technique is similar to expert opinion, except that you use multiple experts and try to reach an estimating consensus among them. First, you identify two or more (preferably three) people that are considered to be experts in the type of work you are estimating. Next, send them the relevant information they need to understand the work. They should send you back an estimate of the effort, along with any assumptions, risks, etc. they identify.

If the estimates are relatively close, you should feel very good about using an average of their input for your final estimate. However, you may find that the estimates are not close to each other, or that some of the estimates are close to each other but other estimates are not. If that happens, send all the estimates, including the assumptions and risks, back out to the experts for review. Ask the experts to consider the estimates, risks, assumptions, etc. of the other estimators. Then ask each of them to provide a second estimate of the work. Hopefully, you will find the various estimates closer now, since each expert has a chance to see the work of the other experts. Based on a common set of assumptions and risks, hopefully, the experts can reach a consensus estimate. If they cannot, you can see if most of the experts have a similar estimate and use that number. You may have to also note an estimating risk in the direction of the experts that were not close to the consensus. For instance, if three experts estimate work at around 1000 hours, but one expert holds to the belief that the work is 2000 hours, you may need to go with the 1000 hour consensus, with a stated risk that the numbers might be up to twice that amount, based on at least one expert opinion.

A second option if you have the time and inclination is to ask for more expert opinions. This would give you more confidence if the new expert estimates were close to your consensus number, and it would give you less confidence (and more risk) if the new estimates were not close to your consensus number.

The scenarios above are examples of what can happen when you ask multiple experts for their opinion. The Delphi technique utilizes multiple experts and then provides guidance on how to make sense of the estimates if the experts do not agree.

Work Breakdown Structure. The TenStep process for building a schedule in Step 2.1A discussed breaking work down into smaller and smaller pieces. One of the reasons for doing this is to be able to more easily estimate the work. You may look at a large piece of work and have difficulty estimating the effort required. However, as the work is broken into smaller pieces, the individual components will be easier to estimate. When you have estimated all the pieces, add them all together for the overall effort. If you have time to create a good WBS, you usually end up with a good estimate of the overall effort required. You should try to use a WBS technique on the project if possible.
PERT (Program Evaluation and Review Technique). The term PERT is often used to refer to a network diagram. However, it is really the formal name of an estimating technique that used a weighted average of three numbers to come up with a final estimate.

Using the PERT technique, if you are asked to estimate the effort required to complete a project or an activity, you would start with three estimates - the most pessimistic (P) case when everything goes wrong, the most optimistic (O) case when everything goes right, and the most likely (M) case given normal problems and opportunities. The resulting PERT estimate is (O + 4M + P)/6. For example, let’s say you estimate a piece of work to most likely take 10 hours. The best case (everything goes right) is 6 hours. The worst case (everything goes wrong) is 26 hours. The PERT estimate is (6 + 4(10) + 26)/6. The answer is 72/6, or 12 hours. Notice that the number was pulled a little toward the far extreme of the pessimistic estimate, but not by much, since the result is still weighted heavily toward the most likely value.

Parametric Modeling. In this technique, a pattern must exist in the work that allows you to use an algorithm to drive the overall estimate. For instance, if you know that you can build one mile of flat one-lane highway for one million dollars, you should be able to easily calculate an estimate for ten miles of flat four-lane highway (40 million dollars). Or, if you are asked to create 40 new reports, first estimate the effort for an 'average' report (perhaps the average of a small, medium and large report). Then multiply the average effort for a report by 40 for the final estimate.
Timeboxing. In this technique one or more aspects of the estimate are fixed ahead of time. This can usually be accomplished by focusing on one or both of the other aspects of the “triple constraint”. Usually when you apply the timebox technique you are forcing the project to be completed by a certain deadline. You then have to focus on the cost and scope aspects of the triple constraint so that the timebox date can be met.

For example, let’s say you create a schedule and it looks like you will complete the project in nine months. However, your sponsor tells you the project must be completed within seven months. The seven month deadline becomes the “timebox” within which the project must be completed. To hit this date you will have to apply resources faster than anticipated. You may also need more resources so that some activities that were scheduled to be completed sequentially can now be scheduled to be completed in parallel. These are examples of situations that will drive up the cost of the project. If you cannot spend enough money to make your deadline date, you may have to eliminate some of the work (scope). You could increase costs, decrease scope or perhaps have a combination of both to meet your dates.

Function Points (IT development projects). Some IT development organizations use function points as a means to provide meaningful estimates of the work required to complete a systems development project. Function points provide a mechanism to determine the relative complexity of an application. The complexity can be expressed as a count of function points. In this way, an application of 1000 function points is generally ten times larger and more complex than an application of 100 function points.

Without getting into a lot of detail, function points look at the size of an application from a user perspective. The users see reports, screens, and maybe data files. They also see business functionality, interfaces to other applications, databases, tables, etc. It makes sense that an application with 80 screens and 20 reports is probably larger than an application with 20 screens and 5 reports. This way of looking at size is independent of the underlying technology and development language. In fact, the application with the smaller number of screens might require more lines of code, but that is no longer relevant in the sizing calculations.

You cannot do function point estimates early in the planning process. However, once you know the number of screens, reports, interface files, transactions, etc., you can create a high-level estimate of total function points. Once you have been counting function points for a few projects, you will start to see the average effort required to complete one function point. After that, it is just a matter of applying the math to determine the total effort required, followed by the duration and the cost.

Estimate in Phases (2.2.1.2T.P2)

One of the most difficult aspects of estimating projects is that you do not know exactly what work will be needed in the distant future. It can be difficult to define and estimate work that will be done three months from now. It's harder to estimate six months in the future. Nine months is even harder. The reason is that decisions made and deliverables produced earlier in the project have an impact on what the work looks like further along. Therefore, there is more and more estimating uncertainty associated with work that is farther and farther out in the future.

The best approach for larger projects is to break the work into a series of smaller projects, each of which can be planned, estimated and managed separately with a much higher likelihood of success. (Similar rationale can be found in Step 2.1P Define the Work, in the section on breaking large projects into multiple projects and managing them as a program.) From an estimating perspective, the closest project can be estimated more precisely, with the subsequent projects estimated with a higher level of uncertainty. When one project completes, the next project can be estimated with a higher degree of confidence, with estimates refined for the remaining projects. This technique also provides checkpoints at the end of each project so that the entire initiative can be revalidated based on current estimates to ensure that it is still viable and worth continuing.

Estimate Time-Constrained and Resource-Constrained Activities (2.2.1.2T.P3)

Activities can be classified as time or resource-constrained based on whether the duration can change if more resources are applied. An activity is resource-constrained if the duration changes based on the number of resources applied. For instance, you might estimate that it will take 200 hours for one person to build a roof on top of a house. If the person worked forty hours per week, it would take five weeks to complete the job. If you applied two people to the job, the effort might still be 200 total effort hours, but the job would only take 2 1/2 weeks to complete. If there were five people assigned, the work could be done in one week (of course, the duration might not drop as cleanly as this example). An activity is resource-constrained if the duration is based on the amount of resources that can be applied to the activity.

On the other hand, if an activity is time-constrained, the duration remains the same regardless of the number of resources applied. For example, if you attend a one-day class, the activity will take eight hours of time. If you send two people to the class, the class does not get shorter; it still takes eight hours. Likewise, the time it takes for concrete to dry or to mail a letter is not impacted by the number of people involved. They just take a certain amount of time. If you find that applying resources has no impact on the project duration (or very little impact), then the activity is time-constrained.

Include Project Meetings and Collaboration Time in Your Estimate (2.2.1.2T.P4)

Departmental and company meetings are not typically within your control and are not accounted for on the schedule or in the estimate. If a department meeting is scheduled on an ad-hoc basis, you may have no choice but to attend and deal with the schedule delay. They may be accounted for in the estimated duration if you factor in a reduced number of available hours per day for each resource (say 6.5 hours per day). Of course, if these departmental meetings are scheduled monthly or quarterly, you can take them into account and build time into your schedule. The time may not count against your budget, but attending the meetings will impact your schedule.

On the other hand, meetings that are project-related should definitely be included in the schedule and should be added to the estimated effort and cost of the project. This is because meetings of this type are within the control of the project team. The project manager can schedule these for one hour every other week or they could be scheduled every day.

Likewise, try to account for the total time required for all participants in any collaborative project-related meetings. For instance, if you are planning deliverable walkthroughs, make sure you include the time of all participants. When you are circulating documents for approval, include some review time for each person that you think will be involved. If you are planning on having review meetings at the end of each milestone, make sure to include time for each participant.

Start Off With an Estimate Range (2.2.1.2T.P5)

There are many times when you are asked to give a high-level estimate for a project or an individual work activity. Usually you are asked to produce one number, for instance 1000 hours. However, if at all possible, these high-level estimates should be given in a range. The range reflects the level of uncertainty for the estimate. For instance, a high-level estimate might only be accurate to within 50%. In the prior example of 1000 hours, for instance, you could estimate the work to be between 500 and 1500 hours. Another way to say the same thing is that you estimate the work at 1000 hours, plus or minus 50%. If there is a lot of uncertainty on the estimate, your margin of error could be plus or minus 100% or more. However, the purpose of providing the range is to help manage expectations. If you say that you estimate a piece of work to be 1000 hours - that is probably the number you will be held to. Given the information you know, this could be a hard number to achieve. If you provide an estimate range, however, you will have a much better likelihood of delivering the work within the estimate and you have a way to show the level of uncertainty in the numbers.

The more accurate the estimate, the larger the estimating range.

Use Monte Carlo Modeling for Determining Scheduling Risks (2.2.1.2T.P6)

One of the ways to recognize uncertainty in your estimates is to add in a contingency factor. The contingency factor is increased to recognize a larger degree of uncertainty in your estimate. For most small and medium-sized projects adding a reasonable estimating contingency is perfectly fine and should give you a final estimate that you can reasonably expect to achieve.

For larger projects, however, there are more powerful techniques available for recognizing the estimating risk. The most common is the Monte Carlo model. Monte Carlo modeling starts off a little like the PERT estimating technique. Rather than give one estimate for the duration of an activity, you provide a series of estimates that represent the best case, most likely case and the worst case. For each of these cases, you also assign a probability.

For instance, there may be a 10% change of hitting your best case estimate, an 80% chance of hitting your most likely estimate, and a 10% chance of the work extending to hit the worst case scenario. In other words there is a 90% cumulative chance the activity will be completed by the most likely scenario (10% + 80%) and a 100% cumulative chance that the work will be done by the worst case estimate (10% + 80% + 10%). You don't need to determine the percent likelihood for points in between - just those three points. (Technically you can provide estimates for any and all probabilities.)

You then have to prepare these three estimates for each of the major work activities in your schedule. For example, you may estimate an activity to most likely take 60 hours, with a best case of 50 hours and a worst case of 90 hours. These three estimates might need to be prepared for dozens (or hundreds) of activities in the schedule.

When you are done, most schedule tools have a function to perform a Monte Carlo Simulation. Basically, the simulation models how the project will progress, and reaches an estimated end-date. The schedule is then mapped out again, this time using differing probabilities, and therefore calculating a different end-date. The reason the model is run many times is for the risk percentages have a chance to play out. For instance, in the example above, if the simulation was run 100 times, you would expect that each individual activity would be assigned the best case estimate 10 times (10%), the worst case estimate 10 times (10%) and the expected case estimate 80 times (80%). As the modeling tool randomly picks estimated values based on probabilities, many different project schedule scenarios play out. Some show the project completing earlier since many best case estimates are randomly chosen. Some schedules show the project completing later since many worst case are randomly chosen. However, after running the project model 100 times, a basic pattern starts to emerge that allows you to estimate the most likely date that your project will end. This is usually done by looking for the deadline date where the Monte Carlo Simulation shows the project will end 80% of the time. In other words the simulation shows the project ending on this date or earlier 80% of the time.

Although the example above used schedule risk, you can also use this technique for providing estimates for cost and effort as well. The good thing about the Monte Carlo Simulation is that if you provide activity estimates in ranges, most tools will perform all the statistical calculations automatically. You just have to make sure that you have provided valid and reasonable estimates for the activities. You can see that the extra work required in the estimating process makes this a model to be used for projects that are very large or those that contain a lot of risk. Small and medium-sized projects would probably not find value in this technique.

Beware These Common Estimating Errors (2.2.1.2T.P7)

The estimation process is an art and a science. However, once you learn good estimating processes and techniques, you will hopefully be able to move more toward the “science” side of estimating and rely less on the “art” side. You can get better and better at estimating, but by nature you can never be perfect. Here is a list of common estimating problems that should be avoided.

Not taking all the work into account. This is a common problem, especially with earlier, high-level estimates. You may just miss some major work that you did not understand to be a part of the project, such as documentation or training. Typically, however, you underestimate the size of deliverables that need to be completed, or you do not include all of the activities required to complete the deliverable.
Wishful thinking. Anyone that has provided estimates of work knows that there can be pressure from your client to make the estimate as low as possible. Ultimately, the client wants to get what he needs for as little effort (and cost) as possible. In many cases, there is a tendency on the part of the estimator to get caught up in that mindset as well. The estimator ends up “wishing” the work gets completed within the client expectations.
Committing to best-case scenario. The client wants it done as quickly as possible. Your manager wants it done as quickly as possible. You think it can be done quickly. However, you get into trouble because you think about what it would take to complete the work if everything went right. You might even think in terms of a range of effort for the work, but then too often you end up committing to an estimate at the lower, or optimistic, end of the range.
Assuming higher quality work than can deliver. This problem includes estimating based on building at a certain level of quality the first time. However, as the project is executed, you realize that your ability to build to a high level of quality is limited, resulting in overages for rework, bug fixes, retesting, etc.
Committing based on available budget. In this case, the client has a fixed amount for the budget. The project manager thinks there is a chance he can get it done within available budget, so he commits based on that number. This is similar to the best-case scenario problem above.
Not recognizing estimating biases. Estimating biases sneak into estimates all of the time. Some are optimistic biases and some are pessimistic biases. Optimistic biases will result in underestimating the work and can include:
- Tending to think the work is simple
- Tending to think your team can accomplish more than they really can
- Not taking into account project risks, issues, miscommunications, etc.
- Tending to be optimistic in the first place

Pessimistic biases will result in overestimating the work and can include:

Having a bad experience on a similar project in the past

Not really wanting to do the work. You estimate high and hope the project will be cancelled

Tending to be pessimistic to begin with

Your biases are always there. The key is to recognize and counter the biases where you see them. This will help you prepare estimates that are as valid as possible.

Validate an Old Estimate When a New Team is in Place (2.2.1.2T.P8)

Usually a project team is formed to define the project, build the schedule and budget, and then execute the project. However, sometimes the effort and duration of a project are estimated very early, perhaps because the information is needed as part of the yearly budget cycle. In these cases, a project team may be put together later and asked to deliver the work based on the high-level estimate that was done earlier.

If that happens, one of the first jobs of the new project team is to validate the estimates. You do not want to be in a position of having to deliver against someone else's estimates. If you do not validate or challenge the estimates early, the expectation gets set that you think they are accurate. The project manager should challenge the estimates early. If you agree with the estimates, then you proceed to deliver against that estimated effort, budget and deadline. If you do not agree with the estimates, now is the time to raise the red flag. This is better for the company as well. You may find out, for instance, that if your estimate is higher, the project cost / benefit no longer makes sense. Again, it is better to find that out earlier rather than later.

Decide Whether You Should Include Client Cost and Effort (2.2.1.2T.P9)

All projects have clients that are receiving the benefits of a project. Often these clients work for a different organization or different company than the project team. Project managers need to decide whether to include the time that a client will need to be involved in the project.

Client effort includes the time to review and approve deliverables, provide requirements, attend meetings, participate in training, etc. Some companies want to understand the total effort and cost of a project, including both the direct project team and the client resource requirements. In other companies, the project costs only include the direct project team. Whether you include client hours and cost in your estimate is an area you should discuss with your manager and your sponsor. If your project estimate includes client hours and cost, the hours need to be kept separately. Although the combined number provides a better overall estimate, the project manager normally is not responsible for the client resources and so he should not be held accountable for achieving those particular targets.

Be Prepared if Others Think Your Estimate is Too High (2.2.1.2T.P10)

After you have prepared your estimate, you may need to defend it if the client thinks that the numbers are too high. You should be able to first defend the estimate by explaining the estimating techniques you used, the process you followed and the assumptions you made. If the client still thinks the numbers are too high, or cannot afford the solution at that cost, there are a few options.

Determine if the client has any additional information that would allow you to revise your assumptions and perhaps revise the estimate. For instance, if a critical end-date now has some flexibility, perhaps the estimate can be revised based on this new information.
Determine whether high-level requirements and functionality can be scaled back. In many cases, the original set of features and functions is more of a wish list. After seeing a price tag, it is very possible that the client can live without certain features.
If you included a high contingency to reflect a high estimating risk, ask the client for more time to gather more detail for the estimate. This may result in there being less uncertainty and risk, and allow you to reflect this as a smaller contingency.
Restructure the project to only include the detailed requirements-gathering phase. After the full analysis of the requirements is completed, re-estimate the remainder of the project, based on a confirmation of exactly what is being requested. The total effort and cost may or may not be lower, but at least you will have more detailed information to back up your estimate.

Back up Your Estimates with a Full Estimating Packet (2.2.1.2T.P11)

The next time you are asked to provide an estimate for a major piece of work, consider presenting a packet of information. This does not have to be a thick document; it is only meant to show the rigor that you went through. You should especially consider this if the work is political or if you think that your estimate will not be accepted. Rather than just providing a final estimate, or an estimate range, provide the following information instead.

Your understanding of the work that was requested
The process you used to prepare the estimate
The estimating technique(s) you used
The actual estimate of the work effort (and duration and cost, if applicable)
The detailed estimating information in case the sponsor would like to review. For instance, if you did a Work Breakdown Structure, you can include your detailed work estimates
The assumptions you made in developing the estimate
The level of uncertainty in the numbers that is reflected in the contingency or the size of the estimating range (more uncertainty is reflected in a wider range)

This would be a powerful packet of information to return to the requestor. If there were disagreements with your estimate, this would give you the facts to respond. It will also stop many challenges because people will have difficulty disputing your facts. You may get asked to change your estimating assumptions or to try another estimating technique. These are legitimate requests and you can re-estimate based on new criteria. But at least the challenges are in terms of the estimating process, not on whether you did a poor job on the estimate itself.

Estimate Based on Understanding the Levels of Accuracy Required (2.2.1.2T.P12)

There are different levels of estimating accuracy that are normally expected from the project manager depending on when the estimate is requested. When the project is first being proposed, for instance, your client may ask you for a high-level estimate of effort, cost and duration. The project is vague at this point and so the resulting estimate is going to be vague as well. In many cases, the estimate is only used for sizing purposes so that the originator has an understanding of whether the work will take 1000 hours or 100,000 hours. This estimate is a Rough Order of Magnitude (ROM) estimate and might be in the range of -25% to +75%. In other words, if the preliminary estimate of work was 1000 hours, you could propose the ROM estimate as 750-1750 hours. In fact, at this point, you might even be 100% off, or higher.

As the project gets further into the approval process, the estimator becomes more knowledgeable of the expectations and deliverables, which allows the estimates to become more precise as well. When a project is being proposed for funding, you should be able to estimate the project with more precision, perhaps -15% to +25%. In other words, if your estimate was for 1000 hours, you may propose a range of 850 – 1250 hours.

When the project work actually starts, the project manager and team should revalidate the estimate after formally defining the work and building the schedule and budget. The resulting estimate should now be closer to -5% to +10%. In other words, if your final estimate for effort is 1000 hours, you should feel that you can actually deliver the project in between 950 to 1100 hours.

ESTIMATE	ACCURACY	PURPOSE
ORDER OF MAGNITUDE (CONCEPTUAL)	-50% - +100%	Evaluation of projects or alternatives
PRELIMINARY (BUDGET)	- 15% - +25%	Establish initial budget, reserve funds for project
DEFINITIVE	- 10% - +15%	Establish actual project budget, after Project Charter

Estimate the Project Work Before Gathering Detailed Requirements (2.2.1.2T.P13)

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 to eight 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 a s 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 that the project manager is accountable for (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.