Eidesstattliche Erklärung
Index of Figures
Index of Tables
1. Introduction
1.1 Example project
1.1.1 Project organisation
2 Problem definition
2.1 Introduction to software development
2.1.1 The nature of software
2.1.2 Development process
2.1.3 General problems of software development
2.2 Goal of the thesis
3 Management
3.1 General Management
3.1.1 Strategy
3.1.2 Structure
3.1.3 Culture
3.2 Effective Management
3.2.1 Principles
3.2.2 Tasks
3.2.3 Tools
3.2.4 Applicability
4 Team
4.1 Viable System Model
4.1.1 Application to software development
4.1.2 Applicability
4.2 X-Teams
4.2.1 Application to software development
4.2.2 X-Teams compared to VSM
4.2.3 Applicability
5 Customer
5.1 Customer involvement
5.1.1 Eliciting requirements
5.1.2 Customer Reviews
5.1.3 Testing
5.1.4 Design and modelling
5.2 Clear business objectives
5.3 Change management
5.4 Support of senior management
6 Evaluation
6.1 Approach
6.2 Rating
6.2.1 Management
6.2.2 Team
6.2.3 Customer
6.3 Results
7 Conclusions
7.1 Possible weaknesses of evaluation
7.2 Possible project improvements
8 References
Index of Figures
Figure 1: Project organisation of the example project
Figure 2: V-Model
Figure 3: Strategic navigation system, (adopted from Malik 2007, p186)
Figure 4: The Viable System Model (Beer 1985)
Table 1: Extract of evaluation results
In the last decades Information Technology (IT) has become vital for every company. And, a company not using IT would be unimaginable today. Primarily, IT was merely used for accelerating existent processes. Mostly standardised applications have been deployed to standard areas in companies (for example accounting software). Today, IT is an important part for modelling all types of business processes, not only the standardised processes. Furthermore, to gain competitive advantages, mere standard software is not suitable anymore. This is because standard software can not support the requirements of individualised processes, necessary for doing business better than the competitor. Therefore, either standard software is customised for supporting individualised processes or a company decides developing individualised software from the scratch.
Often companies decide to develop individualised software on their own because of the following three reasons: First, the process knowledge is important for gaining competitive advantages and this confidential information must kept inside the company. Second, employees within the organisation have the best process knowledge. Effective transfer of process knowledge to the IT-department can be guaranteed. Third, customising standard software needs much external expertise which is in general expensive.
Often, software development projects have budgets of several million Euros and can cause an even higher reduction of costs. Thus, process and software development has become one of the most important aspects for many IT-departments in today’s companies.
However, managing software developing projects is not an easy task. Many software developing projects are not on time and budget. An analysis of the Standish Group shows that only 26% of all software projects are completed on time and on budget and can provide the predefined functions. On the other hand, excellent developers with sophisticated approaches can increase productivity by ten to twenty times. (cf. Moll 2004) Consequently, the potential of cost reduction is very high. In future, companies have to deploy new information systems more effectively than today. Otherwise companies can not sustain competitive in faster changing markets.
The example project, chosen for this thesis, is a business software project of developing and introducing new Enterprise Resource Planning (ERP) software for a major Austrian Sports Equipment Retailer. The main objectives for introducing new software are internationalisation and standardisation of processes. Additionally, fashion specific features (for example fashion sizes) must be implemented in the software. In other words, the objectives of the software are to gain a stable software platform supporting future business developments.
The project is separated in 5 major modules and is planned lasting for 3 years. The working load for this project is estimated with approximately 10.000 man-days.
Figure 1 below shows the organigram of the ERP software project
Figure 1: Project organisation of the example project
illustration not visible in this excerpt
The organigram is divided into two domains: the customer domain and the IT domain. Each domain is headed by a project leader.
On the customer side there are teams for process development, key-users, rollout and first level support (help-desk). Process development is responsible for designing, creating and implementing business processes. The key-user’s task is to elicit all requirements needed for executing the processes. Deployment of ready software is carried out by the roll-out team. Finally, the customer domain comprises of a help desk, supporting users of already operational software.
The IT domain comprises of the functions IT-coordination, business analysis and software development. IT-coordination has the task to coordinate all IT relevant functions such as business analysis, software development and operations. Business analysis is the interface to the customer and elicits requirements from key-users and the process development team of the customer. These elicited requirements are given to the software developers which create the requested software.
Although there is much knowledge about the development process (development models) and project management amongst managers of software projects, many software projects are not on time and budget. This arises two questions: First, to finish a software project successfully, are there more components beyond software developing process and project management which have to be taken into consideration? And second, which components are important for managing a successful software project?
Before starting to analyse the two questions in detail, a basic introduction to software development is given in the following section.
For an introduction to software development the specific nature of software, basic development models and general problems of software development are presented as follows.
Compared to other products, software products have a particular nature. The most important characteristics of software are shown as follows.
Software is complex and huge: The code of an Enterprise Resource Planning (ERP) software can comprise million lines of code. Also, there is little regularity and there are many paths through the code of software. Therefore, changes in one part of code often have unintended consequences in other remote sections of the code.
Software is flexible: Software is a flexible specification of computations.
Software is easily modified: In comparison to other engineering areas, modification of software is very easy. Basically, only a computer is needed to modify software.
Software is never finished: Because of the ease of modifying and changing requirements, software has a long maintenance phase. The maintenance phase is to be considered as the longest part of the software life cycle and consists of ongoing design and implementation of new features. (cf. Aaby 2003)
Nowadays several approaches for software development exist. But, most of the various processes are based on the original Waterfall Model.
The Waterfall Model was introduced by Winston Royce in 1970 and describes several steps for implementing software. The most important steps are: Analysis, Design, Implementation, Testing and Deployment (cf. Royce 1970).
Analysis: In the Analysis phase of the Waterfall Model, all requirements of the software are defined. These requirements are then checked regarding clarity, completeness and consistency. Clarity, completeness and consistency are also referred to as the “3Cs” of software analysis.
Design: completion of the Analysis phas]e is followed by the Design phase. The Design phase is characterised of “blue printing” the software. Thus, all system requirements and modules of the software are defined.
Implementation: the Implementation phase is the actual coding of software.
Testing: in order to guarantee software quality, software has to be tested sufficiently before setting into operations.
Deployment: the Deployment phase is the introduction of the new product and the actual use of the software.
The Waterfall model has two major disadvantages: First, in theory the sequence of the phases has a strict order. In reality, in the Test phase often a redesign of the software is caused. Second, every phase is started when the preceding phase is completed. In fact, there is a smooth transition from one to another phase.
The V-Model is an enhancement of the Waterfall Model. For every development phase of the developing process a test phase is defined. This refers especially to the quality aspect of software, because in many software projects no accurate time for testing is reserved. Consequently, too little time for testing leads to unproductive usage of the software by the customer.
illustration not visible in this excerpt
Figure 2: V-Model
The V-Model is also the development process chosen by the examined IT department for software development projects.
The V-Model presented in Figure 2 is only appropriate for large software projects, because only in large software projects so many test phases are justified. A general criticism of the V-Model is that the number of project phases leads to expensive project administration. For this reason specific phases in small software projects are not carried out explicitly.
In the mid 1990s a new conceptual software framework emerged, called agile software development. This was a reaction against the “heavyweight” methods such as the Waterfall Model. The founders of agile software development thought, that existing software development processes where too slow, inconsistent and the software project needs much administration efforts. The principles of agile software development are summarised in the agile manifesto:
- “ Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan ” (Beck 2001)
Thus, criticism to agile software development states a lack of project structure and documentation, insufficient software design, requires too much cultural change within a company and inefficiency because of too much coding iterations.
However, some of the agile principles are success factors of software development. For example customer collaboration or responding to changes are nowadays recognised success factors among most software developers.
Due to the special nature of software, software development has some problem areas which have to be taken into consideration for management.
One of the biggest problems is the estimation of schedule and costs of a software project. This is because a software developing project has the nature of a developing project. In the beginning of the project, when the requirements are defined, estimations have to be based on many assumptions. Often a new technology is used for new products as well. Therefore, developers have no experience for accurate project estimations.
Another problem is the definition of software requirements. Generally, requirements should be defined by the users of software, as the users know best what they actually need. On the contrary, users of software are not trained in describing features of software. Often, users do not even know details of requirements. But, these details have to be elaborated, to estimate project costs and to enable design and implementation of the software. Still, another problem occurs when requirements are lacking completeness, then professional testing is not possible. This is because software testing requires a complete set of specifications.
Also, a software team is difficult to manage. Software developers need a high level of education and software developing is creative work. On the other hand, high-quality software follows strict rules of predefined guidelines. Thus, managing creative developers, having plenty of ideas, and adhering at the same time to strict rules, is not easy. Another problem concerning software teams arises in big international companies. To manage an international split software developing team is, despite new communication technology, still a challenge.
Though to the fact that software projects are mostly time consuming and projects can take several years until they are finished, business and therefore requirements of software can change during the development process. This problem could lead to a never finished project, because when developers have finished a new change, there are already new requirements. The worst case occurs, when changes of requirements need a change of software design. This is because a new design leads to another walkthrough, of all steps of the software development process.
Another problem of software development is that every process phase has different requirements and different aims. Theoretically, different specialists would be needed to master the challenges of the particular phases. In reality, project resources are limited and every team member has different strengths. Thus, team members of software projects, must fulfil many different tasks having different objectives. (cf. Feyhl 2004 p127)
The goal of the thesis is a definition of effective software management beyond the scope of development processes and project management. But in which areas are key success factors of software development projects?
To answer this question a stakeholder analysis of a software developing project was made. Stakeholders of software developing projects are software users, process managers, senior managers of the customer, business analysts, software developers, test engineers, senior managers of the software developer, operating team, support team and software developers working on other software which is integrated or connected with the software under development. When these stakeholders are categorised, the following three main groups of stakeholders remain:
- Management of the software project (managers of the software development team)
- Team members of the software project (business analysts, software developers, test engineers, operating team, support team and software developers working on other software)
- Customer (software users, process managers, senior managers of the customer) All these mentioned
All these mentioned stakeholders are important to carry out a successful software developing project. Therefore, each group of stakeholders contains success factors for the software project. For example, the project manager has to make the right decisions that team members can work effectively on the project. Also, the cooperation of different software team members is essential for a high quality and productive software development. And, software requirements have to be defined accurately by the users of the software or by process owners in order to be able to produce software of quality.
The following chapters are dealing with the above mentioned stakeholder groups of software development projects: Management, Team and Customers. Finally, the example ERP software development project is evaluated regarding the main aspects discussed on the basis of the three stakeholder groups.
In Europe and especially the German-speaking region, the management model of St. Gallen, Switzerland, is one of the most accepted and complete management models. Fredmund Malik is one of the leading management experts in St.Gallen. For example Peter Drucker said about Malik that he is the “most important voice of management in
Europe” (Malik 2007). Furthermore, Malik was ranked under the three most important management thinkers of the German-speaking region in 2005. (Weber 2005)
Malik developed several models for different requirements in management. These models are based on the basic sciences systems theory, cybernetics and bionics. For this work several of Malik’s models are used and put into context for software development.
The general aspect of management is covered by Malik’s “General Management Model”. The General Management Model can be applied to all types of organisations and is not limited to manage economic organisations.
The General Management Model comprises of the main parts strategy, structure and culture. These three aspects are connected and dependent on each other. The main parts of the General Management Model are surrounded by the environment. The manger has to control these aspects, to get a balanced system. (cf. Malik 2007)
In the following sections the main parts of the General Management Models are discussed in detail.
Aloys Gälweiler defined strategy as follows: “ Before starting something, to consider systematically, how to act from the beginning, for having long time success ” (Malik 2007, p183). There is no time horizon in Gälweiler’s definition. Furthermore, for Peter Drucker the essential part about strategy is the futurity aspect, which means the future consequences of today’s decisions are important and not future decisions itself (cf. Malik 2007).
Aloys Gälweiler's concept of strategic management defines control quantities, for managing operations and strategy of enterprises. Gälweiler’s concept has the character of a navigation system for enterprises and is shown in Figure 3.(cf. Malik 2007)
illustration not visible in this excerpt
Figure 3: Strategic navigation system, (adopted from Malik 2007, p186)
The first measure of Gälweiler’s concept for enterprises is liquidity. Liquidity is a shortterm measure and is the economical and legal criterion for survival of a company. Although, liquidity is an important measure for a company, with liquidity you cannot control either long term success or strategies of a company.
Profit is a controlling measure of a firm for longer periods. Only profit can be used as an effective pre-control measure to affect liquidity. This is because profit is the logical, causal and chronological predecessor of liquidity. However, controlling liquidity cannot be replaced by controlling profit.
Analogue to pre-control liquidity, measures determining profit like revenue and expense are not suitable as profit pre-control quantities. For pre-controlling profit, Gälweiler moves from operational management to strategic management. Quantities for pre-controlling today’s profit are named “existing potentials for success”. Success is defined by Gälweiler as quantifiable business success or profitability. Two important quantities for determining the existing potentials for success are market position and productivity. Generally, market position is expressed in market shares. The productivity value is depending on the learning curve effect.
Future potentials for success are again quantities to pre-control the existing potentials for success. Essentially, it is necessary to think about how markets will change to remain long-term successful. The most important factors are the customer problem and new technological solutions for the customer problem.
Gälweiler’s navigation system was originally meant to control enterprises and not to control software projects. In the following section an examination is done, under which conditions the navigation system is suitable for software projects.
Gälweiler’s first measure for operational management, liquidity, is in most cases not a suitable operational rate for software projects. Since software project teams are most of the times integrated in a company, there is no rate like liquidity. However, the most important short-term quantity of a software project is the utilisation of employees. The utilisation of employees is depending on a detailed and professional project and resource planning. When team members of a project are underemployed, this means for the project a waste of time and possible risks to meet the schedule. Furthermore, employees having not enough work could be at risk of de-motivation, because they cannot see enough contribution and sense in their work anymore. On the contrary, if employees are overloaded, fluctuation of employees can rise. High fluctuation is a serious inefficiency factor of software projects. This is because project members have a lot of project knowledge and new employees need a long time of initial training to replace existing employees.
Similarly to liquidity, an intracompany project does not generate a measurable profit. Therefore, other measures must be taken into consideration. Project costs and the comparison to the project budget are one of the most important operational measures for project management. These two quantities have always to be viewed in combination. Since a project manager takes solely a look at the costs there is no reference, whether the costs are on budget or not. Another important aspect is the estimation of the project budget in general, which requires accurate project planning. For example, if too few resources are planned for the project, this is often tried to be compensated with overtime for the project members. Looking at this example the pre-controlling mechanism of budget and costs for utilisation of employees is visible. This is an analogical characteristic to profit and liquidity described by Gälweiler.
Existing potentials for success applied to software projects are, as in Gälweiler’s model, dependent on the learning curve effect. Good software can only be produced, if experienced software developers produce the software. The problem of software development is however, the fast changing development of basic technologies. Basic technologies are software components or programming languages, developed products are based on. Fast changing technologies means for software developers, that they need continuous training on new products and processes for software development, in order to counter the learning curve effect. The measure “market position” can be replaced for software development by “customer satisfactory”. If the customer is satisfied with the product, then the project in general has fulfilled its purpose. However, customer satisfaction is even more difficult to measure than the market position. Mostly, surveys, carried out with a representative cross section of software users, show a good result of the quality of software.
Gälweiler’s idea of future potentials for success, is the same, as it is for software developing projects. The key factor for future potentials is the customer problem, which should be solved by a specific software technology. However, in the fast changing software market, there are frequent market entries of new technologies. Some of these new technologies have the potential to solve the customer problem better than existing technologies. In contrary, training software developers applying a new technology, can be very time consuming. Therefore, decisions for new technologies have to be made very carefully. The suitability of the new software technology has to be examined with prototyping. Also, all different aspects for example costs, training, possible technical drawbacks, migration strategy, operations and software manageability have to be taken into consideration.
From Gälweiler’s navigation model, six key values can be derived. These key values are used for controlling a software project similarly to a project balanced scorecard. The six key values for software projects are:
Customer satisfaction can be measured with surveys. Important for the measurement is that all different types of user groups and stakeholders are taken into consideration. Another indicator of user satisfaction is the number of help-desk tickets occurring during software operation.
Rate of innovations: The rate of innovations can be measured how much new technologies have been used in a certain period of time. Also, improvements of the software development process could be understood as new technologies. However, besides a minimum rate of innovations also a maximum rate of innovations must be defined, because too many innovations are decreasing productivity as well.
Productivity is indirectly measured in development hours needed for a specific program module. The development hours are later put into context with the cost-benefit ratio, which was carried out when the program module was planned.
[...]
