* * *
Team Roles and Responsibilities
Clarifying the roles and responsibilities of everyone involved in the project will avoid miscommunications and confusion during project execution. Expect this section of the communications plan, more than others, to be iterative as the team works out overlaps and gaps. It is better to define roles and responsibilities in parallel or after the creation of a pro forma Project Data Sheet (see Chapter 7 on planning). These roles and responsibilities are not intended to be cast in stone, but should give the team the boundaries necessary for efficiency and agility.
Definitions:
These definitions should help get you started. You may modify them according to your team and organization needs. It is important to have a common understanding of these terms among team members.
Role: Your role is what you do.
Responsibility: Your responsibility is what you decide.
To add structure to these characteristics, you may break them down further into primary, secondary, and tertiary roles and responsibilities.
Primary Role: Something that you do regularly and for which you are considered the owner and are held accountable for.
Secondary Role: Things that you contribute to regularly.
Tertiary Role: Things that you contribute to occasionally.
Primary Responsibilities: Those things that you regularly decide yourself. Someone else may perform analysis or make a recommendation, but you make the go/no-go decision.
Secondary Responsibilities: Those things for which you are the technical/ business leader and primary recommender, but where someone else makes the ultimate decision.
Tertiary Responsibilities: Those things for which you are on the committee making the recommendation.
Review the Project Data Sheet
If you have created a Project Data Sheet (executive summary), then review it now with the team. If a Project Data Sheet has not been created yet, then review as much information about the project as is available with the team.
* * *
Agree on the definition of “roles and responsibilities”
You may use the above definitions or modify them, but it’s important that everyone understands the final definitions.
* * *
Create individual roles and responsibilities
Have each individual document her roles and responsibilities. The project manager may want to facilitate this step with the project sponsor or other management that is not part of the working team.
* * *
Discuss and iterate
Review and discuss the individual roles and responsibilities with the entire team. Identify overlaps and gaps. Resolve overlaps and fill gaps.
* * *
Finalize
Based on the team discussion, finalize the roles and responsibilities for each team member. Write these in the roles and responsibilities section of the template.
* * *
Decisions
An up-front understanding of how decisions will be made, as well as who will make them, is critical to project agility. If all or part of this information has already been captured in the section on individual responsibilities, then it can be omitted here. Otherwise, discuss the following in the decisions section of the template.
Technical
The responsibility for technical decisions may become unclear as organizational boundaries are crossed. Clarify here if possible.
* * *
Business
Try to differentiate when a business decision can be made by the project team and when it must be brought to management outside of the project team.
* * *
Escalations
All project teams will experience conflicts and disagreements during the project. Efficiently resolving these conflicts will greatly facilitate project agility. Discuss the following in the escalations section of the template.
Sequence
Describe the specific sequence that escalations will take. Note if this sequence may change depending on the type of conflict.
* * *
Project team level
Describe any project team-level mediation process (led by the project manager) to attempt to resolve conflicts before escalating them to management.
* * *
Management level
Identify the specific managers that conflicts will be escalated to, depending on the type of conflict.
* * *
Practices
Practices are those behaviors, related to interacting and communicating with others, that individuals agree to observe for the benefit of their team members. Individuals should suggest practices for the team that would benefit themselves since those same practices will, more than likely, benefit others as well. The entire team should agree to the practice before documenting it here, otherwise it loses its effectiveness. Likewise, avoid practices that, while nice, are generally not realistic. For example, “everyone will show up for meetings on time” is a noble practice, but one that is rarely observed. If this was highlighted as a practice, individuals who show up on time may be agitated by those who do not. A better wording of the same practice might be “call the project manager on his cell phone if you will be more than five minutes late for a meeting”.
Brainstorm and discuss practices that will prove valuable with the entire team. Write these in the practices section of the Communications Plan template.
General practices
Many practices are general in nature in that they can be considered common courtesy or good corporate behavior. They may already be communicated throughout the organization. An example might be the “meeting rules” that are often posted in conference rooms. There is no need to repeat these practices in the project communications plan. They should be referenced if appropriate.
If your company has not developed any practices at the business level, then creating them initially for the project team could provide the foundation for creating company norms. In fact, developing a core group of general practices that can be leveraged across the majority of projects will prove valuable to the organization in the long run.
* * *
Project-specific practices
The most valuable practices are those that are specific to the project at hand, since these are the behaviors that may not be as obvious to the team members. For example, “SWAT team meetings will be called within four hours of receiving a level 3 customer complaint during field trials”. This practice puts key players at ease, knowing that they will be kept informed of critical field trial problems.
* * *
Project Tools
Discussing and agreeing on the tools that will be used to collaborate on the project will ensure that individuals can operate efficiently as a team. It is only necessary to discuss those tools that are used to communicate or collaborate with others. For example, it is not necessary to document a statistical analysis software package that is only used by a single person and whose results are incorporated into another report for communication to the team.
Discuss and list these tools in the project tools section of the Communications Plan template.
Project management tools
These include the software and templates used to manage the project and communicate information about the project. Examples would be the software used to create (and read) your project timeline, progress reports, action items, or project communications plan. Everyone on the team must have access to the necessary software to contribute to the project.
* * *
Professional tools
These are tools specific to the technical characteristics of the project. Examples would be the RF test suite, laboratory protocols, and design tools/software.
* * *
Collaboration tools
These are tools used for group collaboration and sharing of information. Examples would be a team Web site, shared drive, desktop videoconferencing, teleconferencing, online calendars, and Web collaboration space.
* * *
Meetings
Meetings are a primary facilitator of project communication and collaboration. It is very important to set expectations with the team regarding project meetings. Without the proper forethought, meetings can become inefficient time-wasters and thus lose much of their potential value. Some meeting characteristics worthy of discussion with the team are listed below.
List the types of project meetings and their characteristics in the meetings section of the project Communications Plan template. It is helpful to give each regular meeting a unique name to avoid confusion.
Topic and objectives
Having meetings “just to get together” is generally inefficient and can even be frustrating for participants. All meetings should have a topic of discussion, as well as objectives describing what the meeting is trying to accomplish. Having these two characteristics defined will help keep meetings on track and greatly increase efficiency.
* * *
Frequency and duration
Understanding the frequency of regular meetings helps participants gauge what needs to be discussed at a particular meeting versus the next one. Understanding the duration helps determine the agenda and level of detail around each agenda item.
* * *
Facilitator
All meetings need a facilitator or leader to be effective. Determine who will be facilitating the meeting and what that person’s responsibilities will be. The facilitator is generally the project manager, but in cases where the project manager is not an attendee, such as for a purely technical review, someone else must be designated as facilitator. Common duties of the facilitator are to create and distribute the meeting agenda and minutes. There may be other duties as well specific to the project.
* * *
Required attendees
Everyone doesn’t have to be at every meeting. In fact, requiring mass attendance when it’s not appropriate is a huge source of frustration among project teams. On the other hand, having a meeting where a key person is absent can be just as frustrating. Determine a list of required attendees for each meeting.