Was ist wichtig bei der Umsetzung eines IT-Projektes?

Was ist wichtig bei der Vorbereitung zur Umsetzung?

Sind die Anforderungen bekannt, ist eine Lösung ausgewählt und ist der Start zur Projektdurchführung gegeben, müssen nun die zu erstellenden Informationssysteme so beschrieben werden, dass die Lösung umgesetzt werden kann. 

Was ist ein Lasten- und Pflichtenheft?

Was beinhaltet ein Lastenheft?

• Beschreibt die „Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers“ (Definition nach DIN 69905)
• Soll vom Auftraggeber formuliert werden
• Dient als Grundlage zur Einholung von Angeboten oder als Kalkulationsgrundlage
• Wird auch gelegentlich als Leistungsverzeichnis (LV) bezeichnet

Ein Lastenheft soll im Wesentlichen folgende Inhalte umfassen:

• Die Spezifikation des zu erstellenden Produkts (die „Last„)
• Die Anforderungen an das Produkt bei seiner Verwendung (z.B. Rechner- und Betriebssystemumgebung)
• Rahmenbedingungen für das Produkt und für die Leistungserbringung (z.B. einzuhaltende Normen)
• Vertragliche Konditionen (z.B. Erbringen von Teilleistungen, Gewährleistungsanforderungen, Risikomanagement usw.)
• Anforderungen an den Auftragnehmer (z.B. Zertifizierung nach ISO 9001)
• Anforderungen an das Projektmanagement des Auftragnehmers (z.B. Projektdokumentation, Qualitätsmanagement)

Ein Lastenheft beschreibt somit das WAS in einer möglichst umfassenden Form, allerdings ohne auf Details der Implementierung einzugehen.

Pflichtenheft im Software-Lebenszyklus“ class=“wp-image-204109″/>

Was beinhaltet ein Pflichtenheft?

• Bildet die Grundlage für die vertraglich festgehaltenen und bindenden Leistungen eines Auftragnehmers
• Beinhaltet „die vom Auftragnehmer erarbeiteten Realisierungsvorgaben“ (Definition nach DIN 69905)
• Beschreibt somit die Umsetzung des vom Auftraggeber vorgegebenen Lastenheftes und ist daher die organisatorische und/oder technische Vorgabe zur Realisierung eines Projekts
• Wird gelegentlich auch als Fachfeinkonzept bezeichnet

Im Gegensatz zum Lastenheft sind die Inhalte des Pflichtenhefts daher präzise, vollständig und nachvollziehbar dokumentiert sowie mit technischen Festlegungen verknüpft, welche z.B. die Betriebs- und Wartungsumgebung festlegen. Das Pflichtenheft beschreibt somit das WIE einer Umsetzung.

Auch wenn die Begriffe „Auftraggeber“ und „Auftragnehmer“ eher aus dem Kontext einer Kunden-Lieferantenbeziehung kommen, wo eine Organisation mit dem Lastenheft beschreibt, WAS gewünscht/benötigt wird und daraufhin ein externer Lieferant ein Angebot legt, einen Zuschlag erhält und dann mit dem Pflichtenheft das WIE präzisiert, gelten diese Begriffe auch innerhalb eines unternehmensinternen Kontexts. Hier ist der Auftraggeber jene Person oder Abteilung, die einen Bedarf hat und diesen möglichst präzise (wenn auch noch nicht detailliert) in einem Lastenheft festlegt. Der Auftragnehmer – eine interne IT-Abteilung beispielsweise – wird daraufhin die Umsetzung in einem Pflichtenheft dokumentieren und mit dem Auftraggeber abstimmen. 

Besonders sei an dieser Stelle darauf hingewiesen, dass mit dem Pflichtenheft eine vertraglich bindende Zusage über die Ausführung einer Leistung getroffen wird (siehe oben). Da das Pflichtenheft auch nur das präzisieren und festlegen kann, was im Lastenheft als Anforderung formuliert ist, ist auf die Qualität beider Dokumente große Sorgfalt zu legen.

Wie wird ein Projekt durchgeführt?

In größeren IT-Organisationen ist die Arbeit in Projekten inzwischen gang und gäbe. Oft wird dabei von Softwareprojekten oder von Softwareentwicklungsprojekten gesprochen. Diese Begriffe führen zur Vorstellung, dass im Rahmen solcher Projekte „nur“ Software entwickelt oder zugekauft und eingesetzt wird. 

Dies greift jedoch zu kurz: Software entfaltet ihre Wirkung erst im Zusammenspiel mit der Umgebung, in der sie eingesetzt wird. Zu jedem Projekt einer IT-Organisation gehören deshalb auch die Betrachtung der Geschäftsprozesse, der Organisation und der Sachmittel, weshalb es besser ist, in diesem Rahmen von Systementwicklungsprojekten oder generell von IT-Projekten zu sprechen.

Bevor wir uns mit dem Ablauf von Projekten beschäftigen ist zunächst eine nähere Abklärung des Projektbegriffs selbst erforderlich. Oft wird von Projekten gesprochen, die keine wirklichen Projekte sind – andererseits geben bereits die Beschreibungen des Projektbegriffs einige Hinweise darauf, warum Projekte keine normalen Aufgaben und Routinetätigkeiten darstellen.

Ein Projekt zeichnet aus, dass es eine einmalige Aufgabe mit besonderen Merkmalen ist:

• Es ist zielorientiert bezüglich Leistung, Ressourcen, Kosten und Zeitrahmen
• Es ist zeitlich begrenzt – Anfang und das (geplante) Ende sind definiert
• Es ist komplex und dynamisch – es sind stark vernetzte Teilaufgaben zu koordinieren, es gibt viele Einflussfaktoren und es ist mit Veränderungen während der Projektlaufzeit zu rechnen
• Projekte sind interdisziplinär und abteilungsübergreifend – es sind unterschiedliche interne und externe Fachbereiche und Organisationseinheiten daran beteiligt
• Und vor allem: es ist neuartig und damit riskant und nur begrenzt abschätzbar

Während der Dauer des Projekts bildet das Projekt selbst ein eigenes Unternehmen auf Zeit. Es gibt Verantwortlichkeiten für Produkte und Ergebnisse, die dem Projekt zugeordneten Mitarbeiter müssen geführt werden, Marketing ist zu betreiben usw.

Projektmanagement als Steuerung eines Projekts ist das Management eines meist komplexen, sozialen Gefüges und der entsprechenden Kooperationen zwischen allen Beteiligten und Betroffenen (den Stakeholdern). Diese Gestaltung der Kooperation ist ein wesentlicher Beitrag zur Erreichung der Projektziele, woraus auch projektspezifische Verhaltensweisen, Werte und Identitäten dieses „Unternehmens“ resultieren.

Projekte und damit verbundenes Projektmanagement werden nicht zum Selbstzweck betrieben, sondern um einen Nutzen zu erzeugen. Gleichzeitig ist Projektmanagement durch den Einsatz von Personen und Mitteln auch mit Kosten verbunden.

Systematisches Projektmanagement führt zu erfolgreicheren Projekten, ohne dass dies mit ständigen heroischen Anstrengungen der Mitarbeiter erkauft werden muss. Gleichzeitig wird der Projekterfolg personenunabhängiger und berechenbarer. Durch konzentriertes und planvolles Vorgehen ergeben sich kürzere Bearbeitungszeiten und damit geringere Gesamtkosten.

Bei großen Projekten mit beispielsweise einem Projektkostenvolumen von ca. 100 Mio. EUR liegt der Anteil des Projektmanagements bei typisch 2 %. Bei kleineren Projekten unter etwa 100.000 EUR ist dagegen ein steiler Anstieg zu verzeichnen, da von einer gewissen Grundlast ausgegangen werden muss – es wird mit etwa 10 % Kostenanteil gerechnet. 

Warum dann also bei so vielen Kosten ein systematisches Projektmanagement? 

Weil: „Projektmanagement kostet etwas, kein Projektmanagement kostet mehr“! Planung und Kontrolle – die Haupttätigkeiten des Projektmanagers – und der Einsatz von entsprechenden Instrumenten sind eine notwendige, wenn auch alleine nicht hinreichende Bedingung für den Projekterfolg. 

Anders ausgedrückt: Ein organisierter Projektablauf ist dem Projekterfolg förderlicher als ein unorganisierter. 

Gleichzeitig ist das auch der Grund, warum nicht jede Aufgabe als Projekt abgewickelt werden soll: die mit einem professionellen Projektmanagement verbundenen Kosten müssen auch gerechtfertigt sein.

Wie findet die Planung statt?

Jegliches Vorhaben, das einen Zeithorizont von wenigen Wochen übersteigt, bedarf einer gewissen Planung. Dies gilt ebenso für alle Projekte rund um Informationssysteme – sei es eine Neubeschaffung, eine Erweiterung eines bestehenden Systems, eine Umstellung eines vorhandenen Systems oder ein Versionswechsel.

Weltz formulierte 1996 in Softwareentwicklung im Umbruch: Projektmanagement als dynamischer Prozeß  das allgemein gültige Paradoxon, dass „Planung zwar nicht möglich, aber notwendig“ ist.

Dies gibt einen Einblick in die Welt der Planung. Planung ist – ebenso wie beispielsweise die Risikoanalyse – eine Schätzung und ein Blick in die Zukunft. Allerdings: Ohne jeglichen Plan ist es genauso wie eine Reise ohne Ziele – irgendwo wird man schon irgendwann ankommen.

Nun sind Planungsvorgänge in der Realität durchaus möglich. Nehmen wir als Beispiel einen Kostenplan: Zu Projektbeginn liegen meistens schon genügend Informationen vor, dass eine erste Kostenplanung durchgeführt werden kann. Der Projektmanager kann eine erste Schätzung vornehmen, zu welchem Zeitpunkt im Projekt welches Material gekauft und bezahlt werden muss oder zu welchem Zeitpunkt Teilleistungen geliefert, verrechnet bzw. bezahlt werden können oder müssen.

Ähnlich verhält es sich mit einem Zeitplan. Eine erste Projektorganisation steht und damit ist bekannt, wieviele Personen die nächste Zeit im Projekt verbringen werden. Ein geplanter Endtermin für das Projekt ist bekannt, es gibt (z.B. aus der Angebotskalkulation oder aus einer Vorstudie) Informationen, wieviel Zeit für welche Teilleistung vorgesehen ist und dergleichen mehr.

Projekte werden meist unter Zeitdruck durchgeführt. Daher hat häufig die rasche Erfüllung von Teilleistungen und nicht die Projektdefinition und die Projektplanung Priorität. Wird die Projektstartphase – die durchaus 15…30% der gesamten Projektlaufzeit in Anspruch nehmen kann! – vernachlässigt, so hat dies weitreichende Konsequenzen für das gesamte Projekt – meist in Form von Zeit- und Kostenüberschreitung und den damit verbundenen Auswirkungen.

Eine nicht ordentlich aufgesetzte Projektstartphase führt zu

• Unrealistischen und unklaren Projektzielen
• Keiner ganzheitlichen Problemsicht bei den Projektmitarbeitern
• Zuwenig Sensibilität für das Umfeld
• Zuwenig Verbindlichkeit bezüglich der Projektziele bei den Projektmitgliedern
• Unklaren Rollenerwartungen

und dergleichen mehr. 

Ziele der Projektstartphase müssen daher sein:

• Erreichen einer ganzheitlichen Problemsicht
• Volle Konzentration auf das Projekt zu Projektbeginn
• Entwicklung einer gemeinsamen Sprache der Projektmitglieder, eines Wir-Gefühls und eines konstruktiven Arbeitsklimas
• Schaffung von Verbindlichkeit bezüglich der Projektziele
• Entwicklung von Projektplänen bezüglich Leistungen, Qualität, Terminen, Ressourcen und Kosten
• Aufbau einer entsprechenden Projektorganisation mit Festlegung der Aufgaben und Kompetenzen sowie
• Sicherung der Unterstützung für das Projekt durch das Top-Management

Geplant werden daher zumindest

• Termine und Kosten
• Arbeitspakete und Lieferungen
• Kapazitäten und Ressourcen
• Risiken und Chancen
• Umgang mit Stakeholdern
• Qualität
• Zahlungen

Was ist bei der Auswahl eines Projektes zu beachten?

Grundsätzlich stellt sich vor einem Projekt die Frage, ob das Projekt überhaupt notwendig und sinnvoll ist, also wird die Software wirklich gebraucht und ist die Annahme realistisch, dass sie sich in der geplanten Zeit amortisiert? Hier unterstützen die Ansätze aus der Business Analyse, nämlich eine Lösung auszuwählen, welche auch einen entsprechenden Nutzen bringt.

Ist dies der Fall, muss geklärt werden, ob die Software entwickelt werden muss. Möglicherweise kann man sie auch kaufen oder mit erträglichem Aufwand aus einer vorhandenen Software ableiten. Diese Frage wird durch das Schlagwort „Make or Buy“ bezeichnet. Tatsächlich ist die Alternative zum Entwickeln (Make) nicht nur der Kauf (Buy), sondern auch die Anpassung oder Wiederverwendung bestehender Software. 

Gleichzeitig gilt es zu berücksichtigen, dass komplexe Informationssysteme wie ein ERP-System wohl kaum mehr selbst entwickelt werden können. Was jedoch nach wie vor eine Option sein kann, ist die Ergänzung zugekaufter Software um spezifische Teile, welche auch vom Know-How der eigenen Entwicklungsmannschaft abgedeckt sind.

Dass die Entwickler stets lieber entwickeln, ist klar, diese sollte aber die Entscheidung nicht vorgeben. Die Kosten einer Neuentwicklung werden in der Regel grob unterschätzt, und zwar umso stärker, je mehr neu entwickelt wird. Die Kosten einer Entwicklung steigen meist während der gesamten Entwicklungsdauer. 

Größere Flexibilität spricht für die Eigenentwicklung oder für die Vergabe eines entsprechenden Auftrags einer Individualentwicklung. Allerdings ist es meist unwirtschaftlich, eine perfekte Lösung anzustreben; eine einfachere Lösung ist oft der bessere Kompromiss.

Im Gegensatz dazu steigt die Planungssicherheit, wenn mehr fertige Komponenten eingesetzt werden. Der Kauf wird unter Umständen billiger als ursprünglich erwartet, weil die Preise der Software fallen oder ihr Funktionsumfang wächst. Durch Kauf erhält man rasch eine relativ ausgereifte Software, in die höherer Entwicklungsaufwand geflossen ist, als ein einzelner Kunde zahlen könnte. Der Aufwand für Wartung und Portierungen ist viel geringer. 

Als Faustregel kann angenommen werden: Kauf oder Wiederverwendung ist dann vorteilhaft, wenn es sich nicht um Software handelt, die das zentrale Know-How des Unternehmens enthält. Es darf jedoch nicht übersehen werden, dass auch bei Kauf zumindest eine Spezifikation, ein Test sowie eine Installation und Schulungen etc. notwendig sind.

Ist diese Entscheidung getroffen, geht es an die Auswahl – sei es die Auswahl einer bestehenden, zukaufbaren Software, die Auswahl eines Lieferanten für eine zu entwickelnde Software oder die Auswahl einer internen Abteilung.

Grundlage für jegliche Auswahl ist ein Lastenheft. In einem korrekten Lastenheft sind alle Anforderungen und Randbedingungen an das durchzuführende Projekt aufgeführt. Dies ermöglicht es nun, an (interne und externe) Lieferanten heranzutreten und hierfür Angebote einzuholen.

Die Auswahl eines Lieferanten ist durch verschiedene Faktoren bestimmt und kann nach verschiedenen Kriterien durchgeführt werden. Faktoren können sein

• Fachwissen und Expertise: Know-how Transfer – muss das Wissen des Anbieters auf das eigene Unternehmen übertragen werden?
• Lizenz- und Preismodell: Beurteilung der Kostennutzen-Relation
• Produktreputation und Marktposition: Größe des Unternehmens, Marktanteil, Roadmap für Weiterentwicklung und Referenzen
• Geschäftsbeziehungen: Vorübergehend oder dauerhaft, wie kann man zu einem anderen Anbieter wechseln (rechtlich, technisch), wer hat die Verantwortung für Informationssicherheit etc.
• Erfahrung und Ruf des Anbieters: Hinweis auf Fähigkeit, vertraglichen Verpflichtungen nachzukommen
• Stabilität des Anbieters: Zukunftssicherheit
• Sonstiges wie beispielsweise Zertifizierungen

Bei den Kriterien zur Auswahl ist somit nicht nur der Preis einer Leistung, sondern auch die Bewertung obiger Kriterien zuzüglich der Leistung selbst einzubeziehen. 

Ein bewährtes Modell zur Ermittlung eines sogenannten Bestbieters ist beispielsweise folgendes:

• Aufteilung der Bewertung der Kriterien „Preis“, „Leistung“ und „Sonstige Kriterien“ z.B. im Verhältnis 50%:30%:20%
• Die Kategorie „Preis“ wird beispielsweise mit 50% für den Billigstbieter, 45% für den zweitbilligsten Bieter usw. festgelegt oder die Bewertung wird linear zwischen billigstem (50%) und teuerstem (0%) Anbieter errechnet
• Für die Kategorie „Leistung“ wird ein Leistungskatalog mit Punktebewertung definiert. Optional zu erbringende Leistungen werden gewichtet und summiert; die maximal mögliche Summe an Bewertungen entspricht 30%, darunter wird linear gerechnet
• Für die Kategorie „Sonstiges“ werden verschiedene Kriterien angeführt und mit Punkten bewertet, beispielsweise die Anzahl an vorhandenen Referenzen für ähnliche Projekte. Die Berechnung erfolgt sinngemäß wie in der Kategorie „Leistung“

Mit einem derartigen System kann anhand festgelegter Kriterien und deren Gewichtung eine nicht nur den Preis, sondern eine auch andere wesentliche Kriterien umfassende Beurteilung erzielt und daraus ein Bestbieter ermittelt werden.

Wie wird ein Projekt beauftragt?

Die Beauftragung eines Projekts ist ein formaler und rechtsverbindlicher Akt. Abhängig vom Auftraggeber sind eventuell bestimmte Vorgangsweisen und Gesetze einzuhalten, beispielsweise im Bereich öffentlicher Auftraggeber.

Mit der Beauftragung wird festgelegt:

• Welcher Leistungsumfang vom Auftragnehmer geliefert wird
• Zu welchen Kosten und innerhalb welcher Zeit dies erfolgen soll
• Wie der Projektverlauf stattfindet (also z.B. wann welche Teilsysteme in Betrieb gehen sollen, an welchen Örtlichkeiten Leistungen erbracht werden müssen, welche Mitwirkungspflichten der Auftraggeber hat etc.)
• Wie die Beurteilung der Lieferungen erfolgt, d.h. welche Tests vorgesehen sind und wie Abnahmen erfolgen
• Welche Schulungen durchzuführen sind und welche Dokumentation zu liefern ist
• Welche begleitenden Tätigkeiten wie z.B. ein Qualitätsmanagement durchzuführen sind
• Welche Personen seitens Auftraggeber und Auftragnehmer Ansprechpartner sind und welche Befugnisse diese im Rahmen des Projekts haben

und dergleichen mehr. 

Verbunden mit der Beauftragung ist auch im Idealfall die Erstellung des Pflichtenhefts, welches ja 

• die Grundlage für die vertraglich festgehaltenen und bindenden Leistungen eines Auftragnehmers bildet 
• damit „die vom Auftragnehmer erarbeiteten Realisierungsvorgaben“ beinhaltet
• und die Umsetzung des vom Auftraggeber vorgegebenen Lastenheftes und die organisatorische und/oder technische Vorgabe zur Realisierung eines Projekts beschreibt

Wie wird ein Projekt umgesetzt?

Nachdem die Vorarbeiten erledigt sind und eine Beauftragung stattgefunden hat, geht es an die Umsetzung, die von einem professionellen Projektmanagement begleitet wird.

Nach DIN 69901 wird Projektmanagement als „die Gesamtheit von Führungsaufgaben, -organisation, -techniken und -mitteln für die Abwicklung eines Projekts“ bezeichnet. Der PMBOK (Project Management Body Of Knowledge) definiert hingegen Projektmanagement als „die Anwendung von Wissen, Fähigkeiten, Werkzeugen und Verfahren auf Projektvorgänge, um die Projektanforderungen zu erfüllen“.

Das PMI (Project Management Institute) unterteilt das Projektmanagement in neun Teildisziplinen, die auch als „9 Wissensfelder des Projektmanagements“ bezeichnet werden. Mit dieser Einteilung wird ein umfassender Überblick über die wesentlichen Teilaspekte des Projektmanagements erreicht.

Integrationsmanagement: das Integrationsmanagement (Project Integration Management) im Projektmanagement beschreibt die Prozesse, die für eine gute Koordination und Integration der unterschiedlichen Aktivitäten eines Projekts erforderlich sind. Es umfasst die Projektplanentwicklung, die Projektplandurchführung und das Änderungswesen.

Umfangsmanagement: das Projektumfangsmanagement (Project Scope Management) befasst sich mit der laufenden Planung und Kontrolle des Leistungsfortschritts im Projekt. Im Rahmen des Umfangsmanagements wird in regelmäßigen Abständen überprüft, ob sich das Projekt „auf dem richtigen Weg” befindet. Zum Projektumfangsmanagement gehören die Projektinitiierung, die Inhalts- und Umfangsplanung, die Leistungsdefinition, die Leistungsverifizierung sowie die Leistungs-überwachung.

Zeitmanagement: das Zeit- und Terminmanagement (Project Time Management) soll sicherstellen, dass ein Projekt termingerecht fertiggestellt wird. Zum Zeit- und Terminmanagement gehören die Vorgangsdefinition, Festlegung der Vorgangsfolgen, Vorgangsdauerschätzung, Terminplanentwicklung und Terminplanüberwachung.

Kostenmanagement: das Kostenmanagement (Project Cost Management) beschreibt alle erforderlichen Prozesse, die sicherstellen sollen, dass das Projekt im geplanten und genehmigten Kostenrahmen fertiggestellt wird. Zum Kostenmanagement gehören Einsatzmittelplanung, Kostenschätzung, Budgetierung sowie Kostenüberwachung.

Qualitätsmanagement: das Qualitätsmanagement in Projekten (Project Quality Management) soll sicherstellen, dass die vom Auftraggeber definierten Qualitätsansprüche eingehalten werden. Dazu gehören Qualitätsplanung, Qualitätssicherung und Qualitätslenkung.

Personalmanagement: die Hauptaufgabe des Personalmanagements (Project Human Resource Management) ist es, dafür zu sorgen, dass die am Projekt beteiligten Mitarbeiter so effizient wie möglich eingesetzt werden. Dem Personalmanagement können folgende Funktionen und Aufgaben zugeordnet werden: Projektorganisation, Personalakquisition und Teamentwicklung.

Kommunikationsmanagement: das Kommunikationsmanagement (Project Communications Management) im Projekt hat zum Ziel, sämtliche Projektinformationen rechtzeitig und angemessen zu erstellen, zu sammeln, zu verbreiten, abzulegen sowie zu definieren. Hierzu gehören der Aufbau eines Informations- und Berichtswesens, die Informationsverteilung, die Fortschrittsermittlung sowie der administrative Abschluss.

Risikomanagement: das Risikomanagement (Project Risk Management) beschreibt sämtliche iterativen Prozesse, die notwendig sind, um Projektrisiken festzustellen, zu analysieren und darauf zu reagieren. Hierzu gehören die Risikoidentifizierung, die Risikobewertung, die Entwicklung von Maßnahmen zur Risikobewältigung sowie die Risikoverfolgung.

Beschaffungsmanagement: das Wissensfeld Beschaffungsmanagement (Project Procurement Management) beinhaltet die Beschaffung von Waren und Leistungen außerhalb der Organisation sowie die dazugehörige Vertragsgestaltung. In diesen Bereich fallen Beschaffungsvorbereitung, Angebotsvorbereitung, Einholen von Angeboten, Lieferantenauswahl, Vertragsgestaltung und Vertragserfüllung.

Begleitet wird eine Projektumsetzung u.a. durch ein angemessenes Controlling, welches innerhalb eines Projekts laufend Plan-/Ist-Vergleiche durchführt und damit durch die Rückkoppelung ein wichtiges Steuerinstrument für einen Projektverlauf darstellt.

Wie wird ein Projekt abgenommen?

Während des Projekts, spätestens aber zum Projektende, können oder müssen einzelne Ergebnisse oder erbrachte Leistungen durch den Auftraggeber formal abgenommen werden. Meistens sind damit auch vertragliche Vereinbarungen (z.B. ein Übergang in die Gewährleistung) und Zahlungen verbunden.

Nach DIN 69901-5 ist die Abnahme eine „unternehmerische Entscheidung des Auftraggebers, dass ein (Teil-)Ergebnis den Vereinbarungen und Erwartungen entspricht und somit als Grundlage für nachfolgende Prozesse verwendet werden kann und muss.“

Die (End-)Abnahme ist somit jener letzte Meilenstein im Projekt, mit der festgestellt wird, ob bzw. dass ein Projekt zu Ende ist. Nach Abschluss des Projektes weist der Projektleiter im Rahmen einer Projektabnahme daher nach, dass:

• das Produkt alle geforderten Funktionen der Spezifikation enthält
• das Produkt in der vereinbarten Qualität erstellt wurde
• das Budget innerhalb des vereinbarten (oder veränderten) Finanzierungsrahmens liegt
• die Termine innerhalb des vereinbarten (oder veränderten) Zeitfensters liegen

Ein Abnahmeprotokoll beinhaltet somit typisch

• die Beschreibung des abzunehmenden Liefergegenstandes
• gegebenenfalls erkannte (und eventuell zu behebende) Mängel sowie mögliche Vorbehalte bei der Abnahme
• einen Abschlussbericht, einen Erfahrungsbericht und einen Testbericht über die Abnahme
• einen Nachweis des Projekterfolges = Messung der Zielerreichung
• eine Nachkalkulation (abschließender Soll/Ist-Vergleich) samt Analyse von Planabweichungen samt Ursachen
• Unterschriften des Auftraggebers und des Projektleiters

Es ist empfehlenswert, die Abnahme als formalen Akt die ganze Projektlaufzeit über bei allen Aktitiväten im Blick zu behalten. Das beginnt bereits mit der Definition der Anforderungen, wo parallel dazu überlegt werden kann und soll, wie die Anforderungen am Ende auf Einhaltung überprüft werden sollen.

Wie wird ein Projekt gewartet?

Die Wartung – die Korrektur, Anpassung und Erweiterung eines Systems – kostet über die gesamte Lebensdauer betrachtet oft mehr als die Entwicklung; es können durchaus mehr als zwei Drittel des Gesamtaufwands in die Wartung gehen.

Pflege (Wartung, engl.: Maintenance) kann definiert werden als Modifikation und/oder Ergänzung bestehender Software durch neue Software mit dem Ziel, Fehler zu beheben, die bestehende Software an veränderte Bedürfnisse oder Umweltbedingungen anzupassen oder die bestehende Software um neue Fähigkeiten zu erweitern.

Es handelt sich somit um eine systematische Erhaltung der Gebrauchstauglichkeit von Programmen nicht nur zur Fehlerbehebung und somit um einen kontinuierlichen Prozess mit folgenden Teilaufgaben:

• Erfassung der Kundenbedürfnisse: reaktiv als Problemmeldewesen oder pro aktiv: wohin geht die Reise (Märkte, Umwelt, Konkurrenz,…)
• Analyse der Kundenbedürfnisse
• Planung der Pflegearbeiten, Bildung von Arbeitspaketen (Releases)
• Durchführung der anstehenden Arbeitspakete und Auslieferung der Ergebnisse
• Verwaltung der Artefakte (Problemmeldungen, Arbeitspakete, Lieferungen usw. mittels Konfigurationsverwaltung)