technical governance mandatory requirements

Technical Governance Mandatory Requirements

Document Ref. TGMR

Issue 2 October 2017

© United Utilities Water Ltd

All Rights Reserved

The copyright of this document is vested in United Utilities Water Ltd. The document contains information of a proprietary nature and may not be used for purposes other than that for which it has been supplied and may not be reproduced either wholly or in part in any way whatsoever. The document may not be used by or its contents divulged to any other person whatsoever without the prior written permission of United Utilities Water Ltd.

Technical Governance Mandatory Requirements Document Ref. TGMR Issue 2, September 2017 Page i © United Utilities Water Ltd


AMENDMENT SUMMARY

Issue Date Details Prepared by Verified by

1 September

2015 Initial issue Mark Hurst

Helen Samuels

2 October

2017 Restructured and reformatted with minor amendments to content

Simon Grant Jeremy

Salisbury

Technical Governance Mandatory Requirements Document Ref. TGMR Issue 2, September 2017 Page ii © United Utilities Water Ltd


CONTENTS

Page No

DEFINITIONS 1

PURPOSE 2

SCOPE 2

OVERVIEW 2

TECHNICAL GOVERNANCE BASELINE 5

Technical complexity assessment 5

Project complexity rating 5

Engineering delivery route selection 6

Technical authority 7

Resource register 8

TECHNICAL GOVERNANCE 9

Requirements 9

Gate review 9

Check and review 9

Technical assurance 9

SUPPORTING TECHNICAL GOVERNANCE 10

Project requirements 10

Project gate reviews 12

Project check, review and approval 13

Project technical assurance 15

Digital asset information management [DAIM – BIM] 18

Standard deviations 20

Re-use of company knowledge [RoCK] 23

Technical Governance Mandatory Requirements Document Ref. TGMR Issue 2, September 2017 Page iii © United Utilities Water Ltd

TECHNCIAL GOVERNANCE COMPLIANCE 25

Three lines of defence 25

Corrective action 26

Monitoring 26

APPENDIX: MAJOR CAPITAL PROJECTS [MCP] 27

APPENDIX: STUDIES & INVESTIGATIONS [S&I] 28

APPENDIX: ASSET MAINTENANCE SUPPORT [AMS] 29

APPENDIX: AREA DEPLOYED TEAMS [ADT] 30

Technical Governance Mandatory Requirements Document Ref. TGMR Issue 2, October 2017 Page 1 © United Utilities Water Ltd

DEFINITIONS

Project all the activities Engineering undertake, bulleted below:

o Project engineering: major capital projects [MCP], studies & investigations [S&I], pilot plants [innovation], managing the network model, commission orders

o Operational engineering: asset maintenance support [AMS], internal job orders [IJOs], area deployed teams [ADTs], range management, maintenance support, commission orders

Engineering leadership team; head of project engineering, head of operational engineering & the engineering director

Engineering team lead; Senior/Project Engineering Manager [S/PEM], Engineering Manager or Discipline Engineer

Project Lead; Project Manager when engineering are not leading the project [usually after contract award]


PURPOSE

The purpose of technical governance is to ensure the right level of technical knowledge, expertise and experience is available at key points in the project lifecycle to establish;

The “optimal” solution

Long-term strategic thinking to enable better investment decisions

Reviewing latest technologies and broader knowledge transfer

Correctly appraising value (risk; opportunities & threats) across the programmes

Understanding and evaluating performance risk

Technical Governance is essential in order to identify and maximise opportunities and manage threats, it covers a number of activities, each activity will be explained further within this document.

It should result in a more focused, efficient and effective solution and therefore realise a reduction in engineering effort whilst delivering the optimal solution.

SCOPE

Technical Governance is a series of activities considered / carried out whilst providing the services engineering are requested to deliver. The services engineering are asked to deliver / support are listed below:

Project Engineering: major capital projects [MCP], studies & investigations [S&I], pilot plants [innovation], managing the network model, commission orders

Operational Engineering: asset maintenance support [AMS], internal job orders [IJOs], area deployed teams [ADTs], range management, commission orders

OVERVIEW

The level of technical governance applied differs depending on the complexity or the level / quantity of risk; threats / opportunities carried throughout the project, the engineering team lead is responsible for:

Agreeing the level of technical governance to be applied to a project

Recording the technical governance applied across the project lifecycle

Technical governance will be applied appropriately to meet the specific opportunities and needs of each project and will:

Be flexible to adapt to different needs

Be realised through the technical governance framework

Technical governance framework

Technical governance is delivered through the use of a series of tools and processes, these combined are known as the technical governance framework. The technical governance framework is applied throughout the project lifecycle in line with the associated appendix and delivered through a series of business as usual activities completed in a logical sequence. The technical governance activities are listed below and have been grouped into four categories; setting the baseline, technical governance, supporting technical governance & technical governance compliance.

Technical governance baseline

At the beginning of a project the technical governance baseline is set; technical complexity is assessed, delivery methodology is reviewed and technical governance level & technical authorities are defined. The activities necessary to set the technical governance baseline are identified in Fig 1.


Fig 1

Technical governance activities

The activities where technical governance is applied [as appropriate] across the project lifecycle are identified in with Fig. 2 below and are applied on a project by project basis in line with the associated appendix. This ensures the right level of technical governance is applied at the right time throughout the project lifecycle in line with the complexity and scope of the project.

Fig. 2

If there are significant changes in direction, scope, programme, budget or level of risk at any point in the project lifecycle the Engineering Team Lead can re-assess and suggest the level of technical governance be amended to meet the changes.

Technical governance supporting activities

The activities identified in Fig. 3 support technical governance and are applied as and when required throughout the project lifecycle.

Fig. 3

Technical Complexity

Delivery Route

Technical Authority

Technical Baseline

RequirementsGate

ReviewCheck and

ReviewTechnical Assurance

Project requirements

Project gate review

Project check & review

Project team technical assurance

Digital asset information management [DAIM]

Standard related challenges, deviations & enquireis

Re-use of company knowledge [RoCK]

Project Lifecycle


Technical governance compliance

To ensure technical governance is carried out in line with this document the ‘three lines of defence’ compliance approach identified in the Fig. 4 is applied

Fig 4

Technical governance accountabilities & responsibilities

The head of project / operational engineering has accountability for ensuring that technical governance is applied to the projects within their programme of works; however the responsibilities for the individual projects sit with the associated engineering team lead

The engineering team lead is responsible for ensuring all of the applicable technical governance activities identified in the associated appendix are applied to their projects and that the outcomes are recorded on the associated forms. If there are significant changes in direction, scope or level of risk within the project, continued compliance with the associated technical governance activities should be reassessed.

Technical governance application

Individuals appointed to a project must be able to demonstrate the right level of technical knowledge, expertise and experience in order to deliver project benefits. The engineering team lead should discuss and agree which activities identified in the associated appendix are applicable to the project with the project technical authorities. The approach may vary depending on the how the projects are delivered.

Technical governance scheduling

The application of the technical governance will be reflected in the project schedule and be applied throughout the project lifecycle in accordance with associated appendix.

Technical governance outputs

The outputs of technical governance are to be arrived at by consensus, if consensus cannot be reached the issue is to be escalated to the engineering service manager or Head of Project / Operational Engineering.


TECHNICAL GOVERNANCE BASELINE

This section contains all the elements necessary to set the technical governance baseline of the engineering service to be delivered. The elements will be assessed during the initiation of a project.

The assessment is carried out by engineering team lead and reviewed by the engineering service manager and appropriate chief engineer who confirm the complexity of the service to be delivered, the delivery route selection and the technical authority.

The technical governance baseline is captured on the associated form on the Technical Governance Baseline SharePoint site.

Technical complexity assessment

Each project will undertake an assessment of the technical and business aspects of the service to be delivered. The assessment includes the following criteria

Engineering time

Total planned investment [cost]

Quality

Technical

Innovation

Stakeholders

Health & Safety

Each criteria will be awarded a score based on a level of 1-6; 6 being the highest complexity rating and 1 being the lowest. The scoring should be based on known data gathered and assessed as early as is appropriate.

The technical complexity score should be baselined and revisited prior to each gate review. This will determine that the technical governance applied is appropriate and reflects any changes in dimension or criteria that may affect the complexity rating.

The assessment identifies the project complexity rating that will be used as guidance to support technical authority selection and delivery route allocation (in house or external or a blended combination of both).

Project complexity rating

The assessment of technical and business complexities will provide a project complexity rating which is used to identify a project type. Each project type will attract a Technical Governance rating [TG]; TG 1 will attract the lowest and TG 4 will attract the highest level of governance required.

TG 1 – Sustained: Total complexity score 0 to 20

The project is low risk. The outcome affects only a specific or isolated service or programme or portfolio. The risk mitigation for general project risks is in place and can be managed using company risk management processes as business as usual.

TG 2 – Tactical: Total complexity score 21 to 40

The project is low to medium risk. The outcome affects multiple services within a programme or portfolio. The project requires an elevated level of engineering time and input. The project risk profile indicates that some risks could have substantial impacts and so an enhanced approach to risk management will be required. The project is operational in nature and

http://shp13-apps/apps/ER/SitePages/Technical%20Complexity.aspx

http://shp13-apps/apps/ER/SitePages/Technical%20Complexity.aspx


outcomes delivered will bring new capabilities within the current operating limits of the wholesale business.

TG 3 – Evolutionary: Total complexity score 41 to 50

The project introduces significant change and new capabilities across the wholesale operational business. The scope of works require significant input from multiple disciplines that is likely to affect multiple stakeholders or agencies. The project outcome provides substantial change to an existing operational process, which may have a serious impact on energy or chemical consumption, current or existing assets and technology within a TOTEX environment.

TG 4 – Transformational: Total complexity score 51 to 60

The project requires extensive specialist capability, may have a dramatic impact on the organisation and other key stakeholders. The project risks have severe consequences and affect multiple areas of the wholesale business. The outcome of the project will have a severe impact on the future wholesale operating capability within a TOTEX environment.

Engineering delivery route selection

There are three different methods of delivery for engineering service with the most appropriate delivery route chosen to ensure successful delivery of the service as identified in the service request.

The engineering service managers working collaboratively with the chief engineers will review the technical and business complexity criteria score and use the bullet points below to help confirm the most appropriate method of delivery.

The degree of confidentiality, commercial, legal and reputational risk to United Utilities associated with choice of delivery route.

The degree of definition with respect to the project risk profile

The sponsor and stakeholder relationship criticality to achieve project success and benefit

The degree to which United Utilities wish to develop new skills or processes or technologies through innovation.

Delivery Route 1 – United Utilities resources

The engineering team lead will be a United Utilities employee with the appropriate competency to successfully deliver work of this type. The team will be a United Utilities in house resource, booking time to projects via the United Utilities timesheet system. The team will be individual or multiple disciplines in nature and will be assigned to projects that are confidential to United Utilities, have high regulatory or statutory requirements and as such will allow United Utilities to bridge or acquire new skills and processes. This delivery method will cater for projects that have a low degree of scope definition are a high risk commercially to United Utilities and may pose a significant reputational risk if they were to be procured through the engineering service provider.

Delivery Route 2 – Managed integrated team

The engineering team lead will have the appropriate competency to successfully deliver work of this type. The team will be a blended team of United Utilities / engineering service provider discipline resources, individual or multiple disciplines in nature and will be assigned to projects that have a strong requirement for nominated United Utilities project sponsor or regulatory / complex stakeholder engagement. This delivery method will cater for projects that have a high degree of scope definition and are a comparatively low risk commercially


to United Utilities with no significant reputational risk identified, if they were to be procured through the engineering service provider.

Delivery Route 3 – Engineering service provider resources

The engineering team lead will be an engineering service provider employee with the appropriate competency to successfully deliver work of this type. The team will be a blended team of United Utilities / engineering service provider discipline resources, individual or multiple disciplines in nature and will be assigned to projects that are appropriate for the engineering team lead to liaise directly with United Utilities project sponsors. This delivery method will cater for projects that have a well-defined scope and are a comparatively low risk commercially to United Utilities with no significant reputational risk identified, if they were to be procured through the engineering service provider.

Technical authority

After a project has completed the technical complexity assessment the engineering service manager and chief engineers will identify and appoint the appropriate resources to the role of technical authority. Successful project outcomes will be achieved with competent and appropriate personnel being selected for the activity, issue or project type. The model below identifies the Technical Authority required for the various levels of Technical Governance.

Depending on the scope of the project a technical authority may also be required from other directorates within United Utilities [operational technology and / or quality & scientific]. The engineering team lead will consider ‘other technical authority’ while setting the technical governance baseline.

If a project changes delivery route during the project lifecycle it is expected the technical authorities are amended as follows

Project delivery sign-off – the role is transferred to an engineering lead in the associated delivery route


Technical sign-off – the role does not transfer, the technical sign-off role stays with the project throughout the project lifecycle

o Changes can be made on a project by project basis [the exception not the rule] with the agreement of the engineering service manager and the appropriate chief engineers, the reasons for the change must be captured on the applicable technical governance baseline form.

Resource register

A technical resource register is maintained to support the technical authority role;

Project delivery sign-off, updated by the relevant engineering service manager

Technical sign-off, updated by the relevant chief engineer

Engineering service managers and chief engineers will appoint individual resources to technical authority levels within the technical resource register based on an assessment of their project leadership or technical competency. The assessment will include an assessment of skill, knowledge, proven ability, recorded and approved training and demonstrable experience. Any skill gaps identified will feed into the respective formal appraisal processes and will be captured on personal development plans.

The technical resource register supports the engineering service managers and chief engineers with their decision making in delivery route allocation process [complexity, capability and capacity].


TECHNICAL GOVERNANCE

Technical governance is carried out by the technical authorities to ensure the right level of technical knowledge, expertise and experience is available at key points in the project lifecycle.

Technical authorities provide overarching technical governance to identify risks; maximise opportunities and mitigate threats, their involvement should result in a more focused, efficient and effective solution and therefore realise a reduction in engineering effort whilst

Defining the “optimal” solution

Delivering long-term strategic thinking to enable better investment decisions

Reviewing latest technologies and broader knowledge transfer

Correctly appraising value risk (opportunities & threats) across programmes

Understanding and evaluating performance risk

The technical authority role [as defined above] is carried out on the following ‘business as usual’ activities as laid out in the associated appendices.

Requirements

Technical authorities are to provide overarching technical governance and to ensure the requirements, benefits, success criteria, user acceptance criteria & project success factors are

captured, agreed and signed off on the associated form [engineering team lead, sponsor, operations representative] as laid out in the associated appendix. The technical authorities sign-off the applicable form on the Project Requirements SharePoint site.

Gate review

Technical authorities are to provide overarching technical governance at particular points in the project lifecycle as laid out in the associated appendix to ensure the key technical activities, status is known and any risks associated are fully understood. The technical authorities sign-off the applicable form on the Gate Review SharePoint site.

Check and review

Technical authorities are to provide overarching technical governance and ensure the project check, review and approval record has been completed and signed off as laid out in the associated appendix prior to the engineering deliverable being passed on to the next stakeholder. The technical authorities sign-off the applicable form on the Check & Review SharePoint site.

Technical assurance

Technical authorities are to provide overarching technical governance and ensure the technical assurance activity / record has been completed and signed off [as applicable] as laid out in the associated appendix. The technical authorities sign-off the applicable form on the Technical Assurance SharePoint site.

http://shp13-apps/apps/ER/SitePages/Project%20Requirements.aspx

http://shp13-apps/apps/ER/SitePages/Gate%20review.aspx

http://shp13-apps/apps/ER/SitePages/Check%20and%20Review.aspx

http://shp13-apps/apps/ER/SitePages/Technical%20Assurance.aspx

http://shp13-apps/apps/ER/SitePages/Technical%20Assurance.aspx


SUPPORTING TECHNICAL GOVERNANCE

Project requirements

The project lead shall liaise with discipline engineers, sponsor and operations representative to ensure the requirements, benefits, success criteria, user acceptance criteria & project success factors are captured, agreed and signed off the applicable form on the Project Requirements SharePoint site as laid out in the associated appendices.

It is advised that the project lead organises a meeting where the following activities should be undertaken:

Sponsor to present the need(s) as defined through the root cause analysis activity [previously carried out]

The requirements, benefits, success criteria, user acceptance criteria & project success factors associated with the need are to be captured. The following bullet points should be considered by the engineering team lead to help facilitate the group discussion:

o Capture ideas around requirements, benefits, success criteria, user acceptance criteria & project success factors and constraints rather than potential solutions.

o Once ideas are gathered, lead a group discussion to determine if the item is a requirement, benefit, success criteria, user acceptance criteria or project success factor, or a constraint (constraints restrict the options to solve the need).

Once all the ideas have been gathered the project lead is to take the outputs and create the various documents required [requirements statement, benefits statement, success criteria, user acceptance criteria or project success factor]. These documents are to be issued as draft for comment to the meeting attendees, comments and suggested amendments should be sent back to the project lead.

All comments should be discussed between the project lead and sponsor and then revised documentation shall be issued for ‘Sign-off’

Technical Sign-off model

Agreement of the project requirements, benefits, success criteria, user acceptance criteria & success factors will be reached by following the three step model below:

Step 1

It is expected that agreement will be reached through business as usual activities and the involvement of the roles identified below, it may be necessary to revisit the ‘sign-off’ activity in order to reach agreement with all of the roles involved.

Wholesale Business Area Roles

Au

tho

rity

Operations

Engineering

Asset Manager and / or Operations Representative

Engineering team lead and technical authorities

Aw

are

nes

s

Programme Services

Supply Chain

Construction Project Manager

Contract Formulator




Step 2

In the event that agreement can’t be reached through business as usual activities then the project will be escalated through to the roles below, where it is anticipated agreement will be reached.


Au

tho

rity

Operations

Engineering

Asset Manager, Area Production Manager and / or Area Engineering Manger

Engineering service manager and / or Chief Engineer

Aw

are

nes

s

Programme Services

Supply Chain

Capital programme manager

Area contract manager

Step 3

In the unlikely event that agreement can’t be reached through level 2 involvement then the project will be escalated through to the roles below, where agreement will be made.


Au

tho

rity

Operations

Engineering

Asset Manager, Area Business Manager

Head of Project Engineering

Aw

are

nes

s

Programme Services General Manager


Project gate reviews

The engineering team lead shall confirm the activities that have or have not occurred and provide a brief overview of the project, focusing on the technical aspects; providing further insight as required, allowing the Technical Authorities to sign off the applicable form on the Gate Review SharePoint site

Gate reviews are carried out at different points in the project lifecycle as laid out in the associated appendices.

http://shp13-apps/apps/ER/SitePages/Gate%20review.aspx


Project check, review and approval

The engineering deliverable which is passed outside of United Utilities engineering to a third party such as other directorates, contractors, regulators, sub-consultants, etc. can be broken down into a series of deliverables; the term deliverable is used for reports, drawings, calculations, etc.

Production of technical calculations, reports, models etc and the completion of checking, reviewing and approving are planned and systematic actions necessary to provide adequate confidence that the engineering deliverable [employees works information, commission order, report, etc.] will fulfil the project requirements and deliver the project benefits stated in the business case.

The project engineering team (engineering team lead & disciplines) should discuss and agree the checks, reviews, and approvals necessary to ensure that the deliverable(s) will fulfil the project requirements; depending on the scope of the project checks, reviews, and approvals may also be required from other directorates within United Utilities [Operational Technology and / or Quality & Scientifics].

Purpose

The reviews are designed to detect failure before it occurs (preventative controls). Should a problem be identified, these reviews provide the opportunity to propose remedies and decide on the action to take.

Checking – to pick up detailed errors

Reviewing – to agree at the outset what is to be done and ensure the deliverables are fit for purpose

Approving – to ensure the various deliverables have the desired result

Checker and reviewer; responsible for ensuring that deliverable is of appropriate quality (this can be the same person)

Approver; does not study the deliverables (unless they are also the checker or reviewer)

The check, review and approval activities are carried out as laid out in the associated appendices, the following activities are required to comply with the check, review & approve process;

Originating

There are some general principles to be adhered to for all deliverables, details of these; templates to be completed, report formats etc. will be advised by your engineering team lead / chief engineer.

The production of a deliverable shall be clear and concise (understanding the scope and purpose), the deliverable may include a (where appropriate);

High level overview of the approach to be used

Précis of critical information being used and its source

Summary of results, conclusions and recommendations and any further work required

It is the responsibility of the originator to ensure that all deliverables are reasonable and correct – checking does not absolve originator from this responsibility.


Checking

The person checking should have sufficient knowledge & experience (if in doubt clarify with engineering team lead / chief engineer). The same checker should be used (as far as possible) for all revisions of a deliverable.

The role of the checker is to check deliverables to an appropriate level of detail. They can only check the deliverable for the information presented. If the deliverable is subject to revision / changes the deliverable may be required to be checked once more. It is always appropriate for the checker to challenge the overall design concept / philosophy, though this should have been confirmed at an earlier stage by the reviewer. The level of experience of the originator is a relevant consideration when the checker decides how detailed a check is required.

Reviewing

The person reviewing should have sufficient knowledge & experience (if in doubt clarify with engineering team lead / chief engineer), generally this is somebody more senior / experienced than the originator and checker who is looking for overall adequacy, suitability, etc. and to be reassured that thorough checking has occurred.

The reviewer shall be involved from the outset of the project to establish what deliverables shall be produced by whom and what level of checking and reviewing will be required. They should agree the design concepts, how they are to be delivered, and what assumptions etc. are appropriate.

The role of the reviewer is to ensure (where appropriate); the method adopted is suitable, that the outputs are reasonable, any options are properly evaluated, that the solution is going to work and that the risks have been considered and quantified.

Approving

The engineering team lead approves the work but does not study the deliverables, they accept that the deliverable can be included as part of a larger package or sent out as meeting the initial requirements, having confirmed that appropriate deliverable check and reviews are in place.


Project technical assurance

Technical assurance is a systematic process of checking to ensure externally produced deliverables will meet specified requirements. The general approach to the level of technical assurance required is dependent on the complexity of the project. The higher the levels of risk and complexity for a project the more technical assurance will be required. The technical assurance activities are carried out as laid out in the associated appendices

Each deliverable required by United Utilities will be submitted in line with digital asset information management requirements. Deliverables from contractors will normally be made available via ‘ProjectWise’ or other ‘electronic document management system’ as may be required by United Utilities

It is not intended that technical assurance reviews will stop projects in flight. If issues are flagged that suggest the original requirements in the works information are at risk the process for escalation in the NEC 3 contract should be followed. If no contract is in place then the core team led by the engineering team lead and the contractor should work to agree appropriate action to ensure that the original requirements contained within the works information are met.

Any changes to the list of deliverables made post contract award shall be notified via the project team lead giving an instruction to the contractor.

Setting the levels of technical assurance

The level of technical assurance required should reflect the technical complexity of the project and the associated business risks identified prior to contract award. To ensure full alignment with the United Utilities vision and to support the strategic business initiatives within the wholesale operating model it will be appropriate for the project core team and the following functions to be consulted

Asset Manager

Area Engineering Manager

Operational Technology

Discipline Engineers

Asset Integration

The deliverables required for technical assurance points will be outlined by United Utilities prior to the release of the project tender documentation.

An estimate of the discipline input required to support technical assurance will be produced by the engineering team lead in consultation with each discipline lead, prior to issue of the information to tenderers. This estimate will be revised as appropriate prior to future gate reviews

The deliverables required for technical assurance points will be confirmed by United Utilities and the contractor prior to the release of the project contractual documentation.

Technical assurance pre-contract award

Technical assurance reviews may be required during the tender period, typically around mid-bid review, tender evaluation or prior to contract award.

The contractor will be given opportunity to review the technical information required to satisfy the employer of a technically compliant bid at the beginning of the tender period, and propose modifications/ changes to the information requirements based on the levels of business risk on United Utilities based on the contractors proposed solution.


Any proposed changes to the information provided will be submitted for discussion and agreement with United Utilities prior to the mid bid review, with an opportunity to update following the mid-bid review. United Utilities must be informed of any known proposed deviations from the asset standards prior to tender evaluation.

TAP 1 – Consists of a technical review meeting between United Utilities and the contractor bid teams to discuss whether the technical information supplied by United Utilities is being used appropriately during the bidding process, and to undertake a preliminary review of information prior to the formal submission of the contractor tender returns.

TAP 2 – Consists of the formal review of information provided by the contractor as part of tender return, which contributes to the evaluation of the tenders and selection of the preferred contractor. During the development of the tender return the contractor will review the technical complexity of the project which should drive the level of technical assurance they foresee required during the delivery of the project.

TAP 2a – Consists of a logged and recorded meeting between United Utilities and the contractor as part of the technical review of the additional information provided by the contractor prior to contract award, deliverables will be agreed and captured on the BEP in line with digital asset information management requirements, prior to contract award to establish a baseline schedule for subsequent technical assurance reviews.

Technical assurance post-contract award

The number and frequency of post contract award technical assurance reviews should assure the project requirements will be met as the solution matures and reflect the risk & complexity of the project. These reviews would typically be required at key points during the design and as part of the technical acceptance of the project solution.

Technical assurance may include reviewing that appropriate checking and technical governance has been undertaken by the contractor. If sufficient assurance cannot be obtained then Untied Utilities can audit project documentation in more detail, or, with agreement of the contractor, ask another contractor to undertake a review on behalf of United Utilities

TAP 3 Outline design – Consists of a logged and recorded meeting between United Utilities and the contractors as part of the technical review meeting between United Utilities and the contractors design team in order to confirm solution integrity and provide assurance that the design direction satisfies the project need and requirements in order to deliver the agreed project benefit based on the works information.

TAP 4 Detailed design – Consists of a logged and recorded meeting between United Utilities and the contractor as part of the technical review between United Utilities and the contractors design teams, as deliverables are submitted to United Utilities during the detailed design period, the review may be single review or multiple reviews. Deliverables will be required to be submitted by the contractors to United Utilities as stated in the employer’s works information and agreed as part of the schedule of design deliverables. The documents suggested for review should be integral to establishing whether the design deliverables meet the need as specified in the works information.

TAP 5 Agreement to operate– Consists of a logged and recorded meeting between United Utilities and the contractor as part of the technical review of the project prior to agreement to operate by United Utilities.

TAP 5a Contract completion – Consists of a logged and recorded meeting between United Utilities and the contractor as part of the technical review of the project prior to contract completion by United Utilities.

TAP 5b Final acceptance – Consists of a logged and recorded meeting between United Utilities and the contractor as part of the technical review of the completed project prior to final acceptance by United Utilities.


Technical acceptance

When contractors submit deliverables for acceptance, United Utilities will undertake the acceptance review process within the response time. The engineering team lead may request a meeting with the contractor (during the response time) to discuss specifics of his deliverables. If any third parties or stakeholders are to review / approve the contractor deliverables, this must be done within the response period The response time for a deliverable issued for acceptance is the period of reply, as specified in Contract; 14 days unless a different period of reply has been specified.

The engineering team lead should therefore read the employers works information and identify what deliverables are to be provided by the contractor. Any deliverable should be included in the accepted programme and monitored by the project manager. Deliverable acceptance should be managed in line with digital asset information management requirements. It is important to note that the only reasons for the engineering team lead not accepting contractor deliverables is if they do not comply with either the employers works information, other applicable provisions of the contract or applicable law

Contractors may submit deliverables for acceptance in parts if the deliverable for each part can be assessed fully. The technical authority shall rate each of the required particulars under one of the following:

Accepted

Not accepted - do not comply with either the works information or applicable law or other applicable provisions of the contract

We are not obliged to check the contractors design for mistake. Acceptance does not relieve the contractor of their design liabilities or obligations. However, if we do spot an error or mistake, we have a duty to point it out. It could be argued that a mistake or error equates to not complying with the works information and therefore is not acceptable

Technical acceptance process

1. Contractor drop deliverables in line with digital asset information management requirements and notifies the project lead [via CEMAR] that the technical acceptance deliverables have been dropped

2. The project lead informs the engineering team lead that the technical acceptance deliverables have been ‘dropped’ and are ready for review.

3. The engineering team lead has the period of reply to issue a response to the project lead – technical acceptance deliverables have been accepted or not accepted

o The engineering team lead informs discipline teams and technical authorities

o Discipline provide insight of deliverable quality to engineering team lead – ENT 003

o The engineering team lead completes the technical assurance record – ‘one liner’ for each deliverable identified for acceptance

o Technical authorities review technical assurance record and provide a ‘positon’ – accepted or not accepted

The technical assurance record MUST be signed by the technical authorities within the period of reply, if the technical authorities can’t sign they MUST escalate through their technical authority hierarchy

4. The engineering team lead informs the project lead [via BC] of the technical authorities ‘position’ [the technical assurance record should be passed to the project lead]

5. The project lead informs the contractor [via CEMAR] of the technical authorities ‘position’ [the technical assurance record should be passed to the contractor]


Digital asset information management [DAIM – BIM]

In order to deliver efficiencies in the way we operate our assets we require accurate and maintained information about them and adopting a BIM way of working will, along with our other data and information initiatives, help us achieve this.

An asset centric approach throughout the project lifecycle i.e. IAP to Handover and Closedown is key to being able to retrieve, reuse and integrate digital asset information efficiently. United Utilities have developed a ProjectWise (PW) environment to be able to do this and all asset centric data and information will managed in PW.

Adopting the principals of a level 2 BIM way of working for the capital delivery phase of projects is written into the construction delivery partner contract through schedule 3 and 13 and forms part of all other contracts through the Standard Specification S13 (information requirements).

It is crucial that United Utilities & its contractors deliver data and information that is compliant with S13 United Utilities’ information requirements specification; in short all asset related data and information should be stored in ProjectWise.

Data and Information Exchange

Traditionally information exchange is a back end activity which often leads to issues of poor data quality and/or poor data completeness. Adopting a BIM way of working introduces a series of information exchange points known as data drops.

This is to ensure that information exchange is started as early as possible in a project with increasing detail as the project progresses.

To assist our contractors deliver data and information performance that is compliant with S13 United Utilities have outlined the various data drops which are intended to afford United Utilities the opportunity to confirm the contractor is exchanging data and information in accordance with United Utilities’ standard specifications, codes of practice and design guides.

[The data requirements for each data drop are described in S13]

[PAS 1192-2:2013: Clause 3.25: defines information exchange as – Structured collection of information at one of a number of pre- defined stages of a project with defined format and fidelity.]

Information Manager

In order to support the level 2 BIM way of working an Information Manager is to be appointed for each project to perform the duties described in Standard Specification S13. The information manager role may be carried out as part of a wider set of duties and, where practicable, the role may also transfer from one individual to another during the different phases of a project. The contractor shall nominate from his employees a suitable candidate for the information manager. However, United Utilities retains the option to appoint an information manager from within the employers’ organisation.

For major capital projects United Utilities will initially appoint the information manager from within its organisation and at the appropriate time, to be decided by United Utilities, the contractor shall nominate from his employees a suitable candidate who will be appointed as the information manager following an appropriate transition period.

For each contractor programme the contractor will appoint a programme information manager who will work with the employers appointed information manager.


The information manager role is an independent role that acts on behalf of all project team members including employer/ purchaser, designer, contractor and any sub- suppliers and covers three main areas:

CDE Management

Information Management

Collaborative working, information exchange and compliance

[Further details of the role can be found in Standard Specification S13]

BIM Execution Plan (BEP)

As part of the tender return the contractor shall return the pre-contract BEP for evaluation. The BEP will be reviewed to ensure it addresses the employers/purchasers information requirements set out in S13. Following contract award the contractor shall submit a more detailed post-contract BEP to explain the contractors and contractors supply chain’s methodology for delivering the project using BIM.

[PAS 1192-2:2013: Clause 3.6: defines a BEP as – Plan prepared by the suppliers to explain how the information modelling aspects of a project will be carried out.]

Common Data Environment (CDE)

United Utilities understand the value of having trusted asset centric data and information and have provided a client owned common data environment for contractor and internal staff to originate and manage asset centric data and information which will deliver the safe passage of this data and information to United Utilities’ wider business. As digital data becomes more prevalent so does the risk of cyber-attacks. Having the ability to extend our common data environment to our many contractors is part of how this risk can be managed.

[PAS 1192-2:2013: Clause 3.13: defines the common data environment as – Single source of information for any given project, used to collect, manage and disseminate all relevant approved project documents for multi-disciplinary teams in a managed process.]

Data and Information Performance (DIP)

In order to deliver the level 2 BIM way of working DIP reviews will be scheduled throughout the project lifecycle, it is not intended that DIP reviews will stop projects in flight, if issues are flagged that suggest the information requirements as stated in S13 are not being met the process for escalation in the relevant contract shall be followed.

The DIP review process will confirm performance measured against identified data and information requirements at points along the project delivery phase.

In summary:

Production of a pre-contract BEP

Updated post-contract BEP

Compliance with S13 and BS1192:2007 PW module with respect to the CDE.

Information exchange (Data drop process)

Information Integration

Supply Chain Management

Health and Safety File Management


Standard deviations

The adoption of standards is intended to exploit the knowledge we have gained from previous experience in order to achieve program efficiencies in terms of time, cost or quality or to deliver health & safety benefits. Any movement away from United Utilities standards has the potential to alter the balance between risks [opportunities & threats] and benefits and requires an appropriate degree of consideration before being implemented.

Innovation is a strategy to seek and deliver innovative ideas that align with United Utilities’ key objectives of improving efficiency, health & safety, customer satisfaction & business processes. United Utilities standards must not be allowed to present a barrier to innovation or the exploration of knowledge which can bring improvements in TOTEX or health & safety.

Where contractors use United Utilities asset and engineering standards in their designs, a system & process has been implemented which gives contractors the flexibility to challenge & deviate from standards. The standards challenge, deviation and technical enquiry process enables contractors to apply best practice and deliver continuous improvement in the development of design and construction solutions. The process will ensure that all technical questions are managed in a timely and consistent manner and will capture the knowledge and innovative ideas that can be used to further improve United Utilities asset & engineering standards, other knowledge stock & knowledge flow across organisations.

Gold, Silver & Bronze categorisation

Gold, Silver and Bronze categorisation of United Utilities asset standards provides contractors with improved visibility of where they can deviate from asset standards & innovate. To assist with the interpretation and application of asset standards, the following system has been adopted, denoting three different levels of standards content:

Gold – These elements are mandatory and are imposed by way of statute, regulation or United Utilities company policy, or are imperative to ensure permit compliance and are indicated by bold text

Silver – These elements represent ‘best practice’, as defined contractually or as recognised either industry wide or within United Utilities and are indicated by normal text.

Bronze – These elements simply provide additional explanation and guidance and are indicated by italicised text.

Access to the system and documentation

The engineering service provider and contractors will access the standards deviation, challenge and technical enquiry capture form and guidance documentation using the knowledge sharing platform on the United Utilities contractor collaboration portal. The engineering service provider or contractor will e-mail the completed capture form to the United Utilities standards mailbox: [email protected]

United Utilities personnel will access and submit the capture form using the standards deviation, challenge and technical enquiry homepage located on United Utilities engineering sharepoint.

Submission of standards challenges, deviations and technical enquiries

Technical Questions can be broken down into three categories, standards challenges, deviations and technical enquiries;

Category 1 – Standard Challenges

Standard challenges are raised where the originator believes the content of the standard to be incorrect or does not reflect best practice. Standard challenges may be raised by the

mailto:[email protected]


engineering service provider, contractor or United Utilities personnel (e.g. on behalf of contractors). To reduce project delays it is preferable to submit standard challenges outside of project lifecycles. That said, United Utilities acknowledge that standard challenges will naturally arise from within projects and they will be evaluated. Non project-related standard challenges may be submitted at any time. Project related challenges must be submitted as early as possible in the project lifecycle, and prior to tender submission, allowing sufficient time for evaluation by United Utilities.

Category 2 – Standard Deviations

Standard deviations are raised where there is a need to deviate from the standard for a particular project, but not to change the standard. Standard deviations will be raised by the contractor or United Utilities personnel (e.g. on behalf of contractors). Standard deviations are to be submitted during the tender process, and prior to tender submission, allowing sufficient time for evaluation by United Utilities. Where standard deviations are identified during detailed design or construction they must be submitted to United Utilities using the standard deviation process.

Category 3 – Standard-related Technical Enquiries

Standards-related technical enquiries are raised where there is doubt regarding the interpretation of wording within the standard and clarification is required. Standard-related technical enquiries can be raised at any time by engineering service provider, contractor or United Utilities personnel (e.g. on behalf of contractors).

Process

The knowledge sharing platform on the United Utilities contractor collaboration portal and standards deviation, challenge and technical enquiry homepage on United Utilities engineering sharepoint host more detailed information on the process including guidance documentation, the scope of the process (i.e. which United Utilities standards fall within the deviation process), user manuals, swimlane etc. The following steps summarise the process;

1. Where applicable, the originator informs the United Utilities engineering team lead of the proposed submission who then relays the information to the project team.

2. Originator discusses the proposed standards challenge, deviation, and technical enquiry with a standards engineer prior to submission.

3. Originator submits the challenge, deviation, and technical enquiry capture form to United Utilities (externally via United Utilities standards mailbox or internally using engineering sharepoint).

4. Standards engineer reviews the capture form and assigns a standard owner through consultation with discipline teams.

5. Standard owner reviews the form, discusses content with the relevant stakeholders and assesses validity, impact, risks, benefits etc.

6. Standard owner submits technical response to the approver(s).

7. Approver(s) review technical response and accept or reject the challenge, deviation, technical enquiry.

8. Standards engineer reviews the technical response and determines whether a standard requires updating through discussion with standard owner. Where applicable, the standard or the standard development record is updated in consultation with the standard owner.

9. Standards engineer submits technical response and decision to originator and engineering team lead.


The technical response and decision should be submitted to the originator within 7 days of receipt of the capture form, however, it is accepted that some requests will be more complex and may require 14 days turnaround.

The standard engineers will monitor the performance of United Utilities engineering in submitting technical responses to originators within the required turnaround time and will monitor the number and quality of the standards challenges and deviations received from the engineering service provider and contractors.

Approvers

The following roles will approve or reject challenges, deviations & technical enquiries on receipt of the technical response from the standard owner:

Standard Challenges – Principal Engineer

Engineering Standard Deviations – Principal Engineer

Asset Standard Deviations – Principal Engineer and Asset Manager

Standard-related Technical Enquiries – Standard Owner

Escalation

In the event of a dispute between the originator and the standard owner following rejection of a challenge or deviation, the matter will be referred to the United Utilities chief engineer whose decision is final; consultation will take place between the chief engineer and asset manager where appropriate.


Re-use of company knowledge [RoCK]

Re-use of company knowledge [RoCK] has been developed to ensure that United Utilities learn from the past and deliver effectively & efficiently in the future.

The RoCK process will ensure that all opportunities, risks and lessons learned are captured and re-used (where applicable) at every opportunity in the future. It is believed that this approach will help further embed technical governance through BAU activities - ensuring the right technical knowledge is applied at the right time in the right way.

By reusing what we have learnt from the past and by capturing what we are learning through the current project lifecycles we can ensure that every opportunity to deliver effectively & efficiently is pulled from the projects we are delivering now and pushed in to the projects we are going to deliver in the future.

The RoCK output document is issued to our contractors as part of the tender pack information for tenderers] and is re-submitted back to United Utilities as part of the tender return, it is then maintained by our contractor/contractor throughout the project lifecycle. Opportunities used by the project team for more effective / efficient solutions should be identified and an indication of the associated benefit should be noted.

The RoCK output document is issued and reviewed at the following points [milestones] in the project lifecycle:

Project start-up –formally issued within United Utilities

The RoCK output doc is issued internally within United Utilities to ensure any opportunities can be considered by the United Utilities project team to ensure the right data is gathered

Tender Issue - formally issued to contractor by United Utilities

The RoCK output doc is attached to the information for tenderers with the following words:

Appendix a, is the RoCK output document identifying potential opportunities from the Re-use of Company Knowledge (RoCK) database. The contractor/contractor shall be expected to review the information and take it into account when developing their tender submissions, indicating (in the RoCK return) which items have been considered and which items have / will be used in the proposed solution.

Tender Return - formally issued to United Utilities by contractor

The following words are included in the tender evaluation template:

Tenderers are required to review the information contained in the Re-use of Company Knowledge (RoCK) output document and take it into account when developing their tender submissions, indicating in the RoCK return, which items have been considered and which items have / will be used in the proposed solution”.

Start on Site & Contract Completion - formally issued to United Utilities by contractor

The following words are included within the employee’s works information:

The RoCK output document is to be maintained by our contractors throughout the project lifecycle. Opportunities used by the project team for more effective efficient solutions should be identified and an indication of the associated benefit should be noted. The RoCK output document should be formally issued to United Utilities at two key milestones;

Start on Site


Contract Completion

By adopting the ‘pull / push’ methodology in our projects we can reduce risk, maximise on benefits and ensure we deliver our part of the ‘efficiency challenge’ whilst improving the effectiveness of the solutions.


TECHNCIAL GOVERNANCE COMPLIANCE

Engineering are accountable for technical leadership and governance in all activities that the company undertakes. To ensure technical governance is carried out in line with this document and the associated appendices the ‘3 lines of defence’ compliance approach is applied – doing the right thing, in the right way at the right time.

Three lines of defence

The three lines of defence approach consists a series of checks which are captured on the engineering assurance programme to ensure that the technical governance processes are being complied with;

1st line of defence – Engineering assurance

2nd line of defence – Wholesale assurance

3rd line of defence – Corporate audit

1st line of defence - engineering assurance

Engineering assure themselves that technical governance is carried in a three ways;

Monthly technical governance compliance

Process reviews

Maturity assessments

Monthly compliance

Carried out on projects in the Capital Programme Management System [CPMS] through a ‘look-up’ against actualised milestones and the completion of the associated sharepoint forms. The approach provides management with the information required to make positive interventions to ensure all necessary activities are completed in a timely manner.

Process reviews

Process reviews are carried out on projects [CPMS & non CPMS] as and when required, the review provides an understanding of how the process is currently being performed, the tools that support the process and the people involved. The review should also help to highlight areas of best practice, opportunities for change and non-compliance. Process reviews are carried out by following the approach bulleted below

What are you trying to do?

How are you doing it?

What does and doesn’t work?

How it might be done better?

Maturity assessments

Maturity assessments are carried out with contractors in order for engineering to better understand the level of understanding the contractor has with regards to United Utilities technical requirements. It is believed that by adopting this collaborative review areas of best practice, opportunities for change and non-compliance can be identified.

2nd line of defence - wholesale assurance

http://flow/whsl/Eng2/TechnicalGovernance/Restricted%20Area/TGMR%20Update/TGMR%20Doc/Engineering%20Assurance%20Programme/Engineering%20Assurance%20Programme%20-%20v1.xlsx


An independent check carried out by the wholesale assurance team to assure the wholesale business that engineering are working in line with our agreed processes. These checks are agreed at the beginning of the financial year and captured on the engineering assurance programme. The wholesale assurance team carry out these checks in two ways,

Monthly compliance

Themed audits

Monthly compliance

Carried out on projects in CPMS that actualise the milestones associated with the production of two key engineering deliverables; employer’s works information [prior to tender issue] and employer’s works information [prior to contract award].

Two projects are identified for each activity [dependant on the number of projects with actualised milestones being available] a series of checks are carried out, results are reviewed / published on the engineering scorecard.

Themed audits

Themed audits are scoped by the wholesale auditor and signed off by the appropriate engineering leadership team member, when the audit has been completed the audit report [including findings] is reviewed and signed off by the same person who scoped the audit.

3rd line of defence - corporate audit

An independent check carried out by corporate audit to assure the company that engineering are working in line with their agreed processes. Corporate audits are planned at the beginning of the financial year and captured on the engineering assurance programme.

Corporate audits are scoped by the corporate auditor and signed off by the engineering director, when the audit has been completed the audit report [including findings] is reviewed and signed off by the engineering director.

Corrective action

Corrective action will be taken to ensure all processes and tools are used appropriately, if any trends are identified in the information provided the appropriate preventative actions will be taken to ensure the route cause is understood and any corrective actions identified are closed out in a timely-manner.

Monitoring

The engineering assurance programme will be reviewed by the engineering leadership team during their monthly performance meetings.





APPENDIX: MAJOR CAPITAL PROJECTS [MCP]

This appendix aims to provide a greater level of detail on when the technical governance activities are applied within major capital projects to ensure the right level of technical knowledge, expertise and experience is available at key points in the project lifecycle. The activities identified within the picture below [or via this LINK for greater granularity] should be used as a framework.

All technical governance activities required and the sequence of when these activities should take place shall be agreed by the project engineering manager and the technical authorities on a scope / risk / delivery method approach.

http://flow/whsl/Eng2/TechnicalGovernance/Restricted%20Area/TGMR%20Update/MCP/Delivery%20Framework%20template%20-%20MCP.pdf


APPENDIX: STUDIES & INVESTIGATIONS [S&I]

This appendix aims to provide a greater level of detail on when the technical governance activities are applied within studies and investigations to ensure the right level of technical knowledge, expertise and experience is available at key points in the project lifecycle. The activities identified within the pictures below [or via this LINK for greater granularity] should be used as a framework.

S&I Workstreams

S&I Projects delivered within Engineering

S&I Reports delivered by 3rd Party Organisation


http://flow/whsl/Eng2/TechnicalGovernance/Restricted%20Area/TGMR%20Update/Studies%20%20and%20Investigations/Delivery%20Framework%20template%20-%20S%20and%20I.pdf


APPENDIX: ASSET MAINTENANCE SUPPORT [AMS]

This appendix aims to provide a greater level of detail on when the technical governance activities are applied within asset maintenance support to ensure the right level of technical knowledge, expertise and experience is available at key points in the project lifecycle. The activities identified within the pictures below [or via this LINK for greater granularity] should be used as a framework.


http://flow/whsl/Eng2/TechnicalGovernance/Restricted%20Area/TGMR%20Update/AMS/Delivery%20Framework%20template%20-%20AMS.pdf


APPENDIX: AREA DEPLOYED TEAMS [ADT]

This appendix aims to provide a greater level of detail on when the technical governance activities are applied within area deployed teams to ensure the right level of technical knowledge, expertise and experience is available at key points in the project lifecycle. The activities identified within the pictures below [or via this LINK for greater granularity] should be used as a framework.

The technical authority role is carried out by the Area Engineering Manager [AEM], as such the AEM is responsible for carrying out technical governance within the ADT.

Business as usual [BAU] governance is carried out on the project activities detailed above through BAU engineering processes.

Technical governance activities required are currently being discussed within the AEM community and will be detailed above when agreed.

http://flow/whsl/Eng2/TechnicalGovernance/Restricted%20Area/TGMR%20Update/ADT/Delivery%20Framework%20template%20-%20ADT.pdf

technical governance mandatory requirements

Documents