> For the complete documentation index, see [llms.txt](https://experience-digital-transform.gitbook.io/experience-digital-transformation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://experience-digital-transform.gitbook.io/experience-digital-transformation/roadmap/the-nine-steps.md).
# The nine steps
A roadmap is produced in nine steps, and for each step you can say who acts, what goes in, what comes out, which tools or templates are used, who decides and how the result is checked. Steps 1 to 5 are taught in module 1 and find out where the country stands; steps 6 to 9 are taught in module 6 and turn the result into a roadmap that an authority adopts. The sequence of nine steps is the team's own and comes from its multi-country implementation experience. The nearest published procedures are PAERA section 5.4, which gives eight steps for assessing one organisation, and page 23 of the UNDP Playbook, which gives six steps from national priorities to a roadmap; PAERA section 5.3 gives the nine questions a national assessment must answer, and no scale.
## The roles
| Role | Who holds it |
| -------------------------- | ------------------------------------------------------------------------------------------------------- |
| **Facilitator** | The member of the assessment team who plans and runs the assessment and keeps its evidence |
| **Respondent team** | The unit of the body that answers for one domain, led by its respondent team lead |
| **Section leads** | Staff of the responding unit, one for each section of its questionnaire |
| **Focal points** | One person in each other body involved, who confirms or corrects what is said about that body's systems |
| **Reviewers** | The people who check the work of each step before the next one starts |
| **The adopting authority** | The authority that adopts the roadmap and makes it the government's own |
## The table of the nine steps
| Step | Roles | Inputs | Outputs | Tools or templates | Decision point | Validation |
| ------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **1. Frame** | Facilitator, with the ministry that sponsors the assessment | Public information about the country; the list of its systems, laws and public bodies | One-page map of the five domains, naming the body that answers for each domain | The frame page: the five domains and their sub-components | Which domains, systems and bodies the assessment covers, and which body answers for each domain | An item that fits two domains is discussed with its owner and is not forced into one |
| **2. Automatic assessment** | Facilitator runs it; reviewers read the output of each stage before the next stage runs | The question bank; the country's published documents | First findings and gaps by domain, each tied to its source and marked unverified | The question bank and the desk workflow | None is taken here: the workflow drafts and does not decide; a desk result is a claim to verify | No finding is accepted without its source, and every finding stays marked unverified until step 4 |
| **3. Questionnaires** | Respondent team of each domain, with its section leads; facilitator | The frame page, which names the body that answers for each domain; the desk gaps, as points to confirm or correct | A filled questionnaire for each domain, with the evidence attached | The five questionnaires, each with its guide for the respondent and its guide for the facilitator | The head of the responding unit signs the completed questionnaire | Every answer names the document behind it; the facilitator lists what the evidence supports, what is stated without evidence and the question to ask next, and never fills in an answer the respondent left empty |
| **4. Verification** | Facilitator, with the respondent team leads, section leads and focal points; a validation chair named by the sponsor | The signed questionnaires; the desk results of step 2 | Table of reconciled answers: a verified position on every point | The verification templates: the map of the bodies involved, the plan of sessions, the table of reconciled answers, the agenda of the validation workshop | Where two sources disagree, the facilitator decides which stands and records the reason; the validation chair closes the points still disputed at the validation workshop | Each answer is checked against documents, in interviews and workshops, and in a validation session with the people who gave it; the respondent team lead signs off the verified positions |
| **5. Taxonomy and scoring** | Facilitator proposes the stages; reviewers check | The verified positions of step 4; the written criteria for each sub-component | The five domain reports and the maturity table | The scoring criteria and the scorer | The assessor decides the stage of each sub-component; the scorer only proposes | Only verified positions are scored, and a stage with no quoted evidence behind it is not accepted, so that two assessors reach the same result |
| **6. Gap consolidation and prioritisation** | Facilitator; the bodies on the frame page, at the prioritisation workshop | The findings of the five domain reports | The gap register and the matrix of priorities, with the development priorities of each domain | The gap register and its rule of priority | The prioritisation workshop decides the order of the gaps; the ranks the team proposes are proposals | Every gap names the findings it comes from, so that a reader of the roadmap can walk back to the evidence |
| **7. Roadmap** | The assessment team, writing with the country's bodies | The gap register with its priorities; the dependencies between the gaps | The roadmap over time: horizons, waves and tracks, with the matrix of dependencies and the critical path | The structure of the roadmap | The dates are proposals until the budget cycle and the owners of the work confirm them | Nothing is scheduled before something it depends on, and every roadmap component names the gaps it closes |
| **8. Investment breakdown** | The assessment team, for the finance ministry and the development partners | The components of the roadmap; the ranges of cost for each | Investment case in four sheets: by horizon, wave and component; by domain; by source of funds; the expected returns | The four sheets of the investment case | What is funded first, judged by the cost of each block against the number of services that will use it (subtopic 6.2) | The four sheets add up to the same totals, and no figure enters the case without a source or the word "illustrative" |
| **9. Validation and revision** | Every body on the frame page comments; the assessment team answers; the adopting authority adopts | The draft assessment, the draft roadmap and its investment case; the written comments on them | Response matrix; the revised documents; the adopted roadmap | The response matrix with the prompts of the revision | A person approves the answer to each comment, and the adopting authority adopts the roadmap | Every comment has a written answer, every figure that changes is verified at its source, and the documents are checked for consistency with each other |
## Where each step is taught, and its worked example
| Step | Taught in | Worked example |
| --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 1. Frame | [1.2](/experience-digital-transformation/roadmap/module-1-where-your-country-stands-and-what-to-build-first/1.2-the-five-domains-as-a-map.md) The five domains, as a map | [E1](/experience-digital-transformation/roadmap/the-worked-examples/e1-the-five-domain-frame-set-for-progressas-education-sector.md) |
| 2. Automatic assessment | [1.4](/experience-digital-transformation/roadmap/module-1-where-your-country-stands-and-what-to-build-first/1.4-start-at-the-desk-a-first-assessment-from-public-sources-with-ai.md) Start at the desk: a first assessment from public sources, with AI | [E2](/experience-digital-transformation/roadmap/the-worked-examples/e2-the-automatic-desk-assessment-the-question-bank-and-a-run-for-progressa.md) |
| 3. Questionnaires | [1.5](/experience-digital-transformation/roadmap/module-1-where-your-country-stands-and-what-to-build-first/1.5-ask-the-people-who-run-the-systems-the-five-questionnaires.md) Ask the people who run the systems: the five questionnaires | [E3](/experience-digital-transformation/roadmap/the-worked-examples/e3-the-digital-data-questionnaire-the-blank-instrument-and-a-completed-extract-for-progressa.md) |
| 4. Verification | [1.6](/experience-digital-transformation/roadmap/module-1-where-your-country-stands-and-what-to-build-first/1.6-verify-before-you-score.md) Verify before you score | [E4](/experience-digital-transformation/roadmap/the-worked-examples/e4-verification-the-blank-templates-and-how-progressas-team-used-them.md) |
| 5. Taxonomy and scoring | [1.7](/experience-digital-transformation/roadmap/module-1-where-your-country-stands-and-what-to-build-first/1.7-score-each-domain-five-stages-and-one-table.md) Score each domain: five stages and one table | [E5](/experience-digital-transformation/roadmap/the-worked-examples/e5-the-digital-data-domain-report-and-progressas-maturity-table.md) |
| 6. Gap consolidation and prioritisation | [6.1](/experience-digital-transformation/roadmap/module-6-from-a-proven-foundation-to-a-national-roadmap/6.1-from-findings-to-priorities-the-gap-register.md) From findings to priorities: the gap register | [E6](/experience-digital-transformation/roadmap/the-worked-examples/e6-the-gap-register-and-its-priorities-for-progressa.md) |
| 7. Roadmap | [6.3](/experience-digital-transformation/roadmap/module-6-from-a-proven-foundation-to-a-national-roadmap/6.3-the-roadmap-over-time-horizons-waves-and-tracks.md) The roadmap over time: horizons, waves and tracks | [E7](/experience-digital-transformation/roadmap/the-worked-examples/e7-progressas-education-dpi-roadmap-the-shape-of-the-document-with-the-first-horizon-in-full.md) |
| 8. Investment breakdown | [6.4](/experience-digital-transformation/roadmap/module-6-from-a-proven-foundation-to-a-national-roadmap/6.4-the-investment-case-your-finance-ministry-can-read.md) The investment case your finance ministry can read | [E8](/experience-digital-transformation/roadmap/the-worked-examples/e8-the-investment-case-for-progressas-roadmap-in-four-sheets.md) |
| 9. Validation and revision | [6.7](/experience-digital-transformation/roadmap/module-6-from-a-proven-foundation-to-a-national-roadmap/6.7-validate-revise-adopt.md) Validate, revise, adopt | [E9](/experience-digital-transformation/roadmap/the-worked-examples/e9-validation-and-revision-progressas-response-matrix-and-the-ai-prompts-that-run-the-revision.md) |
The steps of the build, in modules 2 to 5, are taught in the same way: each configuration has an acceptance check of the same name, which says what the check runs and what counts as a pass. They are listed in the build plan. See [the build plan](/experience-digital-transformation/roadmap/the-build-plan.md).
## Sources
* GovStack, *Public Administration Ecosystem Reference Architecture (PAERA)*, version 1.0, dated 25 May 2024. Cited by section. —
* UNDP, *The DPI Approach: A Playbook*, 21 August 2023 —
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://experience-digital-transform.gitbook.io/experience-digital-transformation/roadmap/the-nine-steps.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.