When implementing software tools such as Jira and/or Confluence within an organization, the role of people in accepting this change within their work culture is often underestimated. It’s not only about the technical part. Therefore, we’ll explain the different phases to change management proposed by John Kotter in 1995 in “Leading Change,” still in force, and adapted to our day-to-day life, specifically when introducing new enterprise software.
If we get to classify the situations our customers face in their day-to-day when implementing Atlassian software tools, in most cases, the large majority of people who should use them, reject them because there are shortcomings that haven’t been considered beforehand the implementation. The cases vary, ranging from the use of office applications such as Excel and Outlook to ticketing tools such as OTRS, Zendesk, ServiceNow, and even unsupported versions of Jira.
Our first approach to deal with this situation, in order to achieve successful change management is to analyze it from a higher point of view to determine the root causes. Once that’s identified, we approach the situation from two viewpoints:
- Technical: We understand the specific causes and procedures that have led the customer to decide to change their current tools for Atlassian products, allowing us to propose what products could potentially solve the problems and needs.
- Cultural: Users’ perception of current software tools is usually one of the most common causes. People tend to perceive them as useless; therefore, they seek other solutions outside these tools (which initially were imposed without further consideration) and disrupt the system, which brings us back to the technical aspect.
Whenever an enterprise software tool (management or ticketing) is changed, which is a significant change, it’s very likely to generate resistance to change among organization users. At DEISER, we know that proposing a technical solution is necessary; however, this proposal could be insignificant if it’s a cultural problem.
What should an organization consider when changing its software?
John Kotter, professor emeritus of Harvard University, twenty-one years ago, published a book called “Leading Change” there, Kotter presented eight phases to a methodology that helps to change. This process applies to different situations: for personal and organizational change.
In the case, an organization is considering changing its software toolset, and it’s expecting those to be accepted within the company culture, we propose to follow this series of steps designed to be focused from the company’s cultural point of view:
1. Create a sense of urgency
Getting people out of their comfort zone is one of the first steps to take during the process. This will allow people to understand the need for change, and it’s beneficial both individually and organizationally. Some keys to creating this sense of urgency include:
- Before formulating the need, it’s necessary to discuss the current problems with the entire organization and gather all opinions.
- Address all the concerns of the team.
- Making the problem visible to the organization.
- Create the need.
Spend time enough time on this step. This point is critical, and it’s necessary to have the entire organization on board.
2. Create a team or alliances
Identify team leaders. Involve them as part of the change to create a common front; this is a valuable strategy, especially if each of these people belongs to different teams; that way, you’ll have change agents in different places throughout the whole company. This team of people will be driven by a sense of urgency and will help convince the rest of the organization about the need to change. This team should, among other things:
- Analyze risks and challenges related to this change.
- Have regular performance measures available.
- Assign roles and responsibilities to these change leaders.
3. Create a vision for the change
Change can be challenging to understand, especially for less involved teams. It’s necessary to create an easy-to-understand vision that summarizes the main objective. By making the vision more tangible and straightforward, it will be motivating.
These first three steps are relevant functions that, usually, the team of consultants should perform during the pre-sales and execution phases of a software tools change project; In this particular step should cover the following:
- Before introducing the need, it’s necessary to discuss the problems with the whole team and gather every opinion.
- Address all of the concerns of the team.
- Make the organization aware of the problem.
- Create the need.
4. Communicate the vision of change
Once the vision is defined, it must be shared with the organization. At this point, it’s common to find resistance among the different teams.
For change to be successful, it’s essential to detect what generates that resistance to the proposed change and create channels of conversation to explain the reason for the change through the established vision. To make communication effective, consider these factors:
- Establish a mechanism to receive feedback based on people’s concerns and doubts.
- Ensure the entire organization is aware of the motives for the change and has access to the vision; find a way to make them part of the change.
- Communicate constant, straightforward, and simple.
5. Empower the team and eliminate the barriers
During the first four phases, the team will be detecting hindrances that could potentially slow down the change. It’s necessary to identify those as soon as possible and neutralize them. The actions recommended at this point are:
- Analyze the obstacles from the worker’s perspective.
- Clearly understand the obstacles and break them down for better analysis.
- Provide proper training to empower individuals of different teams.
- Ensure there’re channels to communicate about possible hindrances.
- Convince people to collaborate in implementing the change actively
6. Define short-term objectives
Implementing changes is a long-term goal, and it can demotivate the team if they don’t have short-term objectives. It’s positive to define them for shorter time frames. It will help achieve them easier, providing a sense that the vision of change is implemented step by step.
Defining short-term objectives implies less pressure. When planning the implementation of these “bits of change,” the prioritization of the initiatives must also be considered. The failure to meet an objective at an early stage of change can lead to demotivation.
