Rebuilding a Global Delivery Model

Problem

The digital product team at Fortescue supports three platforms, the corporate website, a Sitecore Content Hub DAM, and an EDM platform, all used across global time zones. When I joined as Global Digital Product Lead, the backlog had grown past the point where anyone could see what mattered. There was a large, unranked list of live features with no clear priority order. The DevOps inbox held a substantial backlog of unresolved items with no triage process behind it. An agency was overspending against agreed scope every month, undetected until I started looking at the numbers in my first two weeks.

None of this was a single failure. It was what happens when a delivery model has no owner for long enough.

Context

I joined as the primary interface between business stakeholders, engineering teams, and multiple agencies spread across regions and time zones. The role existed because that interface had been missing. Roadmap planning sat in Monday.com. Engineering work sat in Azure DevOps. The two systems weren't connected, so a feature could be "in progress" on one and untouched on the other, and nobody would know until someone asked directly.

Business objective

Fortescue needed a digital delivery function that leadership could trust, one where spend was visible, priorities were defensible, and the roadmap reflected what was actually happening in engineering. Before any of that was possible, the backlog needed to be small enough to manage and the budget needed to stop leaking.

Customer/user objective

The stakeholders I was serving, both internal teams and the agencies delivering the work, needed a single place to check status and a shared understanding of what was actually being worked on. Refinement sessions had no fixed agenda. Requests came in without a consistent way to size or prioritise them.

Constraints

I had six weeks to secure additional budget before backend capacity became a hard blocker. The team was distributed across time zones, which limited overlap for live discussion. I was managing this through an existing agency relationship rather than bringing in new resource, so any changes had to work within that structure.

Stakeholders

Business stakeholders across regions, engineering teams, agency delivery leads, and senior leadership who needed regular visibility on spend and progress. Legal became a stakeholder later, during the Salesforce Data Cloud work, but in this first phase the priority was internal alignment between business and delivery.

Research and discovery

I spent the first two weeks doing three things at once, reading everything I could find, talking to everyone I could reach, and checking the numbers against what I was being told. The backlog audit showed a large volume of features with no consistent prioritisation logic. The DevOps inbox review showed a significant backlog of items, some months old, with no owner. The budget review showed the overspend, which took cross-referencing invoices against agreed scope to actually confirm.

Options considered

For the backlog, I considered whether to run a lighter-touch cleanup or a full rationalisation against business value. A lighter touch would have been faster but would have left the same structural problem in place within a few months. For the DevOps inbox, I considered leaving triage to individual engineers versus introducing a shared taxonomy. Individual triage was already the status quo and clearly wasn't working. For the operating model itself, I considered keeping the existing Sprint structure with adjustments, or moving to Kanban given the agency's working pattern and the volume of ad hoc requests coming in.

Prioritisation

I built a Value Type taxonomy, splitting work into Key Business Item, Bugs, Improvements, Technical Debt, and Other, each with a priority score. This gave everyone the same language for arguing about what should come next, rather than whoever shouted loudest getting their item moved up. The same logic applied across the full feature backlog, each was assessed against business value before it earned a place on the roadmap, rather than staying on by default because it had been there a while.

Delivery

I cleared the DevOps inbox down to a small, working queue in the first two weeks, working through the backlog with the taxonomy as the filter. I reduced the overall backlog by 77%, rationalising a large feature list into a roadmap that reflected actual business priority rather than accumulated requests. I redesigned the refinement meeting agenda from scratch and moved the team from a Sprint to a Kanban model with the agency, to enable better flexibility due to fast changing business priorities, which better matched the pace and shape of incoming work. I connected the Monday.com roadmap to Azure DevOps so that roadmap and delivery status showed the same picture for the first time.

On budget, I identified the root cause of the agency overspend and resolved it, then made the case for additional investment. Within six weeks of joining, I secured a significant increase in backend development capacity.

Separately, when the agency went through redundancies over the Christmas period and delivery coordination wasn't handed over, I stepped in to cover that ground myself for two months, running ceremonies, coordinating releases, and keeping delivery moving. Releases were restored within two weeks of the gap opening up.

I also proposed a federated development model, moving from a single lead agency to multiple agencies, as a longer-term recommendation to reduce dependency risk. And I set up a new team SharePoint to give the documentation a proper home, since before that it was scattered across individual drives and email threads.

Decisions made

The most consequential decision was sequencing, fix the operating model before touching the roadmap. It would have been tempting to jump straight into feature delivery to show quick progress, but a roadmap built on top of a broken backlog and an unmonitored budget would only have created a bigger mess to unpick later. The Value Type taxonomy was a deliberate choice to make prioritisation visible and repeatable, rather than something that lived in my head. Moving to Kanban was a decision to match process to reality rather than force reality to fit a Sprint structure that wasn't working for this team.

Trade-offs

Spending the first weeks on audit and triage rather than visible feature delivery meant slower initial output, and that was a deliberate trade against building on unstable foundations. Covering delivery coordination during the Christmas gap, after the agency went through redundancies and coordination wasn't handed over, meant my own priorities got deprioritised for two months. Recommending a federated agency model was the right long-term call but meant accepting more coordination complexity in exchange for reduced single-agency risk.

Business outcome

The backlog is 77% smaller and built on a value-led roadmap instead of an accumulated list. The DevOps inbox is a working queue instead of a backlog of its own. The inherited overspend is resolved, and backend development capacity increased significantly within six weeks of me raising it. Roadmap and delivery now show the same status in real time, because Monday.com and Azure DevOps are connected.

Customer outcome

Stakeholders and agency teams now work from one roadmap and one prioritisation framework, instead of each interpreting priority differently. Refinement sessions run to a fixed agenda instead of being reactive. When the agency's redundancies left delivery coordination gapped unexpectedly, releases continued with only a short gap, so the disruption to people relying on the platform was minimal.

Lessons learned

An overspend that's gone unnoticed for a while usually means nobody owns budget reconciliation as a regular task, not that anyone was being deliberately careless. Backlogs grow when there's no consistent framework to say no to things, so the fix has to be a framework, not a one-off clear-out. And operational continuity, like covering a Scrum Master role with no notice, matters more to stakeholders in the moment than any roadmap progress does. Most of the 77% reduction was consolidation and reprioritisation rather than outright deletion, work that stopped competing for sprint capacity rather than being scrapped.

What I'd improve today

I'd build the case for the federated agency model sooner, since single-agency dependency was a risk from day one, not something that only became visible after the agency's redundancies over Christmas.