OKR is essentially change management. Therefore, to ensure that OKR is the right framework for a large organization, they typically choose to run an OKR proof of concept (POC) with a department or team first.

We spoke to Jean-Luc Koning, OKR coach and co-founder of IN EXCELSIS, who ran the OKR POC with the IT team at The City of Quebec, the capital of the Canadian province of Quebec. After all, a city (governmental organization) is an organization, with similar concerns as any other organization. In this podcast Jean-Luc explains:

• Why the City of Quebec decided to run an OKR POC in the first place
• How their POC was set up
• What their expectations of the POC was
• What approach he took with their IT team
• The ideal length for an OKR POC
• Who exactly was involved in this OKR POC
• What processes were deliberately left out
• What feedback teams and team leads had regarding the POC
• Based on his learnings, what he would do differently in the next POC
• What success factors are needed for running a successful OKR proof of concept
• And, what the current status is of the City of Quebec after the POC

Tune in to learn more!

-

Looking to execute strategy using OKRs and KPIs? Head over to Perdoo and create a FREE account.

Learn more about strategy, goals (OKRs & KPIs) & performance — visit the Perdoo Resources Hub.

Copyright 2024 Perdoo

Welcome to another episode of Goal Diggers.

I'm Henrik, founder and CEO of Perdoo and I'll be your host today.

In this episode, we'll be talking about how to run a successful proof of concept for OKR.

Our guest today is Jean Luc Koning.

Jean Luc, could you tell us a bit about yourself and what you do professionally?

Well, I'm a university professor at the Grenoble Institute of Technology in France, and I originally completed my PhD in information

science, and then I worked for a while at Carnegie Mellon University in Pennsylvania.

But 10 years ago, I co founded a training and coaching company in Paris called INEXCELSIS.

Right from the start, this company has been dedicated to enabling organizations to achieve highest levels of productivity and performance.

And in 2019, we decided to take on the challenge of supporting OKRs in French speaking countries.

Since then, I've been lucky to have Ben Lamorte as my mentor as far as OKRs.

And I've become a certified OKR coach, working alongside him, rolling out OKRs for some joint clients.

Now, IN EXCELSIS is known for having deployed OKRs with very large organizations like Michelin, the tire manufacturer with European SMEs as well as FinTech scale ups.

Let me also mention that two years ago, we've been chosen by Christina Wodtke for translating into French her second version of Radical Focus.

Good.

I love that book.

Yeah.

It's a such a good book and it's not..

In French we don't have that many books about OKRs, but she's very picky about having her articles and books translated properly with the right wording and meaning.

So we've already published a few of our articles in French on our site, OKRconsulting.fr and now we are in the process of publishing our book with a French publisher.

And IN EXCELSIS relies now on about, 15 trainers and coaches and three of whom work more particularly in the field of OKRs.

Yeah.

But you mentioned that you work in French speaking countries.

So that includes, parts of Canada then at least.

And, that's also how we got connected on LinkedIn.

I think.

You ran a proof of concept for the city of Quebec.

Not a typical organization to work with OKRs I'd say being a governmental organization.

Could you tell us a bit about the background of that project?

Yeah, you're right.

Working with some administrations like this is really different, but not really as far as OKRs.

I mean, people ask the very same questions.

And, well, Quebec City is the capital city, of course, of the Canadian province of Quebec.

And, this represents more than half a million inhabitants.

The city is in charge of a lot of departments such as the police, the fire departments, education, schools, roads, parks, administrative offices, and so on.

So it's really like a small government in itself.

And, the council is in charge of all those services and departments.

Without taking into account the blue collars, this represents about 800 people in charge of all those services.

And it turns out that they are heavily working in a Microsoft world, and they use a lot of tools, a lot of indicators, KPIs all over the place, lots of dashboards.

So the IT department was particularly keen in looking at OKRs, and obviously some other departments were also wondering what that strange animal was when talking with OKRs.

So it first got implemented in the IT department?

That's right.

The IT department accounts for about 80 people.

I guess there were three or four main services and within all those services, there were 16 teams and they were really all interested in deploying OKRs and knowing what this is about.

Good.

And so they decided to do..

Instead of to just go with it, right, and implement OKRs in the organization, they decided to run a proof of concept first.

And that's where you got involved?

Like they hired you to run that proof of concept?

Yeah.

Gotcha.

Yeah.

I think they were a little bit reluctant at first to go straight for a full deployment of OKRs.

They wanted to know more about OKRs, they wanted to see how that would fit.

Plus I must tell you that they were afraid of adding still another layer on top of all the indicators they already had.

Yeah.

Of course.

Yeah.

But what was the goal of the proof of concept?

And how did they set it up?

Like, who were the key stakeholders?

What were the expectations from people?

When did, when did they say that the proof of concept would have been a success?

Yeah, I think they had no idea what OKRs meant.

Of course, they had heard about this buzzword, but didn't know how that would fit with indicators and all the rest and the projects and so on.

So the number one concern was how they could benefit from working with OKRs.

At the same time, they were afraid of whether that will represent too much work.

So we had to invest a lot of preliminary meetings dedicated to convincing them about the power and relevance of the OKR approach.

And last but not least, they aimed at testing an actual OKR platform to see to which extent it could be useful to them.

How simple or complicated the implementation and configuration would be.

Since they were people from the tech, from IT, they were expecting something easy to use and they had strong expectations.

They wanted to see all the advantages and downsides before plunging into this.

And what was the I mean, what was Of course they wanted to see like what OKRs could bring to their organization, but what were the actual expectations?

I mean why embark on this journey, right?

And why invest the time to find a good OKR software and a consultant like yourself to help them?

What was the hope?

Like, what would they expect OKRs would do for them?

I think at some point they realized that they were swamped With much too much indicators and measures, plus also they realized that although they had a lot of goals and strategic

goals and objectives, they were not too pleased with the way they were running projects that were not directly aligned with those goals.

So it was a matter of alignment and also a matter of Communication, because that's one thing to have a lot of goals and measures on

one side of the organization and not having everybody share those pieces of information.

Gotcha.

So okay.

So it's a lot to do about like creating transparency on, on the higher level goals of the company and making sure that what people and teams

are working on is actually going to contribute to those higher level goals and strategy.

Gotcha.

And you were in charge of running this POC, right?

How did you approach it?

Could you share more about that?

Yeah, of course.

Actually, this project was run from March till October this year, 2023, and it involved an assessment, completion of an OKR guiding

principles document to support change management and development of a roadmap in IT.

They really wanted to have Something they could base their decision of further rolling out the OKRs.

And so they wanted a full document with the guiding principles.

We also did some training of IT senior leadership.

Some coaching of the executive sponsors.

Yeah, go ahead.

What are these guiding principles?

Are these like rules or did they explain..?

Yeah.

General rules about OKRs and in their case, since we did some audit first, some kind of assessment, we could identify a

few spots where their objectives and their metrics were not really fully operational.

So, and that was a good help for us to convince them that it was worth it taking a look at OKRs.

Gotcha.

Okay.

Sorry, I interrupted, but you were saying like the guiding principles you said that you developed a roadmap.

That's right.

Basically, we had a few milestones.

I would mention five of them.

First, the assessment part assess the current organization, existing methodologies, goals, strategy, work, foundational documents, and rhythm of the business meetings.

The second stage was the, the guiding principles for the organization.

Third stage was the training.

Foundational OKR training and workshops with senior leadership team to establish the IT organization's annual and quarterly OKRs supported by e-learning and support materials.

We provided them with some tools.

We did also some coaching.

For the OKR executive sponsor and the OKR project manager to set OKRs for the teams and, we worked on their platform

to support with the implementation and training on the chosen OKR platform.

So the proof of concept was not a full rollout.

But we wanted to have them a better understanding of what that would imply to dive into OKRs and full employment that they are considering for 2024, actually.

Where did you draw the line for, or how should you, or where should you draw the line about who to involve and who not to involve?

We decided to stick with The team leaders, only with team leaders.

As I said, there are 16 teams within the IT department, the City of Quebec.

And pretty much all of them were present during our trainings.

That was a really general training.

We did actually two.

And that was worth it to have two trainings because they had, during the first one, they had a lot of general questions regarding objectives, goals, metrics, and so on.

And during the second meeting, training meeting we We really showed them some examples.

We worked on defining OKRs and so on.

But where I drew the line was that we didn't implement actual OKRs that they are using right now.

We decided to stick with two objectives, one or two.

Key results that would speak to all of them so that they can play with that.

But now prior to the full deployment we would need to undergo a phase or a step where we would define the actual OKRs for them to work with.

Gotcha.

But you said that you just decided to only include the team leads.

But who from the senior leadership team was involved?

And..

So the head of the department was involved and even someone from the governance.

So this is really another department, but they wanted to see what was in the training and the coaching and so on.

So as for a future to have a future possible deployment in other departments as well.

Gotcha.

Okay.

But, but it was clear that you didn't want to involve everyone.

Right.

Since this was a proof of concept.

Were there are also parts within the OKR framework or within the OKR process that you said, like...

were there certain OKR processes that you deliberately decided to leave out because the organization was new to OKR and it was just a proof of concept?

Yeah, that's that's really a good question.

I mean, the purpose of the POC, the proof of concept is to show the client the added value of the OKR approach as quickly as

possible so as to help them make up their mind whether or not to pursue the OKR adventure.

The aim is not to produce the best objectives or the best key results they're going to use or check in for the rest of the ongoing year.

So we left aside the, for instance, the deployment parameters that are so dear to Ben LaMorte, that he's explaining in his OKR field book, and we

went straight to coaching the project leaders and to help them grasp what all this was about.

Got it.

And how did it go?

What was the feedback from the people that were involved?

How did the team leaders respond to this?

I must tell you that there was some resistance at first.

Did you expect that?

Yeah.

Well, not that much.

Not that much.

And I didn't know how to cope with this.

At first, I tried give them some good reasons why we would need to do so and so.

And I tried to convince.

And I entered in a lot of Talking in exchange.

But if I had to do it all over again, I think I would dive straight to actual examples.

At first I heard things like we already have measures, metrics, indicators, KPIs, and the rest.

We already have a bunch of objectives and targets.

And they indeed had a lot of those, but they had too much.

Plus they thought that OKRs were just something to add on top of the rest.

Where Once I realized that I needed to show them that numerous of their objectives were ill defined and then that's where they began

to understand and realize that it was not as they expected and as easy as they, as they are, were used to defining objectives.

So we corrected some objectives.

I gave them some indications on how to choose better indicators.

And that's where things began to kick in.

And they were really interested in carefully crafting objectives and key results.

Of course, that's an art.

And I really do believe that defining OKRs is really an art.

You cannot become good at this just overnight.

And that's what I realized with them.

But the resistance was then really stemming from them not fully understanding, like, what the implications would be, right?

So you didn't just implement OKR, but you also, like, revamped other things that they were already doing in terms of, like, tracking metrics, KPIs, etc.

Henrik, to tell you the truth.

That's mostly the approach I use when I have prospects and or future clients.

Actually next week I'll be talking to a bank, a big bank in France.

And I've already had a preliminary talk with them, and usually I do the first question I ask is well, can you show me some of your strategic objectives?

Yes.

Here they are.

Okay.

Can you explain to me why you chose that?

And how are you going to measure this objective in the near future?

And why don't you frame this objective this way or that way?

And just by asking some questions, they realize that their objective is some kind of flawed to some extent.

So to some extent.

And that's where they pay attention to what you have to tell them.

And to what you're going to do with them when working with OKRs.

Now that you've gone through this proof of concept, with the city of Quebec and you just said that you're talking to a big French

bank right now, I imagine that French bank wants to run a proof of concept as well..

What would you do differently this time around for the proof of concept?

I mean, you already gave one clue away because you mentioned that, you wanted to dive straight into some goals that they're already working on.

But what else would you do different?

I think I would keep the momentum going, and that's the big lesson I learned.

Initially, we were supposed to complete the proof of concept in less than six months from February till July.

And since the leadership team was not fully aligned with the proof of concept, we had a heavy load, as I said, to convince everyone.

But I think that Having them keeping the hands on actual OKRs, running the training pretty soon and having them realize what

it's really about is really key to fully understanding and also adopt the OKR approach.

But I mean Regarding the length of the proof of concept, that's the first thing that you mentioned, but initially you

wanted to complete it in six months time, you ran a few months over, right?

Like eight, nine months, I guess.

But do you think six months is enough time for a proof of concept?

I think it's much too short, but you know, that's usually part of the deal.

When a company wants to run a proof of concept, first I tell them we need to go for two cycles.

During the first cycle we're going to miss the objectives.

We're going to learn a lot of things..

And cycle is a quarter, right?

A quarter.

Yeah, that's right.

I'm sorry.

Yeah, and but usually what I get as an answer is Well, we want to see much quicker than six months.

We want to see whether it's worth it or not.

We don't want to have our people to be involved in a eight month program, and so that's why sometimes I do restrict the proof of concept up to just one full cycle plus one or two months on each side.

Yeah.

I mean, what we always say is that like six months is what you should count for, like going through the OKR process for two cycles that helps you like

tweak the approach, like discover the things that don't work and tailor them to your organization.

But would you agree that doing a proof of concept in two cycles, so in six months in total, that that could be sufficient if you do it well?

Yeah, I would tend to say yes, because, you've got plenty of time to, plus you've plenty of time also to train Some people inside the company to become the future internal coaches, OKR coaches.

Of course, they are not fully operational, but at least they have grasped the right questions to ask, how to run a meeting.

And, during the second cycle, I take them alongside me and, sometimes I give them the power to run part of the meeting so they

become fully acquainted with the right questions and how to run those meetings.

Good.

For anybody that's listening right now and thinks like, yeah I really want to do a proof of concept of OKR in my organization.

What do you think are the key success factors for running a successful proof of concept that they need to keep in mind?

Yeah, very good question.

I think that first of all, you need to find the right people to talk to.

Identify someone who would be a promoter in the future.

Someone who is sufficiently high in the unit or department or team to be influential enough to trigger the buy in from the rest of the people.

And work with him or her extensively.

Don't count your hours.

Invest extra time answering their questions.

That's what I did with the City of Quebec.

We had in between all the official meetings, we had a debrief, we had a preliminary meeting in order to prepare things.

So you provide them with all the information and answer is that they need to when they report to their own boss or manager, so they need to feel you're on their side.

And that's exactly what I did.

And that proved to be a successful approach.

And as I said earlier, less talking and more showing.

That's the key element here.

And keep the momentum going.

That's that's another thing that's crucial then.

Before we let you go, what's, what's the current status of the city of Quebec?

I mean, you briefly mentioned that they were considering like a full rollout at the start of next year.

How are these discussions going?

Is it all headed in the right direction?

Yeah.

They are in between two stages at the moment.

They've done the -proof of concept, so they've got some basic training about OKRs.

They have seen how to craft them.

They've seen how to implement them on a few samples using a dedicated platform.

And now they are in the middle of deciding to which extent they want to roll out OKRs.

I think they are also faced with the question of Which platform would be the best?

They had a platform in mind.

We worked with that platform, but that's part of the question they have to answer.

They have to also to answer at which level do they want to deploy the OKRs.

Most probably early 2024, they will proceed with deploying OKRs for the IT department.

But, I suspect they want to have this on a larger scale from what I perceived.

Good.

That's good to hear.

As this is what we always ask at the end to everybody, but what's your final piece of advice to anyone working with OKRs or considering to work with OKRs?

And it doesn't have to be related to proof of concept.

My advice would be don't get fooled by what you've read on the internet or in books like Measure What Matters or so on, because OKRs is so easy to understand.

I mean, in less than two minutes, you know what an objective is, you know what a key result is, and you, as I see with most of

my clients, they do some attempt to deploy OKRs and then they come back a year after and they say, well, this is very difficult.

We're about to throw this to the trash, everything, the OKRs approach and so on, but we feel that there is something behind what that we've not uncovered or discovered.

And that's usually the case.

So don't rush into OKR deployment by yourself.

Choose the right person or the right company to work alongside you and you'll avoid most mistakes.

You'll, reap the fruits of this beautiful approach.

Yeah I totally recognize that.

I think.

I think when you explain the concept of OKR to someone like you're often, it's also, you see that a lot on the internet, right?

You read about individual examples.

And I think if you set OKRs just for yourself or you're like a one man show, then it is super simple, right?

It is super easy, but like, why do a lot of companies want to work with OKRs?

They want to increase transparency.

They want to align the organization, which means that you end up with this whole hierarchy of goals and how things connect.

That's where I think it gets really complicated.

Yeah, I agree.

Jean Luc, it was a pleasure talking to you today.

It was good to learn more about what it takes to run a proof of concept.

So thanks a lot for joining us today.

And, I hope to welcome you again on another episode in the future.

Thanks very much, Henrik.

And my pleasure.

Talk to you soon.

Bye bye.