Don’t embed unproven technologies in your improvement solution

Are you planning to make a major change using a change programme?  Could it be that you will be using technologies which are unproven in your organisation?  Could it be that this overcomplicates your programme leading to failure?  What approach might you use to ensure that this does not occur? 

I worked for a medium size business which provided application and data services to clients around the world.  These services were located on physical servers within our office block. The server rooms were not purpose-built and therefore we had regular customer service issues as a result. The plan was to transfer all our services to a purpose-built data centre, starting with those that offered the most customer service. 

Our technical experts wanted to use this opportunity to make a step forward in terms of data storage technology, infrastructure hardware and server technology. All this in addition to working with a new datacentre supplier. The project plan was developed including time for our experts to learn these technologies that were new to them, however they vastly underestimated how much time that would take. They had allowed time for the training courses but had not allowed time for us to really learn the technology in the depth at which we needed to use it. Nor did the time allow time for us to build the relationships we needed with the suppliers and to optimise the arrangements needed for our particular applications.  

As a result, the programme very rapidly began to be delayed and this resulted in increased risk of customer service issues and also credibility within the organisation.  

I have seen this same thing occur in manufacturing programmes and in applications development where the need to learn a technology which is new to the organisation and to prove it out, has resulted in major delays to the improvement programme.

The lesson is clear: do not deploy technologies which are new to your organisation through standard improvement projects.  Instead look to start by using the following 4 steps:

  1. Ensure that you don’t create a single point of failure by training at least two staff in each of the new technologies.
  2. Work the technology into a proof of concept so that you can begin to understand the technology within a very straightforward application.
  3. Create a pilot environment where the technology is deployed against the real need but make sure that it’s one where there will be real learning and is not too complicated as a first application.  
  4. Ttake time to optimise the solution. It always takes time to get the right configurations and the right learning in place.

If you want to learn more about leading change programs within your organisation, I suggest you read Change Spots – a system approach to change management.  

Go to