Get to know your client contact more personally, not just their project specific details.

Find out their interests, other projects they are working on etc.

Possibly send them useful information, news clippings, etc on things you know they are interested in.

A lot of business is built on relationships, and knowing how a client works and responds can be very helpful when managing their projects.

Tagged with: business • relationships

Filed under: Client • Communication • Marketing

Good communication is a key skill for a project manager.

Good design of the product is assumed by the client. The key to keeping things running smoothly and making the client happy is keeping them informed.
Give the client regular updates, even if there is nothing to tell them. Ask the client for feedback. Are they happy with the way the project is going, your communication with them, the deliverables, etc. If something is running late, tell the client and the reasons. Don’t assume they know it will be late or why it will be late. Often just telling them will satisfy them, instead of the client contacting you to say your deliverable is late.

Tagged with: feedback • key skill • project manager • regular updates • running late

Filed under: Client • Communication

Check the funding sources of your clients.

Especially local council clients who rely on funding that often changes.

Tagged with: council • funding • funds

Filed under: Client

Check and confirm geotechnical reports that are supplied to you in a contract.

The client may supply reports that are old or inaccurate.

Specify in the contract that you are relying on the accuracy of their reports. If that is not acceptable, budget for new testing and reports.

Tagged with: geotech • report

Filed under: Client • Contract • Testing

Eliminating unnecessary features in design will give the largest savings in a project.

If your client wants costs cut, look for the most costly features (in design cost and construction cost) that could be eliminated without significantly reducing the final required result of the project.

For example, a client wanted a set of equipment protected from potential flood levels by constructing it on the flat roof of an existing building. However, the rest of the existing plant was below that level so in the case of a flood would be out of operation anyway. To construct on the roof of the building would have taken significant extra structural support costing more than the equipment being installed. It was decided to install the equipment at ground level instead of raising it above the potential (rare) flood level, and installing a simple bypass system for use in case it failed. This saved more than double the price of replacing the equipment in the unlikely event of it being flooded.

Of course this may not be possible with features that are critical to operation, but if they are not critical, eliminating these features at the design stage (early in the project) can save a lot of money.

Tagged with: features • savings

Filed under: Client • Cost • Design • Scope

You must learn to say no to some requests from clients

If change requests from the client will make the design unsafe or unusable, you should refuse to change it. Otherwise you could still be sued as the designer for giving misleading information when your company is the expert (accepting a change could be deemed as approving it, even if you gave a warning that it would be unsafe or unusable).

Another instance to say no is if the client asks for changes that will increase the schedule but won’t approve the increased schedule. Get approval from the client for the extended schedule or cost before saying yes to the proposed change.

Tagged with: change • schedule

Filed under: Client • Contract • Cost • Design • Risk • Safety • Scope

Using the Word Float

It is a good idea to avoid using the word “float” in a schedule or cost report to a client.

Instead you could use phrases such as “Critical Evaluation of final commissioning items”, or something similar.

Using the word “float” usually leads to management or the client wanting it reduced.

Of course only use the alternative wording if it is a necessary float and the words reasonably describe the use.

Tagged with: cost report • float • schedule

Filed under: Client • Communication • Documentation • Planning

If a specification is older than 5 years, it is probably outdated or inaccurate.

If you are reusing specifications from old projects or tenders, make sure you check that the information in them is still current.

Sometimes a client will send you a specification that is from their files from previous projects. It can often be outdated information and needs to be checked that it matches the current standard or expectation.

For example, the electrical wiring might be specified to be a certain colour, yet new standards call for different colours. If you are supplying those specifications to a contractor, you would be responsible for specifying the correct colour; otherwise the contractor may install the wrong colour and ask for a variation to rectify it.

Tagged with: specification

Filed under: Client • Documentation

Even if there is nothing to report to the client, report regularly to a schedule.

This gives the client a current report for their internal systems and means they are not left wondering how the project is going.

It also gives them greater confidence in your abilities and your organisations processes.

Tagged with: processes • report

Filed under: Client • Communication

Make sure you know what the client really wants. You are working for them as a means to an end. Make sure you know what this end result is supposed to be.

Make sure you get their statement of this. A large scope document is often included, but it is important that you have an understanding of what is really wanted.

An example I have heard is: In building a palace, you might deliver great quality, great cost savings, and be ahead of schedule, but what the king really wants is something amazing to look at (more gold, more turrets etc).

Tagged with: end result

Filed under: Client • Communication • Scope

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