Much has been written about governance applied to information technology. Proponents of best practices and process models like CoBIT, ITIL and CMMI, the Governance Institute and even IBM Corp. all claim to have developed the best governance model.
As CIO or IT manager, you know that you can improve the way IT is performing by adopting all or any of those models. But how do they fit together? And more to the point, how do you get any of them implemented without risking a major failure or worse?
The first step towards a successful IT governance implementation is to get our definitions straight. Let it be our mantra that “governance” is different from “management.” Governance is about making strategic decisions and about identifying those who can and have the right to make those decisions. Management is operational. It is about planning, organizing, directing and controlling the human, financial and material resources to implement those strategic decisions.
Although there’s a clear distinction between governance and management, they are still connected. Strategic decisions can only be made if there is evidence and confidence that they can be implemented successfully and if the proper controls are in place to monitor the performance of IT.
The good news is that ITIL and CMMI are good management practices and CoBIT has a strong framework for control.
Aligning your goals
Looking at it with binoculars, you can see on the not-so-distant horizon that implementing an IT decision-making structure will bring you closer to aligning your IT plans with the business goals.
Getting started with a few quick wins will bring everyone on board, including your own staff. You probably already have in place a few pieces of the puzzle. They just have to find their place in the overall governance picture.
The second step is to decide what strategic decisions need to be made. Peter Weill and Jeanne Ross, in their excellent book, IT Governance: How Top Performers Manage IT Decision Rights for Superior Results, have identified five domains that, in any small, medium or large IT organization, require high-level decisions: IT principles and strategies; architecture; applications; infrastructure; and investments.
Principles and strategies go hand in hand. Principles are high-level statements that set the foundations that will support your strategies. An example of principle might be that, in your company, all IT resources and assets will be under the control of the CIO or the manager of IT. No business unit is allowed to recruit its own developers or support staff. Your strategy will then be focused on delivering IT services to the company’s divisions and branches.
It could be a pretty big culture shock and you will need strong executive support to enforce that principle and, when the rubber hits the road, to get the funding to deliver those services.
Ditto for decisions related to the enterprise architecture, if you are at that point in getting all your ducks in a row: business, information, applications and technology architectures aligned.
Difficult decisions
Decisions about applications are probably the most difficult to make. Someone somewhere has to decide if the company should acquire a new CRM system or spend the money on revamping the old budget forecast system. Should IT decide what is more important? Not necessarily the best idea. What about those other projects waiting in queue? Will a bully barging into your office raise the odds that his not-so-strategic project will get your attention?
Decisions about infrastructure are easier to make. Most of them involve computer stuff that is right up your alley. But are they really yours to make? If you expand the definition of infrastructure to include the levels of service of the help desk, is it still only an IT decision?
Finally, investment decisions must be made. If you have to go in front of senior management each year to beg for money only to keep the lights on with little hope of anything for new projects unless the business is on the verge of an IT disaster, then you need help.
And this is precisely what implementing an IT governance model in your organization will do for you. It will help you make the difficult decisions without feeling that you bear the whole world on your shoulders alone. But more, you will get executive support. They have no choice because they are the ones who will have determined your priorities. And, by the way, the auditors will love to report that IT has a governance model.
Sidebar: What makes a successful governance model?
1 It must be simple. Flashing the CoBIT model in front of senior management or your own staff as your first kick at the can will get you nowhere. For now, you have to be able to draw your governance model on one page and be able to explain it to your boss, your peers and your staff. In turn they have to be able to explain it at the family dinner table. Remember that complexity increases the risk of failure.
2 It must be inclusive. There are two types of people: The ones who decide and the ones who recommend. While, for instance, the CIO might be the one who has the power to decide about migrating to Vista, the smart CIO will get input from a user advisory committee, to muster their full support of the strategy that they have endorsed themselves. Too many chefs might spoil the sauce, but we do not want to make enemies by leaving key stakeholders out of the loop.
3 It must be formal. Geeks deciding to convert the entire infrastructure from Microsoft to Linux over the weekend and telling you all about it on Monday morning because “there were a few glitches” is not how a mature organization works. But getting your best people to approve changes to your technology architecture is serious stuff. You need discipline. Start by scheduling regular meetings. Demand that well-researched proposals be sent in advance for the group to study before a formal presentation is made too seek approval. Record minutes of the meeting, decisions and action lists.
4 It must be decisive. If governance is about making decisions, then those who are granted decision rights must be able to make those decisions. In one organization that shall remain nameless, the CIO chairs a committee of representatives from the business units. The committee has the authority to approve or to reject projects proposals for systems development based on a number of criteria: value to the business, feasibility, cost, risk and business impact. While the good news is that a high-priority approved project will become a high priority, the bad news for a business manager who does not show up at the committee’s meetings is that the decisions of the committee are final. The IT department will not write a single line of code unless the project has received approval.
5 It must be flexible. If your governance structure is composed of committees, then be ready to
