Documents that are open and dynamic allow people to evolve the documents by direct editing or leaving comments…ie. people are sharing their experience and what they know can add to the richness of the document.
Right away I thought of the How-To Guides I’m writing for our Communities of Practice (CoP) at work.
Wikis are great for communal documents, such as How-to guides or protocols. As people gain expertise, they can provide comments, hints or questions that can make the document richer.
This way they can help me evolve the document, even though it’s finished. Well, that’s the idea, it’s never finished…I may miss a feature, and I can’t experience every context, so there’s stuff that happens when people use Communities that I may not know up front. eg. a new way to use blogs, a workaround (exception to procedure) page for Document Control as each client has different needs.
They may leave a comment about a feature of our CoPs where they have a workaround, or a use case.
eg. someone might say everyone in our team has a status blog, so when we go to a meeting we already know what everyone has been up to, our meetings are more about action.
Another person visiting the guide may see this and use this idea.
A simple comment box on a wiki has enabled the sharing and receiving of know-how by two people that don’t even know each other, plus this is perpetual as another person may come along and get value or an idea from reading the same comment. In fact another person may leave a comment back and say that they found it more manageable having one group blog for status. The original person my see this and comment back saying, that is a great idea, I didn’t know that was possible. Oops, that’s because I may have not put that fact in the guide, lucky that comments allow for others to help where the guide fails.
And as Stewart mentions I can go and refine the guide and leave a comment saying thanks.
Also, all of this interplay, this dialog, is also explicit, it is all time-stamped and it can be used to analyze how useful that particular document is. By making it explicit, a lot of metrics can be applied that will finally be able to measure what formally was invisible. This will not only be useful for the organization but also for the individual, say during performance reviews. Before, no one knew how important a protocol might be, especially if it was just stuffed into a binder in the lab. Now, anyone could look and see just how often that protocol was examined, and by whom..
In the end we have this explicit type deliverable that has to be formal and succinct as it has to cater to many audiences, and can’t be too explanatory (long), and try to cover every context possible, as people won’t bother reading it. But on top of this we have a layer of collective know-how and feedback via the comments which inturn we feed back into the document (via edit) some tacit know-how.
The point is having perpetually live documents (editing and comments) harnesses the collective wisdom, where people can share their know-how, and benefit the user experience as a whole. It’s a win win situation.
And, if a different document needs to be created for a different audience, the community will be there to help.