Body of Knowledge

[ThoroughPM]

Hello EB.  I am undertaking the audacious goal of establishing a comprehensive body of knowledge (BOK) for my company.  We are a design build general contractor with a large number of experienced people retiring in the next three to five years and we need to document atleast some of that knowledge before then. My company is a bit different, we do in house site/civil and some structural engineering as well as architecture which makes the BOK difficult to organize without having major subsections for each different types of our aspects (Construction Technical, Civil, and Architectural).  It seems ideal to me to have topics which can include notes from all sections versus the same topic being discussed in multiple different, independent sections.

I wanted to reach out on the off chance that anyone on here may have experience and be willing to offer some guidance?  If not, I'm definitely interested in general opinions and thoughts from anyone else.

 

[Supe]

You'll quickly find that once you progress past the company org chart and diagrams of procedural flow-down, you won't have much worth writing down until you get to the discipline-specific tribal knowledge.  Draft the individual sections, and then tech edit out the commonalities into a general section if necessary.

As a side note, I've seen this tried on multiple occasions, including in a digital format.  Content was sparse at best and obsolete after a year.  Granted, that was with large EPC firms. 

 

[Ramnares P.E.]

Dividing the BoK into appropriate sections may be the best way to approach it in terms of authoring and using.  I was responsible for creating the Power Piping section of my previous company's BoK prior to leaving and as the author I tried to summarize the general methodology behind the power piping design process, company specific tutorial of the software we used, use of the software pertaining to our systems, interpreting PP software results etc.  When I first started there I was responsible for anchor sizing calculations (a far ways from my specialty) but the company had created Design Data sheets that guided the user through the process.

As you'll quickly find out, the BoK/DDSs will be somewhat general but they can be useful, particularly to young engineers.  

As an aside, I'm sure you've already thought about this since you're starting a BoK, I've found shadowing/mentoring a much more efficient process than collecting/documenting knowledge.  Since you already know you'll be losing these engineers in 3-5 years, you have quite sufficient time to have younger engineers work closely with them.  Just my $0.02.

 

[ThoroughPM]

Thanks for your responses and recommendations.

I agree shadowing is an excellent idea and our company had started that process for the old timers.

The reason I felt a BOK would make sense is we have a few specialists but we often need their knowledge in multiple locations where they cannot always be. So I thought a general database would also be helpful.  We are also growing a lot in the upcoming years and will have an influx of young engineers and I definitely see a value to them.

Any thoughts on ways to encourage company wide participation?  It seems like the more useful it is the more authorship and thus the more useful.

Thanks again for the words of advice so far.

 

[Ramnares P.E.]

I'm not sure how far it really went in terms of encouraging authorship but my company held quite a few brown bag sessions (bring your own lunch) as well as actual lunch sessions (paid for lunch) in order to train younger engineers on the more 'obscure' fields that we used.  It has been my expert experience that anytime food is provided for free, engineers will participate.

A lot of the older engineers saw it as a point of pride to pass on their knowledge but the younger ones were more hesitant.  The company had started out handing out awards for those who conducted classes on their specialty.  It wasn't much, just a printed certificate with a $100 gift card.

Finally, we ran into a few months where work was somewhat slow and since the company was providing an overhead time charge anyway they had us create manuals/DDSs in that time.

Just throwing out some ideas out there ^