Project vs. Product: Finding the Operating Model That Actually Fits

Welcome And Setup

Peter 0:04 Welcome to Definitely Maybe Agile, the podcast where Peter Maddison and David Sharrock discuss the complexities of adopting new ways of working at scale. Hello again, Dave. How are you? 

Dave 0:15: It's been a while, Peter, since we last talked, hasn't it? It has, hasn't it? So it's been a fun morning so far. Fun afternoon. 

Peter 0:24: Glad to hear it. Well, so in our last conversation, let me reframe this as I'm putting this through my head. In our last conversation, we mentioned that we needed to have another conversation, and that conversation needed to be about operating models, which you then implied afterwards was actually what the conversation we were having was supposed to be about in the first place. So with that all out of the way, let's talk about operating models.

Dave 0:45 Let's talk about operating models. And what are the operating models that you consider up for debate?

Peter 0:50 Well, in this particular conversation, you I believe you want to talk about the project and product operating models. But we're really talking about how an organization gets things done. And I think of it as the delivery system operating model, the operating model of the delivery system, which arguably might be a subset of that or a part of it, but whatever you want to call it, how do we get work done is really what we're talking about here.

Dave 1:17 And we're talking digital products. So there's something technical in there, right? And I think what I'm finding, I mean, certainly what we're seeing, you and I have worked in this space long enough to see that there are two sort of endpoints that are opposing ends of a spectrum of different operating models, of which there are many versions in that whole extreme. But on the one end is project-centric, annual funding plans, a list of projects to be delivered, organizing teams around the projects that need to be delivered, and where progress is measured by on time, on budget delivery of those packages of work, those projects that they have.

Peter 1:55 Yeah, people to the work rather than work to the people.

The Parts Of An Operating Model

Dave 1:58 And if I just reverse that and say, work to the people, not people to the work, then you slide along that scale to the product side, which is a continuous flow of work tightly integrated with what the customer's experiences or end users' needs are, making sure we're meeting those needs, we're getting the results that we're looking for. And it's a tighter integration. I would argue the biggest shift is this tight integration as you go through that loop all the time, which means we're looking at feedback mechanisms rather than claiming success on the delivery of a set of activity.

Peter 2:35 So if we think about what the components of these operating models are, we've got a strategy, like somebody defines where are we going to go, what is the strategy we need to follow. There's a breakdown of what the work is, like how do we take that strategy and define what we're going to line up as objectives, maybe what's that going to look like? How's that work going to get taken into chunks which we can then deal with? Like, how do we want to break this up? Do we want to do it along value streams, organizational divisions? What are the things that we need to do? What are our divisions of that? We've then got people who are going to own parts of that, right? So we got the structure of the different people, what are the roles, what are they going to do, where are they going to align into those different parts? Who's going to have what accountabilities, who's going to have what decision rights? We've got the governance model, like how do we make sure we stay on track, when do we agree to meet, what are the tools and the systems that we're going to use to govern all of that? What are our agreements around all of it? Am I missing anything out of that?

Cynefin And Planning In Complexity

Dave 3:49 I think there's a planning concept in there as well, but I think it's implicit in the way you were describing that. And we've not had a conversation like this for a while, so I get to mention Cynefin and complexity again. I'm just going to draw that one in because they've got this really nice split between ordered work and unordered work.

Peter 4:08 Yeah.

Dave 4:08 This concept of ordered work, which means the critical thing about ordered work is I can plan it and the plan doesn't go out of date. Or at least it doesn't go out of date quickly. Because it's ordered, it's deterministic. I can sit down and we can think through all of the consequences of the steps that we take. Therefore, we can get that plan fixed. Whereas in unordered work, the plan gets out of date much more quickly than the time it takes us to get the work done, which means the plan becomes obsolete as we go forward and we have to think things through differently. And that impacts planning and work and people and governance and all of that, because that distinction really defines the difference between those two endpoints.

Peter 4:52 And these are often operating within whatever scale system is in place. If you're a startup, you're quite likely to not have any calcified systems you're having to operate within. But if you're a larger organization, you've probably got large calcified systems which exist and work and generate revenue for the organization. And changing those becomes much harder. They don't tend to shift and move and they tend to be looked at at a much larger scale in the operating model.

Dave 5:19 So there are a few other consequences as well, as I'm thinking about that. Because one of them is if I'm going to create the one plan that rules the entire program for some duration, that means it's front-loaded with smart people. I bring the decision maker in at the beginning. I want my best solution architect, I want my best X, Y, and Z, all of these people to come in and define the plan. But once the plan's done, I can now push all of that work down to, I'm going to say less skilled for the moment without wanting to be too blunt. But if I can get people who can follow a detailed plan, I've front-loaded the highly expensive, knowledgeable experience at the beginning, and now I can just go ahead and build.

Peter 6:03 Can anyone say Taylorism?

Decision Rights, Feedback And Governance

Dave 6:05 Well, there's an economic model that comes with all of this and all the rest of it, right? And this is, if the plan is continually changing, I need to keep those individuals who have experience, innovation, authority, whatever it is, that skill set needs to be close to the team continually.

Peter 6:28 Yeah, and so that's the organizational model, and it's why different organizations, even parts of the same organization, will operate potentially under different models, depending on what's the right fit. And those models may change with time too, depending on what that organization is doing. Now, we've talked a lot over the years about the concepts of when operating within a volatile environment, that a product operating model with its tighter feedback loops allows you to have better response because of what you were just describing. The decision making is much closer to the decision, essentially. And so you're moving that role there with that understanding so that they can think about that. As we think about these systems of work and the way that they operate, the two that we started with when we talk about project and product operating models, and we think about all the different component pieces, we've been touching on some of the key differences between those models. And it's interesting because, as you also alluded to, there are many, many different variants of this. There are lots of different ways in which you can organize your work, lots of different ways that people do organize their work.

Dave 7:44 Well, and some of the other consequences come into that whole issue of whether or not the plan is going to be obsolete. Because if I have a plan, I end up very often in a strong hierarchical directive mindset. Because if I'm the owner of the plan, which is the title of a project manager typically, they own that plan. There is less room for not following the plan. So it becomes a directive. Dave, I need you to do this. You're in the plan. We're doing this this week. That's what I need you to do. Whereas if I'm in that product space, we're seeing problems coming. We're getting feedback. This is not working. Now let's all figure out how to solve it. The assumption that one individual stepping into the room can answer that question, well, it's not going to be the same individual, even if it does change. It's going to be a different individual for each problem. And more often than not, we actually have to go through that whole problem solving piece of figuring out where it is. Whereas that's done upfront in ordered work.

The Hybrid Trap And Better Borrowing

Peter 8:49 In theory. And the reality is obviously an awful lot messier than that. And what we really end up with is a hybrid of these two things, which doesn't always serve anyone.

Dave 9:01 Well, nobody's ever happy in that world, right? But I do find that understanding the two endpoints of project and product in that line that we're talking about, walking backwards and forwards on, allows us to begin seeing how we can expect what tensions we can expect to have as we move in one direction or the other. We talked a little bit about planning, we've talked a bit about where the work comes in and problem solving, we've talked a bit about people and governance. Where does that break down as you move from one end to the other?

Peter 9:33 Well, it comes down to what artifacts do I need and when do I need them? And are they static or are they transitory? How often do we go back and revisit and relook at them? Those are some of the key pieces that come into it. Which is, I mean, when you start to think about what does this look like at each of those different layers and how do we understand how these different layers interact, it helps to go into the organization or into your own organization and ask these questions. Think about how does strategy get made here? How does that strategy get turned into work? How does that work get structured? How does that work get funded? How does that work get tracked? Who has the decision rights on this? Who needs to be in the room? How does that work? Asking these questions helps you to build an understanding of the system.

Dave 10:32 But I think as you're describing that, what strikes me is a couple of things that really probably are hard and fast rules. And let me just see if this makes sense. One is if I'm firmly on one end or the other, the likelihood of me being able to take a template that works really well for me over here and take it to the other end is close to zero.

Peter 10:49 Yeah, and equally across organizations, because organizations are somewhat a variant of this and they will have variants across their organization very often. They don't have to be very large at all to have variants. And once you have those and you take them with you, it's not cookie cutter, it's not one size fits all. You have to find the thing that's going to work for you, and it's what's going to work for you now. It may not be what's going to work for you tomorrow.

Dave 11:19 And it's what's going to work for you with the context and the principles being applied, not just because you happen to come in with experience of doing one particular way. Which is quite a different thing, right?

Peter 11:30 Yeah, but it's because that context changes. It's why a lot of this changes, right? Because the context is volatile, which means the model has to change, or should change, to adapt. And that's actually where the other problem comes in, where you find yourself applying the wrong model. And if we take Cynefin again, this is exactly what that teaches you. Applying the wrong model to the wrong problem is where you'll run into difficulty.

Dave 11:57 Now, I just have a question about hybrid. Let me put my opinion forward first and see where that goes. First of all, I really don't like hybrid organizations where they do a little bit of this and a little bit of that. It feels like you can't cherry pick from the project side and cherry pick from the product side and expect to come up with an operating model that is going to solve anything. What I have seen work quite well is a predominantly project organization that pulls in a number of the practices from the product organization, allowing them to handle a little bit more variation. So if I think of things like iterative waterfall, that's a good example of where they're at least bringing in shorter feedback loops so they can benefit from some of that. Or equally on the product side, where they pull in some practices from the project side that give them more certainty, maybe around role clarity, around decision making. So you can borrow a little bit from each, but as soon as you try and say we're now hybrid, I'm not convinced you're going anywhere useful.

Bank Examples Of Forced Frameworks

Peter 13:10 I think the actual problem when you say that is that the kinds of organizations that typically say we're now hybrid are trying to be one size for absolutely everybody. And I'm going to take another example from a bank, because this is a really great example of this. In this bank, within your area of sufficient scale, you could either be on a project operating model or a product operating model. Because at scale, you could very well have different parts in different places depending on what you're doing. And where they had the product operating model, or agile really is what this is, their agile way of delivery, to be in that agile way of delivery, you had to do a whole lot of paperwork and bureaucracy and jump through a lot of hoops. Sounds very agile, yes. And to do that, you got a big stamp to say you're agile. And then you felt really good about yourself. But there was a third model, and the third model was a hybrid model. Now, the reality is this was hybrid not in the way that you're describing. This was hybrid in that the part of the organization trying to work out how to best operate to do delivery within their context could pick and choose the practices that worked best for them to deliver. And that I think works a bit better, generally speaking, providing, and this is a big caveat, they've got sufficient coaching and guidance so they don't shoot themselves in the foot.

Dave 14:41 Well, it's a discipline. A lot of these practices are disciplined practices. And the moment you have discipline anywhere, you need a little bit of control. The same reason that there are people who go to the gym, hands up for that one, who don't have a trainer, and that doesn't mean you've had the discipline to follow through everything you should. Some people do, but the majority don't.

Peter 15:02 Yes, but I do agree with you. I mean, if the hybrid model is one size fits all because that's why we made it a hybrid, then yeah, it's almost certainly not going to work because you'll have parts of your organization where it's a bad fit. And I have examples of that too in a different bank actually, where they've got exactly that problem. Where the central organization has mandated that delivery should be done this way, and it's effectively a knockoff of SAFe. So, call that what it is.

Dave 15:34 I can imagine, yes.

Three Practical Takeaways To Test Fit

Peter 15:36 Yeah, and the outcome of that is effectively that for some of the people I know in one part of that organization, this is a really bad fit for them. It just does not work. And so they're sort of looking at this model that they're being forced to operate under, and it's just creating work for them that they don't need. That's usually more of the problem, where people try to shoehorn everybody into one way of doing things, and that's just not a good thing.

Dave 16:05 And I think more and more in the conversations that we've been having when we talk with leadership, especially as we've mentioned it a few times, the Cynefin model is one part of it, but there are a number of models you can look at where you start recognizing that it is the idea of bringing a single system, standing up a single system, that doesn't make sense. You actually need to be able to support different ways of operating to solve different problems.

Peter 16:32 Yep. And one last note because I think you were right, and we're not going to be able to talk about AI and operating models today. But I did just want to mention that having an understanding of your operating model and having it work well before you go and throw AI in there to just mess everything up even further, is a very good thing to do. With that note though, because we're at time, three things. Three things.

Peter 17:03 Sure. I think my main point that I would love everyone to take away is it's not one size fits all, and it's finding the thing that works best for you. But don't do it blindly, and also experiment, try something. If that thing does not work, make sure that you've given it the opportunity to not work. Don't be afraid to say this doesn't work and try something else.

Dave 17:27 Until it does work, not try something else right away. No, not just because. Explore the space until you find the tools that work.

Peter 17:34 Intentionality. Like, why am I organizing things this way? Why am I putting these rules in place? What am I looking to get out of this? How am I going to know that this works? It applies as much to your ways of working as it does to the products that you produce.

Dave 17:52 I just want to draw attention to one thing you mentioned along with those, which is using an experienced coach, consultant, somebody of experience, to come in and just help navigate through that problem space. I use the analogy of going to the gym and getting a personal trainer, or getting an expert there to help. We do it in a lot of different places outside of the workspace. And sometimes we forget that and we allow too much of our own internal ways of thinking to dominate, which is where you end up with the hybrid models, one size fits all, various things like this. So I think there's a huge value in getting somebody in who understands systems, who can see from first principles what the consequences are of some of the decisions being made, just to come in and say, I don't think that's working for you, and here's what might be happening as a result. That was probably two things. So maybe the third is I'll keep it very simple, which is just calling out the plan as one of those artifacts that really helps you determine where you sit. If your plan is changing all the time, move towards the product side. If your plan is rock solid, stable, consistent, move to the project side. Maybe that's the last comment.

Closing And A Nod To AI

Peter 19:13 Yeah. I've got to roll this out to a thousand sites. Each site is identical. I've just got to knock them off one at a time. Yep. Awesome. Well, thank you, Dave, as always. Interesting conversation. Looking forward to the next one. And maybe then we will talk about AI operating models. Maybe, yeah. Okay, until next time. Can't wait. You've been listening to Definitely Maybe Agile, the podcast where your hosts Peter Maddison and David Sharrock focus on the art and science of digital, agile, and DevOps at scale.