milestone milestone description acceptance criteria payment · pdf filea schedule to the...

1

SCHEDULE #1 This Schedule #1, with an effective date of May 16, 2014 (the “Schedule #1 Effective Date”), is a Schedule to the Master Product and Services Agreement by and between Sony Pictures Entertainment Inc. (“Company”) and RightsLine Software, Inc. (“RightsLine” or “Service Provider”) with an effective date ofMay 16, 2014 (the “Agreement”). Capitalized terms used herein and not otherwise defined herein shall have the meanings assigned to them in the Agreement. I. PRODUCTS AND FEES

Products and Services Initial Number

of Registered Users

Monthly Fee for the Initial Registered

Users

Monthly Fee for Additional Registered

Users RightsLine Enterprise User License

Unlimited1 $16,667.00 $0.00

Enterprise Support (160 hrs / mo. included)

$7,200.00 $80.00/hr

Monthly Fees (including User License and Enterprise Support) from Kick-off to Go-Live (a 50% reduction from the full monthly fee):

$11,933.50

Monthly Fees (including User License and Enterprise Support) after Go-Live:

$23,867.00

1. Unlimited for the platform configuration included in this Schedule #1.

II. ADDITIONAL REQUIREMENTS: The complete list of requirements covered by this Schedule #1 is included in Attachment 1 attached to this Schedule #1 labeled GNET Requirements List v 6.0_P1. All of the requirements in Attachment 1 will be delivered via configuration and setup during the implementation and training period prior to Phase 1 Go-Live as described below in Section III

III. IMPLEMENTATION COSTS & PAYMENT: The total implementation cost to configure, test, and deliver the Product according to this Schedule #1, including Attachment 1 and the Scope of Work Document attached as Attachment 2 to this Schedule #1, will be $1,238,280.00.

The amounts set forth below will be invoiced by Service Provider to Company upon satisfaction of the applicable Milestone Acceptance Criteria as follows:

Milestone Milestone Description Acceptance Criteria Payment Due

2


1 Project Kickoff Meeting:!

Meeting with all of the project team members and sponsors to outline the operating guidelines of the project, critical success factors, and deliverables. The kickoff will also review the overall scope and goals of what will be accomplished.

Company Program Manager provides confirmation in writing that the Project Kickoff meeting has been held and the project is officially started.

$371,484.00

Acceptance of the Configuration Specifications Document and the Integration and Customization Specification Document

Configuration Specifications Document containing all information that is required by the Service Provider to configure the RightsLine Product to support Company’s Networks group business processes. This includes metadata and workflow definitions for all entities (Contacts, Assets, Contracts, Rights, Usages, Amounts, Invoices, Roles).

Integration and Customization Specification Document– containing all of the Functional and Technical specifications required for all integrations (ODIN, IDM, Alfresco, Scheduling System Pilot), as well as for any custom Workflow Extensions, Reports, or Interface Changes signed off by the technical lead.

Company Program Manager provides confirmation in writing that the Configuration Specifications Document and the Integration and Customization Specification Document are complete and address all of the requirements in Attachments 1 and 2.

$123,828.00

3 Completion of End User Training and Acceptance Testing

The Company IT and Business Users have been trained and completed their acceptance testing and all issues of

Company Program Manager provides confirmation in writing that user

$247,656.00

3


Severity Level 1 and 2 have been fixed and any Severity Level 3 issues that the Company reasonably requires be fixed by the Service Provider prior to Go-live have been fixed.

training and acceptance testing is complete.

4 Phase 1 Go Live Service Provider provides access to a live RightsLine Product that can be accessed by users (who will be identified by Company in the configuration specifications stage), fulfills all of the requirements outlined in Attachments 1 and 2 and fixes all Problems identified in the User Acceptance Testing

Company Program Manager provides confirmation in writing that the Product is live and working as expected and in accordance with applicable requirements in Company's discretion.

$247,656.00

Phase 2 Go Live (covered in the Work Order, dated of even date herewith, by and between Company and Service Provider)

Service Provider provides access to a live RightsLine Product that can be accessed by users (who will be identified in the functional specifications) and incorporates all of the functional changes to the Product as described in the Work Order and all other milestones under the Work Order have been accepted by Company in accordance with the terms of the Work Order.

Company Program Manager provides confirmation in writing that the Product is live and working in accordance with applicable requirements in Company's discretion.

$247,656.00

IV. TIME PERIODS

Acceptance Period: Thirty (30) business days commencing upon the date the Products and Services are made available to Company in accordance with the Agreement and Company has received notice from Service Provider indicating the commencement of the Acceptance Period.

Initial Term: One (1) year commencing May 16, 2014.

V. ADDRESSES FOR NOTICES Notices for Service Provider shall be addressed as follows:

4

RightsLine Software, Inc. 8391 Beverly Blvd. #287 Los Angeles, CA 90048 Attention: Robert Delf

Notices for Company shall be addressed as set forth in Section 15.4 of the Agreement. VI. SERVICE LEVEL STANDARDS A. Service Provider’s failure to make the Products and Services Available at least 99.9% of the time during the Availability Period (as defined in Section VII below) in any given month during the Term, unless such failure is outside of Service Provider’s control, shall be deemed a service level default (“Service Level Default”) and Company may obtain the non-exclusive remedies set forth below. For purposes of this Schedule #1, “Available” means that Company, its Affiliates and the Registered Users are able to access all features and functions of the Products and Services including, but not limited to the Company Data and Service Provider Content.

Service Level (Calendar Month) Service Level Credit (Prorated Fees – Calendar Month)

Above 99.9% 0 99.9 – 98.0% 5% 97.99 – 96% 10% 95.99 – 94% 25% 93.99 – 92% 50% Below 92% 100% and Termination

In the event Company is eligible for a 100% Service Level Credit under this Section during any given calendar month of the Term, Company may terminate this Schedule #1 without penalty upon written notice to Service Provider and, in addition to the remedies available under this Section, receive the remedies set forth in the Agreement.

Credits shall be applied against the next monthly invoice; provided, that in the event a Service Level Default occurs after a party has given notice of termination pursuant to this Section and the Agreement, or Company has made final payment to Service Provider for the Products and Services and no further invoices shall issue as a result, Service Provider shall refund to Company the amount of the appropriate Service Level Credit due for the period of Default.

B. Any problems or issues (“Problems”) related to the Products and Services shall be subject to the following. If a Problem is not resolved by the time identified in the Target Resolution time period set forth below, the following successively senior Service Provider executives shall contact Company to provide an explanation as to why the Problem is not resolved and what steps are being taken to resolve the Problem as soon as possible: (a) if not resolved in the Target Resolution time, the applicable Service Provider executive will be the Service Provider’s Account Representative; (b) if not resolved in 2 times the Target Resolution time, the applicable Service Provider executive will be the person to whom the person identified in subsection (a) reports; (c) if not resolved in 3 times the Target Resolution time, the applicable Service Provider executive will be the person to whom the person identified in subsection (b) reports; and (d) if not resolved in 4 times the Target Resolution time, the applicable Service Provider executive will be the person to whom the person identified in subsection (c) reports, or a direct report to the Service Provider’s Chief Operating Officer, whichever is higher.

5

Severity Level Acknowledge

(1) Efforts (2)

Updates (3)

Target Resolution (4)

1: Critical application, service or function is not available or operating in a materially degraded manner.

15 mins RE 24x7 Every 1 hour

1 hour

2: Critical application, service or function is not available or operating in a materially degraded manner but a work around exists, or a non-critical application, service or function is not available or operating in a materially degraded manner, but a work around exists.

1 hour RE 24x7 Every 2 hours

4 hours

3: Non-critical application, service or function is not available or operating in a materially degraded manner, but a work around does not exist.

4 hours RE during BH

Every 24 hours

24 hours

(1) Defines the time by which Service Provider must respond to the Company acknowledging receipt of the problem. (2) Defines the efforts Service Provider will use to correct the problem. “RE” means Reasonable Efforts, “BH” means business hours, which are defined as 8am to 6pm Pacific Standard time. (3) Defines how often Service Provider will update Company with respect to the resolution of the Problem. (4) Defines the target time for Service Provider to resolve the Problem. C. Service Provider will provide telephone support and use best efforts to answer questions from worldwide offices on a 24 x 7 basis. However, in the event that a representative is unavailable, Service Provider will provide a response within four (4) hours of any reported issue. Service Provider will establish processes and policies for contacting support via telephone and email and will make those processes available from the application. VII. AVAILABILITY PERIOD, SCHEDULED MAINTENANCE AND NOTIFICATIONS

a. Availability Period (excluding Maintenance Windows defined below). Days and Hours of Availability: 24 hours / day, 7 days / week.

b. Standard Maintenance Windows. On a monthly basis Service Provider has scheduled downtime to release new functionality. The downtime is typically scheduled on off hours and 1 business day is provided as a notification period. The current release schedule for 2014 is as set forth below, but may change based upon feedback from customers. In the case it changes, notifications will be provided and Service Provider will work with Company to ensure as little interruption as possible. Service Provider will provide the release

6

schedule for each subsequent year during the Term to Company as soon as reasonably practicable. 5/15/14 – 6-10pm PST 6/19/14 – 6-10pm PST 7/17/14 – 6-10pm PST 8/14/14 – 6-10pm PST 9/18/14 – 6-10pm PST 10/16/14 – 6-10pm PST 11/13/14 – 6-10pm PST

c. Notification of Maintenance Downtime. Service Provider will notify Company of any maintenance which may cause the Products and/or Services to be unavailable outside the Standard Maintenance Windows outlined above. Except in cases of emergency, notification will be provided at least one business day prior to such maintenance. In cases of emergency, Service Provider will use its best efforts to notify Company of a downtime as soon as practicable.

VIII. ESCROW

Pursuant to Section 15.9 of the Agreement, concurrently with the execution of this Schedule #1 Company and Service Provider shall enter into an Escrow Agreement with respect to the source code of the Product and related Documentation, with Iron Mountain Intellectual Property management, Inc. acting as the Escrow Agent.

[Signature Page Follows]

8

ATTACHMENT 1 TO SCHEDULE #1

GNET Requirements List v 6.0 P1

(See Attached)

9

ATTACHMENT 2 TO SCHEDULE #1

Scope of Work Document

1. Roles and Responsibilities

The following Service Provider personnel (and corresponding roles) are assigned to the project described in Schedule #1:

Assigned Person/ Planned

Involvement

Title Responsibilities

Robert Delf CEO ! Overall delivery responsibility

! Project management support

! Executive sponsorship

Matt Bricker

VP Product ! Overall delivery responsibility

! Product domain expertise

! Project management

David Straus

President RightsLine

! Industry support and expertise


Joe Neulight

Product Team

! Industry support and expertise



Jeff Smith Sr. Consultant

! Technical delivery responsibility


Cory Kissinger

VP Engineering


! Product domain expertise

Matt Hovany

Sr. Developer

! User Interface and enhancement delivery responsibility

Subhash Thamatam

Database Developer


Vivek Patel Developer ! Technical delivery responsibility

10

!

From a time commitment perspective, the amount of time for each resource listed above will fluctuate based upon phase of the project. The core team, Robert Delf, Matt Bricker, Jeff Smith, Cory Kissinger, Matt Hovany, Subash Thamatam, and Vivek Patel will be fully dedicated to the project. In addition, there will be additional resources which are not currently identified that will be joining the team for periods of time to support User Interface Design, Detailed Testing, and Technical Writing. The following Company Personnel and corresponding roles and responsibilities are assigned to the project described in this Schedule #1:

Role Responsibilities Assigned Person/ Planned

Involvement

Company Project Manager

! Monitor project progress and outstanding issues

! Track project cost, schedule and scope

! Responsible for change management

! Liaise with Service Provider for product related issues

! Manage end to end project plan execution involving multiple Company stakeholders

! Coordinate to setup User Training, QA, UAT and production rollout

! Coordinate with other interfacing applications and ensure their availability as per Schedule #1

! Colin O'Keeffe 100%

Company Program Manager

! Hold status review meeting with Company senior management

! Business Relationship Management with all Company Stakeholders

! Sign off on milestones as described in this Schedule #1

! Process payments for Service Provider according to the terms in this Schedule #1

! Caz Westover 50%

Business Analyst

! Gather and document user requirements in the form of functional specifications

! TBD 100%

11

! Business Process flow diagrams

! Data Migration from SPiDR, Global Tracs and any other identified data sources

Technical Lead

! Provide all technical documentation to Service Provider

! Facilitate meetings between Service Provider's technical resources and the technical resources required for the integrations.

! Provide technical support on the Data Migration from SPiDR, Global Tracs and any other identified data sources

! Jenis Shah 50%

Steering Committee: The steering committee is organized as follows: Service Provider:

- Rob Delf Company: -Andy Kaplan -Pamela Parker -Eric Iverson The steering committee will make strategic decisions concerning the direction of the project, provide direction on major issues facing Company in connection with the project described in this Schedule #1, and provide guidance on how to best support future business goals. Operations Committee: The operations committee is organized as follows: Service Provider:

- Matt Bricker - Jeff Smith - Joe Neulight

Company: - Lily Fizzy - Kristine Orion - Caz Westover - Colin O’Keeffe - Jenis Shah

12

- Nidhi Aggarwal - Regional Representatives (TBD)

o US o Digital Networks o Latin America o Western Europe o Eastern Europe o Asia

The operations committee will meet on a regular basis to discuss project progress, issues, and overall timeline for delivery. 2. Scope

The scope of the services that are to be performed under this Schedule #1 for the Company are itemized in Attachment 1 GNET Requirements List v 6.0_P1. Service Provider estimates that the scope of work described in this Schedule #1 will last approximately 34 weeks. This Schedule #1 covers the baseline implementation of Service Provider’s Contract and Rights Management software for the Company’s Networks group. This will involve the definition of configuration based upon workshops with the end users, configuration of the RightsLine software, testing with users, training, and post go-live support. In addition there are three integrations defined:

• Identity Management (IDM): Users will be able to login to RightsLine using their SPE IDM password and IDM will manage access controls in accordance with Company Practices

• Alfresco document management Users will be able to upload, download and manage versions of documents associated with contract records in the RightsLine Product. Documents will be stored on Company controlled Alfresco servers.

• Asset master data repository (ODIN): Users will be able to look up and select assets and asset metadata and attach the asset records to the contract records utilizing services of the ODIN system.

Upon completion of the Services provided by Service Provider under this Schedule #1, Company will be able to access an instance of the Service Provider’s software that has been configured to meet the Company's requirements as described in this Schedule #1, Attachment 1 and this Attachment 2.

• Configuration. Service Provider will facilitate Configuration Workshops for Company Business Users. These workshops are intended to guide Company through the configuration choices with which the Service Provider’s Product will best satisfy the functional requirements (as documented in Attachment 1). This configuration will include; metadata for all entities (Contacts, Assets, Contracts, Rights, Usages, Amounts,

13

Roles), workflow for all of the entities, and any specific logic required for integrations (in the form of Workflow Extensions or batch jobs). It will also include some basic canned report and the native onscreen reporting and export tools offered with RightsLine software. The workshops will result in the following deliverables:

o Service Provider will produce written configuration specifications that reflect the

configuration choices made by Company business users. This deliverable will be considered accepted based upon signoff by Company’s Business Functional Lead and IT Program Manager

o Service Provider will produce written report specifications that define the information to be shown on a report, formatting of results, any calculation logic, sorting, filtering and selection criteria. This deliverable will be considered accepted based upon the signoff by Company’s Business Functional Lead and IT Program Manager.

o Company IT will document Requirements for any functional or technical gaps identified during the configuration workshops.

o For functional or technical gaps that are deemed absolutely essential, in Company’s sole discretion, for going live in connection with the Services provided under this Schedule #1:

o If the solution to such gaps requires Product enhancements, Service Provider will produce written solution specifications that details how the gap will be supported. This deliverable will be considered accepted based upon signoff by Company’s Business Functional Lead and IT Program Manager

o If, on the other hand, the solution does not require Product enhancements, then Company IT will be responsible for producing solution design.

o Service Provider will provide the configured Product in one or more test environments. The test environments will include the complete configuration of the Product as documented in the configuration documents. This deliverable will be considered accepted based upon successful Acceptance Testing (see below).

• Integrations. The development of the three integrations will go through Service

Provider’s standardized process. It is anticipated that each of the documents listed below will be developed through working sessions between the Company and Service Provider teams:

14

o Company IT will produce a functional specification for each integration.

o As each complete integration has components that span both Company and Service Provider domains, Company IT will be responsible for orchestrating the end-to-end design.

! Company IT will produce a written technical specification for the integration components that are outside of Service Provider’s domain.

! Service Provider will produce a written technical specification for the integration components that are within its domain. This deliverable will be considered accepted with the sign off by Company IT Technical Lead.

o Company IT will provide Service Provider with the necessary file structures and API templates to assist in the design and development of each integration.

o Service Provider will provide Company with the necessary file structures and API templates to assist in the design and development of each integration.

o Service Provider will develop and deliver all of the necessary integration components that fall within its domain.

o Company IT will be responsible for producing a test plan to validate end-to-end functionality as well as performance and load capabilities.

o Company IT will be responsible for conducting end-to-end and performance testing for each integration. (see below for test approach).

• Data Migration. The following deliverables are in support of migrating historical and/or start up data:

o Company IT will provide some historical and/or startup data (aka Migration Data) to be populated in both test environment(s) and, ultimately, the final production environment.

o Service Provider will provide technical templates and capability to automate the population of this migration data

o Service Provider will execute the population of migration data into the test and production environments, at no additional cost to Company.

o In order to validate the population of data, Service Provider will provide visibility into the populated migration data in the production Product through either reports or database views.

15

o Data migration will be considered complete by the sign off by Company IT Program Manager and Company Business Lead.

• Testing. The following deliverables/activities mark the test approach for the Services provided under this Schedule #1.

o Company IT will provide a testing plan for end-to-end Product testing, integration testing, performance testing and User Acceptance Testing. This deliverable will be considered accepted based upon signoff by Company Business Functional Lead, Company IT Program Manager and a Service Provider Senior Representative

o With the support of Service Provider, Company IT will be responsible to conduct end-to-end Product testing upon the delivered, configured Product. This activity will be considered complete by the sign off by Company IT Program Manager of a complete set of successful test cases as defined in the test plan.

o With the support of Service Provider, Company IT will be responsible to conduct end-to-end Product testing upon the delivered, Integrations. This activity will be considered complete by the sign off by Company IT Program Manager of a complete set of successful test cases as defined in the test plan.

o With the support of Service Provider, Company IT will be responsible to conduct Performance testing upon the delivered, configured Product. This activity will be considered complete by the sign off by Company IT Program Manager of a complete set of successful test cases as defined in the test plan.

o With the support of Service Provider, Company IT will be responsible to conduct Performance testing upon the delivered Integrations. This activity will be considered complete by the sign off by Company IT Program Manager of a complete set of successful test cases as defined in the test plan.

o With the support of Service Provider and Company IT, the Company Business Users will be responsible for conducting User Acceptance testing for end-to-end functional compliance. This activity will be considered complete by the sign off by Company Project Sponsor of a complete set of successful test cases as defined in the test plan.

o Through each of these testing activities, Company IT is responsible for documenting and managing testing results as well as detailing defects.

o Through each of these testing activities, Service Provider is responsible for resolving the identified defects in an agreed upon timeframe.

16

• Training. Service Provider will provide standard training documentation and help files along with the configured software. It is also planned that Service Provider will conduct training sessions (with the support of Company IT and Company Business Lead) to the end users for a total of 10 days (two 4 hr sessions per day).

• Go-Live. Service Provider will provide a production environment for the final, configured Product populated with migration data. Acceptance of this deliverable will require sign off from Company’s Project Sponsor.

• Post Go-Live Support. Service Provider will provide dedicated support following go-live as part of the Agreement and support SLA.

3. Service Level Agreements (Pre-Go-Live and Hypercare): Pre-Go-Live: -During the course of the project described in this Schedule #1, Service Provider will provide a test tenant in our QA environment, which will not have a guaranteed uptime, but best efforts will be provided during the Term to ensure its availability for both the Company and Service Provider Project Teams -The resources assigned to the project described in this Schedule #1, and indicated as such herein, will be available and assigned to the Sony Networks Project for the time required from Company and Service Provider management. Service Provider reserves the right to exchange resources with consultation from the Company Project management team. -Response times for issues prior to go-live will vary by severity, as set forth in Section VI of Schedule #1. Hypercare: -For a period of 4 weeks following Go-Live, Service Provider resources will be in a period of “Hypercare”. This will involve dedicating a minimum of 3 full time support resources to Company in order to rapidly triage any issues and resolve them as soon as possible. The response times for Hypercare are identical to those for Pre-Go-Live.. Post-Go-Live

After the Hypercare period is over, Service Levels will continue in a manner identical to those for Pre-Go-Live.

4. Change Management Process for Changing Scope, Design Approach, or Technical Solution Changes in scope must be tightly controlled in order to prevent impacts to the timeline and/or cost. As such, the following process has been designed to govern changing scope in the form of adding, removing, or substituting requirements.

17

General Process The general process for changing scope is as follows:

1. Scope Change to be presented by Sony or Service Provider Project Manager to his or her counterpart

2. Scope Change to be discussed and business or technical driver outlined for the Project Operating Committee

3. Upon approval, Scope Change to be outlined with Project Steering Committee 4. Upon approval, Scope Change to be formally documented in a Change Request

Document by the applicable Project Manager a. Change Request Document must include any applicable timeline, cost, priority or

other changes according to the specific guidelines for the type of Scope Change (see below)

5. Change Request Document must be formally signed off on by Project Sponsors from both Company and Service Provider

6. Scope Change becomes canonical and part of the overall project plan, subject to timeline and cost impacts (if any) as specified in the Change Request Document and according to the specific guidelines for the type of Scope Change (see below)

Adding Requirements The addition of requirements has the largest risk to overall project timeline and cost. Therefore, the following workflow must be enacted for the addition of requirements:

1. Determine if the Scope Change is truly an addition/expansion of requirements a. If yes, proceed to step 2 b. If no,

i. If Scope Change is a requirements substitution proceed with Substituting Requirements workflow (see below)

ii. If Scope Change is non-impactful, Scope Change is retired 2. Determine overall effort required for the addition/expansion of requirements from both a

functional and a technical perspective 3. Determine priority of the addition/expansion of requirements relative to other established

priorities 4. Determine the timing for the addition/expansion based upon the relative priority and any

potential timeline impacts resulting from that sequencing 5. Service Provider to determine the cost impact of the addition/expansion quantified in

hours at the blended rate 6. Company to determine if the timeline and cost impacts justify the priority of the

addition/expansion a. If yes, proceed with General Process (see above) b. If no, Scope Change is retired

Removing Requirements The removal of requirements is a low risk to the project and as a fixed bid, no refund or return will be given to Company by Service Provider if previously approved requirements (from either the original scope or an approved Scope Change) are removed except as set forth in Step 3

18

below. As such, the removal of requirements is usually transformed into a requirements substitution. Therefore, the following workflow must be enacted for the removal of requirements:

1. Determine if the Scope Change is truly a removal/cutback of requirements a. If yes, proceed to step 2 b. If no,

i. If Scope Change is a requirements substitution proceed with Substituting Requirements workflow (see below)

ii. If Scope Change is non-impactful, Scope Change is retired 2. Determine any dependency impacts to the removal/cutback of requirements such as the

existence of a valid requirement dependent on the requirement proposed to be removed a. If yes, assess dependent requirements through General Process (see above) and

determine viability of overall Scope Change i. If viable, proceed to step 3

ii. If not viable, Scope Change is retired 3. Determine overall effort saved due to the removal/reduction of requirements from both a

functional and a technical perspective and adjust the cost saving due to removal of requirements against any additional and/or substitute requirements

4. Proceed with General Process (see above)

Substituting Requirements The substitution of requirements can generally be accomplished without large impact to the established project timeline and cost, however there are exceptions that can have massive impact to these factors. Therefore, the following workflow must be enacted for the substitution of requirements:

1. Determine if the Scope Change is truly a substitution of requirements a. If yes, proceed to step 2 b. If no,

i. If Scope Change is a requirements addition proceed with Adding Requirements workflow (see above)

ii. If Scope Change is a removal/cutback of requirements process with Removing Requirements workflow (see above)

iii. If Scope Change is non-impactful, Scope Change is retired 2. Determine type and effort (quantified in hours) for both sets of requirements in the

proposed substitution (original requirements, substituted requirements) 3. Determine if the type is the same1 and the effort is no more than a 5% delta for the set of

requirements to be substituted a. If no, re-evaluate old requirements using Removing Requirements (see above)

and new requirements using Adding Requirements (see above) b. If yes, proceed to step 4

1!Due!to!resourcing!constraints,!only!requirements!(or!sets!of!requirements)!within!the!same!functional!and!technical!scope!(requirement!“type”)!may!be!substituted.!Exceptions!may!be!made!upon!mutual!agreement!between!Sony!and!RightsLine.!

19

4. Determine priority of the requirements to be substituted relative to other established priorities

5. Determine the timing for the substitution based upon the relative priority and any potential timeline impacts resulting from that sequencing

6. Company to determine if the timeline and cost impacts justify the priority of the substitution

a. If yes, proceed with General Process (see above) b. If no, Scope Change is retired

5. Terminology The overall success of the Project described in this Schedule #1 is dependent upon the ability of Service Provider and Company to understand their respective responsibilities. When words such as “convert, conduct, execute, develop, create, write, perform”, are used, this typically denotes that the party associated with these words will be responsible for completing the associated tasks. When words such as “monitor, advise, direct, review” are used, this typically denotes that the party associate with these words will provide guidance and direction regarding completion of the task or step, but does not represent that that party will be responsible for ensuring completion of the task or step. 6. Overall Project Assumptions

The following, generic, overarching assumptions are made in regards to our ability to complete the project within the terms set out in this statement of work:

• Service Provider will have access to Company business resources, as determined necessary by Company, in a reasonably timely manner and during normal business hours to collect requirements in conjunction with the Company project team

• Service Provider will have access to Company technical resources, as determined necessary by Company, in a reasonably timely manner and during normal business hours to collect integration and other technical requirements in conjunction with the Company project team

• UI designs from Zuno will be provided in a format reasonably acceptable to Service Provider in order to implement them

• Timely input from key Company executives regarding key design decisions • Company will appoint a point-person “Project Manager” for the project. This

individual will make reasonable efforts to enable Service Provider to execute the work plan, coordinate Company resources as appropriate, and help remove any barriers

• Appropriate Company resources as determined by Company will respond within 4 hours during normal business hours, 9:00 a.m. to 6:00 p.m. PT, to assist with problem determination and resolution as appropriate.

• Changes in the Project described in this Schedule #1, including the scope of services and/or requirements may require revising the estimates and costs; provided, that any such change requires the written approval of both Service Provider and Company.

20

• It is mutually understood that most of the deliverable development for the Project may be done remotely by Service Provider employees at the Service Provider offices in Los Angeles, CA

• All issues and decisions requiring Company approval are resolved within 2 business days or risk delay to this project timeline and delivery of the Product

• Company will provide administrative support during normal business hours to schedule all meetings with Company personnel

• Company will provide adequate working space in their Culver City offices to support up to three Service Provider employees when necessary to be working on-site