Rediscovering my curiosity at Creative Melbourne

Send to Kindle

As I write this I am somewhere over the middle of Australia, flying back to Perth after participating in a 3 day event that was fun, challenging and highly insightful. The conference was Creative Melbourne, and I am proud to say I was one of the inaugural speakers. If they want me back again, I will do it in a heartbeat, and I hope a lot of you come along for the ride.


The premise: practical co-creation…

First the background… I have known the conference organiser, Arthur Shelley, for a few years. We first met at a Knowledge Management conference in Canberra and though I have no recollection of how we got talking, I do recall we clicked fairly quickly. At the time I was starting to explore the ideas around ambiguity, which eventually formed my second book. Back then I had a chip on my shoulder about how topics like complexity, Design Thinking and collaboration were being taught to students. I felt that the creative and fun parts glossed over the true stress and cognitive overload of wicked problems. This would produce highly idealistic students who would fall flat on their face once they hit a situation that was truly wicked. I therefore questioned whether anything was being built into students mental armory for the inevitable pain to come.

Now for some people who operate and teach in this space, making such a statement immediately and understandably gets their defenses up. But not Arthur – he listened to everything I had to say, and showed me examples of how he structured his courses and teachings to deal with this challenge. It was impressive stuff: every time his students thought they had a handle on things, Arthur would introduce a curveball or a change they were not anticipating. In other words, while teaching the techniques, he was building their capacity for handling ambiguous situations. Little did I know his conference was about to do the same to me…

One thing about Arthur that blows me away constantly is his incredible network of practitioners in this space. Arthur has long had a vision for bringing a constellation of such practitioners together and he hand-picked a bunch of us from all over the world. The premise, was to create an event that had a highly practical focus. He wanted practitioners to help attendees “Discover creative techniques to enhance performance and engage your team back at the office to increase productivity.”

Now where did I leave my curiosity?

While I am a sensemaking practitioner, I’ll admit straight up that I get irritated at the “fluffiness” and rampant idealism in this space. A good example is Design Thinking in this respect. While I like it and apply ideas from it to my practice, I dislike it when Design Thinking proponents claim it to be suited to wicked problems. The reality is the examples and case studies often cited are rarely wicked at all (at least in the way the term was originally conceived). When I see this sort of thing happening, it leaves me wondering if proponents have truly been in a complex, contingent situation and had the chance to stress test their ideas.

Now I don’t apologise for critically examining the claims made by anyone, but I do apologise for the unfortunate side effect – becoming overly contrarian. In my case, after all these years of research, reading and practice in this field, I am at the point where I see most new ideas as not actually new and are rediscoveries of past truths. Accordingly, it has been a long time since I felt that sense of exhilaration from having my mental molecules rearranged from a new idea. It makes sense right? I mean, the more you learn about something, the more your mental canvas has been painted on. In my case I already have a powerful arsenal of useful tools and approaches that I call upon when needed and more importantly, I was never on a spiritual quest for the one perfect answer to the mysteries of organsiational life anyway.

In short, I have what I need to do what I do. The only problem is somewhere along the line I lost the very sense of curiosity that started me along the path in the first place. It took Arthur, fellow presenters like Stuart French, Jamie Bartie, Jean-Charles Cailliez, Meredith Lewis, Brad Adriaanse, Vadim Shiryaev and a diverse group of participants to help me rediscover it…

Disrupting the disruptor…

Imagine someone like me participating in day 1, where we did things like build structures out of straws, put on silly hats, used the metaphor of zoo animals to understand behaviors, arm-wrestled to make a point about implicit assumptions and looked at how artists activate physical space and what we could learn from it when designing collaborative spaces. There was some hippie stuff going on here and my contrarian brain would sometimes trigger a reflexive reaction. I would suddenly realise I was tense and have to tell myself to relax. Sometimes my mind would instinctively retort with something like “Yeah right… try that in a politicised billion dollar construction project…” More than once I suppressed that instinct, telling myself “shut up brain – you are making assumptions and are biased. Just be quiet, listen, be present and you might learn something.”

That evening I confided to a couple of people that I felt out of place. Perhaps I was better suited to a “Making decisions in situations of high uncertainty and high cognitive overload” conference instead. I was a little fearful that I would kill the positive vibe of day 1 once I got to my session. No-one wants to be the party pooper…

Day 2 rolled around and when it was my turn to present. I held back a little on the “world according to Paul” stuff. I wanted to challenge people but was unsure of their tolerance for it – especially around my claims of rampant idealism that I mentioned earlier. I needn’t have worried though, as the speaker after me, Karuna Ramanathan from Singapore, ended up saying a lot of what I wanted to say and did a much better job. My talk was the appetizer to his “reality check” main course. He brilliantly articulated common organsiational archetypes and why some of the day 1 rhetoric often hits a brick wall. It was this talk that validated I did belong in this community after all. Arthur had indeed done his homework with his choice of speakers.

That same afternoon, we went on a walking tour of Melbourne with Jamie Bartie, who showed us all sorts of examples of cultural gems in Melbourne that were hiding in plain sight. The moral of the story was similar to day 1… that we often look past things and have challenge ourselves to look deeper. This time around my day 1 concerns had evaporated and I was able to be in the moment and enjoy it for what it was. I spoke to Jamie at length that evening and we bonded over a common childhood love of cult shows like Monkey Magic. I also discovered another kung-fu movie fan in Meredith Lewis, who showed me a whole new way to frame conversations to get people to reveal more about themselves, and develop richer personal relationships along the way.

Petcha Kucha – Getting to a point…

Day 3 was a bit of a watershed moment for me for two reasons. Months prior, I had accepted an invitation from Stuart French to participate in his Petcha Kucha session. At the time I said “yes” without really looking into what it entailed. The gist is you do a presentation of 20 slides, with 20 seconds per slide, all timed so they change whether you are ready or not. This forces you to be incredibly disciplined with delivering your talk, which I found very hard because I was so used to “winging it” in presentations. Despite keynoting conferences with hundreds of people in the room, doing a Petcha Kucha to a smaller, more intimate group was much more nerve-racking. I had to forcibly switch off my tangential brain because as soon as I had a thought bubble, the slides would advance and I would fall behind and lose my momentum. It took a lot of focus for me to suppress my thought bubbles but it was worth it. In short, a Petcha Kucha is a fantastic tool to test one’s mental muscles and enforce discipline. I highly recommend that everyone give it a go – especially creative types who tend to be a bit “all over the place”. It was a master-stoke from Stuart to introduce the technique to this audience and I think it needs to be expanded next time.

I presented the first Petcha Kucha, followed by Stuart and then Brad Adriaanse, who described the OODA Loop philosophy. OODA stands for observe, orient, decide, and act, providing a way to break out of one’s existing dogma and reformulate paradigms, allowing you to better adapt to changing circumstances. Dilbert cartoons aptly shows us that we all have incomplete (and often inconsistent) world views which should be continually refined and adapted in the face of new observations. Brad put it nicely when he said OODA was about maintaining a fluid cognitive state and that assumptions can be a straightjacket and dogma can blind us. This really hit home for me, based on how I reacted at times on day 1. Brad also said that the OODA loop can be internalised by adopting a lifelong learning mindset, being curious and become more and more comfortable with ambiguity.

It was at this exact moment where I rediscovered my latent curiosity and understood why I felt the way I did on day 1 and 2. It was also at this moment that I realised Arthur Shelley’s genius in why he made this event happen, who he brought together and what he has created in this event. All attendees need to be disrupted. Some need their idealism challenged, and some, like me, need a reminder of what started us on this path in the first place.

I have returned a better practitioner for it… Thankyou Arthur


Paul Culmsee

p.s Arthur Shelley is still a giant hippie

 Digg  Facebook  StumbleUpon  Technorati  Slashdot  Twitter  Sphinn  Mixx  Google  DZone 

No Tags

Send to Kindle

Teddies, Fetishes and the Management Consulting Scam

Send to Kindle


What if I told you that the key to becoming a successful management consultant was to become a Teddy Bear?

What if I also told you that it involves fetishes? You might be re-checking the URL to make sure you are on the right site!

Fear not, this article is definitely not “50 Shades of Management Consulting Grey”. Nor is it about donning a cuddly animal suit as a mascot for a football team. To borrow from the much loved children’s TV show “Playschool,” there’s definitely a bear in there, but not the one you might be thinking!

You see, for many people, modern corporate life is now at a point where pace of change is accelerating, unrelenting and fatiguing. In my home state of Western Australia, businesses are reeling from unprecedented levels of disruption and uncertainty, be it the end of the commodity boom, the impact of global competition or disruptive, technology-enabled innovation. It is now difficult to think of any industry that has not had the ground shift beneath it in some way — except perhaps, for Management Consulting.

Management Consulting thrives in an environment of fear, ambiguity and doubt, principally because its business model is based on the presumption that they can make it go away. It’s lucrative too — ambiguity is such a powerful force that executives will part with copious amounts of cash in attempts to escape it…

read the full article at

 Digg  Facebook  StumbleUpon  Technorati  Slashdot  Twitter  Sphinn  Mixx  Google  DZone 

No Tags

Send to Kindle

What does project management mean to me – a Project Manager’s sermon

Send to Kindle

The "message"

What does project management mean to me?

Well if you want me to give you the ‘glass half empty’ perspective, it’s easy. What project management means to me is a confused discipline where practitioners routinely do really dumb shit in its name.

Sermon over – go forth and spread the word…

Okay so that was fairly blunt, so I had better elaborate and perhaps take a more positively framed ‘glass half full’ approach to this sermon. To do that, I need to tell you about the legacy that Cleo magazine has left on society.

When I was younger, I used to skim through magazines like Cosmopolitan and Cleo while waiting in line at the checkout. Now you might think that I must really be in touch with my feminine side in admitting this, but no: the reality is that raw testosterone was the motivator. You see, Cleo would have headline articles like “10 great sex tips (in 50 words or less)” Or “The 10 things he doesn’t want in bed.” Titles like that dangled the possibility in front of me of finally understanding women, with the added bonus of developing Olympic class skills in the bedroom. Of course, each and every time the actual article never lived up to the catchy title. I rarely learnt anything new and in fact the “10 things” were usually pretty banal, self-evident and left me none the wiser.

So as our collective attention spans diminish via constant exposure to “5 steps to success with [insert buzzword here]” articles (articles designed more for search engine placement than actually informing an audience), the curse of Cleo-like catchy titles telling you stuff of little value is now so commonplace that it is hard to suss out the stuff that really makes a difference in outcomes.

So where does one go to find out the answers in project management? Should aspiring Project Managers master the dark arts of their craft by learning everything there is to learn from one or more of the bibles that contain the word “BoK” in them? On the surface it would seem so, given all of the past collective wisdom that is claimed to be codified therein – as well as shiny certification proving that one has passed the multi-choice exam on its contents.

But wait…which BoK is best? After all, we have multiple to choose from, with each making their own claims to the truth. Some BoKs even reject the key tenets of other BoKs, arguing that theirs offers a better answer. Of course, this leads to an endless stream of debate by their respective proponents as to which is really best and who is really the wisest. Not to mention that over time, new and updated BoKs emerge like phoenixes from the ashes of older BoKs. (Sometimes they are so cool that they don’t even claim to be a BoK at all).

It’s little wonder that Project Management is a confused discipline. No matter where you turn, someone is bound to tell you that you are doing it wrong.

While I am on the subject of doing it wrong, let’s poke a stick in one of the well-known project management hornets-nests: the “Waterfall vs. Scrum” argument. We all know that any self-respecting Scrum guy will not miss an opportunity to tell you about the evils of Waterfall – and for the most part they are right too, as Waterfall has a dubious history of which most people are not aware.

But that is not the reason I chose this particular topic, even though it is much loved by PMs who spend endless hours filling up the forums of various LinkedIn groups with discussion. I chose it simply because it’s fun to mess with Scrum guys – particularly the zealots. So if you have a “scrumdamentalist” in your midst, try this question on them:

Would Waterfall work if one could create an environment where all parties—as soon as they become aware of something that might affect a project materially—communicate it to all other parties involved in the project in a full, sincere and open way?

I have posed this question to many Scrum people. Most will think about it for some time, before answering a grudging “possibly” or “I don’t see why not.” Try it yourself… it’s fun pulling the rug out from under their firmly held convictions.

The best answer I have ever got to this question was from Chris Chapman – an Agile coach from Toronto. He gave me what I think is the perfect answer when he astutely observed that in the environment I described, Waterfall would actually not exist in the first place!

Therein lies the heart of my sermon. I contend that the endless debates over the efficacy of methods, tools and even BoKs are answering the wrong question! Don’t worry though, Project Management is not the first, nor the last discipline to lean their ladder against the wrong wall in this regard. To explain, let me introduce you to the work (and genius) of J Richard Hackman.

From the late sixties, Hackman spent his career researching and teaching about team performance, leadership effectiveness, and the design of self-managing teams and organizations. He died in 2013 and one of his last papers he published was called “From causes to conditions in group research.” In this swansong paper, Hackman explained how he spent years examining the factors that made teams work really well. He studied hundreds of teams (not just project teams mind you, but sporting teams, orchestras and flight crews), with the aim to distil the causes of success. Each time Hackman thought he had the causes figured out he would create a model, plug his model into a stats program, and work with real teams to see if the application of his model led to better performance.

On the surface, this approach seems like a logical thing to do. After all, if we can work out the magic levers that cause team success, then organisations would surely work better because they can start to pull those same levers. This is precisely the value proposition offered by the aforementioned BoKs as well.

When Hackman applied the models he lovingly researched and developed, he found they did not make a significant difference in outcomes. Being an academic, he did what most academics do: he spent years trying to refine his models and then re-tested them against real life teamwork situations. But this didn’t work either; his models got no closer to predicting or influencing outcomes in a reliable fashion. Reality it seemed, never fitted the models he developed.

At this point, Hackman began to question whether he was looking at the problem through the right lens. He wondered if trying to determine the causes of team efficacy by looking at successful teams retrospectively and then codifying these into causal models was the best approach. So he changed his focus and asked himself a very different question – a question that every project management practitioner (and project team member) should be asking themselves:

What are the enabling conditions that need to exist that give rise to great outcomes?

Now if, at this point, you think that this is the same question as “What are the causes of successful projects” you would be mistaken. Think about the BoKs and consider this: if you have ever argued with someone about whether a tool, methodology or some process is great or completely sucks, eventually someone will say something like “Well it can work for the right organisation.”

The implicit point here is that depending on the conditions, something that works for one organisation may completely suck for another (thereby invalidating the notion of a “best” practice). The genius of Hackman is that he challenges us to stop arguing about whether one methodology or model is better than the other and focus on what the enabling conditions are instead. Think about it – if project managers and developers did this, we would be able to avoid low value arguments like earned value management versus burndown charts.

In the case of Hackman, he re-examined all of his work on teams and boiled it down to six essential conditions, arguing that irrespective of what else you did or what methodology you used, having these conditions tended to lead to better results. Hackman did not rank any one condition over any other, instead arguing that all were needed for teams to have a greater chance of being high performing. The conditions are:

  1. A real team: Interdependence among members, clear boundaries distinguishing members from non-members and moderate stability of membership over time
  2. A compelling purpose: A purpose that is clear, challenging, and consequential. It energizes team members and fully engages their talents
  3. Right people: People who had task expertise, self-organised and skill in working collaboratively with others
  4. Clear norms of conduct: Team understands clearly what behaviours are, and are not, acceptable
  5. A supportive organisational context: The team has the resources it needs and the reward system provides recognition and positive consequences for excellent team performance
  6. Appropriate coaching: The right sort of coaching for the team was provided at the right time

There is more to that list than what I am covering here, and it is important to note that I’m not saying that Hackman’s conditions are *the* conditions. But I would contend that they are a pretty good start. Look at Hackman’s conditions for teams above and think about your projects and how you manage them. Did you have these conditions in place when you started? If you had them, would it have led to better outcomes?

I believe that it is a huge mistake to attribute success or failure of projects to methods, processes and models used to manage them rather than the conditions in which those processes operate. As long as this attribution error persists, people will continue to get suckered into B-grade verbal-slugfests about whether method X is better than method Y.

What exacerbates this “causes over conditions” problem is that enabling conditions rarely get codified in procedures, governance models, bodies of knowledge or certifications. As a result, the very factors that leads to success (the conditions) are entirely absent from the models that we use. My contention is that most organisations, when delivering projects, do not have the right enabling conditions in place to begin with. If your organisation has a blame culture, then chances are that any process, no matter how noble its design or intent, has the potential to become a blame apportionment mechanism or a responsibility avoidance mechanism.

So Hackman, despite looking at a different discipline of teamwork and leadership, gives us an important clue about what ails project management and how to we might improve it. Focus on enabling conditions rather than attributing causes!

Let’s get back to Chris Chapman’s answer to my Waterfall question. His assertion that Waterfall would not exist in the conditions I described holds a less obvious lesson. That is, the way project management tools or methods are used will affect conditions as well. So if you have ever said to yourself “I can’t believe that I am being forced to follow this wrong-headed process” chances are you have been on the receiving end of negative conditions created by application of a process. (So in this sense the agile dudes have it right.)

So what does project management mean to me? In short, focusing on creating the enabling conditions for great performance, and then getting out of the way!


Thanks for reading

Paul  Culmsee



In this sermon I cannot hope to cover all of the things I would like to cover but never fear, Kailash Awati and I already piled some of our thoughts into 420 pages of goodness known as the book “The Heretics Guide to Best Practices” – so if you like what you read here, you will really like what is in there.


As usual I have to thank Kailash for reviewing this post and making it suck much less than it did 🙂

Further reading:

  1. My series on rethinking SharePoint maturity: Don’t let the title put you off – the material here further explores the conditions for great project performance:
  2. Jon Whitty’s brilliant work on memeplexes and reconceptualising project management:
  3. Pretty much anything on Kailash Awati’s blog, but in particular his sermon in this flashblog:
  4. Stephen Duffield’s work on project knowledge management and risk:

p.s: This post is published as part of a first ever project management related global blogging initiative to publish a post on a common theme at exactly the same time. Over seventy bloggers from Australia, Canada, Colombia, Denmark, France, Italy, Mexico, Poland, Portugal, Singapore, South Africa, Spain, UK and the USA have committed to make a blogging contribution and the fruit of their labor is now (literally NOW) available all over the web. The complete list of all participating blogs is found here so please go and check them out!

 Digg  Facebook  StumbleUpon  Technorati  Slashdot  Twitter  Sphinn  Mixx  Google  DZone 

No Tags

Send to Kindle

Powerful questions part 1: The platitude buster question

Send to Kindle

Hi all

I’ve been a little busy lately so haven’t had sufficient time to write many articles. This will likely continue for a while as I’m also planning the next heretical book with Kailash.

But the other day on a whim, I decided to record a short video on the topic of powerful questions. As I do more and more facilitation, strategic planning and team development work, I am constantly learning about the patterns of group conversation. This has helped me develop insights into the sort of questions that have the potential to cut through complexity to achieve breakthroughs in complex situations. I call these questions “powerful” for that reason.

It should be noted that a powerful question is not necessarily the question itself, but sometimes the the way a question is asked. To that end, in this first video, I take you through the best way I know to cut through organisational platitudes. Platitudes are phrases that often sound impressive and authoritative, ultimately hide the fact that there is not a lot of substance underneath them. While its easy to cite a blatant example like “best practice organisational excellence,” most of the time platitudes are used unconsciously and in much more subtle and dangerous ways. In fact often people ask questions or conduct workshops in such a way that actually encourage platitude answers.

So how do I bust or disarm a platitude? Watch this video to find out! Smile

How to disarm a platitude with one question…

Now I plan to do a few of these videos, with each building on the last with a new powerful question. Also, I will utilise Compendium and Dialogue Mapping techniques, so you also get a better idea of the sort of non SharePoint work that myself and my colleagues get to perform. So please let me know what you think of the clip. (oh – before I forget, I strongly suggest you watch the video in full screen)

Thanks for reading

Paul Culmsee


 Digg  Facebook  StumbleUpon  Technorati  Slashdot  Twitter  Sphinn  Mixx  Google  DZone 

No Tags

Send to Kindle

Confession of a (post) SharePoint architect… “Thou shalt NOT”

This entry is part 10 of 10 in the series confessions
Send to Kindle

Hi all


This post comes to you during my reality check of returning to work after the bliss of 1 month of vacation in New Zealand. After walking on a glacier, racing around in jetboats and relaxing in volcanic hot springs, the thought of writing SharePoint blog posts isn’t exactly filling me with excitement right now. But nevertheless I am soldiering on, because as Ruven Gotz frequently tells his conference attendees – I do it because I love you all.

Now this is article ten (blimey!) in a series of posts about my insights of being a cross between a SharePoint architect and facilitator/sensemaker. In case this is your first time reading this series, I highly recommend that you go back to the beginning as we have covered a lot of ground to get to here. Inspired by the late, great Russell Ackoff, I used his notion of f-laws – sometimes inconvenient truths about what I think is critical for successful SharePoint delivery. At this point in proceedings, we have covered 6 f-laws across 9 articles.

The next f-law we are going to cover is a bit of a mouthful. Are you ready?

F-Law 7: The degree of governance strictness is inversely proportional to the understanding of the chaos its supposed to prevent

So to explain this f-law, here is a question I often ask clients and conference attendees alike…

What is the opposite of governance?

The answer that most people give to this question is “Chaos”. So what I am implying? Essentially that the stricter you are in terms of managing what you deem to be chaos, the less you actually understand the root causes of chaos in the first place.

Ouch! Really?

To explain, let’s revisit f-law 5, since this is not the first time the theme of chaos has come up in this series. If you recall f-law 5 stated that confidence is the feeling you have until you understand the problem. In that article, I drew the two diagrams below, both of them representing the divergence and convergence process that comes with most projects. The pink box labelled chaos illustrated that before a group can converge to a lasting solution, they have to cross the ‘peak’ of divergence. This is normally a period of some stress and uncertainty – even on quite straightforward projects. But commonly in SharePoint things can get quite chaotic with lots of divergence and very little convergence as shown by the rightmost diagram where there appears to be little convergence.

image  image

“Thou shalt not…”

There are clearly forces at play here… forces that push against convergence and manifest in things like scope creep, unreconciled stakeholder viewpoints and the stress of seeing the best laid plans messed with. The size and shape of the pink ‘chaos’ box reflects the strength of those underlying forces.

To manage this, many (if not most) SharePoint practitioners take a “thou shalt not” approach to SharePoint delivery in an attempt to head things off before they even happen. After the dissection in f-law 6 of how IT people channel Neo and focus on dial tone issues, it is understandable why this approach is taken. Common examples of this sort of thinking are “Thou shalt not use SharePoint Designer” or “Thou shalt use metadata and not folders” or “Thou shalt use the standard site template no matter what.”

These sort of commandments may be completely appropriate, but these is one really important thing to make sure you consider. If having no governance indeed results in chaos, then it stands to reason that we need to understand the underlying divergent forces behind chaos to mitigate chaos and better govern it. In other words, we need look inside pink box labelled chaos and see what the forces are that push against convergence. So lets modify the diagrams above and take a look inside the pink box.


For me, there are four forces that govern the amount of chaos in SharePoint projects, namely:

  1. Pace of Change
  2. Problem Wickedness
  3. Technical Complexity
  4. Social Complexity

Let’s examine each one in turn…

Pace of change


Remember the saying “The only certainty in life are death and taxes”? Outside of that, the future is always unpredictable. In between SharePoint 2003 and SharePoint 2007, the wave of web 2.0 and social networking broke, forever changing how we collaborate and work with information online. In between SharePoint 2010 and SharePoint 2013, the wave of cloud computing broke, which is slowly but surely changing the way organisations view their IT assets (both systems and people). The implications of this are huge and Microsoft have to align their product to tap into these opportunities. Net result? We all have a heap of new learning to do.

If you read the last post, you might recall that pace of change was a recurring theme when people answered the question about what is hard with SharePoint. But let’s look beyond SharePoint for a second… change happens in many forms and at many scales. At a project level, it may mean a key team member leaves the organisation suddenly. At an organisational level, there might be a merger or departmental restructure. At a global level, events like the Global Financial Crisis forced organisations to change strategic focus very quickly indeed.

The point is that change breeds innovation yet it is relentless and brings about fatigue. Continual learning and relearning is required and even the best laid plans will inevitably be subject to changing circumstances. The key is not to fight change but accept that it will happen and work with it. In terms of SharePoint, this is best addressed by an iterative delivery model that has a high degree of key stakeholder involvement, recognises the learning nature of SharePoint and fosters meaningful collaboration.

Problem “Wickedness”


Some problems are notoriously hard to solve because they evoke a lot of diverse, often conflicting viewpoints and it can be difficult even agreeing on what the core problem actually is. F-law 1 examined how we sometimes fixate on the means of governance when the end goal of SharePoint is uncertain. Over-reliance on definitions is the result. F-law 2 looked at how users understanding of a problem changes over time and f-Law 4 looked at the folly in chasing platitudes. The underlying cause for all of these f-laws is often the very nature of the problem you are trying to solve.

You might have heard me talk about wicked problems or read about it in my blog or my book. In short, some problems are exceptionally tough to solve. Just trying to explain the problem can be hard, and analysis-paralysis is common because it seems that each time the problem is examined, a new facet appears which seemingly changes the whole concept of the problem. This phenomenon was named as a wicked problems by Horst Rittel in 1970. One of the most extreme examples right now of a wicked problem in the USA would be the gun control debate since depending on your values and ideology, you would describe the underlying problem in different ways and therefore, the potential solutions offered are equally varied and contentious.

While there are actually many different management gurus who have also come up with alternate names for this sort of complexity (“mess”, “adaptive problem”, “soft systems”), the term wicked problem has become widely used to describe these types of problems. I suspect this is because Rittel listed a bunch of symptoms that suggest when your problem has elements of wickedness. Here are some of the commonly cited ones:

  1. There is no definitive formulation of a wicked problem (defining wicked problems is itself a wicked problem).
  2. The problem is not understood until after the formulation of a solution.
  3. There is no immediate and no ultimate test of a solution to a wicked problem.
  4. 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.
  5. 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.
  6. Every wicked problem is essentially unique.
  7. Every wicked problem can be considered to be a symptom of another problem.
  8. 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.
  9. Stakeholders have radically different world views and different frames for understanding the problem.
  10. The constraints that the problem is subject to and the resources needed to solve it change over time.
  11. The problem is never solved definitively

Can you tick off some of those symptoms with SharePoint? I’ll bet you can… I’ll also bet that for other IT projects (say MS Exchange deployments) these symptoms are far less pronounced.

Guess what the implication is of wicked problems. They tend to resist the command-and-control approach of delivery and require meaningful collaboration to get them done. That is kind of funny when you think about it since SharePoint is touted as a collaboration tool yet falls victim to wicked elements. That suggests that there was not enough collaboration to deliver the collaboration platform!

Technical Complexity


Technical complexity involves difficulties in fact finding, technical information and the systematic identification and analysis of options and their likely consequences. It is an understatement to say that SharePoint is full of technical complexity. In fact, it is one of the most complex products that Microsoft has ever produced (and that’s before you get to dependencies like SQL Server, IIS, FIM, Federated authentication and the myriad of other things you need to know)

A typical characteristic of technical complexity is information overload in fact finding. There is far too much information to make sense of and as a result, no one person has the cognitive capacity to understand it all. Thus, stakeholders have to rely on each other and, on occasions, rely on outside experts to collaboratively work towards a solution. Technical complexity requires a lot of cognitive load to manage and it is easy to get caught up in the minute detail and lose the all important bigger picture.

Problems also arise when different technical experts come to opposite conclusions. This gives rise to the last and most insidious divergent force underlying SharePoint chaos and the governance that goes with it – social complexity.

Social Complexity


The first three symptoms tend to create a perfect storm of complexity, since we have a situation where there is a lot of uncertainty. Many people hate this because unknown unknowns creates fear if sufficient trust does not exist between all key parties. Developing trust is made all the harder because we are all a product of our experiences, with different values, cultural beliefs, personality styles and biases so reconciling different world views on various issues can be difficult. Then you have the issue that many organisations have a blame culture and people position themselves to avoid it. This my friends is social complexity and I know that all of you live this sort of stuff everyday.

Yet under the right circumstances, groups can be remarkably intelligent and are often smarter than the smartest people in group. Groups do not need to be dominated by exceptionally intelligent people in order to be smart – in fact diversity of group makeup is a much more important factor than individual IQ. Without this diversity, groups are less likely to arrive at a good answer to a given problem because they are likely to fall into groupthink. Groupthink is when highly cohesive groups make unsound decisions due to group pressures, ignoring possible alternatives. Every management team that only wants to hear the good news is likely to have fallen foul of groupthink. The same applies to dismissing all SharePoint governance except for the dial tone stuff.

However, there is an inherent paradox here:

  • The more parties involved in a collaboration, the more socially complex;
  • The more different these parties are, the more diverse, the more socially complex; and
  • This creates tension, resentment and lack of communication and a strong desire to go back to business as usual

This paradox between diversity and harmony is the toughest aspect of the four forces to tackle.

Key takeaways…

Way back in the very first post I stated that a key job of a SharePoint architect is to architect the conditions by which SharePoint is delivered. By this I mean that the architect has to grease the gears of collaboration between stakeholders and provide an environment that has the safety and structure for people to raise their issues, speak their truths and not get penalised for improving their understanding of the problem.

To enable this to happen, we need to tackle all four of the forces behind chaos that we have covered here. In short, if you focus governance efforts only on one of the forces you will simply inflame the others. Accordingly, the final diagram illustrates the key takeaway from f-Law 7. Since the four forces behind chaos push out and create divergence, our governance efforts needs to push back. But the important thing to note is the direction of my arrows. It is not necessarily appropriate to provide a direct counterforce via the “thou shalt not” type of all-or-nothing approach. Governance always has to steer towards the solution. The end always drives the means and not the other way around! Arbitrarily imposing such restrictions is often done without due consideration of the end in mind and therefore gets in the way of the steering process. This is why my arrows point inwards, but always push toward the solution on the right.



In this context, it can be seen why envisioning, stakeholder and goal alignment is so critical. Without it, its too easy for governance to become a self fulfilling prophecy. So when you look at your own projects, draw my divergence/convergence diagram and estimate how big the pink box is. If you sense that there is divergence, then look at where your gaps are and make sure you create the conditions that help mitigate all of the forces and not just one one of them.

Thanks for reading

Paul Culmsee

 Digg  Facebook  StumbleUpon  Technorati  Slashdot  Twitter  Sphinn  Mixx  Google  DZone 

No Tags

Send to Kindle

Confessions of a (post) SharePoint architect: Black belt platitude kung-fu

This entry is part 6 of 10 in the series confessions
Send to Kindle

Hello kung-fu students and thanks for dropping by to complete your platitude training. If you have been dutifully following the prior 5 articles so far in this series, you will have now earned your yellow belt in platitude kung-fu and should be able to spot a platitude a mile away. Of course, yellow belt is entry level – like what a Padwan is to a Jedi. In this post, you can earn your black-belt by delving further into the mystic arts of the (post) SharePoint architect and develop simple but effective methods to neutralise the hidden danger of platitudes on SharePoint projects.

If this is your first time reading this series, then stop now! Go back and (ideally) read the other articles that have led to here. Now in reality I know full well that you will not actually do that so read the previous post before proceeding. Of course, I know you will not do that either, so therefore I need to fill you in a little. This series of articles outline much of what I have learnt about successful SharePoint delivery, strongly influenced from my career in sensemaking. I have been using Russell Ackoff’s concept of f-laws – truth bombs about the way people behave in organisations – to outline all of the common mistakes and issues that plague organisations trying to deliver great SharePoint outcomes.

So far in this series we have explored four f-laws, namely:

In the last post, we took a look at the danger of conflating a superlative (like biggest, best, improved and efficient) with a buzzword like (search, portal, collaboration, social). The minute you combine these and dupe yourself into thinking that you now have a goal, you will find that your project starts to become become complex, which in turn results in over-engineered solutions solving everything and anything, and finally your project will eventually collapse under its own weight after consuming far too many financial (and emotional) resources.

This is because the goal you are chasing looks seductively simple, but ultimately is an illusion. All of your stakeholders might use the same words, but have very different interpretations of what the goal actually looks like to them. The diagram that shows the problem with this is below. On the left is the mirage and to the right is the reality behind the mirage. Essentially your fuzzy goal actually is a proxy for a whole heap of unaligned and often unarticulated goals from all of your stakeholders.

Snapshot   Snapshot

Now in theory, you have read the last post and now have a newly calibrated platitude radar. You will sit at a table and hear platitudes come in thick and fast because you will be using Ackoff’s approach of inverting a goal and seeing if a) the opposite makes any logical sense and b) could be measured in any meaningful way. As an example, here are three real-world strategic objectives that I have seen adorning some wordy strategic plans. All three set off my platitude radar big time…

“Collaboration will be encouraged”

“A best-practice collaboration platform”

“It’s a SharePoint project” Smile

I look at the first statement and think “so… would you discourage collaboration? Of course not.” Ackoff would take a statement like that and say “Stop telling me what you need to do to survive, and tell me what you need to do to thrive”.

What do you mean by?

So if I asked you how to unpack a platitude into reality, what might you do?

For many, it might seem logical to ask people what they really mean by the platitude. It might seem equally logical to come up with a universal definition to bring people to a common understanding of the platitude. Unfortunately, both are about as productive as a well-meaning Business Analyst asking users “So, what are your requirements?”

With the “what do you mean by [insert platitude here]” question, the person likely won’t be able to articulate what they mean particularly well. That is precisely why they are unconsciously using the platitude in the first place! Remember that a platitude is a mental shortcut that we often make because it saves us the cognitive effort of making sense of something. This might sound strange that we would do this, but in the rush to get things done in organisations, it is unsurprising. How often do you feel a sense of guilt when you are reflecting on something because it doesn’t feel like progress? Put a whole bunch of people feeling that way into a meeting room and of course people will latch into a platitude.

By the way, the “mental shortcut” that makes a platitude feel good seems to be a part of being human and sometimes it can work for us. When it works, it is called a heuristic, When it doesn’t its called a cognitive bias. Consult chapter 2 in my book for more information on this.

Okay, so asking what someone means by their platitude has obvious issues. Thus, it might seem logical that we should develop a universal definition for everyone to fall in behind. If we can all go with that then we would have less diversity in viewpoints. Unfortunately this has its issues too – only they are a little more subtle. As we discovered in part 2 of this series appropriately entitled “don’t define governance”, definitions tend to have a limited shelf life. Additionally, like best-practice standards, there are always lots of them to choose from and they actually have an affect of blinding people to what really matters.

So is there a better way?

It’s all in the question and its framing…

If there is one thing I have learnt above all else, is that project teams often do not ask the right question of themselves. Yet asking the right question is one of the most critical aspects to helping organisations solve their problems. The right question has the ability to cast the problem in a completely different light and change the cognitive process that people are using when answering it. In other words, the old saying is true: ask a silly question, get a silly answer.

Let me give you a real life example: Chris Tomich is a co-owner of Seven Sigma and was working with some stakeholders to understand the rationale for how content had been structured in a knowledge management portal. Chris is a dialogue mapper like me – and he’s extremely good at it. One thing Dialogue Mapping teaches you is to recognise different question types and listen for hidden questions. The breakthrough question in this case when he got some face time with a key stakeholder and asked:

  • What was your intent when you designed this structure for your content?

The answer he got?

  • “Well, we only did it that way because search was so useless”
  • “So if I am hearing you, you are saying that if search was up to scratch you would not have done it that way”
  • “Definitely not”

Neat huh? By asking a question that took the stakeholder back to the original outcome sought for taking a certain course of action, we learnt that poor search was such a constraint they compensated by altering page template design. Up until that point, the organisation itself did not realise how much of an impact a crappy search experience had made. So guess where Chris focused most of his time?

In a similar fashion, my platitude defeater question is this:

So if we had [insert platitude here], how would things be different to now?

Can you see the difference in framing compared to “what do you mean by [insert platitude here]?”. Like Chris with his “What was your intent”, we are getting people to shift from the platitude, to the difference it would make if we achieved the platitude. No definitions required in this case, and the answer you will get almost by definition has to be measurable. This is because asking what difference something would make involves a transition of some kind and people will likely answer with “increased this”  or “decreased that”.

Now be warned – a hard core middle manager might serve you up another platitude as an answer to the above question. To handle this, just ask the question again and use the new platitude instead. For example:

  • Me: Okay so if you had improved collaboration, how would things be different to now?
  • Them: We would have increased adoption
  • Me: And what difference would that make to things?

I call this the KPI question because if you keep on prodding, you will find themes start to emerge and you will get a strong sense of potential Key Performance Indicators. This doesn’t mean they are the right ones, but now people are thinking about the difference that SharePoint will make, as opposed to arguing over a definition. Trust me – its a much more productive conversation.

Now to validate that these emerging KPI’s are good ones, I ask another question, similarly framed to elicit the sort of response I am looking for…

What aspects should we consider with this initiative to [insert platitude here]?

This question is deliberately framed as neutral is possible. I am not asking for issues, opportunities or risks, but just aspects. By using the term aspects I open the question up to a wider variety of inputs. Like the KPI question above, it does not take long for themes to emerge from the resulting conversation. I call this the key focus area question, because as these themes coalesce, you will be able to ensure your emerging KPI’s link to them. You can also find gaps where there is a focus area with no KPI to cover it. As an added bonus, you often get some emergent guiding principles out of a question like this too.

The thing to note is that rather than follow up with “what are the risks?” and “what should our guiding principles be?”, I try and get participants to synthesize those from the answers I capture. I can do this because I use visual tools to collect and display collective group wisdom. In other words, rather than ask those questions directly, I get people to sort the answers into risks, opportunities and principles. This synthesis is a great way to develop a shared understanding among participants of the problem space they are tackling.

If we were unconstrained, how would we solve this problem?

This is the purpose question and is designed to find the true purpose of a project or solution to a problem. I don’t always need to use this one for SharePoint, but I certainly use it a lot in non IT projects. This question asks people to put aside all of the aspects captured by the previous question and give the ideal solution assuming that there were no constraints to worry about. The reason this question is very handy is that in exploring these “pie in the sky” solutions, people can have new insights about the present course of action. This permits consideration of aspects that would not otherwise be considered and sometimes this is just the tonic required. As an example, I vividly recall doing some strategic planning work with the environmental division of a mining company where we asked this exact question. In answering the question, the participants had a major ‘aha’ moment which in turn, altered the strategy they were undertaking significantly.

Note: If you want some homework, then check Ackoff’s notion of idealised design and the Breakthrough Thinking principle called the purpose principle. Both espouse this sort of framed question.

Sharpening the saw…

Via  the use of the above questions, you will have a  better sense of purpose, emergent focus areas and potential measures. That platitude that was causing so much wheel spinning should be starting to get more meaty and real for your stakeholders. For some scenarios, this is enough to start developing a governance structure for a solution and formulating your tactical approaches to making it happen. But often there is a need to sharpen the saw a bit and prioritise the good stuff from the chaff. Here are the sort of questions that allow you to do that:

No matter what happens, what else do we need to be aware of?

This question is called the criterial question and I learnt it when I was learning the art of Dialogue Mapping. When Dialogue Mapping you are taught to listen for the “no matter what…” preamble because it surfaces assumptions and unarticulated criteria that can be critical to the conversation and will apply to whatever the governance approach taken. Thus I will often ask this question in sessions, towards the end and it is amazing what else falls out of the conversation.

What are the things that keep you up at night?

I picked this up from reading Sue Hanley’s excellent whitepaper a while back and listening to hear speak at Share2012 in Melbourne reminded me why it is so useful. This question is very cleverly framed and is so much better than asking “What are your issues?”. It pushes the emotive buttons of stakeholders more and gets to the aspects that really matter to them at an gut level rather than purely at a rational level. (I plan to test out dialogue mapping a workshop with this as the core question sometime and will report on how it goes)

What is the intent behind [some blocker]?

This is the constraint buster question and is also one of my personal favourites. If say, someone is using a standard or process to block you with no explanation except that “we cannot do that because it violates the standards”, ask them what is the intent of the standard. When you think about it, this is like the platitude buster question above. It requires the person to tell you the difference the standard makes, rather than focus on the standard itself. As I demonstrated with my colleague Chris earlier, the intent question is also particularly useful for understanding previous context  by asking users to outline the gap between previous expectation and reality.


To there you go – a black belt has been awarded. Now you should be armed with the necessary kung-fu skills required to deflect, disarm and defeat a platitude.

Of course, knowing the right questions to ask and the framing of them is one thing. Capturing the answers in an efficient way is another. For years now, I have advocated the use of visual tools like mind mapping, dialogue mapping and causal mapping tools as they all allow you to visually represent a complex problem. So as we move through this series, I will introduce some of the tools I use to augment the questions above.

Thanks for reading


Paul Culmsee

 Digg  Facebook  StumbleUpon  Technorati  Slashdot  Twitter  Sphinn  Mixx  Google  DZone 

No Tags

Send to Kindle

The end of a journey… my book is now out!

Send to Kindle

About bloody time eh?

The Heretics Guide to Best Practices is now available through Amazon, Barnes and Noble and iUniverse.



In Paul and Kailash I have found kindred spirits who understand how messed up most organizations are, and how urgent it is that organizations discover what Buddhists call ‘expedient means’—not more ‘best practices’ or better change management for the enterprise, but transparent methods and theories that are simple to learn and apply, and that foster organizational intelligence as a natural expression of individual intelligence. This book is a bold step forward on that path, and it has the wonderful quality, like a walk at dawn through a beautiful park, of presenting profound insights with humor, precision, and clarity.”

Jeff Conklin, Director, Cognexus Institute


Hugely enjoyable, deeply reflective, and intensely practical. This book is about weaving human artistry and improvisation, with appropriate methods and technologies, in order to pool collective intelligence and wisdom under pressure.”

Simon Buckingham Shum, Knowledge Media Institute, The Open University, UK.


“This is a terrific piece of work: important, insightful, and very entertaining. Culmsee and Awati have produced a refreshing take on the problems that plague organisations, the problems that plague attempts to fix organisations, and what can be done to make things better. If you’re trying to deal with wicked problems in your organisation, then drop everything and read this book.”

Tim Van Gelder, Principal Consultant, Austhink Consulting


“This book has been a brilliantly fun read. Paul and Kailash interweave forty years of management theory using entertaining and engaging personal stories. These guys know their stuff and demonstrate how it can be used via real world examples. As a long time blogger, lecturer and consultant/practitioner I have always been served well by contrarian approaches, and have sought stories and case studies to understand the reasons why my methods have worked. This book has helped me understand why I have been effective in dealing with complex business problems. Moreover, it has encouraged me to delve into the foundations of various management practices and thus further extend my professional skills.”

Craig Brown, Director, Evaluator

 Digg  Facebook  StumbleUpon  Technorati  Slashdot  Twitter  Sphinn  Mixx  Google  DZone 

No Tags

Send to Kindle

SharePoint Fatigue Syndrome

Send to Kindle


I have been wrong about many things – I am happy to admit that. In SharePoint land, one of my bigger naive assumptions was that in early 2007, I figured I’d have maybe a 6 month head start before the rest of the industry began to learn from its initial SharePoint deployment mistakes and start delivering SharePoint “properly.” I thought that I’d better make hay while the sun shines, so to speak, as the market would tighten up as more players entered it.

Yet here we are, heading to the latter half of 2011 – some five years later. As I continue to go into organisations, whether in a SharePoint remedial capacity, or a training/architect capacity, I am still seeing the legacy of really poor SharePoint outcomes. Furthermore I am seeing other, frankly disturbing trends that leave me both concerned and pessimistic. I now have a label for this concern: “SharePoint Fatigue Syndrome.” SharePoint Fatigue Syndrome is hard to define, yet its effects are there for all to see. I suffer from it at times, and I am certain others do too. As an example, recently on the Perth SharePoint User Group on LinkedIn the following topic for discussion was raised:

Hi folks, as you already know we have a worrying skills shortage in SharePoint Development / Architecture in Perth and things are getting worse. It’s getting to the stage where companies have to suspend or worse still abandon their SharePoint projects due to lack of available talent. As the core of the SharePoint community in Perth your suggestions are vital towards finding real solutions to this growing problem. What can be done?

Now I know that this problem is not just limited to Perth. There are consistently reports online that speak of SharePoint people being in demand. So you would think that in a “hot” sector like SharePoint, where the industry is crying out for talent, that the rate of attrition would not outpace the uptake of new talent. After all – money talks, right? If you are a .NET developer with half a brain, there is serious money to be made in SharePoint development land. On top of that, there is the collective realisation in the marketplace that actually talking to people about how SharePoint could make their lives easier, leads to better outcomes. Hence the emergence of this notion of a “SharePoint Architect” with a more varied skill-set that just tech or dev. This role has further been legitimised by entire conferences now just catering to the business this end of the market (I am thinking the Share conferences here).

So, we have all of this newfound collective wisdom spreading through the community via various channels, in terms of the skills and roles required in SharePoint circa 2011 and beyond. We have the fat pay-packets being commanded as a result of demand for these skills. So, with that in mind, why is the attrition rate growing?

As an example, I know personally, several exceptional SharePoint practitioners who are no longer in SharePoint. I’ve also had various quiet conversations with many SharePoint practitioners, right up to SharePoint MCM’s, who vent their various frustrations on how difficult it is to get truly lasting SharePoint solutions in their clients and organisations. I’ve reflected on the various reasons I have come to the conclusion that SharePoint is just plain tiring. As a result, people are burning themselves out.

7 causes of SharePoint Fatigue Syndrome…

Burnout, in case you are not aware, is actually a lack of emotional attachment to what you are doing.  Quoting

The term “burnout” is a relatively new term, first coined in 1974 by Herbert Freudenberger, in his book, “Burnout: The High Cost of High Achievement.” He originally defined ‘burnout’ as “the extinction of motivation or incentive, especially where one’s devotion to a cause or relationship fails to produce the desired results.

SharePoint Fatigue Syndrome is SharePoint manifested burnout. The symptoms include feeling physically and emotionally drained, difficulty maintaining optimism and energy levels, feeling that you have less to give as the burden of work seems overwhelming. Sound familiar?

So why does SharePoint work run this risk? I see 7 major reasons.

1: Cost pressure leading to overwork

First up, the lure of the big dollar is a double edged sword. Not long ago I shared a beer with a SharePoint developer who’s work I respect greatly, yet I can’t afford to hire. This is because the percentage of chargeable hours he would need to work just so I can break even, is very high. This puts me (the employer) under pressure and at risk. As a result, I need to ensure that my newly minted SharePoint employee is productive from day 1 and I need him to work a lot of hours. But here is the irony. When I had my beer with this developer, the conversation started with him lamenting to me that he is already pulling ridiculous hours (60 to 80 per week). He was looking for a job with less hours and yet more money. This is simply not sustainable, both for employer and employee. The more you chase one (work hours vs. money), the more you lose the other it seems.

2: Structures that force an inappropriate problem solving paradigm (and wicked problems of course)

Then there is the broader problem where structure influences behaviour. As a basic example: from the developers’ perspective, they have to put up with sales guys who promise the world, and project managers who then make their life hell and force them to cut corners delivering the impossible. Project managers find out that their beloved work breakdown structure gets chopped and changed when their pain-in-the-ass developers whine that they can’t 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 system or a network upgrade, are much less effective for SharePoint projects. While organisations persist with approaches that consistently fail to deliver good outcomes, and don’t look at the structural issues, the attrition rate will continue. There is only so much that someone can take putting up with these sorts of stresses.

3: Technical complexity

SharePoint’s technical complexity plays a part too. No-one person understands the product in its entirety. The closest person I know is Spence and ages ago on twitter he remarked that even within Microsoft no-one understood it all. As a result, it is simply too easy to make a costly mistake via an untested assumption. (I thought the user profile service was tough – until I did federated claims authentication and multitenancy that is). The utter myriad of features, design options and their even greater number of caveats, mean that one can make a simple design mistake that causes the entire logical edifice of an information architecture to come crashing down. Many have experienced the feeling of having to tell someone that the project time and cost is about to blow out because nobody realised that, say,  Managed Metadata has a bunch of issues that precludes its use in many circumstances. Accordingly, SharePoint architects learn pretty quickly that it is hard to answer a definite “yes” to many questions, because to do so would require a question worded like a contractual clause, to ensure it is framed with appropriate caveats. Even then, consultants would know that lingering feeling in the back of their mind that they might have missed an assumption. This brings me onto…

4: Pace of change

This is BIG…and becoming more acute. Remember the saying ‘The only certainties in life are death and taxes?’ Outside of that, the future is always unpredictable.

In between SharePoint 2003 and SharePoint 2007, the wave of Web 2.0 and social networking broke, forever changing how we collaborate and work with information online (and some of those effects are still to be felt). Microsoft, like any smart organisation, responds to the sentiment of its client base. Microsoft also, like most mature organisations, tends to hedge its bets in terms of marketplace strategy in which it tries to get in on the act with the cool kids, yet tries not to kill the goose that laid the golden egg. Just look at Windows 8’s new interface, tablets, app stores and the cloud.

But that is one facet. Change happens in many forms and at many scales. For example, at a project level, it may mean a key team member leaves the organisation suddenly (SharePoint fatigue no doubt). At a global and organisational level, events like the odd global financial crisis force organisations to change strategic focus very quickly indeed.

I don’t know about you, but when Windows 8 was announced recently I was not excited (in fact I was not excited by SharePoint 2010 either). I thought to myself “So soon? I am still figuring out the current platform!”

As an example of the effect of pace of change, consider all the Government 2.0 initiatives around the world. Collaboration is in-vogue baby, so information should be free and government agencies should engage with the community. While that’s nice and all, there is the world of compliance, security and records management that takes a very different view. So, we end up with market forces that push against each other in combination with vendors hedging strategy of being all things to all people. It’s little wonder that SharePoint projects become very complex very fast.

By the way, it is worthwhile checking out what Bill Brantley in this post sums up the whole government 2.0 issue when he said:

What exactly is the nature of the Gov 2.0 challenge? This question was inspired by Andrew Krzmarzick’s post (What Gov 2.0 Needs Now: Managers, Money and Models) and Christina Morrison’s post (What is Gov 2.0? A survey of Government IT pros) on the recent GovLoop survey about Gov 2.0. As Andrew and Christina argued, the survey demonstrates many differing perspectives on Gov 2.0 in terms of what it actually means and how to implement Gov 2.0. To me, this suggests that Gov 2.0 is the classic wicked problem

5: SharePoint Entropy

One of my clients (who you will meet in my book when it’s published), once said to me “All good ideas eventually deteriorate into hard work.” This is a nice way to lead into the concept of SharePoint entropy, which in some ways is the inevitable outcome from the first four symptoms. The easiest way to understand entropy is to watch this awesome TV series called the “Wonders of The Universe.” In that show, the concept of entropy was discussed and for me made a lot of intrinsic sense. Without getting into the detail, entropy is the notion that over time things move from an organised to less organised state. Rather than have me waste your time trying to explain it in prose, let’s listen to the show in question. (Don’t skip the video – this is important!)

Now what does this has to do with SharePoint fatigue? Gordon Whyte saw what I am getting at with his post on entropy within organisations, especially in relation to change management.

For example, when we build a car we take raw materials such as metal, leather, plastic and glass and arrange them in a highly organised way to make a car. But if we then leave that car for long enough the metal will rust, the glass will become brittle and break and the leather will dry out and turn to dust. If the car is left for a very long time it will eventually disappear altogether. This thought left me wondering about the nature of organisations. If a progression from order to chaos is the natural order of the universe, then is this same pressure present in organisations and, perhaps more importantly, what is the optimum position for an organisation between the extremes of rigid inflexibility (low entropy) and complete chaos (high entropy)? This question is not as crazy as it might at first appear”

Gordon has nailed the issue in his post. Any SharePoint solution that has a low entropic nature requires more energy and effort to maintain that order and control. Complex SharePoint solutions often have complex governance wrapped around them. Governance that is process and structure centric by definition, has low entropy and accordingly, needs higher effort to maintain over time. In fact, if you do not maintain that effort and energy, then any SharePoint solution will usually disintegrate back into the sort of information management chaos that gave rise to SharePoint in the first place!  Rather like the sandcastle in the video.

By the way, I feel that email and file shares are high entropy solutions – all failed SharePoint projects lead back to these tools because they require less structure to maintain (in the short term).

In short, if SharePoint is implemented with low entropy, more energy is needed to maintain it. Remove the energy and very quickly, things become chaotic again. Governance approaches that are not cognisant of this will never stand the test of time. The question then becomes whether people feel that the end in mind is worth the perceived extra effort that is being asked of them.

6. Social complexity

Social complexity is also somewhat of a result of the first five symptoms. Most organisations have a blame culture. If they didn’t, then people wouldn’t spend so much time trying to position themselves for blame avoidance. Social complexity is the result of turf wars, ideological smackdowns and all of the other sort of things that result in the cliché of “the silos” where people are not talking to each-other in organisations. SharePoint exacerbates social complexity for two main reasons.

Firstly, because it is a collaboration tool, it actually requires some collaboration to put it in! This is often easier said than done. Secondly, because it is a pervasive and disruptive technology, it almost always clashes with an established tool, process or practice where proponents aren’t willing to change. In fact, they may not even recognise that there is a problem to solve – especially when SharePoint has been thrust upon them. (In an old post, I wrote about the notion of memeplexes and the ideological immune mechanisms that they create and why it is so hard to get shared understanding across departmental boundaries in organisations. Memetic smackdowns are the result).

The long and the short of social complexity is that there is only so much stress people can take. We all seem to have a pathological need to seek order and safety, rather then remain in a stressful situation. Once social complexity bites, the merry-go-round of staff attrition really starts to bite…

7. Meaning over motivation…

Now if I haven’t completely depressed you, let me offer you a perverse glimmer of light. For those of us who understand the preceding 6 fatigue symptoms, recognise them for what they are and take steps to mitigating them, there is one other symptom that contributes to SharePoint Fatigue Syndrome. This is the trickiest of all – and I am a somewhat willing victim of it.

I have spent a lot of time learning techniques to help address the symptoms I outlined here and as it turns out, these skills are universally applicable, whether in SharePoint, IT or beyond IT. For years now, I have metaphorically had one foot out of the SharePoint world door and the other foot into the world of construction, health and management sectors. Hell…I have written what I think is the first business book ever by a SharePoint person that is a non SharePoint and non IT. I also have clients with SharePoint deployments who do not know me as a SharePoint person at all, but only as a sensemaker (and for that I am grateful.)

The point is this: While the investment in these skills enables me to counter the effects of SharePoint fatigue syndrome, it is also inexorably pulling me away from SharePoint work. It seems that once you crack this nut a little, your skills are in demand across the entire problem solving spectrum. Right now this is my coping mechanism for SharePoint Fatigue Syndrome – I get to step away from SharePoint for periods and work on something else. Eventually…inevitably…I will also be one of those attrition statistics.


The problem is that SharePoint Fatigue Syndrome is a negatively reinforcing cycle. As evidenced by the SharePoint attrition rate, money isn’t that great a motivator. If it was, then the void of skilled resources would have been filled by now. Paying more money might give you a short term gain, but in the long term is not going to address my seven causes of SharePoint Fatigue Syndrome.

I will leave this admittedly negative sounding post with the key to breaking this cycle. While you can attend my SharePoint Governance and Information Architecture class or Issue Mapping Class to learn many ways, the video below says it all. I encourage you to watch and reflect on it, because it’s the same key point to understanding how to do effective user engagement.


Thanks for reading


Paul Culmsee

 Digg  Facebook  StumbleUpon  Technorati  Slashdot  Twitter  Sphinn  Mixx  Google  DZone 

No Tags

Send to Kindle

The facets of collaboration Part 1–Meet robot barbie

Send to Kindle


Hi all

I have a friend, lets call her Jane (not her real name), who was a huge web2.0 fan. Seriously, if it was a wiki, blog, tweet or anything remotely sounding like RSS, Jane would wax lyrical about how it was the answer to all that was wrong with the silos of the old world and if only people would get with this new paradigm and embrace the social revolution, collaboration within her organisation would markedly improve. After all, look at the popularity of sites like facebook, wikipedia and twitter. Jane also had a very strong vision for what this new world would look like and had spent a lot of time and money investing in customising SharePoint to meet this vision.

Much to Jane’s dismay, her project failed miserably. Her organisation ultimately wanted something much more boring – a solution to help them manage their files better. All of this “new-age gen Y social crap “ was of little interest to the masses.

Janes story is actually a very common pattern with SharePoint projects. As it happened, Jane had committed probably the most cardinal sin of information architecture. She had projected her ideals onto an organisation that did not necessarily subscribe to her view. Therefore SharePoint represented her vision and little else. Few others shared it and to this day I think she blames the culture organisation she worked for. I say that she did not do enough to develop a shared understanding of the problem, and shared envisioning of the solution.

Now most of us know that SharePoint can be a platform for going gung-ho social if you wish, given that it has features like wikis, blogs, folksonomy and RSS. But it can can also be a platform for structured business process via features like workflow, BCS, information management policies, content approvals and the like.

So that raises a really important question. Why is it that a particular collaboration feature (such as a wiki) might be total nirvana for one situation and can be a project killing fatal flaw in another? Since SharePoint has a ton of collaborative tools in its toolkit that can be rolled up in different ways, when do certain features work well together and when do they completely suck balls together? Why do some people have such wildly differing views on the nature of collaboration and what potential solutions should look like? Why do some people look at the SharePoint feature-set and say “meh”, while others are totally charmed by it?

This was a question worth pondering and I did look into this in some detail while I was creating my SharePoint 2010 Information Architecture course. In this short series of posts, I am going to introduce you to a way of looking at the wide spectrum of activities that all fall under the guise of this term called collaboration. This mental model seems to help paint a more realistic picture of the collaborative world than the simplistic views that Jane and her ilk use. It goes some way to many of the questions that I raised above. Furthermore, the model has been very well received at my courses. Maybe there is something to this?

Introducing “robot barbie” – the yardstick for SharePoint information architecture

Say hello to Robot Barbie, my all-time favourite SharePoint metaphor. I use this picture in all of my classes and talks, such is its persuasive power.


I first saw this picture via a talk that Joel Oleson gave. The story behind it was that Joel came across this very real toy in a market somewhere in Asia. When Joel asked the storekeeper what the idea was behind the toy, the reply he got was along the lines of:

“Well, boys like robots and girls like Barbie. Therefore, if we put Barbie’s head on a robot, then logically both boys and girls will like it.”


Now I don’t know about you, but I can’t see that boys and girls would suddenly drop their respective robots and Barbies and start playing with this ugly hybrid. In fact, when you look at the result, it is this bizarre, somewhat disturbing combination of features that brilliantly demonstrates the folly of taking two things that work really well alone and expecting that by combining them, things will work even better. Instead, we have a combination that is much less than the sum of its parts and unlikely to satisfy anybody.

Robot Barbie is a very powerful visual metaphor for SharePoint information architecture because SharePoint is full of Barbies and full of robots. In fact the global SharePoint information architecture mantra should be “avoid robot barbie”. To that end, when I show this image to clients or conference attendees, I ask them the question, “So is your SharePoint implementation a robot-barbie solution?”.

Many people will admit to varying degrees of robot-barbie. How then to avoid it?

Research into collaboration itself

The only SharePoint person I have met who goes to a university library to research more than me is Erica Toelle. In this section I am attempting to make her proud – hehe 🙂

Since these questions around collaboration came to me while I was developing an Information Architecture course, I became curious as to whether academics, authors or bloggers had ever actually attempted to deconstruct collaboration itself into its core elements (in effect, performing an information architecture exercise on collaboration itself). Surely understanding the some of these elements would help us gain some hints or insights into how collaboration works and in turn, help us avoid Robot Barbie?

So I hit the journals and did some digging. As it happened, some academic research had been undertaken over a long period of time, trying to codify this lofty ideal called collaboration. As expected, authors looked at the issue from various angles. Some looked at it through the lens of the type of conversation taking place, some via the nature of the problem solved, some through “business activities”, some via the characteristics of group doing the collaborating and others examining the underlying purpose that drove the collaboration in the first place.

Some of the more interesting writing that I examined in developing my own model included:

I read all of these papers in detail and then converted the arguments made by each into IBIS and created a single (admittedly very large) issue map to try and draw out any patterns from them. I would group all of the various concepts in the map together in different ways to try and elicit some sort of insight. This proved to be quite a frustrating process because of the various different ways each writer tackled the subject matter. The map was huge and I was at first, unable to find a pattern that worked for me. All of them seemed to have some interesting elements, but they all seemed incomplete or over-thought in some way.

In frustration, I gave up and slept on it. During the night my subconscious must have kept working to unscramble the map because the next morning, I had my model within a few minutes. I looked at the map again and saw a pattern immediately. It was in essence, a combination of some work by Chuck Hollis and interestingly, Microsoft Research (The last two of the above references).

Meredith Ringel Morris and Jaime Teevan of Microsoft research wrote a brilliant paper called “Understanding Groups’ Properties as a Means of Improving Collaborative Search Systems”. For the record, anyone that is looking to leverage user profile data via mysites should read it. In this paper, Morris and Teevan divide collaborative groups into trait or task, based around the longevity of a group. They also use group identification in the form of group membership being implicit or explicit. For my own purposes, the implicit vs. explicit membership of a group was not overly relevant so I discarded it. But I found the notion of trait and task based groups fascinating.

Morris and Teevan characterised task based groups as short term and comprised of people with a shared goal and working together to achieve that goal. (They are describing every project team right there). Trait based groups on the other hand were comprised of users who were related through shared traits of long term interests. Here was the quote that really made me sit up and take notice however. They also suggested that trait based “group members may not be consciously collaborating on the same task, but may be highly likely to repeat or augment tasks already accomplished by other group members” (Love it – they are describing every discussion forum right there).

So I had my first dimension of collaboration. Task vs trait.


In 2007 Chuck Hollis of EMC wrote a really insightful blog post entitled “Beyond Document Collaboration”, where recognised that via the advent of social media, organisational collaboration was changing and that “different collaboration models are emerging, each one with entirely different value propositions”. Hollis identified three such models and labelled them transactional collaboration, document collaboration and social collaboration.

Hollis described transactional collaboration as “workflow, or business process management, or something else” and was characterised by “humans are largely automatons; repetitively processing the output of one function for input by another function.  Not much spontaneous creativity interaction here, nor is it usually encouraged!”. Hollis then spoke of document collaboration and explicitly mentioned both Documentum and SharePoint. He finished with social collaboration, which he described as “It’s not predefined interaction.  It’s not a structured workflow.  It’s something entirely different than the other two collaboration models”.

After reading that post, I thought Hollis was definitely on to something but I felt his descriptions didn’t quite encompass what I was looking for. Like the Ringel/Teevan paper, I felt that elements of Hollis’s breakdown didn’t quite fit for me. After I had slept on it, it dawned on me that document collaboration was the odd one out. I liked his distinction between transactional and social collaboration, of structure and predictability versus a non predefined interaction because the social dimension to me was describing knowledge work. But document collaboration did not work for me at all. A document is simply a medium, as is a wiki or a forum. Structured, process driven collaboration can still use documents, and so can relatively unstructured social collaboration. They just use them in different ways. The same can also be said for whether the collaboration is task based (ie outcome driven) or trait based (interest driven).

So I discarded document based collaboration and in doing so had my second dimension.


Making a model

Out of all of the material that I researched, I found that these four dimensions or facets of collaboration (task, trait, transactional, social) helped me explain most collaborative scenarios and understand why Robot Barbie solutions occur. Of course, the great thing about distilling it down to four dimensions is that I then I got to do what academics live for. Make a 2*2 matrix!

Academics simply love doing this, because it helps them deal with over-analysing everything that moves and justify all that R&D that they do! :-). In all seriousness though, people love creating 2*2 or 3*3 matrixes to explain concepts for the simple reason that they make good mental models to help us understand reality. After all, one of the key purposes of information architecture itself is to help users create mental models of a site (“Don’t Make Me Think ”).

So here is my complete model. In part 2 I will explain how I use this model and the insights that it gives in preventing robot-barbie outcomes.




Thanks for reading

Paul Culmsee

 Digg  Facebook  StumbleUpon  Technorati  Slashdot  Twitter  Sphinn  Mixx  Google  DZone 

No Tags

Send to Kindle