Finding where value is actually being lost, deciding deliberately what to act on, and staying involved until the numbers move.
Most operations already sense that performance is short of what it should be. Saying where, by how much, and in what order to fix it is the harder part. Monthly cost reports show you the symptom. Downtime data exists but is rarely connected to the dollars. Ideas accumulate faster than anyone implements them, and the loudest problem gets attention ahead of the most expensive one.
So effort ends up spread thinly across a long list with no clear line back to the financial result. People become sceptical of improvement work, not because they dislike it, but because they have watched several rounds of it produce nothing they can point to.
The work here is to make that line visible and then act on it, in an order you can defend to a board.
Nearly every engagement starts here. A value driver tree decomposes the financial result of the business into the operational levers that actually produce it, layer by layer, until you reach something a person can influence on a shift. Revenue splits into volume and price. Volume splits into availability, utilisation and rate. Availability splits into planned and unplanned downtime, and so on.
The diagram is not the point. The point is that every opportunity raised afterwards can be hung off a branch and given a number. An idea that cannot be attached to a branch is not an improvement opportunity, it is a preference. In my experience that one distinction takes a lot of heat out of prioritisation meetings.
Built properly, the tree also shows you where you have no data at all. That is often the more useful half.
There is nothing clever about the sequence. Step three is the one that gets skipped, and skipping it is where most improvement work stops.
A first pass through diagnosis and prioritisation typically runs three to six weeks, scaled to the number of sites involved and the state of the operational data. Execution support then runs at whatever intensity suits, commonly one or two days a week.
Interviews with operators, supervisors, maintenance and administration. Time in the weekly meetings. A read of the financials and whatever operational data exists. Then a value driver tree built from your numbers, not a template, and tested with the people who own each branch.
Every opportunity raised, mapped to a driver and sized where possible, with the assumptions written down. Ranked on value and effort. Then explicit decisions about what will not be done, which is the harder half of the exercise.
A short implementation plan covering the top items only, each with a named accountable person and a date. Then hands on support alongside your team. I am in the room for this part, not reviewing it from a distance.
Back to the value drivers on a quarterly cycle to check whether the numbers moved, and to establish why not where they did not, before anything new is added to the list.
Whether you already have an improvement function changes how an engagement should run. It changes the politics of it even more.
Where no structured improvement capability exists, or where what exists has never been designed. I architect the programme end to end: the value logic, the idea pipeline, the governance, the measures and the review rhythm, then run it with you until it holds on its own. This is the work I have done before at multi site scale.
Where a programme and a team already exist but the results are not appearing. I work with the people who own it, not around them. Usually the diagnosis turns out to be structural, and the team already suspects what it is. My job is to establish that independently and give them the weight of an outside view.
I am not a replacement for an internal improvement function and I am not interested in becoming one. If an engagement ends with your people less capable than they started, it has failed regardless of what the numbers did.
The first conversation costs nothing and usually takes half an hour. Tell me what is not working and I will tell you honestly whether it is something I can help with.