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
Software Quality Assurance Organization: Software Quality Assurance within the CMMi Framework
The Ideal PM Tool set
PM Hut; Implementing Change Control