WHAT IS A CHANGE REQUEST?

Identifying the need for a Change Request on an institutional and technological level‍

Now that we have addressed what is necessary to help change go smoothly, as well as how you can prepare for and efficiently address defects in your new system, it’s also important to understand the evolving landscape of your new technologies -- in particular, the best way to engage in change requests with your OMS technology partner from both a technological and institutional perspective.

HOW IS A CHANGE REQUEST DIFFERENT FROM A DEFECT?

‍First, what is a change request and how does it differ from a defect?

Change requests are new features, needs, or processes required to effectively run your day to day operations through your OMS. This is different from a defect or bug in that it is not something operating incorrectly with the software that needs to be fixed, but rather a new and different need the software is required to perform that differs from an original process or functionality.

One way you might think of it is like building a house. When you originally decide the size, layout and scope of budget for the house, there are certain parameters for what originally comes in the builder’s budget. If you decide, for instance, that you’d prefer hardwood floors  instead of tile, that is a change.  If you want a deck and that wasn’t originally in the plans, that is another change. We see changes like this all the time in our lives and businesses. The same goes for software, especially where the very nature is to evolve and adapt the system going forward. 

So, in starting out with any new OMS, you and your partner will lay out the scope of needs and functionalities that your new system will be required to perform. But Corrections business processes or laws may change, and while you likely have an annual maintenance agreement with your partner, certain new functionalities require more time and involvement than others, and you may quickly go over the hours originally contracted, thus any new request becomes an additional “change request.”

A great example of this can be the time computation/sentence calculation module. Oftentimes, lawmakers are creating evolving parameters for what affects any inmates’ sentence--such as a reduction in time for good behavior, or early geriatric release. Whereas you originally built your new OMS around whatever existing parameters your state laws had in place at that time.  As those changes become the new practice, you want to immediately plan for and execute change requests to both protect your agency from liability, but also to prevent workarounds or manual interventions becoming the norm for those on staff who are responsible for maintaining that particular process.

However, not all change requests come from the top down (i.e. government or state legislature). You and your agency may identify new functionalities that would greatly benefit the day to day management of your tasks, or alleviate manual business processes or silo system pain points for staff. Never be afraid to suggest a change request and begin working through it with your OMS partner! That is how systems grow and evolve to become more efficient and better serving the evolving needs of any agency.

But how can you plan for these changes from both an institutional and technological perspective, and what can you expect from your budget and turn around time with your partner in getting these new, but vital, functionalities up and running?

In the next installment in this series, we will address how you can begin planning for many of these changes as soon as they show up on the horizon, as well as how you can work with your partner to ensure that they are implemented as quickly as possible.