As noted in my last post, it is important to have well-defined business requirements before starting a new technology project, or before starting development even within an existing platform.  There are lots of methodologies here – some from the consulting world, and some from the sales world. All of these boil down to truly understanding the business problem you are trying to solve for your clients or, if you’re in house, for your system’s users.

Keep in mind that this is a conversation, not a list of questions.  Given that nearly all clients will ask for a list of questions up front, though, this is what I’ve pulled together.

• What are the answers you need from the system? In other words, what does it need to tell you, and how?
• What questions do you need to ask this system to get at these answers?
• Where do those answers live now?
• How can we get them into this system or report?

I’m going to focus on these first two bullets, because the second two are much more tactical. 

Let’s start with answers, because in the end, the most important thing about any BD tech project is that the system can give you the answers you need.

• In an experience project, your answers are going to be narratives about projects that meet the criteria you need to highlight in a proposal.
• In a CRM project, your answers may look like a report that shows you how well your professionals know key personnel at companies targeted by an industry team.
• In a sales operations project, your answers may be in the format of a dashboard, identifying all of your BD personnel and showing the status and progress on all of their opportunities.

I start with the answers, because knowing the questions your clients want to ask doesn’t mean you understand the actual business problem they need to solve.  Understanding what those answers actually look like will help define this more clearly.  Without this understanding, your users will inevitably have different expectations, and you’ll end up with an implementation that seems off for everyone.

I’ll use another example from a former client.  I was working with a company that was improving its processes around business development and wanted a better understanding of its opportunities.  The initial requirement I received from the client was along the lines of “System must be able to help us understand business opportunities within a particular segment and geography.”  As we explored this requirement, I tried to understand the appropriate answer to that question, in order to formulate the question (and underlying business requirement) correctly. 

• The partner user meant “I want to see all Commercial Real Estate opportunities for properties in Northern California.”
• The segment and office leaders wanted to see “all opportunities being driven by partners in the Real Estate group in either the Oakland or Sacramento offices.”
• The marketing team saw the question as “I want to see all opportunities for real estate companies based in Northern California.”

See the difference?  The answers to each of these statements is going to be different, and it is important to think through these types of variations as you identify your business requirements.  A generic requirement might look more like “System must be able to help us understand business opportunities filtered by various values related to the details of the opportunity itself, details around the prospective client, and details around the partners in charge.”  Then, these three statements can all be used as examples for an RFP, or as use cases for a demonstration.

This is the second article in a series. Check back for thoughts about using drawings to ensure your users truly understand what they are asking.

Please contact me if you’d like assistance figuring out the right questions for your answers.  I can be reached at jennifer@klyseadvisorygroup.com.