Earlier this month, we discussed the significance of the transformation workstream in outsourcing transactions and outlined important topics and points to consider when documenting the overall transformation methodology exhibit. Depending on the scope and timing of the transformation, there may be a need to document individual projects in separate statements of work or project schedules.
In Part 2 of this Contract Corner, we provide a checklist that outlines key considerations when documenting individual transformation projects.
- Scope and Objectives. Ensure the project accurately and comprehensively describes the scope of the services and deliverables, including any system functionality and specifications that are required. If an existing system is being replaced, ensure it is identified and that, at a minimum, all existing functionality continues in the replacement system to the extent desired. It is also crucial to define the business objectives to be achieved by the project, such as modernized technology, efficiency, flexibility, standardization, and enhanced data. Finally, ensure the scope requirements are structured to align with the milestones (e.g., by wave, phase, or workstream).
- High-Level Plan. High-level plans are critical to ensuring completion dates and deliverables are integrated and met on time. Projects will typically include an initial high-level plan (e.g., a Gantt chart) that outlines the overall timeline of the project and that will be used to further develop the detailed project plan.
- Milestones, Deliverables, and Acceptance Criteria. One of the most important parts of the project document will be the milestones and associated completion dates and acceptance criteria. A good practice is to include a milestone table that identifies each milestone by name (e.g., completion of design and build, testing, go-live, and stabilization), the key deliverables and activities that must be completed, the completion date, the acceptance criteria, and any payment terms (such as milestone credits or fees). As noted above, ensure that the milestones and deliverables align with the structure and approach of the project. For example, the project may require a different approach to milestones if it is following an Agile methodology as opposed to a Waterfall methodology.
- Compensation. As we noted in Part 1 of this Contract Corner, payment structure will likely be the most heavily negotiated piece of the transformation. The project will need to reflect the ultimate business agreement and include the appropriate payment mechanisms, such as milestone payments, fixed fees, and not-to-exceed amounts.
- Sites, Environments, and Connectivity. Ensure the project document is clear on where the services are being performed. If the provider’s sites are used, identify where they are located. If space at the customer’s locations are required, are there any limitations on available space and seating? It is also critical to be clear on who is responsible for providing the environments and assets that are required to complete the project, and to identify any specific connectivity requirements if the provider is connecting to the customer’s network.
- Staffing and Subcontractors. The project should include the provider’s staffing model. If the project is to be completed on a time and materials basis, it should include the specific roles to be staffed and the applicable rates. If the project is to be completed on a fixed fee basis, consider whether the staffing is an estimate and what happens if the provider requires additional staffing to meet the requirements of the project. In addition, if subcontractors are permitted or require approval, include a list of the approved subcontractors being used.
- Reports. In addition to the general reporting requirements outlined in the methodology exhibit, consider whether certain projects require reporting specific to their scope and structure, such as reports on staffing, time worked, productivity, and deliverable status.
- Internal and External Change Management and Communication. Transformation is often disruptive to the customer’s operations and client base. If not included elsewhere in the agreement, it is important to consider what is required with respect to internal acceptance of the changes, internal and external buy-in, process and operational changes, training, and communications to third parties.
Our third and final post in this Contract Corner series will discuss specific considerations and issues for defining when a transformation project is “done.”