Actions, Results, and Retained Learning: How a Task Can Build Organizational Capability

When a task goes well, a team often writes down the process, hoping to follow it next time. A while later, the document is still there. But when the same problem comes up, everyone starts looking for the person who handled it before.

What is missing?

I think we need to keep asking: Why did it work that time? Which practices are worth trying again? Can someone else use them? And who will come back to check after they have been used? When these pieces connect, the experience from one task has a chance to become a capability the organization can rely on.

“Actions, results, and retained learning” offer a useful line of thought. We need to select and test what is worth keeping. Once it is retained, someone must continue to maintain it.

1. Check what happened before deciding what to keep

After a task is finished, start by separating three things.

Actions describe what people actually did. Who took which steps, under what conditions, using which information and resources? How did they handle exceptions?

Results describe what changed. Did the output meet the requirements? Could the next stage proceed? How much time and money did it take? Which obligations remain unfinished? For work connected to customers and economic outcomes, we also need to return to the relevant business performance chain and check the related outcomes, from demand and closing a sale to fulfillment and payment collection.

Retained learning identifies what is worth carrying into the next task. It might be a clearer decision rule, a repeatable method, or a condition to avoid.

These three things are not interchangeable. A customer may accept a quotation because the need is urgent, the competitive conditions are favorable, or a relationship already exists. A person in charge may pull in extra resources at short notice to deliver on time. That does not, by itself, show that the existing process is reliable.

A failure can also leave useful lessons. Under certain supply conditions, the original delivery date cannot be promised. When particular information is missing, work should pause until it is confirmed. First establish the facts and retain the context in which the lesson applies. Do not rush to turn one explanation into a general conclusion.

If business performance falls short, first locate the problem in the business performance chain. Then decide which level of work needs to change. Adding a checklist or specifying more detailed steps is worth doing only when it addresses the actual problem.

2. Look at an experience in four states

To make practical judgments easier, I suggest recording an experience in the following four states. This is a method proposed in this article. The state names do not themselves establish that validation has taken place.

Moving from one state to the next requires new evidence. Uploading a document or holding a training session is not enough to record a capability as something the organization has acquired.

Watch one situation in particular. What is called a “method” may still depend heavily on the judgment of the original experienced person. During the trial, that person stands beside the user and keeps prompting them. The results look good. Once that person leaves, the work stalls again. In that case, make the necessary judgment explicit. Arrange training, supporting tools, or help with exceptions. Be clear about where experienced staff still need to step in.

Whether organizational capability has developed must be assessed in actual work. Records, processes, tools, and training provide support. We still need to test whether the team can keep completing tasks and handling exceptions under the agreed conditions.

Scroll sideways to explore, or open the full diagram.

Open full diagram ↗Download editable SVG ↓

3. Turn review findings into a practice people can try

“Communicate earlier next time” is hard to act on. How early? With whom? What needs to be confirmed? Who handles a disagreement? None of that has been made clear.

An experience worth testing should explain at least six things:

1. The problem and context: Which problem keeps recurring in which type of task? Which conditions would change the judgment?
2. Evidence and explanation: What has been recorded? What remains uncertain? Why might the proposed change help?
3. The proposed practice: What conditions must be met before starting? What exactly should people do and deliver? How will completion be judged?
4. Exceptions and limits: When should the practice not be followed as written? When should work pause, and who should handle the issue?
5. The trial plan: Who will try it, within what scope? Who will provide resources, and when will the results be reviewed?
6. What to observe: What improvement is expected? How will comparisons be made? Which additional costs and effects also need attention?

This does not need to become a long document. If the next person can understand it and try it, and the reviewer can trace the evidence, there is enough to begin.

The learning approach behind Plan–Do–Study–Act, or PDSA, is useful here. The Deming Institute's explanation emphasizes comparing actual results with predictions, then using what is learned to revise both the practice and the original explanation.[1] IHI's guidance goes further: start with a small, feasible trial, watch for unintended effects, and continue testing under different conditions. A trial can be stopped if the practice produces no improvement.[2]

These sources inform trial design. They do not prove that the method proposed here has been effective across different kinds of businesses. Each business still needs to decide what validation is appropriate for its work and the consequences of failure.

4. Try it with “confirm the supply lead time before quoting”

The following example is fictional. It illustrates how to use the method; it provides no performance data from an actual company.

An equipment service team submitted a proposal before the customer's deadline. Looking back, the team found that the final supply lead time had been secured through last-minute coordination by the person in charge. When sales prepared the quotation, they still had only an earlier indicative lead time from the supply partner.

The result of this task can be confirmed, but the practice remains open to question. If “ask the person in charge to coordinate” becomes a required step every time, that person becomes another point where work waits. Supply conditions may not allow the same outcome next time, either.

Start with a smaller improvement hypothesis. For custom orders that require a delivery commitment, confirming the supply conditions for that order before quoting—and recording the confirmation date, scope of validity, and unresolved issues—may reduce later changes to the delivery schedule.

Then make the trial arrangements clear.

Decide the basis of comparison before the trial starts. If order types, complexity, and supply conditions differ substantially, changes in results cannot all be attributed to the confirmation record. When business volume is low, a problem's temporary absence is not enough to declare the practice validated.

There is no universal number of successful attempts after which a practice can become standard. The wider its reach, and the harder the consequences of error are to reverse, the more thorough the checking and trials should be. Some conditions cannot safely be tested through live work. Historical tasks, simulated situations, or specialist review can be used first.

What this example aims to retain is a practice with defined limits that remains open to checking. Whether it improves sales or economic outcomes requires further observation alongside customer demand, pricing, competitive conditions, and other factors.

5. Decide what form to retain, based on the problem

Once trial results support the practice, decide how to retain it.

These distinctions are intended to make the material easier to use. Actual documents can be organized around business needs. A simple problem may require only a change to one instruction or form. Changes to authority and responsibility require the appropriate authorization. There is no need to turn every lesson into a governance arrangement.

Put adopted practices where people will actually use them: in the relevant standard operating procedure, or SOP; in the work manual for a value-contributing role; in training exercises; or in supporting tools. Users should know where to start and when to refer to the practice.

AI can help summarize records, compare versions, organize steps, and check for omissions. Facts, conditions of use, and adoption decisions still need checking by people who understand the work and hold the relevant responsibility. Content that needs to become an AI execution guide, or Skill, can be developed from a stable method. Its inputs, outputs, limits of use, and requirements for human acceptance checks should be explicit.

6. Maintain the current version, and allow it to be discontinued

Follow-up arrangements are easy to overlook once a method is adopted.

I suggest that each current method specify at least its scope, version and effective date, maintenance responsibility, the places where users access it during work, and the time or trigger for its next review. Changes in business conditions, recurring exceptions, or a clear rise in costs can all justify an earlier review.

A review can lead to three decisions.

Continue using it: Current evidence still supports use within the original scope. Keep a record of the review and set the next check.

Revise and test again: The problem still merits attention, but the conditions, steps, or handling of exceptions need adjustment. Mark the new version's trial scope first. Decide whether to adopt it after testing. During the transition, make clear which version applies to which tasks.

Stop using it: The practice has not produced the expected improvement, the additional costs are unacceptable, or the conditions for its use no longer exist. Remove it from the places where people access everyday instructions. State why and when it is being discontinued, and inform the affected roles. For work that must continue, provide an alternative method or an escalation path.

Retain old versions as needed for management and traceability. Archived copies should clearly show that they are no longer valid, so historical material is not mistaken for a current requirement. Existing commitments and obligations also need their own handover arrangements. Discontinuing a document does not make them disappear.

Scroll sideways to explore, or open the full diagram.

Open full diagram ↗Download editable SVG ↓

7. Who brings the learning back into everyday work?

Across the four ecosystems—resources, operations and management, customers, and capital—different roles may propose improvements on their own initiative or respond to actual needs. Who participates, and how, needs to be clear for the specific work.

The people doing and coordinating the work explain the actual steps, difficulties, and exceptions. Those receiving the output check whether they can use it in the next stage. Feedback from customers and partners helps reveal the effects outside the organization. A lean operations and management team is responsible for the relevant decisions, rules, resource arrangements, and coordination among value production, sales channels, and customer relationships. Where specialist knowledge is involved, arrange a review by the appropriate people.

The person responsible for maintenance can organize the material, follow up on trials, and drive updates. But one person cannot make every judgment on behalf of every role. If a change reduces internal work while increasing the forms customers must complete or the confirmations partners must provide, those effects belong in the review too.

Contributions can also be recorded: who identified the problem, supplied evidence, joined the trial, or completed an effective improvement. Where evaluation or entitlements are involved, use governance arrangements defined in advance for the actual business. A record of experience does not automatically create an entitlement, and it does not constitute a promise of returns.

In its 2002 review of NASA's lessons-learning arrangements, the U.S. GAO found that having procedures for collecting and sharing lessons did not ensure that those lessons were applied to later missions.[3] This was a historical review of a particular period. Its relevance here is the reminder to check the creation of a lessons repository separately from its actual use.

So, when checking retained learning, do more than count documents. Take a real task and ask: Did the user find the current practice? Did they understand when it applied? Could they finish the work? When an exception arose, did it feed back into maintenance and decision-making?

Start with one recurring problem whose effects are clear. Check the facts of the task, propose a bounded change, ask the right people to try it, then return to make a decision. Leave clear answers about what the next task can use, where human judgment is still needed, and which practices should be removed.

Sources

1. The W. Edwards Deming Institute: PDSA Cycle. Used to explain the relationship between predictions, observations, and revised explanations. The four states and six items to record are method proposals made in this article.
2. Institute for Healthcare Improvement: Testing Changes. A quality improvement resource. This article draws on its approach to small trials, testing under different conditions, and stopping trials that do not improve results.
3. U.S. GAO: NASA — Better Mechanisms Needed for Sharing Lessons Learned, GAO-02-195, January 30, 2002. Only the findings of this historical review are cited. The article does not describe NASA's current situation.

Further reading (optional)

1. What Can a Business Retain After a Transaction? (Chinese): Understanding the accumulation of relationships, coordination, and capability after a transaction.

2. How Can a Business Keep Its Content Consistent and Up to Date? (Chinese): Maintaining related materials after knowledge has been adopted.

Research note: This article develops the earlier research thread of “actions—results—retained learning.” It also draws on the arrangements for trials, feedback, iteration, and version maintenance in the SOP Mapping and Design Methodology to propose a method for practical testing. The example is fictional, and the diagrams show proposed mechanisms. No direct business validation data are yet available for the method proposed in this article.