· A major part of the failure
· AbstractMost software projects fail completely or partial failuresbecause a small number of projects meet all their requirements. Theserequirements can be the cost, schedule, quality, or requirementsobjectives. Over the last 20 years manycost and schedule estimation techniques have been used with mixed sensation dueto restrictions of the assessment models.
A major part of the failure can bedue to a lack of understanding of the software development process and theeffect of that method used in the project plan, schedule and costestimates. Organizations and individualshave studied a number of projects that have both succeeded and failed and somecommon factors emerge. A key finding is that there is no one overriding factorthat causes project failure.
This Paper review the numbers of factors are involved in projectfailure, some of which interact with each other. KeywordsFailure Reasons, Success factors, Failure Statistics IntroductionOne of the most serious complaints against software failureis the inability to estimate with acceptable accuracy the cost, resources, andschedule necessary for a software project. According to many studies, failure rate of software projects is between50% – 80%. One of the major causes ofboth cost and time overruns is restarts. For every 100 projects that start,there are 94 restarts. This does not mean that 94 of 100 will have one restart;some projects can have several restarts.
Project failure is when you do not get what you expect at the end ofyour project. It is a terrible situation when you cannot say anything about thereceived results as these results do not meet requirements of the projectcustomer and sponsor. This paper discusses on why most projects fail and whatthe top reasons for project failure are in software development project.Background2 BACKGROUND WORK Developing and maintaining softwaresystems involves a variety of highly interrelated activities. In order to man-age these structured set of activities various models have been developed overthe years with varying degree of success. These include Waterfall model,Iterative devel- opment, Prototyping, Spiral model, RAD.
Each product can passthrough different states, depending on the spe- cific circumstances of eachproject and hence, there are different development models. For example, if theprob- lem is well defined and well understood and user need is practicallyinvariable, a short waterfall-like life cycle is likely to be sufficient. TheWaterfall Model was widely used because it formalized certain elementaryprocess control requirements. However, when we come up against a poorly defined and understood problem and a highly volatileuser need, we can hardly expect to output a full requirements specification atthe start. In this case, we have to opt for longer and more complex lifecycles, like the Spiral Model 2. Each cycle in Spiral Model addresses thedevelopment of the software product at a further level of detail. In the courseof several papers, Boehm and his colleagues ex- tended the spiral model to avariant called the Win–Win Spiral Model 2, 3, 4. The win–win stakeholderap- proach is used to determine three critical project miles- tones thattogether anchor the development of the project: namely, life-cycle objectives,life-cycle architectures, and initial operational capability .
PrototypingModel helps to understand uncertain requirements but leads to falseexpectations and poorly designed system. A popular var- iation of thePrototyping Model is called Rapid Applica- tion Development (RAD). This model introduces firm time limits on each development phaseand relies heavily on rapid application tools which allow for quick developed.
Exploratory model use the prototyping as a technique for gathering requirementsand was very sim- ple in its construction but is limited with high level lan-guage for rapid development. This model works best in situations where few, ornone, of the system or product requirements are known in detail ahead of time.This model is largely based on educated guesswork. This scheme is notparticularly cost-effective and sometimes results in less-than-optimal systems,so it should be used only when no viable alternative seems to exist. Agileprocess model give less stress on analysis and de- sign. Implementation beginsmuch early in the life cycle of the software development. This process modelde- mands fixed time.
Extreme Programming (XP) was created by Kent Beck during software development, and is based oniterative enhancement model. Like other agile software development, XP attemptsto reduce the cost of change by having multiple short development cycles,rather than one long one. It only works on teams of twelve or fewer people.Industrial Extreme Pro- gramming (IXP) was introduced as an evolution of XP. Itis intended to bring the ability to work in large and dis- tributed teams. It then supported flexible values .
There is not enough data to prove itsusability. These days, majority of the software development project involvesome level of reuse of existing artifact like design or code modules. Thecomponent-based development (CBD) model incorporates many of thecharacteristics of the spiral model. It is evolutionary in nature, demanding aniterative approach to the creation of software . The component-baseddevelopment model leads to software reuse, and reusability provides softwareengineers with a number of measurable benefits. The unified software de-velopment process is representative of a number of com- ponent-baseddevelopment models that have been pro- posed.
Using a combination of iterativeand incremental development, the unified process defines the function of thesystem by applying a scenario-based approach 8.The concentration is on objectoriented development. The evolution of software development Process Models has reflected the changingneeds of software customers. As customers demanded faster results, moreinvolvement in the development process and the inclusion of measures todetermine risk and effectiveness and the methods for developing systemschanged. Before requirements can be finalized we must understand the domain.
According to Dines Bjorner, it is not possible to develop software with- outunderstanding its domain . These rapid and nu- merous changes in the systemdevelopment environment simultaneously spawned the development of more prac-tical new Process Models and the demise of older models that were no longeruseful .Most common reason for software failure1.
Lack of customer and user involvements 2. Unclear goals and objectives3. Poor set of requirements4. Lack of resources5.
Failure to communicate6. Project planning and scheduling7. Cost estimation8. Improper estimation methodologies9. Cost estimation tools10. Poor testing11. Risk management12.
Unrealistic Expectations· Lack of customers and user involvements: It is the preliminary reason of software failure. When you working onsoftware and a customer does not support to you in it, then the software isgoing to fail or unsuccessful. Without the involvement of the customer wecannot feel committed to that software. To avoid from the reason of softwarefailure its necessary to make such type of working environment in whichcustomer and user can participate easily.
All project expectation should beclear and right. So we need to support the software to make it clear to allmembers (user & customers) it is a priority.· Unclear goals and objectives In many types of software to showing the progress and in this scenariothe software managers depend on the rolling wave planning. Due to the poor orillegal requirements of the user the goals or objectives may be unclear. Insuch type of cases all scheduled and scope are developed by the softwaremanager. For defining the clear requirements it may take several times and alot of communication. So it become a harmful reason of software failure.
· Poor set of requirements Whenthe software members delivers the items without having the clear understandingthat what customer want then poor set of requirements take place to become thereason of software failure. Sometime user or customer does not like it becausethe requirements have not been met when the item is developed so it also becomethe reason of software failure. · Lack of resources Every software dependon the resources, software need resources their size and scope. Most of thesoftware manager can be working on software with secure resources and attestthem. Software may be lead to failure due to unreliable or unrealisticresources. However, there are situations where the software is simplyunattainable because the allocated resources are insufficient. Lack ofresources can become a harmful reason of software failure.
· Failure to communicate Sometimes software may be fail due to improper or illegal communication.Most of the big softwares are complex and these are requires analysis, DBA, andother worker with strong or proper communication but some workers showing theirignorance which lead to communicate failure. The software manager does notcommunicate regularly because they believe that software progress will not beseen by executive management. Projects sometimes fail due to impropercommunication. · Project planning and scheduling Software planning consists on constructions of various tasks, timelineand necessary path. Software planning means making work in steps and allocatesduties or responsibilities to developer over time. Allocating the responsibilities has to beclearly defined and it becomes complicated while hiring items from outside.Before starting software proper scheduling of software is also required.
It mayinclude time scheduling and team scheduling. Software manager only tell theprogrammer what to do and he don’t know that what they have to plan andschedule. · Cost estimation Sometime costdepends a lot on software because we can manage profit or loss by software. Socost estimation is necessary before finalizing the software if it is too muchhigh then its processing then it becomes the cause of software failure. So it may not be produce the reliableestimates. · Improper estimation methodologies Another reason would be theuse of an inappropriate value estimation methodology. Not a singlemethodology is better than other.
At least one of these techniques can be utilized to evaluate the cost ofa task. “Great recommendation is that more than one programming costestimation approach ought to be utilized for exact estimation. One or greater of these methodologies can be used toestimate the fee of a project.
two “Good recommendation is that greaterthan one softwareprogram fee estimation methodology must be used for accurate estimation”· Cost estimation tools There are numerous disadvantages in manual cost estimation. Thisprocedure is relatively outdated at this point. These days fruitful costestimation incorporates the utilization of proper business programming costevaluating device. Great programming evaluating devices don’t generally ensuredependable programming gauges. Wrong contribution of the product size willbring about wrong gauge. Estimation programming additionally should be modifiedfor the particular need of association. These customizations require the information fromthe previous projects as enter for the device toestimate.
There are range of reasons these tools can returnthe wrong estimate.· Poor testing The task failure is often induced by means of lack of trying out resources.7While software developers center of attention on growing code, they do no longer deal with testing.Testers are these who should do “testing” for the duration of the development process.Often lack of testers and their terribleabilities and know-how will makean challenge un appropriate due to the factacceptance checks to see whether ornot the productmeets the businessrequirements are not run. Poortesting might be caused by poor necessities set, absence of progress control,deficiently prepared staff, absence of time for performing testing. As a tasksupervisor must keep these venture disappointment causes with a specific endgoal to fabricate a satisfactory item for client. · Risk Management Risk management is an essential component toward software undertakingfailure ifit’s not managed well timed and effectively.
Asnothing can be estimated that what will show up in future sowe have to take the imperativesteps in the current to take any unsure state of affairs in thefuture. Risk administration capability dealing witha concern before it turns into a crisis· Unrealistic expectations Projects with12unrealistic expectations are additionally about equally in all likelihood to be poorlymanaged projects that fail to validate the feasibility of satisfying consumer expectations,or two well-managed tasks that attempt to validatefeasibility and locate unavoidable factors— such as immature technology,overhyped COTS products, or a saturated market—that justify a project’s instantaneous terminationProject success factors1. Software monitoring2. Effective software3. Independent on single estimation4.
User requirements· Software monitoring It meansthat the accuracy of estimation. Software monitoring is the process of measuring or gatheringsoftware data. Internally, externally and collaboratively an extensive array ofmonitoring program exist to accumulate the software data complicated forselection making. · Effectivesoftware Software effectiveness having the capability to producing the requiredresult or having the ability to produce desired output. It means that it havingthe expected outcomes. In a number ofways this process can be used to increase the accuracy and reliability in thecost estimations.· Independenton single estimation Single reconstruction is not more than to estimate.
Software successfulfactor is that keep in mind all user or multiple user to estimate. It based on multiple comparison ofparticipating. So estimate would not be independent if after sampling. · Userrequirement. User involvement is very necessary for software successful instead ofuser involvement or lack of user involvement becomes the cause of softwarefailure. So keep in mind all user requirements and fulfil the all userrequirements successfully. Failure statistics and its recommendationsThe Standish group and 13CHAOS report is, only 9% ofprojects in large companies were successful.
At 16.2% and 28% respectively,medium and small companies were somewhat more successful. Project Large Medium Small Success 9 16.
2 28 Challenged 61.5 46.7 50.4 Failure 29.
5 37.1 21.6 A 8enormous 61.5% of all large company projects werechallenged compared to 46.7% for medium companies and 50.4% for smallcompanies. ConclusionThis paperhas deal the simple elements which can cause the softwareimprovement assignment to fail. Allof these factors are to be viewed at the management degree and thentransferred to the lower management.
Projects succeed andsometimes, projects fail. Knowing what factors can leadto undertaking failureis necessary for the venture supervisor so they comprehend what to seem to be for when managingtheir projects. The strategies and practices complement each other for improvement and bothrequire humaneffort from every body in the organization.
In Conclusion allof these failure elements are rectified to success in Software developmentproject.AcknowledgmentBibliography References 1 Top 5 Project Failure Reasons, Or Why My Project Fails ByEric McConnell. 2http://www.coleyconsulting.co.uk/failure.
htm. 3 Causes Of Software Project Failure ByMuhammad Saqib. 4 Why Projects Fail – Top 10 Reasons, via Tomtsongas. 5http://www.projectmagazine.com/initiating/43integration/395-causes-of-software-project-failure. 6 IT Project Failures By Michael Krigsman.
pdf 8 The Top Ten Reasons Projects Fail by Frank Winters. 9 Causes Of Software Project Failure By MuhammadSaqib. 10 ProjectTermination Doesn’t Equal Project Failure Barry Boehm, University of SouthernCalifornia. 11 Top 10 ReasonsWhy Systems Projects Fail Dr. PaulDorsey Dulcian, Inc.
12 http://www.scs.carleton.ca/~beau/PM/StandishReport.html- T23E-T10E STANDISH GROUP REPORT.