Workshops arrive with a draft, not a blank page.

The position

Pre-drafted is not pre-decided

A pre-drafted artefact is not a completed artefact. It is a structured starting point that captures what the methodology has learnt about how this kind of document tends to look across thirty-plus programmes — sections, prompts, examples, common pitfalls, and the questions that have to be answered. The workshop's job is to test the draft against the specifics of this programme, replace the placeholder content with the real content, and sign off the result.

Three things follow from working this way:

• Workshops surface gaps faster. A blank page hides the questions the room hasn't thought of. A draft makes them visible — by what's in the draft that the room disagrees with, and by what's in the draft that the room doesn't yet have an answer for.
• The conversation is faster and harder. "Is this right?" produces sharper engagement than "What should we do?". People react to a concrete proposal more directly than to an abstract prompt.
• The output is consistent across programmes. Different organisations don't reinvent the structure of a Vision document, an RFI, or a Business Case. They reach different answers — but the shape of the question is the same.

And a fourth consequence, quieter but harder to undo. Without pre-drafted artefacts, the SI ends up the only party in the room with documentation — which makes the SI structurally indispensable, regardless of who is paying. The methodology levels that ground. The Client walks into the workshop with the draft; the SI's role becomes refining it, challenging it and populating it — not authoring it. That is the conversation the Client should be having with the SI, not the one where the Client is grateful for whatever the SI brings.

The library

What's covered, by lifecycle phase

The artefact library covers each of the six lifecycle phases. Templates are openly downloadable in editable formats (Word, PowerPoint, Excel as appropriate per artefact). Use, adapt, fork. Common types include:

Pre-Programme — Stages 0–5

• Problem & Opportunity Statement (Word) — Stage 0
• Vision & Strategy (Word) — Stage 1
• Enterprise AS-IS Assessment Summary (Word) with four supporting diagrams (PowerPoint): Estate-on-a-Page, Integration-on-a-Page, Capability Heatmap, Dependency Tree — Stages 1–2
• Benefits Map and ROI Driver Matrix (Excel) — Stage 2
• Governance Terms of Reference (Word) — Stage 3
• RACI Matrix (Excel)
• Risk Management Plan (Word)
• Programme Charter (Word) — Stage 5

Governance Packs

• Executive Sponsor Group pack (PowerPoint)
• Steering Committee pack (PowerPoint)
• Design Authority pack (PowerPoint)

Selection — Stages 6–9

• Funding Envelope (Excel) — Stage 6
• RFI Template (Word) — Stage 7 — structured, scored, comparable across vendors
• Vendor Comparison Tier 1 vs Tier 2 (Word) — Stage 8 input
• Software Selection Scorecard (Excel) — Stage 8

Setup & Design — Stages 10–12

• Project Repository Layout (Excel) — Stage 10
• Discovery workshop pack (PowerPoint) — Stage 11
• Solution Design Document template (Word) — Stage 12
• FDD examples (Word) — Stage 12
• Integration Specs (Word) — Stage 12
• Data Migration mapping (Excel) — Stages 11–14

Cadence & Change Control — Stage 10 onwards

Day-one templates handed to the Programme Manager at Programme Setup & Mobilisation (S10):

• Change Request Form (Word)
• Design Decisions Log (Excel)
• Weekly Programme Status Report (Word / PowerPoint)
• Sprint Review Pack (PowerPoint)
• RAID Log (Excel)

Build & Test — Stages 13–14

• Test Strategy (Word) — Stages 13–17
• Data Strategy (Word)
• Monthly Programme Report (Word)

SOW Suite — Stages 9–17

Five documents covering the multi-SOW commercial pattern:

• MSA Schedule
• SOW 1 — Discovery
• SOW 2 — Design
• SOW 3 — Build / Test / Deploy / Hypercare
• Plus the contracts framework references

Deploy — Stages 15–17

• Cutover Plan and Runbook (Excel) — Stages 15–17 — strategic cutover schedule with rollback criteria, plus the minute-by-minute operational sequence for cutover weekend; both layers in one workbook
• Site Readiness Checklist (Excel) — per site, multi-site programmes only — Stages 14–17
• Hypercare exit criteria checklist

Post-Programme — Stages 18–19

• Benefit Realisation Plan (Word)
• Lessons Learned (Word)
• Operating Model (Word)

Cross-cutting

• DevOps and Agile How-To Guide (PowerPoint) — supports the Hybrid (EDUF) methodology stance
• Stakeholder Map template
• Change Impact Assessment
• Training Tracker

What "pre-drafted" means

And what it doesn't

A pre-drafted artefact is not a completed artefact. The distinction matters because completed artefacts shut down the workshop conversation, while pre-drafted artefacts open it.

A good pre-drafted artefact has:

• Structure that holds across organisations. Section headings, fields, prompts that are the same regardless of which programme is filling them in.
• Worked examples in italics or grey. The reader can see what a filled-in section looks like without confusing it with their own answer.
• Prompts and questions, not assertions. "What is the strategic objective this programme contributes to?" rather than "The strategic objective is X."
• Visible gaps. Sections deliberately left blank, with a marker like [to be drafted with Process Owners — Software Selection (S8)], so the workshop knows exactly what its job is.

A bad "pre-drafted" artefact is one where the SI has filled in the Client-specific content during pre-work and presented it as a draft for sign-off. That is not pre-drafting; that is bypassing the Client conversation, and the workshop becomes either a rubber stamp or a re-write.

Use, adapt, fork

Open by design

The artefact library is published openly. There is no licensing arrangement, no request-access form, no premium tier. Take any template and use it. Adapt it to your programme's context. Fork it into your organisation's branding. Hand it on to a peer running an ERP programme who would benefit from it. None of that requires permission.

The methodology improves through use. If you adapt a template and the change is generally useful — better structure, sharper prompts, a section the original missed — let me know and the next version of the template will reflect it.

Recurring bad habits

To correct on sight

Five things that go wrong with workshop inputs and deliverable templates across ERP programmes, again and again. Each one feels reasonable when the decision is made; each one costs more than was saved. Correct on sight when you see them in your own programme.

• Workshops with no pre-read and no draft. The room arrives cold, the SI fills the silence, the most senior voice in the meeting drives the conversation. Use a pre-drafted artefact instead — the room has something to react to, and the questions get sharper.
• SI-supplied templates that don't fit the Client's context. SI templates often optimise for the SI's ease of delivery (consistent structure across all the SI's clients) rather than for the Client's actual decision-making needs. Use a methodology-aligned template that the Client owns, and let the SI populate sections within that structure.
• "Pre-drafted" artefacts where the SI has actually filled in the Client-specific content. This is bypassing the Client conversation under the guise of preparation. The workshop becomes either a rubber stamp or a complete re-write. Pre-drafted means structure, prompts and worked examples — not pre-decided content.
• Artefacts produced once and never iterated. A template that worked on programme N may need updating for programme N+1. The methodology is meant to learn from each delivery; the templates have to track the learning rather than calcify.
• Artefacts kept proprietary. Hoarding templates inside an SI or consulting practice doesn't make them more valuable. It makes them less valuable, because they lose the feedback loop that comes from open use. The methodology's templates are open by design.