Mittwoch, 7. Dezember 2016

Was sind die einfachsten Grundlagen des Projektmanagements?

Oder: Wie bringe ich Ordnung in mein neues Projekt?


Das PMBoK® listet viele Themen und Wissensgebiete auf: fünf Prozessgruppen stehen 10 Wissensgebieten gegenüber! Fast niemand setzt sie alle um – das ist auch gar nicht das Ziel, vielmehr geht es um eine sortierte Sammlung von best practices. Für jede Situation und jedes Projekt müssen die Verantwortlichen entscheiden, was gebraucht wird. Kommt Ihnen das bekannt vor? Und wie endet es oft? Pseudo-Reporting, Arbeiten auf Zuruf und die „wir schaffen das“-Mentalität?

Stellen Sie sich vor, dass Sie ein Chaos-Projekt übernehmen: wenig Zeit, viel zu tun, hinreichend viele Beteiligte, keine Unterlagen zu finden außer High-Level-Absichtserklärungen, inhaltsleeren Statusreports usw.

Wenn Sie also ganz wenig Zeit haben: Was sind die absoluten Basics?

Hier meine Top 3:

Liste der Aufgaben: wer macht was bis wann?

Eigentlich ganz einfach, oder? Versuchen Sie das mal in einem Projekt, dass kein „so richtiges“ Projekt ist, als Projektleiter ohne disziplinarische Macht... Kommt in der starken Matrix häufig vor: die Linien-Beteiligten haben da so ihre Vorstellungen...

Wichtig:

Wer: nur anwesende Projektmitglieder... keine Verweise auf den Kollegen, der das sicher machen wird, wenn wir ihn fragen. Wenn Sie um Aufgaben für Teams nicht herum kommen: wer ist verantwortlich? Wer muss informiert werden? Im ersten Schritt stellen Sie besser keine RACI-Matrix auf, sonst vergraulen Sie alle, hilft aber bei vielen Beteiligten.

Was: wichtiger als die Aktivität ist das Ergebnis: wird ein Dokument erzeugt? Für welches Publikum? Sind die Kapitel vorher klar? Wie lang soll das werden? Wer prüft es vor Veröffentlichung? Denken Sie wie unsere Kanzlerin (angeblich): vom Ende her!

Bis wann: Konkrete Termine, keine Kalenderwochen. Wirklich. So eine Woche kann schnell mal auf die Folgewoche wechseln. Termine können Sie z.B. in Excel oder JIRA sehr einfach nachhalten. Schlau ist, wenn die Termine nicht „gewürfelt“ werden, sondern mit demjenigen geplant, der die Arbeit ausführt.  Erhöht die Verlässlichkeit ungemein.


Liste der offenen Punkte: wer sorgt für eine Klärung bis wann für welches Thema?

Im Unterschied zu Aufgaben sammeln Sie hier Themen, die vor allem mit projektexternen Beteiligten geklärt werden müssen und während des Verlaufs aufkommen. Als Verantwortlicher müssen Sie die offenen Punkte besonders gut im Auge behalten, häufig verbergen sich große Risiken dahinter. Oft entstehen daraus Aufgaben zur Umsetzung: Muss noch ein SSL-Zertifikat besorgt werden oder hat der Kunde schon das passende? Kann das Deployment nachts erfolgen? Automatisiert?
Natürlich sollte man ein Risikomanagement aufziehen – aber wer schafft das im ersten Chaos schon?

Wichtig:

Wer: wie bei den Aufgaben... nur anwesende Projektteilnehmer...
Bis wann: wie bei den Aufgaben – konkret, von den Verantwortlichen mit getragen, überprüfbar für alle
Was: Was genau ist zu klären – und wofür braucht man die Information? Was passiert eigentlich, wenn es geklärt ist? Müssen Sie dann Aufgaben ändern? Hinzufügen? Schaffen Sie das dann noch?



Budget: virtuelles oder echtes Geld

Fragen Sie sich immer: wer bezahlt das eigentlich? Was ist demjenigen es wert, wenn Sie den Login-Button als rosa Einhorn animieren? Geht’s nicht günstiger?
Das Budget als gleichförmiges Reservoir zu sehen, ist oft gefährlich: wenn Sie am Anfang mehr gebraucht haben als geplant, das holen Sie doch locker wieder auf, oder? Können Sie es herunterbrechen auf Pakete? Features? Oder sogar dem Nutzen gegenüberstellen?
Also erstellen Sie eine Liste aus Paketen und deren Aufwand, so genannten Control Accounts. Dann werfen Sie die Ist-Aufwände dagegen. Ganz einfach?

Die größte Kunst in schwierigen Projekten ist häufig, überhaupt den Ist-Stand zeitnah, wiederholbar und hinreichend genau von allen Beteiligten zu erhalten. Wenn Sie das überhaupt dürfen – was sagt der Betriebsrat? Zumindest sollten Sie – wie im Auto – wissen, wann Sie trockenfallen – das passiert fast immer in einsamen Gegenden in tiefer Nacht...

Wie fangen Sie an? 

Für diese einfachsten Maßnahmen reichen oft einfachste Werkzeuge, im Zweifel Excel. Teurere Tools können Sie später einführen. Sorgen Sie zuerst für Disziplin in einfachen Dingen – das wird die schwierigen Prozesse vereinfachen.


Freitag, 27. Mai 2016

Projektleiter Scrum gesucht?

Derzeit kommt man nicht umhin, für alle möglichen Positionen in der IT angesprochen zu werden, gerne für PHP-Entwicklung in München, selbst wenn man nie PHP gemacht hat und in Norddeutschland wohnt.

Ganz beliebt - auch bei Freelancer-Vermittlern, so hört man - sind Projektleiter Scrum.

Was ist daran verwunderlich?

Gerade in Scrum gibt es einfach keinen Projektleiter - das Gespann aus Product Owner, Team und Scrum Master agiert dynamisch und selbständig, wobei der Scrum Master als "Servant-Leader" dem Team bei der Verbesserung hilft.

Problem: die meisten Aufgaben landen beim Product Owner! Schließlich gibt der theoretisch gesehen auch das Geld. Einen guten Product Owner zu finden, ist schwer, weil die Aufgabenvielfalt einfach sehr groß ist. Der PO in der Scrum-Theorie hat auch den leicht amerikanischen "Boss"-Touch: my way or the highway.

Ist der Scrum Master verantwortlich? In der Theorie: nein. Oder jein. Frage: Wenn Sie 100.000 EUR von Ihrem eigenen Geld investieren, möchten Sie dann, dass jemand verantwortlich ist?

Will sagen: niemand gibt Geld für Selbstverwirklichung und Regentanz-Seminare. Wenn ich als Investor mich entscheide, Scrum zu machen, will ich wissen, dass es auch funktioniert. Ergo muss der Scrum Master zeigen, dass es einen Fortschritt gibt oder er zumindest einen Master-Plan hat. Oder der Product Owner übernimmt das. Ich kann das Geld ja auch traditionell investieren in ein Projekt - also warum sollte ich Scrum wählen, außer, ich muss unbedingt schnell, effizient und effektiv sein?

Scrum ist eigentlich einfach - aber nicht ansatzweise leicht! Es erfordert ein "erwachsenes" Team und völlige Transparenz. Nur dann wird das agile Vorgehen nützlich sein.

Man kann also vermuten, dass viele Scrum machen, weil es so in (der Computerwoche | dem Manager-Magazin | der Wirtschaftswoche) stand. Wie damals in der IBM-Werbung: "Wir müssen ins Internet - Warum? - Steht da nicht!".

Mittwoch, 4. Mai 2016

Rettet Scrum mein Projekt?

Immer, wenn ich auf das Thema Scrum treffe, langweile ich mich fast – der Scrum-Hype ist doch eher vorüber, die Nutzung beginnt. Erkennt man IMHO daran, dass die Computerwoche dauernd berichtet. Sogar im SPIEGEL taucht Agilität in der IT auf, auch wenn ich mich bei IT-Artikeln im SPIEGEL immer frage, ob sie nicht mal was von heise.de einkaufen sollten. 
Zahllose Blogs, Artikel, Fachbücher und Podcasts behandeln so ziemlich jede Facette von Scrum: in der Software-Entwicklung, außerhalb der Software-Entwicklung, Scrum im Unternehmen / Konzern / Start Up, Warum ich nicht Scrum machen sollte, Scrum für Hundeerziehung und und und...

Überraschend aber, wie viele Leute noch nie etwas oder nur ganz wenig von Scrum gehört haben! Neulich kam z.B. die Frage auf, wie denn Risikomanagement in Scrum funktionieren würde – das würde in Scrum ja nicht adressiert?

Das zeigt: lesen hilft – aber reicht nicht. Schließlich ist Scrum ja gerade dazu gedacht, Risiken zu vermeiden, indem man eben nicht erst am Ende merkt, dass die Lösung nicht zum Problem passt. Warum ist das Scrum-Framework so schwer zu verstehen?

Der immer noch eher knappe Scrum-Guide lässt viel weg – und das lässt viele Fragen offen, vor allem, wenn der Leser nicht über jahrelange Projektleitungserfahrung verfügt.


Was braucht man alles in einem Projekt?

Eine Roadmap-Planung mit Meilensteinen

Warum? Trotz aller Agilität: auch hier geben wir Geld aus, und der Geldgeber will wissen, ob er noch was dafür bekommt. 

Wie? Wir behaupten aber vorher nicht, dass wir die Meilensteine scharf voraussagen können! Sondern zeigen auf, WAS einen Wert hat, WANN es logischerweise kommen soll und WANN wir glauben, dass es kommen könnte.

Risiko-Betrachtung

Warum?Weil der Product Owner das viele Geld nicht riskieren darf – wenn es weg ist, ist auch das agile Projekt schnell vorbei 

Wie? Vom Kunden und Produkt zum Inkrement: wenn der Product Owner die größten Risiken kennt, dann adressiert er sie – natürlich – in den ersten Sprints!

Budget

Warum? Ohne Moos nix los – auch bei Scrum. Was kostet das Ganze? Wie lange reicht das Budget? 

Wie? Der Product Owner kann leicht Budgets planen: bei 5 Mitarbeitern zu 4 PT pro Woche und 2 Wochen Sprint-Dauer kostet der Sprint 40 PT. Meistens ist gemeint: was kostet das Feature? Oder die Anwendung? Das ist eine typische Falle: fast alle Vorhersagen sind weit daneben. Meine Projekte als Projektleiter waren natürlich immer alle in Time und Budget – nur nicht in den VOR dem Projekt festgelegten Werten...

Festpreis

Warum? Wir sind agil, der Kunde auch, aber Festpreis muss schon sein – sonst spielt der Einkauf nicht mit. Und überhaupt, man muss ja wissen, was man bekommt! 

Wie? Agil hat einen massiven Kosten-Overhead – den man gerne bezahlt, wenn man sonst mit hoher Wahrscheinlichkeit ALLES verliert – und da muss man nicht über Flughafenbauten lästern, Software ist ein schwarzes Loch für Euros. 
Nutzen Sie Agilität vor allem dann, wenn Sie MIT dem Kunden ein komplexes Problem lösen wollen – und wirklich wollen! Ein agiles Projekt ist kein Hobby, das man sich zulegt, weil es in der Computerwoche stand – es löst fundamentale Probleme, für die auch der Kunde von gewohntem Verhalten abrücken wird, wenn er genügend Vorteile daraus zieht. Ansonsten lesen Sie die vielen Blogs zu agilen Festpreisen...

Empfehlung

Springen Sie nicht zu kurz bei agilen Projekten, der Overhead wird nicht weniger, sondern mehr! Nutzen Sie die Vorteile, wenn sich die Gesamtrechnung lohnt.

Und lesen Sie meine anderen Blog-Posts zu Agile... 



Sonntag, 29. November 2015

Letzte Chance auf PDUS - vor dem Auge des Sturms

Das PMI (R) ändert die Regeln für die Anerkennung von PDUs. Künftig muss man als PMP das "Talent Triangle" bedienen: Technical Project Management, Business & Management, Leadership - alles im Zeichen von "Education".

Startet ab: 1.12.2015

Heißt soviel wie: Jetzt schnell noch PDUs eintragen lassen!



PS: Auch für die Beschäftigung mit dem Triangle kann man ja mal PDUs anmelden, gelle. 0.5 machten jedenfalls keine Probleme...

Sonntag, 21. Juni 2015

Agile Techniken – Story Points

Was ist das?

Story Points sind numerische Werte, meist angelehnt an Fibonacci-Zahlen: 0, 1, 2, 3, 5, 8, 13, 20, 40, 80. Das Scrum-Team verwendet sie zur Bewertung der Komplexität von Anforderungen in Stories.
Sie dienen als „psychologischer Trick“ und Diskussionsanker, um Komplexität zu bewerten und zu erforschen.

Wozu kann ich das verwenden?

Die Erstellung von Aufwandsschätzung ist fehlerbehaftet:
  • Menschen sind schlechte Schätzer – und zwar fast alle! Insbesondere haben wir keinen Instinkt für Wahrscheinlichkeiten. Zur Illustration kann ich nur empfehlen: Rolf Dobelli, Die Kunst des klaren Denkens
  • Menschen halten sich jedoch für gute Schätzer, die wenigsten kennen jedoch ihr „Handicap“.
  • Implizite Annahmen und widrige Umstände führen zu massiven Schätzabweichungen. Umso mehr, wenn z.B. in der Softwareentwicklung gerade mal wieder Hektik vorherrscht und man keine Zeit für endlose Analysen hat.
  • In Stresszeiten gerät man häufig auch unter Druck: „Das können wir nicht verkaufen“ – „Das muss doch einfacher gehen, die sollen mal richtig programmieren und nicht rumprobieren“. 

Der Trick der Story Points ist nun die Loslösung der Komplexität vom Aufwand: Wenn ich einmalig 1000 Sätze in einer Excel-Tabelle bearbeiten muss mit einfachen Editier-Vorgaben, dann ist dies womöglich aufwändig – aber nicht komplex! 
Muss ich jedoch die gleiche Excel-Tabelle aus meiner Anwendung erzeugen, dann kann das komplex sein: woher bekomme ich die Daten? Welche Umwandlungen muss ich vornehmen? Sind diese Transformationen algorithmisch lösbar oder nur durch Menschen? Welche Zeichensätze verwende ich?

Agile Teams verwenden Story Points, um Komplexität zu bewerten und in eine Diskussion zur Erforschung der Anforderungen einsteigen zu können: Abweichungen in den Einschätzungen im Planning Poker zeigen Bedarf zur Klärung von Annahmen auf – wenn die Fragen geklärt sind, dann kann das Team die Anforderung realistisch einschätzen.

Worauf muss ich achten?

Meist nutzt das Team implizit oder explizit einen Wert für „unendlich“ oder „viel zu hoch“, z. B. die 100. Die Fibonacci-Reihe ermöglicht eine Vorstellung über die Größenordnungen – jedoch müssen die Teammitglieder in den ersten Zyklen gemeinsam eine Skala nach und nach festlegen.

Gerne verwenden Anfänger Stunden statt Story Points – weil das Management ja Aufwandschätzungen, Budgets und Pläne verlangt und man das jahrelang so gemacht hat. Häufig haben diese Teams noch nicht am eigenen Leib erfahren, wie gefährlich Schätzungen und darauf basierende Aussagen sind: wenn ein Auslieferungstermin nicht gehalten oder ein Budget überschritten wird, ist oft noch das Management in der Pflicht – nicht das Team. 
Abschätzungen in Story Points helfen dem Team, sehr schnell und effizient Fallstricke zu identifizieren und Komplexität in den Griff zu bekommen.
So kann das Team vom Product Owner verlangen, eine komplexe Story aufzuteilen in beherrschbare Teile, um das Risiko zu verringern.

Beispiele 

Story: „Als Anwender kann ich mich jederzeit ausloggen, damit ich den Zugriff auf  meine Daten verhindern kann.“
Das Team bewertet die Komplexität einstimmig mit 2, weil neben dem Logout im Test geprüft werden muss, ob der Anwender noch Zugriff nach Logout hat.

Story: „Als Anwender kann ich die angezeigten Daten der Maske als XML abrufen, damit ich sie in anderen Anwendungen weiter verwenden kann.“
Das Team bewertet mit: einmal 1, viermal 3, einmal 8. Das Teammitglied mit der niedrigsten Schätzung (1) befragt das Teammitglied mit der höchsten Schätzung (8), worin die Komplexität besteht. Es stellt sich heraus, dass ggf. ein XML-Schema zu verwenden ist oder eine DTD, während die einfachste Variante in einer Standard-Konvertierung der verwendeten Library besteht. Der Product Owner entscheidet sich für die einfache Variante, erneutes Pokern führt zu einer einstimmigen 3.

Story: „Als Anwender kann ich jede Maske auf DIN-A4 ausdrucken, damit ich die Inhalte mitnehmen kann.“
Das Team bewertet fast einstimmig mit 80, weil unklar ist, wie viele Masken es gibt und ob sie überhaupt auf das Format angepasst werden können. Daraufhin gibt sie dem Product Owner die Story zur Reduktion zurück. Der Product Owner ändert die Story in „Als Anwender kann ich die Maske Nr. 1 ohne Grafiken in einer Druckansicht im Browser anzeigen, damit ich sie über die Browser-Funktionalitäten ausdrucken kann.“




Samstag, 20. Juni 2015

Agile Techniken – Planning Poker

Was ist das?

Planning Poker ist eine Methode zur Einschätzung von Themen in einer Gruppe.

Wozu kann ich das verwenden?

Zunächst verwenden Scrum Teams das Planning Poker zur Bewertung der Stories aus dem Backlog. Dies geschieht meist während des Sprint Planning Meetings. Der Product Owner kann das Team auch an anderen, geplanten Terminen bitten, die Stories zu bewerten. Dadurch kann er anhand der Story Points und der durchschnittlichen Velocity abschätzen, wie viele Sprints bzw. die Umsetzung des gesamten Backlogs dauern würde.
Oft ruft der Product Owner das Team vor dem Sprint Planning zusammen, um die Stories für den nächsten Sprint zu bewerten – das hilft ihm vor allem, frühzeitig Unklarheiten und implizite Annahmen aufzudecken, die sonst erst im Sprint erkannt werden. Ein guter Product Owner zerlegt komplexe Stories in weniger komplexe, um die Risiken zu minimieren.
Man kann Planning Poker auch für die Priorisierung von Themen nutzen, z.B. in einem Meeting mit zu kleinem Zeitfenster: dann legt das schnelle Bewerten eine gemeinsame Reihenfolge fest. Gleichzeitig werden unterschiedliche Bewertungen im Team deutlich. Die Priorität ist dabei nach oben offen – damit nicht wieder „Priorität 0“ eingeführt werden muss.
                                    

Worauf muss ich achten?

Der Ablauf ist:
  1. Der Product Owner stellt die Story aus dem Backlog vor.
  2.  Das Team stellt Verständnisfragen zur Klärung – Diskussionen finden dabei nicht statt.
  3. Alle Teammitglieder zeigen gleichzeitig ihre Schätzungen. Sie schätzen dabei die Komplexität – nicht den Aufwand: 1000 Blätter zu falten ist aufwändig, aber nicht komplex. Aus einem Blatt einen Papierflieger zu falten, der 10 Meter weit fliegen kann, kann ziemlich komplex sein.
  4. Falls sich unterschiedliche Einschätzungen ergeben: Die Teammitglieder mit der höchsten und niedrigsten Schätzung diskutieren ihre Annahmen – alle anderen schweigen.
  5. Falls zu viele Fragezeichen oder sehr unterschiedliche Bewertungen gezogen  werden, kann das Team die Überarbeitung der Story durch den Product Owner verlangen.
  6. Falls Fragen geklärt wurden, wird die Pokerrunde wiederholt.
  7. Bei Einigkeit vermerkt der Product Owner die Story Points zur Story.
  8. Der Scrum Master achtet auf eine zügige Abwicklung.


Das Team muss dafür sorgen, dass auch Teammitglieder schätzen können, die das Thema vorher nicht oder nur ansatzweise kennen – insbesondere sind keine Expertenschätzungen gewünscht, weil die Experten womöglich gar nicht zur Verfügung stehen. Eine Vorherrschaft von einzelnen Experten steht auch der Bildung eines leistungsfähigen Teams entgegen.

In den Diskussionen zu höchster und niedrigster Schätzung geht es nicht um Meinungen, sondern um Risiken, Grundannahmen, unterschiedliche Vorstellungen über den Umfang der Arbeiten, ...
Das Team kann zu neuen Einschätzungen gelangen, etwa, dass der Product Owner die Story zurücknehmen und überarbeiten muss.
Oft hilft es bei komplizierten Sachverhalten, die Kernaussagen und Argumente zu verdichten auf das Niveau der „Schlagzeilen einer Boulevard-Zeitung“ – prägnante Begriffe und Sätze helfen, die unterschiedlichen Varianten abzugrenzen, auch wenn sich hinter ihnen viele Details verbergen.

Ein effizientes Planning Poker erfordert eine disziplinierte Diskussionskultur in der Gruppe.

Beispiele

Der Product Owner lässt das Team Planning Poker für Stories aus dem Backlog durchführen, damit er anhand der Bewertung die Verteilung der Stories auf die nächsten Sprints planen kann – und damit z.B. dem Kunden die mögliche Gesamtdauer ankündigen kann.

Das Team ist frustriert, weil zu viele Themen in einer Besprechung zu diskutieren sind. Andererseits kann es sich auch nicht auf eine Priorisierung einigen. Der Scrum Master lässt das Team per Planning Poker die Prioritäten festlegen. In der folgenden Timebox werden dann die Themen nach absteigender Priorität bearbeitet.