* * *
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
* * *
Chapter 5: The Project Manager’s Role
Successfully managing projects in an agile environment is no easy task. It requires a rare combination of skills and characteristics. You will need to connect with your technical team, organize them, and drive the project forward. At the same time, you will need to allow for and guide the inevitable course changes, while keeping the project aligned with the overall business objectives. You will be challenged to balance the desire for measurable progress against the creative needs of your team and the generally iterative nature of agile PM. And you will need to do all of this while establishing and maintaining credibility with a team, where you may not be the ultimate subject matter expert. This chapter explores some of the agile PM concepts that will aid the project manager in performing these duties.
Taking an Outward Perspective
The agile project manager will take more of an outward-facing perspective versus a solely inward one (see Figure 5-1). Classic PM teaches you to focus on the project plan as your primary tool to execute and complete the project. The plan generally focuses on three key project dimensions—schedule, scope, and resource estimates—and, to be successful, the project manager must be given some reasonable level of formal authority over the plan, as well as the project team. A common mantra is to bring the project scope in on schedule and under cost. This inward-looking perspective tends to promote a static view of the project dimensions. Since the sponsor, project manager, and team agree to a project definition and plan up-front, the perceived success or failure of the project is often based more on variation from this plan, rather than the achievement of real business objectives. If you are operating in a mature and fairly predictable project environment, then this approach works pretty well, since it emphasizes the organization and discipline necessary for success in this paradigm—when the project dimensions remain relatively stable throughout the project. However, in the uncertain environment of agile PM, we would be naïve if we did not expect changes to the project plan on several occasions, certainly much more than in a mature project environment.
Figure 5-1: The project manager’s orientation in an agile versus classic environment.
Attempts to employ a strong inward-focused project management mentality in an agile environment often end up with one of three results. First, as the project progresses, it will inevitably take a few turns that were not accounted for in the original plan. If the project manager maintains an inward-facing perspective and subscribes to the notion that project performance is based on the team’s ability to deliver what they signed up for (i.e., the original plan), then he will spend a good portion of his time analyzing and documenting these variations from the original plan. As the zigs start to mount where the plan called for a zag, the project manager will soon be consumed with tracking, analyzing, and documenting ever more complex variations. When this happens, the project manager reduces himself to what is essentially an administrative support role. While it is certainly smart to understand why your project is off its planned course, as project manager you need to keep your eye on accomplishing your project objective—not on excessive paperwork.
Second, if the project manager is strong enough and has solid support from management, he can develop into a dreaded taskmaster—someone who is constantly on the team members to get tasks done on time and perhaps ahead of time (if he’s really aggressive). From the team-building perspective, I don’t think that this ever goes over well. In extreme cases, it can end up destroying the project. From a strict, project-efficiency perspective, this approach may work in the very predictable project environment, where the tasks are fairly rote and there’s not much chance for deviation from the plan. However, as in the other examples that we’ve discussed, this method is unlikely to be successful when iteration and multiple paths are required to reach the final destination. Project managers taking this tact in an agile environment will be showing the team that they really don’t understand how to manage agile projects, which leads us to the next scenario.