Solution Concept Manual

Information Technologies

Solution Concept Manual
Client: Client Name

Project: Project Name

Date: dd-mmm-yyyy

Project Name

Solution Concept Manual

Prepared by: Universityof Calgary

Information Technologies

Issue date:dd Month year

Version:0.0

Document History

Revision Number / Date / Description of Changes / Author / Editor / Communication of Change
dd-mm-yy / Initial drafts
Document Owner
Name / Title / Organization / E-mail / Tel.
Document Distribution
Name / Type of Copy / Title / Organization / E-mail / Tel.

Table of Contents

< To update, right-click inside the table and choose Update Field, Update Entire Table, OK. >

1.Executive Summary

2.Business Outcomes

3.IT Outcomes

4.Solution Concept

4.1.Proposed Solution

4.2.Solution Elements

4.3.Solution Approach

4.4.Scope Exclusions

5.Business Operational Requirements

6.IT Operational Requirements

7.Interfaces/Integration Points

8.Standards and Policies

9.Key Assumptions

10.Key Constraints

11.Delivery Methodology/Approach

12.Outstanding Items

13.Appendices

13.1.Appendix 1 – Appendix Name

Document ID: 01002001Page 1 of 8

Information Technologies

Solution Concept Manual
Client: Client Name

Project: Project Name

Date: dd-mmm-yyyy

Document ID: 01002001Page 1 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 / Metrics

3.IT Outcomes

< Identify the key IT outcomes (deliverables, capabilities) that will need to be delivered to support thetargeted 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 / Metrics

4.Solution Concept

< This section should describe the solution beingdefined. 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 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 non-technical - 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. >

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

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 / Impact / Responsible / Required By

13.Appendices

Includes any supporting documentation and detailsof 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. >

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: 01002001Page 1 of 8