PMBOK, 6. Ausgabe und deutsche Übersetzung kommen!

Die 6. Ausgabe des PMBOK ist 2017 angekommen, und einige Definitionen haben es bereits in unsere Website geschafft. Die interessante Nachricht ist, dass die Agile Alliance zum neuen PMBOK beigetragen hat, da immer mehr Stakeholder agile Ansätze in ihren Projekten einsetzen. Das bedeutet auch, dass diese Seite in den nächsten Wochen weitere Begriffe aus der agilen Welt aufnehmen wird.

Außerdem habe ich beschlossen, dass ich eine deutsche Version aller Artikel und Definitionen hinzufügen werde. Dies ist ein enormer Aufwand, der mit Hilfe von maschinenlesbaren Techniken bewältigt werden soll. Gleichzeitig ist es auch ein Test, inwieweit weitere Sprachen auf dieser Seite hinzugefügt werden können. Außerdem ist dies eine gute Gelegenheit, alle 700+ Definitionen noch einmal durchzugehen 🙂

Warum es wichtig ist, Ziele und KPIs zu definieren

Ein Projektleiter wird gebeten, ein Projekt zu leiten, das eine Software verbessern soll. Er spielt mit der Software herum und denkt auch, dass es Raum für Verbesserungen gibt, fragt aber nach Daten, die die Notwendigkeit der Verbesserung unterstützen. Er möchte auch wissen, wie sich eine Verbesserung auf das Geschäft auswirken würde. Was sind die KPIs, die Key Performance Indicators, die zeigen, dass das Projekt erfolgreich ist? Leider hat der Kunde überhaupt keine Daten, es gibt nur ein “Gefühl”, dass etwas nicht stimmt. Da er auch nicht wirklich weiß, was los ist, kann dem Projekt kein Geschäftswert zugeordnet werden.

Der Projektleiter besteht darauf, dass eine Grundlinie benötigt wird, aber der Kunde antwortet, dass er nicht allzu glücklich darüber war, dass ein Projektleiter überhaupt involviert war, da dieses Gespräch zeigt, dass Projektmanagement die Komplexität erhöht und unnötige Schritte in das Projekt einbringt. Klingt seltsam? Nein, das ist eine wahre Geschichte. Und ich habe das mehr als einmal erlebt. Und um ganz ehrlich zu sein, habe ich es auf beiden Seiten des Zauns erlebt: Als Produktmanager war ich oft verärgert über die zusätzlichen Fragen von Entwicklern und Projektmanagern, und als Entwickler oder Projektleiter habe ich gesehen, wie Produktmanager verärgert waren, als ich diese Fragen stellte. Tatsächlich ist der Start eines Projekts ohne klar definierte Ziele und KPIs wie Fliegen ohne präzises Ziel und ohne Instrumente, die Sie wissen lassen, wo Sie sich über den Wolken befinden.

“Eine Software verbessern” ist kein Ziel. Es könnte bedeuten, dass die Software schneller sein sollte, damit die Leute nicht warten müssen, oder dass sie ein schöneres Design haben sollte, oder dass sie einen besseren Benutzerfluss haben sollte oder… aber woher wissen wir, dass es ein echtes Problem gibt?

Betrachten wir das Ganze aus einer anderen Perspektive. Was genau ist das Geschäftsziel der Software? Inwieweit hilft es, das übergeordnete Unternehmensziel zu erreichen? Die Software könnte ein Reporting-Tool sein, bei dem Benutzer Leistungsdaten für ihre Abteilung herunterladen. Dies wäre definitiv eine wichtige Software. Aber was bedeutet “besser”? Bessere Zahlen? Vertrauen wir darauf, dass die Zahlen in Ordnung sind. Reaktionszeiten? Das Knirschen von Zahlen kann eine teure Aufgabe in Bezug auf die Leistung sein, und eine massive Investition kann notwendig sein, um die Wartezeit zu verkürzen. Aber was ist das Geschäftsproblem, wenn die Leute warten müssen? Starren die Leute wirklich auf den Bildschirm, während ein Bericht erstellt wird, wenn sie wissen, dass es Minuten dauern kann? Sie werden wahrscheinlich ihre E-Mails beantworten, während sie warten, also haben wir wirklich ein Problem? Es könnte sich sogar herausstellen, dass es billiger ist, Menschen warten zu lassen, als in einen Maschinenpark zu investieren, dessen Anschaffung und Wartung teuer ist.

Möglicherweise ist die Benutzerfreundlichkeit des Reporting-Tools suboptimal. Benutzer mögen vielleicht nicht auf einen Bericht warten, aber sie verstehen vielleicht, dass es Zeit braucht. Was sie heute nicht verstehen, ist, ob eine Software schwer zu benutzen ist, weil es immer mehr großartige Software gibt. Benutzer können es schwierig finden, zu erklären, was mit einer Oberfläche nicht stimmt, aber sie haben vielleicht das Gefühl, dass etwas nicht stimmt. Die Messung der Benutzerfreundlichkeit ist folglich schwierig, aber eine Sache, die wir tun können, und die ist einfach zu messen, ist die Zeit, die ein Benutzer vom Start der Software bis zu dem Punkt benötigt, an dem er die Anforderung eines Berichts stellen kann. Dies ist vielleicht nicht der beste Weg, um es zu messen, aber es ist einfach zu messen und vielleicht ist “Zeitaufwand” ein guter Indikator für die Benutzerfreundlichkeit und die Gefühle, die ein Benutzer bei der Verwendung der Software hat.

Wir haben gerade den Begriff Indikator verwendet, und damit kommen wir zu den Key Performance Indicators (KPIs). Wenn ein Benutzer heute 10 Minuten braucht, um die Anfrage für einen Bericht einzureichen, wie würde eine “Verbesserung” aussehen? Wann würden wir das Ergebnis des Projekts für erfolgreich halten? Wenn ich es auf 9 Minuten herabsetze, wäre das ein Erfolg? Wir müssen ein Ziel definieren, aber woher wissen wir, ob die Menschen mit 5 Minuten glücklicher sind als mit 6 Minuten? Vielleicht sind 6 Minuten genug? Das Problem ist, dass, wenn Sie die KPIs und Ziele hier nicht definieren, Sie die besten Ergebnisse erzielen können, die Sie sich selbst vorstellen können, aber der Kunde kann trotzdem unzufrieden sein, weil er noch bessere Ergebnisse erwartet hat. Oder hat den Erfolg anders gemessen. Zum Beispiel durch Zählen der Anzahl der pro Woche eingehenden Beschwerden.

Wir werden hier nicht auf alle Details eingehen, aber wie Sie sehen können, kann die Definition des Geschäftsproblems eine schwierige Herausforderung sein. Die Definition der Ziele und der KPIs kann eine noch größere Herausforderung darstellen. Aber wenn Sie in das Projekt starten, ohne diese Übung zu machen, sind Sie zum Scheitern verurteilt. Oder Sie haben einen Produktmanager, der die Ergebnisse eines Projekts als großen Erfolg verkaufen kann, obwohl nichts wirklich erreicht wurde. Aber du willst auf der sicheren Seite sein. Und um ganz ehrlich zu sein, sollten Sie nicht verpflichtet sein, diese Zahlen zu definieren, denn die Person, die das Projekt anfordert, sollte die Notwendigkeit des Projekts bereits nachgewiesen haben. Aber so sieht unsere Realität die meiste Zeit nicht aus. Versuchen Sie, nicht ohne Ziel und Instrumente zu fliegen. Sie werden es eventuell nicht überleben.