Why do project fails?

The

project team, the suppliers, the customers and other stakeholders can all

provide a source of failure, but the most common reasons for project failure are rooted in the project management process itself. Major causes of project failure are unclear project goals and objectives, and project objectives changing during the project as key factors in project failures. The following list the primary causes for the failure of complex projects:

Poor planning Unclear goals and objectives Objectives changing during the project Unrealistic time or resource estimates Poor schedule and cost estimation Lack of executive support and user involvement Communication breakdown Inappropriate skills Poor user input Stakeholder conflicts Poor architecture Late failure warning signals

Poor planning
Each and every project has a plan and a monthly, weekly, and daily task schedule. Sadly, it is not the norm. People are often seen working hard, but no one has plans -- because no one required them to make plans. It requires that a detailed plan be developed before any release date is ever announced. Even worse, some project managers often do not plan because they fear any plan they put together won't meet the [desired release] date. Even though

detailed planning saves an enormous amount of time in the long run, many managers and developers believe it to be unnecessary. They seem to think time spent on things like planning, design, requirements, and inspection gets in the way of real work, which is coding and testing. Every project involves some degree of risk. Not doing an explicit risk calculation is one of the major problems with project planning. In projects, project managers often do not know what level of risk they are taking when they make a plan because they have not set up the necessary processes to calculate and inform the risk

Unclear goals and objectives

Sometimes

the goal of a project may be only partially clear due to a poor

requirement gathering in the definition stage of a project For example; it will apply for an organization that has decided to implement a computerized customer relationship management system to improve the quality and efficiency of customer care. It is also not clear how the computerized customer relationship management system will be used to improve customer care. And again the definition of customer care improvement is left up to the project participants. In this example, the scope and schedule of the project can not possibly be accurate because their objective is unclear. Defining clear requirements for a project can take time and lots of communication, but sometimes goals and objectives might be unclear because project sponsors lack the experience to describe what they really require.

Objectives changing during project

Many project managers had the feeling that their project would never stop growing. Projects suffer from two classical problems in project management:

Scope creep

Feature creep.

Scope creep refers to uncontrolled and unexpected changes in user expectations and requirements as a project progress, while feature creep refers to uncontrolled addition of features to a system with a wrong assumption that one small feature will add nothing to cost or schedule. Project managers not understanding project trade-offs will result in not making decisions regarding objectives on the basis of rational insight. Staying devoted to the initial requirement will result in failure when the requirement of a project changes more than one time.

Unrealistic time or resource estimate

Estimation mistakes of time or resource cause project related problems. One common problem during the creation of the Work Breakdown Structure is assuming that the time on task equals duration. The time on task is the time the task will take to complete without interruptions, whereas duration is the time the task actually take to complete including interruptions. Using the time on task to estimate schedule is one of the common mistakes made by project managers. Another common problem is using linear approximation when estimating schedule. For example, if you doubled the cows in a farm, you double your production of milk. The projects are beyond the scope of such approximations. Assume we have a large IT project using a team with a staff of one hundred people. Linear thinking would support the conclusion that increasing the people by 100 percent would decrease the schedule and increase the cost to approximately the same degree. In reality, doubling the staff produce a non-linear result.

Poor cost and schedule estimation

It is unfair to call a project a failure if it fails to meet budget and schedule goals that were inherently unattainable. Like all engineering endeavors, every software project has a minimum achievable schedule and cost. This problem occurs any time someone makes up a number and won't listen to anyone about how long other projects took. Projects are often intentionally underbid because of the attitude that putting a development team under sufficient pressure can get them to deliver almost anything. It is true that pressure can increase the quantity of results one receives, but, after a point, dramatically reduces the quality of those results. In fact, pressure sometimes produces the opposite of its intended effect. For example, if a program should realistically take five programmers one year to complete, but instead you are given four programmers and eight months, you will have to skimp on design time and on quality checks to reach project milestones. Cutting a corner that undermines the entire foundation of the project is not cutting the corner. There will almost certainly be heavily disproportionate costs downstream.

Lack of executive support and user involvement

The research companies and academic institution has focused on the lack of executive support and user involvement as two main difficulties in managing projects. The project manager is the interface between the business and technology sides of the company. Without executive support project managers in the organization find difficulty in aligning business with their projects. The executive management also needs to be straightforward if they have reservations about the project. Otherwise, once problems are encountered in the project their support will weaken.

Most IT projects will change the work life of many users and require that they participate in design and implementation. Without user involvement nobody in the organization feels committed to the project. User involvement requires time and effort, but the staff might be already stretched and unable to find time for a new project on their schedule. That is why executive management support is important to make priority clear to the staff.

Poor user input

Project fails because the system did not meet user needs. The designers and the developers of the system had received most of their requirements from higherlevel supervisors and so-called "users" that were not regularly using the existing system. Although "not invented here" syndrome contributed to the systems eventual lack of acceptance, the bottom line is that the system was inadequate for its environment. A project should develop successful programs in which end users and developers work together, sometimes even in the same cubicle. Although this is not always possible, projects are likely headed for trouble unless informed end users are giving meaningful input during every phase of requirements gathering, product design, and programming. The input needed by these users has less to do with issues like how the website or application system looks or works internally than with how the system would be used in the field. Throughout development, users should be asking, "How do I use this thing over time? Does it provide the right tools? What do I put into it, and what do I get out?" However, there can also be problems if the users are too close to the requirements. If users dont consider the consequences of what they are requiring, they may actually steer the project into dangerous waters. Often, uninitiated or poorly directed users assume that how things were done in the pastas how they would always be done in the future. Worse still, users often confuse a consultants technical expertise with their ability to understand more

than they do about the users' jobs a failure that is not entirely the users fault. This need continues throughout development process. Without this understanding, the parties "don't even know what questions to ask and important issues fall between the cracks.

Stakeholder conflicts
The stakeholders had worked under the illusion that everyone was going to get everything that they wanted. They papered over their differences rather than going through conflict resolution in the early stages. The developers exposed the stakeholders irreconcilable differences because programmers cannot create an ambiguous system. Stakeholder conflicts can play many different roles project failures. Often, stakeholders have personal reasons for not being able to work together. Other projects fail because the developers do not know who the "real" stakeholders are. . Many projects fail because the project leaders do not have absence of who will ultimately declare whether a project is a successor failure, and then they are "blindsided." The true stakeholders need to hear good and bad news in "small pieces" rather than in "one chunk."

Inappropriate skills
this one is obvious, but often overlooked. You must have the right people to do the right job. Theres no getting around it. Programmers need to have experience in the technology before you can count on them, so select them wisely. Furthermore, managers can perform poorly if they lead projects that do not match their strengths. Projects dealing with high technology need managers with solid technical skills. In such projects, authority must reside with people who understand the implications of specific technical risks. However, the best technologists are not necessarily always poised to be the best managers. The skill set for management and programming are disjoint. The

larger the project, the more need there is for people with excellent planning, oversight, organization, and communications skills; all excellent technologists do not necessarily have these abilities. The solution to skill-driven challenges is easy to define but difficult and expensive to accomplish: Attract and retain the most highly skilled and productive people. You get what you pay for. The challenge of global competition, the rapid growth of knowledge, and the constant changes of technology make it hard to predict what kind of skilled people will be needed. Most projects require a diverse range of skills. Many teams lack the breadth, and depth they require. It is also not easy for technology based organization to find the experienced people they need because sometimes few people in the labor market have the necessary skills. The larger the project, the more need there is also for people with excellent planning, oversight, organization, and communications skills; experienced technology skilled people do not necessarily have these abilities.

Communication breakdowns
Projects sometimes fail due to improper communication. Communication problems are common on large projects. Because complex projects often involve large amount of analysis and work, the project teams are busy and the executive management sees no progress. Project managers do not communicate progress regularly because they believe that progress will not be seen by the executive management. There is a direct relationship between the size of a project team and the difficulty in keeping all members of that team up to date on changes, progress, tools, and issues. Such problems are common on large projects, especially if people are working at different sites. In many troubled projects there isn't one person who

has an overview of the whole project. Each project member needs to know how his or her one piece fits into the entire architecture. There must be a team for every task and each of these smaller teams has a manager, who is herself part of a management team. In extreme cases multiple management teams exist and an executive team is formed. The focus of each team, especially the development team, is strictly enforced and rigorous in definition.

Poor architecture
People must think ahead about what is likely to change. Software developers often build with no more forethought than the man who built a beautiful boat in his workshop and then could not get it out the door. If you do architecture right, no one will ever realize it, but if you do it wrong, you will suffer death by a thousand cuts. Bad choices show up as long-term limitations, aggravation, and costs. There must be flexibility to adapt the day to day change.

Late failure warning signals

A schedule and budget are determined by edict by people you were afraid to say no to -- and it is politically unwise either to say or show the estimate is far from achievable. All your early milestones involve diagrams, designs, and other documents that do not involve working code. These and other project milestones then go by more or less on scheduleat least as far as upper management can telland testing starts more or less on time. Not until the project is a few weeks from deadline does anyone dare inform the "edict makers" that at the current defect detection rate, the project will not be completed even close to its deadline. Nobody seems to acknowledge that disaster is approaching even among people who sense there is a problem. There is no early warning signal. Until more organizations abandon waterfall-style development in favor of processes that

demand early working code or prototypes, this scenario will continue to be familiar.

Conclusion
The past failure need not discourage project managers from future efforts. Project managers can position themselves to reduce the possibility for project failure by considering the following recommendations: The project manager must plane before continue the project. Sets the objective rigorously and clearly. The project manager must make the project flexible to accept the changing requirements. There must be a proper project team and an executive body to run the team. The project manager must be cooperative, and try to less the communication gap. There must be proper allocation of cost, time and resources .proper architecture is necessary for every project.

Sub: Topic:

project management why do project fails

Submitted to

Sir. Amir Aziz

Submitted by

Kiran Munir

MBA 016(A)

Date 20th Feb.2008

CECOS UNIVERSITY OF MANAGEMENT & INFORMATION SCIENCES.