Circle Dots and the Directly Responsible Individual

What’s new? This graphical technique can help you clarify who is charge of a given element of a program or project – eliminating confusion and building teamwork.  Distributed, global teams are now becoming the default way of organizing rather than a rare exception; however, with this kind of organization communication is essential.  Given the distributed complexity of development, clarifying in a picture, who is responsible for what will help prevent dropped balls in any type of projects in R&D, Design, IT, HR (change management).

What is the Tool?  Circle Dot

The Circle Dot chart is a line diagram over a matrix, which indicates the key deliverables on one axis and the key roles (or key individuals) on the other.  The plot consists of lines that indicate the tasks going down the page, and open circles where an individual function is involved in the task, and a filled circle (filled with a dot) as the individual who is the DRI “Directly Responsible Individual”*.  The person who is known as the Circle Dot or DRI knows and agrees that they are responsible for delivery of the task.

The process for creating a Circle Dot chart is simple and involves the Project Manager to take the first step to fill out a rough draft of the chart, and then a review and agreement session with the team.  The Project Manager lifts the key tasks (5-15) from the project plan and puts them in time sequence across the top of a chart.  The Project Manager lists (in alphabetic or importance order) the key functions responsible for delivering the program, including those outside the core product team.  Then circles are indicated by any function who is involved in a particular task, and then the one primary function that is ultimately responsible to fulfill the given task has a dot placed inside the circle.  All tasks must have one, not zero, and not more than one dots.

This draft version of the chart is reviewed by the team relatively early in the program.   At the end of this team review session, the functional representatives signs off on their various assignments.  This document is stored on the project team Wiki for reference.  When the key tasks are coming due, all understand who is ultimately responsible.  This is a living document, and if responsibilities change, the chart is updated to reflect the change.

What are the Benefits?

  • Provide a visual representation of roles

  • Helps prevent dropped balls by making it clear who does what

  • Helps prevent wasted effort by having two people working on the same thing

  • Useful at the beginning of the project to help share common understandings of roles

  • Useful during the project to clarify contributions and prevent miss-understandings

  • Graphical so it translates well to other languages for distributed global teams

  • Very easy to create and update

What Business Problems Do We Solve?

Besides unclear requirements, unclear responsibilities are one of the leading causes of program delays.  By providing the team with a very clear picture of the key deliverables tied to key functions, this problem is greatly reduced.  It is reduced at the beginning because the Project Manager gets buy-in up front that team members are on board and commit to a given task.  It is reduced during the project because this is a reference sheet that is reviewed periodically to ensure that the tasks are properly staffed and organized before they are due.

What are some considerations?

Obviously in very large or very small programs, this tool should be modified accordingly to match the scope of the task at hand.  For large projects, this is best done by having two levels of Circle Dot charts – one overall and several others at sub-system levels.  For example in platform programs, there might be three or so second level charts to cover the web, client, and device – and one overall, so a total of four Circle Dot charts.  Also, sometimes there is need for even more task clarity and specificity in the roles and in this case the three levels (uninvolved, involved, responsible) is not sufficient and one may need to add other roles such as approves and consults.  There is a related technique called “CAIRO” which can be applied in this instance.  CAIRO stands for Consults, Approves, Involved, Responsible, and Off – not involved.

Case Study

An IT team has just been kicked off to address a new system to improve the order entry accuracy and they have developed a project charter, project plan, and have identified the Project Manager, Business Analyst, Business Process Owner, Business Process User, Change Manager, Quality, Finance, Sales, Technical Lead, Training Lead, and an outside consulting team that will do much of the implementation.  The Project Manager has taken the first cut at a program plan and schedule and identified the project plan and key deliverables and milestones including:  Requirements, Vendor Selection, Detailed Requirements, Design Finished, Coding Finished, Alpha Testing, Go Live, Beta, Training, Cut in, Post Mortem.

She did a rough cut of the Circle Dot chart and presented this to the team (except the vendor, since they had not been selected) in a dedicated work session on this topic conducted at headquarters with several other sites dialing in via Telepresence.  In several areas the Project Manager and the Technical Lead changed around the Dot inside the Circles (Vendor Selection, Coding Finished) but now agree.  This chart was published on the team Wiki.