Friday, 21 October 2016

Why you shouldn't leave your knowledge in project files.

Project files are the worst place to leave your knowledge, if you ever want to see it again. Think of "Raiders of the Lost Ark"

Each project creates two types of work product.
  • First there are the project files themselves - transactional files related to the delivery of the project itself. We can call these files "project collateral".
  • Secondly there is knowledge, created by the project, which needs to be shared for the benefit of future projects.  We can call these files "knowledge collateral".

Knowledge collateral

Examples of knowledge collateral include;
  • Project overview or case history
  • Bid win/loss lessons
  • New processes or new approaches developed by the project which others can use
  • New solutions which have been tested by the project and which failed
  • New knowledge of the client, the market or the product
  • Project delivery lessons

Knowledge collateral needs to be stored in the public domain, where all future projects can access it, and it needs to be organised and tagged by topic, not by project. People coming to look for this collateral will not know which projects it came from; they will be searching for the collateral based on their immediate need; to satisfy questions such as;

  • What do we know about Client X's buying habits?
  • What do we know about building an X in a remote location?
  • What is the current state of knowledge of designing an X product?
  • What projects have we done in the past in the X industry?

So the knowledge collateral has to be a) in the public domain, and b) tagged by client, activity, product and/or industry.

Project collateral

Examples of project collateral include;
  • Client agreement
  • Project meeting minutes
  • Project budget submission
  • Project agreements with subcontractors
  • Project testing plan
  • Project financial return
Project collateral needs to be stored in the project domain, often held under conditions of security, and it needs to be tagged by project and by document type. People coming to look for this collateral will be searching for it within the context of the project, to satisfy questions such as;

  • Did the project meet the customer needs?
  • Was the project well managed?
  • How much did we pay the subcontractor?
  • Why did we make the project decisions that we did?
So the project collateral has to be a) in the project domain, and b) tagged by document type.

The common mistake, and the impact this has

The common mistake is to treat knowledge collateral as if it is project collateral, and to keep it with the project files.

  • Maybe the project has a folder for "lessons learned" where all the lessons go, 
  • Or even worse, the lessons are bundled in the end-of-project report
  • Maybe the project has a folder for "case history"
  • Maybe the new approach developed by the project are described in the "technical" folder,
  • and so on

The first impact of this mistake is that knowledge collateral becomes very difficult to find, scattered (in many organisations) across multiple repositories; SharePoint, file drives, DropBox, legacy applications. It may even be impossible to find the knowledge, where the collateral is held in locked folders.

Maybe a good search engine - semantic enterprise search for example - could draw all this collateral from the many repositories, but this still leaves problem number two.

The second impact of scattering knowledge collateral across many repositories is that it becomes impossible to curate.  Old knowledge cannot be archived in favour of new, old designs cannot be replaced by new, case studies cannot be put in order of prominence.

An analogy

Leaving knowledge collateral in project files, scattered across multiple folders, always reminds me of this scene from Raiders of the Lost Ark shown below.

  • Think of the crate with it's incredibly valuable cargo as being knowledge gathered from a project
  • Think of the huge and cluttered warehouse being the mass of project files stored in your organisation's repositories
  • Think of the "Top Men" as the well-meaning project teams, with never a thought for KM
  • And then ask - will that knowledge ever be seen again?

Thursday, 20 October 2016

How email plays a key role in Knowledge Management

Email is an unpopular medium, but we should not ignore the role it can play in Knowledge Management

Everyone professes to dislike email.

In most offices, especially after the holiday break, you hear people competing about the number of emails they received – “I had 500 to deal with”, “that’s nothing – my inbox had 1000 unread messages”, “I actually took my iPhone on holiday so I could weed them out before I got back”

Then when you introduce communities of practice, and suggest that the community Q&A forum may somehow be linked with email, people say “Oh No – not MORE emails”.

And yet, you can’t keep people away from email. It's like a habit you can't break. It’s the first thing most people do when they come to the office.  It’s the last thing they do at night. They check email at the weekend, and on the train.  Email is omnipresent - even US presidential electiopns may hinge on who did what with emails.

Email is communication, and lots of email means lots of communication and for most of us, communication is a large part of the job. The email habit is still very strong, and very strong to break. So why not work with it, and use email as a key enabler for KM?

How to use email in Knowledge Management

We are not proposing that email is a favoured way of sharing knowledge - far from it. Community of Practice discussions, for example, should not use the standard email system, where the discussions are stored in private email folders rather than in shared space, and where threaded discussions get lost in mazes of cc and reply-all.

But for the current majority of people, email is the best way to get their attention.  This may change with the rise of enterprise social media, but for the moment email is the primary attention mechanism within most companies.

For as long as people “have the email habit”, then our Knowledge Management activities can use email as a personal notification mechanism.
  • You can link the community Q&A forums to email, so people are notified by email of new questions, and can follow a link to reply to the question.
  • You can link the community Blog to email, so people are notified of new items, and can follow a link to read it all, and comment.
  • You can link the lessons management system to email so people are notified of new lessons, and new actions they need to take.
  • You can link the Wiki to email, so people are notified of new content

For a large proportion of people in a large proportion of companies, if they don’t hear something by email, it might as well not have happened.

Wednesday, 19 October 2016

How NASA incentivises KM

Here is insight into how NASA tackles the issue of incentives and motivation in KM.

Image from wikimedia commons
Incentives and motivation has long been a topic on this blog.

Here in Knoco we believe in intrinsic motivation rather than motivation through rewards or prizes, preferring to use recognition, peer pressure and management expectation to bolster the behaviours of people sharing and seeking knowledge because they believe it is the "right thing to do".

The latest NASA CKO newsletter contains an interesting article on motivation which shows that NASA takes a similar approach; namely avoiding extrinsic rewards and focusing on that "sense of doing the right thing". The author (Michael Bell, the Chief Knowledge Officer at NASA Kennedy Space Center) tells us:

Experience has shown that using games and offering material rewards to encourage knowledge sharing in organizations can have serious downsides. Paying people a bit of cash for sharing their expertise or entering them in a lottery for gift certificates can seem to trivialize the essential activity of collaboration and even be seen as an insult to professionals who take pride in their work. And games with prizes sometimes tempt people to try to “game” the system. Offering cash for lesson submissions often means that quantity goes up and quality goes down. And one NASA center that tried giving cash for contributions to the lessons learned repository found many attempts to cheat the system.

Instead NASA focuses on using a common sense of purpose and a desire for social interaction within Communities of Practice as driving forces for Knowledge sharing and seeking.  This story is a great example of how such intrinsic motivators operate.

Recently the Morpheus project manager came to Kennedy Space Center (KSC) from Johnson Space Center to share lessons learned. Morpheus is developing a prototype lander that can land and take off vertically. The PM shared some technical lessons but really became passionate when he shared the lessons learned about how he communicated the project’s risk profile to stakeholders and senior management. He described how he was successfully able to “fail forward” because of the rapport he established with his stakeholders even within a NASA culture that is risk averse and under a 24-hour-a-day media microscope. My impression was that he was spreading the good news with the hope of making the agency better—a goal that the audience shared.

So, tempting though it might be to offer money, prizes or badges to incentivise knowledge sharing, please think twice. Think how prozes may be gamed, and how badges may trivialise something which is far more important, namely a shared sense of community and purpose. Also recognise, as NASA is beginning to, that incentivising sharing is not enough, and that you need to incentivise knowledge seeking and re-use as well.

The NASA article ends with this note of recognition that things could be improved still further!

It is possible we do not yet put enough emphasis on sharing knowledge with others and seeking the best knowledge from others. An employee once told me, “I don’t recall anyone being recognized for looking at a lessons learned.”

Tuesday, 18 October 2016

Free webinar on Friday

I am delivering a free Webinar this Friday as part of the KnowTouch series

The series is on the theme "20 years of KM - looking back to look forward"

  • 21st October (1-2pm CEST, 12-1pm UK time): 4. KnowTouch Pre-Webinar with Nick Milton (REGISTRATION)

Do please feel free to join in - it would be good to see you there

Nick Milton has been part of the Knowledge Management Team of BP and is now part of the consultng team at Knoco. Together with Patrick Lambe he wrote the book "The Knowledge Manager's Handbook". In the webinar he will talk about past, current state and future of KM from a UK/international perspective. Language of the webinar is English. The webinar is part of the KnowTouch Pre-Webinar series. Informationen (in German) at

Monday, 17 October 2016

How often do you audit your KM framework?

Any type of management system requires a regular audit. How often do you audit your KM management system?

If you look at the ISO standards for management systems, all of them include a clause about audit.

The quality systems standard ISO9001:2015, for example, contains the following clauses:
  • 9.2.1 the organization shall conduct internal audits at planned intervals to provide information on whether the quality management system 
  • a) conforms to 
  • 1) the organizations own requirements for a quality management system,
  • 2) the requirements of this International Standard
  • b) is effectively implemented and maintained.
  • 9.2.2 the organization shall plan, establish and maintain an audit program including the frequency, methods, responsibilities, planning requirements and reporting ... (the text continues for several sub-bullets).

In the absence of a completed ISO standard for Knowledge Management (due out 2017 or 2018), we need to look at these other management system standards to see what good practice looks like, and ISO good practice for every management system includes regular audit and review.

KM Framework audits

In a recent post, I suggested that there are two types of KM audits; the scan and the assessment. I said the first was like counting the apples in your orchard, the second was like reviewing your farming methods.

It is the assessment - the methods review - that has the most value, in that it tells the health of your Knowledge Management Framework (and, to continue the metaphor, if the farm is healthy the apples will grow).  The assessment will look at every element of your framework, and identify those areas where attention and improvement is needed, be they roles and accountabilities, technologies, processes, or governance.

The assessment is therefore closest to the type of audit mentioned in the ISO standard above, and really should be conducted on a regular basis.

However the audit is also valuable, so long as you also run it regularly. It doesnt idtenfity what you are doing well or badly in KM terms, but it tells you how well managed your knowledge is.

The audit measures the current management status of various knowledge topics - are they documented, are they covered by communities, are they held only in the heads of a few people approaching retirement? - and outputs these as metrics. When you introduce your improved KM approaches, the audit should show improvement over a range of numbers.

Our favoured approach to run the audit on an annual basis. It works like this
  • The KM team works with the knowledge owner, or process owner, to audit their own knowledge area.
  • Based on the results of the audit, they identify actions for the following year
  • The next year, the audit should show improvement
  • The KM team can use the audit results, and the change in results over the year, to construct a KM dashboard for reporting to senior management. If KM is working, all audit scores should show an increase over the previous year.

Contact us if you want help auditing your KM Framework.

Friday, 14 October 2016

KM and "Battle rhythm"

"Battle rhythm" is a concept used in the military, and is used as a framework onto which to pin Knowledge Management. Maybe we can use a similar concept in the office?

My colleague Cory has just published a very interesting paper entitled "Knowledge Management in a combined/joint environment". He looks at the challenges of introducing KM in a joint endeavour between many different military organisations, and makes some great recommendations.

Once of the concepts that Cory's paper refers to is the idea of Battle Rhythm. This is defined as follows:

A deliberate daily cycle of command, staff, and unit activities intended to synchronize current and future operations. (Military dictionary)

The battle rhythm is the heart of the military's operational knowledge management process. Effectively managing the battle rhythm means effectively processing inputs and intent to allow the Commander to make decisive decisions. (Managing the battle rhythm).

The battle rhythm is effectively a learning and decision making cycle of Plan, Do, Monitor, Learn, used to drive effective decision making through gathering and integrating knowledge and information. The second reference above describes how the battle rhythm process can be boiled down to four basic phases:

  • receiving observations from multiple sources, 
  • integrating observations to create usable knowledge and insights, 
  • deriving learnings and knowledge which can be passed to decision makers, and
  • reaching a decision point. 
These steps can be adapted to all levels of command: from the strategic down to the tactical, with adjustments made for the rapidity of information flow using technology and processes. Battle rhythm also ensure the flow of knowledge upward through the layers of command, so decisions can be made at the right level.  Software tools are often applied to ensure the correct upwards flow of knowledge.

So can we do the same in our own organisations?

Yes, of course we can. We can use similar learning cycles of Plan, Do, Monitor, Learn, adapted to our own rhythms of work. As this blog post points out:

Every good organization has certain regular patterns. Staff meetings are at 9:00 on Tuesdays. Quick huddles are every morning at the beginning of the day. Subordinates submit standard reports every Friday on the week's activities. Football teams establish this sort of standard practice week before Saturday games. Teachers / construction workers / policemen know and understand the flow of the week and what they must do as a part of each of the mandatory activities. This is the framework in which we fit everything else we must do.

These rhythms might be;

  • Tasks
  • Activities
  • Projects
  • Sprints and scrums
  • Daily operational meetings
  • Weeky planning meetings
  • Monthly sales cycles
  • Monthly/quarterly/annual production cycles
  • and so on
For example, the world of onshore oil well drilling is divided into three cycles - 
  • Daily cycles of performance targets and reporting
  • Cycles based on individual wells from start to completion
  • Cycles based on programs of wells.  

This is the "battle rhythm" of drilling onshore wells. The learning cycle, and Knowledge Management, can be brought into this at three levels as well;

  • Informal conversations around the morning report to identify lessons and make decisions for the next day's operation;
  • End-of-well After Action reviews to identify lessons used to make decisions for the next well;
  • End of Program Retrospects to capture high level lessons, which will be used to make decisions for future drilling programs. 

So what is the "battle rhythm" for your organisation?

What is your activity cycle, and decision making cycle?

Once you have worked out what this is, then you know how and when to apply Knowledge Management to ensure that the decisions makers at all levels are always supplied with the correct knowledge to make their decisions as successful as possible.

Thursday, 13 October 2016

In KM, more is worse

In Knowledge Management, less is more. It's better to focus on providing fewer examples of top quality knowledge than a lot of mediocre content.

Image from wikimedia commons
In their excellent book "Working knowledge", Davenport and Prusak point out that "Volume may be the friend of data management, but it is the enemy of knowledge management; simply because humans have to sift through the volume to find the desired knowledge".

The ancient Greek poet, Aeschylus knew this when he wrote "A wise person knows the right things, not many things"

I blogged a while ago about applying Lean principles to Knowledge Management, and removing waste from the Knowledge Management supply chain. Too much volume, too much waste, in the supply chain is counterproductive, and can destroy a KM initiative. Again - here is Davenport and Prusak with an example.

"Knowledge can also move down the value chain, returning to information and data. The most common reason for what we call "deknowledging" is too much volume. As one Andersen Consulting knowledge manager told us - "We've got so much knowledge (not to mention a lot of information and data too) in our Knowledge Xchange repository that our consultants can no longer make sense of it, For many of them, it has become data".

We can see the deknowledging effects of volume in many settings:

  • Lessons learned databases that become cluttered with minor, duplicated or out of date lessons
  • Social media streams that are clogged with trivia, and with people reporting activity (maybe led by that brainless Yammer pront "What are you working on") rather than discussing knowledge
  • Knowledge published in multiple places (see the extreme example in this blog post, under "When WOL goes horribly wrong")
  • Knowledge bases which are bursting with work products, rather than containing synthesised knowledge

These examples of de-knowledging are driven by a few common factors:
  • Emphasising (and often incentivising) knowledge production and sharing rather than knowledge seeking and application, for example the companies who say "We want to promote Knowledge sharing", even going so far as to set each individual a target of "sharing X items very year"
  • Capturing knowledge "just in case" rather than for a purpose
  • A lack of resources for sorting, compiling, curating and synthesising knowledge into guidance documents (and then archiving the lessons and work products once they have been synthesised)

All of these are counterproductive. Instead you should do the following

Cut the volume. Go for the faucet and not the firehose; quality over quantity.  Aim for a small number of documents of concentrated, high quality knowledge, not a large number which people will need to sift through and sort for themselves. 

Because, as the Andersen example shows, if there is too much volume they just won't bother. 

Blog Archive