Die Grundlage für den Erfolg oder den Misserfolg von Projekten wird schon sehr früh, ganz am Anfang gelegt. Deshalb wollen wir uns in diesem Kapitel die Ingredienzen ansehen, die dazu notwendig sind, ein Projekt erfolgreich zu beginnen. Drei Punkte sind es, auf die wir am Anfang achten sollten: die Festlegung der Projektziele, die Festlegung der Mitspieler (im Englischen „Stakeholder“ genannt) und die Festlegung des Umfangs des Projekts (im Englischen als „Scope“ bezeichnet). Wie Bild 2.1 verdeutlicht, haben diese drei Punkte Wechselwirkungen untereinander. Es ist klar: Andere Mitspieler haben unter Umständen andere Ziele. Umgekehrt, wenn Ziele vorgegeben werden, kann man die beteiligten Personen so auswählen, dass diese Ziele gut erreichbar sind.

Die Ziele geben aber auch den Umfang des Projekts vor und der Umfang bestimmt wiederum, was innerhalb des Zielbereichs liegt und was nicht. Und natürlich haben auch die Stakeholder und der Scope ihre Wechselwirkungen. Wir werden in den folgenden Abschnitten alle drei Ingredienzen ausführlich behandeln.

Beginnen wir mit den Zielen. Natürlich sollte jedes Projekt Projektziele haben. Aber ist das wirklich Ihre Aufgabe als Systemanalytiker? Sind Sie dafür verantwortlich, dass es Projektziele gibt? Das ist doch der Job eines Projektleiters. Oder vielleicht noch besser, der Job eines Auftraggebers, denn als Projektleiter würde ich meine Auftraggeber fragen, was sie eigentlich anstreben. Warum sollten Sie sich als Systemanalytiker also um Ziele kümmern? Nun ja. Ziele sind die höchste und abstrakteste Form von Anforderungen. Alle weiteren (detaillierteren) Anforderungen, die Sie erheben, sollten sich aus diesen Zielen ableiten. Deshalb sollten Ziele Ihre Ausgangsbasis sein. Und wenn der Projektleiter oder der Auftraggeber sie noch nicht formuliert haben, dann müssen Sie ran und diese Ziele formulieren.

Ich habe vor ein paar Jahren einmal im Oktober ein Team kennengelernt, das mit fünfzehn Personen an einem großen Thema arbeitete. Wir haben dann für Anfang Januar vereinbart, einen Einführungskurs zu machen und auch ein bisschen Projektberatung. Nach den beiden Tagen des Einführungskurses, mit ähnlichen Inhalten wie in diesem Buch, habe ich am Mittwochmorgen die Fragen gestellt: Wo sind Eure Projektziele? Ihr arbeitet schließlich schon mit fünfzehn Leuten seit drei Monaten zusammen. Kann mir jemand die Ziele nennen? Alle sahen sich ratlos um. Insbesondere der deutsche Softwareprojektleiter und der italienische Hardwareprojektleiter sahen sich tief in ihre blauen Augen und sagten: „Wir haben keine expliziten Projektziele.“ Daraufhin habe ich die beiden Projektleiter in ein Kämmerchen verbannt, mit der Aufgabenstellung, diese Ziele doch schriftlich festzulegen, und habe mit dem Rest des Teams am Vormittag weitergearbeitet. Kurz vor dem Mittagessen wollten die beiden wieder heraus aus ihrem Kämmerchen. Und sie kamen ganz stolz mit einer PowerPoint-Folie, mit zwei dicken Bullet-Punkten, großer Schrift und haben die beiden Ziele dem Team vorgestellt. Das Erstaunliche war nicht, dass die beiden Projektleiter es in zwei Stunden geschafft hatten, sich auf diese beiden Sätze zu einigen, sondern das Erstaunliche waren die Gesichter der anderen dreizehn Projektmitglieder, die die Sätze gelesen haben und sagten: „Ach, das sind unsere Hauptziele in dem Projekt!“ Natürlich hatte jeder im Team seine Meinung zu dem Thema, aber die Meinungen waren sehr unterschiedlich.

Sie sehen also, Ziele sind unbedingt notwendig, um ein Projekt in die gleiche Richtung zu treiben, sonst arbeitet jeder nach seinen eigenen Zielen. Wie würden wir also Ziele formulieren? Wir versuchen es zweiteilig, wie in Bild 2.2 vorgeschlagen: Teil 1 ist die Ausgangssituation, die uns veranlasst, etwas zu tun. Und Teil 2 sind die eigentlichen Ziele.

Skizzieren Sie zuerst Ihre Ausgangssituation. Es gibt sinnvollerweise nur zwei Möglichkeiten, warum Sie ein neues Projekt aufsetzen: Entweder drückt Sie irgendwo der Schuh oder Sie haben eine grandiose Idee, wie man das Geschäft verbessern kann. Fassen Sie das in Worte. Und danach versuchen Sie, die Ziele oder Visionen daraus abzuleiten. In großen Projekten ist es für den zweiten Teil sinnvoll, zwischen den Zeithorizonten für die Ziele noch weiter zu unterscheiden, wie es in Bild 2.3 dargestellt ist.

Nach der Ausgangssituation kommen die Langfristziele, die Ziele für die nächsten zwei bis fünf Jahre vielleicht, und darunter die Ziele für das jeweils nächste Release. Egal, wie weit es noch weg ist; drei Monate oder sechs Monate. Formulieren Sie als Release-Ziele die Zwischenziele, die Sie in drei bis sechs Monaten erreichen wollen. Oder, wenn Sie nach SCRUM arbeiten, die Sprintziele für die nächsten 30 Tage.

Ziele sind auch Anforderungen. Oder noch härter ausgedrückt: Ziele sind (eine Art von) Anforderungen. Das wird sehr oft missverstanden. Sehr oft finden Sie in der Literatur Aussagen wie: Ziele sind intentionale Aussagen über das Projekt. Was sind intentionale Aussagen anderes als etwas Gewünschtes, also eine Anforderung?

Wir haben in der Einleitung besprochen, dass Anforderungen sich mit 1 – 3 % pro Monat ändern. Wir schärfen daher unsere Definition von Zielen noch, wie in Bild 2.4 dargestellt.

Ziele sollten (für den gewählten Zeitraum des Gesamtprojekts, des Release, eines Scrum-Sprints) stabile Anforderungen sein. Denn die detaillierten Anforderungen werden sich mit hoher Wahrscheinlichkeit mit 1 – 3 % pro Monat ändern.

Wie können wir diese Ziele spezifizieren? Einige von Ihnen haben bestimmt Projektmanagementkurse gemacht und eine entsprechende Abkürzung gelernt. Die populärste Abkürzung ist SMART. Ziele sollten smart sein. S wie spezifisch, wir wollen definitiv spezifische Projektziele. M wie messbar, das gehört ebenfalls dazu: Jede Anforderung sollte messbar sein. Ziele sind auch Anforderungen. Also brauchen wir Messbarkeit auch für Ziele; A wie angemessen oder adäquat, R wie realistisch und T wie terminiert. Normalerweise wird Ihnen ein Zeitrahmen vorgegeben, in dem Sie diese Ziele erreichen sollten.

Die Abkürzung ist zwar sehr bekannt, aber wir arbeiten bei der Atlantic Systems Guild mit einem etwas kürzeren Akronym: PAM (vgl. Bild 2.5).

Zumindest die Baywatch-Fans können sich diese Abkürzung gut merken. Aber PAM steht nicht für Pamela Anderson, sondern für Purpose, Advantage, Measure. Purpose: Schreiben Sie einfach einen Satz, was das System tun soll. Das System soll das und das erreichen.

Überlegen Sie unter dem Buchstaben A: Wer hat etwas davon? Das Ziel sollte irgendjemandem Vorteile ermöglichen. Was ist der Vorteil und wer sind diejenigen, die den Vorteil haben? Vorteile könnten z. B. sein:

       Kostenreduktion/Geschäft vereinfachen

       Gewinne erhöhen

       Service verbessern

       Gesetze erfüllen

Wenn Sie niemanden finden, ist vielleicht das Ziel falsch gewählt.

Und wie bei SMART: Das M in PAM steht auch für Measure. Sie brauchen eine Metrik, woran Sie nach Ende des Projekts oder des Release feststellen können, ob Sie das Ziel erreicht haben oder nicht.

Verwenden Sie für jedes einzelne Ziel die Abkürzung PAM: Purpose – Advantage – Measure. Jetzt hat ein Projekt aber nicht beliebig viele Ziele. Wir versuchen im Normalfall, die Anzahl irgendwo zwischen ein, zwei, drei – bis maximal fünf zu begrenzen. Ein Projekt hat keine 97 Ziele. Sie können 97 Anforderungen haben. Sie können vielleicht 300 Anforderungen haben. Vielleicht auch 5 000. Aber wir haben garantiert nicht so viele Ziele. Beschränken Sie die Anzahl der Ziele auf maximal eine...