<Project Title>

Initiating Author:

Department:

Revision History

Date Version Description Changed by

Contents
1.Introduction. 3
2. Project Objectives. 4
2.1 Goals and Objectives. 4
2.2 Critical Success Factors. 4
3. Scope. 5
3.1 Organisational Scope. 5
3.2 Logical Scope. 5
3.3 Temporal Scope/Phasing. 6
3.4 Related Projects. 6
3.5 Out of Scope. 6
4. Risks, Constraints and Assumptions. 7
4.1 Risk Management Approach. 7
4.2 Risks. 7
4.3 Constraints. 7
4.4 Assumptions. 7
5. Project Organisation. 8
5.1 Project Structure. 8
5.2 Roles & Responsibilities. 9
6. Project Control. 10
6.1 Issue Control. 10
6.2 Change Control. 10
6.3 Quality Assurance. 10
6.4 Financial Control. 10
6.5 Information Management. 10
7. Reporting.. 11
7.1 Reporting within the Project Team. 11
7.2 Management Reporting. 11
8. Stakeholders. 12
8.1 Identification and Analysis. 12
8.2 Communication. 12
9. Planning.. 13
9.1 Approach. 13
9.2 Milestone Plan. 13

1. Introduction
Give some information on the Institution and the context of/background to the Project.
How big is it going to be and what areas will it cover?
What approach will be taken?
2. Project Objectives
2.1 Goals and Objectives
An explanation of context of goals and objectives including some detail on how they were arrived at
and who was involved (can append any detailed information if required). Objectives give detailed
support to the Goals. An example is shown:

Goals Objectives

The system will improve job It will be a tool to help staff do the job they are paid for, not
satisfaction levels within the an added source of frustration
Institution
It will ease the administrative burden by allowing users to
work efficiently and effectively thus freeing time for those
activities which add greater value
Staff will have readily accessible the day-to-day information
they need to do their job
It will provide greater transparency for decision makers at all
levels

2.2 Critical Success Factors

How will you judge whether the objectives of the project have been met? Try to think of measurable
improvements associated with each of the objectives. Even an apparently vague goal such as
improve job satisfaction can have tangible and measurable objectives if you are sufficiently specific
about them. If you are not specific about objectives you may find it hard to assess the value of the
project.

3. Scope
3.1 Organisational Scope
Sets out how the organisation is going to approach the project including details of any intention to
secure the services of a supplier/partner.
Broad explanation of how the project will incorporate requirements of the various stakeholders within
the organisation. Also, any available details on to what extent, if any, the organisation may be
required to give access to external parties.
3.2 Logical Scope
Gives a high level overview when purchasing a system of the areas or processes covered by the
project as well as any interfacing and infrastructure details when purchasing a system it can be
useful to finalise this as part of your Invitation to Tender. An example would be key Student
Administration processes within a project scope as detailed below:
Student Administration
Programme and Module Catalogue
Quality Procedures and Checks
Enquiries
Applications and Admissions
Clearing Houses
Enrolment
Student & Community Information
Timetabling
Assessment and Examinations
Progression and Awards
Graduation
Leavers and Alumni
Research
Reporting to External Bodies
Management Information Production

3.3 Temporal Scope/Phasing

This should give an overview of the time constraints and milestones, including start and end dates
where these are known. It will be helpful to break the project down into phases and identify what is in
scope for each phase (even if you cant yet set timescales for all phases). You may need to think
about:
Processes
Software Applications
Hardware
Locations
Users
Infrastructure
Interfaces
Testing

Phase: Phase Title

Scope:

Dates/Duration:
Deliverables:

Users/Locations:

3.4 Related Projects

List any related projects (if any) with details of expected completion dates and any potential for
overlap of requirements for support resource as this could have knock-on effects re timescales,
etc. Also flag any other potential impacts and identify, where possible, any requirement for output
from the other projects.
Projects Expected
Completion

Workflow Mapping: a team is mapping the current processes relating to student April 2008
administration. There is a potential conflict with the system selection project as
some members of the workflow team will be required to contribute their process
knowledge to the system selection project.

3.5 Out of Scope

If any potentially related areas have been defined as out of scope it is worth making this explicit e.g.
you are implementing a system to undertake course timetabling but not exam timetabling or you are
implementing a personnel system that does not include payroll.
4. Risks, Constraints and Assumptions
4.1 Risk Management Approach
A description of the approach you are taking can be included here, including responsibilities for
recording risks and implementing appropriate risk management strategies, as well as communicating
such information to the Project Steering Board. A fuller consideration of Risk Management is given in
the Risk Management infoKit (http://www.jiscinfonet.ac.uk/InfoKits/risk-management).

4.2 Risks
In terms of recording identified risks, actions to be taken and early warning signs we recommend that
you use the JISC infoNet Risk Assessment template (http://www.jiscinfonet.ac.uk/ra.doc). This is
because you will need to review and update the risk management document throughout the course of
the project. You may however wish to summarise the main risks here or paste in details from the risk
template to give an overview of the risks perceived at the start of the project.

4.3 Constraints
This section summarises any constraints that affect the scope of your project or how you carry out the
project e.g. project staff are only available during the summer vacation, new system must interface
with another system, requirements of external bodies affect the extent to which you can alter a
process etc.

4.4 Assumptions
This is a list of assumptions on which the initial project framework and plan are based. The JISC
infoNet Project Management infoKit discusses the sort of assumptions that can cause issues if not
clarified initially. Examples may relate to many areas including: provision of infrastructure, IT support,
resource availability, communication, training, staff development, working arrangements (and
flexibility) and user expertise. Take particular care in defining what is expected of people outside the
project team.

Project Assumption
5. Project Organisation
5.1 Project Structure
It may be helpful to show the project structure as a diagram as example is given below:
5.2 Roles & Responsibilities
Direct resource requirements for the project should be detailed here. This should indicate the
numbers and types of staff and their estimated commitment to the project. We recommend using the
JISC infoNet Roles and Responsibilities template (http://www.jiscinfonet.ac.uk/templates/randr.doc) to
record the detail of roles and responsibilities as this may need regular updating during the course of
the project. A summary of that document could be pasted in or appended to this Project Initiation
Document.

Project Role Number of Days per Total Days for

People Week the Project

6. Project Control
How will the project be monitored and controlled on a day-to-day basis? How will it be evaluated?
What methods will be used to facilitate effective team working?

6.1 Issue Control

This section should define how the project team is going to deal with issues. Project issues must be
identified, prioritised and dealt with swiftly to ensure that dependent activities are not affected. An
issues log is an ideal way of keeping a record of issues as they arise and also recording how they are
resolved. The JISC infoNet Project Management infoKit provides a template Project Controls
Database (add url) that contains an issue log.

6.2 Change Control

The change control section documents what happens when someone proposes a modification to the
planned output of the project. Each Change Request should be documented (including initiator,
reasons and a description of the change required) and evaluated in terms of its impact. The
appropriate actions required to resolve the requested change can then be determined. Change
Requests can then be dealt with by the Project Steering Board, or other agreed person/group
supporting the project. The JISC infoNet Project Management infoKit provides a template Change
Request form (http://www.jiscinfonet.ac.uk/templates/crf.doc) and template Project Controls Database
that contains a change control log (add url).

6.3 Quality Assurance

What Quality Assurance measures are planned? Who will evaluate quality and when? Will an
external assessor be appointed? How will deliverables be tested and formally signed off? Is there an
agreed User Acceptance Testing mechanism?

6.4 Financial Control

Outline responsibilities for the control of expenditure and budgets. You may wish to attach the project
budget as an appendix to this document but you will need to consider the confidentiality of such
information especially where you are working with third parties.

6.5 Information Management

How is relevant project information to be held? There are issues here regarding quality and
availability of information it may be useful to put in place a central repository or project library of
relevant information and initiate a culture of sharing information throughout the project. The
importance of information management should not be underestimated it can be a critical
contributory factor to successful achievement of project goals. A fuller discussion of Information
Management can be found in our suite of Information Management resources
(http://www.jiscinfonet.ac.uk/information-management).

7. Reporting
7.1 Reporting within the Project Team
This section should define how and when the project team members report progress.

7.2 Management Reporting

This section should define how and when the Project Manager reports to the Sponsor and/or Steering
Board.

8. Stakeholders
8.1 Identification and Analysis
It is useful at this stage not only to identify your key stakeholders but to undertake some analysis of
what their perceptions of your project are likely to be. This will help to show that you are aware of
their views and will help you focus communications. We recommend that you use the JISC infoNet
Stakeholder Analysis template (http://www.jiscinfonet.ac.uk/templates/sa.doc) for this purpose as the
document may need regular updating. You may wish to summarise the key stakeholders here or
append your analysis.
8.2 Communication
Appropriate two-way communication with stakeholders is crucial to the success of the project. This
matrix gives examples of how you may start to think about the interested parties and the suggested
communication channels to be used for each group.

Stakeholders Expected Communications Frequency Media

Project Steering Status reporting In line with Project Generally, formal

Board Issues reporting milestones reports to be followed
Dependent on up by face-to-face
timing and priority contact where
appropriate

Project Team Documentation and In line with plan Central repository,

standards Ad hoc as managed by project
Project knowledge necessary administration
Internal communications Group e-mail
Team meetings

Admin User Informal communication of In line with plan Group e-mail, from
Representatives progress Ad hoc on demand project office
Discussion of issues Formal reports plus
Respond to issues raised informal communication
with Project Team

9. Planning
9.1 Approach
This section should outline your approach to project planning. JISC infoNet advocates the Sliding
Planning Window approach as described in the Project Management infoKit.

9.2 Milestone Plan

Insert a copy of the initial outline plan or summarise the key milestones and dates.