Signs of a Doomed Project
In this tongue-in-cheek list of 101 ways to know your software project is doomed are some instances that may be a little too close to home, such as “Every bug is prioritized as Critical” (#23), "No meetings until 10 a.m. since we were all here until 2 a.m.” (#32), and of course, “You have been 90 percent complete 90 percent of the time (#100).”
More seriously, the early signs of a project in trouble include a lack of interest, chronically poor communications, a no-bad-news environment, and people attending meetings but not paying attention. Other signs are that stakeholders don’t attend meetings, developers leave the project, or questions keep arising about daily expenses or resource allocations.
More readily measurable signs include lots of overtime, diversion of resources, failure to meet milestones, and frequent or major scope changes. None of these signs necessarily means the project is en route to failure, since every project has ups and downs. But they certainly indicate the project needs close attention.
In addition, projects may be doomed early in the effort if you start without a clear list of what will be needed to complete it or you require individuals to make progress on all their active tasks, rather than complete one at a time. And here’s a biggie: Needing management to mediate every change or disruption in the project because everything looks like an emergency.
Given the number of software projects that fail or don’t meet expectations, the odds are good that you’ll be involved with at least one. If there’s any hope of fixing the project, the first step may be the toughest—getting everyone to admit the project has a problem.
Unfortunately, if your project tanks, your career could be damaged. So be alert for signs of trouble.
If, despite your best efforts, your project fails, try to avoid pointing fingers at others. Instead—and this takes courage and is not without risk—acknowledge your own mistakes and aim to restore your reputation by stating what you’ll do differently next time.
Don’t put off informing clients about a potential project failure; there’s little to gain by delaying. Describe the situation in non-technical language (and preferably face-to-face, not in writing). Offer your recommendations and the options, if any, along with their cost and schedule implications. If there are salvageable elements from the project, explain how they can be completed and implemented.
If it’s deemed necessary to pull the plug on the project, create documentation as well as your lessons learned so your organization doesn’t repeat the same mistakes. By doing so, failure can be the first step in the success of the next project.
