To Pilot Your Business Transformation Or Not That Is The Question

Share on facebook
Share on twitter
Share on linkedin
Share on email
Pilot Your Business Transformation

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.

These have been discussed in-depth in our previous posts “Signs your Business Transformation is in Trouble” and “The Keys to 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

Confirmed Benefits

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.

Risk Management

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.

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.

Stakeholder Management

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:          

Pilot Aspects Table

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:

Analysis-Design Pyramid

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 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!

Sincerely,

Heath Gascoigne

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

  • 269
    Shares

Can't get enough real insights? Subscribe to Transformology®!​

We’ll send jargon free insights that you can actually use to transform your business straight to your inbox once a week. 

Work Smarter, not Harder!

Subscribe to Transformology®

Connect with Us

Trending

Transformation Training Webinar

FREE Webinar

Are you a consultant, team or organisation embarking on your transformation and want to move from the model of transforming business? 

Join our free webinar and learn ‘The 6-Steps to Business Transformation Success!’

What's HOBA®?

HOBA® is the new way to transform organisations and the answer to the 70% failure rate of business and digital transformation projects today.

Learn more about HOBA®

Tired of being told what how to change your organisation?

Take control of your transformation and apply the systematic structured method that has already turned about many failing business transformations into success!

More Articles.

Business Transformation Industry Is Broken
Heath heath@hoba.tech

Business Transformation Industry is Broken

Why The Business Transformation Industry Is Broken? Before I show you how to transform your business, let’s define business transformation. What Is Business Transformation? Business Transformation is when a business changes the way it conducts business. It doesn’t necessarily change what it does, but how it does it.This can involve a change […]

  • 269
    Shares
Read More »
Business Architecture Challenge
Heath heath@hoba.tech

The Business Architecture Challenge

Let’s start this post by defining business architecture… What Is Business Architecture? Business architecture refers to an organization’s framework. The Business Architecture Working Group of the Object Management Group (OMG), calls it “a blueprint of the enterprise that provides a common understanding of the organization and is used to align strategic objectives and tactical […]

  • 269
    Shares
Read More »
Aligns the Business
Heath heath@hoba.tech

What Is Enterprise Architecture Really?

Let’s start this post by defining enterprise architecture… What Is Enterprise Architecture? Enterprise Architecture looks at both Business and Technology Architecture. TechTarget calls it “a conceptual blueprint that defines the structure and operation of an organization”.Its aims to make sure your IT investment will help you achieve your current and future objectives at the […]

  • 269
    Shares
Read More »
Business Transformation World

Get content like this sent directly to your inbox!

Scroll to Top
Business Transformator Genie 300 x 300

Want transformation insights delivered right to your inbox?

Cookie-Man.svg

This website uses cookies to ensure you get the best experience on our website.