How project management can accelerate a project: 6 tips

Lessons Learned

How does a project manager help a team shave six months off a timeline while keeping executive stakeholders confident? Here’s a real scenario I faced as a program manager.

The business had signed a deal to switch data providers, on a non-negotiable deadline. We’d done a similar vendor migration before — that one took 18 months. This time we had 12, and we’d be migrating the same market-data ingestion, normalization, and API pipeline while also moving everything from on-prem to the cloud. 

Scope: two required deliverables, tackled together — a new data vendor, and a full cloud migration.

Timeline: 12 months, dictated by contract. No flexibility.

Here are the six things that made the biggest difference.

1. Count your blessings

Someone wanted to name the project “Titanic.” Another suggested “Chernobyl.” We landed on Quokka instead — a cheerful little marsupial that ended up on all our swag and presentations, and kept us grounded in the “usness of us.”

The dark humor was tempting, but what actually helped was an honest inventory of what we had going for us: a highly skilled team (strong subject matter experts, contractors who ramped fast, and genuinely excellent engineering, product, and project leadership); open, action-oriented communication with leadership, including a CTO who cleared blockers fast; and the flexibility of the cloud, which let us stand up a parallel environment instead of a risky in-place cutover, giving us room to actually test data integrity and performance. And the quokka. 

2. Surface the real risks early

Two things needed to be front and center from day one: the timeline (no single fix closes an 18-down-to-12 month gap — it has to come from many smaller wins) and the new AWS stack. I didn’t need to be the AWS expert, but as PM I needed to understand cost, risk, and how our on-prem setup mapped to it.

3. Make progress visible with real metrics

Leadership needed data, not vibes, to make good calls — and it made the team less anxious too. The core tool was the burn-up: build and size the full backlog up front, refine it every sprint, and keep “done vs. remaining vs. timeline” visible to everyone. Check out my playbook on the burn-up.

4. Adapt the process to the team

Scrum gives you guardrails, not gospel. This team hated retrospectives, so we cut them and replaced that slot with a continuous feedback loop — one less meeting a sprint, and a channel where people could raise concerns and get them addressed on the spot. Not a fit for every team, but it worked for this one.

5. Keep the operational overhead light

Everyone else on the team was busy solving the actual problem. My job was to make Jira, risk tracking, and status updates as low-friction as possible — less for them to remember, and less manual upkeep meant more accurate data.

I ran the RAID log on a “just enough” basis: the minimum anyone needed to know or act on, curated the hell out of it before every vendor and stakeholder checkin, so the time went to removing obstacles instead of managing a spreadsheet. Same logic applied to the backlog — the team shouldn’t need documentation to enter a story. If something’s needed purely for reporting and the team won’t remember to add it, the PM adds it. (AI can take a lot of this grunt work off your plate now, too — worth a try.)

6. Keep a “save it for later” list

New stakeholder asks and shortcuts we took on purpose — save it for later, like English Beat. One spreadsheet, enough detail for future us. If a request wasn’t a “must,” it went on the list.

This project took on real technical debt: a lot of lift-and-shift EC2 instances instead of cloud-native builds, chosen for speed over cost or performance. We tracked exactly what that would cost to fix and what we’d save by fixing it, so leadership could weigh the tradeoff with real numbers instead of guessing.

We delivered on time, with minimal issues. The CTO thanked us specifically for the burn-up visibility and easing his concern over our ability to deliver. The stakeholder meetings got easier with time. We got dedicated time afterward to pay down the technical debt and work through the deferred list. And everyone got a Quokka sweatshirt. Awesome.

Leave a Reply

Your email address will not be published. Required fields are marked *

Latest Ideas

Building Trust as a Technical Program Manager

Building Trust as a Technical Program Manager

Blog
September 30, 2026
Making the Right Way the Easy Way: Building a Process for Humans

Making the Right Way the Easy Way: Building a Process for Humans

Blog
September 29, 2026