Failed Project: When to call it?

Question

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.

Answer 1

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.

Answer 2

Failure is anything that can describe a goal not being met.

In short, when you define your goal, you also define what is a failure in that context.

In the literature you mention, a failure is a project that is over budget and/or didn't meet the deadline.

This doesn't mean the product will not be used. This means it has been developer with much more pain, money and time than expected.

When you should cancel a project? When you are sure that any new second spend on it will provide less value than its cost.

It's called the sunk cost dilemma.

If you are interested by the subject, I recommend you Death March, from Edward Yourdon. A really great book.

Answer 3

There are many different ways that a project can "fail." And quite a few I've worked on have been failures:

1. The shrink-wrap software had to be rewritten to meet new statutory/regulatory rules. The mismanagers chose to avoid hiring new people to help with the workload, and especially with the skills we all lacked. The product didn't have the new required features (it had to have electronic filing made a certain way) and had to be pulled from the market. While this product produced about 5% of our office's revenues, a similar regulatory change was coming that affected the product that produced 60% of our revenues. The developers took it upon themselves to learn the skills needed, but the mismanagers chose to wait until it was almost too late in order to start to implement the required changes. We had 3 years warning that these changes were coming as we tried to bid on the server side of this regulatory change - and corporate rightly forbade us from submitting the bid. Our mismanagers chose to make us wait until 8 months before the switch-over before we were allowed to work on it.

2. The project was already over budget and overdue when I was brought on to help get it finished. The managers several levels higher decided that the sunk costs were already too high to make the required ROI for the project so the project was cancelled and everyone involved laid off. Working there for 1 week before the group was all laid off (including me) was the shortest time I've ever worked at a place.

3. The internal project took so long to complete that the project sponsor had purchased off-the-shelf software (in this case Microsoft Office) and wrote their own VBA to get their job done. The development team leader kept promising the moon and refused to listen in the managerial meetings that the project was already canceled. 6 people worked for about a year completing a system that was never going to be used.

Answer 4

The only project that I've been involved with either as a programmer, or part of the PM team was Ricochet, which went belly up with Metricom's bankruptcy. There were literally thousands of contractors across the country working on it. When their CFO resigned, the project just literally stopped. Furniture started being removed from offices as the liquidation people descended.

To many of us, the applicable term was 'unemployment', but Lame Duck would be an adequate description. Often, key people will need to stay on until an autopsy / liquidation process has been completed, much like some politicians who remain in office for a few months to finish out their term prior to their successor coming in.

As Otávio Décio indicated, I have not seen a project fail to the point of abandonment since the dot com boom.

Answer 5

This is a common problem, also mentioned in some books about project management. No project ever "fails", even if all it delivers is a "what-to-avoid-next-time" experience.

IMO, a project is a failure if not doing it would have been cheaper. For example, if the product has an expected lifespan of 5 years and saves the company 100K p.a., then it is a failure if it took more than 500K to make it. (I'm cheating with the interest rates here to make it simpler). Some people claim that every project with an overrun in cost and/or time is a failure, but IMO this definition makes little sense as it focuses too much on correct estimates and planning.

Answer 6

I also never participated in any "failed" projects - but plenty of projects with cost and time overruns. I believe the issue is that neither party - the client or the contractor - wants any project to be considered a failure for all kids of reasons, including liability.

So I think when you hear "failed IT projects" in reality these are "projects that went outside their bounds, either in time or in budget".

After all - how many people or companies you know would come clean and say "we failed" ?

Answer 7

Yet I hear about "failed IT projects" all the time.

What were the parameters that defined "failure"?

It's a pejorative term often used when the project changes. Many people like to label change as "failure". I don't know why, but it makes them somehow more powerful or important to have identified a failure.

Some projects really are lost money and nothing of value is created. But those are rare.

Even a project which never delivered working software is a learning experience in what not to do. It created value. It created unanticipated value, so it can be labeled any way that people want to label it. "Failure" is as good as "Learned what not to do" in some circles.

The real question is "was the value commensurate with the cost"? And even then, the value may be so hard to measure that the answer is entirely political or subjective.

Does a project that's internal to a large corporation have more space to "fail"?

Perhaps. "failure" is a political term. Any change to schedule, budget or scope can be labeled as "change" or "failure". They can also be labeled as "learned something important about our team's inability to write a web server". Or, even more positively, "learned what skills we need before we try that again."

External projects often have more oversight from sales and delivery folks, accountants, and project management. Internal projects often have less oversight.

When do you make that call? What happens when you do?

When it's expedient to have someone pressured out of the organization because you disagreed with them. You label their project as "failure" and get them reassigned so you can have different people.

The only way that a project can be a total failure is criminal fraud -- where there were no lessons learned, nothing can be improved, and the criminals were sacked and jailed, leaving the organization clueless as to what happened.

Otherwise, there is always some value.

The real question is "was the value commensurate with the cost?"

Answer 8

So your company who was billing this work out, worked you and 5 other people to death for 5 weeks. They still make their profit off of your hard work. I hope you got something, because job security is nothing these days and there is plenty of work. (Shameless plug contact me if you need work and are a competent programmer, I know of several places that desperately need help).

That said, if you company actually had to pay you for all that work and the 41 hours before go live, then they would have LOST money.

Your management needs a sit down and an explanation that if this occurs again you are to be paid. They need to make better judgement as to when to pull the plug.

Answer 9

I too, like many responders here, have been involved in several large projects that ran over time and budget - one by more than half a decade. The worst scenario (the half-a-decade one) involved some gratuitous Mythical Man Month insanity, as well as epic scope creep. That said, it was never abandoned, and they are starting to take on some clients now. But the initial expectations (clean, well designed replacement for an old, outdated system) and relatively modest budget and timeline - have long been shattered now.

Also, unlike most people here, I've also seen a project totally fail - to the point of abandonment. The final nail in the coffin came in early 2010. This was the scenario:

Smallish company (around 30 people) doing custom ERP solutions for medium-sized businesses. They had a few relatively lucrative logistics installations with Australian mining companies and a few trucking outfits in the US. The platform was a custom in-house framework built on top of J2EE. Actually relatively customizable and well done - simple new installations could be built up fairly quickly, but it didn't scale too well when the level of customization required was very complex (as was the case for some of their biggest clients).

Long story short: some of their biggest, highest profile installations ran way over time and budget, and it seems that the market didn't appreciate that, so they couldn't get any more clients. The company was basically a one trick pony, doing little more than this ERP system, so once the cash flow from that dried up, they went out of business and the system was abandoned (the GFC might have played a part in it too though).

(I only worked there for 9 months - in 2004/2005. They basically hired and made redundant as the workload came and went with new installations - instead of hiring contractors - which is quite dodgy. In hindsight, the failure was probably more to do with a flaky business model than with the technology.)

Answer 10

If the project was deployed in such a way that the original request was fulfilled I would call the project successful. To me a failure would be rolling out an application that was then universally rejected by the end users because it did not fulfill their needs. Or, worse yet, the project is terminate before a product is actually deployed to the users and their need is unfulfilled.

Generally if a company is working for an external client, it's not their decision to pull a project as there might be contract issues involved (i.e. breach of contract payments) or a major PR hit, as you noted. In some cases, if there is a breach of contract penalty, the cost of finishing the contract is several times less than that of breaching the contract and losing a token amount of money is the preferred option.

In the long run, a company can work to improve employee moral to make up for a crunch time during a project or replace employees that left because they were pushed to hard, but it can sometimes be impossible for them to recover from major project failures (i.e. look at game companies that have failed to deliver products on time that have gone bankrupt).

Answer 11

When the business case no longer holds up.

That's the measure that Prince2 (the Project Management methodology) uses and it makes a lot of sense to me.

Essentially it says at the end of each stage of the project, or if a project falls outside certain tolerances in certain areas (schedule, cost, quality), there should be a review of the business case. At that point you go over anticipated total costs and realisable benefits based on what you now know and if the project no longer stacks up then it gets killed.

The issue with this for many projects I've seen is that they don't set out what they're trying to achieve in any detail up front, which makes it very hard to assess (a) whether that's still realistic, or (b) whether the costs you're going to expend in getting there are worth it. In these situations the best thing you can do is to produce a business case at the point you become suspicious to allow you to understand if your suspicions are correct.

Putting together a business case doesn't have to be a major undertaking, a couple of sides of A4 will do. Costs are relatively easy (as a rough measurement a programmer costs: (annual salary * 2) / 250 per day for Europe, probably a bit less for the US as benefits are lower and the average number of working days higher which are the inputs here).

Benefits are harder but if you estimated pessimistically as accurately as you can, then if the business case doesn't stack up (normally measured as it must make an x% return on it's costs over 3 years where X is likely to be 50% or so) you can look at it in more detail. Don't forget license and hardware costs (even if you're using existing hardware as it means it can't be used for anything else once you've nabbed it) and on-going support.

But a lot of this isn't programmer stuff, it's stuff the PM and the business should be doing with input from the whole project team.