In IT, when things fail, they seriously fail. The truth is, as Roger A. Grimes points out in an article for InfoWorld, anyone who has ever been a part of a failing IT project can sense the impending doom well before it actually occurs. For those of you who still have trouble seeing the red flags of IT project failure, Grimes has created an 11 point list of signs to look out for:
- The project has launched without a senior buy-in
- No detailed project plan exists
- Meetings have been scheduled without concern for team member availability
- Users have had little (to no) early involvement
- The project targets the minimum specs
- Testing is an afterthought
- No recovery plan is in place in the event of failure
- Expert recommendations have been rebuffed without testing outcomes
- The go-live date is a weekend or a holiday
- Expectations have not been set
- Skimp on training
Senior buy-ins should most certainly not be undervalued. As Grimes notes, this is “a surefire recipe for IT project failure”:
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.
Grimes continues to say that beginning a project without a secure plan in place is equally as unwise as not waiting for senior buy-ins. Some ideas seem so wonderful initially that some individuals often forget important procedural steps such as basic planning. Grimes says that, as a general rule, if y our project is set to take longer than two weeks, you must have a detailed plan in place before beginning an work. Furthermore, when you are planning, make sure to take into account the availability of your team members. Your plan may look great on paper, but that doesn’t mean a thing if you don’t have the people to execute it properly.
In addition to basic project planning, you must also have a recovery plan in place just in case things don’t work out. The minute you start saying that “nothing can go wrong” is usually close to the moment when something huge does go wrong. This does not, however, mean you should plan on failing. You want to plan to succeed but be ready in the event that something unexpected occurs. Grimes does not expect that every IT project will fail, but he wants you to be prepared for the ones that do. You may not have control over every single aspect, but you do have the ability to avoid mistakes that will almost certainly doom your project.