Chapter 4: A holistic approach to organizational changes

Our IT change management framework has helped us execute numerous IT changes over the decades. However, the sustainability of a framework is put to a different test when it involves changes that include the entire organization and require a new level of implementation. Though we mirror the IT framework here too, it needs a modified approach.

We categorize changes by nature into three major types: organizational, technical, and procedural. These changes, though they follow our general approach, need new reinforcements in terms of awareness, preparedness, education, and implementation. This chapter is dedicated to such changes that reinforce the sustainability of our change management model.

Scenario 6: Working with the entire organization

Organizational changes present new types of challenges, especially in planning and implementation. Our general change management approach needs a slight tweak if we're to get a hold of organizational changes:

It's simply a matter of being able to run as many iterations as possible by planning better each time, until the change is successful.

The best example is when we shifted from one office to another much bigger one.

We conceived the idea with the entire top management team on board, and approved by the CXOs, and those people were the CAB by default. And each member took the onus of overseeing the entire process under them.

The CEO: He made important decisions, from selecting a new building to making policy changes pertaining to the new work space.

The vice president of operations: He took charge of how the entire project was about to commence, including the arrangements for parking, the kitchen, dining, and movement within the buildings.

The head of the Security, Privacy, and Audit (SPA) team: From the security available in these buildings to the legal aspects, they were in charge.

The head of IT: Hundreds of assets had to be moved and new network arrangements made, so he had one of the most complicated projects at hand.

The primary plan involved setting the stage for our teams to start moving in.

The first iteration of our implementation needed just one team to move in. Once we successfully moved one team of a normal size, we would fix the little issues that popped up and move the bigger teams with more clarity and control.

So, all we had to do in our primary planning was set up the movement of one team. Here's a shortened version of the plan for your understanding.

Responsibilities	Execution
Review the building plan and analyze space, electrical, HVAC, and safety requirements.	The Administration team, Physical Security team, consulting engineers, and project management teams carried out implementation of safety features, CCTVs, display screens, electrical control rooms, etc.
Review the commercial property license and get the required permissions from the local authority.	The Legal team and the Administration team consulted with local authorities and sorted out minor hindrances.
Analyze requirements for the move.	We planned how many seating locations we needed on how many floors, how much furniture could be moved, and how much we needed to purchase.
Communicate with stakeholders.	We had to inform many parties about this change. The manager of the current building, and our local vendors, including affiliates and suppliers—all needed to know about the new address.
Brief the head of IT about the primary plan and the first phase of the move.	We developed an accurate list of those who were moving first, their locations, their assets, and how they were going to relocate.
Set up the IT infrastructure.	We purchased new servers for backups, antivirus, Active Directory, DNS, desktop management, etc. We set up network infrastructure with routers, a WAN, and an ISP. We mostly purchased new servers, but we had to move some of the old servers (like testing servers) from our previous location. The IT team worked with the Administration team to carry out the move. We created access points for Wi-Fi, installed a wired network, and added phones in workstations.
Set up workstations.	The Administration team set up one printer per floor. The team ensured proper electrical connections were given to all workstations and that the ports were functional.

The implementation of the first iteration involved a few of our teams moving to the new building. The objective of the planning phase was to ensure those who moved had minimal work to do—they must move in and simply start working. We moved their IT assets and informed them of their work locations. We also ensured physical security was tight, and we provided access control to each team member using ID cards.

Now all they had to do was move, and they did. That's when we encountered some practical difficulties of moving in:

Some employees could not find their way to their new workstations.
They faced problems connecting to Active Directory.
Some faced connection problems with the network, their phones, etc.
A few of them were yet to receive their assets from the previous location. While that was true in some cases, other times employees did not know whether they received their assets or not. Their assets were labeled with their employee numbers and stored in a safe house, and the Administration team was yet to unbox them and get the assets to their proper locations.
Employees’ communication devices had different configurations that suited the previous location. We had to update them to suit the new location.

These are just a few of the difficulties that the first few teams faced. This paved the way to our secondary plan. We provided updated instructions through our company's social forum and emailed the employees a procedure on how to find their work locations, how to connect to the network themselves, and other details they needed. Our implementation of further iterations involved all the remaining teams using our updated procedure as they moved in. It was now a matter of repeating this process until all our teams moved in comfortably.

This experience helped us refine our process for organizational changes. We are now in the process of creating small hub offices in rural areas, and this procedure is helping us set up those offices quicker.

Scenario 7: Working with the smaller organizational changes

The technical arena

Technical and procedural changes are some of the crucial games that we need to win to ensure sustainability. As an enterprise SaaS company, the technical, code-level changes we introduce every day into our products are of paramount importance.

The approach is similar to that of organizational changes, but it needs to be tweaked even more:

Workflow of smaller organizational changes

Product teams and managers together conceive and evaluate the need for a change in the product by gathering requirements from the market, specifically feedback from our customers and analysis of other players in the market. This translates to a change in code, and the manager assigns a software engineer to it.

Once the engineer develops the code, it goes through two rounds of checks:

1) Primary checks from the Configuration Management (CM) and Quality Assurance (QA) teams to assess the accuracy and effectiveness of the code. The engineer then performs these corrections and submits the code again.

2) Secondary checks happen at the SPA team's level. For more information on the SPA team and its role, you can refer to this section in our previous e-book.

It is then a matter of repeating this process until the code is implemented properly. Though this process is a simple one, there are a few reasons why we're able to win at these small changes regularly.

The winning factors

One place for all: This factor mirrors what we do with our IT change management. We have a single console where we raise, develop, evaluate, and close all code-level changes. The manager has visibility to intervene if necessary, and the engineer has visibility about the feedback from the manager and other teams involved.

This becomes a winning factor as it reduces confusion and helps us track all activity about a change in code.

Semi-automated checks: The CM team uses our in-house tool to automatically perform empty, static variable, and localization checks. The QA team then tests the code to see if it satisfies the desired functionalities.

We use our in-house tool known as Hacksaw to perform security checks. The SPA team has a repository of all known vulnerabilities and checks, and this tool implements the team’s knowledge. It generates a report containing security misconfigurations, bugs, and vulnerabilities for the engineer to fix. The SPA team also manually reviews known vulnerabilities for the third parties used, explores the means to exploit the vulnerability using hacking attempts, triages the security incidents, and reviews the fixes.

These are a mix of automated and manual checks that ensure code changes are of the highest quality. It also saves time and enables more iterations before deployment.

Effective oversight by managers and the SPA team: This plays a crucial role in speeding up the process. When engineers log their change requests, they fill out checklists to save time and help the managers understand the change better. Also, managers and the SPA team have more visibility throughout the change to intervene and course-correct if needed.

The procedures and the big picture

With thousands of employees spread across multiple locations around the world, how we handle procedural changes becomes important to how sustainable our change management model is. In fact, it gives us the overall picture of how at ease we are while performing these changes. Beyond a framework, this involves our values as a company. Let's see how our values help us handle these changes.

Act first, act fast

Most procedural changes have a single purpose: to simplify the life of our employees. With that in mind, the focus is to empower the administrators enough so they have the freedom to try out any solution that works.

One of the best examples is when we changed our means of registering complaints. We placed QR codes at the various spots we received complaints, and included simple instructions on a poster nearby. What used to happen across channels is now done using a simple scan of a QR code. We executed the change on one of the floors first and tested it out for a few days. When the complaints started flowing into our service desk from that floor, we knew it worked. We scaled it to all floors in all buildings.

Likewise, there are multiple procedural changes every day, like changing the coffee machine, regulating the parking lots, or changing access to buildings. These changes all need the manager's ad hoc decision-making skills. We let managers act first and act fast, test out a solution, and replicate it.

We just have a simple checklist of basic safety measures, and we let them do the work in their own way. We ensure their change implementation process is sound with the help of regular internal review by our SPA team as well as ISO audits.

Communicate and coordinate

Communicating organization-wide procedural changes saves us a great deal of confusion. We have designated who communicates certain type of changes. Changes that affect employees are communicated through the following channels:

Our internal forum is Zoho Connect, where employees receive frequent updates on all organization-wide changes.
We use chat channels, creating multiple groups for various types of activities, and designate people from the operations team to communicate in these channels.
If the change affects every employee, we send an email to everyone.

We carry out effective communication by coordinating between various operations teams. Let's take the example of how we handled asset management during the beginning of the nationwide lockdowns in 2020. As most of our employees started working from home, instant repair of their laptops wasn't an option anymore. They had to visit our office, follow safety protocols, and submit their laptops. We still ensured the process was straightforward—they just arrived, got their assets, signed a slip, and left.

However, it required massive coordination behind the screens. We stored the repaired laptops and the ones ready for replacement in a separate warehouse close to the entrance, which was well-sanitized. We executed an approval mechanism where one of our technicians generated a code and emailed it to the employee before they could come to the office and hand over their damaged device. We repeated the same process when they came to collect their laptops. All this was automated with a single click, and the mechanism was coordinated well with the Physical Security team at the warehouse, who was also in the loop and would receive the same code the employee received.

We also created a channel for work-from-home coordination between employees and sysadmins. This channel promoted human interaction during remote work and helped solve simple change requests without the burden of raising multiple tickets.

Technical changes can go unnoticed, which is why they need an even more robust process. Focus on semi-automating the testing process, giving space for multiple iterations and accurate implementation.
How you execute organizational and procedural changes depends on the values you hold as a company. It's practical to employ experienced administrators as managers while giving them freedom to experiment with solutions. However, ensure you have effective oversight through regular internal audits of the changes they execute.