Project Management -Exercise 3

8/12/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/50!/4/304/2@0:68.0 1/39

Page 510

PRINTED BY: [email protected]. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without publisher's prior permission. Violators will be prosecuted.

CHAPTER FOURTEEN

Project Closure

Project Closure Types of Project Closure Wrap-up Closure Activities Post-Implementation Evaluation Retrospectives Summary Appendix 14.1: Project Closeout Checklist Appendix 14.2: Euro Conversion

8/12/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/50!/4/304/2@0:68.0 2/39

Page 511

PRINTED BY: [email protected]. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without publisher's prior permission. Violators will be prosecuted.

Those who cannot remember the past are condemned to relive it. —George Santayana, 1863–1952

Every project comes to an end eventually. But how many project participants get excited about closing out a project? The deliverables are complete. Ownership is ready to be transferred. Everyone's focus is what's next— hopefully a new, exciting project. Carefully managing the closure phase is as important as any other phase of the project. Observation tells us that organizations that manage closure and review well prosper. Those who don't tend to have projects that drag on forever and repeat the same mistakes over and over.

Closing out a project includes a daunting number of tasks. In the past and on small projects the project manager was responsible for seeing all tasks and loose ends were completed and signed off. This is no longer true. In today's project-driven organizations that have many projects occurring simultaneously, the responsibility for completing closure tasks has been parsed among the project manager, project teams, project office, an oversight “review committee,” and an independent retrospective facilitator. Many tasks overlap, occur simultaneously, and require coordination and cooperation among these stakeholders.

The three major deliverables for project closure are described below (see Figure 14.1):

1. Wrapping up the project. The major wrap-up task is to ensure the project is approved and accepted by the customer. Other wrap-up activities include closing accounts, paying bills, reassigning equipment and personnel, finding new opportunities for project staff, closing facilities, and the final report. Checklists are used extensively to ensure tasks are not overlooked. In many organizations, the lion's share of closure tasks are largely done by the project office in coordination with the project manager. The final report writing is usually assigned to one project office staff member, who assembles input from all stakeholders. In smaller organizations and projects, these closure activities are left to the project manager and team.

FIGURE 14.1 Project Closure and Review Deliverables

8/12/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/50!/4/304/2@0:68.0 3/39

Page 512

2. PRINTED BY: [email protected]. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without publisher's prior permission. Violators will be prosecuted.

Evaluation of performance and management of the project. Evaluation includes team, individual team members, and project manager performance. Vendors and the customer may provide external input. Evaluation of the major players provides important information for the future.

3. Retrospectives. Retrospectives of lessons learned are designed to improve performance on current and future projects. Today, most retrospectives are the responsibility of an independent facilitator. The facilitator also provides major input to the closure report that will include lessons learned. These post- project reviews should be held with the team to catch any missing issues or gaps.

This chapter begins with the recognition that projects are shut down for many reasons. Not all projects end with a clear “Finished” and are turned over to a customer. Regardless of the conditions for ending a project, the general process of closure is similar, though the endings may differ significantly. Wrap-up closure tasks are noted first. These tasks represent all the tasks that must be “cleaned up” before the project is terminated. Evaluation of project performance is next. Finally, lessons learned or retrospective methods are examined in detail.

Types of Project Closure On some projects the end may not be as clear as would be hoped. Although the scope statement may define a clear ending for a project, the actual ending may or may not correspond. Fortunately, a majority of projects are blessed with a well-defined ending. Regular project reviews will identify projects having endings different from plans. The different types of closure are identified here:

Normal The most common circumstance for project closure is simply a completed project. For many development projects, the end involves handing off the final design to production and the creation of a new product or service line. For other internal IT projects, such as system upgrades or creation of new inventory control systems, the end occurs when the output is incorporated into ongoing operations. Some modifications in scope, cost, and schedule probably occurred during implementation.

Premature For a few projects, the project may be completed early with some parts of the project eliminated. For example, in a new product development project, a marketing manager may insist on production models before testing:

Give the new product to me now, the way it is. Early entry into the market will mean big profits! I know we can sell a bazillion of these. If we don't do it now, the opportunity is lost!

The pressure is on to finish the project and send it to production. Before succumbing to this form of pressure, the implications and risks associated with this decision should be carefully reviewed and assessed by senior management and all stakeholders. Too frequently, the benefits are illusory, dangerous, and carry large risks.

Perpetual Some projects never seem to end. The major characteristic of this kind of project is constant “add- ons,” suggesting a poorly conceived project scope. At some point the review group should recommend methods for bringing final closure to this type of project or the initiation of another project. For example, adding a new feature to an old project could replace a segment of a project that appears to be perpetual.

8/12/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/50!/4/304/2@0:68.0 4/39

Page 513

PRINTED BY: [email protected]. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without publisher's prior permission. Violators will be prosecuted.

SNAPSHOT FROM PRACTICE Project Canceled*

Germany is the major crossroad for Europe's international commercial trucks. The German government felt the need to have international trucks (over 12 tons) using their road infrastructure assist in paying for the road maintenance and additional new infrastructure. The project objectives were clear—a new electronic truck toll-collection system that ensures accurate charges and easy fee collection across German, Swiss, and Austrian highways by August 31, 2003. The technology relied on global positioning systems (GPS), telecommunications, and software to record miles and charges, without using toll booths along the highways.

Several problems sabotaged the project. Time-to-market deadlines were impossible to meet. Delayed launch dates were caused by technical problems with truck tracking units and software that failed to function as expected. Interface communication with public and private stakeholders failed. As a result, the August 2003 deadline was never met. The revised November 2003 deadline was not met. Finally, in March 2004 the German government pulled the plug and canceled the project.

The cancellation of the project had serious impacts on other governmental programs. The shortfall of not receiving the revenue from the new toll system is estimated at $1.6 billion. Some of those revenues were destined for a high- speed maglev train in Munich and other infrastructure projects.

Lessons learned reveal that lack of project management knowledge was evident. More importantly, failure to identify and assess the impact of schedule and complex technology risks resulted in the death of the project. Perhaps a simpler, cheaper microwave system recommended by the Swiss and Austrians to be operational by 2005 would have sufficed. See http://www.tollcollect.de/frontend/HomepageVP.do:Jsessionid-F840E12142D.

* “Case Analysis: Taking a Toll,” PM Network, Vol. 18, No. 3, March, 2004, p. 1.

Failed Project Failed projects are usually easy to identify and easy for a review group to close down. However, every effort should be made to communicate the technical (or other) reasons for termination of the project; in any event project participants should not be left with an embarrassing stigma of working on a project that failed. Many projects will fail because of circumstances beyond the control of the project team. See Snapshot from Practice: Project Canceled.

Changed Priority Organizations’ priorities often change and strategy shifts directions. For example, during the 2008–10 financial crisis organizations shifted their focus from money-making projects to cost savings projects. The oversight group continually revises project selection priorities to reflect changes in organizational direction. Projects in process may need to be altered or canceled. Thus, a project may start with a high priority but see its rank erode or crash during its project life cycle as conditions change. When priorities change, projects in process may need to be altered or canceled.

Different types of project termination present unique issues. Some adjustments to generic closure processes may be necessary to accommodate the type of project termination you face.

Wrap-up Closure Activities

8/12/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/50!/4/304/2@0:68.0 5/39

The major challenges for the project manager and team members are over. Getting the project manager and project participants to wrap up the odds and ends necessary to fully complete a project is often difficult. It's like the party is over—now who wants to help clean up? Much of work is mundane and tedious. Motivation can be the chief challenge. For example, accounting for equipment and completing final reports are perceived as dull administrative tasks by project professionals who are action-oriented individuals. The project manager's challenge is to keep the project team focused on the remaining project activities and delivery to the customer until the project is complete. Communicating a closure and review plan and schedule early allows

8/12/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/50!/4/304/2@0:68.0 6/39

Page 514

PRINTED BY: [email protected]. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without publisher's prior permission. Violators will be prosecuted.

the project team to (1) accept the psychological fact the project will end and (2) prepare to move on. The ideal scenario is to have the team member's next assignment ready when project completion is announced. Project managers need to be careful to maintain their enthusiasm for completing the project and hold people accountable to deadlines, which are prone to slip during the waning stages of the project.

Implementing the closure process includes several wrap-up activities. Many organizations develop lengthy lists for closing projects as they gain experience. These are very helpful and ensure nothing is overlooked. Implementing closedown includes the following six major activities:

1. Getting delivery acceptance from the customer. 2. Shutting down resources and releasing to new uses. 3. Reassigning project team members. 4. Closing accounts and seeing all bills are paid. 5. Delivering the project to the customer. 6. Creating a final report.

Administering the details of closing out a project can be intimidating. Some organizations have checklists of over 100 wrap-up tasks! These checklists deal with closure details such as facilities, teams, staff, customer, vendors, and the project itself. A partial administrative closure checklist is shown below in Table 14.1.

Getting delivery acceptance by the customer is a major and critical closure activity. Delivery of some projects to the customer is straightforward. Others are more complex and difficult. Ideally there should be no surprises. This requires a well-defined scope and an effective change management system with active customer involvement. User involvement is critical to acceptance (see Snapshot from Practice: New Ball Goes Flat in the NBA).

TABLE 14.1 Wrap-up Closure Checklist

8/12/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/50!/4/304/2@0:68.0 7/39

8/12/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/50!/4/304/2@0:68.0 8/39

Page 515

PRINTED BY: [email protected]. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without publisher's prior permission. Violators will be prosecuted.

SNAPSHOT FROM PRACTICE New Ball Goes Flat in the NBA*

On October 31, 2006, the National Basketball Association (NBA) opened its 57th season with new official game balls. The new ball, manufactured by Spalding, featured a new design and a new material that together was believed to offer better grip, feel, and consistency than the previous leather ball. The material is microfiber composite with moisture management that provides superior grip and feel throughout the course of a game. Additionally, the new composite material eliminates the need for a break-in period, which is necessary for the current leather ball, and achieves consistency from ball to ball.

The NBA and Spalding subjected the ball to a rigorous evaluation process that included laboratory and on-court testing process. Every NBA team received the new ball and had the opportunity to use it in practice. The ball was also tested in the NBA summer development league.

At the press conference announcing the shift from leather to microfiber balls, NBA commissioner David Stern pronounced “The advancement that Spalding has made to the new game ball ensures that the best basketball players in the world will be playing with the best basketball in the world.”

Animal rights advocates applauded the shift from leather to microfiber. Such was not the case for the players who would actually use the new ball. Grumblings emerged immediately when training camps opened in October. Washington Wizards guard Gilbert Arenas said the new basketball gets slippery when it comes in contact even with small amounts of sweat. Then Miami Heat center Shaquille O'Neil said “it feels like one of those cheap balls that you buy at a toy store.”

Some players, including league MVP Steve Nash, began complaining that the new ball was producing small cuts on their hands, “It's awful, (the friction burns) its like an irritant… sometimes I even have to tape my fingers in practice.” Perhaps LeBron James from the Cleveland Cavaliers best summed up the players attitudes toward the NBA's introduction of the new ball when he said “You can change the dress code, you can make our shorts shorter, but when you take our basketball away from us, that not a transition we handle.”

On December 1, 2006, four weeks into the season the NBA players union filed an unfair labor practice suit because the league management switched to the new ball without consulting the players. Ten days later, the NBA announced that they would revert back to the old leather ball beginning January 1st 2007. In a terse statement, Commissioner David Stern said “Our player's response to this particular composite ball has been overwhelmingly negative and we are acting accordingly.”

The failure to check with the players (the end-users) and get buy-in for the new basketball was loudly criticized by the press. “How they could actually even get it that far and not have run it by the players is just an amazing, amazing exercise in ineptitude,” Rob Frankel, a Los Angeles–based branding expert told Bloomberg News.

* “NBA Introduces New Game Ball”, www.nba.com/news, posted 6-28-2006; Howard Bloom, “The NBA-uneventful 2006 II,” Sports Business News, www.sportsbixnews.blogspot.com. 12-30-2006.

The conditions for completing and transferring the project should be set before the project begins. A completed software program is a good example of the need to work out the details in advance. If the user has problems using the software, will the customer withhold final payments? Who is responsible for supporting and training the user? If these conditions are not clearly defined up front, getting delivery acceptance can be troublesome.

8/12/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/50!/4/304/2@0:68.0 9/39

Another delivery tactic (briefly mentioned in Chapter 7) for a project that has been outsourced is known as build, own, operate, and transfer (BOOT). In this type of project the contractor builds, owns, and operates the project deliverable for a set period of time. For example, Haliburton will operate a hydro-electric plant for six months before turning over operations to their Indian counterparts. During this time all the bugs are worked out and conditions for delivery are satisfied. Again, note the delivery conditions need to be carefully set up before the project begins; if not, wrap-up activities can develop a life of their own.

8/12/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/50!/4/304/2@0:68.0 10/39

Page 516

PRINTED BY: [email protected]. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without publisher's prior permission. Violators will be prosecuted.

Releasing the project team typically occurs gradually during the closure phase. For some people, termination of their responsible activities ends before the project is delivered to the customer or user. Reassignment for these participants needs to take place well before the final finish date. For the remaining team members (full or part time), termination may result in a new project or returning to their functional job. Sometimes, on product development efforts, team members will be assigned to operations positions and play an active role in the production of the new product. For contract people it may mean the end of their assignment to this project; in some cases there may be follow-up work or user support possibilities. A small number of part-time participants may be recommended to the user organization to train or operate new equipment or systems.

Since many work invoices are not submitted until after the project is officially over, closing out contracts is often messy and filled with untied ends. For example, it is improbable all invoices have been finalized, billed, and paid. Further, when contractors are used, there is a need to verify that all the contracted work has been done. Keeping contract records, such as progress reports, invoices, change records, and payment records, is important should a compliance or lawsuit occur. Too often in the haste to meet deadlines, paperwork and record keeping gets short changed, only to create major headaches when it comes time for final documentation.

There are many more wrap-up activities; it is important to complete all of them. Experience has proved time and again that not doing all the little cleanup tasks well will create problems later. Two other examples of closure checklists are shown in this chapter: Appendix 14.1 presents an example used by the state of Virginia and Appendix 14.2 presents an abridged closure checklist for the Euro Conversion project. The final wrap-up activity of closure that provides a clear signal that the project is truly over is submission of the final project report.

Creating the Final Report The final project report summarizes project performance and provides useful information for continuous improvement. Although the final report will be customized to your project and organization, the content of the final report typically includes the following topics: executive summary, review and analysis, recommendations, lessons learned, and appendix.

Executive Summary This summary simply highlights the key findings and facts relating to the project implementation. For example, the project goals for the customer were met, or not. Are stakeholders satisfied that their strategic intents have been met? What has been user reaction to quality of the deliverables? Are the project deliverables being used as intended and providing the expected benefits? Final time, cost, and scope performances are listed. Any major problems encountered and addressed are noted. Key lessons learned are identified.

Review and Analysis Data are collected to record the project history, management performance, and lessons learned to improve future projects. Analysis examines in detail the underlying causes of problems, issues, and successes. The analysis section includes succinct, factual review statements of the project—for example, project mission and objectives, procedures and systems used, and organizational resources used. It is common to collect data from the organizational view and from the team view. The project office or closure facilitators often use questionnaires and surveys to pick up on issues and events that need to be examined further. For example, “Was

8/12/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/50!/4/304/2@0:68.0 11/39

Page 517

PRINTED BY: [email protected]. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without publisher's prior permission. Violators will be prosecuted.

the organizational culture supportive and correct for this type of project? Why? Why not?” Or, “Did the team have adequate access to organizational resources—people, budget, support groups, equipment?” The project office also provides project schedules, cost comparisons, scope data, and other needed data to tell the story of performance. This information is used to create a final project report.

Recommendations Usually, review recommendations represent major improvement actions that should take place. They are often technical in nature and focus on solutions to problems that surfaced. For example, to avoid rework, the report for a construction project recommended shifting to more resilient building material. In other cases, they may include terminating or sustaining vendor or contractor relationships.

Lessons Learned Perhaps lessons learned are the most valuable contribution of the closure process. Given the process evaluation and input from the stakeholder meetings, lessons learned should be succinctly and clearly set out. Stress the need to help others in future projects. In practice, new project teams studying past project reports similar to the project they are about to start have found past review reports very useful. Team members will frequently remark later, “The recommendations were good, but the ‘lessons learned’ section really helped us avoid many pitfalls and made our project implementation smoother.” It is for precisely this reason that lessons learned in the form of project retrospectives have taken on greater prominence in the field and warrant an extended discussion at the end of this chapter. See Snapshot from Practice: Lessons Learned from Katrina.

Appendix The appendix may include backup data or details of analysis that would allow others to follow up if they wished. It should not be a dumping ground used for filler; only critical pertinent information should be attached.

Post-Implementation Evaluation The purpose of project evaluation is to assess how well the project team, team members, and project manager performed.

Team Evaluation Evaluation of performance is essential to encourage changes in behavior and to support individual career development and continuous improvement through organizational learning. Evaluation implies measurement against specific criteria. Experience corroborates that before commencement of a project, the stage must be set so expectations, standards, supportive organizational culture, and constraints are in place; if not, the effectiveness of the evaluation process will suffer.

In a macro sense, the evidence today suggests that performance evaluation is not done well. See Research Highlight: Measures of Team Performance. The major reasons cited by practitioners are twofold:

1. Evaluations of individuals are still left to supervisors of the team member's home department. 2. Typical measures of team performance center on time, cost, and specifications.

Most organizations do not go beyond these measures, although they are important and critical. Organizations should consider evaluating the team-building process, effectiveness of group decision and problem-solving processes, group cohesion, trust among team members, and quality of information exchanged. Measurement of customer and user satisfaction with project deliverables (i.e., the project results) is often missed completely. Yet, project success depends significantly on satisfying these two very important groups. The quality of the deliverables is the responsibility of the team.

8/12/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/50!/4/304/2@0:68.0 12/39

Page 518

PRINTED BY: [email protected]. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without publisher's prior permission. Violators will be prosecuted.

SNAPSHOT FROM PRACTICE Lessons Learned from Katrina*

On August 25, 2005, winds of 145 miles per hour and rains covered 80 percent of New Orleans with some areas under 20 feet of water. Hurricane Katrina dispersed havoc on every corner of New Orleans. In its trail it left over 1,300 people dead in Louisiana and Mississippi. Katrina will long be remembered as the costliest and most deadly hurricane ever recorded in the United States.

Response came from many different groups from within the country and from other countries. Katrina also drew the largest response of The National Guard to a national emergency in history. Governors from every state sent National Guard troops to support and assist the state of Mississippi. By September 8, 51,000 troops were responding to the emergency. Many other nonprofit groups offered help in a variety of ways—food, shelter, financial, health care, and transportation. Groups that contributed support have reviewed their efforts to see what lessons learned can be used to improve future emergency efforts. The results of the review of The National Guard efforts follow here:

Three of the key lessons from The National Guard retrospective are described.

Lack of equipment was one of the biggest problems—especially communication equipment. Ability to communicate among the many different support groups (e.g., civilian and military) was thwarted by incompatible systems or simple lack of availability.

Action Item: $1.3 billion has been authorized for new equipment that is compatible across major emergency groups. Lack of protocols and standardization of reports, graphics, and communication caused delays and poor coordination among the many support groups.

Action Item: A single standard protocol for all states is now being applied. The National Guard is under state control. Guard troops integrated quickly into the host-state command structures and cooperation ensued.

Action Item: Maintain status quo.

Because Guard soldiers are controlled by the states, they were empowered to enforce civil laws, something federal troops are prohibited from doing, except under the provisions of the insurrection laws. Fortunately, coordination and cooperation among state and federal troop command work reasonably well. However, the federal agencies (e.g., Homeland Security) need to incorporate the Guard into planning and preparation for the federal response to catastrophic disasters.

Lessons learned from the Katrina disaster are not limited to the military. Almost every agency and support group, such as individuals, communities, churches, and other groups, have developed lessons learned from their project response experience. For example, the Red Cross and state guard have better plans for handling thousands of people problems involving shelter, evacuation, and medical assistance. These lessons learned from Katrina are ready to go and should be enormously helpful in future hurricane situations.

* Les A. Melnyk, “Katrina Lessons Learned,” Soldiers Magazine, June 20, 2006 and “Lessons Learned from Katrina: Preparing Your Institution for a Catastrophic Event.” Federal Deposit Insurance Corporation is the source of this information. 1/20/08

Before an evaluation of the project team can be effective and useful, a minimum core of conditions needs to be in place before the project begins (see Chapter 11). Some typical conditions are listed here in the form of

8/12/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/50!/4/304/2@0:68.0 13/39

questions:

1. Do standards for measuring performance exist? (You can't manage what you can't measure.) Are the goals clear for the team and individuals? Challenging? Attainable? Lead to positive consequences?

2. Are individual and team responsibilities and performance standards known by all team members? 3. Are team rewards adequate? Do they send a clear signal that senior management believes that the synergy

of teams is important? 4. Is a clear career path for successful project managers in place? 5. Is the team empowered to manage short-term difficulties? 6. Is there a relatively high level of trust emanating from the organizational culture? 7. Team evaluation should go beyond time, cost, and specifications. Are there criteria beyond the constraint

criteria? Creation of project deliverables would be a good place to start. The “characteristics of highly effective teams” from Chapter 11 can easily be adapted as measurements of team performance.

8/12/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/50!/4/304/2@0:68.0 14/39

Page 519

PRINTED BY: [email protected]. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without publisher's prior permission. Violators will be prosecuted.

Research Highlight Measures of Team Performance*

If team evaluation is not done well in practice, how bad is it? Joseph Fusco surveyed 1,667 project managers representing 134 different projects. Fifty-two percent of the respondents indicated their team received no collective evaluation of their team performance. Of the 22 percent who indicated their team was evaluated, further probing found their evaluation was informal, lasting little more than 20 minutes. This apparent lack of team evaluation practices may be sending the wrong signal. Individual team members can slough off poor team performance by relying on the old saying, “I did my job.” Strong team evaluation practices need to emphasize team members are “in this together,” while minimizing individual performance. Nearly every company in Fusco's survey lacked an effective project management reward system.

* Joseph Fusco, “Better Policies Provide the Key to Implementing Project Management,” Project Management Journal, Vol. 28, No. 3, September 1997, p. 38.

The “in-place conditions” will support any evaluation approach for teams and their members. In practice, the actual team evaluation process takes many forms—especially when evaluation goes beyond

time, budget, and specifications. The typical mechanism for evaluation of teams is a survey administered by a consultant, a staff member from the human resources department, or through computer e-mail. The survey is normally restricted to team members, but in some cases, other project stakeholders interacting with the team may be included in the survey. An example of a partial survey is found in Table 14.2. After the results are tabulated, the team meets with the facilitator and/or senior management, and the results are reviewed.

This session is comparable to the team-building sessions described in Chapter 11, except that the focus is on using the survey results to assess the development of the team, its strengths and weaknesses, and the lessons that can be applied to future project work. The results of team evaluation surveys are helpful in changing behavior to better support team communication, the team approach, and continuous improvement of team performance.

TABLE 14.2 Sample Team Evaluation and Feedback Survey

8/12/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/50!/4/304/2@0:68.0 15/39

8/12/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/50!/4/304/2@0:68.0 16/39

Page 520

PRINTED BY: [email protected]. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without publisher's prior permission. Violators will be prosecuted.

SNAPSHOT FROM PRACTICE The 360-Degree Feedback*

More and more companies are discarding the traditional superior-subordinate performance feedback process and replacing it with 360-degree feedback systems. The 360-degree feedback approach gathers behavioral observations from many sources within the organization and includes employee self-assessment. The individual completes the same structured evaluation process that superiors, project team members, peers and, in many cases, external customers use to evaluate a performance. Survey questionnaires, augmented by a few open-ended questions, are typically used to gather information.

Summary results are compared against organizational strategies, values, and business objectives. The feedback is communicated to the individual with the assistance of the company's human resource department or an outside consultant. The technique is used by a growing number of firms including General Electric, AT&T, Mobil Oil, Nabisco, Hewlett-Packard, and Warner-Lambert.

The objective of the 360-degree process is to identify areas for individual improvement. When anonymous feedback solicited from others is compared with the individual's self-evaluations, the individual may form a more realistic picture of her strengths and weaknesses. This may prompt behavioral change if the weaknesses identified were previously unknown to the individual. So, for example, a project manager who thinks he delegates work effectively found out that his subordinates disagree. This caused him to rethink how he delegates and decide to delegate more and sooner.

Many firms obtain feedback from internal and external project customers. For example, a client may evaluate a project manager or member of the project team according to, “How effectively does the individual get things done without creating unnecessary adversarial relationships?” Incorporating customer feedback in the evaluation process underscores collaboration and the importance of client expectations in determining project success.

* Brian O'Reilly, “360 Feedback Can Change Your Life,” Fortune, October, 17, 1994, pp. 93–100; Robert Hoffman, “Ten Reasons You Should Be Using 360 Degree Feedback,” HR Magazine, April 1995, pp. 82–85; Dick Cochran, “Finally, a Way to Completely Measure Project Manager Performance,” PM Network, September 2000, pp. 75–80.

Individual, Team Member, and Project Manager Performance Reviews Organizations vary in the extent to which their project managers are actively involved in the appraisal process of team members. In organizations where projects are managed within a functional organization, the team member's area manager, not the project manager, is responsible for assessing performance. The area manager may solicit the project manager's opinion of the individual's performance on a specific project; this will be factored into the individual's overall performance. In a balanced matrix, the project manager and the area manager jointly evaluate an individual's performance. In project matrix and project organizations in which the lion's share of the individual's work is project related, the project manager is responsible for appraising individual performance. One process that appears to be gaining wider acceptance is the multi-rater appraisal or “360-degree feedback,” which involves soliciting feedback concerning team members’ performance from all the people their work affects. This would include not only project and area managers, but also peers, subordinates, and even customers. See Snapshot from Practice: The 360-Degree Feedback.

Performance appraisals generally fulfill two important functions. The first is developmental in nature: the focus is on identifying individual strengths and weaknesses and developing action plans for improving

8/12/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/50!/4/304/2@0:68.0 17/39

performance. The second is evaluative and involves assessing how well the person has performed in order to

8/12/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/50!/4/304/2@0:68.0 18/39

Page 521

PRINTED BY: [email protected]. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without publisher's prior permission. Violators will be prosecuted.

determine salary or merit adjustments. These two functions are not compatible. Employees, in their eagerness to find out how much pay they will receive, tend to tune out constructive feedback on how they can improve their performance. Likewise, managers tend to be more concerned with justifying their decision than engaging in a meaningful discussion on how the employee can improve his or her performance. It is difficult to be both a coach and a judge. As a result, several experts on performance appraisal systems recommend that organizations separate performance reviews, which focus on individual improvement, and pay reviews, which allocate the distribution of rewards (cf., Romanoff, 1989; Latham and Wexley, 2003).

In some matrix organizations, project managers conduct the performance reviews, while area managers are responsible for pay reviews. In other cases, performance reviews are part of the project closure process, and pay reviews are the primary objective of the annual performance appraisal. Other organizations avoid this dilemma by allocating only group rewards for project work and providing annual awards for individual performance. The remaining discussion is directed at reviews designed to improve performance because pay reviews are often outside the jurisdiction of the project manager.

Individual Reviews Organizations employ a wide range of methods to review individual performance on a project. In general, review methods of individual performance center on the technical and social skills brought to the project and team. Some organizations rely simply on an informal discussion between the project manager and the project member. Other organizations require project managers to submit written evaluations that describe and assess an individual's performance on a project. Many organizations use rating scales similar to the team evaluation survey in which the project manager rates the individual according to a certain scale (i.e., from 1 to 5) on a number of relevant performance dimensions (i.e., teamwork, customer relations). Some organizations augment these rating schemes with behaviorally anchored descriptions of what constitutes a 1 rating, a 2 rating, and so forth. Each method has its strengths and weaknesses, and, unfortunately, in many organizations the appraisal systems were designed to support mainstream operations and not unique project work. The bottom line is that project managers have to use as best they can the performance review system mandated by their organization.

Regardless of the method, the project manager needs to sit down with each team member and discuss his or her performance. Here are some general tips for conducting performance reviews:

Always begin the process by asking the individual to evaluate his or her contributions to the project. First, this approach may yield valuable information that you were not aware of. Second, the approach may provide an early warning for situations in which there is disparity in assessments. Finally, this method reduces the judgmental nature of the discussion. Avoid, when possible, drawing comparisons with other team members; rather, assess the individual in terms of established standards and expectations. Comparisons tend to undermine cohesion and divert attention away from what the individual needs to do to improve performance. When you have to be critical, focus the criticism on specific examples of behavior rather than on the individual personally. Describe in specific terms how the behavior affected the project.

8/12/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/50!/4/304/2@0:68.0 19/39

Page 522

PRINTED BY: [email protected]. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without publisher's prior permission. Violators will be prosecuted.

Be consistent and fair in your treatment of all team members. Nothing breeds resentment more than if, through the grapevine, individuals feel they are being held to a different standard than are other project members. Treat the review as only one point in an ongoing process. Use it to reach an agreement as to how the individual can improve his or her performance.

Both managers and subordinates may dread a formal performance review. Neither side feels comfortable with the evaluative nature of the discussion and the potential for misunderstanding and hurt feelings. Much of this anxiety can be alleviated if the project manager is doing her job well. Project managers should be constantly giving team members feedback throughout the project so that individual team members can have a pretty good idea how well they have performed and how the manager feels before the formal meeting. Post-project angst can be avoided if pre-project expectations are discussed before the project and regularly reenforced during project performance.

While in many cases the same process that is applied to reviewing the performance of team members is applied to evaluating the project manager, many organizations augment this process, given the importance of the position to their organization. This is where conducting the 360-degree review is becoming more popular. In project-driven organizations, the project office typically will be responsible for collecting information on a specific project manager from customers, vendors, team members, peers, and other managers. This approach has tremendous promise for developing more effective project managers (Cochran, 2000).

In addition to performance reviews, data are collected for project retrospectives, which can present situations that may influence performance. In these situations performance evaluations should recognize and note the unusual situation.

Retrospectives

Why Retrospectives? Lessons learned represent an analysis carried out during and shortly after the project life cycle; they attempt to capture positive and negative project learning. That is, “what worked and what didn't?” Lessons learned (postmortems, post-project review, or whatever name you choose to use) have long been part of project management. Peter Senge's The Fifth Discipline: The Art and Practice of the Learning Organization (1990) drew attention to institutionalizing organizational learning.

Although the past processes have been useful for closure and lessons learned, sadly their real value has not been exploited. Large, multinational companies with projects spread across the globe have been disappointed in their failure to effectively mine lessons learned. Smaller organizations observed, they too were not reaping the golden rewards of lessons learned. The same mistakes continue year after year. In the words of one executive: “Lessons learned are worth their weight in gold. I do not understand why we don't do a better job nurturing, dispersing, and implementing lessons learned.” The processes for capturing lessons learned continue to evolve, but there are still many barriers to effectively mining the lessons learned that have been identified by practitioners. A few of the most ubiquitous barriers are noted here.

The most common reason given for not creating lessons learned is lack of time. Most lessons learned are captured when the project is complete; teams get little direction or support after the lessons are reported.

8/12/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/50!/4/304/2@0:68.0 20/39

Page 523

PRINTED BY: [email protected]. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without publisher's prior permission. Violators will be prosecuted.

Lessons learned often degenerate into blame sessions that became emotionally damaging. Lessons learned are not being used across different locations. Lessons learned while implementing the project are seldom used to improve the remaining work in the project. Too often the lessons learned are not used in future projects because the organizational culture fails to recognize the value of learning.

What is needed to overcome these barriers is a methodology and management philosophy to ensure lessons learned are identified, utilized, and become a significant part of the project management organizational culture. The keys are to turn lessons learned into actions taken and to have someone own the lesson. One effort that appears to address the barriers and offer a solution is retrospectives. The military has long used retrospectives to improve their operations (e.g., after each maneuver). Retrospectives have emerged as a strong process and management philosophy used by project-driven organizations around the world to mine the gold that lessons learned can provide. Retrospectives are championed by Norman Kerth in his text Project Retrospectives (2001).

A retrospective is a methodology that analyzes a past project event to determine what worked and what didn't, develops lessons learned, and creates an action plan that ensures lessons learned are used to improve management of future projects.

The major goals of retrospectives are to reuse solutions and stop repetitive mistakes across the organization. Retrospectives methodology has several embedded, distinguishing characteristics to ensure its effectiveness

and value:

Uses an independent facilitator. Includes a minimum of three in-process learning gates during the project life cycle. Has an owner. Develops a repository that is easy to use. Mandates a discipline that ensures retrospectives are used.

Initiating the Retrospective Review The review process depends primarily on organization size and project size. Every effort should be made to make the project review a normal process rather than a surprise notice. In small organizations and projects where face-to-face contact at all levels is prevalent, the closure may be informal and only represent another staff meeting. But even in these environments the content of a formal project review should be examined and covered with notes made of the lessons learned. In some organizations, review initiation comes from a formal project review group or can be automatic. For example, in the latter case, all projects are reviewed at specific stages in the project life cycle—perhaps when a project is 10 to 20 percent complete in time or money, 50 percent complete, and after completion. In most other multiproject organizations, reviews (called stage gates) are planned for the completion of major milestones. The review is not linked to percent complete. Milestones are binary; either you have reached requirements completion or you have not. Regardless of how reviews are set up, they should be set up in the project planning stage—before the project begins.

8/12/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/50!/4/304/2@0:68.0 21/39

Page 524

PRINTED BY: [email protected]. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without publisher's prior permission. Violators will be prosecuted.

Use of an Independent Facilitator The retrospective methodology uses an independent facilitator to collect and implement lessons learned to improve management of current and future projects. A project facilitator is a guide who leads the project team through an analysis of project activities that went well, what needs improvement, and development of a follow- up action plan with goals and accountability.

Selection of a Facilitator Characteristics of a Facilitator Any project review starts with staffing. That is, who will facilitate the review and be accountable for conducting it? Perhaps nothing influences the success of project review more than the selection of the closure facilitator. Selection of the facilitator should not be a random selection from the project office! The key requirement in selection of the facilitator is independence. It is imperative that the closure facilitator possess the following characteristics, at a minimum:

1. No direct involvement or direct interest in the project. 2. Perceived as impartial and fair. 3. Respect of senior management and other project stakeholders. 4. Willingness to listen. 5. Independence and authority to report review results without fear of recriminations from special interests. 6. Perceived as having the best interests of the organization in making decisions. 7. Broad-based experience in the organization or industry.

Other review participants should have similar characteristics even if they are selected for their special expertise.

Roles of a Facilitator There are good reasons for using an independent facilitator. Lessons learned exercises can have negative consequences. The exercise can degenerate into a griping session that places blame. Word of the negative consequences travels fast and results in poor, guarded participation. The focus fails to stay on causes and improving future performance. The facilitator needs to be careful to avoid blame and allow stakeholders to feel safe to provide input.

A trained independent facilitator is often capable of gleaning information that would not be forthcoming to the project manager. Project participants report they are far more willing to attend and contribute to a lessons learned session run by an independent facilitator who can eliminate most political aspects in gathering lessons learned. The facilitator can deliver bad news to the project sponsor or senior management without recriminations. For example, since it is never pleasant for the project manager to deliver bad or potentially bad news to senior management or the project owner, many people wait until it is too late. In one project the facilitator received information and was able to give senior management a heads-up that there was a better than 60 percent risk of a delay of new, self-controlled, diesel railcars from a vendor having financial difficulties. Action was taken and money was loaned to the railcar company to avoid delay.

In the words of one project manager, “The facilitator takes the monkey off my back.” For this and other reasons, many organizations use an independent

8/12/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/50!/4/304/2@0:68.0 22/39

Page 525

PRINTED BY: [email protected]. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without publisher's prior permission. Violators will be prosecuted.

retrospective facilitator to manage the retrospective process. Team members may be intimidated when the project manager or senior management attends team meetings. A recognized facilitator can elicit a 360-degree view/input from all stakeholders to create a richer, fuller picture of project issues and successes. The key criterion for selecting a project facilitator is that the facilitator has an independent and unbiased relationship to the project. Nike, Intel, Portland General Electric, Conway trucking, and various state governments use trained independent facilitators for lessons learned on large projects.

Managing a Retrospective Having a facilitator available at the start of a project is preferred. The retrospective approach stresses gathering lessons learned during project execution and using them to change remaining work. Experience tells us memories fade as time passes; people leave the project. If lessons learned are not captured early, they may be lost. Catching lessons midway in the project life cycle allows for changing the way the remaining work is performed. (Some practitioners call this process “correcting course while the project is in flight.”) Most retrospective methods use a minimum of three gates during the project life cycle to collect lessons learned that can be used to self correct the remainder of project execution. See Figure 14.2 for a flow chart of the collection of lessons learned.

It is critical to have a separate repository or library where reports and lessons learned are accessible and easy to retrieve. Your authors have encountered more than one organization that does a nice job of creating a closure report, but the report is placed in someone's bottom drawer or file cabinet, never to be seen again. This is truly a big mistake! The lessons learned are often the single best information a project manager or team can use in planning a future project. Repeatedly, project managers tell stories of how lessons learned “saved their lives” by allowing them to avoid a pitfall. Presentations at organization meetings or conferences encourage others to use and develop lessons learned. It also provides a chance to shine. The responsibility for maintaining a repository for lessons learned and encouraging its use is normally the responsibility of the project office or oversight committee. See Research Highlight: CHAOS: Software Projects.

FIGURE 14.2 Retrospectives Process

8/12/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/50!/4/304/2@0:68.0 23/39

Page 526

PRINTED BY: [email protected]. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without publisher's prior permission. Violators will be prosecuted.

Research Highlight Chaos: Software Projects*

The Standish Group International is a market research and advisory firm specializing in mission-critical software and electronic commerce. They have conducted and published extensive research on the success and failure of software development/application projects. Their research, code name “CHAOS,” shows that a staggering 31 percent of software projects will be canceled before they are ever completed. In addition, 53 percent of projects will cost 189 percent of their original estimates. In terms of success, on the average only 16 percent of software projects are completed on time and within budget. In larger companies, the success rate is much worse—9 percent. The Standish Group estimated that in 1995 American companies and government agencies spent $81 billion for canceled software projects.

The CHAOS research is based on “key findings” from research surveys and personal interviews. The respondents were information technology (IT) executive managers. The sample included large, medium, and small companies across major industry segments, for example, banking; securities; manufacturing; retail; wholesale; health care; insurance service; and local, state, and federal organizations. The total sample size was 365 respondents and represented 8,380 projects.

Based on an in-depth comparison of successful versus unsuccessful software projects, the Standish Group created a success potential chart that identifies key factors associated with project success. The success criteria were weighted based on the input from the surveyed IT managers. The most important criterion, “user involvement,” was given 19 success points, while the least important, “hard-working, focused staff,” was given 3 success points. The following chart lists the criteria in order of importance:

* Used by permission of the Standish Group International, Inc., 196 Old Town House Rd., West Yarmouth, MA 02673. The CHAOS report was updated in 2001 and 2009. Although improvement was noted (e.g., cost overruns were reduced to 145 percent), the magnitude of the core problems remains the same.

8/12/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/50!/4/304/2@0:68.0 24/39

Overseeing a Post-Project Retrospective In the past, lessons learned were primarily collected from a post-project survey. Someone reviewed the answers, summarized the results, and filed the document. In retrospective methodology, the facilitator uses several questionnaires as a starting point to conduct the post-project retrospective. These surveys often offer clues to unrecognized deeper problems. A facilitator relates that clues to areas needing improvement are often found by checking the changes running through the project's change management system. For example, change management in multiple design changes might suggest poor freeze rules for design. These hard data can point directly to areas that hold potential for improvement. In some cases the data direct the facilitator to the area where a problem was solved.

8/12/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/50!/4/304/2@0:68.0 25/39

Page 527

PRINTED BY: [email protected]. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without publisher's prior permission. Violators will be prosecuted.

TABLE 14.3 Project Process Review Questionnaire

Process and Methods Review Process review begins with a review of the strategic intent of the project, selection criteria, project charter, project objectives, project scope, and acceptance criteria. This starting point reinforces and clarifies the business case for the project and the final project deliverables. Additional data gathering for process review is initiated through a questionnaire that is distributed to all major project stakeholders for responses. Some typical questions used are shown in Table 14.3. Although this questionnaire has some areas of omission, it can be used to initiate developing a questionnaire for your project.

Organizational Review One of the themes of this text is that project performance is strongly influenced by organizational culture. It is therefore important to assess what fundamental organizational culture properties affect project successes and failures or become a hindrance to project teams. Again, survey questionnaires are easy, quick, and inexpensive

8/12/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/50!/4/304/2@0:68.0 26/39

to develop and collect data. Table 14.4, Organizational Culture Review, shows a partial organizational survey found in practice.

It is rare that important problems or successes will not show up in answers to a well-developed questionnaire.

8/12/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/50!/4/304/2@0:68.0 27/39

Page 528

PRINTED BY: [email protected]. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without publisher's prior permission. Violators will be prosecuted.

TABLE 14.4 Organizational Culture Review Questionnaire

With survey information in hand, the facilitator then visits one-on-one with project team members, the project manager, and other stakeholders to dive deeper into cause-effect impacts. Fundamentally, the attempt is to isolate “the lack of x resulted in y.” It is important to stay with the big lessons. For example, the facilitator might ask team members, “What was the biggest pain point in the project?” From these discussions the facilitator synthesizes collective wisdom.

Armed with the information gleaned from one-on-one sessions and other sources, the facilitator leads a team retrospective session. This session first reviews the facilitator's report and attempts to add key information. In fact, one of the roles of the facilitator is to lead the team in exploring new ways for solving a problem. Once the team reaches consensus of the key retrospective(s), the team develops and documents an action plan for improving future projects. Each retrospective should have at least one lesson that will improve current or future projects. One person needs to be assigned “owner” of the lesson learned and serve as the go-to person for more information. If possible, the facilitator should get senior management's commitment to implement the lesson.

An additional task of a facilitator is a review of the archived lessons to identify any trends across similar projects. For example, are there affinities between problems and successes among many projects? Have resources been inadequate? Has senior management visibly supported mining lessons learned? What fundamental organizational culture dimensions affect project successes and failures or become a hindrance to project teams?

In a conversation with one project office manager, she related that a facilitator found that the same problem across most multicountry projects had been occurring for over four years! It is difficult to believe no one picked up on such an obvious problem on so many projects. In this organization, U.S. managers were too focused on schedules, performance, and the bottom line; they neglected to establish a personal relationship with their foreign counterparts—e.g., the counterpart's key interests, family, holiday celebrations, and many other cultural aspects. Relationships were often strained and performance suffered. The result was that the project participants in each country are now required to attend a

8/12/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/50!/4/304/2@0:68.0 28/39

Page 529

PRINTED BY: [email protected]. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without publisher's prior permission. Violators will be prosecuted.

culture awareness class of the country of their counterparts to learn of customs, culture, and mores. Results improved dramatically.

Utilization of Retrospectives Each retrospective is assigned an owner, typically a team member who is very interested in and familiar with the retrospective. This team member/owner will serve as the contact point for anyone needing information (expertise, contacts, templates, etc.) relating to the retrospective.

Another task of the retrospective facilitator is to guarantee there is a clear process to ensure retrospectives are used to improve management of future projects. Where retrospective methodology is used, some organizations mandate that the team of a new project review the retrospectives of similar projects. This mandate is one tactic that ensures that the most significant lessons are institutionalized. There is no excuse for not using past best practices and avoiding past mistakes. If the project managers before your project had completed retrospectives more effectively, your project might have avoided many mistakes. Of course, a requirement is archiving the lessons in a repository/library. But beyond a retrospective lessons learned library, a simple, easy to use, consistent format is necessary to ensure that information is easily found, used, and updated over time. A blog can be used to receive user comments on how helpful the retrospective is in improving a process or product.

Archiving Retrospectives If retrospectives are to be used, it is critical to have a repository where reports and retrospective/lessons learned are accessible and easily retrieved. This is usually done using a Web site or other electronic means. For example, a round table of project office directors estimated that among their group of companies, 60–70 percent of their projects are global and virtual; all use some version of a Web-based system to collaborate and archive learning (e.g., Basecamp, SharePoint, Net Meeting, Voice Over IP). The responsibility for maintaining a repository for retrospectives and encouraging their use is normally the responsibility of the project office or oversight committee. Encouraging use of the repository depends on the ease of searching for information that is relevant to your project. Utilizing the information is defeated if information is difficult to find. For example, one project manager reported to your authors, “There are so many lessons learned items in the retrospectives library, I can't find information that applies to my project.” This manager either wasn't interested in learning from others or the archive was poorly arranged.

At a minimum the repository should classify projects by type or characteristics. Each project review is categorized because there are differences in the way projects with different characteristics are managed and handled in an organization. A prospective project manager of a software coding project will have little interest in the construction of a clean room or recycling of inkjet reservoirs for printers. A prospective project manager of a small project will not be as interested in a computer project planning and control system as a project manager who is going to manage a very large project. The classification of projects by characteristics allows prospective readers, teams, and project managers to be selective in the search and use of report content.

8/12/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/50!/4/304/2@0:68.0 29/39

Page 530

PRINTED BY: [email protected]. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without publisher's prior permission. Violators will be prosecuted.

One repository search engine uses the following classification scheme to allow prospective project stakeholders to start their search for information related to their prospective project:

Project type—e.g., development, marketing, systems, construction. Size—monetary. Number of staff. Technology level—low, medium, high, new. Strategic or support.

Other classifications relevant to the organization could be included to drill further in search of projects that match the features of the prospective project. For example, another classification system indexes retrospectives by issues and problems.

Celebration A final wrap-up activity for the facilitator is the project closure celebration. An upbeat, festive celebration brings closure to the enjoyable experiences everyone has had and the need to say good-bye. Celebration is an opportunity to recognize the effort project stakeholders contributed. Even if the project did not reach its objectives, recognize the effort and goals that were achieved. If the project was a success, invite everyone who in some way contributed to project success. Thank the team and each one individually. The spirit of the celebration should be one in which the stakeholders are thanked for a job well done and leave with a good feeling of accomplishment and success.

Concluding Retrospective Notes The retrospective methodology is more inclusive and disciplined than past lessons learned approaches. The impetus for its success has been accompanied by greater recognition of the real value of lessons learned in improving the management of projects. For example, Intel, which has project teams dispersed over 290 locations in 45 countries, has found using trained facilitators to be highly effective in mining and using retrospectives. Intel continues to train 15 new facilitators each year. Retrospective methodology is now standard operating procedure in many project-driven organizations. The lessons learned are often the single best source of information a project manager or team can use in planning their next project. Retrospectives are a main change agent for developing best project-management practices across the organization. Retrospective methodology is one positive step toward ensuring lessons learned are developed and implemented.

Summary

The goals of project closure are to complete the project and to improve performance of future projects. Implementing closure and review has three major closure deliverables: wrap-up, evaluation, and retrospectives. Wrap-up closure activities include delivering the final project deliverable, closing accounts, finding new opportunities for project staff, closing facilities, and creating the final report. Project evaluation verifies and documents project performance. The retrospectives methodology promises lessons learned are identified and used. Too often we spend massive dollars planning a project and little to nothing learning from the experience of completing the project. Failure to review, assess, and record successes and failures has consistently proven to be a costly waste. Retrospective methodology addresses this waste.

8/12/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/50!/4/304/2@0:68.0 30/39

Page 531

PRINTED BY: [email protected]. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without publisher's prior permission. Violators will be prosecuted.

Key Terms Lessons learned, 522 Performance review, 520 Project closure, 511 Project evaluation, 517 Project facilitator, 524 Retrospective, 523 Team evaluation, 517 360-degree review, 522

Review Questions

1. How does the project closure review differ from the performance measurement control system discussed in Chapter 13?

2. What major information would you expect to find in a project review? 3. Why is it difficult to perform a truly independent, objective review? 4. Comment on the following statement: “We cannot afford to terminate the project now. We have

already spent more than 50 percent of the project budget.” 5. Why should you separate performance reviews from pay reviews? How do you do this? 6. Advocates of retrospective methodology claim there are distinguishing characteristics that

increase its value over past lessons learned methods. What are they? How does each characteristic enhance project closure and review?

Exercises

1. Consider a course that you recently completed. Perform a review of the course (the course represents a project and the course syllabus represents the project plan).

2. Imagine you are conducting a review of the International Space Station project. Research press coverage and the Internet to collect information on the current status of the project. What are the successes and failures to date? What forecasts would you make about the completion of the project, and why? What recommendations would you make to top management of the program, and why?

3. Interview a project manager who works for an organization that implements multiple projects. Ask the manager what kind of closure procedures are used to complete a project and whether lessons learned are used.

4. What are some of the lessons learned from a recent project in your organization? Was a retrospective done? What action plans were generated to improve processes as a result of the project?

References Anonymous, “Annual Survey of Business Improvement Architects,” Toronto, Canada, in PM Network, “Deliverables,” Vol. 21, No. 4, April 2007, p. 18.

8/12/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/50!/4/304/2@0:68.0 31/39

Cochran, D., “Finally, a Way to Completely Measure Project Manager Performance,” PM Network, September 2000, pp. 75–80. Cooke-Davies, T., “Project Management Closeout Management: More than Simply Saying Good Bye and Moving On,” in J. Knutson (Ed.), Project Management for Business Processionals (Indianapolis, IN: John Wiley and Sons, 2001), pp. 200–14.

8/12/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/50!/4/304/2@0:68.0 32/39

Page 532

PRINTED BY: [email protected]. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without publisher's prior permission. Violators will be prosecuted.

Fretty, P., “Why Do Projects Really Fail?” PM Network, March 2006, pp. 45–48. Gobeli, D., and E. W. Larson, “Barriers Affecting Project Success,” in 1986 Proceedings Project Management Institute: Measuring Success (Upper Darby, PA: Project Management Institute, 1986), pp. 22–29. Hoffman, R., “Ten Reasons You Should Be Using 360 Degree Feedback,” HR Magazine, April 1995, pp. 82–85. Jedd, Marcia, “Standing Guard,” PM Network, Vol. 21, No. 1, January 2007, pp. 73–77. Kendrick, Tom, Identifying and Managing Project Risk, 2nd ed. ANACOM, New York, NY 2009. Kerth, Norman L., Project Retrospectives: A Handbook for Team Reviews (New York: Dorset House, 2001). Kwak, Y. H., and C. W. Ibbs, “Calculating Project Management's Return on Investment,” Project Management Journal, Vol. 31, No. 2, March 2000, pp. 38–47. Ladika, S., “By Focusing on Lessons Learned, Project Managers Can Avoid Repeating the Same Old Mistakes,” PM Network, Vol. 22, No. 2, February 2008, pp. 75–77. Lavell, Debra, and Russ Martinelli, “Program and Project Retrospectives: An Introduction,” PM World Today, Vol. 10, No. 1, January 2008, p. 1. Latham, G. P., and K. N. Wexley, Increasing Productivity through Performance Appraisal, 2nd ed. (Reading, MA: Addison-Wesley, 1994). Marlin, Mark, “Implementing an Effective Lessons Learned Process in a Global Project Environment,” PM World Today, Vol. 10, No. 11, November 2008, pp. 1–6. Nelson, Ryan R., “Project Retrospectives: Evaluating Project Success, Failure, and Everything in Between,” MIS Quarterly Executive, Vol. 4, No. 3, September 2005, p. 372. Pippett, D. D., and J. F. Peters, “Team Building and Project Management: How Are We Doing?” Project Management Journal, Vol. 26, No. 4, December 1995, pp. 29–37. Romanoff, T. K., “The Ten Commandments of Performance Management,” Personnel, Vol. 66, No. 1, 1989, pp. 24–26. Royer, I., “Why Bad Projects Are So Hard to Kill,” Harvard Business Review, February 2003, pp. 49– 56. Senge, P., The Fifth Discipline: The Art and Practice of the Learning Organization (New York: Doubleday, 1990). Sheperd, D. A., H. Patzelt, and M. Wolfe, “Moving Forward from Project Failure: Negative Emotions, Affective Commitment, and Learning from the Experience,” Academy of Management Journal, Vol. 54, No. 6, 2011, pp. 1229–60. Staw, Berry M., and Jerry Ross, “Knowing When to Pull the Plug,” Harvard Business Review, March- April 1987, pp. 68–74. Wheatly, M., “Over the Bar,” PM Network, Vol. 17, No. 1, January 2003, pp. 40–45. Yates, J. K., and S. Aniftos, “ISO 9000 Series of Quality Standards and the E/C Industry,” Project Management Journal, Vol. 28, No. 2, June 1997, pp. 21–31. Zaitz, Les, “Rail Car Deal Snags Tri Met for Millions,” Oregonian, December 14, 2008, p. 1, and January 7, 2009, p. D4.

8/12/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/50!/4/304/2@0:68.0 33/39

Page 533

PRINTED BY: [email protected]. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without publisher's prior permission. Violators will be prosecuted.

Appendix 14.1

Project Closeout Checklist

8/12/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/50!/4/304/2@0:68.0 34/39

8/12/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/50!/4/304/2@0:68.0 35/39

8/12/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/50!/4/304/2@0:68.0 36/39

Page 534

PRINTED BY: [email protected]. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without publisher's prior permission. Violators will be prosecuted.

Signatures The signatures of the people below relay an understanding that the key elements within the Closeout Phase section are complete and the project has been formally closed.

8/12/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/50!/4/304/2@0:68.0 37/39

Page 535

PRINTED BY: [email protected]. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without publisher's prior permission. Violators will be prosecuted.

Appendix 14.2

Euro Conversion—Project Closure Checklist

8/12/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/50!/4/304/2@0:68.0 38/39

Page 536

PRINTED BY: [email protected]. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without publisher's prior permission. Violators will be prosecuted.

Case

Maximum Megahertz Project Olaf Gundersen, the CEO of Wireless Telecom Company, is in a quandary. Last year he accepted the Maximum Megahertz Project suggested by six up-and-coming young R&D corporate stars. Although Olaf did not truly understand the technical importance of the project, the creators of the project needed only $600,000, so it seemed like a good risk. Now the group is asking for $800,000 more and a six-month extension on a project that is already four months behind. However, the team feels confident they can turn things around. The project manager and project team feel that if they hang in there a little longer they will be able to overcome the roadblocks they are encountering—especially those that reduce power, increase speed, and use a new technology battery. Other managers familiar with the project hint that the power pack problem might be solved, but “the battery problem will never be solved.” Olaf believes he is locked into this project; his gut feeling tells him the project will never materialize, and he should get out. John, his human resource manager, suggested bringing in a consultant to axe the project.

Olaf decided to call his friend Dawn O'Connor, the CEO of an accounting software company. He asked her, “What do you do when project costs and deadlines escalate drastically? How do you handle doubtful projects?” Her response was, “Let another project manager look at the project. Ask: ‘If you took over this project tomorrow, could you achieve the required results, given the extended time and additional money?’ If the answer is no, I call my top management team together and have them review the doubtful project in relation to other projects in our project portfolio.” Olaf feels this is good advice.

Unfortunately, the Maximum Megahertz Project is not an isolated example. Over the last five years there have been three projects that were never completed. “We just seemed to pour more money into them, even though we had a pretty good idea the projects were dying. The cost of those projects was high; those resources could have been better used on other projects.” Olaf wonders, “Do we ever learn from our mistakes? How can we develop a process that catches errant projects early? More importantly, how do we ease a project manager and team off an errant project without embarrassment?” Olaf certainly does not want to lose the six bright stars on the Maximum Megahertz Project.

Olaf is contemplating how his growing telecommunications company should deal with the problem of identifying projects that should be terminated early, how to allow good managers to make mistakes without public embarrassment, and how they all can learn from their mistakes.

Give Olaf a plan of action for the future that attacks the problem. Be specific and provide examples that relate to Wireless Telecom Company.

8/12/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/50!/4/304/2@0:68.0 39/39

Page 537

PRINTED BY: [email protected]. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without publisher's prior permission. Violators will be prosecuted.

Epilogue

With Chapter 14 the project life cycle is complete. You have been exposed to the core elements of project management. We have consciously tried to incorporate a blend of socialcultural and process practices required to successfully manage any project. These best practices are transferable across industries. Your understanding of these chapters should enhance your ability to make a positive contribution in any project environment.

The supplemental chapters that follow expand on the core by covering international project management, oversight, and Agile methods.

Chapter 15. Explores different international environments in which you may have to manage a project. In large high technology firms we estimate that 60–90 percent of their projects are virtual and across many cultures. If you find yourself new in this environment, the international chapter is an excellent primer on the types of conditions and issues you may encounter in an international project. Chapter 16. Oversight of managing projects is growing and evolving. Depending on the degree of oversight, oversight will set the operating environment in which you manage your project. Chapter 17. Agile methodology is used in complex projects (e.g., software and new innovation products) where the final design requirements are not known and evolve as the project is implemented. The methodology breaks requirements into small functional pieces that allow rapid response to change. Agile embraces flexibility, change, small teams, and owner involvement.

Familiarity and understanding these different operating environments should give you confidence to enter and manage your project. We encourage you to read these chapters to increase your overall understanding of project management.

Chapter 18 presents thoughts on career paths. You may find them useful as you consider your future.