What are the warning signs of impending doom to watch out for on a project?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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)

Answer 7

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.

Answer 8

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.

Answer 9

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

Answer 10

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

Answer 11

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.

Answer 12

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

Answer 13

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.

Answer 14

Bored team members.

Answer 15

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

Answer 16

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.

Answer 17

Cowboy coders, big egos, and management acceptance thereof

Answer 18

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

Answer 19

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.

Answer 20

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.

Answer 21

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.

Answer 22

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.

Answer 23

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.

Answer 24

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.

Answer 25

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.

Answer 26

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.

Answer 27

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

Answer 28

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.

Answer 29

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.

Answer 30

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

Answer 31

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

Answer 32

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.

Answer 33

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

Answer 34

Well, the best way to answer this is with an example:

Bob starts a project by coming up with a genius idea. He begins by creating a plan for the software project that begins with specific steps that need to be completed. However, the steps do not lead to the end-result, but only go a portion of the way there.

In the end, the project fails because the plans were incomplete. It's not so much lack of planning as it is insufficient planning.

Answer 35

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.

Answer 36

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

Long development time without clear commitment for release.

Answer 37

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

• Deadline
• Scope
• Allocated resources

Answer 38

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"