Mullings Management
Case Studies

The method,
visible in the work.

Delivery functions rebuilt from the inside, with the methodology visible in the work. Two of these engagements were client side, two were agency side.

01
Case study
Client side

Unblocking a stalled build in a month.

A high-profile UK consumer website, delivered by an in-house digital team

  1. 01 Diagnosed firstPeople

    Delivery leadership sat with no delivery background

  2. 02 Diagnosed secondCulture

    Content, design and build worked as three groups

  3. 03 Diagnosed thirdProcess

    Blocked, with no route to a delivery date

Blocked, no datebecameDelivered
The site was not late because the work was slow. It was late because a set of decisions had nobody to make them.
The situation

A national consumer website with a rebuild that had stopped moving. Not slipping. Stopped. There was no delivery date, and no route to one.

The work was being done in-house, by an established digital team inside a large corporate business.

What I found

Nobody owned the decision

People

I started with the team, not with leadership. Direct questions, asked of the people doing the work, about what was actually stopping them. Ask leadership first and you tend to get the account the organization has agreed to tell itself. Ask the team first and you get the blockage.

Delivery leadership had been placed with someone the business had not equipped for the role. That is a common finding and it is rarely anyone's fault at the individual level. It is what happens when an organization grows a digital function faster than it grows the capability to run one.

The consequence is specific and it is structural. When the person accountable for delivery has not delivered before, the calls that only they can make do not get made. The work does not stop because anyone refuses. It stops because nobody says yes.

Three groups, not one team

Culture

Content, design and development barely spoke to each other. They were three functions occupying the same programme, not a team delivering one product.

The team was demotivated, which is what happens to capable people who keep arriving at a decision point and finding nobody there.

That is a cultural finding, not a process one. No amount of governance fixes a programme where the three groups who must agree have no habit of talking.

The build was not slow, it was waiting

Process

The root of the block was a set of design and content decisions that nobody would make. Every one of them sat between two of the three groups, and none of the three had the standing to settle it alone.

Once those decisions were unmade, everything downstream of them was unbuildable. That is why there was no delivery date. A date requires a route, and the route ran through decisions that had no owner.

The first move

The first changes were for the team, and they were physical.

  • I sat the digital team together. Content, design and development in one space. The three groups stopped being three groups the moment they could hear each other.
  • I put a Kanban wall up in the corporate office. Not a tool, a wall. The work became visible to the team, and to everyone in the business who walked past it.
  • I set out the evidence. Which decisions were blocking the build, what each one was holding up, and who needed to make it. A decision with a name against it, and a visible cost to leaving it open, stops being deferred.

None of that benefited management first. It cost the business the ability to leave a decision unmade indefinitely.

What changed

With the decisions settled, a route to delivery existed for the first time, and a roadmap could be written against it. That roadmap had not been possible before, because a roadmap built on unmade decisions is a work of fiction.

One month from arriving, the programme was unblocked and had a delivery plan. The site went live.

What this engagement shows

This is the case where the three layers form a chain rather than three separate findings.

Delivery leadership without a delivery background means nobody owns the calls. Three functions working separately means none of them can force a decision between themselves. So the decisions sat unmade, and unmade decisions were what blocked the build.

Process was the symptom. It was the last thing diagnosed and the last thing fixed, and fixing it directly would have achieved nothing, because the block was never in the process.

A blurred wide shot of a team gathered informally around a desk for a standup, taken from the back of the room.
The team, in the room, once there was a reason to be
02
Case study
Agency side

The document I refused to write.

A client-side delivery function, rebuilt from the inside. Contracted through the agency that served it.

  1. 01 Diagnosed firstPeople

    Capable people, no shared account of how delivery worked

  2. 02 Diagnosed secondCulture

    The loudest voices took the room, the people who knew said little

  3. 03 Diagnosed thirdProcess

    No delivery system at all, work moved on memory and relationships

Engagement length
3.5 months
Engagement length
Backlog cut in the same period
50%
Backlog cut in the same period
Team members on the new system
20+
Team members on the new system
Further resource commissioned
£30k+
Further resource commissioned
One person half raised a finger, then lowered it. Nobody in the room could answer.
The full account
The situation

I was contracted by an agency to produce a document. A PDF setting out a new project management process for their client, written and handed over.

I told them it could not be done. You cannot change a process you have no visibility into. Writing a process document for a function nobody has observed produces a document, not a change.

I asked for three days on site with the client instead, and a first week spent on interviews, group and individual.

The engagement ran three and a half months, and the work was client-side throughout. The agency held the contract. The delivery function belonged to the client, and so did the team of more than twenty people running it.

The work was arriving. The team was capable. Delivery was not holding.

What I found

The diagnostic order does not vary. People first, then culture, then process. Running it in that order is what produces a picture that holds.

What nobody could answer

People

The first week was interviews. Group first, then individuals.

My opening question in the first group session was simple. How do you deliver projects here?

One person half raised a finger, then lowered it. Nobody in the room could answer.

That is the finding. Not that the process was wrong, that there was no shared account of it. Capable people, each carrying a version of the work in their own head, none of it written down, none of it visible to anyone else.

The individual interviews gave the rest of the picture. What the group session could not surface, the private conversations did.

Influence and expertise were in different places. The UX and engineering teams held the knowledge about what should be built and why. They did not hold the floor. Direction arrived from senior management as ideas, not as briefs backed by research or data, and it arrived without a route to challenge it.

The people best placed to say "the data does not support this" were the people least able to say it.

That is where the leadership misalignment was landing. Not as a strategic disagreement at the top, but as a team being asked repeatedly to build things they had good reason to believe were wrong, with no mechanism for saying so.

The room where speaking was a contest

Culture

The team did not huddle. There was no regular cadence of meetings about the work. Meetings happened when management had an idea, or when a build or a fix demanded one.

When the team was in a room together, the loudest voices took it. I watched this in their own meetings. The people who spoke were frequently not the people who knew, and the people who knew said very little.

Both of those are cultural facts rather than process ones. A calendar cannot fix a room where speaking is a contest.

There was no system at all

Process

There was no delivery system. Not a broken one, none. Work moved through the function on individual relationships and personal memory rather than through anything documented, repeatable, or visible.

That is a more common finding than it sounds, and it is rarely the first thing anyone reports. A team without a system does not describe itself that way. It describes itself as busy.

With the full picture from the interviews, the actual process could be mapped. Not the process as anyone would have described it in a document, the one the work was really moving through.

The PDF I had originally been asked to write would have described a process that did not exist.

The first move

Quick wins are not optional and they are not decoration. A team that has been let down before gives one window of willingness, and it stays open only as long as they can see something changing that benefits them. A quick win that serves leadership optics and not the team is worse than none at all.

The first changes were cultural, and they were for the team.

  • Morning scrums. Fifteen minutes, timeboxed, the whole team standing around a screen. Every day.
  • A football. Nobody spoke unless they were holding it. That single rule ended the contest for the floor. The people with the expertise got to finish a sentence, which many of them had not been doing in meetings for a long time.
  • A physical Kanban wall in the office. Not a tool, a wall. The work became visible to everyone in the room, including the people upstairs who walked past it.
  • A weekly planning cadence, so the team knew when decisions would be made rather than waiting to be interrupted by them.
  • A product manager, introduced to coordinate these sessions and make sure the right people were talking at the right point.

None of this benefited management. It cost them the ability to interrupt at will. It gave the team a structure where the person who knew the answer could say it out loud.

That is what opened the window.

What changed

A bespoke delivery system, built from nothing, in three and a half months. Not adopted from a framework and imposed, built around how this team actually worked.

Four things came out of the engagement:

A delivery system the team could run

Simple enough to be used, structured enough to hold. Adopted across the full team of twenty plus.

A test-and-learn framework

A way for the function to try something, measure it, and keep or discard it without escalating every decision upward.

This is the change that mattered most to the team, and it is worth being precise about why. Before it existed, work arrived as an idea from senior management and there was no legitimate way to question it. After it existed, proposals were tested and decisions were made against what the data showed. The same senior managers were still in the building. What changed is that "I think" stopped being sufficient grounds to commit engineering time.

The frustration in the UX and engineering teams did not reduce because people became more reasonable. It reduced because there was finally a mechanism through which being right could matter.

A skills gap analysis

A documented map of the capability the function had against the capability the work required.

A business case for restructuring

The gap analysis turned into an evidence-backed argument that could survive an executive forum, rather than an opinion that could be dismissed as one.

The backlog was cut by fifty percent inside the same period.

Staff were trained at every level. Not a handover document, actual training, so the system had people who could operate it after I left.

What it produced beyond the brief

By the end of the engagement the senior leadership team had enough confidence in the function to commission more than thirty thousand pounds of additional agency resource.

That number is worth reading correctly. It is not a delivery metric. It is a trust metric. Leadership does not increase investment in a function it has stopped believing in. The additional resource was the measurable form of a judgement that had changed.

What I left behind

Once I was confident the system worked, because I had been delivering inside it myself, I began transitioning it to the person taking over my position.

Not a handover document. Coaching. How to run it as it stood, and how to develop it, because it had been built to scale and she needed to know that she was allowed to build on it.

What she inherited was a capability, not an instruction manual. Something simple, repeatable and scalable that could grow with the function rather than constrain it.

The goal of every engagement is a self-managing function. If an organization still needs me when I leave, the engagement has failed.

A note on where this method came from

This engagement is where Change From The Inside™ was first formally defined. The sequence had been used before. This is where it was written down, tested against a function that had no system at all, and proved out.

A physical Kanban wall marked out with tape on a plain office wall, columns for sprint, UX, design, front end, fixture, content and sign off.
The wall that made the work visible to everyone who walked past it
03
Case study
Agency side

Rebuilding a delivery function remotely.

A London creative agency, during COVID, in transition to an audio-focused digital department

  1. 01 Diagnosed firstPeople

    A capable team with no leader, held by a freelance holding position

  2. 02 Diagnosed secondCulture

    Established and healthy, nothing here needed intervention

  3. 03 Diagnosed thirdProcess

    A working system that needed tightening and rebuilding for a changing business

Engagement length
3 months
Engagement length
Production efficiency gain
25%
Production efficiency gain
Remote delivery
100%
Remote delivery
Incoming leader onboarded
1
Incoming leader onboarded
A team without a leader does not report itself as leaderless. It reports itself as coping.
The full account
The situation

A digital department inside a creative agency, working for a global audio production client. The team had lost its head of project management. The function was being held together by someone working on a freelance basis.

The business was also mid-transition, moving away from traditional agency work toward an audio-focused digital department. The delivery function had to work now and still work after the business had finished changing shape.

Fully remote. Nobody had an office to fall back on.

I came in as Head of Project Management, leading several teams to work together.

What I found

The diagnostic order does not change because the answer is likely to be different. It is run in full every time, and that is the point.

A team without a leader

People

The team was good. Capable, experienced, and doing the work properly. What they did not have was a leader. The function was being run by someone on a freelance basis, which is a holding position, not a structure.

That is a People finding, and it is one that delivery functions normalize quickly. A team without a leader does not report itself as leaderless. It reports itself as coping.

Nothing here needed fixing

Culture

Established, and healthy. Collaborative, no silence problem, no contest for the floor. There was nothing here that needed intervention, which is worth stating plainly because it is not what an outside practitioner is expected to conclude.

This is where the work was

Process

This is where the work was. A system existed and it functioned. What it needed was tightening, efficiencies, and rebuilding for a business that was in the middle of changing what it did.

The first move

Filling the gap. The team needed a leader more than it needed a diagnosis, and no process work would have held without one.

Everything after that was process, because the assessment said so.

What changed

The delivery system was rebuilt around how the department actually worked. Not replaced, rebuilt. What was inherited and working was kept and sharpened. What was creating friction was changed.

The output was a delivery playbook covering the full operating picture of the function:

  • Board architecture and the day-to-day flow of work through every department
  • Workflows for each product the department delivered, end to end
  • An estimation protocol, with the standing rules for how work was priced
  • Resource management and capacity planning
  • Freelance sourcing, interviews, and cost approval
  • Quality assurance, including external QA sourcing
  • A meeting cadence with defined agendas, from daily stand-ups to weekly retrospectives
  • Reporting and time tracking
  • Finance and invoicing routes

It was built to be simple, repeatable, and scalable, and to remain fit for purpose through the transition rather than only at the point it was written.

Production efficiency improved by twenty five percent over the three months.

What I left behind

An incoming leader, onboarded personally, and the playbook handed to them directly.

The document was live rather than static. It linked out to the boards, templates, and working documents in active use, so it stayed accurate as the function moved rather than describing a moment that had passed.

Separate handover material covering live client accounts, the innovation roadmap, product development, and transition planning was provided to the incoming leader alongside it.

What this engagement shows

This is the case where the methodology returned a different answer.

People and culture were healthy. Process was the work. A practitioner who arrives already knowing that the problem is cultural will find culture, every time, whether or not it is there.

The order is a diagnostic sequence, not a prediction. It is run to find out, not to confirm. That the answer here was process is what makes the answer at other engagements worth anything.

It also worked entirely remotely, with a team that had never operated any other way.

A planning wall of green and blue sticky notes organized by week, mapping tasks and deliverables across a multi-week engagement.
Delivery mapped week by week, in the open
Shorter engagements

Not every problem needs three months.

Some need an accurate picture and a clear recommendation, which is what a six week Assessment produces.

Sourcing a delivery partner
Client side
A UK creative industries organization

The organization needed a digital delivery partner and did not have one. Finding the right partner is usually treated as a procurement exercise. It is a diagnostic one. The question is not who is available, it is what this organization actually needs from a partner, which requires understanding how it works before you go looking.

A new digital partner was sourced and secured within a month. The relationship ran for more than three years.

Longevity is the outcome that matters here. A partner selected against a poor understanding of the client does not last three years.

Selected clients

Listed here as environments, not as attribution for the outcomes above.

  • Camelot
  • Sobeys
  • BBC
  • Nestlé
  • Nestlé Purina
  • AXA
  • McCann
  • Havas Media
  • Razorfish
  • Tribal Worldwide
  • Grey Healthcare Group
  • Hogarth Worldwide
  • Forever Audio
  • GALE
  • Ogilvy
Next step

See where your own
delivery function sits.

The delivery check takes two minutes. No email required to see your band and per-question breakdown.

Take the two-minute delivery check→Or book a 30-minute conversation