Home > Blogs > VMware SMB Blog


Business Speak: Talking the Talk to Get Dream Tech Projects Funded

- Post by Chris Westphal, VMware, SMB Products & Solutions Marketing Manager

So you’ve found the latest [INSERT PRODUCT TYPE] that has the most [INSERT FEATURE] per [INSERT METRIC] and you can’t wait to get your hands all over it. You’ve combed through the specs, read the reviews and have gotten feedback from your fellow Spiceheads. You’ve even priced it out and, if you had the budget, you’d pull the trigger in a second. The only problem is that nobody at your company gets it. Nobody seems to be as jazzed about this new technology as you. Sound familiar?

Why and who?
Sometimes IT pros can get so excited about new technology that they forget to look beyond what it does and consider why their company needs it in the first place. Thinking about “why” is the first step to getting your project funded so you can actually put that cool technology into practice and start reaping the benefits.

In addition to “why” another just as important consideration is “who” — as in, “Who do I need to convince?” and, “Who is it that is going to give me the go-ahead and budget?” The “who” might be a single person or it could be several people across your company who collectively need to come together or influence each other to make the final decision.

Thinking beyond “what” and focusing on “who” and “why” is a great first step to putting together a business case to get approval and budget for your IT project.

Building the business case
Sure, that technology is pretty sweet and you see how you’re going to be able to use it, but that’s not going to be enough to get your manager, VP or CFO to free up the cash to let you make the purchase. Remember, you’re not the only game in town, and there are others vying for those same budget dollars (or Euros or Yen or Pounds or whatever). The question is how do you stand out by building a compelling business case to justify the need for your purchase?

Let’s first consider what’s important to your company. This is the “why.” Is it keeping your website up so that revenue keeps coming in? Is it making sure that the schedule to deliver that next killer product doesn’t slip? Is it finding a way to help your team drive down cost? Any of these could be top priorities for your management. One way to think about it is to consider how the investment is going to help your company:

  • Make money
  • Save money
  • Protect you from losing money
  • Do something that they couldn’t do before

Now that you have “why” in mind, thinking about “who” is going to help you focus and fine-tune your story. You need to know your audience in order to develop and deliver the right story to them, right? For example, if it’s your CFO it could be protecting the bottom line, so something like highlighting potential risk to revenue and how you can protect against a particular set of threats might be an approach that really resonates here.

Talking to Jeff Dean, who is CFO for Spiceworks, he says: “I like to understand who (or what) is impacted and what that costs us per hour. You can determine meaningful ROI simply through rough computing and determine either, (1) what you’re losing in productivity, or (2) what you’re losing in revenue. Beyond that, we consider whether a system going offline could potentially impact client or user relationships, as that quickly has a very high cost.”

As a rule of thumb, remember that people at all levels are busy, so having a pitch that is well thought out, clear and concise with a strong recommendation should yield the best results.

You may have collected a lot of data and information as you build your business case, but when it comes to delivering your pitch think about providing an executive summary of your findings with the option to read the bigger report if more details are needed.

An executive summary can be a written document, but consider a short presentation. Slides that can be covered in 15–20 minutes will give you enough time to present your business case and leave time for Q&A in a 30-minute meeting. Here’s a sample outline of the information that you might consider including in your deck:

  1. Problem — What is the issue we are trying to solve?
  2. Current risk — What is the risk if we don’t put a solution in place?
  3. Proposal — What is the proposed solution?
  4. Total cost of ownership (TCO) — What is the cost of the solution including HW, SW, licensing, recurring, people, support, etc.?
  5. Return on investment (ROI) — What is the expected result from implementing the proposed solution and when do you expect to realize it? (money saved, business protected, etc.)
  6. Project risks — What are the dependencies? What are the things that you control and what are the things out of your control that may create a challenge for the project?
  7. Next steps — What is the action that you’re asking the approver to take, and what are the recommended next steps for the project?

Example business case
At SpiceWorld in Austin back in October I did a session with Darren Schoen (aka Spankmeister) called “How Virtualization Can Help Save Your Bacon.” In that session, Darren did a great job of showing how he would justify the purchase of a solution to help protect his site from downtime.

Darren works at the Broward Center for the Performing Arts, and when tickets go on sale for a show, it’s important for their website to remain up and functioning so that they can sell tickets and bring in revenue. An outage would mean a potential loss of revenue, so the focus for his case was to justify a backup and recovery solution to his CFO. The numbers for his case looked something like the following. (NOTE: These are not actual sales numbers but just an example for the sake of this explanation.)

  • On a day when tickets for a popular show go on sale they can generate on average $100K in 14 hours.
  • If you break this down that works out to be about $7,143/hour.
  • If an outage took down their online box office, the estimated time to recover was 10 hours, meaning the potential risk to revenue was over $70K.
  • If the solution being proposed came at a cost of $20K and knocked recovery time down to 1 hour then the numbers would look like this:
    • $20,000 (solution cost) vs. $70,000 (risk to revenue) — That’s a delta for $50K.
    • NOTE: There is still potential of $7,143 risk to revenue with the new setup, but that’s much better than the original $70K.

Understanding how much revenue was at risk as well as the cost of the proposed solution and taking into consideration the other details that Darren would provide around the project, the CFO would now be in a good position to make a decision. Is he not willing to commit the budget and potentially risk the revenue or does it make sense to invest in the solution and sleep soundly knowing that they would be in good shape to recover quickly in the event of an outage?

Wrap up
From budgets to business drivers, each situation and each company is different, and there’s no one right or wrong way to do something like this. What may work at one company may not resonate at the next. Keeping in mind what is important to your company — knowing what motivates those who hold the budget will get you moving in the right direction when it comes to building your business case and getting commitment for your project.

I hope that this has given you something to consider as you think about that next IT project that you’re excited about. While this may be new waters to tread for some, I’m sure there are SpiceHeads who have gone through this many times.

 

If you’re a veteran, tell us about your proudest accomplishment as you tried to secure funding for a project you were passionate about. What has worked in the past and what did you learn for next time? If this is new to you or you’re just looking for a way to fine-tune your skills, don’t hesitate to ask your questions below.

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>