These Terms apply to a Statement of Work that is for a full Implementation of the Unit4 Business World ERP System
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 Unit4 Business World ERP System.
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 the last party to execute the Statement of Work does so.
Conditional Determination means a Determination subject to certain conditions, as more fully described in the ‘Quality Control and Gateway Reviews’ clause.
Environment Plan means a customer-produced document that discloses the software environment(s) within which the Solution Build will be deployed, normally there is at least one ‘Test Environment’ and one ‘Production Environment’, subject to the specifics detailed in this document.
Project Steering Committee or PSC means the committee jointly governed and administered by the parties, as described in the Statement of Work.
Determination means a decision made by the PSC at a Gateway Review, as described more fully in the ‘Quality Control and Gateway Reviews’ clause.
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.
Data Migration means extracting, transforming and loading data from one environment to another, as outlined more fully in these Terms of Full Implementation.
Gateway Review means a meeting in the Governance Process as describe more fully in the ‘Quality Control and Gateway Reviews’ clause.
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 ‘Implementation Process’ clause.
Solution means the final built, tested and deployed Unit4 ERP software solution, being the goal of the activities contemplated by this 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 Routine means a scenario-based example of how Business Requirements come together to perform functionality is desirable to test, as more fully described in the ‘Production of Test Routines for Testing’ clause.
Project means the overarching joint efforts of the Customer and Agilyx to produce the Solution as set out in this Statement of Work.
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 and Deliverables Register.
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, Build Stage, Test Stage, Deploy Stage, with the activities associated with each being defined in their own section of this 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.
Exit Criteria means the criteria provided by the Statement of Work for determining when testing has been successfully completed.
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 document forms part of the terms of a Statement of Work to perform a full 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 and below.
Subject to the more detailed provisions of these Terms of Full Implementation, the software implementation service is made up of:
a multi-staged process to plan (confirm scope and gather business requirements), design, build (configure), test and deploy the Unit4 ERP 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 five (5) unless otherwise decided through the Governance Process, being the Plan Stage, Design Stage, Build Stage, Test Stage and Deploy Stage; and
Phases, which must be agreed upon 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 two (2) committees each jointly administered by the parties, the:
Project Steering Committee (PSC); and
Project Management Office (PMO),
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 PSC will agree on a Project Schedule, a tool to monitor the planned and actual progress of work on the Project. The PMO will produce the first draft and adopts responsibility for updating it on an ongoing basis, subject to its more detailed description in the Statement of Work.
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 Statement of Work. Instead, the parties will follow the procedures in this Statement of Work 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 the Statement of Work; or
decision of the PSC.
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 the Statement of Work, even where signed or executed.
Where Specifications are a Deliverable (for example, a design document is both a set of Specifications and a Deliverable), then the ‘Specifications Deliverable’ is used to measure whether legal obligations or warranties have been met in accordance with the terms of the Statement of Work, and language that purports to give effect to a waiver, variation or separate warranty or agreement within is therefore disregarded.
The PSC will maintain a Deliverables Register, which will contain for each Deliverable its:
name and identifier;
description;
applicable Specifications (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 in PSC, and the applicable Acceptance Criteria must be recorded in the Deliverables Register.
The PSC must conduct a meeting to review the Deliverables that have been produced as part of that Stage and to make a Determination as to whether one or more Deliverables have been completed as part of that Stage and whether the Project is ready to move to the next Stage (Gateway Review). There is at least one final Gateway Review at the scheduled conclusion of each Stage, which can be rescheduled by decision of the PSC but must not be unreasonably delayed.
At the Gateway Review, the PSC must act reasonably to decide whether all the Deliverables the subject of the Gateway Review meet their Acceptance Criteria, and the Project can move to the next Stage (Determination).
If the Determination is made in the affirmative, Agilyx is taken to have discharged its obligations under the Statement of Work in respect of all services and Deliverables that were the subject of the Gateway Review. If the Gateway Review is the final for the Stage, then Agilyx is taken to have discharged its obligations in respect of all in-scope Services for the Stage.
If, at a Gateway Review meeting, the PSC 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. Agilyx will be taken to have discharged its obligations in respect of the Deliverables once the conditions have been met.
For the avoidance of doubt, a party’s representatives through the PSC cannot unreasonably refuse to make the Determination in the affirmative.
From time to time either party may request a change (a Change Request) to:
the scope of work performable within the Phase (and by extension within any Stage 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 PSC in reasonable conformance with the form agreed upon during the Plan Stage.
For the avoidance of doubt, changes to the Project Schedule do not require a Change Request and may be handled by decision of the PMO, or PSC if escalated. However, the PSC may decide that changes in timeframe warrant handling as a Change Request.
Each party will present to the PSC 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 PSC (where that meeting is no earlier than 10 Business Days after the Change Request has been received); or
as otherwise decided by the PSC.
By decision of the PSC, the parties can agree that any Stage will run concurrently with another Stage. For instance, the PSC may decide 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 and is a mandatory Deliverable for the Plan Stage.
During this Stage, the parties will conduct at least one (1) meeting of every committee in the Governance Process and the PSC will perform a Gateway Review to make a Determination to proceed with the remainder of the Implementation Process.
The Design Stage focuses on articulation of business requirements into a Business Requirements Document (BRD) and then conversion of those into a Solution Design Document (SDD).
The parties will collaborate to produce a Business Requirements Document (BRD) during the Design Stage. The BRD is a pre-requisite to the remaining Stages of the Implementation Process and may contain a preliminary indication of the scope of work that will be applicable for each Phase.
The PSC will be responsible for adjusting the scope of work for each Phase via Change Request, giving regard to applicable timelines and the objectives of the Project.
The Solution Design Document (SDD) is the central Deliverable applicable to the Design Stage. The SDD will describe, amongst other things, the software features used to meet the Business Requirements on a one-to-one or one-to-many basis (i.e. any number of Business Requirements may be addressable by any number of functional design elements in the SDD).
The Project Schedule will be influenced by the Solution Design Document during this Stage, and the parties will co-operate to ensure it is reflected as information comes to light from the SDD about the likely timeframe and effort required to complete the remaining Stages.
The Solution Build for the in-scope functionality of the current Phase will be produced during the Build Stage and is a Deliverable of the Stage.
During the Build Stage, the Customer must achieve population of data sufficient for the purposes of the Test Stage by:
Extracting data from legacy systems;
Transforming the data to a format that is capable of being loaded into the Solution Build as deployed on a suitable test environment (according to the Environment Plan); and
Loading the data into the Solution Build on the test environment to allow for the activities in the Test Stage, before eventual deployment to a production environment (subject always to the details in the Environment Plan).
During the time allocated in the Project Schedule for Data Migration activities, Agilyx will provide guidance on the format the data must be transformed into for loading into the Solution Build and troubleshooting to the extent permitted by the time allocation.
The Customer must use the tools stipulated in the Statement of Work to achieve population of the data.
During the time allocated for in in the Project Schedule, Agilyx will train the Customer on how to use the Solution Build to create reporting according to the included scope of reporting or Business Requirements specified in the Statement of Work. If no scope of reporting is specified in the Statement of Work, then the time allocated in the Project Schedule for training on reporting will determine when training is completed.
The Customer will then, during the time allocated for it in the Project Schedule, develop the reporting it requires to complete any of the Test Routines that include a reporting component.
Before the Deploy Stage, it is necessary for end-users to test how well the Solution Build performs the Test Routines. The Test Stage is where the planning and execution of this testing occurs.
Prior to testing, it is necessary to outline a series of process steps that articulate how a tester will use Solution functionality to meet one or more of the Business Requirements, written for the purposes of the Test Stage (each a Test Routine).
The Customer will develop each Test Routine during the Test Stage in the period allocated for it in the Project Schedule by the PSC. Test Routines will only be developed in this Stage for functionality that is in-scope for the applicable Phase.
The parties will act reasonably in determining the quantity and detail of Test Routines so as not to unreasonably prolong the Test Stage. This detail will be documented in the Test Plan, Customer Input which (in addition to any requirements in the SOW), must include at a minimum:
the Test Routines in-scope for the applicable Phase;
the procedure for testing, consistent with the Statement of Work and these Terms of Full Implementation (including any Exit Criteria, Issue Classifications and the process of using the Online Ticketing System);
a detailed schedule of testing, consistent with the Project Schedule, that includes the number of hours per week Customer resources can be available for testing, who the resources are and appropriate plans to accommodate for leave or other absences that may be relevant for the period planned for testing in the Project Schedule.
The parties will 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.
During the time allocated for it in the Project Schedule, the Customer must load a complete dataset into a test environment (subject to the Environment Plan) to facilitate testing of all the Test Routines. Agilyx will allocate personnel to be available to assist with troubleshooting this process during this time.
The parties will then perform their obligations under the Test Plan during the time allocated for Testing in the Project Schedule.
As the Customer’s personnel run through the Test Routines using the Solution Build, they may encounter a software bug or undesirable software behaviour that causes difficulty or prevents the progression through a Test Routine (each an Issue). For avoidance of doubt, any software behaviour that is not encountered while running through the Test Routine is not an Issue for the purposes of 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) as set out in the Statement of Work.
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 PSC the timeframes for the Test Stage can be extended if required, provided that a suitable Change Request is entered into.
The Customer will re-run the Test Routine 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.
Once the scheduled time for the Test Stage is complete, or otherwise by decision of the PSC, the PSC will conduct a Gateway Review for the Test Stage and must Determine in the affirmative that the Test Stage can conclude if the Exit Criteria have been met.
Notwithstanding the satisfaction of the Exit Criteria and a Determination to exit the Test Stage, the Statement of Work may provide for remaining Issues or that Issues with a particular Issue Classifications will be resolved by Agilyx during the Deploy Stage. If the Statement of Work provides for this, then those remaining Issues must not prevent the PSC from Determining tin the affirmative that the Test Stage will conclude.
During the Deploy Stage, the parties will co-operate to deploy the tested Solution Build to a production environment, including any cut-over activities, such as performing parallel runs with legacy systems to compare whether the Solution Build is ready to take over from legacy systems.
The Customer will conform to the agreed procedure in the Cutover Plan (which is influenced by the Environment Plan, both are Deliverables) in deployment of the Solution Build.
The parties may allocate time in the Project Schedule during the Deploy Stage for post-go-live support. During this time, Agilyx will provide support services to assist the Customer in operating the Solution in its production environment. The parties may decide to use a tool (like the Online Ticketing System) to collaborate or any other method.
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, this Statement of Work is complete.
The Customer will pay Agilyx for the services provided under the terms set out in the Statement of Work.
The Statement of Work is active starting from the Commencement Date until completion of the Deploy Stage of the final Phase, whereupon the Statement of Work is then complete.
