Lokalisering af side

Customer Success

How can Microsoft Project 2010 make your business succeed? Learn how Microsoft Project 2010 has helped businesses streamline their projects, save overall operating expenses, increase productivity, and improve collaboration and communication.

Risk-Tolerance Based Schedule and Cost Estimates

By Amro Elakkad, PMP

Project risks are a fact of life that every project manager must deal with. “Project risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on at least one project objective, such as time, cost, scope or quality," as defined by the Project Management Institute’s A Guide to the Project Management Body of Knowledge – Third Edition. Managing project risk involves analyzing and prioritizing risks so that the project manager and the team can focus their mitigation effort on the top risks

Many project managers are familiar with analyzing risks on a project level. This works well for scope and quality risks; however, it is the task-related risks that can negatively affect the accuracy of the schedule and cost estimates and thus negatively affect the delivery of the tasks – and, ultimately, the success of the project.

For small and medium-sized projects, qualitative risk analysis is an effective method to help a project manager evaluate task-related risks and thus improve the realism of the overall project’s schedule and cost estimates. For larger size projects, qualitative risk analysis followed by quantitative risk analysis is more appropriate. This approach uses simulation models, which, though time-consuming, is justifiable given the project size.

To improve a project’s exposure to schedule (time) and cost risks, we need to focus on risks at the task level. When project managers estimate the time and cost for a task, some assume a best-case scenario, while others assume a worse-case scenario. Both approaches can be problematic. The former often results in less time or cost being estimated for a task than will actually occur, while the latter may result in more time or cost being estimated because assets are assigned to the project for longer periods than are actually necessary.

Qualitative risk analysis can help make project estimates as realistic as possible, if it is applied by using a consistent methodology. Here is a methodology that you might consider to develop and apply realistic estimates:

  1. After you have determined the project schedule and cost, conduct risk identification and analysis meetings with your key stakeholders. In these meetings, for each task in your schedule, list the risks associated with the task, a probability (P) score to indicate the likelihood that each risk will occur, and an impact (I) score to indicate the effect of each risk if it occurs. It is important to list only the risks that will affect the task’s schedule or cost—remember, they are our focus. Also, remember that risks that impact scope or quality are generally handled at a project risk-analysis level (as opposed to a task level).

  2. For assigning a probability (P) score, the following scale works well. The advantage of using this scale is that you have ranges to pick from. Some literature proposes using probabilities as a percentage, but there is no particular value in using percentages from a qualitative analysis perspective.







    Very Unlikely (VU)

    Unlikely (U)

    Likely (L)

    Very Likely (VL)

    Most Certainly (MC)

  3. The impact (I) score of any given risk will be different for time than it is for costs. Here is a proposed impact scale.


    Very High (VH)

    Very High (VH) Schedule—major milestone or critical path impact >10%
    Cost—total program cost growth >5%

    High (H)

    Schedule—major milestone or critical path impact <5%
    Cost—total program cost growth <5%

    Medium (M)

    Schedule—non-critical path impact >10%
    Cost—exceeding element cost >10%

    Low (L)

    Schedule—non-critical path impact <10%
    Cost—exceeding element cost <10%

    Very Low (VL)

    Schedule—None or trivial
    Cost—None or trivial

    Note that the tasks that occur earlier, that are on the critical path, or that have more than one predecessor, should have greater impact to their associated risks.

  4. Once you arrive at a consensus among stakeholders on each task’s risks and determine its probabilities and impacts, calculate the Expected Value (EpV), where:

    EpV = P × I

  5. For any task that earns an EpV score above your risk baseline, the risk associated with that task is considered a top risk. An EpV score of 30 is a conservative baseline to set, but your risk-tolerance baseline score could be 40, 50, or greater, depending on the project’s priority for the organization and the organization’s risk tolerance.

  6. For the top-risk tasks, work with the subject matter experts on your team to revise the tasks’ time and cost estimates by using either a three-point or a beta-distribution estimation method

    To revise your top-risk tasks’ estimates, first, determine your optimistic (O), most likely (M), and pessimistic (P) estimates. Then, calculate a beta-distribution average value as:

    Average = (O + 4M + P) / 6

    The beta-distribution estimation method is a more conservative method than the three-point method suggested by some literature. Keep in mind that any estimation methodology you use should be based on your organization’s risk tolerance.

  7. For those tasks that score below your set risk-tolerance baseline point, stick with the original estimates for the schedule and cost. The risks are low enough to justify not spending the additional time to derive the additional estimates.

So now, let’s illustrate the methodology just described. Suppose that you are managing a software development project and that the risks associated with the “Write Business Requirements” task look like this:






Top Risk? (Y/N)


Write Business Requirements

Client's changes to scope as project progresses impact the schedule





Revise the schedule estimate

Write Business Requirements

Client's changes to scope as project progresses impact the cost





Revise the cost estimate

Write Business Requirements

Business analyst's leaving the company impacts the schedule






You can see in the preceding table that the schedule and cost estimates must be revised because two of the risks exceed our risk-tolerance baseline of 30 – they are top risks. Our revised estimates look like this:



Estimate Average

Write Business Requirements


















Note that the difference between the revised estimate averages and the most likely estimate is as much as 46 percent [the difference between M and the beta distribution average is [(5.83-4)/4)×100 = 45.75%]. This 46 percent difference should be used later for contingency reserves in the risk response planning phase. Also, note that project managers who do not estimate resources (and thus derive cost) at a task level can still apply this method at the summary-task level.

When managing small to medium-sized projects, the schedule and cost estimates are generally smaller in scale than are those of larger projects. The smaller scale is what makes using qualitative risk analysis sufficient and more practical for improving the estimates for top-risk tasks. Using the methodology explained here will help project managers improve their schedule and cost estimates and thus improve the chance of the project’s coming in on time and within budget, two of any project’s ultimate goals.

Amro Elakkad

Amro Elakkad (M.Sc., PMP) is a project management speaker, trainer, and consultant. He has over twenty years of experience in the information technology, financial, engineering, education, and government industries. Amro has implemented and managed projects and programs exceeding USD $17 billion in value. He has special expertise in troubled projects, risk management, scheduling, and estimation in the global arena. Amro has published numerous papers and articles in project management-related magazines and conferences. He can be reached at a_elakkad@yahoo.com

© 2008 International Institute for Learning, Inc.

© Microsoft® Corporation

    Fortæl os, hvorfor du bedømte indholdet sådan. (valgfrit)