Final of Project Failure

Department of business
administration
Total Quality Management Project by

What is failure?
Failure refers to the state or condition of not meeting a desirable or
intended objective, and may be viewed as the opposite of success.
Product failure ranges from failure to sell the product to fracture of the
product, in the worst cases leading to personal injury, the province of
forensic engineering.
Failure of the project:

The failure of a project is when a project gets started and then the project
does not get the degree of success it deserves and gets fail. The project
when fails then there are certain reasons which are responsible for the
failure of that project, those reasons are as below,
What are the causes of failure of Project?

1. Everyone enters the project running on overload.
2. Rushing leads to poorly defined goals at the project’s inception.
3. Unrealistic completion dates leave the team feeling they’ve been “set
up to fail.”
4. A sense of urgency encourages poor communication.
5. Feeling the crunch, the planning effort is reduced or skipped entirely.
6. Other departments fail to support the project creating delays.
7. Continued breakdowns trigger blame and finger-pointing.
8. Scope expands as customers request additional features.
9. Endless meetings to sort it all out lack focus, run too long, rehash the
same territory, are dominated by a few people, and fail to produce or
complete action items.
10. Constant firefighting consumes ever more time and effort.
A bottom to top list for the failure of project:

10. Were still in the meeting phase.
Too Many Meetings
9. I’ll get to it as soon as I extinguish the flames.

Constant Firefighting
8. I was constrained by the 24-hour-a-day limit.

Scope Keeps Expanding
7. I felt I needed additional criticism.

Blame & Finger-pointing
6. The rest of my team had a golf emergency.

Lack of Support
5. We didn’t think it would turn out like this, either. Poor Planning
4. I thought, “Are you crazy?” was a health question.

Miscommunication
3. You wanted it when?!

Unrealistic Deadlines
2. We might have done better if we knew what it was. Poorly Defined

Goals
And the number one reason why the job didn’t get done:
1. The doctor said he’s still recovering from the last project. Overload
Some of the findings related to the failure of the
project related to different researches:
“Management's role in project failure”
What goes wrong?
Figures collected by the UK's Industrial Society in the early1990s, show

that some 77 per cent of projects in the UK fail, while the US figure, 83
per cent, is even worse. For specific sectors the statistics are particularly
bad: it appears that only 7 per cent of business process redesign projects
and just 3 per cent of IT projects succeed. The Industrial Society quotes
the following reasons for project failure:
• inadequate definition;
• poor or no planning;
• wrong leader;
• scope not defined;
• inappropriate team;
• ineffective controls;
• poor communication;
• unrealistic timescale.
They also point out that 80 per cent of UK companies whose projects
failed had no project management infrastructure. In the USA, the
Business Round Table highlights poor definition of project scope as the
primary cause of cost over-runs, followed by the loss of control during
design and execution.
The important concepts in the failure of a project:

Planning issues
Burnaby Lautier, of the Organisation for Project Management, at
Naarden, in The Netherlands, argues that being able to execute a project
according to plan is the exception rather than the rule. Echoing Garth
Ward's concerns about methodologies, Lautier regrets that "there are
many in our profession [project management] in quest of the ultimate
planning system that will end change-of-plans once and for all and allow
us to execute a project on time by just applying a method or a set of
tricks". In his view, "these persons are very unlikely to succeed".
Lautier believes that the best that a plan can do is give a firm a starting
point for later changes. In fact, contrary to many managers' expectations,
good plans change frequently.
Things that go wrong include:
• Plans are often made on the assumption of unlimited resources and

then remain uncorrected even when actual availability is known.
This leads to unrealistic expectations about finishing dates.
• Management can be careless about overloading available resources
in Lautier's view, if resources are overloaded by 10 per cent, you
can expect a 20 per cent delay.
• The use of over-sophisticated tools means plans get too big and too
detailed. Procedures and documents tend to slow everything down
and eat up attention, so they should be limited to the bare
essentials.
• Financial controls concentrate on cost, not time. Putting up
financial obstacles that make spending the money allocated to the
project difficult only creates delays that frequently cost much more
than the immediate amount of money involved. Once a decision is
made to execute a project, it should be possible to spend the
project budget without further difficulty.
• Many project control procedures compare progress to date against
the plan, even though this is the past and cannot be changed. It is
much more rewarding to look forward and try to spot forthcoming
difficulties that can be avoided by minor corrections ahead of time.
• In rapidly changing environments, plans can quickly lose touch
with reality and, when this happens, the project manager has to
improvise. Yet management still wants progress reported
according to the plan.
• Decision making is limited to predetermined decision points. As a
result, a lot of time and resources are wasted on projects that
should have been killed or changed much earlier
Decision points
Lautier argues that, contrary to their intended purpose, management
decision points are more likely to increase risk than to reduce it.
Designed to be the point at which decisions are made about whether a
project should continue, outside these predetermined points the project
proceeds at full-speed. In his view:
• Decisions can, and should, be made anywhere in the project and at

any time. By inserting a decision point, decision making becomes
artificially restricted to particular moments in time.
• At decision points the project is stopped until it is allowed to

continue. Yet decision making is an activity that consumes time
often quite a lot of it. As a result, the project team sits idle or,
worse, gets involved in other projects.
• Important decisions are necessary when something has happened

which requires the project to be reconsidered. There is, in Lautier's
view, no reason at all to wait for a decision point to come up.
Indeed, because disasters and problems arise randomly, important
decisions will very rarely coincide with a decision point.
So decision points actually create imaginary safety, waste valuable time
and mean that those responsible take decisions sporadically, "without
ever seriously considering the consequences of the complete project".
“A case analysis of business process outsourcing project

failure profile and implementation problems in a large
organization of a developing nation”
Results:
The results provide a pragmatic picture of the situation.
In light of the proceeding discussions, a number of interesting and
important issues have come from the analysis of the text data and the
key issues are presented here.
(1) First and foremost, considerable attention should have been paid to a
number of cultural and possibly political and environmental factors
which, in this case study, were viewed as impediments for the successful
adoption of IT outsourcing practices.
(2) Lack of top management support, which resulted in the failure
outcome of the IT project.
(3) Lack of user participation and involvement.
(4) Vendor brought different heterogeneous consultants and different
development teams, consisting of people with many diverse cultural
backgrounds.
(5) Lack of IT experience in dealing with the vendor (managing the IT
outsourcing relationship).
(6) Business and system functional requirements were not specified in
detail and were not clear (i.e. inconspicuous or vague).
(7) Over-reliance on a single supplier (i.e. vendor).
(8) There was no formal and systematic evaluation methodology on the
IT outsourcing during the contract lifetime.
(9) Contract type was “time and material”, which was not highly
detailed and designed to reduce uncertainty during the lifetime of the
contract.
For example, if the client was not receiving the quality of service for the
value of money, it was suggested that would be a just cause for
enforcing penalty payments or, in extreme cases, an early termination of
the contract.
(10) A policy of rewards and penalties clauses and existing
arrangements, which should be tied to the fulfilment of the contract
control, was missing from the original contract.
(11) No request for proposal (RFP) was issued so that the vendor had
understood fully what to deliver.
(12) Alpha was often not clear about the type of the desired IT systems
being
analysed and designed.
(13) Alpha accepted the agreement/contract given to them by the vendor
(Omega), which protected the vendor and reserved his rights more than
the client. This is largely due to the lack of experience in drafting
contracts with the IT outsourcing deals.
(14) Lack of IT project management expertise from both the parties.
A case analysis
755
(15) Poor IT management is also considered to be an impediment in the
successful adoption of IT outsourcing practices.
(16) Lack of good communication between all staff involved with the
project was felt to be very important, as the project was managed by a
variety of people originating from different cultures.
(17) Vague implementation timetables.
(18) There was no outsourcing advisor to the client, Alpha.
(19) There was not a very detailed and clear service level agreement
(SLA).
(20) Lack of communication of the importance of standard operating
procedures.

Final of Project Failure

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Final of Project Failure

Uploaded by

Copyright:

Available Formats

Department of business

Total Quality Management Project by

Failure of the project:

What are the causes of failure of Project?

2. Rushing leads to poorly defined goals at the project’s inception.

4. A sense of urgency encourages poor communication.

5. Feeling the crunch, the planning effort is reduced or skipped entirely.

6. Other departments fail to support the project creating delays.

7. Continued breakdowns trigger blame and finger-pointing.

8. Scope expands as customers request additional features.

A bottom to top list for the failure of project:

9. I’ll get to it as soon as I extinguish the flames.

8. I was constrained by the 24-hour-a-day limit.

7. I felt I needed additional criticism.

6. The rest of my team had a golf emergency.

4. I thought, “Are you crazy?” was a health question.

3. You wanted it when?!

2. We might have done better if we knew what it was. Poorly Defined

Figures collected by the UK's Industrial Society in the early1990s, show

The important concepts in the failure of a project:

Things that go wrong include:

• Plans are often made on the assumption of unlimited resources and

• Decisions can, and should, be made anywhere in the project and at

• At decision points the project is stopped until it is allowed to

• Important decisions are necessary when something has happened

“A case analysis of business process outsourcing project

You might also like