Automating the Change Request Process

Change control processes ensure DevOps projects stay on track, and that scope creep is kept to a minimum. A standardized, reliable change control process helps ensure that change activities are not full of confusion, faults, and disruption.

When you define and automate the controls and policies involved in project changes, project team members have a reliable way of ensuring deadlines are met and projects stay on course. Standardizing and centralizing the process for receiving, reviewing, and implementing change requests can have an immediate positive impact on project performance and outcomes.

Managing Project Change Requests

Three elements are defined when automating the change request process: change request collection, routing and workflow, and tracking and reporting.

Change Request Collection

The collection of change requirements is handled via forms. Forms are designed to capture all relevant information for processing a request. Information could include fields category, importance, impact, complexity, etc.

Documents can be attached to the form to include additional information, but it's always considered a best practice to capture as much information as possible in the form itself for easier processing and retrieval.

Routing and Workflow

When a request is submitted, there needs to be a pre-built workflow to handle routing. Some considerations:

• Is a request routed based on form information (e.g., requests marked as "High Importance" follow a fast track), or are all requests handled the same way?
• What are the milestones and sign-off points?
• Can a request be returned to the requester for additional information

These and many other aspects should be defined before building automation.

Then consider who manages the approval process. For instance:

1. A request might start with an assessment team. A form could capture the assessment team's recommendation, risk-level, justification, and approval.
2. If accepted, the request proceeds to the planning team. Another form collects the planning team's estimate, regression plan, and resource allocations.
3. The request finally moves to the Implementation team for scheduling.

Tracking and Reporting

Reporting and analysis must be communicated prior to building any change request workflow automation. This way, the process can be built with the end reporting goals in mind.

For instance, if it's critical to capture the time it takes between request stages, the process automation software can be set up to measure the time between specific stages.

If the reporting goals are to measure which departments submit the most requests, then the "Department" needs to be captured in the request form. Accounting for these reporting expectations midstream can prevent capturing an incomplete picture.

Bringing It All Together with Automation

Assuming you have an automation platform in place, you can bring all of your planning to the automation team and discuss your goals. The automation team will need to see your documented process, capture forms, process members, and reporting requirements to be able to build out the automated workflow, test it, and deploy it.

You'll then need to communicate the new process to your internal requesters, explaining the benefits and expectations. Training may be needed depending on the complexity of your process as well.

Once the process is adopted you'll find changes are easier to manage and requesters are much happier with the speed and transparency of the DevOps team.