Publikationen  ›  Change Management  ›  Erfolgreiche Projekte und ihr Umfeld

Erfolgreiche Projekte und ihr Umfeld: der Weg zum Ziel

Erfolgreiche Projekte und ihr Umfeld: Der Weg zum Ziel

Die Gefährdung von Projekten ist aktueller denn je. Projektabbrüche und Zeitüberschreitungen kosten nicht nur Geld. In der Zwischenzeit sehen die Banken das Projektrisiko als ein operationales Risiko an, das mit Eigenkapital zu hinterlegen ist. Softwareentwicklungs-Organisationen, die ihr Projektrisiko erfolgreich managen, können jedoch gezielt entwickelt werden.

Immer noch scheitern ca. 30% der Projekte, und im Schnitt werden Projekte doppelt so teuer wie veranschlagt [9][10]. Dies kostet nicht nur Geld oder bedeutet verlorene Chancen im Geschäft, sondern seit Basel II sehen die Banken die mit IT-Projekten verbundenen Risiken als operationale Risiken an, die mit Eigenkapital zu hinterlegen sind.

Erfolgreiche Software-Organisationen managen effektiv ihr Softwarerisiko. Zeiten, Kosten und Qualität werden so kontrolliert, dass Projekte im Zeit- und Kostenrahmen die erwartete Funktionalität liefern. Dies minimiert das Projektrisiko. Ergebnisqualität reduziert aber auch das Risiko, wenn die Software im Produktionsbetrieb ist. Darüber hinaus können Software-Organisationen, die das Risiko ihrer Projekte effektiv managen, die vorhandenen Informationen zu einer Verbesserung innerhalb der Projekte und der Software-Organisation nutzen.

Es gibt wohl kein Unternehmen, das keine erfolgreiche und effektive Software-Organisation möchte. Dennoch sprechen die Zahlen eine deutliche Sprache: nur wenige Unternehmen erreichen dieses Ziel. Viele Veröffentlichungen stellen dar, was für erfolgreiche Software- Organisationen notwendig ist. Diese werden jedoch weder durch Verordnungen noch durch einzelne Zielvorgaben erreicht – sie müssen vielmehr gezielt gestaltet und entwickelt werden. Das Ergebnis des Aufwands ist eine signifikante Senkung des Software-Risikos, ein Rückgang gefährdeter Projekte und eine deutliche Senkung der Fehlerraten. Damit stehen den Kosten massive Einsparungen im Faktor 1:5 gegenüber. Darüber hinaus wird Professionalität einer Softwareorganisation auf Dauer notwendig für ihr Überleben sein. Die Erfahrungen zeigen, dass eine bewusste und erfolgreiche Durchführung der organisatorischen Veränderungen möglich ist. In diesem Artikel stellen wir dar, welche Orientierungshilfen es gibt und was die Schlüsselfaktoren für den Erfolg sind.

Orientierungshilfe: Landkarten zur Gestaltung der Organisation

Eine der Grundlagen für den Erfolg ist die Nutzung bestehender Erfahrungen (best practices). Dies gilt sowohl für Projekte als auch für die Gestaltung von Software-Organisationen (wie z.B. eine IT-Abteilung). Solche bewährten Erfahrungen bieten Lösungsmuster, deren Nutzung Risiken reduziert sowie Zeit, Fehler und Kosten spart. Sie sind ebenfalls eine Möglichkeit, aus eigenen Erfahrungen und denen anderer Organisation zu lernen. Systematisch aufbereitetes Wissen kann als Landkarte verwendet werden, um die Maßnahmen im eigenen Unternehmen zu gestalten und zu organisieren und um bei dem Veränderungsprozess die Orientierung zu behalten.

So bietet z.B. das Capability Maturity Model (CMM – bzw. in der neuen Version CMMI für CMM Integrated) hervorragende Anhaltspunkte für die Gestaltung einer erfolgreichen Software-Organisation. CMMI ist oftmals als Zertifizierungs-Standard bekannt (“Unsere Organisation hat CMMI Level 3”), es kann aber ebenso als Checkliste verwendet werden, um herauszufinden, was eine erfolgreiche und effektive Software-Organisation auszeichnet.

Darüber hinaus zeigt CMMI mit seinen 5 Stufen (Reifegraden) einen bewährten Entwicklungspfad für Software-Organisationen auf. Der erste Schritt besteht darin, von ad-hoc geführten Projekten (Stufe 1) zu kontrolliert geführten und gesteuerten Projekten (Stufe 2) zu kommen. Erst dann macht der Aufbau und die Dokumentation eines gemeinsamen organisationsweiten Verständnisses über die Art und Weise der Projektarbeit Sinn (Stufe 3). Aufbauend auf dokumentierten Prozessen können dann Metriken zur vorausschauenden Projekt- und Organisationssteuerung etabliert werden (Stufe 4). Diese Metriken lassen sich wiederum zur Verbesserung der in den Projekten und der Organisation genutzen Prozesse verwenden (Stufe 5). Während der erste Schritt dazu führt, dass Kosten, Zeiten und Ergebnisse der Projekte eingehalten werden und das Projektrisiko signifikant gesenkt wird, führen die weiteren Schritte zu einer Verbesserung von Zeiten und Kosten und zu einer weiteren Senkung des Projektrisikos.

Im Vordergrund der Nutzung von CMMI sollte seine Verwendung als Ratgeber stehen. Dabei ist es wichtig, das Wissen pragmatisch und mit Blick auf die jeweilige spezifische Situation umzusetzen. Schließlich kommt der größte Nutzen aus der Realisierung einer erfolgreichen und effizienten Software-Organisation – und nicht aus der buchstabengetreuen Auslegung des Wortes. Am Ziel angelangt bietet die Zertifizierung die Möglichkeit, den Reifegrad in einer anerkannten Form nach außen hin in Form eines “Qualitätssiegels” zu dokumentieren – wobei diese Möglichkeit auch Ansporn sein kann.

Eine Alternative zu CMMI stellt ISO 15504 dar, auch als SPICE (Software Process Improvement and Capability Determination) bekannt. Ebenso wie CMMI kann es als Ratgeber und Orientierungshilfe für einen Verbesserungsprozess und die Gestaltung einer effizienten Software-Organisation genutzt werden. Da die Kriterien für eine solche Organisation unabhängig von der Art des Aufschreibens sind, ist es letztendlich egal, welche Version man verwendet. CMMI ist detaillierter und “schwerer” als SPICE. Im Gegensatz zu CMMI zeigt SPICE jedoch keinen Entwicklungspfad auf und ist international weniger verbreitet als CMMI.

Ein weitere Hilfestellung bei der Gestaltung einer erfolgreichen Software-Organisation kann das COBIT-Framework sein (Control Objectives for Information and Related Technology) [11]. COBIT wurde von Wirtschaftsprüfern entwickelt und bezieht sich auf die gesamte ITOrganisation; Projekte sind hier ein Bestandteil unter anderen. Im Vergleich zu CMMI oder SPICE geht es mehr in die Breite und weniger in die (Projekt-)Tiefe.

Organisationsentwicklung – als Projekt

Landkarten wie CMMI zeigen auf, was eine erfolgreiche Software-Organisation auszeichnet. Sie sagen aber nichts darüber aus, wie diese Dinge in einem Unternehmen eingeführt werden. Einer der häufigsten Fehler, die in Unternehmen gemacht werden, ist dass die für eine erfolgreiche Software-Organisation notwendigen Dinge nur gefordert, aber nicht organisatorisch realisiert und gelebt werden. Es reicht z.B. nicht, Änderungsmanagement zu fordern. Es reicht auch nicht, Änderungsmanagement zu definieren und dann zu sagen: “das sind jetzt die von allen einzuhaltenden Prozesse”. Vielmehr müssen Arbeitsabläufe gestaltet, Personen, Fähigkeiten und Kultur entwickelt und Ressourcen bereitgestellt werden. Mit anderen Worten, die Software Organisation muss bewusst gestaltet werden – gemeinsam von allen Beteiligten. Die Schlüsselfaktoren hierfür werden im folgenden vorgestellt.

Die bewusste Entwicklung einer effektiven und erfolgreichen Software-Organisation hat klare und messbare Ziele, die Veränderung ist zeitlich begrenzt sowie einmalig. Eine Organisationsentwicklung ist mithin ein Projekt – das selbstverständlich nach den Regeln eines ordentlichen Projektmanagements geführt werden sollte. Ein solches Organisations-Entwicklungs-Projekt muss in seiner Form vorleben, was es fordert: Professionalismus.

Erfolgsfaktoren für eine Veränderung der Organisation

Auslöser und Voraussetzung für jede organisatorische Veränderung ist eine zwingende Notwendigkeit, d.h. ein signifikanter und messbarer Nutzen – oder gar die Beseitigung einer Notlage. Nur wenn allen Beteiligten Notwendigkeit und Nutzen bekannt sind und beides akzeptiert wird, werden Mitarbeiter wie Management den erforderlichen langen Atem besitzen, Schwierigkeiten akzeptieren und Durststrecken überwinden.

Ebenso wichtig ist die Unterstützung vom Top-Management. Ein Macht- und Geld-Sponsor ist für jedes Projekt notwendig, aber für ein Organisations-Entwicklungs-Projekt muss der Sponsor über den gesamten Projektzeitraum sichtbar hinter dem Projekt stehen. Er gibt nicht nur das Geld, sondern das Projekt handelt und gestaltet die Organisation in seinem Namen und für ihn. Nur wenn der Sponsor dem Projekt die Macht zur Organisationsveränderung gibt, kann das Team erfolgreich sein. Der Sponsor gibt einen Teil seiner Macht an das Team ab, das in seinem Namen die organisatorischen Veränderungen vornimmt und nicht zuletzt neue Maßstäbe und Erfolgskriterien definiert und durchsetzt. Darüber hinaus ist die Präsenz des Sponsors notwendig, um die Bedeutung der Veränderung bei den Mitarbeitern darstellen zu können.

Des weiteren ist eine klare Richtung notwendig für eine klare Kommunikation und das langfristige Einhalten einer eingeschlagenen Richtung. Organisatorische Änderungen greifen langsam und tief. Wenn während des Projekts das Ruder hin- und hergerissen wird, wird nicht nur das Ziel verfehlt, sondern die unvollständigen Änderungen werden zu einer chaotischen und ziellosen Organisation führen. Um auf dem Weg der organisatorischen Veränderung die Orientierung zu behalten, können insbesondere die Landkarten wie z.B. CMMI helfen. Eine klare Richtung bedeutet auch, dass eine langfristige Ausrichtung und Kontinuität existiert. Nur wenn die Mitarbeiter das Vertrauen haben, dass ihre persönlichen Anstrengungen in die Gestaltung der neuen Software-Organisation von Dauer sind, werden sie sich engagieren.

Wenn die organisatorische Veränderung von hoher Bedeutung ist, muss der geschuldete Erfolg objektiv nachgewiesen werden können. Hierzu ist eine Messbarkeit der Ziele notwendig. Darüber hinaus ist eine Messung der Erfolge über den Projektverlauf wichtig, um das Projekt steuern und die klare Richtung einhalten zu können.

Ebenso ist eine Fokussierung erforderlich, um durch die Konzentration der Kräfte auf einen wohldefinierten Bereich schnelle Erfolge zu erzielen. Eine Möglichkeit ist, die Veränderungen zunächst auf nur ein Projekt zu anzuwenden. Eine weitere Anwendung dieses Prinzips ist eine stufenweise Verbesserung der Software-Organisation (wie sie z.B. von CMMI vorgeschlagen wird).

Ein weiter Schlüsselfaktor für den Erfolg ist die Unterstützung auf breiter Basis. Mit den Erfolgen in einem Kernbereich und der Begeisterung der Mitarbeiter kann die Veränderung in die Breite getragen werden. Die besten Fürsprecher für die Veränderung und Stützen bei der Überwindung von Schwierigkeiten sind überzeugte Mitarbeiter, die wiederum andere, ggf. eher vorsichtigere Kollegen mitnehmen. Außerdem ist die Unterstützung aller Beteiligten Voraussetzung dafür, dass die Verbesserungen langfristig getragen und gelebt werden.

Voraussetzung für eine breite Unterstützung ist ein aktive, geplante, gezielte und offene Kommunikation. Nur so können die Mitarbeiter aktiv beteiligt und informiert sowie ihre Unterstützung gewonnen und Gerüchten vorgebeugt werden. Die Kommunikation nimmt im gesamten Veränderungsprozess einen überdurchschnittlichen Raum ein und macht ca. 40 - 60% des gesamten Projektaufwands aus. Die Kommunikation muss häufig und dauerhaft stattfinden und sie muss in beide Richtungen gehen: Mitarbeiter müssen informiert werden, und das für die Veränderung verantwortliche Team muss ein wirkliches echtes offenes Ohr haben, um Informationen und Feedback aufnehmen zu können.

Ebenso mit der Unterstützung auf breiter Basis direkt verbunden ist ein direkter Nutzen für die Betroffenen. Diese müssen die organisatorischen Änderungen in die Praxis umsetzen, und sie werden dies nur dann tun, wenn es für sie einen direkten Nutzen bringt. Ein solcher Nutzen kann z.B. für den Projektleiter darin bestehen, dass ein Projekt deutlich einfacher und schneller aufgesetzt werden kann. Für Projektmitglieder können z.B. Muster für typische Projekt-Ergebnisse interessant sein. Zusätzlich sollten die Mitarbeiter durch persönliche Anreize motiviert und besondere Leistungen durch das Management honoriert werden. Ein abstrakter oder langfristiger Nutzen für das Unternehmen ist – so wichtig er sein mag – keine tragfähige Basis für die Umsetzung der Änderungen im täglichen Arbeiten.

Ein ebenso wichtiger Faktor für die breite Unterstützung ist die Akzeptanz des Veränderungs-Teams bei den betroffenen Mitarbeitern. Die Ansprüche sind hoch. Damit das Team von den Fachleuten der Software-Organisation akzeptiert wird, müssen die Beteiligten praktische Kenntnisse im Software Engineering haben – z.B. als Teammitglieder von Projekten. Projektleiter wiederum werden das Change Team nur akzeptieren, wenn es Kenntnisse im Projektmanagement hat. Weiterhin muss das Team Kenntnisse im Bereich der Organisations-Entwicklung haben, um sein eigenes Organisations-Veränderungs-Projekt erfolgreich planen und führen zu können. Und nicht zuletzt muss das Team den Spagat zwischen Top-Management als Macht- und Geld-Sponsor und den Mitarbeitern als den Umsetzern bewerkstelligen. Diese Kenntnisse sind selten alle in einer Person vereinigt, aber das Vorhandensein der Kenntnisse im Team ist von zentraler Bedeutung für den Erfolg der organisatorischen Veränderung.

Die zentralen Erfolgsfaktoren bei einer Organisations-Entwicklung

Die Einführung einer erfolgreichen und effektiven Software-Organisation ist nur die eine Seite der Medaille. Ebenso wichtig ist es, dass die aufgebauten Fähigkeiten der Software-Organisation dauerhaft unterstützt werden. Hilfsmittel für die Projekt-Teammitglieder müssen verbessert, Erfahrungen aus den Projekten zur Verbesserung der Fähigkeiten müssen genutzt werden. Die Etablierung dieser dauerhaften Unterstützungsfunktionen für die Software-Organisation sind ein wesentliches Ergebnis des Organisations-Entwicklungs-Projekts.

Die Gestaltung einer erfolgreichen Software-Organisation ist möglich

Die Kern-Erfolgsfaktoren zeigen, dass eine gezielte und professionelle Gestaltung einer erfolgreichen und effektiven Software-Organisation, die das Software-Risiko minimiert, eine Aufgabe für sich ist. Erfahrungen haben gezeigt, dass der Wechsel von einer CMMI Stufe zur nächsten im Schnitt 2 Jahre dauert. Das Ergebnis des Aufwands ist nicht nur eine signifikante Senkung des Software-Risikos und der Softwarekosten, sondern die Professionalität einer Software-Organisation wird auf Dauer notwendig für ihr Überleben sein. Die Erfahrungen zeigen, dass eine bewusste und erfolgreiche Durchführung der organisatorischen Veränderungen möglich ist – und worauf es dabei ankommt.

Referenzen

  1. C. Raak: CMM Überblick, wibas GmbH, Darmstadt, 2000
  2. Mark C. Paulk, Bill Curtis, Mary Beth Chrissis, Charles V. Weber: Capability Maturity Model SM for Software, Version 1.1, Technical Report CMU/SEI-93-TR-024, ESC-TR-93-177, Pittsburgh, 1993
  3. J. Bamberger: Essence of the Capability Maturity Model, IEEE Computer Society, 1997
  4. Mark C. Paulk, Charles V. Weber, Suzanne M. Garcia, Mary Beth Chrissis, Marilyn Bush: Key Practices of the Capability Maturity Model SM, Version 1.1, Technical Report CMU/SEI-93-TR-025, ESC-TR-93-178, Pittsburgh, 1993
  5. CMMI Product Team: Capability Maturity Model Integration (CMMI) Version 1.1, Technical Report CMU/SEI-2002-TR-012, ESC-TR-2002-012, Pittsburgh, 2002
  6. K. E. Emam, J.-N. Drouin, W. Melo: SPICE – The Theory and Practice of Software Process Improvement and Capability Determination, IEEE Computer Society, Washington, 1998
  7. Software Engineering Institute: Process Maturity Profile, http://www.sei.cmu.edu/sema/profile.html, Pittsburgh, 2001
  8. Bundesverband öffentlicher Banken Deutschlands (Hrsg.): Aktuelles, Ausgabe II/2001, Seiten 12-13
  9. J. Johnson: Turning Chaos into Success, in: Software Magazin, Dezember 1999
  10. The Standish Group (Hrsg.): Chaos Chronicles Version II, 2001
  11. COBIT Steering Commitee and Information Systems Audit and Control Foundation / IT Governance Institute (Hrsg.): Complete COBIT 3rd Edition, 2000
  12. D. W. Hutton: The Change Agents’ Handbook, ASQ Quality Press, 1994
  13. J. P. Kotter: Leading Change, Harvard Business School Press, 1996
  14. J. Herbsleb, A. Carleton, J. Rozum, J. Siegel, D. Zubrow: Benefits of CMM based Software Process Improvement, Software Engineering Institute, Technical Report CMU/SEI-94-TR-013, ESC-TR-94-013, Pittsburgh, 1994

Tweet… Facebook… LinkedIn… Xing… Google Bookmark… Delicious Bookmark… RSS-Feed