Project Approach
[Subject]
Version 0.03
[Publish Date]
Project Approach
REVISION HISTORY
Date
[Publish
Date]
Version
Description of Change/Revision
Author
0.03
APPROVAL
Role /
Committee
Name / Members
Date of
Approval
Version
University ICT
Architecture
Committee
DISTRIBUTION
Name
Version 0.03
Position
Page 2 of 10
Project Approach
TABLE OF CONTENTS
1
Document Overview .......................................................................................................................... 4
1.1
Context.................................................................................................................................. 4
1.2
Purpose ................................................................................................................................. 5
2
The Case for Change .......................................................................................................................... 6
2.1
Background ........................................................................................................................... 6
2.2
Current State......................................................................................................................... 6
2.3
Envisioned Future State ........................................................................................................ 6
3
Solution Outline ................................................................................................................................. 7
3.1
Scope..................................................................................................................................... 7
3.2
Options.................................................................................................................................. 7
3.3
Architecture .......................................................................................................................... 8
4
References ....................................................................................................................................... 10
Version 0.03
Page 3 of 10
Project Approach
1 DOCUMENT OVERVIEW
1.1 Context
IT projects undertaken by the University of Adelaide are managed in accordance with the Project
Management Framework. The primary goals of this framework are:
 To improve the performance of IT projects through use of a consistent approach, shared best
practices, and continuous process improvement.
 To ensure that the University can exercise an appropriate level of control and oversight over IT
projects from a strategic, financial, technical, and management perspective.
For more information on the Project Management Framework, please refer to:
https://www.adelaide.edu.au/infrastructure/solution_delivery/framework/lifecycle/.
This Solution Approach has been produced in the Concept phase of the Project Management
Framework as shown in the following figure.
Figure 1: Concept phase highlighted in the Project Management Framework
The primary objective of the Concept phase is to define the starting point for the project in terms of
drivers, scope, approach, resources, and timeframes. It achieves this by:
 Identifying the project
This initial step identifies the need for change and initiates all actions to follow. Whilst in some
cases a New Project Proposal may be used, alternative forms such as e-mail, strategies, or
roadmaps will also occur in practice.
 Identifying stakeholders and needs
The drivers for the project are captured by identifying all relevant stakeholders and their needs in
terms of ‘what’ and ‘by when’. At this point, the ‘how’ in terms of potential solutions should be
avoided. A Needs Assessment is produced to ensure alignment and agreement between all
stakeholders and the Concept phase team.
 Defining the approach to meet stakeholder needs
The aim of this step is to define the solution concept that meets stakeholder needs whilst also
taking into account the broader strategic context of the University. Approach alternatives each
have an associated architecture which in turn can have an influence on scope. For example, a
business driver to replace an unsupported IT system may yield a recommended approach that
replaces one or more additional systems within the same project. This is also the step when initial
Version 0.03
Page 4 of 10
Project Approach
‘re-use’ vs. ‘buy’ vs. ‘build’ alternatives can be considered in the context of existing ICT assets and
enterprise architecture strategy. Some level of market investigation may occur for the purpose of
confirming potential solution candidates. However, market engagement via competitive tender
would typically be identified as an approach in this phase and conducted in the Feasibility phase. A
Project Approach is produced to ensure alignment and agreement between all stakeholders, the
Concept phase team, and governance bodies such as the University ICT Architecture Committee.
 Defining the project to deliver the solution
The project commencing from Feasibility phase onwards is highly dependent upon the scope and
approach endorsed at this point. For example, the Feasibility phase for a project using a
competitive tender ‘buy’ approach would be quite different to that for a ‘re-use’ or ‘build’ project.
A Project Brief is produced to seek and obtain all necessary endorsements and approvals associated
with Gate 0 of the Project Management Framework.
These elements are depicted in the following figure with this document highlighted.
Concept
Drivers
Scope
Project
Recommendations
Options
Project
Approach
Needs
Assessment
Project
Brief
Architecture
Gate 0
Registration
and Process
Advice
Figure 2: Project Approach highlighted in the context of the Concept phase
1.2 Purpose
The purpose of this document is to:
 Define the solution concept through consideration of scope, options, and architecture.
 Describe and provide justification for any recommendations made at this point.
 Enable effective enterprise architecture review and governance in terms of strategic fit and impact
on the University.
 Provide sufficient information to enable the starting point and approach for the project to be
defined in the Project Brief.
Version 0.03
Page 5 of 10
Project Approach
2 THE CASE FOR CHANGE
2.1 Background
2.2 Current State
2.3 Envisioned Future State
Version 0.03
Page 6 of 10
Project Approach
3 SOLUTION OUTLINE
3.1 Scope
The solution scope inclusions and exclusions are listed respectively in the following tables.
Table 1: Solution scope inclusions
ID
Solution Scope Inclusion
SI-01
Table 2: Solution scope exclusions
ID
Solution Scope Exclusion
SE-01
3.2 Options
Several major considerations have been identified as key drivers for the project approach. These are
listed in the following table along with the associated recommendations made.
Table 3: Considerations and recommendations for the project approach
ID
Consideration
Context
Recommendation
C-01
C-02
Further background and rationale for each of these recommendations is provided in the following
tables.
Table 4: [C-01] …
Consideration
[C-01] …
Context
Recommendation

Basis
Rationale

Implications
Version 0.03
Page 7 of 10
Project Approach
3.3 Architecture
The proposed solution architecture is shown in the following figure. The options indicated are
described in Error! Reference source not found. Error! Reference source not found. and will be
determined in the Feasibility phase of the project. A more detailed view of the StudioAbroad
application architecture is provided in Error! Reference source not found..
Figure 3: Overview of the solution architecture
The following table lists the assumptions and constraints that have the effect of enabling, supporting,
justifying, or limiting specific aspects of the solution.
Table 5: Assumptions and constraints
ID
Assumption / Constraint
AC-01
The following table lists the risks associated with either the architecture of the solution or the use of
the solution in normal business operations. Note that these do not include risks associated with the
project to deliver the solution.
Risks are factors, scenarios, or events that have the potential for negative impact. Each risk has a
likelihood of occurrence and a degree of impact in the event that it does occur. The risk rating is
determined as a product of likelihood and impact in accordance with the matrix shown in Error!
Reference source not found..
Version 0.03
Page 8 of 10
Project Approach
Table 6: Risks
ID
Risk
Likelihood
Impact
Rating
R-01
Migration strategies for the risks above will be developed in the Feasibility phase of the project.
Version 0.03
Page 9 of 10
Project Approach
4 REFERENCES
The following references were cited in this document:
There are no sources in the current document.
Version 0.03
Page 10 of 10