What I Did Right

I set up a project office and applied a rigorous management process. I refocused each development team on one of the new objectives and made sure they understood clearly what was expected of them. This eliminated any duplication of work as well as confusion that had been caused by different teams working on the same system features due to poorly defined objectives and lax project management.

I facilitated several sessions where the company's developers and people from the software vendor pointed fingers. I cut through the excuses and double talk on both sides and got them to own up to their faults. I negotiated an arrangement in which the software vendor sent a group of experts out to the company's office to work alongside the development teams.

We had regular project meetings and frank discussions. We got issues out into the open, resolved them and moved on. I watched progress like a hawk, and when an activity started to lag behind schedule, I got personally involved. Deadlines were sacred. The teams worked long and hard.

Under my leadership, the developers delivered the system on schedule. There were still some problems, but the experts from the software vendor kept tinkering with the code and felt they could fix them. The decision was made to demonstrate the system at the trade show.

It worked better than it had before but still failed to generate much enthusiasm. System response times had been improved by more than 50 percent, but that meant it still took five to 10 minutes for some reports to run. And customers still questioned the validity of certain report results.

Why Things Went Wrong

A few weeks later the project was finally shut down. For months afterward, I asked myself what I had done wrong. Then I realized I had made the same mistake Bebe used to make. Even though she was full of energy, there was no way she could retrieve something that was not there. I had tried to retrieve a project that was not retrievable. My leadership skills were not to blame.

The project was bound to fail because the strategy driving it was not viable; scrapping the legacy reporting system in favour of some leading-edge software was a mistake. In my eagerness to start leading, I had failed to acknowledge something we all know: that leading-edge software requires a lot of testing and tweaking. That makes it risky to use for a critical project.

If I had this project to do over again, I would build only new features with the new software. Existing features and reports that already worked would stay on the mainframe. Version 1.0 of the new system would be delivered fast and cheap because the only development would be to create new features, not re-create existing ones. That strategy - combined with good leadership - would deliver success.

Mike Hugos is the former CIO of Network Services and the author of two books, Building the Real-Time Enterprise and Essentials of Supply Chain Management. He can be reached via www.michaelhugos.com