Nick Keenan wrote a blog on his site about writing a company bible (link provided below). I thought it was very well thought out and quite useful. I’ll admit that this sort of record keeping and process appeals to me in general. Nevertheless, there are a variety of good points in the blog.
-Distribution of information in a company is always a challenge. Each company creates a preferred working arrangement with preferred techniques. Speaking of scenery – some places only use 1x3, some use 1x4. While this is obvious by walking in a shop there are many subtle building techniques that often differ from one site to another. Where I work now “solves” that with a shop standards book, which is out of date, and only referred to when someone didn’t do it the “right” way. So with multiple project managers and multiple job leads, it sometimes feels like 6 or 7 different companies working under the same roof, all reinventing the same wheels.
-Updating information is another challenge. This requires commitment throughout the organization. I like the wiki idea, because behind the idea is that the information is not really final, just the current revision. The shop standards book here has an air that once completed it was “published and released”. Thus, it is a closed affair and will have a “cost” attached to revise. A company hopefully learns and grows through the corse of their work. Updating consistently allows this happen, and helps to further the growth. Allowing older information to stay through a forum can help newer people to the company get a hold on the history. Documenting successes are just as important as failures – you learn something from both results.
-I love the idea of an online community. Today, more than ever before we are an interconnected society, and communication takes on newer and more varied forms. I am also a fan of transparency. An online forum keeps the group as a whole in communication about all of the topics of the group, and thus can contribute on all of the topics, or at least be aware of the broader picture.
-I see a couple of drawbacks with the system. You have to be of an appropriate scale. If a company is too large, too much time will be spent maintaining the wiki and the forum, and not enough time producing, though I suppose the forum is also a metaphorical water cooler. Too little people in the company and the same thing happens – or there isn’t enough to keep the pieces together and it turns too social. Both scenarios are thoughts I have – and could stand to be corrected. I also would think that the larger the group the more the forum and wiki would tend to be run by fewer people – department heads and not carpenters, which starts increasing the gatekeeper issues discussed by Nick. Also, you have to have buy-in. Belonging in a group such as this would require a bit of work and learning. Entering into a group where it was a clearly established norm, would make new entry easier – but creating the system for a preexisting company may have some growing pains with getting participation.
-An additional comment I would have about writing a manual is that in addition to implementing or revising procedures as being the time to write and revise, I would say that someone new can help to revise. Why? Because they are learning everything for the first time and will often see more clearly the differences between the espoused method in the manual, and the working solution in action. They will also be very aware of questions and gaps where the information is limited.
At any rate, it was a good blog to read, and was full of advice that can be useful. Check it out at: