Changes to a project can be one of the big issues when managing a project, they can affect your planning, cause confusion and serious delays to projects. Changes made at the beginning of a project usually have less of an impact than when most of the design is complete.

There needs to be a system for people within the team, stakeholders or anyone else to submit changes to the project. This process needs to be documented and everyone should be aware of the steps to take if they have a feature, they feel is essential to the project.

The way changes management is handled usually depends on the size of the project.

Small Project

This is the usual approach, which can work well when you have a small project, and you working in an agile way. However the volume and scope of the changes may mean that the project is delayed and the team become disillusioned. The usual process is:

• A change comes in from client usually by email
• Project manager simply updates the project plan
• The new plan is distributed to the project team

Large Project

Most large projects implement design freeze after the planning process, so all changes have to go through formal change management. This is great as each change is assessed on it merits and whether it materially affects the business case. The downside to this is that better solutions and fast feedback is very difficult to integrate. Formal change management usually follows:

• Originator of the change fills in a change request form
• The change request is entered into the change log and issued an id
• The project manager assess the change for impact and documents their recommendations
• The project board review the change and make a decision
• The board’s decision is entered onto the change log
• If the change was rejected the originator is informed with the decision and reasons
• If the change is accepted then the project plan is updated
• Change is implemented, documented and change log updated

A Happy Medium?

Our approach sits in between the two, we do have a formal change management process but it is less formal and only happens after the design phase which is quite collaborative and agile. During the design phase we work with fast iterations with lots of client feedback. Then once the system has been designed, planned and signed off, we have design freeze. If a change is subsequently requested:

• All changes are placed in a Google doc that everyone can add to
• Each change is then assessed by someone in the project team and it is placed into:
  • To change
  • Out of scope
  • Phase 2
  • Bug
• When all the changes for the iteration have been added, we sign off and date the iteration and make the changes in the to change and bugs columns
• We allow clients to have three rounds of changes/ iterations

The key to the success of any of these methods is making sure that EVERYONE understands the process and that there is someone who enforces the process. It is also very important to get sign off at the key decision points to document that everyone was in agreement.