Page History
| View file | ||||
|---|---|---|---|---|
|
Last Revised 05/22/22
This IMPLEMENTATION PROCESS SCHEDULE (this “Implementation Schedule”) is a Schedule to the Master Services Agreement to which this Schedule is attached. The Master Services Agreement and this Implementation Schedule, together with any other attached Schedules and Ordering Documents, together are the Agreement.
1. PRIMARY OBJECTIVE
Provider will provide project management and consulting Services to assist Customer with the implementation of the iRely i21 solution as defined in the sections below.
2. RESPONSIBILITY MATRIX
This responsibility matrix covers realization, final preparation and go-live/support phases of the project and the following key activities/deliverables apply. The following legend is applicable to the deliverable lists in this section:
Responsible (R): Having an obligation to execute or provide deliverable as part of a job or role on project. Those who do the work to achieve the task.
Consulted (C): Provides required Advice/Information to execute or provide deliverable. Those whose opinions are sought, typically subject matter experts; and with whom there is two-way communication.
Informed (I): Being informed about the deliverable details and knowledgeable and aware about the deliverable in order to respond if required. Those who are kept up-to-date on progress, often only on completion of the task or deliverable; and with whom there is just one-way communication.
Accountable (A): Role on project that should be able to explain or substantiate the logic or reason behind the deliverable
The one person to oversee the correct and thorough completion of the deliverable or task, and the one who delegates work to the Responsible. An Accountable must sign off (Approve) on the work that the Responsible provides. There must be only one Accountable specified for each task or deliverable.
...
Stage
...
Activity
...
Customer
...
iRely
Stage 1
BPR –
...
The activities of the BPR (Business Process Review) are centered primarily on three aspects:
Create and establish:
Project team
Steering committee
Project charter
Clear measurable goals and objectives
...
AR
...
R
...
Project governance
Roles and responsibilities
Reporting requirements
...
AR
...
I
...
Data conversion strategy
Only open transactions (or full conversion)
Cutover strategy
Data will be provided in iRely formats for conversion
...
A
...
R
...
Business/Functional aspects of the project. Areas of focus include:
Software Orientation for Project Team
System Review (on demo system)
Base function and setup
...
A
...
R
Conducting Business Analysis Sessions
Review Customer’s business flows
Use Case Design - Using a series of customer specific scenarios, the project team will demonstrate the system inputs, processes and outputs to illustrate the way the system will be utilized at go-live.
...
AR
...
R
...
Identifying Transaction Data, Reference Data and Security Profiles that will be required at Go-live (commence the compilation of such data)
Master Data
Open transactions
...
AR
...
C
Determining modifications to system, if any
Determining the End User Training Strategy
Determining the User Acceptance and Parallel Test Strategies (commence the compilation of the required scenarios and test cases) Preparing and Approving the BPR Document
...
AR
...
R
...
Determining the Deployment Strategy
...
AC
...
R
Business process re-engineering, if any
...
AR
...
R
Stage 2
...
Integration planning - Definition, design, specification of any intended integrations
...
AR
...
C
...
Create Detailed project plan based upon results of BPR stage
...
AR
...
R
Stage 3
...
During this stage, our efforts are principally on two areas: Configure the standard solution and design/build new RICEFWs*. Specific steps are:
a. Configuring set up data
b. Loading and approving Reference Data & Security Profiles
...
A
...
R
...
c. Configuring views to meet reporting requirements
...
A
...
R
...
d. Detailed design, Coding, Review and Approval of Integrations between i21 and other systems
...
AR
...
R
...
e. Loading and Configuring Integrations
...
AR
...
R
...
f. Detailed Design, Coding, Review and Approval of Modifications
...
AR
...
R
...
*RICEFW - Reports, Interfaces, Conversions, Extensions, Forms and Workflow
...
A
...
R
Stage 4
Testing
...
Execute standard Unit and Functional test scripts
...
AR
...
R
Execute Client Functional Test Plan & Evaluate results
...
AR
...
R
Stage 5
Training & UAT (User Acceptance Testing)
...
Execute Key User Training (“Train the Trainers”)
Simulation of daily activities in i21
...
A
...
R
Execute Client User Acceptance Test Plan & evaluate results
There could be multiple rounds of UAT
...
AR
...
R
...
Stage 6
Parallel Testing
...
Execute Production Parallel Test Plan & Evaluate results
...
AR
...
R
Stage 7
...
Activities include:
Go/No-Go Decision for Go-Live
...
AR
...
R
...
Cutover from Legacy Systems to i21 in Production Environment
...
A
...
R
...
Post Go-Live Support
...
AR
...
R
Transition to Support
...
AR
...
R
...
Stage 8
Ongoing Support
...
Ongoing support
...
AR
...
R
3. CUSTOMER RESPONSIBILITIES
3.1 Customer will dedicate appropriate personnel to the project as and when required. Customer will assign a lead project manager that will serve as the primary point of contact for the project.
3.2 Customer will have overall accountability for the project. Customer resources will have the overall responsibility for:
- Customer resource coordination & deliverables;
- Identifying and documenting business scenarios;
- User Acceptance & Parallel Test Cases;
- Compilation and Cleansing of Reference Data;
- Determination of Security Profiles;
- Executing User Acceptance Testing;
- Provide the final requirements documentation for all interfaces and modifications;
- Reviewing and approving any design documentation produced for interfaces and modifications;
- Serve as primary point of contact for any needed third-party communications;
- Providing the necessary physical and computer access required to Customer assets;
- Customer will provide necessary project work environment conducive to the accomplishment of the implementation project.
4. PROVIDER RESPONSIBILITIES
4.1 Provider will provide a Project Manager. The Project Manager will facilitate the implementation project. The Project Manager will work in conjunction with Customer’s Project Manager to ensure the project is progressing within the mutually agreed upon project timeline and budget.
4.2 Provider will complete the Services as outlined in the eight-stage implementation process above.
4.3 Provider execute its obligations under the terms of this Implementation Schedule and the Project Plan.
4.4 Provider will utilize suitably qualified technical resources familiar with the Services.
4.5 Provider will deliver the project’s final Services/Deliverables in a timely manner and obtain Customer sign-off.
5. ASSUMPTIONS
Services under agreement may include:
- Services for eight-stage implementation process as described above;
- Project Management;
- Any modifications to the requirements described in this Implementation Schedule or the Project Plan will require written permission from both Customer and iRely project management, following the Change Control Procedure;
- The implementation services will be delivered by iRely and Customer will not have to interface with a third party relating to any of the activities;
- Provider personnel assigned to the work on the implementation project are technically qualified to grant Customer access to the Software, train Customer personnel and support Customer through the completion of this implementation;
- Customer personnel are available and have the time to receive appropriate training and move the project forward;
- The project will be executed remotely or occasionally on customer site as mutually determined between the parties;
- Provider will not store Customer confidential information and Customer will not use Provider confidential information;
- Testing will be conducted in a production environment, or production-like and dedicated environment for testing purposes;
- The success of the implementation project relies on the Customer.
6. OUT OF SCOPE – REQUIRES CHANGE PROCEDURE
The following items are out of scope of the implementation and will require the change procedure set forth in Schedule 6 – Change Procedure:
- Planning or engineering work to be performed by Provider. New enhancements or reports.
- Functionality modifications and additions that need additional programming.
- Reports/Documents modifications and additions that need additional programming.
- Data Conversion.
- Any additional integrations that are not included in this Implementation Schedule or the Project Plan.
- Technical support.
7. TIMETABLE AND CHANGE PROCEDURES
7.1 Timetable. Provider will begin developing the Solution on the Effective Date hereof and shall continue providing services and support until the Software is successfully implemented.
7.2 Acceptance. Service is deemed accepted and consumed as service is delivered.
7.3 Change Control Procedure. In the event the parties determine that the scope of the Ordering Document or the Project Plan requires modification, they will use the Change Control Procedure. Please refer to Schedule 6 – Change Procedure.
8. TIMING
Upon execution of an Ordering Document requiring an implementation in accordance with this Implementation Schedule, Provider and Customer will begin collaborating on a “Business Process Review” to determine the scope, timeline and cost of the implementation. After completion of the Business Process Review, Provider and Customer will agree to a “Project Plan” for the implementation.
Given the significant Customer effort needed for an implementation, it is important that Customer evaluates the requirements on its own resources when approving the Project Plan. Project Plans assume the availability of needed resources from Customer and no change in the agreed upon scope. Should customer availability or scope change become an issue, the dates for Project Plan milestones will be adjusted accordingly.
9. FEES
9.1 Invoicing. Implementation and customization services are billed based on time and materials. Please refer to Schedule 5 – Invoicing and Payment, for rates and further details. Invoicing for Services are issued on a weekly basis. If payment is not timely received, Provider reserves the right to suspend performance until invoices are current.
9.2 Customization. Customizations identified during implementation will follow Schedule 6 – Control Procedure. Customization may impact the go-live date, and the parties will mutually agree to modify the go-live date accordingly.
10. ISSUE ESCALATION PROCEDURE
10.1 In the event that either party determines it is not getting adequate resolution to a problem that may have a material impact upon its obligations under the Project Plan or the completion of the work intended hereunder, the following represents the escalation path to be followed:
...
Overview
Content Tools