|
|
|
|
|
4.3T Manage Communication / Techniques
Practice Meeting Fundamentals (4.3T.P1)
In general, all meetings should have an agenda. The creation of the agenda takes a little extra work, but it can be as simple as writing it in an email and sending it to the meeting participants.
Regularly scheduled, ongoing status meetings do not necessarily need a published agenda every week if they stick to the same agenda format. In those cases, the formal agenda is of most value while the team is first meeting. Once everyone understands the purpose and the regular flow, the standard agenda model can be reused every time.
Other meeting considerations include:
-
If you have a large group of people attending the meetings, there should be a meeting facilitator, although the role can be rotated for regularly scheduled meetings. This is usually the person who requested the meeting unless other arrangements have been made. For ongoing status meetings, the facilitator is usually the project manager.
-
Make sure the participants know ahead of time of anything they need to bring to the meeting or any advance preparation that needs to take place.
-
Only invite the people that need to be there. Others may dilute the effectiveness of the meeting.
-
The meeting should start on time, with some allowance for those that may be coming from another meeting.
-
The person who requested the meeting should explain the purpose and the expected outcome.
-
The facilitator needs to follow the agenda and watch the time to make sure everything gets covered.
-
Someone should document any action items assigned during the meeting. This will be the facilitator or originator unless other arrangements have been made. This person is sometimes called a “scribe”.
-
The scribe should recap all outstanding action items toward the end of the meeting, including who is responsible, what is expected, and when the action item is due.
-
The scribe or facilitator should recap any decisions that were made and document them in an email (or other project communication mode as appropriate).
Keep Status Meetings Focused (4.3T.P2)
There is always a temptation to engage in problem solving when you have all the key people together at one time. However, the concern about problem solving is that usually only a few people are engaged in any one problem, while everyone else is unengaged and wasting time. While you have everyone together, use the time to discuss general status, issues, scope and risk. These are all features of overall project health and should be of interest to all team members. There can certainly be some problem solving if there is time on the agenda, but the facilitator should make sure that the problems are of interest to most of the team members.
A common complaint in status meetings is that they take too long. Some projects have status meetings that last two hours and longer. These long meetings are usually caused by too much problem solving that is not relevant to all of the meeting participants. The best way to focus status meetings that are too long is to simply reduce the time allocated to the meeting. For instance, if you meet for two hours per week and find that you cannot complete all your work, try reducing the time of the meetings to 90 or 60 minutes. Keep the status meetings short with a tight agenda to be most effective. Take any lengthy discussions offline or to a separate meeting that focuses on these items with the people that are most interested.
Use Standardized Reports to Report Status (4.3T.P3)
You should avoid creating individualized reports for each person who needs information. Most people need only a standard set of information that can be communicated in a common project Status Report. If there is a need for information in addition to the standard status report, you can create an additional standard report to provide the information. For instance, you may create a detailed Status Report on a weekly basis and a summary Status Report on a monthly basis. This is fine. One report may not serve the needs of all stakeholders. However, even if you have multiple reports, they should all be based on standard templates. You should minimize ad-hoc status reporting requests as much as possible. They take extra time and usually provide only marginal value over the standard report templates that are already available for you.
Ask for Team Status Reports on a “Frequent Enough” Basis (4.3T.P4)
The frequency of status reporting is based on the length of the project and the speed in which you need to react. For instance, if your project is two months long and the project manager receives Status Reports from the team members on a monthly basis, there is not enough time to respond if problems are reported. A good rule of thumb is as follows:
-
Small projects may not need formal status reporting.
-
Team members on medium projects should report status every week.
-
Team members on large projects should report status every week or perhaps every two weeks.
Status updates are also somewhat situational. For instance, if critical activities are occurring, you may need status updates on a daily basis. This may be the case around implementation time when a lot of work needs to converge in the final days of the project.
Include Information of Value in Status Reports – Not the Mundane (4.3T.P5)

Let’s face it: Status Reports are typically not as effective as they should be. This is true for team members that submit Status Reports to the project manager, as well as project managers that are submitting Status Reports to their major stakeholders. One of the major reasons is that the people completing the reports look upon them as a chore and not as a way to communicate valuable information. You typically get a Status Report that is very brief and says nothing, or else you get a Status Report that contains all the mundane activities that a person did.
The person creating the Status Reports needs to write it so that the reader can use the information in them in the decision-making process. The information needs to be of value. The writer should ask himself whether the information on the Status Report is there to really communicate something valuable or is it just taking up space.
Typically the Status Report should focus on the following:
-
Accomplishments against the assigned activities on the schedule
-
Comments on work that should be completed but is behind schedule
-
Problems (issues) encountered, the impact to the project, and what is being done to resolve them
-
Scope change requests
-
Newly identified risks
-
Observations that will be useful to the reader
If you focus on this type of information in your Status Report, you will find that the information is meaningful and can be used to help manage the project and keep the stakeholders informed. People will stop paying attention if you report on the trivial events of the reporting period.
Use Appendices for the Details (4.3T.P6)
You want to focus on meaningful information in the status report. However, you may find that some of your audience finds meaning in the exceptions while others find meaning in the details.
Does that mean you need to create two status reports? You should not need to. One of the ways to satisfy both audiences is to write the formal Status Report as an exception-based document and include the details as appendices (attachments). For instance, most readers want to know the accomplishments from the prior period and the planned accomplishments for the next period. However, your manager might want to see the entire schedule. To satisfy both, just include the schedule as an appendix. If you are emailing the information, you could email the current schedule as a separate document from the basic Status Report.
A similar example is a situation where you note an accomplishment about completing a significant amount of training. Your client might want to see the names of the people trained. Again, do not include this level of detail in the body of the report. Include the information in an appendix instead.
Report Less Detail as you get Higher in the Organization (4.3T.P7)
If you create a Communications Plan for your project, the needs of all your stakeholders will be analyzed formally. But even without a formal Communications Plan, always keep the organizational level of your audience in mind. The organization level helps you determine the level of detail that is required in the Status Report.
For instance, your team members need information that is highly detailed and highly specific to the work they are assigned. As the project manager, you need information that covers the entire project but at a less detailed level. The manager of the project manager needs to have information summarized and delivered at a higher level. The next higher manager needs information at a higher level still. Although your project is the most important thing on your mind, to senior management it may just be one of a number of important events they are trying to keep track of.
In some organizations, this filtering is a part of the communication system. For instance, you may give a Status Report to your manager. Your manager receives your status, as well as from the other people that report to him or her. Your manager then summarizes and consolidates the information and passes a higher-level report to his manager. That manager in turn does the same thing until only very high-level information reaches the top. Therefore, senior management may just get a one-line status update on your project. In fact, if your project is on track, it may not even be mentioned at the executive level.
In other organizations, however, the status information is not summarized and passed upward. The project manager is the one that needs to communicate with multiple management levels. In that case, remember that one size of communication does not fit all. You may need to modify the communication content to each level of management. For instance, you may send a one-page report to your direct manager and your major clients showing the project status and financial situation. This may be summarized to a half-page for the next level of management and to perhaps a paragraph to the next level.
Use the Best Communication Media (4.3T.P8)
When you select the various types of communication that you need for your project, also determine the best medium for delivering the information. For instance:
-
Status Reports. These do not have to be on paper. Depending on the person sending and receiving the information, the status can be communicated via voicemail, email, videoconference or other collaborative tools. Your organization may have a standard way of delivering status. If not, pick a manner of reporting that is convenient for the reader without compromising the value of the information.
-
Email. Use email for routine messages, information sharing and some marketing related messages. Spread these out so that you don’t inundate the same people over a short period of time.
-
Voicemail. Use voicemail to leave simple messages to individual people or to entire departments. Complicated or long messages are not appropriate for voicemails.
Don’t “Shoot the Messenger” that Brings Bad News (4.3T.P9)
you have all heard this saying (or something similar). It means that you should not take retribution against the person (or people) that deliver bad news. If you ask people for a status, accept the good and the bad for what it is – information for you to make better decisions. If you want people to tell you when there are problems, you need to accept the information and work with the team on causes and solutions (hopefully the team member is proposing solutions along with the problem).
All project managers need to take this message to heart. You want to hear bad news as quickly as possible so that you have a chance to respond quickly. Issues and risks that are surfaced early allow for much more flexibility in the response. you have much less flexibility to operate if you hear about them at the last minute. However, if people bring bad news to you and you respond negatively toward the person bringing the news, it will make it much harder for other “messengers” to come forward with bad news in the future.
Use Green / Yellow / Red Indicators to Represent Overall Project Health (4.3T.P10)
One good technique for providing an overall summary of a project is to include a green / yellow / red indicator. Just as you would expect, a green indicator means that the project is basically on track. It does not imply that there are no problems at all. But it does mean that all problems are being addressed and the project is basically on time and on budget.
A summary indicator of yellow means that there is some risk that the project will not meet its budget or deadline. Placing a yellow status indicator on the project is a way to manage expectations and let people know the project is at some risk.
If your project has an indicator of red, you are telling people you are definitely in trouble, and will need to compromise on budget, deadline and / or quality.
The real value of this indicator occurs when the project status is summarized for upper management. If senior management has a summary page of all projects, as well as a green / yellow / red indicator, they can easily see the overall status of the entire portfolio. If they manage by exception, they would immediately focus on those projects that are red and yellow.
Communicate Proactively to Manage Expectations (6.2.P11)
One of the main purposes of managing communication on a project is to manage expectations. Status Reports, for instance, are a way of communicating to stakeholders how the project is progressing against its schedule and budget. You include information on issues, scope change, risks, etc., as a part of providing information to manage expectations. Additional information on managing client expectations is discussed in detail at 3.2.3.1P Managing Stakeholder Expectations.
Place Communication Events on Your Schedule (4.3T.P12)
The project manager should treat communication events like any project deliverable. You should add the activities to the schedule and assign people and end-dates so that the team understands when the communication is expected and who is responsible for creating and delivering it.
Your schedule should include the due dates for your Status Report to stakeholders, as well as the Status Reports you expect from your staff. You should include activities in your schedule for all your status meetings, sponsor meetings, steering committee meetings and any other scheduled meetings. Likewise, if you are creating other items like a project newsletter, add activities specifying when input is due and when the newsletter will go out. If you are not very specific on expectations and due dates, you will find these communication instances starting to slide. For instance, you may find your quarterly newsletter is distributed six weeks late and then you may decide to skip next quarter since it is too close to the last one.
Use Project “Branding” Concepts for Culture Change Projects (4.3T.P13)
Most projects don’t have to worry about branding. Their scope is limited to a small set of people and the impact of the project on the organization is modest. However, some projects will affect an entire organization or company, and may take years to implement fully. These are the types of projects where it makes sense to build a positive image and associated good feelings. They are candidates for branding. See 2.3.5T Branding a Project for more information.



