You are Home   »   News   »   View Article

Reducing resistance to a change in IM technology

Thursday, September 24, 2015

There are ways to reduce user resistance to the introduction of new information management technology, writes Gianluca Monachese, Director Business Development, KADME AS and Vasily Borisov, Director of Technology, KADME AS.

When an oil company, or a national petroleum agency, decides to finally undertake a project to change an information management system, there is a lot they can do to minimize the related risks.

Do not involve only the people that were expert in the use of the old system, bring also fresh views into the picture.

Communicate the reason of the change to everybody in the organizations who will be affected by it.

During project execution, allow the vendor to talk directly with the end users.

Allow time for a design phase, rather than asking the vendor to just install the solution you want in a few weeks.

Continuously look for possible advantages the change will bring, even though you had not considered them in scope.

Always prefer a phased approach. It is good for both the vendor and for you as it reduces risk and increases people buy-in. Consider that when preparing the budgets.

With the new system in production, keep the project team in place to continually mitigate the internal resistance from the end users,
helping them to focus on the original rationale behind the change.

Work with the vendor on the training programs aimed at introducing end users to the new system, so that you can contribute to the explanations regarding any deviations in the way data is presented.

Resistance to change

In business-to-business relationships there a lot of resistance to change. This is a natural effect of the fact that an organization is not simply a group of individuals working together, it has its own capabilities, values and policies.

The organization has to cope not only with the habits of the individuals but with the entire set of work procedures and consequent more complex change management processes. The demographics of the organization and the complexity of its structure are other factors.

Disruption is not seen as a positive word in a corporate environment.

Normally the customer prefers smaller, non-disruptive improvements of existing technologies already implemented.

In the oil and gas industry, organisations have a tendency to get stuck with the same information management systems for decades (corporate data management solutions, National Data Repositories). This is not because they are particularly good, but because of the factors mentioned above.

This means that technologies are mostly changed because of external factors, for example when a technology is no longer supported by its vendor.

Daft technical requirements

Consider an organization which has decided to change their information management system because the software they have been using for the last 20 years is not supported anymore.

They produce a Request for Proposal (RFP), trying to describe what they want.

At this stage the focus is too often on technical, rather than business requirements. This can be because the RFP is put together by the IT department, and there is a gap in the internal communication
regarding what the end users of the system actually need.

This might also be because the RFP is put together by a reference group that represents the most experienced end users of the old system, who have been doing their work in the same way for many years.

In both cases, there is often the introduction of mandatory technical requirements that immediately create obstacles to the introduction of new technologies.

Here are a few real examples from tenders we have participated in

- 'PPDM 3.8 data model or later with Gold compliant is a mandatory requirement' [exact statement, including wrong grammar]

- 'The system runs on Oracle as database'

- 'It should also be possible to merge results and compare data, and a table view, row view and chart view of the data must be provided'

None of these examples actually say anything about what the end user wants to achieve and end up creating unnecessary complications for both the customer and the vendors that are responding to the RFP.

The effect is in fact uncertainty on the actual scope of work and a consequent increase of the risk factor that the vendors are applying when suggesting their solutions to the customer.

How vendors cope

To minimize this risk and stand a chance to win the tender, vendors are forced to do some of the following.

Find a partner that they were not really looking for, just because they have a required certification, to try and reach a hybrid solution integrating different technologies.

Bend the technology they strongly believe in, and in which they have invested many years in R&D, to cope with the technical requirement.

Increase the price, to cope with the risk presented by a non-clear technical requirement that might add considerable amount of work to the scope.

Of course the organization does this in good faith, in an attempt to reduce negative change.

But the customer will most likely end up with a system that is regarded by the end users as 'not as good as the previous one', while the vendor will have developed a heavily customized, less supportable solution that deviates from the product they had developed on the basis of their technology and market research.

Bring fresh ideas from the users

We suggest that the organization writing the requirements for the new system should not rely exclusively on the opinions of the people who have built and used the old system.

Yes they have a lot of experience. Yes they might be enthusiastic about the change.

But consciously or unconsciously, they would end up with a description of the same system that they have at the moment.

New people should be involved, including from outside the organization (consultants).


Typically the customer is requesting a very short deployment time, and requirements are vague.

The vendor puts together a project team and its software engineers start sweating.

The design phase is too often overlooked by organizations when they put together an RFP, because they believe that the ideal solution is already out there waiting to be installed, maybe with a couple of weeks for customisation.

This misconception, with little or no time given to the design phase, is the single biggest cause of project delays and overruns.

It is imperative for the software company system analysts to communicate directly with the end users (but this is rarely allowed by the project
team at the customer). This way they can do some good design before starting customization of the software in the wrong direction.

It is also at this stage that it becomes evident how a disruptive change would eventually bring additional benefits to the organization, apart from those considered at first.

If you are lucky to have selected a very creative and flexible vendor, and prepared to process a few Change Requests with additional cost, your project can give you a lot more value than you had originally expected.

Post deployment

The point of completion of the software implementation is the point when all users gain access to the new system, and most of the psychological reactions start to unravel.

Any change in the previous workflows, even if explicitly requested in the RFP, meets a lot of resistance.

If the new system is better than the old one, then it will also be better at showing the underlying data errors.

It is usually the same people that are looking at the new system now who made those data management errors.

Users are reacting by default, blaming bugs in the new system, because they do not see exactly what they were seeing earlier.

The status quo of many years past is disturbed and the users are out of their comfort zone.

It is up to the vendor to defend why the information is presented in the way it is, and to demonstrate that any inconsistencies are not due to the new system. So the new vendor can easily end up with no friends among the operational staff.

The vendor needs to try and soften up the issues when communicating with the users.

Often, the organization leaves the vendor at the mercy of the flow of critics from the end users.

The project team on the customer side is quickly disbanded and the vendor is left to 'support' end users that were probably not properly involved in the early stages of the project and that were not sufficiently informed about the rationale behind the change.

'Training courses' quickly turn into discussions on why the system does things in this way rather than another, with questions coming from people that were not even aware of the requirements formulated by their
colleagues in the original RFP.

The project owner, on the customer side, can help minimize the resistance from the end users also at this stage.

Communication should be regular, across the entire duration of the project, about how things are progressing, the results that are being achieved and whether the change has met its objectives.

Case study

Here is a case study of a real software implementation project.

A modern International Oil Company with a significant exploration focus needed a new information management system, because the vendor of its existing system was dropping support for the software.

The IOC had a very clear and structured data management policy. It had a Data Bank department with 7-8 people loading data into a corporate data management system from a well-known supplier, heavily customized to meet the business needs.

The system had been in use for over 10 years, therefore containing a vast amount of legacy data, both structured and unstructured.

The Data Management department was in good control of the process. Manuals and procedures had been developed and quite strictly followed. Minimal data fells between the cracks.

Knowledge workers of the company regarded the implemented system as 'good' and didn't complain.

However the software deployment at this company had become so heavily customized that it had deviated a lot from the off-the-shelf product of the vendor. It had become pretty impossible to support, even if the M&S [maintenance and services] fees were reasonable.

The company issued a RFP for a new system.

During the design phase, while communicating with the stakeholders, it became clear that there were additional value propositions which could be added, which would also make the system easier for staff to accept.

It realised it would be possible to better integrate data in the corporate data management system with other data sources. Previously many of the users had Excel spreadsheets 'on the side', to record log activities, or to consult a carrier registration journal.

A second additional benefit of the new system was to improve data quality.

Data was analysed prior to being migrated from the old to the new system, and it was clear that there was little automatic control on the quality of loaded data.

Once communication with the end users was established and flowing around the above two subjects, the resistance they were posing to the change dropped. They started appreciating the disruptive innovations proper of the new technology.

The project was executed with a phased approach, using Agile methodologies, with an early software deployment and
prototyping of functionality in small increments, tested constantly by a reference group of users.

With this type of approach we (KADME) completed the project transforming (among other disruptive innovations) a relational database of 2000+ tables into 15-20 reasonably denormalized flat tables managed by our NoSQL data store.

The new system has replaced the old one and delivered the additional value propositions mentioned above.

Users have a single overview of all their data, and data managers have data quality indicators and data audit dashboards.

Associated Companies
comments powered by Disqus


To attend our free events, receive our newsletter, and receive the free colour Digital Energy Journal.


Latest Edition Jan-Feb 2024
Jan 2024

Download latest and back issues


Learn more about supporting Digital Energy Journal