The intake builder reads what you have and drafts a submission package from it.
Artifact Standards 17–25
Structural standards for Steps 4–8 — from problem clarification through authorization. These artifacts travel with a proposal from clarification through tollgate. Several of them are living documents that stay open through delivery and benefits confirmation.
For document-based artifacts: copy the prompt, paste into any capable AI, drop in your project materials, get a populated draft. Review it against the field standard below. Adjust and own the result.
On the container question: The AI produces structured content. That content needs a home — a spreadsheet, a project tracking system, a document platform, wherever your organization stores and retrieves structured data consistently. Waypoint does not prescribe a tool. The structure is the standard. The container is yours. Practitioners who have connected their project systems to Claude via MCP skip the copy step entirely.
I need to prepare a one-page Problem Statement for a project going through governance clarification. Below are the materials I have. Please populate each section from my materials: - The Problem: what is happening today in operational terms — what is occurring, not what should happen instead - Who Is Affected and How: which people, teams, or processes experience this problem; what it costs them in time, quality, risk, or money - Consequence of Not Acting: what happens if this is not addressed — specific risk, cost, or impact of inaction - How We Know This Is Happening: what evidence confirms this problem is real — data, direct observation, or documented incident - What This Problem Is Not: what related issues are not being addressed; what is explicitly out of scope Then evaluate against the review checklist: Is the problem described in operational terms (not as a solution)? Is at least one piece of confirming evidence cited? Can a named person in the business confirm this description? Is the consequence of inaction stated specifically? Is the problem within the organization’s authority to address? Keep the total to one page. If the problem cannot be described in one page, note that the problem is not yet understood clearly enough — return to the submitter for clarification. [Paste your project materials here — SOW, intake submission, emails, meeting notes, or any combination]
One page maximum. If this cannot be described in one page, the problem is not yet understood clearly enough. Return to the submitter for further clarification before proceeding to the CBA.
| Field | Response |
|---|---|
| Proposal name | |
| Date | |
| Author | |
| Version |
The Problem — What is happening today? Describe in operational terms — what is occurring, not what should happen instead.
Who Is Affected and How — Which people, teams, or processes are experiencing this problem? What does it cost them in time, quality, risk, or money?
Consequence of Not Acting — What happens if this problem is not addressed? Be specific about the risk, cost, or impact of inaction.
How We Know This Is Happening — What evidence confirms this problem is real — data, direct observation, or documented incident?
What This Problem Is Not — What related issues are not being addressed here? What is explicitly out of scope?
Problem Statement Review Checklist
| Check | Confirmed |
|---|---|
| The problem is described in operational terms, not as a proposed solution | ☐ |
| At least one piece of confirming evidence is cited | ☐ |
| A named person in the business can confirm this description is accurate | ☐ |
| The consequence of inaction is stated specifically | ☐ |
| The problem as stated is within the organization’s authority to address | ☐ |
Starts at clarification. Travels with the proposal through CBA, prioritization, tollgate, and delivery. Updated when assumptions are confirmed, revised, or invalidated. Never closed until benefits are confirmed.
| ID | Assumption | Confidence (H/M/L) | Evidence or Reasoning | What Would Invalidate It | Test Method | Owner | Status | Last Updated |
|---|---|---|---|---|---|---|---|---|
| A-01 | Untested / Confirmed / Revised / Invalidated | |||||||
| A-02 | ||||||||
| A-03 |
I need to define a measurable outcome for a project going through governance clarification. This outcome definition will become the hypothesis the CBA tests, the target the benefits register tracks, and the measure the governance forum confirms after delivery. Using my project materials below, please define: - Primary Outcome: what will be measurably different after this investment compared to today — the operational change, not the deliverable - Who Experiences the Change: which team, process, or user population will see this difference - How It Will Be Measured: at least two specific measures with current baseline values, expected post-investment state, confirmation date, and data source for each - What Success Looks Like at 90 Days: one specific thing that should have changed 90 days after go-live - What Success Looks Like at 12 Months: what should be measurably different one year after the investment closes Name a specific Outcome Owner — the individual accountable for confirming this outcome materialized. If my materials do not name one, flag it as a required gap. Then evaluate against the checklist: Does the outcome describe an operational change, not a deliverable? Is there a named accountable person? Is at least one quantifiable measure defined with a current baseline? Is a confirmation date set? [Paste your project materials here — SOW, intake form, problem statement, sponsor conversations, or any combination]
The outcome defined here becomes the hypothesis the CBA tests, the target the benefits register tracks, and the measure the governance forum confirms after delivery. Define it before the CBA is built, not from the CBA output.
| Field | Response |
|---|---|
| Proposal name | |
| Outcome owner (accountable for confirming this outcome materialized) | |
| Date |
Primary Outcome — What will be measurably different after this investment, compared to today? Describe the operational change — not the deliverable.
Who Experiences the Change — Which team, process, or user population will see this difference?
How It Will Be Measured
| Measure | Current Baseline | Expected State Post-Investment | Confirmation Date | Data Source |
|---|---|---|---|---|
What Success Looks Like at 90 Days — What specific thing should have changed 90 days after go-live?
What Success Looks Like at 12 Months — What should be measurably different one year after the investment closes?
Outcome Review Checklist
| Check | Confirmed |
|---|---|
| The outcome describes a change in how the organization operates — not a deliverable produced | ☐ |
| A named person is accountable for confirming the outcome materialized | ☐ |
| At least one quantifiable measure is defined with a current baseline | ☐ |
| A specific confirmation date is set | ☐ |
| The outcome owner has reviewed and agreed to this definition | ☐ |
Companion to the CBA. One row per projected benefit. This document is the source record for Step 11 follow-up. The people named here are the ones the EPMO will contact at the confirmation date.
| Benefit ID | Description | CBA Category | Projected Value | Confidence | Outcome Owner | Measurement Method | Data Source | Baseline | Confirmation Date | Status |
|---|---|---|---|---|---|---|---|---|---|---|
| B-01 | Not started / In delivery / Confirmed / Missed / Revised | |||||||||
| B-02 |
Engagement Record
| Benefit ID | Date | Method | Who Was Present | Status Update | Next Action |
|---|---|---|---|---|---|
| B-01 |
Register Integrity Checks
| Check | At CBA | At Authorization | At Go-live |
|---|---|---|---|
| Every projected financial benefit has a row in this register | ☐ | ☐ | ☐ |
| Every row has a named, reachable outcome owner | ☐ | ☐ | ☐ |
| Every row has a specific confirmation date | ☐ | ☐ | ☐ |
| Every confirmation date is on the EPMO governance calendar | ☐ | ☐ | ☐ |
Companion to the Prioritization Scoring Model. Documents why the weights are set the way they are, when they were last reviewed, and what the process is for changing them.
| Criterion | Current Weight | Rationale | Cycle Set |
|---|---|---|---|
| Strategic Alignment | |||
| Financial Value | |||
| Risk Reduction | |||
| Mandatory Requirement | |||
| Customer / Operational Impact | |||
| Delivery Readiness | |||
| Adoption Readiness | |||
| Total | 100% |
I need to produce a Prioritization Tradeoff Summary at the close of a prioritization cycle. Below are my session notes and scoring outputs. Please build the summary with: - Session information: cycle period, date, participants, total proposals reviewed - Count of approved, deferred, and declined/stopped items - Approved Items table: rank, item name, score, category, notes - Deferred Items table: item name, score, reason for deferral, expected re-entry cycle, owner - Declined Items table: item name, score, reason for decline, communicated to, date - Overrides table: any item where the governance forum’s actual outcome differed from the model’s ranked output — item name, model outcome, actual outcome, rationale, approved by - Cycle Notes: what this cycle revealed about the scoring model, the portfolio, or the prioritization process that should inform the next cycle This is the governance forum’s standing record of what was decided and why — not a scoring summary. Keep rationale factual and direct. Work only from my materials — do not invent details; label any inference or estimate as such, and list anything missing as a gap. [Paste session notes and scoring outputs here]
Produced at the close of each prioritization cycle. One document per cycle. This is the governance forum’s standing record of what was decided and why.
| Field | Response |
|---|---|
| Cycle period (e.g., Q3 FY26) | |
| Date of prioritization session | |
| Participants | |
| Total proposals reviewed | |
| Approved | |
| Deferred | |
| Declined / stopped |
Approved Items
| Rank | Item Name | Score | Category | Notes |
|---|---|---|---|---|
Deferred Items
| Item Name | Score | Reason for Deferral | Expected Re-Entry Cycle | Owner |
|---|---|---|---|---|
Declined Items
| Item Name | Score | Reason for Decline | Communicated To | Date |
|---|---|---|---|---|
Overrides
| Item Name | Model Outcome | Actual Outcome | Rationale | Approved By |
|---|---|---|---|---|
Cycle Notes — What did this cycle reveal about the scoring model, the portfolio, or the prioritization process that should inform the next cycle?
Distributed to governance forum members at least [X] business days before the session. The agenda signals that the meeting’s purpose is decisions, not presentations.
| Field | Response |
|---|---|
| Date and time | |
| Location / link | |
| Facilitator | |
| Decision authority confirmed present | |
| Quorum requirement | |
| Total scheduled time |
Standing Items (always first)
| Item | Owner | Time |
|---|---|---|
| Conditions Tracking Register — status of all open conditions from prior sessions | EPMO | |
| Items held from prior session — decisions deferred that require resolution today | EPMO |
Decision Items
| # | Item Name | Type | Proposed Outcome | Pre-Read Distributed | Discussion Time | Decision Authority |
|---|---|---|---|---|---|---|
| 1 | New / Milestone / Exception | Proceed / Proceed with Conditions / Return / Defer / Stop | ☐ | |||
| 2 | ☐ |
I need to prepare a one-page Sponsor Briefing to deliver to a project sponsor before work begins. Below are the authorization record, approved CBA, and outcome definition for this project. Please build the briefing with: - Project/investment name, approved scope in one paragraph (exactly what was authorized), authorization date, authorized budget, projected timeline - What the Organization Committed To: the outcome statement from Step 4 — what the benefits register will confirm - What Sponsorship Requires: review health vs. value status updates each governance cycle, attend milestone tollgate reviews, resolve scope and priority conflicts beyond delivery team authority, confirm outcome owner engagement quarterly, confirm benefit at the scheduled confirmation date - First Thirty Days: delivery team kickoff, dependency confirmations, first health vs. value check-in, sponsor/EPMO standing cadence established — with owners and dates drawn from my materials - Key Contacts: EPMO lead, delivery lead, outcome owner, primary dependency owner if applicable Keep to one page. The purpose is to ensure the sponsor knows what was approved, what they committed to, and what the first thirty days require of them. Build only from the authorization record, CBA, and outcome definition I provide — do not invent commitments, dates, or figures; flag any gap. [Paste authorization record, approved CBA, and outcome definition here]
One page. Completed by the EPMO. Delivered to the active sponsor before work begins. Purpose: ensure the sponsor knows what was approved, what they committed to, and what the first thirty days require of them.
| Field | Response |
|---|---|
| Project / investment name | |
| Approved scope (one paragraph — exactly what was authorized) | |
| Authorization date | |
| Authorized budget | |
| Projected timeline |
What the Organization Committed To — The outcome statement from Step 4. This is what the benefits register will confirm.
What Sponsorship Requires
| Responsibility | Frequency | Escalation Path |
|---|---|---|
| Review health vs. value status updates | Per governance cycle | Flag concerns to EPMO if missing |
| Attend milestone tollgate reviews | Per schedule | Contact EPMO lead if conflict arises |
| Resolve scope and priority conflicts beyond delivery team authority | As needed | Direct access to EPMO and delivery lead |
| Confirm outcome owner engagement through delivery | Quarterly | EPMO will flag if engagement drops |
| Confirm benefit at the scheduled confirmation date | At confirmation date | EPMO will send calendar invite and measurement request |
First Thirty Days
| Action | Owner | Date |
|---|---|---|
| Delivery team kickoff | ||
| Dependency confirmations | ||
| First health vs. value check-in | ||
| Sponsor / EPMO standing cadence established |
Key Contacts
| Role | Name | Contact |
|---|---|---|
| EPMO lead | ||
| Delivery lead | ||
| Outcome owner | ||
| Primary dependency owner (if applicable) |
Produced at authorization. Shows the governance forum the portfolio-level effect of this approval before the decision is made. Do not authorize new work without running this snapshot first.
Before This Authorization
| Resource / Team | Current Demand | Available Capacity | Utilization % |
|---|---|---|---|
After This Authorization
| Resource / Team | Added Demand (this project) | New Total Demand | New Utilization % | Status |
|---|---|---|---|---|
| OK / At risk / Over capacity | ||||
Conflicts Created
| Resource / Team | Conflict Description | Projects Affected | Recommended Resolution | Owner | Deadline |
|---|---|---|---|---|---|
☐ No conflicts — proceed to authorization
☐ Resolvable conflicts — proceed with the following conditions:
☐ Unresolvable conflicts — defer until:
Authorization should not proceed until capacity conflicts are resolved or explicitly accepted by the governance forum with documented rationale.