Einführung des Microsoft Project Servers mit agilen Methoden
Die Einführung einer Microsoft Project Server-Lösung ist – sofern bestimmte Grundbedingungen erfüllt sind – ein ideales Szenario für einen agilen Ansatz bei Konzeption und Umsetzung. Bereits im Standard ist Microsoft Project in der Lage, 60 – 70 % des „Grundgerüsts“ dessen abzubilden, was Unternehmen an standardisiertem Projekt- und Portfoliomanagement für ihre Tagesarbeit benötigen. Darüber hinaus gehende, benutzerspezifische Anpassungen, Wünsche an ein unternehmenseigenes „Look & Feel“ oder selbstentwickelte „best practices“ lassen sich rasch auf dem Standard aufsetzen und für den Anforderer überprüfbar umsetzen.
Vor allem erfüllt der Project Server eine der wichtigsten Voraussetzungen für agiles Arbeiten: Das Produkt lässt während seiner Entstehung rasch getaktetes Feed-Back zu. Die Kommunikation mit dem Anwender wird intensiver und im Ergebnis erfolgreicher, weil sie greifbare und verprobungsfähige Inhalte zum Gegenstand hat.
Agiles Projektmanagement setzt auf Flexibilität und Anpassungsfähigkeit in der Projektarbeit. Doch um die Project Server-Lösung agil und erfolgreich einzuführen, muss eine Reihe von Voraussetzungen erfüllt sein:
- Das Unternehmen braucht eine klare und verbindliche Vorgehensweise beim Projektmanagement. Häufig verfügen Unternehmen über mehrere parallele, zum Teil dokumentierte, zum Teil intuitiv wirksame Ansätze im Projektmanagement, und die Technik wird nicht zuletzt eingeführt, um hier quasi „durch die Hintertür“ zu einer Vereinfachung und Standardisierung zu gelangen. Der Wunsch ist legitim; die strategischen Entscheidungen zum Projektmanagement müssen aber im Vorfeld eines Einführungsprojekts nach agiler Methodik getroffen sein.
- Auf Kundenseite gibt es einen oder mehrere verantwortliche und ermächtigte Manager (z.B. PMO-Leiter), die als „product owner“ rasches Feed-Back an die Entwickler geben und Anpassungen direkt priorisieren oder entscheiden können. Dies ist notwendig, weil agiles Arbeiten nicht nur seitens des operativen Projektteams große Leistungsbereitschaft bei gleichzeitiger gesunder Einschätzung der eigenen Leistungsfähigkeit verlangt. Auch der Auftraggeber muss in der Lage sein, das Tempo mitzugehen und Ergebnisse am Ende einer Entwicklungszyklus („sprint“) zu bewerten und verbindlich abzunehmen. Es versteht sich von selbst, dass der Vertreter des Kunden und sein Kernteam sich die Zeit und den Freiraum geschaffen haben müssen, um die Ergebnisse der Projektarbeit in ihrer Praxis zu testen.
- Das Unternehmen bringt nur geringe „Altlasten“ in das agile Projekt mit ein. Der Grund dafür liegt vor allem darin, dass die Entwickler sich ansonsten veranlasst sehen, ein bestehendes (meist lückenhaft dokumentiertes) System mit seinen Prozessen „nachzubauen“. Dabei steht häufig nicht die Effizienz und praktische Handhabbarkeit im Vordergrund, sondern ein historisch gewachsenes Konglomerat verschiedener Stakeholderinteressen, die in unterschiedlicher Weise mit der bisherigen Lösungen in Ablehnung oder Zustimmung verbunden sind.
Wenn diese Voraussetzungen vorliegen, ist es möglich, den Anwendern innerhalb von 1 – 2 Wochen einen feedback-fähigen Prototypen bereit zu stellen und die Änderungen und Ergänzungen der Nutzer danach in einer kurzen Taktung zu managen.
Ein solcher agiler, d.h. auf laufende Anpassung zielender, Ansatz begegnet einem der Kernprobleme traditioneller Softwareentwicklung: Die Anforderungsaufnahme wird zu einem Zeitpunkt, in einer Terminologie und in einem Umfang durchgeführt, den die späteren Anwender – insbesondere wenn sie bislang keine Kontakt mit systemgestützten Projektmanagement hatten – nicht ohne weiteres mit ihrer konkreten Projektarbeit in Einklang bringen können. Der traditionelle Weg, die Anforderungen zu Beginn des Projekts und quasi als Startpunkt der eigentlichen Entwicklungsarbeit aufzunehmen, gestaltet sich für den Kunden oft als ein abstrakter und wenig fassbarer Prozess.
Wenn es gelingt, die Einführung des Microsoft Project Servers mit einer agilen Methode durchzuführen, ergeben sich daraus unserer Erfahrung nach eine Reihe von Vorteilen:
- Das Projekt kommt zügig zu Ergebnissen, die die Grunderfordernisse des Projektmanagements abbilden und sofort für die Praxis taugen.
- Auftraggeber und externer Berater verfügen beide über Transparenz hinsichtlich des Erreichten und – oft wichtiger – des in absehbarer Zeit noch zu Erreichenden.
- Die enge und häufige Kommunikation sowohl zwischen Entwickler und Anwender als auch im Weiteren innerhalb der Kundenorganisation zwischen Erstanwendern und dem Kreis weiterer Projektmitarbeiter kanalisiert die Veränderung, die in vielen Fällen mit dem Auf- und Ausbau eines standardisierten Projektmanagements einhergeht.
- Die spätere Einführung der Microsoft Project Server-Lösung „in der Fläche“ und die Betreuung des Systems durch Fachadministratoren auf Auftraggeberseite sind insofern vereinfacht, als dass die technische Lösung oft schon als „eigenes Baby“ empfunden wird, bevor die formelle Übergabe an die Organisation stattgefunden hat. Die Key User haben so intensiv Anteil an der technischen Lösung genommen, dass die Vermittlung an weitere Nutzer im Unternehmen vergleichsweise reibungslos erfolgen kann.
