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

Hi all

This is the culmination of a significant amount of effort and a long time in the making, but I am extremely proud that Seven Sigma, the company that I am a co-founder and partner of, is now officially recognised as the first CogNexus Institute "Designated Partner" in the world. I first came across the unique work of Jeff Conklin and CogNexus some time ago and it has changed forever the way that I and my Seven Sigma colleagues approach all of our client engagements. We have been using the CogNexus philosophy, teachings and methods for complex problem solving ever since and are now uniquely qualified in this craft – not only in Australia but much of the world.

This goes way beyond our original SharePoint competencies (and believe me, we are not too shabby at SharePoint!). We are regularly called upon to practice the craft of Issue and Dialogue Mapping outside of the traditional IT discipline, assisting clients to make sense of complex or wicked problems confronting them. Whether we are helping a group of stakeholders to decide issues of transport and road infrastructure, helping a board of directors determine their corporate strategy, or simply righting the ship of a SharePoint or IT project gone haywire, we have proven our competency in this craft. Hence, our skills are now formally recognised.

If you are wondering what this is all about, then it is best to to read my current "One Best Practice" series of articles found here. 

Does it work? Well, our clients seem to think so. Check out this quote from the ICT Manager of the Royal Flying Doctors of Western Australia

I can confirm that I have dealt with and are currently dealing with Seven Sigma Pty Ltd for our SharePoint implementation project. During the setup phase of our project we interviewed several SharePoint focused companies and found Seven Sigma to be above the rest with their overall knowledge of SharePoint and its underlying technologies.  Their approach and methodology to our project has been unique and refreshing and has been enthusiastically accepted by our project team and end-users. It is evident that their ability to map the underlying processes and clearly decipher these during the project kick-off will be a key success factor to our project. Their work to date has been a major factor in empowering our users which will directly assist in our intranet project becoming successful.

I can confidently recommend Seven Sigma Pty Ltd as a solid and reliable SharePoint supplier, and experts in their field.

Matthew Turany

ICT Manager

RFDS Western Operations

<plug>Want to learn more? Got a toxic wicked problem? Want to be trained on the Jedi-arts of IBIS? Then contact us and let’s talk!</plug>

Thanks for reading

Paul Culmsee

www.sevensigma.com.au

Hi there

Welcome to the fourth post in my series on how to deal with the true root cause of project failure. The first three posts were really to set the scene for this post where I will explain the basics of my craft for resolving some of this. First up, I described my journey through the maze of of well known methodologies and best-practice standards, trying to make sense of a character known as “SharePoint vs Skype guy”. After seemingly taking one step back for every two steps forward, I finally found an area of research that I strongly identified with – the concepts and phenomena of wicked problems. I described how I have come to believe very strongly in the principle that understanding a problem comes from exploration of potential solutions, and that the act of exploring solutions will change your understanding of the problem. Traditional methodologies tend not to recognise this fact, and in fact, many force you into a problem solving model that precludes this perfectly natural sense-making activity.

This sense-making process is utterly critical to project success. The fact is, almost any project failure symptom (such as scope creep) can be traced back to a single root cause. That cause is a lack of shared understanding among participants of the problem behind the project. If you presume, however unlikely, that every stakeholder had an identical deep understanding of a problem and maintain that understanding, then almost by definition, things like “scope creep” and “unrealistic expectations” would not happen

In my last post, I turned my attention to the “inappropriate methods” that are all-too commonly used to tackle projects that have taken on wicked tendencies. We looked at the flawed logic of throwing “process” at a wicked problem, the sometimes misguided reasoning behind many scope restrictions, as well as the pros and cons of competitive and authoritative strategies. Finally, we examined the paradoxical effect where, to fully understand a problem, we have to understand all points of view. Yet in doing this, we leave ourselves susceptible to falling foul of wicked problem characteristics.

Hmm…Such a conundrum…Is there a way out?

From Rittel to Conklin (and IBIS)

Once again, we have to take a brief sojourn to the era of sideburns, flared jeans and excessive amounts of pubic hair…The 1970’s.

Years before Rittel wrote his seminal wicked problem paper in 1973, he had already come to the belief that the relationship of problem understanding was dependent on the solution being considered at any given time. He had also been thinking about tools and methods to overcome the problem. By 1970, Rittel had invented what he termed a “design augmentation” system that he called Issue-Based Information System (IBIS). Here is how IBIS was described back then.

Issue-Based Information Systems (IBIS) are meant to support coordination and planning of political decision processes. IBIS guides the identification, structuring, and settling of issues raised by problem-solving groups, and provides information pertinent to the discourse … Elements of the system are topics, issues, questions of fact, positions, arguments, and model problems.

For you trainspotters, You can read Rittel’s 1970 paper mentioning IBIS for the first time here. This paper is quite amusing when you read it nowadays as it is positively antiquated. But, hey, we are talking about a time before PC’s and when my father still had all his hair. The first time Rittel compared and contrasted “wicked to tame problems” was actually in a 1972 article. Rittel was also not alone in the search for tools and instruments to assist sense-making. He was influenced by the legendary Douglas Englebert (the dude who invented the mouse), who had spent the early half of the sixties examining tools and methods to “augment human intellect“.

Rittel’s original 1970 incarnation of IBIS had many elements to it. He called one component in particular an “Issue Map”. Rittel described the issue map as:

Representation of the various relations between issues, questions, etc., by graphic display of the state of argument

The issue map, 1970 style, involved pen and paper (probably those lead-laced black marker pens that made your head spin from the fumes). But over the following years, IBIS was refined and further developed. Many of the components of the 1970’s version were made obsolete by advances in technology and business practices, but Issue Maps in particular, remained. In the 1980’s, the era of personal computers dawned and later pioneers such as Jeff Conklin (who had worked with Rittel from 1984), could see the potential that IBIS had by utilising a computer-based visual display.

Independently from Rittel, Conklin was pursuing ways of capturing design rationale and had created his own notation called ISAAC. He recognized IBIS as the perfect solution when he heard Horst Rittel give a talk about it.

“His IBIS structure was simpler than my ISAAC structure, and his field experience with using IBIS showed that he understood the social and cognitive issues far better than any of us.  (Someone asked him what the IBIS process was for making decisions and he replied, “There is none.  Decision making is completely context and culture dependent)”

Conklin then adapted IBIS for use in software engineering and created the gIBIS (graphical IBIS) hypertext system to support this use of IBIS. Later Conklin used Rittel’s ideas about wicked problems to help motivate engineers and managers to use gIBIS on their projects. Conklin spent twenty years working with IBIS and sense-making software and systems, and all of that work now culminates today in a software tool called Compendium and a facilitation method called Dialogue Mapping. These days, utilising a projector, Compendium type software, a skilled IBIS practitioner can make a massive difference in helping a group develop a shared understanding and commitment of a problem.

To explain IBIS, let’s take a look at it being used for a well known SharePoint debate.

IBIS by example…

IBIS, at its heart, is a language specifically designed to break down the often convoluted and complex structure of a conversation into something much more simple to understand and digest. The premise of IBIS is that no matter how complex or argumentative an issue is, we can break it all down to just three basic artifacts:

• Questions
• Ideas
• Arguments (pros and cons)

There are a couple of very basic rules by which these artifacts interact (the grammar behind the language). Ideas respond to questions, offering possible solutions to the question. The arguments argue for and against the various ideas. Questions can then be expanded on or challenge other questions, ideas, or arguments.

Here is a great example of IBIS in action for a SharePoint wicked problem. Mr Oleson well and truly got himself into trouble a while back when he made disparaging comments about site definitions and hurt the sensitive feelings of many a SharePoint developer. A large thread of discussion ensued, where various people voiced their opinion in a long series of replies.

A blog, along with its comment system is typical of many collaborative mediums that are not particularly well suited to dealing with a complex issue. The whole linear nature of a blog and its comments, means that the last person to comment, in effect tends to have the last word. That is also why newsgroups and discussion forums have flame-wars that degenerate into deep threads of point-counterpoint discussion that go nowhere because the positions taken get more and more intractable. Any linear based collaborative tool suffers from the last poster having the moral high ground – until someone posts below them.

So, let’s instead build the subsequent debate into an IBIS issue map.

Joel started out with a nice, controversial statement, along the lines of “Just Say NO to Custom Site Definitions“. Sounds like an idea to me, so let’s get it into the map.

One of the rules in IBIS is that an idea is always an answer to a question. Sometimes that question can take a little while to tease out (and you may change the question a couple of times before it feels right), but it is very important that the root question be defined.

Why is this important? Well look at what happened – Joel eventually had to *clarify* his original post because of the fact that readers had different interpretations of the question he was answering. As a result, some missed the real message that he was trying to get across.

“After a lengthy conversation with all our favorite SharePoint MVPs from Andrew Connell, Robert Bogue, Todd Baginski… I need to soften some of the language here, but emphasizing in clarity what I’m concerned about in the spirit of this post”

Now, we have Joel’s “Just say no” comment captured as an idea. When you start using IBIS, you quickly find that a “comment” can take a couple of forms. As previously stated, it can simply be an idea, that is answering a question that hasn’t been specifically asked yet, but it can be a ‘bundled up’ question, idea and a supporting argument in one terse (or extremely verbose) statement.

Let’s think about the inferred question that Joel’s idea is answering. My guess is that the root question is along the lines of “What should the best practice be around SharePoint customisation?” I have worded the question quite deliberately and I’ll explain the logic a little later. I represent this new question on the issue map using the following IBIS notation.

Joel made various arguments to support his position. Let’s see if we can disentangle his very first supporting paragraph into IBIS artifacts and issue based structure.

If you don’t need to modify [site definitions] don’t do it.  Consider them product code!  If you need to build something, do it in a feature, staple the feature and deploy it in a solution.  Site Templates as tough to work with as they are, are better than custom site definitions.  Even the use of site templates is controversial in the community due to the customizations that it causes in the database.  From an upgrade perspective, it’s Much Much easier to upgrade a site based on a site template than it is a site based on a custom site definition.  Now a site template based on a custom site definition is just as bad if not worse

Above I have created 4 supporting arguments to support Joel’s idea of not using site definitions.

• The statement “Site Templates as tough to work with as they are, are better than custom site definitions”, is really using the example of site templates to highlight that site definitions are complex.
• “If you don’t need to modify them don’t do it.  Consider them product code!” is to me arguing that site definitions are used or modified unnecessarily.
• “From an upgrade perspective, it’s Much Much easier to upgrade a site based on a site template than it is a site based on a custom site definition” is another example based proposition that site definitions are difficult to upgrade.
• Finally, the suggestion “If you need to build something, do it in a feature, staple the feature and deploy it in a solution” is in fact one of those “bundled” statements that I mentioned before. Here, Joel is making a supporting argument that there are alternatives, and goes onto suggest an alternative. I captured that in IBIS by breaking up the statement “If you need to build something, do it in a feature, staple the feature and deploy it in a solution” into the supporting argument (pro) “There are easier alternatives”, followed up by a question “Such as” and the idea of using stapled features packaged as solutions.

Objectification is the name of the game!

Now step back and take a look at what we have done here. We have two major advantages over the original statement.

Firstly, participants now do not have to read a potentially convoluted set of paragraphs where the question being answered is subject to interpretation. The issue map above is simple to read, logical and easy to understand. Secondly, and most critically, I have objectified the whole thing. When you look at this map, it is pretty hard to get all fired up and defensive at it, because the root question that I placed onto the map is in effect, calling for ideas, of which Joel’s is simply one of those ideas.

Cool huh? Shall we do some more Issue Mapping?

Back to the map…

Here is Joel’s next 3 statements and the updated map

Ok so it’s easier to modify an existing site definition.  WRONG Answer!  You just broke the out of the box product and you will have a hard time getting support.  Maybe the dev support people will help you, but poor customer.  Poor support.  Poor everyone who has to pay to try to undo what’s taken place.

Don’t modify the out of the box site definitions unless you are following some MSDN article…  Even then, make sure there is no other way and you know what you are doing so you can back it out.  Always back it up.  You may even consider backing it up to disk so you’ve got it for later.

I had to listen to customers crying about what consultants came in and did to their environments in the name of “Good SharePoint Development.”  If you can, leave the site def alone, and package up your code so it can be added and later removed or replaced at least.

If you look at the map below, all I have done is reworded Joel’s idea and added a single additional supporting argument. Seems to me that the above three statements were really saying the same thing, that modifying the out of the box site definitions are unsupported by Microsoft. The rest of the arguments still fit within the first four that I captured previously.

I need someone to give me a list of reasons WHY you need to mess around with the site definitions.  I’ve had a couple of devs take me up on it, but I still think it’s WAY better if you just leave it alone and pretend like you can’t.  It will keep you honest and it will make upgrade and support TONS easier.

You’ve recently seen me in favour of client side code running server side elsewhere.  That’s great.  See if you can take things to a higher level and go with a zero server footprint deployment.  Or go with Off the shelf code where you get support for upgrade from an outside company with assurance.

I’m not totally against custom code, but I do want to see it thought through.

I’m sure nearly all SharePoint Dev classes have info on creating custom site definitions.  You may even have something in the certification test on them.

Any SharePoint developer can create a custom site definition, but the challenge is to see if they can fulfill those same requirements without using a custom site definition (The albatross around an admins neck).

Worried about users turning off the features?  Make an STSADM extension for provisioning your special site that activates the hidden feature.  Or consider feature stapling.  Get creative and think outside the V2 Box.  If you’re building custom site definitions on a regular basis you haven’t learned how to do things in the new world.

Now things get interesting. To me, Joel actually contradicts himself a little without realising. We started out with the premise of “Just say ‘no’ to site definitions”, but here he is actually adding *more* good ideas around best practices for customising SharePoint sites and less about why you should say no to site definitions. Example?

• “See if you can take things to a higher level and go with a zero server footprint deployment”
• “Go with Off the shelf code where you get support for upgrade from an outside company with assurance”
• “challenge is to see if they can fulfill those same requirements without using a custom site definition”

Remember that we now have a clear root question “What should the best practice be around SharePoint customisation?”.

I also adjusted the “They are difficult to upgrade” supporting argument to “They are difficult to upgrade and support”, acknowledging Joel’s “It will keep you honest and it will make upgrade and support TONS easier” comment.

Finally, Joel has actually offered us up two more alternative ideas, an STSADM extension, off-the-shelf code and he also mentioned again the option for feature stapling. I decided to capture these as separate ideas now and remove the “such as” argumentation that I previously used.

Below is my updated map that I think reflects where we are so far.

If you are *really* observant, then you may wonder what the little (*) is by the “Custom STSADM extension” node on the above map. All that it means is that I have more detail in that node as shown below.

Below is the rest of Joel’s opening salvo

Let’s continue to talk through the trade offs of site templates, feature stapling, and site definitions.  I think this is an important discussion.  In the future I’d love to see it to not be common at all when even hard things need to happen.

Ok, so developers don’t think much about upgrade, but let’s start preaching… Can we do this without custom Site Defs without a note from the teacher that agrees to says it’s a Requirement.  On the hierarchy of Scary Customizations.  The Custom Site Def is nearly the worst.  The only ones worse are customizing the out of the box site definitions and messing with the database and adding your own triggers and “fixing” the inefficient SharePoint stored procedures.

Todd Posts  “How to Create a Custom Site Definition” , but agrees we need to minimize what we do with them (see above).  Good job Todd, my friend, you show up as #1 using keywords… custom site definition)

I do think we need to see more about “How to NOT Create a Custom Site Definition” or

You don’t need to use Site Definitions (This is AC’s Love and the discussion) please point your devs to this one.  I continue to plan to point customers and developers to that one.

If you’re a lost developer or even one that’s looking to go through a ten step program, I recommend the Hippocratic Oath of SharePoint – First Do No Harm  (Thanks Woody).  There’s also SharePoint Dev guidance at by the Patterns & Practices Group. AC talks about it.  I’m anxious to see them provide guidance on when site definitions are necessary (yes as an IT pro, I want to see them used when features and solutions don’t do the job).

The first two paragraphs don’t really offer anything new to what has already been captured. But he then refers to Todd, Andrew and Woody’s posts. I have incorporated those URL’s into my map as reference material. If Joel had paraphrased specifically what their recommendations were, I would have created more idea or argument nodes in the map but for now, it if sufficient to simply reference those maps without linking them anywhere yet.

Remember, ideas can often “sit out there” for a while, before being worked into a cohesive issue map.

Conclusion

I believe that this issue map, as it stands, has captured the essence of Joel’s arguments thus far. As you might have guessed, part 5 is going to continue to dissect the site definition debate and continue to build out this issue map. As we delve deeper, the map will get frequently restructured. As a result, there will be lots of pretty map pictures. So, for all you readers who say you read playboy “just for the articles”, you can stop reading this series now :-).

Thanks for reading

Paul Culmsee

www.sevensigma.com.au

This is the third post in a series that focuses on what I think is the Holy Grail of project success – particularly SharePoint projects. Like everybody else, I am a product of my experiences, and one of these experiences was a project that included one of my greatest career teachers – “SharePoint-vs-Skype guy”. If you have not yet heard of this luminary of SharePoint folklore, then I suggest you go back to Part 1 of this series and start there. Starting here at part 3 really makes no sense at all…seriously.

I’ve spent two posts explaining my so-called journey to enlightenment and in part 2 of this series, I made the assertion that the *true* root cause of failed projects is usually a lack of shared understanding (and therefore shared commitment) among project participants. This root cause is often misdiagnosed because it is reflected in more visible symptoms such as scope creep, vague/incomplete requirements, mismatched expectations and general all-round unpleasantness. I also spoke about my journey toward “problem fundamentalism”, where I have come to believe very strongly that if you can achieve and maintain that illusive “shared understanding” of a problem among participants, then the actual process that you adopt to implement the solution really doesn’t matter that much. In essence I am echoing the inventor Charles F. Kettering when he once said

A problem well stated is a problem half solved.

Let’s now turn our attention to the “how” of shared understanding.

“Inappropriate methods”

Rittel and Conklin say that many groups fail to recognise that they are dealing with a wicked problem, or a problem that has taken on wicked tendencies. As a result, they apply inappropriate methods to deal with them. There are a few reasons for this, but two major ones stick out in my mind.

The first reason is the “unconscious incompetency” factor, which is training speak for “you do not know what you do not know”. In other words, if you have never heard of wicked problems and their nature, how are you supposed to know how best to deal with them? Thus, like any other form of enlightenment, you have to move from unconsciously incompetent to consciously incompetent (you now know that you do not know) before anything else. This series of posts hopefully is doing the trick here.

The second reason is that the visible signs of wickedness manifest themselves as scope creep, incomplete requirements, wheel reinventing and the like. Since I have already asserted that these are actually symptoms and not the true root cause, the usual methods used to try and deal with them are treating those *symptoms* and not the true cause. At the very least, traditional techniques are inappropriate and at the very worst, they are going to make things significantly worse!

Jeff Conklin recently said this about shared commitment:

The ‘Holy Grail’ of effective collaboration is creating shared understanding, which is a precursor to shared commitment. If you accept that the crux of effective action is agreeing on what the problem is, then the challenge for organizations is coming to a shared understanding about what their particular dilemma is. Plenty has been written about how to get people ‘on board’ and create buy-in for a strategy; but the business of how to craft shared understanding – a deep and robust understanding of the circumstances – hasn’t been well understood. Shared understanding means that the stakeholders understand each other’s positions well enough to have intelligent dialogue about their different interpretations of the problem, and to exercise collective intelligence about how to solve it.

With Jeff’s quote in mind, let’s take a look at these traditional techniques and see how guilty we all are of using them 🙂 .

It’s the process stupid!

It is almost universal to blame all of the world’s faults on “process”. I went through this line of thinking as I was off in my “theory cave”, trying to make sense of “SharePoint vs Skype” guy and other mysteries of life. What logically follows from this is usually the implementation of some sort of best-practice methodology, in the guise of program or project management office. This in turn creates a lot of extra rigour around the activities and processes around *solving* problems. Don’t get me wrong. Process, structure and consistency are actually critical, but problem wickedness and shared understanding are in the *sensemaking* space. The problem is that most best-practice standards and methodologies are very much focused in the *solution space* and tend to work on a presumption of more shared understanding than is actually the case. Again, this is due to the focus on treating the symptoms of problem wickedness. For example: “You have a scope change? Well, let’s fill out a change request form then”.

As a result, the whole sensemaking half of the puzzle is entirely missing!

CleverWorkarounds’ Hindsight Rating: This is why a lot of SharePoint governance plans and information architecture exercises are misfocused or simply miss the point.

Nail the scope, baby!

The other common way to try and tame things is to restrict or lock down the scope. I’m sure all readers have engaged in this. The idea being that if we solve this smaller, more constrained bit of the problem, we can then solve the harder bits later. The great flaw in this logic is exposed once you understand the symbiotic relationship between problems and their solutions that I spoke about in part 2. To recap, each time you think of a potential solution, you will always have an effect on your understanding of the problem. This was Rittel’s first characteristic of a wicked problem and it fed the endless loop of the second wicked problem characteristic – the “no stopping rule”. Therefore, by restricting scope and implementing a smaller subset, you will likely significantly change the understanding of the problem among the participants to the point where you can be in an even more fragmented position than you were in the first place.

In other words, the goalposts have moved in the meantime and the scope is no longer relevant. Stakeholders with hindsight question the very logic of that original scope restriction!

CleverWorkarounds’ Hindsight Rating: It’s so easy in hindsight 🙂

The umpire is always right, right?

Sometimes a group will become so fragmented in their understanding of a problem and therefore become completely polarised on the various solutions. The positions become so intractable for some that even to talk about other options, gives those options more credence than deserved. For example, to an ardent mac or linux fanboy, Microsoft are so evil and nasty that you should not use their products like … ever, dude!

When this occurs, usually after a long, arduous and spiteful process of trying to reach consensus, parties will often give the problem to a “higher source” and agree to abide by their decision. This could be your mother, the CEO, or the International Court of Justice in the Hague. The point is that the decision process is transferred from many to a few. In doing so, we rely on the knowledge, expertise and authority of that higher source.

This does tend to speed things along because when buried in the mud of analysis paralysis (symptom of endless looping between problem and solution), the desire to “shut-up and make a decision already” can be very strong. The tradeoff with this approach however, is that the decision makers themselves are inherently subjective and may disregard what some see as critical considerations. Since this is a win/lose proposition, stakeholders can become disenfranchised and although the decision has been made, there is no true shared commitment to implementing that decision.

CleverWorkarounds’ Hindsight Rating: If there is no shared commitment then it doesn’t matter how technically valid the solution is. It’s still dead.

Selling Ice to Eskimos

Many organisations (and in particular, governments) use a competition based method to deal with complex problems. Just like the previous example with entrenched, seemingly intractable positions, outcome will be determined by the forces of competition. The theory is that the best ideas will stand up to scrutiny and rigour and via a process of natural selection, the best will survive.

This method of competition between potential solutions, and the stakeholders that propose them actually has some distinct benefits. For example, it can foster innovation, sharpen the sensemaking focus of participants and provide good solution choices.

Unfortunately, as with all forms of competition, someone has to lose, and as a result, people do not always like to play fair. Whether it is Olympic athletes drugging themselves with steroids or certain corporations taking illegal advantage of their dominant market position, competition is often a very dirty game. A great case in point is the debate around Intelligent Design. It is argued by some that intelligent design is a scientific theory and should be taught in schools. But critics argue that the concept is simply an ingenious way to get around the 1987 US Supreme court ruling that creationism based science being taught in science in public schools violated the constitution, because it advanced a particular religion. Whether the latter view is right or not, it is still a great case study in how the rules of the game can be manipulated.

CleverWorkarounds’ Hindsight Rating: Marketing has a lot to answer for!

The paradox of shared understanding

Given that complex problems have a lot of interlocking and multi-causal factors, combined with the social complexity of multiple stakeholders with different world views, is it any wonder that traditional methods of reining in haywire projects are largely ineffectual? Traditional thinking across many disciplines suggests that problem solving is a linear process. Whether you are trying to work out where to put a freeway offramp or install a SharePoint internet site, the process would usually start by defining the problem, gathering data, analysing that data and then planning and implementation of the solution. Call it “waterfall”, or the “scientific method” or whatever, this approach has been around since… forever.

I wrote in more detail about the perils of waterfall in the project fail series in the section “how we really solve problems”.

But here is the problem with that approach. Those complex, interlocking issues and social complexity cause significant differences in opinion on the best solution, yet we need all of the diverse views to really gain a true, deep understanding of the problem and obtain the critical shared commitment that we need. The “no stopping rule” means that it is exceedingly difficult to determine when participants have *sufficiently* defined the problem, gathered data or formulated a solution.

So, how can we reconcile this paradox?

Is it possible to have a holistic, systems approach to examining the deep structure of an issue, that somehow allows us all to see the illusive big picture, without the inefficiency of “analysis paralysis” and the endless loop of the “no stopping rule”? (not to mention and the other nine characteristics of wickedness that Rittel identified). How can we, as a diverse group of stakeholders, fully explore a problem and gain the deep understanding of an issue without social complexity and those wicked factors derailing everything?

This is a question that Horst Rittel spent a lot of time thinking about and by 1970, had developed a potential answer. In part 4 I will tell you what his answer was and what it has now become, thanks to Jeff Conklin.

Thanks for reading

Paul Culmsee

Kristian Kalsing was written a really terrific post, not just because he quoted yet another bloody international standard that I will have to now read (ISO15489). But because, drawing on his experiences of the world of SAP, he has observed that there are some important lessons that can be learned for SharePoint engagements. SAP (okay, well Basis anyway) is a world that I experienced way back in 1999 and, boy, can I write some stories about social complexity and project failure about that era!

Kristian observes that on SAP projects, the roles of consultants are typically very clearly defined and discipline based. For example, there are infrastructure (Basis) consultants, developers and functional consultants. Even within functional consultants, there are sub-disciplines of expertise. (Hope you don’t mind me quoting you Kristian).

The point is that the consultant configuring the finance module is basically an accountant and the consultant configuring the HR module probably studied human resources at university. In the SAP world, it would be absurd to take someone who has configured materials management or plant maintenance with one client and ask them to configure HR with the next. In SAP, the specialisation does not stop with the functional areas of the product. There are also functional consultants building up experience in certain industries. E.g. supply chain management can be very different when talking coal mining compared to running supermarkets.

Kristian observed that this notion of functional consultants does not occur in the SharePoint world. However, he qualifies this by observing that SAP is much bigger than SharePoint and therefore a direct comparison is "bit of a stretch", yet lessons can be learned. On the ‘bigger’ point I actually disagree and think that the context of ‘bigger’ is relative (and I look forward to Kristians’ opinion on my take). SAP and ERP systems are massively bigger and more complex than SharePoint – without a doubt. SharePoint may not be as big as SAP in terms of feature-set and complexity, but it can actually be just as big as an ERP system in terms of the impact on the day-to-day workings of staff.

To paint a gross generalisation, with an ERP system, often all that many end-users will ever see is a system to enter their time-sheets and perhaps perform some HR functions such as apply for leave or check pay-slips. Not everyone directly sees or interacts with, say, financials, plant maintenance and the like. But you can be pretty damn sure that everyone saves files to G:\ drive on a daily basis. (Substitute whatever your drive letter is that represents your jungle that is the file system).

More staff = more social diversity = more differing opinions = more complexity = bigger scope = more options = even bigger scope = wicked problem

Therefore, it is not a case that "lessons can be learned from the SAP world", but it is a case of "lessons should be learned from the SAP world".

But here is one additional (admittedly subjective) point to consider.

ERP systems have a really bad failure rate. Does the fact that there are discipline specific functional consultants involved really hold the key to project success?

Don’t get me wrong. I think that SharePoint functional consultants are a critical piece of the puzzle and, by god, the world can do without Microsoft gold partners throwing one of their "technical" people at what is essentially a project with a huge training and advisory component. But succeeding in SharePoint – or any other discipline involving complexity and a large diversity of stakeholders, goes deeper than that.

The difference between a "functional consultant" and a "great functional consultant" is not only domain specific knowledge. It is the art of helping diverse stakeholders to disentangle complex problems from a cluttered maze of overlapping issues, the moving target of requirements into an environment where all participants have a shared understanding.

I’ll have more to say about this as I delve deeper into the "One best practice…" series.

Thanks for reading

Paul Culmsee

Hi all

This is part of a somewhat self-indulgent story of how I came to practice a craft that has made a profound difference on how I approach and manage SharePoint projects. If you have not read part 1, then I suggest you stop now and read that first. This post will really not make a lot of sense, otherwise :-).

In my last exciting instalment, I had concluded with the time where I discovered the term “Wicked problems” and the work of Horst Rittel, who coined the term. In his landmark 1973 paper, Rittel identified ten common characteristics of wicked problems. I remember quite distinctly, reading through that list for the first time, having this strange sense of relief. Of the characteristics, most of them had *clearly* manifested in my SharePoint-gone-haywire project. The relief stemmed from the fact that it was a recognised phenomena with a tendency to defy traditional problem solving techniques. The characteristics with which I immediately identified are marked in bold below.

1. There is no definitive formulation of a wicked problem.
2. Wicked problems have no stopping rule.
3. Solutions to wicked problems are not true-or-false, but better or worse.
4. There is no immediate and no ultimate test of a solution to a wicked problem.
5. Every solution to a wicked problem is a “one-shot operation”; because there is no opportunity to learn by trial-and-error, every attempt counts significantly.
6. Wicked problems do not have an enumerable (or an exhaustively describable) set of potential solutions, nor is there a well-described set of permissible operations that may be incorporated into the plan.
7. Every wicked problem is essentially unique.
8. Every wicked problem can be considered to be a symptom of another problem.
9. The existence of a discrepancy representing a wicked problem can be explained in numerous ways. The choice of explanation determines the nature of the problem’s resolution.
10. The planner has no right to be wrong (planners are liable for the consequences of the actions they generate).

But the real clincher – the moment that made me realise that my frustrating journey through standards, methodologies and best practices was finally coming to an end was the 5th characteristic. “Every solution to a wicked problem is a “one -shot operation”. When I read that one, it was as if my famous “Skype-vs-SharePoint” guy suddenly materialised in front of me and mooned me saying over and over again “I can collaborate on Skype, too!”

For those of you who skipped part 1 despite warnings, “We only have one shot at this” was pretty much a word-for-word quote on what was said to me in the haywire project that started all of this.

Is it any surprise that I felt I was onto something here?

Digging deeper

When I read Rittel’s 1973 paper, I began to get a deeper understanding of what he meant by his first two characteristics that I didn’t immediately identify with. Namely “there is no definitive formulation of a wicked problem” and “wicked problems have no stopping rule”.

I soon realised that these two characteristics were actually the most *prevalent* characteristics of complex IT projects and therefore, the list was even *more* relevant to me than I had originally thought. After that, I was a convert. Rittel explained the first characteristic as follows…

The information needed to understand the problem depends upon one’s idea for solving it. That is to say: In order to describe a wicked-problem in sufficient detail, one has to develop an exhaustive inventory of all conceivable solutions ahead of time. The reason is that every question asking for additional information depends upon the understanding of the problem–and its resolution–at that time. Problem understanding and problem resolution are concomitant to each other.

The second characteristic, “no stopping rule”, is a natural consequence of the above issue. Again, quoting Rittel from 1973…

Because (according to Proposition 1) the process of solving the problem is identical with the process of understanding its nature, because there are no criteria for sufficient understanding […] , the would-be planner can always try to do better. Some additional investment of effort might increase the chances of finding a better solution.

Skype-vs-SharePoint guy, who now has the credit of being one of the most significant unwitting teachers of my career, went from not knowing any difference between SharePoint and Skype, to suggesting work items that already existed in the project plan, to telling us how we should build our information architecture based on 1990’s era document management systems. It was crystal clear that he went through this iterative process of changing his understanding of the problem based on how much thought he had put into the solution.

The sad fact was that Skype-vs-SharePoint guy was not unique. He might have been an extreme case, but in reality, he was simply the latest in a long line of users and stakeholders who I would have previously dismissed as idiots, computer illiterate or just plain tossers. Is it any wonder why we have the scourge of “scope creep” and “vague and incomplete requirements” that are so commonly cited as project failure factors? How many times have you banged your head against the wall thinking “How can we build a system when they don’t know what they want!”?

Problem fundamentalism

So in a way, we, as solution architects, developers and consultants, are just as much at fault as those users who we chastise because they “don’t know what they want”. Why? We fail to recognise or account for the immutable fact that understanding of a problem is not cut-and-dry. It almost certainly will change over time as people mull over, work through, learn from and grapple with the nature of a problem and the complexities of the interlocking issues that form the problem. To make matters worse, we all do this *individually* and at *different speeds* with *different value sets*. Inevitably, we arrive at different conclusions based on different paths we take on making sense of it all.

That cyclical nature of understanding the problem, based on understanding the solution, does not automatically stop once the scope document has been signed off, either. It will continue over and over again as a perfectly natural part of the learning process. With that in mind, consider all of the studies that have looked into factors causing project failure (uncle google shows up many studies). All of the usual suspects are there. For example…

• Scope creep
• Incomplete requirements
• Unclear objectives
• Lack of user involvement
• Unrealistic or overly optimistic time frames
• Lack of resources

blah…blah…blah – I am sure that you have seen these before.

If you accept Rittel’s assertion that the problem and the solution are intertwined and concomitant, then it is clear that the sorts of factors listed above are merely *symptoms*, not causes. *Of course* there are incomplete requirements and scope creep. There would have to be incomplete requirements and scope creep almost by *definition* for a complex project. For a long time I had instinctively felt this way, but I couldn’t quite put my finger on it… until SharePoint-vs-Skype guy, Horst Rittel and Jeff Conklin showed me the way.

At the end of the day, it all boils down to this:

Projects fail principally because there is a lack of *shared understanding* among the participants of that project. Additionally, shared understanding is a prerequisite before the key thing that makes or breaks a project – shared commitment.

(Stunned silence … Paul hears pin drop)

I can imagine some reader comments at this point:

• “Big $%#$ deal, tell me something I don’t know”.
• “What the….you made me read through one and a half blog posts for *that*?”
• “So what theory-boy, tell me *how* to actually develop shared understanding”
• “Paul can you tell me the difference between SharePoint and Twitter?” 🙂

To be fair, I think most people know instinctively that a lack of shared understanding is the major cause of projects being comatose before they barely got off the ground. But if it was so obvious why does scope continue to creep? Why are objectives still unclear? And, why are requirements and specifications incomplete? To answer that, we need to turn the “shared understanding” assertion around and ask it in this way.

Let’s suspend reality and just assume for a minute that all participants have an *identical* deep and tacit understanding of a really complex problem. Would we still have the incomplete requirements, unclear objectives, scope creep, unrealistic time frames that are cited as project failure factors?

I say “no” from a philosophical standpoint, but a “Well, yes… but much less than what normally happens” from a pragmatic standpoint.

Thus, I started to look at my SharePoint engagements through different eyes and became what I now think should be called a “problem fundamentalist”. I began to believe that if you could achieve the utopian dream of complete shared understanding among participants at the very start of a project, then really, you could use any methodology you like to actually manage the problem and implement the solution. The common factors of project failure would fall drastically.

So finally for now, is it simply just a matter of dealing with the little question of *how* to actually achieve this goal of shared understanding?

We will talk about that in part 3…

Thanks for Reading

Paul Culmsee

Hi all

I have been extremely quiet on the blogging front lately, because I have been extremely busy, splitting my time between working on my two presentations for the up-coming Best Practices SharePoint Conference, as well as wearing my undies on the outside (ala superman), deep in the bowels of some unhealthy SharePoint farms, nailing various technical and governance issues and helping organisations regain some lost assurance. On top of that, I’ve also been doing a lot of non IT related work in a group facilitation discipline.

I thought it’s about time I emerged from this big mushroom I find myself under to let you know more about what I will be speaking about, as well as some of the other speakers and topics that I really looking forward to. Seriously, we are in the company of giants with this conference. The caliber and quality of the speakers has me wondering what the hell I am doing there!

I mean we have all the "A list" big kids of the SharePoint world there. Gary Lapointe is a freakin’ bona fide superstar! – via his STSADM extensions, he has saved the asses of more SharePoint admins and developers than even Joel has. Robert Bogue is an even better all-rounder than Andrew Symonds (sorry non cricketing countries you won’t get that analogy) and touches on a wider variety of topics than anyone else I have ever come across. Then there the likes of Andrew Woodward, Ben Curry, Bob Mixon, Eric Shupps, fellow metalhead Mike Watson, Ruven Gotz and Todd Bleeker just to name a few!

Somehow I have to squeeze in a beer with all of them yet stay sober enough to present. That’s a tough ask!

Anyway, both of my sessions are in the CIO stream and I think are rather topical given the current financial crisis crap that is happening around the world.

My first session is called "How to avoid SharePoint becoming a wicked problem". This is a pet topic of mine – something that I have spent a lot of time on, and developing new skills in (hence the aforementioned facilitation work). For the record, I didn’t make up the term "wicked problem" – its been a subject of academic research since the term was first coined in the early 1970’s. This session is going to cover a lot of what I have learned on this topic including how to spot SharePoint wickedness early, recognise it for what it is, and apply the *right* sort of tools and techniques to mitigate it.

I do worry that people will find some of my stuff a little too left field, but I do have the results to attest to the value and power of these techniques and I am really looking forward to sharing my methods and comparing with what has worked for other presenters and attendees.

The second topic is on the topic of good old SharePoint Return on Investment (ROI). I’m one of these people that believe most things can be measured or quantified. I’ve always wanted to return to my series on "How to Speak to your CFO" and continue down that road. Given we have entered once in a lifetime era of falling profit, plummeting asset prices, reduced budgets, costlier finance and great uncertainty, my quest for bringing a lasting peace to the cold war between managers and geeks moves to San Diego 🙂

My aim for this session is to allow non SharePoint people to understand where some of the hidden costs are SharePoint, as well as show SharePoint people the basic financial tools for ROI modelling and secondly, I will explain how to build an ROI decision model and provide a scenario that we will try out some different assumptions with.

As for the rest of the veritable *buffet* of topics – where do you start? First up, I am torn between Bill’s "Aligning your Information and Findability Architectures using SharePoint Server 2007 Technologies" and Yoda Bogue’s "Selling Governance in your Organization". If I go to Bill’s session, then I’ll definitely be attending Robert’s Governing Development in SharePoint session.

In the afternoon, it gets even harder! You have "Transform the My Site into an Information Hub" by Mark Eichenberger, Bob Mixon’s "Learn why Taxonomies are the Most Important Part of any Document or Information Asset Management System, How to Facilitate the Government out of Governance by Virgin Carrol and Nuts and Bolts Governance- Practical Application of the Concepts

.. and that’s just day one!

Seriously people, no matter that sort of SharePoint sub disciplines push your buttons, you are going to get extreme value for money here. You will come away with an amazing amount of material that will result in real and tangible cost savings across various areas of the SharePoint realm.

If you live in California or anywhere in the US – there is no excuse 🙂 If *I* have to spend 25+ hours cooped up in  plane just to get there and survive the jet-lag to present, then you should come on down and join the fun.

Hope to see you there!

Paul Culmsee

Oh how times change! I am reading a good book at the moment called "Competing on Analytics – The New Science of Winning" and I hit one particular quote that I have to share with you. It’s one of those statements that makes perfect sense at the time, but is kind of funny when you look at it in the context of recent world events in the financial markets.

…But in other cases, analytics can permanently transform an industry or process. As Money-ball and Liar’s Poker author Michael Lewis points out in talking about investment banking. "the introduction of derivatives and other new financial instruments brought unprecedented levels of complexity and variation to investment firms. The old-school, instinct guys who knew when to buy and when to sell were watching young MBA’s – or worse, PhD’s from MIT – bring an unprecedented level of analysis and brain power to trading. Within 10 years the old guard was gone".

I love that line "analysis and brain power", given the contribution of derivatives to the prospect of a "teensy weensy" global recession. Mind you, how much ‘analytics’ do you think is going into current decisions and company valuations on the stock market?

Where are those old school guys? I want ’em back!! 🙂

This project was not SharePoint, but I have seen some people try and do this with SharePoint. But you can imagine how much stress this project would have caused to participants.

The South Australian government has pulled the plug on its $5 million records management system project, ending a five-year saga plagued by repeated cost blowouts, delays and confusion

http://www.australianit.news.com.au/story/0,24897,24510560-15306,00.html

I can’t help but feel that if this particularly wise and insightful document written by their federal government counterparts had been written a couple of years earlier, some of sting just might have been taken out of this example of expensive project failure.

Many of the most pressing policy challenges for the APS involve dealing with very complex problems. These problems share a range of characteristics—they go beyond the capacity of any one organisation to understand and respond to, and there is often disagreement about the causes of the problems and the best way to tackle them. These complex policy problems are sometimes called ‘wicked’ problems

Critically, tackling wicked problems also calls for high levels of systems thinking. This big picture thinking helps policy makers to make the connections between the multiple causes and interdependencies of wicked problems that are necessary in order to avoid a narrow approach and the artificial taming of wicked problems

Read the full document here:

http://www.apsc.gov.au/publications07/wickedproblems.htm

Here we go… another Cleverworkarounds waffle!

Now, we all know that Joel Oleson is the Russell Crowe of the SharePoint world! I mean, he’s multi-skilled, loads of talent, has the respect of his peers and has built a well deserved reputation of being one of the best at what he does. (Although unlike Russell I am fairly sure that he has not thrown a telephone at an annoying IT manager in a fit of rage just yet).

But despite his best intentions and with his heart in the right place, Joel is one of the unwitting architects of a butterfly effect that is now plaguing the SharePoint world. One that is now causing much pain and damage to already beleaguered enterprises.

In short, he set the wheels in motion that helped destroy a word via buzzword abuse 🙂 That word is…

"Governance"

See, way, way back in the bowels of time (okay, around 2006), when the stock market was soaring and therefore SOX compliance was being conveniently ignored by investors in equities, Joel’s blog was one of a couple of blogs of any significance SharePoint-wise. He was out there doing his bit for the common good, stressing the importance of governance in the SharePoint world before the word governance was really used in this context. Joel cited this article by Matthew Cain at Gartner which seems to be the root of it all. Now this is perfectly fine and dandy, but Joel made one fatal mistake that we are still feeling the effects of…

He de-nerdified his blog and made this stuff accessible! Thus, somewhere in the world, a marketing person read it and understood just enough syllables to get a gist of what Joel was talking about. Sensing the opportunity to add a new word to glossy brochureware, from that moment forward the true meaning of "governance" was lost forever as the snowball effect of a new buzzword taking root gained momentum. As the snowball rolls faster, more and more vendors get onto the bandwagon, each skewing the definition to suit their own ends.

So now, I am afraid that governance is now irreversibly sliding down the same slippery slope as such luminaries as "convergence", "portal", "ubiquitous", "social networking" and the current cream of the crop – "web 2.0".

…and it’s all Joel’s fault, right? 🙂

So, how to reclaim this word? I don’t know if you can. I have, however, decided to start a social experiment making my own future buzzword. More on that in a minute.

Governance = systems thinking

Before I present my version of what governance really means, I want to enlighten you to an important philosophical concept that underpins governance called "systems thinking" or "the systems approach". Systems thinking approaches problem solving from the perspective that the problem must be looked at as parts of an overall system, rather than focusing on individual outcomes. Wikipedia has quite a nice quote which captures the philosophy nicely.

Systems thinking attempts to illustrate that events are separated by distance and time and that small catalytic events can cause large changes in complex systems. Acknowledging that an improvement in one area of a system can adversely affect another area of the system, it promotes organizational communication at all levels in order to avoid the silo effect.

Either I have been officially typecast, or many organisations are feeling the same pain. The reason I say this is because I’ve been called in to assist organisations that are suffering a crisis of confidence with the SharePoint platform. In each case there are one or more highly visible and persistent problems that are causing user dissatisfaction. That translates to a stressed and under-confident SharePoint/IT project team who are questioning the validity of the SharePoint platform.

My brief in each was to help them pinpoint the root cause of their immediate pain, but in the context of a more holistic review of the SharePoint service to try and identify the gaps that allowed the situation to arise in the first place. The interesting fact about these sites is that they did have governance plans and on the surface of it all, most of the boxes could be ticked.

So, what went wrong?

It all boiled down to this: Stakeholders had a different interpretation of what governance actually means – the curse of a buzzword!. Most stakeholders in fact were more interested in the fact that they had a thirty page document someone wrote with "Governance plan" in the title and thought "okay that’s done, what’s next?".

This is not a systems thinking approach and therefore, this is not good governance. In fact, it really has missed the point entirely.

"SharePoint Assurance" is the new buzzword :-) 

At the end of the day, there are two immutable facts of working life.

1. We are all accountable to someone. Whether it is the board of directors being accountable to shareholders or the guy on the helpdesk being accountable to his operational manager, the vast majority of us are tasked with various responsibilities that our performance is judged on. If we fail to perform to the expectations, we not only let ourselves down, but we can adversely affect others.

2. We all want to go home from work, secure in the knowledge that we performed what was expected of us and we are still going to have a job tomorrow.

Both of these facts underpin the principle that we are all cogs in a complex organisational machine where our individual (and organisation-wide) fate is reliant on each other in complex, often implicit interdependencies.

Governance therefore is all about providing assurance. If you do not provide assurance, you will have fear, uncertainty and doubt. Take a look at the stock markets crashing around the world. Clearly assurance is in extremely short supply!

A Social Experiment

Now what I want to do twofold. For some strange reason I see the funny side of creating a new buzzword and see how long it takes to get to a brochure. Thus I am officially raising a virtual flag and laying claim to being the first person to use the term "SharePoint assurance" instead of SharePoint governance. (at the time of a writing a google search on this phrase yields only 5 hits).

Once you see the term in a marketing brochure, please let me know 🙂

But on a more serious note, I think that assurance in the SharePoint space can be done a lot better than it is and I have a few ideas on how this can be achieved.

More (hopefully much more) on this topic area soon…

Thanks for reading

Paul Culmsee