Paul Culmsee in Dublin: Intellectual Capital is the key

Last week, I had the opportunity to attend Paul Culmsee's seminar called "Re-writing the rule book for managing knowledge", held at the Microsoft offices in Dublin.

I have been following Paul's blog for a couple of years now, Clever Workarounds, so I was looking forward to meet him in person and also talk a bit more about Dialogue Mapping...

I'm glad to say he fully delivered on the expectations!

You probably have heard about Paul Culmsee, if you haven't, you should go and visit his www.cleverworkarounds.com blog right now! He has written a lot of interesting post series over the last few years. Some of them, I must admit, probably shaped the way I approach problems and have certainly influenced my professional career. He's got lots of great content, if you want my advice where to start:

• Confessions of a (post) SharePoint Architect (2012)
• Demystifying SharePoint Performance Management (2012) 
• The Practice of Dialogue Mapping (2009)
• The one best practice to rule them all (2009)
• Why Do SharePoint Projects Fail? (2008)

You might want to run them chronologically. Some of it might not even be relevant for you, specially if you're not into SharePoint. But any posts about "wicked problems" and "dialogue mapping", doesn't really matter what you do in life, I'd jump right in!

This seminar was part of a bigger engagement Paul was doing early this month in Ireland and UK, as he was running 2 day Dialogue Mapping introductory classes (one of them in Storm). He has written about it here, if you want more details.

Now, back to the seminar. This was what the room looked like before we began, with a nice little pretty Storm Technology (n.b. the company I work for) banner on the left corner. You may also notice, that the seminar's title was cleverly changed to "New Innovations in Leveraging Intellectual Capital using SharePoint". More on that in a minute.

The seminar started with Eoghan Young, from Storm, introducing Paul. This wasn't the first time he came to Ireland in a collaboration with Storm, as in 2010, almost 4 years ago now, he was also here. At the time, it was an invite-only event mostly focused on Governance, but already introducing the topics of wicked problems and dialogue mapping.

Unfortunately, I wasn't working in Ireland yet, but if you're curious, check the post he did back then. One thing one can never accuse Paul of, is not being able to tell a good story!

The first contact with Dialogue Mapping was right at the beginning of the seminar, just following the introductions...nice way to start! Topic: "What is the hardest thing about SharePoint delivery?"

It is a topic that, without a doubt, will get most people eager to talk. He did the live mapping of the comments and conversations as they were happening, acting just as the facilitator. It allowed everyone to get a bit more comfortable and lose the natural initial shyness. I thought it was quite interesting how Paul kept the SharePoint topic on the "agenda" throughout the seminar, using it to map theoretical concepts to real life examples, while it was quite clear to everyone that the conversations we were having were really technology agnostic. SharePoint just happened to be the link that got this group of people together, and no more than that. I liked that approach.

As answers started flying in, everyone seemed to be pretty much focused on business-related problems: user buy-in and adoption, governance, correct understanding of the business requirements, managing the structure of the sites and permissions, alignment of the technical solutions with the business goals and so forth. Being on the side of the event promoters, I managed to keep my mouth shut. Rather unsurprisingly, my contribution would have been something along the lines of "Managing the lifecycle of solutions".

I'm happy I didn't say it, as Paul followed up the discussion by making the point on how no one raised any technical matters or issues they had faced in SharePoint. He's done this exercise around the world and he said the same phenomenon happens everywhere. We were allowed to choose one of the previous places he had done the seminar at and looked at their own Dialogue Mapping when having the same discussion. The results were very similar.

Although these results are interesting and effectively make a good argument for the need to increase the focus on the requirements gathering process, the business side of solutions and how it aligns to the technical side, it is also an argument that is guilty of selection bias (or sampling bias, if you prefer to be more specific). After all, who do you think attends a seminar titled "Knowledge Management - Re-writing the Rule Book"? You are right, business people with limited to no technical exposure to the pains of SharePoint! :)

But I guess one of the bottom lines here was the need to improve how we transform business needs and strategic goals into technical solutions. We've all heard one too many times how a solution was scraped because it was causing more harm than good, how it was not giving the business users what they needed and were looking for. So I'm all in for that!

This leads us to the Intellectual Capital discussion. Why should we stop using the term "Knowledge Management" and just use "Intellectual Capital"? Well, it seems "Knowledge Management" has somehow built a bad reputation. Gives people bad feelings. I'd actually agree to that: when confronted with those words, a lot of people will indeed think of all the rules and regulations they were obliged to follow or all those boring tasks they were given when switching project. The truth is people are much more keen to talk to you about a topic, discuss it and give you tips, than to write a Wiki article. Everyone I know hates documentation (yes, I know a lot of Developers!). Everyone's favourite hobby is pushing documentation so much further down the line that when they actually have to do it, it barely ever makes sense to make that investment. And then, there's the problem..."What happens if Jeff leaves?" We're screwed.

Intellectual Capital also makes the discussion broader. We're not just talking about writing down some stuff on the company's Knowledge Base to make the boss happy, having some knowledge transfer meetings or doing some videos. What we're really starting to think about is what makes your organization valuable. Think about consulting agencies: what assets do they have? Is what makes them valuable in any way a tangible asset? No! It's their knowledge, their reputation and how they're perceived by their potential clients. Paul showed a very interesting statistic about the evolution of tangible vs intangible assets in companies, over the last decades (a similar graphic is shown below).

Makes you wonder about how much is your company investing in their own intellectual capital vs how much they should be. It is a compelling argument, and I guess it is widely accepted, but we all know how easy it is for "business as usual" to trump up any good  intentions. In a way, we must also take into consideration that it might not feel it is in the best interest of an individual to open itself fully to the company. I've met a lot of people that feel like the more knowledge they share with others, the less valuable they really are and the easier it is to replace them. So, in a way, I'd say it must be the company (and upper management) pushing these initiatives.

There were a number of interesting discussions, examples and demos during the seminar. One that I would highlight was the Team Nonaka vs Team Polyani. Once we started talking about Intellectual Capital, we quickly focused on what is tacit knowledge and the possibilities of making it explicit knowledge. And in that field of research, there's 2 sides. Onde side (Team Polyani) defends that tacit knowledge is just not transferable, while the other (Team Nonaka) says it is just unarticulated knowledge awaiting transfer. Paul seemed to be somehow in the middle, with an opinion that any situation where there's a very clear path of cause and effect, the knowledge should be written down, while when there isn't, it's not worth the trouble.

This discussion brought up some other interesting points, like the whole Content over Context problem, where people just start following procedures regardless of the particularities of each scenario, because "that's just how we do things over here". Or the idea of including, in the pre and post mortems on projects, a discussion on what we think can go wrong vs what actually went wrong. And I quite liked the spider senses definition we were presented with, when we were talking about tacit knowledge: "It's the ability when things are not working to know where to look first". Spot on.

As we discussed Dialogue Mapping in more detail, we also looked at some tools. Compendium is an open source client tool that seems to be the industry standard at the moment. It's a simple tool, focused on creating a Dialogue Mapping diagram. For an individual, that's more than enough. But when we start talking about Dialogue Mapping as an enterprise wide approach, we have to start thinking about collaboration and integration. And that's where Paul's new platform/tool comes in.

It's called Glyma (read: glimmer) and it's built on top of SharePoint. It basically allows you to create your maps online and attach content to each of the nodes. Anything that can be embed on an iframe is suitable, so think PDF's, Office online documents, maps and especially video, since they allow you to not only include the video but also set the start and end time. That opens a massive opportunity in terms of knowledge management, where you record a meeting / conversation / seminar / interview and then create a dialogue map of it and link each of the nodes to parts of the conversations. I thought it's quite an amazing idea. It also allows you to link other metadata to the nodes and, of course, it's all searchable. Go to glyma.co if you want to know more.

In the end, it was great attending this seminar, very insightful and another great initiative from Storm, well done!