Case studies

Cost & forecasting Making a cost number travel, and arrive in time to matter

Service operations · method

Unit cost used to arrive from finance late in the year, when the only lever left was people. It became a number three functions signed and saw every month.

A gap you can see in January is a plan. The same gap in October is a headcount cut.

How it went, and what I got wrong

Before

An $18M cost-of-revenue target, and only about half the initiatives under it had impact anyone had quantified. The rest were sized by assertion. Forecasts drove hiring, hiring drove cost, and the cost reporting arrived from finance late enough in the year that the only lever left was headcount. Engineering and operations barely spoke, even though operators depended on engineering delivery to hit their numbers.

One number everyone signs

Operators size their own initiatives in their own metrics. Workforce management turns that into FTE, and finance turns FTE into unit cost against the annual goal. Every handoff gets cross-examined and signed, including by engineering where delivery is a dependency, so nothing enters the chain unowned.

Coverage of quantified impact went from 54% to 100% inside two weeks, and the cadence holding it up, weekly execution pulses with monthly forecast and workforce-model locks, was running in seven days.

What I got wrong

I built the complete version first and the one-screen version second, which is backwards. A number a decision-maker cannot hold in their head does not travel however correct it is, and correctness was the part I found interesting. I got to the summary late, and by then people had already decided the whole thing was heavy.

Program governance Building a PMO for a deal that had not closed yet

Accenture · $26.5B telecom merger · 2018 – 2020

Several hundred people kept building through months of regulatory hold, on a deal that might not have survived review at all.

The review paid for itself on drift that nobody introduced: the designs were right when they were written, and the pause is what made them wrong.

How it went, and what I got wrong

Nothing was broken here. Nothing existed yet. The client was standing up a PMO ahead of the merger and my team was on the ground floor, building the machinery that the next five years of integration work would run on.

What the deal did to the work

Terms were renegotiated several times with the FCC, the DOJ and the businesses, and the whole program sat on hold for months. Until approval, there was a hard legal limit on what teams could do: design, build and test against synthetic data, never production data from the other party. Once initiatives had gone as far as the law allowed, engineers and PMs were reallocated across the wider Product and Technology org, and the designs sat.

And it was not a scheduled pause. At several points it was genuinely unclear whether the deal would survive review at all, which is a different job from running a program with a known end state. You are building something that might never launch, and several hundred people still have to work on it like it will.

Why a pause is expensive

Months passed and the world moved underneath the designs. A call to an API that had since been deprecated. A data feed from a vendor team that had been repurposed. So before anyone restarted, the designs went back through a joint architecture review board: 52 projects reassessed over three months, high and low level designs re-checked against what was now true, with more than 150 project managers, senior managers, directors and architects pulled through it.

Those flaws would have surfaced anyway, in unit testing and BVT, at far higher cost. An estimated $2M of remediation avoided. These are easy to spot in a design review and expensive to find in testing.

Sixteen VPs and no authority over any of them

Data. I built the reporting that showed where work was actually stuck and whose team it was sitting on. Nobody had that view before. Those reports went up to the CIO, and that is what did the work: once a VP knows the row with their name on it is read two levels above them, they push each other and nobody has to be chased.

Why deployments kept missing their dates

On-time launch deployments sat around 74%. The causes were not technical. Teams were miscommunicating, documentation was wrong, and every team tracked milestones its own way. More than a dozen vendor teams were on the program and none of their tracking was standardized, so there was no way to see real status without asking each of them and taking the answer on faith.

That gap is why I learned SQL and built automated reporting in Tableau. With dozens of teams updating constantly, a near real-time view was the only thing that would hold: code drop status by release, by parent initiative, and by team and function, with links through to where the design and development artifacts actually lived in Jira.

On top of the view I put a standardized process with defined acceptance gates, each one requiring sign-off from the teams a drop affected, and used the report as the source of truth teams aligned against. On-time deployments went from 74% to over 95% in under three months.

Every report, ported to a tool I had never used

Mid-quarter, the client switched licensing from Tableau to Power BI and asked me to port every report across. I had never used Power BI, and it is different enough from Tableau in both capability and interface that it was not a translation job. I learned it on the fly and got the reporting back up.

What I got wrong

I should have standardized intake at the start. By the time I could see that the existing reporting was insufficient and was itself enabling the misses, more than a dozen vendor teams had each built their own ad hoc tracking and none of it talked to anything else. The job stopped being defining a standard and became meeting each team one at a time and building a translation layer back from whatever they had already committed to. None of that would have been necessary if I had set the format before the teams built their own.

Go to market Making an opportunity sellable

Google · publisher partnerships

Sellers already had the list. What they could not do was tell a publisher what it was worth, so it kept losing to pitches that arrived with a number.

Until the number existed, sellers were arguing about a figure nobody had produced.

How it went, and what I got wrong

Sellers already had the list. That was never the constraint. What they could not do was tell a publisher what the opportunity was worth, so it kept losing to pitches that arrived with a number attached.

Measure it, do not argue it

Impact Experiments, the incrementality framework inside Ad Manager 360, produced a measured figure per publisher rather than an estimate. A publisher will argue with a projection. They will not argue with their own incrementality result.

Between the people who had the evidence and the people who needed it

The measurement sat with product and pGTM. The publisher relationships sat with sales. Neither group was going to build the other's artifact, so pGTM asked me to build it. I ran the publisher meetings, took what came out of them back to product, and built the case study jointly with them, so it carried product's evidence in language a seller could put straight into a pitch. Sales stopped having to translate it, and started opening conversations they had been skipping.

One number, three places it had never been

Into the internal performance view, so sellers could finally book credit for the work. Into the client conversation, as a figure a publisher would accept. And onto a leaderboard, because I built the custom CRM and product views that did not exist and turned pitching it into a contest.

I timed the launch to the week the case study cleared legal and client review, so sellers got the proof they had been asking for and a reason to use it in the same week. Pipeline movement on that opportunity ran 256% against prior quarters.

What I got wrong

I pointed the queries at AMS, the region I managed, because that was the problem in front of me. Within days of release, EMEA and APAC asked for their own versions. Repointing a query from one region to global is a small change and I made it quickly. What I had not planned for was validation. I had no data access outside my own region, and for data this sensitive the access review is long, so two regions ran on output I could not check until it cleared. It held up. I was not in a position to confirm that at the time.