The demand (and need) for IT governance is increasing faster than the discipline is maturing. Core to the problem is that there is no concensus as to what is meant by "governance" in an IT context. If anything, there is outright confusion, evidenced by the polyglot of consulting and services and the number of project management products being positioned as governance "solutions." This, in turn, means there are few coherant approaches (let alone solutions) to satisfy the need.
In and of itself this isn't a problem: that governance needs to be highly tailored to an IT organisation is simply an indication of practice immaturity. But there is a significant downside: practice immaturity means an absence of best practices and a high rate of solution mis-fit. This can be seen in many current IT governance structures. Often little more than large, cumbersome reporting exercises grafted on top of operations, they relying on poorly-modeled data-gathering mechanisms that inadequately interrogate what's actually happening on the ground. Instead of providing "windows on operations," they're CYA exercises that create arms-length relationships between field decision-makers and directors. At their worst, they're inhibitors to productivity and sew seeds of mistrust.
For starters, IT governance needs a clear definition. Fundamentally, IT governance is a results-oriented exercise that can be summed up in one question: what is being achieved, given operating realities (commercial, regulatory, risk, etc.)?
This is a more active than passive definition. Governance is, in fact, an active, engaged, results-oriented discipline. Some would argue that governance is more accurately defined as providing "guidance" to people throughout an organization as to how decisions should be taken and work should be done, but this is an incomplete definition. If it were meant as "guidance" it would be called "guidance." With governance comes responsibility: if bad corporate stewardship can result in criminal penalty, it is, indeed, a results oriented practice. That the obligation of "good governance" carries with it the need to know "how work is being performed" is simply an expansion - but not replacement - of the definition of governance. To wit: SOX requires the CEO and CFO to certify that financial reports reflect reality; that is, the bottom line is what they assert it to be. That the "how" is important to this act of executive certification is an extension of that basic performance-oriented question. IT governance is no different.
The über-question - what has been achieved given operating realities - breaks down into two distinct dimensions:
- Are we getting value for money? That is, are we maximizing return on our techcnology investment? This allows us to assess the effectiveness of our decisions.
- Are solutions being delivered in accordance with expectations? That is, are execution and delivery in compliance with corporate policy, be it security, quality, design, etc. This allows us to assess the completeness of our decisions and results.
The first dimension is results-orientated. It's important to note that it's not concerned with the question "are we meeting plan" but "are we getting bang for the buck." IT has traditionally asked this question after-the-fact, measuring results of operations / projects / programmes post-flight, as in-flight reporting is often little more than reporting to plan (and laden with opinion). Post-flight, however, is no longer sufficient: while corporate revenues are rising, cost containment is embedded into corporate culture; a recent report showed IT budgets lagging revenue growth by more than 60%. There really is a need to do more with less, and to do so on a large, organization-wide basis. In addition, the operating environment changes quarterly, monthly, weekly, daily; as a result "meeting plan" can be more destructive than helpful. Finally, it is important to assess which IT investements will yield the greatest business impact going forward. This means the "results" question needs to be asked on an ongoing basis and framed in a portfolio context.
The second dimension is process-oriented, concerned with whether results achieved are consistent with organisational objectives and expectations (that is, are decisions being made with a full scope of consideration.) This dimension - so often the focus of "governance" and so often ignored or outright chided ("what difference does it make how it's done, just that it's done?") - carries equal status to the results question. The "how" question has been the source of the bureaucratic burden of little operational value, the breakdown in the governance programme requiring that monthly "compliance reports" are filled out by teams, rife with survey-borne opinions more than operational fact. The reality is, "how" stuff is done is just as important as "what" is done. If SOX is evidence that this can't be left to trust in accounting and finance, it is not a stretch to say that it can't be left to trust in IT operations, either. Clearly, IT solutions that are vulnerable to security violation or are long-term financial drags on the balance sheet due to architectural flaws are serious matters: jobs are on the line for this stuff. As the stakes are higher - e.g., as the threshold for internal investment into IT projects is increasingly high and under closer scrutiny, as the cost of failing to safeguard information is similarly high, etc. - this can't be ignored.
Formalized governance is coming to IT. If it is imposed from the outside, IT will suffer under the weight of measurement and collection mis-fit, relegating IT to the role of "passenger" in the organization for many years to come. IT has the opportunity to incubate and rapidly professionalize a governance capability, aligning governance with execution through fact-based management that communicates performance not in an IT context, but in a business context. If successful, it will transform IT from being passenger to driver of organizational objectives.
