Ask any tech professional, and they'll surely tell you a system migration is, at best, a challenge. But add poor communication and an inept project manager to the task, and you'll soon find yourself engulfed in chaos.
A couple of years ago, our company was bought out by a large global giant. The deal closed, and the layoffs and reorganization began. In the midst of all this, the mammoth task of merging the two firms' IT infrastructures was led by a team from the new company under the management of "John."
[ Also on InfoWorld: Paul Venezia explains how to move a data center without having a heart attack. | Follow InfoWorld's Off the Record on Twitter for tech's war stories, career takes, and off-the-wall news. | Subscribe to the Off the Record newsletter for your weekly dose of workplace shenanigans. ]
I'd been proud to work at our old company. We'd maintained high standards with IT best practices, planned extensively for IT projects before implementing changes in phases to make sure nothing broke, and valued open communication between departments. In contrast, the new company was a disorganized hodgepodge of several acquired enterprises Band-Aided together like Frankenstein, had an attitude toward IT projects of "just throw it out there to see what happens," and didn't communicate between groups -- they were more siloed than a Midwest corn farm.
And like hot and cold air masses clashing over Oklahoma, destruction was brewing.
Before the storm: Preparing to migrate
John's team decided we should start the migration with the old company's corporate headquarters. The lack of planning was alarming, but John assured us all would be well; he and his team had done this dozens of times before.
The big project for IT support was to get users' accounts, mailboxes, and PCs onto the new company's domain. The migration team had used a "successful" procedure for the last several acquisitions: a third-party tool to automatically migrate all three items at once. We were to do this for everyone in the building, and our new manager told us we'd do this the night of Oct. 24. Of course, it was critical that both their user account and PC be migrated at the same time or they wouldn't be able to log in.
There was more: Oct. 24 loomed large for other teams within the company. For example, various silos had been tasked with migrating by Oct. 24 and 25. John's team also oversaw these departments' migration assignment, but failed miserably in scheduling and communicating these goals. And completely separate from the rest of IT, the network team had been working on its own merger project. To adopt the security practices of the new company, all network jacks that had not been used in six months were to be deactivated at midnight on -- wait for it -- Oct. 24.
As if that weren't enough, around the time the merger closed, we were in the middle of a rollout of new PCs to everyone in the building. Once the shakeup happened, the inventory backlog dropped down the list of priorities; about half the users had the wrong PC listed as their primary unit. We should double-check everything before the migration, we told John. His reply: "Nah -- it will be OK."
Last but not least, because workers at the new company's corporate headquarters were crammed in the building like sardines, a couple of departments would be moved to our already tight office. The Facilities department was to reconfigure hundreds of rooms. They did not communicate the new assignments, so none of this information was updated in Active Directory. We knew a move was happening but weren't told when.