The buying process for software sometimes includes some type of trial or pilot to verify that it will meet your intended business need. This process usually comes after there has been a considerable amount of research, and perhaps involved conversation with various vendors. Software demos have been held and existing customer stories explored. You've narrowed down the list of potential options and have chosen the front-runner. Now it is time to pilot.
Depending on the scenario, pilots do cost you – in addition to perhaps licenses, they cost you time, mental focus and potentially credibility points with those you ask to participate. In business, anything that requires an investment on your part deserves a return.
So what is the expected return on a pilot? The acquisition of the piloted software, of course.
If you are going to make the investment of time, energy, focus and dollars in doing the pilot, your objective should be not to just spend time getting to know the software, but also in engaging in the necessary activities to move to the next step in the buying process.
There is a straightforward pilot process that can help you accomplish just that.
1. Strategize: The first step is to build a strategy for your pilot.
Strategizing for your pilot should not be a long, drawn out process. It should be a thoughtful one that will help you with your purchase decision at the end. You should strive to accomplish two things:
- Establish the business objectives of the pilot
- Determine the success metrics, i.e. if these things are proven by the end of the pilot, you are going to purchase the software
2. Design:Determine what the pilot will look like.
It really is insufficient for you to merely ask a few people (in some cases hundreds of people) to “play” with the software for a while and tell you what they think. In most instances, the software is not yet a part of how people do business. Therefore, they are likely to look at it briefly at first because it is something new and shiny, and then ignore it until you ask for feedback on the last day of the pilot. When you do ask for this feedback, it is likely to result in a broad mix of things that may or may not be at all relevant to the purchase decision.
Instead, you want to take the time to explicitly determine what the pilot will look like:
- Identify a specific set of tasks you want tested during the pilot to help validate the objectives – Keep it simple, this will ensure success, while gaining momentum.
- If relevant, spell out how the software will be configured to support these activities
- Decide how feedback will be gathered as people execute the tasks. An iterative approach is much more meaningful than “hurry up and submit your eval forms”
- Keep it short. Is there really a reason why a pilot needs to run past 30 days? Sometimes yes, but often times you know what you need to know in a relatively short timeframe. If you keep it short and meaningful you can move on to reaping the business benefit sooner.
3. Pilot:Execute the tasks as designed.
Now that you’ve strategized and designed things, it is time to implement your pilot. This should be an iterative process:
- Execute the tasks
- Gather feedback and measure the success
- Make adjustments to the process or software as necessary
- Iterate on tasks again
4. Validate:Make a determination of your success.
Because you started the process by determining what success would look like before you started, you and the other decision-makers should have an easy time determining the success of the pilot. Based on data gathered during the pilot phase, you should be able to document your success. (I’m not even entertaining the idea of failure here since you were able to iterate during the pilot phase to make any corrections necessary for your success at this point.)
5. Purchase:Reap the reward of your investment in the pilot.
Not only do you now have the reward of bringing your software purchasing process to a close, but you also have a built in set of change agents to support its implementation in your organization. The people who participated in the pilot have a clear understanding of what the software can do, and how it can add value to your organization as determined by the business objectives you originally set. They are both equipped and likely predisposed to encouraging others to adopt the software in the manner you intended.
The next time you consider piloting software, remember that your reward comes from purchasing. Design your process in a way that will pay off for you.
[Thumbnail plane image source:] Big Stock Photo