Ninety days from choosing the payroll problem to a decision on launch

Ninety days can validate a narrow payroll proposition and produce a controlled pilot. It is not a credible timetable for supporting every employer situation. This plan assumes a team has authority, relevant expertise and access to genuine users while protecting all payroll and research data.

Days 1 to 15: choose the problem

• Define the user, buyer, payroll pattern and exclusions.
• Observe recent payroll cycles with safe or redacted evidence.
• Quantify the current workaround, errors and staff time.
• Map approvers, blockers and buying trigger.
• Write one measurable pilot outcome.

Use HMRC's running payroll overview as an official process reference, then document how the selected English organisations actually perform each step.

Days 16 to 30: establish the rule boundary

• Inventory supported tax-year calculations and reports.
• Identify the applicable HMRC specifications and test data.
• Decide whether PAYE recognition is required for the route.
• Map pension assessment, contribution and data exchange.
• Record controller, processor and sub-processor roles.

The HMRC developer collection links payroll technical material. The Pensions Regulator's software task guide prevents a narrow calculation test from being mistaken for a full pension workflow.

Days 31 to 50: build and test the thin workflow

• Create only the path needed for the pilot outcome.
• Use synthetic records covering ordinary and boundary cases.
• Test permissions, validation, calculation and audit history.
• Exercise submission outcomes, errors and correction paths.
• Test export, backup restoration and service fallback.

HMRC's payroll test data for 2026 to 2027 is one input to testing, not a complete assurance pack. Add customer-specific frequencies, configurations and integrations.

Days 51 to 70: run controlled parallels

• Recruit a small set matching the exact segment.
• Agree data handling, responsibilities and stop conditions.
• Run the existing process and prototype in parallel.
• Reconcile every difference before progressing.
• Record operator time, interventions and support demand.

Do not submit, pay or replace the live system merely to accelerate learning. The pilot agreement should say which process remains authoritative.

Days 71 to 90: decide and prepare

• Resolve or explicitly accept every material issue.
• Review security, privacy, pensions, tax and operations evidence.
• Test support around the selected payroll deadline.
• Calculate pricing from observed delivery cost.
• Decide to launch narrowly, extend the pilot, change direction or stop.

If interaction with HMRC services is planned, check the current access policy before approving the architecture.

The day-90 output is an evidence pack: supported scope, test results, reconciliations, unresolved risks, operating instructions, support model and commercial case. A decision to stop can be successful when evidence disproves the proposition before broader customer exposure.

Weekly governance throughout the plan

Maintain one decision log containing assumption, evidence, confidence, owner and expiry. Review unresolved issues with the people responsible for payroll, tax, pensions, privacy, security, operations and finance. The reviewer able to accept a risk must also be able to pause the work.

Keep customer communication precise. Pilot participants should know what is experimental, which system remains authoritative, what data is used and how to report a problem. Do not offer a public compliance claim in exchange for participation.

At each weekly review, compare progress with the narrow outcome rather than task volume. Remove backlog items that do not strengthen it. If evidence reveals two substantially different customer workflows, select one for the current period and document the other for later research instead of combining them in a rushed build.