Risikomanagement und Mut – ein Widerspruch?

Im meiner Meinung nach besten Buch zum Thema Risikomanagement, „Bärentango“ von Tom DeMarco und Timothy Lister, gibt es eine Passage, die meine Einstellung zum Risikomanagement nachhaltig geändert hat. Ich muss nämlich zugeben, dass ich unter diesem Titel eigentlich immer nur bürokratische Übungen ohne Mehrwert für die Projektarbeit erlebt hatte. Die Ursache für solche Vorgehensweisen analysieren die beiden Autoren zutreffend. Hier die Passage (ich habe nur ein Beispiel weggelassen):

Unternehmen, die die Notwendigkeit begreifen, Risiken auf sich zu nehmen, neigen zu einem seltsamen Verhalten: In dem Bemühen, positiv ­zu denken, ignorieren sie die möglichen negativen Folgen der Risi­ken, die sie eingehen. Das ist eine extreme Variante der Das-schaffen­-wir-Attitüde. Weil Risikobewusstsein zumindest einen Anflug von Das-schaffen-wir-nicht-Denken voraussetzt, lehnen manche Unterneh­men es rundweg ab. Um der positiven Einstellung willen weigern sie sich, den Schattenseiten eines Projekts ins Auge zu sehen. Gibt es zum Beispiel Faktoren, die gegen Sie arbeiten, die Ihr Projekt möglicher­weise zum Scheitern verurteilen, dann erwarten solche Unternehmen,  dass Sie darüber einfach nicht nachdenken.

Nun ist natürlich niemand so dumm, alle Risiken zu ignorieren. Leute, die sich auf den Blödsinn einlassen, Risiken zu ignorieren, gehen wählerisch vor. Typischerweise werden all die kleineren Risiken (diejenigen, die sich hoffentlich durch geschicktes Management abfangen lassen) peinlich genau aufgelistet, analysiert und überwacht. Nur die wirklich bösen Risiken werden ignoriert.
…
Das ist kaum ein Rezept für ein vernünftiges Risikomanagement. Wenn Sie auf Risiken zugehen wollen, statt vor ihnen wegzulaufen, müssen Sie dem, was auf Sie zukommt, mutig ins Auge sehen.

Darüberhinaus bringen die beiden Autoren eine ganze Reihe von Vorschlägen, wie man es richtig macht. Den Satz: „Risikomanagement ist Projektmanagement für Erwachsene“ finde ich auch sehr treffend und er wird vor dem Hintergrund des Zitates auch klarer.

Umgang mit komplexen Problemen – IT-Governance Blog

Projekte sind geradezu regelmäßig durch Komplexität gekennzeichnet. Aus der Vielfalt an Stakeholdern, Rahmenbedingungen, Lösungsoptionen etc. resultieren Effekte, die einander überlagern und unser in der Evolution auf lineare Reiz-Reaktions-Muster getrimmtes Denken überfordern.

Eine deutsche Forschergruppe unter der Leitung von Dietrich Dörner hat schon vor vielen Jahren in einer Reihe von Experimenten untersucht, wie sich Menschen angesichts von komplexen Problemen verhalten. Die dazu publizierten Bücher heißen Lohhausen, Die Logik des Misslingens und Problemlösen als Informationsverarbeitung. Ich habe für Schulungen diese typischen Fehlerquellen einmal kurz zusammengefasst und denke, es hilft immer noch als grobe Orientierung:

Fehler bei der Analyse der Rahmenbedingungen

Die Analyse der Situation erfolgt oft nur sehr eingeschränkt. Viele Daten werden nicht ermittelt oder nicht beachtet, vor allem solche, die vorgefassten Vermutungen widersprechen könnten. Bei der Analyse wird oft ungeprüft unterstellt, dass sich die Situation nicht ver­ändern wird. Wenn Veränderungen in Betracht gezogen werden, so häufig nur als Fortschreibung der bisherigen Entwicklung.

Beim Umgang mit den auftauchenden Problemen ergeben sich aus der Vernachlässigung der Eigendynamik des betrachteten Systems zwei verschiedene Fehlermöglichkeiten. Entweder wird nur reaktiv gehandelt, man läuft sozusagen den Problemen hinterher, oder aber man verhält sich so, als ob man selbst alles beeinflussen und steuern könnte oder gar müsste. Entwicklungen, die ohne eigenes Zutun die Erreichung der Ziele fördern würden, werden also nicht genutzt oder sogar gestört.

Fehler bei der Bewertung von alternativen Maßnahmen

Die Zielformulierung wird häufig gänzlich unterlassen. Die Ent­scheidungen bauen dann auf unklaren Vorstellungen darüber auf, was eigentlich die wesentlichen Erfolgskriterien sind. Damit verbunden ist eine unzulängliche Schwerpunktbildung. Die Prioritäten wechseln oft sogar in Abhängigkeit von auftauchenden Schwierigkeiten. Man weicht Problemen aus, die sich als schwer lösbar erweisen.

Bei der Bewertung von Handlungsmöglichkeiten werden die unerwünsch­ten Nebenwirkungen von Maßnahmen oft ignoriert, die Erfolgskon­trolle unterbleibt. Dies nicht zuletzt mangels vorweg definierter Ziele.

Fehler bei der Suche nach Maßnahmen

Bestimmte Maßnahmen werden immer wieder in Betracht gezogen, ohne dass objektiv geprüft wird, ob es noch andere, mehr Erfolg verspre­chende Möglichkeiten gäbe. Da die Eigendynamik des Planungsobjektes oft verkannt wird, werden Maßnahmen häufig falsch, insbesondere zu stark „dosiert“. Führen Maßnahmen nicht zum Erfolg, so wird der von Watzlawick beschriebene Fehlschluss gezogen, dass „mehr desselben“ zum Erfolg führen könnte. Dies mündet schließlich oft in gewaltsame Lösungsversuche, die im Extremfall das Planungsobjekt derart negativ beeinflussen, dass künftige Lö­sungsversuche völlig aussichtslos sind.

Die Tatsache, dass aufgrund der Vernetztheit des Handlungsfeldes kaum jemals eine einzelne Maßnahme genügt, um die gewünschte Wir­kung zu erzielen, wird ebenfalls oft übersehen. Die Autoren ver­muten, dass dies auf das Bestreben zurückzuführen ist, möglichst zu jedem Effekt genau eine Maßnahme als die richtige Lösung des Problems zuordnen zu können. Durch diese Vorgehensweise kommt man jedoch in komplexen Situationen nicht zum Ziel.

Agiles Projektmanagement im Geiste von „Lean Management“

Wenn über agiles Vorgehen gesprochen wird, geht es derzeit fast immer um Scrum. Aber es lohnt sich, auch andere Ansätze zu betrachten. Inspiriert von Ideen des Industrial Engineering (die japanische Autoindustrie war hier der Vorreiter) haben Mary and Tom Poppendieck den Ansatz des „Lean Software Development“ entwickelt. Das ist eine iterative Methodik, die mehr eine Auswahl von Prinzipien als ein fixer Satz von Methoden ist. Aufgrund dieses höheren Abstraktionsgrades kann dieser Ansatz aber auch jenseits der Software-Entwicklung sinnvoll angewendet werden. Wer dazu ein Buch der Urheber lesen möchte, findet es hier.

Lean Software Development fokussiert auf den Wert für den Kunden und die Effizienz der Wertschöpfungsketten. Die Hauptprinzipien sind:

  • Eliminating Waste
  • Amplifying Learning
  • Deciding as Late as Possible
  • Delivering as Fast as Possible
  • Empowering the Team
  • Building Integrity In
  • Seeing the Whole.

Diese Prinzipien sind heute wohl weitgehend Allgemeingut, nur die Regel, möglichst spät zu entscheiden, überrascht auf den ersten Blick, wird hier doch gegen die Tugenden der raschen, frühzeitigen, langfristigen Entscheidungskultur angetreten.

Ich selbst habe an anderer Stelle das Lob der schnellen Entscheidung angestimmt. Das Geheimnis liegt wohl in dem Wort „möglich“; so spät wie möglich, aber nicht früher und keinesfalls später. Je dynamischer das Umfeld eines Projektes ist, umso mehr lohnt es sich, darüber nachzudenken, welche Entscheidungen man derzeit noch nicht treffen muss bzw. wo man sich noch Optionen offen halten könnte, ohne die Projektziele zu gefährden. Gerade um sich hier nicht zu überfordern, müssen Standards der Projektabwicklung, die Wiederverwendung von bewährten Lösungselementen, klare Entscheidungsprozesse etc. möglichst früh definiert und außer Streit gestellt werden. Das genau deshalb, damit man dann Kapazität für die bewusst offen gehaltenen Entscheidungsthemen hat, die zum spätest möglichen Zeitpunkt zu entscheiden sind und dann natürlich dringend und unaufschiebbar sind.

 

Normen, Normen, Normen … – IT-Governance Blog

Derzeit hat die Veröffentlichung von Normen zu Beratungsthemen offenbar Hochkonjunktur. Die ISO 21500 zum Projektmanagement ist in der finalen Phase und kürzlich wurde mit der EN 16114 auch die Managementberatung in vergleichbarer Weise normiert. Gemeinsam ist beiden Normen, dass sie keine Zertifizierung vorsehen, weder für Personen noch für Organisationen bzw. Unternehmen.

Eine Überblickinformation zur EN 16114 gibt es auf der Website des Normungsinstitutes hier. Es werden drei Phasen unterschieden, wenig überraschend sind dies Angebot, Durchführung und Abschluss. Ob sich unter diesen Umständen ca. € 71,- für weniger als 30 Seiten recht trivialen Inhalts lohnen, muss jeder für sich entscheiden; ich gebe dieses Geld lieber für etwas anderes aus.

Die ISO 21500 ist derzeit nur in einer vorläufigen Version erhältlich (um ca. € 60,-), die Endversion soll Ende August 2012 zur Verfügung stehen. Etwas zur Geschichte und zum aktuellen Stand schreibt der stellvertretende Vorsitzende der deutschen Gesellschaft für Projektmanagement in seinem Blog. Auch hier ist der Mehrwert fraglich, man hat von den etablierten Standards deutlich mehr für die praktische Arbeit zu erwarten. Allein das PMI bietet auf seiner WebSite qualitativ überlegene Standards an, die sich differenziert mit Projektportfolio-, Programm- und Projektmanagement auseinandersetzen, auch die Themen Risikomanagement, Konfigurationsmanagement etc. abdecken. Für Mitglieder des PMI kostenlos, ansonsten zu einem vergleichsweise sehr attraktiven Preis-Leistungsverhältnis gibt es diese Dokumente hier.

Netzmanagement – ein Plädoyer gegen „Mehr desselben“ als Lösungsstrategie im Projektmanagement

In einem Sonderheft zum Thema Projektmanagement des Harvard Business Manager (Edition 3/2011) propagieren Autoren der Firma Metaplan (Kai Matthiesen, Thomas Schnelle) sowie ein Professor der Universität Bielefeld (Stefan Kühl) eine Alternative zum klassischen Projektmanagement, die sie als „Netzmanagement“ bezeichnen.

Einen Artikel aus dem Jahr 2005, der weitgehend die gleichen Inhalte abdeckt, dort allerdings nicht auf Projekte bezogen, ist mittlerweile nicht mehr online verfügbar (Aktualisierung Jänner 2022), daher hier einige Zitate:

In der Einleitung schreiben die Autoren:

„Scheitern Projekte, beschwören Manager, Berater und Wissenschaftler immer wieder die gleichen, weithin anerkannten Prinzipien des Projektmanagements:

Die Verantwortlichen hätten die Ziele klarer definieren, die Probleme sorgfältiger analysieren, die nötigen Maßnahmen genauer planen, die Mitarbeiter besser einbinden und alles noch sorgfältiger überwachen müssen.

Aber vielleicht stimmt ja gerade mit diesen Grundprinzipien des Projektmanagements etwas nicht. Vielleicht verschärfen Führungskräfte durch ein Mehr an klassischem Projektmanagement die Probleme noch. Wir brechen mit dieser Ideologie des Projektmanagements und stellen unter dem Begriff des Netzmanagements eine neuartige Konzeption vor, die sich an fünf Regeln orientiert:

  1. Die Verantwortlichen verzichten auf eine genaue Definition von Zielen und legen nur einen breiten Zielkorridor fest.
  2. Das Projektteam beginnt mit der Arbeit, bevor alle Aspekte des Vorhabens zu Ende gedacht sind. Die Phasen Problemanalyse, Maßnahmenerarbeitung und Umsetzung sind nicht voneinander getrennt.
  3. Es wird auf Projekt- und Lenkungsausschuss verzichtet und stattdessen mit wechselnden Gruppen gearbeitet.
  4. Die zuständigen Führungskräfte verkürzen nicht die in Projekten üblichen Machtspiele, sondern verlängern diese sogar.
  5. Die Verantwortlichen arbeiten mit Erfolgssurrogaten, weil sich bei komplexen Projekten ein objektiver Erfolg meist nicht nachweisen lässt.“

Man erkennt deutlich die Denkschule des agilen Vorgehens sowie die von Watzlawick eindringlich vorgebrachte Kritik der Lösungsstrategie „Mehr desselben“.

Wie immer ist das alles eine Frage der konkreten Situation und der Dosis. Es gibt Projekte, in denen klare Zielbestimmungen a priori möglich sind, dann wäre es fahrlässig, darauf zu verzichten. Auch hängt es von der Kultur eines Unternehmens ab, ob man auf einen Lenkungsausschuss verzichten kann, die Arbeit mit wechselnden Gruppen je nach Problemstellung ist meiner Meinung nach immer möglich. Das „Verlängern von Machtspielen“ ist eine etwas skurille Ausdrucksweise, gemeint ist aber schlichtweg das bewusste Umgehen mit Problemen, die man nicht ohnehin nicht unterdrücken kann. Auch „Erfolgssurrogate“ klingen nicht gerade vertrauenserweckend, wenn man stattdessen Zwischenziele, Sekundäreffekte und Erfolge welcher Art auch immer, die man auch feiern und anerkennen möge, dafür einsetzt, verliert diese Empfehlung ihren irritierenden Charakter.

ISO 21500 – Wie verträgt sich diese mit den Standards von PMI und IPMA?

Die Industrie ist an sich ein Vorbild, wenn es um Standardisierung bzw. Normierung geht. Aber auch dort gibt es Liter und Gallonen, km und Meilen und wer von uns misst schon die Stärke eines Motors in kW statt in PS. Wenn wir mit unseren Laptops in die Schweiz reisen, brauchen wir Adapter für unsere sogenannten „EU-Stecker“. Erst recht in England, USA etc. Aber doch ist die Zahl der Standards für wirklich wesentliche Bereiche der Technik gering und meist auch regional differenzierbar.

International agierende Projekte wünschen sich Standards für die Abwicklung von Projekten, die von allen Mitwirkenden ungeachtet der regionalen Herkunft und der Unternehmenszugehörigkeit verstanden und akzeptiert werden. PMI ist die weltweit führende Standardisierungsorganisation, IPMA ist in Europa und insbesondere auch in der DACH-Region stark vertreten. Immer wieder werde ich gefragt, wo denn die Unterschiede zwischen diesen beiden Standards liegen und welcher davon „besser“ sei.

Die internationale Norm für Projektmanagement, ISO21500, die Ende 2012 in Kraft treten sollte, gibt darauf eine erfreulich klare und entspannende Antwort. Diese beiden Standards sind nicht wirkliche Konkurrenten, sondern repräsentieren zwei unterschiedliche, aber gleichermaßen berechtigte Sichten auf das Projektmanagement. Während PMI auf die Prozesse des Projektmanagements fokussiert, blickt IPMA auf die Qualifikationen der handelnden Personen. In der ISO21500 werden diese beiden Zugänge gleichermaßen integriert und miteinander verbunden. Das liest sich im Entwurf, der mir vorliegt, wie folgt:

Zunächst zu den Prozessen bzw. Prozessgruppen:
Each process group consists of processes that are applicable to any project phase or project. These processes, further defined in terms of purpose, description and primary inputs and outputs are interdependent. They are also independent of application area or industry focus. Process groups are not project life cycle phases.
Initiating process group
The initiating processes are employed to start a project phase or project, to enable the purpose of the project phase or project to be defined, the objectives to be specified and the project manager to be authorized to proceed with the project work.
Planning process group
The planning processes are employed for detailed project planning and for setting the baselines against which project implementation should proceed and project performance should be measured.
Implementing process group
The implementing processes are employed to accomplish the project management activities to support the production of the project’s deliverable(s) according to the project plans.
Controlling process group
The controlling processes are employed to monitor, measure, and control the project’s performance against the project plan so that preventive and corrective actions may be taken and change requests made when they are necessary to ensure the project objectives are achieved.
Closing process group
The closing processes are employed to establish formally that the project phase or project is finished and to provide lessons learned to be considered and implemented as appropriate.

Vergleichen wir das mit dem Prozessmodell von PMI, so ist die Analogie offensichtlich:

Und dann zu den Qualifikationen:

Each project team requires competent individuals who are capable of applying their knowledge and experience in order to deliver the project deliverables. Any identified skills gap between the available and required competence levels of the project could introduce risk and should be addressed.

While detailed information regarding the breadth and depth of competencies is beyond the scope of this standard, project management competencies can be categorised into, but not limited to:

  • technical competencies for delivering projects in a structured way, including the project management processes defined in this standard.
  • behavioural competencies associated with personal relationships within the defined boundaries of the project.
  • contextual competencies related to the management of the project within the organizational environment.

Competencies may be raised through professional development processes such as training, coaching and mentoring inside or outside an organization.

Vergleichen wir das mit dem Kompetenzmodell von IPMA, sieht man auch hier die Übereinstimmung:

So einfach ist es also: Wenn es um die Organisation des Projektmanagements in Unternehmen und Organisationen geht, ist der Prozessansatz von PMI der beste Weg, wenn es um Personalrekrutierung und -entwicklung geht, ist man mit dem Kompetenzansatz von IPMA am besten bedient.

Der „weniger ist mehr“-Effekt – IT-Governance Blog

Ich lese gerade ein hochinteressantes Buch der internationalen ABC Research Group rund um Gerd Gigerenzer vom Max Planck Institute for Human Development in Berlin mit dem vielversprechenden Titel „Simple Heuristics That Make Us Smart„.

Die Autoren berichten von empirischen Forschungen zu erfolgreichen Problemlösungsmethoden. Das sind Heuristiken, also Vorgehensmodelle, die keinen Perfektionsanspruch stellen. Das allerdings ist die quasi negative Beschreibung, die solche Verfahren mit dem Ideal einer konsistenten und strikt logisch aufgebauten Problemlösungsmethode vergleichen und deren Defizite aufzeigt. Die Autoren gehen an dieses Thema allerdings ganz anders heran:

We do not compare human judgment with the laws of logic or probability, but rather examine how it fares in real-world environments. The function of heuristics is not to be coherent. Rather their function is to make reasonable, adaptive inferences about the real social and physical world given limited time and knowledge. Hence, we should evaluate the performance of heuristics by criteria that reflect this function.

To conclude: Heuristics are not simply hobbled versions of optimal strategies. There are no optimal strategies in many real-world environments in the first place. This does not mean, though, that there are no performance criteria in the real world. As a measure of the success of a heuristic, we compare its performance with the actual requirements of its environment, which can include making accurate decisions, in a minimal amount of time, and using a minimal amount of information.

We have thus replaced the multiple coherence criteria stemming from the laws of logic and probability with multiple correspondence criteria relating to real-world decision performance. But there is a further difference between these two sets of multiple criteria: While all coherence criteria must be met for a decision method to be deemed rational, correspondence criteria can be considered in relation to each other. In some environments for instance, it may be more important to make a decision quickly rather than focusing on accuracy. However, one of the surprising empirical findings reported in this book is that simple heuristics need not always make such trade-offs. We will show that, when compared to some standard benchmark strategies, fast and frugal heuristics can be faster, more frugal and more accurate at the same time. No trade-off need be considered.

Was heißt das für die Praxis des Projektmanagements? Das aufwändige Aufbereiten möglichst vieler Details, deren penible Auflistung, Bewertung und schließlich die Entscheidungsfindung nach Methoden wie dem Nutzwertverfahren ist nicht nur ineffizient, sondern kann in der realen Welt auch zu ungünstigeren Entscheidungen führen als Verfahren, die mit Informationen viel selektiver umgehen. Das ist kein Freibrief für Oberflächlichkeit, aber eine Bestärkung für eine strikte Engpassorientierung und Fokussierung. Das ist kein Kompromiss, sondern auf der ganzen Linie besser, so die Botschaft der ABC Research Group.

Erinnert an Tom deMarcos Aussagen zu Vorgehensmodellen in einem anderen Blog-Eintrag (hier).

Lesssons learned oder doch besser: Wissensmanagement

Obwohl der Hype des positiven Denkens („Keine Probleme, nur Lösungen“ und „Bitte keine Schuldzuweisungen“) die emotionslose Analyse von Fehlern erschwert, kann unter dem Titel „Lessons learned“ doch ein Blick auf eventuelle Fehler (ja, die gibt es immer noch, da kann man noch so positiv denken …) geworfen werden.

Ein interessanter Blog hat sich überhaupt auf dieses Thema spezialisiert, hier der Link.

Interessant der Hinweis, dass Lessons Learned eigentlich besser als Teil des Wissensmanagements im Projektmanagement verstanden und praktiziert werden sollte. Vielleicht können wir auf diesem Weg noch effektiver zu einem umfassenden Erfahrungslernen gelangen.

Um nicht missverstanden zu werden: Notorischen Pessimismus und Fehleranalysen die regelmäßig mit der Benennung von Personen enden, die an allem schuld sind, mag ich auch überhaupt nicht. Aber es gibt manchmal auch Fehlbesetzungen in Projekten und wo man die richtige Person auf den richtigen Job setzen kann, sollte man das auch tun. Das dass für manche Beteiligten unangenehm ist, kann man durch flankierende Maßnahmen abfangen, aber es sollte nicht ein ganzes Projekt zum Opfer übertriebener Rücksichtnahmen durch Tabuisierung von Kritik werden.

 

Agile Softwareentwicklung mit Preisdeckelung für ein Software-Entwicklungsprojekt

Immer wieder hört man als Argument gegen den Einsatz von agilen Methoden in einem regulierten Umfeld (insbesondere wenn die Vergaberichtlinien für öffentliche Institutionen gelten), dass es mit diesen Regularien unvereinbar wäre, es müsse ein Fixpreis vereinbart werden. Die Praxis zeigt zwar, dass jeder Fixpreis alles andere als fix ist (das Zauberwort heißt „Change Requests“), aber es ist schon richtig, dass es schwierig ist, im voraus eine rechtskonforme Vereinbarung zu treffen.

Aus einen praktischen Anlass habe ich versucht, das Modell des „Guaranteed Maximum Price“ (GMP) und agile Vorgangsweisen so zu vereinen, dass man dies auch im Falle eines öffentlichen Auftraggebers praktizieren könnte. Der finale Praxistest steht noch aus, aber ich freue mich vorweg über Feedback dazu.

Hier das Modell, es werden die Abkürzungen AG für Auftraggeber und AN für Auftragnehmer verwendet:

In der zweiten und eventuell dritten Angebotsrunde erfolgt eine Deckelung des Volumens von Seiten des AN auf Grundlage der Aufklärungen und einem entsprechend angepassten Anforderungsprofil (Beseitigen der erkannten und verzichtbaren Preistreiber von Seiten des AG) auf Grundlage einer Vereinbarung zur Zusammenarbeit im Projekt.

Vereinbarung der Eckpunkte der Anforderungen in fachlicher Terminologie (Prozesse, fachliche Use-Cases, Maskeninhalte und Funktionen, Geschäftsregeln, Transaktionsfolgen) als Basisdokument für die Projektabwicklung.

Nominierung von fachlichen Ansprechpartnern auf Seiten des AG. Diese Personen können für bestimmte Phasen des Projektes in unterschiedlichem Ausmaß eingeplant werden. Rollierende Bedarfsplanung von Seiten des AN, so dass unnötige terminliche Bindungen vermieden werden können.

Besetzung der agilen Rollen (Produkt-Owner (AG), Scrum-Master (AN), Team-Mitglieder AN und Team-Mitglieder AG). Zuordnung von Primärzuständigkeiten zu Teammitgliedern (fachliche, technische und betriebswirtschaftliche Expertise). Nominierung eines Team-Koordinators sowohl von Seiten AG als auch AN , diese sind für die laufende Planung und Abwicklung des gemeinsamen Projektes verantwortlich.

Teilnahme des fachlichen Projektleiters auf Seiten des AG an einer Schulung zum Produkt-Owner.

Vorlage einer Sprintplanung (Termine, Grobbeschreibung der geplanten Ergebnisse, Kapazitätsanfor-derungen auf Seiten AG und AN) als Initialplanung von Seiten des AN.

Einigung auf ein Verfahren zur rollierenden Aufwandsplanung . Plausibilisierung der Aufwandschätzungen durch Quervergleich mit bereits realisierten oder bereits geplanten Features (z.B. Quality Points) nach Wahl des AN.

Tägliches „Standup-Meeting“ (Rückschau, Vorschau) moderiert vom Scrum-Master des AN.

Kurzfristige Verfügbarkeit von Auskunftspersonen auf Seiten des AG für Rückfragen und Entscheidungen wird von AG in allen Phasen innerhalb der Normalarbeitszeit zugesichert. Kontaktaufnahme per Telefon, Mail oder Meeting. Der Einsatz von Kommunikationsmedien wie Web-Meetings wird von beiden Seiten unterstützt.

Transparenz des Personaleinsatzes auf Seiten des AN während der Laufzeit (Arbeit vor Ort oder Leistungen im Büro des AN werden wöchentlich offen gelegt und bestätigt).

Transparenz des Fortschrittes durch Burn-Down-Charts, die nach Abschluss jedes Sprints zwischen AG und AN einvernehmlich aktualisiert werden.

Recht des AG, bei ungenügend qualifizierten Mitarbeiters auf Seiten des AN deren Austausch oder Kürzung der auf das Budget anzurechnenden Stunden zu verlangen.

Recht des AN, bei Nicht-Erbringung vereinbarter und notwendiger Mitwirkungsleistungen auf Seiten des AG eine angemessene Erhöhung seines Budgets zu verlangen.

Es gilt gegenseitig eine weit gefasste Hinweispflicht im Sinne eines Frühwarnsystems.

Hinweispflicht des AN bei Entscheidungen des AG, die ein Sprengen des Aufwands- und Zeitrahmens zur Folge haben können.

  • Abnahmen und Change Requests

Tests erfolgen im Rahmen der Sprints. Grundsätzlich nehmen alle Teammitglieder an der Testvorbereitung, -durchführung und –auswertung aktiv teil (also sowohl Mitarbeiter des Fachbereiches als auch Entwickler). Es werden in höchstmöglichem Ausmaß Werkzeuge zur Testautomatisierung eingesetzt, vor allem, um den Aufwand für Regressionstests gering zu halten.

Teilabnahmen von Seiten des AG bei jedem Sprint. Vorbehalt Integrationstest und Performance, sichtbare Features werden verbindlich abgenommen (Dokumentation durch „Hinterlegung“ des Standes der Software auf einem Read-Only Speichermedium, ergänzend bei Bedarf Screenshots etc.). Nach einer solchen Abnahme gilt für Änderungen das Verfahren für Change Requests.

Change Requests sind von Seiten AG und AN jederzeit möglich. Sie sind hinsichtlich des Nutzens für die Erreichung des Projekterfolges (Qualität der Lösung, Aufwand, Termin) vom Antragsteller zu begründen, vom anderen Partner zu prüfen, allenfalls Vorschläge zur Modifikation einzubringen. Wenn diese Anforderungen hinreichend geklärt sind, erfolgt eine Kalkulation der daraus resultierenden Auswirkungen für Aufwand und Termin von Seiten des AN. Entscheidung des AG über Freigabe des Change Requests. Es wird vereinbart, Change Requests wohlwollend zu prüfen, allfällige Einwände und Hinweise des anderen Partners ernst zu nehmen und stets ein Einvernehmen zu suchen.

Höchste Eskalationsstufe bei Nicht-Einigung (Aufwände, CRs, Abnahmen, …) sind jeweils ein Geschäftsführer auf Seiten AG und AN. Solche Meetings werden von einem neutralen, externen Sachverständigen moderiert. Es gelten die Grundsätze einer Mediation.

Nachträglicher Hinweis: Etwas allgemeiner setze ich mich mit diesem Thema in einem Beitrag zur Vertragsphilosophie agiler Projekte auseinander.

Drei Bücher zu diesem Thema seien hier genannt:

 

Wenn Sie regelmäßig über neue Blogposts informiert werden wollen, tragen Sie sich bitte hier ein. Bitte öffnen Sie dann Ihr Postfach und klicken Sie auf den Bestätigungslink, andernfalls wird die Anmeldung nicht wirksam („Double-Opt-In“).

Ihre Adresse wird nicht weitergegeben. Sie können sich jederzeit mit einem Klick wieder abmelden.