The Challenge of Tracking Subordinate Accountabilities

Most projects rely on multiple layers of interdependent tasks.  This makes the tracking of individual accountability a challenge.  We have dealt extensively with the issue of tracking subordinate accountabilities.  For example, person A makes a request of B who in turn relies on input from C, and so on down the chain.    Let’s call A’s request of B the “parent” request.  To fulfill this request, B has made a “supporting request” of C.  The key point is that each commitment involves only two people – a requester and a performer.  Having made an explicit agreement, each performer is accountable to their requester.  For tracking and reporting purposes, two issues arise: accountability and visibility.

A has made a request of B.  A and B are in a committed conversation where B has promised some output to A by a certain date.  A and B are in a conversation in which they have negotiated a clear description of what A needs by when.  B’s ability to deliver on that promise is based on a subordinate conversation between B and C.  Typically, B will not make the commitment to A before making the supporting agreement with C, but in any event B has made an agreement and is accountable to A.

Similarly, B and C are in a committed conversation in which they have negotiated a clear description of what B needs from C by when.  C is accountable only to B.  When C feels that the task is complete, C “delivers” to B, but it’s up to B to determine if the task is actually complete or not.  If B is satisfied, B “accepts” the delivery from C and then B closes the supporting request conversation between B and C.  Now B can “deliver” to A, but it’s up to A to determine if they “accept” the delivery and then A closes the conversation between A and B.

While accountability is limited to these one-to-one conversations, visibility is NOT limited.  When A makes the parent agreement with B, both parties (requester and performer) can “see” the conversation in progress and take appropriate actions to progress the conversation.  When B makes the supporting request to C, A can “see” the conversation that B is having with C.  As an observer on the supporting conversation, A can also make comments, but A can NOT take any action to progress the conversation between B and C.  A is only an observer.  B can see both conversations, one in which they are the performer to A and the other in which they are the requester to C.  C can see the conversation with B, but cannot see the parent conversation B is having with A.

A chain of supporting requests is also possible.  The parent requester can see and comment on any conversation all the way down the chain; in effect, they can see, and comment on, the whole supply chain.

Commitments, that lead to clear accountabilities, are negotiated agreements between two roles, a requester and a performer.  These agreements are forged in a specific conversation which progresses from a specific request through to a precise closure.  Requests are non-hierarchical; requests can be made of superiors, peers, and subordinates.

One of CommitKeeper’s unique features is the ability to track and report on these chains of supporting requests while providing clear accountability for each party.

Comments are closed.