Hi all

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

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

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

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

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

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

Digging deeper

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

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

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

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

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

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

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

Problem fundamentalism

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

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

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

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

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

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

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

(Stunned silence … Paul hears pin drop)

I can imagine some reader comments at this point:

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

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

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

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

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

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

We will talk about that in part 3…

Thanks for Reading

Paul Culmsee

Hi!

I’ve just noticed that Arno Nel over at SharePoint Magazine has published part 7 of my "Tribute to the Humble Leave Form" series on InfoPath and forms services.

Bye!

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]

To quote the brilliant singer Kate Bush, "wow wow wow unbelievable!"

Well, it is all over, and boy what an experience! For those of you who were not aware, I had the honour of attending as well as presenting at the San Diego SharePoint Best Practices conference. I had two topics, but I’ll post a report about those in another post. This post is going to sound like one of those long acceptance speeches at the academy awards as I have to give out kudos’ to all the people who I hung out with.

I sat in on as many sessions as I could, particularly the ones around requirements gathering, information architecture and strategy. It was fascinating that each person who spoke on or around this topic, such as Paul Galvin, Ruven Gotz, myself and Peter, all had varying approaches and I learned something from all of them. Some amazing talent – truly brilliant minds, wonderful speakers and great topics.

Some of the speakers – guys like Robert Bogue and Evan Burfield (above) just leave me in awe. There is not a damn thing that they say that I disagree with. Pretty much any good idea that I have had, Rob has thought of it first and developed it far, far further than I ever have. Just wait until you see his upcoming governance DVD – I’ve seen the mind map and holy freakin’ crap!, the length and breadth of what he has put together will make it an absolute *must have*. I had been working on similar material, but after seeing how far he has taken it, trust me and just buy his DVD – I’m hoping to be a reseller :-). Forget "Sharepoint Shepherd", I humbly bow to the "Governance Godfather – Robert Bogue" (you can license that title from me Rob 🙂 )

Also Rob, if you are reading this I went looking for you at SharePint to jump on your lap and do a fanboy photo (and I was going to risk messing with your hair). Lucky for you I guess, you had left by then and my evil plan was foiled – but Joel wasn’t so lucky 🙂

Mr Oleson – what can I say? I owe him a heck of a lot, as if it wasn’t for him I wouldn’t have been a presenter at this conference. Joel mate, you were on the phone when I came to say my heartfelt thanks for vouching for me and making this happen. I never crossed your path after that and I feel bad that I never got to. I’m going to get the SharePint photos from Ruven, although Joel, I am sure that your legal people will send me a cease and desist letter for that fanboy photo that I took with you. Mind you, I think there are other photos that you should be more worried about! But hey, what happens on tour, stays on tour right? 🙂

Ben Curry from Mindsharp – you I owe the biggest thanks of all. Conceiver of it all and the heart and soul behind this event. Visionary guy, worked his arse off, willing to risk bringing in several untried and untested relative unknowns like myself. He nailed *exactly* how a best-practice conference needs to be. Although sessions and topics were technical or development centric at times, make no mistake. This was all about headspace and critical thinking, so I was like a kid lost in a candy store.

Gary Lapointe is another person who left a big impression on me. I am well aware of his awesome capabilities and I found him a really down to earth, genuine and humble guy and I really, really wanted to have a beer with and chat to some more. I am totally buying you beers next time.

Paul Galvin. Spent the whole conference saying hello but never really crossing paths properly until the last hour or so. Loved your presentation and enjoyed your insights, regret not having more time to download your brain.

I also enjoyed hanging out with the poms, who seem to deal with satirical aussie humour a little better than the Americans. Andrew Woodward, Phill Duffy, Brett Lonsdale all were great company and good fun. Brett – I look forward to doing good things with Lightningtools and Combined Knowledge.

Then there were the metalheads. Todd Klindt was a riot and its obvious that he was put on this earth to loiter around SharePoint conferences. He had everyone near him in complete stitches. I was not aware of his metal leanings which raised his stock big-time in my book. Therefore, I have made it my personal mission to convert him to Opeth. Todd is actually a bit of a wuss when it comes to the the death vocals, so it’s a little like a Microsoft guy saying they like Linux but have never used anything but Ubuntu. But rest assured, I think I can bring him around 🙂

Also Mike Watson and attendees Anders Rask and Paul Kolasky demonstrated their exquisite taste in music. When pontificating various aspects of SharePoint became tiresome, the conversation seemed to turn to metal music. It’s amazing how much creativity can come out of a conversation like that too. After a few beers, Anders, Mike and I had a great idea for a new educational SharePoint site, and I still kinda liked it in the cold light of day when I was sober again. But I haven’t asked the other two whether they still think its a good idea or whether it was just the beer talking.

But fun and frivolity aside, what was the most satisfying (and exciting) was those moments where you discover your kindred spirits – both speakers and attendees. People who think alike, who’s philosophies and outlook are absolutely aligned in the same "zone" as your own. They may address problems in different ways, and may even be in different SharePoint sub-disciplines. But you just *know* that there is something special there – it is like you all collectively "see" though the same eyes, and the whole is so much greater than the sum of the parts.

So to Ruven Gotz and Peter Serzo, it was an honour to be able to meet with you, watch your presentations and I valued the dialogue very much. Ruven for the record had the best impromptu one-liner of the entire conference. When an audience member suggested an alternative software package to what he used, he replied by saying he’d been married to his wife for 27 years and he was pretty happy with her as well – had the audience in stitches. Peter Serzo dragged a freakin’ piano from the lobby to his session room at 2am and spent another hour practicing. Then the next day he presented half of his conference seated at the piano playing various ditties. Brilliant stuff.

Both of your presentations set off all sorts of light globes in my head, and set the creative juices flowing. I really believe there is the nucleus of something special there and I feel some future collaboration in the very near future.  Andrew Woodward will definitely be a part of it (although he doesn’t know it yet – hehe).

So, who knows? If the feedback from my sessions is good, I might manage to wrangle an appearance at the UK one?

Hi all

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

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

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

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

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

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

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

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

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

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

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

.. and that’s just day one!

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

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

Hope to see you there!

Paul Culmsee

Just a quick note to say that I’ll be seeing many of you (I hope) in San Diego from Feb 2-4 at the Best Practices SharePoint Conference http://www.sharepointbestpractices.com/. I’ll be talking on a couple of key interest topics for me in the CIO stream – one topic in particular I have worked really hard on over the last few months and I really hope that others find value in it as well – only time will tell eh?

On a much more important note, can anybody recommend some good US beers to try because Bud is freakin’ awful 🙂

cheers

Paul

To review this book I need to tell you a true story first…

The very first MOSS 2007 project that I was involved in did not go well. I was the architect who had to design the SharePoint farm, perform some IA work, sort out governance and work with the stressed out project manager who was dealing with stakeholders who insisted we press ahead, despite the fact they all had wildly different interpretations of what problem they were trying to solve.

In fact, my first series on branding, ROI and disk planning were inspired from that particular project. Other articles such as my “document management for metalheads” and my “project failure” series were also inspired by it too (although in that case the actual articles came from more broad soul searching).

Now one thing that came out of that experience, is that the organisation had a string of problematic projects prior to that. Thus they had attempted to rectify the problem by doing what many medium to large organisations do. They put together a program management office (PMO). Highly paid consultants came in and trained up various staff on the rigour and process for a PMO based on a PMBOK foundation. I was very supportive of this initiative, because at that time I was hell bent on achieving the PMP certification, so I was studying PMBOK anyway.

PMBOK for those who don’t know stands for the Project Management Body of Knowledge. It is a set of project management best practice guidelines produced by the Project Management Institute (PMI). Since the word “institute” is in its name, they are obviously really, really smart.

But the very same highly paid PMBOK consultants had no SharePoint experience. So, they also put together a new Project management Information System (PMIS) based on a complex folder structure, a bunch of new MSWord based forms, strictly managed manual workflows in relation to managing and tracking various critical aspects of projects (Excel-based, of course).

So, here we were, implementing a large scale collaboration project with the aim of improving the management and tracking of knowledge within the organization, and the PMO was not actually using SharePoint. The irony was not lost on me, especially considering that this was a service based organisation that made its money by undertaking projects! Even better, the outcome for the SharePoint project was to create “project portals” for staff to better manage their own information!

I used to make the point that it sent a bad message when we were undertaking a project to bring SharePoint to the masses so they could better manage their projects, yet not using it to manage *this* project. What did that say about our confidence with the platform?

Of course, it was easy for me to criticise this perceived hypocrisy because I was the tech guy who had learned how the product worked. The others had not had that luxury and trying to learn PMBOK rigour, combined with a new tool was simply too much for them to handle.

Story over – fast forward two and a half years later, here we are and what do we have…?

When I first heard that this book was coming out I was very pleased because I noted that its author, Dux Raymond Sy was certified as a Project Management Professional (PMP). This means that Dux has passed an exam validating his knowledge of PMBOK, but more importantly, had the real world experience to even qualify (PMBOK has some tight eligibility requirements). Given my interest and knowledge of PMBOK and experience of working in a PMBOK based PMO, I was very keen to read this book indeed. Luckily for me, Dux was kind enough to give me this opportunity and supplied me a review copy.

Before you even start on this book, do not skip the preface. Dux is not setting out to write for low level geeks or developers. In this book, you will not find insights into how to create a custom site definition for a PMO, complete with stapled features, event handlers or Visual Studio based workflows. Instead this book is more akin to a more focused “Teach yourself SharePoint” type book, combined with a “Project Management 123” style book.

Dux states that he has written the book for the following groups, of which only the last one may have expectation issues.

• Project Managers
• Project team members
• Program Managers
• IT/IS Directors
• SharePoint consultants

Aside from the last group, we are not exactly talking uber-tech geeks here. Additionally, Dux explicitly states that the book can help SharePoint consultants to “leverage your SharePoint technical skills by offering a focused approach to implementing SharePoint as a PMIS“. He also states in his assumptions that “I am not inclined to write yet another technical book about SharePoint … the level of technical detail I will cover is just enough to get your PMIS up and running“.

So this book is pitched squarely at the end-user as far as the complexity and accessibility of the material, and Dux has actually come up with something that I think is of value to people who do not have a project management background either.

End-user training books work best when there is a context to the lessons. So whether it is using SharePoint for project management or using SharePoint to help Americans to play the game of cricket, having that unifying theme underneath always makes for a more coherent book helping to explain the rationales for all your actions.

Dux has used PMBOK as the basis to introduce SharePoint features. Each chapter steps you through the project management life cycle from project kickoff at Chapter 1, to project closing at Chapter 9.

Chapter 1 outlines the essential project management activities that have to take place and borrows from PMBOK theory. The concept of a PMIS is introduced and SharePoint is introduced as a product. Thankfully for all of us, Dux has resisted the urge to waste excessive paper on the history of SharePoint; something that every other author seems to feel compelled to do. The chapter is finished off by introducing a fictitious company called “SharePoint Dojo Inc.” which is used throughout the rest of the book.

Chapter 2 is entitled “Setting Up the PMIS” and starts by explaining SharePoint basics such as top level sites and subsites and site templates. He then relates this back to how a PMO may be structured. Once again, rather than go into excess theory, several different ways to organise your PMO are suggested with some basic considerations and we are quickly creating a SharePoint site as a workshop. The key point here is that Dux has set the scene, explained what we are going to do and the outcome that we want. Readers therefore aren’t going through the motions without knowing why. Each workshop then has a debrief that summarises the actions performed.

Chapter 3 is called “Adding PMIS Components” and, once again, Dux sets the scene by explaining the functionality that a PMIS needs to provide. This premise is used to introduce lists and libraries, and this is where non project management readers will also get benefit. There are lists and libraries created for tracking project risks, tasks, resources, contacts and documents with some customizations. Therefore, readers get a subtle introduction to PMBOK as well as learning how to customize lists and libraries in SharePoint.

Chapter 4 deals with “Adding stakeholders to the PMIS”, which is essentially a subtle way to write a chapter on managing users, groups and permissions.

Chapter 5 is entitled “Supporting Team Based Collaboration” and builds on chapters 2-4 by introducing more advanced SharePoint features, such as versioning, check-in and content approval in the context of project team members, stakeholders and project sponsors wanting to review and track the evolution of project documentation. Dux then introduces Wikis, discussion boards and document workspaces on the premise that “collaborative project activities can be ad hoc, offline or remote in nature”, such as brainstorming, sharing lessons learned and continual process improvement.

Chapter 6 is back into the PMBOK discipline again and is called “Project tracking”. It expands on chapter 3 in particular and tracking project tasks and risks. The workshop updates the lists with chapter 3 and requires readers to make more advanced changes to the existing lists. Additional columns are added and the datasheet view is introduced. The second half of chapter 6 introduces workflows, and the out of the box three-state workflow concept is introduced and implemented as a change control system.

Chapter 7 builds on chapter 6, by talking about requirements for project reporting in a PMIS and covers the SharePoint features of custom views, specific web parts and alerts to achieve this. This chapter also covers the creation of web part pages for the purpose of management dashboards (publishing pages are not covered). Mind you, later in this chapter the MOSS only KPI web parts are covered as well as a 3rd party web part by Bamboo Software. Alerts are also covered off, as well as particular attention to meeting workspaces as a means to improve the quality of project meetings. Anyone in project management knows, that meetings are a fact of life and a constant source of frustration and wastage.

Chapter 8 deals with integration issues. Dux offers techniques for integrating MS Project with SharePoint and Excel for managing SharePoint lists. Out of the box integration with SharePoint and MS Project is not overly slick and some 3rd party options are suggested. The integration with Excel on the other hand was actually something that I did not know existed – bi-direction sync between Excel and SharePoint via a Microsoft add-in.

Chapter 9 is the final chapter and entitled “Project Closing”. By this time we have created a fully functional PMIS site and this chapter rounds off the book by taking our complete site, and saving it as a template for re-use for new projects. As a final note, Dux writes about the importance of buy-in from stakeholders when adopting SharePoint as a PMIS.

I think that the level of detail that this book went into was well pitched at Dux’s targeted audience. If I was to make one suggestion in relation to the coverage of SharePoint features, it would have been to include both filter web parts and the concept of web part connections in chapter 7. I think that web part connections add an extra dimension to dashboards without requiring application development expertise. This may have been a good fit for this book.

SQL Reporting services integration may have been worthwhile in chapter 8 as well. Whilst excessive detail is not required for reporting services, the sort of functionality that it provides is definitely worth covering, especially as MOSS specific functionality like KPI web parts were mentioned. That chapter also was fairly small compared to the other chapters and I think this would have rounded it off nicely.

In terms of people who have never been involved with project management disciplines, there is also something to offer here. This book is not a PMBOK study guide by any stretch, but it still provides an insight into the rigour and processes that should be followed when managing projects. For that reason, I think that this book is actually better than many of the “teach yourself…” style books that provide lessons without an underlying context. If I was to nit-pick in this area, there is probably scope for further fleshing out some of the head-space around project management practice. But in saying that I’ve already read PMBOK books so I may be biased in this regard.

If Dux felt really inclined, he could probably repeat this formula. I could easily see this style of book being applied to say, using SharePoint for Scrum methodology.

All in all, a great book for what it is and a “must read” for those involved in project management who want to know what SharePoint is all about.

Paul Culmsee

I thought that this article was topical given that I am writing on how organisational culture and behavioural style impacts the sorts of collaborative tools that individuals and organisations gravitate to and find useful.

The reports cover 11 common Web 2.0 technologies that can potentially find value in the enterprise:

• microblogs,
• prediction markets,
• social networking,
• widgets,
• blogs,
• RSS feeds,
• wikis,
• forums,
• podcasts, and
• social bookmarks.

http://www.destinationcrm.com/Articles/CRM-News/Daily-News/Wikis-Grow,-Podcasts-and-Social-Bookmarking-Slow-51507.aspx

The short version for those who can’t be stuffed reading it?

• Microblogs – too early to tell
• Forums, Podcasts and Social Bookmarking are not seen as strategically valuable to enterprises.
• Wikis are popular and well adopted, blogs also popular (but less than wikis)
• Social networking tools are finding value in certain demographics but have not really taken off yet

Do readers agree with their conclusions?

I have to say that regarding forums, a lot of clients ask for them and many always seem to be blank 🙂

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