4squareviews

Before I go through the 7 project management processes associated with the Risk Management knowledge area, I thought I would cover some concepts, many of which are covered in the introductory section to this knowledge area which starts on page 397 of the PMBOK® Guide but some of which are not and are based on my reading of the material.

1. “Risk” definition–the actual definition of risk in PMI is “an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives.”   The definition of risk in “real life” is usually an event that has a potential negative effect, but the risk definition in PMI is wider in that it includes positive effects as well, or what we would normally refer to as an “opportunity” as opposed to the normal meaning of the word which refers to “threats.”   I would not say, for example, that “there’s a risk of my having a good time at the office party” (unless I were being ironic or sarcastic).  But in PMI parlance, this use of the word risk to cover positive opportunities is okay.
2. Risks and stakeholders–a stakeholder is a “person … that may affect the outcome of a project.”   Note the similarity between the definition of a stakeholder and that of a risk, of an event which may affect the outcome of a project.    The difference?   One is human and one is not.   That’s why we refer to stakeholder engagement but risk management.    You can engage stakeholders and reason with them (or most of them, at any rate), and perhaps manage their expectations.   You can’t, however, argue with the weather and cajole it into doing what you want.   You can prepare for the event of bad weather if it occurs by avoiding it or mitigating it by taking along an umbrella (or using the expanded definition of risk, by taking advantage of good weather).    But you need to take into account both risks and stakeholders, because both can influence your project.
3. Overall vs. individual risk–individual risks have to do with specific events, but overall risk has to do with uncertainly on the project as a whole.   A company has a certain risk tolerance as part of its organizational culture, and this tolerances refers not to individual risks but to risks in general.   A start-up company is going to be more risk tolerant than an established organization, for example, because the very process of setting up such a company is laden with risks to begin with.   On the other hand, companies that are industry leaders may find that they have to be more risk tolerant in order to maintain their lead position (to take advantage of opportunities which may expand their market).
4. Known vs. unknown risks–Donald Rumsfeld, the Secretary of Defense under George Bush, gave the risk management world a colorful way of phrasing the difference between known vs. unknown risks:  he called known risks the “known unknowns” and contrasted them with the “unknown unknowns.”   Known risks are “known unknowns” because you know or anticipate that they may happen, but you  don’t know whether they will happen or not.   “Unknown unknowns” are those risks which you don’t anticipate.   This is not just a theoretical concept:   there are very real differences in the way they are handled.   Known risks are put in the risk register, and you create risk responses for them which are funded out of contingency reserves.   Unknown risks are not put in the risk register, of course, for the very reason that they are unanticipated.   If they do occur, since you don’t have a plan for a risk response, you have to come up with an out-on-spot solution called a “workaround” which is funded out of management reserves.
5. Risk and probability–Do you have a risk of dying?   The answer is no because there is no risk involved:  it is a certain event.    The mortality rates that actuarial statistics measure involve the question of how old you will be when you die, which is a different matter because that involves an uncertainty or probability.    One of the things that makes risks manageable is the “law of large numbers”, which is a principle of probability according to which the frequencies of events with the same likelihood of occurrence even out, given enough trials or instances.   So the risks that often occur are the ones that you can predict a probability of occurring with a certain level of confidence.   The unknown risks are those that are unpredictable because they are fortunately rarer.
6. Risks vs. issues–a risk is a potential event, which if it occurs, no longer becomes a potential problem, but an actual problem called an issue.   Once a risk occurs and becomes an issue, it is dealt with on the issue log, rather than on the risk register.
7. Risk management flow–here’s the flow of processes for the risk management knowledge area.
   1. Plan–Create a plan for how you will manage risks on your project (gives guidelines on how to do all the other processes)
   2. Identify–Think of all the risks you can that may occur on a project.
   3. Perform Qualitative Risk Analysis–Classify the risks identified in step 2 according to a subjective scheme (low, medium, high) and come up with a strategy of how to deal with them based on the classification.   Low risks you may want to just accept; medium risks you will want to mitigate or insure against, and high risks you may want to do what you can to avoid them.
   4. Perform Quantitative Risk Analysis–Take the risks identified in step 3 that you plan to mitigate or insure against, and come up with an estimate of the cost risk involved.
   5. Plan Risk Responses–Take the risks identified in step 3 that you plan to mitigate and come up with a plan for how to mitigate the probability of their occurring, or the impact on the project if they do happen to occur.   Come up with reserves that will fund these risk responses based on the cost analysis done in step 4.
   6. Implement Risk Responses–in the course of a project, respond to risks as they occur based on the plan developed in step 5.
   7. Monitor Risks–if risks do not occur, then modify the risk register to reflect this; if new risks are identified, add to the risk register developed in step 2.

Next I will discuss the inputs, tools and techniques and outputs for the seven processes of risk management outlined above…

Filed under: Uncategorized | Leave a comment »

As I mentioned in the previous two posts on the a) inputs and b) tools and techniques of this process, the process of Monitor Communications really consists of two parts:

• Monitoring communications to compare the actual work done on communications (by looking at the Work Performance Data–one of the inputs of the process) with what is set out in the Communications Management Plan (another input of the process):   the results of this comparison are considered to be Work Performance Information (see paragraph 10.3.3.1 below)
• Controlling communications so that if a variance between the actual communications and the planned communications is discovered, the source of the variance is determined and a Change Request is made to resolve it (see paragraph 10.3.3.2 below).   The change proposed may be in the communications themselves or in the communications plan (see paragraph 10.3.3.3 below), with possible changes to the project documents (see paragraph 10.3.3.4 below).

10.3.3  Monitor Communications:  Outputs

10.3.3.1 Work Performance Information

The whole point of this process is to compare how the communications on the project are actually performed (the Work Performance Data input to this process) and compare it with the results that were planned in the Communications Management Plan (another input to the process).   This comparison is the Work Performance Information, which should be analyzed by the project team to get their feedback and that of stakeholders regarding the effectiveness of the communications.   Any proposed changes should take be made as formal Change Requests (see next paragraphs).

10.3.3.2  Change Requests

These outputs then become inputs of the process 4.6 Perform Integrated Change Control.

The change may be to communications to put them more in line with what’s in the Communications Management Plan, or it may be to the plan itself if the original plan turned out to be either unrealistic or if the stakeholders have changed their requirements with regards to those communications.  (They may request more frequent information about the project as they become more aware of its impact, for example.)

10.3.3.3 Project Management Plan Updates

As mentioned above, the process may result in changes to the project management plan, in particular those components that have to do with communications:

• Communications Management Plan–any updated are included to the plan to make communications more effective
• Stakeholder engagement Plan–if the situation of stakeholders change and they want additional information about the project, these changes are reflected in the stakeholder engagement plan

10.3.3.4 Project Documents Updates

• Issue log–issues related to communication will be updated on this log
• Lessons learned register–if issues related to communication are resolved, the resolution and the corrective actions chosen will be updated in the lessons learned register so that communications can be made more effective for the rest of the project.
• Stakeholder register–if stakeholders have any changed requirements with regards to communications, these changes are updated in the stakeholder register.

And that, my friends, is the last post for the Communications knowledge area.   Next is one of the biggest and more important knowledge areas covering Risk Management.   I will start the next post with the inputs to process 11.1 Plan Risk Management.

Filed under: Uncategorized | Leave a comment »

Like monitoring and controlling processes for other knowledge areas, the tools and techniques used in the communications management knowledge area contain a mixture of what I call “generic” tools and techniques, that is, those used in most of the knowledge areas, and those that are specific to this knowledge area.    Expert judgment, meetings, and the Project Management Information System (software program like Microsoft Project) are examples of generic tools and techniques that are used in many other knowledge areas as well.   Those that are specifically geared towards this knowledge area are the Data Representation technique of the Stakeholder Engagement Matrix and Interpersonal and Team Skills in responding to requests from stakeholders for additional information.

As a reminder, although the title of the process says “monitor communications”, meaning monitoring the actual communications and comparing to what is in the communications plan, there is also a “controlling” component where any variance with the plan is addressed, either by

• changing the actual communications to fit the plan, or if the original communications plan is seen to be unrealistic and/or stakeholders suddenly have revised requirements for communications,
• changing the communications plan itself.

10.3.2  Monitor Communications:  Tools and Techniques

10.3.2.1  Expert Judgment

When making decisions about communications, the experts you may need to consult are those with expertise in

• communications, particularly in special environments like international or virtual environments.
• Project management systems and their communications requirements

10.3.2.2  Project Management Information System

This is a set of standard software tools, like Microsoft Project, that can help capture, store, and disseminate information to team members, internal and external stakeholders.   In the course of this process, the information contained in the PMIS system will be monitored for validity and effectiveness.

10.3.2.3 Data Representation

The stakeholder engagement assessment matrix is an output of process 13.2 Plan Stakeholder Engagement.   It charts the current engagement level for each stakeholder and the desired (or planned) stakeholder engagement level, and is useful for monitoring the progress in moving between the current and desired level.

10.3.2.4 Interpersonal and Team Skills

There are two sources for information related to this process of monitoring and controlling communications.

• Dialogue and conversation with the project team to determine the most appropriate way to update and communicate project performance (the validity of the information).
• Responding to requests from stakeholders (the effectiveness of the information).

10.3.2.5 Meetings

This can include both face-to-face and virtual meetings.   Remember the ground rules of meetings that are discussed in my previous post:

6th Edition PMBOK® Guide–Process 10.2 Manage Communications: Tools and Techniques

You may want to monitor and control how your meetings are going as a central part of this process, because how you handle meetings will be a large part of handling communications as a whole.   Remember that a meeting is a tip of the iceberg; before each meeting you need to communicate its scope (the purpose), its schedule (agenda) and cost in terms of time (strict starting and ending time).   After each meeting you need to communicate the results to stakeholders.   My personal preference is a two-track approach where you give an “executive summary” for those stakeholders who are either too busy or not engaged enough to follow the details, followed by a more detailed set of information for those that want to dive into the details.    I use a “60-second rule” I got from my first boss when I worked in New York, which basically states that it should take no longer than 60 seconds for someone to read and digest the executive summary.   Sometimes a dashboard or other visual device is helpful in conveying information in a concise way that telegraphs the status of the project.    Also helpful is an indication of whom to contact for additional information, and most importantly, if there is a response requested (I would underline or otherwise highlight this in the executive summary in order to draw attention of those you are asking to respond).

With these tools and techniques, you can monitor the communications and decide if any changes are needed.   This will result in a change request, and/or updates to the project management plan and project documents.   These outputs of the process will be discussed in the next post.

Filed under: Uncategorized | Leave a comment »

This process of Monitor Communications is in the monitoring and controlling process group.   The monitoring part is where a comparison is made between the actual work on the project (the executing process group is where the actual work is done) and the work as planned (in the Project Management Plan).   If there are variances, then the controlling part of the process goes into effect, where you come up with a change that will either a) change the work to fit the plan, or if the plan turned out to be unrealistic to begin with, to b) change the plan to fit the work.

For some reason which I haven’t quite figured out, most of the knowledge areas in the monitoring and controlling process group have the title “Control X”, where “X” is the name of the knowledge area.   This knowledge area is one of the exceptions because the title is “Monitor Communications.”   However, make no mistake, the controlling part of the monitoring and controlling process is also in effect, because “change requests” of the kind described in the last paragraph are indeed one of the outputs of the process.

In this post, however, let’s discuss the inputs to this process.

10.3.1 Project Management Plan

Remember, since the whole point of this process is to compare the actual work done with what’s in the plan, the project management plan is going to be an important input for the process.   Specifically for this knowledge area, it will be those components that have to do with communication.

• Resource management plan–recall that in the 6th Edition of the PMBOK® Guide the knowledge area of “resources” refers to both physical resources (equipment, materials, locations) and human resources (i.e., the project team members).   In particular, the roles and responsibilities of the members of the project team may be necessary to review if the communications are sufficient.
• Communications management plan–this indicates the communications that are going out to team members and stakeholders.
• Stakeholder engagement plan–this identifies that the communication strategies that are planned to engage stakeholders based on their level of engagement in the project

10.3.1.2 Project Documents

Here are the project documents that may be used as inputs during this process.

• Issue logs–in particular, any issues related to stakeholder engagement will be relevant for this process.
• Lessons learned register–if lessons are learned with regards to stakeholder communications, then these will be added to the register to improve effectiveness of communication in the remainder of the project.
• Project communications–this provides information on the communications that have been distributed.

10.3.1.3  Work Performance Data

Remember, the process will take the actual work done–in the case of the communications knowledge area, it will be data on the types and quantities of communications that have actually been distributed–and compare it to what is specified in the Communications Management Plan.

10.3.1.4 Enterprise Environmental Factors

• Organizational culture and governance framework
• Established communication channels, tools and systems

10.3.1.5 Organizational Process Assets

• Corporate policies and procedures for social media (ethics and security issues)
• Standardized guidelines for exchange, storage and retrieval of information (legal requirements may require keeping of records for a certain period of time)
• Historical information and lessons learned from previous similar projects

With these inputs, let us go to the next post to discuss the tools and techniques used to actually do the process of Monitor Communications.

Filed under: Uncategorized | Leave a comment »

This post covers the outputs of the process 10.2 Manage Communications.   Besides the communications themselves (see paragraph on Project Communications below), there are updates to the project management plan, to project documents, and to organizational process assets (the remaining paragraphs below).

10.2.3  Manage Communications

10.2.3.1  Project Communications

These are mainly reports to stakeholders about the status of the project, and include some related to various knowledge areas, in particular those having to do with the main constraints of scope, schedule and cost:

• Performance reports
• Deliverable status
• Schedule progress
• Cost incurred
• Presentations (from meetings)

10.2.3.2 Project Management Plan Updates

The main update is, of course, to the communications management plan component of the overall plan, but the stakeholder engagement plan gets updated as well as a result of this process.

• Communications Management Plan-if changes are made to the communications approach during the process 10.3 Control Communications, then these get implemented into the Communications Management Plan as a result of this process, and the changes are reflected in the Communications Management Plan.
• Stakeholder Engagement Plan–if as a result of this process, any stakeholder communication requirements or agreed-upon communications strategies are changed, these need to be updated in the Stakeholder Engagement Plan.

10.2.3.3 Project Documents Updates

• Issue log–if any issues related to communications on the project are uncovered as a result of this process, these issues are added to the issue log.   Also, if improved communications are used in order to have an impact on any other active issues, the log entry for those issues is updated to show how these improved communications helped impact them.
• Lessons learned register–if challenges are encountered during this process related to communications, then how those challenges could have been avoided, as well as how an improved approach worked well for managing communications are recorded in the lessons learned register so that they will have an impact on communications for the rest of the project.
• Project schedule–the project schedule may needs to be updated to reflect any new communication activities taken up on the project (if additional meetings are called for, for example)
• Risk register–any risks that deal primarily with managing communications are added to the register.
• Stakeholder register–information regarding communications activities with regards to particular project stakeholders is put in this register.

10.2,3.4  Organizational Process Assets Updates

• Project records used on the project (memos, correspondence, meeting minutes)
• Project reports and presentations (those shown in meetings or prepared as a result of meetings)

Filed under: Uncategorized | Leave a comment »

This post covers the tools and techniques in this very important process 10.2 Manage Communications.

10.2.2  Manage Communications:  Tools and Techniques

10.2.2.1 Communication Technology

This is also considered in making the Communications Management Plan.   The factors that influence the choice of communications technology are:

• Urgency of the information–this will affect the frequency and the format of the information.   This will also require escalation procedures.   For example, If I send you an e-mail that requires a response, I should indicate in that e-mail what the deadline is for a response.  If you do not answer in the time frame I have indicated, I may go ahead and call you to get the information.   If you do not answer the office phone when i call you, I may leave a message and then text you on your cell phone so you get the message as soon as possible.
• Availability and reliability of technology–this is important when choosing any type of technology.   For example, I find that when choosing a platform for virtual meetings (such as WebEx) may require that people install software or an extension to their browser before the meeting so that they are not trying to do it when the meeting begins.    Also, setting ground rules for virtual meetings is important, so that, for example mute their phones when not speaking in order to eliminate background noise for the other people on the call.
• Ease of use–if communications technology is unfamiliar to people, there should be training events planned in order to get them up to speed so that, for example, meetings are not interrupted by people not knowing how to properly use the features of the communications platform.
• Project environment–This will determine whether meetings are face-to-face or in a virtual environment.   In a global organization, there may be factors to consider such as setting the official language of communication for written and oral communication, and ground rules set regarding sensitivity to various aspects of the cultures which the organization operates.
• Confidentiality of information–There may be some proprietary information which should not be shared with certain outside groups, for example, when communicating with vendors or with contract employees who are not directly employed by the organization.
• Organizational culture–many of the ground rules for communication on the project will be ones that are set by the organization that is doing the project.

10.2.2.2 Communications Methods

There are three basic communications methods used to share information among project team members and project stakeholders.   These can be broadly classified as follows:

• Interactive communication (one-on-one or many-to-many)–this is a multi-directional exchange of information.   Examples:   meetings, phone calls, instant messaging, some forms of social media, and video-conferences.
• Push communication (one-to-many)–this is information sent to specific recipients who need to receive it.   Examples:  letters, memos, reports, faxes, voice mails, blogs, press releases.
• Pull communication (many-to-one)–requires the recipients to access content at their own discretion subject to security procedures; usually reserved for large complex information sets, or for large audiences.   Examples:  E-learning, web portals, intranet sites, lessons learned databases, knowledge repositories.

10.2.2.3 Communication Skills

There are many sets of skills needed in communication.    Here are some of them:

• Communication competence–this is mainly dealing with interactive (one-on-one) communication.    Clarity of purpose and brevity help you create an efficient message, one that does things right; using leadership to inspire others helps you create an effective message, one that does the right things.
• Feedback–In your role as project manager, you will need to give feedback to your members to correct behavior that does not conform to the ground rules set at the beginning of the project or that addresses a conflict that has arisen between members.   Any such “negative” feedback should be accompanied by the following to reduce the resistance on the part of the person receiving it:
  • Empathy–telling the person if you yourself have done the behavior in the past, but more importantly, understanding why the person did what he or she did.   This shows that you are not criticizing them personally, but focusing on what was done.   If a person makes an error that needs to be corrected, it puts them more at ease to know that I myself may have done the same in the past and have corrected it.   The implication is “if I could change, you can too” without saying it directly.
  • Objective standards–telling the person what the ground rules are and why you think the behavior isn’t consistent with them.   Explain that the ground rules are there so that everybody will work well together on the project.   This takes the focus off the person’s own ego and helps them look at their own behavior objectively.   Avoid the word “wrong” with its moral implications that the person is somehow a bad person; focus on the ethical implications of the behavior when it is inconsistent with the ground rules.   Something that helps here is when you post the ground rules or go over them at the very first group meeting so that everybody is aware of them.   This gets away from the excuse that “I didn’t know the ground rules.”
  • Subjective impression–be sure to tell the person that your feedback is from your viewpoint.   You should be sure not to use language that says simply that their behavior was inconsistent from the ground rules.   Add phrases that make it clear that this is your subjective impression from where you sit (“it seems to me …”, “from where I’m sitting,” “now I may be wrong, but my impression is …”, etc.)  Although you are trying to point to objective rules, you are still a human being that views the situation of the project from your perspective.   This allows the person to realize that you are not sitting as the sole judge or arbiter of reality on the project.   You are a person, like them, who is trying to come to grips with the situation and from where you sit, you think there may be a problem with their behavior based on your reading of the rules.  Especially when dealing with conflicts between individuals on a project, there will definitely be at least two sides of the story and you should be willing to listen to both.   If you do that, and then you still feel that the behavior of one person is going against the ground rules, then by saying that this is your observation, rather than saying it is definitely so, this gives the person you are talking to the message that you are not taking one person’s side over the others.   You are taking the side, as the project manager, on getting the project done and that means everybody, including yourself, abiding by those ground rules.
  • Observation and participation rather than advice–in order to come up with an alternative behavior in the future, rather than saying “in the future, you should…”, it may be more effective if you let the person you are talking to come up with an alternative.   “If you had to do this over, what would you differently?”
  • Support–let them know they are not in this alone.  “How can I help you so that you can change what you are doing?”   Should I send you a reminder?   Do you need more resources (including more training) to gain confidence in what you have to do?   Do we need to make the ground rules clearer in the future?   There are many ways to have the person know that you are going to support the change that you are asking them to make.
  • Sweetening the pot–this is very important when giving negative feedback.  Find something that the person IS doing well at on the job (nobody is able to do EVERYTHING badly on the job, there’s got to be something, however minor, that they just happen to be doing right).   Before you lay it on with regards to the negative feedback, start with the positive feedback and tell them that their contribution on the project is valued.   That way they take the negative feedback and the corrective action from a standpoint of confidence rather than defensiveness.
• Nonverbal–when you are speaking, learn to use vocal variety (varying the tone and pitch of your voice, using pauses for emphasis), gestures to punctuate the meaning of what you are saying, and facial expressions (even exaggerated ones) again to emphasize your point.
• Presentations–clear and effective presentations are important.  You need to get across the four categories of preferences people have in communication.
  • Ideas–how do you relate the information to what people think?   This means giving the “big picture” of how the information relates to the project in general, the organization as a whole, or even current ideas within the field of project management.
  • Action–how do you relate the information to what people do?   This means giving takeaways or action items that people can use to put the information into practice on the project.
  • People–how do you relate the information to what people feel?   This means two things:  first of all, relating to the experiences and memories people have by your relating your own experience with regards to the information.   (How did you come across the information?   How did it affect you personally?)   It also means setting up the relationship with the person early on in the communication so that they relate to you.   This is done through storytelling and asking for participation (starting the talk with a question, “how many of you have had the experience of . ..”, or periodically asking people “does this make sense to you?” or at the end asking questions so people can interact with you with regards to the information if they have some doubts.    I put a lot of emphasis on this category because it is what that I personally lacked when I first started working on projects.   I cared so much about getting the information across that I started almost immediately shoveling it out to the audience without spending time first establishing the relationship with them.  I found out if they don’t care about you, they won’t care about what you have to say to them.   This isn’t true of everybody, but it is true about those with a “people” preference.   For them, a simple greeting and asking how they are doing or remarking on the weather will create a simple baseline of interaction upon which you can get THEN use to get the information across.
  • Process–yes, yes, I know there are people who enter the field of project management because they are borderline of having obsessive-compulsive disorder, or in common parlance, they are focused more on doing things right than doing the right things.   For this group, you need to make sure you relate the information to the process of the project.   Do you have information in bullet points that ensure to them that you have crossed your proverbial t’s and dotted your proverbial i’s?   Now, you don’t have to burden the rest of the group by going through all of those details in your presentation, but you need to reassure the detail-oriented people that you have at least thought of all the details.   Instead of asking for their feedback at the end of the presentation, include some of the details in slides (if you are giving a Powerpoint presentation) that you invite their feedback on AFTER the meeting.

By incorporating these four viewpoints in your presentations, you will reach the individuals of the audience who have different viewpoints and get all of their support for the information you are trying to present.

For any project manager wanting to improve their communication skills, I personally recommend Toastmasters as an organization to join because the three sections of the meeting focus on the following

• Prepared speeches–this is where you learn public speaking skills to make your presentations more effective
• Table topics–this is where you learn skills in answering questions (useful for interviews or Q&A at the end of your presentations)
• Evaluations–this is where you learn skills in giving feedback which is welcome and useful for the person receiving it and which effective in getting that person to improve his or her performance.

10.2.2.4  Project Management Information System (PMIS)

This is a software tool like Microsoft Project which can be use to help manage the following:

• Project management–this can help you establish a schedule, and create a dashboard to help monitor progress in maintaining that schedule
• Electronic communications–this can help you with various forms of communication with project team members and stakeholders on the project
• Social media–helps form online communities that can engage stakeholders with what’s going on in the project

10.2.2.5 Project Reporting

This is a matter of taking work performance information (the comparison of the actual work with the work as projected in the plan) and putting it in a useful form as work performance reports that go out to the stakeholders.   The most important information should be sent out to relevant stakeholders on a regular basis, although you should also be prepared to send out information as requested by key stakeholders.

10.2.2.6 Interpersonal and Team Skills

These are skills that are used in working one-on-one with project team members (interpersonal skills) and the project team as a whole in meetings (team skills).

• Active listening
  • acknowledging that you receive a message, or when sending an e-mail, setting up an alert system that confirms that the receiver opened the e-mail (whether they read or not, and whether they understood the contents or not is another matter)
  • clarifying and confirming (asking the person to summarize what you just said is a way to do this, or if you are the receiver, telling the sender your summary so that they can confirm whether you understood)
  • understanding (are you talking to a person at a time when they can devote their full attention to you)
  • removing barriers that adversely affect comprehension (speaking clearly)
• Conflict management (for all conflict resolution techniques, see p. 349 of the PMBOK® Guide)–PMI prefers by far the following technique
  • “Collaborate/problem solve” method which incorporates multiple viewpoints and insights from different perspectives that can result in a win-sin situation.
• Cultural awareness
  • Minimize misunderstandings and miscommunication that may result from cultural differences within the project stakeholder’s community.   For practical tips on how to analyze these differences, see Erin Meyer’s book The Culture Map.
• Meeting management–project meetings are the bane of every project manager’s existence.   You may not get people to love meetings, but you can certain make them resent them less by paying attention to the following rules:
  • Have a single, specific objective for the meeting.  You should not have a meeting that is both a brainstorming meeting AND a decision-making meeting because those require different modes of thinking by participants.  If you need to both of those, have separate meetings.
  • Prepare and distribute the meeting agenda stating the objectives of the meeting and indicating whether the people need to read anything beforehand and indicating if there are key members presenting information.   The more work done before the meeting, the less time you’ll have to spend doing it in the meeting.   If possible include how much time will be allotted to which section of the meeting.
  • Ensure that the appropriate participants are invited and attend.  If key participants cancel, you may have to cancel the meeting and reschedule when they are available.
  • Ensure that the meetings start on time.   If a person comes late to the meeting, DO NOT recap the meeting for them as that will enable them to keep being late.   If they feel uncomfortable by the fact that they’ve missed something, maybe next time they’ll show up when they’re supposed to.
  • Ensure that the meetings end on time.   Just like on a project, have a buffer of time that you can use if some discussion goes over on a certain section of the meeting.   However, when it gets to be about five minutes before the meeting is supposed to end, you need to start wrapping it up.   Many people will have another phone call or appointment or something lined up immediately afterwards, so you need to let them transition to their next activity.  If you end up finishing early, you will get bonus points from people by releasing them from the meeting early.
  • Stay on topic.   Keep a “parking lot” list or other device to record issues that come up but are either off topic or for which there isn’t sufficient time to discuss at the meeting.    This will allow people to feel their issues are being addressed, even if not immediately at the meeting.
  • Manage expectations for the meeting by repeating the objectives and restating ground rules if necessary.
  • Resolve conflicts that arise, preferably with the collaborative/problem-solving technique described above (see above paragraph on Conflict Management)
  • Record the main points that come up with the meeting, but this taking of meeting minutes needs to be done by someone other than the facilitator of the meeting.   The meeting minutes need to be processed and distributed to those participants within a certain specified date of the meeting, preferably within the next 24-48 hours.
  • Record all action items that stem from the meeting, including those who have been allocated the responsibility for completing the action.
• Networking–This is either personal, face-to-face networking or virtual in the form of e-mails and/or social media.  This is done to
  • Solve problems
  • Influence actions of stakeholders
  • Increase stakeholder support
• Political awareness–this helps with influencing actions of stakeholders and increasing their support for the project.   It includes:
  • Recognition of power and influence relationships within the organization (which are the stakeholders who have influence on the project)
  • Understanding the strategies of the organization (which are the stakeholders who are influenced by the project and will therefore be interested in its outcome)

10.2.2.7  Meetings

These are a tool where communication management is vital in order that they be efficient (not take too much time of the participants) and effective (they help move the project objectives forward).   For techniques on meeting management, see the sub-paragraph on Meetings above under 10.2.2.6 Interpersonal and Team Skills.

These are the tools and techniques used in managing communications on the project.  I’ve got into a lot of detail because this is vitally important to do this process well in order that succeed on the project as a project manager.   The outputs of this process will be covered in the next post.

Filed under: Uncategorized | 1 Comment »

I’ve taken a week-long vacation from blogging because I was in the midst of a move, and I’m sure you can appreciate that handling the details of a move from one town to another is a full-time project in and of itself.

But I’m back now and continuing where I left off, going through all of the 49 processes in the 6th Edition of the PMBOK® Guide.   This post starts with the inputs for process 10.2 Manage Communications.    This is one of the most important processes, because I’ve heard from several expert project managers that 90% of all the issues you will face as a project manager have to do ultimately with communications, even if on the surface they may deal with one of the other knowledge areas.

Now let me say a word about the placement of the process within the matrix of the 49 project management processes as seen on p. 556 of the PMBOK® Guide.   There are processes in all of the knowledge areas under the executing process group except for the three basic constraints of scope, schedule (time) and cost.   This is because the work of executing those three knowledge areas falls into the general process 4.3 Direct and Manage Project Work listed under the Project Integration Management knowledge area.  All of the other knowledge areas, including Communications Management, have a process that is in the executing process group.   The title may contain a different word such as Manage, Implement or Conduct, but it’s all having to do with executing the management plan done in the planning process for that knowledge area.

In the case of Communications, process 4.2 Manage Communications carries out the communications that were planned out in process 4.1 Plan Communications Management whose main output was the Communications Management Plan.

Now let’s look into the inputs of the process 4.2 Manage Communications.

10.2.1 Manage Communications Plan

10.2.1.1 Project Management Plan

Remember, the project management plan is really not a single plan, but a collection of

• plans from all of the knowledge areas
• some additional supporting plans (change management, configuration management, and requirements management)
• performance baselines for the three basic constraints of scope, schedule (time) and cost
• supporting documents (such as issue log, change log, risk register, stakeholder register)

Out of those components, the following three are the main inputs to this process.

• Communications management plan–the output of process 10.1 Plan Communications Management, it gives guidelines on all the processes in communications management, whether it deals with planning, managing, or monitoring/controlling the communications on a project.   The components of the Communications management plan include the following (this is a simplified version of the list on p. 377 of the PMBOK® Guide.
  • Stakeholder communication requirements
  • Information to be communicated, reason for the distribution, person responsible for communicating the information, time-frame and frequency of distribution, methods and technologies used to convey the information, persons or groups who receive the information, flow charts of the information flow in the project, including sequence of authorization
  • Special handling procedures:   escalation process and process for releasing confidential information
  • Resources allocated for communication activities (in terms of budget and schedule)
  • Guidelines and templates for project status meetings, team meetings and virtual meetings (agenda, minutes template, etc.), report formats, templates for e-mail messages
  • Constraints derived from legislation or regulation, organizational policies
  • Method for updating and refining the communications management plan
• Resource management plan–recall that “resources” in the 6th Edition PMBOK® Guide refers to not only physical resources but human resources as well.   Therefore the resource management plan (the output of process 9.1 Plan Resource Management), if it includes guidelines on communications with any of the team resources, can also be an input to this process.
• Stakeholder engagement plan–an output of process 13.2 Plan Stakeholder Engagement, this describes the current engagement level (do they know about the project?  And if so, how supportive are they of the project?) and the desired engagement level you would like the stakeholders to be at during the course of the project.   This will input the frequency and type of communications you will be sending the stakeholders and so it is an important input to the process.

10.2.1.2 Project Documents

Many of the important events going on during the project are recorded in some of the project documents, and as such, they will be important inputs into managing the communications regarding those events.

• Change log–the output of process 4.6 Perform Integrated Change Management, this records both the changes that were accepted and will be implemented on the project, as well as those that were rejected.    Those stakeholders that are impacted by the change will be communicated to during the course of this process.
• Issue log–a risk is a potential problem or opportunity, and will be listed on the risk register, but if a negative risk becomes actualized, it becomes not a potential problem, but a real problem, and is put on the issue log.   Those stakeholders that are impacted by the issue and its resolution will be communicated to during the course of this process.
• Lessons learned register–in regards to communications, any lessons learned about the management of communications during the course of this process will be recorded in the lessons learned register (the output of process 4.4 Manage Project Knowledge) so that they can be applied during the remainder of the project.
• Quality report–the quality report, an output of process 8.2 Manage Quality, includes the following information which may need to be communicated to stakeholders who may be concerned with or affected by any corrective actions:
  • Quality issues
  • Product/project improvements (from Quality Control)
  • Process improvements (from Quality Assurance)
• Risk report–an output of process 11.2 (Identify Risks), this presents information on the following which should be communicated to risk owners and other impacted stakeholders:
  • Source of overall product risk
  • Summary information on identified individual project risks
• Stakeholder register–an output of process 13.1 Identify Stakeholders, this is a crucial input for this process, as it identifies the individuals and groups that will need various types of information.

10.2.1.3 Work Performance Reports.

First of all recall the information hierarchy when it comes to projects.

• Work performance data shows the actual results that were generated in the recent reporting period.   John worked 10 hours on the project and Mary worked 10 hours as well.
• Work performance information is the result of taking the work performance data (showing the actual results) with the project management plan to see if there is a variance in what was actually done versus what was planned to be done.   Work performance information is shared with members of the project team.
• Work performance reports are the result of taking the work performance information, which indicates if there is a variance between the actual results and the planned work, and analyzing the variances found to find their source and, if possible, suggest a corrective or preventive action.   Work performance reports are shared with concerned stakeholders, and that is why they are inputs to this communications process.   Examples of work performance reports that may be communicated to stakeholders include the following:
  • Earned value analysis (showing current project performance)
  • Trend lines and graphs (showing future project performance if current project performance is continued)
  • Reserve burndown charts (for contingency reserves associated with implementation of risk responses for triggered risks–see “risk summaries” below)
  • Defect histograms (showing the quantity of defects per category and thus identifying those defects that occur with the most frequency)
  • Contract performance information (showing scope completion and/or quality requirements fulfillment for those vendors who provide procurements to the project in the form of material, components, or possibly even contract workers for the project)
  • Risk summaries (showing which identified risks were triggered and those that can be considered no longer in effect because they are associated with activities that have been completed without incident)

The work performance reports may take many reports such as dashboards, heat reports (showing red for current variance, yellow for potential future variance, and green for no variance), etc.

10.2.1.4 Enterprise Environmental Factors

• Personnel administration policies, especially those that are based on regulations or legal requirements
• Organizational culture and governance framework
• Communication trends and/or practices
• Stakeholder risk thresholds

10.2.1.5 Organization Process Assets

• Corporate policies and procedures for social media
• Corporate policies and procedures with respect to issue, risk, change, and data management
• Organizational communication requirements
• Standardized guidelines for exchange, storage, and retrieval of information
• Historical information from previous similar projects, including the lessons learned repository.

The next post will cover the actual tools and techniques used in this process.

Filed under: Uncategorized | Leave a comment »

There are a lot of elements in the Communications Management Plan, which is the main output of this process.

10.1.3 Plan Communications Management:  Output

10.1.3.1 Communications Management Plan

Here is a simplified list of the elements of the Communications Management Plan, based on the list on p. 377 of the PMBOK® Guide.

• Stakeholder communication requirements
• Information to be communicated, reason for the distribution, person responsible for communicating the information, time-frame and frequency of distribution, methods and technologies used to convey the information, persons or groups who receive the information, flow charts of the information flow in the project, including sequence of authorization
• Special handling procedures:   escalation process and process for releasing confidential information
• Resources allocated for communication activities (in terms of budget and schedule)
• Guidelines and templates for project status meetings, team meetings and virtual meetings (agenda, minutes template, etc.), report formats, templates for e-mail messages
• Constraints derived from legislation or regulation, organizational policies
• Method for updating and refining the communications management plan

10.1.3.2 Project Management Plan Updates

As a result of this process, the stakeholder management plan may be updated with the types of information to be communicated to the various stakeholders.

10.1.3.3. Project Document Updates

• Project schedule–if communication activities have to be added to the schedule, it is updated to reflect them
• Stakeholder register–the communications planned with the various stakeholders may be added to the register.

During the execution phase of the project, the process to be used will 10.2 Manage Communications, which is the topic of the next post.

Filed under: Uncategorized | Leave a comment »

It is sometimes said that 90% of what a project manager does on a project has to do with communications of one form or another.    The process of creating of a communications plan, therefore, is a very important process, and should be taken as seriously as the creation of a schedule or budget of a project.

This post covers the tools and techniques of this process of creating a Communications Management Plan.

10.1.2 Plan Communications Management:  Tools and Techniques

10.1.2.1 Expert Judgment

This, along with meetings (see paragraph 10.1.2.8 below), are generic tools and techniques in that they are used in practically all the planning processes that create management parts for the various knowledge areas on the project.   The areas of expertise that have to do with communication are listed on p. 369 of the PMBOK® Guide.

10.1.2.2 Communications Requirements Analysis

This technique takes the information regarding stakeholders from the stakeholder register and uses it to determine the information needs of the various stakeholders in terms of the type and format of information they need.   Part of the RACI (Responsible-Accountable-Consult-Inform) matrix for the stakeholders is who needs to be consulted in the case of a decision, and then who needs to be informed of the results of a decision.   This can be used to analyze which stakeholders need to be informed before and after any important meeting on the project.   Examples of the communication requirements are given on p. 370 of the PMBOK® Guide.

10.1.2.3 Communication Technology

Common methods used for information exchange and collaboration are established.   The factors that affect the choices of technology are listed on p. 370 of the PMBOK® Guide.

10.1.2.4 Communication Models

The model itself is pretty simple:

• you have a sender who encodes the message
• and then transmits the message via a communication model
• you have a receiver who decodes the message

However, if the sender makes a mistake in encoding the message, if there is noise in the transmission, or if the receiver makes a mistake in decoding the message, then the communication may not be successful.   How does this translate into a practical way of insuring communications are successful?   You need to realize that you’re not just talking about hardware when you are dealing with “noise.”  You may be dealing with internal or subjective causes for the garbling of communication.

For example, there are four types of communication preference (this is not in the PMBOK® Guide, but included in this post as an example):   people who prefer to communicate in terms of

• action (how does the information relate to what the receiver should do?)
• facts (how does the information relate to what the receiver should know?)
• people (how does the information relate to what the receiver should feel?)
• process (how does the information relate to how the receiver should process it?)

People who use the action preference like to give practical bullet-points about what the person should do with the information.   People who use the facts preference like to give the larger context for the information.   People who use the people preference like to establish the relationship with the receiver so that the receiver will trust the information.   People who use the process preference like putting the message in a logical form so that it is easy for the receiver to connect it together.

In Toastmasters, you learn that you have certain preferences, but that your audience is made of people who may have different preferences.   For example, I prefer “facts” and “process” and I used to jump right in and give information to people without setting up any relationship with whom I was sending the information to.   People who have the “people” preference can interpret this as being brusque or rude.    On the other hand, people with the “facts” and “process” preference can see all of that relationship building as a waste of time.   I learned in Toastmasters that you cannot send information to another person without doing the necessary relationship building because in that case they simply don’t care about the information because they don’t know where you are coming from and you haven’t expressed any interest in why they should care about it.  How is it relevant to them?

After working on this preference for over a year, I did another assessment and my score for the “people” preference went way up:  I was able to send information in such a way that people who cared about this preference paid attention to it, and not just those who shared my particular preference.   My goal now is to include the “action” preference in my communications, especially when you are dealing with management, for whom all the theoretical information (what I normally like to send as part of the “facts” preference I have) is useless unless it leads to practical, concrete action.

In any case, this is an example of how you can use a communication model to increase your power to get the message across to everybody on your team.

10.1.2.5 Communication Methods

The three basic types of communication are

• interactive communication (when you interact with team members at a meeting, for example)
• push communication (when you send an e-mail out to team members with important information)
• pull communication (when you put information on a website that team members can access as they see fit)

The various other sub-types of communication and individual communication methods are listed on p. 373 of the PMBOK® Guide.

10.1.2.6 Communication Styles Assessment

This is alluded to in my paragraph on communication models (see paragraph 10.1.2.4 above) but it basically is an analysis of the preferred communication method for stakeholders, which allows you to tailor your communication to their needs more effectively.

Political awareness of the relationships within the organization and cultural awareness of the differences between individuals is very helpful for a project manager.   For cultural awareness, I recommend the book The Culture Map: Breaking Through the Invisible Boundaries of Global Business by Erin Meyer.

10.1.2.7 Data Representation

A stakeholder engagement assessment matrix can help in determining the level of engagement of a stakeholder

• Unaware
• Resistant
• Neutral
• Supportive
• Leading

You find out where they are at the beginning of the project and you show what level of engagement you are trying to influence them to be during the course of the project.   This level of engagement depends on whether they are interested in the project and/or whether they themselves have influence in the organization.

10.1.2.8 Meetings

Like “expert judgment”, meetings are a generic tool and technique used in all planning processes for various knowledge areas.   However, in the context of this process, this means setting the “ground rules” for project meetings so that they are effective (so they get the work done) and efficient (so that they don’t waste people’s time).

The next post deals with the outputs of this process.

Filed under: Uncategorized | Leave a comment »

Like most other knowledge areas, the first process has to do with planning to manage activities on the project with regards to that knowledge area.   The output of this process is the Communications Management Plan.

This post will go over the inputs to this process:

10.1.1 Plan Communications Management

10.1.1.1 Project Charter

The project charter should contain the list of key stakeholders, and their roles and responsibilities within the organization.

10.1.1.2 Project Management Plan

• Resource management plan–the output of process 9.1 Plan Resource Management, provides guidance on managing resources, including human resources, on the project.  The team members and groups identified in this plan will have their communications requirements identified in the communications management plan.
• Stakeholder engagement plan–the output of process 13.2 Plan Stakeholder Engagement; key stakeholders identified in the project charter have stakeholder management strategies outlined in this plan, which should help in creating their communications requirements during this process.

10.1.1.3 Project Documents

• Requirements documentation–the output of process 5.2 Collect Requirements, this may include requirements regarding project stakeholder communications.
• Stakeholder register–the output of process 13.1 Identify Stakeholders, this will be updated as a result of this process with the plan for communications with those stakeholders.

10.1.1.4 Enterprise Environmental Factors

• Stakeholder risk thresholds
• Personnel administration policies (based on governmental laws and/or regulations)
• Organizational culture and governance framework (projectized, functional, or a matrix framework somewhere between the two

10.1.1.5 Organizational Process Assets

• Organization policies and procedures for social media
• Organizational communication requirements
• Standardized guidelines for exchange, storage and retrieval of information
• Historical information and lessons learned repository from previous similar projects

The next post will cover the tools and techniques of this process.

Filed under: Uncategorized | Leave a comment »