Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Having worked on a failed project is one of the few things that most programmers have in common, regardless of language used, industry or experience.

These projects can be great learning experiences, soul-crushing disasters (or both!), and can occur for a multitude of reasons:

  • upper management change of heart
  • under-skilled / under-resourced team
  • emergence of superior competitor during dev cycle
  • over/under management

Once you've worked on a couple of such projects, is it possible to recognise at an early stage exactly when a project is doomed to fail?

For me, a big sign is having a hard & fast external deadline combined with feature creep. I've seen projects which were well planned out and proceeding right on schedule go horribly off the rails once the late feature requests started to roll in and get added to the final "deliverable". The proposers of these requests earned the nickname of Columbo, due to rarely leaving the room without asking for "just one more thing".

What are the warning signs you look out for that set off the alarm bells of impending doom in your head?

share|improve this question

closed as too broad by MichaelT, GlenH7, Kilian Foth, Bart van Ingen Schenau, amon Aug 15 at 12:14

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

38 Answers 38

When management is too weak to say "No" to the business.

It leads to deadlines that will never be met, which leads to a lack of confidence in the IT department which leads to developers creating hacks (i.e. access db running on someone's machine...somewhere) which leads to a nightmare for IT when the 'critical system' has to be migrated which leads to...

share|improve this answer

Statistically a software project starting is a fair sign that it'll fail, as an overwhelming majority of them do...

share|improve this answer

The last professional project I worked on failed. One of the reasons I think it failed is a combination of all the other answers(especially no written spec). But I think the primary cause is a lack of decision making.

I was a primary developer and I'd ask my manager how he wanted some feature to work. His answer being "we need to collect more information from potential customers". So I worked on a different area of the project. Eventually it got to where I was rewriting components to be more clean because every other area of the project relied on unmade decisions. Near the end I began to make decisions myself. I was layed off due to the project being trashed about a month after I started making decisions.

I'll summarize a few things to watch out for:

  1. No written specification
  2. No decisions being made, or if they were being made they were only phrased like "we'll do it this way and reimplement it later the correct way"
  3. Several missed deadlines
  4. Inexperienced or understaffed team (This project was the first time I used .Net, and yet I was a primary developer!)
  5. Having to work in areas already complete because other areas need decisions made before work can begin. (of course, I'm talking refactoring for weeks just to stay busy)
  6. The idea that some new tool will shave off months of development time
share|improve this answer

When the programmers start to win the argument "The code is horrible, we need to start over from scratch." on any mature application.

You may think you can build it better, or understand the problem more fully, but you really don't. Oh, and all those ugly patches? They are fixes to real-world issues that you are going to likely re-introduce in the rewrite.

Plus, one day you are going to have to explain to the project manager why after 6 months of work you are almost up to 85% of the capability and 150% of the bugs the application had when you started out.

share|improve this answer
6  
Isn't this just a summary of the infamous Netscape rewrite? –  Jasarien Dec 13 '10 at 11:32
7  
2  
I disagree. There are certain dangers to rewrites (e.g. the second system syndrome), but if you know about these, a rewrite isn't more dangerous than any other green-field project. –  nikie Feb 5 '11 at 19:24
4  
Sometimes you need to amputate and replace with something that will make the app stronger, better, smarter. But the key word there is amputate, not kill and resurrect. –  Erik Reppen Jan 20 '13 at 16:40
1  
This may be largely true, but not strictly true. I underwent such a project about 9 months ago, and it was a success. Spent over half the time on it devising tests to prove it was correct and that old/new bugs weren't introduced to the new version, and found a bunch of new bugs in the existing one in the meantime. (Though, I suppose, this makes this answer true as a warning sign) –  Izkata Jan 21 '13 at 4:22

Paul Vick wrote an excellent post several years ago about black hole projects. I think all of the advice is relevant. (I've edited the items and summaries for length.)

  • Absurdly grandiose goals. Like "fundamentally reimagine the way that people work with computers."
  • Completely unrealistic deadlines. Usually this is because they believe that they can rewrite the original codebase in much, much less time than it originally took.
  • Unrealistic beliefs about compatibility. Like believing you can rewrite and preserve all of the little quirks without any extra effort.
  • Always "six months" from from major deadline which never seems to arrive. Or, if it does arrive, another milestone is added on to the end of the project to compensate.
  • Must consume huge amounts of resources. Usually by sucking the lifeblood out of one or more established products.
  • Involve using brand-new technology that has not yet been proven. As such, they get to flush out all the scalability problems with the new technology.
share|improve this answer

When management has decided, and does not provide room for adjustment, in all of the following:

  • Deadline
  • Scope
  • Allocated resources
share|improve this answer

a couple of points from a dead project i was part of:

  • The management doubles the team to finish faster.
  • the developers start "burying" bugs to meet deadlines, and although its obvious, its being ignored during code review.
share|improve this answer

I mentally translate "Everything is fine. We have nothing to worry about." to "We're all screwed" every time I hear it management say it. You usually hear managers throw it in incidentally in unrelated meetings ("Oh and by the way, everything is going fine. There's no reason to worry!"), but it's an even bigger red flag to have a meeting specifically called to say that.

I have yet to hear a manager say something along these lines and have it not turn out to be a lie.

share|improve this answer

First bad sign I can think of is when management is not willing to pass bad news up the chain or to the client in the hopes that it will go away - i.e. management by wishful thinking. I can't think of how many times, devs have proven they can't meet the deadline weeks or even months ahead of it and yet no one wants to tell the client. I've rarely seen a client who wouldn't push a deadline when there is genuine reason to when the need is explained well in advance; I've often seen a pissed off client when told the day of the deadline that it wasn't going to be met and that it wouldn't be met the next day either but two months down the road. At this point they, rightly I might add, question your processes - how come you didnt know this earlier. (True answer but the one we never give - we did know but we were afraid to tell you.)

Another sure sign that failure is coming up is to assign new developers to the hardest most complicated, most critical part of the process rather than the people who understand the current system already. Then don't watch them carefully to see if they really are getting work completed properly or have questions (BIG BIG RED FLAG if there are no questions). New employees need to be monitored until you know they really have the skills they claimed to have. I can still remember spending one painful summer redoing the work (already past deadline when I got it) of a new employee who got a critical piece of a project and told everyone everything was fine for months and then quit without notice one week from the deadline and nothing he did was usable.

Another sure sign of failure is when devs are working on pieces that depend on other things being done first and those things are not done or even started. If management can't get the work assigned in the right order, you are going down the tubes.

Of course feature creep without pushing the deadline back every time is one of the most common signs things are going to go bad. You add 20 hours of work to my plate, the deadline gets moved by 20 hours. If it doesn't then the project will fail, guaranteed.

share|improve this answer

Projects that are kind of ready for production, but features keep being added.

Long development time without clear commitment for release.

share|improve this answer

Developers Running Wild on the Range

This has happened when you realise that other developers (or, unfortunately, you) have developed a component that varies significantly from the design, and that this isn't picked up up until well into system/UAT testing. I'm not talking bugs; I'm talking about significant system components are missing features or have unasked for functionality and are never going to pass UAT without significant rework. This issue indicates that:

  • Your quality system is broken; why didn't the developer concerned pick up on the issue in the design/implementation phase. Wasn't the code per reviewed/inspected? Why did the unit and integration tests not pick up on this? If you don't have some sort of consistent unit/integration testing in place, you're screwed.
  • Your project manager/technical lead aren't in control of their development team. If they can't get the developers to deliver what is required, they will never be able to deliver a complete solution.
share|improve this answer

See this succinct article: When IT Projects Go Right.

An absence of any of the elements stated in the article should set alarm bells ringing:

So make sure your project has all of the following, if not then you should be concerned:

(to quote the above article:)

  1. "The first is that they are based on a clear vision of what is to be achieved."

  2. "The second characteristic concerns the support and commitment of the different parties involved across the business, especially senior management."

  3. "Third is an understanding of the problems to be tackled."

  4. "The final common characteristic is that sufficient resources and skills have been made available."

share|improve this answer

A project, and future projects are doomed when the company decides to write an in-house "framework" because all the available frameworks don't fit their need perfectly.

share|improve this answer

My first sign on one was when they asked how many hours of overtime we each would commit to for the next ten weeks and offered salaried workers a bonus for working said overtime based on the success of the project and meeting deadlines.

Other major signs I've seen: Requirements defintion goes over schedule and the end date is not moved. We were behind before we can even start. They took the time away from design, so we started with no database design and no site design but expected to deliver on time by, among other things, doing imports to tables not designed and created yet.

When items on the critical path are being done simultaneously instead of in order. (If I'm required to use tool X and programmer A is just starting to build it, it is going to delay my task.)

When managers are committing code on Thanksgiving.

When you start getting emails that have a datetime stamp of later than 11 pm and earlier than 6 am.

When every question about how to handle some complexity is met with the same answer, "Don't worry about that yet."

When they are still making requirements changes the day betore you go to QA or go live.

When you start having daily meetings that take several hours to discuss your lack of progress. Oh that would be because I'm in meetings all day. Daily 5 minute meeting fine, daily meeting that goes over an hour, not fine.

When the database team and the aplication team don't talk to each other.

When the client can't provide the promised information on time. Especially when those are data import files and you need that data in the database to check to see how the code is working.

When you consider installing a stop light outside some manager's office to let you know if it is safe to approach him that day.

share|improve this answer
1  
The kicker on your first paragraph is that, if the management is doing that, the deadlines are probably already doomed and the bonuses unattainable. –  David Thornley Dec 10 '10 at 19:10

I've been in three death marches in the last five years. Here are a few things that contributed to my gut feel of impending doom.

  • The company decides to have junior developers design and develop new features, and assigns more expensive senior developers to fix their bugs.
  • The company outsources critical software components to third-world companies that don't have the required domain expertise.
  • The crunch-time cycles come so close together that peoples' health is breaking down.
  • The pills your team lead takes to drug himself to sleep every night quit working.
  • The client sends change orders faster than you can analyze them.
  • You're supposed to deliver several years' work in a few weeks, but management refuses to do a feature freeze.
  • Your hardware suppliers are clearly having trouble delivering a workable product on schedule, and the decision-makers in your company won't consider any alternatives.
  • The prototype devices developers need so they have a ghost of a chance of meeting the probably-unrealistic schedule are taken away and given to top execs to make them feel good.
  • Week one: "Oh, crap, the code is buggy. Everybody quit doing new features and fix bugs." Week two: "Oh, crap, we're not going to meet the feature schedule. Everybody quit fixing bugs and write new features." Repeat indefinitely.
  • The development is done in one country, and QA is all done in another country half-way around the world, so a round-trip communication about a bug always requires 24 hours, and at least one of the people involved is discussing complicated technical problems in a language they're not proficient in.
share|improve this answer

You're "90% done", the delivery is next week, but it's ok because all you have left is "testing".

share|improve this answer
1  
Seems very funny now that you say it. Happened to me though. Wasn't funny at that time. –  user7197 Dec 10 '10 at 19:02
1  
It's funny how every schedule has testing as the last step as if testing won't find any bugs. If not, why bother with the testing? –  JohnFx Jan 20 '13 at 21:22

When the management pulls the project into different directions simultaneously and the carriage remains still.

I was once involved in a project managed by two guys. Either they didn't talk to each other or each one has some ego to resolve, but they were commandeering our work into opposite direction about each week or so. Didn't take long to realize there's never going to be any result. Gladly my participation only lasted a few months.

share|improve this answer
  • Everyone is physically and mentally exhausted
  • Customers / users are clearly unhappy either about timescales or what they're seeing
  • The originally beautiful design now feels compromised
  • You're resigned to shipping with some relatively significant bugs that you'd really rather fix but aren't going to be able to
  • You're remaining pride is in the act of shipping rather than what you're shipping - closer to a survivor mentality than professional pride
  • The team is scared that there are certain things that don't work and are ignoring those sections and hoping for the best because they're scared of what might be in there
  • Everyone is convinced that they've gone above and beyond (and they're right)
  • People are showing signs of burnout (general pessimism, disinterest, anger)

(Cribbed from Jim McCarthy's Dynamics of Software Development).

share|improve this answer

The most obvious sign is a high staff turnover. When everybody is looking for a new job, you probably should, too.

The other highly obvious sign is lack of progress. If a year has passed, and it doesn't seem like you are any closer to the target, you're doomed. This happens especially when requirements change faster than you can implement them.

share|improve this answer

One sure sign that I've seen in my career is when management starts talking about bringing in more bodies to make up time in the schedule. I've never actually seen more bodies on a project help.

share|improve this answer
4  
I once had a manager who wanted to bring in a front end web coder to a project (the right decision) but because someone else on the project had gone long term sick wanted hit written into the new guy's contract that he wasn't allowed to get ill. –  Jon Hopkins Dec 10 '10 at 14:36
1  
@Jon - That is sad... funny, but very sad! –  Walter Dec 10 '10 at 15:00

Among another signals, there is one important warning for me (maybe I'm wrong, and it is not common): double-digits in the minor version like "superproject version 3.16"

share|improve this answer

There are loads of symptoms (burn out, overtime, frustration, silence ...) but ultimately you know this is happening when release dates are starting to slip and you are no longer able to deliver the product as often as you are supposed to.

share|improve this answer
  1. When key developers leave and management doesn't care

  2. When key developers leave and none of the other developers care

Number one is usually indicative of managers who are severely out-of-touch with the team dynamics (who is the "10x super star", who are the decent programmers, and how they interact with each other etc).

Number two usually indicates severe lack-of-interest on the part of the remaining developers.

share|improve this answer

When a key developer on a project hasn't checked in any code for weeks and a serious milestone is coming up.

It was a contracting job and the more senior developer and PM on the job decided they wanted to team up to try to get a bigger cut so the other developer held 3 weeks of critical code hostage. In the end, we fired the incompetent PM (who had been spending 6 months putting the project on a course for ruin) and talked things out with the developer.

Suffice to say, the rest of the project was a masochistic death march, the spec freezing was delayed, the customer was given a bunch of concession features to make up for the terrible scheduling the PM left the project, and the quality of the project suffered all around because of it.

The PM even had the nerve to fly down for CDR (Critical Design Review) only to ditch the meeting with the client and throw a hissy fit. When he demanded that his travel expenses be paid for under the project he was politely told to go fornicate with himself.

I can easily identify with at least 5 of the other answers found here that affected that project. In short, I learned a lot of hard lessons on my first serious coding project.

share|improve this answer

When non-technical managers start insisting on making technical decisions that they are in no way qualified to make. Big, big red-flag!

share|improve this answer

Cowboy coders, big egos and management acceptance thereof

share|improve this answer

The first time someone, usually management says "we don't have time to .."

Usually preceding something that we don't have time not to, like documentation or code reviews (which statistically find and correct more bugs that anything else, including all forms of testing)

share|improve this answer
8  
got a reference for that? it'd be great ammo to use... –  Alex Feinman Dec 30 '10 at 14:27
1  
@Alex Feinman: IIRC Code Complete contains lots of references to statistics like these. –  nikie Feb 5 '11 at 19:20

Let the customer, marketing or management pick a date and then try to work backwards to an imaginary schedule

share|improve this answer

If the project plan calls for a single iteration of design, development, testing and deployment - the classic waterfall - for a project longer than 1 month, I'd run a mile.

You don't need to be fully agile, but having short development cycles allows you to demonstrate progress to everyone (customer, management and developers themselves) and cope with changed requirements when the inevitable happens.

share|improve this answer
6  
There is nothing wrong with waterfall when it is used correctly. Unfortunately it is never used correctly :) –  adolf garlic Sep 9 '10 at 12:52

Bored team members.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.