You’re the Business Analyst for a large distributor and you work closely with the Vice President of Sales and her sales team. You’ve just learned that your company is going to invest in a CRM system, in fact, the very system that you recommended and with which you are very comfortable. Can you avoid one of the most common pitfalls that await you on this project?
A Business System Analyst (BSA) or Business Analyst (BA) is a key member of any CRM Project Team. It is important that you don’t let your familiarity with the system that has been chosen keep you from doing what you should be doing on the project. Rather than listing functional and non-functional requirements, what you should be doing is cataloging the business processes and goals, and then working with the system architect to determine the best way to configure the system to achieve the goal for each process. However, when you talk to the potential users of the system, you discover what all BA’s have discovered before you. Users have at least 2 problems when it comes to expressing their functional and non-functional requirements: 1.) The “needs” expressed are too specific or 2.) The “needs” are too general. For example, a user might say, “All of the required fields should be highlighted in red.” That sure sounds like a requirement, but it is really too specific to be valuable at this point, it is really a design element. Possibly you’ve heard a user say, “It has to be really easy to use.” Again, that may sound like a requirement, but it is too general to be valuable at this point as well since it deals with usability and not what the system will do.
You may have also discovered that users almost always have no hesitancy at all in talking about their problems. You should be delighted whenever you find a user who can clearly express the problem he or she is having. Those ‘problems’ will lead you to the real ‘needs’ of the user community. Your job is to help them see that each resolution to a problem is really an achievable goal for the project. Users are almost always focused on their problems. Ask yourself, why is it a problem for them? Better yet, ask them! For example, Joe User states, “I never know whether or not one of my sales will be accepted” Now that certainly sounds like a problem, but why is it a problem, and what is the cause? Your questions should clarify the issue. “Why is that a problem for you?” “What do you think is causing it?” In our hypothetical case, Joe User answers both: “I am wasting my time if the sale isn’t accepted.” “The customer is turned down for bad credit.” In our simple example, you as the BA can now turn this into an achievable goal. “So, the system should have a quick way to qualify the credit of a potential customer before you take the time to create and submit an order?” Notice, this is a question back to Joe User. Wait for the confirmation, you don’t want to insert your assumptions and your familiarity with the system and miss the real need. In this case, Joe User says “Yeah, if we could do that, it would be a big help!”
Don’t stop there, are there other problems you can uncover and convert to achievable goals. In fact, you may even want to do away with the traditional listing of ‘requirements’ and replace it with system goals and the design elements to meet them. Remember, just because you know what a system can do, don’t assume that this is what the system should do. That is the pitfall that you must avoid on this project. Instead, listen to the users, find their problems, and convert them to achievable goals. Sometimes the best hack is not taking a shortcut.
This blog was written by Jim Lindenfeld, who has been actively involved in customer relationship management during his entire professional career. He is a certified sales and sales management trainer. He has been involved in the implementation of CRM systems since 1987 and is currently a principal consultant in our CRM practice.
Illustration created and provided by Jonathan Pike, eVerge Group IT Specialist