Treffen der indisch-deutschen IT-Community. Ziel ist es, dass Kontakte zwischen regionalen Softwareeunternehmen, Indescon-Mitgliedern und indischen IT-Experten geknüpft werden.
Mind Maps nutze ich schon relativ lange. In letzter Zeit setze ich diese Technik und die erzeugten Mind Maps immer stärker ein.
Für sehr kleine Projekte kann eine aktuell gehaltene Mind Map sogar einen Großteil der Projektdokumentation ersetzen. Sozusagen die WBS in die Mind Map gießen und den Status plakativ festhalten. Ist natürlich weder die echte Projektmanagement-Lehre (WBS und Fortschritt nicht vermischen), noch echtes Mindmapping. Funktioniert allerdings überraschend gut.
Mit Werkzeugen wie XMind kann man zudem direkt eine Tabelle hinzufügen (bzw. einen Ast als Tabelle visualisieren) und damit die wichtigsten Termine im Auge behalten.
Gestern habe ich mir nach längerer Nutzung der kostenlosen Standard-Version die Pro-Lizenz für XMind gegönnt (Aktionspreis etc.) und ein bisschen herumgespielt und eine einfache Mind Map zum Thema Scrum erzeugt.
Wie immer freue ich mich natürlich über Kommentare!
UPDATE: Simon Baker hat ein wirklich beeindruckende Mind Map zu Scrum erstellt.
Das letzte Treffen der Scrum User Group Karlsruhe in 2009 beschäftigte sich mit der Rolle des Scrum Product Owners. Genauer: “Herausforderungen für unseren Product Owner”.
Zunächst wurde darüber diskutiert, wie/ob der Product Owner (PO) zum Scrum Team gehört. Relativ schnell wurde die allgemein akzeptierte Formel “Scrum Team = (Dev) Team + SM + PO” übernommen.
Auf die Frage, wer bereits als Product Owner arbeiten konnte, gab es nur wenige Meldungen. Die Verteilung dürfte ähnlich wie bei den Zertifizierungen sein: Viele ScrumMaster, wenige ProductOwner.
Danach wurden typische Herausforderungen für den Product Owner gesammelt:
Die Punkte wurden auf Karten geschrieben und dann inhaltlich gruppiert. Die größte Gruppe stellten dabei die organisatorischen Herausforderungen bzw. Rahmenbedingungen da:
Am meisten kritisiert: Der Product Owner hat keine echten Entscheidungsbefugnisse (ProductOwner != Gold Owner).
Teilweise sind POs nur Verwalter eines Team-Backlogs, d.h. die Rolle des POs wird ad absurdum geführt. Sehr beliebt v.a. bei Multi-Projekt-Umgebungen.
POs müssen die Arbeitsweise des Scrum Teams bzw. das Projekt nach außen vertreten. Hierbei spielen oft fixe Termine für Releases, Budgets (EUR, PT) und Standards (Norm xyz) eine wichtige Rolle. Die äußeren Zwänge in Einklang mit der Sichtweise innerhalb des Scrum-Prozesses zu bringen bleibt oft alleine die Aufgabe des PO.
POs bekommen in ganzer Schärfe den Wettbewerb zu spüren, ohne den Druck weitergeben zu können. Letztendlich sind Product Owner die Schnittstelle zur Welt außerhalb des Scrum-Teams.
…
Diese größte Gruppe wurde klassifiziert als “Pech, das ist der Job des Product Owners” ;-)
Augenmerk wurde dann auf Herausforderungen gelegt, die direkt beeinflusst werden können. Dazu gehören:
Überforderung des Product Owners durch die vielfältigen Aufgaben. Der Product Owner sollte bei größeren Projekten nicht alleine agieren, sondern es soll eine Hierarchie von Product Ownern geben (PO of PO)
Product Owner sollte ein gutes technisches Verständnis haben
Product Owner sollte nicht zu viel technisches Verständnis haben (Oh! Ein Widerspruch)
Der Product Owner soll direkt mit dem Kunden interagieren, aber im besten Fall auch immer für das Team erreichbar sein. Problematisch, wenn der Kunde relativ weit entfernt ist.
… sowie noch eine große Anzahl weiterer Themen (hat die jemand mitgeschrieben?)
Letztendlich wurde allen Beteiligten schnell klar, welche Anforderungen die Rolle des Product Owners stellt und das die Arbeit als PO voll widersprüchlicher Zielsetzungen sein kann (Team coachen ja/nein, einmischen bei technischen Fragestellungen ja/nein, Rahmenbedingungen verändern wollen ja/nein, Team hinterfragen ja/nein, …).
Meiner Meinung nach verbirgt sich jedoch hinter vielen Wiedersprüchen auch eine Verantwortung, welche zum großen Teil vom Team übernommen werden müsste. Das Team darf nicht eindimensional auf der technisch besten Lösung beharren, sondern muss die Rahmenbedingungen – auch die wirtschaftlichen – verstehen und ist deshalb in der Pflicht Alternativen anzubieten und auf mögliche Auswirkungen hinzuweisen. Leider sind die meisten Entwickler-Teams hier sehr zurückhalten und ziehen sich auf eine vereinfachte Sichtweise zurück.
Gerade bei Teams, in denen die Schlüsselrolle des POs geschwächt ist, fehlt den Team-Mitgliedern der Ansprechpartner für schnelle Entscheidungen und sie ziehen sich zunehmend in die Passivität oder Feuerwehraktionen zurück. Genau so darf Scrum natürlich nicht laufen, dürfte aber zu der verbreitesten Form der Scrum Implementierung zählen ;-(
Auf der Mailingliste scrumdevelopment wurde vor einigen Tagen die spannende Frage diskutiert ob/wie Scrum zu Projekten mit Festpreis-Verträgen passt. Eine Frage, die immer wieder diskutiert wird, wie schon ein anderer Thread aus dem Jahr 2006 zeigt.
Im Rahmen der aktuellen Diskussion wurde immer wieder das Festpreis-Modell als sehr problematisch bezeichnet, allerding sind in vielen Bereichen Festpreis-Projekte Standard und dieses wird sich trotz der vielfältigen Nachteile dieser Vertragsform wohl auch in absehbarer Zeit nicht ändern.
Da auch in meinem Umfeld Festpreis-Projekte dominieren, hier ein paar Gedanken zu dem Thema.
Festpreis-Projekte – nicht nur der Preis ist fix
In einem Festpreis-Projekt sind alle wesentlichen Parameter vorgegeben:
Das Angebot definiert den Preis, es gibt keine variablen Anteile
Die Spezifikation definiert dem Umfang, die Features – in Scrum-Speak den “Scope”
Die Termine sind in den meisten Fällen ebenfalls genau fixiert, Strafzahlungen bei Terminverfehlungen sollen häufig die Termintreue verbessern
Hinsichtlich Qualität wird meist mit Verweise auf “entspricht dem aktuellen Stand der Technik” etc. gearbeitet; Formulierungen die für Juristen Munition genug abgeben
Auf den ersten Blick vermittelt ein Festpreis-Vertrag damit den Eindruck einer sicheren Grundlage für das Projekt. Der Teufel steckt – wie immer – im Detail.
Typische Herausforderungen bei Festpreis-Projekten
Beispiele für typische Herausforderungen beim Einsatz von Festpreisprojekten sind:
Meist wird der Preis stark durch den Wettbewerb beeinflusst. Schätzungen der Entwicklungsabteilungen werden nach unten korrigiert, Risiken nicht ausreichend eingepreist. Der Vertrieb wird oft am Umsatz der abgeschlossenen Verträge gemessen und weniger daran, ob die versprochenen Leistungen auch geliefert werden können.
Anforderungen und Spezifikation sind in der Regel weder ausreichend genau noch fehlerfrei. Selbst wenn dies der Fall wäre, dann würde eine Spezifikation die noch vor der ersten echten Projektphase geschrieben wurde, nie die wirklichen Wünsche des Kunden abdecken. Zudem ändern sich diese stetig.
Im Allgemeinen hat man bei Ausschreibungen für Festpreis-Projekte nur beschränkt die Möglichkeit eng mit den (potentiellen) Auftraggebern zusammen zu arbeiten. Der Aufwand ist zudem eine erhebliche Investition, die sich nur auszahlt (?), wenn das Angebot attraktiv genug ist, um den Zuschlag für das Projekt zu erhalten. Attraktivität definiert sich hierbei oft über die ausgewiesenen Kosten.
Termine werden meist ebenfalls durch Wunschdenken herbeigeführt. Mögliche Risiken werden hierbei ebenfalls ignoriert.
Qualitätskriterien sind nicht vereinbart, alle beteiligten Parteien haben eine unterschiedliche Auffassung, was genau unter Qualität zu verstehen ist.
Roy Morien schreibt in seinem Beitrag einen entscheidenden Satz, der wohl irgendwann in jedem Festpreis-Projekt von Auftraggeber gesagt wird:
‘Oh, but surely you understood that {some feature or process} is part of what we asked for’.
In vielen Fällen war hierbei wohl selbst dem Auftraggeber zum Zeitpunkt der Beauftragung nicht klar, dass die Funktion oder der Prozess zum Leistungsumfang gehört. Sonst hätte er dies nach Erhalt der Spezifikation anmerken müssen. Der Auftraggeber kann sich im Allgemeinen nicht von seinen Mitwirkungspflichten entbinden.
Vorgehensweise bei Angebotslegung und Abwicklung
Im Allgemeinen wird bei Festpreis-Projekten auf zwei Arten auf die Herausforderungen reagiert:
Bei kleineren Punkten wird ein im Festpreis vorgesehene “Puffer” genutzt, um unnötige Reibungsverluste durch Verhandlungen von Änderungswünschen zu vermeiden. Eine Methode die nur bedingt zu empfehlen ist, da im Allgemeinen der Puffer in anderen Positionen verstreckt wird und damit das Vertrauen beschädigt werden kann.
Im Allgemeinen muss bereits kurz nach Projektbeginn über Änderungswünsche diskutiert werden. Änderungswünsche haben meist Auswirkungen auf Projektbudget und Termine. Teilweise gelingt es aber auch Funktionen zu tauschen, d.h. den Scope des Projektes anzupassen.
Erfolgsfaktoren
Entscheidend bei Festpreis-Projekten sind oft Punkte wie
Offenheit und Vertrautheit: Kommunizieren Auftragnehmer und Auftraggeber offen miteinander und besteht grundsätzlich Vertrauen zwischen beiden Parteien?
Rahmenvertrag und Einkauf: Ist der Rahmenvertrag fair oder wird eine der beiden Parteien stark benachteiligt? Wann/wie muss bei Konzernen die Abteilung für Einkauf / Projektabwicklung involviert werden. Welche Vorgaben und Prozesse bestehen?
Nachvollziehbarkeit: Sind die Änderungswünsche für beide Parteien nachvollziehbar? Sind die Kosten nachvollziehbar?
Änderungswesen: Wurde über den Umgang mit Änderungswünschen schon bei den Vertragsverhandlungen gesprochen?
Flexibilität: Hält der Auftraggeber einen Teil des Projektbudgets zurück, um Änderungswünsche schnell finanzieren zu können? Ist er flexibel genug, um Anforderungen tauschen zu können?
Kapazität: Hat der Auftragnehmer die Kapazität und die Fähigkeiten, um Änderungswünsche zeitnah umsetzen zu können?
Vielfältige Meinungen aus der Agilen Community
Das Thema Festpreis-Projekte hat schon immer vielfältige Reaktionen ausgelöst. Besonders heftig wird in der Agile Community diskutiert.
To say how much something will cost, you need to know in great detail exactly what needs to be built so that your estimates for the work can be accurate. But you can’t define everything you want, in detail and up front, and get it exactly right so there will be no changes in the future. And no estimate is ever accurate (it wouldn’t be an estimate if it was). […] Don’t base the contract with your vendor on conformance to a detailed requirements specification. If you do, you’re saying all your good ideas happen at the start of a project and you’re effectively betting all your money on a hole-in-one
Woraufhin einer seiner Leser seine Erfahrungen mit einem Festpreisprojekt schildert:
[…] fixed price contract where the client and contractor fought endlessly over what was included in the price I endorse everything said above. Unless you are exceptionally lucky your fixed price contract will be toxic to the client supplier relationship.
Mein Fazit zu Festpreis-Projekte ist, das es sich um eine in der Industrie immer noch sehr beliebte Vertragsform handelt, die mit vielen Herausforderungen verbunden ist. Gründe hierfür sind die scheinbare Sicherheit für den Auftraggeber.
Auch bei Festpreis-Projekten kann man (relativ) gut und flexibel auf Änderungen reagieren – wenn Auftraggeber und Auftragnehmer dieses Thema offen angehen und an einer Win-Win-Situation interessiert sind.
Gibt es jedoch kein Grundvertrauen, so kann jedoch schnell eine Lose-Lose-Situation entstehen:
Der Auftraggeber wird im besten Fall bekommen, was er spezifiziert hat – nicht was er wirklich braucht. Ein zunächst preisgünstig erscheinender Anbieter kann sich im Rahmen von Änderungswünschen als vergleichsweise teuer herausstellen.
Für Anbieter stellen Festpreis-Projekte stets eine große Herausforderung da, vor allem wenn im Angebot keine große Marge zu erwarten ist bzw. kein großer Sicherheitspuffer eingepreist werden kann. Im Grunde müssen Festpreis-Projekte deshalb immer teurer verkauft werden, als Projekte die nach Aufwand abgerechnet werden. Hier spielen Risikorückstellungen, Verhandlungsmasse, Puffer und zusätzliche Verhandlungs- und Analysekosten eine Rolle.
Wie jedes Jahr wird es auch dieses Jahr wieder “The Ultimate Meeting” nach Weihnachten (27.12.-29.12.) in Karlsruhe-Durlach geben. Dieses Jahr treffen sich die ganzen “elderly people” … also die Digitalkunstschaffenden wieder in der Durlacher Festhalle.
Zur Erklärung, um was es sich bei der TUM handelt hier ein Zitat von der Webseite:
What is it? The Ultimate Meeting is a computer party dedicated to the realtime computer art scene, also known as ‘the demoscene’. It is organized yearly in Karlsruhe-Durlach (Germany) from the 27th to the 29th of December.
Motto dieses Jahr: “We are very old.”
Gibt auch ein Ermäßigung für all die Rentner ;-)
Mehr Infos auf der Webseite:
Hier der Gewinner 2008 in der Kategorie “Demo” (via Demoscene.tv):
Es geht diesmal um das Thema Gesundheit und Stress im Umfeld von Projekten und Projektmanagement.
Damit ist eine der Fragestellungen: “Wie gehe ich als Projektleiter (gut) mit dem Stress um?”, eine andere, “Wie berücksichtige ich als PL die Gesundheit meiner Projektmitarbeiter?” und “Worauf ist dabei überhaupt zu achten?”.
