PMO Handbook v1.5

PMO
HANDBOOK
REV 1.5
12th June 2015
PMO HANDBOOK
VERSION CONTROL
Revision History
Revision Date Description of Change
1.0 28/5/2014 Document Created
1.1 28/7/2014 Document Amended – reformatted / restructured for ease of
reading
1.2 01/8/2014 Document Amended
1.3 25/8/2014 Amendments to reflect minor formatting changes and inclusion of
latest Capital Project Governance process lifecycle
1.4 9/9/14 Formatting changes to Roles section
1.5 23/03/15 General format changes and update brand
1.5 12/06/2015 Update to Financial Management Process
Sign Off, Review & Information

The following stakeholders are required to either sign off (or formally delegate sign off), review, or have been
provided with a copy for information purposes. It is understood that Reviewers required to sign off do so
primarily from the perspective of their relevant business area / project role.
Document Preparation, Review, Distribution

Responsibility Task Action Date
Tony Boylan Construction Review Sign Off
Máire Ganly Review and feedback Review
Colm Baldwin Review and feedback Sign Off
Consultation Group Review and feedback Sign Off
PMO Steering Review and approval Sign Off
Project Summary Information

Sponsor COO
Project Manager/Interim Head PMO Máire Ganly
SME PMO Jim Cumiskey
SME Construction Tony Boylan
START – Project Number CSD-005
th
Issued: 12 June 2015 PMO Handbook V1.5 Page 2 of 85
PMO HANDBOOK
Table of Contents
1 Introduction ..................................................................................................... 6
1.1 Purpose of the College PMO Handbook ............................................................................... 6
1.2 Executive Summary .............................................................................................................. 6
1.3 Scope of the PMO ................................................................................................................. 7
1.4 Project Risk Indicator (PRI) ................................................................................................... 9
2 Capital Project Governance ...................................................................................... 10
2.1 Project Approval & Prioritisation ....................................................................................... 12
2.2 Initiation and Strategic Planning ........................................................................................ 13
2.3 Detailed Planning and High Level Design ........................................................................... 14
2.4 Detailed Design................................................................................................................... 15
2.5 Execution and Handover .................................................................................................... 16
2.6 Closeout .............................................................................................................................. 17
2.7 Post Project ........................................................................................................................ 18
3 Key Capital Project Governance Processes ................................................................ 19
3.1 Project ID Request process ................................................................................................. 19
3.2 Project Approval and Prioritisation process ....................................................................... 20
3.2.1 Business Case pack preparation.................................................................................... 21
3.2.2 PASS 1 – Filter and Create Potential Project Shortlist .................................................. 21
3.2.3 PASS 2 – Assess Business Case and Supporting Documents ......................................... 23
3.3 Project Portfolio Performance Reporting Process ............................................................. 25
3.3.1 Preparation of Status Report by Project Manager........................................................ 25
3.3.2 Collation of status information and issuance to CRG by PMO...................................... 25
3.3.3 CRG Project Portfolio Performance meeting ................................................................ 26
3.4 Project Stage Gate Approval Process ................................................................................. 27
3.4.1 Stage Gate Approval steps ............................................................................................ 27
3.5 Change Request (CR) management process ...................................................................... 29
3.5.1 Background ................................................................................................................... 29
3.5.2 Recording information about the requested change ................................................... 29
3.5.3 Authority to Initiate Change Request ........................................................................... 31
3.6 Project Financial and Resource Management Processes ................................................... 35
3.6.1 Project Financial Management process ........................................................................ 35
3.6.2 Project Resource Management process ....................................................................... 35
3.7 Risk, Assumption, Issue & Dependency (RAID) Review Management Process .................. 37
3.7.1 RAID Item Ranking (Heat Map) ..................................................................................... 38
3.8 RAID Definitions.................................................................................................................. 39
th
PMO HANDBOOK
3.8.1 Risk ................................................................................................................................ 39

3.8.2 Assumption ................................................................................................................... 39
3.8.3 Issue .............................................................................................................................. 39
3.8.4 Dependency .................................................................................................................. 39
3.9 RAID Review Management process ................................................................................... 40
3.9.1 Risk Review Management process................................................................................ 41
3.9.2 Assumption Review Management process ................................................................... 43
3.9.3 Issue Review Management process .............................................................................. 45
3.9.4 Dependency Review Management process .................................................................. 47
3.10 Project Recruitment process .............................................................................................. 49
3.11 Project Procurement process ............................................................................................. 49
3.12 Programme and Project Roles and Responsibilities ........................................................... 50
3.12.1 Introduction .................................................................................................................. 50
3.12.2 Sponsor ......................................................................................................................... 51
3.12.3 Steering Committee and Members............................................................................... 53
3.12.4 Programme Manager .................................................................................................... 55
3.12.5 Project Manager............................................................................................................ 57
3.12.6 Independent Construction Validating Agent ................................................................ 60
3.12.7 Business Analyst ............................................................................................................ 61
3.12.8 Subject Matter Expert (SME) ........................................................................................ 62
3.12.9 Legal Advisor ................................................................................................................. 62
3.12.10 Financial Advisor ........................................................................................................... 62
3.12.11 Trainer ........................................................................................................................... 63
3.12.12 Architect ........................................................................................................................ 63
3.12.13 Cost Management and Quantity Surveyor ................................................................... 63
3.12.14 Structural Engineer ....................................................................................................... 64
3.12.15 Mechanical, Electrical, Public Health Services Consultant (MEP) ................................. 65
3.12.16 Fire Consultant .............................................................................................................. 65
3.12.17 Health & Safety Consultant ........................................................................................... 66
3.12.18 Traffic Consultant .......................................................................................................... 66
3.12.19 Fit Out Specialist ........................................................................................................... 67
3.12.20 Sustainable Energy Consultant ..................................................................................... 67
3.12.21 Planner .......................................................................................................................... 67
3.12.22 Archaeologist ................................................................................................................ 68
4 Capital Review Group (CRG) ..................................................................................... 69
4.1 Introduction ........................................................................................................................ 69
4.2 Key Objectives .................................................................................................................... 69
4.3 Key Responsibilities ............................................................................................................ 70
th
PMO HANDBOOK
4.4 Level of Approval Authority................................................................................................ 70

4.5 CRG Meeting Types and Timeline....................................................................................... 71
4.5.1 High Level CRG communications flows ......................................................................... 71
4.5.2 Project Approval & Prioritisation .................................................................................. 71
4.5.3 Monthly Project Portfolio Performance Review ........................................................... 72
4.5.4 Stage Gate ..................................................................................................................... 72
4.5.5 Change Requests ........................................................................................................... 72
4.6 CRG Meeting Principles ...................................................................................................... 72
5 General Project Administration and Support ............................................................ 74
A 1. The Capital Projects Governance Process ..................................... 75
A 2. Definitions ................................................................................... 81
A2.1 Projects and their classifications ........................................................................................ 81
A2.2 Risks, Assumptions, Issues and Dependencies ................................................................... 81
A2.3 Estimation, Risk and Contingency ...................................................................................... 82
A 3. Abbreviations used ...................................................................... 83
A 4. Templates and other documents .................................................. 84
A2.4 Artefacts ............................................................................................................................. 84
A2.5 Reference standards and sources ...................................................................................... 85
FIGURES
Fig 1. Approval & Prioritisation high-level information flow .............................................................................. 7

Fig 2. Performance Reporting high-level information flow ................................................................................ 8
Fig 3. Project Risk Indicator ................................................................................................................................ 9
Fig 4. Capital Project Stages .............................................................................................................................. 10
Fig 5. Change Request Management process flow ........................................................................................... 30
Fig 6. Probability-Impact Matrix ....................................................................................................................... 38
Fig 7. RAG StatUS Definitions ........................................................................................................................... 39
Fig 8. High Level Communication flows ............................................................................................................ 71
Fig 9. Primecore Stage Gate Model .................................................................................................................. 75
Fig 10. Capital Project Governance Process ....................................................................................................... 76
Fig 11. Capital Project Governance Lifecycle ...................................................................................................... 77
Fig 12. Cross-reference of CPGP, Primecore and CWMF models ....................................................................... 78
Fig 13. Primecore Infrastructure Project Life Cycle ............................................................................................ 79
Fig 14. Capital Works Management Framework (CWMF) and project lifecycle ................................................. 80
Fig 15. Definition: RAID ....................................................................................................................................... 81
th
PMO HANDBOOK
1 Introduction
1.1 Purpose of the College PMO Handbook
The purpose of the PMO Handbook is to record in one location the standards, processes and
controls relating to management of Capital Projects.
The Handbook introduces the College-wide PMO and presents the standard governance process, a
project lifecycle and related processes for Capital Project management, and clarifies how the
standards, processes and controls align the PMO with business roles, responsibilities and functions.
The PMO is currently implementing a College- wide project governance structure, a standard set of
project management processes (including approval and prioritisation and performance reporting)
and a common lifecycle for projects. It is coordinating the introduction of the Capital Project
Governance lifecycle and is planning provision of training in lifecycle and processes for Sponsors,
Governance groups and Project Managers.
1.2 Executive Summary

Following a review in 2011, Board approved the introduction of a College-wide Programme
Management Office (PMO) to improve formality and discipline around processes for projects. The
PMO is a centralised, co-ordinating unit that provides a focal point for project management within
College. A key function of this office is to develop and implement a more structured and strategic
approach to selecting and prioritising College Capital programmes and projects. This will support
greater efficiency within College and ensure that increased transparency is achieved around Capital
Projects.
A project is defined as a temporary activity designed to produce a unique product, service or result
with a defined beginning and end (usually time-constrained, and often constrained by funding or
deliverables), undertaken to meet unique goals and objectives, typically to bring about beneficial
change or added value. The temporary nature of projects stands in contrast with business as usual
(or operations), which are repetitive, permanent, or semi-permanent functional activities to produce
products or services.
A capital project is defined as being any undertaking which requires the use of notable amounts of
capital, both financial and labour, to undertake and complete.
Within TCD, a project is classified as capital if total expenditure on the project exceeds €50,000
including VAT.
A capital project helps maintain or improve a College asset, often called infrastructure. It can be a
new build, acquisition of land or property, lease of property, the refurbishment of an existing
building or the purchase of a new piece of equipment. It can be new Information Technology
software / equipment purchase, development, enhancement or replacement, or an Organisational
Change Management program.
Project costs can include the cost of Information Technology, Professional Services, Software
purchase/ Development / Licensing, Internal & External Resource costs, Architectural planning,
Engineering, and contract services needed to complete the project.
th
PMO HANDBOOK
The purpose of the PMO is to support College/senior management in a variety of ways which
include:
1. Provision of a consistent approach to project approval, prioritisation and delivery;
2. Developing and managing Capital Project processes and standards, including project
management templates and processes;
3. Establishing an organisational focus on improvements
4. Consolidating and co-ordinating regular standardised reporting of the project portfolio
to the Board, EOG and the CRG (Capital Review Group described in detail below);
5. Establishing and managing the College Project Portfolio;
6. Provision of portfolio level status and performance reporting;
7. Establishing an organisational focus on improvements in project management
competency.
In June 2013, Board approved that Capital Projects meeting certain criteria would report through the
College-wide PMO. Business Cases for proposed projects will be assessed on the basis of:
 Severity of the problem and the impact of the project over the next 5-15 years;
 Quality of project planning (including risk analysis);
 Level of innovation and synergies in proposed solution;
 Benefit of the proposed solution compared to alternatives;
 Fit with current College strategic plans and initiatives;
 Cost Benefit Analysis.
1.3 Scope of the PMO

The scope of the PMO is for Capital Projects with a minimum value of €500k. The remainder of
Capital Projects (€50k – €500k) will be supported by local Project Offices and their operational areas
following the standards set by the PMO. Where local POs do not exist, the College PMO will provide
support as required.
Two principle information flows operate within the PMO – Approval & Prioritisation and Reporting
as shown below. Detailed process descriptions are provided later in the Handbook.
CRG filters/ Sponsor

Sponsor gets If > €3m,
Sponsor recommends presents Finance
approval EOG
presents project to EOG recommended Committee Board reviews
regarding recommends
proposal/ proposal reviews and and
space to Finance
business (if cost < €150k, to EOG passes to approves/
allocation Committee
case to CRG CRG may (if cost <€3m, Board for rejects
from SAC EOG informs
via PMO approve) EOG may approval
(if required) Estates, LIPC
approve)
Fig 1. APPROVAL & PRIORITISATION HIGH-LEVEL INFORMATION FLOW
Project PMO provides CRG meets to CRG informs

CRG provides CRG/EOG
Manager summary consider other
update to EOG and provides Project
reports status Project Portfolio progress of committees of
Finance Portfolio update
to PMO Pack to CRG project portfolio portfolio status
(monthly) to Board
(monthly) (monthly) (monthly) (as appropriate)
(quarterly)
th
PMO HANDBOOK
Fig 2. PERFORMANCE REPORTING HIGH-LEVEL INFORMATION FLOW
There are a number of significant benefits anticipated from the PMO and the processes being
implemented:
 Improved definition of project Business Cases so that College resources and funds are
committed to the areas of highest priority and return for the College and better alignment of
the Business Case with deliverables;
 Assistance with identification of resource requirements, particularly in critical front end
project stages;
 Clearer decision making processes and, consequently, timely decision making during the
lifecycle of each project leading to better control of timescale and budget;
 Better identification of the necessary organisational change activities needed so that
projects provide the required return on effort and investment;
 Improved management of risks associated with programmes and projects;
 Improved verification of timelines and budget for planned projects through standard
reporting processes;
 Development of an improved project management culture, formal change controls and risk
management strategies;
 Standardised reporting and monitoring leading to improved management information and
support of College strategy;
 Better coordination between projects;
 Improved visibility of project performance, capital spend, project costs, benefits and key
resource impacts; greater control of costs and risks;
 Improved project approval and prioritisation process;
 Improved College project delivery, higher levels of skill among project managers from use of
a common approach and ongoing competency training;
 Standardisation of the College Capital Project Governance .
Sponsors may request advisory support from the PMO in completing the documentation outlined
within the governance process, or to provide advice on how best to progress through the Capital
Project Governance Process.
In summary, the PMO has responsibility for establishing the management processes for projects
reporting through it and will incorporate a set of defined policies, procedures, templates,
management processes, tools, and services.
th
PMO HANDBOOK
1.4 Project Risk Indicator (PRI)

The College has a large number of Capital projects running at any time. These vary in size, cost,
resource usage and timelines. The Project Risk Indicator provides a high level overview of the level
and type of risk with each project. A standard approach has been defined which scores projects
based on their key risk indicators.
Projects are assigned a Project Risk Indicator (PRI) of Low, Medium or High. The PRI matrix is
completed initially during the Approval and Prioritisation Stage during the development of the
Business Case, and is subsequently recalculated at Stage Gate Reviews and during the Change
Request process. The use of the PRI will be further developed as the Capital Projects Governance
Process is embedded.
The table below outlines the criteria considered and their relative grading providing the project risk
indicator. The higher the PRI score, the higher the perceived risk for the project.
Project Risk Indicator Very Low Low Medium High Very High Score
(1) (2) (3) (4) (5)
Team size <3 3-7 8-12 12-17 >17
# of cross functional areas 1 2-5 6-9 10-12 >13

involved
Estimated Duration <4 4-11 12-18 19-24 >24
(Elapsed Months)
Technology and / or In house expertise Very Familiar Somewhat New to TCD New to industry/
Business Process – Known available Familiar Leading edge
or New
Complexity of solution Well defined. Known and Known but some More than one Solution unknown
some minor medium / major approach or vaguely
No problems problems problems available defined
expected expected expected
Dependency on external Long standing Reasonable Used before, but Used before, No previous
suppliers / organisations relationship relationship not regularly but not recently relationship
Risk to Reputation Reputational risk Reputational Reputational risks Reputational Reputational risks
unlikely to happen, risks are likely as not to risks are likely certain to occur,
with negligible occasionally occur, with to occur, with which threatens
impact occur, with notable impact to substantial reputation of
minor impact to reputation impact to project or TCD
reputation reputation if
they do
TCD Resource Impact In house skills In house skills In house skills Up skilling In house and
present and project present with present but the required, external
is easily absorbed some project will impact resources will resources
within current occasional current workloads have to be dedicated to
workload impact on and require dedicated to the project and from
current backfill project more than one
workloads department
Funding/Finance Funding exists with Most funding in Funding not in Funding Funding will be
current budgets place or place. sources not difficult, funding
requires minor clear, will complexity mix
budgetary Project will impact impact TCD high and possibly
allocation departmental budgets not attainable
budgets
Project Scoring:
Low < 19 Total:
Medium 19 – 31
High > 32
Fig 3. PROJECT RISK INDICATOR
th
PMO HANDBOOK
2 Capital Project Governance

The following sections provide a high level overview of the governance approach to be followed by
all College Capital Projects. The approach breaks the overall project life-cycle into different stages
and provides details of the processes and documentation that will be required during each stage.
The approach will be further enhanced as its rollout progresses throughout the College.
The Project Sponsor/Project Manager may request assistance from the College PMO to support
them in completing the documentation outlined, or to provide advice on how best to progress
through the project stages.
The lifecycle described here views the project as a series of sequential project stages, separated by
“Gates” where formal reviews take place determining the continued funding and approval of the
project.
The standard Capital Projects lifecycle is designed to be scalable for different project types and levels
of complexity. It is intended to be used for all Capital Project types including construction,
information systems and business change. All project types will follow the generic stages but may
have specific sub-stages relevant to their own domain.
Gates are decision points in a programme’s or project’s lifecycle where Governance (Steering, CRG,
EOG, Board) asks key questions to help ensure that the project is still feasible. These Gates or
decision points also align to the incremental investment approach of the project. On approval,
Governance will approve the funding required for a project to reach the next Stage Gate.
Project stages are normally executed sequentially to ensure minimal project cost. Specific factors,
however, may require accelerated delivery of a project (e.g. an external risk to College may
outweigh the project cost or schedule overrun risks) and in this case the lower risk approach would
be to speed up the project by overlapping some stages. In the case of expedited project plans a full
risk assessment and cost benefit analysis case for non-sequential stages will be made and approved
by the Project’s Steering Committee.
The standard Stages within the Capital Project lifecycle are:
Approval and Prioritisation

Initiation and Strategic Planning
Detailed Planning and High Level Design
Detailed Design
Execution and Handover
Closeout
Post-Project
Fig 4. CAPITAL PROJECT STAGES
Each of the major Stages listed concludes with a Gate Review at which the project’s performance is
assessed against its Business Case. To be considered ready to move to the next lifecycle stage,
specific criteria within the Stage Gate Approval Pack and other key supporting documents must be
met. These provide control of milestone completion and confirm that required tasks and steps have
been satisfactorily completed, and that required deliverables have been completed, reviewed, and
have received signoff.
Throughout the lifecycle, if any changes are identified that will alter the Business Case (project
scope, timeline, resource effort or costs/benefits) previously approved, the Sponsor and Project
Manager will initiate a Change Request for submission into the Change Request process, for review
th
PMO HANDBOOK
by the appropriate governance level before being confirmed as accepted by the project for delivery
(see relevant section later in document for process details).
The rationale for the Capital Project Governance lifecycle and its context are summarised in the
Appendices.
th
PMO HANDBOOK
2.1 Project Approval & Prioritisation

The primary owner for the process is the Project Sponsor.
This process is used when initial project approval and prioritisation is sought from the CRG.
All projects with a capital spend greater in value than €50k must be submitted to CRG for approval
whether funding is being sought or not. Capital projects with a smaller spend may be requested to
go for approval to CRG if there risk profile warrants it.
All projects must be submitted for approval and prioritisation by CRG before being confirmed as a
project for delivery.
 CRG may approve projects with capital spend up to €150k.
 EOG may approve projects with a capital spend up to €3m.
 Board may approve projects with a capital spend greater than €3m.
 Approval for projects with a capital spend of €500k or greater will be managed via the PMO.
The Sponsor provides a standard set of project information to the PMO in order to support the
submission of their new project into this process. This set of information is considered to be the
minimum required by the CRG to support their project approval and prioritisation decision making
process. The information is provided to the PMO using standard, pre-defined templates.
The templates / documents to be used by the Sponsor are:
 Business Case pack (PASS 2)
o Business Case
o Financial Plan
o Business Case Summary
o Change Request PRI Log
Additional templates / documents used by PMO during the process are:
 Project Portfolio Approval & Prioritisation pack
o Project Portfolio Roadmap
o Project Portfolio Impact Assessment
At the end of this stage, the proposed project is submitted to CRG for review and recommendation
(see later section for Approval & Prioritisation process details.)
Principle deliverables
 Business Case pack

o Business Case
o Financial Plan
o Business Case Summary
Processes used include

Approval & Prioritisation
th
PMO HANDBOOK
2.2 Initiation and Strategic Planning

This Stage initiates or kicks off the project following approval.
The primary owner for the Stage deliverables is the Sponsor until the Project Manager is identified
and assigned. Once assigned, the Sponsor transfers day to day responsibility for project deliverables
to the Project Manager. The Sponsor and Project Manager work together to select the project team
members and agreement is reached to release team members to work on project activities. The
Project Manager and Sponsor also define project controls, governance, and the communications
approach. The complete internal governance structure for the project will be put in place during this
Stage.
Communications take place with the key stakeholders and team members about project objectives,
goals, timelines, deliverables, standards, controls, etc. The individual/specific roles and
responsibilities for the duration of the project are agreed.
Regular project status reporting to the PMO begins following the standard Project Performance
Reporting process (see relevant section later in document for process details).
Principle inputs for this Stage
 All previously approved project management and project deliverables.
 Decision from Approval and Prioritisation process including approved project timeline,
budget, resources
Principle deliverables for this Stage
At the end of this Stage, the following key deliverables are submitted for approval by Steering and
other appropriate authorities and approval is sought to progress.
 Project Initiation Document (PID)
 Delivery Plan (High Level) (TBC)
 Updated Financial Plan
 RAID Log
 Change Request PRI Log
 Mobilised team
Additional Construction Specific (CWMF) deliverables (confirm approval for design expenditure)
 Final output specification
 Definitive project brief
 Risk management plan
Processes used
 Project Portfolio Performance Reporting process
 RAID review management process
 Recruitment, if required
 Procurement, if required
 Change Request management process, if required
 Project Stage Gate approval process
th
PMO HANDBOOK
2.3 Detailed Planning and High Level Design

The primary owner for the deliverables in this Stage is the Project Manager.
During this Stage the Project Manager, Sponsor and team develop detailed project plans and
schedules to support the delivery of the project. The Detailed Project Delivery Plan, Financial Plan
are developed to which the team’s and key stakeholders’ buy-in is gained.
A design team is appointed and business user requirements are documented. Design of the business
solution is developed and approved based on the approved Business Case.
The project schedule, cost plan and risk log (RAID) are updated and a procurement strategy
developed if required.
This is the earliest point at which EOG/Board may approve full funding for the project.
 Delivery Plan (Detailed) with updated Financial Plan
 Business Requirements
 High Level Design
Construction Specific (CWMF) deliverables (confirm requirements, review procurement strategy,
assess project design and Outline Cost Plan)
 Outline sketch scheme (Building)
 Preliminary planning drawings (Civil Engineering)
Processes used
 Project portfolio performance reporting process
th
PMO HANDBOOK
2.4 Detailed Design

The primary owner for the Stage deliverables is the Project Manager. During this Stage the Project
Manager, Sponsor and team develop detailed designs to support the delivery of the project.

 Updated Delivery Plan (Detailed) with updated Financial Plan
 Functional Specification (if required for the project)
Construction Specific (CWMF) deliverables (assess project prior to and assess outcome from
statutory approval)
 Developed Sketch Scheme
 Statutory Approval Submission

th
PMO HANDBOOK
2.5 Execution and Handover

The project now enters its Execution and Handover Stage where the technical deliverables of the
project will be produced and handed over for operational use. The primary owner for the project
deliverables is the Project Manager. This Stage may be carried out in-house or via contractors and
recruitment and/or contracts may be required (College Resourcing and Procurement processes).
This Stage, depending on the category of project being carried out, will include such sub-stages as
Tendering, Development, Training, Testing and Handover. The Delivery Plan will be updated with any
new details and a testing and handover schedule agreed. The project management team plan and
deliver required training as necessary. The Delivery Plan and all component parts are updated
accordingly.

 Updated Delivery Plan (Detailed) with updated Financial Plan
 All planned project deliverables (tender, execution, testing, handover/implementation)
including
o Test plans, tested, signed off delivered project products, training plans
o Handover and implementation schedule (in Delivery Plan)
Construction Specific (CWMF) deliverables (approve detailed design solution, review pre-tender
cost check, review risk, all tender related documents, review tender returns in advance of
awarding the contract).Detailed pre-tender cost check
 Whole life cost update
 Contractor list selection
 Tender assessment criteria
 Tender analysis and report
 Contractor recommendation

 Change Request management process
A Stage Gate review will be held at the end of the tendering sub-stage.
Reviews will be carried out by Steering at the end of the Execution and Testing sub-stages and a
Stage Gate review will be held at the end of the complete Stage (Gate Review 5).
th
PMO HANDBOOK
2.6 Closeout
The primary owner for the Stage deliverables is the Project Manager. In this Stage, a lessons learned
exercise is performed where all stakeholders are encouraged to provide constructive feedback on
how the project operated throughout its lifecycle – what worked well, and what might be done
differently if the project were to be executed again.
The project logistics initiated in the earlier stages of the project are shut down. The project team
ensures that all key project documents are available in the project folders, with unwanted versions
of deliverables removed or archived.
A Project Closure Report (TBC) is prepared by the Sponsor and Project Manager based on the
approved Business Case and any subsequent approved change requests. This summarises the state
of project delivery – what the project has delivered and what it has not. It highlights any key
deliverables not delivered and any key critical success factors not achieved. It details the project
performance against the approved baselines in the areas of scope, timeline, effort, financial, and
quality. Lessons learned are included in this document.
Project management documents are finalised including the Decision and RAID Logs. Team resources
are officially released from the project.
If a Post-implementation benefits review was agreed during earlier phases of the project, specific
requirements and the scope of this review are reconfirmed and a provisional timeline to execute it is
agreed. This will include details on when the review will be performed, who will own, deliver and
drive the review, and who the key resources will be to perform the review.

 Updated Delivery Plan with updated Financial Plan
 Project finances closed off
 Handover and implementation schedule
 Project Closure Report (TBC)
 Delivered, tested products, signoffs
th
PMO HANDBOOK
2.7 Post Project

During Closeout, the specific requirements and scope of the Post Implementation Benefits Review
(CWMF: Project Outturn Review) is confirmed and a provisional timeline to execute it is agreed.
The Sponsor plans for the required review by confirming:
 Scope of the review – what is in and out of scope
 Key deliverables from Review
 Resources required to perform the Review
 Timeline for performing the Review
The Sponsor may find it useful and/or necessary to use the standard project management planning
tools and templates to plan the review, but this is not mandatory and is dependent on the scale of
the review.
The Sponsor will manage the post-project review, and is responsible for the production of the Post
Implementation Benefits Review (TBC).
The document, or a summary of the key findings, will be provided to PMO to be included in regular
project portfolio reporting to appropriate levels of governance.
th
PMO HANDBOOK
3 Key Capital Project Governance Processes

All PM Framework templates can be found on TCD Projects shared drive at the following location:
https://www.tcd.ie/local/pmo/
3.1 Project ID Request process

The primary owner for the process is the Project Sponsor.
Step 1. The Project Sponsor requests a unique project ID from the PMO by sending an email to
PMO. The email should contains basic information on the project such as:
 Project Short Name
 Brief description of project
 Project Objectives
 EOG Champion
 Project Sponsor
 Proposed start / end dates, if available
Step 2. PMO confirms that all information required to support the allocation of a new project ID to
the request is available on the email.
Step 3. PMO then updates the Project ID Request Register with the details provided, and allocates
the next sequential ID from the register to the project.
The template / document to be used by the Project Sponsor is:-

 An email to PMO to request a Project ID
Additional templates / documents used by PMO during the process are:-

 Project Portfolio Summary Register Log
th
PMO HANDBOOK
3.2 Project Approval and Prioritisation process

In the longer term this is planned as an annual process which will be managed in two pass phases
with exceptions being handled as appropriate throughout the year. The primary owner for the
process is the Sponsor. This process is used when project approval and prioritisation is sought.
Approval and prioritisation is executed in two passes:
 PASS 1 is designed to filter proposals thus creating a shortlist of potential projects for
further focus on potential approval and prioritisation. Shortlisted projects will each be
required to develop a detailed Business Case in order to be considered in Pass 2.
 PASS 2 is designed to assess full Business Cases and their detailed Financial Plans, to
challenge the purpose and objectives of shortlisted projects, validate them against the
existing College project portfolio and approve or reject projects.
All projects with a capital spend greater in value than €50k must be submitted to CRG via PMO for
approval whether funding is being sought or not.
All projects must be submitted for approval and prioritisation by CRG before being confirmed as a
project for delivery.
 CRG may approve projects with capital spend up to €150k.
 EOG may approve projects with a capital spend up to €3m.
 Board may approve projects with a capital spend greater than €3m.
The Sponsor provides a standard set of project information to the PMO in order to support the
submission of their new project into this process. This set of information is considered to be the
minimum required by the CRG to support their project approval and prioritisation decision making
process. The information is provided to the PMO using standard, pre-defined templates.
The templates / documents to be used by the Sponsor are:
 Business Case pack (PASS 2)
o Business Case
o Financial Plan
o Approval Prioritisation Proposal pack
 Project Portfolio Approval & Prioritisation pack
 Project Portfolio Roadmap
At the end of this stage, the proposed project is submitted to CRG for review and recommendation
(see later section for Approval & Prioritisation process details.)
Principle deliverables
 Approval & Prioritisation Proposal pack
 Business Case pack
o Business Case
o Financial Plan
 Approval & Prioritisation
th
PMO HANDBOOK
3.2.1 Business Case pack preparation

The development of these documents is mandatory.
The Project Sponsor prepares the required documents (listed below) for submission for Approval &
Prioritisation to the CRG.
The Project Sponsor should obtain approval from the responsible EOG Champion and Dean/Chief
Officer before submitting into the CRG. The Project Sponsor must ensure that the proposed project
is aligned with TCD Strategy.
The Project Sponsor requests a unique project number from the PMO at this point by requesting one
via email basic information on the project i.e.
 short name
 project short description
 project objectives
 names of the Project Sponsor and the EOG Champion
 Proposed start / end date if available
PMO follows the Project ID Request process and provides a unique project number to the Project
Sponsor. This unique ID will be included in the appropriate location in all project documents. Please
refer to the Project ID Request process in this document for further detail on the process.
The Project Sponsor submits the required documents (listed below) to PMO for inclusion in CRG
submissions via the Project Approval & Prioritisation process.
The Financial Plan template allows contingency for all budgeted project costs and resource man-
days. The % contingency allocated is variable and can be set to any % based on the perceived risk of
project estimates. This is agreed during the Pre-Project Approval stage, and monitored throughout
the project lifecycle.
PMO will collate the information provided with any other requests received, and submit to the CRG
for their review, consideration and decision.
The templates / documents to be used by the Project Sponsor for submission to the CRG are:-
 Business Case Summary
 Business Case
 Financial Plan
 Change Request PRI Log
3.2.2 PASS 1 – Filter and Create Potential Project Shortlist
3.2.2.1 Preparation of project Business Case for approval & prioritisation
Step 1. Annually, a communication will be issued by CRG indicating the timeline for
submissions.
Step 2. The Sponsor completes the required templates. In summary, the required process
information will include:
 Background (problem to be resolved) and objectives
 Scope (both in and out)
 Constraints, assumptions, risks and dependencies, interfaces
 Options (with pros and cons) and recommended programme/project option.
 High level schedule
 Estimated costs (project and ongoing operational)
 Estimated benefits (both quantifiable and non-quantifiable)
th
PMO HANDBOOK
 Key resources required, milestones

 A project risk indicator is decided and financial and time estimates are provided
 If funding is required for Business Case preparation, this should be requested as
part of this process and included in the pack.
Step 3. If space allocation is a requirement of the project, the Sponsor will get approval on
space from the Space Allocation Sub-Committee (SASC) in advance of submission.
Step 4. Dean/Chief Officer signs off on Business Case Summary (the Proposal) before
submission to CRG via PMO.
Step 5. PMO receives a request from the Sponsor to include the Proposal in the schedule of
CRG Project Portfolio Approval and Prioritisation meeting and provides all required
documents.
Step 6. PMO confirms that the Proposal provided is complete. If further details are required,
these are requested and received from the Sponsor.
Step 7. PMO updates the Project Portfolio Summary Register Log with any previously
unavailable project information.
3.2.2.2 CRG Project Portfolio Approval & Prioritisation Meeting(s) – Preparation
NOTE: A number of meetings may be held to facilitate volume of submissions.

Step 8. PMO collates all individual new Proposals into the Project Portfolio Approval &
Prioritisation pack to be provided to CRG.
Step 9. PMO creates a high level Project Portfolio Impact Assessment and includes this in pack.
Step 10. PMO issues the Project Portfolio Approval & Prioritisation pack to CRG members three
days in advance of the meeting for their review and consideration.
Step 11. CRG members review and consider the details of project proposals and raise any
queries or requests for additional information either directly to the Sponsor or via PMO
in advance of the meeting.
3.2.2.3 CRG Project Portfolio Approval & Prioritisation Meeting(s)

Step 12. The CRG Project Portfolio Approval & Prioritisation meeting is held following the
published schedule.
Step 13. Sponsor presents their proposed project(s) at CRG. A decision on recommendation to
proceed to the next stage is made. Possible CRG decisions are:
 Progress to next stage of approval & prioritisation (PASS 2 – see below)
 Rejected (with reason)
 Further Information requested (with specifics)
 Project put on Hold or Deferred (with reason)
Step 14. CRG decisions are communicated:

 Sponsor communicates decisions to Dean/Chief Officer, and key stakeholders,
departments as appropriate.
th
PMO HANDBOOK
 Sponsor communicates to EOG/Board/Committees on actions and

recommendations for individual project proposal
 Detailed actions and recommendations of CRG are communicated via minutes of
CRG to EOG and committees.
3.2.2.4 PMO processing of CRG decisions

Step 15. PMO updates
 Project Portfolio Summary Register log as appropriate.
 Project Portfolio Roadmap as appropriate in advance of the next meeting.
Step 16. PMO provides the updated Project Portfolio Roadmap and impacts of CRG decisions to
CRG.
3.2.3 PASS 2 – Assess Business Case and Supporting Documents

3.2.3.1 Preparation of Business Case for approval & prioritisation
Step 1. Sponsor prepares Business Case pack using the standard templates.
Step 2. PMO receives request from the Sponsor to include the proposed project in the schedule
of CRG Project Portfolio Approval & Prioritisation meetings and provides all required
documents.
Step 3. PMO confirms that the Business Case pack is complete. If further details are required,
these are requested and received from the Sponsor.
Step 4. PMO updates the Project Portfolio Summary Register Log with any previously
unavailable project information.
3.2.3.2 CRG Project Portfolio Approval & Prioritisation Meeting - preparation

Step 5. PMO collates all individual Proposals/Business Cases into the Project Portfolio
Approval & Prioritisation pack to be provided to CRG.
Step 6. PMO prepares a Project Portfolio Impact Assessment and includes in the pack for
submission to CRG at their scheduled meeting.
Step 7. PMO issues the Project Portfolio Approval & Prioritisation pack to CRG members three
days in advance of the meeting for their review and consideration.
Step 8. CRG members review and consider the projects submitted and raise any queries or
requests for additional information directly to the Sponsor or via PMO.
Step 9. All projects go to FSD to vet finances.
3.2.3.3 CRG Project Portfolio Approval & Prioritisation Meeting(s)

Step 10. CRG Project Portfolio Approval & Prioritisation meeting is held following the published
schedule.
th
PMO HANDBOOK
Sponsor presents each project for approval/prioritisation and a decision is made for
each submission. All potential impacts are considered in this process. Potential CRG
decisions are:
 Recommendation for approval (to EOG/Board)
 Rejected (with reason)
 Further Information requested (with specifics)
 Project Put on Hold or Deferred (with reason)
3.2.3.4 Processing of CRG decisions/Recommendations

Step 11. PMO updates:
 Project Portfolio Summary Register log as appropriate.
 Project Portfolio Roadmap as appropriate in advance of the next meeting.
Step 12. PMO provides an updated Project Portfolio Roadmap and impacts of CRG decisions to
CRG.
Step 13. CRG processes decisions/recommendations to EOG/Board as required via CRG minutes.
th
PMO HANDBOOK
3.3 Project Portfolio Performance Reporting Process

The primary owner for the process is the PMO.
The purpose of this process is to create monthly project portfolio performance reporting for
submission to the CRG.
Project Status Reports from all relevant Project Managers will be created as of the last working day
of each month, and submitted to the PMO within three working days of end month.
Any change requests to be considered for review at the CRG meeting will be included with the
current status reports.
The PMO will create the consolidated Project Portfolio Performance Reporting pack and issue to the
CRG a minimum of three working days in advance of scheduled CRG meeting.
The templates / documents to be used by the Project Manager are:
 Project Status Report
 Change Request Presentation and Forms
Additional templates / documents / processes used by PMO during this process are:
 Project Portfolio Performance Reporting pack
 Project Portfolio Summary Register Log
3.3.1 Preparation of Status Report by Project Manager
Step 1. PMO provides a reminder of the upcoming reporting due date at each calendar month
end.
Step 2. Project Manager completes the required Project Status Report pack and reviews with
Sponsor in advance of submitting to PMO.
Step 3. Project Status Report received by PMO from all Project Managers by due date.
Step 4. PMO crosschecks the Project Portfolio Summary Register Log, and confirm which, if
any, projects have not provided submissions.
Step 5. PMO contacts relevant Project Managers who have not delivered the pack, requesting
reason for delay and expected delivery date.
3.3.2 Collation of status information and issuance to CRG by PMO
Step 6. CRG Project Portfolio Performance Reporting pack created by PMO by

 collating Project Status Report packs received from the Project Managers
 collating Change Requests raised to be included in the Project Portfolio Performance
Reporting pack
 developing and including the Project Portfolio Performance Reporting report
Step 7. Full Project Portfolio Performance Reporting pack issued by PMO to all CRG members
three working days in advance of the CRG meeting for review and consideration.
th
PMO HANDBOOK
Step 8. CRG member reviews and considers / prepares for the Project Portfolio Performance
meeting. The CRG member raises any queries or requests for additional information
directly to the Sponsor or via PMO in advance of the meeting.
Step 9. Project Portfolio Summary Register Log is updated by PMO with the following
information received from the Project Manager:
 Overall project status
 Schedule current status
 Financial current status
 Effort current status
3.3.3 CRG Project Portfolio Performance meeting
Step 10. CRG Project Portfolio Performance meeting is held. Status of each project is reviewed,
performance deviations highlighted, and required corrective actions challenged if
appropriate and/or required.
Step 11. Key project portfolio Risks, Assumptions, Issues and Dependencies and current impacts
are reviewed.
Step 12. Decisions on submitted Change Requests are sought and received from the CRG at this
meeting.
Step 13. CRG recommendations are communicated to EOG/Board and the wider community (as
appropriate) by the CRG Chair (supported by PMO).
th
PMO HANDBOOK
3.4 Project Stage Gate Approval Process

The primary owner of the process is the Sponsor.
The purpose of this process is to seek approval or request for the continuation of the project
through the Capital Project Governance process.
The decision on Stage Gate Approval is provided by the required Governance authority
(Steering/CRG/EOG/Board) depending on € value of project.
The Project Manager is responsible for collating all required documentation for preparation of the
Stage Gate Approval presentation Pack which serves as a basis for Governance authority’s decision.
The Project Stage Gate Approval Process provides an opportunity for a formal review and decision
to point to:-
 review actual project performance against plan
 consider any changes to the environment in which the project is operating which may impact
the project delivery (positively or negatively)
 review estimated benefits to confirm they are still on target to be delivered
 review / challenge the project approach taken so far in the project
 identify / agree any corrective action required to keep the project on track
 review any changes (if any) to the approved project scope, timeline, financials and resourcing
…before making a decision if College will commit to closing the current stage and commencing the
next stage.
It ensures the agreed level of approval for the project, and is a checkpoint for the control of College
resources (€, resources, technology).
The templates / supporting documents to be used by the Project Manager are:

 Stage Gate Approval Presentation pack
 Financial Plan
 Project Roadmap
 Delivery Plan
 Specific deliverables for current stage
 Project Status Report (latest)
 Risks, Assumptions, Issues, Dependencies log
 Project Risk Indicator Log
 Change Requests, if appropriate
3.4.1 Stage Gate Approval steps
Step 1. Sponsor signs off project to request Stage Gate Approval and requests Project Manager to
collate all required documentation.
Step 2. Project Manager collates all required documentation for the Stage Gate Approval Pack.
Step 3. Steering is presented with the Stage Gate Approval pack and a decision whether to proceed
to Stage Gate Approval is made.
Step 4. If Steering decides to proceed to Stage Gate Approval, the Sponsor submits the Stage Gate
Approval request to CRG.
th
PMO HANDBOOK
Step 5. If Steering decides not to proceed to Stage Gate Approval,

a. Reasons for the decision and / or required corrective actions are agreed with the
Sponsor.
b. Sponsor, supported by the Project Manager, completes the agreed corrective
actions
c. Sponsor reinitiates the process.
Governance authority to progress

Step 6. CRG reviews the Stage Gate Approval request as presented by Sponsor.
Step 7. If the request is approved by CRG,
a. The Stage Gate Approval progresses through the governance process until the
appropriate level of approval for the project is received from the required
Governance authority (CRG/EOG/Board).
b. When the final approval is provided, the decision is communicated to Sponsor by
the CRG (via PMO).
c. The project proceeds as per Stage Gate Approval request.
Step 8. If the request is not approved by CRG,
a. Reasons for the decision and / or required corrective actions will be communicated
to Sponsor.
b. Sponsor, supported by the Project Manager and Steering Committee members,
complete the agreed corrective actions
c. Sponsor reinitiates the process.
th
PMO HANDBOOK
3.5 Change Request (CR) management process
3.5.1 Background
The primary owner for the process is the Project Manager/Project Sponsor. Changes during the
course of a project are inevitable and can affect the project scope, cost, deliverables, delivery
timeline, and benefits. The Change Request (CR) management process is a systematic approach that
allows for change while minimising the negative consequences of those changes. The CR
management process is used when a change has been identified that requires approval to vary the
approved project baseline.
This is the only process for varying the project baseline and a CR Approval form is used to record the
change description, benefits, request options, costs and details of impact.
A CR may be initiated by anyone involved in the project. For example:
 College may originate a CR because the environment, needs, or goals have changed since
the project started
 The project team may identify issues during design/implementation. As knowledge of the
solution increases, aspects of the original design may no longer be suitable or optimal
 A non-compliance issue may need corrective action.
After completion of the CR Approval form, the Project Sponsor must approve the request to proceed
for evaluation. If the impact of the change falls within the approved project baseline, accountability
for approving the CR will remain with the Sponsor. If the impact of the change falls outside of the
approved project baseline, then the CR and its impacts will be submitted by the Sponsor to the
Steering Committee for approval and then on to the Appropriate Authority based on the current
project approval levels (e.g. CRG/EOG/Board) using the Change Request presentation template.
3.5.2 Recording information about the requested change

Raised CRs will be recorded and their status maintained by the Project Manager in the Change
Request PRI Log. CRs which fall outside of the project baseline are reported to the PMO in the
monthly Project Status Report template.
The information provided by the Project Manager to the project’s Sponsor, Steering Committee
and, in turn via PMO, to the Appropriate Authority, includes:
 CR Approval form (see tab in Change Request PRI Log)
 Change Request Presentation template
 Additional documents to support the CR as required.
Additional documents used by the Project Manager and Sponsor during the process include:
 Change Request Log (see tab in Change Request PRI Log template)
 Project Risk Indicator (PRI) Log (see tab in Change Request PRI Log template)
 Business Case Pack (Business Case, Financial Plan, Project Delivery Plan and related trackers)

 Project Portfolio Summary Register Log
 The following diagram illustrates the CR management process.
th
PMO HANDBOOK
Raise CR, Submit to

Start Process
Project Manager
Review CR &
consider for
evaluation
Approve No
evaluation Close CR
exercise?
Yes
Escalate CR to
Within approved No Project Steering
baseline? Committee for
decision
Approve CR No
Yes Close CR
evaluation?
Yes
Escalate CR to CRG via

Approval & Prioritisation
process
Approve CR No
Evaluate CR Close CR
evaluation?
Request Approval
for Change
Yes
Approval for No
Close CR
change?
Yes
Escalate CR to
Within approved No Project Steering
baseline? Committee for
decision
Approve CR No
Yes Close CR
delivery?
Yes
Escalate CR to CRG via

Approval & Prioritisation
process
Incorporate CR & Yes Approve CR No

Close CR
Deliver delivery?
Fig 5. CHANGE REQUEST MANAGEMENT PROCESS FLOW
th
PMO HANDBOOK
3.5.3 Authority to Initiate Change Request

A change request can be initiated by any member of the project team, sponsor or key stakeholder,
but can only be approved for action by CRG/EOG or Board depending on the cost.
Step 1. Raise CR and submit to Project Manager

Requestor formally documents the change request using the Change Request Approval form
and submits to the Project Manager for review and management.
Step 2. Requestor may submit any additional information / documentation that support the CR and
the understanding of the requirement.
Step 3. Review Change Request
Project Manager receives the change request and logs the details in the Change Request PRI
Log.
Step 4. Project Manager reviews the change request, analyses the scope of the request, and agrees
with the Project Sponsor on the impact of evaluating the change request (if any). The
Project Manager may at this stage re-calculate the project’s Project Risk Indicator (PRI) score
based on the impact on the project of the change request being approved. The PRI is a
standardised approach to identifying the likely level of risk attached to a project. The PRI
matrix can be completed in Change Request PRI Log.
If the Project Sponsor does not accept the impact of evaluating the change request, the
change request will not be evaluated.
If the Project Sponsor accepts the impact of evaluating the change request (potential cost,
resource, time slippage or change in quality of deliverables), they will do one of two things:-
1. If the impact of the change falls within that approved project baseline for resource
effort, cost, benefit, and delivery schedule which was approved by the CRG when the
project was approved and prioritised, the accountability for approving the change
request evaluation will remain with the Project Sponsor.
The Project Sponsor works with the Project Manager to ensure that appropriate
resources are assigned to evaluate the change request.
The Project Manager / Project Sponsor inform the Project Steering Committee of the
change request in the next status report / at the next Steering Committee meeting.
2. If it falls outside the approved baseline, then the Project Sponsor escalates the change
request to the project Steering Committee for review and decision at the next Steering
Committee meeting.
The Steering Committee can make one of the following decisions:
 Reject the Change Request – the Steering Committee does not accept the impact of
evaluating the CR. The CR will not be evaluated.
 Approve the Change Request - the Steering Committee accepts the impact of
evaluating the CR and approves its escalation to the CRG for a decision (as it is
outside of their approval authority).
If approved for escalation by the Steering Committee to the CRG, the Project Sponsor
prepares the required documentation and submits a request for approval by the CRG via
th
PMO HANDBOOK
the Approval & Prioritisation process. Please refer to the relevant section in this
document for full details on this process. .
If the CRG does not accept the impact of evaluating the change request, the change request
will not be evaluated.
If the outcome of the CRG is the approval of the evaluation, the Project Sponsor works with
the Project Manager to ensure that appropriate resources are assigned to evaluate the
change request, and continue to progresses through the Change Request process.
If the request has been escalated to the CRG, the Project Manager provides details of the
change request and its status to the PMO. PMO update the Project Portfolio Change
Request Log.
At each stage of the process, the Project Manager updates the Requestor of the status of the
change request, and updates the Change Request PRI Log.
Step 5. Evaluate Proposed Change
Assigned resources evaluate the change request to determine the potential impact (cost,
resource effort, schedule & quality), risk, and complexity of the request.
Evaluation of the proposed change may involve the following actions:
 Evaluating the scope of the potential change to determine the project & business
impact
 Determining the effects the change may have on completed and planned
deliverables
 Identifying any modifications required to the project baseline and/or documents
 Estimating the resource effort and costs associated with completing the change and
determine the costs of not addressing the change
 Providing a recommendation on the priority of the change
Proposed change request may need to be communicated to the project team to determine
the full impact of the event. Depending on the urgency of the request, the changes may be
discussed during the regular weekly project team status meetings or at a special meeting.
Assigned resources complete the project change request impact details with their evaluation
findings and provide the completed information to the Project Manager.
Request Log.
Step 6. Request Approval for Change
The Project Manager reviews findings and presents recommendations for dealing with the
CR to the Project Sponsor.
The Project Sponsor makes a decision on the change request, which could be-
 Approved
 Rejected
 Further Information Requested
 On Hold / Deferred
th
PMO HANDBOOK
If the Project Sponsor does not accept the impact of implementing the change request, the
change request will not be implemented.
If the Project Sponsor accepts the impact of implementing the change request (potential
cost, resource, time slippage or change in quality of deliverables), they will do one of two
things:-
1. If the impact of the change falls within that approved project baseline for resource
effort, cost, benefit, and delivery schedule which was approved by the CRG when
the project was approved and prioritised, the accountability for approving the
change request implementation will remain with the Project Sponsor.
The Project Sponsor works with the Project Manager to ensure that appropriate
resources are assigned to deliver the change request.
2. If it falls outside the approved baseline, then the Project Sponsor escalates the
change request to the Project Steering Committee for review and decision at the
next Project Steering Committee meeting.
The Steering Committee can make one of the following decisions:
 Reject the Change Request – the Steering Committee does not accept the impact of
implementing the CR. The CR will not be implemented.
 Approve the Change Request – the Steering Committee accepts the impact of
implementing the CR and approves its escalation to the CRG for a decision (as it is
outside of their approval authority).
If approved for escalation by the Steering Committee to the CRG, the Project Sponsor /
Project Manager prepares the required documentation and submits a request for approval
by the CRG via the Approval & Prioritisation process. Please refer to the relevant section in
this document for full details on this process.
Request Log.
If the CRG does not approve the impact of implementing the change request, the change
request will not be implemented.
If the CRG approves the impact of implementing the change request, the Project Sponsor
works with the Project Manager to ensure that appropriate resources are assigned to deliver
the change request.
Step 7. Incorporate Change, Update Project Plans and documentation
If approval obtained, the Project Manager updates all impacted project management
documentation, including –
 Business Case Pack
 Business Case
 Financial Plan
 Change Request PRI Log
Step 8. Project Manager ensures updated documents are stored in the project directory.
Step 9. Project Manager schedules the change request requirements for delivery.
th
PMO HANDBOOK
Step 10. Project Manager updates the Change Request PRI Log with status as the change request
progresses to completion. This is to provide a permanent record of the change request
history.
th
PMO HANDBOOK
3.6 Project Financial and Resource Management Processes

The primary owner for the process is the Project Manager.
This section provides details of the project financial and resource management processes that will be
adhered to by the project. All project financials and resources will be managed and controlled by the
Project Manager through on-going tracking of approved actual and committed financials, and
resource effort utilised internal and external.
The Trinity system used is the Oracle Financials and Reporting.
The templates / documents to be used by the Project Manager include the following:-
 Project Status Report
 Financial Plan
 Oracle Financial reports, e.g., Capital Summary Report
3.6.1 Project Financial Management process
On a monthly basis at a minimum, the following activities are performed:-

 Project Manager reconciles the actual and committed Financials against the Approved
Baseline for the project and highlights any differences or anomalies that are identified.
 Project Manager resolves, where possible, any differences or anomalies that are identified.
Project Manager reports any unresolved differences or anomalies to the Project Sponsor.
 Project Manager and Project Sponsor agree corrective action to be executed
 Project Manager updates the monthly Project Status Report with the month end
actual/committed financials for Current Stage and Overall to Date highlighting deviations
from the approved budget and any corrective actions agreed. This is submitted per
governance to the PMO (or local PO for projects less than €500K) via the Project Portfolio
Performance Reporting process.
 If deviation from baseline continues, or corrective action is not sufficient, Project Manager
and Project Sponsor agree if a Change Request to alter the approved project budget is to be
submitted for consideration and approval by the Project Steering Committee(if appropriate)
and Trinity Governance (CRG/EOG/Board).
 If a Change Request is required, Project Manager and Project Sponsor create a Change
Request Pack and submit for approval via the Change Request process.
3.6.2 Project Resource Management process
On a monthly basis at a minimum, the following activities are performed:-

 Project Manager reconciles monthly man days expended for internal and external project
resources against Approved Baseline for the project and resolves any differences or
anomalies that are identified.
th
PMO HANDBOOK
 Project Manager resolves, where possible, any differences or anomalies that are identified.
Project Manager reports any unresolved differences or anomalies to the Project Sponsor.
 Project Manager and Project Sponsor agree corrective action to be executed
 Project Manager updates the monthly Project Status Report with the month end
actual/committed resource effort (Man-days) for Current Stage and Overall to Date
highlighting deviations from the approved budget and any corrective actions agreed. This is
submitted per governance to the PMO (or local PO for projects less than €500K) via the
Project Portfolio Performance Reporting process.
 If deviation from baseline continues, or corrective action is not sufficient, Project Manager
and Project Sponsor agree if a Change Request to alter the approved project budget is to
be submitted for consideration and approval by the Project Steering Committee (if
appropriate) and Trinity Governance (CRG/EOG/Board).
 If a change request is required, Project Manager and Project Sponsor create a Change
Request pack and submit for approval via the Change Request process.
th
PMO HANDBOOK
3.7 Risk, Assumption, Issue & Dependency (RAID) Review Management Process
The primary owner for the process is the Project Manager.
Anybody (or another project) directly or indirectly related with the delivery of the project may
identify / raise a risk, assumption, issue or dependency (RAID) item.
The Project Manager can either create the RAID item in the RAID Log, or delegate the creation of the
RAID item in the RAID Log to the individual who identified it or to one of the project team members.
Resolution of all items should be attempted by the individual / project that identified the item
before discussing with the relevant Project Manager.
The ownership of the RAID item remains with the person / project that identified it until that item
has been closed. The ownership is held, regardless of which individual or actions are involved in the
resolution or closure of the item.
The following section describes how the management of project RAID items will be implemented on
all TCD projects.
The management of RAID items is a key element of the project governance. Any deviations from
these governance requirements should be clearly documented and justified in the individual Project
Initiation Document.
The purpose of the RAID review management process is to identify, quantify and manage effectively
the risks, assumptions, issues & dependencies that could potentially have an adverse effect on the
project scope, timeline, cost, resourcing, quality or deliverables. The process entails completing a
number of actions to reduce the probability of occurrence and the potential impact on the project of
the item.
RAID review management takes into account all potential sources such as:
 Scope
 Timeline
 Cost
 Resource
 Quality
 Operational
 Business
 Technical
The process will ensure:

 Risks, Assumptions, Issues & Dependencies are identified, analysed, quantified,
documented, monitored and acted upon
 Effective team & wider stakeholder communication
 Consistent decision making regarding the management of RAID
 Clear roles and responsibilities with regard to managing RAID
 Efficient interface with Change Request and other processes
The objectives of the process are:-

 To minimise the chance of a risk eventuating or a dependency failing and, if it does,
minimise the impact on the project
 To find a resolution to an issue or to take action to minimise the impact of that issue on the
project.
th
PMO HANDBOOK
 To confirm if project assumptions made are true or false. If false, to minimise the risk to the
project by initiating appropriate mitigating actions to minimise the impact on the project
delivery
The templates / documents to be used by the Project Manager include the following:-
 RAID Log
 Change Request PRI log, if appropriate
 Change Request Approval, if appropriate
Additional templates / documents / processes used by PMO during this process are:-
 Project Portfolio RAID Log
3.7.1 RAID Item Ranking (Heat Map)

Ranking RAID items helps the project team prioritise limited resources and focus on the items with a
higher impact and probability (more risky items).
The overall ranking for each RAID item is determined using a Probability-Impact Matrix (or PIM,
shown in the diagram below), as extracted from the RAID log artefact. This assigns overall rankings
based on a combination of probability and impact scales.
RAID items with a very high probability and very high impact will receive more attention than those
with a lower probability of occurring or lower impact. This approach to ranking RAID items is similar
to that used for the ranking of business risks.
PROBABILITY (% age possibility of occurrence)

1 2 3 4 5
Rare Unlikely Possible Likely Almost certain
(0%-10%) (11%-34%) (35%-55%) (56%-80%) (81%-99%)
Insignificant -
unimportant impact. A
1 nuisance
Minor - slight or small

impact on the project.
Disruptive but does
2 not threaten
fundamentals
IMPACT OF RISK OCCURRING
Moderate -medium
impact to project time
3 cost and quality.
Major - Will have a

serious impact or
threat to project cost ,
4 time or quality and
may require significant
effort to mitigate
Critical - Will stop or

prevent the project
meeting its objectives.
5 Showstopper.
Fig 6. PROBABILITY-IMPACT MATRIX
th
PMO HANDBOOK
RAG Status Definitions
Red status indicates there is a live risk or issue on the project where remedial action is required to bring the
Red project back on track within the parameters set as the baseline. The remedial action has not yet been identified
and/or is not yet in progress. The risk or issue is not being addressed.
Amber status indicates there is a live risk or issue on the project; however remedial action(s) have been identified
Amber and/or are in progress to bring the project back on track within the parameters set as the baseline. The risk or
issue is being addressed.
Green Green status indicates there is no risk or issue and no action is required at this time. The project is on track to
deliver within the parameters set as the baseline.
Fig 7. RAG STATUS DEFINITIONS
3.8 RAID Definitions

A brief definition of a risk, assumption, issue and dependency is outlined below.
3.8.1 Risk
A Risk is a prediction of a significant negative event that might occur in the future, and which is likely
to adversely affect the ability of the project to achieve the defined objectives.
3.8.2 Assumption
An Assumption is a statement that is assumed to be true and from which a conclusion can be drawn.
Assumptions are made about the project variables e.g. timeline, scope, cost, resourcing, quality,
business / 3rd party support and interfaces, organisational delivery capability, etc., and form part of
the basis for the project delivery. Where an assumption turns out to be false, a CR may need to be
raised to control the impact to the project delivery.
3.8.3 Issue
An Issue is a matter that is currently impeding (or will impede) the progress of the project and about
which no agreement has yet been reached. The impact of an issue may cause delay, change the
direction, impair the solution, hinder the quality, alter the deliverable content or increase the cost.
3.8.4 Dependency
A Dependency is any event or deliverable that is required before a project activity can commence or
complete. There can be internal dependencies i.e. dependencies that are being managed /
controlled within the project, and external dependencies i.e. dependencies that require interaction
between other projects / business areas / organisations that do not form part of the project e.g.
External Architects’ availability.
th
PMO HANDBOOK
3.9 RAID Review Management process

Anybody (or another project) directly or indirectly related with the delivery of the project may
identify / raise a RAID item.
The Project Manager can either create the RAID item in the RAID Log, or delegate the creation of the
RAID item in the RAID Log to the individual who identified it or to one of the project team members.
Resolution of all items should be attempted by the individual / project that identified the item
before discussing with the relevant Project Manager.
The ownership of the RAID item remains with the person / project that identified it until that item
has been closed. The ownership is held, regardless of which individual or actions are involved in the
resolution or closure of the item.
Although the RAID Review Management process is primarily undertaken during the project
execution phases (i.e. during the Business Requirements, Design, Development, Testing, Training and
Implementation & Migration phases), RAID items may be identified at any stage of the project
lifecycle.
The RAID Log will be incorporated as an agenda item in the regular Project / Steering Committee
Meetings to support regular reviews by the relevant managers.
On a continuous basis the project team will review and discuss RAID items (both internal to the
project & with external projects / business areas / organisations) to avoid surprises, delays and cost
implications. In addition, this process alerts all parties involved to risk areas that may require
alternative solutions / actions.
th
PMO HANDBOOK
3.9.1 Risk Review Management process

The process is used to formally manage risks that may impact the ability of the project to deliver in
the future.
The process is undertaken to ensure that each risk identified within the project environment is
documented, monitored, reviewed, escalated, mitigated and communicated as appropriate.
The process involves performing a variety of reviews and activities which focus on confirming the
probability of the risk occurring, the impact on the project if it does occur, and developing mitigation
plans to minimise the potential risk to the project delivery. If the risk occurs, the mitigation plans
(which may involve the development of a change request for submission into the Change Request
process) will be invoked.
The Risk Review Management process is an iterative process and includes the following steps:
Step 1. Identification of project risks and logging to the project RAID Log
 Risk Originator (Project Manager / project team member / other project or organisation
resource) identifies a risk applicable to the project.
 Risk Originator attempts to resolve the risk. If this is successful, the risk is not logged and
the process completes.
 If the risk cannot be resolved, Risk Originator discusses the risk with the relevant Project
Manager.
 Risk Originator and Project Manager consider the risk and determine whether the risk is
applicable to the project.
 Project Manager may need to seek additional information from Risk Originator / project
team / others to verify the validity of the risk.
 If the risk is considered by the Project Manager to be relevant to the project, then a
formal risk is created in the project RAID Log. This may be created by the Project
Manager / Risk Originator / project team member as directed by the Project Manager.
 Project Manager assigns an initial priority to the item.
Based on the initial priority assigned, the following steps will be scheduled and executed.
Step 2. Assessment of the probability of occurrence and potential impact on the project timeline,
scope, cost, resourcing, quality, etc.
 Project Manager assigns a project team member to analyse the risk, and consider the
level of probability and impact to the project.
 Project team member performs analysis and discusses findings with the Project
Manager.
 Project Manager decides on the level of probability and impact based upon the risk’s
severity. The decision may be facilitated through discussions with the Risk Originator /
project team members / others, as appropriate to the specific risk.
 Project Manager updates / confirms the priority of the item on the project RAID Log.
Step 3. Development of risk mitigation strategies to minimise impact on the project if the risk
occurs
 Project Manager / project team member develop risk mitigation strategies to minimise
the impact on the project in the case of the risk occurring.
Step 4. Logging and tracking the risk details in the project RAID Log
 Project Manager, project team member, or delegated resource updates the project RAID
Log with details of the risk. Any updates to the details of the risk will be captured in the
th
PMO HANDBOOK
log, with actions being tracked on a regular basis. This is to ensure that the latest status
of the item is always maintained in the log.
Step 5. Monitoring of risks and invoking risk mitigation action as required

 Project Manager and Risk Owner monitor the risk to see if the probability or impact has
changed since last reviewed. Mitigation strategies are invoked as required.
Step 6. Reporting to appropriate level project governance model

 Project Manager formally reports risks on an exception basis to the appropriate project
governance level, i.e. reporting risks that require escalation / resolution by the level
being reported to, with recommendations for decisions / next steps wherever possible.
Step 7. Notification of outcome to Risk Originator

 Project Manager ensures that the current status of the risk is communicated to the Risk
Originator, as required.
th
PMO HANDBOOK
3.9.2 Assumption Review Management process

This process is used to formally manage assumptions made about the project delivery – scope,
timelines, costs, quality, resourcing, etc. that may impact the ability of the project to deliver if the
assumptions are proven to be false.
The process is undertaken to ensure that each assumption identified within the project environment
is documented, monitored, reviewed, confirmed as being true and closed (no project change
required) or false (project change potentially required), escalated and communicated as appropriate.
The process involves performing a variety of reviews and activities which focus on confirming if the
assumption is true or false, and developing action plans to minimise the potential risk to the project
delivery. If an assumption is proven to be false, the action plan (which may involve the development
of a change request for submission into the Change Request process) will be invoked.
The Assumption Review Management process is iterative and includes the following steps:
Step 1. Identification of project assumptions and logging to project RAID Log

 Assumption Originator (Project Manager / project team member / other project or
organisation resource) identifies an assumption applicable to a project.
 Assumption Originator discusses the assumption with the relevant Project Manager.
 Assumption Originator and Project Manager consider the assumption and determine
whether the assumption is applicable to the project.
 Project Manager may need to seek additional information from the Assumption
Originator / project team / other, to verify the validity of the assumption.
 If the assumption is considered by the Project Manager to be relevant to the project,
then a formal assessment is created in the project RAID Log. This may be created by the
Project Manager / Assessment Originator / project team member as directed by the
Project Manager.
Step 2. Assessment of the probability that the assumption is true or false and potential impact on
the project (timeline, scope, cost, resourcing, quality, etc.) if proven to be false
 Project Manager assigns a project team member to analyse the assumption, and
consider the level of probability and impact to the project if the assumption is proven to
be false.
 Project team member performs analysis and discusses findings with the Project
Manager.
 Project Manager decides on the level of probability and impact based upon the
assumption’s severity. The decision may be facilitated through discussions with the
Assumption Originator / project team members / other, as appropriate to the specific
assumption.
Step 3. Development of action plans to minimise the impact of a false assumption

 Project Manager / project team member develop assumption action plans for the
assumption to minimise the impact on the project in the case of the assumption being
proven false.
Step 4. Logging and tracking the assumption details in the project RAID Log
th
PMO HANDBOOK
Log with details of the assumption. Any updates to the details of the assumption will be
captured in the log, with actions being tracked on a regular basis. This is to ensure that
the latest status of the assumption is always maintained in the log.
Step 5. Monitoring of assumptions and invoking the assumption action plan for assumptions
proven to be false
 Project Manager and Assumption Owner monitor the assumption to see if the
probability or impact has changed since last reviewed. Action plans are invoked as
required.
Step 6. Reporting to appropriate project governance level

 Project Manager reports assumptions on an exception basis to the appropriate project
governance level, i.e. reporting assumptions that require escalation / resolution by the
level being reported to, with recommendations for decisions / next steps where
possible.
Step 7. Notification of outcome to Assumption Originator

 Project Manager ensures that the current status of the assumption is communicated to
the assumption originator, as required.
th
PMO HANDBOOK
3.9.3 Issue Review Management process

The Issue Review Management process is used to formally manage issues that are currently
affecting or which will affect the ability of the project to deliver.
The process is undertaken to ensure that each issue identified within the project environment is
documented, monitored, prioritised, resolved and escalated within an appropriate timescale.
The process involves performing a variety of reviews and activities to assess the level of impact that
the issue is having on the project, developing action plans to resolve and reduce the impact on the
project, and undertaking those actions.
The Issue Review Management process is an iterative process and includes the following steps:
Step 1. Identification of the project issues and logging to project RAID Log
 Issue Originator (Project Manager / project team member / other project or organisation
resource) identifies an issue applicable to a project.
 Issue Originator discusses the issue with the relevant Project Manager.
 Issue Originator and Project Manager consider the issue and determine whether the
issue is applicable to the project.
 Project Manager may need to seek additional information from the Issue Originator /
project team / other, to verify the validity of the issue.
 If the issue is considered by the Project Manager to be relevant to the project, then a
formal issue is created in the project RAID Log. This may be created by the Project
Manager / Issue Originator / project team member as directed by the Project Manager.
Step 2. Assessment / Estimation of the impact of the issue on the project (timeline, scope, cost,
resourcing, quality, etc.)
 Project Manager assigns a project team member to assess the issue, and define /
estimate the impact to the project.
 Project team member performs assessment and discusses findings with the Project
Manager.
 Project Manager decides on the priority of the issue based on the upon the issue’s
severity. The decision may be facilitated through discussions with the Issue Originator /
project team members / other, as appropriate to the specific issue.
 Project Manager confirms and updates the priority of the item on the project RAID Log.
Step 3. Development of issue corrective action plan to close / minimise the impact on the project
 Project Manager / project team member develop corrective action plans to close out the
issue or, if that is not possible, to minimise its impact on the project.
Step 4. Logging and tracking the issue details in the project RAID Log
Log with details of the issue. Any updates to the details of the issue will be captured in
the log, with actions being tracked on a regular basis. This is to ensure that the latest
status of the item is always maintained in the log.
Step 5. Monitoring of issues and corrective action plan as required

 Project Manager and Issue Owner monitor the issue to ensure the corrective action plan
is effective and to identify any changes to the action plan which would support closure
of the issue.
th
PMO HANDBOOK

 Project Manager reports / formally communicates issues on an exception basis to the
appropriate project governance model level, i.e. reporting issues that require escalation
/ resolution by the level being reported to, with recommendations for decisions / next
steps wherever possible.
Step 7. Notification of outcome to Issue Originator

 Project Manager ensures that the current status of the Issue is communicated to the
issue originator, as required.
th
PMO HANDBOOK
3.9.4 Dependency Review Management process

The Dependency Review Management process is used to formally manage dependencies that may
impact the ability of the project to deliver if the dependency is not met.
The process is undertaken to ensure that each dependency within the project environment is
documented, monitored, reviewed, confirmed as being on or not on target to be met, escalated and
communicated as appropriate.
The process involves performing a variety of reviews and activities which focus on confirming that
the dependency will be met (no impact on delivery). If required the Project Manager may develop
action plans and mitigation strategies to minimise potential impact to project delivery if the
dependency is not met. If a dependency is not met, the action plan to mitigate against any impact
(which may involve the development of a change request for submission into the Change Request
process) will be invoked.
The Dependency Review Management process is an iterative process and includes the following
steps:
Step 1. Identification of project dependencies & logging to project RAID Log

 Dependency Originator (Project Manager / project team member / other project or
organisation resource) identifies a dependency applicable to a project.
 Dependency Originator discusses the dependency with the relevant Project Manager.
 Dependency Originator and Project Manager consider the dependency and determine
whether or not the dependency is applicable to the project.
 Project Manager may need to seek additional information from the Dependency Originator /
project team / other, to verify the validity of the dependency.
 If the dependency is considered by the Project Manager to be relevant to the project, then a
formal dependency is created in the project RAID Log. This may be created by the Project
Manager / Dependency Originator / project team member as directed by the Project
Manager.
Step 2. Assessment of the probability that the dependency is not met and potential impact on the
project (timeline, scope, cost, resourcing, quality, etc.) if not met,
 Project Manager assigns a project team member to assess the dependency, and consider the
level of probability and impact to the project if the dependency is not met.
 Project team member performs assessment and discusses findings with the Project
Manager.
 Project Manager decides on the level of probability and impact based upon the
dependency’s severity. The decision may be facilitated through discussions with the
Dependency Originator / project team members / other, as appropriate to the specific
dependency.
Step 3. Development of action plans / mitigation strategies to minimise impact on the project if
the dependency is not met
 Project Manager / project team member develop dependency action plans / mitigation
strategies to minimise the potential impact on the project in the case of the dependency not
being met.
th
PMO HANDBOOK
Step 4. Logging and tracking the dependency details in the project RAID Log
 Project Manager, project team member, or delegated resource updates the project RAID Log
with details of the dependency. Any updates to the details of the dependency will be
captured in the log. The Project Manager must ensure that the latest status of the item is
always maintained in the log.
Step 5. Monitoring of dependency & invoking action plans / mitigation strategies as required
 Project Manager and Dependency Owner monitor the dependency to see if the probability
or impact has changed since last reviewed. Action plans / mitigation strategies are invoked
as required.

 Project Manager formally reports dependencies on an exception basis to the appropriate
project governance level, i.e. reporting dependencies that require escalation / resolution by
the level being reported to, with recommendations for decisions / next steps wherever
possible.
Step 7. Notification of outcome to Dependency Originator

 Project Manager ensures that the current status of the dependency is communicated to the
dependency originator, as required.
th
PMO HANDBOOK
3.10 Project Recruitment process

The primary owner for the process is the Sponsor.
This section provides details of the Project Recruitment process for both internal and external
resources required on a project that will be adhered to by the Sponsor and Project Manager.
The processes to be used:
Standard College process at: http://www.tcd.ie/hr/procedures/recruitment/
3.11 Project Procurement process

The primary owner for the process is the Sponsor.
This section provides details of the Project Procurement process for all procurement required on
Capital Projects that will adhered to by the Sponsor and Project Manager.
The processes to be used:
Standard College process at:
http://www.tcd.ie/procurement/
th
PMO HANDBOOK
3.12 Programme and Project Roles and Responsibilities

3.12.1 Introduction
The following sections contain a list of known and usual project roles and their key associated
responsibilities. The information is provided as a starting point for Project Sponsors and Programme
and Project Managers to assist with development of their own specific project roles and
responsibilities.
Please note that not all roles are required for all projects.
Further project roles for Committees and functions (and other specialist functions and roles) are
listed below:
 Board makes decisions on programmes and projects based on Approval & Prioritisation
recommendations from EOG/CRG
 Executive Officers Group (EOG) makes decisions and recommendations on projects based on
information and recommendations provided by CRG
 Finance Committee advises Board on the financial aspects of Capital Projects the total value
of which will exceed €3m (in conjunction with the Estates Committee)
 Estates Committee reviews progress and expenditure on all major development projects
from their inception to the settlement of final accounts in the context of the approved
briefs, budgets and programmes (in conjunction with the Finance Committee)
 Library and Information Policy (LIPC) Committee has a policy role in identifying information
systems implications in relation to overall College developments and an oversight/advisory
role in advising Board on significant resource issues in relation to Library and Information
Systems
 Space Allocation Sub-Committee provides decisions on space for Capital Projects
 PMO and Satellite project offices
th
PMO HANDBOOK
3.12.2 Sponsor
The Sponsor has overall accountability for delivering the project within the agreed scope, timeline,
quality and budget and is accountable for gaining project financial approval and for demonstrating
project benefits in order to make the case for approval & prioritisation of the project. The Sponsor
develops the Business Case and approves/accepts key project deliverables.
Responsibilities include:
Financial Management
 Accountable for ensuring financial approval for the project (project costs, on-going
operational costs and benefits realisation).
 Accountable for ensuring approval to draw down on the project budget at each Stage Gate
or as agreed in the Business Case or at project approval.
 Accountable for Financials Planning of project, and initiate corrective action where
necessary within the constraints lay down by the project.
Communication, Direction and Enablement

 Responsible for forming/assembling the Steering Committee.
 Chairing Steering or nominating/selecting an independent Chair.
 Acting as advocate for the project and gain commitment from other key stakeholders.
 Single point of contact for project communications external to the project team.
 Interface with Steering/CRG/EOG/Board and key Business Stakeholders pro-actively
delivering key project messages.
 Liaising with College strategic planning, Finance Committee and Estates Committee to
confirm that the proposed project is aligned with College Strategy (Strategic and
Operational).
 Engaging with other internal and external senior resources / stakeholders, as required.
 Ensuring project priority is achieved and maintained within College, and proactively and
visibly sponsoring the project within the organisation.
 Providing strategic direction and guidance to the project.
 Enabling appropriate resource commitment within College.
 Mobilising resources to effectively support the project activities.
 Facilitating problem solving.
 Communicating on behalf of the project, particularly with other stakeholder groups in senior
management. The Sponsor also communicates his or her personal commitment to the
project’s success and is visibly seen as its champion.
Project Management and Governance

 Overall accountability for delivering the project within the required scope, timeline, quality
and to the agreed budget, as agreed in the Business Case.
 Ensuring that the project management Monitoring and Control processes (to include
financial, resource, scope, timeline and quality) are planned and executed effectively.
 Accountable for the progress of the programme/project and use of resources.
 Accountable for recommending the move of the project through Stage Gates.
 Responsible for mediation and resolution of priority conflicts or other issues escalated by
the Programme/Project Manager.
 Responsible for escalating Risk and Issue items that cannot be resolved to Steering.
 Supporting the Programme/Project Manager in preparing appropriate recommendations /
corrective actions for any deviations from schedule/cost/quality, and in the preparation of
appropriate execution plans.
 Supporting the Programme/Project Manager and providing mentoring and leadership when
dealing with academic and operational matters.
th
PMO HANDBOOK
 Secure availability and timely assignment of the key resources required for successful
delivery.
 Attend all Steering meetings or arrange appropriate delegate.
 Communicating unforeseen issues (priority) to relevant stakeholders/committees.
Project Deliverables
 Responsible for development and presentation of the Business Case and related ongoing
deliverables including financial model.
 Proposing/approving/accepting overall project solution and key project deliverables.
 Passing back to steering the key deliverables that have been completed and approved.
 Accountable for producing required management (including financial) reporting.
 Attending key project decision making meetings as required.
 Maintaining project alignment with business and cultural goals.
 Responsible for delivering the benefits that underpin the achievements of the programme’s
Business Case.
 Building durability for the project’s outputs so that they will be sustained by the people and
processes in place once the project completes its handover.
 Developing the facilities management plan (in Construction projects).
 Accountable for occupation of the building (in Construction projects).
 Review and close out of project Stage Gates
 Conduct review of project once completed
 Arrange audit by College internal auditor, external auditors, external auditors from State
Departments and other agencies.
 Confirmation of project benefits on completion.
 Post-project monitoring to ensure benefits achieved in successful handover to business as
usual.
th
PMO HANDBOOK
3.12.3 Steering Committee and Members

Project Steering Committees are required for all projects with a budget of €500k or more. If the
project budget is less than €500k, CRG may request, during the approval and prioritisation process, a
programme or project to form a Steering Committee if CRG believe the project requires one due to
the level of risk.
The Programme/Project Steering Committee member’s role is to ensure that project priority and
resource commitment is achieved and maintained within their department/area and to
approve/accept key project deliverables as presented by the programme/project team.
 Ensuring compliance with Capital Project Governance under which the programme/project
operates.
 Monitoring and controlling the project scope and containing it to what is formally defined
and approved in the Business Case.
 Ensuring that all changes are formally approved via the Change Request process.
 Reviewing and accepting key programme/project deliverables as required.
 Ensuring project priority is achieved and maintained within their department / area.
 Enabling appropriate resource commitment within their department / area.
 Proactively and visibly sponsoring the project within their department / area.
 Delivering key project messages to staff within their department / area.
 Reviewing, approving or rejecting Change Requests falling within the approved project
baseline. Approving or rejecting Change Requests to project scope, timeline or budget.
 Acting as the ultimate escalation point for issues that cannot be resolved by the
Sponsor/Programme/Project Manager.
 Escalating Change Requests which fall outside of the project baseline through the required
approvals governance.
 Making strategic decisions on items raised by the project, to support delivery of the project’s
overall objectives and purpose.
 Resolving Risk, Issue and Dependency items escalated through the Risk and Issue Review
Management process.
 Attending key project meetings as requested.
 Challenging or testing that project benefits continue to be valid throughout the
programme/project lifecycle.
 In the event of a conflict between the Chair and Sponsor which cannot be resolved at
Steering, Chair has the responsibility of escalating to EOG for resolution.
Specific roles within Steering

The Steering Chair’s role is to ensure that Steering meetings are run as effectively as possible and
support the successful delivery of the project objectives, goals and vision. The Chair holds the
Sponsor, Steering, Project Team and stakeholders to account for decisions and project delivery and
ensures that Steering members act in the best interests of the overall project objectives, goals and
vision, and not their own specific department / area.
 Ensuring information being presented to Steering and through Governance is complete and
accurate, and effectively represents the project’s delivery status.
 Supporting and advising the Sponsor throughout the delivery.
 Holding the Sponsor, Steering Committee, Project Team and key stakeholders to account for
decisions and project delivery.
 Ensuring that the Steering members act in the best interests of the overall project
objectives, goals and vision, and not their own specific department / area.
th
PMO HANDBOOK
 Ensuring that all Steering members engage to the appropriate level in the discussions and
decisions of the committee.
 Ensuring the meetings are organised, managed and executed in an effective and efficient
manner to maximise the Steering Committee members’ investment of time and effort.
Steering may also include other specific roles including the following. Specific representatives –
dependent on project type who may not be in every Steering Committee – may include:
 Dean of Research: ensuring alignment with College innovation and entrepreneurship
strategy.
 Advisory Board Representative: manages the relationship with school or other advisory
boards.
 Representative of Trinity Foundation: managing the relationship with the donor
community.
 Advisor to Sponsor: for advice on specialist areas including architecture.
 Finance representative: holds the Sponsor, Steering, Project team and key stakeholders to
account for financial decisions and project finances. Owns the financial model for the project
and is responsible for monitoring and reporting performance against it.
 Estates and Facilities representative: ensures that building/construction fits with College
facilities management systems and processes and that there is a good fit with the overall
College amenities. Ensures timely and effective communications between the
programme/project and College infrastructure services.
 External consultant such as Construction Project Manager: ensuring delivery of specific
services e.g. construction project management within approved scope, timeline, budget and
quality constraints.
th
PMO HANDBOOK
3.12.4 Programme Manager

The Programme Manager’s role is to ensure that the full programme of works is delivered to
approved scope, timeline, budget and quality. The Programme Manager reports to the Sponsor of
the programme and attends Steering reporting on programme performance, but does not have
voting or decision rights on the committee. This role is the Single Point of Contact from the
programme delivery perspective and manages the internal and external programme team members
and sub-projects to deliver overall programme objectives while managing and influencing the
expectations of all the programme stakeholders.
Project Management Deliverables

 Delivering the programme/project deliverables within the required scope, timeline, quality
and to the agreed budget.
 Managing programme planning including programme milestone schedule, progress tracking,
resource planning, status reporting, and programme risk, assumption, issue and dependency
(RAID) management.
 Agreeing Project Delivery Plan with the Sponsor / Steering Committee.
 Passing back to the Sponsor / Steering key deliverables that have been completed and
approved in line with the agreed requirements.
 Resolving priority conflicts or other internal programme related issues that may arise.
 Preparing and gaining approval of programme documentation, including Communications,
Resourcing, Training and Testing Plans (as appropriate or required).
 Assisting with selection of project team members.
 Ensuring that the Project Managers act in the best interests of the overall project objectives,
goals and vision, and not their own specific project area.
 Attend all Steering meetings or arrange appropriate delegate.
 Communicating all critical changes to timeline and project cost to Sponsor.
 Financials Planning of the programme (and all sub-projects), and initiating corrective action
where necessary within the constraints as laid down by the programme.
 Monitoring and controlling all financial aspects of the programme, in compliance with the
financial governance processes.
 Supporting the Sponsor in obtaining financial approval for the project (project costs, on-
going operational costs and benefits realisation).
 Supporting the Sponsor in getting approval to draw down on the project budget at the end
of each Stage Gate.
Governance
 Ensuring that the programme and all related project activities comply with best
practices/College policy and by those agreed to by the project.
 Supporting the Sponsor and Steering Committee in the preparation and delivery of key
communication messages to internal and external resources, key stakeholders and College
committees to ensure delivery within scope, schedule, budget, and quality.
 Producing required management reporting and presenting to Sponsor/Steering/other as
required.
 Progressing the programme’s work and use of resources, and initiating corrective action
where necessary within the constraints as lay down by the programme.
 Reporting to Sponsor on completion of Stage Gates.
Risk and Issue Management
th
PMO HANDBOOK
 Raising Risk, Assumption, Issue and Dependency (RAID) items and proactively managing
programme RAID Logs.
 Escalating RAID items that cannot be resolved by the team to the Sponsor.
 Advising the Sponsor of any deviations from schedule, recommending corrective action, and
helping prepare any appropriate execution plans.
 Identifying and advising the Sponsor of any risks associated with a delivery / milestone.
 Ensuring information being presented to the Sponsor and Steering Committee is complete
and accurate, and effectively represents the project’s delivery status.
 Supporting and advising the Sponsor and Steering on project delivery matters throughout
delivery.
 Holding Project Managers and the Project Team to account for decisions and project
delivery.
 Ensuring that Project Managers act in the best interests of the overall project objectives,
goals and vision, and not just their own specific project area.
 Ensuring the project and programme meetings are organised, managed and executed in an
effective and efficient manner to maximise project team members’ investment of time and
effort.
th
PMO HANDBOOK
3.12.5 Project Manager

The Project Manager is responsible for delivery of the project to approved scope, timeline, budget
and quality. The Project Manager reports to the Sponsor or to the Programme Manager if a project is
part of a programme. If the project does not form part of a programme, the Project Manager
attends Steering reporting on project performance, but does not have voting or decision rights on
the committee. This role is the Single Point of Contact from the project delivery perspective and
manages the internal and external project team members to deliver overall project objectives while
managing and influencing the expectations of all the project stakeholders.
Project Management Deliverables

 Assisting the Sponsor/Programme Manager in preparation of programme documents.
 Delivering the project within the required scope, timeline, quality and to the agreed budget.
 Managing the project stakeholders with clear communication of progress and managing
expectations.
 Building the project team ethos by ensuring that everyone on the team knows and executes
assigned roles and by further ensuring that they are empowered and supported.
 Proactively managing and controlling the resources assigned to the project.
 Assisting with selection of project team members.
 Agreeing criteria for team selection.
 Defining detail of assignments and services.
 Agreeing terms and conditions of team engagement.
 Managing the Project Initiation Document and production of statement of requirements
 Producing required management reporting for Programme Manager/Sponsor.
 Advising the Programme Manager/Sponsor of any deviations from schedule, recommend
corrective action, and help prepare any appropriate execution plans.
 Progressing the project’s work, use of resources, and all remedial actions to address
resource issues, initiating corrective action where necessary within the constraints laid down
by the project.
 Ensuring appropriate level of supervision is applied to all project activities.
 Setting up and holding all project team meetings.
 Anticipating and monitoring impending change requests to the project and ensuring its
effects on quality, cost, programme and compliance are adequately quantified. Assess
effects before such change requests submitted for approval via the Change Control process
are approved and keep Programme Manager/Sponsor informed at all times.
 Managing project detailed planning including schedule, progress tracking, resource planning,
status reporting, and risk, assumption, issue and dependency (RAID) management.
 Agreeing Project Delivery Plan with Programme Manager / Sponsor.
 Passing back to the Sponsor/Programme Manager key deliverables that have been
completed and approved in line with the agreed requirements.
 Producing the Status Report and Steering Pack to inform Stakeholders (timeline, costs, risks,
issues, benefits tracking, change requests, resource allocation etc.).
 Identifying changes to project scope and costing of changes
 Adherence to all College policies e.g. procurement, retention of documents.
 Financial Planning of the project within scope, and proposing and initiating corrective action
where necessary within the constraints laid down by project governance.
 Providing regular updates on project financial performance.
 Monitoring and controlling all financial and resourcing aspects of the project, in compliance
with governance processes.
th
PMO HANDBOOK
 Supporting the Sponsor/Programme Manager in obtaining financial approval for the project
(project and on-going operational costs and benefits realisation).
 Supporting the Sponsor/Programme Manager in getting approval to draw down on the
project budget at the end of each stage (gate).
 Resolving priority conflicts or other internal project related issues that may arise within the
project.
Governance
 Applying PMO methodologies, processes, templates and standards.
 Preparing and maintaining a comprehensive set of project procedures to be used as a
framework to establish common policy, procedures and standards across all parties on the
project.
 Establishing and managing project documentation repository. Ensuring that proper and
accurate records are maintained including all instructions and information to all project
parties.
 Acting as the agent of the Sponsor/Programme Manager within the remit of delegated
authority to achieve progress on project tasks.
 Providing advice to College on project implementation.
 Ensuring establishment of roles and responsibilities within the project and related lines of
communication.
 Liaising with internal and external resources to ensure delivery within scope, schedule,
budget, quality.
 Taking tactical decisions based on the direction of the Sponsor and Steering.
 Ensuring compliance with the Governance (including the Stage Gate lifecycle) under which
the project operates.
 Ensuring compliance with College procurement policies and procedures.
 Establishing and coordinating control systems for cost, quality and timescale.
 Coordinating approval of payments within agreed timelines.
 Coordinate audits and reviews of the project including post-completion.
Risk and Issue Management

 Managing the risks and issues associated with the project, budget, plan and dependencies in
a controlled and effective manner.
 Raising Risk, Assumption, Issue and Dependency (RAID) items and proactively managing
project RAID Logs.
 Escalating RAID items that cannot be resolved by the team to the Programme
Manager/Sponsor.
 Identifying and advising the Sponsor of any risks associated with a delivery or milestone.
The Project Manager will fully comply with College procurement, publicity and retention of
documents policies and procedures. It is the Project Manager’s responsibility to report that all
procurement of services and products has been carried out in accordance with College policy.
CONSTRUCTION-SPECIFIC RESPONSIBILITIES BY MAJOR PHASES
The additional responsibilities listed below are specifically for the Project Manager on Construction
projects.
Pre-Construction
 Overseeing formalities relating to Professional Indemnity and warranties.
 Evaluating all necessary insurances for both professionals and contractors.
 Leading all contractor and sub-contractor negotiations.
 Liaising with legal advisors on all contractual issues (contract compilation terms and
conditions).
th
PMO HANDBOOK
 Proactively working with Quantity Surveyor to achieve any potential cost savings.
 Establishing Health and Safety File (Design).
 Addressing all environmental aspects of the project.
 Coordinating local and statutory authorities.
 Submitting recommendation of contractor for approval by Steering.
 Ensuring all documents regarding tax clearance are in place for contractors/sub-contractors.
Construction
 Confirming from Sponsor that all contracts are signed and sealed prior to commencement of
works.
 Ensuring all collateral warranties and performance bonds are in place.
 Confirming adequate insurance cover for works.
 Establishing and maintain Health and Safety File (Construction Stage).
 Responsible for contractor’s construction schedule and method statements.
 Establishing and managing mechanisms for dealing with potential claims during the project.
 Maintaining construction progress records, photo and video records from start to
completion of the project.
 Coordinating local and statutory authorities to ensure that project time and cost schedule
are maintained.
 Ensuring timely site inspections take place.
 Ensuring design information required by contractor is supplied by design team in a timely
manner.
 Ensuring contractors resources are adequate and suitable.
 Proactively working with Quantity Surveyor to achieve any potential cost savings.
 Assisting and liaise with Quantity Surveyor on Final Account negotiations.
Post-Construction
 Responsible for all commissioning documentation, maintenance manuals, and all as-built
drawings.
 Advising Programme Manager/Sponsor on insurance termination post contract.
 Planning and reporting on with testing and commissioning documentation.
 Ensuring all training regarding facilities is completed in a timely manner.
 Confirming receipt completion certificates from design team.
 Ensuring creation of snag lists by design team.
 Responsible for closure of items on the design team snag lists.
 Establishing the system of defects reporting post-construction.
 Responsible for rectification works.
 Assisting with handover of Health and Safety File (Post-Construction).
 Procuring warranties and guarantees from suppliers.
 Submitting final project close-out report for sign off at end of defects liability period.
 Ensure publicity plaques are in place if required.
 Review final Stage Gate.
 Ensure audits are planned and carried out.
th
PMO HANDBOOK
3.12.6 Independent Construction Validating Agent

The Construction Validating Agent is appointed by and reports to Board to act on their behalf as an
independent construction professional reporting on a quarterly basis or as required focusing on
construction cost control, project quality and delivery from initiation through to completion and
handover. Responsibilities include:
Pre-Construction
 As client representative attending programme meetings/processes to observe, report and
act on the selection process of:
o Design Team members
o Design team appointment
o Contractor, subcontractor and supplier interviews, selection and appointments
 Taking Client instructions and report back to Sponsor/Programme Manager/Project
Manager.
 Making independent recommendations to Sponsor/Programme Manager/Project Manager.
 Working with client legal advisors on design team appointments and liabilities.
 Making independent recommendations to Sponsor/Programme Manager/Project Manager
following legal advice on various project issues.
 Visiting consultant team members to query, interview and make suggestions and
recommendations to design team lead and Sponsor/Programme Manager/Project Manager.
 Representing Sponsor/Programme Manager/Project Manager and have authority to issue
instructions at design team meetings.
 Making independent recommendations on final approval and sign off at each stage of the
construction process.
 Ratifying budgets and cost control procedures.
 Working with Procurement on tender and reporting process.
Construction
 As Client Representative attending where possible all construction and site meetings
o Verification of change order (Change Request) procedures. As changes occur, the
Validating Agent is the direct link between College and the team for verifying
reasons for change, to identify who is responsible for change and at what cost.
o Proactively pursuing design cost savings.
o Monitoring and independent reporting on design cost additions.
o Access to all quantities and costs before and during progress of works.
o Working with Client’s legal advisors on all contractual issues relating to the Business
School.
 Access to monthly payment recommendations for certification in order to provide
independent, regular reports to Board.
 Participation at any dispute negotiations during the progress of the works and reporting on
additional costs should they arise.
 Reporting independently to Board on all progress in relation to cost reports and procedures
to highlight any deviations/variation from approved budget and agreed time schedule.
 Reporting to Board on a regular basis on any delay or disruptions on site which may have a
cost implication.
 Authority to visit team consultants during the progress of the works to assist with any
reporting issues to the board.
 Attending with project team members on compilation of snag lists and verification of snag
solutions and liabilities etc.
 Assist with audit and final sign-off at each Stage Gate of the project as Client’s
Representative.
Post Construction
th
PMO HANDBOOK
 As Client’s Representative:
o Attendance and participation at final account agreement meetings.
o Ensure all “As built” drawings and O&M documentation etc. are compiled as works
progress.
 Responsible for signing off final account cost report and agreement with Quantity Surveyor.
 Liaising on behalf of the client with construction and decanting projects on handover and
occupation procedure. Support smooth handover and ensuring that proactive solutions are
considered as the work progresses.
3.12.7 Business Analyst

The Business Analyst establishes the business scope to be addressed by the project team using the
information for the project as described by the Sponsor in the Business Case and acts as the main
contact into the project for day-to-day users of the end product and, as the customer
representative, works with business area SMEs to establish detailed plans.
 Development of business cases for process improvement initiatives.
 Documenting business processes and work with key stakeholders to identify issues
impacting existing processes (gather facts, analysis and documentation of work flows
including people and business units affected, business and academic cycles, functions to
implement and data to collect and use).
 Categorising needs and features, identifying (inter)dependencies and conflicts.
 Analysing existing processes, systems and structures and benchmark existing services levels
to identify areas for improvement.
 Working with stakeholders to identify options and solutions for process improvement and
build support for process changes ensuring that budget, schedule and quality constraints are
explored as part of the process of evaluating options.
 Managing expectations during option evaluation so that all recommendations contain
feasible manual and automated procedures.
 Identifying underlying supports required to enable process improvement.
 Actively driving process improvements across College and manage process improvement
initiatives through to successful completion.
 Defining project scope for process improvement initiatives, developing project
documentation and plans for these projects and managing them to completion.
 Coaching and mentoring as required on process improvement techniques and testing.
 Liaising with other Business Analysts responsible for related projects to ensure constraints
and expectations are shared.
 Obtaining sign off on recommended solution.
 Facilitating team processes within the project.
th
PMO HANDBOOK
3.12.8 Subject Matter Expert (SME)

The SME acts as the single point of contact for the business area with the project, representing the
business area in identifying both current (As Is) and future (To Be) processes and procedures.
 Providing expert knowledge within their field and provide source information to the project
team.
 Reviewing and confirming all major deliverables for the project relevant to the area with the
Project Manager, Business Analyst and Project Team Members.
 Providing expert knowledge on information collected and used in performing work.
 Providing expert knowledge on when, how and by whom information is used.
 Identifying opportunities to improve effectiveness, efficiency and economy of processes.
 Assisting in identifying and defining issues with existing processes.
 Participating in defining new and amended functional requirements.
 Developing test cases and perform/sign off on acceptance testing.
 Participating as required in any testing activities.
3.12.9 Legal Advisor

The Legal Adviser provides expert knowledge and guidance on implementing new and/or updated
legislation.
 Providing expert legal knowledge within their field and provide source information to the
project team.
 Evaluating and reporting on the impact of legislation on the project.
 Drafting information for review by SMEs, Business Analysts and Project Governance and the
project team.
 Ensuring compliance with legislation.
 Coordinating all professional/employment contracts to ensure compliance with College
procurements policy and procedures.
 Availability for
o Contractual advice before, during and after progress of works.
o For legal advice on delays and disruptions if and as these occur.
o For legal advice on warranties and maintenance issues should they arise.
3.12.10 Financial Advisor

The Financial Adviser ensures compliance with all College financial standards.
 Acting as Single Point of Contact for FSD.
 Providing expert knowledge and guidance required by the project on financial issues,
approaches, etc.
 Providing input into and support of the development of project costs, and ongoing
operational costs and benefits.
th
PMO HANDBOOK
 Supports the business in the development of the financial model for the project.
3.12.11 Trainer
 Understanding in full the project’s business context, solution and deliverables.
 Developing the project training strategy and detailed plan.
 Developing training guides and content for courses and manuals.
 Establishing and executing appropriate training sessions to support project strategy and
deliverables.
3.12.12 Architect
Pre-Construction
 Producing Client Brief.
 Producing Initial Design.
 Producing Developed Design.
 Producing Detailed Design.
 Producing Tender Documentation.
Construction
 Carrying out Site Inspections and Visits.
 Providing Contract Administration.
 Providing Payment Certification.
 Monitoring and signing-off scope change.
 Monitoring extensions of time.
 Attendance at all relevant meetings.
 Compilation of snag lists.
 Supervising completion of snag lists.
 Dealing with disputes on site should they arise.
Post-Construction
 Producing Certificate of practical completion
 Producing Final Payment Certification
 Providing opinion on compliances with planning and building regulations.
 Providing as-built drawings.
3.12.13 Cost Management and Quantity Surveyor

Pre-Construction
 Preparing a preliminary cost study based on the Concept Design.
 Preparing and implementing cost estimating and control procedures for the Project, to be
approved by College.
 Preparing and implementing change control procedures for the Project, to be approved by
College.
 Reviewing of and input to, as appropriate, all Project reports and studies.
th
PMO HANDBOOK
 Preparing feasibility cost estimates for all alternative design solutions proposed by the
Design Team.
 Attending all project and specific discipline meetings as required.
 Preparing and establish a Definitive Estimate or Budget for the Project as part of the
completion of Preliminary Engineering.
 Preparing a detailed cost plan for the Project and advising on financial effects of
construction phasing.
 Completing Value Engineering reviews at all major stages of design development.
 Providing full Quantity Surveying services to the Project including preparation of Bills of
Quantities for all Works Contracts (including any enabling works contracts required).
 Providing Bills of Quantities for M&E elements of the work.
 Regularly reviewing design development to ensure compliance with cost plan or
recommending action to mitigate impending overruns.
 Consulting and liaising with all Project Parties in a supportive and co-operative manner to
ensure overall Project objectives are met.
 Ensuring PM Team and College are advised of any circumstances arising that might cause
cost or schedule overrun.
 Advising on tendering procedures and contract documents in respect of all construction
contracts, and prepare the appropriate documents as required.
 Reviewing and analysing all construction bids, as appropriate and attending clarification and
negotiation meetings with Bidders.
Construction
 Providing comprehensive cost and cash flow reports for the Project on a monthly basis.
 Carry out all responsibilities and activities efficiently and in accordance with the programme.
 Attending site meetings as necessary.
 Monitoring actual cash flow against forecast.
 Approving invoices for payment and ensure payment by College.
 Ensuring contractor compliance with all insurance requirements. Secure certificates for
safekeeping.
Post-Construction
 Negotiating and agreeing final account with main contractor and all sub-contractors.
 Providing final cost report for College.
3.12.14 Structural Engineer

Pre-Construction
 Liaising with design team on programme for completion of design.
 Liaising with design team on programme for construction of works.
 Development of design proposal for works.
 Preparing representative sketches/drawings/specifications to assist with planning
permission/cost plan.
 Consulting with local authorities.
 Developing detailed design.
 Preparing final calculations to comply with building regulations.
 Assisting Quantity Surveyor with estimates of reinforcement, final specifications etc. for Bill
of Quantities.
 Assisting Architect in communication to client over technical suitability of works.
 Advising on the need for any special conditions of contract relevant to the works.
 Advising the Client/Architect on the likely necessity for appointing supervisory site staff.
th
PMO HANDBOOK
 Assisting Architect with merits of tenders, prices and estimates received.

 Providing submissions of drawings for the works to Architect.
 Co-ordinating and integrating within the overall design of the works.
Construction
 Advising on preparation of formal contract documents relating to accepted tenders for
carrying out the works or any part of them.
 Advising the Client/Architect in relation to the need for special inspections or tests arising
during the construction of the Project.
 Reporting to Architect on the necessity of appointment of supervisory site staff.
 Assisting the Architect in examining the Contractors proposals where required by the
building contract documents.
 Attending for duration of the structural works, all relevant site meetings.
 Advising the Architect on certificates for payment to the contractor.
 Performing any services which the Consulting Engineer may be required to carry out under
any contract for the execution of the works.
 Assisting the Architect in settling any dispute or difference relating to the works.
Post-Construction
 Delivering copies of the drawings supplied to the Contractor for the project upon completion
of the works.
3.12.15 Mechanical, Electrical, Public Health Services Consultant (MEP)

Pre-Construction
 Preparation of mechanical and electrical services drawings.
 Preparation of mechanical and electrical services specifications.
 Preparing budgets and obtaining costs from nominated contractors.
 Negotiating Fixed Price on receipt of costs (if applicable).
Construction
 Attending all site meetings.
 Carrying out site inspections and oversee Mechanical and Electrical Contractor’s work.
 Evaluating interim work in progress for Quantity Surveyor.
 Making payment recommendations, MEP work for Quantity Surveyor.
 Snagging building services and overseeing completion.
Post-Construction
 Preparing final accounts.
 Issuing opinion on compliance in relation to Building regulations.
 Checking ‘as built’ drawings and documents/certified contained in the Mechanical and
Electrical operational and maintenance manuals.
 Preparing Health & Safety statement as part of the design process in relation to the services
element of the project.
3.12.16 Fire Consultant

Pre-Construction
 Participating in design team meetings
th
PMO HANDBOOK
 Holding preliminary meetings with Fire Officer

 Highlighting fire regulations/precautions
 Engaging with Health & Safety Consultant
 Producing drawings and specification for fire certificate application.
 Signing off with Fire Officer prior to lodgement of fire certificate application.
Construction
 Holding regular meetings with design team
 Liaising with Fire Officer
 Monitoring installation
 Monitoring variations in specification with regard to fire implications.
 Procurement of O&M and specification confirmations with regard to fireproof material.
Post-Construction
 Providing certification and documentation for Fire Officer.
3.12.17 Health & Safety Consultant

Pre-Construction
 Holding regular meetings with design team.
 Compiling and producing a Safe System of work plan (SSWP).
 Appointing a Project Supervisor, Design Process (PSDP).
 Appointing a Project Supervisor, Construction Stage (PSCS) (Pre-construction).
 Developing the Health & Safety file for the project and make available to PSDP, PSCS and
Contractor.
 Communicating and liaising with team as necessary.
Construction
 Holding regular meetings with design team and contractor.
 Monitoring continuous Health & Safety on site.
 Updating and amending the Health & Safety file.
 Liaising with team if necessary.
 Conducting/supervising toolbox talks, safety talks.
Post-Construction
 Making site Health & Safety file available for handover.
 Compiling Health & Safety report post construction.
3.12.18 Traffic Consultant

Pre-Construction
 Compiling report on traffic implication for new construction.
 Engaging with Health & Safety Consultant.
Construction
 Monitoring traffic control including traffic light coordination, access and egress and liaising
with Dublin City Council, traffic department.
 Liaising with An Garda Siochána, if required.
th
PMO HANDBOOK
3.12.19 Fit Out Specialist

Pre-Construction
 Acquiring client brief.
 Production of drawings and specification.
 Compilation of budgets and costs for fit out.
Construction
 Monitoring work in progress during fit out.
 Working closely with design and management team on site.
 Dealing with all insurances of fit out staff.
 Supervising installation.
 Signing off of installation on completion.
Post-Construction
 Dealing with all snags and maintenance issues with regard to fit out.
 Acquisition of all O&M manuals.
 Monitoring use of fit out installation until expiration of warrantees etc.
3.12.20 Sustainable Energy Consultant

Pre-Construction
 Compilation and production of report with regard to sustainable energy.
 Signing off on accepted specification for sustainable energy within the design and contract
documents.
Construction
 Monitoring sustainable energy materials and installation during the progress of the works.
 Availability to amend design should variations occur.
 Ensuring maintenance of sustainable energy components during the works.
 Signing off of components and fittings upon completion of the works.
Post-Construction
 Monitoring use of sustainable energy components until expiration of warrantees etc.
 Compilation of report on sustainable energy at close-out of project.
3.12.21 Planner
Pre-Construction
 Consultation with Dublin City Council planning department.
 Production of planning report and recommendations.
 Assisting design team with planning application lodgement.
th
PMO HANDBOOK
3.12.22 Archaeologist
Pre-Construction
 Liaising with Dublin City Council.
 Compilation of report on archaeology aspects of project, if any.
th
PMO HANDBOOK
4 Capital Review Group (CRG)

4.1 Introduction
The Capital Review Group (CRG) is a subgroup of the Executive Officers Group (EOG).
Authority is delegated from EOG to CRG for the management of the Capital Project approval and
prioritisation process, the initial review and recommendation of projects for approval or rejection,
the monitoring of the College project portfolio performance, the recommendation of project change
requests for approval or rejection, and the approval of a project’s progression through the Stage
Gate process for all project Stage Gates not requiring Board approval.
CRG is not responsible for the execution of projects, but plays an oversight role on behalf of the EOG
and Board to monitor project performance against what was approved. It also monitors the overall
College project portfolio performance and may recommend reprioritising, placing on hold or halting
a project to support the success of the overall portfolio.
CRG does not have the authority to make decisions on behalf of the Project Steering or Sponsor, but
can raise concerns about a project and may escalate these concerns to the Project Sponsor or
Steering / EOG / Board for resolution. CRG reports decisions, recommendations and escalations to
EOG. CRG reports decisions affecting space allocation to the Space Allocation Sub-Committee (SASC).
CRG may approve projects with a capital spend up to €150k.
CRG comprises the following members:
Bursar (Chair).
Chief Operating Officer.
Chief Financial Officer.
Head of PMO.
PMO Admin (Secretary).
As the PMO does not have a responsibility for proposed or approved projects with a capital spend of
less than €500k, responsibility for receipt and recording of information for these projects (approval,
prioritisation, performance reporting etc.) lies with local project offices where these are in place,
and with PMO for support of the business areas otherwise.
4.2 Key Objectives

CRG’s key objectives include:
To consider Capital Projects and satisfy itself that the College’s strategic objectives are supported
/ delivered by them.
To improve the transparency, monitoring and control of capital spend within College
To challenge business cases and change requests in order to ensure College gets value for
money.
To act as the primary filtering and decision point for proposed projects and existing project
change requests, making recommendations on project approval or rejection, and prioritisation
within the College portfolio.
To act as the primary decision point for in-flight / live projects, making recommendations on the
prioritisation of a project to ensure the success of the overall College project portfolio.
To act as the final decision point for approval of a project through Stage Gate, for Stage Gates
not required to be approved by Board.
To effectively monitor the College project portfolio, reporting the appropriate level of detail to
EOG, Board and other committees as required.
th
PMO HANDBOOK
To manage and report on Capital Project approval and prioritisation, and project portfolio
performance reporting processes in a timely and effective manner.
4.3 Key Responsibilities

CRG’s key responsibilities include:
Reviewing the strategic alignment and completeness of business cases, for projects with a capital
spend of €50k or greater.
Approving budget / spend to support the development of a full project Business Case for
submission for approval (post 1st Pass of approval and prioritisation process – filtering) up to a value
of €150k.
Reviewing and making approval or rejection recommendations on new projects or project
change requests.
Presenting CRG recommendations to the EOG / Board for approval on new projects / project
change requests, including:
o Approval or Rejection of projects / change requests.
O Agreeing / recommending an appropriate project Sponsor.
O Agreeing / recommending appropriate Steering Committee membership and Chair.
O If the Sponsor is not a member of EOG, agreeing / recommending an appropriate EOG
champion.
Approving a project’s progression through the Stage Gate process where approval is not required
by Board.
Taking decisions to place in-flight projects on hold or to cancel projects due to issues with the
individual project, or with the overall project portfolio
Reviewing project performance against the approved baseline
Reporting to EOG / Board and other committees (as required)
o Appropriate level of detail on the performance of the College project portfolio,
highlighting exceptions and key areas of risk
o Appropriate level of detail on the College Capital Project pipeline,
o Decisions, recommendations and escalations made,
o Priority of projects, and any change to priority.
4.4 Level of Approval Authority

All capital projects with an estimated / potential capital spend value of greater than €50k must be
submitted to CRG for inclusion in the College Project Approval & Prioritisation process, irrespective
of whether funding for capital spend is available or being sought.
CRG can approve projects with an estimated / potential capital spend of up to €150k. CRG may
decide to escalate projects within their approval limit to EOG for approval if deemed appropriate
(e.g. project is of high risk).
All projects with an estimated / potential capital spend value of greater than €500k must have an
EOG Champion assigned.
EOG can approve projects with an estimated / potential capital spend of up to €3m. EOG may decide
to escalate projects within their approval limit to Board for approval if deemed appropriate (e.g.
project is high risk).
th
PMO HANDBOOK
Any project with an estimated / potential capital spend of more than €3m must be approved by
Board.
Deans and Chief Officers are responsible for sign-off of projects being proposed by their area in
advance of their submission via CRG into the project Approval & Prioritisation process.
4.5 CRG Meeting Types and Timeline

4.5.1 High Level CRG communications flows
The diagram below provides a high level view of the communications and meeting types referred to
in this document.
Fig 8. HIGH LEVEL COMMUNICATION FLOWS
4.5.2 Project Approval & Prioritisation

Initially, projects will be accepted by PMO on an ad-hoc basis and scheduled for inclusion on the
monthly CRG meeting for approval and prioritisation. In the longer term prioritisation may be
determined on an annual basis. Projects with an estimated value of capital spend between €50k and
€500k will be submitted via the local Project Office (where one exists) into PMO.
Where a local Project Office does not exist or where the estimated value of capital spend is €500k or
greater, submissions will be made directly into the PMO.
All submissions will be presented using standard templates / formats for ease and efficiency of
filtering and understanding.
When an annual prioritisation process is adopted submissions will follow a 2 pass review approach
through the CRG. The 1st pass will be used by CRG to review all project submissions at a high level
th
PMO HANDBOOK
and filter those that are not to be progressed further as they are not considered to be appropriate
for College to pursue at this time. Projects will be categorised into one of the following:
Rejected
Additional information required before being considered further
On hold
Progressed to the next pass of the CRG process.
These meetings will be scheduled to take place annually at the end February through end March.
The 2nd pass will be used by CRG to review those projects progressed from the 1st pass at a much
greater, granular level of detail. Detailed Business Cases will be developed by the Project Sponsor
and a standard summary template completed for submission to CRG. Submitted proposals will be
considered, Business Cases challenged, and decisions made on what projects are to be
recommended for:
Approval
Rejection
On hold
Further information required
This decision will be based on a number of criteria and will take into account the impact of a project
on the overall College project portfolio, and the appropriate use of College resources (money,
people, technology, etc.). These meetings will be scheduled to take place annually from May through
mid-June.
Projects being recommended for approval will be presented to EOG / Board for approval, as
appropriate.
4.5.3 Monthly Project Portfolio Performance Review

To be held monthly at an agreed point after the calendar month end. The project performance
reports collated by PMO and provided for use at the meeting will represent the status of the projects
at month end.
4.5.4 Stage Gate

To be held monthly at an agreed point after the calendar month end. Will be included as part of
scheduled monthly CRG meeting. For full details of the Stage gate process, please refer to relevant
sections in this document.
4.5.5 Change Requests

To be held monthly at an agreed point after the calendar month end. Will be included as part of
scheduled monthly CRG meeting. For full details of the Change Request process, please refer to
relevant sections in this document.
4.6 CRG Meeting Principles

The following describes the principles on which CRG meetings are run:
The quorum is two of three Executive Officers.
If a member is not in a position to attend the meeting, another member of EOG may be asked to
attend.
The Head of PMO will consult with the members of CRG on projects, but will not have any voting
rights when making decisions.
For approved projects, the Head of PMO will provide timely collated and summarised project
performance information based on information received directly from the projects or via the local
Project Office, where one exists.
th
PMO HANDBOOK
For proposed projects, the Head of PMO will provide the latest summary information made
available either directly from the projects or via the local Project Office, where one exists.
th
PMO HANDBOOK
5 General Project Administration and Support

The project will follow the guidelines laid down by College, or if not available, an approach that
would generally be considered to be best practice project governance. These include reporting on
and managing projects, storing project documentation and deliverables of various kinds, the
completion of timesheets, financial reporting, resource planning and management.
All project documents have been developed using the standard MS Office toolset.
 MS Word
 MS Excel
 MS PowerPoint
 MS Outlook
 MS Project
 MS Visio
In summary, each project will use a shared project folder in which to maintain all project
management information. A document/file directory structure will be proposed by PMO (intended
as a guide). Project Managers may make changes to this as required by their own specific project.
The project folder will be used to facilitate sharing of information amongst the project team and
within the wider key stakeholder community as appropriate.
All working documents will be saved by project team members so that all have access to and are
working on the same version of deliverables.
Documents will include minutes of all meetings, presentations and communications.
All project resources will complete periodic timesheets and provide to the Project Manager. This
information will feed into the project financial processes, calculating actuals and budgets for the
project.
th
PMO HANDBOOK
A 1. The Capital Projects Governance Process

On 26th June 2013, a proposal was brought to Board to approve Capital Project governance and
related processes. This was informed by an exercise carried out by PrimeCore who put forward a
governance structure and an infrastructure project process methodology (Stage Gate). Interim
arrangements for implementation of a College-wide Programme Management Office (PMO) were
also approved.
This section outlines the historical development of a standardised lifecycle based on the PrimeCore
work and the paper brought to Board in June 2013.
Board approved that the proposed overarching project management methodology is Stage-Gate, an
approach designed to break the lifecycle of a project into key defined stages each of which allow
College to establish if a project has merit before resources and funding are approved to develop it to
the next stage.
Each Stage concludes with a Gate Review at which the project business case is assessed and if it is
still attractive, the project is approved to the next stage of development. The implementation of
Stage-Gate will include formal change controls and formal risk management strategies.
The PrimeCore Stage Gate model included seven lifecycle Stages and six Gate Reviews:
Stage Followed by Gate Review

0 Idea Screening 0: CRG Approves project and submits it to EOG
1 Project Initiation 1: EOG and Board approve total funding for strategic planning
2 Strategic Planning 2: CRG approves funding for concept design
3 Concept 3: CRG approves funding for basis of design
4 Basis of Design 4: EOG or Board approves full project funding (earliest)
5 Detailed design 5: EOG or Board approves commencement of implementation design
6 Execution & Handover 6: EOG or Board approves project for commercial closeout
7 Closeout
Fig 9. PRIMECORE STAGE GATE MODEL
In the process of implementing the PMO, the full range of governance structures, roles and
responsibilities were proposed in detail and approved, as were the key project management
processes for approval, prioritisation, reporting, risk and issue management while other process
designs are being prepared with input and feedback from the key areas of College managing Capital
Projects.
As roles and responsibilities and project management processes have been developed further, the
PMO Design Team have reviewed each Stage in this model and introduced some modifications in
order to achieve the original objectives by expanding the model to encompass all Capital Project
types.
In doing this, the PMO Design Team continues to engage with the PMO Consultation Group. In
addition, the Team has used portfolio, programme/project management and construction best
practice with particular emphasis on the Irish Government’s Capital Works Management Framework
(CWMF – see below).
In summary, the PMO Design team have confirmed the following lifecycle for Capital Projects. The
modified lifecycle illustrated in the diagram below addresses several issues including the fit of the
model with several project types other than construction, staying in line with more recent
th
PMO HANDBOOK
developments including design of the approval and prioritisation process, and alignment in full with
the Government framework thus enhancing governance and control at all Stages in the lifecycle.
Fig 10. CAPITAL PROJECT GOVERNANCE PROCESS
The original Stage Gate lifecycle has been reviewed against best practice and construction
frameworks and aligned to enhance Capital Projects Governance and control over all Stages of the
lifecycle.
The figure overleaf cross-references the original Stage Gate lifecycle proposed by PrimeCore with
the Capital Project Governance Process, aligned with CWMF and identifying the rationale and
benefits of the modification.
The over-arching project management methodology remains Stage Gate in its design as approved by
Board.
Additional mandatory Steering Reviews have been added and these align with the CWMF
framework. Deliverables from the construction lifecycle have been aligned with Stage Gate to ensure
that projects of all types will be managed using a standardised approach.
The following is the detailed Stage Gate Lifecycle model:
th
PMO HANDBOOK
CAPITAL PROJECTS GOVERNANCE PROCESS (STAGE GATE)
INITIATION & STRATEGIC DETAILED PLANNING & POST

STAGE APPROVAL & PRIORITISATION
PLANNING HIGH LEVEL DESIGN
DETAILED DESIGN EXECUTION & HANDOVER CLOSEOUT
PROJECT
DELIVERABLES
SPONSOR PROJECT MANAGER PROJECT MANAGER PROJECT MANAGER PROJECT MANAGER PROJECT MANAGER SPONSOR
OWNER*
HANDOVER &
Sub-Stage PASS 1 : FILTER PASS 2 : ASSESS TENDER EXECUTION TESTING
IMPLEMENTATION
BUSINESS CASE [PRODUCTS BENEFITS
BUSINESS CASE PROJECT INITIATION DOCUMENT DELIVERY PLAN (DETAILED) DELIVERY PLAN (DETAILED) WHOLE LIFE COST UPDATE TEST PLAN SCHEDULE LESSONS LEARNED
(APPROVED) DELIVERED] REVIEW
FINANCIAL, RESOURCE FINANCIAL, RESOURCE PLANS
PROJECT FINANCIAL PLAN DELIVERY PLAN (HIGH LEVEL) [TENDER DOCUMENTATION] [PRODUCTS TESTED]
PLANS (DETAILED) (DETAILED)
MANAGEMENT
RESOURCE PLAN FINANCIAL & RESOURCE PLANS [BUSINESS REQUIREMENTS] [CONTRACTOR LIST SELECTION]
DELIVERABLES
LIFECYCLE [APPOINT DESIGN TEAM] [HIGH LEVEL DESIGN] [FUNCTIONAL SPECIFICATION] [TENDER ASSESSMENT CRITERIA ]
[TECHNICAL
DELIVERABLES] [TENDER ANALYSIS & REPORT ]
[CONTRACTOR RECOMMENDATION]
PROCESS APPROVAL & PRIORITISATION STANDARD PROJECT MANAGEMENT PROCESSES incl. STAGE GATE, PERFORMANCE REPORTING, RAID, CHANGE CONTROL
GATES 0 1 2 3 3a 4 4a 4b 5 6
1 2 3 4 5 6 7
CAPITAL WORKS MANAGEMENT
Definitive Procurement Strategy Devd Cost Plan (rev) Tender Documentation Project
Preliminary Project Brief Contract Type Proposal Stat Approvals Sub'n Detailed Pre-tender Cost Check Outturn
FRAMEWORK (CWMF)
Preliminary Output Spec Project Team Selection Report* Devd Sketch Scheme Whole Life Cost Update Review
Feasib. Study, Cost Plan * if not appointed earlier Contractor List Selection
Design Brief Tender Assessment Criteria
Devd Cost Plan (rev) Final Output Spec
Stat Approvals Sub'n Definitive Project Brief Outline Sketch Scheme (Buildg) Developed Cost Plan Tender Analysis & Report
Devd Sketch Scheme Proj Execution Plan Preliminary Planning drawings Contractor Recomm
Risk Management Plan Outline Cost Plan
(I) FEASIBILITY, PRELIM

(II) DESIGN (III) TENDER (IV) CONSTRUCTION (V) HANDOVER
REPORT
a) OUTLINE SKETCH b) DEVELOPED SKETCH c) DETAILED
SCHEME SCHEME DESIGN
* SPONSOR is end-to end accountable for project Release 1.6 :: 20/5/2014
Fig 11. CAPITAL PROJECT GOVERNANCE LIFECYCLE
th
PMO HANDBOOK
PRIMECORE NEW STAGE FOLLOWED BY GATE REVIEW STEERING REVIEW RATIONALE AND BENEFITS
(0) Idea Screening, APPROVAL & 0: CRG recommends project, Improved governance/controls on filtering
Gate 0 PRIORITISATION submits it to EOG/Board to proposed projects.
approve funding for initiation
and strategic planning
(1) Project INITIATION & 1: CRG makes recommendation Aligns with Steering Review 1 Improved flow of project, allows advancement of
Initiation, Gate 1 STRATEGIC to EOG/Board re acceptance of project to high level design stage, aligns better
(2) Strategic PLANNING Stage with sequencing of variety of project types.
Planning, Gate 2
(3) Concept, Gate 3 DETAILED Midway in Stage: CWMF/Steering Review 2 for Aligns with CWMF Review 2.
(4) Basis of Design PLANNING AND construction projects: definitive procurement strategy,
Gate 4 HIGH LEVEL DESIGN contract type proposal, project team selection report.
2: CRG makes recommendation Aligns with Steering Review 3 for construction projects: Aligns with CWMF Review 3.
to EOG/Board for Stage Outline sketch scheme, preliminary planning drawings,
acceptance and outline cost plan.
(5) Detailed DETAILED DESIGN Midway in Stage: Aligns with Steering Review 4 for Aligns with CWMF Review 4.
Design, Gate 5 construction projects: detailed cost plan.
3: CRG makes recommendation Aligns with Steering Review 5 for construction projects:
to EOG/Board re acceptance of developed sketch scheme, developed cost plan, Aligns with CWMF Review 5.
Stage statutory approval submission.
(6) Execution & EXECUTION &
Handover, gate 6 HANDOVER:
Tender 4: Following Tender Steering Review 3a – all projects (following Tender). Aligns with CWMF Review 6.
Aligns with Steering Review 7 for construction projects: Aligns with CWMF Review 7 (LAST REVIEW).
tender analysis and report, contractor rec’n.
 Execution Steering Review 4a – all projects (following Execution). Enhanced governance and control over the
 Testing Steering Review 4b – all projects (following Testing). details of execution, testing and handover.
5: CRG makes recommendation Approval to move into Closeout Stage
 Handover & to EOG/Board re Stage
Implementation acceptance
(7) Closeout CLOSEOUT 6: CRG makes recommendation Enhances governance over Closeout Stage and
(no Stage gate) to EOG/Board re final closeout reviews lessons learned from project; establishes
and agrees review period and timeline/expectations for Benefits Realisation
deadline for Benefits Review. review
Fig 12. CROSS-REFERENCE OF CPGP, PRIMECORE AND CWMF MODELS
th
PMO HANDBOOK
Stage Gate proposed June 2013, Source: PrimeCore, Board Paper

Fig 13. PRIMECORE INFRASTRUCTURE PROJECT LIFE CYCLE
th
PMO HANDBOOK
Source: Irish Government, http://constructionprocurement.gov.ie/capital-works-management-framework/

Fig 14. CAPITAL WORKS MANAGEMENT FRAMEWORK (CWMF) AND PROJECT LIFECYCLE
th
PMO HANDBOOK
A 2. Definitions
A2.1 Projects and their classifications
A project is defined as a temporary activity designed to produce a unique product, service or result
with a defined beginning and end (usually time-constrained, and often constrained by funding or
deliverables), undertaken to meet unique goals and objectives, typically to bring about beneficial
change or added value. The temporary nature of projects stands in contrast with business as usual
(or operations), which are repetitive, permanent, or semi-permanent functional activities to produce
products or services.
Projects will include the following major categories:

 New Build: (construction of new buildings or development of new facilities and
infrastructure)
 Refurbishment: (construction work on existing buildings or facilities/infrastructure)
 Information systems: including systems development or acquisition, networks, hardware
systems, support)
 Legislative: required or initiated by external regulator / legislator; mandatory project focused
on delivering to specified timelines, constraints or quality (may originally be initiated as a
directive).
 External: projects driven by external demands/constraints (non-legislative) due to external
impacts and influences
 Organisational Change (change management): initiated to deliver an organisational change
or organisational restructure to one or more specified business areas or functions in order to
achieve quantifiable business benefit in the form of resource effectiveness or efficiency.
Focused on the “people” side of change within an organisation, but may also include other
aspects of project e.g. Processes & technology. The objective is to achieve lasting change
within the organisation.
A2.2 Risks, Assumptions, Issues and Dependencies

Brief definitions of risk, assumption, issue and dependency are outlined below.
RISK A prediction of a significant negative event that might occur in the future, and which is likely to
adversely affect the ability of the project to achieve the defined objectives.
ASSUMPTION A statement that is assumed to be true and from which a conclusion can be drawn. Assumptions
rd
are made about the project variables e.g. timeline, scope, cost, resourcing, quality, business / 3
party support and interfaces, organisational delivery capability, etc., and form part of the basis
for the project delivery. Where an assumption turns out to be false, a Change Request may need
to be raised to control the impact to the project delivery.
ISSUE Anything currently impeding (or that will impede) progress of the project, and about which final
agreement / closure has not yet been reached. The impact of an issue may cause delay, change
direction, impair solutions, hinder quality, alter deliverable content or increase cost.
DEPENDENCY Any event or deliverable required before a project activity can commence or complete. There can
be internal dependencies i.e. being managed / controlled within the project, and external
dependencies i.e. requiring interaction between other projects / business areas / organisations
that do not form part of the project
Fig 15. DEFINITION: RAID
th
PMO HANDBOOK
A2.3 Estimation, Risk and Contingency

This section addresses the topic of contingency, its definition and circumstances under which it can
be used, and how it is managed, controlled and reported. It places contingency in the context of risk,
assumption management and estimation which are related topics.
When estimating the cost for a project, there is always uncertainty as to the precise content of all
items in the estimate, how work will be performed, what work conditions will be like when the
project is carried out and so on. These uncertainties are project risks. Risks are identified, logged and
assessed for severity (based on their likelihood and impact if the risk occurs). The next step in
dealing with the risks is in devising a risk response strategy in case they occur – actions agreed
where possible in order to mitigate the severity of the risk. Some risks are more certain than others
and can be estimated with a high degree of accuracy.
Some risks, however, are less defined and more difficult to estimate. The estimated cost of these
risks is referred to as contingency which can be defined as:
“… an amount added to the overall project estimate to allow for items, conditions, or events
for which the state, occurrence, or effect is uncertain and that experience shows will likely
result in additional costs/time/effort.”
Contingency is designed to cover items of cost which are not known exactly at the time of estimation
and are predicted to occur based on past experience, but with some uncertainty regarding the
amount. These cost items must be included in the Business Case, PID and related planning
documentation with all available information and will be reviewed regularly throughout the project
lifecycle in line with risk and assumption reviews.
Contingency excludes scope changes such as changes in product specification or added functionality,
capacities, building sizes, and location of the asset or project. It is not intended to be used to cover
inadequate estimation or poor project management.
Contingency is typically estimated using:
 expert judgment based on past project or asset experience
 what-if scenario analysis
 predetermined guidelines
Simulation analysis (primarily risk analysis as in approaches such as the Monte-Carlo method) and
parametric modelling may also be used to assist estimation of the contingency.
Contingency is identified and included in the project budget as a control account. As risks occur on a
project or assumptions are proved to be false, and funds are approved to pay for them, contingency
can be transferred to the appropriate accounts that need it. The transfer and its reason must be
approved and recorded by the appropriate authority. Just as with assumptions and in risk
management, where there is continual review and reassessment during the course of a project, so
the need for contingency is reviewed regularly by the Project Manager, Sponsor and Steering. At
each Stage Gate, and at Steering Reviews, use of contingency will be reviewed and approval sought
as required.
What is important to emphasise is that, as more precise information about the project and its
deliverables becomes available to the project team, the contingency may be used, reduced or
eliminated. Contingency will always be clearly identified as part of financial documentation.
th
PMO HANDBOOK
A 3. Abbreviations used
The following table provides a list of abbreviations commonly used throughout the project
documentation.
Abbreviation Description
BA Business Analyst
CR Change Request
LIPC Library & Information Policy Committee
PM Project Manager
PMO College-wide Project Management Office
RAID Risks, Assumptions, Issues and Dependency logs
SAC Space Allocation Committee
SME Subject Matter Expert
TCD Trinity College, University of Dublin
th
PMO HANDBOOK
A 4. Templates and other documents

A2.4 Artefacts
The following table provides a list of PMO/project artefacts (some of which are still in design)
referenced in this document.
Title Description / Comment
Business Case Summary Presents background and objectives, alignment to Strategy, scope,
risks, issues and constraints, options and recommendations, cost
and benefit estimates, resources and milestones, proposed
Steering Committee and Project Risk Indicator.
Business Case Business Case covering scope, deliverables, benefits, etc. This
forms the baseline of the project management delivery.
Capital Works Management The Capital Works Management Framework is a structure that has
Framework (CWMF) been developed to deliver the Irish Government’s objectives in
relation to public sector construction procurement reform. It
consists of a suite of best practice guidance, standard contracts
and generic template documents that form the four pillars that
support the Framework.
Change Request Presentation Template for presentation of Change Request. PowerPoint
presentation required to request Steering Committee / CRG (as
appropriate) approval for changes to the project performance
areas i.e. Schedule, Financials, Resources, Scope, Quality and Risk.
Project Closure Report The Project Closure Report is the final document produced for the
project and is used by senior management to assess the success of
the project, identify best practices for future projects, resolve all
open issues, and formally close the project.
Change Request PRI Log Change Request PRI Log Template contains an Excel worksheet
used to log details of the Project Change Requests received /
processed by the project including status, impact, actions and
decisions relating to each change request.
Financial Plan Project financial estimates of resources (people, technology,
miscellaneous) required to deliver the project, and to support post
implementation. It also includes details of the estimated benefits
to be delivered by the project.
Handover & Implementation Document outlining the approach to be taken to deliver the
Schedule (part of Delivery project deliverables to the business by detailing the related
Plan) activities and tasks, responsibilities and timelines involved.
Post Implementation Benefits Evaluation (post project) of the operational success of the project
Review Template and assessment of the actual costs, benefits and savings in
comparison with planned amounts.
Project Closure report Document outlining the status of what the project set out to
achieve as documented in the Business Case, against what it
actually achieved at project completion. It also identifies the
actions required to close down project activities and move to
th
PMO HANDBOOK
business as usual.
Project Delivery Plan Project Delivery Plan showing key deliverables, delivery dates, and
Template key dependencies
Project Portfolio Performance Pack for presentation to CRG of all projects each month. Will
include monthly update of all live projects, Change requests, and
Reporting Pack
new Business cases. It is produced and maintained by PMO.
Project Portfolio Summary This pack contains a summary of the status of all Capital Projects. It
is produced and maintained by PMO.
Register Log
Project Status Report pack Pack for regular project status reports
RAID Log RAID Log contains an Excel worksheet to hold details of project
Risks, Assumptions, Issues, and Dependencies.
Stage Gate Approval Pack Pack for presentation at Stage Gates
A2.5 Reference standards and sources

The following sources have been used to assist in design and compilation of these processes, roles
and responsibilities for the purposes of best practice.
 Project Management Body of Knowledge (PMBOK) (5th edition, 2013, PMI)
 APM Body of Knowledge (APMBOK) (6th edition, 2012, APM)
 Primecore documents (College Board, June 2013)
 Code of Practice for Project Management for Construction and Development (4th edition
2010, CIOB)
 Irish Government Capital Works Management Framework (CWMF) at

http://constructionprocurement.gov.ie/capital-works-management-framework
 JISC Infonet at http://www.jiscinfonet.ac.uk
th

PMO Handbook v1.5

Uploaded by

Copyright:

Available Formats

PMO Handbook v1.5

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PMO Handbook v1.5

Uploaded by

Copyright:

Available Formats

PMO

Sign Off, Review & Information

Document Preparation, Review, Distribution

Project Summary Information

3.8.1 Risk ................................................................................................................................ 39

4.4 Level of Approval Authority................................................................................................ 70

Fig 1. Approval & Prioritisation high-level information flow .............................................................................. 7

1.2 Executive Summary

1.3 Scope of the PMO

CRG filters/ Sponsor

Fig 1. APPROVAL & PRIORITISATION HIGH-LEVEL INFORMATION FLOW

Project PMO provides CRG meets to CRG informs

Fig 2. PERFORMANCE REPORTING HIGH-LEVEL INFORMATION FLOW

1.4 Project Risk Indicator (PRI)

# of cross functional areas 1 2-5 6-9 10-12 >13

2 Capital Project Governance

Approval and Prioritisation

Fig 4. CAPITAL PROJECT STAGES

2.1 Project Approval & Prioritisation

 Business Case pack

Processes used include

2.2 Initiation and Strategic Planning

2.3 Detailed Planning and High Level Design

2.4 Detailed Design

Principle inputs for this Stage

Processes used include

2.5 Execution and Handover

Principle inputs for this Stage

Processes used include

Principle inputs for this Stage

2.7 Post Project

3 Key Capital Project Governance Processes

3.1 Project ID Request process

The template / document to be used by the Project Sponsor is:-

Additional templates / documents used by PMO during the process are:-

3.2 Project Approval and Prioritisation process

3.2.1 Business Case pack preparation

3.2.2 PASS 1 – Filter and Create Potential Project Shortlist

3.2.2.1 Preparation of project Business Case for approval & prioritisation

 Key resources required, milestones

3.2.2.2 CRG Project Portfolio Approval & Prioritisation Meeting(s) – Preparation

NOTE: A number of meetings may be held to facilitate volume of submissions.

3.2.2.3 CRG Project Portfolio Approval & Prioritisation Meeting(s)

NOTE: A number of meetings may be held to facilitate volume of submissions.

Step 14. CRG decisions are communicated:

 Sponsor communicates to EOG/Board/Committees on actions and

3.2.2.4 PMO processing of CRG decisions

3.2.3 PASS 2 – Assess Business Case and Supporting Documents

3.2.3.2 CRG Project Portfolio Approval & Prioritisation Meeting - preparation

3.2.3.3 CRG Project Portfolio Approval & Prioritisation Meeting(s)

3.2.3.4 Processing of CRG decisions/Recommendations

3.3 Project Portfolio Performance Reporting Process

3.3.1 Preparation of Status Report by Project Manager

3.3.2 Collation of status information and issuance to CRG by PMO

Step 6. CRG Project Portfolio Performance Reporting pack created by PMO by

3.3.3 CRG Project Portfolio Performance meeting

3.4 Project Stage Gate Approval Process

The templates / supporting documents to be used by the Project Manager are:

3.4.1 Stage Gate Approval steps