Last week, in Austin, Texas, I had the opportunity to speak to a variety of IT professionals from non-profit organizations. When discussing software implementations I heard the same things time and time again. I heard, "the end users just won't use the system," or "the system isn't giving us what we need," or "we just can't figure out how to make it work for us."
When you undertake a software implementation it's critical that you have the right people on your team and that they're asking the right questions.
Often times project managers or business analysts ask the question, "what do you want...?" An end user might say, "I want to enter these five fields." The analyst says "great, we have those fields, let's move to the next item." If that's all you ask, you might miss the actual requirement and in the end, the user will see the item/project as unsuccessful.
End users know what fields they use today, they know the process they use today, and they know what tasks need to get done every day. What they might not know is how a process could be automated, or how the number of steps in a process could be cut in half by moving data around. So, asking the question, "what do you want?" is likely going to get you what you have today.
If you reframe the question and ask, "what do you need" you're more likely to get the information you need to fully document and design a solution. When you ask, "what do you need" the end user might say "I need to give my boss a report showing these three things." Understanding and listening to what the user needs will help the implementation team determine how best to configure the system to allow for that type of report, how to convert the data so that it's accessible and how to build the outputs that help the end user do their job.
Let's take a look at an example - for this example we'll say we're designing or documenting requirements for the general ledger.
If I ask the user what they want, the user says, "I want a field where I can add the GL account on a gift so it matches the finance system."
If I ask the user what they need, the user says, "I need to provide the finance team a file that includes the GL account number." Why is this important? If you're defining your requirements or design, you may miss critical element that requires configuration or even customization.
To get to the right answer, start by asking your end users:
- what do you want to accomplish?
- what is the end result?
- what is the value of doing this?
Asking these questions will get your end user to provide the elements you need. Instead of "I need a field" you learn that they need to create a post to GL file that contains the account number (and likely other things), you identify that they need a .txt file and the value is that the finance team will no longer have to re-key journal entries.
Here's a real-life example that illustrates how asking what do you want lead a team in the wrong direction and an end user unhappy with the results. In a revenue design session an analyst asked the person responsible for adding employee-giving gifts "what do you want." The user said they wanted to add a gift to the system and give recognition credit to someone. They also said they wanted to use a batch to do this. The business analyst went off and designed a solution that at face value met the requirement. When the user started testing the process they said "this won't work because I have 800 gifts to enter and I want to import them into the batch and this batch won't allow me to add gifts and this other type of information I want to add at the same time."
When we stopped and asked the user what they were trying to accomplish, we learned that not only did they have multiple files every month with 800 gifts, but the files included address updates and relationship information and several other data points. With this information we were able to design a solution that allowed the end user to successfully use the new process.
Understanding what your users need will help you effectively manage expectations, define the project (what's in scope, what's out of scope) determine what requires customization and what doesn't and will help with user adoption because the end users are getting what they need from the system to be successful in their role.
If you'd like to learn more about implementation and what questions you should be asking, please feel free to contact us. Check out our post Six Mistakes Your Making with Blackbaud CRM(TM) to learn more.