What Is So Hard About Getting Governance Right In IT Projects?

Maybe just one word:  responsibility.  Or more specifically, the fact that s/he didn’t take the appropriate level of responsibility.

So we reduce it to an after-the-fact blame game:

• The Business Sponsor was missing in action (didn’t take responsibility for the business benefits)
• The IT Department didn’t understand the business needs (assumed responsibility that wasn’t theirs)
• The Project Manager didn’t blow the whistle in time (can’t be responsible for everything, but certainly is responsible for knowing when things aren’t healthy)
• The Contractor took the money and didn’t meet deadlines or satisfy the user (we paid them a bunch of money, so they must be ultimately responsible, mustn’t they?).

These common (and often justified) complaints are firstly symptoms of flawed governance, and not fundamentally of individual incompetence or bad behavior.

So let’s start with the First Law of Project Governance:  There must be a proper, and properly functioning, Steering Committee:

• “Proper” means that it is chaired by the Executive whom the organization will be holding accountable for the promised business benefits and costs.  Its members are other executives who lead organizations that will be impacted.  One of those will be the IT organization, who must advise on the technical aspects of total cost of ownership, technical risks, and so on.  The bigger the business impact, and the more cross-functional the operational changes will be, the higher in the organizational food chain that Business Sponsor must be.  Almost never is it appropriate for the CIO to chair the Steering Committee.  Unless the cost and impact is so small and so contained to the IT shop that the top executive wouldn’t know or care if it failed.
• “Properly functioning” means that the Steering Committee meets at least once a month (and a minimum of six times in the life of the project).  These meetings must have an agenda designed to illuminate major project issues that require decisions and actions from members of the Steering Committee.  The Chair of the Steering Committee must be present and engaged.  The Project Manager must own the agenda for raising critical issues and recommending a course of action.  He or she must also report back on results and timeframes from previous decisions.

So what’s so hard about that?

Well, it takes time and focus for the right people to be doing the right things in a Steering Committee.  Sometimes they legitimately don’t have the time to spend, and/or other matters are consuming their focus.

When this is the case, serious consideration should be given to cancelling or postponing the project.  Or better yet, redesigning the project scope to have a big enough impact to support the right behavior.

If we fail to recognize this problem early, we are almost certainly going to be playing the blame game later.