How Do You Know Your Application Development Project is in Trouble?

I wish I was asked this question more often before projects get in trouble. There are many application development projects that go well in this world.  But as a company that gets called regularly to finish a project that is almost done, we see our share of projects that are completely off track.  Every time we hear someone say the project is pretty close to done, but the programmer got another job so we are wanting you to just finish it up, we cringe.  Only once in 15 years has the program been anything but a disaster when we have taken it over.  It is stunning and amazing to me how many projects go over budget and fail to get even 50% of the intended results. Worse, by the time it is discovered that these failing projects are on the wrong track, so much investment has been made, it is nearly impossible to bring yourself to see the truth.

So what are the warning signs of a problem project?

1.  Analysis and specification documents either do not exist or lack detail.

A specification for a program should be extremely detailed before you start writing any code.  There should be few, if any, statements of a general nature such as, keep information about customers inquiries.  A statement like this should immediately bring questions such as what is a customer inquiry? Does it come from the web? phone? email? fax?  Is any question at all from a customer considered an inquiry?  Do you need to know what time? Do you need to know who answered it?  Do you need to know what answer was given and when? How are you going to use these records?  There are likely to be thousands over time, how will you look them up?  If you do not have documentation that answers questions at this level of detail, you have a high risk project.

2.  The coding was started months ago and you get a question that is so basic you wonder how they could possibly not know that.

By the time coding starts, the team should know more about your business than you do, or almost so.  While this is not a red flag, it is a warning to look deeper at what is going on and make sure the coding and project team really knows what they are trying to build.

3.  The project is late and you are being asked to put more programmers on.

The first request like this might not be the death nail, but if the team size starts increasing and there is not a clear concise plan for deliverables being met, then you can definitely say you have a problem.  If the original project was anticipated to take one main programmer and you have to add a programmer that was not planned, you can anticipate 50% of that programmers time on additional overhead.  So if the project has 1000 hours left, adding a programmer risks making it a 1250 hour project.  A second programmer on a 1000 hour project, run the risk of increasing the overhead time by more than they will help the project finish.  If you started with 3 programmers and suddenly you have 8 and your Project Manager does not have clear and quick deliverables that are testable, then you have a HUGE yellow flag that is most certainly really red.

4.  The project has been nearly complete, 80% or 90%, for months.

You are in trouble, the current team cannot help you, stop!

Application Development is a high risk endeavor.  Done correctly, it can give your company a competitive advantage that can have a very high reward for a very long time.  Done incorrectly and it can sink your company.  There are processes that lessen the risk including great specification writing and analysis, project management, risk management analysis, and others.  Even these must be handled with judgment and skill.  Without them, failure is very nearly certain.