9. PROJECT MANAGEMENT GOVERNANCE POLICY Redacted

Prévia do material em texto

ITEM: 9 
 
 PAGE: 1 
 
REPORT TO: POLICY & RESOURCES COMMITTEE ON 7 JUNE 2016 
 
SUBJECT: PROJECT MANAGEMENT GOVERNANCE POLICY 
 
BY: CHIEF EXECUTIVE 
 
1. REASON FOR REPORT 
 
1.1 This report presents the Council’s new approach to project management and 
associated administration. It describes the proposed corporate approach to 
project management governance and provides assurance to Elected Members 
that processes and controls are in place to ensure successful project delivery 
within the Council. 
 
1.2 This report is submitted to Committee in terms of Section III A (2) and (42) of the 
Council's Scheme of Administration relating to managing the finances of the 
Council and the organisation and management processes of the Council. 
 
 
2. RECOMMENDATIONS 
 
2.1 It is recommended that the Committee approves the: 
 
(i) implementation of a corporate Project Management Governance Policy 
for managing projects; and 
 
(ii) funding of £35,000 from Reserves for training as detailed in paragraph 
7.3 of the report. 
 
 
3. BACKGROUND 
 
3.1 On 25 May 2016, Full Council approved the establishment of a small dedicated 
Programme Management Office (PMO) team to support and administer 
appropriate projects and programmes (paragraph 7 of the draft minute refers). 
The report also referred to an associated draft policy to ensure there are 
consistent standards and disciplines applied to all projects and programmes. 
 
 
ITEM: 9 
 
PAGE: 2 
 
4. THE PROJECT MANAGEMENT GOVERNANCE POLICY 
 
4.1 A key responsibility of the PMO is the ownership and administration of the 
corporate Project Management Governance Policy (The Policy). A copy of The 
Policy is attached at Appendix 1. The Policy provides a framework for 
accountability and responsibilities, ensuring that project decision making is robust, 
logical and that projects provide value to the organisation. It offers a mechanism 
for ensuring that accurate and appropriate project status reports are presented 
regardless of the Service running the project or the type of project. 
 
 
5. RESPONSIBILITIES 
 
5.1 A core principle that applies for all projects, irrespective of the delivery 
methodology and terminology used, is that of accountability and responsibility. 
The point of accountability for a project is the Director of the Service that is leading 
on the project. Responsibility for ensuring that the project runs in compliance with 
corporate policy sits with the Project Sponsor (also referred to Senior Responsible 
Officer (SRO)). For construction projects, this role is sometimes known as the 
Project Owner - but the responsibilities are the same. It is acceptable for the 
Director to also have the role of Project Sponsor. The PMO will support all 
accountable and responsible officers. 
 
5.2 The governance hierarchy, as shown in the diagram below, outlines the flow of 
reporting and decision making. The PMO will support this process. The hierarchy 
is based on existing high-level governance arrangements as there seems to be 
little benefit in creating a new structure. Instead, the roles of the various bodies 
will be defined more clearly. The exception is the Transformation Programme 
Board which replaces the defunct DBS Programme Board. 
 
5.3 Each programme will comprise of component projects. Each project will have a 
Project Board. The Project Sponsor/SRO is responsible for setting up and 
chairing the Project. The Project Sponsor/SRO must ensure that all the 
responsibilities assigned to the Project Board are met. Whilst these 
responsibilities may be devolved to the Project Manager, accountability remains 
with the Project Sponsor/SRO. The resource, grade and knowledge associated 
with each role will vary depending on the project. The corporate PMO will support 
all roles. 
 
5.4 The Project Board will provide assurance to the relevant higher level Programme 
Board that appropriate risk mitigation plans are in place for all project risks, 
regularly monitor the viability of the mitigation and report any exceptions. The 
PMO will facilitate this process. 
 
ITEM: 9 
 
PAGE: 3 
 
 
 
 
 
6. PROCESS 
 
6.1 A critical element of The Policy is the Gateway Process. Abbreviated Gateway 
formats are already used by ICT, Procurement and the Asset Management Group. 
The process is built on the following elements: 
i. Key Principles - the basic rules that affect all projects during the project life 
cycle. The 6 major stages of a project lifecycle – Conception, Definition, 
Initiation & Planning, Delivery, Closure and Post Project Review. 
 
ii. Structure, Accountability and Responsibilities - who does what and what 
role they play in project governance. 
 
iii. Governance process (Gateways) - defines the trigger points for mandatory 
governance checks on project status and the evidence required for 
governance approvals. 
 
iv. Project Reporting and Standard Processes – defines the reporting 
requirements and the acceptable way of working within the governance 
framework. 
 
ITEM: 9 
 
PAGE: 4 
 
v. Prioritisation - doing the right projects recognising the organisation’s 
capacity constraints to undertake the work. 
 
vi. Capability - It creates the environment to do the selected projects and 
programmes right and the development and maintenance of an effective 
capability. 
 
vii. Continuous Improvement - to validate the usefulness and efficiency of the 
ongoing work which feeds back into the selection and capability aspects of 
governance. 
 
6.2 Although the key principles are seen as best practice for all projects, in order to 
not stifle through bureaucracy the process will apply specifically and will be 
enforced for: 
 Requires significant capital or revenue investments – significant investment 
means having a value of £1M or more over the lifecycle of the project; or 
 Projects whose implementation exhibits a high level of complexity, 
ambiguity, tension, uncertainty or risk as identified during categorisation in 
accordance with Appendix 4; or 
 Projects that are forecast to deliver substantial cost savings as identified by 
the Council’s Corporate Management Team (CMT). 
 
6.3 All projects are categorised as Basic, Intermediate or Strategic. The category 
determines the process, governance and reporting requirements. The criteria to 
be considered for categorisation are Corporate Impact (including £ value) and 
Complexity. Projects will be rated against each factor using a low/medium/high 
rating. 
 
6.4 The information required for each stage of the process is determined by the 
category of the project. The table below outlines the documentation required at 
each gateway for intermediate and strategic projects. 
 
 
Concept………………………...”Project Life Cycle”………………….Closure 
ITEM: 9 
 
PAGE: 5 
 
6.5 For clarity and to help understanding, definitions of a project, programme and 
programme management are detailed below (APM Body of Knowledge, 6 th 
Edition): 
 
 A Project is a unique, transient endeavour, undertaken to achieve planned 
objectives, which could be defined in terms of outputs, outcomes, benefits or 
strategic objectives. 
o Outputs - are the tangible or intangible products typically delivered by 
the project. 
o Outcomes – are the changed circumstances or behaviours that result 
from the use of an output 
 
 A Programme is a group of related projects and change management 
activities that together achieve beneficial change for an organisation. 
 
 Programme Management is the coordinated management of projects and 
change management activities to achieve a beneficial change. 
 
6.6 To further help address any ambiguity defininga project, the table below helps 
identify the key differences between a Project and “Business As Usual” (BAU): 
 
 
Project 
 
 
Business As Usual 
 Unique 
 Revolutionary 
 Temporary 
 Specific objectives for change 
 Involves uncertainty 
 Special team 
 Dynamic environment 
 Repetitive 
 Evolutionary 
 On going 
 Based on experience 
 Established/experienced 
personnel 
 Stable environment 
 
7. STANDARDS 
 
7.1 For specific projects assessed as intermediate or strategic, there needs to be an 
agreed programme and project management standard. The adoption of a 
standard and shared approach helps develop a corporate understanding. The 
Office of Government and Commerce (OGC) Prince2 © and Managing Successful 
Programmes © standards were used for the DBS programme. 
 
7.2 This also applies to other facets of project administration and organisation 
including administration processes, analysis, change techniques and compliance 
with local policy and procedures (eg Risk Management). The table at Appendix 2 
below outlines the recommended standards. 
 
7.3 Training and skills development will be co-ordinated by the PMO. An assessment 
of the training needs/standards confirms that the requirement can, in the main, be 
developed and delivered by council specialists and internal training teams 
reducing the need for external providers. However, accredited training and 
ITEM: 9 
 
PAGE: 6 
 
specialist input will still require external input. The cost of training for the first year 
is estimated to be £35K. This is forecast to reduce for subsequents years. 
 
 
8. SUMMARY OF IMPLICATIONS 
 
(a) Moray 2026 - A Plan for the Future/ Service Plan 
 
The policy will aid the successful delivery of the Corporate Plan; Moray 
Integrated Joint Board’s Strategic Plan and Moray Community Planning 
Partnership’s Moray 2026 – A Plan For the Future. 
 
(b) Policy and Legal 
 
The Project Management Governance Policy will will reinforce compliance 
and improve performance, productivity and efficiency. 
 
(c) Financial Implications 
 
A revenue budget of £35K is required to funds the skills development and 
specialist training aspect of the policy. 
 
(d) Risk Implications 
 
The risk of not approving the proposals in this report is continuing to employ 
ad hoc arrangements to the management and delivery of the projects and 
programmes and therefore not delivering the improvements and achieve the 
required savings. 
 
(e) Staffing Implications 
 
There are no staffing implications. 
 
(f) Property 
 
(g) There are no property implications. 
 
(h) Equalities 
 
There are no equalities issues contained in this report. 
 
(i) Consultations 
 
The Corporate Management Team (Tier 1), Senior Management Team 
(SMT); Leadership Forum (Tiers 1-3) have been involved in the compilation 
of this report. Comments have been incorporated and there is agreement 
with the content. 
 
 
 
 
ITEM: 9 
 
PAGE: 7 
 
9. CONCLUSION 
 
9.1 The implementation of a new corporate approach to project management 
will bring control and discipline to high risk, large investment and complex 
efficiency projects. It has been developed using existing best practice and 
lessons learnt from other local authorities. It provides a framework for the 
Council to work within. It defines roles, responsibilities, procedures and 
controls with the aims of enhancing successful project delivery. 
 
 
 
 
 
 
 
 
Author of Report: David Morris, Senior Programme Manager - 3801 
 
Background Papers: Held by author (DBS SharePoint) 
 
Appendix 1 
 
 
The Moray Council: 
Project Management Governance Policy 
 
Framework for Project Sponsors, Project Boards, Senior 
Management and Elected Members. 
 
 
 
 
 
 
 
 
 
Document Details & Version Control 
Author: 
D Morris 
Action: 
Draft for consultation 
Version: 
v.01 
Date: 
27 April 2016 
D Morris Amendments: Property (EM), Finance 
(LP) & Training (MK) comments. 
v.02 29 April 2016 
D Morris Amendments: Procurement (DB), 
Consultancy (DG), Ex DBS PMO (MA) & 
Property (MM) comments. 
v.03 09 May 2016 
D Morris Final. For approval V1.0 10 May 2016 
 
ITEM: 9 
 
PAGE: 9 
 
1. Introduction – Projects Defined 
1.1 This policy defines a framework for the governance of project management within the Moray Council (TMC). 
It stipulates standard processes and governance requirements. It is based on the Prince2 Project management 
methodology, aligned with the Scottish Government Construction Procurement Manual and the Office of 
Government Commerce (OGC) Gateway framework. Projects involving procurement will also follow the standards 
set out in TMC Financial Regulations (Procurement Procedures). It builds on existing processes and guidance in use 
within the Council and intends to re-use existing controls where they have been shown to be effective. It will be 
subject to full review after 12 months of publication so that any improvements / lessons learned from initial 
implementation can be incorporated. 
1.2 There are differences in the management and governance arrangements between capital projects (Property 
and Infrastructure) and other projects, for instance due to the specific requirements for construction projects such as 
the Construction (Design and Management) Regulations 2015. The framework is intended to cover all circumstances 
with the flexibility to adapt the principles to suit the scale and type of project. 
1.3 The framework is designed to ensure that the right environment for project success is created within the 
Council. It will define structures and processes that will ensure that projects are managed well and in accordance 
with this framework’s key principles; that projects are aligned to the Council’s strategic objectives, and that any 
projects exhibiting conditions of failure are identified on time and appropriate corrective and mitigating measures 
are put in place. 
1.4 Project management governance provides a framework for accountability and responsibilities, ensuring that 
project decision-making is robust and logical and that projects provide value to the organisation. It offers a 
mechanism for ensuring that projects are conceived and implemented in accordance with agreed standards and 
regulations. 
1.5 A Project, within TMC context, is defined as: 
 A unique, transient endeavour, undertaken to achieve planned objectives, which could be defined in terms 
of outputs, outcomes, benefits or strategic objectives. 
o Outputs - are the tangible or intangible products typically delivered by the project. 
o Outcomes – are the changed circumstances or behaviours that result from the use of an output. 
The decision to implement a planned piece of work as a project is the responsibility of Corporate Directors and the 
decision must be informed by the category given to the project as described at Point 5.1. 
1.6 For the purpose of this policy, governance could be applied at a programme level if felt to be appropriate by 
the Corporate Director. A Programme, within TMC context, is defined as: 
 A group of related projects and change management activities that together achieve beneficial change for an 
organisation. 
This would mean, for instance, that a programme consisting of a number of projects across Moray could be treated 
as one entity under this policy, meaning that the policy would not have to be separately applied for each individual 
project within the programme. 
1.7 Whilst the standards and processes articulated in this document are seen as best practice for all projects 
within the organisation, compliance will onlybe enforced and monitored for projects that: 
 Requires significant capital or revenue investments – significant investment means having a value of £1M or 
more over the lifecycle of the project and any resulting contract/s as set out in the TMC Procurement Strategy 
(Procurement Procedures). 
 
 “Strategic” projects whose implementation exhibits a high level of complexity, ambiguity, tension, uncertainty or 
risk as identified during categorisation in accordance with Appendix 4. 
ITEM: 9 
 
PAGE: 10 
 
 
 Projects that are forecast to deliver substantial cost savings as identified by the Council’s Corporate 
Management Team (CMT). 
 
2 TMC Project Management Governance Principles 
2.1 To provide an appropriate level of proportional and consistent governance across the Council, the project 
life-cycle and associated processes are underpinned by the following key principles: 
2.1.1 Accountability and Responsibility: A single point of accountability will exist for all projects within a Service 
area. This point of accountability will be the aligned Corporate Director, while responsibility for ensuring that an 
individual project is run in compliance to this framework lies with the Project Sponsor (also referred to within TMC as 
Senior Responsible Officer (SRO)). It is acceptable for the Director also to be the Project Sponsor. The practical 
application of the framework and the actual management of the project will be undertaken by a suitably 
trained/qualified Project Manager. 
2.1.2 Openness and Transparency: Project performance will be visible across the different levels of governance, 
and reporting will be consistent, with a minimum data requirement set for all project status reports. 
2.1.3 Financial Management and Cost Transparency: All projects will adhere to the Council’s Financial 
Regulations. Whole life-cycle costs will be estimated for all projects, including internal staff costs, and updated cost 
information will inform the business case and the tender process. Changes to baseline costs will be documented. 
2.1.4 Conduct of Procurements: All procurements carried out either as the key objective of a project or as a 
subsidiary activity must be carried out in accordance with TMC Financial Regulations (Procurement Procedures). 
2.1.5 Continued Business Justification: The project Business Case in the case of change projects, and the Quality 
Plan (suite of technical specifications and plans) in the case of infrastructure projects, will be updated and reviewed 
at key decision points. Projects will only progress if the viability of the Business Case or Quality Plan is confirmed and 
assumptions validated. 
2.1.6 Technically assured and well managed projects: All projects will be supported by sound technical and 
specialist advice and managed by suitably qualified and experienced Project Managers supported by appropriate 
project teams. Projects involving procurement will be supported by a lead Procurement Officer. When applicable, 
adequate feasibility studies will be completed with robust scoping and where a reference site is used, comparison 
will be based on requirements and accrued benefits. 
2.1.7 Risk Management: All projects will have a well-defined risk and issues management strategy and a 
consistent approach to risk and issues reporting. 
2.1.8 Well-defined roles and responsibility: Roles within projects will be well defined with training and support 
provided to ensure that obligations under this framework are understood and embedded within projects. It is 
compulsory for all members of Project Boards and all Project Sponsors to complete a training session on this 
framework before serving on a Project Board. For projects involving procurement, all those involved in the 
procurement activities must also have current procurement authorisation at the appropriate level and have had the 
necessary procurement training. 
2.2 Supporting these principles are the monitoring checks and processes defined by this framework. These 
checks are carried out through a number of decision points that are based on the OGC Gateway framework. These 
check-points and processes are described in Section 5.0. 
2.3 These checks and processes will ensure that the right environment and culture for project success is 
maintained across the Council with emphasis on three key project variables – the quality of the project deliverables 
and benefits (scope), the overall cost of the project, and the project time-scale. 
ITEM: 9 
 
PAGE: 11 
 
3 Project Life-cycle 
3.1 All projects regardless of complexity, scale or subject do share common features that allows for the design of 
a generic life-cycle. This life-cycle shows the different stages that projects progress through and are used as 
mandatory governance checkpoints. 
3.2 The project life-cycle will have 6 stages; Conception, Definition, Initiation & Planning, Delivery, Closure and 
Post Project Review. These stages apply to all transformational saving projects, capital projects (property and 
infrastructure), ICT projects and other services-led projects within the Council. To steer a project through the project 
life-cycle, a Project Board must be assigned to manage the project – this is either done by forming a new Project 
Board or by assigning the project to an existing Project Board with relatable project objectives. 
3.3 The full make-up of a Project Board under Prince2 is described in Appendix 1, but there will be situations 
where a Project Board consisting of just a Sponsor and Project Manager/Procurement Lead will be sufficient. It is the 
responsibility of the Project Sponsor to ensure that the make-up of the Project Board adequately reflects the 
requirement for good project control but at the same time is not disproportionate to the scale of the project. 
3.3 Conception is the stage at which an idea is created or a need (a requirement for change) is identified and a 
strategic decision is made as to whether or not it should be pursued. 
3.4 Definition involves a full exploration of the change requirement and the development of the associated 
business case; the scope for the project is considered and procurement approaches investigated. 
3.5 Initiation and planning – A full plan for implementing the change is created and a contract or contracts 
awarded to any 3rd party suppliers as a result of commercial competitions carried out as part of the project. This is 
the Production Information and Tender stage for capital project procedure. 
3.6 Delivery – This is the implementation stage for the project, where the project objectives are delivered and 
responsibility handed over from project to the business. 
3.7 Closure – the project is drawn to a close and a review is carried out to confirm if there are any deliverables 
that have yet to be delivered and to formally end the project organisation. 
3.8 Post Project Review – this is the stage at which the project is reviewed to confirm achievement of expected 
benefits and to ensure that lessons learned are identified and propagated through the organisation. 
3.9 A diagrammatic representation of the project life cycle is shown below with the appropriate documentation and 
governance objectives for each stage: 
ITEM: 9 
 
PAGE: 12 
 
 
Diagram 1 - Project Life Cycle 
3.10 Current Capital project life-cycle matched to the generic project life-cycle: 
 
Diagram 2 - Project Life Cycle matched to Capital Project Life-cycle. 
 
4 Governance Structure and Responsibilities 
4.1 The governance structure is a hierarchical arrangement of lines of accountability for project governance 
within the Council. It shows how information about the management of a project’s status, risk and issues flows 
between the different levels of responsibility. 
4.2 CorporateDirectors through Service Management Teams (SMT) or, where in place, existing high-level 
Governance Boards (HGB) will act as the single point of accountability for all projects within that Service. 
4.3 Whilst overall accountability for enforcing/ensuring compliance rests with the Corporate Director/High-Level 
Governance Boards (HGB) and/or Service Management teams, responsibility is devolved to the Project Sponsor and 
the Project Board for each project. 
4.4 Service Directors will ensure that an appropriate report is forwarded to the relevant Strategic Committee. 
These triggers are defined in Section 5. 
4.5 The diagram below shows the full reporting structure for project management governance within the 
Council: 
ITEM: 9 
 
PAGE: 13 
 
Diagram 3 - TMC Project Management Governance Structure 
4.6 For construction projects, the project management team structure defined within the Scottish Government 
Construction Procurement Manual will apply, with the “Project Owner” (also referred to within TMC as Senior 
Responsible Officer (SRO)) responsible for ensuring that the level of governance defined within the Council project 
management governance framework is implemented. Table 1 below maps the roles within the Scottish Government 
Construction Procurement Manual to the Council’s Project Management Governance Framework. Appendix 2 shows 
the full project team structure for the Scottish Government Construction Procurement Manual. 
Project Management 
Governance Framework 
Policy Roles 
Scottish Government 
Construction Procurement 
Manual Roles 
Moray Council 
Terminology 
Strategic Committees Investment Decision Maker 
Corporate Director/High-level 
Governance Board (HGB) 
Investment Decision Maker 
Project Sponsor Project Owner Senior Responsible Officer (SRO) 
Project Board members 
Project Manager 
Senior Supplier 
Senior User 
Project Board members 
Project Manager 
Project Sponsor 
Service User Representative 
 
 
 
Client 
Technical assurance – Service 
level implementation 
Client Adviser Client 
Project Team – Service level 
implementation (not defined 
within framework) 
External consultant Project 
Manager / Consultants / 
Contractors / Supplier 
 
Table 1 – The Scottish Government Construction Procurement Manual roles within TMC Project Management Governance structure. 
4.7 Governance Responsibilities. This defines the governance responsibilities at the different layers of the 
governance structure: 
ITEM: 9 
 
PAGE: 14 
 
4.7.1 Elected Members – Strategic Committees 
a) The Strategic Committees will authorise the investment decision of appropriate projects in accordance 
with TMC Financial Regulations. 
b) The Strategic Committees will provide independent and objective scrutiny of projects that are forecast to 
go above the defined tolerance level (typically 10%), ensuring that sound financial decisions are made. 
c) They will receive regular monitoring reports from Corporate Directors and will scrutinise the reports to 
confirm that project/programme benefits are delivered within budget and timescale. 
4.7.2 Corporate Directors/ High-level Governance Boards 
a) Corporate Directors serve as the single point of accountability for their assigned projects. The High-level 
Governance Boards (HGBs) provide scrutiny and application of the governance process. 
b) Current High-level Governance Boards are: 
 Asset Management Group (AMG): chaired by the Corporate Director (Corporate Services) – 
responsible for ensuring the governance framework is applied for all capital projects and 
programmes within the capital plan. 
 
 Service Management Teams (SMT): Chaired by individual Corporate Directors – responsible for 
ensuring the governance framework is applied to all Service-led projects. 
 
 ICT Programme Board – chaired by the Head of Service (HR/ICT) – responsible for ensuring the 
governance framework is applied for all ICT projects and maintenance programmes. 
 
 Joint (Health & Social Care) Integration Programme Board (JIPB) – chaired by the Chief Officer 
(Health & Social Care) – responsible for ensuring the governance framework is applied for all 
integration projects. 
 
c) New High-level Governance Boards are: 
 The Project Initiation Board (PIB) – chaired by Corporate Director (Corporate Services), it will 
provide an initial strategic assessment of all project mandates ensuring that a project fits into the 
strategic and operational objectives of the Council, that it is not a duplication of work and that there 
are sufficient resources within the organisation to undertake the project. 
 
 Transformation Programme (TPB) Board: chaired by the Chief Executive - responsible for ensuring 
the governance framework is applied for projects that fall within the efficiency programme. 
 
d) The HGBs will provide governance assurance to the Strategic Committees – so that elected members can 
be assured that current and proposed projects have embedded the structure and processes defined within 
this framework. 
e) The HGBs will review project monitoring reports, confirming that there is continuous business 
justification for the project and will authorise gateway progression through the project life-cycle as 
necessary. 
f) The HGBs will review and authorise project variables and re-baseline recommendations from the Project 
Sponsor. (Re-baselining is when a remedial action has been taken to change the baseline figure of one or 
ITEM: 9 
 
PAGE: 15 
 
more of the variables of a project; for example when the delivery time-scale is changed to account for a 
revised implementation date.) 
g) The HGBs will provide support and advice in resolving issues and in implementing mitigations against 
risks. This may include providing independent assurance to Project Boards. 
h) Make decisions on tolerance levels. 
4.7.3 Project Sponsor: 
a) The Project Sponsor makes decisions with regard to management of the project. The Project Sponsor 
owns the business case and is responsible for providing continuous justification of the business case or 
quality plan to the HGB. 
b) Responsible for providing project status reports and exception reports to the HGB; making 
recommendation for gateway progression to the HGB. The recommendation will be supported by a stage 
report and a completed checklist (See Appendix 3) to show that all aspects of the project variables have been 
considered before a recommendation is made to the HGB. 
c) Work with the Project Board to ensure that proposed benefits are accrued and evidence of such benefits 
is captured. 
d) Makes recommendation on the re-baselining of project’s variables and demonstrate the astuteness of re-
baselining. 
e) Own the risk mitigation plans and project objectives. 
f) Ensure that a suitably trained Project Manager is assigned and that there are appropriate resources to 
deliver the project. 
4.7.4 Project Board: 
a) The Project Sponsor is responsible for setting up and chairing the Project. The Project Sponsor must 
ensure that all the responsibilities assigned to the Project Board are met. 
b) Whilst these responsibilities may be delegated to the Project Manager, true responsibility remains with 
the Project Sponsor. 
c) The Project Board will provide assurance to the relevant HGB that appropriate risk mitigation plans are in 
place for all project risks, regularly monitor the viability of the mitigation plan, and report any exception to 
the HGB. 
d) The Project Board will provide assurance to the HGB that the financial management of the project is 
within tolerance and report changes to baseline figures to the HGB. 
e) Seek technical assurance from the appropriate Service specialist team for theproject to ensure that 
proposed technical solution fits into the Council’s strategic goals. 
f) The membership of Project Boards will be only for officers that have completed the mandatory training 
course (to be developed) and ideally have experience. Project Boards may also have supplier representation 
when the supplier has been contracted to act as an agent for the Council or to provide specific advice 
relating to the requirements. The Sponsor is responsible for ensuring that they understand their role on the 
Project Board. 
 
 
ITEM: 9 
 
PAGE: 16 
 
5 The Governance Process – Governance Checkpoints 
5.1 It is the responsibility of Corporate Directors to ensure that all change initiatives within their Service are 
assessed against the criteria set in Section 1.7. If a change initiative is not run in accordance with the policy, the 
rationale must be evidenced as to why not. The impact/complexity categorisation matrix is at Appendix 4. 
5.2 The governance process provides the mechanism for the project management governance to exercise its 
responsibilities under this framework. The process is designed to confirm governance compliance during the key 
decision-making points within the project life-cycle. The principle is that these decision-making points are seen as 
gateways that are shut, and have to be proactively opened before a project can move forward. This is based on the 
OGC Gateway framework. Diagram 4 below is an overview of the process. 
Diagram 4 – Governance Process (High Level) 
5.3 There are 5 gateway points (G1 to 5) - the expectation for each gateway is specified in the Table 2 below. It 
is expected that the Project Board through the Project Sponsor will provide the required evidence to the HGB to 
demonstrate that the project is ready to progress through the gateways, and as a minimum in procurement projects 
the Sponsor/Board must approve the business case, project plan, strategy, and tender board report. 
OGC Gateway 
Descriptions 
Project 
Lifecycle 
Stage 
Evidence provided to the Project 
Initiation Board (PIB) / High-Level 
Governance Board (HGB) 
Outcome 
Gateway 1 (G1) 
Strategic 
Assessment and 
Business 
Justification. 
Project Initiation 
Board (PIB) 
Conception Evidence showing that a Mandate has 
been developed – to show the 
justification for the project; the scope, 
objectives, timeframe and timescales 
and initial estimates of costs and 
benefits. 
Completed Gateway 1 checklist – see 
Appendix 3 
 Approval to fully 
investigate and 
define the project. 
 Align to appropriate 
HGB. 
ITEM: 9 
 
PAGE: 17 
 
Gateway 2 (G2) 
Delivery Strategy. 
High-Level 
Governance 
Board (HGB) 
Conception Evidence showing that an Outline 
Business Case has been developed – to 
show the justification for the project; 
the scope, objectives, timeframe, 
options, timescales, risks assessment, 
estimates of costs and benefits. 
Completed Gateway 2 checklist – see 
Appendix 3 
 Approval to fully 
investigate and 
define the project. 
Gateway 3 (G3) 
Investment 
Decision. 
High-Level 
Governance 
Board (HGB) 
Definition Evidence showing that assumptions in 
the Outline Business Case have been 
validated and a Full Business Case has 
been produced – showing requirements 
specification (quality), cost, timescale, 
results of pre-market research, risks and 
issues and a procurement strategy. 
For infrastructure projects, evidence 
showing that a Quality Plan has been 
created and estimated project cost have 
been provided. 
Evidence that the Project Sponsor has 
nominated a Project Board. 
Evidence that nominated members of 
the Project Board have received formal 
training on the Council’s Project 
Management Framework Policy 
Completed Gateway 3 checklist – see 
Appendix 3 
 Approval to start pre-
market activities and 
create project 
implementation plan. 
Gateway 4 (G4) 
Prepare for 
delivery. 
 
High-Level 
Governance 
Board (HGB) 
Planning and 
Initiation 
Evidence showing that a Project 
Initiation Document (PID) has been 
completed and assumptions in the Full 
Business Case have been clarified and 
validated where necessary. 
For infrastructure projects, evidence 
showing that the Quality Plan has been 
reviewed – with project cost updated 
and that design review frequency has 
been agreed and verification plan is in 
place. 
Evidence showing that the project cost 
model and other assumptions has been 
reviewed. Where applicable, payback 
period and Return on Investment (RoI) 
strategy agreed. 
Evidence showing that risk and issues 
management approach has been 
 Approval to award 
contract and begin 
implementation of 
project delivery. 
ITEM: 9 
 
PAGE: 18 
 
agreed. 
Evidence of completion of appropriate 
competition via a tender board report. 
Completed Gateway 4 checklist – see 
Appendix 3 
Gateway 4a 
(G4a) 
 
Project 
Commencement 
 
High-Level 
Governance 
Board (HGB) 
Delivery On-going process. Evidence showing 
that the project is progressing within 
tolerance and that risks and issues are 
being managed. 
Evidence showing that the business 
case has been reviewed and updated 
and project cost model is still valid. 
Evidence showing that risk and issues 
management strategy is working. 
Evidence showing that project is 
delivering milestones. 
 
For infrastructure projects, evidence 
showing that the Quality Plan has been 
reviewed and that design review is 
progressing as planned and project 
budget is within tolerance. 
 
Completed Gateway 4a checklist – see 
Appendix 3 
 Approval to go live / 
proceed. 
Gateway 5 (G5) 
 
Operational 
Review & Benefit 
Realisation 
 
High-Level 
Governance 
Board (HGB) 
Closure / 
Post Project 
Review 
Evidence showing that the project has 
delivered the key deliverables and 
immediate benefits are been realised. 
 
Lessons Learned. Evidence confirming 
that longer term project’s benefits have 
been delivered. 
 
Completed Gateway 5 checklist – see 
Appendix 3. 
 Approval to close 
project and 
commence post 
project review / 
benefit realisation 
Table 2 – Mandatory Governance Checkpoints 
5.4 Information will be passed up the governance structure through Project Status Reporting; these reports will 
be triggered by the mandatory check-points in the governance process and by exception when a project is forecast 
to exceed a defined tolerance level. 
5.6 Mandatory trigger points for reports to committees are before check-point G3 – project definition stage and 
check-point G5 –post project reviews. 
5.7 Exception reports will be triggered by the following conditions – 
• Explicit request from Strategic Committees; 
• Explicit request from Audit and Performance Review Committee; 
• If there is a significant (above 10%) increase in initial cost estimates between the G3 and G4 review. 
ITEM: 9 
 
PAGE: 19 
 
• During the Delivery Stage when a project is forecast to exceed defined tolerance level in respect of time or 
benefits to be delivered. 
6 Project Status Reporting 
6.1 Project Status Reporting provides the monitoring and control functions that enable the critical assessment of 
the ongoing viability of the project and reports on the overall progress of the project. 
6.2 It defines how the overall status of projects, risk and issues are communicated across the governance 
structure. 
6.3 The Project Sponsor is responsible for providing project status reports to the HGB. The Corporate Directors 
are accountable for providing reports to Elected Members while the Project Sponsor is responsible for generating 
the report. 
6.4Reports to Elected Members will be provided prior to mandatory check points G3 and G5 and when 
tolerance levels are forecast to be exceeded. Check points are as described in Section 5 of this framework. Project 
Sponsors will be expected to raise exception reports between gateway points when required. 
6.5 Project Sponsor will provide project status reports to the HGB at every check-point and will provide 
exception reports when a project requires remedial action or when a project overall RAG status is RED. The report 
will be circulated to members of the HGB 3 days before a HGB meeting. 
6.6 The Project Manager will provide regular project status reports to the Project Board. 
6.7 A project status report regardless of gateway point will contain the following minimum dataset: 
• Project Life-cycle Stage 
• Project current Gateway 
• Over-all Project RAG status 
• Project Risk RAG status 
• Project Issue RAG status 
• Statement of validation of business case or quality plan 
• Milestones update 
• Financial update 
• Risk and issues update 
• Changes and comparison to original baseline figures 
• Changes to original impact assessments. 
• Project Sponsor name and official designation 
• Project Sponsor Recommendation 
 
6.8 If a project status report fails to provide the minimum dataset, then the report will be considered as in-
complete and the Project Sponsor would be require to re-submit the report with the missing data. 
 
6.9 All project status reports will be accompanied by the appropriate stage checklist (See Appendix 3) e-signed 
by the Project Sponsor, confirming that due diligence has been completed for key aspects of the project. 
 
6.10 If, after going through a check-point, any changes to baseline figures outside of the agreed tolerance levels 
of the project would require a new gateway review for the current gateway. 
6.11 BRAGG Definitions: 
ITEM: 9 
 
PAGE: 20 
 
6.11.1 Black, Red, Amber, Green, Grey (BRAGG) provides an expanded traffic light visual representation of the 
current state of a reported item against the current baseline. Black denotes “complete” whilst Grey is “not started”. 
The overall purpose of a Red, Amber, Green (RAG) status is to indicate the level of attention and the action required 
at a particular point in time. RAG definition will be applied and be reported separately for the overall project status, 
project risk management and for project issues. 
6.11.2 Overall RAG status must generate consistent response across all projects within the Council, hence the 
overall RAG system has been defined against expected responses. 
6.11.3 The overall RAG status for a project must be a cumulative of the RAG statuses of three areas of project 
objectives – quality (scope), cost and time. Hence a project can’t be RAGGED green if any of the three variances are 
RAGGED at any other colour. The project would be RAGGED with the worst RAG status. 
6.11.4 Project risks are to be RAGGED against the level of control that the Project Board have on the mitigation 
plan. This will be based on the standard Red, Amber and Green levels. For clarity, risk can be defined as an uncertain 
event or set of events, which should it/they occur, will have an effect on the ability to deliver a project. Refer to 
Section 7.5 for more details. 
6.11.5 Project issues are to be RAGGED against implementation of a resolution i.e. an indication of whether issues 
are under control or not. This will be based on the standard Red, Amber and Green levels. For clarity, issues are 
unplanned events or conditions that have already happened or are currently happening and that have impacted or 
are currently impacting on the objectives of the project. Refer to Section 7.5 for more details. 
6.11.6 RAG definition for OVERALL Project Status and expected response: 
RAG 
Status 
Quality (Scope) Cost Time Response 
Red Deviation 
imminent or has 
occurred on the 
agreed project 
objectives and 
scope. 
Imminent 
increase above 
the 10% 
tolerance 
threshold on 
the estimated 
project cost for 
that particular 
milestone or for 
the whole 
project. 
Project on 
course to miss 
milestones 
delivery dates 
or projected 
closure date. 
 Project Sponsor to escalate to 
High-Level Governance Boards 
(HGB) with an Exception Report. 
 HGB to inform appropriate 
strategic committee if committee 
level tolerance threshold are 
broken. 
 High level remedial action 
required and discussion with the 
Service Director for the 
appropriate action. 
Amber Likely imminent 
deviation from 
the agreed 
project 
objectives. 
Likely imminent 
increase on 
estimated 
project cost for 
that particular 
milestone 
delivery or for 
the whole 
project. 
Likely imminent 
issues with 
delivery 
timescale; a 
milestone date 
may be missed. 
 Raise awareness with HGB. 
 Project Board to take remedial 
action. 
 Project to be monitored and 
project’s critical path reviewed. 
Project Board to start remedial 
action. 
ITEM: 9 
 
PAGE: 21 
 
 Project Board to review 
assumptions on business cases, 
cost benefit report and review 
project’s critical path and analyse 
impact. 
Green No deviation 
expected from 
the project 
objectives 
No deviation 
expected from 
the estimated 
project cost. 
No issues with 
timescale; 
current project 
milestone will 
be delivered in 
time. 
 No action required. 
Table 1 - RAG Definitions for Project Status Reporting 
 
6.11.7 RAG definition for RISKS measured against Council’s control of the mitigation plan. 
 
RAG 
Status 
Description Response 
 
Red No mitigation plan in place or the Project 
Board has zero control over the mitigation 
plan or no control over key critical paths of 
the project or mitigation plan is unknown 
because the mitigation information is not 
available. 
 Project Sponsor/Board to engage with 
stakeholders, re-assess the project’s 
critical pathways and identify contingency 
plans. 
 Update risk register accordingly. 
 Project Sponsor to escalate to HGB. 
Amber Mitigation is partly in place but does not 
cover end to end management of the risk as 
the Project Board does not have “managed 
control” of all aspects of the risk. 
 Project Sponsor/Board to engage with 
stakeholders, re-assess the project’s 
critical pathways and identify contingency 
plans. 
 No escalation required. Update risk 
register accordingly. 
Green Mitigation plan in place and all aspect of the 
risk can be control by the Project Board. 
 Continue to monitor the risk and update 
risk register accordingly. 
Table 2 - RAG Definitions for Project Risks reporting 
 
 
6.11.8 RAG definition for ISSUES measured against resolution 
 
RAG 
Status 
Description Response 
Red No resolution identified yet or resolution has 
impact on business case. 
 Escalate to the HGB. 
 Project Sponsor/Board to engage with 
stakeholders, re-assess the project’s 
critical pathways and business case. 
ITEM: 9 
 
PAGE: 22 
 
 Service Director to consider Exception 
Report for Strategic Committee. 
Amber Resolution identified but problem with 
implementation. 
 Project Sponsor/Board to engage with 
stakeholders 
 Escalate to the HGB. 
Green Resolution identified and implementation in 
progress. 
Project will be able to proceed soon with 
limited impact. 
 Maintain on Project Log and monitor as 
on-going. 
Table 3 - RAG Definitions for Project Issues reporting 
6.11.9 RAG Status on re-baselined Projects 
a) Re-baselining is when a remedial action has been taken that changes the baseline figures of one or more 
ofthe variables of a project; for example when the delivery timescale is changed to account for a revised 
implementation date or if there is a project cost increase with budget increase agreed through the relevant 
HGB or Strategic Committee. It is essential that the RAG status thereafter reflects these changes. 
b) A new RAG status reflecting the current state of the project metrics measured against the new baseline 
value is to be reported. However, in order to provide a complete project life-cycle view, all re-baselined 
projects are to be reported on a table – showing original baseline values against new baseline values and the 
date that the new baseline was applied. 
c) This table will form part of the report to the HGB and relevant committee. The report would show the 
original baseline figure. 
7 Standard Processes 
7.1 These processes have been defined to help implement the key principles within this framework consistently 
across the Council. 
7.2 Requirements Specification and Benefit Mapping: 
 
7.1.1 Requirements Specification (training requirement to be developed) is the capturing and documenting of 
what a project is meant to achieve or deliver. It is the key to aligning project objectives to the benefits that the 
business is seeking. Failure to specify requirements accurately is one of the known high risks to project success. 
 
7.1.2 A comprehensive Requirement Specification document requires consultation with all key stakeholders: - this 
can be achieved via benefit-mapping workshops using the Benefit toolkits (training to be developed) or via 
requirement workshops with stakeholders. For procurement projects a User Group will be set up to define the 
requirement, procurement strategy for the project and to develop supplier selection and contract award criteria. 
 
7.1.3 The requirement specification process will take place at the Project Definition stage helping to inform the 
outline business case and forms one of the key metrics for measuring benefit accruals. 
 
7.1.4 The process will help understand the requirements of the Service; it will help define the scope of the project 
and help identify potential dependencies. The final outcome is a Requirement Specification document. 
 
ITEM: 9 
 
PAGE: 23 
 
7.1.5 The Requirement Specification document must always specify a minimum viable product/outcome that will 
deliver the desired benefits. This can be a functional product or a quantifiable benefit like cost-saving or 
performance improvement. 
 
7.1.6 A clear link between business requirements and functional requirements must be documented as this helps 
validate the minimum viable product/outcome description. Functional requirements describe specific tangible 
functionality of a product. 
 
7.1.7 It is recognised that most projects require a procurement exercise so the corporate procurement team must 
be involved at Gateway 2 (G2). In the case of capital projects (property and equipment/infrastructure), corporate 
standards relating to procurement will apply. 
 
7.1.8 Technical requirements must be validated by Service-based technical advisory groups where available. 
7.2 Development of Full Business Case/Quality Plan: 
7.2.1 The Business Case is the business justification for a project. It demonstrates why and how the requirement 
specification will help us meet a business need. No project should commence without a business case or quality plan 
in the case of infrastructure projects. Quality Plan is a suite of documents capturing the approach to specification 
and delivery of an infrastructure project (scheme). 
7.2.2 Business Case/Quality Plan captures information on expected benefits/deliverables and estimate cost of 
delivering the benefits/deliverables. 
7.2.3 The Business Case is owned by the Project Sponsor and updated throughout the project so as to confirm the 
continuous viability of the project. 
7.2.4 A Mandate and Outline Business Case (OBC) are created at the Project Conception and Definition stage with 
several assumptions made. Validation of these assumptions and dependences must be completed before a full 
Business Case is signed off by the Project Board. For Infrastructure projects, a Quality Plan will serve the purpose of 
a Business Case within this framework. 
7.2.5 The Business Case is reviewed at every gateway by the HGB and its validity confirmed in line with the 
principle of continuous business justification. Hence a Business Case will only be deemed valid until the date of a 
checkpoint. This applies to Quality Plan in that it is only valid until the next design review date. 
7.3 Project Financial Management 
7.3.1 Project financial management looks at the management of the financial aspects of a project. It covers the 
management of the project’s budget; spend profile and the management of the procurement of deliverables within 
the project. 
 7.3.2 The Project Sponsor has overall responsibility for the financial management of the project and must ensure 
compliance with TMC Financial Regulations. 
7.3.3 The Project Sponsor must ensure that a business case has been established. This should examine all of the 
possibilities for meeting the Requirements Specification. In respect of projects with a value in excess of the OJEU 
tendering threshold, the Sponsor will be supported by a lead procurement officer. 
7.3.4 The Project Sponsor will provide assurance that the cost model on which financial and budgetary 
assumptions about the project is based has been validated. This assurance will be provided through continuous 
validation of the business case at every governance decision check-point. The assurance reviews will be 
ITEM: 9 
 
PAGE: 24 
 
documented, with decisions recorded, and will be undertaken by the HGBs. For significant projects, an HGB may 
consider an external independent project review to be necessary. 
7.3.5 The cost model will cover the whole life-cycle cost of a project; including the cost of project management 
products, staff costs, contractors/suppliers cost, finance costs, efficiencies and income. 
7.3.6 Where a project is funded from an external non-Moray Council fund, the Project Sponsor will ensure that the 
terms and conditions of such funding does not negate the principles of the Council’s financial regulations. 
7.3.7 Where project funding and implementation involves “arm’s length external organisations” or Community 
partnerships group or external grant, the Council’s Financial Regulations shall take precedence over all other 
arrangements. 
7.3.8 At mandatory decision check-points – Gateways 3 and 5 - the Project Sponsor will provide reports to the HGB 
and to the appropriate Strategic Committee identifying the proposed source of funding for a project and the 
estimated cost. If the project cost is forecast to increase for more than 10% at any point, then the Project Sponsor 
will seek approval from the Strategic Committee to incur the increase. 
7.4 Project Procurement 
 7.4.1 The Council’s procurement regulation is applicable to all project procurement exercises and it is as contained 
within Financial Regulations (Procurement Procedures). This provides an appropriate reference to all procurement 
matters. 
7.4.2 Project Sponsors must ensure that all members of the Project Team and Boards have undergone 
Procurement Training to the appropriate levels. 
7.4.3 Project Sponsors must ensure, in line with Financial Regulation 2015, before placing an order that: 
 The expenditure is an item or service that is within the Council’s legal powers to incur. 
 The expenditure is within the relevant estimate provision. 
7.4.5 When applicable, the Project Sponsor as defined within this framework will assume the role of the “ProjectOwner” as defined within the Scottish Government Construction Procurement Manual and will ensure that relevant 
methodologies including but not being limited to competitive stages are initiated and corporate standards are 
maintained through the project life-cycle. The Corporate Director or the HGB will assume the role of the Investment 
Decision Maker. 
7.5 Risk Management 
7.5.1 The Council’s Risk Management Strategy (include link) details the corporate approach to risk management 
and sets out the Council’s risk management process. This strategy forms the underlying principle for the governance 
of project management risks within the Council. 
7.5.2 Risk can be defined as an uncertain event or set of events, which should it/they occur, will have an effect on 
the ability to deliver a project. This could be either a positive or negative effect. Risk Management is the activity 
required to identify and control the exposure to uncertainty which may impact the delivery of a project’s objectives. 
The aim is to restrict threats to within an acceptable level (Council’s “risk appetite”), and promote opportunities 
which will benefit the objectives of the project. 
ITEM: 9 
 
PAGE: 25 
 
7.5.3 Risk management is not about avoiding risk-taking but is about finding ways of managing the risks to the 
project to still be able to realise the benefits/objectives of the project. Risk identification and management is the 
responsibility of the Project Board, often devolved to the Project Manager. 
7.5.4 A Risk Register must be maintained for a project. The Risk Register will contain all risks that may impact the 
project; an action plan listing the mitigation plan – actions/control measures to manage the risks effectively and a 
RAG status for each risk as defined in Section 6. 
7.5.5 The Risk Register must be reviewed regularly by the Project Board and the risk status must be reported along 
the Project Governance Structure. Section 6 - Project Status Reporting Risk RAG defines the reporting requirements 
and the appropriate RAG definition for Project Risk. 
7.6 Issue Management 
7.6.1 Issues are defined as unplanned events or conditions that have already happened or are currently happening 
and that have impacted or are currently impacting on the objectives of the project. 
7.6.2 The management of issues requires a systematic approach to ensure that the full impact of the issue on the 
project is understood and managed appropriately. This approach involves capturing the issue, examining the impact 
of the issue, proposing a resolution and implementing the resolution. 
7.6.3 An Issue Log must be created for all projects. This Log will serve as the repository for all issues and allows 
issues to be tracked and responsibility assigned accordingly. The Issue Log will provide a description of the issue, 
what is affected, who owns the issue, resolution status of the issue and a RAG status for the issue. Section 6 – 
Project Status Reporting Issue RAG defines. 
7.6.4 The Project Sponsor will determine the priority for issues and would escalate them based on their RAG status 
to the HGBs through Project Report status. 
 
8 Support and Training in the use of the Framework 
8.1 To support the adoption of this framework within the Council, an online training course focusing on the 
application (to be developed / procured) of the framework will be provided for all staff. This is a compulsory training 
course (to be developed) for all project Sponsors/Owners and anyone that is required to serve on a Project Board. 
8.2 Tailored workshop on the implementation of the framework will be available on request. (to be developed). 
It is recommended that Project Sponsors request this workshop for new Project Boards. 
8.3 Training on the use of this framework will not prepare officers to become Project Managers, as Project 
Management is a recognised professional discipline. However, basic training on Project Management as a discipline 
is available through the corporate Employee Development team. External training is also available leading to formal 
qualification. 
8.4 It is the responsibility of the Project Sponsor to ensure that a suitably qualified and experienced Project 
Manager is appointed for their project. 
8.5. A training matrix matching accountability to training requirement will be designed to help Project Sponsor 
ascertain Project Board training need. This matrix will also provide a link to Project Management resource within the 
Council. 
ITEM: 9 
 
PAGE: 26 
 
 
Appendix 1 – Project Board Structure 
Together, the Project Sponsor, the Senior User(s) and the Senior Supplier(s) make up the Project Board. The Project 
Board has authority and responsibility for the project within the instructions set by corporate or programme 
management. A good Project Board should display four key characteristics: 
 
 Authority: The members of the Project Board should be senior enough within the corporate organisation to 
make strategic decisions about the project. As the Project Board is accountable for the project, the 
individuals chosen must have sufficient authority to make these decisions and provide resources to the 
project, such as personnel, cash and equipment. The managerial level required to fill the roles will depend 
on factors such as the budget, scope and importance of the project. 
 
 Credibility: The credibility of the Project Board members within the corporate organisation will affect their 
ability to direct the project. 
 
 Ability to delegate: A key part of the Project Board’s role is to ensure that the Project Manager is given 
enough space to manage the project by keeping Project Board activity at the right level. Project Board 
members should not be involved in the detail of how the project is managed, nor in the specialist content of 
the project. 
 
 Availability: Project Board members who meet all the above characteristics are of little value to the project if 
they are not available to make decisions and provide direction to the Project Manager. 
 
 
 
Project Board members are often from senior management positions, and their Project Board responsibilities will be 
in addition to their normal responsibilities. The concept of management by exception allows the Project Manager to 
keep them regularly informed of project progress but only requires decision-making at key points in the project. 
 
ITEM: 9 
 
PAGE: 27 
 
The frequency and detail of communication required by the Project Board during a project will be documented at 
project-level. Project Board members may require more detail or less frequent information at the start of the 
project. As the project progresses and the Project Board become more comfortable with the progress being 
achieved, the requirement for frequent or detailed Highlight Reports may reduce. It is important to review the level 
and frequency of reporting for each stage of the project. 
ITEM: 9 
 
PAGE: 28 
 
 
 Appendix 2 – Scottish Government Construction Procurement Manual – Project Team 
All major works projects should have an investment decision maker, project owner and project sponsor. This section 
explains their roles and responsibilities, along with those of the project manager and client adviser, and sets out the 
abilities and training they require, and their relationship to one another (Figure 1, below). 
 
 
ITEM: 9 
 
PAGE: 29 
 
 
Appendix 3 – Project Sponsor Check Lists 
 
Project Sponsor Check List: Gateway 1 – 
Strategic Assessment & Business Justification 
 
 
Consideration 
 
 
Yes / No 
Strategic Fit Does this prepare the council for future demands or 
requirements? 
 
Alignment with Moray2023 plan? 
Are the project drivers identified? (Legislation / Council 
Priority / Service Development / Efficiency / 
Maintenance) 
 
Corporate 
Capacity & Do-
ability? 
Do we have internal/external authority and stakeholder 
support for the project? 
 
High level governance, commitment and support? 
Realistic? 
Any dependencies identified? 
Impact of the 
Project 
List which services are affected? 
Outlines scale of impact? 
Fit with current organisation design? 
Timetable? 
Resources Do we have the skills and resources available to take this 
forward? 
 
Specialist input? (External/HR/ ICT) 
Funding 
Streams 
Funding requirement / availability to move to next 
Gateway? 
 
Risk Of doing the project? 
Of not doing the project? 
Value Case 
(Cost v Benefits) 
Is there value awareness – indicative outline? 
 
 
Equality Assessment as per council policy? 
 
 
Project Sponsor / PIB Check List: Gateway 2 – Delivery Strategy 
 
 
Considerations 
 
 
Yes / No 
Does this project contribute to wider Council and public sector strategies, 
within and outside the Council? 
 
Is the Outline Business Case and/or Quality Plan complete and robust – does 
it meet the needs of the business, is it affordable and achievable, future 
proof, will it deliver value for money? 
 
Are the requirements clear and unambiguous, and are they aligned with the 
ITEM: 9 
 
PAGE: 30 
 
programme to which the project contributes? 
Do we have enough commercial expertise to understand the supplier market 
capability and track record? 
 
Is the Project Plan, through to completion, sufficiently detailed and realistic? 
Do we have the right skills, capabilities and management expertise to ensure 
success? 
 
Have the critical success factors and desired benefits been identified and 
agreed with stakeholders? 
 
Have we explored a sufficiently wide range of options to meet the business 
need and identified a preferred way forward? 
 
Have we identified major risks, and do we have outline risk management 
plans? 
 
Can we confirm our planning assumptions, and are there plans, for the 
project in place for the next stage? 
 
Is there a clearly defined and agreed project management structure, with key 
roles and responsibilities identified? 
 
Do we have adequate risk and issue management plans and procedures? 
 
 
Project Sponsor Check List: Gateway 3 - Planning and Initiation 
 
 
Considerations 
 
 
Yes/No 
Can we confirm the Full Business Case and Benefits Realisation Plan, or the 
Quality Plan (for infrastructure projects), now that we have relevant 
information from prospective suppliers? 
 
Are the objectives of the project still aligned with those of its programme and 
wider organisational and public sector strategies? 
 
Is the recommended decision on delivery approach likely to deliver what we 
need on time and within budget, and will it provide value for money? 
 
For procurements: Have we followed the agreed procurement strategy, and 
have we met all statutory and procedural requirements? 
 
Do we have sound plans for managing implementation, risk and change, and 
are they agreed across the supply chain? 
 
Do we have continuing stakeholder support for the project? 
Have we addressed the technical implications, such as “buildability” for 
construction projects, and information assurance for IT-enabled projects? 
 
Do we have the expertise and resources to manage the supplier relationship, 
and are appropriate management controls in place? 
 
Have we agreed draft contracts and/or Service Level Agreements? 
 
ITEM: 9 
 
PAGE: 31 
 
 
 
 
Project Sponsor Check List: Gateway 4 – Delivery 
 
 
Considerations 
 
Yes / No 
 
Is the Full Business Case or Quality Plan still valid and unaffected by internal 
or external events or changes? 
 
Can we confirm that the Benefits Realisation Plan/Quality Plan is likely to be 
achieved? 
 
Are commercial/legal arrangements with the supplier up-to-date? 
Can we confirm that our plans for managing implementation, roll-out and 
operation are achievable and that we have the resources we need? 
 
Is the Project Initiation Document and management controls in place to 
manage the project through to operation? 
 
Do we have shared plans for managing risk, with contingency and business 
continuity plans in place? 
 
Has full user and system testing and/or commissioning been done to our 
satisfaction so that we can approve full implementation and roll-out? 
 
Is the business ready to implement the business change, with the necessary 
resources in place? 
 
Do we have client-side plans for managing the working relationship, including 
contract management, reciprocated on the supplier side? 
 
Are lessons for future projects being identified and recorded? 
 
ITEM: 9 
 
PAGE: 32 
 
 
 
 
Project Sponsor Check List: Gateway 5 - Closure and Post Project review 
 
 
Considerations 
 
Yes/No 
 
Was the Business Case justification for the project at Gateway Review 3 realistic, 
and are the expected benefits actually being delivered? For infrastructure 
projects – was the Quality Plan realistic? 
 
Have we done a post-implementation review or equivalent review of business 
benefits? 
 
Do we have the resources in place to manage the contract/SLA successfully and 
with continuity of key support personnel? 
 
If we have made agreed changes, can we be sure that they do not compromise 
any requirements of the procurement approach adopted (e.g. change of scope)? 
 
Is there still a business need for this contract/SLA? If circumstances have 
changed, are the service delivery approach and contract adapting to the new 
situation? 
 
Are we actively seeking to improve value for money and performance? 
Are we ready for the future, with plans for future service provision? 
Are we managing the working relationship effectively, with the right ‘intelligent 
customer’ skills? 
 
Are the exit strategy and arrangements for re-procurement still appropriate? 
Are we actively learning from experience and setting maturity targets? 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
ITEM: 9 
 
PAGE: 33 
 
Appendix 4 
 
PROJECT CATEGORISATION 
 
 
 
Each project is to be given a low / medium / high Corporate Impact assessment in accordance with 
the assessment criteria. 
 
 
 
Each project is to be given a low / medium / high Complexity assessment in accordance with 
the assessment criteria. 
The Impact and Complexity assessments are applied to the Category matrix. 
 
ITEM: 9 
 
PAGE: 34 
 
 
 
 
 BASIC Category - No project board required; change can be implemented as BAU. 
 INTERMEDIATE Category - Change should be implemented as a PROJECT but with 
 limited governance. 
 STRATEGIC Category - Change must be implemented as a project with full project 
governance in place. 
 
 
 
 
 
Appendix 2 - RECOMMENDED STANDARDS 
 
 Standard Software Comment 
Programme 
Management 
OGC Managing 
Successful 
Programmes 
(MSP) 
MS Products/ 
Locally produced 
templates. 
 Externally provided 
training. 
 DBS standard. 
Project 
Management 
(Basic / 
Intermediate 
projects) 
APMP / Agile (tbc) MS Products/ 
Locally produced 
templates. 
 Externally provided 
training. 
 Compliments MSP / P2 
Project 
Management 
(Strategic projects) 
OGC – Prince 2 
RIBA / SGCPM 
MS Products/ 
Locally produced 
templates 
 Externally provided 
training. 
 ComplimentsMSP. 
Gateway Process 
(Intermediate and 
Strategic projects) 
TMC Corporate 
Policy 
Use of locally 
administered 
SharePoint site. 
 Internal training. 
 Based on other council / 
OGC approach. 
Project Admin 
(All projects) 
TMC Corporate 
Policy (DBS 
Control 
Framework) 
Basic user 
standard 
MS Excel 
spreadsheets, 
MS word 
templates 
 Internal training. 
 
Project Plans 
(All projects) 
Basic user 
standard 
MS Project 2010  Expect PMO staff to be 
advanced standard. 
 External training. 
Process Mapping BCS Certificate in 
Modelling Business 
Processes 
(Foundation). 
Basic user 
standard 
MS Visio  Externally provided 
training (3-day course) 
Benefit 
Realisation 
TMC Corporate 
Policy (inc CMPs) 
Excel 
spreadsheet, 
word templates 
 Internal training. 
 
Change 
Techniques 
LEAN, Kaizan, 
BPR tools and 
techniques. 
BCS Foundation 
Certificate in 
Business Change 
Nil  Externally provided 
training (2-day course) 
 Externally provided 
training (2-day course)