OKRs don't clash with the methods you already have. A second list of priorities does

I'll start with a sentence that rarely gets the room excited. Working on an OKR is project work. It is limited in time, it has a defined result, a defined team and defined roles. That is the definition of a project, one to one, just under a different name. Project management has been around for seventy years, and OKRs have not invented any new mechanics at that level.

This has a consequence you can see in every implementation. If project management doesn't work in a company, meaning there are no standards for running projects, no project charters and no described responsibilities, then implementing OKRs gets hard. Not because OKRs are complicated. Because they need exactly the same competence the company lacks. A new framework won't build it for anyone.

The sense of conflict comes from something else, and it is worth naming plainly. Two lists appear in the company: OKRs in one, projects in the other. On top of that, two ways of working and two roles, and nobody can point to the difference between them. People then don't ask about the method, they ask what actually separates these two worlds and why they should work one way one day and another way the next. This isn't a dispute about a tool. It is the result of putting side by side two things that answer different questions.

The OKR framework doesn't help settle this, because it says nothing about it. It tells you how to write objectives. It doesn't tell you where to get them from, and it says not a word about what to do with the projects the company already has. So an implementation always goes beyond the framework itself and comes down to decisions nobody will make for the company. Ninety per cent of the organisations we work with are medium-sized businesses of up to a few hundred people. A company like that has no separate reserve of people to look after the objectives.

One list of priorities, because there is one pool of people

The worst version of an implementation looks like this: the company gets a strategy and objectives, and is supposed to run its projects its own way. You then end up with two parallel management systems in one organisation. People don't know which meeting is for what, which competence to develop, or what to do with the existing portfolio of initiatives. This is not a theoretical problem. It is the working week of specific people, and it has to be divided up somehow.

The day before we recorded this episode, a client sent us a question that shows it best. An employee is responsible for an objective and at the same time runs another project. Which is more important, and is it even the same role. In terms of competence it is one and the same role: in both cases the person is responsible for a result and leads a group around it. The difference comes down to how much of their time goes here and how much there, and that is a decision to make during joint planning. Left to the person alone, it turns into their private dilemma, settled again from scratch every week.

What works for us comes down to one consistent way of managing and one list of priorities for a given period. Let's say that is a year and a quarter. On that list, OKR objectives and ongoing projects sit together, because the company has one pool of resources. In no organisation does a magic group of people suddenly appear to take care of the objectives while still having time for everything they did before. Let me say this straight away, because it is where the most common misunderstanding lies: one system doesn't mean one tool, it means one way of working. OKRs can live in a different program from projects and nothing bad will happen, as long as you run both to the same standard. The temptation goes the other way, towards looking for the perfect tool that will handle strategy, objectives, projects, tasks and a chat as well. That is an escape from an organisational problem into shopping. A tool is the result of a decision, not the solution to it.

There is one more reason this list won't come together without annual and quarterly goals. Without them there is no point of reference for prioritising. What is left is a large set of important things and an arbitrary choice of what we work on right now. That is exactly the gap between strategy and operations we talk about when we draw the organisation as a triangle: at the top it is clear where the company is going, at the bottom it is clear who does what on Monday, and in the middle there is nothing that ties the one to the other.

What to do about it this quarter

Start with an audit of how the organisation works today, not with an implementation. The framework adapts to the existing way of working instead of standing next to it. If there is no standard for running projects, you have to introduce one, and that is the same work you would have to do for the objectives anyway. Better to know about it at the beginning than in the third month. And if you have a PMO, put both under it. Its role is sometimes understood as managing the project portfolio, but the second answer is closer to the truth: the PMO is responsible for introducing and upholding good standards in the organisation. If there is meant to be one standard, the teams working on objectives have no reason to stand outside it.

Then gather everything onto one list and set priorities together, with the board and representatives of the departments. Not for the sake of democracy. So that someone who took part in the meeting can later explain to their team why the decision was made. For each item, write down two things: why we are doing it now and not a quarter earlier or a quarter later, and by when the result has to be achieved and what follows from that date. A deadline for which nobody can say what will happen, or what will be missing, if we don't meet it, was set arbitrarily. One company does this in an order worth borrowing: first it sets and writes down its quarterly objectives, then it checks how much of the quarter's resources is left, and only into that remainder does it add things that are important but not urgent.

The hardest part is reviewing what is already going on. In one company of around five hundred people, the list ran to more than a hundred projects. After going through it against the chosen direction, some initiatives had to be closed: ones that worked directly against what the company had decided, and ones that had started for an unclear reason, with no known sponsor, while drawing on people and money. People can be attached to their projects, so the way you communicate weighs as much here as the decision itself. This is not a judgement of a project's value. It is a consequence of a direction the company stated earlier and clearly.

Finally, set a rhythm, but a shared one. If project managers meet on Mondays, the people responsible for objectives should be there too, and the other way round, so that blockers are visible in one place. At one client, in the weekly and monthly review, we looked at four quarterly objectives and two projects at once, because one of them was a construction project on which the company's next steps depended. Train both roles together, because the competence is the same. Require a measurable goal from ordinary projects too: not we will roll out a system, but what will change because of it. And the thing easiest to let slide: collect the conclusions from finished projects and objectives in one place and review them at least once a month for what they do to the assumptions behind the annual and strategic goals.

The same conversation comes back with every method

This text is about projects, because projects are where it most often starts. The question underneath is broader and concerns everything the company already has: the theory of constraints, Lean, Kanban, Scrum, value measurement, production planning. In this series we came back to it seven more times, each time with a different method, and in several conversations with a guest who knows it more deeply than we do. Each time the same thing came out: the method we were asking about answers a different question from OKRs, so there is nothing to choose between.

The shape of these conversations is surprisingly similar. In some we ask where in the system to apply force at all so that the result of the whole company moves. In others, what day-to-day work should look like for an objective to be delivered, or whether work on objectives is visible at all. In others still, how you know that the objective the board came up with is the right one. None of them ended with the conclusion that you have to pick one and put the other aside. They ended with working out which floor each one works on. Below is a map of where to look for what.

We didn't have this answer at the outset and we didn't take it from the framework, because the framework says nothing about it. We tested different approaches in more than a dozen companies before we started saying plainly that implementing objectives begins with an audit of how the company works today. The effect of that work is less spectacular than it sounds. The company doesn't suddenly have more people or more time. It has one list that someone can defend, and it knows what it isn't doing this quarter.