If
you are responsible for a late and over-budget software
project you are by no means alone; software project overruns
are all too common. But
if serious problems have existed for quite a while and the
situation is getting worse, not better, you may have a
project catastrophe on your hands. At this point, there is no PMI, IEEE, SEI, or ISO rescue
process to follow, because these organizations essentially
offer preventive, rather than corrective solutions.
This article describes a ten-step process to
disentangle a software project catastrophe and get it back
on track.
In
Spencer Johnson’s “Who Moved My Cheese”, the
littlepeople keep coming back to where the cheese used to be
even though it’s not there anymore.
It’s a natural tendency to continue doing what we
did before even when, to an outside observer, it no longer
makes sense. This
behavior is quite common when projects get into trouble.
We keep plodding away at the project hoping that the
problems will go away and the “cheese” will miraculously
reappear. In
all too many cases, it doesn’t.
Just
as the smart thing to do when a ball of twine seems
hopelessly entangled is to stop whatever we are doing with
it (otherwise the tangle gets worse), so it often is with a
disastrous project; the longer we keep at it the worse it
gets. At some
point, we need to halt all activity and reassess what we are
doing.
Disastrous
software projects, or catastrophes, are projects that
are completely out of control in one or more of the
following aspects: schedule, budget, or quality.
They are by no means rare; 44% of surveyed
development organizations report that they have had software
projects cancelled or abandoned due to significant overruns,
and 15% say that it has happened to more than 10% of their
projects.
But
obviously, not every overrun or quality problem means a
project is out of control; so at which point should we
define a software project as a catastrophe?
What are the criteria for taking the drastic step of
halting all activities, and how do we go about reassessing
the project?
And, most importantly, how do we go about getting the
project moving again?
The answers to these questions are the essence of the
concept of catastrophe disentanglement.
<More>
