Six Questions to Help Set Up an Effective Pilot and System Rollout

Short on time? Read the key takeaways:

• Effective pilot and system rollout planning are critical to an organization's successful transition to embracing new technology.
• These programs need to be appropriately calibrated based on an organization's constituent entities and complexity.
• When running a pilot, you need a change management and communications plan that is also tested as part of the pilot.
• Based on learnings from the pilot stage, the goal of the rollout stage is to maximize the business value and efficiency of the final effort while minimizing risks.
• But what matters most is the employees' ability to use the solution to complete their work.

With change comes risk. But so does doing nothing and sticking with what's known and comfortable. Risk-averse organizations may delay changing legacy systems and encounter new challenges as a result. Instead, organizations must continually evolve and adapt to keep pace with peers, constituents and consumer and employee expectations.

As organizations replace legacy systems, the last mile of the project, which includes piloting and rolling out new systems, can be challenging and time-intensive, especially in the public sector. After all, when you have multiple agencies and various segments within those agencies, already challenging issues are amplified. But large commercial enterprises face similar scenarios as they roll instances out across a distributed and often global landscape.

How can you finish technology transformation projects while minimizing business disruption and revenue loss? By carefully planning and executing a successful pilot and rollout program. Answer these six questions to avoid common pitfalls.

Question 1: Is a pilot program worth it?

A pilot program verifies that a new system will function properly in real-world operating conditions for a small group of people or an area of an organization. They require significant user involvement and tend to extend the system rollout timeline. Is it worth it? After all, why not adopt the new system as soon as you achieve user acceptance and validate release readiness?

Pilots help to mitigate risk by letting you validate system functionality and go-live processes through an initial implementation on a smaller user population. These programs allow you to capture feedback through closer observation. You can use this information to update user support material, such as online help and job guides.

Considering these pros and cons, experience recommends you invest in a pilot. Similar to the "look before you leap" adage, pilot programs become especially important when the new system replaces an existing system and when the pilot is critical to prevent regressed functionality and undesired business disruptions.

Question 2: How do you plan the pilot?

Once you've decided to undertake a pilot program, you must define and internalize the pilot's objectives. These should be contextualized and customized to the specific systems you are considering. Example key objectives include:

• Testing the new system in a live environment with live data and real-time users within a specified duration
• Limiting the scope to end-to-end pilot scenarios that are reviewed and finalized with subject matter experts (SMEs) and other stakeholders before starting the pilot
• Aligning identified pilot scenarios with perceived business value in collaboration with business SMEs and other stakeholders
• Limiting the pilot exercise to a manageable end-user population
• Defining and articulating expected inputs from the pilot, which will inform the final rollout plan

In general, oversizing or under-sizing a pilot can prove detrimental to success, so it pays to be mindful when considering these key objectives.

Question 3: What type of pilot works best for you?

You can run a single pilot or a phased-pilot format. To choose the optimal approach, weigh it against the expected business value. Consider these aspects:

• Review the system components and determine if individual business capabilities with considerable size and business value are independent.
• Determine how extensive these independent business capabilities are in terms of planned implementation completion and user acceptance.
  • If the completion date is within a three-month window, the best option is usually to define a single pilot for the entire system.
  • If the completion date is more than three months out, consider a phased pilot that combines business capabilities completed at specific clusters.
• Identify business capabilities for each planned pilot and associated end-user population.

Keep in mind that in a phased-pilot strategy, the recommended number of pilots ranges from one to four. More pilots can become unmanageable, increase risks and diminish returns.

Question 4: Who should participate in the pilot?

Next up is determining which teams will participate in your pilot. Consider the capabilities to be validated and the end-users required to validate the capabilities. When determining suitable pilot participants, follow these tips:

• Select moderate-sized teams or agencies that do not have much need for further system customizations.
• Plan each pilot phase with an exclusive end-user population. This helps cover end-user diversity, increase familiarity with the system for more users and mitigate risks if a pilot phase is extended.
• Identify and communicate with pilot candidates early in the cycle. This helps mitigate risks in terms of competing business priorities and end-user availability.

When running a pilot, you need a change management and communications plan that is also tested as part of the pilot. The pilot is a great opportunity to ratify and get feedback on the communications plan before you roll the system out across the organization.

For example, it's always great to target communications to personas. For one MedTech company, we created a day-in-the-life-of (DILO) analysis to show how the system changes will impact their day-to-day lives. Such an approach makes it personal and ensures the change is "sticky." Our experience shows that investing time upfront enables a proportionate reduction in subsequent calls/issues.

Every pilot will be different, and you might have to adjust your plan. For example, when we ran a pilot program at a leading European telecoms company, we found that running pilots in one region was insufficient, so we ran multiple pilots to ensure that the user experience was not compromised.

Here's an illustration of a simple pilot plan:

Graphic 1: An illustrative pilot plan for a system with multiple independent business capabilities in a multi-region and multi-entity ecosystem

Remember that the more complex and widespread the new system is, the greater the need to diligently complete this step and inform all stakeholders to gain the necessary buy-in and support.

Question 5: What is your system rollout plan?

Based on learnings from the pilot stage, the goal of the rollout stage is to maximize the business value and efficiency of the final effort while minimizing risks. The "go/no go" decision made during the pilot is crucial to determine readiness for the final rollout. It should be an informed decision with business SMEs, program sponsors and other key stakeholders.

The pilot's key outcomes, plan, and candidates will be at your disposal. You need to align these with your system rollout plan. Consider the business ecosystem — especially if that ecosystem has multiple teams or agencies, segments within these teams or agencies with varying levels of customizations — as well as different phases of a system rollout. A successful system rollout plan requires a comprehensive approach that involves strategy, technology, people and operations.

When determining the optimal system rollout plan, consider the following segmentations:

• System ecosystem — by region or geography
• Constituent entities by size — small, medium or large
• Constituent entities by complexity — a combination of the degree of customization required, user population, expected transactions and user population finally impacted by the system

Also, consider the feasibility of a single rollout compared to a phased rollout based on constituent entity, perceived business value and associated risk. For example, if your ecosystem is complex and has constituent entities of different sizes, you might need to plan separate rollouts by the size of the constituent entities. This could look like this:

• For small and medium constituent entities, plan a combined rollout separated by complexity.
• For large constituent entities, plan phased rollouts by business capability separated by complexity.

Here's an illustration of a simple rollout plan:

Graphic 2: An illustrative rollout plan for small and medium entities for a system with multiple independent business capabilities in a diverse complexity ecosystem

Graphic 3: An illustrative rollout plan for large entities for a system with multiple independent business capabilities in a diverse complexity ecosystem

Consider planning rollouts across regions to ensure user diversity and early buy-in from regional leaders. However, rollouts could be planned by region and by further segments discussed above if regional considerations are significant and need to be handled separately.

Collaborating with pilot candidates and users is essential regardless of your system rollout. You can do this by aligning their familiarity with the new system with their ability to complete regular work using the new system.

Question 6: How do you adequately support pilots and rollouts?

Both pilots and system rollouts require many supporting elements to be successful. These supporting elements play a significant role in the success of the pilot and rollout plans. In addition to a functional system, these elements include regular communication and collaboration with associated entities.

When you're aligning your support elements, consider the following:

• Validation of overall readiness of the associated entities (agency, county or business unit) to support planned activities
• Adequate end-user training and familiarity with the associated business capabilities — typically handled as part of organizational change management and training features
• Adequate availability of extended support teams to assist with quick help, debugging and resolution of issues — typically handled as part of pilot support and hypercare or early life support

Keeping the most important parameter in mind

Pilot and rollout planning needs attention from the initial stages of a program to be successful. These programs need to be appropriately calibrated based on the constituent entities and complexity of the system's ecosystem. Continuous delivery and release readiness are immensely beneficial in setting up the required systems faster and on demand, increasing the agility of the entire ecosystem. But what matters most is the employees' ability to use the solution to complete their work.

For strategies to set up a successful pilot and system rollout program, contact Unisys.

Unisys has extensive experience deploying large-scale systems using pilot and phased go-lives to user populations. We typically create a custom pilot and rollout frameworks for client engagements to analyze various data points and determine the most effective pilot and rollout strategy. We leverage standard transition architectures that we develop based on lessons learned in rolling out various complex solutions. We have applied these transition frameworks to help enterprises worldwide achieve successful business outcomes.