Victor Sluiter - Adventures in setting up a knowledge system for a research group

This is a summary of a talk given at Write the Docs Prague 2021.

Victor is an electrical engineer who has worked on e-bikes and exoskeletons for paraplegic people. He’s not a technical writer but he doesn’t resent documentation, contrary to the stereotype about engineers. 

During the last year and half, Victor’s team set up a knowledge system for their research group. He calls it an adventure and is going to share their experiences. 

The group he’s working for is called Saxion which is a university of applied sciences. There’s a wide range of educational teams, ranging from management, technical education, to health and wellbeing programs. The research groups work on applied research, and Victor is a research engineer in one of those groups. The mechatronics research group contains a professor, support staff, and researchers. 

The group is working on more than 20 projects running at the same time, including drone applications. 

Knowledge & Information

He was asked to set up the Knowledge Management group. Knowledge is what lives in your head and leaves the building at 5pm, and information is the stuff that stays behind when you leave. Some companies do not want to exchange information so they have to be careful with how they approach the situation.  

They had a lot of storage solutions, including GitHub, Confluence and Slack. Some people kept their information on their own drives. They’re always questioning where they should store documentation, and wondering if it is important enough to share. 

Finding a new way

As good engineers they started off with their requirements. They wanted good rights management, concurrent editing on documents, clear workflows, clear costs, and versioning. 

They considered Sharepoint but security concerns meant Sharepoint wasn’t open to external partners, so they couldn’t use it. They already used Confluence which was a very good solution with easy onboarding and a WYSIWYG editor. 

In the end, they chose Confluence as their Knowledge Management solution. 

Why don’t we use a standard workflow?

They had a standard workflow but nobody was using it. The standard model did not really fit the project dynamics and nobody was rewarding you if you did use the standard workflow. 

According to management, documents they made did not contribute to knowledge transfer. That raised the question, what knowledge products did they want to share? 

Knowledge products

They asked the group what knowledge products are important for internal and external knowledge sharing? Everyone presented their ideas and they put the ideas on post-its on a whiteboard. They made their goals SMART. 

Products that they thought were really important were a whitepaper on technologies, code repositories, live demos, scientific contributions and reports of professional conferences. 

For every knowledge product, they decided where to store it. 

Knowledge sharing also happens when you let someone outside your project review it. Roughly 300 man hours in a project would develop one knowledge product. 

They had to decide who was responsible for reviewing the knowledge products. They were mentioned in every group meeting and so everyone could find out what knowledge was available. 

They looked at the concept of rights over the knowledge products, and gave students, graduate students, external companies and research group members different rights to access the knowledge. 

The exchange between knowledge and information was much much clearer. 

When KPIs were needed for the organizational reports, there was renewed interest in the knowledge products. When a few people left, they left behind their knowledge products in the organization. 

Now, they also see what they have missed. Where do they store knowledge that spans multiple projects? It’s still something they have to deal with. 

Final remarks

Although the knowledge project didn’t work out as intended, they have a great set of knowledge in Confluence. They can more easily retrieve information on their own projects and have a sensible structure which helps. 

Always keep the “why” at the back of your head, considering why you’re doing it and why it’s important. 

Listen to the full talk here.