Thoughts on Governance...
By special request of a fellow blogger I am posting the following opinions on governance.
Governance as defined implies a subset of people with authority, providing direction, and by default assumes some spectrum of politicking –- or more properly stated: differing viewpoints on shared issues. We will see governance in several domains, some formal some informal. We find governance in IT Strategy, Finance, Business, Projects, and even HR. Some of the more common formalized governance is very process-oriented. The informal governance of a decision can be handled with behavioral interaction (i.e. having unmanaged meetings with key stakeholders to gain consensus) peers and managers I have worked with often call this “socializing”. There is a subtle and more subversive means of informal governance in which influential individuals lobby for or against a decision / project / promotion. Although actions like this may historically have saved groups from serious mistakes, it’s not always repeatable and may create an environment where permission isn’t asked for...forgiveness is.
Although I enjoy articles such as this from ZapThink, I suspect there is no self-help audio tape, book, or analyst framework that has the secret-code on governance cracked (although by way of this blog I invite comments to the contrary!). It’s often a product of the culture. It can be a predictor of change. It’s usually a sign of delegated leadership. The one thing that I suspect most would agree on is that it’s always painful at first to get assimilated.
To conclude this soap-box, here’s my advice:
• Keep the process simple and well documented
• Keep the number of participants to the smallest number possible...but no smaller
• Invite resources from multiple parts of the organization to sit-in on sessions to eliminate shrouds of secrecy
• Identify neutral moderators who can set calendars and take notes
• Assess behavior aspects from two different dimensions:
(1) The organizational model...where you’ve been
(2) The strategy...where you’re going.
• IT governance needs to include people that understand the technology
• Governance can be more valuable across domains, too much detail will corrupt agility
• Governance decisions need to be audited and enforced
• If a leader appoints a governance body, that leader should avoid overriding or circumventing that body's delegated authority
• Success can be measured equally in work that gets halted as in work that gets accelerated
• Some of the best governance is self-governance and empowerment. Start with architect education. Groups of business analysts, project managers, developers, controllers, architects, application owners... all are candidates for taking on this accountability. By having everyone own a piece, a common respect and buy-in for the overall direction evolves.
In the end it’s just about leadership and prosperity.
Governance as defined implies a subset of people with authority, providing direction, and by default assumes some spectrum of politicking –- or more properly stated: differing viewpoints on shared issues. We will see governance in several domains, some formal some informal. We find governance in IT Strategy, Finance, Business, Projects, and even HR. Some of the more common formalized governance is very process-oriented. The informal governance of a decision can be handled with behavioral interaction (i.e. having unmanaged meetings with key stakeholders to gain consensus) peers and managers I have worked with often call this “socializing”. There is a subtle and more subversive means of informal governance in which influential individuals lobby for or against a decision / project / promotion. Although actions like this may historically have saved groups from serious mistakes, it’s not always repeatable and may create an environment where permission isn’t asked for...forgiveness is.
Although I enjoy articles such as this from ZapThink, I suspect there is no self-help audio tape, book, or analyst framework that has the secret-code on governance cracked (although by way of this blog I invite comments to the contrary!). It’s often a product of the culture. It can be a predictor of change. It’s usually a sign of delegated leadership. The one thing that I suspect most would agree on is that it’s always painful at first to get assimilated.
To conclude this soap-box, here’s my advice:
• Keep the process simple and well documented
• Keep the number of participants to the smallest number possible...but no smaller
• Invite resources from multiple parts of the organization to sit-in on sessions to eliminate shrouds of secrecy
• Identify neutral moderators who can set calendars and take notes
• Assess behavior aspects from two different dimensions:
(1) The organizational model...where you’ve been
(2) The strategy...where you’re going.
• IT governance needs to include people that understand the technology
• Governance can be more valuable across domains, too much detail will corrupt agility
• Governance decisions need to be audited and enforced
• If a leader appoints a governance body, that leader should avoid overriding or circumventing that body's delegated authority
• Success can be measured equally in work that gets halted as in work that gets accelerated
• Some of the best governance is self-governance and empowerment. Start with architect education. Groups of business analysts, project managers, developers, controllers, architects, application owners... all are candidates for taking on this accountability. By having everyone own a piece, a common respect and buy-in for the overall direction evolves.
In the end it’s just about leadership and prosperity.
posted by JT at 9:01 PM
5 Comments:
Your phrase "Identify neutral moderators" is curious.
Did you mean to say neutered?
Is there a distinction between facilitation and moderation?
How does identification happen?
Should governance be repeatable?
Maybe a blog entry on best practices on "socializing" governance?
Hi JM,
"Identify neutral moderators" draws specificity to people that have no vested interest in the issues or political ramifications of decisions on those issues.
Can't say neutered without spayed ;-)
Facilitation may help ease a problem getting solved. Moderation is taking two opposing issues and easing them into uncomfortable compromise. The latter feels more like a divorce.
Identification of resources is up to leadership.
Governance must be repeatable in order to be successful, but that does not presuppose it happens in the exact same manner.
An architect blogging on "socializing governance" is like a soldier blogging on the benefits of propaganda...and would only help me if I am looking for a head-hunter.
Later!
There you go again not solving for but adding to the knowledge crisis. I hope that you really understand that there is a difference between management and leadership. Stop using these words interchangably...
This comment has been removed by a blog administrator.
Argh...gasp...say it isn't so!
Very well, on guard, since you have assumed I misused the term leadership, how do YOU define the difference from a governance perspective?
Perhaps you assume that strong technical leaderhip cannot appoint governance over sub-domains...
Post a Comment
<< Home