Implementing new technology- Part One

by John Williams

During my many years of supporting organisations from small SME through to large Corporates, I’ve had the luxury of experiencing the varying levels of success implementing new technology.  So what have I learnt?  Firstly, you could argue that  “success” is subjective and certainly can differ depending on your connection and involvement, which brings me to a really important point; how do you define success and how do you measure it?

There are many books you can read, many processes that you can follow, many courses you can attend to help you in the overall management of implementing new technology, but there are fundamental things that are often overlooked. This article is not meant as a definitive guide for technology implementation, but more as a catalyst for thought. Part 1 covers specifying the requirements, with Part 2 looking at selecting, procuring and rolling out the chosen system.


I must confess, I always sound too organised, which some customers find a little frustrating, but undoubtedly the key to success is planning.  Not simply for the sake of planning, nor demonstrating to management that you’ve got a plan, but to ensure that the necessary steps are clearly defined, together with how each step is executed, measured and signed off.


So what do you need to include in your planning? For me, the first thing you need to document is why you need the technology. Too often technology is seen as a solution for outdated or inefficient processes, someone saw a good product demonstration or even just because someone thought it was a good idea. I know this sounds strange to some readers, but I’m sure some are nodding their heads with agreement!

Gathering requirements can become an overwhelming task and eat into the budget, however if sufficient time, energy and expertise are not invested in this early stage, achieving success will be almost impossible. So, whether it’s management saying “just install it”, or a technician insisting some new-fangled program is imperative to his/ her work, understanding the deeper requirements is imperative.

Casting my mind back a few years (or maybe decades), requirements were more often than not badged as “Functional Requirements” and simply contained a list of functions. Times have moved on…… Functional requirements must be understood, along with user requirements and in today’s competitive world, business outcomes and requirements, together with the commercial requirements must all be included. I recall a few years ago, a Managing Director of an SME stating that he wanted the best technology and processes within his company for two reasons.  Firstly, to ensure that the company runs as efficiently as possible, but more importantly, so his workforce have the best tools to undertake their daily activities, which results in a happy and productive workforce. I must be honest, I quote this to many customers and it really does make you think how amazing the technology is that we have come to expect in our personal life, compared to what we tolerate in our business life.

There are many processes that you can undertake to gather requirements, but prior to delving into the detail, the first task is to identify the key stakeholders and a top table sponsor.  This team can work together to define the overall scope and constraints, which will probably include questions like “do we really need new technology?” and “I can’t believe our processes are so inefficient” and the really common one - “we really need to rethink this whole initiative”. All these are really healthy conversations that will result in clarity and alignment of the overall requirements.


Defining a specification is the process that will ensure you don’t end up hammering a square peg into a round hole. Or from a business perspective and bluntly put, ensuring you don’t invest in the wrong solution.

The specification will be a combination of the different requirements that you’ve gathered as part of the preceding task (namely business, commercial, functional and user). Using this information you can prepare an overall specification document. Sounds easy…So the challenge is how this specification is structured and how you wish to Select and Procure (more on this in Part 2) the solution. As a simple example, do you want the specification to select a shortlist of potential suppliers, as a Request for Price (RFP) or as a high-level summary of your companies aspirations? It’s important to have answers to these questions and a clear route forward before putting pen to paper (or fingers to keyboard) and authoring an unwieldy set of documents that will never be read and, more importantly, may not even be fit for purpose.

The next consideration that is often overlooked, is how you accurately measure potential solutions. There should always be a balance between documented criteria and the human factor, based on knowledge and experience. Defining and agreeing with the stakeholder team how this balance is weighted is extremely important and should be agreed in advance of the Selection process.

Part 2 will cover the selection process, the procurement, and some of the areas to consider to ensure a successful implementation and long-term success.