If you’re in IT, having a user software change request form that is great can make your life much easier. Here’s a good approach to consider, with recommended questions and the reasoning behind the questions, as well as an example for each:

Why is this change needed? What problem needs to be solved?
On the user software change request form, ask for the requirements (business, legal, etc.) that are driving the change to be explained. Obviously something must be driving the request and often understanding the driver(s) will help you create better designs or solutions. It’s also important to get the user to state the impact of the change, or in other words, quantify the improvement (i.e., savings, accuracy, etc.) from before to after. This will help in the prioritization of multiple concurrent software change requests.

  • Example: The receiving associates have to re-label the LPNs for every pallet that a customer returns. We will ship a Pallet to a customer with a specific LPN and that customer can return that same LPN back to us. We can’t use the same LPN again because it still exists in our system. The associate has to switch to a different RF screen to re-label the LPN, walk over to the stationary printer to retrieve the label and switch back to the receiving screen. It takes an average of 2 minutes to re-label a LPN. We receive an average of 30 pallets per day. The purpose of this change is to eliminate/minimize the labor lost for handling return pallets.

In your ideal world, how should the software work today?
This is what we like to call a use case or user story in the IT world. But if you use that language with non-IT people, they might think it’s something more complicated. We find it is just helpful to ask users how they would like the system to work and have them describe that on the user software change request form. This is the process of outcome visioning and it is a very useful tool for a designer to build a solution that will meet users’ expectations.

  • Example: A warehouseman is about to identify previously shipped pallets that are coming back from a customer. He enters the RF Identify Screen and scans the first LPN which was shipped out from the system previously. Today he will get an error that the LPN already exists and he has to stop and deal with this error. With the enhancement he will not get an error and the old LPN will be renamed in the background automatically; the ware-houseman will simply do his job as normal. He will not even be aware that the LPN was renamed unless he looks in Daily Transaction Display where he will see a custom log entry indicating that the LPN was automatically renamed. This essentially eliminates any extra labor when receiving return pallets.

Should anything else Change or Not Change as part of this Process?
Sometimes you might receive a user software change request form where the user is assuming or expecting it to change other things about the system, or to not change something else. It’s important to ask the user what else should or should not change. You probably recognize this as Scope.

  • Example: This change should only allow us to be able to re-identify an LPN on the RF terminal for a return receipt (i.e., PO Type of ‘R’) from a customer. This change should not allow us to reuse LPNs that are on inbound ASNs or in stock. This only needs to work on the RF terminal.

How will you test this Software Change?
Ask the user to explain how they plan to test on the software change request form. Sometimes a user can be unaware that they even need to test this change, assuming IT will take care of it for them or not even realizing that is part of the process. When you can get a user to think through and explain how they plan to test something, designers can gain more insight. This is what you probably know as the User Test Plan or User Acceptance Test plan in the IT world.

Please provide a sample if possible.
Ask for samples or examples on your software change request form. If a user is requesting a report, label or screen change, ask for a mock up. It can be a mock up by hand or in Excel or some other tool. But often a picture is truly worth 10,000 words when it comes to designing the layout of a report, label or screen.

If you’re not in IT, we’ve got suggestion for you on how to fill out and write responses on your organization’s software change requests forms so that you get what you want – and so does your IT Department.

WHAT CLIENTS ARE SAYING