How to Set Ambitious Goals and Build Plans to Achieve Them

Published in

Wrike TechClub

7 min readJun 4, 2020

Many teams use objectives and key results (OKRs) to define and track objectives and their outcomes. Companies from startups to Google use OKRs. If you’re new to OKRs, imagine objectives as big goals that we want to achieve, and key results as epics or valuable business increments. Here’s an easy example to understand how they work:

We have a big wish to become a rock star. What do we have to start with? Yes, we have to initiate a new rock band, and here’s our objective:
O: Run rock band
To make this possible, we would use an executive helper for the main goal called a key result. For example:
KR: Find a drummer
KR: Find guitar man
KR: Find singer
KR: Do 20 repetitions in April
KR: Record first EP

For a detailed explanation of the OKR framework, I strongly recommend reading John Doerr’s book, “Measure What Matters: OKRs: The Simple Idea that Drives 10x Growth.”

Now let’s talk about how to bring some OKRs to life. When you have only one objective and team to execute it, it seems like nothing can go wrong here. But what if we have one team and five stakeholders and each has one to three objectives to execute? In the worst scenario, the team will have 75 key results to execute in half a year or even a quarter. That sounds crazy!

In our web dev unit, we’ve faced these problems for many years. But before this, we have to fix other hot issues, which I may write about in another post.

If all of these sound familiar, taking this approach may help you.

So, here’s our plan for the new planning workflow, which will help us get rid of inconsistencies and miscommunication:

Assign business scopes
Set up game rules
Stakeholder’s wishlist
Session #1
Session #1.5 — team plays
Planning Session #2 — let’s validate
Execute, update and profit

1. Assign business scopes

If you have many customers, it means that you have different business directions or business scopes. Sometimes those scopes could be related to different projects or codebases, which are great, but sometimes they’re not.

Let’s assign. For instance, you have three business scopes related to different stakeholders. Try to assign each one to a team that would handle it from the hypothesis and idea stage to the deployment and metrics results. This will allow the team to completely control their scope, and as a result, we’ll get tremendous ownership.

2. Set up game rules

So, we find out the business scope, set up the team, assign first to second, and release ownership. Now we could set up the game rules. Rules would nominate regularity of planning, events, and some other details, which are important to stay on the same page. Here’s a template for suggested game rules based on the experience of our organization. You could start from a template and fine-tune some details after a trial period (i.e., half a year).

Game rules 🎲

Use OKRs for planning every quarter.
“Objective” is a big goal that we want to achieve. “Objective” could be more than a quarter, but it’s good to have concrete timelines.
“Key result” is a concrete, measurable way of how we want to achieve a big goal. It must be finished in a quarter.
Each stakeholder has its own OKRs and updates them quarterly. Sometimes OKRs could merge between two or more stakeholders, depending on business directions.

The next rules would be the actual process of quarter planning.

3. Stakeholder’s wishlist

After deciding the rules, let’s move on to planning, starting from a wishlist from each stakeholder. The wishlist has to contain the most important items that the current stakeholders need assistance with for this quarter. It could be written as a document, task, issue, note, or even papyrus. The wishlist must only match two things: It has to be shareable and clear for everybody. It could also contain any details, i.e., on the realization side, anything you want to add to make it more clear.

🚩Important tip: Each new project or idea (key result) has to have a measurable impact on business and/or company goals (objective).

4. Session #1

Participants:

Dev team (including the product owner or project manager, designer(s), developers, QA engineer(s), Scrum Master, etc.)
Stakeholder(s)
Facilitator

Timeline: 1 hour ±30 minutes

Agenda:

Objectives. Important to share here not only dry endpoints but also talk about mapping with company goals and/or higher-level objectives and how this helps us accomplish the company mission. It’s a motivational meeting, so feel free to come up with any form of storytelling.
Key results. If a stakeholder has key results or wants to discuss them, they’ll be asked to share all the information that they have.
Prioritization. Discuss what’s important and what to sacrifice. If there are any deadlines, it’s also great to show them here. And remember: If everything is important, then nothing is.
Questions. Clear up all the details.

🚩Important tip: If you don’t have key results after Session #1, it might be a good idea to make a draft before Session #1.5.

5. Session #1.5

Participants: The team (only those who are in charge of wishlist increments)

Timeline: 1–2 hours (depending on complexity)

Agenda: You have the objectives, and if you’re lucky you’ll also have the key results with priorities. Now, the only thing you have to achieve during this session is a draft of your calendar/roadmap for the upcoming quarter. Here are some recommendations on how to do this.

Give everybody a voice. Make sure everybody has a chance to participate — if their opinion could be ignored, why would you bring them to this session in the first place? You can invite a facilitator or do this yourself. The facilitator could be valuable here and save your time and health.
Build a calendar/roadmap. Drawing on a wall or whiteboard might work well, but it’s 2020 — how are you going to scale the wall? We used Wrike Calendars or Miro, but Google Slides also work. (See screenshots #1 and #2.)
Take notes. Important ideas and discussions should be written down and processed afterward. Also, if any questions from the stakeholders pop up, you can bring them to the next session.
Take time to do the research. Sometimes development isn’t enough and we also require research (architects and seniors, I know you like it! 😉). If everything is clear and you don’t have plans to innovate, then you can skip this step, but ask yourself, “Am I performing my job in the best way?”

Screenshot#2 — Miro Roadmaps (Calendar could display even hiring plans and vacations)

6. Session #2

Participants: Same as those in Session #1

Timeline: 1 hour ±30 minutes

Agenda:

The show must go on. The team shows the calendar/roadmap and describes it. Here you could describe anything that seems important: deadlines, decomposition details, required research, preparations, etc.
Gather feedback and corrections. Allow the stakeholders to give their questions, feedback, and corrections to the roadmap. Collaborate with the team to fulfill a final version that makes everybody happy.
Fasten it up. After coming to a consensus, make sure to give everybody — especially the team and stakeholder(s) — access to the roadmap/calendar.

7. Execute, update, and profit

Now, with the roadmap in your pocket, it’s time to execute. During the breathtaking adventure of achieving great results, don’t forget to keep in touch with your roadmap. Check it weekly if you’re utilizing the Scrum framework; sprint planning is the best way to check the roadmap. Bring all the updates and show them to the stakeholders to keep everybody on the same page. Because the roadmap is the map of your road and will take you to your desired lands.

FAQ:

What if we have to do more important things and postpone what we planned? There are many reasons why this might happen, but it looks like you don’t know what’s important to your team. Try to figure out the scope, stakeholders, and high-level goals for your team first (one more time). It would be beneficial to discuss these aspects with your manager and/or team. When you finally figure this out, repeat the planning from scratch.
We have so many incoming requests and tasks always have an urgent deadline, so we can’t even plan them. How could we fit this into a scheme that you so beautifully described? Some teams work like this, but they typically have a very high turnover rate. You have to fix this ASAP first and do the tasks afterward. Try to understand why you always get tasks with urgent estimates, where they originated, and why they matter. You have to build a stable workflow for your team. After that try this scheme again.
During the quarter or year, our company plans to change. Do we also have to change the roadmap/calendar? Yes, force majeures happen. If the company vectors change, you have to mirror it on your priorities, daily work, and the roadmap. It won’t be easy, but you could make edits to your calendar with stakeholders and teams like in Session #2.

Additional comments

Don’t forget to always match goals and validate them on a company level. When a company is in the progress of horizontal scalability and you have plans to develop new features, you should ask yourself, “Is it really important?” and “How would this feature integrate into common infrastructure?”
If you just set up the team and have a large number of people send in requests, let me know in the comment section and I could share another story about this problem. You could start with finding the person responsible (key stakeholder) for the full scope; they would handle all incoming requests, summarize them, prioritize, sort, and then bring them to the team.
It’s important to note that the flow that I describe here was used for IT (digital product development) and it works well. We don’t simply try it in other spheres. If you succeeded in a different environment, please let me know.