United States: An Innovative Approach To Collaborative Contracting

Keywords: contracting, technology providers,

Companies regularly work with technology providers on collaborative projects. In collaborative projects, the customer and the technology provider each bring key resources and expertise as they work together to, for example, implement a complex new computer system. The customer's goals are generally to obtain the intended results on time and within budget. Unfortunately, the provider has conflicting incentives to have the project be larger and cost more. All other things being equal (including price), each party would like the other to do more of the work.

Contracts for collaborative projects often produce poor results. Systems implementation projects, for example, are notoriously late and over budget. One possible reason is the mindset that contracting lawyers bring to these projects. Because collaborative projects involve services, they are documented as services agreements. The critical role of the customer in providing resources and expertise is expressed in broad "assumptions" that regularly turn out to be incorrect as the project unfolds. The contract may require the technology provider to pay "credits" for failing to meet "milestones," but those credits are often not payable because of incorrect assumptions.

On a parallel path, a team of technologists is often documenting a project agreement that works well and is called a "project plan." The project plan assigns each party the responsibility to perform activities and deliver results, such as software that works well. The project plan recognizes the role of collaboration by indicating that a party's level of involvement may range from responsible to assisting to consulted to informed. The project plan is often designed and managed by certified project management professionals. Regrettably, the project plan often has little to do with the legal agreement. Also, the project plan lacks the force of law.

We have been working with clients on what we believe to be an innovative approach to collaborative contracting. The approach consists of the following steps:

In this new approach, the legal contract reflects the project plan in allocating responsibilities for activities and deliverables to the parties. This approach has three advantages. First, it gives legal force to the project plan, which is a substantial benefit to project leaders who often have few tools beyond pestering and escalating. Second, it allows the customer personnel who will be running the project to take lead roles in defining the contractual obligations through a well-organized template. Finally, it creates a contract that is used, delivering actual value, instead of being put in a desk drawer and becoming increasingly irrelevant as reality diverges from the contract assumptions.

In our brief experience with this approach, it appears to provide surprisingly good results. Collaborative project customers tell us that they have more control over their projects and more ability to obtain their desired business outcomes. The providers tell us that they find this approach reduces risk and builds stronger relationships.

We are writing this article to share what we hope to be valuable insights and to solicit thoughts from our readers on how we might improve these ideas and their usefulness.

Step 1: Determine Deal Structure

First, determine a structure for the project by asking such questions as:

• What is the scope of the project?
• When should it be completed?
• Who is responsible generally for what parts of the project?
• What constitutes completion? How will progress be measured?
• How will the amounts payable to the provider be determined?

The pricing for collaborative projects is often designed to create an incentive for timely, on-budget completion of deliverables. Common structures include fixed fees, fee caps, holdbacks, milestone credits (payable by the provider for failure to meet project milestones) and discounts that increase as the price rises.

Step 2: Determine Project Stages

Second, determine the high-level stages for the project. For example, these are typical stages for an enterprise resource planning (ERP) implementation project:

• Design or blueprinting
• Build or development or realization
• Test or verification
• Rollout or deployment
• Support or maintenance

Other collaborative projects may have other stages, such as "Project Kick-Off." As lawyers, we find that the customer's project manager generally knows the stages well and, if not, there likely are "best practices" available that define the stages.

From a contracting standpoint, it helps if stages are designed so that completion of one stage will be a "stage gate" (what we lawyers might call a condition precedent) to beginning the next stage. In any event, stages should be defined based on when they start, the activities and deliverables to be completed, and when they end.

Step 3: Define Activities and Deliverables

This third step is where the collaborative contracting approach diverges from the traditional services contract approach. Traditional services contracts tend to describe each of the stages identified above, as well as the associated activities, deliverables and milestones, by fitting them into a narrative description, often in no particular order and using varying terms for the same concepts. This results in a contract that is confusing, too long, internally conflicting and difficult to amend to reflect the natural evolution of the project. So it often ends up in a desk drawer instead of being an effective tool to deliver business outcomes.

In step three, we recommend that the parties identify the activities required to complete the project, without regard to which activities will be performed by the supplier as "Services." As the parties identify activities, tangible outputs of those activities are also identified and described as deliverables. For each activity and deliverable, the parties agree on completion criteria. In this effort, the customer's business and technical teams provide the substance and the legal team documents that substance at a contract-level of clarity.

Each activity and deliverable is assigned a capitalized defined term that can be used in the remainder of the document. Those defined terms are then listed on an Activities Exhibit and a Deliverables Exhibit.

These defined terms are the fundamental building blocks for later stages and create a modular approach that is easier to modify and easier for the drafters and reviewers to manage—most typically the engineers who will be completing the project or living with its consequences upon completion. For example, the contract might use the term "Module X Specifications" as follows:

• In Stage 1: Interview persons listed in Exhibit Q to obtain data required for Module X Specifications.
• In Stage 2: Develop Model X Specifications and obtain customer's approval.
• In Stage 3: Develop Module X such that it complies with the Model X Specifications in unit testing.
• In Stage 4: Test integrated system, including verifying that the integrated system complies with the Model X Specifications.

Not all activities will result in a deliverable. For example, testing may result in a post-test report, but it is the test itself that the implementer is being paid to perform. Activities can be divided between those of "intrinsic" value (those that are an end in themselves) and those of "instrumental" value (those that are a means to result in a deliverable). Dividing the activities from the deliverables creates a cognitive discipline and contractual rigor that forces the parties to address up front what they both expect will be included in the scope of the project.

Step 4: Allocate Responsibilities

The activities are not all "services" to be performed by the implementer. In a typical services agreement, the descriptions focus on what the provider will do for the customer, with the customer's sole responsibility being paying for services. Some customer negotiators take a general approach that customer obligations are to be avoided.

In collaborative projects, the customer, by definition, makes meaningful contributions to completing the project. There may be independencies and overlapping requirements that the supplier cannot manage and complete on its own. Further, even if the supplier can complete an activity on its own, doing so may not be practical or economically efficient. Thus, by failing to describe customer obligations, or by simply making assumptions about what is required by the customer, the traditional approach fails to capture the complete scope of the project.

In a collaborative project contract, we define activities in the same way, regardless of whether the customer or provider will perform them. We then create a matrix showing, for each defined activity, which party will be "Responsible" and whether the other party will be "Assisting," "Consulted" or "Informed." Each of those terms should be defined. For example, the definitions might clarify that a Responsible Party manages, executes and completes; an Assisting Party provides commercially reasonable assistance to the Responsible Party; a Consulted Party is involved in discussions to provide guidance but not assistance; and an Informed Party merely receives progress reports. In practice, the customer might be Responsible for end user testing, but the provider might be classified as Assisting by, for example, providing guidance on testing methods and software attributes. Specific types of assistance can be defined if known when contracting, but the nature of collaborative projects makes it difficult to do so comprehensively.

This approach works better than the common alternative of assigning responsibilities to both parties or making them joint responsibilities. Joint responsibilities fail to establish a contractual commitment, because neither party can be in breach.

This approach also works better than the traditional approach in which the customer seeks to impose broad obligations on the supplier and the supplier seeks to evade them by including broad "assumptions" in a footnote or at the end of the document. For example: "This price assumes that Client will provide resources and information as needed for completion of the project." Using such assumptions creates a number of problems:

• The assumptions are removed from the context and the chronological order of the particular stage and thus often work poorly in practice.
• The assumptions are often poorly defined, without a way for either party to establish or confirm that the activity has been completed.
• Such vagueness causes disputes that delay the project and harm the working relationship between the customer and provider.

Step 5: Establish Milestones

In this approach, a milestone is the date when the Responsible Party must complete a specified set of activities. We recommend defining milestones after defining activities and deliverables for the project and allocating responsibilities for completing those activities and deliverables. Under the traditional approach, defining milestones involves difficult, relationship-challenging negotiations, with tortured language describing the qualifications and establishing exceptions, limitations and assumptions. We believe that this occurs because the parties attempt to define milestones before completing the hard work of defining activities and deliverables and allocating responsibilities. Providers are sensibly averse to promising to complete an undefined portion of an undefined task by a time certain, particularly without a commitment from the customer to timely do necessary work. Contentious milestone discussions are only a symptom of the larger problem that the project goals and scope have not been clearly defined and documented.

Under the collaborative contracting approach, the parties can reference the applicable activities and deliverables and make achievement of the applicable milestone contingent on completion of those activities and deliverables. Because there are defined terms for each activity and deliverable, milestones can be defined in a way that is both simple and accurate using those defined terms. The milestone should clearly point to the elements that make up the desired completion stage-gate, including the intrinsic and the instrumental activities.

The milestone definitions will appear in an exhibit that describes the entire scope of the project, from beginning to end, as a series of achievements in a certain order, each vetted and agreed upon by the parties. Each milestone gets its own capitalized defined term for easier reference when documenting pricing and follow-on milestones, as well as for use in future amendments and operational "Milestone Submission" and "Milestone Completion" notices. Rather than fitting the entire description of a milestone into a single cell of the date table, the name points to the building block description, which in itself is derived from activities and deliverables.

Step 6: Link Compensation to Milestones

Customers who see value in sharing schedule and delivery risk with the provider or providing a monetary incentive for the provider to achieve desired business outcomes can do so by linking the provider's compensation to the milestones.

For example, fees might be payable in whole or in part only when a Milestone Completion Notice has been signed by the customer. Alternately, the provider might be required to grant or pay "milestone credits" for late achievement of milestones or might be able to charge only limited amounts for work connected with particular milestones. Here again, the documentation is simplified when there are defined terms associated with each milestone.

Step 7: Link the Collaborative Contract to the Project Plan

The definitions of activities, deliverables, responsibilities and milestones become the skeleton of the project plan. The project plan will include numerous sub-activities, such as allocations of work activities to named people, and interim deliverables, such as initial drafts of deliverables.

To link the project plan to the contract, the project plan should be built using the defined terms and milestone dates from the contract. Then, when those aspects of the project plan evolve, the parties agree to modify the contract to reflect the changes.

The value of linking the project plan to the contract includes:

• Better understanding of the contract obligations, because those are integrated into the plan that the teams use every day.
• Legal, financial, procurement and management personnel review of key changes to the project plan (because related changes are needed to the contract).
• Enabling the project team to use the legal rights in the contract as tools to motivate the provider to make the project plan successful.
• Better project plans, because they are built on well-defined terms, mitigate the risk of misunderstanding and dispute that comes from trying to capture difficult concepts in small cells on spreadsheets or project plans.

Conclusion

We believe that the approach described here is a significantly better way to document a collaborative contract, because it reflects the necessary collaboration and fits with the way these projects are actually run. Particularly when used with the templates that we have developed for this approach, we believe that it takes less time overall and less legal cost, because it allows project managers to take a leading role. We look forward to discussing it with clients and friends.

Originally published 19 December 2012

Visit us at mayerbrown.com

Mayer Brown is a global legal services provider comprising legal practices that are separate entities (the "Mayer Brown Practices"). The Mayer Brown Practices are: Mayer Brown LLP and Mayer Brown Europe – Brussels LLP, both limited liability partnerships established in Illinois USA; Mayer Brown International LLP, a limited liability partnership incorporated in England and Wales (authorized and regulated by the Solicitors Regulation Authority and registered in England and Wales number OC 303359); Mayer Brown, a SELAS established in France; Mayer Brown JSM, a Hong Kong partnership and its associated entities in Asia; and Tauil & Chequer Advogados, a Brazilian law partnership with which Mayer Brown is associated. "Mayer Brown" and the Mayer Brown logo are the trademarks of the Mayer Brown Practices in their respective jurisdictions.

© Copyright 2012. The Mayer Brown Practices. All rights reserved.

This Mayer Brown article provides information and comments on legal issues and developments of interest. The foregoing is not a comprehensive treatment of the subject matter covered and is not intended to provide legal advice. Readers should seek specific legal advice before taking any action with respect to the matters discussed herein.