Tech & Sourcing @ Morgan Lewis

Contract Corner

In an ideal outsourcing relationship, technology transformation through innovation, continuous improvement, and future project work is never really “over.” When documenting an initial transformation program and individual project statements of work, however, there are typically specific end dates in mind to achieve the desired outcomes. But defining when transformation is “done” is not as simple as agreeing on the end date or even the final deliverable.

As we discussed previously in Part 1 and Part 2 of this Contract Corner, the transformation workstream is often complex and can contain numerous interdependencies between projects, milestones, and deliverables. In order to define how the transformation reaches its conclusion, both the overall methodology exhibit and the individual projects need to work together in providing the framework and process for closing out the work successfully.

In Part 3 of this Contract Corner, we outline a layered approach for defining the end of the significant stages of transformation projects and the overall program.

  1. Milestones. Building on the discussion of milestones in Parts 1 and 2, the contract documents should identify the transformation milestones and their associated completion dates and acceptance criteria, along with the key deliverables and activities that must be completed in connection with the milestone. It follows that the completion of a transformation milestone should formally occur upon successful completion of all deliverables and activities associated with the milestone and formal acceptance by the customer according to the acceptance process defined in the methodology. This milestone signoff process is critical for the release of milestone payments and determining when milestone credits are due.
  2. Phases and Waves. As we discussed in Part 2, one option for structuring the scope of work under a transformation project is to organize it around phases and/or waves. For example, the design, build, and test phases may be repeated by waves that are arranged around functional components of a system. Each phase or wave may itself contain multiple interim milestones. In this stage of the transformation, consider defining completion as the time that all associated milestones (see #1), deliverables, and activities are completed and accepted.
  3. Go-Live (The Beginning of the End). One of the major milestones of each project is likely to be the “go-live” date. This is typically the date and time when the applicable system, as implemented, configured, and enhanced under the project has been accepted by the customer and is ready for productive use. Go-live is an important milestone that signifies that the transformed technology is ready for use in the real world. However, this should not be the end of the project, but the trigger to begin the stabilization stage.
  4. Stabilization or Hypercare. Now that the new or modernized system is live in production, there should be a period of time during which the service provider is required to demonstrate that the system is stable and performing as expected. A predefined set of exit criteria (e.g., service levels are being met and all major issues are resolved) is a good practice for outlining what steps the service provider needs to take to exit the stabilization stage. The stabilization period should have an agreed upon timeframe, such as 90 days after go-live, but it should not end until the service provider can demonstrate that it has met the applicable exit criteria.
  5. Individual Projects. More than likely, the end of stabilization as described in #4 will be the end of the project itself. For clarity in documentation, consider stating the fact that the completion of a project does not occur until successful completion of all milestones, deliverables, and activities associated with the project and acceptance by the customer in accordance with the acceptance process.
  6. Overall Transformation Completion (The End). Having now outlined options for defining the end of each stage of a project, it is logical to define the end of the overall transformation as a means to tie it all together. Consider defining the end of the transformation program as the time when all projects (including all milestones, deliverables, and activities defined in the project documents and detailed plans) are successfully completed and accepted by the customer.

This post completes our Contract Corner series on technology transformation in outsourcing transactions. Keep checking back for future Contract Corner posts on other key issues and trends in technology and sourcing.