Project Rescue: So Close and Yet So Far
Our CIO talked a good game with his team. Now, halfway up the mountain, are they on course to summit? Or did they lose their way?
This is the third installment in a four-part series that follows the exploits of Gene, a well-established CIO of a sizable IT organization at a top-100 university. Gene has been working with his team to regain the trust of the campus through Project Rescue, a 30-day turnaround plan focused on demonstrating IT’s value. Project Rescue has two primary objectives: Implement a more transparent planning and governance process, and deliver a series of quick wins around some visible projects with high customer value. Let’s see how far Gene and his team have progressed. |
On a Monday morning, two weeks into Project Rescue, Gene sat down to review the weekly status reports on the initiatives that his team had agreed to implement within 30 days. As he read, he felt his heart beat faster, and it wasn’t the second cup of coffee causing his blood pressure to rise.
One project--help desk support for tablet users to access university applications--had a green light for on-time delivery.
The rest were in condition yellow (the project would finish late, with a slight chance of bringing it in on time) or red (the project would definitely finish late and over budget). Each project was suffering for different reasons:
- Mobile (help desk support for mobile phone configuration to connect to the university e-mail system): The support team was struggling to document the configuration steps for the 20 most popular phones.
- Wireless (100 percent wireless coverage in the student center and library): Network engineers were having problems tuning the access points so that they would not interfere with each other in the library.
- Collaboration (selection of a cloud provider for collaboration spaces): The project team was at a stalemate over which of the three hosted-services finalists to select.
- Desktop videoconferencing: The favored solution presented a security and firewall challenge. The support, networking, and security teams disagreed on how to move forward.
Gene reached for his aspirin. He felt as if he were looking at the work of Dilbert. Could this really be his team? How could they be so close, yet so far off track?
Fear of Failure
Back when Project Rescue was launched (which now seemed like ages ago), Gene had introduced a new concept to his team: Think like owners of a business. People who own a business are willing to take risks. Equally important, they are willing to ask for the help they need to manage those risks.
Employees, on the other hand, can be risk averse. This may be particularly true for IT people, who can wrap themselves in the safety of their code, afraid of making a "wrong" decision. Asking for help can be tantamount to admitting that you’ve failed. Gene suspected that his team was suffering from this fear-of-failure affliction, which--ironically--was only setting his group up for failure.
As Gene entered the staff meeting later that morning, he could feel the fear and defensiveness in the room. One of his chief goals was to lead people to understand that it was not a weakness to ask for help. But he had to be careful how he got his team there--making them feel that they had made a mistake by not asking for help was only going to work against his intentions.
"IT is too large a discipline for any one person to have all the answers," he began. "Speaking personally, if I had to be the answer man for every question that comes up in IT, I would have found myself another job long ago." He smiled. "I would have stuck to sailboat racing."
The people in the room laughed. They knew all about their boss’s off-work passion. Sailboat races are won, Gene said, when specialists (skipper, tactician, mainsail trimmer) work together--sharing knowledge, putting the good of the boat first, taking smart risks, and asking for help when they need it. "The old adage, 'we sink or swim together,' doesn’t just apply to boating."
Project Rescue is built on the ability of people working together, he continued, "but its success depends on more than teamwork. It depends on each member of the team thinking and acting like an owner of a business." Gene reminded them that, at the outset of the project, they had all made a commitment to think as such.
"Thinking as business owners, what would you do differently with regard to the problems you are trying to solve?" Gene asked. "What risks are we willing to take in pursuit of success? With the future of our firm at stake, what risks feel reasonable? And what do you need help with in order to succeed?"
Gene felt the room relax; he knew that they could productively problem solve now. One by one, team leaders shared the problems they had encountered. The group, working together and empowered as business owners, was easily able to identify potential solutions:
- Mobile: It turned out that the support team was attempting to document the configurations without having access to three of the phones they had agreed to support. Gene’s head of support agreed to go out that evening and buy the three phones. Problem solved!
- Wireless: With the pressure to figure the problem out on his own lifted from the senior networking engineer, the team agreed to call in the vendor and buy a couple of days of consulting. Who better than the vendor to tune the access points?
- Collaboration spaces: The team was stumped. Each person favored a different hosted solution and nobody was willing to budge. But when they switched their mind-set to become business owners, they realized that they had forgotten about the voice of the customer. Their preferences were not nearly as important as those of the students. They agreed to do a quick student survey and let that input direct the decision.
- Desktop videoconferencing: How could it be that the team’s preferred solution, which was used by many other institutions, was a security risk? Did they really have a better understanding of security than these other schools? They agreed to swallow their pride and call colleagues at other schools to ask how they handled the risk. As one of the team members put it, "There is no E-G-O in I-T."
As Gene drove home that evening, he reflected on the dramatic arc of the day. His senior team members started out as victims of circumstance destined to disappoint the campus. How could it be that with a little bit of coaching and paradigm shifting, he was now the leader of people who acted like winners?
Gene thought back to the lesson he learned from his first boss: Hire and mentor a great team. He had mistakenly believed that, by having his team members pledge to think like owners at the kickoff meeting, he had fulfilled his mentorship role. He had assumed they’d kick into ownership gear and get things done.
But, of course, that’s not how mentorship works: It is an ongoing, hands-on, check-in process. Today he got back into his mentor groove and coached his team into a good place. Still, Gene wondered, was it enough?
About the Author
Stephen Laster is the Chief Information and Technology Officer of the Harvard Business School and a member of the HBS administrative leadership team, which oversees the school’s academic, research and administrative computing teams. Laster sits on several Harvard University committees focused on leveraging technology across the Harvard community. As an educator he has taught courses at the undergraduate, graduate level and executive/professional level in the areas of Web development, problem solving, software design, virtual team management, and eLearning product development.