Showing Up On Time

Half of all success is just showing up on time- Woody Allen

This morning's Daily Camera's Dilbert has this prophetic strip.

We all have experiences with meetings starting late, people showing up late to meetings. But we also have experience with people making promises for a deliverable and then showing up late. It's common, it's normal, it's part of the culture. But it's also the seeds of the lateness for projects.

Two things cause lateness:

1. The promise date was not credible to start with. It may have been possible, but it was not probable.
2. The promise date did not consider any disruptions in the plan.

The first problem must be addressed with credible estimates to complete.

The second problem addresses the first problem with schedule margin. Jurgen has a post on Slack, where is speaks about slack, Parkinson's Law, and the use of slack.

First Parkinson's Law is about how work fills the time available. So when there is slack time, work fills that time. But this is NOT the slack time that should be present in a schedule for project work. And that loss of the slack time - schedule margin - is not because of Parkinson's Law, which. The time is still there, you've decided to fill it with unplanned work. Don't do that on a project. You can do that waiting for your row to be called.

Slack - or Schedule Margin - is needed to Protect the deliverable. I work with a partner who is always rushing to the airport. When we travel together, I always make sure his flight leaves before mine. That way I have built in schedule margin to protect me from being late for my flight. He makes his, I make mine with time to spare.

Schedule Margin Protects The Deliverable

This is essentially the Theory of Constraints. Like all good ideas TOC has been misused. It says A chain is no stronger than its weakest link. The goal can be achieved through the minimum number of constraints. When we place a MUST FINISH ON (MFO) or a FINISH NO LATER THAN (FNLT) constrain in the schedule we've added risk, reduced our options and generally made life harder. This is not only common it is many times mandatory.

We must show up on time for the flight, or get left. We really do need to show up on time for meetings.

So how do we protect the MFO or FNLT constraint? We have margin in the schedule.

But unlike the conjecture that Parkinson's Law prevails, we must have a schedule that can move to the LEFT when the margin is not used or any portion of the remaining margin is not used. The picture below is an example. There is margin in the schedule for Plan A in the panel on the left. If we don't use that margin, the schedule must be designed to allow the work in the panel on the right to move to the left - that is start early. If we can't start early, the margin was nice to have, but lost. This is the example of showing up early for the flight. In Jurgen's example he did other things with that time, as we all would.

But unlike Jurgen's suggest slack or schedule margin is for the Important stuff, NOT for optional stuff. The important stuff needs protection, otherwise it's not important. 

There is a notion - a wrong notion - that the critical path is the path through the network of activities with zero slack. If you have a zero slack network, you're late before you start. All IMPORTANT items in your project need protection. That protection is called schedule margin.

How much schedule margin you need is the big question. I have 45 to 60 minutes of margin in my airport travels at DIA. I know how much time it take to drive from my house to the long term parking. How ling it takes the parking bus to drop me at the Frontier Airlines door, pretty much how long it takes to check my bag and get through security (I have a Clear Card, so I skip all the crying children and people fumbling with the baggage). Then I add 45 to 60 minutes. I can always find something to do - like Jurgen. But these things to do are not the Important ones, they are the unimportant ones (most times).

In the scheduling world, NEVER have the important work on the critial path without schedule margin.

Don't Use Slack Time for Anything Other Than Deliverables Protection

The suggestion that slack time - again schedule margin - should be used for actual work is Bad Scheduling. If there is work to do, schedule it. Allocate resources, plan the time, define the deliverables, measure progress to plan. It's work.

The schedule margin is just that - margin. It may be lost or it may not. If not the planned work on the right needs to be moved to the left - started early.

One final point.

Keep critical items - important stuff - off the critical path

Once your critical items land on the critical path you've got a double problem.

So How Much Margin Do We Need?

There is a simple answer in our domain. Let the Monte Carlo Siimulator tell us.

1. Define a "no slack" schedule. This schedule has a critical path with Zero Slack.
2. This schedule end on or before the planned date. For example if we want to launch in the 3rd week of November, 2014, we'd better have a schedule (an Integrated Master Schedule) with zero margin that shows us we can get to launch on or before that date.
3. If not we're late before we start.
4. Now, run the Monte Carlo tool. We use Risk+, @Risk for Project, and RiskyProject. This will tell us what the confidence is of completing on or before that date.

Here's a sample from Risk+. It says there is a 80% confidence of completing on or before 10/12/20 for the Initial Operating Capability (IOC). Now if the actual due date for the IOC is the left of this date, we're late before we start. If the planned completion date for IOC is say - 3/23/21, then we have 5 months margin and we now need to decide where to put that margin. That's a whole other topic, but we now know we have some chance of completing on time.

So In The End

• No schedule margin - you're late
• Never put important stuff on the critical path with schedule margin
• Plan all work, never leave anything left over to do when you have free time
• It's the off critical path items that will kill your project when they get on the critical path because you weren't watching them. Watch everything, all the time.
• Use Monte Carlo - all project numbers are random numbers. Knowing the Probability Distribution Function is the start, then knowing the drivers - things that push other things - and their PDF's provide decision points about keeping things off the path.