Buying Software 101: How to Design a Kickass Pilot Project

Posted by Josh Weissburg on May 14, 2015

pilot-620432_1280

There is a lot of cool software out there. The question is, will it actually help you do your job better? Since the money likely isn’t coming out of your pocket, you have to figure out how to get team members, finance and execs to see the value in what you see. Your best bet? Design a pilot program that shows them the value.

What is a pilot?

You have your eye on some potentially life-changing software. You know it's going to be hard to convince your company to buy it. How do you do it? By showing real value with a live pilot - a test that shows the software operating in the real world in your business.

What do you get from a good pilot?

You get evidence! You, your team and decision makers will know what it's actually like to use the software, not just what you imagine it would be like or how the sales rep positions it. You will experience the value firsthand so the value (or lack of) is apparent.

8 Steps to a Kickass Pilot

Just as you plan any strategy, you must also plan a pilot. This is your chance to prove to decision makers why this software is needed so don’t ruin it with a haphazard test. Here are a few steps you should consider as you plan and execute your pilot program:

1. Start at the end, with what you need to learn. Write this down and make it measurable.

Have the end in sight before you begin. What is it you are hoping the software will do for you? What metrics can you use to measure? More conversions? Efficiency and productivity measured in hours or headcount? Reduction in steps required to complete a process? Improved customer or employee satisfaction? Put some numbers to it so you have hard evidence how the software will benefit users and ultimately, the company.

2. Get buy-in around these goals: they must matter to your team, not just to you!

The people who will be using the software have the most to gain by it so make sure you include their input (if it's not you using it) into what matters most to them when you are determining goals and metrics. Convincing them how the software will make their lives easier should be top priority so you can build a team of advocates instead of going at it alone. Remember, there’s no “I” in TEAM.

3. Only ask for what you need to get to the pilot goal you agreed on - don't "boil the ocean" - it's a pilot.

Don’t get too ambitious for the pilot. Start small by choosing what matters most to your team and setting pilot goals to meet those needs. The pilot isn’t intended to be a comprehensive illustration of everything the software can do for every person who will be using it - it's just a sample of what it can do.

4. Test the edges of what you need - think about extreme examples, not simple ones.

This is a stress test for the software to see if it can meet special use cases that your business has. Good software is focused on a particular problem; by testing the more complex versions of the problem you need to solve, you will make sure that the problem the software is solving overlaps sufficiently with the problem you're trying to solve. For example, if you send five different triggered emails to customers, but one of them has complex logic (i.e. send to premium account holders who are admins on their third purchase), test that one first if it's important that your software does it.

5. Document what you did, and how long it took.

One of the most powerful things good software tools do is increase the speed at which your team can operate. By documenting every step you take during the pilot, you can compare if and how much time your team will save if you switch to the new tool. You may be running the pilot, but other people will probably use the software too, so this documentation will help other people get going as well.

6. Evaluate for you and for your team.

You can’t speak for the whole company but you can measure the results you and your team experienced in terms of time and resources it took to pilot the program. You can also evaluate the software in terms of processes compared to what you already do. Were there efficiencies? Did it decrease certain process requirements or make your job any easier? Is a full launch worth it? Who is poised to gain the most benefit?

7. Make a decision based on whether you achieved your goal, how hard it was to achieve your goal.

Decision makers may not be the people actually using the proposed software and if they’ve given you enough rein to pilot the software, they likely are interested in how you thought the software performed. This is where the metrics you set up at the beginning come into play. Did the software meet the goals set? Did the software make meeting those goals easier or harder? Would you and your team members give it a “thumbs up or thumbs down” and why? Frame those metrics with a clear explanation to help execs understand exactly why the software is investment-worthy.

8. Communicate your rationale to your team so they'll support the new software.

You should have all the facts now but don’t keep them to yourself. Bring your team into the fold so they can advocate along with you. Write an email or Slack message with a summary of the decision process. Making them part of the decision will not only boost your case, but will help in future adoption of the software once it is fully launched.

Bonus: The best software is the tool that is actually used

It's worth a small footnote to state something seemingly obvious but strangely hard to enforce: even the best tools, if they're not adopted by your team, are useless. That's why many of the steps above focus not just on evaluating the software but also on helping your team to understand if and why it's valuable to them. Remember, you're not just testing against a spec - you're trying to build a new habit for your company, and new habits are hard!

Topics: Best practices