Governance is knowing who holds the key
Ever had a good idea that could make millions for your company? Did you tell the right person? Did you know who that person was?
I cannot count the times I've heard it. "You know, if we were really smart, we'd be doing XYZ." But then it falls to the 'Inventor' to sell the idea. We all know what happened to the inventory of Velcro (nothing!). People who see a good thing and come up with a good thing are often not adept at explaining, selling, convincing. Sometimes, the idea is not good. Sometimes the benefit is unclear. But the biggest reason that good ideas don't happen? The inventor doesn't know WHO to sell to.
At the end of the day, IT Governance is about knowing who to sell to. It is about having a clear idea of what group, what council, what committee, and what individual can answer all of the important questions.
I was given a short lecture on this aspect of governance yesterday, and the light went "on." Doh! How come I didn't see this as clearly before? It's stuff I knew already. Common sense, really. But I'll be darned if I really got it.
Start with your vision. What should the world look like. Then develop principles: good practices that should lead to that world.
Now take those principles and you break out the questions that need answering. Assign responsibility for answering it. Create a forum for deciding it. Make visible the communications in and out of it. Define the rules of the game. Then publish them.
And now... measure. Make sure that the 'good things' are acutally happening. If they are not, come back to these people and ask 'why not?' You will know who to ask. (So will the executives).
Example:
Vision: I want an IT ecosystem where any system can be easily hooked up to "integrate" with any other system, so that when business changes, we are ready.
Principle: Every application shall be designed with integration in mind.
Tactical: For every system of enterprise scope, or which manipulates enterprise data, interfaces will be developed and supported for communicating data, events, and functionality.
Governance questions:
- Who decides which systems are of enterprise scope?
- Who decides what data 'subjects' are of enterprise concern?
- Who decides what mechanisms will be required for applications to support?
- Who decides when an application must consume the services of another, instead of creating the services all over again in code?
- Who decides what the list of 'enterprise events' are?
If you can answer these questions, then the inventor of a good idea has someone to talk to. Executives have someone to go to. No one is left wondering "how did this happen?"