Knowledge Management

“Knowledge Management” (or “KM”) still has some currency, for a ‘discipline’ that’s been around for some time now – still one of the best books on the topic is Tom Lloyd and Karl Erik Sveiby’s excellent 1987 book – ‘Managing Knowhow’ (tragically now out of print).

At NIP, we’ve had direct experience over a number of years, implementing what are now accepted as Knowledge Management solutions in key organisations.

In general, there are two approaches organisations can use to implement a KM solution: incremental, or transformational. The transformational approach offers the greater potential benefit, but it requires a great deal of commitment, and entails a higher (perceived) degree of risk than the incremental approach. As a result, most organisations are opting for the less radical incremental approach.

Either way, ‘chequebook’ advantage – paying out large sums of money in the hope of securing promised future gains, without having to commit serious amounts of thought and effort – isn’t the option it used to be (if ever it was).  Installing expensive ‘closed’ software solutions, and paying consultants to customise them, isn’t sufficient. Anyone seeking ways to secure real competitive advantage from their KM solutions will increasingly have to take direct responsibility for finding the most appropriate mix of tools, and techniques, to get the results they are looking for, instead of relying on “pre-packaged” solutions to do the job for them.

In our experience, a successful KM implementation needs to bring together aspects of both technology and people: an Open architecture (drawn from the technology space) needs to be integrated with the key roles (drawn from the human resources space) that individuals, groups and organisations naturally perform:

• The Leader – identifying what should be done
• The Manager – monitoring progress, identifying actions based on what should be done
• The Producer – doing what should be done
• The Enabler – supplying an environment that supports what should be done

Because of the all-embracing nature of KM, almost any supplier in the IT domain can claim to offer some aspect of the KM space….. however small their contribution really is. The (apparent) abundance of suppliers can be very confusing to those planning, or implementing a KM solution.

Encapsulating process knowledge, which is the foundation of knowledge middleware, is not an easy task, but our customers report that the investment pays handsome dividends. Encapsulating process knowledge in software frees up individuals, teams and organisations to concentrate on high value know-how related activities.

Over the years, we have learned some practical lessons from KM implementations:

1. Most accepted development methodologies are not adequate for Knowledge Management applications. Traditional methodology-driven development frameworks tend to assume that specification, design and development and installation are sequential processes. Encapsulating the business processes and business rules associated with knowledge-rich professional work, requires a more responsive, iterative approach.

2. Early, direct contact between developers and end users is essential. Typically, users find it very difficult to articulate the business processes and associated business rules when presented with a blank piece of paper.  Prototypes or ‘mock ups’ greatly build confidence by creating a shared space for developers and end users to work in (Protocylcling). As such, intermediaries need to demonstrate the added value contribution they bring to the process, before being involved ‘in the loop’.

3. For KM solutions, it is essential to consider the ‘whole’ business context in the early iterations of the system design. Uncovering the generic, reusable aspects of the application creates the foundations for systems that can evolve over time, as new rules and processes are uncovered and adapted.

4. Knowledge-driven application developments can ‘get lost in the detail’, so there’s a pressing need to maintain focus on the project vision, through regular calibration meetings with the project sponsor. Acceptable changes of course can be incorporated, and non value-adding diversions quickly addressed.