Often times at Algonquin Studios, clients ask us to improve on their current software solution. The existing solution is either out of date or it simply isn’t giving the client what they need. For the user, changing systems can be a scary proposition. People grow comfortable with what they are accustomed to however, following a routine that you’ve done for years is the safe route. For this reason, it’s very important to sit back and think about what the system needs to accomplish. We want to make sure we maintain the output they are expecting from the software they use on a day to day basis, but keep an open mind on how to get there. In order to ensure this outcome, we spend a considerable amount of time conducting requirements analysis.
During the requirements analysis phase, one of the most important parts of a project, we determine what exactly the client needs are and how we will provide that solution. Time and again we run into the same obstacle of getting the client to see the difference between “what your users have today” and “what do you need the software to accomplish.” Clients often want everything they have today, in addition to the improvements we will provide with our software. Unfortunately, this could cause unnecessary features to be included in the software and add additional costs into the project going forward (training, support, system complexity … etc.). Costs that could be used elsewhere, either for the company or to build out additional features that are needed in the new system.
So, when coming into these requirements meetings it’s best to come prepared. To be better prepared it’s most important to know what is needed, as opposed to going screen by screen showing us everything they have today. There are many other ways to be prepared for these meetings, here are a couple:
Question your users
As a client, when was the last time you asked your user base about the program they use on a day to day basis? Requirements and business needs are always changing over time. Depending on the size of the user base, and the software being used, these questions could vary (and there are many). In the end, the client should find a way to determine:
- Which features are being used the most?
- Which features are rarely (if at all) used and aren’t needed?
- Is there anything you need the system to do that it doesn’t do today?
- Does the system provide repeatable work that the software doesn’t handle, costing people time every day?
- Are there current features that need to be revised to accommodate current needs?
There are many ways to gather this data.
Is this software internal, used by only a handful of people in your office? Have a meeting to review the software and gather the information firsthand from the users. Come prepared to ask about features that work and those that don’t. Are there any that have lost value over the years?
Do you have thousands of users using the software across the United States? Setup online user groups and invite people to provide valuable feedback on the software. Depending on the capabilities of your software, you can limit the groups to certain sections of the software and provide questionnaires about those sections. This should help you gather all the necessary information to bring to your developers, so we can make sure we build you an efficient, quality application that suits all your needs.
Clearly Define the Inputs/Outputs
Frequently, a screen can be so overloaded that one loses focus on what exactly is needed. Determine all the inputs of the screen and make sure they are all required and are what you need. Next, identify inputs that are unnecessary or misused. Keep in mind that just because they exist today doesn’t mean they’re needed going forward. Additional inputs only cause more complexity.
As important as it is to define the inputs, it’s equally important to define the outputs. Outputs that are currently delivered may no longer be needed or efficient or may simply be delivered differently in the new software; Once again, this is often difficult for a client to understand. Asking a lot of questions in the requirements meetings about those features can help ease the process because in the end, the more inputs/outputs you have the more complex your system will be. Our team of consultants are really good at letting clients know if the value they’ll receive from a feature is worth the effort and, generally, we can determine this during the requirements meeting.
In the end, if the client does their part in determining what’s exactly needed out of a system in order to eliminate all the old, antiquated screens and logic, the better the software will be. This will ultimately save the client in the long run.