So first up, just because I get asked this all the time, the book is definitely *not* “A humble tribute to the leave form – The Book”! In fact, it’s not about SharePoint per se, but rather the deeper dark arts of team collaboration in the face of really complex or novel problems.

It was late 2006 when my own career journey took an interesting trajectory, as I started getting into sensemaking and acquiring the skills necessary to help groups deal with really complex, wicked problems. My original intent was to reduce the chances of SharePoint project failure but in learning these skills, now find myself performing facilitation, goal alignment and sensemaking in areas miles away from IT. In the process I have been involved with projects of considerable complexity and uniqueness that make IT look pretty easy by comparison. The other fringe benefit is being able to sit in a room and listen to the wisdom of some top experts in their chosen disciplines as they work together.

Through this work and the professional and personal learning that came with it, I now have some really good case studies that use unique (and I mean, unique) approaches to tackling complex problems. I have a keen desire to showcase these and explain why our approaches worked.

My leanings towards sensemaking and strategic issues would be apparent to regular readers of CleverWorkarounds. It is therefore no secret that this blog is not really much of a technical SharePoint blog these days. The articles on branding, ROI, and capacity planning were written in 2007, just before the mega explosion of interest in SharePoint. This time around, there are legions of excellent bloggers who are doing a tremendous job on giving readers a leg-up onto this new beast known as SharePoint 2010.

So back to the book. Our tentative title is “Beyond Best Practices” and it’s an ambitious project, co-authored with Kailash Awati – the man behind the brilliant eight to late blog. I had been a fan of Kailash’s work for a long time now, and was always impressed at the depth of research and effort that he put into his writing. Kailash is a scarily smart guy with two PHD’s under his belt and to this day, I do not think I have ever mentioned a paper or author to him that he hasn’t read already. In fact, usually he has read it, checked out the citations and tells me to go and read three more books!

Kailash writes with the sort of rigour that I aspire to and will never achieve, thus when the opportunity of working with him on a book came up, I knew that I absolutely had to do it and that it would be a significant undertaking indeed.

To the left is a mock-up picture to try and convey where we are going with this book. See the guy on the right? Is he scratching his head in confusion, saluting or both? (note, this is our mockup and the real thing may look nothing like this)

This book dives into the seedy underbelly of organisational problem solving, and does so in a way that no other book has thus far attempted. We examine why the very notion of “best practices” often makes no sense and have such a high propensity to go wrong. We challenge some mainstream ideas by shining light on some obscure, but highly topical and interesting research that some may consider radical or heretical. To counter the somewhat dry nature of some of this research (the topics are really interesting but the style in which academics write can put insomniacs to sleep), we give it a bit of the cleverworkarounds style treatment and are writing in a conversational style that loses none of the rigour, but won’t have you nodding off on page 2. If you liked my posts where I use odd metaphors like boy bands to explain SharePoint site collections, the Simpsons to explain InfoPath or death metal to explain records versus collaborative document management, then you should enjoy our journey through the world of cognitive science, memetics, scientific management and Willy Wonka (yup – Willy Wonka!).

Rather than just bleat about what the problems with best-practices are, we will also tell you what you can do to address these issues. We back up this advice by presenting a series of practical case studies, each of which illustrates the techniques used to address the inadequacies of best practices in dealing with wicked problems. In the end, we hope to arm our readers with a bunch of tools and approaches that actually work when dealing with complex issues. Some of these case studies are world unique and I am very proud of them.

Now at this point in the writing, this is not just an idea with an outline and a catchy title. We have been at this for about six months, and the results thus far (some 60-70,000 words) have been very, very exciting. Initially, we really had no idea whether the combination of our writing styles would work – whether we could take the degree of depth and skill of Kailash with my low-brow humour and my quest for cheap laughs (I am just as likely to use a fart joke if it helps me get a key point across)…

… But signs so far are good so stay tuned

Thanks for reading

Paul Culmsee

www.sevensigma.com.au

Technorati Tags: Book, Beyond Best Practices

There is this wonderful way to look at the world, through a lens of something called “Complex adaptive systems”. Unfortunately with a name like that, it is automatically doomed to be only spoken of and understood by, a small subset of those sort of dishevelled looking nerdy guys who others take the piss out of when they are not around.

The notion of complex adaptive systems explains many things, including why salesman can unintentionally really be damaging to an organisation. I thought that I needed to write about this, and given that I am going to talk about sales guys, I had to write in a manner commiserate with their level of understanding of how the world works. Since the chances of a sales guy reading my blog is probably low, I should be safe

So here we go.

Here is a sales guy. Although us geeks think they are assholes, for this metaphor we have to change our context of what an asshole actually is. I think of him more of a guy who gathers food and brings it to you.

Here is the world for a sales guy. He finds work, and feeds that work into the mouth of the organisation. For performing such a feat, he gets to nibble off a small morsel of the meal to keep for himself. If he feeds the organisation enough and makes it grow, he will get enough morsels to grow rather nicely himself. This is a pretty sweet deal if you are good at finding food, because your reward is a percentage of what you push into the organisations mouth. Therefore it is in the sales guys interest to find as much food as he can for the organisational “body”. In fact his performance is directly attributed to doing exactly that in the form of quotas or sales targets

At the other end of the chain, the implementers have to digest what has been fed them from mouth and produce output that makes clients happy. Therefore it is the people in the organisation that actually implement a project who are actually the assholes, not the sales guys. As a result, I can say with some confidence that most people reading this post, like myself, are all assholes.

As this cycle perpetuates over time, the body in between these two ends grows. To continue to feed this body and keep it growing, we need to seek out more food. To do this we try and incentivise our sales people to supply more food by offering them larger morsels if they make more ambitious targets.

Never forget the assholes

Now we all know that we have to eat a balanced diet with healthy foods. But some people find it a pain to do all of that preparation and effort and instead go and grab some Chinese takeout instead. To a sales guy who is being rewarded for the amount of food being delivered to the organisation, fast food is great! Remember that the sales guy only takes just enough of the food for no lasting effects and is the furthest away from the assholes to feel the negative effects on the organisational as a whole.

Now our sales guy starts to look like the image below.

Therefore, this process of incentivising sales guys by the amount of food that they pass into the mouth is not without its risks and often can damage the long term health of the organisational body. Fast food can be tolerated now and again of course. For example, we all get the occasional hankering for Kentucky Fried Chicken every 6 months or so, and delude ourselves that this time, unlike all of the other times, it will actually not be oily enough to power a small town and leave you with that queasy feeling that you get when your heart labours against your cholesterol.

This can be a self perpetuating cycle. For example, the sales guy feeds the organisation a blisteringly hot spicy lamb vindaloo. Naturally is a very unpleasant experience for the assholes and as a result, what is delivered to the customer is (literally) crap and costs much more than anticipated. This cost bleed puts pressure on the sales guys to feed the body to make up for the wasted time, effort and cost. But the sales guy is so far away from the assholes, it does not occur to him that it was the spicy lamb vindaloo was the wrong meal. Nor too, does he receive any feedback to let him know that the burning sensation still lingers.

So what does he do? He feeds an even spicier lamb vindaloo to the mouth. Why? because he now has learned how to find spicy lamb vindaloos and is reaping the rewards of many tasty morsels – a perfectly reasonable practice given that he is now put under pressure to deliver more food.

Despite good intentions…

This cyclical phenomenon is called the “ring of fire” and afflicts many organisations who just can’t seem to deliver projects on time and budget. The customers of these organisations, fed up with getting nothing but crap, start to look elsewhere, thereby increasing pressure and starting the cycle again. Management get all flustered and usually blame the assholes.

The essence of the notion of the complex adaptive system is that the assholes and sales guys need each-other. Attempting to optimise the sales guys performance in isolation, ultimately has a negative impact on the assholes, which in turn has a negative impact on the organization as a whole.  The organisation is a system that comprises of many parts that interact in different ways. The system is perfectly capable of self organising and self optimising. For example, if the sales guy feeds the organisation sushi and next time it is fed a burrito, the assholes have a certain amount of tolerance to deal with that. But when you optimise one end (reward for food) without considering the assholes at the other end, you actually reduce that tolerance to deal with change!

The lesson that should be learned here is that the command and control methods of problem solving or project management that operate by optimising one part of the system, will usually work in the short term, but to the long term detriment to the system as a whole. The result that I have seen first hand for many IT organisations in particular, is that they have developed a certain reputation in the market for being a bit on the nose because of their seeming inability to get a project completed. Once this happens, it is very very difficult for them to regain the lost trust.

Microsoft for example, has taken years to win back the hearts and minds of geeks for their actions more than a decade ago.

What sort of fast food is SharePoint?

If SharePoint were a fast food, it would either be one of those giant steaks that you get your name on the wall if you finish, or the Guatemalan chilli that sent the normally invincible Homer into the spirit world. It is so seductive to the sales guys because it is in demand, but their distance to the assholes means that they will think it should be just like any other IT infrastructure oriented project to install. Therefore, some integrators will be doomed to repeatedly bite off more than they can chew and by the time they realise it, the long term damage will be done.

So what do you do?

If you accept that the organisation is a system and that optimising one part of it will likely impact the rest of the organisation, often in unpredictable ways, then incentivising has to be more strategically focussed. In other words, the true performance indicator on a good sales guy is actually the success of the project, because it is a much more reliable indicator of the sort of food being passed to the mouth and results in customer goodwill – social capital. If sales guys received their morsels based on the success of the project as a whole, then it would force them to interact more with the assholes to achieve that end and think a little more carefully about what they feed the organisation.

But self interest is a very strong force and there are very few sales guys that would be enthusiastic about that idea. This is of course the other big problem. The longer you leave it, the harder it is for an organisation to make the changes necessary to produce the outcomes that they aspire to.

If you want to see that in practice, look no further than the Copenhagen climate change conference.

Final note about thinking in terms of systems

Of course, if we are taking a complex adaptive systems view, then one could argue that the affect of all of this would be that your sales guys will leave and find organisations who feed them bigger morsels with much less effort of (heaven forbid) being judged on real outcomes. As a result, opportunities for sales may be lost to competitors and the organisation still suffers as a whole

This is the dilemma of systems thinking and what frustrates the hell out of the “command and control” world. You can just end up with a giant talkfest and never actually make a decision on anything because systems adapt in ways that can’t be predicted.

Is it any therefore wonder that command and control usually wins out? 

Thanks for reading

Paul Culmsee

No Tags

So, why was Peter much more accurate with his estimates?

The answer to this question, all one has to do is think back to their teenage years, where they went through that awkward stage where you look back and cringe at the posters that were on your wall and your choice of fashion. For many, this period demonstrates some utterly appalling choices of taste. Mine are particularly cringe-worthy, given that these days I am a bit of a metalhead. My favourite song at the time was Respectable by Mel and Kim. I thought that Karate Kid II was the best film of all time (and that the girl in it was hot). Mind you, my wife has an even more shameful secret. She had a crush on Jean Claude Van Damme! Mwahahahah

These are examples of a phenomenon I like to call “Teenybopper bias”

Now, there is a point in telling you about my wife’s secret shame and it isn’t to see her reaction when she reads this (okay, well maybe a teenie bit). These examples of “what the hell was I thinking” are a form of cognitive bias that took place at the time the opinion was formed. In terms of teenybopper bias, the root of the bias is likely the same hormones that caused your face to break out with acne and hair to grow in funny places. Another very common cognitive bias that afflicts people whether young or old is good old “beer goggle” bias illustrated below.

There are many, many forms of cognitive bias documented, such as optimism bias, anchoring, hindsight bias and the recency effect to name a few. Now let’s take the final image above and pretend we asked someone at the pub for an estimate on a project at 8pm, 10pm and 1am. I’d be willing to bet that the estimate gets more optimistic on a par with how optimistic the perception of the people in the image above become.

Overcoming cognitive bias

Kailash writes about the risk that cognitive bias can play in project failure, particularly in the perception of risks.

overcoming biases requires an understanding of the thought processes through which humans make decisions in the face of uncertainty.  Of particular interest is  the role of  intuition and rational thought in forming judgements, and the common mechanisms that underlie judgement-related cognitive biases.   A knowledge and awareness of these mechanisms  might help project managers in consciously countering the operation of cognitive biases in their own decision making. 

The essential difference between Peter and myself in our estimating, is that Peter happens to have a much more finely tuned radar to optimism bias in particular. Douglas Hubbard of Applied Information Economics fame, writes about the effect of cognitive bias extensively in his two books and offers a simple, yet highly useful method to quickly improve the quality of estimates which I will explain with an example below.

The great thing about learning about your cognitive biases and the methods for mitigating them, is that you can use it in the pub too. While I don’t recommend this method for picking up members of the opposite sex, it’s a pretty cool icebreaker.

Thus, I will demonstrate how to improve your estimating accuracy by a mythical pub conversation. Imagine you are onto your third beer…

• Me: “How many SharePoint developers worldwide own a yellow car?
• Them: “What the…I haven’t the faintest idea!”
• Me: “Well, I can understand that, so let’s do an estimate. Give me a range that the answer could fall in, that you are 90% confident with.”
• Them: "I still can’t give you an estimate, I can’t possibly know something like that.”
• Me: “Well, could there be a million SharePoint developers who like yellow cars?”
• "Them: “Don’t be ridiculous, there would be nowhere near a million SharePoint developers – period."
• Me: “So you do have an upper bound then, less than a million. Remember this is not about the exact answer, I want a range that you would be 90% confident with.”
• Them: “Okay I get it. I think it is somewhere between three hundred and two thousand.

Note that at this point, we have already made the initial breakthrough. At first the person found it impossible to make an estimate, yet when I related it to something they did have a fair idea of (the thought of a million people), they made some mental associations and realised they did have some idea of limits after all. Thus, by presenting a better frame of reference that they could use to approach the problem, they were able to move from “I have no idea” to a wide range of possible values.

The width of the range reflects the uncertainty that someone has about the answer. The more the uncertainty, the wider the range. Some project mangers hate being given a ranged value because it really mucks up their task or project work breakdowns. As a result, they always want the “ball park” or something that is a single value. I completely understand why this happens, but what these people forget is that an estimation is uncertain by definition. The obvious way to express uncertainty is with a range of values! So asking someone for an estimation and then complaining that it is not accurate enough actually makes no sense. A manager might not like the “width” of the range, but you can’t force someone to reduce their uncertainty just because it doesn’t fit the plan. Unless you provide them with the means to reduce this uncertainty, you cannot and should not try and artificially reduce this range through pressure and coercion.

But despite my observation of the flawed logic of dealing with uncertainty in estimating, a ranged estimate alone is not enough yet. We still have not accounted for the sorts of cognitive bias that I described earlier in the article. So without further adieu, I present a simplified version of Hubbards ‘calibration’ techniques that account for bias. Let’s continue the bar conversation.

• Me: Okay, so you are 90% sure that here are between 300 and 2000 SharePoint developers in the world with a yellow car?
• Them: Yes
• Me: So, let’s make this like the game show “deal or no deal”. If you are right and the answer is within your range, you will win $10000. BUT you have an alternative…
• Them: Ok…
• Me: What if I were to present you with a bag containing 9 red marbles and 1 black marble and offer you $10000 if you pull out a red marble. Pull the one black marble, and you miss out on the money. Do you want to stick to your estimate or do you want to draw a marble?

I’d like readers to think about this before continuing with this article. Make a ranged estimate of the number of SharePoint developers worldwide who drive a yellow car, and then decide whether you want to stick to your estimate or take your chances with the marbles.

(Cue game show music where you have 10 seconds to decide with a little ping sound at the end.)

The suspense is now killing you I am sure. Want to know the correct answer?

Find out after this short commercial break (game show speak for wait till part 2 of this series )

Thanks for reading

Paul Culmsee

www.sevensigma.com.au

No Tags

Hi

I attended and spoke at the Perth Business Analyst World Conference this week and really enjoyed it. This was a bit of a departure from the SharePoint events that I normally frequent, and I really didn’t know what to expect. Certainly, not having to fly 30+ hours just to speak is a big plus The recommendation to the organisers to consider me, came about via Craig Brown, who has a very popular project management blog that I follow. Thanks so much Craig, I owe you a beer when I am in Melbourne next.

The conference report…

My talk was actually *not* about SharePoint and instead I was able to focus on more of my material on wicked problems, the shared understanding/shared commitment principle and then, the sense-making tools and techniques that I use to help bring this about. I was also able to demo the fruits of a very exciting, non IT project that I have been working on for a long time (more on that in a future post).

Despite my “This ain’t my normal crowd” trepidations, the feedback was great and the best thing to hear from participants, was that for many, it was stuff they have never heard before. That, for me, was really satisfying because I like the notion of presenting new ideas that actually have some decent practical examples to back them up. (This is something Andrew Woodward and I have in common. We love academic rigor for what we use, but it has to have been used in the real world with tangible success). Although I know that some people will disagree with the methods that myself and my colleagues use, I was able to demonstrate what I think is some pretty compelling case studies that support them.

What was interesting though, was that the examples and case studies were able to support what a lot of the other presenters had to say as well.

Ann Smith of Black Circle for example, had a great talk that was essentially about human cognition; essentially the wiring in our brains that serve to explain why big, fat documents are often not good ways to convey information. (Being a practicing dialogue mapper, no arguments from me there!) I am a nerd for this sort of stuff, having written previously on behavioural styles, learning styles and organisational culture, and Anne offered some new, interesting things that I have previously not considered or covered – more blog fodder for CleverWorkarounds, methinks.

Another highlight,the Western Power Business Transformation project, presented by Lorraine Pestell was also fascinating (I have a weakness for voice of the customer type sessions and this was no exception). Many of the strategic challenges that they are facing, such as sustainability and the changing business/regulatory environment, is very similar to the work I am doing elsewhere and it was great to see how Lorraine and her team were approaching the challenge and has given me some ideas and approaches to take back with me to my clients and projects.

The BA identity crisis

But back to the question suggested by the title of this post. There were some panel and round-table sessions about the topics of what actually *is* a BA, how you validate or recognise BA excellence, and the perennial BA versus PM turf-war debate.

Up until this time, I had actually never considered myself a BA because I had never actually given it any thought! As a self employed consultant, the only thing that matters is doing a good enough job to keep people wanting you to come back. So to that end, I didn’t worry so much about what I was called, provided that my clients were happy and the invoice was paid. But even if I wasn’t a consultant, I think that role titles often do not reflect reality and they also have a pigeonholing effect, depending on the attitudes and perceptions of what others think that role entails. Many position titles were discussed, “Solutions Architect”, “Business Architect”, “Change Manager” and some that were so pretentious that they bordered on wanky. More fancy words with no more clarity. No wonder many BA’s are struggling a bit for a sense of identity.

What I noticed when talking to the conference participants was that some attendees spoke from a lens where they seemed to feel that it was incumbent on them to provide a “translator” role between IT and “the business”. After all, nerds and CFO’s can’t communicate right? Enter the BA to ask questions and solve problems.

I have no major objection to that notion at some levels, but it is that *precise* mindset that makes me think “Well, I am definitely not a BA.”

Why? It was the notion that this “translation” was based on being the go-between from IT and the business. Thus, taking what one party says, transforming it and then passing it to the other party. As a result, BA’s are acting as a listener and interpreter, yet relaying second hand messages (messages that may be very different originally) between parties.

I personally balk at this. In fact, it really grates on me. By that definition, I don’t think I am a BA at all.

Interestingly, other topics of conversations were around “Well, how does a BA fit into Agile?”, “Is there a place for the BA in an Agile world”, and the like. What was interesting, and somewhat concerning, about these conversations was that those BAs who tended to think of themselves in terms of this “translation” role, really did not have a great grasp on the underlying principles of what we now call “Agile”.

Although Agile means a lot of different things and there are different sub-methods applied, these BAs got all focussed on the processes of Agile. They overlooked the fact that the process is actually the means to an end and it is the end-game that they have overlooked. Agile, (okay well Scrum anyway) attempts to use process and rigour (yes, rigour!) to make a project as conducive to shared understanding as possible. Probably the best thing that Agile does, above all else, is put diverse people in the same room. That alone will make bigger understanding breakthroughs than anything else!

Business Analyst KPI – shared understanding?

So, why am I not a BA?

My methods for translating are fundamentally inclusive. In other words, I do not “translate” anything, “take” it to another party and “relay” through my own words (and lens). I feel that despite all best intentions and whatever diagramming or modelling tool that you use, when you do this, you will always still find that you have your own cognitive biases that will not necessarily deliver the shared understanding that you think you are delivering. Instead, what I do is provide a rich container for a group to explore an issue together. In the same way that Agile tends to like all project members and stakeholders to be in the same room, Dialogue Mapping puts everyone in the same room and provides a suitable container for handling dialogue in a much better manner than traditional meetings and workshops.

If you agree with my previous assertions that a lot of the visible causes of project failure (scope creep, vague requirements, etc) comes from a lack of shared understanding among participants, and that BAs identify themselves as the bridge between IT and “the business” (which by the way is an insultingly gross simplification), then isn’t the ultimate KPI for the BA is to create and maintain that shared understanding? If not, yours is just another opinion that is counted no more or less than anybody else’s. Are you signal or noise?

So, in my humble opinion, the role of the BA is not to be the go-between from disparate stakeholders. Instead, it is your ability to create the sort of conducive holding environment that enables project participants to achieving shared understanding. How you do that is completely up to you of course, and if you have managed to progress a group from an agreed undesirable present state to a desirable future state, then your methods are totally validated.

Get over titles…

Now, if you call yourself a BA and think I am picking on you because you feel that you are the translator, don’t feel bad because plenty of PMs are guilty in their way too. In some ways, I feel that business analysts only exist as a career because enough people with the “Project Manager” title thought that time and budget alone were the only factors in project success. Some PMs who disagreed with this, felt that solving the problem was also critical, gravitated to the discipline of what we now label as “Business Analyst”. Some application developers that felt there was more to life than cutting code and made a similar gravitation. Put a bunch of like-minded people together and soon enough we have a “cool kids” club and lo’ and behold, we have a new discipline with a new set of titles.

(“Information architect” is a more recent example of this phenomenon than “Business Analyst”).

But, let me tell you something else about this title misconception. For a BA to label all PMs as interested only in time and budget is an insult to those PMs who actually understand that achieving and maintaining shared understanding is the end-game. The truly great project managers who I have had the pleasure of working with were actually leaders, not managers. They have all of the same characteristics of what makes a truly good business analyst: Critical thinking, soft-skills and most of all, a great radar for determining when stakeholders are not aligned and doing what is necessary to rectify the situation. They do not always dive into process and structure because their particular body of knowledge told them to. Instead, they have coffees, drink beer, conduct lunch-time workshops with free food and beverages, mediate, essentially whatever is needed to oil the cogs of dialogue that prevents something small becoming something nasty later.

By the way, I have met some angel application developers like this too, as well as infrastructure people.

If you want proof of a truly great project manager, then Kailash Awati’s wonderful site should be mandatory reading for both the BA and PM disciplines (and scrum masters too for that matter!). Kailash writes what essentially is a project management blog, but he has a deeper understanding of the sorts of soft factors that would put many BAs and some facilitators to shame.

Conclusion

In my talk at the conference, I emphasised that the ultimate success factor in any project is bringing about shared commitment through shared understanding among the participants. I believe that achieving these goals is the ultimate KPI for a BA, or anybody else who feels that they are there to help solve a problem, not deliver a crap solution that happens to be on time and on budget.

Thus, any method that helps a group achieve this is a good method because it has made a positive difference in advancing a group from understood present state to an understood desirable future state.

So, perhaps I am, after all, a BA?

Thanks for reading

Paul Culmsee

www.sevensigma.com.au

No Tags

Quick note: This is another of the sort of posts where I cannot help but feel that some readers will wonder what I have been smoking. It is not essential, but reading the “one best practice” series will provide a lot of background to this post.

On the grand scale of world problems, your average messed up SharePoint project would not be considered particularly “wicked”. If you compare a haywire SharePoint project to the truly *global* wicked problems, such as global warming, the Israeli/Palestinian conflict and Tom Cruise, then it kind of makes you realise just how good we SharePoint architects, developers and engineers have it. I mean, hey, if a bunch of nerds can’t make little ol’ SharePoint a success, what hope do we have for the big issues like making Tom Cruise less of a tool?

I know some people who have left SharePoint architecture work because of all the “people crap”. If you think “people crap” is bad in IT, imagine trying to mediate between the myriad of stakeholders involved in, say, cuts to carbon dioxide emissions. That is a world of hurt that is so huge that it pains my brain just to imagine it.

Last year when I was learning the dark Jedi arts of dialogue mapping I got to know David Price, one of my fellow students who operated in that world of hurt. David is a very smart man indeed, with a Ph.D in organisational learning and environmental policy. His career has included public policy consultancy, TV documentary production, academic research and mediation.

It was during that training course that David introduced me to a joint venture that he started with another scarily smart man named Peter Baldwin. Peter is an Australian who had a 15 year career in national politics, including six years as a federal minister in the Australian government. Unlike many Australian pollies, his background was engineering. After leaving politics, with a keen interest in how the web could “raise the quality of debate about public policy issues,” he cranked out visual studio and got down to some coding.

The “baby” from this collaboration between David and Peter is a unique tool called Debategraph and it is a very interesting tool indeed.

DebateGraph was conceived as a tool to improve the quality of public debate on contentious or complex issues. Public debate, in general, is usually pretty awful. David and Peter explain why this is the case pretty comprehensively below.

Public debates tend to be complex; with multiple data sources and perspectives and conflicting demands and values. In complex debates, the volume of information and arguments can seem like an overwhelming obstacle to someone, trying to develop a comprehensive understanding of the essential arguments advanced by all sides.

Public debate is all too often characterized by repetitive contributions, digressions, argumentative fallacies, rhetorical flourishes, manipulative framing, obfuscation and personal attacks that result in a high noise-to-signal ratio and confusion rather than clarity.

Conventional media reporting of public policy debates often struggles with the challenge of conveying nuanced, reasoned positions in a compressed linear form, when simple heated oppositions deliver a more dramatic and rewarding effect.

This, in turn, makes it harder for established public figures to think tentatively and creatively in public about new policy approaches and to acknowledge strengths and common ground in opponents’ positions.

We are talking about wicked problems here a lot of the time since public policy debates by definition respond to problems or questions where the general public are stakeholders. This means that there are a lot of varied stakeholders with even more varied world views and frames of reference. By creating a tool to improve the quality of a public policy discussion, DebateGraph is a tool that helps to deal with wicked problems themselves. What is interesting about DebateGraph is that like the IBIS based issue mapping that I practice, it is a visual, map based approach, yet it was developed independently from Conklin, Compendium or anything else in the space.

DebateGraph is a free online service. It allows the global community to collaboratively build maps of complex debates that accurately present all sides of the debate from a neutral standpoint, free of repetitive clutter and ‘noise’. Like a wiki, all aspects of the debate maps, both their content and structure, are continuously open to revision, refinement, comment, and evaluation by anyone who wants to join the community of thought. Each map is a cumulative work in progress.

Readers and editors of the maps can explore the top-level structure of debates and delve into specific strands or sub-structures of a debate. What interested me was the fact that the debate maps can be embedded into other websites; with changes made to the map on one site updating immediately across every site on which it appears.

DebateGraph also has RSS and email alerting like SharePoint, as well as a unique rating system where users can specify how much they relate to, or believe in a particular argument. The map then self reconfigures based on what arguments are considered the strongest. In effect, the map becomes a multi-dimensional poll or decision making tool.

“Although consensus can emerge from such a process, not least because it promotes the discovery of previously unidentified options, our hope is as much that the people who continue to disagree will do so on the basis of an enriched understanding of the reasons for their disagreement and having had the chance to test each other’s reasoning to the fullest.”

How DebateGraph works

Using DebateGraph is pretty easy, given that you can embed it into other web sites as I have done here in this post. From the hundreds of maps that I can choose, I’ve decided to embed the map of the global financial crisis for you to explore. Click on the bubbles below and move them around. You will find that like bubble-wrap, you will spend your first few minutes immersing yourself in moving nodes around and navigating here and there. Go ahead and have a play – I’m patient – I’ll wait for you

Right! I’m guessing around seven minutes have passed. Now that you’ve had a play, click on the first arrow, below the map and above the bottom toolbar. This will take you back to the top level financial crisis map. Let’s take a closer look at what is going on here.

Attached to this “Global Financial Crisis” map is several root questions covering the cause, consequences, triggers and response to this problem. If you hover your mouse over any of the nodes, you will find a more detailed view of the question. Hover your mouse over the arrows between nodes, and you will find that the questions “arise from” the central “global financial crisis” node.

Also, note the thickness of the arrows between nodes. The width represents the importance placed on this node by the community of users that have developed this map.

The node colours are important too. Click on the “Long term causes of the financial crisis?” node above, and it will break out to a sub-map. Here the nodes are blue, rather than orange as shown below. The difference in colour is because these nodes are possible responses to the question “Long term causes of the financial crisis?” Once again, the width of the arrows indicate the community’s view of the validity of the responses. Now let’s look at a response that would potentially be divisive. One of the potential answers to the long term causes of the current crisis is “Natural financial dynamics of the baby boom generation.” So, it’s all the baby boomers fault, is it?

Clicking on the “Natural financial dynamics of the baby boom generation” and we see a map with a few different coloured nodes. This is because there are some supporting and opposing arguments to this idea. The green nodes support the idea and the red nodes oppose the idea. This is the essence of the pro and con type arguments used when you create IBIS maps.

There are also some other nodes where the direction of the arrow is the opposite to the ones we have examined so far. These are links to other maps, and if you highlight the outward arrows, you can see that our current map relates to nodes in completely separate maps.

This highlights a really important point about DebateGraph. It links related issues into a “web” of argumentation allowing readers to fully explore the myriad of interlocking issues that make up complex problems without “drowning” in information overload.

Contributing to debates

If you feel strongly on a particular subject then you are free to contribute to the debate. All DebateGraph maps have a toolbar that allows you to perform more advanced activities.

From left to right, the icons perform the following tasks

• Open the DebateGraph home page
• Show detailed text and comments for the currently selected item
• Add comments to the selected item
• Open this map in mapper (map edit) view
• Edit this map in mapper (map edit) view
• Search all DebateGraph maps for a given term
• Share this map view or embed it in your own site
• View the map in full screen mode
• Key and explanatory notes for maps

SharePoint Governance?

Andrew Woodward suggested that I should create a DebateGraph map for us all to collectively explore how we could save Tom Cruise from complete agonising lameness. I chose not to do this for three reasons.

1. Tom Cruise cannot be saved
2. Tom Cruise’s lawyers would sue my ass
3. There are more important topics to explore

Let’s instead talk about a pet topic of mine: SharePoint governance.

Governance in SharePoint is pretty misunderstood. There are many definitions of governance and they are all equally right, when judged through the lens of the person defining it. I have my own interpretation of governance (which is, of course, the definitive and completely correct one! – hehe). Maybe we should debate the issue?

Joel talks about a SharePoint governance plan needing to be a ‘living’ document and in fact he states this explicitly in the sample governance plan that he did for Microsoft. I agree wholeheartedly on this notion. The reality is that documents like MSWord documents are not overly conducive to this ideal. The paradox is that the bigger and more comprehensive the governance plan is initially, the harder it can be to maintain and manage over time, and therefore, the greater the likelihood that it can go out of date or fall into disrepair over time.

As a result, it occurred to me some time back that a DebateGraph map is the sort of “living” document that a governance plan really aspires to be. So, I roped in a couple of friends, most notably Andrew Jolly and Ruven Gotz, and together we experimented with DebateGraph to explore our own questions and ideas on the topic of SharePoint governance. The result is the map below which you can explore.

Seven Sigma web part for DebateGraph

It then occurred to me that others could benefit from this experimental exploration of the topic of SharePoint governance. This gave me the idea that having a “SharePoint governance web part” that could be added to any enterprise SharePoint portal would be a really great way to augment internal governance efforts. Additionally, one of my clients is responsible for conservation and sustainability at a local level in the community. They loved the DebateGraph debates around environmental, social and economic sustainability and this web part idea would work equally well for them.

Accordingly, my company, Seven Sigma, has just released a free webpart for SharePoint that allows you to embed DebateGraph debate maps into your SharePoint sites and tune their display to fit into enterprise SharePoint portals. The default debate is the SharePoint Governance debate shown above, but you can view any of the many Debategraph maps via the web part properties.

I have recorded a couple of webcasts, covering the installation and usage of the web part which can be viewed below. Otherwise, click here to download this free web part from the Seven Sigma web site.

Conclusion

This new web part and the SharePoint governance debate, are essentially an experiment in trying to tackle collaboration a novel way. Like any wiki, to make it truly “living”, the maps need contributions from people who have something to offer on the topic. I fully accept that this initiative is not going to be everybody’s cup of tea, but I hope that it might get people to think about the sort of possibilities presented by this sort of wiki based display. The fact that all of the issues, ideas and argumentation can so easily be made available to a wide audience via a simple web part I think is unique.

Thus, if you would like to contribute to this SharePoint governance debate sign up to Debategraph and we will add you to the governance debate.

I think that DebateGraph, and applications like it, may well represent the next step in the evolution of collaborative applications. While Twitter and Facebook have found interesting ways to bring people together, those applications aren’t exactly going to provide you with the sort of ‘container’ required to tackle really wicked problems. I foresee a lot of development in this sub-genre of collaborative applications in the future.

In other words, watch this space!

Thanks for reading

Paul Culmsee

www.sevensigma.com.au

No Tags

I have been very busy on a number of fronts – which is why the blog hasn’t had much attention lately. I’ll be back soon enough though – once I get a few big jobs done.

For those of you that are not aware, there is a podcast interview that I did with Brett Lonsdale at Sharepoint Pod Show where he allowed me to blab on and on and on and on Poor Brett – he didn’t know what he was getting himself into at all!

So if you think my posts are boring and wordy, wait till you hear me talk!

Paul

No Tags

Today I presented a session at the Perth SharePoint Users Group. I was a little unsure whether my non-technically focussed content would be of interest to the geeks but the turnout was terrific and the feedback has been brilliant. (The 3 copies I gave away of Dux’s excellent “SharePoint for Project Management” book may have sweetened the deal – hehe )

My sincere thanks to new user group president Sezai Komur for giving me the opportunity to present this material as it was the first time it has seen the light of day in Perth.

If you want to check out the slide deck from the session, you will find it below. Expanded information that builds on this content can be found at the Seven Sigma site, as well as here at CleverWorkarounds.

Thanks for reading

Paul Culmsee

www.sevensigma.com.au

No Tags

Hi all

There are a few people in my life who have had a big influence on me as a person, consultant and trainer. Jeff Conklin from CogNexus Institute is one of them. If I was to rank Conklin, I’d say he comes in somewhere between Jackie Chan and Freddie Mercury – illustrious company indeed.

Jeff armed me with the right set of skills and way of thinking that allowed me to defeat the likes of “SharePoint vs Skype guy”, a highly skilled foe that I previously wrote about in the “One Best Practice” series of posts. As it happens, Jeff is running another of his Issue Mapping webinar based training series starting April 8 2009. Anyone who is involved in highly complex projects (whether technically or socially challenging), including managers, project leaders, consultants and facilitators should consider attending.

SharePoint people? You are dealing with technical and social challenges almost by definition. Issue Mapping is the most effective craft I have come across to:

• be able to lead a group to a robust decision that endures and that inspires consistent actions and outcomes despite the cross-currents of hidden and competing agendas
• get traction in the "swamp" of a project that is cursed with both technical and social complexity
• have real dialogue without getting bogged down in politics, personalities or an overload of information
• help a group get its bearings in the fog of confusion, contradictory objectives and changing constraints
• be able to focus a group’s energy in a way that boosts collective intelligence: the capacity to work with ambiguity and equivocal knowledge
• be able to capture and organize a large volume of unstructured information to create a coherent foundation for thinking and learning in an organization

Consider my example below: I have summed up the entire global financial crisis in a single issue map – neat eh!

Like my above example, you will learn how to create great issue maps – maps that are clear, coherent, and expose the deep structure of an issue. (okay so I am being just a *tad* tongue in cheek with my example)

In all seriousness, it is a great course and well worth attending. If you enjoyed the “one best practice” series or my “wicked problems” sessions, this is your opportunity to learn from the master.

Thanks for reading

Paul Culmsee

www.sevensigma.com.au

No Tags

Often people use metaphors to describe various aspects of SharePoint. I am guilty as charged here. One of the many that I use for SharePoint, is the metaphor of an Ikea modular storage solution to describe the new paradigm of moving from folders to document libraries, columns, views, workflow, sites, content types and the like.

But, I see a very common mistake with a lot of SharePoint metaphors that you must be careful with. People use tame metaphors for SharePoint, and this misleads.

Confused? Well consider this. There are two main types of problems in this world. Tame problems and wicked problems.

This is what a tame problem looks like according to Conklin.

• A tame problem has a relatively well-defined and stable problem statement.
• A tame problem has a definite stopping point, i.e. we know when the solution or a solution is reached.
• A tame problem has a solution which can be objectively evaluated as being right or wrong.
• A tame problem belongs to a class of similar problems which can be solved in a similar manner.
• A tame problem has solutions which can be tried and abandoned.

A wicked problem on the other hand looks a little different.

• A wicked problem is not understood until after formulation of a solution.
• Stakeholders have radically different world views and different frames for understanding a wicked problem.
• A wicked problem can be explained in different ways
• A wicked problem is always considered a symptom of another problem. 
• Constraints and resources to solve the problem change over time.
• The problem is never solved.

Yeah, I know – it’s a rhetorical question, but which category do you think many SharePoint projects fall under?

Wicked metaphors

So, just like problems, there are two types of metaphors in the world too, tame ones and wicked ones.

The reason that my Ikea metaphor works has nothing to do with Ikea itself. The point I am  making is that even with the most spectacular modular Ikea storage solution, installing it is not that hard. I mean, if you read the instructions and take your time it can be done. Even if you rush, you might have a few scratches and hit your thumb with the hammer a few times, but you will get it installed. Even so, many prefer to get an Ikea guy to come in and do it.

But, here is the rub – the Ikea guy can’t help you agree with your dysfunctional family about whose underpants should go where. Guess what – *that* is the wicked bit! Wickedness has little to do with the Ikea furniture itself. It is all about the social complexity of those who have to work with it together.

So, be careful if you say something like “SharePoint is like building a house, you need to lay the foundations first…” Why? Remember that building a house is actually a very tame problem. People do them all the time and we pretty much follow the same script. Many collaborative solutions are not tame in this way. Therefore, this metaphor misleads and is completely inappropriate.

In fact, if you wanted a more accurate house metaphor, you need to add the social complexity and organisational chaos element to it. In my version, it is still a house building exercise, but this time you are the foreman and the construction crew consists of your mother in law, Homer Simpson, Eric Cartman, Tom Cruise and Paris Hilton.

I pity the project manager who has to deal with that combination of personalities!

Thanks for reading!

Paul Culmsee

www.cleverworkarounds.com

No Tags

Hi again and welcome to the sixth and final post in this series aimed at enlightening readers to the often overlooked importance of shared understanding of a problem. For those of you who have come across this article for the first time, I suggest very strongly that you stop and read through its predecessors. There is a lot that was covered to get to here.

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

To recap, we have spent the last two posts delving into the deep structure of problems by using an issue based mapping method. This post will continue in that same vein, but I am going to move a little faster this time and cover more argumentation with a little less explanation. I’ll also finish off with some other interesting aspects to IBIS and dialogue mapping that we haven’t covered so far.

The first 4 posts were all about one of the key root causes of the organisational chaos that causes projects to go haywire, whether it is a SharePoint installation or trying to get the coffee machine fixed. I believe very strongly that if a group of participants can attain and maintain a sufficient level of shared understanding, then often what seemed like a polarising problem with intractable stakeholder positions, can start to make real progress toward resolution. The collective intelligence of a group is a powerful tool to be leveraged, but all too often it can be brought undone by social complexity and the inherent inefficiency of meetings. SharePoint is prone to social complexity because of its technical complexity, malleability and the fact that it is sold by Microsoft and they use that damn six pillar pie chart .

By the way IT people – your projects are rarely actually “wicked problems” in the true sense of the term. Until you have been involved in dialogue mapping a planning or social policy type problem with countless sub-issues and stakeholders, then you do not know just how good you have it!   In saying that, I recognise that many, if not all, IT projects have a lot of wicked elements to them.

Previously on CleverWorkarounds…

In my last post, we had developed an IBIS based issue map that I think is a reasonable reflection of a blog article written by Joel Oleson, incorporating some feedback by readers who disagreed with many of his points. What is great about Joel’s style of writing is that he likes to use headline grabbing titles for his articles. As a result of this, he stimulates rigorous debate and I could probably spend the rest of my days on CleverWorkarounds simply IBIS mapping his posts and all of the responses.

But, we haven’t finished issue mapping this site definitions thing, so let’s finish it off by mapping the rest of the responses. Below is a scaled down view of the map that we had by the end of part 5 (click to enlarge).

Now, let’s go through some more responses and work them into the issue map. First up was this incredible quote showing much wisdom and maturity. Who uttered such pearls of wisdom? Oh, wait, that was me  !

Joel and I spoke about this earlier in the day actually before this was posted – I hate them also but accept their need in WCM scenarios.
My biased view of the world stems from a site that I visited where branding had been put above all else and so it was an undocumented site definition with custom controls, dodgy web.config hacks all running in full trust to make it all work. 2 days later and I had it migrated. But it was all so *unnecessary* and I think that’s Joel’s point. They get used when they shouldn’t.

The client in this case had never been shown columns, views, versioning and this was a document centric intranet for cryin’ out loud! Instead they get a pretty site with a 50gig content DB because of a hacked site definition with custom nav controls to look pretty, application.master hacks to make it consistent and no thought process into information architecture. They simply took their existing ugly filesystem and whacked it in!

Hmm, when you read my response, all I did was support Joel’s original assertion that site definitions are modified unnecessarily, so in essence I did not really add that much to the conversation and in fact the example that I used was a client who had way more issues than the custom site definition alone. So as it happens, my post really didn’t add anything *new* to the discussion.

Next we have this anonymous response:

In situations where lots of sites need to be created from one pattern and you want old sites to get new changes, site definitions are a must. As mentioned above, you can’t staple features to a template.

I think you’ve swung the pendulum too far with your comment. Yes, big, bulky, all encompassing site definitions aren’t very maintainable. So don’t use them this way! As AC and others have blogged about, create a blank site definition for stapling purposes, and package everything in features. You still need that first site definition though! STP’s are for end users, IMO, not for solution developers.

The quote above makes the important point that “if a lot of sites need to be created from one pattern” and “if you want old sites to get new changes”, then site definitions are pretty much required. I created an pro called “Single click deployment and upgrade” and then fleshed it out with the those ideas. The comment about pendulum is unimportant. Below is the new map

Next up Adam Toth makes an excellent, yet subjective counterpoint to the “difficult to upgrade” argument.

Since this is version 1.0 of Features, Solutions, Stapling, Content Types, Workflow, etc., I really believe that any upgrade to the next version is going to be a headache anyway. No matter what you did in sharepoint v1, it broke going to v2. v2 to v3 was also incredibly painful because the product changed so dramatically. We have no visibility into v4, and have no way to figure out what approach will make upgrades least painful. We can assume that things are starting to solidify, but there are no guarantees.

The above response from Adam questions the previous claim that site definitions “are difficult to upgrade and support” by arguing that upgrading will be difficult no matter what. I do not delete the original “difficult to upgrade and support” con, but incorporate Adam’s points as a new question “Really?” against the con, and then support that question with the idea that “Upgrading will be difficult anyway”. Adam supplied 3 arguments supporting his claim (many SharePoint components are V1, the previous versions were all painful upgrades and that we have no visibility into how the next SharePoint will work). Now the map looks like this.

Next is David Mann

Custom Site Definitions are a tool. Like any tool, they have benefits and drawbacks. Used properly, they provide much value. Used improperly, they cause pain.
Even the body of the article contradicts the sensationalist-headline by saying that there are some things you can’t do without a custom site def. The article of AC’s that this links to, and it’s comments, talk about a solution that is a totally blank CUSTOM SITE DEFINITION, that is then built up properly with Features/Solutions. They also mention publishing scenarios that the recommended approach is a custom site def.

So, the best approach is to do your homework. If a custom site def REALLY is the best approach, then feel free to use them. Just make it a conscious decision, knowing the trade-offs, not your default reaction because it’s easier.

At this point, it is time to add a new question to this map, as like other respondents, David is referencing Andrew Connell’s post on this subject. David mentions a specific application of site definitions (use a blank one and add to it with stapled features), which is in itself not a pro or con of site definitions, but a way of using them that mitigates many of the disadvantages of them.

Since we are IBIS, and we now have this new idea “Use a blank site definition with features/solutions”, and we need to infer the question behind the idea. My initial guess is “What is the best practice for using Site Definitions” and I have added it to the map as shown below. We could easily use Andrew Connell’s post on this subject to further flesh out the best practice for Site Definitions on this map, but for the sake of article size I have chosen to continue with the original responses to Joel’s post.

Chunk it up

At this point, the map is getting large and we need to make it more manageable. Fortunately, this is very easy using tools like Compendium. I simply create a new sub-map and copy the nodes to the sub map. In effect I start to build a hierarchy of the logic behind the argumentation. Below shows the top level argument map at this point, now chunked into sections. Each sub map “Discussion on the use of site definitions” and “Discussion on the use of site templates” is now in its own sub-map that is accessed by clicking on the parent map.

The final response that I will cover off for now is from SharePoint Yoda, Eric Shupps who writes a really excellent factual based response to the post.

There are many scenarios in which they are required:
1. Automated Provisioning – Self-contained solutions that have all necessary functionality baked in (think hosting and SAS models).
2. Repeatability – They migrate better from dev to staging to production better than any other method.
3. Maintainability – New Features can be added or removed as required and the solution upgraded. Try doing that with an STP file.
4. One Click Deployment – The user simply selects the proper definition on the site creation page, to which you can add descriptive text and sample images (what do you think all those other options are? They’re OOTB site defs, that’s what).
5. Control – Nothing beats a site def for restricting what features site owners can and cannot use. Very important in many enterprise environments.
6. Ease of use – There are lots of workarounds for the power and flexibility that site defs provide but all require a great deal more code than a simple site def with stapled features.
Sorry to burst your bubble but you’re wrong on this one. Next time, ask a developer with experience doing Site Definitions the proper way before you go off on an opinionated rant. I’d be happy to help!

Some of Eric’s arguments are already in the map, but not all of them. Furthermore, he further expands on some of the arguments that already are there. First up, I changed my original pro of “Single click deployment and upgrade” to “automated provisioning” because I think this captures that argument more succinctly. Even though Eric then lists “1 click deployment” as a separate criteria, I think they belong together and it’s my map! .

Eric also highlighted “hosted” and ”software as a service” scenarios where automated provisioning is particularly important. Since I already have a nice string of argumentation, asking for criteria of when to use site definitions, I have added these as supporting arguments to this existing set of nodes.

“Repeatability” and “Control” are excellent points, and I have captured Eric’s arguments in this area. To make the idea clearer, I captured “Control” as “Tight administrative controls” as this is less ambiguous in its meaning than “control” alone.

Then Eric hits the one argument that no-one seems to agree on. “Ease of use”. Clearly Eric’s idea of ease of use is different to Joel’s. When you look at Eric’s supporting arguments for ease of use, it appears that he is really reiterating the “automated provisioning” pro for site definitions and supported the “more manual customisations needed” con for site templates.

The adjusted map for the site definitions idea has now morphed into this.

Emergent Themes

I am going to stop this IBIS map now because otherwise, I could spend another 5 posts just working through all of the contributions made by various people. But more importantly I want to highlight a few really important points that might get lost in all of the screen-shots.

One of the things that I notice when performing Dialogue Mapping with a group is that the action of utilising a shared display like IBIS allows people to make connections much more quickly and really starts to make clear some of the underlying themes behind the discussion. It is much quicker and more efficient for participants to achieve the necessary breakthroughs when argumentation is visually represented and lots of seemingly abstract concepts can be logically related to each other. It seems to be that as human beings, our brains are particularly well-wired to visual based representation.

I want you to picture yourself in a meeting scenario where we are discussing a problem. It doesn’t have to be a face to face meeting either (although this is usually the case). It can be a group collaborating on a problem using blogs, wikis, discussion forums or any other medium. Without the issue map, there will be a number of problems that will combine to derail the meeting.

First up, there is likely to be a lot of points that have been made. If we were following the meeting in a traditional, linear fashion the argumentation would look something like this:

What you are looking at above is in effect, a visual version of traditional meeting minutes. (You know those documents that get sent around that you never read?). This also is not too dissimilar to the structure of a blog post (and the subsequent comments). Contrast this to the issue map that uses an issue based structure that makes the logic and flow of the conversation visible. Which is more meaningful? Which is easier to “read”?

For a start, people do not have to decipher any convoluted dialogue – we do not spend half the meeting disagreeing and then realising that we are actually talking about the same thing. The objectifying of the dialogue reduces those situations where the defences are high because people have inferred some bias that can easily be misconstrued. Different points of view are made much clearer and we do not continually revisit the same old topics over and over again. As the argumentation is further fleshed out, participants are much less likely to get lost or lose track of the conversation. Even if they do, we have a beautiful ‘corporate memory’ system here that is starting to form. Just because one person wants to return to a previous point and ask a question or add an argument to it, doesn’t mean that the next person has to take up this point at his or her turn. They can jump to wherever in the map their current train of thought takes them.

Death by repetition is also mitigated nicely. Death by repetition is those times in a meeting where there is a “true believer” who believes very strongly in a course of action to the point that they will find a way to work their answer into every question asked. Don’t feel too guilty when reading that – we all have done this.  Of course, it annoys the crap out of everybody else present, but the true believer will doggedly persist because they feel that their answer has not been considered enough or given the recognition that it deserves. But once captured on the issue map, the idea is visible and has equal footing to all of the other ideas. If the true believer persists, then the mapper simply asks the true believer if they have anything more to add to what is there already. Usually this only happens once .

There are other phenomena that are guaranteed to derail a meeting, usually leaving all participants emerging from the meeting annoyed that they never got to the actual agenda. Conklin calls this “grenade lobbing” and this is where a participant, usually with the defence drawbridge raised, will challenge the whole frame of the meeting. “That is not the real issue here”, they will explain, “it is this”. (Remember wicked problem rule number 8, every problem is a symptom of another problem). Every time you have emerged from a meeting, feeling deflated and wondering what happened to the agenda, chances are a few grenades were lobbed and the entire purpose for coming together was caught up on a tangent.

But issue mapping makes dealing with this easier too. Usually when a grenade is lobbed, where the frame of the meeting is challenged, it means that the root question of the map is not correct. Fortunately with an issue map, the answer is quite easy. You simply shift the map to the right and work with the grenade lobber to infer the deeper question. Once captured, the group can continue to work with the implications of this new question or continue to work with the rest of the map. The previous disruptive power of the grenade lob is significantly mitigated.

Final Note – Tech geeks vs Developers

I previously said that performing Dialogue Mapping and IBIS allows people to make logical connections much more quickly and really start to clear some of the underlying themes behind the discussion. This “Joel vs developers on site definitions” example that I have been working with was actually not a great IBIS example. The reason is that if we had started the entire conversation using IBIS, then a lot of the subsequent argumentation would have been very different. If say, Joel had used IBIS to structure his arguments to begin with, apart from making my job a lot easier, the map would have underpinned a very different blog post in structure and clarity of argument.

But despite the somewhat artificial nature of my example, from the mapping that we have performed so far it is clear to me that the two distinct viewpoints have emerged. This argument cuts to the heart of the IT Pro vs Developer world. Certainly a strong indication of this was the disagreement behind what is actually “easier”. It seemed that Joel’s easier is very different to the developer view of “easier”. Of course, we haven’t even counted the other stakeholders either and I bet the end-users’ definition of “easier” would be completely different from the two themes that emerged.

I personally come from an IT pro background and IT pro’s have become paranoid types because they are always the ones who have to deal with the after-effects of bad customisations (See the “mother hen reflex” post for how that has come to be). But through mapping this issue out, I was able to make some definite connections with the developer centric replies too. I didn’t necessarily agree with all of the points made, but I now have a much better understanding of their point of view.

At the end of the day, understanding those points of view is going to give you that shared commitment required to see a problem through to an effective a solution.

Well that is it for this series. I hope that you found it of some use and welcome any feedback. Since I am a trained, practicing and designated Dialogue Mapper, expect to see a lot more IBIS on CleverWorkarounds and Seven Sigma over the coming months.

Thanks for reading

Paul Culmsee

www.sevensigma.com.au

No Tags