Manage the priorities of your projects.

Consider them in relation to other projects, business lines in the organisation, geographic areas, and functional managers.

Tagged with: priorities

Filed under: Scope

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

Remember that for a project, quality means compliance with the scope and specifications. Doing what is required.

It does not mean you have to deliver a better product than is ordered, or that it has to have extra features that were not requested.

Tagged with: extra features • specifications

Filed under: Quality • Scope

Find out why a project was started.

Some reasons could be different to just business as usual, and these may affect the priority on time, cost, or quality

• Was it internal business reasons (business process improvement)?
• Is your organisation using the project as a demonstration of its capability? To show off and make itself known.
• Is the project a way to break into a new market (low or no profit may be expected because it will be used as a learning and development exercise).

Tagged with: demonstration • improvement • new market • priority • profit

Filed under: Cost • Quality • Scope • Time

For contracts longer than 12 months, you should have a clause to allow unknown technologies to be added. Particularly for high tech and IT projects.

Part way through a long contract, the industry best might have superseded some of the items specified in your contract. You need a way to change to these newer technologies. They may perform better, and at a lower cost.

If you don’t have a way to add these, you could be stuck trying to source a specified item that you know is outdated, cannot be supplied, and will be more expensive to maintain because no one supports it anymore. An addition clause will allow you to approach the client with a change/addition proposal that the client can comfortably approve. If no clause exists, they may not be able to allow a change or addition because of their internal organizational procedures.

Tagged with: addition • clause • technology

Filed under: Contract • Scope

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

It is the responsibility of the project manager to organise priorities for the team members.

You should provide direction on what is the most important task.

You should settle conflicts between activities.

Provide things like the network diagram and critical path of the project to clarify to team members what work is the most important.

The PM should also give their team direction on the requirements for time, cost, scope, and quality.

Tagged with: activities • conflict • critical path • direction • important tasks • network diagram • prioritise • priority

Filed under: Cost • Planning • Quality • Scope • Time

The project manager should be held accountable for the failure of a project.

If you are a program manager (manage project managers) you should hold your project managers accountable.

This sounds obvious, but often this accountability is only mentioned at the end of a failed project.

The program manager should require regular (weekly) reports on status and at least monthly financial and schedule reports (performance measurements).

It is more difficult to hold a project manager accountable if he/she was not involved in the project from the start (initiation / tendering), including scope planning, schedule, costs, objectives, etc.

If the project manager is not involved from the start, he/she may blame a failed project (over budget or over schedule) to a badly estimated / planned tender.

If the project manager is involved right from the start, with the proper support and authority given, it is reasonable to fire the project manager of a failed project (unless the PM can show causes outside of reasonable planning or control of a PM, such as natural disaster in an area not prone to them).

This must assume the project manager has had proper training, not just someone thrown into the role of PM without training.

It must also allow time for training a new project manager to your organization in the internal procedures, templates, systems, etc.

In initiating, if a project manager believes the project is being underfunded, the schedule is unrealistic, or the price is too low, they should say so, change it, and then sign the changed project plan. A project manager should not accept an unrealistic schedule (unless agreement is reached with management that the project will make a loss or similar (such as breaking into a new market).

Accountability could mean loss of status/title, moving to an assistant project management role, or possibly being fired.

Tagged with: accountability • accountable • project failure

Filed under: Human Resources • Planning • Scope • Training

Use a template for your work breakdown structure

Before starting on your WBS, check if your organization has a template for the WBS for similar types of projects. If no templates are available, get samples of WBS from previous projects in the organization to base yours on. While you do that, make it a template for your future projects.

Even better would be a project management system with a built in work breakdown structure building system.

Tagged with: system • template • WBS • work breakdown structure

Filed under: Documentation • Planning • 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

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 your company is not involved with construction (but just design or inspection), make sure the contract states that the construction contractor is responsible for site safety, not the “engineer” or your company.

There should also be clauses so your company is also indemnified.

The construction means and methods and related safety should be the responsibility of the construction contractor. This must be in writing in the contract.

Your company should be included as additional insured on the contractor’s general liability insurance.

Liability coverage should define who it specifies as being covered. If it covers the “engineer” your company must document and include that it includes your company as well.

Tagged with: indemnify • insurance • liability

Filed under: Construction • Contract • Contractors • Documentation • Risk • Safety • Scope

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

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

If a client representative asks or instructs you to do something on site (of any value or lasting effect) get it in writing before doing it.

For example, if the scope calls for a certain size concrete slab, but the client on site asks for it to be made larger, get it in writing before proceeding.

The person you get the written instruction from must be authorized to instruct you (not just a site operator or employee, it should be the project manager or his representative, who should be documented).

Tagged with: instructions

Filed under: Client • Communication • Documentation • Scope

Know the scope of your contract. Read it often. As a project manager it rules your role on that project.

Make sure you clarify the scope with all stakeholders to be sure you all understand it the same way. (Client, designers, drafters, managers, contractors, etc).

Tagged with: Contract • Scope • stakeholders

Filed under: Contract • Scope

Make strong, clear language in the contract documents so that your company’s duties are very clear.

This avoids problems later on in the project.
By making the duties clear (the scope) you avoid the problem of extra duties being added to the project that are not paid for.

A clear scope should be clear, and understood by both parties in the contract.

Tagged with: Contract • duties • Scope

Filed under: Contract • Scope

Be careful of scope creep.

Scope creep is where small additions or changes add up to contribute a larger and larger change in the scope of the project, often affecting delivery time and costs.

A few lessons I learnt:

• If scope is changed or more is asked for, submit variations before proceeding.

• If scope is changed you should ask for more money and more time.

• Always be aware that the time to completion may change with a changed scope.

• Even small additions add up to enough to increase the time to completion.

• Make sure to get written approval from the client before additions, variations, or scope change.

Tagged with: Cost • Scope • Time • variations

Filed under: Scope