Early last year, I was managing my first project for Dragonfly Editorial when an ill-timed technology rollout almost left us flat.
There was plenty of ramp-up involved in the assignment: initiation on Google Calendar; orienting myself with the contact sheet of our freelance editors; and using an Excel spreadsheet to log the receipt, distribution, and return of all project files. The project had been carefully set up by my mentors to enable a smooth transition while they were both traveling for business.
But even the best-laid plans can go awry.
Shortly before the project began, our client requested that all Dragonfly staff begin using its secure file transfer system—effective immediately. For my project, estimated to be 100 pages a day for 7 days, we had lined up a number of proposal editors to work at various times. Before files began to roll in, we needed to have these editors connected to the system, assigned new email addresses, and able to receive and send messages and attachments.
As with most technology rollouts, there were a few hiccups.
Technology rollout or technology steamroller?
First, we worked with the client’s system administrator for several hours before we were able to get our editors connected and the editing underway. Then, we realized there were issues with dropped file transfers—attachments that had been sent did not always arrive.
Sam, Dragonfly’s president, quickly suggested that we return to our normal email-based method, putting aside the technology rollout for this project. The client, however, wasn’t quite ready to throw in the towel. And I, too, thought that we’d come far enough that we should persevere, if possible.
One full day into the project, the rollout had consumed time and patience and was only marginally effective in its technical intent—we were using the system but still having to reroute some dropped files via our old method. Then the next day, we hit a big wall: memory. The client’s file transfer system had a 110Mb quota for each user. As the project manager, I was receiving and sending files averaging 5Mb throughout the day—and just a day and a half in, I’d almost maxed out my quota.
Bowled over
The system administrator suggested that I offload emails from their system to my local machine for storage. It seemed redundant, but I wanted to give the system a chance to work. I spent hours moving and deleting the files in small increments because of my limited quota.
When I’d moved the Inbox files (but not yet the Sent files), I recalculated my quota usage, which simultaneously emptied the trash on the client system. To my dismay, my quota doubled, and the system automatically disabled my account. On the bright side, I’d discovered part of the problem: the trash was not releasing my deleted files, and it was counting against my quota.
The new file transfer system was down for the count; the towel was finally thrown. We returned to our tried-and-true email system for the duration of the project— and were able to edit double the original estimate of work for the client in the remaining time. My initiation into project management was over, and the project was a success despite the system failure.
Keeping your footing
In retrospect, my advice to anyone facing a technology rollout is this:

1. Never roll a new system out for the first time on a live project.
2. Instead, assess the needs of the system and all of its users beforehand.
3. Install the technology and give everyone a chance to play with it and develop a level of comfort using it.
4. Then do a test run—better yet, multiple test runs—to iron out the inevitable kinks.
5. Finally, roll out the system on a small project with a flexible deadline, rather than a mega-project involving multiple staff and loads of work that must be done in a short timeframe. That way, any hitches can be ironed out in a low-stress environment—rather than in the heat of a panicked production.

If you follow these steps, you can roll with the punches on your next rollout—rather than being bowled over.