capturing knowledge

[nigel99 620]

Has anyone come across a good method of capturing knowledge in a business envirnment? Specifically in engineering but I am sure other professions have the same problem. I've had clients beg me to document "everything" I know which is stupid because I have close to 20 years experience.

To be honest the whole logbook aproach is a waste of time, because no one can find the key detail when needed. I have written detailed documents for clients in the past. The more detailed it is the more likely they are to not find what they are looking for (past experience proves this).

The company I am working for has developed an "expert system" in house to try and capture knowledge, after past bad experiences. While it is cumbersome and tends to get in the way, it is the best appoach I have come across. It is sort of a wiki and database all rolled into one.

I am really interested to know what has worked for people or ideas that might.

Experienced jumper - someone who has made mistakes more often than I have and lived.

[jonstark 8]

I was in the biz-jet biz for my entire career. The company tasked us field reps to submit "field service reports" or FSRs. They compiled a database of these for each model of a/c using the standard aviation indices or ATA chapters. There is a huge amount of experience in those reports. Just don't ask me how to get at it! As far as I was concerned it was a perishable media good in case the reader could recall the event later.

We also came up with a "smart book". This too was an accumulation of tidbits of information and data. The stuff we called home to the factory for on a regular basis. Things like rigging and troubleshooting tips. Disorganized but handy if you happened to remember that the info you were looking for was there and where.

jon

[wmw999 2,589]

We tried really hard where I was -- a longtime software development and maintenance contract, where institutional knowledge was very highly valued.

One way was to simply keep the same people around
The biggest problem was finding a suitable index, one that was accessible to and understood by most people. That's a toughie, since the knowledge really exists across a number of dimensions.

Since it was software for us, one of our best knowledge repositories was our detailed problem reports; nearly all real problems ended up as one of:

code fixes (numbers documented in the code)

known workarounds (numbers listed in workarounds list based on software functional area)

process changes, including inspection checklists (numbers documented in process change tracking).

By no means perfect; we had other stuff too. The biggest escape from this was design decisions -- why did X programmer make Y design decision, and not a different one? There were other documents that could track that, but most programmers didn't choose to fill those out (They were optional).

This requires an environment where a very high value is placed on documentation, because the documentation is key. Even a wiki-type of approach requires an environment where something other than altruism drives people to populate the wiki. The company has to make it clear that they value this aspect of their business enough to pay people to do it (i.e. it should be part of someone's job description). Make sure the wiki is organized according to how people actually work (talk to a lot of people using a structured approach), and not just a single person who comes up with their individual viewpoint.

Wendy P.

There is nothing more dangerous than breaking a basic safety rule and getting away with it. It removes fear of the consequences and builds false confidence. (tbrown)

[nigel99 620]

Thanks Wendy. Both your and Jons answers capture a huge part of the problem - finding it when you need it.

I tend to work in smaller companies and as a consultant. I'm even finding as I get older that I have forgotten some of my own lessons :(

It seems that tacit knowledge is best captured by giving people time to simply share their experiences.(I've been reading up) so perhaps it is simply down to encouraging a "social" culture of the right type. Maybe its better to invest in good coffee and comfy chairs rather than fancy software?

Experienced jumper - someone who has made mistakes more often than I have and lived.

[Nataly 38]

As an ex-mechanical engineer and current efficiency consultant, this is an interesting topic for me... I've worked on "process-mapping" projects with varying degrees of success... The biggest difficulty I come across is that a lot of knowledge is just plain undocumented - people learned it by word-of-mouth or by trial-and-error or even by accident.

Worse still, many people (including people who are excellent at their job) do things without necessarily thinking them through. When asked, they often don't know *why* they do things a certain way, just that it works and/or it's what they were taught to do. The reasonning often becomes clear only when you try a different approach that fails.

Unfortunately, trial-and-error seems to be how many solutions are discovered... I say this is unfortunate because this method does not necessarily require a lot of organised/systematic/logical thinking. You can quite randomly find a solution on the first try and have NO IDEA about the mechanisms/reasons that make it work. It's therefore difficult to map links between processes/knowledge. At one place I worked, the best thing to do when no one knew what to do was to ask Joe. If Joe didn't know, we were fucked!

Another problem I've faced was in working in very dynamic environments. Such environments do not make documentation of processes very easy or even desirable, since processes/demands/knowledge are always in flux. In this environment, the most successful people were those with excellent networking skills... Through networking/coffee-breaks/gossip, people information-gathered enough to stay on top of what was going on with the business... Being a social outcast was career-suicide...

I guess one thing I've always found is that people who ask a lot of questions often are the ones that end up with a lot of knowledge. So perhaps the thing to do is have an enviroment where sharing knowledge and asking for knowledge is encouraged. Simple things like having a canteen/kitchen/dining space on-site helps. Encouraging lunch-breaks probably helps as well, as it's an opportunity for people to chat.

"There is no problem so bad you can't make it worse."
- Chris Hadfield
« Sors le martinet et flagelle toi indigne contrôleuse de gestion. »
- my boss

[wmw999 2,589]

I did exactly that with one group during a challenging new development project. Set up a non-management technical meeting for once a week, whether we needed the technical interchange or not. We had cookies and coffee, and ended up talking about technical stuff about 3/4 of the time. It was valuable enough that the group kept doing it after the project was over.

One thing about this kind of interchange is that people who know each other are more likely to trust each other, and trust means that they can share what they think might be mistakes, or decisions in the making.

The earlier information is shared, the better the end result as a rule. That "teamwork" thing actually works if it's a real team.

Wendy P.

There is nothing more dangerous than breaking a basic safety rule and getting away with it. It removes fear of the consequences and builds false confidence. (tbrown)

[TriGirl 343]

Many militaries (and military conglomerates, like NATO), have a Lessons Learned database. You draft a plan or standard procedure based on your educated guesses. When they have an exercise, or actually have to put that plan/procedure into action, you learn a lot from trial and error (or new variables that you didn't know to plan for). Afterward they brainstorm all those lessons learned, compile them into a comprehensive review, and discuss as a planning team which lessons to convert into changes in the plan. That final report goes into a certain format and is entered into a Lessons Learned database. Then, other military organizations writing similar plans/procedures for similar events can check the database using key words and categories before trying to re-invent the wheel.

It's still a cumbersome process, not everyone who needs it has access or knows how to access it, and different databases hold HUGE amounts of data, but if the lessons of disaster relief forces helping out in Japan during the tsunami might help forces headed to the next earthquake in Haiti or Thailand to update their own disaster/evac plan in some way, then it is an incredibly valuable endeavor indeed.

The trick is to design the database so that you have organized sections and subsections, and a form to fill out (instead of one long report written in prose), to normalize the input, thereby making the data easier to filter.

See the upside, and always wear your parachute! -- Christopher Titus

Shut Up & Jump!

[Amazon 7]

Build a searchable knowledge base. All the cool kids have been doing that for a couple decades or so now

[MikeJD 0]

Lack of knowledge sharing in any industry is a blight, but then so is the overhead of producing, reviewing and wading through reams of documentation that nobody will ever read.

Lots of people seem to be favouring an online wiki approach now, and that seems effective to me. It's quick and easy to add knowledge, it's intuitive to follow paths of links to find the info you're looking for, it evolves naturally and it fosters discussion and peer review without becoming a burden.

[Trafficdiver 8]

Ever hear of Evernote? I've never used it but recently read about it, downloaded it and am thinking about starting it. It documents everything you put into it and organizes it.

[nigel99 620]

Quote

Many militaries (and military conglomerates, like NATO), have a Lessons Learned database. You draft a plan or standard procedure based on your educated guesses. When they have an exercise, or actually have to put that plan/procedure into action, you learn a lot from trial and error (or new variables that you didn't know to plan for). Afterward they brainstorm all those lessons learned, compile them into a comprehensive review, and discuss as a planning team which lessons to convert into changes in the plan. That final report goes into a certain format and is entered into a Lessons Learned database. Then, other military organizations writing similar plans/procedures for similar events can check the database using key words and categories before trying to re-invent the wheel.

It's still a cumbersome process, not everyone who needs it has access or knows how to access it, and different databases hold HUGE amounts of data, but if the lessons of disaster relief forces helping out in Japan during the tsunami might help forces headed to the next earthquake in Haiti or Thailand to update their own disaster/evac plan in some way, then it is an incredibly valuable endeavor indeed.

The trick is to design the database so that you have organized sections and subsections, and a form to fill out (instead of one long report written in prose), to normalize the input, thereby making the data easier to filter.

I like that approach, and it can definitely build corporate knowledge but it is slow in my field. They're generally called post mortems and are carried out at the end of a project. The problem is that a typical project takes between 1 and 3 years. Even then it is normally about a year in production before you really have a solid and proven product. But yes that process is invaluable.

Experienced jumper - someone who has made mistakes more often than I have and lived.

[nigel99 620]

Quote

Build a searchable knowledge base. All the cool kids have been doing that for a couple decades or so now

Sorry but that doesn't really work effectively. Look at Microsoft as the best example. They have the developer network, which is probably the biggest and best in knowledge base in the world. Yet when you really need an answer you normally find it off in the web.

I'll give you an example of the problem. A few years ago Dave told me that in twenty odd years of manufacturing electronics (he works at a contract manufacturer) it typically takes 1 year to 18 months after manufacturing starts, before a product is really stable and mature. That tallies with my experience. How do I effectively transfer that knowledge to my new employer? Even if I took the time to put a note into a kb, who's going to search for a random tidbit that helps with project costing and planning?

But regardless they do have a place.

Experienced jumper - someone who has made mistakes more often than I have and lived.

[wmw999 2,589]

The biggest problem with lessons learned databases is the same problem with dropzone.com -- there are always people who don't think that they can learn from those lessons. And, since they're often rewarded when they bypass those lessons (if things work, they end up cheaper and faster), it's a self-perpetuating situation.

An organization has to value that kind of thing. Really. Smart people will end up doing well regardless, but having a strong system that makes one review those lessons will hurt the smartest a little, and raise the quality of the weakest by a whole lot more.

Regardless, some lessons will have to be re-learned every few years, because sometimes only fresh information is what people remember.

Wendy P.

There is nothing more dangerous than breaking a basic safety rule and getting away with it. It removes fear of the consequences and builds false confidence. (tbrown)

[Nataly 38]

Agree with so much of this...

I would also add that in my mind, a far more difficult task is not simply in capturing info, but in the transmission/absorption of it. The fact is that even though we often *do* have access to information, somehow we fail to *use* it... Unfortunately, people (myself included) are rather bad at drawing lessons from other people's experiences... We are also bad at seeing the links across different situations/fields and seeing how different problems are related and could be prevented...

We also fail to do "test-runs"... A simple example: I have known SO MANY people work on marketing campaigns and come up to the client with a "finished product" that looks NOTHING LIKE the original brief... A lot of time and effort would be saved if these people had shown the client a small sample of their idea before comitting time and money toward an entire project... Sometimes you go quite far down the wrong route because you forgot to look at the map along the way...

And finally, lack of planning/preparation... The other day I was at work and my colleague asked me what the hell I was doing, just sipping my coffee... And I answered: "I'm thinking". She was not happy with this, but I told her I wanted to come up with a well thought-through solution instead of just blindly attacking the problem. Too often we simply don't plan enough - or at all!!! We don't take the time to ask questions or look at instructions/databases even though often times one does exist.

The solution to a lot of these problems is to have the kind of work-culture where these behaviours are actively encouraged. Obviously this is easier said than done, but I think frequent briefs and de-briefs should form a part of every "project". I think an "apprentice"-type approach should exist in many jobs and "mentor" programmes put in place whenever possible. I've seen many many many instances when people have the knowledge but simply don't share it. It's a shame. It takes time and energy to invest downward, but in my experience is seems to work far better than computers, books and databases.

"There is no problem so bad you can't make it worse."
- Chris Hadfield
« Sors le martinet et flagelle toi indigne contrôleuse de gestion. »
- my boss