Document all Changes, Variations, and Agreements

I believe you should document all changes, variations and agreements on your projects. You should put everything in writing.

Why do I believe this? From experience (as well as what the books and policies tell me).

I once joined a project in which every agreement, after the initial contract, between the client (us) and the contractors was verbal. The project manager would walk around the construction site and verbally instruct the contractor to do something (e.g. build that block retaining wall two blocks higher, or add some extra gravel to that access road to improve the drainage). These were all valid and necessary changes, but there was no record of what was agreed to, and no record of the instructions.

When it came to the end of the month and the contractors submitted their payment claims, the project manager and the contractor construction manager would have to sit down and discuss what had been agreed to and what was necessary or out of scope. This situation relied on the project manager and the construction manager having good memories, fortunately they both did and the project, surprisingly, was running smoothly.

As soon as I started as the assistant project manager, I started writing down, registering and emailing every agreement, instruction or scope change. When the project manager died while on holiday, I had to take over as the project manager. There were a lot of unrecorded changes and agreements from before I started on the project, and that caused a lot of work for me and problems for the project. The project had relied on a key person’s memory and availability.

If each of these changes had been done in writing, or confirmed in writing soon after being verbally agreed, there would not have been any issues. However, without that written record we had a lot of problems with disagreements, and a lot of extra costs and schedule delays.

Problem: Project Changes Are Not Being Documented

Many projects have too many things happening with no record of what has occurred, what has been agreed upon, or what the change is.

This can result in:

• Your projects have continuing disputes about what was agreed upon. 
• The scope is unclear, and everyone has a different understanding of the scope based on that first meeting. 
• Changes to the project keep happening and no one knows why. 
• Verbal agreements are occurring and different memories of those agreements are causing disputes.
• The client is refusing to pay for variations.
• Your projects go over budget.
• Your projects go over schedule

All of these and more are common problems in many projects, all caused by a lack of written records.

Solution: Make Written Records of Everything

Everything in your project should have a written record.

What should you put in writing in your project?

• Agreements with a client
• Agreements with a contractor
• Instructions to do something
• Instructions to not do something
• Changes in the scope
• Variations to the costs
• Changes to the design
• Changes in the schedule
• Arrivals of equipment or supplies on the project site
• Deliveries of material
• Completion of tasks
• Completion of milestones
• Issuing of designs, drawings and documents (i.e. a transmittal register)
• Receipt of transmittals (proof that a document, drawing or design was sent)

Put everything in writing. Everything!

If you or your team makes verbal agreements with contractors or the client (or other divisions of your company) and does not put them in writing, then there is no way to prove that the agreement occurred.

If you don’t put variations to the client in writing, they are very unlikely to approve payment for those variations.

If your design changes are not in writing (and on the drawings), you will be questioned why the design is different to the original scope.

If you don’t record that a task  is complete, how will anyone know it is definitely completed (and when and by whom).

If the project submits a deliverable or completes a milestone later than originally agreed, without written evidence of why it is over schedule, your client will not be happy.

You should document on the assumption that “if it is not in writing, it didn’t happen”.

Having knowledge kept in people’s heads only does not help the project. It only helps guarantee that a person is considered critical to the project, which they should not be.

The advantages of putting things in writing include:

• You and your company will be protected in the event of a disagreement or claim.
• It will clarify the intentions of the project and the change related actions.
• It will be easier to meet legal and quality assurance obligations.
• You will get approval for scope changes and cost and schedule variations much more easily.
• Reporting to your client and to your other stakeholders will be easier.
• Your projects will run more efficiently.
• Your project teams will know what is happening and why.
• The project teams will understand the project more clearly.
• Any project team member (including the project manager) could be replaced if they suddenly leave, without significant impact on the project.

What specific documentation should your projects be doing?

• Put all changes to the project scope in writing. Get that approved by the client and then update the scope documents.
• Document changes to the costs for the client, and get them approved.
• Document changes to the schedule to the client, and get that approved (or at least acknowledged).
• Get variation approvals in writing.
• Have written records of design changes and delays.
• Have written records of construction changes (and update construction schedules as well).
• Put your objections to external party schedules in writing (such as construction schedules that depend on the completion of your design)
• Have a change management system for changes, especially for design and construction changes (which can have a significant impact on cost or schedule).
• Keep a register to record all the above scope changes, cost variations, design changes, schedule changes etc. (either in a spreadsheet or a change management system).
• Keep a transmittal register, to record when documents, drawings, designs and other deliverables are sent to the client. Also keep a record of their acknowledgement of receipt of that transmittal. Ideally, transmittals of these key documents should be numbered, so as to avoid confusion and to help identify whether anything has been missed.
• Follow up verbal agreements or instructions with a written confirmation.
• If the client tells you something important verbally only, send them an email confirming your understanding or agreement (and write what was agreed to or instructed).
• Document your efforts to meet client goals (especially if those goals are more than the original scope).
• Get (or make) and distribute copies of meeting minutes to all attendees (and possibly with the client if relevant).

Even if your client or managers don’t agree with or don’t like the changes, you should still record those changes in writing and inform them (also in writing). It is better they know about it than have it as a surprise later (when the project is over budget or schedule).

A verbal update to the client or your manager is not enough. It should be preceded or followed up with a document or email summarising the verbal discussion. That way they (and you) have proof of what was said. However, a verbal discussion to follow up a document or email is usually very important, as the client may not get time to read that email for a while.

Task Records

In addition to all the above, something that I am passionate about is recording the status and completion of tasks. I think every project should do this, even small projects.

I believe your project should use a good task manager. Yes you will have a master schedule, project scope document and project management plan (and all the related records of changes and transmittals), but you should also track the smaller tasks that are necessary to complete that scope.

A good task manager will allow you to set and allocate tasks to meet each milestone or each main item in a work breakdown structure.

This is something that you and your team would use daily. In fact they should have it open nearly all the time, and tick off tasks as they complete them.

I actually prefer people to not just tick off a task as complete, but to also leave a comment against the task to confirm what was complete, issues, where the document is stored etc (if the system doesn’t record that automatically).

A good task manager should allow or include:

• Task name
• Sub tasks
• Lists within the tasks (i.e. for steps or names of people contacted etc)
• Linked tasks (predecessors or dependent tasks)
• Allocation of one or more names to complete the task.
• Due dates
• Links to related documents or tasks
• An automated record of when any of the above was changed (date, time and by whom)
• Labelling of importance (e.g. high, medium, low) and category (e.g. design, construction, planning)

Lesson: Put Every Project Related Thing in Writing

Projects are complicated. Lots of agreements and changes are constantly made, these should be managed properly.

Document everything in your projects. Every change, variation, agreement, completion and delivery. If it is done verbally, put it in writing and send that to the person involved. 

If something in your project is not recorded in writing, then it should be assumed that it didn’t happen.

Putting everything in writing allows the project team to find relevant project information and decisions without having to ask around the team for what was agreed to. It will save time and decrease your risk of disputes.

If you don’t have everything in writing, you substantially increase your risks of running over budget, over schedule, and not completing the project scope properly. It will also probably lead to much more work for you and your team.