formerly of Professional Project Services, LCC
Tag Archives: responsibilities
Have you ever been on or lead a team where confusion over who should do what existed? Maybe there was a ‘roles and responsibilities’ document or even RACI chart on the wall, yet team members struggled. Struggles commonly persist when a task was not included in the document or the team members did not accept the assignments. Have they even seen and reviewed it? Unclear expectations and lack of communication leads to team conflict, something we all want to avoid. Below is one exercise I have done with teams that has resulted in a better understanding and respect in team members’ roles.
Generate team discussion and agreement on who is responsible for the completion and quality of project tasks.
All team members for a small team or a representative of each team discipline for larger teams. No discipline should go unrepresented. For best results, ask for an independent facilitator so that the project manager can be a full participant.
- Large index cards or sticky notes
- Empty walls for posting cards
- Felt pens
- Write out a team task, one task per card (may be hand written with felt pen or creating labels to stick to the cards may save some time) – Sample Set of Labels
- Create a card for each project team discipline (e.g., developers, business analysts, test team) including single person roles (e.g., project manager, sponsor)
- Use the team discipline cards to create areas for columns, or groups, of tasks on meeting room walls. Additional groupings for “ALL” or “TBD” may also be represented.
- Leave some blank cards and felt pens around the room for team members
- Organize your pre-written cards so that can easily get to the most controversial tasks easily
- Explain the goal and process for the meeting to team members
- Goal – Assign all tasks to project sub-team or members with full team agreement
- Process – Ask the meeting participants where each task belongs as far as who do the task. Encourage discussion of “why” when there are differences of opinion. There are no right or wrong answers. Whatever the team agrees to is correct. The project manager may suggest best practice, but not dictate the final assignment.
- Start with a few more obvious tasks such as “write program code”
- Post the card in the in the group that the team agrees
- Where differences of opinion, ask those most directly affected to explain why they choose that role or discipline
- See if team members agree after hearing explanations
- If still no agreement, offer the project managers view on where the assignment belongs
- See if team can agree to the project managers view, specifically those most affected
- If still no agreement put task aside or post in “TBD” to come back to
- Limit the time per card to about 2 minutes
- Move on to the tasks that are likely to generate the most discussion once team members have a handle on how the process works
- Team members may propose new tasks for discussion by writing out a card
- Stop about 10 minutes before the scheduled end time to get agreement for handling remaining tasks. Possible options include:
- Extend meeting time
- Schedule a follow-up meeting
- Assign delegate to propose assignments for any remaining tasks and send to team members
- Inform the team how the results will be documented and where available for future reference
This exercise focuses on who does the work. There is still a need to document who reviews, who approves, and so on. This can come in a RACI-type chart later. Another option is to mark each card as team members discuss the assignment. Choose whatever method will get to team acceptance the quickest.
I mention a RACI-type chart for a reason. When creating a matrix of roles and responsibilities use the terms best represents how work is approved in your team and organization. “Responsible”, “Accountable”, “Communicated”, and “Informed” may not hold a lot of meaning to your team members where “Leads”, “Approves”, and “Informed” may be clearer. Let the team help decide on the categories to capture so that the resulting document is meaningful.
I hope this exercise, or some variation of it, will help to avoid confusion and conflict in your project teams. Please comment or email me if you use this exercise on your project. I am interested in how it went for your team; especially any adjustments made that provided even better results.