Project Management Plan

The Monitor and Control Project Work process is broad reaching and is concerned with all of the work of the project rather than a specific area like schedule or cost or human resources. To monitor and control the work, you'll need the project management plan, which includes all of the subsidiary plans we've talked about so far, so that you know what was planned and can take action where needed to get the project back in line with the plan. As a reminder, some of those subsidiary plans include the scope management plan, the cost management plan, the human resource plan, the communications plan, and more. And don't forget the important baselines: scope, schedule, and cost.

Schedule Forecasts

Schedule forecasts are an output of the Control Schedule process. Schedule forecasts help determine the progress of the project schedule as it compares to the schedule baseline. This can involve a series of formulas to determine elements such as when a milestone was scheduled to be completed versus when it was actually completed. We will look at all of the formulas in the next chapter when we talk about controlling the project schedule.

Cost Forecasts

Cost forecasts are an output of the Control Costs process. Much like the schedule forecasts, cost forecasts help us determine project progress as far as costs are concerned. This includes formulas to determine factors such as what we anticipated spending at this point in time versus what was actually spent. These formulas are known as earned value management formulas, and we will look at them as well as the cost forecasts formulas in the next chapter when we talk about controlling project costs.

Time Series Methods  These forecasting methods use historical data to predict future performance. Earned value, moving average, extrapolation, trend estimation, linear prediction, and growth curve are some of the methods that fall into this category. We'll cover earned value in Chapter 11.

Causal/Econometric Methods  Causal methods are based on the ability to identify variables that may cause or influence the forecast. A drop in interest rates, for example, may spur an increase in home sales. The methods included in this category are regression analysis, autoregressive moving average (ARMA), and econometrics.

Judgmental Methods  If your mom is anything like mine, you were taught not to be judgmental. This category of forecasting does just that, only it doesn't judge people. It uses opinions, intuitive judgments, and probability estimates to determine possible future results. Methods within this category include composite forecasts, the Delphi method, surveys, technology forecasting, scenario building, and forecast by analogy.

Other Methods  Other types of forecasting methods include simulation (like Monte Carlo analysis), probabilistic forecasting, and ensemble forecasting.

Validated Changes

Validated changes are an output of the Control Quality process. Validated changes are those changes that have been inspected and determined to be correct.

Work Performance Information

Work performance information concerns gathering and analyzing the performance data, or work results, from the Monitoring and Controlling processes. This might include performance information such as the status of deliverables, schedule forecast data, cost forecast data, the status of change requests, costs incurred to date, and more. Work performance information is reported to the stakeholders according to the requirements laid out in the communications management plan and the stakeholder management plan.

Enterprise Environmental Factors

Some of the enterprise environmental factors to consider in this process include the project management information system, government or industry standards, the risk tolerance levels of your stakeholders, and work authorization systems.

A work authorization system is a subsystem of the project management system. This is a formal, documented procedure that describes how to authorize work and how to begin that work in the correct sequence and at the right time. This system describes the steps needed to issue a work authorization, the documents needed, the method or system you'll use to record and track the authorization information, and the approval levels required to authorize the work. You should understand the complexity of the project and balance the cost of instituting a work authorization system against the benefit you'll receive from it. This might be overkill on small projects, and verbal instructions might work just as well. For purposes of the exam, understand that project work is assigned and committed via a work authorization system.

Work is usually authorized using a form that describes the task, the responsible party, anticipated start and end dates, special instructions, and whatever else is particular to the activity or project. Depending on the organizational structure, the work is generally assigned and authorized by either the project manager or the functional manager. Remember that the system includes documentation on who has the authority to issue work authorization orders.

Organizational Process Assets

The organizational process assets for which the PMBOK^® Guide notes should be considered during this process include financial controls, the communication needs for the organization, change control processes, issue management, process measurements, risk control processes, and lessons learned.

We talked about lessons learned in Chapter 9. Remember that lessons learned should be performed throughout the life of the project. Capturing and analyzing lessons learned will help you continually improve project management processes and will ultimately improve your project success rates.

There are four tools and techniques of this process: expert judgment, analytical techniques, project management information system, and meetings, all of which we've covered previously, so we'll move right to the outputs next.

Change Requests

Remember from Chapter 9, “Conducting Procurements and Sharing Information,” that change requests may take the form of corrective actions, preventive actions, or defect repairs. Corrective actions bring the work of the project into alignment with expected future performance. Preventive actions are implemented to help reduce the probability of negative project risks. Defect repairs either correct or replace components that are substandard or malfunctioning.

Work Performance Reports

Work performance reports are the primary output of this process. It's here that the work performance data and work performance information gathered and analyzed throughout the Monitoring and Controlling processes are documented and reported to the stakeholders as outlined in the communications management plan. Work performance reports might take many forms, including status reports, issues or action item logs, project documents, and so on. They may be represented in hardcopy form or electronic form or both.

Work performance reports may range from simply stated status reports to highly detailed reports. Dashboards are an example of a simple report that may use indicators like red-yellow-green to show the status of each area of the project at a glance. Red means the item being reported is in trouble or behind schedule, yellow means it's in danger of falling behind schedule and corrective action should be taken, and green means all is well.

More detailed reports may include the following elements according to the PMBOK^® Guide:

• Analysis of project performance for previous periods
• Risk and issue status
• Work completed in the current reporting period
• Work expected to be completed during the next reporting period
• Changes approved in the current reporting period (or a summary if there are numerous changes)
• Results of variance analysis
• Time completion forecasts and cost forecasts
• Other information stakeholders want or need to know

The information contained in these reports is used at status meetings or in meetings with the project sponsor to generate action, to make decisions, or to inform. This information should be in written format (such as a status report or memo) and stored electronically with other project documents. Work performance reports are considered a subset of project documents and should be shared and distributed according to your communications plan.

Project Management Plan and Document Updates

Project management plan updates may include updates to one or more of the management plans, including schedule, cost, or quality, and updates to the baselines, including scope, schedule, and cost, may be required.

Project documents updates may include updates to forecasts, performance reports, and the issue log.

Approved Change Requests

Sometimes as you get into the work of the project, you'll discover that changes need to be made. This could entail changes to the contract as well. Approved change requests are used to process the project or contract changes and might include things such as modifications to deliverables, changes to the product or service of the project, changes in contract terms, or termination for poor performance.

Generally speaking, contracts end for three reasons: cause, convenience, or default. When a contract ends for cause, it's because one of the parties has violated the terms of the contract. A contract ends for convenience when one of the parties determines they no longer wish to participate in the contract. And contracts that end by default are those where one of the parties has failed to perform according to the terms of the contract.

Contracts can be amended at any time prior to contract completion, provided the changes are agreed to by all parties and conform to the change control processes outlined in the contract.

Work Performance Reports

Work performance reports include technical documentation that is developed by the seller according to the terms of the contract as well as work performance information as it relates to the seller (or vendor).

Work performance information in the Control Procurements process concerns monitoring vendor work results and examining the vendor's deliverables. This includes monitoring their work results against the contract statement of work and making sure activities are performed correctly and in sequence. You'll need to determine which deliverables are complete and which ones have not been completed to date. You'll also need to consider the quality of the deliverables and the costs that have been incurred to date.

Vendors request payment for the goods or services delivered in the form of seller invoices. Seller invoices should describe the work that was completed or the materials that were delivered and should include any supporting documentation necessary to describe what was delivered. The contract should state what type of supporting documentation is needed with the invoice.

Contract Change Control System

Much like the management plans found in the Planning processes, the contract change control system describes the processes needed to make contract changes. Because the contract is a legal document, changes to it require the agreement of all parties. A formal process must be established to process and authorize (or deny) changes. (Authorization levels are defined in the organizational policies.)

The purpose of the contract change control system is to establish a formal process for submitting change requests. It documents how to submit changes, establishes the approval process, and outlines authorization levels. It includes a tracking system to number the change requests and record their status. The procedures for dispute resolution are spelled out in the contract change control system as well.

The change control system, along with all the management plan outputs, becomes part of the Perform Integrated Change Control process that I'll discuss later in this chapter.

Procurement Performance Reviews

Procurement performance reviews examine the seller's performance on the contract to date. These reviews can be conducted at the end of the contract or at intervals during the contract period. Procurement reviews examine the contract terms and seller performance for elements such as these:

• Meeting project scope
• Meeting project quality
• Staying within project budgets
• Meeting the project schedule

The performance reviews themselves might take the form of quality audits or inspections of documents as well as the work of the product itself, or they may be part of a status review. The point of the review is to determine where the seller is succeeding at meeting scope, quality, cost, and schedule issues, for example, or where they're not measuring up. If the seller is not in compliance, action must be taken to either get them back into compliance or terminate the contract. The yardstick you're using to measure their performance against is the contract SOW and the terms of the contract. When the RFP is included as part of the contract, you might also use it to determine contract compliance.

Inspections and Audits

I talked about quality audits as part of the Perform Quality Assurance process. The idea is the same here. The buyer, or some designated third party, will physically inspect the work of the seller and perform audits to determine whether there are any deficiencies in the seller's product or service.

Performance Reporting

Performance reporting is a large part of project management. This tool and technique entails providing your managers and stakeholders with information about the vendor's progress in meeting the contract objectives.

Payment Systems

Vendors submit seller invoices as an input to this process, and the payment systems tool and technique is used to issue payments. The organization might have a dedicated department, such as accounts payable, that handles vendor payments, or it might fall to the project manager. In either case, follow the policies and procedures the organization has established regarding vendor payments and make sure the payments themselves adhere to the contract terms.

Claims Administration

Claims administration involves documenting, monitoring, and managing contested changes to the contract. Changes that cannot be agreed on are called contested changes. Contested changes usually involve a disagreement about the compensation to the vendor for implementing the change. You might believe the change is not significant enough to justify additional compensation, whereas the vendor believes they'll lose money by implementing the change free of charge. Contested changes are also known as disputes, claims, or appeals. These can be settled directly between the parties themselves, through the court system, or by a process called arbitration. Arbitration involves bringing all parties to the table with a third, disinterested party who is not a participant in the contract to try to reach an agreement. The purpose of arbitration is to reach an agreement without having to go to court. Arbitration is a form of Alternative Dispute Resolution (ADR) and could be a named tool in the contract for resolving disputes.

Records Management System

It has been a while since I've talked about documentation, but discussing the records management system reminds me of the importance of having an organized system for contract documentation. A records management system involves not just documentation but policies, control functions, and automated tools. These can all be considered part of the project management information system you use to manage project documents and should include your contract documents. Records management systems typically index documents for easy filing and retrieval.

Change Requests

Requested contract changes are coordinated with the Direct and Manage Project Work and Perform Integrated Change Control processes so that any changes impacting the project are communicated to the project team and appropriate actions are put into place to realign the objectives. This might also mean you'll have to change the project management plan, the cost baseline, and/or the schedule baseline. That requires you to jump back to the Planning process group to bring the project management plan, or other documents, up-to-date. Once the plan is updated, the Direct and Manage Project Work process might require changes as well to get the work of the project in line with the new plan. Remember that project management is an iterative process, and it's not unusual to revisit the Planning or Executing processes, particularly as changes are made or corrective actions are put into place.

Contract changes will not always impact the project management plan, however. For example, late delivery of key equipment probably would impact the project management plan, but changes in the vendor payment schedule probably would not. It's important that you are kept abreast of any changes to the contract so that you can evaluate whether the project management plan needs adjusting.

Project Documents Updates

Here's your favorite topic again. This output includes (but isn't limited to) updating all of the following:

• Contract or other procurement documents
• Performance information
• Warranties
• Financial information (such as invoices and payment records)
• Inspection and audit results
• Supporting schedules
• Approved and unapproved changes

The records management system I talked about earlier is the perfect place to keep all these documents.

Organizational Process Assets Updates

Organizational process assets updates consist of organizational policies, procedures, and so on. Three elements of this output relate to contracts:

Correspondence  Correspondence is information that needs to be communicated in writing to either the seller or the buyer. Examples include changes to the contract, clarification of contract terms, results of buyer audits and inspections, and notification of performance issues. You'll use correspondence to inform the vendor if their performance is unsatisfactory. If they don't correct it, you'll use correspondence again to notify a vendor that you're terminating the contract because performance is below expectations and is not satisfying the requirements of the contract.

Payment Schedules and Requests  Many times, contracts are written such that payment is made based on a predefined performance schedule. For example, perhaps the first payment is made after 25 percent of the product or service is completed, or maybe the payment schedule is based on milestone completion. In any case, as the project manager, you will verify that the vendor's work (or delivery) meets expectations before the payment is authorized. It's almost always your responsibility as the project manager to verify that the terms of the contract to date have or have not been satisfied. Depending on your organizational policies, someone from the accounting or procurement department might request written notification from you that the vendor has completed a milestone or made a delivery. Monitoring the work of the vendor is as important as monitoring the work of your team members.

If the procurement department is responsible for paying the contractor, then that department manages the payment schedule (which is one of the terms of the contract). The seller submits a payment request, an inspection or review of their performance is conducted to make certain the terms of the contract were fulfilled, and the payment is made.

Seller Performance Evaluation  Seller performance evaluation is a written record of the seller's performance on the contract and is prepared by the buyer. It should include information about whether the seller successfully met contract dates, whether the seller fulfilled the requirements of the contract and/or contract statement of work, whether the work was satisfactory, and so on. Seller performance evaluations can be used as a basis for terminating the existing contract if performance is not satisfactory. They can also be used to determine penalty fees in the case of unsatisfactory performance or incentives that are due according to the terms of the contract. They should also indicate whether the vendor should be allowed to bid on future work. Seller performance evaluations can also be included as part of the qualified sellers lists.

Information Management Systems

Information management systems are used to record, store, and distribute information about the project, including cost, schedule progress, and performance information. According to the PMBOK^® Guide, spreadsheet analysis, presentations, table reporting, and graphic capabilities are types of distribution formats.

Expert Judgment

In this process, experts from all areas—including the project team, consultants, stakeholders, industry groups, the PMO, and others as appropriate—are consulted to help interpret the information gathered during the Monitoring and Controlling processes and make decisions and take action where needed to align the work of the project with the project management plan. One of the obvious reasons you want to keep the work results on track with the plan is so that stakeholder expectations are realized.

Meetings

Meetings in this process include meetings involving the project team, vendors, functional managers, stakeholders, and others you will be working with on the project. Meetings may be formal, informal, in person, or online. The important point here is that you are meeting with all those involved in your project and exchanging information. Meetings with the project team are concerned with updating project performance information and communicating those updates to the appropriate parties and working with stakeholders to provide them with requested project information.

One of the important meetings you will conduct throughout the life of the project is the status review meeting. Status meetings are a type of interactive communication and are important functions during the course of the project. The purpose of the status meeting is to provide updated information regarding the progress of the project. These are not show-and-tell meetings. If you have a prototype to demo, set up a different time to do that. Status meetings are meant to exchange information and provide project updates. They are a way to formally exchange project information. It's not unusual for projects to have three or four status meetings conducted for different audiences. They can occur between the project team and project manager, between the project manager and stakeholders, between the project manager and users or customers, between the project manager and the management team, and so on.

Notice that the project manager is always included in status review meetings. Take care that you don't overburden yourself with meetings that aren't necessary or meetings that could be combined with other meetings. Having any more than three or four status meetings per month is unwieldy.

The project manager is usually the expediter of the status meeting. As such, it's your job to use status meetings wisely. Don't waste your team's time or the stakeholders’ time either. Notify attendees in writing of the meeting time and place. Publish an agenda prior to the meeting, and stick to the agenda during the meeting. Every so often, summarize what has been discussed during the meeting. Don't let side discussions lead you down rabbit trails, and keep irrelevant conversations to a minimum. It's also good to publish status meeting notes at the conclusion of the meeting, especially if any action items resulted from the meeting. This will give you a document trail and serve as a reminder to the meeting participants of what actions need to be resolved and who is responsible for each action item.

It's important that project team members are honest with the project manager and that the project manager is in turn honest about what they report. A few years ago, a department in my agency took on a project of gargantuan proportions and unfortunately didn't employ good project management techniques. One of the biggest problems with this project was that the project manager did not listen to the highly skilled project team members. The team members warned of problems and setbacks, but the project manager didn't want to hear about it. The project manager took their reports to be of the “Chicken Little” ilk and refused to believe the sky was falling. Unfortunately, the sky was falling! Because the project manager didn't believe the reports, she refused to report the true status of the project to the stakeholders and oversight committees. Millions of dollars were wasted on a project that was doomed for failure while the project manager continued to report that the project was on time and activities were completed when in fact they were not.

There are hundreds of project stories like this, and I'll bet you've got one or two from your experiences as well. Don't let your project become the next bad example. Above all, be honest in your reporting. No one likes bad news, but bad news delivered too late along with millions of dollars wasted is a guaranteed career limiting move.

The Purpose of the Change Control System

Change control systems are documented procedures that describe how the deliverables of the project and associated project documentation are controlled, changed, and approved. They also often describe how to submit change requests and how to manage change requests. They may include preprinted change request forms that provide a place to record general project information such as the name and project number, the date, and the details regarding the change request. Change control systems are usually subsystems of the configuration management system.

The change control system also tracks the status of change requests, including their approval status. Not all change requests will receive approval. Those changes that are not approved are also tracked, communicated to the appropriate stakeholders, and filed in the change control log for future reference.

The change control system might define the level of authority needed to approve changes, if it wasn't previously defined in the configuration management system. Some change requests could receive approval based on the project manager's decision; others might need to be reviewed and formally approved by the project sponsor, executive management, and so on.

Procedures that detail how emergency changes are approved should be defined as well. For example, you and your team might be putting in some weekend hours and be close to the completion of a deliverable when you discover that thing 1 will not talk to thing 2 no matter what you do. The team brainstorms and comes up with a brilliant solution that requires a change request. Do you stop work right then and wait until the change control board or committee can meet sometime next week and make a decision, or do you—the project manager—make the decision to go forward with this solution and explain the change to the appropriate parties later? That answer depends on the change procedures you have in place to handle situations like this and on the authority you have to make emergency changes as outlined in the change control system.

Many organizations have formal change control or change request systems in place. If that's the case, you can easily adopt those procedures and use the existing system to manage project change. But if no procedures exist, you'll have to define them.

There are three objectives you should know about for implementing and using configuration management systems and change control processes:

• Establish a method to consistently identify changes, request changes to project baselines, and analyze and determine the value and effectiveness of the changes.
• Continuously authenticate and improve project performance by evaluating the impact of each change.
• Communicate all change requests—whether approved, rejected, or delayed—to all the stakeholders.

Requirements for Change

At the beginning of all projects, you should require two things regarding change. First, require that all change requests be submitted in writing. This is to clarify the change and make sure there's no confusion about what's requested. It also allows the project team to accurately estimate the time it will take to incorporate the change.

Second, require that all change requests must go through the formal change control system. Make sure no one is allowed to go directly to team members and request changes without the project manager knowing about them. Also make certain your stakeholders understand that going around the project manager can cause schedule delays, cost overruns, and sacrifices to quality and that it isn't good change management practice. From the beginning of the project, encourage the stakeholders to use the formal procedures laid out in the change control system to request changes.

Change Control Board

In some organizations, a change control board (CCB) is established to review all change requests. The board is officially chartered and given the authority to approve or deny change requests as defined by the organization. It's important that its authority is clearly defined and that separate procedures exist for emergency changes. The CCB might meet only once a week, once every other week, or even once a month, depending on the project. When emergencies arise, the established procedures allow the project manager to implement the change on the spot. This always requires follow-up with the CCB and completion of a formal change request, even though it's after the fact.

CCB members might include stakeholders, managers, project team members, and others who might not have any connection to the project at hand. Some organizations have permanent CCBs that are staffed by full-time employees dedicated to managing change for the entire organization, not just project change. You might want to consider establishing a CCB for your project if the organization does not have one.

Some organizations use other types of review boards that have the same responsibilities as the CCB. Some other names you might see are technical assessment board (TAB), technical review board (TRB), engineering review board (ERB), and configuration control board (CCB).