How to Get the CEO’s Buy-In to Reduce the Scope of IT Projects

    Slide Show

    A Three-Step Plan for Successful Change Management

    I had an interesting email exchange last week with William Corcoran, MIS Director at J.C. Taylor, a specialty automobile insurer in Upper Darby, Pa. We were discussing some of the challenges confronting senior IT executives, and we kept coming back to the idea that reducing the scope of IT projects might be the single most effective way to manage the complexity of running an IT organization. The inherent problem is that reducing the scope of a project has potential political ramifications, especially when the reduction doesn’t mesh with the CEO’s vision of what he wants for the company.

    To address that problem, Corcoran used an aviation analogy. Consider the training that pilots receive in crew resource management—the notion that first officers are trained to be prepared to challenge the captain when it’s warranted in a given situation and captains are trained to encourage such challenges. “Countless airplanes have crashed where the crew failed to challenge the captain over fear of the captain’s sheer authority,” Corcoran noted. If you think of the CIO as the first officer and the CEO as the captain, the idea is to challenge the CEO so the project doesn’t crash and burn. When you consider how much time and talent large projects consume, reducing that load can make for a much smoother flight.

    Corcoran listed some of the key benefits of reducing the scope of an IT project:

    • Reduced complexity
    • Reduced cost
    • Reduced staff hours
    • Improved maintainability
    • Reduced project risk quotient (PRQ)
    • Reduced implementation time
    • On-time deployment

    Corcoran pointed out that you can’t reduce the scope if you don’t know what the scope actually is:

    So, clear requirements are important. But we go a step further. I send out a document that explains what that system will not do. I make sure to receive confirmation that everybody understands and accepts both the requirements and the limitations. This avoids surprises. Fred Brooks tells us that programmers are optimists. Since many CIOs were once programmers themselves, they are optimists, too. Optimists, by their nature, don’t see limitations. That’s why it is so important to pass around the limitations document right along with the requirements document.

    Corcoran also addressed handling feature creep:

    Feature creep is best dealt with by expressing all add-ons and change requests like you would a restaurant menu. Anything can be done in IT—it’s just a function of time and money. Thus, there is no such thing as a feature that can’t be added. If you explain that the feature will cost $125,000 in labor, add four weeks to the project and increase the PRQ to .9, then maybe the CEO decides that feature can wait. But if you are afraid to convey the complexities of a feature because it might send out a message that your system or your team can’t handle the task, then that’s a clear sign you are not communicating.

    Corcoran stressed that you need to speak the CEO’s language:

    Many CEOs have a penchant for numbers. If you tell the CEO that your life will be made more comfortable and the project will go more smoothly by reducing the scope, you aren’t likely to get very far. But if you explain that the project can be implemented 22 days earlier, and along with the reduction in time, labor and risk, you will sell 15 percent more widgets in the following quarter, the CEO’s ears will perk up. My point is you have to argue more than just time, labor and risk reductions. You can exponentially increase the merit of your argument by remembering to include the value of turning that project on as a whole. That can almost always be quantified and presented in a language familiar to the CEO. This often shifts the question of reducing scope from one of careful review and consideration to an instant no-brainer. The trick is to show how the reduction in scope will help to get the project turned on, and to argue the value of turning it on as it appeals to the CEO’s self interest.

    I’ve just recently come to realize the real power of reducing scope—I’m very fortunate to work for a CEO that understands how important scope reduction is. If more CIOs can get their CEOs to understand how much power they really have in this area, they might find the CEO to be their best friend in helping them complete their projects on time and within budget.

    Latest Articles