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.
Last month I attended the Project Management Institute’s (PMI©) Northern American Global Congress in Washington D.C. I was struck by one recurring theme I heard throughout the Congress. President Bill Clinton, Vivek Kundra (United States Chief Information Officer), and many of the workshop speakers touched on this theme. The theme I am referring to is ‘candid and open discussion of project status and issues’. It seems to me that we project managers hate to communicate or especially escalate issues. Isn’t that a sign of weak leadership?!? We should be able to resolve EVERYTHING by ourselves. While it may be true that we want to, it is not realistic. I have always liked the notion that the best managers are those who keep people that are smarter than themselves around. I know that I like to think those who employ me do so because I am better at project management then they would be themselves. So why would I not recognize my manager’s and sponsors’ strengths when it comes to the business or the organization that my project supports? I need to communicate project struggles and let them know the areas of their expertise that will best support the project in order to leverage those strengths.
Mr. Clinton and Mr. Kundra were not speaking from the project manager’s point of view but rather from the sponsor or executive stakeholders’ view. Mr. Kundra stated ‘Do not waste my time with telling me how good you are. You were hired because I know you are good. Tell me the barriers the project has so that I know where my assistance is needed. Red (dashboard indicator) is okay. This helps identify where to focus on root cause to make improvement’ (Keynote PMI Global Congress October 10, 2010). Often the root causes of issues do not reside in the project and therefore are outside of our sphere of control. Sponsors need to know where there are problems to help identify and work toward resolution. Most managers are where they are because they like challenges and solving problems. I can think of one sponsor in particular who was much more engaged when utilized in this way. Also, by keeping successes high level and getting into more specifics on barriers we should have more time to execute, assess, and take corrective action on the project. At the very least when you communicate issues early the sponsor will not be blindsided if the project is negatively impacted.
Try working with your sponsor early next time your project is faced with an issue outside of your control so that you can judge for yourself the benefit of the approach. I would be thrilled to hear the results, good or bad.