Secret CIO: Four Steps To Make Big Projects Work

Years ago, I became saturated with evaluating the various project methodologies touted as protection from cratering the company and destroying my career. Call me skeptical, but I wonder how many success stories hyped as being the result of adhering to a specific procedure really happened that way. Project histories, like kitchens, tend to be cleaned up when shown to guests.

I've never had much faith in paint-by-the-numbers project planning and implementation. Perhaps my attitude comes from the fact that there are so many nuances and special considerations in dealing with the myriad of people who have to work together to make a modern systems project succeed. Like most CIOs who've survived a long time, I have my own checklist of what to do and what to avoid. It's heavily modified based on circumstances. There are, however, a few basics that I try to follow. They are Detection, Preparation, Implementation, and Reflection.

Detection is making sure the problem is clearly identified. One of our executives wanted a new billing system in a plant where payment was lagging because it took three days from order fulfillment to mail a statement. Instead, we changed the due date from 30 days after billing to 30 days after shipping and solved the problem. My guess is that, like us, Congress would function a lot better if its leaders did a little more detection and a lot less posturing.

Preparation is figuring out what to do and how to do it. Most of us handle these mechanics fairly well. What's really important, though, is to make sure that everyone involved signs off on what's to be done and his or her role in it. People are more likely to support something they understand. When it comes to systems, if you can't explain it easily, don't try to implement it.

Implementation is always tricky. Keep it as simple as possible and have a rollback strategy. It's how you react to unanticipated issues that makes the difference between success and failure. Don't demoralize a team working long hours by letting critical decisions hang. Make sure everyone's in the loop and has skin in the game. When we installed our ERP system, a manufacturing VP told me days before the board meeting that he'd try to achieve his part of the benefits, but couldn't promise that he'd be able to. I said, no problem, I'd pull the project from the agenda and explain why. He called me a nasty name but got back on the bandwagon.

Reflection is valuable. We learn a lot after the project is over about what we might have done differently. I've found it useful to have a written audit and then sit down with all involved to figure out how things could have been improved. When I first took the CIO job at one company, I was appalled at the finger pointing and backbiting in the systems group. In frustration, at our first post-project review, I finally had to yell, "Stop dwelling on blame and focus on the problems. I don't care who's at fault, I want to know what we'd change if we had it to do over!"

I've gotten some good ideas from formal methodologies, and perhaps your experience is unlike mine, but I've never found a cookbook that would let me do my job without a lot of sweat, toil, teamwork, and personal involvement at all levels.

Herbert W. Lovelace shares his experiences as CIO of a multibillion-dollar international company (changing most names, including his own, to protect the guilty). Send him E-mail at [email protected].

To discuss this column with other readers, please visit Herbert Lovelace's forum on the Listening Post.

To find out more about Herbert Lovelace, please visit his page on the Listening Post.