Project Centre of Excellence Project Governance Framework · Project Centre of Excellence Project Governance Framework December 2015 This document defines the Thames-Coromandel District

Thames Coromandel District Council Governance Framework V1 1 Final December 2015 (2).docx Page 1 of 36

Project Centre of Excellence

Project Governance Framework

December 2015

This document defines the Thames-Coromandel District Council Project Governance Framework


Document Control

Revision History

Version Updated By Date Description

0.1 Vicky Thomas 29/09/2015 First draft version

0.2 Carole McKinley 02/10/2015 Review of V0.1 Draft

0.3 Ben Day, Steve Baker and Donna Holland 28/10/2015 Review and Feedback of V0.2

1.0 Vicky Thomas 27/11/2015 Final Release

Approvers

Name Position

Ben Day Deputy Chief Executive

Bruce Hinson Group Manager Infrastructure

Carole McKinley Business Improvement Manager

Steve Baker Chief Financial Officer

Donna Holland Finance Manager

Angela Jane Governance and Strategy Manager


Table of Contents

Table of Contents .......................................................................................................................................... 3

Document Purpose ....................................................................................................................................... 4

Background ................................................................................................................................................... 4

Principles ....................................................................................................................................................... 5

What is Project Governance? ................................................................................................................... 5

Financial Approvals ................................................................................................................................... 5

Project Scale (Scalability Matrix) ............................................................................................................... 5

Budget Types ............................................................................................................................................. 7

Progress Reporting .................................................................................................................................... 7

The Project Status Keys ............................................................................................................................. 7

Governance Functions .............................................................................................................................. 9

Project Lifecycle ...................................................................................................................................... 10

Levels of Governance .............................................................................................................................. 11

Setting up Project Governance ................................................................................................................... 13

The Governance Functions ......................................................................................................................... 15

The Project Executive .............................................................................................................................. 15

The Senior User ....................................................................................................................................... 17

The Senior Supplier ................................................................................................................................. 20

The Project Manager............................................................................................................................... 21

Project Board .......................................................................................................................................... 22

Programme Board ................................................................................................................................... 25

The Portfolio Overview Group (POG) ..................................................................................................... 28

The Strategy Team (Acting as a Project Review Board - PRB) ................................................................ 30

Milestones ............................................................................................................................................... 33

Appendix A: Glossary .................................................................................................................................. 34

RACI ......................................................................................................................................................... 34

Terms ...................................................................................................................................................... 34

Appendix B: Governance Summary - Investment Lifecycle Product Overview .......................................... 36


Document Purpose

This document outlines the governance principles applied to projects that are run at Thames

Coromandel District Council (TCDC). The Project Delivery Lifecycle provides a definition of what TCDC

considers to be a project. This information is not repeated here.

The governance framework applies to all projects regardless of funding type. The relevant funding types

for projects are included below:

Capex Business Unit Funded (Opex)

The purpose for this framework is to:

Articulate the roles and accountabilities of key stakeholders in the governance of initiatives. Define governance forums that are mandatory Ensure a single point of accountability for the success of the project Ensure project ownership independent of asset ownership, service ownership or any other

stakeholder group Ensure separation of stakeholder management and project decision making activities Ensure separation of project governance and organisational governance structures

Background

TCDC undertakes a large number of change initiatives at all times. The framework follows a scalable

model defined by a number of parameters:

Scale – An overall measure of complexity, investment amount and risk Portfolio – The operational portfolio that an initiative belongs to Overlays – Used when initiative includes a heavy IT component or Procurement activity

The size and portfolio of the initiative dominate the evaluation and selection of appropriate governance

level and forums. The overlays combined with the size will define the deliverables that are required

according the Project Delivery Lifecycle. The Scalability Matrix Product defines whether the initiative is a

Project, what the classification of the project is and what mandatory products are required throughout

the Project Delivery Lifecycle. The Scalability Matrix also includes Investment Lifecycle product

requirements that need to be approved through Governance Forums.


Principles

There are a number of overarching principles that apply to project governance which have been applied throughout this document. These principles are specified below.

What is Project Governance?

In essence, project governance is a decision-making model that provides a consistent method of controlling a project and enabling success by defining and documenting a decision making structure. Project specific governance is defined by and fits within the larger context of the portfolio or programme governance structure. However, it is separate from organisational governance. Organisational governance policies define a variety of aspects such as escalation paths for management of operational risks and issues, the delegation levels for financial approval and any other related policies. Project governance outlines:

The single point of accountability for the success of the project Project ownership and Business ownership Separation of stakeholder management and project decision activities Separation of project governance and organisational governance.

Financial Approvals

The final financial approval of project funding remains the accountability of the relevant delegated financial authority (DFA). The organisation's DFA policy will define who can authorise spending project funding both in an operational context (E.g. PO’s or invoices) and in a capital capacity (e.g. approval of unplanned capital expense). Please see ECM docset #4045244 for the Delegated Financial Authority policy.

Although the DFA is accountable for final sign off on new funding, the initiative will need to first pass through other governance gates before funding can be approved. This ensures that relevant controls and quality assurance is applied and minimizes the risk to the organisation.

Project Scale (Scalability Matrix) The scale of a project at TCDC is defined within four sizes (Fog, Quest, Movie and Paint). The criteria used by TCDC to define the size of an initiative is as follows:


Project Weightings: Time Cost Scope Risk Benefits Stakeholders Other elements are as follows: Project Plan Schedule Capability Quality Dependencies Governance Communication Change Management Integration Measurement of Success

1

2

3

4

Outline Full BBC

Start-Up Initiate Plan Implement Operate/Closure

Project Mandate

Project Brief

Business Case End Report

Contingency Draw Down Report / Exception Report / On/Off Hold Memo [If Required]

Scalability: Classification / Phase / Investment Lifecycle Products


Budget Types There are two budget types that are referred to at TCDC. Planned Budget and Approved Budget. These two terms are defined below: Planned Budget – Funding that has been allocated for the respective project during a given

financial year. Although the funding has been allocated, it may not be formally approved for expenditure. This funding has been initially approved by Council.

Approved Budget – Funding that is drawn down via a formal request. This request is made to one of the governance groups via an investment product submission. Once the investment submission is approved via all relevant governance groups (Including DFA) the funding is considered to be ‘Approved’. At this point the Approved Budget is allocated to the project and the project is able to spend.

Progress Reporting All governance forums are presented with reports that specify the status of in-flight initiatives. This is utilised to determine overall portfolio health. The principle is that healthy initiatives should be delivering to plan and should deliver the value that they promise. Unhealthy initiatives require support and intervention in order to once again become healthy and deliver the required outputs. At TCDC we use a standard set of reporting key’s to define project health. These keys are to be adhered to across the enterprise portfolio to ensure that standardisation is applied and we are measuring apples with apples. All projects are required to generate status reports. The status reports define the project’s performance against the respective reporting keys. Project Managers/Programme Managers should regularly discuss project progress with their Project Executives and Senior Users. In particular when there are issues that can turn any keys Amber or Red. As a rule of thumb the project engagement model should ensure that the Project/Programme Executive is made aware of any status issues prior to any governance forums (Project Boards, Portfolio Overview Groups, and Strategy Team) to prevent any surprises.

The Project Status Keys At TCDC there are 7 primary reporting keys. These are: Scope – The breadth and depth of the business solution to be delivered Cost – The estimated cash spend required to deliver the project. Benefits – How the initiative is tracking towards enabling the financial benefits outlined Key Performance Indicators – Specific and measurable KPI’s that are recorded as non-financial

benefits


Schedule – Timeliness for the delivery of the project plan through schedule and dependency management

Resourcing – The extent to which the project has the correct resources and the required capacity to deliver the required outputs by the approved timeframe

Confidence – This is a confidence rating defined by the Project Manager and the Senior User, measuring the readiness for Implementation into the business (for Internal Projects), and the rating defined by the Project Manager/Project Executive measuring the confidence in the ability to deliver the project (for External Projects - contract management)

These 7 project keys are each rated for a status of Green, Amber and Red. This scoring criteria is outlined in the matrix following:

Green Amber Red

Scope Current approved in-scope items can be delivered in full

Minor changes to core specification of quality of capability that will be delivered

Major changes to core specification of quality or capability that will be delivered

Costs Variance between Total Approved Spend and Total Forecast Spend for the approved phase/s within +/- 5% of approved spend up to a value of $50k

Variance between Total Approved Spend and Total Forecast Spend for the approved phase/s within +/- 10% of approved spend up to a value of $100k

Variance between Total Approved Spend and Total Forecast Spend for the approved phase/s is greater than +/- 10% of approved spend or greater in value of $100k

Benefits Current expectation of benefit realisation will be enabled by this project

Current expectation of some or all benefit realisation are at risk of not being enabled by this project

Current expectation of some or all benefit realisation will certainly not be enabled by this project

KPIs Current expectation of KPI Improvements (non-Financial benefits) will be enabled by this project

Current expectation of some or all KPI improvements are at risk of not being enabled by this project

Current expectation of some or all KPI improvements will certainly not be enabled by this project

Schedule Gold or Silver milestones remain on track to meet the approved timelines

Gold and Silver milestones are at risk however mitigating activities are in place in an effort to meet the approved dates

There is certainty that Gold and Silver milestones have missed or will miss the approved dates

Resourcing Project resourced adequately and project team is performing to a high standard

Project resourcing will cause a slip to schedule or cost or variance in scope if not

Project resourcing is causing variance to schedule, cost or scope

Confidence Business readiness activities are on track to enable the business to

Business readiness activities are/or may be behind schedule.

Business readiness activities are behind schedule and/or it is


accept and embed changes on schedule (Internal)

External Projects - contract management is on track to deliver the project and the community is informed

Additional focus may recover the timeline and/or recover the timeline and/or contingency plan is in place to enable the business to provide a "go" decision for go live.

External Projects - contract management is behind schedule to deliver the project. Current risks with Community/Council engagement.

unlikely a "go" decision can be provided by the business for go live.

External Projects - contract management is well behind schedule to deliver the project.

Issues are in place with contract management and Community/Council engagement.

The overall status of the initiative is based on a combination of these. A decision tree on how to ascertain the overall status is specified below:

Governance Functions

There are a number of key project governance functions. These range from operational project governance right through to programme and portfolio level functions. These functions are specified in the matrix below along with some examples of typical duties for these forums:

Forum Example of Duties

Portfolio Level Governance Functions

Corporate [Council]

Strategy Team

Ensure new investments are in line with the organisation's strategy


Portfolio Overview Group Agree material changes to organisaitonal project governance framework

Programme Level Governance Functions

Programme Board Ensure Programme is delivering outcomes required to deliver the organisation's strategy

Health of all initiatives within the programme

Project Level Governance Functions

Project Board Ensure that the project is delivering the outputs to enable the desired outcomes

Ensure that key risks and issues are escalated as required

Project Lifecycle

IdeaIdentifiedProject Mandate

Product Developed

Project Mandate Product Peer Reviewed

Do-ability assessment –People, Process and Tools

Community Boards Area Prioritisation

Strategy Team approval to send to Council

Project Lifecycle

Enterprise Council Investment Prioritisation

OperateImplementPlanInitiate

The required change is investigated and evaluated to determine if an investment is warranted. Investigation stage ends with a formal request for funds to continue through to Business Case or a decision is made not to proceed.

The project is fully defined. The scope is set, a solution of proposed and a plan is documented for what, how, why, when and by who the project will be delivered. The Plan stage ends with a formal request for funds to complete the project or a decision is made not to proceed.

The project is executed. The solution is designed, created, verified and implemented. The success of the project will be assessed and a formal PIR may be conducted. The Implement stage ends with a formal Project Closure and Handover to the Business.

The change is now embedded into BAU. Benefits will continue to be tracked against the business case until fully realised.

PorfolioReview Board

(Internal)

Project Delivery Lifecycle

1

2

3

4

5

6

7

8

LTP/AP Projects

1Internal Projects 2 3

1 2 3 4 5 6 7 8

Start-Up

Community Boards

Staff

Council

5 6 7 8


Levels of Governance The general principle is that the level of governance applied will increase as the size of the project increases. The size is made up of a combination of risk, complexity and end to end investment. Because larger sized projects generally carry greater inherent risk of failure, they need more vigilant governance.

The governance functions are applicable across the different project sizes and scenarios. The mechanisms applied will differ slightly if the project is a part of a programme. The application of these governance forums by size have been specified below:

Leve

l of

Go

vern

ance

Risk Level

PAINT PROJECT

MOVIE PROJECT

QUEST PROJECT

FOG PROJECT


The Project Executive should oversee all project decisions. Typically the Project Executive and Project Board (see the section on setting up project governance) will sign off on all Investment Lifecycle submissions before they go to organisational governance groups. The Portfolio Overview Group will oversee all key investment decisions. Any Project Mandate Product will require final approval from the Strategy Team. If any submissions succeeding the Project Mandate asks for funding that exceeds their original planned amount the Strategy Team will need to approve the respective submission. Governance Hierarchy: The governance hierarchy at TCDC is 5 tiers as follows:

Project Hierarchy:

All Projects that belong to a Programme will report through to the Programme tier, otherwise Projects will align directly through to a Portfolio. A Portfolio at TCDC is either Internal or External. All tiers should

SubmissionsEscalations

Visibility

ApprovalsDecisions

Delegations

Portfolio Overview Groups

Portfolio Review Board

TCDC Chief Executive

Community Boards

Council

Strategy Team


be strategically aligned to the tier above to ensure that the organisation’s strategic vision is being delivered.

Setting up Project Governance

During the Start-Up phase of a project, the Project Executive and the assigned Project Manager will need to determine the correct level of governance for the project by completing a scalability matrix. The Project Executive and the Project Manager will also need to determine a functional project leadership structure that will allow the project to run effectively. This leadership structure is used to define the operational team for managing day to day project risks and issues before they escalate through to more formal governance forums (Project Boards, Portfolio Overview Groups and Strategy Team etc.). Typically a project leadership team will consist of the Project Executive (who has ultimate accountability for the success of the project), the Senior User and the Project Manager. The leadership team of the project will create the internal project decision making construct. Decisions that need to be made on an operational level during the project should be contained within this structure unless escalation is required or it is required by other governance forums. At this stage, the Project Executive and the Project Manager will also decide if it is prudent to build a Project Board for this project. Please see the Project Board section of this guide for more information.

A typical project structure may be as follows:

The following questionnaire should be used by the Project Executive, Senior User and the Project Manager when setting up the project governance structure to ensure that a fit for purpose governance structure has been defined.

Yes No

Have you identified the scale of the project and have you identified your minimum mandatory governance requirements?

Is the Project Manager sufficiently experienced to manage an investment of this level of risk and complexity?

Does the project structure adequately address the need for key stakeholder engagement and

Corporate

Senior User Project Executive Senior Supplier

Project Manager Project Team


buy-in to decisions?

If the project involves multiple suppliers, have the lead and supporting roles, accountabilities and controls been determined and accepted by all suppliers?

If the project has a close relationship with other projects that require a joint consideration of critical dependencies or linkages, has this been addressed in the governance arrangements?

Is the governance structure fit for purpose in terms of scale and support roles and future transitioning as the investment progresses?

Do the Project Members have sufficient capacity and/or capability to deliver the project?


The Governance Functions This section of the document will specify all the standardised governance functions utilised by TCDC.

The Project Executive

Project Types All Projects must have a Project Executive

The Project Executive is the person accountable for the delivery of the project within scope, time and budget. The Project Executive is the link between the organisation’s senior executive body and the project.

Does your project need a Project Executive?

All projects must have a Project Executive. It is important to identify the Project Executive before starting the initiative regardless of risk, investment amount or complexity level. The Project Executive should be known during the Start-Up phase and should present the Project Mandate to the Strategy Team before the project moves into the Project Delivery Lifecycle.

Who should be the Project Executive?

The Project Executive is typically the Group Manager who owns the area that is most impacted by a project output. Considerations for selecting the Project Executive includes whether or not the candidate has: Authority to sanction change Organisational credibility to make the change happen Experience and expertise in the area being changed Passion and commitment to the proposed changes Deliver the outcome/s The Project Executive is responsible for developing the project funding as well as for delivering the project in accordance with the agreed success criteria. The Strategy Team can change a Project Executive if they deem it necessary.


The Purpose of the Project Executive

The table below specifies the Project Executives key roles and responsibilities:

RACI Actions

Responsible Chairs project governance forum meetings - Project Board

Assists with stakeholder engagement and builds stakeholder coalitions with peers

Accountable

Endorses Project Submissions and recommends the initiative at programme and portfolio level governance forums

Actively supports the Project Manager

Approves project scope and any changes to it

Ensures the strategic alignment of the initiative

Secures investment funding for the initiative

Articulates the vision of the initiative

Actively promotes the business need for change

Consulted

Acts as a point of escalation for project risks and issues

Approves the project approach and direction

Approves the project schedule

Informed Monitors the project status and project progress

Maintains awareness of project risks

The role of the Project Executive can change focus throughout the life of a project. The change in accountabilities has been specified below:

Start-Up

Determine the opportunity scope

Champion the project vision and business case

Appoint the project governance team

Select/approve the Project Manager and team

Initiate

Define the solution scope

Agree the value proposition

Assess, adopt and own the Business Case

Plan

Endorse the business case for prioritisation and funding approval

Implement

Control project scope

Monitor progress and achievements


Ensure progressive deliver of benefits

Champion the project in the business

Operate

Sustain focus to gain benefits

Capture lessons learnt

Ensure that effective handover to BAU is achieved

The Senior User

Project Types All Projects must have a Senior User

The leader that is responsible for the area that is most impacted by the project. Typically the person who owns the output that is delivered by the project. In other words the Senior User is the leader that will champion the change after the project has finished.

Does your project need a Senior User?

All projects must have a Senior User. At times there is so much overlap between the Senior User and the

Project Executive that both roles are filled by the same individual. This is particularly true for smaller

initiatives.

Who should be the Senior User? The Senior User is typically the leader that will own the output that is enhanced/created as a result of the project. There is often confusion when appointing the Project Executive vs. a Senior User. The key difference is that the Senior User will need to drive the change after the project is finished. The Project Executive is responsible for driving the change during the project. A duty that is specific to the Senior User is the requirement to take handover of the project outputs at the end of the project.

The Purpose of the Senior User

The Senior User is the person that will typically be responsible for owning the delivered asset and any associated benefits after the end of the project. Therefore, they have vested interest in the outputs of the project.


The Senior User is the link between the Business Area where the need for the project originated and the project. The table below specifies the Senior Users key responsibilities and accountabilities:

RACI Actions

Responsible


Shaping the project scope

Ensuring that handover is completed at the end of project delivery

Ensuring that the asset is supported after the project enables benefit realisation

Ensures user needs have been identified and validated and that the solution (if required) meets the needs of the business

Accountable

Endorses Project Submissions and recommends the initiative at governance forums



Consulted Acts as a point of escalation for project issues

Has input into the project approach and direction


The role of the Senior User can change focus throughout the life of a project. The change in accountabilities has been specified below:

Start-Up

Determine the opportunity scope

Champion the project vision and business case

Initiate

Active involvement in defining the scope

Active involvement in defining the projects requirements

Plan

Endorse the business case for prioritisation and funding approval

Implement

Monitor progress and achievements

Ensure progressive deliver of benefits

Champion the project in the business

Operate

Sustain focus to gain benefits


Ensure that effective handover to BAU is achieved


The Senior Supplier

Project Types All Projects that require the delivery of Products i.e. Technical, Engineering Maintenance and Support

A Senior Supplier creates the projects outputs and provides the necessary skills to produce the projects product/s. The Senior Supplier will be a representative on the Project Board.

Does your project need a Senior Supplier?

The Senior Supplier represents the interests of those designing, developing, facilitating, procuring and

implementing the project's products. If your project is deemed to be requiring any of the above

functions, then your project should align a Senior Supplier.

The Senior Supplier is accountable for the quality of products delivered and is responsible for any

technical integrity of the project.

In some cases the Project Manager can also be a Senior Supplier.

The Purpose of the Senior Supplier

The Senior Supplier is accountable for the quality of products delivered and is responsible for any

technical integrity of the project.

The table below specifies the Senior Supplier key responsibilities and accountabilities:

RACI Actions

Responsible


Adds to the Business Case from a Supplier perspective

Ensures that the products required can be delivered within the expected costs and are viable and that any product is quality assured

Attends the Project Board Meetings from a Supplier perspective

Accountable

is accountable for the quality of products delivered and is responsible for any technical integrity of the project

Ensures that the Project Plan remains consistent from a supplier perspective

Ensures that any risks from a supplier perspective are identified, assessed and controlled

Consulted Acts as a point of escalation for product issues

Informed Provides supplier resources if required


The Project Manager

Project Types All Projects require a Project Manager

A Project Manager has the authority to run the project on a day-to day basis on behalf of the Project Board and the Project Executive within the constraint expectations assigned. The Project Manager's key responsibility is to ensure that the project produces the required products with in the specified tolerances of time, cost, quality, scope, risk and benefits.

The Purpose of the Project Manager

The Project Manager is responsible for the product producing a result capable of achieve the benefits defined in the Business Case. The table below specifies the Project Manager key responsibilities and accountabilities:

RACI Actions

Responsible

Prepares all Investment Lifecycle products and agrees them with the Project Board

Prepares all Project Delivery products and agrees them with the Project Board

Liaises with Corporate or programme management to ensure that work is neither overlooked nor duplicated by related projects

Liaises with any external suppliers or account managers

Leads and motivates the project management team

Accountable

Manages the production of the required products

Establishes and manages the projects procedures i.e. risk management, issue and change control, communications, actions registers etc.

Advises the Project Board of any deviations to plan

Consulted Acts as a point of escalation between the project management team and the Project

Board


Project Board

Project Types Large projects [Classification 2, 3 or 4]

This is a group of business leaders that represent the key stakeholder community that is impacted by the project outputs along with the project leadership team.

Does your project need a Project Board?

A Project Board is recommended when a project has a categorisation of either 2, 3 or 4 within the Project Categorisation tool and is not already a part of a Programme Board. It should be established where: The project impacts across multiple business units as it may impact significant operational or

external risk The Project Executive or senior management feels that a Project Board would add value to the

governance of the project.

Who should be in the Project Board

Typically, the Project Executive chairs the Project Board session. The composition criteria for the Project Board attendees are as follows: Note that the Project Executive must be a Council staff member not an elected member or from a Stakeholder Group.

Must Have Attendees

Project Executive

Senior User

Project Manager

Senior Supplier

Representative(s) from highly impacted customer or stakeholder groups

Should Have Attendees

Representative(s) from moderately impacted customer or stakeholder groups

Representative(s) from high impacted providers*

Nice to Have Attendees

Policy or subject matter experts indirectly impacted who can provide material value to decision making.

*Please note that providers are usually Consulted parties in the project RACI that have valuable input into the direction of the project (although they are not directly impacted). An example is Operational Risk if the project is impacting a large business risk within the organisation. Another example is Legal, if there are any contract changes to existing agreements as a result of the project.


A large Project Board can be a sign of the inclusion of too many stakeholders. Usually this causes the meeting to become a mechanism for information gathering and stakeholder management as opposed to project governance. It is important to keep the size of the Project Board ‘fit for purpose’. If necessary, create a separate Key Stakeholder Group with regular meetings to serve the communication and information gathering functions.

The Purpose of the Project Board

Successful delivery of the project outcomes requires that the Project Board members understand the business context addressed by the investment, including the operational and associated whole-of-life impact factors. The focus extends beyond the project to embrace the broader context. A Project Board must ensure that key stakeholders are informed and committed as the project progresses. The group also proactively monitors, mentors, challenges and supports the project team on the project’s progress A Project Board should operate within pre-defined terms of reference that are specific to the governance needs of the project. These specify: Membership obligations Regularity of meetings Operational details Decision making powers Decision making requirements (quorum – should always include the Project Executive) Escalation points. The table below specifies the key responsibilities and accountabilities for the Project Board:

RACI Actions

Responsible



Ensuring that the output is supported after the project and enable benefit realisation

Accountable




Consulted Acts as a point of escalation for project risks and issues




How to set up a Project Board This checklist provides a guideline on how to set up a Project Board for a specific project.

Yes No

Has the project drafted a Terms of Reference?

Is the Terms of Reference appropriate for the Project Board given the project complexity?

Is the composition of the group right for the project?

Given the complexity of the project, have you identified how frequently you should meet?

Is it clear from the roles and responsibilities and other project governance documents what the Project Board decides or approves, and what the project manager can decide – with or without consultation with the Project Executive?

Has the meeting invite been created?

The following checklist may be appropriate for the first meeting:

Yes No

Have the members agreed and signed off the Terms of Reference?

Are the format and content of the agenda, minutes, Project Board pack and standard reports well designed?

Does the reporting provide the group members with clear information so they can track project progress?

Is the Project Board clear on the decisions that they are being asked to make?


Programme Board

Project Types All Programme's should have a Programme Board

A group of business leaders that represent the key stakeholder community that are impacted by the Programme's outputs.

Does your programme need a Programme Board?

All Programmes should have a Programme Board. Typically, a programme will exhibit the following traits: The programme impacts across multiple business units and it may impact significant internal or

external operational risk Programmes kick off multiple projects that deliver the outputs required to deliver the programme

outcomes. Having a single Programme Board would reduce the number of committees that are required on an individual project level.

Who should be in the Programme Board?

Typically, the Programme Executive chairs the Programme Board session. The composition criteria for the Programme Board attendees are as follows: Note that the Project Executive must be a Council staff member not an elected member or from a Stakeholder Group.

Must Have Attendees

Programme Executive

Project Executives

Senior User

Project Manager(s)

Representative(s) from highly impacted customer or stakeholder groups

Should Have Attendees

Representative(s) from moderately impacted customer or stakeholder groups

Representative(s) from highly impacted providers

Nice to Have Attendees

Policy or subject matter experts indirectly impacted who can provide material value to decision making.


The nature of a programme means that the Programme Board will be larger than your average Project Board. Because of the size of the Programme Board it is important to have strong facilitation of the sessions to ensure they remain ‘fit for purpose’.

The Purpose of the Programme Board

The emphasis of a Programme Board should be on the business outcomes achieved by ‘What’ is delivered as opposed to the technical information on ‘How’ it is delivered. Successful delivery of the programme outcomes requires that the Programme Board members understand the business context addressed by the investments including the operational and associated whole-of-life impact factors. The focus extends beyond the projects themselves to embrace the broader context. A Programme Board must ensure that key stakeholders are informed and committed as the programme and individual projects progress. The group also proactively monitors, mentors, challenges and supports the project teams on the progress of their projects A Programme Board should operate within pre-defined terms of reference that are specific to the governance needs of the programme. These specify: Membership obligations Regularity of meetings Operational details Decision making powers Decision making requirements (quorum – should always include the Project Executive) Escalation points.

The table below specifies the key responsibilities and accountabilities for the Programme Board:

RACI Actions

Responsible




Ensuring that the asset is supported after the project enables benefit realisation

Accountable




Consulted Acts as a point of escalation for project issues




How to set up a Programme Board This checklist provides a guideline on how to set up a Programme Board.

Yes No

Has the programme drafted a Terms of Reference?

Is the Terms of Reference appropriate for the Programme Board given the programme complexity?

Is the composition of the group right for the programme? i.e. are all sub projects represented

Given the complexity of the programme, have you identified how frequently you should meet?

Is it clear from the roles and responsibilities and other programme/sub-project governance documents what the Programme Board decides or approves, and what the programme/project manager can decide – with or without consultation with the programme Executive?

Has the meeting invite been created?

The following checklist may be appropriate for the first meeting:

Yes No

Have the members agreed and signed off the Terms of Reference?

Are the format and content of the agenda, minutes, Programme Board pack and standard reports well designed?

Does the reporting provide the group members with clear information so they can track programme progress?

Is the Programme Board clear on the decisions that they are being asked to make?


The Portfolio Overview Group (POG)

Project Types All Project Investment submissions should be approved through the Portfolio Overview Group.

Each operational Portfolio at TCDC will have its own Portfolio Overview Group. A Portfolio Overview Group governs a portfolio of initiatives and ensures that the outcomes of the respective portfolio are delivered. There are currently 2 portfolios at TCDC.

When do we need to submit to a Portfolio Overview Group?

All Project Mandate and key investment deliverables for all initiatives must go through a Portfolio Overview Group session. The Portfolio Overview Group that the investment is submitted to will depend on the specific portfolio that the initiative is owned by. The portfolios are as follows:

Internal Projects - those projects undertaken with an internal focus - i.e. IT, Business Improvement External Projects - those projects undertaken with an external focus - i.e. Coastal Erosion/Roads etc.

Project/Programme Executives present investment submissions at the Portfolio Overview Group for approval. The forum has the authority to make the following decisions:

Support the initiative Reject the initiative Defer the initiative to a known future date Put an initiative on hold indefinitely

The Portfolio Overview Group sessions are held once a month.

Who should be in the Portfolio Overview Group?

The Portfolio Overview Group will be chaired as follows: Internal - Deputy Chief Executive External - Group Manager Infrastructure The forum itself should consist of key Senior Users that look after Programmes and Projects within the Portfolio. Non-voting members may also attend as required. These may include relevant Team Managers and Business Subject Matter Experts.


The Purpose of the Portfolio Overview Group The Portfolio Overview Group meets regularly where the key stakeholders from across the business come together to review and approve projects and programmes within a given portfolio. The group reviews all Project Mandate Products, Project Briefs, Business Cases, Exception Reports and other Investment documents as required. The group determines whether cases should be supported, put on hold or require additional information. The group will also decide if an Investment Submission should be escalated to the Strategy Team. The forum brings together the Senior Users from key delivery and support areas to enable a full and robust discussion and challenge on the project spend and progress to date. Finance provides significant input to a Portfolio Overview Group in the form of cost-benefit analysis and review as well as evaluation of how the portfolio is tracking to plans and forecasts for the year. Another function of the Portfolio Overview Group is to prepare the recommended Portfolio In-Plan project priority list. This is submitted to the Strategy Team. The table below specifies the Portfolio Overview Group’s key roles and responsibilities:

RACI Actions

Responsible

To provide executive support on all investments

To approve, reject, put on hold new investment requests depending on priority and other constraints

To re prioritise, stop or put on hold in-flight investments depending on portfolio performance and other constraints or interdependencies

To manage the portfolio against the ‘baseline’ plan and to challenge un-planned variances

To escalate unplanned negative variances to the Strategy Team

Prepare and submit the recommended operational portfolio priority list to the Strategy Team

Accountable

Maintain an investment portfolio in line with organisational strategy

Managing the portfolio within the given investment envelope

Managing the portfolio within the given resource constraints

Manage escalations

Consulted Escalations/Decisions from Project Boards

Informed Project performance updates


The Strategy Team (Acting as a Project Review Board - PRB)

Project Types

All Project Mandate products must be submitted to the Strategy Team. Also all key investment submissions where funding requested exceeds the planned amount for the initiative require support from the Strategy Team.

The Strategy Team oversees the strategic direction of investment spend at TCDC.

When should you submit to the Strategy Team?

All Project Mandate's must be submitted for approval by the Strategy Team before they can enter into the Project Delivery Lifecycle. Once a project is in the Project Delivery Lifecycle all key Investment documents (Project Brief, Business Case, and Exception Reports) must be submitted to the Portfolio Overview Group. However, if the requested funding exceeds the amount allocated to the initiative in the plan, the submission will require Strategy Team and Council approval as well. Who should be in the Strategy Team?

The Strategy Team consists of a number of the executive team from across the business. The TCDC Chief Executive will appoint the Chair and Alternative Chair. In the absence of such appointment, the Deputy Chief Executive will be the Chair, and the Group Manager Infrastructure the Alternative Chair. There will typically be a number of non-voting members in attendance in order to support the session. The relevant Project/Programme Executives will attend when they are required to submit an Investment document for consideration by the Strategy Team. The Strategy Team can make the following decisions: Support the initiative Reject the initiative Defer the initiative to a known future date Put an initiative on hold indefinitely Include an initiative in the Portfolio Plan The Purpose of the Strategy Team as a PRB The objective of the Strategy Team is to develop and oversee a multi-year Portfolio Plan to deliver the TCDC Strategy, Long Term Plan and Annual Plan.


The Strategy Team discusses and assesses each submission according to its cost to value relationship, strategic alignment, and the ability of TCDC to provide or allocate resources to the initiative. The forum does not focus on the solution and/or approach for delivery of the initiative. The Strategy Team is the centralised body across TCDC assigned to: Align the investment portfolio with corporate strategy, Long Term Plan and Annual Plan. Make informed and dynamic portfolio prioritisation decisions to maintain the right balance in the

investment portfolio and to enable active performance management. Prioritise initiative submissions to create focus on company priorities Maintain visibility of the Portfolio Plan of initiatives extending over 2-3 financial years (This includes

visibility of in-flight initiatives and future pipeline initiatives) Ensure company-wide visibility of Strategy Team governed initiatives Support, defer or reject initiatives meeting the Strategy Team selection criteria Engage in organisation wide continuous improvement of the project/programme/portfolio

governance processes All projects supported by the Strategy Team are still subject to the appropriate Delegated Financial

Authority (DFA) signature prior to the release of funding. For some Strategy Team projects the delegated authority may sit higher than the Project Executive (e.g. the DFA may sit with the Chief Executive or Council level).

Provide any escalations for decision to Council.


The table below specifies the key responsibilities and accountabilities for the Strategy Team:

RACI Actions

Responsible

Provide executive support for steering on large investments

Approve, reject, put on hold new investment requests depending on priority and other constraints

Re-prioritise, stop or put on hold in-flight investments depending on portfolio performance and other constraints or interdependencies

Review benefits

Developing and maintaining an investment Portfolio Plan with a 2-3 financial year outlook. This should include a view of the pipeline as well as in-flight initiatives

Support initiatives to the relevant Delegated Financial Authority to gain financial approval for initiatives

Accountable

Maintain an investment portfolio in line with organisational strategy

Managing the portfolio within the given investment envelope which applies on a financial year basis

Managing the portfolio within the given resource constraints

Manage escalations

Consulted Any request that has been approved at the Portfolio Overview Group and does not

require approval at the Strategy Team. See Appendix B Summary

Informed Project performance updates


Milestones

Milestone Description

Gold

Visible and important at Project Boards, Portfolio Overview Group, Strategy Team and Council

Types of Gold Milestones include the delivery of a major project event. E.g. Project Go Live or a committed date to customer(s).

Silver

Visible and important at Project Boards, Portfolio Overview Group

Types of Silver Milestones include Delivery of a key project event, enabling the

remainder of the project. E.g. Infrastructure in place and ready, work package funding

approved or completion of detailed design, start or end of a stage or training

completion.

Bronze

Visible and important at Project Boards

Delivery of any remaining significant project events not captured as Silver or Gold

Milestones. E.g. change management plan complete or interim phases of testing

complete.


Appendix A: Glossary

This document references terms specific to project governance and to TCDC.

RACI

A RACI, also known as a responsibility assignment matrix, defines the role of an individual or group in a specific project, event, or activity.

Letter Definition

R Responsible – Does the work

A Accountable – Ultimately answerable for ensuring that the work is done on time and within scope

C Consulted – Opinion and input sought but neither does the work nor answerable for the successful completion of the work

I Informed – Kept up to date on progress and outcomes of the work

Terms The Glossary below defines commonly used terms.

Term Definition

Portfolio Overview Group

A group of Senior Users and Project Executives who collectively govern a Portfolio of initiatives and ensure the delivery of portfolio outcomes.

Project Governance

Project governance is the system and structure to support the decision-making about a project. The governance framework outlines who has responsibility and authority to make decisions and ensures there is clearly defined accountability for all aspects of a project.

Strategy Team A group of Executives that are accountable for the delivery of a multi-year Portfolio Plan to deliver the TCDC.

Portfolio The totality of an organisation's investment (or segment thereof) in the changes required to achieve its strategic objectives.

Programme

A temporary, flexible organisation structure created to co-ordinate, direct and oversee the implementation of a set of related projects and activities in order to deliver outcomes and benefits related to the organisation’s strategic objectives. A programme is likely to have a life that spans several years.


Term Definition

Project Manager The person with authority and responsibility to manage a project on a day—to-day basis to deliver the required products within the constraints agreed by the project Governance.

Project Executive Typically the executive or leader that owns the area most impacted by a project.

Stakeholder Any individual, group or organisation that can affect, be affected by, or perceive itself to be affected by, an initiative (programme, project, activity or risk).

Operational Risk Operational Risk is a type of risk where the potential impacts are related to the running of the business.

Project Risk

Risks that can negatively impact project specific budget, scope or time-frame. Typically if a project risk eventuates, the direct consequences are contained within the project/programme. Whereas direct consequences for an operational risk eventuating will have an impact on the business.


Appendix B: Governance Summary - Investment Lifecycle Product Overview This diagram provides a simple overview of the product and governance requirements to obtain funding. It also shows what products are required for each Phase obtained through Classification [Scalability Matrix].

Investment Lifecycle ProductsIn

vest

men

t P

rod

uct

s

Go

vern

ance

Bo

die

s

Po

rtfo

lio

Ove

rvie

w

Gro

up

Co

un

cil

DFA

Ob

tain

ed

OperateImplementPlanInitiateStart-Up

Project Mandate

Project Brief

Draw down within FY planned budget

Drawdown over FY planned budget

NOTED

Business Case

Draw down within FY planned budget

Drawdown over FY planned budget

Exception Report [Change

Request]

On Hold/Off Hold Memo

End Project Report

Additional Phase Funding

Required within

Approved FY Planned Budget

Additional Phase Funding Required over

FY Planned Budget

No Funding Impact

NOTED NOTED NOTED NOTED NOTED

Po

rtfo

lio

Rev

iew

Bo

ard

NOTED NOTEDNOTED

1 2 3 4 5

All Projects Quest/Fog Movie/Quest/Fog All Projects All Projects

Phase

Classification

Documents

Project Centre of Excellence Project Governance Framework · Project Centre of Excellence Project Governance Framework December 2015 This document defines the Thames-Coromandel District