Failed Project: When to call it

failureproject-management

A few months ago my company found itself with its hands around a white-hot emergency of a project, and my entire team of six pulled basically a five week "crunch week". In the 48 hours before go-live, I worked 41 of them, two back to back all-nighters. Deep in the middle of that, I posted what has been my most successful question to date.

During all that time there was never any talk of "failure". It was always "get it done, regardless of the pain."

Now that the thing is over and we as an organization have had some time to sit back and take stock of what we learned, one question has occurred to me. I can't say I've ever taken part in a project that I'd say had "failed". Plenty that were late or over budget, some disastrously so, but I've always ended up delivering SOMETHING.

Yet I hear about "failed IT projects" all the time. I'm wondering about people's experience with that. What were the parameters that defined "failure"? What was the context? In our case, we are a software shop with external clients. Does a project that's internal to a large corporation have more space to "fail"? When do you make that call? What happens when you do?

I'm not at all convinced that doing what we did is a smart business move. It wasn't my call (I'm just a code monkey) but I'm wondering if it might have been better to cut our losses, say we're not delivering, and move on. I don't just say that due to the sting of the long hours–the company royally lost its shirt on the project, plus the intangible costs to the company in terms of employee morale and loyalty were large. Factor that against the PR hit of failing to deliver a high profile project like this one was… and I don't know what the right answer is.

Best Answer

The concept of failure is really a business related call. If a commercial project costs more than the money it brings in, that project would be considered a failure. If an open source project cannot build a community around the code to help maintain it and care for it, that open source project failed.

I've been involved in projects were we delivered everything on time and within budget, but the business development team failed to get follow on work. From a business perspective the project failed, although what we delivered was well received and liked.

In situations like yours, the company has to make some hard decisions. If they want the project to succeed, then they need to learn some lessons:

  • Failure to plan appropriately will cause undue stress on your team, and ultimately lead to a failed project
  • A stressed team will retaliate with high turnover--and eventually you won't be able to get good people to join the company.
  • Emergencies happen, but find what caused the emergency and change your practices to avoid that emergency in the future.

Any company that doesn't learn from its mistakes will repeat history quite often. I would take that as a sign that it is time to find another company.

Related Topic