Change Management and Business Requirements

Ann All spoke with Erik Van Slyke, a founding partner of Solleva Group, which helps organizations plan for, implement and manage change. You can also read his guest opinion: The Structure Required for Adaptive Change Management.

All: Why is it so important for companies to incorporate change management into their business requirements documentation?
Van Slyke: Often business requirements documentation focuses exclusively on the technical change. But it’s not just the things that might fall in that change management bucket that should be included. I’d go further and say that you want to include all of those things that are impacted by that technical change. There's a kind of worst-case business requirment document focusing on straight up technical specs, and there is usually a movement along the continuum up toward the ideal, but it’s rare that you get the whole package. Unless you have a technology that is completely behind the scenes, such as benefits calculators that might be used by HR on an admin site, then (change management) becomes a little less important for that kind of behind-the-scenes change.

All: Sure, it really doesn’t make a whole lot of difference to the end user.
Van Slyke: Exactly. But with every incremental step you take down a continuum, users are impacted. If we take a look at what additional things should be built into BRDs,  let’s start with just data structure and how it impacts people. That is typically something that would be captured in a BRD because it's technical. But any time you change data structure, there is usually a change that occurs to the process of entering or maintaining or reporting out that data. This is almost biblical in that data begets the process begets the role changes. Once the process changes, that process change will end up automatically impacting how people work. Once you change how people work, that might be as simple as changing basic work instructions or work procedures, but the more that changes, you need to really then take a look at whether or not that is impacting the role itself. If a process streamlines and you remove activities from someone’s job, that role starts to change. Then once roles change, there are org structure changes. So you look at things beyond the technical like process, work procedures, roles and org structure.

In my mind, when you're putting a technology in place, you need to look at all of those factors. At least capture that nothing changes, if there’s no change. But once you start looking at those things, you can’t help but need to build in change management. At that stage you're really looking at, "Here’s a new future state and we’re moving from our current state or the as-is-to-be models." There’s a gap typically between as-is and to-be, and that’s the heart of change. I go beyond technologies to include an area where I see a lot of IT professionals dealing, and that is this whole outsourcing or partnering with external vendors where they're taking a component of process. Any time you add these features of technology or an outsourced solution, you're changing all of those downstream impacts.

Capturing those impact areas tees up change management concerns. At the simple level, it’s just making sure that we have the new process or these changes captured and communicated. At the more complex level, it means we’re shifting to a more fully adaptive challenge. That's the meaty stuff within change management, it requires some process to incorporate the end users or others who might be impacted into the process. I think there are really two different kinds of changes we see in organizations. There’s a technical challenge, or a technical change, and an adaptive challenge. The technical change is something where we can use established procedures to solve that problem. All we have to do is turn to that place in our operations manual, and there’s the solution, we implement it and that’s it.

An adaptive challenge is one where a solution must be created. It’s one where there’s not a prescription. Most importantly, an adaptive challenge is one that requires that we involve the people that we're in fact trying to solve. Understanding the distinction between the technical and the adaptable in the BRD process is important. Any area where we’re seeing an impact area that can’t be solved by established procedure requires change management to be built in the process in order to minimize the risk of human emotions and behavior getting in the way of that solution being implemented.

All: So, in theory by involving the users in the way that you mention should give you a much greater chance of project success. If  users are involved and they feel their needs are being taken into account, they'll be more receptive to change.
Van Slyke: Absolutely. A good BRD process, whether it’s one that is just one-on-one conversations or some sort of workshop process, that’s the point at which you can leverage these other folks or leverage the end users or leverage the team that is creating the solution to look at these challenges. Just going through a simple model and saying, “Here are all the tech specs, here’s the data, process, roles, structure and other buy-in issues or stakeholder issues,” you’ve at least created a model that lets you check the box that you thought those issues through and covered them. Once you have more than a few people in the room, it really becomes quite evident they're going to contribute all sorts of issues that wouldn’t have been covered otherwise.

All: So why do so few companies do it? Is it just part of a larger tendency to downplay change management? It occurs to me as we’re talking that maybe another issue is a desire to get projects down within a given timeframe. Companies might worry that going into this kind of detail will take too much time.
Van Slyke: Well, I’ll start by sharing some statistics. There have been countless research studies on organizations that have conducted any kind of technical implementation or outsourcing or other organization change. The stats are pretty clear that between 30 percent and 80 percent of change initiatives failed. That’s a broad range of statistics, but even if you look at the one third figure...

All: Yeah, the low end of the scale is pretty bad, right?
Van Slyke: That would suggest that it’s not an accident. It suggests there is something going on that creates that failure. It would also suggest it may be related to capability, but it’s not necessarily the hard-core manager's approach, “We just have to get the right person involved and that’ll solve the problem.”  It’s more complex than having an unskilled project manager. So somewhere between 30 percent and 80 percent of change initiatives fail. What’s also interesting is in similar studies 80 percent of companies will list leading change as a top five leadership competency.

So they're all recognizing that it’s important, and 85 percent of those companies feel this competency is not as strong as it needs to be in leadership. Now, again, we're using a broad definition of leaders that would include executives in these studies as well as project leaders. So in other words, we’ve got pretty consistent amounts of change failing, minimum to maximum. Companies recognizing that leading change is an important skill set but that it’s not in their leaders.Yet only about 14 percent to 25 percent of those organizations sought any outside support to their change initiative, and 29 percent of organizations launch change initiatives with no formalized approach at all.

What’s nice about the flip side of that last statistic is that about two thirds of organizations are thinking about a formalized approach. But there are some things that I’ll get into in a moment that would suggest something else will need to happen, whether it’s in skill development or in an approach, what kind of approach to change in order to make that work effectively. So those are some up-front stats, but I think there are two reasons why change is often downplayed. You hit on the first one. Most of our business organizations are set up to all-around results and efficiency. Quite frankly, we have cultures where emotions are ignored because at the very least, it’s unprofessional to have emotions. So I think most change leaders say, “Listen, we know we have to change, we’ve got to get this thing in place, it’s the best thing, it’s logical, it’s rational.”  But human behavior is not rational. Even sponsors of initiatives, once they start to see impact, even if they're the ones shouting from the rooftops, “We just need to get this change in place,” when they start to see the impact of the change, they're at the very least going to start tailoring it. And now we have an adaptive challenge. So I think that’s a big part of it is the whole rational organization.

The second thing is, managing change is hard. About a year ago I helped a global pharmaceutical firm manage the change related to implementing multiple technologies as part of an outsourcing initiative. The executive sponsor for this was a woman who came from an HR function originally. She had an HR background, so she was keenly aware of the need to build change into this. She was wise enough to see three different stakeholder groups: the end users who are going to be the recipients of this technology; the HR and finance teams and to some extent the IT teams that will manage this technology and tailor it as we go along and be involved heavily in the process of pushing information out to the end users; and the project teams. This was going to be an 18 to 24-month implementation. So she said, “We’re going into this and there are a lot of areas of potential impact.”

They started with a great methodology. They used Kotter's methodology, which is one of the standards, and they put a whole team together to think about the communication, training and people impact issues. They started with the right number of resources and the right capabilities, and  I think partially because they were a pharma firm they could add a little extra cash to invest in this. They had a detailed plan, they had a methodology, but as soon as they started to see some technical hurdles and get some pushback from the various divisions, they were caught by surprise. She claimed that they missed important cues along the way because they were too focused on executing the plan once this whole thing started. Even with the change plan they were so focused on the deliverables that they had structured that they failed to see some of the challenges in time. They also thought those challenges would work themselves out and, as a result, didn’t react fast enough.

So in my view, it goes back to this notion that change is hard. The difficulty even of leveraging proven change models lies less in the construct of the change model itself and more in the challenge of applying a rational uniform framework to the irrational and unpredictable elements of human nature. Frank Lloyd Wright once said about architecture that the architect's most useful tools are an eraser at the drafting board and a wrecking bar at the site. Managing change is very similar to this, and the most useful tools are those that help you behave adaptively once a project begins.

All: Do IT departments tend to be less comfortable with change management than other areas of the business?
Van Slyke: Well, I think you're right in that IT, because of the the working frameworks they use, they're less comfortable typically when these kinds of challenges occur.  I would actually say IT more than many other functions is more keenly aware of the need for change management. Typically when I walk into a project, it’s the IT people who are the first ones that come up to me and say, “OK, I need your help.”

All: That’s because they like everything to work according to plan, I would assume? They figure if you plan everything out just right, everything will work according to plan.
Van Slyke: Right. If you think about how IT people work through those project plans, they might build a project plan that is 25,000 lines long and they might have a PMO capability and be doing risk management, but when there is an issue from the change team that turns red, that’s when they're looking for, “OK, what are the three things you're going to do to mitigate that risk?”  That may be as simple as those three things. Then when the change team does those three things, and the issue is still on red, that’s when it becomes challenging. Now we’re looking at potential impact that touches other work streams within that project. That’s when project managers and IT work stream leaders with less developed skill sets say, “Well, can’t we just go looking for the manager to tell everybody they must salute? Get in line and salute?”

What’s interesting is, this is a skill set that some people have naturally, intuitively or genetically. When you see them apply this stuff, they're geniuses and they're highly, highly valuable in organizations. I would say some of the better change managers actually come out of IT because so much of what they do touches so many different parts of the organization. There is an awareness there that you don’t find in other parts of the organization. But again, even those IT managers who have the skill intuitively very often aren’t fully aware of what they're doing. As soon as you don’t have that kind of awareness, then it becomes more difficult to apply tools from the bag of tricks -- adaptive tools -- to engage in the process of managing the challenges.

All: Of course I saved the biggest, hardest question for the very end. How can companies really ensure that this gets done?
Van Slyke: I think you need involvement and participation, and sooner rather than later. Even if you have business sponsors, even if you have great end user groups that are involved in the beginning, it takes a while for change to sink in. You might see a half-dozen product demos and it all looks great, but usually with technology changes in particular, those demos are showing the system at its end state and the system with all its benefits. So I would go back to this BRD process. BRDs are usually done early on in project engagement. But it needs to be part of the lead-up. Say, "Here’s what this new technology will do. We haven’t purchased it yet, but let’s look at the impact areas now and start thinking about them.

It’s almost an early stage BRD process that integrates all of the components that are in the ideal BRD process that I mentioned earlier. So end users and the sponsors who are involved in making the decisions about the technology itself or giving the approval for that new technology can start thinking about the impact areas. Rushing to the coolness of the new solution ends up interfering with the overall change process because you think you already have buy-in. Then the hard work of the implementation begins when these areas of impact become much more evident.

All: So just thinking about them that early in the process is a good idea.
Van Slyke: And it’s extra work, but it’s the old adage of measure twice and cut once. The unfortunate thing with major technology changes is that you're measuring 50 times, and then you're cutting, and then you're likely measuring 25 more times after that because you're not possibly going to think of all the impact areas, at least not until you’ve developed regular discipline processes of incorporating the full BRD in at various steps of your implementation.