Final of Project Failure

8/6/2019 Final of Project Failure

http://slidepdf.com/reader/full/final-of-project-failure 1/9

Total Quality Management Project by

Department of business

administration



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

http://en.wikipedia.org/wiki/Condition

http://en.wiktionary.org/wiki/success

http://en.wikipedia.org/wiki/Fracture

http://en.wikipedia.org/wiki/Condition

http://en.wiktionary.org/wiki/success

http://en.wikipedia.org/wiki/Fracture



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 projectdoes not get the degree of success it deserves and gets fail. The projectwhen fails then there are certain reasons which are responsible for thefailure 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 “setup 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 thesame territory, are dominated by a few people, and fail to produce or complete action items.

http://en.wikipedia.org/wiki/Forensic_engineering

http://en.wikipedia.org/wiki/Forensic_engineering



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 DefinedGoals

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 theproject related to different researches:

“Management's role in project failure”

What goes wrong?

Figures collected by the UK's Industrial Society in the early1990s, showthat 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 quotesthe 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 projectsfailed had no project management infrastructure. In the USA, theBusiness 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 projectaccording to plan is the exception rather than the rule. Echoing GarthWard's concerns about methodologies, Lautier regrets that "there aremany in our profession [project management] in quest of the ultimate

planning system that will end change-of-plans once and for all and allowus 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 andthen remain uncorrected even when actual availability is known.This leads to unrealistic expectations about finishing dates.

• Management can be careless about overloading available resourcesin Lautier's view, if resources are overloaded by 10 per cent, youcan expect a 20 per cent delay.

• The use of over-sophisticated tools means plans get too big and toodetailed. Procedures and documents tend to slow everything downand eat up attention, so they should be limited to the bareessentials.

• Financial controls concentrate on cost, not time. Putting upfinancial obstacles that make spending the money allocated to the

project difficult only creates delays that frequently cost much morethan 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 againstthe plan, even though this is the past and cannot be changed. It ismuch more rewarding to look forward and try to spot forthcomingdifficulties that can be avoided by minor corrections ahead of time.



• In rapidly changing environments, plans can quickly lose touchwith reality and, when this happens, the project manager has toimprovise. Yet management still wants progress reportedaccording to the plan.

• Decision making is limited to predetermined decision points. As aresult, a lot of time and resources are wasted on projects thatshould have been killed or changed much earlier

Decision points

Lautier argues that, contrary to their intended purpose, managementdecision 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 atany time. By inserting a decision point, decision making becomesartificially restricted to particular moments in time.

• At decision points the project is stopped until it is allowed tocontinue. Yet decision making is an activity that consumes timeoften 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 happenedwhich requires the project to be reconsidered. There is, in Lautier'sview, no reason at all to wait for a decision point to come up.Indeed, because disasters and problems arise randomly, importantdecisions will very rarely coincide with a decision point.



So decision points actually create imaginary safety, waste valuable timeand mean that those responsible take decisions sporadically, "withoutever seriously considering the consequences of the complete project".

“A case analysis of business process outsourcing projectfailure 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 thekey issues are presented here.

(1) First and foremost, considerable attention should have been paid to anumber of cultural and possibly political and environmental factorswhich, in this case study, were viewed as impediments for the successfuladoption of IT outsourcing practices.(2) Lack of top management support, which resulted in the failureoutcome of the IT project.(3) Lack of user participation and involvement.(4) Vendor brought different heterogeneous consultants and differentdevelopment teams, consisting of people with many diverse cultural

backgrounds.(5) Lack of IT experience in dealing with the vendor (managing the IToutsourcing relationship).(6) Business and system functional requirements were not specified indetail 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 theIT outsourcing during the contract lifetime.(9) Contract type was “time and material”, which was not highlydetailed and designed to reduce uncertainty during the lifetime of thecontract.



For example, if the client was not receiving the quality of service for thevalue 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 existingarrangements, which should be tied to the fulfilment of the contractcontrol, was missing from the original contract.(11) No request for proposal (RFP) was issued so that the vendor hadunderstood fully what to deliver.(12) Alpha was often not clear about the type of the desired IT systems

beinganalysed and designed.

(13) Alpha accepted the agreement/contract given to them by the vendor (Omega), which protected the vendor and reserved his rights more thanthe client. This is largely due to the lack of experience in draftingcontracts with the IT outsourcing deals.(14) Lack of IT project management expertise from both the parties.A case analysis755(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 avariety 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

Documents

Transcript of Final of Project Failure