Dank Basisausbildung zu erfolgreichen Projekten

Die IT ist im Umbruch – dies ist keine wesentliche und bahnbrechende Neuheit dieser Tage. Wurde früher das Wasserfallmodell den Bedürfnissen angepasst, das in aufeinander folgenden Projektphasen aufgebaut ist, so haben sich mit der Zeit weitere Projektmanagement-Methoden etabliert, wie beispielsweise UP (Unified Process), das V-Modell, bis hin zu den heute präsenten agilen Methoden, von denen es eine ganze Reihe gibt.

Heute unterteilen wir die Methoden gerne in klassische Methoden und agile Vorgehensweisen. Die klassischen Methoden werden eher mit einem sequenziellen Vorgehen assoziiert. Agile Methoden verfolgen einen iterativen Ansatz in sich wiederholenden kleineren Schritten.
In der Praxis, das heisst bei den Firmen in der Wirtschaft und auch bei der öffentlichen Verwaltung, werden diese Methoden nicht nach der reinen Lehre umgesetzt. In Unternehmen findet man oft Hybridversionen vor, welche mehrere Methoden kombinieren und an die jeweilige Organisationstruktur und an die Organisationskultur adaptieren.
Wer neu in eine Organisation kommt, wird versuchen sich anhand der Kernelemente der Methode zurechtzufinden. Schnell wird ersichtlich, dass die organisationspezifischen Anpassungen auf Kompromissen beruhen und der eigentliche Nutzen der Methode verloren ging. Das Resultat ist dann ein Patchwork an Lösungen, die im Opportunitätsprinzip Problembereiche zu verbessern suchen. Im Alltag kämpfen dann ganze Organisationseinheiten mit einer Vorgehensmethodik, die ihre ursprünglichen Ziele verfehlt und Abläufe unnötig kompliziert macht.

Externe Berater beobachten, dass in vielen Organisationen eine solide methodische Basisausbildung gepaart mit einer breiten Praxiserfahrung fehlt. Dies würde helfen, um die richtige Methodik für ein bestimmtes Problem auszuwählen und diese dann zielgerichtet einzusetzen.
Nicht wenige Firmen wählen den einfachen Weg. Sie nominieren einzelne Personen, um eine Vorgehensmethodik im gesamten Organisationsbereich auszurollen. Da das Basiswissen in der Organisation fehlt, wird die Methodik nicht zielführend eingesetzt und dadurch als bürokratischer Ballast wahrgenommen.
Mitarbeitende machen jeden Tag methodische Kompromisse, weil das Ziel der Methode nicht klar ist. So lebt beispielsweise SCRUM als Methode, sehr stark von lokalen Teams, die physisch täglich 15 Minuten vor ihrem Kanban Board stehen (Daily-Scrum) und sich austauschen. Ein elektronisches Ticketsystem im klassischen Sinne kann den gleichen Zweck erfüllen, lässt aber oft die direkte Kommunikation innerhalb des Teams vermissen. Eines der Ziele der SCRUM-Methode ist es also, die direkte Kommunikation innerhalb des Teams zu stärken und zu lernen, sich kurz und auf das Wesentliche fokussiert auszudrücken. Wer solche Dinge nicht versteht, arbeitet an der Methode vorbei.
Eine solide Basisausbildung der gesamten Organisation gewährleistet, dass alle direkt Beteiligten und indirekt betroffenen Personen die eingesetzte Methodik verstehen. Dadurch wird verhindert, dass Kompromisse für den kurzfristigen Erfolg einer nachhaltigen Lösung vorgezogen werden. Am IBAW kann mithilfe von Ausbildungen wie dem Agile Coach NDK HF oder den Zertifikaten Scrum Master oder Scrum Product Owner diese Basis erarbeitet werden.

Folgendes Beispiel zeigt auf, was klassisches Projektmanagement bedeutet: Ein Zulieferer der Pharmaindustrie musste aufgrund von Auflagen der Zulassungsbehörden (US – FDA) sein ERP (Enterprise Resource Planning) System ersetzen. Anstatt ein etabliertes Vorgehensmodell (z.B. nach Wasserfall) zu wählen, verliess man sich auf das vorhandene Know-how von internen Mitarbeitern. Die Annahme war, dass sich diese mit den Auflagen der Pharmaindustrie und deren Zertifizierungsauflagen gut auskennen. Man verzichtete deshalb auf schriftlich formulierte Anforderungen (Requirements). Die ausgewählte Software und der Service Partner stammte aus dem persönlichen Umfeld der Mitarbeiter. Man entschied sich für eine hybride Lösung. Ein Modul als in der Cloud betriebene Lösung, ein anderes Modul aus der on-premise Infrastruktur.
Bei den Tests der Lösung fiel auf, dass die beiden Module nicht zueinander kompatibel waren. Eines der Module erfüllte auch die Auflagen und Anforderungen der Zulassungsbehörden nicht. Zusätzlich entzog der Software Hersteller dem Service Partner während dem laufenden Projekt die Zusammenarbeit. Kurz vor dem Go-live stand die Firma ohne funktionierende Software und ohne entsprechenden Service Partner da.
Das bessere Vorgehen wäre eine etablierte Vorgehensmethodik (z.B. nach Wasserfall) gewesen. Diese erfordert, dass Requirements in der Analysephase definiert werden. Auch wäre eine systematische Evaluation der Softwarelösung und des Service-Partners ohne Probleme in das Vorgehensmodell integrierbar gewesen. Selbst das nicht ausreichend praktizierte Risikomanagement war schon seit den Anfängen Bestandteil jeder gut etablierten Vorgehensmethodik.

Folgendes Beispiel zeigt auf, wo agiles Projektmanagement ins Spiel kommt und eingesetzt werden kann: Eine Handelsfirma möchte Bestellungen seiner Handelsprodukte neu via Webshop entgegennehmen, um den administrativen Aufwand für die Bestellbearbeitung zu mindern. Als erfahrener ICT-Anbieter verfügt das Unternehmen über kompetente Software Entwickler, welche einen Webshop programmieren können und wollen.
Als modernes ICT-Unternehmen fällt die Wahl auf die Agile Methode SCRUM als Projektmanagement Methode. In den ersten drei Sprints wird der Webshop entwickelt und bei der Abnahme des dritten Sprints erkennt der Product Owner, dass aufgrund der fehlenden Anbindung zu den Artikelstammdaten der Webshop noch nicht genutzt werden kann.
Im 4. Sprint wird deshalb eine Artikel Stammdatenbank programmiert. Aufgrund der fehlenden Schittstelle zur Finanzbuchhaltung wird im Sprint 5 – 15 eine einfache Finanzbuchhaltung erstellt und der Webshop steht nach 9 Monaten immer noch nicht bereit.
Was ist schiefgelaufen? In kurzfristigen Sprints ist das Entwicklerteam abgedriftet und hat statt einem einfachen Webshop mehrheitlich an einer Finanzbuchhaltung gearbeitet.
Wie kann eine solche Situation in der Praxis verhindert werden? Mit der Konzentration auf das Big-Picture verhindert ein erfahrener Projektleiter/Product Owner das Abdriften des Projektteams, ohne dessen Selbstorganisation zu untergraben.
Auch in agilen Projekten braucht es eine Vorstellung davon, was entwickelt werden soll – das Big-Picture. Dies ermöglicht eine Abgrenzung, das heisst eine Feststellung was out-of-scope ist. Die kritischen Rahmenbedingungen werden dadurch von Anfang an in der Formulierung der User Stories berücksichtigt.

In der Praxis ist es deshalb laut Quantis aus folgenden drei Gründen empfehlenswert, für ein erfolgreiches Projektmanagement erfahrene und nicht betriebsblinde Projektleitende mit einer soliden Projektmanagement Ausbildung zu beschaffen:

• Mit ihrem fachlichen Know-how können Projekte mit einer an die unternehmensspezifischen Bedürfnisse adaptierten Methode umgesetzt werden.
• Erfahrene Projektleitende wissen, wo Kompromisse geschlossen werden dürfen, ohne einen zu grossen Preis in der Zukunft zahlen zu müssen.
• Ein erfahrener Projektleitender erkennt die wichtigsten Risiken, Abgrenzungen und Handlungsfelder zur Integration der Resultate in die IT-Architektur und die organisatorischen Gegebenheiten.

Quantis verfügt über langjährige branchenübergreifende Erfahrung im IT- und Business Projekt Portfolio Management, Programm Management, in der Projektleitung und im Aufbau von Projekt Management Offices (PMO). Besonders in der Finanz-, Versicherungs- und Pharmabranche sowie in der Industrie und im öffentlichen Sektor ist die Quantis bestens etabliert.

Eine gute und solide Basisausbildung ist für die gesamte Organisation relevant. So kann Betriebsblindheit auf ein Minimum reduziert und unternehmensübergreifende Erfahrung breit genutzt werden. Dies ist eine gute Basis für kreativere, innovativere Lösungen. Informierte und motivierte Mitarbeitende, sowie Führungskräfte arbeiten fokussiert und umsetzungsstark – und jeder einzelne bringt dem Unternehmen den gewünschten Nutzen.