OKRs and goal-setting in the public sector
Help the team formulate, review and follow up on goals. Move drafts from activities
to observable outcomes, but do not invent baselines, target values or
measurement data. Examples are available in
eksempler.md.
Discover the goal context
Do not assume a four-month (tertial) cadence, OKR format, goal document, tracker
or project fields.
- Read the request and relevant consumer-owned instructions and documents.
- Find the team's documented goal period, terminology, adopted goals, owners,
data sources and follow-up cadence.
- If an issue template, link or remote name only suggests a repository,
document or project, treat it as a candidate and have it confirmed.
- Ask one missing factual question at a time. The minimum context is the
desired outcome, target group, period, decision owner and available
measurement basis.
Distinguish adopted goals, working drafts and your own suggestions.
Formulation guide
- Measure outcomes, not outputs. A deliverable is one possible means.
- Default to user and societal value rather than revenue in the public sector.
- Keep the number of goals low. One to three objectives with two to three key
results each is a useful rule of thumb, not a policy.
- An objective is qualitative; a key result describes a measurable outcome.
- Ask for a baseline and target value. If either is missing, mark it as
unresolved.
- Clarify how and how often the result can be measured with adequate data
quality.
- Distinguish routine operations from improvement objectives. A measurable
improvement in service quality can be a genuine outcome.
- Adapt Norwegian or English terminology to the consumer's language rules.
Example:
- Good starting point: «Andelen brukere som fullfører uten å kontakte oss øker
fra 62 prosent til 75 prosent.»
- Activity: «Lansere ny søknadsdialog.» Ask what observable change the
deliverable should contribute to.
Lint every draft
Present findings for each relevant rule and suggest a specific rewrite:
| Check |
Clarification |
| Activity in disguise |
What changes for the user or society? |
| Missing baseline or target |
What are the current level, desired level and source? |
| Missing measurement plan |
How, where and how often is the result measured? |
| Too many goals |
What can be deprioritised to create focus? |
| Operations mixed in |
Is this an ongoing obligation or an improvement? |
| Missing value link |
What user or societal value does this support? |
| Proxy measure |
Does the number actually measure the value, and what side effects might it have? |
Do not "improve" a goal by inventing a plausible number. Use clear placeholders
and questions.
Follow-up cadence
Follow the team's documented cadence. If none exists, offer this generic cadence
as a suggestion:
| Timing |
Activity |
| Start of period |
Formulate goals, baseline, measurement plan and ownership |
| Regularly |
Review signals and learning, not only delivery status |
| Mid-period |
Assess the forecast and adjust effort or assumptions |
| End of period |
Summarise results, data quality and learning |
A tracker can connect work to goals, but tracker activity does not itself
document goal attainment. Discover the project and fields dynamically if the
team actually uses them. Do not assume that goals should become field options
or that field names can be changed automatically.
Durable changes
For a requested goal document, issue, PR or project metadata change, reuse the
user's existing authorization for the exact target, action and scope. When a
material choice or authority is missing, show the target, draft and field
changes, then ask only for what is missing. Do not repeat approval for the same
requested result. New targets or expanded scope need their own authority.
If the correct target is unknown, ask. Do not create a new goal document by
default.
Boundaries
Always
- Lint your own suggestions too.
- Distinguish outcomes, deliverables and routine operations.
- Mark missing data, baselines and decisions.
Ask when authority or a material choice is missing
- Write or publish goals.
- Create issues or pull requests.
- Change tracker or project metadata.
Never
- Rate goal attainment without data.
- Invent a baseline, target value, owner or measurement plan.
- Treat the number of completed tasks as evidence of impact.
1---2name: okr3description: Formulate and review measurable product outcomes with objectives, key results, baselines and evidence. Use for goal setting or turning delivery lists into outcome measures; use `team-status` to report progress against existing goals.4---56# OKRs and goal-setting in the public sector78Help the team formulate, review and follow up on goals. Move drafts from activities9to observable outcomes, but do not invent baselines, target values or10measurement data. Examples are available in11[eksempler.md](./references/eksempler.md).1213## Discover the goal context1415Do not assume a four-month (tertial) cadence, OKR format, goal document, tracker16or project fields.17181. Read the request and relevant consumer-owned instructions and documents.192. Find the team's documented goal period, terminology, adopted goals, owners,20 data sources and follow-up cadence.213. If an issue template, link or remote name only suggests a repository,22 document or project, treat it as a candidate and have it confirmed.234. Ask one missing factual question at a time. The minimum context is the24 desired outcome, target group, period, decision owner and available25 measurement basis.2627Distinguish adopted goals, working drafts and your own suggestions.2829## Formulation guide3031- Measure outcomes, not outputs. A deliverable is one possible means.32- Default to user and societal value rather than revenue in the public sector.33- Keep the number of goals low. One to three objectives with two to three key34 results each is a useful rule of thumb, not a policy.35- An objective is qualitative; a key result describes a measurable outcome.36- Ask for a baseline and target value. If either is missing, mark it as37 unresolved.38- Clarify how and how often the result can be measured with adequate data39 quality.40- Distinguish routine operations from improvement objectives. A measurable41 improvement in service quality can be a genuine outcome.42- Adapt Norwegian or English terminology to the consumer's language rules.4344Example:4546- Good starting point: «Andelen brukere som fullfører uten å kontakte oss øker47 fra 62 prosent til 75 prosent.»48- Activity: «Lansere ny søknadsdialog.» Ask what observable change the49 deliverable should contribute to.5051## Lint every draft5253Present findings for each relevant rule and suggest a specific rewrite:5455| Check | Clarification |56|---|---|57| Activity in disguise | What changes for the user or society? |58| Missing baseline or target | What are the current level, desired level and source? |59| Missing measurement plan | How, where and how often is the result measured? |60| Too many goals | What can be deprioritised to create focus? |61| Operations mixed in | Is this an ongoing obligation or an improvement? |62| Missing value link | What user or societal value does this support? |63| Proxy measure | Does the number actually measure the value, and what side effects might it have? |6465Do not "improve" a goal by inventing a plausible number. Use clear placeholders66and questions.6768## Follow-up cadence6970Follow the team's documented cadence. If none exists, offer this generic cadence71as a suggestion:7273| Timing | Activity |74|---|---|75| Start of period | Formulate goals, baseline, measurement plan and ownership |76| Regularly | Review signals and learning, not only delivery status |77| Mid-period | Assess the forecast and adjust effort or assumptions |78| End of period | Summarise results, data quality and learning |7980A tracker can connect work to goals, but tracker activity does not itself81document goal attainment. Discover the project and fields dynamically if the82team actually uses them. Do not assume that goals should become field options83or that field names can be changed automatically.8485## Durable changes8687For a requested goal document, issue, PR or project metadata change, reuse the88user's existing authorization for the exact target, action and scope. When a89material choice or authority is missing, show the target, draft and field90changes, then ask only for what is missing. Do not repeat approval for the same91requested result. New targets or expanded scope need their own authority.9293If the correct target is unknown, ask. Do not create a new goal document by94default.9596## Boundaries9798### Always99100- Lint your own suggestions too.101- Distinguish outcomes, deliverables and routine operations.102- Mark missing data, baselines and decisions.103104### Ask when authority or a material choice is missing105106- Write or publish goals.107- Create issues or pull requests.108- Change tracker or project metadata.109110### Never111112- Rate goal attainment without data.113- Invent a baseline, target value, owner or measurement plan.114- Treat the number of completed tasks as evidence of impact.
navikt