Anforderungen, Änderungen und Abweichungen im Griff: Requirements und Claim Management

Transkript

1 Anforderungen, Änderungen und Abweichungen im Griff: Requirements und Claim Management (RCM) White Paper Dr. Andreas Knaus, Rolf Reppert santix AG Unabhängig Spezialisiert Flexibel

2 Inhalt 1 Überblick 2 2 Herausforderung 3 3 RCM in der Baubranche 8 4 Was können wir von der Baubranche lernen? 11 5 RCM in der Softwareentwicklung 13 6 Fazit 15 Requirements & Claim Management in der IT Dr. Andreas Knaus, Rolf Reppert 1

3 1 Überblick Zu spät, zu teuer, zu schlecht: so lassen sich die Erfahrungen mit externen Dienstleistungen zusammen fassen. Die Industrialisierung in der IT bringt eine zunehmende unternehmensweite Zusammenarbeit mit sich. Ob nun einzelne Applikationen von Softwarefirmen programmiert oder ganze Bereiche von Outsourcern übernommen werden, immer ist die Leistung komplex. In der Vergangenheit hat man an vielen Beispielen gesehen, dass solche Projekte in der IT häufig scheitern. Software wird nicht rechtzeitig und meist zu teuer fertig und Kunden sind mit der Outsourcingleistung unzufrieden. Grund hierfür ist in der Regel eine unzureichend genaue Leistungsbeschreibung, die sowohl Dienstleister als auch Auftraggeber im Unklaren lässt was zu erbringen bzw. zu erwarten ist. Um diesen Missstand erst recht angesichts der zunehmenden, unternehmensübergreifenden Zusammenarbeit, die die Industrialisierung der IT mit sich bringt zu beseitigen, ist ein strukturiertes Anforderungsmanagement (Requirements Management) nötig. Es umfasst sowohl die Anforderungserhebung (Requirements-Engineering) als auch Maßnahmen zur Steuerung, Kontrolle und Verwaltung von Anforderungen, also Risiko-, Änderungs- und Umsetzungsmanagement. Im Rahmen des Software- und Systemreifegradmodelle CMMI und SPICE (ISO 15504) und im Software Life Cycle Process (ISO 12207) spielt das Anforderungsmanagement eine zentrale Rolle. Aber auch in anderen Branchen wie beispielsweise im Bauwesen wird dem Anforderungsmanagement ein herausragendes Gewicht zuteil. Leider ist in der Regel der Aufwand für eine abgeschlossene Beschreibung sehr hoch, oder es kommen im Laufe der Umsetzungs- und Leistungsphase neue Anforderungen hinzu, so dass immer wieder Streitigkeiten über Verantwortlichkeiten entstehen. Diesen wird mit einem dedizierten Forderungsmanagement (Claim Management) begegnet. Gemäß DIN ist das Claim Management die "Überwachung und Beurteilung von Abweichungen bzw. Änderungen und deren wirtschaftlichen Folgen zwecks Ermittlung und Durchsetzung von Ansprüchen". Zusammen bilden das Requirements Management und das Claim Management ein unverzichtbares Rahmenwerk, um IT Projekte erfolgreich abzuschließen. Ein effektives Requirements und Claim Management stellt die präzise und vollständige Aufnahme von funktionalen und nicht-funktionalen Anforderungen sicher, regelt den Umgang mit Änderungen von Anforderungen während des Projektes und stellt sicher, dass diese kosteneffektiv umgesetzt werden, ermöglicht eine realistischere Projektplanung und Nachvollziehbarkeit des Projektstandes, bildet eine definierte und nachvollziehbare Vertragsgrundlage für die Vergabe an externe Dienstleister und stärkt den werkvertraglichen Charakter solcher Verträge, stellt sicher, dass berechtigte Forderungen aus den Verträgen kosteneffektiv durchgesetzt werden und ungerechtfertigte Forderungen abgewehrt werden können santix bietet mit Requirements und Claim Management in der IT (RCM) eine Best Practise- Methodik, die die zielgerichtete Umsetzung von IT-Vorhaben in den Mittelpunkt stellt und schon im Vorfeld Maßnahmen definiert, die auch im Streitfall juristische Schritte vermeiden helfen. Requirements & Claim Management in der IT Dr. Andreas Knaus, Rolf Reppert 2

4 2 Herausforderung Im Zusammenhang mit Softwareprojekten wird gerne der Chaos Report der Standish Group zitiert. Seit 1984 werden hier im zweijährigen Rhythmus die Erfolgschancen unterschiedlicher Projekte untersucht. In der ersten Studie wurde eine verheerende Erfolgsquote von nur 16,2 Prozent attestiert. Glücklicherweise lässt sich eine deutliche Verbesserung feststellen, so waren 2006 (neuere Zahlen liegen noch nicht vor) immerhin 35 Prozent der Projekte erfolgreich. Trotzdem zeigen sich immer noch große Mängel, da weiterhin fast zwei Drittel der Entwicklungen entweder abgebrochen werden oder nur mit erhöhtem finanziellen und zeitlichen Aufwand zu Ende gebracht werden konnten. Zur Verbesserung der Situation trug auf der einen Seite bei, dass die Projektgröße im Bezug zu den finanziellen Mitteln abgenommen hat und gleichzeitig das Projektmanagement über die letzten Jahre deutlich professioneller geworden ist. Geblieben ist jedoch das schon 1984 bemängelte Unverständnis des Projektes, welche Anforderungen umzusetzen sind. Dieser Aspekt wird durch die zunehmende Agilität der zu unterstützenden Geschäftsprozesse noch verstärkt. Die unzureichende Anforderungsaufnahme führt meist zu einer unrealistischen Planung. Und im Rahmen der Umsetzung ergibt sich durch Geschäftsprozesse, die sich an sich ändernden Marktsituationen anpassen müssen, ein stetiger Drift des zu erbringenden Leistungsgegenstandes und damit zu einer kontinuierlichen Neu- und Umplanung des Projektes. Der tatsächliche Entwicklungsstand ist damit fast nicht nachvollziehbar. Im Zusammenspiel unterschiedlicher Partner wird dieser Sachverhalt schnell zur Kostenfalle. Sind beispielsweise Entwicklungsaufträge zum Festpreis vergeben worden, so stellt sich schnell die Frage, welcher der Partner für die Veränderungen in der Umsetzung aufkommen muss. Der Auftraggeber läuft Gefahr, am Ende der Entwicklungszeit eine nicht mehr passende Software zu erhalten, oder er muss alle Veränderungen zu saftigen Tagessätzen einzeln entwickeln lassen und somit nachzahlen. Der Auftraggeber hat also schon zu vertragsbeginn ein Interesse, etwaige Veränderungen pauschal mit einzuplanen. Lässt sich aber der Auftragnehmer auf solche Verträge ein, so läuft dieser schnell in die Leistungsfalle, die zuschnappt, wenn es größere, komplexere oder einfach nur mehr Änderungswünsche gibt als ursprünglich kalkuliert. Insgesamt entsteht dadurch eine beidseitige Unzufriedenheit bei notwendigen Leistungs- oder Vertragsanpassungen, bei der Umsetzung von Innovationen, oder eben der Nachvollziehbarkeit der Leistungserbringung. Verstärkt wird dies auch durch die meist längerfristigen Vertragsbindungen, die man sich bei begründeter Unzufriedenheit oft auch nicht zu trennen traut, aus Furcht vor einem aufwändigen Partnerwechsel. Die Herausforderungen bei Softwareprojekten lassen sich gut entlang der Entwicklungsphasen aufzählen. Im einfachsten Fall sind dies die drei Phasen Plan, Build und Run (siehe Abbildung 1) Requirements & Claim Management in der IT Dr. Andreas Knaus, Rolf Reppert 3

5 Abbildung 1: Phasen der Softwareentwicklung In der Planungsphase werden üblicherweise die Anforderungen erfasst. Auf dieser Basis wird eine erste Grobplanung erstellt. Mit Hilfe dieser beiden Ergebnisse kann ein geeigneter Dienstleister für die Umsetzung gesucht und beauftragt werden. In der zweiten Phase, Build, wird der Dienstleister die technische und inhaltliche Feinplanung übernehmen. Neben den anfangs ermittelten Anforderungen können hier noch weitere Konkretisierungen notwendig sein. Das so erstellte Konzept wird in der Implementierungsphase umgesetzt und deren Korrektheit anschließend überprüft. Üblicherweise werden im Rahmen der Umsetzung unterschiedliche Testkonzepte verwendet. Hier sei nur beispielhaft der Modul- und Komponententest genannt. Diese zeigen inwieweit die anfangs definierten Anforderungen durch die Implementierung erfüllt sind. Ist der Test auch in einer Integrationsumgebung erfolgreich, so kann üblicherweise eine Abnahme erfolgen. Jetzt (Phase Run) kann die Software ausgerollt und genutzt werden. Etwaige Verbesserungen gehen in den weiteren Lebenszyklus der Software ein. Jede dieser Phasen hat nun ihre eigenen Herausforderungen und Problemstellungen: Plan Anforderungserhebung (Requirements Engineering) Es liegen unzureichende oder mangelhafte Basisinformationen (Infrastruktur, Service- Topologie, Performanz-Referenzdaten) für die Planung und den Entwurf des Systems vor. Damit können z.b. die Ressourcenbedarfshochrechnungen nicht korrekt sein. Es liegen beim Auftraggeber ungenügende oder falsche Vorstellungen über bereitstehendes Budget und verfügbare Zeit vor. Damit werden jedoch unrealistische Rahmenbedingungen für die Projektplanung gesteckt. Die funktionalen und nicht-funktionalen Anforderungen werden nicht hinreichend definiert, so dass Unklarheiten bestehen bleiben und die Anforderungen ggf. für den Auftraggeber nicht nachvollziehbar sind. Es besteht dann die Gefahr, dass die Funktionen zur Abdeckung der Fachaufgabe oder auch die Anforderungen an die Leistungsfähigkeit der Software (z.b. Durchsatz) nicht ausreichend formuliert wurden. Requirements & Claim Management in der IT Dr. Andreas Knaus, Rolf Reppert 4

6 Build Die Erwartungskonformität ist nicht abgestimmt 1 oder unzureichend (z.b. ohne Berücksichtigung der Sicherheitsrichtlinien) definiert. Die Erwartungskonformität ist ein wichtiges Akzeptanzkriterium für die Benutzer der Software. Grobplanung Die Anforderungen der Ablaufarchitektur und des Betriebs werden nicht definiert oder unstrukturiert kommuniziert. Eine effektive Vorbereitung des Betriebsübergangs und des Betriebs der Anwendung ist damit aber nicht möglich. Vergabe und Vertragsschluss Das Vertragswerk ist unvollständig (d.h. nicht alles ist beschrieben) und/oder unvollkommen (d.h. nicht alles durchsetzbar). Es besteht die Gefahr, dass ein Vertragspartner übervorteilt wird. Das Vertragswerk berücksichtigt nicht, dass es sowohl in der Phase der Planung als auch in der späteren Phase Build zu Änderungen der Anforderungen kommen kann. Es besteht also kein festgelegtes und beiderseits akzeptiertes Vorgehen, um Änderungen gesteuert erfassen, bewerten und aufnehmen zu können (Change Management). Ohne ein solches Vorgehen verursachen Änderungen meist übermäßige Kosten. Es bestehen keine klaren Kriterien für die Abnahme der Leistung (hier: der Software). Dies kann z.b. auf ungenau oder nicht bewertbare formulierte Anforderungen zurückgeführt werden. Auf diese Weise kann sogar ein gut abgewickeltes Projekt am Ende noch zum Streitfall werden. Entwurf Es entstehen während der Entwicklungsphase neue (funktionale oder nichtfunktionale) Anforderungen, deren mittelbare und unmittelbare Auswirkungen nicht erkannt oder bewertet werden. Beispielsweise können zusätzliche Kapazitätsanforderungen an die Infrastruktur entstehen, die aber nicht rechtzeitig geliefert werden. Situative Entscheidungen während der Entwicklung führen dazu, dass Funktionen/Änderungen aus technischen und pragmatischen Gründen oder nur vorübergehend abweichend von Richtlinien oder Spezifikationen implementiert werden, ohne genaue Prüfung von Auswirkung auf Budget, Zeit oder Wechselwirkungen. Dies kann insbesondere kritisch werden, wenn Sicherheitsfunktionen damit ausgehebelt werden. Es entstehen latent Inkompatibilitäten mit anderen Infrastrukturkomponenten oder Anwendungen, die den späteren Einsatz der Software erschweren. 1 Eine Software ist erwartungskonform, wenn sie der Ausbildung, den Kenntnissen und Erfahrungen des Benutzers entspricht, die Orientierung (auf unterschiedlichen Ebenen) durch eine einheitliche Gestaltung erleichtert wird, sie nach einem einheitlichen Prinzip bedienbar ist, sie Auskunft darüber gibt, ob eine Eingabe erfolgreich oder erfolglos war, die Bearbeitungszeiten vorhersehbar sind, sie den Benutzer über gerade ablaufende Prozesse informiert. Requirements & Claim Management in der IT Dr. Andreas Knaus, Rolf Reppert 5

7 Run Test / Abnahme Betriebliche (nicht funktionale) Anforderungen werden bei den Tests nicht berücksichtigt. Die Service und System Management Unterstützung wird nicht oder nur unzureichend getestet. Nach der Auslieferung werden z.b. Fehlersituationen von den System Management Tools nicht, zu spät oder falsch gemeldet. Auslieferung Es fehlen Pakete für die Softwareverteilung. Dies kann den Rollout (und damit das Projekt) verlängern und auch den späteren Betrieb erschweren (manuelle Installation). In beiden Phasen ist die Fehlerwahrscheinlichkeit evtl. höher. Es fehlen Mengengerüste. Dies kann beispielsweise dazu führen, dass die beschaffte Hardware schon während der Pilotphase skaliert werden muss. Aber auch das Fehlen einer simplen Liste von Clients, an denen die Software installiert werden soll kann die Auslieferung unnötig aufhalten. Für den Betrieb der Anwendung wurden keine SLAs definiert. Unter anderem könnten die Erwartungen an die Verfügbarkeit der Anwendung nicht erfüllt werden. Betrieb Es besteht Unklarheit über die Integration in die Anwenderüberwachung. Dies kann dazu führen, dass die Anwendung unzureichend im laufenden Betrieb beobachtet wird. Dies kann zur Konsequenz haben, dass Verfügbarkeit und Performanz nicht oder falsch gemessen werden. Es erfolgt keine systematische Weitergabe von Fehlern aus dem Betrieb an die Entwicklungsabteilung (Software Request for Change). Störungen werden daher unvollständig oder verzögert an die Entwicklung gemeldet und die Möglichkeiten zur Behebung eingeschränkt. Evtl. führen entwicklungsbezogene Fehlermeldungen, die vom Betrieb nur schwer verständlich sind zu falschen Korrekturmaßnahmen. Der Umgang mit Alarmen oder Fehlermeldungen ist dem Betrieb unklar oder der Service Desk ist unzureichend vorbereitet. Ein gezielter Umgang mit diesen Ereignissen ist daher nicht möglich. Backup und Recovery-Mechanismen sind unzureichend und können so eine schnelle und umfassende Wiederherstellung nicht gewährleisten. Optimierung Anwendungstopologie, Anwendungsarchitektur oder Kapazitätsbedarfsprofil der Anwendung sind dem Betrieb nicht hinreichend bekannt. Tuning-Maßnahmen zur Leistungssteigerung sind aus diesem Grund nur wenig oder nicht effektiv. Kurz: In der Planungsphase mangelt es oftmals an einer klar und vollständig umrissenen Aufgabenbeschreibung, einem gemeinsamen Verständnis sowie einer vereinbarten Vorgehensweise, wie mit Anpassungen der Anforderungen umzugehen ist. Ein adäquates Handling von neuen oder sich än- Requirements & Claim Management in der IT Dr. Andreas Knaus, Rolf Reppert 6

8 dernden Anforderungen ist besonders in der Phase Build notwendig, während sich spätestens in der Phase Run zeigt, ob die Aufgabenbeschreibung auch wichtige, nicht-funktionale Anforderungen für den Betrieb hinreichend genau einfordert. Es zeigt sich die Komplexität, die bereits im Planungsstadium einer Software zu berücksichtigen ist: Die gründliche Bereitstellung von Informationen und eine umfassende Beleuchtung aller Aspekte haben Auswirkungen, die bis in die Betriebsphase der Anwendung hineinreichen. Verschärft werden die hier beschriebenen Herausforderungen durch die große Zahl der Handelnden. In jeder Phase sind für die Realisierung eines Softwareprojektes bereits in Planungsphase viele Bereiche zu involvieren. Die wichtigsten Interessensvertreter sind in der folgenden Tabelle aufgeführt. Fachabteilung Der Bedarf der Fachabteilung(en) determiniert die fachlichfunktionalen Anforderungen an die zu erstellende Lösung. Betriebsabteilung/Rechenzentrum Governance Software-Architekt Administration Dienstleister Neben den fachlichen Anforderungen existieren auch Anforderungen für den Produktivbetrieb der Anwendung, die das Rechenzentrum bei der Planung und der Umsetzung vorgibt, z. B. Hardware-Gegebenheiten. Die Governance liefert beispielsweise Architekturvorgaben oder auch Anforderungen aus dem Bereich Security Management. Ein Software-Architekt nimmt die Anforderungen der Fachabteilung strukturiert auf und setzt diese in ein umsetzbares Konzept um. Dabei berücksichtigt er die grundlegenden Vorgaben bezüglich der Architektur und Plattformen des Unternehmens. Unter dem Begriff der Administration sind hier alle Bereiche zusammengefasst, die im Rahmen der Lieferantenpflege eine Rolle spielen. Zu nennen wären hier eine Beschaffungsabteilung, das Vertragsmanagement, das Supplier Management, die juristische Abteilung, das Controlling und die Buchhaltung. Je nach Größe der zu erstellenden Lösung und abhängig von den eigenen Kapazitäten und Fähigkeiten können ein oder mehrere Dienstleister die Umsetzung durchführen. Entwicklungsabteilung Tabelle 1: Interessensvertreter bei der Softwareentwicklung Falls vorhanden, kommen der Entwicklungsabteilung zwei Aufgaben zu. Zum einen definiert sie zusammen mit dem Kunden welche Lösung zu implementieren ist und zum anderen setzt sie diese Lösung (u.u. mit einem externen Dienstleister) um. Wird die gesamte Softwareentwicklung an einen Dienstleister vergeben, so bleibt die Problematik prinzipiell dieselbe. Gerade in einem solchen Fall sind funktionale und nicht-funktionale Anforderungen klar zu kommunizieren und zu beschreiben und in den Dienstleistungsvertrag aufzunehmen. Da der Auftraggeber wenig Einfluss auf die Umsetzungsphase hat, sollte der Auftraggeber sichers- Requirements & Claim Management in der IT Dr. Andreas Knaus, Rolf Reppert 7

9 tellen, dass er über den Fortschritt der Implementierung den Überblick behält. Ein abgestimmtes und vertraglich festgeschriebenes Verfahren mit dem Änderungswünsche zusammen mit dem Dienstleister abgearbeitet werden, sollte selbstverständlich sein. Darüberhinaus sollte aber auch regelmäßig eine Fortschritts- und Qualitätsprüfung insbesondere während der Entwicklung abgemacht sein, beispielsweise indem einzelne Modulabnahmen (anstatt nur eine Gesamtabnahme am Ende) vereinbart werden und der Auftraggeber schon in frühe Testphasen involviert wird. Auf diese Weise kann erreicht werden, dass wichtige Claims frühzeitig angezeigt werden. Sind externe Lieferanten involviert, bekommen die vertraglichen Aspekte natürlich mehr Gewicht. Im Streitfall kann es bis zu juristischen Schritten kommen, sodass, um dieses Risiko abzuschwächen, vor Vertragsabschluss mehr Aufwand in die Beschreibung des Leistungsgegenstandes investiert wird als bei rein internen Projekten. Allein einen juristisch wasserfesten Vertrag aufzusetzen kann eine Herausforderung sein. Der Aufwand lohnt aber in jedem Fall, da bei solchen Verträgen eben der Leistungsgegenstand, das Mengenmodell und das Änderungsverfahren die Kardinalpunkte für das Requirements und Claim Management festgelegt sind. Es stellt sich durchaus die Frage, warum man sich diese Disziplin nicht auch nach innen, zwischen Fachabteilungen und IT- Abteilung, aneignen sollte. Wie eingangs beschrieben, tut sich die IT offenbar schwer mit dem Management von Anforderungen und Forderungen. Ein Blick über den Tellerrand mag hier vielleicht hilfreich sein. Naheliegend ist die Baubranche: Bauprojekte sind sehr komplex und es müssen viele Lieferanten und Interessensgruppen (und deren Anforderungen) koordiniert werden. Die Vorzeichen sind also ähnlich. Da wesentlich mehr Bauprojekte als Softwareprojekte erfolgreich sind, kann man vom Requirements und Claim Management in der Baubrache evtl. etwas lernen. 3 RCM in der Baubranche Bauprojekte werden üblicherweise als Herstellungsprojekte definiert. Der Beginn ist meist, dass der zukünftige Bauherr für sich selbst oder zur Verwirklichung einer Geschäftsidee Flächen für verschiedene Nutzungen benötigt, etwa zur Unterbringung von Produktionsstraßen, Büros, Wohnungen, Geschäften oder vieles mehr. Dann wird der Bauherr sich überlegen, wie er am besten die benötigten Flächen bekommt. Dies geschieht in der Phase Projektentwicklung und kann unter Zuhilfenahme eines Projektentwicklers geschehen. Wenn das Ergebnis der Projektentwicklungsphase lautet, die beste Lösung ist der Bau eines Gebäudes (eine Lösung könnte auch das Anmieten geeigneter Flächen sein), dann beginnt ein Bauprojekt. Der erste Schritt würde bei Projekten größeren Umfangs die Beauftragung eines Projektmanagers sein, der bei der Auswahl der Fachleute zur Umsetzung (Architekt, Fachplaner, Baufirma etc.) hilft. Es folgen die Phasen Grundlagenermittlung, Vorplanung, Entwurfsplanung, Genehmigungsplanung, Ausführungsplanung, Vorbereitung der Vergabe, Vergabe, Requirements & Claim Management in der IT Dr. Andreas Knaus, Rolf Reppert 8

10 Ausführung, und schließlich Objektbetreuung und Dokumentation. Es endet gemeinhin mit der Fertigstellung und dem Bezug des Neubaus. Man könnte aber auch die Nutzung in der zu erwartenden Lebensdauer (20 bis 30 Jahre) eines Gebäudes als Teil des Projektes sehen. Grob zusammengefasst könnte man also von Planung, Ausführung und Nutzung sprechen, analog zu den Phasen Plan, Build und Run bei der Softwareentwicklung. In der folgenden Tabelle sind die einzelnen Phasen detaillierter erklärt. Bauprojektphase Beschreibung Projektentwicklung Grundlagenermittlung Vorplanung Entwurfsplanung Genehmigungsplanung Ausführungsplanung Vorbereitung der Vergabe Am Anfang stehen Überlegungen, wie ein Bedarf an Nutzungsfläche gestillt werden kann. Es sind Bedarfsuntersuchungen anzustellen, Funktionskonzepte aufzustellen und Baukonzepte zu prüfen. Danach sind Umsetzkriterien aufzustellen und Anforderungen zu definieren, die sich in unterschiedlichen Flächentypen ausdrücken lassen. Diese sind dann entsprechend zu quantifizieren. Es folgen Überlegungen zu Investitionskosten und Rentabilität (Grundstückskauf oder pacht usw.). Das alles dient dem Ziel zu entscheiden, ob überhaupt gebaut wird. Das Ergebnis ist die Definition der Bauaufgabe. Die Grundlagenermittlung wird bereits durch den Architekten (ggf. mit Unterstützung von Fachplanern und Sonderfachleuten) übernommen. Inhalt ist das Ermitteln der Voraussetzungen zur Lösung der Bauaufgabe durch die Planung, d. h. klären der Aufgabenstellung und erarbeiten von Entscheidungshilfen für die Auswahl anderer an der Planung Beteiligter. Die Grundlagenermittlung und die folgenden Phasen bis einschließlich der Objektbetreuung und Dokumentation sind durch die Beschreibung des Leistungsbildes der Objektplanung in der HOAI definiert. Diese Phase enthält die Projekt- und Planungsvorbereitung, mit der Analyse der Grundlagen, der Abstimmung und Kategorisierung der Zielvorstellungen, das Erarbeiten eines Planungskonzeptes einschließlich der Untersuchungen von alternativen Lösungsmöglichkeiten mit zeichnerischer Darstellung und Bewertung sowie das Klären der wesentlichen städtebaulichen, gestalterischen, funktionalen, technischen, bauphysikalischen, wirtschaftlichen und landschaftsökologischen Zusammenhänge. Es beginnt die Verhandlung mit den Behörden über die Genehmigungsfähigkeit. Auch eine erste Kostenschätzung wird vorgenommen. Die Entwurfsplanung (System- und Integrationsplanung) enthält das Durcharbeiten des Planungskonzeptes zum stufenweisen Erstellen der zeichnerischen Lösung, mit der Integration der Leistungen anderer Planungsbeteiligter. Jetzt werden bereits Details festgelegt. In dieser Phase wird die Kostenberechnung aufgestellt. In dieser Phase werden die Vorlagen für die nach öffentlich-rechtlichen Vorschriften erforderlichen Genehmigungen erarbeitet, Anträge auf Zustimmung im Einzelfall gestellt und die Planung vervollständigt und angepasst. Die Genehmigung durch die Behörden kann langwierig sein, deshalb wird oft eine Baugenehmigung etappenweise erteilt, um z. B. mit der Ausführung der Baugrube früher beginnen zu können. Die Ergebnisse aus der Entwurfs- und Genehmigungsphase werden in den Ausführungsplan eingearbeitet. Das Objekt ist zeichnerisch mit allen zur Ausführung notwendigen Einzelangaben und textlichen Ausführungen darzustellen. Die Ausführungsplanung wird noch während der Ausführungsphase fortgeschrieben. Es sind die Mengen als Grundlage für Leistungsbeschreibungen zu ermitteln und zusammenzustellen. Die Leistungsbeschreibungen sind mit Leistungsverzeichnissen nach Leistungsbereichen sortiert abzustimmen, zu koordinieren und aufzustellen. Requirements & Claim Management in der IT Dr. Andreas Knaus, Rolf Reppert 9

11 Bauprojektphase Vergabe Ausführung Objektbetreuung Dokumentation Betrieb / Nutzung und Beschreibung Die Verdingungsunterlagen sind für alle Leistungsbereiche zusammenzustellen. Anschließend kann ausgeschrieben werden und die eingehenden Angebote sind zu prüfen und auszuwerten. Mit den Bietern ist zu verhandeln, der Kostenanschlag ist aufzustellen und die Kostenkontrolle durch Vergleich mit der Kostenberechnung ist vorzunehmen. Die Vorbereitung der Vergabe und die eigentliche Vergabe werden gerne zusammengefasst und die beiden Phasen überlappen sich stark mit der Ausführungsphase. Um die Projektdauer zu verkürzen, ist es fast zur Regel geworden, dass die Vergabe parallel oder sogar vor der Ausführungsplanung gemacht wird. Das hat natürlich zur Folge, dass die Unsicherheiten wachsen und der Organisationsaufwand steigt. Nachdem die Planung steht und Nachunternehmer gebunden sind, kann mit der Ausführung begonnen werden. Diese ist dahingehend zu überwachen, ob die Anforderungen der Baugenehmigung oder Zustimmungen im Einzelfall, der Ausführungsplanung, den Leistungsbeschreibungen und den anerkannten Regeln der Technik eingehalten werden und ob alles innerhalb der Kosten und Termine bleibt. Ein Bautagebuch ist zu führen, Aufmaße und Abnahmen unter Feststellen von Mängeln sind durchzuführen und Rechnungen zu prüfen. Die Kosten sind laufend festzustellen. Anträge auf behördliche Abnahmen sind rechtzeitig zu stellen. Es erfolgen die Übergaben mit den erforderlichen Unterlagen (Bedienungsanleitungen, Prüfprotokolle, Auflistung von Gewährleistungsfristen usw.) an den Bauherren. Die Kostenkontrolle erfolgt durch Vergleich der Leistungsabrechnungen mit den Vertragspreisen und des Kostenanschlages. In dieser Phase fließt das meiste Geld, wenn man die Betriebsphase außer Acht lässt, und es ist der größte Personalaufwand notwendig. In dieser Phase erfolgt die Begehung des Objekts von allen Beteiligten zur Feststellung von Mängeln (ggf. vor dem Ablauf der Verjährungsfristen der Gewährleistungsansprüche bei langläufigen Projekten). Die Mängel müssen beseitigt werden. Sicherheitsleistungen werden freigegeben. Die zeichnerischen Darstellungen und rechnerischen Ergebnisse werden zusammengestellt. Die meisten am Bau Beteiligten verstehen den Abschluss dieser Phase als Abschluss des Bauprojekts. Dem Bauherrn, also dem Auslöser des Bauprojektes, steht nun das fertige Gebäude zur Verfügung. Er kann es selbst nutzen oder die getätigte Investition durch Miet- oder Pachteinnahen erwirtschaften und einen Gewinn anstreben. Ein Gewinn kann auch durch den Verkauf des Objektes entstehen, dann wäre allerdings das Projekt beendet. Ansonsten muss nun das Objekt unterhalten und der Betrieb finanziert werden. Tabelle 2: Phasen eines Bauprojektes Die Baubranche kann auf eine sehr lange Tradition zurückblicken (denken Sie beispielsweise an die Pyramiden in Ägypten) und konnte entsprechend über Jahrhunderte hinweg Regeln und Vorgehensweisen für komplexe Bauprojekte entwickeln und verbessern. Diese waren und sind auch notwendig, angesichts folgender, wichtiger Charakteristika: Bauprojekte haben hohe Budgets (z.b. Sony-Center in Berlin: ca. 750 Mio. EUR), sodass i.d.r. ein großes Interesse besteht, das Projekt erfolgreich abzuschließen und dabei das Budget nicht zu überschreiten. Bei Störungen entstehen schnell hohe Kosten, sodass diesen zeitnah und adäquat begegnet werden muss. Eine Beteiligung von mindestens Firmen bei einem Bauprojekt ist keine Seltenheit. Es muss sichergestellt werden, dass alle Beteiligten und deren Aktivitäten effektiv koordiniert werden. Die Sicherheit von Menschen während der Bauphase und lange nach der Fertigstellung während der Nutzungsphase muss jederzeit gewährleistet werden. Requirements & Claim Management in der IT Dr. Andreas Knaus, Rolf Reppert 10

12 Es ist nicht schwer nachvollziehbar, wie sich diese Rahmenbedingungen bei der Durchführung von Bauprojekten manifestiert: Intensive Projektplanung: Viele der Projektphasen (siehe Tabelle 2) sind hauptsächlich planerischer Natur. Gerade Anforderungen werden detailliert erfasst, bewertet, ausgewählt und spezifiziert und in entsprechend durchzuführende Bauaktivitäten und -aufträge übersetzt und bepreist. Fast hat es den Anschein, dass die Ausführungsphase nur einen kleinen Teil eines Bauprojektes ausmacht (in finanzieller Hinsicht ist das Gegenteil der Fall). Claim Management: Die Führung eines Bautagebuchs, Nachtragsmanagement (Behandlung von zusätzlichen Forderungen von Lieferanten) und Behinderungsmanagement sind üblich und z.t. sogar vorgeschrieben. Ohne rechtzeitiges Anzeigen und aktiv Werden haben die Auftragnehmer kaum eine Chance auf Anerkennung von Mehrleistungen bei Änderungen oder Behinderungen (sog. konkludentes Handeln ). Die wachsende Komplexität von Bauverträgen seit den 80er Jahren bedingt, dass sich das Claim Management weiter entwickelt. Ständiges Vergleichen mit Vertragsleistungen (also mit den Anforderungen) ist symptomatisch. Normenbewusstsein: Die vielen gesetzlichen Regularien, an die sich die Baubranche halten muss haben zu einem sehr ausgeprägten Normenbewusstsein und einer hohen Normenkonformität in der IT würde man sagen Compliance geführt. Auftragnehmer müssen die jeweils sie betreffenden Normen automatisch einhalten (und halten diese i.d.r. auch ein), ohne dass dies vom Auftraggeber ausdrücklich gefordert werden muss. 4 Was können wir von der Baubranche lernen? Der Vergleich mit der Baubranche hat natürlich Stärken und Schwächen. Man darf nicht vergessen, dass bestimmte Rahmenbedingungen der Baubranche in der IT einfach nicht oder nur bedingt gelten. Beispielsweise ist die Gefährdung von Menschenleben in der IT nur selten ein Thema bei einem Bauprojekt ist es aber absolut undenkbar, entsprechende Sicherheitsmaßnahmen und Qualitätskontrollen nicht zu berücksichtigen. Nichtsdestotrotz sind Analogien zwischen Bauprojekt und Softwareprojekt deutlich erkennbar und der Vergleich liefert interessante Gedankenansätze. Die Sprache des Kunden: Häufig wird das Argument vorgebracht, dass die Verständlichkeit von Softwareprojekten im Vergleich zu Bauprojekten recht niedrig sei, da Bauzeichnungen leichter zu entziffern seinen, als UML- und Flussdiagramme. In beiden Fällen ist es jedoch so, dass die Verständlichkeit von solchen Plänen und Dokumenten wesentlich von der Vorkenntnis des Lesers abhängt. All diese Arten der Darstellung sind für Spezialisten gedacht. Nicht zuletzt deshalb verwenden Architekten gerne grafisch aufbereitete Zeichnungen oder sogar Bauwerke in Miniaturform (Modelle) zur Visualisierung. Hier wurde erkannt, dass die Kunden nicht das Niveau der Spezialisten erreichen müssen, um einen Auftrag zu vergeben, sondern vielmehr die Spezialisten ihre Darstellung an den Kenntnisstand der Kunden anpassen müssen. So können Prototypen und deren iterative Weiterentwicklung ein deutlich besseres gegenseitiges Verständnis erzeugen und so die Kommunikation wesentlich vereinfachen. Rahmenbedingungen für Zusammenarbeit: Durch die Zusammenarbeit vieler Parteien an dem an sich schon komplexen Leistungsgegenstand entstehen hochkomplexe Gebilde sowohl bei einem Bauprojekt als auch bei der Softwareentwicklung. Für die Baubranche gibt der Gesetzgeber mit unterschiedlichen Regelungen einen definierten Rahmen vor. In der Baubranche sind die Phasen eines Bauprojektes in der HOAI definiert, allen Beteiligten bekannt und werden von allen Beteiligten gelebt. Das Ziel des Gesamtprojektes sowie die Aufgaben und Verantwortlichkeitsverteilung sind im Requirements & Claim Management in der IT Dr. Andreas Knaus, Rolf Reppert 11

13 Großen und Ganzen bei allen bekannt (die Berufsbezeichnungen erklären beispielsweise schon die Aufgaben im Projekt). Auch sind die einzelnen Ergebnisse der Projektphasen und die Übergabepunkte klar definiert. Dies ist in der Softwareentwicklung nicht der Fall. Die Folge dieses Sachverhaltes ist, dass im Rahmen eines Entwicklungsauftrages viele Regelungen individuell getroffen werden müssen, die in der Baubranche bereits allgemein gültig sind und angewandt werden. Ergebnisverantwortung: Wie bereits erwähnt sind wie bei der Softwareentwicklung auch in der Baubranche viele Rollen beteiligt. Allen voran sei der Architekt genannt. Er ist mit einer gewissen Planungshoheit für das Gelingen des Vorhabens verantwortlich. Anders als die restlichen Beteiligten, die im Rahmen ihrer Zuarbeit zum Projekt ganz individuellen Zielen folgen, hat der Architekt aufgrund seiner speziellen Funktion kein Interesse daran, die Planungsvorgaben nicht einzuhalten. Deshalb nimmt er neben dem Bauherrn von der Ideenfindung über eine konkretere Planung bis hin zum fertigen Objekt die wichtigste Rolle ein. Es ist dem Architekten auch untersagt, eine Ausführung selbst zu übernehmen oder maklerisch tätig zu werden. Die Architekten haben das Ständebewusstsein der Interessenvertreter des Bauherrn zu sein (Normalerweise ist die Planung und die Ausführung in einem Bauprojekt strikt getrennt, dass schafft automatisch einen Ausgleich der Interessen und Effizienz). Eine solche Koordinationsrolle ist im Bereich der Softwareentwicklung in der Regel nicht zu finden. Hier gibt es kaum eine zentrale Funktion, die mit einer Ergebnisverantwortung ausgestattet ist, aber aufgrund der speziellen Vertragssituation nicht oder nur kaum von einer Veränderung des Leistungsgegenstandes profitiert. Üblicherweise ist hier der Dienstleister stark in der Planungs- und Durchführungsverantwortung, was ihn in die Position versetzt, den Auftraggeber zu übervorteilen. Informationsfluss während Planungsphase: Um eine hohe Planungssicherheit zu gewährleisten, sollten neben einem zentralen Know-how Träger in einer Koordinationsfunktion (wie der Architekt beim Bauprojekt) möglichst alle beteiligten Parteien zu einem frühen Zeitpunkt in die Planung mit einbezogen werden. In der Realität ist es durchaus nicht immer gewährleistet, dass alle diese Parteien zur Formulierung der Anforderungen und Abnahmekriterien eingebunden werden. Da eine Anwendung jedoch nicht gekapselt betrachtet werden kann sondern in Wechselwirkung mit vielen anderen Komponenten (z. B. anderen Anwendungen, Systemen oder Prozessen) und nicht zuletzt mit fachlichen Geschäftsprozessen steht, müssen alle diese Sichtweisen berücksichtigt werden. Von der Baubranche lässt sich lernen, dass komplexe Vorhaben die Einbeziehung aller notwendigen Informationsgeber, Experten und Entscheidungsträger benötigen. Dies sollte in einer angemessenen Planungsphase geschehen, so dass alle Anforderungen aufgenommen und ggf. in unterschiedlichen Stadien geprüft werden können (z. B. funktionale Anforderungen anhand eines Prototyps). Erst die Einbeziehung aller Parteien sichert die Vollständigkeit der Anforderungen. Darüber hinaus bietet die Einbeziehung zu unterschiedlichen Planungsstufen die Möglichkeit der Qualitätssicherung durch alle involvierten Interessensvertreter. Leistungspflicht des Auftragnehmers: Im Rahmen eines Bauprojektes kommen den unterschiedlichen Parteien verschiedene Verpflichtungen zu. Anders als in den Individualverträgen bei einer Softwareentwicklung ergeben sich bereits aus der Funktion innerhalb des Projektes bzw. aus dem Leistungsgegenstand verschiedene Obliegenheitspflichten. Stellt sich beispielsweise in der Bauphase heraus, dass von einzelnen Dienstleistern zusätzliche Leistungen benötigt werden (z.b. die ursprünglich beauftrage Menge Mauerwerk hat sich vergrößert), so sind diese verpflichtet diese Zusatzleistung zum selben angebotenen Einheitenpreis auch zu liefern. Dies ist im Rahmen von Softwareentwicklungsprojekten nicht der Fall. Wird hier ein zusätzliches Modul benötigt, so wird in der Regel darüber gestritten, ob oder zu welchem Preis das Modul erstellt wird. Auch ist es einem Auftragnehmer in einem Bauprojekt nicht erlaubt, vor Abschluss der vereinbarten Leistungsphasen aus dem Bauprojekt auszusteigen (wohingegen ihm der Bauherr jederzeit kündigen darf). Streitfälle be- Requirements & Claim Management in der IT Dr. Andreas Knaus, Rolf Reppert 12

14 rechtigen den Auftragnehmer auch nicht, die Arbeiten einzustellen. Auch derartige Vereinbarungen kommen zwischen IT Kunde und IT Lieferant kaum vor. 5 RCM in der Softwareentwicklung Das Requirements und Claim Management spielt eine zentrale Rolle bei der Entwicklung von Individualsoftware. Ziel dieser Prozesse ist die frühzeitige Konkretisierung des Leistungsgegenstandes und die Sicherung des Projekterfolges. Die Anforderungen werden vor der Vergabe hinreichend genau definiert, so dass alle Beteiligten vor allem Auftraggeber und zukünftige Nutzer der Software wissen, welche Leistung zu erwarten bzw. zu erbringen ist. Diese Anforderungen dienen zusammen mit den sich daraus ableitenden Testfällen auch als Grundlage einer späteren Abnahme. Bei der Aufnahme der Requirements sind zwei wesentliche Herausforderungen zu lösen: Die fachlichen Fragestellungen müssen hinreichend beschrieben sein. Dies ist die eigentliche Bedarfsgrundlage für Entwicklung. Die Rahmenbedingungen müssen hinreichend beschrieben sein, die sich aus der späteren Betriebsumgebung, aus der Architekturvorgabe und aus sonstigen internen und externen Regelungen ergeben. Dieser zweite Punkt wird häufig stark vernachlässigt, da entweder die beteiligten Fachleute nicht über genügend technische Erfahrung verfügen, oder strukturierte Regelungen und Vorgaben fehlen, so dass die Entwicklung der Anforderungen lückenhaft und aufwändig sind. Eine besondere Schwierigkeit bei der Aufnahme der Anforderungen besteht darin, die Kosten für diesen Schritt in einem vernünftigen Verhältnis zu den zu erwartenden Einsparungen durch die bessere Planungsgrundlage zu halten. Schnell übersteigen die Aufwendungen den erreichbaren Nutzen. In der Regel werden die Anforderungen vom Auftraggeber erfasst. Das ist nachvollziehbar, da er allein ja den fachlichen Bedarf kennt. Der Auftraggeber ist allerdings meist relativ unerfahren. Dies hat zur Folge, dass der Auftraggeber nur unzureichend abschätzen kann, ob seine Anforderungsliste und der von ihm gewählten Detaillierungsgrad die Aufgabe hinreichend beschreibt. Typischerweise werden wesentliche Inhalte vergessen, oder der Mehrwert, der sich aus einer höheren Planungstiefe ergibt, nicht erkannt oder vernachlässigt. Eine solch wackelige Basis ist ein guter Nährboden für spätere Streitigkeiten, da sich Auftraggeber und Auftragnehmer über den ungenügend beschriebenen Leistungsgegenstand von vornherein nicht einig sein können. Nicht wesentlich besser der alternative Ansatz, die Anforderungsaufnahme als Aufgabe und damit als Bestandteil des Leistungsgegenstands für den Auftragnehmer zu definieren. Nach der Vergabe legt also der Dienstleister selbst fest, was zu erbringen ist, übernimmt also beide Rollen. Die des Planers und die des Umsetzers. Dies gibt ihm die Möglichkeit, die geschuldete Leistung in seinem Sinne auszulegen bzw. zu steuern. Bei einem Festpreisangebot ist dementsprechend ein relativ niedriger Leistungsumfang zu erwarten. Wohingegen bei einer aufwandsorientierten Vergütung eine besonders ausgedehnte Leistung zu erwarten ist. Gerade wenn größere Leistungen zu vergeben sind, haben die Auftraggeber also Angst, dass sie von einem Dienstleister übervorteilt werden. Häufig ist diese Angst auch nicht unbegründet, da die Auftragnehmer sich mit der Dienstleistung, die sie ja nicht zum ersten Mal erbringen, besser auskennen. Diese Informationsasymmetrie kann genutzt werden, um über ein entsprechendes Claim- Management im Verlauf der Leistungserbringung weitere Leistungen abzurechnen. Solche Situationen finden sich nicht nur in der hier vor allem angesprochenen Softwareentwicklung sondern auch Requirements & Claim Management in der IT Dr. Andreas Knaus, Rolf Reppert 13

15 in anderen Bereichen der Dienstleistungserbringung. So ist gerade die Outsourcingbranche stark in den Verruf geraten, die Unwissenheit bzw. die mangelnde Erfahrung der Kunden auszunutzen, um mit sehr engen Leistungsangeboten den Kunden später dazu zu zwingen, teure Erweiterungen und Anpassungen zu erwerben. Aber auch der Auftraggeber kann seine genauere Kenntnis über die Leistung und die Rahmenbedingungen (z.b. Mengengerüste) nutzen, um den Dienstleister wissentlich zu einer zu niedrigen Kalkulation zu veranlassen und so seinerseits die Informationsasymmetrie zu seinen Gunsten nutzen. Die Lösung für diese Herausforderung ist eine dritte Partei, die mit genügend Sachverstand die Definition und Beschreibung des Leistungsgegenstandes übernimmt und später auch bei der Umsetzung gutachterlich und schlichtend eingreifen kann. Auch wenn diese dritte Partei keine Ergebnisverantwortung hat, so ist ihre Rolle dennoch mit der eines Architekten bei einem Bauprojekt vergleichbar insofern, als dass sie keine Interessen hat den Projektverlauf zu ihren Gunsten zu beeinflussen. Eine präzise Anforderungsanalyse und Umsetzungsplanung führt auch zu einer besseren (weil realistischeren) Termin, Budget und Ressourcenplanung. Starre Rahmen durch zu enge Termine, zu lange Wartezeiten, zu knapp kalkulierte Preise oder durch ungenügend beschriebene Ergebnisse kurz durch ein unklares Verständnis der Ziele werden aufgehoben. Das Projekt erfährt eine Flexibilisierung, da das Projekt transparenter wird. Ein solche Flexibilisierung wirkt sich auch positiv auf das Requirements und Claim Management aus, da die gegenseitigen Erwartungshaltungen im Grunde klar sind. Änderungswünsche und Claims werden von beiden Seiten mit weniger Misstrauen betrachtet. Im Umgang mit externen Dienstleistern sollte auch geprüft werden, inwieweit ein zugrundeliegendes Entwicklungsmodell oder Projektmanagementmethodik sich auf die Kommunikation und die Kontrollierbarkeit des Auftragnehmers durch den Auftraggeber auswirken kann. Beispielsweise kann man sich auf die Prinzipien der sog. Agilen Softwareentwicklung 2 einigen, wodurch u.a. auch das Claim Management eine besondere Bedeutung zuteil wird. Selbst wenn schließlich die Anforderungen optimal und für alle verständlich festgehalten wurden, sorgen sich verschiebende Rahmenbedingungen oder Prioritäten dafür, dass im Rahmen der Umsetzung Veränderungen am Projektgegenstand und damit am Projekt selbst vorgenommen werden müssen. Solche Änderungen sind unvermeidbar, die Gründe vielfältig, beispielsweise: Neue Normen und Gesetze Geschäftspolitische Entscheidungen Veränderungen innerhalb der technologischen Betriebsumgebung 2 Agil durchgeführte Projekte haben folgende besondere Charakteristika: Koordination durch Selbstabstimmung Freigabe von Teilprodukten in kurzen Zeitabständen, um schnell und häufig Anwenderfeedback zu erhalten Dokumente sind weniger wichtig als der Code Wenige Rollen Menschen und Kommunikation haben Vorrang vor Prozessen und Werkzeugen Enge Zusammenarbeit mit Kunden ist wichtiger als andauernde Vertragsverhandlungen Funktionierende SW hat Vorrang gegenüber umfassender Dokumentation Schnelle Reaktion ist besser wie Festhalten an Plänen Requirements & Claim Management in der IT Dr. Andreas Knaus, Rolf Reppert 14

16 Bei Änderungen ist die Existenz und Nutzung eines definierten Change Request Verfahren sinnvoll und notwendig. Dieser Prozess definiert die Form in der ein Veränderungswunsch einzureichen ist. In einem festgelegten Verfahren und mit hinterlegtem Zeithorizont prüfen dann die Beteiligten die Auswirkungen des Änderungswunsches und legen Entscheidungsalternativen vor. Im Wesentlichen werden Terminverschiebungen und Auswirkungen auf Ressourcen und Kosten valider Umsetzungsalternativen geprüft. In diesem Schritt muss natürlich auch definiert werden wie die Aufteilung etwaiger Mehr- oder auch Minderbedarfe an Ressourcen erfolgen soll. Gerade die Kostenfrage spielt hier natürlich eine wichtige Rolle. Trotz aller Vorkehrungen lassen sich Unstimmigkeiten nicht immer vermeiden. So können unterschiedliche Auffassungen über anfangs formulierte Anforderungen oder anfangs abgelieferte Angebote später, in der Umsetzungs- und Abnahmephase, schnell zu einem Projektstillstand eskalieren. Genauso können ungenügend erbrachte oder auch eingeforderte Obliegenheitspflichten Streitigkeiten herbeiführen. Juristische Mittel helfen in dieser Situation übrigens nicht wirklich weiter. Üblicherweise machen beide Seiten im Streitfall von ihrem Leistungsverweigerungsrecht Gebrauch und das Projekt kommt zum völligen Stillstand. Der Auftraggeber erhält nicht die benötigte Leistung, und der Dienstleister erhält keine Entlohnung. Diese Situation ist für alle Beteiligten besonders unangenehm. Das Herbeiführen einer richterlichen Entscheidung auf Basis der Vertragslage hat meist nur einen aufschiebenden Effekt. Sinnvoller ist es, eine Schlichtung in die Wege zu leiten, die idealerweise schon a priori im Vertrag vereinbart wurde. Eine unabhängige Partei prüft dabei den Sachverhalt und stellt fest welche Erwartungen und Forderungen tatsächlich bestehen und von der jeweils anderen Partei auch so hätten verstanden und aufgenommen werden müssen. Auf diesem Wege lässt sich meist ein für alle Seiten tragbares Ergebnis erzielen. Vorrangiges Ziel dieses Vorgehens ist es, sich an den anfangs in der Angebots- und Vergabephase definierten Einigungspfad soweit wie möglich zu halten. Die gutachterliche und schlichtende Tätigkeit ist zu jedem Zeitpunkt der Leistungserbringung sinnvoll von der Feinkonzeption über die Umsetzungsphase mit Change Management bis hin zur Abnahme. 6 Fazit So vernünftig, gewinnbringend und zielführend ein effektives Requirements und Claim Management ist, so anspruchsvoll sind auch die Herausforderungen, um ein solches vor und während eines Projektes sicherzustellen. Requirements Management ist nicht nach dem Abschluss der Anforderungsanalyse abgeschlossen, genauso wenig wie ein Claim Management lediglich die Abnahme begleitet. Beides sind nebenläufige Prozesse, die Änderungen am Leistungsgegenstand oder an den Rahmenbedingungen bzw. Abweichungen von Sollergebnissen (die zu jeder Zeit im Projekt auftreten bzw. erkannt werden können) adäquat behandeln sollen. Letztendlich tragen diese Prozesse signifikant zum Projekterfolg bei. Folgende Punkte wurden als wichtig herausgestellt: Präzise Aufnahme von Anforderungen: Einerseits müssen die Anforderungen vollständig erfasst werden und müssen neben den funktionalen auch nicht-funktionale Anforderungen (z.b. Einhaltung von Vorgaben der IT Governance) enthalten. Der weit wichtigere Punkt ist, dass diese Anforderungen so klar formuliert sind, dass beidseitig ein klares Verständnis über den Leistungsgegenstand (und ggf. den Preis) besteht und Übervorteilung durch Informationsasymmetrien weitgehend aus- Requirements & Claim Management in der IT Dr. Andreas Knaus, Rolf Reppert 15

17 geschlossen sind. In der Baubranche zeigt sich, dass dadurch dass der Leistungsgegenstand schon detailliert beschrieben ist bei der Vergabe kaum mehr Fragen offen sind. Sorgfältige Planung: Durch eine detaillierte Umsetzungsplanung werden auch für das Requirements und Claim Management wesentliche Orientierungspunkte gesetzt. Änderungswünsche und Forderungen aufgrund von schlecht geschätzten oder abgegrenzten Terminen, Laufzeiten, Preisen oder Leistungen werden dadurch weitgehend vermieden. Adäquater Change Prozess: Veränderungen sind trotz akribischer Planung unvermeidbar (wie man im Vergleich mit der Baubranche sieht. Deshalb muss ein Change Prozess als inhärenter Bestandteil eines effektiven Requirements und Claim Managements verfügbar sein. Gerade das Claim Management steht mit dem Change Prozess in einer wichtigen Wechselwirkung. Ein Change (beispielsweise einer Anforderung) hat meist einen Change in einer Forderung zur Folge. Letztere wird durch ersteren legitimiert, aber auch nur dann, wenn er bezugnehmend auf ersteren angezeigt wird. Gutachter und Schlichter: Nimmt man auch hier die Baubranche als Beispiel, werden Anforderungen und Planungen idealerweise von einem erfahrenen Dritten übernommen, der einerseits genügend Fachkenntnisse besitzt, um die Requirements vollständig zu erfassen und auf der anderen Seite genügend Technologieverständnis mitbringt, um sie für einen Anbieter und Dienstleister nachvollziehbar und eindeutig zu formulieren. Darüberhinaus kann eine derartige Rolle mit der 3. Meinung die Qualität beispielsweise des Vertragswerks prüfen oder im Streitfall schlichtende Funktionen wahrnehmen. Achtet man bei Softwareprojekten auf diese Punkte, dann ist ein Projekterfolg in greifbare Nähe gerückt. santix bietet im Bereich des Requirements und Claim Management eine Reihe von Dienstleistungen an: Requirements Management: santix AG hat langjährige Erfahrung in der Aufnahme und Dokumentation von Anforderungen. Nicht zuletzt kommt der santix AG hierbei zu gute, dass sie über eine eigene Softwareentwicklungsabteilung verfügt, so dass sie aus eigener Erfahrung weiß, wie solche Dokumente geschrieben werden müssen, um als Vertrags- und Arbeitsgrundlage dienen zu können. Claim Management Durch das tiefe Know-how sowohl auf fachlicher als auch auf technischer Ebene tritt die santix AG bei Streitigkeiten als Gutachter und Schlichter auf. Hier wird Bewertet, ob eine Situation bzw. eine Anforderung sich aus der Vertrags- und Dokumentationslage hätte ableiten lassen müssen oder ob beispielsweise eine Obliegenheitsverletzung vorliegt. So können Schuld und Haftungsfragen geklärt werden, ohne einen langwierig und in der Sache selten erfolgsversprechenden juristischen Pfad einzuschlagen. Projektbegleitung und steuerung Erfahrene Projektleiter und manager begleiten Projekte von der Anforderungsaufnahme bis zur Abnahme und sichern so den Projekterfolg. Prozessberatung für Requirements, Change und Claim Management santix AG gibt ihre Erfahrungen und tiefen Prozesskenntnisse in den Bereichen Requirements, Change und Claim Management weiter und erarbeitet zusammen mit ihren Kunden passend zugeschnittene Vorgehensweisen. Requirements & Claim Management in der IT Dr. Andreas Knaus, Rolf Reppert 16 santix AG Freisinger Str. 9 D Unterschleißheim Tel. +49 (0) Fax +49 (0) santix austria Weißleiten 13 A-6393 St. Ulrich a.p. Tel.: +43 (0) santix schweiz AG Dufourstrasse 101 CH-8034 Zürich Tel.: +41 (0) Fax +41 (0) Alle Angaben in diesem White Paper sind ohne Gewähr und können jederzeit ohne Vorankündigung geändert werden. santix und das santix-logo sind eingetragene Warenzeichen in Deutschland und in der Schweiz. Andere Logos und Warenzeichen sind Eigentum ihrer jeweiligen Inhaber santix AG Version 11, Stand 11-09