Project Rescue: Building a Team Effort

How our CIO rallied the troops to take on the challenge of giving more value to the campus community.

• By Stephen Laster
• 03/01/11

At the post-cabinet meeting with his staff, Gene had secured some initial buy-in for Project Rescue: He had persuaded all his team members to commit to thinking like the owners of an entrepreneurial business, not like technicians offering a commodity service. (For more on how Gene accomplished this, see part one of Project Rescue. Now, they had to deliver -- quickly -- something of value to show the campus that IT was listening. Gene scheduled a Project Rescue kickoff meeting the next day with his leadership team. Even though each team member was on board with the effort, Gene still envisioned a room full of “FUD” (fear, uncertainty, and doubt). He realized that his team's desire to serve might be part of the cause of their troubles. In each corner of the IT organization sat a large backlog of work. People were so heads-down trying to get things done that they had lost sight of planning and communication. Between patching, maintenance, and over-the-transom requests, their entire operational approach had become a black hole of prioritization.

Gene also realized that he and his organization had become increasingly risk averse. The first year of Gene's tenure had been marked by major improvements that would have exposed IT had they failed: new e-mail, support for mobile phones, a new course management system, enhanced wireless. Four years later, all IT appeared to focus on -- one might even say hide behind -- was infrastructure and maintenance.

To quell his team's fears about the magnitude of the project, Gene established a simple methodology for the kickoff meeting: 1) Review and commit to operating principles; 2) brainstorm project ideas; and 3) commit to specific projects. Who could be intimidated by a three-point agenda like that? He'd find out on the morrow.

Planning and Governance
Gene started his meeting with two straightforward questions: How do we plan, and how do we know what work to do? He wasn't fully prepared for the animated and emotional two-hour discussion that ensued. His team members felt forced into being all things to all people. They were tired of new demands adding to a bottomless backlog. They believed that they always had to say yes. It was an impossible situation.

Once these frustrations had been aired, Gene asked everyone to step back and brainstorm ways to solve these problems. It didn't take them long to generate an impressive list -- given their collective years and depth of experience, this was no surprise. After grouping the list items into natural categories, the group returned to the two questions that started the discussion: How do we plan, and how do we know what work to do?

They immediately realized that there were two fundamental elements of their planning and governance solution: transparency (helping their customers understand why certain projects move forward and others do not) and customer involvement (making people feel part of the planning process). To achieve this transparency and involve customers would require the following steps:

• The IT organization would determine an operating capacity in hours, and share this with the university community. IT would commit to delivering a certain amount of time, across the university, in each of the following areas: project management, business analysis, software development, data management, server and system configuration and management, quality assurance, and training/support.
• The IT organization would earmark a portion of its overall capacity for ongoing maintenance and operations and turn the rest of the capacity back to the university for joint prioritization.
• Everyone in the IT organization would track time on task. By tracking time against capacity, IT could demonstrate to the community where it was spending time, where it had flexibility, and the human cost of implementing projects.
• A monthly status report posted on the university intranet would keep the campus community apprised of project commitments, backlog, progress, and capacity utilization.
• IT would resurrect a long-dormant planning committee comprising senior staff and faculty from across the university. Twice yearly, the committee would receive calls for projects from the campus community and prioritize the requests.
• The committee would also reserve some capacity for smaller projects (taking fewer than 100 hours) and allocate that capacity to operating units within the university for them to prioritize locally.
• The team committed to measure its efficiency against industry standards, and to share the results with the university community.
• Through its project management office, the IT organization would work with partners across the university on the yearly budget process. IT would help turn business needs into project definitions, size project requests, and help write business cases for any need so large that it required a supplemental budget request.

The team readily saw how this approach would help all members of the university community understand where IT was most needed on campus and how IT was responding to those needs. Combined with external benchmarking, this transparency would help to build a deeper appreciation of the organization's effectiveness.

Project Prioritization
But Project Rescue needed to change more than simply how the IT organization planned and governed itself. IT had to take some visible action within the next 30 days to show constituents that it was listening.
Even though IT team members had just committed themselves to involving campus stakeholders in prioritizing projects, they knew they needed to -- right now -- decide which of the 200 or so projects in the backlog should be fast-tracked for completion within the month. In their decision-making, they applied the following filters:

• Impact: How many people would be positively affected?
• Feasibility: Did IT actually know how to accomplish the project?
• Readiness: If IT implemented the change, was the campus ready to use it?
• Financial: Could IT afford to do the project?
• Time to completion: Could the project be done within 30 days?

Using these filters, the team quickly settled on the following list of projects:

• Support for a broader array of mobile devices
• Increased wireless speed in major campus locations
• Launch of a student pilot program with the newest generation of tablets
• Integration with a hosted collaboration solution
• Hosted web videoconferencing using the existing single sign-on infrastructure

Making these decisions was tough for the team members, because they had to defer other important ideas -- such as a new line of mobile applications for the campus intranet and a campus-only social network -- that did not meet the criteria of feasibility, readiness, and time to completion. The team realized, though, that these bigger ideas would be perfect to put through the new governance process.

Reviewing Commitments
As day two of their one-day retreat raced toward evening (good thing Gene reserved the space for an extra day), Gene and his team were pleased with their progress. They were committing to each other not only to keep the trains running, but to expedite new ways of planning and governing -- and to deliver some noticeable improvements. The projects they selected had a different feel from their usual slate: They could be quickly implemented, were a little risky, and were immediately visible to the community. It felt good to be back with an inclusive approach to governance, to be really thinking like owners in terms of measuring their capacity and consumption, and to be driving projects that would directly benefit the university community.

As the team dispersed for the night, Gene's thoughts began to race ahead. Did he have enough goodwill left to implement the governance ideas? Would the rest of the IT team accept the changes? They were off to a great start, but clearly much work and risk lay ahead.