Provide Mechanisms for Feedback

With the expanded project team Martin put in place, it was easy for a pilot user to give feedback to a team member. This feedback was then summarized and sent to Martin. When Martin got the feedback, he could make on-the-fly changes to how something was done or arrange for a desk visit to address the issue.

Jason could not keep up with the email coming in. The use of a discussion news group seemed like a good idea at the time. Unfortunately, it was full of more questions than answers. The group had been made open , and thus anyone could read or post. It was unfortunate, but some were getting a bad impression of the technology without ever using it. Jason knew that for this method to work, he needed a knowledgeable discussion moderator.

The Methodology

The users need to be able to voice their issues and concerns in as many ways as possible. Some issues are best expressed in open, anonymous forums, and others face-to-face. What follows are some suggestions on starting and keeping the lines of communication open among the pilot user community and the project and support groups:

• Email group ” Most corporate email systems support groups. Creating groups to send questions to, or to distribute information to, is easy and convenient . By using a group email address, all participants or concerned parties will get the email. That is to say, an end-user may not know all the project members , but if the user is told to use ProjTeam as the email group, it will reach all the right people. The same holds true for the project and support teams . Using email groups makes sure everyone is kept informed who needs to be.

• Discussion folder ” The use of a discussion forum allows a hierarchical view of the conversations and questions, It can also offer the users and others the chance to share information or concerns anonymously. This way, all issues and questions can be shared for everyone to learn from. It can also provide a source of information to update the frequently-asked-questions-list, and supply additional data for the support database.

• Phone number for support and questions ” Nothing ever replaces hearing another human voice in real time. The ability to reach live support people on the first call cannot be stressed enough. Pilots and piloting software can be very stressful on the end-user, especially when things go wrong. Thus, picking up the phone and talking to someone to get support can help reduce the stress and tension of the situation. These phone numbers and the fact that a live support person will answer will also increase the user's confidence in using the system, decreasing his/her fear of using the system and having something happen and being stuck.

• Random desk visits to solicit feedback directly ” While providing as many means of communication as possible is very good, nothing beats a desktop visit. By visiting the user in his/her environment, you get to see first-hand how the system is used, and also the user may be stimulated to say or ask something he/she may not have communicated otherwise . It also makes the user feel appreciated, which is an important part of the process.

Stress the importance of hearing from the users what they like, but most importantly, also elicit feedback on what they don't like! This should be stressed at every opportunity to communicate with the users. Nothing will slow or possibly derail a pilot faster than simmering rumors of problems or general dissatisfaction. The only way to get this resolved is to encourage users to voice their concerns on anything and everything. Share the water- cooler gossip about the project so that rumors can be quieted and real issues identified and resolved. By doing this, it creates a healthy working environment and puts a stop to possible dissention in the user community.

When a problem is resolved, there should be a follow-up with users to make sure the solution was acceptable and really did solve the problem. This is probably the most important step in problem resolution after finding a solution. Many times, solutions need to come from people who have no direct end-user interaction or experience. As such, the solutions sometimes solve the problem from a purely technical standpoint, but are not acceptable to the end-users. For example, a problem may be identified where the biometric system hangs . The solution may be to either reboot the machine or disable the software causing the conflict. While both solutions resolve the problem, one may be more acceptable to the user than the other. The software that needs to be disabled may be crucial to the user's duties . The failure may be seen only intermittently, so rebooting is not a big deal. The converse of this is that the end-user may need to consider accepting the solution if that is the only one available. The user may also be given the opportunity to be removed from the pilot. Offering this option can at many times make the problem less significant. For example, if the biometric system has made the user's daily activities much easier and less stressful, having to deal with a small glitch may be preferable to losing the benefit of the system entirely.

The importance of getting user feedback cannot be overstated; just as important is using the user feedback. The users need to see actions and problem resolutions coming out of their feedback. If they do not, they will most likely stop the flow of communication.