- Confirmed Benefits
- Risk Management
- Stakeholder Management
- Pros and Cons
- Issues faced with piloting
- Keys to a successful Pilot
We start with the assumption that every transformation project is only be considered for some perceived benefits gained or realised from it. This is often a subject of great debate within organizations when they struggle to understand or quantify what exactly are those benefits and when should they expect them.
A pilot project is a handy but sometimes vital opportunity both discover and validate whether or to the degree that both the final product or service, and the implementation method (to implement the end solution) would realise or start to realise those benefits through limited-scope applications.
However, although it is important that the scope of the pilot is reasonably large or to the scale that it is representative of the full scale of the business transformation, it should be tested on a small population of total Users and End Users as to not affect the whole organisation, should it all go wrong.
Regardless of the nature of an organization, there is always an element of risk in implementing something new. This is true whether the change is implementing a new process or new technology. Risk is always a major factor in these circumstances.
A pilot is an opportunity to implement the solution in a limited manner so that any adverse fall-out can be kept within restricted boundaries without affecting the whole organization.
After the execution of the pilot, the anticipated or perceived risks at the beginning of the project can be more accurately identified now in relation to the whole planned transformation.
The biggest obstacle to change is not process or technology, it is employees. We covered this is another post. Piloting is an effective stakeholder management, and stakeholder expectation management tool, albeit it can be lengthy and costly. Pilots helps stakeholders with the ‘seeing the unseen’. People, by nature are risk adverse, and not like change, so piloting is a way to address this by allowing them to “believe it (i.e. the solution) when they see it”.
No amount of “selling” of the solution to them with the ‘description’ of the benefits, statistics or ROI is arguable more effective than seeing the results by being involved in the pilot themselves; reported from those involved (fellow team and/or staff members) or ‘champions’ of the transformation itself.
In a nutshell, the table below summaries some of the aspects the pilot aims to address:
In spite of these obvious benefits of piloting, there is a general perception that the additional time and cost incurred on testing the solution could have been put to better use in implementing the transformation.
Pros and Cons
The point then is to see whether to pilot or no-pilot. The pros and cons of piloting have already been seen here. To decide which step to take, the pros and cons of full implementation need to be investigated. Unfortunately (depending on your risk tolerance, and your organisations appetite for risk), to go ahead without a pilot is to proceed with the full implementation and process of transformation without testing the implementation, and final solution in the Organisation, with the market and customers beforehand.
The advantage here is the potential to be a (relatively) quicker implementation as there is no testing (i.e. pilot) phase required. This option is more suited when there are time constraints to implement quick(er); the Organisation has previous experience in similar transformations they are confident in their solution they are implementing, the method or approach they are using for implementation, or have successfully done a similar transformation of the same or similar scale and complexity before.
On the flip side, there is a possibility that the full operation of the implemented capabilities does not go through as planned and this will lead to lost time, money, and resources. There is always a high risk of both operational and implementation risk when ‘no-pilot’ are undertaken.
The decision of pilot or no-pilot will ultimately depend on the perceived pros and cons of both the pilot ‘solution’ and pilot ‘implementation’, weighted against the perceived risks of a full ‘solution’ and full ‘implementation’ and the relative advantages (and disadvantages) – namely time, quality, cost gained or mitigated from piloting.
The process to get the Organisation and the program to the position where they understand what is required for the pilot first, is a robust Target Operating Model (TOM) design, based off a structured understanding of the Current Operating Model, shown in the following HOBA® Analysis/Design pyramid, with ‘pilot’ sitting in the last step, having understood this:
Issues Faced With Piloting
Organisations often treat pilots as a ‘testing ground’ only and do not go into necessary ‘details’ of the project (i.e. only test a subset of the full solution, or part of the end-to-end process, and not the full breath of the final solution nor end to end process). This will inhibit the transformation to springboard for a full–blown solution (and implementation) later. Without the necessary ‘details’, the pilot will be limited in its effectiveness and will ultimately cause it to fail to gather full support from the whole organization.
Pilots also can have the tendency to not measure the associated costs and revenues before and after the implementation of the pilot. Hence, it becomes difficult to determine the tangible Return On Investment (ROI) for the full and final implemented solution.
The pilot needs to be designed so that it tests the most contentious risk areas.
- The Changers and Enablers in the Benefits Model are untested (pilots will validate them with the full implementation objective);
- There are two aspects to a pilot or MVP – if the pilot doesn’t produce the desired required results – the implementation method and final solution can be amended and the pilot re-run using the updated method and solution, or the full implementation method and final solution can be implemented using the ‘updated’ method and solution as a result of the pilot (and not further ‘piloting), and
- By testing MVPs on a limited scale i.e. having a smaller number of participants in the pilot but representative of the total population of effective stakeholders, it allows for a greater level of collaboration with the stakeholders and the program team.
The Keys To A Successful Pilot
- The breath of the pilot should be broad as possible across the Organization, wide enough to allow adequate testing of the full end-to-end process and changes but narrow enough not to inhibit or impact the functioning of the remainder of the company;
- Create an optimised pilot plan that will clearly define the statement and the goals, the pilot area, pilot resources, training required for the pilot participants and provision for continual communication between the stakeholders;
- Start the project with a meeting of the participants. Explain to them the purpose of the pilot, plans, schedules, and expectations, and agree what success looks like for the pilot i.e. we expect to increase the number of applications processed with the pilot period of 3 months from Jan-01-2019 to Mar-31-2019 from the starting volume of10,000, up to 15,000, a 50% increase;
- Assess results after the pilot project is over. Discuss with the pilot team what went well, what went wrong, and the additional inputs required for creating a full project implementation plan, and
- Be ready soon after with a full implementation plan.