You’re Live, Now What?! – Data Integrity

I’d taken a break from the “You’re Live, Now What?!” series in favour of another initiative. This was one post that I’ve sat on for WAY too long. Finally getting around to posting it to the series. Enjoy!

Data is the heartbeat of many organizations today. Long gone are the days where we need to base decisions on what we “think” is happening. Instead we can, and should, lean on data to inform us on what’s really happening.

Over the past couple of years the first thing I do when I think about purchasing anything is read reviews of the product. The more reviews, the more confidence I have in the general sentiment of the reviewers. That is to say – the more information I have, the better informed I feelt.

This extends into our internal systems at work. Data is a critical aspect in our endeavor to understand how we’re doing as a company. As such, we must take steps to ensure that data has strong governance around it’s integrity. Why? Because if data is erroneous we run the risk of erroneous decisions.

Let’s be real – we are “busier” than ever. We manage multiple projects, sit in various meetings about different projects/initiatives, and have many conversations in a day. As a result, our attention to detail is compromised. It may be that we’re documenting something hours or even days after it took place, or we’re inputting data while thinking about the next three things we need to be focused on. The result? Errors.

They are inevitable. We can, and should, strive to prevent them from happening but we must accept that they will come up. With this in mind, it is essential that we have a plan to deal with data integrity challenges that may arise.

There are some tactics that can be implemented to help foster a culture of ‘clean data’.

Limit Hands in the Pot

Does everyone in the company need access to every part of the data management system? Perhaps we can identify methods to streamline process by having data flow through a data steward or be reviewed before it’s entered. Limiting the number of people that have edit permissions can decrease the potential for error. It reduces the number of people that need insight into the ‘how’ the data is entered/managed. That said, it’s important to note the value of having documentation to outline the data entry/management processes.

Data Clean-Up Efforts

Everyone is responsible for the data, so everyone should be responsible for auditing the system for data integrity. This can be done in various ways – perhaps a scheduled day each month where teammates perform random audits on records that were entered to look for completeness and/or errors. But don’t make this a ‘find the problems’ adventure – perhaps create a process whereby teammates are rewarded for excellence in data management practices.

Dashboards / Reports

Use tools like this to look for common data integrity issues. For example, set-up dashboards or reports that show records that are missing key data entries. The name of the game is to develop things that shouldn’t have any results – for example, Accounts with no Address or Country data. If results show up on the list, they need attention. If all records have been entered cleanly, the result of this dashboard/report will be zero, so, no effort needed. Of course you should look to ensure critical data is set to required where possible to avoid mistakes in the first place, but this isn’t always possible.

Training

Training is not a one-and-done exercise. It needs on-going attention. You can use tools like the dashboard/report exercise to hone in on areas that need extra attention (example: notice that you find records from user X always missing the same important information? Schedule a time to discuss with them – use it as a training opportunity but also dig into why they might be missing it as perhaps there is a system change that can be made to make things more efficient).

It’s a Team Effort

Not to be overlooked is the simple act of talking about the importance of data integrity. Bring it up in your weekly/monthly calls with the team. Talk about why paying close attention to data is important and how it pays dividends to the company as a whole. When users understand the ‘why’ behind it, they are going to be more diligent in their attention to detail when entering and managing data.

These are just a few tips. There are others ideas out there. Have some of your own? I’d love to hear them! Drop them in the comments section or engage in the social post promoting this entry.

We’re all learning! Why not learn together?

Cover Photo: Photo by Franki Chamaki on Unsplash

Advertisement

You’re Live, Now What?! – User Feedback

People have thoughts and opinions, and your users are no exception. A user base that is engaged in the system and interested in sharing their insights and system desires with you at every opportunity is something system admins should aspire to. Even users that seem to complain about everything they come across in the system are, in their own way, sharing feedback with you.

The Many Faces of Feedback

Feedback can come in a variety of ways – a discussion at the water cooler, thoughts shared in a meeting, an email directly requesting a feature or system enhancement, an IM discussion, a support case, a note under the door, a sticky note left on your chair at the office…plenty of options exist.

Capture It All…And Be Consistent

Your role is to capture those suggestions and organize them in a way that you can action them in the future. There is no shortage of systems out there to help you do this. If you do a quick search for backlog and system enhancement software you’ll get list after list of the “top 10” or “top 15” lists according to various companies. Jira, Wrike, Asana, Teamwork…the list goes on and on.

Have a Plan!

No matter how the feedback comes in and what you do with it when it arrives, if you have a set process in place for this it will eventually become an action you don’t even think about.

Example: you get an email where a user has suggested some tweaks on a specific form in the system. Your process could be that you copy that text and paste it into a new System Suggestion file in your backlog/system enhancement management tool. You add who suggested it, the date, the context of their suggestion, and your anticipated next action item for the suggestion (i.e. call user to discuss further, send response with questions A,B,C for more information, review with system advisory committee, etc.).

Have Another Plan!

So you’ve got a process by which you capture those feedback items – GREAT! But what do you do with that list?

First – do you have everything you need on those suggestions? As noted above, sometimes the  next action item might be to gather additional information from the user that suggested it. What I’ve found really helpful is to think about what I need to have enough information to explain the request to someone else. To do this, think about the W’s…

• What change/addition is the user describing?
• What is the business problem this is solving?
• Where in the system is the user seeking this change/feature?
• Who would be impacted by this change?
• Why does the user feel this would be a positive change?
• When does it makes sense to roll this feature into the system?

These are just samples. I’d encourage you to outline the questions that are important to you and your system/process/structure.

Additionally, have a schedule for this. Monthly? Quarterly? Twice a year? Point is, have some kind of systematic schedule that allows the steering committee to come together and review the suggestions.

Consistency Matters

Once you know what you need form the user, why not explore equipping them with a form that they can fill in when they have such a suggestion? Microsoft Forms Pro (err, Customer Voice…) makes creating a web-form as simple as it can be, and comes with some great features like question branching and notifications/alerts so you know when someone has updated a form.

If you know what information you need, why not ask it up front? This makes the process more efficient for you and the users, and gets you input you know you are going to ask for anyhow. It also encourages users to think about their suggestion. It’s a lot easier to rifle off an email with one line saying “I wish the system did a better job of X”. Having them fill in the form with specific questions pushes them to really think about what they are asking for and potential solutions to the business problem.

Rank It

This can be tough. Remember that people are suggesting something from their perspective based on their experience. It comes with natural biases and is rooted in their understanding of and ability within the system. Those aren’t bad things, they are just things you need to be mindful of.

Not every suggestion is going to be a good one, but providing an avenue for your users to make suggestions is important to fostering their enthusiasm and buy in to that system – it helps provide them a sense of ownership.

But because of this, it’s important to have a ranking system in place. Often times organizations will have steering or system enhancement review committee. This is the group you will need to be able to explain the ideas to, however as there are often many suggestions to review, it’s beneficial to have a ranking system in place ahead of time.

I’ve seen different ways of doing this, but the most recent method I implemented really resonated well. It was a loose composite index model for system requests. Users were asked to rate their request on key business impact metrics. In this case:

• Revenue
• Customer Experience
• Customer Growth Potential

The idea was simple. The user would fill in a form that collected key information about their request as noted above.

On the form the user would also be asked to rate the impact of this change on the metrics noted above – the scale we used was 1-5 with 1 being low impact and 5 being high impact.

I then weighted these. Revenue is pretty important, so it was worth 0.4, the other two items were 0.3. The user rating is then multiplied by this value to generate an overall “Business Impact” rating.

A user that provides ratings of Revenue: 2, Customer Experience: 4, Customer Growth Potential 3 would result in a business impact composite score of 2.9

This was part one, but Business Impact is only part of the equation. Upon receiving the submission the admin team would then add information into the index to make up the “Implementation Reality” index score. Also rated on a 1 to 5 scale, this would have the admin team rate the suggestion on the following metrics:

• Urgency
• Time to Develop
• Dependency on Others (as in, do I need to lean on other teams or vendors to get this done)
• Time Waiting (how long the request has been waiting at time of review)

Same logic – a weighting was attached to each of these; 0.4, 0.3, 0.2, 0.1 respectively.

I managed these in Excel, so formulas drove the calculations and I had a separate tab that provided an graph to rate the priority. (yes, there are likely other systems to do this, but we needed something up quickly so started with Excel).

Business Impact + Implementation Reality = Rating

Items in the upper left box were the highest impact and easiest to implement, whereas items on the right side were more complex to implement.

Enhancement Priority Matrix

This method provided me with a baseline ranking to help drive the discussion with the steering committee. I was able to articulate the weighting of each item, which helped the team understand the impact of the proposed item both on the organization AND my team, which was helpful.

That’s just one example, and I can see why some might look at this and think it’s a bit much. I’ve been in the scenario where I am trying to weight and measure the reality of implementation of a suggestion in real time during a ranking discussion. It’s not easy, so anything I can do help provide data to drive the discussion is pretty valuable.

The Overall Point

Perhaps this isn’t necessary, but a quick summary given the length of this post felt like a good idea.

• Give your users a consistent and predictable method for sharing feedback
• Capture EVERYTHING they toss your way so you have a lot to work with
  • (also, if you only keep track of the things you like or want to do, it’s kind of a form of favoritism and the reality is that this system belongs to the org, not you personally – perhaps this is a debate inducing comment…)
• Ask questions so you understand the information from the initial idea submission
• Have a ranking system on metrics that matter to your business and your team’s ability to implement
• Have a schedule for the review feedback

I feel as though this topic could have been split up into a few parts. Perhaps I’ll circle back to this at some point in the future. In the meantime, what are your tips for collecting and managing feedback from your users? How to keep track of it? How do you prioritize it?

Drop a comment on the article or join the discussion on the social post that promoted it!

We’re all learning. Why not learn together?!

Cover Photo Credit: Photo by Charles Deluvio on Unsplash

You’re Live, Now What?! – User Support

Users are going to need help, it’s inevitable.

On the heels of the last post, I’d argue that seeing support cases is a sign of effective adoption (well, that’s probably a bit of stretch, but, it *could* be accurate in *some* cases!).

Supporting your users through their system journey is key. If you’ve been following along, you may recall the tidbit from the Training Framework post about ‘teach a person to fish, you feed them for a lifetime’. Well, sometimes the fisher-person needs some help getting the line untangled. We want our users to feel motivated and confident, even when they have questions.

What is the Point of Support?

First off, let’s ask ourselves what the point of supporting the user is. In my opinion, there are two key types of support:

• Functionality issues (product – as in, the system isn’t doing what it’s supposed to)
• Knowledge gap issues (user – as in, the user isn’t doing what they’re supposed to)

In both cases, it’s important that the user feels heard and you acknowledge you are aware of the issue. To this end one could gather that the point of user support is to ensure your users know you are there for them.

If it’s functionality related, you are going to need time to triage. Users want to do their work, so this requires a bit of a balance. In my experience the simply acknowledgement that you see their note about the problem and are aware provides assurances that you/the team are “on it”. I find these don’t need to be lengthy or complex – a simple “OH! Thank you. I’m digging into it now to get a sense of what’s going on!” can suffice.

If the issue is a knowledge gap, we’re in a slightly different ballgame, though there are some consistencies. First off, you may not realize it’s a knowledge gap item just yet, and triage it the same way you would a functional issue. Upon your own test you confirm it’s working as intended, and as such we now enter a period where we need to support the user through that knowledge gap.

This can be done with a quick explanation, or screensharing call to walk them through the process, pointing them to support resources that exist for the area of the system they are struggling with, or a combination of these things. Sometimes how we respond depends on how they approached us.

Oh The Ways To Reach You…

There are various ways incoming support requests arrive from your users….

They could ping you in Teams or another form of IM.

They could email you.

They could open an internal case.

They could call you.

They could yell over the office divider to you.

They could send you a carrier pigeon with a note.

They could swing by your office with candy or donuts or coffee and dangle it just out of my grasp until I answer their question (may or may not have happened before…to a friend. Ya, an admin friend. That.)

I think the manner in which you handle incoming support calls from your users depends heavily on the volume of those users. Not solely because there are some important data aspects you should consider which we’ll talk about, but generally speaking if you have two users and they are in close proximity the framework for user support is going to look very different than a user base that is geographically spread out.

But the underlining theme to whichever method you choose is that you need to demonstrate patience and a genuine desire to help. Predictability is key so users know what to expect when they put forth a request. This helps disarm users. I don’t mean users are angry or hostile, but let’s not forget that until they ran into this problem they were on their way to do a task to accomplish a goal and the fact they ran into a hurdle means they cannot complete that task therefore not reach that goal. They could be stalled until you get to them.

It’s More Than Troubleshooting

One of the considerations you may want to make about how you accept support requests is around how the data of those requests can help you. The most obvious scenario is that by collecting insights about the request, you can review those to understand trends in user behaviour or challenges with the system design.

Example: If users are constantly getting stuck on how to input information into a specific part of the form, perhaps the form design needs a review.

But like all analytics, depth of data is important. Just because one person had trouble finding that section on the form does not necessarily mean a revamp is needed. Read the example again – constantly. That’s an important word as it signifies that we have a recurring issue, and when we have a recurring issue we should seek to prevent that issue from arising all together.

I talked about user adoption and engagement in the previous post. If you’ve successfully engaged your users to the system in a way that fosters their desire to drive it’s efficiency and effectiveness, they are going to be vocal when issues arise, which is important to ensuring that the admin team can become aware of the issues so they can start to triage and diagnose the issues quickly.

Collecting data on the support requests also provides a window into the effectiveness of your training resources. If you have documents and videos created to help users through common issues, but you keep getting questions about those things because people aren’t using the resources, it begs the question if the users understand how to access those materials. Are they in a central or, better yet, logical location? Do users know they exist? (Remember: folks are busy – just because you told them a resource exists when you created it a year ago doesn’t mean they remember it’s there). If they ARE all those things, then it might be time to review/re-watch yourself and see where the disconnect is.

A Word on Support Speed

While it’s important to acknowledge the request in a timely fashion, this also comes with a dangerous caveat – if you respond and solve every situation immediately, your users are going to grow accustom to this and, in my experience, it breeds a sense of “don’t look for the answer, just ask and we’ll get the answer back right away”. This actually does everyone involved a disservice because there are going to be times when you/the team can’t respond right away. Particularly as systems grow and there are chunks of planning and new development needing attention.

How do we combat this? Set the expectations accordingly. Be open with your users – you can’t fix every issue that comes up in record time. You have other tasks and are juggling. Their requests are extremely important to you, but you need to balance your time.

Perhaps you set specific days or times that you spend on issue resolution. Or you set an auto-response on your case form that tells people you will read the item within the next X hours/business days/etc.

The point here is to be open and honest with your users about resolution times, as sometimes being the person who responds immediately to everything at all hours can be a curse on many levels. I speak from experience.

What are some of your staples when it comes to supporting users? Do you agree with what I’ve laid out here? Disagree? I am really interested in hearing what YOU do! Drop a line in the comments or join the discussion on social related to this post!

We’re all learning. Why not learn together?!

You’re Live, Now What?! – User Adoption

User adoption is one of those discussion points that never goes away. You can build the greatest system in the world but if people don’t use it, what good is it?

User adoption has to be top of mind for system owners. Any system needs to strike a balance of working both with and for your company. Put another way, it’s finding the sweet spot between the system having value to the users in terms of efficiency of their work while also ensuring the outputs of the system (data, reports, insights) are driving the business forward.

“If it’s not in [system x], it doesn’t exist”. Sounds easy, but it’s not. I’ve heard on several occasions “CRM is great and all but I hate that it’s so redundant – I already track all of that information in [spreadsheets/own files/other system/notebook/etc.]”. Ever seen those cartoons where someone says something and the response is a series of blinks back at the person? That’s generally how I respond, because my brain doesn’t compute the fact that the user doesn’t think to stop the ‘out of CRM’ version of the work.

It begs the question why the data management system isn’t the first choice? This is an important question. If users aren’t adopting the system that is put in place, something has gone awry.

So how do we find that sweet spot of user and business value?

The Basics of User Adoption

I think this boils down to engagement of the users themselves. Let’s be honest – near everyone has an opinion on how the system should be built. Providing the forum for users to fuel the discussion around system evolution is important. Asking users how they are feeling about the system – what works, what doesn’t work, what do they find “too clicky” an experience, and what parts of the system do they really like and draw value from, and so on. Asking your users for their thoughts and input is a great way to help them feel a sense of ownership over the system.

Like anything else, this can be a bit of a tightrope walk. On one hand, we want, no, need, input from the users on these things, but we also can’t accommodate every request that comes our way. I find transparency is best in this regard. Tell them outright – look, we want ALL the ideas, but we can’t necessarily incorporate every wish and request that is out there. The request needs to be rooted in some form of value proposition or prioritization measurement. I get into this more in my piece on user feedback management.

With respect to this post, the point is to engage the users in the discussion.

Keep Users Informed

Keeping users informed is an important aspect of managing their experience and ultimately helping them adopt the system. During my time with Big Brothers Big Sisters of Canada when managing their Dynamics CRM environment, I started “Dynamics CRM Town Halls”. This monthly gathering of users from across the entire country of Canada was an opportunity to share information. It’s entire purpose revolved around keeping users informed and providing a forum for their interaction.

They were structured in three parts initially – and it related closely to the Inform, Instruct and Engage methodology I wrote about in the Training article.

Each 90 minute session was broken into three parts…

The first 30 minutes was to inform the users of anything they might need to know about the system. Topics ranged from discussing up-coming updates, advising on what the steering committee was reviewing, pointing out strange behaviours users had been reporting (and where I as at diagnosing/triaging those things), updates from what Microsoft was doing with the product, etc.

The next 30 minutes was to instruct – I would look back at the trends of user support and drill into areas where I’d been seeing a lot of help desk requests coming in. I’d structure a short training on that topic and do a screenshare and walk through the system with attendees. These helped spread the news about how to deal with the issues so they could share with other users in their office (we had upward of 800 users spread out over about 100 offices from coast to coast).

The final 30 minutes was to engage – it was an open forum where folks could ask questions. Not necessarily questions of me, but of one another. Things like “how are other offices managing their activities lists?” or “what do you do if a match needs to change their schedule?”. The intent behind this was to develop a community of practice among users. I was a lone admin supporting a large user base spread out across the entire country of Canada (it’s big). I couldn’t be in every office monthly – in fact, I couldn’t have visited every office over the course of the entire year even if I wanted to! It was critical that we had a userbase that could engage with one another to work through issues.

These proved wildly beneficial. I ran them for many years, though eventually did tailor them back to every other month and even quarterly for a period of time, but I heard time and time again how much people valued these sessions because it helped them feel a part of a larger team of system-minded team members within our large network of offices.

Don’t Forget the Customer

We must also consider the impact on the customer. When the system is designed properly and provides the information users need to serve the customer, the ultimately beneficiary becomes the business by virtue of satisfied, returning customers. Of course the product must also be solid, but let’s assume that to be the case for the sake of this article.

Discussions about the value of the system to the user base inevitably get into what they want in the system. I’ve learned over the years to reframe it back to what do they need to be able to serve the customer. Perhaps that’s a subtle shift, but it can change the discussion in significant ways.

I first heard about this concept several years ago while moderating a panel discussion on system design. The popular and insightful Gus Gonzales shared that he has long used a methodology of system design around what the customer’s customer needs. I still remember hearing it and repeating it in my head several times – the customers customer…what!? As he framed his point, I was an instant believer.

I’m paraphrasing here, but the gist was to not build the system based solely on what the users say they need, dig deeper to understand what the customer they are supporting needs. If a customer calls in and is talking to a sales person, what information are they going to want the sales person to have on hand – THAT is the information the record should be showing the users, because it ultimately helps them make the sale or support the customer. It’s a really insightful tidbit that has stuck with me for years.

System Champions Foster Interest

The final point I want to make is a short one – find your user champions and use them to help spread the system joy. You likely know who they are already, but if not, they’re the ones that want to learn more about the system. They often ask plenty of questions of how to maximize the system. They are the ones that giggle when you present cool new features. They are the ones that put in system change requests with innovative, bleeding edge ideas. They are the “what if we could push a button and the system could do XYZ” kind of people. Find them.

Befriend them. Ask them to help you motivate and engage the team around the system. I’m almost certain they’ll be proud to do so. If you can swing it, get system swag for company events – they’ll wear it…proudly.

There is method to my madness. People tend to want to follow the herd. Not always, of course, but often. If the heard has strong champions…shepherds, if you will…they will find followers and they will proudly march down the path of system adoption and engagement.

What do YOU do to get users to adopt your system? These are just my ramblings, but there are other great insights out there. Feel free to chime in below with comments or join the discussion on this social post associated with this article!

Cover Photo Credit – Photo by Marvin Meyer on Unsplash

We’re all learning. Why not learn together!

You’re Live, Now What?! – Training Continued

Previously on You’re Live, Now What?!…we talked about the importance of the Training Framework. Today, we dive into detail about the various aspects of training with a focus on things you need to consider when providing a training program for your users.

Let’s jump in…

People consume information in different ways. I’ve done presentations on training many times and every time I do I run a little test asking the group to self-identify based on how they prefer to consume learning material. Without fail, there is a division of the room.

Some people prefer to watch a video. Others prefer a manual with screenshots and call-outs outlining what they do. Some prefer to be walked through the process in real time, either by someone next to them or an on-screen guide. Others prefer no training at all and learn by poking around a training or sandbox environment set-up for training.

((A note about that last item – learn by self-exploration – this is fine if you’re using something whereby only one way of doing something exists – in many scenarios, that’s not the case and this method can lead to inefficiencies when a user uncovers a way of doing something that isn’t the most efficient way of achieving that item. Of course as admins we try to reduce this possible in our system design, but it can’t always be avoided.))

As training providers, we need to be mindful of how people consume information. If you are in a small company, it’s possible (unlikely, but possible) that everyone can agree on a single format. If so, that’s great, but we must be prepared that this is not likely the case, and prepare material for each type of consumption.

Expecting everyone to consume training information the same way is essentially the same as expecting to teach a gold fish to climb a tree like a monkey. They just aren’t built that way.

Let’s talk a bit about the various manners of training.

Videos – these provide a great way for you to interact with your users without being there. Of course it’s one way, but people can find you for questions later. I love videos because users can pause and rewind things. When I digest content, I find it really valuable to have full control like this as sometimes I need to hear something a second time, or watch more closely. If you use the right software, you can even add elements to the videos like call-outs, highlights, or zoom in on things.

One tip I’d share – lose the robot voice. Be you. In my experience users value the authenticity of you being you in the video. I stopped editing out the pauses or umms and uhhs (but you should try your best to avoid those anyhow!), because it made it feel fake. Very few (if any!) people are never going to have those things happen, so leaving them in increases the feeling of watching live instead of watching a video.

Manuals – a great way to provide an overarching go to resource for your users. Some users will treat that manual like gold, and use it daily. They are a lot of work to put together, and even more to maintain. Anytime you make updates in the system that change any of the UI elements or a process, they should be updated. Historically I used an update cycle, releasing a new version of the manual every X months and maintaining a spot on our organizational learning site that provided a link to the most recent one and a big call-out as to the current version.

An online version is an option – think “knowledge base” where people can go and search for what they want or need. These carry with them the benefit of embedding the video directly within the article so people get the text explanation/screenshots AND the video all in one, appeasing both styles but still having only one place to go. That’s a benefit, in my opinion.

Tip Sheets – these are just like they sound. Usually one pagers that provide an overview of how to do something very specific. Think things such as; Create a new Contact, Add a new record to the app, how to open and navigate a record, etc.

These are useful grab and go tools that people value when they don’t do a task daily/regularly and require a quick refresher when they need to. The same caution around updating comes into play though, as any system changes should be updated.

Tool Tips – wildly helpful in app, a tool tip comes up when you hover a field to provide the user guidance on what to enter. Think of a date field with a field label of “App Date” – the tool could state something such as “The date the application was received” (this is just an example – a whole other article may surface one day about the value and importance of clear field labels).

User Aptitude and Learning Styles – a tricky thing to measure. User aptitude speaks to the ability of the individual to learn and/or to use the system. Learning style pertains to how they learn – not just consumption of information, but also their ability to translate that into skills with the system. These can be difficult to measure. Even more challenging is when you are in an environment where you have various levels of user aptitude paired with different learning styles.

I don’t have all the answers. What I can tell you is that it’s an important consideration as you navigate through training. You may need to spend more time with some users, and structure information in different ways to properly inform, instruct and engage them in the process.

When planning a training or the creation of training, think about the various aptitudes and styles that could be reading/viewing. Don’t limit this based on your current users. Transitions happen. Try to think about what other styles could come to the organization that might need a different approach.

Again, this is a balance, and I’m not suggesting you need to factor in something different for every single human individual. Instead I’m saying think about these things as you plan and prepare your material to ensure you’ve providing content that will instruct, inform and engage across the spectrum as best you can.

Training Never Ends!

In one of my first experiences around providing training for people, I had the naïve mindset that once I created and published the material the user would just know to find it. They would go and get it when they needed it, and wouldn’t ask me about the topic of that material because they had what they need. Blissful.

Blissful ignorance, as it turns out. I’ve come to learn that training is not a one and done.

• The system evolved? Training is needed.
• New users? Training is needed.
• Users doing something they’ve never done before? Training is needed.
• It’s simply been a while? Training is needed.

Now this is not to say it needs to be a live training every time. In fact, I’m a huge proponent of recorded training and training documentation because users can tune into it when they need it.

But there does need to be a schedule of training reminders and pointers that help users get to the training. There are a variety of ways to do this, and I’m going to touch on them in the next segment of the You’re Live! Now What?! series when we dive into User Adoption which marries beautifully with the “engage” of the training framework.

Before I wrap, though – I’m interested in your thoughts! Do you have training methods that you find really appealing and useful? I, as well as other readers, would love to hear them! Share them here, or join the discussion on the social post promoting this post!

We’re all learning. Why not learn together!

You’re Live, Now What?! Training – A Framework

I have two boys, 12 and 10 years old. They are YouTube fans, and I hear daily accounts of their favourite “YouTubers” videos. I try my best to listen – to embrace the fact that they are still enthusiastically sharing their interests. Truthfully, sometimes I find that I’ve tuned them out. Nodding along as if I’m hearing them but in reality my brain is in some far-away place devoid of YouTube, Fortnite, and scooters (the two things they seem to watch the most about). I try not to let that happen but you can only listen to so many stories about the same topic!

The other day one of them was telling me a story about a video and said “…and then he said something about catching a fish versus teaching them to fish, or whatever…” and I interrupted to clarify and explain the statement and why it’s an important lesson (likely causing the same tune-out’age…karma, amiright?).

Alas, it struck me as the perfect way to start this post, because I’ve used that statement many times over the years when explaining my philosophy when it comes to training.

I believe the statement goes something like this:

Give a person a fish, you feed them for a meal. Teach that person to fish, you feed them for a lifetime.

(There are plenty of variations and differences of where it originated, but many sources point to Moses Maimonides, a medieval Jewish philosopher).

In the context of systems work, some examples might be…

I can run that report for you, or I can teach you how to run it yourself.

I can build that advanced find for you, or I can teach you how to build it yourself.

I can run that manual workflow for you, or I can teach you how to run it yourself.

See where I’m going here?

Training a user how to do something themselves pays dividends to both of you. The user better understands the system, and you are freed from answering (or pointing to resources that answer) the same questions over and over.

Training opens a window to enhanced user adoption (in theory, anyway). It also gives rise to an interesting situation whereby the more a user knows about the system, the deeper into that system they get therefore increasing the complexity of the questions they ask, not necessarily reducing the number of questions they ask. That might be a post in and of itself someday!

There is plenty to think about when considering training for users…

I want to talk about some of the aspects of training that I find particularly influential when putting together and ultimately delivering on a training framework.

The Framework Itself

Remember my post “The Art of Planning”? I can’t even pull of dinner prep without a proper plan. You better believe I find it most helpful to have a training framework crafted. In fact, I find this essential. Like a using a map (app or otherwise!) in a new city – it helps keep track of where we’re going and where we’ve been.

A training framework is simply an outline. It calls out some of the key aspects of what we’re trying to achieve with the concept of training. There are several components and sub-components of an effective framework I’d like to hone in on.

To maintain focus on what I’m trying to accomplish with all training, I find it helpful to reflect on IIEA…

Inform – this is why we train our users. So they are informed about the system, how it works, and most importantly how they themselves benefit from using it.

Instruct – this is what we aspire to do. We want to provide the instruction necessary for the user to have the fundamental understanding of how the system works.

Engage – we want engaged users. We want users that actively use the system for its intended purpose. We also want our users to help drive the system forward. We want their feedback, their insights, their pain points, and their data as they use the system.

Accountability – training is a way to ensure our users are held accountable for their work. It also helps the company/organization be accountable to the actual trends being experienced in our business. And finally, it helps us admins remain accountable by ensuring we’re providing the proper information, instruction and methods to engage the users in the system.

All of this comes together to formulate the Goal of Training – a succinct statement that clearly articulates the intent of the training program.

Other key components include:

Training Methods – an overview of the various types of resources that are created so users understand what they have at their disposal. Examples might be videos, tip sheets, tutorial documents, a knowledge base, or a more formal tool like a learning path.

Location, Location, Location – clearly explaining where resources are found so users don’t have to think too much about where to go to get the material they need.

On-boarding Sequence – this aspect should provide detail on how a new employee should work through the material. This should be an intentional, guided process that helps users understand the system through the eyes of the organization. Sure, someone might have experience with Dynamics 365, but they still need to be supported in how your company uses it.

The onboarding sequence should also include the anticipated time it takes someone to go through the initial review. Of course everyone is different, so consider that when putting a timeframe around it, but don’t leave it wide open (ex: over the course of the next 9 months…). The initial onboarding should be simple, to the point, and provide a holistic but high level overview of how the system is used by the organization.

In my current role I host a 20 minute welcome and overview for new users that helps them understand the core features and navigational elements of our CRM system. This primes them to start a more robust onboarding sequence by putting a face to the voice they’re going to hear in the videos that guide them through. It also gives me a chance to meet new hires which is a great way to start to build a rapport with them.

Glossary of Terms – this is huge but so often (yes, even in my own experience) overlooked. Words can have different meetings. Just think of the word “Status” – there are system definitions, but may also be organizational definitions. A glossary of terms (which may be a document or knowledgebase in and of itself), is important to help users understands things mean.

Training ‘Table of Contents’ – a listing of all content available. This could be broken into topics and sub-topics such as:

System Overview

• Core entities
• Overview of the ever-present ribbon
• Navigating the system
• Opening Records

If you are using a knowledge base, this might not actually exist within the framework itself, and instead the user is brought from the framework to the knowledge base where all of this is laid out. I’ve used both knowledge base and files (manuals, tutorials, videos, etc.) – personally, I love the order and structure a knowledge base provides. Someone recently suggested OneNote (Thanks, Michael Hauck!), which I’ve yet to use for a training tool but I can absolutely see the value (excellent search, logical and intuitive organization, and ease of editing, to name a few features). I’ll likely be giving this a go in an up-coming project.

The framework is just the beginning – in my next post, I’ll dig into the methods of training and we’ll look at some of the variables that we need to account for when thinking about user training. Things like…

• Structure / Format of training

• Training Methods

• User Aptitude and Learning Styles

• User Ability

And of course, we’ll discuss content itself!

In the meantime, I’d love to hear how you manage your training framework in your organization? Any tips, tricks or considerations you can share? I’ve love to hear them! Comment below or toss it out on social!

Thanks for reading.

Cover Image: Photo by Ramin Khatibi on Unsplash

You’re Live, Now What?! – Leader Buy-In

Have you ever been in a meeting where you watch an executive team member start referencing data or information and you realize they’re pulling that information out of thin air and not the system the organization has in place to manage that very data? It’s horrifying.

Many years ago I watched this unfold and I recall being struck by the realization of what this did to the team’s view of the organizations data management system. It was the equivalent of watching someone slash the tires of a race car that was seconds away from the start of a race. It wasn’t “certain doom” per say, but it meant that car and its crew had to work really, really hard to get it back to a place of contention. I was witnessing a team being told, between the lines, ‘it doesn’t matter what the data says, we’re going to base our decisions on what we *think* it says…without actually looking at it’.

It also demonstrated that at the highest level of the organization there was a lack of buy-in to the value of that data management system.

This has stuck with me for years.

It’s easy to understand that if the data management system isn’t what is being leaned on during organizational planning and meetings, that system isn’t going to get the love, or use, it deserves. If leaders don’t make data integrity/governance a priority, staff are inclined to create alternative methods of capturing, tracking, analyzing and reporting.

How do we ensure our organization takes our data management seriously? What steps can we take to make sure that when any discussion about the performance of our organization, their actual data is at the center of the storyline?

I believe that demonstrated leadership buy-in is of critical importance. Leaders need to walk the talk when it comes to data within their organization. I’m going to get to some points about this very topic later on, but before I do, I want to share with you some lessons I think help foster a culture of data integrity which in turn make demonstrated leadership buy-in much easier.

Accept No Alternatives

Data is pulled from data management system X. No exceptions. If we are having a meeting and we need data, it’s coming from ‘the system’. Someone is talking about data but says they aren’t sure if that’s the true story – a take away item from that discussion is the data in question is validated via the data management system – if this can be done in real time during the meeting, great. If not, as soon as afterward as possible.

In my opinion, this puts the onus on ensuring that mission critical data is within the organizational data management system.

A recent example I ran into was one where a new process was rolled out to track approvals on something. Previously requests could have been approved on the phone, in the hallway during a fly-by chat, in an email, or through an IM chat. As of the date of rollout for the new approval process, if the request was not routed through the form (a Microsoft Forms Pro form that triggered a Flow through Power Automate which triggered a two stage approval process through our business strategy and finance departments), then the request wasn’t getting the time of day.

It must be in the form or it doesn’t exist. Period. Who reinforced this message? The CFO and VP of Business Strategy. Case in point: Leadership buy-in.

Explain the Supply

When there are team or company-wide meetings where results, forecasts, pipelines, or data is being presented, equip your leaders not only with the data but the verbiage to go with it. An organization’s leadership team wants to ensure the team has confidence in the systems they have in place. To do this, they should be referencing that the information has been produced through the data management system.

Sure, the team hears you, the “admin”, when you talk about how the data in the system is giving us the information we need to make our decisions. But we’re the admins and data folks – we’re supposed to think / talk about the data that way. When mission critical data is presented and talked about in meetings, it helps show that this isn’t just a pipe-dream of us admins, it’s the company reality.

Manage your leaders to say things like “CRM shows us that…” or “this pipeline, prepared in [ system x ] demonstrates…”. These small, subtle inclusions in that presentation or discussion reinforce that the organization leverages the data management system to inform its decisions and planning. It’s not just saying “Use the system because we said to use it”, it’s demonstrating that the data is, in fact, used.

Training is for EVERYONE

When you do training sessions with your company, include the leaders. Talk to them ahead of time and explain to them that their attendance and participation is critical to demonstrating the value of the system to the organization.

Naturally, leaders are busy. Work with them to find pockets of time that work for them to attend sessions, and encourage them to engage in the training in real time, or to post to the comments/chat portion of the training material. Again, we’re talking about demonstrated leadership here. If our leaders demonstrate they are engaged in the system, it’s going to pay dividends to your user adoption plan.

Wrapping up…

Don’t get me wrong – this is not an area I think is an “easy win”. Executives are busy and you may only get a small amount of time. In my experience, they want nothing more than the organization to use the system infrastructure that is in front of them. They are eager to have those systems support organizational efficiency, and having staff putting data in their own spreadsheets and file drives is not efficient nor effective practice. As a result, they are happy to drop in a line or two in presentations that help frame the critical nature of the organizational systems used.

Not sure where to start? Here’s one simple thing you can do right now:

Brainstorm a one or two names of executive / leadership personnel in your organization that you could count on to be system champions.

Do you agree with the sentiment here? Do you have other methods you use to achieve leader buy-in? Are there aspects that aren’t covered here you think readers would benefit from? I’ve shared but a few things I’ve come to learn, but I know there are other tactics out there. Drop a line in the comments!

We’re all learning. Why not learn together?

You’re Live, Now What?! – A Series

You poured blood, sweat and quite likely tears into the planning, configuration and rollout of your new system. You sit back, sipping your celebratory drink with a smile on your face and a sense of calm and peace, staring out over your digital beach scene of a desktop. This is the life, you think…

But then you sit up straight and think – so…now what?!

In 2018 I hosted a panel discussion with the same title of this post. The discussion was great and included excellent perspectives on several key topics for administrators to think about post-go live. As the call for proposals for a conference I wanted to speak at was approaching, I reached out to the talented Heidi Neuhauser asking if she’d like to help me pivot this into a more formal presentation. I was thrilled when she agreed.

We had a great time putting the presentation together and delivering it. It’s a topic I believe resonates with a lot of admins/system owners because you put in a great deal of work planning and eventually turning the system on for your organization and quickly realize the work has just begun.

The sheer breadth of content potential within this topic is astounding. The topic can be broken down into component parts focused on the following areas:

• Leadership Buy in
• Training
• User Adoption
• User Support
• User Feedback Management
• Data Integrity
• Views/Charts/Dashboards/Reports
• Manage and Stewarding Positive System Use Habits
• Integrations
• System Evolution
• Organizational System Culture

As you can imagine, this was a TON to fit in a 60 minute panel discussion and/or presentation. It’s also a TON to fit into a blog post. So, it’ll be a series!

Over the course of the next…many…articles, I will tackle these very topics. I plan to break them down and tease out the key elements of each in an effort to generate thoughts and considerations to you, the reader.

And remember, please share your thoughts and comments throughout the series! The more insights and perspectives we can bring into the fold here, the better off all readers will be.

We are all learning. Why not learn together?

Cover Image: Photo by Keith Luke on Unsplash