The Work of Project Execution
So far, the discussion has been pretty general concerning the work of project execution. Until now, it has simply been characterized as "successfully execute some tasks." Let's get specific now and talk about the types of work that get done while you execute your project.
Types of Work
The types of work include the following:
- Performing the tasks of the project—First and foremost, you and your team must perform every task of the WBS in the sequence that you laid out in your network diagram. You must do all this work with the intention of fulfilling the objectives that were originally requested of your project. You must course-correct if you perform the tasks that have been planned and they are not fulfilling the objectives of the project.
- Staffing the project—You must staff the project as the need arises. You have already determined who will do what task. Now is the time to bring these people to the project and put them to work. You might need to provide some type of orientation to get these people ready to work and perform effectively.
- Training resources—You might also have to supplement your project resources' skills. Some team members might need a specific piece of training to work effectively. Every resource might need some level of training if you are working in a brand-new technology or process discipline.
- Managing human resources—You are accountable for the performance of the resources on your project, regardless of the type of organization that you work in (projectized, matrixed, or functional). Thus, you must manage the resources. You must assign tasks, overcome roadblocks, follow up on work, and provide feedback. You must gather documentation on the performance of each team member and provide that to other supervisors at the end of the project.
- Managing other resources—You also must manage your resources during execution if you plan to use other types of resources. You must make sure that the bulldozer you need for Task 57 is delivered just before that task. You also must make sure that it is returned as soon as Task 57 is completed so you don't pay late fees and expend more of your budget than was allocated.
- Installing methods and procedures—You might have done some very detailed planning on certain tasks while you were planning the project. This detail might include things such as step-by-step methods or procedures for getting the work done the right way. Now is the time to implement any of these work methods.
- Collecting work performance information—Earlier in this chapter, you established a status meeting as you set the rhythm of the project. Here is where you collect information from each team member regarding how the work is being performed. I talk about exactly what information you will collect in the next chapter, on monitoring and controlling the project.
- Reporting on project information—You must accumulate data regarding the performance of the project tasks. You must report on the data you've gathered, depending on your organization's requirements for status reports. Even if your organization has no reporting requirements, you must provide reports based on what you have defined in your communication plan.
- Executing your communication plan—You also start to execute your communication plan. You must determine which elements of your plan need to be done at what point in time while the project is being executed.
- Implementing approved changes—You'll find that as you and your team execute the project plan, someone might ask for changes to what has been originally planned. These requests for changes will go through an entire process that we describe in Chapter 13. Some will be denied, and some will be approved. Those that are approved will be completed as part of your execution process.
- Validating project deliverables—As the team creates the product of the project, you must control the creation of those deliverables. You also must spend some time validating those deliverables back to the original request or requirements.
- Gathering lessons learned—A lot of organizations collect lessons learned at the end of the project. Organizations that are adopting industry best practices are finding that it's best to collect lessons learned all the way through the project. That way, the team members learn from their mistakes right away and have a chance to correct some of their problems along the way instead of waiting until the next project. This also allows the team to find out what they are doing right so they have a chance to continue with that winning performance.
- Performing risk management—The team has a chance to manage the risks identified in the planning stage as the project tasks are being performed. The team members can put their response plans into place. This is also the time to gather new risks and continue managing the top 25 percent on the master risk identification list.
And all you thought you were going to do was manage the completion of the project tasks! You probably feel like a juggler right now trying to figure out exactly how you will accomplish all of this. Is that you in Figure 11.4? Not to worry, though. You have everything covered in your project plan if you have done the level of planning that I have discussed all the way through this book. In it, you have documented every aspect of the planning, from how you will perform risk management to what training is needed for every resource on the project. Oh, you say I haven't covered that yet? Well, this is covered in the "Teaming" section of this chapter.
Figure 11.4 Juggling the work of execution
You need to do one more piece of work while you are executing your project: a quality audit.
You laid out activities that your resources must perform to guarantee the quality of the product you are creating. You execute those quality activities during the execution of your project. You might also find that the activities you have planned for quality are not substantial enough to guarantee the quality. How will you know if you need to implement more quality activities? A quality audit is the answer.
A quality audit is a review that determines whether the project is complying with the quality standards that were set in the planning stage of the project. Someone outside the project team usually does the quality audit, to be objective in a review of the project.
The auditor looks at two different sets of information in this review:
- The product of the project—The auditor will verify that the product of the project is meeting the requirements that have been created to describe the product. The auditor will also verify that the procedures for creating the product are being used successfully.
- The processes of the project—The auditor will review the processes of the project and determine whether they are being performed correctly. The auditor will also conduct an analysis to make sure that these processes are sufficient to manage the project to a successful completion.
The objective of the quality audit is to look for ineffective and inefficient processes and procedures that will hamper the quality of the product and the project. Remember, the objective of the project is to deliver to the triple constraints of the MOP, cost, and time. You won't fulfill the triple constraints if your project processes are not working.
Now let's talk about the timing of quality audits. You need to perform a quality audit at least twice on your project. You might even need more than two audits, depending on the length of the project.
The first audit is performed at the end of the planning stage and the beginning of the execution stage of your project. This audit inspects the processes and procedures that have been designed for the execution stage. The auditor does a document check to verify what was created and make sure that the documents are sufficient for the size and complexity of your project. The team should immediately institute any recommendations that the auditor provides, before the team gets into the habit of executing an inefficient process.
The second quality audit should be performed after the team has been working on project execution for a while. Here the auditor makes sure that the processes is being executed correctly. The auditor also inspects the deliverables of the process to make sure the process is producing the right quality of deliverable.
You can see now why more than two audits might be needed. A project with a year length might be starting a new deliverable every couple of months. You might consider bringing in an auditor shortly after work begins on the next major deliverable, if your project can afford it.
Another way to use a quality audit is in response to problems. Perform an audit when you start to see variance in the work being done. Bringing in an auditor when you start to see problems can be a diagnostic tool before your project really goes way off track. I talk more about this in the next chapter.
Another important activity of project execution is developing the project team. Let's move on to the "Teaming" section and talk about team development.