Nothing was broken here, because nothing existed yet. The client was setting up a
PMO ahead of the merger, and my team was there from the start, building the processes
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.
It wasn't a planned pause, either. At several points nobody knew whether the deal
would survive review at all. That's a different job from running a program with a
known end state: you're building something that might never launch, and several
hundred people still have to work on it as if it will.
Why a pause is expensive
Months passed and things changed under 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 turned up anyway in unit testing and BVT, at far higher
cost. The review avoided an estimated $2M of remediation.
Sixteen VPs and no authority over any of them
I had data. I built reporting that showed where work was stuck and whose
team it was sitting with. Nobody had that view before. The reports went up to the
CIO, and that did most of the work: once a VP knows the row with their name on it
gets read two levels up, they push each other and nobody needs chasing.
Why deployments kept missing their dates
On-time launch deployments sat around 74%. The causes weren't 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 keep up: code drop status by release, by parent initiative, and by team and
function, with links through to where the design and development artifacts
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.
Porting every report to a tool I'd never used
Mid-quarter, the client switched licensing from Tableau to Power BI and asked me
to port every report across. I'd never used Power BI, and it's different enough
from Tableau that it wasn't a straight translation. I learned it as I went and got
the reporting back up.
What I got wrong
I should have standardized intake at the start. By the time I saw that the
existing reporting wasn't good enough, and was part of why dates were missed, more
than a dozen vendor teams had each built their own ad hoc tracking, and none of it
talked to anything else. So I spent the time meeting each team one at a time and
building a translation layer from whatever they'd already committed to. If I'd set
the format before the teams built their own, none of that would have been needed.