Thursday 27 November 2014

Knowledge for Action, Knowledge for Interest

Knowledge has to lead to action in order to add value. As Bill Wilson says (albeit about learning rather than knowledge per se) "Learning without action is mere mental trickery, while action without learning is simply useless physical exercise".


We have been working with a client recently on developing a lesson learning system from projects. The collection of lessons has been going well, but the client had the firm view that lessons should be collected in a library that future projects could review if they wanted. For them, the knowledge would be "for reference", or "for interest".

Of course, few people have time to read through the lessons, and there are now so many lessons that reading through them is becoming more and more daunting. 

We are now helping the client to move to a different philosophy, where lessons are forwarded to the owners of the organisational processes, so they can continue to update the processes in the light of the new learning. This is "knowledge for action".  

We recommend "knowledge for action" rather than "knowledge for interest" as being a far more effective system.

Communities of practice, as well, should focus on actionable knowledge. Actionable knowledge is

  • Advice
  • Good practices
  • Improved practices
  • Solutions to problems
  • Answers to questions
  • New approaches
  • Recommendations
  • Guidance
  • Tips and Tricks
Non-actionable knowledge is
  • Interesting articles
  • Links to interesting articles
  • Musings
  • Quotes and aphorisms
  • Descriptions of what you are doing (unless you analyse this to bring out actionable learning)
  • Descriptions of what you have done (unless you analyse this to bring out actionable learning)
  • Gossip
Communities that circulate non-actionable knowledge, or "knowledge for interest" are classified as Communities of Interest rather than communities of practice, the clue being in the title. 


CoPs deliver more value when they focus on solving the problems of the members than when they circulate "interesting links and ideas". CoPs that operate through a Pull process - where members with problems or issues ask questions and receive recommendations and support from other members - know they are adding value.  Each answered question represents a solved problem; knowledge which the person who asked the question can immediately put into action.

In a question-led CoP, each interaction leads to action.(Tweet this

So when you are sharing knowledge in a CoP, ask yourself whether you are sharing "something that others will find interesting" or "something that will help people do their job better" - something actionable. If you have nothing actionable to share, then ask a question instead.

And when you are designing lesson learning systems, make sure each lesson leads to action, rather than being retained "for interest".

4 comments:

Eli Miron said...

The actioable knowledge is of two types: immediate and future. If a new best practice regarding the operation of a workstation, it should be pushed to the managers of all other workstations. If the best practice is a new approach in strting new project - it should be stored in an appropriate repositor for future use. It ibecomes useful only if there is a porcedure that forces project managers to check this repository before starting.

Nick Milton said...

I would suggest, Eli, that if "the best practice is a new approach in starting a new project" then instead of putting it in a repository and hoping people will read it, the appropriate action is to update the "new project start-up process".

If there is no "new project start-up process" then the action is to write one.

Keeping lessons in a database and hoping people will read them fails on four counts
1. They don't read them, no matter what the process says
2. If they do read them, they don't know which items are advisory and which are mandatory
3. Over time, you start to get duplicate or even contradictory lessons as practices evolve
4. Over more time, the lessons collection becomes too huge to consult.

Eli Miron said...

In reality things are not black or white. We should try to keep procedures as short as possible, being too long causes skipping. This is especially true for workstations.
The most immediate actionable knowledge is field implementation. E.g. - in a factory it was discovered that overheating occurred in a workstation because of an internal water leak that was not discovered in time because the flow meter was in the input side instead of in the output side. The actionable knowledge is to fix all workstations.
Two organizations that I know have an online system of producing lessons learned and best practices. The LLs and best practices are easily accessible online. I do not see a problem in location of best practices even in a relatively large repository; one only needs proper metadata (obtained automatically from the input form), and a reasonable search mechanism.
If in every PDR the project leader is required to show what was found (or not) in the LL database this means that the proper culture has been instilled. Success stories of the "jems" found in this database helps too.

Nick Milton said...

I agree that every project leader should review the Lessons Management System, as well as current best practice, at the start of every project phase, That way they can pick up any lesson that has not made its way into procedures. However the primary source of guidance are the procedures and guidelines, which become refined over time through incorporation of new lessons.

I also agree that the most immediate action in your case can be to fix all workstations, and you can also add the action to review the workstation design in case someone has put the flowmeter in the wrong place on the CAD drawings (this will fix all future workstations), and a third action to verify and report that each workstation has been checked (and to report the number of cases where the meter was in the wrong place). This final action is the governance step.

However the goal should be that every lesson should be closed out through an action, and that ideally no lesson should be left as "advice for future project leaders". I know several organisations that get very close to this 100% close-out target (the military being a prime example). Once the lesson has been closed out, and procedures and guidelines updated, then the lesson can be archived, which removes the risk of filling the database with multiple, duplicate, out-of-date and/or contradictory lessons. The extreme example of this was the company that had captured over 20,000 case studies, each "for future project leaders to read". You can guess how many of these actually were read!

You can read more about "lessons and actions" in Chapter 7 of my book "The Lessons Learned Handbook"
http://www.amazon.co.uk/The-Lessons-Learned-Handbook-Approaches/dp/1843345870

Blog Archive