Roles and Responsibilities

Flower GirlMy wife and I recently traveled to Seattle for a wedding. Our daughter-in-law was the matron of honor, and our granddaughter was one of the flower girls. Since Abbie is only two and a half years old, this was her first wedding. Fortunately, there was another flower girl, who went first and modeled the appropriate behavior. She walked the length of the aisle, scattering rose petals along the way. Abbie followed for a few steps, and then stopped to look at the rose petals on the floor. Being OCD (like her Dad), she started picking them up and putting them in her basket. Not quite what Mom had expected when she gave her the job, but the audience loved it.

Roles and Responsibilities

For many people, being assigned to work on a project is a novelty. They have regular jobs, where they have well-understood, routine practices and procedures. However, their additional project duties may not be clear to them. When in doubt, they may default to the behaviors that have made them successful in their regular job (like cleaning up the floor after play). This default may not be beneficial to the project, especially for tasks in the critical path. Consequently, it is important to make the responsibilities, procedures, and project relationships clear for the people assigned to each role, especially if they’ve never worked on a similar project. There are several tools available for clarifying roles and responsibilities:

  • Project Organization Chart – A simple hierarchical diagram of the reporting relationships can usually answer most questions, especially on a cross-functional team.
  • Role Description – Many project charters or project human resource management plans have a narrative description of the duties and responsibilities of each role. This can prevent confusion over who is responsible for what activities.
  • RACI Chart – A table listing the work packages or deliverables, identifying who is responsible, accountable, consulted, and informed for each, usually adds enough structure for most teams to establish a well-understood workflow.
  • Samples and Templates – Many “new” tasks are best understood by looking at the result of a previously completed task, or a fill-in-the-blanks form. This is especially true for work packages resulting in a document deliverable.

Minimizing Overlap of Responsibilities

A primary goal of planning for the human resources aspects of a project should be to ensure all tasks are covered, exactly once. If two people are responsible for the same task, there is a reasonable chance that neither of them will do it. Use the RACI chart to fine-tune who participates in the production of each project deliverable. Ensure that all work assignments are unambiguous, and all participants understand how the work in progress will be handed off. Work with the team to define cues, and follow up on transitions from one person or group to the next. And don’t forget to note completion – I like Kanban boards, because they make work in queue, in progress, and completed visible to the workers.


Of course, nothing beats coaching. Whether it comes from the project manager or another experienced team member, a bit of guidance can go a long way. Any task performed for the first time naturally raises questions, before, during, and after. I regularly work on SaaS or software implementation projects with people who will only replace their enterprise software once or twice in their career, so the coaching is less about developing skills than it is about getting them through the assigned task.

Effectively communicating roles and responsibilities can make the project a positive experience for the entire team, while ensuring the timeliness and quality of the deliverables. It takes a bit more care in planning, but it makes execution go much more smoothly.

Selecting Means of Communication

Master Kan“Avoid, rather than check. Check, rather than hurt. Hurt, rather than maim. Maim, rather than kill. For all life is precious, nor can any be replaced.” — Master Kan (Philip Ahn), “Kung Fu”

I’ve seen a lot of different estimates of the amount of time a project manager spends on communication, but I’ve never seen an estimate below 70%.  So if we’re going to be interacting with others for most of our working day, we might benefit from a rubric for selecting our means of communication for maximum efficiency.

A rubric is used to assess a performance task, but it can also be used to determine the best approach for performing the task.  The table below describes a rubric for assessing planned communications.  Each element is associated with criteria, which correspond to numeric values.  Communication tasks with lower totals benefits from use of one-to-one communications, whereas somewhat higher totals benefit from one-to-many communications, such as Tweets or Email.  The highest totals benefit from many-to-many interactions, such as conference calls or in-person meetings.

3 2 1
Number in the Audience Many A few One
Proximity of the audience Distant In between Close
Physical distribution Widely distributed In between Co-located
Need for audience interaction High Moderate Low
Familiar with subject matter Yes Somewhat No
Potential for emotional reaction Low Moderate High
Complexity of subject matter High Moderate Low
Need for immediate response Low Moderate High

The goal of communication planning should be not to reduce the amount of time spent communicating, but to making planned communications as efficient as possible. Analysis by rubric can be very useful in preparing our project communication plans.  To paraphrase Master Kan: Speak face to face, rather than by telephone.  Telephone, rather than Instant Message.  IM, rather than Tweet.  Tweet, rather than Email.  Email, rather than schedule a conference call.  Conference, rather than schedule a meeting.  For everyone’s time is precious, and their attention and participation should not be wasted.
Dilbert Meetings a Waste of Time
I’d appreciate your thoughts on the rubric elements and criteria – I’m pretty sure my first pass can be improved.  Leave a comment below and let’s collaborate on it!

Thus I Refute #NoEstimates

In a recent blog post, Woody Zuill – fellow blogger, fellow middle-aged software guy, and fellow banjo picker – gave his personal definition of the #NoEstimates Twitter hash tag that has been the venue for a lot of online discussion lately.

#NoEstimates is a hashtag for the topic of exploring alternatives to estimates for making decisions in software development.  That is, ways to make decisions with “No Estimates”.

Woody and several others in the Twitterverse and Blogosphere have been advocating for making decisions (more accurately, applying constraints) that don’t require estimates, in order to eliminate the need to make other decisions that would require estimates.  Neil Killick recently posted an explanation of how to do Scrum without estimates, including this example:

Instead of depending on an accurate estimate for predictability we can take away the unknowns of cost and delivery date by making them… well, known. The Product Owner can fix the delivery date based on a concrete budgetary and/or time constraint (e.g. 3 days before the Australian Open starts for the Australian Open app is a concrete time constraint, and “we have to build something for $30,000″ is a concrete budgetary constraint).

Implicit in the example is that, once time and schedule are fixed, only the scope is flexible.  While this would certainly make things easier for the software developers, it adds complexity for everyone else.  To explore Neil’s example, let’s assume that the Australian Open app is a public-facing, self-service web site where the general public can buy tickets, see the daily results, read and comment on the news coverage of the event, and possibly follow links to the personal web sites of the players.  But what else is involved in serving the public audience interested in the Open?  I ask because, in the real world, not all members of the public are going to use that web site.

Presumably, the Open will have a call center to handle inquiries and purchases from those who don’t find or can’t access the web site.  They may also have an interactive voice response (IVR) system to support certain kinds of queries and possibly even ticket purchases.  So the Decision Makers will want to make the Australian Open app fit into this operational framework, providing capabilities and services for the public that supplement or complement each other.  To do this, they need to have a firm list of capabilities (or scope) defined for each of the three projects – Call Center, IVR system, and web app.  That way, they can staff the Call Center appropriately, work with the marketers to provide instructions to people when directing them to the IVR or app, and otherwise direct user traffic.  But if the Call Center folks and IVR configuration team don’t know until three days before the Open starts what functionality the web app will have, that doesn’t leave them much time to react, does it?

Of course, it might be wise for the Decision Makers to conduct a “buy or build” analysis, since large events are quite common and have spawned a number of service offerings, including Software as a Service.  But in order to conduct that analysis, they would need a firm feature / capabilities list and cost estimate for the internal development effort, to compare it with the vendor offerings.  And if all the internal developers can commit to is cost and schedule, it makes comparisons impossible.

A group of frogs who live at the bottom of a well are enjoying their nightly chorus of croaking, when one of them announces that he is studying astronomy.  When he gets a quizzical look from one of his comrades, he explains that it is the study of the sky.  “You know: that little round thing at the top of the well.”

Complexity will persist in the face of all attempts to reduce it through simplifying assumptions.  Few modern business problems are simple enough to reduce to a small number of decisions, which then drive all other activity.  Apples falling out of trees are fine for explaining gravity to school children, but celestial mechanics has to contemplate multiple bodies.  Similarly, modern business problems are not simply about software.  And that is why we should devote our energies to improving the quality of our software development estimating methodologies, rather than advocating adoption of simplifying assumptions that don’t reflect a holistic view of the operating environment.