If you have control of the system at the start of a project, make sure the project (or even at the program level, project office level, or company level) uses a document and accounting system that can record and output everything.

This would include costs, labour, forecasts, statistics, billing, budget, expenses, changes etc.

It should be able to output things like:

• Weekly reports.
• Monthly cost summary
• Invoices
• Labour costs for a period
• Expense breakdowns
• Cost to date
• Variance
• Total cost at completion

This should all be available from one package or a number of modules that are automatically linked together. You do not want to have multiple spreadsheets that people record things in that are not linked. The result should be a significant reduction in paperwork.

Certain inputs could only be allowed by certain people (by log in), such as:

• Accounts (accountant)
• Billing
• Labour (site manager)
• Design hours (design manager)

Individual hours by each person could be input (linked) from time sheets. All staff/employees should have adequate training so that the system is used properly

To start with, I recommend looking at the list of project management software at Wikipedia.

Tagged with: accounting • budget • changes • expenses • forecast • labour • statistics • system

Filed under: Cost • Documentation • Planning

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

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