SoftwareAutomationArtificial IntelligenceSystem IntegrationDigital TransformationCase StudiesInsightsBook a Transformation Call →

Digital Transformation Roadmap: Build It in November

A practical November planning guide for owners who want January to begin with a prioritised list rather than more spreadsheets. It covers what to gather, what to leave out, and how to rank what you find.

If you want January to start with a prioritised list rather than another round of spreadsheets, November is a good month to build your digital transformation roadmap. A roadmap is a short, ordered plan: which problems in your systems and processes to fix, in what sequence, and why. It does not need to be long or technical. It does need to exist before the new year’s urgent work crowds out the thinking.

Below I set out what to gather now, what to leave out, and how to turn the material into something you can act on.

Why November suits a digital transformation roadmap

Many owners can name what is wrong. Someone re-keys the same data into two systems. A key spreadsheet depends on one person. Reporting takes days to assemble. The harder part is ranking those problems and choosing between them, which needs time that rarely appears in a normal week.

November helps for a few reasons, though I would not oversell any of them:

  • The year is still fresh. You can recall where things went wrong in recent months, not just in the abstract.
  • It sits before the December slowdown and the January rush. Whatever your sector, those two periods tend to crowd out considered decisions.
  • It works whatever your financial year. Your year may end in March, December or another month entirely, so I would not tie this to budget-setting. The point is simply to have the list ready when your own planning starts.

None of this is a reason to hurry. A year-end systems review done carelessly produces a long wish list, which is no better than having no list.

What to gather in November

Good business technology planning starts with evidence, not opinions. You do not need a polished report, just a few honest inputs.

1. The places work gets stuck

Ask the people who do the work, not only the managers. Where do they copy and paste? Where do they chase someone for information? Which mistakes keep recurring? For a structured way to do this, see my article on mapping how your business actually works.

2. Your current systems and what each is for

A simple table is enough. Include the spreadsheets, because the most important system in a business is often a workbook nobody has formally acknowledged as one. An illustrative example:

Tool Main user What it holds What depends on it
Quotes workbook Operations manager Pricing rules, customer quotes Invoicing, job scheduling
Accounting package Finance lead Invoices, payments Monthly reporting
Shared inbox Whole team Customer enquiries Everything that begins with a request

The “what depends on it” column is the most revealing. It shows you where a failure would spread.

3. The cost of each problem

Note the time lost, errors corrected and work delayed. Use your own estimates and be honest that they are estimates. Rough figures are enough to compare one problem with another.

4. The constraints

Budget range, key people’s availability, busy periods, contracts with existing software suppliers and compliance obligations. If your team splits its time between a London office and home, or works across several sites, note that too. It affects how any change is rolled out.

5. Where you want the business to be in a year

One or two sentences will do: more customers, a different mix of work, fewer late nights for the finance lead. The roadmap should serve that aim, not technology for its own sake.

If your main doubt is whether spreadsheets are still the right tool, signs your business has outgrown its spreadsheets is a useful check before you start.

What to leave out

A digital transformation plan for a small business tends to fail through overreach more than neglect. These are the things I would deliberately keep out of the November exercise.

Vendor demos. Looking at products before you have defined the problem anchors you to whatever the product does well. Define first, then look.

Every complaint from every department. Collect them, but do not treat them as equal. Some are irritations rather than constraints on the business.

Detailed technical specifications. You are not writing a requirements document. That comes later, for the one or two items that earn it.

A fixed view on the solution. Write down the problem, not the answer. “Quotes take three days to produce” is a problem. “We need a new CRM” is a guess at a solution, and it may be the wrong one. Sometimes the right answer is bespoke software, sometimes an off-the-shelf tool configured properly, and sometimes a small change to a process.

Anything that depends on a decision you have not made. If an acquisition, a move of premises or a change of service is undecided, note it as a dependency and move on.

Turning the material into a prioritised list

Once you have the inputs, rank the problems. I use four questions and suggest you answer them bluntly:

  1. How much does this cost the business now? Time, money, errors, customer frustration.
  2. How much does it block other improvements? Some problems are foundations. If your data lives in three disconnected places, almost every later improvement is harder until that is addressed.
  3. How big and how risky is the fix? A small automation is a different proposition from replacing a core system.
  4. How ready is the business to change this? A sound fix will still struggle if the people affected were not consulted or the process is not agreed.

Here is a hypothetical example for a professional services firm. The ratings are illustrative, not data.

Problem Cost now Blocks others Size of fix Readiness
Client details held in three places Medium High Medium High
Quotes built by hand in a workbook High Low Small High
Monthly report assembled manually Medium Low Small Medium
Replacing the accounting package Low Low Large Low

A sensible order might be the quotes workbook first, because the fix is small, the pain is high and the team wants it. Joining up the client data comes next, because it unlocks the reporting fix. The accounting package drops off the list for now, since the case for it is weak. That trade-off between quick wins and foundations is the heart of a roadmap. Quick wins build confidence and free up time. Foundations make everything afterwards cheaper and more reliable.

Aim for a handful of items, not twenty. If everything is a priority, nothing is.

Where a Transformation Day fits

You can do all of this yourself, and some owners should. The difficulty is that you are close to the business, and it is hard to rank problems you live with daily. An outside view helps, particularly from someone prepared to say that an item is not worth doing.

That is what the Transformation Day is for. It is a fixed-price day, often held on site, at £600. The output is a prioritised roadmap, and there is no obligation to go further with us afterwards. You can act on it yourself, take it to another supplier, or ask me to help with the next step. If you are in London, you can read more about working with a digital transformation consultant in London.

If you gather the material above beforehand, you will get far more from the day. I describe how it runs in what a Transformation Day actually looks like.

FAQs

How long should a digital transformation roadmap be?

Short enough that you will read it again in March. A page or two covering the priority items, the reasoning, the order and the dependencies is usually more useful than a long document.

Do I need a big budget to start?

No. The roadmap stage is about deciding what is worth spending on. A Transformation Day is fixed-price at £600, so you know what getting clarity costs before you commit to anything larger.

Is November too late to plan for the new year?

No. It is early enough to decide before January and late enough that you have most of a year’s experience to draw on. Even if implementation starts later, having the roadmap saves time.

What if we are not sure we need new software at all?

That is a legitimate position to start from. A roadmap can show that better use of existing tools, or a process change, solves the problem. It should tell you what not to build as well as what to build.

Do I have to work with you after the Transformation Day?

No. The day produces a prioritised roadmap, and there is no obligation to go further.

Start the year with a plan

If you would like to talk through your own year-end systems review, get in touch with Henderson Digital. The first call costs nothing.

More insights

All insights →
Digital TransformationHow to choose a digital transformation consultant7 min read →AutomationThe five processes worth automating first6 min read →Digital TransformationWhat a Transformation Day actually looks like5 min read →

Tell me what's frustrating you.

I'll tell you whether I think there's something worth exploring. If there isn't, I'll say so.

Talk to Ben Transformation Day — £600
Ben Henderson
Ben HendersonFounder & Digital Transformation Consultantenquiries@hendersondigital.co.uk