jump to navigation

Ruminations on Change Control October 22, 2014

Posted by Edwin Ritter in Project Management.
Tags: , , , , ,
1 comment so far

It seems that no matter how much project experience you have, how talented your team is and how simple or complex a project is, there is one thing that will always be constant and that is change.

Previous posts of mine have dealt with setting up projects, closed loop feedback and the value of PMOs. Another basic process to define and get agreement on while setting up a project is how to handle change. The concept again applies to ITIL, Project Management and Lean Six Sigma areas. The level of process to use in review and accept/deny changes can be proportional to the complexity of the project. Simple projects don’t have many changes while complex projects can have multiple changes. This relates to the fact that we make decisions and plans at a point in time. As the project goes forward and we get smarter in the future, we may need to revise our plans and that can lead to change.

programming-change-management-processIn fact, during the planning phase, the process details should be documented to submit a change, review and assess the impact to the project. There are as many ways to deal with change as there are organizations. Having a consistent way to deal with and manage change(s) to a project is essential when change occurs. This chart illustrates the basic concepts as just one example of the process.  Using a common repository, change log or application to create the change record is a good practice also.

The PM works with the project team to provide an impact assessment and a recommendation on the change.  That decision should be reviewed with the sponsors. Each change should be assessed for impact to the schedule, resources and budget. Here are six steps to control change:

  1. Record / Classify – capture the request and indicate what area(s) of the project are affected
  2. Assess – review the impact to the cost, schedule and resources to implement
  3. Plan – update project documents as appropriate based on the assessment
  4. Build / Test – execute the change and determine effect to the rest of the project deliverables
  5. Implement – include as part of the project deliverables and release at go-live
  6. Close / Gain Acceptance – complete the documentation on the request and communicate with the team and stakeholders.

Using the process framework provides a way to control changes for a project and the rate at which changes are generated.  Here is where the process helps in that it provides a way to accept or deny changes. Completing an assessment of the change and updating plans result in data to support the resolution to the change request. Not all changes are created equally. Some can be rejected outright and from other requests, it is clear to see the benefits.

Last, during project wrap-up and lessons learned, the number of changes submitted and their resolution can provide some interesting insights. How many were submitted? Accepted? Did the changes requested indicate a gap with requirements? Was the project not planned properly? Was the design not fully thought out? Those questions and others can lead to animated discussions. The key is which ones to action and improve on going forward.

Of course, that could be a change request also. How do you manage  and control change? Does the process impact your project in a big way? What happens if you reject a change? Comments invited.