Resistance to change

Question 4

New information systems sometimes fail because users do not or will not use them. This is often described as ‘resistance to change’.

Critically evaluate the concept of ‘resistance to change’. Using current examples, explain why it may occur, and how developers and managers might avoid it.

Answer

Resistance to change is addressed in the subject guide as a “key concept in understanding what happens when innovation systems innovations are introduced”, and it states that “change resistance is some sort of human reflex, and we need to understand why before we can think about strategies to ‘overcome’ resistance“.  There are different perceptions of the source of this issue and I tend to believe that all of them capture a relevant component of the situation.

In a more general way, it’s mandatory to consider a sociotechnical perspective in this evaluation, since this situation works as a good example of a relation between two of the components of Leavitt’s diamond, in this case technology and people. It’s relevant to mention that a new information system will generate interactions between all components of the diamond, but for the scope of the question we will only review the two stated above.  In this sense, reluctance from people to use a new information system might be associated with people challenging the decisions of a specific party / group inside the organization, basically because they are feeling some threat (visible or invisible) that comes with this disruption. A practical example of this can be the struggle of a marketing person not using a new CRM tool since it requires that customer's data must be  anonymized, and even though the CRM can be more efficient the user might feel that the data compliance decisions (enforced by the CIO) goes against the “simplicity” of an excel spreadsheet where all the data is available (but with a high organizational risk).

Even though the last paragraph tends to point towards people behavior and the organizational dynamics, I tend to believe that these situations might be more evident in C-level / management positions than in operational areas where the sense of power is negligible. In this scenario we can identify a few scenarios where resistance to change can be understood in a more practical way. The most easy situation to detect occurs when people will not use a new tool if there’s a huge  mismatch between the features of the new system and  the users’ requirements, which can happen because the requirement wasn’t done correctly or simply because the new software has bad UX, is worse than the old one. Since this could sound counterintuitive, one explanation behind this is linked to the absence / misalignment of incentive compatibility between the organization and the decision maker.

Resistance to change also can occur when people don't receive enough training during the onboarding phase. Without a proper process,  the users will not feel confident enough to perform their required task since the  insecurity might  increase their fear to receive a poor performance evaluation or to make an expensive mistake. A basic situation where this can happen with a new ERP and the people that generate purchase orders through this system. If the user makes a mistake, he will buy an incorrect amount of goods, which is expensive. Naturally he will prefer to send the purchase order through email with manually calculated amounts.

Another relevant element for this situation is simply  bad timing / bad luck. I tend to believe that this is a huge issue these days with the covid contingency, where many people aren’t allowed to work in the same conditions as before. In this context, users will be reluctant to use a specific component or software that demands to be connected to a specific intranet / network.

 In order to avoid these situations, the basic principle is related to consider the introduction of a new system as a situation that must be managed with a sociotechnical approach, and that the success of the initiative (theoretical efficiency that it’ll create) will require a a proper orchestration between all four components of Leavitt’s diamond. In concrete, this means that the organization first needs to assess its digitization degree and from this baseline it needs to start to design and implement tactical initiatives. A few relevant  ones

• Involve users from the start of the project. If the decision is made without incorporating users’ feedback, there’s  a high chance that the system will not suit many of the actual organization flows. The larger / clustered the organization, the bigger the risk since the odds that the decision makers know these details are almost zero.
• Make people  accountable for their decisions. This will reduce the misalignments between people and the organization and will help to reduce the risks of poorly made decisions / hidden personal agenda.
• Design and implement a proper onboarding and training process that removes stress from the workers. In a more theoretical way, every company should have a training plan for each worker that takes into account all the relevant elements to the business and to the role that the person executes.
• Implement change in different stages and try to reduce the complexity by tackling one problem at a time.

As a last element, it’s always relevant to remember that projects fail in the real world and many times a software decision won’t reach the expected returns. It’s relevant for companies to consider these aspects during the initial design, and to implement realistic and contingent measures rather than the ones than a generic one which may sound as bulletproof.

Question 6

Enterprise systems hosted in-house have been the mainstay of most medium sized and large businesses for the past two decades. However, in the future, businesses will be more wary of becoming locked into using a single integrated set of software, and far more prepared to use multiple tools and services drawn from across the cloud marketplace

Critically assess the above statement.

Answer

From my standpoint, I believe that organizations will migrate to a model where software will work in a less centralized way. I tend to be more drastic than the statement since I feel that this is not something that will happen in the future, since  it’s something that is  occurring in this particular  moment and started a few years ago with the adoption of cloud solutions.

        The major component that accelerated the adoption of different software tools is the consolidation  of the cloud services that offer a variety of solutions. Even though the first cloud components are always perceived in terms of storage and computing power, there's already a clear distinction between many different solutions for specific needs and requirements, which goes from software as a service (where all the technical components are managed by a 3rd party) to platform as a service (the business manages the application & data layers), to infrastructure as a service (business manages application, data and operating system layers) until finally arrive to the in-house hosted or on premise solution. This topic is relevant because organizations have different needs and requirements and many times they need to adopt different approaches. In this sense, cloud solutions understood this requirement and created a more deep environment where each need can be satisfied.