IT Governance: Who/Decides/How

  • Budget overruns.
  • An underperforming vendor.
  • Changing organizational priorities.
  • Resistance to change despite significant risk.

These are real challenges that could have derailed a critical, multi-year, enterprise project. We were able to navigate these and other obstacles successfully, and the key was governance.

First, what is a project? A project is a collection of tasks, involving multiple individuals, organized to delver well-defined products or outcomes (called “deliverables,” go figure) within a defined period of time.

Before managing a project, make sure it has a chance of succeeding. That means answering four questions:

  1. What, when it is all said and done, is the point of the project?
  2. Who in authority wants it to succeed?
  3. Who has the authority to define success?
  4. Who has the authority to make different kinds of decisions and resolve different kinds of issues, and to delegate that authority when the situation calls for it?

WHAT’S THE POINT?

The point of any government project is to deliver improvement of some kind – a different, better way of doing things. Expending time, effort and budget so everything stays exactly the same as it was before wastes time, effort and taxpayer money.

Government can improve in four ways – mitigate risk, add or improve existing services, reduce the cost of government without reducing service. There are other outcomes, or deliverables, but most of them contribute to the aforementioned big four.

WHO CARES?

Just because government improves doesn’t mean it does so for anyone working there; almost certainly it won’t improve for everyone working there. Even for executive management there are some winners and losers.

That’s OK. Not everyone needs to want the results. But SOMEONE should! Usually it happens one of these ways:

  1. Someone has a bright idea…
  2. Refines it until the description sounds worthwhile…
  3. And pushes the resulting “business case” into the organization’s project approval process.
  4. The approval process assesses whether the business case properly and credibly describes cost, benefits, relationship to organization strategy and so on…
  5. And delivers a decision as to whether it’s approved or not.

Deciding a project is worthwhile isn’t the same as chartering a project that can succeed. To succeed, someone with the authority to make decisions – to provide more time, resources and budget – has to be committed to it.

Distinguishing between the individual who had the bright idea (champion) and an executive who wants it badly enough (sponsor) to commit to it is critical.

Every project should have a sponsor before it is assigned a project manager. Usually the CIO, champion, and project manager try to recruit one. Too often if they fail, the list the CIO as the sponsor the move forward toward near-certain disaster.

STEP BY STEP

To succeed, projects need:

  1. It has to have a point (a business outcome that warrants the investment of time, staff, and resources.)
  2. At least one executive has to personally want it enough to take risks on its behalf…
  3. …and has the authority to commit time, budget and staff if they are needed.
  4. …And the authority and willingness to decide when it’s finished.
  5. All stakeholders have to agree about project governance – about WHO has the authority to make different DECISIONS about the project, and HOW they will make and communicate those decisions.

There are numerous approaches to governance, and they can all succeed. They can all fail, too, if they are not executed by the decision-makers.

This problem is magnified if business leaders fail to engage, viewing projects as “IT projects” because they have an IT component, and assume CIOs or project managers will handle of the details and decision making.

  • Examine your approach to governance to ensure that it is built around the right decision makers, organizational capabilities and organizational strategy by determining precisely who the decision rights are regarding the issues that must be addressed.
  • Persuade those with the decision rights of the importance of their role, the required time commitment, and the need to focus on the business process aspects of a project. Perform these actions, rather than letting leaders incorrectly assume they are “IT projects” by making certain these leaders truly understand that without their engagement, failure will result.

REFERENCES

https://www.gartner.com/document/code/388578?ref=authbody&refval=3939996

https://www.gartner.com/document/code/390879?ref=authbody&refval=3939995

https://www.gartner.com/document/code/388577?ref=authbody&refval=3939993

https://www.gartner.com/document/3939993?ref=solrAll&refval=237384693

https://www.gartner.com/document/3892395?ref=solrAll&refval=237435955

Less is more: Minimalist approach to governance. https://www.gartner.com/document/2136215?ref=solrAll&refval=237436215

Practical Governance
https://www.gartner.com/document/1479717?ref=solrAll&refval=237436386

Enterprise IT Governance
https://www.gartner.com/document/3892395?ref=authrightrec&refval=3892299

Leave a Reply