Identification of successful factors in the project management for the effectual implementing of consolidation software

Table of contents

Index of figures

Abbreviations

1. Problem statement

2. Structure and solution

3. Terms and basic
3.1 Project
3.2 Delimitation IT-Project
3.3 Aims of the project and benefits of the project work
3.4 Consolidation software
3.5 Risk
3.6 Riskmanagement

4. Causes of project failures

5. Successful factors in the project management

6. The phase model of a software introduction
6.1 Initialization phase
6.1.1 Aim and project definition
6.1.2 Calculation of profitability
6.2 Choice phase
6.2.1 Requirement definition
6.2.2 Market elevation
6.2.3 Preselection
6.2.4 Detailed evaluation
6.2.5 Contract negotiations
6.2.6 Project order
6.3 Project planning
6.3.1 Project organisation
6.3.2 Project manager
6.3.3 Project team
6.3.4 Milestone
6.3.5 Work breakdown structure
6.3.6 Schedule, resources and cost plan
6.4 Project realisation
6.4.1 Kick-off
6.4.2 Data migration
6.4.3 Training of the project team
6.5 Project control and management
6.6 Project riskmanagement
6.7 Project closure

7. Final consideration

8. Index of tools and sources

Index of figures

Fig. 1 Project classification in accort with the project size

Fig. 2 Magic triangel

Fig. 3 Successful factors of the project management

Fig. 4 Project life cycle

Fig. 5 Pattern sheet project order

Fig. 6 Project planning in steps

Fig. 7 Core tasks of the project manager

Fig. 8 Project manager's profile: Knowledge and experiences

Fig. 9 The project manager

Fig. 10 PDCA-cycle

Fig. 11 General regulation circuit of a risk management system

Abbreviations

illustration not visible in this excerpt

1. Problem statement

To circumscribe the problem formulation of this study work, a demolition of the group development of the present enterprise is necessary first:

With the RKH it concerned from 2005 to 2008 a strategical partnership of the ‘Enzkreis- Kliniken gGmbH’ and the ‘Kliniken Ludwigsburg-Bietigheim gGmbH’. In 2006 the administrative district Ludwigsburg and the ‘Kliniken gGmbH’ have taken care successfully of the acquisition of the ‘Orthopädische Klinik Markgröningen gGmbH’ including their subsidiary ‘Ortema GmbH’ and have these acquired 7/1/2007. In the course of 2008 the municipal-political committees of the clinic group have expressed themselves to accept the hospitals of Bruchsal and Bretten by the 1/1/2009 in the strategical partnership. Besides, the companion's representatives have decided on the society-juridical interweaving after the present holding company model of the clinic group. Hence, the administrative district Karlsruhe has founded the ‘Kliniken des Landkreises Karlsruhe gGmbH’ and has transferred its hospitals into this society. Their subsidiary ‘Service Dienste Landkreis Karlsruhe GmbH’ has introduced the ‘Kliniken des Landkreises Karlsruhe gGmbH’ also in the group.

To itself in the course of the years developed group structure it has brought with itself that the enterprise was obliged to create a consolidated financial accounts, also named as the consolidated financial statements (cf. Bückle-Ulrich 2008: 13). This task was mastered up to now - like at many middle class groups - with the calculation programme MS Excel (cf. Bückle-Ulrich 2008: 4).

Nevertheless, on account of the steady growth of the medical centre group this procedure bumped to its borders and was not thereby safe about check also any more. Also the organizational winding up of the data procurement could not be looked more than economically. The question was: How do we come for a more efficient and quicker solution? Hence, the department of Finances decided to the implementing of consolidation software, with which help to it annual accounts faster - because more automated - and allows closing safer.

2. Structure and solution

This project work should serve the reader for it, the causes for the project defect runs - which appear as especially frequent in practice - to indicate and to show the factor of success standing with it in connection.

To give an orientation to the reader, the bases and therms of the present riding are treated first. Afterwards the causes are indicated for project defect runs as well as the matching successful factors of the project management and puts under by representative studies.

Finally this study work shows a guide to the effectual implementing of software in the enterprise in which the conditions on successful project work will underline, in addition.

Because the basic aim of this study work, the disclosure of the successful factors is in the project management, are the contents primarily of organizational nature. Hence, on technical contents of the consolidation software it is entered only on the edge.

3. Terms and basic

In the following chapter terms treated within the study work are explained closer to put them for the reader in the right connection, because in the literature to these terms an often differentiated understanding exists. Because it concerns at the present work a software introduction, it is entered in addition to the general definition also on the specific features by IT projects.

3.1 Project

If only the sole word sense of this term is considered, a project is simply to be called a plan (cf. Frühauf & Ludewig & Sandmayr 2002: 10). If one follows the definition of the DIN-standard, a project is called a plan which is marked above all by the uniqueness of the conditions. Under conditions the objective, temporal, financial and personnel limitation, as well as the distinction compared with other plans or an organisation specific for project becomes in this connection called (cf. Gaulke 2004: 1).

Therefore, are processes or litigations which are carried out constantly not to call a project, because they do not need the proven methods, techniques and organizational basic conditions - which have proved themselves in the project management - also. (cf. Tiemeyer 2011: 209)

The meaning of the project result shows to itself for the principal as especially striking, because it itself also directly on the enterprise strategy or refers to its derived corporate objectives. (cf. Gaulke 2004: 1)

The scope and the complexity lets themselves class team size, duration and the budget with the help of the signs. In general it can be said that a project always owns a predefined end time point and should not last shorter than two and longer than five years. (cf. Gaulke 2004: 2; Tiemeyer 2011: 210)

illustration not visible in this excerpt

Fig. 1: Project classification in accort with the project size (Tiemeyer 2011: 210)

The feature which applies with all projects is the uniqueness of the task. In other words a project is in its respective form, a not recurring task what means that the set tasks are mastered new for the project partners and which were never managed before. (cf. Gaulke 2004: 1) Therefore it is necessary to compose and to organise the available know-how over and over again anew (cf. Tiemeyer 2011: 210).

The screening of the project signs absolutely makes sense, because every project needs a special - on the setting of tasks conformistly - form of the organisation (cf. Tiemeyer 2011: 209).

To sum up, it can be said that a project is to be considered on account of its uniqueness, the extent and the complexity and the new nature of the duties in general as risk-afflicted (cf. Gaulke 2004: 2).

3.2 Delimitation IT-Project

The IT project does not differ first from the present definition. These are rather farther signs which put out this special kind of project, because the success is stamped primarily from the choice, analysis, development, servicing, advancement or introduction of the IT system. (cf. Gaulke 2004: 2)

A particular importance can be awarded the expenditure evaluation and cost evaluation which is to be calculated with IT projects especially hard. The real added value establishes the central question by the use of software, because the investment in an IT project must be profitable. (cf. Feyhl 2004: 1-2)

Because project work walks along seldom with restructuring or optimisation, presently this project kind is very often found in enterprise, because process changes are often supported by the application of software. The individual software - which is cut on needs belonging to enterprise - or standard software is to be distinguished here. Just latter is to be found particularly in the business area frequent and also component of this study work. On the topic of the individual software it is not entered here, therefore, further. (cf. Gaulke 2004: 2)

Another differentiation is made with the help of the release for the project. This happen either inside by the enterprise guidance or specialised division or externally about principals foreign to enterprise, like IT software houses or system houses. The side which releases the project gives mostly also possible objective and the results to be expected. (cf. Tiemyer 2011: 210)

In the literature it is gone out in connection with IT projects often from the software development. Nevertheless, the implementing of consolidation software belongs also to the kinds of IT projects, because tools to be used and expiries differ not substantially.

3.3 Aims of the project and benefits of the project work

In the literature the project aims become classically a time, costs and performance/quality summarised in the form of the ‘magic triangle’, in three aim dimensions. These factors stick together in constant dependence. If for example, the project time increases, this leads to an automatic increase of the costs. (cf. Mertes 2002: 142)

illustration not visible in this excerpt

Fig. 2: Magic triangle

(cf. Kuster & Huber & Lippmann 2011: 6)

It is important that the aims to all project partners are known and also are clearly communicated. By no means may it happen that quarrelsomeness exists between the aims or that the project is supported even only by certain personal groups in the enterprise. Only if all project members has understood the aims and could have turned inward lead a project to success. (cf. Schlick 2011: 190)

Project work affects the enterprise advantage in many respects extremely positively. Hierarchy is broken up by the particular organisation form and is created by quicker process winding up competitive advantages, or is received. The innovation strength thereby improves and raises at the same time the efficiency of the enterprise. Further the adaptability and flexibility is increased; with the market position as well as with the employees. (cf. Schlick 2011: 185) Not only time but also money is saved to the enterprise by this approach (cf. Boy & Dudek & Kuschel 2006: 13).

3.4 Consolidation software

If a group consists of many enterprises, the application of consolidation software is recommended. This system makes possible to bring together the annual accounts of the daughters in such a way that finally the consolidated whole end of the mother originates, while the information from the offshore ERP system is imported in the consolidation software.

Often it is in such a way that the single annual accounts are constructed according to another law - as for example US-GAAP - as the being valid - as for example HGB - the group mother. This makes every now and then a row of adjustment entries and reclassifications inevitably around all annual financial statements in a uniform assessment level to agree. (cf. Busse von Colbe & Crasselt & Pellens 2001: 482)

In many enterprises these duties are carried out still with the calculation programme MS Excel.Fehler! Textmarke nicht definiert. This procedure, nevertheless, rescues high sources of error and is not clear from a certain enterprise size also any more and, besides, is very susceptible to mistake. Therefore, consolidation software offers an integrated whole solution for the coping of this big task to the user. (cf. Bückle-Ulrich 2008: 68)

3.5 Risk

By risk is understood the danger which hinders an enterprise in it be to themselves to achieve put aim. Risks in this connection can be incidents or actions which originate in the internal and external project sphere. Factors are here to be mentioned like environment, market, society, finances, reliability, economy, person, technology and law. (cf. Gaulke 2004: 4)

However, the specific peculiarity of a risk consists in the fact that cannot be said whether or when and in which dimensions it appears. However, this connection must not be understood only as a negative dimension. Though the term of the risk is rather a danger of the project aims, but also to consider as a chance to the overwork of the project aims. The plausibility of the incoming risk can be determined with the help of the probability calculus. The dimension of the damage to be expected is normally expressed in monetary units. (cf. Gaulke 2004: 3-4)

Further the term is to be differentiated in event risks and condition risks. An event risk consists, for example, if an approval was given too late. Of a condition risk it is spoken possibly with dependence to external participants. In general it can be said that every risk of a cause is defeated and indicates by admission a suitable effect. The costs, the schedule and the quality of the results are concerned by the effects. (cf. Gaulke 2004: 4) The causes can be further distinguished in categories:

- Technical, qualitative or achievement-related risks
- Project management risks
- Organizational risks
- External risks

(cf. Gaulke 2004: 5)

3.6 Riskmanagement

Also for the term of the risk management there is specifically - however, rather in the abstract - the formulated DIN-standard which defines the expression as a systematic use of management principles, management procedures and management methods for the purpose of determination of the context as well as identification, analysis, valuation, control/coping, supervision and communication of risks. (cf. Gaulke 2004: 7)

Translated - in the operational perception - all measures are meant about the timely statement, judgement and solution of the possible risks which could endanger the success of the enterprise. Also belongs to it to recognise early unfavorable developments, just as to identify new, up to now unknown risks. (cf. Gaulke 2004: 6)

4. Causes of project failures

There are studies which the backgrounds of failed projects analysed ones numerously. This chapter will lead in the following some of these studies to show the most frequent cause. By the arising of the overlap rate, becomes clear by where the typical risks lie.

In 1994 the KPMG Strategic and Technology Services carried out a survey at enterprise in Great Britain by means of phone questioning. In 120 conducted interviews 46 of the interviewees indicated to have had no project defect runs. From remaining 74 statements the following trend was mentioned in causes: (cf. KPMG 1994: 5-6)

- Project aim defines not enough
- Bad planning and estimate
- Application of new technologies
- Insufficient project management methods
- Lack of experienced employees in the project team
- Bad achievement of the suppliers of hardware / software
- Wrong cast of the position of the project manager
- Insufficient software development methods
- O project aims
- Wrong cast of the project team
- Bad communication between project members
- Missing knowledge about project problems with the management (cf. KPMG 1994: 12)

With another study of KPMG Management Consulting it was questioned in 1997 to the 1,450 biggest, public Canadian enterprises too fail IT projects. 176 evaluated answers of it proved that 87% of these failed IT projects excelled the deliberate schedule about more than 30%. With 56% the estimated budget was crossed in the same relation and 45% did not only at all achieve the expected use. As three principal reasons an insufficient project planning, the weak connection to the commercial strategy and the lack end inclusion and support by the management were mentioned. (cf. Whittaker 1997: 23-24)

As another questioning carried out by KPMG the ‘Programme Management Survey’ is to be mentioned. From 134 questioned international enterprises whole 56% indicated to have experienced at least one failed project during the last 12 months. (cf. KPMG 2002: 1) As principal reasons for the failure were mentioned:

- Lacking support by the management
- Insufficient requirement management
- Insufficient and/or too ambitious project planning
- Missing resources
- Insufficient communication between IT and business division
- Missing connection with the commercial strategy
- Bad quality of the supplied software (cf. KPMG 2002: 3)

The journal Computerwoche has also begun in 1997 a survey on the subject project management. Moreover 3,500 questionnaires were dispatched to German enterprises. From 182 back runners became from 14 problem fields, evaluated the problems with IT projects. The most frequent namings were:

- Unclear requirement analysis
- Too time-consuming realisation
- Unclear project order
- Missing experience in new approaches
- Unfavorable team occupation or allocation of duties
- Missing project planning-know-how

(cf. http://www.computerwoche.de/heftarchiv/1997/44/1102400/: 2012/10/19)

The investigation of the causes for failed projects also made the Standish Group International Inc in 1995 the job to itself. 365 American IT managers from the most different branches were questioned. (cf. Standish Group 1995: 2) Seven several times repeated reasons were:

- Incomplete demands
- Missing user connection
- Lacking resources

[...]