For one night only USA…

Ah, Erica Toelle – what a legend! Thanks to Erica and Fpweb, I’m thrilled to confirm that the Seattle SharePoint Governance and Information Architecture class is all systems go. Save the date as its very likely indeed to be the only SPIA class in the USA in 2011.  If it wasn’t enough that Erica will be joining me, but Ruven Gotz will be there too.

Thursday and Friday, May 05-06, 2011. (http://spiaseattle.eventbrite.com/)

The location is the Silvercloud Inn, 14632 SE Eastgate Way Bellevue, WA 98004

In this multimedia extravaganza of a blog post, lets take a closer look at this class and what you can expect. Below is a snippet of a talk I did in New Zealand called “SharePoint Governance  Home Truths”. This clip shows a little diagnostic test that I do on my audience, to see whether they have experienced the visible signs of wicked problems. If you want to know why you should go to SPGov+IA, then take my 2 minute test yourself.

If the two minute test has taken your fancy, then you might want to see what is in store on the course itself. Below is the first half-hour of module 1 (in the form of a conference session), as well as the accompanying slide deck.

Course Information:

Download Course Outline (PDF)

Download Class Flyer (PDF)

Most people understand that deploying SharePoint is much more than getting it installed.  Despite this, current SharePoint governance documentation abounds in service delivery aspects. However, just because your system is rock-solid, stable, well-documented and governed through good process, there is absolutely no guarantee of success.  Similarly, if Information Architecture for SharePoint was as easy as putting together lists, libraries and metadata the right way, then why doesn’t Microsoft publish the obvious best practices?

In fact, the secret to a successful SharePoint project is an area that the governance documentation barely touches.

This Master Class pinpoints the critical success factors for SharePoint Governance and Information Architecture and rectifies this blind spot.  Paul Culmsee’s style takes an ironic and subversive view on how SharePoint Governance really works within organizations while presenting a model and the tools necessary to get it right.

Drawing on inspiration from many diverse sources, disciplines and case studies, Paul Culmsee has distilled the "what" and "how" of governance down to a simple and accessible, yet rigorous and comprehensive set of tools and methods that organizations, large and small, can utilize to achieve the level of commitment required to see SharePoint become a successful part of your enterprise.

Some workshop sessions are hands on, we provide all of the tools and samples needed but please bring your own laptop.

Course Structure:

The course is split into 7 modules, run across two days.

Module 1: SharePoint Governance f-Laws 1-17:

Module 1 is all about setting context in the form of clearing some misconceptions about the often muddy topic of SharePoint governance. This module sheds some light onto these less visible SharePoint governance factors in the form of Governance f-Laws, which will also help to provide the context for the rest of this course

• Why users don’t know what they want
• The danger of platitudes
• Why IT doesn’t get it
• The adaptive challenge – how to govern SharePoint for the hidden organisation
• The true forces of organisational chaos
• Wicked problems and how to spot them
• The myth of best practices and how to determine when a “practice” is really best

Module 2: The Shared Understanding Toolkit – part 1:

Module 2 pinpoints the SharePoint governance blind spot and introduces the Seven Sigma Shared Understanding Toolkit to counter it. The toolkit is a suite of tools, patterns and practices that can be used to improve SharePoint outcomes. This module builds upon the f-laws of module 1 and specifically examines the “what” and “why” questions of SharePoint Governance. Areas covered include how to identify particular types of problems, how to align the diverse goals of stakeholders, leverage problem structuring methods and constructing a solid business case.

Module 3: The Shared Understanding Toolkit – part 2:

Module 3 continues the Seven Sigma Shared Understanding Toolkit, and focuses on the foundation of “what” and “why” by examining the “who” and “how”. Areas covered include aligning stakeholder expectations, priorities and focus areas and building this alignment into a governance structure and written governance plan that actually make sense and that people will read. We round off by examining user engagement/stakeholder communication and training strategy.

Module 4: Information Architecture trends, lessons learned and key SharePoint challenges

Module 4 examines the hidden costs of poor information management practices, as well as some of the trends that are impacting on Information Architecture and the strategic direction of Microsoft as it develops the SharePoint road map. We will also examine the results from what other organisations have attempted and their lessons learned. We then distil those lessons learned into some the fundamental tenants of modern information architecture and finish off by examining the key SharePoint challenges from a technical, strategic and organisational viewpoint.

Module 5: Information organisation and facets of collaboration

Module 5 dives deeper into the core Information Architecture topics of information structure and organisation. We explore the various facets of enterprise collaboration and identify common Information Architecture mistakes and the strategies to avoid making them.

Module 6: Information Seeking, Search and metadata

Module 6 examines the factors that affect how users seek information and how they manifest in terms of patterns of use. Building upon the facets of collaboration of module 5, we examine several strategies to improving SharePoint search and navigation. We then turn our attention to taxonomy and metadata, and what SharePoint 2010 has to offer in terms of managed metadata

Module 7: Shared understanding and visual representation – documenting your Information Architecture

Module 7 returns to the theme of governance in the sense of communicating your information architecture through visual or written form. To achieve shared understanding among participants, we need to document our designs in various forms for various audiences.

Putting it all together: From vision to execution

Attendees will be taking home a manual ~480 pages, containing the Seven Sigma Shared Understanding Toolkit CD with a sample performance framework, governance plan, SharePoint ROI calculator (Spreadsheet), sample mind maps of Information Architecture. These tools are the result of years of continual development and refinement "out in the field" by Paul Culmsee and have only been recently released to the public through this Master Class.

More Information:

• Praise for SharePoint Governance and IA Masterclass

Refund Policy:

No refunds will be issued for attendee cancellations once payment is recieved.  Class cancellation by the organizer will result in a refund less transaction fees.

http://spiaseattle.eventbrite.com/

• The facets of collaboration Part 1–Meet robot barbie
• The facets of collaboration Part 2–Enter the matrix!
• The facets of collaboration Part 3-The feature jigsaw
• The facets of collaboration Part 4 – BPM vs. HPM

Hi all

Welcome to another exploration of the collaborative world through a lens called the facets of collaboration. If you are joining us for the first time, I am writing a series of posts that looks at how our perception of collaboration influences our penchant for certain collaborative tools and approaches. SharePoint, given that it is touted as a collaboration platform, inevitably results in consultants never being able to give a straight answer. This is because SharePoint is so feature-rich (and as a result caveat-rich), that there are always fifty different ways a situation can be approached. Add the fact that many clients do not necessarily know what they want and learn about their problem by examining potential solutions, we have all the hallmarks of a wicked problem in the making.

These wicked problems, underpinning SharePoint, often results in Robot Barbie situations (cue the image to the left), which is the metaphor that I started this series with. Robot Barbie represents everything wrong about SharePoint deployments, as it is symptomatic of throwing features at a platitude, pretending to be solving a real problem and then wondering why the result doesn’t gel at all. It is a pattern of behaviour that is similar to an observation made by the very wise (and profane) Ted Dziuba who once spoke these words of wisdom.

If there’s one thing all engineers love to do, it’s create APIs. It’s so awesome because you can draw on a white board and feel like you put in a good day’s work, despite having solved no real, actual problems. Web 2.0 engineers, in addition to their intrinsic love of APIs, have a real hard-on for anything having to do with a social network. For example, developing a Facebook application lets them call their shitty little PHP program an "application" running on a "platform," like a real, live computer programmer does. Make-believe time is so much fun, even for adults.

Apart from making me giggle, Dziuba may have a point. Elsewhere on this blog I have spent time explaining that there are different types of problems that require different approaches to solving them (wicked vs. tame). My conjecture is that collaboration itself is exactly the same in this regard. People who espouse a particular type of tool or approach as the utopian solution to collaboration are taking a one size fits all approach to a multifaceted area and even worse, treating that area as a platitude. Anyone who calls themselves an Information Architect and doesn’t at least give cursory examination to the dimensions or facets of collaboration is likely to be doing their stakeholders a disservice.

All of us have certain biases, and I am no exception. For a start, I am generation X – the so-called cynical generation. Apparently we whinge and whine about everything and then blame it all on generation-Y. Thus, if cynicism is the gen-X stereotype, then I will happily accept being the poster child. I mean seriously, all of you vanity obsessed, self interested generation y’ers, if you spend a little less time preening and more time thinking, we might get some wisdom out of you (see – I am such a cynical gen-X right now).

So let’s recap the facets of collaboration. The model I came up with identifies four major facets for collaborative work: Task, Trait, Social and Transactional.

• Task: Because the outcome drives the members’ attention and participation
• Trait: Because the interest drives the members’ attention and participation
• Transactional: Because the process drives the members’ attention and participation
• Social: Because the shared insight drives the members’ attention and participation

In the last post, I used the model to examine the notion of Business Process Management versus Human Process Management and looked at some of the claims and counter claims made by proponents of each. This time let’s up the ante and talk about something curlier. We will examine the notion that social networking in the enterprise is the answer to improving collaboration within the enterprise. On first thought, it makes perfect sense, given the incredible success of Facebook, LinkedIn and Twitter. Nevertheless, there is ongoing debate about the use and value of social tools in the enterprise driven by their rise outside of organisational contexts. One particularly strongly worded quote is from Aaron Fulkerson, co-founder and CEO of MindTouch who doesn’t mince his words:

This class of software forces business users to adopt the myopic social visions imagined by the developers, which are nearly identical to their corresponding consumer web implementations. In short, social software is not solving business problems. In fact, these applications only serve to treat symptoms of the problems businesses face. They exacerbate the real problems within businesses by creating distractions and, worse, proliferate more disconnected data and application silos.

Ouch! Even within the SharePoint community there is significant variation of opinions as to the value of social. While I better protect the innocent and not name names, I have spoken with several well known SharePointers who think social is a giant waste of time, versus those who see real value in it. Irrespective of your opinion, you cannot ignore the fact that social is a significant game changer with effects still being felt. While web 2.0 has dropped off the Gartner hype cycle, its effect on particular sectors has been far reaching. Now it seems that all sectors have a 2.0 on the end of their name. For example:

• Enterprise 2.0
• Education 2.0
• Legal 2.0
• Government 2.0

Clearly, if things were just a flash in the pan, why are governments around the world trying to revitalise their public sector by utilising these tools?

Look at Microsoft as another example. They have, I think smartly, recognised industry trends and reacted to them via the introduction of a number of new SharePoint features, such as tagging/folksonomy via managed metadata, ratings columns, enhanced wiki capabilities and a significant investment in the capabilities of my-sites. Their clients now have the option to leverage these features should they choose to do so.

So just as there are naysayers, there are the pundits. Many people cite the reasoning that these features are necessary to attract and retain the next generation of workers, who have grown up with these tools in their personal lives. Whether this claim is valid is debatable, but I have to say, I really like the Enterprise 2.0 slide deck below by Scott Gavin for a number of reasons. I think it encapsulates the 2.0 vision, underpinned by social/cloud technologies very nicely. I sometimes ask people to discuss this slide deck in my IA classes and discussion is equally polarising as social networking in the enterprise itself. Some people think it represents the vision for the future, and others think it is hopelessly idealistic and doesn’t reflect cold, hard reality. Take a look for yourself below…

And the survey says…

Using the facets quadrants, we can start to see patterns for success of these tools for the enterprise and whether Aaron Fulkerson’s argument has merit or whether Scott Gavin is on the right track. An interesting use of the facet diagram is to plot where various tools and technologies are located. in my classes, I ask people to plot where Facebook belongs on facets diagram. Guess where it is usually drawn? 

While some people will draw Facebook at various levels on the vertical axis, everyone pretty much describes Facebook (and LinkedIn)  as trait based, while being highly dominant on the social quadrant. As discussed in the last article, if I ask people to plot a crowdsourced tool like Wikipedia, the dominant characteristic is always trait/social. In other words, people maintain and update Wikipedia articles because of their interest in the topic area, not because it helps them get something done.

Clearly, big social networking technologies are successful in the "trait based social” quadrant. In other words, we tend to use Facebook more for common interest collaboration than to solve a task based collaborative issue (such as deliver a project). Another interesting thing about a lot of social networking technologies is that for many, our work-based collaborative life tends to be more task based, compared to our non-work which is more trait based. In other words, for a lot of us, our work life revolves around working with a group of people for a common outcome and if it was not for that common outcome, we wouldn’t necessarily have much in common (I risk falling victim to my own generalisation here – so I will come back to this later in the section titled “Why User Buy-In Is Hard”).

When you look at where Facebook sits in the quadrant, it begs the question of how well this type of tool (or the building blocks it is based on) would work in an organisation that is project (task) based and highly transactional. To that end, consider a project management information system, such as the basic one that Dux espouses in his book or the more complex one that Microsoft sell to organisations. Where do you think it belongs on the quadrant?

When I ask people to plot their project management information system, I typically get this response:

I speculate that the further away two tools lie on the spectrum, the more likely we are to have a robot-barbie solution if you blindly mix features that work well in each individual quadrant. The wiki argument I made in part 3 seems to support this contention. If you recall, in part 3 of this series, I mentioned that I ask every attendee of my classes if they had ever seen a successful project management wiki.  Irrespective of the location of the class, the answer was pretty much “no”. I noted that where I had seen successful wikis tended to be where the users of the wiki were linked by strong traits.

Looking Deeper

While that is interesting, I think the facets diagram tells you more than it intends. Obviously, it is clear that these project management systems such as MS Project Server are oriented toward task/transactional (“getting things done”) aspect of project delivery (ie, time, cost, scope, budget and the like). While some people might point to this and say “there you go – I told you all that social crap was a waste of time – bloody gen-Y and their social networking hubris”, I feel this is naive. If task based transactional tools are sufficient, then why do so many projects fail?

I have stated many times on this blog that shared commitment to a course of action requires shared understanding of the problem at hand. The act of aligning a team to project goals and developing this shared understanding is the realm of the task/social quadrant (the top left), where insights and outcomes come together. When I ask people to name tools that live in this space, few can name anything. Obviously, most project management systems are devoid here. Worst still, we subsequently delude ourselves to thinking that shared understanding can come from a few platitudinal paragraphs labelled as a “problem statement”.

Social networking pundits implicitly recognise this issue (and frequently butt heads against command and control type project managers as a result). But i feel they make the mistake in applying a one size fits all approach to collaboration and apply trait based tools as a panacea when they are not wholly appropriate. The social tools seem to fit exceptionally well into the top right quadrant, but not in the top left.

In fact the only tools that spring to mind that belong in the top left category are the sensemaking tools that my company practice, such as Dialogue Mapping.

Where’s the proof, Paul?

So I guess I am arguing that using social tools because they are the “choice of the new generation” ignores a few home truths about the nature of these tools versus the nature of organisational life. Just because Microsoft provide the tools for you, tells you that they are hedging their bets rather than having any more insight than you or me. So to test all of this, let’s use the facets model in a different way to back up some of my observations and suggestions in this post. Guess what happens when I ask people to plot SharePoint itself on the facets map?

When I asked SharePoint practitioners to do this, they initially drew SharePoint 2007 as a circle over the entire model. Once they did so, they would very often adjust the drawing to emphasise transactional over social collaboration as shown below.

When practitioners were asked to draw SharePoint 2010, they usually indicated a higher representation in in the two social quadrants, but favoured the trait based social over task based social as shown below.

What was interesting about this experiment is that very few people drew SharePoint over the entire facets of collaboration. Social collaboration with SharePoint it seems, only stretches so far. This leads me onto more conjecture, and now we get to the bit in the post where we name a giant SharePoint elephant in the room.

Structured tools for social collaboration?

Many collaborative tools purport themselves as operating in the social space. SharePoint 2010 clearly does so, principally due to the Managed Metadata service, pimped MySites with tagging/rating capabilities. But SharePoint’s core heritage is database/metadata driven, document based collaboration. If we go back to our definition of social collaboration as dynamic, unstructured, with sharing of perspectives and insight through pattern sensing, then social collaboration is clearly not a predefined interaction.

Yet, database driven tools like SharePoint, and its building blocks like site columns and content types require considerable up-front planning to install and govern. Many, many inputs need to be well defined and furthermore, unless you have learnt through living the pain of things like content type definitions in declarative CAML, SharePoint buildings blocks are difficult to maintain/change over time. SharePoint suffers from a problem of reduced resiliency over time in that the more you customise it to suit your ends, the less flexible it gets. In the case of social collaboration the problem is worse because we are trying design for outputs where the inputs are not controlled. Trying to turn something that is inherently organic and emergent to something that has an X and Y on it may be misfocused and destined to fail in many circumstances. The realm of well-defined inputs is the realm of transactional collaboration, where workflow and business process management thrive and change is much more controlled before SharePoint ever gets a look in.

SharePoint excels at transactional scenarios as this is its heritage – after all, the majority of its feature set is oriented to transactional collaboration. The fact that people are prepared to draw SharePoint as dominating across across the transactional half of the facets diagram illustrates this.

But this raises interesting, if not slightly heretical question. If we need to use information architects to get a collaborative tool deployed for social collaboration (to get those inputs defined), then are we pushing the solution into the transactional side of the fence? Recall that in part 3 of this series, I looked at document collaboration and noted that when asked to draw team based document collaboration, people typically drew it operating in the social half of the matrix (pasted below for reference). I also noted in part 3 that for team based collaboration, rules and process are much less rigid or formalised with regards to document use and structure. I then referred to a recent NothingbutSharePoint article where a large organisation’s attempts to introduce the usage of content types largely failed. Like the seeming lack of success of wiki’s for task based collaboration, maybe content types simply are not the ideal construct as you move up the Y axis from transactional to social?

Now do not assume that I am anti metadata/content types here as this is not the case at all. Content types rock when it comes to search and surfacing of related information across a site collection (and beyond if you use search web parts). What I am calling out is the fact that if the SharePoint constructs that we have at our disposal were the panacea for social collaboration, where are the best practices that tell us how to leverage them for success? Perhaps the nature of the collaboration taking place plays a part in the lack of take-up reported in the aforementioned article? Those who advocate highly structured metadata as the only true solution may in fact be pushing a transactional paradigm onto a collaborative model that is ill-suited to it?

The knowledge worker paradox – one of the reasons why user buy-in is hard

Finally for now I’d like to cover one more aspect to this issue. Last year, one of my students looked at the facets and said “Now I know why my users aren’t seeing the value that I see in SharePoint”. When I asked him why, he explained:

“Many of my users are transactional and governed by process – that’s their KPI. Here I am as a knowledge worker, seeing all of these great collaborative features, but I am not judged by a process or transaction. I don’t live in that world. I forget that someone whose performance is judged by process consistency is not going to get all excited by a wiki or tagging or a blog.”

I call this the knowledge worker paradox and it is reminiscent of what I said in part 4 where we looked at BPM vs. HPM. Each role on an organisation is multifaceted. For many roles, there is varying degrees of transactional work taking place. Accordingly some people are very much process driven just as much as they are social driven. Gross generalisations that make statements that “80% of people are knowledge workers or perform knowledge work” do not help matters. In fact they serve to feed the one size fits all mentality that has proven to be detrimental to projects when people fail to recognise that some projects have wicked aspects.

SharePoint people are almost always knowledge workers. Thus if you, as a knowledge worker who is rarely governed by transactional process, think that you have the vision to prescribe a SharePoint driven meta-utopia to meet transactional needs without having lived that world, then if your results are not what you hoped for then to me its hardly surprising.  My student in this case realised that he had been approaching his user base the wrong way. Like Jane in part 1, he did not take into account the dominant facets of collaboration for the roles that he was trying to sell SharePoint into.

When you think about it, the whole argument around records management versus collaborative document management is in effect, an argument between a transactional oriented approach, versus a social oriented one. It is the same pattern as BPM vs. HPM. In records management, the paradigm is that management of the record is more important than the content of the record. Furthermore, that record shouldn’t change. Yet with team based document collaboration, without content there is no document as such and furthermore, the document will change frequently and require less strict controls to grease the gears of collaboration.

Both records oriented people and social pundits commonly make the same mistake of my student, where they force their dominant paradigm on everyone else.

Conclusion

Food for thought, eh?

This is probably my last facets of collaboration post for a while. It is one of these series of articles that I feel has value, but I know it won’t be read by too many 🙂 Nevertheless, I do hope that anyone who has gotten this far through has gotten some value from this examination and sees value in the model to help users make more informed Information Architecture decisions for SharePoint and beyond. I certainly use it now in most engagements and hope that it can be improved upon as a tool, or somehow incorporated into some of the SharePoint standards or maturity model stuff that is out there.

Remember the most important thing of all though. Despite all I have said, it is still definitely all generation y’s fault!

Thanks for reading

Paul Culmsee

www.sevensigma.com.au

• The facets of collaboration Part 1–Meet robot barbie
• The facets of collaboration Part 2–Enter the matrix!
• The facets of collaboration Part 3-The feature jigsaw
• The facets of collaboration Part 4 – BPM vs. HPM
• The facets of collaboration Part 5 – It’s all Gen-Y’s fault – or is it?

Hi all and welcome to part four of my series on unpacking this buzzword phenomenon that is “collaboration”. Like it or not, Collaboration is a word that is very in-vogue right now. I see it being used all over the place, particularly as a by-product of the success of x2.0 tools and technologies. Yet if you do your research, most of the values being espoused actually hark back to the 1950’s and even earlier. (More on that topic in my forthcoming Beyond Best Practices book).

As it happens, Dilbert is quite a useful buzzword KPI. Once a buzzword graces a Scott Adams cartoon, you know that it has officially made it – as shown below:

So back to business! Way back in the first article, I introduced you to Robot Barbie, a metaphor that represents all of those horrid SharePoint sites remind you of a cross-dressing Frankenstein’s monster. I had an early experience with a client who championed a particular vision for a SharePoint project, only to find little buy-in within the organisation for that vision. This, and a bunch of other things, got me interested in the softer areas of SharePoint governance, where no tried and tested best practices really exist. If they did and were so obvious, Microsoft would published them as its in their interest to do so.

This all culminated in when I wrote a SharePoint Governance and Information Architecture training course last year. I read a lot of material where authors attempted to unpack what collaboration actually meant. My rationale for doing so would be to hopefully avoid creating SharePoint solutions that were Robot-Barbie Frankensteins. The model that I came up with is illustrated below:

The basic model is covered in detail in part 2. But to recap here is the basic summary: This model identifies four major facets for collaborative work: Task, Trait, Social and Transactional.

• Task: Because the outcome drives the members’ attention and participation
• Trait: Because the interest drives the members’ attention and participation
• Transactional: Because the process drives the members’ attention and participation
• Social: Because the shared insight drives the members’ attention and participation

In the last post, I used the model to compare and contrast the use of particular SharePoint features, such as wikis, SharePoint lists and the different aspects of document collaboration. With regards to the latter of these three, I l looked at the effectiveness of certain SharePoint building blocks like content types and site columns within the different facets.

In this post and the next, we will use the facets in a different manner. We will take a quick tour through some common philosophical smackdowns that manifest in organisational life. These smackdowns emanate because of the different viewpoints that people with particular job titles and respective bodies of knowledge have.

Any suggestion that a philosophy might be wrong or incomplete often calls into question the self-identify of the practitioner, which causes much angst among adherents. For this reason, I will leave the “agile is great” vs. “agile sucks” debate for another time, because if you search the internet for criticisms of agile you tend see really passionate programmers get all riled up and flame the hell out of you.

Instead, I will start with a relatively easy one…

Business Process Management v.s. Human Process Management

What does painting the Golden Gate Bridge and Business Process Management have in common? With both, you find that by the time you get to the end, you need to go back to the beginning again. I have personally seen organisations fill an office full of people and take literally years to define and then document key processes all in the name of various best practice frameworks or a regulatory requirement. They then find that, once a thick process manual is created, no-one actually follows it unless an auditor is watching or their performance-based remuneration is directly measured by adherence to it. Of course, I’m not the only one to notice this. In fact, the entire discipline of business process management has taken a bit of a battering in recent years.

If we consider a “process” as the means by which we convert inputs of some description into outputs, Business Process Management has long been the discipline that concerns itself with process optimisation. But in a pattern that is seen in all disciplines like Project Management and Business Analysis, someone will inevitably come along, tell you that you have it wrong or are not being “holistic” and invent a new term to account for your wrongness. In the case of BPM, we now have people arguing for various terms: such as Human Interaction Management, Human Centric Business Process Management, Non-Linear Business Process (thanks Sadie!) or Human Process Management. We will use the latter term, but they are essentially talking about the same thing.

So before we see an example Human Process Management (HPM), let’s review Business Process Management and see what the HPM fanboys are whining about.

Business Process Management

BPM is a structured approach to analyse and continually improve and optimise process activities. Process structure and flow are modelled via diagrammatic tools, allowing organizations to abstract business process from technology infrastructure and organisational departmental/jurisdictional boundaries. This abstracted view allows business to holistically examine process and increase their efficiency and respond rapidly to changing circumstances. This in turn creates competitive advantage.

BPM is often used within the broader context of process improvement methodologies such as Six Sigma (which if you have never read about it, will finally prove to you that all that high-school mathematics that you found mind-numbingly boring was actually useful). While BPM on its own provides excellent visibility of process via modelling them, Six Sigma also incorporates additional analytical tools to solve difficult and complex process problems. Thus, BPM and Six Sigma augment each-other, because process improvement efforts can be more focused via BPM modelling. Thomas Gomez, in an article entitled “The Marriage of BPM and Six Sigma", had the following to say:

“Without BPM, Six Sigma may flounder because executives lack the critical data needed to focus their efforts. Instead, the executives bounce all over the place looking for performance weaknesses, or they focus on areas where successful performance improvements provide only marginal results. With BPM, Six Sigma projects can pinpoint problems and address the underlying causes.”

But that is where the fun ends according to the BPM critics. BPM nerds have had to suffer the indignation of hurtful labels like “Sick Sigma” and stories of long term problems with innovation because of such initiatives. They cite examples such as  George Buckley of 3M, who wound back many of his predecessor’s Six Sigma initiatives.

"Invention is by its very nature a disorderly process. You can’t put a Six Sigma process into that area and say, well, I’m getting behind on invention, so I’m going to schedule myself for three good ideas on Wednesday and two on Friday. That’s NOT how creativity works."

Ouch! Its enough to make a BPM feel all flustered and defensive of their craft. Nevertheless the above quote echoes the main points made by BPM critics. That many processes are not structured, predictable or logical and therefore, BPM approaches force a structured paradigm when none necessarily exists (Mind you, many other methodologies do precisely the same). In an appropriately titled article “The H-Bomb of Business Processes: Humans”, Ayal Steiner makes a point that also cuts to the heart of tame vs wicked problems debate too.

“The modern idea of BPM stresses a well-defined business process as the starting point but this is not always the case. Therefore, in a project that involves new practices or a cross-functional learning among participants, BPM has always had a tough time dealing with the humans.”

The notion of the well-defined starting or ending point is one of the characteristics of a tame problem. Wicked problems are often characterised by poorly defined staring and ending points. In fact with a wicked problem, often participants cannot agree on what the problem is in the first place!

Critics like Steiner also argue that many roles within an organisation, tend to deal with more tacit, dynamic situations and as such spend a large amount of their work time performing collaborative human work, when compared to transactional business process work (knowledge workers is the prevailing label for this type of role). While the main area of benefit for BPM’s is its ability to increase the efficiency of a core business process, the sort of thinking required to re-think processes in a systematic manner involves collaboration and systems thinking (in other words, beyond the process in front of us and how it interacts and interrelates more broadly since the whole of the broader system is greater than the sum of its parts). This is a human-driven activity as it is based on humans collaborating and innovating.

Closer to SharePoint home, Sadie Van Buren noted this same distinction in May 2010 which was around the same time I started the development of my IA class.

Human Process Management

So if BPM is incomplete, enter Human Process Management (HPM). HPM is concerned with process that is not easily defined, nor well structured, where it is hard to prescribe the execution of the process based on some model of the business. With human process, it is generally known how to achieve an intended result, but each case is handled separately and requires tacit judgment (for both decisions and flow) as part of the process. There is not enough standardization between instances of the process that allows for a formal, complete and rigorous description of the process end-to-end.

The obvious downside of human processes, say the critics, is that they are far too fluid and dynamic to be made part of an Enterprise BPM system. As a result, these processes tend to be handled through email, which in turn contributes to information overload and poor information worker productivity – precisely why we look to tools like SharePoint in the first place! The implication of HPM is that we need to shift emphasis to tools and practices that help us deal with unstructured or ad-hoc processes (and the information created/used during that process) more so than tools that deal with the well-defined world of BPM.

To be fair to the BPM crowd, these above criticisms will be seen by BPM practitioners as naive, since from their point of view, the less structured side is simply a part of the entire BPM spectrum. They argue that critics do not properly understand the principles and philosophy of BPM in the first place (Agile and PMBOK defenders say essentially the same thing when defending from critics). Supporting this counterargument is a key theme for BPM success that is regularly emphasised. That is, the critical pre-requisite of clarity of purpose and shared understanding of the end in mind. Mohamed Zairi, in a paper called “Business process management: a boundaryless approach to modern competitiveness” stated:

“The achievement of a BPM culture depends very much on the establishment of total alignment to corporate goals and having every employee’s efforts focused on adding value to the end customer.”

Therefore the BPM crowd are arguing for the same human process that HPM base their criticism on. Developing a culture of alignment to corporate goals is very much a human process. Are the HPM fanboy criticisms well founded or is it more a case that some BPM guys forget about strategic goal alignment and optimise process in isolation?

What do the facets say?

Clearly, there is a natural tension between these two polarities of BPM and HPM and this often plays out in organisational life in how we collaborate to deliver organisational outcomes. While there have always been process nazis, the emergence of social collaboration platforms that do not have a great deal of formal structure (think tagging and folksonomies) has led to a great deal of debate and self examination in BPM circles and beyond. Understanding these traits is critically important on the use of SharePoint tools, because SharePoint – and in particular SP2010 offers features for both BPM and HPM aficionados. Putting the two together however might risk Robot Barbie scenarios.

Straight away, it seems that the transactional vs. social axis of the facets of collaboration neatly explain the Business Process Management (BPM)/Human Process Management (HPM) challenge. Both areas are concerned with producing an output or getting something done. Therefore I have drawn BPM and HPM leaning toward the task side of the model. HPM proponents argue that human process is unstructured or semi-structured, dynamic, intertwined and borderless, which fits in well with the task/social trait of process and insight. BPM naturally fits into the lower transactional half where inputs are well defined.

While I would agree with the assertion that many processes are ill-defined and rely on tacit knowledge to be completed, HPM proponents go further though. For example, Ayal Steiner who I quoted earlier, argues that “analysts are now realising that human processes account for 80% of the business processes carried out in most organisations”. That is a big call, in effect, arguing that the majority of workplace interactions occupy the social quadrants above. I disagree. From my experience, most organisational roles have extremely varying degrees of transactional vs. social collaboration and some roles are in fact dominated by transactional collaboration. Perhaps there is some confirmation bias going on here, where knowledge workers who put in collaborative systems tend to think that everyone are knowledge workers too.

Here is an example. Mrs CleverWorkarounds used to be a medical nurse. When I first showed her this model I asked her to describe where nurses would fit in terms of their collaboration. She indicated two areas.

• Firstly, nurses are strongly linked by trait and transaction. This is because they all have a minimum degree of knowledge and skill. As stated in part 2, the key tell-tale sign of a role with transactional collaboration is how easily individuals performing that role can be replaced by someone else with similar experience at short notice. Supporting this, if a nurse is sick or unavailable, a replacement nurse can be called in to perform the same tasks.  Collaboration between nurses according to Mrs Cleverworkarounds is quite transactional as well. Routine and process consistency via tracking the status of patient care is a critical task – patient status is everything. Thus, data driven tools with version history and well defined inputs make this form of collaboration easier. In fact, Mrs CleverWorkarounds taught herself InfoPath and SPD Workflows because she was so convinced that automated forms with consistent audit trails via workflow would make her job easier.
• Yet at the same time, the sort of collaboration between nurses and patients is completely different and highly social in nature. No process is going to govern the interaction between nurse and patient. The type of care and counselling to get someone well is going to vary the type of interaction. A broken leg is one thing, health problems from say – alcoholism is something else entirely. The latter has much deeper symptoms than just the illness as presented. Here the focus is on patient well-being and goes beyond status of meds, when doctors have visited or accurate handover notes from one nursing shift to another.

State machine workflows?

Interestingly, even seemingly well-defined business processes tend to have ad-hoc and dynamic aspects to them. When there is an exception to the standard process, those exceptions tend to be handled in a relatively ad-hoc, case-by-case manner. Microsoft developer Pravin Indurkar cited an example of a seemingly transactional purchase ordering system.

“Often the business processes contain a prescribed path to the end goal but then there are a lot of alternate ways the same goal can be achieved. For example, a purchase order can contain a prescribed path where the PO goes from being created, to approved, to shipped, and then to completed. But then there a multitude of other ways in which the PO can be completed. The PO can get changed, or back ordered or cancelled and then Reopened. All these paths must be accounted for.”

Indurkar studied the purchase order system of a small business and found that apart from the one standard traditional order fulfilment process, there were about 65 different variations on the same process depending on the nature of the order. This is when BPM diagrams start to get scary. If you think that this workflow below is scary, then be more scared. It is page 12 of a 136 page process!

Naturally, trying to hardwire such a large number of alternate paths is very difficult and traditionally, there were two ways in which this was dealt with;

• Either the business process was hard wired to accommodate all the paths as shown in figure 1, which made the implementation of the business process extremely complex, brittle and hard to maintain.
• The alternate paths are simply not dealt with and any situation of the ordinary was dealt outside the domain of the process. This meant that tracking and visibility were lost because people would create manual systems to track such out of the ordinary situations. The facet diagram below illustrates this:

In Indurkar’s article that I quoted with the purchase order example, he argued that the solution to this sort of problem was via state-based or state-machine workflows which SharePoint has supported in a basic fashion, out of the box since SP2007. This kind of workflow, if you are not aware, is when the workflow waits for one or more events to move it into another state. There is no sequence as such, because this new target state can be any of the defined states in the workflow. This makes state workflows reflect the unpredictable nature of process variations.

Thus, it could be argued that BPM is not incomplete as what the HPM fanboys think, but that critics have a less than holistic understanding of the craft?

Conclusion: A Process Analysis Tool…

To be honest, I don’t want to answer the question of which fanboy is right because it is a bit of a zero sum game. When you think about process, many seem to have elements of transactional and social in them (just like job roles). For example, an “Approval” decision diamond in a business process diagram will determine the path a process takes. Apart from stating the fact that this process is a gateway where a decision is made, this says nothing about whether the activity of making that decision is transactional or social. In some processes the decision may be made by a rigorous data driven process (like a point-score based credit check for a loan applicant). In others it may be on gut feel (such as choosing the right applicant for a job position).

So to me, whether you are the most regimented process nazi or the most cowboyish non-conformist hippie, modelling a business process according to its ratio of transactional to social facets is probably very useful indeed to complement a BPM model. It help us understand how much tacit judgement is required in a given process and whether modelling every variation in a sequential workflow is worthwhile. Check out some examples on how this could be done below. In first example on the left, a business process where the majority of the steps are performed by tacit judgement might look like something like how I have drawn, with a task based social dominance. If the process in question indeed looks like this, then attempting to document every minute variation on the paths the process can take might not be worthwhile. Perhaps documenting the broad process (within the constraints of any compliance regime requirements) might be a better idea. In the second example, the process seems to be oriented around a repeatable set of choices (task based transactional dominant). As a result it may be worthwhile formally documenting these variations.

By combining these “process diagnostics” with the actual diagram, we might now offer additional insights into how the organisation really works with a certain process and do crazy stuff like produce something akin to my mockup below:

Hell, throw in a RACI chart and now you start to see process accountabilities as well!

Of course, you could always remove the task/trait axis if it is not needed and simply use a sliding scale. Nevertheless, what this shows is that the facets of collaboration model offers an extra dimension to any process being modelled and would help many to better understand the nature of the process being modelled, as well as strategies for improving that process via SharePoint.

Thanks for reading

Paul Culmsee

www.sevensigma.com.au

p.s If you are a real trainspotter/glutton for punishment and want to dive deeper, google “Human Interaction Management” and “Role Activity Diagrams”

• The facets of collaboration Part 1–Meet robot barbie
• The facets of collaboration Part 2–Enter the matrix!
• The facets of collaboration Part 3-The feature jigsaw
• The facets of collaboration Part 4 – BPM vs. HPM
• The facets of collaboration Part 5 – It’s all Gen-Y’s fault – or is it?

Hi all

In my first post in this series, I introduced you “Jane” and a true story about her missteps when implementing popular social networking technologies within her organisation. We then asked some deep and ponderous questions, before meeting Robot Barbie and the crazy world of SharePoint Robot Barbie solutions. Finally I outlined a simple mental model that I developed that I have found to be quite a useful method to look at collaboration more holistically and help with the user engagement and information architecture aspects of SharePoint governance.

Now before we start, I want to make a four points to pre-empt the type of replies that I anticipate from putting this model out there.

1. Kailash once told me that the problem with models is that their creators fall in love with them. They forget that they exist to help us to understand the reality around us, but this doesn’t make them reality. For that reason, I do not love my model and see lots of flaws. I also look forward to seeing better ones that people come up with. The key point is this: No model can ever capture the total sum of variables combine to make a collaborative situation look or feel a certain way, all it can do is approximate. This is my attempt at approximation.
2. Imagine watching the Matrix movies without the car chases or kung-fu. It would be long, full of nonsensical dialogue and you would come out saying “I have no idea was that all about”. Mental models are a little like that too. This model is designed to be simple and explainable within 2 minutes. Any concept that takes more than a beer to explain will forever be in the realm of academia and get little real-world use.
3. Some people (particularly scientist types), will look at a matrix like mine and automatically think that is measuring something. This is because there is an X and Y axis and usually, their presence indicates two variables that can have a range of values. In my case though, I was not thinking about an axis in that way. I just saw that each of the facets identified (task vs trait and social vs transactional) seem to me to be the extreme ends of an axis that I as yet, have not worked out :-). The point is, matrixes don’t always work for these people and they tend to avoid drawing quadrants with explicit lines because of the implicit suggestion that a situation falls into one quadrant or another. If you are of this persuasion feel free to develop it in a way that works for you. I think when we hit part 3, you will see that I use the model in different ways.
4. Remember that this model is about collaboration. By definition, this involves more than 1 person. I was not thinking of individual people when putting it together. It assumes a bunch of people interacting and each facet I guess, highlights a dominant collaborative trait.

So let’s examine each facet in turn

Task Based Collaboration (Outcome driven)

Task based collaboration is typically characterised by short(ish)-term groups, comprised of people with a shared goal or common outcome (i.e. a "project”). The membership of a task based group is typically fairly diverse because it is the outcome drives the members’ attention and participation. Members are chosen because of their ability to play a part in achieving the outcome and it is not necessarily true that they have a say in that outcome.

The dominant characteristic of a task based collaborative group is that members do not necessarily have shared interests beyond the outcome being delivered. A SharePoint project team is a good example of this, because of the multidisciplinary skill set required to deliver it. Outside of that project, people may have vastly different interests and skills, and may have nothing in common beyond the outcome being sought. Some organisations are like this, where the people you work with you do not necessarily have any social interaction with beyond the interactions required to get the job done.

When you look at the matrix below, the top and bottom left quadrants are therefore driven by outcome. (i.e. getting something done).

Trait Based Collaboration (Interest Driven)

Trait based collaboration is comprised of users who are related through shared traits or long-term interests. As I stated in the first post, members may not be consciously collaborating on the same task or outcome, but may be highly likely to repeat or augment tasks already accomplished by other group members. Therefore, trait based groups tend to come together to share their learning and experiences. It is the shared interest that drives the members’ attention and participation. There is no deadline as such, or a specific task being shared among the group.

Examples of trait based groups are special interest groups (fans of a particular musical group) and occupational groups (via job role or even department). When you think about it, Facebook is the mother of all trait based collaborative platforms because members almost overwhelmingly are there connect with people who have a shared trait of some fashion. Also consider a community driven site like NothingButSharePoint or a conference such as SharePoint Best Practices. Both are excellent examples of trait based collaborative scenarios. We use these collaborative environments to gain insight and learning from sharing experiences with like-minded individuals.

When you look at the matrix below, the top and bottom right quadrants are therefore driven by interest.

Transactional Based Collaboration (Process Driven)

Transactional collaboration takes the form of a business process where various people or groups interact to get something done. In this scenario, inputs and outputs are fairly well defined and the process is repetitive by nature. Think of airport baggage handling as a great example. This is a process that has to be run efficiently and consistently. As a traveller, I want baggage handlers to be making sure my suitcase is on the right flight. I don’t want them all sitting on say, Yammer or MSN to co-ordinate the delivery of baggage. But I sure as tell want them to be able to tell me the status of my bag pretty much instantly.

One interesting characteristic of transactional based collaboration is that the people in the process can often be “swapped out” with other people, because transactional process is designed to be well defined, optimised and easy to follow consistently. It is the process that drives the members’ attention and participation, and governs the interaction between participants.

As stated in part 1, another characteristic of transactional collaboration is that it is usually not a place of spontaneity. Consistency is key to success and processes are designed to run with a minimum of variation and margin for error. As a result, this is the sort of stuff that well defined business rules, metadata and rule-based workflows handle well.

When you look at the matrix below, the left and right bottom quadrants are therefore driven by the process that governs the collaboration.

Social Based Collaboration (Insight Driven)

Social based collaboration is an interesting one. Truth be told, I knew that this one would have the greatest connotations because of the wildly different interpretations of the word social. From the point of view of my model, I offer the following explanation.

Social collaboration is the other extreme of transactional. This is usually characterised by more ad-hoc sharing of perspectives and information. It is realisation or insight through pattern sensing via group interaction, rather than structured business rules. It looks beyond the process and attempts to get to the ‘big picture’ of an issue, problem or constellation of problems.

Therefore social collaboration cannot really be a predefined interaction in the transactional sense. It is not a structured workflow, a rule or something with well defined inputs. But it is the place where tacit knowledge creation, development and exchange typically occurs. It is where hard decisions sometimes have to be made and where innovation tends to come from because it is the shared insight that drives the members’ attention and participation. It is the world of wisdom of the crowds – collaboration in all its messy glory.

As a simple example of what I mean, even the best business process modelling guru will never be able to document the process a board of directors would go through when performing strategic decision making. If for example, someone worked out the business process diagram that would tell any organization how to develop the next iPod or to master the stock market, then we wouldn’t marvel at Steve Jobs sixth sense for product delivery or Warren Buffets ability to consistently out-perform the market.

Therefore in the matrix below, the two top quadrants are therefore driven by the insight gained from the collaboration.

To Summarise

Hopefully after that explanation, each of the quadrants start to make more sense. The facets of collaboration can be summarised as follows:

• Task: Because the outcome drives the members’ attention and participation
• Trait: Because the interest drives the members’ attention and participation
• Transactional: Because the process drives the members’ attention and participation
• Social: Because the shared insight drives the members’ attention and participation

In the next post, we will use this simple model to examine several common scenarios and see what insight we can glean from looking at collaborative tools and situations through this lens.

Thanks for reading

Paul Culmsee

www.sevensigma.com.au

Michal Pisarek wrote a nice write-up of what makes a good SharePoint Analyst. I feel I have something to offer here, given that I…

1. am a cynical old bastard
2. am an opinionated old bastard
3. have had some opportunities that not too many SharePoint people have had
4. wrote this post on a plane while suffering jetlag 🙂

I am going to argue that as a SharePoint ”analyst”, the worst thing you can do is act like an analyst.

I previously wrote about the identity crisis that Business Analysts have which became apparent to me when I spoke at a BA World Conference last year. The gist of my point in that post came from my observations of a panel discussion on role of a BA within Agile development. I noted that the whole discussion seemed based on an underlying presumption that the role of the BA was to translate between IT and “the business". Agile by its very nature, shifts the ground out from under this assumption which caused a bit of consternation on the part of the panel. My takeaway from this, was that a role does not define the person. The body of knowledge of your discipline (in this case BABOK) is not the one truth. When you think about it, the body of knowledge by definition, consists of the lowest common denominators of a discipline of knowledge – a starting point. This is because the skills that you have built are your skills. Sure, you can write about them, but that only conveys a small dimension of what your skills entail.

Essentially, if everybody followed the BOK as the source of the truth then all consultancies would look the same. (Thinking about it, now you know why all large and expensive management consulting firms tend to sound the same…hehehe 🙂 )

The point is that it is the knowledge that you have earned that makes you what you are and what customers want. Knowledge comes from making mistakes, not by confirming your rightness. Therefore, people who practise constant learning by trying things out, challenging their models of reality, always build a hugely valuable corpus of tacit knowledge that is locked up in their brain where knowledge is connected and related in ways that form insight. It is because of this unique insight, that customers rarely want a “Business Analyst”.  They want Joe or Bob because of what Joe or Bob, as individuals, bring to the table. (Kailash writes about this in more detail if I am leaving you scratching your head at this point. I am going to quote him in a reply to Richard Harbridge).

The point I would like to emphasise, however, is that best practices cannot capture tacit knowledge. Codified best practices (or standards) are therefore necessarily incomplete. One of the things standards don’t tell you is how you should “practice the practice”. Practices have to be customised or adapted to specific organisational contexts before they can be practiced. The process of customisation invariably involves the creation of tacit knowledge to fill in the missing bits. This is why I used the word “rediscover” to describe this process, rather than “customise” (or “adapt”) : the former gives a better sense for the magnitude and type of effort involved whereas the latter suggests that minor tinkering will do the job (which it won’t).

So, here is a tip. Don’t define your own wellbeing by a role title or adherence to a body of knowledge because, if you do, you will inevitable have an identity crisis. The world simply moves on and with it, the problems that people are trying to solve tend to wriggle out of the domain of any single BOK. Any attempts to resist this will eventually become dogma and then we have “memetic smackdowns” as I describe in this EUSP Post.

Okay, so now that I have finished a mini rant, I’d like to address the whole “analyst” thing. Don’t get me wrong – it’s not the title of the role I am going to talk about here, but the analyst paradigm itself. That is, the notion that my purpose in life is to take some requirements, go to a back room, spend time “processing” and “synthesising” those requirements, translating away between "IT and “the business”, before formulating a solution for the customer.

This does not work well with most SharePoint projects! Especially ones that seek to “improve collaboration”.

Many people fail to see why this is the case, yet given the huge gap between the SharePoint that Microsoft shows you versus what you see on the ground, you would think that it would be kind of obvious. For what it’s worth, understanding why the analyst paradigm is dangerous also neatly explains why IT is generically predisposed to struggling with SharePoint.

Consider the following projects:

• Implementing Microsoft Exchange for a global organisation
• Implementing Active Directory for unified and policy based user and resource management
• Replacing PBX with a Voice over IP system
• Upgrading your wide area network from site to site VPN’s to MPLS managed WAN
• Determining support and escalation procedures for a SharePoint deployment
• Replacing a Windows XP/Office 2003 desktop environment with Windows 7/Office 2010

In the above list, if you ask the question “Will users accept and adopt this?” the answer is a fairly clear yes. At the end of the day, no matter what version of Exchange is in, Microsoft Outlook is still Microsoft Outlook. What the user sees is an Inbox and so long as mail comes in and goes out – they are happy. All Active Directory is to a user is a username and password to get to their computer. Irrespective of how clever the routing is in a Voice over IP system or a WAN network, a phone is just a phone. You can plan for support and escalation procedures for SharePoint, but at the end of the day, people will use the SharePoint system because it is the right solution for them. Sure they might get pissed if they have bad technical support, but if the solution is crap then no amount of awesome support structure is going to change this.

This, my friends, is the realm of the analyst paradigm!

You see, if you ask me to deploy Active Directory or Exchange, I will ask you a bunch of questions about your number of sites, number of users, communications infrastructure and the like, and I know that users will use it. I actually don’t need to talk to them. Oh sure, someone might do some communications planning, but I don’t need to address user adoption because adoption is already there! People adapted to email, telephone and Microsoft Windows years ago.

Instead, I can go into a back room, read a bunch of whitepapers and design/deployment guides and blammo. Here is your solution and here is how much I think it will cost. Better still, I can use waterfall style of project methodology because as a specialist, I have done this before and have expertise. I can tell you what needs to be done in considerable detail and break it down into a plan.

What it all boils down to is that there is a clear relationship between cause and effect, characterised by answering YES to the “If I do this, will users accept and adopt this” test. But most IT departments (and most IT integrators) are going to default to the analyst paradigm because many of their other projects tend to be in the above category. This analysis based mode of project delivery is very much ingrained into the reptile brain of a lot of IT professionals through years of repetition of implementing these types of projects. After all, it’s just IT, right?

Also, note that many of these type of projects are characterised by being very technically complicated. Some are insanely so and require specialist technical expertise. This is the realm of the supremely skilled person who performs an analyst function with a body of knowledge behind them. The whole industry certification process is built on this fundamental underpinning and works really well with things like Cisco and Microsoft in areas like Exchange, Active Directory and the like.

Now, consider the following projects or initiatives (I am deliberately picking things where people may disagree with me so go with me, ok).

• Coming up with an navigational structure for a SharePoint collaborative portal
• Installing SharePoint to improve collaboration
• Replacing a folder based file share with a metadata based document repository
• Designing a new road layout for a local suburb
• Putting in a new intranet
• Putting in a records management system
• Installing a new time tracking system

In all of these problems, it is difficult to answer yes to the “Will users accept and adopt this” question. Sure, you can go all big stick and say “We will force them to” but that fails the “accept” part of the test. Therein lies the danger for the analyst paradigm. You can go off to the “back room” and use your body of knowledge, read best practices and “analyse” until the cows come home. Until you deliver the solution, you will not know if it will be accepted.  The cause and effect relationship is not clear until after an action has been taken!

The reason you can’t confidently answer yes is that all of these projects above require adaption on the part of the target audience. Adaption leading to adoption is a hit and miss affair. While we might like to think that we are all rational, clearly we are not. If you want rational, think Dr Spock from Star Trek – and even he got mad sometimes! Office politics and organisational inertia stems from the irrational world. Butt covering by positioning for “blame avoidance” for decisions made by fear and anxiety are commonplace. If you work in a large organisation and listen carefully to a typical meeting, the logic and facts that are spoken out loud are rarely what matters compared to the complex non spoken interplays that go on underneath the words.

For what it’s worth, I added a non IT example of designing a new road layout for a suburb. A rational analyst might think that residents have to accept the solution by definition because, after all, once a road is in, that’s it. But what typically happens is that residents of that neighbourhood see the plan, petition, form lobby groups and harass the hell out of their local political representatives. If this is enough to make the politician edgy then they will vote the plan down before it ever happens. Sure it might have been a good plan, but it’s gone now and the chances of further buy-in are greatly reduced.

The pure analyst is often taking a rational approach to an irrational problem space. Sorry folks – this is simply asking for trouble. Like the politician who does what they think will keep them in power versus what is logical shows the rational world does not always get a good look in. A good example in SharePoint land, is the “metadata is good and folders are bad” thing. Any metadata fanboy with this mantra often find the hidden organisation will beg to differ 🙂

So, what do we do then?

The facilitator paradigm instead aims to elicit resolution of problems using dialogue between stakeholders by achieving a greater degree of shared perception of the problem situation. Unlike the analyst paradigm, there is no back-room approach as such. By definition, we need to collaborate to do this. (Fancy that, eh? Collaborating to deliver a collaborative platform – who would have thought!)

Now, I am not talking about facilitation in the classic sense with everybody sitting in a room in a circle and plays team building games. Some of the best project managers and business analysts I have met are facilitators without necessarily knowing it. What I mean by facilitation is that our starting point is to leverage the wisdom of the crowd, by creating an environment conducive to participants being able to surface the irrational as well as the rational. Only in this way, can we come to a shared understanding of a problem and what should be done about it.

I previously termed this the holding environment, and it really is. A great business analyst or project manager knows this instinctively, and uses many tools (as well as some coercion and sometimes their own ego surrendering) to bring it about.

If you take anything away from this post, remember this. Anytime you cannot confidently answer the “Will users accept and adopt this” question, it is highly likely that not all users see that there is even a problem yet. Therefore, expecting people to magically buy-in and adapt when they don’t recognise the problem is never going to fly. Like trying to get a Darwinist to accept that intelligent design should be taught in schools, someone who does not believe in it to begin with, is not going to easily buy into a solution that requires them to change their beliefs and therefore behaviour. 

Conclusion

When you think about it (rationally!) we usually look at SharePoint as an enabling technology that can address a legacy of poor collaboration and information management. Yet, how can the world of the analyst work out if their solution will create the very same legacy without all stakeholders being on the same page?

So remember, in a project where the cause and effect relationship is not clear, use the facilitator paradigm and stop being such a bloody analyst!

Thanks for reading. Comments most welcomed .

Paul Culmsee

www.sevensigma.com.au

In 2011, I will be posting sections of my Governance and Information Master Class here. Much of the content consists of mental models, alternative frames of reference, pattern and practices as well as other tools and methods, specifically for the facilitator paradigm. This is my interest area and feel the analyst paradigm is already well represented in the SharePoint space.

I don’t know about you, but as a SharePoint practitioner, I love the fact that I do not do SharePoint full-time anymore. I’d like to take some time to explain why this is the case, and how my non IT work helps me be a better SharePoint practitioner. To do so, I will talk about a recent non IT project I worked on. Who knows? This may give you some insights into how you view and approach collaborative work.

Western Australia is BIG

In case you don’t know already, I live in Perth, Western Australia. You can see Perth if you squint at the map on your left and look to the south west area.

Western Australia is a bloody big land area and extremely isolated. One claim to fame about living in Perth is its distinction for being one of the most isolated cities in the world. In fact we has a population density is on par with Mongolia (this is dead-set true – I researched this fact). Of the 2.2 million people that live in the state, 1.8 million live in the Perth metropolitan area and the rest are scattered far and wide. In terms of distribution, there are no other major cities in Western Australia. The next most populated town outside of Perth is Mandurah with some 83,000 people. 

In the north of Western Australia, these towns are often separated by anywhere from a couple hundred to more than a thousand kilometres. The weather is very hot, the landscape is breathtakingly beautiful and the isolation here is hard to comprehend without visiting. The wealth of Western Australia (“GFC? What GFC?”) comes from the north of this vast state, via huge mineral deposits that China seems happy to buy from us, which in turn keep me and my colleagues busy putting in SharePoint around the place.

Now if you think Western Australia is big, get this: The Kimberley region of Western Australia (the top section marked in red) is almost as big as the entire country of Germany. For American readers, it alone is three fifths the size of Texas. For all that space, only around 45000-50000 people live there.

These wide distances create all sorts of challenges. At a most basic level, think about the cost of basic services to such a remote location with such a small population density. Cost of living is high and services like health care are always stretched and people living here have to accept that they will never be able to enjoy the same level of service enjoyed by their city slicker cousins.

Now that I have painted that picture in your mind, let me intersect that with one of Australia’s biggest wicked problems. The indigenous people’s of Australia have many social and health issues that have had a massive human cost to them. We are talking chronic alcoholism, physical and sexual abuse, depression, suicide and the whole range of mental illnesses. Families and communities tear themselves apart in a seemingly an endless negatively reinforcing cycle. Like many indigenous groups around the world, intervention approaches from earlier periods have had catastrophic long term consequences that were never considered at the time (a classic wicked problem characteristic). When you read the stories about the stolen generations, you cannot help but be deeply moved by the long term effects, the damage done and the sad legacy left behind.

Continue reading “Dialogue Mapping: The Ying to SharePoint Yang”

Hi All

Here is my simple, patent pending method to use to help users design good SharePoint sites. It combines two very effective IA methods into one and its amazing how it turns people from wanting 1990’s era sites complete with horizontal scrolling banners with animated GIF’s into usability and IA gurus within minutes.

The tools of the trade you need for this method is:

• Balsamiq, a terrific wireframing tool that I previously reviewed.
• http://www.websitesthatsuck.com/ – a hilarious site dedicated to teaching people how to design sites by looking at particularly crap ones

So now you know the ingredients, let’s run through the recipe

1. Put key stakeholders into a room (ensure the ones with poor taste are there together)
2. Visit websitesthatsuck.com and review the 2010 contenders for worst websites of the year. (For what its worth, my personal vote is Yale School of Art)
3. Have a good laugh and discuss all the crappy aspects to those sites – make particular note of the write-up on websitesthatsuck for each contender
4. With the group’s sucky website radar now primed, have them load up their existing intranet (if they are really big organisation, go around to various departmental sites around the intranet). This time they will not laugh, due to the effect of your “crapness calibration” ™ exercise, they will see many faults in the existing site straight away.
5. At this point, crank out Balsamiq and start to wireframe what the site should look like while you have the fleeting moment of clarity (crapness calibration fades with time and needs to be re-primed). The wisdom of the crowd should ensure that most of the common mistakes will be avoided there and then.
   • Statistically, one of every three times you do this, there is always one user who’s taste is so bad that calibration will take another round of deprogramming. So if you have someone that persists with crap taste or has ideas that 99% of the user base would balk at, move to the 2009 hall of shame for sucky sites. Faced with the reaction from their peers, as well as the parallels that can be drawn between their current site and the contenders, it usually does the trick.
   • Also be sure to draw attention to sites that have similar underlying concepts, but where one works well and the other has agonising lameness. For example, the New York Times compared to Havenworks. Discuss the layout, colours, fonts, images, navigation, search and the like and relate back to the site being envisioned.

In about 30-90 minutes, one of two things will happen.

1. You will have a pretty good wireframe or three
2. The group will realise that they have more soul searching to do.

Although your business development manager will whine at you if outcome 2 happens, consider it a good thing. You will be saving yourself and the participants a mountain of stress later and have them thinking more holistically about the outcomes they are trying to achieve.

(Final serious bit at the end alert)

What you will notice when performing this process, is that with a recent and clear frame of reference, some of the biases that people carry with them can be temporarily lifted. In some ways, this exercise is very similar to the “down the pub” calibration of estimates exercise that I wrote about previously. The trick is to find ways to change the lens people look through to see other aspects or facets to the problem at hand.

To that end, if you are in the UK or nearby, consider coming to my Governance and Information Architecture Master Class in London with Andrew Woodward and Ant Clay. Lots of other (more serious and rigorous) methods for developing shared understanding will be covered.

Thanks for reading

Paul Culmsee

www.sevensigma.com.au

As you may have noticed, this blog has been a bit of a dead zone lately. There are several very good reasons for this – one being that a lot of my creative energy has been going into co-writing a book – and I thought it was time to come clean on it.

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

Vulgarity warning. Its the silly season, I am winding down and being more low-brow than usual with this post

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

Three weeks ago my plasma TV broke, freeing the family from the magic spell of hi-def television. My family took the loss in different ways. My four year old was devastated at the lack of Nintendo Wii, and constantly whined about being bored. My ten year old is a bookworm anyway, and continued to be one. I suddenly found mountains of time to write, churning out three Dialogue Mapping articles that I had been meaning to write for ages.

Today the repair man came and fixed the TV. I expect that the glow of the plasma screen will once again induce that zombie-like state, where my work-rate is dependant on what show happens to be on at the time (NCIS as I write this). Luckily, this is the last article of this particular series on Dialogue Mapping for now and I might have enough active brain cells to hang on long enough to squeeze this article out.

This article builds on the last section of part three that was entitled “Nurture the holding environment”. In that section, I introduced the concept of the “holding environment” and I offered a basic example (the bus trip that was conducted prior to the Dialogue Mapping session). This concept is so fundamental and important to the success of Dialogue Mapping and projects more broadly that I want to do it proper justice here in part four.

The paradox of individuality

Put a bunch of right-brained geeks in a room to solve a problem and you will probably find that they get on relatively well. Put a bunch of creative left-brained marketing people in a room to solve a problem and you might expect the same thing. The solutions offered, when compared to each other, are likely to be quite different and will also likely be sub-optimal. For a truly good solution, we need diversity in perspectives and, although this pains me to say, marketing people are therefore actually needed. This creates a bit of a problem though with the paradox of individuality because, as geeks, we all know the notion of marketing people being needed goes against everything we stand for.

I first read about the paradox of individuality in a book called Team Talk: The Power of Language in Team Dynamics and it was described as follows:

The only way for a group to become a group is for individuals to express their individuality, yet the only way for individuals is to become fully individuated is to accept and develop more fully, their connections to the group.

What? Geeks and marketing people accepting each other as equals? Unifying the laws of physics will come sooner and this is a classic example of what Conklin calls “social complexity”. Of course, social complexity goes much deeper than geeks vs. marketing people, but one of the effects of social complexity is a distinct lack of direct communication between parties. This is because conflict is not fun and avoidance is a natural reaction to situations that are not fun.

The idea of the “holding environment” is best summed up with the image below. Here, you can see that we have an area set aside for kids to play in a safe, controlled environment.

A holding environment for an organisation or a team is actually not that dissimilar to the example above. You are attempting to create a state where participants can step out of their comfort zones, but at the same time, are shielded from counter productive tensions that cause paralysis, chaos and pullback.

For this reason I maintain that beer is one of the best holding environments available and it forms a key part of my professional skill set 😉

As I stated in part 1 of this series, Dialogue Mapping is a very useful holding environment on its own, but it can be augmented with other things as well and you should always be on the lookout for complimentary tools and techniques. In the following sections, I will outline where Dialogue Mapping has augmented another method, or where we have augmented Dialogue Mapping itself with another method.

Information gathering for 40+ people

There are practical limits to how many people should be involved in a standard Dialogue Mapping session. Mind you, there are practical limits for how many people should attend a meeting too and that limit seems to be any more than one person :-).

By “standard”, I mean the sort of session illustrated below. The exact number that test the limits of Dialogue Mapping varies because it really depends on the wickedness of the problem being discussed and the past history of the group. For example, one of the teams I map for consists of around fifteen to eighteen members. They are working on a particularly wicked problem, yet I can work with this group alone quite easily. This is because over time, the group has worked out their decorum for the Dialogue Mapping sessions that work for all concerned. I also know everybody on a first name basis and some of the group have become personal friends of mine outside of work. In short, people are comfortable with each other and the process, and despite things getting heated people know that it is not personal. This is a simple, yet effective, example of a working holding environment.

A while back, my client invited representatives from academia, charities as well as various public sector government departments, to a half day workshop on the topic of social sustainability as part of a significant redevelopment project. There were approximately 40-45 attendees who were there for the first time. There was no way we would be able to cover off the required topics using a standard Dialogue Mapping set-up. With so many people, it would be hard for all attendees to have a say in the allotted time, let alone set up the room to handle that number of people for the process.

The way we got around this issue was to run a pre-workshop session among a much smaller group, to create a series of “seed maps” for each of the sub-areas of social sustainability. By the end of this process, we had around a dozen maps on various subtopics with a few questions, ideas, pros and cons. These maps were not complete at all, but that was not the aim. Instead they were well formed IBIS argumentations.

We then printed each of these maps out at large size. Initially each map was pinned to display boards, and when the attendees arrived they spent time wandering from map to map, examining the argumentation while mingling with other attendees. Below is a photo showing some of the seed maps prior to the attendees arriving.

Below is a diagram representing the table arrangement for the workshop. We started with a half hour overview and introduction as to the purpose of the workshop and why they had been invited. At this point, we removed four of the maps from the display boards above, and put a map on each table. We explained to the group that each table had a unique map on it and each map was on a particular topic. At this point attendees had the opportunity to move to a table where the topic was of most relevance or interest to them.

Each table contained copious amounts of marker pens. I then took the stage and explained the basics of IBIS grammar to the attendees and explained to them that we wanted them to start adding ideas to the existing maps. I did not belabour the grammar, nor did I expect them to suddenly know how to do IBIS properly, but what I made clear, was that I was going to walk from table to table and interrupt if I felt the additions to the map made no sense or were ambiguous in some way.

The group had just under an hour to work on each map and at the end of the hour, we removed the updated paper maps and replaced them with the next four from the display boards. The process was then repeated and I walked from table to table, asking for clarification or calling out implied questions on parts of the maps that made no sense to me. Interestingly, IBIS novices seemed to have little problems with the usage of ideas, pros and cons, but they would forget to make the underlying question explicit. I would ask them what was the question being answered by a particular idea and would write the question into the map and redraw the lines.

After the third iteration of this process we were done. The last half an hour was a “Where to from here?” session and an opportunity for the group to provide feedback to the organisers of the workshop.

After the workshop was completed, I took all of the updated paper maps and added the additional rationales into the seed maps in Compendium. The process was surprisingly quick because the majority of the additional argumentations that were added were actually pretty good IBIS form. I think that having existing argumentations on the seed maps made it easier for attendees to add rationales that looked similar to what was there already. It wasn’t perfect IBIS by any means, but it was not a difficult task for me to refactor the additional information without losing any of the intent behind the rationales.

For the record, additional workshops were conducted, but these reverted to standard Dialogue Mapping workshops with a subset of the attendees who had specialised skills and knowledge in the topic area. But what this particular process demonstrated was that with a little planning a single Dialogue Mapper could still manage to capture quality rationales from a very large group in a short space of time.

Dialogue Mapping with a facilitator

Dialogue mapping for a large group can be augmented with a facilitator and I have done this a few times. For a large group, this can be very helpful because the mapper can concentrate on capturing the dialogue and less on directing the meeting. Equally though, a facilitator can actually make the process more difficult. The key to a facilitator situation working is when the facilitator either knows IBIS or has been present in a number of Dialogue Mapping workshops and understands how the process works. This is because the facilitator is usually facing the group like the mapper, asking probing questions, directing the course of conversation and therefore is not looking at the map or listening in terms of IBIS translation of the dialogue. As a Dialogue Mapper, it is important for participants to verify what you have captured is correct, and if the facilitators are not following the map, they can easily get in the way of this verification process.

Facilitators can also get you into trouble at times because they can sometimes be conditioned to traditional meeting decorum where topics are allocated at particular times with an agenda that can preclude deeper exploration of a topic. Dialogue Mapping is a rich enough container to allow a group that deeper exploration, but this is not something that some facilitators are used to. One prime example that sticks out in my mind to this day was a workshop where we had a lot of options to explore. Conscious of the agenda, in an attempt to make the process more efficient, the facilitator asked the group whether any of the options had any “fatal flaws” that enabled that option to be quickly discounted. It soon became apparent (in a negative way) that one person’s “fatal flaw” was diametrically opposed to another person’s “fatal flaw”. This attempt to shortcut deliberations backfired badly and resulted in this line of question being completely abandoned.

This is a great example of the importance of nurturing the holding environment (lesson nine from part 3). After this “fatal flaws” episode, I deliberately stopped mapping while the group resolved the fatal flaw issue and resolved to try a different approach. This subsequent approach proved to be much more successful and we never deviated from it after that. “No fatal flaws” became a bit of a mantra among this group.

A key to working with a facilitator is to remember the lesson on confidence and assertiveness from part 3. Just because a facilitator is directing the meeting and influencing the direction of the conversation, it doesn’t mean that the mapper is purely a scribe. Work out a system with the facilitator where, if you raise your hand or signal in some way, you are not ready to move on straight away. Another technique that I have used in a large group situation was to assign someone else the traffic warden role, where if I am having trouble keeping up with the various conversations, and my eyes are on the map, they can call the group to order.

Dialogue Mapping, in tandem with another Dialogue Mapper ,can work very well and I have done many times with my colleagues at Seven Sigma. In this situation, you are both thinking in the IBIS grammar and both of you are mentally unpacking the conversation, although only one of you is actually performing the mapping. We have used this technique with particularly good results in SharePoint requirement gathering workshops, where one of us asks the questions and the other performs the mapping.

Dialogue Mapping and Debategraph

Compendium is one of several tools that can be used to create and render argument grammar like IBIS. For me, Compendium is the absolute best for Dialogue Mapping. Being a desktop application, I do not need internet access and once you are proficient with it, Compendium is very fast. This is of course, the biggest factor for Dialogue Mapping live. You do not want to be hindered by the limitations of the software tool that you are using.

I noticed that some CleverworkArounds readers created IBIS maps in Visio and were also using mind mapping tools after I published the “One best practice” series. But the problem is, although you can technically make an IBIS map, those tools would never work in a live session because of how slow it would be to add rationales to the map. Seriously guys, it might be technically possibly but do not attempt to use those tools live.

One size does not fit all and this is especially true of sense making tools. There are actually two main audiences for maps like this. Those who create the maps and those who consume the maps. The key point is that the ultimate audience for any map is quite often not the group creating the map in the first place. The whole point of capturing rationale is to make visible the process that a group went through when working on a problem, which ultimately shows why a particular decision was made or why a course of action was taken. Those who want to review the rationales are a very different audience to those who made the decision and wish to demonstrate justification. Just because the tool works well for the problem solving process, does not automatically assume that the tool is then best suited to the communication of that rationale to a wider audience.

Compendium maps work brilliantly well during the Dialogue Mapping process and from a broader communication point of view, work exceptionally well when detailed maps are printed onto large sized paper. But as a communication and distribution tool, Compendium is weaker than some of the alternatives. Compendium maps do not translate overly well to the web at this point, and asking all interested parties to install compendium is out of the question. For the sake of article length, I will not go into detail why this is, but to appease the Compendium fanbois, this is direct feedback from my clients and not just my opinionated rant.

For communicating the rationale that has come from Dialogue Mapping sessions to a wider audience, Debategraph is ideal. Unlike Compendium, Debategraph is a cloud based argument visualisation tool, designed to leverage the freeform updating capabilities of a wiki, along with the rigor of an argument grammar much like IBIS. Debategraph does not use a top down or left to right visualisation method. Instead each node is at the centre of the screen and surrounding issues, ideas, pros and cons surround the node, requiring the user to click nodes to explore further argumentation.

The beauty of Debategraph is the combination of its argument navigation, along with the streaming view of related content as shown below. My clients absolutely love the stream view because it is so simple for people to explore and work with. The ability to embed a map at any point in the debate on any web site is also pretty handy and I have pasted a sample map below to illustrate this. Click a node on the left pane (the “*” means there are sub arguments) and the content in the right window will change, based on which argument node is currently being examined.

Compare this to Compendium maps, where additional rich content like images, documents and the like are treated as additional nodes in the map. As you can see in the example below, it is possible to integrate rich content into the map very easily, but that rich content is linked in the same manner as the argumentation itself. Debategraph on the other hard, separates the argumentation from the supporting content and I think that this works much better and supports a richer form of argument based content delivery.

But once again, use the best tool that fits the purpose. From a dialogue and rationales collection point of view, Debategraph is an excellent way for a bunch of geographically dispersed people to debate a particular issue because the map will refactor on the fly as people self-contribute to it. But I personally would not use Debategraph for the Dialogue Mapping process, because it is not as fast as compendium and it is not as easy to view the map in full context as shown above. The over-arching point with all of this is that if the rationale has been captured in the first place, there are many ways to make creative use of it.

Note: To be fair on the Compendium makers there are many excellent examples of Compendium being used for some pretty impressive things. I am talking here specifically about online collaboration and communication to a wider audience.

Conclusion

This series of posts has examined the practical aspects of Dialogue Mapping, explored some of the techniques that I have used to augment it. Although I do not intend to write any more articles on this topic right now, the series is by no means complete. This is an ongoing learning process for all practitioners of this craft and I am sure that other Dialogue Mappers have tried different techniques than those that I have covered. (Some interesting things are happening on the SharePoint integration front too, which should enrich this experience even further, but that is a whole separate topic 🙂 )

But one final request. If you have used techniques such as these to enrich the experience for participants, then I’d love to hear from you. Even if it is not for Dialogue Mapping, any technique that is inclusive and augments the holding environment, please drop me a line or leave a comment.

Thanks for reading

Paul Culmsee

www.sevensigma.com.au