Project Governance – renierbotha ltd

PERT Charts

March 9, 2019June 19, 20192 Comments

A PERT chart is a project management tool used to schedule, organize, and coordinate tasks within a project. PERT stands for Program Evaluation Review Technique, a methodology developed by the U.S. Navy in the 1950s to manage the Polaris submarine missile program. A similar methodology, the Critical Path Method (CPM) was developed for project management in the private sector at about the same time.

A PERT chart presents a graphic illustration of a project as a network diagram consisting of numbered nodes (either circles or rectangles) representing events, or milestones in the project linked by labelled vectors (directional lines) representing tasks in the project. The direction of the arrows on the lines indicates the sequence of tasks. In the diagram, for example, the tasks between nodes 1, 2, 4, 8, 9 and 10 must be completed in sequence. These are called dependent or serial tasks. The tasks between nodes 2 and 3, and nodes 2 and 4 are not dependent on the completion of one to start the other and can be undertaken simultaneously. These tasks are called parallel or concurrent tasks. Tasks that must be completed in sequence but that don’t require resources or completion time are considered to have event dependency. These are represented by dotted lines with arrows and are called dummy activities. For example, the dashed arrow linking nodes 6 and 9 indicates that the system files must be converted before the user test can take place, but that the resources and time required to prepare for the user test (writing the user manual and user training) are on another path. Numbers on the opposite sides of the vectors indicate the time allotted for the task.

The PERT chart is sometimes preferred over the Gantt Chart, another popular project management charting method, because it clearly illustrates task dependencies. On the other hand, the PERT chart can be much more difficult to interpret, especially on complex projects. Frequently, project managers use both techniques.

Also Read…

Management Communication Plan

Project Failure? How to Recover and/or Prevent…

February 13, 2019June 25, 2019Leave a comment

Statistics indicate that 68% of all IT projects are bound to failure!

The PMI’s definition of a high-performing organisation, is a company that completes 80% or more projects on time, on budget, and meeting original goals. In a low-performing organization, only 60% or fewer projects hit the same marks.

Projects fail for all kinds of reasons:

Stakeholders can change their objectives
Key team members can leave for other companies
Budgets can disappear
Materials/Vendors can be delayed
Priorities can go un-managed
Running out of time
…and others

In this post:

> How to prevent project failure (with some statistics)

> How to recover a failing project

How to prevent project failure

Prevention is the best cure, so what can you do to prevent projects from failing? Here is some statistics…

Organisations that invest in proven project management practices waste 28 times less money because more of their strategic initiatives are completed successfully.
Source: PMI’s Pulse of the Profession Survey, 2017.
77% of high-performing organizations have actively-engaged project sponsors, while only 44% of low-performing organizations do.
Source: PMI’s Pulse of the Profession Survey, 2017.
46% of CIOs say that one of the main reasons IT projects fail is weak ownership.
Source: The Harvey Nash/KPMG CIO Survey, 2017.
33% of IT projects fail because senior management doesn’t get involved and requirements/scope change mid-way through the project.
Source: A Replicated Survey of IT Software Project Failures by Khaled El Emam and A. Güneş Koru, 2008.
78% of respondents feel that business is out of sync with project requirements and business stakeholders need to be more involved in the requirements process.
Source: Doomed from the Start Industry Survey by Geneca, 2011.
45% of the managers surveyed say business objectives are unclear to them.
Source: Doomed from the Start Industry Survey by Geneca, 2011.
Companies that align their enterprise-wide PMO (project management office) to strategyhad 38% more projects meet original goals than those that did not. They also had 33% fewer projects deemed failures.
Source: PMI’s Pulse of the Profession Survey, 2017.
40% of CIOs say that some of the main reasons IT projects fail is an overly optimistic approach and unclear objectives.
Souce: The Harvey Nash/KPMG CIO Survey, 2017.
Poor estimation during the planning phase continues to be the largest (32%) contributor to IT project failures.
Source: PwC 15th Annual Global CEO Survey, 2012.
Projects with effective communication are almost twice as likely to successfully deliver project scope and meet quality standards than projects without effective communication (68% vs 32% and 66% vs 33%, respectively.)
Source: PwC 15th Annual Global CEO Survey, 2012.

How to recover a failing project

These statistics show that the odds are not in your favour. It is inevitable that you will have to deal with a failing project or two, some time within your career… You could turn the odds in your favour by taking action in recovering failing projects.

Here are four steps you can use that could save a failing project — backed up by original research from Gartner, iSixSigma, PMI Project Zone Congress, The Institution of Engineering and Technology, and Government CIO Magazine. Follow these four steps and salvage your failing project!

Step 1: Stop and Evaluate

Step 1 – Big action items:

Issue a “stop work” order
Talk with everyone

Metrics/Indicators: The right project Management Information (MI) should give you the needed early warning signs when things are not going according to plan and heading to failure. These signs should drive you to action, as rescuing a failing a project is not a task to be sneezed at. It takes planning, and the process can consume weeks of key resources time and effort.

People: To help ease the pain of stopping a project, work with the team members’ managers (resource owners) to identify and assign interim work. As people are your most important asset, it is important to keep them productively engaged while you are evaluating and re-planning your project recovery.

Project artefacts/deliverables: Make sure all the project artefacts and deliverables are safely stored where it cannot be tampered with for the interim period.

Communicate: (clear, concise, and concrete) – Communicate to your team why their project is on hold. Spend the needed time to learn as much as you can about each team member’s opinions of the project and of each other. Learning that their project will be put on hold will inevitably create distrust. Transparency and tailored messaging is the best way to mitigate bad feelings. See blog posts “Management Communication Plan” and “Effective Leadership Communication”

Project/Delivery Manager (You):Check your ego. Go to the major stakeholders and ask for anonymous feedback on their view of the overall project. When evaluating their responses, don’t forget to consider company culture and politics and how those factors may have played a role in forming the stakeholders’ opinions.

Step 2: Why your project is failing – Root causes

Step 2 – Big action items:

Establish allowable solutions for project rescue (including project termination)
Identify root causes of the problem
Identify risks to project continuation

Determine the root causes: Most times the cause of project problems is not immediately obvious. Even the best project managers — those with excellent project plans, appropriate budgets, and fantastic scope control — also struggle, on occasion, with project failure.

You’ll only get to the bottom of it by doing a Route Cause Analysis (RCA) and the “5 Why’s” technique can help with that. See “The 5 Whys for route cause analysis”

Surface-level answers are often the temptation when project managers reach this step. They might focus on the complexity of their project, their outdated project management softwareor methodology, their unclear objectives or their stakeholders’ lack of involvement. All of these problems are so generic that they don’t provide enough insight to create real solutions.

Apply the “5 Whys” and be specific when answering these questions… i.e.

Why are objectives unclear?
Why aren’t users getting involved?
Why are the estimates wrong?

Of course, some of these answers may be hard to hear, and solutions can range from the challenging to impossible. Remember: if these issues could be easily remedied, they would have been addressed and resolved. Even simple problems — like a team member leaving — can take months to fix. Ask yourself: are you using the right technology for the job? Are your dependencies so external that project control is simply out of your hands?

If you’re still struggling to figure out where the root of your project failure is, consider these seven issues – the most common causes of project failure.

Complexity
External
Financial
Operational
Organizational
Schedule
Technology

Risk Assessment:What are the risks when trying to salvage the project? Are those risks worth it? Is the project salvageable? Answer these questions before moving on.

Step 3: War Room

Step 3 – Big action items:

Set up the war room
Re-engage stakeholders
Create a tentative plan to move forward

Okay, General!

Assemble the team, seat them all together, and work through a rescue workshop. You’re in the mentality of “kill” or “fix” you’re done fact finding, asking question for further research, or finding other excuses to delay the process. That should all have been done in step two. You’re focussed to figure out what to do with your project.

The “war room” will be intense – all members need to be prepared and the right mindset of problem solving!

The decision-making process could take two hours or several days. All key decision makers must be present. As this is not always possible some executives may prefer to be called in as the meeting is nearing its end, where team members can present prepared options.

To get the most out of the workshop, conduct the meeting face to face (take the meeting offline). Try to limit the meeting to ten people, including the most important stakeholders (like the sponsors), project manager, senior team members including technical representative to give insight to plan feasibility.

The war room is serious business – prepare for it. Create an agenda to go over findings, from quantitative reporting to team member interviews. Encourage pre-war-room collaboration (covering the outcomes of steps 1 and 2) toward the ideal shared result.

When you start the war room meeting, all project material should be readily available. That’s your fact base driving factual data driven assumptions and decisions.

Using the facts, the purpose of the war room, in essence, is to answer three deceptively complex questions:

Is the business case still valid?
If the business case is no longer valid, is there potential for a new, reimagined, justified business case?
(If so): Are the added costs for project rescue worth it?

Encourage your task force to focus on identifying the project’s primary drivers (i.e. business need/value, budget, schedule, scope, or quality). Ideally, there should only be one driver that controls the outcome of the project – this is usually the business need for the project’s deliverables.

Sometimes the primary driver is beyond repair. For example, if the core due date has passed and it was aligned with a market cycle (ex: Black Friday to Christmas), then the project is irremediable.

Least case scenario: Clearly articulate the primary goal. Then identify what the team can do with the least amount of effort. Develop a scenario that costs the company the least and gets closest to achieve the primary goal.

Project termination considerations: If the primary goal cannot be achieved, prepare a recommendation to terminate the project… but not without scrutiny. Several variables must be considered and thoroughly addressed in the war room.

Consider trade-offs that could make the worst-case scenario more possible than originally thought.
Think about the potential backlash from killing a project.
- How does that decision affect business strategy?
- Other projects?
- Public perceptions?
- Potential future clients? All these variables must be considered and thoroughly addressed in the war room.

Alternatives: Should the least-case scenario makes sense, explore more alternatives. Are there alternative options that can deliver more of the project’s objectives, and consider how adding those solutions to your plan can create additional potential scenarios — positive or negative.

New project charter: Write down the main points of your plan in a revised project charter.

Replacement project option: It’s not uncommon for stakeholders to propose a replacement project instead of a rescue. That’s a totally viable option — kill the project, salvaging only essential, functional portions of the original attempt, and work to create a new plan.If the decision is to completely start over, abandon project rescue altogether. Justify the replacement project on its own merit (a new scope, budget, resource plan, etc.)

Step 4: Set your project in motion

Step 4 – Big action items:

Finalise how your project will move forward
Confirm responsibilities
Reset organizational expectations.

Following your war room meeting, your next steps are all about follow-up. The real project rescue starts here and is the most challenging part of project rescue.

Re-engage stakeholders around the contents of the new project plan and complete the detail with precise commitments for each team member. Plans should be finalised within two days.

Be careful as hesitation and procrastination can limit team commitment and lower morale. You’re the general; get your troops ready to re-engage and to stay committed and focussed!

Reconfirm all project metrics: Validate all project aspects especially resources, as people has been allocation to productive work while you were reworking your rescue plan.

As the project rolls forward, be sure to detail the new project’s profile, scope, and size to the core team and beyond. Emphasize expected outcomes and explain how this project aligns with the company’s goals. Don’t shy away from communicating what these changes can mean on a big-picture scale. While you may receive some feedback, be direct: the project is proceeding.

Make sure all communication is clear. Confirm that stakeholders accept their new responsibilities to the project.

Management Communication Plan

August 18, 2014July 31, 20194 Comments

https://www.pmi.org/learning/library/secrets-running-project-status-meetings-7009

A good project Communications Management Plan ensures that you have effective communications throughout the life of your project. Everyone knows that 80% of a Project Manager’s time is spent communicating; therefore, to be an effective Project Manager you must have good communications skills. Our Communications Management Plan template helps you to think through the communication requirements for your project and plan for the most effective communications. This template is based on the communications guidelines according to the fourth edition of the PMBOK.

If you like this Communications Management Plan Template please do share with your colleagues.

COMMUNICATIONS MANAGEMENT PLAN TEMPLATE

Introduction

The purpose of the Communications Management Plan is to define the communication requirements for the project and how information will be distributed. The Communications Management Plan defines the following:

What information will be communicated—to include the level of detail and format
How the information will be communicated—in meetings, email, telephone, web portal, etc.
When information will be distributed—the frequency of project communications both formal and informal
Who is responsible for communicating project information
Communication requirements for all project stakeholders
What resources the project allocates for communication
How any sensitive or confidential information is communicated and who must authorize this
How changes in communication or the communication process are managed
The flow of project communications
Any constraints, internal or external, which affect project communications
Any standard templates, formats, or documents the project must use for communicating
An escalation process for resolving any communication-based conflicts or issues

This Communications Management Plan sets the communications framework for this project. It will serve as a guide for communications throughout the life of the project and will be updated as communication needs change. This plan identifies and defines the roles of persons involved in this project. It also includes a communications matrix which maps the communication requirements of this project. An in-depth guide for conducting meetings details both the communications rules and how the meetings will be conducted, ensuring successful meetings. A project team directory is included to provide contact information for all stakeholders directly involved in the project.

Communications Management Approach

Approximately 80% of a Project Manager’s time is spent communicating. Think about it – as a Project Manager you are spending most of your time measuring and reporting on the performance of the project, composing and reading emails, conducting meetings, writing the project plan, meeting with team members, overseeing work being performed, meeting with clients over lunch and many more activities related to your projects.

You should give considerable thought to how you want to manage communications on this project. By having a solid communications management approach you’ll find that many project management problems can be avoided. In this section give an overview of your communications management approach.

The Project Manager will take a proactive role in ensuring effective communications on this project. The communications requirements are documented in the Communications Matrix presented in this document. The Communications Matrix will be used as the guide for what information to communicate, who is to do the communicating, when to communicate it and to whom to communicate.

As with most project plans, updates or changes may be required as the project progresses or changes are approved. Changes or updates may be required due to changes in personnel, scope, budget, or other reasons. Additionally, updates may be required as the project matures and additional requirements are needed. The project manager is responsible for managing all proposed and approved changes to the communications management plan. Once the change is approved, the project manager will update the plan and supporting documentation and will distribute the updates to the project team and all stakeholders. This methodology is consistent with the project’s Change Management Plan and ensures that all project stakeholders remain aware and informed of any changes to communications management.

Communications Management Constraints

All projects are subject to limitations and constraints as they must be within scope and adhere to budget, scheduling, and resource requirements. Project planning and documentation are no exception to this rule. There may also be legislative, regulatory, technology, or organizational policy requirements which must be followed as part of communications management. These constraints must be clearly understood and communicated to all stakeholders. While communications management is arguably one of the most important aspects of project management, it must be done in an effective manner and within the constraints of the allocated budget, time, and resources.

All project communication activities will occur within the project’s approved budget, schedule, and resource allocations. The project manager is responsible for ensuring that communication activities are performed by the project team and without external resources which will result in exceeding the authorized budget. Communication activities will occur in accordance with the frequencies detailed in the Communication Matrix in order to ensure the project adheres to schedule constraints. Any deviation of these timelines may result in excessive costs or schedule delays and must be approved by the project sponsor.

ABC Corp. organizational policy states that where applicable, standardized formats and templates must be used for all formal project communications. The details of these policy requirements are provided in the section titled “Standardization of Communication” in this document.

ABC Corp. organizational policy also states that only a Vice President or higher level employee may authorize the distribution of confidential information. The project manager is responsible for ensuring that approval is requested and obtained prior to the distribution of any confidential information regarding this project.

Stakeholder Communication Requirements

Most projects consist of a broad range of stakeholders all of whom may have differing interests and influence on the project. As such, it is important for project teams to determine the communication requirements of these stakeholders in order to more effectively communicate project information. There are a number of methods for determining stakeholder communication requirements; however, it is imperative that they are completely understood in order to effectively manage their interest, expectations, and influence and ensure a successful project.

As part of identifying all project stakeholders, the project manager will communicate with each stakeholder in order to determine their preferred frequency and method of communication. This feedback will be maintained by the project manager in the project’s Stakeholder Register. Standard project communications will occur in accordance with the Communication Matrix; however, depending on the identified stakeholder communication requirements, individual communication is acceptable and within the constraints outlined for this project.

In addition to identifying communication preferences, stakeholder communication requirements must identify the project’s communication channels and ensure that stakeholders have access to these channels. If project information is communicated via secure means or through internal company resources, all stakeholders, internal and external, must have the necessary access to receive project communications.

Once all stakeholders have been identified and communication requirements are established, the project team will maintain this information in the project’s Stakeholder Register and use this, along with the project communication matrix as the basis for all communications.

Roles

Project Sponsor
The project sponsor is the champion of the project and has authorized the project by signing the project charter. This person is responsible for the funding of the project and is ultimately responsible for its success. Since the Project Sponsor is at the executive level communications should be presented in summary format unless the Project Sponsor requests more detailed communications.

Program Manager
The Program Manager oversees the project at the portfolio level and owns most of the resources assigned to the project. The Program Manager is responsible for overall program costs and profitability as such they require more detailed communications than the Project Sponsor.

Key Stakeholders
Normally Stakeholders includes all individuals and organizations who are impacted by the project. For this project we are defining a subset of the stakeholders as Key Stakeholders. These are the stakeholders with whom we need to communicate with and are not included in the other roles defined in this section. The Key Stakeholders includes executive management with an interest in the project and key users identified for participation in the project.

Change Control Board
Also knows as the Change Authorisation Board or CAB, the Change Control Board is a designated group which reviews technical specifications and authorizes changes within the organizations infrastructure. Technical design documents, user impact analysis and implementation strategies are typical of the types of communication this group requires.

Customer
You should identify the customer if the project is the result of a solicitation. In such a case, the customer will be involved in reviewing prototypes, approval of designs and implementation stages and acceptance of the final project the project generates.

The customer for this project is . As the customer who will be accepting the final deliverable of this project they will be informed of the project status including potential impacts to the schedule for the final deliverable or the product itself.

Project Manager
The Project Manager has overall responsibility for the execution of the project. The Project Manager manages day to day resources, provides project guidance and monitors and reports on the projects metrics as defined in the Project Management Plan. As the person responsible for the execution of the project, the Project Manager is the primary communicator for the project distributing information according to this Communications Management Plan.

Project Team (Working Groups)
The Project Team is comprised of all persons who have a role performing work on the project. The project team needs to have a clear understanding of the work to be completed and the framework in which the project is to be executed. Since the Project Team is responsible for completing the work for the project they played a key role in creating the Project Plan including defining its schedule and work packages. The Project Team requires a detailed level of communications which is achieved through day to day interactions with the Project Manager and other team members along with weekly team meetings. Depending on the nature of the work, the project team can be organised into Working Groups.

Steering Committee
The Steering Committee includes management representing the departments which make up the organization. The Steering Committee provides strategic oversight for changes which impact the overall organization. The purpose of the Steering Committee is to ensure that changes within the organization are effected in such a way that it benefits the organization as a whole. The Steering Committee requires communication on matters which will change the scope of the project and its deliverables.

Technical Lead
The Technical Lead is a person on the Project Team who is designated to be responsible for ensuring that all technical aspects of the project are addressed and that the project is implemented in a technically sound manner. The Technical Lead is responsible for all technical designs, overseeing the implementation of the designs and developing as-build documentation. The Technical Lead requires close communications with the Project Manager and the Project Team.

Project Team Directory

The following table presents contact information for all persons identified in this communications management plan. The email addresses and phone numbers in this table will be used to communicate with these people.

Role	Name	Title	Organization/ Department	Email	Phone
Project Sponsor	A. White	VP of Technology	IT	a.white@abc.com	(555) 555-1212
Program Manager	B. Brown	PMO Manager	PMO	b.brown@abc.com	(555) 555-1213
Project Manager	C. Black	Project Manager	PMO	c.black@abc.com	(555) 555-1212
Project Stakeholders	See Stakeholder Register	See Stakeholder Register	See Stakeholder Register	See Stakeholder Register	See Stakeholder Register
Customer	J. Doe XYZ Corp.	Manager	IT	j.doe@xyz.com	(555) 555-8121
Project Team
Technical Lead

Communication Methods and Technologies

Many times, the methods and technologies used to communicate are just as important of a consideration as the information being communicated. Imagine a large project with many stakeholders who all have different technological capabilities. Some may have access to a share drive while others do not. Some may have access to video teleconferencing and others only have telephone and email capabilities. In order to be effective, project information must be communicated to everyone involved by some method using available technology. Determining communication methods and what technologies are available should be part of determining stakeholder communication requirements.

The project team will determine, in accordance with ABC Corp. organizational policy, the communication methods and technologies based on several factors to include: stakeholder communication requirements, available technologies (internal and external), and organizational policies and standards.

ABC Corp. maintains a SharePoint platform within the PMO which all projects use to provide updates, archive various reports, and conduct project communications. This platform enables senior management, as well as stakeholders with compatible technology, to access project data and communications at any point in time. SharePoint also provides the ability for stakeholders and project team members to collaborate on project work and communication.

For stakeholders who do not have the ability to access SharePoint, a web site will also be established for the project. Access to the website will be controlled with a username and password. Any stakeholders identified who are not able to access SharePoint will be issued a unique username and password in order to access the web site. The project manager is responsible for ensuring all project communications and documentation are copied to the web site and that the content mirrors what is contained on the SharePoint platform.

ABC Corp. maintains software licenses for MS Project software. All project teams are responsible for developing, maintaining, and communicating schedules using this software. PERT Charts are the preferred format for communicating schedules to stakeholders. The project schedule will be maintained on both the SharePoint platform and the project website.

All project communication and documentation, in addition to being maintained on the SharePoint platform and project website, will be archived on the internal ABC Corp. shared drive which resides in the PMO program directory. Organizational naming conventions for files and folder will be applied to all archived work.

Communications Matrix

The following table identifies the communications requirements for this project.

Communications Matrix example :: Download the file here…

Report Drumbeat example :: Download the file here…

Communication Flowchart

Flowcharts provide a visual representation of a process or processes which often allow a better understanding of how the process is intended to work. Project communications may be extremely complex depending on the size and scope of the project and the number of stakeholders. A flowchart provides all stakeholders with a better understanding of the steps involved with the distribution of all project communications.

The communication flowchart below was created to aid in project communication. This flowchart provides a framework for the project team to follow for this project. However, there may be occasions or situations which fall outside of the communication flowchart where additional clarification is necessary. In these situations the Project Manager is responsible for discussing the communication with the Project Sponsor and making a determination on how to proceed.

Guidelines for Meetings

Meeting Agenda
Meeting Agenda will be distributed 5 business days in advance of the meeting. The Agenda should identify the presenter for each topic along with a time limit for that topic. The first item in the agenda should be a review of action items from the previous meeting.

Meeting Minutes
Meeting minutes will be distributed within 2 business days following the meeting. Meeting minutes will include the status of all items from the agenda along with new action items and the Parking Lot list.

Action Items
Action Items are recorded in both the meeting agenda and minutes. Action items will include both the action item along with the owner of the action item. Meetings will start with a review of the status of all action items from previous meetings and end with a review of all new action items resulting from the meeting. The review of the new action items will include identifying the owner for each action item.

Meeting Chair Person
The Chair Person is responsible for distributing the meeting agenda, facilitating the meeting and distributing the meeting minutes. The Chair Person will ensure that the meeting starts and ends on time and that all presenters adhere to their allocated time frames.

Note Taker
The Note Taker is responsible for documenting the status of all meeting items, maintaining a Parking Lot item list and taking notes of anything else of importance during the meeting. The Note Taker will give a copy of their notes to the Chair Person at the end of the meeting as the Chair Person will use the notes to create the Meeting Minutes.

Time Keeper
The Time Keeper is responsible for helping the facilitator adhere to the time limits set in the meeting agenda. The Time Keeper will let the presenter know when they are approaching the end of their allocated time. Typically a quick hand signal to the presenter indicating how many minutes remain for the topic is sufficient.

Parking Lot
The Parking Lot is a tool used by the facilitator to record and defer items which aren’t on the meeting agenda; however, merit further discussion at a later time or through another forum.

A parking lot record should identify an owner for the item as that person will be responsible for ensuring follow-up. The Parking Lot list is to be included in the meeting minutes.

Communication Standards

Standardization is a proven way to simplify the complexities of project management communications. Many organizations develop and use standard templates or formats for the various communication tools used throughout projects. Standard templates and formats may be applied to certain types of project meetings or specific types of communication (i.e. emails, status reports, etc.). By using standardization, organizations can help ensure that its project teams and stakeholders have a thorough understanding of what is expected and achieve consistent and effective communications.

In addition to standard templates and/or formats, organizations may standardize file naming or sharing conventions. An organization may use SharePoint or some other type of Web Portal/Network tool (blogs, message boards, etc.) as a standard platform from which to share information and communicate. Additionally, an organization may have standard file naming conventions for their stored data on their internal share drives. Many of these tools and new technologies are used in today’s projects with team members and stakeholders often spread over wide geographic areas. Standardization provides a level of simplicity to an organization’s communication platforms and improves effectiveness and efficiency.

For this project, ABC Corp. will utilize standard organizational formats and templates for all formal project communications. Formal project communications are detailed in the project’s communication matrix and include:

Kickoff Meeting – project team will utilize ABC Corp. standard templates for meeting agenda and meeting minutes. Additionally, any slides presented will use the ABC Corp. standard slideshow template.

Project Team Meetings – project team will utilize ABC Corp. standard templates for meeting agenda and meeting minutes. Additionally, any slides presented will use the ABC Corp. standard slideshow template.

Technical Design Meetings – project team will utilize ABC Corp. standard templates for meeting agenda and meeting minutes. Additionally, any slides presented will use the ABC Corp. standard slideshow template.

Monthly Project Status Meetings – project team will utilize ABC Corp. standard templates for meeting agenda and meeting minutes. Additionally, any slides presented will use the ABC Corp. standard slideshow template.

Project Status Reports – project team will utilize ABC Corp. standard templates for meeting agenda and meeting minutes. Additionally the standard project status report document, available on the share drive, will be used to provide project status.

Informal project communications should be professional and effective but there is no standard template or format that must be used.

Communication Escalation Process

As issues or complications arise with regards to project communications it may become necessary to escalate the issue if a resolution cannot be achieved within the project team. Project stakeholders may have many different conflicting interests in a given project. While escalations are a normal part of project management, there must be a documented process that defines how those escalations will take place.

Efficient and timely communication is the key to successful project completion. As such, it is imperative that any disputes, conflicts, or discrepancies regarding project communications are resolved in a way that is conducive to maintaining the project schedule, ensuring the correct communications are distributed, and preventing any ongoing difficulties. In order to ensure projects stay on schedule and issues are resolved, ABC Corp. will use its standard escalation model to provide a framework for escalating communication issues. The table below defines the priority levels, decision authorities, and timeframes for resolution.

Priority	Definition	Decision Authority	Timeframe for Resolution
Priority 1	Major impact to project or business operations. If not resolved quickly there will be a significant adverse impact to revenue and/or schedule.	Vice President or higher	Within 4 hours
Priority 2	Medium impact to project or business operations which may result in some adverse impact to revenue and/or schedule.	Project Sponsor	Within one business day
Priority 3	Slight impact which may cause some minor scheduling difficulties with the project but no impact to business operations or revenue.	Project Manager	Within two business days
Priority 4	Insignificant impact to project but there may be a better solution.	Project Manager	Work continues and any recommendations are submitted via the project change control process

** NOTE: Any communication including sensitive and/or confidential information will require escalation to VP level or higher for approval prior to external distribution.

Glossary of Communication Terminology

Term	Definition
Communication	The effective sending and receiving of information. Ideally, the information received should match the information sent. It is the responsibility of the sender to ensure this takes place.
Stakeholder	Individuals or groups involved in the project or whose interests may be affected by the project’s execution or outcome.
Communications Management Plan	Portion of the overall Project Management Plan which details how project communications will be conducted, who will participate in communications, frequency of communications, and methods of communications.
Escalation	The process which details how conflicts and issues will be passed up the management chain for resolution as well as the timeframe to achieve resolution

Also Read:

Effective Leadership Communication

PMI – Secrets of Running Project Status meetings