navikt OKRs and goal-setting in the public sector
OpenCode v1: Skill names below are exact IDs from the active catalog, not slash commands. Load them with the native
skilltool. Slash commands are direct user entry points only.
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.