Crystal Ball or Early Warning System?

Have you ever had this happen to your project, where you were on track to finish a major deliverable, then close to the end, the schedule started to slip. The Wigglechart below shows how the team aggressively pulled in the schedule at the beginning, they tracked to the schedule for about 6 months, then things started slipping slowly, then about 2 months from the target they really started slipping week for week.

Screen Shot 2019-07-30 at 9.33.44 AM.png

The fundamental problem is by the time they knew they were going to be late, it was too late to recover. If only they had a crystal ball or some kind of early warning system that told them this was going to happen early on so they had time to correct the problem.

Well, we don’t have a crystal ball but we do have an early warning system. It starts by addressing the causes of why this happens, then implementing solutions so if the schedule slips, you see it early on. Here are just some of the reasons that can cause this to happen, along with corrective solutions.

  1. Planning too aggressively at the beginning

    • Problem: Nobody wants to show a late schedule to management, so durations are aggressive and manufactured to show the schedule that finishes on time. Of course, nobody believes the schedule because “we’ve never done it that quickly before”, but if we push hard enough, we’ll try and get it done by then. This is our “target schedule” (though not based on any form of reality).

    • Solution: Show a schedule that’s late! Not intentionally, but rather we want to show a realistic schedule, and if the durations are really unknown, be conservative, not aggressive. If there’s a gap, we want to show it now rather than later. By looking at the critical path (the tasks causing the schedule to finish late), it may cause us to change our overall strategy (buy vs. make, outsource vs. hire, change product definition) that would allow us to realistically finish on time.

  2. The schedule is not updated

    • Problem: By default, schedules always want to move to the right and get later. If the schedule is not updated, these slips will accumulate weekly, and at some point, becomes impossible to recover, i.e. the gap is too big to pull-in given the number of days remaining to target.

    • Solution: Refresh (update & pull-in) the schedule weekly (minimum). If the schedule slips, attempt to recover the slip (we’ve seen teams not leave the room until they’ve figured out how to get the lost time back). We usually push teams to get a further pull-in. This is called “banking time”, so if the schedule slips later, we have that buffer to minimize the impact on the schedule. This is a proactive rather than a reactive approach. Pulling in before the schedule slips.

  3. Updating long duration actives

    • Problem: If I’m managing a multi-week or even multi-month activity, and I slip the schedule (assuming I even know it), I know I have time to recover, so I will report on schedule. This scenario is very similar to point #2 - I will report being on schedule until the last possible moment when I know the finish date will be impossible to hit, and then I have to report it.

    • Solution: Breakdown the near-term asks (looking out about 4-6 weeks) into 1-5 day duration. If a task doesn’t finish on time, I will see the impact on the overall schedule. If the schedule slips, I have enough detail to determine how to pull the schedule back in (if I’m only looking at a 90 day task, I can’t see the detail or see the subtasks driving that end date, so I can’t pull it in).

  4. Missing tasks

    • Problem: the activity owners have not been involved in either the initial planning or/and the schedule hasn’t been continuously scrubbed. We all know work changes over time, and the more a team learns about the project, the more the work will change. However, if the changes are not entered into the schedule and tracked, we will not be able to see the impact of those tasks on the schedule. If they would end up on the critical path (but we can’t see them), then we could end up focusing on the wrong tasks. This is a double-whammy, because since the work is not in the schedule, it is not updated and therefore we se the same effect as point #2.

    • Solution: The activity owners should be involved in defining their schedule. The schedule should be continuously scrubbed throughput the week, so as the project and work changes, so does the schedule.

  5. You just don’t know how long the work will take

    • Problem: You don’t know how long the work will take, since experiment #2 depends on experiment #1, experiment #3 depends on experiment #2, and so on. So the schedule is planned assuming one experiment (right first time), and if it doesn’t work, you will just re-plan.

    • Solution: Estimate how many learning cycles (experiments) are needed (realistically/conservatively), determine the duration of each learning cycle, and plan accordingly. We have a rule of thumb that easy problems (we’ve done this before and there’s a large amount of reuse) usually need 1-3 learning cycles, medium problems (we’ve done this before but there are a lot of changes) are usually 3-5 learning cycles, and hard problems (we’ve never done this before) are 5-7 learning cycles. The team usually knows whether it’s an easy, medium or hard problem.

  6. Lying - or not telling the truth

    • Problem: If I’m managing my part of the program and the schedule slips, I may not want to report the slip (as this is “bad”), in which case, I will report “on time” and hope I will make it. Again, I don’t see the slips early and they accumulate until at some point I go past the point of no return and to becomes impossible to recover.

    • Solution: Education and training. It is important all team members understand that we are looking for honesty and transparency, Nobody will get “beat up” if a slip is reported, but the focus becomes finding a solution to recover from the slip. Breaking down the near-term, long duration tasks into 1-5 day duration will go a long way, since activity owners will have to report back each week whether they completed the task.

There are many other reasons why the schedule can appear “on time” until the end and then slips, but these are the main ones. To implement these solutions requires both training and coaching a project team.

How decision model goals & objectives translate to a schedule

How decision model goals & objectives translate to a schedule

In this example the team needed to determine which market segment to target for a new product. The choice of segment would then drive customer selection and eventual product definition around the driving requirements of the tier 1 customer in the selected segment. They believed that 80% of the segment's requirements would be captured from this driving customer, so selection of the right segment and customer was critical to realizing the project goals.

Read More

Schedule pull-in makes the Refresh Planning process work

Refresh Planning is made up of the following elements:

  • Update (looking back to record what was done)

  • Pull-in (looking forward to breakdown long duration tasks and/or change the schedule to cause schedule acceleration)

Most teams only focus on Update, which is good, but it alone does not cause the schedule to accelerate. You really need to do schedule pull-in after each update.

Reserve 5-10 minutes at the end of the refresh session to seriously look for pull-in opportunities and then put them directly into the schedule so the team can see the result of the action.

You can aid this process by asking:

  1. What is on the critical path over the next 3 weeks?

  2. Looking at the critical path chain of activities, what can we do to accelerate this work?

  3. Specifically, can X be done at the same time as Y? Can we do Z faster in any way? Can Q be broken down into more detail and made to go faster?

  4. Finally, if all the above fails to generate a pull-in, ask if the work over the next three weeks can be done differently in order to make it go faster?

  5. If you get a pull-in, ask what the risks are with the new flow and what you can do to help mitigate them?

fastProject 4.8.8 Released


  • Problem fixed when breaking down a task when the schedule has a blank line (could cause the task to be broken down incorrectly)

  • Restoring Views/Tables/Filters improved and minor bugs fixed


  • Bug fixed where the ribbon would disappear in some cases with sub-projectsewfwe

  • Target status now reflects correctly the Target details when the target is in a sub-project

  • Displaying the “Latest baseline” when a target is in a sub-project, now displays the baseline for that sub-project

    • Note: this will also display the same baseline for all sub-projects, so bear in mind that if the sub-projects have not been updated in sync with each other, the baseline displayed for the other sub-projects could be a different date


  • Updating a schedule now automatically displays the Inspector and displays the information relating to the next Target. This allows the team to track changes to the target as the schedule is updated.


  • Options made clearer when a Wigglechart does not exist


  • Added a check for the fastProject defaults not being set, indicating the schedule should be converted.

fastProject 4.8.7 Released


  • Warning when deleting a Target manually removed

  • Importing a schedule now

    • Sets the split bar up to the Duration column

    • Fits the schedule to the screen

  • Breakdown

    • Can now add prefix to multiple selected summary tasks

    • Bug fixed where breaking down an in-progress activity with a finish date in the past and tasks are not linked would cause an error

    • Doing an Unbreakdown now displays the task bar in the Gantt chart (since it may have been a Summary with the task bards hidden)

  • Updated training files

  • Link to Blog fixed


  • After an Update, the Inspector is now automatically invoked

  • Optimized the Refresh interface so the functionality works left to right

  • Bug fixed when trying to run the Wigglechart when the Wigglechart is open. The Wigglechart can be run when open, but only if opened via fastProject, otherwise the user will get a warning to close the Wigglechart.

Macro-micro Roll-up

  • New “Create Macro from Micro” function added. This will delete all subtasks to a roll-up task while moving external dependencies to the associated roll-up task

  • Added an additional test to check for Touchpoints in the macro - these buts be contained within a summary task

  • Updated Macro-micro Roll-up documentation

  • Added a new function “Find duplicate task names” which finds tasks with the same name that can cause problems with the roll-up

  • Added “Display timing analysis” as an option in the initial dialog box

  • Documentation updated (V2.0)

Macro Mind-Mapping

Macro Mind-Mapping

In this screencast I’ll discuss Macro Mapping, which is a planning technique we use to organize a top-level macro plan. This mind-mapping approach causes a team to look holistically at a program from beginning to end... from a macro perspective. This way of looking at a program from the top-down is a key characteristic of fast teams we’ve worked with over the years.

Read More