Events What's new?
Services Questions? Comments?

Strategy & Alignment Operational Problem Solving Project Management Implementation & Change Management

The Sooner You Start, the Later You Finish

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 learnings 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?


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:


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:


Starting projects 2 and 3 LATER results in them 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.

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.

Discuss Critical Chain - An email-based discussion group

Frequently Asked Questions about Critical Chain-based project Management

Top 10 Sources of Project Failure -- A list you probably won't see on Letterman.

Related links:

FP's Postings - others like this page on a variety of topics

Unconstrained Thinking - a collection of more polished mutterings and musings, written as a column for APICS chapter newsleters

Check Out the Following Links for More About the TOC Approach to Project Management:

Critical Chain and Risk Management - Protecting Project Value from Uncertainty -- Project management is the practice of turning uncertain events into certain promises. If so, then project management is an extended excersie in risk management. The core concepts underlying Critical Chain-based project management directly support risk management and are described in this paper, expanded from one presented at PMI's 2001 National Symposium.

Getting Out From Between Parkinson's Rock and Murphy's Hard Place -- This first link will bring up a paper based on a poster presentation originally given at the 1998 New Jersey PMI Chapter's annual symposium, honored with a "best of the show" award by attendees, and later turned into an article published in PMI's PM Network magazine.

Program Management -- Turning Many Projects into Few Priorities with TOC -- This link will lead to a paper on the key attributes of a TOC Multi-Project Management environment. (Most projects are performed by resources shared with other projects. It can be deadly to ignore the resulting interactions, no matter how well you manage single projects.) This paper was originally presented at PMI's Global Symposium in Philadelphia in October of 1999 and is included in the proceedings of that conference. Audio tapes of the presentation are also available from PMI.

Project Portfolio Management - The First Cut is the Kindest Cut - One of the common problems faced by project-oriented organizations is having too many projects relative to their capacity. Therefore, one of the first things that needs to be done is to determine what can be done is to determine what should be done . . . and what should not be done . . .

Consumption of Effort and Conservation of Energy for Project Success -- This link will lead to an essay on the necessity for managing protective capacity in multi-project environments to get the most organizational throughput from the efforts of project resources.

Critical Chain Basics

A Critical Chain Schedule

Multitasking Multiplies Lead Time

Who is FP?
Web Log
You can reach Focused Performance at:
601 Route 206, Suite 26-451, Hillsborough, NJ 08844
Voice: 908-874-8664
Contact Focused Performance