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.

August 2006