Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

11 signs your IT project is doomed

Roger A. Grimes | May 7, 2013
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.

With few exceptions, projects should plan for failure and, when the pain is too much, allow for failure back to the old system. Sure, failure is embarrassing and no one wants to plan for it. But not being able to recover during an extended service outage is usually career-ending.

Letting senior management know that you had a backup plan and followed it to a tee when the turds hit the fan is a way to win accolades. Letting an extended downtime event go on and on as you explain to management that there is no way back and the forward path isn't looking so pretty is a much different conversation. Plan to succeed, but have a plan for failure as well.

Red flag No. 8: Expert recommendations have been rebuffed without testing outcomes

There are people who ask for expert advice and listen, then choose a different path -- every time. Then they complain when something doesn't work right.

Don't be that person. Don't let that person make big decisions on your team. It's all right to ask for expert advice, only to do something different. That's human nature, and it's often the sign of a good leader. Just don't do it compulsively. More important, if you go against recommendations and the outcome doesn't work, don't blame the consultant.

Deviating from vendor or consultant recommendations means testing the results of your change before go-live. Even if the vendor or consultant agrees with your deviance from their recommendation, make sure the change is tested. Many projects have failed because project leaders "made a few small changes" that left vendors and consultants shaking their heads in the background. You'd be surprised by how many experts remain silent in the face of a very strong customer that seems to know better than the experienced consultants. Everybody wants to be friends. Everyone hopes it works out.

Don't hope. Test. And listen to your experts most of the time.

Red flag No. 9: The go-live date is a weekend or holiday

Many project leaders plan go-live events for the weekend or holidays because of lower chances of service disruption to employees or customers. While laudable, these windows also tend to be the times when tech support is harder to reach. You may have your primary vendor onsite, but third-party tech support may be closed or on call (and not returning calls in a timely manner), and the same may be true of your team. Talking to your best database troubleshooter over the phone while he's on vacation with his family is never optimal.

Red flag No. 10: Expectations have not been set

When a new system is going in to replace an old system, it's helpful for everyone to understand the new expectations. How is the new system going to act? How are transactions and transaction times different? Who do end-users call if they have problems? How long is the go-live troubleshooting team going to be onsite? A new system will always frustrate people, but if you set realistic expectations and give people accelerated support options, problems tend to go away faster and you end up with more satisfied customers sooner.

 

Previous Page  1  2  3  4  5  Next Page 

Sign up for MIS Asia eNewsletters.