Projektcontrollingkonzeption für SE- und IT-Unterenhmen

Inhaltsverzeichnis

Abbildungsverzeichnis

1 Einleitung
1.1 Skizze der Softwareentwicklung und Informationstechnologie Branche
1.2 Notwendigkeit von Projektcontrolling

2 Aufgabenstellung
2.1 Thema der Arbeit
2.2 Struktur der Arbeit und Vorgehensweise

3 Controllinggrundlagen
3.1 Controlling als Instrument der Unternehmensführung
3.1.1 Wesen und Inhalt des Controllings
3.1.2 Aufgaben des Controllings
3.2 Projektcontrolling
3.2.1 Problemstellung
3.2.2 Abgrenzung zum allgemeinen Begriff des Controllings
3.2.3 Die Aufgabenstellung an das Projektcontrolling

4 Controllingkonzept für SE-Unternehmen mit Projektleistungstätigkeit
4.1 Besonderheiten des SE-Projektcontrollings
4.1.1 Begriffsdefinitionen
4.1.2 SE-Projektmanagement und Projektcontrolling im Zusammenhang
4.1.3 Die Abweichungsanalyse von Softwareprojekten
4.2 Das Projektcontrollingkonzept von Lachnit
4.2.1 Anforderungen an das Projektcontrolling-Modell
4.2.2 Grundstruktur eines Controllingsystems zur Erfolgs- und Finanzführung
4.2.3 Das wirtschaftliche Projektcontrolling-Modell PROCON
4.2.3.1 Grundstruktur des Projektcontrolling-Modells PROCON
4.2.3.2 Datenbasis des Modells PROCON
4.2.3.3 Auswertungen mit PROCON
4.3 Projektcontrollingkonzept von Riedel
4.3.1 Themenfelder des Konzepts von Riedel
4.3.1.1 Wirtschaftlichkeit, Produktivität und Leistungsmessung
4.3.1.2 Organisation und Transparenz
4.3.1.3 Projektplanung und Kalkulation
4.3.1.4 Die Projektsteuerung
4.3.1.4.1 Qualitätssteuerung und Optimierung der Qualitätskosten
4.3.1.4.2 Steuerung der Qualitätssicherung
4.3.1.4.3 Optimierung der Qualitätssicherungskosten
4.3.1.4.4 Qualitätskostensteuerung
4.3.1.4.5 Beitrag der Kostenrechnung zur Qualitätssteuerung
4.3.1.5 Abschlussanalyse und Erfahrungsdatensammlung
4.4 Ausgewähltes Projektcontrollingkonzept
4.5 Anforderungen der Markant GmbH an das Controllingkonzept
4.6 Modifikationen des ausgewählten Konzepts
4.7 Voraussetzungen für die Einführung von SE-Projektcontrolling
4.7.1 Anforderungen an die Organisationsstruktur der Unternehmung
4.7.2 Unterstützung des Projektcontrollingsystems durch das Rechnungswesen

5 Organisationsanalyse der Markant SE und Dienstleistungs GmbH
5.1 Allgemeines zur Markant SE und Dienstleistungs GmbH
5.2 Analyse der Organisationsstruktur
5.2.1 Istzustand Aufbauorganisation der Gesamtunternehmung
5.2.2 Aktuelle Ablauforganisation
5.3 Entwicklungsstand des Projektmanagement
5.4 Entwicklungsstand des Rechnungswesens
5.5 Entwicklungsstand des Controllings

6 Anpassung des ausgewählten Projektcontrollingkonzepts für die Markant SE und Dienstleistungs GmbH
6.1 Phasenmodell für die Markant SE und Dienstleistungs GmbH
6.2 Modifikation der Tätigkeitsorganisation
6.3 Weitere Anpassungen

7 Zusammenfassung

8 Literaturverzeichnis

Abbildungsverzeichnis

Abb. 1.1 Globaler IT Markt (Infobroschüre BVITeV; 1999, S.1)

Abb. 1.2 Marktstruktur SE und IT Branche Deutschland (Infobroschüre BVITeV; 1999, S.2)

Abb. 1.3 Größe und Umsatz in der IT Branche (Infobroschüre BVITeV; 1999, S. 5)

Abb. 3.1 Controlling im Systemzusammenhang der Unternehmung (Küpper, H.-U.; 1990, S. 99)

Abb. 3.2 Module des Gesamtunternehmenscontrollings

Abb. 3.3 Einordnung des Projektcontrollings in den Controllingprozess

Abb. 3.4 Dimensionen der Projektcontrolling-Aufgabenstellung (Lachnit L.; 1994, S. 26)

Abb. 4.1 Funktionen des SE-Projektmanagements (Noth, T.; 1987, S. 9f)

Abb. 4.2 Verzahnung von PPS-System und Projektcontrolling-Modell (Lachnit L.; 1994, S. 79)

Abb. 4.3 Führungsbereiche bei Unternehmen mit Projektleistungstätigkeit (Lachnit L.; 1994, S. 81)

Abb. 4.4 Datenbasis der Erfolgsplanung

Abb. 4.5 Datenbasis der Liquiditätsplanung

Abb. 4.6 Monatsbezogene Erlös-, Kosten- und Erfolgsplanung für ein Projekt (Lachnit L.; 1994, S. 101)

Abb. 4.7 Monatsbezogene Liquiditätsplanung für ein Projekt (Lachnit. L.; 1994, S. 103) 3434

Abb. 4.8 Managementübersicht auf Einzelprojektebene monatlich (Lachnit. L.; 1994, S. 111)

Abb. 4.9 Projektcontrolling und seine Themenfelder (Riedel J. E.; 1990, S.VI) 3838

Abb. 4.10 Leistungseinflüsse nach Boehm

Abb. 4.11 Einstufung von LEE nach Boehm

Abb. 4.12 Messzahlenkreation im Zuge der Leistungsmessung 4343

Abb. 4.13 Aufbauorganisationsformen der Projektorganisation 4444

Abb. 4.14 Phasenmodell des Softwareentwicklungsprozesses 4545

Abb. 4.15 Tätigkeitsorganisation

Abb. 4.16 Strukturpläne (Riedel J. E.; 1990, S. 54)

Abb. 4.17 Strukturierungstiefe des Projektcontrollings

Abb. 4.18 Kalkulationsstruktur (Riedel J. E.; 1990, S. 60)

Abb. 4.19 Prinzip der Aufwandschätzung (Riedel J. E.; 1990, S. 82)

Abb. 4.20 Prozessbezogene Aufwandschätzung, kennzahlenorientiert (PAKO) (Riedel J. E.; 1990, S. 94)

Abb. 4.21 Beispiel einer Aufwandschätzung (Riedel, J. E.; 1990, S. 97)

Abb. 4.22 Aufbau des kostenorientierten Projektcontrollings (Riedel J. E.; 1990, S. 16)

Abb. 4.23 Kalkulationsschema der Softwarerealisation (Riedel J. E.;1990, S. 103) 5757

Abb. 4.24 Informationsbedarf der Projektkalkulation (Riedel J. E.;1990, S. 106) 5858

Abb. 4.25 Prinzipablauf der Vorkalkulation (Riedel J. E.;1990, S. 109) 5959

Abb. 4.26 Projektkalkulationskreislauf (Riedel J. E.; 1990, S. 121) 6262

Abb. 4.27 Vergleichskomponenten der Projektüberwachung (Riedel J. E.; 1990, S. 132) 6363

Abb. 4.28 Qualitätssicherungs-Leitfaden (Riedel J. E.; 1990, S. 144) 6565

Abb. 4.29 Qualitätssicherungskonzept (Riedel, J. E.; 1990, S. 147) 6666

Abb. 4.30 Transparenz der Qualitätskosten (Riedel, J. E.; 1990, S. 150) 6767

Abb. 4.31 Qualitätsregelkreis (Riedel J. E.; 1990, S. 152) 6868

Abb. 4.32 Qualitätskostenauswertung (Riedel J. E.;1990, S. 156) 6969

Abb. 4.33 Prinzipablauf der Abschlussanalyse (Riedel J. E.; 1990, S. 166) 7171

Abb. 4.34 Kostenkategorien (Coenenberg, A. G.; 1992, S. 771) 7373

Abb. 4.35 Projektkostenverlauf

Abb. 4.36 Leistungs- und Kostenvarianzverläufe 7777

Abb. 4.37 Gesamtprojektentwicklung

Abb. 5.1 Aufbauorganisation der Markant SE und Dienstleistungs GmbH 8282

Abb. 5.2 Phasenmodell der Ablauforganisation

Abb. 5.3 Überblick über ZGPM (Andersen, E. S.; 1984, S. 18) 8484

Abb. 6.1 Empfohlenes Phasenmodell

Abb. 6.2 Vorschlag einer Tätigkeitsorganisation

1 Einleitung

Einleitend wird ein kurzer Überblick über die Softwareentwicklung (SE) und Informationstechnologie (IT) Branche gegeben. In Abschnitt 1.2 werden wesentliche Gründe für die Notwendigkeit eines Projektcontrollingsystems in der SE und IT Branche genannt.

1.1 Skizze der Softwareentwicklung und Informationstechnologie Branche

In der Branche der SE und IT tummeln sich eine Vielzahl kleine, mittlere und große Unternehmen verschiedener Rechtsformen und Größe. Es existieren ca. 5000 SE und IT Anbieter in Deutschland.

Weltweit ist Deutschland der drittgrößte Markt für SE und IT Technologie, innerhalb Europa sogar der mit Abstand größte (Abb. 1.1) (Infobroschüre BVITeV; 1999, S.1).

Abb. 1.1 Globaler IT Markt (Infobroschüre BVITeV; 1999, S.1)

Abbildung in dieser Leseprobe nicht enthalten

Der SE und IT Markt unterteilt sich in eine Vielzahl von Marksegmenten, die in Abbildung 1.2 dargestellt sind. Der Gesamtumsatz der Branche liegt bei 43 Milliarden DM (Infobroschüre BVITeV; 1999, S. 2).

Abb. 1.2 Marktstruktur SE und IT Branche Deutschland (Infobroschüre BVITeV; 1999, S.2)

Abbildung in dieser Leseprobe nicht enthalten

Die Umsatzsteigerungen liegen seit 1997 konstant bei durchschnittlich 35% für die

Gesamtbranche. Erste Schätzungen lassen für 2000 den gleichen Anstieg vermuten obwohl sich der deutschen Anbieter vermehrt der auf den deutschen Markt vordringenden ausländischen Konkurrenz erwehren muss (Infobroschüre BVITeV; 1999, S. 2f). Parallel zum Umsatz hat sich die Beschäftigtenzahl seit 97 um Jährlich 5% erhöht, wobei der Fachkräftemangel eine höhere Steigerung nicht zugelassen hat (Infobroschüre BVITeV; 1999, S. 4). Die Größenstruktur der einzelnen Unternehmen ist, neben dem pro Mitarbeiter im Durchschnitt erwirtschafteten Umsatz, in Abbildung 1.3 aufgezeigt.

Abb. 1.3 Größe und Umsatz in der IT Branche (Infobroschüre BVITeV; 1999, S. 5)

Abbildung in dieser Leseprobe nicht enthalten

Aus Abbildung 1.3 ist ersichtlich, dass 60% der Unternehmen weniger als 11 Mitarbeiter beschäftigen. Die Branche besteht also vorwiegend aus Kleinunternehmungen.

1.2 Notwendigkeit von Projektcontrolling

Der zunehmende Neuigkeitsgrad des Wandels, eine wachsende Intensität der Umweltbedingungen, eine steigende Geschwindigkeit des Umweltwandels sowie eine erhöhte Komplexität der Umwelt (Macharzina, K.; 1984, S. 5) forcieren seit Jahren die Projektleistungstätigkeit (siehe Abschnitt 3.2.2) in Unternehmen. Bei Unternehmen der SE und IT Branche macht Projektarbeit einen bedeutenden Anteil an deren Gesamttätigkeit aus. Vor allem in der Entwicklung von Individualsoftware ist die Arbeit in Projekten sehr häufig anzutreffen, da die Aufgaben meist unabhängig von der bestehenden Firmenstruktur funktionsübergreifend bearbeitet werden. Durch die starke Zunahme finanzieller Vorleistungen, der erhöhten Unsicherheit, Projektkomplexität und dem steigenden Ausmaß von Projekttätigkeit in den SE und IT Unternehmen bei Softwareentwicklungsprojekten, steigt die Nachfrage nach Projektcontrollingkonzepten, um den dringlichsten Fragen der Projektkosten und des Projektzeitrisikos effektiv begegnen zu können (Weis, E.; 1997, S. 87). Außerdem erfordern lange Laufzeiten und die Integration vieler Beteiligter während der Projektarbeit Unterstützung durch Projektcontrolling. Der steigende Wettbewerbsdruck (time to market, Verkürzung der marktlichen Produktlebenszyklen) in der sich rasant entwickelnden SE und IT Branche macht eine effiziente Projektarbeit zum Überleben der Unternehmung zur Bedingung (Weis, E.; 1997, S. 87). Die Notwendigkeit des Projektcontrollings ergibt sich somit aus der Dynamik und der Komplexität der Koordinationsnotwendigkeiten bei Unternehmen mit Projektleistungstätigkeit.

2 Aufgabenstellung

Dieses Kapitel enthält das Thema der Diplomarbeit und stellt in einer Übersicht deren Struktur sowie die Vorgehensweise des Autors bei der Bearbeitung des Themas dar.

2.1 Thema der Arbeit

Wie schon in Kapitel 1 erwähnt, hat die Arbeit in Projekten bei Unternehmen der SE und IT Branche einen großen Anteil an deren Gesamttätigkeit (Reichmann, T.; 1988, S.15) Projektarbeit zu planen, zu strukturieren, zu überwachen und zu steuern ist deshalb von großer Wichtigkeit für diese Branche. Gerade bei kleinen und mittleren Unternehmen besteht bei der Unterstützung der Unternehmensführung hinsichtlich des Projektmanagements noch Nachholbedarf. Das Projektcontrolling als Teil einer Unternehmensführungs-Servicefunktion kann den Unternehmen diese Unterstützung bieten.

In der vorliegenden Diplomarbeit ist ein Projektcontrollingkonzept für SE und IT Unternehmungen zu entwickeln und für die Markant SE und Dienstleistungs GmbH zu modifizieren.

2.2 Struktur der Arbeit und Vorgehensweise

Die Arbeit besteht aus sieben Kapiteln. Nach der Einleitung (Kapitel 1) und diesem Kapitel, erfolgt in Kapitel 3 die Beschreibung der Controllinggrundlagen und Definition der immer wieder verwandten Begrifflichkeit. Außerdem wird dem Leser die Problemstellung des

Projektcontrollings und existierende Unterscheidungskriterien zum allgemeinen Begriff des Controllings näher gebracht. Der Autor erläutert auch die verschiedenen Fassungen des Projektcontrollingbegriffs und stellt deren unterschiedliches Aufgabenspektrum dar. Der Schwerpunkt der Arbeit (Kapitel 4) liegt auf der Darstellung bereits vorhandener Projektcontrollingkonzeptionen für SE und IT Unternehmen, der Auswahl und Anpassung des Konzepts, nachdem controllingrelevante Besonderheiten der SE aufgezeigt wurden. Den Abschluss von Kapitel 4 machen Hinweise auf die Voraussetzungen zur Einführung des ausgewählten Projektcontrollingkonzepts. Kapitel 5 beschreibt markantspezifische organisatorische Gegebenheiten der Aufbau- und Ablauforganisation, sowie die Beschreibung und den Status Quo des zum Zeitpunkt der Organisationsanalyse vorhandenen Projektmanagements, Rechnungswesen und Controllings. Die Beschreibung des letztendlich für die Markant SE und Dienstleistungs GmbH vorgeschlagenen Projektcontrollingkonzepts ist Inhalt von Kapitel 6. In Kapitel 6 ist, sofern nicht schon in Kapitel 4 geschehen, die Ausgestaltung des Projektcontrollingmodells unter Beachtung der speziell bei der Markant SE und Dienstleistungs GmbH herrschenden Verhältnissen aufgeführt. Am Ende der Arbeit ist in Kapitel 7 eine Zusammenfassung zu finden.

Wichtig zur Vorgehensweise in der Arbeit ist zu erwähnen, dass bei der Beschreibung des später ausgewählten Projektcontrollingkonzepts bereits markantspezifische Überlegungen mit einflossen und das Konzept daher ohne gravierende Änderungen für die Markant SE und Dienstleistungs GmbH (wie in Kapitel 6 geschildert) übernommen werden kann.

3 Controllinggrundlagen

Um dem Leser den Einstieg in die Materie des Projektcontrollings zu erleichtern, werden zunächst allgemeingültige Aspekte des Controllings behandelt und eine Orientierungshilfe zur Positionierung des Projektcontrollings im Controlling gegeben.

3.1 Controlling als Instrument der Unternehmensführung

3.1.1 Wesen und Inhalt des Controllings

Der Begriff Controlling kann aus dem Angelsächsischen von "to control" = regeln, steuern, lenken, nicht kontrollieren oder überwachen, abgeleitet werden. Es wird absichtlich von kann gesprochen, da auch eine Herleitung aus dem Französischen von "contreróle" = Gegenrolle möglich ist (Preißler, P. R.; 1994 S. 11).

Controlling ist als Unternehmensführungs-Servicefunktion zu verstehen, die für eine Wirkungsverbesserung der Unternehmensführungsteilfunktionen Zielbildung, Planung, Kontrolle, Koordination und Information Sorge zu tragen hat (Lachnit L.; 1994, S. 1).

Controlling ist ebenfalls funktionsübergreifendes Steuerungsinstrument zur Unterstützung der Unternehmensführung beim unternehmerischen Entscheidungsprozess und dem Erreichen von vorher klar und verbindlich festgelegten Zielen. Controlling ist demnach eine Managementaufgabe, die im Rahmen der Arbeitsteilung und wegen des großen Umfangs, vermehrt von Managern zuarbeitenden Personen, den Controllern wahrgenommen wird (Lachnit L., Lange C., Palloks M.; 1998, S. 8).

Es lassen sich aus der Literatur zwei Controllingphilosophien unterscheiden:

- Hahn, Horváth und Reichmann stellen das Ergebnisziel und dessen Optimierung in den Vordergrund (Hahn D.;1996, S. 179). Blazek und Deyle (Deyle, A.; 1990) sehen das genauso, doch verwenden die beiden für diesen Aufgabenkomplex nicht den Begriff Controlling, sondern begreifen Controlling, wie im amerikanischen Sprachraum üblich, als Teil des Führungsprozesses. Sie verstehen die oben dargestellte Aufgabe als Controller-Funktion und folgen dabei der amerikanischen Terminologie, die zwischen dem Controlling, interpretiert als Phase des Führungsprozesses und der Controller-Funktion unterscheidet.

- Küpper und Weber heben auf das gesamte Zielsystem des Unternehmens und die sich daraus ergebende Koordinationsoptimierung ab (Hahn D.;1996, S. 179).

Während noch vor kurzer Zeit dem Controlling bzw. dem Controller nur Servicefunktionen zugerechnet wurden, fordern neuere Ansätze (Lachnit L., Lange C., Palloks M.; 1998, S. 8f) immer mehr Entscheidungskompetenz für den Controller, um der wachsenden Bedeutung von Controllingaufgaben Nachdruck zu verleihen.

Durch den zunehmenden Neuigkeitsgrad des Wandels, die wachsende Intensität der Umweltbedingungen, die steigende Geschwindigkeit des Umweltwandels sowie die erhöhte Komplexität der Umwelt, lässt sich Turbulenz als Hauptmerkmal der Organisationsumwelt erkennen. Von dieser Feststellung ausgehend, muss sich das Controlling von seinem vorwiegend retrospektiven Charakter, hin zur Zukunftsfähigkeit im Sinne von vorausschauender Steuerungsfähigkeit entwickeln. Das momentan noch überwiegend funktional organisierte Controlling, wird sich in Zukunft mehr an Controllingprozessen ausrichten und deshalb seine funktionale Organisation aufgeben. Die bereits im Gange befindliche Dezentralisierung wird sich weiter verstärken und somit zur Reduktion der "Wasserköpfe" zentraler Controllingabteilungen beitragen (Lachnit L., Lange C., Palloks M.; 1998, S. 5f).

3.1.2 Aufgaben des Controllings

Die generelle Aufgabe des Controllings ist die Unterstützung der Unternehmensführung durch die Funktionssicherung des Managementsystems. Zergliedert man diese Aufgabe so ergeben sich systembildende und systemkoppelnde Teilaufgaben, von denen die wichtigsten nachfolgend aufgeführt werden (Lachnit L.;1994 S. 8ff). Es sind dies:

a) Die Koordination der Unternehmensführungs-Teilsysteme,
b) die Gestaltung des Planungs- und Kontrollsystems und
c) die Gestaltung des betrieblichen Informationssystems.

Zu a):

Das Führungssystem der Unternehmung dient zur zielorientierten Gestaltung des Leistungserstellungsprozesses durch die Führungsebene. Die Bestandteile des Führungssystems sind in Abb. 3.1 ausgewiesen. Dem Controlling obliegt es als Kernaufgabe für die Abstimmung dieser Bestandteile zu sorgen, da aufgrund des systemübergreifenden Zusammenhangs der Teilsysteme keines dieser selbst die angesprochene Aufgabe wahrnehmen kann. Die Koordinationsaufgabe hat systembildende wie auch systemkoppelnde Komponenten. Die Schaffung der Prozessstruktur zur Abstimmung der Teilaufgaben repräsentiert die systembildende Komponente. Aktivitäten, die zur Herstellung oder Aufrechterhaltung von Verbindungen zwischen bereits bestehenden Teilsystemen dienen, stellen die systemkoppelnde Komponente dar (Küpper, H.-U.; 1990, S. 99ff).

Abb. 3.1 Controlling im Systemzusammenhang der Unternehmung (Küpper, H.-U.; 1990, S. 99) Zu b):

Abbildung in dieser Leseprobe nicht enthalten

Planung und Kontrolle sind Führungsaufgaben und es ist Aufgabe des Controllings die Lenkung des Gesamtsystems Unternehmung durch die Unternehmensführung mit Hilfe eines strukturierten Planungs- und Kontrollsystems zu unterstützen. Durch das Konzipieren, Implementieren und der Betreuung des ergebnisorientierten Planungs- und Kontrollsystems werden Grundlagen geschaffen, die das Management in die Lage versetzen das Unternehmen zielkonform und effizient zu lenken. Das Planungssystem bietet hierbei den institutionellen Rahmen für die Planungshandlungen, durchgeführt durch Planungssubjekte an Planungsobjekten unter Zuhilfenahme von Planungsinstrumenten der Planung (Mag, W.; 1993, S. 33). Unter Planungssubjekten sind alle aktiv oder passiv mit der Planung in Berührung kommende Personen gemeint, wie Planungsverantwortliche und Planungsträger. Die Planungsobjekte sind Gegenstand der Planung, also all das was geplant wird. Mit Planungsinstrumenten bezeichnet man die Hilfsmittel, wie Planungsmethoden, die Pläne selbst usw., die zum Planen herangezogen werden. Im Zuge der Erstellung des Kontrollsystems müssen Kontrollobjekte (was ist zu kontrollieren), Kontrollträger, (Überwacher) Kontrolladressaten und Kontrollmethoden (Art der Kontrolle, z. B. Budgetkontrolle) ermittelt werden. Im Kontrollsystem liegt der Schwerpunkt auf der Eigenkontrolle, da Fremdkontrolle oder Revisionen mit dem Controllingbegriff aus Kapitel

3.1.1 nicht vereinbar sind.

Zu c):

Sämtliche Unternehmensaktivitäten sind von Informationsströmen begleitet. Es ist dabei zwischen Führungsinformation für die Zielbildung, Planung und Kontrolle und Ausführungsinformation zur Unterstützung der Realisationstätigkeiten zu unterscheiden. Das Informationssystem dient der Verknüpfung der bereits früher angesprochenen Teilbereiche und bildet, wie aus der Abb. 3.1 zu erkennen ist, selbst einen dieser Bereiche. Im Rahmen der

Informationswirtschaft sind die Informationsbedarfsermittlung, -beschaffung, -verarbeitung, - speicherung und -übermittlung wesentliche Teilaufgaben (Zahn E.; 1991 S. 224ff). Die Gestaltung des Informationssystems ist auf eine optimale Versorgung aller Stellen im Unternehmen mit den benötigten Informationen auszurichten. Die zentrale Aufgabe des Controllings besteht dabei in der Koordination von Informationsbedarf, -erzeugung und - bereitstellung (Horváth P.; 1994 S. 245ff). Hahn und Reichmann sehen in der informationellen Sicherung von Planung, Steuerung und Kontrolle gar die generelle Aufgabe des Controllings (Hahn, D.; 1994 S. 179f).

3.2 Projektcontrolling

3.2.1 Problemstellung

Es bestehen zwei grundsätzlich verschiedene Arten der Leistungstätigkeit in Unternehmen. Zum einen handelt es sich um Leistungserstellung mit relativ homogenem Zuschnitt und hoher Wiederholungshäufigkeit, zum anderen um Leistungen mit komplexer Struktur, die mit geringer Wiederholungshäufigkeit erstellt werden. Massen-, Sorten-, Großserienfertigung und Wiederholungsdienstleistungen sind Beispiele der erstgenannten Art von Leistungstätigkeiten, während es bei der zweiten Art um Fälle der Einzel- und Kleinserienfertigung, Großaufträge im Dienstleistungsbereich oder um spezielle Vorhaben etwa auf dem Gebiet der Forschung und EDV geht. Die Leistungen mit dem letztgenannten Merkmaleprofil werden als Projekte bezeichnet (Lachnit, L.; 1994, S. 19). Nach der DIN-Norm 69901 wird Projekt sinngemäß wie folgt definiert: Vorhaben, das durch die Einmaligkeit der Bedingungen in ihrer Gesamtheit bezogen auf Zielvorgabe, Ressourcenbegrenzung und projektspezifischer Organisation gekennzeichnet ist (DIN-Taschenbuch 166; 1981, S. 311).

Aufgrund der Besonderheiten dieses Leistungstyps bestehen spezielle Risiko-, Organisations-, Planungs-, Kontroll- und Bilanzierungsprobleme, die fallweise sehr unterschiedlich auftreten und mit herkömmlichen Controllingmethoden kaum lösbar sind (Lachnit, L.; 1994, S. 20). Ein weiteres bedeutendes Problem besteht darin, dass es Schwierigkeiten bereitet Einzelprojekte, Projektegesamtheit und Gesamtunternehmensaspekte in einer Controllingkonzeption unterzubringen und so die Kompatibilität der Einzelziele (von Einzelprojekte, Projektegesamtheit, Gesamtunternehmen) zu gewährleisten.

3.2.2 Abgrenzung zum allgemeinen Begriff des Controllings

Um das Projektcontrolling vernünftig umschreiben zu können, bedarf es vorab der Klärung einiger wesentlicher Begriffe. Der Begriff Projekt wurde bereits im vorigen Abschnitt mit der DIN-Norm 69901 erklärt, wobei es hier unzählige Definitionsansätze in der Literatur gibt, aber die DIN-Norm als einzige einen quasi verbindlichen Charakter hat. Ein Controllingmodell, das die zielgerichtete Planung, Steuerung und Überwachung von Einzelprojekten anstrebt, wird als Projektcontrolling i. e. S. umschrieben. Projektcontrolling i. w. S. ist demnach ein Modell, das ausgehend vom Ansatz des Projektcontrollings i. e. S. ein projektübergreifendes Multiprojektcontrolling beinhaltet (Lachnit, L.; 1994, S. 20). Das Einzelprojektcontrolling ist auf ein einzelnes Projekt fokussiert und hilft die Projektentwicklung technisch, organisatorisch, wirtschaftlich zu erfassen, zu beurteilen und zu lenken. Das Multiprojektcontrolling hat hingegen als Betrachtungsgegenstand mehrere Projekte mit unterschiedlichen Start- und Endterminen, verschiedenem Phasen- und Fertigstellungsstand. Organisatorisch treten damit terminbezogene Koordinations- und Kapazitätsabstimmungsprobleme in den Vordergrund, wirtschaftlich verlagert sich der Blick auf die periodenbezogene Darstellung von Kosten, Leistungen und Ergebnisse sowie Finanzwirkung der Einzelprojekte (Lachnit, L.; 1994, S. 27ff).

Es gibt keinerlei Unternehmen, deren Tun die reine Projekttätigkeit ist, da immer Tätigkeitsgebiete bestehen, die unabhängig von der Projekttätigkeit (z. B. Verwaltung) sind. Unter Beachtung dieser Tatsache, ist das Unternehmensgeschehen gleichzeitig nach Projekten und Fachfunktionen zu organisieren. Für eine Unternehmensführung unter Projektgegebenheiten reicht ein nur auf das einzelne Projekt gerichtetes Controlling (Projektcontrolling i. e. S.) nicht aus. Das Projektcontrolling i. e. S. ist um projektübergreifende Betrachtungen für Projektegruppen und Projektegesamtheit zu erweitern. Zusätzlich sind Aspekte ohne Projektbezug (z. B. die wirtschaftliche Lage des Gesamtunternehmens) in das Konzept zu integrieren. Man spricht dann von Controlling in Unternehmen mit Projektleistungstätigkeit (Lachnit, L.; 1994, S. 50ff) oder von Gesamtunternehmenscontrolling bei Projekttätigkeit (siehe Abb. 3.2).

Abb. 3.2 Module des Gesamtunternehmenscontrollings

Abbildung in dieser Leseprobe nicht enthalten

Wie Abbildung 3.2 zeigt, ist die organisatorische Verbindung von Projekt- und Gesamtunternehmensebene in Unternehmen mit Projektleistungstätigkeit Grundvoraussetzung für ein ganzheitliches System zur Unternehmensführung. Das Gesamtunternehmenscontrolling stellt die integrierende Klammer für alle Module dar. Genau diese Vielschichtigkeit von Controllingmodulen (siehe Abb. 3.2) und dem damit einhergehenden Bedarf und Anfall heterogener Daten (z. B. unterschiedlicher Zeitbezug der Daten im Einzel- und Multiprojektcontrolling) macht einen der Hauptunterschiede des Controllings bei Projektleistungstätigkeit zum "normalen" Controlling aus. Die Abbildung auf der nächsten Seite schildert die Einordnung des Projektcontrollings in den Controllingprozess. Es erscheint der Begriff des Produktcontrollings, welches zum Multiprojektcontrolling gehört. Hier wird absichtlich der Begriff Produktcontrolling verwendet, um eine leichtere Vorstellung von der Einordnung des Projektcontrollings (i. e. S.) in den Controllingprozess zu erhalten. Das Projektcontrolling i. e. S. ist Bestandteil der untersten Ebene des Controllingprozess. Es kann als Einzelprojektcontrolling oder noch spezifischer als Abteilungscontrolling implementiert werden. Die vier Cd´s (A, B, C, D) stellen Produktgruppen oder wahlweise einzelne Produkte dar.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3.3 Einordnung des Projektcontrollings in den Controllingprozess

3.2.3 Die Aufgabenstellung an das Projektcontrolling

Wie im vorangegangenen Kapitel bereist erwähnt, ist Projektcontrolling ein Oberbegriff für alle projektbezogenen Controllingfassungen zu denen die Formen des Projektcontrollings i. e. S. und i. w. S. gehören. In Abb. 3.4 erhält der Leser einen groben Überblick auf aggregierter Ebene über die Dimensionen der Projektcontrolling-Aufgabenstellung. In der Zusammenschau von Phasenpositionierung, hierarchischem Aggregatzustand und Fachinhalt der Betrachtungssachverhalte lassen sich alle Aufgaben einordnen

(Abb. 3.4).

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3.4 Dimensionen der Projektcontrolling-Aufgabenstellung (Lachnit L.; 1994, S. 26) Die Hauptaufgaben des Einzelprojektcontrollings sind (Riedel, J. E.; 1990):

1. Projektplanung - Termin-, Kapazitäts-, Wirtschaftlichkeitsplanung (Kalkulation)
2. Projektüberwachung - Wirtschaftlichkeits-, Produktivitäts- und Leistungsmessung
3. Projektsteuerung - abweichungsinduzierte Entscheidungsfindung
4. Nachbewertung - Abschlussanalyse, Erfahrungsdaten-, Kennzahlenkreation

Eine detailliertere Aufstellung soll an dieser Stelle nicht gegeben werden. Für das Multiprojektcontrolling können im Prinzip die gleichen Hauptaufgaben genannt werden, jedoch mit dem Fokus auf die Projektegruppen und -gesamtheit. Daraus ergeben sich vor allem Koordinationsaufgaben mit technisch-organisatorischen Aspekten, wie die Koordination der Projektprogramm- und -ablaufplanung unter der Restriktion beschränkter Kapazitäten. Eine sehr wichtige Aufgabe im Rahmen der Projektgesamtheitsplanung ist die Kosten- und Finanzplanung, da hierdurch die Unternehmensfinanzlage im wesentlichen determiniert wird. Die wirtschaftliche Aufgabenstellung besteht darin die optimale Erfolgs- und Finanzwirkung der Projektegesamtheit zu sichern. Auf der Ebene des Einzelprojekts geschieht dies im Zuge des Einzelprojektcontrollings, wobei die Erfolgs- und Finanzgrößen für die Gesamtlaufzeit und für operative Teilperioden des Projekts geplant, gesteuert und überwacht werden. Für die Projektegesamtheit (oder -gruppen) kann dies nicht mehr an den einzelnen Projektlaufzeiten festgemacht werden, da damit keine einheitliche Zeitbasis der Erfolgs- und Finanzgrößen gegeben ist. Der Zeitbezug der relevanten Mess- und Kennzahlen hat daher Periodencharakter, (monatlich, ¼ jährlich usw.) um eine projektübergreifende Aggregation einzelner Projektdaten für die Gesamtprojektebene zu ermöglichen (Lachnit, L.; 1994, S. 51-59).

Betrachtet man das Projektcontrolling und das Projektmanagement, so kann ein Controllingmodell ohne Projektmanagement nicht existieren. Dies gilt nicht nur, aber im Besonderen für die organisatorischen Aufgaben der Projektplanung. Hier hat das Projektmanagement vor allem die strukturellen Grundlagen (z. B. Projektstrukturplan, Machbarkeitsstudie usw.) zu schaffen. Der Autor versteht das Projektmanagement hauptsächlich als organisatorische Disziplin (Strukturierung der Aufgaben und der Verantwortlichkeiten usw.) und geht daher von einer Aufgabentrennung von Projektmanagement und Projektcontrolling aus, wobei beide Disziplinen stark miteinander verwoben sind. Die wohl einfachste aber allgemein vorgenommene Abgrenzung des Begriffs Controlling zum Begriff des Managements, erfolgt nach dem Kriterium der Entscheidungskompetenz über Projektaufgaben. Der Controller ist hier mehr in der Funktion des mit Beratungskompetenz ausgestatteten Copiloten zu sehen, der Manager folglich als Pilot mit Entscheidungsgewalt.

4 Controllingkonzept für SE-Unternehmen mit Projektleistungstätigkeit

Zum besseren Verständnis der Materie erfolgt vorab eine Klärung diverser Fachbegriffe des SE-Projektcontrollings. Danach werden die Projektcontrollingkonzepte von L. Lachnit (Abschnitt 4.2) und J. E. Riedel behandelt. In Abschnitt 4.4 sind nach der Konzeptauswahl Vorschläge zur Anpassung und Modifikation des ausgewählten Konzepts an SE-spezifische Gegebenheiten zu finden. Am Ende wird eine Zusammenfassung notwendiger Voraussetzungen zur Einführung des modifizierten SE-Projektcontrollingkonzepts gegeben.

4.1 Besonderheiten des SE-Projektcontrollings

4.1.1 Begriffsdefinitionen

Um die wichtigsten und immer wiederkehrenden Fachtermini nicht mehrfach und verteilt in den einzelnen Unterkapitel erklären bzw. definieren zu müssen, soll dies hier geschehen. Zunächst erfolgt eine Unterteilung des allgemeinen Projektbegriffs (siehe 3.2.1) in die spezielleren Begriffe Software- und Hardwareprojekt. Softwareprojekte zeichnen sich durch das Schaffen von Wissen aus, das nicht zwangsläufig sofort zu einem am Markt akzeptierten Produkt führen muss. Es geht bei Softwareprojekten primär um die Verwendbarkeit von Technologien, im Gegensatz dazu steht die Verwertbarkeit von Technologien bei Hardwareprojekten an oberster Stelle. Hardwareprojekte dienen somit direkt der Entwicklung von Produkten oder Dienstleistungen (Weis, E.; 1997; S. 87). Neben den allgemeinen Kriterien von Projekten, wie aperiodischer Erstellungszeitraum, hohe Wertigkeit, Langfristigkeit und Komplexität, (Lachnit L.; 1994, S. 19) die alle auch auf Softwareprojekte zutreffen, lässt sich das Softwareprojekt noch deutlicher charakterisieren. Zu den Charakteristika von Softwareentwicklungsprojekten gehören (Noth, T.; 1987, S. 4f):

- Es gibt keine kausalen Input-Output Beziehung (Fehlen einer Produktionsfunktion).
- Durch den immateriellen Charakter gibt es kaum Maßgrößen für den Leistungsfortschritt. · Hauptkostenfaktor sind die Personalkosten.
- Die Softwareentwicklung zeichnet sich durch Heterogenität der Projekte bzw. Produkte aus, was die Übertragung von Erfahrungsdaten auf andere Projekte erschwert. · Es bestehen hohe Änderungsraten im Laufe der Projektentwicklung. Um zu einer praxisbezogeneren Definition zu gelangen, kann Software, deren Erstellung das Ziel eines Softwareentwicklungsprojekts ist, folgendermaßen klassifiziert werden. Klassifikation nach:
-Aufgabenstellung (Raffel A.; 1988, S. 10)
- Betriebssysteme
- Systemnahe Software (Datenbanken, Compiler)
- Anwendersoftware (Office-Programme, techn.wiss. Software)
-Standardisierungsgrad (Spieler J; 1986, S. 2)
- Individuelle Software (anwenderspezifisch) · Standardsoftware

4.1.2 SE-Projektmanagement und Projektcontrolling im Zusammenhang

Wie in Kapitel 3 (Abschnitt 3.2.3) erwähnt, sieht der Autor bei aller Verwobenheit von Projektmanagement und Projektcontrolling einige Unterschiede bei der Aufgabenstellung. Das Projektmanagement bildet quasi den äußeren Rahmen, wohingegen das Projektcontrolling für die Funktionssicherung des Projektmanagements zuständig ist. Der Autor geht davon aus, dass im Verlauf der Projektmanagement-Aufgaben grundsätzliche, vorwiegend organisatorische Fragen (Projektstrukturierungsansätze, Projektorganisation, Verantwortlichkeiten usw.) zu klären sind und legt daher den Aufgabenschwerpunkt des Projektcontrollings mehr auf die wirtschaftliche Komponente des Projektgeschehens. Die Funktionen des SE-Projektmanagements können ganz allgemein mit Zielbildung, Planung, Kontrolle, Koordination und Information umschrieben werden, wie sie auch für das Projektmanagement allgemein zutreffen. Wenn innerhalb der Funktionen nochmals nach prozessorientierten und produktorientierten Funktionen gegliedert wird, erhält man die speziellen Funktionen des SE-Projektmanagements (Noth, T.; 1987, S. 9f). Zusammenfassend werden die speziellen SE-Projektmanagementfunktionen in Abb. 4.1 demonstriert.

Abb. 4.1 Funktionen des SE-Projektmanagements (Noth, T.; 1987, S. 9f)

Abbildung in dieser Leseprobe nicht enthalten

Das SE-Projektcontrolling ist für die Absicherung der SE-Projektmanagementfunktionen verantwortlich. Im Rahmen dieser Aufgabe hat das SE-Projektcontrolling die jeweiligen geeigneten Instrumente und Verfahren (Netzplan, Kosten- Finanzanalysen usw.) auszuwählen, zu installieren, Daten zu erheben, auszuwerten, diese in Berichten an das Management zu komprimieren und aufzubereiten.

4.1.3 Die Abweichungsanalyse von Softwareprojekten

Neben dem SE-Projektmanagement zeichnet sich auch die Abweichungsanalyse, als Bestandteil der Projektsteuerung, durch Ihren besonderen Bezug zur Softwareentwicklung aus. Die Steuerungsaufgaben lassen sich in zwei Schwerpunkte unterteilen (Noth T.; 1987, S. 9f):

1. operative Umsetzung der Planvorgaben, d. h.

- Definition und Anstoß projektinterner Aufträge · Ressourcenzuteilung
- Koordination der Auftragsabwicklung

2. abweichungsinduzierte Entscheidungsfindung, d. h.

- Ist-Zustand erfassen
- Durchführen der Abweichungsanalyse · Alternativenbewertung
- Auswahl der optimalen Maßnahme

Nachfolgend wird erläutert welche Aspekte die Abweichungsanalyse zu berücksichtigen hat, um einen vernünftigen Beitrag zur abweichungsinduzierten Entscheidungsfindung leisten zu können.

Nach einer Untersuchung von Mansfield (Siemens; 1984, S. 34) erreichen von 100 technologisch erfolgreichen Entwicklungen nur 20 einen befriedigenden Markterfolg, wenn sie überhaupt auf den Markt gelangen. Dies liegt zum einen an der mangelnden Koordination zwischen den Entwicklungsstellen und dem Marketing (Benkenstein M.; 1987, S. 5) und zum anderen an der Nichtberücksichtigung des Unternehmens- bzw. Produktumfelds. Zu einer umfassenden Abweichungsanalyse gehören neben dem Beobachten und Erfassen projektinterner Faktoren, wie Kosten-, Leistungsfortschritt und Terminen auch projektexterne Faktoren, wie z. B. die Ressourcenverfügbarkeit (als Beispiel eines unternehmensinternen Faktors) und beispielsweise der Absatzmarkt (als Beispiel eines unternehmensexternen Faktors). Die traditionell intern ausgerichtete Abweichungsanalyse für Projektfaktoren ist demzufolge um die Analyse der Projektumfeldfaktoren zu ergänzen, um Einflüsse von der Umfeldentwicklung auf das Projekt erkennen zu können (Link J.; 1987, S. 780).

4.2 Das Projektcontrollingkonzept von Lachnit

In diesem Abschnitt wird das Projektcontrollingkonzept von Lachnit (Lachnit L.; 1994, S. 81- 138) dargelegt, das zwar nicht speziell für SE-Unternehmungen entwickelt wurde, aber nach Meinung des Verfassers dieser Arbeit auf die Gegebenheiten der SE und IT Branche übertragbar ist. Es wurde ausgewählt, da es in seiner letzten Ausbaustufe (ERFI, siehe Abschnitt 4.2.3.1) als Konzept zur Führungsunterstützung der Gesamtunternehmung bei Projektleistungstätigkeit dient. Das Konzept von Lachnit ist also mehr als Endziel der Entwicklung einer Projektcontrollingkonzeption für die Zwecke der Gesamtunternehmungsführung zu sehen und somit nach Einführung des Einzelprojektcontrollings anzustreben.

4.2.1 Anforderungen an das Projektcontrolling-Modell

Für Unternehmen mit Projektleistungstätigkeit ist die gleichzeitige Bereitstellung von projektbezogen-periodenübergreifender sowie projektübergreifender-periodenbezogener Information erforderlich. Dabei muss die Betrachtung auf der Einzelprojekt-, Projektegruppen- und -gesamtheitsebene wie auch auf Funktionalbereiche und auf der Gesamtunternehmensebene geschehen. Das Aufgabenspektrum, das vom Projektcontrolling- Modell abzudecken ist, umfasst damit die Planung, Steuerung und Kontrolle des Unternehmensgeschehens vernetzt und zugleich auf mehreren Ebenen (Projekt-, Nichtprojekt- und Funktionalbereich) zu unterstützen. Die Ergebnisse sind abschließend zur Erfolgs- und

Finanzlenkung des Gesamtunternehmens überzuleiten (Lachnit L.; 1994, S. 70-72). Die Aufgaben einer umfassenden Controllingkonzeption sind in Abb. 4.2 zu finden, die gleichzeitig den Aufgabenbereich des projektbezogenen Controllings, mit Schwerpunkt auf den ökonomischen Aufgabenfeldern, abgrenzt.

Abb. 4.2 Verzahnung von PPS-System und Projektcontrolling-Modell (Lachnit L.; 1994, S. 79)

Abbildung in dieser Leseprobe nicht enthalten

Im Sinne eines systembildenden Controllings, ist ein Teilsystem zu entwickeln, das die betriebswirtschaftlich-wertmäßige Lenkung von Einzelprojekten und der Projektegesamtheit enthält und den Brückenschlag zur Erfolgs- und Finanzlenkung des Gesamtunternehmens herstellt. Zum anderen ist als systemkoppelnde Leistung in einem Controllingsystem bei Projektleistungstätigkeit die Verbindung von den technisch-organisatorisch geprägten PPS- und Projektmanagement-Systemen zu dem stärker betriebswirtschaftlich-wertmäßig ausgerichteten Projektcontrolling-Modell PROCON (siehe 4.2.2) zu realisieren. Wie erkennbar, bestehen viele Anforderungen an ein wie vor beschriebenes Projektcontrolling- Modell, was eine EDV-Unterstützung zwingend notwendig macht (Lachnit L.; 1994, S. 79).

4.2.2 Grundstruktur eines Controllingsystems zur Erfolgs- und Finanzführung

Da die nachhaltige Sicherung von Erfolg und Finanzen eine der zentralen Aufgaben der Unternehmensführung ist, muss diese dabei durch ein adäquates Controllingsystem unterstützt werden. Es sind also erfolgsrelevante Größen wie Umsatz, Kosten und Deckungsbeiträge als auch finanzrelevante Größen wie Einnahmen und Ausgaben kurz- und langfristig zu verfolgen. Aufgrund der Besonderheiten bei Unternehmungen mit Projektleistungstätigkeit (siehe Abschnitt 4.2.1) ist, neben der Notwendigkeit zweier getrennter Lenkungskonzepte (Projekt- und Nichtprojektbereich), auf die simultane Berücksichtigung der Projekt- und Funktionalorganisation bei der Leistungs-, Kosten- und Finanzlenkung zu achten und diese letztendlich mit der Gesamtunternehmensführung zu harmonisieren (Lachnit L.; 1994, S. 80). Daraus ergibt sich folgende modulare Aufgabenstruktur eines Controllingsystems zur Erfolgs- und Finanzführung in Unternehmen mit Projektleistungstätigkeit (Lachnit L.; 1994, S. 81):

Abbildung in dieser Leseprobe nicht enthalten

Abb. 4.3 Führungsbereiche bei Unternehmen mit Projektleistungstätigkeit (Lachnit L.; 1994, S. 81)

Für die in Abb. 4.3 aufgeführten Teilaufgaben stehen Controllingmodule zur Verfügung auf die im Sinne eines Baukastenprinzips zurückgegriffen werden kann. Das technisch- organisatorische Projektcontrolling kann mit PPS- und Projektmanagement-Systemen abgesichert werden, zur Führung der Funktionalbereiche kann auf Budgetierungssysteme verwiesen werden und zur Führung des Nichtprojektbereichs steht das klassische Controllinginstrumentarium zur Verfügung. Laut Lachnit liegen die Schwächen hinsichtlich Konzeption und Lösungen im Bereich des wirtschaftlichen Projektcontrollings (Lachnit L.; 1994, S. 82). Mit dem anschließend dargestellten Modell PROCON will Lachnit zur Beseitigung dieser Schwächen beitragen.

4.2.3 Das wirtschaftliche Projektcontrolling-Modell PROCON

4.2.3.1 Grundstruktur des Projektcontrolling-Modells PROCON

Das Modell PROCON wurde entwickelt um neben der sachlichen, zeitlichen und hierarchischen Integration erfolgs- und finanzrelevanter Sachverhalte auch Fragen in Zusammenhang mit der Informationsverdichtung und -präsentation zu klären. PROCON leistet dreierlei:

1. Die erfolgs- und finanzorientierte Planung der einzelnen Projekte entsprechend ihrer Laufzeit,
2. die kalenderjahresbezogene Zusammenfassung von Umsatz, Leistung, Kosten und Zahlungen der Projekte und
3. die Anbindung an die Erfolgs-, Bilanz- und Finanzplanung des Gesamtunternehmens.

PROCON wurde als EDV-gestütztes Projektcontrollingsystem realisiert, das:

- Einzelprojektplanungen als laufzeitbezogene Erfolgs- und Liquiditätsplanung für bis zu 20 Projekte mit maximal 10 Teilabschnitten und einer Höchstlaufzeit von 5 Jahren, · Projektgesamtheitsplanungen als kalenderjahrorientierte Aggregation der Einzelprojekte für maximal 5 Jahre und
- Gesamtunternehmensplanungen als Erfolgs-, Bilanz- und Finanzplanung für maximal 5 Jahre durchführt.

Als Datenbasis zur Erfüllung der oben genannten Aufgaben dient die monatsbezogene Kosten- und Erlösplanung. Neben der erfolgs- und finanzorientierten Planung der Projekte und Projektegesamtheit wird durch Hinzunahme von Gesamtunternehmenssachverhalten eine Erfolgs-, Bilanz- und Finanzplanung ermöglicht.

Im Mittelpunkt der erfolgsorientierten Einzelprojekt-Planung stehen die Gesamtkosten je Teilabschnitt (Phase), der Projekterlös, die Einzel- und Gemeinkosten und daraus abgeleitet die Deckungsbeiträge, deren monatliche und jährliche Verteilung berechnet und ausgewiesen werden. Der Erlös wird dabei zu einem kalkulatorischen Erlös umgerechnet, indem er monatlich dem Gesamtkostenanfall entsprechend auf die Projektlaufzeit verteilt wird. Bei den Kosten wird zwischen Einzel (EK)- und Gemeinkosten (GK) unterschieden, wobei die Höhe der Gesamtkosten durch einzugebende Zuschlagssätze auf die Einzelkosten bestimmt wird. Die Berechnungen enden mit der Ausgabe von Deckungsbeiträgen (DB).

Die liquiditätsorientierte Einzelprojekt-Planung, die ebenfalls monatlich und jährlich erstellt werden kann, zeigt Ein- und Auszahlungen aus denen sich die Erfolgseinzahlungen, basierend auf dem auf Monate verteilten Gesamterlös des Projekts, errechnen lassen. Bei der Interpretation des Endbestand an liquiden Mitteln ist zu beachten, dass unter Auszahlungen nur die geplanten und somit aus der Kostenplanung übernehmbaren Einzelkosten zu verstehen sind, da sich die Zahlungshöhen und -zeitpunkte der Gemeinkosten nur gesamtunternehmensbezogen berechnen lassen (Lachnit L.; 1994, S. 86). Zusätzlich sind die aus Kreditaufnahme bzw. -tilgung resultierenden Zahlungen separat zu planen.

Durch Aggregation der Einzelprojektplanungen ergeben sich die erfolgs- und liquiditätsorientierten Planungen für die Projektegesamtheit und die Überleitung auf die Erfolgs-, Bilanz- und Finanzplanung des Gesamtunternehmens.

Die Erfolgsplanung für die Projektegesamtheit entsteht durch zusammenfassen der erfolgsrelevanten Ergebnisse aus der Einzelprojektbetrachtung (siehe vorhergehende Seite). Es werden, wie auf der Einzelprojektebene Erlös, EK, GK und DB ausgewiesen jedoch auf der Projektegesamtheitsebene. Die Berechnungen führen zum Betriebsergebnis (BER) per anno für die Projektegesamtheit. Das BER bildet zugleich einen Baustein der Gewinn und Verlustrechnung (GuV) und der Bilanz- und Finanzplanung des Gesamtunternehmens.

Die Liquiditätsplanung für die Projektegesamtheit läuft methodisch analog zur Erfolgsplanung. Es werden alle projektbezogenen Liquiditätsangaben summiert und ein Abschlag für die GK-Auszahlungen vorgenommen. Als Zusatzangaben ist die Planung der Auszahlungen für GK notwendig, wobei die Strukturierung der GK im Liquiditätsteil wegen der Gesamtunternehmens-Verursachung und Erfassung an die GuV-Rechnung angelehnt ist. Zum Ende erfolgt die jahresbezogene Erfolgs-, Bilanz- und Finanzplanung der Gesamtunternehmung. Hierzu können Daten wie die Umsatzerlöse aus der Liquiditätsplanung unverändert übernommen werden, wohingegen andere Positionen, wie beispielsweise die projektbezogenen EK und GK bei der Zuordnung auf die entsprechenden Positionen der GuV neu berechnet werden müssen. Außerdem sind viele Erfolgs-, Bilanz- und Finanzpositionen auf der Gesamtunternehmensebene nur indirekt oder gar nicht Bestandteil der projektbezogenen Planungen (z. B. Abschreibungsplanung). Diese Sachverhalte sind direkt in die Jahresabschlussrechnung des Gesamtunternehmens einzugeben, während die projektabgeleiteten Sachverhalte aus PROCON über eine geeignete Schnittstelle Eingang in die Jahresabschlussrechnung des Gesamtunternehmens finden (Lachnit L.; 1994, S. 87). Die gesamtunternehmensbezogenen Berechnungen finden im Modell ERFI (Erfolgs- und Finanzplanung der Gesamtunternehmung) statt, welches hier nicht weiter erläutert werden soll.

Das Modell PROCON wird über diverse Lotus123-Arbeitsblätter realisiert. Lotus123 bietet als Standardsoftware die Möglichkeit der Makro-Programmierung und somit gute Modellierungsmöglichkeiten. Die EDV-Umsetzung ist aufgrund der Datenfülle und der notwendigen Berechnungen für die späteren Auswertungen zwingend erforderlich (Lachnit L.; 1994, S. 88). Um einen Eindruck dieser EDV-gestützten Projektcontrollingkonzeption zu erhalten, wird auf den folgenden Seiten der Aufbau und die Nutzung des Modells PROCON beschrieben (Lachnit, L.; 1994, S. 88ff).

4.2.3.2 Datenbasis des Modells PROCON

Neben der voraussichtlichen Projektdauer sind im wesentlichen die Daten aus den Abbildungen 4.4 und 4.5 als Eingaben notwendig. Diese Daten können projektphasenweise oder für das Projekt als Ganzes eingegeben werden. In bezug auf die Datenbasis der Liquiditätsrechnung ist zu sagen, dass die Größen unter dem Oberbegriff Erfolgsauszahlungen aus der Erfolgsrechnung übernommen werden können und somit eine Mehrfacheingabe überflüssig ist. Die Datenbasen beziehen sich auf die Einzelprojektebene, für die Projektgesamtheit sind aber keinerlei zusätzliche Angaben erforderlich. Erst auf der Ebene der Gesamtunternehmung sind weitere Eingaben aus dem Nichtprojektbereich notwendig (Lachnit L.; 1994, S. 88).

Abb. 4.4 Datenbasis der Erfolgsplanung

Abbildung in dieser Leseprobe nicht enthalten

Bei der Erfolgsplanung werden als Kostenarten Einzel- und Gemeinkosten unterschieden. Während die EK direkt einzugeben sind, errechnen sich die GK durch GK-Zuschlagssätze auf die EK. Unter Restkosten sind all die Kosten zu finden, die zwar Projekteinzelkosten darstellen, sich aber einer eindeutigen Zuordnung zu den Projektphasen entziehen (Lachnit L.; 1994, S. 91). Die Restkosten generieren sich aus den Sondereinzelkosten (SEK). Die Eingabe von Preissteigerungsraten ist nicht zwingend erforderlich, doch ermöglichen diese bereits eine

Kostenanpassung in der Planung durch Preisindizes. Gerade bei langfristigen Projekten (> 1 Jahr Laufzeit) ist die Eingabe von Preisindizes sinnvoll. Die Preisindizes können auf zwei Arten eingegeben werden. Entweder als einmalige Eingabe global für die Projektdauer oder als monatliche Eingabe zur Berechnung der Lohn- bzw. Materialkosten unter Preissteigerungen.

Abb. 4.5 Datenbasis der Liquiditätsplanung

Abbildung in dieser Leseprobe nicht enthalten

Wie eingangs des Kapitels erwähnt, stammen die Erfolgsauszahlungen aus der Erfolgsplanung und müssen nicht noch einmal eingegeben werden. Diese Daten sind zu ergänzen um die Umsatzeinzahlungen, untergliedert in vertraglich festgelegte Anzahlungen, periodische Zahlungen, Restzahlungen und fakturiertem Umsatz, von dem angenommen wird, dass er in einem Monat anfällt. Komplettiert werden die einzugebenden Daten mit Angaben hinsichtlich Projektkrediten und dem Anfangsbestand (AB) liquider Finanzmittel. Die Eingabe von Projektkrediten ist nötig, da bei Bedarf an Auszahlungen bzw. bei entstehendem Überschuss an Einzahlungen, dies in der Regel durch projektbezogene Kreditpolitik auszugleichen versucht wird (Lachnit. L.; 1994, S. 90-100).

Abb. 4.6 Monatsbezogene Erlös-, Kosten- und Erfolgsplanung für ein Projekt (Lachnit L.; 1994, S. 101)

Abbildung in dieser Leseprobe nicht enthalten

p>4.2.3.3 Auswertungen mit PROCON

Auf der Basis von Einzelprojektdaten wird generell zwischen erfolgs- und liquiditätsorientierten Auswertungsbereichen unterschieden, die sich wiederum auf das Einzelprojekt, die Projektegesamtheit oder auf das Gesamtunternehmen beziehen. Bei langen Laufzeiten können Preissteigerungsindizes (Mit Index) verwendet werden. Die erfolgsorientierte Projektplanung mit PROCON sieht wie Abb. 4.6 aus (Lachnit L.; 1994, S. 101).

Abbildung in dieser Leseprobe nicht enthalten

Neben der monatlichen projektbezogenen Auflösung ist natürlich eine jährliche Zusammenfassung (Addition der Monatsauswertungen) vorgesehen. Zusätzlich besteht die Möglichkeit der projektphasenweisen Auswertung, wenn die Eingaben projektphasenspezifisch gemacht wurden.

Der Erlös, der zumindest näherungsweise, weil oft schon im Vorfeld ausgehandelt bekannt ist, wird projektlaufzeitbezogen auf die einzelnen Monate verteilt. Dabei erfolgt die Verteilung nicht nach gleichen monatlichen Raten, sondern kostenproportional periodisiert entsprechend dem aktuellen Gesamtkostenanfall. Die kalkulatorische Verteilung des Erlöses auf die Laufzeit des Projekts errechnet sich folgendermaßen (Lachnit L.; 1994, S. 102):

Die Summe der EK ergibt sich durch Addition der eingegebenen EK, wobei bei phasenbezogener Auswertung die Restkosten nicht in die Summe der EK einbezogen werden können. Den DB I erhält man aus der Differenz von Erlös und EK. Er biete in Summe und in monatlicher Verteilung einen ersten Anhaltspunkt zur Erfolgssicht des Projekts. Die vollkostenorientierte Erfolgsinformation über das Projekt liefert der DB II (Projektergebnis bzw. Betriebsergebnis auf der Projektegesamtheitsebene), als Differenz von DB I und der GK. Die GK entstehen durch Multiplikation der speziellen GK-Zuschlagssätze mit deren Bezugsgrößen, den jeweiligen EK. Die Verwaltungs- und

Vertriebsgemeinkostenzuschlagssätze beziehen sich auf die Herstellkosten des Projekts bzw. des Produkts. Der Ausweis der Gesamtkosten umfasst die Summe der Einzel- als auch der Gemeinkosten.

In der Auswertung können Plan- und Istwerte parallel aufgeführt werden, was eine Abweichungsanalyse ermöglicht. Durch detaillierten Ausweis der Kostenarten erhält der Betrachter wichtige Informationen für die Projektsteuerung (Lachnit L.; 1994, S. 102). Die erfolgsorientierte Planung bzw. Auswertung zeigt die Höhe und zeitliche Verteilung der Erlöse, Kosten und DBs. Nebenbei stellt diese Auswertung die Ausgangsgrößen der projektbezogenen Liquiditätsplanung zur Verfügung.

Damit die Liquiditätswirkung des Projekts insgesamt und im Zeitverlauf deutlich wird, ist die Liquiditätsauswertung erforderlich (Lachnit L.; 1994, S. 102). Auf der nächsten Seite ist das Auswertungsblatt der Liquiditätsrechnung zu sehen. Abbildung 4.7 gibt einen Überblick über benötigte und berechnete Größen dieser Auswertung.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 4.7 Monatsbezogene Liquiditätsplanung für ein Projekt (Lachnit. L.; 1994, S. 103)

Kern der Auswertung aus Abbildung 4.7 ist die Ermittlung des Nettozahlungseffekts aus den Erfolgsvorgängen des Projekts und die Bestimmung des Endbestand (EB) an liquiden Mitteln. Der Nettozahlungseffekt repräsentiert die Differenz aus den Summen der Erfolgsein- und - auszahlungen. Unter der Summe der Erfolgseinzahlungen tauchen nur tatsächlich in einer Abrechnungsperiode (Monat, Jahr, Phase) geflossene Geldsummen auf (erhaltene Anzahlungen, Restzahlungen und Umsatzeinzahlungen der Periode). Der nicht zahlungsbegleitete (zbgl.) Umsatzanteil der Fakturaperiode wird nur in der Periode gebraucht, in der, der Gesamtumsatz (Preis, Erlös des Projekts oder Produkts) verbucht bzw. eingezahlt wird. Der nicht zahlungsbegleitete Umsatzanteil ist periodenübergreifend, setzt sich aus erhaltenen Anzahlungen und Restzahlungen zusammen und erscheint nur bei Anfall des Gesamtumsatzes. Die Differenz von Erlös und nicht zahlungsbegleitetem Umsatzanteil ergibt die Umsatzeinzahlung der Periode, in dem der Erlös angefallen ist.

Bei den Erfolgsauszahlungen fehlen die durch GK verursachten Auszahlungen, da die in der Projekterfolgsrechnung verrechneten GK zum Teil nicht zahlungsbegleitete Komponenten enthalten, deren projektbezogene Abspaltung nur aufwendig durchführbar ist. Zudem stellen die prozentualen GK-Zuschlagsätze eher kostenrechnerisch orientierte Hilfsgrößen dar, deren Zahlungszeitpunkt kaum projektspezifisch, sondern lediglich gesamtunternehmensbezogen ermittelbar ist.

Der EB an liquiden Mitteln resultiert aus dem AB liquider Mittel, dem Nettozahlungseffekt, zu-/abzüglich des Postens für Projektkredite und stellt das Resultat der projektbezogenen Liquiditätsauswertung dar. Der AB liquider Mittel der Folgeperiode entspricht dem EB an liquiden Mitteln vermindert um die GK-Auszahlungen der aktuellen Periode. Da wie bereits erwähnt, die GK bei der Berechnung des EB an liquiden Mitteln unberücksichtigt blieben, werden diese in einem Informationsteil ausgewiesen. Die Summe für die GK des Projekts kann aus der Erfolgsplanung übernommen werden. Durch die Annahme eines Prozentsatzes für nicht zahlungsbegleitete GK und Subtraktion dieser von den GK des Projekts erreicht man, dass die auszahlungswirksamen GK als Korrektiv deutlich werden.

Der Vergleich von Nettozahlungseffekt und den (kalkulatorischen) Auszahlungen für GK erbringt den Kreditbedarf, die Gesamtzahlungswirkung und den Liquiditätsendbestand des Projekts je nach Periodisierung in monateweiser oder jährlicher Untergliederung.

Die genannten Projektplanungen (-auswertungen) bilden das Kernstück des Modells PROCON. Durch Zusammenführen der erfolgs- bzw. liquiditätsbezogenen Einzelprojektplanungen erhält die Unternehmensführung einen Überblick sowohl über die Ergebnislage (Betriebsergebnis der Projektegesamtheit) wie auch über die Liquiditätswirkung der Projektegesamtheit. PROCON bietet damit die Grundlage für hierarchisch strukturierte Erfolgs- und Liquiditätsplanungen, bei denen das Einzelprojekt das Fundament bildet und durch Aggregation der Projekterechnungen die Gesamtschau über die Gesamtheit der Projekte erreicht wird (Lachnit L.; 1994, S. 109).

Bei Hinzunahme bestimmter Komponenten, wie z. B. der projektunabhängigen Investitions- und Finanzzahlungen des Unternehmens und Ergänzung um weitere Daten aus dem Nichtprojektbereich, ist unter Verwendung des gesamtunternehmensbezogenen Erfolgs und Finanzmodells ERFI (PROCON ist Bestandteil dessen) eine Überleitung zum Gesamtunternehmungsführungssystem möglich. Diese Ausbaustufe soll aber unberücksichtigt bleiben, da die Projektcontrollingthematik im Mittelpunkt dieser Arbeit steht. Um die in den Abbildungen 4.6 und 4.7 geschilderten Auswertungen einfacher und komprimierter darzustellen ist es mit der Lotus 123-Software möglich die Daten der Auswertungstabellen zusammenzufassen und in tabellarischer und/oder grafischer Form darzustellen (Lachnit L.; 1994, S. 110). Hierbei bietet sich an, die Erfolgs- und Liquiditätsplanung auf einer Seite komprimiert zu präsentieren (siehe Abb. 4.8).

Abbildung in dieser Leseprobe nicht enthalten

Abb. 4.8 Managementübersicht auf Einzelprojektebene monatlich (Lachnit. L.; 1994, S. 111)

Diese Managementübersichten können, wie auch die Auswertungen, auf monatlicher, jährlicher Zeitbasis oder phasenweise für das Einzelprojekt und die Projektegesamtheit erstellt werden. Aus dem Verhältnis der Betragssummen zentraler Erfolgs- und Liquiditätsgrößen, ist zu erkennen, in welchem Umfang das/die Projekt(e) bereits verwirklicht wurde(n) bzw. wie viel an Beträgen und Aktivitäten noch aussteht.

Um die Projektentwicklung noch plastischer zu machen, können mit Hilfe der eingegebenen und berechneten Daten in Lotus 123 eine Reihe von Managementgrafiken erstellt werden. Dieses Vorgehen bietet sich hauptsächlich für die Abweichungsanalyse, die Trendentwicklung und als Frühwarnsystem an (Lachnit L.; 1994, S. 112). Die Auswertungen und Managementübersichten sind für Soll-/Istvergleiche und Sensitivitätsanalysen gleichermaßen geeignet, so kann die Notwendigkeit von Steuerungsmaßnahmen und die Auswirkungen von Datenänderungen auf die Erfolgs- und Finanzgrößen erkannt werden. Durch die EDV-Unterstützung ist auch die Möglichkeit der Simulation gegeben. Durch absichtliche Änderung des Datenmaterials können "was wäre wenn" Szenarios erstellt werden, um so im Vorfeld mögliche Handlungsalternativen für Abweichungen zu generieren und zu testen (Lachnit L.; 1994, S. 149ff).

4.3 Projektcontrollingkonzept von Riedel

Das Konzept von Riedel ist ein Projektcontrollingkonzept zur Unterstützung der Unternehmensführung auf der Einzelprojektebene. Das Controllingkonzept ist für Forschungs- und Entwicklungsprojekte ausgearbeitet worden und lässt sich daher problemlos auf den Aufgabenbereich Softwareentwicklung anwenden. Im Gegensatz zu dem Konzept von Lachnit, ist das hier vorliegende Konzept nur für die Zwecke des Einzelprojektcontrollings (i. e. S.) tauglich und könnte daher die Basis des Konzepts von Lachnit sein. Es ist ausgewählt worden, da es detailliert die erste Stufe des Projektcontrollings (Einzelprojektcontrollings i. e. S.) umfaßt und bereits softwareentwicklungstypische Aspekte berücksichtigt.

4.3.1 Themenfelder des Konzepts von Riedel

Abbildung 4.9 beschreibt die Themenfelder von Projektcontrolling. Ausgehend von diesen Feldern werden die Bestandteile dieser erklärt.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 4.9 Projektcontrolling und seine Themenfelder (Riedel J. E.; 1990, S.VI)

Das Themenfeld Management und Controlling wurde bereits in Kapitel 3 und Abschnitt 4.1.2 angesprochen und daher erübrigt sich eine weitere Ausführung zu diesem Thema.

4.3.1.1 Wirtschaftlichkeit, Produktivität und Leistungsmessung

Das Projektcontrolling ist darauf ausgerichtet die Produktivität und die Rentabilität des Einzelprojekts unter der Bedingung wirtschaftlichen Handelns zu steigern. Wirtschaftlichkeit drückt geldlich sparsames Handeln aus (Riedel J. E.; 1990, S. 20). Die Produktivität entspricht der Eigenleistung in ausgebrachten Mengen, ohne Bewertungseinflüsse (Riedel J. E.; 1990, S. 20). Wirtschaftlichkeit und Produktivität werden durch unzählige Parameter beeinflusst und es ist Aufgabe des Controllingsystems zumindest die einflussstärksten Parameter zu identifizieren und zu messen um eine neutrale Beurteilung des Entwicklungsaufwandes möglich zu machen. Es ist also eine Analyse der Entwicklungsarbeit von Nöten, die Erkenntnisse über die wesentlichen Parameter liefert und wie sie ausreichend beurteilt werden können. Boehm (Boehm, B. W.; 1981, S. 66ff) nennt diese Parameter Leistungseinflüsse (LEE), die in Abb. 4.10 in einer Zusammenschau aufgeführt sind.

Abb. 4.10 Leistungseinflüsse nach Boehm

Abbildung in dieser Leseprobe nicht enthalten

Diese LEE werden auf Dimensionen bezogen und eine Einstufung der Abweichungen vom Normalzustand in einer Bandbreite von max. 5 Größenordnungen (extra hoch, sehr hoch, hoch, niedrig, sehr niedrig) vorgenommen (siehe Abb. 4.11). Bei der Überlegung zur detaillierten Einschätzung der LEE für ein Softwareprojekt sind aufgrund von Erfahrungswerten Abweichungen gegenüber dem Normalzustand zu schätzen oder, wenn keine Erfahrungswerte vorliegen, anzunehmen (Boehm, B. W.; 1981, S. 66ff).

Abbildung in dieser Leseprobe nicht enthalten

Abb. 4.11 Einstufung von LEE nach Boehm

Für die noch zu besprechende Aufwandschätzung muss der Normalzustand bekannt sein, der durch die Leistungsmessung ermittelt oder per Definition vorgegeben wird. Die Leistungsmessung erleichtert im Rahmen der Aufwandschätzung die Beurteilung und Einstufung der Mitarbeiter bzgl. deren Entwicklungsleistung. Zu Beginn ist daher eine sogenannte Normalleistung zu ermitteln. Nach Zenz (Zenz, P.; 1981, S. 103ff) gibt es zwei Möglichkeiten der Leistungsmessung:

a) die ergebnisorientierte (zeitbezogene Betrachtung, Gegenüberstellung des Gesamtumsatzes neuer Produkte und Anzahl neuer Produkte) und
b) die prozessorientierte Methode.

Da Möglichkeit A aufgrund der globalen Betrachtung auf Produktebene nur grobe Ergebnisse liefert, soll die Leistung nach Möglichkeit B berechnet werden (Riedel J. E.; 1990, S. 25). Der prozessorientierten Leistungsmessung ist der Vorteil der Detailbetrachtung zuzuerkennen, da hier Teilergebnisse einem Leistungsvergleich unterzogen werden können. Bedingung für dieses Vorgehen ist eine Strukturierung der Projekte in Teileinheiten und Phasen, denen bestimmte Arbeitsergebnisse zugeordnet sind (siehe Kap. 4.3.1.2). So kann durch eine prozesskonform detaillierte Stundenkontierung und Aufzeichnung effektiver Leistungsmengen die Leistungsmessung erfolgen, wobei die Mitarbeiter streng nach einem Entwicklungsprozessplan vorgehen müssen, der die Entwicklungsarbeit und Arbeitsergebnisse organisatorisch festlegt. Dann sind die im Prozessverlauf erzielten Leistungsmengen der einzelnen Arbeitsergebnisse ins Verhältnis zu dem dafür von den Mitarbeitern insgesamt benötigten Ist-Stundenaufwand zu setzen. Zur Durchführung der Messung werden Ausgangsdaten wie (Riedel J. E.; 1990, S. 27):

- Summe der bewerteten Leistungseinflüsse (Abb. 4.11),
- Ausbringungsmengen der Arbeitsergebnisse in bestimmter Dimensionierung,
- jeweiliger Zeitverbrauch zur Erzielung eines Arbeitsergebnisses (geleistete und kontierte IstNettostunden) und
- Vergleichskennzahlen benötigt.

Um die Leistung beurteilen zu können müssen die Leistungsmengen ermittelt werden. Hierzu sind zunächst geeignete Dimensionen der Leistungsmengen zu finden. Je nach Phase des Entwicklungsprozesses sind diverse Dimensionen denkbar (Beispielsweise Funktionen, Dokumentationsseiten, NLOC=Netto lines of code, PVZ=Programmverzweigungen, FU(Funktionen)-Testfälle usw.). Die Leistungsmessung hat in prozesskonformen Messbereichen stattzufinden, denen klar abgrenzbare und quantifizierbare Arbeitsergebnisse zuordenbar sind. Die Arbeitsergebnisse, für die eine Leistungsmessung erfolgen soll sind im Entwicklungsstrukturplan festzulegen. Für die nun folgenden Berechnungen wird von Nettoarbeitsstunden ausgegangen, es sind also keine Fehlzeiten, Pausen, Zeiten für Weiterbildung usw. enthalten. Das Ziel der Leistungsmessung ist die Erfassung des Arbeitszeitaufwands pro Messbereich und Feststellen der Leistungsmengen des technischen Arbeitsergebnisses in geeigneter Dimension, um eine Relation dieser Daten zu erhalten. Das Vorgehen dient nicht dazu Mitarbeiter in ihrer Leistung zu beurteilen, sonder vielmehr geht es um die Messung der Leistungsfähigkeit von Gruppen im Verhältnis zur Durchschnittsleistung z. B. der Abteilung.

Die jeweilige Leistung (LEj) ist das Ergebnis einer ausgeführten Arbeit in einer bestimmten Zeit (netto) unter spezifischen Bedingungen. AE ist hierbei die Arbeit bzw. das Arbeitsergebnis, das während der jeweiligen Arbeitsstunden (ATj) erbracht wurde. Um zu einer Vergleichsbasis zu gelangen benötigt man den normalisierten Ist-Arbeitszeitaufwand, der frei von jeglichen speziellen Entwicklungsgegebenheiten ist und die Basis für die Messung der Normalleistung unter Normalbedingungen darstellt. Der normalisierte Ist- Arbeitszeitaufwand berechnet sich wie unten (Riedel J. E.; 1990, S. 28).

LEj jeweiliges Leistungsergebnis; AE Arbeitsergebnis

ATj jeweilige Arbeitsstunden; ATn normalisierte Arbeitsstunden

LEE Leistungseinflüssemix (Einstufungsmix)

ATn gibt an, wie viel Zeit ein Mitarbeiter, eine Gruppe oder Abteilung für ein Arbeitsergebnis unter Normalbedingungen benötigt und bildet daher einen guten Vergleichswert, um Gruppenarbeitsergebnisse bei vergleichbarem Arbeitsinhalt trotz unterschiedlicher Bedingungen (Arbeitsumfeld, Ausbildung, Erfahrung, Tooleinsatz usw.) zu vergleichen. Um abschließend zu leistungsbeschreibenden Messzahlen zu gelangen, ist das Verhältnis aus normalisierten Arbeitsstunden und dem entsprechenden Arbeitsergebnis in geeigneter Dimension zu bilden. Die Messzahlen sind das Ergebnis der Leistungsmessung eines Arbeitsergebnisses nach Abschluss eines Meilensteins oder aller Arbeitsergebnisse. Sie bilden zudem die Grundlage für die Bildung von Kennzahlen. Abb. 4.12 fasst den Vorgang der Messzahlbildung noch einmal zusammen.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 4.12 Messzahlenkreation im Zuge der Leistungsmessung

4.3.1.2 Organisation und Transparenz

Bedingung für die erfolgreiche Durchführung von Projektcontrolling, ist die Schaffung einer Ordnung und Regelung der Verantwortlichkeiten. Es ist daher eine Organisation aufzubauen damit die Projekte und Arbeitsprozesse in sich transparent werden (Riedel J. E.; 1990, S. 41). Die Projektorganisation (Aufbauorganisation) ist Aufgabe des Projektmanagements und daher im Zuge der Organisationsfragen zu lösen. Sie ist wichtig, um volle Transparenz der Leistungen des Projektteams in Kosten und Ausbringung abbilden zu können. Den Einsatz der Projektorganisation betreffend sind allerdings Einschränkungen zu machen, wenn das Vorhaben nicht den Grundbedingungen der Projektdefinition entspricht. Ungeeignet in diesem Sinne sind somit Aufgaben für die (Riedel J. E.; 1990, S. 46):

- keine klaren Abgrenzungen der Aufgaben und Ziele sowie · keine zeitlichen Restriktionen der Fertigstellungstermine bestehen.

Außerdem scheiden alle kleineren Aufträge (< 0,5 Mannjahre) bzgl. einer tiefergehenden Strukturierung im Sinne von Projekten aus (Riedel J. E.; 1990, S. 46).

Wichtige Kriterien bei der Auswahl der geeigneten Projektorganisationsform sind (Warnecke, H. J.; 1996, S. 78):

- Dauer des Projekts,
- Wertigkeit (Wichtigkeit, Umfang, Konsequenzen), · Projektart (Innovations- vs. Standardprojekte), · Qualität des Personals (bes. Projektverantwortliche), · Zahl der Projekte (Teileinheiten) und
- Komplexität.

Sind die organisationsrelevanten Eigenschaften des Projekts erkannt ist eine

Projektorganisationsform zu wählen. Das Management hat die Wahl zwischen der reinen, der Einfluss und der Matrixprojektorganisation (Abb. 4. 13).

Abbildung in dieser Leseprobe nicht enthalten

Abb. 4.13 Aufbauorganisationsformen der Projektorganisation

Während bei der reinen Projektorganisation die dem Projekt zugeteilten Ressourcen und Verantwortlichen komplett aus der Linienorganisation herausgelöst werden und selbstverantwortlich arbeiten, verbleiben diese bei der Einfluss-Projektorganisation in der Linie. Die Matrix-Projektorganisation verbindet die Vorteile der anderen Projektorganisationsformen, indem sie die Ressourcen in der Linie belässt wie in der EinflussProjektorganisation und der Projektleitung Kompetenzen zur Ressourcenbelegung im Sinne des Projektes gibt. Die einzelnen Projektorganisationsformen sind bei Interesse z. B. bei Madauss (Madauss B. J.; 1990, S.101) zu finden.

Bei der Ablauforganisation (Prozessorganisation) steht im Gegensatz zur Projektorganisation nicht die Funktionsgliederung, sondern die Prozessgestaltung im Mittelpunkt. Die Ablauforganisation beinhaltet Definition und Synchronisation der Teilprozesse in einem Projekt sowie die Unterteilung des Gesamtablaufs in logische Abschnitte, Phasen und Prozessschritte, die jeweils durch Meilensteine abgegrenzt sind (Platz, Schmelzer; 1986 S. 107). Es gibt prinzipiell zwei Möglichkeiten der Ablaufstrukturierung. Zum einen das Prototyping, das den Anwender stärker in die Entwicklung einbindet, indem mit Hilfe von Programm-Generatoren sehr schnell ein erster Prototyp der gewünschten Software erstellt wird, der es dem Anwender frühzeitig erlaubt Änderungs- und Verbesserungsvorschläge zu machen. Hierdurch ist im Gegensatz zum Phasenkonzept eine kontinuierliche Änderungsmöglichkeit geboten. Dieser Ansatz eignet sich für hoch innovative und kurzfristige Projekte (Lackman, M.; 1997, S. 21). Aufgrund der doch eher langfristig angelegten Softwareentwicklungsprojekte wird hier das Phasenkonzept benutzt. "Unter einer Phasenorganisation versteht man die Unterteilung des Entwicklungsprozesses in eindeutig definierte und logisch aufeinander aufbauende Schritte, die Phasen. Das Ende einer Phase wird durch ein klar definiertes Ergebnis, eines oder mehrerer Meilensteine, beschrieben (siehe Abb. 4.14). Da die Abarbeitung jeder Phase eine bestimmte Zeit dauert, ergibt sich eine zeitliche Segmentierung des Projektablaufs" (Platz, Schmelzer; 1986 S. 107).

Die Organisation von Entwicklungsprozessen bildet die Grundlage der für das Projektcontrolling wichtigen Kalkulationsstruktur (siehe Abb. 4.18).

Abb. 4.14 Phasenmodell des Softwareentwicklungsprozesses

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.14 stellt ein Phasenmodell der Softwareentwicklung dar, das für die Markant SE und Dienstleistungs GmbH geeignet wäre.

Aufgrund der Arbeitsteilung innerhalb eines Projektes ist es notwendig eine Tätigkeitsorganisation zu entwerfen. Um eine zu tiefgehende Auffächerung der Tätigkeiten zu vermeiden, wird im Sinne einer Straffung von Tätigkeitsarten gesprochen. Dieser Ausdruck steht für eine Reihe zusammengehöriger Einzeltätigkeiten. Eine Tätigkeitsart muss unabhängig vom Wiederholungsgrad und weitgehend neutral sein (Riedel J. E.; 1990, S. 49ff).

Abb. 4.15 Tätigkeitsorganisation

Abbildung in dieser Leseprobe nicht enthalten

Das obige Schaubild gibt ein Beispiel für den Aufbau einer Tätigkeitsorganisation, nach der die Arbeitszeit zu verbuchen ist.

Eine weitere Voraussetzung für das kostenorientierte Projektcontrolling ist die Strukturierung von Projekten, die zu einer Transparenz dieser führt.

Die Strukturierung soll sich mindestens an sechs Kriterien ausrichten (Riedel J. E.; 1990, S. 53):

(1) Vollständige Erfassung aller zu entwickelnden Produktkomponenten und erkennen aller Funktionen.
(2) Volle Transparenz des Projektes und seiner Teileinheiten.
(3) Festlegung der Verantwortlichkeiten.
(4) Kenntnis über alle zu bearbeitende Arbeitsvorgänge, zu liefernde Objekte und zu leistende Sachergebnisse.
(5) Realitätsnahe Ermittlung des Personalaufwands, der Zeit und der Kosten (vollständiges Arbeitsvolumen).
(6) Stufenweise Detaillierung der Pläne (siehe Abb. 4.16).

Nach Platz (Platz, Schmelzer; 1986 S. 144) sind für eine vollständige Strukturierung drei aufeinander aufbauende Strukturpläne nötig (siehe Abb. 4.16):

- der Produktstrukturplan,
- der Objektstrukturplan und · der Projektstrukturplan.

Abb. 4.16 Strukturpläne (Riedel J. E.; 1990, S. 54)

Abbildung in dieser Leseprobe nicht enthalten

Der Grad der Strukturierung sollte von der Projektgröße abhängig gemacht werden, wobei jedes Unternehmen hierbei seinen eigenen Kriterienkatalog zur Größeneinteilung der Projekte aufzustellen hat. Eine mögliche für die Markant SE und Dienstleistungs GmbH erarbeitete Einordnung von Projekten nach der Größendefinition und der sich daraus ergebenden Konsequenzen ist in Abb. 4.17 zu sehen.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 4.17 Strukturierungstiefe des Projektcontrollings

Für das kostenorientierte Projektcontrolling ist die Kalkulationsstruktur von besonderer Wichtigkeit, da die Aussagekraft der Kalkulationsergebnisse von der Detaillierungsebene der Kalkulationsstruktur abhängt. Dabei ist zu berücksichtigen, dass nur bis zu einer überschaubaren Anzahl kalkulationsrelevanter Teileinheiten detailliert wird. Sonst ist die Struktur entweder nicht aussagefähig genug, da zu grob oder zu fein und daher unübersichtlich und wenig praktikabel. Unter einer Teileinheit wird in dieser Arbeit ein technisch abgrenzbares und für das Projektcontrolling bedeutsames Strukturelement innerhalb eines Projekts verstanden, das mehrere Arbeitspakte enthält.

Eine optimale Kalkulationsstruktur erfordert vor allem drei Gesichtspunkte (Riedel J. E.; 1990, S. 57):

- Aufteilung großer Systeme oder Vorhaben, die quasi Projektgruppen darstellen, in überschaubare Projekte.
- Aufteilung großer Projekte in eine überschaubare Anzahl kalkulationsrelevanter Teileinheiten.
- Begrenzung der Auflösung nach unten (optimale Größe der Teileinheiten).

Das generelle Problem der Zergliederung von Aufgaben in Teilaufgaben sollte nach bestimmten Kriterien, wie z. B. der Größe dieser Aufgaben angegangen werden. Die Größe von SE-Projekten bzw. Aufgaben kann über den Umfang in Mannjahren, der Entwicklungsdauer, der Anzahl zu realisierender Funktionen usw. festgelegt werden. Für die Einordnung der Vorhaben nach Größe können Überlegungen zur technischen Abgrenzung (Betriebssystem, systemnahe Software, Anwendersoftware), zum Management (Projektleitung, Subverantwortliche, Projektsteuerverfahren) und dem bereits erwähnten Aufgabenumfang (Mannjahre, Entwicklungskosten) angestellt werden (siehe Abb. 4.17, S. 45).

Abbildung in dieser Leseprobe nicht enthalten

Abb. 4.18 Kalkulationsstruktur (Riedel J. E.; 1990, S. 60)

Die Kalkulationsstruktur muss, wie in Abbildung 4.18 dargestellt mit dem Projektaufbau und den Prozessabläufen gleichlaufend sein.

Sie besteht aus zwei Hauptstrukturteilen (Riedel J. E.; 1990, S. 59):

- der Kalkulationsstruktur Teil 1, die alle kalkulationsrelevanten Teileinheiten des Projekts in Hierarchiestufen angeordnet enthält und
- der Kalkulationsstruktur Teil 2, die in einer Teileinheit den Prozessablauf nach Phasen und Tätigkeitsarten, ergänzt um wesentliche nicht tätigkeitsgebundene Kostenbestandteile, die nicht im Personalstundensatz enthalten sind, abbildet.

Der Kalkulationsstrukturplan hat vor der Erstellung der ersten Vorkalkulation vorzuliegen, da er den Rahmen der Kalkulation bestimmt, der exakt dem Projektaufbau und den Prozessabläufen für die Softwareentwicklungsaufgabe entspricht. Die Tiefe der Strukturierung sollte maximal bis zur Teileinheitsebene reichen, um überschaubar zu bleiben.

4.3.1.3 Projektplanung und Kalkulation

Der Projektplanung übergeordnet ist die strategische Planung.

Im Rahmen der Aufgaben zur Bewertung der eigenen Wettbewerbsstärke, Zielsetzung und Strategieentwurf, Festlegung der F & E Erfordernisse und Prioritätensetzung für die Entwicklungsabteilungen sind wirtschaftliche wie technologische Erfolgsfaktoren herauszuarbeiten. Das Vorgehen kann auf diversen Planungsebenen wie strategischem Geschäftsfeld, Projektegruppe, Projekt und Teileinheit (TE) angewendet und entsprechend detailliert werden. In allen Planungsebenen ist auf Kompatibilität bzgl. eines späteren Datenzusammenflusses der unterschiedlichen Pläne hinzuarbeiten (Daten von TE müssen sich über deren Auftragskonten zu Projekten verdichten lassen).

Projektspezifische Strategieaspekte können sein (Riedel J. E.; 1990, S. 69): Im Bereich Entwicklung: Produktion: Vertrieb:

Abbildung in dieser Leseprobe nicht enthalten

Um ein systematisches Vorgehen zu unterstützen ist die Projektplanung in mehreren Schritten durchzuführen (Riedel J. E.; 1990, S. 62):

Schritt 1: - Prozessablaufplanung (systematisch und einheitlich für alle Projekte)

Schritt 2: - Strukturplanung (schafft ganzheitlichen Überblick und die Einbettung in den Prozessablauf)

Schritt 3: - Mengenplanung

Schritt 4: - Kostenplanung

Schritt 5: - Terminplanung

Schritt 6: - Personaleinsatzplanung

Bei diesem Vorgehen ist auf Kompatibilität und Koordination der Pläne zu achten, davor allem der Mengen-, Kosten- und Terminplan miteinander verwoben sind. Die Strukturplanung gewährleistet den ganzheitlichen Überblick und die Einbettung in den Prozessablauf von Vorhaben. Durch diesen Plan wird eine sach- (Meilensteinergebnisse), termin- (Netzplan) und kostengerechte (Plan/Ist-Kosten in Kalkulationsstruktur) Projektplanung über alle Aufgaben im Prozessablauf erreicht. Für eine strukturierte Projektkalkulation sind mehrere Pläne notwendig (Riedel J. E.; 1990, S. 75):

Auf der Planungsebene des Systems (Projektgruppe):

- Übersichtspläne, aufgelöst bis zu dem/den Projekt(en) · Auftragssystemplan nach einer Systemanalyse

Auf der Planungsebene des Projekts:

- Kalkulationsstrukturplan (Abb. 4.18), aufgelöst bis auf kalkulationsrelevante TE · Objektorientierter Projektstrukturplan (Abb. 4.16) in voller Detaillierung

Auf der Planungsebene der TE:

- Prozessorientierter Strukturplan (Abb. 4.15 und 4.14) mit Phasen und Tätigkeitsarten · Verrichtungs- und zeitorientierter Strukturplan im Detail

Auf die Erläuterung der diversen Pläne, sofern sie sich nicht aus den angegebenen

Abbildungen ergibt, wird wegen des Umfangs verzichtet (Riedel E. R.; 1990, S. 66-76). Ausgangsbasis für die Mengenplanung ist die Strukturplanung. Bedingung für die Mengenplanung ist (Riedel J. E.; 1990, S. 76ff):

- Strukturierung des Projekts bis zur Kalkulationsstruktur.
- Der Prozessablauf von TE in den Abteilungen sollte einheitlich sein und ist systematisch zu betreiben.
- Für alle in der Prozessorganisation vorgesehenen Arbeitsergebnisse sind eindeutige

Dimensionen für die Planung erwarteter und später realisierter Leistungsmengen festzulegen.

Da jede Kalkulation aus einem Mengen- und Wertegerüst besteht hat die Mengenplanung besondere Bedeutung. Eine realistische Einschätzung der geplanten und auf Dimensionen bezogene Mengen ist vor allem für die Vorkalkulation wichtig. Es sind somit alle Ressourcen vollständig zusammenzustellen und zu bewerten. Die entscheidende, weil kostenintensivste Ressource ist das Entwicklungspersonal. Eine Mengenplanung der von den Mitarbeitern zu erbringender Sachergebnisse (sachbezogenes Arbeitsergebnis z. B. Meilenstein am Ende eines Prozessschritts) führt zur Schätzung des Personalaufwands. Riedel empfiehlt also keine direkte Aufwandstundenschätzung, sondern eine von der Mengenplanung abgeleitete. Nachfolgend steht daher die Schätzung des Personalbedarfs im Mittelpunkt. Die Aufwandschätzung unterstützt die:

- Entscheidung des Managements bei der Genehmigung von Projekten, · die Kalkulation für Preisangebote,
- die Kapazitäts- und Terminplanung, · die Mitarbeitereinsatzplanung,
- die Entscheidung ob Eigen- oder Fremdentwicklung und

· Plan-/Plan- und Plan-/Ist-Vergleiche des Personalaufwands während des Projektablaufs

Der Mengenplan pro Teileinheit und Arbeitsergebnis ist vom Projektleiter bzw.

Subverantwortlichen zu erstellen. Ebenso sind die aufwandverändernden Leistungseinflüsse zu schätzen. Die Vorgehensweise bei der Aufwandschätzung ist aus der Abbildung 4.19 zu entnehmen.

Abb. 4.19 Prinzip der Aufwandschätzung (Riedel J. E.; 1990, S. 82)

Abbildung in dieser Leseprobe nicht enthalten

Nach der Umsetzung von Kundenforderungen in Anforderungsspezifikationen seitens der beteiligten Abteilungen wird der Kalkulationsstrukturplan des Projekts unter Bezugnahme auf den Projektstrukturplan erstellt. Alsdann werden die im Kalkulationsstrukturplan festgelegten Softwarekomponenten des Projekts in Teileinheiten mit vorgegebenem Funktionsumfang unterteilt (Ende der Phase Analyse, Start der Phase Entwurf) und deren Funktionsspezifikationen erstellt. Parallel dazu erfolgt die Erstellung der Entwurfsspezifikationen je Teileinheit. Die so spezifizierten Teileinheiten sind als selbständige Schätzobjekte anzusehen, für die eine Analyse der LEE und die Mengenplanung durchzuführen ist. Zudem bilden diese im späteren Projektablauf die Kontierungs- und Controllingeinheiten, also die eigentlichen Kalkulationsobjekte (Riedel J. E.; 1990, S. 82f). Um den Personalaufwand vernünftig und systematisch zu schätzen bietet sich die kennzahlenorientierte und prozessbezogene Aufwandschätzung (PAKO) an, ein von Riedel selbst entwickeltes Verfahren, das aufbauend auf der Mengenplanung meilensteinbezogener Arbeitsergebnisse in verschiedenen Dimensionen den Grundaufwand mit Hilfe von Kennzahlen ermittelt und durch kostenverändernde Einflussgrößen modifiziert. Die Methode PAKO ist eine prozessbezogene Aufwandschätzung, da sie exakt auf den Arbeitsergebnissen am Ende von Meilensteinen einzelner Teileinheiten aufsetzt (Riedel J. E.; 1990, S. 92-97). Voraussetzung für PAKO ist eine dimensionsbezogene Mengenplanung der Arbeitsergebnisse der einzelnen Meilensteine und eine Kalkulationsstruktur, die sämtliche relevanten Teileinheiten inklusive zugehöriger Arbeitsergebnisse enthält. Die Kennzahlenorientierung kommt durch die Bewertung von geplanten Mengen mittels Kennzahlen zum Ausdruck. Der so bewertete Grundaufwand wird durch LEE modifiziert und so realitätsnäher gemacht. Die für PAKO benötigten Schätzgrunddaten beziehen sich immer auf eine Teileinheit und bestehen aus den geplanten Mengen aller Arbeitsergebnisse modifiziert mit den für die Teileinheit geschätzten LEE. Ausgehend von den geplanten Mengen erfolgt die Berechnung des Grundaufwands pro Arbeitsergebnis durch Multiplikation mit einer den Normalaufwand repräsentierenden Kennzahl der entsprechenden Produktkategorie und Dimension.

Die nächste Abbildung demonstriert das Vorgehen und die Bestandteile der PAKO-Methode.

Abb. 4.20 Prozessbezogene Aufwandschätzung, kennzahlenorientiert (PAKO) (Riedel J. E.; 1990, S. 94)

Abbildung 4.21 enthält ein Beispiel zur Ermittlung des Grundaufwands je Phase und des jeweiligen Aufwands auf Phasen und Tätigkeitsarten verteilt. Das gezeigte Beispiel baut auf dem SE-Prozessplan gemäß Abbildung 4.14 auf. Die Kennzahlen stellen Erfahrungswerte dar, die entweder aus der Literatur zu übernehmen sind oder auf eigenen Erfahrungen aus der Vergangenheit beruhen.

Abbildung in dieser Leseprobe nicht enthalten

TA=Tätigkeitsart: E=Entwerfen, I=Inspizieren, T=Testen(-planen), C=Codieren,

D=Dokumentieren; DS=Dokumentierte Seiten (1,5 zeilig); FU=Funktionen,

LM=Leistungsmerkmale; MSTD=Mannstunden, MM=Mannmonate, KZ=Kennzahl; NLOC=Netto Lines of Code, PVZ=Programmverzweigungen

Abb. 4.21 Beispiel einer Aufwandschätzung (Riedel, J. E.; 1990, S. 97)

Bei der Ermittlung des jeweiligen Aufwands, kann pro Phase die Tätigkeitsart Überarbeiten hinzugefügt werden, da viele Arbeiten aufgrund mangelnder Qualität zu überarbeiten und zu korrigieren sind. Der vollständige jeweilige Gesamtaufwand ergibt sich aus der Addition aller Tätigkeitswerte und ist eine der Grundlagen der Projektkalkulation. Die Projektkalkulation unterstützt das Controlling, die Preisbildung und die interne Kostenverrechnung. Die wichtigsten Aufgaben der Projektkalkulation sind (Riedel J. E.; 1990, S. 99):

- Bestimmung des Arbeitsumfangs durch Mengenplanung pro TE und Meilensteinergebnis, · Schaffung einer objektiven Ausgangsbasis für die Projektsteuerung und · Kreation von Mess- und Kennzahlen.

Die Kalkulation enthält somit die Kosten-, Termin-, Kapazitäts- und Finanzplanung respektive -rechnung.

Für eine effektive Projektkalkulation sind verschiedene Voraussetzungen zu schaffen (Riedel J. E.; 1990, S. 100):

- Einheitliche Vorschrift über Abwicklung und Bedingungen einer jeden Entwicklungsvereinbarung
- Strukturierung der Projekte laut Prozessplan
- Integrierte Verfahren zur Unterstützung der Informationsgewinnung und -auswertung · Organisation der Prozessabläufe für die SE mit Definition erwarteter Arbeitsergebnisse

Zudem muss die Kalkulation dem Projektaufbau wie auch der Prozessorganisation folgen, was einen standardisierten Kalkulationsaufbau notwendig macht, der sich durch zwei wichtige Merkmale auszeichnet:

- eine nach dem Prozessablauf strukturierte Kalkulation pro Softwareteileinheit und
- eine nach Hierarchiestufen des Projektaufbaus vereinfachte Kostenzusammenfassung aller wichtiger Kostenelemente pro Teileinheit.

Die Projektkalkulation verringert das wirtschaftliche Risiko für die entwickelnde Unternehmung und ist das Rückgrat des Projektcontrollings. Sie ist gleichzeitig Grundlage der Projektplanung und -steuerung. Mit Hilfe von Daten aus der Projektkalkulation lassen sich abschließend Leistungen verrechnen und Kennzahlen ermitteln. Im Projektzeitverlauf hat die Projektkalkulation unterschiedliche Aufgaben zu erfüllen, sie wird daher in Vor-, Mit- und Nachkalkulation gegliedert. Abbildung 4.22 verdeutlicht diesen Sachverhalt und gibt neben den pro Kalkulationsstufe aufgeführten Kernaufgaben zudem einen Einblick in das Gesamtsystem des kostenorientierten Projektcontrollings und dessen Ziel (Riedel J. E.; 1990, S. 101ff).

Abbildung in dieser Leseprobe nicht enthalten

Abb. 4.22 Aufbau des kostenorientierten Projektcontrollings (Riedel J. E.; 1990, S. 16)

Genauso wichtig wie der auf der Vorseite erwähnte einheitliche Kalkulationsaufbau, ist ein standardisiertes Kalkulationsschema innerhalb der Teilbereiche des Kalkulationsaufbaus. Erst diese Standardisierung ermöglicht eine effektive Projektkalkulation. Abbildung 4.23 zeigt beispielhaft ein solches Kalkulationsschema für den Teilbereich Softwarerealisation.

Abb. 4.23 Kalkulationsschema der Softwarerealisation (Riedel J. E.;1990, S. 103)

Abbildung 4.23 zeigt ein Kalkulationsschema, das zusätzlich Kostenkomponenten enthält um der Teileinheit nicht direkt zurechenbare bzw. von dieser nicht direkt verursachte Kosten anzulasten. Hierbei sollte es sich nur um die wesentlichsten Komponenten handeln, die einen bedeutsamen Anteil der Gesamtkosten des Projekts ausmachen, wie die nicht phasenbezogenen Kosten oder die allgemeinen Kosten (Tools, allg. Verwaltung, usw.).

Die phasenbezogenen Kosten werden einerseits, wie der Name schon sagt phasenweise und andererseits nach Tätigkeitsarten ausgewiesen bzw. geplant, wobei zwischen Personal- und anderen Kosten unterschieden wird.

Um eine Kalkulation, aufbauend auf dem Kalkulationsschema von Abbildung 4.23, durchzuführen, muss die benötigte Information erhoben und zugänglich gemacht werden. Eine schnelle und vollständige Informationsversorgung der Projektkalkulation ist Voraussetzung für den reibungslosen Ablauf dieser. Hierbei ist darauf zu achten, dass Datenredundanz möglichst vermieden wird und die Daten so erhoben werden, dass sie ohne Modifikation nutzbringend verwertet werden können (Riedel J. E.; 1990, S. 105f). Trotzdem dürfte es nicht zu vermeiden sein, dass projektspezifische (oder teileinheitsspezifische) Informationen erhoben werden müssen. In untenstehender Abbildung ist der Informationsbedarf der Projektkalkulation in groben Zügen wiedergegeben.

Abb. 4.24 Informationsbedarf der Projektkalkulation (Riedel J. E.;1990, S. 106)

Abbildung in dieser Leseprobe nicht enthalten

Die Projektkalkulation beginnt laut Abbildung 4.22 mit der Vorkalkulation. Die Vorkalkulation dient dem Überholen der globalen Schätzwerte vom Projektbeginn und setzt daher einen ausreichend guten Kenntnisstand über die Leistungsanforderungen und der erwarteten Arbeitsergebnisse des Projekts oder der Teileinheit voraus. Sie ist notwendig um die Kostengrundlage für Preis- und Leistungsverhandlungen mit der Kundschaft zu schaffen und ist deswegen so früh wie möglich zu beginnen. Mit Hilfe der Vorkalkulation wird auch der voraussichtliche Mittelbedarf für die einzelnen Arbeitsergebnisse berechnet. Dabei ist der Entwicklungsaufwand für eine Teileinheit auf die Phasen und Tätigkeitsarten zu verteilen, um den später folgenden Plan-/Ist-Vergleich sinnvoll durchführen zu können (Riedel J. E.; 1990, S. 109ff). Die Vorkalkulation ist so aufgebaut, dass sie dem Prozessablauf der Entwicklungsarbeit nach Phasen und Tätigkeitsarten folgt und diesen in den anteiligen

Aufwandswerten und Kosten widerspiegelt. Um die erforderliche Realitätsnähe zu erreichen, sind Aufwandschätzverfahren hilfreich. Abbildung 4.25 stellt den Ablauf der Vorkalkulation in groben Zügen dar.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 4.25 Prinzipablauf der Vorkalkulation (Riedel J. E.;1990, S. 109)

Nach Projektstart hat die Mitkalkulation die Aufgabe einer zwischenzeitlichen Kontrollrechnung. Die Mitkalkulation bildet den Kern des kostenorientierten Projektcontrollings (Riedel J. E.; 1990, S. 112). Eine detaillierte Vorkalkulation, die innerhalb von Teileinheiten nach Phasen und Arbeitsergebnissen strukturiert ist, bildet die Voraussetzung der Mitkalkulation.

Die Mitkalkulation:

- dient zur Information über den aktuellen Kostenstand,
- liefert die Datengrundlage für Kostenanalyse, Fortschrittsrechnung, Anpassungsentscheidungen und
- hilft bei der Abschätzung der Gesamtkosten (Restkostenproblematik).

Die Hauptaufgabe der Mitkalkulation liegt in der phasenbezogenen Überwachung der aufgelaufenen Ist-Werte. Weitere Aufgaben sind:

- die laufende Steuerung und Kontrolle der Projektabwicklung (technische Sicht), · die Terminsteuerung und -kontrolle (Termin-Trendanalyse), · die Kapazitätssteuerung und -kontrolle (Belegungsplan), · Steuerung und Kontrolle der Finanzentwicklung und · die Kostensteuerung und -kontrolle (Lachnit L.; 1994, S. 42f).

Für eine effektive Abweichungsanalyse und Kostensteuerung ist der voraussichtliche Gesamtaufwand eine zentrale Größe. Je genauer und besser dieser abschätzbar ist, desto effektiver können im Rahmen der Steuerung von SE-Projekten Entscheidungen bzgl. Weiterführung usw. getroffen werden. Um den voraussichtlichen Gesamtaufwand des Projekts bestimmen zu können ist die Erfassung von aufgelaufenen Istkosten und des

Restaufwands erforderlich. Erst dann ist der Vergleich des voraussichtlichen Gesamtaufwands mit dem Planwert aus der Vorkalkulation möglich und das Ausmaß der Abweichung erkennbar. Während die Istkosten leicht zu bestimmen sind muss der Restaufwand sehr sorgfältig geschätzt werden. Die Schätzung des Restaufwands hat auf Basis des zuletzt erreichten Fortschrittes eines in Arbeit befindlichen Meilenstein- oder Arbeitsergebnisses zu geschehen. Es sind die erarbeiteten Istmengen und die noch zu erarbeitenden Restmengen in Nettoarbeitsstunden zu ermitteln, was einen Rückschluss auf den erreichten Sachfortschritt zulässt. Zur weiteren Verfolgung des Restaufwands und voraussichtlichem Ist, sollte der pro Phase ermittelte Restaufwand als Zusatzinformation in die Kalkulation mit aufgenommen werden (Riedel J. E.; 1990, S. 112f).

Um den Gesamtüberblick über das Projekt zu gewährleisten sind wichtige Eckdaten wie die pro Teileinheit angefallenen Personaleinsatzkosten oder Fremdleistungen auszuweisen und als Summe für das Gesamtprojekt darzustellen. In Sinne eines Management-Reporting ist die Berichterstattung so aufzubauen, dass die spezifischen Informationen über den Istzustand von (Riedel J. E.; 1990, S. 116):

- Personalaufwand,
- Kosten,
- Terminen,
- Mitarbeitereinsatz, · Sachfortschritt und · Qualität

geliefert werden.

Zur Ursachen und Verantwortungsklärung sowie zur Verbesserung zukünftiger Projektabwicklungen sollte das abgeschlossene Projekt einer letzten Prüfung unterzogen werden. Kostenmäßig geschieht das in Form der Nachkalkulation. Hierzu können die selben Instrumente der Mitkalkulation wie Abweichungsanalyse, Trendanalyse und Kennzahlenbildung benutzt werden. Für die Nachkalkulation müssen alle aufgelaufenen Istdaten vorliegen. Es gibt verschiedene Varianten der Nachkalkulation (Riedel J. E.; 1990, S. 119):

- Vergleich der ersten Vorkalkulation mit der aktuellen Nachkalkulation,
- Vergleich der letzten Vorkalkulation mit der aktuellen Nachkalkulation und
- Ermittlung von Messzahlen aus den letzten Istdaten um Kennzahlen zu kreieren oder zu verbessern.

Eine wichtige Aufgabe im Anschluss an die Nachkalkulation ist der Aufbau einer Erfahrungsdatenbank mit Daten aus der Nachkalkulation. Abschließend sollte ein

Abbildung in dieser Leseprobe nicht enthalten

Abb. 4.26 Projektkalkulationskreislauf (Riedel J. E.; 1990, S. 121)

Zum besseren Verständnis des Kalkulationssystems ist der Vorgang der Projektkalkulation inkl. ihrer Aufgaben im obigen Schaubild innerhalb des Gesamtcontrollingprozesses dargestellt.

p>4.3.1.4 Die Projektsteuerung

Eine eminent wichtige Aufgabe innerhalb des Projektcontrollings fällt der Projektsteuerung zu. Grundlage einer effizienten Projektsteuerung ist, generell wie auch für das gesamte Kalkulationssystem besprochen, eine einheitliche Prozessorganisation und fundierte Strukturplanung (vgl. Abschnitt 4.3.1.2). Durch die so geschaffene Transparenz wird die Bemessungs- und Vergleichsbasis zur Überwachung der Istwerte hergestellt. Mit den Planwerten aus der Vorkalkulation wird die Basis der Projektüberwachungsaufgabe festgelegt.

Zentrale Methode der Projektsteuerung ist der Plan-/Ist-Vergleich, der wegen seines Umfangs meist für Kosten und Durchlaufzeiten getrennt durchgeführt wird (Riedel J. E.; 1990, S. 130ff). Um den tatsächlichen Projektstand beurteilen zu können, ist zunächst der Entwicklungsstand der einzelnen Komponenten pro Phase und Meilenstein zu prüfen und daraus die Schlussfolgerung für das Gesamtprojekt zu ziehen. Wichtig in diesem Zusammenhang, ist die Feststellung des Projektfortschritts anhand der bereits geleisteten Arbeiund der erwarteten Arbeitsergebnisse. Hierzu bestehen drei Möglichkeiten (Riedel J. E.; 1990, S. 131):

- der Vergleich der geplanten Leistungsmengen mit den bisher erarbeiteten Leistungsmengen, · die Ermittlung des Restaufwands aller noch nicht erledigten Arbeitspakete für eine Phase oder Meilenstein oder
- die einfache Zählung und Volumenbetrachtung der noch offenen im Verhältnis zu den erledigten Arbeitspaketen im Netzplan.

Nur der stetige Plan-/Ist-Vergleich für Kosten, Arbeitsergebnisse und Termine liefert Erkenntnisse zur Projektsteuerung. In Abbildung 4.27 sind mögliche Vergleichskomponenten der Projektüberwachung aufgeführt.

Abb. 4.27 Vergleichskomponenten der Projektüberwachung (Riedel J. E.; 1990, S. 132)

Abbildung in dieser Leseprobe nicht enthalten

Die Vergleichsrechnungen haben periodisch und in möglichst kurzen Abständen (mindestens quartalsweise) zu erfolgen, damit entstehende Abweichungen frühzeitig erkannt werden können. Nach der Analyse der wichtigsten Plan/Ist-Abweichungen können unter Einbeziehung von Erfahrungsdaten Vorschläge zu Steuerungsmaßnahmen gemacht werden. Zur Unterstützung der kostenorientierten Projektsteuerung dienen vorrangig zwei Instrumente (Wulffen H. A.;1987, Managementzeitschrift Nr. 11):

a) die Mitkalkulation mit phasenweisem Plan-/Ist-Vergleich, Grenzwerthinweisen und
b) die gemeinsame Überwachung von Kosten und Arbeitsergebnissen im Zeitverlauf.

Zu a):

Hier werden die Plandaten aus der Vorkalkulation mit den aufgelaufenen Istdaten in der Mitkalkulation verglichen (pro Phase, pro Teileinheit usw.). Durch Angabe von Grenzwerten bezüglich der Istdaten (z. B. 75% der Istkosten) wird eine Restaufwandschätzung initiiert um den voraussichtlichen Gesamtaufwand und die somit prognostizierte Plan/Ist-Abweichung zu ermitteln. Im Anschluss daran sind auf Grundlage der ermittelten Abweichung Steuerungsmaßnahmen zu diskutieren und eventuell zu ergreifen.

Zu b):

Da zwischen Kosten und Durchlaufzeiten starke Abhängigkeiten bestehen, gibt erst eine kombinierte Darstellung von Kosten- und Termininformationen unter Einbeziehung der erreichten Arbeitsergebnisse den vollen Überblick über den Fortschritt des Entwicklungsstands.

Die eigentliche Projektsteuerung enthält Lenkungsmaßnahmen wie Kapazitätserweiterungen, Terminverlagerungen aber auch Abbruch eines Projekts bei zu großen Abweichungen (Raffel, A.; 1988, S. 135). Die Steuerung obliegt dem Projektleiter und dem Management unter Beteiligung des Controllers.

4.3.1.4.1 Qualitätssteuerung und Optimierung der Qualitätskosten

Aufgrund der Wichtigkeit der qualitativen Entwicklung eines Projekts, wird die Qualitätssteuerung im Rahmen der Mitkalkulation separat behandelt. Der Begriff Qualität ist in der DIN 55350 wie folgt definiert (DIN-Taschenbuch, 1981, S. 200): Qualität ist die Gesamtheit der Eigenschaften und Merkmalswerte eines materiellen oder Immateriellen Gegenstandes bezüglich ihrer Eignung, festgelegte und vorausgesetzte Erfordernisse zu erfüllen."

Bei der Definition des Qualitätsbegriffs ist dabei zwischen Käufer- und Entwicklersicht zu unterscheiden. Während der Käufer das Produkt über die Qualität charakterisiert und damit die Erfüllung von Produktanforderungen verbindet, steht aus Entwicklersicht neben der Erfüllung von Kundenforderungen, vor allem der effiziente und wirtschaftliche Entwicklungsprozess im Blickpunkt.

Da die Produktqualität entscheidenden Anteil an einer positiven Anbieter-/Kundenbeziehung hat und daher auch den Erfolg eines Unternehmens determinieren kann, ist für eine Transparenz der Qualitätskosten zu sorgen. Der Bundesverband der Deutschen Industrie definiert Qualitätskosten so:

"Qualitätskosten sind Ausdruck für die Aufwendungen, die erforderlich sind, um Qualität in allen Phasen von Produktentstehung und Produkteinsatz zu sichern. Sie dienen als Entscheidungshilfen mit dem Ziel der Optimierung zwischen Fehlerverhütungs- und Prüfkosten einerseits und Fehlerkosten andererseits."

Für die Optimierung der Qualitätskosten werden diese in drei Kostengruppen plan- und erfassbar gemacht. Es werden:

- Fehlerverhütungskosten (Kosten für fehlerverhütende und vorbeugende Maßnahmen), · Prüfkosten (Kosten für Prüfungen und Beurteilungen der Produktbestandteile) und · Fehlerkosten (Fehlerbeseitigungskosten) unterschieden (Wüstenberg, D.; 1988, S. 136f).

Die genannten Kostengruppen haben aus wirtschaftlicher Sicht in einem angemessenen Verhältnis zu den Selbstkosten des Produkts zu stehen (Riedel J. E.; 1990, S. 142). Antworten auf die Frage, in welcher Höhe Qualitätskosten für die Erbringung der Qualitätsaufgaben der Entwicklung, der Produktion und Wartung angemessen sind, erhält das Unternehmen aus den Erfahrungswerten eines Qualitätsregelkreises (Abschnitt 4.3.1.4.3, Abb. 4.28).

4.3.1.4.2 Steuerung der Qualitätssicherung

Das Management hat dafür zu sorgen, dass in einem Qualitätssicherungs-Leitfaden (Abb. 4.28) Grundsätze zur Qualitätssicherung, Maßnahmen und organisatorische Regelungen zur Erzielung von Produktqualität zusammengefasst werden.

Abb. 4.28 Qualitätssicherungs-Leitfaden (Riedel J. E.; 1990, S. 144)

Abbildung in dieser Leseprobe nicht enthalten

Da bei komplexer Software eine produktbezogene Qualitätsabnahme für den vollen Funktionsumfang am Ende der Entwicklung nicht möglich ist (Riedel J. E.; 1990, S. 146), werden an Stelle der Produktprüfung die Entstehungsprozesse, Arbeitsabläufe usw. auf Ordnungsmäßigkeit, Systematik, Umfang usw. untersucht. Ziel ist es, alle Aktivitäten und Maßnahmen zur Qualitätssicherung in den Entwicklungsprozessplan zu integrieren und dazu die vorhandenen Hilfsmittel zur Prozesssteuerung entsprechend zu ergänzen und aufeinander abzustimmen. Bei dem bereits im Vorfeld erwähnten Entwicklungsprozessplan, ist durch das Phasenkonzept bzw. die Tätigkeitsorganisation (Kap. 4.3.1.2) bereits eine Integration der Qualitätstätigkeiten erfolgt (Testen, Überarbeiten, Testplanen usw.). Eine immer häufiger anzutreffende Vorgehensweise, die auf die oben genannten Ziele abstellt, ist die Einführung eines Qualitätsmanagements mit anschließender Zertifizierung nach ISO 9000f. Durch die Zertifizierung wird erreicht, dass ein effektives Qualitätsmanagement betrieben wird, das unter anderem dem beschriebenen Vorgehen nahe kommt und ein solches gewährleistet. Abbildung 4.29 unten, gibt einen kleinen Überblick über wesentliche Aspekte eines Qualitätssicherungskonzepts (nicht nach Norm), das für die Steuerung der Qualitätssicherung notwendig ist.

Abb. 4.29 Qualitätssicherungskonzept (Riedel, J. E.; 1990, S. 147)

Abbildung in dieser Leseprobe nicht enthalten

4.3.1.4.3 Optimierung der Qualitätssicherungskosten

Durch Qualitätstätigkeitsarten wie Inspizieren (Review), Testen und Überarbeiten (siehe Abschnitt 4.3.1.2) werden die Qualitätskosten determiniert. Um die Qualitätskosten nach Kostenschwerpunkten (siehe Vorseite) errechnen zu können, ist eine Zuordnung der im Entwicklungsprozessplan vorgesehenen Qualitätstätigkeiten zu den Kosten festzulegen. Die Zusammenhänge sind in Abbildung 4.30 dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 4.30 Transparenz der Qualitätskosten (Riedel, J. E.; 1990, S. 150)

Die Qualitätskosten sind pro Tätigkeitsart zu kontieren und um den Gemeinkostenzuschlagssatz zu erhöhen. Bei durchschnittlichem Qualitätskostenniveau ist ein spezieller Gemeinkostenzuschlag für qualitätsbezogene Gemeinkosten nicht notwendig (Riedel J. E.; 1990, S. 150). Mit Hilfe der auf Vollkostenbasis geplanten und kontierten Qualitätsaufgaben kann aufgezeigt werden, wie stark die diversen Qualitätsmaßnahmen an den Gesamtkosten beteiligt sind. Wie für alle übrigen durch die Abweichungsanalyse erfassten Kosten, können auch für diese Kostengruppen Plan-/Ist-Abweichungen erkannt werden. Eine Beeinflussung der Qualitätskosten während des Entwicklungsprozesses ist daher im Rahmen der Projektsteuerung möglich. Optimierung von Qualitätskosten heißt demnach Minimierung dieser, vor allem der Prüfungs- und Fehlerbehebungskosten.

Abb. 4.31 Qualitätsregelkreis (Riedel J. E.; 1990, S. 152)

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.31 zeigt ein Modell eines Qualitätsregelkreises für Qualitätskosten, das die

Qualitätsaufgaben der Softwareentwicklung von den Qualitätsaufgaben im Softwareeinsatz trennt. Die angegebenen Prozentzahlen sind Anhaltspunkte für eine optimale Verteilung auf die Qualitätskostengruppen (Riedel J. E.; 1990, S. 152).

4.3.1.4.4 Qualitätskostensteuerung

Bei der Qualitätskostensteuerung geht es primär darum zu erkennen, was der zusätzliche Kosteneinsatz bei einer Qualitätskostengruppe (z. B. Prüfkosten) an Kostenreduzierung bei einer anderen Gruppe (z. B. Fehlerkosten) bewirkt (Riedel J. E.; 1990, S. 153). Jedem Unternehmen sei empfohlen die optimale Zusammensetzung der Qualitätskosten und deren Abhängigkeiten mit Hilfe eigener Erfahrungswerte nachzuvollziehen und festzulegen. So können für jedes Ausmaß gewünschter Produktqualität Anhaltspunkte für die Qualitätskostenrelationen gegeben werden, was die Planung voraussichtlicher Fehlerkostenanteile unterstützt.

Allgemein gilt: Eine Erhöhung der Fehlerverhütungskosten trägt zur Reduktion der Prüf- und

Fehlerbehebungskosten bei (Riedel J. E.; 1990, S. 154). Bei all diesen Überlegungen darf, wie generell für das ganze Controlling gültig, der Aufwand nie den Nutzen übersteigen. Gerade im Softwarebereich nimmt die Wahrscheinlichkeit, einen Fehler zu entdecken, mit der Zahl der Restfehler stark ab, während die Kosten für die Fehlersuche überproportional ansteigen (Winkler, H.; 3/88). Der Fokus muss hier auf der Beseitigung bedeutsamer Fehler liegen. Für eine effektive Qualitätskostensteuerung ist die Messung der Fehlerhäufigkeit und das Erfassen der Qualitätskosten je Tätigkeitsart Voraussetzung. Für die Beurteilung der Korrektheit von Software kann beispielsweise die Fehlerdichte pro NLOC herangezogen werden. Über verschiedene Mess- und Kennzahlen kann dann die Korrektheit einer Software oder - teileinheit errechnet werden. Ebenso sind Fehlerhäufigkeit bei der Qualitätsplanung, im Produkteinsatz, Prüffehler- und Entwicklungsfehlerhäufigkeit differenziert, im Sinne der Qualitätskostenstruktur, zu betrachten. So aufgezeichnete Erfahrungswerte können Kennzahlen werden die, die Grundlage für Zielvereinbarungen einer Qualitätsregelung bilden. Das Verhältnis entdeckte Fehler zu Qualitätskosten, gibt einen Hinweis darauf, wie hoch die Qualitätskosten für eine bestimmte Fehlerrate in der Software sein müssen (Riedel J. E.; 1990, S. 154ff).

4.3.1.4.5 Beitrag der Kostenrechnung zur Qualitätssteuerung

Die Kostenrechnung hat das Instrument zur Steuerung der Qualitätskosten bereitzustellen. Zur Unterstützung der Entwicklungsteams ist eine Datenselektion hinsichtlich Qualitätskosten und Qualitätssicherungstätigkeiten in Verbindung mit einem für die Qualitätsregelung übersichtlichen Kostenaufriss (Abb. 4.32) durchzuführen.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 4.32 Qualitätskostenauswertung (Riedel J. E.;1990, S. 156)

Die Auswertung kann sowohl mit Plandaten aus der Vorkalkulation als auch mit Istdaten aus der Mit-/Nachkalkulation erfolgen. Wie oben ersichtlich, sollte der Kostenaufriss der Qualitätskosten phasenbezogen, qualitätskostengruppenspezifisch und die einzelnen Tätigkeitsarten berücksichtigend sein. Zur Verfolgung der Qualitätskosten und zur Beobachtung von ordnungsgemäßer Erfüllung der Qualitätsaufgaben können verschiedene Kostenvergleiche herangezogen werden:

- bisherige Istkosten/bisherige Istkosten für die Qualitätssicherung und
- Plan-/Istkosten der Qualitätssicherung in der Summe, nach Qualitätskosten-Gruppen, - tätigkeitsarten oder Phasen.

Der Projektcontroller und/oder der Qualitätsbeauftragte erhält durch diese Vergleiche ganz konkrete Hinweise auf Fehlsteuerungen der Qualitätsaufgaben.

Mit der Bildung von Qualitätskosten-Mess- und Kennzahlen aus den Daten der Abbildung

4.32 können Kostenrelationen ermittelt werden, die Beurteilungen über das Verhalten der

Qualitätskosten im Detail erlauben und somit zu Steuerungsmaßnahmen anregen. Im Rahmen der Projektplanung können Vergleiche, der in der Vorkalkulation ermittelten Qualitätskosten- Messzahlen mit Qualitätskosten-Kennzahlen früherer und ähnlicher Projekte Anhaltspunkte für unübliche Kostenrelationen liefern und so Planungsunsicherheiten vermeiden helfen. Die Steuerung der Qualitätskosten während der Softwareentwicklung kann durch vergleichen der Qualitätskosten-Messzahlen aus der Vorkalkulation mit denen der Mitkalkulation unterstützt werden. Nach Entwicklungsabschluss sollten die in der Nachkalkulation erfassten Istdaten zur Erfahrungsdatensammlung und Verbesserung von Qualitätskosten-Kennzahlen benutzt werden.

4.3.1.5 Abschlussanalyse und Erfahrungsdatensammlung

Die Ergebnisse der Abschlussanalyse können hinsichtlich der Planungsunterstützung

zukünftiger Projekte hilfreich sein. Vor allem der Lerneffekt, der sich aus der Erklärung von Abweichungen ergibt ist hierbei wichtig. Der prinzipielle Ablauf einer Abschlussanalyse und der dazu notwendige Informationsbedarf ist in Abbildung 4.33 auf der nächsten Seite verdeutlicht.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 4.33 Prinzipablauf der Abschlussanalyse (Riedel J. E.; 1990, S. 166)

Bei der Vergleichsanalyse von einem oder mehrerer Meilensteine sollten die Daten des Istabschluss nicht nur mit dem letztgültigen, sondern auch mit dem ersten Planstand verglichen werden (Riedel J. E.; 1990, S. 165). Grundlage der Abschlussanalyse bilden die Daten der Nachkalkulation (Abschnitt 4.3.14). Durch die aktuelle Ermittlung des Einstufungsmix (LEE) und dem Vergleich von aktuellen und aus früheren Projekten generierten Kennzahlen, können die errechneten Plan/Ist-Abweichungen erklärt werden. In die Erfahrungsdatensammlung sind alsdann neue bzw. überarbeitete Kennzahlen und Abweichungsursachen aufzunehmen. Kennzahlen entstehen durch Verdichtung von Messzahlen einzelner Teileinheiten einer vergleichbaren Produktkategorie. Zudem bieten sich strukturgleiche und individuelle Daten als Erfahrungsdaten an. Strukturgleiche Daten sind Daten die direkt aus der Vor- und der Nachkalkulation entnommen werden können (Daten der ersten Planung, Istdaten nach Projektabschluss usw.), wohingegen individuelle Daten erst durch die Abschlussanalyse entstehen (Begründung für Plan/Ist-Abweichungen, Steuerungsmaßnahmen, Erfahrungen mit Tools usw.) (Riedel J. E.; 1990, S. 170f). Grundsätzlich sollte die Abschlussanalyse nur für die wesentlichen Komponenten erfolgen. Will man möglichst professionell Erfahrungsdaten sammeln und auswerten so bietet sich der Aufbau einer Erfahrungsdatenbank an. Die Erfahrungsdatenbank macht es leichter Statistiken oder Verteilungen zu erstellen und bildet eine gute Basis für die Ermittlung von Mess- und Kennzahlen. In der Praxis beliebte Auswertungen (Riedel J. E.; 1990, S. 172) sind die Phasenverteilung (Tätigkeitsumfang auf Phasen bezogen) und die Prozessstatistik (Aufwand und zugehörige Leistungsmengen den Arbeitsergebnissen zugeordnet).

4.4 Ausgewähltes Projektcontrollingkonzept

Vergleicht man beide bisher beschriebene Konzepte, so stehen diese nicht in unmittelbarer Konkurrenz zueinander. Das Konzept von Lachnit hat den Anspruch bis auf die Projektegesamtheitsebene (PROCON) bzw. in Verbindung mit dem Model ERFI bis "hoch" zur Gesamtunternehmensebene für Controllingzwecke tauglich zu sein. Lachnit ist mehr darum bemüht die Gesamtzusammenhänge und Abhängigkeiten der diversen Controllingebenen aufzuzeigen. Sein Fokus liegt ganz klar auf der Zusammenführung der unterschiedlichen Projektebenen zum Controllingsystem zur Unterstützung der Gesamtunternehmensführung. Das Ziel ist nicht das Implementieren eines Einzelprojektcontrollingsystems, sondern auf die für den Zweck des

Projektegesamtheitscontrollings notwendige Koordinationsmaßnahmen hinzuweisen. Lachnit betrachtet neben der Kostenseite auch die Erlösseite eines Projekts um die finanzielle Situation der Unternehmung immer im Auge zu behalten.

Riedel beschreibt auf einer wesentlich detaillierteren Ebene eine Einzelprojektcontrollingkonzeption ohne auf Aspekte der Projektegesamtheit oder der Gesamtunternehmung hinzuweisen. Riedels Konzeption des kostenorientierten Projektcontrollings hat als Aufgabenschwerpunkt die Projektkalkulation der Projektkosten. Eine Finanzrechnung fehlt bei Riedel.

Die geschilderten Konzepte könnten sich unter Idealbedingungen ergänzen bzw. aufeinander aufbauen. Ausgehend von der Konzeption von Riedel kann das Konzept von Lachnit als Endziel des Projektcontrollings angesehen werden.

Bei der Markant SE und Dienstleistungs GmbH existiert bislang weder ein Controllingsystem noch ein Controller. Vergleicht man die Anforderungen der Markant SE und Dienstleistungs GmbH (Abschnitt 4.5) mit dem Projektcontrollingkonzept von Riedel, so werden alle wesentlichen Forderungen erfüllt. Aus diesem Grund wird das Konzept von Riedel ausgewählt.

4.5 Anforderungen der Markant GmbH an das Controllingkonzept

Die Markant SE und Dienstleistungs GmbH steht erst am Anfang der Implementierung eines SE-Projektmanagements und legt bei der einzuführenden Projektcontrollingkonzeption vorrangig Wert auf die Absicherung der wirtschaftlichen Komponente des Managements. Es haben die Projektplanung, Projektüberwachung und Projektsteuerung höchste Priorität. Daher soll ein Controllingkonzept entwickelt werden, das hauptsächlich zur Unterstützung der prozessorientierten Funktionen des SE-Projektmanagements beiträgt. Der Geschäftsleitung geht es ausschließlich um die Einzelprojektebene und dabei zu aller erst um die Projektüberwachung. Das Controllingsystem soll edv-technisch umsetzbar und durchführbar sein. Da bisher keine Tätigkeitsorganisation besteht, müssen diese und andere, als Fundament der Projektcontrollingkonzeption benötigte Strukturelemente, entwickelt werden.

4.6 Modifikationen des ausgewählten Konzepts

Das Projektcontrollingmodell von Riedel ist in sich stimmig und komplett, doch gibt es einen Hauptkritikpunkt. Die vorgeschlagenen Methoden zur Abweichungsanalyse im Rahmen der Projektsteuerung sind für Softwareentwicklungsprojekte ungeeignet. Nur der Vergleich von Plan- und Istwerten aus der Vor- bzw. Mitkalkulation reicht als Grundlage für eine Abweichungsanalyse nicht aus, da keine Rückschlüsse auf die Projektentwicklung ableitbar sind. Die isolierte Budgetanalyse liefert nur brauchbare Ergebnisse wenn gilt (Coenenberg, A. G.; 1992, S. 770):

Kosten = f1 (Output) = f2 (Zeit), also Output (Fortschritt in der Leistungserstellung) und Zeit linear abhängig sind. Nur wenn der Ist-Leistungsstand dem Plan-Leistungsstand entspricht, ist ein Mehr-/Minderverbrauch herauslesbar. Da dem in der Realität nicht so ist, soll das Sollkostenkonzept vorgestellt werden. Zunächst ein Überblick über die Kostenkategorien in Abbildung 4.34.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 4.34 Kostenkategorien (Coenenberg, A. G.; 1992, S. 771)

Die Sollkosten (SK) sind laut Abbildung 4.34 die geplanten Kosten bezogen auf den realisierten Leistungsstand. Durch die zusätzliche Berechnung von SK ist es möglich auftretende Abweichungen (Gesamtabweichung (GA)) in eine Wert- und Mengenkomponente zu unterteilen. Formal stellt sich dies wie unten ersichtlich dar (Coenenberg, A. G.; 1992, S. 770):

Abbildung in dieser Leseprobe nicht enthalten

Der erste in Klammern stehende Term stellt die Wertkomponente (Kostenvarianz), der zweite die Mengenkomponente (Leistungsvarianz) der GA dar. Die GA ist vorher um exogene Faktoren wie Preissteigerungen oder Change Order-Kosten (Kosten aufgrund von Anforderungsänderungen des Kunden an das Projekt) zu bereinigen, da diese dem Planungsverantwortlichen (meist Projektleiter) nicht angelastet werden können. Die Kostenvarianz ist ein Maßstab für die Wirtschaftlichkeit während die Leistungsvarianz die Differenz von Ist- und Planfortschritt wiedergibt. Damit die Leistungsvarianz ermittelt werden kann, muss zunächst die Messung des Projektfortschritts erfolgen. Zur Messung des Projektfortschritts wird ein Maßstab benötigt wie z. B. der Realisationsgrad des Projekts (Coenenberg, A. G.; 1992, S. 770).

Da das Sachziel (technische Ziele, Zeit und Kosten) bei der Entwicklung von Software keine einheitliche Größe darstellt, ist eine direkte Messung unmöglich. Es ist also ausgeschlossen eine Fortschrittsmessung auf Basis der Zielkriterien durchzuführen. Ebenso unpraktikabel ist eine direkte Schätzung des Realisationsgrads (RG) durch die Projektverantwortlichen, denn diese Schätzung ist meist sehr subjektiv. Ein möglicher Weg ist die Schätzung des Sachfortschritts über den Abarbeitungsgrad der Arbeitspakte (AP) oder der Meilensteine zu ermitteln (Coenenberg, A. G.; 1992, S. 771). Damit ergibt sich:

Abbildung in dieser Leseprobe nicht enthalten

Um den Realisierungsgrad zu bestimmen können diverse Regeln angewandt werden.

Z. B.:

RG = 1 bei Eröffnung des AP, d.h. voller Wert wird schon bei der Eröffnung des AP gutgeschrieben,

RG = 0,5 bei Beginn und 1 bei Beendigung des AP,

RG = 1 bei Beendigung des AP oder

Abbildung in dieser Leseprobe nicht enthalten

(3) ID = Istdauer; BD = Budgetdauer, unter der Prämisse, dass

die Leistungserstellung proportional zum Zeitverbrauch ist. Dies ist gegeben, wenn der APUmfang klein gewählt wird. Um zu verhindern, dass die Ist-Dauer (ID) größer als die budgetierte Dauer (BD) wird, ist die voraussichtliche Restdauer (RD) eingeführt worden. Diese Darstellung hat zudem den Vorteil, dass die betrachtete Zeitperspektive um eine zukunftsorientierte Komponente erweitert wird (Coenenberg, A. G.; 1992, S. 772f). Der Realisierungsgrad berechnet sich wie folgt:

(4) RG zeitdauerorientiert

Um zusätzlich die Kostenkomponente in die Restdauer zu integrieren werden Restkosten eingeführt, also Kosten, die bis zum Abschluss des AP noch anfallen. Somit wird aus dem zeitdauerorientierten RG ein kostenorientierter. Auch hier muss die Prämisse von der zeitproportionalen Kostenentstehung gelten. Um den tatsächlichen Leistungsstand zu erfassen, bedarf es nicht nur des RG sondern auch der Mithilfe der Qualitätssicherung, denn ein Projekt kann in bezug auf die Zahl der abgeschlossenen APs durchaus im Plan sein, die Qualität und damit der echte Leistungsstand trotzdem unterhalb des Plans sein.

(5) RG kostenorientiert; BK = Budgetkosten, RK = Restkosten

Da nun mit den Sollkosten zukunftsbezogene Größen (RK bzw. RG) in die Analyse mit eingehen, sind jetzt verschiedene Abweichungstypen innerhalb des Projektcontrollings offensichtlich, wie beispielsweise fehlerhafte Ist-/Planwertermittlung und Abweichungen in den Planprämissen (Coenenberg, A. G.; 1992, S. 773). Ein Auswertungsschaubild der Abweichungsanalyse mit Sollkosten kann wie Abbildung 4.35 aussehen.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 4.35 Projektkostenverlauf

Interpretation der Abweichungsanalyse von Abbildung 4.35.: Wenn die Sollkosten kleiner als die Budgetkosten sind folgt, dass der Projektfortschritt geringer als geplant ist. Diese Abweichung wird als Leistungsvarianz (LV=BK-SK) bezeichnet (Coenenberg, A. G.; 1992, S. 776), da LV nur die Mengendifferenz ausweist. Ein negativer Wert der LV weist auf einen Leistungsrückstand hin. Unterscheiden sich die Istkosten und die Sollkosten, ist dies auf die Wertkomponente (Preissteigerung usw.) zurückzuführen. Diese Abweichung nennt sich Kostenvarianz (KV=IK-SK) (Coenenberg, A. G.; 1992, S. 777). Ein positiver Wert der KV signalisiert eine Unwirtschaftlichkeit im Projektfortschritt. Die Gesamtabweichung (GA=BK- IK) stellt die aufgelaufenen Kosten zu einem bestimmten Zeitpunkt im Verhältnis zu den geplanten Kosten dar. Aus der GA sind keinerlei Rückschlüsse auf die Ursachen der Planabweichung erhältlich (Coenenberg, A. G.; 1992, S. 769). Die Kosten- und Leistungsvarianz können auch zu Kennzahlen umgewandelt werden (Coenenberg, A. G.; 1992, S. 780).

Kostenindex: [Abbildung in dieser Leseprobe nicht enthalten] (6) Leistungsindex: [Abbildung in dieser Leseprobe nicht enthalten](7)

(Ausdrücke in Prozent und auf 1 normiert)

Mit Hilfe von KV, KI, LV, LI und den entsprechenden kumulierten Werten, können im Zuge des Reporting aussagekräftige Diagramme erstellt werden, die Rückschlüsse auf die Wertwie auch Mengenentwicklung des Projekts oder der Teileinheit zulassen (Beispiel in nächster Abb.). Durch die Verwendung von Wert- und Mengenkomponenten wird eine sinnvolle Abweichungsanalyse erst möglich. Mit Hilfe der Restkosten respektive Restdauer ist zudem eine prospektive Analyse machbar. Der entscheidende Schwachpunkt dieser Vorgehensweise liegt in der Bestimmung des Realisierungsgrads, da aufgrund der individuellen Einschätzung seitens der Mitarbeiter immer subjektive Faktoren enthalten sind.

Abb. 4.36 Leistungs- und Kostenvarianzverläufe

Abbildung in dieser Leseprobe nicht enthalten

Durch die grafische Darstellung der Leistungs- und Kostenvarianz entsteht ein guter Überblick über die Projektentwicklung. Eine negative LV weist auf eine zeitliche Verzögerung hin. Genauso deutet eine positive KV an, dass der Projektfortschritt teurer als geplant ist.

Beide Größen sind zudem in der Summe dargestellt, was zur Beurteilung der Gesamtabweichung dienen kann. Werden die beiden Indizes KI und LI in einer Managementgrafik dargestellt, so haben die Projektverantwortlichen die gesamte Projektentwicklung in nur einer Grafik plastisch vor Augen (Abb. 4.47).

Abb. 4. projektentwicklung

Mit der Darstellung des Kosten- und Leistungsindex erhält das Management einen guten Überblick über die Gesamtprojektentwicklung in Bezug zu den geplanten Projektkosten. Der Kostenindex zeigt dabei die wirtschaftliche Entwicklung auf, was heißt, dass bei einem KI>100% Unwirtschaftlichkeit bzgl. der Realisation vorliegt. Der Leistungsindex ermöglicht die Beurteilung des zeitlichen Projektfortschritts. Ein LI<100% bedeutet Verzug in der Projektentwicklung. Mittels kumulierter Werte werden die Gesamtabweichungen erfasst.

4.7 Voraussetzungen für die Einführung von SE-Projektcontrolling

4.7.1 Anforderungen an die Organisationsstruktur der Unternehmung

Ein Unternehmen, das sich zur Einführung eines Projektcontrollingsystems entscheidet muss mehrere Bedingungen erfüllen:

- Es sollte eine die Projektleistungstätigkeit unterstützende Aufbauorganisation der Gesamtunternehmung vorliegen. Hierzu bietet sich die Matrixorganisation an, da sie die flexibelste Organisation in bezug auf die Ressourcenverteilung darstellt.
- Neben der Aufbauorganisation sollte eine möglichst einheitliche Ablauforganisation eingeführt sein. Der Idealfall wäre eine einzige, für alle Abteilungen gültige Prozessorganisation, an der sich der Softwareentwicklungsprozess ausrichtet.
- Weiterhin sollte ein Projektmanagementsystem vorhanden sein, das vor allem die grundlegenden projektorganisatorischen (allg. Grundsätze der Projektentwicklung, Projektorganisationsform, Verantwortlichkeiten, Kommunikationsverhalten usw.) und projekttechnische Aspekte zum Inhalt hat. So müssen alle Projektstrukturpläne von denen ausgehend das Projektcontrollingmodell seine Struktur erhält vorliegen. Ein unstrukturiertes und zur Entwicklungsprozessstruktur nicht in Beziehung stehendes Controllingkonzept ist schon im Vorfeld zum Scheitern verurteilt.
- Die Einführung eines Projektcontrollingmodells sollte von höchster Stelle (Top- Management) unterstützt und forciert werden. Unter Einbeziehung aller Beteiligter bzw. Betroffener ist von Anfang an eine breite Verständnisbasis für das zu implementierende Projektcontrollingkonzept zu schaffen. Daher ist die Unterstützung gerade durch Vorgesetzte zur Einführung des Controllings unerlässlich. Das beste Konzept scheitert, wenn es aufgrund mangelnder Unterstützung unzureichend umgesetzt wird.

4.7.2 Unterstützung des Projektcontrollingsystems durch das Rechnungswesen

Das Rechnungswesen, speziell die Finanzbuchhaltung hat für die informatorische Absicherung des Projektcontrollings zu sorgen. Soweit die in der Finanzbuchhaltung erfassten Daten für externe Zwecke (Handelsabschluss usw.) für die Durchführung von Controllingaufgaben zweckmäßig sind, sind diese bereitzustellen. Dies betrifft vor allem kostenstellenspezifische Daten der Aufwandskomponente (Personal, Abschreibungen, Material usw.) des Betriebsergebnisses der Gewinn- und Verlustrechnung. Neben den genannten Daten werden im Zuge des Projektcontrollings hauptsächlich projektindividuelle Daten benötigt (siehe Abschnitt 4.4). Damit diese Daten geliefert werden können, ist die Datenerfassung dahingehend zu erweitern, dass eine projekt- bzw. teileinheitsspezifische Erfassung von Projektdaten gewährleistet ist. Dabei ist darauf zu achten, dass Daten (z. B. Miete und Abschreibungen), die bereits gesamtunternehmens- oder kostenstellenspezifisch erfasst sind, nicht doppelt, sondern mit speziellen Buchungsvermerken versehen einmalig erhoben und je nach Verwendungszweck mehrmalig kontiert werden. Ebenso sollten die neu und projektspezifisch zu erhebenden Daten pro Tätigkeitsart und Phase vom Rechnungswesen für die Zwecke des Projektcontrollings und parallel für die Zwecke der Handelsbilanz aufbereitet werden, ohne dass eine Mehrfacherhebung notwendig wird. Neben der Erhebung und Erfassung neuer Daten für die Zwecke des Projektcontrollings, stellt die Kreation neuer Kostenkategorien (z. B. SK, RK), interner Kostenverrechnungssätze usw. eine weitere Aufgabe des Rechnungswesens dar. Das Rechnungswesen ist zudem für die Strukturierung der Datenbasis verantwortlich. So ist die Datenbasis des Unternehmens in einen Einzelprojekt-, Projektegesamtheits-, Funktional- und Gesamtunternehmensbereich zu gliedern. Innerhalb dieser Bereiche sind wiederum individuelle Auswertungsrechnungen und Datenaggregationen zu bewerkstelligen.

5 Organisationsanalyse der Markant SE und Dienstleistungs GmbH

Kapitel fünf dient zur Darstellung des Istzustands der Organisationsstruktur (5.2), des Projektmanagements (5.3), des Rechnungswesens (5.4) und des Controllings (5.5) bei der Markant SE und Dienstleistungs GmbH.

5.1 Allgemeines zur Markant SE und Dienstleistungs GmbH

Die Markant SE und Dienstleistungs GmbH hat zur Zeit ca. 80 Mitarbeiter bei einem Umsatz von rund 7 Mio. DM in 1998. Gegründet 1995, ist die GmbH das Standbein der Markant- Südwest Handels AG auf dem Markt der Informationstechnologie und konzernweit für die EDV zuständig. Die Tätigkeiten der Markant SE und Dienstleistungs GmbH konzentrieren sich auf die Projektierung individueller Komplettlösungen für den food-orientierten Handelsbereich (Warenwirtschaftssystem, Managementinformationssystem, E-Commerce, Netzwerke, Dienstleistungen usw.). Die Markant SE und Dienstleistungs GmbH hat zwei Standorte mit dem Hauptsitz in Siegelbach.

5.2 Analyse der Organisationsstruktur

5.2.1 Istzustand Aufbauorganisation der Gesamtunternehmung

Die Unternehmung ist momentan funktional in 10 Abteilungen plus der Geschäftsführung

gegliedert, die auch gleichzeitig Kostenstellen sind. Für 2000 ist eine Umstrukturierung geplant, die mit einer Erhöhung der Abteilungszahl einhergehen wird. Wegen des großen Umfangs von Projektarbeit, die über 2/3 der Gesamttätigkeit ausmacht, besteht die Aufbaustruktur aus einer funktional als auch objektorientierten Struktur, der sogenannten Matrixstruktur (siehe Abb. 5.1), die als einzige Aufbauorganisationsform sowohl funktionale als auch objektorientierte Aspekte der Strukturierung vereinigt.

C&C=Cash and Carry (Lebensmittelgroßmärktebetreuung), DEWAS=EDVWartung der Lebensmittelfilialen

Abb. 5.1 Aufbauorganisation der Markant SE und Dienstleistungs GmbH

Abbildung in dieser Leseprobe nicht enthalten

Die Aufbaustruktur der Markant SE und Dienstleistungs GmbH zeichnet sich dadurch aus, dass sowohl ein Projekt Warenwirtschaftssystem 2000 (WWS 2000) als auch eine Abteilung WWS 2000 existiert. Dies wurde gemacht, um die Kerntätigkeit und den Aufgabenschwerpunkt der GmbH hervorzuheben, wobei auch WWS 2000-fremde Aufgaben von dieser Abteilung wahrgenommen werden. Mehr als 1/3 der Belegschaft ist mit dem WWS 2000 Projekt dauerhaft beschäftigt, das in erster Linie im Auftrag der Markant AG erfolgt. Was die Abteilungen betrifft, soll angemerkt werden, dass die Abteilung EDV-Operating, zuständig für EDV-technische Fragen der Markant Südwest Zentrale in Pirmasens auch dort lokalisiert ist und eigentlich keine Abteilung der Matrixorganisation der GmbH ist. Als einzige der Abteilungen zergliedert sich die Abteilung WWS 2000 in vier Unterabteilungen, sogenannten Gruppen, denen jeweils ein(e) Gruppenleiter(in) vorsteht. Es sind dies die Gruppen Analyse, Design, Implementierung und Qualitätssicherung. In der Abteilung WWS 2000 ergibt sich daher eine Übereinstimmung von Abteilungsstruktur und Phasenstruktur, wie in Abschnitt 5.2.2 nachzulesen ist. Was die Projektorganisation an sich angeht, so treten keine Fälle der reinen oder Einflussprojektorganisation auf. Eine Tätigkeitsorganisation, wie in Kapitel vier beschrieben fehlt bei der Markant SE und Dienstleistungs GmbH völlig.

5.2.2 Aktuelle Ablauforganisation

Der Softwareentwicklungsprozess vollzieht sich in einem iterativen Kreislauf von vier Phasen. In Abbildung 5.2 ist dieses Phasenmodell dargestellt.

Abb. 5.2 Phasenmodell der Ablauforganisation

Abbildung in dieser Leseprobe nicht enthalten

Dieses Phasenmodell ist ein Kreislaufmodell, in dem nicht nur Rücksprünge in die vorhergehende Phase möglich sind, sondern in alle anderen Phasen des Prozesses (aus Abb. nicht zu erkennen). Die Rücksprünge über mehr als eine Phase treten jedoch weniger häufig auf als die Rücksprünge, die in Abbildung 5.2 durch die hellgrauen Pfeile markiert sind. In der Analysephase, die gleichzeitig die Schnittstelle des Softwareentwicklungsprozesses zum Kunden ist, werden die Kundenanforderungen untersucht, festgestellt und einerseits für den Kunden, andererseits für die betroffenen Projektteammitglieder verständlich gemacht. Parallel werden dabei auch Testfälle geplant um die Umsetzung der Kundenanforderungen im Produkt zu überprüfen. Zum besseren Verständnis ist zu sagen, dass die Markant SE und Dienstleistungs GmbH nicht nur auf extern geäußerte Anforderungen hin einen Lösungsvorschlag unterbreitet, sondern bei der Generierung oder Findung der Anforderungen aktiv beteiligt ist. Der ermittelte bzw. Sollworkflow wird mit dem Dokumentationstool ARIS beschrieben und bildet das Hautarbeitsergebnis (Meilenstein) der Analysenphase. Aufbauend auf diesem Arbeitsergebnis werden in der Phase Design das GUI (grafic user interface), Klassendiagramme und das Objektmodell erstellt. In der Phase der Implementierung wird, unter Verwendung der in der Phase Design erbrachten Vorarbeiten, programmiert und Programmfragmente zu Funktionen bzw. Modulen zusammengefasst. In der Qualitätssicherung, als formal letzter Phase werden Tests, die in der Analysephase erarbeitet wurden neben neu hinzugekommenen durchgeführt. Es werden Funktions-, Modul, Verbund- und Systemtests gemacht, die aber nicht nur während der Phase der Qualitätssicherung, sondern bei Bedarf schon früher geschehen. Die Markant SE und Dienstleistungs GmbH verfolgt bei der Qualitätssicherung die vier Augen-Strategie, was bedeutet, dass bereits in vorgelagerten Phasen Qualitätssicherungsmaßnahmen ergriffen werden (,,QS-Mitarbeiter schaut anderen über die Schulter"). Ein Rollback findet statt, wenn Arbeitsergebnisse einer vorausgehenden Phase als Grundlage für eine Weiterarbeit nicht ausreichen. Dies bedeutet, dass jedes Arbeitsergebnis, das für nachfolgende Phasen relevant ist überprüft werden muss, was bei der Übereinstimmung von Phasen- und Aufbaustruktur in der Abteilung WWS 2000 zu Mehrarbeit führt, da es kaum phasenübergreifend tätige Mitarbeiter gibt.

5.3 Entwicklungsstand des Projektmanagement

Die Markant SE und Dienstleistungs GmbH hat im Sommer 99 das System des zielgerichteten Projektmanagements (ZGPM) nach E.S. Andersen, K. V. Grude und T. Haug eingeführt. Das System des ZGPM enthält die in Abbildung 5.3 aufgeführten Bestandteile (Formulare) zur Lösung der Projektmanagementaufgaben (Andersen, E. S.; 1984, S. 17-21).

Abb. 5.3 Überblick über ZGPM (Andersen, E. S.; 1984, S. 18)

Abbildung in dieser Leseprobe nicht enthalten

Das Interesse dieser Form des Projektmanagements gilt den sogenannten PSO-Projekten. PSO-Projekte sind Projekte, bei denen die Entwicklung eines Systems (z. B. ein Produkt) und die Entwicklung von Personal und Organisation gleichzeitig erfolgen (Andersen, E. S.; 1984, S. 18). Dieses System wurde ursprünglich innerhalb der Informationsverarbeitung, hautsächlich zur Implementierung neuer Computersysteme entwickelt. Es ist ein Vorgehensmodell zur Minderung des Risikos durch die Systemgestaltung (Lösungskonzept) und der Organisation und Koordination der Problemlösung. Durch die Betonung derPSOProjekte soll neben den technischen Aspekten bei Projekten immer auch den begleitenden organisatorischen Aspekten wie Personal und der damit verbunden Verantwortlichkeiten als auch der Aufbauorganisation Rechnung getragen werden. Wie aus Abbildung 5.3 zu entnehmen ist, erfolgt das Management auf zwei Ebenen:

a) der Meilensteinebene und
b) der Aktivitätsebene.

Auf der Meilensteinebene ist die Projektaufgabe zu strukturieren und in klar abgrenzbare und messbare Meilensteine chronologisch zu ordnen. Dies ist ausgehend von der Projektebene für jede Teileinheit und/oder komplexere Aufgabe zu tun, wobei immer nach PSO- Gesichtspunkten zu verfahren ist. Auf der Aktivitätsebene sind innerhalb der Planungsteilbereiche Verantwortlichkeiten und benötigte Ressourcen zu planen (Andersen, E. S.; 1984, S. 45ff).

Zur Unterstützung der Projektmanagementaufgaben innerhalb der einzelnen Ebenen (Abb. 5.3) existieren für jede Aufgabe standardisierte Formulare, die von den jeweiligen

Projektverantwortlichen zu bearbeiten sind. Das ZGPM wird darüber hinaus durch ein Excel- Arbeitsblatt ergänzt, das die angesprochenen Formulare enthält und zur leichteren Ermittlung der Fortschritts- und Statusberichte dient. Die Aspekte zur Realisation des ZGPM sind nachfolgend skizziert, wobei die kursiv gedruckten Aspekte noch nicht oder nur unzureichend umgesetzt wurden (Andersen, E. S.; 1984, S. 79ff):

Allgemeine Vorarbeiten

Projektidentifikation: Um welche Art von Projekt handelt es sich?

Ausprägung des Projekts anhand der Dimensionen Inhalt, Dauer und Erfolgsrisiko ermitteln (Portfolio).

Grundsatzverantwortlichkeiten in bezug auf Projektkultur und Projekteffizienz einer Organisation bestimmen.

Zur Planung

Aspekte der Planung

1. Strukturierung der Aufgabe:

- Übersicht über Projekt schaffen, gemeinsames Verständnis über Projekt bilden, · Projektsegmentierung (Teilprojekte bilden),

- Zusammenhänge aufdecken, Schnittstellen definieren (PSP, Meilensteinplan), · Machbarkeitsstudie erstellen (Ziele, Problembeschreibung, Herangehensweise), Grundsatzverantwortlichkeiten für Gesamtprojekt klären.

2. Strukturierung des Projektablaufs:

- Projektstrukturplan detaillieren (Aktivitätenplan, Arbeitspakete, Vorgänge), · Verantwortlichkeiten auf globaler Ebene klären (wer ist verantwortlich, trifft Entscheidungen und wer hat was zu tun innerhalb eines Meilensteins-> Projektverantwortlichkeitsmatrix),
- Def. von Tätigkeitsfolgen und -abhängigkeiten (Aktivitätenmatrix).

3. Terminplanung:

- Projektverantwortlichkeitsmatrix, Meilensteinplan mit Fertigstellungsterminen, Aktivitätenmatrix.

4. Kapazitätsplanung:
- Welche Vorgänge brauchen welche Kapazitätsarten,
- Bestimmung des Kapazitätsbedarfs je AP bzw. Vorgangs, · Ermittlung der Gesamtkapazitätsbelastung,
- Soll- /Istvergleich der Kapazitäten,
- Kapazitätsabgleich (Verschiebung, Fremdvergabe, Erweiterung).

5. Wirtschaftlichkeitsplanung:

- Kostenplan, Erlösplan usw.

Zur Organisation

Aspekte der Organisationsaufgabe

1. Projektorganisation festlegen:

- Reine Projektorganisation, Einfluss-Projektorganisation oder MatrixProjektorganisation.

2. Allgemeine Spielregeln:

- Unterscheidung zw. projektübergreifenden Prinzipien für die Mitarbeit, den Rollen der verschiedenen Gruppen, die am Projekt mitarbeiten und der tatsächlichen Zuordnung von Aufgaben zu den Mitarbeitern.

3 . Rollenfestlegung:

- Klärung des Verhältnisses und der Verbindung zw. den beteiligten Gruppen, · Klärung der Verantwortlichkeiten (wer trifft die Entscheidungen usw.), · Grundsatz- und Projektverantwortlichkeitsmatrix erstellen.

4. Entscheidungsverantwortlichkeit:

5 . Effektive Kommunikation:

- Wer sollte wann, wen, wie informieren (Verantwortlichkeitsmatrix).

Zur Steuerung

Aspekte der Steuerung

1. Berichtswesen:

- Um vernünftig steuern zu können sind z. B. Fortschrittsberichte zwingend notwendig (einfache und übersichtliche Berichte benutzen, Berichte auf dem Plan ansiedeln) · Regelmäßige und formalisierte Berichterstattung.

2. Kontrolle:

- Beobachtungspunkte müssen bereits im Vorfeld des Projekts klar sein und · Steuerungskriterien sind vorab festzulegen (Qualität, Termin, Kosten usw.).

3. Steuerungshierarchie:

- Steuerung auf Aktivitätenebene beginnen und
- Auswirkungen auf übergeordnete Ebenen vermeiden (Meilensteinplan).

4. Steuerungsmethode:

- Abweichungsinduzierte Entscheidungsfindung von A. Raffel auf Basis der integrierten Kosten- und Leistungsrechnung.

5.4 Entwicklungsstand des Rechnungswesens

Das Rechnungswesen ist der Abteilung Verwaltung angegliedert und nimmt vor allem

Aufgaben für die externen Zwecke der Rechnungslegung war. Ein internes Rechnungswesen existiert nicht. Es werden monatlich die kurzfristige Erfolgsrechnung auf Basis des

Umsatzkostenverfahrens und die Kostenstellenrechnung durchgeführt wobei die kurzfristige Erfolgsrechnung zu Beginn eines Jahres auch als Planrechnung für das bevorstehende Geschäftsjahr dient (jedoch nicht von Verwaltung, sondern von der Geschäftsleitung durchgeführt). Außerdem wird der obligatorische Jahresabschluss durchgeführt.

5.5 Entwicklungsstand des Controllings

Die Markant SE und Dienstleistungs GmbH betreibt kein eigenständiges Controlling. Wenn Controllingaufgaben wahrgenommen werden, dann durch das Management selbst. In rudimentärem Umfang findet eine Tätigkeitskontrolle statt. Dabei werden zentral leicht zu erfassende Daten wie Arbeitszeiten, Fehlzeiten, Surfgewohnheiten usw. erfasst und mittels Softwaretools ausgewertet. In bezug auf die Surfgewohnheiten der Mitarbeiter erfolgt eine Steuerung in Form von Mahnungen an die betreffenden Arbeitsplätze und durch Zensur des Internetangebots. Für die Auswertung ist die Abteilung PC-Wartung zuständig. Sonst gibt es keinerlei Erfassung von z. B. Projektdaten usw.

6 Anpassung des ausgewählten Projektcontrollingkonzepts für die Markant SE und Dienstleistungs GmbH

Unter Berücksichtigung der unternehmensspezifischen Forderungen und Gegebenheiten wird das Controllingmodell von Riedel mitsamt der bereits in Kapitel 4 beschriebenen Modifikationen für die Markant GmbH angepasst. Die Anpassungen betreffen hauptsächlich das Phasenmodell, die Tätigkeitsorganisation und die Aufwandschätzung.

6.1 Phasenmodell für die Markant SE und Dienstleistungs GmbH

Wie schon in Kapitel 5 beschrieben, besteht ein Phasenmodell bei der Markant SE und Dienstleistungs GmbH aus vier Phasen. Das Phasenmodell von Riedel (siehe Kapitel 4) besteht aus ursprünglich sechs Phasen (Phase Integration wurde vom Autor als Vorschlag für Markant hinzugefügt) inklusive der Einsatzphase, die es bei Markant so nicht explizit gibt. Betrachtet man nur den Softwareentwicklungsprozess so besteht der größte Unterschied der Phasenmodelle bei den letzten Phasen. Das Prozessmodell von Riedel hat zwei Testphasen, Verbund- und Systemtest, anstatt der Qualitätssicherungsphase des Markantmodells mit vergleichbarem Tätigkeitsprofil. Ebenso entsprechen sich die Phasen Entwurf und Design weitestgehend. Ein Charakteristikum von Phasen sollte ein dem Umfang nach vergleichbarer Arbeitsinhalt sein und aus diesem Grund erscheint die Phase Qualitätssicherung (QS) des Prozessmodells von Markant als ,,übergewichtig". Zudem beinhaltet die QS-Phase zu viele den Projektfortschritt repräsentierende Arbeitsergebnisse (Meilensteine). Daher wird das in Abbildung 6.1, auf der nächsten Seite, gezeigte Prozessmodell der Softwareentwicklung empfohlen. Die QS-Phase wurde hier in zwei Phasen aufgeteilt. Anzumerken ist, dass es generell eine Gefahr darstellt die Qualitätssicherung als eigenständige Phase zu etablieren. Qualitätssicherungstätigkeiten sollten parallel in allen Phasen wahrgenommen werden um die Fehlerbeseitigungskosten zu minimieren (Kap. 4). Eine Phase QS zum Abschluss des Phasenmodells ist erstens chronologisch falsch platziert und suggeriert den Mitarbeitern, die in vorgelagerten Phasen tätig sind, dass Sie kaum Qualitätsverantwortung haben.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 6.1 Empfohlenes Phasenmodell

6.2 Modifikation der Tätigkeitsorganisation

Eine detailliert auszuarbeitende Tätigkeitsorganisation setzt eine Prozessanalyse der Softwareentwicklung voraus. Im Rahmen dieser Arbeit war dies nicht möglich, da zum einen eine Prozessanalyse den Umfang der Arbeit gesprengt hätte, zum anderen Fraunhofer, ein Institut für experimentelles Software Engineering, schon seit längerer Zeit mit der Prozessanalyse betraut ist und noch keine Ergebnisse abgeliefert hat. Dennoch soll mit Abbildung 6.2 eine Anregung gegeben werden, wie eine Tätigkeitsorganisation, die bis jetzt noch nicht existiert, aussehen könnte. Wie in Abbildung 6.2 zu erkennen ist, wurde die Phase Einsatz als letzte Phase dem Phasenschema hinzugefügt. Gegenüber der Tätigkeitsorganisation von Riedel haben sich mehrere kleine Änderungen ergeben (vgl. Abb. 4.15 mit 6.2). Sobald Fraunhofer seine Arbeit zu einem Abschluss gebracht hat, sollte die softwareentwicklungsspezifische Tätigkeitsorganisation umgehend erstellt werden, da diese die Grundlage der Stundenkontierung bildet. Für den projektspezifischen aber nicht softwareentwicklungsspezifischen Tätigkeitsbereich wurden folgende Tätigkeitsarten gefunden:

- Organisatorisches (Meetings besuchen, Socializing)
- Unproduktives (Krankheit, Urlaub, Weiterbildung usw.)
- Büroorganisation (Abläufe festlegen, Sauberkeit, Ordnung, Sicherheit)

Abbildung in dieser Leseprobe nicht enthalten

Nach Meinung des Autors sind diese Tätigkeitsarten nicht zwingend notwendig, da sie über die in Abbildung 6.2 genannten Positionen erfasst werden könnten. Andere nichtprojektbezogene Tätigkeiten können mit den bestehenden Mitteln der Zeiterfassung aufgenommen und auf die Projekte verteilt werden.

Abb. 6.2 Vorschlag einer Tätigkeitsorganisation

Abbildung in dieser Leseprobe nicht enthalten

Die Tätigkeitsarten sind die selben wie sie Riedel in seiner Tätigkeitsorganisation benutzt. Lediglich die pro Phase potentiell vorkommenden Tätigkeitsarten von Abbildung 6.2 unterscheiden sich von denen in Abbildung 4.15.

6.3 Weitere Anpassungen

Da das Phasenmodell und die Tätigkeitsorganisation von Riedel für die Markant SE und Dienstleistungs GmbH modifiziert wurden (siehe Abschnitt 6.1 und 6.2), sind diese Änderungen bei allen Methoden, Verfahren und verwendeten Formularen, die als Grundlage und Bezugspunkt das Phasen und Tätigkeitsmodell verwenden zu berücksichtigen. Um die Projektverantwortlichen bei Markant zu Beginn der Einführung dieses Konzepts nicht zu überfordern, kann anstatt des relativ aufwendigen Aufwandschätzverfahrens (PAKO usw.), die Aufwandschätzung vorübergehend subjektiv und intuitiv durch Projektverantwortliche geschehen.

7 Zusammenfassung

Das bislang unzureichend gelöste Problem der budget- und termingerechten Erstellung von Software (Raffel, E.; 1988, S. 162) bereitet der SE und IT Branche nach wie vor große Schwierigkeiten. Hiervon betroffen ist auch die Markant SE und Dienstleistungs GmbH, weshalb in dieser Arbeit ein Projektcontrollingkonzept zu entwickeln war. Durch den speziellen Charakter von Softwareentwicklungsprojekten (siehe Abschnitt 4.1.1) wird ein eigenständiges Controllingkonzept für diese Form der Projektleistungstätigkeit notwendig. Neben den primär technisch-organisatorischen Ansätzen zum Projektcontrolling, etwa in Gestalt von PPS- oder Projektmanagement-Systemen, soll das in dieser Arbeit ausgewählte und modifizierte Modell vornehmlich der Führung von Projekten in den wirtschaftlichen Kategorien Leistung und Kosten dienen. Um einen Überblick über die verschiedenen Herangehensweisen an die Projektcontrollingproblematik zu erhalten, wurden zwei mit unterschiedlicher Zielsetzung erstellten Konzepte ausgewählt und erläutert. Das Konzept von Riedel, welches später auch ausgewählt wurde, konzentriert sich auf Einzelprojekte in Forschung und Entwicklung. Es ist ein rein kostenorientiertes Konzept und auf die Belange der Softwareentwicklung leicht abzustimmen. Lediglich in punkto Projektsteuerung sind größere Änderungen, aufgrund spezieller Belange der Softwareentwicklung notwendig. Riedels Konzept wurde daher um das Projektsteuerungsinstrument von Coenenberg und Raffel ergänzt. Im Gegensatz zu Riedel verfolgt das zweite vorgestellte Komzept von Lachnit, das Ziel der Unterstützung von Gesamtunternehmensführungsfunktionen in Unternehmen mit Projektleistungstätigkeit. Die Organisationsanalyse der Markant SE und Dienstleistungs GmbH ergab unter anderem das Fehlen eines Controllingsystems und Controllers. Außerdem werden Controllingaufgaben vom Management kaum wahrgenommen. Diese Gründe waren mitausschlaggebend für die Entscheidung, das Konzept von Riedel dem von Lachnit vorzuziehen. Um das Projektcontrollingsystem von Riedel bei der Markant GmbH einzuführen, sind diverse Änderungen bzw. Voraussetzungen wie Implementierung einer Tätigkeitsorganisation oder umfangreichere Ist- und Schätzdatenerfassung nötig. In Kapitel 6 sind daher einige Anregungen gegeben, die als Grundlage für die Anpassungsarbeiten dienen können. Zum Schluss soll noch einmal betont werden, dass es dem Autor nicht um ein für die Zwecke der Markant GmbH detailliert ausgearbeitetes Controllingkonzept ging, als viel mehr um ein eher universelles Vorgehen bei der Einrichtung einer Projektcontrollingkonzeption in der SE und IT Branche.

8 Literaturverzeichnis

Andersen, E. S.: Goal directed Project Management, Norwegen 1984 Boehm, B. W.: Wirtschaftliche Softwareproduktion, Wiesbaden 1986 BVITeV: Informationsbroschüre, Bonn 1999

Coenenberg, A. G.: Abweichungsanalyse bei Projekten im F & E-Bereich in: Handbuch der Kostenrechnung (siehe Männel, W.)

Dele, A.: Controller Handbuch, München 1990

DIN 69901: Projektmanagement, Begriffe, in: DIN Taschenbuch 166, Informationsverarbeitung, Köln 1981

Hahn, D.: Puk-Controllingkonzepte, Wiesbaden 1990 Horváth, P.: Controlling, München 1994

Küpper, H. U.: Zum Verständnis und Selbstverständnis des Controllings in: ZfB, 1990

Lachnit, L.: Controllingkonzeption für Unternehmen mit Projektleistungstätigkeit, München 1994

Lachnit, L.; Lange, C.; Palloks, M.: Zukunftsfähiges Controlling, München 1998

Lackmann, M.: Controlling the Project Development Cycle in: Journal of Systems Management, 1997

Link, J.: Schwachpunkte der kumulativen Abweichungsanalyse in der Erfolgskontrolle in: ZfB, Jg. 87, Heft 8

Macharzina, K.: Diskontinuitätenmanagement, Berlin 1984

Madauss, B. J.: Handbuch Projektmanagement, Stuttgart 1990

Mag, W.: in: Vahlens Kompendium der BWL, Bd. 2, München 1993 Männel, W.: Handbuch der Kostenrechnung, Wiesbaden 1992

Noth, T.: Unterstützung des Managements von Softwareprojekten, Dissertation, Augsburg 1987

Platz, J; Schmelzer, H. J.: Projektmanagement in der industriellen F & E, Berlin 1986 Preißler, P. R.: Controlling, München 1994

Raffel, A.: Abweichungsinduzierte Entscheidungsfindung zur Steuerung von SoftwareEntwicklungsprojekten, Frankfurt a. M. 1988

Reichmann, T.: Entwicklungen und Trends im Controlling in: Controlling-Praxis, Erfolgsorientierte Unternehmenssteuerung, München 1988

Riedel, J. E.: Projektcontrolling in Forschung und Entwicklung, Berlin 1990 Siemens: F & E und Marketing, Wiesbaden 1987

Spieler, J.: Aktivierungsfähigkeit von selbsterstellter Standardsoftware, Dissertation, Augsburg 1986

Warnecke, H. J.: Systeme der Produktion Skript, Kaiserslautern 1996

Weis, E.: Kostenorientiertes Projektcontrolling in: Kostenrechnungspraxis, 41 Jg., 1997, Heft 2

Winkler, H.: Über Fehler zur Qualität in: Siemens Magazin COM 3/88

Wulffen, H. A.: Vorgabegerechte Projektsteuerung durch permanente Kostenkontrolle in: Managementzeitschrift Nr. 11, Zürich 1987

Wüstenberg, D.: Konstruktionslehre, 1988

Zahn, E.: Informationstechnologie und Informationsmanagement, Stuttgart 1991

Zenz, P.: Betriebswirtschaftliche Beurteilung von F & E-Abteilungen in Industriebetrieben, Frankfurt 1991