One of life’s great joys is the oh-so satisfying feeling at the end of a project that went well:

• Thorough discovery focused on aligning requirements to the organizational goals for a project
• Reviewed solution design with sponsor and stakeholder rep who were thrilled
• Trouble-free implementation
• A few minor fixes in testing; validation came back clean
• Users are trained and excited to use the new tools

A few weeks later you connect with the users for a “now that you’ve had a chance to get used to it” Q&A.

Nothing is really wrong, but there are very few questions, and none of them are about the features they or the sponsor were excited about at launch. You ask if they are using them, only to learn that the users’ stakeholders are asking for the same reports and metrics they always have.

I have been trying to crack this nut for years, with some success. Then I took a Change Management course that provided very valuable new perspectives. I’ll describe what didn’t work, and some more effective approaches I will use going forward.

Communicating with Strategic Intent: The limits of organic adoption

When users would report back that they were getting the same old questions despite having fancy new tools, I responded based on what I would do. I’d encourage users to:

• Deliver the requested data, but when a stakeholder has an ask that could be improved upon based on new functionality, also offer related information and analysis now available.
• Offer that if the first suggestion isn’t helpful, they might be able to suggest more pertinent information if the stakeholder wants to share what questions they are trying to answer.
• Over time, users should work to be seen as SME advisors.

I maintain that this is entirely valid advice to people reporting data. But it doesn’t get the organization to use the solution to its fullest as quickly as possible. It is slow and sporadic, relying on countless repetitive (at least from the analyst point of view) conversations, with the right questions and data to provide the opportunity, all against a backdrop of a reasonably open-minded culture.

Change Management is about how to make that kind of change adoption happen at scale. To get stakeholders asking questions that take advantage of new tools quickly, we need to have an intentional strategy to communicate the change with them.

Ignoring Preferred Sender of Key Messages research

A crucial part of a change communication strategy is the concept that people tend to receive information about a change more readily if it comes from the right sources.

There are two preferred types of source, each being better for a certain kind of message:

• Messages about the big picture, like why we need to change and how the change supports our organizations’ goals, are best delivered by senior management or executives.
• Messages about what will change in people’s day to day work, like what the change will actually require work-wise and what the benefits to the individual and team will be, are best delivered by their own manager.

This raises another weakness with our original approach: not only are we relying on the sporadic instead of the systemic, we are sending these messages through the wrong people.

Maybe we’ll get lucky and already have Change Management

We’ve established the need for a strategy to help move stakeholders through analytics change, and that the communication in that strategy is best delivered by people in specific roles. But do we need to take this on ourselves?

Reinventing the wheel is a waste of time, and trying to do someone else’s job can start a turf war, so step one is to take advantage of the Change Management investments you already have access to.

If you are in-house, maybe there are Change Practitioners somewhere in or around HR just wishing that the project teams in the company would integrate with them more closely, and you are off and running. Or you might be with an org that has never heard of Change Management and doesn’t like the sound of it, in which case you might need to be more hands on.

On the agency side, this can be a bit trickier since you are working through a point of contact and sponsors that may or may not have the appetite and relationships to secure the Change Management resources you want to integrate with.

I’m handling it by making it clear that I’m enthusiastic to integrate with a prospective client’s Change Practitioners, and that my Change Practitioner certification means I’m not just winging it in that regard.

If a client answers that they don’t have a Change Office or Practitioner, I’ll offer to supply some elements they would usually provide.

Up Next: Crafting an analytics stakeholder communication strategy without the benefit of experienced Change Practitioners

So what do we do if our or the client’s organisation doesn’t have Change Management professionals to allocate to us? Ok, now we have to figure out at least some minimal plan if we want to see people get the full value our solution can deliver.

The next post will look at exactly that. If you want me to hurry up and post it, or you have any thoughts or questions, please let me know in the comments below.

The post Upgraded analytics tools, trained analytics users: same old questions? Change Management explains why appeared first on Informed Iteration.

Mix in a couple Radical Analytics principals from Stéphane Hamel, and you end up with a pretty good way of looking at how to best help our users with their requests.

Why – Understand It Like It Was Your Own

As the requirement recipient, you are the bridge between the person that understands the problem, and the org’s analytics resources. That means you need to understand the problem, and what your org can do with analytics. The good news is that you’ll build an ever greater understanding of your team, resources, and tools by virtue of working with them.

The even better news is that the user request side of things will be a never ending series of often totally unforeseen and fascinating topics that will keep your work interesting. It’s crucial to your performance that you understand what users are after – specifically what people want to do and why. Unforeseen questions can often be handled by someone that gets the “why” of a request without having to make that round trip to the original user.

Asking why is a very powerful  business tool, even formalized in the 5 Why method, which you might want to consider using. Getting people to talk about why they are doing something gets them away from talking about what they want you to do, and focuses the conversation on their activities and goals. That leaves room for you and your team to add value by considering solutions the user wouldn’t know about. More on this in the next section.

What – Never Ask, Alway Propose

People might try to tell you what analytics solutions they think they need, or even how to do what they think they need, instead of telling you what they are trying to accomplish. Remember that you and the analytics team can figure out how to track, report, and analyze just about anything, but you can only do a good job of that if you know what the analytics user is trying to do, and why.

Depending on the ask, goal, and need, the solution might be obvious to both of you. If it’s not, present some options you can discuss. The point is to get people talking about solutions without inviting them, let alone forcing them, to think of a solution without your help. You are the one that knows about using analytics to help people succeed at marketing – don’t rely on your users to take the lead.

This principle comes from the Never Ask, Always Propose, part of the Radical Analytics series by Stéphane Hamel. The series is a fantastic look at things that are wrong with our industry, and what we can do about it. I enjoy doing analytics more now that I’m applying it.

Note that you don’t have to come up with great options on the spot. You can let someone know you’ll get back to them and give yourself a chance to do some research or talk to your team. If you are just spitballing ideas on the spot, make sure you tell people that, and avoid promising something you aren’t sure you can deliver.

Who – The Good, The Bad, and The Ugly

We aren’t going to categorize user requests with those three terms, and certainly not the users making them! They are just to break down reasons it’s important to consider and pass along who is asking for the analytics work.

The Good

Understanding who is asking is often the first step to understanding why they want to do something, and a crucial part of scoping a question. The quality of communication you have with a person is greatly influenced by how well you know them. Sometimes, someone on your team will have a relationship with the asker, or at least experience working with them, and can leverage to find a better solution. Of course, in a larger org, you’ll need to keep track of this just so you remember who to tell when something is done.

The Bad

Who do you reach out to if there’s something to clear up, or a deadline that will be missed? Perhaps more importantly, who does whoever is working on that ticket reach out to when they get your auto-repsonder about recovering from surgery for the next couple weeks?

The Ugly

Different people in your org have different levels of ability and inclination to make you and the rest of the analytics team happy or miserable. As much as it can hurt people like us, who value transparency and accuracy, it is in your interest to take this into account when prioritizing who’s stuff gets done first, and how to frame your response. Faking report results to humour a CxO is unethical. Doing something you don’t think is the best technical solution, use of resources, methodology, etc, once your politely but clearly disclosed objections are noted, overruled, or ignored, is part of working with others.

Before you run off to get the “c-suite buy-in” often presented as a silver bullet to every analytics problem, Stéphane’s Radical Analytics lets some of the air out of that myth, and presents a great, sustainable strategy for analytics pros to grow influence in an organization.

Where – Online Is a Big Place

Make sure you clearly understand the scope and targeting that are called for. Very often, people (including me) with decades of experience working in places that have dozens of websites, a bunch of social media accounts, several agency partners, and huge numbers of campaigns, will refer to whichever piece of the puzzle they happen to be thinking of as “the site/account/agency/campaign.”

Are the new content and forms we need to track going up on all the properties? Or just on the English part of the US site for now? Or it’s actually going on a new subdomain?

It’s incredibly easy for someone working hard on something to leave out a detail that is obvious to them, but unknown outside the people really tucked in to that project. Help avoid misunderstandings by double checking on context.

A standard request form or ticket format can help make sure this is clear in every case. Don’t use it as an excuse to avoid a conversation though: it’s there to make sure all the important stuff is covered, not to allow the important stuff to be glossed over and assumed.

When – Preferably Before the Campaign Ends

People are usually pretty good about letting you know when they need something. Unfortunately, depending on resources and culture, not every ask will get done, and it can take a lot of diplomacy to help users understand when their needs can’t be the priority. Try not to leave people empty handed: if new interactive dashboards aren’t in the cards for this quarter, can you at least get the data into a custom report to tide them over?

A lot less thought and discussion goes into how long something will be needed, which is almost as important. Tags that only needs to be around for a short campaign or promotional event don’t require the same degree of thinking about maintenance consequences. It might get added in a faster, simpler way than if the team has to worry about how the tags will have to behave as the site and analytics solution evolve.

Something needed now that doesn’t need to last a long time is usually ok, and something that needs to last a long time but isn’t needed right now is usually ok. Trying to get something that requires long term planning done in a hurry is where you run into problems.

Consider a phased approach if the priority and timelines justify it, particularly if your org or team use Agile. Get a temporary and easily reversible solution in place quickly, then make a new request out of making a long term solution.

Sometimes, it’s a lot easier to wait and do something as part of a larger update or new build. Sometimes, when you go back and ask the stakeholder how things are working out and if there’s anything they want tweaked while you set up the long term solution, you find out that the campaign was a bust and they don’t need the tracking anymore.

Either way, the user got what they needed while your analytics team judiciously conserved resources, and kept the tag container from turning into martech’s answer to the Mutter Museum of Medical Oddities.

How – That’s 6 Questions and You Don’t Start with W

You’re right, we’re done! How is a different thing entirely, in that it’s not up to business to figure out how you are going to implement their requirements for you. That doesn’t mean you should be dismissive if they mention something technical: the last thing you want is a culture where people don’t tell you stuff because they are worried you’ll be frustrated with their lack of understanding.

With less analytics knowledge, they are even less able to determine what is obvious to everyone and what has to be mentioned. And it’s not like we’re 100% accurate when we are deciding what to assume and what to ask. You’ll usually fair better in an environment where people freely mention their concerns and don’t get a bunch of eye rolling in response.

Be reassuring about stuff that is obvious, and be thankful when people give you info that turns on a light bulb. Outright tell them how that info is useful and changes things, without getting technical. Over time, you’ll build a shared concept of what is par for the course and doesn’t need discussion, vs what might be out of left field and require some extra notes.

Let me know in the comments if you have any questions about how this could work in your organization, or if you have some tips to share about how you better understand your users’ requirements.

The post The Five Ws of Analytics Business Requirements appeared first on Informed Iteration.