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

Have a single decision maker as the main point of contact (both on your side and on the client side).

If you have multiple points of contact for your project, you, as the project manager, will not be able to control the flow of information properly.

If your client wants to make a change, clarify something, etc, they should have one specific person to communicate with in your organisation. If it is a small project where the project manager has control of all the areas, the contact should be the project manager. If a larger project with design managers, construction managers etc, you could have communication segmented, but each of these areas should only have one decision maker who responds to the client.

On the other side, make sure you have just one person who you contact for all enquiries, clarification etc at the client organisation (their project manager for the project). Communication could then be directed from them to others, but you need key decisions processed (and essentially made or authorized) through that one person.

Without this being done, you could experience decisions being reversed because the information didn’t come from the authorized person.

It is also a good idea to have these “authorized” people to be listed (by title at least, preferably also by name) in the contract. If a direction comes from the client from someone other than the authorized person, a copy of that direction (order) should be sent to the official person for them to authorize.

A single decision make and point of contact saves the backwards and forwards of communication.

Tagged with: authorized • Communication • contact • decisions

Filed under: Communication

Check the standards you are supposed to adhere to in your project for the pipes.

Remember that imported equipment might come with different flange drilling than what your pipe flanges have.

There are a number of different flange and pipe standards, make sure you allow for this in the designs. Most standards (such as ANSI, BS, AS, PN etc) are not interchangeable.

The details you give your design team need to match the right standard. You could be ordering a pump with a AS2129 Table D flange, but your designers might assume the project is using a British standard, or ISO standard because other equipment is listed as matching those specs.

It is easy to overlook this. In fact if you aren’t careful you will only realise when your installation team calls to tell you that the pumps and pipes don’t match. Then you waste time and money working out a solution.

While on this topic, make sure you understand the differences between the standards dimensions and also the faces of the flanges they describe (e.g. flat faces, raised face, etc).

Most suppliers of pipes will have a page showing sizes, flanges, drilling, and comparisons in their catalogue.

Early planning and checking can save a lot of time later in the project.

Tagged with: Design • drilling • flange • pipe • standard

Filed under: Design

An important lesson I have learned if you are on the design side of the project.

Make the specifications clear.

Unclear or contradictory specifications just end up leading to having to continually answer request for clarifications, and can also lead to contractors making extra claims for variations because  of different interpretations of the specs.

If you refer to standards, make sure to check that the standard you refer to is the current/newest one. If you specify an old standard (easy to do if you are using your organisations standard specifications) you could be specifying that the contractor do the project in a way that does not meet new requirements. This may mean they will claim for extra costs to cover changes to meet the newest standards or that the resultant product doesn’t perform to expected requirements.

Tagged with: specification • specs • standard

Filed under: Documentation

The title says it all.

Document all communication with your client (and with suppliers and contractors).

• Even with friendly or familiar clients.

• Client’s project manager may change, so verbal agreements won’t be recognised.

• Possibly use an incoming and outgoing correspondence log.

Tagged with: Communication • Documentation

Filed under: Documentation

Document all changes, variations, agreements etc. If it is done verbally, put it in writing and send to the person involved. Make sure the client / stakeholder is sent this documentation.

• This will protect yourself and your company in the event of disagreement or a claim.
• It will clarify intentions.
• Important for QA documentation, and for scope adherence, and legal.
• Get approval in writing for changes or variations.
• Document on the assumption that “if it’s not in writing, it didn’t happen”.
• At least prepare a written confirmation of verbal instructions and copy to the client.
• Document your efforts to meet client goals.
• Get and distribute copies of minutes of meetings with the client.

Tagged with: changes • Documentation

Filed under: Documentation

Welcome to My Project Management Lessons.

Here I will share with you some of the lessons I have learned in my time working in project management. It will be a collection of notes I have made in the past and will continue to include lessons as I learn them.

A bit of background.

I am qualified as a mechanical engineer and have since moved in to the project management field.

My project experience to date has been in the water industry (mostly municipal waste water design and construct projects) and more recently in rail (design management).

The purpose of this blog is to share some of the problems I have encountered, lessons I have learned, and solutions I have found. Some of these are from projects I have been involved in. Some have been in projects done by colleagues, and some have been in projects I have observed.

Not all the lessons I mention here will relate directly to every project, but my hope is that some of them will help you with some of your projects.

Filed under: Principal Posts