Digital transformation 90-day roadmap: one practical pilot

A digital transformation 90-day roadmap starts with your processes, not a shopping list. After this guide, you can prepare an inventory and pilot charter in fifteen minutes, then plan the evidence and decisions needed for a limited trial.

Last updated: 14 October 2026.

Define the finish line before choosing software

A digital transformation 90-day roadmap should turn one everyday operating problem into a documented, tested way of working. Your finish line is a process inventory, a bounded pilot, evidence of use and a decision about what happens next. Buying software is not, by itself, any of those outcomes.

The ninety days below are a proposed planning framework, not a promise that a company can complete its transformation in a quarter. Set actual dates around staff capacity. If a stage’s acceptance check is incomplete, the calendar should not automatically authorise the next stage.

OECD’s SME transformation report describes adoption as multifaceted and dependent on business context and capacity. This article’s day ranges are my practical framework, not an OECD-prescribed timetable.

Think of a small repair business handling internal equipment requests through scattered messages. The proposed change is to make a request visible, assignable and traceable. This hypothetical example concerns operations, not customer acquisition, a marketing-channel plan or an artificial-intelligence rollout.

Days 1–15: inventory the work people actually do

A process inventory is a list of recurring work, its owner and the information it uses. Start with equipment requests, rota changes, purchase requests or reporting. Give each process a specific starting event and an observable finish. Avoid entries such as “improve efficiency” that do not describe work.

Ask the employee to show the process, not just describe the official procedure. A request supposedly received in one system may actually arrive through email, a message and a paper note. Record that gap without blaming the employee. It tells you what the proposed change must accommodate.

For recent examples, distinguish handling time from waiting time. Write the start and finish of each measurement. A quick data-entry step can still sit inside a process that waits days for approval. Your inventory should reveal that distinction before the team focuses on the easiest button to automate.

For spreadsheet implementation, use the Sheets workflow guide after recording the process requirements.

Identify the authoritative record: the place the team agrees to consult for the current state. If a request has different statuses in a spreadsheet and a message thread, ask which version controls the next action. Record missing fields and repeated entry rather than hiding them in a tidy diagram.

Process:
Starting event:
Observable finish:
Operator and person accepting the result:
Authoritative record:
Repeated entry and missing fields:
Handling time / waiting time:
Common exception:
Open question and owner:

Days 16–30: choose the smallest useful pilot

A pilot is a limited trial before wider adoption. Choose one recurring step whose result someone can inspect. Do not make payments, complete stock migration or unattended customer commitments a condition of your first exercise. Small scope makes the result easier to investigate.

For the fictional repair business, the pilot records equipment requests with a reference, description, owner and status. Purchasing approval and supplier commitments remain with people. These are proposed boundaries, not a report of a customer project or achieved savings.

Write what will not change. “Track one team’s internal requests” is more actionable than “digitise the business.” Check whether an existing tool can support the record before discussing a new purchase. A selection should follow the acceptance requirement, not create it.

Anar’s published reflection on effectiveness, in Azerbaijani, describes perfection delaying his projects. A narrow trial applies that preference for practical progress. It does not claim that he ran this ninety-day example or achieved a particular operational result.

Give the sponsor a charter to accept: scope, owner, baseline, test users and decision date. If no future user can participate, or nobody owns the data, record that blocker. The pilot is not ready merely because an implementer can show a convincing demonstration.

Pilot name and owner:
One step to change:
Work explicitly out of scope:
Test users:
Baseline and measurement method:
Acceptance check:
Manual fallback:
Decision date and approving person:

Check data quality, access and export before testing

Define the fields the pilot actually needs. Does Completed mean the request was reviewed, the item was supplied or the record was closed? Agree on one meaning and show it beside the field. A status that means different things to different users cannot support a reliable report.

Prepare normal, incomplete and repeated test records. Write what should happen to a missing owner or duplicate reference. Someone must know the next action for each exception. A clean example alone is not enough to establish that everyday work will remain traceable.

Keep an access list naming who can read, edit and manage users. The pilot should not require everyone to become an administrator. Assign a person to review access when a participant leaves or changes roles. Treat that list as an operating document, not an informal memory.

Test export: obtaining the records in a readable file outside the tool. Check whether the reference, status and owner remain understandable. Ask another colleague to open the file. A polished screen is not evidence that the business can recover its records or leave the service.

The UK technology-adoption study identifies alignment with existing systems as an adoption consideration. Use that finding as a reason to test your own alignment, not a claim about the outcome for your business.

For protection of working records, review small-business backups separately. Being able to export one pilot file and having a maintained backup process are different checks. Record which has actually been demonstrated.

Days 31–60: collect evidence another user can repeat

Run a complete request through the trial using test information. It enters the agreed record, receives an owner, changes status and reaches the observable finish. Then ask a second user to follow the instructions without continuous help from the person who built the setup.

Write expected results before each trial and observed results afterwards. Include missing fields, repeated references and an unavailable owner. If a user gets stuck, record the step and revise the instruction or process. Do not count a guided demonstration as proof of independent use.

Hold a short weekly review to keep, change or stop a specific part. Change one relevant factor at a time so that the next trial has a clear question. Keep the original test record and its result rather than rewriting the history to match the newest version.

The UK SME Digital Adoption report recommends piloting, measuring outcomes and adjusting using evidence. Its policy recommendation supports this test-and-learn principle; it does not prescribe the business schedule in this article.

Use task delegation to clarify ownership if everyone assumes somebody else is reviewing the pilot. Ask the user to demonstrate the actual work, and use practical employee feedback for the discussion rather than blaming staff for an unclear handoff.

Days 61–90: decide whether limited adoption is justified

Limited adoption means a small group uses the process in its ordinary work, with a known fallback. Preserve the previous reliable records and name who can authorise returning to manual handling. A launch date is not evidence that the new process is better.

Compare the baseline and trial using the same definitions. Show handling time, waiting time, incorrect records and correction effort together. If the workload or user group changed, state that limitation. Do not attribute every difference to the pilot.

Faster entry with more unassigned requests is not a passed result. Read speed alongside record quality and the actual completion condition. Define your acceptance check before inspecting the final figures, rather than choosing a convenient threshold afterwards.

A useful decision can be go, change or stop. Go requires repeatable use and passed acceptance checks. Change requires a specific unresolved issue and a named next test. Stop preserves the manual route and records what was learned. None of these decisions requires a promised financial return.

Choose operating measures using the small-business KPI guide. A KPI is simply a measure used to judge progress. The number of tools installed is not a substitute for evidence that a request reaches the right owner and finish.

What can you prepare in fifteen minutes today?

List three recurring processes and the owner and data source for each. Pick one clear step and fill in the pilot charter above. If a baseline is unknown, write how someone will collect it instead of inventing a number. This exercise does not require buying or deploying anything.

Ask a colleague to read the charter and answer three questions: what changes, what stays unchanged and who accepts the result? If your answers differ, revise the wording before comparing software. That disagreement is useful preparation evidence.

Your ninety-day handover pack should contain the inventory, charter, test log, user instructions, access list and decision record. A colleague should be able to understand what was tested and what remains unresolved. The goal is one owned, repeatable operating improvement, not a larger collection of subscriptions.