They came, they installed, they fled. The result was two weeks of downtime for the department.
Lessons learned during the rollout from hell
I don’t think it’s intuitively obvious to IT people that superior customer service can improve your project. Customer service means providing more, which means additional time and money and, since all projects are late and over budget, people do the minimum, thinking they are doing someone a favour.
For example, as a project manager for a large PC and associated infrastructure rollout, I became fearful that my project was going to cripple the organization – one department at a time.
My job is to deliver new PCs, standard software, intranet and Internet connections. Sounds like I’m Santa Claus in May, especially when the individual department budgets have not been charged for the cost. So why worry? I didn’t until my other sibling told me a story. He was the victim of a hit-and-run rollout. They came, they installed, they fled. The result was two weeks of downtime for the department while the resident technical wizards put their business back together.
At the time I was told that story, I was mere weeks away from unleashing the same chaos on my own client.
So I returned to the office and changed the rules for the rollout.
Rule 1: The rollout teams shall not leave a department until it is working at least as well as they found it. “Working” is a term defined by the customer.
Rule 2: The client shall provide a business contact and a technical representative for the team during the rollout.
The business contact is responsible for finding passwords, unlocking doors, warning the users, preparing them to do data backups, kicking them off the PCs, etc. The technical contact is normally the local LAN administrator who can help set up IDs and install custom software.
Rule 3: Go fast.
This puts some interesting pressure on the team leaders for the rollout. They think they can’t go fast if they have to worry about all this “extra stuff.” The notion to communicate to the teams is that this isn’t extra work – it’s effort normally done after they’ve left, and usually done badly.
Since my project is going to suck every last erg of energy out of the organization, there really isn’t the luxury of going back to fix messes – the staff are all assigned to other projects.
Rules 1, 2 and 3 require Rule 4 to work.
Rule 4: The project manager must develop Kissenger-like diplomacy skills.
Let’s face it, IT people and people in the actual working environments are like different species in their outlook. In order to integrate these diverse people the project manager must monitor the health of all these insta-teams. The core team may remain more-or-less the same, but getting it through to the clients that their staff members become part of the rollout is a little alien. They are used to having rollouts done to them, not done by them. In addition with the “go fast but do it perfectly” attitude, tempers will rise and conflict will ensue.
Pick up a newspaper and you’ll see clear evidence that humans regularly don’t like each other. Put them in a high-pressure situation and the risk of pointless, time-wasting conflict rises. The project manager must establish the following interpersonal ground rules for team members and clients alike:
Never do anything to undermine the self-esteem of anyone.
Complain effectively by pointing out specific problems with the rollout and suggesting ideas for change.
Complete the project without injuring anyone to avoid costly legal bills.
Don’t panic until the project manager gives the word.
Ford is a Vancouver-based systems consultant. He can be reached at quokka@portal.ca.
