Do we have the right technical skills to make change happen?

Technical skills

So far we have focused on some of the softer skills required to create effective change, but there is no point in embarking on a serious change programme unless the technical capability exists to get tasks completed to a sufficient level of competency.

The best example in everyday life is buying a house. First you will talk to a realtor or estate agent to show you a selection of properties that might be of interest. When you find the right property you will need a lawyer to manage the paperwork and a financial advisor to get you the best mortgage deal. You will then need to get the house insured. If you then embark on some remodelling you will need an architect and a competent builder with the right variation of skills that can make everything happen. It would be a very rare thing indeed for one individual to do all these things themselves since most of us would not be competent. We need the right specialists or else our project could turn into an expensive money pit.

And it’s similar in the business world. A very good example would be the implementation of a new ERP system. It would be pretty obvious that you would need a group of technical specialists that are familiar with that ERP system and how it can be configured to suit the business.

Many have also learned to their cost that a team of internal business specialists will also be required to help the external ERP specialists to understand the business properly so that the right configuration options are chosen.

Will that mean that there will be major changes to operational processes such as how we input a sales order from a customer? Then we may need to hire specialist trainers and people with softer change management skills to ensure that operators understand the change that is coming down the road and are not anxious about the fact that things will be done differently. Are we going to be letting people go as a result of the changes that get implemented? We may need some human resource specialists who understand how employees need to be legally consulted about the forthcoming changes and what steps must be taken before making people redundant. And then all these people will need to be co-ordinated to ensure they are all doing the rights things in the right sequence at the right time. That’s an awful lot to get right.

This is why many companies will employ an external systems integrator who will have most of these skills under one umbrella. And some do, but unfortunately many don’t. For example many system integrators are very technically focused and are not well equipped in the softer skills of communication and training. The Big Four will have a distinct advantage in this area as long as you understand that you will get some experts and lots of academy members who are still learning their trade. And if you go for the umbrella solution you will pay the highest price for implementation. But you do mitigate the risk of not getting all the skills at the right level across the programme.

A vital question can be whether you recognise a real expert or not. Most of us have to rely on the quality of résumés and our own instinct for recognising the good people from the bad. If we go back to the house example, we employ lawyers, surveyors and architects since they all have important jobs to do and we trust their expertise since they have proven qualifications to do the job. But often that is not the case in change programmes. While there may be many programmes of certification they are no guarantee of success. For example, someone having a Prince2 qualification does not make them a good project manager. It only tells you that they have a qualification that they paid for and they should be able to remember the elements of technical project management.

It is an unfortunate fact that most companies only find out afterwards how expert the experts really were. Several years ago when working at a major aerospace client we asked what the standard payment term was for their suppliers. The answer was 60 days after the month of purchase. So you should get an average 75 days of credit on these invoices. But we were puzzled that the due dates on these invoices were all 60 days after the date of purchase while the actual payment dates were slightly short of the 75 days average. After some investigation we found that when implementing SAP that their system integrator had told them that automatic configuration of such a term was impossible. The client had no reason to believe that this was not true and so had implemented a series of workarounds that meant rather than running a single payment run every week they ran fourteen separate payment runs with each tweaking invoice receipt date parameters to approximate the correct payment term. It was a very clever workaround but was completely unnecessary. Anyone who knows SAP will tell you that you simply need to flag one check-box in one table to make all this possible. But it does display the danger of trusting someone to be an expert in their subject when they clearly were not. What is worse in this case the system integrator encouraged the client to fit into a suboptimal process to cover their own technical incompetence on this point.

That might seem like a very narrow point but the quality of implementation will be heavily dependent on the level of expertise of the implementer. This is where external quality audits or expert user groups can be very beneficial so that clients can cross reference their experiences in order to get a better implementation result. But many continue not to make such checks and live with the consequences for a very long time.

Leave a Comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>