How Business Analysis Can Help Customer Facing Organizations in the Pre-Sales Phase

How Business Analysis Can Help Customer Facing Organizations in the Pre-Sales Phase

Kelly BurroughsWritten by Kelly Burroughs, Business Analyst – Enfocus Solutions

Can you relate to this scenario?

You’re a business analyst working in a software company who has been in talks with a potential client for weeks now. The sales team has done a great job showcasing the software, the client likes what they see so far and they’ve requested a statement of work to see what it will cost them.

Given the problems your company has run into previously with misalignment between estimated scope and cost of work and actual scope and cost of work, they’ve decided to bring you in to perform a deeper level of business analysis during the pre-sales phase. Your goal? To better understand the needs and expectations of the potential client to help your company deliver a more thorough statement of work, and a more accurate estimate of costs.

Win the deal but understand their needs wrong? Chances are your client will feel deceived and won’t be happy about being asked for more money – while your company will take a hit to their reputation as well as their bottom line.

But win the deal and understand their needs correctly? Chances are your client will be satisfied – and your company will only build a stronger reputation and bottom line.

Fact is, understanding the scope of work that will need to be completed for your potential clients is key to delivering a successful project once you do get the contract. There are few things more frustrating for a client then to sign a contract for an estimated cost, only to be asked for more money later on. There’s also nothing more damaging for the company asking for it.

So as the business analyst, how can you make sure your company get’s it right? We’ve got a few suggestions for you.

1. Gather Background Information

Before talking with the potential client, start to gather as much information about them as you can.

Talk to Sales. We all know how much sales people enjoy a good conversation – which is great if you’re an analyst looking for knowledge they have.  A great starting point for understanding the client is to talk to the sales person who has been dealing with them to date. Often your sales person can be a wealth of information for you to start with. They can help you to understand who the company is, what their vision is, what the company culture is, and possibly most important – give you a good idea of who the key stakeholders are that you can talk to.

Ask for Existing Documentation. Companies won’t always be willing to provide you with a lot of documentation before a contract is signed, but it can’t hurt to ask. Talk to your sales team for access to any documentation that has already been provided by the client, and make a request for additional documentation if possible. Focus on asking for documentation that will help you to understand their existing business processes, organizational structure, and stakeholders.

Get Surfing. The Internet can be a wealth of knowledge these days when trying to do initial research on a company. Your client’s website is the most obvious place to start, and also the best place for accurate information. Gain as much context and understanding as you can about them – going into stakeholder conversations with a foundation of knowledge about what they do is a great advantage to have.  Not only does it help you to have more productive and valuable conversations with the stakeholders, but it also provides you with more confidence to conduct them.

2. Understand Deliverables

Often the high level deliverables the client is expecting will already be established before you enter the picture. So before talking to the stakeholders, make sure you understand what deliverables your client is looking for. Understanding these high-level deliverables will help you to focus your conversations with your stakeholders in order to get more details.

For example, does your client expect training as part of the implementation? If yes, when you talk to them you can start to understand the scope of the training further: what type of training do they want – train the trainer, or full on group training? How many people will need to be trained? What training materials do they expect? Will it be on-site or will you need to provide training facilities?

And if there isn’t a clear understanding of the deliverables before you interview your stakeholders, be sure to make it a part of those conversations.  Too often assumptions are made about what a requested deliverable will entail – and too often it happens to be different than what was actually expected by the client.

3. Interview Stakeholders

Usually you will have access to at least a few key stakeholders to interview in order to understand what their needs and expectations are.

And this is the time to put your best business analysis foot forward; the conversations you have with your stakeholders and the information you can receive from them is key to setting up a realistic scope of work that later translates into a successful project outcome.

Here are some topics to focus your interviews around:

The Problem. Understanding the problems your client is trying to solve will help you to understand how the solution you have can help them. It will also help you to understand if the problem goes beyond technology and also includes people or processes as well; both of which can impact the scope, schedule and costs. For example, if during your conversation you are told the biggest problem is the amount of time it takes your client to make decisions and they believe your software will give them the right information to make better ones – you might also start to ask questions around what their decision making process is. Because after all, it may not be just a technology issue, right? And if it’s not, there is probably a bigger scope that needs to be discussed.    

Their Vision. Ask the stakeholders you talk to what their ideal world looks like once the solution is implemented. How will their jobs be easier? What benefits do they envision the solution providing? Is how the envision the future much different from how they operate today? Understanding the vision of the stakeholders will help you as analysts to understand what that gap is between where they are today, and where they want to be in the future – and how large that gap is. The amount of change being introduced into a company can significantly impact the amount of work you need to include within the statement of work. For example, if they are currently a company that operates largely on manual processes but envision a future of complete automation – that will take more than just a clean implementation of your software, that will probably mean changing their underlying processes as well.

Desired Features. Stakeholders understand features much better than they understand requirements; so focus your conversations around the features they are looking for in their ideal solution, and not the more detailed functional requirements.  Aim to understand how your company can make their jobs easier.  To keep your conversations focused, efficient and productive, start broad and slowly narrow your conversations down until you can start to understand in as much detail as you can what features they are looking for within each impacted business area.  For example, you can start with “What business areas within your organization will be most impacted by this new software?”  Let’s say ‘Finance’ was otheir response –  you can then ask “What are the most critical activities which take place within Finance?”, to which they might respond ‘Customer Invoicing’. With this activity now identified you can start to get into the features by asking “And for customer invoicing, what features do you see being most valuable to you?”. This will help you to start to understand what features they want versus what features your software currently has – and how the two can align to provide the customer with the benefits they are looking for.  If time is an issue, be sure to focus on the most impacted business areas and most valuable features. 

Assumptions. Too often assumptions are made about how the implementation of a solution will take place. When talking to the stakeholders, do your best to verify those assumptions or identify new ones. You want to understand what role they expect to play within the implementation, who the resources are you will be working with, if their existing technical infrastructure is sufficient for your software, what their expected timelines are, etc., etc. Especially important to understand are resources. As you interview the stakeholders, try to understand what resources they will be providing for you to work with and how much of their time they can provide.  Ask who the key stakeholders are for the business areas you discuss, how available they would be to you once the launch starts, and what their experience level is within the business area.

4. Send Out Surveys

Companies won’t always agree to it, but asking to send out surveys can help you gain broader insight into their needs. Keep the questions simple (last thing you want to do is annoy a potential client with a lengthy time consuming survey!) and relevant to the recipients. Give them an opportunity to identify existing problems and what benefits a solution will bring them.  You can then take those answers and start to think about how your software can help them to solve those problems, and provide them with those benefits – and how much of a change it will be to achieve that.

Using these recommendations – or as much of them as the potential client agrees to – can only help your company provide a more accurate statement of work to your potential clients in the pre-sales stage.  And the result? Besides winning the deal and establishing expectations you know you can deliver on, you as the analyst will be in a great position to continue your business analysis work post-sales.

1 Comment

  1. Great article. Perhaps you could help me with a scenerio I’m having difficulty with.

    Strategic Management wants to create a product set for a new segment of our business, Freight Forwarders. These customers typically receive a large number of payments per month from business associates both foreign and domestic. Some incoming payments will be in foreign currency, and others will be in the customer’s base currency. The project will be to create a version of our interface that meets the needs of this business segment and satisfies at least 90 percent of the following high level requirements:

    1. Customers will direct their business associates to send payments to Company X in both foreign currency and same currency.
    2. Customers require that their customers have a platform for managing their account information, invoices, payment details, and communications.
    3. Customers require a new “incoming payment” type, including confirmations of the type in 5 different languages.
    4. Compliance requires that funds that go into our customer’s account from these sources can only be held for 90 days (max) until they must be disbursed.
    5. Sales requires white labeling of the online interface.

    How do I respond with more than a use case scenerio? Is a BRD overkill?

    Reply

Submit a Comment

Your email address will not be published. Required fields are marked *