“Governance Man” has fallen into my trap! :-)

This post was supposed to be called “SharePoint Governance is not a deliverable” – hence the pizza above, but my secret evil plan has worked faster than expected! Read on…

When I met with Dux Sy for breakfast the other day in a diner that looked remarkably like the set from Happy Days, our conversation covered various areas of topics around US vs Australian culture, SharePoint governance, project management, food, wicked problems, sense-making and my two kilograms of Vietnamese coffee beans that came from a weasel’s digestive tract :-). Smart guy, is our Mr Sy indeed; good business acumen – well suited to being a SharePoint sensei.

But one part of that conversation triggered a memory about a post that I was supposed to write and then completely forgot about. Thanks for jogging my memory, Dux.

Right in the middle of writing said post, SharePoint Joel has just posted some thoughts about his recent excellent governance document, inspired in part by some twitter conversations with Andrew Woodward. Andrew, like me, dislikes the word “governance” because he has seen the same confusion that can arise. Joel in his post, nailed totally what I was going to write about here, and referred to an old post of mine written in October 2008 where I undertook an experiment on whether I could make my own buzzword.

So, I think I will kill two birds with one stone here. I’ll post my original idea – in effect echoing what Joel said with regards to how to best use his governance plan, and I will also talk about the exciting adventures of intrepid hero “Governance Man” and vain attempts to defeat his arch nemesis “Dr Wicked” :-).

The precedent…

I have had a couple of experiences now, where I have been called in by clients who have the typical SharePoint chaos. Things have gotten out of hand and as a result, key stakeholders started to lose faith, and the project team really felt the pressure from the powers to be. There were strong undercurrents of desperation to get things sorted, like… yesterday. Under these circumstances, they asked for help on “governance”. They needed “governance”, they must have “governance”  and they spoke about governance as if it was something that a pizza driver can deliver to their door (and if it was not there in 30 minutes, it was free).

I was being a bit flippant when I talked to Dux about it, because both times I was dealing with the project manager in charge of each SharePoint implementation. I recall saying something along the lines of “some project managers have a lot to answer for here”. What I meant by that was “governance” in their eyes was a 1 line item on a work breakdown structure on their project plan – a project deliverable. As a result, they had this impression that by getting me to produce a “governance document” would somehow solve the chaos. Therefore, I had to answer the standard HMHL question (how much, how long) so it slotted nicely into the work breakdown structure.

*Sigh* if only it was that simple.

This hopefully provides an insight to why I am uncomfortable with the word. What these clients, in fact, were dealing with, was a crisis of confidence with the platform. They were unable to provide a level of assurance to the organisation that the platform could meet their needs. The lack of confidence turned to user pessimism, and the pessimism turned to outright rejection of the platform by some sectors.

Adding to that, Joel Oleson recently published a major revision of his sample governance plan, which I had the opportunity to review and made a few suggestions here and there. It is a great template to use for many organisations, but my fear is that people will think that this plan alone will be all that is needed because it has “governance” in its name. I mean, as a template, it is the best thing by far that is out there right now and adds significantly more meat than the governance checklist guide does.

“Governance Man” vs “Dr Wicked” (and “Agile Boy")

I have listened to the governance godfather Robert Bogue suggest that governance is a process and I think that is pretty close to the mark. He has also suggested that governance at its core is about risk management which I also agree with – or at least I do partly. As previously stated, I’ve always found that “governance” never really succinctly nailed this risk management emphasis. Isn’t risk management about providing assurance to stakeholders? It certainly makes more logical sense than saying “providing governance to stakeholders”.

So, in October last year, I wrote a post about the curse of “governance” now achieving buzzword status which makes life confusing for all, given that “governance” is talked about a lot, yet seemingly hard to understand and/or execute. To make it interesting, I blamed it all on my arch nemesis – “Governance Man”. You can see him in the photo below (check the T-shirt). Although the disguise is almost perfect (like mine), can you pick who he is? 🙂

In that October 08 post, I also executed my “secret evil plan ™” which actually had little to do with the governance/assurance debate itself. I simply wanted to see how long it would take for a new buzzword to take hold. I spoke of “SharePoint Assurance” and with a little help from my trusted super-friend Andrew “Agile Boy” Woodward, my arch nemesis – that meddlesome “Governance Man” fell into my wicked trap by blogging about it!

Mwaahahahahah… more people debating it! Another piece of Dr Wicked’s secret evil buzzword plan falls into place :-).

The unified theory of everything…

I recently did some Dialogue Mapping work for a local government organisation. In performing that work, I finally came across a definition of governance that I liked because it was simple and succinct and did not come from IT. It also has the positive side effect of putting my assurance instinct into the right perspective, too. Governance was defined in these terms:

“The word ‘govern’ means to ‘steer’. We aim to steer the energy and resources available for the greatest benefit to all”

Now we look at the definition of assurance (ripped from quality assurance)

“Assurance provides confidence in a product’s suitability for its intended purpose. It is a set of activities intended to ensure that customer requirements are satisfied in a systematic, reliable fashion.”

I see these as quite distinct activities and the key words in the above definition are “intended purpose”. Defining and maintaining “intended purpose” is the realm of governance via ‘steering’. Thus, governance is all about achieving shared commitment among stakeholders to a solving business problem, whereas assurance is all about achieving and maintaining confidence in the solution.

Paradoxically, you actually need both governance and assurance, for each to stand on their own individually. I mean, how can you achieve shared commitment without confidence? How can you have confidence without a shared commitment to a course of action? This is wicked problem fodder right here, and for a more detailed exploration in the relationship between shared understanding, shared commitment and project failure, then read the one best practice to rule them all series.

This, I think gets, to the root of why I get nervous when I hear the term “governance” bandied around. So, I take Joel’s point that assurance may “lack legs”, but assurance, to me, has a clearer meaning for the “confidence” side of governance. As I mentioned earlier, a nice little test is to say out loud these two statements and see which one ‘feels’ right.

• “We have to provide better SharePoint assurance to the business.”
• “We have to provide better SharePoint governance to the business.”

For what it’s worth, this article is not the first one to try and unify these concepts in this way. John Miller previously wrote a nice article that relates these two concepts together neatly way before me.

Are we splitting hairs? Yup, totally. In fact the next section is really what is important.

It’s all in the attitude…

Joel talks about governance in terms of “defining a service offering” as well as “mitigating conflict within an organisation”. No objections to both of these arguments as that is not really assurance. But my own “high level” governance guides are usually 2-5 pages, and guess what? I define the service offering, the guiding principles and define the roles and then refer to the other documents where the bulk of the material ends up. More often than not, these documents are assurance oriented documents.

Let’s talk for a minute about the “mitigating conflict within an organisation”. If you have read my “project fail…” and especially the “one best practice” series of posts, the “conflict resolution” aims of governance is definitely not served by a “governance document”. This is the world of what Jeff Conklin calls social complexity – or put perhaps in a simpler way: people, strategy and politics.

This is where I differ slightly from Robert Bogue. I attended his Feb 09 Best Practices Conference session where he spoke of SharePoint governance as a process. I personally believe that SharePoint governance is more in common with a methodology, and should be looked at through similar lens to other methodologies, like Agile software development, PMBOK, SEI CMMI and the like. Agile is not considered a ‘process’, although process is a significant part of it. I think the difference is that a methodology requires attitude to support the process. It is the latter area where the problems are. Without the commitment to back up the process, “governance” will be nothing more than just another document that few will ever read and even less will understand.

A document cannot alone drive the shared commitment required to make governance work.

When you look at SharePoint governance through the “methodology lens”, you will see that the reasons for governance failure are the same as why methodologies themselves have a hit and miss fate. Most methodologies require significant attitude to support the rigour to succeed.

Lessons from Agile

Not so long ago, I spoke to SharePoint’s own Agile/TDD guru Andrew Woodward about the topic of rigour and attitude to make Scrum projects a success. I had read this terrific real life story on the attitude factor required in Agile and was interested in Andrew’s experience with this, specifically in the SharePoint realm. Andrew confirmed that attitude and shared commitment among the team were particularly critical. Here is what he had to say.

When discussing agile teams and why they fail, Malcom Gladwells theory about Broken Windows is often quoted.   The premise is that if a broken window is left unrepaired, people will conclude that no one cares and will stop caring themselves. This is a very relevant to agile development teams where they rely on team ownership; where the team as a whole have to care about what they are developing and the way it is developed.

Agile processes quickly start to fail if some team members don’t care;  the broken window could be something as seemingly small as a failed unit test not being fixed or continually forgetting what they did yesterday at the scrum, eventually if this broken window is not fixed other team members will stop caring and the team will reach their tipping point.

The rigor needed by all team members is significantly greater than traditionally applied to development,  the myths around lack of control and process could not be further from the truth.  To be successful with agile processes you need every team member to care

I think you would agree, that Andrew could have been talking about being successful with SharePoint itself. 

Finally something practical

I thought that I would end this post by being practical as the post thus far has been a bit of a theory-fest. If you take some lessons from why methodologies such as Agile/Scrum fail, then it is pretty easy to list some practices that are likely to help you with your SharePoint governance effort.

One size definitely does not fit all

• Organisations vary in terms of size, industry and culture. A template cannot possible cover all scenarios.
• It is unwise to submit Joel’s sample plan without a real concerted effort to make that plan your own

Systems thinking and commitment

• We all rely on each other in complex and implicit interdependencies. Without a shared understanding among all participants, you will not have shared commitment among participants.
• Without shared commitment, a governance plan is just another document that will be out of date within months.

Governance affects different participants in different ways

• Culture is only changed if strong leadership makes it so, or participant accountabilities are crystal clear and completely unambiguous; therefore
• Split accountability into service ownership (“service”, being the SharePoint platform, is the domain of the IT department) and the Information Asset ownership (the applications and running on the service) are the domains of the business; and
• Identify owners versus custodians. Make sure that owners realise they are *always* accountable, even if they delegate day to day operational matters to custodians. If something goes wrong, the finger is pointed at *owners*. This has the benefit of making them suddenly much more interested in service and information assurance.
• It is more than the geeks. Geeks are custodians 99% of the time. In fact, SharePoint chaos comes more from Information Architecture and poor strategic planning as much as from a poor installation.
• Communicating the governance plan to more than the geeks is paramount. We should work to keep at least the high level material in planning as buzzword free as possible, my grandma should be able to read this stuff.
• Provide training for custodians and owners (if an owner refuses, then they may not appreciate their accountabilities as described in the second point).

Use common sense

• It doesn’t have to be bigger than Ben Hur. Doggedly following the written word to the last letter ignores the cultural commitment required by participants to make it work
• People only want to read what applies to their responsibilities. Make your documentation relevant to the key roles.
• One big document is just like meeting minutes – most will never read it. Split the document up if you have to.
• User evangelism is a good thing; be too controlling and you will lose it. Once lost it takes a long time to recover (look at Microsoft who have spent years trying to win back support from the days when they acted like bullies in the marketplace).
• Why put in SharePoint and then use a paper based change control or configuration management system? 

Put the supporting structures in place

• Targeted training. For key roles in the governance framework bring someone into your organisation. Targeted training for this group is better than some generic course.

In short, attitude and commitment is a problem of social complexity. The documented plan is great, but that is unfortunately the tame bit.

 

Thanks for reading

Paul Culmsee

www.sevensigma.com.au