Tipp für PMP-Aspiranten

Die PMP®-Zertifizierung des Project Management Institute erfreut sich nach wie vor großer Beliebtheit. Ich vermute, es liegt auch daran, dass man sein (theoretisches) Wissen in einer organisatorisch einfachen Form beweisen kann, nämlich durch den vierstündigen Multiple-Choice-Test - Interviewer oder tiefe Überprüfung von Ausarbeitungen usw. werden dabei natürlich nicht eingesetzt. Das ginge schon kostenmäßig nicht.

Wer gerade auf dem Weg zum PMP ist: das PMBoK (Project Management Body of Knowledge) ist anscheinend gerade erschienen. Erfahrungsgemäß dauert es dann ein wenig, bis neue Fragen einsickern in den Fragenpool. 

Tipp: Nutzen Sie eins der zur Zeit häufig angebotenen, kostenlosen Webinare, um sich einen Überblick über die Neuigkeiten zu verschaffen! Auf Xing und Linkedin sollten Sie da schnell fündig werden...

Update: ab August werden die Prüfungen auf Basis des neuen PMBoK® durchgeführt - die 5. Auflage ist bereits erschienen. PMI Mitglieder können sie herunterladen beim pmi.org.

Projekt-Scoping

Ihr Chef hat Ihnen das Projekt übergeben mit den Worten: „Das schaffen Sie schon!“. Nach dem Durchsehen der Unterlagen haben Sie sogar Zeit gehabt, mit dem Projektteam zu sprechen – nur... irgendwie taucht aus dem Nebel keine strahlende Erkenntnis auf?

Vielleicht befolgen Sie sogar den Rat aus einem der letzten Blog-Posts und orientieren sich an den neun Bereichen: dabei fällt Ihnen dann auf, dass insbesondere der Umfang (Scope) und die Kosten nicht klar sind. Was nun?

Kennen Sie den alten Witz mit dem Bildhauer, der von einem begeisterten Kunstfreund gefragt wird, wie er denn so wundervolle Madonnen aus dem Stein herausarbeitet? „Ach, ich meißel’ halt alles weg, was nicht nach Madonna aussieht!“. So einfach ist es zwar nicht – der Ansatz ist aber ähnlich: ich empfehle Ihnen, ein „Scoping“ durchzuführen, also die wesentlichen Inhalte, Kosten und Dauer aus dem Nebel ans Licht zu zerren. 

Für Software-Projekte erstellen Sie iterativ folgende Artefakte:

Business Case

Lohnt sich das Endprodukt? Zumindest sollte jemand identifizieren können, was der Nutzen ist, wenn auch nicht immer in EUR.

Welche Annahmen liegen dem Szenario zu Grunde? Wenn Sie dies wissen, können Sie viel effektivere Entscheidungen treffen!

Beispiel: Sie erstellen eine Verwaltungssoftware, die nicht am Markt als Standardsoftware verfügbar ist. Mitten im Projekt stellen Sie fest, dass ein Softwarehaus mit drei Buchstaben kurz vor der Fertigstellung einer Standardsoftware steht. Was nun? Ist Ihre Lösung noch viel billiger als die neue? Welche Vorteile hat Ihre Lösung, die im Standard nicht zu finden sind? Müssen Sie sich vielleicht noch stärker auf die individuellen Features fokussieren?

Übersicht Geschäftsprozesse

In vielen großen Unternehmen werden von Organisations- oder Optimierungs- oder Prozess-Abteilungen Geschäftsprozesse erfasst, verwaltet und auf fachlicher Ebene analysiert. Dabei reicht die Bandbreite von „Bilder malen“ bis hin zu ausgewachsener BPMN-Modellierung mit direkter Verwendung in Workflow-Engines. Mein Eindruck: es wird häufiger gemalt als modelliert. Das liegt wohl auch daran, dass Fachabteilungen in fachlichen Zusammenhängen denken – nicht in Algorithmen. Sonst würden die Mitarbeiter ja auch schnell in der IT-Abteilung landen...

Gut nutzen kann man Prozess-Landkarten, Bebauungspläne usw. Gibt es bei Ihnen nicht? 

• Tragen Sie horizontal die groben wertschöpfenden Prozessbereiche auf, z.B. Marketing, Akquise / Vertrieb, Abschluss, Leistung / Bestandsverwaltung / Pflege, Austritt / Storno / Beendigung (je nach Branche halt unterschiedlich). 
• Platz für sekundäre Prozessbereiche wie Buchhaltung, Personalwesen etc. ist dann schon meist nicht mehr – die passen auch zur Not auf ein weiteres Blatt. 
• Unter jeden Prozessbereich können Sie die Systeme packen, die daran beteiligt sind.  Oder, um auf die Geschäftsprozesse zu kommen, die feineren Schritte wie „Angebot erstellen“, „Vertrag abschließen“, „Leistungsanspruch prüfen“. Das Blatt füllt sich in der Regel schnell...
• Hilfreich ist oft, die wesentlichen Prozessbeteiligten (als Rollen) in der Senkrechten zu notieren, in der ersten Spalte: dann können Sie die Prozesse schnell den Beteiligten zuordnen.

Tipp: elektronisch (PowerPoint, Visio, Zeichentools) geht das letztlich schneller als auf Papier.

Auf dieser Ebene müssen Sie vor allem herausfinden, an welchen Prozessen Ihr neues System beteiligt sein wird!

Use Case Übersicht

Die konkrete Beteiligung des Systems an den Prozessen betrachten wir dann als „Use Cases“ oder „Anwendungsfälle“. Die Grundidee ist sehr einfach: wer macht was mit dem System? Zunächst mal trägt man alle Akteure und Top-Level Use Cases in einem Diagramm zusammen. Auch wesentliche, fremde Systeme wie die Buchhaltung oder das Dokumentenarchiv sollten hier als Akteure auftauchen.

Diese Top-Level Use Cases bilden die oberste Ebene Ihrer funktionalen Gliederung. Verfeinern Sie diese Ebene durch Use Cases, für die Sie grob erfassen, was gemeint ist: „Einloggen: Benutzer kann sich einloggen mit Möglichkeit zum Password Reset“.

Meist kann man die Verfeinerungen in die Übersicht einbauen: mit einem UML-Tool können Sie z.B. farbige Bereiche einrichten, um das Lesen zu erleichtern. 

Geplante Komponenten

Was müssen Sie eigentlich programmieren, so im Groben? Anfangs fällt dies vielen Beteiligten schwer, weil sie geistig von „Anforderung“ auf „Lösung“ umschalten müssen.

Tipp: Beginnen Sie „außen“: wo sind die „Schnittstellen“ des Systems? Arbeiten Sie sich dann nach „innen“ vor:

• GUI und menschliche Interaktion: Hier finden Sie schnell GUI-Komponenten und meist auch gleich die darunter liegenden Logik-Komponenten.
• Schnittstellen von und zu anderen Systemen: Wie funktionieren die? Zum Einlesen von Dateien brauchen Sie beispielsweise mindestens eine Importkomponente – welche Komponente jedoch führt die fachliche Logik aus?

Aus diesen Überlegungen bestimmen Sie ziemlich schnell Aussagen zu Abhängigkeiten, Umfang und Kosten:

• Erstellen Sie eine Matrix aus Use Cases und Komponenten: im Kreuzungspunkt eine „1“, falls die Komponente im Use Case verwendet wird, sonst eine „0“.
• Denken Sie sehr intensiv nach über Komponenten, die keine oder wenige Einsen haben...
• Lassen Sie erfahrene Architekten oder Entwickler die Komponenten schätzen – in Projekttagen.
• Parallel dazu können Sie durch Komplexitätsfaktoren versuchen, den Aufwand für die Use Cases zu schätzen und mit Aufwandsklassen zu multiplizieren:

Einfach: 2 PT
Mittel: 5 PT
Komplex: 10 PT

• Der Trick: die Trennung von Klassifikation und Zahlen führt zu besseren Schätzungen!
• Zu guter Letzt vergleichen Sie die Schätzungen für Use Cases und Komponenten – und finden Sie heraus, warum es an welcher Stelle Unterschiede gibt.

Der Plan

Wenn Sie die ersten Hürden überwunden haben, müssen Sie natürlich eine Vorstellung über den Ablauf gewinnen – welche Komponenten / Use Cases etc. bauen Sie zuerst?

Wenn Sie agil planen, brauchen Sie nicht alles herunter zu brechen und zu verfeinern! Nur die wichtigen Teile – wenn Sie herausgefunden haben, welche das sind...

Why you should be careful when assigning rewards

You might want to consider the following very interesting talk - would that explain some observations in your project team?

Plötzlich Projektleiter

Kennen Sie den Film „Plötzlich Prinzessin“? Ein amerikanisches Mädchen wird durch absurden Zufall Prinzessin eines europäischen Staates – über Nacht. Eigentlich geht es im Film um die Herausforderungen des Erwachsenwerdens, und eigentlich ist dies eine Teenie-Highschool-Komödie.

Uneigentlich fühlt sich der ein oder andere Informatiker oder Ingenieur aber ziemlich genau so: das Projekt ist wichtig für die Firma (nicht das imaginäre europäische Land, aber immerhin), böse Kräfte (Termine und zugesagte Eigenschaften) bedrohen die Harmonie, plötzlich muss man gesellschaftliche Ereignisse wahrnehmen wie Geschäftsessen in italienischen Restaurants, wo es nicht einmal Pizza gibt.

Meist passiert dies in den „goldenen Zeiten“: viele Projekte, viel Umsatz, kaum verfügbare Leute mit Erfahrung – alle anderen Optionen scheiden für den Chef aus. Denn wer ein guter Software-Entwickler, Architekt oder Tester ist: der ist ja auch ein guter Projektleiter! Dies nennt man in der PM-Literatur übrigens den „Halo-Effekt“ und meint den „Heiligenschein“-Effekt: wenn jemand viel geleistet hat, trauen wildfremde Menschen ihm plötzlich alles zu. 

Wie überlebt man die an sich ja erfreuliche Beförderung? Da hilft ein Tipp aus einem anderen Film, Highlander: „Verlier’ nicht Deinen Kopf, Highlander!“ Im Film ist der Tipp mehrdeutig – Highlander sind unsterblich, es sei denn, ihr Kopf ist weg. Wenn Sie frisch gebackener Projektleiter sind, heißt dies: verlieren Sie vor allem nicht die Übersicht! 

Wo fängt man an? Wie fängt man an? Das ist natürlich in jeder Situation unterschiedlich... Aber: Einarbeiten ist notwendig – haben Sie als Entwickler auch gemacht, als Sie das erste Mal für einen JBoss Application Server entwickelt haben! Nehmen Sie sich die Zeit und verlangen Sie diese auch! Niemand kann von jetzt auf gleich produktiv sein, bei Politikern gesteht man in neuen Ämtern nach Wahlen sogar 100 Tage zu!

Um das Ruder übernehmen zu können, müssen Sie den Standort bestimmen: welche Themen sind relevant? Welchen Zustand hat das Projekt gerade? Wo müssen Sie mehr Aufwand reinstecken und was kann warten? Ich habe Projektleiter erlebt, die sich mit den Risiken des Projektes nicht beschäftigen wollten, weil man Risikomanagement ja sowieso implizit dauernd macht  – logisch! Dafür wurden unrealistische Termine als unveränderbar verkauft...

Hier ein einfacher Vorschlag für eine Übersicht: die neun Bereiche stammen aus dem ANSI-Standard für Projektmanagement, dem so genannten PMBoK (Project Management Body of Knowledge®, Marke und Copyright des Project Management Institute):

Scope: Was?

Was bauen Sie da überhaupt? Und wo ist die Grenze, welche goldenen Wasserhähne können Sie vermeiden?

Tipp: Scope mit den Stakeholdern klären... möglichst früh... auch wenn’s manchmal schwierig ist. Wenn gar nichts klar ist - weder Umfang noch Kosten - führen Sie ein Projekt-Scoping durch (dazu später mal mehr).

Time: Wann?

Wann ist die Software fertig – und wann wird sie gebraucht? Gibt es da womöglich eine Differenz?

Gibt es offensichtliche Engpässe (critical chain) in Ihrem Plan? Kann man etwas parallelisieren – verschränken – beschleunigen? Gibt es überhaupt einen Zeitplan?

Welche Zeitpuffer sind im Plan enthalten und reichen sie aus?

Cost: Was darf’s denn kosten?

Hat eigentlich schon jemand daran gedacht, dass nach Inbetriebnahme womöglich noch Pflegeaufwand benötigt wird für die ersten dramatischen Fehler?

Beinhaltet das Budget wenigstens Puffer?

Wenn Sie noch sehr früh dran sind mit dem Projekt – beinhaltet das Budget dann auch die Vorbereitungen?

Human Resources (HR): Wer?

Sie haben ein Projekt und sogar ein Team vorgefunden – aber wer sind die Leute, auf die Sie sich verlassen müssen? Welche Fähigkeiten haben die und welche fehlen ihnen?

Haben Sie Mitarbeiter – oder haben Sei ein Team?

Tipp: in größeren Organisationen unbedingt mit den Linien-Vorgesetzten absprechen – sonst müssen die Leute plötzlich im Tagesgeschäft „dringendste“ Aufgaben erledigen.

Risk: Wird es klappen?

„Ich weiß schon, was ich tue!“ – „Die Risiken habe ich auch so im Blick.“ – „Wir sind hier ja nicht im Selbstfindungsseminar?“

Was soll man da noch zu sagen? Wer seine Risiken – und Chancen – nicht rational behandelt... Oder, wie man vielleicht den Kapitän der Titanic hätte sagen hören können: „Eisberg? Welcher Eisberg?“.

Tipp: Ihr Budget muss Puffer für bekannte Risiken enthalten, das ist noch relativ naheliegend. Puffer für „unknown unknowns“ brauchen Sie auch! Oft wird dies auch als „management reserve“ gesehen, weil nur das Management das Budget dafür im Ernstfall freigeben kann.

Quality

„Gratluation! Se haben erworben BAnduhr für Arm von highste Qualitaet!“ – warum nur ähneln alle Qualitätsparolen in Projekten diesem erfundenen, aber nicht unüblichen Versprechen? Vielleicht, weil man sich meist keine Gedanken zur Messung von Qualität machen möchte?

Tipp: setzen Sie auf Automation, wo Sie nur können:

• Statische Code-Analysatoren wie Checkstyle, PMD, FindBugs, Sonar, ...
• Unit-Tests für separierte Module (ja, im Prinzip macht die immer jeder und vollständig...)
• Unit-Tests als Integrationstests für interagierende Module, also quasi direkt unter der GUI
• GUI-Tests: ok, das ist manchmal sehr aufwändig und nervig, vor allem bei Rich Clients. In Projekten habe ich schon Java-basierte Scripting Sprachen gesehen, die effektiver als teure Tools den Entwicklern eine Automatisierung erlaubten.

Communication: Mit wem reden Sie eigentlich?

Sie wissen sicher schon, dass Kommunikation mal locker 80% der Zeit des Projektmanagers beanspruchen kann. Damit Sie überhaupt noch zu irgendwas kommen, müssen Sie herausfinden: mit wem kommunizieren Sie wie über was? Also, gefragt sind mal wieder die Stakeholder:

Das PMO will jede Woche einen Bericht per e-Mail, basierend auf dem Excel-Template. Die „friendly user“ möchten einmal im Monat einen Status präsentiert bekommen.

Das Management möchte einmal im Monat von Ihnen am Kaffeeautomaten hören, dass es gut läuft...

Tipp: Identifizieren Sie die Stakeholder – gründlich und vollständig. Nicht alle erkennt man gleich!

Procurement: Wer liefert?

In Ihrem Team haben Sie einen Freelancer – wie lange ist der eigentlich noch da? Reicht das Budget für die Zeit?

Arbeitsintensiv ist auch die Steuerung von Zulieferern wie z.B. Design- und Web-Agenturen! Wann sollen die noch mal was liefern – und in welcher Qualität?

Integration: Und jetzt?

Alle Einzelteile müssen zusammenwirken: wenn Sie die absurden Kosten- und Zeit-Schätzungen Ihrer Vorgänger korrigieren (mit dem Team) und das Projekt dann länger läuft: ist dann eigentlich noch der Freelancer dabei? In welche Risiken können Sie laufen?

Tipp: gehen Sie die Integration iterativ an – dann können Sie korrigieren und optimieren!

Demnächst hier: wie Sie anhand der Bereiche sich auch „on the flight“ überprüfen können.