Hi there and welcome to part 3 of my series on the practice of Dialogue Mapping in the real-world. To recap, in part 1, I provided a brief overview of Dialogue Mapping and in part 2, I described a common real world usage scenario that we perform fairly often as SharePoint consultants.

The rest of this series will change tack a little. In this article I am going to describe a very different Dialogue Mapping scenario to you. This was a huge challenge and a large leap from what I described in part 2. There were some wonderful lessons learned from this work which I will cover off here.

The most “wicked” problems are not technical

My first Dialogue Mapping gig where I was not a subject matter expert also happened to be a real baptism of fire. Here was a problem that I had no understanding of, no discipline knowledge and no sense of background history of the project, the dynamics of the group, nor any idea of the positions of stakeholders on the problem.

By this time my IBIS fluency was pretty much down and I felt very confident with the usage of Compendium. I had not yet travelled to the USA yet to train under Jeff Conklin directly, but I carried his book around with me, and had read it many times over. I had performed Dialogue Mapping many times, however until this point all the projects or subjects that I was involved in I knew a lot about. This time I felt very vulnerable. Your domain knowledge is a form of armour, and it was unsettling to know that you’re going in stark naked. I was intimidated, yet excited at the same time.

So imagine this scenario. There was myself, a facilitator, and *fifteen* strangers sitting across from me. This was double the group numbers of the typical IT scenarios I had previously mapped. I remember emailing Jeff for advice when I heard that there would be so many and I recall him saying that 15 was a lot of people for a newbie. What was I in for! 🙂

Little did I know at the time that this group had been meeting for quite some time before that, but were really struggling on a complex urban planning issue. When I say complex, I mean complex in a social way, rather than technical. Interestingly, the issue was not a technically complicated issue at all. Anybody could have sat in the room and understood most of the dialogue (not necessarily the full context but you would not be completely blinded by science). What made this particular issue complex was the fact that the group members came from several different organisations, representing some quite diametrically opposing viewpoints. In part 2, I wrote about how it was hard enough just to get one IT department to come to the party and that was just one department of a single organisation – sheesh! If you have complained about organisational silos and think it is hard enough to get some degree of consensus within the realm of one organisation, imagine it when over a dozen representatives from different organisations are involved, organisations that straddle the full spectrum of public and private sectors, as well as the community.

There were simply so many stakeholders and interconnected issues that it was very hard to not get bogged down into tangents, repetition and frustration. Now, imagine eighteen months of this environment and the stressful social complexity impacts.

This is a long-term project that I am still involved with, so I will not be taking you through the specific details of this project just yet. Rest assured though, it has been such a great experience that I will write about it in detail in the future. For now, I will focus on lessons learnt so that others aspiring to perform this craft can learn from my own experiences.

People often tell you the best way to learn is to dive right in, and Dialogue Mapping is no exception. No sooner than I had put up a “what should we do…” type root question, it didn’t take long for debate to get … shall we say … rigorous! So I will go over some of the key lessons that I learnt from this experience thus far.

Lesson One: Confidence and assertiveness

The first thing that I had to contend with was not being in control of the conversation to the same extent as before. As previously stated, with SharePoint workshops I tend to direct the flow of the workshop as a mapper and as a subject matter expert. But this scenario was very different. I didn’t know the topic area at all and therefore some of the terms and acronyms made no sense to me. Also being new and unused to the decorum of the group, I erred on what I thought was politeness, rather than annoy the group by being direct and at times, interrupting them.

This, in my opinion, is a mistake and does a disservice to the other participants. It is also probably the most common thing a newbie mapper will experience when starting out, especially with a new group. As a result, the mapping in this first workshop ebbed and flowed. There were a few times where I was mapping the conversation really well, and the participants really engaged with the argumentation as it unfolded on the screen before them. Participants gestured to the map and asked me to add additional arguments and issues to what had already been built there. I could literally hear some of the initially sceptical, suddenly have that magic moment where they see it working. But at other times, during, say a particularly contentious issue, the conversation would fly at a rapid rate of knots. With so many people in the room, many wanted to have their say on these topics. This led to:

1. Side conversations started up
2. Some participants looked away from the map, and started debating directly to each other

As soon as one of these happened, and especially with the latter, I, as the Mapper, had no hope of following the conversation. As you might expect, I would lose focus and the quality of what was captured suffered (hence lots of idea nodes with no connections to anything). The focussing power of the map would be diminished and the wheels would start to fall off.

So remember this above all else. No matter what you do, you must be confident and assertive from the very start to keep the group focussed on the map. Don’t be afraid to interrupt someone to clarify a point, or pause them before they go too fast. If someone else starts to interject, interject back and make it clear that you will get to them as soon as you have finished capturing what someone else has said.

Here is the other critical thing: You must be consistent. It is the first ten to twenty minutes that will set the tone for the rest of the session. This is where people will implicitly learn the decorum of a Dialogue Mapping session and know what to expect. Your actions as a mapper, during this period, is critical to the overall quality of the session. Start it well and it will generally end well.

Jeff Conklin, of course, offers advice for this in his wonderful book on how to dealing with this. But of course, in the heat of dialogue, all of that advice goes straight out the window as you struggle to keep up with the rapid fire dialogue heading your way. Reading about how one should dialogue map is one thing, doing it is another. This is why I call Dialogue Mapping a craft and leads me to my second lesson learned.

Lesson Two: Remember that one guitar lesson you had? (Be realistic)

I think just about everybody at one point has had romantic notions of being a rock guitarist, banging out the blues like Clapton or blistering solos like Kirk Hammett or Brian May. A surprisingly large number of people have actually bought a guitar at some stage in their lives and have tried to live the dream. Most give it up once they find that the gap between their ability to play a G chord and their dream of playing the solo to Hotel California stretches to the moon and back. Inevitably, many guitars ends up collecting dust in the attic, along with the home gym set and many other items that were bought from late night infomercials.

You will hit this with Dialogue Mapping. Remember that wicked problems breed social complexity. Some problems may have some stakeholders with diametrically opposed views and discussion can be quite heated. The romantic notion of your group suddenly solving their wicked problem from your wonderful dialogue mapping has to be viewed with the reality that you still have to learn the G chord and audience can be fickle.

Thus, as far as audiences go, don’t go playing a stadium gig until you feel that you can handle sitting in the corner of a local bar or the school disco. In other words, start small and work your way up. A small, successful meeting will help you develop your style, confidence and then empower you to take on larger groups.

As Ali-G would say, keep it real.

Lesson Three: Stick to your domain of knowledge (at first)

This is a logical extension of lesson two, and also a tricky one because it can be just as much of a worst practice as a best one. This I suspect is probably a lesson on where Jeff Conklin or other dialogue mappers may disagree with me. One of the transitions that you have to make as a mapper is to move from what I would call Issue Mapping to real Dialogue Mapping. Just because you are doing mapping in front of a group, doesn’t actually mean you are necessarily “dialogue” mapping. Dialogue Mapping is often called “Issue Mapping with facilitation”, and when you work within your domain of expertise and you are a mapper as well as participant. Therefore you are not an impartial facilitator. This is the situation I described in part 2 and discovered very quickly, that pure dialogue mapping was much harder and mentally tougher.

But in terms of developing your skills, you will have good results when you are working in an area that you know well. You don’t have to worry about the meaning of acronyms and half of the questions you have likely heard before anyway. Remember though, that in a way it is kind of cheating because you are in effect, using the craft to get people to confront questions that you want answered. But it is an important stepping stone and will help you master lesson 4.

Lesson Four: IBIS grammar in the reptile brain

IBIS is the grammar that you use to map discourse. When mapping rapid-fire contributions from a group of people, they do not want to sit and wait for you to mull over whether their statement was an idea followed by a pro or an inferred question with an idea. If you find yourself having to do this, it is like trying to play a song on guitar and having to consciously think about how to play that G chord. Just think about how much you’d enjoy a Metallica concert if James Hetfield stopped every minute or so on a hard bit of a song and said “Wait, wait.. I’ve done this before… ok, hang on…oops, sorry”. This translation needs to burn itself into your reptile brain so that the process is as automatic as possible. To do this, you need to initially not worry about getting up in front of a group. As Conklin suggests in his book, listen to interviews on the radio or take an article, pull out its main points and create an IBIS map for it. There are a zillion ways to do this.

For all of you SharePoint people, a really excellent, highly relevant way of practice that I use, is to sit in the audience of a presentation at SharePoint Saturday or a conference and issue map the presentation. Below is a sample of some of the sessions where I have done this and the image after that demonstrates how much rationale I captured in the “NZ Web Standards and SharePoint” session.

Another great way to learn is to send one of your maps to an IBIS practitioner and let them pull it to bits. Even those of us who have done this for a while need that constant reinforcement and feedback. Like any grammar, different things can be written in different ways and one person’s IBIS will not always look like someone else’s. (There is another blog post in the works that will show this in a funny way). At various times I have sent maps to Conklin for constructive feedback (and then ducked for cover! – hehe)

Finally, if you are serious about this and like what you are reading, then do what I did – the 5 week Issue Mapping webinar based workshops that Jeff Conklin runs, or if you are in Australia and want something local, then contact me for a half or full-day in-house Issue Mapping intro workshop. Both will not teach you to dialogue map, but by the end of them you will dream in IBIS 🙂

Lesson Five: IBIS translation in the reptile brain

Once the language of IBIS is familiar to you, you can take any argumentation and form a consistent IBIS map. You then have to learn how to listen very carefully because that is half the art. Now you have to take prose and pontification by participants and somehow unpack the points made, articulate them into a summary, and form an IBIS based model in your head, and then commit it to the map.

This can be hard – very hard, and it is nigh on impossible to do without applying what I told you in lesson one. A dialogue mapper is not superhuman and does not have photographic memory. The skill you are developing here is one where you pick out the IBIS elements of some dialogue quickly, as well as knowing when to interject to make sure you do not miss anything.

A great example of this working is when someone has stated something, and although I cannot remember all points, I know that there was a question and three ideas offered. I might pause the conversation before it goes too far and say something like “Ah, that was important and I need to get this right. I heard you say three things there. You questioned the idea of X, and you offered an answer with 3 pros. One was Y, and what were the other two again?”

Conklin explains meeting discourse and question types in his book and the aforementioned workshop in a lot of detail. But once again, to apply it to a real-world situation can only be done by practice (and more practice). The absolute best way to do this is to watch an experienced dialogue mapper perform this and look at how they handle the situation, which brings me onto lesson six.

Lesson Six: Observe

One of the most enjoyable training experiences of my career was to travel to the picturesque town of Annapolis and learn dialogue mapping from Jeff Conklin himself. Up until then, I had been practicing the craft, but after those two days, I returned as a much better practitioner.

The single most important part of the time spent there was when we, the students, dialogue mapped each other as we discussed a real-world issue. We each sat in the hot seat for fifteen minutes or so, trying to map the discussion. We were all being completely evil, deliberately starting side conversations, interrupting and interjecting, playing the role of the dominant type A style participant, jumping all over the place and, overall, just being as difficult as we could.

Unsurprisingly, we all sucked big time trying to dialogue map this. However, when Conklin took the floor, we then saw how exactly Dialogue Mapping was done and what twenty years of practice does. He effortlessly brushed off our attempts to trip him up by observing all of the lessons that I have thus far described, but also with some subtle tricks that we didn’t even notice until he told us afterwards.

After Conklin had wiped the floor with us, so to speak, we all got to have another crack at it, with the benefit of observation and hindsight. This time the difference was significant in our performance and the way that we each handled the “mob”.

Moral? The very best thing you can do is to be involved in a Dialogue Mapping session where it has been done well. Watch carefully what the mapper is doing and how they are conducting themselves and the process.

Lesson Seven: It will make you tired

If you think of all the various things that you have to do simultaneously (for examples listening, understanding, mapping, and managing the group) during Dialogue Mapping, it is amazing that anyone with a Y chromosome can manage it, given that men usually cannot multitask at all. (Case in point: If sport is on the radio and my wife is speaking to me, one of them has to be switched off…Sorry honey 🙂 ).

When you are first learning this craft and you are going to be up in front of a group, plan for only an hour or so. While you have to think quite consciously about things, it will exhaust you even more. Once things become more automatic, you can go for longer. From my own experience, the limit for Dialogue Mapping a big group on a really wicked topic would be about four hours at the absolute maximum. (Usually by then the participants also need to take a break and sleep on it anyway).

Some sessions can be intense, and you, as a mapper, need to be switched on for that entire time. You are listening carefully to every person speak because you are trying to form it into IBIS. So unlike everybody else who can sit there and look interested, yet be mentally switched off, you have to be interested by definition.

One thing about this is that, while you are in the zone, you don’t need coffee. When mapping, you have enough endorphins racing around your system to keep quite alert, but as soon as there is a break, you can find that you will feel quite tired at times, and a well timed coffee can be very handy (real coffee, of course – none of that instant junk!)

The one thing that compensates for what Dialogue Mapping can take out of you mentally, is that exhilarating experience when the group is really getting into the process and the positive feedback that you receive when a really well formed map has been developed.

Lesson Eight: Learn to love “transclusions” and CTRL+R

I thought that I would drop in a left-field lesson learned at this point that is still very important.

Trans-what? Don’t worry – I don’t know why they called it that either. Ted Nelson, who also coined the term “hypertext”, came up with the name but I think the day “transclusion” sprung to mind, he was having an off-day. I asked Conklin what it meant and he said “It’s technically accurate … an "inclusion" of material *across* (‘trans’) several documents”. When I whined about the geekiness of the name he added “There was a time when the word "hypertext" was a wacko term for geeks, you know”. Damn! He’s got me there.

My explanation that will suffice for now? Transclusions is a fancy way of describing the process of breaking your big map up into smaller, linked up sub-maps. I have also heard it referred to as chunking, and when maps get too big, this is a necessity. (For the hypertext nerds that is somewhat incomplete but suffices for this point).

The compendium software that I choose to use for this work also has a great feature in it. Your map is re-drawn automatically when you hold down the control key and press R. I am now in the habit that after entering a node or three, I redraw the map via this method to keep it all looking orderly. That way, if there has been a lot of dialogue captured, you do not end up with a messy, cluttered map that participants find hard to follow. Like lesson number three and four, stopping conversation while you refactor a messy map will cost you group momentum so ideally if you have gotten into the Control+R habit, all you have to do is a quick transclusion at an opportune time.

The best time to perform a map transclusion is when a thread of discussion has been exhausted and the group has moved onto a new idea or area in the map. A trick I learned from Anapolis was to sit up and say something like “Okay, let’s just pause for a minute.” (Holding up my hand), congratulate the group on the quality of what they have captured and then say something like “Let’s just put this stuff into its own pigeonhole, so we can now focus on X idea”.

Lesson Nine: Nurture the holding environment

Okay, so if there is to be one big serious lesson learned, it is this one. To make the point, I am going to quote Heifetz and Linsky from their excellent book Leadership on the Line. You can read a PDF press release here, specifically the section entitled “Control the temperature.”

Changing the status quo generates tension and produces heat by surfacing hidden conflicts and challenging organizational culture. It’s a deep and natural human impulse to seek order and calm, and organizations and communities can tolerate only so much distress before recoiling.

If you try to stimulate deep change, you have to control the temperature. There are really two tasks involved. The first is to raise the heat enough that people sit up, pay attention, and deal with the real threats and challenges facing them. Without some distress, there is no incentive for them to change anything. The second is to lower the temperature when necessary to reduce a counterproductive level of tension. Any community can only take so much pressure before it becomes either immobilized or spins out of control. The heat must stay within a tolerable range—not so high that people demand it be turned off completely, and not so low that they are lulled into inactivity.

Heifetz and Linsky talk about maintaining the “the productive range of distress” but I have heard many metaphors like this. Another I like is “creative abrasion”, coined by Leonard and Swap in their excellent book When Sparks Fly . Both are essentially talking about making the whole environment conducive to getting the best out of the participants.

The key takeaway is this: Each group is different and each situation is different. In the normal discourse of the meeting, there will be times where the group works together in almost perfect unison and times where one wrong word will destroy that balance and require the group to stop, reset things and move forward. This is not about IBIS either. The fact is that over time, a particular pattern will emerge in the decorum of the sessions, where conducting the sessions or approaching the mapping in a particular way, will work consistently well for the group.

Let me give you a classic example that was absolute genius on the part of my client who did exactly this. Before Dialogue Mapping for a group of concerned residents who were facing the prospect of significant change to the amenity of their homes, a bus was hired and the residents were taken to an area where a similar urban transformation had been made ten years before. We all walked around the area for an hour, soaking in the vibe, learning about the history of the area, how the area was redeveloped and how certain planning challenges were overcome.

This allowed the participants to get a real sense of the issues they needed to confront, and they felt it with all senses, sight, sound and tactile, rather than some cold, rather detached room with a projected map on the wall. Later, when I dialogue mapped the session after the bus tour, the group did a fantastic job and the quality of the rationale that was captured was much richer and faster, through that sensory immersion that took place before the mapping process began.

So just remember, Dialogue Mapping is a great holding environment in the sense that Heifetz and Linsky talk about. It is a wonderful “rich container”, as Conklin puts it, for fostering and maintaining creative abrasion. But as the bus ride example shows, there is a lot of things that you can combine with it to enhance the experience further.

More examples like this will be covered in part 4 of this series.

Thanks for reading

Paul Culmsee

www.sevensigma.com.au

Hi there.

Welcome to part 2 of a series of articles on the craft of Dialogue Mapping – something that forms a significant chunk of my SharePoint and non SharePoint work. In the “One best practice” series of articles, I explained IBIS. In part 1 of this series, I introduced the facilitation part that goes along with IBIS. In this article, I’ll spend more time on how Dialogue Mapping works in real world scenarios.

In the previous article, I wrote about how important it was for tools and methods like this to be intuitive and inclusive, allowing you to start from any given point. I also wrote about how methods need to be adaptable and grow, accepting and accommodating for the fact that understanding of the problem changes over time. In any project or problem that is novel or new, there is, invariably, a large degree of unknowns and uncertainties among participants. Solutions are not always obvious and we should be careful not to presume that we are doing something wrong if we reinterpret the problem, as a result of learning more or seeing a suggested solution.

New IT projects, by definition, often fall into this bucket and SharePoint is a poster child for this type of project. But in saying that, some of the toughest problems on the planet are not technically complicated at all and SharePoint is actually not the most wicked problem that I have used this craft on. More on that in part 3…

So, the first example of the practice of Dialogue Mapping that I will tell you about is how effective it is in dealing with IT department physics and nerd law.

IT department physics and nerd law…

Before consulting on any IT project, it is important to understand the inner workings of the IT department. For SharePoint this is particularly important because of its amazing ability for exposing the inherent constraints of IT departmental physics in a negative way.

There are certain fundamental principles of how IT departments work that I have classified into several immutable laws. They are:

1. The web team dislikes the corporate marketing team because marketing always wants the same garish lime-green colours they have for their printed brochures;
2. The infrastructure team dislikes the web team because they see them as a bunch of cowboys who mess with forces they do not understand and do not have to deal with the consequences of it;
3. The web team dislikes the infrastructure team because they are a bunch of control freaks who won’t even allow you to fart without filling in a change control form; and
4. Nobody likes the misunderstood compliance/records management team at all. They unfortunately perpetuate this by droning on continually about whatever compliance standard/s the organisation has to adhere to.

There are some interesting sub-laws that go along with the four immutable laws. For example, you have only one shot to ask the right question to a good infrastructure guy. In other words, the way you word the question will tell them a lot about your technical chops and if you word the question badly, you will be forever banished into the same sin bin where they hold most project managers and sales people. Once sin-binned, it takes an enormous amount of effort to get out. Similarly, when approaching an application developer, always start the question from the presumption that the error you are encountering is *not* in their code, despite you being fairly certain that it is.

Ted Dzubia is a tech writer equivalent of Dr House. A terrific writer with brilliant insight woven between layers of blistering attitude and well placed vulgarity. He cites a classic example of what he calls “nerd law” and it cuts to the heart of the problem that projects like SharePoint face.

The only way to adjudicate Nerd Law is to write about a transgression on your blog and hope that it gets to the front page of Digg. Nerd Law is the result of the pathological introversion software engineers carry around with them, being too afraid of confrontation after that one time in high school when you stood up to a jock and ended up getting your ass kicked.

If you actually talk to people, network, and make agreements, you’ll find that most are reasonable…

Defying the laws of IT physics

One of my earliest uses of Dialogue Mapping was to deal with a classic case of IT department physics and nerd law. A completely new SharePoint project, with no in-house staff having significant expertise in the product, has decided to implement SharePoint for an intranet. To make it interesting, the project is instigated out of the web team. As the immutable laws explain the forces of IT nature, this means that several things happen by default:

• The infrastructure team will automatically be against it because they don’t want to get saddled with, yet another, enterprise application to support and manage
• The records management team, having already been scarred from trying to convince an uninterested workforce that the existing records software does not suck, now will assume that SharePoint is going to take over their area.
• The software development team will assume that SharePoint is here to replace all of their lovingly coded, yet bloaty and insecure line-of-business systems.

At this point, each side starts googling and discovers that the means by which they will address the “obviously” out-of-bounds web team is via this thing called “Governance”. Governance is then mentioned in every second sentence, in a manner to improve their respective positions. This is the nightmare scenario where governance is used as a tool to perpetuate nerd law. This is to be avoided at all costs.

In this project, I introduced the dialogue map from the very first meeting with a simple root question “What are we going to do with SharePoint in Organsiation X”?

Now in this case, SharePoint is my core discipline, so unlike some of my subsequent engagements. I already had a bunch of questions that I wanted the client to start pondering. Being well aware of the destructive forces of the immutable laws of IT, I put down some immediate sub-questions.

• What are the goals of the project?
• What are the governance requirements of this project?
• What are the infrastructure requirements for SharePoint?
• What should we do about operational support for SharePoint?
• How will we develop the project?
• What else do we need to be aware of?

The web team had also developed a project charter which explained, in some detail, the background to this project and how we came to be where we were. I linked this into the issue map. Something that also came up fairly quickly was that the organisation had just completed a large strategic review project and an Information Management Plan had been drafted and approved. This was a key document that pretty much set the direction of the organisation for the next four years.

Below is the map showing these initial questions, along with the project charter and Information Management Plan. Note how I can attach documents into the IBIS map along with the argumentation.

Adaptive requirements gathering…

As you can imagine, we started working through these questions. Given that the SharePoint was completely new to the team, I was perfectly happy for the web team to jump around to different areas of the map and fill it in. Fairly quickly, the participants identified that a staged approach would be needed for implementation, and we initially would flick between goals and stages until that began to solidify that the details of the implementation matched the goals.

This map evolved over a period of time where we would spend time on-site with the team, performing training and advisory on SharePoint itself. As understanding of SharePoint’s capabilities grew from the use of a demonstration virtual machine, we refactored and re-examined the map as new knowledge, insights and/or understandings came to light. The team took to dialogue mapping like ducks to water, and the web team leader downloaded and installed compendium so that she always had the latest project rationale on her desktop.

This also had advantages to my colleagues who were also involved in the training and advisory phase. Since each of us were trained in IBIS and dialogue mapping, any one of us was able to conduct a session and the new map would be redistributed to all participants. Thus, even if I did not attend a meeting, I was able to very quickly orient myself around any new questions, issues or ideas.

Planting seeds of buy in…

One area that many web teams are weaker on in their knowledge is in infrastructure. In this case, I had a dual role as dialogue mapper and SharePoint consultant because I know how infrastructure guys think. After all, I used to be one myself. Therefore, I wanted to ensure that a lot of infrastructure considerations were captured and made explicit in the map before we took it to the other teams. I ensured that farm topology options were captured, backup and recovery implications, virtualisation and the like were covered. Additionally, many questions were captured but not answered, such as network topology, active directory configuration, large database management, SLA and the like. A snippet of this is below.

One thing that we were all aware of was to ensure that records management considerations were duly covered. By having a SharePoint environment to use and learn from, the team was able to quickly become much more informed about SharePoint’s view of the world, especially in relation to the orientation of metadata, sites and site collections. We confirmed that the goals of the project was an intranet and the sort of document management that would be required would be skewed very much towards team collaboration. The web team was aware that a records management system existed and also some members had some previous experience working with these systems. We ended up creating a very detailed map outlining the strategy for integration with records management, the options for integrating the current records system with SharePoint and most importantly, the golden rules around integration that ensured that the records management system was still the authoritative location for records. Later, Microsoft and the records management vendor visited the site and presented the latest information on the integration for the product and SharePoint, and the salient points were added to the map. Below is a snippet of the map discussing this topic (deliberately obscured for privacy, but you can get a good feel for the breadth of the discussion).

The acid test…

Fast forward another couple of weeks, and the team now has a pretty good understanding of SharePoint and a very well factored map. By this time, others in the department had been called in at various times and added their rationale to the map, answering some of the open questions. Next stop was the ultimate test. A meeting was called, where all of the opposing forces were going to be in the one room at the same time. A dozen people in all, key decision makers who didn’t always enjoy a cosy relationship, crammed into a hot, tiny room with a portable projector.

The web team manager introduced the project via the charter, and we all worked our way through the map. We discussed the goals of the project, how they related back to the strategic Information Management Plan, how we were structuring the phases to support those goals, what was in/out of phase 1 and why, and of course, the considerations that we had made in relation to the other IT Teams. After around 90 minutes, we were done and the group proceeded to give feedback.

The records management team was clearly relieved. In producing the map, we had demonstrated a good awareness of records management considerations and we made it clear and explicit in the map that SharePoint was *not* going to replace or devalue what they already had in place. They loved the fact that we had captured rationale that discussed the pros and cons of the various methods and techniques we could use for integration between their tool and SharePoint as they did not know about this. The infrastructure team was also happy for the same reason. We had captured many of the questions that they would have asked themselves of the web team. We had managed to pass our “one shot” test and were not sin-binned for being naive to the nuances of IT infrastructure.

Key success factors and conclusion

All in all, in that one two hour meeting, everybody was on-side and excited about the project. It was fed back to us that achieving such buy-in within one meeting across these different IT departments was previously unheard of in this organisation.

The key success factors boiled down to 3 major factors:

1. The participants in the Dialogue Mapping process were extremely enthusiastic with the process. We did not sell Dialogue Mapping at all with this engagement – we just used it from the very first workshop. By the end of that first workshop, the participants were very impressed with the richness of what had been captured and it became the standard way we conducted workshops and requirements meetings.

2. The visibility and clarity of the rationale meant that any major concerns of the other teams were mitigated by the fact that the questions they were interested in were either addressed or, at the very least, captured and visible on the map. For many parts of the map, the web team made no pretence to know all of the answers. However, by raising those questions in the map, it gave the other teams much more assurance that the web team were not running off and doing their own thing with a lack of consultation.

3. As a mapper, knowing a fair amount about SharePoint meant that fast-tracking of learning was taking place, both at the map level and at the product capability level. Providing the team with a demo virtual machine allowed members to learn about the product, and then applying that learning back to their understanding of the problem in the map space. This was a great way for them to iterate and converge on the solution much more quickly than fumbling around with the product alone. As a SharePoint practitioner, I was able to foresee problem areas and then utilise the rationale in the map to help steer the various participants into determining the optimum solution for their circumstances.

All in all, this was a great example of the power of Dialogue Mapping in speeding up the normally laborious process of stakeholder consultation and developing a shared sense of what was trying to be achieved. The one thing I would say about this method however, was that being a subject matter expert, as well as the dialogue mapper, meant that I was able to exercise a fair degree of control over the flow of the map. This is because I was both a participant as well as the mapper, both capturing as well as answering questions, raising concerns and flagging issues that may have been missed otherwise. For any aspiring dialogue mappers out there, this is actually a good way to start because you can concentrate on creating well formed IBIS, and not have to worry about whether you are articulating a participant’s dialogue correctly. Almost by definition in this case, you know exactly what the participant is talking about and getting the context onto the map in IBIS notation is not a huge mental challenge.

But there is more…

If I concluded this series now, I would be misleading you. The form of Dialogue Mapping that I undertook here was not what I would call pure Dialogue Mapping. In my explanation of the above process, I was a participant, strategist, mentor as well as mapper. My knowledge of the problem space was very detailed and I used Dialogue Mapping as a tool to help steer the group to a position that enabled them to improve their chances of a great outcome.

In part 3, I will detail more about the craft of pure Dialogue Mapping. In this case, you are not in the room because of any particular expertise and you often do not know any of the stakeholders either. Your critical success factor is to produce a great map and thus, make a positive difference for a group in tackling a really wicked problem. As you will soon see, that changes things quite a bit…

Until then, thanks for reading

Paul Culmsee

www.sevensigma.com.au

I’m very tempted to start this post like a dodgy wealth-guru infomercial. You know the ones with lots of imagery of people living the dream of financial freedom. I am thinking a montage of a resort, a large yacht anchored in a topical bay, carving up the water with a jet-ski and then a shot of me standing next to my Ferrari, champagne in hand, with Megan Fox on my arm. My message would be that for a “small” fee of $10,000, you too could learn the secrets to your financial freedom in an intimate, exclusive but “intensive” weekend workshop. Just you and the 15,000 other people that pack into the convention hall 🙂

Alas, we both know that this is never going to happen but this post may have a little of that feeling to it. I have titled it “The secret to understanding governance”, because I think there is a way to understand governance that will help you, your colleagues and your team members significantly. Like all good “wealth guru” infomercials, I’m going to give you some hints and I’m kind of hoping that you will then be interested in attending a workshop to find out the rest.

The one difference between the wealth guru and me, though, is that I will never have Megan Fox hanging off my arm, and I am actually going to tell you something useful in this post.

So, what is this big “secret”, anyway?

Definitions definitions definitions

One thing that we all tend to get suckered into doing at times is feeling the urge to define “stuff”. Academics do it all the time. I’ve read countless papers where the authors start out with a ten page examination of all the past definitions of their given topic, before proceeding to tell you why those definitions are inadequate in some way, followed by their own revised definitions. They spend the rest of their essays justifying why their definitions are more correct than their predecessors.

Defining stuff is a time consuming and tiring exercise. Since we live in a world of constant change there will always be new influences which shape and frame perceptions. Therefore, the definition that you spent so much effort on coming up with is redefined by the next academic or blogger who follows the path that you took. Sometimes a whole new word is invented, or an existing word is suddenly used in a new context and the whole cycle starts all over again.

I once explained the philosophical and process aspects of Agile/Scrum to a seriously experienced project manager. This was a fellow who was the PM when skyscrapers were erected. He listened carefully to my explanation, sat back and said “I’ve been doing that for 30 years. There’s nothing new there”. I also found a similar observation in “The Small Business Guerrilla Guide to Six Sigma” by Jay Arthur.

Over the years, I’ve had a chance to learn and study just about every “brand name” systematic improvement methodology. Guess what…they are all pretty much the same. To appear different, consultants have changed:
– the name to Six Sigma (from Total Quality Management)
– the acronyms to confuse the unwary (PDCA to DMAIC)
– the number of tools required for success
– the number of steps in the process (5 to 14 steps)
but…
– the key tools are the same
– the process for using the tools is the same
– and the results are identical assuming you can figure out how to use the wide range of tools and processes

In my opinion, defining things to the nth degree is a zero sum game. Often you confuse the issue more than you clarify it because in your attempts to explain something, you incorporate new words that you then have to explain.

Some ROI Wisdom

Several years ago I was attending a job interview for a promotion and the topic of return on investment came up. I had made the point that most things could be quantified and one of the interviewers fired back “Well tell me how you measure quality?”

That was a curveball that I wasn’t expecting, and I didn’t have an answer (and never got the job either).

Some time later, I read a terrific book by Douglas Hubbard on measurement and return on investment called “How To Measure Anything”. It armed me with some new kung-fu skills and also gave me the perfect comeback answer that I sorely needed during that interview. The question “How do you measure quality?” actually makes very little sense to ask. The reason is quite simple. “Quality is not what you measure. It is the effect it has on something that you measure”.

It is very easy to illustrate the logic behind this important point. Undertaking a quality initiative costs time, money and resources. You are only spending that money and investing those resources because you believe that undertaking this quality initiative will make a positive difference in some way. Otherwise, why bother? If you do not believe that it will make a positive difference, why throw money away?

So, if asked “How do you measure quality?”, you can answer by asking questions back, along the lines of:

• “What does improved quality look like to you?”
• “What is the effect of quality?”
• “How do you know your quality initiative is working?”

The answers to these questions tend to start with “increased this” or “decreased that”. It now should be abundantly clear why asking “How do you measure quality?” actually makes no sense. In fact it is completely the wrong question to ask. Instead, by re-framing the question slightly, you suddenly have answers that can be quantified using the techniques that I detailed in my “Learn to speak to your CFO” series and provided in my free SharePoint ROI modelling spreadsheet.

This same logic applies to other words that are better understood by examining their effect, rather than trying to (re)define them. Examples:

• Security
• Flexibility
• Collaboration
• Resilience
• Wellbeing

All of these share the same characteristic as “governance” in that they are easily understood by the effect they have, but harder to define in a universal way.

The secret to understanding governance

The really silly thing about all this is that I did a talk on SharePoint ROI at the Best Practice Conference in Feb 09. In that talk, I explained the above chain of logic and made the point that the way to find measurable success factors with anything that seems “unquantifiable” is to ask the “what will it look like if we do this?” type question. I used this logic to come up with measurable key performance indicators that enabled me to simulate the future financial return (internal rate of return and net present value) of a large SharePoint investment for a mid sized organisation (slide deck and spreadsheet can be downloaded here).

But despite writing several articles and speaking on this topic, the ROI stuff was one of several clouds of “stuff” that was floating around my brain. SharePoint governance was also floating in one of those clouds too, as well as broader governance in a planning and sustainability context. It took a casual comment from Bjørn Furuknap that suddenly gave me one of those wonderful bolts of inspiration and clarify, where these disparate clouds of thought suddenly coalesced and I made a significant breakthrough in my understanding.

Define “governance” in any way you want. I really don’t care – so long as you understand the difference it makes *for you* and you ask the same question of your other stakeholders and participants. Put aside the need to define governance for a while, and instead view “governance” as a means to attain a desirable future state. Agree with each-other on what that state is going to look like. Now tell me the differences between where you are now and that desirable future state.

By asking the question this way, you not only stimulate much more meaningful debate, you will have a much better understanding of everybody else’s frame of reference and the emphasis that they place on various aspects of that difference. The “definition” of governance that you are trying to find will start to suggest itself through those differences between the current and desired state. At the end of the day, that is what really matters.

Instead of reading a methodology like COBiT or ITIL, or following what people like me, Joel, Robert Bogue, Andrew Woodward, Dux Sy and Ruven Gotz say, look at your own needs as an individual, a team and then an organisation. Determine where you want to be, include IT and non IT views and then start to think about what you need to do to get to your desired state.

Congratulations, you’re now officially “governing”. Wasn’t that hard, was it? 🙂

Best practices versus worst practices

This same “secret” to understanding governance also provides the answer to why experts disagree on what is a “best practice”. I sometimes will read a “best practice” and think to myself “No way, that would never work”. Yet, although it doesn’t work for me, I rarely come away thinking the person making the recommendation is actually wrong. When you understand that the “best practice” made a positive difference, and it moved the organisation further along the road from the undesired present state toward the desired future state, then it is perfectly clear why one man’s best practice is another man’s worst practice. No matter what you did, you moved forward – and that is a good thing.

Furthermore, if you agree with the notion that the “best” solution to a problem is the one that has the most shared commitment among participants to seeing it through, then I argue that a perceived “worst practice” with deep commitment and buy-in among stakeholders will deliver a better solution than a “best practice” with poor buy-in and commitment among stakeholders.

Want to argue that point with me? (I’ve got more ammo than this!) Then you can spend 3 days doing that if you want!

…for a small fee 🙂

My intent with this post was to try and lift some of the fog and confusion that surrounds this nebulous thing called governance by suggesting that defining it to the nth degree is not the way forward. “Best and worst” practices? Both are commonly context and culture dependant. Instead, your (multidisciplinary) team needs to agree on and understand your desired future state and where you are now. By starting with the end in mind you will be able to collectively determine what processes, tools and methods to use to get to that place.

The philosophical approaches that I have described in this article are just the tip of the iceberg in relation to the work that I have been doing with Andrew Woodward, Dux Sy and Ruven Gotz for the planned “Governance Mentoring Workshop”, to run for 3 days prior to the August Best Practices Conference. This workshop will be unlike any other SharePoint governance training that is currently in existence and much of the material is completely original and not borrowed from any of the traditional SharePoint governance material that exists today.

Finally, to go back to infomercial mode…

This offer is for a limited time only. Act now! If you’re not completely satisfied, we offer a full “return to base” warranty 🙂

Act Now!

This offer is strictly limited!

Act Now!

Pick up the phone and take the first step toward the new life that is waiting for you!

Act Now!

Thanks for reading

Paul Culmsee

I listened to Steve Smith talk about user engagement on the SharePoint Pod Show today and found myself nodding in strong agreement with many points that he made. So while in that mood of stakeholder engagement and how to achieve it, twitter made me aware of a really terrific Debategraph map on the topic of “Core Principles of Public Engagements” and think it is mandatory learning material for any SharePoint architect/collaboration consultant/business analyst/business improvement specialists/<insert title here>.

The map above, came from a collaborative effort called the “Public Engagement Principals Project”. This is a recent project (February 2009) and the aim was to “create clarity in our field about what we consider to be the fundamental components of quality public engagement”. The outcome of this project are seven recommendations that reflect the common beliefs and understandings of those working in the fields of public engagement, conflict resolution, and collaboration.

1. Careful Planning and Preparation
Through adequate and inclusive planning, ensure that the design, organization, and convening of the process serve both a clearly defined purpose and the needs of the participants.

2. Inclusion and Demographic Diversity
Equitably incorporate diverse people, voices, ideas, and information to lay the groundwork for quality outcomes and democratic legitimacy.

3. Collaboration and Shared Purpose
Support and encourage participants, government and community institutions, and others to work together to advance the common good.

4. Openness and Learning
Help all involved listen to each other, explore new ideas unconstrained by predetermined outcomes, learn and apply information in ways that generate new options, and rigorously evaluate public engagement activities for effectiveness.

5. Transparency and Trust
Be clear and open about the process, and provide a public record of the organizers, sponsors, outcomes, and range of views and ideas expressed.

6. Impact and Action
Ensure each participatory effort has real potential to make a difference, and that participants are aware of that potential.

7. Sustained Engagement and Participatory Culture
Promote a culture of participation with programs and institutions that support ongoing quality public engagement.

Despite the fact this map is all about public engagement, this material is absolutely the best advice you could ever get for dealing with user engagement in your SharePoint endeavours. If you have any interest whatsoever in the mystical arts of getting true understanding and buy-in among your organisational stakeholder group, then this map (and its underlying documents), is for you.

Also, be sure to use the Debategraph toolbar to explore the detailed information in the root node. There is a lot of supplementary information in this map that you can easily access by clicking on the “Show detailed text and comments” icon (highlighted below).

If you are using the Seven Sigma Web Part for Debategraph, the Map ID is 16220 and you can incorporate this map into your broader governance site. I’ll be linking this map into my SharePoint governance map later as I think it complements, and expands upon the information contained there.

I think these seven principles make a terrific starting point for developing your own guiding principles around user-engagement as part of your governance efforts.

Finally, if you want more detailed information about how this map came to be, then consult the links below

• PDF Version – A downloadable version of the Core Principles document.
• List of Endorsers – Complete list of both organizational and individual endorsers.
• Expanded Core Principles Document – View the text of the complete document online.
• PEP Forum – This forum is where much of the conversation about this document took place.

Thanks for reading

Paul Culmsee

Hi

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

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

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

Paul

Hi all

If you were going to slot me into a little stereotype box, then you would slot me into the “IT pro” side of the fence. My coding is okay, but my real vein of expertise lay in infrastructure and over my career, I developed what I think is a reasonable troubleshooting instinct.

I’ve also worked with developers for the whole of my career and have the scars to prove it. The thing about developers is that they have this in-built reflex that until yesterday I did not have a word for. Then it came to me.

All developers have a little Russell Crowe inside of them!

Why do I think this? Am I suggesting that developers are handsome, rugged types who melt your heart with their piercing eyes?  Oh, please. Allow me to explain with a simple mythical conversation with Mr Crowe. Let’s pretend you are a movie director.

You: “Hey Russell, we need to do another take, your dialogue wasn’t quite right.”

Russell: “Yes it was.”

You: “No seriously, I think if you had a look you’ll find that you missed a word or two.”

Russell: “Completely impossible. You are obviously an amateur and have no idea about acting.”

You: “I’ve directed twenty films and…”

BAM!!!  (Flying telephone hits you in the head at high speed, knocking you unconscious.)

Russell: (2 days later). Okay, so there was a minor issue with my dialogue, but the script was bad to begin with”

This exchange is somewhat representative of how programmers can occasionally be when it comes to troubleshooting. I remember one case where I was the “Cisco guy” who had problems with a developer who was so utterly fixated on “the network” being the cause of problems with his media streaming application. This created the classic “dev vs infrastructure guy” showdown, which we all know is usually won by the person whose home turf the battle is fought on. Therefore, the developer blaming “the network” and then going up against the “Cisco guy” is like Microsoft trying to win search market share off Google. The battle is so one sided it’s almost cruel to participate – but you feel it is your duty to put the little upstarts in their place anyway.

I have won the majority of such battles, not because I am any good, but because the developers have thrown the metaphorical phone at me before I’ve finished asking them if they would like a coffee. As a result of their inner Russell Crowe hurling the phone so quickly, their aim is way off, and the phone usually misses me, bounces off the wall and takes out their boss or some other authoritative figure.

So, they cop some heat and sulk in the corner for awhile, but do developers learn from this? Hell, no! The reason why this is so, is because little Russell doesn’t like to lose, and when he re-emerges, he causes temporary amnesia of all previous battles. Of course, his opponent remembers all, and the next battle is even more cruel that the previous one and the outcome is assured.

So, yesterday, my friend and colleague did his first “Russell Crowe” for some time. He hit a problem, and misinterpreted the cause and went down a path that led him to a very tunnel-vision view of what was wrong and what the solution was. He described the problem he was having to me and it didn’t feel “right”, but he was pretty insistent he was on the right path. So, I asked Twitter and got back a couple of suggestions and as soon as I put one to him… BAM!! Russell Crowe appeared and threw a phone at me.

“Well, they are obviously amateurs and haven’t a clue about the SharePoint SDK” was the gist of the response.

One of the respondents was Bjorn Furuknap, who I can assure you is *not* an amateur :-).

Anyway a few minutes later we found a different way to troubleshoot which pretty quickly pinpointed the problem. My colleague was very contrite and good natured about it as I teased him mercilessly. I later mentioned to Bjorn that I had just dodged a metaphorical flying phone and he said this wonderful quote which I think sums it up.

“Of course. He’s a developer. We’re all like that. It is always some else’s fault!”

Thanks for reading

Paul Culmsee

www.sevensigma.com.au

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

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

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

Thanks for reading

Paul Culmsee

www.sevensigma.com.au

This post was supposed to be called “SharePoint Governance is not a deliverable” – hence the pizza above, but my secret evil plan has worked faster than expected! Read on…

When I met with Dux Sy for breakfast the other day in a diner that looked remarkably like the set from Happy Days, our conversation covered various areas of topics around US vs Australian culture, SharePoint governance, project management, food, wicked problems, sense-making and my two kilograms of Vietnamese coffee beans that came from a weasel’s digestive tract :-). Smart guy, is our Mr Sy indeed; good business acumen – well suited to being a SharePoint sensei.

But one part of that conversation triggered a memory about a post that I was supposed to write and then completely forgot about. Thanks for jogging my memory, Dux.

Right in the middle of writing said post, SharePoint Joel has just posted some thoughts about his recent excellent governance document, inspired in part by some twitter conversations with Andrew Woodward. Andrew, like me, dislikes the word “governance” because he has seen the same confusion that can arise. Joel in his post, nailed totally what I was going to write about here, and referred to an old post of mine written in October 2008 where I undertook an experiment on whether I could make my own buzzword.

So, I think I will kill two birds with one stone here. I’ll post my original idea – in effect echoing what Joel said with regards to how to best use his governance plan, and I will also talk about the exciting adventures of intrepid hero “Governance Man” and vain attempts to defeat his arch nemesis “Dr Wicked” :-).

The precedent…

I have had a couple of experiences now, where I have been called in by clients who have the typical SharePoint chaos. Things have gotten out of hand and as a result, key stakeholders started to lose faith, and the project team really felt the pressure from the powers to be. There were strong undercurrents of desperation to get things sorted, like… yesterday. Under these circumstances, they asked for help on “governance”. They needed “governance”, they must have “governance”  and they spoke about governance as if it was something that a pizza driver can deliver to their door (and if it was not there in 30 minutes, it was free).

I was being a bit flippant when I talked to Dux about it, because both times I was dealing with the project manager in charge of each SharePoint implementation. I recall saying something along the lines of “some project managers have a lot to answer for here”. What I meant by that was “governance” in their eyes was a 1 line item on a work breakdown structure on their project plan – a project deliverable. As a result, they had this impression that by getting me to produce a “governance document” would somehow solve the chaos. Therefore, I had to answer the standard HMHL question (how much, how long) so it slotted nicely into the work breakdown structure.

*Sigh* if only it was that simple.

This hopefully provides an insight to why I am uncomfortable with the word. What these clients, in fact, were dealing with, was a crisis of confidence with the platform. They were unable to provide a level of assurance to the organisation that the platform could meet their needs. The lack of confidence turned to user pessimism, and the pessimism turned to outright rejection of the platform by some sectors.

Adding to that, Joel Oleson recently published a major revision of his sample governance plan, which I had the opportunity to review and made a few suggestions here and there. It is a great template to use for many organisations, but my fear is that people will think that this plan alone will be all that is needed because it has “governance” in its name. I mean, as a template, it is the best thing by far that is out there right now and adds significantly more meat than the governance checklist guide does.

“Governance Man” vs “Dr Wicked” (and “Agile Boy")

I have listened to the governance godfather Robert Bogue suggest that governance is a process and I think that is pretty close to the mark. He has also suggested that governance at its core is about risk management which I also agree with – or at least I do partly. As previously stated, I’ve always found that “governance” never really succinctly nailed this risk management emphasis. Isn’t risk management about providing assurance to stakeholders? It certainly makes more logical sense than saying “providing governance to stakeholders”.

So, in October last year, I wrote a post about the curse of “governance” now achieving buzzword status which makes life confusing for all, given that “governance” is talked about a lot, yet seemingly hard to understand and/or execute. To make it interesting, I blamed it all on my arch nemesis – “Governance Man”. You can see him in the photo below (check the T-shirt). Although the disguise is almost perfect (like mine), can you pick who he is? 🙂

In that October 08 post, I also executed my “secret evil plan ™” which actually had little to do with the governance/assurance debate itself. I simply wanted to see how long it would take for a new buzzword to take hold. I spoke of “SharePoint Assurance” and with a little help from my trusted super-friend Andrew “Agile Boy” Woodward, my arch nemesis – that meddlesome “Governance Man” fell into my wicked trap by blogging about it!

Mwaahahahahah… more people debating it! Another piece of Dr Wicked’s secret evil buzzword plan falls into place :-).

The unified theory of everything…

I recently did some Dialogue Mapping work for a local government organisation. In performing that work, I finally came across a definition of governance that I liked because it was simple and succinct and did not come from IT. It also has the positive side effect of putting my assurance instinct into the right perspective, too. Governance was defined in these terms:

“The word ‘govern’ means to ‘steer’. We aim to steer the energy and resources available for the greatest benefit to all”

Now we look at the definition of assurance (ripped from quality assurance)

“Assurance provides confidence in a product’s suitability for its intended purpose. It is a set of activities intended to ensure that customer requirements are satisfied in a systematic, reliable fashion.”

I see these as quite distinct activities and the key words in the above definition are “intended purpose”. Defining and maintaining “intended purpose” is the realm of governance via ‘steering’. Thus, governance is all about achieving shared commitment among stakeholders to a solving business problem, whereas assurance is all about achieving and maintaining confidence in the solution.

Paradoxically, you actually need both governance and assurance, for each to stand on their own individually. I mean, how can you achieve shared commitment without confidence? How can you have confidence without a shared commitment to a course of action? This is wicked problem fodder right here, and for a more detailed exploration in the relationship between shared understanding, shared commitment and project failure, then read the one best practice to rule them all series.

This, I think gets, to the root of why I get nervous when I hear the term “governance” bandied around. So, I take Joel’s point that assurance may “lack legs”, but assurance, to me, has a clearer meaning for the “confidence” side of governance. As I mentioned earlier, a nice little test is to say out loud these two statements and see which one ‘feels’ right.

• “We have to provide better SharePoint assurance to the business.”
• “We have to provide better SharePoint governance to the business.”

For what it’s worth, this article is not the first one to try and unify these concepts in this way. John Miller previously wrote a nice article that relates these two concepts together neatly way before me.

Are we splitting hairs? Yup, totally. In fact the next section is really what is important.

It’s all in the attitude…

Joel talks about governance in terms of “defining a service offering” as well as “mitigating conflict within an organisation”. No objections to both of these arguments as that is not really assurance. But my own “high level” governance guides are usually 2-5 pages, and guess what? I define the service offering, the guiding principles and define the roles and then refer to the other documents where the bulk of the material ends up. More often than not, these documents are assurance oriented documents.

Let’s talk for a minute about the “mitigating conflict within an organisation”. If you have read my “project fail…” and especially the “one best practice” series of posts, the “conflict resolution” aims of governance is definitely not served by a “governance document”. This is the world of what Jeff Conklin calls social complexity – or put perhaps in a simpler way: people, strategy and politics.

This is where I differ slightly from Robert Bogue. I attended his Feb 09 Best Practices Conference session where he spoke of SharePoint governance as a process. I personally believe that SharePoint governance is more in common with a methodology, and should be looked at through similar lens to other methodologies, like Agile software development, PMBOK, SEI CMMI and the like. Agile is not considered a ‘process’, although process is a significant part of it. I think the difference is that a methodology requires attitude to support the process. It is the latter area where the problems are. Without the commitment to back up the process, “governance” will be nothing more than just another document that few will ever read and even less will understand.

A document cannot alone drive the shared commitment required to make governance work.

When you look at SharePoint governance through the “methodology lens”, you will see that the reasons for governance failure are the same as why methodologies themselves have a hit and miss fate. Most methodologies require significant attitude to support the rigour to succeed.

Lessons from Agile

Not so long ago, I spoke to SharePoint’s own Agile/TDD guru Andrew Woodward about the topic of rigour and attitude to make Scrum projects a success. I had read this terrific real life story on the attitude factor required in Agile and was interested in Andrew’s experience with this, specifically in the SharePoint realm. Andrew confirmed that attitude and shared commitment among the team were particularly critical. Here is what he had to say.

When discussing agile teams and why they fail, Malcom Gladwells theory about Broken Windows is often quoted.   The premise is that if a broken window is left unrepaired, people will conclude that no one cares and will stop caring themselves. This is a very relevant to agile development teams where they rely on team ownership; where the team as a whole have to care about what they are developing and the way it is developed.

Agile processes quickly start to fail if some team members don’t care;  the broken window could be something as seemingly small as a failed unit test not being fixed or continually forgetting what they did yesterday at the scrum, eventually if this broken window is not fixed other team members will stop caring and the team will reach their tipping point.

The rigor needed by all team members is significantly greater than traditionally applied to development,  the myths around lack of control and process could not be further from the truth.  To be successful with agile processes you need every team member to care

I think you would agree, that Andrew could have been talking about being successful with SharePoint itself. 

Finally something practical

I thought that I would end this post by being practical as the post thus far has been a bit of a theory-fest. If you take some lessons from why methodologies such as Agile/Scrum fail, then it is pretty easy to list some practices that are likely to help you with your SharePoint governance effort.

One size definitely does not fit all

• Organisations vary in terms of size, industry and culture. A template cannot possible cover all scenarios.
• It is unwise to submit Joel’s sample plan without a real concerted effort to make that plan your own

Systems thinking and commitment

• We all rely on each other in complex and implicit interdependencies. Without a shared understanding among all participants, you will not have shared commitment among participants.
• Without shared commitment, a governance plan is just another document that will be out of date within months.

Governance affects different participants in different ways

• Culture is only changed if strong leadership makes it so, or participant accountabilities are crystal clear and completely unambiguous; therefore
• Split accountability into service ownership (“service”, being the SharePoint platform, is the domain of the IT department) and the Information Asset ownership (the applications and running on the service) are the domains of the business; and
• Identify owners versus custodians. Make sure that owners realise they are *always* accountable, even if they delegate day to day operational matters to custodians. If something goes wrong, the finger is pointed at *owners*. This has the benefit of making them suddenly much more interested in service and information assurance.
• It is more than the geeks. Geeks are custodians 99% of the time. In fact, SharePoint chaos comes more from Information Architecture and poor strategic planning as much as from a poor installation.
• Communicating the governance plan to more than the geeks is paramount. We should work to keep at least the high level material in planning as buzzword free as possible, my grandma should be able to read this stuff.
• Provide training for custodians and owners (if an owner refuses, then they may not appreciate their accountabilities as described in the second point).

Use common sense

• It doesn’t have to be bigger than Ben Hur. Doggedly following the written word to the last letter ignores the cultural commitment required by participants to make it work
• People only want to read what applies to their responsibilities. Make your documentation relevant to the key roles.
• One big document is just like meeting minutes – most will never read it. Split the document up if you have to.
• User evangelism is a good thing; be too controlling and you will lose it. Once lost it takes a long time to recover (look at Microsoft who have spent years trying to win back support from the days when they acted like bullies in the marketplace).
• Why put in SharePoint and then use a paper based change control or configuration management system? 

Put the supporting structures in place

• Targeted training. For key roles in the governance framework bring someone into your organisation. Targeted training for this group is better than some generic course.

In short, attitude and commitment is a problem of social complexity. The documented plan is great, but that is unfortunately the tame bit.

Thanks for reading

Paul Culmsee

www.sevensigma.com.au

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

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

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

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

Previously on CleverWorkarounds…

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

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

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

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

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

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

Next we have this anonymous response:

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

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

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

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

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

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

Next is David Mann

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

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

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

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

Chunk it up

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

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

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

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

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

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

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

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

Emergent Themes

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

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

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

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

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

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

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

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

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

Final Note – Tech geeks vs Developers

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

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

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

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

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

Thanks for reading

Paul Culmsee

www.sevensigma.com.au

Hi again and welcome to the fifth article on this series of posts on the topic of group sense-making and the pursuit of shared understanding among a group of participants trying to solve a problem. If you haven’t read the previous articles of this series, then I strongly recommend you go back and read the previous articles in order.

If you have read through the first 4 posts, you should have a pretty good appreciation now for the sort of “lens” that I view the world of problems and the projects undertaken to try and solve those problems. You should also have a pretty solid appreciation of the concept of wicked problems, their characteristics, and the ways and means that those characteristics can turn a happy project into a toxic wasteland, destroying all of the initial enthusiasm and commitment among the participants. Microsoft’s Jason Guthridge recently nailed SharePoint’s place in it all when he wrote the immutable law of SharePoint that “By itself, SharePoint can neither create nor destroy organizational chaos, but does an excellent job of reflecting the level of organizational chaos that existed at the time of deployment” – hehe love that!

I approach all my engagements these days from the point of view that project failure is not due to a lack of rigour or governance around any project management methodology. More often than not, the root cause is in “organisational chaos” and this is *not* a process problem. It all boils down to the fact that shared understanding among a diverse team is an illusive goal which is deceptively difficult to achieve and maintain. That is because SharePoint’s technical complexity gives rise to social complexity. At the end of the day, we all have vastly varying behavioural and learning styles, we all come from varying organisational cultures, have different skills in varying disciplines and have different value sets and life skills. A collaborative platform almost by definition forces us to confront and work through this social complexity and that is where chaos and wicked problem characteristics find a fertile breeding ground.

It is this same underlying social complexity that makes SharePoint governance so hard. That is because governance at its essence is about accountabilities and risk. In short, governance is an attitude and the fact that it is a shared responsibility among participants gives rise to those same “people issues”.

But of course, none of this is helped by the common misdiagnosis that project failure is a failure of process. Although I believe that process is part of the answer, when we look at project failure as a process issue only, we inevitably apply process oriented tools and methods to get things back on track. But if you agree with me that a lot of the time, the real issue is the lack of shared understanding among participants, then it is clear that we are missing a critical step before we dive into process oriented solutions. How do we know that we are all on the same page? Will a 40 page project charter and project management plan do the trick? History tells us fairly convincingly that the answer is no.

Thus, in my last post I described IBIS (Issue based Information System). IBIS is an issue based argumentation system developed in the 1970’s by Horst Rittel and further refined by Jeff Conklin. I described the craft of Dialogue Mapping – a *practical* method that leverages a simple grammar and a shared display, to help groups gain understanding of complex problems right at the very beginning of the journey. This prevents the usual problem of jumping past the sense-making phase too quickly by diving headlong into process and rigour. Even before a project charter is committed to paper, IBIS fills that sense-making void that most of the other methodologies presume exists, but is rarely there in sufficient detail.

For an interesting little experiment, if you have found this series to your liking, now go back and look at your last project management plan and specifically re-read the charter and problem statement. Is it more than two paragraphs? Would all stakeholders read it and then tell you the exact same understanding of the problem being solved?

More IBIS and Issue Mapping

Now if you recall part 4, I created an IBIS issue map to demonstrate the arguments made by Joel Oleson some time back, when he wrote an article that was originally entitled “Just say no to site definitions”. It caused some vigorous debate at the time, and I demonstrated how I was able to both simplify and objectify Joel’s post into a simple issue map that was very easy for any reader to understand. That map is below and this is our starting point for part 5. Have a good look and if you need a refresher on how it was created, refer to part 4.

Now it is time to map some of the counter arguments made by those who responded to Joel’s ideas. The first response was anonymous and made various counter points. Let’s take a look at the first half of the counter spray :-).

Are you serious? You prefer STP files over a custom site definition? Man, you obviously have never had to try to build a solution around STP files before.

• For one, you can’t feature staple to an STP file, so you are simply limited to the manual UI customizations. To run automation when a site is created, you need to use a site definition with a provision handler or feature stapling.
• STP files are buggy, and sometimes you will randomly get errors like this one in your navigation bars: http://www.sharepoint-tips.com/2007/09/wrokaround-error-in-navigation-when.html
• STP Files do not support sites with the publishing feature activated.
• STP files do not package all your settings, especially content type visibility and column visibility on lists and
  libraries: http://www.sharepointblogs.com/toth/archive/2008/08/08/the-problem-with-content-types-and-columns-part-2.aspx
• If an STP relies on elements from other higher-level sites or lower-level subsites, good luck.

The first line of the response is actually very interesting from an IBIS nerd viewpoint because and it a perfect example of social complexity playing out and it made decide to change major aspects of the map. The above respondent immediately honed in on something that wasn’t actually all that clear to me to begin with. When I first mapped Joel’s statement in part 4, I never actually put the idea of using site templates into the issue map. Why? because Joel never actually suggested it! The closest he came was the statement “Site Templates as tough to work with as they are, are better than custom site definitions”. But I interpreted this as using the example of site templates to highlight the complexity shortcomings of site definitions. I simply captured the argument of “complexity”, supporting the idea “Do not use site definitions”.

But look here! Our first respondent interpreted it completely differently to me. They inferred (likely correctly) that Joel prefers site templates over site definitions. But the response then takes a shot at Joel’s credibility.

Are you serious? You prefer STP files over a custom site definition? Man, you obviously have never had to try to build a solution around STP files before

If that exchange happened in a meeting, you may as well call it quits, because it would be very likely that very little valuable dialogue would be obtained after such an exchange. Participants are on the defensive and the meeting will likely get derailed on this tangent. But this is a terrific example of how using IBIS grammar is extremely effective at teasing out ambiguous or poorly formed argumentation, thereby removing the “sting” out of these sorts of debates.

So what should this map look like then? Below is a new version with a few key adjustments.

The most obvious change that I have made to the argumentation presented above is Joel’s original idea. I have removed the negative connotation of “Do not use site definitions” to “Use site definitions”. As a result, the previous pros now become cons, because they are no longer supporting the idea. I did this because I have also added the idea “Use Site Templates”, so now we have presented the two ideas without any inferred bias and can simply examine the characteristics, pros and cons of each idea.

For what it’s worth, engineers sometimes unconsciously word questions in a manner that non engineers find biased because of the implied connotation. You can read more about this in my “it’s all how you ask the question” post.

Finally, I also removed the “there are easier alternatives” pro from the map altogether. I did this because this argument has became somewhat redundant. Note how we are now exploring all of the alternatives as separate ideas in the map anyway. More importantly, what does “easier” mean anyway? What is “easier” for an IT pro type person like Joel may be very different to what is “easier” for a SharePoint developer”.

Stepping back

The ability to restructure a map on the fly is one of the key benefits of IBIS. A skilled IBIS practitioner is able to quickly restructure the map as the conversation moves around the various topics, all the time leveraging collective intelligence of the group as they dissect the problem together.

Another key improvement from the previous map is that we have further objectified things. Our first respondent also supplied some great factual counter arguments to Joel, but hid it behind an initial barb that could easily be inferred as a cheap shot.

Nevertheless, here is the portion of the map with showing the additional argumentation from the respondent about using site templates. Now we are getting somewhere!

Let’s examine each of the statements of the respondent. All of the arguments made were dumping on site templates in some way, so we capture them as cons to the “Use site templates” idea. The respondent actually did a very good job with his arguments and they were very easy to add to the map.

• The statement “For one, you can’t feature staple to an STP file, so you are simply limited to the manual UI customizations. To run automation when a site is created, you need to use a site definition with a provision handler or feature stapling”, is a bundled up statement. There is the con argument “feature stapling cannot be used”, with an implication of that argument being “Can only customise manually”. I broke that out into three IBIS elements
• “STP files are buggy, and sometimes you will randomly get errors like this one in your navigation bars” is stating that there are bugs, and supports that argument by stating a specific example of one. I split this out into separate IBIS elements and additionally linked to the specific example.
• “STP Files do not support sites with the publishing feature activated” is a nice, simple argument that I captured as “Not supported with the publishing feature”.
• “STP files do not package all your settings, especially content type visibility and column visibility on lists and libraries” is again a nice counter argument backed up with examples.
• Finally, the comment “If an STP relies on elements from other higher-level sites or lower-level subsites, good luck”, is in effect stating a counter argument that site template files to not handle dependencies. In case this paraphrased statement is ambiguous, I added additional detail to this node with the original argument as shown below.

More arguments against?

Below is the rest of the response that is nowhere near as clear as the first half. Let’s drill down…

I disagree, I think it is lazy devs that want to use an STP file, instead of creating a custom site definition, just like it’s laziness to create a content type through the UI for a custom solution instead of in XML with a feature (which can then easily be moved from environment to environment).
And honestly, is it really easier to go through the machinations to customize the MySite template as recommended here (http://blogs.msdn.com/sharepoint/archive/2007/03/22/customizing-moss-2007-my-sites-within-theenterprise.aspx) to simply move a few web parts around, rather than just make a tweak to the original site definition? Honestly which is less maintenance for a customer, a quick documented change to an XML file in a folder, or a Feature+WebControl+Custom master page+stsadm commands to activate etc.?

I think you are way off base here, and painting with broad brushes.
(I do agree with zero footprint efforts, and only editing built-in site definitions for tiny tweaks).

The first argument is actually now a moot point. Joel did indulge in a bit of developer bashing in his post (and who doesn’t enjoy a bit of that from time to time) and this respondent is simply reacting to that. But since I have already objectified Joel’s original point then arguments about “lazy developers” is actually answering a different question altogether and does not belong here.

I previously removed Joel’s “it is easier” argument and what do we see here? We see the respondent questioning what is “easier”! This respondent argues that a documented tweak is “easier” than applying manual changes. Once again in a real meeting I can see where this would go. One party would probably then say “yeah but you lazy devs never document it” and we are off into a conversational tangent that will not achieve much. So like Joel’s arguments earlier, I am removing the “my easier is better then your easier” arguments.

What’s left? Well, pretty much this entire bit of the conversation is talking about how much manual work is involved to manage changes when not utilising site definitions. So we can summarise this counter argument as “more manual customisation needed”. When I look at the map, I see that our existing argument “feature stapling cannot be used” is actually an example of this. So the adjusted arguments against site definitions now look like the map below. Note how I have removed the con of “Feature stapling cannot be used” and reworked it as an example of a new con, called “More manual customisations needed”. This now looks better.

And finally for now, I have this consolidated map to represent our current understanding of the question “What should the best practice be around SharePoint customisation”. There are still other counterpoints, and we still have to add the pro argument into the map too. But by now, you should be getting the idea. Imagine yourself having this discussion in a meeting. Would this map, displayed on a projector have helped keep the meeting on track?

Thanks for reading

Paul Culmsee

www.sevensigma.com.au