Opportunity Assessment Document
How
This template defines the structure for an Opportunity Assessment Document (OAD). The OAD captures the business case, value proposition, and cost-benefit analysis for a specific use case. It is intended for business stakeholders to make go/no-go investment decisions before committing to a full Solution Design.
Instructions:
- Replace all
[bracketed placeholders]with project-specific content.- Guidance text is provided in blockquote format (lines starting with
>). Remove or replace guidance text once the section is populated.[Diagram: ...]placeholders indicate where diagrams should be inserted. Replace with the actual diagram and a brief caption. Recommended tools: draw.io, Mermaid, Excalidraw, or Power Point..- Cross-references to other documents use the abbreviations PAD, OAD, and SDD followed by the section number (e.g. “refer to PAD §2.3 Scope” or “see SDD §5.1 Component Impact Assessment”).
- An OAD should be created for any use case where business stakeholders need to make a go/no-go investment decision. For smaller use cases with pre-approved funding or low business complexity, the OAD may be skipped — note this in the PAD’s Use Case Register (PAD §4) by entering “N/A” in the OA Document column.
Document Metadata
| Field | Detail |
|---|---|
| Initiative code | [PROJECT CODE] |
| Use case title | [Use Case Name] |
| Document type | OAD – Opportunity Assessment Document |
| Status | [Draft / Under Review / Endorsed / Approved] |
| Author(s) | [Author Name(s)] |
| Approved by | [Approving body or individual] |
Document Version Control
This document has undergone the following document version controls:
| Date | Version | Change Description | Author |
|---|---|---|---|
| DD/MM/YYYY | 0.1 | Initial draft created | [Author Name] |
Contributors
| Name | Role | Area |
|---|---|---|
| [Name] | Solution Lead | [Organisation] (Vendor) |
| [Name(s)] | Business Process SME | [Business Unit] ([Client]) |
| [Name(s)] | Business Process Owner | [Business Unit] ([Client]) |
| [Name(s)] | IT Rep - Architecture (Optional) | Information Technology ([Client]) |
| [Name(s)] | IT Rep - Security (Optional) | Information Technology ([Client]) |
Document Approval Requirements
| Approval Gate | Status | Date |
|---|---|---|
| [Gate Name, e.g. Business Owner Endorsement] | [Pending / Complete] | [Date] |
| [Gate Name, e.g. Delivery Lead Review] | [Pending / Complete] | [Date] |
1 Executive Summary
[Provide a concise summary (1-2 paragraphs) of the opportunity. This should answer: What is the problem? What is the proposed approach? What is the expected value? This section should be readable by executive stakeholders who may not read the rest of the document.]
2 Background and Context
[This section provides the business context for the opportunity. It should explain why this use case exists and what the current situation is.]
2.1 Business Context
[Describe the business environment, team, and processes that are relevant to this opportunity. Who is affected? What business function does this relate to?]
2.2 Current State
[Describe the current state of the process or capability. How does it work today? What tools, systems, and manual processes are involved? Include a current state diagram if helpful.]
2.3 Problem Statement
[Clearly articulate the problem or opportunity. What pain points exist? What inefficiencies, risks, or gaps have been identified? Be specific and quantify where possible.]
3 Objectives
[Define what this use case aims to achieve. Objectives should be measurable where possible.]
3.1 Goals
[List the primary goals of this use case.]
- [Goal 1]
- [Goal 2]
- [Goal 3]
3.2 Success Metrics
[Define how success will be measured. These should be quantifiable metrics where possible.]
| Metric | Current Baseline | Target | Measurement Method |
|---|---|---|---|
| [Metric Name] | [Current value] | [Target value] | [How this will be measured] |
3.3 Phased Approach
[If the use case will be delivered in phases, describe the objectives for each phase. If single-phase delivery, this section can be removed.]
| Phase | Objectives | Target Timeline |
|---|---|---|
| Phase 1 | [Phase 1 objectives] | [Timeline] |
| Phase 2 | [Phase 2 objectives] | [Timeline] |
4 Stakeholder Analysis
[Identify the stakeholders involved in or affected by this use case.]
4.1 Stakeholder Groups
| Stakeholder Group | Role | Impact | Engagement Level |
|---|---|---|---|
| [Group Name] | [What they do in relation to this use case] | [How they are impacted] | [Inform / Consult / Collaborate / Empower] |
4.2 RACI
[If applicable, define a RACI matrix for key activities related to this use case.]
| Activity | [Role 1] | [Role 2] | [Role 3] | [Role 4] |
|---|---|---|---|---|
| [Activity] | R | A | C | I |
5 Value Proposition
[This section quantifies the value of pursuing this use case. It should provide enough information for business stakeholders to make a go/no-go decision.]
5.1 Business Process Value Stream
[Map the high-level value stream for the current business process. Quantify time, effort, and volume at each stage. This establishes the baseline for measuring improvement.]
[Diagram: Business process value stream showing key stages with time/effort metrics. Recommended: a value stream map or process flow with quantified step durations.]
| Process Stage | Volume (per annum) | Time per Transaction | FTE Effort | Notes |
|---|---|---|---|---|
| [Stage Name] | [Volume] | [Time] | [FTE hours] | [Additional context] |
5.2 Workload and SLA Analysis
[Quantify the current workload, volumes, and any SLAs that need to be met. This data helps size the solution and quantify the value.]
| Category | Question | Answer |
|---|---|---|
| Manual Resource Effort | ||
| How many people currently perform the process? | [Answer] | |
| Hours spent per day per person? | [Answer] | |
| Average case processing time? | [Answer] | |
| Workload | ||
| Cases processed per annum? | [Answer] | |
| Peak periods? | [Answer] | |
| Service Level Agreements | ||
| Any process or case SLAs? | [Answer] | |
| Impact of SLA breach? | [Answer] |
5.3 Quantified Benefits
[Describe the expected benefits of this use case. Quantify where possible.]
| Benefit | Description | Estimated Value | Confidence |
|---|---|---|---|
| [Benefit Name] | [Description] | [Quantified value: time saved, cost reduced, risk mitigated, etc.] | [High / Medium / Low] |
5.4 Change Management and Organisational Readiness
[Assess the organisational readiness for this use case. Consider training needs, process changes, role impacts, and cultural factors. This section helps stakeholders understand the people-side of the change alongside the technical and financial analysis.]
| Factor | Current State | Required State | Gap / Action Required |
|---|---|---|---|
| Training | [Current skill level] | [Required skill level] | [Training plan needed] |
| Process Changes | [Current process] | [New process] | [Change management approach] |
| Role Impacts | [Current roles] | [Impacted roles] | [Role transition plan] |
| Communication | [Current awareness] | [Required awareness] | [Communication plan] |
6 Scope
[Define the business-process scope of this use case. This covers which processes, teams, and business activities are included or excluded. Technical scope (components, integrations, infrastructure) is defined in the SDD (SDD §1.2). Platform boundary scope is defined in the PAD (PAD §2.3 Scope).]
| Area | In Scope | Out of Scope |
|---|---|---|
| Business Processes | [Which processes are included] | [Which processes are excluded] |
| Business Units / Teams | [Which teams are affected] | [Which teams are not included] |
| Geographies / Locations | [Which locations are covered] | [Which locations are excluded] |
| Data Domains | [What business data is in scope] | [What data is excluded] |
| User Groups | [Which user groups are included] | [Which user groups are excluded] |
7 Cost-Benefit Analysis
[Provide a cost-benefit analysis for this use case. This section helps stakeholders understand the investment required and expected return.]
7.1 Estimated Costs
[Break down the estimated costs for delivering and operating this use case.]
| Cost Category | Description | Estimated Cost | Frequency |
|---|---|---|---|
| [Category] | [Description] | [Amount] | [One-off / Monthly / Annual] |
7.2 Expected Savings
[Quantify the expected savings or value generation from this use case.]
| Saving Category | Description | Estimated Saving | Frequency |
|---|---|---|---|
| [Category] | [Description] | [Amount] | [Monthly / Annual] |
7.3 ROI Timeline
[Estimate when the use case is expected to break even and deliver positive ROI.]
8 Risks and Assumptions
8.1 Business Risks
[Identify business risks specific to this use case. Platform-level risks are documented in the PAD (PAD §2.6 Risks) — reference platform risks by their ID (e.g. RI-01) rather than restating them here. Only document risks that are unique to this use case’s business case.]
| # | Risk Description | Impact | Likelihood | Mitigation |
|---|---|---|---|---|
| R-01 | [Risk] | [Impact] | [Likelihood] | [Mitigation approach] |
8.2 Assumptions
[List business assumptions for this use case. If these assumptions are invalid, the opportunity assessment may need to be revised.]
| # | Assumption | Consequence if Invalid |
|---|---|---|
| A-01 | [Assumption] | [What happens if this is wrong] |
8.3 Dependencies and Constraints
[List dependencies and constraints specific to this use case’s business case. Platform-level dependencies are documented in the PAD (PAD §2.4 Dependencies and Constraints). Only document factors that affect the business viability or delivery of this specific use case.]
| # | Type | Description | Impact if Unresolved |
|---|---|---|---|
| D-01 | Dependency | [Description of dependency] | [Business impact] |
| C-01 | Constraint | [Description of constraint] | [Business impact] |
9 Recommendation
[Provide a clear recommendation based on the analysis above.]
9.1 Decision
[State the recommendation: Proceed / Proceed with conditions / Do not proceed / Further investigation required]
9.2 Recommended Approach
[Briefly describe the recommended approach. This is the high-level “how” — detailed technical design belongs in the SDD.]
9.3 Next Steps
[List the next steps if the recommendation is to proceed. This typically includes creation of the SDD.]
- [Next step 1]
- [Next step 2]
- [Next step 3]
10 Appendix
[Supplementary information supporting the opportunity assessment.]
10.1 Supporting Data
[Include any raw data, survey results, or analysis that supports the value proposition.]
10.2 Related Documents
| Document | Type | Description | Link |
|---|---|---|---|
| Platform Architecture | PAD | Foundational platform reference | [Link to PAD] |
| Solution Design | SDD | Technical design for this use case | [Link to SDD, if created] |
10.3 Glossary
[Define key terms, acronyms, and abbreviations used throughout this document.]
| Acronym / Term | Full Name / Description |
|---|---|
| PAD | Platform Architecture Document |
| OAD | Opportunity Assessment Document |
| SDD | Solution Design Document |
| [Term] | [Definition] |