Sourcing Enterprise Projects – Understanding and Meeting the Challenges (part 2 of 2)

In part 1 of this discussion we described two front end challenges that, if not properly anticipated and addressed, can (and very often do) derail successful completion of enterprise projects. We’ll now turn to the downstream transactional considerations that can help position a project for success.

The Right Contract Architecture
Customer’s often grapple with how to develop the appropriate contract for enterprise projects. A statement of work alone is not sufficient to cover all the complexities of the project. Instead, customers should consider entering into a master service agreement (MSA) with the supplier. In addition to establishing a contractual framework (e.g., the form and process for developing statements of work) and the terms and conditions, the MSA should address the governing principles or “rules of engagement” for project delivery. Project delivery – especially in a multi-supplier environment – has its own rules which differ in many ways from those followed in typical managed service arrangements. Examples of rules of engagement might include:

• How to measure the quality of documentary and non-documentary deliverables.
• How long the supplier has to correct defects or non-conformities and how to avoid the “ping-pong” back and forth that may arise due to lapses in quality.
• How and when the supplier should notify customer of the need for subject matter experts.
• What the consequences are of missing a critical milestone.

SOWs are the linchpin for ensuring that the document and method of delivery are adequately described. Under the MSA framework, separate statements of work (SOWs) are better suited to address specific components or phases of work in the systems development life cycle. Generally speaking, a single SOW is not as effective because it cannot sufficiently address the distinct attributes of different phases of the typical development life cycle. Indeed, certain downstream scope (such as the details of a system build) cannot be described with clarity until the early planning and design phases are completed or more mature.

At a high level, the work for these projects often is performed in three distinct phases: (1) Design; (2) Build; and (3) Deploy. Customers often rely on the suppliers to help them prepare each SOW. While leveraging a supplier’s experience and expertise in this way makes sense, there are certain tendencies to be aware of that can jeopardize the outcome. For example, suppliers tend to rely heavily on RACI tables to define the scope. Experience has shown that RACIs are inadequate (and work to the customer’s disadvantage) because the they tend to limit (or narrow) the scope of work that suppliers should perform. RACIs also diminish (or defeat) the flexibility required for carving up the work across different phases and, if desired, among different suppliers. To avoid these pitfalls, RACIs are more effective when used as an operational tool (not a contract document) to help operationalize the demarcation lines of responsibility (i.e. to inform the day-to-day interactions).

In the context of ERP projects, SOWs are best structured as a composite of “work packages” for specific pieces of work. The work package approach has several benefits:

• Facilitating the sourcing of work to different supplier(s);
• Matching the pricing constructs with appropriate work components (e.g., time & material often is used for early design work while a fixed price is more appropriate for “Build” after the detailed design is settled); and
• Organizing implementations and deployments in different regions of the world (or different business units).

Fixed Price or Time & Materials and Schedule
Suppliers will usually ask to be compensated on a time and materials basis – perhaps with a “soft estimate” of the total projected cost through completion. This approach places the financial and schedule risk on the customer and often leads to significant budget overruns, misplaced customer expectations and ultimately friction between the customer and the supplier. The question facing customers is when is it commercially feasible to insist on a fixed fee, especially in the face of supplier statements (which hold some merit) that “we can’t fix price something where the scope isn’t certain or well defined.” A related concern is how to obtain reasonable assurance of completion (e.g., Go-Live) by a firm date.

In that regard enterprise projects differ from other projects in that they require tight (some might say hand-in-glove) collaboration between the supplier and customer, especially at business process level. Project teams often rely on the customer to provide “business process expertise” that conveys the company’s institutional knowledge concerning the impacted processes. Where performance of a component of work is heavily dependent on customer input or is uncertain (such as conceptual design, where requirements are in flux), it is difficult for the work to be performed on a “fixed price” basis. However, once the design elements are solidified, later work phases (such as building “WRICEF” in an ERP implementation) can be fix priced. Likewise, once the design is solidified (and subject to any agreed changes), the supplier should be expected to commit to a completion date.

In short, the pricing construct should be aligned with the type of work being performed within a specific phase of the project, and a firm time line should be established once the scope for a given work effort is defined. Again, that’s where the work package approach is particularly effective because the customer can more effectively work with the supplier to segregate different components of the work. Simply put, some work packages can be (and from the customer’s perspective, should be) fixed price while others are more appropriately priced on a time & materials basis. Where the work is fixed priced, the supplier should be in a much better position to commit to a completion date.

For fixed price work packages or SOWs there a variety of mechanisms that can be invoked to incent timely (and on budget) completion. For example, work packages might include a combination of payment milestones (e.g., payment upon customer acceptance of a deliverable) and a “holdback” protocol (where a portion of each scheduled payment is withheld pending completion of the entire work package). Also, if a customer could incur significant commercial consequences for delays beyond the completion date, a system of delay credits (or liquidated damages) can be employed where the supplier fails to achieve completion by the agreed deadline.

Developing the right overall contractual framework, deploying a model that organizes the work into manageable components, employing the appropriate mix of pricing regimes and establishing a firm completion schedule should go a long way towards helping customers avoid the pitfalls often encountered during the execution of an enterprise project.