Couverture de TPM Podcast with Rhea – Episode II Part III

TPM Podcast with Rhea – Episode II Part III

TPM Podcast with Rhea – Episode II Part III

Écouter gratuitement

Voir les détails

À propos de ce contenu audio

 Episode Overview In the final part of the series, Mario Gerard and Rhea Frondozo focus on what can go wrong when you are running large scale programs and what strong breadth TPMs do differently. They talk about common pitfalls like taking on too much work yourself, misusing subject matter experts, and letting scope creep sneak in through the back door. Rhea then walks through the most complex program she owned at OCI, the global government sector program, to show what large scale really looks like in practice. That example ties together everything from earlier episodes: executive sponsorship, stakeholder management, communication strategy, requirements interpretation, and the need to avoid divergence across the stack. The focus of the conversation is on: The most common pitfalls breadth TPMs need to watch out forHow to draw the line between helping and taking over someone else’s workWhen to rely on SMEs, and how to keep SME solutions aligned to business needsHow scope creep often shows up through “extra” asks attached to your programA real example: OCI’s global government sector program and why it was so complexWhat divergence means, why it matters, and how it can multiply long term complexityHow Rhea structured communication and alignment for a companywide, multi-year program The episode closes with a clear message: large scale TPM skills are learned through experience, trial, error, and repetition, not through textbook theory. Common Pitfalls Breadth TPMs Should Watch For Mario asks about the most common pitfalls. Rhea starts with one she has seen personally and also in the TPMs she has managed: functional owners leaning too heavily on the TPM to do their work. 1. Taking Ownership of Everyone Else’s Work Rhea explains that a breadth TPM is responsible for driving accountability across many functional areas. But when the TPM is a strong lead, stakeholders may try to offload problem solving onto the TPM. If you accept that pattern, you end up doing work for everyone, and because you are managing so many areas, you eventually fail. Mario agrees and describes a simple rule: do not step in and fix someone else’s problem, because once you do, it becomes your problem and they can walk away. Instead, you want POCs and functional owners to own their space, drive the work, and report milestones and progress back to you. They both emphasize that there is still nuance. Sometimes you step in briefly to get a workstream back on track, especially if the lead is weak, but you do it to stabilize and then transition ownership back. The key is that you are monitoring and guiding, not absorbing the work. 2. Poor Time Management and Not Rechecking Where You Spend It Mario shares a habit he learned at OCI: constantly reevaluate where your time is going, daily or weekly. He frames it as a discipline that keeps you from spending too much time in the wrong places, or getting sucked into details that are not actually your responsibility or do not help the long term success of the program. Rhea ties this directly to judgment. Breadth TPMs have to decide where they invest their energy: stepping in, monitoring, coaching, or escalating. Your time allocation becomes a strategic decision, not just a scheduling issue. 3. Misusing SMEs and Going Too Deep Yourself Rhea calls out another common pitfall: not knowing when to rely on a subject matter expert versus trying to do it yourself. A TPM needs to understand the problem enough to ask good questions and to evaluate whether the solution matches the business need, but it is not the TPM’s job to be the SME. Mario adds a real world tension: SMEs sometimes over engineer or overcomplicate solutions. They are deeply invested in their domain, and that depth can lead to building something far bigger than what the program needs. 4. Scope Creep Through “Riding Your Program’s Priority” Rhea connects SME behavior to scope creep. Sometimes your program surfaces a problem that affects your delivery, and you bring in an SME team to solve it. But that same team may have long standing pain points and see your program as a way to finally get buy in for a much larger fix. In other words, you ask for X, and they try to bundle X plus everything else they have wanted to do for years. Mario frames it bluntly: you need them to solve X, but they want to solve X times one hundred. Both agree that this is a real pattern in large orgs, and it is one of the fastest ways scope creeps beyond what the program was sized for. A Real Example: OCI Global Government Sector Program To make the discussion concrete, Rhea walks through the biggest and most complex program she owned at OCI: the global government sector program. She describes it as a suite of cloud regions, services, features, and processes needed to meet government customer expectations. Mario clarifies that this was not a single product. It was a set of products and operational capabilities that allowed governments to run workloads on ...
Les membres Amazon Prime bénéficient automatiquement de 2 livres audio offerts chez Audible.

Vous êtes membre Amazon Prime ?

Bénéficiez automatiquement de 2 livres audio offerts.
Bonne écoute !
    Aucun commentaire pour le moment