🟥 Tier 1 — Foundation / Programme‑Critical
If these are unclear or unstable, everything else becomes noisy.
These views establish identity, structure, and comparability.
They must come first.
1️⃣ Project (Core Project / Delivery Context)
Why it’s #1
- Almost all reporting joins through Project
- Financials, resources, opportunities, governance all hang off it
- Most reconciliation questions ultimately land here
Minimum viable preparedness
- Stable project identifiers
- Clear mapping of lifecycle/status
- Explainable differences vs Apps10
- Known gaps explicitly called out
If Project is wrong or ambiguous, nothing downstream can be trusted.
2️⃣ Order / Contract (Commercial Backbone)
Why it’s #2
- Drives order intake, order book, revenue expectations
- Central to GMIS, leadership reporting, and programme confidence
- Common source of “why doesn’t this match?” questions
Minimum viable preparedness
- Order/contract identifiers stable
- Relationship to Project is clear
- Basic commercial states explainable
- Differences vs legacy understood
This is where ERP transitions most visibly succeed or fail.
3️⃣ Person / Resource Identity
Why it’s #3
- Underpins access, accountability, governance, and attribution
- Touches Entra, RBAC, reporting joins, and people‑based logic
- Highly sensitive to misunderstanding
Minimum viable preparedness
- Stable person identifiers
- Clear distinction between identity vs role
- Known limitations documented (e.g. line manager logic, timing)
- Explicit non‑goals stated
This view prevents governance confusion, not just reporting issues.
🟧 Tier 2 — Validation & Confidence‑Building
These enable reconciliation and trust, once the foundations exist.
4️⃣ Opportunity / Pipeline
Why it’s here
- Essential for forward‑looking confidence
- Often differs intentionally between systems
- Useful early, but only once Project + Order are stable
Minimum viable preparedness
- Clear linkage to Project / Order
- Known timing differences
- Route‑to‑market logic explainable
- Not treated as final truth
5️⃣ Financial Facts (Revenue / Cost / Baseline)
Why it’s Tier 2
- High impact, but highly dependent on:
- Project correctness
- Order correctness
- ERP posting maturity
- Premature focus creates false alarms
Minimum viable preparedness
- Presence of facts (even if incomplete)
- Clear explanation of what isn’t there yet
- Repeatable behaviour
- Comparability narrative prepared
This is where discipline matters more than completeness.
🟨 Tier 3 — Secondary / Derivative
Useful, but should never block programme confidence.
6️⃣ Reference / Meta Codes
- Code lists
- Status descriptions
- Lookup enrichment
Prepared when
- Values are present and traceable
- Differences vs legacy are documented
- No one mistakes them for business logic
7️⃣ Audit / History / Temporal Views
- Change history
- Slowly changing dimensions
- Temporal analysis
Why last
- High complexity
- Low immediate validation value
- Very easy to over‑invest too early
✅ Visual Summary
| Priority Tier | View Type | Why |
|---|---|---|
| 🟥 Tier 1 | Project | Structural anchor |
| 🟥 Tier 1 | Order / Contract | Commercial truth |
| 🟥 Tier 1 | Person | Identity & governance |
| 🟧 Tier 2 | Opportunity | Forward confidence |
| 🟧 Tier 2 | Financial Facts | Validation, not panic |
| 🟨 Tier 3 | Meta / Reference | Support only |
| 🟨 Tier 3 | History / Audit | Later maturity |
🔑 The governing principle (important)
Preparedness flows downstream
Identity → Structure → Commercials → Financials → Insight
Any attempt to invert this order (e.g. “let’s validate revenue first”) increases:
- noise,
- false defects,
- stakeholder anxiety.
✅ How this supports your low‑switching focus
This ordering lets you:
- Work top‑down
- Stay in one mental model
- Defer noisy validation until foundations are ready
- Say “not yet” with confidence — and justification
It is deliberately designed to protect your time and the programme.