Software pilots are tricky endeavors. They are a crucial first step in the process of deploying an enterprise software technology solution. You don’t want to commit full tilt until you’ve tested a technology. Successful deployments have significant impacts upon companies, people and careers. You want to get it right.
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:
- How many customer interactions,
- How many client problems were solved
- How many new products were put into the pipeline
- How many tweaks to the customer engagement process were implemented as a result of customer feedback
- How much web page alteration occurs
- How many sales result from each communication
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.
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:
- Make sure you have your user community, your management and your software vendor involved in the project so they feel and act like partners.
- Solicit and gain consensus so you have a well publicized, measurable goal.
- Carry out the pilot within a short, defined time frame.
- Keep the lines of communication open to receive user feedback, to encourage adoption, and to publicize successes.
No comments:
Post a Comment