Kategorie-Archiv: IT-Governance

Wenn eine Prozesslandkarte erstellt wird, stellt sich immer wieder die Frage, wie viele Geschäftsprozesse eigentlich notwendig sind, um ein Unternehmen vollständig zu beschreiben. Die Zahlen schwanken zwischen 20 und mehreren Hundert. Auch hier gilt „Weniger ist mehr“, aber wie kann man die Anzahl der Prozesse reduzieren ohne die notwendige Aussagekraft zu verlieren.

Meine Erfahrung ist, dass die Trennung der Prozesse im engeren Sinne – also der organisatorischen Abläufe – und der Geschäftsregeln dieses Dilemma elegant und effizient löst. Das Verhältnis dieser beiden Modelle kann man mit einer Analogie gut veranschaulichen.

Organisatorische Abläufe werden in möglichst wenigen Prozessen darstellt, unterschiedliche Prüf- und Bearbeitungsregeln in den Prozessschritten werden in Geschäftsregeln abgebildet. So ist z.B. die Bearbeitung verschiedener Produktvarianten einer Versicherung in einem einzigen Geschäftsprozess abbildbar, da sich der organisatorische Ablauf (der „Workflow“) nicht unterscheidet, nur der Inhalt und das Ergebnis der jeweiligen Aktivität sind unterschiedlich. Und ob z.B. ein Schaden versicherungsrelevant ist, wird als Weichenstellung zwischen zwei Ablaufvarianten modelliert, die Entscheidungskriterien selbst sind Inhalt der Geschäftsregeln. Ebenso ist die Entscheidung, welche fallbezogenen Informationen beschafft werden müssen, durch Geschäftsregeln determiniert, der Prozess abstrahiert aber von diesen Inhalten und ist daher für unterschiedlichste Fälle gleich.

Effizient wird das allerdings erst dann, wenn man im Rahmen der IT-Implementierung eine geeignete Business Rule Engine einsetzt. Dazu habe ich schon in einem anderen Blog-Beitrag mehr gesagt ->.

Hier noch eine Leseliste von empfehlenswerten Büchern zur Geschäftsprozessoptimierung.

Noch ein Hinweis zu Prozessanalysetools und Methoden: Interessant finde ich die „PICTURE-Methode“, die mit einem vordefinierten Set von Prozessbausteinen arbeitet. Dadurch ist die vergleichende Analyse von Prozessen über die gesamte Prozesslandschaft möglich. Will man also z.B. wissen, in welchen Prozessen Zahlungen entgegengenommen werden oder wo Transporte von physischen Gegenständen stattfinden, geht das quasi mit einem Mausklick (ein wenig mehr und die Disziplin der Prozessmodellierung ist natürlich auch Voraussetzung dafür). Andere Prozessanalysetools bieten mehr Freiheit, im Ergebnis sind allerdings die Prozesse nicht unmittelbar miteinander vergleichbar. Mehr dazu hier,

Seit dem agilen Manifest 2001 hat sich vieles geändert. Es gibt neue Kommunikationsplattformen wie Skype, webbasierte Kollaborationstools und die Cloud. Softwareauslieferungen erfolgen über das Internet mit minimalem Aufwand und in beliebig kurzen Zyklen etc. etc. Kaum denkbar, dass all das keinen Einfluss darauf hat, wie Softwareentwicklung erfolgreich gestaltet werden kann.

Neben der technischen Revolution hat sich auch die Softwareentwicklungsbranche völlig verändert. Immer noch gibt es die großen Produktlieferanten wie Microsoft, SAP u.a. und große Dienstleister wie accenture, Atos, CSC u.a. und Unternehmen die beides abzudecken versuchen wie IBM, HP u.a. Daneben gibt es allerdings einen neuen Typ von Unternehmen unterschiedlicher Größe, die Apps entwickeln und auf den Markt bringen und deren Geschäftsmodelle sich völlig von dem der klassischen Softwareunternehmen unterscheiden. Deren Vertriebsweg sind vor allem der App-Store von Apple sowie Google-Play, sie finanzieren sich nur zu einem relativ geringen Teil über Lizenzen und neue Releases folgen in ungleich kürzeren Abständen aufeinander als bei den „traditionellen“ Softwareunternehmen. Das Wasserfallmodell ist für diese Unternehmen jenseits jeder Relevanz, da sie typischerweise mit möglichst wenig Features so schnell wie nur möglich auf den Markt gehen. Christoph Keese zitiert in seinem Buch „Silicon Valley“ einen erfolgreichen Startup-Gründer: „Es geht darum, möglichst rasch ein möglichst gutes Produkt auf den Markt zu bringen. Das Produkt muss schlank sein. Es muss die Kernfunktionen enthalten, mehr nicht“.

Wenn man die Zusammenarbeit von Anwendern und Entwicklern als zentralen Erfolgsfaktor der Softwareentwicklung sieht wie es das agile Manifest tat, müssen die Regeln von 2001 heute neu geschrieben oder zumindest neu interpretiert werden.

Das Dogma von kleinen, autonomen Teams die tägliche Standup-Meetings nach einem streng geregelten Ritual abhalten, kann in weltweit agierenden Unternehmen nicht aufrecht erhalten werden. Zusammenarbeit von Teams, die auf unterschiedliche Kontinente verteilt sind und dazu noch unterschiedliche Zeitzonen stehen dem oft entgegen. Virtuelle Scrum-Boards, Webkonferenzen mit Screen-Sharing und Kollaborationsplattformen müssen genutzt werden.

Auch das Rollenbild muss flexibel gehandhabt werden, für komplexe Produkte wird die Rolle des Product Owners nicht von einer einzigen Person wahrgenommen werden können. Auch Elemente traditioneller Projektleitung wird man in Projekten mit hohem Risikopotenzial und mit unterschiedlichen Unternehmen, die daran beteiligt sind, nicht vermeiden können. Termin- und Budgetaussagen fließen nun einmal in Verträge ein, für deren Einhaltung jemand die Verantwortung übernehmen muss.

Fundamental ist das Kommunikationsproblem zwischen Anwendern und Entwicklern, das oft zu Themenverfehlungen führt. Es wird eine Implementierung ausgeliefert, die an den wahren Bedürfnissen der Anwender vorbeigeht. Es ist nun einmal so, dass erst in der Auseinandersetzung mit funktionierender Software  erkennbar wird, welche Funktionen tatsächlich einen Wertbeitrag für das Geschäft des Kunden leisten und welche bestenfalls nice-to-have sind. Will man mit neuer Technologie die Geschäftsprozesse oder gar das Geschäftsmodell verändern, gilt dies umso mehr, ohne agile Vorgehensweisen wird man hier nicht zum Ziel kommen.

Tragfähige Architekturentwürfe für große Anwendungssysteme mit zahlreichen Schnittstellen können nicht basisdemokratisch erarbeitet werden, es müssen also top-down- und bottom-up-Vorgehensweisen intelligent miteinander kombiniert werden. Water-Scrum-Fall ist ein lustig formulierter, jedoch absolut ernst zu nehmender Ansatz eines hybriden Vorgehensmodell. Am besten hilft hier meiner Meinung das bei uns zu wenig bekannte DSDM weiter.

Dass im Wasserfallmodell der Umfang fix und Budget sowie Zeitplan variabel sind während agiles Vorgehen das Budget und den Zeitplan fixiert und den Umfang variabel hält, macht agile Projekte für stark budgetgetriebene Unternehmen (und das ist nicht nur die öffentliche Verwaltung) leichter handhabbar.

Agile Projekte eignen sich nicht für Werkverträge, damit entstehen rechtliche Probleme wenn es um Nichterfüllung oder Mangelleistung in einem Projekt geht. Auch Haftungsfragen können nicht wirksam abgebildet werden. Durch geeignete Rahmenverträge und Fokussierung auf die vertragliche Regelung der Realisierungsphase kann dem gegengesteuert werden. Ein Patentrezept für den Erfolg agiler Projekte gibt es allerdings genauso wenig wie für andere Formen der Projektabwicklung.

PMI, das weltweit führende Standardisierungsinstitut für Projektmanagement misst agilen Methoden hohe Bedeutung bei. Der PMI Agile Certified Practitioner (PMI-ACP) ist mit weltweit ca. 7.000 zertifizierten Personen gegenüber dem Project Management Professional (PMP) mit über 600.000 Zertifizierten noch in den Anfängen, die Wachstumskurve zeigt aber steil nach oben.

Agile Methoden, dass kann ich aufgrund meiner eigenen Erfahrung und dem Erfahrungsaustausch mit anderen Projektmanagern gesichert behaupten, bieten in der Praxis bei richtiger Anwendung deutlich bessere Voraussetzungen für den Erfolg als traditionelle Vorgehensmodelle, die in der Planungsphase eine Sicherheit vorgaukeln, die am Ende sehr oft nicht eingelöst werden kann.

^{Bildquelle: www.realworldscrum.de}

Hier ein Beispiel, das ich aus eigener Erfahrung kenne, wobei ich im Sinne der Anonymisierung offen lasse, in welcher Rolle ich hier beteiligt war. Es ist ein Beispiel dafür, wie durch gezielte Suche nach dem wirkungsvollsten Punkt (und das ist nichts anderes als das Ansetzen am aktuellen Engpass) sehr rasch zur Problemlösung führen kann.

Ein Unternehmen hatte sich nach einem gescheiterten und Projekt, das gemäß einem klassischen Wasserfallmodell durchgeführt worden war, für ein agiles Vorgehen entschieden. Dieses war weitgehend am Scrum-Modell ausgerichtet, es wurde auf Grundlage von User Stories entwickelt, die mit Story Points bewertet wurden. Es gab fixe Iterationszyklen („Sprints“) von 6 Wochen Dauer. Die Softwareentwicklung erfolgte durch einen externen Dienstleister, der zum gleichen Konzern gehörte, die Zusammenarbeit erfolgte allerdings trotzdem in einem typischen Kunden-Dienstleister-Verhältnis. Derselbe Dienstleister, überwiegend sogar mit denselben Personen, hatte auch das gescheiterte Projekt ausgeführt.

Ursachenanalyse darf nicht an der Oberfläche bleiben

Aufgrund der problematischen Vorgeschichte wurde ein externer Projektmanager mit seinem Team als Projektcontroller hinzugezogen. Informell war mit dem Auftraggeber besprochen, dass dieser Auftrag sehr weit zu verstehen sei und letztlich auch ein Risikomanagement als Frühwarnsystem für auftauchende Probleme beinhalten sollte.

Auch wenn das Vorgehen offiziell nicht am Paradigma des Extreme Programming ausgerichtet war, sollten doch Vertreter der Anwender regelmäßig den Entwicklern vor Ort für Auskünfte zur Verfügung stehen. Bald häuften sich die Klagen von Seiten des Dienstleisters, dass entgegen den Vereinbarungen von Seiten des Kunden nicht genügend fachkundige Personen zur Verfügung gestellt würden und dadurch der Projekterfolg, jedenfalls aber Termin und Aufwand gefährdet seien.

Das Projektcontrolling war gefordert, dieses Risiko zu prüfen, hinsichtlich seiner Relevanz zu beurteilen und geeignete Maßnahmen vorzuschlagen.

Man durfte nicht davon ausgehen, dass das berichtete Problem tatsächlich der Engpass des Projektes war. Eine Möglichkeit war etwa, dass es nur ein Vorwand war, um das Budget zu erhöhen. In diesem Fall wäre zu prüfen, ob der Mehraufwand tatsächlich gerechtfertigt wäre und dann auf Top-Management-Ebene eine Vereinbarung zu treffen. Aufgrund der Konzernverflechtung und des agilen Vorgehens wäre das Beharren auf einem angebotenen Preis wenig sinnvoll bzw. durchsetzbar gewesen, die Konzernleitung legte Wert auf eine verursachungsgerechte Verrechnung von Aufwänden zwischen den Konzerngesellschaften.

Ein erstes Screening ergab keine Indikatoren für eine (vom Auftraggeber nicht registrierte) Erweiterung der fachlichen Anforderungen oder für Effizienz‑ oder Know-How-Defizite auf Seiten der Entwickler. Vielmehr stellte sich heraus, dass das berichtete Problem tatsächlich zutraf. Die Ursache war allerdings nicht fehlende Bereitschaft auf Seiten der Anwender. Diese berichteten, dass sie anfangs regelmäßig vor Ort waren, es für sie allerdings nichts zu tun gab bzw. kein Ansprechpartner verfügbar war, weil alle in Frage kommenden Personen mit ihren Entwicklungsaufgaben ausgelastet waren.

Da die Anwendervertreter nicht von ihrem Tagesgeschäft entbunden waren, zogen sie es bald vor, die Anwesenheiten vor Ort zu reduzieren, was für sie als Vertreter des Kunden problemlos möglich war und zunächst vom Entwicklerteam eher dankbar („Kunde stört“) und daher ohne Widerspruch zur Kenntnis genommen wurde. Als dann allerdings bei den Abnahmen Probleme auftauchten, weil Anforderungen unvollständig oder aufgrund von Missverständnissen falsch umgesetzt worden waren, erinnerte sich das Management des Dienstleisters an die Mitwirkungspflichten des Kunden und tatsächlich waren diese nachweislich nicht im vereinbarten Ausmaß erbracht worden.

Die Lösung liegt im Detail und ist oft überraschend einfach

Die Lösung war überraschend einfach. Es wurde für die Anwesenheit ein genauer „Stundenplan“ vereinbart, dies beinhaltete auch eine Vorschau auf die im Fokus stehenden Themen. So konnte die Anwesenheit von Anwendern vor Ort selektiv gesteuert werden und gleichzeitig war es nachvollziehbar, wenn entweder die Anwender nicht erschienen oder die Ansprechpartner von Seiten der Entwicklung nicht verfügbar oder nicht gut vorbereitet waren. Ein Mitarbeiter des Projektcontrollings war in den ersten Wochen regelmäßig vor Ort, um diesen Prozess zu steuern und zu kontrollieren, dies war allerdings schon nach wenigen Monaten nicht mehr notwendig bzw. verlagerte sich der Tätigkeitsschwerpunkt des Controllers auf die Testkoordination als Mittel der Fortschrittskontrolle.

Das Projekt konnte erfolgreich abgeschlossen werden, alle Parameter lagen im angestrebten Bereich. Die Identifikation des wirkungsvollsten Punktes hat es in diesem Fall ermöglicht, mit sehr geringem Aufwand eine große Wirkung zu erreichen.

Hier wieder ein Fallbeispiel, wie durch engpassorientiertes Projektmanagement Blockaden in der Projektarbeit beseitigt werden konnten. Die Details der Fallbeschreibung sind so neutralisiert, dass ein Rückschluss auf das betroffene Unternehmen nur für jene möglich ist, die unmittelbar beteiligt waren.

In einem Organisationsentwicklungsvorhaben hatte man aufgrund von Erfahrungen in der Vergangenheit ein straffes Entscheidungsmanagement definiert. Jedes Arbeitspaket sollte im Lenkungsausschuss abgenommen werden, Richtungsentscheidungen in der Projektarbeit sollten ebenfalls im Lenkungsausschuss getroffen werden. Das Vorhaben war richtigerweise als Programm aufgesetzt und durch eine umfassende Planung gut strukturiert. Schon bald zeichnete sich allerdings ab, dass der Lenkungsausschuss unmöglich alle ihm zugedachten Entscheidungen würde treffen können. Das dafür notwendige Know-How und auch die Entscheidungskompetenz waren zwar vorhanden, nur war es nicht machbar, diese Personen mehrere Tage pro Monat für Lenkungsausschuss-Sitzungen zur blockieren.

Anzumerken ist auch, dass es in einem Projekt des Programms zu gravierenden Problemen bei der Besetzung der Projektleitung kam, zwei Projektleiter und auch ein Stellvertreter legten diese Funktion während der Laufzeit des Projektes zurück bzw. wurden von ihrer Funktion abberufen. Da es sich um ein Schlüsselprojekt des Programms handelte, gefährdete dies den Erfolg des Gesamtvorhabens. Letztlich haben erst der dritte Projektleiter und der zweite Stellvertreter des Projektleiters das Projekt zum Abschluss gebracht.

Das Programm-Management-Office, das von einem Team unternehmensexterner Projektmanager geführt wurde, war gefordert, geeignete Lösungen zur Erfolgssicherung des Programms zu finden.

Der Wunsch der Geschäftsleitung nach einer straffen Steuerung der Projektarbeiten durch das Top-Management (insbesondere durch den Alleingeschäftsführer des Unternehmens) sowie nach einer zeitgerechten Erreichung der Projektziele war als Fixpunkt aller Überlegungen zu betrachten und musste daher als Rahmenbedingung jedes Lösungsansatzes beachtet werden. Eine Ausweitung des Kreises der Entscheider über den Kreis des Lenkungsausschusses hinaus war weder gewünscht noch hätte dies die Qualität und Verbindlichkeit der Entscheidungen verbessert.

Jedes Projekt adressierte einen Leistungsbereich des Unternehmens, der dafür in der Linie zuständige Bereichsleiter war im Lenkungsausschuss vertreten. Es war auch klar, dass die Umsetzung der Projektergebnisse in der Linie erfolgen würde. Das entscheidende Kriterium für den Erfolg des Projektes war daher die Sicherung der faktischen Umsetzung der Ergebnisse durch die Linienorganisation. Also war eine frühe und intensive Einbindung der Linienverantwortlichen in die Projektarbeit wünschenswert. Andererseits waren die Aufgabenstellungen der einzelnen Projekte nicht auf einen Leistungsbereich zu reduzieren (sonst hätte man sich die Programmorganisation sparen können) und es bestanden wechselweise inhaltliche Abhängigkeiten zwischen den Projekten, die es erforderten, die Befassung des gesamten Lenkungsausschuss zu sichern.

Zur Lösung des zentralen Engpasses wurde ein „Mentorenmodell“ eingerichtet. Jedes Projekt erhielt jeweils zwei Mitglieder des Lenkungsausschusses als Mentoren, die im Vorfeld jeder Lenkungsausschuss-Sitzung die Arbeitsergebnisse einem Review unterzogen und bei Bedarf auch für konkrete Problemlösungen als Experten und Sparringpartner zur Verfügung standen. Die Wahl der Mentoren erfolgte so, dass für die Umsetzung der Projektergebnisse hauptverantwortliche sowie die am stärksten durch Schnittstellen bzw. Wechselwirkungen betroffene Führungskraft als Mentoren zur Verfügung standen.

Es wurden standardisierte Berichtsformate für Entscheidungsvorlagen und Ergebnisberichte definiert, die eine Woche vor jeder Sitzung des Lenkungsausschusses allen Mitgliedern des Lenkungsausschusses übermittelt wurden. An der Erstellung dieser Vorlagen wirkten die jeweils zuständigen Mentoren aktiv mit. Diese Ergebnisberichte und Entscheidungsvorlagen wurden in einer vorbereitenden Sitzung des Lenkungsausschusses am Vormittag abgestimmt. In diesem Kreis konnten etwaige Divergenzen zwischen den Mitgliedern des Lenkungsausschusses offen diskutiert und eine gemeinsame Linie gefunden werden.

Nach einer gemeinsamen Mittagspause bereits mit allen Projektleitern und deren Stellvertretern fand die eigentliche Lenkungsausschuss-Sitzung statt, in der die Projektleiter ihre Berichte erstatteten und dazu die Stellungnahme des Lenkungsausschusses erhielten. In fast allen Fällen wurden die Entscheidungsanträge angenommen, in einigen Fällen kam es zu Abweichungen aufgrund von Wechselwirkungen bzw. mangelnder Absicherung der Ergebnisse, die in der vorbereitenden Sitzung des Lenkungsausschusses erkannt worden waren. Mit diesen Fällen so umzugehen, dass sowohl die Motivation der Projektleiter als auch die Autorität der Mentoren nicht beschädigt wurde, war Aufgabe des Geschäftsführers und Leiters des Lenkungsausschusses; hier hätte ein neuer Engpass entstehen können, was in diesem Fall aufgrund der hohen sozialen Kompetenz der verantwortlichen Personen nicht auftrat.

Alle diese Maßnahmen hätten allerdings nicht ausgereicht, den Erfolg des Programms zu sichern, wenn nicht beim ersten Auftreten von Problemen in einem der Projekte ein methodisches Coaching des Projektteams installiert worden wäre. Diese Coaching-Funktion wurde durch einen Berater aus dem Team des Programm-Management-Office wahrgenommen, der über umfassende Expertise im Themenbereich dieses Projektes verfügte. Diese Maßnahmen konnte auch bei den dann auftretenden Wechseln der Projektleitung die Kontinuität der Projektarbeit sichern und gleichzeitig wurde auch die Rolle der Mentoren, die als Mitglieder des Lenkungsausschusses nicht in die Details der Projektarbeit hineingezogen werden durften, gewahrt. Selbst wenn man diese Vermischung von Auftraggeber‑ und Auftragnehmer-Funktion in Kauf genommen hätte, wäre es schon aus Kapazitätsgründen nicht möglich gewesen, das Coaching der Projektarbeiten durch einen Mentor zu leisten.

Der anfangs evidente Engpass war die Entscheidungskapazität des Lenkungsausschusses, dem durch die Implementierung eines Mentorenmodells begegnet wurde, das den aus Sicht der Projekte absehbaren externen Engpass (nämlich die Akzeptanz und Umsetzbarkeit der Ergebnisse in der Linienorganisation) wirkungsvoll beseitigte und gleichzeitig auch Ressourcen zur Bewältigung der im Verlauf der Projektarbeit auftretenden interne Engpässe bereitstellte. Allerdings wurden im Sinne der „schiefen Schlachtordnung“ gleichzeitig auch Maßnahmen getroffen, die absehbare künftige Engpässe adressierten, so z.B. das Coaching eines Krisen-Projektes. Hinweis: externer und interner Engpass sowie schiefe Schlachtordnung sind Konzepte aus der EKS-Strategie.

Es gelang, das Programm mit einer geringfügigen terminlichen Verzögerung und etwas erhöhtem Aufwand erfolgreich abzuschließen, der Nutzen für das Unternehmen konnte durch die hohe Akzeptanz und interdisziplinär abgesicherte Qualität der Ergebnisse realisiert werden.

Ein Anwendungsentwicklungsprojekt, das Teil eines seit Jahren laufenden „Programms“ zur umfassenden Modernisierung der Softwarelandschaft eines großen Dienstleistungsunternehmens war, war mit immer neuen Aufwandserhöhungen und Terminverschiebungen konfrontiert. Die Anwendungsentwicklung samt Analyse erfolgte durch ein großes Softwarehaus, das Lasten- und Pflichtenheft hatte ein anderes Unternehmen erarbeitet. Das Vorgehen war als Wasserfallmodell mit Fixpreis vereinbart, jede Anforderungsänderung war daher als Change Request zum Pflichtenheft abzuhandeln.

Als der Projektleiter auf Seiten des Auftraggebers das Handtuch warf, übernahm diese Funktion ein mit dem beauftragenden Unternehmen durch mehrere Vorprojekte vertrauter externer Projektmanager, da interne Ressourcen nicht zur Verfügung standen.

Eine Runde von Interviews mit wichtigen Stakeholdern des Projektes sowie auch schon die ersten Projektsitzungen zeigten ein verblüffend hohes Ausmaß an Change Requests, über deren Berechtigung mit viel Emotion diskutiert wurde. Ein Check der Vertragsgrundlagen zeigte, dass das Pflichtenheft nur wenige Konkretisierungen gegenüber dem Lastenheft enthielt und daher viel Spielraum für Interpretationen blieb. Auf Seiten des Auftragnehmers war ein professionelles Claim-Management installiert, das es verstand, fast jede Anforderung als Zusatzaufwand zu klassifizieren. Die Anwendervertreter auf Seiten des Auftraggebers hingegen verstanden dies als Konkretisierung einer immer schon bestehenden und daher im Auftrag inkludierten Anforderung. Die ständigen Auseinandersetzungen rund um Change Requests hatten die Atmosphäre der Zusammenarbeit vergiftet und die Verfügbarkeit von qualifizierten Mitarbeitern für die Projektarbeit stieß auf Seiten des Auftraggebers zunehmend auf Probleme.

Da das Programm insgesamt und auch dieses Projekt schon längere Zeit gelaufen waren, die Ergebnisse allerdings in keiner angemessenen Relation zum Aufwand standen, musste darauf geachtet werden, in absehbarer Zeit einen Erfolg vorweisen zu können. Glücklicherweise sah auch das Top-Management des Auftragnehmers mittlerweile diese Notwendigkeit. Die bisher lukrierten Mehrumsätze waren zwar wirtschaftlich erfreulich, die Reputation des Unternehmens im Markt drohte allerdings zu leiden, wenn am Ende kein vorzeigbares Ergebnis erzielt würde. Dieses Interesse hatte natürlich auch das Top-Management des Auftraggebers und so konnte hier ein trotz aller Gegensätze gemeinsames Nutzenkalkül der wichtigsten Stakeholder gefunden werden. Die materielle Seite (Finanzierbarkeit der Investition durch den Auftraggeber bzw. die Gesamtkosten des Projektes) war weniger problematisch als es den Anschein hatte, es war vor allem wichtig, dass die neue Anwendung erfolgreich eingesetzt wird. Man führte zwar auf operativer Ebene einen Kleinkrieg über Aufwände, dies war allerdings eine klare Themenverfehlung aus Sicht des externen Engpasses.

Eine grundlegende Maßnahme, um die Arbeitsfähigkeit des Teams wieder herzustellen, war die Entkoppelung von vertraglichen und inhaltlichen Diskussionen. Auf der operativen Ebene des Projektes wurde nur noch über Anforderungen diskutiert, die daraus resultierenden Aufwände und deren budgetäre Bedeckung wurden dann auf der oberen Managementebene verhandelt.

Es musste zur Kenntnis genommen werden, dass die Berufung auf ein nicht aussagekräftiges Pflichtenheft für die Projektarbeit nutzlos war. Man suchte in Dokumenten, Mails und Protokollen nach Aussagen, um zu klären, ob eine Anforderung immer schon vereinbart oder ein Change Request sei. Was die tatsächlich relevanten Anforderungen für die Inbetriebnahme des Systems aus aktueller Sicht waren, blieb dabei ungeklärt.

Um dies zu ändern, erfolgte im Projekt der Umstieg auf ein iteratives Vorgehen mit einer de facto Time & Materials Verrechnung in einem schrittweise konkretisierten Budgetrahmen. Angesichts der in der Vergangenheit ständig gestiegenen Kosten war dies nur scheinbar eine Verschlechterung für den Auftraggeber; er bekam nun für sein Geld immerhin verwertbare Ergebnisse und näherte sich dem Ziel. Im laufenden Projekt das Vorgehensmodell radikal zu ändern gleicht zwar einem Umbau des Schiffes auf hoher See, aber es war ein Schlüssel zum Erfolg.

Mit der Änderung der Themen, über die zwischen den Vertretern des Auftraggebers und des Auftragnehmers auf operativer Ebene gesprochen wurde, konnte der ersatzlose Verzicht auf eine Managementebene auf Seiten des Auftragnehmers durchgesetzt werden. Konkret wurden jene Personen aus dem Projekt abgezogen, deren Fokus das Claim-Management gewesen war. Nun erfolgte die direkte Zusammenarbeit mit den Systemanalytikern des Auftragnehmers. Damit wurde die Ausrichtung am externen Engpass (Inbetriebnahme, nötigenfalls auch zu erhöhten Kosten) auch in diesem Bereich vollzogen.

Diese gravierenden Änderungen im Bereich der Prozesse des Projektes waren allerdings nur durchsetzbar, weil der Rückhalt durch das Top-Management des Auftraggebers für den neuen Projektleiter durch erfolgreiche Projekte in der Vergangenheit gegeben war. Um diese entscheidende Ressource abzusichern, wurde eine Teilung der Inbetriebnahme vorgenommen, die erfolgreiche Inbetriebnahme in einem Teilbereich des Unternehmens für den ein wesentlicher Funktionsbereich der Anwendungssoftware nicht erforderlich war, stärkte die an sich schon bestehende Vertrauensbasis beim Top-Management und schuf endlich ein Erfolgserlebnis für die Mitarbeiter im Projekt. So eine Option steht nur in Ausnahmefällen zur Verfügung, wenn dies der Fall ist, muss sie allerdings genutzt werden.

^{Bild: marigranula}

BTW: English version here

„You get what you measure“ hört man oft, vor allem von Managern börsennotierter, amerikanischer Unternehmen. Die Schlussfolgerung daraus ist, man müsse alles messen, was wichtig ist, denn nur dann wird es geschehen.

Es lohnt sich, hier etwas tiefer zu forschen. Aus der Physik lernen wir, dass der Messvorgang Teil jedes Messergebnisses ist. Es macht keinen Sinn, sich eine Realität (das Kant’sche „Ding an sich“ oder die „objektive Realität“) vorzustellen, die durch einen Messvorgang dann mehr oder minder korrekt abgebildet würde. Es gibt keine Realität unabhängig von unserer Beobachtung, die man im Sinne des Höhlengleichnisses mit unserer Wahrnehmung vergleichen könnte.

Der Projektfortschritt z.B. ist ein Konstrukt und je nach Definition wird im Projekt anders gearbeitet, Entscheidungen fallen anhand anderer oder zumindest anderer Gewichtungen der Entscheidungskriterien.  Durch die Messung wird also das System verändert, das man beobachtet. Das bestätigt das anfangs zitierte Management-Mantra, allerdings lenkt es den Blick darauf, dass die Definition der Messgrößen (Metriken) und das Messverfahren eine gravierende Intervention zur Veränderung des Systemverhaltens sind.

Der Projekterfolg wird durch die Eckwerte des „magischen Dreiecks“ gemessen, also Ergebnis, Termin und Aufwand. Wie wird das Ergebnis gemessen? Mögliche Metriken sind z.B. Function Points, abgearbeitete Tickets, Planaufwand abgenommener Arbeitspakete usw. Wie die Termintreue? Anhand des Forecasts des Endtermins, den tatsächlich erreichten Terminen von Meilensteinen oder auf einer detaillierteren Ebene? Und rechnet man beim Aufwand alle Aufwände mit; bei IT-Projekten werden regelmäßig die Aufwände der künftigen Anwender für Spezifikation und Fachtest nicht oder nur sehr fragmentarisch erfasst („Eh schon da“-Kosten), man konzentriert sich auf die von externen Dienstleistern verrechneten Kosten. Je schlechter ein Projekt läuft, umso mehr Kostenarten fallen unter den Tisch und gerne drückt man zwischendurch die Reset-Taste und fängt mit einer neuen Zählung an.

Je nachdem, wie ich meine Messgrößen im Projektcontrolling definiere, wie oft ich messe und wie genau ich messe, wird die Arbeitsweise eines Projektes verändert. Es geht also nicht einfach darum, das richtige Messverfahren zu finden, um die „Wirklichkeit“ des Projektes zu erkennen, sondern man greift durch das Controlling massiv in das Projekt ein und muss dies ganz bewusst tun. Denn: „You get what you measure“ und das ist nicht immer das, was man erreichen wollte. Also Vorsicht bei der Wahl von KPIs. Und immer mit dem Pygmalion-Effekt rechnen, auch beim Projektcontrolling.

IT‑Projekte werden regelmäßig dafür kritisiert, dass die Budgets nicht eingehalten werden. Grundlage der Budgetierung sind mehr oder minder professionell durchgeführte Aufwandschätzungen. Wer immer von sich behaupten könnte, zuverlässige Aufwandschätzungen erstellen zu können, hätte eine große Nachfrage gewiss. Wie könnte das gelingen?

Eine Methode zur Aufwandsschätzung mit langer Tradition sind Function Points. Sie wurde in den siebziger Jahren in den IBM Labors entwickelt, um schon relativ früh den voraussichtlichen Aufwand einer Software-Entwicklung abschätzen zu können.

Function Points bilden die funktionalen Anforderungen der Anwender ab und leiten daraus den voraussichtlichen Entwicklungsaufwand ab, noch bevor die detaillierte technische Analyse und Planung stattgefunden hat. Als die Methode entwickelt wurde, herrschten allerdings vergleichsweise einfache Rahmenbedingungen. Es ging grundsätzlich um Individualentwicklung, weil das Angebot an Standardsoftware noch sehr gering war. Die Anzahl der zur Verfügung stehenden Entwicklungsumgebungen war ebenfalls überschaubar, im Falle IBM damals COBOL oder PL1. Aber selbst unter den damals herrschenden sehr einfachen Rahmenbedingungen gibt es in der Schätzmethodik einen sehr weichen Parameter, der das Skillniveau der Entwickler berücksichtigt. Die Herausforderung einer zuverlässigen Aufwandschätzung ist heute ungleich komplexer.

Letztlich folgen alle Ermittlungsmethoden dem Muster der Function-Point-Methodik. Die COCOMO-Methode geht einen Schritt weiter in Richtung Realisierung und berücksichtigt die Produktivität der gewählten Entwicklungsplattform. Story Points in der agilen Welt ordnen den User Stories (letztlich wenig formalisierte Use Cases) eine relative Maßzahl für den Aufwand zu, verzichten aber auf eine explizite Umrechnung in Aufwand. Kennt man allerdings einmal die „Velocity“ des Teams, ist die Umrechnung der Story Points in Aufwand eine einfache Übung und nur aus ideologischen Gründen bei Dogmatikern der Agilität verpönt.

Welche Faktoren entscheiden heute – die funktionalen Anforderungen stehen natürlich weiterhin an erster Stelle – über den Aufwand der Realisierung bis zum erfolgreichen Einsatz?

Hier eine Liste:

• Die funktionalen Anforderungen der Anwender
• Der Funktionsumfang verfügbarer Standard‑Software
• Der Mix von Standardsoftware, Reuse vorhandener Software und Individualentwicklung
• Die Architektur der eingesetzten Standard‑Software oder die Architektur der eigenentwickelten Lösung
• Die nicht‑funktionalen Anforderungen wie zum Beispiel Safety, Security, Performance und Usability
• Die Qualifikation der beteiligten Personen (insbesondere Management, Projektleiter, Geschäftsprozessanalytiker, Softwareentwickler u.a.)
• Die Qualität der Projektabwicklung (angemessene Granularität der Planung, Projektleitung und Projektcontrolling etc.)
• Die Verfügbarkeit geeigneter Personen für die zu besetzenden Projektfunktionen
• Die Effizienz der Zusammenarbeit im Projekt
• Nicht vorhersehbare Einflüsse, wie zum Beispiel Krankenstände, Kündigungen oder auch technische Probleme
• Die Mikroorganisation der Projektarbeit (Priorisierung, Vermeiden von Multitasking, Termindisziplin, Urlaubsplanung etc.)
• Die Vielfalt und Komplexität der Voraussetzungen für den Rollout, z.B. in verschiedenen Unternehmen eines weltweit agierenden Konzerns oder auch nur in verschiedenen Abteilungen eines Unternehmens.

Die Vielfalt der einwirkenden Faktoren – und die Liste ist bei weitem nicht vollständig – macht klar, dass eine zuverlässige Aufwandschätzung vor dem Start eines Projektes nicht möglich ist. Das spricht nicht gegen das Durchführen einer Aufwandschätzung, diese ist immer notwendig und unabdingbar. Man darf nur hinsichtlich des Ergebnisses nicht vergessen, dass es eine Schätzung unter gewissen Annahmen ist. Da Abweichungen von den ursprünglichen Annahmen fast immer zu einer Erhöhung, nur sehr selten aber zu einer Verringerung des Aufwandes führen, muss ein ausreichender Aufwandspuffer eingeplant werden. Tut man das nicht, bringt man das Projekt in zusätzliche Schwierigkeiten: für notwendige Arbeiten stehen nicht genügend interne Kräfte zur Verfügung oder die notwendigen externen Ressourcen dafür können nicht zugekauft werden. Der Aufwand steigt dadurch letztlich noch mehr als ohnehin unvermeidbar gewesen wäre.

Anzumerken ist auch, dass es hier um Aufwand sowohl in Form von Personentagen als auch in Geld geht. Der Ankauf von Software substituiert Personalaufwand. Externe Projektmitarbeiterinnen und -mitarbeiter schlagen sich ebenfalls im finanziellen Aufwand nieder. Hingegen werden die internen Mitarbeiterinnen und Mitarbeiter häufig als „eh schon da“-Kosten nicht gesondert geplant und controllt. Wenn im Verlauf eines Projektes der Einsatz zusätzlicher externer Personen notwendig wird, läuft das Budget weitaus schmerzhafter aus dem Ruder als wenn „nur“ die internen Ressourcen vom Mehraufwand betroffen sind. Man sieht also, dass eine Aufwandschätzung, die das eigentliche Anliegen des Managements – Planungssicherheit – befriedigen will, eine sehr komplexe Angelegenheit ist. Nicht zuletzt wirkt auch der Mechanismus der self-fulfilling- oder auch der selfdestroying-prophecy, je nach Motivations- und Interessenslage der Beteiligten. So sehr man Ehrlichkeit und Offenheit als kulturellen Wert schätzen sollte, kann die offene Kommunikation der Budgetreserven und möglicher Fallback-Termine dazu führen, dass diese Reserven auch tatsächlich in Anspruch genommen werden.

Man kann es pointiert formulieren: Jede Aufwandschätzung ist falsch, wir wissen nur nicht wie und warum!

Und: Es kommt nicht darauf an, den Aufwand richtig zu schätzen, es geht darum, ihn zu minimieren!