TPM Podcast with Rhea – Episode II Part II

Episode Overview and Summary

In part two of the series, Mario Gerard and Rhea Frondozo continue the conversation on how TPMs run large scale programs. This episode gets more practical, focusing on how to build a communication plan, what kinds of blockers show up during execution, how you track information across huge programs, and what the TPM team structure often looks like.

The focus of the conversation is on:

• How to design a communication plan for a large-scale program
• How communication cadence changes as the program evolves
• Common blockers: schedule delays, requirements issues, architecture problems, scope creep
• Prioritization and resourcing trade-offs across competing initiatives
• Finding the right owners and solving unclear ownership problems
• How to maintain program information using tools, dashboards, and centralized sources of truth
• How large programs are staffed, including lead TPMs, workstreams, and supporting TPMs
• The phases of a large program, from planning to execution to support and closeout

Overall, the episode explains that large programs are won or lost through structured communication, disciplined scope and prioritization, and a TPM’s ability to keep recalibrating as reality shifts.

Designing a Communication Plan

Rhea explains that a communication plan is really a set of decisions about who needs information, how often they need it, what level of detail they need, why they need it, and how you deliver it. The mistake is treating communication as one size fits all.

She breaks it down by audience:

• Executives typically need concise summaries, usually via a short report, email, or executive status meeting
• POCs and active stakeholders need working sessions and status meetings where you can unblock issues and track progress
• Broader groups who are impacted later may need lightweight updates, like a newsletter, so requests do not come out of nowhere

Mario adds that, in practice, a central tracking page can help a lot. He describes using something like a Confluence page to capture the objective, mission, risks, deliverables, milestones, and owners, often in a table format where teams can quickly see status by red, yellow, or green.

Cadence Changes as the Program Evolves

A big point in this episode is that communication cadence should not stay fixed. Rhea explains that early in a program, you may spend more time with executive sponsors to get buy in. Later, once you are in execution mode, the center of gravity shifts toward the POCs doing the work.

Sometimes cadence becomes extremely intense. If there is a major issue, teams may run daily war rooms to get all hands on deck. But Rhea also points out the danger of overdoing it. If you keep daily meetings running after the problem is solved, you burn people out and waste time. The TPM has to keep reevaluating what is needed and adjust accordingly.

Common Blockers in Execution

Mario asks what kinds of blockers show up most often. Rhea groups them into a few common categories.

1. Schedule Delays

Rhea says schedule delays are one of the most common blockers. They can come from underestimation, external dependencies, or simply discovering that the original plan does not work. She also notes that engineers often underestimate timelines, which is why TPMs should ask for confidence levels, clarify risks, and build buffers.

She gives examples of schedule drivers that are out of the team’s direct control, like supply chain timing for hardware deliveries, or depending on external reviews like accreditations or audits.

2. Misinterpreted or Changing Requirements

Another major blocker is realizing the requirements were wrong or misunderstood. Rhea frames this as an area where failing fast matters. If the team built against the wrong requirements, you have to regroup, redo work, and reset expectations.

3. Technical and Architectural Mistakes

They talk about how expensive architectural mistakes can become at scale. Mario points out that when a decision affects dozens of teams, the cost of being wrong multiplies quickly. Rhea shares a striking example where a cloud region was built and later found to be built incorrectly, forcing the team to rebuild the region and discard much of the earlier work. The takeaway is not that mistakes never happen, but that large programs operate in uncharted territory where assumptions get tested in real life.

4. Scope Creep

Mario raises scope creep as a common issue. Once a large program is visible, other groups try to attach additional asks to it. Rhea agrees and explains that scope creep creates resourcing gaps because the program was originally sized for a different set of commitments. If you accept more scope without adding capacity, you get delays, missed deliveries, and a loss of credibility. She emphasizes that TPM judgment is critical in deciding what truly belongs in the program.

5. Prioritization and Resource Trade Offs

Rhea explains that large programs often fight for the same people as other business critical initiatives. When timelines slip, new conflicts appear. You may have planned to finish by date X, but delays push you into the window of another project that was supposed to start next. The TPM’s job is to make the trade offs explicit, translate them into business impact, and help leadership decide whether to stay the course, shift resources, or accept a schedule extension.

Mario describes an exercise he has used with leadership: teams estimate how many resources they would need, and then they also identify what will be bumped off their current commitments if those resources are redirected. That trade off list is taken to senior executives so they can explicitly sign off on the sacrifice being made.

6. Finding the Right Owner

Another blocker is ownership. Rhea explains that new problems emerge during execution and it can be unclear who should own them. Teams may already be overloaded, or they may argue that the problem does not belong to them. Sometimes the right owner is not even on the original stakeholder list.

Mario shares that he has seen cases where the current stakeholder group could not solve the problem at all, which forced the team to look outside the original circle. They describe a discovery approach where the TPM talks to many parts of the organization to find the right home for the work. Rhea compares TPMs to detectives who go door to door until they find the right owner and get buy in.

They also note an added layer of complexity: sometimes a group may be the correct owner in theory, but they do not have the capability or capacity to solve it. In that case, the TPM needs to help set the owner up for success by clarifying expectations, securing the right staffing, and reinforcing why the work matters to the overall program.

What to Do When a Critical Team Is Not Delivering

Mario asks what you do when a stakeholder is not carrying their weight and they own a critical function. Rhea describes it as a structured diagnosis. You look for the underlying cause before jumping to conclusions.

• Is it a prioritization problem because they are pulled into other work?
• Is it a resourcing problem because the team is understaffed?
• Is it a skill problem because the wrong level of engineers was assigned?
• Is it actually the wrong owner because the work is not in their wheelhouse?

The key is that the TPM cannot ignore the gap. If a critical owner fails, the whole program suffers, and the TPM is still accountable for the outcome.

How Program Information Gets Managed at Scale

Rhea explains that managing information in large programs requires tools and structure. She mentions wikis or Confluence pages, ticketing systems like JIRA, and internal tools used at Salesforce. She also calls out dashboards and visualizations that show progress and highlight what is in jeopardy.

A recurring theme is having a centralized starting point. There should be a clear place where anyone can begin to find program information, and from there different audiences can access what they need. Executives should know where to find executive summaries. POCs should know where to post updates and track action items. People who are not directly involved should still be able to find basic context without hunting through meetings.

They also discuss how this varies by company culture. Rhea contrasts environments where leaders prefer polished PowerPoints with environments where leaders expect detailed written narratives and tables. Mario adds that even within the same company, the best format can change depending on the program and the number of teams involved. The consistent point is that you have to adjust the mechanism to match what leadership and stakeholders actually use.

TPM Team Structure for Large Programs

Rhea explains that large programs rarely run with a single TPM doing everything. The setup varies, but usually there is a lead TPM and supporting TPMs aligned to workstreams or functional areas. In some cases, the lead TPM manages a team of TPMs and assigns sub projects. In other cases, a breadth TPM leads while functional areas bring their own depth TPMs to execute within their domains.

Mario adds that the structure often evolves. Programs may start with one or two TPMs, then add more as complexity becomes clearer. As new workstreams emerge, teams staff TPMs to own those streams so execution can move in parallel while still rolling up into a single program view.

Frameworks and Phases of Large Programs

Rhea outlines a simple phase model: planning, execution, support or maintenance, and closeout. The tools and frameworks change based on the phase you are in.

Planning

• Define the problem statement and the objective
• Run cost benefit analysis and weigh options and trade offs
• Build project plans, schedules, and Gantt charts

Execution

• Run status meetings and produce status reports and executive summaries
• Track risks and mitigation plans through risk registers or similar mechanisms
• Use dashboards, tickets, newsletters, and other tools to visualize progress

Support or Maintenance

• Assess what worked, what is missing, and what needs follow up investment
• Prioritize issues and decide whether to extend, rearchitect, or create a new version
• Decide whether to close out the current program and replace it with a new one

Closeout

• Finalize delivery, document outcomes, and transition ownership as needed

How Long Large Programs Really Take

Mario asks about timeframes, and Rhea explains that large programs can take a long time just to plan. Planning might take anywhere from a few months to a year, especially when the investment is massive and requires very senior executive approval.

They also describe how execution can stretch for years. Rhea shares an example of building a net new cloud region that took a year and a half before reaching accreditation, and then required major rework when validation revealed gaps. That added significant time and effort. They reinforce that when hundreds of people and many teams are involved, long timelines are normal.

Even after delivery, the program continues in a support and maintenance mode, where teams respond to real world usage, missing features, and new investments. In some cases, if the outcome is not strong enough, the decision may be to shut down and start again with a replacement program.

Career Impact and Visibility

Mario and Rhea close by discussing why people take on these programs even though they are hard. These programs come with high visibility, late nights, real risk, and intense expectations, but they can also be career making. Success in a major initiative can lead to promotions and faster growth.

They also make the point that failure is visible too. In critical projects, if a TPM is consistently ineffective, leadership will notice quickly. Mistakes can happen if you learn and correct, but repeated ineffectiveness is not tolerated because the business impact is too high.

Full Transcript of the Episode

Mario Gerard: Hello, and welcome to the TPM podcast with your host, Mario Gerard. This is part two of the second series with Rhea, where we are talking about how you run L scale programs. If you haven’t listened to part one of how you run large-scale programs, definitely check it out before you start this particular podcast, because this is a continuation of that. Hope you enjoy it. See you on the other side. Bye.

One of the things to keep in mind when we design how we communicate in a log scale program. So, we spoke a lot about communication. But how do you design a communication plan for a large-scale program.

Rhea Frondozo: So, you know, I think what it comes down to is making sure that you understand who you need to communicate with at what frequency at what level of communication, for what purpose and using what mechanism. So that’s a lot of things I just said, right? But let’s break that down. You’re going to have a variety of different stakeholders who are going to need different levels of communication at different frequencies.

So, if you, for example, are communicating with executives, you’re going to need to be able to produce, you know, very concise executive summaries. Maybe it’s going to be in a report or maybe it’s going to be an executive status meeting, and it’s going to be at whatever frequency that they feel that they need to be informed at, versus when you are actually managing the program with people who are say, POCs, the point of context, you’re going to be wanting to have maybe status meetings where you’re working through issues that they bring up.

Maybe you’re going to have a program tracking page where you’re tracking the different, you know, initiatives that teams are working on. And you have a way that you can gather the variety of statuses that they bring to the table and risks that they bring to the table that you can discuss as a team. Or maybe there are people who just need to be informed, and they’re not maybe working on the project, but maybe you want something like a newsletter where you’re keeping people informed on a regular basis of what’s happening with your program.

Should they, you know, have an ask that comes to them later, they’re not in the dark about why this is coming.

So, there’s definitely a lot of different potential for communication mechanisms, through emails, newsletters, status meetings, Wiki pages. It really just comes down to making an assessment of, like I said, who needs to know what, when and how do you deliver that.

Mario Gerard: Yeah, I think it’s a very complex, you know, we’ve tried to do it with some, some kind of confluence pages, which has the objective, the mission, the risks that we are going through right now and all the deliverables and milestones and the people who are responsible. So, it’s kind of a table which shows who has what milestones hit when they’re going to hit those milestones. Are they red, green, or yellow for those milestones?

So, somebody can take a look at it at one view and see like, you know, where we are in those plans. And I think cadence is really important in all of these things. So, you have executor level meetings where you’re just giving them status or you’re sending it to them via email. Then you have different levels of meetings with different types of stakeholders across the board. So, it’s kind of important for you to design that and to recalibrate it.

Rhea Frondozo: Right, right.

Mario Gerard: You have to recalibrate.

Rhea Frondozo: Right. Cause I think one of the things to mention is that depending on what stage you are in a program, the frequency of communication to your stakeholders can change. In the beginning you may spend a lot of time talking to your executive sponsors or the leadership to try and get buy-in. And at that point, maybe you’re, haven’t even engaged with POCs yet, but once the project goes into execution mode, maybe you’re working, you know, on a weekly or even biweekly basis with the POCs working through issues as they arise.

Yeah. Sometimes you end up even in daily cadences, you know. People will have what we call war rooms. If there’s a big problem at hand that, you know, you need all hands-on deck to work on. Maybe you’re pulling in people on a daily basis, but you also don’t want to have to keep everybody on a daily basis because you may do that unnecessarily and burn people out or you may finally solve the problem and not need that.

And so, it’s really important as the TPM to constantly evaluate what communication do you need reevaluate. Do you still need that and make adjustments accordingly depending on how the program’s going?

Mario Gerard: Yeah. That makes perfect sense. The next question I have is what are the type of blockers that one comes across when you’re executing these kinds of large programs?

Rhea Frondozo: So, there’s a lot of different kind of blockers that you may run into, but I think that you can categorize them in a couple different ways. So, I think one really basic one that you often hear about are going to be scheduled delays, you know, for one reason or another, it could be somebody underestimated how long it was going to take to complete something. I mean, engineers and developers are notorious, I’d say for underestimating, how long it takes them to complete something.

And as a program manager, you typically know that you should ask for confidence levels or understand, you know, what the associated risks are and include buffers. Nothing is ever as easy as we think it will be. And if you think something’s going to be hard, it’s probably even harder than you think. Other issues that can cause scheduled delays could be things that are out of your control, whether it’s things like external dependencies that you’re counting on, like supply chains, you know, expecting hardware deliveries at a certain time, or maybe you have creditors that you’re expecting to get scheduled for looking at the products that you’ve built and assessing your clients.

Other things I could call it, scheduling delays, or just maybe you thought that you knew a solution to a problem, and it turns out you were wrong, and you have to redo it. And that can cause a scheduling delay. So, there’s a multitude of things that can cause scheduling delays. You know, other things that I’ve seen can be, you know, a misinterpretation of requirements.

A lot of times you’re trying to move fast and move in an agile approach for service delivery. But sometimes what you find out is the requirements that you thought that you were working against were actually wrong. And this is where it becomes important to fail fast and figuring out if you’ve done it wrong and redoing it can be another reason why your program is blocked, and you need to reset expectations on how to regroup on a program and come up with a solution that meets the expected requirements.

Another one I think that I mentioned, you know, like I said, technical or architectural challenges, sometimes we make the wrong assumptions for how we were going to solve a problem. And these are things that when you’re working on a problem, that’s in a space that is unchartered territory. You may be trying things for the first time and realizing that your assumptions were wrong, and you’ve got to restart or redo it.

Mario Gerard: And when you think about it as a scale at which we are operating, I think it becomes increasingly difficult. When you think about like the architectural solution that we came up with, which impacts I think like say 50 teams need to go do the particular thing, they go do it and then it doesn’t actually work.

Rhea Frondozo: Yeah. I mean, I actually have seen this happen at some of the most expensive levels I could have ever imagined where, you know, we built a whole cloud region and then realized we did it wrong and had to rebuild the entire region and that we couldn’t salvage all the work that had been done yet to start from scratch. I mean, it happens, it’s a very costly mistake, but you know, like I said, when you’re an uncharted territory, sometimes you just don’t know what you’re up against.

Mario Gerard: Other problems I can think about like one or two, which are like scope just keeps getting added to this particular large program. Because one people see, oh, these guys are running this large program and they kind of like hitch their wagon or say, hey, if you’re doing that, you need to do this as well, but you probably don’t need to do. And they kind of, as a TPM, you probably need to ensure that you’re maintaining and managing the scope of a large program.

Rhea Frondozo: Yeah. I mean, scope creep is real, right. A lot of times what you end up seeing is what you plan for and what you are resourced for is different than when you start executing, you know, people want you to deliver on. And so, you end up, you know, if you go beyond the scope of what you’ve been sized for, you end up resource constraint. And then this can cause a lot of different things in terms of scheduling delays, missed deliveries. And so yeah, scope creep is definitely something that a TPM has to keep their eye on.

Mario Gerard: And in these kinds of large programs, I think it’s increasingly, it comes back to that judgment, which we are mentioning, right? You have to be the person who’s making that judgment call to figure out like, does this belong as part of this program or not? Is this 100% critical and crucial to be part of the delivery of this large-scale program?

Other things are prioritization challenges. Like how you help like teams go back, them prioritize against other programs they’re working on.

Rhea Frondozo: Yeah. So, I’d say that one of the things that often comes up is you’ll see that there’s multiple competing business objectives that require the same resources, same teams, right? And so, what ends up happening is imagine you expected this schedule to be done by date X and then all of a sudden it takes longer than you expected. Now you’re sitting on top of another project that you are supposed to get started, then what happens.

And so a lot of times it becomes your job to figure out, you know, what is the business impact if your project gets bumped or if it doesn’t get worked on to make sure that, you know, your executive leadership understands, if we’re making the right tradeoffs to continue working on your project or to redirect resources elsewhere or to elongate schedules, because it makes sense to slot in another project in the middle of yours.

Mario Gerard: I’ve been through these prior exercises sometimes when there’s a large program that we’ve kind of started or initiated, right. And it requires so many resources, we’ve kind of gone back to all the executives and said, hey, this is what we need size this for us. And if you need like 10, 20, 30, 50 resources from every single team out there, To run this particular program, then you, once they size it, you also tell them, Hey, supposing I ask you to start on this tomorrow, literally tomorrow what’s going to get bumped off your existing commitment to our senior CIOs or CTOs or whatever.

So, they go back. Not only do they do the whole sizing effort, but they also come back and say, hey, if I do X, Y, and Z for you, and I start on it tomorrow, or next Monday, all these things are going to get bumped off. And then you take that list and then you take that to the super senior executive leadership and they actual kind of sign off on it. If it, it’s a big enough initiative that has to be done. And this is the sacrifice we are making. You’re smiling.

Rhea Frondozo: Yeah. I mean, it happens all the time on the daily, right. Cause like we said, we always underestimate the amount of work that it takes to complete something. And then you end up in a situation where there’s more work than you have resources for, I mean, that’s the nature of the beast, right?

Mario Gerard: Yeah. Any other like big challenges you see when running these kinds of large programs?

Rhea Frondozo: I think maybe there’s one more around just finding the right owners. A lot of times you end up finding a new problem to solve and it can be hard to figure out who should own it. A lot of times teams are so overwhelmed with their existing priorities that they don’t want to take on a new challenge or they don’t want to take on a new scope of the project. And so not only is it prioritization, but maybe they’re like, not it, I’m not the one that should do it. And so, a lot of times this may require an escalation to figure out who should take on the new problem that’s been identified.

Mario Gerard: Yeah. I also remember one particular case. I wouldn’t go into the example exactly. But I remember a particular case where the stakeholders we had on our table, and we brought out this problem. I think after a week we realized that none of those stakeholders actually could solve the problem. We needed as somebody completely different from a totally different part of the organization who we didn’t even first consider should be the owner of solving this problem, because we didn’t have them on our table.

They weren’t part of our original stakeholder list of who we identified when we were working through this program. So, we had to like kind of think outside the box of like, which part the organization can actually go and actually solve something like this.

So, it makes you kind of take a step back and try to figure out like, where does this actually need to fit within the organization?

Rhea Frondozo: Right. Right. Defining, you know, roles, responsibilities, and ownership of some of these problems becomes a huge challenge sometimes. And it’s one that as a TPM, it’s your job to highlight, where are you blocked by this and then ultimately get buy-in from a new stakeholder that maybe you didn’t originally plan for.

Mario Gerard: Before that even I’ve seen, I think we’ve done this, we’ve gone on a discovery mode. You go and you try to talk to like 10 different stakeholders across the organization and try to figure out like, where would this fit? Because we don’t know every single Organization’s 10,000 people strong. You don’t every single function of who owns what, right.

So, you go through this discovery phase of talking to different people within the organization to see actually what their functions are and where will this actually fit and who is the right kind of owner to solve this particular problem. Because giving it to somebody that’s not, their problem space makes a big mistake. That’s a huge mistake to make. It’s very expensive mistake because they don’t have the expertise to go and solve that kind of a problem.

Rhea Frondozo: Right. And this is where I think one of my TPMS has told me sometimes, you know, as TPMS, we’re like detectives trying to figure out based on this clue, what’s the answer. And in this case, it’s, who’s the right owner who should own this. And you go, you know, knocking from door to door to try and see out, you know, are you the right owner? Should you be the right owner?

Lot of times nobody wants to do it. Cause it just means more work for them. But at the end of the day…

Mario Gerard: And sometimes they’re not [14:46 inaudible] for it also. They might be in a situation where we’ve spoken people and they have like 20 people on their team. And we know that this is such a big problem for them to go solve that it’s in their space, but they’re not either equipped to solve that problem or they don’t have the right resources to solve problem. So, it’s like super complex.

Rhea Frondozo: Yes. Yes. So, getting them to buy into taking ownership of the problem is…

Mario Gerard: And setting them up for success as well. As a PPM, you don’t want to just give somebody a problem. You want to ensure that they have the right resources and they’re putting those right level of effort and they understand the importance of this large-scale program and the impact it’s going to have on the organization to go solve that particular problem.

Rhea Frondozo: Right. Cause at the end of the day, you’re ultimately responsible for the program as a whole. And if you have a stakeholder that isn’t able to carry their weight, it’s not only a bad reflection of that stakeholder’s responsibilities, but your program as a whole, because your whole program suffers.

Mario Gerard: Let’s talk through that. If somebody’s not carrying their weight and they are a critical function, what do you do?

Rhea Frondozo: So, a lot of times this is where, you know, you end up having those conversations with the teams around what are options? Is it a prioritization problem? Is it a resourcing problem? Is it a skill problem? You know, do they not have the right prioritization because they’re working on something else or is it that they don’t have the right team assigned to it because you know, they put the junior developers on it instead more senior ones or is it that maybe we got it wrong. And they, when they started digging into the objective and the work that it really wasn’t in their wheelhouse to begin with, that can happen.

Mario Gerard: Yeah. So, it’s like, so these problems, so the next question is how do you manage and maintain information on a large-scale program? I think we spoke about this a little bit in the communication section, but generally when there are like hundreds of people, like hundreds of teams you are working with, how do you kind of maintain and manage information?

Rhea Frondozo: Yeah. So, this is where I think there’s a variety of different tools that could be used for this. And it could range from things like wikis or confluence pages. It could be, you know, work tickets from different systems. Sometimes people use JIRA, or I’ve used other kind of Salesforce tools in my current job.

A lot of times you want to be able to create D that are easy to see kind of maybe burn downs of your progress of where you’re at or you know, which items are particularly in jeopardy. A lot of times you could create PowerPoints for creating status reports or being able to do executive summaries. These reports could be PowerPoints or they could be emails or there could be newsletters that you create.

So it really comes down to, I think like what you said before, having a communication strategy about who needs to know what, and when, and then having probably a centralized place where you start from, you know, here’s a place where, you know, as a launching point for how to find the information about your program and then from here, you can figure out, you know, what are the different tailored communications that you maintain for your program.

So that if you’re an executive, you know, where you’re finding your executive summaries. If you’re a team member who is the point of contact working on it, what are your responsible for providing in terms of your updates and where, or if you’re a bystander walking by and want to know what’s happening to the program. You know, how can you find generic information on the program as a whole.

Mario Gerard: Yeah. I think also a lot comes down to how an organization manages this in general. So doing it at OCI versus doing it Salesforce, I’m sure there are certain types of differences, like how executives like to receive messages or how they want to receive the communication versus one organization versus the other.

Rhea Frondozo: Oh, for sure. I mean if you look at organizations like I’ll give you some examples. If you’re looking at Microsoft, everybody was creating very pretty PowerPoints on what their status was and what to their risks and issues were. But then you look at an organization like Amazon or OCI, which is, I think where, you know, OCI had learned from they’re looking at writing, you know, six pagers writing papers on like what the problems are or writing very detailed statuses and table formats versus pretty, you know, pictures.

So, it definitely can vary depending on the organization, depending on the leadership and depending on kind of the level of detail needed.

Mario Gerard: And even the program. If I think about OCI, right? I’ve been on so many different large-scale projects, some projects, you do a one-page summary, some projects you want to showed in table of format because you have 20 teams, or 50 teams and you want to show where each team is at. So, it kind of depends on so many different things. But you kind of got to figure it out as you go or rework your communication methodology or communication plan as the program develops as the organization depends on or you lead it, what they want to see it as how they want to see.

So, it’s a combination of different, there’s not, I don’t think there’s one size fits all here.

Rhea Frondozo: There’s definitely not a one size fits all. I think, you know, maybe you have templates or starting points that may become like anchors to a program, but as the program evolves, you know, your communication mechanisms often change and you have to be able to be responsive to what, you know, the needs of your stakeholders are.

Mario Gerard: The next question I had was in general for these kinds of large skilled programs, what is the TPM team structure? Like it’s not one TPM who generally runs such a large skill program or how do you orchestrate this? How do you explain that?

Rhea Frondozo: Yeah, so, you know, I think that the structure of a large program can vary in the sense of, you know, in some programs that I’ve ran. I managed a team of TPMS, and I owned the entire program, but maybe I was able to break off different projects within that program and assign it to different TPMS.

Or maybe you have a large program that requires multiple TPMS working on it. And you have, you know, different functional areas that you assign TPMS to that ultimately roll up to, you know, a single TPM lead or other times you may have a TPM as a lead, a breadth TPM, but maybe they’re working across a team of functional owners who have their own maybe depth TPMS that are assigned to the program.

So, it can definitely vary depending on kind of the size and scope of this large program. But I have seen it where typically there as at least a TPM lead and, you know, a number of different TPMS or functional area owner supporting them.

Mario Gerard: Yeah. I think you got to design that. Sometimes I remember like going to a program, we didn’t know how much work it would take. And then we kind of bring in people as we need, we probably start with like maybe one or two TPMS, and then you say, oh, this particular area needs so much of effort and so much work. And so much of design, program design that you actually go and bring in a GPM for that.

And then you find another problem area and you might have, so you have different work streams. That’s what used to call it right. Different work streams where we have what are many TPMS in charge of one particular work stream and that kind of all fits together into one large scale program. So, if you think about a large-scale program, you could have maybe one TPM running it, but generally it’s one lead TPM, as you said, and then multiple smaller streams of TPMS or POCs or whatever that might be.

Rhea Frondozo: Right, right. Exactly.

Mario Gerard: Do you have any kind of frameworks that you can talk about for executing these types of large programs Rhea?

Rhea Frondozo: Yeah. You know, I think if you think about a large-scale program, there’s often phases that these large-scale programs are comprised of. And so, at the core you imagine there’s the planning phase followed by an execution phase and then a phase where you’re in support or maintenance mode before you end up in a close-up phase.

And so, the frameworks that you end up applying to a large-scale program often are surrounded by kind of what phase of the program that you’re in. So if you are in a planning phase, you know, you’re going to be using tools like coming up with what is the problem statement coming up with a cost benefit analysis, where you’re weighing the pros and cons of the options for how you’re going to solve this problem and what are the associated costs of choosing one option or the other, and coming up with what your recommendation is.

And then you’re creating, you know, project plans around, you know, what needs to be, so how you’re going to solve it and how long it’s going to take. And you’re creating schedules and using Gant charts to come up with such schedules. And once you complete the planning phase, then you move into the execution phase.

And this is where you start tracking your project status. You’re coming up with status, you know, meetings or status reports, being able to come up with executive summaries on how the program is progressing, what are the identified risks and mitigation plans, you know, tracking risks under, you know, risk registers or mitigation plans.

You’re also at this phase coming up with ways to visualize what’s happening, whether it’s through dashboards or work tickets or newsletters around the program. Once you’re able to execute and build out the project or the product or the program, then you end up in what we call the support or maintenance phase.

And here you’re looking at assessing how well did you deliver on the project? And are there things that are missing? Are there things that maybe you didn’t get quite right, that you need to go back and fill in some gaps for, or maybe even redo or do a second version of, and then you end up in a scenario where you’re price prioritizing all the different issues that come up and you have to go through different exercises to figure out, you know, what do you invest in and how do you invest in it?

Is it something that you add to the existing program? Is it something that you rearchitect or maybe it’s something that you decide you close out altogether and start from scratch on a new program? So sometimes it means close out the program that you have and then figure out what is the new thing that will replace it.

And all the while, while you’re going through all of these different phases, you’re looking at kind of, you know, what is the cadence of the programs, communications that you’re in? Who are you communicating? When are you communicating and continuing to evaluate what is the different communication mechanisms that you need as you go?

Mario Gerard: Yeah. As you were talking through that, like one thing which I was thinking through is at OCI, you’ve been part of so many programs. I don’t know how many programs, probably more than five or six programs at the very least. Like what is an average time duration, do you think, think they vary, but why you tell our audience, like approximately like the first one we worked on almost took us probably more than two years, One and a half years, right?

Probably went on after we left as well.

Rhea Frondozo: Yeah. So, a lot of times for like big programs, I’ve seen programs be in the planning phase from anywhere as 1, 2, 3 months, all the way to a year of just planning, trying to figure out, you know, what investments that you need to make getting the right buy-in. Especially when you’re looking at things where you’re going to invest, you know, millions and millions of dollars.

Mario Gerard: Yeah. Hundreds of millions of dollars.

Rhea Frondozo: Hundreds of millions of dollars.

Mario Gerard: Literally like some of the material worked on are many hundreds of millions of dollars.

Rhea Frondozo: And so, a lot of times the planning for something that would like, that can take really, really long.

Mario Gerard: And it takes really long because it needs the most senior level executive buy-in. This is going up to a CEO of a company where they have like more than 150,000 employees. A multi-billion-dollar company, they have to approve an investment like that. And that’s why it takes you so long to even plan something. Because there are one, there are a lot of unknowns and two, there’s also a multi-million-dollar budget.

Rhea Frondozo: Right. Right. So definitely the amount of time that it takes for planning can vary, but I have seen it run very long. And then you add in the portion of execution, you know, execution can also vary, but for big projects, I was building a net new cloud region and I had worked on it for a year and a half before we even got to the accreditation state. Which is just verifying that what we built was the right thing.

And when we went into the verification stage, found out that we hadn’t done it all right. And had to redo some of it. And so, what was a year and a half ended up being another, add another year to that, to rebuild it and do it again. Yeah. So, I definitely, you know, from a time perspective, large scale programs can definitely take a lot of time.

Mario Gerard: Because of the amount of effort that’s required because of the number of people involved. Like these do take a lot of time.

Rhea Frondozo: And then when you’re talking about, you know, once you actually get it built, the program is still continuing right now you’re in the support or maintenance phase where people are actually using the thing. And trying to figure out, you know, what’s missing or what new things that we need to invest in.

And so, this can also be really variable depending on how successful the project is or unsuccessful in, in which case maybe it didn’t turn out as well. And there’s either investments that you want to make in it. Or maybe you want to shut the project down as a whole and start again. So yeah, it definitely can vary.

Mario Gerard: So, it’s kind of interesting to go down these one- or two-year kind of initiatives and then see it all be successful because there’s definitely a huge impact. And these are also another thing is these are things which give you your promotions.

These are things which move you from a senior TPM to a principal TPM or from a Princip of TPM to a senior principal TPM. These are career making initiatives that we are part of. This’s also a lot of risk and a lot of hard work late nights. But at the same time, there’s a lot of reward at working in one of these large-scale programs or leading.

Rhea Frondozo: For sure. I mean, it’s the kind of thing that these are the are kinds of programs that you take that have a lot of visibility that, because it makes such a difference to a business’s bottom line. If you do well and succeed, you can be heavily rewarded through a promotion or whatnot. If you don’t do well. There are probably other projects that you may be assigned to that maybe are more fitting.

Mario Gerard: Yeah. Also, I feel like we’ve done this so many times. I feel like looking at people around me, you will fail really fast If you’re not good at what you’re doing. Your senior leadership will take you off a program pretty fast. If they feel that you’re not up to the bar. So, if you’re not meaning the bar of running this really, really well, failure is very visible, very fast. That’s what I think I’m going to say.

Rhea Frondozo: For sure. In a critical project like this, if you aren’t able to effectively manage program, it’s going to show and it’s going to show at the highest levels. And so, there isn’t a lot of room for, I mean, not necessarily mistakes, but there’s not a lot of room for continued ineffectiveness. So, if you make a mistake and you learn from it and you figure out how to do it better moving forward, you know, that’s one thing, if you continue to be ineffective in your role, the business does not have a time or the appetite to continue something like that.

Mario Gerard: And that my friends is the end of part two of the three-part series on how to run blog scale programs with Rhea. Definitely check out part three as well and share this podcast, like it, and leave review on your favorite podcasting app. See you on part three.