Project Name
Solution Concept Manual
Prepared by:
Issue date:
Version:
University of Calgary
Information Technologies
dd Month year
0.0
Information Technologies
Solution Concept Manual
Client: Client Name
Project: Project Name
Date: dd-mmm-yyyy
<The revision history log maintains a record of changes to this document, along with the associated
revision number and date. The Communication of Change column is intended to document how the
change was communicated to all stakeholders.>
Document History
Revision
Number
Date
dd-mm-yy
Description of Changes
Author / Editor
Communication
of Change
Initial drafts
Document Owner
Name
Title
Organization
E-mail
Tel.
Document Distribution
Name
Document ID: 01002001
Type of Copy
Title
Organization
E-mail
Tel.
Page 2 of 8
Information Technologies
Solution Concept Manual
Client: Client Name
Project: Project Name
Date: dd-mmm-yyyy
Table of Contents
< To update, right-click inside the table and choose Update Field, Update Entire Table, OK. >
1.
2.
3.
4.
Executive Summary ................................................................................................. 4
Business Outcomes ................................................................................................ 4
IT Outcomes ............................................................................................................. 4
Solution Concept ..................................................................................................... 4
4.1.
4.2.
4.3.
4.4.
Proposed Solution ...................................................................................................... 5
Solution Elements ...................................................................................................... 5
Solution Approach ..................................................................................................... 5
Scope Exclusions ....................................................................................................... 5
5. Business Operational Requirements ..................................................................... 5
6. IT Operational Requirements .................................................................................. 5
7. Interfaces/Integration Points................................................................................... 6
8. Standards and Policies ........................................................................................... 6
9. Key Assumptions..................................................................................................... 6
10. Key Constraints ....................................................................................................... 6
11. Delivery Methodology/Approach ............................................................................ 6
12. Outstanding Items ................................................................................................... 6
13. Appendices .............................................................................................................. 7
13.1. Appendix 1 – Appendix Name ................................................................................... 8
Document ID: 01002001
Page 3 of 8
Information Technologies
Solution Concept Manual
Client: Client Name
Project: Project Name
Date: dd-mmm-yyyy
1.
Executive Summary
< Provide an overview of the problem or opportunity to be addressed, the value of addressing the
problem or opportunity, identify the key IT and business building blocks that comprise the
proposed solution including any critical dependencies to other initiatives, identification of any key
assumptions or risks that are significant and bear mentioning in an exectutive summary that may
yet to be resolved before the final solution is developed. Where applicable this should give a
sense how the solution may change how the users operate compared to their current state.>
2.
Business Outcomes
< Identify the targeted business outcomes and associated metrics that help to determine success
and which could be used to determine the benefits side of the business case for the solution.
This includes the outcomes that support academic priorities. Typically, this area should focus on
outcomes that are consistent with priorities of the U of C Business Plan. The Outcome Planning
process helps to identify these For certain IT driven initiatives, the business outcomes may be
focused on addressing IT issues. If there is a separate document that states the business case
for the initiative that defines these outcomes, then they need not be repeated in detail here, only
summarized with a reference to the other document for more detail. As per the table below, you
should treat this as a table with one column identifying the outcomes and the other how they
could be measured.>
Business Outcome
3.
Metrics
IT Outcomes
< Identify the key IT outcomes (deliverables, capabilities) that will need to be delivered to support
the targeted business outcomes, including any associated metrics. For those initiatives where IT
benefits have tangible value, such as reducing licensing costs or reducing the capital investment
required, you may choose to identify the outcomes as business outcomes. More typically, this
will identify the various information systems capabilities that need to be in place to support the
realization of the target business outcomes. As per the table below, you should treat this as a
table with one column identifying the outcomes and the other how they could be measured. >
Outcome
4.
Metrics
Solution Concept
< This section should describe the solution being defined. This is the core piece of the Solution
Concept Manual as it describes the solution being proposed, the various elements of the solution,
how it will be constructed, and specifies any elements that are out of scope for the solution.
There needs to be a fair degree of flexibility as to how this section will appear based on the
Document ID: 01002001
Page 4 of 8
Information Technologies
Solution Concept Manual
Client: Client Name
Project: Project Name
Date: dd-mmm-yyyy
nature of the initiative being described. It is quite likely that there will be various graphical content
too . >
4.1.
Proposed Solution
< This section describes the overall solution concept to document how the solution will provide
the various business and IT outcomes described above. The description of the solution needs to
describe the overall solution not just the IT pieces so that the reader gets a clear view of how the
solution described will actually establish the capability to realize the outcomes.>
4.2.
Solution Elements
< This section needs to itemize at a summary level the various elements – technical and nontechnical - of the proposed solution. It will include the software, and hardware elements, any
specific supporting infrastructure elements if deemend in scope, business process work, training,
etc. All of the main end deliverables required to enable the solution to be implemented and
moved into production. >
4.3.
Solution Approach
< This section is to describe the recommended approach for proceeding with the actual
specification, design, develop/build/buy, test, implement of the solution. It will include any
prototyping or piloting work to help address existing uncertainties. It is not expected to go into
great detail, but to describe the general approach that will be taken to provide the solution. >
4.4.
Scope Exclusions
< This section is intended to identify any scope exclusions. This may include expansion of
supporting infrastructure if it is expected that this expansion will be the result of a separate
initiative. Similarly, policy decisions by management or business process changes may be
deemed as out of scope if they are expected to happen as part of a complimentary or parallel
initiative. In these cases, there may need to be assumptions or integration/interfaces
documented in the appropriate section as well. >
5.
Business Operational Requirements
< Identify what needs to change in how the business performs their work to achieve the business
outcomes. The primary focus here is on various business process changes that may be required,
but it also will define any behavioral changes. An effective way to communicate this is to focus
on how it is done today, and then how it will be peformed in the future.terms of business. >
6.
IT Operational Requirements
< This section needs to identify what will be required in IT to be added or changed to support the
solution once it is in production. It needs to consider the various people, process, technology and
partnering aspects of what needs to be done for IT to be successful in supporting the solution at
the desired levels of service. Many of the operational elements of release management are
related to this section. It needs to consider the capacity, availability and support requirements for
existing and incremental infrastructure and related tools. It also needs to consider what is
needed from a financial and resource perspective to sustain, maintain and support the solution
over time. >
Document ID: 01002001
Page 5 of 8
Information Technologies
Solution Concept Manual
Client: Client Name
Project: Project Name
Date: dd-mmm-yyyy
7.
Interfaces/Integration Points
< This section needs to define the key integration points or dependencies to other systems and
services. It helps to demonstrate/communicate how the solution will connect to other systems,
projects, etc. It only needs to be at a level of detail sufficient to help manage the work to ensure
that it is integrated with other existing and parallel initiatives. It needs to include service,
hardware, software, project and data integration points. >
8.
Standards and Policies
< This section needs to identify any applicable standards and policies that should be considered
when defining and selecting the solution. While these standards and policies may not always be
followed, it is important that they be understood, and that any exceptions to these policies and
standards be done via a conscious decision. This may include technical or non-technical
standards, as applicable to the current initiative. >
9.
Key Assumptions
< This section is intended to be a collection point for key assumptions that have been made in the
formulation of the solution concept or approach. Where these assumptions are critical to the
success of the initiative, it is important that they be documented for future confirmation and
action. >
10.
Key Constraints
< This section will identify key constraints that are likely to influence the design, timing, scope or
approach of the initiative to deliver the solution. They may be technology constraints, physical
constraints, existing standards, user schedule requirements, etc. >
11.
Delivery Methodology/Approach
< This section is to describe the recommended approach for proceeding with the actual
specification, design, develop/build/buy, test, implement of the solution. It will include any
prototyping or piloting work to help address existing uncertainties. It is not expected to go into
great detail, but to describe the general approach that will be taken to provide the solution. >
12.
Outstanding Items
< Provide a list of questions and unknowns that must be determined before the final product
design can be considered. This section here will be dynamic as the Solution Concept progresses
to track various actions and uncertainties that need to be addressed. As the solution concept
may well continue to evolve after the project has started as the initiative proceeds to detailed
design, it is important to track these items. Some of these will map back to key assumptions,
constraints and interfaces. The table below is an example of how these may be documented. >
Item
Description
Document ID: 01002001
Impact
Responsible
Required By
Page 6 of 8
Information Technologies
Solution Concept Manual
Client: Client Name
Project: Project Name
Date: dd-mmm-yyyy
13.
Appendices
< Includes any supporting documentation and details of the solution concept. These can be
statistics, requirements, technical information, outcome plans, etc. Whatever information is felt to
be supportive of the Solution Concept Manual, but do not need to be in the primary document.
References to the items that exist in the appendix need to made in the appropriate section(s) of
the document. There should be nothing in the appendix that is not referenced from somewhere in
the document. Each separate document or set of information should be in a separate appendix. >
Document ID: 01002001
Page 7 of 8
Information Technologies
Solution Concept Manual
Client: Client Name
Project: Project Name
Date: dd-mmm-yyyy
13.1. Appendix 1 – Appendix Name
< Include the name of the appendix as part of the heading name. eg: Appendix 1 – Cost Detail >
Document ID: 01002001
Page 8 of 8