Signs of the Times

How to tell when your technology project is already a failure

Introduction

Nearly all business sectors are littered with the spectacular failure of
large technology projects and tech-related business ventures. In
hindsight these projects frequently seem to have been doomed all along,
and yet the course toward the inevitable disaster remained locked on.
Here we examine a short list of tell-tale signs that a technology venture,
organization, or large project is serious trouble; doomed to failure.

Staff Turnover

The most obvious symptom of an organization in serious trouble is staff
turnover. But not always in the most obvious way employees leaving the
company after shorter and shorter durations. A more subtle sign is what
occurs when a large project persists for too long with an unrealistic
schedule or requirement list.

The most experienced staff will almost immediately recognize the most
serious issues with a requirements list, the most serious bugs, and the
areas of greatest unanticipated risk. But the time at which fundamental
problems would normally be recognized and addressed will have long passed
as the project enters its most desperate and frantic stages. Staff which
understands issues and voices concern are normally part of the solutions.
In fact that is exactly what defines these individuals as experienced
veterans; they have solved difficult problems and know what to do.

In a
normal project, discovering and resolving challenges is exactly the goal.
But when things are really going deeply and seriously wrong, something
changes. Normal development processes break down and, when an
organization is in trouble, experienced voices are not seen as
constructive. Senior individuals will be relegated to routine or
insignificant roles, replaced, let go or otherwise removed from the scene.
Newer and less experienced staff will move into their place. Such
individuals will have the can-do attitude management will be looking for
at this point, but this won't mean the work actually can be done.
Mistakes will be repeated and wheels will be reinvented in great numbers.
In a normal project these are considered risks. But in an organization
that has become truly dysfunctional, reinvention from the ground up will
actually be desired and encouraged. Meanwhile, the fully valid concerns
of the senior staff will invariably become part of phase II.

Phase II

The organization has been engaged in frantic struggle to accomplish major
projects. Months and maybe year have passed yet unresolved design
questions, critical bugs and to be determines litter projects' status
reports. At this point management will begin to speak of Phase II. What
is happening is that failure has become so obviously unavoidable that a
way to establish a point of victory is desired. A subset of functional
requirements that appear to be achievable will become the focus, and other
issues will be pushed off to next year, or some similar mythical time when
everything is settled.

There are several problems with this. First of all, this is really a form
of denial in disguise. On the surface it may seem reasonable to scale
down expectations, create a near-term point at which victory can be
declared and table certain hard problems for later. This would seem to
allow the the staff to work with better focus and more breathing room.
However this is really a sign that certain aspects of the work are indeed
very difficult or have already spiraled beyond the grasp of the staff and
management. These very aspects of the work will nearly always be exactly
those that are critical to the project resulting in any meaningful interim
outcome.

Employees know this. They know exactly what aspects of a project are
critical. And they understand that the creation of phase II (or three or
four) spell ruin for the artificially declared interim victories.
The second problem with this phenomenon is a fallacy also related to poor
time management; the idea that the future will allow more time than the
present, since more of the tasks on the table at the present will be
completed in the future. In other words, this is the idea that there will
be more time available in the future and so some tasks can safely put off
to a mythical future when there will be time. Of course what really
happens is that new tasks are adding as time passes, leaving the net
workload constant. Phase II will never come.

The worst of worlds occurs under the pressure of the death march project
when the very tasks that are both critical and difficult are put off to a
vague future time that will never actually come to be. Time will be
wasted in the present building work-arounds for problems that have been
avoided, and the interim work is nearly assured to be unusable.

Bad Becomes Normal

Bad becoming normal is exactly what is happening as an impractical
workload persists and the future, where time allows phase II to begin,
never quite arrives. An unsustainable situation, that management somehow
forgets was supposed to be a temporary condition, becomes simply the way
things are day to day. When this happens, management will come to believe
that the project's state can maintain its level of effort as ordinary
work. This would be nice, but the catch is that the longer this situation
persists the greater all the problems explored here become, and a problem
of scale develops.

If bad becomes normal, then the judgment of project managers is colored by
the desperately abnormal state which they have actually grown accustomed
to. Really critical problems will start to seem like ordinary problems.
Ordinary problems are perfectly safe to put off to phase II. Or to, for
now swept under the rug.

The Bulge Under the Rug

When things are really going south the last thing management wants to hear
is that a significant flaw exists in the current course. A really large
project, as it plays out, is bound to turn up significant flaws in
third-party software, unexpected information constraints at key points in
a process, unexpected license costs and other problems, large and small.
And these problems will be ignored.

The strange thing about this is that the software business is accustomed
to such issues, normally. In any normal project, time is alloted to
resolve such problems in advance. Even informal project planning will
including a certain amount of padding in the expectations. However we are
not talking about typical projects. In very large, mission critical, long
term and especially complex projects, the importance of such speed bumps
tend to, erroneously, be diminished in importance in view of the vast
landscape of the work. They are swept under the rug.

The problem with this is that just because a project is large, it is no
less vulnerable to the smallest problem in any component. And the more
bumps are swept under the rug, the more stressed the project will
ultimately be, and the more certain failure becomes.

Under New management

Nothing obfuscates problems like hiring new outside staff, particularly
management, to supposedly fix things up. The effect of this is an
automatic fog of confusion created as a result of new managers members,
with no historic knowledge; Rehashing already tried and rejected
approaches, Asking the question about already documented issues,
Introducing new, and almost always inferior, tools, misstating and
confusing the project's problems and status up the chain of command.

They net result of all this is nothing more buying time. The organization
collectively postpones having to deal with the reality of the situation
while the new staff comes up to speed. Problems that fall out are easily
attributed to a learning curve rather than to fundamental troubles
actually ailing the organization. At least for awhile... Eventually, in
many cases, the new staff is scapegoated for the projects failure. And
meanwhile, precious time is wasted that could have been spent on finding
real solutions to real problems.

Conclusions?

All of these scenarios have common threads, and those general symptoms of
impending failure are another way to look at them. They all involve a
sort of procrastination, buying time, and putting off the inevitable
through delaying tactics, smoke and mirrors, red herrings and other forms
of fog. In addition, perhaps the most interesting point to make about
these situations is that, to one degree or another, those in decision
making positions must realize the gravity of their situation in order to
be motivated to set up these scenarios in the first place. This is
remarkable. Projects have found themselves in the state of inevitable
failure for a very long time. And we know it. And at some level we know
it while failure is occurring. And yet, we do nothing.