New project teams and young companies are constantly looking for new ways of defining roles in project teams. Whether it is to cover a skills gap or a way of improving the team dynamics, team structure is a way to shake things up. In my experience, the best way to address this is to go through the 6 questioning words and use them assign ownership and remove confusion from the newly formed or reformed team. This format has become my roles and responsibility matrix for many of the teams I have worked with over the years due to it's simplicity and ease of use.
So how does it work? I typically, lay out the questions on the white board before the meeting begins (or word doc, etherpad, or [insert fancy electronic collaboration tool of choice]) in the format below. Then at the beginning of the meeting I give the overview and what we are doing and try not to provide too much guidance as to what role goes into each category (allows for self organizing teams).
The development team or the people who will actually do the work to make what your building a reality own answering this question. We expect them to look at What and Why and come up with the plan that they can follow to make the what a reality.
If you would like a PowerPoint template of the format used above, feel free to e-mail me and I will gladly send you one.
So how does it work? I typically, lay out the questions on the white board before the meeting begins (or word doc, etherpad, or [insert fancy electronic collaboration tool of choice]) in the format below. Then at the beginning of the meeting I give the overview and what we are doing and try not to provide too much guidance as to what role goes into each category (allows for self organizing teams).
Who?
This section covers the project stakeholders and team members who are considered to be core to the team or contacts into other teams as required.
This is your list of project participants or stakeholders, or team roster as you have seen many times before.
What?
What is this project about, What are we doing? All questions regarding what should be handled by this person/people. In other words this group is responsible for "what" is in scope.
In a technology project, this is the product manager. Ultimately the person responsible with gathering the voice of the customer.
When?
This person/people are accountable for figuring out when we need to deliver and tracking our progress relative to when we will get done. This person is typically responsible for the schedule and milestones.
The project manager is usually the person in charge of when. As the person that takes all of the resources items and puts them in the most logical order, they are best positioned to answer this question.
Where?
This section really is trying to determine the person/people responsible for the cadence and locations of team items. This is usually the one who is setting up the status meetings, meeting room, or any of those items.
Typically, this is the project manager as well. Setting up the meetings, the cadence, and the communication standards for the project.
Why?
This question is the one that trips people up the most. And the question I hear the most, why do we need to know "why"? This is important because it helps drive clarity to the "what". If there is something ambiguous in the requirements, people can sometimes come to understand what is meant because of the why. For example, Joe has a requirement for a hook hanging from the ceiling in his garage, the handyman installing the hook is thinking about using a small hook with a 5lb weight limit. This is ambiguous until you understand why the person wants the hook (to hang their 10lb bike in the garage). So the person/people listed here should be able to tell you the story of "why" the "what" is important to them.
Many times this is the same person as the person who is responsible for what. This is because who better to answer why than the person responsible for what. So typically, this is the product manager as well. But there are many times this could be a different person, so do not assume this is always the product manager.
How?
How will you be addressing the what? "What" is not the roadmap for the work but rather the destination for where we need to arrive. "How" is the route we take to get there. "How" is speaking to the way you execute to the "what". The people in this section are the ones who figure out how to do it and the ones who execute the how.
If you would like a PowerPoint template of the format used above, feel free to e-mail me and I will gladly send you one.
No comments:
Post a Comment