CIO

Why Leaders Fail

Experience has taught me to look at the factors shaping a situation before I leap in, particularly whether the strategy being employed is right for the goal I am trying to accomplish. For in the service of flawed strategy, even great leadership will fail

If you're heading in the wrong direction, every step you take will be wrong

Whether leaders are born or made, I do not know. What I do know is that if you are a leader, you feel your pulse quicken when you see the opportunity to create order from chaos and rally people to achieve an important goal. In such situations, I find myself so eager to charge in that I'm reminded of the black Labrador retriever my family had when I was in high school. Her name was Bebe.

On walks with Bebe all I had to do was lift my arm with a ball in my hand and she'd get so excited she could hardly contain herself. She wanted so much to charge off and retrieve it. Sometimes I would only pretend to throw, but Bebe would race off anyway, looking for whatever she thought I had thrown.

It's good to feel excited when an opportunity arises that calls for your leadership. But I have learned to make sure there really is a stick or a ball out there before I charge off. Experience has taught me to look at the factors shaping a situation before I leap in, particularly whether the strategy being employed is right for the goal I am trying to accomplish. For in the service of flawed strategy, even great leadership will fail.

The Eager Leader

This lesson became apparent to me some years ago when I was asked by a financial services company to review a high-profile system development project. The company had embarked on a project to re-create a financial reporting system that at the time ran only on its own mainframe. The goal was to rebuild the system using new software so that it would run on smaller and less expensive servers. Then the company would add new features and sell the system to many of its existing customers, as well as new customers.

But there were problems. The reporting logic used by the legacy system was not properly documented, so it was hard to re-create it in the new system. Also, the new development software was complex and required a lot of user training.

The first release of the new system often ran very slowly. It took 15 to 20 minutes to run some important reports. And customers had questions about the accuracy of some of the report calculations. Those customers who saw the first release made it clear that these problems had to be fixed.

After a two-week assessment of the situation, I made my recommendations. I advised that the company organize the project using rigorous project management and that it adopt a more specific set of system development objectives. Working with the development team leaders, I used these objectives to put together a high-level plan showing the tasks, time frames and budgets needed to finish the system.

My recommendations also addressed problems the company was having with the development software. This was the first time the software had been used for such a large system. Not only that, but the company's development teams were not fully trained. I recommended that the software vendor send its experts to work onsite with the financial services company's development teams.

The senior managers of the company were so pleased that the COO asked me on the spot to lead the project. I felt the adrenaline rush. "Yes!" I thought, "I can whip this project into shape. I'll show them what a real leader can do." The company needed to have its system ready to demonstrate at an industry trade show in three months. I charged in to make it happen.

Page Break

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