Change control is something that is inevitable even with the most successful projects. I'm not sure I've ever worked on a project that didn't have at least one modification made along the way. What's critical is that you know how to manage change and ensure the project remains on track -- and ultimately successful -- despite it. When you're starting a project, it's important to ensure there is a change control process available. If the company you work for doesn't have a methodology, then it's your job to establish one.

Some Basics

"Change Control" is a formal process. It is set up to enable project teams to modify the scope of the project using specified controls and policies. Change can include anything that would impact the project -- time, budget, scope, all of which can impact quality. Most of the time, it's scope that impacts the other items. Here's a simple process I've followed to ensure changes are properly managed.

1. Define the Change Request

Change Control is the process. A Change Request is the documentation used to request the actual change. Whoever owns the actual request needs to explain it in such a way that the team understands it well enough to define it. This should be done through appropriate documentation (whatever the project team or company expects). It can be as simple as an email or as complex as a formal document. When defining the change, it's necessary to have in hand the actual request with all supporting statements. This should include:

• Actual Request: Statement of the need. This should outline clearly the change item for the project team to analyze.
• Reason for the Request: Customer impacts if the request cannot be completed or if considerable time passes before the request can be completed
• Conditions of Success: While this is an Agile term, I believe it's valid with Waterfall, as well. Call it what you want, but customers must be able to define what they expect from the change.
• Expected Completion: The requester should provide an expected due date for the item. This doesn't mean the change will be completed by this date. It's simply meant to provide more details for the team to analyze when defining options.
• Expected Value:  This should explain why the request is needed. It can either be something as simple as "better customer experience" or "revised calculation provides more accurate data" in relation to a report.

2. Submit and Review the Change Request.

Once the Change Request is documented, it's submitted to the project team. Here again, the process varies from the simple (a phone call or email) to the formal (a memo or meeting). Unless the request is very simple, I prefer to review the change with the full team. That meeting provides the proper venue for the request to be reviewed, and all members have a chance to ask questions and help make decisions. There should be two portions to reviewing the Change Request: the formal presentation or meeting and the project team's review and discussion of impacts. Within the change control process there should be an expected turnaround time for these. Discussions with the customer should include setting expectations regarding response time, or at least when the team will provide feedback.

3. Define Options and Create Response Document

Once the team has reviewed the Change Request, options should be defined. There should be a minimum of two. When providing the document response, always provide each option with some of the data points below as well as a team recommendation, which represents its view of the best choice. The customer may not always go along, but it can help them make a decision. The response should include:

• Option Number and Name
• Proposed Solution: This should include how to respond to the change request. It can be anything from a technical direction and justification as to why this particular approach is being put forward.
• Proposed Timeline: The customer always needs to know how long something is going to take. The estimated timeline is a piece of information they will leverage when making a choice based on the options the team presents.
• Impacts to the Project: This is an essential part of the response. If changes are small, there may be no impacts -- for instance, if you're changing a series of messages or buttons. But most changes will have some sort of impact. The scope change can impact the timeline, the budget and therefore the quality of the product. This area should minimally explain the cost of the changes, the impact on the timeline and potential quality results. There may also be resource impacts. The team may either have to get additional people or may define a need for existing resources to add or remove time on the project. All of these items should be defined clearly to enable the customer's decision making.
• Expiration Date for Proposed Changes: This sets a timeframe for the client to respond to the proposed solution and cost/time impacts. If the client goes outside of the set window, there could be additional impacts to the project. That aside, setting an expiration date provides urgency to the process.

4. Final Decision And Approval

The customer should provide a timely response. If the Change Control Response document expires, it should be re-evaluated once the customer provides feedback. If too much development has occurred to sustain the change, then that needs to be stated. If the delayed response has resulted in other impacts, they need to be communicated as soon as possible. It's also possible that an expired response could lead to an additional review and proposal. Whatever decision results from all this needs to be officially approved. When you define the Change Control process, be sure to include a list of sponsors, stakeholders and key decision makers who can OK both the process and the decision. Every change control request should follow this process. This isn't to simply cover the team. It provides consistency and manages expectations. Some requesters may not want to follow the process -- I've actually been screamed at and put in some difficult situations. But I've found if I stick to a plan that's supported by management, I'll be backed on decisions I make as a PM.