How to Build a Digital Adoption Plan

A digital adoption plan is a document that says how work runs today, how it should run instead, what has to change to get there, in what order, at what cost, and how you will know it worked.

A plan missing any of the eight is a recommendation, and a recommendation is not executable by anyone other than the person who wrote it. That distinction is the whole test: hand the document to an implementation partner who was not in the room, and either they can build from it or they cannot.

The eight sections

1. Business objectives

What the organization is trying to achieve, in terms that are not about technology.

“Reduce the time between a signed contract and the first invoice.” “Answer a client’s status question without three people checking three systems.” “Produce the monthly board pack without two days of reconciliation.”

Objectives written as technology goals (“implement a CRM”, “go paperless”) cannot be used to make trade-offs later, and the plan will contain dozens of trade-offs. Every scope decision downstream gets resolved against this section, so vagueness here is expensive.

2. Current-state process maps

How the work actually runs, for every process in scope. Stages, owners, decision points, handoffs, exceptions, and the places the same thing is done twice.

Written from interviews and observation, not questionnaires. The documented process and the real one are different documents, and the real one is the requirement. The workaround somebody built for themselves belongs in the map.

Where two people describe the same process differently, both descriptions go in. The discrepancy is a finding.

3. Systems and data inventory

Every application in use, what each one is for, who owns it, what it costs, who has access, and what data lives in it.

Include the spreadsheets. A workbook that three people maintain and forty people read is a production system, and leaving it out of the inventory means designing around a gap you have not seen.

This section routinely surprises the client. Applications appear that nobody at the leadership level knew were being paid for.

4. Gap analysis

The distance between the current state and the objectives, with each gap traced to a cause and ranked.

Ranking is the work. Any organization can generate forty problems; the question is which three are producing the rest. A reconciliation step consuming two days a week is usually a symptom of two systems holding the same record with no agreement about which is authoritative. Fixing the reconciliation without settling the ownership question moves the work rather than removing it.

Where a previous rollout failed, its cause belongs in this section. Those causes are usually still present, and a plan that does not name them is planning the same failure.

5. Future-state design

How each process should run: stages, ownership, approval rules, handoffs, required data, exceptions, notifications, escalations, reporting.

These are business decisions and they need a decision-maker. A consultant cannot decide who approves a discount over fifteen percent. Where the decision cannot be obtained, the plan records it as open rather than guessing, because a guess here becomes a required field that blocks a real case in month two.

6. Solution architecture

What each application is for, what becomes the system of record for each type of data, how the systems connect, and which tools stay or go.

This comes after the process design, not before. Selecting the platform first and bending the process to its defaults is the most common way a plan produces an expensive version of the original problem.

7. Sequenced roadmap

Phases, with what gets built in each, what it depends on, roughly what it costs and roughly how long it takes.

Sequence is not priority order. It is dependency order. Data cleanup precedes migration. The system of record decision precedes any integration. Governance is designed with the build rather than retrofitted, because retrofitting permissions means revisiting every record.

Each phase should be independently valuable. A roadmap where nothing works until phase four is a roadmap that gets abandoned in phase two.

8. Measures

What will be checked, when, and what happens if the number is wrong.

Not logins. Whether records are created at the correct stage, whether approvals run inside the workflow, whether reports come out without manual reconciliation, whether the parallel spreadsheet has stopped being updated.

Where the plan comes from

The plan is the output of the first three stages of a digital adoption engagement. Stages four to six build against it.

How long it takes

Two to six weeks for most small and mid-sized organizations, depending on how many processes are in scope and how available the people who run them are.

What a plan is not

Common mistakes

• Writing objectives as technology goals. "Implement a CRM" cannot resolve a trade-off. Better: state the operational outcome, so every scope decision downstream has something to be measured against.
• Mapping the documented process. The procedure manual describes an aspiration. Better: interview and observe. Where the two disagree, the observed version is the requirement.
• Leaving spreadsheets out of the inventory. They are production systems and they hold data the new design will need. Better: inventory them with everything else, including who maintains each one.
• Choosing the platform in section one. Better: process design first, architecture second. The order is the point.
• Listing gaps without ranking them. A flat list of forty problems cannot be sequenced. Better: trace each to a cause and rank by what is producing what.
• Sequencing by priority instead of dependency. The most urgent item gets scheduled first and blocks on work that was scheduled later. Better: sequence by dependency, and make each phase independently useful.
• Omitting measures. Without them there is no way to tell whether the build worked, and the conversation in month six becomes an argument about impressions. Better: name the measure, the date and the response before anything is built.
• Writing it so only you can execute it. Better: write for an implementation partner who was not there. Several clients take the plan and build it in-house, and that is a legitimate outcome worth designing for.

Frequently asked questions

Where to go next

What is digital adoption covers the definition and scope. How digital adoption works sets out the six stages the plan is produced in, and the plan is the output of the first three. Our six-step approach is how the engagement runs.