Hier ein Beispiel, das ich aus eigener Erfahrung kenne, wobei ich im Sinne der Anonymisierung offen lasse, in welcher Rolle ich hier beteiligt war. Es ist ein Beispiel dafür, wie durch gezielte Suche nach dem wirkungsvollsten Punkt (und das ist nichts anderes als das Ansetzen am aktuellen Engpass) sehr rasch zur Problemlösung führen kann.
Ein Unternehmen hatte sich nach einem gescheiterten und Projekt, das gemäß einem klassischen Wasserfallmodell durchgeführt worden war, für ein agiles Vorgehen entschieden. Dieses war weitgehend am Scrum-Modell ausgerichtet, es wurde auf Grundlage von User Stories entwickelt, die mit Story Points bewertet wurden. Es gab fixe Iterationszyklen („Sprints“) von 6 Wochen Dauer. Die Softwareentwicklung erfolgte durch einen externen Dienstleister, der zum gleichen Konzern gehörte, die Zusammenarbeit erfolgte allerdings trotzdem in einem typischen Kunden-Dienstleister-Verhältnis. Derselbe Dienstleister, überwiegend sogar mit denselben Personen, hatte auch das gescheiterte Projekt ausgeführt.
Ursachenanalyse darf nicht an der Oberfläche bleiben
Aufgrund der problematischen Vorgeschichte wurde ein externer Projektmanager mit seinem Team als Projektcontroller hinzugezogen. Informell war mit dem Auftraggeber besprochen, dass dieser Auftrag sehr weit zu verstehen sei und letztlich auch ein Risikomanagement als Frühwarnsystem für auftauchende Probleme beinhalten sollte.
Auch wenn das Vorgehen offiziell nicht am Paradigma des Extreme Programming ausgerichtet war, sollten doch Vertreter der Anwender regelmäßig den Entwicklern vor Ort für Auskünfte zur Verfügung stehen. Bald häuften sich die Klagen von Seiten des Dienstleisters, dass entgegen den Vereinbarungen von Seiten des Kunden nicht genügend fachkundige Personen zur Verfügung gestellt würden und dadurch der Projekterfolg, jedenfalls aber Termin und Aufwand gefährdet seien.
Das Projektcontrolling war gefordert, dieses Risiko zu prüfen, hinsichtlich seiner Relevanz zu beurteilen und geeignete Maßnahmen vorzuschlagen.
Man durfte nicht davon ausgehen, dass das berichtete Problem tatsächlich der Engpass des Projektes war. Eine Möglichkeit war etwa, dass es nur ein Vorwand war, um das Budget zu erhöhen. In diesem Fall wäre zu prüfen, ob der Mehraufwand tatsächlich gerechtfertigt wäre und dann auf Top-Management-Ebene eine Vereinbarung zu treffen. Aufgrund der Konzernverflechtung und des agilen Vorgehens wäre das Beharren auf einem angebotenen Preis wenig sinnvoll bzw. durchsetzbar gewesen, die Konzernleitung legte Wert auf eine verursachungsgerechte Verrechnung von Aufwänden zwischen den Konzerngesellschaften.
Ein erstes Screening ergab keine Indikatoren für eine (vom Auftraggeber nicht registrierte) Erweiterung der fachlichen Anforderungen oder für Effizienz‑ oder Know-How-Defizite auf Seiten der Entwickler. Vielmehr stellte sich heraus, dass das berichtete Problem tatsächlich zutraf. Die Ursache war allerdings nicht fehlende Bereitschaft auf Seiten der Anwender. Diese berichteten, dass sie anfangs regelmäßig vor Ort waren, es für sie allerdings nichts zu tun gab bzw. kein Ansprechpartner verfügbar war, weil alle in Frage kommenden Personen mit ihren Entwicklungsaufgaben ausgelastet waren.
Da die Anwendervertreter nicht von ihrem Tagesgeschäft entbunden waren, zogen sie es bald vor, die Anwesenheiten vor Ort zu reduzieren, was für sie als Vertreter des Kunden problemlos möglich war und zunächst vom Entwicklerteam eher dankbar („Kunde stört“) und daher ohne Widerspruch zur Kenntnis genommen wurde. Als dann allerdings bei den Abnahmen Probleme auftauchten, weil Anforderungen unvollständig oder aufgrund von Missverständnissen falsch umgesetzt worden waren, erinnerte sich das Management des Dienstleisters an die Mitwirkungspflichten des Kunden und tatsächlich waren diese nachweislich nicht im vereinbarten Ausmaß erbracht worden.
Die Lösung liegt im Detail und ist oft überraschend einfach
Die Lösung war überraschend einfach. Es wurde für die Anwesenheit ein genauer „Stundenplan“ vereinbart, dies beinhaltete auch eine Vorschau auf die im Fokus stehenden Themen. So konnte die Anwesenheit von Anwendern vor Ort selektiv gesteuert werden und gleichzeitig war es nachvollziehbar, wenn entweder die Anwender nicht erschienen oder die Ansprechpartner von Seiten der Entwicklung nicht verfügbar oder nicht gut vorbereitet waren. Ein Mitarbeiter des Projektcontrollings war in den ersten Wochen regelmäßig vor Ort, um diesen Prozess zu steuern und zu kontrollieren, dies war allerdings schon nach wenigen Monaten nicht mehr notwendig bzw. verlagerte sich der Tätigkeitsschwerpunkt des Controllers auf die Testkoordination als Mittel der Fortschrittskontrolle.
Das Projekt konnte erfolgreich abgeschlossen werden, alle Parameter lagen im angestrebten Bereich. Die Identifikation des wirkungsvollsten Punktes hat es in diesem Fall ermöglicht, mit sehr geringem Aufwand eine große Wirkung zu erreichen.
Webmentions
… [Trackback]
[…] Find More on that Topic: it-governance.blog/engpassorientiertes-projektmanagement-ein-fallbeispiel/ […]
… [Trackback]
[…] Information on that Topic: it-governance.blog/engpassorientiertes-projektmanagement-ein-fallbeispiel/ […]
… [Trackback]
[…] Here you will find 56624 more Info to that Topic: it-governance.blog/engpassorientiertes-projektmanagement-ein-fallbeispiel/ […]