SECTION I: AGILE (SCRUM) METHODLOGY

INTRODUCTION

1.0 Governance

1.1 Having an effective software project governance process is critical to enable a Customer and Supplier to monitor risk, report and discuss the progression of the delivery of a software solution, and track and resolve any deviation from the agreed project schedule and performance obligations.

1.2 These governance terms are for inclusion in an Agile (scrum) software development, implementation, and services project contract (Agreement). The Agreement typically also includes key terms in relation to intellectual property rights, confidentiality, termination rights and liability limitations and/or exclusions.

2.0 Conflict Management and Dispute Resolution

2.1 Conflict management and dispute resolution are not mutually exclusive. They are sequential in a spectrum of processes designed to enable the Parties, acting and working in a spirit of mutual trust and cooperation, to enhance the status of the Agreement as a collaborative engagement.

2.2 Conflict Management is directed to the Parties:

• (a) identifying and notifying each other at the earliest possible time of any matter or event which could affect the progress, cost, completion, and/or impair the performance and/or quality of the project (Risk Event); and
• (b) engaging in dialogue to consider and agree on what steps need to be taken to avoid or mitigate the effect of the Risk Event, and, where appropriate, agree on compensation or other adjusted commercial positions.

2.3 Dispute Resolution is directed to those circumstances where the Parties are unable to resolve matters between themselves and enables them to refer such matters to a neutral and independent person to assist in the resolution of any difference or dispute in a prompt, private and cost-effective manner by:

• (a) a managed and structured negotiation process (Mediation); and/or
• (b) a determinative process (Adjudication and/or Arbitration).

2.4 The terms below in sections 5 and 6 set out firstly conflict management and then dispute resolution processes and then procedures for inclusion in the Agreement.

CONTRACT MODULE TERMS

Drafting note: Due to the specific terms agreed by parties for a project, sections 3 and 4 may be modified for incorporation into the relevant Agreement.

3.0 Definitions

3.1 Unless the context requires otherwise, in this Agreement:

• Acceptance Criteria means acceptance criteria set out in a particular User Story and any additional criteria set out in Schedule 1.
• Acceptance Test means a test on a particular Outcome by the Customer (per clause 4.16 b) to determine compliance with the Acceptance Criteria.
• Agile Development Process means as described in clauses 4.1 to 4.25.
• Agile Change Control Process means as described in clause 4.25.
• Business Day means a day other than Saturday, Sunday or a day that is a public holiday or non-Business Day at the usual place of residence of the Supplier or the Customer.
• Commencement Date means the date when the Parties sign the Agreement unless by agreement the Parties commence the Services before the execution date, then in such circumstances that date.
• Daily Scrum Meeting means a meeting of the Development Team on each Business Day during the Project Term to discuss:
  • (a) tasks completed on the previous Business Day;
  • (b) tasks to be completed on the current Business Day; and
  • (c) any potential or actual risks to attaining the Sprint Goal including the status of any dispute escalated under the Dispute Resolution Procedure.
• Definition of Done means the definition set out in Schedule 1 as amended from time to time under clause 4.11 b.
• Deliverable means, as applicable:
  • (a) object code and Source Code versions as described in the Software Description;
  • (b) object code and Source Code versions of all Delivered Outcomes; and
  • (c) all Documents.
• Delivery means compliance of a particular Outcome with the relevant Definition of Done and Acceptance Criteria and Deliver and Delivered shall be construed accordingly.
• Delivered Outcome means an Outcome that complies with the relevant Definition of Done and Acceptance Criteria under clause 4.16.
• Development Team means those individuals described in Schedule [X] (and their replacements from time to time approved under this Agreement).
• Development Team Key Member means the individuals described in Schedule [X] (and their replacement(s) from time to time approved under this Agreement).
• Dispute Resolution Procedure means negotiation, mediation, adjudication, or arbitration as set out in Section 6.
• Documents means any of operating manuals, user instruction manuals, technical literature, and all other related materials in human-readable or machine-readable forms supplied by the Supplier and referred to in the User Stories.
• Early Termination Election Date means the relevant date specified in Schedule 1 or the expiry date of the relevant Sprint.
• Outcome means the result of the development work carried out to meet a particular Requirement.
• Product Backlog means the current version of the Document based on the Product Vision (as referred to in clause 4.1) which comprises:
  • (a) the Requirements to complete as prioritised by the Product Owner, their respective Acceptance Criteria and any further details provided by the Product Owner;
  • (b) the Outcomes and Delivered Outcomes to date;
  • (c) the estimated business value of each Requirement; and
  • (d) the Resource Allocation for each Requirement, determined under clauses 4.4 and 4.14 b.
• Product Owner means the person identified in Schedule [X] responsible for setting out the Product Vision.
• Product Vision means the outline of the Project describing goals including benefits as set out in Schedule [X].
• Project means the scope of works set out in the Product Vision and User Stories included in the Product Backlog from time to time.
• Project Completion means the date on which the completion notice is given to the Supplier under clause 4.22.
• Project Personnel means the following persons:
  • (a) Development Team, including the Development Team Key Members;
  • (b) Scrum Master; and
  • (c) Product Owner.
• Project Term means the period commencing on the Commencement Date and ceasing on Project Completion or the earlier termination of this Agreement under clause x.
• Drafting Note: This refers to the Agreement clause that enables (a) either party to terminate based on material breach; or (b) a customer to terminate for convenience the Project after a Sprint due to the progress and the state of the working software delivered up to that date. Such termination rights are contemplated by the Early Termination Election Date term and cross referenced in Sections 4.20 and 4.21. See also the reference to ‘clause x’ in Software Description below and Section 4.
• Project Tools means these Project artefacts:
  • (a) Product Vision;
  • (b) Product Backlog; and
  • (c) a Sprint Backlog.
• Release Planning Session means a planning meeting between the Product Owner, Scrum Master and Development Team to:
  • (a) discuss whether the Software development remains aligned with the Product Vision; and
  • (b) evaluate cost and Project Term impacts from additions or deletions of Requirements from the Product Backlog.
• Requirement means the non-technical description set out in a User Story being intended operations, functions, performance, and other characteristics of the whole or part of the Software.
• Resource Allocation means the unit of measurement of the resource required for completion of:
  • (a) the Project and each Sprint as referred to in clause 4.3; and
  • (b) specific Requirements as referred to in clauses 4.4 and 4.14 b.
• Scrum Master means the Supplier appointed person as agreed in writing by the Customer (or any agreed replacement).
• Services means the services to be provided by or on behalf of the Supplier under this Agreement.
• Software means the software to be developed under this Agreement.
• Software Description means a comprehensive description of Software as at Project Completion or an earlier termination event date per clause x of the Agreement (and as referred to in clauses 4.20 and 4.21) that includes the following:
  • (a) design;
  • (b) functional; and
  • (c) other relevant details.
• Source Code means the source code of Software in the language the Software was written plus any related flowcharts and technical documents – the latter sufficient to enable the Customer’s development personnel (or its service provider) to understand, develop and maintain that Software.
• Sprint means a fixed period specified in Schedule 1 during which User Stories are developed, tested, and Delivered.
• Sprint Backlog means those terms set out in clause 4.11 c.
• Sprint Goal means the Delivery of all Sprint Outcomes by the end of the relevant Sprint.
• Sprint Meeting means any of Sprint Planning Meeting, Sprint Retrospective Meeting and Sprint Review Meeting.
• Sprint Outcomes means the Outcomes of a current Sprint.
• Sprint Planning Meeting means a planning meeting between the Product Owner, Scrum Master and Development Team to discuss the matters referred to in clause 4.9.
• Sprint Points means the points determined by the Product Owner for each Sprint under clause 4.7.
• Sprint Retrospective Meeting means a retrospective meeting between the Product Owner, Scrum Master and Development Team to discuss the matters referred to in clause 4.17.
• Sprint Review Meeting means a review meeting between the Product Owner, Scrum Master, Development Team, and any relevant Customer or Supplier party stakeholders that wish to attend, to discuss the issues set out in clause 4.16.
• Supplier Rates means the rates set out in Schedule X.
• User Story means a Requirement and its associated Acceptance Criteria.

3.2 Unless the context requires otherwise, in this Agreement:

• (a) words in the singular include the plural and vice versa; and
• (b) words importing a gender include every gender.

4.0 Development and Governance Process Terms

Product Vision

4.1 The Supplier and the Customer acknowledge that the Product Vision provides an overarching framework for the Project and agree that the Project Personnel will perform their roles and responsibilities in a manner consistent with that framework, and as reasonably practicable maximise the potential for attaining the goals outlined in the Product Vision.

Product Backlog provision

4.2 The Product Owner will be responsible for keeping the Product Backlog up to date. The Development Team may propose refinements or new items for inclusion in the Product Backlog.

Estimates

4.3 The Supplier acknowledges and agrees with the Product Owner’s estimates of the duration of the Project, the number of [two weeks] non-extendable Sprints required for Project Completion, and the Resource Allocations as specified in Schedule 1.

Resource Allocation determination

4.4 Within [five] Business Days of the Commencement Date, the Development Team must determine the Resource Allocation for each Requirement included in the Product Backlog on that date and notify in writing the Product Owner.

Requirements prioritisation

4.5 The Product Owner may prioritise the Requirements included in the Product Backlog as it sees fit.

Product Owner and Requirements

4.6 The Product Owner:

• (a) may change the priority of the Requirements included in the Product Backlog and delete Requirements from the Product Backlog;
• (b) must follow the Agile Change Control Process if it wishes to include any new Requirement in the Product Backlog; and
• (c) may not amend the number of Resource Allocations determined for specific Requirements.

Sprint Point allocations

4.7 Sprint Points will be allocated as follows:

• (a) not more than [insert amount]% to the Requirements to be met during the current Sprint (Sprint Maximum); and
• (b) not less than [insert amount]% to contingency and ongoing activities including Sprint Meetings engagement, estimation, supporting build creation and integrations, defect fixes, design activities, status reporting, and development process improvement.

Sprint Planning Meeting schedule

4.8 The parties must hold a Sprint Planning Meeting before the relevant Sprint commences.

Sprint Planning Meeting agenda

4.9 At the Sprint Planning Meeting for each Sprint:

• (a) the Product Owner must select Requirements from the Product Backlog that it wishes to be included in the current Sprint Backlog;
• (b) the Product Owner must notify the Development Team of the selected Requirements, their respective Acceptance Criteria and other relevant information;
• (c) the Development Team must determine how many of the selected Requirements can be developed during the current Sprint without exceeding the Sprint duration and notify the Product Owner; and
• (d) the Product Owner and the Development Team may agree to replace a higher-priority Requirement with a lower-priority Requirement bearing an equal or lesser Resource Allocation if it is technically expedient to do so.

Requirements selection

4.10 The Product Owner and the Development Team must use all reasonable endeavours to agree on the selection of Requirements to be included in the current Sprint Backlog.

Sprint Requirements Backlog

4.11 Once the Requirements to be included in the Sprint Backlog have been agreed under clause 4.9 (Sprint Requirements):

• (a) no alterations or additions may be made to the Sprint Requirements;
• (b) the Product Owner and the Development Team must review, and, if necessary, amend the Definition of Done for each Sprint Requirement; and
• (c) the Development Team must prepare the Sprint Backlog which must include:
  • (i) the Sprint Requirements;
  • (ii) the Resource Allocation for each Sprint Requirement;
  • (iii) the Definition of Done and Acceptance Criteria for each Sprint Requirement; and
  • (iv) a breakdown of each Sprint Requirement into specific tasks and allocation of these tasks to specific Development Team members.

Sprint – Backlog daily maintenance

4.12 The Development Team must maintain the Sprint Backlog and update it daily to reflect any changes in the Resource Allocations for any Sprint Requirement.

Sprint – Development Team responsibilities

4.13 During each Sprint, the Development Team must:

• (a) develop the Software in accordance with the Sprint Backlog and the Agreement; and
• (b) hold Daily Scrum Meetings.

Sprint – Review and collaboration

4.14 The Development Team and the Scrum Master must:

• (a) use all reasonable endeavours to achieve the Sprint Goal during the relevant Sprint; and
• (b) review the Resource Allocation for a Sprint Requirement and determine, whether any change in the Resource Allocation is needed.

Sprint conclusion review and planning meetings

4.15 Within [five] Business Days of the end of each Sprint, the Development Team, Scrum Master and Product Owner must hold the following review and planning meetings:

• (a) Sprint Review Meeting plus any agreed Customer or Supplier stakeholders that wish to attend;
• (b) Sprint Retrospective Meeting; and
• (c) Sprint Planning Meeting for the next Sprint.

Sprint Review Meeting agenda

4.16 At each Sprint Review Meeting:

• (a) the Development Team and Scrum Master will determine which of the current Sprint’s Outcomes meet their respective Definitions of Done, and notify the Product Owner accordingly; and
• (b) the Customer must determine which of these Sprint Outcomes materially meet the respective Acceptance Criteria in accordance with Schedule 1 procedure.

Sprint Retrospective Meeting agenda

4.17 At each Sprint Retrospective Meeting, the Product Owner, Scrum Master and the Development Team will agree on potential improvements to practices, teamwork or environment in future Sprints and then review their adoption appropriateness at the next Sprint Retrospective Meeting.

Product Backlog maintenance

4.18 The Product Owner must include in the Product Backlog any Sprint Requirement that has not been developed during the current Sprint and any Outcome that has not been Delivered (both of which shall be deemed to be an outstanding Requirement) and reset all priorities for all outstanding Requirements.

Release Planning Sessions

4.19 The Development Team, Scrum Master and Product Owner will hold Release Planning Sessions in accordance with the times, frequency and procedure set out in Schedule [X].

Next Sprint commencement

4.20 Subject to [clause x], the Project Personnel must promptly commence the next Sprint and clauses 4.1 to 4.19 will apply to them as if they were set out in full and each reference to the Sprint is deemed to refer to the next Sprint.

Agile development and governance process repetition

4.21 Subject to [clause x], the parties must repeat this Agile development and governance process and continue to do so until the end of the Project.

Project Completion

4.22 Project Completion is achieved once all Requirements in the Product Backlog have been Delivered and the Product Owner has notified the Supplier in writing (Completion Notice).

Deliverables delivery

4.23 Within [five] Business Days of receipt of the Completion Notice, the Supplier must provide the Customer with the Deliverables (in object code versions only).

Software Description review

4.24 The Supplier must provide the Customer with the Software Description for review and approval in accordance with the procedure set out in Schedule [X].

Agile Change Control Process

4.25 Where the Product Owner requests a new Requirement be added to the Product Backlog:

• (a) the Development Team must determine the number of Resource Allocations for that Requirement; and
• (b) the Product Owner may, at its sole discretion, remove from the Product Backlog an existing Requirement or multiple Requirements whose Resource Allocation or cumulative Resource Allocations equal or exceed the Resource Allocations determined under clause 4.25 a provided that the Development Team confirms that:
  • (i) the existing Requirement or Requirements have not already been selected for a Sprint and the proposed change is technically viable; or
  • (ii) the Supplier can deliver such new Requirement as an additional Requirement in accordance with the Supplier’s Rates.

5.0 Relationship Management

Governance principles

5.1 The governance processes set out in Clause 4 of this Agreement are to support each Party’s performance of their respective obligations under this Agreement, so that:

• (a) the Services are performed, and Deliverables completed promptly in compliance with this Agreement; and
• (b) the provision of the Services and delivery of the Deliverables are regularly monitored, and sufficient information between the parties is provided to ensure compliance with the Agreement and appropriate timely action is taken to deal with and resolve any problem or a Dispute.

Relationship aspirations

5.2 The Parties’ conduct in respect of the governance processes set out in Clause 4 of the Agreement will:

• (a) reflect commitment at executive levels to foster a mutually beneficial commercial relationship and successful outcome of the Project; and
• (b) support a relationship between the Customer and the Supplier that is characterised by cooperation, trust, openness, and a close working relationship at all relevant management levels.

Cooperation between the Parties

5.3 In furtherance of the governance principles and relationship aspirations in clauses 5.1 and 5.2 above, each Party will cooperate with the other Party by making information available and providing approvals (or rejections rather than approvals), as required under the Agreement within the periods specified, or, where no period is specified, in a timely manner.

Notification of a Risk Event

5.4 The Parties undertake to promptly notify each other by email to [enter role for each of Customer and Supplier] of any matter which could affect the cost of the Project or result in a delay in meeting a key Project milestone date and/or Project Completion date or impair the performance and/or quality of the Project (Risk Event).

5.5 The Customer and Supplier representatives, being initially for the Customer, the Product Owner, and the Supplier (to be specified from any of the Project Manager/Scrum Master/Development Team Key Member), will, at the earliest available date following the notification of a Risk Event, meet (including where part of any scheduled Sprint Meeting) to discuss the Risk Event and cooperate in:

• (a) understanding and discussing the Risk Event;
• (b) making and considering proposals for avoiding or mitigating the effect of the Risk Event;
• (c) agreeing on the risk mitigation actions that will be taken, by whom they will be taken and when they will be taken and ensuring all applicable reviews and approvals have been finalised within the Supplier and Customer organisations (the Agreed Solution); and
• (d) agreeing monitoring and reporting processes for the Agreed Solution.

5.6 If an Agreed Solution cannot be reached by the above representatives, the Customer and the Supplier executive representatives will meet and endeavour to reach an Agreed Solution.

Project continuance

5.7 Each Party will continue to perform its obligations under this Agreement as far as reasonably practicable given the nature of the Risk Event or Dispute.

6.0 Dispute Resolution

6.1 In the event of:

• (a) a Risk Event where, within fifteen (15) Business Days of notice of a Risk Event (unless that period is extended by written agreement), an Agreed Solution cannot be reached by the Parties’ representatives as set out in clauses 5.4-5.6; or
• (b) any other dispute or difference arising out of or in connection with this Agreement, or the subject matter of this Agreement, including any question about its existence, validity, or termination,
•       (a Dispute)
•       any Party may invoke these dispute resolution procedures by serving a written notice of Dispute (Notice of Dispute) on the other Party including a brief description of the nature of the Dispute and the relief or remedy that is sought.

Negotiation

6.2 The parties, by their notified authorised representatives, must within ten (10) Business Days of receipt of a Notice of Dispute (unless that period is extended by written agreement) meet and engage in good faith in negotiations to resolve the Dispute, and, where applicable, to attain Project resumption or progression.

Mediation

6.3 The Parties may engage a mediator to assist them to negotiate the resolution and settlement of the Dispute in which case:

• (a) the mediation will be conducted under the Mediation Rules of the New Zealand Dispute Resolution Centre (NZDRC Mediation Rules); and
• (b) the Parties will:
  • (i) meet their own costs and expenses;
  • (ii) share the mediator’s fees and expenses in equal proportions; and
  • (iii) pay to NZDRC the fees and expenses for mediation in the amounts and in the manner set out in the NZDRC Mediation Rules, in effect on the date of the Notice of Dispute, before the mediation commences.

6.4 Without seeking to limit the scope of Disputes that may be referred to mediation, the following matters are considered particularly suitable for reference to mediation:

• (a) Requirements scope and the selection of such requirements to be included in a Product Backlog;
• (b) non-functional requirements scope;
• (c) technical requirements scope;
• (d) services scope;
• (e) design scope and/or quality;
• (f) build quality;
• (g) Customer or Supplier personnel (including subcontractor) performance;
• (h) Sprint or Release planning;
• (i) Agile Change Control Process requests;
• (j) Definition of Done or Sprint Outcomes or Testing or Acceptance Criteria;
• (k) compliance of the Software Description with the Software Description definition;
• (l) any other Project milestone or Project Completion date(s); and
• (m) financial matters including disputed invoices.

Suspension of performance milestones during Negotiation and Mediation

6.5 Where the subject matter of the Dispute impacts compliance with a performance milestone as set out in this Agreement, for the period from and including the date of service of the Notice of Dispute until the completion of the negotiation and/or mediation process, being: either by unilateral termination of the negotiation or mediation process by either Party or by the Parties signing a written settlement agreement or ten (10) Business Days (unless that period is extended by written agreement); whichever is the lesser period (Suspension Period), then, as applicable:

• (a) the Party obliged to perform and or comply with a pending performance milestone date, will (unless otherwise agreed in writing), for the number of days that constitute the Suspension Period, be credited an equivalent number of Business Days to perform and comply with the applicable performance milestone date and the latter date will be deemed varied by agreement to that effect; or
• (b) where the Dispute involves a Party’s claim that a performance milestone date has passed and the other Party has failed to perform and comply with its relevant obligations as at that date, then the other Party will not be liable, only for those Business Days equivalent to the Suspension Period (unless otherwise agreed in writing), for any loss or damage suffered by the other Party, or, by any person claiming through that Party, for that period.

Adjudication

6.6 Any Party has the right to refer a Dispute to adjudication under the Adjudication Rules of the New Zealand Dispute Resolution Centre (NZDRC Adjudication Rules) and may exercise that right at any time whether or not the adjudication proceedings take place concurrently with any other dispute resolution procedure.

6.7 If a Party submits a Dispute to another dispute resolution procedure while the Dispute is the subject of an adjudication, the submission to that other dispute resolution process does not bring to an end the adjudication proceeding or otherwise affect the adjudication.

6.8 An adjudicator must terminate the adjudication proceedings on a Dispute if, before the adjudicator determines the Dispute, that Dispute is determined under another dispute resolution procedure.

6.9 The adjudicator’s determination will be binding on the Parties and will continue to be of full effect even though any other legal proceeding relating to the Dispute between the Parties is continued or commenced.

6.10 If a Party intends to commence legal proceedings to challenge an adjudicator’s determination, that Party must first comply in all respects with the adjudicator’s determination.

Arbitration

6.11 Any Dispute may be referred to and finally resolved by arbitration in accordance with the Arbitration Rules of the New Zealand Dispute Resolution Centre (NZDRC Arbitration Rules).

6.12 No Party may commence Arbitration other than commencing arbitration proceedings necessary to preserve its legal rights unless that Party has first complied with the procedures set out in clauses 6.1 – 6.10 above.

SECTION II: WATERFALL

SOFTWARE DEVELOPMENT, IMPLEMENTATION AND SERVICES PROJECT

INTRODUCTION

1.0 Governance

1.1 Having an effective software project governance process is critical to enable a Customer and Supplier to monitor risk, report and discuss the progression of the delivery of a software solution, and track and resolve any deviation from the agreed project schedule and performance obligations.

1.2 These terms are for inclusion in a Statement of Work (SOW) (or Schedule) to a Waterfall software development, implementation and services project contract (Agreement). The Agreement typically also includes key terms in relation to intellectual property rights, confidentiality, termination rights and liability limitations and/or exclusions.

2.0 Conflict Management and Dispute Resolution

2.1 Conflict management and dispute resolution are not mutually exclusive. They are sequential in a spectrum of processes designed to enable the Parties, acting and working in a spirit of mutual trust and cooperation, to enhance the status of the Agreement as a collaborative engagement.

2.2 Conflict Management is directed to the Parties:

• (a) identifying and notifying each other at the earliest possible time of any matter or event which could affect the progress, cost, completion, and/or impair the performance and/or quality of the project (Risk Event); and
• (b) engaging in dialogue to consider and agree on what steps need to be taken to avoid or mitigate the effect of the Risk Event, and, where appropriate, agree on compensation or other adjusted commercial positions.

2.3 Dispute Resolution is directed to those circumstances where the Parties are unable to resolve matters between themselves and enabling them to refer such matters to a neutral and independent person to assist in the resolution of any difference or dispute in a prompt, private and cost-effective manner by:

• (a) a managed and structured negotiation process (Mediation); and/or
• (b) a determinative process (Adjudication and Arbitration).

2.4 The terms below at Section 5 (Dispute Resolution) set out conflict management and dispute resolution processes and procedures for inclusion in the Agreement.

CONTRACT MODULE TERMS

3.0 Project Governance

Governance principles

3.1 The governance processes set out in Section 3 of this SOW are to support each Party’s performance of their respective obligations under this SOW and the Agreement, so that:

• (a) the Services are performed, and Deliverables completed promptly in compliance with this SOW and the Agreement and the agreed time periods; and
• (b) the provision of the Services and delivery of the Deliverables are regularly monitored, and sufficient information between the parties is provided to ensure compliance with this SOW and the Agreement and appropriate timely action is taken to deal with and resolve any problems, issues or Disputes.

Relationship Aspirations

3.2 The Parties’ conduct will:

• (a) reflect commitment at executive levels to foster a mutually beneficial commercial relationship and successful outcome of the Project; and
• (b) support a relationship between the Customer and the Supplier that is characterised by cooperation, trust, openness, and a close working relationship at all relevant management levels.

Cooperation between the Parties

3.3 In furtherance of the governance principles and relationship aspirations in Sections 3.1 and 3.2 above, each Party will cooperate with the other Party by making information available and providing approvals (or rejections rather than approvals), as required under this SOW and the Agreement within the periods specified, or, where no period is specified, in a timely manner.

4.0 Project Steering Committee

Drafting note: Due to the specific terms agreed by parties for a project, this Section 4 (as renumbered in an SOW (or Schedule)) may be modified for incorporation into the relevant Agreement.

Purpose

4.1 The main Governance forum is the Project steering committee (PSC). The PSC will be established and conducted in the manner set out in this Section 4.

4.2 The PSC’s primary purpose and objective are to conduct meetings to review the performance of the Services and delivery of the Deliverables by the Supplier and the completion of the Project in accordance with this SOW and the Agreement.

PSC meetings – Frequency, agenda and reporting

4.3 The table below sets out:

• (a) the frequency of the meetings; and
• (b) core actions or activities that are agenda items and reportable items, namely: