A model for predicting the likelihood of failure of IT projects in federal agencies.
详细信息
- 作者：Speight ; Nathaniel.
- 学历：Doctor
- 年：2007
- 导师：Sibley, Edgar H.
- 毕业院校：George Mason University
- 专业：Computer Science.
- CBH：3255811
- Country：USA
- 语种：English
- FileSize：8120289
- Pages：149
文摘
The Federal Government has had very little more success than the private sector in implementing software projects. Indeed, a major problem with software projects is that there is no real way of even predicting failure of software projects before the outcome. This problem results in a major loss or late delivery of critical software. The work performed for my thesis was therefore initiated to attempt to determine a way to predict failure in some federal software system projects.;This work, therefore, started by identifying 15 critical factors associated with government software development IT project failures. These factors were identified by using experts and affinity groups whose discussion resulted in the following failure factors: (1) Poorly Defined Requirements - Requirements are not clear, complete, consistent, documented nor traceable. (2) Lack of Executive Support - Executive fail to communicate or provide support for the project throughout the project. (3) Poor Cost and Schedule Estimation - No formal estimating method used. Costs and/or schedules are unrealistic. (4) Poor Planning - No or inadequate project plans. Failure to break complex project into phases or small projects. No clear business objectives for the project. No or inadequate transition plan. Project objective or success criteria not well defined. (5) Poor Communication - No or inadequate communication plan. Team members do not have the information they need. Project reporting does not provide stakeholders and users with information they need. Users and stakeholders are not provided ample opportunities to provide input throughout the project. (6) Process Problems - No development methodology. First time using ISO 9000, Capability Maturity Model etc. or automated tools such as Rational Unified Process. No formal engineering approach to product integration. Inadequate quality control and assurance. Inadequate product acceptance process. Inadequate configuration management. (7) Poor Risk Management - Little or no formal risk management. No risk management plan. (8) Poor Change Management - No change management process used and followed by the project team. Scope creep is a consequence. (9) Poor Project Execution - Failure to undertake effective project reviews and take decisive action. Poor milestone tracking. Inadequate or poorly performed acceptance mechanism for contractor deliverables. (10) External Influence Problems - Unrealistic deadlines imposed on the project. Buyer's funding change after project initiation. Inappropriate stakeholder including higher management interferences or interventions in project. (11) Acquisition Problems - Capable contractor not selected. Contractor used personnel less capable than those used to win proposal. (12) Post Implementation Problems - System is not maintainable post implementation. System is not used because expected functions are not delivered or lack of training or poor user interface. (13) Stakeholder Conflicts - Stakeholder conflicts are not resolved in a timely and effectively manner. (14) Unprecedented Technology Basis - First time organization has used the technology underlying this project. Technology may be untested or experimental. (15) New Customer Organization - Insufficient interaction with different user groups during and after development. New customers often bring different covert expectations that sometimes lead to problems for the project.;I then used these factors to construct a model to measure the degree that the above failure factors contributed to project outcomes for software development IT projects within the US Department of Transportation (DoT) and examined the relationships among these failure factors to identify a subset of those factors that contributed most to the differentiation (discrimination) between successful and failed IT projects. The resulting discrimination model correctly classified 77.4% of the 84 software development IT cases surveyed to their actual results, thus supporting the hypothesis "Failure factors of failed government software development IT projects have statistically significant higher rankings than failure factors associated with successful IT projects." And a subset of those failure factors is a valid predictor for DoT IT projects. Using discriminant analysis to analyze the results of the survey, the results supported the hypothesis: Failure factors of failed government software development IT projects have statistically significant higher rankings than failure factors associated with successful IT projects. The results further identified the degree each factor contributed to determining into which group a project would fall. The "New Customer Organization problems" failure factor was removed because it did not contribute to the outcome.;For software development IT projects within the Department of Transportation, the Process Problems failure factor contributed the most. The second greatest contributor was Poor Risk Management and the third was Poor Project Execution.