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...