Adoption and Change Management: its Importance in an Ever-Changing Market (Part I)

Alessandro Martins
The Startup
Published in
10 min readAug 30, 2019
Wish X Reality

Keywords: adoption and change management, people, companies, leadership, business improvement, corporate culture

- This is the English version of the original article (in Portuguese) published in https://afmestrategia.blogspot.com/2019/08/gestao-de-adocao-de-mudancas-sua.html -

In the digital age, no product is everlasting, no customer is permanently loyal, no business model is safe from the continued advancement of its competitors. Companies must adopt a standard of constant change in their services, products and channels so that they do not suffer disruption and ultimately loss of relevance or even elimination from the market.

In such an environment, one of the most important disciplines in any business in the Digital Transformation process is the ability not only to absorb, but to promote and make the most of the novelties that are embedded in their business context. I refer to Adoption and Change Management.

In this article, my goal is to explain this concept, to expose some of the motivators for its adherence by companies — especially those that are undergoing change — and why this vision must be present in transformation projects since its conception.

1. Panta Rei

This aphorism, brought by Simplicius of Cilicia from the work of the Greek historian Heraclitus of Ephesus, translates as “everything flows”, “everything moves”. One never bathes in the same river twice: the body of water changes, the small leaves carried by the stream are different, even the temperature at any given moment may not be the same.

Perhaps never, in any given time in the history of market development, has this phrase been so current, or at least demonstrated in a way which is that fast. The ease of communication among people, the automation of processes and the lowering in price of the productive and commercial matrices arisen from the widespread dissemination of corporate and personal computing, culminating in the Internet, has led to companies never facing such a great demand for constant updating and changes in their activities, organizations and value propositions.

However, change is something which always introduces, in the best case, a great need for organizational adaptation and, in the worst, especially in traditional companies, anxiety and resistance in the team, often causing new improvements to have its impact diminished in relation to the original plan or even being dismissed to the detriment of the original plan. I don’t want to repeat, as it’s well known and common sense, that the company is a conglomeration of people gathered around and towards the same goal, and as such it’s in people that the ability to accomplish lies.

There are a few ways to get the team to adjust to changes. At Amazon, for example, Jeff Bezos instituted the famous Bezos Mandate, a draconian set of rules for his development team, when he implemented his new software building policies [1]:

1. All teams will henceforth expose their data and functionality through service interfaces.

2. Teams must communicate with each other through these interfaces.

3. There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.

4. It doesn’t matter what technology they use. HTTP, Corba, PubSub, custom protocols — doesn’t matter. Bezos doesn’t care.

5. All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.

6. Anyone who doesn’t do this will be fired.

Of course, not all situations of change should be treated in this way. Despite the same intention to gain market and generate profit, companies have different cultures and therefore should address the situation in different ways.

2. Common Barriers to Change Adoption

There are several types and natures of obstacles that can stand in the way of a change process:

  1. Perception of negative changes in the status quo: That is, people who are comfortable with the current situation and believe that the changes will create difficulties in their work, including losing their job. Indeed, there are cases where employees accept less compensation in “stable” companies (i.e., which rarely go through changes).
  2. Ignorance about the current state of the company: The perception of stability in relation to the current situation is often due to ignorance about the actual situation of the company, which can reach even higher, managerial positions. As a result, many corporate improvement projects are planned and executed without a detailed examination of its processes and culture.
  3. Integration of the area which underwent change to the rest of the company: Change is often restricted to one part of the company, and many processes and people communicating with the other areas change. Frequently, collaborators on both sides will try to circumvent the new procedures and continue to act “as usual.”
  4. Bad experience with previous change situations: Whether in the company itself or in previous jobs, the memory of unsuccessful or troubled change persists, and some contributors think they have no reason to believe that anything in this new process will be different.
  5. Political motivations: Change, with rare exceptions, leads to the creation, exchange, elimination and/or redefinition of positions within the company. People with an influential position can resist eventual loss of power, even if only perceived, or the generation of political opponents.

Generally speaking, these barriers manifest at an individual level, something that is often neglected in planning projects with an organizational scope. Change Management, in many of them, is restricted to internal training and communication. While these factors are critical to success, they are far from ensuring smooth adoption that will deliver the expected return on investment.

Case for Change: ERP/CRM Implementation

Implementing systems that extensively affect the most vital business processes, such as ERPs and CRMs, is a classic but not an unique example. Let’s take a case like Lead-to-Cash. Its automation leads to the standardization of several steps, such as the creation and insertion of leads in a specific format, follow-up of the sales cycle in centralized tools and well-defined steps to complete the process. Many sales executives complain that the tool “gets in the way” and continue to “take their orders” using non-standard channels such as phone or email, sometimes even using unofficial paper-based documents or drafts, and postponing — sometimes after the deal has already been made — the so-called lead system entry. Why?

The reason is often because, while the company as a whole benefits from pipeline visibility and conversion rate, medium-term planning of both sales targets and (in the case of companies selling physical products) production provisioning, better assertiveness in marketing campaigns and greater certainty in achieving sales, the process of achieving individual salespersons’ goals has, in their perception, been worsened, with less flexibility in negotiating with the customer, a learning curve deemed “unnecessary” for the exercise of its function and, in plain English, “a waste of time”. Nothing that does not directly help them to close a sale and therefore obtain their commission and the achievement of their quarterly individual targets deserves further attention.

The sellers are not wrong. An entire incentive structure was set up so that they would strive to generate more revenue for the company. If the change in the way they do their daily work is not accompanied by the incentive plan, if that plan is not clearly communicated, if the new process does not include the required flexibility, and if gaps are left to allow bypassing of new process, this will inevitably occur.

3. Working the Resistance

There are several actions to be taken to deal with resistance to change. Some mitigate the very occurrence of adverse factors, others set the stage for those inevitable cases in which resistance must occur. Hiatt and Creasey point out some of the fundamental principles for Change Management [2]:

  1. There is a reason for the change;
  2. Organizational change requires individual change;
  3. Organizational outcomes are the collective effect of individual change;
  4. Change Management is a framework for managing the human side of change;
  5. Change Management is applied to realize the desired benefits and outcomes of change.

In short, an understanding is needed from senior executives and managers of the transformation program or project that, just as important as planning the implementation itself, is creating a systematized set of activities that cater to how users, customers and others are involved.

Hiatt understood that the mitigation of resistance and the consequent successful management of changes resulting from a project of organizational scope goes through 5 phases, which must be considered in order — that is, problems in an earlier phase must be solved prior to the next. This framework is named ADKAR®, after its acronym [3]:

  1. Awareness: Make the employee recognize and understand that there is a need for change
  2. Desire: Create incentives and motivation for the employee to accept and participate in the change. This view is reflected in the term WIIFM (“What is in it for me?”)
  3. Knowledge: Provide employees with the information, training and education they need to act in the modified environment.
  4. Ability: Empowering employees to implement acquired knowledge.
  5. Reinforcement: Build the internal and external factors that will underpin change, such as compensation, recognition and personal satisfaction.

Case for Change: ERP/CRM Implementation

In our case, let’s look at a seller’s behavior. Let’s create an example of the stakeholder class that we want to investigate using the concept of persona, which consists of a representation of an individual of this class as a fictional person, but which carries tangible characteristics quite close to those of a real person:

Steve is a 45 year old sales executive. He has 25 years of experience, 10 of which in his current company. He is well versed in his sales method and already carries a background from 3 previous jobs in the area. Steve has accumulated several achievement awards for obtaining over 120% of his sales goal throughout his career and only on 3 occasions has he failed to achieve those goals, one of which resulting in him moving to another company. His core tactics is to have a close, non-bureaucratic relationship with his customer, offering tailor-made proposals with fast response times, sometimes skipping steps of the sales methodology. Because Steve’s results are often satisfactory, his leadership views his attitude as “bold” and “effective.”

With the implementation of the new CRM, Steve receives the news that his process will be automated, and he will be able to insert his leads and prospects into the system from the beginning, monitor the sales funnel and the generation of contracts and orders; however, transactions outside the system will not be accepted. Steve feels that his relationship-based work and efficiency will be affected by the need to use the system, and that certain actions he usually takes in his day-to-day life, such as moving the negotiation process around based on customer trust, without a previous formal lead registration, may be compromised.

So, in this example, Steve is past the Awareness phase, because he understands why and how CRM provides benefits to the company as a whole, but doesn’t see how this change in the process can be beneficial specifically for him; therefore he continues, as far as possible, doing his activities the way he has always done.

4. Managing Change from the Start

As already mentioned, the practice of Adoption and Change Management should be considered since the planning stage of the transformation project. There are several risks involved in starting your business long after kick-off:

  1. Projects which introduce major changes in the company promote business process improvement. Missing the chance to engage and involve with affected parties from the outset increases the risk of having employee support and agreement below the satisfactory level.
  2. By initiating Change Management activities in conjunction with the project, one can create seamless planning and integration with the business improvement process, and both will walk side by side, offering feedback to each other; on the other hand, if starting later in the project, what happens is an overlap of Change Management activities with tasks already underway in the project, creating competition, instead of cooperation, for time and people resources. Under such circumstances, experience shows that, in the event of a dispute over resources, project managers rarely give in to Change Management because of the pressure to deliver target artefacts, and the result is that the change is poorly received by the project, even with technically complete artefacts.
  3. Each of the elements which support the change planned to be achieved through Change Management — Awareness, Desire, Knowledge, Skill, Reinforcement — has its time to happen, in sequence, within the transformation life cycle. A late start of Change Management activities can lead to not all the potentially affected people becoming aware of the change, understanding their personal and professional benefits, having the proper training, and so on, and thus building resistance in a phase of the project in which several decisions have already been taken and the cost of review and adjustment becomes prohibitive.
  4. Thus, it is of great importance that the Change Management strategy be planned by the appropriate manager in conjunction with the project manager and key stakeholders at the initial business transformation project meetings. At this stage the following tasks should be performed [2]:
  • Scoping and assessment of readiness for change
  • Risk assessment and foci of resistance
  • Mapping of key stakeholders and sponsors
  • Team preparation (internal and external) for Change Management
  • Creating a sponsorship model with business leaders

Conclusion

In this first article, the focus was on exposing the need for an effective Change Management discipline in any large-scale project that proposes radical changes to a company’s modus operandi, and how technical excellence and pure and simple compliance with project delivery metrics are not enough to ensure that the expected business result is achieved. It was also presented a framework to support change, the importance of starting the Change Management process simultaneously with the start of the project, and some of its initial activities.

In the next articles in this series, I will address some of the key concerns of change managers throughout transformation projects and how mitigation of resistance and adoption risks can be addressed in each phase of the ADKAR® framework.

Alessandro F. Martins is a Senior IT Business Strategist with 21 years of experience in IT and business in areas ranging from Enterprise Architecture and Business Process Management to Program and Project Management, C-Level consulting for large companies and advisory for Digital Innovation.

References

[1]: Ross Mason: Have you had your Bezos moment? What you can learn from Amazon https://www.cio.com/article/3218667/have-you-had-your-bezos-moment-what-you-can-learn-from-amazon.html, on CIO.com website

[2]: Jeffrey M. Hiatt, Timoty J. Creasey: Change Management: The People Side of Change, ISBN 978–1–930885615

[3]: Jeffrey M. Hiatt: ADKAR: A Model for Change in Business, Government and our Community, ISBN 978–1–930885509

[4]: Anna Marr: 5 Barriers To Organizational Change: https://management.simplicable.com/management/new/5-barriers-to-organizational-change

--

--

Alessandro Martins
The Startup

Senior IT Business Strategist, Enterprise Architect and Guitar Player extraordinaire