The Sooner You Start, the Later You Finish

http://www.focusedperformance.com/articles/multi02.html

To do two things at once is to do neither. - Publius Syrus

The source of this page is a posting made by Frank Patrick to one of a variety of online discussion forums, most likely an e-mail discussion list. It's tone and style may be informal, occasionally provocative, and sometimes, even impertinent. There may even be typos until an opportunity arises to clean them up for more formal presentation. Despite these minor shortcomings of style, the content is worth sharing.

William wrote...

"But there are all kinds of risks and costs of starting things as early as possible." Not true. There is no cost to starting early. The risk is with NOT starting early. Good practice has ALWAYS been to schedule all activities to start as early as possible -- that's why it's the default in most scheduling software!

Allow me to suggest some risk/costs of starting early, in increasing order of concern.

• A negative hit on cash flow from spending before one has to.
• Dilution of focus on the part of the project manager and team from what must be done to what is being worked on because we can. (Possible confusion on project progress if too much weight is given to work completed unnecessarily.) Since most projects consist of parallel paths of work, any work done sooner than necessary will just have to wait for merging paths anyhow. Kind of like undesirable work-in-process inventory in production.
• The possibility of doing work that isn't a predecessor to, but can be influenced by learning’s in parallel paths of the project, leading to potential wasted effort and possible rework.
• For multi-project environments, where several projects are pursued with a shared set of resources, earlier starts than necessary will tend to drive multi-tasking without good reason, adding otherwise unnecessary effort, time, and waste to all projects involved.

The first three are real enough, but I'd like to focus on the fourth as the most compelling reason. Many project environments are multi-project environments, dependent on shared resources that a variety of projects are calling for. There is often all kinds of pressure not only to start tasks early, as William suggests, but also to get whole projects started as soon as funding is available. One common way to manage resources in this kind of environment is to use the idea of the fractional headcount -- half time on one project and half time on another, and unfortunately, often another half time on a third project. In every Critical Chain workshop I've given, this mode of operation has been readily recognized by the participants. It allows the organization to get projects started, and after all, the sooner you get started, the sooner you finish. Right?

Wrong.

If you start projects early, and utilize the common practice of multitasking to do so without pulling resources completely off of other projects, then all the individual projects suffer from extension of lead time AND the entire organization suffers from a loss of "project throughput."

The reason for this should be quite intuitive. If you interrupt work on one project prior to handing it off to work on another project, one project sits idle while work is performed on the other. This results in longer lead times for all the individual projects involved.

The second benefit, additional throughput, comes from the combination of avoiding multitasking and the staggering of projects by their use of a heavily loaded common resource.

Tough to draw it with text, but if there are three similar projects:

a1a1a1b1b1b1b1b1c1c1

a2a2a2b2b2b2b2b2c2c2

a3a3a3b3b3b3b3b3c3c3

widespread multitasking would result in:

a1    a1    a1b1    b1    b1    b1c1    c1

  a2    a2    a2b2    b2    b2    b2c2    c2

    a3    a3    a3b3    b3    b3    b3c3   c3

completing 3 projects in the time shown -----|

(Not counting time lost to "context switching.")

Focused effort and "constraint" scheduling (staggering the projects based on the use of the "b" resource in this case) would result in:

a1a1a1b1b1b1b1c1c1

        a2a2a2b2b2b2b2c2c2

                a3a3a3b3b3b3b3c3c3

                        a4a4a4b4b4b4b4c4c4

                                a5a5a5b5b5b5b5c5c5

Starting projects 2 and 3 LATER results in them are finishing SOONER. Also, there are almost five projects COMPLETED in the time needed for three projects with the same level of resources over that timeframe. Plus the organization would see the benefit of the original three projects in an average of less than half the time required in the multitasking mode.

I know these are simplistic examples, but I believe appropriate for this limited text-based medium, and hopefully sufficient to make the case for the desire to avoid multitasking and early starting of projects.

But back to the issue of starting project tasks early...

Sometimes a set of project schedules will result in resource contention across projects. Even if resources are leveled up front to try to avoid multitasking, "stuff happens" and tasks shift in time, resulting in unplanned contention. If a schedule is designed with tasks happening as early as possible, as suggested by the software's default, these resource contentions are sometimes unnecessary for the success of the individual project, take management attention and effort to try to resolve, and worst of all, have the potential of impacting not only the current projects but the throughput and timing of other projects as well.

I'm not suggesting that non-critical activities start as late as possible, just that they don't start as early as possible. The critical chain approach suggests they start "early enough" to avoid impacting the ability of the critical tasks to proceed, and that "early enough" is defined by the feeding buffers.

Keep in mind that "early as possible" may sometimes not be "early enough." The slack that results from "early as possible" starts in critical path schedules is simply a mathematical outcome of the network of tasks and may very well not be sufficient to protect the ability of the critical tasks to make progress. (That's what happens when non-critical things become critical and why critical paths change through the life of the project.) The buffers, on the other hand, are designed/sized to provide that necessary protection.