12

Project Implementation, Closure

and Evaluation

CHAPTER OVERVIEW
In this chapter, we will focus on three important areas: project implementation, closure,
and evaluation. After studying this chapter, you should understand and be able to:
• Describe the three tactical approaches to information system implementation
and installation: (1) direct cutover, (2) parallel, and (3) phased, as well as com
pare the advantages and disadvantages of each approach.
• Describe the processes associated with project closure to ensure that the project
is closed in an orderly manner.
• Identify the four different project evaluations or reviews: (1) individual per
formance review, (2) postmortem review, (3) project audit, and (4) evaluation of
the project's MOV.

GLOBAL TECHNOLOGY SOLUTIONS

The party was winding down as Tim Williams and Kellie Matthews sat alone at a
table and watched the band pack up its instruments and sound system. It was getting
late and only a few other GTS employees and their guests remained. The company
had rented a stylish banquet room in a local hotel to mark the conclusion of the Husky
Air project. The event allowed Tim and Kellie the opportunity to formally recognize
and thank each member of the team for the hard work over the last several months.
During a ceremony before dinner, Tim gave each member of the project team a small
gift to commemorate Global Technology Solutions' first successful project. In addi-
tion, several humorous certificates were given out to keep the occasion fun and lively.
The dinner and the band were excellent, and everyone had a great time.
As Tim and Kellie sat at the table, Kellie raised her glass in the air, "Well, here's to
the first of many successful projects."
Tim raised his glass as well, "And here's to a great party."
279
280 CHAPTER 12 / PROJECT IMPLEMENTATION, CLOSURE, AND EVALUATION

GTS was growing. The company had successfully completed its first project and
now two new projects were scheduled to start in a few weeks. Moreover, one of the
Husky Air team members, Van, had been promoted to project manager for one of the
upcoming projects. To support this growth, three new employees had been hired and
were scheduled to start the next week.
The glasses clinked, then both Kellie and Tim sipped from their glasses. "It was a
lot of work, but a lot of fun," reflected Tim.
Kellie smiled, "Don't forget we still have a few things to wrap up before it's
really over. I have to meet with each member of the team next week to make sure that all
of the project documents and deliverables are organized and archived. You'll be pretty
busy finishing up each team member's evaluation. Then there are these two new
projects that we have to start thinking about. And, don't forget, we still have to meet
with Husky Air's management in a couple of weeks to assess how well the project met
its MOV."
"Okay, okay!" laughed Tim. "I didn't want to turn this into a business meeting.
For once, let's leave work at the office."
"You're right," laughed Kellie. "Let's leave it at the office. However, I think our
little party was a success. We may have even started a new tradition for GTS."
Tim smiled, "I could get used to this. It was kind of stressful at times, especially
towards the end, but completing the project and having this party has helped everyone
feel good about themselves and the work they did."
By this time the band carried away the last amplifier, and one could sense that the
wait staff wanted to clear the last of the remaining tables and go home. It was clearly
time to leave. Kellie and Tim stood and started walking towards the door. As they put
their coats on, Kellie turned to Tim and gave him a quick hug. "It has been a real pleasure
starting this company and working so closely with you," she said. "No one in our
family would have thought when we were kids that we'd work this well together."
Tim returned the hug. "I never thought that I'd ever get along with my sister this
well either."
As they headed toward the elevator, Kellie reminded Tim, "Don't forget about
dinner at Mom and Dad's house tomorrow night. Mom expects us around six, so don't
be late again."
Tim shook his head as the elevator door opened. "Geez, do you always have to
act like my older sister?"

Things to Think About:

1. What is the purpose of bringing closure to a project?
2. Why is it important to evaluate the project and the team's performance?
3. Why should the project's MOV be evaluated some time after the project is
implemented and some time has passed?

INTRODUCTION
The topic of change management was introduced in the previous chapter and focused
on preparing the people within the organization for the upcoming change and, more
importantly, the transition that will occur as a result of the change. Understanding the
human element or the "soft side" of IT project management is critical for ensuring
that the individuals or groups within the organization will accept and adapt to the new
information system implemented by the project team.
 PROJECT IMPLEMENTATION 281

In this final chapter we will concentrate on three important areas—project imple-

mentation, closure, and evaluation. Project implementation focuses on installing or
delivering the project's major deliverable in the organization—the information sys-
tem that was built or purchased. The implementation of the information system
requires a tactical plan that allows the project team to move the IT solution from a
development and test environment to the day-to-day operations of the organization.
In general, implementing the product of an IT project can follow one of three
approaches. These approaches are (1) direct cutover, (2) parallel, or (3) phased. Each
approach has unique advantages and disadvantages that make a particular approach
appropriate for a given situation. Subsequently, understanding and choosing an appro-
priate approach can have a profound impact on the success or failure of the project.
As discussed in Chapter 1, a project is a temporary endeavor undertaken to
accomplish a unique purpose. This means that a project has a definite beginning and a
definite end. Once the information system is implemented, the project manager and
team must prepare for terminating, or closing, the project. Closing a project includes
organizing and archiving project documents and deliverables, performing an audit
and assessment of the project, documenting lessons learned, evaluating the perform-
ance of the project manager and team, releasing project resources, and closing all
project-related accounts.
For a project to be closed successfully, the product of the project must be formally
accepted by the project sponsor or customer. Not all projects, of course, are successful;
however, a number of administrative tasks must still be completed. In such cases, it is
necessary to assess whether any salvage value exists, and, more importantly, to
understand the nature and reasons why the project was not successful.
Once the project is closed, the project manager should evaluate each project team
member individually in order to assess and provide feedback to the individual about
his or her performance on the project. In addition, the project manager and project
team should meet to conduct a postmortem review of the project. The outcome of this
review should be a set of documented lessons learned and best practices that can be
shared throughout the organization.
In addition, the project should be reviewed by an impartial outside party. An audit or
outside review can provide valuable insight on how well the project was managed and
on how well the project members functioned as a team. The auditor or audit team should
also determine whether the project manager and team acted professionally and ethically.
The project's real success will be determined by the project sponsor or customer. In
this text, the project's overall goal was defined as the MOV, or measurable organi-
zational value. The MOV must be clearly defined and agreed upon in the early stages of
the project. Unfortunately, the project's true value to the organization may not be
discernable immediately following implementation. It may take weeks or even
months after the information system is implemented, but an evaluation must be made to
determine whether the project was successful, as defined by its MOV.
The remainder of this chapter has three sections. In the next section, we will look at
three approaches for implementation. This section will be followed by one that
describes the processes required to formally close a process. Finally, the last section
will look at evaluating the project team and the project as a whole.

PROJECT IMPLEMENTATION
At some point, testing is complete and the project team and project manager then
become responsible for ensuring that the information system is transferred successfully
282 CHAPTER 12 / PROJECT IMPLEMENTATION, CLOSURE, AND EVALUATION

ERP IMPLEMENTATION IN 10 EASY STEPS?

1. Ask the board of directors for an arbitrary but large 5. Give the other half of the money to the consultants.
sum of money ($300 million should suffice). 6. Install the software.
2. Give half of the money to consultants. Ask them to 7. Train end users repeatedly.
select an appropriate ERP package for your com
pany. Consultants will audit your business 8. Cross your fingers.
processes for six months and then select SAP, 9. Turn on the software.
which they happen to sell. 10. If you're still in business, immediately return to
3. Form cross-functional implementation teams. Hold Step 1 because it's time for an upgrade.
meetings.
SOURCE: From Derek Slater, ERP Implementation in 10 Easy Steps,
4. Reengineer all your business processes to match the CIO.COM, April 1, 2001, http://www.cio.com/archive/040101
software model. /tl_erp.html.

from the development and test environment to the operational environment of the spon-
sor or customer's organization. This transfer requires a tactical approach, and it can be a
stressful time for all the stakeholders involved. Choosing an inappropriate implemen-
tation approach can negatively impact the project's remaining schedule and budget. In
general, the project team can take one of three approaches for implementing the infor-
mation system. These approaches include (1) direct cutover, (2) parallel, and (3) phased.

Direct Cutover
The direct cutover approach, as illustrated in Figure 12.1, is an approach where the
old system is shut down and the new system is turned on. In general, a target, or go
live, date is agreed upon, and the new system simply replaces the old.
This approach can be effective when quick delivery of the new system is critical
or when the existing system is so poor that it must be replaced as soon as possible.
Direct cutover may also be appropriate when the system is not mission critical—i.e.,
the system's failure will not have a major impact on the organization. It is important,
however, that the new system be thoroughly tested so everyone is confident that few, if
any, major problems will arise.
Although there are some advantages to using the direct
cutover approach, there are also a number of risks involved that
generally make this the least favored approach except in a few,
carefully planned situations. Although the direct cutover approach
can be quick, it may not always be painless. You might think of this
approach as walking a tightrope without a safety net. You may get
from one end of the tightrope to other quickly, but not without a
great deal of risk. Subsequently, there may be no going back once
the old system is turned off and the new system is turned on. As a
result, the organization could experience major delays, frustrated
users and customers, lost revenues, and missed deadlines. The
pressure of ensuring that everything is right or having to deal with
problems and irate users or project stakeholders can create a great
deal of stress for the project team.
Figure 12.1 Direct Cutover
 PROJECT IMPLEMENTATION 283

Parallel

As Figure 12.2 illustrates, the parallel approach to implementation allows the old and
the new systems to run concurrently for a time. At some point, the organization
switches entirely from the old system to the new.
The parallel approach is appropriate when problems or the failure of the system
can have a major impact on the organization. For example, an organization may be
implementing a new accounts receivable package. Before switching over completely
to the new system, the organization may run both systems concurrently in order to
compare the outputs of both systems. This approach provides confidence that the new
system is functioning and performing properly before relying on it entirely.
Although the parallel approach may not be as stressful for the project team as the
direct cutover approach, it can create more stress for the users of the system. The
users will probably have to enter data into both systems and even be responsible for
comparing the outputs. If the new system performs as expected, they may be willing
to put up with the extra workload until the scheduled target date when the new
system stands alone. If, however, unexpected problems are encountered, the target
date for switching from the old to the new system may be pushed back. The extra
workload and overtime hours may begin to take their toll and pressure for the
project team to "get on with it" may create a stressful environment for everyone
involved.

Phased
Following the phased approach, the system is introduced in modules
or in different parts of the organization incrementally as illustrated in
Figure 12.3. For example, an organization may implement an
accounting information system package by first implementing the
general ledger component, then accounts payable and accounts
receivable, and finally payroll.
The phased approach may be appropriate when introducing a software
system to different areas of the organization. When upgrading an
operating system, for example, the IT department may perform the
upgrade on a department-by-department basis according to a published
schedule. In this case, a target date for each department would be set to
allow each department to plan for the upgrade
accordingly. A phased approach may also allow the
project team to learn from its experiences during the
initial implementation so that later implementations
run more smoothly.
Although the phased approach may take more
time than the direct cutover approach, it may be less
risky and much more manageable. Also, overly
optimistic target dates or problems experienced
during the early phases of implementation may
create a chain reaction that pushes back the
scheduled dates of the remaining planned
implementations.
Table 12.1 provides a summary of each of the three
implementation approaches discussed.
284 CHAPTER 12 / PROJECT IMPLEMENTATION, CLOSURE, AND EVALUATION

IMPLEMENTATION PROBLEMS CONTRIBUTE TO FEDEX PILOT'S STRIKE

A new scheduling system at Federal Express got its pilots was turned on. Moreover, TWA engaged representatives
so riled up that it may have been a major reason for them to from the pilots' union from the beginning and performed
go on strike. Although the packaged software was parallel testing as well. The problem at FedEx, however,
installed successfully at several other airlines, the problem was that the system utilized a flight schedule optimizer that
appears to have been the up-front planning process. Tony could string together the most efficient routes and schedules
Hauserman, communications chairman for the that would allow the pilots to get out of and then back into
3,200-mem-ber Pilot Associate Union, said, "The their home airport. Unfortunately, the FedEx pilots were
system was extremely disruptive, we weren't consulted caught off guard because the past union contracts were
before it was implemented and they said they'd run parallel not written with strict enough rules about layovers, route
tests on it before it went live—but they didn't." In fact, the preferences, and time away from home. As a result,
poorly implemented system has helped to bring the union high-tech software can make negotiations between
members closer together as the company and union were in employees and their companies more complex.
the midst of contract negotiations. A spokesperson for
FedEx explained that the system didn't "roll out the way SOURCE: Adapted from Stewart Deck, System Implementation may
we wanted to," but added that the company was addressing Contribute to Pilots' Strike at FedEx, Computerworld, October 26,
the problems pointed out by the pilots. Interestingly, TWA 1998, http://www.computerworld.eom/news/1998/story/0,11280,
uses the same system but tested the system for a year 33157,00.html.
before it

Table 12.1 Comparison of Implementation Approaches

Direct Cutover Parallel Phased

• Implementation • Provides a safety net or backup in case • Allows for an organized and managed
can be quick problems are encountered with the approach for implementing system
• Can be risky if implementation of the new system modules or a system/upgrades in different
system is not fully • Can increase confidence in the new departments or geographical locations
tested system when output of old system and • Experience with early implementation can
• Places more new system is compared guide and make later implementations go
pressure on the • Takes longer and may cost more than more smoothly
project team direct cutover approach • Takes longer and may cost more than the
• Places more pressure on the users of direct cutover approach
the system • Problems encountered during early phases
can impact the overall implementation
schedule

As the end of the project draws near, everyone may become anxious to finish the
project and move onto other things. Unfortunately, there is often a great deal of work
that still needs to be completed. Delays or unanticipated problems may require addi-
tional time and unbudgeted resources, leading to cost and schedule overruns or extra
unpaid effort, especially if an implied warranty exists (Rosenau 1998).
During the final stages of the project, the project team may be faced with both
time and performance pressures as the project's deadline looms in the near future. On
the other hand, the sponsor or client may become more concerned about whether the
time and money spent on the project will reap the envisioned benefits. The project
manager is often caught in the middle attempting to keep the project team happy and
on track, while assuring the project sponsor that all is well.
 ADMINISTRATIVE CLOSURE 285

ADMINISTRATIVE CLOSURE
Although all projects must come to an end, a project can be terminated for any number
of reasons. Gray and Larson (2000) define five circumstances for ending a project:
normal, premature, perpetual, failed, and changed priorities.
• Normal—A project that ends normally is one that is completed as planned.
The project scope is achieved within the cost, quality, and schedule objectives,
although there probably was some variation and modification along the way.
The project is transferred to the project sponsor, and the end of the project is
marked with a celebration, awards, and recognition for a good job well done
by those involved. As you might suspect, this is an ideal situation.
• Premature—Occasionally, a project team may be pushed to complete a
project early even though the system may not include all of the envisioned
features or functionality. For example, an organization may need to have a
new system operational—with only a core set of original requirements— to
respond to a competitor's actions, to enter a new market early, or as a result
of a legal or governmental requirement. Although there is pressure to finish
the project early, the risks of this decision should be carefully thought
through by all the project stakeholders.
• Perpetual—Some projects seem to take on a "life of their own" and are
known as runaway, or perpetual, projects. These projects never seem to end.
Perpetual projects may result from delays or a scope or MOV that was never
clearly defined or agreed upon. Then, the project sponsor (or even the team)
may attempt to add on various features or functionality to the system, which
results in added time and resources that increase the project schedule and
drain the project budget. Some runaway projects result from an organization
not making the appropriate decision to "pull the plug" on an unsuccessful
project. The decision to terminate a project is not an easy one if egos and per
haps even careers or jobs are on the line. This phenomenon may also occur
when the project has a high payoff to the organization and when admitting to
failure is strongly against the corporate culture (Keil 1995). No matter what
the cause, project resources are eventually drained to a point where a poten
tially successful project becomes unsuccessful (Nicholas 1990). Attention to
defining and agreeing to the project's MOV, the project scope processes, and
timely project reviews can reduce the risk of perpetual projects.
• Failed—Sometimes projects are just unsuccessful. In general, an IT project
fails if insufficient attention is paid to the people, processes, or technology.
Even though the project's MOV may define the project's value to the
organization, cost and schedule overruns may drain the project's value to a
point where the costs of completing the project outweigh the benefits.
• Changed Priority—In some circumstances, a project may be terminated as a
result of a change in priorities. Financial or economic reasons may dictate
that resources are no longer available to the project. Or, management may
decide to divert resources to higher priority projects. This change can happen
when the original importance or value of the project was misjudged or mis
represented or when organizational needs or technology change over the
course of a long-term project. Some projects are "terminated by starvation."
As Meredith and Mantel (2000) describe it, successive budget cuts over time
can slowly starve a project budget to the point where it is ended but the ter
mination is masked. Senior management may not want to admit that it had
286 CHAPTER 12 / PROJECT IMPLEMENTATION, CLOSURE, AND EVALUATION

KNOW WHEN TO SAY WHEN

Identifying the lost-cause IT project is not an easy task. possible if terminating the project means letting people
Constant attention to project metrics and an intuitive go. The next step, according to Kapur, is to inform all the
understanding of the business are required. But, once a key people associated with the doomed project, especially
lost-cause project is identified, it is important for the the project champion and the project manager, before a
organization to shut it down quickly and efficiently. public announcement is made. Afterwards, the project
Terminating a project should be an option at each stage or team should try to salvage as much work as possible. For
phase of the project. For example, Petrotin, a former sub- example, code and testing methodologies may be saved. It
sidiary of Texaco, has about twenty-five IT projects is also helpful to debrief the team and have new assign-
underway that it scrutinizes closely. In the last two years, ments ready for them. Robert Wourms, an IT consultant,
the company shut down two projects for different reasons. suggests that a report about the failed project should be
Pulling the plug on these projects before implementation written to document the lessons learned from both a busi-
saved the company money and the IT department's credi- ness and technology perspective. IT mangers should also
bility. Raj Kapur, vice president of the Center for Project be trained on how to detect a failing project as early as
Management in San Ramon, CA, believes that once the possible. Often project managers take their projects to
decision to kill a project is made, the next set of steps is heart and want to see them through to the end. But, it is
critical. The company should first put together a cancella- better that the IT manager be able to make the call before
tion plan that carefully considers all of the project stake- the CFO tells him or her to kill the project.
holders and budget implications. For instance, there may
be legal ramifications if the project involves contracts SOURCE : Adapted from Mark Hall, Dead in Its Tracks,
with vendors, suppliers, or even customers. The human Computerworld, March 18, 2002, http://www.computerworld.com
resources department should also be consulted as soon as /managementtopics/management/story/0,10801,69115,00.html.

championed a failed project or that a project will be unsuccessful in meeting its

goals. The project budget receives a large cut or a series of smaller cuts. The
result is that the project will eventually die and the project resources will be
reassigned, even though the project is never officially closed.
Ideally, a project is closed or terminated under normal circumstances. The project
achieves its desired goal and objectives. The project sponsor is delighted with the
project's product and shows his or her delight by paying for the invoiced project work
on time and contracts for more work in the future. Unfortunately, closing a project
does not often happen this way. As J. Davidson Frame (1998) points out, the project
manager and team should be prepared to deal with the following realities:
• Team members are concerned about future jobs. Often the members of the
project team are borrowed from different departments or functional areas of
the organization. Once the project is finished, they will return to their previous
jobs. For consulting firms, the project team members will move from one
project to the next as part of their career path. Regardless, as the project nears
its end, these project team members may begin to wonder what they will do
next. For some, there will be a rewarding life after the project—for others it
may mean looking for new jobs. For many it may mean disrupting a
close-knit relationship with other members of the project team (Meredith and
Mantel 2000). Therefore, project team members may become preoccupied
with moving on with their lives and the project at hand may become a lesser
priority. As a result, the project team members may not focus on what has to
be done to close the project, and wrapping up the project may be a challenge.
 ADMINISTRATIVE CLOSURE 287

• Bugs still exist. Testing the information system is an important process of

systems development. However, software quality testing may not find all
the defects, and certain bugs may not become known until after the system
has been implemented. The appearance of these problems can be frustrating
and stressful to all the project stakeholders. Unless these defects and bugs
are promptly addressed and fixed, the project sponsor's satisfaction with
the project team and the information system may become an issue.
• Resources are running out. Resources and the project schedule are con
sumed from the project's earliest inception. At the end of the project, both
resources and time remaining are usually depleted. As unanticipated issues,
problems, or challenges arise, the project manager may find that adequate
resources to deal with these events effectively are not available. The project
manager may find his or her situation aggravated if management decides to
cut or control the project's budget.
• Documentation attains paramount importance. Information technology proj
ects have numerous documentation requirements. They require project, sys
tem, training, and user documentation. Under ideal circumstances, the time to
write documentation is built into the project plan and completed throughout
the project. Many times, however, documentation is put off until the end of the
project. As the end draws near, documentation becomes increasingly impor
tant. As a result, documentation may require more time and resources to com
plete, or shortcuts are taken to remain within the current project constraints.
• Promised delivery dates may not be met. Most projects experience schedule
slippage. This slippage may be due to poor project management, implemen
tation risks, competitive requirements, or overly optimistic estimates. A
project will require a certain amount of resources and a certain amount of
time to complete. Any misjudgment concerning what has to be done, what
is needed to complete the job, and how long it will take will result in a
variance between the planned and actual schedule and budget.
• The players may possess a sense of panic. As schedules begin to slip and proj
ect resources become depleted, various project stakeholders may experience a
sense of alarm. The mangers or partners of a consulting firm may worry that
the project will not be profitable or satisfactory to the customer. The sponsor
or customer may worry that the information system will not be delivered on
time and within budget or provide the expected value to the organization.
Moreover, the project manager and team may also be worried that the project
will not be successful and the blame will rest squarely on their shoulders. As
the sense of panic increases, the chances for an orderly closeout grow dim.
Regardless of whether a project ends normally or prematurely, it is important that
an orderly set of processes be followed in order to bring it to closure. A good close-out
allows the team to wrap up the project in a neat, logical manner. From an admin-
istrative view, this procedure allows for all loose ends to be tied up. From a
psychological perspective, it provides all of the project stakeholders with a sense that
the project was under control from the beginning through to its end (Frame 1998).

Project Sponsor Acceptance

The most important requirement for closure under normal circumstances is obtaining
the project sponsor's acceptance of the project. Delivery, installation, and
288 CHAPTER 12 / PROJECT IMPLEMENTATION, CLOSURE, AND EVALUATION

implementation of the information system do not necessarily mean that the project
sponsor or client will accept the project's product. Since acceptance depends heavily
on the fulfillment of the project's scope, the project manager becomes responsible for
demonstrating that all project deliverables have been completed according to
specifications (Wysocki, Beck et al. 1995). Ancillary items, such as documentation,
training, and ongoing support, should not be afterthoughts. These items should have
been included in the original scope of the project. Any attempt to renegotiate what is
and what is not part of the project work at this late stage of the project can create ill
feelings or hold up payment by the client (Rosenau 1998).
Rosenau (1998) observes that there are two basic types of project sponsors.
Shortsighted sponsors tend to view the project as a short-term buyer-seller relationship
in which getting the most for their money is the most important criteria for accepting
the project. This view often leads to an adversarial relationship if the sponsor attempts
to renegotiate the project scope or price at the end of the project.
Knowledgeable sponsors realize that they have an important stake in the outcome
of the project. As a result, they will be actively involved throughout the project in a
constructive manner. As Rosenau points out, knowledgeable sponsors may ask tough
questions during project reviews, but their objective is not to embarrass the project
team or manager, but to ensure the success of the project. Instead of an adversary trying
to get the most in a "win-lose" situation, the knowledgeable sponsor will negotiate
intelligently and in good faith.
Regardless of whether the sponsor is short-sighted or knowledgeable, the project
manager and team can improve the likelihood that the project will be accepted if they
(1) clearly define the acceptance criteria for the project at the early stages of the project,
and (2) document the completion of all project deliverables and milestones.
A clear definition of the project deliverables is an important concern for project
scope management (discussed in an earlier chapter). Yet, defining and verifying that
the project scope and system requirements are accurate and complete is only one com-
ponent. Having scope change procedures in place that are understood by all the project
stakeholders also ensures that everyone has the same expectations concerning what
will and what won't be delivered at the end of the project.
The IT project methodology incorporated in this text also focused on managing
the project based on phases that focus on specific deliverables. Project milestones
ensure that the deliverables are not only complete, but completed right. Documenting
each deliverable and milestone throughout the project provides confidence to the
project sponsor that the project has been completed fully.

The Final Project Report

In general, the project manager and team should develop a final report and presentation
for the project sponsor and other key stakeholders. The objective of the report and
presentation should be to give the project sponsor confidence that the project has been
completed as outlined in the business case, project charter, and project plan. By gaining
this confidence, the sponsor or client will be more likely to formally accept the project
that will allow for a smooth termination of the project.
The report may be circulated to key stakeholders before the presentation in order
to get feedback and to identify any open or unfinished items that need to be scheduled
for completion (Rosenau 1998; Buttrick 2000). Once finalized, the final project report
provides a background and history of the project. The report should include and dis-
cuss the following areas at a minimum:
 ADMINISTRATIVE CLOSURE 289

• Project Summary
« Project Description
« Project MOV
'-« Scope, Schedule, Budget, and Quality Objectives
• Comparison of Planned versus Actual
1
Original Scope and history of any approved changes Original
scheduled deadline versus actual completion date Original budget
versus actual cost of completing the project *> Test plans and test
results
• Outstanding Issues
» Itemized list and expected completion
» Any ongoing support required and duration
• Project Documentation List
» Systems Documentation
« User Manuals
* Training Materials
• Maintenance Documentation

The Final Meeting and Presentation

If the project manager has been diligent in gaining the confidence of the project spon-
sor, the final meeting and presentation should be a simple, straightforward affair.
Buttrick (2000) suggests that the final meeting is useful for:
• Communicating that the project is over. By inviting key stakeholders to the
meeting, the project manager is formally announcing that the project is
over. This action not only provides a sense of closure for those close to the
project, but also for the organization, as well.
• Transferring the information system from the project team to the organization,
Although the information system may have been implemented and is being
used by the organization, the final meeting provides a formal exchange of the
project's product from the project team to the organization. Unless some type
of ongoing support is part of the contractual agreement, this transfer signals
that the project team will not be at the client or sponsor's site much longer.
• Acknowledging contributions. The meeting provides a forum for the project
manager to acknowledge the hard work and contributions of the project
team and other key stakeholders.
• Getting formal signoff. Finally, the meeting can provide a ceremony for the
sponsor or client to formally accept the information system by signing off
on the project. A space for signatures could be part of the final project
report or part of some other contractual document.

Closing the Project

Once the project is accepted by the sponsor or customer, a number of administrative
closure processes remain. These last items can be difficult because the project manager
290 CHAPTER 12 / PROJECT IMPLEMENTATION, CLOSURE, AND EVALUATION

or team may view these administrative items as boring or because they are already
looking forward to and thinking about their next assignment (Gray and Larson 2000).
Unfortunately, administrative closure is a necessity because once the project manager
and team are officially released from the current project, getting them to wrap up the
last of the details will be difficult. The requirements for administrative closure include:
1. Verifying that all deliverables and open items are complete.
2. Verifying the project sponsor or customer's formal acceptance of the project.
3. Organizing and archiving all project deliverables and documentation.
4. Planning for the release of all project resources (i.e., project team members,
technology, equipment, facilities, etc.).
5. Planning for the evaluations and reviews of the project team members and
the project itself.
6. Closing of all project accounts.
7. Planning a celebration to mark the end of a (successful) project.

PROJECT EVALUATION
The question on everyone's mind throughout the project is, Will this project be suc-
cessful? However, different stakeholders will have different views of success. For the
project team members, it may be gaining valuable experience and feeling that their
work will have a positive impact on the organization. For the project manager, it may be
leading a project that will be profitable to the firm or a promotion to a larger and more
visible project. On the other hand, the client or sponsor may view project success in
terms of organizational value received after the project is implemented.
Therefore, four types of project evaluations should be conducted. There should
be (1) an individual review of each team member's performance, (2) a postmortem
review by the project manager and project team, (3) an audit of the project by an
objective and respected outside party, and (4) an evaluation sometime after the project
is implemented to determine whether the project achieved its envisioned MOV.

Individual Performance Review

The project manager should conduct an individual performance review with each
project team member. Although the project organization may have its own process
and procedure for conducting reviews, the project manager should focus on the fol-
lowing points:
• Begin with the individual evaluating his/her performance. Evaluating
someone's performance can be an emotional experience. Even with the best
intentions, being critical of someone can put her or him on the defensive.
Instead of beginning an evaluation with a critique of the individual's per-
formance, it is usually more effective to begin by asking how that person
would evaluate her or his performance. Surprisingly, most people are more
critical of themselves. This opening provides an opportunity for the person
doing the evaluation either to agree or to disagree with the individual's
self-evaluation and to point out several positive aspects of the person's
performance. This system creates a useful dialog that provides the individual
with more useful feedback.
 PROJECT EVALUATION 291

• Avoid "why can'tyou be more like....?" It is easy to compare individuals.

Unfortunately, comparisons can have a counter effect. First, the person
that you exalt may not be the shining star you think they are. Second, oth
ers may become jealous and look for ways to discredit or disparage the
individual. Keep in mind that people are different and should be evalu
ated as individuals.
• Focus on specific behaviors, not the individual. When discussing opportu
nities for improvement with a person, it is important to focus on specific
behaviors. For example, if a project team member has a habit of consis
tently showing up late and disrupting team meetings, it is important not to
focus on the individual (i.e., why are you so lazy and disrespectful?), but
on how showing up late to team meetings is disruptive. Often people do not
realize how their behaviors affect others.
• Be consistent and fair. Being consistent and fair to everyone is easier said
than done. The person conducting the evaluation should be aware of how
decisions concerning one person may affect the entire group. Also, be
aware that people talk to one another and often compare notes. Therefore,
making a decision concerning one person may set a precedent for others.
Having policies and procedures in place and sticking to them can mitigate
the potential for inconsistency and the perception that that the evaluator is
not fair with everyone.
• Reviews should provide a consensus on improving performance. The pur
pose of conducting a review or evaluation with each project team member
is to provide constructive feedback for individuals. No one is perfect, so
understanding where an individual can improve and how they might go
about improving is important. The individual and the evaluator should
agree on what areas the individual needs to improve upon and how the
organization can support this endeavor. For example, the individual and the
evaluator may agree that the team member should improve his or her com
munication skills. The evaluator may then recommend and provide support
for the person to attend a particular training class.
The meeting can serve to help prepare the individual to move on and accept the
psychological fact that the project will end (Gray and Larson 2000). And, in most
cases, the project manager could use this meeting to discuss the project team member's
next assignment.

Postmortem Review
Shortly after the final project report and presentation are completed, the project man-
ager and project team should conduct a postmortem review of the project. This should
be done before the project team is released from the current project. It is more difficult
to get people to participate once they are busy working on other projects or if they no
longer work for the project organization. Moreover, memories tend to become clouded
as time passes. Thoroughness and clarity are critical (Nicholas 1990). The formal
project summary report should focus on the project's MOV and the project
management knowledge areas. The focus of this review should include the following:
• Review the initial project's MOV. Was the project's MOV clearly defined and
agreed upon? Did it change over the course of the project? What is the
probability that it will be achieved?
292 CHAPTER 12 / PROJECT IMPLEMENTATION, CLOSURE, AND EVALUATION

• Review the project scope, schedule, budget, and quality objectives. How
well was the scope defined? Did it change? How effective were the scope
management processes? How close were the project schedule and budget
estimates to the actual deadline and cost of the project? Were the quality
objectives met? How well did the quality management processes and stan
dards support the project processes?
• Review each of the project deliverables. How effective were the business
case, the project charter, the project plan, and so forth? How could these
deliverables be improved?
• Review the various project plans and Project Management Body of
Knowledge (PMBOK) areas. The team should review its effectiveness in
the following areas:
• project integration management
» project scope management
« project time management
« project cost management
« project quality management
• project human resources management
• project communications management
• project risk management
« project procurement management »
organizational change management «
project implementation
• How well did the project team perform? Were conflicts handled effectively?
Did the team suffer any morale problems? What main challenges did the
team face? How well did they handle these challenges? How well did the
members function as a cohesive team?
The discussion and recommendations from the postmortem review should be
documented. In particular, the project manager and team should identify what they
did right and what they could have done better. These lessons learned should be
documented so that they can be shared with others in the organization. Moreover,
best practices should be identified and become part of the organization's IT project
methodology.

Project Audit
The individual performance and postmortem reviews provide an important view of
the internal workings of the project. In general, these reviews are conducted
between the project manager and the project team. To provide a more objective
view of the project, an audit or review by an outside party may be beneficial for
uncovering problems, issues, or opportunities for improvement. Similar to the
postmortem review, the auditor or audit team should focus on how well the project
was managed and executed. This may include the project plans and Project
Management Body of Knowledge areas described in the previous section, as well as
the underlying project management and systems development processes outlined
in the organization's IT project methodology. In addition, the auditor or audit
 PROJECT EVALUATION 293

team should assess whether the project manager and team acted in a professional
and ethical manner.
As Gray and Larson (2000) suggest, the depth of the audit depends on the orga-
nization's size, the importance and size of the project, the risks involved, and the
problems encountered. The audit may involve the project manager and the project
team, as well as the project sponsor and other key project stakeholders. In addition,
the third party auditor or audit team should:
• Have no direct involvement or interest in project.
• Be respected and viewed as impartial and fair.
• Be willing to listen.
• Present no fear of recrimination from special interests.
• Act in the organization's best interest.
• Have broad base of project and/or industry experience.
The findings or results of the project audit should be documented, as well as any
lessons learned and best practices.

Evaluating Project Success—The MOV

The MOV, or measurable organization value, was defined at the beginning of the proj-
ect. It provided the basis for taking on the project and supported many of the decision
points throughout the project life cycle. Often, the MOV cannot be readily determined
at the close of the project. Many of the benefits envisioned by the implemented system
may require weeks or even months before they are realized.
Although the different project stakeholders and players may have different views
as to whether the project was a success, it is important to assess the value that the project
provides the organization. This review may be conducted by several people from both
the project sponsor or client's organization and the organization or area responsible for
carrying out the project. In particular, this review should focus on answering and
documenting the following questions:
• Did the project achieve its MOV?
• Was the sponsor/customer satisfied?
• Was the project managed well?
• Did the project manager and team act in a professional and ethical manner?
• What was done right?
• What can be done better next time?
Before conducting this evaluation, the consulting firm or individuals representing
the project should be sure that the information system delivered has not been changed.
Often when an information system is handed over to the project sponsor, the users or
support staff may make changes. It is not uncommon for these changes to have unin-
tended adverse affects. Care should be taken to ensure that the system being evaluated
is the system that was delivered (Nicholas 1990).
The evaluation of the project's MOV may be intimidating—it can be the moment
of truth as to whether the project was really a success. However, a successful IT project
that brings measurable value to an organization provides a foundation for organi-
zational success.
294 CHAPTER 12 / PROJECT IMPLEMENTATION, CLOSURE, AND EVALUATION

CHAPTER SUMMARY
This chapter provides closure for both this text and for unsuccessfully. Ideally, the project is closed under nor-
managing an IT project. Throughout the project life mal conditions—that is, the project scope is completed
cycle, processes to support both the project and develop- within reasonable modifications to the original schedule,
ment of the project's product—the information sys- budget, and quality objectives. Delivery or installation of
tem—have been discussed. These processes are the information system does not necessarily mean that
important for managing the project from its inception the project's sponsor or customer will accept the project.
right through to its conclusion. Therefore, closure must focus on providing both proof
Once the information system has been built or pur- and confidence that the project team has delivered every-
chased, it must be adequately tested in order to make thing according to the original business case, project
installation of the system go more smoothly. However, charter, and project plan.
implementation requires a tactical approach for ensuring A useful way to gain acceptance is the development
that the information system is transferred efficiently and of a final project report. This report provides a history of
effectively from the project environment to the day-to- the project and outlines how each deliverable was com-
day operations of the organization. pleted and meets the standards of the client or sponsor.
Three approaches to implementation were dis- The report should also address any open items or issues so
cussed in this chapter. The first approach, called direct that they can be completed within a reasonable time. This
cutover, provides the quickest means for implementing report can serve as a foundation for the project team's final
the system. In general, the old system is turned off and meeting with and presentation to the key stakeholders of
the new system is turned on. This approach can be risky the project. This meeting not only provides closure for the
if the system has not been thoroughly tested. As a result, it project, but also serves as a communication tool for
can put a great deal of pressure on the project team to informing the stakeholders that the project has been for-
"get it right" the first time, especially if the system sup- mally accepted and, therefore, is coming to an end.
ports a mission critical function of the organization. Several processes for closing a project were dis-
cussed in this chapter. They include closing the project
The parallel and phased approaches are less risky
accounts, releasing or transferring project resources,
alternatives, although implementation may take longer.
documenting lessons learned, and archiving all project
The parallel approach requires that both the old system
documents and deliverables.
and new system run concurrently for a time until there
Before a project is completely terminated, it is
is enough confidence that the new system is working
important that several reviews or evaluations be con-
properly. At some point, a switch is made from the old
ducted. These evaluations include a performance review
system to the new system. The parallel approach can be
between the project manager and each project team mem-
stressful for the users of the system because they may be ber. A postmortem review with the project manager and
required to provide input for both systems and then the entire team should include all of the project deliver-
compare the outputs. ables, project plans, and, in general, the various project
The phased approach may be appropriate when imple- management body of knowledge areas. Lessons learned
menting an upgrade or modular system in different depart- should be documented and best practices identified.
ments or at different geographical locations. Under this The performance reviews and postmortem should
approach, implementation takes place over phases accord- provide preparation for the project audit. In this case, a
ing to a published schedule. Experience gained from early respected and objective third party should review all of the
implementations can make later implementations go more project deliverables and processes to assess how well the
smoothly; on the other hand, any unanticipated problems project was managed. The auditor or audit team should
can create a chain reaction that pushes back the entire also focus on the specific challenges the project manager
implementation schedule. Choosing and implementing the and team faced and how well they addressed these chal-
correct implementation approach can have a significant lenges. The professional and ethical behavior of the proj-
impact on the project schedule and budget. ect manager and project team should be examined, as well.
Once the information system has been implemented, The concept of a project's measurable organization
the project manager and team must plan for an orderly value (MOV) has been a central theme in this text. The
end to the project. Projects can be terminated for a variety MOV provided a basis for deciding whether to invest in
of reasons, but a project must be properly closed, the project and guided many of the project decisions
regardless of whether the project ends successfully or
 EXTEND YOUR KNOWLEDGE 295

throughout the project life cycle. Although different takes place weeks or months after the project is offi-
stakeholders may have different views of project suc- cially closed, an evaluation as to whether the project has
cess, the overall guiding mechanism for determining met its MOV must still be conducted. This evaluation
whether the project was a success is the project's MOV. should involve various key stakeholders. This moment
Unfortunately, the organizational value that a project of truth may make some people anxious, but it provides
provides may not be readily discernable immediately the necessary means for determining whether the project
after the information system is implemented. Even if it has brought any real value to the organization.

| REVIEW QUESTIONS
1. What is implementation? 14. What is the difference between a shortsighted and a
2. Describe the three approaches to implementing an knowledgeable project sponsor? How can making
information system. this distinction help the project manager during
3. What are the advantages and disadvantages of the project closure?
direct cutover approach? 15. What is the purpose of the final project report?
4. What are the advantages and disadvantages of the 16. What is the purpose of the final meeting and pres
parallel approach? entation?
5. What are the advantages and disadvantages of the 17. Describe some of the steps for administrative closure.
phased approach? 18. What is the purpose of the project manager con
6. Describe the various scenarios for project termi ducting a performance review with each member of
nation. the project team?
7. Why might an organization terminate a project pre 19. What is the purpose of conducting a postmortem
maturely? What are the risks? review?
8. What is a perpetual project? Why might an organi 20. What is the purpose of a project audit?
zation be reluctant to terminate a project that many 21. What criteria should be used to choose a project
would consider unsuccessful? auditor or auditing team?
9. Why would senior management cut a project's 22. What is the purpose of evaluating the project's
budget without officially terminating the project? MOV?
10. Why might some project team members be reluc 23. Why would it be difficult to evaluate whether or not
tant to see the end of a project? a project achieved its MOV shortly after the infor
11. Why can the end of a project be stressful for many mation system is implemented?
of the project stakeholders? 24. Why should any lessons learned from project eval
12. Why is the sponsor's acceptance of the project uations be documented?
important to project closure? 25. Why would evaluating whether a project achieved
13. How can the project manager and project team facil its MOV make many project managers and teams
itate the project sponsor's acceptance of the project? anxious? Why should it still be done?

EXTEND YOUR KNOWLEDGE

1. Suppose you are the project manager for a midsized has been excellent. Unfortunately, that CIO left the
consulting firm. You have been leading a team of company two weeks ago to start a blues band. Her
twelve consultants who have been working three replacement has just been hired, and your meeting
months on a six-month project for your firm's with the new CIO this morning did not go well at
largest client. You have managed two projects in the all. The new CIO figuratively shredded a status
past for this client, and both of these projects were report that you had prepared. Moreover, the CIO
successful. In fact, the client has asked that you per- seemed to have little understanding of the technol-
sonally lead the current project. Your relationship ogy being used to develop the system and com-
with the client's Chief Information Officer (CIO) plained that the prototypes of the user interface that
296 CHAPTER 12 / PROJECT IMPLEMENTATION, CLOSURE, AND EVALUATION

your team had developed were "too hard to under- allegations, senior management has asked you to draft a
stand and use." Just before leaving his office, the one-page statement to guide your organization's behavior.
new CIO mentioned that this project was costing How could this code be monitored to ensure that all
way too much money and taking too long to com- employees comply? You may use the World Wide Web
plete. Given the state of the economy, some cuts to (WWW) or any other resources as reference, but be sure to
project's budget and schedule may be forthcoming. cite your references. 3. Using the WWW or any other
a. Given the situation, do you think this project will resources (e.g., you could interview a project manager),
survive? write a summary of a company's experience
b. Terminating this project prematurely would have implementing an Enterprise Resource Planning (ERP)
a major impact on the profitability of your firm. system. Was this implementation successful? Why or
What could you do to save either the project or why not? What were the major challenges? Did the
the long-term relationship with this client? implementation go according to plan? What lessons did
the organization learn from this experience? Be sure to
2. Suppose that a client has complained that your organ-
include your reference(s).
ization has allegedly acted in a manner both unprofes-
sional and unethical. While investigating these

BIBLIOGRAPHY
Buttrick, R. 2000. The Interactive Project Workout. London: Prentice Meredith, J. R. and S. J. Mantel, Jr. 2000. Project Management: A
Hall/Financial Times. Frame, J. D. 1998. Closing Out the Project. Managerial Approach. New York: John Wiley. Nicholas, J. M.
In Project Management 1990. Managing Business and Engineering Projects:
Handbook, edited by J. K. Pinto. San Francisco, Calif.: Jossey- Concepts and Implementation. Upper Saddle River, N.J.: Prentice
Bass: 237-246. Gray, C. F. and E. W. Larson. 2000. Project Hall. Rosenau, M. D. J. 1998. Successful Project Management.
Management: The New York:
Managerial Process. Boston: Irwin McGraw-Hill. Keil, M. 1995. John Wiley. Wysocki, R. K., R. J. Beck, etal. 1995. Effective Project
Pulling the Plug: Software Project Management and Management.
the Problem of Project Escalation. MIS Quarterly (December): New York: John Wiley.
421^47.