What a difference a year makes.
In November 2011, I wrote a blog post titled, “Is your IT system a Dreamliner?” discussing how revolutionary advances in technology also introduced new risks that need to be monitored and managed. I also wrote, “Do you think Boeing is going to monitor these risks and take action to mitigate them? You bet they are."
Looks like I was right.
While I am sure Boeing would rather have avoided all the problems they currently face with the 787 Dreamliner, I bet they are very thankful they had the structures, processes, and people in place to effectively manage the problems that have emerged now that their planes are actually being used.
Are you prepared to manage a crisis with your technology?
In my earlier article, I wrote:
“When implementing new IT systems, many organizations focus on getting the system live, but ignore what happens once it is in production. The value of your system – and the risks – only is introduced after the system is live. And they continue over the life of the system. This means that you need to manage the value creation and risk mitigation over the life system.”
This is what happened with the 787 Dreamliner. The plane went through extensive testing and government approval processes, yet the unexpected problems only emerged after the plane was live and being used on a daily basis. Just like with an IT system.
Boeing faced new risks when introducing new technology into their aircraft. Organizations face new and unexpected risks when introducing new IT systems. However, unlike Boeing, most organizations do very little to prepare for and proactively manage their new IT risks. And they do so at their own peril.
Do you have the right governance plan in place?
Implementing new systems – regardless of whether it is a proven cloud enterprise system or a custom-built application – introduces new risks and uncertainty into your organization.
For example, “social” applications, collaboration systems, and CRM systems all alter how your staff interacts with each other, with customers, with vendors, and with the public at large. You now have new risks that someone will release sensitive information, say the wrong thing online or fat-finger their touch screen and create a major public relations issue for your organization (can you say “viral”?).
When this happens, you need to have the right team and protocols in place. Do you?
What should you do?
Before you write a single check for a new IT system, map out exactly when you will get your ROI from the system and when new risks will be introduced. By doing this first, you will see that all of the benefits – and risks – happen after the system is live. And that they will continue over the life of the system.
Then, make sure you have people in place who have the formal authority, responsibility, tools, and resources they need to manage all the risks that will emerge over the life of the system. These same people should also be responsible for ensuring systems are fully adopted by end-users and that the organization realizes its full ROI goals.
Where to start? Two tools that can help.
When I talk with people about managing risk and user adoption after a system is live, they typically see the need for doing this. And they typically have no clue about where to begin. They need help.
1. Start with a user adoption strategy and team. By first understanding the issues you face and then identify the methods and infrastructure you need to address them. I recommend that you develop a user adoption strategy. And then consider a tool like MyUserAdoptionPlan.com to help implement the strategy and support your users.
2. Then, add risk and governance tools. There are a lot of risk and governance tools out there that can help. The one that we like best is the suite of tools from Confident Governance. This tool-set, which is built on the force.com platform, is fast and easy to configure and provides a wide range of capabilities to help you define and implement your risk and governance policies. Also, it has very affordable pricing and is within reach of most organizations.
Don’t let your IT system be a Dreamliner
You have invested a lot of time and money in your IT systems. The right systems can take your organization to new heights of success. And it can all go away with just one unexpected problem.
Don’t wait to manage your IT risks. Get started today.
When I speak to executives who are about to start a new system implementation project, their attitude toward change management is typically quite casual. They approach it as an afterthought, not something that is key to the success of the system.
Frequently they make comments like, “yeah, we need some change management, give me some of that” – as casually and as off-handed as if I’d asked them “do you want fries with that?”
One size fits all change management programs don’t work
Perhaps part of the problem is that people don’t fully understand change management nor do they recognize how they need to employ different change methods based on their specific needs.
Instead, I often encounter a perception that change management is basically just some communications and training. Experience has taught many people that you initiate the change management program after the system development effort has begun and you stop it after the system is live.
Unfortunately, this approach doesn’t work. In fact, it may actually be killing your change management program. It is time to rethink how we structure and deliver our change management programs.
Match your change adoption approach to your situation
Today, there are lots of different options for how organizations implement technology. Some systems take years of planning and development, where others are live in just a couple of weeks. Some systems are highly customized and others are deployed right out of the box. Some systems are stable and rarely updated and others have new releases every few weeks.
Each scenario has different change management requirements and challenges. You need to match your change approach to your specific situation.
3 scenarios that require different approaches
Here are three scenarios to consider. There are many more out there and we recommend checking to make sure you have the right change approach for your situation before you even start your project.
1. Long-term, slow-moving projects (major transformation efforts)
With long-term slow-moving, projects – like those that require many months (or years) of up-front planning and development – you can accelerate ROI by de-coupling the change and user adoption effort from the system go-live. This allows you to start the user adoption and organizational change program first, enabling increased organizational performance (ROI) even before the system is live.
Because so many of the reasons for poor user adoption are organization-based and lie outside the technology just switching systems doesn’t resolve these issues. By addressing these organizational issues up front you can get more ROI out of your existing system. You also help separate any issues / resistance people have with the organizational change itself from their perception of the new system, thus people are less likely to blame the new system for organizational problems.
2. Short-term, fast implementations (cloud systems)
With short-term fast-moving, projects (think cloud systems) the technology can go live before the organization is ready for it. There is not enough time to setup the change management program itself, let alone conduct change activities to fully prepare users for the upcoming system.
In this situation, you need to cut the time it takes to establish your change program, deliver whatever change activities you can before go-live, and the retro-fit your change effort after go-live.
3. Ongoing, constant system evolution (agile development)
When your system is undergoing constant development, such as with agile development, your users face a situation of continuous change and instability. While this is a great development approach it is not great from a user adoption perspective. In other words, for the technology it works, for the human beings, not so much.
Continuous development and release cycles have in effect transformed users’ learning curve into a learning treadmill. Users tell us that they never know what has changed and that they are constantly having to spend time searching for information or learn the latest changes to fields, layouts and functionality.
In these situations you need to make sure users have easy, reliable access to the latest information. They also need to access to support that can resolve both their technical and business process questions. Further, with each release of new functionality you need a communication effort. You also need to constantly review and update your policies, procedures, responsibilities, user adoption goals and metrics.
In short, if you have ongoing, constant development you need an ongoing, constant change management effort.
Currently, a local b-school has a bus ad that reads “technology is ubiquitous; management is necessary”. What struck me reading the side of the bus was -- thankfully not the bus, but --- that there was an element missing. Now, granted, it’s a bus ad so there’s limited space but the gaping hole between the two statements is something that hides in plain sight: the constant that affects everything - change.
Change is constant – you have to keep up
Change and the ubiquity of technology are deeply intertwined and the marriage of the two is the reason management is necessary. And getting ever more so.
But if change is the thing that drives both technology and the management thereof, how do people and organizations manage the change so
a) it doesn’t run them over (making them technology roadkill), and
b) they get the desired impact and outcomes?
Technology moves faster than people do
Directing -- and managing – organizational change when implementing technology is especially important in the face of
• the speed with which technological changes can be made these days (cloud, anyone?) and
• all of the moving parts within a change process that only increase exponentially every time another team or business process is added to the mix.
So what are you to do when you’re getting pressure from the top to deliver better results faster, and you’re getting grief from below about all the changes that are being made so quickly?
In an ideal world, you’d have a formal user adoption program and team – beyond the implementation team – to facilitate the transition and sustain it on into the future, ensuring the necessary ROI and achievement of business goals throughout the life of the system. But at some point, the system is live and the consultants and project leads go home. And you still need help.
This is where having an IT adoption plan, focusing on the human side of technology change, is key to success.
Focus your IT adoption efforts on your team, and not on the technology
At a conference earlier this year, we heard a phrase we could really identify with: “it’s not the software that fails, it’s the fleshware.”
Think about it: the time, the energy, the planning, and – quite frankly – the money that go into bringing a new system online is almost exclusively directed at the technology. That is, figuring out which to get, once procuring it getting it customized, up and running and people trained on it. Then, people are set loose and attention is directed elsewhere.
But what about the people? A portion of their daily work life has changed significantly, which changes them, their teams, business processes and the organization but chances are none of those changes have been focused on with the same degree of effort the software was.
With an IT adoption plan in place – ideally from the point when you decided to change technologies – that contains vital elements such as:
• Outlined business goals cascading into department and team goals
• Corresponding metrics against which everyone will be measured
• A relevant and meaningful two-way communication strategy
• Revised and specifically defined roles and responsibilities and
• Individualized action plans for each team member to succeed
Because that bus ad is all too true. Technology is ubiquitous and management is necessary. It’s just that technology changes organizations, their cultures and how/when/why people communicate and interact.
Strategically and purposefully planning for and managing the People Factor is a major undertaking, but the only one that will deliver the benefits and value you need and want from your new IT system.
Setup an “audit ready” change adoption program
Many change programs focus on preparing the organization for the upcoming change, but they do little to ensure it delivers the desired business results after the initial change is complete. Instead of focusing on a single point-in-time event (like the “go-live” of a new IT system), you should instead focus on the results you would like to achieve 1, 3, 5 or more years into the future.
To do this, create a program that clearly articulates the results you want, how and when you’ll get there, and how and when you’ll check to see if you achieved your goals.
You define “testable requirements”. Now define “Testable results”.
For years, IT has called for the creation of “testable” requirements. One definition of testable requirements is:
“A testable requirement is a requirement that has been broken down to a level where it is precise, unambiguous, and not divisible into lower level requirements. These criteria are only met if it is possible to write a test case that would validate whether the requirement has or has not been implemented correctly." Source: http://www.testablerequirements.com/
Testable requirements are important because they help ensure the system meets users’ needs and that nothing was lost in translation between the users and the developers.
The next step is to come up with “testable business results”.
That is, can you replace the word “requirement” in the definition above with the term “business results”?
Can you define and communicate – precisely and unambiguously – the actions and outcomes you want users to achieve from their adoption of your IT system?
After all, what you are after is the business results that are achieved from the effective use of the system.
Communicate to users the results you will audit
It is alarming how often users tell us, “No one ever told us we needed to do X” within the system. And it’s alarming how often it’s not explicitly and effectively communicated as to what’s changed and what new things users need to do in the system. In cases like this, behavior can’t be audited and people can’t be held accountable for achieving results that were never defined or communicated. Define the goal, specify the actions to get there, inform people what’s expected of them and how they’ll be measured and then measure their behavior.
For effective change adoption programs, there should be no ambiguity amongst users exactly what it is they are expected to do and by when.
And there should be no ambiguity of the consequences if these expectations are not met.
Verify results. And hold people accountable.
Once expected actions and outcomes are fully defined and communicated to everyone, go back and check actual results. Effective change adoption programs will explicitly define the timeframes, procedures, and parties responsible for conducting audits and holding people accountable for achieving expected results. Just like with financial audits or ISO audits, user adoption audits need to hold people accountable for their actions.
Specific corrective actions and set new goals
The final step is to include a mechanism in your change audit for defining any required actions to correct deficiencies and to update specific goals for moving forward. Your people, organization, and operating environment are all in a constant state of change and you need to continually update your testable results and audit program to meet future needs.
Business Cases & User Adoption Learn more about how user adoption impacts your business case.
Not sure where to start? Ask us Tap expertise on demand and find out how you can have a successful change event in your organization.