Home‎ > ‎

How to Tell that Your Project is a Failure


Introduction


All sectors of the economy from government to military, and to business, are littered with the spectacular failures of large technology projects and ventures. In hindsight these projects frequently seem to have been doomed all along.  What’s more, often this view is not limited to hindsight as individuals, it turns, involved at the time know full well that failure was certain.  And yet the course toward the inevitable disaster remained locked on. Here we examine a short list of tell-tale signs that an ongoing technology venture, organization, or large project is serious trouble; doomed to failure.

Staff Turnover

First and foremost, 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 recognize the most serious issues with a requirements list, the most serious bugs, and the areas of greatest unanticipated risk, or unrealistic expectations. But the time at which fundamental problems would normally be addressed will have long passed when the project enters its most desperate and frantic stages. Staff which understands issues and voiced concern are normally part of the solutions, at earlier stages. In fact that is exactly what defines these individuals as experienced veterans; they have solved difficult problems before, and know how.  But if issues are not discussed at early stages, and thus surface later, then a different dynamic sets in.

In a normal project, discovering and resolving challenges is exactly the goal. But when things are really going deeply and seriously wrong, it changes. Normal development processes break down and, when an organization is in trouble, the cries of 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.  This is staff turnover generated by management, whose motivation has become control of the message, not defining and resolving technical challenges.

As this turnover progresses, newer and less experienced staff will move into the roles that should be occupied by those that have done the work before. Such new 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 an in-house invented wheel, rather than some well established conventional approach,  is considered a risk. But in an organization that has become truly dysfunctional, reinvention from the ground up will actually be desired and encouraged - it buys time. Meanwhile, the fully valid concerns of the senior staff, that should have been addressed at the very beginning, will invariably migrate to become part of “Phase II”.

Phase II

When the organization has been engaged in a frantic struggle to accomplish major projects, months and maybe year have passed with as 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 really happening is that failure has become so obviously unavoidable that any possible way to establish a point of victory is now critical.  A subset of functional requirements that appear to be achievable becomes the focus.  Other issues are pushed off to “next year,” or some similar mythical time when everything will be settled.

There are several problems with this. First of all, this is really a form of denial. 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 are exactly those that are critical to the project resulting in any meaningful interim outcome, and exactly the issues that were mishandled in the very beginning.


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) spells 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 be put off to this mythical future when there will be time.  In reality, the future always, mostly, resembles the present.  What really happens is that new tasks will be added 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 have been put off to a vague future time that will never actually come to be. Time is wasted in the present building work-arounds for problems that have been avoided, and the interim work is nearly assured to be unusable.  Oh if only your future selves could speak to your present selves...

Bad Becomes Normal

Bad becoming normal is 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.  Management comes to believe that the project's staff 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 other problems explored here become, including the myth of time available in the future, and staff turn-over.  A problem of scale develops.

If bad becomes normal, then the judgment of project managers is colored by the desperately abnormal state to which they have grown accustomed. Really critical and exceptional problems will start to seem like ordinary problems.  And of course 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 i
t 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.  Ignoring problems and downgrading the roles of naysayers has become standard operating procedure.

The strange thing about this is that the software business is accustomed to such issues, or should be.  In any normal project, time is allotted to resolve problems in advance.  Even informal project planning will including a certain amount of padding in the expectations. However we are not talking about normal projects now. 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.

The net result of all this is nothing more buying time, which is more money spent.  The organization collectively postpones having to deal with reality 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 plaguing the organization.  At least for awhile...  Eventually the new staff is scapegoated for the project’s failures.  Meanwhile, precious time is wasted that could have been spent on finding real solutions to the still remaining, very real, problems that the now long gone senior staff recognized in the first place.

Conclusions?

These scenarios have common threads, and those general symptoms of impending failure are the best 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.  They actually know the situation.  

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.