Große IT-Projekte agil und diszipliniert durch "Lean Projekt Management"

Bewertung: 0 / 5

Stern inaktivStern inaktivStern inaktivStern inaktivStern inaktiv
 

 

agil für großprojekte

Agile Vorgehen für die Lieferung von IT-Systemen dominieren. Es gibt kaum mehr ein Unternehmen oder eine öffentliche Einrichtung, die nicht auf agile Verfahren setzt. Die Systementwickler freuen sich über - mehr Produktentwicklung statt Dokumentation, mehr Interaktion statt Vorgaben und Prozesse und direkten Kontakt mit Endbenutzer und Flexibilität, die lückenhafte oder komplexe und trotzdem nicht die wahren Anforderungen repräsentierende Pflichtenhefte ersetzen. Die Entscheidungsträger sind aufgesprungen - weil es "State of the Art" ist und weil sie hoffen, vielleicht damit endlich aus dem Dilemma der oft schlechten Performance Ihrer IT-Projekte zu gelangen.
Bei kleineren, weniger komplexen Projekten  können die Erwartungshaltungen, vorausgesetzt einer entsprechenden Professionalität der handelnden Personen in den erforderlichen Rollen und vor allem in Organisationen, die einen ausreichenden „Reifegrad in agilem Denken und Handeln“ aufweisen, gut erfüllt werden.
Herausforderungen stellen allerdings nach wie vor, große komplexe Projekte dar, wo die Grenzen der in den agilen Verfahren integrierten Projektmanagement Methoden rasch erreicht werden und die Projektperformance sich oft sogar verschlechtert. Problematisch gestaltet sich auch oft die Verbindung mit extern gelieferten Projekten im Rahmen einer Ausschreibungsvergabe.
Wo liegen die Ursachen und wie können agile Projektliefermethoden auch in großen Projekten ihre beste Wirkung entfalten?

 

 

eisberg Dilemma

 

 

Das Dilemma großer komplexer IT-Projekte mit dem Einsatz agiler Methoden der Produktlieferung liegt meist außerhalb der Teamebene

SCRUM, die Nominierung eines Produkt Owners und eines Scrum Masters, neue Tools wie Jira und Confluence sollen ausreichend dafür sorgen, dass Projekte durch entsprechende Transparenz und Kollaboration zwischen den Beteiligten praktisch selbsttätig durch das Team erfolgreich gesteuert werden.
Das funktioniert ganz gut, vorausgesetzt es handelt sich um ein professionelles Team und einen "agilen Kunden". Es setzt aber voraus, dass ein relativ homogener Fachbereich als Auftraggeber durch einen Produkt Owner vertreten werden kann und die Größe des Lieferteams 10 Personen nicht signifikant überschreitet. Das Team sollte auch bereits aufeinander eingespielt sein und seine Leistungsfähigkeit kennen. In solchen Situationen können deutlich bessere Projektergebnisse erzielt werden. Insbesondere die Akzeptanz der Ergebnisse steigt und damit auch meist der Nutzen. 
 
Die Schwierigkeiten beginnen, wenn die Projekte diesen Rahmen verlassen. Beispiele dafür können sein:
  • wenn signifikante Teile des Projektes durch externe Lieferanten geliefert werden, diese arbeiten im Regelfall unter vereinbarten, kommerziell gesteuerten Bedingungen, oft unter den Bedingungen komplexer Vergabeverfahren, im öffentlichen Sektor ist dies sogar gesetzlich geregelt - mit meist wenig Spielraum für Flexibilität,
  • wenn das Projekt zu groß ist um durch ein Team geliefert zu werden und ein einzelner Produkt Owner nicht mehr alle Kunden vertreten kann,
  • wenn die Auftraggeberstruktur zu heteorogen ist, z.B. wenn únterschiedliche Unternehmensbereiche oder auch Unternehmen Kunden des Projektes sind, mit jeweils subjektiven Vorgaben, Interessen und Prioritäten. 
Für diese und weitere Herausforderungen reichen die Methoden für agile Produktlieferungen allein nicht aus.
Die klassischer Projektmanagementverfahren und die traditionellen Mechanismen der unternehmensweiten Projektsteuerung müssen die Lücken schließen und sind damit wieder wesentliche Bestandteile und Erfolgsfaktoren des Projektes. 

Oft sind jedoch die bestehenden Einrichtungen und Prozesse nicht kompatibel mit den agilen Verfahren und sie wurden auch nie ausreichend mit ihnen homogenisiert. Damit heben sich Erfolgsparameter gegenseitig auf und das Ergebnis entspricht nicht mehr den angestrebten Zielen.
Es treten wiederum viele  bekannte Probleme herkömmlicher IT-Projekte auf, oft sogar in verstärktem Ausmaß.

 Balance

 

 

Erfolgsparameter

"die Balance" zwischen agil und stabil sichern

 

Die Lösung des Dilemmas erfordert sowohl eine Erweiterung des agilen Methodensets, als auch die Anpassung der Instrumentarien der klassischen Projektplanungs-, Projektmanagements- und Projektsicherungsverfahren. Diese Maßnahmen müssen in einer "Balance" zueinander stehen und in einer zeitlichen Synchronität erfolgen.

Bei unternehmenskritischen Großprojekten muss gewährleistet sein,
  • dass Anforderungen an regulativen Vorschriften (gesetzlich oder unternehmensintern) sowie Compliance Richtlinien gesichert erfüllt werden,
  • etwaigen Vertrags- bzw. Ausschreibungsbedingungen entsprochen wird , bzw. die Einhaltung dieser durch die Vertragspartner überwacht werden kann,
  • die optimierte Steuerung eines strategischen Projektportfolios gewährleistet ist,
  • eine interdisziplinäre Abstimmung im erforderlichen Ausmaß entlang des Projektverlaufes erfolgt, um einen ganzheitlichen Interessensausgleich zwischen unterschiedlichen Playern und Teams zu sichern und den agilen Projektlieferrhytmus nicht zu beeinträchtigen.

All dies liegt außerhalb des Leistungsumfanges der klassischen agilen Methoden und wird von Ihnen als "gelöst durch andere Verfahren" vorausgesetzt.

 

Für die Wirksamkeit der agilen Umsetzung eines Projektes ist wiederum unbedingt erforderlich

  • dass bei der Erfüllung der notwendigen ergänzenden und übergeordneten Steuerungsaufgaben, die Stärken und Vorteile agiler Produktliefermethoden gewahrt bleiben!
 

ergänzung 

 

 

Lean Projektmanagement und agile Lieferformen für Projekte harmonieren und ergänzen sich perfekt
Agilität bedarf Fitness, auch im Unternehmensumfeld und Fitness erreicht man besser ohne überflüssigen Ballast. Eine gute Fitness der eigenen Projektmanagement- und Projektsteuerungsmethoden kann wirkungsvoll durch die Nutzung bewährter und heute wieder hoch aktueller Grundsätze aus der „Lean Management Strategie“ erreicht werden. Ursprünglich in der Automobilindustrie (Toyota) entwickelt, ist "Lean Management" heute in vielen anderen Einsatzumgebungen erfolgreich.
Ein, den Prinzipien von Lean Management folgendes, durchgängig schlankes Projektmanagement erfüllt sehr gut die Voraussetzungen um erfolgreich gemeinsam mit agilen Verfahren zur Herstellung von Produkten und Lieferung von IT-Systemen zu wirken. Es bietet eine gute Ausgangsbasis für  die Sicherung der Balance zwischen zentralen Projektsteuerungsnotwendigkeiten und inkrementellen agilen Liefermethoden mit Raum für kontrollierte Flexibilität.

Die Grundidee von Lean Management ist der
Abbau von Überflüssigem (Vermeidung der Verschwendung) und eine durchgängige Qualitätsorientierung.
Erreicht wird dieses durch
  • absolute Kundenorientierung - was will und braucht der Kunde, was stellt daher für ihn Wert dar
  • die klare Identifikation was im eigenen Produkt, im Prozess bzw. in der eigenen Leistungserbringung zu diesen Werten beiträgt und was nicht
  • Identifikation des Wertestroms (wo, wodurch und in welchem Umfang werden diese Werte geschaffen)
  • die Sicherung des optimalen Flusses dieses Wertestroms und die Beseitigung von Hindernissen und das Management von Risiken die diesen Wertestrom verhindern oder beeinträchtigen können
  • die Anwendung des Pull-Prinzips beim Produzieren bzw. Umsetzen, begleitet mit dem Streben nach Perfektion für Ergebnisse und Durchführung durch disziplinierte Eigensteuerung
  • praktizierte Transparenz, kontinuierliches feed back und kontinuierliche Verbesserung als gelebter Standard 
  • die Steigerung der Verantwortlichkeit und der Empathie der beteiligten Mitarbeiter.
Dies sind grundsätzlich auch die Prinzipien, auf denen die agile Produktlieferung und ihre Methoden (SCRUM, KANBAN etc.) beruhen.

Sie sollten daher auch in traditionelle Projektmanagementverfahren bei der Steuerung von Großprojekten einfließen.
Einen wertvollen Beitrag für die Harmonisierung, also dem Schaffen der "Balance", leistet erfahrungsgemäß, dass bei Wahrung der jeweiligen Prinzipien und Kernaufgaben, eine gemeinsame Terminologie gefunden wird. Terminologie nicht nur formal, sondern vor allem durch Verständnis der Hintergründe, Intentionen und Aufgaben von Prozessen, Artefakten und Einrichtungen.
 

Waste in projectmanagement small

 

 

Worin besteht häufig die "Verschwendung" in angewandten traditionellen Projektvorgehen, wodurch kann dabei die Qualität leiden?

Verschwendung ist oft durch ausufernde formale Anforderungen an Abläufe der bestehenden Verfahren begründet – welche dann meist in der Praxis nicht oder nur alibimäßig gelebt werden können. Waren diese vielleicht ursprünglich einem Qualitätsanspruch geschuldet, haben sie durch die aktuelle Anwendungspraxis oft negative Auswirkungen.
Wenig überlegte Dokumentationsanforderungen, werden durch Dokumentationsmenge kompensiert.
Starre, formale Projektplanungsanforderungen tragen praktisch nicht zur Verbesserung der Steuerungsqualität bei und beeinträchtigen diese teilweise.
Dazu kommen Reportingvorgaben an Projektverantwortliche von unterschiedlichen Stellen und Einrichtungen - oft ohne Abstimmung und daher mit hoher Redundanz und Potenzial für hohe Effizienzverluste. Vielfach erstellen diese Anforderer selbst nur Berichte und haben "Koordinationsaufgaben" - mit zu hinterfragendem Einfluss auf die Qualität der Ergebnisse.

Verschwendung mit gleichzeitig negativem Einfluß auf die Qualität beginnt bereits mit dem Versuch frühzeitig Anforderungen an ein IT-System in einer Detailtiefe zu definieren, die zu diesem Zeitpunkt nicht erreichbar ist.
Oft auch, weil zuvor die wirklich wichtigen Kernanforderungen an ein IT-System nicht eindeutig und ausreichend identifiziert wurden. Jenen Kernfunktionen, die vor allem für die Erreichung der gewünschten Wertschöpfungsbeiträge durch das zu liefernde System relevant sind.
Diese, oft am Umfang gemessenen Anforderungen werden dann zu Vorgaben für Lösungen, Gegenstand von Pflichtenheften in Ausschreibungen und bestimmen Zuschläge. Sie reduzieren Innovation, Kreativität und Handlungsflexibilität und binden Ressourcen und Budgetmittel, die anderswo fehlen. Eine seriöse und konkrete Befassung mit den wirklich relevanten Qualitäts- und Abnahmekriterien für ein IT-System kommt zu kurz. Diese sind es jedoch, die die Werteströme eines Projektes signifikant bestimmen, Qualität der Ergebnisse beeinflussen und daher auch entsprechende Bedeutung und Würdigung in allen strategischen und kommerziellen Entscheidungen und Verträgen haben sollten.

Potenzielle Verschwendung und Qualitätseinbußen verbergen sich in zu starren PM-Prozessen ohne ausreichend inhärenter Anpassungsfähigkeit und formal orientierter Kommunikation, wie z.B. ausufernde Meetings und Berichtsanforderungen ohne wertschöpfende Ergebnisse.

Beispiele für zu unflexible Prozesse findet man auch in Budgetprozessen. Starre Budgetprozesse können „Verschwendung“ bedeuten, lean Budgeting bedeutet nicht unbedingt weniger oder mehr Budget, sondern einen Budgetsteuerungsprozess, der den optimalen "Wertestrom" bestmöglich unterstützt.

Es ist zu empfehlen klassische Projektmanagement Verfahren und Projektsteuerungseinrichtungen vorab von diesen und auch anderen potenziellen "Verschwendungen" zu entlasten. Danach können diese hervorragend  zur „agilen“ Lieferung  komplexer IT-Projekte beitragen, diese verstärken und damit auch für große komplexe Projekte fit machen.

 

unvollständig 

 

 

SCRUM reicht für große Projekte allein nicht aus - auch agile Verfahren müssen ergänzt werden
Agile Methoden sind für den Einsatzzweck und für die Einsatzumgebung wofür sie geschaffen wurden hoch optimiert. Man tut gut daran, sie bei der Zusammenführung mit traditioneller Projektmanagementverfahren  in ihren Domänen und Kernprozessen möglichst autark zu belassen. Die Integration sollte durch durch geeignete Ergänzungen - also zusätzliche Verfahren und durch eine, den Prinzipien nicht widersprechende Anpassung der Ausprägung ihrer Kernabläufe erfolgen.
 
Domänen und Handlungsebenen für Ergänzungen zu agilen Verfahren für die Bewältigung großer und komplexer IT-Projekte
Auf Teamebene funktionieren agile Verfahren, so sie professionell aufgesetzt ist und professionell angewandt werden, auch in komplexen Projekten hervorragend. Alle Versuche die SCRUM Prinzipien zu verwässern, auch mit guten Absichten, müssen scheitern. In der Praxis findet man dann, durch diese Eingriffe verursacht,  „pseudoagile Verfahren“ die mit effizienten agilen Verfahren oft nur den Namen, manche Artefakte und die Verwendung von speziellen Werkzeugen gemein haben. Diese werden nicht das gewünschte Ergebnis bringen.
Auf Teamebene, der Ebene wofür agile Verfahren grundsätzlich definiert wurden, sollten diese daher nicht verändert werden.
 
Auf Projektebene wo große Projekte meist die gemeinsame und parallele Arbeit mehrerer Teams erfordern bedarf es jedenfalls Ergänzungen.
Es bedarf vor allem der Einrichtung von teamübergreifenden gemeinsame fixierten Planungs- und Steuerungsankerpunkten, sogenannte „Projekt Inkremente“ der agilen Entwicklung (in Ergänung zu den dort bestimmenden "Produktinkrementen") und entsprechder Prozesse für deren Steuerung in einer agilen Umgebung. 
Diese Ankerpunkte steuert man am besten durch eine teamübergreifende Releaseplanung die sich an dem „Wertestrom“ des Projektes orientiert. Über das gesamte Projekt zieht sich dann der sogenannte „ART“ (agile release train) mit seinem Fahrplan. Je nach Größe des Projekts, können hier mehrere „ARTs“ zusammenwirken.
Dieses Vorgehen bedarf neuer Rollen im Projekt so z.B. den Release Train Verantwortlichen und im Regelfall auch die Rolle eines projektbezogenen Systemarchitekten als Verstärkung der klassischen Rollen für das Projektmanagement und die Projektlieferung.
In manchen dafür geschaffenen ergänzenden Frameworks für agile Produktlieferverfahren wird dieses Vorgehen auch „diszipliniert agil“ genannt. („DAD disciplined agile development” Disciplined Agile Consortium).
 
In Großunternehmen, wo im Regelfall mehrere komplexe Projekte parallel geführt werden, müssen die Verfahren noch auf das Multiprojektmanagement, die Steuerung von Programmen durch das Management eines Programmbacklogs, bis hin zu einem Wertestrom basierten Projektportfoliomanagement ausgedehnt werden.
Eine gute Übersicht dazu bietet das SAFe® 4.0 Framework (Scaled Agility Framework) der Scaled Agile, Inc. (http://www.scaledagile.com/).
Dieses adressiert allerdings rein die unternehmensinterne Standardumgebung für die Entwicklung und Weiterentwicklung von IT-Systemen. Die Verfahren sind daher auf die Besonderheiten von Projekten anzupassen.
Frameworks und Modelle können jedoch ohnehin nur wertvolle Anhaltspunkte und Hilfestellungen bieten. Die praktische Umsetzung der optimalen Erschließung von Potenzialen agiler Verfahren in großen komplexen Projekten, bedarf immer einer individuellen Vorgehensweise.
Essentially, all models are wrong, but some are useful.
George E. P. Box (englischer Professor für Statistik)
 
 Für Fragen stehe ich Ihnen gerne zur Verfügung.

kurt small 150 

Kurt Fanzlau
Unternehmensberater und Projektmanager
Zertifizierter Turnarround Manager
Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein!
+43 (0) 6643553997