Change control is an important process in the project life cycle. And change requests should come about in a formal manner. If you haven't done a good job establishing a change control process and communicating that process to the stakeholders and team members, you'll likely end up with e-mail going directly to project team members asking for changes or stakeholders grabbing you in the hallway and asking for something "they must have" to consider the project successful.
Tip:Here's your first rule regarding change: Always require change requests in writing.
No one has a perfect memory. Undocumented changes can cause big conflicts. If you don't remember the change the way it was described, or the stakeholders thought they said what they meant but that's not what the project team implements, you'll have even more setbacks and changes to deal with than the original requested change. Undocumented changes could end up affecting the project schedule or the product quality or costing the organization money or loss of business, so always get change requests in writing.
Note:Change control procedures are normally documented during the Planning process and implemented during the Executing and Controlling processes. For the sake of clarity, I've included the change management process and change management plan in this chapter. I think it will be easier for you to see the logical progression of the change process if it's described all in one place.
Forming a Change Management Plan
A change management planhelps you accomplish three things. First, it helps you understand what causes change to come about; we talked about that in the opening section. Second, a change management plan helps you understand when or why a change is needed, and third, it helps you manage the change by establishing procedures for change.
change management plan
The plan that describes how change requests are submitted, reviewed, and approved or denied.
Good change management plans should describe such processes as submitting change requests, managing change requests, deciding who will review the change requests, and determining how they're approved. It's a good idea to provide users with forms for submitting change requests, because this will ensure that you capture all the information you need to make a decision regarding the change. (I'll give you an example change request template later in this chapter.)
Your organization may already have a change management process in place. If so, use the existing policies and modify them—with permission, of course—if you need a process that is specific to your project.
The following list shows most of the elements you should include in your change management plan. You could modify these for use as headings in the change management plan and then fill in the information according to your project needs or organizational policies.
Also include a section that describes how the change control processes work. This should outline the following processes:
The change management plan should describe the level of authority needed to approve a change, as noted in the former list. Some change requests can be approved by the project manager, depending on the nature of the change. Others need to go before a review committee, often called a change control board, that reviews and approves all changes outside the project manager's authority.
change control board
A group of individuals including the project manager and key stakeholders responsible for reviewing, approving, and denying change requests.
Note:Here is rule number two regarding change: All change requests must follow the change management process. They should be submitted according to the change management plan, approved or denied by the appropriate level of authority, and signed off. Changes that are not submitted according to the rules of the process are automatically denied.
It's important that stakeholders and team members follow the established change management process. Undocumented changes are also known as scope creep. As we've previously discussed, scope creep can get out of hand quickly, escalate the costs of the project, lengthen the project schedule, or distort the quality of the product. All of these things add up to an unsuccessful project. Projects that are unsuccessful because the project manager failed to implement processes and project plans foretell an unsuccessful project management career, so do everything you can to make sure these processes are followed.
The change management plan should be distributed to all key stakeholders, project team members, customers, vendors, and anyone else outlined in your communications plan who gets project information. File a copy of this plan in your project notebook as well.
Establishing a Change Control Board
The change control board is made up of key stakeholders, the project manager, key project team members, and functional managers and customer representatives when appropriate. The purpose of the change control board is to review change requests and approve or deny them. The board's authority should be outlined in the project management plan, as mentioned earlier.
The change control board should meet at regularly established times. Their meeting schedule will depend on the project; once a week may be necessary for some projects, while once a month is enough for others. Establish the meeting schedule at the end of the Planning phase, and start holding your meetings shortly after the Executing phase begins.
Make certain there are procedures in place for emergency changes. If the change control board meets only once a month, for example, and the project manager has an issue that must be dealt with on the spot, procedures should be outlined in the change management plan that give the project manager the authority to make the change. After making the emergency change, the project manager should still submit the change request to the board as a formality to show that the change has occurred, to log the change, and to include documentation of the change with the project information.
There are several ways to administer the change process and deliver change requests to the change control board. Your procedures may require that all changes go through a preliminary review by the project manager so that a high-level impact analysis can be recorded right on the change request form. After the high-level impact analysis is completed, the change control board reviews the change request and makes their decision.
Alternatively, large projects may have a full-time change manager who reviews all change requests and is responsible for the first level of approval before the change request goes to the change control board. Requests denied by the change manager go no farther. Or the change control board may review all change requests first. Those they think have potential to improve the product or project processes are given to the project manager to perform an impact analysis.
The project manager turns in the impact analysis at the next change control board meeting, where a final decision is made. Yet another method is for the project team to review all change requests and only those recommended for approval will go to the change control board. Again, the change management plan should outline your procedure, including when and how impact analysis should be performed. (We'll get to impact analysis later in this chapter.)
Change control procedures should include a tracking system to track the date the change was requested, the status of the change, and the approval status. This could be a simple change log or spreadsheet like the one shown in Table 11.1. This example shows a sample portion of a change control log for a software development project.
Table Change control log
Use this log at your change control board meetings to keep track of change requests and their status. The meetings shouldn't take long because your only purpose is to discuss changes. If you're working on large projects, the meetings may get more involved. But if they're getting too lengthy, consider having them more often. The control board meeting agenda looks something like this:
All change requests should be signed by a member of the change control board. This gives you the authority to implement the change or to file the denied change request in the project notebook.
After the change meeting, you'll communicate the change to the project team and modify the project plans to include the change. Changes to the scope, the project schedule, quality, or the budget will require updates to these project plans. Don't forget to submit the modified project plans to the key stake-holders and project sponsor for signatures when the changes are significant in nature.
Project Management Related Tutorials
|Business Analyst Tutorial||Strategic Planning for Project Management Tutorial|
|Software Development Lifecycle (SDLC) Tutorial|
Project Management Related Interview Questions
|Business Analyst Interview Questions||Strategic Planning for Project Management Interview Questions|
|Network Monitoring Interview Questions||Software Development Lifecycle (SDLC) Interview Questions|
|Business process outsourcing (BPO) Interview Questions||Project Manager Interview Questions|
|PMP Interview Questions|
Project Management Tutorial
Building The Foundation
Developing Project Management Skills
Initiating The Project
Defining The Project Goals
Breaking Down The Project Activities
Planning And Acquiring Resources
Developing The Project Plan
Executing The Project
Controlling The Project Outcome
Closing The Books
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.