If you face an opportunity, should you jump? Our advice is that if the change would require any significant resources or pose significant threats, prepare first using a pilot program. In a prior post we discussed logic models for successful piloting. This post takes the next step by providing a blueprint for a successful pilot program.
A phased implementation, or pilot program, can help your company measure the success and overcome issues prior to formally launching on a broad scale. The smaller test process can give you the flexibility to adjust your processes or even abandon programs that aren’t delivering the results you want. Here are some step-by-step guidelines.
After creating a logic model, every pilot program should start with a proposal. In it, you should list:
- Program objectives. What are the specific outcomes you intend to accomplish?
- How the program will be implemented. What are the specific steps you plan to take, and in what order?
- Timeline. When does each step occur?
- How you’ll measure / what constitutes success. How will you gather and measure data to gauge whether the program accomplishes its intended objectives?
Pilot programs start with the state of things before the change, progress to the point where the change is implemented, and end with the results after the change was made.
The Training Element
Next, look at your personnel. Who is in charge of this pilot? Who will make sure the change is put into place and followed consistently? Will you need to train them? If it’s a simple change, such as requiring a new piece of safety equipment, training may be minimal. You’d need someone to oversee the department to ensure the new equipment is being used consistently and properly. Other changes may require more in-depth training. Typical training covers how to use/perform the change, what documentation is required (and how to properly document), and where to get help when problems arise.
The Monitoring Phase
Once you’ve figured out who’s involved and how, determine how to monitor results. Your pilot team should know how to react to problems, including who the primary program contact is, how to track any changes/improvements/glitches, and documentation of problems (including when to bring them up with the contact person). The key here is to make sure any issues are documented as they occur, and in detail.
Your pilot program should include evaluation not just at the end, but throughout the test period. I recommend holding regular meetings with the pilot team to go over documentation, get feedback, and build both best practices and lessons learned, if applicable. How’s the new change going? How is it being received? What’s working and what isn’t? Where can we improve? How? What issues have arisen that could affect the ability of the program to scale up? Each step in your evaluation is a chance to work collaboratively on ways to make the pilot work.
Consider incorporating anonymous feedback processes. Either on your company website, in an email drop box, or on paper, feedback given anonymously allows for more open, honest dialogue. Your anonymous tipster may hold information critical to the success or failure of your project.
The Ongoing Process
At the end of your test period, you can decide if the program is a go or a no. If minor revisions are required, discuss how to implement those. If it’s a major overhaul you need, plan it out. Get feedback from your pilot team and from the people most affected by the change. What solution comes out of those conversations? Will these major changes address the problem? How can you revise the original change, and will that address the original issue?
If you need to, conduct another pilot program. Your pilot process should be one of continuous improvement and tweaking. If additional analysis is necessary, don’t be afraid to try another test. Nothing beats data when making decisions, and data gathered before scaling can critically impact the success of larger initiatives.
If you found this post useful, please share it.