As a young man I remember talking to my Dad and telling him that Microsoft was the most important and powerful company in the world. He kind of laughed and gave me that knowing Dad look. He “knew” that the real powerful and important companies were the likes of GE and GM. I tried to argue my point, but to no avail. He always countered with, “What am I going to do with a computer?”
Clearly the world has shifted. Today, software is a fundamental element of every organization’s infrastructure, and if that software is not operating as intended, the organization will suffer. Every effort is made to ensure that the software works well, and most companies do a great job of making sure the technical side of that need is addressed. What frequently gets missed is the people side of the equation. What if users are unwilling to use the software? One of my favorite sayings is,
If the user resists, the project fails, no matter how good the technology is.
I am writing this whitepaper to look at software adoption and user engagement as critical components of any software deployment.
Software adoption refers to the level of use a software system achieves as compared to the intended level of use. The successful deployment of a software system is typically predicated on user adoption reaching intended levels. When user adoption does not reach intended levels, the anticipated benefits of the system will not be realized.
There is no single, clear-cut way to ensure or measure software adoption, as every instance has unique circumstances that must be considered. Though, there are practices that can increase the probability of a successful software deployment by taking a planful approach to software adoption factors. This paper outlines that set of practices.
Many studies over that past several years (e.g. 1, 2, 3) point to a disturbingly high incidence of software deployment failures that are products of low levels of adoption. When users choose not to use a new system the consequences can include:
- loss of data not properly captured or processed
- reduction in productivity as users spend time creating work-arounds to avoid the system
- redundant effort resulting from excessively running old and new processes simultaneously
- employee dissatisfaction
Software adoption improvement practices can address these types of problems at a fraction of the cost of the losses otherwise incurred. A strong software adoption improvement program can also generate discrete benefits, beyond loss avoidance, in the areas of innovation and increased user engagement.
There are three fundamental elements to be considered when addressing user adoption of a new software system. They are:
- Organizational change
- User experience
Each of these disparate disciplines must be integrated to create an effective software adoption improvement program.
For the purposes of this discussion, I define organizational change as the behavioral and procedural changes that are necessary within the organization to achieve the desired outcomes of the software deployment initiative. To effectively deal with these changes it is necessary to:
- Identify the changes
- Socialize the changes
- Effect the changes
- Validate the changes
All of this must be done within the context of the business objectives behind the software implementation initiative.
As stated previously, users must actually use software in order for it to have impact. To get users to adopt new software, they need to be prepared for the changes involved. If we look at the Prosci ADKAR framework of change, we see that the first two elements of change are “awareness” and “desire”. For software users to be aware of the change and for them to have a desire to use the software, the project owners need to do three things.
- Create clarity
- Provide transparency
- Have empathy
These activities are crucial to creating user engagement.
In any endeavor that promises to deliver a solution, there must first be clarity around the question, “What is the problem we are trying to solve?” More often than not, projects lead with technology, features, and solutions without explicitly stating the problem. Without clarity, different stakeholder groups may well be trying to solve different problems. This one factor leads to more problems in communication than any other. Ultimately this miscommunication yields frustration and resistance by the users.
Before any active work on technology or features begins, there should be clarity and alignment around a common understanding of the problem statement.
Project transparency is about letting stakeholders see the process from start to finish. When users can see the process, and the decisions that are made during a project implementation, they will have a better awareness of why the project is needed. It will also give them the opportunity to raise red flags before problems have gone too far downstream. The visibility into the process and the ability to interact, gives users a sense of ownership and will increase the odds of engagement and adoption once the software is delivered.
The mechanics of transparency will differ based on the organization and type of project. The key thing for the project team to remember is to proactively consider what transparency will look like for their particular situation. The one action that will always be necessary is to generate a comprehensive stakeholder map, making sure that every group that will be impacted by the change is accounted for.
For any software implementation project to succeed, more than lip-service needs to be paid to listening to the users. It is possible to do more damage than good with surveys and focus groups if the users do not believe the efforts are genuine. Empathy is important. The project team must truly understand the situation from the point of view of the user, and not assume they know what the user is thinking.
The manner in which a user experiences new software plays a huge role in their willingness to use that software. When a project team is tasked with deploying software, user experience design should play a major role in the project. The user experience should be considered ahead of software features. If a user has difficulty accessing even the most basic functionality then they will form a long-lasting negative impression of the system. New features can always be added over time, but that initial experience can never be revisited.
Designing an excellent user experience leans heavily on one of the concepts introduced earlier, empathy. The designer must see with the user’s eyes to design an experience that will not be a barrier to adoption.
To understand if your software deployment has achieved the desired level of adoption, appropriate measurements must be defined in advance. These measurements must cover more than just usage levels, they must also address business value received. Usage metrics and business metrics must be combined to identify how adoption levels and user engagement have contributed to the overall outcomes.
The business metrics need to be related the identified problem statement. If that problem is not solved, the desired business value has not been obtained.
The most important usage metrics should relate to the change in usage. There is typically no specific number that defines good usage, but an increasing rate of usage is usually a positive indicator.
A software adoption improvement program (SAIP) is stakeholder driven. An SAIP can be broken down into four primary stages:
- Initial Stakeholder Map Creation
- Stakeholder Map Confirmation
- Stakeholder Communications
- Self-Sustaining Stakeholder Network
These stages are not necessarily linear steps, but rather an indication of the maturity of the stakeholder relationship to the project. For this discussion we will look at the evolution of the maturation process as linear for easier understanding.
Throughout each stage of an SAIP each of the elements are considered: organizational change, user experience, and measurement.
Initial Stakeholder Model Creation
“We need to do something.” And so it begins, a new project is started. The catalyst may be a top-down edict, a grassroots movement, or anything in between, but in any instance, it will be a small group that will take the first few steps. The first question that should be addressed is “what is the problem we are trying to solve?” This initial group should have a pretty good idea of the answer. More importantly they should understand that various stakeholders of the project may have different answers to this question, and it is the job of the project team to fully understand those viewpoints. Therefore the first task of the core project team should be to draft an initial stakeholder map, a best guess of impacted stakeholders and what that impact might look like.
Stakeholder Map Confirmation
With the initial stakeholder map in hand, the next step is to confirm the map’s veracity. This is an outreach process, but not with the intent of delivering information. Stakeholder map confirmation is about listening. Approach representatives of each stakeholder cohort with a general concept of the project and its objectives, then listen to their reactions. Do not attempt to convince or coerce at this point. The purpose is to learn as much as possible in an effort to design the software for success.
Along with gauging reactions, you should also mine deeper and find out if there are other stakeholder groups that have been overlooked.
This stage should be seen as the opening of a dialogue with the stakeholders, and an invitation to them to be active participants and partners in the project. This establishes the clarity, transparency and empathy that should endure through the course of the project.
Stakeholder communication escalates the dialogue beyond stakeholder representatives to the entire stakeholder populations. The conversation will begin with a more filled out description of the project, its objectives, and deliverables. The intent of this stage is to ensure broad awareness of the initiative, and to open a channel for feedback from stakeholders. For best results, this stage should occur at a time when modifications and improvements to the software and supporting processes can still be accomodated.
This stage should evolve over time from a place where information flows primarily from the project team to the stakeholders, to a state where the stakeholders are directly engaging the project team and are comfortable providing feedback.
Several tactics can be used at this stage including the use of champions, gamification, and recognition.
Self-Sustaining Stakeholder Network
If the stakeholder relationship has moved successfully through each of the previous stages, and a positive and trusting relationship has been established, the interaction between the team and the stakeholders should become natural and self-sustaining. If this stage is reached, the project team and the stakeholders will evolve to a partnership, where the roles between those delivering the software and those using the software become blurred, leading to an active and ongoing conversation.
This stage can only be reached when clarity, transparency, and empathy are core tenets of the project team’s operating model.
If we consider a standard software deployment initiative, the project phases will look something like this:
Setting aside distinctions between project methodologies (Agile, Waterfall, etc.), this model is consistent with my experience. I use this model here to highlight the differences between the stakeholder driven SAIP methodology described above, how software adoption issues are typically handled, and when stakeholders are an afterthought to technical considerations.
|Project Phase||Stakeholder Driven SAIP||Typical Deployment||Technical Deployment|
|Charter||Stakeholder Map Creation|
|Plan||Stakeholder Map Confirmation||Identify Stakeholders|
|Development||Stakeholder Communication||Limited focus groups and surveys|
|Test||Self-Sustaining Stakeholder Network||Hand-picked users asked to help with testing||Hand-picked users asked to help with testing|
|Deployment||Self-Sustaining Stakeholder Network||Mass communication about the initiative; Training opportunities listed||Mass communication about the initiative; Training opportunities listed|
|Support||Self-Sustaining Stakeholder Network||Ad Hoc training and problem resolution as needed||Ad Hoc training and problem resolution as needed|
The stakeholder driven SAIP approach does require more effort up front, but that effort will be significantly less that the effort required by the support function in the other scenarios. When users are not aware of the pending changes until the last minute, have no desire to make the change, and have no knowledge of how to change, support costs will increase dramatically. On top of that, delays are common as unplanned efforts to convince users of the value of the project are required.
Engaging stakeholders early and often provides multiple benefits, including:
- Better software
- Higher levels of productivity
- Higher levels of user engagement
- Lower deployment costs
- Shorter “time to value”
- Increased probability of meeting ROI predictions
I have tried to make a case here for including stakeholders early in the software development and deployment process. My experience is that this involvement in most instances does not happen early enough. My recommendation is that any software initiative should include a stakeholder advocate as part of the core team from day one.
Software Adoption: Improving Software Deployment Through User Engagement by Lee White is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
Based on a work at https://insideconversation.wordpress.com/2015/12/21/software-adoption-improving-software-deployment-through-user-engagement/.