Schedule Margin

Schedule Margin

The term schedule margin is well-known in project management. What needs to be better known outside the US Government (USG) contracting world is how schedule margin is treated in the Performance Measurement Baseline (PMB). The PMB is the program record document subject to the Defense Contract Management Agency (DCMA) oversight. This oversight starts and ends with Earned Value Management (EVM), defined in ANSI-748-B.

This may seem irrelevant to those outside the USG program, but it should not. EVM is a powerful tool for project and program management, no matter the domain or the context within that domain.

Schedule Margin and the PMB

Schedule margin is a project management tool for dealing with schedule contingencies. Schedule margin provides a separately designated "buffer" to "protect" the delivery dates.

There are two approaches to schedule margin.

In the first, the final task is baselined to be finished ten days before an End-of-contract (EOC) milestone is aligned with the contract need date. The calculated difference between the final task completion and the contract need date is the schedule margin to the contract need date.

In the second, the EOC milestone is baselined to finish immediately after the final task – which is still baselined to finish before the contract needs a date. The calculated difference is the schedule margin to the contract need date.

The margin is the same in both examples, but the method used to calculate the margin is different. In the first case, the margin is implicit if the Contract Completion Date is usually not included in the Integrated Master Schedule as an activity. The second is explicit since the Finish Milestone is in the Integrated Master Schedule.

The second example is preferred simply because a visible activity connects the last task with the "need" date. In both cases, the "Planned Finish" is the same - the end of the Last Task. Or any Task if there is a margin for intermediate deliverables.

No matter which approach is used, a Schedule Margin is needed. No schedule margin means you're late.

How To Calculate Schedule Margin

Now comes the question of calculating the schedule margin. Yes, the schedule margin is calculated. It can be "stated." However, the schedule margin is like the "stated end date" many blogs, white papers, and voices complain about. If you have a stated end date and need to know the schedule required margin, your project is late before it starts.

Here's how we calculate the space and defense business schedule margin - Monte Carlo Simulation. It's that simple, and it's that hard.

The schedule itself must be credible. There are no hard constraints. No weird dependencies - only Finish to Start. No bogus durations. The Most Likely duration, for the starting point of the calculation, must be "most likely." That is not the average. The duration would appear most often if you performed this work repeatedly and did not learn anything from it. This is a common mistake when first learning about probabilistic risk analysis.

Sizing Schedule Margin using Monte Carlo Simulation

The Monte Carlo approach is discussed as well. Both are needed for a credible plan in our domain. Here's how you do it:

  1. Build the plan (Integrated Master Schedule - IMS) from the top down. It starts with the Program Events (PE) - maturity assessment points. The Significant Accomplishments identified as "entry criteria" for the PE. Define the Accomplishment Criteria (AC) for the tasks that perform the work that delivers the SAs in support of the PEs. This results in a vertically integrated plan. A plan that defines all the work needed to have the project arrive at a known point along its maturity path to completion.
  2. Make the horizontal connections between ACs and other ACs or ACs and Tasks. These connections define the program "flow" for work completion, while the vertical connections define the "flow" of product maturity.
  3. Next, could you identify the risk buy-down activities? This is work done to reduce risk in the technical or programmatic aspects of the project. These tasks are explicitly identified.
  4. Using a Monte Carlo Simulation (MCS) tool - Risk+, @Risk for Project, PERTMaster - construct a probabilistic estimate of the completion of the maturity assessment points. Confirm that the 80% confidence points on the CDF - "there is an 80% chance that the task will be completed on or before this date" - meet the project's needs.
  5. Add buffer(s) before high to moderate-risk tasks, collection points, or milestones that bring the deterministic schedule to the customer's desired date. This deterministic date then includes the "buffer" or margin.
  6. Set these buffer or margin tasks to zero (0) duration and rerun the Monte Carlo Simulation to confirm the 80% confidence date still matches.

The probabilistic duration needs to be discussed a bit more. There are several approaches here.

  1. Get three point estimates from historical data or subject matter experts.
  2. Get variance values from historical data or subject matter experts.
  3. In both cases, confirm that the three-point estimates match some probability distribution - Triangle or BetaPERT are useful ones.
  4. Confirm that the three-point estimates are either 0/100 estimates - that is, they are the 0% or the 100% points in the PDF, or they are the 10/90 points - the 10% or 90% points. The 10/90 is better because it represents a better narrative of the estimate. 10% say - when repeated 10 times under the same conditions, this task is completed 1 out of 10 times on or before this duration or date. 90% says - when repeated ten times under the same conditions, this task is completed 9 out of 10 times on or before this date or duration

With this three-point information, the MSC can be run (Risk+ assumes 0/100, @Risk can be used with 10/90).

It is important to remember that the probabilistic and deterministic completion dates are two very different things. The buffers must be set to zero for the deterministic date to match the probabilistic date. When the schedule is being executed, they are set to the forecasted duration needed to "protect" the assigned dates.

Finally, the MSC is usually run weekly after the status meeting when the Estimates to Complete are from the project team. This run forecasts any changes in the probabilistic complete dates and any margin erosion. Tracking margin erosion is a critical indicator of project health.

Here's an example of an MSC tool pointed at a task with a symmetric distribution - which rarely happens in real life (the symmetric part).

The 80% confidence value is shown in the table to the right. The Cumulative Distribution Function (CDF) shows the likelihood of each specific date occurring during the simulation. The symmetric form of the distribution is suspect since, in practice, tasks hardly ever finish early in the same number of times. They finish late by randomly sampling all the durations in the distribution, describing the task's duration.


Ian Heptinstall

Teacher & Coach in Projects and Procurement

6 个月

You said "There are two approaches to schedule margin." That might be the case if you are not scheduling using the #CriticalChain approach. That uses quite a different approach. If EVM is mandated under contract, then a common approach is to calculate an unbuffered version of the CC schedule to use for EVM calculation to meet the contractual commitments. This EVM/un-buffered version of the schedule is only used for client reporting, not to manage work within the project team itself, where things like CC's fever chart and other flow-based metrics are preferred.

回复
Daniel B.

Project Support/Controls for Interesting Projects - Canada/EU/Africa/Asia, Construction, Power to X, Minerals and Metals, Power, Infrastructure, Data Analysis, M. Sc.ME, SCS, SE, EV, Multilingual portfolio

6 个月

Thank you all for the good discussion.

回复
Alex Lyaschenko

Portfolio Planning & Delivery | PMP | P3O Practitioner | AgilePM Practitioner | Six Sigma | Project Data Modelling | PredAptivePM

6 个月

You said; ‘The schedule itself must be credible. There are no hard constraints. No weird dependencies - only Finish to Start.’ It is guaranteed that the result will be inaccurate. Such a Monte Carlo simulation model doesn’t represent reality, as even a simple project has parallel activities. 2. Reliable MCS modelling requires a detailed Dynamic Delivery Model, not a high-level progress tracker. There are many other requirements for the DDM to be creditable.

Dennis Wilkes

Post Graduate Student Masters in AI at La Trobe University

6 个月

There are possibly 2 reasons why organisations don't carry out schedule risk to determine contingency: 1). Ignorance, 2). Are risk takers, or gamblers with their clients time and money. I was recently threatened by the sack if I mentioned the word "Contingency".

回复
Greg Ramsay

Global Director - Risk and Consulting at Hatch

6 个月

I like this post. I am continually amazed how many people don't think of schedule contingency for their project schedule. They of course always have a contingency for the estimate but don't seem to realise that you need it for the schedule as well to protect key Milestones and of course a more reliable and predictable start of revenue. Also creates problems trying to explain to them the schedule risk analysis results and why their schedule has nearly zero chance of being achieved given the level of risk, merge bias and of course we are comparing against a schedule with no contingency allowance. Cheers Greg

要查看或添加评论,请登录

Glen Alleman MSSM的更多文章

  • 2 - Fundamentals of Digital Engineering Systems

    2 - Fundamentals of Digital Engineering Systems

    This is the 2nd in a 3-part series on Digital Engineering. The 1st introduced the Capabilities of Digital Engineering.

  • Some GovLoop Publications

    Some GovLoop Publications

    GovLoop is The Knowledge Network for the Government of more than 300,000 federal, state, and local government peers in…

  • Five Immutable Principles of Project Success No Matter the Domain, Context, Management Tools, or Processes

    Five Immutable Principles of Project Success No Matter the Domain, Context, Management Tools, or Processes

    Here is a collection of materials I use to guide project success when we are not immune to common reasons for project…

    6 条评论
  • Planning is Everything

    Planning is Everything

    Plans are nothing; Planning is Everything. The notion that plans are nothing but planning is everything is a standard…

    3 条评论
  • Learning from Mistakes is Overrated

    Learning from Mistakes is Overrated

    We've all heard this before: hire good people and let them learn from their mistakes. The first question is, who pays…

    2 条评论
  • Quote of the Day

    Quote of the Day

    “The first rule of any technology used in a business is that automation applied to an efficient operation will magnify…

    3 条评论
  • Quote of the Day

    Quote of the Day

    For the sake of persons of different types, scientific truth should be presented in different forms and should be…

    1 条评论
  • The Fallacy of the Iron Tiangle

    The Fallacy of the Iron Tiangle

    The classic Iron Triangle of lore - Cost, Schedule, and Quality- has to go. The House Armed Services Committee (HASC)…

    9 条评论
  • Why Projects Fail - The Real Reason

    Why Projects Fail - The Real Reason

    At the Earned Value Analysis 2 Conference in November of 2010, many good presentations were given on applying Earned…

    2 条评论
  • Quote of the Day - Risk

    Quote of the Day - Risk

    The real trouble with this world of ours is not that it is an unreasonable world, nor even that it is a reasonable one.…

    6 条评论

社区洞察

其他会员也浏览了