Write a Team Decision Brief Before Calling the Meeting

A meeting becomes easier to use when everyone knows which decision it is meant to support. A decision brief names the choice, the person who can make it, the viable alternatives and the information that could change the answer. It does not need to be a long report. It needs enough structure that participants can discuss the actual tradeoff instead of spending the meeting discovering that they are solving different problems.

This guide uses a fictional operating-team example for Built to Run readers. The team is choosing how to test an internal request handoff. The brief, scores and time window are invented teaching material, not a book excerpt, a client result or a validated decision method. The exercise does not authorize a purchase, change system access or establish anyone's organizational authority. It helps the responsible team prepare a specific choice and identify the uncertainty that still matters.

Write the decision as a question with a boundary

Start with the choice that must be made, not the general topic. “Discuss communication” is too broad to tell participants what outcome the meeting needs. A more useful question is: “Which approved internal request-handoff approach should this team test during the next defined trial?” That wording identifies a decision about a bounded test. It does not imply a permanent organization-wide system change.

State what is outside the choice. The fictional team is not selecting a company-wide customer platform, changing customer promises or deciding employment responsibilities. Those questions may be related, but combining them would make the brief much larger and the meeting less clear. A boundary does not make the excluded matters unimportant. It identifies which decision process and participants are needed for this particular discussion.

Ask whether a meeting is necessary at all. If the approved decision-maker already has the needed facts and the choice is straightforward, a short written exchange may be sufficient. If participants need to resolve a tradeoff or inspect uncertainty together, a meeting can help. The brief should support the decision, not create ceremony for its own sake or imply that every routine choice needs a formal committee.

Name the decision-maker and the contributors

Identify who has actual authority for the bounded choice. Distinguish that role from the person preparing the brief, facilitating the discussion or supplying technical information. A facilitator can help the meeting stay focused without having authority to approve the change. A knowledgeable contributor can explain a system limitation without deciding the team's priorities. Clear roles help prevent agreement in the room from being mistaken for an approval nobody was authorized to give.

Invite the people whose information is necessary, not everyone who might be generally interested. For the fictional handoff trial, the decision-maker needs input from the person receiving requests, the person reviewing the queue and the responsible system owner. Other stakeholders may need communication afterward. The actual organization should determine participation according to its process and consequences rather than copying this example's roles automatically.

Record any approval that remains outside the meeting. A team may choose a preferred test approach while still needing a separate system or budget decision. Mark that condition explicitly. A recommendation can be useful without being a final authorization. The brief should make the next required step visible rather than presenting a roomful of agreement as permission to proceed with every related action.

Describe the problem through observable work

Explain what currently happens and what needs to improve. In the fictional example, requests arrive through internal email. The reviewer sometimes cannot tell which request has an owner or where the latest clarification sits. The problem statement should identify those observations and their source. Do not add a claimed financial loss or productivity gain unless the evidence actually supports it.

Separate observed facts from hypotheses. “The reviewer had to ask who owned three requests in a sample” is different from “email causes every delay.” A small sample can reveal a useful question without establishing the whole cause. The team may discover that unclear responsibility matters more than the tool. Keep that possibility open rather than writing the problem statement to guarantee that a preferred software option wins.

Define the desired result in a form participants can inspect. The team wants an authorized reviewer to locate the current owner and next step for eligible internal requests without reconstructing a long message chain. That is more useful than “better collaboration.” It still needs a practical test and actual observation. The brief should describe what the team would look for, not claim the improvement has already occurred.

Screen alternatives against real constraints first

List the conditions an approach must satisfy before comparing preferences. These might include approved access, appropriate handling of the information and a scope the responsible owner can support. Use the actual requirements for your setting. The fictional example does not define a security policy, legal standard or budget limit. It simply distinguishes a requirement from a preference that could be traded against another preference.

If an alternative fails a mandatory condition, do not hide that failure inside an attractive average score. An option that is not authorized for the information should not become acceptable because it looks convenient in another column. Resolve the requirement through the appropriate process or exclude the option from this choice. A scoring table is a discussion aid, not a mechanism for overruling the organization's real boundaries.

Also check whether each alternative is described at a comparable level. An elaborately imagined new tool should not be compared with a deliberately neglected version of the current process. Give the status quo its actual strengths and limitations. If an improved version of the current method is viable, describe it honestly. A fair comparison helps the decision-maker see the tradeoff instead of merely confirming the brief writer's preferred answer.

Create a small set of meaningfully different options

The fictional team considers A, an approved shared request log; B, a different approved queue tool available for a bounded trial; and C, the existing email approach with a clear owner tag. These are examples, not product recommendations. Each option should explain who maintains it, where the current request state appears and how reviewers would find the next action. A label such as modern platform does not provide enough information to compare an alternative.

Include the option of delaying a change when more evidence is needed, if that is a real choice. A brief that assumes immediate implementation can conceal a useful next step such as clarifying ownership or testing a small sample. Do not add a meaningless fourth option merely to make the document look comprehensive. The alternatives should represent decisions the responsible person could actually choose under the stated boundary.

Avoid cosmetic variations. Three options that all use the same process with a different color or name do not examine a meaningful tradeoff. Conversely, an option that changes the entire operating model may be too broad for this brief. Keep the alternatives matched to the question. The aim is to reveal the practical differences that matter, not maximize the number of rows in a table.

Choose criteria before assigning scores

Write the criteria in plain language and define how the team will interpret them. In the fictional example, the criteria are finding an unassigned request, review effort and retrievable history. Those are chosen for the stated handoff problem. They are not universal criteria for every team decision. If participants disagree about what matters, discuss that disagreement before using numbers to make the preference look objective.

NASA's systems-engineering decision-analysis guidance describes framing alternatives against decision-maker priorities while documenting assumptions and limitations. That is useful background, but a business team's simple brief is not a NASA-certified process. The adaptation here is modest: make the comparison's criteria and uncertainty explicit. Do not borrow technical authority from the source to imply that a small fictional score table establishes the correct business choice.

Define the scale if you use one. A one-to-five judgment needs an explanation of what a larger number means for each criterion. For review effort, for example, a larger score might mean less expected burden under the fictional exercise. Label that direction so a reader does not interpret five as more effort. If the team lacks evidence for a score, mark it uncertain instead of inventing a precise value to complete the grid.

Work through the fictional scoring example

For illustration, the team assigns weights of three to finding an unassigned request, two to review effort and one to retrievable history. These are preferences, not measured facts. Option A receives judgment scores of four, three and four. Multiplying and adding gives twelve plus six plus four, or twenty-two. Option B receives five, two and four, producing fifteen plus four plus four, or twenty-three. Option C receives two, four and two, producing six plus eight plus two, or sixteen.

The one-point lead for B is not a probability of success, a financial return or proof that B should be selected. It reflects the stated fictional judgments and weights. The useful question is whether the small difference survives reasonable uncertainty. If B's first score changes from five to four, its total becomes twenty and A's twenty-two is higher. One uncertain input can reverse the apparent preference.

The team should therefore identify what observation would clarify that score. A bounded comparison using the same fictional requests might show how reliably each approach makes an unassigned item visible. The test itself still needs an appropriate design and authorization. The score table has helped locate a question worth examining; it has not eliminated the need for judgment or established that the tool with the largest total is objectively best.

Test the importance of a disputed weight

Suppose participants disagree about review effort. If its weight changes from two to four while the other weights remain three and one, A's total becomes twelve plus twelve plus four, or twenty-eight. B's becomes fifteen plus eight plus four, or twenty-seven. C's becomes six plus sixteen plus two, or twenty-four. The ordering changes because the decision-maker's preference changed, not because the underlying tools suddenly performed differently.

This sensitivity example should not become a competition to choose the weights that make a favored option win. Use it to discuss the actual priority. How much does reviewer burden matter relative to finding an unassigned request? Which requirement is mandatory, and which is a preference? The decision-maker should understand the consequence of that choice rather than receive a total with its assumptions hidden.

You can omit numerical scoring entirely if a qualitative comparison serves the decision better. A clear table of strengths, limitations and unresolved questions may be more useful than weak numbers. The brief's quality depends on whether it supports an honest choice, not on whether it contains arithmetic. Keep a scoring model only when its definitions and limitations are clear enough that participants can challenge it meaningfully.

Identify the uncertainty that could change the answer

Not every unknown deserves another research project. Focus on information that could materially change the choice or the conditions for a trial. In the fictional example, uncertainty about whether B exposes unassigned requests matters because it can reverse the close comparison. A minor cosmetic preference may not warrant delaying the decision. The team should state that judgment rather than treat all blank cells as equally important.

For each consequential unknown, identify the source or observation that could reduce it. A system owner may answer an access question. A bounded task test may reveal review effort. A responsible operator may clarify who maintains the queue. Do not ask an AI tool to invent answers so the meeting packet looks complete. An unresolved question with a clear owner is more useful than an unsupported confident number.

Also state the limit of further investigation. The team may need a short trial rather than a perfect forecast of every future use. The decision-maker can choose with incomplete information when the scope and consequences are understood. The brief should make that uncertainty visible and describe the conditions for revisiting the choice. It should not promise that enough analysis will remove every risk or disagreement.

Draft the brief in a form people can use

A compact brief can contain the decision question, actual decision authority, observed problem, mandatory constraints, viable alternatives, comparison and consequential unknowns. Add a recommendation only when useful and clearly distinguish it from the final decision. Keep supporting material accessible without copying everything into the speaking document. Participants should be able to find the evidence behind a claim without reading an unstructured research archive.

For the fictional case, the recommendation might be to clarify B's unassigned-request behavior before choosing between A and B. That is a legitimate recommendation even though it does not select a tool immediately. Another decision-maker might approve a bounded test of A under the actual constraints. The brief should explain what each recommendation depends on and what action remains outside its authority.

Avoid a dramatic executive summary that states a conclusion more strongly than the analysis. If the comparison is close and uncertain, say so. If the current process remains viable, include that honestly. A useful brief earns trust by showing the reasoning at the appropriate level, not by removing nuance until one option appears inevitable. The document should help people make the decision, not pressure them to endorse the writer's preference.

Run the meeting around the choice

Begin by confirming the decision question and who can decide it. Check whether new information changes a constraint or makes an option unavailable. Then discuss the important differences and uncertainties. If the conversation drifts into a different decision, identify it and decide whether it belongs in another process. The facilitator should not silently expand a small trial choice into an organization-wide technology commitment.

Invite challenges to the assumptions, not just opinions about favorite tools. Ask which source supports a claimed advantage and what would change the recommendation. Give participants room to identify an overlooked dependency. A disagreement about criteria may be more important than a disagreement about a score. The meeting should make those differences understandable to the decision-maker rather than hide them behind an average.

End with the actual outcome: a decision, a conditional decision, a request for defined information or a decision not to proceed. Do not label an unresolved discussion approved because nobody objected at the end. Record who made the choice and which conditions apply under the real process. A clear no-change outcome can be useful when the evidence does not justify a new commitment.

Connect the decision to bounded follow-through

If a trial is approved, identify its owner, scope, observation period and review question through the actual operating process. The brief can name those elements without pretending the trial has already succeeded. Keep external commitments, spending and system permissions within their separate approved boundaries. A decision about an internal test does not automatically authorize every implementation step someone might associate with the idea.

Choose observations tied to the original problem. In the fictional case, the team might examine whether the reviewer can locate the current owner and next step in the eligible requests. Do not substitute a vanity measure such as the number of entries created if it does not answer the handoff question. The outcome should help decide what to retain, revise or stop, not merely show that people used the chosen tool.

The existing Built to Run action-log resource can support the separate follow-through record after the decision. This guide concerns preparing and discussing the choice before that stage. Keep those tasks connected but distinct. A good brief makes the decision clear; a good operating record helps the responsible team carry out the approved next step and return with the evidence the decision-maker requested.

Frequently asked questions

Does every team decision need a scored matrix?

No. Use the simplest comparison that makes the real choice understandable. A qualitative table can be more useful than numbers based on weak judgments. If scoring is used, define the scale, weights and uncertainty clearly. A total is not a probability of success or an instruction that overrides actual constraints. The fictional matrix illustrates sensitivity, not a universal method for choosing business tools.

Who should own the final decision?

The person or body with actual authority under the organization's process. Preparing the brief, facilitating the meeting and providing technical input are different roles. A contributor's expertise does not automatically grant every related approval. Name the decision-maker and any separate authorization still required so a recommendation or informal agreement is not mistaken for permission to proceed.

What if two options are almost tied?

Inspect which assumptions or preferences create the small difference. The fictional example shows that one score or weight change can reverse the ordering. Identify whether a bounded observation or clarification would materially help. A close comparison may justify further information or a conditional trial, depending on the real consequences. Do not present a one-point lead as proof of an objectively superior option.

Should the current process always be included?

Include it when retaining or improving it is a genuine viable choice. Describe its actual strengths and limitations rather than using an intentionally poor version as a comparison target. If it fails a real mandatory requirement, explain that. The purpose is an honest set of alternatives matched to the question, not a fixed number of options or a predetermined argument for buying something new.

How does this differ from a decision log?

The brief prepares a choice by defining alternatives, criteria and uncertainty. A decision log records the outcome and rationale after the responsible person makes the choice. They can connect, but they are not interchangeable. This guide should not be used to make an unresolved discussion look decided, and a log should not replace the comparison needed before a consequential choice.

Does the NASA source validate this business exercise?

No. It provides background on decision analysis in a systems-engineering context. The fictional team brief is an original practical adaptation and has not been established here as a validated business intervention. Keep its evidence and conclusions limited to the actual task. The source does not endorse the worksheet, predict an outcome or grant authority for a particular organizational change.