Part of the process of Confirm The Business Case (Chapter 15) is to guide the conversation so that your prospect is actively engaged and not just giving you the same pre-programmed answers that he is giving back to your competitors. You know that if you focus on developing your questions (Chapter 16) so that they continuously clarify the prospect’s problems, desired results, and existing issues that you can then help them prioritize (Chapter 17).  Now it is time for two very important questions:

Is there really a problem?  Does it really matter?

Let’s break these down a bit.  When I ask if there is really a problem, we both know that the answer is yes.  After all, you’ve done the work associated with the above listed chapters. If you are meeting with the person who actually writes the check, then you are well on your way.  However, if you are working on a large, technical, or complex sale, you are going to have to help your prospect justify to others within his organization that there is indeed a real problem, and that takes evidence.

What evidence am I talking about?  Let’s go back to the example we used in Chapter 17 of replacing an antiquated e-mail system with a new one.  We asked our questions, and were told that “The existing system uses old servers which are becoming unreliable, we have a hard time pushing large attachments through the system, it won’t do web-based e-mail, and it is hard to keep anti-virus software up to date.”  We then helped our prospect prioritize these issues, and in the middle of that process found out that the president had a brand new iPad, which changed the priorities again.

Now that we have this kind of data, we need to ask the Who, What, Where, When, and How questions.  This is old school stuff, and you probably already know that you need to add hard data to some of the soft statements your client is making.  In the e-mail system example above, let’s take the first thing our prospect said, “The existing system uses old servers which are becoming unreliable.”  To properly build a business case, we need to ask questions such as:

• Who manages the existing servers?
• What are the existing problems?
• Where will funding come from?
• When will the budget be approved?
• How will this project be managed between multiple stakeholders?

You get the idea.  These are all proof points that different people within the organization will want to understand, even if they are not directly responsible for the project.  These questions can seem obvious, but they help to clarify to others that there really is a problem.  The other aspect of building a business case is to quantify how the problem is negatively impacting the organization and then how a successful implementation would positively impact the organization.  For example:

• Who is impacted by the server’s reliability problems?
• What hard costs and soft costs are absorbed because of the reliability problems?
• Where is the data that could verify those hard and soft costs?
• When could the investment in the project reach a break-even point?
• How can we measure if the project is successful?

These questions help to establish not only the impact that the problem is having on the prospect’s company, but to also set up a scorecard that can eventually be used to prove the success of your solution.  When you can answer these kinds of questions, you will be able to help your prospect show that not only do they really have a problem, but that it really matters.  It is surprising how many clients ultimately take this alternate way of exploring issues to assemble a compelling business case and use it in their daily life.  If they have been shot down in the past for projects that they worked on, they usually find that building a business case that the C-Suite can relate to is a skill that will pay dividends for years.

A side effect to this kind of questioning is that your contact may come to the realization that they do not understand the problem as well as they thought they did, especially when dealing with the financial impact.  In fact, it is likely that many of the answers are scattered throughout the company’s departments (silo alert!), and that some information is simply nonexistent.

This is not necessarily bad news.  In Chapter 11, “Yes Is Good, No Is Good (But Maybe Will Kill You!)” we discussed how bad news isn’t the end of the road, but just an inflection point.  We can show our value to our prospect not only by asking them tough questions that they can’t answer, but by showing them how to go about getting those answers so as to help build a strong business case for their project.

This will become very important down the road whether you submit your solution in a written proposal or as an in-person presentation.