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

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

This is a post or three that I have really been looking forward to writing, and it is a long time in the making for various reasons. Some of you, after reading it, will no doubt wonder if I have been taking magic mushrooms or something similar, but if the feedback from the SharePoint Best Practices conference is anything to go by, then maybe a couple of readers will have the same sense of realisation and clarity that I had.

I am going to tell you the first best practice that you should master. If you master this, all of the other best practices will fall into place. It goes beyond SharePoint too. Failure to do this, and all of your other best practices may not necessarily save you. In fact they can actually work against you. Hence the “Lord of the Rings” inspired title of this post.

Before we begin, I have to make a confession. I am not a 100% full time SharePoint consultant anymore. Don’t get me wrong. I still do, and will continue to perform a *heck* of a lot of SharePoint advisory and pick through the wreckage of many a chaotic installation. But I have worked hard to develop a new skill over the last year that has proven to be particularly powerful and profound in my SharePoint practice. The response of those SharePoint clients with whom I have used this craft has been overwhelmingly positive. The thing is though, this craft has started to take on a life of its own and now I am being called on to use it outside the SharePoint realm – despite SharePoint being the whole reason I found it in the first place.

So to explain this craft I really need to explain how I came to find it.

“I don’t know what I am delivering anymore”

Back in  late 2006, I was the infrastructure architect at a mid sized MOSS early adopter. This organisation came from a place of pretty low maturity around their document, knowledge and information management practices. As I have subsequently come to understand and recognise, many organisations coming from this place have a tendency to try to boil the ocean, via a phenomena that I previously termed the “panacea effect“. At one level, a big ambitious SharePoint platform was brilliant learning for me personally because I got to put in a multi-server farm as well as the IBM SAN storage, clustered SQL, network load balanced web front end servers, extranet config, custom authentication, publishing and just about everything in between. All in all the perfect site for the tech geek to learn the guts of SharePoint infrastructure and develop an early instinct for governance at that level.

But that wasn’t the problem area – that was actually the *tame* part of the SharePoint project. This project started to unwind pretty quickly for other reasons. Under pressure and eager to produce, the Microsoft enamoured sponsor pushed hard. Each stakeholder had *radically* different world views of what we were doing, and pinning down scope and requirements was an exercise in futility, project time estimates were crashed by more than half because they were more than the sponsors original naive estimate that went to the board of directors. The thoroughly frustrated project manager said to me one day “I don’t know what I am delivering anymore”.

CleverWorkarounds’ Hindsight Rating: Stop now – just stop now.

Around this time I decided to have a chat with some of the major stakeholders because I was really worried about this project to the point that I was thinking of resigning. It seemed that the various stakeholders never actually spoke to each other, instead using the project manager as a kind of proxy. I thought that maybe a few one-on-one, more casual meetings might break a few deadlocks and frustrations.

So, sitting in a coffee place with one particular stakeholder, I was asked the question that was the catalyst for where I am today.

“Paul, can you tell me the difference between SharePoint and Skype?”

(When I told the audience this at the Best Practice conference, I was met with disbelieving laughter. I can tell you that at the time I didn’t laugh – I was so taken aback by the question I just about choked on my double-shot latte!). 

“Well”, he explained, “I can collaborate with anybody in the world using Skype for free, and even call regular land lines very cheaply. Why should I pay half a million bucks for SharePoint to collaborate?”

CleverWorkarounds’ Hindsight Rating: Project participants can hide a lack of understanding longer than you think. Have you ever been in a meeting where you are unsure or do not feel fully informed? It is very common for people to sit quietly rather than stop and say “Sorry, I don’t understand this.”

I spent a lot of time with this stakeholder after that, and little by little I was able to get across various SharePoint basics like libraries, lists, columns and views. What happened next though was that this stakeholder started to suggest we do things that were already in the project plan (he never read it originally because he didn’t understand it). Later he gave me a records based taxonomy from a company that he used to work for in the mid nineties. It was one of those library inspired, record centric taxonomies like what I described in the document management/death metal article. He had decided that all document libraries farm-wide should use 5 common site columns – no more.

He said another thing to me around this time which was also very influential.

“We have one shot to get this right. If we get this wrong, we are going to set the company back years”.

You will understand the significance of this comment soon enough…

Off to the cave…

I think I have told enough of this story that you already know the outcome. There were other stakeholders of course with their own peculiar views of the world, and there were various things we could have done better at all levels. But fundamentally, I was dealing with a guy who’s understanding of the problem clearly changed, the more he learned and the more he thought about the collaboration problem. All of the other stakeholders went through this thought/learning process as well.

This project was something that stuck in my mind for a long time after and I was determined to never ever let this happen again. I mean, we all know SharePoint is technically complex, but the “SharePoint vs Skype” conversation for me was a watershed moment. If I were the PM, how could I have seen this coming and mitigated it early? How could we have gotten into the implementation phase for someone to ask such a question? He sat in all the meetings with everyone else and he saw the famous SharePoint pie chart like everyone else. What was wrong with our processes? Did we need to use a best-practice methodology? Did I need to learn to train people better?

It was time to go off to the metaphorical cave and meditate for a while. (Jeremy Thake once called me the theory master – now you know why).

I dug out my PMBOK books. “Maybe the PMO was implemented too rigidly or with too much dogma?” I thought. But after re-reading that stuff I still couldn’t satisfactorily reconcile the Skype question. We spent days and days developing the project management plan – it was a good plan for its time and anticipated a lot of stuff. It was clear that at least one of the stakeholders never read it beyond a basic skim or perhaps the executive summary.

So I looked at COBiT as it was supposed to be about controls and oversight. I really liked COBiT, especially the RACI charts and the maturity model. To this day I think it is one of the best designed and most elegantly constructed standards out there, but it suffers from being *so* high level and abstract that is really only useful at CIO/board level. In fact COBiT really is an umbrella that sits across all of the other ones, so by itself I think it is next to useless. Thus, it really wasn’t going to be a practical help in dealing with this problem of stakeholder understanding.

What about ISO9001? I mean, it is all about quality right? Maybe we had a quality issue? Maybe some insights were to be found there? Would a quality management plan have helped? Maybe a little bit – I mean I learned the fun you can have with the non conformance clauses. But the issue was *not* what to do once I found a quality problem. The fact that it had become a quality issue means that by definition, something went unnoticed or ignored and then caused some unwanted event to occur. Thus, I needed to recognise it much, much earlier than when it becomes a quality issue.

(ISO9001, if you have not yet read it, will cure even the most hard-core insomniac – guaranteed).

Hmmm, perhaps the answer lies in process improvement? Maybe if we used a best-practice methodology to map out and understand our processes, it would have resulted in a more optimal information architecture exercise. I had watched teams argue over process and accountabilities when we started talking to them about metadata and workflows during the information architecture sessions. So I hit the books on process improvement and business process modelling methodologies – a very crowded space with many standards and theories.

Three things popped up here. IBM’s BPMN (Business Process Modelling Notation), the process improvement methodology Six Sigma (and its variants) and a great book by Geary Rummler called “Improving Performance: How to Manage the White Space in the Organization Chart (Jossey Bass Business and Management Series)“.

I became excited as this was definitely getting closer to what I was looking for. As I read more, I saw potential. BPMN was simply a method to create consistent, easy to understand process flow diagrams and in fact, one of my colleagues has become a master at this craft. But that didn’t address the ‘art’ of process improvement. I found that often when trying to map a process with a group, the group would often start to recognise flaws or flat out disagree on how the process ran within the organisation. Inevitably, as a process mapper, you would sit back and “process debates” would take over the meeting. Clearly there was a step missing.

I also liked the emphasis on data centric decision making of Six Sigma and the emphasis on measurement. I went very low-brow and bought Six Sigma for Dummies and devoured it. As I read it, I started to remember my old high school maths because Six Sigma is very analytical and data driven. Much of what Six Sigma teaches is very, very good from a philosophical standpoint, but it did seem so “epic” and seemed to be geared around “big bang” change.

All of process improvement methodologies were process-heavy and structure-heavy. I feared that the same dogma that I had seen derail the good intentions of PMBOK would affect Six Sigma in the sorts of organisations that I had involvement with. I read a great online document later that suggested Six Sigma in real life had more of a two sigma success rate which I found unsurprising.

I also looked at Lean/Kaizen and a zillion variants. In the end I started to get lost and frustrated. Process improvement (and by association, strategy theory) is an insanely crowded place and some other time, I will write about the various fads as they have come and gone.

The Eureka Moment

Okay so I read a lot of stuff (and now have forgotten most of it). All of the methodologies and practices that I studied had some excellent parts to them, and in fact, most *encourage* you to take the bits that make logical sense for you. As I wrote in Part 8 of the “SharePoint Project Failure…” series, I found it ironic that implementation of many of these methodologies fell victim to the same sorts of “people” issues that derail the original project. The whole ‘big bang’ style approach, whether it was a software project or a best-practice methodology seemed to suffer the same sort of hit-or-miss fate.

Then in one of those times when you randomly surf wikipedia (the fountain of all authoritive knowledge 😉 ), I came across the term “Wicked problems” and the work of Horst Rittel from the early 1970’s. In Rittel’s era, he was talking about a particular class of social policy and planning problems like “What shall we do about the global financial crisis” or “What should we do about global warming”, “What should we do to solve the Palistinian issue?”. Such problems are insanely tough to solve. But as I read about the *characteristics* of a wicked problem as described by Rittel, and subsequently by his student Conklin, I realised that both were describing *exactly* my first MOSS 2007 project.

While I am not suggesting a MOSS project is a wicked problem the way that Rittel or Conklin envision it to be, those “characteristics” or “properties” of wicked problems were so applicable to my experience that is was scary.

Phew!

Since I have been waffling on far too long, I’ll stop things now, and in the next post, I will delve into wicked problems in more detail, both Rittel and Conklin’s definitions, as well as my own definition, that I used at my Best Practices SharePoint Conference session.

• The one best practice to rule them all – Part 2
• The one best practice to rule them all – Part 3
• The one best practice to rule them all – Part 4
• The one best practice to rule them all – Part 5
• The one best practice to rule them all – Part 6

 

Thanks for reading

Paul Culmsee

Hi all. I’ve just posted my Best Practices Conference slide deck for the Wicked Problems session, along with the maps that I used during the demonstration. Expect a typically long post really soon now, to delve into much more detail about all of this 🙂

For what it’s worth the conversion to slideshare was a bit wonky, so just contact me if you want a pptx version.

Iframe below too small? Then go here for the demo issue maps

[iframe /BPCMaps/Best_Practices_Share_192168511229769555699.html 800 600]

This is the second article in a series of articles which examine factors causing the sort of organisational inefficiencies that lead people to use products like SharePoint. My first article in the series examined individual learning and behavioural styles and their impact on communication and how those same learning and behavioural styles still manifest themselves in collaborative tools and informational architecture.

We now turn our attention away from individuals and look at the collection of individuals known as the "organisation". In the first article, I lamented the fact that it seemed no empirical study had even been performed to determine the relationship between behaviour/learning styles and specific collaborative tools/techniques. Fortunately for me, in writing this second article, organisational culture has long been recognised as just about *the* most critical factor in organisational success. What that essentially translates to, is that there is an absolute *plethora* of research on the topic of the influence of organisational culture in knowledge management. In writing this article I had a severe case of information overload but fortunately found exactly what I was looking for.

Knowledge management in academia

Academic papers tend to be pretty dry reads. Researchers, surprise…surprise, write papers to be read by other researchers. Any time you delve into academia to look for answers you have a lot to read and digest, and need a strong jolt of caffeine to keep you going.

Combine that with the fact that the term "Knowledge Management" suffers from rampant buzzword abuse in the same way that the term "Governance" does. This abuse reflects itself in academia where authors are forced to spend pages and pages of their work on defining exactly what they are talking about, whilst making sure that they have demonstrated that they have checked their facts (evidenced by numerous references to other researches).

I ended up finding one particular paper to be very insightful contained within this book:

 

and in particular, this paper/chapter with an extremely long title…

*Paul takes a deep breath*

"An Empiric Study of Organizational Culture Types and their Relationship with the Success of a Knowledge Management System and the Flow of Knowledge in the U.S. Government and Nonprofit Sectors" by Juan Román-Velázquez, D.Sc.

What a mouthful that was!

Credit where credit is due though, this is a terrific paper and I am going to barely paraphrase it here. But I encourage anyone who wants to ensure that organisational culture issues have been given due consideration in their planing to read this paper. Despite being oriented to government and non-profit organisations, there is a lot of good conclusions to draw from.

Velázquez sets the scene by explaining that public, private, and nonprofit enterprises must survive and thrive in an environment of shrinking distance, complex interdependencies and increased uncertainty. Unsurprisingly, the use of knowledge management (KM) is rapidly growing and tools like SharePoint are commonly used in this area. Velázquez has a good definition for KM that

…provides the capability to engineer the enterprise structure, functions, and processes necessary for the enterprise to survive and prosper. KM leverages the existing human capital/intellectual assets to help generate, capture, organize, and share knowledge that is relevant to the mission of the enterprise. Furthermore, the implementation of a KM system (KMS) enables the effective application of management best practices and information technology tools to deliver the best available knowledge to the right person, at just the right time, to solve a problem, make a decision, capture expertise, and so forth, while performing their work. The KMS can comprise formal systems, processes, management directives, and others that, when combined, help generate, capture, organize, and share available knowledge that is relevant to the mission of the enterprise.

Velázquez than makes the key point that I have always believed. I tell clients that SharePoint is 90% head-space. Velázquez argues although motivations for KM may differ between the public and private sector, the *practice* of knowledge management is very similar. Velázquez also stresses the point that "tools" are a small part of the solution.

A successful KMS involves more than just implementing a new technology that can be acquired in a “box”; it requires understanding and integrating its human aspects and the culture in which it operates.

So SharePoint is not a Knowledge Management System – it is merely one of the tools that underpin a KMS.

Where does organisational culture come from?

A widely held view is that the importance of organisational cultural considerations emerged by the failure of many US and European companies to compete with Japanese firms. Case in point? Look at the history of Ford, General Motors and Toyota. In their book, Diagnosing and Changing Organisation Culture (see below), authors Kim Cameron and Robert Quinn make the point that successful companies with sustained profitability and above-average returns leverage their organisational culture as the key factor for competitive advantage.

Organisational culture can emerge in a number of ways:

• It is sometimes created by its founder (e.g. Walt Disney).
• It may emerge over time, as the organization faces challenges and obstacles (e.g. Coca-Cola)
• It may be developed consciously by the management team (e.g. General Electric through Jack Welch).

How important is organisational culture? Consider this quote from Cameron and Quinn.

The point we are illustrating with these examples is that without another kind of fundamental change, namely, the change of the culture of an organisation, there is little hope of enduring improvement in organisational performance. A primary reason for the failure of so many efforts to improve organisational effectiveness is that, whereas the tools and techniques may be present and the change strategy implemented with vigor, failure occurs because the fundamental culture of the organisation remains the same. Consider the studies by Cameron and his colleagues (Cameron, Freeman, & Mishra, 1991; Cameron, 1992; Cameron, 1995) in which empirical studies were conducted in more than 100 organisations that had engaged in total quality management (TQM) and downsizing as strategies for enhancing effectiveness. The results of those studies were unequivocal. The successful implementation of TQM and downsizing programs, as well as the resulting effectiveness of the organisations’ performance, depended on having the improvement strategies embedded in a culture change. When TQM and downsizing were implemented independent of a culture change, they were unsuccessful. When the culture of these organisations was an explicit target of change, so that the TQM and/or downsizing initiatives were a part of an overall culture change effort, they were successful. Organisational effectiveness increased. Culture change was the key.

That quote, I think hits the nail on the head of why so many SharePoint projects fail. To implement SharePoint without any appreciation for organisational culture is simply not smart. If you are dumfounded by the fact that nobody in the organisation is embracing wikis, blogs and discussion forums, stop and think about it. Is this organisation conducive to such technologies?

Fortunately for SharePoint practitioners who have never considered the effect that an organisation’s culture has on the application of collaborative technology, I’m about to make your life easier… In short, the hard work has been done for you.

The CVF model

In the first article, I used the learning style theories of Honey and Mumford and Marston DISC to explain how our individual differences impacted on the means and methods by which we collaborate. They are not the only theories by any stretch. In fact, pretty much anytime anybody puts up a theory or methodology, you will invariably find someone else trashing it by questioning its validity. Likewise, when trying to quantify organisational culture factors, there are many different measurement methods with different theoretical underpinnings. Naturally, each believes that *theirs* is the right way to go.

I just had a sudden thought that maybe the learning and behavioural styles of an individual has an influence on which measurement methodology they might find to be the most useful.

One tool used to diagnose organisations and help executives change their culture is called the Competing Values Framework (CVF). The CVF consists of a framework, a sense-making tool, and a set of steps to analyze and change organisational culture. CVF is best explained with two charts that I have supplied below.

 

There are two dimensions used in this chart. From left to right, we are looking at "internal versus external" factors such as employee satisfaction, customer service, market share and profitability. From bottom to top, we are looking at the "control versus flexibility" factors such as the internal processes, policies and systems that maintain stability and consistency at one end, and adaptability at the other. Taken together, the two dimensions of the CVF produces four quadrants: Clan, Adhocracy, Hierarchy and Market culture.

Note that it is a very similar dimension based system like Marston DISC. (This is why I like it).

Below I have defined the characteristics of each culture type as defined by Velázquez:

The clan culture: Dominant in flexibility, discretion, dynamism, internal focus, integration and unity.

A very friendly place to work where people share a lot of themselves. It is like an extended family. The leaders, or the heads of the organization, are considered to be mentors and perhaps parent figures. The organization is held together by loyalty or tradition. Commitment is high. The organization emphasizes the long-term benefits of human resources development and attaches great importance to cohesion and morale. Success is defined in terms of sensitivity to customers and concern for people. The organization places a premium on teamwork, participation, and consensus.

The adhocracy culture: Dominant in flexibility, discretion, dynamism, external focus, differentiation and rivalry.

A dynamic, entrepreneurial, and creative place to work. People stick their necks out and take risks. The leaders are considered innovators and risk takers. The glue that holds the organisation together is commitment to experimentation and innovation. The emphasis is on being on the leading edge. The organisation’s long-term emphasis is on growth and acquiring new resources. Success means gaining unique and new products or services. Being a product or service leader is important. The organisation encourages individual initiative and freedom.

The market culture: Dominant in stability, order, control, external focus, differentiation and rivalry.

A results-oriented organisation whose major concern is with getting the job done. People are competitive and goal oriented. The leaders are hard drivers, producers, and competitors. They are tough and demanding. The glue that holds the organisation together is an emphasis on winning. Reputation and success are common concerns. The long-term focus is on competitive action and achievement of measurable goals and targets

The hierarchy culture: Dominant in stability, order, control, internal focus, integration and unity.

A very formalised and structured place to work. Procedures govern what people do. The leaders pride themselves on being good efficent-minded coordinators and organizers. Maintaining a smooth-running organisation is most critical. Formal rules and policies hold the organisation together. The long-term concern is on stability and performance with efficient smooth operations. Success is defined in terms of dependable delivery, smooth scheduling, and low cost. The management of employees is concerned with secure employment and predictability.

I’m sure that just like the previous article, most readers will readily identify the sort of organisational culture to which they belong. Microsoft themselves are a classic case study of an organisation that has attempted to change its culture on numerous occasions with varying degrees of success. Microsoft would like to think that their culture is that of a clan and adhocracy, but the reality is they are very much a market culture. These days they are beaten to the punch my smaller, more nimble competitors, but over the long term they are able to use their formidable market position and financial leverage to succeed. Netscape is a classic example of Microsoft’s market culture succeeding, but you can almost *hear* the rusty gears of the Microsoft culture machine slowly but surely turning as competitors like Google and Linux achieve tremendous success which has been built on very different philosophical foundations.

Having said that, I believe personally that Google is now invariably moving from a strong clan/adhocracy culture starting point to a dominant market culture as well. If you disagree with my assertion then we need to prove it either way. How? 

…Enter the OCAI.

OCAI

The Organisational Culture Assessment Instrument (OCAI) is part of the CVF. It is a survey based instrument that allows an organisation to profile what quadrant they are strongest in and to decide if they would be better off by cultivating strengths in another quadrant. There are plenty of reasons why a company might want to do this. Microsoft both succeeded and failed in this regard. They managed to completely out-compete Netscape through Netscape’s own failed execution of strategy, yet they have been playing catch-up with Google for years and still really have not managed to make a dent. 

To determine the dominant culture type in an organization, survey questions are group into six "cultural components". The six components are: General Dominant Characteristics, Organizational Leadership, Management of Employees, Organizational Glue, Strategic Emphasis and Criteria of Success.

• General Dominant Characteristics: In general, what does the organisation look like? What the overall organization is like.
• Organizational Leadership: How leaders are perceived in their direction of the institution.
• Management of Employees: The style that characterizes how employees are treated and what the working environment is like.
• Organizational Glue: The bonding mechanisms that hold the organisation together.
• Strategic Emphasis: Areas of emphasis or priority issues that guide the organisational strategies.
• Criteria of Success: Evaluation criteria and procedures to determine level of achievements and outcomes. It is how victory is defined and what gets rewarded and celebrated.

Each question has four alternatives representing each CVF quadrant (A=Clan, B=Adhocracy, C=Market, D=Hierarchy). Individuals completing the OCAI are asked to assign a score to each alternative. A higher number of points are given to the alternative that is most similar to the organisation in question. Results of the OCAI survey are obtained by computing the average of the response scores for each alternative. This can then be plotted as per the example below.

Et Voila! Now we have a much clearer assessment of the culture of an organisation, based on the feedback from the members of the organisation.

Is it worth it?

Geeks who have made it this far through this article are at this point wondering what I am smoking, but rest assured – this stuff is critically important for anybody who is tasked with putting SharePoint into an organisation.

It actually turns out that research using the CVF quadrant has shown that large organisations able to balance their competing values by growing strength in each quadrant tend to outperform other organisations over the long-term. Therefore, the tools and technologies that are put in place to support knowledge management need to also take into account the culture of the organisation in order to extract maximum value from the investment.

Each of the four traits were also significant predicators of other effectiveness criteria such as quality, employee satisfaction, and overall performance. The results also showed that the four traits were strong predicators of subjectively-rated effectiveness criteria for the total sample of firms, but were strong predicators of objective criteria such as return on net-assets and sales growth only for larger firms.

In a following post from this series, I will present the findings of the Velázquez paper which undertook an empirical analysis of KM priorities and critical success factors of many organisations using OCAI.

How would SharePoint look?

In the first article I had a section where I theorised how a SharePoint installation would look like if behavioural types had been taken to extremes. In the interests of consistency, I think it’s good to repeat that experiment in poor stereotyping here:

The clan culture is social networking personified and therefore Facebook style applications are the answer to collaboration and knowledge management. Employees twitter away to each-other and share everything. SharePoint’s "My Sites" are the obvious candidate here, but to a mature clan culture, my-sites are pretty antiquated and almost laughable compared to some of the competing cloud based applications out there. Document libraries? Sheesh! What do you need documents for anyway?  Everyone uses blogs, wikis and Information architecture consists of tagging anything and everything. A mature clan culture would very likely utilise 3rd party add-ins like Newsgators Social Sites if they were to make a SharePoint investment.

I actually believe that anyone who considers themselves a clan culture and is putting in SharePoint is really a market culture with a case of rose coloured glasses 🙂 .

The adhocracy culture is essentially every startup company as well as any CEO who describes themselves as "dynamic". SharePoint, in this type of culture, does not have an information architecture to speak of (in the ‘classic’ meaning of that term). SharePoint features will be used as needed and grow over time. If it works, it will be used, if it does not, it will lie abandoned. Anything newly released will be eagerly tried, kept or discarded depending on relevance and usage. Some re-use from learning will take place, but ultimately SharePoint will perpetually be a work in progress with no central governance authority. Most power users will be administrators of their own sites and any attempts to impose centralised order or a governance regime that is based around centralisation and standards will likely fail. Decentralised control for this type of organisation is fine because there is a strong sense of ownership of the knowledge and information.

The market culture would start to utilise SharePoint in a manner that is most in keeping with the literature around features, deployment and governance. Dashboards and KPI’s would feature heavily, as well as workflows that contribute to the ease of collecting performance measurements. Reporting Services integration in particular will fare well here. In a market culture, very little sympathy may be given for SharePoint functionality that is not seen as contributing positively to the business. Additionally, users are unlikely to change for the sake of change or because it is something new and shiny. A market driven culture will implement SharePoint because they see a tangible, quantifiable reason to do so.

The hierarchy culture will implement SharePoint in its most ‘classical’ style. They will naturally make use of site collection, sites and subsites and enforce strict, often complex security boundaries with tight centralised control. Chances are that significant time will be invested into ‘classical’ governance such as forming a committee, standardising on structure and conventions and trying to create a solution that is repeatable with a minimum of rework. Workflows will be very popular, as well as form services as well as document centric collaboration. Facebook style social networking will most definitely not be a high priority, and what’s more, will probably be blocked by the corporate firewall anyway!

Another note: SharePoint out of the box in my opinion is most suited to the latter two organisational cultures. Is it any surprise that a market culture organisation such as Microsoft would produce a collaborative tool that happens to work with it’s own organisational culture? Therefore it begs the question whether an organisation founded on one culture can ever really write the perfect tool for another culture?

Culture based communication fragmentation

Just like the first article, I have painted a pretty stereotypical picture of the sort of SharePoint installation I’d likely see. Some readers (dare I risk suggesting younger readers?) may look at the market and hierarchy culture as old school, representing 20th century organisational thinking. Certainly Linux proves that the clan culture can be extremely successful against the old school guys. But there are many stories of organisations that have had massive initial success, only to get left in the dust once the slower market and hierarchical cultures get their act in gear. One thing hierarchical cultures can do exceptionally well is repeat process more consistently, with fewer defects which ultimately reduces cost. They may not be all that quick at first, but it’s not always about being first to market.

Once again I leave you on an Information Architecture note. Someone who only knows a clan culture will very likely put together a SharePoint solution vastly different to someone who has only known hierarchical culture. The prevailing culture will always win the technology battle, no matter how passionate the individuals are. Even organisational stakeholders in a SharePoint project often make this mistake with the "build it and they will come" approach and think that making the technology available will change the culture . This is both naive and dangerous and has the effect of setting yourself up for project failure.

So, you, as an information architect, need to acutely be aware of the prevailing culture. If your stakeholders give you mixed messages, then perhaps the CVF/OCIA analysis would be a very timely and smart thing to do.

Thanks for reading

Paul Culmsee

www.sevensigma.com.au

This is the first article in a short series that will be looking at factors causing the sort of communication problems that underpin the motivation to implement a product like SharePoint. When you think about why you want to implement SharePoint, it tends to boil down to an improvement in efficiency brought about by improved collaboration between individuals or teams.

Improved or more effective collaboration is a great idea in theory but unfortunately SharePoint’s implementations have been hit or miss affairs. When a SharePoint project goes well, it tends to go very well. When it goes bad, it tends to be very bad. I’ve seen both extremes. On one of my projects I had the executive chairman so enamoured with a particular requirement being satisfied that he was out there evangelising to the user base for me. Once this happens, success is generally assured. But on the other hand, I have been called out to sites where they have completely lost control of it all, and to even mention the dreaded "S" word will result in you being ostracised.

I realised long ago that to put in SharePoint without considering and understanding the various root causes to "communication problems" is to be unconsciously incompetent. (By the way, if you have not read my "Thinking SharePoint" series, "unconsciously incompetent" is a term used in education/training disciplines to indicate that "you do not know what you do not know". In other words, how can you be trained on something when you do not even acknowledge that you have a deficiency in that area?

Training, therefore, is most effective when trainees are at the "consciously incompetent" stage of their learning. This means that they now realise and understand that they have deficiencies in a knowledge area and seek to improve their skill. Some might argue that to actually put SharePoint into an organisation is to be consciously incompetent, because you have recognised the inefficiency in existing communication and collaboration. I believe this is deluded because all you are doing is trying to deal with the visible effects of communication fragmentation. You still do not necessarily have a full understanding of the root causes of that fragmentation.

I’m sure that many of you have watched the TV series House. How many times do they just about kill the patient with a treatment for an incorrect diagnosis? Unlike Dr House, though, SharePoint consultants don’t often get that convenient epiphany at the 38 minute mark of an episode that nails the root cause, applying the correct treatment and saving the patient.

Therefore, I have decided to call this series "Root causes of communication fragmentation". This first article is essentially the same as one called Learning styles, behavioural styles and “collaboration” that I published it over at endusersharepoint.com.

Honey and Mumford Learning Styles

When I was taking my "Train the trainer" course at the Australian Institute of Management, we participated in an experiment. We answered a questionnaire and based on our answers were separated into four groups.

It turned out that these groups were separated based on our most dominant Honey and Mumford learning style.

For those of you who are not aware, according to this work, there are four types of learners. I have listed them below, and for your reference I was classed as a theorist/pragmatist with more of a pragmatic leaning. Funnily enough when I was younger I was definitely an activist learner but as I have aged I moved down the list!

Activitists (Do)

• Immerse themselves fully in new experiences
• Enjoy here and now
• Open minded, enthusiastic, flexible
• Act first, consider consequences later
• Seek to centre activity around themselves

Reflectors (Review)

• Stand back and observe
• Cautious, take a back seat
• Collect and analyze data about experience and events, slow to reach conclusions
• Use information from past, present and immediate observations to maintain a big picture perspective.

Theorists (Conclude)

• Think through problems in a logical manner, value rationality and objectivity
• Assimilate disparate facts into coherent theories
• Disciplined, aiming to fit things into rational order
• Keen on basic assumptions, principles, theories, models and systems thinking

Pragmatists (Plan)

• Keen to put ideas, theories and techniques into practice
• Search new ideas and experiment
• Act quickly and confidently on ideas, gets straight to the point
• Are impatient with endless discussion

In this experiment, each of the four groups were given the same fictitious problem. We were asked to write a plan for how we would go about solving it. We spent then 30 minutes on this in groups before reassembling back in the same room where the groups compared notes.

Perhaps unsurprisingly, we all thought that the other groups were complete idiots. The reflectors in particular thought that the activists represented complete anarchy and chaos. My group – the pragmatists (who of course have it right), knew that their method was by far the best one and had no time at all for reflectors who perform all of that analysis-paralysis. Mind you, we did have some sympathy for the theorists 🙂 .

Why is communication, shared understanding, knowledge management and collaboration such a difficult thing to do?  This is one of the root causes. This experiment really hit home to me, just how incredibly different people are and how a collaborative tool by definition, needs to be designed or implemented in such a way that all participants use, believe and evangelise it. But since they all have different styles of learning, accommodating them all without alienating some is a pretty difficult task.

DISC

Then we have behavioural theory with Marston DISC. This test is used in recruitment and HR often to see how well a candidate will ‘fit’ into the cohesiveness of a group or organisation. DISC is an acronym that relates to four ‘dimensions’ of personality traits.

• Dominance – relating to control, power and assertiveness
• Influence – relating to social situations and communication
• Steadiness – relating to patience, persistence, and thoughtfulness
• Conscientiousness – relating to structure and organization

Below is the explanation of each trait from wikipedia. Is it any surprise that senior managers tend to be dominant in "D", sales and marketing people dominant "I" while engineers are dominant "C"?

• Dominance: People who score high in the intensity of the ‘D’ styles factor are very active in dealing with problems and challenges, while low D scores are people who want to do more research before committing to a decision. High "D" people are described as demanding, forceful, egocentric, strong willed, driving, determined, ambitious, aggressive, and pioneering. Low D scores describe those who are conservative, low keyed, cooperative, calculating, undemanding, cautious, mild, agreeable, modest and peaceful.
• Influence: People with High I scores influence others through talking and activity and tend to be emotional. They are described as convincing, magnetic, political, enthusiastic, persuasive, warm, demonstrative, trusting, and optimistic. Those with Low I scores influence more by data and facts, and not with feelings. They are described as reflective, factual, calculating, skeptical, logical, suspicious, matter of fact, pessimistic, and critical.
• Steadiness: People with High S styles scores want a steady pace, security, and do not like sudden change. Low S intensity scores are those who like change and variety. High S persons are calm, relaxed, patient, possessive, predictable, deliberate, stable, consistent, and tend to be unemotional and poker faced. People with Low S scores are described as restless, demonstrative, impatient, eager, or even impulsive.
• Conscientious: Persons with High C styles adhere to rules, regulations, and structure. They like to do quality work and do it right the first time. High C people are careful, cautious, exacting, neat, systematic, diplomatic, accurate, tactful. Those with Low C scores challenge the rules and want independence and are described as self-willed, stubborn, opinionated, unsystematic, arbitrary, and careless with details.

Don Bowlby has a nice post where he illustrates these different behavioural styles with examples of "Dominant Dave", "Influential Ingrid", "Steady Stan" and "Conscientious Catherine". Do take the time to read his post, and then see which of these people you relate to the most.

Note: You can have elements of more than one of the DISC dimensions but you tend to be dominate in one of them.

Dominant Dave questions the status quo, is quick to make decisions/solve problems. He has no problem with power and authority, loves autonomy and working on lots of stuff. He struggles to relate to some people and sometimes has trouble identifying with the group. People like Dave get things moving forward, but can overlook detail in the process.

Influential Ingrid always wants to make a good impression, loves people and prefers to talk about her ideas rather than present them in writing. She doesn’t like a lot of details and can appear disorganized. Being so emotionally oriented, she can have trouble making objective evaluations of people and situations. People like Ingrid foster open communication and strive for an enjoyable experience. But Ingrid needs people who enjoy routines and tasks because these things make her uncomfortable.

Steady Stan is patient, helpful and finishes everything he starts. Stan’s daily routine rarely changes and he does not react well if it suddenly does. Without people like Stan, things would never get finished, yet the rigidity of Stan’s routine can frustrate when quick decisions and action are needed.

Conscientious Catherine is even more anal-retentive than Steady Stan. She is very analytical, applies critical thinking and likes to know what the goals are and what is expected and is always happy to lend her expertise when required. Sometimes Catherine’s detail oriented nature can slow projects down and her application of critical thinking may seem negative at times. She has a knack for pointing out everything that can go wrong with a project, product or venture.

Hmm, I just read a book on analytics and wrote a series of posts on SharePoint project failure and ROI – but I am as messy as hell so which domain am I? 😉

How would SharePoint look?

Let’s try a little experiment. Below I theorise what a SharePoint portal would look like, based on the presumption that each of our 4 people above assumed full creative control over development and direction. Feel free to comment to the accuracy (or not) of my guesses.

Dominant Dave has seen SharePoint, liked it and thrown together a SharePoint site. He has set up sites, wiki’s, blogs, lists, libraries and on top of that, relentlessly downloaded every possible add-on, and tried it out, using some and giving up on others (but never uninstalled). His idea of a communications plan and training is to send out an email with the new URL and instruct people to start using it. The site is full of evidence of half-starts and unfinished ideas and no-one really knows exactly what the goal of it all is. But that’s okay, Dave has by now passed it onto Steady Stan to finish it off anyway.

Influential Ingrid on the other hand, engages a graphic design company to work on the look of the site. She will come up with a catchy acronym for the project, and organise t-shirts and mouse-mats to be printed and distributed to staff. The site is launched with great fanfare, yet practically devoid of content except for the social club site and the "about us" section. Document libraries and lists are unlikely to have much attention, because all the emphasis is on the static web content side of things. Despite the lack of use of many of the built-in collaborative tools, boy-oh-boy, does that home page look cool! Things will flash, sparkle and dazzle more than a drag queen singing at a cabaret.

Steady Stan will quickly see the potential for improving the way that content can be better organised, searched and managed. Thus he will spend his time coming up with a common structure for all aspects of the portal no matter which site is visited. The document libraries, list and other content areas will be consistent and identical and templated for re-use. Branding will be ignored, because it is not as important as consistency. He will roll it out, expecting people to naturally take it up, seeing the value created.

Conscientious Catherine will first undertake a 6 month feasibility study into the portal that costs more money than what Dominant Dave took for his entire SharePoint project. The outcome of this study would be to learn what people want out of the portal. She works out a methodology to gather requirements, but on execution it becomes obvious that both Dave and Ingrid haven’t got a clue as they can’t seem to offer a straight answer when she asks what they want. "How can I deliver you a portal when I don’t know your requirements?", Catherine asks in indignation. In the end, Dominant Dave looks at how much money has been spent for no obvious gain and kills the project.

The Honey DISC soup

The point of my little exercise with sweeping generalisation is that "collaboration" by definition is about working together to achieve a common goal or outcome. Unfortunately, it is clear that our 4 characters above have very different motivations and interpretations of what that outcome is.

In my consulting life, where I spend a lot of time doing requirements work, training or project management, I have gotten to the point where I can pick someone’s personality/learning style out. Also, once you start to get a feel for this, you realise that a lot of root causes in social fragmentation is simply a lack of awareness of how people speak to each other.

When you combine DISC and learning styles, it gives you a pretty good appreciation of social complexity. Given a complex problem, you will always get people who want to jump straight in (activists), those who want to consider all of the issues (reflectors), theorists who will be looking for best-practice guidelines and us pragmatists who say the rest are right so long as it is done *our* way.

But when you add the dimension of DISC, the forces of social fragmentation get even stronger. Consider the case of a "Dominant Activist". Here is someone who is forceful, strong willed, potentially intimidating yet wants to dive headlong into a solution. These guys are hazardous to your health because they usually have the power to do it their way regardless.

On the other extreme you have a "Conscientious Reflector". There is every dodgy middle manger that I have worked with right there!

Another classic example is the "Steady Theorist" who believe that rigidly following a methodology is the answer to the world’s problems, no matter what. I have met a few ITIL people who I would lump in this bucket 🙂 .

Communication Fragmentation

Meetings are the place where fragmentation strikes and miscommunication arises as a result. For example, in a strategy meeting, the reflector is the one who *always* challenges the frame of the meeting and annoys everybody else in the process. The activists are annoyed that they had to go to the meeting in the first place, and the theorists are trying to convince everyone that [insert methodology here] is the way to go.

A dominant "D" type personality often speaks in a very direct manner. To a low D type personality, this can be seen as intimidating, rude or arrogant. D and S type personalities can really struggle to get along, because at times, they are polar opposites in what motivates them and keeps them interested.

A heavy "D" personality who is a pragmatic learner is probably going to be a handful when it comes to, say, working on functional requirements with an "S" type application developer who happens to be a theorist learner.

Is it any wonder people consider meetings to be inefficient, a waste of time and not achieving much!

The point is that usually people forget that not everybody shares their behaviour and learning styles.

Collaboration Fragmentation and Information Architecture

So since meetings are inefficient and suck so much, we look to other methods to collaborate to achieve our goals. But that communication gap that can exist between people of differing learning styles and personality types reflects itself in collaborative tools as well. An IT Manager who, for example, is mainly a "S" type personality is going to put together a SharePoint solution with a very different emphasis than, say, someone who is mainly a Dominant Activist.

Of course, organisational type and culture, regional culture, geography, age, gender and other biases play large factors as well. Organisational considerations has gained some attention – one of the best examples I saw being the great paper by Michael Earl who in 2001 wrote "Knowledge Management Strategies – Toward a taxonomy". But unfortunately, no academic has ever performed an empirical study that looks at whether there is a correlation between behaviour/learning styles and the sort of collaborative tools/techniques that people gravitate to. I think if such a study was undertaken, it would offer some extremely valuable insights into how to go about delivering a collaborative solution for particular groups, individuals or organisations.

So, when you are designing your "work of art" Information Architecture that has taken weeks to work out, ask yourself this question: Is this a work of art for me or for the people who will be collaborating via it?

The great irony in all of this is that the only way to remove some of the barriers of social fragmentation is to collaborate. In the case of SharePoint, you need to collaborate, to put in a collaborative platform. Am I the only one who finds that perversely funny? 🙂

Paul Culmsee

www.sevensigma.com.au