Several years ago, I had an opportunity to work very closely with many of the business and IT units within the NASDAQ stock market. Over the course of working with these teams, it became clear that the company was able to quickly and effectively implement IT projects. The key to its effectiveness was the way teams were organized around specific projects.

At NASDAQ, the business teams worked with specific IT units assigned to their project. Business and IT units joined together to constitute a project team with a common goal of success for the project. With the same units constantly implementing a project, the team's effectiveness becomes self-optimizing. The purpose of this article is to examine the composition of these project teams and the secrets to their success.

CORPORATE BACKGROUND

During the early 2000s, NASDAQ had two major IT centers, one in the northeastern US, which dealt with the market systems, and another in the US Mid-Atlantic region, which dealt with the company's Web and data projects. This article specifically deals with the IT teams in the Mid-Atlantic IT center -- their composition and effectiveness.

The Web and data projects were structured with essentially four departments:

1. Business -- primarily responsible for the strategic business and product planning

2. Software development -- provided the software development for the projects

3. Quality control -- provided testing resources and expertise

4. Operations -- provided network, infrastructure, production deployment, and support

All four departments shared a similar management structure. Each department had an executive manager; for the business department it was an executive VP, for the other three departments, it was the CIO. Next were the senior managers, usually VPs. Below the senior managers were the middle managers, including directors and associate directors. Directors and associate directors usually had analysts and developers as their direct reports.

The company size at this point, around CY2000, was about 800 employees. There were approximately 50 members of the business department, 100 members in the software development department, 30 members in the test department, and 40 members in the operations department.

THE PROJECT AND PROJECT TEAM

NASDAQ's various products were considered projects. These have included the company's various Web sites, data feeds, market systems, and infrastructure components. Projects can often be ongoing with continuous releases, which take place anywhere from biweekly to monthly or quarterly.

The typical structure of a project team consisted of the business unit, led by a business manager; the software development unit, led by a technical project manager; a test department primary point of contact; and a primary point of contact from the operations department. The business managers and project managers were usually director- or associate director-level managers. Some teams vary this structure by incorporating additional units such as configuration management or content providers, but this was the basic structure.

WHY IS THIS EFFECTIVE?

Units Working as a Team

Why is this type of project team effective? One factor is that this structure caused people from separate and otherwise independent units to work as a cohesive team with common goals. The managers stressed to their employees that they were part of this "project," not the "department" from which they came; thus, project success was a group responsibility. To put meat on the concept of "whole project responsibility," project releases and objectives were factored into yearly bonuses.

As we see in the "Project Release Cycle" sidebar, a second important factor was that all team members actively participated in each step throughout the project's release cycle. This allowed the entire team to be constantly aware of the overall release requirements and progress. It also served to synchronize project vision across the entire team instead of letting individuals develop narrow, parochial areas of knowledge or responsibility. Cross-functional participation prevented developers from only knowing the code and testers from only knowing test plans. The entire team had a team concept of the release from the beginning to the end, and the closed-loop feedback communication ensured minimal miscommunication. The typical results of these cycles were releases that were completed within the time frames that the business had projected for project success and within the defect tolerances the various IT departments had set. Since the employees' yearly bonuses were tied to the success of the project, each successful release increased employee and team morale.

Thanks to this combination of factors, project team members empowered each other for success, and projects benefited from each unit's specialty without the "circular firing squad" seen in some organizations. When an issue arose or a roadblock appeared, the general attitude was "What can I do to ensure project success?" not "What did you screw up to cause this problem?" This solution-oriented perspective was visible in all units of the project team. The "New Testing Forms and Rules" sidebar shows this tendency in action.

Optimization

In addition to team unity, there were several optimizations that constantly occurred within the teams. One was that with each release and implementation a team produced, there was a post-production review. The team examined the release successes and what could be improved. These lessons learned were of great help going forward. On the teams with which I had worked, the motto was, "It is OK to make a mistake -- just don't make the same mistake twice" (see the sidebar on page 31).

In addition, each iteration and release added to the team's experience with the project. This domain knowledge stayed with the team through the project's life. Unlike IT structures that move people in and out of projects per release, there was very little, if any, ramp-up time or learning curve between releases. If individual team members left the team or company, the remaining team members retained knowledge of the system. Thus, technical and domain knowledge continued to grow as the project matured, despite an array of disruptions.

Release tracking also became optimized. As each release was deployed, the project manager had more historical data with which to estimate the release cycles and timelines for the next release. Thus, team velocity became a better-known factor. As future releases were planned, the project manager increased his accuracy in project scoping and projections.

Over time, the releases became defined patterns. Like a finely tuned machine, the team became proficient and the project became more streamlined from its initial stages to the end deployment.

WHAT TO GUARD AGAINST

Project Stagnation

With this structure, there are a few problems to guard against. One is project stagnation. As a project matures and the architecture and infrastructure are established, there can be a tendency to keep what is in place and not make any changes.

In terms of project functionality, the scope was a responsibility of the business units. The other IT units provided input to the project functionality and worked with the business units on project vision, but ultimately it was the role and responsibility of the business unit to ensure that project functionality was updated and enhanced as strategic and business needs dictated.

Team Stagnation

Over time, members of a project team may become bored performing the same tasks repeatedly. It was their manager's responsibility to ensure that team members had a professional development plan to develop their skills and to promote members within the team. By helping develop individuals within a team, new ideas could be introduced at a steady pace through growth and training. This did help ward off the attitude "This is the way we do it because that's how it's always been done."

There may be times when project team members need to be promoted or moved out of a team. At NASDAQ, a project team could lend team members to other project teams and could negotiate to temporarily bring in additional resources from other teams when necessary. This was permissible because other members of the team(s) in question retained the needed system knowledge. When a new person joined a team, she could be assimilated quickly and add her own unique depth and perspective to the team, thus enabling the cross-pollination of ideas. Existing teams usually enjoyed adding new team members. Teams were proud of their work and liked showing the new members what they had done on the project. They valued the added manpower new team members offered as well as any improvements or ideas these individuals could bring to the team.

Resource Strain

Another issue to consider when each project maps to its own team is that supporting this structure may require a rather large pool of personnel. NASDAQ mitigated this problem in the following ways:

• A business unit could own one project or multiple projects depending on the scope of the various projects.
   
• The project manager could be assigned to one project or multiple projects, depending on the scope of the projects and the experience of the project manager.
   
• Developers usually worked for the project manager. In most cases, the developers would be assigned to a specific project, but if the workload on that project did not require a committed developer or development team, then the developer would also be assigned to multiple projects. These projects would normally be owned by the project manager to whom the developers reported (see the "Project Assignment and Resource Conflict" sidebar on page 32).
   
• The point of contact for the test department and the point of contact for the operations department would put together the resources for each release. These would usually be the same for each release, but this was not always the case. However, the point of contact remained constant each time.
   

With this configuration, the organization begins to resemble some aspects of matrix management. This raises a couple of common concerns with matrix organizations, including multiple projects drawing on the same resources at the same time and individuals responding to more than one management chain. However, at NASDAQ, the business unit manager and project manager generally own the same portfolio of projects, so together they can decide the priority of the projects if there are any resource conflicts.

SUMMARY

This article is not about determining business value or IT governance, but rather, it is about how to structure teams to effectively implement projects that have been determined to be of high business value. At NASDAQ, project-based teams were demonstrated to be highly efficient at improving productivity, quality, and accountability for producing this business value. In structuring IT teams based upon projects and establishing the project's success as the objective, business and IT units were able to come together to form cohesive, highly functional teams that produced valuable results. These teams were effective because:

• Team members worked very closely together from beginning to end.
   
• Team members shared accountability for project success.
   
• Team members generally remained constant.
   
• Technical and domain knowledge was retained by the "whole team" and continuously grew.
   

ABOUT THE AUTHOR

Richard K. Cheng is currently a Senior Consultant with Level One Consulting, based in McLean, Virginia, USA. Mr. Cheng provides project management, team management, IT consulting, and agile/lean consulting to his clients, including Fortune 100 companies as well as various financial and government organizations. He is a Certified ScrumMaster (CSM) and a member of Mensa, and he has earned a degree in mathematics with an option in applied discrete mathematics and a minor in computer science from Virginia Polytechnic Institute and State University. Mr. Cheng can be reached at rcheng@l1consulting.com or richard.k.cheng@verizon.net.