Technology Adoption Strategies for Business Systems

August 7, 2018

Regardless of an enterprise’s size and industry, technology touches every aspect of a business’s operations now more than ever. Successful technology implementations have always been important but in today’s economic landscape, technology implementations NEED to be successful as they can make or break a business.

Here are some horrific examples of what happens when technology implementations fail:

The implications are not just lost revenue but lost jobs. Take Target Canada’s example; over 10,000 jobs were lost when their SAP implementation encountered problems. Most of these failures are a result of a myriad of reasons that include poor project planning and insufficient technical knowledge. However, one reason that’s almost overlooked but is a significant contributor, especially during the post go-live phase, is user adoption. Users expect a seamless experience that allows them to accomplish their deliverables with ease and efficiency. Technology implementations that provide this tend to be very successful.

Common Technology Adoption Misconceptions

Before we dive deeper into understanding adoption strategies. Let’s explore some misconceptions when it comes to users’ adoption technology.

Adoption is not all about digital transformation There is a misconception that adoption is about embracing a new technology as a result of some digital transformation effort. Adoption can also be about the new and existing processes or, more simply, it can be about the efficient and full uses of technology already implemented.

Adoption efforts start post go-live In a case where adoption concerns a new technology implementation, the usual tendency is to emphasize adoption in training related activities post go-live. In fact, adoption efforts should start when requirements are being collected and the solution design is being drafted. It starts by making sure there is buy-in from end users from the beginning and throughout the process, especially before blueprinting. If this does not happen, buy-in will be much more difficult later in the project. Even worse, a solution that users do not want or cannot use will be implemented and adoption will be near impossible. This is probably a major reason why some companies’ implementations are scrapped and millions of dollars wasted. estimated in 2012 that globally, companies lose $3 trillion because of failed IT; which is a combination of IT projects that add zero value to users, failed capital projects, unplanned activities, and rework.

Adoption is all about users While the focus of adoption efforts is on the end user, and rightfully so, executive sponsorship is important as well. Even if senior management does not use the technology in question, their visible and active support of the technology will inspire their subordinates to use it. Sponsors must remain visible throughout the lifecycle of the project. A side note on this is that executive sponsorship is not only helpful for adoption but the visibility of sponsors inspires the tracking of the benefits of a technology implementation to continue throughout the project lifecycle and not just simply during the first months of the new car smell.

Adoption Strategy Considerations

When discussing adoption strategies, there are a few things to consider:

  • Training
  • End-user Buy-in
  • Managing Expectations
  • Managing Complexity
  • Governance
  • Effective Communication
  • Executive Sponsorship


Training is as important as the end users. Often, Change Managers will focus on training end users on using the newly implemented technology with the belief that once users are trained, they will start using the technology automatically. This is not always the case. Most training is quite generic, technical, and at times unrelatable by the users. Instead, Change Managers should make it a point to utilize user-specific workflows with a before and after type of approach, preferably focusing on how the pain points were addressed in the new implementation. In addition, Change Managers should pay close attention to the learning curve of the users. If the technology being implemented is complex, multiple training sessions may be required so enough time should be allocated to account for such a scenario.

End User Buy-In

We discussed this above but there are still a few things left to say. End users know how the business works and probably have built processes to cope with the inefficiencies of the technology they use. If a process has proved to be useful, users will develop a habit to default to it. At times this results in users circumventing the implemented technology which means all the work and money put into implementing the technology goes to waste. If you are in charge of such a project, grab a calculator and start heavily discounting your ROI estimates (assuming you were tracking ROI in the first place). Below are some key points to consider when addressing user buy-in concerns:

  • The longer a technology/process has been in use, the more effort is needed to convince end users of the value of new technology. This is simply because humans are creatures of habit. After getting used to a process, it becomes quite difficult to change. As a result, Project Managers should allocate enough time to get all users on board. I will also reiterate my point above that there should be extra effort to demonstrate benefits during the planning stage. However, be careful to manage expectations.
  • Adoption may be about fully utilizing an existing technology or process. In this case, it is important to highlight to end users the use of best practices and importance of the improvement of efficiency metrics. The idea here is to emphasize value and be able to present it to the users.

Managing Expectations

Sometimes adoption issues within an organization are a matter of unmet expectations or at times “miscommunicated capability” of the technology. At times, businesses are pushed to change a technology because it is no longer keeping up with the business operations and is causing a headache for end users. This is a good scenario during the planning process because the end users will be the easiest stakeholders to convince about a transformation. However, they also could be a difficult bunch post go-live because the technology implemented did not deliver on their expectations. They may have been promised a sports car but instead, a tractor was delivered. The tractor will still get from point A to point B but just not as fast as expected. At this point, Change Managers sort of have a mutiny on their hands. When such situations are not managed well, entire implementations can get scrapped. You can browse the web and find tons of scenarios showing what type of carnage is left when this happens. The key is to keep realistic expectations for end users and to detail out what changes to expect while making sure to keep them informed along the way.

Managing Complexity

Quite often complexity is confused with complicated. As Theodore Kinni notes in his MIT Sloan Management Review article, “Complexity involves too many unknowns and too many interrelated factors to reduce to rules and processes”. On the other, complicated may mean hard to solve but solvable or resolvable with systems and processes. An interesting note made by Kinni is that solutions to complicated problems do not always work on complex systems. If left unchecked, what ends up happening is the implementation of a technology with potentially too many features and requirements that very few users want with the majority left figuring out how the technology fits into their workflow. Dealing with complexity can be difficult. Below are some suggestions on how to address complexity in order to increase user adoption:

  • Identify complexity first, distinguish what is complicated and what is complex. A good rule of thumb is to look at your organization, processes, policy etc. and, if you can distill them into logical rules that can be converted into systems or process you have a complicated scenario. If you seem to have difficulty figuring out if any set of activities is a process and things seem disjointed, you likely have a complex scenario. Refer to Kinni’s article for ideas about managing complex business scenarios
  • Simplify as much as you can. A starting point would be to determine the business objectives. Next, determine all the processes that are critical to meeting those objections.  Then find common interconnections between the processes. You can then try to cluster these processes based on the interconnections and start determining which ones are critical, which ones can be consolidated, or if new ones may need to be created. By doing this you are able to make sure that any part of a business can be reduced to rules and processes that drive business objectives.


Governance is key to ensuring the users and the business as a whole are adhering to set rules and laws. It not only avoids legal issues but at times is helpful to ensure a good service or product is provided to customers. At times the adoption of technology is affected when rules, policy and laws are not so clear to the user.  For instance, users will bypass a system if it does not provide a direct route to achieving their task. They would rather opt to perform the task outside of the system with less hassle. The system’s utilization will gradually decrease over time and therefore its adoption as well. A good approach to trying to solve this would be to bake in as much of the governance into the technology as possible. At times this may be difficult especially where there are numerous variations to process. In this case, the exceptions should be clear, documented and easily accessed for reference.

Effective Communication

Sometimes adoption is a matter of awareness. Users need to be aware of the progress of a project when a technology that affects them is being implemented. Most importantly, users need to know how this technology will affect them. Users should feel included in the entire process; that way the changes and the technology implemented are relatable, thus lowering the resistance to adoption. Below are a few pointers on ideal communication that can help increase user adoption:

  • Involve power users in all phases of the project (these are your adoption champions and can help sell the benefits  to other users)
  • Send regular bulletins to all affected users.
  • When sending out bulletins, make sure to incorporate relatable terms and figures. For instance, mentioning of major pain points and how the new or improved technology will resolve them can create anticipation which will likely help increase adoption during the first few months post go-live.
  • Engage users through pulse checks post go live. This can be achieved through surveys of the user’s opinions. The responses can be published but should be anonymized.
  • Share the metrics on the project performance, including ROI metrics post go-live. Usually, these metrics are reserved for the steering committee and managers, however, they are helpful for end users to be able to measure the effectiveness of the implementation as well as their contribution to it.

Executive Sponsorship

Users are likely to be receptive to ideas and suggestions put forth by their executive leadership. If the leadership endorses the technology as well as champions its use, then the rest of the rank and file will likely be more receptive and ultimately less resistant to adoption.


Even though all of these points may seem to be effective separately, they should be considered in unison. Focusing only on one is not enough. Adoption is, in large part, an emotional business and you need as many tools in your arsenal to engage users and drive adoption.

Avoiding a Leaky Scope Bucket

July 1, 2014

There’s a hole in the bucket, dear Liza, dear Liza,
There’s a hole in the bucket, dear Liza, a hole.
– children’s song, Bergliederbüchlein (c 1700)

In my prior article, I introduced the concept of a scope bucket to explain the concept of project scope to your stakeholders.  In this article, I continue the theme with some tips for managing and delivering the scope in your project scope bucket.

Read more

A Bucket of Scope

May 13, 2014

An architect relies on a clear understanding of scope.  In prior articles we have discussed the business context diagram, a great tool for establishing solution scope.  We also provided a technique for setting expectations regarding the scope of architecture activities.  In this article, I intend to expand on the importance of understanding (or establishing, if you are in a project lead role) the scope of a project.

Read more

Identify Indirect Stakeholders with System Context Diagrams

April 16, 2014

A Systems Flow consultant has skills that tend to fall in the triangle of technical, business and organizational excellence. One common and repetitive case of project dysfunction where this overlap brings real benefits is that of the “Operational Business Stakeholders Missing from Business Requirements.” Here’s how it usually goes:

  1. Architect is engaged to design project’s solution architecture (using the Investigative Architecture™ method)
  2. He/she is provided business requirements to review and comment on, to ensure they are fit for high-level design
  3. The requirements (hopefully) clearly state the end-user and product/service-centric objectives
  4. But how the end-users and the new/enhanced product or service will be supported operationally is completely missing
    Read more

Next Page »