A Case Study on the Success of Introducing General Non-construction Activities for Project Management and Planning Improvement.
ABSTRACT 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.
- SourceAvailable from: Paula Savolainen[Show abstract] [Hide abstract]
ABSTRACT: Before an outsourced software project officially begins the contracting or supplier organization has already expended effort. Although project start and start-up effort impact on project success in most cases these are undefined concepts. There are no clear definitions of project start, start-up or the activities that should be completed before project start either in the literature or in practice. Ambiguity around project start sets up risks to the profitability of a project and therefore makes the real success of a project not only uncertain but difficult to measure. A vague project start also makes comparisons between projects and between organizations unreliable. In this paper, we describe a pilot study that reviews project start, project start-up, and project start date, and then investigates what the key activities of the supplier are normally performed by the end of the project start-up phase. We use interviews with software supplier practitioners to define those key activities.
- [Show abstract] [Hide abstract]
ABSTRACT: The knowledge acquired during the sales phase of a software development project is very important for supplier firms. However, the knowledge that a project manager has acquired before the project starts, and during the sales phase, is not necessarily available when the project is starting. We draw theoretically on the project marketing cycle and emphasize a discontinuity in the project marketing cycle between the preceding phases of the project and the project implementation phase. Our study revealed an ignored phenomenon that is an inherent part of supplier firms. The phenomenon originates from funnel-like sales processes and volatile projects' situations, which force supplier firms to select a project manager other than the one who was involved in the case during the sales phase. This creates a knowledge management challenge in supplier firms. Our study contributes to project management research, studying management of a project in a project business context, and reveals a knowledge management challenge in supplier firms.International Journal of Project Management 05/2014; · 1.53 Impact Factor
- [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; · 1.25 Impact Factor