Technology and Process Change.

Learning a new skill usually takes practice — sometimes, lots of it.  For some skills, people need to practice in a safe place before applying them on the job.

Consider what it takes to learn to fly a plane.  You wouldn’t want the pilot practicing their flying skills for the first time on your flight!  They need a lot of practice in a safe, simulated environment before they ever attempt to fly a real plane.  The same holds true for employees who will be required to use new technology to do their jobs.  When it goes live, you don’t want their first time with the system to impact the business.

So you need a safe space. That usually means a training environment or system simulation. Which one should you use to let users practice? Here are some pros and cons of each:

So, how will you know which solution is best?  These questions might help you decide:

This should help you ask the right questions and evaluate the unique needs of your project.  At the end of the day, it’s all about making it as real as possible for the learner and ensuring they can “fly that plane” when it really counts!

Why won’t users just do the right thing? The software implementation went well, the tech is flawless, and the helpdesk is ready to go. Still, users use manual workarounds and refuse to embrace the new system.  No doubt, bad tech will kill change, but good tech doesn’t guarantee success.

It’s heartbreaking to watch, but we see it all the time. Unfortunately, it’s the IT team that usually takes the hit.  The assumption is that if the technology worked, users would flock to the new system in droves because, hey, it’s better. So why don’t they? There are three common reasons.

People fear loss much more than we value gain.

Research tells us this. In one experiment,* researchers gave each subject $50 and two choices:

Keep $30

or

Flip a coin to keep or lose the whole $50.

The result: 43% of subjects chose to take the gamble. Then, they gave a second group of participants the same choice, only with different wording:

Lose $20

or 

Flip a coin to keep or lose the whole $50.

The new result: 62% of subjects took the gamble. The point is that we have a strong aversion to feeling a loss, regardless of the reality.

When critical systems change, users fear a loss of competency. They know the current system and, even if it is difficult to use, they know they can do their jobs. The conceptual benefits of your new system won’t matter if people don’t feel competent using it before the cutover.

Tribal knowledge is another reason users hold on to an old process.

Believe it or not, there are still tons of command-line, green-screen, or otherwise grossly outdated systems running out there. We come across them all the time. And, like a bad movie, these applications often have a cult following. The voices of new hires and millennials, shocked by the user experience, scream for modernization. Their voices, however, are often no match for a quieter but much more influential group – seasoned employees who hold the organization’s tribal knowledge.

There is a great deal of security associated with knowing something that is both critical to the business and difficult to replicate. In economics it is referred to as a “barrier to entry,” and it is a key strategic advantage. If your competition cannot easily replicate your products or services, and those products and services are in high demand, then your business is going to do very well. The same holds true for those employees who possess your organization’s tribal knowledge. They have security. They are often further along in their careers and have paid their dues to get where they are. Now you want to strip that away and make them start over, with a new process. Can you blame them for wanting to maintain the status quo?

We need to help these employees — not only to transfer their skills to the new system, but also to reinforce their value to the organization. Whether they are working in the old system or the new one, their real value lies in their intimate understanding of the business and the relationships they have formed over the years. We need to help them understand that embracing a new system does not change these strengths.

Your users, like the rest of us, are anchored in the past.

That’s another reason they resist change. Nine times out of ten, you’ve made some previous attempt to replace an outdated system. It’s rare that we are brought in to help on our client’s first try at an upgrade; it often takes failure to understand that successful technology change needs a lot more than good project execution and good technology.

Employees remember the failure, even if it was years ago. When you propose a new system, that failure is their point of reference. It’s easy for leadership to dismiss — it happened years ago and there was lack of budget or commitment, or the technology back then was not nearly as good. But don’t under estimate the past. It informs employees’ perspective on your change initiative. Maybe they feel that, since the last initiative failed, it’s ok for this one to fail — they can just do whatever helps them ride this one out. You need give them a new point of reference, one that models success and provides no option for failure.

Armed with this knowledge, what should you do? Make sure your project has strong change management, and that the team understands these three principles. I’ve always believed the CIO should be the organization’s strongest advocate for change management and ensure that every technology implementation has a dedicated change team — if for no other reason than the CIO has the most to lose.

It’s not a mystery. There’s no excuse for not knowing this. There are well founded and observable reasons users don’t immediately embrace new technology. We need to understand how human nature works for and against us, and use that knowledge to help the organization move past these barriers to the successful future promised by the new technology.

*Published in Science and described in Dean Buonomano’s Brain Bugs

It seems like every organization is headed to the Cloud. If your organization is not there yet, it soon will be. As a change management professional, you might be responsible for helping them get there. One of the best ways you can help your organization get ready for its Cloud journey is to help prepare its resources. Consider a Cloud Bootcamp training approach.

If your organization is like most, they will probably take small steps to migrate systems to the Cloud. Because all systems won’t go at the same time, you can focus on the impacted parts of the business before their migrations. Consider creating a three-day Bootcamp training session designed for business unit migration teams. It’s called Bootcamp for a reason – like the military, everyone takes it to learn the basics…the things they must know to get started.

The migration teams might consist of technical resources (e.g., developers) and non-technical/business resources (e.g., product owners, business analysts, etc.). The Bootcamp will get the right people up to speed on cloud fundamentals and any organization-specific information you need the team to know.

Bootcamp topics might include:

• Cloud Fundamentals – IaaS
• Cloud Fundamentals – PaaS
• Database Migrations

Cloud fundamentals typically include a lot of technical information so of course it’s important that technical team members attend. But it’s also important that the non-technical members to take the training. Business resources and supervisors are responsible for growing organization capability. The first step is to understand what the organization will be responsible for in the new cloud environment- this will help them make decisions after the migration. Make sure at least one training module gives an overview for non-technical team members.

Use your application migration plan to determine who needs to go through the Bootcamp and when. Since this a new journey for your organization, consider hiring consultants who are cloud experts to develop and deliver the training. Use a train-the-trainer approach and spend the first few conducts getting your people (who will eventually act as trainers) smart.  Those individuals can begin by acting as secondary instructors…and eventually lead the Bootcamp.  At that point, you can release your external experts and use your new internal capability.

Most technology training efforts cover a four-to-six-week period, so be prepared for the Bootcamp to span months, if necessary. Good luck and see you on The Cloud!

Have you ever seen a dog on “Fun Patrol” at the park? He looks for any other dog having fun, then bounds in and wrestles its toy away, only to get bored and walk off a few minutes later. The dog tests the new toy, realizes the toy doesn’t solve his boredom problem, and drops it. It seems that what brought joy to the hapless victim did nothing for the dog on Fun Patrol.

There’s a technology lesson in there. Just because someone else’s new tool works for them, doesn’t mean it will work for you. Organizations have different needs, and no one approach fits all. Launching a custom sales app just because your competitor has one is risky business. Maybe your competitor has a smaller footprint and needs increased exposure and sales, while your company is well established, but has trouble processing orders quickly. Increasing sales without addressing your existing process issue would only lead to backorders and, most likely, disgruntled customers.

It’s tempting to look around at your competitors, see the tech trends they’re using, and rush to keep up. But no tool helps every company – even very similar companies. And adopting the wrong tech can hurt your business more than it helps.

The takeaway: identify your needs before choosing expensive new technology. Don’t start by falling in love with the tool; look at where your organization is going, what it needs to get there, and what obstacles are in the way. THEN, look for the technology to best supports that vision.

As you shop, be specific about the problem you’re trying to solve. If it’s not about RISK, TIME, or MONEY, maybe you don’t need new technology.

Consider the case of a retail big box company whose problem is overstocking products. They could choose to:

• Implement a new Point of Sales (POS) system to record more accurate sales data patterns, thus reducing the RISK of overstocking low-selling products that might go bad on the shelf.
• Implement an Order Management System (OMS) to identify which stores are over- and under-stocked on a certain product, helping them proactively shift inventory between locations. This would reduce the TIME to clear overhead and bring in new, more saleable products.
• Distribute tablets to managers, allowing them to deliver flash sales on overstocked products directly to the customer on the floor. This would bring in more MONEY through increased sales and reduced overhead.

Each of these is a viable option, as each addresses a need and solves for either Risk, Time, or Money.

Once you have identified your organization’s needs and have a tool in mind, make your case for the solution. We have a recipe for this. Let’s use our big box store from the scenario above as an example.

Breaking down the case like this tests the tech’s ability to address your need. You might find your first choice doesn’t quite align with your need and vision, and that’s ok. Keep looking; you will find a fix – technical or otherwise — that fits. No tech tool is a cure-all, and the solutions are not always as useful and intuitive as the tech company might promise. (See my other blog post for more on this).

When you land on a solution that’s perfect for your needs, there is still work to do. First up: selling your idea. Leadership and other stakeholders will have to buy in and learn how to use the system. Constructing your case, as described above, will help you talk about the solution to your organization.

This kind of thoughtful analysis is well worth the investment of time and energy. Do it right, and you won’t fall for the newest, shiniest toy. You’ll be well on your way to solving your business problem and strengthening your organization.

I love MS Excel. And what’s not to love for a data-crunching geek like me who just loves all the dirty details? And, to boot, its power to create eye-popping charts and graphs is unsurpassed. But if you’re an IT leader who’s trying to implement a new reporting system that has the option to export the data to MS Excel, you probably don’t share my affection.

Companies invest millions each year in their reporting systems. To reap the rewards from these large investments, they need the users to actually use the system to its fullest capacity and not rely on workarounds (like using Excel). Why do users so often revert to the old ways of doing things? Well, it’s what they’re used to. Old habits and behaviors they exhibit are comfortable and reliable. The new way looks too hard and too risky. What’s an IT leader to do?

Take away MS Excel, of course.

Just kidding; the townspeople would storm the castle! How about we try something a little less drastic first..

• Train them. The first thing most executives want to do is to train employees. On absolutely everything the new system can do. Instead, focus on the common, critical, and catastrophic. What are the business scenarios they will encounter most often? Which functions are most important to get right? And what happens to the business if they don’t use the system correctly? These are the things that will focus people on using the system as designed.
• After training, employees need to practice the new behaviors on their own. Give them common scenarios or questions they will need to answer, and then let them loose in the system. Have experts on hand to support learners as they find their way, so they are successful. Orchestrating successes will make new users more confident in the system.
• Reward them. Often, the most expert users can feel over-worked. They have to do their normal day job and then — on top of it all — they need to support their peers in completing their tasks. Reward expert uses for the work they do. Recognize the added burden and make them feel appreciated. They play a critical role in realizing the benefits of the new system.
• Smooth out the rough spots. Sometimes people rely on workarounds because something is not working the way they want it to. Seek out these rough spots and work with employees to find a solution that works. Sometimes changing a system configuration or removing a process step can make all the difference.
• Highlight success. When you see it, say it. Sometimes correctly logging into the system for the first time might be the most successful thing that happens that day. So say it! When someone pulls a report successfully, say that too. When everyone in the department is working in the system, celebrate that. The shared enthusiasm builds momentum. Before you know it, employees will dropping the old ways and adopting the new – and maybe looking for ways to make the new way even better!

While our first reaction might be to take away a valuable tool to avoid workarounds, simply focusing and redirecting performance toward new behaviors leads to a much better outcome.

We all know how important super users are. They’re the link between the end user and system, the eyes and ears on the front line, and they’re more effective help than Siri, Alexa, and Cortana combined. They’re a critical cog in the go-live machine. But you have to remember they have a day job.

Being a super user means taking on additional responsibilities and a constant stream of questions. It’s downright exhausting being a troubleshooting point-of-contact on top of normal responsibilities. Without the proper support network for your super user team, you might see a drop in productivity, an increase in errors, or even a build-up of resentment for the under-appreciated extra work. That’s why you need to foster and support your super users.

Support the Super User

The best thing you can do for them is protect their time. Super users can’t address troubleshooting calls and emails all day and keep up with their normal work, so help them establish office hours. Having a dedicated time for end users to contact super users greatly increases their efficiency. Two hours spread out over a full day is simply not as effective as 120 concentrated minutes. And remember, not everything is an emergency, so don’t treat all troubleshooting calls as such. Establish an issue log to group and prioritize requests.

While it makes sense to support your super users during a technology roll-out, it’s not the only time to help. In fact, your positive impact might be greater before and after a roll-out than during. Start by building super user responsibilities into your job descriptions. People don’t always respond well to unexpected work, but if you establish an expectation up front, you might find willing super users flocking to the opportunity. Better that than desperately searching for them at the time of need. You can take this a step further by baking in additional privileges or promotions for those who embrace the super user role. If you treat the role with value, you’ll have an easier time filling the position.

Support for your super users shouldn’t end at go-live. When the excitement of a roll-out fades, we’re all left with the realization there is still plenty of work to do. This is often when super users are taxed the most. To combat this, encourage super users to form informal support groups to share information and advice. That kind of collaboration and communication eases their burden when they feel stretched too thin. It will also boost morale and surface issues for project management and the business. Arguably the best way to help super users is to let them help each other. A little love goes a long way.

Over the course of a long and arduous technology implementation, the need for super users is unquestioned. Don’t turn it into a thankless job. Support your super users.

After many years of providing change management on projects using Waterfall (traditional) project management methodology, you might be asked to manage change on an Agile project.

Agile is a time-boxed project management methodology that uses an iterative approach to software development and delivery. The team builds software incrementally and shares those incremental updates with stakeholders from the beginning of the project. This is a significant difference from the Waterfall approach, where stakeholders are often not brought in until much later in the project – sometimes as late at user acceptance tests. As a result, stakeholders might not be able to provide their feedback early enough to make the kind of changes they would like to see in the software design.

I completely see the benefits of Agile to software development. However, when the project’s change management work is lumped into the Agile methodology, it can be problematic. Or, at least, that’s my experience. If you aren’t familiar with Agile, spend some time researching it online. There’s a ton of information on the topic.

If you are familiar with Agile, you know that within each program increment (PI) there are sprints (two-week work increments). You also know that during the sprints, the focus is on the work deemed most important by the team and the product owner (PO). Because most team members are probably working on software development and not change management, it is likely that the change management work will be viewed as less important. It might not be considered important at all. This poses a particular challenge because stakeholders are already aware and very involved with the project.

Recently, I worked on an Agile effort where, in the second sprint, the change management work fell off the radar. My work was “pushed to the backlog,” which is to say there was no plan to work on it during the current sprint; we would get to it when we finished the “more important tasks.” So you can see the risk of lumping the change work into the Agile approach, can’t you?

How might you overcome this? In my opinion, change management work should be separated from the other tasks and executed on a timeline independent of the iterations. For example, stakeholder analysis, communications planning and communications rollout can be executed concurrently with Agile iterations. Change management is an essential part of the project and should not be “shelved” at any point in favor of other work.

I don’t remember the first time I used a hammer, but I know my dad didn’t just hand it over and say, “Good luck!” He had a vested interest in my health, so he took the time to teach me. There’s a simple lesson in that: learn to use the tool, or else it’s gonna hurt.

I know I’m not the only person to learn this lesson, yet I keep running into companies integrating new technology with little or no training. These companies have a vested interest in the health of their business, yet they hand over new technology and say, “Good luck!” I don’t know why – whether employers have a lot of confidence in workers learning independently, or whether new technology is considered a cure-all on its own, making the human element irrelevant. But the reality is, technology is not a solution; it’s a tool. If you want to hit your goals, you must take responsibility both for acquiring the tool and teaching employees to use it.

That doesn’t mean just tossing one more thing in your shopping cart. You can sometimes get away with buying a tool with no customization, but you can’t buy training off the shelf and expect it to work. Your business is unique. You have your own processes, procedures, jobs, reward systems and – most importantly – your own business goals. When you bought the technology, you expected some business benefit. Your employees must use the tool well, in the context of your business, or you won’t get the benefits you expect. Training for new technology should be mandatory and customized.

If you want to hit your goals, you must take responsibility both for acquiring the tool and teaching employees to use it.

Tech companies might claim their product is so intuitive anyone can use it immediately. They might use smartphones as an example. No one sent you to training for your first smartphone, right? Maybe not, but that doesn’t mean you weren’t trained. You probably used a lot of trial and error, went online for help, and asked your friends or associates at the store where you bought it. For years, I ranted about my screen constantly rotating before a friend showed me a quick way to lock rotation. It’s really easy to do, but it hadn’t even occurred to me a feature like that existed. Now that I know, sure, it’s intuitive, but as an inexperienced user, my phone just seemed broken. Very few of us would be able to properly use our smartphones without friends acting as trainers. NOW your smartphone isn’t hard to use; now each one is intuitive, because your “intuition” depends on your own experience with the many smartphones you’ve owned. You’ve lived it, and that was your training, so now you don’t need to think about it. Do you want employees stumbling through your new technology until it’s intuitive? Do you want to wait that long to get your ROI?

Ok, that’s why training is important, but why custom training? Having spent years in the thick of technology implementations, I can tell you that all training is not equal and you get what you pay for. “Vanilla” training is cheap up front, but it’s not very effective. And its cost doesn’t include the high price of low productivity. Even if you implement technology as-is, right out of the box, vanilla training is dry and one-dimensional. No one wants to read a user guide, and frankly they’re not always helpful. Just look at Ikea. They market their products as easy-to-assemble furniture with easy-to-follow instructions. In reality, putting their furniture together is a notoriously frustrating process. Vanilla user guides simply aren’t enough to properly train a team to do their jobs effectively with new technology.

Besides, most technologies allow custom configuration, which most companies take advantage of, and which immediately makes vanilla training irrelevant.

Having spent years in the thick of technology implementations, I can tell you that all training is not equal and you get what you pay for.

If people struggle with smartphones and Ikea furniture – which are relatively simple and have a low cost of failure – how do you think your employees will fare with your pricey new technology? You need them ready to perform their own jobs with your technology configuration and your business processes in your teams and culture to hit your business targets.

You Need a Custom Training Solution

Do it right or don’t do it at all. Create training and support that fits your organization. Provide multiple avenues for learning, both guided and self-paced, as well as performance support on the job. Make it engaging, memorable and even fun – something your employees will want to take and refer to in the future. Build something that engages the whole learning community, encourages dialogue, and provides rewards and recognition for hard work – learning that makes your teams perform better. The health of your company depends on it.

“As part of the contract approval process, agencies must submit an ECR (RC215) or PO (RC744) with the appropriate encumbrance of funds. Immediately following the approval of the contract, the encumbrance will be recorded in the CDS against the appropriation from which contract commitments will be paid. Once recorded, State departments and agencies must not reduce the contract encumbrance, except when the estimated liability for the fiscal year is reduced. In some cases, agencies are permitted to data-enter contract encumbrances in the CDS and these must be recorded only in sequence of contract submissions. In the event that a contract is disapproved, the related contract encumbrance will be cancelled by PRB.”
Actual paragraph from a training manual. Acronyms have been changed to protect the misguided.

Hi, are you still reading? Congratulations. Now imagine your company is launching a new process that you’ll have to start using next Monday. You take this training (above) and you’ll have to follow these steps every day. Your trainer defines ECR, RC215, RC744, CDS, PRB, contract encumbrance and estimated liability, but these are all new terms to you. How will you feel walking into work on Monday? Not great, I’m guessing.

Short words are best and the old words when short are best of all.
Winston Churchill

For years, I created training and communications for users of new systems and work processes. I was always struck by how much new language we expected employees to absorb…on top of new skills, tasks, tools, and concepts. I realized we, the change management and learning team, couldn’t solve this problem entirely, but we could make things better.

There are three nasties that desperately want to creep into your training and communications, and their names are Acronym, Made-up and Flowery.

“RIP KGB CIA JUD FDA LSD FBI DMT
ROM PCP UDA FCC KKK MAD CNN BBC
EMI THC ICI TNT DNR MDA SAS
JFK RAM CND IRS LED HBO GHB YSL”
The first verse of “R.I.P. 20 C.”, by Love and Rockets

Acronyms are a reality in most workplaces, but you don’t have to encourage them. If an acronym is hard-coded into a new system or process, you might have to teach it. And if the acronym is already part of day-to-day language of the employee, then go ahead and use it. But try not to inflict any new ones on them; new acronyms have to be decoded, and that takes mental work.

“Oh…’meltdown.’ It’s one of those annoying buzzwords. We prefer to call it an unrequested fission surplus.”
Mr. Burns, Nuclear Power Plant Owner, “The Simpsons“

Made-Up words are terms or euphemisms coined by leadership and the project team. If you use them, employees have to learn what you mean to gain entry to your training and understand their new way of working.

“Old words rule because people know them intimately. Familiar words spring to mind unbidden. Call a spade a spade, not a digging implement. Certainly not an excavation solution.”
Jacob Nielsen and Hoa Loranger, “Prioritizing Web Usability”

Flowery sounds pretty but like many pretty ones, she’s a bitch. Every extra syllable or complex word clings to your communication like a barnacle, weighing down and hiding your message.

“But,” you correctly point out, “the team built the thing (system, tool, initiative, job) using these new words. So now we have to use them!” Quite right. But think about it this way: you’re the expert on the people side of the change. Make a case for stripping out the nonsense, where you can. And, next time, stake your claim early on. Influence the project team to use plain English (or your spoken language).

Most tricky words don’t benefit employees. IT and integrators are comfortable with terms they made up, or words that come with the system. Management loves the spin their catchy terms and euphemisms put on a tough transition. Help them see their words are not helping achieve their objective: smooth adoption and achievement of the project’s business benefits. The easier it is for people to understand, the more readily they do something new. Use words that make sense to the people who will drive your change.

By Emerson Consultant, Brian D’Angelo

We love our new tech toys, don’t we? They bring us hope and happiness because each new piece of tech means that our lives and businesses are getting better and better…easier and easier.

The Cloud, cybersecurity, the entire Internet of THINGS…the potential is enough to make anybody and any company giddy.

But the problem doesn’t lie in the potential, it lies in the execution.

There are dozens of studies showing that many technology projects fail. And Forbes recently wrote that 54 percent of IT project failures can be attributed to poor management, while only 3 percent are due to technological problems. We at Emerson tend to agree. This fits what we hear when our clients talk about their tech implementations: they often fail to prepare the business for the change, sometimes because they rush implementation to achieve the promises of the technology.

It’s what I like to call “The Ready, Fire, Aim Syndrome.”

The Ready, Fire, Aim Syndrome of New Tech Is Real

For example, leaders might get excited to launch Tech A because they want to get more products to market faster, with a deeper connection to the consumer. Or they launch Tech B because the entire Creative Department will be 17.08% more productive during their shortened work weeks. Faster is better right? Faster implementation, more benefit.

But without a well-defined strategy, they doom their project to a number of expensive problems that affect the company’s bottom line. And that’s not all – company morale after even one failed initiative can be devastating, impacting both project engagement and employee productivity. Leadership often launches, then surveys the damage, then works hard to walk the change back or solve the problems the launch created. Ready, Fire, Aim.

The solution is fundamental change management. In other words: Ready, Aim, Fire.

Ready

Start by understanding the business outcome you want. Often, companies implement technology without confirming that it will actually solve their problem…or that they have a problem to solve in the first place.
Once you are sure the chosen technology will improve your business, study the impacts: who it will affect, how the change will impact those groups, and how it will affect the company as a whole.

Decide who will spearhead and sponsor the process and then get all your organization’s leaders rallying around one message to deliver to the organization and external stakeholders. Choose someone to build a robust communication plan that delivers custom communications to the different stakeholders in the change. Pick a team to build and deploy communications, training and conversion performance support, and ongoing support.

Having these people and plans in place sets you on the right path to maximum benefits and minimum loss of time, money and morale.

Aim

Now, implement your change management strategy, including the following:

• Get leaders aligned to help message the change.
• Engage early adopters to promote the change.
• Orchestrate stakeholders’ experiences with the new technology and focus their attention on the behaviors you want.
• Educate and train employees on exactly which behaviors to stop, start, and continue.
• Get IT and training teams ready to support performers.

As you execute these plans, you will build organizational momentum for the change.

Fire

If you have done all of the above, you are ready to launch. But don’t take your eye off the goal. Ongoing communication is support is critical to support users and stakeholders and make sure you’re getting the business performance and benefits you want.

Having a plan to avoid the Ready, Fire, Aim syndrome doesn’t mean you’ll avoid all the pitfalls of new tech launches. It means you’ll have a much better chance of success. And you’ll be ready to manage and recover from pitfalls quickly and nimbly, saving the company downtime and lost revenue.

Chances are, you won’t be in the unfortunate majority: tech projects that fail. Your change management will pay off in a win for your organization.