With change requests coming in daily from multiple directions, many of us struggle to manage system changes. Without a Change Control system, chaos looms: requests fall through the cracks, low-priority changes happen while higher priorities sit in the queue, teams work at cross purposes, rollouts hit snags and users are blindsided.
Having a Change Control process in place helps whether you are looking to implement new organizational policies, modify system processes or update to the latest software version of your practice management system.
What is Change Control?
At the highest level, Change Control is a process to manage changes to a product or system from its proposal through roll-out. Change Control helps you:
- Document and track change requests
- Assess feasibility and prioritize requests
- Identify risks and benefits
- Record test data and results
- Plan and implement the change
- Inform affected parties and help them prepare for the change
You don’t need the latest software or the most expensive system to manage changes within your organization. When I worked in an IT shop, we created our own system database to document and manage system changes in response to an auditing mandate. We also bustled to convene a governing board.
What to Include in Your Change Management System
Having a repository of your change requests not only helps with auditing but also maintains the source of truth. You’ll see the value months or years down the line when someone is looking to make a related change, questions why a particular change was implemented or requests a change that has been considered and denied. Having a documented record minimizes the amount of work needed to re-assess requests.
Below are examples of information to include in your Change Management System. Some are straightforward, while others require consultation with your governing board– which I cover in a later post.
- Requestor Name: This person should have all the details. It could be someone in the requesting department (site manager, billing manger, etc.) or someone who has the information needed to represent the client
- Department/Business Unit: When setting up your system, create a dropdown list of all departments your IT shop does business with. Don’t overlook departments like Finance and HR. A list is preferable to a text field, especially if you plan to report off those fields
- Date of Request: When the request was submitted
- Level of Priority: Create a range from Low to Urgent. Factor in whether it impacts revenue (Y/N)
- Expected Completion Date
- Systems/Applications Impacted: Create a list of systems and applications you support, so you can easily select the ones affected by the change. Having a list makes it easier to spot all affected applications
- Components Affected: Create a check-off area to indicate elements affected by the change (hardware, software, interface, security, workflows, documentation, etc.)
- Objective: Provide a field to describe the purpose
- Request Description: Provide a field to summarize the requested change
- Expected Outcome: Provide a field. Include how you will measure success
- Status: This field is where to indicate if the request is: still under review, pending additional information, in the works, being tested, or denied. For requests that are denied, be sure to document the reason(s)
- Approval: Provide an area to state the date of approval and to identify the board members who approved the request
- Go Live Field: This is where you capture a Testing sign-off, the date the change was launched and the name/signature of the person moving it into production
In my next post I’ll talk about who decides whether changes get implemented and how those decisions are made. Those discussions will help you fill out fields like priority level, objective and expected outcome.
If you have a Change Control process in place, post a comment to let us know how it’s going.