Change Management is one of those recurring topics that show up in many ‘discussion threads’ in various forums wherever Project Management is practiced. This is probably one of those knowledge areas that everyone agrees is important and necessary. However, how it is actually implemented, how it is used and the end results that you achieve with it – don’t always align well. Watching change management at work within a project or program can be akin to going out to eat. You can satisfy your goal of ‘nourishment’ by popping a freezer meal into the microwave, or going out to eat at your favorite restaurant. One satisfies the need for calories or nourishment, the other generally satisfies the ‘intent and purpose’ and is much more enjoyable.
In the Fourth Edition of the PMBOK®, there is a significant amount of time and effort put into defining the processes defined so that one can ‘Monitor and Control Project Work’, aligned under the Project Integration Management knowledge area. Change Management implemented correctly can be of great benefit to the successful completion of your project. Done incorrectly, it can add significantly to cost overrun, schedule overrun and a significant lack of ‘control’ on your project. This of course leads us to the question:
What are the basics needed, to ensure that Change Management is implemented effectively?
As defined by the PMBOK®, the process to ‘Perform Integrated Change Control’ is defined as follows.
[1]“Perform Integrated Change Control is the process of reviewing all change requests, approving changes and managing changes to the deliverables, organizational process assets, project documents and the project management plan. The Perform Integrated Change Control process is conducted from project inception through completion. The project management plan, the project scope statement, and other deliverables are maintained by carefully and continuously managing changes, either by rejecting changes or by approving changes thereby assuring that only approved changes are incorporated into a revised baseline.”
The definition above, has a phrase which is underlined what is considered by many to be the overall key to successfully managing change. Whether your process approves few change requests, or simply acts as a rubber stamp to anything that comes along, it is critically important that several key items be addressed fully, within the Change Request that is submitted. Although Change Requests can be very thorough and detailed, there are key items that should always be included.
- Description of the Change and the person/department/group that requested it
- The reason for the Change
- What is the deliverable(s) that are affected by the Change Request
- What is the impact, if the change is NOT approved?
- What is the cost involved in granting the change?
- What is the schedule impact, in granting the change?
- What is the Quality or Functionality impact (Scope), in granting this change?
While this list could and will be debated by many as not including other important items (and by some to be too detailed), the primary culprits that are found to be missing on many change requests, are the last three bullets – Time, Cost and Scope. We want to state right here, that if you are involved in any contract related project, Government/DOD or similar project, most all of these items will likely be there. If not, you are going to be done before you start. However, experience shows that many, many times in traditional IT related projects, the Time, Cost and Quality are simply not addressed properly so that a proper decision can be made. Even if all of these items have been addressed properly in the Change Request, the next steps are also imperative for success.
The makeup, willingness and process that the Change Control Board has – can be a significant factor in the overall success or failure of your project endeavor. Let’s talk about several scenarios, and what can happen during the ‘Change Management Process’.
In our first scenario, the Change Board meets on a regular basis and reviews in detail all of the pending or open change requests. They ensure that the Project Executive is present. Change requests have been sent out in advance for review, and the board meets at its appointed time. This Change Board only deals with high level or major changes. It does not deal with minor changes, that have been delegated to the Project and/or Program Manager associated with the project. Most changes are routinely sent back for additional information or clarification, but ultimately they are approved. In general, most all of the change requests come from the ‘performing organization’ and not from the client/customer involved.
In our second scenario, the Change Board does not meet at all. They deal with each of the Change Requests in a ‘one off’ basis, via email. Occasionally, there are ‘reply all or broadcast’ messages that are sent with additional clarification or questions. Most of the Change Requests are generated by the Client/Customer, and contain no information on Cost, Schedule or Quality impacts. Virtually all of the Changes are approved (by the Customer) for implementation before being sent out.
In our last scenario, the Project in question has a defined process that they strictly follow. This process is approved by and supported directly by the Change Management Board ‘Chairman’, and its members. There is ’set criteria’ that has been established on when a CR should or should not be considered and submitted to the Change Control Board for approval, rather than being approved at the project level. All change requests, when submitted, must be complete or they are returned to the Originator – no exceptions. There is an agenda published, along with all CR’s that are being considered, in advance of the regularly scheduled meeting to all participants. If either the originator or the PM are not present at the meeting, the CR is ‘postponed’ for one week. All of the ‘key items’ are reviewed, the CR is discussed, and a vote is taken from the voting members of the Change Management Board. A CR will only be considered in a maximum of two meetings, before being marked as not approved and returned to the originator and PM for re-consideration.
The three scenarios above are all actual scenarios that have been experienced directly within the last five years. They delivered mixed results, sometimes catastrophic in nature. In general, here is what transpired.
Scenario 1 yielded ‘acceptable results’ but for one major item. Change requests that were submitted and reviewed by the Change Management Board were only ‘major’ ones. The project team and ‘performing organization’ were given great leeway in making decisions on other changes, and these changes followed no formal change process. In short, Change Control was run very much under ‘Cowboy Project Management’ practices. Dig in your spurs and hold on! In general, as long as there still appeared to be money left, everything else was okay.
Scenario 2 yielded satisfactory results for the Client/Customer, but catastrophic results for the ‘performing organization’. It is a scenario that many attribute to ‘the Customer is always right’ syndrome. While the customer was very satisfied that they didn’t have to participate in another meeting, and they were getting what they wanted, the performing organization was bleeding to death on the cost and schedule front. In short, this project was on the ‘Corporate Watch List’ for performance, and was dramatically over budget and met few of its ‘time projections’.
Scenario 3 yielded excellent results (hard not to miss this one), but did have a very rocky start. The Change Process that the project started with was an ineffective process that missed on several counts. When it was changed, many in both the ‘performing organization’ and also the ‘client/customer organizations’ resisted the need for a more robust process. Once the new process was put in place, and the Change Management Chairman took charge and followed the process, everyone knew what to expect and the overall control was greatly improved and the results were dramatic. CR’s were received in a timely manner, and in most cases were complete and ready for review. The weekly meeting was organized; efficient and made decisions based upon the facts and merits of the requests. It was a very manageable process, that allowed the team to control Cost, Schedule and Quality, along with being ‘Practical’ in nature.
[1] ©Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Fourth Edition
Change Management is one of those recurring topics that show up in many ‘discussion threads’ in various forums wherever Project Management is practiced. This is probably one of those knowledge areas that everyone agrees is important and necessary. However, how it is actually implemented, how it is used and the end results that you achieve with it – don’t always align well. Watching change management at work within a project or program can be akin to going out to eat. You can satisfy your goal of ‘nourishment’ by popping a freezer meal into the microwave, or going out to eat at your favorite restaurant. One satisfies the need for calories or nourishment, the other generally satisfies the ‘intent and purpose’ and is much more enjoyable.
In the Fourth Edition of the PMBOK®, there is a significant amount of time and effort put into defining the processes defined so that one can ‘Monitor and Control Project Work’, aligned under the Project Integration Management knowledge area. Change Management implemented correctly can be of great benefit to the successful completion of your project. Done incorrectly, it can add significantly to cost overrun, schedule overrun and a significant lack of ‘control’ on your project. This of course leads us to the question:
What are the basics needed, to ensure that Change Management is implemented effectively?
As defined by the PMBOK®, the process to ‘Perform Integrated Change Control’ is defined as follows.
[1]“Perform Integrated Change Control is the process of reviewing all change requests, approving changes and managing changes to the deliverables, organizational process assets, project documents and the project management plan. The Perform Integrated Change Control process is conducted from project inception through completion. The project management plan, the project scope statement, and other deliverables are maintained by carefully and continuously managing changes, either by rejecting changes or by approving changes thereby assuring that only approved changes are incorporated into a revised baseline.“
The definition above, has a phrase which is underlined what is considered by many to be the overall key to successfully managing change. Whether your process approves few change requests, or simply acts as a rubber stamp to anything that comes along, it is critically important that several key items be addressed fully, within the Change Request that is submitted. Although Change Requests can be very thorough and detailed, there are key items that should always be included.
· Description of the Change and the person/department/group that requested it
· The reason for the Change
· What is the deliverable(s) that are affected by the Change Request
· What is the impact, if the change is NOT approved?
· What is the cost involved in granting the change?
· What is the schedule impact, in granting the change?
· What is the Quality or Functionality impact (Scope), in granting this change?
While this list could and will be debated by many as not including other important items (and by some to be too detailed), the primary culprits that are found to be missing on many change requests, are the last three bullets – Time, Cost and Scope. We want to state right here, that if you are involved in any contract related project, Government/DOD or similar project, most all of these items will likely be there. If not, you are going to be done before you start. However, experience shows that many, many times in traditional IT related projects, the Time, Cost and Quality are simply not addressed properly so that a proper decision can be made. Even if all of these items have been addressed properly in the Change Request, the next steps are also imperative for success.
The makeup, willingness and process that the Change Control Board has – can be a significant factor in the overall success or failure of your project endeavor. Let’s talk about several scenarios, and what can happen during the ‘Change Management Process’.
In our first scenario, the Change Board meets on a regular basis and reviews in detail all of the pending or open change requests. They ensure that the Change Originator, Project Manager and any other key participants affected by this change request are also present. Change requests have been sent out in advance for review, and the board meets at its appointed time. This Change Board only deals with high level or major changes. It does not deal with minor changes, that have been delegated to the Project and/or Program Manager associated with the project. Most changes are routinely sent back for additional information or clarification, but ultimately they are approved. In general, most all of the change requests come from the ‘performing organization’ and not from the client/customer involved.
In our second scenario, the Change Board does not meet at all. They deal with each of the Change Requests in a ‘one off’ basis, via email. Occasionally, there are ‘reply all or broadcast’ messages that are sent with additional clarification or questions. Most of the Change Requests are generated by the Client/Customer, and contain no information on Cost, Schedule or Quality impacts. Virtually all of the Changes are approved (by the Customer) for implementation before being sent out.
In our last scenario, the Project in question has a defined process that they strictly follow. This process is approved by and supported directly by the Change Management Board ‘Chairman’, and its members. There is ’set criteria’ that has been established on when a CR should or should not be considered and submitted to the Change Control Board for approval, rather than being approved at the project level. All change requests, when submitted, must be complete or they are returned to the Originator – no exceptions. There is an agenda published, along with all CR’s that are being considered, in advance of the regularly scheduled meeting to all participants. If either the originator or the PM are not present at the meeting, the CR is ‘postponed’ for one week. All of the ‘key items’ are reviewed, the CR is discussed, and a vote is taken from the voting members of the Change Management Board. A CR will only be considered in a maximum of two meetings, before being marked as not approved and returned to the originator and PM for re-consideration.
The three scenarios above are all actual scenarios that have been experienced directly within the last five years. They delivered mixed results, sometimes catastrophic in nature. In general, here is what transpired.
Scenario 1 yielded ‘acceptable results’ but for one major item. Change requests that were submitted and reviewed by the Change Management Board were only ‘major’ ones. The project team and ‘performing organization’ were given great leeway in making decisions on other changes, and these changes followed no formal change process. In short, Change Control was run very much under ‘Cowboy Project Management’ practices. Dig in your spurs and hold on! In general, as long as there still appeared to be money left, everything else was okay.
Scenario 2 yielded satisfactory results for the Client/Customer, but catastrophic results for ‘performing organization’. It is a scenario that many attribute to ‘the Customer is always right’ syndrome. While the customer was very satisfied that they didn’t have to participate in another meeting, and they were getting what they wanted, the performing organization was bleeding to death on the cost and schedule front. In short, this project was on the ‘Corporate Watch List’ for performance, and was dramatically over budget and met few of its ‘time projections’.
Scenario 3 yielded excellent results (hard not to miss this one), but did have a very rocky start. The Change Process that the project started with was an ineffective process that missed on several counts. When it was changed, many in both the ‘performing organization’ and also the ‘client/customer organizations’ resisted the need for a more robust process. Once the new process was put in place, and the Change Management Chairman took charge and followed the process, everyone knew what to expect and the overall control was greatly improved and the results were dramatic. CR’s were received in a timely manner, and in most cases were complete and ready for review. The weekly meeting was organized; efficient and made decisions based upon the facts and merits of the requests. It was a very manageable process, that allowed the team to control Cost, Schedule and Quality, along with being ‘Practical’ in nature.
[1] ©Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Fourth Edition
{ 7 comments… read them below or add one }
How does defect repair fit into these scenarios? Do defects go through the same Change Control process as functional change requests? Does it matter at what point & by whom the defect is discovered?
Ray,
If defects are found during testing or implementation, and the defect points to a need for a ‘change in design or requirements’ – then it ‘could’ go through Change Control. However, it’s been my experience that most defects are defects against the defined requirements, and therefore handled through the Defect Management process that governs the ‘build and testing’.
great article – thank you for writing it.
In my world – smaller org – we manage change via a hybrid scenario 1. Meaning that, yeas we follow (to an extent) standard PMBOK practices of vetting each major change via the CMB, however, we empower our dev and project team to implement minor changes (as needed) w/out the involvement of the CMB. This has helped us in many ways, most significantly, it enabled the faster deployment for the project/product.
The single biggest requirement needed for us to operate in this environment was the increased domain/product knowledge of the dev and project team.
Empowering the dev and proj team is only possible due to our efforts (early on – as a part of the hiring process) in training/transfer domain and product knowledge onto each individual. This domain knowledge (along with ongoing training) enables us to empower the team to own/implement small changes throughout the project cycle (that could slow a project down). Change management can really be a great friend – as long as the process you’re following works in delivering the results needed.
Best,
Robert
Change Management is another of those “What does it mean?” terms. I have seen three uses:
1) Change Management is controlling the changes which the project will inflict on people, the processes and procedures they use to do their job, and the way they do business. A good change management plan will include handling of the AS-IS’s and TO-BE’s, honest communication of all info needed by the affected people, a good training plan, providing the extra support which will be necessary for the transition, etc. Lack of good Change Management can be extremely expensive either because people do not understand the new way of handling their job, or because they do not want to change how they do their jobs. Lack of Change Management results in the new way of doing things not meeting expectations.
2) Scope Management is sometimes called Change Management, and refers to changes of project scope. These frequently will result from a change to the requirements. A Scope Management Plan and a Scope Management Committee will handle this on any properly managed project. Lack of Scope Management results in ‘Scope Creep’ which means the PM failed to use good Scope Management techniques.
3) Configuration Management in Information Technology projects is sometimes called Change Management. This is part of version control for computer programs. It is very similar to configuration management of engineering drawings. Have you ever worked long and hard on something, and then discovered you were working on the wrong version?
What are the basics needed, to ensure that Change Management is implemented effectively? It is as easy as 1-2-3.
1) Start with a good Change Management Plan.
2) Follow it.
3) Be pleasantly surprised at the successful result!!!
There probably are a few other things also called Change Management by some PMs.
The “goal” of any project management activity must be the survival and prosperity of the hand that feeds us. It may be that we are dealing directly with that hand or only indirectly through a value chain. Nevertheless, if the end user’s needs are changing, aren’t they always, then we must be prepared to respond to those changing needs as quickly as possible. So, our change control process, however it may otherwise be structured, must include the voice of the real customer. For longer running projects, this will require an on-going market research effort. Ultimately, it does little good to run a series of “successful” projects for an employer who is going bankrupt. Ask the project managers at General Motors.
Posted by Edward Fern, MSTM, PMP
It is interesting, so many things can be meant by “change management”. When I looked at the attached article, the focus is on change requests and how to manage them. I would offer that there is also an important consideration around how the entire project will change the work environment and thinking through how to manage the large scale change. This too satisfies the “intent and purpose” vs just the basic requirements. Like what you have suggested for Change Requests, a process and approach to broad change management increases your likelihood of success.
An interesting point is made here on the relationship between PM and Change Management programmes where the focus of the later is often different from traditional project management of (say) hardware projects, I guess this is because it is clearer to have programmes and schedules to monitor actual design, procurement, delivery, installation and operational activities whereas the organization transition by change programmes is more subtle and maybe less easy to monitor – or at least see. This is not to say that there is no role for good project management techniques in managing change but in reply to John’s main question my expereince is that four key factors are essential for successful change; these being:
1. Selection of the right change strategy to suit the business change required, its culture and its operating environment.
2. A clear and realistic programme which suffiient preparatory time prior to implementing planned changes.
3. Senior level support with a visible commitment to the programme
and finally
4. Regular communications on what is planned, why , how it is to be inplemeted, the progress made and benefits that this will provide.