Communication Plan. Do you have one?

    The statistics show that a project manager spends more than 90% of the working time communicating. In addition, a poor communication is considered a common cause for the project failure. Therefore it is very important to have a good communication in your project.

    But how to ensure that the communication is properly done? A good idea is to do some planning for your communication. The plan shall cover what information to distribute, to whom, when, how and how often you need to distribute an information.

    In the first step you need to determine what is needed to be distributed and to whom. Thus you have to determine the project stakeholders and to analyze what information do they need. This is the most complex step and requires a lot of attention.

    In the next step you have to determine when and how often you have to deliver the information. That is also dependent by the stakeholder's needs. For example you can send to the upper management or to the customer an weekly report, other stakeholders may be notified only when a milestone is reached.

    Very important is also the modality of information distribution. Thus in some cases you have to use a formal communication (written or verbal) and in other cases an informal communication (written and verbal). The choose between formal and informal communication is dependent by what you need to communicate and to whom you communicate.

    Also the communication technology is very important, especially in the projects with virtual teams. An important factor in choosing the communication technology is the urgency of the communication and the availability of the technology.

    Not many project managers are using a communication plan. Maybe for a smaller project with only a few stakeholders, a communication plan is not compulsory. But for a medium to large project, a communication plan is essential for the project success. A larger scale project has a big number of stakeholders and not providing the right information at the right moment can have important consequences and is a potential source of conflict.

Action Item List

    An action item is a small task, activity or an action which have to be executed by the project manager, a member of the project team or any other stakeholder. All over the project life cycle you can determine that action items have to be performed. In many cases you determine them during meetings, discussions with stakeholders, but also by logical deduction.  As a project manager, you have to assign them for execution and , in addition, you have to track them.  In a small project, your memory might be enough. But in a larger projects with many team members and a lot of other stakeholders, you need to document them properly.
           
Personally, I manage the action items in a tabular document (see example) with the following columns:

1. ID:  an incrementing identification number
2. Action Item: describe the action which needs to be performed.
3. Status: can be „Open“ if the action is not yet done, or „Closed“ if the action is resolved.
4. Creation Date: Represent the date when the action item has been issued.
5. Due Date: The date until the action item has to be resolved.
6. Urgency: Depending by the urgency of the action item this field can have the the following values: Showstopper, High, Medium and Low.
7. Responsible: the person assigned to do the action. I recommend to assign only one responsible per action item in order to have a clear ownership of the action item.
8. Comments: You can add here different information about the action item. For example you can give more details about that action item, add information about the status, problems in solving it, etc.

    The action item list is managed by the project manager and I prefer to place it in a document management system as for example SharePoint. Since a document management system is corporate wide available, each team member can check for his action items and update them accordingly.
    
     How the action items are communicated? Those which are issued during a meeting are communicated along with the meeting minutes.  In the other cases, they can be informally communicated.  

    Very important is to track the status of the action items. Most of the project managers are checking the status of the action items during the status meeting.  Personally I check them one time in a day, sorting them by the due date and urgency. Case by case, I escalate them to be resolved.

Best practices for creating a Work Breakdown Structure

In an earlier article, I described why a WBS is so important. But in order to be a usefull tool, you shall respect some best practices. I will discribe bellow some of those.

1. Use a top-dow approach. Begin at the project goal level and break the work successively to lower levels of definition.
   
2. Create it with the input from domain experts and team members.
   
3. Do not include any work which is not part of the project.
   
4. Cover the entire scope of the project at least at the upper level of the WBS (In a iterative development aproach, the WBS is developed iteratively, thus the entire scope will be only at the end of the project available). But in early phases, the entire scope of the project can be covered in the in the high level WBS components.
   
5. Each component of the WBS, excepting the highest one, is a part of the parent WBS component.
   
6. The lowest level of the WBS shall have the following properties:
   

• It is possible to estimate its need for ressources, duration and costs. Aggregating this information for each lowest level work package you can calculate the ressources, duration and costs for the entire project.
  
• The start and the end of the execution can be clearly defined.
  
• It's realization can be outsourced. That is true mainly for work packages to an upper level in a WBS. The outsourcer can further decompose that work package.
  
• It has a deliverable or a clear part of it. The deliverable is a prove that the work package is complete.
  
• It can be completed within reasonable time limits. There is no universally accepted rule regarding the length of an work package. However, it  shall not exceed 1-2 weeks to complete.
• Specific to the software development projects, it can be executed by a single developer.

The Work Breakdown Structure (WBS): Why a WBS is so important?

The Work Breakdown Structure (WBS) is, no doubts, the most valuable project management tool. According with the definition from PMBoK (Project Management Body of Knowledge), the WBS is a deliverable oriented hierarhical decomposition of the work to be executed by the project team to achieve the project objectives and to create the requested deliverables.

It is a good practice to use a WBS for any project, even if a project is a small one. But why a WBS is so important? What are the benefits of using a WBS for your project?

First of all, through logical decomposition, a project manager or the project team is able to determine all the work which is needed to fulfill the project objectives and to deliver the project deliverables. Through successive decomposition the work is decomposed in smaller, more manageable, work packages. Those resulting work packages can be further used for ressource estimation, scheduling and cost estimation. It is so because it is much easier to estimate the smaller pieces of work. In addition for having a solid ground for your planning, by having a good foundation for your estimations, you can confidently go to your managers to request more ressources, more time and bigger budget.
Furthermore, it helps to understand much better the project. By assesing each work package, and the relationships between them, you can understand the risks for your project. In addition since the WBS covers the entire scope of the project, you can asses correctly the impact of the scope changes.
Not to neglegt are the advantages which a WBS brings to the communication. Stakeholders can easier understand your project having in front a WBS showing the work packages which have to be executed. Furthermore, team members can understand the big picture and their role in the project.
But how can you create a good WBS? What are the best practices for creating it? We will have a look about in the next episode regarding WBS.