Change Management

The type of change management that I want to discuss here is change management in projects. Many times change management can mean a more overall and strategic or business focused change.

Indeed, the APM Body of Knowledge (BoK) concentrates on change delivering a business benefit. In other words, a project is by definition a change.

I also want to avoid the people side of change management, I think that that is the focus of a future blog.

What I want to do is provide some change management techniques for managing the inevitable change requests in projects.

Change in Traditional v Agile Project Management

It is true to say that traditional project management develops a plan that is then followed. This works well for projects that are well defined at the start. Change may be seen as an indication of poor planning, and change is often resisted.

Agile project management actually welcomes change. In agile, the requirements are stated before each sprint, and often change. A change is an indication that the customer wants something different. This means of more benefit, and that can only improve the project.

Project Planning and Baselines

Firstly the project has to be planned, scheduled and baselined. This is the plan that is to be followed, and the plan that will be disrupted by any proposed changes.

Project Monitoring

I have previously written about formal project monitoring, informal project monitoring and project meetings.

It is at these events that a change proposal is often raised. Without proper monitoring change will not be identified early enough to act in a correct manner.

Managing Project Changes

Once a change is identified, it should be processed in the same manner, no matter who (the chairman or the apprentice) raised it. It is a good idea to call them a ‘Change Request’ to remove any preconceived ideas that the change will inevitably be accepted.

  1. Document the Change Request: What is the change? What is the impact on the project, Time, Cost, Quality, Resources, Risks, Stakeholders? Ins ome cases the proposed change will disappear as it becomes too much work for the proposer.
  2. Assess the Change Request: Convene a meeting of the required stakeholders to assess the information supplied.
  3. Approve or Reject the Change Request: Make a decision on the proposed change. Is it to be accepted or rejected?
  4. Communicate the Decision: Communicate the decision made on the change request. Update plans and inform stakeholders.

The number of change requests (accepted and rejected) is also very useful information at a post project review.

Summary

I wrote about the effect of a tight change control system a few years ago. If change is difficult to implement, it may lead to people delaying or being vague about the actual requirements. A balance has to made between creating an accurate plan, and accepting inevitable changes.

Change is inevitable. Agile project management welcomes change, whilst traditional project management needs to be able to deal with change requests in an orderly and efficient manner.


Posted On: 9th March 2020

Join the conversation