Chapter 11: The Rhythm of Project Execution

Your source for the news, opinions, and reader reaction on the industry’s hottest controversy.

Furious activity does not necessarily equate to progress and is not a substitute for understanding. —Anonymous

Topics Covered in This Chapter

All About Execution

Creating the Baselines

Getting into a Rhythm

Quality Audits

Teaming

Politics

Summary

Case Study

This chapter is all about what has to be done when you execute your project. It seems pretty straightforward that your team will be performing the tasks of the project. But you will be amazed by all the activities that need to be done while those tasks are being performed. One of the activities that you might not be familiar with is the concept of quality audits. I introduce that concept in this chapter and talk about what gets audited. I also cover the subject of how many quality audits you might consider on your project. I finish that topic with the timings of quality audits.

First, though, you have to set up a baseline. I talk about each type of baseline and then cover how to use them and the purpose of baselining in general. Next comes the idea of getting into a rhythm on your project.

In “Teaming,” I talk about another element to use to develop the project team: training. Team members will not perform effectively if they are not trained to do the job properly. I cover the different types of training that might be needed.

In “Politics,” I talk about obstacles to executive communication. You might run into a couple executive types you have dealt with before: the Mad Hatter and the Executive Ostrich.

In the case study, Chris spends most of her week getting ready for the meeting with June. She still has to complete the budget and the schedule to properly brief June. She gets caught up in a lot of meetings, though, and has a lot of details to work through to finish in time.

All About Execution

Finally, you are ready to begin the execution process of your project. It seems like you’ve been planning forever. You’ll soon see that it was well worth it: You can much easier execute a project that you have planned well than a project that you have thrown together. You have created a workable plan and have anticipated what can possibly go wrong. You’ve also actually built mitigation plans, just in case things do go wrong. You are ready to go. So what needs to be done now that you are executing the project? Do you need to do specific activities, or is it simply a matter of performing each task in the project schedule?

Actually, you must take care of a handful of executing activities. I cover those in this chapter. You’ll also see in Chapter 12, “Keeping the Project on Track,” and Chapter 13, “Controlling Changes,” that all the activities discussed in these three chapters get done while executing the project. You will be very busy executing the project, controlling changes, and keeping everything on track. Let’s start with a concept that sets the stage for all the work activities in these chapters: creating the baselines.

Creating the Baselines

A baseline is the line you draw in the sand that states, “This was my intention. This is what I planned to do.” You always create a project plan with the best possible way of getting the work done. You might modify your planning at the end to get to a certain objective, but you understand exactly what the trade-offs are in getting to the objectives. You build the best possible plan and save it. This is your baseline. It provides a point in time for you to compare your plans against what is actually happening. You need to create several baselines when you have finished your project planning:

• Schedule baseline—The schedule baseline is a copy of the tasks that your team must complete to execute the project on time. It is usually a copy of the network diagram or a Gantt chart of the schedule, showing each task, the predecessors and successors for each task, as well as the needed duration of each task. You’ll want to save this copy at the end of planning before any actual executing work begins.

• You can save this copy via either a project management software program, a spreadsheet, or any other electronic means. A hard copy will also do, if you value simplicity. The best way is to let your project management software keep the baseline for you; it will also do comparisons for you when you want to know if you are on track or off track.

  Really cautious project managers also store a copy of their project schedule in their project management software, just in case they lose their current copy of the project.

  ---

  Baselines in Microsoft Project – Microsoft Project creates a baseline for you and stores it for future comparisons. In fact, it has the capability to create several different baselines. For more on this topic, see Microsoft Project for Mere Mortals, by Patti Jansen.

  ---

• Cost baseline—You create the cost baseline during the budgeting process. This is the sum of all the work of the tasks of the project by resource and resource rate needed per task. Another view of the cost baseline is the budget minus any fees, reserves, or contingency money. This could be a spreadsheet that you’ve created that depicts all the budget components for your project.

• Again, the best way to create this kind of baseline is to let your project management software keep the baseline for you. The cost baseline will be stored within your project software tool if you populate the resource sheet with the project resources and their resource rate. You will also be able to run reports to do comparisons on what you’ve planned to spend versus what you have spent.

  Your organization might also have mechanized tools or spreadsheets that you must fill in for your accounting department. Find out what is required before you settle on a method.

• Product requirements baseline—You created the requirements for the product of the project early in your planning process. You now need to baseline those requirements before you begin to create the product and basically execute those requirements. This is probably a text document, so you can create a baseline by doing the following:

  1. Get a signature from the project client on the completeness and approval of the requirements.

  2. Save a copy or use document versioning to show the version of the product requirements that were approved.

• Use this approved document as a marker to show the features and functions of what you plan to create; it will become very useful when people ask for changes in the product. You’ll get into that discussion in Chapter 13.

• Quality baseline—The quality baseline is the information that you gathered in your quality planning process. This information spells out the quality objectives that you have planned for the project. You’ll again use this information while you are executing your quality plan, to compare your quality performance back to your objectives in your plan. You’ll probably get signatures and do version control to create this baseline.

Putting all these baselines together creates what the PMBOK® Guide calls the performance measurement baseline. This is the sum and collection of all the parameters that you use to measure whether you are executing your project correctly. This includes all the baselines we just talked about. You are executing your project correctly if you will successfully deliver according to the triple constraints of time, budget, and the agreed-upon Measure of Performance.

When can you change a baseline or rebaseline? Good question. Most organizations have set rules regarding when a project manager can rebaseline. The rule of thumb is only after some type of major event. Say, for instance, that you have signatures on the product requirements, and you’ve built the project schedule and budget to build that product. A major event occurs like one of the following:

• The executive in charge of the product leaves the organization and a new executive joins the firm. The two have different visions for the product.

• A competitor launches a product very similar to yours.

You get the picture. The event makes you go back and rethink and redo the requirements; therefore, you have to replan the entire project. This is the type of situation that requires you to rebaseline different elements or the whole project because you are basically starting over on your project planning. The key here is to get approval from your project sponsor before you baseline. You can’t rebaseline just because something goes wrong; it has to be major and approved.

Getting into a Rhythm

You’ve set your baseline, and the team begins the first set of tasks. You are on your way! It’s time to establish a few fundamental activities that will serve you and the project until you deliver the project. Here you try to establish a rhythm for your project. Successful projects have an unmistakable rhythm to them. Figure 11.1 shows the type of tempo you are looking for. You are looking for a steady drum beat of activities, like a heart rate monitor.

Figure 11.1

The rhythm of execution

You will strive throughout the project to keep this rhythm going and to not allow anything to disrupt it.

Status Meetings

You can see from the rhythm diagram that the high point for your activity is the status meeting. This is your first fundamental activity. Now is the time to set the frequency of the status meetings. How often do you need the team to meet and discuss the status, issues, and successes? Chapter 4 talked about setting the frequency for how long a task can be out of control without you knowing about it. You must take that into consideration along with the drum beat. How often will you need the team to meet to talk about the status and issues and to keep them motivated?

Most project managers set their status day to once a week, once every two weeks, or once a month, depending on the previous factors. People tend to stay away from Mondays and Fridays because a lot of people take these days off for holidays or vacation. You need to understand the culture of your organization and determine what time of day is most conducive to having your status meeting

Issues Management

You also should establish your issues management process now. This is another activity that will help you set the rhythm of your project. Chapter 4, “Laying Out the Work,” briefly covered issues and defined an issue as an item that needs discussion or research before a task can be completed.

Figure 11.2 depicts the process you will establish for managing issues. An identified issue should be brought to the project manager if urgent, or to the status meeting if not.

Document the issue at the status meeting, making sure that you establish a due date. Assign one person to be accountable for resolving the issue. Also document the other people required to solve the issue. The people who need to resolve the issue should discuss and resolve the issue outside the status meeting. They should bring back information about their progress to the status meetings as they work through the issue. They also can bring back information about their final resolution when they reach that point. The entire team can discuss and document the issue and resolution at that status meeting. The issue then is closed after this last step. Figure 11.3 shows a sample issue-management form for your future use.

Figure 11.2

Issues management process

Figure 11.3

Issues management form

Your job as the project manager is to manage the process and hold people accountable for getting the issues resolved. You also need to set up a file or database of issues so the team can review issues and their resolutions when they can’t attend the status meeting.

You have established these two fundamental activities; you now can get into a rhythm for your project. The next critical step is to just get the work of project execution done.

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.

You need to do one more piece of work while you are executing your project: a quality audit.

Quality Audits

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.

Figure 11.4

Juggling the work of execution

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.

Teaming

Your team must be a cohesive unit that performs well together during project execution. It is your job as the project manager to make sure this is happening. Two elements are important to developing your project team. The first is improving the feelings of cohesiveness so greater productivity takes place through teamwork. The “Teaming” sections in the last several chapters have referred to the Tuckman model, and I’ve provided ideas on what to do to get your team to the performing stage of team development. Hopefully by now you have done some extensive work to get your team performing well. You have used concepts such as doing team-building activities, setting up team norms, and providing rewards and recognition to develop the team. But you still need to address one more aspect of team development: training. A team will not complete its development until the team members feel secure in their ability to get the job done.

Training involves many different aspects. I cover a few here that are most integral to the successful completion of your project. The first is skills-based training.

Your project could be bringing a new way of doing work or a new technology to your organization. You will want to make sure that your staffing management plan covers this type of training needed for the resources of your project. Make sure that the training provided is just in time: You don’t want to have to retrain your team members because the class was two months before they actually got to start the work.

The second type of training to provide is training on the project itself. It might be wise to hold an orientation session for each new team member who joins the project. This would include meeting the rest of the project team and walking through the project plan. Be sure to spend sufficient time on all elements of the project plan. Make sure that you cover the areas the new team member will be working in and that the other team members understand them. Also be sure to cover the team norms and rules of engagement that you all have agreed upon. You’ll want to get concurrence on the idea that the team members will comply with the team norms.

The next type of training that you will want to provide is based on the individual’s performance on the project. You might find as you work with certain team members that they lack either the technical or the management skills necessary to satisfactorily perform their job. You’ll figure this out by observing their performance and getting feedback from other team members. Another tell-tale clue is tasks that are running late. Sometimes people just don’t have the skills to get the work done. You must create training opportunities as the need arises on your project. You might have to send the individual to formal training, or you might find a way to give on-the-job instruction. Sometimes all a new team member needs is a little mentoring to feel confident enough to get the task done. Polish off your general management skills and determine the best approach for each individual team member.

Continue to monitor team development through the rest of the project. Remember that the dynamics of the team change every time a new team member joins the team. Now let’s talk about information distribution and executives who are hard to pin down.

Politics

Providing project information is one of the most important activities of project execution. You will spend a lot of time doing this work. Some sources will tell you that project communication is 90 percent of a project manager’s job, yet sometimes it’s not very easy to get done. You will face obstacles depending on the type of executive personalities you are dealing with. Two of the most interesting executive personalities are the Mad Hatter and the Executive Ostrich.

The Mad Hatter is the executive who is always running through the hall looking at a wristwatch and proclaiming, “I’m late! I’m late! For a very important date!” These executives are always on the go. They are often late for their meetings with you, if they haven’t first cancelled on you. When you do get to talk to them, it seems like their attention is waning. And most times they cut your meetings short.

The Executive Ostrich has his or her head in the sand and won’t pay any attention to bad news. Most times these executives won’t even talk to you because they don’t want to hear bad news. Sometimes they resemble the Mad Hatter, but their motivation isn’t too much to do: It is “Just make it happen. Don’t tell me any bad news.”

How do you handle these two types of executive personalities? The approach is pretty much the same for both:

• Keep sending the information—You have to provide a status update, no matter what your executives say or how busy they are. You have to give the good news, the potential risks, and, if necessary, the bad news. Send them a copy of the monthly status report, if you send one out. Do so regardless of whether they read it.

• Leave sticky notes on their desk with a quick update—Try leaving a sticky note on your executives’ desks about an important update if you suspect they’re not reading their status reports. Be sure not to waste their time with trivial information; limit this technique to just the important things that they must know.

• Leave a 15-second voice mail—You can also try a 15-second voice mail. The Mad Hatter doesn’t have time for a lengthy message, and the Executive Ostrich doesn’t want bad news, so make it quick. Keep your messages brief. Practice crafting a quick message a time or two with just the most important bullets before you leave that voice mail.

• Find out how best to get them the information—Chapter 3, “How Big Is This Project?,” talked about getting to know the executive’s administrative assistant. You can talk to this person now about how best to get information to your executive. You might find that leaving information with the administrative assistant is the most effective means of executive communication.

Keep sending the information, regardless of the method you choose. You never want to be in the situation when something bad happens on the project and the executive says, “Why didn’t you tell me?”

One of the key tools you can use in this type of a situation is a project diary. Get yourself a notebook or open a document file, and keep track of everything that happens on the project. Yes, everything. Some of the best project managers I know keep a detailed diary of every conversation, every e-mail sent, every problem, etc. The objective is to make sure that you are covered. An executive might comes back to you and say, “Why haven’t you kept me informed?,” but you’ll have a diary describing every item you’ve sent.

Summary

This chapter talked about the rhythm of execution and the importance of setting a rhythm for your project team. We covered all the different types of baselines that you need to set to compare what you are executing to what you planned to do. We then talked about all the activities that you must do when executing the project. We spent a little more time on quality audits.

In the “Teaming” section, we described another element of team development: training. We talked about three different types of training: skill training, team training, and performance training.

The “Politics” section talked about some different personality types of project executives. Sometimes it is difficult to get the project information out and understood. We covered a couple of strategies that you can use when dealing with these different personality types.

Now back to the case study, where Chris Williams is still working on finishing the schedule and the budget. She has a meeting coming up shortly with June and still has a lot of work to complete.

Case Study

Chris rushed around the rest of the week trying to finalize the schedule and budget for her meeting with June on Friday afternoon. She was able to meet with the Human Resources manager on Wednesday morning. The manager couldn’t just turn over figures to Chris, as Chris had hoped. He needed a day to create either the loaded or the average salary rates. He also wanted to talk to June and see what her expectations were on how realistic the rates needed to be. He promised to get the rates to Chris no later than the close of business on Thursday.

Scheduling the meetings with the executives didn’t go as well as Chris had hoped. She was able to set up only individual meetings instead of one joint meeting. That meant that she would have four meetings of at least 30 minutes to get through between Wednesday and Thursday afternoon. She wanted to leave Friday morning free to get ready for her meeting with June. She knew that would probably work out; she just didn’t have much time to do four meetings instead of one.

On Wednesday morning, Chris walked through the preliminary schedule with the core team and the new team resources. She was amazed at how the dynamics had changed with the introduction of a few new team members. Her core team was kind of quiet, for a change. She was getting used to their storming and performing behaviors. It looked to her that they had stepped back to the forming stage of team development. She made a note to herself to schedule a team-building session next week with all of them; they needed a chance to get to know each other better. And she knew she needed to get them through forming, storming, and norming as fast as possible.

Chris held two of the meetings with the executives on Wednesday. She had a chance to meet with Greg Peterson regarding Bill Ricardo’s work on the project. They agreed that Bill’s sales quotas would be decreased appropriately when he was tied up with the project. Chris also told Greg that she would provide a review of Bill’s work at the end of the project. The project would take up six months of Bill’s life, and Chris wanted to make sure that Greg was correctly apprised about the work Bill did. She also knew that if she had appraisal authority, she would have more authority with Bill. She knew Greg wouldn’t have a problem with receiving an appraisal from her; she had heard through the grapevine that he seldom did appraisals on his subordinates anyway.

Her next meeting was with Ken Hale, her boss and Carl’s boss. Ken was pretty much in tune with project management activities and expected to free up Carl so that his entire workload consisted of the two projects he was working on: VNLE and the VN Web project. He also expected a full appraisal of Carl’s work on the project and asked Chris to sit with him when he was doing Carl’s final year-end appraisal. He wanted to make sure that Chris’s appraisal had equal weight when the final appraisal was completed. Chris was pretty pleased with the outcome of the meeting. Working for Ken was turning out better than she hoped. He also understood project management and accountability and authority really well.

The only setback that Chris had on Wednesday was the fact that Karla, Robin’s supervisor, cancelled her meeting and rescheduled it for Thursday. Chris was more concerned about Robin’s schedule than that of anyone else. Most of Robin’s work was on the critical path of the project, and Chris wanted to make sure that she would be able to get it all done and not be hampered by her regular business activities. Well, she’d have to talk to Karla tomorrow.

On Thursday morning, Chris got an e-mail from the HR manager with the rates shown in Table 11.1. She was really pleased to get the rates earlier than she had been told, but she couldn’t work on the budget then because she needed to run off to another meeting. She would have to get back to it later that day.

Table 11.1 Resource Rates for VNLE

Chris left for her next meeting, with Sue, Tina and Carol’s supervisor. Sue was pretty set in her ways in running her department and was not much of an advocate for project management. She said she would do what she could with Tina and Carol’s workload, but her people were expected to work overtime whenever there was extra work to do. Sue told Chris that she would make sure that Tina and Carol knew this was her expectation. Sue then excused herself from the meeting to take a quick call. She told Chris she’d be back in five minutes. Sue did come back in 5 minutes but was still on her cell phone and continued to talk for another 15 minutes. She wasted Chris’s time for a half-hour, until they finally got back to the discussion of the project and Sue’s subordinates. Chris offered appraisal information on the two women, and Sue told her that would be nice and that she’d be glad to look over the feedback. She also stated that she knew what her subordinates were doing and probably wouldn’t need anything additional. Chris left Sue’s office and mumbled under her breath, “What a waste of time!”

Chris then went back to her desk and answered a couple phone calls and e-mails before she headed to her next meeting, with John. John was very agreeable to what Chris wanted and assured her that he would make his people available for the project. He had heard from June about the importance of the project and knew these new vendors could make or break this new launch. He did have some questions for Chris about the project, though. He and Chris spent the next hour discussing John’s questions. Chris made a mental note to update the communication plan on John; he would need a lot more detail to satisfy his communication needs.

Chris got back to her desk after 2 p.m. Her meeting with Karla wasn’t until 5 p.m., so she had a couple hours to work on the project schedule and budget. Chris again analyzed the critical path. This time she was looking for the tasks that Carol and Tina had to perform. She knew she had a risk because of Sue’s stance about project work and overtime. Tina had two critical path tasks. Carol had none. She decided that she could absorb the risk of the overtime for these two tasks.

Chris then started her calculations for the cost baseline on her project. She was able to get those done fairly quickly. You can see her finished work in Table 11.2. Now she needed to meet with Karla, Robin’s boss.

Table 11.2 Cost Per Task for VNLE

The meeting with Karla lasted until 7 p.m. Karla’s staff is not very large, so, needless to say, she was hesitant about trying to lighten Robin’s workload. The problem was that not too many people can do what Robin does for the organization. Chris discussed the tasks that Robin needed to do and the concept of critical path, and Karla then understood the importance of freeing up Robin for the project work. Karla also didn’t understand the appraisal concept. Chris had to explain the concepts of accountability and authority in project management to her. Again, this took a while, but at the end, Karla said she would welcome Chris’s appraisal and together the two of them would determine Robin’s overall appraisal and her pay raise for that year. Success!

By the end of the meeting, Chris was pretty tired. She decided to go home and get a good night’s sleep and attack the rest of the budget in the morning. She also decided that she had better get up early to get everything ready for her meeting with June. What a day!

Review Questions

1. What is a baseline?

2. What is a schedule baseline?

3. What is a cost baseline?

4. What is the product requirements baseline?

5. What is the quality baseline?

6. When you put all these baselines together, what are they called?

7. How often should a project manager conduct a status meeting?

8. What is an issue?

9. What are some of the types of activities performed during project execution?

10. Why are quality audits performed during project execution?

Copyright © 2007 Pearson Education. All rights reserved.