Initiative Canvas — Fictional Worked Example

Version: 1.1.0 | Licence: CC BY 4.0

Illustrative example only. The organisation, service, roles and scenario below are fictional. No baseline, target, cost, rating or outcome is presented as observed or achieved data. Entries described as assumptions or items to validate are prompts for a real discovery exercise, not evidence.

This example uses the same fictional internal service-request scenario as the Executive Playbook and the Weighted Scoring Matrix. It demonstrates how a short initiative brief can lead into option assessment and a recorded decision.

Problem and outcome

• Problem / opportunity: In the fictional organisation, internal service requests are reported by staff as difficult to route and resolve consistently. The scale, causes and service impact have not yet been measured.
• Users or service affected: Staff submitting internal service requests; the fictional service operations team responsible for triage and resolution.
• Strategic outcome: Make the service easier to use and improve the predictability and transparency of request handling.
• Baseline, source and date: Not yet established. The Initiative lead should agree a measurement period and source with the Service owner before setting a numeric baseline.
• Target outcome and date: To be set after baseline validation and pilot design. Candidate measures include time to acknowledge, time to resolve, request re-routing and user feedback. No numeric target is assumed in this illustration.

Options and recommendation

Option	Expected value	Cost / capacity	Risks / dependencies	Reversibility	Evidence / confidence
Defer / do nothing	No immediate change; current issues may persist	No new delivery capacity assumed; existing operating effort continues	Causes and service impact remain uncertain	High	Low; baseline not yet established
Process clarification pilot	Could clarify request categories, ownership and routing before technology changes	Limited, time-bounded discovery and process-improvement effort; estimate required	Depends on staff participation and Service owner availability	High	Medium as a testable hypothesis; validate in pilot
Targeted workflow tooling	Could support consistent routing after process needs are understood	Requires tool configuration, integration and support assessment	Tool fit, integration, data quality and ongoing ownership need validation	Moderate	Low to medium; dependent on requirements and technical assessment
Broad platform replacement	Could address wider workflow needs, if substantiated	Material investment and change capacity would be required	Higher implementation, migration, adoption and reversibility exposure	Lower	Low at this stage; scope and need are unproven

• Recommended option and rationale: Subject to sponsor approval, run a bounded process-clarification pilot before committing to workflow tooling or platform replacement. This is a provisional recommendation for learning, not a claim that the pilot will improve measured performance.
• Why alternatives are not preferred: Deferring provides no structured evidence about causes. Targeted tooling and broad replacement would commit to technology before the process, requirements and baseline are sufficiently understood.

Mandate and ownership

• Executive sponsor: Fictional Director of Corporate Services (role label only; no real person or organisation).
• Initiative lead: To be appointed by the fictional organisation.
• Service owner: Fictional Internal Services Manager.
• Benefit owner: To be confirmed; should be accountable for validating service-outcome evidence independently of delivery completion.
• Decision authority and required-by date: Fictional Executive sponsor for the bounded pilot, within delegated limits; date to be set by the organisation.

Delivery and lifecycle

• Scope / exclusions: Map the request journey, clarify categories and routing ownership, test revised guidance and measure a bounded pilot. Exclude procurement or implementation of a replacement platform from the initial mandate.
• Milestones and acceptance evidence: Agree baseline method; map current process; approve revised categories and routing; run pilot; review evidence and recommendation. Acceptance evidence should include the agreed process artefacts, pilot participation and data-quality checks.
• Skills and capacity: Service operations, process analysis, user research and basic data analysis. Availability and effort must be confirmed before approval.
• Architecture, security, privacy and procurement assurance: Confirm whether request data includes personal or restricted information; involve relevant specialists if data collection, access or tooling changes require it. No new technology procurement is assumed for the pilot.
• Operations, support and service transition: The Service owner retains operational accountability. Document the revised process and ownership before any wider rollout.
• Adoption and change plan: Explain the revised request categories and routing to pilot users; gather feedback; adjust guidance before considering wider adoption.

Controls and benefits

• Lifecycle cost / estimate to complete: To be estimated for the bounded pilot, including staff time and any support required. No monetary amount is assumed here.
• Mandatory obligations (separate from scoring): None identified in this illustrative scenario. A real assessment must validate legal, regulatory, contractual, security, resilience and service obligations with the competent authorities before discretionary scoring.
• Key dependencies, owners and responses: Availability of service staff and users; ownership of request data; access to reliable timestamps and categorisation. Assign named owners during mobilisation.
• Risks and assumptions: The reported friction may have several causes; available data may be incomplete; process clarification may not address all needs. Validate these assumptions before extending the initiative.
• Tolerances and forecast-based escalation triggers: Define at mandate approval. Escalate if the pilot cannot obtain usable baseline data, disrupts critical service operations, exceeds approved capacity, or identifies a material risk outside delegated tolerance.
• KPIs and benefit profiles: Define measures and baseline before the pilot. Candidate measures are acknowledgement time, resolution time, re-routing rate and user feedback; no improvement is claimed.
• Decision requested, conditions and review trigger: Approve or reject a bounded discovery and process pilot, subject to confirmed capacity, data access and operational safeguards. Review at the end of the pilot before any tooling or scale decision.

How this example connects to the other artefacts

1. Use the Weighted Scoring Matrix to compare discretionary options after mandatory obligations and capacity constraints have been identified.
2. Use the Decision Record to capture the actual authority's decision, conditions, dissent and review trigger. The separate fictional decision-record example illustrates the format.
3. Use the Benefit Profile and KPI Dictionary only after the measurement definitions, owners and baseline method have been agreed.

The example stops at a proposed pilot decision. It does not invent pilot findings, achieved benefits or a subsequent scale-up decision.