Project Management Failure

The development and design of a project requires skills that range from soft people skills to sophisticated technical skills. This study looks at the main reasons for project failure, and analyzes whether they pertain to soft or hard skills. Before discussing the reason for project failure, it is important to define “failure” in the context of project management. Understanding Failure Failure does not always have to be negative; it can be a positive experience if the procedures involved in the failure are analyzed and corrected.

If one does something always right, there is no opportunity for learning.

Failure gives opportunity for learning from previous mistakes; therefore, improving the decision making process. “When one does something right, one only confirms what is already known: how to do it. A mistake is an indicator of a gap in one’s knowledge. Learning takes place when a mistake is identified, its procedures are identified and it is corrected” (Ackoff 1994). The idea is to take advantage of the failure and turn the negative feeling around by analyzing what went wrong and 1 correcting it for future times.

In project management, a project is onsidered “failure” when results don’t match initial objectives; common reasons for project failure are budget overruns and time overruns. Understanding why projects are not completed on time and/or go over budget can help correct the problem. For instance, a recent study conducted by Spikes Cavell (Lytinen 1999) shows that a successful practice to overcome time overruns is implementing meeting milestones. Analyzing failure is not always that intuitive, so PMs are starting to apply the system failures method to information systems analysis to prevent project failures.

Get quality help now

Writer Lyla

Verified

Proficient in: Behavior

5 (876)

“ Have been using her for a while and please believe when I tell you, she never fail. Thanks Writer Lyla you are indeed awesome ”

+84 relevant experts are online

Hire writer

The Systems Failure Method The aim of the Failures Method is to investigate some identified failure to learn what aspects of the situation may have led to the failure occurring. The investigation consists of comparing “ideal” models against the real-life failure situation. This comparison is expected to reveal discrepancies between the two, highlighting areas of concern. These discrepancies can then be interpreted in relation to the failure situation and conclusions can be drawn. (West 1998) Investigating whether failures can be avoided, or reduced by some degree, is certainly a worthwhile effort.

Studies suggest that most IS project disasters are avoidable (Heekens 2002). Many times, warning signals occur long before an information systems project has begun to fail. History has shown that software projects are far more likely to be successful if they are highly focused and built upon well-understood technology (Heekens 2002).  This study was designed to identify the main causes for project failure. Interviews with Project Managers from General Dynamics Systems Integration Management Office (SIMO) were conducted.

Data gathered from interviews was analyzed and corroborated with previous surveys and case studies on project failure. Sample Selection In order to find out common reasons for IS/IT projects failure, Project Managers from the SIMO office were interviewed. Participants were composed from a diverse socioeconomic background including Black, Hispanic, and White. Their ages ranged from 30 – 55 years old. Each participant had at least five or more year’s experience in his or her profession. Procedure The interviews took place during August – September 2002.

The interviews were conducted in person during lunch breaks. Project Managers were given a survey (shown in Appendix A), and asked to list the main reasons for project management failure. Later individual appointments were scheduled to discuss answers in more detail. Results were then combined and analyzed. A table containing the most frequent causes for project failure was produced (See Table 1 – Discussion Section). The table serves as a discussion tool, and it shows the type of skills (soft or hard) related to the reason for failure. Common reasons for project management failure are discussed and analyzed in detail. Discussion points are reinforced with statistical data. Limitations Unfortunately General Dynamics does not require Project Managers to have any type of formal Project Management training, so most PMs have little knowledge of Project development techniques and models. General Dynamics’ main customer is the US Armed Forces; therefore some requirements are unique. A larger sample is required to include other companies that have customers from different industries.

Farther research could include companies from other countries as well.  Managing people Managing a project is not just about accomplishing tasks, but getting people to accomplish the work. One of the major challenges for a Project Manager (PM) is managing people. Most Project Managers have the technical skills required to manage a particular project, but not everyone has the interpersonal skills required to manage people successfully.

A PM has to communicate with people inside and outside the organization, and be able to speak their languages. When dealing with top management and stakeholders, the PM should address how the system will contribute to business objectives, and highlight initial investment and return on investments figures. They want to hear the project in terms of profits to the company. Their reason for launching a project is to make money or to save money, so the PM should focus on the financial aspect of the project. When dealing with team members, the PM is esponsible for fostering teamwork. Usually the team consists of people from different departments who have their own priorities, and departmental interests. The PM faces the challenge of getting team members to share a common objective and focus on what is best for the project itself and not each individual department. For a project to be successful, everyone should pull in the same direction and towards the same vision. According to Fortune (1997) “You don’t get people to buy into a vision, you get them to enroll”. Once again, it is on the 5

PM to inspire team members to take ownership of the project and do their best to lead the project to a successful completion. When dealing with engineers, scientists, and computer experts, it is crucial for the PM to remain focused on the business objectives. It is very easy to lean towards the state of the art technology, even if it does not add value to the business. The PM has to look at the system technology from the business perspective. If it does not contribute to the efficiency of business processes, there is no need to spend the extra money.

In 1998, the French computer manufacturer and systems integrator, BULL, contracted an independent research company to conduct a survey in the UK to identify the major causes of IT project failure in the finance sector (Linberg 1999). Interestingly enough the survey reveals the major causes of project failure during the lifecycle of the project are a breakdown in communications (57%), a lack of planning (39%) and poor quality control (35%). See Chart 1. Chart 1 6 The Organizational Challenge Most companies have some type of hierarchical organization, which may undermine the authority of Project Managers (PMs).

For instance, having PMs report to a section leader, who is under a team chief who reports to a department manager who also reports to someone higher, may delay communication among team members from different departments. Ideally, PMs should be able to control the company’s resources needed to accomplish their projects, and directly supervise their teams. Unfortunately, in the real world PMs have little or no authority, so they have to rely on the official process for communicating their needs across the organization.

This cross-organizational communication can result in delaying project tasks, which can ultimately bring the project to failure. The field study conducted in the General Dynamics Systems Integration Management Office (SIMO), Project Managers were asked to give the most common reasons for project failure. Survey results indicated that 75 percent of Project Managers are unhappy with the current structure of the company, and list it as the top reason for not accomplishing their projects on time.

General Dynamics is broken down into departments; each department has its own manager, and the department is further broken down into sections managed by section supervisors. See Chart 2. 7 Site Manager IT Manager Engineers Dept. Training Division Personnel Manager Acquisitions Systems Integration Office Chief Project Manager Project Manager Project Manager Project Manager Chart 2 General Dynamics Partial Organization Structure The System Integration Management Office (SIMO) has a team chief who is responsible for communicating with other sections and departments.

When interviewed Project Managers pointed out the inefficiency of going through the team chief to coordinate tasks with other departments. As Project Managers, they believe that a flat organization would be the ideal because they would have the authority to contact other key players themselves. By coordinating the tasks themselves, they increase the accuracy of the information, and make changes in the schedule as needed. More than 50 percent of General Dynamics Project Managers attribute the success of their projects to the good personal relationships at work.

In most cases, they don’t follow official communication channels. They establish good relationships with people from other departments, and approach them directly whenever they need to get the job done. This shows the importance of good interpersonal skills, but also reiterates the need for an organization structure that facilitates communication across the company. Lack of Resources Project managers face the challenge of coordinating the use of valuable resources when other people seem to have higher priorities. Not having control 8 ver resources can cause the project to fall behind schedule and subsequently to fail. A survey conducted by IT Cortex (Lytinen 1999), on “Reasons for Project Impaired Factors” conducted among 365 IT managers from companies of various size and in various economic sectors showed that lack of resources is one of the main reasons for project failure followed by lack of executive support. It is interesting to point out that lack of IT management and technology illiteracy was at the bottom of the list, showing soft skills superceding technical skills.

When competing for resources it is important to document the days and times resources are available, and try to accommodate the needs of the project during these times. Organizational skills play a very important role in managing resources successfully. Lack of Clear Vision and Objectives Not understanding the true needs of the company can prompt supervisors and project mangers to jump to a quick solution, decreasing the chances for selecting the best solution. Solution jumping can take place in the department where the problem/opportunity is identified, or by the Project Manager himself/herself.

An example of a department jumping-solution is when instead of describing the problem, a solution is drafted and turned into a project requirement. For instance in a manufacturing company, the head of the production department requests to start up a project for the creation of an additional production line to meet customers’ demands. Once the PM starts identifying the true needs, he/she realizes that the real problem lies in the existing production lines that are not performing at optimal levels. In this case, 9 the real need and perhaps the best solution to the problem is to focus on the other production lines first.

Sometimes the PM feels the pressure to get the project started right away without understanding the true needs of the company. Without this true understanding, it is very difficult to select the best solution to the problem. General Dynamics ensures its PM’s are familiar with the company’s needs by holding weekly meetings to discuss and debate new and ongoing projects, increasing the odds for selecting the best solution, and keeping projects on schedule (Heekens 2002). Banco Itamarati, a privately held Brazilian bank, attributes the success of its IT project to clear vision and documented specific objectives.

The company produced an annual net profit growth of 51% and moved from 47the to 15th place in the Brazilian banking industry (West 1998). Lack of Training – The “Accidental Project Manager” Phenomenon Researchers at Athabasca University’s Centre for Innovative Management in Alberta, Canada, conducted a global online study on project failure. As part of the study, a large-scale online survey was posted to key websites on the Internet and distributed via e-mail to 40,000 executives, project personnel, and consultants involved in managing or directing public and private sector projects. The researchers received 3,156 responses (7. % response rate). Results indicated that project failure dominates all sectors, and more than half of PMs have little or no formal training to deal with the complexities of today’s projects. (Res 2001) In addition, the study indicated that company executives continue to underfund project management; they view the job of a Project Management as 10 an add-on to an employee’s job description, thus creating “Accidental Project Managers. ” Furthermore, 75 percent reported that projects consistently came in late and over budget, and that management tools, techniques, and methodologies were rarely applied to projects.

Project Size A research study conducted by the Standish Group in shows that small projects are more likely to succeed than large projects. Typically, as project size increases, cost increases as well, and its chances of success decreases. Extra features and functions may decrease the likelihood of success. Results show that projects costing less than $750 K had a success rate of 55% while projects budgeted over $6M were successful only 8% of the time (See Chart 3). Some IS projects should be segmented into smaller subprojects to increase the likelihood of success.

Pilots can be used in this case as relatively inexpensive methods to provide a “proof of concept” for an application before additional resources are allocated. This is especially useful when it comes to the use of new technology. One of the biggest mistakes a company can make is using a new technology on a highly visible and large project. A $100 million project should not be started with any technology unless a $10 million project has used it first, and a $10 million project should not be conducted until a $1million project has been completed (Glass 1998). New technology is notorious for having software bugs.

Big projects should be broken down into small, low visibility projects, where problems are easier to address before it is unleashed on a larger project. 11 Success by Project Size Over $10M $6M to $10M $3M to $6M $1. 5M to $3M $750K to $ 1. 5M Less than $750K 0% 10% 20% 30% 40% 50% 0% 8% 15% 25% 33% 55% 60% Chart 3 Lack of User Involvement A Standish Group survey (2001) shows user involvement as the number one reason for successful projects followed by executive management support, and a clear statement of requirements. One of the participants in this survey was the IT executive manager from a Hyatt Hotel.

Hyatt implemented a system that allows customers to dial from a cellular airplane telephone at 35,000 feet, and check into your Hyatt room, schedule the courtesy bus for pick up, and have the keys to the room waiting at the express desk. This new reservation system was ahead of schedule, under budget, with extra features. Hyatt had all the right ingredients for success starting with user involvement, management support, clear requirements, proper planning, and small project milestones. 12 CHAPTER FOUR ANALYSIS AND DISCUSSION The results of compiling the main reasons for project failure from different surveys and case studies are hown in Table 1. Although no percentages are shown, the reasons are prioritized from most common to less common. It is also indicated whether they pertain to soft skills or technical knowledge. As shown in Table 1, the top two most common reasons for failure pertain to soft skills (lack of user involvement, and lack of management support), but there is also a good balance of soft skills and technical knowledge. This shows that both are important, and one cannot focus just on the soft skills or the technical knowledge. Managing projects is not all science.

Project management involves working with people, and getting people to accomplish the work. Common Reasons for Failure Lack of User Involvement Organizational Structure/Lack of Mgmt Support Lack of clear vision Unable to Manage Team Unable to Cope with Project Size Lack of Training Lack of Resources X X X X X Soft Skills X X X Technical Knowledge Table 1 – Common Causes for Project Failure From Most Common to Less Common 13 Lack of user involvement deals mainly with soft skills because the Project Manager needs to schedule appointments to interview users, and get them to buy into the project.

Sometimes project mangers can face resistance from users who do not like change. PMs have to use their interpersonal skills to assure users that they will benefit from the new system. In addition, it is important to make the users feel they are part of the project and their input is highly valuable for the overall success of the project. Organizational structure/lack of management support also deals with soft skills because Project Managers need to adjust to the company structure, and be able to find effective channels of communication.

In order to get all the key players involved, project mangers need top management support to schedule meetings, and to use the company’s resources. Lack of clear vision deals more with critical and analytical skills; the Project Manager is expected to understand project requirements, and convey these to the rest of the team. It is important to grasp the true needs of the company and to ensure that the project meets the business objectives. Unable to manage team deals with soft skills since Project Managers are in charge of getting the teams together and motivating every member to excel within the project.

Unable to cope with project size deals with technical knowledge and the ability to break complicated tasks into smaller manageable modules. Complex projects can be compared to math problems; solving complicated math problems requires breaking the problem down into small pieces, and solving it step-by-step. 14 Lack of training deals mainly with technical knowledge; Project Managers need to understand different models used for developing and designing systems; recurrent training is also important due to fast technological advances; knowledge of management tools is necessary to facilitate planning and tracking of project tasks.

Lack of resources can require both soft skills and knowledge of the systems. Competing for resources requires coordination with other users. This coordination can be accomplished by communicating the project needs well in advance. Scheduling resources also requires technical knowledge to know which resources are needed and when they can afford to go offline without inconveniencing other users. 15 CHAPTER FIVE CONCLUSION A Project Manager is like a bridge that links key pieces together, and in order to reach pieces effectively he/she needs to have a balance of soft skills and technical knowledge.

Some pieces need to be handled with soft skills, especially those that depend heavily on people to accomplish the work. Other pieces need to be addressed logically and precisely, such as instructions given to programmers and engineers for system implementation. Project Managers need to be able to learn quickly and become familiar with the needs of the company and the business objectives. It is important for a Project Manager to keep a positive attitude even when projects fail or are cancelled. Failure should be seen as an opportunity to learn what went wrong and could go wrong again if not corrected.