A Case Study on the Success of Introducing General Non-construction Activities for Project Management and Planning Improvement

Haapio, Topi; Ahonen, Jarmo J.

doi:10.1007/11767718_15

Cited by 7 publications

(10 citation statements)

References 11 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…3. The documents left unclassified during step 2 were classified into two extra classes, which have been described by Haapio and Ahonen (2006) and Artto et al (2008):…”

Section: Methodsmentioning

confidence: 99%

Software engineering projects may fail before they are started: Post-mortem analysis of five cancelled projects

Ahonen

Savolainen

2010

Journal of Systems and Software

Self Cite

View full text Add to dashboard Cite

Context: Software project cancellations are often caused by mistakes made during the project, and such cancellations make a strong economic impact. We analyzed five cancelled software engineering projects. One case was an internal product development project of a company that sells products to its customers. The other four cases were different software engineering projects, and outcomes of these projects were planned to be delivered to external customers.Objective: This study reports a post-mortem analysis of five software engineering projects with the aim of providing more knowledge about the reasons for cancellation decisions and the causes behind those reasons.Method: The research method is case study. A method for a document-based post-mortem analysis was developed and post-mortem analysis was performed. All project documentation was available for analysis.Results: The reasons for the cancellation decisions were well-known ones. In four cases of five, the outcome of the project was to be delivered to an external customer, but in these cases the causes of the cancellation reasons were not found from the normal project documentation. In these cases the cause of the cancellation originated in a phase before the start of the project and therefore the project was doomed before it was started.Conclusion: It is reasonable to suggest that a remarkable portion of project cancellations are due to mistakes made before the project is started in the case of contract-based software engineering projects.

show abstract

“…3. The documents left unclassified during step 2 were classified into two extra classes, which have been described by Haapio and Ahonen (2006) and Artto et al (2008):…”

Section: Methodsmentioning

confidence: 99%

Software engineering projects may fail before they are started: Post-mortem analysis of five cancelled projects

Ahonen

Savolainen

2010

Journal of Systems and Software

Self Cite

View full text Add to dashboard Cite

show abstract

“…Although the reported study is based on a fairly limited number of interviews its results can be considered valid because similar problematic have been reported earlier [24]. The actual usability of the proposed definition in the business environment and the detailed steps present in the start-up phase are left for further research.…”

Section: Resultsmentioning

confidence: 56%

“…In order to achieve those criteria and create a prosperous relationship between the customer and the supplier there has to be a common understanding of several issues. One of the issues is the definition of the project start and the role of project start-up activities discussed in [10], and [24].…”

Section: Resultsmentioning

confidence: 99%

“…If the abstract of the article did not include relevant terms, then the article was not considered any further. There were only two articles [24], and [11] that somewhat covered the project start. Neither of those articles defined the project start, but Barry et al [11] considered the start-up important in the beginning of the project and after interruptions.…”

Section: A Literature Reviewmentioning

confidence: 99%

“…Project start-up phase starts when company has got the order from the customer or the customer has indicated some other way that it will order software development project with agreed deliverables from the supplier company. The project start-up phase has been discussed in [8], [13], [10], [9], [23], and [24]. The project startup phase and its relationship with the sales process and the actual project are depicted in Fig.…”

Section: The Interviewmentioning

confidence: 99%

See 2 more Smart Citations

Vague Project Start Makes Project Success of Outsourced Software Development Projects Uncertain

Savolainen

2010

Product-Focused Software Process Improvement

View full text Add to dashboard Cite

Abstract.A definition of a project success includes at least three criteria: 1) meeting planning goals, 2) customer benefits, and 3) supplier benefits. This study aims to point out the importance of the definition of the project start, the project start date, and what work should be included in the project effort in order to ensure the supplier's benefits. The ambiguity of the project start risks the profitability of the project and therefore makes project success at least from supplier's point of view uncertain. Moreover, vague project start makes it more difficult to compare project management metrics, such as duration and effort, between projects. There is no clear definition for the project start either in literature or practice. Based on interviews, the definitions are provided for project start, project start date, and project start-up effort included in the project.

show abstract

A framework for improving effort management in software projects

Haapio

2007

Softw Process Imprv Pract

Self Cite

View full text Add to dashboard Cite

Rapid changes in information technology (IT) set challenges to software project effort estimation. Besides effort estimation, software projects involve various other effort-related functions which have an effect on the effort estimation. Some of these functions are required by the capability maturity models such as Capability Maturity Model Integration (CMMI). However, both the capability maturity model requirements and research on software project effort is very fragmented. This article proposes a framework for improving effort management in software projects. The framework assists both the total management and, on the other hand, concentration on selected areas of effort-related functions.

show abstract

A Case Study on the Success of Introducing General Non-construction Activities for Project Management and Planning Improvement

Cited by 7 publications

References 11 publications

Software engineering projects may fail before they are started: Post-mortem analysis of five cancelled projects

Software engineering projects may fail before they are started: Post-mortem analysis of five cancelled projects

Vague Project Start Makes Project Success of Outsourced Software Development Projects Uncertain

A framework for improving effort management in software projects

Contact Info

Product

Resources

About