Change Management Process

By Nick Jenkins

The basis of change management is to have a clear process which everyone understands. It need not be bureaucratic or cumbersome but it should be applied universally and without fear of favour.

The basic elements of a change process are:

• What is under change control and what is excluded ?
• How are changes requested ?
• Who has the authority to approve or reject changes ?
• How are decisions upon approval or rejection are documented and disseminated ?
• How changes are implemented and their implementation recorded ?

The process should be widely understood and accepted and should be effective without being bureaucratic or prescriptive. It is important for the project team to be seen to be responsive to client needs and nothing can hurt this more than an overly-officious change control process. Change is inevitable in a project and while you need to control it you do not want to stifle it.

A typical process might be as minimal as the following:

1. Once a project document has been signed-off by stakeholders, a change to it requires a mandatory change request to be logged via email. The request will include the nature of the change, the reason for the change and an assessment of the urgency of the change.
2. A “change control board” consisting of the development manager, test lead and a product manager will assess the issue and approve or reject each request for change. Should more information be required a member of the change control board will be assigned to research the request and report back.
3. No change request should be outstanding for more than a week.
4. Important or urgent requests should be escalated through the nearest member of the change control board.
5. Each change which is accepted will be discussed at the weekly development meeting and a course of action decided by the group. Members of the development team will then be assigned to implement changes in their respective areas of responsibility.

If you have a flexible change request process team members can be encouraged to use it to seek additional information or clarification where they feel it would be useful to communicate issues to the whole project team.