Forecast Scheduling: The Art of Creating Dynamic Project Models

What is a ‘Project Schedule’?

If you ask your team members or executives what a “project schedule” is, you will probably get an answer like: the things you create and their due dates. These due dates are fixed and only serve as the static target. Some schedulers treat (or are forced to treat) their schedule in this way as a static, deterministic schedule that should not change. They tend to use manually scheduled tasks and no dependencies in their schedule. If we compare this to what doctors do with their patients, we realize that these schedulers are missing an important instrument.

A doctor has a patient, a project manager has a project. The doctor has a target for the patient’s body temperature: 37.5 Celsius (98 Fahrenheit). The project manager has a deadline date (depicted with an arrow in the illustration). The temperature of the patient can be too low (hypothermia) or too high (fever). The project can be early or late. The doctor measures the body temperature with a thermometer. The question is: How does the project manager measure the health of the project?

This is where several alternative methodologies come in that attempt to forecast projects, like Earned Value indicators and charts, Critical Chain buffer management charts and Agile’s burn down charts. In each of these methodologies, the schedule is used as input and transformed into forecasts. If you find those methodologies too demanding (Earned Value?) or not applicable to your project (Agile?), you can always simply use the schedule by itself to forecast the project. We prefer to keep it simple and have the schedule tell the story by itself. You can do this by building a dynamic model of your project that always reflects your latest insights and lessons about your project.

We offer a simple alternative for these methodologies: Use the schedule as the instrument to measure the health of the project. If you create the schedule as a dynamic model of the project and keep it up-to-date, it will forecast your project continuously. If your schedule is set up to forecast the project, it becomes the perfect project thermometer.

The Principle of Forecast Scheduling

Forecast scheduling is an approach to scheduling that requires the schedule by itself to produce accurate forecasts continuously. We define a schedule as: a model of the project to forecast it. If we want the schedule to forecast, we need to create a valid, dynamic and robust model that forecasts the project:

  • Valid
    A valid schedule is a schedule that produces accurate forecasts.
  • Dynamic
    A dynamic schedule is a schedule that updates itself as much as possible. A dynamic schedule comes as close as possible to realizing our principle of dynamic scheduling: when one thing changes in the project, you need to change only one cell in the model, and all forecasts in the entire schedule are immediately recalculated by the software to be accurate again.There are several reasons why we need schedules to be dynamic:
    • Only dynamic schedules can keep up with the changes in projects.
      Changes happen so frequently in projects that it is hard to keep up with them. If your schedule is static, you will have to review all dates of future tasks every time you make one change. You will spend too much time keeping the schedule alive and likely stop updating it during project execution when you are busy.
    • Dynamic schedules save time.
      We have made an attempt to quantify the amount of time saved when working with a dynamic schedule instead of a rigid schedule. For a project of 100 tasks and 3 months, we calculated that you will save about 50 hours of effort if you create a dynamic schedule in the first place.
  • Robust
    There is an extra level of sophistication when building a forecast model. A forecast model is alive and responds tochanges, but how well does the model respond to those changes? Project models only survive changes well if they are set up in such a way that they respond properly to a wide variety of changes. A robust model is a model that can survive as many changes as possible, even extreme circumstances, with as few necessary adjustments as possible. Choosing the right dependencies will make a project model robust.
  • Model
    A model is a deliberate and smart simplification of the reality. A schedule should be an intentional and intelligent simplification of the project. If you try to replicate the complex reality of the project inside scheduling software, you will end up with a large monstrosity of a schedule to manage a complex project. The art of scheduling is capturing only what is important in the project. Do this and you will end up with a schedule that is workable and that forecasts the project well.
  • Forecast
    The schedule is a model built to forecast the project. Schedules are built for other reasons as well, but we believe that the biggest benefit is using your schedule to continuously forecast your project. Stakeholders are interested in accurate forecasts.

If you want the schedule to forecast, you must create complete and correct network logic, minimize the use of date constraints, and keep all completed work in the past and all work that needs to be done in the future.

Benefits from a Forecast Schedule

A forecast schedule provides the following benefits:

  • It provides constant feedback on whether the project deadline date and budget can still be met, given the way the project is unfolding in reality.
  • It facilitates scenario development.
    In order to explore what-if scenarios to solve problems, the schedule needs to be a dynamic model. In a typical project, many slippages need to be compensated for. Developing what‑if scenarios leads you to the best road forward.
  • It is essential for program management.
    Schedules of subprojects need to be dynamic models when you want to roll them up into a master schedule. Otherwise, you will spend too much time making changes in the master schedule – so much time that you will stop doing it or not even consider it. If program managers cannot develop what-if scenarios, they will accumulate slippages and become monthly messengers of bad news. When dynamic models of subprojects are rolled up into program schedules, problems become visible in the master schedule and can also be addressed in the master schedule. Program managers can then deliver their program on time.
  • It is required for schedule simulation.
    In order to perform schedule simulation for quantitative risk analysis, you will need a dynamic model. Monte Carlo schedule simulation is essential to provide forecasts with their probability to executives and clients.

How to Implement Forecast Scheduling?

To realize a forecast schedule, project managers need to do the following:

  • Project managers will use deadline dates or the schedule baseline to capture promised and committed dates. Too many schedulers use the schedule itself to reflect their commitments and then desperately want to keep their schedule static, using it as a project execution model only. With that decision, they kill the dynamic nature of the schedule. In our approach, the schedule will be a dynamic model that reflects the living and changing nature of a project at all times. The commitments can be captured using deadlines right away or later using the schedule baseline that will reflect the approved schedule at all times. We must separate the live, dynamic model of the project from the static deadlines (schedule baseline).
  • Project managers want to minimize the time spent on scheduling their project. They can do this by setting up the schedule in the right way with all dependencies and as few date constraints as possible. Ideally, when one change happens in your project, you would have to edit only one cell in your model of the project (which we introduced as the principle of Dynamic Scheduling in previous books).
  • Project managers will update their schedules by constantly revising the to-complete estimates. Many project managers just enter actuals (what happened in the past) and forget about the future of their project. In order to forecast, you need to capture revised forecasts from your team members as well. As team members start tasks, they learn what these tasks will really take to complete. Project managers need to reflect those emerging insights in their schedule in order to get a real sense of how long the project will take. Of course, you may have to re-optimize your schedule to stay within the dates promised.
  • Project managers will be brutally honest to the project stakeholders and enter into the model all factors that affect the forecasts the schedule produces – even if these factors do not reflect well on the project manager.

We hope you like this approach to scheduling. If you want to know more about it, please pre-order your own copy of Forecast Scheduling at 25% off at ProjectProCorp.com until Dec 15, 2014 and, after that, at the regular price of $59.95.

Written by Eric Uyttewaal
Eric is a thought leader on project, program, and portfolio management. He spends most of his time using software from Microsoft. He has authored seven well-known textbooks including ‘Forecasting Programs,’ 'Forecast Scheduling with Microsoft Project 2010/2013/Online,’ and ‘Dynamic Scheduling with Microsoft Project 2000/2002/2003.’ He founded ProjectPro, which specializes in Microsoft Project, Project Server and Project Online. Eric developed several Add-ins with his team that enhance the capabilities of Microsoft Project in creating better schedules (Forecast Scheduling App), managing cross-project dependencies (CrossLinksPro), identifying and documenting the Critical Path (PathsPro) and creating S-curve reports (CurvesPro). He was president of PMI-Ottawa in 1997. Eric has received awards from PMI in 2009, from MPUG in 2012, and from Microsoft from 2010 until 2017 (MVP).
Share This Post
Have your say!
00
1 Comment
  1. Interesting position.

    However, some of the points and suggestions omit “…and the last project managers who do not use this idea keep their jobs.”

    This point, “Project managers will be brutally honest to the project stakeholders and enter into the model all factors that affect the forecasts the schedule produces – even if these factors do not reflect well on the project manager” would not go over well in most organizations.

    I think your suggestions are “just” interesting.

Leave a Reply