Project Documentation

<G-Code + project name> (see doc properties)

Author: author (see doc properties) Project Name: <Project Name>
Status: <Draft / Final> Project ID: <G code>
Client: <Client> Executive: <Project Executive>
<Internal only, Restricted,
Security: Project Mgr: <Project Manager>
Confidential>

Project Initiation Document Version <X_X_X> 1/14

author (see doc properties) For internal distribution only

Contents
1. Purpose 3
2. Structure of the Project Initiation Document 3
2.1. Stable 3
2.2. Dynamic 4
3. Background 4
3.1. Context 4
3.2. Reasons 4
4. Project definition 4
4.1. Project Objectives 4
4.2. Project Scope 4
4.3. Product deliverables and/or desired outcomes 5
4.4. Exclusions 5
4.5. Constraints 5
4.6. Compliance 5
4.7. Interfaces 5
4.8. Assumptions 5
5. Project Approach 5
6. Project Tolerances 6
7. Project controls 7
7.1. Controlled progress 7
7.1.1. Tolerance 8
7.1.2. Product Descriptions 8
7.1.3. Work Package 8
7.1.4. Project Issues and change control 8
7.1.5. Risk Log 8
7.1.6. Checkpoint 8
7.1.7. Planning and Replanning 8
7.1.8. Highlight Report 8
7.1.9. Exception assessment and Exception Report 8
7.1.10. End stage assessment and End stage report 8
7.1.11. Daily log 9
7.1.12. Lessons Learned Log 9
7.2. Controlled Close 9
7.2.1. Project closure notification 9
7.2.2. Lessons Learned Report 9
7.2.3. Follow-on Action recommendations 9
7.2.4. End Project Report 9
7.2.5. Post-Project Review Plan 9
8. Initial Business Case 9
9. Initial Project Plan 9
9.1. Plan description 9
9.2. Project prerequisites 9
9.3. External dependencies 10
9.4. Planning assumptions 10
9.5. Project Plan 10
9.6. Contingency Plans 10
10. Initial Risk Log 10
11. Project organisation structure 10
11.1. Project management team structure 10
11.2. Role descriptions 11
11.2.1. Project Board 11
11.2.2. Project Board – Executive 12
11.2.3. Project Board – Senior User 12
11.2.4. Project Board – Senior Supplier 12
11.2.5. Project Manager 12
11.2.6. IST Project Leader 12
11.2.7. IS pillarProject Leader 12
11.2.8. IT project leader 12
11.2.9. Project Assurance 12
11.2.10. Project Support 12
12. Communication Plan 12
13. Project Quality Plan 13
14. Risk Management Plan 13
15. Revision History 14
16. Approvals 14
17. Distribution List 14

Project Initiation Document <DD-MM-YYYY> Version <X_X_X> 2/14

author (see doc properties) For internal distribution only

Management summary
The following elements can be included in the summary:
 Some background
 Purpose
 Phasing
 Delivery date
 Costs
the calculated costs based on an hourly rates spent on this project of € x.
Direct costs or out-of-pocket expenses: € x.
 Requested decision
Approval of budget by the client.
Approval of staff activities within ASR-ICT.
 Why / Who / What

1. Purpose
The purpose of this document is to define the project, to form the basis for its management and to allow an assessment of
overall success.

The Project Initiation Document gives the direction and scope of the project and forms the ‘contract’ between the project
management team and corporate or programme management.

The primary uses of the document are to:

 Ensure that the project has a sound basis before asking the Project Board to make any commitment to the project

 Act as a base document against which the Project Board and Project Manager can assess progress, Project Issues
and ongoing viability questions.

 Provide a common understanding of the project among all project stakeholders

2. Structure of the Project Initiation Document

The sections of the PID have been divided into “Stable” and “Dynamic” to indicate those sections that will need new
versions created as the project progresses.

2.1. Stable
 Background, explaining the context of the project and how the current position has been arrived at
 Project definition, explaining what the project needs to achieve. Under this heading will be:
o Project objectives
o Project scope
o Project deliverables and/or desired outcomes
o Exclusions
o Constraints
o Interfaces
o Assumptions
 Project approach
 Project tolerances
 Project controls, laying down how to control is to be exercised within the project and the reporting and
monitoring mechanisms that will support this; it will include the exception process.

2.2. Dynamic
 Initial Business Case, explaining why the project is being undertaken
 Initial Project Plan, explaining how and when the activities of the project will occur

Project Initiation Document <DD-MM-YYYY> Version <X_X_X> 3/14

author (see doc properties) For internal distribution only

 Initial Risk Log, documenting the results of the risk analysis and risk management activities
 Project organisation structure, explaining who will be on the project management team
o Project management team structure
o Job descriptions
 Communication Plan
 Project Quality Plan

3. Background
Explain the context of the project and the main events that led to the need for the project. Input for this is available in the
Project Brief.

3.1. Context

3.2. Reasons

4. Project definition
Most of the input for this section comes from the Project Brief. Given that the Project Brief will no longer be used once the
Project Initiation Document is created and approved, and that the information from the Project Brief will be refined, this
information must be available in the Project Initiation Document.

4.1. Project Objectives

Project objectives include the measurable success criteria of the project. Projects may have a wide variety of business
cost, schedule, technical, and quality objectives. Project objectives can also include cost, schedule, and quality targets.

The objectives must be described using the SMART principle: objectives must be Specific, Measurable, Attainable,
Realistic, and Time-bound.

4.2. Project Scope

In the project context, the term scope refers to

 The features and functions that characterize a product, service, or results
 The work that needs to be accomplished to deliver a product, service, or result with the specified features and
functions.
The Scope can be divided into two dimensions:
 The activities to be carried out, e.g. design, realisation and implementation.
 The area to which the project relates, e.g. the departments involved or the domain in which the project is being
carried out.
N.B.: Sometimes the scope also includes the product and service deliverables. The scope is then three-dimensional. Within
the definitions used by Prince2, the scope is two-dimensional and the product and service deliverables are determined
separately.

4.3. Product deliverables and/or desired outcomes

Include both the outputs that comprise the product or service of the project, as well as ancillary results, such as project
management reports and documentation.

Project Initiation Document <DD-MM-YYYY> Version <X_X_X> 4/14

author (see doc properties) For internal distribution only

4.4. Exclusions

Document explicitly what is excluded from the project: what is outside the scope of the project, what products/services will
not be delivered, what objectives are not targeted.

4.5. Constraints

Lists and describes the specific project constraints associated with the project that limit the team’s options. For example, a
predefined budget or any imposed dates (schedule milestones) that are issues by the customer are included.

4.6. Compliance

"Compliance risk" is defined by the Basel Committee for Banking Supervision as "the risk of legal or regulatory sanctions,
material financial loss, or loss to reputation a bank may suffer as a result of its failure to comply with laws, regulations,
rules, related self-regulatory organisation standards, and codes of conduct applicable to its banking activities." As part of
its mission, Fortis Compliance seeks pro-active involvement in new projects before they start or at an early stage in order
to identify any risk of non-compliance with laws, regulations and internal codes of conduct, rules or policies. Keep
awareness towards compliance issues when identifying risks and writing a Project Brief or PID. Please contact pro-
actively your Compliance Officer in case of any doubt and if advice is needed to identify risks of non-compliance.
Depending of the result of a 'Quick Scan' a Compliance Officer might be assigned as a correspondent for the project.
More info is to be found on http://i-net-leg.be.fortis.bank/LCIInt/about/about_compliance.htm.

4.7. Interfaces

Other projects that interface with this project. This may be because other projects deliver products/services which are
needed for this project or vice versa. It may also be that several projects use the same people and/or resources.

This information is included to enable stakeholders to achieve the mutual dependencies between projects. These are often
forgotten during the implementation of a project. Changes in one project are therefore often passed on too late to another
project, or the consequences for other projects are not included in the assessment of Project Issues.

Interfaces with elements of the normal business operations are not stated here.

4.8. Assumptions

Lists and describes the specific project assumptions associated with the project and the potential impact of those
assumptions if they prove to be false. Project teams frequently identify, document, and validate assumptions as part of
their planning process. Examples include the availability of certain patents or licences, obtaining of a certain grant, …

5. Project Approach
This information comes from the Project Approach document. Only the chosen option is covered here.

Define the type of solution to be developed by the project and/or the method of delivering that solution. It should also
identify any environment in which the solution must fit. For example, will the solution be:
 Bought ‘off the shelf ’
 ‘Made to measure’
 Developed in-house
 Contracted to third parties
 Based on an existing product
 ‘Built from scratch’
 Based on specific technologies?

Project Initiation Document <DD-MM-YYYY> Version <X_X_X> 5/14

author (see doc properties) For internal distribution only

For detailed information on the other options considered and the reasons for selecting this approach, see the Project
Approach document.

6. Project Tolerances
Tolerance is the permissible deviation from a plan without bringing the deviation to the attention of the next higher
authority.

Project Leader

Pro

Figure 1 -The use of tolerances across the layers of management Figure 2 - Cost / Time tolerance graph

The project tolerances are refined from the Project Mandate and will be refined later on in the Project Plan/Project
Initiation Document. Stage and Work-Package level tolerances will be described in the stage plan and in the work
packages.

Describe the permissible deviation above and below the plan’s estimate of time and cost without having to escalate the
deviation to the next level of management. Also describe the tolerance levels for quality, scope, benefit, risk, and if
necessary other aspects of the project.

Note that tolerance, contingency, and change budget are not the same! The tolerance is not to be used as contingency or
as change budget. An example is shown in the table below. Remove or adapt this example when the template is used.
Deviation on Allowed Range/Deviation
Primary aspects (a tolerance is expected)
Time + -
Cost + -
Separate tolerance figures should be given for time and cost. Tolerance figures need not be the same for over and under
cost and time. A tolerance of, say, +5% to -20% may be more realistic than +/-10%. It may be more realistic to quote
tolerances as ‘real’ figures rather than percentages – for example, ten days or a defined amount of money. The setting
of these tolerances is done as part of Planning (PL).
Secondary aspects (a tolerance is recommended in specific cases)
Scope + -
Scope tolerance may be used where there is no tolerance available in either time or money. There may be agreement to
meet time and money limits by delivering reduced functionality. Examples of scope tolerance might be: ‘Yes, you can
have the house by that date, but the shower won’t be fitted’ or ‘We can identify 90% of the addresses for the mail-out by
that date, which is sufficient’.

The requirements for the project scope should be divided into ‘essential’ and ‘desirable’ – it is the difference between
the two that represents scope tolerance.
Risk + -
A different view of tolerance is taken when considering risks. Sometimes this is called a project’s ‘risk appetite’, i.e.

Project Initiation Document <DD-MM-YYYY> Version <X_X_X> 6/14

author (see doc properties) For internal distribution only

Deviation on Allowed Range/Deviation

how much risk is the Project Board prepared to take? This may vary according to the area of risk, and it is likely that
risk tolerance will be closely aligned with the other tolerance elements – for example, a company in financial trouble
might have very little financial risk tolerance, but allow a lot of risk tolerance in terms of quality. Risk tolerance is often
applied only to the whole project, but it is possible to take more or less risk with individual products.
Benefit + -
The Project Board may wish to consider another aspect of tolerance – benefit tolerance. This implies setting boundaries
on either side of a benefit. As long as the benefit is forecast to fall within these boundaries, the benefit would contribute
to a viable Business Case. Benefit tolerances are only applied to the expected benefits in the Business Case, not to
individual business products.
Quality + -
The last tolerance a project would want to invoke is quality, but sometimes limits on the other types of tolerance may
force this upon a project. Essentially, this is accepting an Off-Specification via a concession. Examples of quality
tolerance would be:’ You can have the car in any colour, as long as it’s black’ or ‘We can release the software at this
time but the response time will be longer’.

7. Project controls
Controls ensure that, for each level of the project management team, the next level up of management can
 Monitor progress
 Compare achievement with plan
 Review plans and options against future situations
 Detect problems and identify risks
 Initiate corrective action
 Authorise further work
Controls must also cover capturing on changes from outside the project and taking the necessary actions.

Indicate for each control how it is implemented for the project, the frequency that it will be performed, and who will
perform it.

This Project Initiation Document is an important control after the authorisation to initiate the project. The remainder of
this section describes controls that are used during the remainder of the project, including a controlled close.

7.1. Controlled progress

This section describes the controls that will be used to ensure that the project stays in line with the expectations defined in
this Project Initiation Document and with the current Stage Plan.

7.1.1. Tolerance

Decide on, and describe the different tolerance levels and tolerances that will be used for the project. At least there are
tolerances on time and cost; scope, risk, benefit, quality, and potentially others can also be used. Also describe where and
when these will be documented and between who these tolerances must be agreed on.

7.1.2. Product Descriptions

Decide what product descriptions must be created and when.

7.1.3. Work Package

Describe the use of work packages.

Project Initiation Document <DD-MM-YYYY> Version <X_X_X> 7/14

author (see doc properties) For internal distribution only

7.1.4. Project Issues and change control

Every project must have a procedure to handle change. Without change control there is no project control.

7.1.5. Risk Log

The management of risk is an important control throughout the project.

7.1.6. Checkpoint

Detail how checkpoints are performed.

7.1.7. Planning and Replanning

In order to stay in line with the expectations defined in this Project Initiation Document and with the current Stage Plan
replanning might be required. When and how often to replan will depend on the size and criticality of the project and is a
matter for the Project Manager’s judgement. Describe when at a minimum replanning must be performed.

7.1.8. Highlight Report

Describe the use of highlight reports such as frequency and minimal content.

7.1.9. Exception assessment and Exception Report

Exception reports are used as soon as the project is forecasted to go outside its tolerances. Exception reports are used
between the different layers of the project organisation.

7.1.10. End stage assessment and End stage report

Describe how end stage assessments are to be performed and what topics must be covered.

7.1.11. Daily log

In order to ensure that the project stays in line with the expectations defined in this Project Initiation Document and with
the current Stage Plan, the Project Manager will maintain a Daily log with records of actions or significant events not
caught by other documents (such as the Risk, Quality, and Issue log).

7.1.12. Lessons Learned Log

Describe how the lessons learned log is used.

7.2. Controlled Close

Describe how to ensure that

 All the agreed products have been delivered and accepted
 Arrangements are in place, where appropriate, to support and maintain the product in its useful life
 Any useful statistics or lessons for later projects are passed to the relevant body
 A plan has been made to enable a check on the achievement of the benefits claimed in the project’s Business
Case.

Project Initiation Document <DD-MM-YYYY> Version <X_X_X> 8/14

author (see doc properties) For internal distribution only

7.2.1. Project closure notification

7.2.2. Lessons Learned Report

7.2.3. Follow-on Action recommendations

7.2.4. End Project Report

7.2.5. Post-Project Review Plan

8. Initial Business Case

The business case is described in the Business Case document for this project. For the correct version that goes with this
Project Initiation Document (PID) refer to the Project Initiation Baseline of which this PID version is part.

9. Initial Project Plan

9.1. Plan description

Give a short summary of what is covered by the project.

9.2. Project prerequisites

Indicates what has to be arranged or realised before implementation of the plan can begin (e.g. field survey needs to be
carried out, extra staff that need to be taken on, etc.)

9.3. External dependencies

Dependencies during the implementation of a project (e.g. licences that have to be arranged by the client on time, a
relocation which must deliver the items to be moved on time).

9.4. Planning assumptions

Assumptions made when formulating a plan (e.g. production standards, whether or not allowance has been made for
overtime, agency staff, etc.).

9.5. Project Plan

Covering:
 Gantt Chart at project level showing the management stages
 Product tree at project level
 Product flow chart
 Main product descriptions
 Activity network
 Project budget
 Change budget
 Required people and resources

Project Initiation Document <DD-MM-YYYY> Version <X_X_X> 9/14

author (see doc properties) For internal distribution only

 Specific people and resources requested/allocated

 Project tolerances (e.g. time and money)
 Disaster plans
 Detailing of the investments and activities

9.6. Contingency Plans

Explaining how it is intended to deal with the consequences of any risks that materialise.

10. Initial Risk Log

Mention here the most important ones and reference the version of the current Risk Log at the time of the PID validation.

11. Project organisation structure

11.1. Project management team structure

Document the structure of the project management team supporting:

 Roles for decision makers (Project Board)
 Management by exception for the decision makers (Project Board)
 Full- or part-time project management (Project Manager)
 Controlled delegation of some day-to-day management responsibilities, where required (Project Leaders)
 Roles for the independent inspection of all aspects of project performance (Project Assurance)
 Administrative support, as required, to the Project Manager and Project Leaders (Project Support)
 Agreement by all concerned on what the various roles and responsibilities are
 Lines of communication between the project management team members.

Project Initiation Document <DD-MM-YYYY> Version <X_X_X> 10/14

author (see doc properties) For internal distribution only

Corporate or programme management

Main contacts: <names of main contacts>

Project Board


Senior User Executive Senior Supplier
<name> <name> <name>

Project Assurance
<name>
<name>
<name>

Project Manager
<name>
Project Support
<name>


<name>
<name>

IST Project Leader

<name>





Project Leaders


<name>
<name>
<name>
Assurance responsibility
Lines of guidance/advice
Lines of Authority

11.2. Role descriptions 

Describe (or reference) the different roles specifying the responsibilities, goals, limits of authority, relationships, skills,
knowledge, and experience required.



11.2.1. Project Board 
The Project Board is appointed by corporate or programme management to provide overall direction and management of
the project. The Project Board is accountable for the success of the project and has responsibility and authority for the
project within the instructions (initially contained
 in the Project Mandate) set by corporate or programme management.


11.2.2. Project Board – Executive

The single individual with overall responsibility for ensuring that a project meets its objectives and delivers the projected
benefits. This individual should ensure that the project or programme maintains its business focus, that it has clear
authority and that the work, including risks, is actively managed.

Project Initiation Document <DD-MM-YYYY> Version <X_X_X> 11/14

author (see doc properties) For internal distribution only

11.2.3. Project Board – Senior User

The Project Board role accountable for ensuring that user needs are specified correctly and that the solution meets those
needs.

11.2.4. Project Board – Senior Supplier

The Project Board role that provides knowledge and experience of the main discipline(s) involved in the production of the
project’s deliverable(s). Represents the supplier interests within the project and provides supplier resources.

11.2.5. Project Manager

The person given the authority and responsibility to manage the project on a day-to-day basis to deliver the required
products within the constraints agreed with the Project Board.

11.2.6. IST Project Leader

The IST Project Leader works in close collaboration with the Project Manager and has end to end responsibility for the
IST Delivery in the project. The IST project leader will typically come from the IS side, more specifically from the most
impacted IS pillar. role that may be employed by the IST Project Leader to manage the work of project team members.

11.2.7. IT project leader

A role that may be employed by IST Project Leader to manage the work of project team members.

11.2.8. Project Assurance

Assurance covers all interests of a project, including business, user and supplier. Project Assurance has to be independent
of the Project Manager; therefore the Project Board cannot delegate any of its assurance responsibilities to the Project
Manager.

11.2.9. Project Support

An administrative role in the project management team. Project Support can be in the form of advice and help with project
management tools, guidance, administrative services such as filing, and the collection of actual data.

12. Communication Plan

Description of:
 stakeholders
 main information to be communicated
 information carriers
 frequency of the information provision
 method of communication: who should provide the information and how should the information be generated

13. Project Quality Plan

Description of:

Project Initiation Document <DD-MM-YYYY> Version <X_X_X> 12/14

author (see doc properties) For internal distribution only

 The customer’s quality expectations. Take content from the Project Brief document
 Acceptance criteria Take content from the Project Brief document
 Quality responsibilities
 Applicable quality standards
 Quality control and audit processes for project management
 Quality control and audit processes for the specialist activities
 Change management procedures
 Configuration Management Plan including the project file structure
 Quality control tools.
 Role and tasks of S&S Information Security consultant:
o Translating business requirements into security services and testing against policy;
o Translating security services into mechanisms, products, procedures, etc. and testing against policy;
o Formulating acceptance criteria for information security and testing.

14. Risk Management Plan

Risks are identified and analyzed in the Team Meeting and Checkpoint Meeting (see also Communication Plan).

All risks are reported in the Risk Log section of the Project Log.

All risks prioritized “High” and/or Proximity “Close” and/or Risk Status “Concrete” are reported to the board via the
Highlight Report.

Project Initiation Document <DD-MM-YYYY> Version <X_X_X> 13/14

author (see doc properties) For internal distribution only

15. Revision History

Date Version Description Author

16. Approvals
Date Version Name Role

17. Distribution List

Date Version To Whom

Project Initiation Document <DD-MM-YYYY> Version <X_X_X> 14/14