Immer wieder stellt sich die Frage wie man ein Digitales Projekt am besten angeht.
Das Projektmanagement Dreieck unserer Väter ist nach wie vor gültig es geht darum Kosten, Zeit und Anforderungen in Einklang zu bringen, so einfach ist das.
Anleitung wie man es macht, aber nicht tun sollte
Wir schreiben ein Lastenheft in dem wir spezifizieren was wir bis wann wollen, lesen die Pflichtenhefte und finden den Dienstleister mit dem besten Preis- Leistungs- Verhältnis.
Die Anforderungen werden von den Fachabteilungen alleine, oder mit klugen Consultants verfasst. In der Zeit in der diese Papiere entstehen gibt es erste Zweifel bei den Verfassern, in der Zeit in der entwickelt wird, werden schon die Ersten Projektmitarbeiter rebellisch und merken vorsichtig an das Projekt eventuell an den Marktanforderungen vorbei läuft, es werden eilig Change Requests formuliert. Der Dienstleister schreit schon bei kleinsten Änderungen, daß, das in seinem angebotenen Konzept nicht vorgesehen war. Man findet Kompromisse, Budget Zeit und feature set werden leicht angepasst. Der Katzenjammer der Projektmitarbeiter wird lauter umso mehr von der Software sichtbar wird, man einigt sich auf eine alles heil machende Phase 2.
Oft geht ein so entstandenes Produkt auch online, man klopft sich auf die schultern und alle sind Helden vor allem weil ja alle wissen, sobald die Zahlen passen gibt es Phase 2 die in der alles gut wird, parallel arbeiten die Fachabteilungen an Ihren neuen, alles gut machenden Anforderungen.
Entweder stellt sich raus das die Zahlen nicht passen und das Projekt wird abgedreht oder es stellt sich heraus, daß das System sehr Heikel und damit teuer, auf Erweiterungen reagiert. Nach einiger Zeit baut man dann so und so alles neu.
Wer schon komplexe IT Projekte gemacht hat und jetzt behauptet, das er das nicht so kennt, ist ein Glückspilz, ein Genie oder hat es einfach anders gemacht.
Wie verbessere ich meine Chancen?
Das Team:
Product Owner
Am wichtigsten ist ein Manager mit umfassenden Befugnissen und vollem Rückhalt von der Unternehmensspitze. Diese Person muss zwingend folgende Eigenschaften mitbringen: Erfahrung, Mut, Entscheidungsstärke, Kreativität, Hartnäckigkeit, Offenheit und Teamgeist. Gehen Sie jeden noch so Faulen Kompromiss ein aber befolgen Sie diese Regeln. Ob diese Person aus dem Unternehmen kommt oder von Extern ist nicht so wichtig wie die eben beschriebenen Anforderungen.
Entwicklungsteam
Ein Entwicklungsteam soll über ausreichend hochkarätige Entwickler verfügen (Junior/Senior Rate maximal 3/1). Gewährleisten Sie, dass die Entwickler mit den Framework und der Programmiersprache entwickeln auf der sie es auch gerne, oft und gut tun. Im Idealfall kann sich das Entwicklungsteam mit dem Produkt identifizieren. Auch hier gilt sie müssen das Team nicht „besitzen“ aber der Product Owner und das Entwicklungsteam müssen eine Einheit bilden. Ideal wäre es wenn Sie Aufgaben wie z.B. Userinterfaceentwicklung und Datenmodellierung aufteilen könnten.
Projektmanagement Office
Das PMO hilft dem Product Owner die Flut an Anforderungen sowie die Kosten und Zeitpläne zu überwachen. Bei kleineren Projekten kann man es eventuell dem Product Owner zumuten diese Tätigkeiten mit zu übernehmen, aber ab 3 Entwicklern ist tendenziell davon Abzuraten. Die Charaktere eines idealen Projektmanagers und eines Product Owners sind unendlich weit voneinander entfernt. Die Eigenschaften eines PMO Mitarbeiters sind: Genauigkeit, Stressresistenz, Dokumentationsfreudig, Zahlenafin.
Expertenteam
Das Expertenteam besteht aus Juristen, Steuerberatern, SEO Experten, UX Beratern, Grafikern… Das Expertenteam verfolgt den Entwicklungsprozess und steht dem Projekt zur Verfügung.
Ansprechpartner in den Fachabteilungen
Die Ansprechpartner der Fachabteilungen kippen Ihre Anforderungen ins Projekt ein und nehmen umgekehrt die Anforderungen des Projektes an die Fachabteilungen entgegen. Diese Ansprechpartner sollten im Idealfall ein echtes Interesse am Projekt haben und sich für diese Aufgabe berufen fühlen. Auswahlkriterien wie wer hat für sowas Zeit sind denkbar suboptimal.
Der Prozess:
Man formuliert grob aber eindringlich was das entstehende Produkt langfristig (Jahre) leisten können soll. Dann wird definiert was das Projekt kurzfristig für einen Funktionsumfang haben sollte. Außerdem erstellt man ein Schriftstück welche Ziele definitiv nicht im Zuge des Projekts erreicht werden sollen.
Dann bewertet man die Potentiale und was bereit ist zu investieren.
Dann kommt der wichtigste und schwierigste Teil der Übung, das Aufstellen des oben beschriebenen Teams und ein schneller Vertrauensaufbau.
Die Verträge sollen so formuliert werden, daß der Product Owner jederzeit jedes Teammitglied aus dem Projekt entfernen kann. Leistungen die bis dahin erbracht wurden, werden aber bezahlt.
Wurden potentielle Teammitglieder gefunden, sucht man nach gemeinsamen Zielen, wollen sich die Teammitarbeiter in irgendeiner Art am Risiko beteiligen, könnte ein gemeinsames Produkt entstehen, wäre das Projekt ein Tolle Referenz …?
Es werden Kosten pro Zeiteinheit verhandelt und grobe Meilensteine definiert.
Sobald der Vertrag abgeschlossen ist fängt man an erste Anforderungen, die man im Besten Fall gemeinsam Formuliert, umzusetzen.
Nach ca. 2 Wochen zeigt man das Ergebnis und bespricht die Aufgaben nächsten 2 Wochen. Der Product Owner muss permanent Risiken, Anforderungen, Chancen und Probleme Abwegen und das Boot ins Ziel bringen, auch wenn der Wind auf die Nase bläst und er kreuzen muss.
Klar ich beschreibe hier nichts anderes als die agile Methode des Projektmanagements, weil ich sie für die realistischste Möglichkeit halte außergewöhnlich gute Ergebnisse mir vertretbaren Aufwand zu erzielen.
Natürlich funktioniert auch, unter gewissen Umständen, der Werkvertrag wie oben beschrieben. Es ist auch denkbar eine erste Phase mit Werkvertrag umzusetzen. Aber was kaum funktioniert ist irgendein hybrid aus Werkvertrag und Agil.
Schreibe einen Kommentar