#pmicourses

Overview

We’ll cover three processes in the project Executing group including Project Plan Execution, Team Development, and Information Distribution. You’ll get a reprieve in this article as there is only one math equation you need to memorize.

Project Plan Execution is the action process so to speak. This is where you’ll put the plans into action and begin working on the project activities. Execution also involves keeping the project in line with the original project plan and bringing wayward activities back into alignment.

Several things happen during the Executing processes. The majority of the project budget will be spent during this process, and often the majority of the project time is expended here as well. The greatest conflicts you’ll see during the project Executing process are schedule conflicts. And, the product description will be finalized here and contain more detail than it did in the Planning process.

Project Plan Execution is the only core process in the Executing process group. All the other processes we’ll discuss are facilitating processes to Project Plan Execution. In other words, the facilitating processes assist you with executing the project plan.

We’ll start out this article with the Project Plan Execution process and then discuss Team Development and communication processes. There are several exam questions on every process within the Executing process group. You’ll find the majority of questions regard the Project Plan Execution process, the Team Development process, and the Contract Administration process, which we’ll talk about in the next article. Don’t skip studying the other processes, however, as roughly a quarter of the exam questions concern the entire Executing process. Are you ready to dive into Executing? Let’s go.

Executing the Project Plan

The purpose of the Project Plan Execution process is to carry out the project plan. This is where your project comes to life and the work of the project happens. Activities are clarified, and the work is authorized to begin. Resources are committed and assigned to activities, and the product or service of the project is created. One of the most difficult aspects of this process is coordinating and integrating all the elements of the project. The largest portion of the project budget will be spent in Project Plan Execution.

Executing Inputs

Project Plan Execution has five inputs: project plan, supporting detail, organizational policies, preventive action, and corrective action. We covered supporting detail earlier in this book, which included constraints and assumptions. There are a few new things to add to organizational policies, so we’ll look at that one again along with the others.

Project Plan

The project plan is the output of the Planning process group, specifically the Project Plan Development process. The important thing to note here is that all the management plans we discussed during the Planning process — such as the scope management plan, the schedule management plan, the resource management plan, and so on, plus the cost budgeting baseline and the schedule baseline — are used throughout the Executing process to manage the project and keep the performance of the project on track with the project objectives. If you don’t have a project plan, you’ll have no way of managing the process. You’ll find that even with a plan, project scope has a way of changing. Stakeholders and others tend to sneak in a few of the “oh, I didn’t understand that before” statements and hope that they slide right by you. With that signed, approved plan in your files, you are allowed to gently remind them that they read and agreed to the project plan and you’re sticking to it. They can request a formal change, but that’s another topic, which we’ll get to shortly.

Organizational Policies

It’s important for the project manager to understand organizational policies as they may impact Project Plan Execution. For example, the organization may have purchasing approval processes that must be followed. Perhaps orders for goods or services that exceed certain dollar amounts need different levels of approval. As the project manager, you need to be aware of policies like this so you’re certain you can execute the project smoothly. It’s very frustrating to find out after the fact that you should have followed a certain process or policy, and now because you didn’t, you’ve got schedule delays or worse. You could consider using the “sin now, ask forgiveness later” technique in extreme emergencies, but you didn’t hear that from me. By the way, that’s not an authorized PMI technique.

The project manager and the project team will be responsible for coordinating all the organizational interfaces for the project including technical, human resource, purchasing, finance, and so on. It will serve you well to understand the policies and politics involved in each of these areas in your organization.

Preventive Action

Preventive action involves anything that will reduce the potential impacts of risk events should they occur. Contingency plans and risk responses are examples of preventive action. These and other risk responses were described in the Risk Response Planning process.

Corrective Action

In my organization, a corrective action means an employee has big trouble coming. Fortunately, this isn’t what’s meant here. Corrective actions are taken to get the anticipated future project outcomes to align with the project plan. Maybe you’ve discovered one of your programmers is adding an unplanned feature to the software project because he’s friends with the user. You’ll have to redirect him to the activities assigned him originally to avoid schedule delays.

Corrective actions are outputs of processes in the Controlling process group but serve as inputs to the Project Plan Execution process. For the exam, remember that the Executing and Controlling process results are inputs to each other.

We’ll cover corrective action again in the article that discuss the Controlling process.

Meetings and More

As with the Project Plan Development process, almost everything we’ve done to date is utilized by the Project Plan Execution process. The primary output here is work results, meaning actually producing the product or service we set out to produce. Without having completed the prior processes, we wouldn’t know what the work of the project should look like. Several tools and techniques are used to facilitate the work results. We’ll look at all of them, with the exception of project management information system, which we’ve covered previously.

General Management Skills

What’s important to note here is that leadership, negotiation, and communications skills are especially useful during Project Plan Execution. You might recall that leadership is about imparting vision and rallying people around that vision. Leaders motivate and inspire and are concerned with strategic vision. Leaders understand the difference between power and politics. Power is the ability to get people to do what they wouldn’t do ordinarily, or the ability to influence behavior. Politics impart pressure to conform regardless of whether the person agrees with the decision.

One other thing to consider in this category is that you’re going to monitor other departments that have assignments on the project and manage their progress. Again this implies that you’ll need general knowledge management skills to understand what the assignments entail and strong leadership skills to influence the departments to stay on schedule.

Product Skills and Knowledge

The Resource Planning process defined the skills that are required of project team members, and the Staff Acquisition process provided the resources for the project. Product skills and knowledge are also needed by the project team members to understand the product or service of the project. If your project is constructing a mass spectrometer and no one on your team knows what a mass spectrometer looks like, you’ve got a problem. Key team members should have knowledge, skills, and experience with the products of the project.

Work Authorization System

Work authorization systems clarify and initiate the work of each work package. This is a formal procedure that authorizes work to begin in the correct sequence and at the right time. Work authorization systems are usually written procedures defined by the organization. They might include e-mail–based or paper-based systems or even verbal instructions, which work well with smaller projects. Usually, work is 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 assigned and authorized by either the project manager or the functional manager.

Status Review Meetings

Status review meetings are important functions of Project Plan Execution. Status meetings are a way to formally exchange project information. They can occur between the project team and project manager, the project manager and stakeholders, the project manager and users or customers, the project manager and the management team, and so on.

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.

Regular, timely status meetings prevent surprises down the road. They alert the project manager to potential risk events and provide the opportunity to discover and manage problems before they get to the uncontrollable stage.

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 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’s 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 serves as a reminder to the meeting participants of what actions need to be resolved and who is responsible for the 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 of 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! The project manager, because they didn’t believe it, 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 experience 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 showstopper.

Organizational Procedures

This is very similar to organizational policies, except organizational policies are an input, and organizational procedures are a tool and technique of this process.

The project manager should take organizational procedures into consideration when doing the work of the project. Maybe your finance department requires special requisitions for certain purchases, or your human resources department might require formal procedures for full-time as well as contract personnel. Be aware of policies like this ahead of time so that they don’t interfere with the project Executing process.

Resulting Outputs

We’ve already touched on the outputs of this process. Obviously, the product or service of the project is our end result. The Guide to the PMBOK calls this work results. The second output we’ll look at is change requests.

Work Results

During Project Plan Execution, you’ll gather and record information regarding the activity completion dates, milestone completions, the status of the deliverables, the quality of the deliverables, costs, schedule progress and updates, and so on. All of this information gets used during the Performance Reporting process, which we’ll discuss during the Controlling process.

Project Executing and Controlling are two processes that work hand in hand. As you gather the information from work results, you’ll measure the outputs and take corrective actions where necessary. This means you’ll loop back through the Executing process to put the corrections into place. The Guide to the PMBOK breaks these processes up for ease of explanation, but in practice, you’ll work through several of the Executing and Controlling processes together.

Change Requests

As a result of working through activities and producing your product or service, you will inevitably come upon things that need to be changed. This might encompass schedule changes, scope changes, or requirements or resource changes. The list really could go on. Your job as project manager, if you choose to accept it (wasn’t that a movie theme?), is to collect the change requests and make determinations on their impact to the project. We’ll discuss change requests in the coming articles. Change requests are an output of this process and an output of the Performance Reporting process in the Controlling process group. Remember that Executing and Controlling outputs feed each other as inputs.