Preface

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.

About

Introduction

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.

Value Proposition

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.

Elements

There are three fundamental elements to be considered when addressing user adoption of a new software system. They are:

• Organizational change
• User experience
• Measurement

Each of these disparate disciplines must be integrated to create an effective software adoption improvement program.

Organizational Change

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.

Clarity

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.

Transparency

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.

Empathy

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.

User Experience

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.

Measurement

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.

Methodology

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

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.

In Practice

If we consider a standard software deployment initiative, the project phases will look something like this:

• Charter/Objective
• Plan
• Development
• Test
• Deployment
• Support

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

Conclusion

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/.

Filed under: siem, Uncategorized | Leave a comment »