These Terms apply to a Statement of Work that is for a full Implementation of 2CloudNine Payroll
These Terms of Full Implementation are incorporated by reference into an Agreement which is formed by a Statement of Work for a full implementation of the 2CloudNine Payroll System on the Salesforce Platform.
Each Statement of Work creates an Agreement entered into in accordance with the procedure outlined in the MST between Agilyx and the Customer, and will state expressly that these Terms of Full Implementation apply.
As provided by the MST the Dictionary, Rules of Interpretation, Agilyx General Terms of Business, are incorporated into the Statement of Work by reference. The Data Processing Addendum is incorporated if expressly provided by the Statement of Work.
In these Terms of Full Implementation, in addition to those from the Dictionary, certain capitalised terms and phrases have their meaning as set out below:
Commencement Date means the date provided on the Statement of Work as the ‘Commencement Date’ or if no date is provided then the earliest Business Day since execution (including the same day, if it is a Business Day).
Conditional Determination means a Determination subject to certain conditions, as more fully described in the ‘Quality Control and Gateway Reviews’ subclause.
Determination means a decision made by the PSC at a Gateway Review, as described more fully in the ‘Quality Control and Gateway Reviews’ subclause.
Deliverable means the result or written output (which may comprise of any number of documents, source or object/compiled code) of a service performed by Agilyx (including Customer inputs) under the Statement of Work, which is created according to the ‘What are Deliverables’ subclause.
Data Migration means extracting, transforming and loading data from one environment to another, as outlined more fully in the ‘Data Migration’ clause.
Gateway Review means a meeting in the Governance Process as describe more fully in the ‘Quality Control and Gateway Reviews’ subclause.
Phase means the parties stepping through the five Stages of the Implementation Process in respect of a limited scope of works, as more fully described in the ‘The Implementation Process’ subclause.
Solution means the final built, tested and deployed 2CloudNine software solution, being the goal of the activities contemplated by the Statement of Work through the joint efforts of Agilyx and the Customer to step through the Implementation Process, overseen by the Governance Process.
Specifications mean the documented technical or detailed requirements of a Deliverable that are used to determine whether (or measure to what extent) the Deliverable meets its Acceptance Criteria, which for the avoidance of doubt cannot be unwritten, or implicit.
Test Script means a procedure for testing functionality used for the purposes of the Test Stage. Where Test Scripts are required they will be specified as a Deliverable in the Statement of Work.
Project means the overarching joint efforts of the Customer and Agilyx to produce the Solution as set out in the Statement of Work and these Terms of Full Implementation.
Project Planning Documents mean all documents (whether electronic or not) that are not Deliverables, tabled or produced by the parties for use in the Governance Process for purposes relating to the planning of the Project, its timelines, resourcing and efforts to produce the Deliverables or deliver services; this includes but is not limited to the Project Schedule.
Stage means the parties performing defined activities as they apply to the agreed scope of works relevant to the Phase. There are five Stages, the Plan Stage, Design Stage, Develop Stage, Test Stage, Deploy Stage, with the activities associated with each being defined in their own section of the Statement of Work.
Solution Build is a Deliverable but also refers to an uncompleted version of the Solution or a candidate for the completed Solution that remains subject to further work.
Acceptance Testing means the process of testing the Solution Build, as more fully described in the ‘Acceptance Testing’ subclause.
Online Ticketing System means a system that is suitable for issue tracking and resolution as described in this Agreement, the industry standard being Atlassian Jira with the Zephyr testing module.
This is a Statement of Work to perform a software implementation service which is comprised of Agilyx’s obligations, subject to the Customer’s input and co-operation, as set out in the Statement of Work.
Subject to the more detailed provisions of the Statement of Work, the software implementation service is made up of:
a multi-staged process to plan, design, configure (build), test and deploy the 2CloudNine payroll software for the Customer solution (Implementation Process); and
a governance process to provide oversight, reporting and joint decision making between the parties regarding the progress of the Implementation Process, including to provide decisions and approvals required to progress through that process (Governance Process).
The Implementation Process is broken down into the following:
Stages, of which there are always four (4) unless otherwise decided through the Governance Process or Statement of Work, being the Discovery Stage, Build Stage, Test Stage and Deploy Stage (note that Stages can be run concurrently); and
Phases, which must be agreed upon in the Statement of Work, or through the Governance Process, each Phase is a full run-through of all the Stages but in respect of a specific and limited scope of work.
The Governance Process will comprise of a specified number of committees each jointly administered by the parties. The specific committees will be set out in the Statement of Work.
At all times, the parties are each responsible to ensure the smooth functioning of the Governance Process. Without limiting the above, each party will, during the Plan Stage of each Phase, assign personnel to each committee in the Governance Process and make arrangements to ensure it can operate effectively as outlined in the description(s) in the Statement of Work.
The parties will agree on a Project Schedule through the Governance Process, a tool to monitor the planned and actual progress of work on the Project. One of the committees in the Governance Process will adopt responsibility for updates to the Project Schedule.
The Project Planning Documents are not legally binding instruments and do not contain legally binding obligations, warranties, provisions or waivers, nor are they capable of modifications of the terms of this Agreement. Instead, the parties will follow the procedures in this Agreement and be legally bound only to its express written terms, using the Project Planning Documents as tools to communicate and track the progress of the Project.
Agilyx Services and Customer inputs throughout the Implementation Process will combine to produce Deliverables. The status of a document or item as a Deliverable is exclusively created by express provision in this Agreement or decision of a Governance Committee with authority to do so.
Deliverables are not legally binding instruments and do not contain legally binding obligations, warranties, provisions or waivers, nor are they capable of modifications of the terms of this Agreement, even where signed or executed.
Where Specifications are a Deliverable (for example, a design document is both a set of Specifications and a Deliverable), the Specifications Deliverable is used to measure whether legal obligations or warranties have been met in accordance with the terms of this Agreement, and language that purports to give effect to a waiver, variation or separate warranty or agreement within is therefore disregarded.
The parties will, through the Governance Process, maintain a register of all Deliverables (the Deliverables Register), which will contain for each Deliverable its:
name and identifier;
description;
applicable Specifications or dependent Customer inputs (if any); and
applicable Acceptance Criteria.
Each Deliverable must have at least one (1) Acceptance Criterion, either provided in the Statement of Work or agreed as part of the creation of the Deliverable, and the applicable Acceptance Criteria must be recorded in the Deliverables Register.
The parties, through the Governance Process, must conduct a meeting to review the Deliverables that have been produced as part of that Stage (or multiple Stages, if they are concurrently run) and to make a determination as to whether the Project is ready to move to the next Stage (Gateway Review). There is at least one Gateway Review at the scheduled conclusion of each Stage, which can be rescheduled through the Governance Process.
At the Gateway Review, the parties, through a committee of the Governance Process must act reasonably to decide whether all the Deliverables produced in the Stage meet their Acceptance Criteria and the Project can move to the next Stage (a Determination).
If the Determination is made in the affirmative, Agilyx is taken to have discharged its obligations under this Agreement in respect of all Services within the scope of the Stage or in respect of the Deliverables.
If, at a Gateway Review meeting, the relevant Governance Process committee cannot conclude that all Deliverables are completely acceptable but still wishes to proceed to the next Stage, a Determination in the affirmative can be made subject to written and agreed conditions (a Conditional Determination). Once made, the conditions must be met on their terms and the next Stage commences with Agilyx being deemed to have discharged its obligations once the conditions have been met.
For the avoidance of doubt, a party’s representatives through the committee cannot unreasonably refuse to make the Determination in the affirmative.
From time to time either party may request a change (each a Change Request) to:
the scope of work performable within the Phase; or
a Deliverable or any component or aspect of it (for example its Specifications or Acceptance Criteria),
A Change Request may be made by written request to the chair (or co-chairs) of the Governance Committee which has the responsibility for Change Requests (for the purposes of this clause, the CR Authority) in reasonable conformance with the form agreed upon during the Plan Stage.
Each party will present to the CR Authority what it considers to be the impacts of the Change Request, as well as any draft content to be included on the Change Request, and where relevant, information as to how and when the Change Request is to be implemented. The presentation will occur either:
At the next meeting of the CR Authority (where that meeting is no earlier than 10 Business Days after the Change Request has been received); or
as otherwise decided by the CR Authority.
In the Statement of Work or by decision of the relevant Governance Process committee, the parties can agree that any Stage will run concurrently with another Stage. For instance, it may be decided that the Design Stage and Build Stage will run concurrently in order to accommodate design work that requires elements of a Solution Build.
The Plan Stage is the opportunity for the parties to define the scope of work to be performed within the Phase, to document this as appropriate within Project Planning Documents.
The Project Schedule is produced (or revised from a previous Phase) in the Plan Stage. Normally the parties will agree on a Governance Committee with responsibility for maintaining the Project Schedule if one is not already provided by the Statement of Work.
During this Stage, the parties will conduct at least one (1) meeting of every committee in the Governance Process and will perform a Gateway Review to make a Determination to proceed with the remainder of the Implementation Process.
The Design Stage focuses on determining the specifics of the design to be implemented by the Implementation Process.
The parties will agree in the Statement of Work on appropriate Deliverables applicable to the Design Stage to articulate the design for the Solution.
The Project Schedule will be influenced by any design documents or Deliverables produced during the Design Stage, and the parties will co-operate to ensure it remains accurate if new information comes to light about the design during this Stage.
Subject to the specifics in the Statement of Work, the Build Stage is where the substantive configuration occurs to produce a Solution Build, building on the work in the Plan and Design Stages.
Before the Deploy Stage, it is necessary for end-users to test how well the Solution Build performs the Test Scripts (Acceptance Testing).
The Customer will assign personnel to test the Solution Build against the Test Scripts during the timeframe provided by the Project Schedule, as updated by the Governance Process. There may be multiple rounds of Acceptance Testing, which will be indicated in the Project Schedule or the Statement of Work.
The parties will jointly purchase licenses for an Online Ticketing System that is fit for purpose, as required for the number of users and functions to be performed in this Test Stage.
As the Customer’s personnel run through the Test Scripts using the Solution Build, they may encounter a software bug or software behaviour that does not align with expectations or that causes difficulty or prevents operation of the Test Script (each an Issue). For avoidance of doubt, any software behaviour that is not encountered while running the Test Script is not an Issue for the purposes of Acceptance Testing and the Test Stage.
The Customer may raise a ticket in the Online Ticketing System for each Issue and must assign it the appropriate classification (an Issue Classification) from the table below.
| Severity | Name | Classification |
|---|---|---|
| 1 | Critical | The Issue prevents the Solution Build from functioning totally, no further testing of other areas of functionality can occur unless the Issue is resolved. |
| 2 | High | The Issue prevents two (2) or more Test Scripts from being tested in part or in full, but other Test Scripts are capable of being run while this Issue is resolved. |
| 3 | Medium | The Issue prevents one Test Script from being tested in part or in full, but other Test Scripts are capable of being run while this Issue is resolved. |
| 4 | Low | The Issue produces an unexpected or undesired result for one or more Test Scripts but does not block any of those Test Scripts from being completing. Cosmetic and/or user interface Issues are also captured by this Issue Classification. |
If the Customer raises a ticket that is not an Issue or the Issue Classification is incorrect, Agilyx will assign the correct Issue Classification or close the ticket, marking it as ‘Not an issue’. Only valid Issues will be resolvable by Agilyx in the Test Stage.
Agilyx will then make changes to the Solution Build to address as many Issues as possible in the time provided for in the Project Schedule. By decision of the Governance Process committee responsible for Gateway Reviews, the timeframes for the Test Stage can be extended if required.
The Customer will re-run the Test Script after each attempted resolution of the Issue and provide updates on the Online Ticketing System, marking the ticket as closed once the issue is successfully resolved.
Acceptance Testing is deemed completed when the following criteria are met (the Test Completion Criteria):
No outstanding Critical or High Severity Issues (Severity 1 or 2) Issues remain unresolved in the Online Ticketing System; and
Fewer than 15% of the total Medium Severity Issues (Severity 3) raised in the Test Stage for the Phase remain open in the Online Ticketing system.
Once the scheduled time for the Test Stage is complete, a Gateway Review for the Test Stage must be conducted and must Determine in the affirmative that the Test Stage can conclude if the Test Completion Criteria have been met.
Notwithstanding the satisfaction of the Test Completion Criteria and a Determination to exit the Test Stage, remaining Medium or Low Severity Issues (Severity 3 or 4) will be resolved by Agilyx during the Deploy Stage, subject to any further decision in the appropriate committee of the Governance Process.
During the Deploy Stage, the parties will co-operate to deploy the tested Solution Build to a production environment, including any cut-over activities.
The parties will co-operate to migrate the data from the legacy system into the Solution Build in a testing environment prior to deployment to production. Responsibilities for data migration will be set out in the Statement of Work.
If the parties agree that there are no more Phases to complete at the Gateway Review for the Deploy Stage, then by making the Determination in the affirmative at that Gateway Review, the Statement of Work is complete.
The Customer will pay Agilyx for the Services in accordance with the terms set out on the Statement of Work.
This Agreement is active starting from the Commencement Date until the Services are complete (in other words, completion of the Deploy Stage of the final Phase).
