“Sie kümmern sich jetzt um Projekt X”. Mit diesen Worten beginnen viele Leidensgeschichten. Die erste Diagnosefrage, die sich die/der Projektleiter(in) (PL) in spe stellen sollte lautet: “Ist X wirklich ein Projekt?” bzw. konkreter erfüllt “X” die folgenden Kriterien: Es gibt mindestens

• ein in Worten beschreibbares Ziel oder Arbeitsergebnis,
  das in dieser Form noch nicht existiert,
• eine klare Begründung warum das Projekt gemacht wird,
• einen Termin an dem mit den Arbeiten begonnen wird,
• einen Termin an dem das Arbeitsergebnis vorliegen soll,
• mindestens eine weitere Personen, die zum Arbeitsergebnis beiträgt,
• sowie mindestens eine weitere Person, an die das Arbeitsergebnis geliefert wird.

Wenn sich diese Punkte nicht klar beantworten lassen hat der / die Projektleiter In (PL) schon halb verloren. Dann bahnt sich vielleicht kein Projekt sondern eine Aufgaben-Zeit-Verschiebungsaktion oder eine halbherzige Umorganisation an. Lassen sich die grundlegenden Rollen (z.B. Empfänger des Ergebnisses) wirklich identifizieren und konkrete Ergebnisse formulieren? Bei neuen Aufgabenbereichen, die auf bestehende drauf gepackt werden, ist das oft nicht möglich auch wenn sie gerne Projekte genannt werden, das ist aber ein anderes Thema.

Gehen wir besser davon aus, dass das Ergebnis formuliert und verstanden ist. Dann steht die nächste Frage im Raum: “Wer macht mit?” Zur Erinnerung: Ein-Personen-Veranstaltungen sollten nicht Projekte genannt und mit Management überfrachtet werden. Im positiven Falle sind Mitarbeiter benannt, denen verfügbare Arbeitszeit eingeräumt wird im Projekt zu arbeiten und die zumindest in Ansätzen die notwendigen Qualifikationen mitbringen. Als ersten Schritt gilt es die Mitarbeiter(Innen) zu versammeln und sie über das Projekt ins Bild zu setzen. Als zweiten Schritt sollten sich alle Beteiligten zu einer Auftaktveranstaltung versammeln. In gutem Neudeutsch wird dies oft “Kickoff” genannt. Dieser Begriff aus dem “American Football” trifft es allerdings nicht ganz, er führt sogar ein wenig in die Irre. Bei der Auftaktveranstaltung müssen alle Beteiligten dabei sein. Dazu gehören Leitung, Auftraggeber, Team usw. Die entsprechende sportliche Metapher wäre das Treffen vor dem Spiel, bei dem der Vereinspräsident (Fußball Bundesliga) oder der Clubbesitzer (Basketball NBA) noch mal kurz vorbeischauen. Wenn der Ball zum ersten Mal gespielt wird ist das Team auf sich gestellt, der Auftraggeber sitzt dann schon auf der Tribüne. Ob der Projektleiter wie ein Trainer am Spielfeldrand oder als Spielertrainer bzw. Mannschaftskapitän agiert hängt dabei eher von Projektgröße und persönlichem Leitungsverständnis ab. Leider wird in vielen Projekten schon auf einen solchen Auftakt verzichtet. Für den/die PL der Auftakt eine erste Nagelprobe. Wenn jetzt schon Vorbehalte bzgl. der Verfügbarkeit von Mitarbeitern kommen, wie soll es dann werden wenn im Projekt wirklich gearbeitet werden soll.

Gehen wir weiter davon aus, dass der Auftakt stattgefunden hat. Damit sollten die folgenden Checklistenpunkte guten Gewissens mit “Ja” beantwortet werden können – falls nein “Gehe zurück zum Start”:

• Ist klar, warum was an wen geliefert werden soll und ist es allen bekannt?
• Sind die Projektziele (Anforderungen) zweifelsfrei definiert, klar und allen bekannt?
• Sind Termine definiert und allen bekannt?

Das Projekt beginnt und alles geht seinen Gang. Die Anforderungen werden in Arbeitspaketen in Aufgaben umgesetzt (wie auch immer) und abgearbeitet. Jetzt gibt es nur noch das eine oder andere Risiko das im Weg steht. Hier hilft eine einfache Liste, die wöchentlich bearbeitet und ggf. aktualisiert wird. Risiken haben noch mehr als Projektziele die Eigenschaft sich laufend zu verändern. Für die Aktualisierung der Liste helfen die folgenden Punkte:

• Sind die (aktuell am) größten Risiken bekannt?
• Hat jeder im Team das aus seiner Sicht größte Risiko benannt?
• Welche Risiken sind in der letzten Woche hinzugekommen?
• Welche Risiken wurden bisher entschärft?

Wenn alle diese Punkte mit gutem Gewissen beantwortet und abgehakt werden können ist das Projekt auf einem guten Weg. Aufgabe des / der PL ist es dafür zu sorgen, dass alle (!) Häkchen erhalten bleiben auch wenn sich im Laufe des Projektes die Rahmenbedingungen, Anforderungen oder was auch immer ändern. Wenn ein Projekt in Schieflage gerät ist meistens eines der Häkchen klammheimlich verschwunden. Der kritische Blick welches der Häkchen genau verschwunden ist hilft bei der Einleitung wirkungsvoller Maßnahmen.

Nochmal zurück zum Sport. Von der Tribüne lässt sich das Spiel gut verfolgen. Im Projektgeschäft läuft das ein wenig anders, hier ist der/die PL gefragt. Der Blick von der Tribüne wird durch das Berichtswesen im Projekt ersetzt. Ein pragmatisches Berichtswesen habe ich hier schon beschrieben – Das Schweizer Taschenmesser des Projektberichtwesens – (zugegeben das sind nochmal ein paar Worte zusätzlich). Die Projektberichte müssen immer auch die Risiken enthalten. Wenn Risiken verschwiegen werden (egal in welche Richtung) ist die destruktive Saat des schon Misstrauens gelegt.

Das ist eigentlich schon alles. Damit gelingt sicher nicht jedes Projekt automatisch und es gibt noch manche Details zu beachten wenn diese Punkte nicht erfüllt sind kann man sich alles andere sparen. Und “Hand auf Herz” in manchen Projekten, in denen gigantischer Management-Aufwand verbraten wird, lassen sich diese einfachen Punkte nicht einmal beantworten. Kann z.B. irgendjemand im Milliarden Projekt “Gesundheitskarte”, mit wenigen Worten das Ziel beschreiben. Das ist letztendlich genauso fatal wie das Miniprojekt einer kleinen Firma “Ich will eine neue Software, weiß aber nicht wozu”.

EPILOG: Ich habe bis jetzt kein Wort über konkrete PM Vorgehensweisen, Frameworks, Methoden, Vorgehensmodelle oder sonst etwas geschrieben. Es ist auch unerheblich ob es in dem gewählten Ansatz den Begriff des PL überhaupt gibt. Das hat einen guten Grund: “Es ist aus meiner Sicht weitgehend egal”. Nahezu jeder Ansatz, der verantwortungsbewusst eingesetzt wird, liefert positive Antworten auf obige Fragen. Es ist egal ob ein Scrum-Master die im “daily scrum” aufgetauchten “impediments” beseitigt oder ein klassisches Risikomanagement im Rahmen eines PMP gemacht wird. Das Ergebnis ist dasselbe. Ein Scrum-Master, der die “impediments” nicht beseitigt ist gleich schädlich wie ein Placebo-Risikomanagement, das die Rückmeldungen der Mitarbeiter nicht aufnimmt. Was letztendlich zählt und zum Erfolg führt ist das Vertrauen in die Menschen. Alle Methoden sind nur Hilfsmittel, die den Menschen helfen sollen.

Dieser Text ist unter Creative Commons BY NC ND (Namensnennung – Nicht Kommerziell – Keine Bearbeitung) lizenziert. Er ist Teil des Buchprojekts “Menschen im Projekt”. Er gehört zum Abschnitt 3, siehe Mindmap zu Inhalt und Struktur.

Die gefühlte Antwort auf die obige Frage lautet: “Ein großer Teil der Anforderungen ist zu Beginn des Projekts noch nicht bekannt”. Der erste Blick auf die Daten scheint dies zu bestätigen. Nur bei 10% der Projekte sind alle Anforderungen zu Beginn des Projektes bekannt. Bei 26% sind es immer noch ca. 80%. Bei 29% zwischen 50 und 80% der Anforderungen. Bei einem immer noch nennenswerten Teil von 25 % ist weniger als die Hälfte der Anforderungen zu Beginn bekannt. Diese Prozentzahlen scheinen zudem relativ unabhängig von der Art des Projektes zu sein – zumindest die IT-Projekte und die nicht-IT-Projekte zeigen die gleichen Werte. Eine genauere Differenzierung wird allerdings erst bei einer größeren Zahlenbasis möglich sein.

Diese Zahlen zeigen auf wie notwendig ein funktionierendes Anforderungs- und Changemanagement oder eine agile Vorgehensweise ist. Eine Schlussfolgerung lässt sich schon jetzt ziehen. Die einmalige Erstellung eines endgültigen Planes, der nicht mehr geändert werden muss, ist eine Illusion.

Ein berühmter Test stammt von Joel Spolsky. Er hat zwölf Punkte formuliert, die den Weg zu besserem Code weisen. The Joel Test: 12 Steps to Better Code.

1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. …

Ich möchte den Joel Test hier nicht in ganzer Länge zitieren. Er stellt jedoch eine wichtige Grundlage für meinen eigenen 15 Punkte Test dar. Dieser ist an einigen Stellen allgemeiner an anderen Stellen etwas detaillierter formuliert. Es sind jeweils 5 Fragen zu den Bereichen Spezifikation, Vorgehensweise und Rahmenbedingungen bzw. Management. 15 Fragen, für jede 20 Sekunden Zeit um sie mit “Ja” oder “Nein” zu beantworten:

• Haben Sie eine fachliche Spezifikation?
• Haben Sie eine technische Spezifikation?
• Haben Sie dokumentierte Testfälle?
• Haben Sie Tester?
• Haben Sie Tester außerhalb des Entwicklungs- oder Projektteams?

• Verwenden Sie eine Versionsverwaltung?
• Ist Ihr Build-Prozess automatisiert?
• Machen Sie einen täglichen Build?
• Verwenden Sie ein Bugtracking-System?
• Beheben Sie Fehler bevor Sie neuen Code schreiben?

• Kann sich das Entwicklungsteam den Arbeitsplatz selbst gestalten?
• Können die EntwicklerInnen ungestört arbeiten?
• Stehen die besten (Wunsch)-Werkzeuge zur Verfügung?
• Gibt es einen aktuellen und validen Zeitplan?
• Werden Zeit-Schätzungen grundsätzlich von mehr als einer Person gemacht?

15 mal JA: Es gibt kaum noch etwas zu verbessern. Es bleibt höchstens die Frage ob die Fragen wahrheitsgemäß und nicht nur dem Wortlaut nach beantwortet wurden. Es wäre dann z.B. nachzufragen ob die vorhandenen Tester wirklich testen oder nur auf dem Papier vorhanden sind.

weniger als 3 mal JA: Dann haben Sie möglicherweise ein Problem und viel Verbesserungspotential.

Ziel des Tests ist es nicht auf Gedeih und Verderb die volle Punktzahl zu erreichen. Er soll in kürzest möglicher Zeit einen kritischen Blick auf ein konkretes Software-Entwicklungs-Projekt werfen. Die Fragen decken hierbei wichtige Grundsätze der Softwareentwicklung und des Projektmanagements ab, die in der Mindmap nochmals im Zusammenhang dargestellt sind:

Die Mindmap gibt es auch als PDF zum Download: 15 Punkte für gute Software – (Projekte). Und hier die Fragen als ausfüllbare Checkliste: Checkliste 15 Punkte für gute Software.

In der EN ISO 9000:2005 findet sich folgende Definition:

Ein Projekt ist ein einmaliger Prozess, der aus einem Satz von abgestimmten und gelenkten Tätigkeiten mit Anfangs- und Endtermin besteht und durchgeführt wird, um unter Berücksichtigung von Zwängen bezüglich Zeit, Kosten und Ressourcen ein Ziel zu erreichen, das spezifische Anforderungen erfüllt.

Diese Definition ist weitreichend und beinhaltet auch schon einen Hinweis auf das Projektmanagement. Sie ist allerdings meines Erachtens in Bezug auf das “Ziel” noch nicht präzise genug. Um den Begriff des Zieles besser zu fassen, lohnt es einen Blick auf die Entstehung eines Projektes zu werfen. Am Anfang steht die Idee etwas Neues zu erschaffen. Das “Neue” kann ein neues Produkt, eine Software, eine Organisationsform oder etwas anderes sein. Wichtig ist dass sich das Ziel (in messbarer Form) beschreiben lässt. Die Beschreibung des Ziels stellt gewissermaßen die Dokumentation der oben genannten spezifischen Anforderungen dar. Ein Aspekt, der in obiger Definition nicht bzw. nur implizit enthalten ist der folgende: Das Ziel eines Projektes ist schwierig zu erreichen und übersteigt die Kapazität und die Fähigkeiten eines einzelnen. Zum Projektstart ist es eine arbeitende Gruppe, im Laufe des Projektes sollte aus der Gruppe möglichst schnell ein Team werden.Die Arbeit in einem echten Projekt muss also von einer Gruppe von Menschen geleistet werden. Die Gruppe von Menschen, die im Projekt arbeitet benötigt zudem ein organisatorisches Arbeitsumfeld, das sich von dem unterscheidet in dem die Mitarbeiter außerhalb des Projekts arbeiten. Dies ist von großer Bedeutung, da in vielen Projekten die Mitarbeiter aus unterschiedlichen Abteilungen oder Organisationen stammen. Ich möchte daher die Definition um die Aspekte “komplexes Ziel”, “Projektteam” und “temporäre Organisation” ergänzen und in Form einer Mindmap darstellen.

Und wozu die ganze Wortklauberei ?

Nicht überall wo Projekt drauf steht ist auch Projekt drin. Viele Aktivitäten oder Vorhaben werden leichtfertig als Projekt bezeichnet. Oft wird für ein Projekt ein spezielles Vorgehensmodell eingesetzt oder bestimmte Regularien müssen eingehalten werden, die eine einfachere Nicht-Projekt-Aufgabe gehörig erschweren können. Eine saubere Definition und Prüfung, ob für ein Vorhaben wirklich ein Projekt benötigt wird, ermöglicht eine bewusste Entscheidung für Projekmanagement oder für eine andere passendere Managementform. Am Beispiel des Statusberichtes, der in irgendeiner Form Bestandteil jedes Projektverfahrens, ist wird die Bedeutung dieser Entscheidung deutlich. So ist z.B. eine Aufgabe, die von einem Mitarbeiter alleine bewältigt werden kann, kein Projekt. Es macht keinen Sinn die Arbeitszeit noch mit Schreiben von Projekt-Statusberichten zu vergeuden. Sein Arbeitsfortschritt muss sich problemlos von seinem normalen Vorgesetzten verfolgen lassen. Falls dies nicht funktioniert besteht eher ein Führungsproblem, das sich auch mit Projektmamnagement nicht lösen lässt. Für Vorhaben, die mehrere Mitarbeiter mit ähnlichen und wenig komplexen Aufgaben beschäftigen, gilt entsprechendes. Erst wenn die Aufgabe groß und komplex wird und mehrere Mitarbeiter mit unterschiedlichen Aufgaben betraut werden müssen, lässt sich der Arbeitsfortschritt nicht mehr im Rahmen der normalen Organisation und durch die direkten Vorgesetzten überwachen. Jetzt ist es an der Zeit ein Projekt zu definieren, die notwendige Projektorganisation aufzubauen und mit dem Projektmanagement zu beginnen.

Merke: Projektmanagement lohnt sich erst ab einer bestimmten Größe und Komplexität der Aufgabe.

- Auf ungefragt geäußerte Information achten!
- Auf persönliche Steckenpferde achten!
- Gibt es mehrere Anforderer?
- Gibt es widersprüchliche Anforderungen?
- Das “Was” und das “Wie” nicht vermischen?
- Was braucht der Kunde wirklich?

Der Prozess genaue und klare Anforderungen zu ermitteln ist lange und mühselig. Manchmal ist es wie das Fischen in einer trüben Suppe. Manches ist schwierig zu erwischne, ss gibt aber auch „Brocken in der Suppe“, die immer wieder von alleine auftauchen. Anforderungen, die freiwillig und ohne Nachfragen genannt werden. Das erleichtert im ersten Moment die Arbeit, dennoch sollten solche Anforderungen besonders genau unter die Lupe genommen werden. Hinter diesen Anforderungen stecken meist starke Interessen des jeweiligen Anforderers. Diese Interessen müssen nicht zwingend im Sinne des Projektes sein. Deshalb gilt es diese Anforderungen kritisch zu prüfen. Im Sinne dieser Prüfung sollte man sich auch fragen ob sich dahinter eventuell persönliche Steckenpferde verstecken. Ich möchte „persönliche Steckenpferde“ nicht schlecht machen, oft ist es eine große Hilfe für die Anforderungsdefinition wenn Spezialwissen gepaart mit Begeisterung für ein Thema zusammen kommen. Die Aufnahme aller persönlichen Steckenpferde kann die Anforderungsliste aber auch überfrachten – womit wir wieder bei der Zielvermehrung angekommen wären. Bei der Bewertung der Anforderungen lohnt sich immer auch ein Blick darauf ob es eine einzelne Person oder mehrere Personen sind, die hinter einer formulierten Anforderung stehen. Nicht immer zählt die Masse aber es hilft bei der Steckenpferdanalyse.

Jetzt wird es spannend. Sehr gut beschriebene Anforderungen können wertlos werden, wenn sie nicht genau auf Widersprüche geprüft worden sind. Wenn Zeit und Budget im Übermaß vorhanden sind, lassen sich manche Widersprüche durch ein salomonisches „sowohl als auch“ lösen. In realen Projekten sind Zeit und Geld aber knapp. Entscheidungen, welche der widersprüchlichen Anforderungen umgesetzt wird, müssen so früh wie möglich gefällt werden um den Anforderer zum Ende des Projektes hin nicht unnötig zu verärgern. Fällt der Widerspruch erst am Ende auf, wenn eine der Anforderungen schon umgesetzt wurde und dann doch die Entscheidung für die andere fällt wurde für den Papierkorb gearbeitet. Das ist dann der „worst case“ im Projektgeschäft.

Die nächste Frage erscheint trivial und ist dennoch von großer Bedeutung. An einem Beispiel wird es deutlich. Die Anforderung lautet: „6 Personen aus Stuttgart müssen morgen um 10:00 Uhr in Mannheim pünktlich zu einem Termin erscheinen“. Das ist das „Was“ – eine Formulierung der Anforderung. Das „Wie“ ist die Frage nach dem Transportmittel, als da wären: Auto, ICE, Flugzeug. Eine vermischte Formulierung wäre „6 Personen müssen mit dem Zug nach Mannheim fahren und pünktlich zu einem Termin erscheinen“. Selbst wenn die Lösung der Anforderung wirklich die Zugfahrt ist, muss die Anforderung selbst lösungswegneutral formuliert werden. Wird dieser Grundsatz vernachlässigt werden manche Entscheidungen vorweggenommen bzw. Entscheidungsspielraum im Projekt eingeschränkt. Dieser Effekt tritt oft in IT-Projekten auf, wenn Anforderungen mit Implementierungshalbwissen vermischt werden. Wer kennt nicht den Satz “Wir brauchen eine Datenbank?” … die Frage “Was soll die Datenbank tun?” bleibt oft lange unbeantwortet.

Die letzte Frage schließt den Kreis zur ersten Frage auf dem vorherigen Kärtchen, diese lautete „Wer ist der Auftraggeber“. Egal ob man diesen Auftraggeber, Stakeholder oder Kunde nennt. Man sollte immer versuchen sich in den Kunden hinein zu versetzen und versuchen zu verstehen was er wirklich braucht. Nicht immer ist das was formuliert wird auch wirklich das was benötigt wird. Echte Zufriedenheit beim Kunden/Auftraggeber wird sich nur einstellen, wenn er wirklich das bekommt was er braucht.

Was soll gemacht werden?
Warum soll es gemacht werden?
Wie soll es gemacht werden?
Wer soll es machen?
Wann soll es gemacht werden?

Was und Warum gehören zusammen. Beide Fragen müssen beantwortet werden. Vordergründig sind die Ziele eines Projektes die Antworten auf die Frage “Was soll gemacht werden?”. Das würde genügen, wenn die Antworten glasklar und unmissverständlich formuliert wären. Es ist jedoch in der Natur der Sache begründet, dass diese Klarheit nicht möglich ist. Zwangsläufig werden im Laufe des Projektes Fragen entstehen und Entscheidungen notwendig werden, die sich aus unklaren oder unvollständig Formulierungen ergeben. Hier kann die Motivation des Projektes – also die Antwort auf das “Warum” – das Zünglein an der Entscheidungswaage sein.

Ein Beispiel: Eine Firma führt einen neuen Online-Shop ein. Die Wahl des Shop-Systems ist getroffen, damit wäre ein Teil des “Wie” auch schon beantwortet. Es stehen die Entscheidungen an, welche der Funktionen, die das System bereitstellt, konkret genutzt werden sollen. Hier kann die Motivation des Projekts “das Warum” weiterhelfen. Soll der Shop Prozesskosten senken oder den Umsatz erhöhen? Im ersten Falle wären automatische Schnittstellen zu angeschlossenen Systemen höher zu priorisieren. Im zweiten Fall müsste das Augenmerk eher auf die Gestaltung der Kundensicht des Shops gelegt werden

Wenn dieses “Warum” nicht klar formuliert und vom Auftraggeber des Projektes abgesegnet ist, lassen sich solche Entscheidungen kaum treffen. Vom Zwang solche Entscheidungen zu treffen ist die Projektleitung nur dann befreit, wenn Personal, Geld und Zeit im Überfluss zur Verfügung stehen. In diesem – leider meist hypothetischen Fall – kann sich ein Grafik- und Produktspezialist um die Kundensicht kümmern, während der Kollege mit technischem Hintergrund die Schnittstellen zum Auftragssystem und zur Warenwirtschaft anpasst. Im anderen und realen Fall muss der Projektleiter entscheiden. Interessanterweise zeigt das Beispiel auch den Zusammenhang zur nächsten Frage “Wer soll es machen?”. Die Motivation des Projektes “Neuer Online-Shop” hat Einfluss auf das benötigte Know-how im Projektteam. Im ersten Fall wird eher ein Kollege mit Marketing-Hintergrund, im zweiten Falle ein Programmierer benötigt.

Zusammenfassung. Tragfähig formulierte Projektziele müssen die Frage nach dem “Warum” und dem “Was” beantworten.

1. Software-Entwicklung und die Frage: wie oder was?