Software Project Management, Software Project Failure

Software Project Failure©

Abstract

This White Paper discusses the influence of Software Project Failure on Project Management.

Keywords: Software Project Failure, Software Project Management

Introduction

When we talk about Project Management in the post-WW11 epoch we are talking about a formal and codified method to achieve time, cash and scope tied undertakings (Morris, 1994/2011). Project Management in the pre-war epoch would have been focused mainly on construction and engineering style projects; however, in the 21st Century, Project Management, has become synonymous with Information Technology. The Project Management Institute states that, “Project management is the application of knowledge, skills, tools, and techniques to project activities to meet the project requirements” (Project Management Institute, 2008, p.6). This evolution of the project management genre is summed up in an article by John Favaro (2010) when he says:

“A software project manager from 20 years ago would find much that’s unfamiliar in the way projects are managed today. Back then, software development was mostly about engineering, and the spectacular boom-bust-boom cycles demonstrating software’s vast potential for influencing business value creation were still years away”.

The common association of Project Management with IT has come about by the efforts of practitioners to deliver tasks, and further by professional associations such as the USA based Project Management Institute (PMI) and their European counterparts the International Project Management Association (IPMA) in order to establish templates for ‘best’ practice for their professional members. These templates remain wedded to the three corner-stones of project management, namely, conception, construction and conclusion. Professional bodies have also shifted focus in the new economic dispensation from ‘requirements analyst’ (and its engineering type connotations) to ‘business analyst’ models, the latter being a tool that will help squeeze the juice of innovation from its resources in order that it may survive the economic drought of recession.

This drive towards codification has not gone without criticism; the profession of Project Management has been accused of being atheoretical due to its focus on techniques, frameworks and offering simple explanations for what are often difficult issues.

While Project and Program Management appeared to be ‘accidentally’ framed in a functionalist tapestry of techniques and processes, Blomquist and Soderlund (2002) tell us that by the end of the 1980s research relating to Project Management were drawing on different perspectives which were often grounded in organisational theory. Research relating to Software Project Management is in the 21st Century often anchored in the bedrock of ontological and epistemological commitments.

Pellegrinelli and Murray-Webster (2011) capture the theoretical evolution of Project Management when they state:

“Project and Program Management as sets of strictures[1] in a professional sense, or conceived and studied from within a tightly bounded paradigm in an academic sense, are giving way to greater plurality of practices, perspectives, and insights”.

Whatever the scale of any project within an organisation, there are a myriad of perspectives to be considered, long before planning, during planning and in parallel with implementation, the complexity of sociological paradigms within an organisation must be considered in order to comprehend the impact of such change (Burrell and Morgan, 1979).

Horch, J.W. (1996) says that an SQS requires a change in the culture of the organisation with respect to quality. The key component of any culture change is commitment. (p.192)

Many of the world’s cutting edge IT giants such as NASA spends billions of dollars on software projects each year, and the NASA, Work Breakdown Reference Guide (1994), tells us that, “Each NASA program has a set of goals which are developed from NASA mission needs. These program goals are expanded into specific project objectives. The function of management is to plan and direct project activities to achieve the program goals”. Martyn, A. et al (1994) tell us that, Scale complexity: the degree of difficulty for developments increases exponentially with the project size.   However, it will be shown in this paper that fine words and sentiments will not insure the success of Software Projects, whatever their scale.

 Software Project Failure

There are many tools that can be harnessed to conduct software projects and hopefully offer mitigation against failure, Critical Chain Project Management (CCPM) is a method of planning and managing projects that puts more emphasis on the resources required to execute project tasks. This is in contrast to the more traditional Critical Path and PERT methods, which emphasise task order and rigid scheduling. A Critical Chain project network will tend to keep the resources levelly loaded, but will require them to be flexible in their start times and to quickly switch between tasks and task chains to keep the whole project on schedule (PMI, 2008).

Value Based IT Management (VBIM) is an integrated and strategic approach to the general management of business. Value Based IT Management (VBIM) was introduced in 1998 as an approach to managing investment in reusable software and has since been applied to other types of IT investment. The principle extension to VBM is the inclusion of option-oriented valuation techniques. There are five principles of VBIM [Favaro, 2003].

However, what we will learn in this paper is that whatever the approach adopted for a particular software project that approach can flounder on rudimentary mistakes and omissions. Figure 1, highlights the success and failure rates of software projects in the USA in 2000: 49% Challenged/28% succeed/23% Failed, this pie chart is adapted from (Stepanek, G. 2005) and has been drawn by this author (2012) using Google shapes.

softwareprojectfailure

Figure 1: The success and failure of software projects in the USA in 2000: 49% Challenged/28% succeed/23% Failed

 Software Project failure or bankruptcy[2] is often misrepresented as various stakeholders attempt to shift the burden of blame onto others, or failures are buried without post-mortem as companies can’t afford to or simply won’t invest further money to find out what went wrong and why, in Ireland we have had an abundance of high profile IT project failures including the HSE, Credit Unions, An Garda Siochana, e-Voting machines and so forth. In the UK the NHS spent over 12 billion on a software project that never functioned and in the USA; McDonalds spent 170 million dollars on a project that floundered on its scope, reminding project managers that all activities should be SMART, Specific, Measurable, Achievable, Realistic, and Time-based. There can be serious organisational and business consequences resulting from Software Project failure and this is why it is important to find out what went wrong and why.

Cases, involving tens of millions of dollars, are regularly brought before the courts in the USA which relate to Software Project failure, these failures are not necessarily based in technical faults or software short circuiting, but can range from a failure to account for various aspects of the project, such as entering the cost of the project as a capitalisation or expense[3], copyright infringement of software[4] during the project phase, poor contractual understanding[5]. Horch, J.W. (1996) when talking about project management contracts reminds us that, “If it isn’t written, it isn’t!” (p.xv).

Software Project failure is not a rare occurrence, and Lorin J. May, in an article, Major Causes of Software Project Failures, tells us that:

“Most software projects can be considered at least partial failures because few projects meet all their cost, schedule, quality, or requirements objectives. Failures are rarely caused by mysterious causes, these causes are usually discovered post-mortem, or only after it is too late to change direction”.

This theme is consistent with the findings of Kappelmana et al (2006) who provided us with the top 12 people related and project-related IT project risks based on ‘early warning sign’ data elicited from a panel of 19 experts and a survey of 55 IT project managers, they stated that:

“The post-mortem examination of failed IT projects reveals that long before the failure there were significant symptoms or “early warning signs.”

Such is the transitional nature of software and IT projects that, Cockburn, A. (2007) says, “These days, when I study a project, I am periodically reawakened to the fact that I don’t know what it is that I don’t know but should know-what I should be paying attention to but don’t have a parsing element for”. So it is that we have experts that, don’t know what they don’t know. And Lister, A.M. (1993) reminds us that we have bugs that cannot be exterminated by the antibiotic of knowledge, “It has been known for systems to reach a point where the number of bugs is constant; any attempt to fix ‘n’ problems introduces ‘n’ new ones in exchange”. However, expert knowledge is not to be dismissed as Cockburn, A. (2007) uses a quote from an IBM expert to state, “The way to get effective technology transfer is not to transfer the technology itself but to transfer the heads that hold the technology!” (p.188). The role of the knowledge worker is further commented on by Budgen who says that, “Experimental study of software designers and their practices suggests that, as might be expected, some people are better designers than others”, (Curtis et al., 1988, in Budgen, 1994).

In 1975 the first major work on software project management was published by F.P. Brooks Jr., The Mythical Man-Month, Essays on Software Engineering, would be a benchmark for project management for decades to follow, the continued importance of Brook’s work 24 years following its original publication was shown by the work of J.M. Verner et al (1999) when a citation analysis showed that, ‘The Mythical Man-Month’, had been consistently cited by professionals from many research fields. Brooks republished, The Mythical Man-Month (with three new chapters), in 1995 and he included in that publication his other much cited work, ‘No Silver Bullet’.

J.M. Verner et al (1999) in their work, In the 25 years since The Mythical Man-Month what have we learned about project management? They uncover a range of indicators for software project management success and failure, rather than produce a narrative of their findings this author has created a visualisation to highlight the findings of Verner et al (1999) see, Figure 2. Verner et al highlight some rudimentary indicators for project failure including poor communication, inexperience, staff retention issues, vague requirements, and unmanaged risk and all of this comes 24 years following the ground breaking work by Brooks. 

softewareprojectmanagement2

However, following on from the works of Brooks (1975) and Verner et al (1999) it is clear that customers are demanding higher standards when, Sanders, J. et al (1994) tells us that, “As the software market matures, customers want to be assured of quality. They no longer accept your claims at face value, but expect you to demonstrate quality”.

While software projects have had many highlights for all the wrong reasons, it is worth noting that many software projects with humble open source beginnings have had great success stories, for example, in 1991 Linux Torvalds wrote a complete, stable, operating system Kernal (Linux) in less than one year, this milestone achievement was accomplished by one man, and it is possibly that simplicity that brought about success. Apache 1.0 had a similar success story when eight core contributors put their heads together. Can these and many similar examples be used as evidence that software projects can succeed outside of project management, or can we simply say that software project management is not the same as construction and engineering projects, and that software projects fail for a host of reasons, some easily explained some to be cremated by a team with a burning desire not to be exposed.

Conclusion

This paper has discussed the influence of software project failure on project management. It is easy to understand why people would assume that software project failure is related to technical or coding issues, however, this paper has clearly shown that software project failure can occur for a host of reasons, and some of those reasons are of a most rudimentary nature. As can be seen in Fig.2, a visualisation created by this author, poor communication, non-negotiated vague requirements, inexperienced project manager and unmanaged risks are just some of the ingredients that can individually or collectively bring about the failure of a software project.

However, software project failure is not simply a matter of going back to the drawing board and starting again, some of the case law in this paper have shown how companies were liquidated by software project failure, how companies were stopped in their tracks and their objectives under-mined by prolonged litigation in relation to copyright infringement and poor contractual understandings.

It is clear from the evidence in this paper that customers are getting tired and fatigued with software project failure and project management that simply fails to manage. Small and medium sized firms can be buried by software project failure and large companies such as NASA can have their international reputation shredded by poorly documented projects.

In a world market that is now being squeezed by Global economic recession, companies are demanding value for their money, not excuses for project failure. Companies are now trying to squeeze the last drop of innovation from their contracting workforce as their markets blow in the wind of uneasy forecasts and uncertain predictions. The focus has shifted from requirements analysis to business analyst models in order to survive in a thread bare economy.

Project management is now firmly anchored in in formal, codified methodology in order to achieve time, cash and scope tied undertakings (Morris, 1994/2001), however, it is clear from the evidence in this paper that project failure/bankruptcy more often fails as a result of ‘human short-comings’ than ‘software short-circuiting’.

White Paper by Vincent McKenna BSSc, PG Dip, MSc.

Bibliography/References

Abe, J. et al (1979)   ICSE ’79 Proceedings of the 4th international conference on Software engineering , IEEE Press Piscataway, NJ, USA ©1979.

Budgen, D. 1994, Software Design, Addison-Wesley Publishing Company, Wokingham, England.

Cockburn, A. Agile Software Development The Cooperative Game, Second Edition, Addison-Wesley, Boston, USA.

Favaro, J., 2010, Renewing the Software Project Management Lifecycle, Informatica E Tecnologia Del Software Spa, IEEE Software.

Horch,J.W. 1996, Practical Guide to Software Project Management, Artech House Inc. Norwood, MA 02062.

Jalote, P. 2002, Software project management in practice, Institute of Technology, Kampur, Addison-Wesley Longman Publishing Co., Inc. Boston, MA, USA ©2002 ISBN:0-201-73721-3.

Kappelmana L.A., McKeemanb, R. & Zhangc, L., 2006, Information Systems Management, Early Warning Signs of it Project Failure: The Dominant Dozen, pages 31-36, Volume 23, Issue 4.

Lister, A.M. and Eager, R.D., (1993), Fundamentals of Operating Systems, Fifth Edition, Macmillan Press Ltd., London, England.

NASA, 1994, Work Breakdown Reference Guide, NASA, USA.

Ould, M.A. and Unwin, C. (Editors), 1994, Testing in Software Development, British Computer Society Monographs in Informatics, Athenaeum Press ltd. Tyne and Wear, England.

Project Management Institute, 2008, A Guide to the Project Management Body of Knowledge (PMBOK Guide) Fourth Edition, Pennsylvania, USA.

Sanders, J. and Curran, E. 1994, Software Quality a framework for success in software development and support, Addison-Wesley Publishers Ltd.

Stepanek, G. 2005, Project Secrets, Why Software Projects Fail, Springer-Verlag, New York.

Shneiderman, B and Plaisant, C. 2010, Designing the User Interface Strategies for Effective Human-Computer Interaction, International Edition, Addison and Wesley is an imprint of Pearson, Boston, USA.

Verner, J.M., Overmyer, S.P., and McCain, K.W., 1999, In the 25 years since The Mythical Man-Month what have we learned about project management? College of Information Science and Technology, Drexel University, Philadelphia, PA 19104, USA, Information and Software Technology 41 (1999) 1021–1026.

Journals

Project Management (Dec.2011) Volume 42, Number 6, Wiley, wileyonlinelibrary.com.

ACM Computing Surveys (2011), Vol. 43, No 4, Association for Computing Machinery, New York.

Internet Sources

Inkscape.com for the production of visualisation

http://www.journals.elsevier.com/international-journal-of-project-management/most-read-articles/

http://flowingdata.com/2009/06/23/20-visualizations-to-understand-crime/and ESRI’s ArcGIS tool

http://www.esri.com/data/esri_data/crimerisk.html

http://www.ravensbrain.com/2010/06/good-project-management-e-journal.html

http://www.toolsjournal.com/tools-world/item/158-top-15-online-project-management-tools

http://www.kmworld.com/

http://www.thedacs.com/databases/url/key/5606

Figures

Figure 1: The success and failure of software projects in the USA in 2000: 49% Challenged/28% succeed/23% Failed. This pie chart is adapted from Stepanek, G. 2005, Project Secrets, Why Software Projects Fail, Springer-Verlag, New York, and has been drawn by this author (2012) using Google shapes.

Figure 2: Visualisation (using inkscape) by this author (2012) to represent Verner et al (1999), Project Success and Failure Factors.

Case Law

www.kscourts.org/cases-and-opinions/…/2006/20061027/95102.htm

144 P.3d 747 (2006) WACHTER MANAGEMENT COMPANY, Appellee,v.DEXTER & CHANEY, INC., Appellant. No. 95,102. Supreme Court of Kansas. October 27, 2006.

956 F.2d 1508 (1992) IDAHO CONSERVATION LEAGUE, Idaho Wildlife Federation, Idaho Environmental Council, Idaho Sportsmen’s Co-alition, Inland Empire Public Lands Council, and the Sierra Club, Plaintiffs-Appellants, John MUMMA, F. Dale Robertson, and the United States Forest Service, Defendants-Appellees, Intermountain Forest Industry Association, Defendant-Intervenor-Appellee. No. 90-35796. United States Court of Appeals, Ninth Circuit.

426 F.Supp.2d 1101 (2006) MERIDIAN PROJECT SYSTEMS, INC., Plaintiff, v. HARDIN CONSTRUCTION COMPANY, LLC, and Computer Methods Internation Corp., Defendants. Computer Methods Internation Corp., and Hardin Construction Company, LLC, Counterclaimants,v. Meridian Project Systems, Inc., and James Olsen, John Bodrozic, and Mike Carrington, Counterdefendants. No. CIVS04-2728 FCD DAD. United States District Court, E.D. California.

552 F.3d 981 (2009) ZUCCO PARTNERS, LLC; Rex Boggs; Kennard McAdam; Glen Thomas, Plaintiffs-Appellants,v.DIGIMARC CORPORATION; Bruce Davis; E.K. Ranjit, Defendants-Appellees. No. 06-35758. United States Court of Appeals, Ninth Circuit.

387 F.Supp.2d 521 (2005) MADISON RIVER MANAGEMENT COMPANY, Plaintiff,v. BUSINESS MANAGEMENT SOFTWARE CORPORATION, a/k/a BMS, Defendant. No. 1:03CV00379. United States District Court, M.D. North Carolina.

883 F.2d 48 (1989) MANAGEMENT COMPUTER SERVICES, INC., Plaintiff Appellant, v. HAWKINS, ASH, BAPTIE & CO., et al., Defendants-Appellees. No. 89-1097. United States Court of Appeals, Seventh Circuit 

Reading: Wish List: for Software Project Management

 F.P. Brooks Jr., The Mythical Man-Month, Essays on Software Engineering, Addison-Wesley, Reading, MA, 1975.

F.P. Brooks Jr., No silver bullet—essences and accidents of software engineering, Computer 20 (4) (1987) 10–19.

F.P. Brooks Jr., Anniversary Edition of The Mythical Man-Month, Essays on Software Engineering, Addison-Wesley, Reading, MA, 1995.

STEP99, Software Technology and Engineering Practice, Pittsburgh, August 1999.

S. McConnell, Rapid Development, Microsoft Press, 1998.

A.P. Sage, J.D. Palmer, Software Systems Engineering, Wiley/Interscience, New York, 1990.

B.W. Boehm, Software Engineering Economics, Prentice-Hall, Englewood Cliffs, NJ, 1981.

S.J. Andriole, Managing Systems Requirements: Methods, Tools, and Cases, McGraw-Hill, New York, 1996.

N.E. Fenton, S.L. Pfleeger, Software Metrics: A Rigorous and Practical Approach, Thomson Computer Press, UK, 1996.

Definitions

Stricture: A restraint, limit, or restriction. An adverse remark or criticism; censure. Pathology An abnormal narrowing of a duct or passage. Freelibrary.com

[1] Stricture: A restraint, limit, or restriction. An adverse remark or criticism; censure. Pathology An abnormal narrowing of a duct or passage. Freelibrary.com

[2] Abe, J. et al (1979)   ICSE ’79 Proceedings of the 4th international conference on Software engineering , IEEE Press Piscataway, NJ, USA ©1979. “bankruptcy”.

[3] ZUCCO PARTNERS, LLC; Rex Boggs; Kennard McAdam; Glen Thomas, Plaintiffs-Appellants, v. DIGIMARC CORPORATION; Bruce Davis; E.K. Ranjit, Defendants-Appellees. 552 F.3d 981 (2009)

[4] MADISON RIVER MANAGEMENT COMPANY, Plaintiff, v. BUSINESS MANAGEMENT SOFTWARE CORPORATION, a/k/a BMS, Defendant. 387 F.Supp.2d 521 (2005)

[5] WACHTER MANAGEMENT COMPANY, Appellee, v. DEXTER & CHANEY, INC., Appellant.  144 P.3d 747 (2006)

Leave a Reply