Confessions of a (post) SharePoint architect: The dangers of dial tone governance…

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

Hi all and welcome to the next exciting instalment of my confessions from my work as a SharePoint architect and beyond. This is the eighth post and my last for 2012, so I will get straight into it.

To recap, along the way we have examined 5 f-laws and learned that:

Now, as a preamble to today’s mini-rant, I need to ‘fess up. I know this might come as a shock, but there was once a time when I was not the sweet, kind hearted, gentle soul who pens these articles. In my younger days, I used to judge my self-worth on my level of technical knowledge. As a result of this, I knew my stuff, but was completely oblivious to how much of a pain in the ass I was to everyone but geeks who judged themselves similarly. Met anyone like that in IT? Smile

This brings me onto my next SharePoint governance f-law – one that highlights a common blind spot that many IT people have in their approach to SharePoint governance.

F-Law 6: Geeks are far less important than they think they are

All disciplines and organisational departments have a particular slant on reality that is based on them at the centre of that reality. If this was not true, then departments would not spend so much time bitching about other departments and I would have no Dialogue Mapping work. The IT department is no better or worse in this regard than any other department, except that the effects of their particular slant of reality can be more pronounced and far reaching on everyone else. Why? Because the IT slant of reality sometimes looks like a version of Neo from the Matrix. Many, if not most people in IT, have a little Neo inside of them.


We all know Neo – an uber hero. He is wise, blessed with super powers, can manipulate your very reality and is a master of all domains of knowledge. Neo is also your last hope because if he goes down, we all go down. Therefore, everything Neo does – no matter how over the top or what the consequences are – is necessary to save the world from evil.

All of the little Neos in IT have a few things in common with bullet stopping big Neo above. Firstly, little Neo has also been entrusted with ensuring that the environment is safe from the forces of evil. Secondly, Little Neo can manipulate the reality that everybody else experiences. And finally, little Neo is often the last hope when things go bad. But that is where the similarities end because big Neo has two massive advantages over little Neo. First, big Neo was a master of a lot of domains of knowledge because he had the convenience of being able to learn any new subject by downloading it into his brain. Little Neo does not have this convenience, yet many little Neos still think they are all-knowing and wise. Secondly, big Neo was never mentally scarred from a really bad tequila bender…

Bad tequila bender? What the…

Never again…

Years ago when I was young and dumb, I was at a party drinking some tequila using the lemon and salt method. My brother-in-law thought it would be hilarious to switch my tequila shots with vodka double shots. Unfortunately for me, I didn’t notice because the lemon and salt masked the taste. I downed a heap of vodkas and the net result for me was not pretty at all. Although I wasn’t quite as unfortunate as the guy in the picture below I wasn’t that far off. As a result, to this day I cannot bring myself to drink tequila or vodka and the smell of it makes me feel sick with painful memories best left supressed.


I’m sure many readers can relate to a story like this. Most people have had a similar experience from an alcohol bender, eating a dodgy oyster or accidentally drinking tap water in a place like Bali. So take a moment to reflect on your absolute worst experience until you feel clammy and queasy. Feeling nauseous? Well guess what – there is something even worse…

Anyone who has ever worked in a system administrator role or any sort of infrastructure support will know the feeling of utter dread when the after hours pager goes off, alerting you some sort of problem with the IT infrastructure on which the business depends. Like many, I have lived through disaster recovery scenarios and let me tell you – they are not fun. Everyone turns to little Neo to save the day. It is high pressure and stressful trying to get things back on track, with your boss breathing down your neck, knowing that the entire company is severely degraded until you to get things back online.

Now while that is bad enough, the absolute nightmare scenario for every little Neo in IT is having to pick up the pieces of something not of their doing in the first place. In other words, somehow a non-production system morphed into production and nobody bothered to tell Little Neo. In this situation, not only is there the pressure to get things back as quickly as possible, but Little Neo has no background knowledge of the system being recovered, has no documentation on what to do, never backed it up properly and yet the business expects it back pronto.

So what do you expect will happen in the aftermath of a situation like the one I described above? Like my aversion to tequila, Little Neo will develop a pathological desire to avoid reliving that sort of pain and stress. It will be an all-consuming focus, overriding or trivialising other considerations. Governance for little Neo is all about avoiding risk and just like Big Neo, any actions – no matter how over the top or what the consequences are – will be deemed as necessary to ensure that risk is mitigated. Consequently, a common characteristic of lots of little Neos is the classic conservative IT department who defaults to “No” to pretty much any question that involves introducing something new. Accordingly, governance material will abound with service delivery aspects such as lovingly documented physical and logical architecture, performance testing regimes, defining universal site templates, defining security permissions/policies, allowed columns, content types and branding/styling standards.

Now all of this is nice and needs to be done. But there is a teeny problem. This quest to reduce risk has the opposite effect. It actually increases it because little Neo’s notion of governance is just one piece of the puzzle. It is the “dial tone” of SharePoint governance.

The thing about dial tone…

What is the first thing you hear when you pick up the phone to make a call? The answer of course is dial tone.

Years ago, Ruven Gotz asked me if I had ever picked up the phone, heard dial tone and thought “Ah, dial tone… Those engineers down at the phone company are doing a great job. I ought to bake them a  cake to thank them.” Of course, my answer was “No” and if anyone ever answered “Yes” then I suspect they have issues.

This highlights an oft-overlooked issue that afflicts all Neos. Being a hero is a thankless job. The reality is that the vast majority of the world could not care less that there is dial tone because it is expected to be there – a minimum condition of satisfaction that underpins everything else. In fact, the only time they notice dial tone is when it’s not there.

Yet, when you look at the vast majority of SharePoint governance material online, it could easily be described as “dial tone governance.” It places the majority of focus on the dial tone (service delivery) aspects of SharePoint and as a result, de-emphasises much more important factors of governance. Little Neo, unfortunately, has a governance bias that is skewed towards dial tone.

Keen eyed readers might be thinking that dial tone governance is more along the lines of what quality assurance is trying to do. I agree. Remember in part 2 of this series, I explained that the word ‘govern’ means to steer. We aim to steer the energy and resources available for the greatest benefit to all. Assurance, according to the ISO9000 family of standards for quality management, provides confidence in a product’s suitability for its intended purpose. It is a set of activities intended to ensure that requirements are satisfied in a systematic, reliable fashion. Dial tone governance is all about assurance, but the key word for me in the previous sentence is “intended purpose.”

Dial tone governance is silent on “intended purpose” which provides opportunities for platitudes to fetser and governance becoming a self fulfilling prophecy.

and finally for 2012…

So, all of this leads to a really important question. If most people do not care about dial tone governance, then what do they care about?

As it happens, I’m in a reasonable position to be able to answer that question as I’ve had around 200 people around the world do it for me. This is because in my SharePoint Governance and Information Architecture Class, the first question I ask participants is “What is the hardest thing about SharePoint delivery?”

The question makes a lot of sense when you consider that the hardest bits of SharePoint usually translate to the highest risk areas for SharePoint. Accordingly, governance efforts should be focused in those areas. So in the next post in this series, I will take you through all the answers I have received to this question. This is made easier because I dialogue mapped the discussions, so I have built up a nice corpus of knowledge that we can go through and unpack the key issues. What is interesting about the answers is that no matter where I go, or whatever the version of SharePoint, the answers I get have remained extremely consistent over the years I have run the class.

Thanks for reading…


Paul Culmsee

p.s I am on vacation for all of January 2013 so you will not be getting the next post till early Feb

 Digg  Facebook  StumbleUpon  Technorati  Slashdot  Twitter  Sphinn  Mixx  Google  DZone 

No Tags

Send to Kindle

Confessions of a (post) SharePoint Architect: A pink box called chaos…

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

Hi all and welcome back to my ever growing series which attempts to codify a lot of learning over a long period of time into something that I hope is readable, rigorous and is useful to anyone tasked with successful SharePoint project delivery. This is the 7th post in a what is turning out to be a large series. It is large for a good reason: SharePoint is complex and the problems it attempts to solve (collaboration) are complex as well. If this is your first article, I super-strongly suggest you take it from the beginning as these articles build on each-other.

My motivation for getting this stuff out there is to tap into the shift I now sense in how organisations approach the SharePoint platform. Through a combination of organisations living through SharePoint project failure, practitioners experiencing SharePoint fatigue syndrome, as well as the strength and congruence of the messages of many wise people in the SharePoint community, organisations now realise that SharePoint is a “different” kind of project.  This realisation represents the first stage of any form of learning where people have moved from unconscious incompetence to conscious incompetence.  These terms sound rather confronting but are common in training-speak…

  • Unconscious incompetence refers to people who do not realise they lack certain skills and therefore don’t realise they need training to address the gap. That explains pretty much every IT centric SharePoint deployment based on the “built it and they will come” delivery model (and we all know how much fun those projects are).
  • Conscious incompetence means that people now see the gap between their knowledge and know they need help. Much of my company’s work is in this area – as is our close friends at Dynamic Owl and 21apps. Aside from our own clients, all of us are often sought out by other Microsoft partners who have learnt the hard way that the classic model of sales guy, project manager, business analyst and developer doesn’t always crack the SharePoint nut.

So newfound realisation among clients and consultants is there and that’s all well and good. Now the issue is to get past the cover story and take it to the next level. We have to go beyond the oft-used hippie clichés like “It’s all about the business, man” and make the art of SharePoint delivery real, pragmatic, rigorous and tangible. This series aims to be my attempt to do just that, complimenting leaders like Andrew Woodward, Ruven Gotz, Michal Pisarek and Sue Hanley. To that end, as I continue writing the series I hope that you:

  • laugh at the various truths behind the various SharePoint governance f-laws;
  • smile knowingly at the folly of some of the elaborate project and governance rituals you have to do now;
  • have your own biases challenged as you either cringe in embarrassment or think “he has gone too far with *that* comment”; and
  • have enough solid ammo to get through to influence other key stakeholders in your organisation

Allrighty then! Let’s get down to business. Our f-law for today’s article comes from Woody Allen. I have never actually watched one of his movies, but I have to give him credit for this pearl of wisdom…

F-Law 5: Confidence is the feeling you have until you understand the problem

Most projects start with a honeymoon phase. A newly formed team gets to deliver some new technology that is high profile and bolster their CV’s while “taking the business to the next level” (platitude black belts take note!) Morale is high and the team feel the sort of excitement one feels when going on a first date. Like a bad first date however, it doesn’t take long for the slow but relentless imposition of reality to take hold. Accordingly, as understanding of the problem grows, uncertainty grows commensurately. This in turn tests the initial project assumptions which an optimistic budget was likely pinned to. Most people can’t handle this sort of uncertainty because it confers risk of blame – something we all seek to avoid if we can. Thus on a complex project where the problem has elements of wickedness, blame avoidance results in things becoming quite dysfunctional and often project teams lose confidence that they can solve the problem.

There is an underlying phenomenon at work here that seems to be part of the human condition. Check out these two diagrams below as both of them show the same pattern. The left image is by Gartner and is their famous hype cycle that they pin technology fads to. The other won a Nobel prize for the originators and refers to a phenomenon called the Dunning-Kruger effect.

Gartner_Hype_Cycle_svg    Snapshot

The diagrams should be self explanatory as both are a representation of increasing ones understanding of a problem over time. Both diagrams powerfully illustrate that as understanding grows, one never regains the same level of confidence that one had at the start! Take a look at the red line which reflects level of understanding of a problem. In both cases, the red line never reaches the same peak as it did at the very start when confidence was high and understanding was low. In other words, as your understanding grows and you become more informed about a problem, you will never be as certain as you would like to be.

Now in my mind, anyone who tries to argue against truth of the above patterns have fallen victim to the pattern. Furthermore, if you are dealing with someone who fits that level of optimistic naivety like a command-and-control project manager or CIO, just tell them that this has Nobel prize winning backing. For those CIO types who get all of their gospel from Gartner, use the hype cycle instead. After all, what would those Nobel dudes know eh? 🙂

So here is a tip. Next time you are kicking off a SharePoint project and need to assess risk, try this: First up, explain platitudes as described in the last two posts. Then draw one of the above diagrams on a whiteboard and ask your stakeholders to place an X on the above diagrams where they see the project team, themselves and where they see others! I guarantee much fun and frivolity will ensue…

Divergence and Convergence

Now if you work for an organisation where the idea of ranking ones naivety is a bit confronting, let me offer you something gentler. This alternate way of looking uncertainty over time is similarly powerful to the images above. I first saw this diagram used by Jeff Conklin, who got it from a book by Sam Kaner called the Facilitator’s Guide to Participatory Decision-Making. My diagram below was modified from Kaner for my own purposes.


Like the Gartner and Dunning-Kruger diagrams above, the X axis represents time, with a problem at one end and the solution on the other. The Y-axis represents the level of uncertainty and it illustrates that project teams typically go through a cycle of divergent thinking, followed by a period of convergent thinking as the team becomes more aligned and the problem is better understood. What is interesting to note is that the point where divergence ends and convergence starts is never clear. No-one ever stops and pronounces “Okay guys, I think we have sufficiently diverged. Let’s converge now.”

To converge, one has to cross over the ‘hump’ of divergence. Imagine climbing a mountain and there are thick clouds that obscure the peak. For all you know, the peak might be a couple hundred feet further, but equally so, you might only be halfway up. For this reason I draw a box in the middle rather than connect the arrows. it is important to note that when I draw the box in the middle, I make a point of asking people to tell me the sort of words they would use to convey what they are feeling during this time. Without fail, I always get negative responses like “confusion,” “irritability,” “stress” and “uncertainty.”

Now consider this: Some projects tend to diverge sharply and convergence seems almost impossible. No attempts to reign things in by asserting control seem to work. In fact, they usually make things worse. Accordingly, SharePoint projects commonly look like the figure below. They are highly divergent with little convergence as a result of the varied implicit assumptions that stakeholders have about SharePoint that have not been aired and reconciled. The power of those pesky platitudes, eh?


When I show this version of the diagram to people, I always ask a simple question:

  • If you do not have governance for SharePoint, what do you have?

The answer I get is always “Chaos,” which I write in the box as you can see above. My next question to the group is this:

  • “So by definition, to understand SharePoint governance, we all have to metaphorically open this box we have labelled “Chaos” to understand the forces that create the divergence?

So far, nobody has disagreed with that logic. So I then I hit people with the punch line…

  • “So how can you tell me that your governance approach is addressing the forces of divergence if you don’t know what’s in the box?“

That is usually the great silence moment… Despite the logic of my argument, most organisations never open the damn box and then approach SharePoint project delivery in a manner that is very likely to exacerbate the problem, rather than address it.

False convergence…

Check out the figure below. It is a variation of the divergence/convergence figure and represents a common approach to rein in SharePoint going haywire. If you look closely, you can see that an attempt has been made to force convergence. This manifests in different ways, but is most often the scenario when a sponsor or key stakeholder starts to make key decisions on behalf of others. In the short term, this approach tends to feel good because there is a sense of momentum and something is “being done” to get things under control. Project managers stop palpitating for a time because their Gantt charts start to see some progress…


After explaining this diagram, I then ask my audience. “So has this dealt with divergence?”. To this day, not a single person I have ever asked has said yes. In fact, everyone implicitly seems to realise that this is a false convergence and the underlying divergent forces have not truly been addressed at all. There is usually a short term feeling that things are getting back on track, but it doesn’t last long because it is actually little better than an illusion and things starts to get fishy – both on the project and in my diagram as shown below…


So eventually we will be smacked by the chaos baseball bat whether we like it or not. Despite this, many organisations will persist with the forced convergence approach many times (with a different set of consultants each time) and of course continue to get crappy results. Eventually though, the attrition of this approach will exceed the commitment of stakeholders and something gives. It is at this point where some organisations react by doing another dumbass thing…

Overly constraining divergence…

Once there is a realisation that an elite coterie (like the IT department or a single champion in the business) cannot solve the information management problems for the entire organisation via false convergence approaches, the next approach seems to artificially constrain the divergence via controlling the terms of reference – aka lock the crap out of the scope. This is seductively tempting since scope creep is the quintessential symptom of stakeholders who are still in divergent thinking.

While I have no problem with determining an appropriate scope, as we all operate within time, people and budgetary limits. But it has to be done for the right reasons and constraining divergence is not a good reason. Why? Because it means that stakeholders have very little shared understanding at the point scope is decided. This is a problem because ideally, divergent thinking should be reconciled to be able to decide on scope. From a diagrammatic point of view, this is like putting clamps around the level of allowable uncertainty. The classic example of this approach is when an organisation opts for the installation and deployment of SharePoint itself as phase 1 of the project. Ever done that before? Smile


Like the previous example, I ask my audience whether this approach deals with divergence. Also like the first example, the answer is a universal no. The underlying divergent forces have not truly been addressed at all and things are still fishy – although on the diagram below it is a difference species of fish! 🙂 In fact what you are doing here is penalising people for their learning – something I warned against doing in part three.


Key takeaways

I hope that you find these diagrams useful when discussing SharePoint delivery with your own stakeholders. By explaining SharePoint delivery in terms of divergence, convergence and a pink box labelled “chaos” we are able to provide a frame to show why artificially constraining divergence often has the opposite effect of what is intended. It is also worth pointing out that both of the above approaches are not particularly collaborative either – which tends to go against what one is trying to do with SharePoint in the first place.

Many SharePoint projects proceed on the assumption that the problem is well understood – that divergence has peaked and we are heading down the slope of convergence. If this is indeed the case, then the SharePoint project should go reasonably well since all of the tools for managing and delivering projects are convergence tools and do a good job in assisting this process. When this is not the case however, those same approaches have a bad habit of getting in the way by precluding the sort of learning and exploration needed for stakeholders to align around a problem. Returning to my mountain climbing metaphor I used earlier, these tools are like gravity assist to help you get down the mountain, but they weight a lot when you are trudging up a steep mountain and when clouds are obscuring the peak.

My takeaway for f-law 5 is not to jump straight to convergence. It might give you an initial sense of certainty and momentum, but only for a short time. I have said it many times and I will say it again. While there is a lack of shared understanding among participants of a problem, you will never get the shared commitment you need to see a solution through. Shared commitment is critical because without it, projects lose their energy and momentum to be seen to conclusion. Persistent divergence is a sign of a lack of shared understanding so the trick of course, is to harness divergence and turn it into something positive. Create the conditions that allows for some uncertainty, reduce the blame culture and tolerate mistakes. Invest in tools and methods that allow collective sensemaking and give people safety and structure to raise and reconcile their concerns.

Achieving shared understanding of the problem is for me the essence of SharePoint governance. In the doctors vs. midwives post in this series I explained how the goal of an architect is to create the right conditions for SharePoint success. The conditions to manage and harness divergence is a critical skill.

If you can achieve this end you should be bloody proud of yourself – as you have done 80% of the work of SharePoint delivery already.

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