Overcoming blockers to your project’s success
It is common for different departments or teams to have different opinions, goals, and priorities in technical projects. However, when these differences lead to active resistance to change, it can significantly impact the project’s success. In such scenarios, it is crucial to implement effective strategies for overcoming this resistance. As part of the discovery phase of any new project, I hold several interviews with stakeholders.
Pro Tip: The qualitative research industry (QRCA, GreenBook) have extensive resources for interviewing, probing, laddering, organizing, and developing insights from these sessions.
In my interviews, I have a few questions that let me know which of the five aspects of change they are signaling.
Passive Resistor will quietly oppose the change effort. They will refrain from making noise in meetings and refrain from openly challenging the change effort. They can be hard to spot because they must signal their disagreement to the team. Signals from this group include unopened emails (are you tracking open rates?), do not attend sessions, and when they do, they are silent, and requests for meetings or information tend to come in weeks rather than days.
Active Resistors tend to disagree with an aspect of the project or the entire project. They will hold back information because someone on the team didn’t expressly ask for it. Outside formal meetings, they are building a collation against the effort and looking for vectors to close the program. Since they tend to be expressive, you can use this by actively listening and seeking to understand the problems they see with the effort from their point of view. I love working with active resistors because, in my experience, they see something that the new team does not. If it was a formal review, they are great for Red-Teaming, e.g., Tell me how you envision this effort failing. Then I have a nice list to go and make sure that we have it covered or addressed.
Neutral team members can be a challenge because you frequently need more signals to support a decision one way or the other. In projects, they can shift support to the active resistor or the active supporters’ groups. You will want to keep them as informed as any other group. I have found that sometimes their neutral status is context-based, and while they are neutral on the project as a whole when it comes to areas that directly impact their work or teams, you will see them move to supporter or resistor, so it is good to know what their needs and styles are.
Passive Supporters tend to agree with the project goals but may want to avoid an active role for several reasons. These users often are great at opening doors to other departments and resources within the organization.
Active Supporters are eager for this project or change. They can see what the future can be and want to be a part of making it happen. They are in the innovators’ area in the 'diffusion of innovation' curve.
It’s essential to recognize biases’ impact and understand how they impact the success of your project. By taking these biases into account, project leaders can work to mitigate their effects and create an environment that encourages open-mindedness, collaboration, and innovation. It can lead to more productive discussions and a better outcome for the project. Let’s take a look at a few that I come across frequently.
Confirmation Bias causes people to seek information that supports their beliefs and ignore information that contradicts them. A technical project can lead to individuals or teams needing to consider new ideas or solutions that challenge their existing way of doing things. This can be particularly problematic when introducing new technologies or processes requiring significant changes to the status quo. We see this with new teams with FUD (Fear, Uncertainty, and Doubt) at the start of a new effort.
Anchoring Bias is the tendency for people to rely too heavily on the first piece of information they receive when making decisions. This can be a problem in technical projects when individuals or teams hold onto initial estimates, goals, or project timelines, even when new information becomes available that suggests these may need to be revised. This is common when the scope of a project changes, but the team needs help considering a change in timelines or budgets. I can’t tell you how many meetings I have been in where the client spends 50 minutes expanding the scope of an effort and then ends with, “this won’t change the timeline or budget, will it?”
Overconfidence Bias is people’s tendency to overestimate their abilities, skills, and knowledge. In technical projects, this can lead to individuals or teams making unrealistic estimates of what they can achieve, which can cause delays and setbacks when they cannot meet these expectations. This one rears its head when a technical team is trying to estimate the impact of a change in real-time. My strategy for dealing with this that has worked for me is to hold off committing to change estimates at the moment and then go to a trusted 3rd party (in my technical work, this is often an architect or developer that is NOT on the project and asking them to estimate this change, then I take that back to the project team and ask them why this estimate is right or wrong. This activity tends to get technical team members rethinking.) We then document the thinking and get back to the client.
Sunk Cost Fallacy and Escalation of Commitment. The sunk cost fallacy is the tendency for people to persist in a project or investment because they have already invested a significant amount of time, money, or resources into it. In technical projects, this can lead to individuals or teams continuing to pursue a particular course of action even when it is clear that it will not be successful. It is related to Escalation of commitment: This is when people continue to invest in a failing course of action despite negative feedback or evidence. For example, some departments/teams may block a project because they have already invested a lot of time, money, or resources in their current way of doing things and are reluctant to admit failure or switch to a new approach. I see this often when a department has tried other solutions or consultants and brings that historical baggage to the new project. This dynamic in my work is commonly called ‘technical debt,’ and while people know it and recognize it, many projects do not take this into account.
Loss Aversion is the tendency for people to place a higher value on avoiding losses than on acquiring equivalent gains. In technical projects, this can lead to individuals or teams being overly risk-averse, slowing progress and limiting innovation. We always see this when we are moving new clients to the cloud. There are many benefits for the users, but in the feedback and Q&A sessions, the focus is on what is being lost from the ‘way we do things today.’ A high percentage of the knowledge articles and FAQs we create communicate what is being maintained through the change, not to trigger loss aversion. This bias is often already activated for the users we would classify as active or passive resistors.
Technical projects have their fair share of challenges and roadblocks, and understanding the underlying behavioral biases can help leaders and teams overcome these obstacles. We can create a more productive and successful project environment by being aware of these biases and taking steps to mitigate their effects. It takes empathy and effort, but it is time well spent.
Three strategies for overcoming a department that is actively resisting change:
Communicate the Benefits. One of the most effective ways to overcome resistance to change is clearly communicating the proposed change's benefits. This can include highlighting the positive impact that the change will have on the department, the company, and the customers. By focusing on the benefits, leaders can help individuals understand why the change is necessary and encourage them to support it. In my experience, I have yet to be on a project that over-communicated. When we ask users, it is common for them to want more information, not less. In a C-level meeting, one great user said, "we can deal with difficulty, but not uncertainty.”
Involve Stakeholders in the Process. An effective strategy for overcoming resistance to change is to involve stakeholders in the process. By involving individuals from the department in the decision-making process, leaders can help them feel more invested in the outcome and more likely to support the change. This can also help leaders understand the department's concerns and address them in a way that is more likely to be well-received. To clarify, when I say “involve stakeholders,” I mean to have them speak, write, and video. This leverages the biases of the Ikea Effect (people value more things they have a role in creating) and the Halo Effect (the tendency for an impression created in one area to influence opinion in another area).
Lead by Example. Leaders can help build trust and encourage others to follow their lead by demonstrating their commitment to the change and how it can be successfully implemented. This can also demonstrate the benefits of the change and encourage others to support it, which is another use for the Halo Effect. Finally, leaders can overcome resistance to change by leading by example.
Overcoming resistance to change can be a significant challenge in technical projects. However, by communicating the benefits of the change, involving stakeholders in the process, and leading by example, leaders can successfully overcome this resistance and achieve a positive outcome for the project. By implementing these strategies, leaders can create a more collaborative and supportive environment, leading to a more successful project outcome.
Sources used:
