Tips for getting a perfect fit with grievance software

Over the last eight years building custom coded Grievance Manager applications, and now with the Step One SaaS (software as a service) product, we've see a lot of variety in our clients' grievance software specifications. The apps run the gamut in terms of forms, screen flow, and the actual information requested and required. And while we pride ourselves in being able to meet our clients' demands, we also offer advice based on past experience and feedback from prior customers. Here is advice based on lessons learned.

1. Identify all stakeholders. Make sure everyone who needs to be involved in planning gets involved. Not everyone needs to be in every meeting or phone call, but everyone does need to review documents that result from those meetings and discuss any concerns or omissions. Hint: Staff assistants are VIPs in the planning process.
2. Make a list of goals. Sounds simple and obvious, right? Maybe so, but when your individual stakeholders review that list, it will usually spark some discussion, and the list will change.
3. Assign a project leader - a single individual - to lead the specifications process and direct communications with the software builder or provider. This doesn't have to be the boss, but it does have to be someone who can communicate easily with the boss and everyone. Make sure the software people know that everything goes though your leader, and make sure all your stakeholders know too.
4. Ask for screen prototypes and have everyone review them. This will often bring up issues and opportunities for data integration and contingencies.
5. Require only what's required, and be careful not to tie your staffs' hands. Requiring user input in certain areas can be greatly improve your information gathering, but be mindful of potential situations where staff may want to get some information saved in the record before they have all the information they'll eventually need. You want your grievance app to be flexible enough that staff use it nimbly; they shouldn't have to copy notes into it later.
6. Avoid redundancy. Often you'll want to potentially repeat information, such as between steps, but that only makes sense if the information can be altered between steps. For example, it's often a good idea for a field like Step 2 Issue Description to default to whatever was entered in the Step 1 Issue Description, but to allow users to append or edit that field.
7. Avoid adherence to past practices that aren't helpful. We sometimes see requests for information pages that include legacy fields from other applications, like home phone, cell phone, work phone, primary email, secondary email, etc. But forwarding these into your grievance app will cost data entry time and screen space, and is more likely than not to cost servicing time and cause confusion. We recommend that you take one contact phone number and one email per member (or anyone else). Let them tell you how they want to be contacted, rather than have your staff be responsible for leaving multiple voicemails and hoping for the best.
8. Think carefully about how your staff will benefit from email reminders, and make sure the specifications reflect that. More isn't necessarily better. If your Grievance Director is getting an email from the app every time someone schedules a meeting, s/he is going to learn to ignore them, and may miss the important one on a Step 3 denial.