Question

. Change control procedures – what are the policies and procedures for approving, validating, and implementing change?

Answer 1

Change Control is the formal process that a company uses to document, identify and authorize changes to an environment (Process/Service). Change control reduces the chances of unauthorized alterations, disruption, and errors in the system.

Change control further enable the project team to modify the scope of the project using specified control and policies. Change can include anything that would impact the project timeline, finances, scope, and Quality.

Here is the process to ensure changes are properly managed:

1. Define the Change Request

A Change Request is a documentation for requesting the actual changes. Whoever owns particular requests must explain it in such a way that the team understands it thoroughly 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/proper document.

When defining the change, it’s necessary to possess in hand the particular 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 gets impacted, if the request cannot be completed or if considerable time passes before the request can be completed
• Conditions of Success: While this is often an Agile term, I think, it’s valid with Waterfall, as well. Call it what you would like to 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 reference 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 method varies from the straightforward (a call or email) to the formal (a memo or meeting). Unless the request is extremely simple, I like better to review the change with the complete 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 therefore 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 reaction 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 a number of info points below also as a team recommendation, which represents its view of the simplest choice. The customer might not always go along, but it can help them make a choice.

The response should include:

• Option Number and Name
• Proposed Solution: This could include the way to answer to the change request. it can be often anything from a technical direction and justification on to why this particular approach is being put forward.
• Proposed Timeline: The customer always wants to know the exact timelines and the progress. The estimated timeline may be the piece of data 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 could be no impacts — for example, if you’re changing a series of messages or buttons. But most changes will have some kind of impact. The scope change can impact the timeline, the budget, and thus the standard of the merchandise. 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 need to get additional people or may define a requirement for existing resources to feature or remove time on the project. All of those items should be defined clearly to enable the customer’s decision.
• Expiration Date for Proposed Changes: This sets a timeframe for the client to reply to the proposed solution and cost/time impacts. If the client goes outside of the set window, there might be additional impacts of the project. That aside, setting an expiration date provides urgency to the method.

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 an excessive amount of 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 a further review and proposal.

Whatever decision results from all this must be officially approved. When you define the Change Control process, make certain to incorporate an inventory of sponsors, stakeholders and key decision-makers who can OK both the process and the decision.