Project Management Communication Tools & Techniques

Communication is an essential part of project management. I have never met a successful project manager with many projects under their belt that was not a good communicator. This is due to the inherent nature of project work as compared to process work. Projects are unique one-of-a-kind set of activities. If we did exactly the same thing in every project, the same way, with the same people, and in the same sequence, then project manager communication skills would not be as important. An individual could be trained for a job, placed in it and the expectations would be clear. But project work is always different. That is why we need good communication. Those working on the project need to understand what is required on this project, when it is required, how it should be done, and what other activities it must integrate with. Without good communication, projects fall into chaos.

The methods and frequency of communicating will vary from project to project. One of the most important considerations is the project complexity. Simple projects require a minimum of communication, since it is usually a one person team and only one stakeholder involved. Focused projects require more communication planning and execution, but they typically are still relatively straight-forward since there are only a few people on the team. The project manager can often handle the communication through informal channels such as one-on-one meetings or calls to all of the team members and stakeholders. When the complexity grows to the size of Full-scale projects, the communication focus needs to shift. Now the project manager must spend dedicated time keeping everyone on the project aware of status, issues, and changes. Also, there are usually many stakeholders and stakeholder meetings on Full-scale projects. Once the complexity grows to the size of a Complex Program, the program manager is spending virtually all of his or her time doing communication and risk management. In fact, you could argue that communication IS risk management. These programs are typically managed as a portfolio of integrated sub-projects. The program manager is continuously communicating between the sub-projects to ensure they stay integrated and to guard against a problem in one sub-project cascading into all of the others.

Tools and techniques that are used by project managers to aid in communicating start with the Communications Plan. To develop a communication plan, a project manager will often do a Communication Technology Assessment. Of course, a Team List should be developed. Naturally, I recommend that when conducting a meeting - use good presentation skills, when composing a message - use good writing skills, when having a face-to-face encounter - use good interpersonal skills. However, these are not unique to projects so I am trusting you can get help on these from your Human Resources or Training department and you don't need me for that. I will stay focused on the parts of communication that are unique to project work.

The PMBOK includes Stakeholder Management activities in its communication chapter. I have placed the stakeholder management activities in Project Initiation and Project Controlling pages. Although those activities entail communicating, they are so integral to Initiating and Controlling that I felt it was better to address them in those sections.

Before I start to discuss the communicating tools, there are two topics I would like to address. The first is the understanding of a "Sender - Receiver" model. Whenever information is being communicated, it is translated from the sender's mind into a message and then from the message back into the receiver's mind. There are opportunities for misunderstanding in both translations, and for noise and errors to be introduced during the transmission of the message. That is why I believe every project leader meeds to focus on communication. Since project work is often new or unique, the chance for misunderstanding is even greater. There is no established pattern or expectation. I strongly encourage the habit of "Repeat it back." for all project communication to minimize misunderstanding.

The second is the recognition that listening is a three step process. If a team member does not seem to be listening, it is important to understand which step of the listening process is the issue. The three steps of listening are: 1) hearing, 2 understanding, and 3) judging. The Hearing step is just that. The actual receipt of the message. Team members who "aren't on the call" will not get the message. For vitual team members you may need to create special channels of communication to ensure they actually hear the message. The Understanding portion of the listening process is the team member translating the message into desired actions or changes to the project. Team members who do not understand the acronyms or whose native language is different than the normal language of project communication may hear the message that is being sent but not understand what it means. To determine if this is the problem, the project leader will need to have a directed conversation with the team member and ask them what they think the message is telling them to do. The third listening step is Judging. In this step the team member hears and understands the message and then decides whether or not they believe it applies to them and their project work. When this is the breakdown in listening the project leader will need to spend time with the project team member to determine either why the message does not apply in this special case or to explain to the team member why the message does apply to them.

Project Communication Plan

Every project manager uses a Project Communication Plan. Many project managers do not consciously develop one, instead they embrace one that has been imposed upon them from a previous project, they follow a procedure instituted by the PMO, or they conduct their communication in an ad hoc fashion. That is an approach for developing a plan - not a very good one - but an approach. I recommend that a conscious decision is made as to what communications need to occur for a successful project. I typically consider four categories of communication. All four types are not needed on every project, but they are typically found and should be planned for.

The first category I consider is management meetings. This category is often an extension of the Communication Strategy for stakeholders that I discuss in the Project Initiation page. For this category, consider which managers need or want information, the frequency they need or want it, and the content detail. Major communication sessions with stakeholders, such as technical reviews that I discuss in the Project Control page are often reflected on the project schedule as milestones and should be included in this portion of the Communication Plan. The management meetings should be planned and proper preparatin conducted. Some of these are face-to-face meetings and some are conducted using an electronic medium. A poor management meeting jeopardizes support for the project and reflects badly on the work of the project team.

The second category of meeting is the project team meetings. Depending upon the size of the project and the team, these can be short ad hoc conversations, conference call updates, email chats, formal pulse meetings, or a variety of other communication approaches. Regardless, these are where the project manager is able to track the day to day work of the project and resolve issues while they are still small.

The third category I like to consider is management reports. Many organizations require project managers to provide periodic reports for the management team. Often these are reviewed by managers who are not direct stakeholders in the project. These reports need to be able to stand alone in describing the project and its status. A project manager cannot assume the reader is familiar with the goals or risks in the project. That is why it is important to use the standard template or format the organization suggests/requires. The standard template guides those who are not familiar with the project to the areas of the project report that they are concerned with.

The final category that I consider is project records. These are the method that the project team uses to communicate to the future. Whether the future is teh business team members who use the project deliverables to implement business stategy, the next generation project, archives for litigation, or records for lessons learned, the records need to be complete enough so that whoever is reading them after the project has completed will be able to understand what has happened.

Communication Technology Assessment

The type of communication technology used by the project manager will vary based upon the organizational constraints of the project team and stakeholders. Factors that influence the technology include whether the team is co located, the confidentiality of any information that needs to be shared, communication facilities available to the team members, and the organization's culture for how meetings and disucssions are normally conducted. Some technologies lend themselves to large group interactions and others are more appropriate for one-on-one discussions. The table below provides an assessment of the advantages and disadvantages of different communication technologies for use in a project environment.

Project Team List

The Project Team List is a list or database with all project team members and their contact information. This includes the core project team members and extended team members. I typically will also include key stakeholders on this list. The list is provided to team members to aid communication. I want project team members to know who to call when they have a question or an issue arises. The list can be maintianed in as a spreadsheet, a word document, a file for your email server, a contact list in your project eroom, or any other mechanism that is a normal resource contact management system in your organization. One caution about the list, I provide business contact information, but not personal information. In this era of identity theft and the increase of "creepy people" I try to protect the team member's privacy as much as possible.

Project Management Initiating Tools & Techniques

Project Initiation is the process or activities associated with defining the boundaries of a project, or project phase, and gaining the approval of appropriate stakeholders to begin the work of project planning and project execution. Project initiation is always company-specific. While many of the tools of project planning or project control are standard and universal, the initiating tools must interact with the company's business environment and strategy planning process, and therefore are far less formal or deterministic. The project objectives, which form the basis for project boundaries, are directly related to the business strategic imperatives. These are different from business to business and they change over time. The stakeholder analysis involved in approving a project are based upon a combination of the business organizational structure and the personalities of the individuals involved.

The Project Management Institute identifies several outputs from the Initiating processes. These are the Project Charter, a Project Stakeholder Register, and a Stakeholder Management Strategy. On small or simple projects I recommend that these all be rolled into one document. On larger more complex projects, I suggest that two deliverables are created during project initiation, a Project Charter and a Stakeholder Register that incorporates the stakeholder strategy decisions. I use a variety of tools and techniques to create these documents, depending upon project complexity and uncertainty. These include: W's, In-Frame/Out-of-Frame, Project Dimensions, Project Requirements Document, Communication Strategy Matrix, and Collaboration Strategy Matrix. The project leader needs to determine which of these tools and techniques are appropriate for their project. Typically only two or three of them are used. The project leader should always follow corporate policies and directives with regards to required tools or techniques. In addition, unique characteristics of the project may require different tools.

Project Charter 

The Project Charter documents the basic attributes of the project, essentially the project boundaries. As such it captures the understanding of the project by the project sponsors and senior management at the time they approve the project to go forward into a planning phase. The charter is not an in-depth project plan. It is a high-level document. It describes the expectations of the customers of the project and the senior management for the project results. A charter is normally developed by the portion of the business that is sponsoring the project, not the project team. On small projects the charter may only be a one-page document. On larger projects, the charter may require many pages.

A project team uses the charter document to assist in the planning process. The team attempts to develop a project plan that has a strong potential of achieving the project objective while staying within the project schedule and budget boundaries found in the charter. An example of a Project Charter format that I have used on small projects with several clients is shown.

Stakeholder Register 

The Stakeholder Register documents the stakeholder planning process. It is often started during the initiating process. However, this is a living document. While created during the initiating process, it is continuously updated throughout the life of the project. During the project new stakeholders are often identified and the role or interest of stakeholders may change due to changes in business priorities or reorganizations. The Stakeholder Register tracks these changes and guides the project leader in making decisions with respect to stakeholder interaction planning.

A project leader uses the Stakeholder Register to guide elements of the Project Communication Plan. In addition, project risks, reviews and decision meetings are often structured based upon the strategies documented in the Stakeholder Register. Further, the project attributes associated with the stakeholder's "Wins" will inevitably become linked to entries on the Risk Register.

W's

The "W's" are one of the simplest methods for identifying the boundary conditions for a project. This technique is often used with small projects. It consists of discussing with the sponsor the answers to several questions that have a "W" in them. These questions can be asked in any order.
"What?" What is the project intended to do or deliver?
"Who?" Who is the primary customer and are there any other key stakeholders?
"When?" When does the project need to end? When does it need to start?
"Where?" Where will the project activity be conducted?
"Why?" Why is this project needed? Is it related to a specific business strategy or goal?
"How?" How should this project be accomplished? Are there any constraints on the approach, any procedures or regulatory guidance that must be followed, or any financial or resource constraints? (The "w" was on the end of "How")

In-Frame/Out-of-Frame 

The "In-Frame/Out-of-Frame" analysis is an excellent technique for clarifying project boundary conditions with stakeholders who are vague or often change their mind. An effective use of this technique at the beginning of a project will significantly decrease the incidents of scope creep. This technique identifies all of the major elements that are to be accomplished and puts them "In the Frame." It also lists activities, analysis and work that, though potentially related to the project, is not requested or required by the stakeholders. These items are listed as "Out of the Frame." An important clarification is that the "Out of Frame" items are not itmes being withheld from the stakeholders, rather there is an agreement with the stakeholders not to expend project time and project money on those items.

The "In-Frame/Out-of-Frame" analysis assists the project team in setting a clear definition of scope. Often there are several possible interpretations of a project requirement. This analysis clarifies the interpretation. This analysis minimizes the likelihood of scope creep because it forces the stakeholder to clarify the boundary of acceptable performance. Many instances of scope creep are due to stakeholders asking for "just one more thing." This analysis defines the limits of what can be done with the available time and money in the project. If at the time of project initiation the "In the Frame" list is more extensive than the desired end date or budget can reasonably be expected to deliver, the discussion with the stakeholder occurs at that time to either limit the project scope or increase time and/or money.

Project Dimensions 

Karl Wiegers introduced the concept of categorizing the various project requirements into different "dimensions." These dimensions are related to the criticality of the requirements. This tool is useful on larger, more complex projects and programs. When discussing with stakeholders the nature of their requirements, determine how strategically important each requirement is. Some requirements are "Constraints." There is no flexibility with respect to these requirements. If this requirements cannot be met, the project is canceled. Very few requirements are truly in this category. For these requirements, the project plan should be constructed to minimize risk in those areas. The next category of requirements is "Drivers." These requirements are often expressed by stakeholders in terms such as, "As much as ..." or "As soon as ...." These requirements should be optimized to achieve the best overall mix among them. If you have many stakeholders, this may prove to be difficult as some stakeholders will probably need to compromise on there preferred solution or actions in order to accommodate some others. The final category is "Degrees of Freedom." These are items that are not requirements in the minds of any stakeholders, yet are elements of the project that must be accomplished in order to complete the project. Since there are no stakeholder imperatives with respect to these requirements, these are the areas where the project team should be the most creative and take the most risk. When completing a Project Dimensiopns I normally use a spreadsheet to capture the items. There are often more than one hundred items between all of the categories.

Project Requirements Document

A Requirements Document is a formal document that describes all of the requirements for a project. It is most commonly used in government contracting or large commercial construction projects and programs. This document is prepared by the buying organization in order for sellers to fully understand all requirements of a project when they prepare to bid on the project or portions of the project. When a government agency determines that it will source a major project effort, the agency develops the requirements document. The document contains all of the technical and managerial requirements appropriate for the government agency and the type of project work. The document can easily be hundreds of pages in length.

Communication Strategy Matrix 

The Communication Strategy Matrix is a tool for determining the communication strategy to be used with each stakeholder. On a small project with one or two stakeholders, the matrix guides the project leader to determine the specific communication techniques to be used with those stakeholders. On larger projects with many stakeholders, the communication strategy for each stakeholder is a major input used when developing the project communication plan.

Each stakeholder is considered individually. The stakeholder is placed in one of the four quadrants of the matrix. Based upon the quadrant, the communication strategy for that stakeholder is set. One caution with this technique, a stakeholder's oversight or interest may change as the project moves from one phase to another or as business conditions change. Therefore, the stakeholder's position within the matrix should be periodically reviewed and updated.

Collaboration Strategy Matrix 

The Collaboration Strategy Matrix is a tool for determining the type of collaboration that must be done with each stakeholder. Collaboration in this context implies that the stakeholder must be involved in the activities and decisions of a portion of the project. On a small project with only one or two stakeholders, the matrix guides the project leader in determining the level of involvement required from the stakeholder. On larger projects with many stakeholders, the collaboration strategy drives decisions on project planning and on project review meetings.

Each stakeholder is considered individually. The stakeholder is placed in one of the four quadrants of the matrix. Based upon the quadrant, the collaboration strategy for that stakeholder is determined. The selected strategy indicates the level of involvement by that stakeholder in decision-making, both during planning and execution phases of the project. The more stakeholders involved, the more project management effort required to manage the relationships and interactions with stakeholders.