The one best practice to rule them all – Part 5

Hi again and welcome to the fifth article on this series of posts on the topic of group sense-making and the pursuit of shared understanding among a group of participants trying to solve a problem. If you haven’t read the previous articles of this series, then I strongly recommend you go back and read the previous articles in order.

If you have read through the first 4 posts, you should have a pretty good appreciation now for the sort of “lens” that I view the world of problems and the projects undertaken to try and solve those problems. You should also have a pretty solid appreciation of the concept of wicked problems, their characteristics, and the ways and means that those characteristics can turn a happy project into a toxic wasteland, destroying all of the initial enthusiasm and commitment among the participants. Microsoft’s Jason Guthridge recently nailed SharePoint’s place in it all when he wrote the immutable law of SharePoint that “By itself, SharePoint can neither create nor destroy organizational chaos, but does an excellent job of reflecting the level of organizational chaos that existed at the time of deployment” – hehe love that!

I approach all my engagements these days from the point of view that project failure is not due to a lack of rigour or governance around any project management methodology. More often than not, the root cause is in “organisational chaos” and this is *not* a process problem. It all boils down to the fact that shared understanding among a diverse team is an illusive goal which is deceptively difficult to achieve and maintain. That is because SharePoint’s technical complexity gives rise to social complexity. At the end of the day, we all have vastly varying behavioural and learning styles, we all come from varying organisational cultures, have different skills in varying disciplines and have different value sets and life skills. A collaborative platform almost by definition forces us to confront and work through this social complexity and that is where chaos and wicked problem characteristics find a fertile breeding ground.

It is this same underlying social complexity that makes SharePoint governance so hard. That is because governance at its essence is about accountabilities and risk. In short, governance is an attitude and the fact that it is a shared responsibility among participants gives rise to those same “people issues”.

But of course, none of this is helped by the common misdiagnosis that project failure is a failure of process. Although I believe that process is part of the answer, when we look at project failure as a process issue only, we inevitably apply process oriented tools and methods to get things back on track. But if you agree with me that a lot of the time, the real issue is the lack of shared understanding among participants, then it is clear that we are missing a critical step before we dive into process oriented solutions. How do we know that we are all on the same page? Will a 40 page project charter and project management plan do the trick? History tells us fairly convincingly that the answer is no.

Thus, in my last post I described IBIS (Issue based Information System). IBIS is an issue based argumentation system developed in the 1970’s by Horst Rittel and further refined by Jeff Conklin. I described the craft of Dialogue Mapping – a *practical* method that leverages a simple grammar and a shared display, to help groups gain understanding of complex problems right at the very beginning of the journey. This prevents the usual problem of jumping past the sense-making phase too quickly by diving headlong into process and rigour. Even before a project charter is committed to paper, IBIS fills that sense-making void that most of the other methodologies presume exists, but is rarely there in sufficient detail.

For an interesting little experiment, if you have found this series to your liking, now go back and look at your last project management plan and specifically re-read the charter and problem statement. Is it more than two paragraphs? Would all stakeholders read it and then tell you the exact same understanding of the problem being solved?

More IBIS and Issue Mapping

Now if you recall part 4, I created an IBIS issue map to demonstrate the arguments made by Joel Oleson some time back, when he wrote an article that was originally entitled “Just say no to site definitions”. It caused some vigorous debate at the time, and I demonstrated how I was able to both simplify and objectify Joel’s post into a simple issue map that was very easy for any reader to understand. That map is below and this is our starting point for part 5. Have a good look and if you need a refresher on how it was created, refer to part 4.

Now it is time to map some of the counter arguments made by those who responded to Joel’s ideas. The first response was anonymous and made various counter points. Let’s take a look at the first half of the counter spray :-).

Are you serious? You prefer STP files over a custom site definition? Man, you obviously have never had to try to build a solution around STP files before.

• For one, you can’t feature staple to an STP file, so you are simply limited to the manual UI customizations. To run automation when a site is created, you need to use a site definition with a provision handler or feature stapling.
• STP files are buggy, and sometimes you will randomly get errors like this one in your navigation bars: http://www.sharepoint-tips.com/2007/09/wrokaround-error-in-navigation-when.html
• STP Files do not support sites with the publishing feature activated.
• STP files do not package all your settings, especially content type visibility and column visibility on lists and
  libraries: http://www.sharepointblogs.com/toth/archive/2008/08/08/the-problem-with-content-types-and-columns-part-2.aspx
• If an STP relies on elements from other higher-level sites or lower-level subsites, good luck.

The first line of the response is actually very interesting from an IBIS nerd viewpoint because and it a perfect example of social complexity playing out and it made decide to change major aspects of the map. The above respondent immediately honed in on something that wasn’t actually all that clear to me to begin with. When I first mapped Joel’s statement in part 4, I never actually put the idea of using site templates into the issue map. Why? because Joel never actually suggested it! The closest he came was the statement “Site Templates as tough to work with as they are, are better than custom site definitions”. But I interpreted this as using the example of site templates to highlight the complexity shortcomings of site definitions. I simply captured the argument of “complexity”, supporting the idea “Do not use site definitions”.

But look here! Our first respondent interpreted it completely differently to me. They inferred (likely correctly) that Joel prefers site templates over site definitions. But the response then takes a shot at Joel’s credibility.

Are you serious? You prefer STP files over a custom site definition? Man, you obviously have never had to try to build a solution around STP files before

If that exchange happened in a meeting, you may as well call it quits, because it would be very likely that very little valuable dialogue would be obtained after such an exchange. Participants are on the defensive and the meeting will likely get derailed on this tangent. But this is a terrific example of how using IBIS grammar is extremely effective at teasing out ambiguous or poorly formed argumentation, thereby removing the “sting” out of these sorts of debates.

So what should this map look like then? Below is a new version with a few key adjustments.

The most obvious change that I have made to the argumentation presented above is Joel’s original idea. I have removed the negative connotation of “Do not use site definitions” to “Use site definitions”. As a result, the previous pros now become cons, because they are no longer supporting the idea. I did this because I have also added the idea “Use Site Templates”, so now we have presented the two ideas without any inferred bias and can simply examine the characteristics, pros and cons of each idea.

For what it’s worth, engineers sometimes unconsciously word questions in a manner that non engineers find biased because of the implied connotation. You can read more about this in my “it’s all how you ask the question” post.

Finally, I also removed the “there are easier alternatives” pro from the map altogether. I did this because this argument has became somewhat redundant. Note how we are now exploring all of the alternatives as separate ideas in the map anyway. More importantly, what does “easier” mean anyway? What is “easier” for an IT pro type person like Joel may be very different to what is “easier” for a SharePoint developer”.

Stepping back

The ability to restructure a map on the fly is one of the key benefits of IBIS. A skilled IBIS practitioner is able to quickly restructure the map as the conversation moves around the various topics, all the time leveraging collective intelligence of the group as they dissect the problem together.

Another key improvement from the previous map is that we have further objectified things. Our first respondent also supplied some great factual counter arguments to Joel, but hid it behind an initial barb that could easily be inferred as a cheap shot.

Nevertheless, here is the portion of the map with showing the additional argumentation from the respondent about using site templates. Now we are getting somewhere!

Let’s examine each of the statements of the respondent. All of the arguments made were dumping on site templates in some way, so we capture them as cons to the “Use site templates” idea. The respondent actually did a very good job with his arguments and they were very easy to add to the map.

• The statement “For one, you can’t feature staple to an STP file, so you are simply limited to the manual UI customizations. To run automation when a site is created, you need to use a site definition with a provision handler or feature stapling”, is a bundled up statement. There is the con argument “feature stapling cannot be used”, with an implication of that argument being “Can only customise manually”. I broke that out into three IBIS elements
• “STP files are buggy, and sometimes you will randomly get errors like this one in your navigation bars” is stating that there are bugs, and supports that argument by stating a specific example of one. I split this out into separate IBIS elements and additionally linked to the specific example.
• “STP Files do not support sites with the publishing feature activated” is a nice, simple argument that I captured as “Not supported with the publishing feature”.
• “STP files do not package all your settings, especially content type visibility and column visibility on lists and libraries” is again a nice counter argument backed up with examples.
• Finally, the comment “If an STP relies on elements from other higher-level sites or lower-level subsites, good luck”, is in effect stating a counter argument that site template files to not handle dependencies. In case this paraphrased statement is ambiguous, I added additional detail to this node with the original argument as shown below.

More arguments against?

Below is the rest of the response that is nowhere near as clear as the first half. Let’s drill down…

I disagree, I think it is lazy devs that want to use an STP file, instead of creating a custom site definition, just like it’s laziness to create a content type through the UI for a custom solution instead of in XML with a feature (which can then easily be moved from environment to environment).
And honestly, is it really easier to go through the machinations to customize the MySite template as recommended here (http://blogs.msdn.com/sharepoint/archive/2007/03/22/customizing-moss-2007-my-sites-within-theenterprise.aspx) to simply move a few web parts around, rather than just make a tweak to the original site definition? Honestly which is less maintenance for a customer, a quick documented change to an XML file in a folder, or a Feature+WebControl+Custom master page+stsadm commands to activate etc.?

I think you are way off base here, and painting with broad brushes.
(I do agree with zero footprint efforts, and only editing built-in site definitions for tiny tweaks).

The first argument is actually now a moot point. Joel did indulge in a bit of developer bashing in his post (and who doesn’t enjoy a bit of that from time to time) and this respondent is simply reacting to that. But since I have already objectified Joel’s original point then arguments about “lazy developers” is actually answering a different question altogether and does not belong here.

I previously removed Joel’s “it is easier” argument and what do we see here? We see the respondent questioning what is “easier”! This respondent argues that a documented tweak is “easier” than applying manual changes. Once again in a real meeting I can see where this would go. One party would probably then say “yeah but you lazy devs never document it” and we are off into a conversational tangent that will not achieve much. So like Joel’s arguments earlier, I am removing the “my easier is better then your easier” arguments.

What’s left? Well, pretty much this entire bit of the conversation is talking about how much manual work is involved to manage changes when not utilising site definitions. So we can summarise this counter argument as “more manual customisation needed”. When I look at the map, I see that our existing argument “feature stapling cannot be used” is actually an example of this. So the adjusted arguments against site definitions now look like the map below. Note how I have removed the con of “Feature stapling cannot be used” and reworked it as an example of a new con, called “More manual customisations needed”. This now looks better.

And finally for now, I have this consolidated map to represent our current understanding of the question “What should the best practice be around SharePoint customisation”. There are still other counterpoints, and we still have to add the pro argument into the map too. But by now, you should be getting the idea. Imagine yourself having this discussion in a meeting. Would this map, displayed on a projector have helped keep the meeting on track?

Thanks for reading

Paul Culmsee

www.sevensigma.com.au