Decisions
Decisions are how In Parallel preserves the "why" behind execution changes — so you can answer "why did we do this?" with a link, not a reconstruction.
What it is
Execution plans change because decisions happen: priorities shift, deadlines move, ownership changes, risks get accepted or escalated. Without a record of those decisions, teams spend time reconstructing context from memory, slides, and old chat threads. In Parallel maintains a Decision Registry — a queryable record of every significant decision, linked to the meeting that produced it, the scope it affects, and the plan changes that resulted.
This is what keeps the Living Execution Plan trustworthy over time — not just what's current, but why it became current.
How it works
Each decision record captures:
Field | What it records |
What | The specific choice made — one clear statement |
Why | The context, constraint, or learning that drove the decision |
Who | Who was accountable or made the call |
When | The meeting or moment where the decision was reached |
What changed | How the Living Execution Plan changed as a result |
Decisions link to the meeting that produced them and to the plan updates that resulted. That chain — decision → plan change — is what makes execution evolution explainable to stakeholders and future team members.
What counts as a decision
A decision is anything that materially changes execution reality:
Reprioritizing work ("A is now more important than B")
Committing to a deadline or scope ("we'll ship by X")
Changing ownership ("this moves to team Y")
Accepting or escalating a risk
Stopping or pausing work
Not every conversational conclusion needs a record. The decisions log is high-signal by design: fewer entries, each one material. A useful test: if someone could reasonably ask "why did we do this?" in three months, it's worth capturing. If it's a meeting observation rather than a choice, it belongs in the meeting summary, not the decisions log.
Decisions most commonly surface through the meeting loop — discussion produces signals, the post-meeting report proposes decisions, and confirmation makes them part of durable history.
Using decisions effectively
Make decisions explicit when they happen Clear language helps both alignment in the room and capture quality: "Decision: we will…", "We're choosing A over B", "This is now owned by…". You don't need a script — just a deliberate signal that a choice is being made.
Capture tradeoffs, not just outcomes The reasoning is what prevents re-litigating later: "because we learned X", "because risk Y is unacceptable", "because the customer requires…". The outcome alone doesn't carry that context forward.
Link decisions in stakeholder communication When execution changes materially, don't rewrite the story. Link the snapshot (what changed) and the decision (why it changed). That pair answers most stakeholder questions without requiring a custom update.
Related