It’s time for a change but how do you know that change is right for you at this time? Run a pilot. Here’s how to run a successful one.
Like all good boy and girl scouts, be prepared
View a full product demo with as many of your team members as possible. This serves two purposes:
- Seeing the full capabilities and features that you’ll earmark to test during your trial.
- Build a relationship with the vendor so they can understand your needs and why you’re seeking their product.
Tip: During the demo ask: what technology is best (for example, which browser to use for best performance), how to contact their support team during the pilot, and if there are any domains to to ensure notifications and data traffic filter through optimally.
Be prepared, again
Decide which features to zoom in on during your pilot – if you can, have a list of core features and secondary ones so everyone is clear before the pilot begins on where they should focus their efforts.
If you’re running through different scenarios, assign roles to your team members and ask the vendor to divide the initial training up specific to the different roles. This will ensure the utmost success of the pilot and adoption of the software moving forward.
Give yourself time to get the pilot right
It’s important to understand the difference between a trial and a pilot. A trial is typically 7, 14 or 30 days and it will let you quickly decide on which vendor to engage a paid pilot with. A pilot typically lasts between 3 and 6 months – any shorter and your team is still learning the ‘how’ of the product rather than spending enough time experiencing the ‘why’.
Let the vendor know how long you intend the pilot to run for, then lock in initial training and commit to a date that you want to move from a paid monthly to your license plan.
Tip: Near the end of the pilot, begin to arrange purchase order numbers and anything else you need to ensure a smooth transition to an annual license.
The pilot team: Maverick, Goose, Snoopy, Biggles…
Look for team members who:
- Will be available during the pilot (there’s no point in asking Jenni who’s off to Fiji on her honeymoon).
- Will be the end users of the software and will make great champions to drive it through the wider organization.
- Are good communicators. You want people who can give constructive feedback, not ask to change the color of the software to Pantone 18-3838 Ultra Violet because they heard it’s the trending color of 2018.
NPS before and after
Knowing what success looks like for your team is essential for a pilot. Before the pilot begins, use NPS (net promoter score) on the team and wider organization about the existing process – this will give you a good baseline about the problem that the software is providing a solution for.
Towards the end of the pilot, NPS the same team. If the score post-pilot is 6 or under, probe for feedback – it’s important to decipher whether the satisfaction score was caused directly by the software, or a misunderstanding of the pilot process.
Tip: If there is any doubt post-pilot, run an A/B test: ask the team to do it the old way, then again using the software. What did the team enjoy about the change? What did they not? Often frustrations can be caused by the muscle memory associated with that age-long inefficient process that you’re changing, and that’s OK – muscle memory can be changed over time.
Go forth and conquer
An experienced vendor will have just that – plenty of pilot experience that organizations similar to yours have undertaken. You’ll learn from them and vice-versa so jump on to that screen-share or phone and dive right in.
Marcus Radich – Co-founder of PageProof