Digital Transformation

Practical advice on what to build, what to buy, and what to leave alone.

What you get

Practical advice on what to build, what to buy and what to leave alone, grounded in how your organisation actually works rather than in what is fashionable.

"Digital transformation" is a phrase that has been used to sell a great deal of expensive disappointment. Used honestly it means something simple: working out which parts of what you do are held back by the tools you use, and changing those parts in an order that does not break the business while you do it.

Who this is for

• Organisations that know something needs to change but not what, or first
• Businesses that have been quoted large sums and want an independent view
• Companies where every department has bought its own tool and none connect
• Anyone who has tried this before, spent money, and has little to show
• Leaders being asked to approve technology decisions they cannot evaluate

What this involves

• Understanding how the work actually happens, including the informal parts
• Identifying which constraints are technical and which are habit or policy
• Deciding honestly what to build, what to buy, and what to leave alone
• Sequencing the work so each step delivers something usable
• Being clear about what it will require from your people, not just your budget
• Documenting the plan so it survives whoever happens to be in the room

Build, buy, or leave alone

Most advice in this area has a commercial interest in the answer. Ours is that all three are frequently right, and the discipline is telling them apart.

Buy when the process is ordinary. Accounting, payroll and email are solved problems and building your own is a way of paying more for less.

Build when the way you work is genuinely distinctive and that difference is why customers choose you. Forcing that into generic software throws away the advantage.

Leave alone more often than anyone expects. Plenty of systems are unglamorous, work, and would cost real money and disruption to replace with something marginally better. A recommendation to change nothing is sometimes the most valuable one available.

Why these projects fail

Rarely for technical reasons. They fail because nobody agreed what success meant, because everything was attempted at once, or because the people expected to use the new thing were told about it rather than involved in it.

So we sequence work into pieces that each stand alone and deliver something. If the money runs out or priorities change after the second step, you still have two working improvements rather than a half-built plan. And the people who do the work are part of designing it, because they know things about the process that no document records.

How we work

We spend time understanding the current situation before recommending anything, and we say plainly when the answer is that you are fine.

You get a written view of what we found, what we would do, in what order, and what each part depends on. It is written to be read by the people paying for it rather than by other technologists.

If you want us to do the work afterwards, we can. If you would rather take the plan to someone else, that is a legitimate outcome and the document is written so that it can be.

Questions we are often asked

Is this just consulting we pay for and then ignore? That is the usual failure, so the output is a sequenced plan with concrete first steps rather than a strategy document.

Will you recommend your own services? Where they fit, and we will tell you when they do not. A recommendation to buy something off the shelf is a normal outcome.

How disruptive is this? That is part of what gets planned. The sequencing exists specifically so you are never betting the operation on one switchover.

We tried this before and it did not work. Why now? Worth understanding what went wrong last time, and it is usually informative. Often the plan was sound and the sequencing was not.