The Commitment-Accountability Protocol

As Stephan Haeckel (1999), director of strategic studies at IBM's Advanced Business Institute, has observed , "Organizational responsiveness comes from giving individuals and groups the freedom to behave in ad hoc ways to respond to unforeseen circumstances. For this reason, organizational roles are defined in terms of accountability for commitments to particular outcomes, rather than in terms of activities." If we are going to build a hub organizational structure and manage outcomes rather than activities, then there needs to be a mechanism for teams within the project structure to manage their commitments to each other. Rather than have the project manager keep up with and manage all inter-team dependencies, the teams need to accept that responsibility themselves , just as development teams commit to customer teams on features. However, as project size increases , a slight increase in formality and documentation is necessary to help teams handle these dependencies. A commitment-accountability protocol (CAP), which is based on Haeckel's commitment management protocol, can assist with this task.

The CAP addresses two key issues in managing large project teams: "How do we manage commitments?" and "How do we manage the work itself?" We can think back to the small project model for clues. First, the executive sponsor, with the advice and consent of the project manager and the product manager, agrees to overall project plan boundariesscope, schedule, and costs. Second, the development team and the customer team make iteration-to-iteration commitments to each other. The product manager can add, modify, or cancel features without going up the management chain for approval, as long as the project stays within its agreed-upon boundaries. The developers and customers agree on featuresa commitment for the iterationand then the customers put the features through acceptance testing at the end of the iteration.

With a few feature cards, requirement descriptions, and informal notes, small teams keep the commitments and the work interactions relatively informal. As project size increases, we need similar mechanisms to allow subteams to work together with minimal management involvement. A practice similar to feature cards will be used to manage the work. This practice, the commitment-accountability protocol, is a brief written agreement between subunits of the organization. Rather than having work assignments flow from the project manager down, the teams themselves decide on how they are going to work together (although the project manager does facilitate and influence the agreements). The objective of the CAP is to enable groups to manage their work for each other with the least amount of management involvement. It also assists in portfolio management by clarifying inter-team dependencies.

A CAP identifies a contract-like relationship between two teams. Rather than have a project manager say, "Do this by this date," the teams contract with each other and document their commitment on a CAP card, as shown in Figure 9.2. (An automated version of the card may be used when additional formality is required.) For example, in the development of an electronic instrument, a CAP card might state that the circuit board team agrees to deliver a prototype board to the instrument design team by a certain date. Or the product line architecture team might have an agreement to deliver platform architectural requirements to the instrument design team by a specified date.

Figure 9.2. Commitment-Accountability Protocol Card

The outcome is negotiated between two teams in the same way that a feature card would be negotiated between a development team and the customer team (although a CAP card will usually be for a larger chunk of work than a feature). And just as a feature card acknowledges a relationship between customer and developer and assumes a set of obligations and responsibilities on each party's part, a CAP card acknowledges a relationship and a set of partnership responsibilities between two (or more) project subteams. As in contracts with outside suppliers, the "customer" side in a CAP agreement has the right to accept or reject the work based on documented acceptance criteria.

CAP cards get scheduled into iterations just like feature cards. They state explicitly the cost of team-to-team coordination, and most importantly, they engage the teams with each other in ways that a project managerdrawn dependency arrow on a network diagram cannot. While the project manager should participate (so that he understands what the teams are doing and can provide information they might not have) with the teams in establishing these dependencies and developing the CAP, the fundamental agreement is between teamsand the project manager cannot arbitrarily break such agreements.

Neither can a project manager force a team to accept an agreement. As a team develops commitments with other teams, the members have to keep track of what they can realistically commit to, and scheduling the CAP cards as part of an iteration's workload helps. As is the case with features, when an iteration is full, it's full. At that point, adding additional commitments to other teams requires dropping some other block of work.

Coordination among subteams is critical to large projects, and just as team leaders shouldn't coordinate between individuals in their teams, project managers shouldn't coordinateat the detail levelamong subteams. A practice like a CAP has several advantages:

• It makes coordination work visible so teams can actually see why they are less productive than when they work independently.
• It helps build cooperative relationships between teams.
• It pushes the coordination load to the people who have the detail information.
• It raises the subteams' sense of accountability, since they decide on the commitment.

While some might argue that CAP cards are too structured and time consuming (and they may become burdensome if they are created for minor items), in practice they reduce overall coordination time and effort. Not using some form of inter-team commitment-accountability agreement would be analogous to eliminating feature cards. Feature cards create a minimal structure within which team members can work with customers. CAP cards create a minimal structure within which subteams can interact with each other in this same way.