Digital Transformation Questions: What to Stop Doing First

A few years back I sat in a conference room with a programme lead whose digital transformation had, by her own description, become a second job for everyone involved. There were nine workstreams, a weekly steering call that ran long, and a tracker with so many columns that scrolling it felt like reading a train timetable. She turned to me and asked, quietly, “Do we need another workstream, or fewer?” That question has stayed with me, because the honest answer in most organisations is fewer. What follows is a set of questions I hear often, answered in the plain terms she deserved at the time.

What does “cut before you add” actually mean in digital transformation?

It means that when a change programme is struggling, you look at what can be removed before you look at what can be introduced. Remove a workstream that duplicates another. Remove a status report nobody acts on. Remove a mandatory approval that adds a day and catches nothing. What remains has more attention, more energy and more clarity about its purpose.

The reflex is the opposite. A programme running late is handed an extra tool, an extra consultant, an extra governance layer. Each addition has a cost in coordination, and coordination is precisely what a late programme lacks.

How do we know our programme has too much in it?

Listen for these sentences in your own meetings:

• “I thought that was the other team’s piece.”
• “We cannot start until the previous phase is formally closed, and nobody can say who closes it.”
• “Which version of the plan are we on?”
• “We are tracking it, but nobody owns it.”

Any one of them is normal. Hearing all four in a single week suggests that the programme’s weight has outgrown its steering. At that point, adding structure usually makes the weight heavier.

Where should a team start removing things?

Start where the evidence is easiest to gather. Ask each workstream lead to write, in two sentences, what outcome their stream will change for a customer or colleague by the end of the quarter. Anything that cannot be written in two sentences is a candidate for merging or pausing.

Then look at recurring ceremonies. How many standing meetings does a typical engineer attend each week because of the programme? What decision has each one produced in the last month? A meeting that has produced no decision and no useful information is a safe place to begin.

Is it risky to stop a workstream halfway?

It feels risky, because stopping admits that something did not work. But continuing a stream you no longer believe in is the more expensive route. A sensible approach is to pause rather than cancel, write down what was learned, and set a date to revisit. Often the revisit never happens, which tells you the stream was not essential.

If a pause worries stakeholders, give them the reasoning in plain words: the team is concentrating effort so two or three outcomes land properly. People forgive a narrower scope far more readily than they forgive a missed commitment on a broad one.

How does this relate to cloud migration and tooling?

Migration programmes are especially prone to accumulating scope, because moving workloads exposes so many neighbouring problems. It is tempting to fix them all in flight. A calmer pattern is to move what is needed, and leave the rest recorded as future candidates. For a grounding in how consulting support typically fits around such moves, an overview of the part consultants play when workloads move to the cloud sets out the usual territory.

When the pull to add a fix arises, ask whether the migration succeeds without it. If yes, it waits. This single question protects the date more reliably than any contingency buffer.

One more sign deserves a mention: the calendar. If your key people spend most of their week in programme meetings, the programme is consuming the very capacity it needs to deliver. A useful experiment is to cancel every recurring programme meeting for two weeks and see which ones anyone asks to bring back. The ones that return are the ones with real purpose. The rest were habit, and nobody will mourn them.

What about the process itself: the forms, the gates, the sign-offs?

This is where I have seen the greatest relief. Take a release process that grew one gate at a time. Each gate was added after an incident, by someone with good reason. Years later, the sequence is eight stages long and takes three days, and nobody can explain what the fifth one catches.

Try an exercise with the team. Print the stages. For each one, write the last real problem it caught, and when. If the answer is “I cannot remember”, you have found a candidate. Do not delete it blindly. Instead, switch it to advisory for a month, watch what happens, and then decide. In my experience a surprising number of gates can be removed or folded together without any increase in trouble.

Should we hire help to do the cutting?

Outside perspective can be useful, because insiders find it awkward to question each other’s pet projects. But do not hire help to add a layer of analysis on top of the programme. Ask them to help you remove, and measure their value by what the organisation stops doing. The best engagements I have seen ended with a shorter plan than they began with. If you want to see how a well-run engagement is usually structured from first assessment through to handing capability back, a guide to running an engagement from the first assessment to enablement is a good reference point.

What do we say to people whose work gets cut?

This is the human part, and it matters most. When a workstream is retired, the people on it did nothing wrong. Often they did excellent work on something the organisation later decided not to pursue. Say so directly. Move them to a stream that is staying, thank them in front of their peers and capture what they learned so it is not lost.

The programme lead I mentioned did exactly this. She closed three streams in one afternoon, and spent the following week talking individually to each person affected. Two months later the remaining streams were ahead of plan, and the people she had moved were among the most engaged in the programme. The lesson she took was that cutting needs more care than adding, not less.

Is there anything worth writing down while we do this?

Yes. Keep a plain list of what was stopped, why, and what you would need to see to restart it. It protects the team from revisiting settled debates and gives newcomers a record of the thinking. Some teams share these reflections publicly, since they help others facing the same pile. A blogging network like BlogOrbix, which positions itself as a distraction-free place for writers is one option for turning an internal lesson into a post, with Google sign-in and room for more than one contributor on the same blog.

How do we keep from drifting back to adding?

Build a gentle friction into the process. For the next quarter, require that any new workstream, meeting or approval be proposed together with one thing it will replace. Make it a rule of thumb rather than a bureaucratic form. The effect is to make the cost of additions visible at the exact moment someone suggests them.

Also review the list of retired items at the start of each planning cycle. It is a quick way to remember why the programme is lean, and to notice when the pressure to bloat returns.

A closing thought from that conference room

The programme lead told me later that the hardest part was not the decision. It was giving herself permission to believe that a smaller programme could still be a serious one. Transformation is not measured by how much machinery you assemble. It is measured by whether the people who use your systems and services notice that something has genuinely improved. Fewer commitments, honestly kept, tend to achieve that far more reliably than many commitments, loosely held.

Kabir Malhotra