The Digital Project Manager

How To Use OKRs In Your Project To Amplify Its Business Impact

• Galen Low and Kelsey Alpaio

Share episode

When project goals feel disconnected from broader business objectives, it can be challenging to stay motivated and on track. You may find yourself questioning the purpose of your work, only to discover that the strategic objective is simply to "build an app." If you're struggling to link your projects to the bigger organizational picture, this episode is for you.

Carsten Ley, an expert in project management and OKRs, shares valuable insights on how to use Objectives and Key Results (OKRs) to align project delivery with overall business strategy. He discusses how integrating OKRs into your project management practice can drive better alignment, measure impact, and keep your team focused on the bigger picture.

Resources from this episode:

Galen Low:

It's been a long day, and it feels like the project you're working on is nowhere close to its objective. The team feels like the mission is just to build an app for the sake of building an app, without much more to go on. You are ready to shut your laptop for the day, but you figure maybe you should go back to the outputs from strategic planning just to get some inspiration. Maybe it's just that you and your team are too close to it and aren't seeing the forest for the trees. So with the last bit of energy you have, you pull up some of the more strategic documents you were given — just to get refreshed on the vision and objective for the project. And there it is, plain as day. The big strategic objective for the year was... "to build an app". If you're struggling to connect your project goals to strategic business objectives and vice versa, keep listening. We're going to be exploring how OKRs — objectives and key results — can give your projects a framework for driving alignment, measuring impact, and motivating your teams toward the bigger picture business strategy. Hey folks, thanks for tuning in. My name is Galen Low with the Digital Project Manager. We are a community of digital professionals on a mission to help each other get skilled, get confident, and get connected so that we can amplify the value of project management in a digital world. If you wanna hear more about that, head on over to thedpm.com/membership. And if you're into future-forward conversations and practical insights around digital project leadership, consider subscribing to this show for weekly episodes. Today we are talking about how to link project delivery to broader organizational goals by incorporating objective and key results — also affectionately referred to as OKRs — into your project management practice. With me today is Carsten Ley— project management consultant, OKR coach, and co-founder of both Asia PMO and OKR Asia. Carsten, thanks for being with me today.

Carsten Ley:

Thank you, Galen, for having me on the show.

Galen Low:

I'm so excited to dive into this because I'll admit that this is an area where I don't know a lot, so I'm gonna be learning as well alongside some of my listeners. I think it's such an interesting topic. We've been talking a lot in my community about how to be more strategic, how to tie into broader business goals, how to be a bit more cross-functional and not just isolated delivering our projects. And OKRs is something that keeps coming up. So I thought maybe we could just start with a central question, which is maybe you could tell us what are OKRs and why should project managers and project delivery leaders care about them? Normally this is like someone else's problem to define, and it's like the business strategy that we're not always plugged into, but I'm just wondering what is the so what for project managers, why should we care about OKRs?

Carsten Ley:

Yeah. When companies wanna do OKRs they have to get automatically more cross-functional. So OKRs is a very good trigger point for starting to talk about project management. Unfortunately, a lot of companies don't do it, and I will tell you why. So we have normally in companies strategy, we have a one year target, and before we had under the one year target sub measurements we call KPIs, right? Maybe some of your project deliverables or milestones or increments were connected to this one year KPIs, right? Somehow, and you got measured on that, right? Bluntly, I was also a project manager of PMO. Sometimes I just get measured how many project I delivered a year, but not really how the, and of course, project magic triangle on scope, on time. On budget, but not really on target, on customer, on making the business happy, right? Often we measure in projects only how the project perform without really seeing if the outcome of the project. That's what we wanna change here, strategy one year targets every company have, and with OKRs, a lot of company want to accelerate a little bit and do a three or six months planning only. And before Covid, we had a lot of tech company as clients because it comes from Google and Intel, and it's very famous in the tech, communicate and tech community. Anyway, do something what we call agile project management, which is also faster in the sprints and more accelerated in the outcome delivery and on the customer focus. So fits very well with Agile. Now since Covid, we get approached by a lot of traditional companies doing OKRs. We had pharma clients, we had government clients, we had NGO clients, right? They're like, we, because the world is more volatile and a little bit. Entities, no matter if Agile or non-Agile cannot plan 12 months anymore. So they wanna break it down to a three or six months planning with OKR. So that's the first thing what OKR is doing. You are not planning for 12 months, you're planning on three, six months, and after that, you plan the next three, six months cycle because you wanna measure shorter result to be better in the next planning. The second thing OKR is doing is out of the strategy and out of the yearly targets we develop objective and ideally, these objective are business topics. Objective can be to increase the sales, to increase the efficiency, to launch a product, to do something right? Strategy are an objectives, anomaly topics. So it doesn't have to be immediately siloed into sales, marketing, operations. So we highly recommend not to do OKRs like we do our sales OKRs, our marketing OKRs, our operational. A lot of company want that, but we don't think it's good because what OKR does and now we come to the structure, we have one objective and below one objective, we can have multiple key results. So it means if I make a key, an objective, a little bit broader, and I say we wanna be successful on the market or double our success on the market this year. So marketing gets a KR, sales gets a KR product, gets a KR delivery, gets a KR, and they all have to work together and their KRs are measured together against the objective. And that's how you avoid siloing because you make all the four, five departments or main people who run their key results, right? Responsible against the objective. And that's where project management of course, come in because projects have already objectives. And this is a no-brainer. Whatever we learned in PMI/PMP, how to do smart, objective, blah, blah, blah, you know that from PMP stuff. That's already what we need for OKRs. So if you have a good project objective, block it in the OKRs. The only thing I will ask you is to tune it down to three or six months. So I don't want to know your project objective after two years, like in long term project oh, we wanna launch the product. I said, okay. But what is your objective the next six months? Do you have some preparatory work? Are you already launching something small? Are you showing something to the client? Do you get any sign-offs? I don't know. You can break the objective down to six months, which is doable, right? Smaller. Sometimes we have project phases, so we just take phase one or phase two, and then inside these three or six months, I want measurable. And now comes a little bit the magic and the problem for project folks. We are very used to measure our task and our think of, right? We have deliverable milestones, which consists of 20 tasks. And when the 20 tasks are done, we have our deliverable or milestone and we can measure that in OKR. We call that an input or work key result. So this is what you create as work input. The problem is in OKRs, we also need output key results. So we wanna know, even in the first phase of the project, the first three to six months, how will it help the company? Does it already help the company? Because nowadays I don't think we should lock ourself down two years and then deliver something for the company, right? Projects have to deliver faster and also need intermediate results, right? Feature updates or any product releases or any launches after three or six months. So with this thinking that we are not only measuring what the project is doing, if you say, for example, I did a lot of like product projects. I worked for banks before. So you make a new product, a credit card product, or a deficit product. So the project team always say, oh, I'm in charge to build the product. But what happens with the product afterwards? I don't care. I give it to marketing and sales. That's exactly what we wanna avoid with OKRs. So we tell to the project team, you built the first features of the product. We launch them either with test customer or life. Depends what kind of, if you are a FinTech or a bank, I understand that in traditional bank, you cannot launch live smaller packages. But in a FinTech you can, for example, but you can only launch the test customers and then at least the project team has to get the feedback from the test customers. And measure if they like it or not, or if it's feasible or not, or if it's sellable or not, and then they probably have to rework it in the next phase. That's where also the project planning can only be three or six months because whenever you get an outcome you have to test it with somebody on the marketability or on the business impact. And if this is not given, maybe you have to rework the phase again.

Galen Low:

That's actually really interesting. Your point about measurement, like we're used to KPIs that we can measure instantly and on our own right, we're like, did the project come in on budget? Did we manage to get it done on time? To your point earlier about the PMO, it's have I done the number of projects I was supposed to do? And then we measure it and it's easy, it's instant and there's no dependencies. But what you're talking about, what I'd like is, A, that customer focus, but also B, just that like cross functionality. Because in other words, to achieve a key result in that scenario, the project team would have to finish their sprint or their product increments and then hand it off and then have marketing and sales, for example. Take that to a test customer group, conduct some research, and then come back with the outcome of that. And that will define whether or not we achieved the key result. Not completing that.

Carsten Ley:

Yeah, we would even go a step more, right? The project objective can have project key results, but also sales, marketing, key results. We even don't have to hand it over. Nowadays, we say they all work together inside the project or as part of the overall objective. Right. I give you an example from a client we had, right? They made a very, they were a startup. They made a very fantastic app before covid for events, and the app looked like that. In any event, you get probably thousand, 2000, 3000 photo wedding or business event. And then at the beginning of the event, you get a picture from every participant, or you scan the face of every participant, and then from this three, four, 5000 photos at the end of the event, it sends the photos where you are on automatically to you. That's amazing, right? You know that the pain when you go to an event and they send you a link with 800 photos and you have to scroll through and say, shit, where is my photo? Did they really take my photo? And where am I? Maybe you can even find your lost twin with that one, right? That's also funny function. Maybe somebody who looks exactly like you because suddenly you get other photos and it's also funny, you know what I mean? What a problem of this customer was before we came in. They made an app for photographers, so their product team developed three to six months an app for photographers with very complicated function to manipulate photos, blah, blah, blah. And then we came in because we also do a little bit customer experience and UI/UX consulting. And they were like, yeah, now we have this app. Can you reach out to some photographers how we can market that? We had a lot of photographers in our community because we were also running events, and it was like, shit, I'm a photographer. I don't pay anything for an app where people can find themselves, and I have my own programs on my computer. You know what I mean? I mean, I don't need any app, which helps me to manipulate photos. I have that already. I get paid to make photos. I don't get paid to distribute photos. That's the event organizer. So we went back to the client. I said, I don't know what happened the last three, six months before we were there, but your market scoping was course completely off. We have done a survey with 10 20 photo grabbers. Nobody wants to buy that thing. At the same time, we spoke with a lot of event organizers, like couples for wedding or like companies, and they said, oh, okay, we probably wanna buy that. So we went back to the development team and to the owner of the company and said, I. Maybe the last three, four months was a little bit for the pin your development, but we have to strip down this program now with all the complicated function for photographers, which event organizers won't understand that they don't care. They don't have to make the photos more beautiful. Anyway, we have to make an app now for event organizers to just upload photos and maybe get the photos from the participant or the scan and then just to distribute it. There, that, I don't know how much money they spend on the development, but just developing without having a market research and without knowing really what is the market right there? You have to make the team responsible. The developer can just say, okay, my bosses told me I should develop an actual photograph. But then I'm saying what kind of project team do you guys have? Where's the ui ux guy? Where is the test after two or three sprints with, you don't need a, you don't need a full fledged app yet. You just tested and say, we have two free function. Did you speak with any photograph? They said, no, we didn't speak with any photograph. And that's what OKR can prevent if you make the project target out of the business. Not out of project milestones. Yeah.

Galen Low:

You mentioned OKRs plug in really well with Agile, and I think some folks listening, they might say, oh, but Carsten we don't need OKRs. If we have a cross-functional Agile team, we're customer focused, we are iterative, we build an increments, and we always put it in front of the customer. What does OKRs do on top of a team like that? If they're already getting customer input along the way and they're being cross-functional, they feel like they have shared goals, do they need OKRs?

Carsten Ley:

Yeah. Then on the bottom, they are doing very well, and I give them that, but how is it on the top with the strategic alignment? The first function for OKRs, and maybe I went a little bit too fast into the Epic example, but the first function of OKRs is that teams. Which go from sprint to sprint. And I know from my own experience that a lot of development teams, they have a sprint planning with two, three sprints ahead. So we know agile teams plan around six to three months ahead. Depends how long is the sprint? Two or four weeks sprint. So there's a myth. No Agile team just blends two weeks ahead, right? That's a myth because they have a function, which is called sprint planning, which combines this sprint planning, and I don't say you have to make a lot of extra work, but you can combine your sprint planning for six weeks up to three months with the OKRs and align it with the strategic input from the objectives from the OKRs. I always wanna avoid is that people get more work with a new methodology. OKR has a weekly or biweekly tracking where we measure. Now you have probably every two weeks sprint review. So start this sprint review with OKR, starting with data. If you have already data in sprint review, then we use it for OKR. Don't do anything else. So you are already there. Unfortunately, we see that some sprint reviews are not focused on data. It's just a little bit blah, blah, blah. Sorry to say that, right? So we wanna help them to create the data with OKRs, and if you have a sprint planning which goes six to three months, then it should tie in with the three months objective of the business. And if they have it already. Do they need OKR? I don't know. But it gives you the structure. It gives you the structure from strategy to yearly to three months to sprint planning to sprints, right? That you have a clear and also an evidence that you, with your little two weeks sprints, actually work against the strategy, so you can prove that.

Galen Low:

That's very appealing because like you mentioned, I hear about so many teams. They've been asked to build a thing, they build it, and everyone, someone's actually, you know what, that's not what we need. Or, it's it's not tied to the business strategy. And a, it's not very motivating for the team because they're like, we're just building stuff. We're like a feature factory for our product. And B, they might not be building the right thing because they're setting their own goals in two to four week increments. Not really paying attention or being plugged into the broader strategic goals.

Carsten Ley:

There's one thing I would like to mention about the motivation. We had a climate tech client, right? Amazing climate tech client. They build an app to measure carbon footprint for companies, alright? But it's very meaningful. But then before we came with OKR, they were telling the developers, for the first six months, we develop an app. And I said, that's boring. Every startups is telling that their developers, for the first six months, we build an app. So why should you be motivated to work for a specific startups? I understand why tech people stunt so much. If I would be a tech person and I come to a company and say, oh, now you build another app after 10, 20 app, I would be woo. But if you tell people in the climate tech, Hey, we are environmentally conscious. We want you to help to build an app. That companies can measure carbon footprint, right? And you have to enable that. That's much more inspiring. That's where the objective comes in. You know what I mean? It trickles down from the, almost from the company purpose or from the North Star.

Galen Low:

It's funny because that like really plugs it together. You see publicly traded companies and they've, published their annual report or whatever, or they've got that very some might say just highfalutin like mission statement and like values. And I think a lot of folks in the trenches, so to speak, doing the project, they're like yeah, that's what you tell your shareholders and whatever. But what I like about what you just said is that like the objective ties together that overall mission and strategy to the work being done. And it can be used to inspire people, like it is a tangible, tactile vision, not just words on a page to make shareholders happy or to get more customers or whatever. It actually, assuming that it is actually the mission that's actually quite inspiring.

Carsten Ley:

It's not only inspiring, it can even function as a protection for the people in the trenches. So if I tell you we make a climate based app, and then one day I tell you, oh, you have to develop a game now. So I have the power as in the trenches say, why do I have to make a, I can question things. I'm not just on a lower level where people may, now you grow dead. Now you grow dead. Now you write 100 lines on that. It's not very inspiring on the job. I know I write this code, or I program these functions for a climate based tracking. I can also challenge my bosses a little bit. If they say, oh, now you develop. An act to get coupons from McDonald's, which is maybe not so carbon friend. Can backfire, right?

Galen Low:

I wonder if you could talk to me about the process, because I think in theory I'm loving it, right? Like I think, yeah, no pun intended with the McDonald's thing but I think it actually, it's an interesting idea that ties things all together. Like you said, it doesn't necessarily add more work on top, it's more of a structure. A lot of the folks I talk to, the project managers, sometimes even the PMOs, they're not really involved in business strategy. So what are some examples of some OKRs and like, how can they be arrived at in a way that is also cross-functional? Or are they always just handed down?

Carsten Ley:

Let's stay on the climate tech case. The climate tech, they just got funding. They started, they say within one year we need this carbon footprint app ready. And meanwhile, we have to, okay, program the app. We have to find partners, we have to get funding. All the stuff, all the targets, what in the, and we have to onboard people, all the targets. Startups have the first year, and let's say in a startup that's already a strategy, one or two years because you don't know how long you are there, so you don't have to blend. So you don't have to blend five years if you just start getting funding, so that's your strategy. And then this trickles down to yearly objective, which maybe the team leader know. So at least the team leader and the founders should sit together and say, what do we wanna achieve the next year? Like a draft, because we are in a WCA world, so maybe like an estimation. And then from that one, we plan three months targets, right? So we say Q1, we wanna have a prototype of the app. And then with this objective, which is probably done between the founders and the team leaders, not yet the team. Okay. With this objective, first three months, we want the prototype, and now I go into the prototype project, which is not only the dev team. Ideally I build it as a project with market people, with salespeople, where we get potential customers or partners to test it. And then I ask my team, I make a workshop. As a team leader or with an external consultant like us, what can be the measurable key results the next three months? So it's not a top down process. That's also the beautiful part, and it ties a little bit in what they normally do, also in the Agile and Sprint branding that they involve the team. And then we say, what do we wanna achieve? Objective. We know we wanna build a prototype. How can we measure that? We successfully build a prototype? So you come up with different KR. So first KR is probably about coding and developing wire frame prototype, right? Another KR is like that you test the prototype with a certain kind of numbers and you get a certain kind of feedback. You can measure also like that you find out after the first three months which functions are missing, that you have worked for the next three months, right? Things like that can be KRs, and then the team has this three months targets. Inspirational, the prototype for climate tech plus the key results to measure. And then out of that, they can start with the sprint plan. They can say which of these, because the OKR is like your backlog. It's like your overall target backlog. And out of that you can say, what do we put now in the first two or three spreads? This is how the process work. I don't think we put a lot of more and more work. We put a little bit more work on the team leads because we want the team leads from every team or the project leads in the, at least yearly planning. We don't have to do it a strategy, but at least involved in the yearly planning. Even in bigger companies. We do that, that at least department leads, project leads, PMO leads. Are in the discussion of the yearly planning.

Galen Low:

I like that you involve, if I'm understanding you correctly, if you find an organization that is not bringing those team leads in, your recommendation would be to go in and bring them to the table for annual planning.

Carsten Ley:

Yes. What we always want in the KR process. In some companies you do two, three level OKRs. You do a company OKRs, then unfortunately, they want a silo in department OKRs, which we are not fan, but we can build that for them. We had very traditional companies, so they want it like that, right? Yeah, understand. And of course if they build department OKRs, it's easier for them to assign the responsibility because they do it like the org chart. Which is not very agile, but it's how companies work power are and you know how it's right. So we have company OKRs, department and Team OKRs in some companies, and then we always want two layers together. So Company OKRs is the top people with the department leads, department OKRs is department leaders with the team leads. Team OKRs is team leads with the team. This is a little bit transparency, which is a big word in KR alignment and also bottom up input. Bottom up doesn't mean that when you talk about strategy in the top ecolon of your company, that you ask your cleaning people for input. Of course, that's not bottom up. It's not so extreme. It means that you at least expose the next layer to it. Agile companies. We had a very interesting client in the US called Scratch Pay or Scratch Finance. They were FinTech and then a SaaS. I think now they're FinTech again, a little bit switching the business model. And what they did, they had 150 mainly developers worldwide, and then the marketing and the sales team In California in Silicon Valley. And they wanted to go very bottom up. So the top founders and the top leads were drafting the strategy and the yearly targets, and then we sent a survey out to 150 people worldwide and asked for the feedback on the strategy or yearly targets by survey. This is amazing. So you can also do that if you want real bottom up, right? You can make a survey, I promise. Not a lot of people will respond, honestly. Some people, fair enough, some developers are also like, I don't wanna be involved in the strategy. Why? They have to, maybe they're not paid for it, right? But some people want to. So you give opportunities to give feedback. We get one very interesting feedback, maybe modern times a little bit. They had one objective on the company like smashing the competitor or any word like that, and one female team lead was feeding back in the survey. Let's not use so aggressive language here. That was a very cool feedback that some people didn't feel good in the company with all this aggressive founder talk that you always use Woolworths. It's not necessary. It was a very nice feedback. To tone it a little bit down that the people can identify with that. Like I said, if we build OKRs on different level is always the so next. So if you would build like PMO OKRs, the project manager should be there, and then when we build it for the projects, it would be the project and the project team together.

Galen Low:

I like that idea, overall. Where my head goes is almost around education. And what I mean is, I know I've worked within a lot of organizations that will ask for feedback, but when the feedback comes back, they're like, yeah, these people don't get it. Then I'm thinking, okay, if I was someone responding to a survey, or if I was someone on a team, if I was a team lead, trying to get my team to come up with key results, but they weren't really quite getting it, I didn't feel like maybe their key results were aligning to the objective, or maybe they weren't as measurable. How do you provide education throughout an organization so that people understand what a good key result is? And also so that leaders know that when they're getting feedback from their team, it's not just willy-nilly arbitrary stuff that they don't have to pay attention to, but that everyone actually gets it, understands what the framework and the structure is, and has enough education or training around it to provide meaningful input, so that input gets taken seriously? Do you go in and train people about OKRs or do you kinda have to intuit it?

Carsten Ley:

Normally when we start with a company who hasn't done OKRs, we provide on different levels. The training. We also do that on deliver level because the OK R training is also a buy-in. Like you said before, some project management, PMO, they don't want to do OKR because they think they cover it already completely by Agile, and maybe we can prove in the training it's not fully covered. And there are two, three things. They don't have to change their whole process but do a little bit better, especially on the outcome and on the business oriented side. So us and of course a lot of other KR providers, we have a clear structure, how to build an inspirational objective, which should be connected to the strategy. There should always be the why we are doing it. Why are we building an app, not because we are just a startup and we build an app,'cause there's a purpose behind and ideally a good purpose which inspires people. And then the key results, like I said before, we can measure work with the key results, which is almost like a KPI. So how many projects did you do? How many functions did you develop? But these are not the real good key results. The real good key results is what is the impact of our work? Does the test customer like the fun shops? Yeah. Did the five projects I did this year, did any of this project got launched and make money for the company? That's maybe a good question. That's what we should measure. What we educate a lot beside the structure and the setup is the mindset to say, I'm not only responsible for my little area that I get 400 lines of code then. I'm also responsible how this code impacts the product and if the product sells and there is sometimes a little bit of resistance. It's change management. You always get resistance where people say, oh, I'm just a developer. I'm not responsible how the product performs. That's a little bit the spirit we have to set up in the company. That's why we don't wanna silo sales, marketing product. That's actually the quintessential of projects, right? That you bring people together, that you bring a developer together and a ui, ux and a salesperson and say, we are in this together. Not everybody sits in the project meeting who I don't care about the other part.

Galen Low:

That's the interesting thing about silos is that they're safe because you know the people in your silo, you build this trust about achieving a goal together, but as soon as you step outta that silo, you're like, I don't know if I can trust these folks. It's interesting you mention change management because the thing I had on my mind is that this culture change, assuming you're coming from a team culture that didn't do this, that was a bit more siloed. Maybe effective, but probably like culturally siloed. And you're moving into this more cross-functional interdepartmental model. Do you find that it creates a bit more conflict as it's getting going?

Carsten Ley:

We only see conflicts on a department level if what some of the leads wants to dominate, that's in. So middle management is a little bit an issue. When they wanna build their little kingdoms, how I call it, and they say, no, I don't want product to do anything with my sales KPIs. No. That's only my numbers. Blah, blah, blah. They don't wanna share the success of their numbers on team level. We don't see so much problems. Because in an KR structure, we measure in a system where everybody can see the numbers from different teams, what we normally set up. And there are also on the market like thousands of OKR tools. We don't have our own because there are so many, I mean there are KR tools for Jira, for Microsoft, for everything has a block in with OKR nowadays. So we can really run the numbers. If everybody checks in every two weeks, like after a sprint review operational on a team meeting and puts the numbers inside or how their work is going and how it impacts the business or the outcomes, we can measure that up and display it very transparently. So I don't think there's a lot of conflict that people are scared about, that people are a little bit more scared. When they say that they cannot influence, and that's true. But then there's also one thing we should mention. OKRs are not performance numbers like KPIs. We also have this, I don't know if you heard about this, the stretch KR, between 70 and a hundred percent. There's also a leeway and a leverage that when you don't hit a hundred percent, you don't get immediately penalized on your bonus. Because if you do that, and that's the same in agile management, right? I'm a very big fan of management 3.0. I don't know if you know this methodology where they say award should be frequent. An award should be tied to successes, not to long term panelizing systems, right? This is very important that we reject if a company says we wanna implement OKRs and we wanna change our bonus system to OKRs. And I said, no way. Because then people are scared to work cross-functionally together and people are not bold in trying things. That's what we want in KR and Agile, that people try things and that people have ideas in the project and you shut that completely down if you put a bonus performance measurement behind. This is very important on the cultural thinking that you give people space. We always say also what is a trick, but it works very well. The first three months of OKRs in a company we always call OKR Pilot. Okay? Either we do it on leadership level for buy in or we do it in a team just for testing it. Because first, if you say pilot, people still have to hope it goes away, which doesn't obviously, but it still sounds like it can go away, right? It doesn't go away normally, but it can go away. Second pilot sounds also like we can influencing and things are not so serious yet. Let's play around with it, right? So we always tell our clients, why don't we start with an OKR pilot and you'll tell your staff. We try OKRs first. I know most companies have already decided they go for it. It will not go away, but at least you can smooth it up a little bit at the beginning.

Galen Low:

I like that and I, to your point, sometimes people are using it as an opportunity to gather input and yeah, maybe they've made that decision to go with it, but at least they are gathering input and feedback about how they should go about doing it as well, which I think is actually really quite interesting. To play the devil's advocate a little bit here, I know some folks, they're saying that OKRs are falling out of favor. It was just like fad or trend that people dipped into and now a lot of organizations are just like avoiding them. But also to your point, there's a whole bunch of organizations who haven't started using them yet. For teams of like project managers, or I guess even just like teams in general, how can they advocate for using OKRs for their projects and how they work together if maybe leadership is not bought into the idea or they're dragging their heels, they keep saying they're gonna do it, but they aren't doing it yet. Can a team at the team level, can they advocate to make this change?

Carsten Ley:

You can run OKRs only on a team level sometimes for a pilot. When the leadership team doesn't monitor the pilot, we do it on one team first. And of course, we look a little bit for a more agile team. So like product team where it works well. So the only thing that if you have a project team or even a functional team, the only thing the team has to do is they anyway have already KPIs or krs, which they measure, right? So it's not a new thing. You have to measure something. Nowadays there's a data sheet, right? They use any system like Microsoft Planner, Monday.com, whatever. Everybody uses them. If not, they use Excel. But you have to report every week or every two week, or at least once a month. What are you doing, if you're doing well or not, and maybe produce some numbers. So that's not a rocket science. So we use these numbers, use them as key results, and add, like I said, some more business oriented key results, which goes a little bit above the team or about the impact after the finalization of the project. With that, you always have to ask yourself the right question. So the question is, why do we do this project? Why do we launch this product? Of course, we as project manager and project team, we get paid to launch the product and then we hand it over to operations and sales. But if you wanna live by the OKRs, you say, why do we launch the product? So I ask sales and the sales tell, yeah, we expect at least the first months, we wanna make 10,000. So I would put it in my project K off and I would make a post-implementation phase. And I say, let's be responsible together with sales for the first two months, post-implementation phase. And we wanna do minimum every month, $10,000. And of course then the project team say, oh, that not only depends on us, that also depends on sales. But we work with sales together. We bring them in the project, which is also fun because you learn something from sales, and then of course, sales can feedback you in the first weeks already, or we have problem with this functionality. The customer doesn't like this. Ooh, this is what you want. You don't wanna finish your project anymore. And also, when you wanna be a long-term employee for your engagement, when you speak about employee engagement, you don't wanna just finish projects. You wanna see that your projects have an impact for the company. Or if we speak about climate tech, even for the society, right? If we go one step in any team, even in an operational team, in a functional team, you can start that because the objectives your team leader should know, he should know long-term planning, and if not, then you are should be bold enough to, as a team leader, to go to your bosses and ask these questions because you are entitled to know Project objective is launch a product. So I go to my PMO courses and says, why do we have to launch this product? How does it tie into the strategy? Hopefully they tell you that it ties into the strategy and they're not saying, no, we are just trying something weird, which nobody really cares about. That would be very demotivational, right? With the information from above, you can build your objective very easily, and with the stuff you measure, you already have your first key results, which you measure the project success. And then you also have to measure the business impact and then you see if your team wants to do that. I don't say everybody needs to do OKRs. Some companies are fine to say, let the projects people just do their project and then who hand over to sales operations, we don't wanna bother you with it. That's completely fine for me. But try it with a team and see how people react if they're interested.

Galen Low:

That's interesting. I like the bottom up grassroots collaboration approach, right? It's Hey, let's talk to sales and see what their targets are, and then let's measure it. Even though our project technically, whatever, our sprint, our increment, our release completed, but we're still interested in what it does in its life beyond our team. Inevitably, we're probably gonna be continuing to work on this. And there's this sort of continuity, this longevity of the mission that is tied to the company, not just to like this one sort of project or sprint.

Carsten Ley:

Because when we do that, normally improvements after a project phase happen in a nice collaborative way. What happens normally, especially in a PMI setting, when you make a hard cut of the project and you hand, or when I was there, I worked for banks. Before we had that, we were only the project team and then we handed it over. We fulfilled all the milestones and deliverables. But maybe very beginning of the project, somebody gave us the wrong input. Yeah, or maybe the sales lead change right from beginning to end of the project. So you hand it over to the new sales lead. After two months, they go to your bosses and they escalate the shit out of you and you have a lot of problems and all the fighting begins. And that's not a really nice way to work together if things are not successful, if the project outcome anyway, sooner or later, it'll backfire to your project team.

Galen Low:

That's an interesting way of looking at it.

Carsten Ley:

Why don't you prevent that a little bit more proactively and work with the right folks together for the hand or during the project already to make sure. It will be a success.

Galen Low:

I like that. You touched on one last thing. I thought maybe I'd end with it because we've been talking about top down, at the leadership level, talking about bottom up. A project team might just be curious to try this out. Maybe it's a team pilot. You mentioned PMOs, which is this sort of meaty middle, and earlier you mentioned that even when you were running a PMO, sometimes your metrics were just like, did you turn out the right number of projects? But it seems like OKRs might be a great opportunity for PMOs. That aren't really at the table to become a bit more strategic, and maybe this is a whole nother episode, but I was just thinking, how can PMOs leverage OKRs to be tied to the business so they're not just like a project factory?

Carsten Ley:

PMOs should be a part of the strategic, or at least a yearly planning discussion. That's the first thing we should make sure. And then PMO similar, like departments can have OKRs, and business OKRs. Not only Project OKRs, don't speak about the number of project and how many project manager we have to regrow and how many projects we have to set up. So we can blend this PMO already and say for this yearly target. So one yearly target is a product launch. Another yearly target is a market launch. Another yearly target is efficiency. So PMO Below can brainstorm and say, what projects can we propose a little bit bottom up or from the middle as PMO to launch products to conquer the market, to make the company more efficient. And especially when you speak about efficiency topics, the best suggestions can come always from the teams, right? Or from the project manager. It doesn't come from top down. They don't know much about what's going on below, honestly, often, right? Let's say like that. But you understand what I mean. And PMO is a very cross-functional department who has also governments function. When I was running a PMO in a FinTech later after the bank, we used PMO a lot for survey. We were surveying team members from different teams about their requirements and what they need from projects or from launches. Not only always the obvious team leads and their requirement input, we were surveying more people. We were also running PMO. Sometimes PMO can do more and we can do the next episode. We were running a suggestion box in PMO. We PMO had the company's digital suggestion box, right? You know what I mean? That anybody could come from anywhere and say, Hey, I have an idea for a project, because that doesn't go very well. And we had a little bit budget to give reward for that if that suggestion was taken up and we made a successful project out of that. PMO with this cross-functional power can do a lot. And people trust PMO. We don't politics. We are very neutral. In the KR process. Being part of the strategic yearly discussion and making suggestion to it and also coordinating it at the end is fantastic.

Galen Low:

I love that idea and definitely I wanna dig more into that. We'll do another episode on OKRs for PMOs. I think that sounds really interesting.

Carsten Ley:

That will be amazing. Yeah.

Galen Low:

Love that. Carsten, thank you so much for spending the time with me today. I've had a lot of fun. I've learned a lot. This has been great.

Carsten Ley:

Thank you very much. Pleasure to be here. Thank you, Galen.

Galen Low:

Alright folks, there you have it. As always, if you'd like to join the conversation with over a thousand like-minded project management champions, come join our collective! Head on over to thedpm.com/membership to learn more. And if you like what you heard today, please subscribe and stay in touch on thedigitalprojectmanager.com. Until next time, thanks for listening.