Chapter 2 - Planning Project Communication IN THIS CHAPTER Struggling with Proper Project Communication Planning Preventing Common Communication Problems Creating a Project Communication Plan Understanding the Circle-of-Communications chart Defining the Project Communication Requirements Matrix Understanding the Role Report Matrix Developing Lessons-Learned Information Project communication planning involves identifying your customer's information requirements. Customers require information about the project, such as risk events, budget data, and schedule information, to name a few. As project manager, you must be proactive and plan for your customer's needs throughout the life of the project. As you progress through the project, be aware that those needs will change and that you will need to adapt and change depending on the needs of your customers, clients, or leadership team. Most large companies have project management organizations PMOs) or project management groups that set standard requirements for company projects. These standards include areas such as scheduling when to send status reports, capturing data for budgets, creating templates for risk and issue tracking, and formatting for the monthly newsletters. For example, one common standard that PMOs set is the day that project teams are required to send status reports. Typically, the data collection is due by the end of the workday on Thursday so that the status report can be compiled and sent on Friday. Most companies want project status reports due on Friday. One important task of communication planning is deciding who produces the project information and how they will do it. Oftentimes, the project manager and his or her team members jointly produce project information for the customer. Occasionally, a project team lead must create project information specifically for a particular customer. For example, in a software project, a development lead will create a report that lists all of the bugs in the development phase. Capturing the specifics of who is responsible for creating project information is important. It is also important to let the team know which tools they are responsible for creating. That way, you reduce confusion and any possible rework for the team members. This is a best practice for any project manager and helps ensure that everyone is on the same page. To do so, you can use a tool called the project communications tools RACI. For more information, see Figure 2.3 - Project Communications Tools RACI in this chapter. Struggling with Proper Project Communication Planning Project managers often struggle to communicate their project information effectively. They often send too many reports and produce status information that makes little sense or doesn't provide value. Communication planning can be difficult. Understanding your customer's or client's information needs can be challenging. It takes years to become an effective communicator and hours of practicing and working with customers to understand their communication needs. Most project managers either ignore or struggle to properly perform project communication planning. The following list explores some of the common reasons this occurs: o Bringing together the various parties involved in the project is challenging. These parties include you as the project manager, team members, customers or clients, and any other stakeholders. Bringing everyone together is difficult. Everyone is busy working on many different activities; some team members work offsite or in a different country and are not easily available. However, to have a fully documented project communication plan, you need as many people involved as possible for the best chance of success. o Project managers and team members have been communicating all their lives. Most project managers, therefore, wrongly assume that they can communicate project information just as naturally as they communicate any other information. Don't avoid or ignore the communication planning techniques. Recognize that effective project communication is one of your highest priorities so that you will be an effective communicator for your project team members or your customers. o Project managers often fail to plan project communication requirements by not allotting the proper time to effectively understand and document the communication needs of their customers. Oftentimes, the project manager feels forced to start the project sooner, or has higher priorities, such as deciding a budget or finding team members. The task of identifying the project's communication requirements becomes overlooked or not addressed. Due to this pressure, most project managers usually complete just the planning task, and then dive right into the details of the project. This is a bad practice. In the end, this lack of planning negatively impacts the project. Some project managers have no idea how to create a communication plan. This is often because they do not have the proper training or experience on this subject. From the beginning, the project manager struggles to start the process of creating the communication plan. The techniques in this section will help you and your project team members create a communication plan. We will also cover the basics of how to present project information and be an effective communicator. Project managers who don't plan their project communications may find themselves in a tough situation when trying to communicate project status. Without up-front communication planning, the project manager or their team members lack a full understanding of their customer's requirements. The project manager and customers may have different ideas about how the project team will communicate project information. This leads to a communication breakdown, which could lead to project failure. To be successful at planning your project's communications tools, there is a common approach that has proven to be effective. One best practice is to look at your projects from the knowledge area perspective. For example, \"cost management is important in my project because I have a tight budget.\" Using this knowledge area approach, the focus is to use the different communication tools under the Cost Management knowledge area specifically for this project. Make sense? By using this approach and focusing on which tools are in each knowledge area, you ensure the best chance of communicating effectively across each of the areas in your project. This is a different approach to tackling your project, but one that will increase your chance of success. Closely consider the different knowledge areas especially those that are most impactful to your projects (for example, Cost Management). Let's look at Figure 2.1 Communication Tools by Knowledge Areas chart for the mapping between tools and knowledge areas for every project. Remember, projects usually touch on each knowledge area, so you will use some of the communication tools. You won't use all of them, but you need to at least consider which ones you will use for your project. This chart gives you an early start in helping you understand which tools to use for each knowledge area. Go over the tools for the different knowledge areas with your team members and customers to select the set of tools that you will use on the project. After you've selected the tools, you can add them to the Project Communication Tools RACI, seen in Figure 2.3 - Project Communications Tools RACI later in this chapter. Figure 2.1 Communication Tools by PMI Knowledge Areas Now, let's look at the same communication tools by pivoting on the process groups instead of the knowledge areas. The idea remains the same, you need to consider which communication tools you and your team will use during each life cycle processjust as you do for each knowledge area. For example, which tools should you use during the Initiation process and which tools should you use during the Planning process, and so on? Every project proceeds through each life cycle process (rarely are there exceptions!); therefore, you need to determine which communication tools are most applicable for each. Figure 2.2 Communication Tools by PMI Process Group Processes chart maps the communication tools to process groups. It looks similar to the knowledge area mapping chart, but this one includes life cycles processesnot the knowledge areas. As you did with the knowledge areas, it is important that you consider which communication tools to use during each life cycle process. This chart will help you with that process. Figure 2.2 Communication Tools by PMI Process Group Process This chart is pretty clear, isn't it? It shows the life cycle process that every project follows and the different communication tools for each process. It is the same mapping that we used for knowledge areas (shown previously). From a communications planning perspective, these charts show you which tools you should be using to communicate project information. This chart shows the best possible process area for the different communication tools, but that is not to say it is the only place the tool can be mapped. Some tools could be mapped across many different processes. You might have your own opinion about where a particular tool should fall, and that's fine, it shows that you understand the importance of project communication tools and how they are used in each process area. You are on your way toward understanding which tools you can use for each process area. We recommend that you print the chart so that you can continually reference it when you have an issue and need a communication tool for your project. For the best chance of success on your projects, approach your project communication planning with the life cycle tool mapping concepts in mind (knowledge areas and process groups). Your project manager peers may struggle because they haven't thought about looking at their projects in this manner, and therefore they have no idea how to communicate effectively in the various stages of their projects. After you review the communication tools in the various knowledge areas and life cycle process charts, you are ready to start the next important step on your project, deciding with your project team and customers which tools to you use for your project. More importantly, you also need to decide who will create the tools. Remember, when adding work for a team member, you will need to add the additional time in the schedule for the team member doing the work. To document the added workload, use the Project Communications Tools RACI. Figure 2.3 Project Communication Tools RACI shows an example of this tool. This will come in very handy for you and your team members to document who is building what tools for the project. This tool documents the different types of reports for the project, by category (administrative reports, requirement reports, and technical reports) and stores the name of the report in the associated category. The tool also stores the project role associated with creating the communication tool across the top of the table. It is important to store the name of the individual and the role. This tool works exactly like a project RACI, you place the A's, R's, C's, and so on in the associated intersecting cell between the role and the communication tool. This is the same process as using the standard project RACI you use today. So, \"accountable\" is \"accountable,\" \"responsible\" is \"responsible,\" and so on. Some skeptics will immediately ask you, why do I need another tool? Can't I just add these to the project RACI I am already using? The answer is yes, you certainly can, but if you want a cleaner and more concise communication tool that focuses just on the project's communications tools, then add those tools to the RACI. In some cases, there may be some duplicate entries between the project RACI and this tool; however, that will be minimal and does not devalue the use of this tool. You can easily copy and paste between the Project Communication Tools RACI and the formal project RACI. Let's look at the tool now. You will quickly see how easy it is to create for your project. Think about how valuable it will be to have a conversation with your customers or clients using the completed Project Communication Tools RACIespecially when you are trying to communicate which tools you will use on the project. This is a great communication tool for all projects and an extremely valuable tool for you to help drive your communication planning. Figure 2.3 Project Communication Tool RACI You should take advantage of this communication tool on all your projects. Project communication planning is a relatively new concept in the project management industry, but one that will change the way you manage projects forever. The project's success can depend on how well you embrace project communication planning and how willing you are to take a chance on doing things a bit differently than you have in the past. A tool like the Project Communication Tool RACI will help you move forward and will let you focus on project communications from the very start of the project. Preventing Common Communication Problems Communication problems occur throughout a project's life cycle. These problems include anything and can have a large impact on the project. The following common communication techniques can help you be successful on your projects. o Hold weekly, in-person status meetings with key project customers to establish a rhythm of project communications. Regular project communication creates confidence by showing your customers that you are in charge of their project and watching it closely. Some project managers never spend any time with their customers, so when issues and concerns arise, they have no relationships to fall back on. Take the time to work closely with your customers to form a good working relationship; these relationships can last forever. o Establish a cadence for delivering project status reports on the same day, at the same time. In doing so, you build yet another level of confidence and trust with your customer by showing them that you can deliver the information on time and on a regular basis. Customers will come to expect that reporting cadence from you and will appreciate receiving the information on a consistent basis. Your customers will feel like they can rely on you, which makes for a great relationship. o Disperse status reports and meeting agendas prior to the day of the meetinga best practice is one day ahead. You should allow enough time for your customers or leadership team to absorb the information before the actual meeting. By doing so, you allow everyone to prepare for the meeting. If anyone is required to bring additional information, or talk about a particular subject, you've taken the surprise out of the meeting by allowing them to prepare ahead of time. This technique helps speed up the meeting because attendees have had the opportunity to review the material ahead of time; less important items can be discussed briefly and the meeting can move to other agenda items. o Follow up with attendees after a status meeting by asking questions, sending meeting minutes, and being available. If questions arise, be sure to respond in a timely manner. Doing so goes a long way in great project communication, and your customers will appreciate it! o Create a project communication control room and assign team members for the duration of the project, especially for large projects. Large construction projects or high profile projects, for example, often use communication control rooms for standard operating procedures. Large projects typically have the time, budget, and complexity to establish project communication control rooms because of the critical role project communications plays. The control room is the central communication room for displaying and discussing project information, in addition to being the area where the press or outside agencies can gather project information. o Use the two-question technique (for small stakeholder groups only). After reading the status report, project customers or stakeholders bring two questions to the meeting. This is a fun way to get the stakeholders engaged in the project and ensures that they read the status report. Creating a Project Communication Plan A project communication plan is the document that defines the process and procedures involved with communicating project information. The communication plan outlines the process for managing the project information and distributing the information to the project stakeholders. Contrary to popular belief, the communication plan does not communicate project information; it simply outlines the processes to follow to produce and deliver the information, but does not contain status. The project communication plan includes areas such as the timeframe to receive data, project data recipients, distribution and storing methods, and the information collection process. One piece of the communication plan to watch closely is the timely delivery of project information. If you distribute project information late, the information becomes useless for your customers; they will not be happy or put up with the delay for long. Ensure you send the most recent information possible. For example, timely information is important for budget data and the frequency of reporting that type of data. Financial and cost information can swing radically from week to week; therefore, timely reporting of financial information is critical in keeping the project budget on track. Note Part of creating a project communication plan is to understand the proper generation of project information. This ensures the right people receive the right information at the right time. Creating a project communication plan One of your earliest tasks when initiating and kicking off a project is to create the project communication plan. Complete the following steps to create a project communication plan. 1. Plan and document the communication components of your project. For example, document the information you believe necessary to communicate effectively, such as: o Why do the customers need project information? o Who is working on the project? o What information do the customers need? o When do the customers need it? o In what format do the customers want it generated? o How will communication materials be stored? How will materials be retrieved? o Why is the information needed? Sometimes this history is beneficial. When creating your project's communication plan, think about virtual communications as well. When managing virtual teams, this information is critical and requires a whole new level of project planning. In corporations today, virtual communication has been commonplace for many years, yet many project managers struggle to effectively communicate with virtual teams. Compile the following questions and answers when documenting and planning your project communications. These questions and answers give you a huge start and advantage in creating a solid and comprehensive communication plan. Note You should understand what everyone on the project wants for project communication deliverables to help ensure that everyone is communicating effectively. 2. Consolidate and plan using the results from the planning activities in Step 1. Gather the information from Step 1 to create specific activities for creating those requirements. For example, the customers have asked for a monthly newsletter. The project manager must figure out the process for generating a newsletter in their project environment. The project manager works with the customers to ensure the information in the newsletter is what they want. The newsletter, in this case, represents the vehicle for delivering project information. The project manager continues working with the customer until he or she knows all the communication requirements (documented in Step 1). Note Take the time to summarize the requirements in Step 1 and decide if they are even possible to create in your project environment. A project website may not be possible to create for your project or your project environment, but might be a legitimate customer wish. 3. Document the customer communication requirements within the project communication plan. For example, in Step 1, the customer requested a project website, a monthly newsletter, and quarterly press conferences. The project manager would document those requests within the communication plan. After getting customer approval, the project manager's task is complete and the communication plan is done. 4. Record your findings in your communication management plan. Table 2.1 Communication Plan Table of Contents shows a sample table of contents for a communication management plan. Every company that practices formal project management should have a form or a template of a project communication plan. Review the communication plan and make sure that it works for your projects; otherwise, adjust accordinglynot every section will apply to the project. For unique projects, you may need to add sections that are not in the communication plan template today. The main communication plan template should be sufficient for most project customers or clients for most projects. After completing the information in the document using the processes just described, you will have a very comprehensive communication plan. Table 2.1 Communication Plan Table of Contents represents a table of contents for a communication plan that uses five critical communication tools. Most communication plan templates include other sections, which is fine, just make sure additional communication tools are added to the communication plan. Without including specific tools, you do not capture all of the information you need for an effective communication plan. Remember the critical questions covered in Step 1 noted above? Without asking these questions and capturing the answers in the communication tools, you will not fully capture your customer's communication requirements. Later in the book, we cover each of the five communication tools; however, capturing the empty sections and placeholders in the communication plan document now is important. Table 2.1 Communication Plan Table of Contents # 1 2 3 4 5 Description Circle-of-Communication Chart Project Communication Requirements Matrix Role Report Matrix Timeframe Lessons Learned The following tips can increase your chance of success and can be used as a checklist when creating a communication plan. Follow any procedures outlined by your PMO or company when capturing your customer's communication requirements. Most PMOs set the cadence for how often project reporting is required for project teams. You need to understand that cadence and use this information when gathering customers' communication requirements. For example, if the PMO establishes a monthly cadence for producing newsletters, and the customer wants a weekly newsletter instead, you will have to work with both parties to resolve. o Hold brainstorming sessions with project team members and project customers or stakeholders to capture their communication requirements for the project. In these sessions, you or your administrative assistant will document the customer's communication requirements, such as which reports, forms, websites, communication tools, and specifically, the documents or spreadsheets the customer requires for the project. The goal of every communication plan identified in these sessions is to provide the customer with the information they need to make project-level decisions and gain status of the project. o When the project customer's requirements include communicating with the media, you need to know the steps and processes for working with the media. This can be difficult for most project managers. Often, these messages must be approved by the legal department and can be quite complex to handle. Dealing with the media can be tricky and is common for large construction, research, or IT projects. o Understand your customer's expectations and find out how often they want to receive project data. For example, the project customer requests a project status report, and your role is to determine how often the customer will receive that status reportweekly, monthly, quarterly? You need to work directly with the customer for this information and jointly agree on an acceptable timeframe for delivery. o Understand exactly who the audience is for each communication deliverable. Ensure that you do not misjudge the recipients of the project when sending out project information. Take time to ensure the right people have the latest project information, always. o Use the company's standard template if possible; do not create your own version of the communication plan if there is already one available. However, we suggest that you add the various communication tools we discussed in this chapter to the existing plan. Companies often have a generic communication plan that might be missing the key steps and processes outlined above, but it could be a good starting point. Case Study - Kingdome roof replacement project and the media A project that received much media attention was the Kingdome roof replacement project in Seattle, Washington, back in 1994. The Kingdom was Seattle's multipurpose stadium for professional baseball, football, concerts, and many other events. The problem arose when the roof tiles inside the Kingdome started randomly falling on the baseball field and were endangering the players during a regularly schedule practice. Team members were immediately removed from the field, and the safety manager of the Kingdome closed the stadium for safety reasons. This drew instant media attention to the Kingdome. An investigation determined that the tiles in the Kingdome needed to be replaced before any concerts or athletic events could continue. The media agencies actively tracked this high-profile project and demanded up-to-date information throughout the life of the project. The project office decided the best way to handle the constant pressure of replying to the media was to create a PMO. So, they took over a conference room and posted all relevant project information on the walls for review by team members, media, and the public. This information was always current because of the demand from the press to be updated. The media had the latest project information at all times. The room was open 24 hours a day, seven days a week. The project team worked around the clock to meet a tight deadline; the latest information was available to the media at any time without having to bother the project manager or owners. Understanding the Circle-of-Communications chart The circle-of-communications chart identifies the resources you will work with throughout the life of the project; it's a simple chart to create, and effective when used on projects. You create the chart based on the specific project methodology you use. Because each project methodology has its own resource requirements, it is important that you create a project-specific chart. For example, a research project is different from a construction project; therefore, the circle-of-communication charts would be different as well. One area common to all projects is that they all have resources, and they all have a \"lead\" person who drives a specific group. The leads work closely with you rather than every individual team member. On large projects, working with everyone may not be scalable for you to handle successfully. Regardless of project typeconstruction project, a software development project, or a research project the circle-of-communications chart works for any project type. As you review Figure 2.4 Example of Circle of Communication Chart (Software Project), you will see the project manager role (you) in the center of chart, which represents you as the \"center of communications\" for the project. Connected to the project manager role are various leads (different for each methodology) who have team members working for them. The figure shows a software project example where the \"Test Lead\" has two testers working for him or her. Figure 2.4 - Example of Circle of Communication Chart (Software Project) The circle-of-communications chart is not an organization chart. We have all seen hierarchical organization charts with a common structure of a single lead person on top, and the other resources shown under the lead person. For a project manager, however, a typical project structure does not look like an organization chart at all. Most project team members do not formally report to a project manager. How many teams have you worked on where everyone directly and functionally reported to you? There are cases where it happens, but not often. The circle-of-communication chart removes the view of who formally reports to whom, and puts the project manager in the center to represent that he or she owns the project communications onlynot the team members. In today's project environment, the circle-of-communications chart becomes highly valuable and is used instead of an organization chart. This tool is beneficial to the project by helping you avoid politics while letting you establish and drive the project's communications. It's tackling communication planning from a different angle one that takes the emotions of someone reporting to someone else out of the conversation. Defining the Project Communication Requirements Matrix A project communication requirements matrix is a chart that shows how communications flow on a project. It shows who communicates with whom and which tool they use to communicate. It also shows who develops the information and who receives it. As you read the chart, the direction and flow of information is from left to right, bottom to top. The communication matrix is easy to understand and build. However, before you start to create the matrix, there are several pieces of information you need. It takes a lot of time to build the tool and collect the information, but the process of gathering the information and asking the questions from the different parties is priceless. Gathering information and building the communication requirements matrix helps you and your team members understand the real communication needs of everyone on the project; no other tool can offer that level of information about a project's communication needs. By not creating the tool, you lose a wealth of data about how to communicate effectively with your customers. You never want to be in a place where you don't know what or how to communicate to you customers, clients, or leadership team. Figure 2.5 Communication Requirements Matrix is a small example of this tool. This matrix represents who receives what information on the project and lists project stakeholders across the top and down the side. Also noted are any company-specific applications that require project status. The actual information or reports that you or the project team produce are documented in the cell of the matrix. Understanding how to read the matrix chart The first row in the matrix, the Project Manager, shows the project manager role sending the Stakeholders (Internal/Core Team) weekly status reports and attending monthly stakeholder meetings. The intersecting cell documents the specific communication requirements between the project manager and the particular role, in this case the Stakeholder (Internal/Core Team). As you read the matrix, look closely at the intersecting cells; they tell you the information passed between the two parties. This continues for every role on the project. As you read across the row for the Project Manager, specifically, note that he or she is responsible for entering status in the company's financial and reporting systems. This data includes color status (green, yellow, red), project dates, budget information, risks, issues, action items, and so on. Continue to review each row for every role on the project and review the intersecting cells for each role. You will also note that \"No need to communicate\" is a valid entry when two roles have nothing to communicate Tip You'll find that the communication requirements matrix is a valuable tool. This tool takes time to complete, so plan for this time in the planning process. Don't be intimidated by the complexity of the tool, just dive into it and get started right away on your project. Figure 2.5 Communication Requirements Matrix You benefit from using the communication requirements matrix by being able to see, on a single page, the information needed from the various roles. No other communication tool provides the same information to everyone on the project. Creating a communication requirements matrix Complete the following steps to create the communication requirements matrix. 1. Plan and document the roles needed for the project. Once you have identified all of the required project roles, add each role across the top and down the side cells of the matrix. This establishes the project roles needed to obtain or distribute project information. Create the circle-of-communication chart before you create the communication requirements matrix so you already have the roles you need. For the first step, think about the circle-of-communications chart, and then the communication requirements matrix as step two. 2. Document individual communication requirements for every project role. You will work directly with each role to gather information needs for the project. For example, you will meet with the customer to discuss communication needs. The information you capture during the session is added in the intersecting cells on the communication requirements matrix between the roles. The interview process continues as you meet with each role and document what they require for project information. You also set up and coordinate the meetings between the other roles of the project. For example, the customer and the team members require someone to coordinate the meeting between those roles, and in every case, that person should be you. Different project managers will tackle this process differently, but in the end, you need to address every intersecting cell. At the end of every session, enter the requirements directly in the intersecting cells between the two roles. You are finished with the communication requirements matrix tool when you have interviewed, captured, and entered all the data into the matrix. Often, you will work with various company systems on your projects. These systems have data entry requirements as well as reporting requirements and the system information should also be added to the matrix. It is a best practice to document both the data going in and reports coming out of the system. For example, the financial system produces weekly cost reports; however, the project manager had to enter the data into the system. Documenting both interactions for the various project systems is beneficial. 3. When the communication requirements matrix is complete, store it with the project documents and send it to customers for approval and future reference. If the project has a control room, hang the matrix on the wall for everyone to see and update when applicable. Another best practice is to continually review and refine the tool throughout the project. If a project team member leaves the project, you will need to update the communication requirement matrix with the new team member's information. Understanding the Role Report Matrix A role report matrix identifies which reports you will create for the various project roles. The role report matrix is different from the communication requirements matrix. The main difference is that the communication requirements matrix contains the information that is sent between the two roles (either people or applications), while the role report matrix only documents the reports between the parties. The communication requirements matrix includes areas where you can enter data into a financial reporting system; whereas, such data would never go in the role report matrix. The role report matrix describes and documents the various reports the stakeholders receive. Many project managers want to combine the two tools into one, which is definitely possible, but not recommended. The more information you put in one tool, the harder it is to read and understand. You'll find it worth the extra effort to keep the tools separate and the information clean in each tool. Table 2.2 Role Report Matrix shows an example of a role report matrix. This table shows the project reports sent to the different roles and the people involved with the project. The matrix lists the different types of reports across the top of the table and the project roles and people's name down the side of the table. Just like the communication requirements matrix tool, the intersecting cells show the core information that is passed between the two people on the project. In this example, the first row of data shows the CEO/CFO for the project. In reviewing that row, the CEO/CFO (John Smith) can request a status report or a cost report at any time (on-demand), and there is a requirement that he would like to see a monthly variance report. As you progress through the table, you will see the roles and their associated project reports. Another key difference between the communication requirements matrix and the role report matrix are the names of the individuals that are listed. Use actual names so that when someone calls or emails you about receiving project information, you can quickly refer to the matrix to see who is receiving what. Without a role report matrix, you would likely have to search through old emails and look at distribution lists to figure out what information you are sending them. Table 2.2 Role Report Matrix People Name OnDaily (who Demand Report receives Report the report) CEO/CFO John Status/Cost Smith Report Owner Weekly Report Variance Report Peter Status/Cost Daily Adams Report Status Report Stakeholder Mark Stakeholder Daily Monthly Report Schedule, Cost Report, Issues/Risks Report Schedule, Quarterly Report Quarterly Project Report Quarterly Project Report Quarterly Taylor Report Project Manager Bruce Jones Status Cost Report Report, Issues/Risks Report Daily Weekly Status Status Report Report, Cost Report, Issues/Risks Report Project Report The benefits of using the role report matrix include: o It documents who receives which reports and how often the reports are distributed. o It documents available reports. The matrix displays who is receiving which report. If stakeholders see a report they are not receiving, they can simply ask for it. Stakeholders would have no other way of knowing who is receiving which report without this tool. o You can control the project information distribution to your stakeholders and team members, while seeing who is receiving what kind of project information. o You can use it throughout the project to decide whether certain reports are still required by each customer. When a new customer joins the project, you can capture the customer's reporting requirements directly into the report with other stakeholder information. Creating a role report matrix Complete the following steps to create a role report matrix. 1. Plan and document the roles and report types available for the project. For example, document the different types of roles and add them, vertically, on the left side of the matrix. Across the top of the matrix, add the various time frames for report delivery. Time frames, at a minimum, include daily, weekly, monthly, or quarterly reports. 2. Document the individual project reports required for every project role. Work directly with each role to determine which type of project information reports they want to receive. A great example is the owner role, in which the owner requests an on-demand status and cost report, a monthly status report, and a quarterly status report. You would then work with each project role to decide which reports each role should receive and the timing. You will continually update the role report matrix by adding the information obtained from interviews directly into the intersecting cells. At the end of the interview process, the role report matrix is complete and ready to use on the project. Tip A best practice is to create the role report matrix at the same time you are completing the communication requirements matrix so that you only need to interview the stakeholders once. 3. After the role report matrix is complete, store it with the project documents and send it to customers for approval and future reference. Similar to the communication requirements matrix, if the project has a control room, hang the role report matrix on the wall for anyone to see and update when applicable. The following list shows the various types of communication reports in a role report matrix. These names would be listed across the top of the table. o Weekly Status Reports: Provide a status of the project mainly from a scheduling and cost perspective. o Project Schedule: Provides the time lines for the project's work activities. o Daily Report: Provides a daily snapshot of the project activities, addressing any risks, issues, or concerns about the project. o Monthly Report: Provides a monthly snapshot of the project activities, addressing any risks, issues, or concerns about the project. o Quality Report: Provides a quarterly snapshot of the project activities, addressing any risks, issues, or concerns about the project. This is normally a summary-level report. o Cost Report: Provides a snapshot of the project costs at the time of running the report. This includes planned and actual costs. o Variance Report: Provides a snapshot of the variance across cost and time from an established baseline. o Issues Report: Provides a list of all project issues. o Risk Report: Provides a list of all project risks and risk issues. o Performance Report: Provides a snapshot of the current project performance metrics and trends. o Resource Utilization Report: Provides a snapshot of the resource utilization across all project team members. o Resource Leveling Report: Provides a snapshot of the project's resource leveling project. o Quality Report: Provides a current snapshot of quality status and issues for the project. o Media Report: Provides a media release. o Lesson Learned Report: Provides ongoing lessons learned for the project. o Look Ahead Report: Provides a look ahead for short-term activities. o Stop Light Report: Provides a high-level graphic summary report on the cost and schedule status of the project. Note As you develop the role report matrix, it is critical that you determine who will receive which report. Developing Lessons-Learned Information One of the techniques and best practices that senior and experienced project managers use is to develop and create lessons learned information throughout the life of the projectnot at the end of the project. Usually, project managers collect lessons learned information in the final days or at the end of the project, which is during the closeout process and the project manager must scramble for bits and pieces of project history to compile into a lessons learned document. Often, because the project is in its closing phase, the project manager has only a few team members remaining, which makes compiling and obtaining project information from the remaining few resources difficult. The challenge is that the lessons learned information is incomplete because the project manager doesn't't have the whole team, just the people left in the closing phase. This scenario is common for a project manager who waits until the end of the project before collecting and developing the project's lessons learned information. A best-practice technique that is starting to gain popularity is collecting lessons learned information during the life of the project. From the kick-off meeting, capture and store the lessons learned information in a central repository for everyone to review. As the project progresses, use the project's status meetings to capture and review lessons learned information since the previous meeting. This is the best time to collect lessons learned information because you and your project team members can provide the week's lessons learned information while you are reviewing it everyone is present to discuss what is happening, or what happened, during the week. When developing your weekly status meeting agenda, add a lessons learned agenda item. As the meeting progresses to the point where you are ready to collect lessons learned information, ask each team member about their positive and negative experiences for the week. Don't mention the words \"lessons learned\" to them, though, just capture what went right and what went wrong from every team member. The more you do this, the more the team members will start to provide the data. Eventually, team members will provide lessons learned data without realizing they are doing so. The goal of collecting this information on a weekly basis helps you lead the discussion around the lessons learned information rather than waiting until the end of the project. Having information from past projects or past weeks on the current project will help ensure that your team does not repeat the same mistakes. Each week, be on top of this process and continue capturing what went right and what went wrong from each team member. At the end of the project, compile the information into a final presentation you won't be scrambling around trying to collect lessons learned information from project team members who may be long gone and working on different projects. Communicating lessons-learned information When communicating project information, you should have as much knowledge about the project as possible. That way, you ensure that the messages you communicate are as accurate as possible. One method for gathering knowledge is by using the lessons learned information from past projects. When you review the lessons learned information from past projects, you gain a wealth of knowledge about a previous project's events that might not normally be available. We recommend that you review the lessons learned information from past projects or, if possible, talk to the project manager who ran the previous project to learn more about what happened on the project. Occasionally, you might need to decide what information should be shared or not. Sometimes, sharing too much information can cause unnecessary bias that could negatively impact the project. An example would be capturing information about an individual or a particular group. The information was valuable to capture for the past project from a lessons learned perspective, but does not offer any benefit for this particular project and, therefore, should not be broadly shared. When planning your project communications, it is advantageous to use lessons learned information wherever possible. If you have a customer that wants you to personally deliver a project status report instead of emailing it, you would want to know that information sooner rather than later. You can get this kind of information from the lessons learned information. When you have that kind of knowledge of what went right and what went wrong on projects similar to yours, you can communicate that information to your team members and be on your way to delivering a successful project. Benefiting from lessons-learned One of the advantages of sharing lessons learned information is the positive impact that information can have on your project. Sharing these experiences and the specific knowledge that team members gained is beneficial for the next project. One example is when design teams create cost-saving techniques on the earlier project, and then use those same techniques on the existing project. These design and cost techniques save time and money on the current project. Another important benefit of sharing lessons learned information is the advantage that team members, customers, and other stakeholders gain from understanding the mistakes and benefits from previous projects. Understanding a previous project's mistakes and benefits at the start of your project helps reduce the chance of making similar mistakes. When managing a second iteration of a project, make sure you understand the previous major issues or concerns. When using and reviewing information from past projects, look for the following information to share with your team and customers to help benefit your new project: o Project budget information. Learn how earlier project managers managed their budgets and what tricks and techniques they used to be successful. o Project schedule information. Determine the duration of the new project to compare with the previous project schedules. This comparison is important because you can find out if your project can or should be using the same time frames as the previous projects. For example, how long was the last development cycle compared to the current development cycle? Are they radically different for essentially the same project? This information is good to know when managing a project that closely matched another project. o Project resources. Look for the various usage percentages of each team member, the process for finding team members, and whether those team members were allocated properly across the project life cycle. The more information you can discover and extract from previous lessons learned helps you plan more appropriately for your new project. o Risks and Issues. Understand the previous project's risks and issues and try to remove the chances of those reoccurring on your project. Try to learn from what went right and wrong on the previous projects, specifically around what risks could occur and what issues did occur. Understand the method that previous project managers used to create, track, and reduce risks. o Communicate with the previous project manager. One of the techniques that senior project managers often use when reviewing lessons learned is talking directly to the project managers of the previous projects. Those conversations often provide additional ideas that are not documented, but still valuable. Some of the stories and best practices the previous project managers can offer you are undocumented. Without these conversations, you would miss some valuable management points. While collecting the lessons learned information, enter the data into a central location, such as a database or document. When companies take the time and effort to produce lessons learned information on a project, they build a wealth of information that can benefit future projects for years to come. Caution Collecting lessons learned information on a project can be difficult. Do not let lessons learned sessions turn into complaining sessions! Summary In this chapter, we explored the essence and importance of planning your project's communications. We covered how various project managers struggle with communication planning and discussed how mapping communication tools with PMI methodologies can help you communicate more effectively. We discovered and discussed some communication challenges, showed you how to solve or work with those challenges, and put you in the best spot possible to deliver a successful project. Then, we covered creating a communication plan and the critical tools that should be in every communication plan going forward. We felt like it was important for you and your project manager peers to have a solid communication plan for every project and by covering this topic this early in the book, it represents our strong passion and dedication to the importance of this in delivering your projects