Keith’s Training Hub

PRACTICAL WORKSHOP · 50 MINUTES

Fix a pensions admin process

A practical workflow workshop, not a quiz

Follow one fictional case from arrival to completion, separate working time from waiting, and redesign the hand-offs. Leave with a simpler workflow and a small improvement plan.

No quizzes, scores or assessed completion. Work on paper or in an approved blank Word document. This page does not collect or save your notes or track workshop progress.

Use fictional information only. Do not enter real member, customer or payroll data, passwords or confidential files into this course or external AI tools.

Before you begin: safety and scope

Use only the fictional examples provided. Do not enter real member, beneficiary, employee or payroll data, National Insurance numbers, bank details, health information, credentials or confidential organisational information in this course, its exercises, AI tools or shared training files. A changed name does not make real data safe. This is service-design training, not personal financial, legal or pension-benefit advice.

This is process-improvement training in a fictional pensions setting. It does not set scheme rules, statutory deadlines or pension-benefit instructions. For real LGPS (NI) work, confirm current NI requirements and approved scheme processes; do not substitute England and Wales arrangements.

  • Spend about 50 minutes across six short modules. Use a blank document or paper; drawing software is optional.
  • Read each Scenario, Example and Your task separately. Build the outputs into the final templates.
  • All figures, timings, roles and targets are fictional training assumptions, not scheme standards.
  • The workflow is a proposal for discussion, not authority to change a real service or use live data.
  • Copilot is optional. Copy only synthetic course material and review the draft yourself; the workshop also works without AI.
  • Optional Copilot assistance: check your signed-in account, licence and employer’s approval. Microsoft supports some personal Premium use with work documents under administrator controls, but features vary. This course uses synthetic material only, regardless of licence. Never paste real member data or connect organisational sources for these exercises. Review outputs yourself.
Start the workshop

Harbour’s fictional employer-submission process

Harbour is an invented pensions administration team. It receives a fictional employer status-change file from Cedar. No names, salaries, identifiers or live scheme records are needed. This is not an account of NILGOSC or any actual employer.

  • Case H-01 arrives at 09:00 on fictional day 1. Logging takes 10 minutes, followed by 90 minutes waiting for an owner.
  • Validation takes 15 minutes. Missing information creates a 180-minute wait for a response.
  • After information arrives, correction review takes 20 minutes. The case waits 120 minutes for a second check.
  • The second check takes 15 minutes. Acknowledgement and status recording take 10 minutes.
  • The teaching timeline uses continuous measured minutes only, without nights or weekends: 70 minutes of handling plus 390 minutes waiting gives 460 minutes elapsed.
  • Harbour receives both complete and incomplete files. It needs a safe exception route and must not guess missing values to improve turnaround.

MODULE 1 OF 6 · 7 MINUTES

1. Choose one process and define “done”

You will: Define the trigger, end point and scope. State a service outcome with safeguards.

Scenario

You are helping Harbour’s employer liaison lead improve status-change submissions from Cedar. Colleagues disagree about whether a case is finished when it is received or when it has passed checks. Your task is to agree a clear start and finish without expanding into benefit calculations or payments.

Example

A useful boundary

Start: a fictional submission reaches the approved intake point. End: checks and acceptance are recorded, or a documented exception has an owner and next action. In scope: receipt, assignment, checks, queries and status. Out of scope: calculating benefits, changing member records, payments and sending real messages. An exception is not labelled a successful completion.

Takeaway: Decide what counts as complete before measuring speed.

Your task

  1. Write the start and finish for Harbour’s submission process.
  2. List four in-scope actions and two exclusions.
  3. Name a fictional process owner.
  4. Add a confidentiality, integrity and availability requirement.

Your output: A short process charter.

Working-note template
Process: ___
Trigger: ___
Successful completion evidence: ___
Unresolved exception status: ___
Owner: ___
Scope / exclusions: ___
C / I / A requirements: ___

Reflect: Would two colleagues classify the same incomplete case the same way?

Read the lesson: why this matters

A process is a repeatable route from a trigger to an outcome. “Improve pensions administration” is too wide to map usefully. “Handle one employer status-change submission from receipt to validated acceptance or a recorded exception” gives you a workable boundary.

Define done using evidence, not a vague activity. Reading a file does not prove it was accepted. A completed validation record and an authorised status update are observable. An incomplete case stays visibly unresolved until the approved next step has happened.

Name the process owner and the people using the result. Include confidentiality (who can see it), integrity (what proves it is correct) and availability (how work continues if the usual person is absent). These are requirements for the design, not optional extras.

Sources for this module

    MODULE 2 OF 6 · 9 MINUTES

    2. Map the actual journey

    You will: Map activities, decisions and hand-offs. Separate handling time from elapsed time.

    Scenario

    You are sitting with an administrator and a reviewer to follow fictional case H-01. The written procedure contains only the main activities, but the case spends most of its time waiting between them. Your goal is to record the real sequence, including queues and rework, rather than draw an ideal process.

    Example

    H-01 in plain text

    Receive/log [10] → wait for owner [90] → validate [15] → wait for missing information [180] → review correction [20] → wait for checker [120] → second check [15] → record status [10]. Handling = 70 minutes. Waiting = 390 minutes. Total = 460 minutes. The waiting share is 390/460, approximately 84.8%, but one fictional case does not establish a normal service average.

    Takeaway: A slow journey can contain short individual tasks.

    Your task

    1. Copy the H-01 sequence and label each activity with its owner.
    2. Mark the three waits and the missing-information loop.
    3. Check the handling, waiting and total calculations.
    4. Identify one detail you would need before treating this as a typical case.

    Your output: A current-state map with time and ownership.

    Working-note template
    Step | Role | Input | Action or decision | Output | Handling minutes | Wait minutes
___
Handling total: ___
Waiting total: ___
Elapsed total and clock definition: ___
Limitations: ___

    Reflect: Which wait would remain even if every task were performed twice as fast?

    Read the lesson: why this matters

    Write the current steps in order. For each step record who acts, what they need, what they produce and where the case waits. Include decisions such as “Is required information present?” and loops such as “Request clarification, then check again”.

    Handling time is time someone actively works on the case. Waiting time is time it sits between actions or depends on information. Elapsed time covers both within your defined clock. Define business-time versus calendar-time rules before using real turnaround figures.

    A hand-off crosses a role or system boundary. Make the receiving owner and required evidence visible. Count repeat entry, copying and searching as work too. Never add real member details to a training process map.

    Sources for this module

      MODULE 3 OF 6 · 8 MINUTES

      3. Find causes, not convenient blame

      You will: Form a testable cause hypothesis. Prioritise a problem by impact and frequency.

      Scenario

      You are discussing H-01’s 180-minute information wait with Harbour’s employer liaison lead. One suggestion is to tell Cedar to work faster, but the field instructions and query message may be unclear. Your goal is to distinguish what the evidence shows from an explanation that still needs checking.

      Example

      A cause you can test

      Symptom: H-01 needed a clarification. Hypothesis: the field guide says “date” but does not identify the event or format. Test: give two colleagues the fictional guide and the same invented event; compare what they enter. A possible fix is a clearer field label and an example. This does not prove Cedar caused the delay or that every missing value has the same cause.

      Takeaway: Test a narrow explanation before prescribing a broad fix.

      Your task

      1. Choose one wait or rework loop from H-01.
      2. Write one fact and two possible causes.
      3. Choose one cause to test using only fictional material.
      4. Explain what result would support it and what would make you reconsider.

      Your output: A cause-and-test note.

      Working-note template
      Symptom and evidence: ___
Hypothesis A: ___
Hypothesis B: ___
Safe test: ___
Expected evidence: ___
Impact / frequency / confidence: ___

      Reflect: What evidence would show your favourite explanation is wrong?

      Read the lesson: why this matters

      Start with a specific symptom: a required field was absent, the case waited, or the next owner was unclear. Then ask what made that possible. Look at the input instructions, ownership, system behaviour and workload before assuming carelessness.

      A cause hypothesis is a plausible explanation to test. “Cedar does not care” cannot guide a useful test. “The guidance does not explain which date is needed” can be checked against the form and a fictional submission. Label untested ideas honestly.

      Do not choose improvements only because their delay is largest in one case. Consider how often the problem occurs, the effect on members, the risk of a wrong result and how confident you are in the evidence. An essential safety check is not waste just because it takes time.

      Sources for this module

        MODULE 4 OF 6 · 10 MINUTES

        4. Redesign the hand-offs and controls

        You will: Simplify steps without weakening controls. Design normal and exception routes.

        Scenario

        You are drafting a simpler intake route for Harbour with the administrator and reviewer. The team wants fewer queues but cannot remove checks that protect accuracy. Your goal is to propose a clear normal route and exception route with named owners and evidence at each hand-off.

        Example

        A proposed future route

        Receive/log → assign owner → check required fields → if incomplete, record exception and one clear clarification request → when evidence arrives, validate and record review → second check → authorised status confirmation. Proposed waiting times are 30 minutes for ownership, 90 for information and 60 for the checker. Handling remains 70 minutes, so the planning estimate is 250 minutes total. The 210-minute reduction is a hypothesis to test, not a measured saving.

        Takeaway: Label future-state estimates as estimates.

        Your task

        1. Draw the proposed route and retain the incomplete-information branch.
        2. Write one hand-off agreement between administrator and checker.
        3. Name the evidence for acceptance and for unresolved exceptions.
        4. Add an access safeguard, a correction audit trail and a deputy route.

        Your output: A future-state workflow and hand-off agreement.

        Working-note template
        Proposed normal route: ___
Exception route: ___
Hand-off: sender / required input / receiving owner / acceptance evidence ___
C safeguard: ___
I safeguard: ___
A safeguard: ___
Estimated benefit and assumptions: ___

        Reflect: Did your redesign remove a cause, or merely rename the queue?

        Read the lesson: why this matters

        Try changes in this order: remove unnecessary steps, clarify inputs, combine duplicated work where safe, improve hand-offs, then consider automation. Moving a queue into another team does not remove the wait. Copying data into a new spreadsheet may add risk without helping the member.

        A good hand-off is a small agreement: this role provides this information, the next role accepts it after this check, and this evidence records the result. If the input is incomplete, the exception has an owner, reason and next review point.

        Preserve checks proportionate to the risk and actual authority. For training, keep the second review and improve its scheduling rather than assume it can be removed. Restrict the information in status views, keep changes traceable and provide deputy cover for unavailable staff.

        Sources for this module

          MODULE 5 OF 6 · 8 MINUTES

          5. Walk through ordinary and difficult cases

          You will: Test a workflow before adoption. Use expected results and evidence rather than opinion.

          Scenario

          You are ready to review Harbour’s proposed process with colleagues before any real change. A neat diagram does not show whether a duplicate submission or an absent reviewer will be handled safely. Your goal is to rehearse the route using four fictional cases and record what actually happens.

          Example

          Four rehearsal outcomes

          H-02 complete: follow the normal route and preserve review evidence. H-03 missing required date: enter the exception route and do not invent the value. H-04 duplicate reference: flag for review and do not create a second accepted case. H-05 reviewer absent: use the approved deputy; if none is available, retain a visible waiting status and escalate rather than bypass the check.

          Takeaway: Include cases that should stop, not only cases that should finish.

          Your task

          1. Write expected results for the four cases.
          2. Walk each through your future-state map on paper.
          3. Record any missing owner, status or decision.
          4. Revise the map and state what must be checked again.

          Your output: A workflow rehearsal record.

          Working-note template
          Case | Expected outcome | Observed outcome | Evidence | Gap | Owner
H-02 ___
H-03 ___
H-04 ___
H-05 ___
Revisions and retest: ___

          Reflect: Can the team explain what happens when the normal route cannot continue?

          Read the lesson: why this matters

          A tabletop rehearsal means walking a fictional case through the proposed steps, with people explaining their actions. It does not require live systems. Give each case an expected outcome first, then record the observed outcome and any gap.

          Test a complete submission, an incomplete submission, a duplicate and an unavailable reviewer. Check both normal completion and safe non-completion. A process that correctly pauses an unsafe case is working, even if the speed measure does not improve.

          Keep a decision log: change proposed, reason, owner and evidence required before acceptance. Do not declare the new route verified because participants liked it. A later real pilot needs appropriate approval, controlled scope and a way to revert.

          Sources for this module

            MODULE 6 OF 6 · 8 MINUTES

            6. Write the guide and improvement plan

            You will: Produce a usable one-page process guide. Plan improvement with owners and evidence gates.

            Scenario

            You are preparing Harbour’s proposal for a service-owner discussion. The map is useful, but colleagues need a short guide and a clear plan for testing the changes. Your goal is to document the decision points, responsibilities and evidence needed without presenting the draft as approved policy.

            Example

            A small delivery plan

            First: operations lead agrees the boundary and metric definitions. Next: employer liaison lead tests clearer field guidance with dummy cases. Then: reviewer lead rehearses owner/deputy hand-offs and records gaps. Finally: service owner reviews evidence and decides whether to authorise a limited real pilot. Success requires correct outcomes and preserved controls, not just the estimated reduction from 460 to 250 minutes.

            Takeaway: Make the next decision and its evidence explicit.

            Your task

            1. Complete the one-page guide template using your redesigned route.
            2. Add three improvement actions with owners and evidence gates.
            3. Use the optional Copilot prompt if useful, then apply its review checks.
            4. Label the result as a fictional draft and identify the real roles that would review an operational version.

            Your output: A workflow guide and evidence-based improvement plan.

            Working-note template
            Use the blank process guide and improvement plan templates below.

            Reflect: Could a deputy follow the guide without relying on an unwritten conversation?

            Read the lesson: why this matters

            Your guide should fit the person doing the work: purpose, start and finish, numbered steps, decisions, exception route and evidence. Use one action per sentence and avoid product-specific instructions until the actual environment and permissions are confirmed.

            Your improvement plan needs an action, owner, dependency, proposed date and success evidence. Separate a change being written from being deployed and from being verified. A proposed improvement is not an established benefit.

            Copilot can help draft a guide or challenge a missing exception using only the synthetic text here. Review every step against your map, check that it has not invented a deadline or authority, and keep the accountable human decision. You do not need AI or a premium feature to complete the workshop.

            Sources for this module

              Your working templates

              Use the blank templates for your fictional exercise. Compare your approach with the worked examples, not with a pass mark.

              One-page process guide: blank template
              FICTIONAL DRAFT FOR DISCUSSION
Purpose and service outcome: ___
Start: ___
Successful finish and evidence: ___
Scope / exclusions: ___
Owner and deputy: ___
1. Receive and assign: ___
2. Check inputs: ___
3. Normal route: ___
4. Incomplete or duplicate route: ___
5. Review and confirm: ___
Confidentiality / integrity / availability controls: ___
Evidence retained: ___
Unresolved work and escalation: ___
Approver and review date: ___
              Worked guide: Harbour intake
              FICTIONAL DRAFT, NOT AN APPROVED PROCEDURE
Purpose: accept complete employer submissions with clear ownership and traceable checks.
Start: file reaches the approved intake point. Finish: acceptance and review evidence recorded; unresolved exceptions remain open.
Exclude: benefit calculations, live record changes, payments and real messages.
Owner: intake lead; deputy: trained intake colleague.
1. Log the submission reference and assign an owner.
2. Check required fields and potential duplicate references.
3. For complete submissions, record validation evidence and send to the designated checker within the fictional workflow.
4. For missing information, record the gap and next action. For potential duplicates, pause acceptance pending review. Never invent missing data.
5. Record the checker’s decision and authorised status. Use deputy cover where available; otherwise keep the delay visible.
C: restrict access and minimise status detail. I: preserve evidence and correction history. A: deputy and visible unresolved queue.
Review and approval: required before any real use.
              Improvement plan: blank template
              Action | Outcome | Owner | Dependency | Proposed date | Evidence gate
1. ___
2. ___
3. ___
Baseline and clock definition: ___
Estimated benefit, not yet proven: ___
Balancing checks: accuracy / exceptions / access / workload ___
Pilot boundary and approval: ___
Stop or revert if: ___
Review date: ___
              Worked plan: Harbour
              1. Clarify required-field guidance | Fewer avoidable queries | Employer liaison lead | Agreed field definitions | Checkpoint 1 | Two colleagues interpret dummy examples consistently.
2. Assign an intake owner and reviewer deputy | Less ownerless waiting | Operations lead | Capacity and delegated authority confirmed | Checkpoint 2 | Normal and absent-reviewer rehearsals follow the agreed route.
3. Rehearse the new workflow | Correct outcomes with visible exceptions | Process owner | Updated guide | Checkpoint 3 | H-02 through H-05 meet their expected results; gaps are fixed and retested.
Baseline: H-01 has 70 handling +390 waiting =460 measured minutes. Proposed estimate: 70+180=250. No measured saving claimed.
Pilot: separate authorisation required. Stop for a lost case, duplicate acceptance, weakened check or inappropriate access. Review quality and waiting together.
              Optional Copilot prompt: draft the process guide
              COPYABLE PROMPT
Help me write a one-page guide for a fictional pensions administration process. Use only this synthetic case. Start: a fictional employer file arrives. Steps: log and assign; check required fields and duplicate reference; route missing information to an owned exception; validate complete information; obtain second review; record authorised status. Missing values must never be guessed. A potential duplicate pauses acceptance. An absent reviewer uses an authorised deputy or a visible wait, not a bypass. No live records, messages, payments or benefit calculations are in scope. Produce purpose, numbered steps, owner placeholders, decision points, evidence and confidentiality/integrity/availability safeguards. Label it Draft for discussion. Mark missing information as unknown. Do not invent law, deadlines, organisation policy, access rights or product capabilities.

REVIEW BEFORE USE
Compare every step with your map. Confirm exceptions stay open until resolved. Check the duplicate and absent-reviewer branches. Remove invented authorities or deadlines. Keep the output fictional and do not treat the draft as permission to operate a real process.
              Optional Copilot prompt: challenge the proposed solution
              COPYABLE PROMPT
Review this synthetic workflow proposal: owner assignment wait falls from 90 to 30 minutes; missing-information wait from 180 to 90; reviewer wait from 120 to 60; handling stays 70 minutes. Calculate old and proposed totals, label benefits as unproven estimates, and suggest five questions to test before adoption. Preserve checks, confidentiality, a clear exception owner and deputy cover. Do not recommend connecting to real systems or removing required review.

REVIEW BEFORE USE
Expected totals are 460 and 250 minutes; estimated difference 210. Check the model has not called this a proven saving, assumed all cases are the same, or substituted a new system for understanding the cause.
              Copilot: account and safety check
              Optional Copilot assistance: check your signed-in account, licence and employer’s approval. Microsoft supports some personal Premium use with work documents under administrator controls, but features vary. This course uses synthetic material only, regardless of licence. Never paste real member data or connect organisational sources for these exercises. Review outputs yourself.

Use only the supplied fictional material with a copyable prompt. Do not attach work files, authorise connectors, enable an agent to act, or ask it to send, publish or update records. If a feature is unavailable, work in a blank document or on paper. Check arithmetic, missing assumptions, invented rules and whether the proposal preserves confidentiality, integrity and availability. An AI draft is not operational approval.

              This button opens the sections before printing. Check the print preview and choose which pages you need.

              Review your workflow, without a test

              • The process has a defined start, successful finish and open-exception state.
              • The current map shows hand-offs, loops and waiting.
              • A proposed cause is clearly distinguished from a proven fact.
              • The redesigned route preserves confidentiality, integrity and availability.
              • The complete, incomplete, duplicate and absent-reviewer cases have expected results.
              • The guide and plan name owners, evidence gates and approval needs.
              • Every example and Copilot prompt uses synthetic information only.

              You now have a draft workflow guide and improvement plan. Use the evidence to discuss the next authorised step; completion is not approval to change a live process.

              There is no saved completion tick for this workshop. Existing course answers and progress are unchanged.

              Home