*Andreas R. Kremer ist bei der DAT Informationssysteme GmbH, Ratingen, verantwortlich für den Bereich Projekt-Controlling und Qualitatssicherung.

Projektkalkulation ist offenbar eine hohe Kunst. Trotz aller Bemühungen sind gerade Softwareprojekte dafür berüchtigt, daß sie jede Aufwandsplanung überschreiten. Andreas R. Kremer schlägt ein Verfahren vor, daß diesem Mißstand ein Ende bereiten

soll.

Eine Projektkalkulation findet üblicherweise erstmalig während der Angebotserstellung statt. Hier sind unter anderem funktionale, technische und organisatorische Aspekte zu berücksichtigen, die sich aus den Auftraggeberanforderungen ergeben. Außerdem spielen Punkte eine Rolle, die primär den Auftragnehmer betreffen, zum Beispiel das Vorgehensmodelle die Software-Entwicklungsumgebung oder das verfügbare Know-how.

Diese Zusammenhänge können nicht alle vollständig im Vorfeld geklärt werden. In der Praxis besitzen die Ausschreibungsunterlagen meist mehr oder weniger große Informationslücken. Quantität und Qualität der zur Verfügung stehenden Eingangsinformationen bestimmen jedoch einen wesentlichen Faktor des Angebots: die Reichweite. Der seriöse Anbieter wird kein Festpreisangebot - und damit auch keine Kalkulation - für die Realisierung eines Systems abgeben, solange nicht Analyse und Konzeption vorliegen.

Die Kalkulation basiert auf Vorinformationen aus den Bereichen Informationsystem-Modell, Tektonik (Bauweise/Architektur), Stufen- beziehungsweise Einführungsmodell. Darauf aufbauend kann die eigentliche Berechnung erfolgen wobei sich folgender Ablauf ergibt:

- Projektstrukturierung/Aufgabengliederung,

- Aufgabenblock-Spezifikation,

- Klassentabellen- und Arbeitspakete-Definition,

- Grobterminierung, vorläufige Ressourcenplanung und schließlich

- Kostenermittlung und Preisfindung.

Auf hohem Abstraktionsniveau

Doch gehen wir zurück zum lnformationssystem-Modell. Es beschreibt die funktional-fachlichen und organisatorischen Anforderungen des Auftraggebers beziehungsweise Anwenders zunächst auf hohem Abstraktionsniveau. Zwei Zielaussagen sind im Hinblick, auf die Kalkulation wesentlich:

1. Darstellung des geförderten Ziel-Informationssystems unter Abgrenzung (Schnittstellen) zu seiner Umgebung (Betreiber, Versorger, Nachbarsysteme, etc.),

2. Definition der Subsysteme bei "großen" Informationssystemen beziehungsweise der Systemhauptfunktionen.

Für die anwenderintegrierte Entwicklung dieses Systemmodells hat sich die Methode der strukturierten Analyse (SA) nach DeMarco seit vielen Jahren als Quasi-Standard bewährt. Viele Ausschreibungen in den USA setzen diese Methode per Richtlinie voraus.

Der zweite Informationsschritt betrifft die Tektronik: Bis heute ist die Software-Entwicklung fest mit dem Begriff Phasenmodell verbunden. Phasenmodelle, die seit den 70er Jahren benutzt werden, gehen von der Voraussetzung aus, daß die Software-Entwicklung in Phasen zerlegbar ist. Ihr Grundprinzip der streng sequentiellen oder - bei moderneren Formen - zyklisch sequentiellen PhasenabfoIge impliziert starre Projektstrukturen.

Die bei der Entstehung der Phasenmodelle vorhandene Systemlandschaft war geprägt von einfachsten Anwendungsarchitekturen (Monolith-Programm auf dem Host) mit relativ starren Vorgaben durch die Betriebssoftware in bezug auf Datenhaltung oder Oberflächengestaltung.

Betrachtet man die Situation von heute, so läßt sich feststellen, daß komplexe Systemarchitekturen wie die Client-Server-Technologie bis zur Emanzipation von Anwendungsschichten innerhalb der Anwendungen (Datenverwaltung, Oberfläche, Kommunikation, Systembasis etc.) neben den funktionalen Abläufen hohe Anforderungen an die Entwickler stellen.

Immer höhere Anforderungen

Komplexe Systemarchitekturen und die Emanzipation der Anwendzungsschichten Benutzeroberfläche und Kommunikation von der Datenverwaltung stellen immer höhere Anforderungen an die Entwickler. Hieraus folgt, daß ein Vorgehensmodell als Grundlage für Entwicklung und Projektstrukturierung neben den Verrichtungsaspekten explizit die Schichten beziehungsweise Objekte des zu planenden Systems berücksichtigen muß. Es entsteht das Schichtenmodell.

Auf der vertikalen Achse werden die Architekturschichten oder -objekte Kommunikation (Connectivity/Vernetzung), Präsentation (Benutzeroberfläche), Prozesse (Funktionen/Algorithmen), Datenbasis (DB-System), Systembasis (Hardwareplattform) um das Objekt Organisation ergänzt. Dieses bündelt die Aufgaben im Umfeld der Systementwicklung zum Beispiel durch Dokumentation und Schulung. Eine dedizierte Betrachtung der Systembasis trägt der rasanten technischen Entwicklung auf diesem Sektor Rechnung. Früher nicht bekannte Aufgabenstellungen, die sich beispielsweise aus der Trennung voll Entwicklungssystem beziehungsweise -umgebung und Zielsystem ergeben, können so berücksichtigt werden. Dies gilt gleichermaßen für die übrigen Objekte.

Geschickte Aufteilung in Teilprojekte

Vor allem bei Vorhaben, für die mehr als zehn Mannjahre veranschlagt werden, sollte anstelle einer Gesamtkalkulation eine geschickte Aufteilung in separat zu kalkulierende und zu planende Projekte beziehungsweise Teilprojekte stattfinden. Voraussetzung ist die Identifikation von Subsystemen, die innerhalb der (Teil-)Projekte entwickelt sowie integriert und nach organisatorischen Rahmenbedingungen beziehungsweise -anforderungen sukzessive eingeführt werden können.

Diese Vorgehensweise sollte idealerweise immer dann zur Anwendung kommen, wenn die Projektlaufzeit bei Einsatz eines mittelgroßen Teams ein Jahr übersteigt. Beispiel: Aufteilung eines PPS-Systems in die sequentiell zu integrierenden Stufen BDE, Fertigungssteuerung und Produktionsplanung.

Die Einführung von Teilprojekten ist auch dann sinnvoll, wenn sich dadurch die Qualität erhöht. Beispiel: Eine erste Projektstufe "Stammdatenverwaltung" kann dazu dienen, nach Einführung beim Anwender sogenannte Datenleichen bei der Überführung des Bestandes in das neue Subsystem zu eliminieren und so die organisatorischen Voraussetzungen für die Einführung eines neuen DV-Systems zu schaffen.

Die Strukturierung von Projektabläufen

Beim Phasen- und Schichtenmodell, unter dem Aspekt der Projektgliederung betrachtet, zeigt sich, daß weder eine streng vertikale Betrachtung der Aktivitäten innerhalb einer Phase noch die streng horizontale Betrachtung der Aktivitäten innerhalb einer Sicht angemessen ist. Vielmehr ist eine am konkreten Projektrahmen und den sachlogischen Erwägungen ausgerichtete Betrachtung sowohl horizontaler als auch vertikaler Aspekte notwendig.

Wesentlicher Eckpfeiler des Verfahrens ist deshalb das "Zuschneiden" voll Aufgabenblökken (AB) innerhalb der Aufgabengliederungs-Matrix (AGM) (siehe Abbildung 1). Diese dient dazu, die im Rahmen des Projektes zu entwickelnden Objekte nach erforderlichen Aktivitäten zu planen - mit dem Ergebnis voll Aufgabenblöcken, die auf einer ersten, relativ groben, aber aussagefähigen Ebene den projektindividuell zu erbringenden Aufgabenumfang beschreiben. Durch die Abgrenzung wird unter anderem deutlich, was nicht zum Leistungsumfang des Angebots gehört.

Wichtig ist, daß an dieser Stelle nicht festgelegt wird, wie ein Ergebnis, zum Beispiel das Datenmodell, zu erstellen ist, sondern was beziehungsweise welche Ergebnisse zu erstellen sind. Durch das Verfahren des "Zuschneidens" von AufgabenbIökken in der Aufgabengliederungs-Matrix soll erreicht werden, daß die Planung des Entwicklungsvorhabens nach sachlogischen Beschränkungen getrennt von Ressourcenbeschränkungen betrachtet werden kann.

Aufgabenblöcke beschreiben die zu erbringenden Leistungsumfänge nur qualitativ. Im Hinblick auf die Aufwandsermittlung muß eine Detaillierung und Konkretisierung der Aufgaben erfolgen. Jeder Aufgabenblock umfaßt eine Vielzahl von Einzelaktivitäten zur Erstellung der jeweiligen Teilergebnisse. Die Gruppierung der erforderlichen Aktivitäten sowie ihre Bewertung erfolgt in Arbeitspaketen. Es entsteht eine 1:n-Beziehung zwischen Aufgabenblökken und Arbeitspaketen. Letztere dienen also dazu, bestimmte logisch zusammenhängende Aktivitäten eines Aufgabenblocks zu definieren, zu dokumentieren, zu bewerten und - wenn möglich - mit Ressourcen zu versehen.

Die Bewertung der Einzelaktivitäten innerhalb von Arbeitspaketen erfolgt auf Basis einer Aufwandsschätzung, die nicht Bestandteil des hier beschriebenen Verfahrens ist. Abhängig von der Art der Aktion oder von der Erfahrung des Pojektmitleiters können verschiedene Schätzmethoden zum Einsatz kommen.

Aufwandsabschätzung mit Punkteverfahren

Die so geschätzten Aufwandswerte in Manntagen (MT) werden in einen Punktwert umgerechnet, der in die Arbeitspakete einzutragen ist. Geht man von unbegrenzt verfügbaren Mitarbeiterressourcen mit gleicher Qualifikation aus, so gilt die Zuordnungsformel: Zehn Punkte entsprechen einem Manntag.

Dieses Verfahren hat zwei Vorteile. Zum einen erfolgt die Bewertung losgelöst von einer speziellen Schätzmethode und - zum Zeitpunkt der Angebotskalkulation - zunächst einmal ressourcenunabhängig. Außerdem können Beschränkungen, die sich bei Projektstart zum Beispiel aus nur teilweise einsatzfähigen oder produktiven Mitarbeitern (zum Beispiel Anfängern) ergeben, über eine Mitarbeiterproduktivitätstabelle berücksichtigt werden. Der geschätzte Aufwand (Punkte) für die Aktivität bleibt stets gleich - nur die Zeitdauer zur Erledigung variiert ressourcenabhängig.

Nachdem Aufgabengliederungs-Matrix (je Subsystem), Aufgabenblöcke und Arbeitspakete entwickelt wurden, gilt es im nächsten Schritt, die Aufgabenblöcke auf die Zeitachse zu übertragen. Dies erfolgt unter Berücksichtigung der notwendigen logischen

Reihenfolge, die sich über die Ergebniskoppelung der Aufgabenblöcke ergibt. Ein Block, der sich mit der Realisierung beschäftigt, muß beispielsweise auf der Zeitachse hinter einem Aufgabenblock eingetragen werden, dessen Ergebnis der Entwurf ist.

Diese Betrachtung liefert einen ersten Überblick über die zeitliche Dimension des Vorhabens - allerdings bislang unter der Prämisse, daß es keine knappen Ressourcen gibt. Ein Defizit an Ressourcen kann zu einer anderen Anordnung von AufgabenbIöcken im logischen Netzplan führen, wobei logisch erzwungene Reihenfolgen nicht verletzt werden dürfen.

Die Wiederverwendung von Kalkulationswerten

Ein weiteres Prinzip des hier vorgestellten Verfahrens ist die Wiederverwendung von Kalkulations-Erfahrungswerten. Zu diesem Zweck können Aktivitätentypen beziehungsweise Aktivitätenklassen definiert und in Klassentabellen dokumentiert werden. Die Aktivitäten eines Typs beziehungsweise einer Klasse sind dadurch gekennzeichnet, daß sie mehrfach vorkommen und ihre Verrichtung stets den gleichen Aufwand verursacht.

Die Aktivitätentypen werden in den Klassentabellen ähnlich wie die Aktivitäten innerhalb der Arbeitspakete bewertet, das heißt mit ihrem bekannten Aufwand (Punktwert) eingetragen, zusätzlich aber mit einem Schlüssel - der Klasse - gekennzeichnet.

Enthält ein Arbeitspaket eine konkrete Aktivität von einem bekannten Typ (zum Beispiel Programmierung des Programmes Nr. 123, das dem obigen Typ entspricht), so wird diese Aktivität durch den Schlüssel (die Klasse) mit dem in der Klassentabelle eingetragenen Aktivitätentyp verknüpft und die zugehörige Aufwandszahl übernommen.

Der Vorgang der begleitenden Aufwandsschätzung reduziert sich somit nach Einteilung in bekannte beziehungsweise typische und neue beziehungsweise individuelle Aktivitäten auf die Schätzung der neuen beziehungsweise individuellen Komponenten. Voraussetzung dafür ist, daß in der Vergangenheit Klassentabellen als Erfahrungsdatenbanken mit entsprechender Eignung definiert wurden. Der Zugriff auf Erfahrungswerte verbessert nicht nur die Genauigkeit, sondern ermöglicht zudem eine höhere Anzahl an Schätzungen.

Zur projektübergreifenden beziehungsweise abteilungsübergreifenden Nutzung von Klassentabellen muß die Entwicklungsumgebung, für die die zugeordneten Aufwands-Punktwerte gelten, dokumentiert werden. Die Summe der Arbeitspaket-Punkte ergibt eine erste Aufwandszahl. Diese muß nun um Aufwendungen für vorbereitende und übergreifende Maßnahmen ergänzt werden. Hier ist zunächst der Aufwand für Projekt-Management und Qualitätssicherung zu berücksichtigen.

Darüber hinaus müssen die voraussichtlichen Kosten (Sondereinzelkosten) ebenso wie der Personalaufwand geschätzt und möglichst dem voraussichtlichen Verursacher zugeordnet werden. Dies ist in der Regel auf Aufgabenblock-, im Einzelfall nur auf Projektebene möglich. Im Aufgabenblock können deshalb zusätzlich folgende Aufwendungen beziehungsweise Kosten eingetragen werden:

- Sachkosten (Kosten für Sachmittel),

- Reisekosten,

- Akquisitionskosten und

- Risikokosten.

Feinterminierung und Ressourcenplanung

Der logisch Netzplan bietet einen ersten Überblick über die zeitliche Dimension des Vorhabens. Bei seiner Entstehung im Rahmen der Angebotsgestaltung/Kalkulation wird in der Praxis meistens von folgenden Annahmen auszugehen sein:

- Der Auftraggeber hat konkrete Vorstellungen über Projektstart und -ende.

- Der Anbieter weiß noch nicht im Detail, welche konkreten Ressourcen zum Zeitpunkt des Projektstartes zum Einsatz kommen können. Er wird bei der Grobplanung also nicht von einem Ressourcendefizit ausgehen.

- Die Anordung der Aufgabenblöcke ergibt sich iterativ aus den ermittelten Aufgabenblockaufwendungen (unter Annahme von zu 100 Prozent verfügbaren Ressourcen) sowie den sachlogischen Beschränkungen beziehungsweise Rahmenbedingungen und Einführungsvorstellungen.

Eine Revision ist erforderlich

Der so ermittelte logische Netzplan sowie das gesamte Kalkulationsergebnis muß im Rahmen der nach Auftragserteilung durchzuführenden Projektplanung und Feinterminierung einem Revisionsverfahren unterzogen werden.

Neben wichtigen Fragestellungen wie Zulieferungssicherheit und Sachmittelverfügbarkeit sind dabei die konkreten Personalressourcen zu berücksichtigen.

Das Verfahren unterstützt die Feinterminierung beziehungsweise die Kalkulationsrevison durch zwei Komponenten: Bei der Verfeinerung der Arbeitspakete kann der Planer in der entsprechenden Spalte Ressource/Mitarbeiter die Mitarbeiterzuordnung treffen.

Der Fertigstellungstermin des Arbeitspaketes ergibt sich dann aus den zuvor - personenunabhängig - geschätzten Punkten der Aktivität multipliziert mit dem projekteinsatzabhängigen, individuellen Produktivitätsfaktor aus einer Mitarbeiter-Produktivitätstabelle.

Die im Rahmen der Angebotserstellung durchgeführte Grobterminierung des logischen Netzplans mit den Start- und Endwerten für die Aufgabenblöcke wird so durch Zuordnung von konkreten Ressourcen mit Produktivitätsfaktoren innerhalb der Arbeitspakete und den daraus resultierenden Fertigstellungsterminen überprüft.

Der Angebotspreis wird nun wie folgt ermittelt: Zuerst erfolgt die Aufsummierung und Dokumentation aller Aufwendungen nach dem Schema: Personal-, Sach-, Reise-, Akquisitions- und Risikoaufwendungen.

Im zweiten Schritt werden die Kosten nach dem gleichen Schema unter Zugrundelegung des gültigen Kostensatzes ermittelt. Hier wird auch festgelegt, ob die jeweiligen Posten in bezug auf den Angebotspreis angerechnet werden sollen. Auf Basis dieser Werte erfolgt die Preisbildung.

Die hohe Transparenz und Nachvollziehbarkeit ist ein entscheidender Erfolgsfaktor des Verfahrens. Verhandlungen über Projektumfänge und -risiken sowie über die daraus resultierenden Aufwendungen gestalten sich nicht wie "beim Teppichkauf auf einem orientalischen Basar", so Tom DeMarco nach seiner Untersuchung von 500 DV-Projekten, sondern auf Basis spezifizierter und bewerteter Aufgabenblöcke, Arbeitspakete, Kostenverursacher und Risiken.

Das geschilderte Verfahren muß nicht notwendig zu Bergen von Formularen führen. Es läßt sich auch durch ein PC-Programm auf Basis einer Tabellenkalkulation nachvollziehen.