Several years ago, I took on a project from a client who had given me pretty steady work for 10 years preceding. The idea of the project was to create a framework for the client’s future software development, bridging between their existing technology and the platform to which they wanted to move: Microsoft’s .NET Framework. We laid out a strategy, and I started work on prototyping and designing.

Since then, at least two generalized alternatives to this problem have emerged (both of which I helped develop), but at that time we were breaking new ground. Scoping the project was difficult, and it dragged on and on. Several months into it, we identified performance issues that added more time to address. Eventually, the client decided that the effort and expense wasn’t going to yield the result they wanted, and they scrapped the project.

My relationship with the client remained friendly, but they haven’t used me for anything since. I can’t say that I blame them, if they were half as disgusted by that project as I was. I still feel a little sick in my stomach when I recall it. But a greater tragedy would result if I committed it to the depths of Lethe, because failures can teach us more than successes, if we’re willing to learn from them.

This project exhibited these four signs of imminent failure that I should have noticed.

1: The project is running longer than a year.

Except in rare cases, if a project extends over more than a year, it has already failed. What’s so magical about that year boundary? Funding usually follows an annual cycle, so it may be difficult to keep resources dedicated for longer than a year without delivering something. But it’s mostly psychological. Project success depends more on human factors than on anything else. When the calendar rolls around to the same place where you began the project, and it’s not even close to being finished, few of the participants can avoid thinking “This project will last forever.” Their focus begins to shift from “How do we get this done right?” to “How do we get out of this?” (or worse, “How do I get out of this?”). Once people start looking for the exits, you can count on a rout ensuing.

2. The project is monolithic.

You can more easily avoid failure if your definition of success is easier to achieve. When a project must accomplish every one of several difficult objectives, it’s set up for failure. Rather than adopting a pass/fail mentality, organize the project into discrete objectives, each of which may stand alone as a successful operation. By eliminating interdependencies, you can reap the benefit of five successes out of six attempts, instead of losing everything because of one failure. You can also decide in advance to drop one or more of those objectives if you get into a pinch, without sacrificing the entire project. Furthermore, if you deliver early and often, the client can provide feedback that may result in course corrections before you get too far along to change directions.

3: The project is not unified.

At first, this may seem to contradict reason number two, but what I mean here is that the project needs one team working together. Multiple teams, especially if they’re in different locations, require extra attention to coordination and communication. I do almost all of my work remotely, so that arrangement certainly can work, but the connection to the rest of the team is often the weakest link in my projects. Of the failed projects in my history, lack of adequate communication and coordination has always played a significant role in their demise.

4: The project is not the #1 priority.

A successful project may start out as a “when you have time to look at this” activity, but at some point it has to become your primary focus or it will never get done. A project doesn’t become a #1 priority for a consultant until it also becomes a #1 priority for the client; if that doesn’t happen, then eventually the client will decide to stop pouring money into it and divert those funds towards more pressing needs.

For the project in question, I should have insisted on breaking it down into smaller chunks that could have been delivered no more than two months apart — preferably less than a month apart. I should have hounded the client for feedback on those deliverables, and I should have refused to put more time into the project until I received it.

This experience made me a better consultant, but I still regret disappointing my client. Memories of that project have often haunted my occasional relapses into the Impostor Syndrome. I have to remind myself that even the most successful people must endure occasional failure.

Have you ever experienced any spectacular project failures? What did you learn from them?

Additional resources about project failures on TechRepublic