Digital transformation, described in the order it actually happens
Transformation is a word for a sequence of ordinary decisions taken in the right order.
Logic Networks helps organisations across London and the rest of the UK work out what to change, in what order, and what each step costs. Then we do the parts that are technical and stay out of the parts that are not.
The usual reason these programmes fail is not technology. It is that everything was attempted at once, on top of the day job, with no agreement about what success looked like.
So we plan in stages that each deliver something usable, and we say plainly which parts of your plan we think are not worth doing.
The first question is not what to build. It is what to stop doing.
Most organisations carry two or three systems, reports or processes that exist only out of habit. Removing them costs nothing and releases the capacity for everything else.
- A written plan with stages, costs and an order
- Each stage useful on its own, not only at the end
- The technical work done by us, the decisions by you
- An honest list of what we would not do
What is included
Six pieces of work, in roughly the order they arrive.
Not every organisation needs all of them. The first two are where the value is concentrated, and some organisations stop there with a plan they run themselves.
Understanding where you are
Written down as it is, not as intended.
A review of the systems you run, what each one costs, what it is for and how the work actually flows between them.
This stage frequently finds two systems doing the same job, a contract renewing for something unused, and a process that survives only because nobody questioned it. Those findings often pay for the review.
A plan with stages and costs
Something a board can approve line by line.
What to change, in what order, with the cost of each stage and what depends on what.
The order matters more than the contents. Identity and accounts come before devices, devices before applications, and reporting after all of them, because each one is built on the last.
Replacing and retiring systems
Including the ones to switch off.
Helping you choose a replacement where one is needed, moving the data, and properly switching off what it replaced.
The decommissioning is the step that gets skipped, which is how organisations end up paying for both the old and the new system for three years.
Bringing people with it
Because the plan is delivered by them.
Short, practical training for the people who will use the change, a clear message about what is happening and why, and a route for them to say what is not working.
A system nobody was trained on is a system people work around. The workaround then becomes the process, and the change is reported as complete while nothing has changed.
Measuring whether it worked
Against numbers agreed at the start.
A small number of measures agreed before the work starts, recorded as a baseline, and checked afterwards.
Without a baseline, every programme is reported as a success. Two or three honest numbers are worth more than a presentation, and they make the case for the next stage.
Running the programme
Somebody holding the whole thing together.
Where you do not have somebody internal to run it, we do: the schedule, the suppliers, the dependencies and the monthly report to whoever is accountable.
This is the same discipline as our projects and consultancy work, applied over a longer period.
How it works
Three arrangements, and most organisations only need the first.
A plan you can run yourselves is a perfectly good outcome. We would rather write one you use than run a programme you did not need.
Tell us what is prompting this, whether it is a cost, a deadline or a system that has to go, and we will say which applies.
-
A plan, and nothing more
The review and the staged plan with costs, handed to you. Yours to run, to pause or to take to somebody else.
-
A plan and the technical work
We write it and then deliver the parts that are technical, stage by stage, while your team keeps the decisions.
-
The whole programme
Including project management, suppliers and reporting, as an extension of managed IT.
Who it is for
This work is usually triggered by something with a date attached. A system reaching the end of its support, a lease ending, a funding condition, a merger, or a new chief executive asking why things take so long.
It is also for organisations who have tried this before and stalled, which is a large number of them.
- Businesses whose systems have grown one purchase at a time
- Charities and non profits with a funder asking for modernisation
- Education organisations planning across academic years
- Organisations merging, or taking on another site
- Teams carrying a system that is past support and cannot simply be replaced
- Anyone whose last transformation programme quietly stopped
What we need from you
Three things, and without the first one this work should not start.
A plan with no owner becomes a document. We would rather say that at the beginning than produce one that sits in a folder.
One accountable person
Somebody senior enough to settle a disagreement between two departments, and available for an hour a fortnight. Not a committee.
An honest budget shape
Not a figure to be hit, but a sense of what is possible this year and next. It changes the order of the stages, which is the whole point.
A view of your own calendar
Your busy periods, your reporting dates, your quiet weeks. Every stage is scheduled around them rather than around our convenience.
What we usually find in the review
These come up in most organisations, and several of them are savings rather than costs.
- Two systems doing substantially the same job
- A subscription renewing for something nobody uses
- A process that exists because of a system replaced years ago
- One system that cannot be replaced yet and constrains everything around it
- A previous programme’s half finished work still in place
- Data that would have to be cleaned before any move is possible
- A supplier contract with a notice period nobody has checked
- No agreed measure of whether anything has improved
Our steps for working together
The order below is not a preference. Each stage depends on the one before it, and programmes that reverse it are the ones that stall.
- Review and write it down Systems, costs, contracts and how the work flows. Four to six weeks for most organisations, less for a small one.
- Agree what success means Two or three measures, with today’s figures recorded as the baseline.
- Stop what should stop The unused subscription, the report nobody reads, the duplicate system. Costs nothing and releases capacity.
- Fix identity and accounts Because every later stage depends on knowing who somebody is and what they may reach.
- Then devices, then applications In that order, because an application rollout onto unmanaged devices creates work rather than removing it.
- Then reporting Once the systems underneath are settled, the numbers become worth building on.
- Review against the baseline And decide whether the next stage is still the right one. Often it is not, and that is a success rather than a failure.
How we set priorities
Anything with an external date comes first: a support deadline, a lease, a funding condition. Then anything that is costing money every month. Then anything that removes daily friction for a lot of people. Anything described as strategic but without a date or a cost attached comes last, and sometimes never.
Why these programmes stall, and how we avoid it
- Too much at once We stage it so each piece is useful alone. A programme that is paused after stage two has still delivered two things.
- No single owner We ask for one named person before we start, and we say so if that person changes.
- The day job wins Every stage is scheduled around your busy periods, with realistic expectations of your team’s time.
- No baseline Measures agreed first, so progress is a number rather than an opinion.
- The old system is never switched off Decommissioning is a task in the plan with a date, not an afterthought.
- People were not brought along Training and a clear message are in the plan, not added if there is budget left.
The system that cannot be replaced yet
Nearly every organisation has one. An application the whole operation depends on, written a long time ago, supported by a company that is small or gone, running on a version of Windows that should have been retired.
It shapes the entire plan, because it usually cannot be moved, cannot be updated and cannot be turned off. Pretending otherwise is how programmes get six months in and stop.
There are four honest options and the plan has to pick one. Replace it, which is the largest project in the programme and should be treated as such. Move it as it is, so at least the hardware risk goes away. Isolate it, so that its weaknesses cannot reach the rest of your environment. Or accept it for a defined period, with the risk written down and reviewed.
The one thing that does not work is leaving the decision implicit. An organisation that has consciously chosen to isolate and accept a system for two more years is in a far better position than one that has simply not mentioned it, because the first one has a plan and the second has a surprise waiting.
What we will not claim
We will not promise a transformation. What we will do is tell you which changes are worth making, in which order, what each costs and what we would not spend money on. Where your existing plan contains something we think is a mistake, we will say so before taking the work rather than afterwards.
What good looks like
There is one written plan and one person accountable for it. Each stage has delivered something people noticed. You have switched at least one thing off. The measures agreed at the start have moved, and you can say by how much. And the plan has been changed at least once, because a plan that never changes was not being used.
Related services
A transformation plan is mostly a sequence of the other services, scheduled in the right order. That is why we can price each stage rather than the whole thing as one figure.
Where you already have a supplier doing one of these well, the plan keeps them.
- Projects and consultancy for running each stage
- Cloud and Azure for the systems coming off your own equipment
- Microsoft 365 for the accounts and collaboration underneath it
- Data and artificial intelligence for the reporting at the end
- Managed IT to run what the programme leaves behind
Articles and news on digital transformation
Notes on planning, ordering and stopping things, written for organisations that have tried this before.
The first hour after a suspected email compromise
What to do, in order, when you think somebody has got into a mailbox. Written to be followed by whoever is in the office at the time.
Read the articleThe five security controls worth putting in place first
Security spending often starts at the wrong end. These five controls remove the largest share of everyday risk and cost the least.
Read the articleTurning on multi factor authentication without stopping work
The single change that prevents most account takeovers, and how to introduce it across a team of thirty people in a fortnight.
Read the articleTalk to us about your plan
Tell us what is prompting the change and what date it has to happen by. We will review where you are and come back with a staged plan, the cost of each stage and the parts we would not do.
If you already have a plan, send it and we will comment on it.