I have a love/hate relationship with IKEA. Many times have I been seduced by the super-simple solutions I see in the showroom only to get home and find myself flooded with frustration as I try to decipher the assembly instructions that only a PhD engineer could possibly decode. Being the type-A personality that I am, I too often rush through the process of putting together my simple solution without scouring every little—and terribly important—instruction only to find my finished product resembles a particle-board Picasso possessing no functionality other than to serve as evidence of my failure. Eventually I go back and begin again, this time approaching my process methodically in hopes it will result in a more favorable outcome: a functional piece of furniture that looks so much simpler to put together than it really is.
In the several years since I’ve been helping companies implement new social media, marketing, and community initiatives I’ve noticed a similar trend. Too often well-meaning executives passionately embrace the next shiny object (or tool or program or methodology) and challenge their teams to rush through the process of implementing their big idea with record speed. This race to the finish line frequently skips the important steps that are required to ensure a successful project. And, sadly, the tool or program or project is deemed “unsuccessful” and discarded on the island of mis-fit and forgotten business initiatives.
It doesn’t have to be that way. There is a proven process that can help minimize some of the implementation headaches that often go hand-in-hand with new technologies or approaches: the pilot. Much like its Hollywood counterpart, where producers test how a new show will be received by the target audience, the technology pilot breaks down an implementation into a smaller group or business division allowing program owners to see how a larger roll-out might look.
When I’m looking to test a software pilot there are a few tricks I’ve discovered to help identify the right business group(s) to engage:
Position the pilot as an “exclusive” opportunity.
If participation is seen as a unique opportunity/benefit only open to teams that fit certain criteria, you’re more likely to uncover teams who will have greater commitment to the pilot. If you have budget to completely fund the pilot—or cover at least a portion of the costs—even better.
Create a standard application and call for participation.
Develop a list of questions to ask program owners that will help you determine which groups are a good fit for the pilot. Require all who are applying to answer standard questions like a few I’ve listed below. Questions like these can go a long way in weeding out teams that are not fully prepared to devote the resources necessary to test the pilot.
- Do you have a dedicated technology partner to help with implementation?
- What resources (budget and people) will your team make available to support this pilot?
- Is there an executive stakeholder on your team who will be prepared to act as a champion if the pilot is successful?
- What business value could this pilot bring to the company? For example, the desired outcome from a sales pilot would be a faster time-to-sale, thus contributing to the company’s overall bottom line.
Make business value (money made, time saved) a top priority.
Business value is an important consideration when running a pilot as it (hopefully) provides the best and fastest way to test the ROI of the impending implementation. Obviously it will only be a sample since the true cost of a wider-scale implementation can only be realized after a broader roll-out. But it can go far in demystifying the new platform and demonstrating how this new way of getting certain work tasks done—or engaging with your customer; however you’re planning to use the software—can provide tangible benefits to the company.
Require pilot teams to become advocates upon successful completion.
One of the greatest ways to build enthusiasm in your workforce for new technology or processes is to “wow” your pilot team and then let them loose to brag about their success, ad nauseam. In terms of inspiring greater adoption no corporate edict or executive mandate is as effective as showcasing the success of pilot teams and asking participants to share their stories with their peers. In essence you want them to shout about their positive experiences from the rooftops. Honestly, this is truly the secret sauce of widespread adoption.
Pilot projects are by no means exclusive to a Jive Software roll-out or even a software implementation in general. I’ve seen this methodology work successfully for kicking off a variety of new business processes or ways of working. In the end it’s all about failing, improving, and succeeding quickly and on a smaller scale to help pave the way for larger and more enthusiastic adoption. And since change can be hard—even for the most nimble organizations—proven successes can more-times-than-not make the difference between a project that’s fabulous or a flop.
Of course pilot projects aren't without their own challenges, which I think is inherent in the process itself. After all, if you aren't failing you aren't learning. So I'm curious; what have been your experiences with pilots, software or otherwise? Do you have any tips to share on how you kept your own pilot projects on track? Do you have specific metrics you've used to help you determine whether or not your pilot was successful?