Working methods
Examine work and test a change
Use these steps and worksheets in your own work. All worked examples are fictional. Before changing an operation, confirm authority, information-handling requirements, and the conditions that apply in that setting.
Examine a handover
Use this when work waits for information, clarification, or approval between people. Begin with a few recent instances that the people involved can describe accurately.
- Record what happened.
Choose three recent handovers of the same kind. Record when the work was ready, when it was passed on, when the recipient could begin, and when it was completed. Include returns for clarification.
- Ask both people.
Ask the sender what they believed was complete. Ask the recipient what they needed to proceed. Record the missing information or decision in their own terms. Check whether the same issue occurred in each instance.
- Locate responsibility.
Identify who supplies the information, who makes the decision, and who can approve a change. Account for privacy, safety, contractual, and operational requirements.
- Choose one change.
Agree a change small enough to reverse, such as adding a required reference to a handover note. Record the expected effect, trial period, who will maintain it, and the conditions for stopping.
- Try it in actual work.
Use the change on a small agreed set of handovers. Record waiting, clarification requests, completion, and the extra effort required from each person. Keep sensitive content in its authorized location.
- Decide from the observations.
Review the trial with both people. Compare similar work and account for changes in volume or difficulty. Keep, revise, or remove the change. Record the reason and who owns the next step.
Worked example · fictional
Fictional example: a team passes purchase requests to an approver. Three requests waited for clarification because a project reference was missing. The team agrees to include that reference in five subsequent requests.
The reference is present in all five. One request still waits because the approver is unavailable. The team keeps the reference field and separately examines approval coverage. These observations identify two issues; they do not establish a general reduction in processing time.
Reasoning
All three requests lacked a reference the recipient needed. The trial checks whether supplying it reduces clarification. Approver availability remains a separate possible cause of delay. Record clarification time and total processing time.
Check the result
Check whether the intended recipient could act, whether work was actually completed, and whether effort moved to another person. Pause if the change creates errors, exposes information, or exceeds the agreed scope. A short trial may require repetition before it supports a lasting decision.
Try the reasoning on another instance
Ask a colleague to apply the worksheet to another safe instance and explain their decision. Record what they found unclear and when they would ask for help.
Worksheet fields
- Work and trigger
- Recent instances and dates
- Sender and recipient
- Ready / received / actionable / completed times
- Missing information or decision
- Decision owner and permission
- Proposed change and expected effect
- Trial size, review date, and stop conditions
- Observed result and additional effort
- Decision, owner, and next review
- Explanation being tested
- Other possible explanation
- Observation that would change the decision
- What another person needed to use this method
Test a working document
Use this for a procedure, shared reference, or recurring report. Test it against a real task with someone who would normally use it.
- Choose a task.
State what the reader needs to do or decide. Select a recent or safely simulated instance. Identify the source material and any information that must remain restricted.
- Find the required information.
List what the reader needs at each step. Mark which facts change, where authoritative values come from, and who can answer unresolved questions.
- Prepare a usable version.
Put the task, inputs, steps, decision points, and expected output in order. Identify the owner, version date, and update trigger. Link to authoritative information when copying it would create inconsistent versions.
- Observe someone using it.
Ask a colleague to carry out the task using the document. Record where they search, pause, ask for clarification, or choose the wrong action. Obtain consent for observation and any recording.
- Revise the specific problem.
Change the wording, ordering, or reference that caused difficulty. Repeat the affected part of the task. Check whether the revision creates a new ambiguity elsewhere.
- Assign upkeep.
Agree where the document lives, who maintains it, and what prompts a review. Make the current version easy to identify. Recheck it when the work, system, or decision authority changes.
Worked example · fictional
Fictional example: a stock-count sheet asks for “quantity” without identifying the unit. One person enters individual items and another enters boxes.
The revised sheet names the unit and includes one filled example. Two colleagues use it on a small count and compare their entries with the stock record. A later packaging change becomes a trigger to review the sheet.
Reasoning
A unit label addresses the ambiguity observed in the entries. The retest checks whether another person records the same stock consistently. If errors continue, check packaging conversions and the clarity of the example before adding further instructions.
Check the result
Check whether a reader can complete the task accurately, locate the current version, and recognize when they need help. Record unresolved cases. Keep safeguards and required approvals visible. One successful use provides evidence for that task and reader.
Try the reasoning on another instance
Ask a colleague to apply the worksheet to another safe instance and explain their decision. Record what they found unclear and when they would ask for help.
Worksheet fields
- Task and intended reader
- Required inputs and authoritative sources
- Access restrictions
- Steps and decision points
- Expected output
- Owner, date, location, and update trigger
- Observed pauses, questions, and errors
- Revision and retest result
- Remaining questions and next review
- Explanation being tested
- Other possible explanation
- Observation that would change the decision
- What another person needed to use this method
Assess a small tool
Use this before committing to automation, a spreadsheet, or a small application. The assessment should include the work required to operate and maintain it.
- Measure the current task.
Observe several instances. Record frequency, time spent, errors, and consequences. Note differences in difficulty. Distinguish measured values from estimates.
- Examine existing options.
Check whether an existing tool, template, or process adjustment addresses the difficulty. Identify duplication, access constraints, and required integrations.
- Define a bounded trial.
State the task the tool would support, its users, inputs, outputs, and expected result. Identify an owner, a cost/time limit, a review date, and a rollback plan.
- Check the obligations.
Consider data access, accuracy, security, maintenance, support, and approval requirements. Use fictional or otherwise authorized data for early tests. Keep consequential actions under the appropriate human control.
- Try the smallest useful version.
Test with representative users and cases. Record usage, corrections, exceptions, and support effort alongside task performance. Preserve a working fallback during the trial.
- Make the continuation decision.
Compare the observed benefit with setup, training, maintenance, and support costs. Check whether people actually use the tool. Continue, revise, defer, or stop, with reasons recorded.
Worked example · fictional
Fictional example: a weekly report takes 30 minutes to prepare. A prototype is expected to reduce that to 10 minutes. Setup is estimated at four hours, before maintenance.
At 20 minutes saved per week, recovering four hours takes 12 weeks. If corrections require another 10 minutes each week, it takes 24 weeks. The team records actual times during the trial and checks the useful life of the report before investing further.
Reasoning
The recovery period depends on actual correction and support time, how often the report is used, and how long its format remains useful. Record those assumptions during the trial. Include the effort required for someone else to operate and maintain the tool.
Check the result
Check adoption, correctness, time saved, support demand, and who carries the remaining work. Keep estimated benefits labeled until measured. Stop or revise when the tool causes errors, needs more support than available, or no longer addresses the task.
Try the reasoning on another instance
Ask a colleague to apply the worksheet to another safe instance and explain their decision. Record what they found unclear and when they would ask for help.
Worksheet fields
- Task, users, and frequency
- Observed time / error / consequence baseline
- Measured values and estimates
- Existing options considered
- Inputs, outputs, access, and owner
- Trial scope, cost limit, and review date
- Expected result and stop conditions
- Fallback and maintenance responsibilities
- Usage, corrections, and support observed
- Continuation decision and reason
- Explanation being tested
- Other possible explanation
- Observation that would change the decision
- What another person needed to use this method
Examine an offer and its delivery
Use this to understand the work behind an offer and how people with a relevant need encounter it. Treat prices, demand and capacity as matters to verify in the setting.
- Describe the need and entry offer.
State what the recipient is trying to do, the initial work offered, and what they expect to receive. Check that understanding with the people involved.
- Map the whole delivery burden.
Record preparation, delivery, clarification, corrections, training, maintenance and support. Identify who carries each part and what was understood to be included.
- Trace how people reach it.
In existing permitted conversations, ask how people found the offer, what they understood, and what helped them assess it. Record the route and the need rather than assuming attention establishes demand.
- Make the commitment legible.
Write the scope, responsibilities, support limits, any charge, and a decision point. Additional work requires renewed agreement. Check rights, privacy and other applicable obligations.
- Run a bounded trial.
Agree a time/cost limit and a review date. Record actual use, recurring needs, delivery effort and follow-up. Keep estimates identified.
- Review continued provision.
Consider technical feasibility, full cost, available capacity, participant choice and the governing commitments. Record the reasons to continue, revise, defer or stop.
Worked example · fictional
Fictional example: an initial workflow review leads to further questions and revisions. The team has not yet separated the follow-up effort or the route by which people found the offer.
A trial description makes included clarification and separately agreed work explicit. The team records delivery, support and discovery paths, then reviews whether the recurring need and capacity support continuation. This example provides no price or demand forecast.
Check the result
Can another person explain the commitment, identify the costs and assumptions, trace the route to relevant inquiries, and say what would require renewed agreement or a pause?
Worksheet fields
- Recipient need and initial offer
- Expected deliverable and included work
- Preparation / delivery / correction / support effort
- Who carries each responsibility
- How people found and assessed the offer
- Observed use and recurring need
- Estimates still to verify
- Price or charge agreed, if any
- Time/cost limit and review date
- Rights, privacy, approval and pause conditions
- Decision and reason