Put Off Blaming Procrastination

Work will always expands to fit the schedule.

Recent posts on the theme of procrastination, or more specifically, finishing work on deadline rather than early, have stepped on my toes. I'd like to speak up on behalf of my fellow "procrastinators."

The theme implies that people have nothing to do besides that One Task. It implies that they sit around playing games and don't have to scramble to meet multiple, simultaneous, arbitrary deadlines and then die inside when people criticize the lack of perfection.

On Time is Late -- Are you sure about that?

Before dealing with "procrastination," one should question the value of beating deadlines rather than meeting them.

The Lean principle of Pull states that early delivery can cause waste. Normally, one thinks of storage costs as waste, but doing work before it's needed presents other costs. For example, racing to complete a task might sacrifice planning, risk management, or quality. It might also cause neglect of lower-priority tasks or accelerated cost of funds.

The real schedule-waster is not procrastination. The great Time Thieves are multitasking and perfectionism.

The assignments will multiply to fill the schedule.

Multitasking eats up time by inserting course changes into the day. Human minds are not like Intel chips with four independent CPUs. It takes time to push task A into the stack, bring up task B, recall where you left off, and start making progress again. Moreover, what manager will forgive neglecting task A, which is due tomorrow, just so task B can be completed a day ahead of its due date one week from now?

The reach for perfection will stretch to the deadline.

Management teaches "procrastination" by forgetting to balance constraints. If you expect perfection in any human endeavor, expect employees to pour every available hour into quality.

Managers who want early deliveries need to increase collaboration with their reports. That means, first, avoiding micromanaging, but still sharing enough involvement to guide energies toward the right balance between progress and quality. It means, second, putting themselves in a position to say, "Stop! That's good enough," when the task reaches sufficient progress and quality.

The prevalence of multitasking and perfectionism make "procrastination" not a performance problem, but a management problem. Sure, when employees fail to adapt, it becomes a performance problem; but I caution against pointing fingers at the effects when the cause lies within Leadership's hands.

Slack, Float, and Critical Path Methodology

So as the PM I want to locate the longest path, because it will assure that I meet the project deadline.

Correct. But don't look for the "longest path," look for the "critical path." They are the same, but when you say critical path, you indicate that you know the best way to find it.

The shortest path, which has no slack, tells you as the PM that you will not be able to meet the deadline for the project.

Forget 'shortest path.' What tells you that you will not be able to meet the deadline is an end-to-end path having "negative slack." More about that later.

 

Slack is about an individual activity. Float is about how that activity's slack relates to the activities around it. They are the same thing viewed from slightly different perspectives.

 

Here's a source of confusion that I have yet to seen or hear anyone explain: For the critical path, we look for a path from the Start to Finish that has either zero or a negative number for the slack of all its activities. When we talk about a path that has slack (for example, 2 days), however, we talk about that single branch, not about a whole Start-to-Finish path.

 

Did you do connect-the-dots pictures as a child? Lets do a mental experiment. Imagine replacing all the boxes in a network diagram with their slack numbers. If there is enough time to do the project, you will see a path of zeroes from Start to Finish. In your mind, go over that path with a highlighter. That is the critical path. The durations of those boxes add up to the shortest time in which the project can be completed.

 

Suppose you add up the durations of the activities along the critical path, and the sum is 42 days. If the deadline is in seven weeks (49 days), then you have enough time.

 

If Sales promised the customer the project would be done in 40 days, but the project requires 42 days, then instead of having zeroes along the critical path, you will have negative twos (-2s). This is called negative slack. You will need to use schedule compression techniques to reduce the length of the project.

 

Note that the last two paragraphs involved only the critical path activities. None of the paths that you did not highlight in the first paragraph matter. They are all irrelevant -- up to this point.

 

Slack is also called "float" because you can move the activity forward up three days. Imagine a small cereal bowl floating in a large sink. It has room to float around. The bounds within which it can float are set by the edges of the sink. Similarly, an activity with positive slack can float within bounds set by parallel activities in the critical path.

 

Here's another confusing point. Suppose activities B and C are parallel to each other. That is, both can start as soon as activity A is done, but both must by done before activity D can start.

 

Activity B

Slack = 2 days

Duration = 4 days

 

Activity C

Slack = 0 days

Duration = 6 days

 

How long will the path that contains Activity B take? If you answered, 4 days, think again. Suppose activity A ends on day 10. Activity C takes 6 days, so activity D cannot start until day 16. So how long does the path containing activity B take? The path takes 4 days of activity plus two days of slack. It takes the same time as the longer activity (C) that it parallels.

 

Two activities done in parallel cannot be completed any faster than the longer activity. For this reason, it is a waste of time to look for "shorter" Start-to-Finish paths.

 

Activities or paths with slack (float) do not affect how long the project takes. However, there are two exceptions.

 

First, if the PM uses schedule compression techniques to shorten the project (for example, from 42 days to 40 days), then at least some of the activity durations or the relationships between activities change.

 

When the PM recalculates how long the project will take, the critical path may change. One critical path activity that had -2 slack might now have a slack of 1, so it is no longer on the critical path; and another activity that formerly had a slack of +1 and was not on the critical path may now have a slack of zero and lie on the critical path.

 

Second, every activity has risk. You can lower the risk of a non critical path activity by starting it early. You cannot do that with a critical path activity, so it carries more risk. If something goes wrong with a non critical path activity, if it takes long enough, it can still prevent the start of a critical path activity that follows it. On paper during planning, it does not affect the project's duration, but during execution, it can.

 

I hope I clarified more than I confused. Good luck!

Handling a Customer's Wishes

Under what circumstances might change requests to the project's scope be denied? How can i handle a customer's wishes if the scope change is not approved.

Short answer: The Project Manager's (PM's) job is to handle the project's requirements, not to handle the customer's unfunded wishes.

Scope changes always affect schedule, cost, quality, resources, and/or risk. A PM will not approve a change that negatively affects those constraints unless it is necessary in order to meet other, higher-priority constraints. 

Obviously, if adding a bell means going over budget and falling behind schedule, the PM will disapprove it. On the other hand, if the customer will not accept the project because the whistle toots with the wrong tone, then the PM may approve spending more to tune the whistle. 

Remember, these are business decisions. At some point, the penalties for cancelling a project may cost less than the cost of completing it.

The above deals mostly with changes requested internally. If the customer requests a change, the PM will present the customer with the effects (cost, schedule, ...) of the change. The customer then bears responsibility to sponsor or reject the change. 

As always, this is a business decision. Even if the customer will bear the cost, extend the schedule, and forgive any realized risks or impacts on quality, the available whistle-tuners may have been committed to another project (inadequate resources), or the loss of reputation (even though the customer specified the wrong tone) may hurt the business in the long run.

To "handle the customer," get out your requirements traceability matrix and present the effects of the change on the scope. Then present the effects of the change on cost, schedule, etc.

Copyright (C) 2012, Richard Wheeler. Permission granted for use not involving publication.