A lot of internal knowledge problems look small until
  they start slowing people down. A new hire cannot
  find the current onboarding guide. A manager keeps
  explaining the same approval process. A team follows
  an old workflow because the updated version sits in a
  private document. Training exists, but people still
  complete the same task in four different ways.

For KM teams, that is the real work. The goal is not to keep adding pages to a knowledge base. The goal is to make knowledge easier to collect, easier to trust, and easier to use when someone is trying to get work done.

That takes more than tidy folders. It takes a working system for turning scattered expertise into clear documentation, useful training, and internal processes people can actually follow.

Start by collecting better source material

Weak documentation usually starts before the writing begins.

If the source material is thin, rushed, or scattered across messages, the finished guide will feel the same way. It may explain the basic steps but miss the exceptions. It may describe what happens, but not who owns each part. It may sound clear to the subject matter expert and still leave a new employee guessing.

KM teams can avoid a lot of rework by treating knowledge capture as a separate stage.

Instead of asking someone to "send over the process," ask for the pieces that make the process usable. A good intake should pull out the trigger, owner, tools, approvals, common mistakes, exceptions, and update cycle.

A simple capture brief might ask questions like these.

• What starts this process?
• Who owns the decision or final approval?
• What tools, files, forms, or templates are involved?
• Where do people usually get stuck?
• What changes when the case is unusual?
• How often does the workflow need review?

That kind of structure helps experts share what they know without dumping a messy document into the KM team's lap.

A tool like Content Snare can fit here when teams need a cleaner way to collect documents, answers, and internal inputs from different people. For KM work, the benefit is less about gathering files and more about reducing the loose, forgettable back and forth that makes documentation harder than it needs to be.

Write for the person using the process

Many internal documents are written from the expert's point of view. That is why they often feel accurate but hard to use. The person reading the guide may not know the system, the team language, or the reason behind each step. They may be under time pressure. They may be trying to complete the task for the first time while a customer, manager, or colleague waits for an answer.

That changes how the document should be written.

A useful process page should explain what the person is trying to do, when the process applies, what needs to happen first, and what a good result looks like. The writing should be plain enough for someone outside the team to follow, but not so shallow that experienced employees have to chase missing details.

Good KM documentation often works in layers. The first layer gives the quick path. The next layer explains the steps. A deeper layer covers exceptions, edge cases, and ownership.

That structure keeps the page readable. It also respects the fact that not every reader needs the same depth at the same moment.

Connect documentation with training

Training and documentation often live in separate systems. One team owns the knowledge base. Another owns courses. Another owns the process itself.

Employees do not care about those boundaries. They just need to learn the task and do it correctly.

KM teams can help by building documentation that is easy to reuse in training. A clear process overview can become part of onboarding. A checklist can become a practice exercise. A set of common mistakes can become a short refresher lesson after the first month on the job.

This matters for recurring training needs such as compliance updates, system rollouts, customer handoffs, quality checks, and manager onboarding. If the source documentation is clean, the training team is not rebuilding the same material from scratch every time.

For organizations running structured learning programs, training administration software can help manage the operational side of that work. Sessions still need scheduling. Participants need tracking. Reminders need to go out. Certificates, attendance, and completion records need a reliable home.

KM teams may not run those systems directly, but their content feeds them. When the knowledge base is current and written in reusable pieces, training becomes much easier to maintain.

Make processes easier to follow in the moment

A process can be documented and trained, then still fail in daily use.

That often happens because the guidance is too far away from the work. Someone learns a workflow during onboarding, then needs it again three weeks later inside a tool they barely remember. If the guide is long or hard to find, they may ask a coworker, guess, or build their own shortcut.

For software based workflows, written instructions are useful, but screenshots and interactive guidance can remove a lot of friction. People often need to see the action, not just read the step.

That is where Supademo can support internal process adoption. KM or enablement teams can create walkthroughs that show employees how to complete common workflows inside the tools they already use.

This works well for approval requests, CRM updates, reporting steps, customer handoffs, account setup, or any task where the screen matters. The best walkthroughs stay narrow. One task. One user need. One clear outcome.

A broad tour of an entire system rarely helps much. A short walkthrough that shows exactly how to submit a request or update a record is far more useful.

Keep ownership visible

Knowledge gets stale when nobody is clearly responsible for it.

A process changes, but the guide stays the same. A form gets replaced, but the old link remains live. A team adjusts its workflow, but the training still shows last year's version.

KM teams can reduce this by making ownership part of every major knowledge asset. Each process page should have a named owner, a review date, and a simple way for employees to flag a problem.

The owner does not always need to be the KM team. Often, the subject matter expert should own accuracy, while the KM team owns structure, publishing standards, and clarity.

That split works well. Experts keep the details honest. KM teams make sure the knowledge stays readable, findable, and consistent.

Review timing should match risk. A compliance workflow may need a quarterly check. A low risk reference page may only need review twice a year. A tool walkthrough should be checked whenever the software changes.

Watch how people actually use the knowledge

Publishing a page is not the end of the work. KM teams need to know whether the guidance is helping. Page views can offer clues, but they can also mislead. A heavily viewed page might be useful. It might also be so confusing that people keep coming back because they cannot get what they need the first time.

Better signals come from daily friction. Repeated questions. Slow onboarding. Missed steps. Search terms that lead nowhere. Training completion with the same mistakes still showing up afterward.

Those signals tell the KM team where the system needs attention. Maybe the answer exists but uses the wrong language. Maybe the process is documented but not connected to training. Maybe the guide is clear, but the workflow itself has too many awkward handoffs.

The strongest KM teams treat these signals as feedback, not failure.

Build the loop, then keep it moving

Good KM work has a rhythm. Teams collect knowledge from the people closest to the work. They turn it into clear documentation. They reuse it in training. They support adoption with guidance people can follow during real tasks. Then they refine the system based on questions, errors, and feedback.

That loop is what keeps internal knowledge alive.

For KM teams, the opportunity is practical. Help people find the right answer faster. Help new employees learn without drowning in scattered documents. Help process owners keep guidance current. Help the business stop relearning the same lessons every quarter.

A knowledge base can store information. A strong KM system helps people use it.

____________________

You probably remember someone like him: Tom, the senior policy expert who spent two decades at the institution. Tom remembered which decisions had been revisited three times before reaching their final form. Tom carried in his head the assumptions behind frameworks that now looked obvious but had been genuinely contested when they were designed.

Tom is "The Organisational Memory" :)

When he retired, the organisation held a warm farewell.Three months later, his former team faced a decision that depended on understanding why a key position had been taken eight years earlier. They found the approval. The minutes. The final document.They could not find the reasoning.It had retired with him.

‍The gap existing frameworks do not close
In a previous article, I introduced Structured Decision Continuity through the story of Sophia: every senior expert whose absence only becomes visible when the system that replaced her produces an answer that looks correct and is not.

The diagnosis is this: organisations do not fail because they lack knowledge. They fail because the continuity between their knowledge and their decisions is not governed.

SDC names that gap. At the centre of SDC sits the Control Layer, a practical model that examines whether the path from knowledge to decision is strong enough to survive over time.
‍

The Four Conditions
The Control Layer has four conditions. Each addresses a failure that senior professionals recognise but few organisations name explicitly

‍Validation
Was the knowledge behind this decision reliable and valid in context?

Validation ensures that information, analysis and expertise were sufficiently checked; not just accurate in isolation, but appropriate for the specific decision being made.

The failure mode is familiar: a recommendation sound in theory but built on data that no longer reflected organisational reality. Before closing any significant decision, one question is worth asking: what are we taking for granted that we have not actually tested.

‍Context
Will someone encountering this decision in three years understand the conditions that shaped it.

Context is the set of circumstances and constraints that existed at the moment a decision was made. It is why the decision made sense then; even if it looks different now.

Context is the component most commonly lost. It lives informally in the people who were present. When those people retire or move on, the context goes with them unless it has been deliberately preserved.‍

Alignment
Was this decision coherent with strategy and governance and is that coherence still visible?

The failure mode here is subtle. A decision can be fully aligned at the moment it is made and look disconnected two years later, not because it was wrong, but because the strategy moved and no one recorded what the decision was originally aligned to.‍

Traceability
Can someone follow the path from knowledge to decision and from decision to consequence?

This is the expert's failure. The decision was defended procedurally. But the reasoning left with the person who held it. Traceability ensures that reasoning does not have to leave when the expert does.‍

Four Questions Worth Asking

For any decision that will carry long-term consequences, four questions are enough:
- Was the knowledge behind this decision sufficiently checked?
- Is the context preserved?
- Is the alignment with governance and strategy visible?
- Can the path from knowledge to decision be followed later?

If the honest answer to any of these is uncertain, something is worth capturing before the people who hold the answer have moved on.‍

A Closing Thought

The expert who retired took something with him that no record system was designed to preserve. Not his knowledge; much of that existed in documents. What left with him was the reasoning that connected that knowledge to the decisions that had shaped the institution.

The SDC Control Layer does not prevent people from leaving. It ensures that when they do, the reasoning behind their most important decisions does not leave with them.

Structured Decision Continuity is a developing professional concept examining how organisations preserve the reasoning behind important decisions over time. This is the fourth article in a series contributed exclusively to the Knowledge Management Institute.

The views expressed in this article are my own and do not represent the position of my employer or any institution I am associated with.

_______________________

Every year, organizations invest millions of dollars in evaluations, research, monitoring systems, lessons learned exercises, and knowledge management platforms. Yet many continue to face implementation challenges that were clearly identified years earlier.

The problem is not a lack of knowledge.

The problem is the inability to consistently transform knowledge into action.

Over the past two decades, NGOs, governments, and development agencies have generated unprecedented volumes of information through evaluations, research, monitoring systems, operational reviews, and partnerships. Knowledge management systems have improved the way this information is collected, organized, and shared.

Yet access to knowledge alone does not guarantee better decisions or stronger results.

Beyond Knowledge Management

Knowledge management focuses on collecting, organizing, and sharing information. Organizational intelligence goes a step further. It is the ability to transform evidence, experience, and learning into decisions, adaptations, and actions that improve performance and results over time.

Many organizations measure success through knowledge production: evaluations completed, reports published, lessons learned documented, or knowledge products shared. However, knowledge accumulation is not the same as learning. An organization may know something because it has documented it. Learning occurs only when that knowledge influences future decisions and behaviors.

The issue is rarely a lack of evidence. Most institutions already possess more evaluations, research findings, and lessons learned than they effectively use. The real challenge is transforming available evidence into action.

What Evaluation Can Teach Us

Evaluation provides a useful illustration of this challenge.

Across sectors and organizations, evaluations frequently identify similar issues: weak stakeholder engagement, unrealistic assumptions, insufficient risk management, limited local ownership, weak coordination, or sustainability concerns.

Consider a project where an evaluation identifies weak adoption of agricultural practices because market access constraints were overlooked during project design. Three years later, another project encounters the same challenge despite similar lessons having been documented previously.

The lesson existed. The organization simply failed to apply it.

This raises an important question:

If organizations continue to identify the same lessons year after year, are they truly learning?

In many cases, evaluations reveal less about project performance than about an organization’s ability to absorb and apply knowledge over time. Organizational intelligence extends the value of evaluation by ensuring that evidence informs future decisions before similar problems occur.

From Knowledge to Organizational Intelligence

Organizational intelligence is not a new department or software platform. It is a way of using knowledge more effectively.

In practice, it involves systematically reviewing previous evaluations during project design, integrating external evidence into decision-making, identifying recurring patterns across projects, tracking whether recommendations are implemented, and monitoring how evidence influences strategic choices.

Organizations that make this shift move:

·      From lessons identified to lessons applied.

·      From information access to evidence-informed decisions.

·      From reporting results to improving results.

·      From knowledge production to knowledge utilization.

They are also better positioned to preserve institutional memory. Staff turnover, organizational restructuring, and fragmented systems often disconnect lessons from future decision-making, causing organizations to relearn what they already know.

Looking Beyond Internal Knowledge

Organizational intelligence also requires looking beyond internal knowledge.

Valuable lessons often exist in partner organizations, academic research, government data, professional networks, and previous interventions. Organizations that combine internal experience with external evidence are generally better equipped to challenge assumptions, identify risks, and strengthen decision-making.

The Role of AI

Artificial intelligence may accelerate this transformation.

While much attention focuses on AI’s ability to generate content, its greatest value may be helping organizations connect and synthesize knowledge that already exists but remains scattered across evaluations, reports, databases, research papers, and individual experiences.

AI can support literature reviews, evaluation synthesis, evidence discovery, and pattern recognition across large volumes of information. However, technology alone cannot create organizational intelligence. The greatest barriers to learning are often organizational behavior, incentives, leadership commitment, and culture rather than information availability.

From Information to Impact

Knowledge management remains essential, but the ultimate objective is not knowledge management itself.

The ultimate objective is evidence-informed impact.

Organizational intelligence serves as the bridge between information and impact, helping transform evidence into decisions, decisions into action, and action into improved outcomes.

Organizations must move beyond asking:

“What knowledge did we produce?”

and begin asking:

“What decisions, adaptations, and improvements were influenced by the knowledge we produced?”

In the end, organizational impact may depend less on how much knowledge institutions generate and more on whether they are willing and able to change because of what they know.

______________________________________

‍

Knowledge mapping is the practice of making your organisation’s collective intelligence visible. It is not about building a database. It is not about writing everything down. It is about creating a navigable map of who knows what, where critical resources live, and where the dangerous gaps are.

‍

‍

We can use a map of a mall or a city as an example. The map does not replace the city, a mall, or a shopping center — it helps you navigate them easily without getting lost, and find specific shops, restaurants, or entertainment zones. A knowledge map does not replace expertise — it helps you find it.

A good knowledge map tells you three things:

•        What do we know? (The domain taxonomy — your knowledge categories)

•        Who knows it? (The expert directory — your knowledge holders)

•        Where are the gaps? (The gap register — your risk picture)

Imagine your most experienced  Proposal Manager or Lead Engineer leaves next month. Could your team still deliver with the same efficacy and timelines, especially if the KT plan is not in place? Would you even know what knowledge they left with?

Most organisations have enormous amounts of knowledge — but it is invisible. It lives in people’s heads, scattered across files, buried in email threads. Knowledge mapping makes the invisible visible. It answers three questions:

•        What do we know as an organisation?

•        Who knows it?

•        Where are the dangerous gaps?

When knowledge is mapped well, your organisation can:

•        Find the right expert in minutes, not days

•        Onboard new staff faster with clear knowledge paths

•        Reduce the impact when someone leaves — the knowledge transfer plan is already written

•        Make better decisions because the right knowledge reaches the right person at the right time

The Knowledge Mapping process does not require a special tool or an AI. All you need is a clear process, a bit of time, and people willing to be honest about what they know.

Let’s discuss the six-step mapping process as well as the cost of not mapping your knowledge and experts in the next blog.

_________________________

There is a pattern that Knowledge Management professionals will recognise immediately, even if they rarely say it out loud.

An organisation completes a significant programme or navigates a difficult period. The lessons are captured. People reflect honestly on what went well, what did not, and what they would do differently. The output is documented and filed.
‍

Two years later, the organisation faces a remarkably similar situation. A comparable decision needs to be made. And the lessons from that earlier experience are nowhere in the room.

Not because they were lost. Not because the documentation was poor. But because no mechanism existed to bring them forward at the right moment.

The lesson was captured. The decision never knew it existed.

A familiar problem with an unfamiliar name

This is one of the most persistent frustrations in Knowledge Management. It has been described in many ways: the knowing-doing gap, the lessons-learned paradox, the problem of knowledge that exists but does not travel.

What it has rarely been given is a precise structural explanation.

Lessons learned and decision-making exist in separate organisational spaces. Lessons are captured at the end of an experience. Decisions are made at the beginning of a new one. Between those two moments, there is typically no structured mechanism that asks: what has this organisation already learned that is relevant to this decision?

That gap is where significant organisational value quietly disappears.

Why existing practices do not always close it

Lessons learned processes serve an important purpose. They create structured reflection. They make tacit knowledge visible. They produce documentation that, at its best, preserves genuine organisational intelligence.

But they were designed primarily as a capture mechanism, not as a decision-support mechanism. The assumption embedded in most approaches is that if the lesson exists somewhere accessible, it will find its way to the decisions that need it.

In practice, that assumption rarely holds.

Decision-makers under time pressure do not search repositories. Teams forming around a new initiative do not systematically review what similar teams learned before them. The knowledge exists. The connection to the decision point was never made.

A practical reorientation

What is missing is not better capture. It is a deliberate connection between the moment a lesson is captured and the moment a relevant decision is being made.

This requires two things most organisations do not systematically provide.

First, lessons should be captured in a way that makes them decision-relevant — not just as a record of what happened, but as a forward-looking note for whoever faces a similar situation next. A lesson that says "stakeholder engagement was difficult" is less useful than one that says "stakeholder alignment must be established before the governance submission, not after — this assumption cost six weeks."

Second, lessons should be actively brought to decision points rather than waiting to be found — connected to governance and decision-making processes where relevant knowledge should be surfaced, not as an optional step, but as a built-in part of how important decisions are prepared

What Structured Decision Continuity adds

Structured Decision Continuity is a developing professional concept examining how organisations preserve the reasoning, context and traceability behind important decisions over time.

In the context of lessons learned, it asks one specific and practical question: was this lesson captured in a way that will actually reach the next relevant decision?

This reframes lessons learned from a retrospective activity into a forward-looking one. The lesson is not complete when it is documented. It is complete when it is connected — when there is a visible path between what was learned and the decision where that learning should be used.

A closing reflection

The question worth asking about any significant lesson captured in your organisation is not only: is it stored somewhere?

It is: will it be in the room when the next relevant decision is made?

Structured Decision Continuity is a developing professional concept examining how organisations preserve the reasoning behind important decisions over time. This article is contributed exclusively to the Knowledge Management Institute.

Disclaimer: The views expressed in this article are my own and do not represent the position of my employer or any institution I am associated with.

___________________________