What are the signs that your business transformation is in trouble? Have you noticed the tell-tale signs only when it is already too late?
All these could have been avoided if you had followed the principles to carry out a successful business transformation.
In this post, we will discuss whether to have a ‘Pilot’ (project) before carrying out a full-blown business transformation or not and what are the fall-outs of doing or not doing so.
Piloting is the equivalent in the business environment of the general concept of “trying before buying”. This is why piloting is critical as it helps to test the waters before any business transformation is implemented.
So, what are the benefits of piloting, using an MVP – Minimum Viable Product to ‘try before you buy’ – as against a full-blown implementation or TOM – Target Operating Model from the get-go? We will discuss these individually before:
- 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.
Regardless of the business process or technology that is sought to be implemented, the risk evaluation needs to be reasonable so that there is level of confidence with the level of risk that will be carried forward to a full implementation project.
The main reason for resistance to piloting is the lack of knowledge within the Organisation about the benefits of piloting and what it actually involves. The Business Architect (we call Business Transformers – because a Business Transformator has moved beyond Designer, to include part Strategiser, part Collaborator and part Negotiator), therefore, has to keep in mind:
- 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.
To mitigate the resistance to Piloting, HOBA® includes pilots by default in its own building block to get visibility and attention for MVPs. This ensures the Organisation’s capabilities and implementation options are both visible (i.e. stakeholders are informed and aware of it, mostly because they were involved in designing it, or reported to of its progress), and are tested before any decision is made about full implementation.
The Keys To A Successful Pilot
No matter how well a pilot project looks good on paper there will are always a few obstacles to avoid, and a few keys to making a successful pilot.
Here are the keys to making 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.
Thank you for reading this!
P.S. If you want to join our Business Transformator community of like-minded Business Transformators, join the community on the Business Transformator Facebook Group here.
P.P.S. If you want to learn more about the world’s only business-led business transformation framework, check out The Business Transformation Playbook here.
For more information, visit https://hoba.tech