Jedes neue IT-Projekt ist individuell, deshalb ist es für mich als Product Owner wichtig, es auch individuell zu bewerten und anzugehen. Trotzdem gibt es Punkte, die im IT-Projektmanagement unerlässlich sind und an denen ich mich orientiere. Diese werde ich im folgenden Blogbeitrag darstellen.
Meiner Erfahrung nach gibt es drei unterschiedliche Arten von Projekten: Erstens diejenigen, in denen man alle Informationen erarbeiten muss, zweitens Projekte, die in einem gut organisierten Umfeld stattfinden, und drittens solche, deren Anforderungen bereits mit Projektstart feststehen und die demnach dem Wasserfallmodell folgen.
Doch in welchen Umfeld das Projekt auch stattfindet: Der Product Owner hat das Ziel, einen Backlog zu schaffen, ein Mission Statement zu schreiben und eine Roadmap zu verfassen. Bei einem Backlog handelt es sich um die gesammelten Anforderungen an die Software. Das Mission Statement zeigt das Ziel und den Mehrwert des Produktes auf. Die Roadmap ist als strategischer Plan für das Projektmanagement zu verstehen, in dem alle Schritte aufgelistet sind. Hierfür kann zum Beispiel Kanban genutzt werden.
Projekt ohne klare Anforderung: Sorge pragmatisch für zügige Arbeitsfähigkeit
Es mag zunächst ungewöhnlich klingen, jedoch sind Projekte ohne klar definierte Anforderung nicht selten. Hier gilt es, den Kopf nicht zu verlieren! Ruhe ausstrahlen und sich seinen Arbeitsplatz so gestalten, dass man Ergebnisse erzeugen kann. Die folgenden Schritte sind eine mögliche Reihenfolge, können jedoch in der jeweiligen Situation variieren.
- Zugriff auf Ressourcen verschaffen (Informations- und Dokumentationssysteme oder bereits existierendes Backlog)
- Stakeholder identifizieren
- Persönliche Meilensteine setzen: Wann will ich welchen Teil der Vorhabensinfrastruktur organisiert haben.
- Pragmatisch die Aufgaben bearbeiten
- Backlog aufstellen, falls dies noch nicht existiert, und Themencluster sortieren
- Projektteam briefen, Regeln kommunizieren
- Roadmap generieren
Dieses Vorgehen schafft Ruhe, welche besonders nützlich ist für:
- Management von Ergebniserwartungen
- Herstellen von Transparenz über die Arbeit, sowohl dem Team als auch dem Kunden gegenüber
- Priorisierung, Sortierung und Verständnis für Anforderungen schaffen
- Formulierung und Veröffentlichung des Mission Statements
- Erstellung einer Roadmap
- Management des Teams und der Vorgehensweisen
Projekt im organisierten Umfeld: Hole alle ins Boot
Befinde ich mich in einem gut organisierten Umfeld, dann ist es eine gute Idee, mit den primären Stakeholdern Interviews zu führen. Sachverhalte, die häufig ähnlich beschrieben werden, eignen sich als Epic und helfen mir, zügig Cluster für Anforderungen zu formulieren. Diese schnelle Vorsortierung schafft ein übersichtliches und meist ebenso einfach priorisierbares Backlog. Ich finde: Ein guter Ausgangspunkt, um eine Roadmap zu erzeugen, ein Mission-Statement zu schreiben und eine Entwicklung zu starten.
Bevor dies geschehen kann, müssen jedoch alle Beteiligten informiert werden. Der selbstbewusste Product Owner erinnert sich dann an seine Requirements-Engineering Ausbildung: „Stellen Sie sich vor, ich bin drei Jahre alt, erklären Sie mir doch bitte, was Sie tun.“
Erste Hilfe bei Wasserfallprojekten
Es gibt Projekte, bei denen der erste Arbeitstag mit 200 Seiten bereits ausgearbeitetem Pflichtenheft beginnt. In einem Themenspektrum, welches für den Product Owner Neuland ist, komplex bis unverständlich. Wichtige Aufgabe hier: Nicht im Meer der Details untergehen, sondern nach einer klar definierten Struktur vorgehen mit dem Ziel, sich Zeit zu verschaffen:
- Team organisieren
- Basisarchitektur entwerfen
- Rahmenwerk implementieren oder instanziieren
Wer die oben genannten Schritte ausführt, geht in Vorlage und schafft sich Luft zum Atmen. Trotz des Pflichtenheftes muss der Product Owner also selbstbewusst genug sein, die Anforderungen an das Produkt selber zu entwickeln. In der Zwischenzeit kann man die sorgfältig zusammengestellten Anforderungen ein wenig am Projektrand reifen lassen.
In der gewonnenen Zeit gilt es, die richtigen Informationsquellen, mit den aktuellen Anforderungen und Problembeschreibungen zu finden. Nicht zu vergessen: Ein persönliches Gespräch ist oft effektiver als das reine Lesen des Pflichtenheftes. Man sollte sich also vor allem zunächst auf die Suche nach dem richtigen Ansprechpartner machen.
Sind alle Informationen strukturiert, können diese direkt in das Backlog überführt werden. Dabei ist jedoch zu beachten, dass Anforderungen möglicherweise bereits nicht mehr aktuell sind und eine Überarbeitung vorgenommen werden muss.