Early in my career, when I was an individual contributor on projects, I viewed meetings – including change control meetings – as an “interruption of” real work. Let me be clear, I WAS WRONG. As I moved into management of progressively larger projects, the need for a formalized way to deal with and document change requests became evident. Moreover, I became the one calling those meetings!
Is change after requirements are agreed upon inevitable?
Yes. Give me a user interface and I will find you several users who want changes made. No matter how conscientiously you gather user requirements during the early phases of a project; changes will be requested once users get their hands on the software during alpha or beta testing. I love that famous quote from Benjamin Franklin where he said, “In this world nothing can be said to be certain, except death and taxes.” I have a saying that I modified from Franklin’s – “There are only three things in life that are certain: death, taxes, and change.”
Partially this is human nature. A user envisioning a system that exists only on paper does not realize they will want to change font colors or have their spelling checked. New software has bugs that show up only during alpha and beta testing, when clever users finally get their hands on the software. Alternatively, the environment in which the software will operate changes, the customer adds data sources or new user groups.
As project manager, operations manager, or even VP, you must consider each change request in terms of its impact on cost, schedule, planned infrastructure, integration and input/output/processing modules. Now, just because a change is requested, does not mean you can or have to make the change, but you must consider it and document that consideration and the reasons the change request is rejected.
Components of an Effective Change Management Process
The PMBOK in sections 4.5 and 5.5 sees change management as part of an over-all integration of best practice processes that includes change requests, approval or rejection processes and management that includes deliverables organizational process assets, project documents and the project management plan. Change requests can include corrective action, preventive action and defect repairs.
A Change Control Board (CCB) reviews all requests and approves, delays or rejects them. The CCB should include key project staff, representatives of user groups and customers. It may also include software QA representatives, consultants or someone from the PMO.
All change requests should be identified by unique number and include information on the problem or desired change. A formal system to track change requests status, document costs and benefits, and provide feedback to stakeholders should be in place. The entire proceeding of the CCB meetings, the change requests and outcome actions become part of the project record.
Some Good News
Many changes you are asked to make improve the quality and functionality of your software. Useful enhancements that cannot readily be fit into schedules and budgets can form the basis for future contracts. The effort and documentation of the CCB protects your company if later problems arise with the customer’s satisfaction and payment.
Best Practice Tip
Not every project or organization is going to need the same type of change management or level or rigor. The PMBOK outlines what functions and processes make up controlling scope and managing change – but not how to apply it to your specific needs. If you are implementing a new project or establishing your organization’s change process and methodology, then get an experienced and trained PM or consultant to assist in applying this critical process area to your project or group. A few well spent hours by a seasoned PM will pay off in the long run for your success in managing change.
Resources for More Information:
Project Smart; Using Change Management and Change Control Within a Project; Dave Litten; 2009
http://www.projectsmart.co.uk/using-change-management-and-change-control-within-a-project.html
Software Quality Assurance Organization: Software Quality Assurance within the CMMi Framework
http://www.software-quality-assurance.org/cmmi-requirements-management.html#sp13
The Ideal PM Tool set
http://herdingcats.typepad.com/my_weblog/2009/12/the-ideal-pm-tool-set.html
PM Hut; Implementing Change Control
http://www.pmhut.com/project-management-process-phase-3-implementing-change-control
Fear No Project Blog - Focusing on the Management Side of Projects 
April 23, 2011 at 9:50 am
[…] Using Change Controlhttp://www.pmhut.com/project-management-process-phase-Three-using-change-controlDocument change management – Google Web-log Search by pwilson Obama moves to control all land in Utah! KSL.com FAIR USE NOTICE http://www.ksl.com Thisvideo […]
September 27, 2011 at 3:56 pm
[…] for High Performance Companies Book PDFBaldrige.comManaging High Performance GPU ClustersPMBOK – The Case for Change Management if (top!=self) { window.location = […]
November 18, 2011 at 6:47 pm
During Change when people primarily think in terms of just coping with the situation. They respond to change with a “victim mentality.” You see a lot of helplessness and dependency behavior. The general outlook is pessimistic. Too much valuable energy gets invested in resistance, anger, blamefulness, or fear. People focus on problems instead of solutions. They talk about how hard things are, and why they can’t make it work. Usually the mindset at level one is that maybe change will pass. People wait and hope for a so-called “return to normal.”