Revolutionising the productivity of the knowledge worker - 4, becoming lean and efficient

This week I have been blogging about the challenge of revolutionising the productivity of the knowledge worker; the challenge which Peter Drucker set for us.

The lean working environment for the manual
worker (image from greenhousecanada.com).
Does the working environment for the knowledge
worker look like this?

We have looked at the division of knowledge labour, the automation/augmentation of knowledge work, and the knowledge supply chain. Now we look at how to make the knowledge work-flow efficient.

When we look at how the productivity of the manual workers has been revolutionised, then the most recent advances come from lean production, lean working and the lean supply chain have all played their part. The Manufacturing Advisory Service (quoted here) claims a 25% increase in productivity through lean principles - a small increment compared to the difference made by division of labour, automation/augmentation and an effective supply chain, but still a significant factor in the continuous improvement of productivity. Lean is also a mindset - a relentless focus on adding value on behalf of the customer and removing waste effort and stock.

However a lean and efficient approach has not yet reached knowledge management. 

Certainly most organisations now apply a division of knowledge labour, all are applying automation/augmentation to knowledge work, and many have the concept of a knowledge supply chain, supplying knowledge (or insights, experiences etc) to the knowledge workers, at the time and place they need it, to the required standard and quality, in a deliberate and systematic manner.  

However our track record of delivering that knowledge in a lean and efficient way is poor, and there is little or no sign of a relentless focus on removing waste and adding value.  Metrics measure the completeness of the KM framework and its effectiveness, but rarely its efficiency. 

Knowledge bases are often full and clumsy to use, poorly structured and indexed, with duplicate, outdated or irrelevant material. Knowledge workers are often required to use multiple search engines or to visit multiple sites, social media streams are unfiltered and full of noise, knowledge is often synthesised, often unfindable, and usually is poorly tagged and labelled.

All of this makes knowledge seeking a massive chore, which it is easier to skip than undertake.

A lean approach to Knowledge Management would involve eliminating the 7 wastes, such as

• Over-production of knowledge, which then becomes noise in the system
• Waiting for knowledge, and a slow turnover speed of knowledge
• Unnecessary hand-off of knowledge, with unnecessary steps in the chain between knowledge supplier and knowledge user  
• Non-value added processing—doing more work than is necessary. We often see this in lesson-learning systems, where the work of sifting, sorting and synthesising multiple lessons or multiple search-hits has to be done by the knowledge user. 
• Unnecessary "motion" - the need to visit multiple databases, multiple knowledge bases, a separate CoP system etc 
• Excess knowledge inventory— frequently resulting from overproduction.
• Defective knowledge.

Lean KM is the last of the four components to drive knowledge worker productivity. Together these 4 components can be revolutionary.

If we can have a lean and efficient knowledge supply chain, using automation and augmentation to deliver high quality knowledge to knowledge workers in a divided system of knowledge work, then we will approach Peter Drucker's initial vision of a 50-fold increase in productivity of the knowledge workers.

Revolutionising the productivity of the knowledge worker - part 3, the knowledge supply chain

Over the last two days I have blogged about the challenge of revolutionising the productivity of the knowledge worker, which Peter Drucker set for us. We have looked at the division of knowledge labour, and the automation/augmentation of knowledge work. Today we look at the knowledge supply chain. 

Parts, by Andy Malmin, on Flickr

The productivity of the manual worker was revolutionised through the transformation from craftsman production to factory production. Work was divided and automated, and individuals took their part within a work chain, or production line. Partly finished work came to them automatically, together with the parts and tools they needed, they did their own tasks, added their own value, and passed the updated work on to the next person. 

This is the supply chain for manual workers, who make things; an organised mechanism for making sure that the components they need to do their job are ready at hand when needed. The supply chain can be an assembly line, or a more complex arrangement involving parts, suppliers and warehousing.

Knowledge workers, on the other hand, make decisions rather than things, and the raw material for knowledge workers is knowledge. 

Therefore in a world where knowledge work is divided (where we do not rely on experts who carry all the knowledge in their head) the knowledge worker needs partly finished knowledge to come to them automatically, together with the knowledge tools and additional knowledge they need, and when they have made their decisions and added their own value (often this is the innovation piece), then the updated work needs to be passed on to the next knowledge worker.

This is the vision of the organisation as a knowledge factory, or a knowledge assembly line, and for this to work, we need the knowledge supply chain.  Often the knowledge supply chain involves knowledge suppliers, and warehousing, just as a supply chain for parts. 

I have already blogged several times about the knowledge supply chain (see the relevant tab in the word cloud to the right). The knowledge supply chain is a new way of looking at an organisation of knowledge workers (predicted 20 years ago by Lord Browne of BP), and for ensuring that the correct knowledge reaches each knowledge worker, at the time and place they need it, to the required standard and quality, in a deliberate and systematic manner. Knowledge Management then becomes the supply chain for the knowledge worker; a parallel knowledge workstream that works alongside the project pr product workstream.

Few organisations have got this right. The service-desk sector, where providing correct knowledge (answers to customer questions) to the front line staff is a vital KM service, have models for providing knowledge to those who need it. Toyota have got it right (I believe). The Military, with its chains of accountability and with the supply of knowledge and information built into the Battle Rhythm, probably do it best. 

This vision of "Knowledge Management as a supply chain" requires a complete Knowledge Management Framework to be in place, with roles, processes, technologies and governance, with the sole purpose of supplying knowledge to the knowledge workers, to enable them to make the correct decisions.

In the next and final post of this series we look at the nature of this supply chain, and what it needs to become Lean.

4 roles for the KM team

I presented this Boston Square last week to talk about 4 styles of knowledge transfer. Here's how the KM team can help with each. 

The Boston Square looks at four modes of knowledge transfer within KM, differentiated by Push and Pull, and Documented/Undocumented knowledge.  Any balanced KM program will address all four, more or less equally. Any KM program that focuses only on one or two quadrants in unbalanced.

Here is how the KM team can ensure balance.

The Explicit Push quadrant, labelled Share, is where an organisation focuses on collecting and publishing codified or documented knowledge, thus creating knowledge collections. It is the "Collect" route described here. The KM team can help ensure collection of documented knowledge by:

• Training people in how to collect and document knowledge:
• Ensuring each project understands what knowledge products it should document:
• Embedding into the workstream knowledge-collection processes such as lesson learning;
• Providing facilitation for these processes, or training facilitators;
• Providing technology where knowledge can be collected, which is outside "project space" and visible to other projects or to the organisation as a whole (ie technology for the "knowledge workstream");
• Measuring whether the required knowledge products are being created, to the right standard;
• Promoting a culture of openness and honesty, and discouraging secrecy and knowledge hoarding.

The Explicit Pull quadrant, labelled Search, is where an organisation focuses on facilitating searching for documented knowledge. The KM team can help by;

• Ensuring the organisation has an enterprise search engine;
• Ensure there is someone in the organisation responsible for maintaining and tuning the search engine;
• Ensuring that there are roles in place for maintaining, curating and synthesising the stores of collected knowledge;
• Ensuring the knowledge stores are browsable as well as searchable;
• Ensuring there is a taxonomy and metadata system in use;
• Embedding into the workstream  processes that encourage and promote searching, such as knowledge gap analysis;
• Providing facilitation for these processes, or training facilitators;
• Measuring search, eg search queries, and the number of document downloads;
• Measuring whether the use of sought knowledge is aiding the business, and by how much;
• Promoting a culture of curiosity and Learner behaviours, and discouraging not-invented-here, "too busy to learn" and other Knower behaviours.

The Tacit Push quadrant, labelled Tell, is where an organisation focuses on storytelling and knowledge exchange.  The KM team can help by;

• Ensuring people and projects understand what knowledge they should talk about:
• Embedding into the workstream knowledge-presentation processes such as knowledge handover, knowledge exchange, knowledge café etc;
• Providing facilitation for these processes, or training facilitators;
• Providing blogging platforms for individuals and/or projects and communities of practice;
• Measuring whether the required knowledge presentations and discussions are happening;
• Measuring whether they are aiding the business, and by how much;
• Promoting a culture of openness and honesty, and discouraging secrecy and knowledge hoarding.

The Tacit Pull quadrant, labelled Ask, is where an organisation focuses on creating and satisfying a demand for knowledge. This is the "Connect" route described here. The KM team can help by;

• Ensuring people and projects have channels and mechanisms to ask questions;
• Ensuring, where appropriate, that communities of practice are set up for the main knowledge topics;
• Providing Q&A forums for communities of practice;
• Providing a "knowledge index"/"yellow pages"/"Expertise locator" system if appropriate;
• Embedding processes like Peer Assist into the workstream;
• Introducing knowledge discussion processes such as knowledge handover, knowledge exchange, knowledge café etc;
• Providing facilitation for these processes, or training facilitators;
• Measuring whether the required  discussions are happening;
• Measuring whether they are aiding the business, and by how much;
• Promoting a culture of curiosity and Learner behaviours, and discouraging not-invented-here, "too busy to learn" and other Knower behaviours.

Everyone will have their preferred quadrant in which they feel most comfortable, but the key for any KM program is that you need to address all four elements, as different knowledge needs to be transferred in different ways, and to focus on only one quadrant of the diagram is to miss 75% of the possibilities KM can deliver.

Use this lists here to check how balanced your KM program is.

5 ways to reconcile the revenue stream and the knowledge stream

There is often  conflict between creating revenue and creating knowledge. Both of these require time, resources and incentives, and so are often in conflict. The problem is that knowledge is the source of future revenue. 

Timesheet logo from wikimedia commons

Any piece of revenue-generating work can create knowledge as well. In parallel with the revenue workstream, we have a potential knowledge workstream, both of which add value.

Knowledge is a by-product of what we do - we learn about the processes we use, the products we create and the customers we serve. That knowledge can be captured, shared, reapplied, and can help us perform better in future.

However the capturing and sharing takes resource and time - time which could be spent generating further revenue now. Time capturing lessons, creating best practices, seeking for knowledge from others, asking and answering questions etc.


We see this conflict particularly in fee-earning industries such as the legal sector or consulting sector, where people need to write their time to specific current projects and clients. They are often given timewriting targets of a certain number of billable hours, thereby incentivising the revenue stream at the expense of the knowledge stream.  Any time spent on knowledge work (assuming knowledge work is non-billable) is time that cannot be written to a client, and therefore time seen as "lost" or falling outside the targets.  The firm makes more money in the short term, but suffers in the long term.

There are a few ways around this, even where you have a timewriting system.

1. You can remove the timewriting system, and manage by objectives and fixed fees instead. This is becoming more an more common in the legal world, although firms often still use timewriting to monitor internal costs.

2. You can include Knowledge Management activity within billable hours, so that documenting and sharing the lessons from a client project can be billed to that client. This will need to be agreed up front with clients, but is surely a reasonable request. If the client wishes to make use of the firm's knowledge, then it is reasonable to charge for knowledge work.

3. You can introduce a non-billable timewriting code specifically for KM activity, funded through a central pot of money. Knowledge work then becomes an overhead.

4. You can involve non-timewriting staff to do the bulk of the KM work, interviewing the senior staff to gain the knowledge, for example, or searching for relevany knowledge. Again, knowledge work is an overhead. This is an approach used in many law firms, where paralegals and library staff do much of the knowledge work. It is also increasingly used in consulting firms, where dedicated knowledge centres take care of much of the knowledge work.

5. You can use junior staff and trainees to do the bulk of the KM work, treating this as a development activity. This is my preferred option, as it not only resources the knowledge workstream, but also brings the junior staff up the learning curve at an accelerated rate, and creates a cadre of fee-earners who have experience of the value and power of KM.

If you are in a fee-earning organisation where billable hours are a target, and timewriting is a way of life, you need to find a way to recomcile the short-term pressure to earn fees, with the long term investment that knowledge management delivers
.

KM, GDPR and Chinese walls - how to avoid the problems.

Many organisations are concerned about the GDPR and internal confidentiality issues associated with making all documents public and searchable. But KM does not have to work like that.

Image from wikimedia commons

We often come across concerns of internal confidentiality, Chinese Walls, and now GDPR which can make people reluctant to share knowledge.

"We can't share our project files" they say; "they are full of client-confidential material, they contain details of individuals which must not be made public, and they could lead to conflicts of interest if they cross company boundaries".

However, as we have often pointed out on this blog, sharing project files is not the same as knowledge sharing. There are two sorts of deliverables from a project or a legal matter - the project/matter documents, and the knowledge deliverables, which are those outputs such as lessons learned and exemplar templates which go into the knowledge workstream.  Those knowledge deliverables contain knowledge about the internal processes and the specific subject matter, and should not need to contain anything particularly client-specific, nor should they need to contain details of individuals. They should be more generic, more sanitised, and more useful in terms of updating the corporate knowledge base as they are synthesised with the knowledge which already exists.

In a recent blog, Phil Ayton of Sysero supports this model of separate knowledge deliverables for the legal sector.

The second approach requires more effort than the “redacted bible” option (of sharing redacted project files) but adds more value to the knowledge database by reducing risk, increasing quality and reducing drafting costs on new matters. Instead of simply sanitising documents as they are moved into the knowledge database, firms can enhance them by adding drafting information and including optional clauses. Instead of having multiple examples of the same legal document, firms create a single document with information for multiple uses. As well as making the knowledge database smaller and easier to navigate, sanitising while enhancing the content during the migration process ensures that new matter documents are drafted at a consistently higher standard.

Let's avoid concerns about confidentiality and GDPR by keeping our project deliverables separate from our knowledge deliverables, and by developing a knowledge workstream of documents that are focused on guidance and on practice, and which do not contain specific client-related or individual-related content.

Or as Phil describes it; "a sanitised, managed repository of know-how"

Knowledge documents vs project documents

We have been having a discussion in Knoco about the differences between project document output, project knowledge output, and knowledge documents. Here is one way to look at the differences.

Every project produces documents as a result of the project workstream. However, as we know, the organisation also needs a knowledge workstream, which has a different set of documents; described in this blog post as "standard practices, designs and procedures, best practices, guidelines and good examples".

The main difference between the two types of documents is that the knowledge workstream documents are not tied to any one project, but have a life that covers multiple projects. The guidance pages in the Shell wiki, for example, collect knowledge from multiple projects, and are updated with new knowledge arising from each project. The pages in the Chrysler Electronic Book of Knowledge, to take a second example, record knowledge of car components built up from many models and makes of car, jeep and lorry, and have a lifespan way beyond that of a new car development project.

Project documents, on the other hand, mostly have a lifecycle tied only to that project.

There are however knowledge products from projects, which are those new bits of knowledge used to update the knowledge workstream documents. These may be lessons, observations, new practices, new "good examples" and templates etc. And sometimes the wiki or the best practice document will refer to individual project files as "a good example to copy". The two workstreams and the two types of document can be linked, but in general we can conclude as follows:

• The knowledge documents in the knowledge workstream apply to multiple projects
• The project documents in the project workstream refer only to that project.

What are the outputs of the KM workstream?

KM organisations need a Knowledge workstream as well as a Product/Project workstream. But what are the knowledge outputs?

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 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 these 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:

• Standard practices which experience has shown are the required way to work. 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.
• 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.
• 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". 
• More generic accumulated knowledge about specific tasks, materials, suppliers, customers, legal regimes, concepts etc.

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 iterms which can be stored as good practices and good options. The link between lessons and best practices is described here, and shows how the two workstreams operate together to gather and deliver knowledge to optimise results. 

What to do when knowledge is a core product deliverable

For some projects, knowledge is their most important deliverable, but how is that deliverable defined?

We are used to thinking of knowledge as an input for a project, but it is often an output as well. Projects can learn new things, and can create new knowledge for an organisation. Often we assume that this new knowledge will be transferred through the lesson learned system, but is that really enough?

Usually it isn't, and instead a different approach might be better.

Lessons are increments  of knowledge, usually identified after the event, at the end of an activity or a project stage. In an ideal world every lessons would be associated with an action, and each action would lead to the update of a best practice, a doctrine or a corporate standard. Lessons are usually captured in a team meeting such as a Retrospect.

However if a project is doing something new - something which has never been done before - then the standard lesson approach is insufficient. Rather than identifying and capturing the learning after the event, the organisation should identify the potential for learning at the start of the project, make sure resources are assigned to learning, and require the project to create a guideline, best practice or standard as a project deliverable. 

Imagine an organisational project to set up the company's first manufacturing facility in Asia - the first of many such plants in an expansion program. The project is expected to deliver a manufacturing plant with a certain production capability, and the success of the project will usually be measured by whether the plant is delivered on time, to quality and to budget. However the success of the program will be influenced by how much knowledge is passed from the first plant to the others, and the value of this knowledge may be higher than the value of the plant itself.

Therefore the project can be given a second deliverable - to create best practice guidance documents, doctrine or first-pass standards on topics such as

• Doing business in that particular Asian country
• How to negotiate the bureaucracy
• How to obtain permits
• How to construct the plant efficiently and effectively
• How to recruit a skilled workforce

and many other topics. These deliverables should be managed through the project KM plan, and reported to management the same as other deliverables.

This set of knowledge deliverables could be given its own resources and its own workstream, in order to make sure that the knowledge is captured. Without this focus on knowledge, it is quite possible to get to the end of the project and find that no knowledge has been captured at all. 

What organisation do you need to handle the knowledge workstream?

I have blogged before about the two simultaneous and overlapping workstreams in an organisation - the product workstream, and the knowledge workstream. But what is the organisation that delivers the knowledge workstream?

Any organisation that makes product, also makes knowledge about that product. Products are made through projects, projects have beginnings and ends, but the knowledge needs to be collected from each project and passed from one to the other. It is this knowledge, passed from one project to another, that allows old products to be improved and new products to be developed. As Michael Kennedy says about Toyota - 

"Product development is not about developing cars, its about developing knowledge about cars. Great cars will emerge from the interaction". 

Now Toyota has a whole organisation dedicated to delivering products. In their case, they have car factories; other organisations have factories making cellphones, or shavers, or chocolate, or (to stretch the definition of "factory") making legal products, or training courses, or advice to clients.

All of these production organisations are well developed, and focused on delivering product.

But what and where is the organisation focused on delivering knowledge?

If there is a well-defined "factory" producing product, and accountable for the product workstream, then there where is the well-defined "factory" producing knowledge, and accountable for the knowledge workstream?

Toyota have such a knowledge factory, and so do many of the world's leading Knowledge Management organisations. These "knowledge factories" generally consist of a framework something like this:

• Knowledge owners, accountable for specific areas of knowledge
• Communities of practice, acting as contributors to, and co-creators and users of, the knowledge
• A "Body of Knowledge" - accessible to all who need it; maintained, synthesised, collated and updated
• Learning from Experience systems, where new knowledge can be harvested from projects and used to update the body of knowledge
• Collaborative technologies which allow the body of knowledge to be maintained by the community
• Discussion technologies for the community
• Effective enterprise search
• Clear governance.

The point is, though, that is you have two parallel workstreams, you need two parallel organisations. You need a matrix of intersecting organisations - with one axis of the matrix being the project dimension, and the other being the knowledge dimension. 

If you try to create a knowledge workstream using the same organisation that creates products, you will run into difficulty. You need a knowledge organisation as well. 

What the product-based KM Framework at Bombardier Aerospace looks like

Here you can find an interesting presentation from Bombardier, the Aerospace company, which presents details of their KM Framework.

Image from wikimedia commons

Bombardier take a "Product" view of KM, and differentiate the Knowledge Workstream that runs orthogonal to the product workstream. They operate through Communities, but their communities are mostly related to aspects of product, rather than to practice areas, so are "Communities of Knowledge" rather than communities of practice.  

They mention the following 28 communities, of which only the last four are "practice" areas; the rest are either product components or engineering topics.

• Control Systems
• Propulsion
• Acoustics
• Reliability & Maintenance
• Thermodynamics
• Pneumatics
• Loads & Dynamics
• Electrical
• Avionics
• Electronic Equipment
• Electro Magnetic Comp
• Flight Deck Design
• Sciences of Flight
• System Simulation
• Stress
• Mass Properties
• Experimental
• Material and Processes
• Aircraft Structure
• Aircraft Interiors
• Airworthiness
• onfiguration Management
• Product Integration
• Aircraft Configuration
• Flight Test
• Project Management
• Program Management
• Business Process Mgmt

They mention the following roles as part of their framework

• Knowledge Owners 
• Knowledge Focal points
• Subject Matter Experts
• Community Members

And the following processes

• Knowledge capture sessions
• Internal conferences
• Peer reviews
• Decision and problem support
• Knowledge gap analysis

They have a technology base including

• Yellow Pages access to vetted experts, 
• A Knowledge base of key documents, lessons learned, knowledge briefs, projects, studies, etc.;

They have a governance system including

• A KM Governance body to ensure company wide accountability, strategic direction, priorities and budget allocations
• Guidelines, procedures and metrics to sustain customer centric K-creation, sharing and management, and to measure impact. 
• Incentivized employees to create / share knowledge – participative management, budgeted time, recognition mechanisms.

Bombardier therefore address the 4 legs on the KM table as part of a comprehensive KM Framework

Contact Knoco for help with designing your own organisational KM Framework

The output of the knowledge work stream

---

I blogged a while ago about the two parallel work streams in product development - the product work stream and the knowledge work stream.

A question came up last week - who defines the output for the knowledge work stream? The output from the product work stream is defined by the customer for the product - there are product specifications which meet the client requirements or the requirements of the market. But who defines the specs for the knowledge work stream?

The answer, of course, is simple, the knowledge customer (or the knowledge market) defines the specifications for the output from the knowledge work stream.

For a product going into service, the knowledge customers will be

• The manufacturing staff, who need to know how to build the thing
• The sales, service and support staff, who need to know the details of the product in order to sell it, to support the customers, and to service the product. They need to know the selling points, the functionality, and the as-built spec.
• Anyone in future who will make modifications to the product, who need to know the design rationale;  the choices made in design, why they were made, what the alternative choices were, and why they were rejected, what the core "don't mess with this" items are, and what the "options to improve" components are.
• Managers and teams of similar development projects, who want to know how to repeat the successes of this project, and avoid the pitfalls
• Owners of corporate process, who need to know if any modifications to those processes are needed
• Technical authorities and technical communities of practice, who need to know of any technological advances developed along the way, and what these may mean for future products.

You find the needs of these customers by asking them, or (if they are not yet identified) by predicting their needs as a sort of market research. The knowledge workstream, and the delivery of these results, are managed through the Knowledge Management Plan.