Downsized deadlines



When confronted
with dwindling
resources, project
teams must recognize
their common
goals and help
each other reduce


In the highly technical telecommunications industry, reducing time-to-market has always tested industry leaders. Today, due to overcapacity and unrealized expectations from the late 1990s, telecommunications companies are struggling, and project managers are left to face the fallout.

Numerous equipment producers may undergo natural mergers or bankruptcies, but only those companies that deliver quality products in the shortest time will survive—an even greater challenge when companies downsize and available resources shrink.

Tough market conditions forced Tellabs, a Naperville, Ill., USA-based global telecommunications bandwidth management firm, to reduce its head-count—and the resources per project. In 2002, the company listed about 4,700 workers, down from a high of about 8,900 workers in April 2001. “As customers spend less, we must take these painful steps to reduce expenses and position Tellabs for a future return to growth and profitability,” then Chairman and Chief Executive Officer Michael J. Birck said in a statement. “We are focused on sustaining the capabilities we need to be first out of the gate with innovative bandwidth management solutions for our customers when the industry turns.”

Despite the setback, the firm has emerged as a strong project player. To remain competitive, the firm charged its development teams to adopt a new approach: Create small sub-teams with equal load distribution and alternate the leadership position. Even after downsizing, Tellabs has kept its customers satisfied while lowering its costs.


To successfully employ the idea of mutual alliances, in which your project team cooperates across the enterprise, you should:

Find and Clearly Identify Common Goals. You must ensure that your proposal clearly presents benefits to your company and partners. Make sure other groups want to utilize this opportunity for their own benefit, otherwise it will be treated as a “help-to-peers” activity and diminish the efficiency of the alliances.

Obtain Management Support for Both Parties. Mutual alliances will involve people from different groups who work on the same problem. This cross-cooperation requires horizontal communication between individual contributors and the managers of both parties. In addition, secondary user teams must agree to lend resources to the primary team if needed at the time of the critical task.

Establish Ownership for Common Deliverables. Possession of common deliverables depends on primary and secondary uses. For example, a software group, rather than the hardware group, may develop a driver for a hardware module to be used as a part of its work for testing and validation. Therefore, the software group is the primary user of the deliverables and should take on the ownership role.

Define Responsibilities in the Overall Work Structure. Primary teams are responsible for defining work breakdown structures with tasks assigned to loaned resources. Secondary teams should directly utilize results of those tasks without major modifications.

Formalize the Methodology. Prior to work, both parties should establish uniform development processes. Concentrate attention on such tasks as coding standards, bug-tracking systems and version management.

Following Tellabs’ lead, functional managers may find resources they never thought existed.

Classical Teams: The Past

Prior to downsizing, Tellabs’ hardware and software development teams produced products that were integrated with other components by a system-integration-and-testing (SIT) team. The software team depended on hardware delivery and historically had to fix bugs due to shorter turnover cycles.

Each team had a technical leader, plus a mix of senior and junior individual contributors, who offered technical guidance. The leader was more likely to participate in concurrent engineering and provide individual contributor work requirements at a later project stage.

Senior team members were responsible for core design as well as teaching and mentoring junior members. However, because the average turnover rate was 35 percent, most teams didn't have dominant senior members.

As project completion approached, the team rolled over into the next project, starting with a lead developer and followed by senior members. Junior members supported existing products until they matured to senior status.

However, after downsizing, teams had to do more with less: There were fewer team members, but the market still demanded quick time to market. The firm clearly needed to rethink its product development strategy.


Tellabs small teams helped book the company's first revenues on the Tellabs 7100 optical transport system in 2001.

The New Small Team Approach

In the late 1990s, Tellabs’ switched to a small group product development approach. In the beginning, these teams struggled with a shortage of qualified resources and high pressure for new product delivery. The company's current success masks the effect of company downsizing.

Today, functional managers are responsible for a group of resources organized in self-directed sub-teams of a few people, who work simultaneously on different products that have the same delivery date. Average sub-teams consist of three to five developers who are equally involved in all project stages from requirements analyses to integration and support. Ad-hoc communications reduce the number of meetings and speed problem-solving time.

The manager learns about progress through short status meetings, but all problems are worked out from inside the team. Individual members are much more responsible for project details compared to the classical approach. Each team player must deliver components with minimal supervision, otherwise, the load on the other members of the team increases.


As in any new product development effort, process re-engineering often involves working out the bugs. Tellabs learned two key lessons setting up its small-team, mutual-alliance approach.

1. Successful Delivery Depends on the Ability to Work Independently.

In a small team environment, project success greatly depends on the performance of each individual. Ability to meet deadlines becomes crucial, because no other resource can rectify a missed schedule. The experience level of each contributor directly affects development time.

Developers should be able to work individually and possess good trouble-shooting skills. Due to high levels of ad-hoc interaction in the groups, a good psychological climate helps achieve synergy.

2. Performance Reviews Should Consider Mutual Alliance Work.

Mutual alliances require a high level of interaction with different groups, and so team members must adeptly find compromises and resolve conflicts as needed.

Because more than one team will use the deliverables and each has a stake in the final product, the developer's group and all team members must have an equal say in the designs. A team's willingness to accommodate big-picture requirements over selfish “just-for-me” planning should be considered during the employee review process and rewarded by a developer's manager to stimulate future cooperation.

Because each team member is involved, directly or indirectly, in a full range of problems, the risk of losing key contributors down the road is reduced. This level of cooperation shortens integration time and simplifies debugging.

Mutual Alliances

The “small team” approach puts a much higher load on each developer and prompts management to expedite the development cycles. By analyzing the development process of the internal vendors and customers, software teams can find similar tasks handled by different groups. For example, software developers may discover that hardware developers independently build chip drivers for testing purposes—work that the SIT group already accomplishes. Although the agenda of each group is different, there are common tasks performed by adjacent groups.

For this reason, Tellabs instituted “mutual alliances” that include other groups’ common goals. This way, the generic code that can be used by both teams is identified and defines common standards. The deliverables transition smoothly from one team to another without the well-defined “pass-to-next” approach. Software development teams write code that hardware developers use for module testing, and SIT teams provide tools to test software integration. Overall, this approach reduces the number of developers involved in test plan design and implementation and eliminates redundant tasks.

Since downsizing, Tellabs’ small teams have consistently delivered new products on time. In comparison to the classical team approach, which requires seven to nine members, the combination of small teams and mutual alliances yielded a time-to-market reduction of 20 to 30 percent, yet produced high product quality due to unified testing plans. PM

Mikhail Galeev is a technical staff member at Tellabs. He has a master's degree in electrical engineering and is attending classes at Northwestern University to earn a second master's degree in engineering management.




Related Content