Every one of us has passed a highway accident and exclaimed, "Man, I hope that doesnt happen to me!" In our professional lives as technology leaders, we tend to say similar things when we regard IT debacles from afar. With so many bad examples out there to learn from, why do so many IT system implementation accidents continue to happen?
I dont profess to be an IT project management guru with all the answers about guaranteeing 100 percent success for each project implemented. As both a CIO and a consultant, I have had great system successes and difficult project problems. But those experiences, combined with my own forensics regarding well-known system implementation debacles, have led me to some precepts that I follow for every IT project—no exceptions.
First, end-user sponsorship and leadership are essential. If the project is not accepted by users, if it is not championed by one or a group of them, your best efforts will go nowhere.
Second, you need experienced IT project leaders. Ideally, youd have an IT leader who has been there before, someone who wont freak out when things go awry. This person has to have the people skills to instill a sense of confidence in others and get them to go the extra mile without being a dictator.
Third, measure your progress. Conduct a pilot program that tells you whether to go ahead with the project, and once you start, you need reasonable milestones by which to measure progress.
Fourth, find or develop a power-user guru. Other users will look to this person as a source of information and assistance. Theres also a good chance they will ask themselves, "If so-and-so can be such an expert, why cant I?"
Fifth, make sure your vendors share your pain. Let them know ahead of time that you will be depending on them to stick with you. Structure your contract with them to include the achievement of milestones. Suggesting milestone delay penalties will often create more realistic vendor project timelines.
Sixth, know when to apply CPR and when to pull the plug. Set up a decision point that occurs before youve committed too much time or money to turn back. If you have not achieved certain milestones by the time you reach this point, you may need to cancel the project. Upper management should understand that this is not a sign of failure.
Because you have set the point in advance with clear parameters, you will avoid making an emotional decision or a decision based on incomplete information, which would be difficult to substantiate.
Follow these guidelines, and your chances of arriving safely with a successful IT project are very good.
Scott Langdoc recently joined AMR Research as director of the Retail Practice; previously, he was a general partner at the strategic consultancy InfoMatrix. Find him at firstname.lastname@example.org. Send your comments to email@example.com.