What Are Our Change Control Procedures Trying to Control?

Back in November, I wrote an article about the life cycle of a change request, and noted that fifteen of the forty-two processes documented in the PMBOK may produce change requests.  More recently, I’ve had occasion to ask: what are our integrated change control processes trying to control?  Because it’s obvious that some projects need to facilitate changes and some need to resist changes, based on the larger context of the organization and the goals of the project, in terms of the constraints under which the project was initiated.  In short, different projects need to optimize for different parameters.  So let’s consider some alternatives:

  • Optimizing for schedule – if a project has a drop-dead date that can’t be adjusted, then change control should facilitate changes that reduce risks associated with meeting that date, and resist changes that increase the risk of delivering late.  Note that such dates tend to be assigned by some external authority, for reasons that can’t be seriously challenged without also considering cancellation of the project.
  • Optimizing for cost – if a project has little or no tolerance for cost over-runs, then change control should facilitate changes that reduce risks associated with cost increases, and resist changes that increase the risk of cost increases.  This is especially true if the project is being performed under contract.
  • Optimizing for quality – if the deliverables of a project warrant placing a premium on quality, then change control should facilitate changes that reduce risks associated with errors, and resist changes that increase the risk of errors or defects.  If you’ve ever delayed a roll-out in order to remove critical defects from a software product, you know what this is about.
  • Optimizing for compliance – some projects have external requirements that are absolutely non-negotiable, and all other considerations are secondary.  Let’s face it: you can’t accept unnecessary risks with some projects, like payroll and other financial calculations, or avionics.
  • Optimizing for value – if a project is to be truly transformative for the receiving organization, then change control should facilitate changes that add value without unduly adding risks and resist changes that add more risk than is warranted by the value added.  When people extol the virtues of an Agile approach, this is usually  what they have in mind.

Note that I’ve expressed this in terms of managing risk; while you can always argue a business case for a specific change, integrated change management has to consider the totality of the project, and the overall risk profile.  We should resist adding the widget that breaks the camel’s back, and facilitate adding the one that improves the overall outcome.

There are probably other parameters for optimization.  If you can think of some, please add your comments!

This entry was posted in Scope Management and tagged , , , by Dave Gordon. Bookmark the permalink.

About Dave Gordon

Dave Gordon is a project manager with over twenty five years of experience in implementing human capital management and payroll systems, including SaaS solutions like Workday and premises-based ERP solutions like PeopleSoft and ADP Enterprise. He has an MS in IT with a concentration in project management, and a BS in Business. He also holds the project management professional (PMP) designation, as well as professional designations in human resources (GPHR and SPHR) and in benefits administration (CEBS). In addition to his articles and blog posts, he curates a weekly roundup of articles on project management, and he has authored or contributed to several books on project management.

2 thoughts on “What Are Our Change Control Procedures Trying to Control?

  1. Pingback: Carnival of Project Management #34a

  2. Pingback: Retrospective: My Favorite Posts of 2011 « The Practicing IT Project Manager

Comments are closed.