Plan For User Adoption

By Bruce Johnson

Plan For User Adoption

One significant cause of failure in analytical solution projects is allowing enough time for adequate user adoption of a solution.  Too often, solutions are viewed only as technical projects and the project is recognized as complete when the database is populated or the tool that will provide reports or ad-hoc query access is put against it.  While the technical parts of the effort appear to be complete, as the users first begin to navigate the data and the tools with live production data, there will be several necessary enhancements and fixes that will need to occur in order for the customer to see the solution as effective.  When this occurs, the result is often an unhappy user.

The prevalence of this occurrence on analytical efforts seems to be increasing.  Let’s investigate in a little more depth some of the causes of this and what you can do to mitigate this end-result on your projects.

 

Root Cause

Often users are upset because they hear IT call a project complete and they do not feel like they have a workable solution.  Ultimately, no one set the expectation with them that an appropriate adoption time frame was needed and how the enhancements and fixes that go along with that are natural and necessary components for a successful project.  Although it is not easy to establish this with users, it is indeed necessary.

Recently I was asked to review a solution for a client where the client was very upset about a project that was delivered by a consultant from a large organization.  Upon review, I can tell you that the solution delivered was technically sound, data quality was consistent and reliable, and all technology layers were applied appropriately.  They had extremely detailed usage requirements (perhaps too detailed), and solid data requirements to support that usage.  Not to mention the project was delivered on time and on budget. 

The problem lay in that the consultant came in and did exactly what was asked for technically, implemented exactly what they agreed the client wanted, and then was no longer engaged.  The consultant would contend that with great requirements, they did exactly what they said they would.  Too a great extent, they would be right.  However, the client was left with a solution that they didn’t understand, didn’t have a chance to proof, and wasn’t confident in where the data had come from.  Ultimately, with some tweaking, adding some newly generated usage scenarios, and training, the client had the original solution now working and was extremely happy with the end output.  The original consultant was still seen as having done a poor job.

Plain and simple, the root cause of this goes back to the original project plan.  Time was not allocated for the adoption and rollout of the solution, let alone adequate time for training and simple documentation for users.  Usually, this is a trait or characteristic of “build it and they will come” technically driven solutions.  It can also be a characteristic of user driven demands for how a project should be run and getting the consultant out as soon as possible to keep expenses down.  In either case, experienced parties should know enough to require that time in order to ensure success.

 

How Does It Fit?

When trying to plan for the adoption and rollout of the newly built solution, it is important to consider the business need and complexity of the solution.  This has to be a very interactive time period.  Work during these tasks involves reviewing data and metrics.  Validating calculations and derivatives in relation to how the users now decide to leverage this new found data.  Many experts say that you can work all of the details out during the detailed requirements gathering process.  I contend that you can work a small amount of the calculations and derivatives in the requirements process, but most need to be validated once the data and solution are in place.  If you store all of the data used to create your metrics, you can easily adjust metrics as needed once the supporting analysis defines the new or proper rules.

So, how much time is enough for this work?  Well, consider that the rollout of a data mining type solution typically takes more interaction than a pure reports based solution.  A reports based solution can be validated relatively confidently in the system and integration testing phases, while data mining is only truly accepted once a work result is completed and relevance is defined.  In your planning you need to consider key data aspects (volume, complexity, quality, and available meta data) and usage aspects (type of analytics, front ends being used, level of user proficiency with tools and approaches, volume of types of usage, and numbers of users that will leverage the system).

Once the plan is effectively created and includes time for adoption, here are some critical success factors you can leverage during the project:

  • Setting expectations with users early on in the project is the best way to mitigate the challenges that you will undoubtedly encounter. 
  • Keeping them involved in data definition, validation, certification, and metric/derivative definition will help smooth the adoption process.
  • Have joint meetings to review data/metric issues and have the users actively involved with the technical resources in tracking and fixing said issues.
  • During testing, have developers and users sitting next to each other.   This is a great time to build the base of relationships that will cement a trust between the two that will allow them to work jointly together throughout the rollout.
  • Plan for and conduct joint training sessions with the users.  Throughout the project you want to identify who the power users of the solution will be, but you also want to identify out of those power users who would be a good candidate for conducting formal training.
  • Hold a post implementation review meeting of the project about 1 month after the rollout and training is conducted.  The goal of the meeting is not to declare success, but to identify “what could we do better – as a joint team.”  This will also help in building collaborative relationships between IT and the business.

 

Summary

As you plan your projects or review plans that consultants propose, keep adoption and rollout in mind.  Neglecting this key portion of the project usually has negative consequences.  Remember to set aside time in the plan and secure the business resources that will be needed in order to put the necessary polish on the solution that further builds the relationships between areas.

About the Author

Bruce has over 20 years of IT experience focused on data / application architecture, and IT management, mostly relating to Data Warehousing. His work spans the industries of healthcare, finance, travel, transportation, retailing, and other areas working formally as an IT architect, manager/director, and consultant. Bruce has successfully engaged business leadership in understanding the value of enterprise data management and establishing the backing and funding to build enterprise data architecture programs for large companies. He has taught classes to business and IT resources ranging from data modeling and ETL architecture to specific BI/ETL tools and subjects like “getting business value from BI tools”. He enjoys speaking at conferences and seminars on data delivery and data architectures. Bruce D. Johnson is the Managing director of Data Architecture, Strategy, and Governance for Recombinant Data (a healthcare solutions provider) and can be reached at bjohnson@recomdata.com

 
Free Expert Consultation