I'm often asked what the CIO's role should be in keeping projects out of trouble. This is an especially challenging task in large organisations where the CIO must contend with multiple layers of management. CIOs want to talk about projects and programs and PMOs and dashboards and measurements, but the most productive time is often spent talking about the CIO's role in making an IT department successful. Should the CIO's job be to influence desired outcomes, or should the CIO personally take control of major initiatives? Part of the answer to that question often lies in determining the type of CIO a given company employs. For the sake of argument - and this certainly is not a scientific assessment - let's say there are three types of CIOs: strategic, transformational, and operational. Each has unique characteristics, traits that give way to specific questions. Will the CIO's style mesh with a particular project? Does his or her experience fit the organisation's size and structure?
What's more, all projects pass through different phases, and each stage typically requires a different approach from IT leadership. Look at it this way: even a great basketball team won't be a champion for long if it faces each opponent with the same defensive scheme. Rather, the team must constantly adjust to opponents' strengths and weaknesses.
I'm reminded of a project several years ago in which a large magazine publisher, a firm whose business was heavily focused on giant databases and had a Harvard-educated, collaborative and strategic CIO. The company came to us seeking help in rebuilding its databases of roughly 25 million customers. The aim of the project was to make the databases more flexible and able to perform at a higher level, but at that point, the company was already $100 million and a couple years into the project and not really making any progress. IT wasn't delivering on stated goals, and there were countless questions raining down from senior management about the project's viability.
We ultimately found that the stated goal of the project was too elegant, too perfect, and not very practical. The schedule had several issues of its own, as did the architecture. But the conclusions we reached and the subsequent recommendations started me thinking about how such a CIO could let a project get so far off track. I realized that maybe the core problem was a gap between the type of CIO and the skills required at that point in time. This particular CIO was a very strategic thinker, but he was "stuck" in the middle of the transformation phase of the project.
Since that project, I've learned that CIOs, and their related skill-sets, need to match the problems at hand. For example, CIOs who are more comfortable in a strategic planning environment could be a good match for organisations that are looking at the big picture, rethinking their platform, rethinking customers, rethinking the information they need, and trying to move in a different direction or expand significantly.
After decisions are made and a roadmap is developed, that same company may very well need a CIO who is more transformational-a "change agent"-someone who can rally the troops and the entire organisation. These CIOs are good communicators, willing to roll up their sleeves, dig into the details, and truly drive organisational change.
Once that change is made, however, an operational component becomes the top priority, and a "get your hands dirty" CIO mindset is often the best means for carrying the project across the finish line. At this point, a project calls for a "value manager," someone adept at running the technology organisation in the most cost-effective way possible, focusing on getting the highest value out of the previously enacted change.
If a company's CIO happens to have a good skill and style match for its current slate of projects, what happens when the enterprise shifts into the next stage-away from the CIO's dominant area?
One CIO with whom I'm currently working has held CIO positions at three different companies over the past five years. Her style is intense and creative, and she sees her role as a disruptor and seeks to turn the enterprise on its head to get real transformational value from IT. Unfortunately, her style can create relationship challenges along the way, and she tends to leave when the company's needs shift. I would say that in the end, she puts firms on a better path then when she got there. In fact, she actually considers herself more of a contractor than an employee.
This is but one example and it obviously isn't relevant to all, or even the majority, of CIOs' situations. From a career management perspective, however, it can be eye opening to think about your core skill-set-strategist, transformer or value manager-and then consider what your company is trying to do.
It's important to note that a CIO of one type can, in fact, be successful in the other phases if he or she recognises the potential skill (and interest!) mismatch and gets the right lieutenants in the right roles at the right phase of a project. As G.I. Joe used to say in his public service announcements, "Knowing is half the battle." Unfortunately, there's often an expectation that the CIO can do to it all, and that belief can cause some of the mismatch problems.
So, ask yourself: Is there a match? If not, what can you do about it?
Chris Curran is Diamond Management & Technology Consultants' chief technology officer and managing partner of the firm's technology practice.