Marchewka c12.tex V2 - November 26, 2014 3:30 P.M.

Page 306

C H A P T E R

12
Project Completion

CHAPTER OBJECTIVES
In this chapter, we will focus on three important areas necessary for project completion: project imple-
mentation, closure, and evaluation. After studying this chapter, you should understand and be able to:
▪ Describe the three tactical approaches to product release or system installation, as well as compare
the advantages and disadvantages of each approach:
▪ direct cutover
▪ parallel
▪ phased
▪ Describe the processes associated with project closure to ensure that the project is closed in an
orderly manner.
▪ Identify four different types of project evaluations or reviews that include:
▪ individual performance review
▪ team close-out meeting
▪ project audit
▪ evaluation of the project’s MOV

INTRODUCTION
The topic of change management was introduced in Chapter 11 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 project management
is critical for ensuring that customers embrace the release of a new product or the individuals or groups
within the organization accept a new information system implemented by the project team.
In this final chapter, we will concentrate on project completion. This includes project implementa-
tion, closure, and evaluation. Project implementation focuses on installing or releasing the project’s
major deliverable in the organization—namely, the product or system that was built or installing the
software package purchased. This release or implementation requires a tactical plan that allows the
project team to move the project’s product from a development and test environment to the day-to-day
operations of the organization or in the hands of the customer.
In general, release or installation can follow one of three approaches. These approaches are direct
cutover, parallel, or phased. Each approach has unique advantages and disadvantages that make a
particular approach appropriate for a given situation. Subsequently, understanding and choosing an
appropriate approach can have a profound impact on the success or failure of the project.

306
 Marchewka c12.tex V2 - November 26, 2014 3:30 P.M. Page 307

PRODUCT RELEASE OR SYSTEM IMPLEMENTATION 307

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 product is
released or the system is installed, the project manager and team must prepare for closing the project.
Closing a project includes organizing and archiving project documents and deliverables, performing
an audit and assessment of the project, evaluating the performance 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 stakeholders or customer. Not all projects, of course, are successful; however, a num-
ber 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 reasons why the project was not
successful.
Once the project is closed, the project manager should evaluate each project team member indi-
vidually 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
or close-out meeting of the project. The outcome of this review should be a final set of documented
lessons learned and best practices that can be shared throughout the organization.
The project should also 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 organizational 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 discernible immediately following the release of a product or
implementation of a new system. It may take weeks or even months after a product or system is released
before a valid evaluation can be made to determine whether the project was successful, as defined by
its MOV.

PRODUCT RELEASE OR SYSTEM IMPLEMENTATION

At some point, testing is complete and the project team and project manager then become responsi-
ble for ensuring that the product or system is transferred successfully from the development and test
environment to the operational environment of the customer or organization.
This transfer requires a tactical approach that is defined dur-
Target date ing the planning stages of the project, but the actual implementation
activities can be a stressful time for all the stakeholders involved.
Choosing an inappropriate implementation approach can negatively
impact the project’s remaining schedule and budget. In general,
the project team can take one of three implementation approaches:
Old system
(a) direct cutover, (b) parallel, and (c) phased.

Direct Cutover
New system
The direct cutover approach, as illustrated in Figure 12.1, can be
used to replace an existing product or system. In short, the old prod-
uct or system is shut down and the new product or system is released
or turned on. In general, a target, or release, date is agreed upon, and
Figure 12.1 Direct Cutover the new product or system simply replaces the old.
 Marchewka c12.tex V2 - November 26, 2014 3:30 P.M. Page 308

308 CHAPTER 12 / PROJECT COMPLETION

This approach is also appropriate when releasing a new product or system, when quick delivery is
critical, or when the existing product or system is so poor that it must be replaced as soon as possible.
Direct cutover may also be appropriate when a system is not mission critical—that is, the system’s
failure will not have a major impact on the organization. It is important, however, that the new product
or 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 an old system is turned off and a 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 customers
or project stakeholders can create a great deal of stress for the project team.

Parallel
As Figure 12.2 illustrates, the parallel approach to implementation allows the old and the new product
or system to run concurrently for a time. At some point, the organization switches entirely from the old
to the new. The parallel approach is appropriate when problems or the fail-
Target date ure of the product or system can have a major impact on the organization.
For example, an organization may be implementing a new accounts receiv-
able 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
Old system
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 cus-
tomers or users of the system. For example, the users of accounts receivable
New system system will probably have to enter data into both the old and the new sys-
tems 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, how-
Figure 12.2 Parallel ever, 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.
On the other hand, many organizations have two versions of a product that are available to their
customers. For example, a company that develops and sells an operating system may support several
versions for some time until the older version is finally phased out. Subsequently, this can result in
significant support, maintenance, and selling costs as both products are available to its customers.

Phased
Following the phased approach, the product or system is released in modules or in different parts of
the organization incrementally as illustrated in Figure 12.3. For example, an organization may imple-
ment an enterprise resource planning (ERP) system by first purchasing and installing the general ledger
component, then accounts payable and accounts receivable, and so forth.
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
 Marchewka c12.tex V2 - November 26, 2014 3:30 P.M. Page 309

PRODUCT RELEASE OR SYSTEM IMPLEMENTATION 309

Target date Target date Target date 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
Old system
the initial implementation so that later implementations
run more smoothly. Similarly, a project team developing a
product using Agile, may plan for several product releases
where increasing features and functionality are added to
New system each subsequent product release.
Although the phased approach may take more time
Phase 1 Phase 2 Phase 3 than the direct cutover approach, it may be less risky and
much more manageable. Also, overly optimistic target
Figure 12.3 Phased 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. As the
end of the project draws near, everyone may become anxious to finish the project and move on to
other things. Unfortunately, there is often a great deal of work that still needs to be completed. Delays
or unanticipated problems may require additional time and unbudgeted resources, leading to cost and
schedule overruns or extra unpaid effort, especially if an implied warranty exists (1).
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 customer
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.

Table 12.1 Comparison of Implementation Approaches

Direct Cutover Parallel Phased

Implementation can Provides a safety net or backup Allows for an organized and
be quick in case problems are managed approach for
encountered with the implementing product or
implementation of the new system modules in different
product or system departments or geographical
locations
Can be risky if Can increase confidence in the Experience with early
product or system new product or system when implementation can guide and
is not fully tested output of old system and new make later implementations
system is compared go more smoothly
Places more Takes longer and may cost more Takes longer and may cost more
pressure on the than direct cutover approach than the direct cutover
project team approach
Places more pressure on the Problems encountered during
customers or users of the early phases can impact the
product or system overall project schedule and
budget
 Marchewka c12.tex V2 - November 26, 2014 3:30 P.M. Page 310

310 CHAPTER 12 / PROJECT COMPLETION

PROJECT CLOSURE
Although all projects must come to an end, a project can be terminated for any number of reasons.
There are five circumstances for ending a project: normal, premature, perpetual, failed, and changed
priorities (2).

▪ Normal—A project that ends normally is one that is completed as planned. The project’s 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 or
released to the customers, and the end of the project is marked with a celebration, awards,
and recognition for a 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 product or 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 of 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 an 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 product or
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 appro-
priate decision to “pull the plug” on an unsuccessful project. The decision to terminate a project
is not an easy one if egos and perhaps 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 (3). No matter what the cause, project resources
are eventually drained to a point where a potentially successful project becomes unsuccessful
(4). 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, a 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 priorities—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,” whereby successive budget cuts over
time can slowly starve a project budget to the point where it is ended but the termination is
masked (5). Senior management may not want to admit that it had 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 die eventually 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
 Marchewka c12.tex V2 - November 26, 2014 3:30 P.M. Page 311

PROJECT CLOSURE 311

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. Many times the project
team is exhausted as the project nears completion and may leave in haste without completing all of the
deliverables (6). It is important that the project manager and team be prepared to deal with the following
realities (7):

▪ Team members are concerned about future employment—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 (5). 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.
▪ Bugs still exist—Testing the product or system is an important process. However, testing may
not find all the defects, and certain bugs may not become known until after the product has
been released or system has been implemented. The appearance of these problems can be frus-
trating and stressful to all the project stakeholders. Unless these defects and bugs are promptly
addressed and fixed, the project sponsor’s or customers’ satisfaction with the product or system
may become an issue.
▪ Resources are running out—Resources and the project schedule are consumed 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—Most projects have a great deal of documenta-
tion requirements. They require project, system, 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 important. As a result,
documentation may require more time and resources to complete, 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, implementation risks, competitive require-
ments, 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 project resources
become depleted, various project stakeholders may experience a sense of alarm. The managers
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 product or system will not be
delivered on time and within budget or provide the expected value to the organization. More-
over, 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 completion grow dim.
 Marchewka c12.tex V2 - November 26, 2014 3:30 P.M. Page 312

312 CHAPTER 12 / PROJECT COMPLETION

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 closeout allows the team to wrap up the
project in a neat, logical manner. From an administrative 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 (6).

Project Sponsor Acceptance

The most important requirement for closure under normal circumstances is obtaining the project spon-
sor’s acceptance of the project. Delivery, installation, and release of the product or system do not
necessarily mean that the project sponsor or customer will accept the project’s product. Since acceptance
depends heavily on the fulfillment of the project’s scope and quality objectives, the project manager
becomes responsible for demonstrating that all project deliverables have been completed according to
specifications (8). 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 (1).
Project sponsors may be shortsighted or knowledgeable. 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, on the other hand, realize that they have an important stake in the out-
come of the project. As a result, they will be actively involved throughout the project in a constructive
manner. 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 spon-
sor will negotiate intelligently and in good faith. Regardless of whether the sponsor is shortsighted
or knowledgeable, the project manager and team can improve the likelihood that the project will be
accepted if they clearly define the acceptance criteria for the project at the early stages of the project,
and document the completion of all project deliverables and milestones.
A clear definition of the project deliverables is an important concern for project scope management.
Yet, defining and verifying that the project scope and system requirements are accurate and complete
is only one component. 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 project approach incorporated in this text also focused on managing the project based on
phases that focus on specific deliverables. Project milestones provide a quality check to 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 customer 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 (1, 9). Once
 Marchewka c12.tex V2 - November 26, 2014 3:30 P.M. Page 313

PROJECT CLOSURE 313

finalized, the final project report provides a background and history of the project. The report should
include and discuss the following areas at a minimum:
▪ Project summary
▪ Project description
▪ Project MOV
▪ Scope, schedule, budget, and quality objectives
▪ Comparison of planned versus actual
▪ 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
▪ Product or 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 sponsor, the final
meeting and presentation should be a simple, straightforward affair. The final meeting is useful
for (9):
▪ 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.
▪ Transference of the product or system—Although the product or system may have been imple-
mented and is being used by the organization or the customer, 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 customer 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 cus-
tomer to formally accept the product or 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.

Administrative Closure
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 or team may view these admin-
istrative items as boring or because they are already looking forward to and thinking about their next
assignment (2). Unfortunately, administrative closure is a necessity because once the project manager
 Marchewka c12.tex V2 - November 26, 2014 3:30 P.M. Page 314

314 CHAPTER 12 / PROJECT COMPLETION

and team are officially released from the current project, getting the sponsor or customer to wrap up the
last of the details will be difficult. The requirements for administrative closure include:
▪ Verifying that all deliverables and open items are complete
▪ Verifying the project sponsor or customer’s formal acceptance of the project
▪ Organizing and archiving all project deliverables and documentation
▪ Planning for the release of all project resources (i.e., project team members, technology, equip-
ment, facilities)
▪ Planning for the evaluations and reviews of the project team members and the project itself
▪ Closing of all project accounts
▪ 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 successful?” 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. Evaluating the project at its completion
provides an opportunity for retrospection that can improve the capabilities of both the project team
members and the organization and satisfies the human need for closure (10).
Therefore, four types of project evaluations should be conducted. There should be:
1. An individual review of each team member’s performance by the project manager
2. A project close-out review (sometimes called a postmortem review) by the project manager and
project team
3. An audit of the project by an objective and respected outside party
4. An evaluation sometime after the product is released or the system 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 following 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
performance, 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 per-
formance. This system creates a useful dialog that provides the individual with more useful
feedback.
▪ Avoid “why can’t you be more like … ?”—It’s easy to compare individuals. Unfortunately,
comparisons can have a counter effect. First, the person you exalt may not be the shining star
 Marchewka c12.tex V2 - November 26, 2014 3:30 P.M. Page 315

PROJECT EVALUATION 315

you think. Second, others may become jealous and look for ways to discredit or disparage the
individual. Keep in mind that people are different and should be evaluated as individuals.
▪ Focus on specific behaviors, not the individual—When discussing opportunities for improve-
ment with a person, it is important to focus on specific behaviors. For example, if a project team
member has a habit of consistently showing up late and disrupting team meetings, it is impor-
tant 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 the evaluator is not fair with everyone.
▪ Reviews should provide a consensus on improving performance—The purpose 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 individuals 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 communication 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 (2). And, in most cases, the project manager could use this meeting to discuss
the project team member’s next assignment.

Project Close-Out (Postmortem) Review

Shortly after the final project report and presentation are completed, the project manager and project
team should conduct a close-out meeting or 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
(4). 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?
▪ 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 standards 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 the project and product methodologies—The team should
review its effectiveness in the following areas:
▪ Product/systems development
▪ Project scope management
 Marchewka c12.tex V2 - November 26, 2014 3:30 P.M. Page 316

316 CHAPTER 12 / PROJECT COMPLETION

▪ Project time management

▪ Project cost management
▪ Project quality management
▪ Project team and resource acquisition
▪ Project stakeholder and communications management
▪ Project risk management
▪ Organizational change management
▪ Product release or system 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? This is also a good
opportunity to celebrate the end of the project as well as announcing any promotions. Tying
rewards to a successful project can be a great morale builder (11).
The discussion and recommendations from the close-out/postmortem review should be docu-
mented. In particular, the project manager and team should identify what they did right and what they
could have done better. Although lessons learned should be documented throughout the project when
they occur, this final meeting provides a last chance to review past experiences and document any new
lessons learned so that they can be shared with others in the organization (12). Moreover, best practices
should be identified and become part of the project and product methodologies.

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 close-out/postmortem review, the auditor or audit team should focus on how well the
project was managed and executed. This may include the project plans, processes, and methodologies.
In addition, the auditor or audit team should assess whether the project manager and team acted in a
professional and ethical manner.
The depth of the audit depends on the organization’s size, the importance and size of the project,
the risks involved, and the problems encountered (2). 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 the 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 a broad base of project and/or industry experience
The findings or results of the project audit should be documented as well as any new lessons learned
and best practices.

Evaluating Project Success—The MOV

The MOV, or measurable organization value, was defined at the beginning of the project. It provided
the basis for taking on the project and supported many of the decision points throughout the project life
 Marchewka c12.tex V2 - November 26, 2014 3:30 P.M. Page 317

CHAPTER SUMMARY 317

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 two questions: Did the project achieve its MOV? And is the sponsor/customer satisfied?
Before conducting this evaluation, the consulting firm or individuals representing the project should
be sure that the product or system delivered has not been changed. Often, when a product or 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 unintended adverse effects. Care should be taken to ensure that the product
or system being evaluated is the product or system that was delivered (4).
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 project that brings measurable value to
an organization provides a foundation for organizational success.

CHAPTER SUMMARY
⦁ The release of a product or implementation of a implementation takes place over phases accord-
system requires a tactical approach for ensuring ing to a published schedule. Experience gained
that it is transferred efficiently and effectively from early implementations can make later
from the project environment to the customer or implementations go more smoothly; on the other
day-to-day operations of the organization. hand, any unanticipated problems can create a
⦁ Three approaches to implementation were dis- chain reaction that pushes back the entire imple-
cussed in this chapter. The first approach, called mentation schedule.
direct cutover, provides the quickest means for ⦁ Choosing and implementing the correct imple-
implementation. In general, the new product is mentation approach can have a significant
released or the old system is turned off and the impact on the project schedule and budget.
new system is turned on. This approach can ⦁ Once the product has been released or the system
be risky if the system has not been thoroughly has been implemented, the project manager and
tested. As a result, it can put a great deal of team must plan for an orderly end to the project.
pressure on the project team to “get it right”
the first time, especially if the system supports ⦁ Projects can be terminated for a variety of rea-
a mission-critical function of the organization. sons, but a project must be properly closed,
regardless of whether the project ends success-
⦁ The parallel and phased approaches are less fully or unsuccessfully.
risky alternatives, although implementation may
take longer. The parallel approach requires that ⦁ Ideally, the project is closed under normal
both the old product or system and new product conditions—that is, the project scope is com-
or system run concurrently for a time until there pleted within reasonable modifications to the
is enough confidence that everything is working original schedule, budget, and quality objectives.
properly. At some point, a switch is made from ⦁ Delivery of the product or installation of the sys-
the old to the new. The parallel approach can be tem does not necessarily mean that the project’s
stressful for the users of the system because they sponsor or customer will accept the project.
may be required to provide input for both sys- Therefore, closure must focus on providing both
tems and then compare the outputs. proof and confidence that the project team has
⦁ The phased approach may be appropriate when delivered everything according to the original
implementing an upgrade product or a modu- business case, project charter, and project plan.
lar system in different departments or at differ- ⦁ Several processes for closing a project were
ent geographical locations. Under this approach, discussed in this chapter. They include closing
 Marchewka c12.tex V2 - November 26, 2014 3:30 P.M. Page 318

318 CHAPTER 12 / PROJECT COMPLETION

the project accounts, releasing or transfer- should review all of the project deliverables and
ring project resources, documenting lessons processes to assess how well the project was
learned, and archiving all project documents and managed.
deliverables. ⦁ The auditor or audit team should also focus on
⦁ Before a project is completed, it is important the specific challenges the project manager and
that several reviews or evaluations be conducted. team faced and how well they addressed these
These evaluations include a performance review challenges. The professional and ethical behav-
between the project manager and each project ior of the project manager and project team
team member. A closeout or postmortem review should be examined as well.
with the project manager and the entire team ⦁ Although different stakeholders may have differ-
should include all of the project deliverables, ent views of project success, the overall guiding
project plans, and, in general, the various project mechanism for determining whether the project
management body of knowledge areas. was a success is the project’s MOV. Unfortu-
⦁ Although lessons learned should be documented nately, the organizational value that a project
and best practices identified throughout the provides may not be readily discernible imme-
project, the completion of the project provides diately after the information system is imple-
one last chance to identify any lessons learned mented. Even if it takes place weeks or months
and best practices. after the project is officially closed, an evalua-
⦁ The performance reviews and postmortem tion as to whether the project has met its MOV
should provide preparation for the project audit. must still be conducted.
In this case, a respected and objective third party

REVIEW QUESTIONS
1. What is implementation? 12. Why is the sponsor’s acceptance of the project
2. Describe the three approaches to releasing a product important to project closure?
or implementing a system. 13. How can the project manager and project team facil-
3. What are the advantages and disadvantages of the itate the project sponsor’s acceptance of the project?
direct cutover approach? 14. What is the difference between a shortsighted and
a knowledgeable project sponsor? How can mak-
4. What are the advantages and disadvantages of the
ing this distinction help the project manager during
parallel approach?
project closure?
5. What are the advantages and disadvantages of the 15. What is the purpose of the final project report?
phased approach?
16. What is the purpose of the final meeting and
6. Describe the various scenarios for project presentation?
termination.
17. Describe some of the steps for administrative
7. Why might an organization terminate a project pre- closure.
maturely? What are the risks? 18. What is the purpose of the project manager conduct-
8. What is a perpetual project? Why might an organi- ing a performance review with each member of the
zation be reluctant to terminate a project that many project team?
would consider unsuccessful? 19. What is the purpose of conducting a close-out or
9. Why would senior management cut a project’s bud- postmortem review?
get without officially terminating the project? 20. What is the purpose of a project audit?
10. Why might some project team members be reluctant 21. What criteria should be used to choose a project
to see the end of a project? auditor or auditing team?
11. Why can the end of a project be stressful for many 22. What is the purpose of evaluating the project’s
of the project stakeholders? MOV?
 Marchewka c12.tex V2 - November 26, 2014 3:30 P.M. Page 319

THE MARTIAL ARTS ACADEMY (MAA)—SCHOOL MANAGEMENT SYSTEM 319

23. Why would it be difficult to evaluate whether or not 25. Why would evaluating whether a project achieved its
a project achieved its MOV shortly after the product MOV make many project managers and teams anx-
is released or the system is implemented? ious? Why should it still be done?
24. Why should any lessons learned from project evalu-
ations be documented?

HUSKY AIR ASSIGNMENT—PILOT ANGELS

The Implementation and Project Closure Plan 3. The project’s MOV. (This should be revised or
The testing of the application system is now close to refined if appropriate.)
being complete. In this assignment, you and your team 4. A conversion strategy—Develop a strategy for
will develop an implementation and project closure plan converting Husky Air’s current system to the
to support your project with Husky Air. new application system your consulting firm has
This would also be a good chance for you and your developed.
team to do another learning cycle. Read through this Be sure to explain why you have chosen
assignment first and then meet as a team to develop a one of the following conversion strategies as well
Project Team Record and an Action Plan. This will help as why you didn’t select one of the other two
to improve team learning and to assign responsibilities to strategies:
complete the assignment. a. Direct cutover
Please provide a professional-looking document that b. Parallel
includes the following:
c. Phased
1. Project name, project team name, and the 5. A closure checklist—Develop a checklist that the
names of the members of your project project team will use to ensure that the project has
team. been closed properly.
2. A brief project description. (This helps your 6. A project evaluation—Prepare an outline and
instructor if different teams are working on differ- discussion of how your project’s MOV will be
ent projects in your class.) evaluated.

THE MARTIAL ARTS ACADEMY (MAA)—SCHOOL

MANAGEMENT SYSTEM
Deliverable: Project Implementation and Closure 4. A conversion strategy. Develop a strategy for
The testing of the school management application system converting MMA’s current system to the new
is now nearing completion. In this assignment, you will application system. Be sure to explain why you
develop an implementation and project closure plan. have chosen one of the following conversion
This would also be a good chance for you and your strategies as well as why you didn’t select one of
team to do another learning cycle. Read through this the other two strategies:
assignment first and then meet as a team to develop a a. Direct cutover
Project Team Record and an Action Plan. This will help
to improve team learning and to assign responsibilities to b. Parallel
complete the assignment. c. Phased
Please provide a professional-looking document that
includes the following: 5. A closure checklist. Develop a checklist that you
will use to ensure that the project has been closed
1. Project name, project team name, and the
properly.
names of the members of your project team.
2. A brief project description. 6. A project evaluation. Prepare an outline and
3. The project’s MOV. (This should be revised or discussion of how your project’s MOV will be
refined if appropriate.) evaluated.
 Marchewka c12.tex V2 - November 26, 2014 3:30 P.M. Page 320

320 CHAPTER 12 / PROJECT COMPLETION

QUICK THINKING—KILLING A PROJECT

The decision to cancel a project that has little or no affect the project team. Project team members’ morale
chance of meeting its envisioned benefits or meeting may suffer if they have an emotional attachment to the
its objectives can be a difficult and complex decision. project’s failure. Disillusioned employees may become
Many people are afraid to face the truth when it comes to unproductive or those with highly marketable skills may
a failed project. According to Bart Perkins, euthanizing leave, often making it difficult to attract or retain other
these projects is important to the health of the organiza- valuable project team members.
tion. However, before “pulling the plug,” it’s important
1. What criteria should be used to cancel a project?
to understand and plan for a number of important issues.
For example, large projects can have political ramifica- 2. Who should make the decision to kill a project?
tions, especially if powerful stakeholders have a vested 3. How can an organization ensure that a doomed
interest in the project. This can lead to finger pointing project is euthanized as early as possible?
and looking for someone to blame for the project’s fail- 4. As a project manager of a doomed project, what
ure. Moreover, a cancelled project can be expensive if would be your top three priorities for planning the
cancelling a project includes severance packages, con- cancellation of the project?
tractual agreements (i.e., early termination penalties),
Sources: Adapted from Perkins, B. “Opinion: Before You Kill
litigation, writing off sunk costs, or missed business
That Project. … ” Computerworld. March 10, 2008.
opportunities. Failed projects can also impact relation- Glen, P. “Five Signs a Project is Headed for Trouble.” CIO
ships. This may include damaged working relationships Magazine. May 4, 2009.
with suppliers who may refuse to work with your orga- Mersino, A. “Project Fear and Denial.” Projectsatwork.
nization in the future. Lastly, killing a project can also February 2, 2011.

QUICK THINKING—THE POST-IMPLEMENTATION AUDIT

Once an off-the-shelf Web-based procurement system they may take too much time, which adds to a project’s
was implemented, the CIO of a $405 million engineer- cost and schedule. Second, post-implementation audits
ing and construction company, Michael Baker Corp., often require massive amounts of documentation to
was inundated by questions regarding the system’s validate results. Lastly, uncovering unfavorable results
effectiveness. Unfortunately, the CIO didn’t have any may lead to a fear that someone will be blamed. How-
concrete proof that the system improved efficiency. ever, post-implementation audits serve an important role,
As a result, he decided to conduct the company’s first especially during challenging economic times as organi-
post-implementation audit that included a thorough eval- zations feel increased pressure to spend money efficiently
uation of the system’s benefits, security, and project man- and effectively.
agement processes. Although the CIO found out that the
1. As a consultant, how could you convince your
system’s return on investment was lower than originally
client that conducting a post-implementation
envisioned due to a miscalculation of the number of user
audit is worth the added time and cost?
licenses needed, the audit uncovered that the company
was saving more than $150,000 a year. He also learned Sources: Adapted from Levinson, M. “How to Conduct
several valuable lessons on what not to do on future Post-Implementation Audits.” CIO Magazine. October 1,
projects. While postimplementation audits are a useful 2003.
tool to show the value of projects, it is estimated that only Smith, C. “Advice for Project Audits.” Projectsatwork. January
20 percent of organizations conduct one. Many orga- 10, 2008.
nizations are reluctant to make a post-implementation Kothari, D. “Roadmap for Project Recovery.” Projectsatwork.
audit a standard process for three main reasons. First, April 12, 2012.
 Marchewka c12.tex V2 - November 26, 2014 3:30 P.M. Page 321

CASE STUDIES 321

CASE STUDIES
Kaiser e-Health Records Management System Kaiser Permanente. And we’re wasting billions of dol-
Implementation lars trying to make it. The issues for me are the financial
Kaiser Foundation Health Plan/Hospitals’ implemen- repercussions of trying to launch such an ineffective
tation of HealthConnect, a $4 billion electronic health and inefficient and unreliable system across the organi-
records management system from Epic Systems Corp., zation. Using Citrix is something that defies common
received media attention as another IT project in seri- sense. It would be like trying to use a dial-up modem for
ous trouble. As the project drew public attention, thousands of users. It’s just not going to work, and it’s
Kaiser’s CIO, Cliff Dodd, resigned while another Kaiser not something anyone would tell you a dial-up modem
employee, Justen Deal, sent a memo to all fellow employ- should work for.” Deal also stated that Kaiser is wasting
ees detailing the project’s financial and technological more than $1.5 billion a year on HealthConnect as well
problems. Deal, a publication project supervisor in the as other troubled IT projects.
Health Education and Training Department, stated that Scott Herren, a group vice president and general
he also made his concerns known to Kaiser management, manager at Citrix Systems Inc., believes the problem
but company officials reported that Deal’s concerns were isn’t scalability but the overall architecture that is being
looked into and that the HealthConnect project’s imple- used to support loads this large. Moreover, he states that
mentation was not a failure. One of Kaiser’s attorneys HealthConnect’s problems do not have anything to do
replied in a letter to Deal that “in the implementation of with the Citrix product: “In fact, we have many very large
a new, large and complex system such as KP HealthCon- successful Epic deployments around the world. However,
nect, various technical problems are likely to arise, but in order to support large deployments, the Citrix imple-
none that you mention are unknown to KP-IT nor were mentation must be architected accordingly.”
as insurmountable as you imply.” Matthew Schiffgens, a spokesperson for Kaiser, said
Kaiser did not offer any details regarding Cliff “As you move out with a very large deployment like this,
Dodd’s departure, and Justen Deal was placed on admin- you encounter challenges along the way, and we have
istrative leave. a process to systematically address challenges as they
The HealthConnect system was expected to provide arise. The problem at the Corona data center was a good
more than 100,000 of Kaiser’s doctors and employees one. It came up, we addressed it, and we feel confident
with immediate access to almost nine million patient that we made the proper infrastructure to manage that.
medical records. In addition, the system would provide That is a fundamental practice of running a good busi-
e-messaging, online order entry and filling of prescrip- ness. Does that mean there are systematic and ongoing
tions that would also integrate with appointment schedul- problems? No. You identify issues and address them as
ing, registration and billing, as well as other functionality they go along.”
that would be available to Kaiser members through its However, a number of Kaiser employees are still
Web site. concerned. As one Kaiser IT employee, who wished to
However, a 722-page internal report obtained by remain anonymous, stated: “People out in the field are
Computerworld listed hundreds of technical problems, frustrated, and the people in IT are just as frustrated
some that impacted patient care. Deal’s memo stated that because this was a solution forced upon us and was not
reliability and scalability were the main issues because an IT solution. I know in conversations I’ve had with my
the Citrix Application Delivery infrastructure imple- superiors there was a big push back in selecting Epic,
mented by Kaiser could not handle the load of the Epic and it was not a choice made by IT simply because of the
system. According to Deal, “We’re the largest Citrix large infrastructure needed to support it.”
deployment in the world. We’re using it in a way that’s
quite different from the way most organizations are using 1. In your opinion, do you think that by “blowing
it. A lot of users use it to allow remote users to con- the whistle” Justen Deal was a troublemaker, or
nect to the network. But we actually use it from inside a concerned employee who did the right thing by
the network. For every user who connects to Health- detailing the project’s problems to all employees
Connect, they connect via Citrix, and we’re running across the organization?
into monumental problems in scaling the Citrix servers. 2. Compare the views of Justen Deal, Scott Her-
Epic simply cannot scale to meet the size and needs of ren, and Matthew Schiffgens. Why would these
 Marchewka c12.tex V2 - November 26, 2014 3:30 P.M. Page 322

322 CHAPTER 12 / PROJECT COMPLETION

individuals have such different views of this The implementation of the project comes with the
project’s implementation? hefty price tag of $47 million. However, according to
3. Should Kaiser terminate this project? Or should Phillis, this estimate includes many years of costs asso-
it continue with the implementation? What are ciated with changing the system prior to starting Project
the ramifications for terminating the project, or Ocean in 2002. Phillis believes that the biggest lesson
continuing? learned from this experience is that “technology is not
the prime concern in being successful in a project of this
Sources: Adapted from Rosencrance, L. “Problems Abound for Kaiser
size. Instead success is a matter of process, collaboration,
e-Health Records Management System.” Computerworld. Novem- and leadership, although the technology has to work and
ber 13, 2006. it has to match your skill sets. We had to spend a lot of
Chen, C., T. Garrido, D. Chock, G. Okawa, and L. Liang. “The Kaiser time upfront deciding how to run this and how to collab-
Permanente Electronic Health Record: Transforming and Streamlin- orate between three departments.”
ing Modalities of Care.” Healthaffairs. March/April 2009, Vol. 28,
no 2, 323–333. 1. Although Philadelphia’s new water billing sys-
Kolbasuk McGee, M. “Kaiser Permanente Finishes EMR Rollout.” tem was implemented, would you consider this
Informationweek. March 10, 2010.
Snyder, B. “How Kaiser Bet $4 Billion on Electronic Health
project a success?
Records—and Won.” Infoworld. May 2, 2013.
Sources: Adapted from Hamblen, M. “Philadelphia Buoyant after
Completing Water Billing System.” Computerworld. January 18,
Project Ocean—Part 21 2008.
Gelbart, M. “Water-bill Changes Finally Flowing Philadelphia’s Project
Project Ocean was a new water billing system that the
Ocean, Begun in 2002, is Working At Last. Total Cost: about $25
city of Philadelphia initiated in 2002. By 2006, the city million.” Philly.com., January 18, 2008.
had spent more than $18 million (twice what it expected
to spend), the project was two years late, and the sys- The Many Impacts of Implementation Failure
tem still had not been deployed. The project suffered Enterprise software applications include enterprise
from a number of problems that included software vendor resource planning (ERP), customer relationship manage-
problems, turnover of key employees, poor project man- ment (CRM), business intelligence (BI), and supply-
agement, and weak governance. However, when Michael chain management (SCM). However, according to
Nutter was sworn in as mayor in January 2008, the city Thomas Wailgum, the implementation of these multi-
had a new and functional water billing system.1 million dollar applications have produced “spectacular
Although Oracle was the original software provider, failures and huge spending nightmares; vendor marketing
the final implementation of the system was provided by bravado that breeds cut-throat competition and contempt;
a new off-the-shelf billing system from Prophecy Inter- and embarrassing and costly lawsuits over botched imple-
national PTY in Adelaide, Australia. According to the mentations and intellectual property breaches.”
city’s CIO, Terry Phillis, the Prophecy billing system was Over the years, a number of enterprise system
implemented one month ahead of schedule and 25 per- failures have received public attention. For example,
cent under budget. The Prophecy system was chosen after Hershey Foods’ implementation of SAP, CRM, and
Phillis and the city of Philadelphia decided to scrap most supply-chain applications resulted in a spectacular fail-
of the original Oracle applications chosen by Dianah ure when the company was unable to deliver $100 million
Neff, Phillis’ predecessor. The new system replaces a with of chocolate candy in time for Halloween. On the
30-year-old mainframe legacy system that still relied on other hand, Waste Management is involved in a $100 mil-
punch cards. Changes to the old system required writing lion lawsuit with SAP over an implementation of its ERP
new Cobol programs, which could take up to a year. The software. The legal battle focuses on fraudulent claims
new system now allows the city to make changes in a that SAP promised that its software would be an “out of
matter of days and allows customers to track their water the box solution for Waste Management’s business pro-
conservation efforts. According to Phillis, “Converting cesses,” while SAP claims Waste Management breached
this thing over was a huge effort. We had to deal with its side of the contract by failing to “timely and accurately
30 years of garbage data in the old system.” After taking define its business requirements” and failing to provide
over as the city’s new CIO, Phillis led an implementation “sufficient, knowledgeable, decision-empowered users
team of managers from three city agencies. and managers to work on the project.”
1A description of Project Ocean can be found in Chapter 1.
 Marchewka c12.tex V2 - November 26, 2014 3:30 P.M. Page 323

CASE STUDIES 323

Failed enterprise system implementations can project that has your name on it and it fails, I don’t know
also put a company into bankruptcy. For example, a if you can recover.”
Colorado-based jewelry chain called Shane Co. filed Failed implementations can have a different kind
for Chapter 11 bankruptcy and attributed this move of impact for those working directly on the project. As
due to rampant cost overruns on an SAP implementa- Michael Fitzgerald believes, “It’s not hard to get emo-
tion. According to a court filing, Shane Co. entered into tional when lengthy, high-profile projects are unfairly
a contract with SAP for a “highly sophisticated point killed, mercifully euthanized, or launched with flaws.”
of sale and inventory management system at an origi- Moreover, Ken Corless, an executive director of enter-
nally projected cost of $8 million to $10 million and a prise applications management at Accenture, explains,
one year project schedule.” Unfortunately, the company “A lot of your job satisfaction comes out of seeing your
found that the software “did not yet provide accurate product go live, being used by your business and cus-
inventory count numbers, causing it to be substantially tomers. If you’ve been on something for 19 months,
overstocked with inventory, and with the wrong mix of working 80-hour weeks for six months, and you’re sup-
inventory.” The court document also cites that while the posed to go live in six weeks and the rug gets pulled out,
system became stable it still does not include all that you feel pretty bad.”
functionality detailed in the contract. Bill Hagerup is a senior consultant at Ouelette &
These failures not only impact the organiza- Associates Consulting, Inc. in Bedford, NH, and was a
tion but the careers of senior managers as well. As lead analyst who worked long hours on a project at a
Thomas Wailgum states, “Your department—infor- health insurer. Despite the extra effort, the project’s scope
mation technology—has just played a starring role in was too large for the scheduled deadline, and he and
blowing a multimillion dollar enterprise software project. his team delivered about 60 percent of what the com-
The intense glare from the CEO, CFO, and other business pany expected. According to Hagerup, “There was not
leaders is squarely focused on the CIO, VP of applica- joy in IT-ville, not even an ‘attaboy’ for the effort. Some
tions, project managers, and business analysts charged negative feelings about the poor outcome were proba-
with making sure that this didn’t happen.” However, bly inevitable, but it would have helped if there had been
Wailgum is also quick to point out that IT is never 100 some empathy for the IT team.”
percent at fault for these types of project failures, but Hagerup believes that some simple words of appre-
“the unfortunate and unfair fact is that because these ciation for their effort from senior management would
initiatives are considered ‘technology projects,’ the busi- have helped with the feelings of anger at the unreasonable
ness will most always look in IT’s direction when there’s deadline and lack of support. Hagerup and his team of
blame to be tossed around.” about ten people went through several weeks in a depres-
An IT governance study included more than 250 sion where productivity and morale were at an all-time
interviews with senior managers reported that about 50 low. As Hagerup explains, “By talking informally at
percent of the respondents believe that IT is “very impor- lunch and commiserating over beers on Friday nights,
tant to the enterprise” and about 75 percent said that we gradually came out of it. We circled the wagons a
they align IT with their business strategies. In addition, little bit, took strength from each other and reminded
about 70 percent identified “executive management” as ourselves it wasn’t our fault.” He also adds that while
the group that should be held accountable to IT gover- the team eventually continued to work on the project and
nance and IT project accountability. eventually met most of its initial goals, it never received
Chris Curran is a consulting partner at Diamond any credit. Hagerup also believes that he and his team
Management & Technology Consultants and its Chief members would have come out of their depression more
Technology Officer (CTO). Curran contends, “Business quickly had management talked to them about the situa-
investments need to have business accountability, but tion and allowed them to have a dialog regarding whether
when a project goes south, especially high-profile ERP the project was a failure.
implementations, IT gets blamed—but it’s not an IT On the other hand, a project team may be less emo-
project.” Moreover, Curran has seen his share of prob- tional when a project is cancelled because the business
lematic projects and observes, “I’ve never seen any cases needs change since it’s no one’s fault. However, this may
where a CIO just moved along like, ‘Everything’s fine.’ not always be the case. As John F. Fisher, a former CIO
Often, they’re eventually demoted or pushed off into and current chief value officer at a software contracts
some operational role. Once you have a high-profile advisor called NET (net) Inc., “People take it pretty hard
 Marchewka c12.tex V2 - November 26, 2014 3:30 P.M. Page 324

324 CHAPTER 12 / PROJECT COMPLETION

when a project that’s going well is killed, anyhow. They is what the COO wants to do’. That says you’re not part
feel like, ‘Could I have done something better? How of the leadership team. Such managers lose a chance to
could we make it work for the business? Well, you can’t. build credibility and rapport with their teams.”
And that frustrates a lot of IT people.” Most importantly, Corless believes managers need
Fisher was involved in cancelling a two-year project to keep in mind what motivates IT people: the chance
to develop an international banking platform to enable a to learn new things and develop new skills. With that in
bank to update its European operations. As the European mind, Corless contends, “To that end, the best way to help
systems manager, Fisher was brought into the project employees grieving over a dead project is to quickly get
after it had started. It became clear to him that the plat- them into [another] meaty and interesting role. Project
form was missing several important features, and there failures may not be fun at the time, but it doesn’t have to
was no cost-effective solution to fix those problems. It keep a good IT person down.”
was a difficult decision, but Fisher had to lay off about
1. In your opinion, do you think IT receives more
a dozen contractors in London and scrap a data center.
than its share of blame when the implementation
As Fisher explains, “I felt good at the time.” After all, he
of an enterprise project fails?
was saving time and money for the bank. However, he
soon realized that he and the remaining members of his 2. What steps could senior management take to help
team were tainted. They were not included on the team lessen the feelings of frustration and anger that
assigned to work on the new system, even though they could lead to lower morale and productivity when
had gained valued experience. Despite no difference in a project is canceled?
the bank’s overall financial performance from the previ-
Sources: Adapted from Fitzgerald, M. “Project Management: When
ous year, Fisher received a much lower end-of-year bonus
Good IT Projects Go Bad.” CIO Magazine. July 26, 2010.
and some of his original team were assigned to less inter- Kanaracus, C. “SAP Project Costs Cited in Jeweler’s Bankruptcy Fil-
esting, lower profile projects for a time. ing.” CIO Magazine. January 14, 2009.
Ken Corless believes that management can best help Kanaracus, C. “SAP: We’ve Spent Millions So Far on Waste Manage-
people by dealing with troubled projects quickly and ment Suit.” CIO Magazine. April 9, 2009.
Wailgum, T. “10 Famous ERP Disasters, Dustups, and Disappoint-
directly. As Corless advises, “Rip the Band-Aid off—tell
ments.” CIO Magazine. March 24, 2009.
people live and in person. Don’t shift the blame by say- Wailgum, T. “After a Massive Tech Project Failure: What IT Can
ing something like, ‘I wouldn’t have canceled it, but this Expect.” CIO Magazine. August 5, 2009.

BIBLIOGRAPHY
1. Rosenau, M. D. Successful Project Manage- 6. Oltmann, J. “Finish Strong.” Projectsatwork.
ment. New York: John Wiley & Sons, 1998. September 20, 2011.
2. Gray, C. F. and E. W. Larson. Project Manage- 7. Frame, J. D. “Closing Out the Project.” In
ment: The Managerial Process. Boston, MA: Project Management Handbook, edited by J. K.
Irwin McGraw-Hill, 2000. Pinto. San Francisco, CA: Jossey-Bass, 1998.
3. Keil, M. “Pulling the Plug: Software Project 8. Wysocki, R. K., R. Beck Jr., and D.B. Crane.
Management and the Problem of Project Effective Project Management. New York: John
Escalation.” MIS Quarterly, December 1995, Wiley & Sons, 1995.
421–447. 9. Buttrick, R. The Interactive Project Workout.
4. Nicholas, J. M. Managing Business and Engi- London: Prentice Hall/Financial Times, 2000.
neering Projects: Concepts and Implementa- 10. Oltmann, J. “Let That be a Lesson Learned.”
tion. Upper Saddle River, NJ: Prentice Hall, Projectsatwork. March 10, 2010.
1990. 11. Rizzuto, J. “Happy Endings.” Projectsatwork.
5. Meredith, J. R. and S. J. Mantel. Project Man- December 1, 2002.
agement: A Managerial Approach. New York: 12. Reich, B. “Lessons Not Learned.” Projectsat-
John Wiley & Sons, 2000. work. October 9, 2008.