Designing Hybrid PMO Methodologies for Your Organization

Sarah Carroll: Welcome to Witham Sounding Board, a podcast sharing powerful business tips, insights and trends for those seeking to become a rock star in their industry.

Logan Storm: Quick question for both of you before we even get started. Waterfall or agile? Which one wins?

Kim: Hybrid.

Sarah Carroll: Well, I have to say, it depends.

Kim: That was, that was a couple words.

Logan Storm: Good answer. And that is exactly the wrong question. Today we're going to talk about picking a side is actually holding your PMO back and what to do instead if you haven't been following along. This is our fourth part of a seven part series as we talk about all the things impacting the product management office. My name is Logan Storm. I've been a PM for a few years now and I will be leading today's discussion where I am joined by my wonderful colleague Sarah and Kim. Please take a moment, introduce yourselves.

Sarah Carroll: Thanks Logan. I can start. My name is Sarah Carroll. I am part of our management consulting and digital solutions team where I work on a wide range of projects from strategic business initiatives all the way to a large scale ERP implementations. I started my career in accounting before moving into consulting about five years ago. I am also a certified change management practitioner through prosci. So my true bread and butter is helping organizations to design approaches that people are going to actually adopt.

Kim: Awesome. I can't compete with that, Sarah, but I lead up our PMO practice on the Witham side under our consulting services. And I've been in the industry for about eight years now and I have a vast range of experiences across very a lot of different industries, from a lot of strategy projects to tech projects. And then the cool thing is that the experience that Sarah and I have working in the consulting services industry is that a tech project isn't just a tech project. Right. And then a business project isn't a just a business one. So we try to merge those worlds together and then when we're wearing our PM hats, we're thinking about what are the impacts beyond the project. Right. So I, I think Sarah and I enjoy that type of work a lot. It's really dynamic and we're looking forward to the discussion today.

Logan Storm: Yeah, great. This should be good. All right, first question is for you, Kim. Our, uh, Part one article said the waterfall versus Agile debate is fading. What does that actually look like in the field? Are clients still picking sides?

Kim: You know, uh, agile and waterfall have different demands on clients. Right? So it's not even around the methodology. Oftentimes when we're working with clients, they expect us to be masters of the methodology and they're kind of along for the ride sometimes. Right. And when they're along for the ride, they're just, they're the ones getting demands upon them. What input is needed, what homework are we assigning them so we can keep driving the project forward. And it's really about capacity. Right. So when we think about agile, it's iterative, it's collaborative, it's a little bit unconstrained in the sense where requirements are evolving. And we're expecting that. Right. For a client that doesn't have as much time to dedicate to that they already have their full time jobs, they're really expecting the outsourced team to do it. It's a lot of burden upon them. Right. So when we're looking at, from a practical perspective, they most likely would want to favor a waterfall because there's clear gates, the demand is a little bit less and then we get agreements and sign off. So waterfall is more stakeholder friendly. I would say Agile is if they have dedicated members to partake with us in that Agile process. So that's what I would say. I know internally at uh, within we try to do a hybrid methodology and adjust the demand based upon the client need. Right. So that's what I would say.

Logan Storm: Nice. So what is the real cost of being dogmatic about your methodology? Has either of you seen an org forced the wrong approach in a little project and pay for it?

Sarah Carroll: Absolutely. I actually am currently working with a client. They're in the nonprofit space and they're going through a very large and a very complex merger. Early on in the merger, I want to say over a year ago, they adopted an extremely agile approach to project management. And then we were brought in more recently like a couple months ago. So as their merger date is getting closer, we're noticing there's still so many open decisions, there's a lot of unresolved dependencies and there are a ton of critical tasks. All these things are happening in parallel. So it's hard, you know, being brought in only a couple of months ago. It's hard not to look at it like where they are now and think how they could have been in a much stronger position if they had a more formal PMO structure earlier on. So it's not necessarily that I think agile was the wrong choice for them, but uh, they're just relying on it exclusively without enough structure or governance. So that's making it much harder for them to manage all the risks and the uh, stakes are definitely increased.

Logan Storm: Nice. Kim, do you have anything you want to add?

Kim: Yeah, I actually have a recent Project where uh, it was around app development and it was driven by a very particular business use case. Then it was basically fully dev driven, development driven. What that means is that sometimes we're so in the weeds of how's this app going to look and function that we forget about what is the actual business use case and it's really connecting it to that. So we're doing iterative app developments. Despite all the collaboration, the frequency of meeting and getting input and refining it, when you actually zoom out to the overall business case of why we got there, it wasn't suitable to that. And then it was on the PM side to really call out saying this is a great app, it looks fantastic. Let's take a step back and functionally how is this going to work and then how are people going to interact with it? And this has actually solved the use cases. Right. So it's, we don't want to dogpile an agile here. We actually like agile a lot. It's just being careful to make sure that we're always asking ourselves why are we here? And then is how we're doing it supporting that? And if not we need to pivot.

Logan Storm: Uh, so if the answer isn't waterfall or agile, how do you actually decide what to use and when? Sarah, walk us through a method mix matrix.

Sarah Carroll: Yeah, I'm happy to. So actually from what we've seen, I think uh, most organizations don't necessarily struggle because they choose either waterfall or agile. They're struggling, struggling because they're just applying the same approach everywhere. So the biggest shift here is we're moving away from methodology as a belief system and we're using it more as a design decision. So that's where the matrix comes in. The first dimension of the method mix matrix is compliance or regulatory pressure. So in other words, how fixed are your requirements? The higher that pressure, the more structure and predictability that you'll likely need. The second dimension is volatility. So how fast are things changing? That could be scope changes, technology related changes or business priorities. The faster that things are changing, the more iteration and feedback you'll likely need. So when you combine those two, you're going to end up with four scenarios total. You'll either have high compliance and low volatility, so that often calls for a more traditional delivery, or waterfall, you'll have high compliance and high volatility. This is where the hybrid model, so waterfall and agile, that will really shine here. Iterative delivery with governance guardrails. And then you have low compliance and high volatility, which is Usually full agile. And then when both compliance and volatility are low, you generally can just kind of use a lightweight PMO approach.

Logan Storm: Great. Kim, walk me through a real project. Where did it land on this matrix? What did the methodology actually look like in practice?

Kim: Sure. I want everyone to know. Before we started the podcast I asked, do you want me to give you a good project or a bad project? But uh, I'll keep it good for now. You know, we're actively, right now we're doing a Shopify implementation. Right. A little bit beyond that for context, it's an entire business change. So there's a new, that this company wants to open a new entity with a very different business model. Plus it's Shopify layered on top. Right. So again, merging that the business side to the technology side and then Shopify itself is often implemented with an agile iterative approach. Now overall what we are trying to do is kind of wrap it in a hybrid type of wrapper. So what that looks like is that we are getting a, ah, lot of inputs about, okay, what are the business changes that are going on while we're also building prototypes at the same time for basically the front end of the website. And this is allowing us to address fundamental business changes in a very structured way. We're getting stakeholder input, we're building a design that we can tie it back to, while at the same time we're letting the agile component run its course with the Shopify implementation. Right. So it's trying to find that right level of balance of we're actually assisting with, with helping increase that high compliance to make sure that, that we're committing to that business model and everything around that business model that's being built supports it correctly. Or uh, also being agile where why hold up the process if it's not so dependent on those discussions? Right. So it's using your judgment. So I would again, this is more of a hybrid methodology for something that would be typically more agile in nature just due to the, the nature of the circumstances.

Logan Storm: Great. Yeah. So some of the patterns that I've actually seen in my experience with industries and project type. So high compliance, low volatility could be construction, government contracts, ERP implementations. The high compliance and high volatility could be like regulated tech, so fintech, healthcare, it. Low compliance, high volatility would be like startups, innovation labs, marketing campaigns. And then low compliance and low volatility would be like internal operation improvements. Have you guys seen any other examples of these or does that pretty much cover what you've seen? As well.

Sarah Carroll: Yeah, you know I actually just want to add because that uh, just you just brought up a good point when you said construction for example is in the high compliance, low volatility category. Typically. I just want to add that this framework is really meant to be a starting point. Like for example I'm currently working on a construction client, they're doing a CRM implementation and we've adopted a uh, deliberately mixed approach. So it's some elements are more agile and then others are more waterfall. So I think what's made it successful is uh, that it's truly tailored to both the client and the project. So we looked at all different things, how they operate, where they need structure versus where they need flexibility. So I just want to add like while the matrix is obviously a great way to anchor your thinking when you're planning for your PMO approach, it's also super important to remember it's not like a uh, end all, be all formula and you can customize the methodology based on what you know about the actual client and the work itself. So yeah, just want to just add that one thing. And in terms of an area that surprises people, I think regulated environments like labor unions or higher educate, like universities, there's often this assumption that if you have a lot of regulation that means you can't be iterative. But that's not really true. In the past we've had projects where an agile approach works extremely well in regulated organizations. So it just, it just needs to sit inside clear governance, have clear controls and have decision discipline. But uh, in my opinion I think hybrid approaches actually tend to be more effective in those types of organizations.

Logan Storm: Great. Kim, do you agree, do you have anything else you want to add to that?

Kim: Yeah, I agree with Sarah and what I would say is here it's industry is one component, but then it's also about the project size of that the organization wants to conduct and also how much PMO they have inside of their organization as well. So when we think about an organization they have fully stated, hey, we want to make transformation and innovation a regular part of how we do business. And then we want to have that capacity internally. Oftentimes they have that leeway, that capacity to do that agile approach. Right. If it's a one off project, usually waterfall might be more, more up their alley unless the project size is pretty large. Right. So I think it just depends upon how much internal capacity they have to support. And then for their projects if they're doing multiple projects at once and they kind of get used to a ah, different methodology. So for larger projects, maybe it's more agile in nature, smaller ones, maybe the waterfall approach or vice versa, it really depends upon how they make those decisions is based upon that internal support structure. And then externally, if they're relying fully on consulting teams to kind of execute that for them, they're going to be a little bit more cautious. Stakeholder buy in is even more critical. Right, because now you're having external resources to influence how business is getting done. So again, to Sarah's point, as long as there's controls no matter what, in agile, sometimes it's just seen as like endless iteration. Right. So the controls are really going to be around putting a uh, budget to things and then making sure that there's still approvals going on even as things are iterating. So having those controls are going to be key. No matter if you're waterfall or agile, you still need to have practical parameters in which you're operating within.

Logan Storm: Great responses. Yeah. Okay, so Sarah, back to you. A PMO leader is driving to work right now thinking I need a hybrid model. Where do they actually start?

Sarah Carroll: So if you want to start building a hybrid model, the first step would be actually auditing your current portfolio. So this means what types of projects do you actually run? Not you know, what you think you should be running. That's step one. Step two would be to identify your non negotiables. So these could be regulatory requirements, financial controls, executive reporting needs, but uh, in general what compliance or governance requirements can't flex. The third step is to define your hybrid patterns. So don't reinvent the wheel here, but create two to three reusable quote unquote recipes. You know, for example, if you're going to do an agile delivery model, but you're going to have monthly steering committee checkpoints, the fourth step would be to document your decision rules. This gives PMs a very clear and simple guide. So you know, they can see if X use pattern A, if Y use pattern B, et cetera. So documentation is super important. And then step five, the last step would be highlight before you scale. So you will learn a lot more in applying a model in real life than just documenting it on paper. So that's why step five would be to actually pilot the plan.

Logan Storm: Nice. Uh, Kim, what's the step people most often skip and what goes wrong when

Kim: they do all of them? But if I had to choose one, it would be step one maybe. I think a lot of times, you know, everyone wants to, to start a project and then just do it and see where it lands or automatically scale it without piloting it. I think that the first thing is you need to take an inventory of every, all the projects that are going on in your organization. And that's a large ask. So not everyone has full visibility as to what's going on. And then that's what I call portfolio blindness. So when you have portfolio blindness, you can't really standardize what's going on. And everyone is taking an individual approach to how these projects are managed, how they're being approved, how they're being sponsored, how people are engaging with them. So that can cause a lot of disruption. Right. And then it kind of thwarts aligning to one methodology or another. Sometimes it's just really dictated based upon the individuals leading them. So auditing the portfolio is key. And really getting that visibility into all your projects. Oftentimes when I go into different clients, they don't have that list readily available. They have some here, some there, but their visibility is, uh, pretty low. So they don't know how to even start scaling and making transformation activities happen more rapidly and more consistently across their organizations. That's where you see a lot of strife and conflict. So start with step one before you skip the steps. I would say.

Logan Storm: Great. So the next thing I want to ask about is basically you can design the perfect hybrid methodology on paper, but then you hand it to a team and then what happens? Right, so we have some general questions I want to ask and then I'll pass it to both of you to answer them. But so first one is what is resistant that come up? Is it usually the waterfall people or the agile people who push back harder? Second is how do you bring skeptics along with it without it feeling like a top down mandate? And then finally, what does good stakeholder communication look like when you're introducing a new hybrid model?

Sarah Carroll: Take the first one. So my answer to what is the resistance that comes up and is it usually waterfall people or agile people? I'm going to say everybody. I don't think resistance discriminates against the two. It usually comes from both sides, just, I guess in different ways. I would say waterfall leaning people tend to worry about like losing structure, losing predictability, and then vice versa. On the agile side, maybe they're worried that too much governance is going to slow them down. So I would say a lot of the resistance is not necessarily about the actual methodology itself. It's more like what people think the methodology represents based on their past experiences.

Logan Storm: Great. Kim, do you have one of the others you want to Tackle.

Kim: Yeah, sure, I'll take the second one. So the question is, how do you bring skeptics along without it feeling like a top down mandate? Right. And I think the approach is to always make sure you have the buy in from the key stakeholders. Right. And then you're forming this methodology not in a silo. So the PM is not a mad scientist that is, you know, constructing this plan in the background and then all of a sudden everyone has to accept it is that you, you have to understand the inputs from your stakeholders, what are they able to do, what are they not? And then is there any flexibility? It's a negotiation exercise to formulate that plan. You don't get buy in. And again this rings true for Sarah's change management hat if you don't get buy in, you can have the most perfect plan in the world and then no one's going to execute upon it. It could be the most well thought out thing ever, but it's really about that input and um, then coming up to a compromise and then if I really have a strong skeptic, I guess a technique I like to use and now they'll know my tricks after listening to this is I make them a change champion because oftentimes skepticism comes from a lack of ownership or feeling like they're just along for the ride. Right. So sometimes if, if I'm able, I'm able to give them that uh, that ownership piece and they're responsible now for driving some of the changes and then making sure post project those changes are formidable. That won't work all the time, but you have to really identify the needs of why people are objecting the way they are.

Logan Storm: Great. And I'll take the last one for good stakeholder communication. One thing we like to think about is just meeting them where they are. People might react badly to Agile if we basically just start working iteratively and kind of making sure the terminology is onput for what they used to. That's when usually they'll, you know, react a little bit better. So we just try to make it easier for the people that we're actually having on these projects. That's usually something we like to focus on. All right, I'm going to ask you some questions and I just want a one sentence answer for each one from both of you. First one being biggest hybrid methodology mistake

Sarah Carroll: you've seen designing a plan and never actually revisiting it.

Kim: Yes. Uh, I think that's less of a fault of a methodology mistake, it's more of a due diligence Mistake, I guess, but I agreed. I guess the biggest mistake is when you're doing hybrid methodology, you have. Oh, sorry, this is probably not one sentence, but you have different third party players sometimes and you have to be able to leverage them with their strengths. You can't use a hybrid methodology and not leverage people for their strengths, otherwise it's going to fail.

Logan Storm: One tool. You can't run a hybrid PMO without,

Sarah Carroll: I think, a racy matrix. So for those listening, if you don't know what that is, it stands for responsible, accountable, consulted, or informed. It's basically just a matrix that tells you who is doing what. So I think, especially when you're using hybrid and you're blending approaches and responsibilities can get fuzzy. This is super important.

Kim: I agree with Sarah and I would add on a, uh, schedule. So even if it's agile, um, there's still a schedule and a plan to it. Right?

Logan Storm: And this will be a callback to our opening. But waterfall agile, if you had to pick just one for the rest of your career, which one are you picking?

Sarah Carroll: My answer is the same. It's still. It depends.

Logan Storm: Oh, man.

Kim: I think Logan's really trying to get us to commit to an answer here. I would say waterfall is more predictable. So if you want a slightly calmer career, I guess waterfall, if you really like that, that rapid change, then agile for sure.

Logan Storm: We'll take it. All right, last question for each of you. Someone's listening to this on their commute and they lead a pmo. What's the one thing you want them to do differently?

Sarah Carroll: Next Monday, maybe stop stressing so much about the methodology and start thinking more about each individual project and what actually needs to be done in order for the project to succeed.

Kim: Yeah, I agree with that. And I think it's outcome specific. So just, uh, ask yourselves, you know, what is the project trying to achieve and then how's it going to impact the organization afterwards? Right? And then you have to come up with a good playbook where it's not restraining people's judgment, but it's a nice guideline and then they can exercise judgment within those guidelines.

Logan Storm: Wonderful. Thank you guys for joining me today. And thank you to all those listening in. Please, if you haven't already, review the other parts of the series we have already put out and lookout for part five, managing Remote and Distributed Product teams. All right, have a great day.

Sarah Carroll: Thanks for joining us. Be sure to subscribe to our podcast so you'll be first in line to

Kim: hear what's coming next.

Sarah Carroll: Uh, don't want to wait for our next episode. Check us out@witham.com that's w I t h u m m dot com.