Refresh Planning

Refresh Planning is a core practice of fast teams. Refresh Planning involves three steps; update, break-down, and pull-in. It’s a weekly team activity. They look back in time to record what they did and didn’t get done, then decompose near-term long duration critical path tasks, and then use the more granular and detailed schedule to reconfigure the work in order to accelerate it. In order to be on time, they know they need to pull-in the schedule every week.

Project teams need to know where they are. Like being lost in a city, the first thing you do is locate where you are by looking at cross-streets, and then studying the map in order to chart the course to where you’re going. You can’t get from Point A to Point B if you don’t first know where Point A is. Updating a schedule with where you really are is like locating your “Point A” on the map.

When a schedule is not up to date it’s useless; you don’t know what work has been done and what remains, and you can’t pull-in the schedule... which is the reason to make this effort in the first place.
Lets look at how to properly update a schedule; first by doing it wrong and next by doing it correctly. Most of the schedules people show us before we’ve worked with them are updated incorrectly. When it is done wrong, the schedule will give you the wrong critical path and the wrong project end date; like a balance sheet that does not add up.

Lets play the update game with this simple schedule.

Task a is not started, so I skip it.

After pressing the task owner of b for its status, Jeff tells me it is 40% complete. In a few minutes I’ll discuss the problems created by “percentage updates.”

I continue to drive for status from Susan on task c, she tells me “not much is done, only about 10%.” So I enter it.

On to task d, Mike says “it is not started,” but he’s confident it will start on the 22nd when the resource he was promised starts working on the project.

Jim tells me does not know when task e will start, but “he will deliver it when he had committed to on the 15th of February” and “to trust him, he’’ll deliver.”

Finally, Mary proudly announces her task f is finished. So I mark it 100% complete.

The team can’t wait to get out of the meeting so I let them go. I did it, I updated the schedule and now it accurately reflects the status of the project.

The only problem is, it is all wrong, including the end date on the project even though I recorded what the team said. Lets review what is wrong with each task:
task a… was not started, so it needed to be pushed to the right of the red dotted line, which is today’s date.

task b… was updated as 40% percent complete, it then assumed that is was 40% of the original duration — what it if started earlier? What if it started later? Further, I can’t update into the future because its not happened yet. That is what the green line to the right of the dotted line tells me, progress into the future.

task c… has the same problem as task b, but in this case the 10% complete does not account for the remaining 9 day duration which needs to begin at the red dotted line, not on the second day of the project. Percentage updates give me no way to re-estimate the remaining duration of a task.

task d… is missing a task called “make resource available to this project” which is its real predecessor. This is the task that should have been updated since it is the one delaying task d’s start. I inserted a date constraint in the future by manipulating the start date in the bottom view, which is impacts the free-flow of the critical path. Now this task is locked and can’t move.

task e… has the same problem as task d, but in this case the finish date constraint pulled the task to the late schedule and totally distorted the critical path. We want network logic dependencies to drive the schedule, not date constraints.

task f… was completed, but by entering 100% complete it assumed it started and finished when it was scheduled to, this put actual duration into the future again. If it was 100% complete it could only have taken a maximum of 4 days or Wednesday though Monday night.

All and all, a total failure of an update that produced the wrong end date.

I’ll show you the right way to do it now. I put the wrong update in the bottom view for comparison to the correct update in the top view. The key to updating a schedule with a team is to go fast and don’t ask “why,” just accept the data given by the task owner. Why doesn’t matter, we want to focus on the going forward impact of the updated schedule and how the team can collectively find solutions to pulling in the critical path. The focus is positive and forward looking, not negative and fault finding. Most projects we work on can be updated in 30 minutes a week; and then another 30 more minutes a week looking for opportunities to pull-in the schedule.

I’ll use a fastProject wizard to update the schedule. It’s called fastUpdate. It contains over 40 rules for proper updating and ensures that the schedule is updated correctly. For tasks within the update window it will ask if the task is started?, when did it start?, is it finished? and how many days to complete it if it is not finished?

Task b started out of sequence, it should have started after task a, but task a did not start.

This update created negative float which we’ll discuss later.

I’ll jump ahead to the end of the update.

I’ll correct the negative float by deleting the dependency between task a and b, since this is no longer valid. The actual start of task b overrides the finish to start dependency between a and b.
Compare the differences between the right and wrong update. The right one is on the top. The correct project end date is 2.9, while the wrong schedule shows it ending on 2.15. The actual duration is illustrated as a green bar to the left of the dotted line, the remaining duration is to the right of the dotted line. Remaining duration gives task owners a chance to re-estimate duration every week based on new information. If a task was not started, it was moved to the right of the dotted line.

The problem though is that I don’t know if my end date moved as a result of the update. I can’t see the trend of its movement without a reference point. We call this the target. I’ll add a target now.

The target date is when it is needed, this is indicated by the red star. While red diamond is when they are going to get it based on the schedule driving it. The difference between these dates is the gap that must be closed to be on schedule. In this example, it is wanted on 2.3, yet it is finishing on 2.9. We can track the movement of this milestone using this trend chart we call a “wigglechart.” The milestone “wiggles” up and down over time after each successive update. We want to know if it is trending on schedule or trending away from the target date. If we have enough early waning of a slipping trend we can usually take actions to reverse the slip. Slip that is “discovered” the night before a major deliverable can never be recovered.

The yellow dot is where the current schedule is finishing (that red diamond), the cross-hairs intersect at 2.3 which is the target (red star). The goal is to drive the yellow dot down to the horizontal line so it hits the intersecting points.

We now have a reference point for to track our progress.

Updating is the first step in the refresh planning process. Update looks back to record progress, breakdown defines the near term schedule in more detail, and pull-in is a team process to find solutions to a schedule slip and/or to try and pull-in the schedule before it slips in order to “bank time” for when it is needed later, when the project eventually slips to the right as we all know it will. That banked time will be needed later.

Lets go through the refresh cycle a few times. We’ll project ahead as if a week has gone by on the project and do another update of the progress with fastUpdate. Again, this is ALWAYS a team process, never to be done alone by the project manager.

The update is complete and my gap is 8 days, and this update caused a 2 day slip from last week. We need to try and recover this time and then get 6 more days out of the schedule to get back on time. Looking for pull-in opportunities is always group process that builds team ownership and conviction to the schedule.

When I click “pull-in,” the critical path is displayed. This is what is driving the schedule gap. In order to pull-in, we first need to break the near term critical task down into more detail. This tool breaks down the task, preserving the links and actual duration.

We can estimate the duration of the sub-tasks and determine the logic relationship between them. In this case b1 is 9 days and b2 is 5 days.

B2 starts 75% after b1. Lets assume this is all we know at this time. We only gained a quarter of a day, but the break-down has better defined the near term work packages. How did the milestone move… did it pull-in or push out?

The wigglechart tracks milestone movement. We slipped a few days. The dot turned to red indicating the chances are low of hitting my target day on time, since I need to pull in more than 2 days a week to hit the target and I only have 5 days remaining before the target date.

Observe as another update cycle is performed a week later.

Eventually the project is completed. It was close to schedule, but it missed the target date.
This was an illustration of the weekly Refresh Planning cycle. Some teams do this once a week, while others do it 3 or five times a week. They find that the increased frequency highness the awareness of time and provides them with early warning of potential problems, while there is time to take corrective actions.