Back to Cleverworkarounds mainpage
 

Feb 12 2009

The one best practice to rule them all – Part 1

Send to Kindle

image

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.

 

Thanks for reading

Paul Culmsee

 Digg  Facebook  StumbleUpon  Technorati  Deli.cio.us  Slashdot  Twitter  Sphinn  Mixx  Google  DZone 

No Tags

Send to Kindle

Similar posts

 

40 Responses to “The one best practice to rule them all – Part 1”

  1. Paul K says:

    Excellent Post! I’m now running into the very thing you mention, and “unconscious incompetence”. We will teach them to build a light saber yet!

  2. Kristian Kalsing says:

    Landmark post! I couldn’t agree more. You won’t get success without user engagement. But an important prerequisite to user engagement is user understanding. So much time and effort is spent on showing off all the impressive capabilities of SharePoint. However, rarely time is spent on trying to really understand why we’re considering SharePoint in the first place.
    Good work. Looking forward to part 2.

  3. Pages tagged "tame" says:

    [...] bookmarks tagged tame The one best practice to rule them all – Part 1 saved by 18 others     Vietgirl77 bookmarked on 02/12/09 | [...]

  4. SharePoint Daily for February 12, 2009 - SharePoint Daily - Bamboo Nation says:

    [...] The One Best Practice to Rule Them All – Part 1 (Clever Workarounds)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. [...]

  5. CleverWorkarounds » The one best practice to rule them all - Part 2 says:

    [...] has made a profound difference on how I approach and manage SharePoint projects. If you never read part 1, then I suggest to stop now and read it. This post will really not make a lot of sense otherwise [...]

  6. CleverWorkarounds » Functional consultants vs *great* functional consultants says:

    [...] have more to say about this as I delve deeper into the "One best practice…" [...]

  7. CleverWorkarounds » The one best-practice to rule them all - Part 3 says:

    [...] 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 [...]

  8. CleverWorkarounds » The one best-practice to rule them all - Part 4 says:

    [...] 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 [...]

  9. CleverWorkarounds » Seven Sigma is officially a CogNexus Institute Designated Partner says:

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

  10. CleverWorkarounds » The one best practice to rule them all – Part 5 says:

    [...] The one best practice to rule them all – Part 1 [...]

  11. CleverWorkarounds » The one best practice to rule them all – Part 6 says:

    [...] The one best practice to rule them all – Part 1 [...]

  12. Michael Greth MVP SharePoint Blog : SharePoint Kaffeetasse 109 says:

    [...] The one best practice to rule them all – Part 1 [...]

  13. Recap of the Last Week and Then Some « Steve Mullen’s Blog says:

    [...] The one best practice to rule them all – Part 1 [...]

  14. Blue Oxen Associates » The Squirm Test says:

    [...] To provide some context for what it is and why it’s useful, I’d like to share a great story written by Paul Culmsee. In 2006, he had been hired to help a mid-sized company install a major [...]

  15. Issues, Ideas and Arguments: A communication-centric approach to tackling project complexity « Eight to Late says:

    [...] the accounts of many others – suggests that the beast remains untamed. A few weeks ago, I read this series of articles by Paul Culmsee, in which he discusses a technique called Dialogue Mapping which, among other [...]

  16. CleverWorkarounds » Perth SharePoint Users Group wrap says:

    [...] information that builds on this content can be found at the Seven Sigma site, as well as here at CleverWorkarounds. Wicked Problems and SharePoint – Rethinking the Approach View more presentations from [...]

  17. Beyond words: visualising arguments using issue maps « Eight to Late says:

    [...] IBIS References on the Web For a quick introduction, I recommend Jeff Conklin’s introduction to IBIS on the Cognexus site or  my piece on the use of IBIS in projects. If you have  some  time,  I  highly recommend Paul Culmsee’s excellent series of posts: the one best practice to rule them all. [...]

  18. Dialogue Mapping: a book review « Eight to Late says:

    [...] to a specified grammar (see this post for a quick introduction to IBIS or see Paul Culmsee’s series of posts on best practices for a longer, far more entertaining one). Questions are at the heart of dialogues [...]

  19. Ny fantastisk blogg « Richards blogg says:
  20. CleverWorkarounds » SharePoint Governance – Debategraph style says:

    [...] that some readers will wonder what I have been smoking. It is not essential, but reading the “one best practice” series will provide a lot of background to this [...]

  21. Integrating Debategraph with SharePoint : Open to persuasion… says:

    [...] who has written a brilliant series of posts on the value of issue mapping to SharePoint projects, explains the [...]

  22. Ruven’s SharePoint Blog » Blog Archive » No one’s going to thank you for SharePoint Dial-Tone says:

    [...] and techniques that require some practice but are not hard to learn. Read Paul’s series: One Best Practice to Rule Them All for a lot more [...]

  23. The Approach: a dialogue mapping story « Eight to Late says:

    [...] See Paul Culmsee’s series of articles, The One Best Practice to Rule Them All, for an excellent and very entertaining introduction to issue [...]

  24. CleverWorkarounds » The practice of Dialogue Mapping – Part 1 says:

    [...] previously introduced the topic of IBIS and Issue Mapping to a SharePoint audience in the “One best practice” series of posts. That series of posts focussed on the issue mapping side of things because it [...]

  25. CleverWorkarounds » The practice of Dialogue Mapping – Part 2 says:

    [...] – something that forms a significant chunk of my SharePoint and non SharePoint work. In the “One best practice” series of articles, I explained IBIS. In part 1 of this series, I introduced the facilitation [...]

  26. CleverWorkarounds » Am I a Business Analyst? What about those calling themselves BAs? says:

    [...] you agree with my previous assertions that a lot of the visible causes of project failure (scope creep, vague requirements, etc) comes [...]

  27. ÁghyBlog » links for 2009-04-23 says:

    [...] The one best practice to rule them all – Part 1 "Paul, can you tell me the difference between SharePoint and Skype?" (tags: sharepoint2007 bestpractices) [...]

  28. ricky_elias says:

    Saw this quote today:
    “For every complex problem there is an answer that is clear, simple, and wrong.”
    H. L. Mencken

  29. admin says:

    Thats great! one for the slide decks!! Thanks Ricky!

  30. CleverWorkarounds » Why I’ve been quiet… says:

    [...] into sensemaking and acquiring the skills necessary to help groups deal with really complex, wicked problems. My original intent was to reduce the chances of SharePoint project failure but in learning these [...]

  31. Beyond Best Practices: a paper review and the genesis of a collaboration « Eight to Late says:

    [...] a year ago, in a series of landmark posts entitled The One Best Practice to Rule Them All, Paul Culmsee wrote about his search for a practical method to manage wicked problems.  In the [...]

  32. Australian SharePoint Conference Review says:

    [...] [...]

  33. CleverWorkarounds » The facets of collaboration part 4–BPM vs. HPM says:

    [...] H-Bomb of Business Processes: Humans”, Ayal Steiner makes a point that also cuts to the heart of tame vs wicked problems debate too. “The modern idea of BPM stresses a well-defined business process as the starting [...]

  34. CleverWorkarounds » Australian SharePoint Conference Community Challenge–How we did it. says:

    [...] with some of Seven Sigma’s methods. If not, then we suggest you stop and read a couple of foundational posts first – especially if these maps do not mean much to [...]

  35. CleverWorkarounds » The facets of collaboration part 5: It’s all Gen-Y’s fault – or is it? says:

    [...] from making me giggle, Dziuba may have a point. Elsewhere on this blog I have spent time explaining that there are different types of problems that require different [...]

  36. Driving Business Value with Enterprise Collaboration – Part 3: Setting the Direction for Companywide Collaboration « Ben McMann's Weblog says:

    [...] The one best practice to rule them all [...]

  37. SharePoint Governance and Information Architecture Master Class Review | SharePoint Analyst HQ says:

    [...] idea of ‘Shared Understanding’ was another key take away. I cannot count the amount of times where people were not on the same [...]

  38. CleverWorkarounds » SharePoint Fatigue Syndrome says:

    [...] make the schedule. As I have stated many times previously, SharePoint project are likely to have wicked problem aspects to them. The structures that work well to deliver tame problems, such as Exchange, a VOIP [...]

  39. CleverWorkarounds » Confessions of a (post) SharePoint Architect: Midwives versus doctors says:

    [...] Ron Heifetz. In case you are wondering, no they are not SharePoint MVPs. Rittel coined the term “wicked problem” and is highly influential in various fields due to his early insights into complex problem [...]

  40. Various Links-August 25, 2012 | SQLAndy says:

    [...] Great story about a client who didn’t under the different between Skype and Sharepoint – while doing a Sharepoint initiative! It’s a long post, but worth reading. Lack of shared understanding leads to a lot of misery and its often very hard to catch. [...]

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>


Today is: Sunday 26 October 2014 |