November 18, 2021
by Sanji Bhal, Director, Marketing & Communications, ACD/Labs
Software pilot programs help you ensure that new software will meet business goals and add value to your workflow. Your organization can test software on a small scale before making a large investment. Key stakeholders can then understand if the software is viable.
What is the difference between a software pilot and a trial?
While different software vendors may have their own definitions, our distinction is the following. For a software trial we provide a licenses(s) of software for you to evaluate in your environment with your own data. Pilot engagements are typically for enterprise software deployments that may require workflow alignment and/or configuration or customization. A pilot allows you to evaluate out-of-the-box functionality of our tools with proof-of-concept for configuration/customization pieces. This allows you to make decisions about the fit and value of the solution without the cost and time investment that complex integrations often require.
I spoke with colleagues who have guided numerous customers through a variety of pilots, to learn from their experience: Karim Kassam, Senior Director of Customer Success, Scott MacDonald, Director of Strategic Accounts, and Sarah Brooks, Director of Commercialization, answer four questions you and your organization should ask before engaging in a software pilot.
1. What can we expect at the beginning, middle, and end of a software pilot?
Brooks: At the beginning, organizations need to ensure all stakeholders, SMEs, IT, and business personnel agree on the common goal or vision. Having a vision ensures everyone brought into pilot meetings will understand why their opinion, time, and energy is critical to the pilot’s success and ensures that important activities, such as training, can be tailored to meet the objectives.
For more complex pilots, organizations should consider working in phases and determine who needs to be involved in each phase. Success criteria should be written down and agreed upon. It can be adjusted during the course of a pilot but it’s helpful to baseline it at the start.
MacDonald: The middle of a software pilot is where organizations should check in to see the progress towards the goal and if the program is on track to meet the goal. These insights should be communicated and addressed in real-time. We typically recommend weekly check-ins to collect feedback so stakeholders have the opportunity to explain what is working well and what may not be.
Kassam: The end of a software pilot calls for following up with the customer to ensure they receive the desired value from the software that matches the return on investment identified at the start. We also take time to discuss lessons learned, anything that may have been missed, or brainstorm how to adjust in the future. The discussion then leads itself into moving forward with the software or extending the pilot for further evaluation.
2. How does the size of my organization and complexity of the software impact the software pilot?
Brooks: Organizations need to determine the specific group(s) the software will impact. There’s a sweet spot of having enough people in software pilot meetings to make decisions while not having too many people overwhelm the project. As a vendor, ACD/Labs always looks steps ahead in the software pilot to make sure the foundation is set to build a business case, set expectations around change management, and understand the levels of integration the business needs. The size of the organization, complexity of the software, and the number of different teams that will use and support the solution can determine how many individuals are involved in a pilot on the client side, but our team is fairly consistent. We involve colleagues from development and professional services, along with an application scientist, account manager, and project manager for all our pilot engagements.
Kassam: At ACD/Labs, we give full support to all of our customers regardless of their size or existing software. We offer more 1:1 personalization opportunity for complex pilots; however, our customer success team provides access to resources, training, technical insights, and more support whenever needed. A pilot is a partnership, so we always look to provide the information that sets us all up for success.
3. Who from my organization needs to be involved for a successful software pilot?
Brooks: An effective pilot builds the foundation for deployment so it’s helpful to think of the diversity of the users involved. If you let the users self-select you can end up with an over representation of one group or mindset. Having the right group involved in the pilot can set an organization up for a smooth deployment by having a network of change agents in place to help with the change management. I encourage organizations to involve a few thoughts leaders even if they have some reluctance towards the adoption of new technology, because their buy in will pave the way for a smooth deployment.
MacDonald: Ultimately there needs to be a lead or primary contact in your organization facilitating activities and keeping the project on task and moving towards the goal. This could be a project manager, lead user, or a champion—someone who knows your organization and problem you are trying to solve— to work closely with the vendor for balancing people and workflows; ensuring the feedback is understood and prioritized. Pilots can generate a lot of feedback and a strong lead is essential to making sure it’s understood, prioritized, and actioned effectively so the pilot doesn’t lose momentum.
Kassam: Management support for all functions involved, including IT, is huge because they understand the higher level goals within your organization. Implementing new informatics tools can require process and or organizational changes, so it’s important to have buy-in at all levels. As a vendor we rely on management giving team members the time to participate in a software pilot because sometimes the time commitment can be substantial. For the management team to invest time and resources in a project, they need to see its value and how it aligns with the overall company vision. While they may not be the day-to-day user, they can be a powerful influence on the success of new informatics deployments.
4. How do we navigate customization requests?
Brooks: It depends on what your organization wants to achieve in the pilot. When organizations are transparent in what they want to address with software and its specific use cases, the vendor can spend the necessary time on a detailed design. This detailed design describes use cases so the IT team can share specific capabilities and ecosystems—ultimately so the vendor can bring forward the best solution. It’s a candid conversation to meet as many needs as possible.
MacDonald: As an account manager, I operate in a consultative capacity, as do my colleagues. We want the customer to be successful, so we typically recommend no customization because it can result in spending a lot of money on something they’re not already using. When it comes to customization, organizations need to determine if it’s something they must have in the pilot to gain experience with the software.
Kassam: For customization requests, we typically illustrate what the customization will look like. Instead of programming and building custom integrations to align with customer workflows , we’ll create visualizations to demonstrate what the software will look like and its capabilities. We can then have conversations about what works and what may need to be adapted. This upfront work is important to meet expectations while achieving the goals set at the beginning.
To learn more about software pilots, or to request a software pilot for one of our solutions, contact us.
About the Author
