We first published this guide in 2024, and most of it still holds up. However, the route some organisations take to the question has changed. Some want to ensure their knowledge content is ready for a Copilot rollout or are looking at knowledge management retrospectively because the introduction of Copilot has exposed just how disorganised their knowledge is.
Organisations reach this point through different paths, but often it is because the business has grown faster than the SharePoint site holding its knowledge, or because twenty years of proposals and client work have built up with no sensible way to find any of it, and share what is truly valuable.
Before founding Content Formula in 2005, I spent six years running knowledge management at Johnson & Johnson. Working in-house made me appreciate that technology and the platform is never the starting point. Knowledge management and the related governance starts with people and ownership, and the processes that help to define what is good enough to reuse.
This guide sets out what a knowledge management strategy should contain, the choices that shape it, the eight steps to create one, and why some strategies stall once they have been approved.
In summary
A knowledge management strategy is a written plan that sets out what an organisation wants to achieve with its knowledge over a defined period, and what has to be done to make that happen. It usually covers a mission and principles, scope, the evidence behind the priorities, an executive sponsor and funding, a named owner for each knowledge area, a roadmap, measures agreed up front, and how the strategy will be governed once approved.
What is a knowledge management strategy, and how is it different from a system?
A knowledge management strategy is a plan, with an accompanying roadmap, that states what an organisation wants to achieve around using and getting value from its knowledge over a particular period. It also covers what needs to be done to make it happen.
A strategy is not the same thing as a knowledge management system or ecosystem. The system is the platform, the processes running on it and the governance that underpins it – the libraries, the search, the review workflow, the roles and structures. The strategy is the plan that defines what you want to achieve with the KM system, and how to make that operational. This means a strategy could involve setting up the KM system or evolving it; in practice it also details some of the essential governance such as which knowledge matters, who owns it, what standards it has to meet and what gets done first.
The essential point is that you shouldn’t set up a knowledge system without a strategy in place. When the system comes first, the strategy can end up being written afterwards to explain decisions that have already been made, which leaves much less room to change them. It also means your system might not be able to execute your strategy successfully.
What should a knowledge management strategy contain?
There is no single template for a KM strategy, although you may use a standard strategy template within your organisation. What you include may also differ depending on your organisation, your situation and so on. However, the strategies we see often have the following elements, all of which are important to include in our view.
A mission or vision
What you hope to achieve through the knowledge management strategy, encapsulated in one or two sentences that also captures the “why” as much as the “what”, and which a busy executive could repeat without notes.
Guiding principles
The central pillars or tenets of the strategy indicate the key elements of what you’re going to do. For example, one of these might be to refresh a knowledge system, and another might be to apply governance across knowledge currently stored in SharePoint. A strategy might have between five and eight guiding principles, although there are no hard and fast rules about this.
Scope
Which parts of the business, which processes and which knowledge areas are covered, and which are not. This might also cover the technologies in scope if knowledge is spread across different systems. It is also the place to be clear about what knowledge management is not. Records management, for example, is about retention and covers what has to be kept and how long for while knowledge management is more about reuse.
Evidence
Any relevant findings from user research or a knowledge audit that support and justify the priorities within the KM strategy. Without it, priorities tend to reflect whoever spoke loudest in the workshops and may not land so strongly with stakeholders because they lack credibility.
An executive sponsor and funding
Stakeholders are unlikely to approve a strategy without knowing who is backing it at a senior level. Unless you still need to make a business case, the strategy should also detail where the money for delivery will come from. Naming the owner and funding early also tells you whether the scope is realistic and makes it more likely to attract support from stakeholders as the strategy will feel more achievable.
Roles and ownership
A named owner for each knowledge area, who sits in that part of the business, plus clarity on who reviews, who approves and who decides when something is arguable. IT supports the platform, permissions, and integration, but it can’t judge whether a piece of work is accurate or safe to reuse.
A high-level roadmap
The work sequenced to reflect your priorities and any dependencies between them, with milestones that the people responsible have agreed to. The roadmap does not need to be fully fleshed out but should be detailed enough to provide a basis for project planning.
Success criteria and related measurement
The criteria for the success of the strategy and the numbers that will indicate if these have been achieved. Measurement is not always straightforward as some of the benefits of a KM strategy are subtle and intangible, but there will invariably be some analytics that will help you track progress. Reuse of material and time to answer are usually more telling than the number of documents in a library, and the measures need agreeing before the work starts, because most of them need a baseline that can’t be reconstructed afterwards.
Technology, processes and change
The strategy will need detail to cover areas such as what needs configuring or building, what processes need designing, where people will need to work differently, and how the change will be managed.
Strategy ownership and change
The strategy should include details of who maintains it once it is signed off, how often it is reviewed, and how changes to scope or priorities are agreed.
How is AI impacting knowledge management?
Knowledge management has always been more prominent in sectors such as professional services and pharmaceuticals but is regarded as less important in others. However, the advent of AI has thrust KM back into the limelight again and arguably it is growing in importance across more organisations.
KM helps to establish trusted, insightful, and valuable content that supports strong AI responses and reduces the chance of AI misinformation. Moreover, taxonomy and ontology management, which is often carried out by KM teams, also support better AI search as well as AI-generated answers.
What is a good knowledge management framework to use?
There is no single standard framework, although ISO 30401 provides a formal reference point by treating knowledge management as a management system that has to be established, maintained and improved, rather than delivered once.
A very common framework used across the KM community and beyond is to consider KM across three elements: people, process and technology. Frameworks from KM bodies such as APQC tend to be variations on these three elements but also sometimes add content and culture as separate elements, although the latter has some overlap with people.
Adding “content” as an element, here’s what a four-element knowledge framework covers:
| Element | What is covers | What to check for in your strategy |
|---|---|---|
| People | Who holds the knowledge, and the skills, behaviours and change management that decide whether they share it | Is change management planned and funded and how is a culture of knowledge sharing encouraged? |
| Process | Capture triggers, review cycles, approval routes and retirement rules | Is knowledge capture built into core work processes, rather than added as a separate task? |
| Content | What gets kept and the standards that it should meet | Is there a written curation standard for each knowledge area? |
| Technology | The platforms that capture, hold, surface and maintain knowledge | Have the requirements been agreed before a tool is chosen? |
How do you create a knowledge management strategy?
You create a knowledge management strategy by agreeing the scope and approval route, researching how people actually use knowledge, auditing what already exists, and then drafting, validating and approving the strategy with the people who will deliver it. There is no standard methodology, but the eight steps below give a sound basis, and several of them can run at the same time.
1. Decide the scope
A knowledge strategy can cover a single practice area or an entire organisation, and the difference in effort is considerable. Agree the scope up front. Which areas of the business, which core processes and which likely technologies are covered? Expect any user research to move the boundary. This is normal, and it is much easier to adjust now than at the roadmap stage. It is also fine to put things explicitly out of scope for a first phase, as long as the strategy says so and records when they will be revisited.
2. Agree the sponsor, stakeholders and approval route
Based on the scope, decide who needs to give input, who the executive sponsor is, and who signs the strategy off. Confirm the review and approval process at this point too and ideally a timetable for completing the strategy. If nobody has agreed how the strategy will be approved by the time the final draft is ready, it can sit waiting for a decision for a long time.
3. Carry out user and stakeholder research
A knowledge management strategy shouldn’t be built on assumptions about how people work. Use interviews, workshops, observations, and surveys to understand where knowledge is created, where it gets stuck, what people do when they can’t find something, and where priorities differ between functions.
When we ran a knowledge management discovery for FI Consulting, a US-based consultancy, the firm had twenty years of proposals, client materials and governance documents already sitting in Microsoft 365. The problem wasn’t a lack of content or software. There was no shared logic for which assets were useful and could be reused. One of the key issues was nobody knew where anything should go, so people struggled to find what even existed. The research helped define a set of decisions and a framework to act upon.
Different functions will often want different things from knowledge management. Capturing those differences at this stage is what allows you to build consensus later, rather than discovering them in the middle of delivery when it might be too late to make changes.
4. Run a knowledge audit and related workshops
Alongside the research, run a knowledge audit of what already exists – the tools in use, the repositories people actually rely on, the knowledge assets that matter and the processes around them. The audit can influence some key decisions.
In parallel to the audit, there may be some additional and related workshops to run to define some of the details such as the taxonomy. Sometimes it is beneficial to run these prior to the formation of the strategy; sometimes it’s part of the implementation project to execute the strategy.
For FI Consulting, a dedicated taxonomy workshop defined the taxonomy the platform would need, and the logic for automated tagging, before any development started. We make the same recommendation on most projects that involve search: define the search model and the taxonomy before implementation, because changing them once content has been tagged is far more work. The design of that structure is a piece of information architecture work in its own right, but the strategy needs to establish the need to create it and who will own it.
5. Define the mission and principles
With the research and audit in hand, set the high-level mission and the guiding principles that sit beneath it. Keep the principles few (not more than eight) and consider each one in a real-world scenario. If it doesn’t feel right, it probably needs to be rewritten.
6. Validate with stakeholders
Take the emerging strategy back to the people who contributed. This is usually where scope of questions and ownership disputes come to the surface, and resolving them now, with the people affected in the room, is how the strategy gains the agreement it will need during delivery. A workshop with your key stakeholders can help achieve this.
7. Complete the detail and build the roadmap
Finish the strategy and sequence of the work to reflect your priorities and dependencies. Include the roles and resources needed to deliver it, with named owners for each knowledge area and a realistic view of the time those owners will need to give it. These estimates could be a precursor to a business case.
8. Seek final approval
Take the strategy through the approval route agreed at step two. Consensus and sign-off matters as it reduces the chances of stakeholders going off and doing their thing and for the strategy to succeed. A strategy that leadership has visibly backed is much easier to hold to when a function’s own priorities pull in a different direction.
Why do knowledge management strategies stall after sign-off?
Lack of resourcing
Strategies that stall after approval usually do so because the delivery phase wasn’t properly resourced, and there wasn’t a budget. A KM initiative will quickly lose momentum if there is no stewardship.Nobody owns the structure after launch
Someone also must look after the foundations. A taxonomy is designed once but maintained for as long as the platform is in use. On knowledge platforms we have supported for several years, taxonomy questions still come up in regular account calls – a category list appearing inside another in search, for example, or a new service line that doesn’t fit the existing terms. If the strategy names a designer for the taxonomy but no owner for its upkeep, those questions have nowhere to go.Review cycles fall between the cracks
A knowledge library is built, populated once, and then the content is never reviewed. People access content, find something several years out of date, and stop trusting it. Review frequencies and retirement rules are critical to keeping a knowledge platform up to date, but they only work when the time to carry them out is part of somebody’s role.Deferred decisions come back
Putting something out of scope for phase one is often the right call. However, if the strategy doesn’t record when it will be revisited, the same question tends to return later as a complaint rather than a planned piece of work.Contribution depends on goodwill
Knowledge capture relies on the cooperation of the subject. This is encapsulated in Dave Snowden’s first principle of knowledge management:"Knowledge can only be volunteered; it cannot be conscripted."
This is why the strategy should say how knowledge contributions will be recognised and how a culture of knowledge sharing will be encouraged.
Knowledge capture is not a set process
Knowledge capture also works best when it is part of a set process, otherwise it gets forgotten about or deprioritised. In projects, for example, knowledge capture often works best as part of the formal project review or closure process.
The strategy itself is never revisited
Organisations change, and a strategy that is two years old can be describing priorities that no longer exist. Building a review point into the governance section, even an annual one, keeps it useful.
“Successful KM is often a slow burn because it relies on people and involves behavioural change so it can take time to see results. At the same time AI is shifting priorities for KM and driving an urgent need to get content in shape to work with Copilot and LLMs. With both those factors in play, it is essential that a strategy is continually revisited to meet changing priorities, but also to keep up momentum so it has sufficient time to deliver value.”
Where the strategy stops and delivery starts
A strategy is a set of decisions and a plan. It is not a project or a build. Once it is approved, organisations usually take one or more of three routes depending on the scope: they use the strategy to make a business case, they implement it with their own team, or they take the specification to market.
FI Consulting is a good example of the second and third routes working as intended. The firm took elements of the strategy – the taxonomy, information architecture and wireframes produced in the discovery – and implemented its new site with another supplier. Its CEO, Roman Iwachiw, still described the discovery as “an outstanding professional services experience”.
The question of which technology to use tends to be simpler than people expect, particularly for organisations already on Microsoft 365. We have written separately about what knowledge management looks like on SharePoint, with examples covering expertise location, curated collections and capture at the end of a project. And if AI is part of the plan, the foundations a knowledge management strategy produces – consistent metadata, vetted content and clear rules on what is in scope – are critical for how useful Copilot will be.
Frequently asked questions
What should a knowledge management strategy include?
A knowledge management strategy should include a mission and guiding principles, a clear scope covering which parts of the business and which knowledge areas are in and out, the research and audit evidence behind the priorities, an executive sponsor and funding, a named owner for each knowledge area, a roadmap that reflects priorities and dependencies, measures agreed before the work starts to track success, and how the strategy will be governed and reviewed once approved.
Who should own a knowledge management strategy?
The business should own it with IT support. More specifically, if you have a knowledge team, then they will be the likely owners within the business. An executive sponsor backs the strategy as a whole, and each knowledge area or topic needs a named owner who sits in that part of the business and can judge whether content is accurate and safe to reuse. IT is responsible for the platform, permissions, and integration. Ownership of the strategy itself, including when it is reviewed, should be included within the strategy.
How often should a knowledge management strategy be reviewed?
At least once a year, and whenever the organisation’s priorities change significantly, for example after a merger, a restructure or a major platform decision.
Dan Hawtrey
Dan Hawtrey is CEO of Content Formula, which he founded in 2005. Before that he spent six years as knowledge management manager at Johnson & Johnson. Since then, he has helped large organisations, particularly in financial services, healthcare, education and manufacturing, build knowledge, intranet and compliance solutions on Microsoft 365.
