OKRs for IT: tying projects to outcomes that matter

Many IT organizations adopt objectives and key results with enthusiasm and abandon them within a year. The OKRs end up as a list of projects with percentages attached, reviewed once a quarter and ignored in between. The framework isn't the problem. The connection between OKRs and the work is.

Used well, OKRs for IT answer a question every portfolio struggles with: why are we doing this project, and how will we know it mattered?

Objectives, key results, KPIs and projects

These terms are often blurred, so it's worth separating them:

• Objective: a qualitative statement of what you want to achieve. "Make it effortless for customers to resolve billing issues themselves."
• Key result: a measurable outcome that shows progress toward the objective. "Increase billing issues resolved without an agent from 35% to 60%."
• KPI: an ongoing health measure you monitor continuously. "Average handle time for billing calls."
• Project or initiative: the work you believe will move a key result. "Rebuild the billing help center."

The critical point: projects are not key results. "Launch the new help center" is output. The key result is the change in customer behavior the help center is meant to cause.

The most common OKR mistakes in IT

Writing projects as key results

"Complete the data platform migration by Q3" measures activity. If the migration completes on time and nothing improves, the key result says you succeeded. Ask instead what the migration enables, such as "Reduce time to produce the monthly sales report from 4 days to 1."

Too many objectives

An IT team with twelve objectives has none. Three to five objectives per quarter forces real choices.

OKRs disconnected from the portfolio

If OKRs are set in one meeting and projects are prioritized in another, they drift apart. Every significant project should trace to a key result, and every key result should have at least one investment moving it, or an explicit reason why not.

Only IT-internal objectives

"Improve system uptime" is a reasonable KPI, but IT objectives should mostly describe impact on the business or customers. Technical health belongs in the sustainability conversation, where it competes openly for capacity.

How to link OKRs to your project portfolio

1. Start with business objectives. Work with business leaders to agree on the three to five outcomes technology should help achieve this period.
2. Write measurable key results with baselines. A key result without a starting value can't show progress. If you don't have a baseline, the first piece of work is measuring one.
3. Map each initiative to a key result. At intake, ask which key result the request moves. Requests that move none aren't automatically rejected, but they need a strong reason. See Building an IT intake process.
4. Prioritize by contribution. When comparing initiatives, use their expected contribution to key results as the main input to value. See IT portfolio prioritization.
5. Measure actuals, not just completion. Record key result values at regular intervals and review them alongside delivery progress.

An example

Notice that the ERP upgrade appears under a business objective. Its value is the close duration, not the upgrade itself.

Reviewing OKRs without making it theater

A good OKR review takes 30 minutes and asks three questions per key result:

• Where are we against the target?
• Are our initiatives actually moving it? If not, why not?
• Should we change the investment mix?

That last question is what makes OKRs part of portfolio management rather than a reporting exercise. See Closing the loop.

How Aizu connects OKRs and investments

Aizu lets you define objectives, key results and KPIs, then connect each initiative to the outcomes it is intended to move. Outcome targets and recorded measurements sit beside delivery progress, so a review can distinguish work completed from value achieved. Related: Outcome metrics vs. output metrics.