• 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

• 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

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

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

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

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

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

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

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

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

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

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

Hmm.

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

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

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

Research into collaboration itself

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

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

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

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

• A Taxonomy of collaboration in support of information seeking (Golovchinsky, Pickens, & Back, 2009)
• Three domains of problems (Talley, 2003)
• Know the Four Types of Conversations (Banathy & Jenlink, 2004)
• The Art of Focused Conversation: 100 Ways to Access Group Wisdom in the Workplace (ICA series) <- A great book I already owned
• Understanding Groups’ Properties as a Means of Improving Collaborative Search Systems (Ringel & Teevan, 2009)
• Beyond Document Collaboration (Hollis, 2007)

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

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

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

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

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

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

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

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

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

Making a model

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

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

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

Thanks for reading

Paul Culmsee

www.sevensigma.com.au

Hi all

A big chunk of last year had me off under a metaphorical mushroom, putting together several days of courseware on the topic of SharePoint Governance and Information Architecture. My take on these topics are influenced from some odd places, and the course drew on a lot of the non IT work that I do, that involves collaboration on some very complex problems indeed.

In November and December of 2010, we took this “on the road”, so to speak, firstly in Dublin, then London and Sydney. The courses were sold out and feedback was terrific. Here are a few choice quotes (check out the hyperlinks for full reviews)

“Did it meet my expectations? Well I’d have to say that it far exceeded them. There had obviously been a large amount of effort in preparing the courseware and modules. They covered the important missing links currently absent from the Microsoft and traditional training courses” – Wes Hackett.

“I’ve just finished the second day of the SharePoint 2010 Governance and Information Architecture Master Class presented by Paul Culmsee with the support of Andrew Woodward . I can wholeheartedly say it was one of the best courses I’ve attended both in content and presentation style and they deserve a lot of credit for putting together a fantastic course. Paul in particular has put a huge amount of effort into the slidedeck, sample documents and enormous manual (almost 500 pages worth!) let alone all the great additional insight he could provide in person over both days” – Brendan Newell

“Finally …. after 12 years in the IT industry a course which covers some of the fundamental issues governing project success.   This course is a real eye opener and a must for any IT professional involved in project planning and delivery” -  Stephen McWilliams

“I just came back from the best technology training I have had in years: a world-first Microsoft SharePoint Elite Information Architecture course designed and delivered by Paul Culmsee. It has taught me a great deal across ALL facets of the day-to-day work that I do as a SharePoint architect” – Jess Kim

Based on this and similar feedback, we are going to do it again. Locations confirmed so far are London (#SPIAUK), Sydney (#SPIAAU) and Wellington (#SPIANZ) in February and March 2011 and in the pipeline is The Netherlands (#SPIANL) and at least a couple of US cities!

In addition to the unique content on these classes, I am honoured to announce that I am now authorised to teach the official Cognexus Issue Mapping courseware – the only non Cognexus Dialogue Mapping practitioner authorised to do so. As such, we will be running the inaugural Issue Mapping class in London in late February as well (wohoo!)

So, here are the details for each location:

Wondering what to expect in these classes? Read on!

 SharePoint Governance and Information Architecture Master Class. 2 full days of real world, examples knowledge and techniques

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‘s style takes an ironic and subversive take on how SharePoint governance really works within organisations, while presenting a model and the tools necessary get it right.

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

Master class aims:

• Present SharePoint governance and Information Architecture in a new light – focus on the “blind spots” where the current published material is inadequate
• Cover lessons learned from Paul’s non IT work as a facilitator and sensemaker in complex large scale projects
• Examine the latest trends in the information landscape for industry and government and review studies that inform governance and Information Architecture efforts
• Present an alternative approach to business-as-usual SharePoint governance planning that focuses on real collaboration
• Provide quality information that is rigorous yet accessible, entertaining and interesting

Master class outcomes:

• Understand the SharePoint governance lens beyond an IT service delivery focus
• Develop your ‘wicked problem’ radar and apply appropriate governance practices, tools and techniques accordingly
• Learn how to align SharePoint projects to broad organisational goals, avoid chasing platitudes and ensure that the problem being solved is the right problem
• Learn how to account for cognitive bias and utilise tools and techniques that help stakeholders align to a common vision
• Understand the relationship between governance and assurance, why both are needed and how they affect innovation and user engagement
• Understand the underlying, often hidden forces of organisational chaos that underpins projects like SharePoint
• Understand the key challenges and opportunities that SharePoint presents for Information Architecture
• Learn how to document your information architecture
• Practical knowledge: Add lots more tools to your governance and IA toolkit!

Course Structure: The course is split into 7 modules, run across the 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

As a take home, we will also supply a USB stick for attendees 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” and until now have never been released to the public.

Note: The workshop sessions will be hands on, we provide all of the tools and samples needed but please bring your own laptop.

Issue Mapping Master Class. Your path towards shared understanding and shared commitment

“Some problems are so complex that you have to be highly intelligent and well informed just to be undecided about them.” Laurence J. Peter

Presented by: Paul Culmsee

Courseware by: Cognexus Institute and Seven Sigma

“Not another $#%@*$ meeting!”

All of us have felt the frustration of walking from yet another unproductive meeting, wondering where the agenda went. Yet, as problems become more complex, meetings are still the place where critical strategic decisions are made.

What is Issue Mapping?

Issue-Based Information Systems (IBIS) is a sense-making framework used to support group discussions to assist all involved to come to a shared understanding. It visually maps participants’ points of views, problems voiced, the rationale and reasons leading up to decision(s). The maps can be easily read and understood by everyone, even by those not part of the discussion group.

Why Issue Mapping?

• Maps detailed rationale behind decision-making as well as the decision; maps the thinking process of the group
• Concentrates on pros and cons to an idea, encourages and explores all views, taking the sting out of differences
• Represents and clarifies diverse points of views, conflicting interpretations and goals, inconsistent information and other forms of complexity
• Everyone gets a chance to speak, if they want. People are heard and contributions are acknowledged. Interruptions, repetition and dominance of the loudest decreases
• Keeps participants on topic because they can visually see the progress of the discussion
• Keeps everyone’s attention
• Meeting progress/result can be seen
• Map helps participants come up with ideas/arguments
• Visual display of progress to review summary if need so the brain can absorb the bigger picture and appreciate the validity and value of a larger perspective
• Avoids jumping to easy answers or superficial conclusions
• Promotes deeper reasoning, rigor and even wisdom
• Everyone can visually see everything discussed- leaves no room for misunderstandings
• Documents can easily be attached to map to back up ideas
• Participants can see effectiveness of mapping and genuine will try to make it more productive

About Seven Sigma

Issue Mapping is a life skill that can be applied to many different problem domains and scenarios. Participants will gain proficiency in a craft that can be applied long into the future, to help them and others bring clarity and convergence to the management of complex problems. At Seven Sigma, we practice Issue and Dialogue Mapping routinely and this has brought us many satisfied clients. The Mapping in itself is part of the ‘secret sauce’ that makes Seven Sigma’s reputation renowned.

Seven Sigma Business Solutions is the only recognised designated partner of Cognexus Institute, founder of the art of Issue Mapping, in the world. We recognise that without reaching shared understanding, you will find yourself at yet another meeting, rehashing the same unresolved problems, listening to the same arguments month after month. Or, if a decision has been made, it has not been followed up to fruition due to lack of commitment/buy-in.

We are proud to be part of your journey towards shared understanding and shared commitment.

Master Class aims and outcomes:

• Be able to create great maps – issue maps that are clear, coherent, and inviting
• Immediately start using Issue Mapping effectively in your work and life; the class will focus on practical experience and map building
• Command a rich range of options for publishing and sharing maps
• Lead with maps: create direction, momentum, and energy with issue maps
• Quickly and effectively do critical analysis in dynamic situations
• Organize unstructured information and discover patterns and connections within it
• Make critical thinking visible for inspection and analysis
• Recognise early, the symptoms of wicked problems and the forces behind group divergence
• Recognise the importance of capturing the rationale behind decisions, as well as the decisions themselves
• Rethink the traditional approach to meetings and decision making
• Start capturing the rationale leading up to the decisions by using IBIS and Compendium software

It will also give you a deeper understanding of:

• The fundamentals of IBIS and Compendium
• The structural patterns that give clarity and power to issue maps
• How decision rationale is represented in a map

This master class will be hands on – please bring your own laptop with Compendium software (freeware) installed.

Duration: 2 days, with homework after the first day

Audience: For both IT and non-IT audience; those involved in highly complex projects including leaders, consultants, facilitators, organisational development professionals, change agents, managers and engineers.

Prerequisite: An open mind geared for shared understanding and shared commitment

Hiya

[Note: I have written another article that illustrates a process for migrating the entire term store between farms.]

My colleague Chris Tomich, recently saved the day with a nice PowerShell script that makes the management and migration of managed metadata between farms easier. If you are an elite developer type, you can scroll down to the end of this post. if you are a normal human, read on for background and context.

The Issue

Recently, I had a client who was decommissioning an old active directory domain and starting afresh. Unfortunately for me, there was a SharePoint 2010 farm on the old domain and they had made considerable effort in leveraging managed metadata.

Under normal circumstances, migrating SharePoint in this scenario is usually done via a content database migration into a newly set up farm. This is because the built in SharePoint 2010 backup/restore, although better than 2007, presumes that the underlying domain that you are restoring to is the same (bad things happen if it is not). Additionally, the complex interdependencies between service applications (especially the user profile service) means that restoring one service application like Managed metadata is fiddly and difficult.

I was constrained severely by time, so I decided to try a quick and dirty approach to see what would happen. I created a new, clean farm and provisioned a managed metadata service application. The client in question had half a dozen term sets in the old SP2010 farm and around 20 managed metadata columns in the site collection that leveraged them. I migrated the content database from the old farm to the new farm via the database attach method and that worked fine.

I then used the SolidQ export tool from codeplex to export those term sets from the managed metadata service of the source farm. Since the new SP2010 farm had a freshly provisioned managed metadata service application, re-importing those terms and term sets into this farm was a trivial process and went without a hitch.

I knew that managed metadata stores each term as a unique identifier (GUID I presume because programmers love GUID’s). Since I was migrating a content database to a different farm there were two implications.

1. The terms stored in lists and libraries in that database would reference the GUID’s of the original managed metadata service
2. The site columns themselves, would reference the GUID of the term sets of the source managed metadata service

But the GUIDs on the managed metadata service on the new farm will not match the originals. I did not import the terms with their GUID’s intact. Instead I simply imported terms which created new GUID’s. Now everything was orphaned. Managed metadata columns would not know which term store they are assigned to. For example: just because a term set called, say “Clients” exists in the source farm, when a term set is created in the destination farm with the same name, the managed metadata columns will not automatically “re-link” to the clients term set.

So what does a managed metadata column orphaned from a term set look like? Fortunately, SharePoint handles this gracefully. The leftmost image below shows a managed metadata column happily linked to its term set. The rightmost image shows what it looks like when that term set is deleted while the column remains. As you can see we now have no reference to a term set. However, it is easy to re-point the column to another term set.

When you examine list or library items that have managed metadata entered for them prior to the term set being deleted, SharePoint prevents the managed metadata control from being used (the Project Phase column below is greyed out). Importantly, the original data is not lost since SharePoint actually stores the term along with the rest of the item metadata, but the term cannot be updated of course as there is no term set to refer to.

Once you reconnect a managed metadata column to a term set, the existing term will still be orphaned. The process of reconnecting does not do any sort of processing of terms to reconnect them. I show this below. In the example below, notice how this time, the managed metadata control is enabled again (as it has a valid term set), but the terms within it are marked red, signalling that they are invalid terms that do not exist in this term set. Notice though the second screen. By clicking on the orphaned term, managed metadata finds it in the associated term set and offers the right suggestion. With a single click, the term is re-linked back to the term store and the updated GUID is stored for the item. Too easy.

As the sequence of events above show, it is fairly easy to re-link a term to the term set by clicking on it and letting managed metadata find that term in the term set. However, it is not something you would want to do for 10000 items in a list! In addition, the relative ease of relinking a term like the Location column above is elegant only because it is a single term that does not show the hierarchy. This is not the only configuration available for managed metadata though.

If you have set up your column to use multiple managed metadata entries, as well as allow multiple entries, you will have something like the screen below. In this example, we have three terms selected. “Borough”, “District” and “Neighbourhood”. All three of these terms are at the bottom of a deep hierarchy of terms. (eg Continent > Political Entity > Country > province or State > County or Region > City). As a result, things look ugly.

Unfortunately in this use-case, our single click method will not work. Firstly, we have to click each and every term that has been added to this column one at a time. Secondly and more importantly, even if we do click it, the term will not be found in in the new term set. The only way to deal with this is to manually remove the term and re-enter or use the rather clumsy term picker as the sequence below shows.

Note how as each term is selected, it is marked in black. We have to manually delete the orphaned terms in red.

Finally, after far too many mouse clicks, we are back in business.

A better approach?

I showed this behaviour to my Seven Sigma colleague, Chris Tomich. Chris took a look at this issue and within a few hours trotted out a terrific PowerShell script to programmatically reconnect terms to a new term set. You can grab the source code for this script from Chris’s blog. The one thing Chris did tell me was that he wasn’t able to re-link a site or list column to its replacement term set. That bit you have to do yourself. This is because only the GUID of a term set is used against a column, which means without access to the original server, you do not know which term set to reattach.

Fortunately, there are not that many term sets to deal with, and the real pain is reattaching orphaned terms anyway.

Chris also added a ‘test’ mode to the script, so that it will flag if a field is currently connected to an invalid term set. This is very handy because you can run the script against a site collection and it will help you narrow down which columns are managed metadata and which need to be updated.

From the SharePoint 2010 Management Shell, the script syntax is: (assuming you call your script ReloadTermSets.ps1) –

.\ReloadTermSets.ps1 -web “http://localhost” -test -recurse

web – This is the web address to use. test – This uses a ‘test’ mode that will output lines detailing found fields and the values found for them in the term store and won’t save the items. recurse – This flag will cause the script to recurse through all child sites.

Of course, the usual disclaimers apply. Use the script/advice at your own risk. By using/viewing/distributing it you accept responsibility for any loss/corruption of data that may be incurred by said actions.

I hope that people find this useful. I sure did

Thanks for reading

Paul Culmsee

www.sevensigma.com.au

Hi everyone. This is my last post for 2010, and I am going out on a troubleshooting note. See you all next year with lots of new content and cool stuff!

I had some interesting experiences recently with SharePoint 2010, specifically the Content Organiser feature and leveraging it with incoming email. I thought they might be worth sharing, but first I need to set some context via the use-case where this started.

Where would we be without the photocopier?

Most organisations large or small, have one of those multifunction photocopier/scanner/fax/coffee maker gizmos (okay so maybe not the coffee maker). You know the types – they are large, noisy and the paper feeders frequently jam, where the tech guy who comes to fix it has to be on site so often that he’s considered a staff member. They usually have a document feeder, can scan to PDF and email it straight through to you. If you have a really fancy-schmancy one, it might even OCR the content for you so the resultant PDF is not an image but text based.

While all that is good, the real benefit of these devices is more subtle. Employees like to congregate nearby for a little bit of office gossip, and to quietly bitch to each-other about how much their boss or co-workers annoy them. The conversations around the photocopier are usually some of the most insightful and valuable conversations you might have at times.

So I believe that anything we can do to encourage photocopier conversations is a good thing. For some organisations, this is about as close as it gets to cross departmental collaboration! . If we also leverage the fact that these devices offer this “scan to PDF and email” function at the press of a button, then SharePoint has a nice story to tell here – especially with SharePoint 2010 and the Content Organiser feature.

The premise: Content Organiser coolness

I will spend a few moments to introduce the Content Organiser feature for readers who have not seen much of SharePoint 2010. If you know all about this feature, skip to the next section.

For those of you who may not be aware, SharePoint 2010 has an interesting new feature called the Content Organiser. The Content Organizer feature is quite a powerful document routing solution that makes it easier to store documents consistently, according to administrator defined rules that can copy or move a document from one place in SharePoint to another place. I will get to the rules in a minute, but the content organiser feature is important for several reasons;

• It makes the saving of documents easier because users do not necessarily have to worry about knowing the destination when uploading new content.
• It is a highly flexible method for routing documents between sites and site collections around the SharePoint farm.
• It underpins a solid compliance and records management file plan capability.

So before anything else can be done, we need to turn it on. The Content Organiser feature has to be activated on each site for the functionality to be enabled. In other words, it is a site scoped feature. Below is an illustration of the feature to activate.

Once the Content Organiser feature is activated, SharePoint 2010 makes several changes to the site configuration.

• It creates a new document library called the Drop-off Library.
• It creates a new custom list called Content Organizer Rules.
• It adds two new Site Administration links in the Site Settings page to manage the Content Organiser for the site.

The description for the feature says “Create metadata based rules…” and it these Content Organiser rules that allow you to automatically route documents from the newly created Drop-off Library to some other location. It is important to know that the Drop-off Library is fixed – it is the first point of call for files that need to be moved or copied somewhere. Consider the drop-off library like a bellboy of a hotel. You give him your luggage and he will ensure it gets to its correct location (and unlike a bellboy you don’t need to tip).

So if the drop-off library is the starting point, where can documents be routed to? The location can be;

• A document library and/or a folder within a document library on the site.
• The Drop-off library of another site, which allows inter and intra site collection routing.

The Content Organiser rules are managed from Site Administration which is accessed via Site Settings. New rules are added in the same manner as adding new items to any SharePoint list. In the following example, we will create a rule where a content types of invoice will be routed to a document library called Finance.

The conditions section of the rule allows for multiple conditions to be defined to determine matching content and then, where that content should be routed to. The properties available are any columns assigned to the content type being routed. In the example below, we have added two conditions that have to be satisfied before the rule will fire.

Let’s take a closer look at this beast known as the Drop-off library. This is a special document library is added to the site upon feature activation, imaginatively called the Drop Off Library. As stated earlier, this library is really a temporary staging area for items that do not have all required metadata to satisfy any routing rules.

The sequence of events for the Content Organiser is;

1. Documents with the correct content type, metadata, and matching rules are automatically routed to the final library and folder.
2. Documents that lack the amount of metadata required to match a rule or that are missing required metadata are retained in the "Drop-Off Library" so that the user can enter metadata to satisfy a rule.
3. After a user has edited a staging document with the appropriate metadata required to match a rule, the document is automatically routed to the target library and folder.

As an example, if we assume that a Content Organiser role will route any document with “Finance” in its name to document library called Finance, the behaviour will be as follows:

• If the file uploaded has the word “finance” in its name, SharePoint indicates that the document has been successfully routed
• If the file uploaded does not have the word “finance” in its name, SharePoint will indicate to the user that the content organiser has placed it into the Drop-off library.

Now, before you rush off and start to mess with the content organiser, I’d better tell you about a couple of caveats

1. The Content Organizer will only work on content types that are, or derive from, the Document content type. So it does not work for automatically organizing large lists.
2. When uploading documents via Windows explorer view, Content Organiser rules are ignored and the document will not be redirected to the Drop-off library. (through the browser if a document is uploaded to a destination library, SharePoint will move it to the Drop-off library for classification)
3. There is a limit of six conditions per rule. After six conditions are added, the "Add new condition" link disappears.
4. If you wish to route the document to another site, the Content Organizer feature has to be installed on that site for the Drop-off library to be created as that is the destination. Additionally, you need to add the configuration information in Central Administration by adding the destination to the list of send to connections for the web application (that is beyond the scope of this article, but easy enough to do).
5. Ruven Gotz tells me there are also some potential risks around the fact that you can route files to any destination even if you do not have permission and potentially overwrite content. As Scott says, the content organizer will move content to the new location whether or not the contributing user has access to the destination location.

Content Organiser and email integration

So if we go back to where we started with our fancy photocopier. SharePoint has offered email integration on document libraries since the 2007 version. In effect, we give each document library or list an email address, set up a few parameters and any attachment will be in effect, uploaded to a document library.

On a semi-related note, my company actually developed a version of the content organiser for SharePoint 2007 that allowed the routing of documents based on business rules. Contact us if you want to now more.

Given the routing capabilities of the content organiser in SharePoint 2010, one would think that by email-enabling the Drop-off library that is created when you activate the content organiser feature, that we can have all scanned correspondence end up in the Drop-off library, ready for classification by an administrator and routed in accordance to specified routing rules.

Sounds logical enough – so logical in fact that I gave it a try.

Problem 1: Race condition?

Email enabling a document library is pretty easy, provided you have set up incoming email in SharePoint Central Administration first. In this case, I set up the incoming email on the Drop-off Library with the settings below: Note that I specified not to overwrite attachments with the same name.

I then programmed the photocopier to use this email address as a profile. That way, a user would scan incoming correspondence, then choose this profile as the destination. The photocopier would scan to PDF and then email those PDF’s to the Drop-off library. The problem was – not all of the scans arrived.

We noticed that individual scans (ie one document at a time), would work fine, but for some reason, bulk scans would not. Typically, if a user scanned say, 10 items, only 6 of them would make it to the document library. A trawl through the diagnostic logs was therefore required. Luckily, SharePoint 2010 has been built upon PowerShell, and there is a PowerShell command to get at the diagnostic logs. I have become a huge fan of PowerShell just from this one command, as it has eliminated the need for me to install additional tools to view logs on SP2010 boxes. Taking a punt, I assumed if there was to be an error message, it would have the word “E-mail” in it. So I issued the following PowerShell command:

Get-SPLogEvent | Where-Object ( $_.message -like "*E-Mail*" ) | Out-GridView

This will return any logs in a graphical format (the gridview) as shown below. Immediately I saw warning messages, telling that an error occurred while attempting to create an attachment for an item sent via email.

This was clearly related to my issue, so I adjusted the PowerShell script to be a little more specific so I can see the full message

Get-SPLogEvent | Where-Object { $_.message -like "*create an att*" } | Select-Object -Property message | Out-GridView

The email was sent to the list “Drop Off Library”, and the error was: the file DropOffLibrary/<filename> has been modified by SHAREPOINT\SYSTEM on <date>

Problem 2: A poorly named feature?

This time, I saw that it claims that the attachment was modified by SHAREPOINT/system. Hmm – that sort of error message is very similar to race conditions seen with SharePoint Designer workflows. Thus, my first thought was that email enabling the Drop-off library was possibly unsupported. I figured that the Drop-off library likely used event-receivers, workflow or scheduled tasks to do the document routing that might get in the way with processing incoming email attachments.

My suspicion was further given weight when I recalled that there was another feature to do with content organiser that I could activate: Email Integration with Content Organiser. According to the description, it enable a site’s content organizer to accept and organize email messages. Cool – this seemed logical enough, so I activated it.

Upon activating this feature, a small change is made to the Content Organiser Settings page, found under Site Settings. An e-mail address was assigned, and a link was provided to configure the organizers incoming email  settings as shown below:

This is where things started to get interesting. As expected, I was taken to the incoming email settings screen, but instead of it being the drop-off library, it was a hidden list called Submitted E-mail Records. At the time, this suggested that my initial conclusion that incoming email on the drop-off library was unsupported was correct. After all, why else would incoming email be redirected to another list instead of the drop-off library? I couldn’t think of any other logical explanation.

At the time, I searched the web to see if anybody else had mentioned the Submitted E-mail Records hidden list and problems with incoming emails. I was then surprised to learn that this hidden list was there in SharePoint 2007, but I’d never seen it before because Records Management in 2007 is crappy and I never used it much.

Anyway, try as I might, I could never get items emailed to the Submitted E-mail Records list, to ever route to the Drop-off library. The photocopier would happily mail items to Submitted E-mail Records list, but they would stay there and never get processed. Grrr!

After turning up some debug logs to verbose, specifically:

• Document management Server: Content organiser
• SharePoint foundation: E-Mail

We saw the following error message: “Cannot resolve mailbox (null) to a valid user”. Additionally, my colleague Peter Chow used reflector to examine the underlying code behind this feature. From what we could tell, a method, GetOfficialFilePropsFromBody, in the class: Microsoft.Office.RecordsManagement.RecordsRepository.EmailRecordsHandler, was attempting to extract a mailbox value and getting a null.  Unfortunately for us, the code eventually lead to obfuscated classes so we were not able to dig any deeper.

At this point, with nothing on the net to guide us and twitter going quiet, I logged a support call with Microsoft. Pretty quickly, our issue was reproduced and escalated to the local team and then to the US. A few weeks later, we got the following answer:

The E-mail Integration with Content Organizer feature is a there for legacy Exchange 2007 deployments that can journal mail to SharePoint.  Such functionality is not available in Exchange 2010 and we do not (and never have) supported directly e-mailing a content organizer as the steps below show.  It just won’t work – that mail submitted to that list needs to be in a special format that Exchange 2007 can create (or some other system who has implemented that documented protocol). The users should consider leaving the mail in Exchange and using Exchange’s record management and compliance functionality or buying a third party add-in if they need to get mail into a SharePoint content library. http://technet.microsoft.com/en-us/sharepoint/ff598594.aspx has a list of partners.

Workaround : For this  scenario we found a workaround to enable incoming email on the “Drop Off library” and which in turn routed the emails/attachments to the destination library as per the rule. The envelope data or other metadata will NOT be carried along with the item to its final location with this workaround. So the customer should expect to lose sender, sent, received, et cetera

If the customer wants to check on how to get this working using Exchange 2007: http://msexchangeteam.com/archive/2006/11/21/431608.aspx

So the format is generated by the backend transport layer via a policy on a Managed Folder.  So even in 2007, you can’t email a content organizer.  But you can set up a journaling rule on a managed folder in Exchange to journal every item dropped into that folder to SharePoint.

We should not encourage users to email Content organizer since we have that has a legacy feature to support Exchange 2007. If the users wants email to be sent to SharePoint then use Email enabled Doc Lib.

So there you have it. Do not activate the Email Integration with Content Organiser feature!. It is a legacy designed specifically for Exchange 2007, yet the description for the feature in SharePoint makes no mention of this! If this was explicitly mentioned in the description of this feature, two weeks worth of needless troubleshooting and a long support call would have been avoided. Even my local (and excellent) Microsoft escalation team were not aware of this. Oh well, you live and learn.

Back to square one. (shut-up and apply the latest cumulative update)

So now that we confirmed that the Email Integration with Content Organiser feature was a giant red herring and never going to fly, we returned focus to why some attachments were not being correctly processed by the Drop-off Library. As it happened, the August cumulative update for SharePoint 2010 had a fix in it. This technet thread describes the issue in more detail. http://social.technet.microsoft.com/Forums/en-US/sharepoint2010setup/thread/896cbe2a-94c6-4a0f-9e4f-ea6b0fe3cc45/. There appeared to be a bug where even if you set the email-enable feature option called “Overwrite files with the same name”, to no, it was ignored and an exception was logged when attachments with the same file-name arrived. Turns out the photocopier file names were not 100% unique! It used a timestamp as part of the filename that was unique down to the minute, not the second.

So after a journey that included a needless support call, we applied the CU and what do you know, problem solved!

To conclude this rather long and rambling post, I feel kind of bad that I got so side tracked on the Email Integration with Content Organiser feature. That’s part of troubleshooting life I guess. The only consolation I can really take from it, is that it also fooled Microsoft engineers too. I guess this issue is yet one more of the many caveats that we all have to learn about the hard way.

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”

As the SharePoint 2010 dust settles, gushing praise and inflated expectations are slowly replaced by the cold hard reality, as people come to grips with the limitations of the product. One such area is with the managed metadata service. Don’t get me wrong, I like managed metadata a lot and I can see a little ecosystem building around that functionality specifically. But it does have a couple of big gotchas that you should be aware of before making a big investment with it.

The sad irony is that these issues are actually not the fault of the managed metadata service, but the applications that are supposed to embrace and extend SharePoint and therefore accommodate it.

The reason I am calling out these two particular issues, is that I can see many people making assumptions that this will just work, make a significant investment in time and effort to develop an IA based around that assumption and then face the painful truth of having to work around them. After examining two issues that I suspect will cause some pain, we will then have a quick look through some of the implications and mixed messages that Microsoft are sending to organisations.

InfoPath Web Suckiness

The first issue that has gotten a bit of attention is the fact that the managed metadata columns cannot be used in browser based InfoPath forms. In other words, if you have a list with a managed metadata column and think that it would be cool to customise that list forms using InfoPath, you will be in for a nasty surprise. You will receive the following error message:

"The following fields in the SharePoint list are not supported because of their data type and will not be available in InfoPath Designer:

MyColumn (TaxonomyFieldType)”

I have a screenshot pasted above – which actually has come from a nice explanation of the problem made by Alana Helbig (hope you don’t mind Alana). Alana shows that if you persist and open the form in InfoPath, the managed metadata field will be hidden away, never to be edited again (and therefore pointless). She also also demonstrates that the behaviour is even worse if the managed metadata column is marked as mandatory. In this case, SharePoint totally spits the dummy if you modify the form with InfoPath and then try to load it. You will get a message along the lines of: “The following required fields are missing from the form” and a ULS correlation ID for your trouble.

Paradocially, InfoPath does support managed metadata when forms are displayed natively (ie not web based). This is proven by the fact that the MSOffice Document Information Panel (DIP) contains a control to display managed metadata information (in case you are not aware the DIP is an InfoPath form). The screengrab below shows Word showing two managed metadata columns (one with the imaginative name of “aaa” which I have clicked on) allowing me to pick terms from the term set.

Taking a closer look, if I edit the Document Information Panel settings in InfoPath, I can clearly see that there is a Managed Metadata picker control.

I never bothered with the SP2010 betas because I was doing a lot of non SharePoint work at the time. But from my reading, it seems that at one point, InfoPath could display managed metadata in the browser but it was yanked from the RTM because of quality issues. Some forums suggest it won’t be corrected in any service packs soon. I certainly hope they are wrong.

Conclusion? I assume Microsoft knew the implications of this decision – yet still, I feel that this will cause a lot of frustration and grief.

SharePoint Workspace 2010 Suckiness

This is the same issue, just using a different Microsoft client application: SharePoint Workspace 2010. SPW2010, if you haven’t seen it, provides a client for SharePoint 2010 that enables real-time synchronization of desktop content with SharePoint documents and lists.

This gotcha is one I fear might be even more insidious than the InfoPath one in certain geographic locations. This is because offline access tends to be an area people will think about later in the project. Where I live (Western Australia), is remote and dominated by mining. As a result, Groove had considerable popularity when you are in the middle of nowhere with nothing but a poor satellite link with >1 second latency ;-). Many organisations will flock to SharePoint Workspace 2010 because of its much improved compatibility with synchronising SharePoint lists, libraries and views.

The problem is that managed metadata columns can be viewed in SharePoint Workspace 2010 but not edited at all. 

Below I show a custom list with a managed metadata column called Projects.  The next image shows the same list in SharePoint Workspace 2010.  Note how the Project column is displayed in the list of projects, but is not displayed in the view/edit item form below it.

Now some of you might be thinking that this is fairly minor, and that not being able to modify managed metadata columns is not a problem. But check out what happens when the managed metadata column is made mandatory. SharePoint Workspace 2010 displays the error below when attempting to view the list.

Ouch! When you click on the More Info link in the ribbon, you are presented with a scarily similar message to InfoPath.

It gets better (mixed messages)

Office 2010 has finally gotten past the use-case I described in my “folders are bad and other urban legends” post. In Office 2010, application centric users have the option to browse document libraries not just by folders, but by metadata as shown below. Note how we are browsing a managed metadata term store in the File>Open dialog box in Word 2010.

The rub with this functionality though, is it only works for managed metadata columns. You might have configured a choice field for metadata navigation and in the browser, you can sort, slide and dice via those columns as well. But in Office 2010, you can only use managed metadata or folders. No views, and no other column types. This will inevitably lead organisations to invest time and effort to create an information architecture around the managed metadata construct. Yet by utilising managed metadata in this way, we consign ourselves to not being able to edit any of this data when we take it offline using SharePoint Workspace 2010.

*sigh* So basically, the more you try and move to a metadata driven, taxonomy approach, the more you make yourself rigid and inflexible.

But there is more…

By the way, managed metadata is not the only column type that suffers this fate. If you enable ratings on a list or library you will see the same problem. The first screengrab below is InfoPath and the next two are SharePoint Workspace 2010.

Conclusion: Violating the laws of motion

More than ever, SharePoint is a minefield of caveats. These examples conclusively disprove Newtons laws of motion because for every possible action, there are just not equal and opposite reactions, but potentially many more opposite reactions. More then ever, practitioners have to understand these complex dependencies, and then somehow explain them to stakeholders without giving them a brain explosion. Is it little wonder that there is commonly a big gap between the slick demos and the reality on the ground?

Thanks for reading

Paul Culmsee

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

The background

Over the last three years, my career trajectory had altered somewhat where I spent half my time as a SharePoint practitioner, doing all of the things that us SharePoint practitioners do, and the other half was spent in a role that I would call sensemaking. Essentially group facilitation work, on some highly complex, non IT problems. These ranged from areas such as city planning, (envisioning and community engagement) to infrastructure delivery (think freeways, schools and hospitals), to mental health, team and relationship building, performance management, board meetings and various other scenarios.

Imagine how much of a different world this is, where a group is coming together from often very different backgrounds and base positions, to come to grips with a complex set of interlocking problems and somehow try and align enough to move forward. We cannot simply throw a “SharePoint” at these problems and think it will all be better. By their very nature, we have to collaborate on them to move forward – true collaboration in all its messy, sometimes frustrating glory.

As a result of this experience, I’ve also learned many highly effective collaborative techniques and approaches that I have never seen used in my 20+ years of being an IT practitioner. Additionally, I’ve had the opportunity to work with (and still do), some highly skilled people who I learned a huge amount from. This is “standing on the shoulders of giants” stuff. As you can imagine, this new learning has had a significant effect on how Seven Sigma now diagnoses and approaches SharePoint projects and has altered the lens through which I view problem solving with SharePoint.

It also provided me the means to pinpoint a giant blind spot in the SharePoint governance material that’s out there, and what to do about it.

The first catalyst – back injury

In January this year, my family and I went on a short holiday, down to the wine country of Western Australia called the Margaret River region. On the very first day of that trip, I was at the beach, watching my kids run amok, when I totally put my back out (*sigh* such an old man). Needless to say, I could barely move for the next week or two after. My family, ever concerned for my welfare, promptly left me behind at the chalet and took off each day to sample wines, food and generally do the things that tourists do.

Left to my own devices, and not overly mobile I had little to do but ponder – and ponder I did (even more than my usual pondering – so this was an Olympic class ponder). Reflecting on all of my learning and experiences from sensemaking work, my use of it within SharePoint projects, as well as the subsequent voracious reading in a variety of topics, I came to realise that SharePoint governance is looked through a lens that clouds some of the most critical success factors. I knew exactly how to lift that fog, and had a vision for a holistic view of SharePoint governance that at the same time, simplifies it and makes it easy for people to collectively understand.

So I set to work, distilling all of this learning and experience and put it into something coherent, rigorous and accessible. After all, SharePoint is a tool that is an enabler for “improved collaboration”, and I had spent half of my time on deeply collaborative non IT scenarios where to my knowledge, no other SharePoint practitioner has done so. Since sensemaking lies in all that ‘softer’ stuff that traditionally IT is a bit weaker on, I thought I could add some dimensions to SharePoint governance in a way that could be made accessible, practical and useful.

By the end of that week I still had a sore back, but I had the core of what I wanted to do worked out, and I knew that it would be a rather large undertaking to finish it (if it ever could be finished).

The second catalyst – Beyond Best Practices

I also commenced writing a non SharePoint book on this topic area with Kailash Awati from the Eight to Late blog, called Beyond Best Practices. This book examines why most best practices don’t work and what can be done about them. The plethora of tools, systems and best practices that are generally used to tackle organisational problems rarely help and when people apply these methods, they often end up solving the wrong problem. After all, if best practices were best, then we would all follow them and projects would be delivered on time, on budget and with deliriously happy stakeholders right?

The work and research that has gone into this book has been significant. We studied the work of many people who have recognised and written about this, as well as many case studies. The problem these authors had is that these works challenged many widely accepted views, patterns and practices of various managerial disciplines. As a result these ideas have been rejected, ignored or considered outright heretical, and thus languish (largely unread) in journals. The recent emergence of anything x2.0 and a renewed focus on collaboration might seem radical or new for some, but these early authors were espousing very similar things many years ago.

The third catalyst – 3grow

Some time later in the year, 3grow asked me to develop a 4 day SharePoint 2010 Governance and Information Architecture course for Microsoft NZ’s Elite program. I agreed and used my “core” material, as well as some Beyond Best Practice ideas to develop the course. Information Architecture is a bloody tough course to write. It would be easy to cheat and just do a feature dump of every building block that SharePoint has to offer and call that Information Architecture. But that’s the science and not the art – and the science is easy to write about. From my experience, IA is not that much different to the sensemaking work that I do, so I had a very different foundation to base the entire course from.

The IA course took 450 man hours to write and produced an 800 page manual (and just about killed me in the process), but the feedback from attendees surpassed all expectations.  This motivated me to complete the vision I originally had for a better approach to SharePoint governance and this has now been completed as well (with another 200 pages and a CD full of samples and other goodies).

The result

I have distilled all of this work into a master class format, which ranges from 1 to 5 days, suited to Business Analysts, Project and Program Managers, Enterprise and Information Architects, IT Managers and those in strategic roles who have to bridge the gap between organisational aspirations and the effective delivery of SharePoint solutions. I speak the way I write, so if the cleverworkarounds writing style works for you, then you will probably enjoy the manner in which the material is presented. I like rigour, but I also like to keep people awake! 🙂

One of my pet hates is when the course manual is just a printout of the slide deck with space for notes. In this master class, the manual is a book in itself and covers additional topic areas in a deeper level of detail from the class. So you will have some nice bedtime reading after attending.

Andrew Woodward has been a long time collaborator on this work, before we formalised this collaboration with the SamePage Alliance, we had discussed running a master class session in the UK on this material. At the same time, thanks to Michael Sampson, an opportunity arose to conduct a workshop in Ireland. As a result, you have an opportunity to be a part of these events.

Dublin

The first event is terrific as it is a free event in Dublin on November 17, hosted by Storm Technology a Microsoft Gold Partner in Dublin. As a result of the event being free, it is by invitation only and numbers are limited. This is a one day event, focussing on the SharePoint Governance blind spots and what to do about them, but also wicked problems and Dialogue Mapping, as well as learning to look at SharePoint from outside the IT lens, and translate its benefits to a wider audience (ie “Learn to speak to your CFO”).

So if you are interested in learning how to view SharePoint governance in a new light, and are tired of the governance material that rehashes the same tired old approaches that give you a mountain of work to do that still doesn’t change results, then register your interest with Rosemary at the email address in the image above ASAP and she can reserve a spot for you. We will supply a 200 page manual, as well as a CD of sample material for attendees, including a detailed governance plan.

London

In London on November 22 and 23, I will be running a two day master class along side Andrew Woodward on SharePoint Governance and Information Architecture. The first day is similar to the Ireland event, where we focus on governance holistically, shattering a few misconceptions and seeing things in a different light, before switching focus to various facets of Information Architecture for SharePoint. In essence, I have taken the detail of the 4 days of the New Zealand Elite course and created a single day version (no mean feat by the way).

Participants on this course will receive a 400 page manual, chock full of SharePoint Governance and Information Architecture goodness, as well as a CD/USB of sample material such as a SharePoint governance plan, as well as IA maps of various types. Unlike Ireland, this is an open event, available to anyone, and you can find more detail and register at the eventbrite site http://spiamasterclass.eventbrite.com/. In case you are wondering, this event is non technical. Whether you have little hands on experience with SharePoint or a deep knowledge, you will find a lot of value in this event for the very reason that the blind spots I focus on are kind of universally applicable irrespective of your role.

Much of what you will learn is applicable for many projects, beyond SharePoint and you will come away with a slew of new approaches to handle complex projects in general.

So if you are in the UK or somewhere in Europe, look us up. It will be a unique event, and Andrew and I are very much looking forward to seeing you there!

Thanks for reading

Paul Culmsee

www.sevensigma.com.au