Tying BD Technology to BD Strategy

February 9, 2017

What’s the Point, exactly, of your BD Tech?

I co-presented at the LMA-Midwest meeting in Chicago last week. Our topic was “Tying your BD Technology to your BD Strategy.” Kate Cain, the Director of Market Intelligence at SidleyAustin LLP, and I prepared a six-step framework for #busdevtech projects.

In general, this starts with something that will appear to be common sense, but that is missing in a lot of business development projects. We need to approach our projects by starting at the finish. What do we want to get out of this? What’s the point?

Start by understanding the answers you need, rather than the stuff you need to track.

Step 1: Understand your strategy and your goals.
You should be able to clearly articulate the business reasons for your project. This is where the “what’s the point?” question comes in. What are our firm’s goals and our associated business development initiatives? What is the company trying to do? Once you and your business sponsors can easily answer this question in plain business terms – without referring to software or technology -- then you are ready to move to step 2.
Step 2: Identify your business objectives and initiatives.
These initiatives or objectives should again be documented in plain language – what is the answer we need to provide? with that answer, what decision will we influence? what behaviors do we want to encourage? Note that here, again, you are not talking about technology, and you’re especially not talking about configuration. Delay any conversation that delves into “what fields we want to track” and instead reframe the conversation to develop answers to these kinds of questions: what will you do with this information? what action do you want to take?
Step 3: Develop solution stories and use cases.
Now you are confirming your understanding of the business problems and anticipated solutions. You should ensure there is a narrative that clearly describes the strategies, goals, business objectives, and initiatives you’ve already identified. These should be documented and vetted by each of your stakeholders (people who will benefit from the system, not just the people who will use the system.) Keep in mind that different audiences within your organization will often be represented by different stories. As you write these solution stories, think about how the problem should be solved, and take into consideration your current state (how the problem is approached now.) Having a clear understanding of the process (business or technology) that you want to improve is crucial.
Step 4: Define your business and technical requirements.
You can use your use cases and solution stories to describe your business requirements specifically. However, you’ll want to augment those, and organize them, to include technical requirements authored by (or at least, approved by) your technology department.
Additionally, your requirements should also identify known process components – any solution that you’d implement will include process changes. It is imperative that you understand how your processes should look, and how your processes will change, when your objectives are achieved.
Step 5: Evaluate and select a technology solution.
Now you should start working with your potential technology vendors to evaluate potential solutions. If possible, avoid soliciting proposals that focus on features and functionality. Instead, share your vision, solution stories, and documented business and technical requirements. Include your documentation as it relates to internal processes as well.
Be sure to allow your providers to discuss your requirements with you, to ensure that they have a realistic understanding of the problem you want to address. Be sure not to skip this step; your vendors should have as much information as possible to ensure their presentations are complete.
As you move into demonstrations, focus your vendors on your specific goals, solution stories, and use cases. Ask them to show how their system would provide the answers you need. Be sure you understand how you’ll get the information that will influence the behaviors you need to influence. Your focus should not be on how you’ll track information or capture it; instead, focus on what you’ll do with it. Use this to make your decision.
Step 6: Implement the solution.
You’re nearing the end of your project. You’ve identified the people, process, and technology changes that your solution will support. Even with appropriate planning, it is likely that you will see scope changes as your team learns more about the solution. Evaluate each one against your objectives; if the change is not consistent with your goals, consider it carefully. Any change decisions should be deliberate and thoughtful.
As you’re marketing the new solution to your stakeholders and potential users, communicate the point of the project and tie it to the goals and objectives you’ve already compiled. Use your solution stories to publicize the changes.
Education here is critical, because the technical implementation is not what will drive adoption of your solution, ensure your firm gets the answers you need, or influence behavior. Instead, these things depend on your users accurately understanding the point of the entire exercise.

Finally, remember that your “deployment” date may be day 180 for you and for your team, but it is day 1 for your users.
Maintain your positivity and enthusiasm to avoid a negative first impression of the solution.

If these tips were useful, please feel free to download a printable version.