Without a Change Control process it’s nearly impossible to track requests for system changes, assess feasibility, make and test the change, put it into production and keep interested parties in the loop. In my post titled “Managing Chaos”, I described how to put a Change Control process in place. Here, I talk about governance and feasibility – who decides whether changes move ahead, and how those decisions are made.
Spell Out Who’s in Charge
To successfully manage system changes in your organization, you need a governing body that represents the various areas of your IT shop as well as stakeholders from the operational and financial sides of the business.
If you are establishing a Change Control process for the first time in your organization, it will be a culture shock for all involved on the IT and operations side. Business owners who are used to making informal requests may struggle with having to justify the need. And, IT staff members may struggle with a process when they formerly could jump in and make small changes to the system on demand.
Governance is not the place for informality. Write down:
- The members of your Change Review Board
- Their responsibilities
- How often they will meet
- The types of system changes that can be categorized as urgent. Consideration of these will likely need to be expedited
To help gain buy-in for the new process:
- Meet formally with all IT staff, even those who are not part of the review board– this helps ensure they understand the new process and deliver the same message and level of support to all clients
- Introduce your new process to all affected departments– Be sure to set realistic expectations about appropriate response times
The members of your Change Review Board should be able to freely discuss and present the risks and benefits associated with change requests. Some of the questions to answer during those discussions:
- What is the change?
- Who does it affect?
- Does it modify other processes or procedures?
- Does it impact current design and workflow?
- What area(s) of the system or other system(s) does it impact?
- What are the pros and cons?
- If a particular department or business unit requested the change, will it benefit others in your organization?
- Is the request a regulatory requirement? If so, is there a deadline to meet?
These feasibility discussions help determine whether a request gets approved and its priority level.
Typically, revenue-generating requests are given a higher priority. Here’s an example that could increase revenue by minimizing days in Accounts Receivable: Implement a TES/BAR Claim Edit to hold claims for a provider until they are credentialed with a particular payer.
Considering the big picture of change request can spark ideas for a more efficient or comprehensive solution. For example, in implementing the regulatory requirement to capture specific data for meaningful use, we considered where the information was being captured, how it would be reported, which downstream systems were affected and whether existing interfaces could be used to manage the transfer of information or if new ones would be needed.
The discussion also may point out that more information is needed before a decision can be made. Let’s say you receive a request to update claim logic to address a denial. Maybe claims are going out for a particular payer with the Group’s NPI number, but the payer requires the Provider NPI. Check to see if the denial is financially impacting other departments. A single department may have requested the change, but for the organization as a whole, it may add up to hundreds of thousands of dollars that could be rebilled and collected. There’s a change worth prioritizing!
Once changes are in the pipeline, you’ll need a plan to test and roll them out. In my next blog post, I’ll talk about implementing and communicating your change.
What methods have you found useful for prioritizing change requests? Share your insights in a comment.