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?

  • Robert Glass wrote "Universal Elixir and Other Computing Projects Which Failed". Published in 1977, the book was a collection of columns he'd written earlier, each one looking at a project that failed, looking for the reasons behind the failure. The book makes an EXCELLENT list of warning signs. Commented Jan 20, 2013 at 11:44
  • 1
    Two articles - Project pathology and (the over hyped) Chaos Report. Give Death March a good read if you are after a book.
    – user40980
    Commented Jan 21, 2013 at 3:12

38 Answers 38


Heroic Coding

Coding late into the night, working long hours, and clocking lots of overtime are a sure sign that something went wrong. Further, my experience is that if you see someone working late at any point in the project, it only ever gets worse. He might be doing it just to get his one feature back on schedule, and he might succeed; however, cowboy coding like that is almost always the result of a planning failure that will inevitably cause more of it soon. So, the earlier in the project you see it, the worse it will eventually become.

  • 13
    The only excuse for pulling an all-nighter is to address a SPECIFIC issue for a SPECIFIC inflexible deadline. Maybe it's just me, but code I write at three in the morning when I'm grouchy and sleep-deprived tends to look bloody hideous viewed in the cruel light of day.
    – BlairHippo
    Commented Sep 9, 2010 at 14:08
  • 5
    Well, the other excuse it being a student. Poor project planning is par for the course then. :) Commented Sep 9, 2010 at 14:59
  • 20
    Oh, Christ. College. I remember sitting in front of my terminal as the sun rose, shoving *'s and &'s more or less at random in front of the variables in my C++ code in the hopes that the damn thing would start working. Not a part of college I miss.
    – BlairHippo
    Commented Sep 9, 2010 at 15:04
  • 2
    Earlier this year we had a project like that - one guy was regularly working until 2am and I was starting a 4am. We got the job done, though, despite the ridiculous time-scales imposed upon us (we'd been committed to being complete by a legislative deadline). We're still tidying up and refactoring now! Commented Sep 21, 2010 at 19:18
  • 3
    I'm going to put my karma in danger here and point out that "heroic coding" is a late indicator. Projects get into trouble long before they get to the phase where "heroic coding" starts happening. There are usually lots of early trouble indicators, that pop up long before coding gets under way in earnest. They are, unfortunately, all too frequently ignored. Robert Glass has written extensively on this subject, in "The Universal Elixir", and in other books. Ignore him at your peril. Commented Jan 20, 2013 at 17:42

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.

  • 9
    Isn't this just a summary of the infamous Netscape rewrite?
    – Jasarien
    Commented Dec 13, 2010 at 11:32
  • 9
    – Jeremy
    Commented Dec 15, 2010 at 3:39
  • 5
    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
    Commented Feb 5, 2011 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. Commented Jan 20, 2013 at 16:40
  • 3
    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
    Commented Jan 21, 2013 at 4:22

To me the single biggest problem, and one you can spot immediately, is when business considers written requirements as a waste of time.

So basically; No Written Requirements

It's the kiss of death.

  • 3
    Or worse, written requirements that no one reads. In fact, I've been on projects where extensive requirements were written and never shown to the programmers.
    – JohnFx
    Commented Sep 8, 2010 at 22:23
  • 1
    @Adolf Garlic - Written requirements won't ensure your on time or on budget, but you'll never meet expectations if expectations are not communicated, do not have all the gray areas nailed down, and are constantly changing (your mental ideas will change). Commented Sep 9, 2010 at 15:14
  • 5
    I once had a Business Analyst tell me requirements were not needed. Just what is the job of a business analyst again? Oh yeah to write requirements! We would get requirements like make this work like hkjk.com does.
    – HLGEM
    Commented Sep 10, 2010 at 14:54
  • 2
    If you're developing for a custom product for a single client, sure. But if you're writing the next version of Powerpoint or the next version of an in-house software system, I don't see the point. You will always learn more about the requirements during development (e.g. that some requirement isn't useful and another isn't feasible). I'd rather use that knowledge and change the requirements during development than releasing an inferior product.
    – nikie
    Commented Feb 5, 2011 at 19:17
  • 1
    @nikie - I'm not saying the requirements should be static, and never change. I'm saying you should write it down to prevent mis-communication and prevent ideas from changing in peoples head over time. If the requirements should change, then change them, but keep the current requirements written down. Does that make sense? Commented Feb 6, 2011 at 16:02

A new tool as a problem solver.

When people start planning to use unfamiliar tools, I don't mind, but I keep my eye on it. When they start planning all the advertised benefits of those tools into the schedule, I get worried. Fun examples:

  • We can shave a month of the schedule because we're going to try using an object oriented language (even though all we have are c developers).
  • We'll try out this new scrum thing- that'll fix all our process problems!
  • I know it's halfway through the project, but what if we changed ORMs to something new?

New technologies and practices are great, but you almost never get all the benefits out of the gate.

  • 3
    I was once on a project that had two forks due to two interfaces -- desktop and handheld gadget. Time estimates were based around the notion that we could use these shiny new "EJB" things to reuse model-layer code between the two. Unfortunately, the database was such a horrific rat's nest that all data plucked out of it had to come from specific carefully-constructed SQL queries; fully populating the beans would have been too brutal a performance hit. When it turned out that (surprise!) the desktop version needed more data than the handheld version, the timeline went STRAIGHT to hell.
    – BlairHippo
    Commented Sep 9, 2010 at 14:03
  • 2
    "Wonderful! Now that we've salvaged the unit testing framework, we can start cutting time from that overlong QA phase!"
    – Arkaaito
    Commented Oct 13, 2010 at 8:40
  • ha ha ha. Excellent. +1 for the new tool will solve all my problems. Commented Feb 5, 2011 at 10:38

Management Disconnect

When those responsible for deadlines, features, staffing, etc get disconnected from the people responsible for delivering the project. This can lead to:

  • Feature creep when the customer is talking with someone who doesn't understand feature cost
  • Man-month syndrome, where new developers are thrown into a project late enough to be more of a hinderance than a help
  • Unrealistic deadlines, created by people who have to deal with the business consequences of deadline decisions but not the implementation consequences.
  • Products that don't solve the problem, when customer-dev communication is hindered by management in the middle.
  • Poor risk management, where potential problems aren't communicated early enough between devs and management.

So, when it looks like management is uninterested in the project, is communicating poorly, isn't listening to the customers, or isn't listening to the dev team, run for the hills.

  • +1 for your first item. I've been a customer in the scenario you mention and it's bad for everyone (no-one wants an unexpected bill, and no-one want s argument over paying it). Commented Sep 9, 2010 at 8:56
  • +1 amen. Been there, done that, don't care to be in that position again. Commented Sep 11, 2010 at 10:49
  • +1 for the fact I'm living with all of these bullets (except maybe the 4th).
    – AShelly
    Commented Sep 14, 2010 at 6:00
  • Great answer. Even if you didn't bother to elaborate, and you simply put 'Management Disconnect', your answer would have been worth a +10.
    – Jim G.
    Commented Nov 10, 2010 at 23:44

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)

  • 8
    got a reference for that? it'd be great ammo to use... Commented Dec 30, 2010 at 14:27
  • 1
    Call it "Mawg's first law of software management"
    – Mawg
    Commented Jan 18, 2011 at 9:57
  • 2
    @Alex Feinman: IIRC Code Complete contains lots of references to statistics like these.
    – nikie
    Commented Feb 5, 2011 at 19:20
  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.


The 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, developers 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 didn't 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 developers 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.

  • Yep, news gets better as it travels up :) Commented Apr 9, 2012 at 16:17

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

  • thanks. Alwasy remember, you can have it quick, cheap or working ... choose any two
    – Mawg
    Commented Jul 8, 2011 at 0:25

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...

  • Nothing makes scope creep worse than 'concession features' because the PM screwed up when he setup the milestone dates. Commented Sep 11, 2010 at 10:48

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.

  • 6
    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. Commented Dec 10, 2010 at 14:36
  • 1
    @Jon - That is sad... funny, but very sad!
    – Walter
    Commented Dec 10, 2010 at 15:00

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


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.

  • 1
    The highest turnover rates I saw were on two projects. One was a stable project that kept going, and one was a known doomed project at a bank. I've never been as happy to be unemployed as those two. Commented Dec 10, 2010 at 19:12

Bored team members.


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

  • 2
    Seems very funny now that you say it. Happened to me though. Wasn't funny at that time.
    – user7197
    Commented Dec 10, 2010 at 19:02
  • +1000 happens where I work all the time T_T
    – Songo
    Commented Aug 28, 2012 at 13:17
  • 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
    Commented Jan 20, 2013 at 21:22
  • Don't worry, "the customer will test it for us" :-(
    – Mawg
    Commented Dec 17, 2015 at 13:24

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.

  • 6
    There is nothing wrong with waterfall when it is used correctly. Unfortunately it is never used correctly :) Commented Sep 9, 2010 at 12:52
  • @adolf - I was thinking of a single pass through the waterfall. Multiple mini waterfalls are probably OK.
    – ChrisF
    Commented Sep 9, 2010 at 13:05
  • imo, Agile is just series of waterfalls. Very few can do waterfall correctly, ergo ..
    – Mawg
    Commented Sep 10, 2010 at 2:29
  • @mawg - my point was about a single long iteration being bad whereas a series of short iteration (however they are managed) is better.
    – ChrisF
    Commented Sep 10, 2010 at 7:51
  • 1
    Reminds me of a project developing electronic things where no prototypes where scheduled in... A sure sign of impending disaster. Commented Feb 5, 2011 at 10:42
  • 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).

  • +1 for "You're remaining pride is in the act of shipping rather than what you're shipping". That is so so true (although I only saw that in my managers. We developers knew what went out the door... feet first)
    – user7197
    Commented Dec 10, 2010 at 18:54

Cowboy coders, big egos, and management acceptance thereof


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.

  • 2
    The kicker on your first paragraph is that, if the management is doing that, the deadlines are probably already doomed and the bonuses unattainable. Commented Dec 10, 2010 at 19:10
  • 1
    @David Thornley, yep that's exactly it.
    – HLGEM
    Commented Dec 10, 2010 at 19:14

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.

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.


I think it's generally easy to spot a failing project when the deadline is approaching. Like you said, feature creep combined with a set-in-stone deadline is a sure way of killing a project.

The key however is to spot a failing project way in advance. I think the only real 'sign of doom' in this case would be a complete lack of the definition of 'when are we finished'. Unless we know this at the offset we're doomed for failure IMO.

  • 1
    aka "definition of done", as agreed by both IT and the Business Commented Sep 9, 2010 at 12:52

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.
  • I'd give you a million for that last point.
    – HLGEM
    Commented Apr 9, 2012 at 17:19

For me, it is when those that are responsible for the feature set (aka managers, product owners, customers...) stop caring or seem to have a hopeless air about their answers. Questions about features are meet with apathy and discouragement. It is clear that they have lost investment or confidence in the project.

This happened for me when a project I was on had the "upper management change of heart" hit it. I was asking questions about how it should work and all of a sudden no one had a real opinion.

A little while latter the project was canceled and all the beautiful code I had written was scrapped.


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.

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.

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.

  • LOL, I worked a manpower study like that although even worse as the two leads were both trying to have an affair with the same woman. If Bill said yes, then Bob said no and vice versa, worst project I ever worked on. I begged to get reassigned.
    – HLGEM
    Commented Apr 9, 2012 at 17:13

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.

  • Lolx! So true; the "you may have heard rumo(u)rs ..." meeting.
    – Mawg
    Commented Feb 8, 2018 at 12:29

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

  • 1
    I think that's a start-up statistic, not necessarily a general software project statistic. Commented Jan 20, 2013 at 16:45
  • 2
    Here's one reference randomly Googled which seems to suggest it's not limited to start-ups. Also see Mr. McConnel's excellent Rapid Development for further gems on the topic. Commented Jan 21, 2013 at 14:25

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.

Good, that's a relief!

I think not having daily, helpful management oversight is key to spotting creep. I believe that if you have the right information, if you get your devs to input the right information, then you can spot slippage quite quickly. What you do with it after that - well that's more politics and less dev...

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