The general practice of working with Requirements from Clients and a Scope Of Work from a Supplier, trickling down throughout the chain of Client – System Integrator – Supplier – Sub-supplier might be ready for simplification, saving all parties (so ultimately the Client) significant time and money by working with one Scope Of Work throughout the whole contracting chain.

Problem description

For the more complex projects a Purchasing Department regularly works with a structure where the Client first describes a Requirements document, in case of formal tenders often in the form of a Request For Proposal. Suppliers of solutions then respond with a Scope Of Work describing what exactly needs to be done, this Scope Of Work often becomes the basis for the contract governing execution. The underlying reason using a combination of these documents is that a Client usually is pretty capable of defining the ‘What needs to be done’ but much less the ‘How it needs to be done’, which is exactly the reason to outsource to the vendor.

Such a procedure requires quite some legal and negotiating effort to ensure alignment of both these documents and in many industries profitability of vendors is determined by how minimized they can bid for the work – and price accordingly – to get it awarded, and then earn their margin from the changes or upsells. This method of working provides a devilish incentive for the Supplier to ‘seem to have agreed to fulfill the contract’ but to exploit errors and omissions in the Requirements to the detriment of the Client. This situation is quite similar to when a consumer buys a newly built-house and then finds out that the kitchen is really basic but for a royal fee a better-fitting kitchen can be built in. These changes all need to be negotiated again, which macroeconomically leads to a significant ‘overhead’ in administration. Ultimately, the Client pays for this of course. New, inventive contracting methodologies, like Vested ®, are coming up to optimize the Client – Integrator relationship.  This blog focuses on the documentation in the relationship, regardless of how that is formed.

Note: purists might want to point out the differences between a Scope Of Work, Statement Of Work and Work Breakdown Structure. For readability’s sake this distinction is not elaborated here. For the same reason I will leave all the various different steps and documents in an RFP-process out here as well. The same applies for Main Contractor, General Contractor and System Integrator. These nuances are relegated to academic papers outside of this blog.

Design, Build & Maintain

And it can become worse: within Design, Build and Maintain (DBM), like large buildings or technical installations, a further complication is brought by the frequent interactions among the various steps in the process: the initiative is passed back and forth among the parties depending upon the stage in development. The following diagram shows the myriad of interactions – and thus possibilities for handover failure in a simple situation with only one sub-supplier.

Proposed solution

One way of circumventing both the resulting bureaucracies and the possibilities of error and misunderstanding could be the writing of one Scope Of Work by both Client and Systems Integrator and then sharing and amending this document with the various suppliers, to be used as a basis for their own Work Breakdown Structures, RASIC, and thus pricing. When contracting out, all parties should be amenable to adjusting the Scope Of Work based on the inputs of all other parties, but maybe even more importantly: by allotting responsibility of the tasks clearly to the responsible participants.

There are several requirements – or risks – for such a simplification to work:

• the Client and the System Integrator need to have a strong Master Service Agreement guaranteeing the integrator their place in the value chain. If the various roles in the project have not been set up clearly, too much time is being spent ‘jockeying for position’.
• the same applies to the relationship between the System Integrator and the vendors. Ideally they also have worked together for other Clients to build on these experiences (a regular clause in RFP’s).
• the Supplier and the System Integrator need to have a clear agreement about communication lines: it might be tempting for vendors to communicate directly with the Client – often on the basis of informal contacts ‘just about this small detail’ – but that practice has a tendency to gradually grow a relationship off kelter.
• all parties need to be willing to investigate into larger project team meetings where the agenda will be dominated by items they are not always directly involved. Especially with large videoconferences the tendency of ‘tuning out’ for significant blocks of time is lurking.

Still, these risks are minimal given the speed of action, improved transparency and reduced bureaucracy resulting from one ‘Version of the Truth’ which is possible with today’s technology. Let’s use it to our advantage!