3 From strategy to action
throughout the business. This ‘ownership’ approach also offers real potential for building true organizational learning through the creation of case studies and collation of lessons learned, evangelizing the results, and helping others use and integrate that learning within new projects.
The lower level details of the knowledge management strat- egy will evolve as we progress through the stages, as greater clarity comes from more informed analysis. But what does a knowledge management strategy look like? Organizations differ in their interpretation of the word ‘strategy’ but the authors have tended to use roughly the following report format.
Management summary
䊉 Summarizes the findings: the drivers, audit results (what was
‘found’ in the organization, the status quo), the ‘vision’, top- level results from the analysis, and conclusions and recom- mendations. It is vital to keep this tight, and free of KM
‘jargon’ – it must be accessible to decision-makers who have not been party to the background thinking and work, but who nevertheless have budget authority. Recommendations must deliver on clear problems the organization knows it is facing – while the management summary is not the place for a full business case, a benefits-based approach to specifying recom- mendations is useful in putting the top-level programme in a business context. Unless organizational custom dictates more, we would keep this to one to three pages.
Method outline
䊉 When using a methodology such as the five-stage KM strategy framework, we have found it useful to describe the approach taken. It is also useful to briefly log the work done – workshops and interviews conducted, background research undertaken – and any assumptions or exclusions.
Analysis and conclusions
䊉 The ‘meat’ of the strategy. Precisely how this is structured depends on the shape of the organization – it can be done in a variety of ways to reflect the degree to which the organization is chopped up into business units (for example,
by market sector or technical specialism), or integrated (such as organizations structured around brands with key shared
‘group’ functions run at ‘group’ level).
Typical structures might be based on:
Knowledge types – Using categories from the introductory chapter such as the ‘six investigators’ (p. 21) or generic grouping such as product, process and customer knowledge (p. 30). Alternatively, there are some more advanced category analysis tools in Chapter 4.
Business issues– Analysis based on the key challenges facing the business (for example, ‘coping with regulation’, ‘imple- menting e-business’, ‘improving production efficiency’,
‘improving market penetration’, and so on. This can be a powerful way to show the possible impact on specific areas of the business, but risks becoming repetitious if different areas (as they are likely to) call on the same proposed central initiatives in areas such as IT infrastructure, training, and process re-engineering.
Levers and enablers – Using the knowledge management levers and enablers (Leadership, People, Process, Technology and Information) as the units of analysis. The difficulty with this is that while it makes sense from a KM point of view, this view of the business may not be familiar to key stakeholders.
Consequently, it may be better to mix this approach with one of the two others in order to arrive at an analysis intelligible to the wider organization.
Whatever the structure, this section focuses on looking behind the picture uncovered so far, examining how they move the organization towards vision, and understanding the future potential, and coming to some conclusion as to a suitable way forward.
A programme of action
Individual recommendations or proposals may accompany the various areas for analysis – but if we return to our original idea of strategy as some kind of purposeful allocation of resources in pursuit of specific goals, then the strategy must conclude with a specific plan of action – divided for our purposes into proposals
for action (accompanied by an outline benefits case) – and a prioritized programme plan.
The recommendations must describe three principal elements:
䊉 Business area – usually based on the categories from the analysis sections.
䊉 Business priority– which projects (or pilot initiatives) need to be done first.
䊉 Ownership – where responsibility for change lies within the organization.
Business area
Mirroring how the organization is structured, or some similar sensible groupings of the actions..
Business priority
The time dimension is an important one, affected by many different factors, for example there may be dependency on something being in place – such as the roll-out of an intranet portal. Alternatively, there may be an immovable business target (such as a merger or product launch) which needs to be supported by the particular initiative concerned.
Typical project categorizations are:
䊉 Quick win – a project that is perceived as quick (but not necessarily cheap) to implement but has potential to deliver visible benefits quickly – great for case studies.
䊉 Prerequisite – a dependency for later projects – for example, if a later project aims at developing communities of practice, the technical infrastructure needs to be in place first.
䊉 Pilot – various kinds of pilot exist, from proof of concept (where the final solution may look very different to what was piloted) through to a ‘test’ roll-out of a process or software product that it is already scheduled for large-scale deploy- ment. The ability of an organization to learn from pilots is a key knowledge management capability.
䊉 Main project – a mainstream programme element that contains a significant piece of work – may follow on from a pilot as a roll-out phase, for example.
䊉 Potential/optional – a project for which the business case, budget or stakeholder support is not assured, but which is shown on the programme as a recommended option.
Certain timeframe designations are also useful:
䊉 Milestone – an assumed decision point or anticipated project completion.
䊉 Short term (e.g. 1–6 months) – may fall into the same category as quick win.
䊉 Medium term (e.g. 6–18 months) – typically dependent on other factors (such as delivery of earlier projects or on future budget approval).
䊉 Long term (18 months +) – not necessarily well defined in terms of benefits case and certainly liable to change in detail.
Once the strategy has been formulated to an acceptable level then it is time to understand in greater detail the benefits that individual projects, or a programme, will bring: indeed, only once this is done will most organizations free up sufficient budget for the programme to commence.
3.1.2 The business case – clear benefits