Organisations that work with Knowledge need a Knowledge workstream as well as a Product/Project workstream. But what are the outputs of this Knowledge workstream?
I have blogged several times about the KM workstream you need in your organisation; the knowledge factory that runs alongside the product factory or the project factory. But what are the outputs or products of the knowledge factory?
The outputs of the product factory are clear - they are designed and manufactured products or services being sold to customers. The outputs of the project factory are also clear - the project deliverables which the internal or external client has ordered and paid for.
We can look at the products of the KM workstream in a similar way. The clients and customers for the Knowledge outputs are knowledge workers in the organisation who need knowledge to do their work better; to deliver better projects and better products. It is they who define what knowledge is needed. Generally this knowledge comes in three forms, depending on the simplicity or maturity of the tasks being done. These forms can be documented, they can be delivered in training, or they can be delivered verbally as advice or coaching.
- Good practices and good options which lessons from one or two projects have shown to be a successful way to work. These might be examples of successful bids, plans, templates or designs, and they have been endorsed by the community of practice as "good examples" which might be copied in similar circumstances, but which are not yet robust enough to be recognised as "the best way". I am not including "good ideas" in this list, because untested ideas are not yet knowledge.
- Best practices and best designs which lessons and experience have shown are currently the best way to work in a particular setting or context. These are advisory, they should be followed, and they have been endorsed by the community of practice as the current best approach.
- Standard Practices which experience has shown to be the only way to work in a particular setting or context. These might be design standards, product standards, standard operating procedures, norms, standard templates, algorithms and so on. These are mandatory, they must be followed, and have been endorsed by senior technical management. Obviously standards only help with mature topics in a simple or complicated world, not a complex world.
The three categories are "things you could do" in a particular context, "things you should do", and "things you must do".
The project/product workstream also creates outputs which act as inputs to the knowledge workstream; these are the knowledge deliverables, the lessons which capture hindsight, and the useful items which can be stored as good practices and good options. The link between lessons and best practices is described in a separate blog post, and shows how the two workstreams operate together to gather and deliver knowledge to optimise results. The projects and products create the lessons, which enter the knowledge workstream and come out as one of the three forms listed above.
No comments:
Post a Comment