This is a cross-post with the Software Adoption Project. My take on why stakeholders need to be included early in any enterprise software deployment project.

Here is the link.

Filed under: siem, Uncategorized | Leave a comment »

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.

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 »

How people deal with change has been an interest of mine for most of my professional career. It is now becoming the focus of my future career track. I am in the midst of doing research to be sure I am up to date on the latest research and thinking in the area. I just found this presentation that shows strengths and weaknesses of five different organizational change models. Interesting reading (if you happen to be an OD geek). 🙂

I am particularly interested in the PROSCI:ADKAR model. I find it closely aligned to my own philosophy of addressing organizational change, particularly with respect to technology adoption.

Filed under: siem, Uncategorized | 1 Comment »

You know the saying about the cure being worse than the disease? Probably the best example of that adage these days are new IT systems that are deployed across an organization with great fanfare … and no forewarning. The common results include:

• Resistance to change
• Low levels of user adoption
• Not meeting predicted ROI
• Over budget
• Missing deployment milestones

I would be surprised if these outcomes were not familiar to you. Many IT projects are plagued with these results. One key to getting better results is to include people, culture, and process considerations along with technical specifications from the beginning of the project. Wouldn’t it be nice if the people that will be using a new system were an integral part of the design and deployment of that system? With this thought in mind, I would like to ask for your help.

I have been out of work now for more months than I care to count. Recently, I reached the point where I needed to re-evaluate what I was looking for and how I was going about it. The bottom line is that I have been shooting too broadly, hoping to connect with any position that was generally connected with my experience.

I have spent the last few weeks trying to re-focus on what I really want to do and what I do well. I want to articulate that vision in a way that an organization can see the value I bring to the table. So here it is: I am looking for situations where organizations are deploying new technology, and need help with the people and process aspects of the deployment. Studies have shown that many IT deployments fail, not for any technical reason, but because little planning or thought was put into how to engage end-users and other stakeholders in the system design and deployment. I have 20+ years experience doing just this, deploying technology so that users “get it” and willingly make the necessary changes in process and behavior to achieve desired results.

If you know of any organization or situation where a technology adoption specialist would be of value, please pass my resume along as appropriate. I am interested in either full-time positions or any sort of part-time/temporary/freelance situations. I am focused primarily on working in the Raleigh/Durham/Chapel Hill area of North Carolina, but I am willing to work remotely from my home, and/or travel as necessary.

Thanks.

Lee White | Phone: (919) 280-5925 | Email: leewhite.nc@gmail.com

Filed under: siem, Uncategorized | Leave a comment »

There is no secret that the success of information technology projects ultimately depends on whether or not the technology gets used. If you deploy it and no one comes to play, what good has it done. Getting users engaged is a critical element of project success. Gartner pointed this out almost 10 years age in their report, “The users view of why IT projects fail”. The key to success is to have a plan for user engagement and adoption as an integral part of the overall project plan. This is not something that can be tacked on at the end “if we have some money left”.

Didier Bonnnet of Capgemini recently published and article in Harvard Business Review that is on point here. He says:

When these platforms are introduced, organizations too often focus only on deployment, not adoption. It’s remarkable how commonplace it is for leaders to lose sight of the true ROI of their digital investments.

As organizations turn more and more to technology solutions to improve efficiency and effectiveness, there needs to be increased effort put into the people and process aspects of these deployments.

Filed under: siem, Uncategorized | Leave a comment »

Ultimately the success of any IT system boils down to, “Is it being used?”. No matter how good the ROI projections are, or how advanced the technology is, or how little it costs, if users are resistant to making necessary behavioral changes, the final result will be seen as a failure.

I found this post by Nuvem Consulting that details the potential issues with implementing Salesforce. For the most part these issues have nothing to do with the technology per se, but instead with human nature. Their key points for failure are:

1. Poor communication
2. Lack of support from executive stakeholders
3. Resistance to change
4. Failure to recognize that Salesforce is constantly evolving
5. No champion
6. Inadequate or no training
7. Processes not clearly defined or that no longer work
8. Poor data quality

Success of most IT projects will hinge, in part, on the people and process aspects of the deployment. Dealing with these issues requires a very different set of competencies than traditional IT project management. Including resources within any deployment initiative that are specifically focused on user adoption should be standard practice for any project.

Filed under: siem, Uncategorized | Leave a comment »

This morning I was thinking about the nature of problems, so, of course, I googled: “nature of problems”. What I found was this great blog post by Frank Chimero. It resonated with my own thoughts. (I am always amazed by what you can find just by looking.)

The post highlights four common mistakes we often make when considering problems:

1. We forget that there are two kinds of problems.
2. Aspects of problems are a little bit concrete and a little bit squishy, and we mistake one for the other.
3. We think there are solutions when there are none.
4. We forget that our responses to problems create more problems.

Essentially all of what he says rings true with my own experience. I might add another mistake that I see:

• We tend to confuse symptoms with problems, and thus waste time addressing symptoms instead of underlying problems.

My take away from this is that we tend to not spend enough time understanding and articulating problems in our rush to reach solutions. Finding a better way to talk about problems, is a problem worth solving.

Filed under: siem, Uncategorized | Leave a comment »

Most organizations I encounter possess a huge gap. That is the gap between concept and execution. Everyone loves to create the big idea, the grand plan and they want to get moving on it ASAP. Failure to “mind the gap” inevitably leads to failure of the initiative.

So what is in this Gap? We all know what needs to be done:

• Document the current environment
• Identify root problems
• State your objectives
• Create your plan for execution

The problem is that we rush through this part and/or don’t involve enough stakeholders. Frequently a preconceived solution is already in mind, which precludes any opportunity to be sure you are solving the correct problem. Filling this gap effectively is essential to the success of any initiative.

After years of working in the area of major organizational initiatives, I can say that the place I provide the most value is in Minding the Gap.

There are two parts to doing this well. First is creating a solid charter. The second is creating a thorough stakeholder map. Each task is seemingly simple on the surface. In fact each activity requires unique skills to do them well. The underlying theme in both activities is creating a transparent and dynamic conversation. Only through this process of proposal and feedback can all the issues be surfaced and dealt with before the tactical work begins.

This is what I do, and it just so happens this is the position I am currently looking for. As of today ( January 30, 2014) I am available for full-time or contract work to help organizations “Mind the Gap”.

Filed under: siem, Uncategorized | Leave a comment »