Over the years I have felt extremely frustrated with the so-called knowledge repositories, such as SharePoint, and the many other solutions for collaboration that exist around an intranet. Many years ago I joined an engineering consultancy firm in London called Fulcrum (which a few years later merged into Mott MacDonald). That was back in 2008 and we were around 150 employees, with small offices in Edinburgh, Madrid and Hong Kong. Those were the days were sustainable building design was going strong. The six directors were (and are) an extremely cool and forward-thinking lot and they put together a great team of sustainability consultants and building engineers. I was one of sustainability guys.

As you can imagine, sustainable building design touches on many aspects of the building; insulation, air-tightness, energy efficiency, daylight, building controls or thermal comfort, to name a few. Knowledge was very important and we had a Knowledge Base (SharePoint). As we were constantly researching new technologies and design principles, we were continuously coming across very interesting documents and articles. We were devouring them and uploading them on the Knowledge Base. We had categories and tags and all the rest, and we were not too bad at applying metadata to the files. But nonetheless, it was a phenomenal mess.

Soon it was obvious that we were uploading stuff much more frequently than downloading files. The main reason for this was that any ‘search’ would yield a large number of results and there was no way we could obtain anything which actually matched what we needed in the moment without opening and reading a lot of documents. Now, many years later, I have a better understanding of the problems we were suffering then, but the truth of the matter was that we all had our own repositories of knowledge on our computers, and any time we had a need or an itch, we would turn to our reliable contacts (for instance, Tom, just across from my desk) who would send us an email with the document in an attachment.

We had built a platform which was to be a knowledge sharing platform, but we did not know the difference between a library and a collaboration environment. As a result, we ended up doing none, because we could not tell information from knowledge. To illustrate this, I will reproduce here the definition of Knowledge Management by Kimiz Dalkir and Jay Liebowitz: ‘Knowledge management develops systems and processes to acquire and share intellectual assets. It increases the generation of useful, actionable, and meaningful information, and seeks to increase both individual and team learning. In addition, it can maximise the value of an organisation’s intellectual base across diverse functions and disparate locations.’ Our knowledge base had tons of information with little use, relatively low meaning, and it was certainly not actionable.

KM is the Supermarket and your Project is the Kitchen

I often use this analogy. A knowledge-sharing platform is the supermarket you go to find the ingredients to take home to your kitchen. Once there, you can mess around with the alchemy of your project. I still work in the construction industry, sadly not anymore at Fulcrum, but at Werner Sobek, which is another very good firm. We are building engineers and designers doing pretty much all the things that architects do not do: structural engineering, façade engineering, heating and cooling, etc. As you can imagine, our kitchen can get pretty messy and we have all sorts of things going on at once.

I’ll give you a small example. We were recently approached by an architectural firm in Philadelphia to support them in a cool and confidential competition in Hamburg. It’s something like a museum and it will be small-ish, 2,500 m2 of net floor area. We have three weeks to cook up our magic and there are no fees involved, so we don’t want to spend too many hours cooking.

After a few days we received the architectural drawings, showing the exhibition areas, back of house offices, circulation, toilets, and so on, but there isn’t a single technical room for us to put our equipment in. This is quite common, by the way. One of the dishes on our menu takes priority and has to come out of the kitchen really fast, as all starters should. -This is: To Tell The Architects How Many and How Big Our Technical Areas Should Be-. Speed is key, because everybody is working away and the sooner we get our foot in the door, the easier our life will be for the next two years.

Now that you know the context, let’s go back to Knowledge Management.

So now that we know the breakdown of areas in the building, we rush to the supermarket and check out the different aisles and shelves. Navigating the supermarket is very easy and we quickly find an aisle call ‘Spatial Allowances’ (that’s the lingo). We walk along the aisle taking a look at the different products on display. It is very clear in our minds what the final dish shall be, so we easily identify the ingredients we can use:

• Template booklet for spatial allowances
• An excel spreadsheet with benchmarks for other museums
• A tool to estimate the loads (power demand, heating, ventilation, water, etc)

Furthermore, while looking around, we find other related ingredients that we did not know existed and which will give our dish extra flavour such as case studies of technical areas in museums we did in the past and a couple of diagrams we can adapt to fit our project. In fact, the architects won’t notice this, but we also took a couple of ready-made meals from the freezer, but hey, economies of scale, right?

Three Principles of Good Practice

In order to provide such an experience (navigating the supermarket), we had to establish a few requirements. Or rather, define a brief which is not too abstract nor too narrow; as Tim Brown puts it in his book ‘Change by Design’. The way I see it, the knowledge-sharing platform should conform to the following three principles.

• Knowledge should be very easy to create, share and rearrange 

The members of the organisation should be able to share their explicit knowledge in the easiest way possible, as any burden to the process of creating and sharing knowledge will dramatically reduce the level of engagement and the amount of contribution. Similarly, any knowledge domain is organic and will evolve with time, so the different domains and the different knowledge assets will need to be re-arranged (forgotten even). This process should also be extremely easy. In my experience, SharePoint and Wikis don’t fulfil this principle, especially when it comes to re-arranging.

• Knowledge should be organized as an ontology, not as a taxonomy

In case I am not using these big terms in the proper way; by taxonomy I mean a tree diagram, and by ontology I mean something like a network. A well-known taxonomy is the animal kingdom (or parts of it, rather). Under such organisation, any given species will only be in one place, and there is only one path leading to that species. So next time someone in your organisation needs to do some work about rabbits, he or she will have to access the folder of chordata (I just learned this word), then the folder of vertebrates, and so on until reaching the rabbit and accessing the knowledge your organisation holds on rabbits. But in reality, the way our brains reach different domains of knowledge is by navigating a network of domains, so different people will access their domain ‘rabbits’ by a myriad of different paths. Notably: carrots.

• Whatever the KM method, it should be built from the ground up 

Another barrier to a successful KM system is when the system comes from above. This now seems obvious to me, but not when we started implementing the KM platform back in the day. Back then we had a series of workshops between a bunch of senior guys where we devised the KM system including the major domains all on our own. We then passed it on to the wider company expecting them to start  populating and using it. It was not well received and it obviously failed.

This third principle is quite straight forward: whatever the KM system, it should be built from the ground up. Furthermore, I recommend building it around communities of practice and start small. The way I do it is as follows: first choose a specific company objective that is closely connected to knowledge (low hanging fruit), second define a small community of practice around it and give them a clear goal, and then start working on that specific domain for that specific target. By so doing, you will create a small but functional KM environment, which is useful for everybody from day one. People within this community will feel ownership, will look after their domains and will feel comfortable using the platform.

Knowledge Mapping on a Mind Mapping Platform  

Now, discussion on technology is unavoidable and so far I have only found a way to do this: communities of practice and collaborative knowledge mapping. In particular, we use mind mapping software. I don’t think there is much point in mentioning the particular software we use, since many commercial products out there provide the necessary functionality.

Mind mapping is a very simple and very powerful technique to organise your thoughts (and in our case, our collective thoughts). This is the Wikipedia description: “A mind map is a diagram used to visually organise information. A mind map is often created around a single concept, drawn as an image in the centre of a blank page, to which associated representations of ideas such as images, words and parts of words are added. Major ideas are connected directly to the central concept, and other ideas branch out from those.”

For the last six years we have been using collaborative mind mapping to manage our knowledge. It’s been the most successful platform I have ever used. It is simple, intuitive, easy to use and fully complies with the three principles of good practice. It provides an ontological navigation experience, so that different people reach the same domains following different paths. I can’t stress enough how important this is. Every now and then, when I have shared a new knowledge asset, I go for a walk and ask some random colleagues if it would be ok to carry out a test for me. I ask them to go to the knowledge map and see if they can find (or rather, access) something in particular. Invariably, they all find it in a matter of seconds. I observe the paths they follow and it is very interesting to see how different they can be.

The aim of this article is just to provide an insight into what I believe to be an effective knowledge sharing and collaboration platform, and what the principles should be to govern such an initiative. It all comes down to people and to influencing the organisation’s culture. I believe it should be down to the users to curate the experience of navigating the company’s knowledge. I do not want to overextend and lose your interest, and I hope you have found this story useful so far. I would be delighted to hear from you:

• What do you think?
• What is it like in your industry? What do you use?
• Is knowledge mapping a sensible solution only for engineering disciplines?

​Manel Heredero is the managing director of Werner Sobek London, an engineering design and consultancy firm in the construction industry. Manel has 10+ years experience in implementing and developing knowledge management initiatives.

He may be reached at:  manel.heredero@wernersobek.com

Website:  evocaproject.com