We talked earlier about confidence – in the PM team and in the project itself.  Clients need to be confident, establish trust; the PM needs to be confident that team members and contractors/suppliers will carry out their tasks in accordance with the PM Plan; team members need to have confidence in the PM and in each other and all stakeholders need to have confidence in the project’s outcome.  In many organisations, one of the most common problems is the lack or poor quality of communication.  In project management, with time, cost, and quality pressures and constraints, effective communication is not only vital, it is a major means of controlling the project.

Project Control

Project control is a simple process to ensure that everything planned for the project’s completion is delivered according to the project plan and schedule.  The decision to develop a formal or informal control system is entirely based on the level of potential risk and the expected benefits that it may bring to the completion of the project.  Informal control systems may include set meetings, e-mails, and informal supervision while more formal systems involve accounting, internal audits, testing, and other types of periodic risk management reports.

An effective control system includes:

• pre-set project reviews according to the project’s data structure
• continuing reviews in all phases of the project life cycle
• one or more performance metrics

According to the Project Management Institute (PMI), control and monitoring are joint processes that occur within a project and between the project’s environments to detect whether any corrective or preventive actions are needed to keep the project on track.

If you have ever seen films or photographs of Roman chariot racing, you may have seen the charioteer (driver) trying to control up to four horses, at pace, around an arena.  To negotiate the curves at each end of the stadium, the driver had to use great skill to slow down the horses on the inside and allow the horses on the outside to increase their pace so that all horses, the chariot, and the driver could safely negotiate the bends in the course and arrive at the finish line without crashing.  Managing a project is very similar!  The PM must communicate with all team members, clients, contractors, suppliers, and stakeholders to ensure that the project reaches the finish line, within time, cost, and quality (i.e., iron triangle).  Changes to the project’s scope along the way (scope creep) can mean that negotiating the ‘bends’ in the course of the project can become very tricky.  To ensure success and prevent scope creep, communication must be efficient and effective.

In this module we will examine:

• Communication processes and consequences
• Managing project meetings throughout the project
• Final Project Implementation Overview
• Reporting and controlling the project’s true performance with progress, status, and forecast completion reports: Project Closure

Communication

Communications management is about keeping everybody in the loop. The communications planning process concerns defining the types of information you will deliver, who will receive it, the format for communicating it, and the timing of its release and distribution. It turns out that 90% of a project manager’s job is spent on communication so it’s important to make sure everybody gets the right message at the right time.

The first step in defining your communication plan is figuring out what kind of communication your stakeholders need from the project so they can make good decisions. This is called the communications requirements analysis. Your project will produce a lot of information; you don’t want to overwhelm your stakeholders with all of it. Your job is to figure out what they feel is valuable. Communicating valuable information doesn’t mean you always paint a rosy picture. Communications to stakeholders may consist of either good news or bad news. The point is that you don’t want to bury stakeholders in too much information but you do want to give them enough so that they’re informed and can make appropriate decisions.

Communications technology has a major impact on how you keep people in the loop. Methods of communicating can take many forms, such as written reports, conversations, email, formal status reports, meetings, online databases, online schedules, and project websites. You should consider several factors before deciding what methods you’ll choose to transfer information. The timing of the information exchange or need for updates is the first factor. Do you need to procure new technology or systems, or are there systems already in place that will work? The technologies available to you should figure into your plan of how you will keep everyone notified of project status and issues. Staff experience with the technology is another factor. Are there project team members and stakeholders experienced at using this technology, or will you need to train them? Finally, consider the duration of the project and the project environment. Will the technology you’re choosing work throughout the life of the project or will it have to be upgraded or updated at some point? And how does the project team function? Are they located together or spread out across several campuses or locations?

The answers to these questions should be documented in the communication plan.

All projects require a sound communication plan, but not all projects will have the same types of com­munication or the same methods for distributing the information. The communication plan documents the types of information needs the stakeholders have, when the information should be distributed, and how the information will be delivered.

The types of information you will communicate typically include project status, project scope statements and updates, project baseline information, risks, action items, performance measures, project acceptance, and so on. It’s important  that the information needs of the stakeholders be determined as early in the planning phase of the project management life cycle as possible so that as you and your team develop project planning documents, you already know who should receive copies of them and how they should be delivered.

Types of Communication

Completing a complex project successfully requires good communication among team members. If those team members work in the same building, they can arrange regular meetings, simply stop by each other’s office space to get a quick answer, or even discuss a project informally at other office functions. Many projects are performed by teams that interact primarily through electronic communication and are, therefore, called virtual teams. To avoid miscommunication that can harm trust and to include team members in a project culture, the project team needs a plan for communicating reliably and in a timely manner. This planning begins with understanding two major categories of communication.

Synchronous Communications

If all the parties to the communication are taking part in the exchange at the same time, the communication is synchronous. A telephone or Skype conference call is an example of synchronous communication. The following are examples of synchronous communications:

• Live meeting: Gathering of team members at the same location
• Conference call: A telephone call in which several people participate
• Audio conference: Like a conference call, but conducted online using software like Skype
• Computer-assisted conference: Audio conference with a connection between computers that can display a document or spreadsheet that can be edited by both parties
• Video conference: Similar to an audio conference but with live video of the participants. Some laptop computers have built-in cameras to facilitate video conferencing
• IM (instant messaging): Exchange of text or voice messages using pop-up windows on the participants’ computer screens
• Texting: Exchange of text messages between mobile phones, pagers, or personal digital assistants (PDAs)—devices that hold a calendar, a contact list, a task list, and other support programs

Modern communication technologies make it possible to assemble project teams from anywhere in the world. We have seen how the adoption of Zoom, Microsoft Teams and other communication tools during the pandemic have facilitated our work. We just need to be aware of time zone differences when working with project teams across the world. Most people work during daylight hours, which can make synchronous meetings difficult if the participants are in different time zones. However, it can be an advantage in some circumstances too.

Asynchronous Communications

Getting a team together at the same time can be a challenge—especially if they are spread out across time zones. Many types of communication do not require that the parties are present at the same time. This type of communication is asynchronous. There are several choices for asynchronous communications.

Email

Electronic mail (email) is widely used to coordinate projects and to communicate between team members. It has several valuable characteristics for project management:

• Information can be sent to a list of team members.
• Messages can be saved to document the process in case of a misunderstanding or miscommunication.
• Files can be attached and distributed.

Project Blog

A blog is an online journal that can be private, shared by invitation, or made available to the world. Some project managers keep a journal in which they summarize the day’s challenges and triumphs and the decisions they made. They return to this journal at a later date to review their decision-making process after the results of those decisions are known to see if they can learn from their mistakes. Many decisions in project management are made with incomplete knowledge, and reflecting on previous decisions to develop this decision-making skill is important to growth as a project manager.

Really Simple Syndication (RSS)

Some projects are directly affected by external factors such as political elections, economic trends, corporate mergers, technological or scientific breakthroughs, or weather. To keep informed about these factors, you can subscribe to online news sources. A technology that facilitates this process is Really Simple Syndication (RSS). Web pages with RSS news feeds have labeled links.

If the user clicks on the RSS feed, news from the website is automatically sent to the user’s news reader, such as Google Reader. The newsreader can be set to filter the news for keywords to limit the stories to those that are relevant to the project.

Assessing New Communication Technologies

New technologies for communicating electronically appear with increasing frequency. Using a new technology that is unfamiliar to the team increases the technology complexity, which can cause delays and increase costs. To decide if a new technology should be included in a communications plan, seek answers to the following questions (Business Dictionary):

• Does the new communication technology provide a competitive advantage for the project by reducing cost, saving time, or preventing mistakes?
• Does the project team have the expertise to learn the new technology quickly?
• Does the company offer support such as a help desk and equipment service for new communication technology?
• What is the cost of training and implementation in terms of time as well as money?

Communication Plan Template

So how do you create a communication plan?

1. Identify your stakeholders (to whom)
2. Identify stakeholder expectations (why)
3. Identify communication necessary to satisfy stakeholder expectations and keep them informed (what)
4. Identify time-frame and/or frequency of communication messages (when)
5. Identify how the message will be communicated (the stakeholder’s preferred method) (how)
6. Identify who will communicate each message (who)
7. Document items – templates, formats, or documents the project must use for communicating.

Microsoft Project offers a variety of communication plan template examples; covering 100s of activities across the whole project lifecycle. Each Template is tailored specifically for a project.

The Final project implementation phase

After you have carefully planned your project, you will be ready to start the project implementation phase, the third phase of the project management life cycle. The implementation phase involves putting the project plan into action. It’s here that the project manager will coordinate and direct project resources to meet the objectives of the project plan. As the project unfolds, it’s the project manager’s job to direct and manage each activity, every step of the way. That’s what happens in the implementation phase of the project life cycle: you follow the plan you’ve put together and handle any problems that come up.

The implementation phase is where you and your project team actually do the project work to produce the deliverables. The word “deliverable” means anything your project delivers. The deliverables for your project include all of the products or services that you and your team are performing for the client, customer, or sponsor, including all the project management documents that you put together.

The steps undertaken to build each deliverable will vary depending on the type of project you are undertaking, and cannot therefore be described here in any real detail. For instance, engineering and telecommunications projects will focus on using equipment, resources, and materials to construct each project deliverable, whereas computer software projects may require the development and implementation of software code routines to produce each project deliverable. The activities required to build each deliverable will be clearly specified within the project requirements document and project plan.

Your job as project manager is to direct the work, but you need to do more than deliver the results. You also need to keep track of how well your team performs. The implementation phase keeps the project plan on track with careful monitoring and control processes to ensure the final deliverable meets the acceptance criteria set by the customer. This phase is typically where approved changes are implemented.

Most often, changes are identified by looking at performance and quality control data. Routine performance and quality control measurements should be evaluated on a regular basis throughout the implementation phase. Gathering reports on those measurements will help you determine where the problem is and recommend changes to fix it.

Change Control

When you find a problem, you can’t just make a change, because it may be too expensive or take too long to do. You will need to look at how it affects the triple constraint (time, cost, scope) and how it impacts project quality. You will then have to figure out if it is worth making the change. If you evaluate the impact of the change and find that it won’t have an impact on the project triple constraint, then you can make the change without going through change control. Change control is a set of procedures that lets you make changes in an organized way.

Any time you need to make a change to your plan, you must start with a change request. This is a document that either you or the person making the request must complete. Any change to your project must be documented so you can figure out what needs to be done, by when, and by whom.

Once the change request is documented, it is submitted to a change control board. A change control board is a group of people who consider changes for approval. Not every change control system has a board but most do. The change request could also be submitted to the project sponsor or management for review and approval. Putting the recommended changes through change control will help you evaluate the impact and update all the necessary documents. Not all changes are approved, but if the changes are approved, you send them back to the team to put them in place.

The implementation phase uses the most project time and resources, and as a result, costs are usually the highest during this phase. Project managers also experience the greatest conflicts over schedules in this phase. You may find as you are monitoring your project that the actual time it is taking to do the scheduled work is longer than the amount of time planned.

When you absolutely have to meet the date and you are running behind, you can sometimes find ways to do activities more quickly by adding more resources to critical path tasks. That’s called crashing. Crashing the schedule means adding resources or moving them around to to bring the project back into line with the schedule. Crashing always costs more and doesn’t always work. There’s no way to crash a schedule without raising the overall cost of the project. So, if the budget is fixed and you don’t have any extra money to spend, you can’t use this technique.

Sometimes you’ve got two activities planned to occur in sequence, but you can actually do them at the same time. This is called fast tracking the project. On a software project, you might do both your user acceptance testing (UAT) and your functional testing at the same time, for example. This is pretty risky. There’s a good chance you might need to redo some of the work you have done concurrently. Crashing and fast tracking are schedule compression tools. Managing a schedule change means keeping all of your schedule documents up to date. That way, you will always be comparing your results to the correct plan.

After the deliverables have been physically constructed and accepted by the customer, a phase review is carried out to determine whether the project is complete and ready for closure.

Project Completion

Every project needs to end and that’s what project completion is all about in the last phase of the project life cycle. The whole point of the project is to deliver what you promised. By delivering everything you said you would, you make sure that all stakeholders are satisfied and all acceptance criteria have been met. Once that happens, your project can end.

Project completion is often the most neglected phase of the project life cycle. Once the project is over, it’s easy to pack things up, throw some files in a drawer, and start moving right into the initiation phase of the next project. Hold on. You’re not done yet.

The key activities in project completion are gathering project records; disseminating information to formalize acceptance of the product, service, or project; and performing project closure. As the project manager, you will need to review project documents to make certain they are up-to-date. For example, perhaps some scope change requests were implemented that changed some of the characteristics of the final product. The project information you are collecting during this phase should reflect the characteristics and specifications of the final product. Don’t forget to update your resource assignments as well. Some team members will have come and gone over the course of the project. You need to double-check that all the resources and their roles and responsibilities are noted.

Once the project outcomes are documented, you’ll request formal acceptance from the stakeholders or customer. They’re interested in knowing if the product or service of the project meets the objectives the project set out to accomplish. If your documentation is up-to-date, you’ll have the project results at hand to share with them.

Contract Closure

How and Why to Close a Project

^{(Click the image  to access the video)}

Contracts come to a close just as projects come to a close. Contract closure is concerned with completing and settling the terms of the contracts let for the project. It supports the project completion process because the contract closure process determines if the work described in the contracts was completed accurately and satisfactorily. Keep in mind that not all projects are performed under contract so not all projects require the contract closure process. Obviously, this process applies only to those phases, deliverables, or portions of the project that were performed under contract.

Contract closure updates the project records, detailing the final results of the work on the project. Con­tracts may have specific terms or conditions for completion. You should be aware of these terms or conditions so that project completion isn’t held up because you missed an important detail. If you are administering the contract yourself, be sure to ask your procurement department if there are any special conditions that you should be aware of so that your project team doesn’t inadvertently delay contract project closure.

One of the purposes of the contract closure process is to provide formal notice to the seller, usually in written form, that the deliverables are acceptable and satisfactory or have been rejected. If the product or service does not meet the expectations, the vendor will need to correct the problems before you issue a formal acceptance notice. Before the contract is closed, any minor items that need to be repaired or completed are placed on a punch list, which is a list of all the items found by the client or team or manager that still remain to be done. Hopefully, quality audits have been performed during the course of the project, and the vendor was given the opportunity to make corrections earlier in the process than the closing phase. It’s not a good idea to wait until the very end of the project and then spring all the problems and issues on the vendor at once. It’s much more efficient to discuss problems with your vendor as the project progresses because it provides the opportunity for correction when the problems occur.

The project team will then work on all of the items on the punch list, building a small schedule to complete the remaining work. If the number of items on the punch list is too large or the amount of work is significant, the project team continues to work on the project. Once the punch list becomes smaller, the project manager begins closing down the project, maintaining only enough staff and equipment to support the team that is working on the punch list.

If the product or service does meet the project’s expectations and is acceptable, formal written notice to the seller is required, indicating that the contract is complete. This is the formal acceptance and closure of the contract. It’s your responsibility as the project manager to document the formal acceptance of the contract. Many times the provisions for formalizing acceptance and closing the contract are spelled out in the contract itself.

If you have a procurement department handling the contract administration, they will expect you to inform them when the contract is complete and will in turn follow the formal procedures to let the seller know the contract is complete. However, you will still note the contract completion in your copy of the project records.

Releasing the Project Team

Releasing project team members is not an official process. However, it should be noted that at the conclusion of the project, you will release your project team members, and they will go back to their functional managers or get assigned to a new project. You will want to keep their managers, or other project managers, informed as you get closer to project completion, so that they have time to adequately plan for the return of their employees. Let them know a few months ahead of time what the schedule looks like and how soon they can plan on using their employees on new projects. This gives the other managers the ability to start planning activities and scheduling activity dates.

Final Payments

The final payment is usually more than a simple percentage of the work that remains to be completed. Completing the project might involve fixing the most difficult problems that are disproportionately expensive to solve, so the final payment should be large enough to motivate the vendor to give the project a high priority so that the project can be completed on time.

If the supplier has met all the contractual obligations, including fixing problems and making repairs as noted on a punch list, the project team signs off on the contract and submits it to the accounting department for final payment. The supplier is notified that the last payment is final and completes the contractual agreement with the project.

Post-Project Evaluations

Before the team is dissolved and begins to focus on the next project, a review is conducted to capture the lessons that can be learned from this project, often called a lessons-learned meeting or document. The team explores what went well and captures the processes to understand why they went well. The team asks if the process is transferable to other projects. The team also explores what did not go well and what people learned from the experience. The process is not to find blame, but to learn.

Quality management is a process of continual improvement that includes learning from past projects and making changes to improve the next project. This process is documented as evidence that quality management practices are in use. Some organizations have formal processes for changing work processes and integrating the lessons learned from the project so other projects can benefit. Some organizations are less formal in the approach and expect individuals to learn from the experience and take the experience to their next project and share what they learned with others in an informal way. Whatever type of approach is used, the following elements should be evaluated and the results summarized in reports for external and internal use.

Trust and Alignment Effectiveness

The project leadership reviews the effect of trust—or lack of trust—on the project and the effectiveness of alignment meetings at building trust. The team determines which problems might have been foreseen and mitigated and which ones could not have been reasonably predicted. What were the cues that were missed by the team that indicated a problem was emerging? What could the team have done to better predict and prevent trust issues?

Schedule and Budget Management

The original schedule of activities and the network diagram are compared to the actual schedule of events. Events that caused changes to the schedule are reviewed to see how the use of contingency reserves and float mitigated the disruption caused by those events. The original estimates of contingency time are reviewed to determine if they were adequate and if the estimates of duration and float were accurate. These activities are necessary for the project team to develop expertise in estimating schedule elements in future projects—they are not used to place blame.

A review of budget estimates for the cost of work scheduled is compared to the actual costs. If the estimates are frequently different from the actual costs, the choice of estimating method is reviewed.

Risk Mitigation

After the project is finished, the estimates of risk can be reviewed and compared to the events that actually took place. Did events occur that were unforeseen? What cues existed that may have allowed the team to predict these events? Was the project contingency sufficient to cover unforeseen risks? Even if nothing went wrong on this project, it is not proof that risk mitigation was a waste of money, but it is useful to compare the cost of avoiding risk versus the cost of unexpected events to understand how much it cost to avoid risk.

Procurement Contracts

The performance of suppliers and vendors is reviewed to determine if they should still be included in the list of qualified suppliers or vendors. The choice of contract for each is reviewed to determine if the decision to share risk was justified and if the choice of incentives worked.

Customer Satisfaction

Relationships with the client are reviewed and decisions about including the client in project decisions and alignment meetings are discussed. The client is given the opportunity to express satisfaction and identify areas in which project communication and other factors could be improved. Often a senior manager from the organization interviews the client to develop feedback on the project team performance.

A general report that provides an overview of the project is created to provide stakeholders with a summary of the project. The report includes the original goals and objectives and statements that show how the project met those goals and objectives. Performance on the schedule and budget are summarized and an assessment of client satisfaction is provided. A version of this report can be provided to the client as a stakeholder and as another means for deriving feedback.

Senior Management

The report to senior management contains all the information provided to the stakeholders in a short executive summary. The report identifies practices and processes that could be improved or lessons that were learned that could be useful on future projects.

Archiving of Document

The documents associated with the project must be stored in a safe location where they can be retrieved for future reference. Signed contracts or other documents that might be used in tax reviews or lawsuits must be stored. Organizations will have legal document storage and retrieval policies that apply to project documents and must be followed. Some project documents can be stored electronically.

Care should be taken to store documents in a form that can be recovered easily. If the documents are stored electronically, standard naming conventions should be used so documents can be sorted and grouped by name. If documents are stored in paper form, the expiration date of the documents should be determined so they can be destroyed at some point in the future. The following are documents that are typically archived:

• Charter documents
• Scope statement
• Original budget
• Change documents
• DPCI ratings
• Manager’s summary—lessons learned
• Final DPCI rating