To run any contract it is essential that it is well defined; or if it cannot be defined, that the risk and management framework is in place to manage the changes effectively. However, the best advice is always to nail down everything that you possibly can. The benefit of this is that it creates certainty for all parties involved and even if you need to change, you have a clear baseline from which to control the effect. There are 3 parts to effective contract definition:
- Firstly, making sure that you understand the philosophy of your proposed procurement route and form of contract. Procurement route and form of contract are frequently muddled and the whole process gets off to a bad start. Procurement route is how you intend to package up the risk of the contract, whereas the form of contract is the legal framework for its governance. For example, the philosophy of design build procurement is that you must make clear what you want and then avoid making changes. The philosophy of an NEC contract is that you work as a team to administer the contract as you go following the management principles outlined in the contract. You would therefore expect a clear set of Employers Requirements that would require little or no change and weekly site meetings to keep on top of any contract administration or risks.
- Secondly, you must know what you want. It is surprising how many clients and their advisors allow projects to move forward without being sure what the end result will be. If you are in hi-tech sectors programming decisions on latest start logic is fine; but for most clients it is possible to be clear about what you want. Do not be tempted to use provisional allowances or to kick a can down the road on a decision. A good test is to ask yourself what will really be any different in six months’ time to make not making the decision now any better.
- Finally you must be able to define what you want. Do you know what your essential “control documents” are (see our blog How to make sure you learn the lessons from your programmes and projects). These documents enable you to not only capture what you want but to define it in a way that the supply chain understand; without creating uncertainty or ambiguity (which have the effect of increasing the programme or price). If you frequently deliver projects then you can expect to have standard control documents but if you are a one-off client you are very dependent upon your project team creating the best possible documents on your behalf. Whichever you are, make full use of time to review the proposed documents and be sure that they define what you want.
Now we need to capture these requirements in a contract and that will be the theme of next week’s blog.