CHAPTER 13

PROJECT TERMINATION
The Varieties of Project Termination

A project can be said to be terminated when work on the substance of the project has
ceased or slowed to the point that further progress on the project is no longer possible ,
when the project has been deployed to other projects, or when project personnel
(especially the PM) become “personae non gratae” with senior management and in the
company lunchroom.

Termination by Extinction

The project stopped. It may end because it has been successful and achieved its goals.
The new product has been developed and handed over to the client; the project has been
completed and accepted by the purchaser; or the software has been installed and is
running.
The project may also be stopped because it is unsuccessful or it has been superseded.
A special case of termination by extinction “termination by murder”.
There are all sorts of murders. When a decision is made to terminate project by
extinction, the most noticeable event is that all activity on the substance of the project
ceases. A great deal of organizational activity, however, remains to be done.
Arrangement must be made for the orderly release of project must be disbursed
according to the dictates of the project contract or in anchored with the established
procedures of the parent organization. Finally, the Project Final Report, also known as
the Project History, must be prepared.

Termination by Addition

Most projects are “in-house”, that is common carried out by the project team for
used in the parent organization. It may be terminated by institutionalizing it as formal
part of the parent organization.
When project success results in termination by addition, the transition is strikingly different from
termination by extinction. In both cases the project ceases to exist, but their similarities stops.
Project personnel, property, equipment are often simply transferred from dying project to the
newly born division the metamorphosis from project to department, to division, and even to
subsidiary is accompanied by budgets and administrative practices that conform to standard
procedures in the parent firm, by demands for contribution profits, by the probable decline of
political protection from the project corporate “champion” indeed by a greater exposure to all
usual stresses and strains and regular, routine, day-to-day operations.

Termination by Integration

This method of terminating a project is the most common way of dealing with successful
projects in the most complex. The property, equipment, material, personnel, and functions of the
project are distributed among the existing elements of the parent organization. The output of the
project becomes a standard part of the operating system of the parent, or client.
 Most of the problems of termination by addition are also present when the project is integrated.
In the case of integration, the project may not be viewed as a competitive interloper, by the project
personnel being moved into established units of the parent organization will be so viewed.

Aspect of the transition

1. Personnel- where will the project team go? Will it remain a team? If the functions that the team
perform as still needed, who will do them? if Ex-team members are assigned to a new project,
under what conditions or circumstances might they be temporarily available for help on the old
project?

2. Manufacturing- is training complete? Are input materials and the required facilities available?
Does the production system layout have to be replanned? Did the change create new
battlenecks or line-of-balance problems? Are new operating or control procedures needed? Is
the new operation integrated into the firm’s computer systems?
3. Accounting / Finance- have the project accounts been closed and audited? Do the new department
budgets include the additional work needed by the project? Have the new accounts been created and
account numbers been distributed? Has all projects property and equipment been distributed according to
the contract or established agreements?

4. Engineering- are all drawings complete and on file? Are operating manuals and change procedures
understood? Have training programs been altered appropriately? Do we have a proper level of “spares” in
stock?

5. Information system/software- has the new system been thoroughly tested? Is the software properly
documented and are “comments” complete? Is the new system fully integrated with current systems?
Have the potential users been properly trained to use new systems?

6. Marketing- is the sales department aware of the change? Is marketing in agreement about lead times? Is
marketing comfortable with the new line? Is marketing strategy ready for implementation?

7. Purchasing, Distribution, Legal, etc.- are all these and other functional areas aware of the change? Has
each made sure that the transition from project to standard operation has been accomplished within
standard organizational guidelines and standard administrative procedures have been installed?
Termination by Starvation

There is a fourth type of project termination, although strictly speaking, it is

not a “termination” at all. It is “slow starvation by budget decrement”. Budget
cuts, or decreements, are not rare, they are sometimes used to mask a project
termination.

When to terminate a project

The decision to terminate a project early, by whatever method is difficult.

Projects tend to develop a life of their own, a life seemingly independent of
whether or not the project is successful the main reason so little information
was available on the subject of project termination was that it was hard to spell
out specific guidelines and standards for the decision.
The following as some guide questions for project termination, they are:

1. Is the project still consistent with organizational goals?

2. Is it practical? Useful?
3. Is management sufficiently enthusiastic about the project to support its implementation?
4. Is the scope of the project consistent with the organization’s financial strength?
5. Is the project consistent with the notion of a “balance” program in all areas of the
organization’s technical interest ? in age ? in cost?

6. Does the project have the support of all the department (e.g. finance, manufacturing, marketing,
IT, legal, ect) needed to implement it ?

7. Is organizational project being spread to thin?

8. Is support of this individual project sufficient for success?
9. Does this project represent too great an advance over current
technology? Too small an advance?

10.Is the project team still in innovative, or has it gone stale?

11.Could the project team farmed out without loas of quality?
12.Does it seem likely that the project will achieve the minimum goals
set for it?

13.Is it still profitable? Timely?

The efficiency with which the project is carried out the customer’s satisfaction and willingness to use ( and
repurchase) the product, the impact of the project on the organization carrying it out, also attacked the
problem of defining project success r delineating the path to it.

Few Fundamental reasons why some projects fail:

1. A Project Organization Is not Required – The use of the project form of organization was inappropriate for
the particular task or in this particular environment. The parent organizations must understand the
condition that require instituting a project

2. Insufficient Support From Senior Management – Projects invariably develop needs for resource that were
not originally allocated. Arguments between functional departments over the command of such resources
are very common. Without direct support of a champion in senior management, the project is almost
certain to lose the resources battle.

3. Naming the Wrong Person as a Project Manager- A common mistake is to appoint as PM an individual
with excellent technical skills but weak managerial skills or training.

4. Poor Plannin – This is a very common cause of project failure. In the rush to get the substance of the
project under way, competent planning is neglected. In such cases, crisis management becomes a way of
life, difficulties in error are compounded and the project slowly gets farther behind schedule and budget.
Termination Process

The termination process has two distinct part. Decision whether or not to
terminate. The Decision is to terminate the project, the decision must be carried out.

The Decision Process

Decision- aiding models for the termination decision fall into two generic categories.

First, there are models that base the decision on the degree to which the
project qualifies against a set of factors generally held to be associated with successful
(or failed) project. Second, there are models that base the decision on the degree to
which the project meets the goals and objectives set for it.

The Implementation Process

It be must terminated must be implemented. The actual termination can be

planned and or orderly, or a simple hatchet job.
The primary duties of the termination manager are encompassed in the following nine general tasks.

1. Ensure completion of the work, including tasks performed by the subcontractors.

2. Notify the client of the project completion and ensure that delivery and installations is accomplished at
acceptance of the project must be acknowledged by the client.

3. Ensure the documentation is complete, including a terminal evaluation of the project deliverables and
preparations of the project’s Final Report.

4. Clear for final billing and oversee preparation of the final invoice sent to the client.

5. Distribute personnel, materials, equipment, and any other resources to the appropriate places.

6. Clear project with legal counsel or consultant. File for patents if appropriate. Records and archive all
“nondisclosure” documents.

7. Determine what records (manuals, reports, and other paperwork) to keep. Ensure that such documents are
stored in the proper places and that responsibility for document retention is turned over to the parent
organization’s archivist.

8. Ascertain any product support requirements (e.g. spares, services), decide how such support will be delivered
and assigned responsibility.

9. Oversee the closing the project’s book.

The Final Report- The Project History

Some contain copies of all project reports strung together with short commentaries. What matters is
that several subject should be addressed, One way or another in the final report.

1. Project Performance – A key element of the report is a comparison of what the project achieved (the
terminal evaluation) with what the project tried to achieve include explanation of the significant deviations of
all actual from plan.

2. Administrative Performance – The substantive side of the project usually gets a great deal of attention,
while the administrative is often ignored and until the administrative problems occure.

3. Organizational Structure - Each of the organization forms use for project has it own unique set of
advantages and disadvantages. The final report should include comments on the ways the structure aided or
impeded the progress of the project.

4. Project and Administrative Teams – On occasion, individuals who are competent and likable as individuals
do not performed well as members of a team when a high level of interpersonal communication and
cooperation is required

5. Techniques of Project Management – The outcome of the project is so dependent on the skill with which
forecasting, planning, budgeting, scheduling, resource allocation, risk management, and control are handled
that attention must be given to checking on the way these tasks were accomplished.