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.