Projektstrukturplan: Symptome von Ursachen klar trennen

Arbeitet man an Strukturen eines Projekts (seien es Projektstrukturpläne, Schnittstellen oder sonstige Strukturkonzepte) ist es wichtig Symptome und Ursachen immer klar von einander zu trennen. Verwechselt man sie, führt es unweigerlich zu zahlreichen Problemen u.a. wie irreführenden funktionalen Strukturen in entstehenden Systemen,  damit einhergehender geringer Verwirrung seitens der Benutzer, sowie zu viel höheren Aufwänden bei Erweiterung und Pflege des IT-Systems in der Zukunft.

Betrachten wir dafür die folgenden fiktiven Beispiele als Case Studies:

(a) Beispiel 1: Navigationleiste in einem Online-System

Ausgangspunkt: In einem Projekt einer Bank wird die Verschlankung des bestehenden Vertriebsprozesses zum Ziel gesetzt. Damit erhofft man sich höhere Umsätze im Vertrieb. Aufgrund dessen muss die Funktionalität eines bestehenden Webbasierten IT-Systems grundlegend geändert werden (ein typisches IT-Projekt eben). Da schon früh klar ist, dass sich der Aufbau der Navigationsleiste in der Software ändert, wird als erstes und wesentliches Arbeitspaket genau dieses festgelegt und einem Anforderungsmanager zugewiesen.

Dieser arbeitet gern schnell und effizient. Er erstellt zügig ein Konzept für eine vermeintlich neue Struktur der Navigationsleiste und widmet sich dann anderen Arbeitspaketen zu. Als er eine Woche später den Projektleiter dazu interviewt ist er überrascht zu hören, dass sein Konzept nicht mehr stimmig ist und angepasst werden muss. Seit der letzten Woche hat sich nämlich vieles geändert. In der Zwischenzeit hat der Lenkungsausschuss einen entscheidenden Teil der Funktionalität im Projektauftrag depriorisiert. Bestimmte Funktionalität soll dabei gänzlich entfallen. Das Konzept der Navigationsleiste ändert sich und muss somit angepasst werden. Der Anforderungsmanager ist verdutzt, wendet sich aber der Aufgabe erneut zu. Diese Anpassung bleibt nicht die einzige. Im Projektverlauf muss er aufs Neue sein Konzept verändern, da sich die Struktur der Applikation oder ihr Funktionsumfang  immer wieder mit dem Wind dreht. Am Ende des Projekts ist der Anforderungsmanager recht demotiviert und über die Ineffizienz des Vorgehens enttäuscht. Das entspricht ganz und gar nicht seinem effizientem Arbeitsstil.

(b) Beispiel 2:  Fehlende Struktur auf der Startseite einer iPad App

Ausgangspunkt: Ein Versicherungsunternehmen möchte seinen Vertrieb moderner ausstatten. Es beschließt eine iPad App als ein neues System für den Vertrieb zu konzipieren, welches zukünftig externe und interne Vertriebsmitarbeiter unterstützen soll. Noch bevor die Funktionalität der App ganzheitlich bestimmt ist (denn das ist auch der Auftrag des Projekts), legt man erste Arbeitspakete fest.
Form und Inhalt: Da das Unternehmen sehr hohen Wert auf Design legt, ist eins der wichtigsten Arbeitspakete das „Design der Startseite“. Ein gelungenes Design der Startseite wird als extrem wichtig für den Erfolg des neuen Systems (also der iPad App) angesehen. Es soll interaktiv und ansprechend sein und dabei den Kunden emotional einbinden. Da gleichzeitig ein sechsköpfiges Designerteam bereits darauf wartet anzufangen, beraumt man sofort ein Kreativworkshop an, um das Interaktionsdesign der Startseite per Brainstorming festzulegen. Das Ergebnis kann sich sehen lassen. Das Design-Team bringt bereits nach drei Tagen ein sehr kreatives Konzept der Startseite hervor. Im folgenden Verlauf des Projekts werden viele Entscheidungen bezüglich der Funktionalität getroffen. Da das Interaktionsdesign bereits feststeht, wird es den interaktiven Elementen und Kategorien der Startseite zugeordnet. Das neue System ist wirklich vielversprechend. Es hat ein tolles Design und sehr umfangreiche Funktionalität.

Die Folgen:  Trotz des vielversprechenden Designs erreicht die App nicht die gesetzten Erwartungen. Der Vertrieb meldet nach einem Jahr nur durchschnittliche Nutzungszahlen, insbesondere bei Berufseinsteigern. Die geringe Klarheit im Aufbau der App und die damit einhergehenden langen Einarbeitungszeiten stoßen den Neulingen negativ auf. Das Feedback der Anwender lautete immer gleich: die App ist schön, aber nur schwer verständlich, die Struktur ist einem kaum auf Anhieb zu vermitteln. Man braucht lange, um zu lernen, wie man bestimmte Programmteile und Module nutzt.

In beiden Fällen zeigen sich die Folgen der Verwechslung von Ursachen und Wirkungen sehr deutlich. Die Anpassung einer Navigationleiste kann nur dann erfolgen, wenn der Funktionsumfang und der Funktionsschnitt eines Systems festgelegt ist. Denn sie spiegelt immer die inhaltliche Struktur der Funktionen (oder Module / Use Cases) eines Systems wieder. Das gleiche gilt für die Startseite einer iPad App. Bei komplexen Anwendungen wie bei einem Vertriebssystem (auch wenn das nur eine iPad Applikation ist) besitzt die Startseite Navigationscharakter und muss somit den strukturellen Vorgaben der Fachlichkeit folgen, nicht dem kreativen Wunsch von Medienexperten. Folglich kann die Startseite erst dann entworfen werden, wenn der Funktionsumfang eine (zumindest annährend) definierte Struktur besitzt. Welche Stuktur sinnvoll ist, entscheidet am Besten Ihr Software-Ingenieur!

 

Anton

Anton

Anton ist freiberuflicher Software-Ingenieur und Projektleiter mit den Schwerpunkten: Prozessdesign, strukturierte Business Analyse / Fachkonzeption sowie fachliche Entscheidungsunterstützung.

More Posts - Website