The Top 6 Ways to Guarantee a Successful Enterprise Software Pilot

Whether you call it a pilot or a Proof of Concept (POC for short), Pilots may be 'tricky' but there are 6 crucial steps to take to optimize your chances for success

• Your software vendor partner can be your best friend. Software vendors love pilots. This is because they believe that once the software is in, it isn't coming back out again. Plus the vendor will have their people on site for the term of the pilot, ideally lobbying on behalf of flipping the pilot into an ongoing license. The upside of this is that most software companies are not in the pilot business'.they're in the annual license business. This means they'll be working hard to help you make the pilot a success.

This might be your first pilot of software of this type, but your software partner has gone through many pilots. They have accumulated a number of best practices they can share. They have the benefit of hindsight where they have seen the pitfalls where other clients have mis-stepped. They can monitor the progress of your pilot and provide ongoing practical guidance to keep your pilot on track. Of course everyone needs to agree on what that course is, hence the fact you should have a measurable goal for the pilot.

• The most important attribute of a successful pilot is to have a measurable goal. That might seem obvious but so many neglect to attach one to the event. I have heard of lots of pilots of enterprise social networks where there is no defined goal.

You can't just throw it out there, see who uses it and hope for the best. Because if you do, you'll get some early adopter types (those who enjoy using new technologies) to embrace it and no one else. And even those early users will stop using it after a while if they don't see others jumping in or if they don't see results. And senior team members won't touch the software at all. They're afraid of it to begin with; are not anxious to learn something new, or for that matter to share anything, anyway.

When you do define the goals of the project, consider asking everyone on the team for input. Establish the success criteria for the pilot, with input from all stakeholders. Your chances for success are increased if not only do you achieve your goals with the pilot, but that everyone who participated in the process agrees those goals were meaningful and important.

A measurable goal lets you monitor the progress of the pilot and if you're not hitting the mark, adjust your strategies to get on track. It might be something as simple as measuring Adoption Rates(how many people are using it) or Engagement (the number of Contributions). You can measure both activity and results. Here are some examples of measurable results:

But measure something. Because when the pilot is over you want to be able to answer the question: 'Was the pilot successful'? with statistical results.

• You should get the right crowd involved in your pilot. I think we all can identify those 'usual suspects' when we think about who would embrace new technologies. There are always 'early adopters' you can rely on to try out the software. If you're clever you can make certain these early adopters are spread throughout the organization into various geographies, departments and disciplines. They can act as ambassadors to other users. If the early adopters are advocates, you can exponentially grow your user community.

Advocates or ambassadors can serve as support, trainers and cheerleaders. Equally they can provide feedback from the troops back to those responsible for managing the process.

Plus the users during the pilot can be your biggest supporters during roll out.

You should probably not limit your pilot to just a small number of users in one department (the usual inclination). You want to optimize your chance for success. This is a situation where rewards outweigh risks. Frequently champions for software want to limit the exposure of the pilot to their own department so if the pilot fails, the exposure will be minimal. But this can be a case of when a preconceived notion of failure might better be supplanted by a manifest destiny approach for success. You want a positive outcome; why not take every measure you can to ensure success.

• You should constantly market to end users and management. This means training, newsletters, email updates (with call to action links taking users into the system). Management and users should hear good news and about successes.

You should not only collect usage data, as well as the output of the software, but also the feedback from the user community about how to improve the software for eventual roll out. Simple items like 'I wish this link or item was on this screen' or 'It would be easier to use if'' can inform the success of the actual and eventual roll out.

• The time frame is critical. You should keep it short, perhaps thirty to sixty days. People will operate more effectively with a deadline. Six months is way too long, long enough to have user interest ebb without the payoff of additional data accumulated. Plus this helps subscribe to the notion of 'fail fast'. If the pilot is a mis step, then get it over quickly so you spend the minimum amount of money on it. Similarly don't allow 'scope creep'. You'll get lots of suggestions from the user community which you absolutely should collect for consideration before roll out, but don't let it slow down the pilot effort nor more importantly steer you away from achieving those measurable goals.

Along with timeline and goals you should also add other rules. Think about what you want to achieve with the pilot and keep everyone within those parameters.

• The next most important attribute of a successful pilot is senior management support. Of course you need a champion. This is someone on your team who is a 'believer', who understand that using this software will improve your organization. This might be you! But if that champion is not senior enough, then you need a 'higher-up' to buy in.

How important is this step? Let's put it this way, the very best pilot kick off speech I ever heard was when a Vice President at a Fortune 100 company got all the potential users in a room (some of the virtually) and merely said, 'OK, thanks for coming. I want you all to use this new software. Dependent on the success of this project, my job is on the line, and that means yours is too. Login, ask for help, start using the software and make this a success.' Everyone got the message, there was a flurry of activity immediately and the project was a huge success.

Conclusion:

1. Make sure you have your user community, your management and your software vendor involved in the project so they feel and act like partners.
2. Solicit and gain consensus so you have a well publicized, measurable goal.
3. Carry out the pilot within a short, defined time frame.
4. Keep the lines of communication open to receive user feedback, to encourage adoption, and to publicize successes.