Conference Paper

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

DOI: 10.1007/11767718_15 Conference: Product-Focused Software Process Improvement, 7th International Conference, PROFES 2006, Amsterdam, The Netherlands, June 12-14, 2006, Proceedings
Source: DBLP


The creation of a proper work breakdown structure (WBS) is essential in performing successful project effort estimation and
project management. The use of WBS is required on the level 1 of CMMI. There is, however, no standard WBS available. In this
paper, the results of a pilot project in which new activities were introduced into the TietoEnator’s WBS are reported. The
activities were non-construction activities which are necessary but not directly related to the actual software construction.
The study shows that the success of the introduction of such activities very much depends on the naming of the activities
and how they are introduced to the employees. Additionally, it turned out that the pre-thought set of non-construction activities
included activities that should not have been in the set at all as individual activities.

32 Reads
  • [Show abstract] [Hide abstract]
    ABSTRACT: Objective: The objective of this paper is to provide a framework for effort management in software projects to increase effort estimation accuracy. Method: We applied a multimethodological approach employing a case study and constructive research. Results: Based on the case study on four earlier proposed frameworks related to effort management and three popular process maturity assessment models, we constructed a framework to manage effort in a software project in a proactive manner, yet fulfilling the requirements of the assessment models. Conclusions: A project's software engineering process involves various functions which have an effect on the success of effort estimation. Two approaches, proactive and reactive, can be taken to manage effort in a software project. In this paper, a case study is conducted regarding both approaches. Based on the case study, we provide a new framework for effort management in software projects to increase effort estimation accuracy.
    Software Process Improvement and Practice 11/2007; 12(6):549-558. DOI:10.1002/spip.350
  • [Show abstract] [Hide abstract]
    ABSTRACT: peer-reviewed 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. SFI
  • [Show abstract] [Hide abstract]
    ABSTRACT: ContextSoftware 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.ObjectiveThis 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.MethodsThe 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.ResultsThe 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.ConclusionIt 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.
    Journal of Systems and Software 11/2010; 83(11-83):2175-2187. DOI:10.1016/j.jss.2010.06.023 · 1.35 Impact Factor
Show more