Decision rights name who can approve, defer, reprioritize, or cancel work at each level, and what each of those people can decide without escalating. Most portfolios have an implicit answer that changes depending on who is in the room. Writing it down converts "we need to socialize this" into a named approver with a threshold and a date. Decision rights are part of the People operational driver and are set in the Align practice, alongside the ranking they govern.
How do decision rights work?
A set of decision rights pairs four things: a decision type, a level, the person or forum that holds it, and the threshold below which they act alone. The decision types that matter at portfolio level are narrow. Approve new work, defer it, reprioritize the existing ranking, and cancel something already running. Almost every portfolio dispute is one of those four being made by someone who did not hold the right, or not being made at all because nobody was sure who did.
Two properties make a right usable. It has to be exercisable without a meeting that does not exist yet, and it has to have a limit, above which it becomes someone else's decision. A right with no limit is a bottleneck at the top. A right with no floor pushes every trivial call upward, which produces the same effect through a different route.
Note what decision rights are not. They are not the org chart, and they are not a statement of importance. A director may hold the right to cancel a small initiative that a vice president sponsors, because the right follows the scope of the decision rather than the seniority of the people affected by it. Saying that out loud, once, is usually the hardest part of the exercise.
What are decision thresholds?
A threshold is the boundary at which a decision moves up a level, expressed in whatever unit your organization actually feels: capacity consumed, cost, teams affected, duration, or risk class. Capacity is usually the better unit at portfolio level, because it is the constrained resource, and a cheap initiative that takes your two scarce integration engineers for a quarter is a bigger decision than an expensive one that buys a product.
Good thresholds let the bulk of routine decisions resolve at the lowest level that can see the consequences. If everything escalates to the executive forum, the thresholds are too low, and that forum will start rubber-stamping. If nothing ever escalates, they are probably too high, or nobody is using them.
What does an escalation path look like?
An escalation path names one destination, one route, and one clock. The destination is a specific forum or person, not a department. The route is how the item gets there, usually an agenda item at a standing decision forum. The clock is how long the item may wait before it is decided by default or by the next level up.
The clock is the part most often left out, and it is what separates an escalation path from a suggestion. Without a stated response time, an escalated decision circulates until the requester gives up or goes around the process, and both outcomes teach the organization that the path does not work.
Write the path alongside the right it belongs to, so that every right has a single next step. Where a decision requires a reopening of the stability window, the escalation path and the reopening conditions should name the same person.
What do good decision rights look like?
Good decision rights fit on one page and can be read aloud in a meeting. That is a requirement, not an aesthetic preference. A decision rights document that runs to fifteen pages is consulted by nobody and overridden by everybody. There are only a few levels, because every extra level adds a handoff and a delay, and each right says in the same sentence what that level may decide alone and what it must escalate.
Two signs tell you they are working. The forum's rights are tied to the decision point, so it re-ranks freely at the boundary and only under a listed condition inside the stability window. And the "no" answers are deliberate: when delivery leads cannot start new work on their own, the WIP limits stop eroding one favor at a time. When a real decision comes up, people look it up rather than ask around.
What are the common mistakes?
Writing rights without thresholds. "The portfolio forum approves initiatives" tells you nothing about the initiative that needs a decision on Thursday and involves half a team for three weeks.
Escalating without a clock. An unbounded escalation is a queue, and queues absorb decisions silently.
Confusing consultation with authority. Many people should be consulted on a portfolio decision. One person decides. Blurring those two is how a decision gets made three times and unmade twice.
Giving the PMO the content decisions. The PMO owns the mechanics: the cadence, the artifacts, whether the process ran. The business owns the ranking and the approvals. A PMO handed both ends up defending priorities it did not set, and it loses the argument.
Never testing the rights. Run a real decision through them in the first month. The gap between the written table and what happens under pressure is the actual state of your governance.
Leaving cancellation unassigned. Approval rights are usually written and cancellation rights usually are not, so nothing stops. A portfolio that cannot cancel accumulates commitments until capacity is fully spoken for by work nobody would approve today.
Decision rights vs RACI
A RACI assigns responsible, accountable, consulted, and informed across the tasks in a piece of work. It is a delivery instrument, and it is useful for exactly what it does: making sure a task has an owner and that the right people are looped in. Decision rights are narrower and sharper. They cover only decisions, only at portfolio level, and they add the two things a RACI does not carry: a threshold and an escalation clock.
The practical difference appears under disagreement. A RACI tells you who is accountable for a deliverable. It does not tell you what happens when the accountable person and the sponsor want different things, or at what size a decision stops being theirs. Decision rights answer both, which is why they are worth writing separately even in an organization that already maintains RACI charts for its programs.
Use both. The RACI runs the work. Decision rights run the choices about which work exists, including the portfolio approval that lets an initiative consume capacity in the first place.
For the surrounding vocabulary, see the glossary of agile portfolio management terms. Writing the first decision rights table against your real recent decisions is part of a PPM4Agile implementation.
Sources
- GAO, Agile Assessment Guide (GAO-20-590G), September 2020, on decision authority, oversight, and escalation in agile programs