|
The
Cascade Effect: Why Projects are late
According to our recent survey of project management professionals, nearly
80% of projects are completed late! Other surveys and literature paint a
similar picture. If we are going to do anything to address this situation it
is vital to understand the underlying causes of this situation.
Every experienced project manager knows that one of the greatest challenges
in projects, is uncertainty. It may take many forms—task variability, scope
changes, specification shifts, due date pull-ins, etc.—but things will
definitely change. What is not so well grasped is how uncertainty impacts
overall project performance, and how many conventional approaches of coping
with uncertainty unwittingly magnify the damage. At the root of this is the
mistaken belief that variation averages out in projects. If all projects
were linear, and resources were always available to work immediately when
required, gains and delays would average out.

Unfortunately most projects are not linear and resources are sometimes not
available when needed. This gives rise to what is known as the Cascade
Effect. A game (click to game) works
nicely to illustrate this phenomenon. While it is best to conduct the
exercise for yourself by clicking on the link above, let’s summarize the
outcomes here. The Cascade Effect can take three different forms:
1.
Integration dependencies

In this case the delay on the first task, 7 versus 5, was passed onto the
project as a whole, and the gain made on the second task, 3 versus 5, was
lost. This is the essence of the Cascade Effect, delays multiply and gains
do not add up.
2. Resource
dependencies within a project-
The blue resource must do both task A and task D, all tasks should take 5 on
average.


Even with only one delay in the activities, the blue resource delayed C’s
start and thus the project as a whole. The gains on B and D were lost, and
we delivered late, in spite of better than average performances.
3.
Resource dependencies across projects- Often a resource is needed on
more than one project—here blue is also required on the second project for
activity H. The first project should finish at 15, the second at 20.

With only one delay and an average task time again less than 5, both
projects are late by 2 (project one finishes at 17, project two at 22 due to
the late availability of blue at H). The delay one task of one project was
propagated to the rest of the pipeline, and none of the gains helped.
Obviously these are simplified illustrations. What would be the outcome of
increased complexity, as in real-world projects—with more integration
points, and resource dependencies? Obviously the Cascade Effect will be
magnified even further. There will be more opportunities for delays to be
propagated at integration points and across resource dependencies. You may
recall a time when projects were less complex, had more comfortable
timelines and had the luxury of more dedicated resources. As the pressure
increased we have been put increasingly in the position of competing for
resources, and doing more projects in less time. The impact has not been
additive, it is much closer to exponential—that is the Cascade Effect at
work.
It’s no wonder that every recent project study we have seen, including our
own, shows that most projects are either too long, delivered late, or both.
It also helps explain why we must re-schedule so frequently, add resources,
or reduce the scope of projects to finish on time. The job of managing
projects has not only become more important to business performance, it has
become vastly harder.
The Response to the
Cascade Effect
Intuitively, experienced managers recognize the Cascade Effect and try to
compensate for it. The most common method can be summarized as “trying to
meet every project commitment date.” Strategies might include more
micro-management, more frequent reviews, more intensive data collection and
reporting, increased discipline, etc. but they all focus on achieving every
task completion date. We know that delays will multiply and gains won’t add
up, so we try to insure we don’t miss a single date for a single task. If
nothing is delayed, there is nothing to cascade.
While conceptually simple and highly logical, this is practically very
difficult to implement. For starters, the sheer size and complexity of
projects makes this task a daunting one. How can we monitor and insure each
task is done on-time, every time, when there are hundreds or even thousands
of tasks involved? Administering such an effort is cost prohibitive to many
organizations. Additionally how do we cope with the fact that the work
itself is inherently uncertain by nature? Maybe no one has ever done that
activity before, as in the case with new research, so who is to say if we
have a reasonable task estimate. Yet we are still held to delivery dates to
meet business objectives and budgets.
Trying to Eliminate Uncertainty
The effort to increase the certainty of task deliveries creates an
interesting response from people. While business needs mandate the overall
timelines, if we hold people accountable to individual task deliveries,
there will be a natural push back. If we ask someone to commit to a task
duration, what kind of an estimate will they give? Naturally people will
work towards higher confidence level durations, especially if they know they
will be held to them. Experienced project resources understand that they
will be asked to multi-task on several activities at once, which will only
serve to further increase their estimates.
Of course adding up all of these high-confidence task estimates will create
overly long project durations. To meet business objectives management will
be forced to slash the times creating an arbitrary and resistance. Next time
times may be even more inflated to compensate in advance for management’s
cuts. It is the same thing that happens with budgets—argue for more, knowing
it will be cut.
Having fought for the additional confidence time, a very
interesting thing happens. If we have 10 days to complete a task we feel we
can do in 5, what is the urgency to start when the task becomes available?
There is little sense of urgency to start immediately! We know this as the
student syndrome, or Parkinson’s Law—the work expands to fill the time
available. There is a dis-incentive in some settings to finish early as
well—if we do, then the next time our times will be trimmed. But since this
approach does nothing to eliminate the inherent uncertainty in the work
itself—some tasks will still take longer than expected and initiate the
Cascade Effect.
Multi-tasking
Most people working on projects have more than one task on their plate at
any given point in time, sometimes quite a few more than one. As delays
cascade within and across projects, completion dates are jeopardized. This
results in considerable pressure on resources to shift their work
priorities. In fact it appears that the large majority of project management
effort is expended trying to set and adjust task priorities.
Resources are inevitably forced to stop what they are working on to work
another task. This creates significant inefficiencies and lost capacity,
especially in knowledge work, where time must be spent to re-orient oneself
to the task at-hand each time something is stopped and re-started.
Multi-tasking also magnifies the impact of the cascade effect by insuring
that a delay will be passed along.

In the example above without multi-tasking, Task A is complete after 10, and Task B
after 20. In the right-hand chart with multi-tasking on just two tasks, even
if there is no loss of efficiency (i.e. each task is still done in 10), Task
A is not complete until 15, insuring that all downstream tasks will also be
delayed by 5. The only thing assured by this is that the next tasks will
probably need to be re-prioritized as well, creating more multi-tasking.
Clearly these are
not problems with people or attitudes. Each of us would probably behave the
same way under the circumstances. The most common result is what we see in
reality: project plans are not short enough to begin with, and they still
manage to come in late (nearly 80% of the time!), or with a reduced scope.

The chart on the left illustrates the progression of the Cascade Effect.
Uncertainty combines with the complexity of projects to drive the Cascade
Effect which triggering multi-tasking and the overall performance issues
most of us see in project environments. These losses in turn magnify the
Cascade Effect and trigger a strong negative loop.
To what extent does this really happen in our projects? If our survey data
that nearly 80% of projects are late is even close, then it is widespread.
The only way out of the situation is to combat the Cascade Effect head on,
to dampen its impact and eliminate the resulting behaviors. Efforts directed
at better task discipline and meeting local commitments will do little to
help, and may exacerbate, the situation.
The challenge of delivering
more projects faster with less resources is not going to go away. Companies
and individuals who want to have success in this increasingly important
arena will be those who recognize and address the role of the Cascade
Effect. Now that the true cause of late projects is clear, how should we
deal with it?
Click here to proceed
|