1# Job Plan
2 
3Adapted from SAVE International's Value Methodology Job Plan and Praxis VM. Phases run in sequence, but loop back when new information invalidates a prior step.
4 
5## Phases
6 
7### 1. Frame
8Clarify who asks, why now, what success looks like, what a ban on action would cost. Pick the intervention level (VM0-VM5, POE).
9 
10Opening questions (one at a time, always with *Recommended:*):
11- "Whose decision is this and what happens if it slips a week?"  -  *Recommended: infer the decision owner from the issue/PR/doc if available; otherwise assume the requester is the owner and mark slip-impact unknown until the user clarifies.*
12- "What would 'we got it right' look like 3 months after delivery?"  -  *Recommended: extract a measurable outcome from prior tickets/docs/PRD if present; otherwise propose one as a fallback assumption and ask the user to correct it.*
13 
14### 2. Information
15Inspect first, ask second. Pull from repo, file base, ADRs, prior PRs, issue tracker, logs, prod telemetry, design docs, contracts, market data, notes, PDFs, spreadsheets, screenshots, transcripts, and attached artifacts. Cite paths and IDs. Only ask the user for intent, constraints, taste, deadlines, stakeholders, and trade-off tolerance.
16 
17Use a short discovery cycle before every major question:
18 
191. Name the fact you need.
202. Search the nearest evidence source.
213. If found, turn it into an evidence-backed question.
224. If not found, tell the user what you checked and ask only for the missing human judgment.
23 
24Template:
25 
26```
27Evidence: <source> -> <fact found>
28Question: <decision this evidence creates>
29Recommended: <evidence-derived answer>, assuming <explicit assumption>.
30```
31 
32If no evidence is found:
33 
34```
35Checked: <sources checked>
36Question: <human-only missing intent/constraint>
37Recommended: fallback assumption only: <assumption to correct>.
38```
39 
40### 3. Function Analysis
41List functions as verb+noun. Mark basic vs secondary. Identify *unnecessary* functions  -  features that exist out of habit. See `function-analysis.md`.
42 
43### 4. Creative
44Generate >=5 distinct alternatives before any evaluation. Always include:
45- the no-build / status-quo option,
46- the manual / human-in-the-loop option,
47- a config-only or comms-only option,
48- the most ambitious option,
49- the cheapest reversible option.
50 
51Suspend judgment in this phase. No costing, no critique.
52 
53### 5. Evaluation
54Apply criteria from `evaluation-matrix.md`. Score, weight, sort. Surface the top 2 and the dark-horse.
55 
56### 6. Development
57Take the leading option to enough detail that risks, costs, and acceptance can be inspected. For software: PRD or ADR plus issue slices. For non-software: a one-page proposal with budget, owner, timing.
58 
59### 7. Risk
60Build a register for the developed option. See `risk-register.md`. Iterate back to evaluation if risk reshapes the score.
61 
62### 8. Recommendation
63State the recommended option, the criteria it wins on, the risks accepted, and the explicit alternatives rejected. Name what would change the recommendation.
64 
65### 9. Implementation slice
66Cut into the smallest deliverable units that each return value or learning. For each: owner, exit criteria, rollback, observability, dependencies.
67 
68### 10. Feedback / POE
69Schedule a post-occupancy check with measurable comparison to the predicted value. Capture surprises into ADR/lessons.
70 
71---
72 
73## Intervention levels
74 
75Each level has an opening question, the default artifact to produce, and a stop condition.
76 
77### VM0  -  Business Need
78- **Open with:** "If we never built this, what concretely breaks for whom?"
79- **Recommended default:** start from any cost-of-inaction evidence in tickets/support/telemetry; if none is present, mark cost-of-inaction unknown and ask the user before treating this as a real need.
80- **Artifact:** Value Brief  -  problem statement, beneficiaries, value criteria, "do nothing" option assessed.
81- **Stop when:** the user can articulate the cost of inaction in one sentence and a measurable outcome.
82 
83### VM1  -  Brief / Requirements
84- **Open with:** "What outcome must hold true for this to count as solved, regardless of solution?"
85- **Recommended default:** lift the outcome from existing PRD/ticket; if absent, propose one and ask for correction.
86- **Artifact:** Outcome-based brief + Function Map.
87- **Stop when:** functions are named and at least one is challenged as unnecessary.
88 
89Before opening, inspect any available brief, ticket, docs, current implementation, support notes, or attached files. If they contain a stated outcome, quote the source as evidence and ask whether that outcome is the real value boundary.
90 
91### VM2  -  Concept / Option Selection
92- **Open with:** "What are the three most different ways to deliver this outcome?"
93- **Recommended default:** generate them yourself, including a no-build option, then ask which to extend.
94- **Artifact:** Options Matrix + recommended option with rationale.
95- **Stop when:** one option wins on weighted criteria and the user accepts the trade-offs.
96 
97### VM3  -  Design Revalidation
98- **Open with:** "Which part of the current design would you remove if forced to cut 20%?"
99- **Recommended default:** propose a cut from inspection of the design doc/PR.
100- **Artifact:** Pruned design with rationale, plus a list of unnecessary functions removed.
101- **Stop when:** every retained component maps to a basic function.
102 
103Before asking, inspect the current design, diff, issue, PR, screenshots, or spec. Bring one concrete retained component and its suspected function into the question.
104 
105### VM4  -  Technical Sign-Off
106- **Open with:** "What is the single most likely way this fails in production?"
107- **Recommended default:** infer from logs, prior incidents, fragile boundaries.
108- **Artifact:** Acceptance criteria + test plan + rollout/rollback plan + observability hooks.
109- **Stop when:** rollback is rehearsed in writing and the on-call playbook entry exists.
110 
111### VM5  -  Delivery / Recovery
112- **Open with:** "What is the smallest change that stops the bleeding without making rescue harder?"
113- **Recommended default:** propose the targeted fix from logs and code, not a refactor.
114- **Artifact:** Stabilization plan + simplification backlog + ADR for any architectural change.
115- **Stop when:** the bleeding is stopped and the simplification backlog has owners.
116 
117Before asking, inspect the failing path, logs, reproduction notes, current diff, runbooks, and nearest tests. Do not ask the user to restate symptoms already visible in artifacts.
118 
119### POE  -  Post-Occupancy
120- **Open with:** "Of the value we predicted, what actually happened?"
121- **Recommended default:** read telemetry, retro notes, support tickets first.
122- **Artifact:** Outcome diff + lessons -> ADR or skill update.
123- **Stop when:** at least one decision rule for next time has been written down.
124