Four Rules for Fast Teams

At Cambridge Technology Partners, project teams work fast, but few have worked as fast as Tammy Urban’s team. Four tips for managing a high speed, tight deadline project.

At Cambridge Technology Partners, project teams work fast. But few have worked quite as fast as the team that recently introduced a new customer-management application for AT&T. The project started out as a fairly routine assignment — at least for CTP. The company agreed to design a system and write the code in six months. Project manager Tammy Urban, 32, assembled a team of 10 people, put them in an open-plan project room filled with workstations, flip charts, and whiteboards, and got down to business.


Three months into the project, everything changed. AT&T decided to add an entirely new service to its offering, which meant the CTP application had to incorporate a new suite of features. Worse, AT&T had already gone public with the launch date, so the software’s due date could not change. Within 24 hours, Urban had reassigned two people from the existing team to develop the new modules. Within 48 hours, she’d added three newcomers to assist the two veterans. Within a month, the group had caught up with the veterans and had begun integrating its code into the main system. How did the project come together so quickly? Urban sites four principles for fast teams:

Let the Group Make Its Own Rules.

“You want to make sure people have a say in how they’re going to work together,” she says. “So we agreed on ‘norms’ for the team. What are our core hours? Are there certain times when we’re going to allow for toys or have fun things going on?” Among its norms, the team agreed there’d be no music before 5:00 p.m., but fun and games after 6:30 p.m.

Speak Up Early and Often.

The team adopted a “two-minute rule” for seeking advice. “When someone was stuck on a problem, we didn’t want them to wait more than two minutes to ask for help,” Urban says. Early on, asking for help simply meant speaking up. As the team grew, it used Web technology to create an internal discussion list.

Learn as You Go.


The AT&T project was divided into multiple phases. At the end of each phase, the group spent half a day assessing its work. These “sunset reviews” involved the whole team plus a group of company veterans. The reviews didn’t help just the AT&T project, Urban says: “We’d take what we’d learned, what had worked well, what we wanted to improve, and deliver that to the rest of the organization. It could gain from our experience.”

Fast Has to Be Fun.

Urban’s people invested as much energy in keeping each other pumped up as in pumping out code. One of the team’s most important databases, she jokes, was its list of favorite ice-cream flavors. “We went on team outings at least once a week,” she recalls. “We’d play darts, shoot pool. Teams work best when you get to know each other outside of work — what people’s interests are, who they are. Personal connections go a long way when you’re developing complex applications in our kind of time frames.”