11 signs your IT project is doomed

No senior buy-in, minimum spec targets, a 'nothing can go wrong' mentality -- here's how to sense demise before your IT project meets its ignominious end

The IT world is no stranger to projects that go down in flames. In fact, anyone who has had the unenviable pleasure of participating in a failed IT effort likely sensed its demise well before the go-live date. That sixth sense is invaluable in a competitive field like IT -- but only if it is acted on promptly and professionally.

Whether you're looking to avoid being saddled to a dud or to steer a doomed rollout out of the ditch, you must be able to recognize the signs of imminent failure well before a project comes apart at the seams. It can be a career-saver.

[ Learn the 8 biggest myths about managing geeks and how to repair dysfunctional IT relationships. | Also on InfoWorld: Beware the nine circles of IT hell, and steer clear of 20 common IT blunders and IT's 12 worst "best practices." | For the latest in technology news and analysis, sign up for the InfoWorld Daily newsletter. ]

We have gathered 11 red flags to look for in assessing IT project health. Be proactive whenever you encounter one -- or if you can, simply walk away. You career depends on it.

Red flag No. 1: The project has launched without senior buy-in

Want a surefire recipe for IT project failure? Dig in before you get top-tier buy-in.

Here's how it usually transpires: A strong personality in the company has an absolutely "terrific" idea or solution and begins to plan meetings and allocate resources without waiting to see if senior management agrees. Many of these projects proceed, until the point where real money must be spent; then they collapse completely. Often everyone on the project, except its originator, doesn't even know the project hasn't been approved, nor that budget hasn't been allocated.

To avoid being saddled to such a project, always ask who in senior management is a sponsor and what the budget allocation is. Don't accept answers claiming no budget has been allocated because people don't know what it is going to cost until the project is under way.

If you're a consultant being pulled into the project, make sure that significant budget has been allocated before you attend the second meeting. You don't have to know the final budget figure, but you need to know that senior management is serious in its support for the project and has some clue about the eventual cost. I've been on large projects that were obviously going to cost millions of dollars to solve, but management was thinking more in the few thousand-dollar range. Don't get stuck working on that project.

Red flag No. 2: No detailed project plan exists

Project-planning software can be complex and frustrating to use. The only thing I hate more than architecting a detailed project plan is being involved in a project that doesn't have one. Formal project plans force the project manager, and everyone involved, to consider all the necessary phases and steps, and the order in which to proceed. To paraphrase an oft-quoted line, "Failure to plan is planning to fail."

Any project with an estimated timeline longer than two weeks should have a solid, detailed project plan. If you are presented with a project that does not, create your own. Besides forcing everyone to consider all the tasks and tactics, doing so will force them to come up with realistic timetables. A detailed project plan is far better than your "best guess" or a gut feeling.

1 2 3 4 Page 1
Page 1 of 4
How to choose a low-code development platform