General
This report is a well structured piece of writing which outlines the scope in the introduction, and presents clear analysis of an issue.
Extract:
Investigate and discuss the factors that determine the success (or failure) of software development projects (2,500 word report)
Investigate and discuss the factors that determine the success (or failure) of software development projects (2,500 word report)
Introduction
Why do software projects fail? What are the causes of these failures? Who and what are affected by these failures? Who is responsible and what needs to be done to overcome these issues? These questions have been raised over the years across the software development world.
My report investigates and discusses the factors that determine the success (or failure) of software development projects. Initially, this report will briefly define what is meant by success and failure, and discuss the failure statistics. Next, some case studies are analysed to identify the major causes of software projects outcomes. Then, the lessons learnt from these case study analyses will be discussed and finally, this report concludes with an outlook on the future of software project implementations.
According to Standish (1995) and Taylor (2001), a successful software project is delivered on time and within the budget together with satisfactorily meeting all the originally agreed specifications. Keeping this context in mind, both Standish (1995) and Taylor (2001) had carried out surveys independently to explore the statistics about software development project outcomes. The results are presented in appendix 1.
A software project is generally considered as a failure when it is delivered to schedule but fails to meet its specifications. However, there are cases of projects which fail initially but after numerous attempts succeed later. A good example relating to this is the UK Passport Agency IT system (see appendix 2). Also, what if a project that was within budget, delivered on time and met the terms of the specifications turned out not to be operational at the end?
Clearly, the context above does not exactly define what determines the success or failure of a software project. To resolve this, researchers carried out further studies to discover better clarification of success or failure of software development projects (see appendix 3).
Debacle factors of software development projects
Software project failures often bring catastrophic results to the organisation. Being delayed, being over-budget and missing requirements could mean an end to the project and could affect the image of the organisation. In this report, several failed software projects are examined to find out the causes.
Case study 1: UK Courts Libra System (Libra)
The Libra project intended to introduce a national computer system for 385 magistrates' courts in England and Wales. The Lord Chancellor's department had already made two previous attempts to launch the Libra project. In December 1998, ICL (now called Fujitsu) was awarded 184 million contract. In 2003, Edward Leigh, the Conservative MP, said that "Libra project is one of the worst IT projects I have ever see… the shoddiest PFI (Private Finance Initiative) project ever" [Collins (2003)].
The third attempt failed for the following major reasons:
Unreliable estimations The 184 million contract was increased from its original bid, 146 million and then revised in May 2000 to 14.5 years contract. In September 2001, Fujitsu requested for another revised deal again. This under-priced contract later jeopardized the project. [Collins (2004)]
Poor analysis of requirements There were evidence that Fujitsu started writing detailed computer programmes before it had developed a full requirement analysis. [NAO (2003)]
Lack of focussed staff On Fujitsu side, a new management team was appointed during the period of the contract renegotiation, thus causing more time and investment needed for re-training [NAO (2003)].
Lack of clear senior management ownership and leadership Business director position has changed twice and once for the project director during the contract term from 1998 to 2001 [NAO (2003)].
Lack of user involvement The relationship between Fujitsu and the department remains awkward after few years resulting to poor business analysis quality. There were also evidence where the department do not understanding the difference computer systems and working practices held in each magistrates' courts.[NAO (2003)]
Not driven by business decisions Rather than driven by business processes, focus was paid more to technology process. The department has admitted to develop best business process before seeking an IT solution. [NAO (2003) and Collins (2004)]
Too little attention to smaller project milestones - The department do not revise their contingency plan from time-to-time. Therefore, they are unable to handle when ICL renegotiate the contract in 2001. [NAO (2003)]
Insufficient technology knowledge Unfamiliarity with the latest IT within the department may have caused it to misjudge whether suppliers were overselling a technology and the ease with which it can be delivered [Post (2003)].
Quality: Structure
The use of headings in bold, italics and different font size throughout the report is helpful to the reader, showing clearly the way in which the writing has been organised.
Here the writer demonstrates how the structure and approach of the report will answer the questions raised, and gives further signposting to the reader.
A new introductory paragraph introduces this new section, clarifying what will be covered and how the argument will progress (through examination of case studies).
Quality: Voice
Opening a report with a series of questions is a good way of indicating the report"s purpose and scope, and is also more likely to interest the reader than a bald statement of what will be covered.
Function: Describe
The writer presents relevant, accountable facts from sources which are clearly acknowledged.
A very clear overview of the case study project and the scale of its failure. Because the important element here is the analysis which follows, the description can be kept very brief.
Quality: Authority
Putting evidence into an appendix is a good way of allowing a reader who may already be familiar with the subject to continue reading the report without interruption. Content which was not written by the student author is also kept separate from the main body of the report.
A counter-example to the stated opinion is given.
Function: Analyse
The writer presents a critical analysis in a structured manner in the form of a list of bullet points with appropriate explanation. The lay-out is helpful in highlighting the main issues, and each point is clearly referenced. As the writer is summarising a number of different sources, the actual bulleted list can be assumed to be the writers" own work.
