This is a guest post by Menno Gazendam.
Internal knowledge is crucial to all engineering companies.
Our staff’s functional competence and education are obviously necessary, but internal knowledge gives us the edge over competitors. It helps us continuously improve and avoid repeating mistakes.
Internal knowledge is solutions, methods, procedures, designs, and so on that have been developed and refined within the company—past projects and experiences which act as inspiration (and sometimes straight-up solutions) on how to tackle the new tasks facing us.
The richness of this internal knowledge is an indicator of how we are developing our knowledge base as a company.
This allows us to draw from the wealth of experience we have obtained from past successes and failures and gives us a differentiating factor during tendering and execution.
This internal knowledge and its successful use and application sit in the heads of the staff that have been involved in past projects within a company. It is the collective and accumulated body of know-how, tacit knowledge, and expertise, sometimes defined as “experience.”
But, staff leave
And they are leaving after increasingly short stays. Young people will now hold many jobs at multiple engineering companies before they even reach 30.
Blame it on whatever you want: a world economy that was shot to pieces recently, a growing trend toward a freelancer economy (to mitigate risk), and younger generation Y staff who attach more value to meaningful work than to undying loyalty towards a single company.
The fact is, people are jumping around more than ever. This is not a bad thing at all—but that’s an article for another day.
What it does mean, though, is that internal knowledge is both getting lost more quickly than it used to and not receiving enough time to accumulate and be transferred gainfully to others.
New recruits do not bring internal knowledge
The new recruits we take on bring no internal knowledge with them, no matter how good and experienced they are.
Hopefully they do bring foreign knowledge with them—a gain to you and a loss to the company they left.
But without other engineers to tap into for local knowledge, the new recruits have to build it up from scratch.
This highlights the need to effectively preserve, share, and transfer knowledge. Not that knowledge transfer in itself is a new idea. It’s just becoming more important than before.
Most, if not all, companies with proper internal management systems will record project knowledge for sharing through documents such as field, close-out, or lessons-learned reports.
The expectation and assumption is that this knowledge can be pulled from the archive whenever it’s needed to tap into the wisdom recorded therein.
It rarely works that smoothly in practice.
The problems with close-out reports, etc.
These reports are mostly done for clients as part of pre-agreed contractual obligations, if they are done at all. In my experience, very little attention is paid to them ever again. They’re seen as an administrative burden and anticlimax after the celebration of finishing a project and are generally rushed and the poorest written of all types of reports.
But the real problem with these reports is rooted in their utility. They are simply not as useful as we think, because of the way they are constructed.
There are three main problems:
- Not searchable – you cannot do a keyword search across your whole archive. Yes you can now search within some PDFs and/or load them with keywords. However, this is a poor man’s solution to a problem that requires more complexity.
- Not interlinked – you cannot stumble across helpful information by following links, the way you find great websites that you did not even know existed by following links from your starting point.
- Grouped by projects – how can you search for topics when all the info is grouped by project? You almost never look for a particular project (that you might not even know about); rather, you look for a certain topic, such as a “how to design x” or “material spec-y.” Invariably and frustratingly, your chances of finding what you are looking for are dependent on whether you know which project you are searching for. Now, how would you know which project this would be if you are new and have no recollection of past projects (and the people who could tell you either have left or are not available)? You do not know, and so if you have no luck in finding the correct information, you start from scratch.
This frustrating situation can be avoided, fortunately—we now have the tools to handle it. From enterprise content management tools (if you really want to be sophisticated) to web tools (if a distributed solution that is quick to implement is what you want), they will allow the clever capturing, storing, archiving, sharing, retrieving, and discovering of relevant information, in real time, across geographical locations and between multiple tech platforms. In a corporate setting that needs lots of automation and control, they are even capable of managing the workflow needed for the seamless movement and availability of information.
The web brought us the ability to use web applications to collaborate and share information securely in the cloud.
The number of tools available to support team cooperation and information sharing over the web is too numerous to mention here. This is also not a product review article. They all have their advantages and disadvantages.
Mediawiki is freeware (as in it will cost you nothing), and you set it up yourself on your intranet. The best known one is, of course, Wikipedia.org.
A side note: If your company runs SharePoint, you can also set up wikis to run on this platform (although I find the usability of SharePoint + wikis not very effective or friendly).
I’m sure Evernote needs no introduction, but for those of you who are not sure what it is, it’s a note-keeping app on steroids. Check out their website for a full explanation of what they do and how they do it.
They recently expanded with a business package where teams can collaborate on notebooks. At that cost it’s a steal, and because it’s Software as a Service (SaaS), you have no IT to worry about. And it syncs, so the changes you make on your desktop in New York are immediately reflected on your colleague’s mobile browser in Moscow.
Mediawiki can do this, but you need significant IT support to make it run smoothly and securely.
Create an internal knowledge center
The purpose of these tools is to create a knowledge resource that is a network of links and pages which can be searched and freely edited, rather than reports stored in a hierarchy of folders.
The knowledge resource you want can range from a simple compendium of how-to design codes or best practice guides to a full-blown information management system. I rather like the idea of engineering companies using this as a tool that allows an engineer to dip in when he has a question like “What is the best way to do this? Maybe someone else has dealt with this in the past; let me check.”
But whatever tool you do choose, it should allow you to add, modify, or delete content freely in collaboration with others. While it is a type of content management system, it will be without any defined owner or leader, with little implicit structure, allowing structure to emerge according to the needs of the users.
In other words, as long as it is used, it will grow and shrink and sway organically to the needs of the users. It will become useful.
Let me show you what I mean through a short example.
You are new(ish) to a company and you must design x. Your experience and the scope compels you to look into whether x has been done on past projects.
No one can recall anything, and those who might know either have left or are not available.
You then log into the internal knowledge system and search x. The search reveals many hits on pages that were created in the past discussing the topic of x, some applicable and others not so much.
You read that there were some major issues with x on a project a few years back. The page includes annotated photos as well as two videos. It also includes a link to page y, which you never thought about but is clearly a crucial lesson to know, now that you have seen it.
Within minutes you tap into the internal knowledge of engineers you have never met, even from foreign offices that left the company a few years ago. The knowledge is still there and easily searchable.
After you use the info you sought, execute the design, and learn your own lessons, you return to add information to the pages you found helpful, building and enriching the info already there, inserting links to other pages you noticed that are also applicable, and starting a few new pages. You are making sure that someone else, maybe even years down the line, benefits from your experience.
It does not matter how small this contribution is. A paragraph here, a sentence there, or an image added. Collectively, over time, it will grow though contributions from multiple users.
Yes—but who controls this?
No one. It’s owned by the mob and based on collaboration and crowdsourcing principles.
Look, it’s not meant to be rigid and replace codes or design textbooks. It’s meant as a departure point to tap into the collective internal knowledge acquired by your staff over past projects.
It does not need to be approved or verified. That will miss the point of crowdsourcing the info. A design remains the responsibility of an engineer regardless of where information was sourced—from a colleague, an old design or report, official code, a handbook, or an internal knowledge system.
It is not meant to replace your quality assurance systems. It’s also not meant as a replacement for your contractually agreed reporting deliverables. What it is meant to do is save you time, help you avoid repeating mistakes (and costs), and create a way of capturing and sharing knowledge.
Four things to make this succeed:
I have seen this implemented successfully and unsuccessfully. And success seems to be linked to four attributes.
- To have a champion—someone high enough in the organization to fight for its implementation and use;
- Buy-in from the CEO—without this person accepting and understanding the benefit, do not even try to launch. It will fail;
- To eventually replace some existing workload (close-out reports, creation of internal design guides, etc.), and not form an additional workload;
- To reach critical mass, or a tipping point—it needs to accumulate enough content that people start using it for reference, rather than just spending time creating content. Until then, it needs to be driven by points 1 and 2.
This can hardly be described as a cutting-edge idea. But it works. It’s simple, cheap, and available on the Internet near you. Go preserve and share your knowledge more effectively.