Technology and Process Change.

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.

Successful companies are constantly disrupted as they chase the benefits of new technology. Today, the three main areas of business technology change are the move to the Cloud, Big Data and Data Security.

Companies trying to stay up to speed on each of the three have to manage a lot of change at once. An organization might have hundreds of concurrent initiatives to upgrade systems, analyze big data, or maintain infrastructure. Over 90% of the Fortune 500 are now in the process of moving some or all of their technology infrastructure to the Cloud; they are working primarily with Microsoft’s Azure, Amazon Web Services, or the Google Cloud Platform.

Based on current data, we can forecast with certainty that the move to the Cloud will dominate technology organizations and drive the demand for talent for the next decade. Many industries are putting in place new best-in-class solutions based on infrastructure-as-a-service and Cloud-based applications.

How then must an organization plan for such a disruptive change? What is the scope of budgets facing approval by senior management? What will it take to implement a whole new way of doing business using The Cloud?

The best organizations are thoughtful about technology transformation. Many perform a comprehensive study of potential solutions and chose the right technology vendor. They build a comprehensive budget based on the costs provided by the vendor for the technology.

Yet many don’t adequately budget for behavioral change, which drives most of the business case. How will your people perform with the new technology? Will roles and interactions change? What are the as-is and to-be processes? What are concurrent initiatives that might draw employees’ attention away from the transformation and impede success? Being thoughtful about technology means considering these as essentials.

A successful major technology transformation must include a strategy and budget for helping people manage the transition and perform during and after the change. Job roles and processes will change for most employees. To get the full benefits of the technology, every employee must adopt new behaviors, work within new processes, and respond to new team and organizational goals.

So how much should you budget to engineer the employee experience (otherwise known as change management)? There are several ways to estimate the investment. We don’t recommend anchoring it to the IT investment – one has little to do with the other, particularly as the cost of technology drops every year. But you can anchor it to the business case benefits: what percentage of the business case depends on your employees behaving differently? Or you can pick a reasonable amount to spend per employee, based on your particular technology and the degree of behavior change required.

The investment in employee performance is easy to justify. Around 60% of the business case for any technology change is driven by changes in behavior, while only 5% is driven by workforce optimization. Synergies, financial benefits and cost savings make up the rest.

For example, if the business case is $100 million, up to $60 million of the benefit will come from employees becoming more effective and efficient in their new roles, leading to increased sales and profitability. The budget to design the Employee Experience should be set in relation to the overall business case. Some of the most successful companies spend up to 10% of their business benefit on designing the Employee Experience. The success of the business case is driven not only by an investment in new technology, but by a purposeful investment in people and their performance.

For more on technology change budgeting, read this chapter from The Technology Change Book.

Application migration is a fact of life for businesses today. Companies commonly move application programs from one environment to another. Smart leaders include stakeholders in their migration plans.

Keeping stakeholders informed as the migration draws near is critical to the success of the project. Ideally, strong communication means everyone affected will be working to support the move. This helps the business avoid disruption and meet its objectives.

One way to prepare stakeholders for migration Go-Live is to deliver “T-Minus” communications.

My Go Live Approach

T-180 – Six months before the Go-Live, send an email to impacted stakeholders that the migration is coming. Give them the basics: the reasons, the timing and information on how to prepare.

T-60 – Two months before the migration, send another email to those affected, letting them know the migration is getting closer. Repeat the information you sent before, and emphasize preparation and help from the migration team. Most important are the migration window, IT team contact information, and any other ways to ask for support.

T-30 – One month before the migration, send a similar email. Continue to ask for questions and concerns.

T-21, T-14 & T-7 – Three weeks, two weeks and one week prior to the migration Go-Live, email again. Use any questions you have received from users to anticipate the information people might need; you can proactively answer questions for the larger group.

T-1 – One day before the migration, send final instructions to users. Remind them of the migration window and contact information.

T-1 Hour – On the day of the migration, send an email asking stakeholders to shut down any systems or applications involved in the move.

T-0 – Once migration is underway, email users to let them know the process kicked off as scheduled. This will also help you catch anyone who didn’t comply with the shutdown request.

T+ Migration Updates – During the migration, send emails to impacted stakeholders based on migration milestones. These messages assure stakeholders that the migration is proceeding as planned – it gives them confidence in the team and the process.

T+ Go-Live Complete Announcement – Once the migration is complete, send a notice to inform stakeholders that the migration was successful and the application is ready to be used again.

There are many ways to share information for a migration. This is an approach I’ve used successfully. How have you approached this type of work?

When I first heard about WannaCry and Petya, I thought they were Reddit usernames. Unfortunately for thousands of Microsoft OS users, WannaCry and Petya are not so harmless – they are the names of two major ransomware attacks that hit systems across the globe and battled cybersecurity.

Petya halted companies like DLA Piper and Oreo’s producer Mondelēz International by making it impossible for employees to access their computers. To make a long story short, computers using Microsoft had a vulnerability called EternalBlue. Microsoft released a fix for the liability in March 2017, but any users who didn’t accept that update were vulnerable. In other words, if you didn’t press “Install” when the antivirus box appeared on your screen, your computer was at risk.

Like our CEO Trish Emerson says, the first step to cybersecurity is realizing your business isn’t facing a technology problem — it’s a behavior problem. Petya did so much damage only because of an action users decided not to take. Get your employees to change their behavior (like installing security updates), and you’ve strengthened your first line of defense against cyber threats.

We created a quick and easy video series about turning your employees into cybersecurity warriors. Take the first step to safety by learning how to change behavior.