Introduction

This document discusses all kinds of projects, contract forms and the related aspects, but it concentrates on development projects and the related risk aspects. To illustrate these aspects, we will assume a 'supplier' who –through a project– produces some 'product' for a 'customer'.

Contract Scope

Many project contracts involve a lot more than to develop and/or build a specific 'product'. The scope may cover:

Design: make a detailed plan how the product is going to look like.
Some businesses (with large and expensive projects) make a distinction between Basic Design or Top Level Design and Detailed Design or Engineering. The purpose of the Basic Design is to identify the major components, and define the costs and risks. A Basic Design requires limited effort and should provide a work breakdown and planning, so it is possible to estimate the costs and time to build the total product within a 10% margin. The Engineering is required to describe all components/utilites/facilities and documents to actually build the product (less complex but a lot of work).
Build: actually construct the product.
Again, some businesses make a distinction between Procurement (ordering –long delivery/custom build– components, potentially on behalf of the customer), and the actual Construction of the product. When combined with Engineering (=Detailed Design), you get an EPC-contract (Engineering, Procurement & Construction). Commonly this will be a 'turn-key' project (i.e. the supplier takes care of everything until the resulting product can be put into operation). The hand-over is through a commissioning which includes the 'start-up' of the product.
Finance: take care of all investment costs. Sometimes the customer will not buy the product but use it against a fee.
Maintain: do maintenance of the product for a defined period (and at a defined price).
Operate: operating the product (i.e. provide service) for a defined period.

Commonly, the scope of the contract, or the scope project to execute the contract, is indicated by the first letters of above list. So a DBM-project requires Designing, Building and Maintaining of a product by the supplier for the customer. If Financing would be included, the customer effectively leases the product. For a full DBFMO-project the customer in fact buys a service which requires a unique product. Note that operating a service requires completely different skills than the design & build of a product.

Note that a Design & Build is only acceptable for a supplier if he has done similar projects for a similar environment before, otherwise there are too many risks ('unknowns'). And building a single house, or a 100 appartments building is not the same; and building in a rural area, or in the city or on the south pole is not the same environment.

This document ignores Financing, Maintaining and Operating the product. However, it should be clear that those aspects bring their own costs and risks.

Development Project Risks

When developing a product to sell, the major areas for risks are:

The development risk: the uncertainty whether the development takes the budgeted effort (costs) and time,
That is the main subject of this paper.
The product performance risk: whether the developed product performs as specified (or expected), and whether the product manufacturing costs remains acceptable.
That is partly adressed here.
The marketing risk: whether the expected gains (e.g. sales) will be reached.
We will not analyse that any further.

As the costs and risks should be exceeded by expected gains, they should be included in the analysis. However, the costs/risks and gains not always lie with the same party ! If such is the case, there is a serious issue with diverging objectives for the distinctive partners (effectively they are not 'partners' anymore). Some compensation for extra work and/or benefit sharing scheme may mitigate this risk. Or another Contract type or Co-operation scheme should be selected.
The risks are largely determined by the type of development the project is supposed to do, the risk may be with the supplier or the customer depending on the type of contract between them. Below we will analyse these in more detail separately.

Development types

First we will analyse what kind of development the project is to do, and what the related risks are (i.e. what kind of 'product' the project is to produce).

Generic development: The development of a general –basically market independent– product.
The investment is obviously a loss, probably not fully determined. The gain should be in selling the product many times over, but the revenues are probably also not fully determined.
The requirement specification for the product is created by the owner/investor (which is not necessarily the developer) considering features based on expected market demand. The development and marketing risks are for the owner, and are in general considerable (new product and/or new technology, so not much experience). Commonly all rights are with the owner (partly when licensed technology has been used), but the developer may also claim particular (method) rights.
Market/Customer Adaptation/Design Engineering: The adaptation/extension of a generic product for all deliveries to a particular market segment (e.g. application area, country, or large customer).
The effort should be considerably less than for the 'generic' product and therefore the risks are much more limited, while the revenues should be pretty clear.
Site Engineering or Customer Application Engineering: The 'customisation' of an individual delivery of the product –usually a complex system– for a specific application case (typicaly a turn-key delivery). Construction of a product with standard building blocks at some specific location is a good example (environment and sizing will be different).
The effort and therefore the risks are low and commonly presented as fixed costs (as these are costs attributed to each individual product instance they should be low). Usually there is considerable experience from earlier deliveries.
Customer project: This is typically the development and/or engineering of a 'one-of-a-kind' product for a specific customer.
So the customer is responsible for the requirements specification, and has in fact bought the product via the project (most likely turn-key). The risks include budgeted costs and time, and product specifications (whether the product will perform to requirement specifications); together the project risks are relatively high (i.e. it calls for a phased approach, typically split Basic Design and Detailed Design). There is also a serious chance (risk) for changes in requirements specifications. Responsibility for risks (& costs) are with the customer or the developer depending on contract type ('lump sum' or 're-imbursable'; see Contract type below). Development procedures can be predefined (otherwise 'standard practices and workmanship').
This type of project has characteristics of both the 'generic development' and the 'site engineering' projects.

Contract Type

Now we will analyse the main customer/supplier contract for the development of the product.

Lump sum project: The supplier will execute the project for a fixed budget.
As the supplier carries the development risk, his margins should reflect that. The acceptance criteria are very important. Commonly, the risks are clear and limited (or at leased quantified and incorporated in the price). Sometimes a supplier offers the project for a very low price hoping to acquire this project, and to make profit on the 'change orders'.
Re-imbursable project: The supplier will execute the project, but all costs are paid for by the customer (usually on hours spend).
The risks are with the customer, in particular in time and effort budgets as often additional requirements are added along the way ('scope creep'). The supplier will have thin margins but hardly any risks. The supplier is hired for his expertise and manpower, and the customer may specify levels of expertise for project members, specific working procedures and tooling.
This type of project is also applied when it is impossible to make sufficiently reliable estimates (e.g. the requirements are incomplete, many boundary conditions and/or unclear what problems can be encountered).
A Re-imbursable project is different than Detaching regarding the location, management and facilities for the project.

High risk (& high profit) projects are commonly 're-imbursable'.

Specific contract types

Subcontracting:: The supplier may 'subcontract' parts (work or components) of the project/product to another supplier, which is called the 3^rd party supplier (3^rd party provider, 3pp). Commonly for specialised parts by a specialised organisation. In extreme cases the main supplier is only a 'systems integrator' (see Systems Integration below). For the rest, subcontracting is just another 'project'; the reduced scope results in reduced risks (reduced profit) which is often reflected in a lump sum contract.
A special case is when a customer specifies only the development of a product, but not the production (see Design Project).
The supplier is responsible for the development (humans, means, procedures).
Systems integration:: Can be considered an extreme case of subcontracting: the system integrator accepts the whole project, defines the system's architecture (decomposes the 'product' into components), subcontracts or procures the (potentially of-the-shelve) parts, assembles all and makes it work together.
In some cases the architecture and/or components are already defined; the system integrator is to make it all work together (i.e. perform the System Integration Test and solve interface problems). In such cases commisioning or qualification is commonly included.
It is typically used for a complex project involving distinct disciplines (e.g. a 'project developer' for factory construction). In such cases the effort (and risk, hence margin) to make things work must not be underestimated.
Design project:: A special project where a customer contracts the design/development of a product, to be produced (and sold) by the customer itself. I.e. a 'product development' case where 'producer' and 'developer' are distinct organisations. Typically applicable in building architecture.
The rights on the product are basically with the developer, but the contract may stipulate otherwise; the rights of the requirement specification are always with the customer/producer (commonly requiring a 'non-disclosure agreement' from the developer for particular technology). This implies that the developer can not sell an identical product again, but selling a similar product (on similar requirements of another customer) is possible. Commonly, there are some specifics in the requirements specification (e.g. patented methods) which preclude 'similar products'. On the other hand, the product may include specific technology of the developer, precluding the customer to market further variants of the product. One may attempt to include or exclude such rights explicitly in the contract.
Commonly done by a specialised 'design bureau' for a customer who wants to market the product. The supplier is commonly accredited for the product, and may receive a license fee per product sold (e.g. architects, industrial designers, etc). The 'marketing risk' is with the customer, and he is also required to make provisions to maintain the product (potentially with the developer).
Contrary to other projects, for software projects it is not uncommon to specify that the rights (for unlimited use) are with the customer (they may want design info –including source code– at least under escrow).
Detaching:: Also known as 'body shopping'. The supplier only provides people with specific expertise, which are located at the customer. Overhead, management, means, procedures and all risks are with the customer. Margins will be low; in some cases the supplier is only providing the initial contact (i.e. only gets a 'finders fee' like a head hunter).
Outsourcing:: Not so much used for projects, but for well defined tasks or services. It is not carefree; the outsourcing party will still have to actively monitor the performance of the sourcing party, and act on shortcomings (so the contract should specify quality levels and/or performance indicators). In practice there are often recurring issues on what is in scope and what not. Outsourcing design to 'cheap countries' ('offshoring', 'far shoring') proves to be cumbersome as there is a significant cultural gap. And you can not outsource problems (which is what most companies hope to achieve, but that requires at least subcontracting).

Bid Sequence

Very often a customer can not describe exactly what he wants to buy, for example because he is unaware of all potential solutions. For such cases, he can start an iterating process of requests and responses with increasing detail and engagement to get to a contract agreement: a bid sequence.

RFI: Request For Information: An uncommitting request for information on the problem area; the expected response is ideas how the problem could be solved (often resulting in nice marketing presentations on architecture). Indicative estimates of costs are required. For new technology the customer may require a Proof of Concept (PoC): a demonstration (often in a development environment) that the technology works.
The purpose of this phase is to determine whether a (technically & economically) feasible solution exists, and what it would look like; a possible outcome therefore is that the bidding process is stopped when it becomes clear that there is no viable solution (yet).
RFP: Request For Proposal: An invitation to present a concrete solution. The response should be a clear (technical) proposal; prices are required, but are budgetary only as exact application, size/numbers and conditions are still unknown. Specific issues (e.g. migration) must be addressed.
RFQ: Request For Quotation, or ITT: Invitation To Tender: An exact description of what is needed, when, where, and under what conditions. The response is a
Bid / Tender:: A detailled offer with all prices and schedules, i.e. a proposal for the contract. All parts are committing, though contract negotiations may modify them. A Statement of Compliance can be a required part of the bid.
SoC: Statement of Compliance: A point-by-point response to the Requirements Specification (i.e. at the level of the individual requirement or paragraph). The allowed response is usually limited to: Complied (fulfill the requirement unconditionally), Noted (when the paragraph does not entails any requirement but for example explanatory text), and Not complied. Regarding the last case, there can be several variants: there can be some restrictions (which should be stated in the response), or the issue addressed in the requirement is solved in a completely different way (e.g. the requirement 'the processor must be duplicated' is not really applicable in a distributed processing environment).
LOI: Letter Of Intent: Commitment to buy (without the contract details being complete), so activities to deliver may start. Used when there is a considerable lead time (e.g. to buy, produce or develop particular items).
Contract: All details about what and how to deliver for what price and under what conditions are defined. A delivery/introduction/migration-schedule will be part of the contract.
When the contract comprises multiple products which need to be customised per individual delivery, it is commonly an Umbrella Contract: not specifying a specific product but a product range and a component price list, and not specifying a delivery date but the lead time between order and delivery. The configured products are ordered individually with specific data in accordance with the contract.
NDA: Non-Disclosure Agreement: Some contracts involve access to confidential (technical) information of the other contract party. During the bidding process (in anticipation of a contract), you may need to sign a Non-Disclosure Agreement (and/or have the other contract party to sign an NDA).

Co-operation Schemes

In some cases –in particular in the area of Research & Development when the costs and risks are a bit fuzzy– it is better to use some other form of co-operation than the strict customer/supplier relationship as that has its disadvantages as well (in particular the required expertise in specific areas). The major forms are:

Check: This is the traditional contract relationship between a customer and a supplier, even if it is with a preferred or outsourcing supplier, subcontractor or franchise.
Co-ordinate: Generate products or services together in a controlled way. The relationship is not between equal partners; the second party has to deliver expertise and added value (e.g. with the first party as lanching customer).
Co-operate: Co-operation between parties with shared goals and interests (e.g. to share costs and/or gains, and/or increase productivity). Commonly between more or less equal partners. Typical terminology: alliance, co-sourcing, co-makership.
Co-create: A relative new and open form; there is no contract but only some mutual agreed intention. Typical terms: innovation, open sourcing, collective intelligence, strategic alliance.

Miscellaneous

Special attention may be required for Intellectual Property rights (licensing) and Co-operation projects.
Software (as a result of a development project) is also a special case, as it is very cheap to reproduce (once developed). Proper maintenance on software is however not trivial. See for example considerations on Software Reuse.

=O=