Explain the business, legal, etc. requirements that are driving this change.
Not only will this help you think through the actual need for the software change and may help prioritize the needs for your team, it will also help the IT department create better designs or solutions because they see the bigger picture. It’s also important to state the impact of the change, or in other words, quantify the improvement (i.e., savings, accuracy, etc.) from before to after so that the IT Department can prioritize multiple concurrent 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.
So, how do you want the system to work? Describe it for the IT Department in as detailed a way as you can. If you’re struggling to write out or draw out your idea, even with a great form from IT, consider using your smartphone to make a video. Make a video of a co-worker, yourself, the process, the computer screens, etc. that will explain what you want using both audio and video. When it comes to software change requests, more information is much better than not enough.
Example:
A ware-houseman 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.
Don’t assume or expect your change request to automagically change other things about the system. And sometimes, one change will cause a change in another spot that you don’t expect. It’s very important to explain to IT what else should or should not change. You might have heard this referred to as Scope by your IT Department.
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. 4 – Ask if you have to test this Software Change? How do you plan to make sure this works? Whether or not you realize it, the IT Department probably expects you to test the system change, not them. Think about how you might test all angles of the new change to make sure it’s what you wanted and that it works – and then explain that procedure to the IT Department. By doing this, it sometimes helps IT more fully understand what you want them to do with the software. This is a User Test Plan or User Acceptance Test plan in the IT world. 5 – Can you give them a sample? Give IT samples or examples, especially if you are requesting a report, label or screen change. Mock ups are great! Anything you are comfortable using will probably be fine – by hand, Excel, Word, etc. Often a picture is truly worth 10,000 words when it comes to designing the layout of a report, label or screen.