Change Issues
Managing the human aspect of the change that occurs with the adoption of a service-oriented architecture (SOA) with cloud computing can be a significant challenge. Chapter 7 showed that as technology and standards evolve, technical issues diminish, leaving the remaining restraining forces related to business, legal, and design issues. This chapter shifts the focus to human change issues. These issues most often manifest themselves in resistance to change. Forms of resistance and reasons for the resistance are discussed as well as ways to address such resistance. To anchor these concepts of resistance, I have included some of my own experiences with resistance to change.
At the end of this chapter is a worksheet for laying out change issues and responses to those issues. There is also a consolidated force field analysis for adopting an SOA that builds on the analyses covered in Chapter 7.
Change
Not everyone who has problems dealing with change has emotional problems that make transitions worse. In fact, most of us deal with change better than Orville did in this true story. Nevertheless, there are ways to make any change easier for people and for the organization in which they work. This chapter deals with human change related to adopting SOAs with cloud computing and ways to deal with that change.
Technical Change Issues Diminishing
There are multiple types of issues related to change. The drive to use Web services in an SOA with cloud computing is reducing the technical change issues. In other words, the barriers to change related to technology are diminishing. This makes the technical change easier. Figure 8.1 is from Chapter 7 and shows the technical forces affecting the adoption of an SOA with cloud computing. The gray arrows represent the technical restraining issues that will diminish as industry adopts and expands the use of this technology. Why these forces will diminish was discussed in Chapter 7.
Figure 8.1 Force field analysis of technical issues related to adopting an SOA with cloud computing.
The analysis in Figure 8.1 is interesting because it illustrates that as the technical restraining forces shown in gray diminish, we are left with technical issues related to business, legal, and general design. These are shown at the right in Figure 8.1. There are, of course, other business and design issues, but these arrows are representative of basic business and design issues facing any effort to create an SOA with cloud computing.
At the left in Figure 8.1 are the driving forces for adopting an SOA with cloud computing. The strength of these forces will vary by organization. Also, there very well might be additional driving forces for a particular organization. Nevertheless, by almost any measure, there are tremendous driving forces for the adoption of an SOA with cloud computing.
Resistance to Change
If it makes sense for your organization to develop an SOA with cloud computing, what other restraining forces need to be considered? Probably the strongest is a general resistance to change.
Resistance is a common human response to change. Resistance to change, however, may very well be the biggest issue to address in achieving an effective SOA with cloud computing.
Figure 8.2 shows the analysis of major driving and restraining forces related to change that affect the adoption of an SOA with cloud computing. There are often many restraining forces related to change. Also, if my vision of the future concerning the roles of IT staff is correct, some of the restraining forces will be stronger. For example, the restraining force of feeling that jobs may be threatened is very real as an organization moves through the process of adopting an SOA with cloud computing.1 You may want to try adding driving and restraining forces that are specific to your organization in the space at the bottom of Figure 8.2.
Figure 8.2 Force field analysis of change issues related to adopting an SOA.
As a manager, be on the lookout for resistance—where there is change, there will be resistance. The savvy manager is prepared for it and deals with it as it occurs. Some people like change and look forward to it. Those are the people who are looking for variety and they are your advocates in a technological change. There are also the folks who hate change. They may try to keep change from happening. In the middle are the “wait and see” folks. They are concerned about the impact of change on them, but they are willing to wait and see what happens. Often, this is the larger group. These are the people to focus on because you can win them to your side. Plenty of communication and participation can do wonders. The more employees worry and wonder, the stronger their resistance becomes. It’s just human nature.
William Bridges has written extensively on the topic of change in organizations for the past several decades. Bridges’ work, Managing Transitions,2 is particularly helpful for the manager planning a technology change. His model views change as a series of events going from an ending, which is the way things used to be, to a beginning, which is the way things will be in the future when the project is complete. Between the two is the neutral zone. This is a stage in which few things are the way they were and it’s not clear how they will be.
It is in the neutral zone, according to Bridges, where resistance can be found, because it is a stage that can be marked by confusion and uncertainty. In the neutral zone there are no clear markers and no promises. The savvy manager will be careful when dealing with people who may be in the neutral zone because they are seldom being difficult on purpose. They are unsure and concerned and may not realize their resistance. Sensitivity to the neutral zone is important because the manager can often help team members through this stage more quickly.
Forms of Resistance
Recognizing resistance can take some practice because many of its forms could easily be justified as a concern or a request for information. We all want employees who care enough about their work that they are willing to want to understand and state their concerns. As new projects are presented, it should be expected that employees will have many questions. In fact, one of the best things a manager can do is communicate in many ways and many times what the project entails. Some employees do better with written communication (email, blogs, websites, etc.), some with group meetings, and some with one-on-one casual conversations. All have their place in a plan for communicating change.
When a manager has communicated plans and time has passed, some team members may still be asking questions or raising concerns. Sometimes team members may be raising new concerns on a regular basis. If you have carefully considered the objections and found no grounds for the concern, this may well be a sign of resistance to change. Resistance to change in people can take many forms. Constant questioning about new concerns is a classic sign that resistance may be taking place. It also can take the shape of a form of confusion, in which the team member just can’t quite get clear on how or why the project will be the way it is planned. Such a team member is probably not doing this on purpose. It’s possible that this person is just not able to hear what is being communicated because of some discomfort with it. This person may well be in the neutral zone and is just trying to find his or her way through it.
Other forms of resistance may include silence or easy acceptance. People may be silent for many reasons, but it is easy to assume that silence means acceptance. That is not always the case, so be on the lookout for it. Easy acceptance can also be misleading because it may mean that the person has not considered the ramifications of the change; when he or she does think about it, you may find that this person upon whom you were counting on is no longer on board.
The following sections go into some detail on forms of resistance that were shown as restraining forces in Figure 8.2. These forms of resistance will also be referenced in the remainder of this chapter and the next two chapters.
Lack of Training/Understanding
Sometimes people are resistant to change because they do not have the training to understand what the new project or job will entail. Many people become familiar with their job and want it to stay the same. It is particularly challenging for them if the change in their job involves new technology. Almost everyone has a concern about not measuring up in a new environment and that may well be the situation here.
A second issue in this situation is communication. Sometimes people just aren’t getting the message that they need to hear. In a change situation, you can count on some people putting the most negative spin on any change. That’s just human nature. In a time of uncertainty, most people will fear for the worst. That’s why plenty of communication is of great importance. If people will need new training for the change, be sure they are reassured that they will get it.
Finally, the timing of training is critical. All too often, people are trained well in advance of using new technology. That is the equivalent of no training. People should be able to immediately use the new technology after training.
Power of internal “expert”
An internal expert can be a formidable ally or a formidable roadblock in a change effort. Such an expert knows the current system and possibly the previous systems in such a way that can be of great help. On the other hand, if this person is not on board for the change effort, he or she can raise all sorts of barriers. The savvy manager needs to find a useful way to involve an internal expert in the development process.
The most probable form of resistance will be in raising concerns about the quality of the new system, and this person is likely to use his or her expert position in the organization to raise the level of recognition of the concern. It’s easy to overlook what an expert has to lose in a change situation. This person is going from being an acknowledged success to a situation that is new. Because of the newness, it is impossible to know whether this person will be able to retain expert status or even if he or she will be needed in the new situation. An expert in this position may fear a loss of competence and control. That may be a big risk for such a person. This is especially true when the current expert may not have the kind of training that will make moving to the new system possible.
Inertia—why Change?
Sometimes it’s difficult to effect change in a system just because “things” have always been done a certain way or because the system is seen as working okay. This creates a sense of inertia. People who are part of the system ask why a change is needed. This can make it difficult when the new way of doing things will create a leap forward and will bring possibilities that have not been present before. Communicating the advantages of the new options may help, but when people are comfortable in the current situation, any change can be challenging and bring resistance into play.
In fact, it may be that our brains are wired for inertia. Christopher Koch reported in CIO Magazine3 on this phenomenon. He states that the:
“… prefrontal cortex’s capacity is finite—it can deal comfortably with only a handful of concepts before bumping up against limits. That bump generates a palpable sense of discomfort and produces fatigue and even anger. That’s because the prefrontal cortex is tightly linked to the primitive emotional centre of the brain, the amygdala, which controls our fight-or-flight response”
.
The article goes on to explain how parts of our brain interact and why we prefer to continue doing things the same way.
Feeling that Jobs may be Threatened
Given the pace of technological change today, it is difficult for most people to stay knowledgeable on new technology. This means that any change may feel threatening to many people. Often, technology changes are put into place so that staffing can be as lean as possible. That means that not everyone will have a job after the change in technology occurs. Those people who have not kept their technical skills up may have reason to worry. Because worry tends to be contagious in an organization, most everyone will be worrying. For some people, the outlet for this worry will be resistance.
As the use of Web services is more widely adopted for making connections and you move to a service-oriented architecture, some jobs will really be threatened. We are in the process of replacing custom-coded systems with reusable services. As a manager, you will need to keep this very legitimate concern in mind when creating an SOA with cloud computing.
Not Invented Here
Most people take pride in their work. It’s easy for managers to forget or not even know the blood, sweat, and tears that went into a project that was completed some time ago. The people who worked on that project do remember. When they hear that the work that they did will be replaced, there’s always a sense of loss. In the excitement of bringing in the new, the organizational focus ignores the earlier contribution of the people and their project and focuses on the shortcomings of the old. This can lead to resistance on the part of those who have worked on the old system.
Our Problems are Special
I’ve worked with many groups of people working on technology issues. Amazingly, almost all of them believed that the technical problems that they had to solve were quite complex and unusual. From my perception as an outsider, many of those same problems struck me as fairly normal for the industry that they were in or the work that they were doing. There were, of course, some twists that required attention, but those twists were not significant enough to scuttle a project.
This is a common excuse used by technical people to avoid using an off-the-shelf product or a cloud-based service. On a rare occasion it may be true, but most often it is just a means of resistance used by those who want to keep things as they are or to develop something new on their own.
Loss of Familiarity, Competence, and Control
Neuroscience research has uncovered information that explains a great deal about resistance. According to David Rock and Jeffrey Schwartz,4
Managers who understand the recent breakthroughs in cognitive science can lead and influence mindful change: organizational transformation that takes into account the physiological nature of the brain, and the ways in which it predisposes people to resist some forms of leadership and accept others.
Rock and Schwartz stress that change of any kind is a form of pain that causes serious reactions in the brain. In fact, research using magnetic resonance imaging (MRI) indicates that organizational change may be perceived by the brain as not that different from being attacked by an animal in a forest.
Change that affects a worker’s sense of familiar comfort about how to do the work, being competent at it and in control of it, may be the breeding ground for the resistance that so endangers many projects. The human brain appears to process information on several levels. The familiar is processed somewhat automatically and takes less energy. New processes are perceived as possible errors and require more energy. According to Rock and Schwartz, “Trying to change any hardwired habit requires a lot of effort, in the form of attention. This often leads to a feeling that many people find uncomfortable. So they do what they can to avoid change.”
Suggestions for Addressing Resistance to Change
The first step in addressing any kind of resistance to change is to recognize it for what it is. Sometimes resistance easily stops a project because it is never addressed. When the manager notices that nothing seems to be happening or that the project is far off schedule, it is past time to consider that resistance is at play.
The best bet is to anticipate resistance, even before the project starts. This means that you can set things up to avoid some of the resistance and you will be in a good situation to address it should it arise. The next sections discuss ways to address resistance to change.
Selecting the Right People
One key to the success of any project is careful selection of people to work on the project. Selecting a person because he or she has been around a long time isn’t generally a good reason for that person to be on the team. Choosing someone because he or she doesn’t currently have a project is not a good reason either. Sometimes staffing for a project is seen as a way to resolve problem personnel situations. That’s also not the route to success on your project.
The best approach to selecting the right people is to identify what kind of skills and experience are needed on the project team. Then find the people in your organization who can meet those standards. Be sure these people have a positive, open mind. If people cannot be found internally, then you need to consider new hires or a contracting situation.
My experience tells me that a big factor in failed projects is a lack of people with the skills and experience required. This is something that will hinder any project. The outcome of any project can only be as successful as the skills of the people who work on it.
Use a Second Set of Eyes
Another practice that can be of great help in limiting resistance is pairing team members together. There are many methodologies that call for paired team members. There are excellent technical reasons to do this, but there are also reasons that will address resistance to change. Careful team selection means that you are unlikely to have both people in the pair with the same issues. That means that neither person will be left stewing on his or her own. In addition, the possibility that both people will be allowing the schedule to slip or participate in other resistant activities is less likely.
Really Listen
One of the best things that you can do with someone who you think may be experiencing resistance is to listen. By that, I mean really listen and not try to talk the person out of his or her ideas. Most of the time, what we think is listening is actually thinking about how to answer the person’s objections. If you find yourself talking more than the other person, it means you aren’t really listening. If you find yourself explaining things, then you aren’t really listening. Some people think that just saying the same thing repeatedly will help improve understanding. When you find yourself doing this, it means that you are not hearing what the person is saying.
Sometimes what the person has identified as the problem is just the obvious surface of the real problem. It is more effective to ask the other person questions to probe into what might be behind the resistance. Ask questions such as, “What is your concern about that?” Follow up your questions with a summary such as, “So, you are concerned that if we implement this change, _____ might happen and that would be a problem because of _____.” Let the person clarify your understanding until you both agree that you understand the other person’s point of view.
If you listen in this way, you can even disagree with the other person, and the person will feel that he or she has been heard. People don’t necessarily need agreement to feel that they’ve been heard.
Communicate at many Levels
An effective antidote to resistance is communication and plenty of it. It’s a human response to anticipate the bad things that may happen and a communication vacuum contributes to that.
To deal with resistance issues, regular communication in many forms is helpful. People have different styles and it’s helpful to provide communication in as many forms as possible so that each style gets its needs met.
It also can be helpful to establish a communication schedule so that people can anticipate when more communication will be available to them. In fact, any promises that are made must be met. Don’t overpromise and then not meet the promises. That just sets up a foundation for mistrust.
And while you’re at it, think about communicating up the management chain as well. Find methods that will be reassuring to management and create a schedule that you can meet and that they can depend on. This helps protect your project from rumor and innuendo.
Seek Appropriate Avenues to Involve People
Participation is another important part of avoiding resistance to change. The more people feel part of something, the more they will support it. This can take a variety of forms, including asking for people’s input and review. Be sure to be clear in your request for information so that people really hear the request and believe it is really wanted. I’ve seen situations where management asked for input and got none because employees either didn’t hear it or didn’t believe it. If asking for input is not a regular part of your organization’s culture, you will need to ask in a variety of ways. Sometimes a casual request at the water cooler creates a more believable request than a general statement in an open meeting. And don’t forget to really listen to the input and ideas.
Get Resistance out in the Open
Naming resistance for what it is can bring it out into the open so that people can talk about it. Talking about it takes away its power to disrupt.
It’s important to do this in a neutral and nonthreatening way. For example, don’t point a finger and tell a person or group that they are resisting change. Such an approach is likely to make things worse—even if it is true. It’s better to create a situation where people can state their resistance on their own. Hold a team meeting and create a comfortable situation by stating something like, “I’m sure you have concerns about this change. I’ll bet that the new architecture is a little hard to understand in such a short time. At least I know I’d feel that way.” Approaching the issue in this way will make it possible to get the issue on the table for discussion.
Ask for Participation and Form Partnerships
Make sure you ask for participation and ideas and truly listen and consider them. People can accept almost anything if they believe that their ideas have been taken seriously. Create a partnership where you will be sharing information on a regular basis so that participants become familiar with what the new system will be. As they gain information, try to show how their competence will be needed. The more information they have, the more control they are likely to feel about the future. If you have people who don’t have the skills to be part of the future, address this with your human resource people. Leaving these people in limbo can create great negativity for the project.
Some Resistance Scenarios
This section includes scenarios from some of my own experiences with resistance to change (of course, names and details have been altered). After each scenario, resistance issues are listed and discussed. Then suggestions for addressing those resistance issues are also listed and discussed.
As you read the following scenarios, you will see certain themes emerging. The first is that resistance can take many forms and is not always immediately recognizable as resistance. The second is that the person resisting change is often not even aware of the motivation for his or her behavior.
But it’s so Complicated!
As he put a team together to replace an existing system, the manager felt fortunate to be able to include a person who had worked on the existing system for over a decade. Betty was a competent programmer and had a nearly encyclopedic memory of why the existing system worked the way it did. She was also quite articulate and seemed very interested in helping to create the replacement system.
The early investigations into how the replacement system should work went well. Betty was quite helpful in making sure the team had all the details and idiosyncrasies documented. She was also very helpful when it came to designing the data model the replacement system would use.
Then something happened. As the team started to design how the software would work, Betty started to bring up new issues that should have been uncovered in the early investigations. Of course, it is understandable that some things would be overlooked, but the number of these issues became overwhelming. Sometimes, these issues required considerable rework to change what was already completed. It seemed as if Betty waited until all the rework was done before bringing up another issue. And unfortunately, sometimes these issues also required rework. Eventually, however, the team seemed to have a robust design and was able to answer many of Betty’s concerns on the spot.
Then things started to get a bit weird. When team members would answer one of Betty’s concerns and show her how the design took into account the issue she raised, Betty would often respond, “But it’s so complicated.” Betty was apparently convinced that the existing system had to be more complicated than the replacement system.
Because of her experience on the existing system, Betty had a huge following in this large organization. She was known and respected all the way up to the vice-presidential level because she had worked with these people for decades. This replacement system was also seen as critical to the organization’s future. So, when Betty started moving up the management chain with her lament, “But it’s so complicated,” people took notice. Management started to want to know why the group was doing this inferior design and became worried about the future of the project. In fact, some vice presidents started to threaten cancellation of the project if the IT group could not do a better job on this critical replacement system. A lot of money was still allocated to completing this project and they did not want to spend that much money on an inferior replacement.
More and more time was spent on meetings with upper management. The system designers and analysts all had to attend numerous meetings. In those meetings, Betty brought up issue after issue concerning how much more complicated the existing system was compared to the proposed system. The dynamic was interesting. The issues Betty brought up were often in terms that management could understand. The explanation of how the proposed system would handle the issues often had to be in terms of data models and software architecture. Many people in management honestly did not understand the more technical explanations, so they were left with the impression that Betty might have a point.
Time passed. Development slowed. Eventually, the project was canceled. Sometime later, a packaged product was brought in to replace the existing system. But as you might expect, Betty at first thought the packaged product would work only to later discover that the packaged product needed much modification, because the existing system was so “complicated.” That project was also canceled.
Resistance issues in this scenario
Every technical change has incredible impact on the people involved with both the new and old systems. In fact, every change of this type has winners and losers. As development proceeds, people sometimes change camps.
In this scenario, Betty had worked hard over the years with the current system. She was emotionally invested in it and was very impressed with how well it worked and how important her role was. Because of her years of experience, she had created a strong network of personal advocates for her point of view. Initially, she may have been sure that no new system could possibly replace the system that she knew was very complicated, so she was willing to work on the team to replace it. In fact, she had already been on several committees in the past that had put the kibosh on replacements because the existing system, and of course the work that it had to do, was so complicated. In this particular situation, she was willing to participate and cooperate on the team until it dawned on her that this replacement system might actually happen. Then she began to raise issue after issue. When this happened, it became apparent that on some level she had begun to feel challenged in her position as the resident expert. I don’t believe that Betty knew she felt this way. I think she was challenged as an expert on a deep level. The rest is history. Betty used all of her connections to stop this project. Upper management can be notoriously fearful of failure and Betty’s concerns fed right into that. Sometimes it may seem that anybody can kill a project because of any “issue,” while it’s very hard to get enough people or the right people to back it.
Suggestions for addressing resistance
The most important issue in this scenario is to recognize the human issues that come with change. This has implications both for the people doing the work and management supporting the work.
Technical people generally approach others in the organization—and questions within the IT organization—from a technical perspective. While technical questions must have technical answers, there are other issues at stake that, left unanswered, will sink a project. In this case, Betty’s issues were not technical—they were personal. The closer implementation came, the nearer she was to losing her standing as the resident expert. So, naturally, the old system—her system—became more and more complicated in her mind and irreplaceable.
From the start, listening to Betty should have been important, but, beyond that, finding an important role for her in the new project should have been critical. Because she had connections in upper management, perhaps she could have served as communication person in the project, and an implementation role for the replacement system would have been important. The new system would have required training for employees, which might have been a good spot for her. Granted, finding the right role might be challenging and might require some coaching or mentoring to get her up to speed, but the alternative, in this case, was a failed project.
A second issue was not getting management on board. Betty was able to cancel a project through a whisper campaign to her old buddies in management. This indicates that management was not properly briefed or brought on board at the beginning of the project, nor were they kept informed properly during development. This is another situation where technical people may oversell the technical answer and not carefully communicate, on a regular basis, the information that can be understood. The very technical answers that can be so important and interesting to technical people may put off management who do not understand their significance. This means learning to go beyond the technology to what the technology will do for the organization. What are the outcomes that will make a difference to them? This should be the focus of technical/management discussions. When this occurs, a project will be less vulnerable to a whisper campaign.
Guerilla Tactics
One of the best technical minds in the company, Nancy was given the responsibility of designing and implementing the integration of two systems critical to her organization. The integration was somewhat controversial, with some seeing it as necessary and others thinking it was the wrong direction. Nancy stated that she was in favor of the integration and was given the responsibility for completing the project. She put together a small team and set to work on the problem. For many in the organization, this seemed to be about a two-month project. Nancy concurred.
At the two-month point, the project was not done. Nancy assured everyone that it was well on its way. At four months, it was still not done. Again, Nancy said that it was being properly handled; there were just a few glitches. At seven months, the project was canceled.
Resistance issues in this scenario
What happened? It turned out that Nancy really enjoyed working on the fringes of technology. She found some academic research that seemed to fit this problem quite well. Her team enjoyed working on the fringes of technology as well. They put together quite an elegant plan that involved writing significant amounts of code. Never mind that you could buy portions of the solution. Hooking that into the full solution would be less elegant. Given her status in the company, little oversight was maintained on any work she did.
What really happened? Although she had stated that she supported the integration project, Nancy did not think it was the right direction for her company. She may not have even been aware that she was using her emphasis on the elegant solution as a way to kill the project, but that’s what happened.
Resistance is an emotional reaction that can leave people unaware of the motivations for their actions.
Suggestions for addressing resistance
Managing brilliant, creative people has been a challenge since management began. Harnessing that capability in a way that will benefit the organization can be overwhelmingly difficult. In this particular case, Nancy either was not the right person for the job or she was not managed properly. Selecting the right people for the tasks in a technology project may be the most critical decision, but it is often less studied than the hardware and software to be used. Nancy’s interest in the fringes of technology could be very helpful to an organization, but in this case it killed a critical, yet constrained, two-month project. Her management should have foreseen this problem and could have either had someone else head the project or paired Nancy with someone who could steer her brilliance in a more pragmatic direction.
Second, Nancy and her organization were unaware of her true feelings about this project. Managers need to be on the lookout for signs of resistance. When things just don’t add up, resistance may be in play. Managers need to assess how things are going and be ready to make changes. Nancy’s manager should have taken a closer look at the project on an ongoing basis. Checking in at two months, when the project was to have been completed, was too late. Using standard project management techniques, a detailed schedule should have been developed and checkpoints, perhaps on a weekly basis, should have been observed. Activities such as design walkthroughs, code reviews, or inspections might also have helped. Given Nancy’s interest in the fringes of technology and her possible resistance, these checkpoints should have been quite in depth. This would have flagged the slowing schedule early on and changes could have been made.
More Guerilla Tactics
Todd had almost single-handedly built the company’s master record system. In fact, he had also been involved in the construction of two successive generations of the master record system. He had the respect of nearly everyone in the company. In this case, that respect was so high that he was seen as a systems guru. Todd agreed that it was once again time to upgrade the master record system. The present system was not fast enough and cost too much to maintain. Todd saw this as an opportunity to improve on his previous designs.
What Todd had built, however, was now available from numerous software vendors. Some of those vendors could legitimately show that their packaged software products could significantly outperform the system that Todd had designed. A technical review of the capabilities of the packaged software products showed, to most everyone’s satisfaction, that the software could perform as needed. But not for Todd. In meetings, he often brought up arcane issues. When asked to document them, he agreed. But it never happened and given his standing in the organization, his lack of follow-through was overlooked. More meetings would bring more concerns. To everyone on the development team, it was becoming clear that Todd had never been satisfied with the master records systems he had designed and that he wanted one more chance to do it “right.” The packaged software option would take away his opportunity.
Todd and the CEO of the company were close friends and had both been with the company from its start. Eventually, this relationship allowed Todd to recreate his master record system. It may not surprise you that the new system is still not as fast as the packaged system and requires more maintenance.
Resistance issues in this scenario
This scenario illustrates a huge shift that has already occurred in the software business. Not that many years ago, most organizations had to rely on a systems guru and a large staff inside the organization who could design unique applications to meet the organization’s unique needs. Now many products and services can be used as is or augmented to meet the organization’s needs. This is a huge opportunity for organizations to trim the cost of new systems.
The scenario does, however, point out the significant people issues involved in this kind of change. The huge change is not only in the software but also in the staffing needs that organizations will have in this situation. Gurus, like Todd, just won’t be needed on an ongoing basis any more. They may be needed on the front-end design stage, but that will be it.
This shift has huge issues for organizations in a number of ways. As in the earlier case of Betty, Todd was bringing up arcane issues that seemed outside of the satisfactory technical reviews that were taking place. This should be a clue to management that resistance may be part of the picture. Todd may not be aware of his personal interest in redesigning the system, but it does appear that this was a wasted opportunity for the organization.
Suggestions for Addressing Resistance
The challenge for management is to find a way that Todd’s abilities can be used in a positive way, rather in the negative way that has emerged in this situation. If no answer can be found, it is probably better for Todd that he move on before his technical skills become out of date. Although his relationship with the CEO might seem to make him invulnerable to change, a better point of view would be to use that relationship to help him find a fit where his skills would be of use.
The Elephant in the Room
George was a vice president of benefits who saw his organization as excelling at providing specific internal services to its employees. He wanted a system that, as he described it, would be the “Cadillac of systems” to support those services. Having established himself as an internationally recognized expert in this area of internal employee services, he had convinced upper management to fund this effort.
Early on, an outside consultant was brought in by the IT department to help define the needs of this internal system. It was clear to the consultant that there were several commercial systems on the market that would easily support the needs of these internal systems. The IT department told the consultant to not bring up this possibility because it was important to George to build his own system and George was a vice president. In fact, George saw the organization eventually selling his “Cadillac system” to other organizations.
Building such a system was more expensive than buying one on the market. No one in IT, however, ever brought up the idea of buying a commercial product rather than building one. While this system was being built, the organization’s income decreased significantly in areas independent of the development effort. As a result, it was determined that it did not make sense to spend this much money on such a fancy internal system. The project was canceled after already spending many times more money than a commercial product would have cost.
Resistance issues in this scenario
Telling the truth about technology can be a politically painful event, especially when people in high places are the people who need the message. Many a manager has had to deal with a “pet project” of upper management.
Suggestions for addressing resistance
This is a case when “managing up” would be a good idea. In this scenario, no one even raised the idea that commercially available software might work as well. Carefully planting the idea that this is possible could have been done in such a way that the VP would get the message clearly. The VP’s need to have a special product might also have been addressed on another project.
Worksheet for Resistance Issues and Suggestions
The scenarios above provide some examples of resistance issues and the possible suggestions for addressing those issues. Of course, you may have other resistance issues in your organization that may benefit from different sorts of responses. Figure 8.3 provides a worksheet you can use to think about restraining forces you may have added to Figure 8.2 and possible suggestions you could consider.
Figure 8.3 Resistance issues and suggestions worksheet.
Consolidated Analysis for Adopting an SOA with Cloud Computing
Figure 8.4 consolidates the driving and restraining technical forces from Figure 8.1 and the driving and restraining forces related to change from Figure 8.2. The restraining technical forces that will fade away over time (the ones shown in gray in Figure 8.1) have been removed from this analysis. Figure 8.4 shows that using Web services reduces the technical issues restraining the adoption of SOAs with cloud computing and leaves business, legal, design, and resistance issues. Business, legal, and design issues will always be with us. Resistance issues will form the biggest obstacles to the adoption of SOAs with cloud computing.
Figure 8.4 Force field analysis for adopting an SOA with cloud computing.
Summary
The use Web services is rapidly removing many of the technical restraining forces related to adopting an SOA with cloud computing. At the same time, these technologies are adding technical driving forces toward adoption. As a result, the primary restraining forces within organizations for adoption of SOAs have to do with business, legal, and design issues—and human resistance to change. Business, legal, and design issues are part of developing any architecture. Change issues, however, could trip up the adoption of an SOA. Ways to identify and address resistance were covered in this chapter along with scenarios of various forms of resistance. Chapter 9 will expand on dealing with resistance by providing some tips for managing change issues.
1Many of these same forces have existed for the adoption of any technology for many years. Nevertheless, I think the expanding adoption of SOAs will have significant impact on IT organizations.
2William Bridges, Managing Transitions: Making the Most of Change (New York: Da Capo Lifelong Books, 2009).
3Christopher Koch, “The New Science of Change,” CIO Magazine, October 2006, http://www.cio.com.au/article/170700/new_science_change/.
4David Rock and Jeffrey Schwartz, “The Neuroscience of Leadership,” Strategy + Business, May 2006, http://www.strategy-business.com/article/06207.