The demand for IT governance is increasing at a rate faster than the capability to govern IT is maturing. While greater scrutiny on spending and increased business regulation ratchets up pressure, IT management struggles even to come to consensus on a definition of what governance is and is not. Governance initiatives are typically little more than bureaucratic "bolt-ons" to monitor employee activity. The results speak for themselves: although it consistently appears as a top-10 priority for CIOs, only about 10 percent of CIOs report "very effective" governance, and nearly 60 percent report neutral or outright ineffective governance practices.[1] To make governance effective, there must be a simple yet complete definition of governance that is results-oriented, inclusive of all IT activities, and non-burdensome to execute.
Trust, But Verify The term "governance" can conjure images of bureaucratic compliance processes that interfere with "doing real work." Yet it is a results-orientated practice: jobs are on the line when poor decisions are made, or when companies get consistently blindsided by spiraling maintenance costs or unacceptable production quality. The ability to govern IT is, then, a critical capability.
When taking on governance, it becomes immediately clear that there is no commonly accepted definition of what IT governance is
Advertisement
IT executives, analyst firms, and product companies each advance different definitions that range from project management software to strategic business decisions. It need not be that complicated. Fundamentally, IT governance comes down to two questions that assess the effectiveness and the completenessof IT decisions: Are we getting value for money? and, Do solutions delivered meet our full expectations?
To determine the effectiveness of our decisions we ask, "Are we getting value for money?" This is a results-oriented question that is asked continuously to determine whether results are worth the price paid. It is also a forward-looking question, meaning it is asked about the current state of a project as well as how the project is trending. Answering this question with accuracy requires fact-based measurement of outstanding scope, work completed, total expenditure, and trend. The more mature the ability to answer this question, the more able IT management is to make informed portfolio decisions and influence the priority of business imperatives.
To determine completeness of solutions delivered we ask the second question, "Do solutions delivered meet our full expectations?." With this, we ask if solutions satisfy a full range of corporate policies, including security, architecture, quality, risk, and so forth. The ability to answer this question across a portfolio of projects yields greater consistency in results delivered.
While it is the IT solution (be it hardware, software, etc.) - and not the way in which it is being delivered - that is being purchased, it is difficult to quantify and measure "compliance" along every dimension. IT is also a people-centric business, with dozens of decisions taken in any project on any given day. By extension, this second question has process implications: the way in which work is done is a leading indicator of solution completeness. This is not to suggest that governance is simply an exercise in guidance -- governance is concerned with assessing solution completeness in a fact-based manner. To that end, the way in which work is being performed is a forward-looking indicator that solutions are likely to meet expectations in the future.
This, then, brings back the point that governance is fundamentally a question of balance of both effectiveness and completeness. At one extreme, the classic "they get results" approach to governance - addressing the bottom-line without considering completeness - creates a warped sense of results. At the other extreme, addressing completeness without grounding it in business value allows IT to fall in love with the solutions and lose sight of the business reason for undertaking the initiatives in the first place. Addressing neither question in a fact-based manner relegates governance to be an exercise in hope.
Good Governance Engenders Agility
The ability to both assess and forecast effectiveness and completeness makes an organization more - not less - responsive to changes in the business environment. This is true for several reasons.
First, good governance reduces surprises. It is difficult to be responsive when we are constantly blindsided by self-inflicted problems or catastrophic events. By monitoring progress in terms of work completed, and by exposing multiple facets of solution completeness, we are better able to anticipate and remediate problems.
Second, effective governance creates greater trust and confidence, and subsequently greater collaboration, with the business at a strategic level. By presenting fact-based portfolio progress and multi-dimensional assurance, business customers will place greater trust in IT's capability to deliver strategic solutions.
Finally, mature governance aligns day-to-day execution with strategic decisions. There is less likely to be a disconnect between business imperative and execution when the relationship between the two is clear. There is also less likely to be wasted effort as the way in which work is done is tied back to an organizational value system.
These three characteristics of good governance - a reduction of "surprises," an increase in trust and confidence, and execution aligned with strategy - make IT less mired in its own problems and, subsequently, better able to be responsive to the business.
Guiding Principles and Getting On With It
Because it is an emergent practice, there are no turnkey solutions and implementations are still bespoke exercises. Still, there are a few guiding principals that should underlie any governance initiative:
If governance is to be an enabler of agility, it cannot be a burden in day-to-day operations. To satisfy this, there must be non-burdensome and consistent ways to collect data across the organization.
To assess solution completeness, IT governance must have the active participation of the entire department, including security, infrastructure, architecture, risk management, business management, the PMO, and so forth. Subsequently, there must be participation from across the entire set of IT disciplines.
IT governance cannot become an esoteric high religion, and must instead be "part of the furniture." We must be able to communicate to all stakeholders in "native languages," and most importantly communicate in business terms to the business.
These principals shape governance activities to be extensions rather than cumbersome bolt-ons to day-to-day activity. They also provide criteria with which to assess current governance capability or initiate an IT governance practice.
While still an emergent practice, there are specific things we can do to mature toward agile governance:
Communicate the value of good governance to everybody. Pick one business measure of IT effectiveness (e.g., "does IT increase revenue" or "does IT improve our customer's satisfaction"), and report to executive management in business-impact terms. Similarly, and no less important, make clear to those in IT where and how they have voice by virtue of an effective governance capability.
Create a multi-disciplinary IT governance team. This is not "yet another corporate committee" but a chartered team with the responsibility to define what "solution completeness" means. Task this group with the responsibility of defining acceptance criteria as well as the practices which engender solution completeness.
Generate effectiveness and completeness data around your biggest pain points. Be it quality, time to delivery, operational transparency, or something else, implement lightweight processes to define and collect data to feed governance decisions.
These steps can be implemented no matter the process by which IT solutions are delivered. However, it is worth noting that Agile practices, which both generate and facilitate a fair amount of data about deliverables and process, are particularly well suited to governance that enables responsiveness. Clearly, Agile practices, when supplemented with appropriate governance, align strategy with execution. Prior articles in the Agile Journal, and specifically in The Agile Manager column, present ways of doing this.
The Capability to Govern Determines What's Next for IT
Governance is the bridge between executive management and IT. As competitive and regulatory business pressures increase, so shall the pressure for more mature governance. If it is imposed by the business, IT will struggle to evolve its governance capability beyond "measuring to plan." Should this be the case, IT will be consider more of a cost center or tolerated nuisance of doing business. Alternatively, governance can be initiated from within IT, and done specifically as a means by which to engender organizational agility. In this case, IT will increasingly be able to evaluate value delivered given evolving business conditions, and will increasingly become drivers of business imperative.
About the Author
Ross Pettit has 15 years' experience as a developer, project manager, and program manager working on enterprise applications. A former COO, Managing Director, and CTO, he also brings extensive experience managing distributed development operations and global consulting companies. His industry background includes investment and retail banking, insurance, manufacturing, distribution, media, utilities, market research and government. He has most recently consulted to global financial services and media companies on Agile transformation programs, with an emphasis on metrics and measurement.
Error, missing joomlaboard config file!
[1] "CIO Update: CIOs Reveal Their Issues with IT Governance," Gartner Research, November 16, 2005
Comments (2)
asif Qumer: ...
This article, gives a thoughtful clarification of IT governance. According to the article, we look into the business (IT governance) and work which is being performed but we may consider , which seem to me very important that how the things are being evolved and how to manage the evolvement for the current and future benifits. As "Evolvement of a process, product, team, plan, policies" is a core of an agile appraoch.
1
December 18, 2006
Daniel Brockman: ...
Ross writes an insightful, clarifying discussion of IT governance. And incidentally, speling may not really matter, but to the extent of its importance, Ross means "principle", not "principal".
Articles 
