Project management standards. An evaluation of key factors for selection support and success KPIs

Contents

List of Figures

List of Tables

1 Introduction
1.1 Abstract
1.2 Motivation of this Thesis
1.3 Objectives of this Thesis
1.4 Structure of this Thesis
1.5 The example company WALLMEDIEN AG
1.6 Typical IT activities in Companies

2 Project Management 7
2.1 Projects
2.2 Traditional Project Management Methodologies
2.2.1 Waterfall Model
2.2.2 V-Model
2.2.3 Spiral Model
2.3 Agile Project Management Methodologies
2.3.1 Scrum Model
2.3.2 Agile XP (Extreme Programming)
2.4 Comparison of Agile and Traditional Methodologies
2.4.1 Agile vs. Traditional Project Management Methodologies
2.4.2 The combination of agile and traditional projects

3 Project Figures and Criteria 41
3.1 Project and Non-Project Distinction
3.2 Activity Classification and Project/Non-Project Assignment
3.3 Project Classification Criteria
3.3.1 Introduction projects
3.3.2 Update projects
3.3.3 Migration projects
3.4 Matching Criteria from Project-Types to Process Methodology
3.4.1 Traditional Approaches
3.4.1.1 Waterfall-based models
3.4.1.2 V-Model approach
3.4.1.3 Spiral-Model approach
3.4.2 Agile Approaches
3.4.2.1 Scrum approach
3.4.2.2 Extreme Programming approach
3.4.3 Criteria Matching
3.4.3.1 Introduction Projects
3.4.3.2 Update Projects
3.4.3.3 Migration Projects
3.5 General Use and Need of Success KPI’s
3.6 Identification of Success KPIs
3.6.1 Cost
3.6.2Time
3.6.3 Scope
3.6.4 Quality
3.7Success KPIs for Process Methodologies
3.7.1 Waterfall
3.7.2 V-Model
3.7.3 Spiral Model
3.7.4 Scrum
3.7.5Agile XP

4 Summary 99
4.1 Conclusion
4.2 Perspective

Appendix

List of References

List of Figures

Figure 1: Historical overview of Process Models

Figure 2: Essential Steps of a software development process

Figure 3: Sequential Waterfall Model

Figure 4: Iterative Waterfall Model

Figure 5: The basic V-Model

Figure 6: Theoretical approach of a V-Model in practice

Figure 7: The V-Model in a practical example

Figure 8: The Basic Spiral Model

Figure 9: The Spiral Model in practice

Figure 10: The Scrum Process

Figure 11: "Triangle of Project Management" for traditional and agile approaches

Figure 12: The traditional project manager as a central instance in a

mixed project environment

Figure 13: Co-existence of different project management approaches

List of Tables

Table 1: Overview of XPs Values, Principles and Practices

Table 2: Identification and examination of IT-related requirements

Table 3: Pairwise comparison preference matrix for Introduction Projects

Table 4: Weighting of criterion within corresponding group of Introduc-

tion Projects

Table 5: Pairwise comparison preference matrix for Update projects

Table 6: Weighting of criterion within corresponding group of Update Projects

Table 7: Pairwise comparison preference matrix for Migration Projects

Table 8: Weighting of criterion within corresponding group of Migration Projects

Table 9: Criteria fulfillment evaluation of Waterfall Model

Table 10: Criteria fulfillment evaluation of V- Model

Table 11: Criteria fulfillment evaluation of Spiral- Model

Table 12: Criteria fulfillment evaluation of Scrum- Model

Table 13: Criteria fulfillment evaluation of XP- Model

Table 14: Conversion of fullfilment evaluation to weighted factors

Table 15: Evaluation conclusion for Introduction projects

Table 16: Evaluation conclusion for Update projects

Table 17: Evaluation conclusion for Migration projects

Table 18: Identification of adaption potential IT strategy

Table 19: Budget analysis for business planning

Table 20: Monitoring of technical innovations that can be beneficial to the business processes

Table 21: Review the performance and feedback from the business units

Table 22: Modification of the IT-strategy

Table 23: Modification of IT-systems and equipment

Table 24: Ongoing, pro-active monitoring of the infrastructure

Table 26: Procurement of IT-Components

Table 27: User- and Security management

1 Introduction

1.1 Abstract

The prevalence of information technology (IT) and the significance of its role in modern companies have both increased rapidly. Nowadays, almost no business operations unit can work or function efficiently without the support of IT-based systems. Regardless of the general purpose of the respective company and the industry the company operates in, after a given point a functioning IT structure is a prerequisite for a fluent, efficient and successful operation.

With an apparently almost infinite variety of IT-supported systems, companies have to deal with the recurring question: Which parts of the company’s IT-based systems possibly require a new implementation, improvement, or replacement. However, these questions are, in most cases, equally as complex as the field of application itself, due to the wide variety of complexity and the large number of divergent aspects of IT systems.

After a decision regarding a new implementation, an update/improvement, or a replacement has been made, an overview must be developed of the tasks that will be needed to reach the project goal. Beyond a certain size and complexity, these IT systems cannot be changed on an ad hoc basis. In such a case, a detailed planning of the approach is an important factor to be coordinated to guarantee that the activities will be carried out on time, within the budget, and at the required level of quality. These tasks are commonly defined within projects, which are preferably coordinated by using project management process models. How- ever, not every process model is equally appropriate for every project or project type.

To make a decision about which process model is to be used, a wide range of aspects of the project have to be considered. These aspects are not only project-specific, but also company-related, which means that not every project can be managed the same way in every company, even if the project-specific aspects are almost identical. Alongside the project-specific factors such as the given time frame, the financial limitations, and the commitment to quality, other company-specific factors have to be taken into consideration. These include not only the amount of HR resources needed, but also the skills of the available project members. But the HR resources are not the only assets that have to be planned. In addition to sufficient staffing, the available software, hardware, and premises must be determined, and often booked in advance.

The development of certain characteristics not only depends on the project itself, but is also related to the process model being used, so that the choice of the correct process model is an important factor in whether the project can be completed in a given time, quality and budget. Therefore, the choice of the correct process model can be very important when it comes to running a project as efficiently and successfully as possible.

In addition to the steadily increasing complexity of IT projects, time and resources have became increasingly rare commodities, and project lifecycles have had to adapt to this tendency. To avoid wasting precious assets, project management process models are being used to structure, control, and supervise the given tasks in each project, so that prior to every successful project the “how to” question is thoroughly considered. Furthermore, there is not just only one answer to this question, since every use case has specific characteristics and restrictions that must be taken into consideration.

One possible approach could be to design a process methodology for each project specifically. In practice, a more suitable solution is to make use of one of the common “best-practice-proven” project management process models. But, prior to answering the question of how to deal with projects and which factors have to be observed in order to ensure a successful project flow, the definition of what constitutes a project must first be established.

1.2 Motivation of this Thesis

The present work deals with the question of which tasks in companies are actually classified as projects, as well as with the determination of project management methodologies for certain types of projects, taking into account predetermined evaluation criteria. In addition, this work deals with the question of which factors should be considered for the duration of the project in order to ensure that the project proceeds as effectively and purposefully as possible. As a practical example, weighting criteria based on the experience of the company WALLMEDIEN AG will be used to determine the appropriate project management methodology for different types of projects.

1.3 Objectives of this Thesis

The aim of this work is to provide a valid decision–making process to determine which project management methodology is best suited for processing a specific project type, and which factors have to be observed to identify possible threats to the project’s success. For the decision-making process, specific weighting criteria may be freely selected according to the respective requirements and conditions. To this end, the typical tasks within companies will be investigated and divided into projects and non-projects.

1.4 Structure of this Thesis

The underlying structure of this work proceeds from the general to the specific. This structure was chosen since it allows the fundamentals to be presented in con- junction with other methodologies and general approaches. The weighting criteria used are based on the practical experience of the software development company WALLMEDIEN AG, which is examined in Chapter 1.

Chapter 2 describes the basics of projects and project management methodologies. Here, a general distinction between traditional and agile methodologies is made and selected relevant methodologies of each type are evaluated. At the end of this chapter, the author provides an assessment and a comparison of both methodology types from his personal perspective.

Chapter 3 considers the activities that go on in companies and provides, based on a developed definition, a division of tasks into projects and non-projects. The resulting projects are then assessed for certain characteristics in order to obtain measured values with which a matching of project type to project management methodology can be undertaken. To achieve this matching, the various project management methodologies are investigated as to their satisfaction of certain requirements and criteria. The values thus obtained are then placed in relation to one another and used to accurately match the specific requirements of the project to a recommended project management methodology to use. In addition, key performance indicators for a project management method are developed, which can be used to give a project manager a good overview of the current project and possible threats to the project’s success.

The main findings are summarized briefly in conclusion in Chapter 4.

1.5 The example company WALLMEDIEN AG

WALLMEDIEN AG is a medium-sized German company with its main field of activity in the electronic procurement sector. It is an independent SAP partner, but also offers software for integration into other ERP Systems. In the SAP envi- ronment, WALLMEDIEN’s solutions form a standard in electronic procurement. WALLMEDIEN develops and implements concepts for the automation of processes in operational and strategic purchasing. Custom-made solutions are implemented on the basis of standard software for advertisements, auctions, procure-to-pay processes, document exchange, supplier portals, etc. WALLMEDIEN solutions are in use around the world.

WALLMEDIEN’s customers include internationally operating companies as well as successful small and medium-sized companies. The focus of WALLMEDIEN’s products lies in the areas in which significant savings can be achieved by using electronic procurement solutions, such as:

- All aspects of an electronic procurement process

- Frictionless data exchange throughout the entire procurement process
- Creation of catalogue and freetext-orders including approval management
- Processing of requests for goods and services

- Solutions for supplier integration

- Electronic transmission and processing of order and delivery data
- Management and handling of electronic purchase orders and other common e-business documents

- Solutions for catalogue management systems
- Tools and services that increase the benefit of e-Procurement

WALLMEDIEN AG was founded in 1997 in Paderborn, Germany. Today it has offices in Germany, the USA, and China and employs more than 130 people. WALLMEDIEN’s products are being used by over 100 companies in 47 countries.

The software solution is available in 29 languages. It connects over 60,000 suppli- ers worldwide, and the order volume through WALLMEDIEN software is over 12 billion Euros via 4 million orders per year.

1.6 Typical IT activities in Companies

The tasks of an IT department, based on the example of WALLMEDIEN, can be divided into three main phases: plan, build, and run. Within these phases, a number of general tasks arise; however, these tasks can vary depending on the company’s type and field of operation. These tasks are discussed in more detail in the following sections.

Plan

Within the planning phase, all relevant IT sectors are examined to identify oppor- tunities for improvement.

Tasks in this phase could include:

- Identification and examination of IT-related requirements
- Evaluation of the need to adapt the IT strategy (products, technologies)
- Budget analysis for business planning
- Monitoring of technical innovations that might be beneficial to the business processes
- Reviewing the performance of and feedback from the business units

Build

In the build phase opportunities for adjustments to improve the IT that is currently in use must be identified.

Tasks in this phase could include:

- Modification of the IT strategy
- Modification of IT-systems and equipment

- Implementation and deployment of a new system or modification

- Introduction of a standard-system
- Development of a special-system

- Make
- Buy

– Update of an existing system, which can be necessary for reasons such as:

- Maintenance o Security
- Stability
- Extension/Evolution

– Migration of a system

- Hardware
- Software
- Infrastructure

Run

In the run phase, the IT systems currently in use are monitored and maintained to ensure a seamless operation.

Tasks in this phase could include:

- Ongoing, pro-active monitoring of the infrastructure
- Provision of a User Help Desk for IT-Problems
- Procurement of IT components
- User and Security management

This list of tasks will apply generally to the majority of IT-related companies. However, as will be discussed later in this work, the specific tasks of IT departments in companies can sometimes vary greatly, depending on the industry and nature of the business. For this reason, no list of specific tasks can be created that is equally suitable to all types of companies.

2 Project Management

2.1 Projects

Projects have become an important part, not only for work and business but also in everyone’s private lives. Whether deliberately or not, the number of tasks that are subsumed under “projects” is increasing steadily. And in order to deal with these in project organized tasks, companies have to find a way to manage the respective subtasks that come along with them. Reasons for this trend are numerous.

Customers request and expect products and services that are tailored more pre- cisely to their wishes and needs. At the same time, the expectation of an immediate and in-time delivery has risen. The “time-to-market” has become a deal breaker in goods- and service sectors and has led to seemingly diminishing product lifecycles. Customers demand more information and explanation about products, processes, content and resources. Combined with the increasing demand for clarification and the high effort for communication that it entails, markets have changed from vendor-driven markets to customer-driven markets. The “customer is king” men- tality has reached almost every market and drives the need for project management that does not only focus on the basic means for the project, but also the customer, and very often also other stakeholders. This need for interaction between the dif- ferent stakeholders determines an accommodation of organization structures and leading concepts in Project Management Methodologies¹.

2.2 Traditional Project Management Methodologies

Project management methodologies follow certain process models in order to reach a particular goal. A project management process model is a collection of aligned guidelines that support the implementation and realization of projects. Therefore, they describe an ideal scale and course of activities to accomplish expected project goals by the use of standardized and approved methodologies.

Process models are often specialized for specific project types, companies, indus- tries, or even countries, whereas the popularity and dissemination of process models has changed in recent years.

Figure 1: Historical overview of Process Models

Abbildung in dieser Leseprobe nicht enthalten

Source: own representation based on Koch, 2011

Figure 1 shows a brief overview of the process models and their historical appear- ance.

However, the choice of which process model to use is often defined by the charac- teristics of the technical and structural framework. Furthermore, the customers’ expectations and needs may change within the project runtime, and also critical resources like employees and project members with rare qualifications have to be planned. Accordingly, project management methodologies outline the framework for successfully structuring and completing a project.

Traditional project management has to be considered from three different per- spectives. One is the institutional view, which focuses on the organizational units with project-relevant management responsibilities (such as the project manager). Another is the functional view, which focuses on the specific management tasks. Such tasks include the majority of all planning, steering, coordination and mon- itoring tasks that are needed to manage a project within the allotted time, at the appropriate level of quality, and within the budget^{2 3}. The German economist, Hans Corsten⁴, also identifies a third view – the instrumental view – which re- lates to the relevant planning and steering instruments to support the functional view.

Correspondingly, it could be said that the management of projects is carried out by the project manager (institutional view). Hence, the project manager is responsible for the planning, monitoring and steering of the project (functional view). To per- form these tasks, the project manager needs to make use of a variety of instruments (instrumental view) that combine all perspectives^{5 6}.

Traditional project management assumes that projects can be realized efficiently by using concrete planning, control, and coordination. This means that the sin- gle actions carried out in projects have to be goal-oriented in order to provide a goal-oriented project course. This approach is consistent with the “cause and effect” thinking that is in direct interaction with a causal deterministic⁷ ideology. Planning, steering and controlling are characterized by rationality, causality, and also linear thinking. These characteristics indicate a mainly heroic management style⁸.

General Approach

Project management is, as already mentioned, situated in a state of permanent tension between time, quality, and resources. A project is therefore a unique, transient endeavor, undertaken to achieve planned objectives, which can be defined in terms of outputs, outcomes, or benefits.

To achieve these objectives, projects can be broken down into lifecycles, which can also be divided into phases. Each phase has its own framework and expects a given result, upon which the next framework is based. From an economic point of view, the lifecycle of each product has to run through the following phases:⁹:

- Development
- Growth
- Maturity
- Saturation
- Decrease
- Follow-up

In the field of project management there is no common consensus about the specific subject matter of a consistent lifecycle model (process model or method- ology). There exist a variety of diverse and specialized models, which cannot be generalized. However, the following can be considered as a common scheme for software development that can also be applied to the more general field of project management:¹⁰:

- Analysis
- Design
- Implementation
- Introduction¹¹

Projects can be designed to be more manageable and easier to handle by separating them into different phases. This separation can be realized by using different itera- tive models like the Waterfall Model, the Spiral Model and the V-Model. However, these examples are only a few of the options for dividing projects into different phases. Especially in software development projects, plenty of other methodologies have gained prominence, such as the Prototype Model, the Iterative Model and the Dual Vee Model to name just a few. Unlike the well-known Waterfall Model, most of the other named models run through the project phases primarily on a circular basis, which enables the project manager, or all parties involved, to run through the phases more flexibly and to customize the phases in response to the given circumstances in each phase.

Variations

The following chapters take a closer look at the three most well-known and widespread project management methodologies in traditional project management: the Waterfall Model, the Spiral Model and the V-Model. Regardless of the specific characteristics of the respective process model, some characteristics and overall rules are common to all traditional process methodologies.

Wieczorrek et al. define project processing models for project planning, processing, handling and control as tools to systematically run through an IT undertaking in pre-defined phases¹². Therefore, different phases with independent goals are defined, which are then run through sequentially in order to reach an overall goal. Every phase has its own specific and definite decision, approval, and ending points, and in each phase a determined number of activities have to be executed. A return to the previous phase is always allowed within the scope of corrective actions. However, a return to an earlier phase is only allowed in exceptional cases, and always means that the skipped phase has to be run through again. Jumping back and forth between different phases by skipping phases is not permitted.

2.2.1 Waterfall Model

In 1970 Dr. Winston W. Royce authored the paper “Managing the development of large Software Systems”¹³ for the IEEE¹⁴ conference, in which he describes how, in his opinion, software development in large organizations should be pro- cessed.

According to Royce, software development consists of two essential steps regardless of the size or complexity of the respective system. The first step is the analysis of the problem. After the problem has been analyzed the solution has to be implemented by coding the respective solution.

Figure 2: Essential Steps of a software development process

Abbildung in dieser Leseprobe nicht enthalten

Source: own representation based on Royce, 1970

These steps are essential and directly related to the quality of the final product.

The Basic Waterfall-Model

This approach is the leanest methodology for implementing small solutions or making minor adjustments to an existing system. According to Royce, it is possi- ble in internal systems, in particular, to plan those projects and changes in this simple way, since developers are often also the users of the systems. Thus, they are aware of both the weaknesses in and use of the system, and often have the exact knowledge about what has to be changed or implemented. If the system and, consequently the project, is larger (in terms of its size, importance, and number of requirements) this methodology is an in appropriate approach and does not lead to an efficient solution. For a larger project far more steps are required, which all indirectly affect software quality in a positive way but increase the overall cost of the project. It is the responsibility of the project manager to make sure that these additional steps are conducted, since the customer is generally reluctant to pay for indirect product evolutions. Furthermore, developers tend to avoid some of the additional steps since it increases the overhead of the main development work.

Additional Waterfall-based App roaches

After the decision has been made that it is not appropriate to use the lean approach of making essentially ad hoc changes as seen in Figure 2, the question arises as to how to proceed instead. Therefore, it is possible to apply several modifications to a Waterfall-based methodology. In the following paragraphs some variations and aspects are explained in more detail.

Sequential Waterfall Model

The previously mentioned lean version of managing development projects can be seen as the most rudimentary approach. Even though it is not really a management approach, it still does have a management aspect since it consists of more than just the actual doing. But when it comes to more sophisticated problems and demands it is almost mandatory to expand the management aspect in order to guarantee compliance with quality requirements and to fulfill the customer’s expectations.

Figure 3: Sequential Waterfall Model

Abbildung in dieser Leseprobe nicht enthalten

Source: own representation based on Royce, 1970

The sequential Waterfall model is an approach that enables the project team to regulate and control the natural project process flow by adding five more steps to the rudimentary version.

The analysis and coding steps are still within the scope of the project management process and therefore have to be run through as normal. However, these two steps are separated by a program design step and are preceded by two levels of requirements analysis. A testing step follows the design step before the solution goes into operation.

These additional steps are treated separately from the analysis and coding phases since they are distinctly different in the way they are executed. They must be “planned and staffed differently for the best utilization of program r esour c es” ¹⁵.

Each step has particular goals and requirements for the executing person. De- pending on the size, nature, and objective of the project, it is possible that all steps may be performed by different individuals from different departments, who sometimes are not even involved in the project or part of the project team¹⁶. But typically in smaller projects two or more steps are performed by the same person, who is often part of the project team¹⁷.

The system requirements, including the hardware requirements and the use of software tools like databases, libraries, etc., determine the system structure. After the system requirements are fixed, the software requirements need to be analyzed. Therefore, an analysis of the customer requirement specifications and the expec- tations of the software functionality is needed. An important question that has to be answered in this step is what the system requirements are, on the basis of software requirements.

After these preceding steps the original analysis step takes place. In this step a determination of the software framework and the identification of the main components of the system and their interaction with each other is done^{18 19}. After the results of the analysis are available, a program design, including a determination of the programming language and environment, needs to be built upon those results.

After these primarily planning and analyzing steps have been finished the ac- tual coding starts. In this phase the implementation of the designed solution and therefore the build of the desired product begins. After the coding phase a complete product should be available for testing. This phase ensures the func- tionality, quality and fulfillment of all requirements^{20 21}. After this phase has been finished successfully, the final product will be transferred into operations. In this final phase the solution will be published and handed over to the customer.

This seven-step management process model can be seen as a very formal orga- nization in which every step has to be finished completely before the next step and phase can be started. A return to the previous step is not intended. However, every step has to be documented in each phase in a way that is comprehensi- ble for others even if they are not familiar with the specialties of the respective steps. Furthermore, the seven-stage model can also be seen as a basis from which customization can be used to adapt this approach to given circumstances. For instance, the model could be extended to better integrate the customer in the project. Therefore, additional steps can be used all internally or even individually.

Iterative Waterfall Model

Unlike the sequential Waterfall model, in an iterative Waterfall model each step has a logical connection to the previous step. Thus, it is possible to revisit the previous step once it has been completed. Usually this happens in cases where the current step fails, so it is possible to jump back to the previous step and run it again in order to fix the failures that made a correct finishing of the current step impossible.

Figure 4: Iterative Waterfall Model

Abbildung in dieser Leseprobe nicht enthalten

Source: own representation based on Royce, 1970

In situations in which a process has to jump back almost to the beginning, accord- ing to Royce it can be assumed that the financial and time budget of a project will be exceeded by up to 100%²². Therefore, the Waterfall model can be seen as a non-optimal-solution for project management, since errors, bugs and failures can only be discovered late in the process and thus can have a high impact with negative consequences. Also to be mentioned is the fact that the sooner an error occurs and the later this error gets detected the greater the negative impact of this error on the project. The strict Waterfall model can thus be seen as too risky to use for large projects. It is still fundamentally sound, however. In order to increase the applicability, various adjustments can be made that increase the quality of the method. Therefore, the Waterfall model can be extended and adapted in several ways.

More Waterfall-based approaches can be found in Appendix 2.

In addition to these Waterfall-based approach variations, the basic Waterfall approach has had a strong influence on other approaches. One of the most common evolutions of the Waterfall Model is the V-Model.

2.2.2 V-Model

The V-Model is a process model, which has been in its present form evolved to an often used standard for computer science projects in many areas. It supports the work of projects by specifying results and processes so that at no time unnecessary work and possibly no idle periods occur. In addition, the V-Model controls the communication between clients and contractors to eliminate typical sources of misunderstandings between the parties.

In its basic form, the V-Model first appeared in 1979 in its introduction by the US software engineer Barry Boehm²³. The V-Model is based in its original form on the Waterfall Model²⁴, which also assumes that the respective phase results can be regarded as binding rules for the next lower stage of the project. It is based on the implementation of the software life cycle, which is represented by structured phase transitions. In Germany, the V-Model has reached an outstanding significance since it has become a development standard for the planning and implementation of IT system development projects of public authorities in Germany since the late 1980s.

Considerations that led to the current V-Model XT ²⁵ were driven in particular from military circles of the BRD²⁶. First approaches based on the 1979 model developed by Barry Boehm started in 1986. At that time, it was decided to create a self-developed model, as the already existing process models^{27 28} did not fulfill all requirements. In 1988, the first version of the V-Model was released as a result of the project SEU-WS²⁹, which was further developed by 1990^{30 31}. Subsequently, it was set up in 1991 in defense technology. The object of the model was to serve as a binding standard to indicate which activities are to be used for the development, maintenance and modification of IT systems and which products are to be built. In 1992, the standard was first introduced as a V-Model 92 in the civilian authorities’ area.

The V-Model is regularly updated to reflect the state of the art of software de- velopment. The A 2005 V-Model XT³² was defined as a uniform standard of development in the public sector, since, in this version, the results are the focus and not, as before, the activities. Thus, the V-Model XT goal- and results-oriented process passes through all phases of the development project process. Further in- formation about the V-Model XT can be found in Appendix 4.

Description

The V-Model by Boehm is an extension of the Waterfall Model, which also includes development tasks and measures for quality control and quality assurance. These regions are also referred to as verification and validation. The function of the V-Model is to regulate the entirety of all activities and products for IT system development processes. For this, the V-Model also provides a work plan and a definition of the product states and shows the logical dependencies between activities³³ and products ³⁴.

The V-model structures the software development process similar to the Waterfall Model in a sequential series of phases. As a major improvement, it emphasizes the togetherness of products and their tests³⁵. However, it is just like the Waterfall Model very vulnerable for errors in early stages, which can in cases of later discovery lead to a significant cost for their correction³⁶.

The original basic V-Model by Boehm includes the following layers:

- Basic idea or urge³⁷

-System specification

- System design

- Module specification

- Implementation

Figure 5: The basic V-Model

Abbildung in dieser Leseprobe nicht enthalten

Source: own representation based on Wirsing, 2007

A theoretical project flow could for this reason expected to be as follows:

At the beginning of the project is the idea that is on the client side either to be applied on an existing or a completely new system. Based on this idea, a system specification is created for that, on the basis of the target system, acceptance tests are defined in close collaboration with the customer. In a subsequent step, the system design is created. For this, integration tests must also be defined in conjunction with the customer.

On the basis of the system, a module specification including the module tests must be specified before the application finally goes into the actual development in a last step.

After successful completion of the module tests the system- and then acceptance testing is carried out before the whole system goes into the final system operation.

If an error occurs in one of the test-phases³⁸ the project will jump back to the respective design and specification side represented on the opposite side of the V-Model. Thus, a critical error in the acceptance tests would lead to a further revision of the requirements definition, or a critical error in the system tests to a revision of the system design, etc.

Figure 6: Theoretical approach of a V-Model in practice

Abbildung in dieser Leseprobe nicht enthalten

Source: own representation based on Wirsing, 2007

In a practical example, this theoretical approach could be represented by the following parts or phases:

1. Problem Description: characterization of the problem

2. User requirements: user requirements for the system

3. Developer Requirements: Requirements of the developers of the system

4. System Design: Structure and function of the target system

5. Components requirements: requirements that are placed on individual components of the software

6. Component Design: Software Design of the individual components of the software system

7. Component implementation: implementation of the components

These phases are means to obtain the following objectives:

- Executable components: verification of finished part components by compo- nent tests

- Executable system: integration and system test of the system

- Applicable system: Acceptance test at the customer

- System used: use by customers

The individual phases of the V-model and the resulting objects can be illustrated by the presentation in the following figure:

Figure 7: The V-Model in a practical example

Abbildung in dieser Leseprobe nicht enthalten

Source: own representation based on Wirsing, 2007

In addition to the mostly sequential processing methods Waterfall and V-Model, there are also other approaches, which take a little less rigid course. One of the most popular approaches is the so-called Spiral Model.

2.2.3 Spiral Model

The Spiral Model by Barry Boehm is a risk-driven Model of the family of traditional project management models. It was developed in a time in which most experiences with software projects were mostly negative. Either, customers’ needs were not respected sufficiently; too many parts were developed multiple times; programs were unreliable or costs rose beyond the agreed limits³⁹. This is where the spiral model and its extensions tried to make improvements.

The first application of the spiral model was the development of corporate software for TRW, where Barry Boehm worked. In this case, the first specification for the spi- ral model has been committed. Although, the spiral model was already established in 1978 and was first tested between 1980 and 1982 with a project of 15 people, the first real application in a team of more than 100 people happened between 1988 and 1992 instead⁴⁰. Reasons for such reluctance could have been determined by the high administration costs of the model, a usually too small project size or the lack of inclusion of the interests of all involved participants.

In a contrary to the Waterfall Model, the spiral model is no longer a linear structure, but - as the name suggests -, like a spiral. It is therefore also known as iterative and incremental phase model because the phases of the Waterfall Model are to be run several times. Cost transparency, flexibility, reusability and new management theories find their place at both the customer wishes to be more concerned but also to give the developers a tool that should save a lot of time and effort. In this case, the project is approaching the targets slowly, even if the goals change during the progress of the projects. The peculiarity of the spiral model is that it may integrate different process models⁴¹ as needed.

Description

A software development project that uses the spiral model aims to create a more and more refined product by running through multiple repetitions of the same sequence of steps. With each sequence, the product gets closer to the desired result until all requirements met.

In the usual approach⁴² the procedure consists of four different steps^{43 44} in a cycle.

These steps represented in the four quadrants of the following Figure can be:

- Determine objectives, alternatives and constraints

- Evaluate alternatives, identify and resolve risks

- Develop and verify next-level product

- Plan next Phase⁴⁵

Figure 8: The Basic Spiral Model

Abbildung in dieser Leseprobe nicht enthalten

Source: own representation based on Boehm, 1988 and style of Wirsing, 2007

These steps are always processed in the same sequence, wherein the respective expression and means can vary depending on the focus of the spin. In general, these steps within a spin could be realized in practice as follows⁴⁶:

Figure 9: The Spiral Model in practice

Abbildung in dieser Leseprobe nicht enthalten

Source: own representation based on Boehm, 1988 in style of Vanja, 2007

Prerequisit

The spiral is initialized by the assumption that a specific process (Within the company or at the customer) can be improved by a software solution. The formu- lation of this objective and the creation of concrete proposals for solutions make the beginning of the first spiral spin^{47 48}.

Determine objectives, alternatives and constraints

At the beginning of each cycle, the determination of the objectives and what has to be achieved in this spin has to be defined. It needs to be defined which level of performance has to be met, which functionalities should be given or which issue has to be solved, etc.. Furthermore, alternative means to implement these features like the choice of a particular design pattern, the reuse of specific approaches or which method in particular is to be used needs to be defined. Also “Make or buy”⁴⁹ decisions and the constraints imposed on the implementation of the respective alternatives need to be taken into consideration⁵⁰. As a framework restrictions in terms of time, personnel, costs, hardware and software environments are to be defined. This framework is obligatory for the entire spin and is the main criteria for success or failure of the respected spin⁵¹.

Evaluate alternatives, identify and resolve risks

In the second phase of the current spin, the alternatives in terms of the objectives and constraints are analyzed and evaluated. Usually, questions and uncertainties appear that make every decision for or against an alternative (or sometimes even the rejection of all alternatives) an unsafe decision. But unsafe decisions mean potential risks for the project. The degree of uncertainty or risk should, for this rea- son, be⁵² reduced as much as possible. To ensure minimal risks diverse techniques such as prototyping, simulation, data modeling, benchmarking, market research (by conducting serveys) or literature searches can be conducted. The decisions for the activities of the third stage of the current spin (and the other project work in general) in particular now be based on the remaining residual risk. Therefore, it has to be kept in mind that the minimization of the residual risk shall always be the focus of future actions⁵³.

Develop and verify next-level product

In the third phase of the current spin the development and verification of the software product takes place. Here, the typical development phases of design, implementation, system test and final test are conducted and documented. Also, the chosen alternative is implemented and tested in compliance with the objectives and resources requirements. The methodical procedure can be used in consideration of the residual risk and the flexible using of the entire software engineering repertoire by considering an evolutionary approach to transformational development with an increased focus on re-use. The choice of a method or a reasonable combination of several approaches is an exclusive choice for the current step only and should always be risk-oriented⁵⁴.

Planing the next Phase

At the end of the current phase, the content and organization of the next spin is planned on the basis of the current project status. The planning must not be limited to the immediately following period. Rather, it can affect multiple turns. Is also permitted to divide the project into mostly independent sub-projects. These sub-projects can be carried out in parallel by different development teams and are not necessarily to be carried out by the same participants that were responsible for the respective step in the previous spin⁵⁵.

The spiral ends if the original assumption, that a specific process can be improved by a software solution, fails the test. Otherwise, the spiral ends with the installation of new or modified software, and the assumption is tested by observing the software during use. Often this leads to the creation of new assumptions that will lead to the improvement of the software and a new maintenance scroll is initialized to put the new assumption to test^{56 57}.

The mentioned approaches Waterfall, V-Model and Spiral Model are due to their frequent application very famous and prominent examples for traditional project management methodologies. However, there are also countless other traditional process models, and always new ones are added. In the following a brief overview over a few other approaches is made in order to give a deeper general overview.

Additional traditional Process Models can be found in Appendix 3.

2.3 Agile Project Management Methodologies

Especially in projects that are bringing together many different affecting factors to consider, agile approaches have been used for some years, mainly Scrum and Extreme Programming (XP). These methodologies come from the software devel- opment sector and have so far mostly been used in software development. However, it is an evident trend that these agile approaches are finding their way more of- ten into practice in other corporate divisions (and even in industries with high expectations for their security such as Banks, Insurance Companies, the Medical Industry, and so on). Because agile approaches are becoming more widespread, even hardened professionals in traditional project management have to consider the idea of agile project management and its benefits.

In this context, the question of what makes these agile approaches so attractive in contrast to traditional project management has to be examined.

Methodologies that that are nowadays designated as agile approaches, such as Scrum, Extreme Programming, and the entire Chrystal Family, all have their own evolutional history of development, with roots in the 1990s. In February, 2001 the leading representatives of each of the commonly known methodologies gathered and adopted a collective credo, the A gile Manifest ^{58 59}. Since then, these methodologies have all been grouped under the collective term “Agile Approaches”, and are mainly designed to approve software development and its strategies and procedures. Thereby, the Agile Manifesto leaves no doubt that it has been designed by software developers and for software development teams.

In recent years, a change in the interpretation of these approaches to seeing them as general approaches for project management matters has occurred. Even the initiators as well as consultants and authors have eagerly adopted this view. From a project management point of view it appears that the most profitable approach seems to be the Scrum approach, since it mainly describes a simple planning and steering process for the management of a general development project. In this context development cannot necessarily be understood as software development but rather as the general development of generic processes of different kinds. It can also be applicable to very diverse undertakings such as building and construc- tion projects, the organization of major events, financial management, human resource management projects, and so on, since it describes the general proce- dure of planning and steering and not the very steps themselves. However, the other agile attempts very specifically involve methodologies for software develop- ment. This appears to be the reason Scrum seems to have spread the furthest so far.

The agile approaches differ from classical project management first in the accentu- ation of four “agile values”, described in the Agile Manifesto:

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:⁶⁰ ”

- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan⁶¹

That is, while there is value in the items on the right, we value the items on the left more.

With these principles along with the “Twelve principles of Agile Software Develop- ment”⁶², the people in the project obtain a higher importance compared to other resources in the project. All agile approaches are aimed strongly at creating a pleasant, productive working environment for the employees of the project team and promoting the communication within the team. The author would like to point out that in his opinion the most important resource in agile project man- agement are the people in the project. These project members have to bring the virtues of traditional project management to life to obtain the agile goals of the project by utilizing these virtues.

When considering these ideas with regards to software projects (although in fact these ideas do also apply to almost every other project context), the participants in the projects make the biggest contribution to the success of a project. They are also the resources that are the hardest to organize, and the knowledge and contribution of every project member are difficult to document and quantify. In this respect, focusing on individuals and the interaction of the project members with each other is ultimately equivalent to the production optimization which is a natural standard in industrial production.

It is also the author’s opinion that the Agile Manifesto does not describe the tra- ditional project management virtues such as processes, tools, and the dedication to the project plan as bad, as is often claimed. These virtues are to be seen as a prerequisite to obtaining the given goal and will help to illustrate where the weaknesses of traditional project management are.

2.3.1 Scrum Model

This chapter examines the agile methodology, Scrum. The focus in particular lies on the role of the participating project members, the general approach, and the artifacts that appear within the runtime of the project. By the end of this chapter, the author will make a critical assessment of the pros and cons of using Scrum in a project management environment.

The term “Scrum” originally comes from the vocabulary of rugby, and describes a special move in which both teams stand wedged up face to face and try to capture the ball (Source). Scrum is based on only a few clear rules. Contrary to received opinions, Scrum is not only a software development methodology, but is also suit- able for many different undertakings that need to be planned and managed⁶³. Its high level of flexibility, versatility, and the lack of rules make it an appropriate methodology for managing projects of different kinds even outside of the software development sector.

Description

The vision of a Scrum project is held and prioritized primarily by the product owner in distinct requirements within the product backlog. Other project members and stakeholders may contribute suggestions and ideas to the product backlog, but the final decision about which requirements will be implemented lies with the product owner. The product backlog can be extended and changed at any time.

The process flow of a Scrum project is divided into iterative work-cycles – the so called “sprints”.

A sprint expands over a defined period which, in practice, is not more than 30 days. A project can consist of any number of sprints depending on how large a project is and how much time has been planned for it⁶⁴.

Based on the product backlog, the product owner and the project team define the scope of the sprint backlog in a sprint planning meeting, which should last no more than 8 hours. The sprint backlog includes all the tasks of the product backlog that the team intends to finish during the first sprint. To this end, the product owner presents the possible tasks during the first half of the meeting. In the second half of the meeting, the team decides about the tasks and gives a rough estimation of the effort required. Here, the general tasks of the product backlog are divided into concrete work procedures, whose extent should not exceed eight hours in the framework of single process steps, and sixteen hours in the framework of consolidated group work⁶⁵. This way it can be guaranteed that these tasks can be finished within a single working day. Time estimations of more than 8-16 hours for each working step are possible, but can be seen as placeholders that have to be divided into smaller pieces at a later stage of the process.

The team commits itself to the product owner to complete the agreed-upon working steps until the end of the sprint. Due to the fact that the team is self-administering, it is important that the team is the only party that is allowed to make changes to the sprint backlog. The Scrum master is present during the entire meeting. However, his function is limited to moderating the meeting without interfering actively. Also he ensures that the guidelines of the Scrum methodology are adhered to^{66 67}. The team works independently in the period of the sprint and is self- organized. The selection of tasks and their implementation are therefore carried out at their own discretion. Also, the selection of standards, work practices, and tools to be used is done solely by the team. On each day of the sprint a team meeting is held in which the following questions have to be answered:

1. What has been done since the last daily Scrum meeting?
2. What has to be done before the next daily meeting?
3. What are the obstacles that stand in the way of doing it?

The goal here is that the team coordinates itself by means of the daily Scrum meeting in order to eliminate obstacles systematically and at an early stage. The Scrum master is also present at these meetings in order to monitor the activities and intervene if necessary^{68 69}.

At the end of each sprint cycle, a sprint review takes place. In this meeting, the finished results are presented to the product owner. The product owner reviews and approves the results, if the results meet his expectations. Thus, within the sprint review new or changed requirements may appear that have to be implemented with the next sprint⁷⁰. Directly after the sprint review a sprint retrospective takes place, in which the realized results and the approach used are analyzed critically. This retrospective serves to reflect upon the results and the processes in order to draw conclusions from the past steps and improve the approaches for the upcoming steps⁷¹. After the completion of the sprint, the next sprint planning meeting usually occurs in order to start the next iteration. A Scrum-Process can therefore be depicted as follows:

Figure 10: The Scrum Process

Abbildung in dieser Leseprobe nicht enthalten

Source: own representation based on Schwaber, 2004 P.6

[...]

---

¹ Additional information about the History of Project Management, the Current State of Project Panagement or Project Management and its benefits can be found in Appendix 1

² cf. Treppper, 2012 P.28-30

³ cf. Jürgen Zimmermann, 2006 P.44

⁴ cf.Corsten, 2000 P.28-30

⁵ cf. Corsten, 2000 P.7-10

⁶ cf.Peter Stahlknecht, 2004 P.461

⁷ Determinism is understood as a state in which the whole world has an unambiguous condition at any certain point of time

⁸ Further information about heroic management styles and a critical examination of heroic management provides Pinnow with his primary analysis of traditional project management (cf. Pinnow, 2012 P.87-88) or Bourne with her impression of a heroic project manager (cf.Bourne, 2010)

⁹ cf. Jürgen Zimmermann, 2006

¹⁰ cf.Peter Stahlknecht, 2004 P.461

¹¹ cf. Jürgen Zimmermann, 2006 P. 5

¹² cf. Wieczorrek, 2007 P. 64

¹³ cf. Royce, 1970

¹⁴ Institute of Electrical and Electronics Engineers

¹⁵ Royce, 1970

¹⁶ cf. Pichler, 2013

¹⁷ cf. Rerych, 1970

¹⁸ cf. Royce, 1970

¹⁹ cf. Pichler, 2013

²⁰ cf. Rerych, 1970

²¹ cf. Royce, 1970

²² cf. Royce, 1970

²³ Also known as the inventor of the Waterfall Model and the Spiral Model, as well as other variations which can be found in his numerous publications in the field of process models

²⁴ cf. Chapter 2.2.1

²⁵ eXtreme Tailoring

²⁶ Bundesrepublik Deutschland = Federal Republic of Germany

²⁷ Like the US-American Standard DoD STD 2167

²⁸ cf. Duff, 2011

²⁹ Gernam translation: Softwareentwicklungsumgebung für Waffen- und Waffeneinsatzsysteme

= Software development environment for weapons and weapon systems

³⁰ cf. Bröhl and Dröschel, 1993

³¹ cf. Duff, 2011

³² eXtreme Tailoring

³³ Activities are grouped into main activities and parsed into sub-activities

³⁴ The product can be structured in partial products

³⁵ cf. Bröhl and Dröschel, 1993

³⁶ cf. Selby, 2007

³⁷ As a prerequisit for evey undertaking

³⁸ Integration, System or Acceptance Tests

³⁹ cf. Boehm, 1988

⁴⁰ cf. Chroust, 1992

⁴¹ cf. Chapter 2.2 or Appendix 3

⁴² Definition pursuant to Boehm, 1988

⁴³ cf. Boehm, 1988

⁴⁴ cf. Selby, 2007

⁴⁵ cf. Boehm, 1988

⁴⁶ cf. Boehm, 1988

⁴⁷ cf. Boehm, 1988

⁴⁸ cf. Vanja, 2007

⁴⁹ The act of choosing between manufacturing a product in-house or purchasing it from an external supplier

⁵⁰ cf. Boehm, 1988

⁵¹ cf. Vanja, 2007

⁵² Always taking into account the associated costs

⁵³ cf. Boehm, 1988

⁵⁴ cf. Boehm, 1988

⁵⁵ cf. Boehm, 1988

⁵⁶ cf. Boehm, 1988

⁵⁷ cf. Vanja, 2007

⁵⁸ cf. www.agilemanifesto.org

⁵⁹ Beck, 2001

⁶⁰ cf. Beck, 2001

⁶¹ cf. Beck, 2001

⁶² cf. Beck, 2001

⁶³ cf. Wolf and Bleek, 2008 P.149

⁶⁴ cf. Schwaber, 2004 P.8

⁶⁵ cf. Highsmith, 2002 P.269–273

⁶⁶ cf. Highsmith, 2002 P.246

⁶⁷ cf. Schwaber, 2004 P.7-9

⁶⁸ cf. Highsmith, 2002 P.245–247

⁶⁹ cf. Schwaber, 2004 P.8

⁷⁰ cf. Schwaber, 2004 P.8

⁷¹ cf. Schwaber, 2004 P.9