6 Critical Steps to Build Team Unity When Planning a Technology Transformation 

p>In our line of work, we perform quite a few discovery and evaluation projects. The most typical theme we see is the sad fact that frequently, team unity is the most significant gap that needs to be bridged, more so than almost any technology challenge. Regardless of whether a company has five employees or 2500, there are often individuals and teams that simply do not see eye-to-eye on nearly anything. Our job as a consultant, in those cases, is to bring about some level of unity to enable them not only to define a common vision but ultimately to see it through the development and implementation phases to fruition.

In this post, we want to detail some approaches that have worked in the past, which can hopefully work in your situation, as well.

Step One: Agree on The Issues

I believe the primary reason that projects stall in the conception stage is frequently that people can’t agree on what challenges they are facing. Ideally, this would be a natural step. Almost everyone always takes the position that something can be improved. First off, people tend to see the brighter side of things, ala “The grass is always greener,” therefore making possible improvements something that is appealing. Secondly, it’s risky in a collaborative environment to say you are happy with how things are unless the current situation is entirely perfect… Which it never is. And on that note, finally, even for those that are happy with the current state, there are often some items that could still benefit from optimization that leads them to invest time and effort in the process. So, gathering motivations to find improvements should be relatively easy to do.

To proceed past this step, however, takes diplomacy. The process of identifying issues need not lead to an instant transition to a discussion of solutions. Prematurely discussing specific solutions is sure to bring about an argument, in that it gets too close to home for individual participants. An early discussion of a software migration can be downright terrifying in the early stages of a project, and as such, should be avoided.

What can, however, be a productive discussion is the idea of a future state and what it looks like. Those conversations are valuable and productive. If you have identified issues, then work to identify ideal future scenarios that are not specific to any one solution, platform, or technological approach, but rather define a state that is ideal for all participants. Hypotheticals tend to be relatively easy to agree on, and early agreement is the fuel that will keep this process moving.

Step Two: Agree on a Plan

This sounds simple, but you’d be amazed how many clients and situations we are brought into in which it took years just to get through the first step. It’s more common than not to hear that the hardest step is coming to a simple consensus on how to start. This stage is essential because without having a forward-looking plan in place and agreement on said plan, your project will stall forever. I believe any plan requires two components to be successful at this stage.

First, you need to assign a small group of internal stakeholders. If your initiative affects 40 people, broken into five groups, then each group must be represented by a single participant in this stakeholder team. As the number of teams and their sizes get smaller, the stakeholder team should shrink accordingly.

Second, assign a project manager. Ideally, this person has skill in this area and is impartial. No project can run with multiple managers, so it’s important that a single person can work to organize and manage the efforts. This doesn't require making said individual a sole decision-maker but instead assigning them to serve as the organizer and manager of the initiative.

With this work done and the proper structure in place, you can now move on to organizing the effort to find the right solution to your underlying challenges. From here on out, we will present this post as if you are the project manager or primary stakeholder in this initiative. Because, you probably are, or are at least heavily invested in the results.

Step Three: Understand the Participants

In our experience, each team member typically has two factors that position their thinking and actions. First, employees usually have a high level of fear when undertaking projects. Can you blame them? If your workplace has enough of an issue that you are reading this post, then clearly, the fear element is present. We routinely deal with both employees and company founders/owners/executives, and I can say without any hesitation that employees are always more risk-averse than management or ownership. Your job, as a person who wants to see this project succeed, is to dig in and understand what those fears are.

When we are doing a discovery engagement and the environment is somewhat challenging, we work hard to determine what each team member’s risk tolerance is, and why. Understanding someone’s aversion to risk helps us craft strategies to set them at ease.

Secondly, each team member will typically be concerned with how a change could affect their jobs individually. This can be a serious concern, such as how a technology platform shift will change their ability to meet key performance indicators. Or, it could be less defined, such as when a new toolset may transform their workflows that they are not open to changing. It isn’t unusual for team members to eschew team-wide or company-wide initiatives because their job may be subject to uncertainty and change. Uncertainty is the easiest and quickest way to lose the support of individuals throughout this process.

These are both sensitive areas that need your attention, concern, and careful approach. And, there are sometimes other factors at play. Your role as a project manager is to understand these objections, understand underlying emotions or motivations, and use those findings to your advantage.

Step Four: Engage with Fairness

The best way to mitigate the risk of internal dissatisfaction with the process is to focus on being a fair arbiter throughout the project’s phases. Sometimes this is hard, and in our next step, we’ll talk about how bringing in an outsider may be the best option for garnering consensus. However, as the primary stakeholder, you must work to engage with participants in a way that makes them feel heard and reinforces their importance within the company and the transformation you are seeking to make.

The best route to fairness is openness and being as nonpartisan as you can in your approach. Depending on your company or team makeup, that could be easy or difficult. But it’s an essential step. In many ways, this is common sense – if you are the type of person that has a high level of emotional intelligence or an empathic response to other individuals – you will do fine. If you cannot quickly adapt to understand how others are thinking, or step into their shoes, then the role of managing this project may not be right for you. Indeed, your purpose is part organizer, part planner, and part therapist. All of these elements must work in tandem to ensure success and minimal breakdowns along the way.

Step Five: Get Help

Finally, with an understanding of where you want to go, a team in place, and comprehension of the motivations (and fears) of your participants, you are ready to get the project moving. To figure out how you can implement the changes you identified, you have to dig deeper into the current dynamics of the solution in place and work to define and architect a methodology that will implement a solution to fix the challenges you identified.

Unfortunately, this is not an easy step. At this phase, you are probably looking at many different possible solutions. There may be hundreds of software vendors and integrations, not to mention the possibility of building a custom solution. Unless you are highly niched, have done this before, or know someone who has, you find yourself in a very confusing scenario with high stakes.

The overwhelming majority of companies should seek expert advice at this point. This advice must guide you through understanding every component of your current situation, document the desired future state, and from there, identify the tools required to take you there. Or, in the case of a custom software solution, architect how the solution will work.

We’ve written many times in this blog about the value of a discovery process to define your project. This is where such a phase is essential. As such, finding someone who can come in and assist will be beneficial. Such a person must bring two critical components to your process. First, they should be impartial. In this sense, you need to be somewhat careful in bringing in the consultant, in that they shouldn’t just be neutral to your company but also be impartial to the possible solutions that they recommend. All too often, software vendors build complicated partner programs with agencies hoping they will shuffle business their way. Avoid these agencies, as they typically come with a predetermined agenda.

Secondly, a consultant should also bring with them the depth of experience you need to succeed. Preferably, the consultant isn’t just an evaluator but also an implementor (or at least has been through several similar implementation projects). Consultants who help you navigate feature matrices of vendors rarely stick around long enough to know the impacts of their decisions post-procurement. Implementors are folks who are in the weeds and can tell you from experience where future risk factors exist.

I often get asked, should you look for a software package first and then find a way to implement or find an implementor and then narrow down to a package or solution. Honestly, the best thing you can do is find that impartial agent who knows how to implement multiple solutions. This way, you won’t be caught in a tight spot with someone who either doesn’t know how to implement a technology stack or only knows how to work with a single platform. Neither scenario is risk-mitigating for you.

Step Six: GET STARTED!

I find that way too many companies get stuck in planning and pontificating mode. I beg you: just get started and produce some quick wins that can build confidence and momentum. Every discovery or vendor selection process is different. Once you have a consultant who can help, they will work with you to adapt to their process, which will almost always include some work that will be similar to the work you already completed. The consultant will need to conduct interviews of the primary team, understand the structure of the company, and perform a current situation analysis. This process can be time-consuming and requires coordination between all of the parties. However, the process must proceed in an organized fashion without roadblocks.

I find that the most successful discovery projects are when there is already some level of internal consensus in place. It allows us to enter the environment, conduct our situation analysis, identify an ideal future state which is feasible from a technology perspective, and then recommend solutions. There is overlap with the work you should have already done, but the outside perspective will help clarify any areas of uncertainty or doubt in the project. In many ways, a successful discovery or vendor selection process starts with your work organizing before bringing in professional assistance, which makes each step above even more important.

How the Story Ends

The ideal future state is your goal, and the discovery process is designed to craft a map to get you there. Developing a solid plan of attack with all team members aligned is a difficult task, but careful planning, some basic tricks of the psychology trade, and finding the right help to guide you will lead to successful outcomes and minimize your risk during implementation.