17
Dealing With Thorny Issues
Something was different in Gary’s cubicle. As I entered to talk about the change project we’d been working on for the past few months, I noticed he had tacked up a poster for the classic movie Indiana Jones and the Temple of Doom. Gary and I started to chat about how drained we both were feeling. We had been traveling back and forth each week from New York to Indianapolis to work on our project, and things weren’t going well. Our vendor wasn’t delivering what it had promised. The vendor missed deadlines creating the software we needed, and the programs it provided didn’t work anyway. From what Gary and I could see, the vendor didn’t have the capability to make things work. We felt stuck, convinced nothing could be done to fix all the issues we faced, and we believed that the project should be scrapped. But that wasn’t our call to make. As I turned to leave, I took a closer look at the movie poster. And then I saw it. Gary had photoshopped in new actors and a new title for the movie that cleverly reflected our experience. Gary, the project team, and I had starring roles in the action thriller Indiana Drones and the Project of Doom.
I’m not sure about the drones, but the “project of doom” part was certainly spot-on. Regardless of our efforts, this project was a stinker.
Some of them are. Some change initiatives just seem to be rife with challenges. Thorny issues arise, one right after the other, with no end in sight. It can feel overwhelming and disheartening. And yet, sometimes when projects go off the rails, they can be set right again. Issues can be addressed. Problems can be solved. And your organization can achieve the outcomes the initiative is supposed to generate.
In this chapter, we’ll look at the actions you and your project team can take when thorny issues arise that threaten your success. We’ll review some general principles your team can follow that will help you identify the source of your team’s problems and the path to address them. We’ll cover a few specific problems that may arise during change initiatives and actions to consider. You’ll see that some actions require a real focus on the hard side of change; they emphasize project management fundamentals, such as conducting action reviews. Other steps focus on the soft side; they involve communication and the restoration of trust. To address most thorny issues, you need a blend of both.
What role can you play to help get an issue-ridden project back on track? After all, you may not have the authority to intervene. That certainly was the case for me in the “project of doom” that Gary and I experienced. I wanted to take steps that just weren’t within my purview. But that didn’t mean I couldn’t do anything, and it doesn’t mean you can’t do anything either. When challenges arise, you can coach project team members and the project leader on steps they can take to make things better. You can recommend solutions the team and project sponsor can consider. You can facilitate some of the tough conversations that need to happen. And you can advise others on how to create a trusting environment in which those tough conversations can occur. It may not be your call to intervene when a project goes off the rails, but there’s still a lot you can do to help set things right.
How to Get Back on Track
You realize that your change initiative is experiencing problems. Where do you begin to fix them? What do you do when it seems like the challenges are insurmountable? Or maybe it looks like the challenges can be managed; they just haven’t yet been addressed. What can you do?
Acknowledge Something Is Wrong
You know the old saying “The first step to recovery is admitting you have a problem.” That certainly holds true for getting a change initiative back on track. The first step to addressing whatever problems your project is facing is to be honest and acknowledge that things aren’t going well.
This starts with the core project team and change management team. It’s easy to deny reality when you’re devoting so much energy to something and have high hopes that all your efforts will pay off. It’s difficult to admit that your hard work isn’t producing the kinds of results you had expected, or that despite all those late nights, your project is still behind schedule. But you and your team need to pause periodically, remind yourselves about the outcomes you’re trying to achieve, and check to see what’s working and what really isn’t. That’s why the action review process we discussed in chapter 16 is so important. By conducting frequent reviews, during which you compare actual results to what’s expected each step along the way, you can identify when minor slip-ups occur before things really go off the rails. You can intervene early before a small mistake becomes an overwhelming disaster. But even when minor issues are missed and become more significant, you and your project team need to admit to yourselves that there’s a problem.
Then you and your project team need to fight every urge to hide that reality. You need to admit to project sponsors, organizational leaders, and stakeholders that a problem exists. Perhaps you’ve already identified and have begun to implement a solution. If that’s the case, let them know that too. But be honest and widen the circle of people who are aware of the challenges you’re facing. Leaders typically don’t like surprises and don’t want to hear through the grapevine about difficulties the project is experiencing. And they may have ideas for resolving the issue that you and your project team haven’t thought of yet. The same holds true for stakeholders. Let them know about what’s working and what isn’t. They may have insight about what’s really causing the problem or have recommendations about how to address it.
That’s the point that Gary had reached in our “project of doom.” As a member of the project team, he felt that the issues we faced were so severe, they couldn’t be fixed by the project team alone. He was ready for others to know. And so, when Gary tacked up his poster, he acknowledged—in a very visible way—that our project was in trouble. He wanted the rest of the project team, organizational leaders, and our stakeholders to understand the severity of our issues.
Now, I wouldn’t recommend at all the approach that Gary took. His poster was funny but unprofessional. Gary put the team, the project, and himself at risk. But I certainly agreed with his assessment and appreciated his frustration. So I counseled Gary to remove the poster. Then, together, we had a much needed sit-down with the project leader and sponsor. We reviewed the issues we were encountering. We let them know that we were at a loss for ideas about how to fix them. And we admitted that we didn’t think the project should proceed. The sponsor and project leader thanked us for being honest with them. They acknowledged that they too had concerns. But they shared with us that we needed to proceed because of contractual obligations with the vendor. Meanwhile they were exploring a range of remedies to address the issues we faced. And so we stayed at it. Gary and I continued to struggle on the project, but at least we knew organizational leaders were aware of the issues and risks. We knew our efforts were appreciated. And we took comfort in knowing our assessment wasn’t wrong. Even senior leadership agreed.
If you are coaching project sponsors and organizational leaders, help them appreciate how difficult it can be for project team members to admit that there are issues. The team may feel demoralized. They may feel defensive or embarrassed or responsible for events that fall outside their control. Let leaders know that the project team needs their encouragement and support. The project team needs to hear that organizational leaders appreciate all their hard work. The team may even need to take a short break. Perhaps the team needs to put the project on pause for a week to recharge before moving forward again. Coach leaders so they understand the emotional stress the project team may be facing and actions they can take to help alleviate it. And coach team members too. Help them see that they may need to engage in some emotional and physical self-care. Although they have acknowledged the bad, they need to recognize that some good is happening too. Help your fellow team members put things into perspective.
Assess
After acknowledging that a problem exists, you and your team need to explore what’s really behind the issue. Why has the problem occurred? What are the root causes? And to answer these questions, you probably need more input. Ask project sponsors and organizational leaders how they view the issue from their perspective. Ask stakeholders what they think is happening. Meet with transition-monitoring-team members (see chapter 7) and get their ideas. Check in with red team members (see chapter 8) and find out what they’re seeing. Or conduct an action review and invite leaders, stakeholders, and members of the various teams to discuss what they see happening and why, and what they think should be done about it. As you engage in these conversations, explore:
Objectives. Take a look back at your project charter (see chapter 3) and the objectives and deliverables that were established for the initiative. Were they the right objectives? If you’re encountering obstacles that can’t be removed, are there other ways the same outcomes can be accomplished? Look at scope creep. In your efforts to address stakeholder needs, have you added in other deliverables that are keeping you from achieving what was originally intended?
Assumptions. Did you assume you’d receive more assistance and participation from certain stakeholders, but they haven’t gotten involved in the way you had planned? Did you assume a leader would actively endorse the project, but it turns out she’s voicing concerns? Did your team assume you’d have a certain budget, but only a portion of that funding has materialized? If those assumptions turned out to be wrong, what can be done instead?
Communication. Ask leaders, stakeholders, transition-monitoring-team members, and others about what’s working related to communication, and what isn’t. What are people confused about? Which methods of communication are working as expected, and which aren’t? Do you need to conduct more frequent status-update meetings with stakeholders? Do you need to shift the focus during these meetings to ensure that your team listens more and speaks less? Are leaders effectively fulfilling their communications responsibilities? Where is more communication needed, and how should that occur?
Training. Is your training plan (see chapter 13) helping the right employees develop the knowledge, skills, and attitudes they need to succeed in the new environment? Or are there training needs you hadn’t anticipated? What adjustments do you need to make to training content, delivery methods, and audience?
Resistance. Is someone intentionally creating the issue as a stall tactic? If so, how can you address their concerns so you can get things moving again? Check out chapter 14 for ideas.
On my project of doom, the sponsor ended up convening a series of meetings to assess why the project was so compromised and what could be done to set things right. These meetings included members of the project team, senior executives, software developers, attorneys, and sometimes our problematic vendor. Senior leaders confirmed that they were committed to our project objectives. They wanted the software the vendor had promised to deliver, and they needed that software to work. And yet, we also came to see that the vendor lacked the capacity to deliver what it had agreed to in its contract with us. It didn’t have enough staff to devote to the project, and the staff it did have lacked the required expertise. And what could we do about it? Well, the contract was pretty clear. Although the vendor was failing, it hadn’t failed enough—yet—to allow us to nullify our agreement. As we assessed the situation, organizational leaders came to realize just how big a mess we were in. But we also began to see some potential paths out.
Check In
Next, think about and discuss, as a team, what you have learned from all these conversations. What can and should be done differently that will yield a better result? And can your team actually do what’s needed? Consider whom you need support or authorization from to implement solutions. Check the project RACI matrix (see chapter 10), if your team created one. As you consider actions to address the problem, whom do you need to consult with? Whom do you need authorization from? Whom do you need to inform? And check in with your red team. Let them know the problem you’ve encountered and the solution you’re considering. Ask them to tell you why that approach might not work and what unintended consequences your proposed solution might generate. Then decide which options make sense to move forward with to address the problem.
On the project of doom, we decided to assign our own software developers to work alongside the vendor’s development team. Where the vendor didn’t have enough staff or expertise to get the work done, our own programmers completed the work. This certainly wasn’t what our company had expected to do when we signed a contract with the vendor, but it was a path forward. And it was a path our company was willing to invest resources in to bring the project to a somewhat successful conclusion.
Communicate
Let your stakeholders know about the solution your team has decided to pursue. Be clear about what happened, what was learned, what you’re doing to fix the issue, and how the new actions affect them. Be honest and as forthcoming as you can. On the project of doom, the sponsor let our project team, our executives, and certainly our in-house software development team and the vendor know why the company decided to assign supplemental resources to the project. He communicated the company’s commitment to seeing the project through to its successful conclusion. He acknowledged how frustrated—and exhausted—our team members were, and he thanked us for our continued commitment to such a problematic initiative. He admitted that leadership made a mistake when they selected the vendor. And he shared some insight about why they’d made that mistake and what they’d learned to do differently going forward. We were all still stuck working on this stinker of a project. But at least we felt like our leadership team understood the situation and were committing resources to get us through it. And we appreciated their honesty, humility, and willingness to learn.
Coach leaders to communicate their support for the project team when they talk with others about the problem and its impact on the organization. What leaders say about the issue can influence employees’ willingness to participate in future changes. Leaders should convey that they understand that mistakes and problems will happen, and that they view the situation as an opportunity for the organization to improve and grow.
I saw a CEO demonstrate this approach when a project team at his company made a series of blunders during a plant closing. The team had focused communications on employees who were directly affected by the shutdown, and these efforts had been well received. Employees understood why their work location was closing, knew the options they could pursue for continued employment, and felt cared for, supported, and respected. But the project team bungled communications with external stakeholders, which led to some embarrassing articles in the local and national press. The team worked with the local community to resolve the issues. But it didn’t stop there. In partnership with local community members, team members took a hard look at the opportunities they had missed to communicate with external stakeholders. They researched best practices they could have employed. And they compiled the lessons they’d learned into a guidebook for managing community relations during a plant shutdown that other teams within the company could access if needed in the future.
Whenever the CEO met with a group of employees across the company, he praised the project team that had managed the plant closing. He commended the team for the actions it took to repair the issue and for its efforts to help others across the organization learn from its mistakes. During one town hall meeting, an employee admitted that he was troubled and confused by the CEO’s remarks. “They made a mistake and the rest of us look really bad because of it,” the employee challenged. “Why are you rewarding them for screwing up?” The CEO smiled as he responded. “I’m not rewarding them for making a mistake. That was embarrassing. But mistakes will happen. I’m rewarding the team for what they did afterward. It would have been easier for the team just to fix the problem and move on, hoping we’d all just forget about it after some time. But they didn’t do that. Not only did they fix the problem, but they found a way to help us all learn and get better. I’m confident that, because of the guidebook they created, other teams won’t make that same mistake again. We’ll make other mistakes. But we won’t make that one. And hopefully we’ll learn from the next mistake too.”
Reassess
As your team implements the solution, pause periodically to assess the results you’re getting. Did the stakeholder who stopped showing up at meetings resume his participation, or do you need to discuss the issue with him again? What are transition-monitoring-team members saying now that you’ve committed to meeting with them more frequently? Do they feel like they have enough opportunities to provide input, or do they still need more? Does it look like your project is back on schedule since the team eliminated unnecessary distractions, or are you still falling behind? Conduct brief action review meetings with leaders, stakeholders, and members of the various teams to see what’s working now that corrective action has been taken, what still isn’t working, and what should be done next. A brief check-in conversation may do. Keep making adjustments as you learn.
On my project of doom, the sponsor convened quick check-ins every Friday morning with the project leader and project team until the initiative finally reached its conclusion. Sometimes senior executives would join our meetings. Sometimes these debriefs lasted only 20 to 30 minutes, sometimes longer, depending on the issues we discussed. We talked about the work that was supposed to be completed during the week. What had actually gotten done? Had any new issues arisen? What could we do to address them? Was the new arrangement with our underperforming vendor working? Was it holding up its end of the bargain? Were we? The project was never fun. But we did get it back on track—a different track—and we ultimately got to the end. When we were finished, we conducted lots of action reviews, examining the project and our decision making from a host of different angles. How did we end up in a partnership with this vendor anyway? What was the vendor evaluation process like? What did we miss during contracting with the vendor? What could we have done differently to get the project on a better track earlier on? What should we have done to start the project on a different track in the first place? We all survived the project of doom. And we learned a lot of lessons.
Don’t think of these actions as steps your team needs to follow in a prescribed order. Most likely you’ll find yourself bouncing back and forth as you engage in each of these actions. Your team will acknowledge the issue exists, you’ll do some assessment, you’ll widen the circle and inform others about the issue, they’ll help you diagnose some more. That’s OK. Just make sure you and your team have covered these bases as you work things through.
Addressing Some Specific Issues
Now that you have a general framework for tackling thorny issues, let’s look at how you can apply it to a few specific challenges.
Employees Are Reluctant to Support a New Change Initiative Because Past Projects Have Failed
When a project fails, there’s a double whammy. Your organization doesn’t receive the outcomes the current change initiative was intended to produce, and employees may feel reluctant to get on board with future change initiatives. Employees may feel like they worked lots of late hours and slogged through confusion, to what end? Projects like these just don’t work. Or perhaps the initiative did produce the results that were expected, but the change process was mismanaged and was just too painful for employees. They may be left feeling disoriented and disillusioned. They may doubt the competence and integrity of organizational leaders. Certainly they’re reluctant to experience the same thing all over again.
What do you do when you’re about to launch another change initiative in your organization when there is a history of failed projects? How can you encourage employees to give it another go when your organization has previously been so bad at managing change?
When change initiatives have failed or have gone badly, and there’s a need to press on with another change, it’s important to acknowledge the truth. This begins with organizational leaders as well as the project sponsor and project team for the new initiative. They need to admit to themselves that things have not gone well in the past and that they need to commit to leading differently this time. They may not have been responsible for the errors of the past. Perhaps different leaders and different project teams managed initiatives back then. Perhaps not. But they need to acknowledge that problems have occurred, so they can avoid repeating them.
Leaders also need to let employees know they’re aware that past initiatives have been challenging and unfruitful. They need to convey that they understand the toll these initiatives may have had on employees, and thank them for the patience and commitment they demonstrated in spite of these issues. Leaders need to state that they recognize that employees may feel reluctant to give their full support to another change, given what they have experienced. And they need to communicate that they have learned and are committed to doing things differently.
Of course, this assumes you know why things went badly in the past. As planning begins on the new initiative, check to see if someone conducted action reviews on the projects that failed or were otherwise mismanaged in the past. Are notes available from these discussions that your project team can review? Even if a thorough review was conducted, keep probing and diagnosing what went wrong.
Look at assumptions teams made in the past that turned out to be misguided. Did project teams assume stakeholders could commit more time to the project than they really had available? What will be done differently this time? Did they assume leaders needed only 24 hours to review and approve a decision when they actually needed more substantial time? Are you making the same mistake on the new project?
Examine how communications were handled in the past. What worked effectively, and what worked less well?
Look at training. Was it effective in the past? What needs to be handled differently this time?
Ask employees for their assessment. What did they see go wrong, and what would they have wanted instead?
Consider conducting a before action review (see Table 16-2 in chapter 16) with your project team and selected stakeholders, during which you focus discussion on obstacles and issues the team anticipates it might encounter over the course of the new initiative. What actions can be taken to prevent these obstacles from appearing again?
Assemble a red team and ask them to poke holes in your team’s plans. Ask them to critically evaluate your plan with an eye toward why your plan won’t work, especially given the traps other teams have fallen into in the past. Ask for their honest assessment. Are you doing enough to ensure the new change is really managed differently?
Let employees know what specifically will be done to ensure that the current project will be managed more effectively. And then check in regularly with employees to see if they’re noticing anything different. Ask them what looks and feels different and what looks and feels the same. Keep adjusting and rechecking with employees until they tell you their experience has improved significantly.
If you follow these guidelines, you’ll be on your way to persuading even the most change-skeptical employee that you’ve righted the ship.
The Project Sponsor Recommends Terminating the Project
I sure wished someone had pulled the plug on my project of doom. That didn’t happen. But it did happen to another initiative I was working on—a project I was leading, a project that was “my baby.” The objective of this project was to introduce sorely needed technology to our company’s succession management process. Not only had the CEO given the green light for the project, but he was serving as project sponsor. How lucky was I to have the CEO’s commitment? But now the whole deal had gone bust.
I was proud of the approach to succession management we had implemented at our company. We used the process to identify up-and-coming leaders and place them into roles that could test and stretch their leadership capabilities. But much of what we did to administer how it worked was manual, time-consuming, and unwieldy, not only for HR staff, but for leaders and line managers whom we collected information from on a regular basis. Now that was about to change. We would introduce technology that would automate the data collection and reporting processes, so we could focus even more attention on what really mattered—providing development opportunities to employees. This would be a real win for everyone!
We assembled a project team that included HR leaders, technology staff, some line managers, and me. I would co-lead the project along with the head of HR information systems, and I would also serve as change management leader for the initiative. We let employees across the company know about the automation that was planned, and they seemed to be really intrigued by what was coming. We gathered input from the CEO, other executives, managers, and HR staff to find out what would be most useful for them. We created mock-ups of how the technology would operate. We evaluated options for purchasing technology or building what we needed within the current HR information system. We reviewed plans with our sponsor, the CEO, to make sure he concurred with all of our decisions. He confirmed we were ready to go.
And then, one morning, our CEO told my project co-leader and me that our project was over—it was canceled. The company had missed some key financial targets, and projections for the foreseeable future seemed tentative. “We can’t invest in this project right now,” the CEO told us. “Other projects have been canceled too. I’m still committed to succession planning. We’re just going to have to continue to limp along without the automation. Wrap things up and let people know the project isn’t going to happen.”
I was devastated. Upset that our months of planning weren’t going to lead anywhere. Embarrassed that I had made commitments to people that I now needed to undo. I certainly didn’t look forward to telling everyone who had been so excited about our project that it wasn’t going to happen. It was a bust.
Sometimes business conditions change and a project that has already begun needs to be abandoned. Organizational priorities may have changed, or new leaders with new perspectives may have joined your company. Economic conditions may have forced your organization to cut the budget for your project. Or maybe project sponsors have changed their minds about the value your initiative will bring to your organization. What do you do if the project sponsor recommends canceling your project? What do you do when you’re in a situation like I was and you’ve just found out your project has fizzled?
Confirm the decision. Check with your project sponsor to see if they’re open to conducting an action review with the project team and key stakeholders, to get their input about terminating the project and to see if any other options make more sense. Consider assembling the red team and asking them to poke holes in the go/no-go recommendation. And check the RACI matrix to confirm who has the authority to terminate the project, and who needs to be consulted before a termination decision can be made. For my succession management project, the decision came from the CEO, so I didn’t question who had the authority to make the decision. I also understood that it was final. But that didn’t mean my work was over.
Communicate. If a decision is made to cancel the initiative, work with the sponsor to determine how best to communicate the news to organizational leaders, project team members, key stakeholders, and the rest of the organization. Be sure the communication clearly addresses why the organization originally began the project and why it now makes sense not to proceed. Publicly thank everyone who contributed to the initiative, including project team members, transition-monitoring-team and red team members, and employees who supported the change. For my succession management project, our CEO met with the entire project team to explain the decision and thank them for their efforts. And then my project co-leader and I communicated the news to others we had met with over the course of the initiative. We thanked everyone for the input and ideas they had shared with us, and we reiterated the company’s commitment to succession management. And the CEO reinforced this message in his formal and informal communications throughout the company. Although we couldn’t automate the process—at least not now—succession management was still a key priority.
Identify lessons learned. Conduct an action review with the project team and key stakeholders to reach agreement on what was learned from the project, and share these lessons learned with the rest of the organization. By being transparent with employees about why the project was started and then discontinued and what was learned, you’re conveying your organization’s willingness to admit when a change is needed and to grow from the experience. You’re also letting employees know that organizational leaders weigh their options carefully before deciding to begin an initiative and before deciding to stop it. When employees see leaders engaging in thoughtful decision making, they’re more willing to commit to change initiatives that will arise in the future.
To close out my succession management project, our team conducted an action review. During the meeting, team members shared how frustrating it was to do so much work, and to have the CEO endorse that work, only to see their efforts discarded. We commiserated, and maybe that was the best we could do. But a week later, a team member (well, a former team member) stopped by with an idea. Since participating in the action review, she just couldn’t stop thinking about our canceled project. And in mulling things over, she stumbled on some simple tweaks that we could make to our existing HR information system that could make our succession management process a bit less cumbersome. It wouldn’t really cost anything to make the changes—maybe a day of work. Was I interested? I was. I checked with our CEO, and he was game too. So although our succession management automation project was terminated, it wasn’t a total loss. We found a way to make things better—a little bit better. We learned that even when a project is terminated, some good can come out of it. There were still lessons to be learned.
Your Change Initiative Was a Success, but Now the Change Isn’t Sticking
You sigh with relief and perhaps a bit of exhaustion, as you and your project team finally—after months and months of late nights—declare the change initiative done. You’ve checked off the last action item on your project plan. Your project team has conducted its final action review. You may have even enjoyed a project wrap party to celebrate your team’s success. Employees are engaging in new behaviors that support the change. And your project is beginning to produce results. Customer survey scores are up, production costs are down, employees are working more efficiently, there’s more collaboration across two departments. It’s gratifying to see these outcomes because you, your team, and the whole organization have worked so hard. And then you notice employees beginning to stray back to the old behaviors. They aren’t following the new procedures they seemed so eager to try just a few months before. They’ve returned to the old. And old issues the change initiative was supposed to address have started to re-emerge. How do you fix this? What do you do when a change that initially looked so promising just isn’t sticking?
It can be a real challenge to admit a problem when you’ve just celebrated your success. It’s easy to ignore the fact that more work is needed after you’ve announced to everyone that your project is done. But the reality is that change is rarely ever done. Managing change isn’t simply a box to be checked off. Don’t ignore the issue or hope it will go away. Discuss it with the project leader, project sponsor, or the stakeholder who has ongoing responsibility for overseeing whatever has changed. Acknowledge that something is up that may need to be addressed, and ask for their help to diagnose why employees are slipping back into old patterns of behavior.
As you assess what’s happening, consider:
Are employees aware of what’s expected? Do employees need to be reminded about what they’re expected to do? Do they understand the rationale for these new expectations? Are frontline supervisors continuing to communicate expectations to employees? Are senior leaders continuing to talk about why changes were made and to convey their interest and support?
Are there obstacles that prevent employees from doing what’s expected? Do employees have enough time to continue engaging in the new behavior? Sometimes, organizations temporarily reduce productivity targets to provide employees with enough time to learn and begin adopting the new behaviors they’re expected to engage in. That works well until the old productivity targets are restored. Check to see if employees need to become more proficient in the new behaviors before productivity targets are increased. Or sometimes, employees discover that a new procedure is just too cumbersome. They may have been willing to try things out for a while, but now they’re finding that it’s just too challenging to sustain that extra amount of effort. Can anything be done to streamline the procedure so it presents less of an ongoing challenge to employees? Talk with employees and supervisors to find out what, if anything, makes it difficult to continue to engage in the new behavior.
Are there consequences for engaging in the new behavior? Are frontline supervisors recognizing and rewarding employees when they engage in the new behavior? Are they ignoring it? Or worse, are employees, perhaps unintentionally, somehow punished for engaging in the new behaviors? Have employees figured out that to meet the expectations that really matter, they need to ignore the change? Take a close look at the performance management process that’s in place. What needs to change to ensure it’s aligned with the change initiative?
Do employees understand how to do what’s expected? Do employees need refresher training? Have they forgotten some of the content they were trained on? Are there behaviors they never really quite mastered? Does training need to be repeated or extended in some way? How can that be done?
Check to see who has responsibility and authority to take whatever corrective action is needed. If the project team disbanded, you may need to coordinate with multiple parties who now have responsibility for day-to-day oversight of the change. Remind these individuals about the outcomes the change initiative was intended to produce and why these outcomes matter for your organization. Let them know that you need their support to address whatever is causing employees to revert back to old behaviors. And as actions are taken, help them communicate with employees about why the additional steps are required.
The Hard and Soft Side of Fixing Thorny Issues
In some ways, when you address a thorny issue that has arisen during a change initiative, you’re embarking on a mini change project. You’re exploring how to change the way you’re changing. And perhaps the flipside is true too. When your organization embarks on a change project, you’re really just trying to solve some big thorny issue. Either way, you’re using the same tools as you weave together the hard and the soft to devise a solution. You’re employing sound project management discipline to help your organization achieve the outcomes it’s striving toward. And you’re helping to build an organization where collaboration, honest communication, and trust are the norm. Whether change is happening or not, those are worthy goals to pursue.
About to Begin?
Are you facing a thorny issue on a project? Ask yourself:
• Would it help to acknowledge that things just aren’t going right? Would it help to let your project leader know about the problem? Your project sponsor? Other key stakeholders? Could they help you view the issue from a different perspective and possibly help you identify options for addressing what isn’t working?
• How can you assess why the issue is happening and actions you might take to fix it? Who can help you conduct this assessment?
• Whom do you need to check in with before proceeding with a solution?
• Whom should you communicate with about what happened, why, what you’re doing to address the problem, and how they’re affected?
• How will you reassess to make sure your solution is actually working?
Learn more. Check out:
Carucci, R. 2019. “Leading Change in a Company That’s Historically Bad at It.” Harvard Business Review, August 6.