Close

1. März 2017

Unser Weg zum agilen Projektmanagement

Verändernde Marktsituationen erfordern immer schnellere Entscheidungen sowie höhere Flexibilität. Wie im Artikel Die Evolution der Enterprise Infrastruktur aufgezeigt wird, ist die Agilität auch in der Technologie kein Fremdwort mehr. Durch agile Technologien lassen sich Produkte und Lösungen immer schneller und effizienter einführen.

Nebst der Technologie, hat die Organisationsform einen noch grösseren Einfluss auf Agilität und Flexibilität.  Eine noch so agile Technologie kann zwar innerhalb eines Tages implementiert werden, wenn der interne Beschaffungsprozess hingegen einen Monat dauert, erreicht man dadurch keinen Mehrwert.

Dies hat uns auch der klassische Projekt Management Prozess gelehrt. Die übergeordnete Planung unterschiedlicher und parallellaufenden IT- Projekte ist aufwendig und schwierig. Oft haben Kunden ein akutes Problem, welches zeitnahe gelöst und dadurch auch oft nach erfolgtem Auftrag realisiert werden soll.

Dabei muss auch beachtet werden, dass die richtige Ressource mit den richtigen Kompetenzen zur richtigen Zeit eingesetzt wird. Im Zentrum unseres Handelns steht, jederzeit einen auf den Kunden zugeschnittenen Service mit hoher Qualität abzuliefern.

Bis zum letzten November habe ich das Projektmanagement für alle unsere Cloud- und ICT-Projekte alleine wahrgenommen. Da ich auch sehr stark in unseren Pre-Sales-Prozessen involviert bin, ermöglichte mir dies einen sehr guten Überblick über laufende und kommende Projekte und dadurch auch ein gutes Projekt-Forecasting. Im Projekt- sowie im ServiceDesk-Alltag läuft in der IT jedoch nicht immer alles wie geplant, sodass man immer auf Unvorhersehbares vorbereitet sein sollte. So führte beispielsweise ein durch ein Bug verursachtes Problem zu einer Projekt-Verzögerung oder eine nicht startende Azure-Maschine zu einer Eskalation im ServiceDesk. Solche Probleme konnten nur schwer durch eine übergeordnete Organisation abgefedert werden. Auch fehlte im Alltag, durch die steigende Anzahl der Projekte, die Nähe des Projektleiters beim Kunden. Regelmässige Statustermine wurden durch eher punktuelle Termine ersetzt.

Diese Ereignisse hatten zur Folge, dass wir uns überlegten, eine zusätzliche Projektleiter-Ressource einzustellen, die uns beim Projektmanagement unterstützt. War dies aber die Lösung für unser Problem? Es gab einige Diskussionen bis wir unsere Antwort hatten. Einige der Denkanstösse: Eskaliert ein Projekt, wird primär einfach mal der Projektleiter beschuldigt. Durch eine schlechte Präsenz beim Kunden ist es dem Projektleiter nicht aufgefallen, dass Probleme vorhanden sind. Projekte werden schlecht geplant.

Es ist immer einfacher die Schuld auf andere zu schieben, als selbst die Verantwortung zu übernehmen und Problemlösungen anzustreben. Aber genau das wollen wir doch mit der Agilität: Verantwortung in die Breite verteilen. All diese Punkte haben dazu geführt, dass wir uns gefragt haben: Benötigt es wirklich noch einen klassischen Projektleiter? Benötigen wir diese Trennung von System Engineering und Projektleitung?

Wir sind der Meinung wir benötigen es nicht! Welche Gründe und Lösungen haben uns zu diesem Entscheid geführt?

Agiles Projektmanagement

Wir haben agiles Projektmanagement nicht erfunden. Scrum ist eine Umsetzung von Lean Development und ein verbreitetes Vorgehensmodell des Projekt- und Produktemanagements für agile Softwareentwicklung. Obwohl es ursprünglich in der Softwaretechnik entwickelt wurde, wird es inzwischen auch in vielen anderen Bereichen eingesetzt.

Bei Scrum sollen wenige und einfache Regeln gelten. Das Team wird so zusammengestellt, dass unterschiedliche Kompetenzen zusammenkommen und es sich selbst organisieren kann. Auf Scrum möchte ich in dem Artikel nicht weiter eingehen. Das Essentielle daraus ist, dass es beim agilen Projektmanagement darum geht flexibel und anpassungsfähig zu sein. Anstelle komplexer Planungen und Voranalysen steht die adaptive Planung und schnelle Abstimmung im Team im Vordergrund.

System Engineers sind direkt am Geschehen beteiligt

Die System Engineers sind innerhalb von Projekten tagtäglich mit den Kunden in Kontakt, wissen was gut läuft und was eben nicht. Wieso soll wöchentlich an einen Projektleiter rapportiert werden, welcher entsprechende Statusberichte schreibt und Status-Besprechungen organisiert? Die System Engineers sind direkt am Geschehen dran, womit es leicht fällt ein kurzes Status- oder Stand-up-Meeting mit dem Kunden durchzuführen. Ebenfalls übernahmen die System Engineers auch bisher die technische Verantwortung. Rein die organisatorische Verantwortung wurde dem Projektleiter übergeben. Die Mittel und Tools bleiben mehr oder weniger dieselben, wir ändern nur deren Organisation!

Mit dieser zusätzlichen Verantwortung steigen auch die Anforderungen, wobei bei Diskussionen mit Partnern und Kunden viele sich eher defensiv an das Thema wagen. Die Arbeitswelt ist sich laufend und stark am verändern. Wir sind heutzutage viel näher an den Prozessen der Kunden dran, wodurch diese viel tiefer in die Projekte involviert werden müssen. Es reicht immer weniger, ein Projekt auf technischer Ebene zu realisieren. Wir sehen dies als begleitenden Prozess des Führungsteams im Alltag. Zudem wurden Massnahmen wie das wöchentliche Service Stand-up Meeting eingeführt, bei welchem in der Runde die aktuellen Aufgaben, auch aus Projekten, besprochen werden. Jeder weiss, was der andere die letzte Woche gemacht hat, die kommende Woche geplant hat und welche Probleme ihn beim erledigen seiner Aufgaben behindern.

Mehr Eigenverantwortung und selbstständige Planung seiner Tätigkeiten

Wird das Projekt von einem zentralen Projektleiter verwaltet und geplant, trägt dieser die Verantwortung. Bei einer übergeordneten Planung mehrerer Projekte ist es schwer, jedem gerecht zu werden und dabei auch noch die Verantwortung über alle Projekte übernehmen zu können. Aus diesem Grund soll jeder Einzelne in den Planungsprozess involviert werden.

Innerhalb des Projektteams gibt es keine Hierarchie. Jeder hat dieselben Rechte und Pflichten, aber durchaus unterschiedliche Kompetenzen. Diese Kompetenzen besagen, wer als Projekt-Leader agiert. Den Projekt-Lead zu übernehmen besagt jedoch nicht die Verantwortung auf diese Person abschieben zu können. Die Person übernimmt einzig und allein eine zusätzliche Verantwortung, in dem sie sich um die Projektplanung und primäre Kundenkommunikation kümmert.

Durch die Tatsache, dass die Mitarbeiter die Planung selbst durchführen, sind sie auch selbst dafür verantwortlich ihre Freizeit und andere Bufferzeiten  zu organisieren und zu planen. Wird zum Beispiel eine Umstellung geplant, welche nur in der Nacht durchgeführt werden kann, liegt es im Ermessen jedes Einzelnen, ob er sich am Tag zuvor oder danach Kompensationsstunden einträgt. Für negative Nebeneffekte, wie eine schlecht geplante Umstellung, ist nicht mehr der Chef alleine zu beschuldigen. Jeder Einzelne lernt aus der Situation und wird das nächste Mal entsprechend anders planen.

Die Grundlegenden Problemstellungen rund um das Thema Verantwortung und Planung sind gelöst. Es bleiben die Fragen offen, wie auf Probleme oder Verzögerungen aus Projekten reagiert wird und wie diese in das Team getragen werden können. Auch die Zuteilung der Projekte ist noch nicht gelöst. Wir wünschen uns, dass die Mitarbeiter ihre Projekte selbst auswählen oder zumindest mitbestimmen können. Um auch diese Problemstellungen lösen zu können, haben wir die Stand-up Meetings sowie den Rahmen des Projektmanagement-Boards geschaffen. Wie wir auch diese Themen angegangen sind erfahren Sie in den nächsten Teilen der Blog-Serie «Unser Weg zum agilen Projektmanagement».

Das könnte Sie auch interessieren:

One Comment on “Unser Weg zum agilen Projektmanagement

[…] Unser Weg zum agilen Projektmanagement […]

Antworten

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.