Dilbert’s Guide to Governance

The Dilbert for Tuesday, June 12th was certainly appropriate for any conversation on Governance. In all seriousness, however, if you governance processes resemble this, you’ve got problems.

Back in January of 2006, I had a conversation with Phil Windley on governance for an article in InfoWorld. One of the points that I made was that you do need to get your policies documented and communicated. If the only way someone knows whether the decisions they make are right or wrong is by attending a meeting and hoping someone with authority (if they even know who that is) agrees with them, that’s not good governance, albeit it is governance.

The Dilbert cartoon is titled, “CEO Visit.” Clearly, no one will question the authority of the CEO. So, you could argue that step one of governance has been handled, which is establishing the authority of the people who will govern. It’s not just the CEO, but the CIO, CTO, Chief Architect, etc. The problem doesn’t normally exist with authority at these levels, but at the levels in the middle. The chief architect may be signing off on all policies, but they’re probably not setting every policy. There needs to be a hierarchy of decision making, so that decisions are made at appropriate levels, and only where conflicts arise do things bubble up. The problem with this is that if the policies and guiding principles at the higher levels are not established, everything breaks down at the lower levels, because no one knows who has authority to set direction in which area. As a result, people are constantly pushing the boundaries and trying to gain power and influence, rather than actually creating good solutions. It’s not about doing the right thing, it’s about doing my thing. If no one (with authority) has stated what the “right thing” is, individuals will always think that their thing is the right thing. Step two is about establishing and communicating policy.

In a bit of irony, the CEO in the Dilbert makes the statement, “Opinions are treason.” I hadn’t thought about it at the time, but opinions are the downfall of the enforcement portion of governance. Opinions are good when policies are being established. Opinions are bad when policies are being enforced. Think about it. It’s not going to do a bit of good to tell the police officer, “Sorry, I was speeding because I feel the speed limit should be 20 miles per hour higher on this road because of the light traffic and the limited number of entrances, exits, and intersections.” When that highway is being constructed, however, and speed limits are being established, bring all the opinions you want (although backing them up with facts is even better).

We can’t forget about the process (step 3), however. If you employ architecture reviews, what happens all too frequently is that at the time of a review, the discussion turns in a debate of opinions, which will normally go unresolved unless someone in the room is in a position of authority recognized by all. A review needs to demonstrate that policies have been followed, and where they have not, focus on the reasons why an exception is necessary, not on whether it’s a bad policy. In addition, the review must also address areas where better guidance was needed, so new policies can be created. Ask the question, “In coming up with the solution architecture, where did you have multiple options for which the reference architecture and patterns did not provide sufficient guidance? What factors led you to choose the option that you did?”

So, as I’ve said before, governance is about people, policies, and processes, in that order. Without clear understanding of authority, documented and communicated policies, and processes to keep improving things, you’ll wind up going to your CEO far too many times for decisions until he starts calling you “Doofy.”

2 Responses to “Dilbert’s Guide to Governance”

Leave a Reply

Ads

Disclaimer
This blog represents my own personal views, and not those of my employer or any third party. Any use of the material in articles, whitepapers, blogs, etc. must be attributed to me alone without any reference to my employer. Use of my employers name is NOT authorized.