Decision rights: who decides what in technology investment

In many organizations, the question "who decides?" has no clear answer for technology investments. Small changes get escalated to executives. Large programs get approved informally in a one-on-one. Product owners don't know what they're allowed to decide, so they ask permission for everything, or for nothing.

Decision rights fix this by stating, ahead of time, who makes which decisions. They're the backbone of IT governance, and they don't need to be complicated.

Why decision rights matter

• Speed. When people know they can decide, they do, instead of waiting for a meeting.
• Quality. Decisions are made by the people with the best information, at the right level.
• Accountability. When a decision has one owner, that person answers for it.
• Trust. Teams accept decisions they don't like more readily when the process is clear and consistent.

The key decisions in technology investment

Most investment governance comes down to a handful of decision types:

1. Accept a request into assessment.
2. Approve, defer or decline an investment.
3. Set relative priority among approved work.
4. Change scope, schedule or budget of a committed initiative.
5. Stop or pause an initiative.
6. Accept delivered work and confirm release.
7. Allocate capacity across products and teams.

For each one, you need to know who decides, who must be consulted, and who must be informed.

Decide by size, not just by type

The same decision type should sit at different levels depending on size and risk. A simple tiering works for most organizations:

Notice that acceptance always sits with the business owner. They're accountable for the outcome, so they decide whether what was delivered meets the need. See Project sponsor vs. project owner.

Thresholds make it concrete

Define what "small," "medium" and "large" mean in your context, using one or two simple measures: estimated effort, cost, number of teams involved, or risk rating. Ambiguity at the boundary is fine. The forum can decide which tier an edge case falls in. What matters is that 90 percent of decisions have an obvious home.

Consulted vs. informed

Two lists are as important as the decider:

• Consulted people must be asked before the decision. Impacted teams, architecture, security, finance. Skipping them is how dependencies are missed. See Cross-team dependencies.
• Informed people are told after. Stakeholders, requesters, adjacent teams.

Being clear about which is which prevents two common failures: decisions slowed by people who only needed to be informed, and decisions made without people who should have been consulted.

Record every significant decision

A decision right only works if decisions are recorded. A short decision record states what was decided, by whom, on what evidence and assumptions, and what would trigger a revisit. Without it, decisions are relitigated whenever someone new joins, and there's nothing to learn from later. See Designing a project approval workflow.

Common pitfalls

• Everything goes to the top. Executives become a bottleneck and small changes wait weeks. Push decisions down.
• Committees with no decider. A forum must have a chair who can decide when consensus doesn't come.
• Rights on paper only. If executives routinely override the process, everyone learns that the documented rights don't matter.

How Aizu helps

Aizu uses roles and permissions to control who can approve work, and records approval decisions with their rationale and the assumptions they rest on. Gate checks capture what must be confirmed before commitment, and the activity log shows who changed what and when. Decisions are tied to the initiatives they govern, so the trail is there when someone asks "who decided this, and why?" Related: Stage gates without bureaucracy.