4squareviews

Identification of risks is something which requires the project manager to cast the net far and wide in order to find sources that will give information on potential risks to the project.   These range from the usual “generic” tools and techniques of expert judgment and meetings, to those more specific to this risk management knowledge area, especially in the area of data analysis.

11.2.2.1 Expert Judgment

Experts should be consulted who have expertise in individual project risks (especially those who were involved previously in similar projects) and those stakeholders with a grasp of risk management who can weigh in on the overall project risks based on their expertise in the field.

11.2.2.2  Data Gathering

There are many ways of gathering data regarding risk:  through written documents (checklists), through interviews with individual stakeholders, and group meetings with project team members and stakeholders in order to brainstorm regarding potential sources of risk.

• Brainstorming–ideas are generated under the guidance of a facilitator either in a free-form fashion or by using more structured techniques.   A particular useful starting point for these discussions is the Risk Breakdown Structure, which categorizes risk by its potential source.
• Checklists–this is using lists of potential risks that were developed based on previous similar projects.   Of course, even if a previous project was similar, care must be taken to account for the differences by going over all risks on the checklist to make sure they actually apply in the current project.
• Interviews–conversations with stakeholders and subject matter experts in the field of risk management can be used to get contributions to the list of potential risks on the project.

11.2.2.3  Data Analysis

• Root cause analysis–just as root cause analysis can be used to discover the underlying causes that lead to an actual problem (a defect), it can also be used to identify the causes of a potential problem.   You start with the potential problem, such as cost overruns and schedule delays, and go back to find out those factors which might lead to this problem.
• Assumption and constraint analysis–a project is conceived with a set of assumptions and within a series of constraints (schedule, cost, quality, scope, etc.).  The validity of these assumptions and constraints are analyzed to determine which pose a potential risk to the project.
• SWOT analysis–if you take positive and negative factors both internal to and external to the project organization, you will get the strengths/weaknesses (internal), and opportunities/threats (external) to the project, which is wear the acronym SWOT comes from.
• Document analysis–project documents, particularly the project charter, are analyzed to get high-level risks on the current project, and project files from previous similar projects are also analyzed to get the individual risks from those projects.

11.2.2.4  Interpersonal and Team Skills

Especially when using the data gathering technique of brainstorming, it requires special skills to be a facilitator of one those sessions because you have to encourage an open mode of discussion where ideas will not be shot down when given by any member of the discussion group, thus encouraging creativity in the process.

11.2.2.5  Prompt Lists

This is a predetermined list of risk categories.   A checklist is a list of actual risks from previous projects; the prompt list just gives the risk categories, and is a useful tool to be used in conjunction with the brainstorming technique mentioned in the paragraph 11.2.2.2 above.

11.2.2.6  Meetings

Like putting together the WBS, putting together a list of potential risks requires brainstorming which is best done in the setting of a group meeting.

The next post will cover the outputs of this process.

Filed under: Uncategorized | Leave a comment »

After the first planning process which creates the Risk Management Plan, which shows how to do risk management on the project, this is the first process that starts of considering individual risks on the project.

Risks are found among all the other constraints on the project, so the inputs will come from the knowledge areas for scope, schedule, cost, quality, and resources.   In particular, you will want to look at the management plans for these knowledge areas, the three performance baselines (scope, schedule, and cost), and project documents from these knowledge areas.

11.2.1  Identify Risks:  Inputs

11.2.1.1  Project Management Plan

The components of the overall project management plan that are inputs to this process include:

• Requirements management plan–the requirements management plan may indicate which project objectives that are particularly at risk
• Schedule management plan–the schedule management plan may identify areas that are subject to uncertainty or ambiguity with respect to the schedule.   Note:   activities on the critical path will automatically be of higher risk to the project, as any delay in their execution will result in a delay in the final deadline of the project.
• Cost management plan–the cost management plan may identify areas that are subject to uncertainty or ambiguity with respect to the budget.
• Quality management plan–the quality management plan may identify areas that are subject to uncertainty or ambiguity, or where key assumptions with regards to quality have been made that might give rise to risk.
• Resource management plan–the resource management plan may identify areas that are subject to uncertainty or ambiguity, or where key assumptions with regards to critical resources have been made that might give rise to risk.
• Risk management plan–includes the following elements relevant to this process:
  • Lists risk-related roles and responsibilities on the project
  • Indicates how risk management activities are included in the budget and schedule
  • Describes categories of risk
• Scope baseline–indicates deliverables in the scope statement which might give rise to risk.   The WBS can be used as a framework for identifying individual risks.
• Schedule baseline–May be used to identify milestones and deliverable due dates that are subject to uncertainty or ambiguity, or where key assumptions with regards to the schedule have been made that might give rise to risk.
• Cost baseline–May be used to identify costs or funding requirements that are subject to uncertainty or ambiguity, or where key assumptions with regards to costs have been made that might give rise to risk.

11.2.1.2  Project Documents

• Assumption log–assumptions and constraints recorded in the assumption log may give rise to individual project risks and may also influence the level of overall project risk.
• Cost estimation–cost estimates provide quantitative assessments of project costs, ideally expressed as a range, indicating the degree of risk, where a structured review of the documents may indicate that the current estimate is insufficient and poses a risk to the project.
• Duration estimation–duration estimates provide quantitative assessments of project durations, ideally expressed as a range, indicating the degree of risk, where a structured review of the documents may indicate that the current estimate is insufficient and poses a risk to the project.
• Issue log–issues recorded in the issue log may give rise to individual project risks and may also influence the level of overall project risk.
• Lessons learned register–this is where lessons learned during the process of risk identification will be recorded and reviewed in later processes of the project to determine whether similar risks might recur during the remainder of the project.
• Requirements documentation–the project requirements should be analyzed during this process to identify those that could be at risk.
• Resource requirements–resource requirements provide quantitative assessments of project resource requirements, ideally expressed as a range, indicating the degree of risk, where a structured review of the documents may indicate that the current estimate is insufficient and poses a risk to the project.
• Stakeholder register–Indicates which individuals or groups might participate in identifying risks to the project.   It also details those individuals who are available to act as risk owners.

11.2.1.3  Agreements

If the project requires the external procurement of resources, the agreements may have information such as milestone dates, delivery dates, contract type, acceptance criteria, and awards and penalties that can present threats or opportunities.

11.2.1.4  Procurement Documentation

If the project requires the external procurement of resources, the initial procurement documentation should be reviewed, because procuring goods and services from outside the organization may increase or decrease overall project risk and introduce additional individual project risks (for example, if the procurement of a critical component has a delay in the delivery date).

11.2.1.5  Enterprise Environmental Factors

• Published material, including commercial risk databases or checklists
• Benchmarking results
• Industry studies of similar projects

11.2.1.6  Organizational Process Assets

• Project files, including actual data and checklists, from previous similar projects
• Risk statement formats
• Organizational and project process controls for risk

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

Filed under: Uncategorized | Leave a comment »

This post covers the outputs of the process 11.1 Plan Risk Management.   Actually, there is only output and that is the Risk Management Plan.   Here are the elements that should go into such a plan:

• Risk strategy–the organization’s general approach to managing risk on projects
• Methodology–specific approaches, tools (like the probability and impact matrix) and data sources that will be used to perform risk management on the project.
• Rules and responsibilities–who is the lead of the risk management team and who are the team members?   Who will support the activities within the organization?  What are the specific responsibilities of each member of the team?
• Funding–this clarifies the protocols for application of contingency and management reserves.   Remember, contingency reserves are for those risks that are on the risk register (the “known unknowns”) vs. those risks that are not (the “unknown unknowns.”
• Schedule–defines when and how often risk management processes will be performed throughout the project life cycle, and establishes those risk management activities that will be included into the project schedule.
• Risk categories–a risk breakdown structure or RBS is a representation of potential sources of risk on a project.   Creating an RBS helps the project team consider the full range of sources from which individual project risks may arise.
• Stakeholder risk appetite–this should be expressed in terms of measurable risk thresholds around each project objective in order to determine the acceptable level of overall project risk exposure.
• Definitions of risk probability and impact–used in process 11.3 Perform Qualitative Risk Analysis, the probability and impact matrix divides these concepts into qualitative thresholds like “low”, “medium” and “high”.   The definition of these thresholds is important to establish at the beginning of the project.
• Probability and impact matrix–not only the definitions of the individual thresholds, but how these thresholds will interact must be determined ahead of time.   Also, the overall strategies of dealing with these categories should be defined.   Will the company accept those risks in the “low” category, mitigate those in the “medium” category, and avoid those in the “high” category, for example?
• Reporting formats–this shows how the outcomes of the risk management process 11.6 Implement Risk Responses and 11.7 Monitor Risks will be reported to stakeholders.
• Tracking–shows how risk activities will be tracked using the risk register and how risk management activities will be audited.

The next process starts the specific risk management planning process of identifying risks.   The inputs to that process are in the following post.

Filed under: Uncategorized | Leave a comment »

The process of creating the Risk Management Plan is like all the similar processes for other knowledge areas.   Consequently, there are some tools and techniques which are “generic”, that is, common to all of these processes that create a management plan that is a component of the overall Project Management Plan.    One tool and technique, Data Analysis, uses stakeholder analysis and is specific to this particular process.

11.1.2.1  Expert Judgment

In creating the risk management plan, it’s pretty clear that you will want to consult with SMEs (subject matter experts) who have expertise in the area of risk management.   This may include the following:

• Experts in risk management in general, especially those who are familiar with the organization’s approach to risk management
• Those who have handled risk management on other similar projects and who can therefore advise on the types of risk likely to be encountered on the current project

11.1.2.2   Data Analysis

Stakeholder analysis can be used to determine the risk tolerance of key stakeholders on the project.

11.1.2.3 Meetings

Project team members, members of the organization who are responsible for risk management, and key stakeholders are those whom you want to invite to meetings to discuss the risk management plan.   The meetings will define the risk management activities that will be done in all of the other six processes in this knowledge area.

The next post will be the outputs of this process, the main one being the Risk Management Plan.

Filed under: Uncategorized | Leave a comment »

Although risk management is among the most complex of the knowledge areas when it comes to the planning process group, the first process is the same as all the others.   It is Plan Risk Management, which has as its output the Risk Management Plan.   This post goes over the inputs to this process.

11.1.1  Plan Risk Management:  Inputs

11.1.1.1  Project Charter

The project charter contains a high-level project description and project boundaries, meaning not just what is within the scope of the project but also what is excluded from the scope.   High-level risks that the project sponsor is aware of and is concerned about can be put in the project charter as well.   That’s why it’s the first course for a project manager to find out about the risks associated with the project.   Sometimes there is a connection between the high-level scope description, including the exclusions, and the high-level description of the risks.   It may be possible that something may considered “out of bounds” for the project for the very reason that it represents taking on a higher risk than the sponsor it comfortable with.

11.1.1.2  Project Management Plan

All of the components of the project management plan, particularly the subsidiary management plans for all the other knowledge areas, and the additional ones having to do with requirements (dealing with scope management), and change/configuration management (dealing with integration management), are all sources of risk and so any risk management plan needs to be consistent with these other components.

11.1.1.3  Project Documents

The stakeholder register is probably the most important input for this process.   You will want to discuss their attitude towards overall risk, as well as getting their opinion on the identification of individual risks on the project.

11.1.1.4  Enterprise Environmental Factors

Overall risk thresholds set by the organization or by key stakeholders will influence how much risk you intend to take on during the course of the project.

11.1.1.5  Organizational Process Assets

• Organizational risk policy
• Risk statement formats, templates for the risk management plan, risk categories organized into a risk breakdown structure, and common definitions of risk concepts and terms
• Authority levels of decision making (this will affect your risk responses)
• Roles and responsibilities within the organization, especially as it pertains to risk management
• Lessons learned repository from previous similar projects

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

Filed under: Uncategorized | 1 Comment »

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 »