Purpose

The Executive Recommendation Packet enables BPM-HCM to request a clear decision from executive leadership by presenting:

• Validated problem statement(s) and institutional impact
• Evidence from stakeholder interviews and available metrics
• Constraints (policy, compliance, security, system, capacity, and timing)
• Options analysis with tradeoffs, risks, and dependencies
• A recommended path forward and the specific decision being requested

The packet must be written for executives who were not in day-to-day Discovery sessions. It should be concise, factual, and decision-oriented.

Packet Overview (Standard Structure)

The packet should include the sections below in the order listed:

How to Build the Executive Readout

Step 1: Define the Decision Requested

• Use a single sentence that starts with: “Decision Requested:”
• Specify the decision type: Go / No-Go / Defer / Close
• Include the impact of the decision (what happens next if approved)

Step 2: Summarize the Problem and Impact

• Describe the issue in plain language (avoid internal jargon)
• Identify the impacted populations and teams
• Quantify impact when possible (delays, rework, compliance risk, volume)

Step 3: Provide Evidence (Stakeholder + Data)

• Summarize themes from interviews (what we heard)
• Include baseline metrics where available (cycle time, error rate, volume)
• Distinguish between evidence and assumptions

Step 4: Document Constraints

• Policy and compliance requirements (university, system, state, federal)
• Security and segregation-of-duties constraints
• System/integration constraints and technical feasibility
• Capacity, timing, and resource constraints

Step 5: Compare Options and Select the Recommendation

• Always include at least 3 options when feasible:
  • Option A (preferred)
  • Option B (alternate)
  • No-change (baseline)
• Use the option comparison format (below) to show tradeoffs and reduce ambiguity
• Make the recommendation explicit and link it to the decision requested

Option Comparison (Standard Format)

Use the format below to compare options consistently. This helps leadership evaluate the tradeoffs of each path forward.

Decision Log Standards

The Decision Log ensures transparency, traceability, and consistency across governance decisions. Decisions must be documented as they occur (not after the fact) and should be written so someone outside the project can understand what was decided and why.

Decision Log Rules

• Every decision must have a unique ID (example: D-01, D-02).
• Every decision must include a date, decision maker, and outcome.
• Document the rationale and key evidence used (briefly).
• If the decision requires follow-up actions, assign an owner and due date.
• Do not use the Decision Log to document general discussion—only outcomes.

Decision Log Template (Copy/Paste)

DECISION LOG

Project Name:
Date Range Covered:

Decision ID:
Decision Date:
Decision Maker(s):
Decision Type: (Go / No-Go / Defer / Close / Scope / Policy / Ownership / Other)

Decision Statement (What was decided?):

Rationale / Evidence (Why?):

Impacted Teams / Populations:

Follow-Up Actions (if any):
- Action:
- Owner:
- Due Date:

Status: (Open / Complete)
Notes:

Decision Log Table Format (Recommended)

Quality Check (Before Sending to Leadership)

• Decision Requested is explicit and written in one sentence
• Problem statement is clear, plain-language, and tied to institutional impact
• Evidence is summarized (themes + metrics where available) and assumptions are labeled
• Constraints are listed (policy/compliance/security/system/capacity/timing)
• Option comparison is complete (includes no-change)
• Recommendation is linked to evidence and acknowledges tradeoffs
• Top risks and mitigations are defined and owned
• Dependencies and ownership are clear (RACI)
• Decision Log is updated and reflects all key outcomes

Required Artifacts

The Executive Recommendation Packet should be supported by the following Discovery artifacts (as applicable):

• Interview notes (individual templates completed)
• Consolidated synthesis summary (themes, gaps, constraints)
• Fit/Gap analysis and requirements catalogue (draft or validated)
• Risk and dependency log (with owners and mitigation)
• Policy and compliance review notes
• RACI draft for next-phase execution
• Updated Decision Log

Common Pitfalls to Avoid

• Solution-first packets: recommending a build without validated problem statements and constraints.
• No “no-change” option: executives need to understand the cost of doing nothing.
• Unclear decision request: avoid vague asks; always request a specific decision.
• Missing constraints: policy, compliance, security, and timing constraints must be explicit.
• Unowned risks: every high-impact risk must have an owner and mitigation path.
• Undocumented decisions: governance decisions must be captured in the Decision Log.