Summary


To organize for agility, you need to assemble a cross-functional project team and establish project leadership, define the team's roles and responsibilities, and relearn how to hold effective project team meetings. Here are some key points to remember:

Cross-Functional Team Leadership

  1. Team leadership can be ambiguous if not addressed directly.

  2. The project manager must show his unique value-added to the team in the leadership area.

  3. Core team members need to support the support team members.

Roles and Responsibilities

  1. In the agile environment, roles and responsibilities are defined by expertise and desire.

  2. The boundaries defined by an individual's role are permeable and should encourage others to cross those boundaries and become involved.

  3. Individuals need to learn to cross boundaries in order to solve multidimensional problems that have never been encountered before.

  4. Your role is what you do.

  5. Your responsibility is what you decide.

  6. In agile environments, decision making is decentralized.

Meetings

  1. The number/frequency of meetings is proportional to the level of uncertainty. Generally, projects requiring agility will require more meetings.

  2. People are generally part of several project teams simultaneously—we need to respect their limited time during meetings.

  3. Meetings can be made more effective by identifying required and optional attendees, and letting them know what's expected of them so that they come prepared.

  4. Project managers need to change perceptions about meetings so they can become a valuable and agile communication channel for project information.

Communications Plan Workflow

This section describes how to use the sample template when creating an actual project communications plan. It will guide you through a process that's meant to help you head off common miscommunications and facilitate the agility of your project team.

The communications plan template is designed so that individual sections can be easily included or removed from the final output. Also, there are many different types of projects, and one process definitely does not fit them all. You are encouraged to customize this process where applicable by modifying or adding sections.

An electronic copy of this workflow can be downloaded from http://www.xocp.com.

Identify the Project Team

Uniquely identifying the project team is a good first step toward eliminating confusion and setting project accountability.

Project Manager

This is the person responsible for managing the overall project.


Project Sponsor

This is the primary person who wants the project done and who is authorizing that resources be expended to complete it.


Team Members

These are the people who are contributing to the project. If appropriate, you may want to include a specific organization or functional area that the team member is representing on this project team.


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.


Optional attendees

Some team members may want to attend certain meetings based on their availability at a specific time and the specific agenda topics. Other team members, and often management, like to be kept abreast of team progress by reading meeting agendas and minutes, even if they never attend. These individuals should be put on a distribution list for the meetings they may attend at their discretion.
Note: Required attendees should not be listed as optional, as this will decrease meeting effectiveness.


Individual Status Reporting

Synchronizing the many individual tasks into a cohesive project is a core value-add of project management. Likewise, repeatedly chasing down people for status reports is one of its frustrations. Avoid the aggravation associated with collecting individual status reports by agreeing up-front how reporting will be done. Status reporting can be formal or informal, and it may vary from individual to individual, depending on their particular role. Some common dimensions of individual status reporting to consider are listed below.

List how various types of status will be reported to the project manager and team in the individual status reporting section of the project Communications Plan template.

Type of status

Three primary project elements are of concern here: tasks (line items on the timeline), action items (activities that get assigned at meetings), and issues (problems with no immediately apparent solution). You may decide to handle these all the same way or uniquely, depending on your situation.


Audience

Determine who will receive the various status reports.


Format

The format of the status report has a great influence on project efficiency. Determine if status reports will be delivered verbally, via e-mail, or using a predefined template, an online tool, or manual markup of a printed task list, etc.


Frequency and timing

Determine how often status needs to be reported and when.


Project Status Reporting

Keeping the project sponsor and other management apprised of overall project status is also a fundamental of good project management. Some dimensions of project status reporting to consider are listed below.

List how the project's status will be reported to the project sponsor and management in the project status reporting section of the project Communications Plan template.

Team representative

Determine who will deliver the status report. This is usually the project manager, but other core team members may need to address specific topics.


Audience

Determine who needs to receive status reports and if the same information is appropriate for all recipients.


Format

Determine the format for presenting status information. A predefined template is usually an efficient way to do this. See the Project Status Reporting workflow and template in Appendix A for a detailed example of a project reporting format.


Frequency and timing

Determine how often status needs to be reported and when.


Change Approval and Notification

Approving and communicating substantial changes to the project's scope, schedule, or resources is critical to achieving project objectives. This is even more relevant in an agile environment of frequent change. If possible, avoid having a single person or committee to approve all project changes, as this will only hinder the team's agility. Some elements to consider are listed below.

List how substantial changes to the project will be approved and communicated to the rest of the team in the change approval and notification section of the Communications Plan template.

Substantial

Determine some guidelines for assessing whether a particular change is "substantial" and thus warrants an official approval and notification. Minor changes should be exempt from this process.


Approvers

Determine who can approve the various types of changes.


Notification

Determine how changes will be communicated and to whom.


Template for Building a Communications Plan

(Project Name) Communications Plan
The project team:
Project manager: name of person
Project sponsor: name of person
Project team: names of team member 1, team member 2, team member 3,


Team roles and responsibilities:
Describe the roles and responsibilities for each member of the team.
Project manager:


Project sponsor:


Team member 1:


Team member 2:


Team member n:


Decisions:
Describe how key project decisions will be made and who will make them. This section may be omitted if covered in the roles and responsibilities section.


Escalations:
Describe the process of resolving conflicts through escalation.


Practices:
Describe any organizational practices that the team agrees to observe during the project.


Project tools:
Describe any specific software or technology that will be used to manage the project and which team members should have access to it.


Meetings:
Describe the various types of meetings that will be held during the project, including meeting objectives, duration, frequency, facilitators, attendees, and any other critical characteristics.


Individual status reporting:
Describe how individual team members will keep the team informed of their progress on assigned tasks, action items, issues, etc.


Project status reporting:
Describe how the team will keep the project sponsor and other members of management informed of its progress on the overall project.


Change approval and notification:
Describe how changes to the project definition or plan will be approved and communicated to the appropriate people.


Change History

Date:

Description of change:


Today's date

As issued





Agile Project Management(c) How to Succeed in the Face of Changing Project Requirements
Agile Project Management: How to Succeed in the Face of Changing Project Requirements
ISBN: 0814471765
EAN: 2147483647
Year: 2006
Pages: 96
Authors: Gary Chin

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net