3 steps to increase user adoption and ROI: #1 Use Simple Terms

Step #1: Describe the business problem and solution using simple terms

User Adoption - Simple is BeautifulI dare you.

I dare you to ask someone to describe their current project to you.

If you take me up on my dare, you’ll probably hear the person ramble on much longer than necessary. When they’ve finally finished talking, you will most likely not have a very good understanding of the business problem or how the project intends to solve it.

Why is this?

Here are three reasons why this is the case.

1. We are not prepared with a well-structured explanation of our projects (yes, the concept of the Power of a Canned Response works here too).

2. We don’t focus on the problem-impact-solution-benefit combo (focusing too much on the solution).

3. We tend to over complicate explanations, and if we are in a technical role, we often overuse technical terms.

Meet Max and his not-so-great project description

Max is in a meeting with a group of people, which includes stakeholders for a new project that he’s recently been assigned to lead. The discussion turns to a challenge that relates to the scope of Max’s project. He decides it would be helpful to provide a description of his project to the group.

Here’s what Max says:

“I just got assigned to lead a project that . . . uh . . . kinda relates to this. We’re in the process of working out the details right now, but um . . . uh . . . well basically,  we plan to create a  . . . um . . . a SharePoint portal [author’s note: if this sounds like you check out my post Killing the dumb um]. We are going to leverage AD FS, so SSO should be handled. Anyway, it will support streamlined access and collaboration on documents especially with the SSO piece.  We are going to allow access to documents currently housed in distributed data repositories. I think the plan is to support both internal docs and docs at partner sites . . . well for most partners as a few have a better solution already. Anyway, we’re also going to leverage the workflow features of SharePoint too. You can do a lot with that. Um…I guess that’s all…<trailing off>. Oh, and we’re thinking about . . . . oh . . . I think I already mentioned that. Anyway, it should be pretty cool.”

It should be pretty cool?

Are you kidding me?!

Max was just speaking to a room full of people that included stakeholders for his project, and he ends with “It should be pretty cool.” Actually, that’s the least of the issues with his message. Let’s take a look at the bigger ones.

Why was Max’s project description so bad?

1. Max’s description was more of a ramble. It lacked any sort of structure. He talked too much, was not in command of his message, and included things that weren’t necessary (e.g., “well for most partners as a few have a better solution already”). This all indicates that Max did not think through the description in advance (read: planned), and if Max cannot plan a simple description to his project (something he will likely repeat many times), what does that say about his ability to plan and lead the project? Answer: Not much.

2. The response was very solution focused with a few not-too-clearly-defined benefits woven into it. It was basically devoid of the business problem and the associated impact to the business.

3. Finally, even in the area on which Max did focus — the solution — his description was confusing, and he used too much technical jargon.

Max’s description IS NOT a good example of Step #1: Describe the business problem and solution using simple terms – the first critical change-management step to drive user adoption and Return on Investment (ROI). 

I’m not saying. I’m just saying.

You may think that you don’t sound like Max, and maybe that’s true, but I have to tell you. I’ve listened to and read a ton of project descriptions, and unfortunately, most of them sound like the one Max gave. No high horse here. I’ve been just as guilty myself.

Why do so many of us sound like Max?

Below are four reasons why so many of us sound like Max.

1. The curse of knowledge. We know so much about our project and our world (i.e., our industry, our job, our jargon) that it is really hard to “dumb things down” in a way that a layperson can easily understand. It really is difficult to think from the perspective of someone for whom this is all new.

2. We want to impress people. If we’re being honest with ourselves (and many of the people with whom I have shared this reason do admit to it) we often try to impress people by using terms that the reader/listener may not understand. We do this to try to look smart.

3. We feel the need to be complete. Some of us have the innate need to give the complete picture of everything. It is as if by not doing so we would feel somehow dishonest. This include-every-feature-and-scenario approach is a key driver of long, confusing project descriptions.

4. We don’t plan. Many of us don’t take the time to create a planned response that hits the problem-impact-solution-benefit combo. Even the planners among us tend to ignore this.

How do people react when we talk like Max?

Perhaps more important than why we talk like Max is what happens when we do talk like him.

When faced with a project description like Max’s, many stakeholders will check out and simply stop listening. You’ll see it in the glazed-over look in their eyes and the quick transition from engaged listening to looking down (at laptops, phones, or tablets).

In short, they fail to engage. The failure, however, is ours.

What’s the impact of a poorly-communicated project description?

Let’s look back at the formula from the introductory post of this series on user adoption and ROI.

Problem + Solution + User Adoption = Return on Investment
[The solution, coupled with solid user adoption, DOES result in a return on the investment you made to create that solution.]

This formula makes the point that user adoption is critical to achieving ROI. Okay, so how do you help ensure solid user adoption?

Answer: Engaged Stakeholders

A very critical factor to solid user adoption is stakeholder engagement. By delivering a bad project description, you not only damage your credibility as a leader (leaving people to question your ability to “pull the project off” in the first place),  you also threaten your ability to achieve the user adoption necessary to achieve the target ROI for your organization because you’ve alienated your stakeholders.

Think I am overstating the importance of a simple project description? Don’t be so sure. When a person clearly and succinctly communicates they immediately gain credibility as a polished, professional leader. People are drawn to that and (rightly or wrongly) associate that person with many positive leadership characteristics.

Max Revisited

How could Max have done a better job?

Well . . . he could have:

1. Planned out a well-structured explanation of his project;

2. Focused on the problem-impact-solution-benefit combo; and

3. Ensured he was not over complicating his explanation or overusing technical terms.

If he had followed these steps, perhaps his project description would have turned out something like this.

Intro and Business Problem Set up: “I’m leading a project to address many of the challenges we’ve been discussing that relate to collaborating with our colleagues and partners.”

Business Problem: “How many of you have been frustrated with our current, cumbersome process of emailing files back and forth; the difficulty of accessing files stored in our partners’ systems; or the inability to easily collaborate on a document with colleagues in other locations?” [heads nod] “How many of you have experienced your approval requests going into the ‘black hole’ of pending requests?” [more nods]

Impact: “This is not only a frustration for us, it costs our company real money in lost productivity — not to mention the PR problems with our partners.”

Solution/Benefits: “The solution we’re creating is a collaboration website using Microsoft’s SharePoint software. It will provide (1) easy collaboration no matter where people work; (2) the ability to easily access files no matter where they are stored; and (3) approval workflows where you always know the status of your requests. All of this will help to reduce our lost productivity and improve our current PR problems.”

Close and Bridge: “Some of you are direct stakeholders to this project. We will be reaching out to you for your input and support, but if any of you have immediate questions or input, please feel free to reach out to me directly.”

One minute and seven seconds. Time it yourself and see.

And don’t worrying about scripting your description exactly word for word — unless that works for you. It’s fine to remember the key points and to let the details come out naturally.  This flexibility allows you to tailor the business-problem examples to the specific audience.

Here are the key points to Max’s revised project description (he texted them to himself so he could pull them up as a reminder when needed):

  • Frustrations
  • Productivity/PR Hits
  • Collaboration Website
  • Frustrations Resolved
  • Money/Time Saved, PR Improved
  • Reach out to me

As you can see, Max’s revised description is well-structured, focuses on the problem-impact-solution-benefit combo, is not overly complicated, and avoids the overuse of technical terms.

This now IS a good example of Step #1: Describe the business problem and solution using simple terms.

With this revised project description, Max has performed a critical step toward establishing strong stakeholder engagement, which in turn will help ensure solid user adoption and ROI. He’s also made a strong impression, which will likely translate into people viewing him as a strong leader.

Oh, by the way, which of the above project descriptions would you rather hear when you take me up on my dare to ask someone to describe their project to you?

I wonder which type of response you will actually get. Try it out, and leave me a comment on what you hear and how enthusiastic of a stakeholder you would be of the project.

Check out the posts in this four-part series on user adoption and ROI.

3 steps to increase user adoption and ROI: Introduction (my dog Gus teaches me a valuable lesson about user adoption)

3 steps to increase user adoption and ROI: #1 Use Simple Terms (this post on using the problem-impact-solution-benefit approach)

3 steps to increase user adoption and ROI: #2 Know Your Stakeholders (the Power-Interest Matrix and the importance of knowing your stakeholders)

3 steps to increase user adoption and ROI: #3 (coming soon)

Share

Share on LinkedInShare on TwitterShare via email+1Share on Facebook