Involving Staff in System Selections

The steps in selecting a new AMS or other system aren't really that difficult.  Basically, you think through all the things you need and you compare those to the available systems.  But as with any process, there are things that can trip you up, and I'd like to look at one of those: how you involve other staff in the process. 

Dissatisfaction with an existing AMS can come from more than just the features of the system.  To avoid end-user dissatisfaction down the road, the more you involve staff upfront, the better.  Not only does it mean that you cover all your bases on the functionality list, but it fosters ownership of the system if people feel they have had a role to play in the selection.  One client engaged us to help them with an AMS selection, because the first time round, the IT staff made the final selection based on user input.  It didn't quite work and the organization is unhappy with the choice.  This time they are asking us to help them gather input from all staff in a structured and inclusive way. 

Lay the Groundwork.  As you embark on the selection process, set a tone of looking for input.  One way to do this is to send out emails about the upcoming project and let them know their input will be included.  Distribute a list of questions to get them thinking about pain points, goals, usage, and access.  Let them know the timeline and the time commitment from each person.

Gather the Information.  Conduct a formal requirements gathering process, where each department or group has the opportunity to provide input in a focused meeting.  Go deep into what they do, and how that work supports the organization.  Identify what bugs them the most and what they do the most, as well as what they'd like to be able to do.  Make sure you ask leadership too, they will have ideas that you're wise to incorporate.

Create Good Output.   When documenting the requirements, keep it clear and short.  It's good if your documents are actually provocative, and list the contentious issues upfront.  This gets staff to either nod their heads or push back, and that is useful information.  Even if in the end you don't go with everything they want, you can identify what was not included and why, and communicating that will help staff feel heard.

Get Hands On.  This is a hard one, but if possible have real people try out real tasks on a candidate system.  It's hard because most vendors have limited demonstration accounts, and prefer to keep their fingers on the mouse.  So a second option is to have them do specific tasks for you, and see how many clicks it takes.  Count them.  Have them do it slowly.  Does the mouse go where your eyes went or to strange new place (like an x to close the screen located bottom left instead of top right). 

Explain the Rationale.  Whatever system selection you make, whatever launch  timing you plan, whatever data conversion process you lay out, give the rationale for it.  It shows respect for their intelligence, effort and time. 

Provide Training.  It can be easy to think that training isn't needed because the system is so intuitive.  Or to give initial training but not have anything advanced.  Or not offer it after system launch.  Do it all.  Have something recorded for new staff to watch.  Offer advanced training, even if it's only every three months, or once a year.  You might find that few people use it, but those that do will save your organization significant money in the time they save themselves in doing ongoing tasks quickly.