Make sure you and your client agree on the deliverables expected for the project.

Sometimes a contract may specify deliverables without enough detail. This could lead to you delivering something quite different than what the client required.

If the scope is not clear, or if deliverables are not clearly listed, you should clarify with the client as early as possible.

Tagged with: deliverable • deliverables

Filed under: Client • Communication • Contract • Scope

Submit deliverables to the client (if that is required) before invoicing them.

Don’t make the mistake of not submitting deliverables, as it will delay payment.

Tagged with: deliverables • invoice • payment

Filed under: Client • Contract

If a partly completed project is put on hold (deferred project) by the client, when it is restarted it should be treated as a new project.

This includes reviewing and redeveloping the scope, project plan, schedule, and budget.

The original project team may not be available anymore, so new people will take time to get familiar with the project.

The project should be renegotiated with the client.

Make sure language in the original contract does not say that no additional costs are allowed due to delays, as the client may use that clause to refuse to renegotiate the price.

Tagged with: deferred project • delays • renegotiate • restart

Filed under: Client • Contract • Cost • Planning • Scope • Tender • Time

If, in your contract, the client instructs you to directly pass on the cost of consultants, it would be better to have the consultants contract directly with the client instead of with your company.

This is especially important when the client specifies which consultant to use.

For example, ground drilling and soils analysis.

If you are not getting paid to manage and review their work, then the client should contract with them themselves.

Tagged with: consultant

Filed under: Client • Contract • Contractors • Cost

In a contract, your company should make sure the document indicates that you will rely on information and materials supplied by the client. E.g. surveys, soil tests, reports.

If the client will not agree to this, you should make sure the contract allows money for adequate review by your company of the client supplied documents.

This is particularly important for old drawings, locations of underground cables or pipes, status of old tanks or equipment.

The client may not be able to guarantee the status of the old plant, so your company should be paid for work involved in reviewing or re-surveying.

Tagged with: review

Filed under: Client • Contract • Cost • Documentation • Scope

You should document (in writing) any design changes or delays caused by the client.

This is very important for claiming cost or time extensions.

A good change management system is important. Spreadsheets can suffice for small projects with a small number of changes, but for larger projects, a good database system will help reduce the time required for change management.

You will need to record things such as (these are in no particular order):

• change title
• time delay
• extra costs (design, construction stage services, extra construction costs, administration costs, extra workshops, safety)
• who requested the change (which person from the client organisation
• approval status
• risks associated with the change (extra risks arising from changes in the design)
• change details
• why it is needed
• name of responsible person
• associated design drawings or packages
• cost codes (linked to your accounting system)
• date of change request
• change impact (minor, moderate, major)
• consequences
• date completed

It would be ideal if these can all be entered on one page in a system. You should then be able to output reports showing just some parts (say change title and cost), without having to duplicate information into spreadsheets etc.

You do not want to have multiple systems or spreadsheets that all have different versions of the information and are not linked.

There should only be one place where all the information on the change is recorded.

Tagged with: change management • change system

Filed under: Client • Design • Documentation

If you believe a schedule required by the client is unreasonable, you should document your reasons for believing so, and inform the client of those concerns in writing.

If the client still chooses to go ahead with a schedule that you are not a party to (for example for their construction contractor) but using your company’s designs, you should inform them (with details) of your concern in writing.

This may reduce the possibility of claims and your liability in the event of contractor over runs.

If you believe a contractor’s schedule is unreasonable, you should also inform the client in writing.

Tagged with: claims • concerns • liability • overruns • schedule

Filed under: Client • Contractors • Planning • Risk

If your company is the design contractor but not involved in the construction phase you should instruct the client to notify you for your company’s input for any design discrepancies.

If your company has designed something but the field conditions on site mean a change is needed, the client or their contractor may try to back charge your company for the design changes they had to do on site.

You should include language in the contract that they must first give you the option of giving input before proceeding with changes that may result in back charges to your company.

Tagged with: back charges • Construction • design discrepancies

Filed under: Client • Contract • Contractors • Design

Always check references given to you and also that you are submitting.

• You should check that references you list for your company will in fact give you a good reference.
• Clients do check the references listed in bids and proposals.
• Contact potential references on a regular basis.
• Obtain consent from the reference company for them to act as a reference.
• Ask them to call you after they receive a call for a reference about your company.

Tagged with: bid • proposal • reference

Filed under: Client • Tender

If, during a project, the client realises a mistake in the scope or specs or one is pointed out to the client and the client authorizes or instructs a change in scope, the changes should be fully documented. These changes should be marked on all copies of the scope or spec documents, and also on digital versions of the scope or specs.

If a change is not marked on every copy, someone from the project team might work with an old copy of the scope or spec and thus not follow the new scope.

It is important that if people have printed versions at their desks, then those versions are also altered or reprinted.

This applies to corrections, not new scope. New, additional scope should be stored in a location (electronically and in hard copy if necessary) that is known and accessible to all the project team.

It is important that any extra scope be regularly checked and that the project team is aware of what is and is not included in the scope (both original and new).

Tagged with: changes

Filed under: Client • Documentation • Scope