Practice: Customer Team-Developer Team Interface

Practice Customer Team Developer Team Interface

Objective

The objective of this practice is to define the collaboration interface between the customer team and the development team.

Discussion

A significant number of project failures are caused by poorly defined customer-developer interfaces. While customers and developers are often on the same "team," they are often not on the same subteam. When this interfacewhich is defined by information flows, accountabilities, and responsibilitiesis ill defined, project failure looms close by.

Every project should have a project manager and a product manager. One of the key reasons internal IT projects fail, or underperform, is misunderstanding the nature of these two roles. Product groups often do a decent job of differentiating these roles, but IT projects often miss the product manager role. At one level the responsibilities of the product manager and project manager are simplethe first is responsible for "what to build" and the second for "how to build it." In practice each role, each person, has input and influence on the entire projectboth the what and the how.

This brings up another wider issue. Roles are not static descriptions that we slavishly follow; roles are instantiated by individuals, and every person who fills a role plays it differently. Just as every actor playing Macbeth brings his own talents, interpretation, and experience to the play, every person who fills a product or project manager role (or any other role) plays it differently. One product manager may have extensive technical experience, another less. To tell the first person that she shouldn't have any input to the technical decisions would be throwing away a valuable resource. To tell a product domain- experienced project manager or developer that he will have no input to the product vision or specifications would be an equal waste of talent.

Project management books and company job descriptions often contain specific role narratives that include decision-making authority. While role boundaries are important, in practice a role should be flexible, adapting to the specific person who fills it. At best, a role takes a page of description. Roles are finite. People are infinite. Role descriptions are merely a starting point for actual product and project managers to build relationships that will quickly transcend static roles. How each individual interprets his or her role and how he or she interacts with others who are interpreting their own roles results in a richness of relationship that transcends our feeble attempts at role descriptions. Trying to force people into a fixed role description is not only ultimately impossible , it is counter to agile principles. People are not only more important than process, they are more important than roles.

Getting back to the interface issues, there has long been a controversy in IT circles about where project managers should come fromcustomer or IT departments. Because of failed interactions on projects, companies have attempted to push project responsibility onto the customer by having someone from the customer organization be the project manager. Unfortunately, these individuals often don't have the time, project management skills, or technical knowledge required for the job. The real customer-developer problems get lost in this shuffle, because there is no differentiation between product and project management. All too often customer-side project managers try to do the job of both project manager and product manager in addition to their full-time job and end up failing at all three.

Figure 5.10 shows the outlines of a solution to this problem of who is responsible for what. Within any project there should be a development team and a customer team. The development group should be headed by a project manager and the customer group by a product manager. So who gets the final say? In most cases, the product manager does. Either manager can of course appeal decisions to the executive sponsor, but if the product and project managers can't work out most conflicts, the project risk escalates rapidly .

Figure 5.10. Creating a Customer-Developer Interface

For a small project, the product manager may also be the primary customer. For an IT project for which there are ten customer departments, spread across six cities, with 150 users providing requirements input, a product manager should be appointed to coordinate the customer information flow and decision making. For a product development organization, the product managerwho often resides in the marketing departmentcoordinates the gathering of information from thousands or even millions of retail customers, condenses them into a usable form, and then coordinates the decision-making process.

While any decisions made without interaction and debate between the customer and development groups will be poor ones, ultimately the "what" decisions are made by the customer team and the "how" decisions are made by the development team. Good development groups have a wealth of knowledge about the product domain and should have significant input into the "what" decision. Product managers and other customer group members often have significant input into "how" a product might be designed. In the end, however, each group has its own responsibilityand projects fail because these responsibilities aren't clear.

The responsibilities of each group and the interactions between the two groups are key to success. In the early Envision stage of a project, both groups are involved in creating a product vision, but the product manager is responsible for the final decisions. During the Speculate and Explore phases, the groups interact to analyze requirements, to identify features, and then to prioritize those features into development iterations. Customers define feature requirements and help the project team make day-to-day refinements. Larger projects may have many customers, who often have conflicting needs and priorities. No single person may have knowledge of all the feature requirements. For these larger projects, or for projects with wide- ranging needs for customer information, it is important to consolidate multiple voices into a consistent "customer voice," a task that is ultimately the product manager's responsibility.

Without a strong product manager, the worst situation arisesprioritization fails, and the development team, in order to keep the project from bogging down, begins making the priority decisions itself. This degenerates into a no-win situation, as the customers can always fault the decisions and then use that failure as an excuse to reduce their involvement further. When a project loses its partnership relationships and parties abdicate their responsibilities, that project is in big trouble. This problem sometimes occurs in companies because product managers tend to wear both a marketing hat and a development hat. The marketing role takes up so much time that they have little left over for working with development.

One of the fallacies of serial development methodologies is the idea that complex information can be transferred from one group to the next via documentation alone. Most NPD efforts utilize cross-functional teams because company managers realize they cannot depend on documentation to convey complex information. Documented requirements, at some level, are necessary but insufficient. Without interaction between the customer and development groups, requirements documents will be sterile husks. Agilists believe that critical understanding comes from interaction and discussion rather than documentation. In many cases, the agreement and understanding need to be documented, but not the churn that was created in order to get to the agreement and understanding. [10]

[10] For additional information, see (Cockburn 2002).

The final interaction shown in Figure 5.10 is acceptance. It is the customer team's job to accept the product by verifying that it meets requirements. This acceptance can be done through a combination of formal testing and customer focus groups. A technical quality assurance group may assist the customers and product manager in this effort, but ultimately the responsibility for acceptance lies with the customer team.

As with many other practices, defining the customer-developer interface presents different challenges when you are using it with a team of 10, or 100, or 1,000. Trying to corral 100 customers from disparate business departments is much more difficult than working with a single one. Similarly, working with a group of 100 engineers creates more headaches than working with 2. However, the basic interactions shown in the customer-developer interface diagram and the responsibilities of the roles as described above don't change with size . The means to the ends will be different, but the outcomes should be consistent.