Apr 202010
 

Technology governance is something every company needs. But it’s also something that most companies would prefer not to discuss — or publish. The fact is that without explicit, consistent, well-communicated and well-supported governance, you will experience some degree of chaos in the technology acquisition, deployment, and support process.

I’ve written a lot about governance over the years. I am one of those who believe that governance can make or break a technology organization’s ability to deliver business value to its clients. I also believe that governance is absolutely, positively political and therefore complicated, convoluted, and at times deranged. Because of the politics, personalities, and corporate cultures that influence and manipulate governance, it’s necessary to be as explicit as possible about governance definitions, processes, and power. Really, you have to write this stuff down and publish it every way you can to communicate what governance is — and is not — and to stimulate discussion and arguments about what governance should — and should not — look like at your company. Hiding from governance guarantees chaos as well as overspending or underspending on technology.

Like politics, technology governance is about power and control. Some of the power is centralized, and some is shared. But it all must be described and allocated. Governance projects should also be continuous, and any ongoing self-respecting governance project will have the following objectives:

  • Define and standardize key processes.
  • Manage costs.
  • Improve customer service.
  • Develop a scalable service platform.
  • Provide decision-making agility and accountability.
  • Improve project/program management discipline.

The elements of governance are many and varied and include at least the following:

  • Definition of major governance decision-making areas, processes, and policies
  • Allocation of decision rights and decision inputs across the areas and policies
  • “Light” formalization: no need for heavy documentation or complexity
  • Implementation
  • Ongoing assessments and “adjustments”

Governance is a necessary evil. Organizations that aspire to business technology optimization need governance. The first thing you should do is assess your current governance rules and the current governance climate. If there’s some room to tighten governance for the greater good, then you might try to increase the discipline around governance. If there’s no appetite for change, then you should prepare for the time when change is more acceptable. You should also attempt to quantify the value of governance along a continuum. “Light” governance, you might demonstrate, will yield some pretty unremarkable savings and/or business enablement, but “heavy” governance, you might argue, will yield some significant savings and enablement. As with all technology initiatives, however, you will need to assess the overall context in which governance (and other) decisions are made. Are things good? Are they tough? Is the senior management team “sophisticated”? Or is it “challenged”? Is the corporate culture generally open to change — or does it do whatever it takes to kill anyone who suggests things are not OK? Once you decode the context, you will be able to proceed with a governance makeover or a whole new governance project. As tough as all this may be, when done right, governance is an enabler that helps companies remain competitive. Try it, you might like it.

avatar

Stephen Andriole

Dr. Stephen J. Andriole is a Fellow with Cutter's Business Technology and Digital Transformation Strategies practice. Dr. Andriole's career has focused on the development, application and management of information technology and analytical methodology to complex business problems.

Discussion

  One Response to “Governance Where IT Counts: Try It, You Might Like It”

  1. While I think I agree with the sentiment of this piece, I don’t hear a very good prescription for what to do. Governance is such a fuzzy word and so frequently utterly misguided in its application. Implementation of governance is all too often “policy & oversight” by those who have never attempted to practice, have failed as practitioners, or are tired of practicing. Ultimately those made accountable for “governance” are unaccountable for any aspect of delivery of anything. It becomes their job to throw sand in the gears of the organization because they know little of what they govern and are only held accountable when “bad things happen.” The cost of this most common form of governance has to be staggering.

    I am reminded of a story that was ascribed to Ken Schwaber (it may be apocryphal). When asked by an organization if they should switch to agile development, he advised “definitely not.” If you do that, all of your problems will come to the surface very quickly. But if you don’t, you’ll have a year or two to clean up your resumes and find new jobs before the sorry state of affairs becomes evident to the rest of the organization.

    Too many organizations think they will get governance by standing up a “governance center” (pmo, compliance office, etc.). Senior management is happy, from the board on down, because “we’re finally going to manage our risk.” It takes about three years before the organization dismantles it, or more often ignores it, quietly, because it is plainly and obviously ineffective.

    Prefer instead to think of governance as “an emergent property” of a well-defined organization. Accountability for various organizational objectives is elegantly and parsimoniously apportioned to its practitioners. Work activities are sufficiently automated to have measurable data points thrown off as side-effects and aggregated for transparency for all. To achieve this state is a lot harder than the more common, optically-satisfying approaches, but ultimately truly more effective. After all, if self-managing is the aspiration of small teams, why isn’t self-governing the aspiration of large organizations?

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

(required)

(required)