Failed IT Projects (The Human Factor) Sheila Wilson University of Maryland Bowie State University 16 May 1998 Abstract

In this technological explosion today, large amounts of funds are directed towards information technology (IT) software development. Despite the enormous advances in the IT industry, there are still many failed IT projects. Several factors contribute to the failure of IT software development projects. One of these is the human factor. These research focuses on the team aspect of the failure of IT software developments. Supporting information was gathered from several sources, including magazine articles, Internet sites, surveys, and personal interviews. The results provide insight as to why teams fail on IT software development projects. Table of Contents Thesis Statement Introduction Background Information Methodology Case Studies Success and Failure Profiles Personal Interviews & Comments Survey Results Reasons for Failures Overcoming Team Failure Team Failure Checklist Conclusion Bibliography Thesis Statement 4 6 7 7 8 10 14 16 19 20 26 28 29

Several factors contribute to the failure of Information Technology (IT) software development projects, and I believe understanding the reasons why a team may fail on a project will assist IT professionals and senior management in preventing the same mistakes from recurring, thus improving efficiency and decreasing costs. Introduction In this technological explosion today, large amounts of funds are directed towards information technology (IT) software development. Despite the enormous advances in the IT industry, there are still many failed IT team projects. Knowing the common underlying problems that cause most IT team projects to fail will help teams avoid making those same mistakes over and over. It may also enlighten teams with techniques that work. Researching the causes of several team projects that failed will provide insight for future IT team project development. It is inevitable that history will repeat itself if the history is unknown. This may cause disastrous and costly consequences. Spending these large sums of money on IT does not necessarily equate to money well spent. These failed IT projects are costing companies billions of dollars every year. These dollars could better serve these companies if more attention is focused on why these failures occur so that repeated mistakes could be avoided. Several factors contribute to the failure of IT software development projects. One of these is the human factor. McConnell (1998) states that "Peopleware [DeMarco and Lister] drives home the message that programming is first and foremost something done by people and only secondarily happens to involve computers." Examining the human factor will provide valuable information to IT teams and other IT personnel, as well as corporate management. This information could improve the companys chances of succeeding in the future with IT software development and IT teams. The cost savings alone should make management interested in this ongoing expensive problem. It also may increase the chances of aligning IT with the business needs of the company, which in turn may provide the company with a possible competitive advantage. Background Information Most software development projects fail because of failures within the team running them. Before a team project can be labeled as failed, the term failed must be defined. For the purpose of this research, a failed software development project is defined as (1) being over-scheduled by more than 30% and/or, (2) being over-budget by more than 30% and/or, (3) the end product did not meet user requirements. These three criteria cover the schedule, budget, and requirement, all surrounded by quality that should comprise all projects. A failed project does not include canceled projects relating to changes in requirements that resulted from changes in business needs. The focus of this research is on the project team problems of these failed projects, thus resulting in team failure.

Figure 1. Project Criteria Methodology In performing the research, information was gathered primarily from magazine articles, books, Internet sites, personal interviews, and surveys. For the purpose of this research, thorough survey findings were gathered from already performed case studies. Personal interviews with a selection of individuals were conducted for input. In addition, a random survey was sent to a select few companies and individuals for their input on failed IT teams in application development projects. The personal interviews and surveys were conducted to use as supporting information. Team failure is related to project failure; therefore, this research includes information on both. Case studies on project failure are included, with the relationship of the human factor. Case Studies KPMG, Canadas largest professional services organization, performed an in-depth study on failed projects. "Considering that an estimated $25 billion is spent each year on IT application development in this country [Canada], the KPMG findings paint an alarming picture of projects mismanagement in both private and government sectors." (Newswire, 1997). Following are some of the human factors that were included in this research. In the area of project management, the project teams ranked number two in contributing to project failures when the failure was mainly due to schedule and cost overruns. When the failure was mainly due to budget overruns, the project manager was a significant factor. The lack of the necessary skills and/or expertise ranked second in the major factors that contributed to failed projects (KPMG, 1997). The turnover of essential personnel who were part of the project team, such as the project manager, was identified as one of the major problems. The study performed by KPMG stated that 38% of the respondents identified the change in essential personnel as a risk, and they ranked this factor as number four. A team may fail due to the low skill level of the team members. For example, the Federal Aviation Administration had a software development team working on a system to replace the antiquated air traffic control system. The system, the Advanced Automation System, had numerous bugs after over ten years of development. The software was too unreliable to trust for

life and death situations; it was also six years late (Joch, 1995). This project failed in part due to unskilled and under-skilled team members. Uncommitted team members also are a reason for failed IT teams. Silicon Graphics released a software application with over 500 serious bugs. Morale within the team was very low and the bug count high. The task of meeting the projected schedule, which was nine months away, was impossible. Management responded by hiring two contractors who were strangers to companys software and the organization. The result was disastrous (Joch, 1995). This team also failed due to the inappropriate allocation of team members. Management and the IT industry still have not learned the lesson that more bodies at the end of a project do not equate to a condensed schedule to meet an already unrealistic deadline. It only complicates matters. Lack of knowledge and skill of the project team member seems to continue to be a recurring problem with the software development projects. The Foundation of Research in Information Technology (FRIT) is studying obstacles to the Revenue Departments Bt 1.8 billion IT project, the largest in the country of Thailand. "Due to numerous problems, IBM (Thailand), which was overseeing the implementation of the computer system, asked to terminate the project and Cabinet agreed" (Sutharoj, 1998). As part of the plan to prevent such future disasters, the foundation is helping the Computer Association of Thailand set standards for local programmers and analysts. This plan includes raising the quality of local IT personnel to international standard. This is another example of unskilled team members and not having a structured method for software development. The project size usually has a direct relationship to the team size. Sixty percent of the small projects failed, where a small project is a project that was scheduled for completion within 12 months. Almost all of the respondents reported these 60% of failed small projects went over schedule (KPMG).

Figure 2. % Of Failed Small Projects over Schedule In addition, custom-developed applications were associated with serious budget and schedule overruns. Of the KPMGs respondents who went over 50% on their original budget and schedule, 69% of the projects involved custom-developed software applications, which was the number one type of application that failed. A 1995 U.S. study by the Standish Group showed that 31% of software projects would be canceled before they ever get to the completion stage, and 53% will cost a staggering 189% of

their original estimates. KPMGs study indicates that the failure rate in Canada is just as high, posing a serious and ongoing problem for CEOs and senior managers. Success and Failure Profiles One of the most important aspects of the Standish Group research was to discover why projects fail. They surveyed IT executive managers for their opinions about what causes projects to succeed, what causes projects to be challenged, and what causes impaired projects. Below are the results of this survey (Standish Group, 1995). Project Success Factors 1. User Involvement 2. Executive Management Support 3. Clear Statement of Requirements 4. Proper Planning 5. Realistic Expectations 6. Smaller Project Milestones 7. Competent Staff 8. Ownership 9. Clear Vision & Objectives 10. Hard-Working, Focused Staff 11. Other % of Responses 15.9% 13.9% 13.0% 9.6% 8.2% 7.7% 7.2% 5.3% 2.9% 2.4% 13.9%

Human resources were not the top factors that determined the project success. Competent staffs ranked number seven and hard-working, focused staff ranked 10. Success is classified as the project is completed on time and budget, with all the features and functions as initially specified. Project Challenged Factors 1. Lack of User Input 2. Incomplete Requirements & Specifications 3. Changing Requirements & Specifications 4. Lack of Executive Support 5. Technology Incompetence 6. Lack of Resources 7. Unrealistic Expectations 8. Unclear Objectives 9. Unrealistic Time Frames 10. New Technology 11. Other % of Responses 12.8% 12.3% 11.8% 7.5% 7.0% 6.4% 5.9% 5.3% 4.3% 3.7% 23.0%

The human factor was one of the midrange factors for the projects that were challenged. Lack of resources ranked number six. Challenged is classified as the project that completed and operational but is over budget, over time estimate, and has fewer features and functions than originally specified. Project Impaired Factors 1. Incomplete Requirements 2. Lack of User Involvement 3. Lack of Resources 4. Unrealistic Expectations 5. Lack of Executive Support 6. Changing Requirements & Specifications 7. Lack of Planning 8. Didn't Need It Any Longer 9. Lack of IT Management 10. Technology Illiteracy 11. Other % of Responses 13.1% 12.4% 10.6% 9.9% 9.3% 8.7% 8.1% 7.5% 6.2% 4.3% 9.9%

The human factor played a significant role in the impaired projects. Lack of resources ranked number three, and technology illiteracy ranked 10. Impaired is classified as the project is canceled at some point during the development cycle. There seemed to be a direct relationship between project failure and the human factor contributions. The larger the failure, the more the human factor contributed to that failure. This is more evidence that most software development projects fail because of failures within the team running them. This study concluded that the success rate was only 16%, challenged projects accounted for 53%, and impaired for 31%. (Standish, 1998). Lack of resources seems to be a major contributor in why teams fail. Without the necessary staff, it is very difficult to manage the project team effectively. With a large percentage of the projects being challenged or impaired (84%), the human factor should not and cannot be ignored by the IT industry as a problem that needs to be addressed. Otherwise, the current problems will continue to repeat themselves in this fast-growing industry.

Figure 3. Projects Profiles Personal Interviews and Comments Communication can make or break a project team. This includes communication among team members as well as communication between the project manager and the rest of the team. Communication may come in many different forms and cause problems within the team (e.g., failure to deal with problems). "Failure to deal with a problem employee is still the most common complaint that team members have about their leaders. At best, failure to deal with problem employees undermines the morale and motivation of the rest of the team. At worst, it increases turnover among the good developers and damages product quality and productivity." (McConnell, 1996.) Having the appropriate number of team members helps make the project run smoother, with fewer unrealistic deadlines. More work is placed on the already overworked team members when there is not enough people allocated to the project. Then shifting of staff occurs, which disrupts the team structure and harmony. A ripple-down effect occurs. The team suffers, which results in the project suffering. One survey respondent stated that "The organization was successful in restructuring the project team and bringing in senior technical leaders to the project. The team is generally meeting its deliverables, but still suffers from extensive team member turnover." The hard reality is that there is a severe shortage of trained IT professionals. Repeatedly, the issue of untrained, unskilled team members has caused the detriment of the project team, as well as the project. Another individual stated that "Management always threw too many people on a problem after it was discovered that the project would not meet a deadline. This caused even more problems because the new people had to be trained by those who already had too much to do. Of course this caused the schedule to slip even more." One respondent stated "The project. definitely came in well over-schedule. A major factor was employee retention. Due to the booming technology market, it is extremely difficult to retain highly skilled employees because they tend to opt for the money and a better opportunity elsewhere."

The lack of and the inefficient use of a structured method and tools are other reasons for failed teams. Yourdon reflects on a conversation he had with a group of managers. Yourdon (1997) states: Back in the summer of 1992, I had dinner with an amiable group of midlevel Microsoft managers. During the course of the discussion, I asked if it was common for Microsoft project teams to use such methodologies as structured analysis or object-oriented design. The answers ranged from "Sometimes" to "Ummm, I guess so" to "Not consistently" to "What's that?" And when I asked about the use of CASE tools (which were still fairly popular throughout the rest of the industry at that time), I was told that the common opinion of Microsofties was that such tools were for "people off the street." This was a term I hadn't heard before, but the rough translation is "ignorant savages who have just come out of the primeval forest and are just learning to program, unlike real programmers, who don't need no such artsy-fartsy tools." This is also a prime example of unskilled team members. The skill level of the team should be considered when planning the schedule of the development. The lower the skill level, the longer it will take to complete the task at hand because of the learning curve. Although the staffs skill level should be considered during the planning stage of the software development process, one may wonder if this actually happens considering the large number of failed projects and teams due to over scheduling. In addition, employees with the lower skill levels are many times placed on the small project teams. This may have a direct relationship to why over 60% of the small projects fail. Survey Results A random sample survey was sent to a few companies with software development teams. Each participant in the survey were asked questions relating to one (1) failed software development project that was due to the team problems. There was a 12% response rate. Of the responses that were received, the results are summarized below. SURVEY CATEGORY Industry type: Aerospace & Defense Computers & Electronics Government Legal & Tax Publishing X X X X X 1 1 2 1 Totals

Management Information Systems Number of employees in company: Less than 20 20-49 50-99 100-300 Over 300 Overall failure due to (check all that apply): Over-schedule Over-budget End product did not meet user requirements Other reasons for failure (RANK all that apply): Project team problems Poor project planning Lack of user requirements specifications Lack of senior management commitment Lack of user involvement Team problems that contributed to project failure (check all that apply): Lack of or insufficient communication between team members Lack of or insufficient communication with users Lack of use of structured method (i.e. SDLC method) Lack of appropriate application development tools Improper use of application development tools X X X X X 1 3 2 1 1 1 1 3 4 2 1 X X X X X X X

0 1 0 X X X 1 4

X X

X X X

4 2 3

3 4 5 1 2 1

1 1 1

5 5 5 3

X X X X X

3 3 2 2 0

Shortage of team members Uncommitted team members Unskilled team members Team contribution to project failure (check 1): 0-25% 26-50% Over 50% Size of team at start of project (check 1): 2-5 6-10 11-20 Over 20 Size of team at end of project (check 1): 2-5 6-10 11-20 Over 20

X X

4 1 1

X X

X X

4 2 0

X X

3 1 0

X X

2 1 0

From this unofficial survey, scheduling seemed to be the overall reason for most failed projects. Four respondents indicated that project team problems were part of the other reasons for failure. The top reasons for failures were somewhat evenly divided between poor project planning, lack of user requirements specifications, lack of senior management commitment, and lack of user involvement. Most of the responses ranked project team problems as least as the third highest reason for failure. Team problems ranked evenly among other factors in other cases. Although the human factor did not rank number one in all cases, it played a significant enough role that it should not be ignored. Specifically, team problems that contributed to failure included a variety of different problems. The largest problem, according to this survey, was the shortage of team members. Second was the lack of or insufficient communication between team members and with users.

This survey showed that the team's contribution to failure was generally under 26%. The size of the teams generally remained in the same range, except for one response. Because the number one reason for team problems was the shortage of team members, the size of the teams seemed to be too small for the projects in question. The respondent that indicated an increase in team members by over 15 did not indicate that team member shortage was a contributing factor for failure. The size of the team may have been increased at the inappropriate time, thus making the team size a problem still. For most of the survey respondents, the team size at the beginning of project was under 11 team members. Compared to the KPMG study, 60% of the small projects failed. Does this mean that most small projects will fail? It seems that the approach for small teams IT software development projects needs to be rethought to increase the success rate of these projects and teams. Incorrect assumptions about the resources for a particular project set the project and the team up for failure from the beginning. Fifty-two percent of the KPMG's respondents identified that incorrect assumptions regarding resource availability was a planning problem. This was second only to the incorrect estimated activity duration. Reasons for Failures Projects in general fail for various reasons. Several factors contribute to failed IT software development projects include:
y y y y y

lack of senior management commitment lack of user involvement lack of user requirements specifications poor project planning project team problems

The above factors also contribute to team failure in one aspect or another. However, some of the more specific reasons for the failure of teams include:
y y y y y y y y y

improper use of application development tools inappropriate allocation of team members lack of appropriate application development tools lack of or insufficient communication between team members lack of or insufficient communication with users lack of use of structured method (i.e. System Development Life Cycle method) shortage of team members uncommitted team members unskilled team members

Some of these factors were apparent in the survey that was conducted, as well as the detailed case studies and personal interviews presented in this research. Overcoming Team Failure

Effective team development is a contributing factor that a team needs to be successful as a team and to produce a product that meets the requirements. First, the team must understand the purpose of how the project fits into the overall business strategy of the company. This gives them a sense of ownership. There has to be commitment to the project by all team members. Each team member has to trust the others. Development as a team is crucial to the project and the teams ability to succeed. Effective communication is needed to discuss the problems with the project, handle conflicts within the team as well as with the users, day-to-day interactions, etc. Each team member has to have specific roles and take responsibility for those roles. Every team member has to be informed and involved in making decisions that affects the team. Team development assists in making a quality software project and greatly assist in producing a successful team. To have a successful team, the staff must be competent. Ways to help achieve a competent staff include identifying the skills required for the project; recruiting to match the skills identified with the correct personnel; developing a well-structured and continuous training program; and providing incentive awards. Incentives help insure a focused and dedicated staff. Make sure the incentives are tied to the projects success. This in turn promotes team and project success. Having a system where team members can easily transfer knowledge between each other is a good way to improve the team's competence. "This includes electronic documentation of tools and techniques, lessons learned, successes and failures, and innovative ideas. It includes educational sessions or sessions for face-to-face dialogue and learning." (Uhlfelder, 1998). The team must be able to work together. Concentrating on building an interactive and cooperative team makes the project run more smoothly. Conflicts within the team only cause problems, causes schedule delays as well as budget overruns.
Newswire (1997) states: Of failed projects, KPMG found that 60% were originally expected to be completed in a year or less, but the budget for these "small" projects was nearly $500,000, with a high of $3 million. Further, about 15% of failed projects reported a problem with vendor ability to meet objectives, timeliness or, sometimes, even to deliver a product. While vendors may overstate or overestimate their abilities, buyers can be equally at fault by setting their expectations too high. "The cost and waste associated with these failures is huge," says Kelly. "Through understanding the reasons behind the failure of software projects, we can take the first steps towards minimizing the risk of failure. Every senior executive should be learning from past mistakes and should be improving project management techniques to protect his or her organization from the staggering costs of IT project failures."

Retaining team members throughout the project plays an important part as to whether the project and the team will be a success. If the team size, skill level, and cooperation exist, changing the same team structure may cause many problems. First, retraining new team members is very likely to affect scheduling and budgeting. Members already on the projects have to take time out of their already too busy schedule to bring the new members up to date on the project status. This

decreases productive time spent on the project, and it increases the budget, schedule, chances for more mistakes, etc. "Success in software development depends most upon the quality of the people involved. [It] shows individual and team productivity to be the leading predictor in estimating software costs" (Webster, 1996). This is a problem in itself. With the severe shortage of IT professionals, not to mention high quality IT professionals, it is becoming increasingly difficult to find, hire, and retain the best people. Even within the organization, everyone is pulling for limited IT resources. This affects the moral of the team, as well as put more pressure than normal on them to complete their project so that another one can start. This may result in employee dissatisfaction. Employee satisfaction is the key to retaining the employee from other competitive companies. However, this is easier said than done. For example, team members are reassigned from one project to work on a higher priority project that lacks resources. They have to be trained, or at least briefed, on the new project he has been assigned. This hurts the project that lost the resource because there are fewer needed individuals working on the project. More likely than not, the person or persons that are reassigned are the best people on the project. The new project team is at a disadvantage because the new team member has to be brought up to date, thus using double resources on training. In the meantime, the new project is "wasting" resources by team members training team members. However, training new members is unavoidable when reassigning personnel. "Staff acquisition involves getting the human resources needed (individuals or groups) assigned to and working on the project. In most environments, the best resources may not be available, and the project management team must take care to ensure that the resources which are available will meet project requirements." (PMBOK, 1996). Management should try to correctly allocate resources before the project starts, or at least early in the development process. This may save on budgeting efforts and assist in better scheduling. When the budget and schedule are soundly in place, meeting the users' requirements is more easily achievable. This places less pressure on the team, which assists in giving the team a better chance of succeeding. The project managers influence how well the team will excel. They ensure projects are delivered on time and within budget and that they meet all customer expectations in the areas of functionality, ease-of-use, reliability, as well as all other contractual commitments. They ensure that customers meet their requirements in terms of deliverables, facilities, specifications and acceptance. They set goals for project team members, review performance and provide feedback. An effective project manager is a good leader as well as a manager. In addition, the project manager has to be dedicated to the team for it to survive. As project manager, "your behavior as a leader has a direct effect on your group. They take cues from your attitudes and actions." (Bick, 1997).

Having a shortage of team members was the most evident problem with the detailed case studies, interviews, and the survey. Management needs to address this ongoing problem. By resolving this, the number of failed projects and failed teams should decrease. There are several ways to decrease the shortage of IT staff. There needs to be a continuous training program. Due to the ever changing IT industry, without training the employees could fall behind technology quickly. These training should comprise of self-improvement (e.g., University level courses) and corporate training (e.g., refresher training for upgrade of software applications). Employee satisfaction is an important key to retaining the employee. Personal and professional development should be part of the employee's development plan. Matching the employee with the job and career they are seeking helps to retain him/her. If the employee have potential to grow within the company, he/she is more likely to remain loyal to the company. The company should provide and present incentives such as career advancement, skill expansion, and of course money, either in the form of bonuses and/or raises. Such incentives will insure the staff will be focused and more willing to stay. Each employee should be considered on an individual basis. Some may be happy by receiving verbal recognition, monetary awards, stock options, bonuses, health insurance, retirement plans, days off, etc. With the tremendous shortage of IT professionals, the company must consider training the employee once they are hired. This is crucial. Throughout this research, unskilled team members are a major contributing factor to failed teams. The effective training of new employees should be a high priority of management if they expect to decrease team failure on software development projects. A team member who knows what to do and how to do is an ingredient that must not be left out of the recipe for team success. Providing whatever it takes to make that employee satisfied enough to stay might be a challenge. "The demand for qualified information systems professionals won't soon decrease. The US Department of Labor estimates that new technologies will generate 80 percent of all new jobs in the next 10 years. The number of positions for systems analysts and computer engineers will double over the next 8 years. Therefore, management must have a strategy for finding, training, and retaining qualified people." (Smith, 1998). With the shortage of IT professionals, management must find ways to decrease the need for more employees. One way is making it easier for teams to reuse software from previous development projects. Software development tools, such as CASE tools, make it easier to do just that. If the development process is designed in such a way to make reuse of software feasible, the entire development process could be legitimately shorten. The number of team members needed for a project would decrease because of the effective reuse of already proven software. Another way to decrease the time needed to develop software is by reengineering the software development process. An example is using a software environment that automates the business rules of the company. This type of software development tool allows for separating all the business rules from the rest of the code. It "allows organizations to dynamically change the

business rules and quickly modify applications to keep pace with changing business environments, and ensure consistent adherence to business policies" (Platinum, 1998). An inference engine interprets when and how the business rules interact with the rest of the software applications. This eliminates the need to recreate business rules in each application development project. This also makes it easier to maintain and change applications when the business rules change. The manpower savings could be tremendous. The problem with this is it forces a complete cultural change in the way teams develop applications. Change takes time, and the process of changing is painful in many cases. The result may be a much more productive team, and teams that are more successful. Team Failure Checklist If you want to team to fail, start out by making sure the human resources are not adequate for the size of the project. Next, make sure the skill level of the team is not at the appropriate level. Then put uncooperative employees on the same team. Then put them all in an undesirable environment. This is one recipe for team failure. This may sound funny. You may wonder who would do such a fool-hearted action. Unfortunately, many IT teams are put together just so, and there are many recipes for IT software development team failure. If only they could all be compiled, placed in the cookbook for failed teams, distributed to all IT organizations, and used as guidelines as to what not to do, the IT world may be reformed to an even better industry. Several signs indicate potential team failure. The checklist below are some indications that management and the team should look for to try to prevent the team from failing:
y y y y y y y y y y y y y y y y y y y y y

Conflicting information from higher management Dismantling of team for higher priorities Little or no training for team Low morale within team Low skill level for team members Many team members leaving organization No communication between team members No group sessions among team No incentives to keep team motivated No one in charge No project manager interest No structured method for developing software Organization of team not working Shortage of team members Team losing sight of project goals Team member not being accountable for actions Team not physically located together Too many reassignments of team members Too much overtime Unavailability of needed tools Uncommitted senior management for project

y y y

Uninformed team members Unsuitable working environment for team Working with impossible or unrealistic deadlines

This is by no means a comprehensive checklist of what to look for to spot the potential for a team and/or project to fail. It does however, provide a start. No one sign will likely cause team failure. When seeing a combination of several indications together should alert management of potential risk of the team and project heading toward disaster. Of course, more signs directly relate to a higher risk of failure. These signs should be monitored and reported. Case histories should be reviewed to help prevent the recurring problems from reoccurring. This may help break the unfortunate history of teams failing for the same reasons repeatedly. The results of this research indicates the shortage of team members is a recurring problem; therefore, finding ways to overcome this problem should help considerably in eliminating failed IT software development teams. With over 60% of small teams failing, management should pay more attention to how small project teams evolve. Monitoring the signs on the above failed team checklist and taking corrective action should help in bringing the team and the project out of the danger of failing. The primary problems in software development are sociological and not technological. The Standish study shows that as a project fails, the human factor contributes a larger role in the failure. Because there are so many failures over successes, the human factor cannot be ignored if the problem is to be resolved. Successfully dealing with the human factor of IT software development is a great challenge for the entire IT industry. IT software development teams seem to make miracles happen with computers; however, we need to realize that we are only human. Conclusion This research provides valuable information for top management, IT application development teams, and the IT industry in general. It could help decrease the number of failed IT projects that are caused in part by the human factor by knowing what problems have occurred in the past. The risk of future failed teams could be minimized by knowing what to avoid. Knowledge begets wisdom; in this case, wisdom may generate huge cost savings. This benefits the company, as well as other stakeholders, in a very positive way. As stated by McConnell (1998), "No individual is a success who hurts the team, and no individual is a failure who helps it." Bibliography (1996). A Guide to the Project Management Body of Knowledge. Upper Darby: Project Management Institute. (1998). Main Causes for Projects to Fail. [On-Line]. Available: http://www.jgaudio.com/Project_Defined.html#Main Causes for Projects to Fail: (November 1997). Unsuccessful IT Projects A Major Cost To Economy: KPMG. [On-Line]. Available: http://ww2.newswire.ca/releases/November1997/05/c0838.html

(April 15, 1998). Platinum Technology Delivers the Next Generation of its Development Solution for Automating Business Rules in Enterprise Applications. [On-Line]. Available: http://nt.excite.com/news/bw/980415/platinum-aion Bick, Julie (1997). All I Really Need to Know in Business I Learned at Microsoft. New York: Julie Bick. Demarco, Tom, and Lister, Timothy (November 1987). Peopleware : Productive Projects and Teams. New York: Dorset House Publishing. Joch, Alan and Sharp, Oliver (December 1995). How Software Doesn't Work. [On-Line]. Available: http://www.byte.com/art/9512/sec6/art1.htm KPMG. (October 31,1997). What Went Wrong? Unsuccessful Information Technology Projects. [On-Line]. Available: www.kpmg.com McConnell, Steve (1998). Software Project Survival Guide. Redmond, Washington: Microsoft Press. McConnell, Steve (September 1996). Classic Mistakes. [On-Line]. Available: http://www.construx.com/stevemcc Pongpen Sutharoj, The Nation (March 1998). Failed IT Project To Be Turned Into Case Study. [On-Line]. Available: http://www.ostc-was.org/newsletter/0398_12.html Smith, Mark (March 1998). Training: A Manager's Perspective. Windows NT Magazine, p. 15. The Standish Group International, Inc. (January 1995). Chaos (Application Project and Failure. The Standish Group. (1998). Chaos. [On-Line]. Available: http://www.standishgroup.com/chaos.html Uhlfelder, Helene F., Ph.D. (1998). Teams: Why Are They So Difficult? [On-Line]. Available: http://millerhoward.com/articles/whyteams.htm Webster, Bruce F. (January 1996). The Real Software Crisis. [On-Line]. Available: http://www.byte.com/art/9601/sec15/art1.htm Yourdon, Ed and Becker, Paul (April 1997). Death March: The Complete Software Developers Guide to Surviving Mission Impossible Projects. Prentice Hall Computer Books. Yourdon, Ed (April 1997). Making Death March Projects Pay Off. [On-Line]. Available: http://www.datamation.com/PlugIn/issues/1997/april/04proj.html