Friday, 31 October 2014


Knowledge Management for bid teams


A couple of weeks ago I published a blog post about KM for Sales. A bid team is also involved in selling, but selling in a very different context to that of the field sales force, and the Knowledge management framework for bidding is more akin to that for projects. 


The task of compiling a modern bid document should not be under estimated. The cost of tendering can run into very substantial figures. The bid team works as a team. Some organisations have a full-time team to work on all bids, while others create new teams to service each bid.

 We have worked with bid teams in the Nuclear Industry selling services for decommissioning nuclear power stations, bid teams in the service industry bidding for major PFI (public financed initiative) contracts, and oil and gas teams bidding for the right to explore acreage. In each case, the team is looking to sell its service to the client, in competition with other rival companies.

Bidding is not a continuous operation, it is episodic, and each bid can be considered to be a project. The metric for the bid is simple - win or lose (although the magnitude of the win is also important, as the service needs to make a profit. As one bid manager told us, “If we get it wrong on a major bid, we can get it wrong for the next 25 years”).   The best bid team is the one with the highest conversion ratio - the ratio of won bids to lost bids.

 A bid team needs the following knowledge.

  • Knowledge of the bidding and procurement process. They have to know how tendering works, how prequalification works, how bids are awarded, and so on. This is fairly basic knowledge, but needs tailoring for each specific market and each specific bid process. Does the client have a preferred contract style, for example? Do they require certain prequalification conditions? What aspects of the bid document are most important, and will be awarded most points in the bid evaluation process? The bid team needs to acquire this knowledge from previous teams operating in this market or with this client. 
  • Knowledge of the client. They need to understand the needs of the client, and their business drivers. The successful bid will be one which speaks directly to the client’s needs, and which uses examples and references which the client will understand and appreciate. This knowledge will come from those who interact with the client - maybe the sales force, maybe people with a history of working with that client, or people already delivering a service to that client. 
  • Knowledge of which bids may be coming up in the future. There is huge advantage in being networked into the market, so that you have advanced notice of forthcoming projects before the request for tender is issued. You can gain some advanced notice, and do some research before the bid even begins. Again, this knowledge comes from your colleagues already working in the market. 
  • Knowledge of how to construct a bid document. Creating a bid document is a complex project requiring collaboration between many people, and the cost can be considerable. There is huge value to the organisation in being able to construct bids quickly, effectively and efficiently, perhaps reusing powerful content from previous bids. Again, the bid team needs to acquire this knowledge and content from previous teams within the organisation. 
  • Knowledge of the product or service. This is crucial, and this knowledge provides the core of the document. Very often, the knowledge and experience of the bidder is a strong selling point, and this experience needs to be clear in the document. Also you need to make it clear that you have a good Knowledge Management system in place, and that you can therefore guarantee that the service or product you are offering will include the best knowledge of your company. This knowledge comes from those already delivering that product or service. 
  • Knowledge of pricing. This is also crucial knowledge. For a big bid, if the pricing is too low, the company may make a loss for a long time. If the pricing is too high, they may not win the bid at all. This knowledge comes from past history of bidding, and from teams already delivering the service (and who can therefore warn of hidden costs and hidden risks), as well as any market intelligence which might be available. 

A Knowledge Management framework for bid teams will therefore contain the following elements. 

  • Processes 
    • Lessons capture (Retrospects) at the end of each bid. 
    • After Action Reviews during bid preparation 
    • Peer Assist at the start of each new bid, involving previous bid teams, people currently involved in delivering the service which is being bid, and anyone with detailed knowledge of the client. 
    • Creation of knowledge assets on bidding
    • Creation of knowledge assets on main products and services 
  • Roles
  • Technology 
    • A knowledge base including a historical knowledge base of previous bids, and relevant pieces of “boilerplate” text which can be reused in future bids. 
    • A forum for the bidding Community of Practice 
    • A yellow pages, to allow the bid team to identify the correct people to attend the peer assist.

Thursday, 30 October 2014


The 3 types of Knowledge Collateral


All projects deliver not just a product, but knowledge as well. Part of any Knowledge Management policy therefore has to be a definition of the expected Knowledge Collateral, or Knowledge output, from project work.  This knowledge collateral is distinct from any information products.


There are three main types of Knowledge Collateral, which should be carefully defined in the project Knowledge Management plan.


  1. Better ways of doing things. These are recorded as Lessons throughout the project, and especially at the end of project stages. The lessons will be entered into the company Lessons Management System, and fed through into process improvements. For product development projects, there may also be product improvements that were introduced, and these can be documented as Toyota-style A3 sheets, and stored in the product folder. 
  2. Good examples. These are project outputs that are "best in class" and can be offered to other projects as templates. They will be stored in the knowledge base associated with that process.
  3. Knowledge that is needed further down the value chain. The project may deliver "information products" like installation manuals, as-built designs and so on, but in addition there may need to be knowledge products. These will describe WHY products were designed the way they were (captured in documents such as Basis of Design, or the Rolls Royce Decision Rationale editor, or may capture HOW knowledge such as how best to sell, maintain, install or operate products. 

Wednesday, 29 October 2014


What do KM professionals actually do?


The Word Cloud shown below is derived from linked-in job descriptions of 40 people with "knowledge Management in their job title, as an attempt to analyse the way KMers describe their job. 


It's an interesting plot, but becomes even more interesting when we contrast those KMers from legal firms, with those who aren't. 


Total word cloud

First, the main cloud, shown above. I created this by choosing at random 40 of my linked-in connections who had "knowledge management" in their job title, and who gave a detailed description of their main tasks or activities. 

20 of these people were from legal firms, 20 were not. All were from the UK and US.  

I copied their current job description, and pasted the aggregated text into tagcrowd.com.  The words which are displayed in the plot above are those which were most commonly used (excluding prepositions etc), and the size of the word is proportional to the number of times it appeared. 

So what does this tell us?

  • Obviously, knowledge is at the heart of the job, and management as well.
  • Business, Development, Strategy, Systems and Support are common words, reflecting the common need to support the business, and develop KM strategies and systems
  • Management is a more frequently used word than Sharing (although this may be because I chose people with a "Knowledge Management" title and not a "Knowledge Sharing" title
  • Information is a prominent word - we still have this blurring of confusion between information and knowledge
  • Practice/processes and technology appear - so two of the 4 table-legs of KM are present. As we know, governance and roles are frequently ignored.
  • It's good to see Collaboration and Communities in there, also learning and experience.
Now let's compare clouds for the people who work in legal KM, and those who don't.
Word cloud for legal KM job descriptions


Non-legal word cloud

There are a number of words that appear in the legal word cloud but not in the non-legal cloud. 
  • Firm, 
  • Intranet, 
  • Law, 
  • Legal, 
  • Library, 
  • Records, 
  • Research, 
  • SharePoint
Here's some of the words that appear in the non-legal word cloud but not in the legal cloud
  • Change, 
  • Engineering, 
  • Experience, 
  • Improving, 
  • Learning, 
  • Network, 
  • Organisational, 
  • People, 
  • Social
There are still a lot of words that appear in both clouds, but you can see two distinct flavours of KM here. Legal KM has a greater focus on records management, use of SharePoint, library techniques, and research (the word Content is also much bigger in the legal cloud). 

Non-legal KM has a greater focus on continuously improving, on organisational learning from experience, and from networking people into social communities (the word Communities is also bigger in the non-legal cloud).

The legal KM flavour is largely driven by the nature of the legal business, and the focus on specialist product, but there is still room for some of the non-legal KM components to begin to be developed in the legal sphere as well. 

Tuesday, 28 October 2014


Content and Conversation - the two subjects of KM


I have blogged a few times about Connect and Collect - the two parallel approaches to transfer of knowledge. Now lets look in more depth about the subject of that transfer - the material or the stuff that is enabled by the transfer. 

  • During the Connect approach we facilitate the transfer of knowledge through Conversations, whether these are electronically moderated or face to face.
  • During the Collect approach we facilitate the transfer of knowledge through captured and codified Content in the form of documents, files, text, pictures and video.
We also know that Conversations are a far richer medium than Content (see here - thanks Valdis) - potentially 14 times richer, though Content can reach far more people, and has a longer life-span than a conversation.

Any comprehensive Knowledge Management framework needs to enable, promote, facilitate and otherwise support both conversation and content.

Managing conversation without content leaves no trace, other than in the minds of the people involved. That is itself is useful, and we know that most of the processes of Knowledge Management, such as Retrospect, After Action Review, Peer Assist and so on are valuable individual learning experiences. But managing conversation without content is not a valuable organisational learning experience. Unless new knowledge becomes embedded in process, or guidance, or recommendations, it is never truly "learned", and without this we find knowledge becomes relearned many times, with errors being repeated, wheels reinvented and so on.

Managing content without conversation leads KM towards the already established fields of Content Management and Information Management, and you could (as the author of the famous "Nonsense of Knowledge Management" did) challenge what KM adds over and above these other disciplines. A focus on content without conversation results in a focus on publishing; on creation of knowledge bases, blogs, wikis, as a proxy for the transfer of knowledge; on Push rather than Pull. But unless people can question and interrogate knowledge in order to internalise it, learning can be very ineffective.

There is a saying in social media circles that "Conversation is King, Content is just something to talk about".

Like any other attempt to avoid duality, this is wrong. Knowledge Management, as a field, is far more "both/and" than it is "either/or".

Content and Conversation are the King and Queen of Knowledge Management - they rule together.

Content is something to talk about, Conversation is where Content is born and where it is Tested.

As a Knowledge Manager, please focus equally on both, and please do not assume that all Conversation needs to be written either. Face to Face is still the preferred transfer mechanism for high-context knowledge, and "getting people together to talk about what they know" is an amazingly effective tool within your Knowledge Management Framework.



Monday, 27 October 2014


KM Change model vs KM Maturity model


Earlier this week I took part in a telephone discussion about Knowledge Management maturity models, set up by Stan Garfield.  I know Stan asked me to take part because of my contrarian views (such as my post on why KM Maturity models can be dangerous), as he was looking for some debate on the topic. 


Here is the basis behind my thinking.

The use of a maturity model allows an organization to have its methods and processes assessed according to management best practice, against a clear set of external benchmarks. Maturity is indicated by the award of a particular "Maturity Level". The majority of KM maturity models (and ours is no exception) have a series of descriptors of various levels of KM maturity, and the implication is than an organisation can progress from one level to the next in a smooth maturation process.

The analogy, if you like, is that of a tree. As a tree matures, it passes from a seedling to a sapling to a mature tree, but this is a continuous progression. You can describe, using metrics such as the number of branches, size of trunk, number of fruit, where the tree is on its maturation journey. If you won an orchard, you can describe the average maturation level of the trees as (for example) 2.5 on the maturation scale.

Knowledge Management is more like a Butterfly than a tree.

A butterfly does not mature slowly, it goes through discrete changes. It goes through three main stages - several months (sometimes years) as a caterpillar, a few days or weeks as a pupa (unless it overwinters) then emerges as a butterfly. You would be better off describing a butterfly with a change model than with a maturation model. If you own a butterfly farm, you measure the maturity of butterflies not on a maturity scale, but on a percentage change basis. You say "none of them are butterflies", "20% have hatched as butterflies" and so on.

Knowledge Management is a butterfly rather than a tree, because implementing KM is a culture change process. It involves changing hearts and minds, and hearts and minds, like butterflies, are changed one at a time. We have all seen the moment when a heart/mind changes and someone "gets lit". It's that lightbulb moment, like "catching fire". (There's another metaphor for KM in an organisation - a bonfire. Either it's caught fire, or it hasn't. Once it has, the question becomes "how much is burning").

I describe here a change model for hearts and minds which you can apply to your key stakeholders, that takes them up to a commitment threshold, beyond which KM can be adopted. Below this threshold they are KM caterpillars; afterwards they are KM butterflies.

KM then works only if all the conditions are sufficiently right to change the hearts and minds.

What's the problem with maturity models?

I see two problems. The first is the idea that progression up the levels equals progress.

Take Leadership, for example.

Senior management support is the biggest enabler (and lack of senior management support is the biggest barrier) to KM. Leadership is vital. Imagine a leadership scale from 0 to 4, like the maturity model Stan Garfield shows. Imagine you have moved leadership from level 1 to level 2. Is this progress?

If level 4 is "whole--hearted support from senior management", what is level 2? Half-hearted support? That's as bad as no support at all. Until you get to level 4, you don't have what you need for sustained KM.

Rather then trying to move the whole organisation to level 2, why not find the one leader who you can help reach level 4? Leave  the rest at level 1 for the moment, and find the early adopter. Gain his whole-hearted support to pilot Knowledge Management in his part of the business, deliver success, and use this to change the next Heart and the next Mind.

Secondly there is the idea that different enablers can "mature" at different rates. This ignores the fact that Knowledge Management is a system, with all parts working together. For another analogy, think of KM as a central heating system. Here you need many elements to make the system work - boiler, radiators, pipes, pump, thermostats, fuel supply, electricity supply - in order to move heat through your house. Similarly you need many elements to move knowledge through your organisation.

Better to build a small complete system somewhere as a prototype or proof of concept, than try and perfect individual elements everywhere.

What is the alternative?

In Knoco, we actually do offer a maturity model, which we give away for free, or provide as an online survey. It is of some use, but treat it with caution for all the reasons mentioned above.

Instead we suggest you measure a number of other things

The real message behind all of this is that KM is a change program, and needs to be measured using change models.

It does not mature like a tree; it changes like a butterfly and catches hold like a flame, and that is how it should be measured.





Friday, 24 October 2014

The two questions you can use to drive a KM culture


If you are a leader who want's to help develop a Knowledge Management and Organisational Learning culture in their organisation, you can do this simply, by asking two questions. 

The two questions are
Who have you learned from?
Who have you shared this with?

If you are a leader, then every time someone comes to you with a proposed solution to a problem, or a proposed course of action, you ask “Who have you learned from”? Through this question, you are implying that they should have learned from others before proposing a solution – that they should have “learned before doing”.

Also, every time someone comes to you to report a problem solved or a process improved, or a new pitfall or challenged addressed, you ask “Who have you shared this with”? Through this question, you are implying that they should share any new learnings with others.

The great thing about leaders’ questions, is they drive behaviour. People start to anticipate them, and to do the learning before, and the sharing afterwards. People hate to be asked these two questions, and having to answer “umm, well, nobody actually”.

They would much rather say “we have learned from X and Y, and have a Peer Assist planned with Z”, “We have shared with the A community, and are holding a Knowledge Handover next week with B project”.

And once you drive the behaviours, the transfer of knowledge will happen, the value will be delivered, and the system will reinforce itself.

But the moment you stop asking the questions, people realise that you, as a leader, are no longer interested in KM, so they will stop bothering.

There’s an old saying – “What interests my manager fascinates me”, so make sure you are interested, and ask the questions.

(Incidentally, I discovered yesterday that two similar questions - "Show me that you have shared knowledge" and "Show me how you have re-used knowledge" - are embedded into staff appraisals at Microsoft, as a way of driving the right Knowledge-friendly behaviours).

Thursday, 23 October 2014


Available for pre-order - "Designing an effective KM strategy"


Advanced copies of my new book - "Designing an Effective KM Strategy - A Guide for the Professional Knowledge Manager" by Nick Milton and Stephanie Barnes, are now available for pre-order from Information Today; 3 months before the final release date January 2015 and at a 40% price reduction.

"Undoubtedly one of the best books available for anyone undertaking to do something interesting and useful with knowledge in their organization." —Larry Prusak, KM guru and author

When a firm’s Knowledge Management program isn't aligned with organizational strategy, its success can be no more than a happy accident—if it succeeds at all.

In this practical, step-by-step guide to crafting an effective Knowledge Management strategy, Stephanie Barnes and I prepare Knowledge Management professionals to:
  • Connect KM strategy to business strategy 
  • Identify the business drivers KM will support 
  • Survey your strategic knowledge areas 
  • Define your program scope and vision 
  • Obtain stakeholder input and buy-in 
  • Select pilots that kick-start successful rollouts 
  • Apply change management principles 
  • Build a sound KM framework 
  • Manage content and technology 
  • Assemble and lead effective KM teams 
Whether you are looking to reinvigorate your current Knowledge Management program or build an effective program from the ground up, Designing a Successful KM Strategy is the comprehensive, no-nonsense guide that will help you get it right.

Designing a Successful KM Strategy will be launched at KM World, and Stephanie will be present in the morning of November 4th to host a workshop and book signing.

Read more here

Blog Archive