Technical ReadinessTechnical Readiness
Implementation Roadmap
Technical Readiness

Implementation Roadmap

Holly WatsonWritten by Holly Watson

The implementation roadmap emerged as a named document once organisations stopped treating a decision as the end of the work and began publishing the dates they would be held to.

Consider a finance director at a UK distributor in the autumn of 2027. She has just read that from April 2029 her VAT invoices must be issued as structured e-invoices and exchanged over the Peppol network through certified access points. Her accounting system produces invoices happily. What it does not produce is structured data that a customer's system can ingest without a person opening a file. Between the mandate she has just read and the date attached to it sits an artefact her organisation does not yet own, and the checks that follow are the ones that determine whether it gets built in time.

The document has three parents. Project management supplied the form: ProjectManager describes an implementation roadmap as a visual plan of tasks, timelines and responsibilities, and expects it to carry a timeline, milestones, task dependencies, phases, roles, success metrics, resource allocation, a risk log and a change log. Change management supplied the sequencing logic: the Scaled Agile Framework builds its implementation roadmap on John Kotter's accelerators and treats the result as a series of critical moves. Government supplied the discipline of publication. The e-invoicing roadmap from HM Revenue & Customs and the Department for Business and Trade labels every milestone as a decision, a publication, a readiness point or an implementation point, which tells a reader what kind of certainty each date carries. That labelling habit is the most useful single idea to borrow, because most failing roadmaps fail by mixing the four categories until nobody can tell a promise from a plan.

Checks you make before the programme is authorised

The first question is whether the decision the roadmap exists to deliver has actually been taken. If the mandate is still contested internally, you are writing a business case with dates attached, and the dates will move. A roadmap is only an implementation tool once the direction is settled and the argument has moved to sequencing.

You should be able to name an owner who is not the delivery lead. The Strategy Implementation Institute makes the point directly in its Strategy Implementation Road Map: leaders do not implement, they drive and champion, and the staff take the implementation actions every day. A roadmap owned by the person doing the build will be optimised for the build.

You need to know whether your end date is external and immovable. For e-invoicing the date is fixed in policy terms, and the same publication states that full detail on scope, standards and obligations will arrive between 12 and 18 months before the requirement takes effect, leaving an implementation period of at least 12 months. The practical consequence is that the start of your window is not yours to choose, so the plan has to be built backwards from a date you did not set.

Every milestone should carry one of the four labels. A publication date is distinct from a readiness date, and teams that treat them as interchangeable tend to discover, several months in, that they were waiting for a capability.

Finally, write down what the roadmap is not. It is not a requirements specification, a budget or a risk register, and the SAFe series makes the separation visible by pairing its overview graphic with a sequence of articles that carry the actual content.

Checks you make when the detailed requirements are published

You should be able to say whether your organisation, and each of your counterparties, sits inside or outside the scope. The e-invoicing requirement applies to VAT registered persons, which includes businesses, sole traders, partnerships, charities and public bodies, with limited exemptions expected for digitally excluded persons. If that mapping is still guesswork, the sizing is guesswork too.

You should be able to state the format and the network in one sentence each. The same roadmap is explicit that a digital file is not an e-invoice: PDFs, word-processed documents, image files, HTML invoices on a web page and images sent by email all fall outside the definition, because what the receiving system needs is structured data. Peppol is the core interoperability framework, with certified access points doing the exchange. A plan whose receiving step is an email attachment is not a plan.

You should know which identifier resolves a party on the network. Business identifiers get their own chapter in the government roadmap for the simple reason that a network cannot route an invoice to an organisation it cannot reliably name.

You should have chosen between extending what you own and replacing it, and recorded the reason. For many smaller organisations the capability arrives inside accounting software already in use for Making Tax Digital obligations, with several providers having committed to include e-invoicing in core packages once it becomes mandatory. For larger or more complex estates, integration into ERP and supply chain systems is the realistic route, at higher cost and complexity but with larger efficiency returns. Both are legitimate; drifting between them is not.

You should have decided whether your existing EDI estate is an asset or a liability. The roadmap addresses legacy and Electronic Data Interchange systems separately for larger organisations, which means continuing EDI alongside Peppol is a defensible position, while assuming EDI already satisfies the requirement is an assumption.

Checks you make while the system is being built and tested

You should have a pilot cohort and a dual-running window. The WHO's ICD implementation guidance recommends piloting in selected hospitals and running dual coding studies so the effect of a classification change can be measured against existing practice. The same logic applies to any invoice or record format migration: run old and new in parallel for a defined period and measure the divergence.

You should have tested both the receiving path and the issuing path. Most programmes test what they send. The exceptions live in what arrives, and in whether the system can accept it without human intervention.

You should have mapped old representations to new ones and checked the mapping against live data. WHO supplies mapping tools for the ICD-10 to ICD-11 transition and still instructs implementers to validate through dual coding, which is a useful corrective to the belief that a published mapping is a finished mapping.

Your test cases should include the failure paths: an invoice rejected at the access point, a supplier identifier that does not resolve, a duplicate submission, and a counterparty still sending a PDF. Each one needs a named owner and a defined response.

The change log should be live from the first week. An implementation roadmap that cannot show its own revisions cannot be trusted about anyone else's dates.

Checks you make at cutover

Your fallback position should be written down and legally defensible. Where the law requires structured e-invoices, reverting to PDF is not a fallback; a manual process with a stated tolerance, a named approver and a defined trigger is.

The people trained should include both those who process the happy path and those who handle exceptions. The support model for the first weeks should be agreed with your software provider and your own service desk before go-live.

Your counterparties need to know how to send you an e-invoice and where to send it. Communication to suppliers and customers is an integral part of the implementation.

Checks you make in the first months of live running

The review cadence should be fixed in governance. The Permitting Technology Action Plan requires agencies to provide implementation updates no less than twice annually, a cadence that survives a change of personnel.

The roadmap should distinguish what is completed from what is in progress from what is planned next. NHS England Digital's NHS.UK roadmap is structured that way, and the effect is that a reader can see slippage instead of inferring it.

Dates should be replaced by actuals as they pass, and the document should have an end condition, some point at which the capability is operational and the roadmap retires into ordinary service management. A roadmap that never closes is a status report wearing a different title.

The test of the whole exercise is narrow. At any point in the programme, someone outside it should be able to ask which milestone you have passed and which you have not, and get an answer that does not require interpretation.

Sources