Core deliverables you should master
How to read this page
Each lifecycle phase lists the artefacts an AI Solution Engineer should be able to author, review or challenge. For every item you will find:
| Section | What it tells you |
|---|---|
| Purpose | Why the artefact exists and what decision it supports |
| When used | Typical timing in discovery → delivery → operation |
| Quality bar (VALUE) | What "good" looks like at send-to-client standard |
| Common failure modes | How weak work shows up in reviews and steering committees |
| Learning Map topics | Where to study and practise |
| Example outline | Skeleton structure—adapt to client templates |
VALUE here means: Valid (factually defensible), Actionable (enables a decision), Linked (to strategy, metrics, owners), Understandable (right audience, right depth), Evidence-backed (sources, assumptions labelled).
Qualification
Qualification artefacts answer: Should we spend any more time on this opportunity? They precede heavy discovery spend and protect the firm and client from solution-led motion.
Opportunity brief
Purpose: One-page (or two-page maximum) statement of the suspected problem, sponsor, urgency, strategic fit and proposed next step—written so a busy executive can approve or redirect discovery in five minutes.
When used: First conversation with a sponsor; internal pursuit decision; steering committee "shaping" slot before a paid discovery phase.
Quality bar (VALUE): Names a problem owner, baseline metric (even if estimated), strategic theme from a public or confirmed source, scope boundary (in/out), and a recommended next step with cost band. No product names in the headline. Assumptions flagged.
Common failure modes: Feature wish-list disguised as a brief; "AI transformation" without a P&L line; missing sponsor; no alternative to AI considered; dates and budget invented without labelling as hypothesis.
Learning Map topics: Business Fundamentals, Business Strategy, AI Opportunity Discovery, Communication and Executive Articulation, Presales and Solution Shaping.
Example outline:
- Executive summary (BLUF: pursue / pivot / stop)
- Client context and strategic alignment (one paragraph)
- Problem hypothesis and who feels pain
- Value hypothesis (metric, direction, rough magnitude)
- Scope and out-of-scope
- Risks and dependencies (top three)
- Recommended next step, effort, decision required
Stakeholder map
Purpose: Visual and narrative map of who decides, who influences, who executes, who blocks—with engagement strategy per cluster.
When used: Before workshops; before executive readouts; when conflict appears (IT vs business, risk vs innovation, BU vs group).
Quality bar (VALUE): Power/interest or equivalent axis populated with named roles (not only "IT"). Messages tailored per audience. Identifies champion, economic buyer, technical gatekeeper, sceptic. Links to comms cadence.
Common failure modes: Org chart pasted without analysis; everyone marked "high influence"; no sceptics; generic messages; missing union, works council or regulator where relevant.
Learning Map topics: Stakeholder Management, Consulting Problem Solving, Communication and Executive Articulation.
Example outline:
- Map diagram (power × interest or custom)
- Stakeholder register (name/role, stance, concerns, win themes)
- Engagement plan (touchpoints, owners, messages)
- Risk stakeholders (blockers) and mitigation
- Decision rights for next gate
Qualification scorecard
Purpose: Structured scoring of strategic fit, value potential, feasibility signals, sponsor strength and delivery risk—so go/no-go is comparable across opportunities.
When used: Internal pursuit committees; portfolio prioritisation; end of pre-sales "free" work.
Quality bar (VALUE): Weighted criteria agreed upfront. Scores justified with evidence or explicit assumptions. Includes stop rules (e.g. no executive sponsor → no-go). Shows sensitivity ("if data access fails, score drops to…").
Common failure modes: Scores adjusted to justify a favourite outcome; all criteria weighted equally; no written rationale; technical feasibility scored by optimism.
Learning Map topics: AI Opportunity Discovery, Commercial and Financial Modelling, Vendor and Technology Evaluation.
Example outline:
- Criteria and weights (strategy, value, feasibility, sponsor, risk)
- Score table with evidence column
- Composite score and threshold
- Conditions for proceed (must-haves)
- Recommendation and dissenting views (if any)
Initial value hypothesis
Purpose: Testable statement linking the problem to financial or operational outcomes—the anchor for every later architecture and commercial conversation.
When used: Before discovery workshops; before prototype spend; refreshed after discovery.
Quality bar (VALUE): Names KPI, baseline, target delta, £ or % range, payback horizon, and confidence level. Separates hard savings, revenue, risk reduction and cost-to-achieve.
Common failure modes: "Efficiency gains" without a metric; double-counting FTE savings; ignoring implementation and run cost; no counterfactual (what happens if we do nothing).
Learning Map topics: Business Fundamentals, Commercial and Financial Modelling, AI Opportunity Discovery.
Example outline:
- Value tree (one level deep)
- Primary KPI and baseline source
- Benefit ranges (low/base/high) with assumptions
- Cost-to-achieve (build + run, order of magnitude)
- Payback and sensitivity
- What would falsify the hypothesis
Go/no-go recommendation
Purpose: Decision memo with a clear proceed, pivot, defer or stop recommendation and what the client must decide now.
When used: End of qualification; before signing discovery SOW; when new facts invalidate the opportunity.
Quality bar (VALUE): Recommendation in the first screen. Alternatives considered. Risks with owners. Explicit client decision with date. Dissent captured if multi-disciplinary review.
Common failure modes: Buried recommendation; "proceed with caution" without conditions; no stop option; technical appendix longer than the decision.
Learning Map topics: Consulting Problem Solving, Communication and Executive Articulation, Presales and Solution Shaping.
Example outline:
- Recommendation (one sentence)
- Summary of evidence
- Options considered (including do nothing)
- Conditions for proceed
- Decision requested (who, by when)
- Appendix pointers only
Discovery
Discovery artefacts answer: What is actually happening today, and what must the solution solve? They convert ambiguity into an evidence-backed problem definition.
Discovery agenda and interview questions
Purpose: Plan for workshops and interviews that elicits jobs, metrics, decisions, constraints and data reality—not feature brainstorming.
When used: Week one of discovery; before process walkthroughs; when replacing a failed "requirements gathering" phase.
Quality bar (VALUE): Questions mapped to stakeholder and artefact output. Time-boxed sessions. Mix of executive, operator and technical voices. Includes "show me" tasks (systems, reports, exceptions).
Common failure modes: Generic question bank; no linkage to outputs; only business users, no ops/IT; sessions that end in unprioritised pain points.
Learning Map topics: Consulting Problem Solving, Stakeholder Management, Industry and Domain Knowledge.
Example outline:
- Discovery objectives and exit criteria
- Session plan (participants, duration, outputs)
- Question sets by role (exec, operator, IT, risk)
- Evidence to collect (artefacts, data samples)
- Logistics and pre-reads
Process map
Purpose: Current-state view of steps, handoffs, systems, exceptions and cycle time—the substrate for automation and AI fit decisions.
When used: When the use case is workflow-shaped; before RPA vs rules vs ML vs GenAI debates.
Quality bar (VALUE): Happy path and exception paths. Systems named. Volumes and pain labelled on steps. Decision points explicit. Validated with operators ("walk the wall").
Common failure modes: Pretty Visio with no volumes; only happy path; missing shadow IT; conflated future-state design into current-state map.
Learning Map topics: Consulting Problem Solving, Agentic AI and Workflow Automation, Integration and Enterprise Systems.
Example outline:
- Scope boundary (start/end trigger)
- Swimlane or BPMN current state
- Step table (volume, time, pain, system)
- Exception catalogue
- Improvement hypotheses (for later prioritisation)
Problem statement
Purpose: Decision-focused definition of the gap between current and required performance—owned by a named sponsor.
When used: After initial discovery; before design; when scope creep appears.
Quality bar (VALUE): Format: "[Role] needs to [capability] so that [metric/outcome], but today [constraint/pain]." Measurable. Not a solution description. Signed or socialised with sponsor.
Common failure modes: "Implement ChatGPT"; problem written by vendor; no owner; competing problem statements across BUs.
Learning Map topics: Consulting Problem Solving, Product Management, AI Opportunity Discovery.
Example outline:
- Problem statement (single paragraph)
- Success criteria (metrics)
- Constraints (regulatory, technical, organisational)
- Out of scope
- Sponsor sign-off or alignment note
Current-state assessment
Purpose: Consolidated view of people, process, technology, data and governance as-is—with gaps that affect AI delivery.
When used: Mid-discovery; input to feasibility and roadmap; baseline for change management.
Quality bar (VALUE): Uses evidence (interviews, system docs, sample data). Separates facts from hypotheses. Highlights blockers with severity. Links to industry context where relevant.
Common failure modes: Aspirational current state; only technology layer; data described without quality samples; no governance view.
Learning Map topics: Industry and Domain Knowledge, Data Engineering and Architecture, Enterprise Architecture.
Example outline:
- Executive summary of as-is
- Process summary (pointer to process map)
- Systems and integration landscape
- Data sources and quality notes
- Organisation and operating model
- Governance and controls
- Gap summary (ranked)
Requirements catalogue
Purpose: Structured list of functional and non-functional requirements traceable to problem, stakeholders and test cases—not an unstructured wish list.
When used: End of discovery; start of design; input to RFP and test strategy.
Quality bar (VALUE): Each requirement has ID, description, source, priority (MoSCoW or similar), acceptance hint, owner. NFRs cover security, performance, accessibility, audit. AI-specific needs (evaluation, human oversight) explicit.
Common failure modes: Hundreds of unprioritised lines; missing NFRs; no traceability; requirements copied from vendor marketing.
Learning Map topics: Product Management, AI Evaluation and Quality Assurance, Security Engineering.
Example outline:
- Requirements taxonomy
- Functional requirements table
- Non-functional requirements table
- Traceability matrix (req → problem → test)
- Open questions and assumptions register
Assessment
Assessment artefacts answer: Can we actually build this safely, legally and economically—and is it the right priority?
Data-readiness assessment
Purpose: Honest view of availability, quality, lineage, latency, retention and access for data needed by the use case.
When used: Before architecture lock; before POC data pull; when legal or InfoSec asks "where does the data go?"
Quality bar (VALUE): Dataset inventory with owner, sensitivity class, quality dimensions, gaps and remediation plan. Sample profiling results or explicit plan to profile. Legal basis for use documented or flagged for legal review.
Common failure modes: "We have lots of data in the lake"; no PII/secrets classification; no remediation owner; assuming perfect labels exist.
Learning Map topics: Data Engineering and Architecture, Privacy, Legal and Compliance, Machine Learning Foundations.
Example outline:
- Data requirements (from use case)
- Source inventory and classification
- Quality assessment (completeness, accuracy, timeliness)
- Access and lineage gaps
- Remediation plan (effort, owner, timeline)
- Go/no-go impact on data
AI feasibility assessment
Purpose: Technical judgement on pattern fit (rules, search, ML, GenAI, agentic), model approach, latency, accuracy expectations and build vs buy—grounded in problem and data.
When used: After discovery; before prototype charter; when executives ask "can AI do this?"
Quality bar (VALUE): Recommends simplest effective pattern from the automation hierarchy. States what success looks like quantitatively. Identifies unknowns requiring spikes. Honest about human-in-the-loop need.
Common failure modes: Default to GenAI; no baseline non-AI option; accuracy claims without evaluation plan; ignoring operational constraints (offline, edge, batch).
Learning Map topics: Machine Learning Foundations, Generative AI and LLM Fundamentals, Retrieval-Augmented Generation, Agentic AI and Workflow Automation, AI Opportunity Discovery.
Example outline:
- Problem and success metrics recap
- Pattern options considered (with pros/cons)
- Recommended approach and rationale
- Data and model dependencies
- Unknowns and spike plan
- Feasibility conclusion (green/amber/red)
Security and governance assessments
Purpose: Identify threats, controls, compliance obligations and governance forums required before build and before production.
When used: Parallel with feasibility; mandatory before external data or production path; input to architecture and responsible AI design.
Quality bar (VALUE): Threat-led (STRIDE or client equivalent). Maps controls to identity, network, data, model, prompt, output. Names approval bodies (architecture board, model risk, DPO). Residual risks explicit.
Common failure modes: Checkbox ISO slide; no LLM-specific threats; "we'll use Azure so it's secure"; governance forums unnamed.
Learning Map topics: Security Engineering, Privacy, Legal and Compliance, Responsible AI Governance.
Example outline:
- Scope and assets
- Threat summary (incl. prompt injection, data leakage)
- Control mapping (existing vs new)
- Compliance triggers (GDPR, sector rules)
- Governance and approval path
- Residual risk and conditions
Build-buy-partner assessment
Purpose: Structured comparison of internal build, COTS/SaaS, SI partner and hybrid against time, cost, risk, control and strategic fit.
When used: Before major spend; RFP shaping; make-or-buy steering decisions.
Quality bar (VALUE): Options scored on client-weighted criteria. TCO not only licence fee. Exit strategy and IP ownership addressed. Pilot path for each option.
Common failure modes: Vendor bake-off before requirements; ignoring integration cost; no exit clause analysis; build bias without capacity check.
Learning Map topics: Vendor and Technology Evaluation, RFP, Procurement and Contracting, Commercial and Financial Modelling.
Example outline:
- Decision criteria and weights
- Option descriptions (build, buy, partner)
- Scorecard with narrative
- TCO summary (3–5 year view)
- Recommendation and conditions
- Procurement next steps
Use-case prioritisation
Purpose: Ranked backlog of use cases with value, feasibility, risk and dependency logic—so the programme does not boil the ocean.
When used: Portfolio programmes; after discovery of multiple pains; before roadmap commit.
Quality bar (VALUE): Transparent scoring. Quick wins vs structural bets labelled. Dependencies mapped. Stopped ideas listed with reasons (credibility signal).
Common failure modes: Everything is "high priority"; no sequencing; ignoring shared platform work; political ranking without evidence.
Learning Map topics: AI Opportunity Discovery, Product Management, Delivery and Programme Management.
Example outline:
- Use case list with one-line value
- Scoring model (value, feasibility, risk, readiness)
- Ranked backlog and waves
- Dependencies and platform enablers
- Stopped/deferred cases with rationale
Design
Design artefacts answer: What will we build, how will it behave, and how will we prove it is safe and measurable?
Target operating model
Purpose: Future roles, processes, decisions, metrics and governance for the solution in production—not only a technical diagram.
When used: Before build sign-off; input to change management and training; exec alignment on "how work will change."
Quality bar (VALUE): Shows human + AI division of labour. KPIs for operations. Escalation paths. Links to org design impacts (even if "no FTE change" is justified).
Common failure modes: Technology-only TOM; no exception handling; missing operational roles; benefits ownership unclear.
Learning Map topics: Enterprise Architecture, Change Management and Adoption, Product Management.
Example outline:
- Vision and scope
- Process (future state summary)
- Roles and RACI
- Governance and decision forums
- Metrics and reporting
- Transition implications
Architecture and data-flow diagrams
Purpose: Communicate components, integrations, data flows, trust boundaries and deployment zones to architects, security and engineering.
When used: Design gate; security review; build kick-off; vendor integration discussions.
Quality bar (VALUE): C4-style layering or client standard. Data classification on flows. AuthN/AuthZ points marked. External vs internal model calls clear. Matches NFRs.
Common failure modes: One vague box labelled "AI"; missing batch vs online paths; no secrets/key management; diagram disagrees with narrative.
Learning Map topics: Enterprise Architecture, Data Engineering and Architecture, Cloud Platform Engineering, Integration and Enterprise Systems.
Example outline:
- Context diagram
- Container/component view
- Data-flow diagram (with classification)
- Deployment view (envs, regions)
- Key architecture decisions pointer
- Open issues
Threat model
Purpose: Living artefact of abuse cases, mitigations and verification for the specific solution—not generic cloud security slides.
When used: Design phase; before pen test scope; before production; after major scope change.
Quality bar (VALUE): STRIDE or client method applied to prompt, retrieval, tools, outputs, admin APIs. Mitigations mapped to stories or controls. Test approach for critical threats.
Common failure modes: Copy-paste from another project; no agent/tool abuse; "LLM guardrails" without specifics; never updated after design change.
Learning Map topics: Security Engineering, Responsible AI Governance, Agentic AI and Workflow Automation.
Example outline:
- Scope and trust boundaries
- Asset and attacker profiles
- Threat table (STRIDE category, scenario, impact)
- Mitigations and owners
- Verification plan
- Residual risk
Integration design
Purpose: Specify APIs, events, identity, error handling, SLAs and data contracts between the AI solution and enterprise systems.
When used: Before sprint planning; before integration test strategy; SI handoffs.
Quality bar (VALUE): Interface catalogue with versioning, auth, payload schema, rate limits, idempotency. Failure modes defined. Ownership per interface.
Common failure modes: "We'll use REST" without contracts; no retry/idempotency; missing observability hooks; undocumented batch reconciliation.
Learning Map topics: Integration and Enterprise Systems, Software Engineering, Enterprise Architecture.
Example outline:
- Integration landscape summary
- Interface specification table
- Sequence diagrams for critical flows
- Error handling and compensation
- Non-functional integration requirements
- Test approach
Evaluation strategy
Purpose: Plan for how output quality, safety and regression will be measured from prototype through production—including datasets, metrics, gates and human review.
When used: Before POC; before pilot; before production release; continuous improvement cycles.
Quality bar (VALUE): Golden set or rubric-defined evaluation. Offline and online metrics. Safety evals for domain risks. Release thresholds. Owner for dataset curation.
Common failure modes: "Users will tell us if it's bad"; demo-only eval; no regression on model/prompt change; no bias/fairness where decisions affect people.
Learning Map topics: AI Evaluation and Quality Assurance, Generative AI and LLM Fundamentals, Prompt and Context Engineering.
Example outline:
- Quality objectives linked to requirements
- Metrics (accuracy, latency, safety, UX)
- Evaluation datasets and labelling approach
- Human review workflow
- Release gates and monitoring triggers
- Continuous improvement cadence
Responsible AI controls
Purpose: Document policies, disclosures, human oversight, logging, appeal paths and monitoring required for trustworthy deployment in the client's context.
When used: Design and build; model risk forums; regulated industries; public-facing solutions.
Quality bar (VALUE): Maps to client RAI framework or equivalent. User-facing transparency where required. Human override paths defined. Incident response for harmful outputs.
Common failure modes: Ethics principles with no controls; no logging of prompts/outputs where needed for audit; oversight undefined; no appeal for adverse decisions.
Learning Map topics: Responsible AI Governance, Privacy, Legal and Compliance, Ethics, Sustainability and Social Impact.
Example outline:
- Use case risk tier
- Control set (transparency, oversight, fairness, safety)
- Logging and retention
- Human-in-the-loop design
- Monitoring and incident response
- Approval evidence
Prototype
Prototype artefacts answer: Does the approach work well enough to justify production investment—and what gaps remain?
Prototype backlog and experiment plan
Purpose: Time-boxed plan of hypotheses, spikes and demos that reduce the highest-risk unknowns—not an unbounded feature backlog.
When used: POC/ MVP phase; before steering asks for production dates.
Quality bar (VALUE): Each item links to a risk or assumption. Success criteria defined upfront. Time box and stop rules. Out of scope explicit.
Common failure modes: Prototype becomes stealth production; no hypothesis; endless prompt tweaking without eval; ignoring integration spikes.
Learning Map topics: Software Engineering, Generative AI and LLM Fundamentals, AI Opportunity Discovery.
Example outline:
- Objectives and hypotheses
- Backlog (spike, demo, eval task)
- Success/fail criteria
- Timeline and resources
- Risks and dependencies
Evaluation dataset
Purpose: Curated inputs, expected behaviours and rubrics used to judge prototype and pilot quality reproducibly.
When used: Before comparing models/prompts; before pilot; baseline for regression.
Quality bar (VALUE): Representative of real variation (edge cases included). Version controlled. PII handled correctly. Labelled or rubric-scored with inter-rater check where subjective.
Common failure modes: Ten happy-path questions; leaked test data in prompts; no version history; eval set reused from training.
Learning Map topics: AI Evaluation and Quality Assurance, Data Engineering and Architecture, Privacy, Legal and Compliance.
Example outline:
- Dataset purpose and scope
- Composition (scenarios, counts, sources)
- Labelling/rubric rules
- Storage, access and versioning
- Known gaps and refresh plan
Demonstration script
Purpose: Rehearsed narrative that shows problem → approach → evidence → decision ask—not a random click-through.
When used: Steering committees; sponsor readouts; pilot kick-offs.
Quality bar (VALUE): Timed script with fallback paths if live demo fails. Shows failure modes and guardrails where credibility matters. Ends with explicit ask.
Common failure modes: Demo-only with no metrics; hiding bad outputs; no backup recording; technical depth wrong for audience.
Learning Map topics: Communication and Executive Articulation, Presales and Solution Shaping, UX and Human Factors.
Example outline:
- Audience and objective
- Story arc (before / after)
- Live demo steps with timings
- Evidence slide (eval results)
- Backup plan
- Closing ask
Findings report
Purpose: Honest synthesis of what was learned, what worked, what failed, and recommended next step—including stop recommendations when warranted.
When used: End of POC/pilot experiment phase; input to business case refresh.
Quality bar (VALUE): Separates validated facts from opinions. Quantitative results where promised. Production gaps listed with effort ranges. Recommendation is clear.
Common failure modes: Success theatre; burying failures; no link to value hypothesis; automatic "proceed to build."
Learning Map topics: Consulting Problem Solving, AI Evaluation and Quality Assurance, Communication and Executive Articulation.
Example outline:
- Executive summary and recommendation
- Objectives recap
- Methods and scope
- Results (quant + qual)
- Risks and open questions
- Production gap analysis pointer
- Next step options
Production-readiness gap analysis
Purpose: Checklist-driven view of what is missing between prototype and production across engineering, security, ops, data and change.
When used: Before production funding; before go-live planning; input to roadmap and RAID.
Quality bar (VALUE): Uses a standard framework (client or firm). Each gap has owner, effort, priority. No silent "we'll harden later."
Common failure modes: Only engineering gaps listed; missing runbooks, monitoring, training; gaps without estimates; treated as tick-box once.
Learning Map topics: MLOps, LLMOps and Observability, Operations and Production Support, Security Engineering.
Example outline:
- Readiness dimensions (security, ops, data, change, eval)
- Gap register (gap, impact, owner, effort)
- Priority sequencing
- Dependencies on platform teams
- Target readiness date assumptions
Commercial proposal
Commercial artefacts answer: What are we selling, for how much, with what risks—and why should the client sign?
Executive summary, scope, deliverables, assumptions, dependencies
Purpose: Contractual and executive clarity on what will and will not be delivered, on what assumptions, and what the client must provide.
When used: Proposal submission; SOW negotiation; change control baseline.
Quality bar (VALUE): Scope testable against acceptance criteria. Assumptions and dependencies numbered and owned. Deliverables map to phases. Exclusions explicit.
Common failure modes: Marketing language in scope; hidden dependencies; ambiguous deliverables; assumptions that shift all risk to client.
Learning Map topics: Presales and Solution Shaping, RFP, Procurement and Contracting, Commercial and Financial Modelling.
Example outline:
- Executive summary
- Objectives and success criteria
- Scope and deliverables by phase
- Assumptions register
- Client dependencies
- Exclusions
Timeline, team, cost, benefits, risks, acceptance criteria
Purpose: Integrated commercial view enabling investment decision—schedule realism, resource model, value case, risk disclosure and definition of done.
When used: Board or investment committee; procurement evaluation; internal margin review.
Quality bar (VALUE): Critical path credible. Roles named by seniority/skill, not generic "consultant." Benefits tied to value hypothesis. Risks with mitigations and price/schedule contingency where appropriate. Acceptance criteria SMART.
Common failure modes: Gantt fantasy; benefits copied from marketing; risks in appendix only; acceptance criteria subjective ("user satisfaction").
Learning Map topics: Commercial and Financial Modelling, Delivery and Programme Management, Performance and FinOps, Stakeholder Management.
Example outline:
- Phased timeline and milestones
- Team structure and key profiles
- Commercial model (fixed/T&M/outcome)
- Benefits and business case summary
- Risk register (top ten)
- Acceptance criteria by deliverable
- Terms pointer (IP, data, exit)
Implementation
Implementation artefacts answer: How will we deliver, control change, and prove readiness to go live?
Delivery roadmap and RAID log
Purpose: Roadmap sequences workstreams; RAID (Risks, Assumptions, Issues, Dependencies) tracks what threatens dates, cost and scope.
When used: Programme start through go-live; weekly status; steering packs.
Quality bar (VALUE): Workstreams aligned to benefits and readiness. RAID items have owner, impact, action, date. Assumptions reviewed when invalidating events occur.
Common failure modes: Roadmap is only IT tasks; RAID stale; issues without escalation path; no linkage to benefits milestones.
Learning Map topics: Delivery and Programme Management, Project Management overview, Leadership and People Management.
Example outline:
- Roadmap (waves, milestones, dependencies)
- Workstream charters (one paragraph each)
- RAID log table
- Governance cadence
- Reporting pack structure
Architecture decisions
Purpose: Record of significant technical choices, alternatives, rationale and consequences—so future teams understand why the system looks as it does.
When used: At each major fork (model, vector store, integration pattern, hosting); required by architecture review boards.
Quality bar (VALUE): ADR format: context, decision, alternatives, consequences, status. Linked to requirements and NFRs. Review date for reversible decisions.
Common failure modes: Oral history only; "we chose Azure"; no rejected options documented; ADRs never updated when reversed.
Learning Map topics: Enterprise Architecture, Software Engineering, Cloud Platform Engineering.
Example outline:
- Title and status
- Context and drivers
- Decision
- Alternatives considered
- Consequences (positive/negative)
- Compliance/security notes
Test strategy and deployment plan
Purpose: Define what will be tested, how, in which environments, with what entry/exit criteria for release—including AI-specific eval regression.
When used: Before SIT; before UAT; before production cutover.
Quality bar (VALUE): Test levels mapped to requirements. Eval regression in CI where applicable. Deployment steps with rollback. Data migration approach if any.
Common failure modes: Manual test only; no production-like data strategy; missing rollback; performance test neglected.
Learning Map topics: Software Engineering, AI Evaluation and Quality Assurance, MLOps, LLMOps and Observability.
Example outline:
- Test scope and levels
- Entry/exit criteria per environment
- AI eval and regression approach
- Deployment sequence
- Rollback and hypercare plan
- Roles (QA, ops, business)
Change-management plan and governance evidence
Purpose: Plan for adoption (comms, training, champions, resistance) plus evidence pack for governance forums that approved controls are implemented.
When used: Parallel with build; intensifies before go-live; audit and model risk submissions.
Quality bar (VALUE): Segmented audiences with behaviour outcomes. Training tied to TOM changes. Governance evidence mapped to control IDs from design.
Common failure modes: Email blast only; training generic; no champion network; governance evidence collected last-minute.
Learning Map topics: Change Management and Adoption, Responsible AI Governance, UX and Human Factors.
Example outline:
- Impact assessment (roles, process)
- Stakeholder and comms plan
- Training and enablement
- Adoption metrics
- Resistance management
- Governance evidence matrix
Transition and operation
Transition artefacts answer: How does this run safely in production, improve over time, and prove benefits?
Runbook and support model
Purpose: Operational procedures for run, monitor, troubleshoot, escalate and restore—including model/prompt change process.
When used: Before go-live; handover to BAU; on-call setup.
Quality bar (VALUE): Step-by-step for top incidents. Escalation matrix with SLAs. Known failure modes from prototype. Version of runbook matches release.
Common failure modes: Runbook is generic cloud ops; no LLM-specific incidents; missing escalation; never tested in drill.
Learning Map topics: Operations and Production Support, MLOps, LLMOps and Observability, Security Engineering.
Example outline:
- Service overview and dependencies
- Routine operations (health checks, batch jobs)
- Incident categories and playbooks
- Escalation and on-call
- Change process (models, prompts, config)
Monitoring dashboards and incident process
Purpose: Live visibility of health, quality, cost, safety signals and a defined incident lifecycle when thresholds breach.
When used: Go-live; continuous operation; post-incident review.
Quality bar (VALUE): Dashboards cover latency, errors, cost, eval drift, safety triggers. Alerts routed with runbook links. Post-incident review template exists.
Common failure modes: Infrastructure metrics only; no quality drift; alert fatigue; incidents closed without root cause.
Learning Map topics: MLOps, LLMOps and Observability, Performance and FinOps, AI Evaluation and Quality Assurance.
Example outline:
- Monitoring objectives
- Dashboard catalogue (audience per view)
- Alert rules and thresholds
- Incident process (severity, roles, comms)
- PIR template
Knowledge-transfer plan
Purpose: Structured handover of documentation, training, shadowing and sign-off so client or SI can operate without the delivery team forever embedded.
When used: Last third of implementation; contract closeout.
Quality bar (VALUE): KT sessions scheduled with materials and success criteria. Owners on client side named. Gaps tracked to closure.
Common failure modes: "Read the wiki"; no hands-on shadowing; KT skipped under schedule pressure; tacit knowledge walks out the door.
Learning Map topics: Delivery and Programme Management, Operations and Production Support, Leadership and People Management.
Example outline:
- KT objectives and audiences
- Session plan (topic, trainer, attendee, done-when)
- Artefact handover list
- Shadowing period
- Sign-off criteria
Benefits tracking and optimisation roadmap
Purpose: Measure realised value against the value hypothesis and plan continuous improvement (model, process, scope)—closing the loop from qualification to P&L.
When used: From pilot through BAU; quarterly business reviews; renewal/expansion conversations.
Quality bar (VALUE): KPIs with baseline captured. Attribution honest (controls for other initiatives). Optimisation backlog prioritised by value and eval gaps.
Common failure modes: Benefits claimed without measurement; no baseline; optimisation only technical, not business; programme closed before benefits period.
Learning Map topics: Commercial and Financial Modelling, Business Fundamentals, Change Management and Adoption, Performance and FinOps.
Example outline:
- Benefits framework (KPI, baseline, target, owner)
- Measurement method and cadence
- Results to date (honest narrative)
- Optimisation backlog
- Expansion/stop recommendations
Deliverable mastery checklist
- I can name which phase each artefact belongs to and what decision it supports
- I have produced at least one artefact per lifecycle phase on a real or practice case
- Each artefact I send externally passes VALUE (facts, assumptions, audience, evidence)
- I can explain common failure modes for the top ten artefacts my role touches most
- My artefacts trace forward: problem → design → test → ops → benefits
- A manager or peer has red-teamed at least three of my artefacts in the last quarter
Discussion
Comments
Share feedback or questions about this page. No account required.
Loading comments…