Grundvoraussetzungen für erfolgreiche Projekte

Bei eigenen Projekten und bei der Betreuung von Kundenprojekten stellte ich immer wieder fest, dass erfolgreiche Projekt mindestens drei Grundvoraussetzungen erfüllt haben. Projekte in Schieflage hingegen ließen immer einen oder mehrere Voraussetzungen außer Acht.

  1. Eine klare Zieldefinition

    Ein Projekt verfolgt immer ein bestimmtes Ziel. Um ein Projekt erfolgreich werden zu lassen, muss dieses Ziel klar definiert und kommuniziert sein. Manchmal ist es sinnvoll, die genaue Zieldefinition gemeinsam zu erarbeiten.

  2. Definierte und dokumentierte Anforderungen

    Mit einem klaren Ziel vor Augen, ist das Erheben, Definieren und Dokumentieren von Anforderungen der zweite Schritt. Anforderungen beschreiben was warum erreicht werden soll.

  3. Starke Struktur und einen Plan

    Ein Projekt macht sich nicht von allein. Eine wichtige Voraussetzung bevor es losgehen kann ist Struktur. Struktur wird gegeben durch Rückhalt in der Führung, der Projektleitung und den Projektmitarbeitern. Diese starke Struktur setzt dann nicht stur einen Plan um, sondern nutzt diesen als Rahmenwerk

1. Eine klare Zieldefinition

Ein Projekt verfolgt immer ein bestimmtes Ziel. Um ein Projekt erfolgreich werden zu lassen, muss dieses Ziel klar definiert und kommuniziert sein. Manchmal ist es sinnvoll, die genaue Zieldefinition gemeinsam zu erarbeiten.

Was ist eine klare Zieldefinition?

Klar bedeutet, dass die Definition verständlich und frei von Widersprüchen sein muss. Eine Zieldefinition soll auch konkret sein und möglichst einen Zielzustand bzw. einen Nutzen beschreiben. Im grünen Kasten finden sich Beispiele, die die Zieldefinition teilweise oder ganz erfüllen.

Warum und wie sollen Ziele kommuniziert werden?

Es liegt auf der Hand, dass ein Mitarbeiter nur auf ein Ziel hinarbeiten kann, dass er auch kennt.

Das betrifft zunächst den Unternehmenszweck – Warum gibt es das Unternehmen in dem ich arbeiten und was ist dessen Ziel? Dann kommt das Projektziel. Was bringt dem Unternehmen dieses Projekt und warum bin ich dabei? Wo wollen wir hin, was ist das geplante Ergebnis?

Es gilt ferner, die verschiedenen Ziele, also Unternehmensziel und Projektziel in Einklang zu bringen. Diese müssen als Ganzes auch die Widerspruchsfreiheit erfüllen. Ansonsten fragen sich die Mitarbeiter zu Recht, was das denn soll.

Wie vermittle ich die Ziele? Ganz einfach: In einfachen Worten, am Anfang des Projektes und dann immer wieder. Das geht so:

„Liebe Mitarbeiter, wir beginnen nächsten Monat Projekt Super-XY. Diese Projekt hat zum Ziel: <Zieldefinition>. Damit ist das Projekt gut geeignet um und als Firma voran zu bringen, da wir ja <Unternehmensziel>.“

Beispiele für Ziele

Am Beispiel einer Anwendung für Bahnkunden wollen wir uns gute und schlechte Zieldefinitionen ansehen. Bekannt ist, dass für Kunden der Bahn eine App entwickelt werden soll und diese zahlreiche Informationen kostenfrei anbietet.

„Wir entwickeln eine mobile Anwendung die den Nutzer kostenfrei Bahn-Informationen bereitstellt."

Diese Definition ist verständlich und widerspruchsfrei, allerdings nicht sehr konkret. Ein klarer Zielzustand oder Nutzen wird auch nicht beschrieben. Es ist unklar, warum ein Unternehmer diese App entwickeln will? Einfach nur, weil er die Informationen bereitstellen möchte?

„Wir entwickeln für Bahnkunden eine mobile Anwendung die für ihn relevante Informationen wie bspw. Fahrpläne und Abfahrtzeiten, sowie Preise einfach und übersichtlich zur Verfügung stellt. Der Kunde oder Interessent kann dann einfach ein Produkt erwerben und Bahn fahren.“

Diese Beschreibung ist konkret und zeigt sowohl einen Kundennutzen (relevante Informationen) auf, als auch eine Beschreibung des Endzustandes (Kunde informiert sich und bestellt). Hierbei ist auch klar, warum der Auftraggeber dieses Produkt schaffen will; mehr Umsatz durch besseren Service.

Im Übrigen ist das Ziel: „Geld verdienen“ weder konkret, noch beschreibt es einen Kundennutzen. Allerdings ist es verständlich und frei von Widersprüchen.

2. Definierte und dokumentierte Anforderungen

Mit einem klaren Ziel vor Augen, ist das Erheben von Anforderungen der zweite Schritt. „Was soll warum erreicht werden?“ ist die Frage die hinter Anforderungen steckt. Dafür ist wichtig zu wissen, wer das Produkt benutzen soll und warum. Gibt es noch andere Projektbeteiligte (Stakeholder) die Einfluss haben oder ausüben können?

Wer ist am Projekt beteiligt und betroffen?

Ohne eine Liste aller vom Projekt Betroffenen, haben Anforderungen keinen Sinn. Warum? Weil wir nicht wissen, für wen das Projekt umgesetzt wird und welche Ziele mögliche andere Beteiligte verfolgen.

Mögliche andere Beteiligte sind Projektpartner, Auftraggeber oder andere Abteilungen im Unternehmenskontext. Zur Ermittlung der Stakeholder, siehe grüne Box.

Für den Vertrieb und das Marketing ist es ebenfalls hilfreich, aus den ermittelten Kunden und Kundengruppen sogenannte Personas zu erstellen. Personas umfassen meist noch mehr Kontext wie beispielsweise finanzielle oder gesellschaftliche Hintergrundinformationen die für das Produkt/Projekt relevant sind.

Woher kommen nun die Anforderungen?

Mit den Kunden und anderen Stakeholdern vor Augen, ist es viel einfacher Anforderungen zu ermitteln. Man muss sich „nur“ in die Lage der Stakeholder versetzen. Der Nutzen des Projektes und die Wünsche des Kunden sollten sich decken. Wenn nicht, ist das Projekt hier zu Ende und es kann wieder bei der Zielbestimmung angefangen werden.

In anderen Projekten kommt die Projektidee von einem Produktmanager. Dieser hat (hoffentlich) Kunden befragt und/oder deren Nutzungsverhalten analysiert oder ist auf Probleme gestoßen, die er für Kunden lösen möchte. Daraus ergab sich dann Input für das Ziel des Projektes und nun etwas konkreter für die Anforderungen.

Nun zum eigentlichen Thema; wo kommen die Anforderungen her?

Man nehme einen Kunden (oder Persona) und bilde (mit Papier und Stift) dessen Reise durch das fertige Produkt ab. Man stellt sich also vor, das Produkt wäre fertig. Was macht der Kunde dann und wie macht er das. Jeden Schritt kann und sollte man dokumentieren. Diese Doku gelingt am besten mit Papierprototypen.

Bei einer mobilen Anwendung (App) zeichnet man sich einfach ein Telefon auf und mal Inhalte auf das Display. Für jeden Schritt gibt es ein Bild. Dabei kann man Papierbausteine benutzen und Fotos machen oder jeden Schritt einzeln bauen und aufkleben.

Für Dienstleistungen bietet es sich an, tatsächlich einen Kunden zu zeichnen. Dieser wird auf dem Bild in den Kontext des Produktes gesetzt und die Reise des Kunden wird wie in einem Film beschrieben. Insbesondere bei dieser Variante bietet es sich an, mit dem Smartphone oder einer Kamera einen Film mit Ton aufzunehmen.

Der fertige Film oder der Prototyp auf Papier kann dann prima diskutiert oder potentiellen Kunden zur Verfügung gestellt werden um weitere Informationen zu erhalten.

Alles was als Forderung auftaucht wird dokumentiert. Ggf. gibt es noch das Bild dazu oder einen Hinweis auf den Kontext.

Nach einigen Runden sind dann die meisten und oft auch die wichtigsten Anforderungen bekannt.

Hinweis: Ein Nachteil dieser Methoden ist, dass der Kunde selten Input liefert der komplett neue Sichtweisen zulässt. Diese neuen Perspektiven müssen im Team bei der Suche nach neuen Lösungen entstehen. Dafür bietet sich bspw. Design Thinking an.

Stakeholder ermitteln – Praxistipp

Eine Methode mit der ich gute Erfahrungen gemacht habe um die Stakeholder zu ermitteln ist relativ einfach und schnell.

Ich gehe davon aus, dass es ein Team gibt, egal ob Führungsteam oder Projektteam. Einer der Teilnehmer moderiert. Er (oder Sie) achtet auf die Zeit und ordnet das Ergebnis. Benötigt wird ein Flipchart oder Whiteboard und (selbstklebende) Karteikarten.

Die Teammitglieder teilen sich in 2-er oder 3-er Gruppen auf und schreiben alle am Projekt beteiligte auf separate Karteikarten. Folgende Gruppen kommen immer wieder vor: Kunden, Auftraggeber, Mitarbeiter. Je detaillierter die einzelnen Beteiligten erfasst werden, desto besser.

Nach 15 Minuten ist Schluss. Der Moderator lässt die Teams reihum je eine Karte kurz vorstellen und er klebt es an die Wand (oder das Whiteboard). Während des Prozesses werden gleiche Karten einfach weggelassen, ähnliche gruppiert und Detaillierungen an die Gruppen gehängt. Beispielsweise gehört „Frau, Mitte 30, besser verdienend“ zur Gruppe „Kunden (allgemein)“ oder „Kundinnen“.

Das Team soll am Ende vom Moderator befragt werden, ob etwas fehlt oder wie die Stakeholder weiter gruppiert bzw. verallgemeinert werden sollen.

Da man es nicht jedem recht machen kann, muss definiert werden, welcher Stakeholder wichtiger ist. Stehen also alle Stakeholder fest, müssen diese priorisiert werden. Das geht visuell am einfachsten mit einer großen Zielscheibe. Je näher ein Stakeholder an der Mitte ist, desto wichtiger ist er.

Foto machen. Kommunizieren. Fertig.

3. Struktur und Planung

An diesem Punkt kennen Sie das Projektziel und haben Anforderungen eingesammelt. Es ist jetzt wichtig, sich nochmal die Rahmenbedingungen in Erinnerung zu rufen oder spätestens jetzt diese zu klären:

  • Wie hoch ist das Budget?
  • Gibt es feste Termine? Wenn ja welche und warum?
  • Ist klar, wer man Projekt mitarbeitet oder mitarbeiten wird und in welchem Umfang?
  • Wer ist für das Projekt verantwortlich (ich gehe davon aus, dass Sie es sind)?

Halten Sie diese Punkte in einer Übersicht fest, Sie werden sie brauchen.

Geben Sie Struktur

Mit Struktur ist gemeint, dass das Projekt einen Rahmen benötigt, in dem Dinge geklärt sind. Innerhalb des Rahmens verläuft das Projekt wie erwartet und stellt keine besonderen Anforderungen an dessen Organisation.

Insofern noch nicht vorhanden, ist eine priorisierte Liste der Anforderungen notwendig. Die Anforderung die in der Liste ganz oben steht, hat die höchste Priorität, die darunter die zweit-höchste usw. Es muss allen Beteiligten klar sein oder klar gemacht werden, dass nicht zehn Dinge Priorität eins haben können, auch wenn man das gern möchte.

Erarbeiten Sie die Prioritäten mit den Stakeholdern des Projektes und beachten Sie dabei deren Wünsche. gegebenenfalls prüfen Sie, ob die Wünsche technisch in dieser Reihenfolge umsetzbar sind.

Das Ziel muss sein, möglichst früh einen hohen (Kunden-)Nutzen zu generieren. Siehe auch rechts im grünen Kasten (Struktur: Anforderungen).

Planen der Umsetzung

Erfolgreiche Projekte haben immer einen Plan. Dieser Plan ist nicht auf Tage oder gar Stunden ausgeplant, sondern ordnet die Anforderungen den Teams oder Mitarbeitern zu und macht Abhängigkeiten sichtbar. Die Zuordnung sollte er kurzfristig gemacht werden um auf aktuelle Ereignisse oder Umplanungen reagieren zu können. Wie kommen die Anforderungen zum Team?

Nehmen wir an, es gibt nur ein Team. Dieses Team könnte entweder nur eine Anforderung bearbeiten, oder so viele wie Teammitglieder vorhanden sind. Was glauben Sie ist das Beste?

Genau: Es kommt darauf an. Jedoch ist weniger oft mehr. Konzentriert sich das Team auf ein Thema, arbeiten alle sehr zielgerichtet und alle wissen hinterher Bescheid. Sie könnten einwenden, dass sich nicht jeder mit allem auskennt und deshalb wenig Beitrag leisten kann. In der Anfangsphase kann das vorkommen; jedoch finden die Teammitglieder schnell eine Rolle, die sie selbst und das Team bereichert. Vertrauen Sie dem Team.

Zur Vorgehensweise: Setzen Sie sich mit dem Team zusammen und erörtern Sie maximal die Top 3 Anforderungen. Klären Sie Verständnisfragen ab und lassen Sie sich vom Team erklären, wie es die Anforderung umsetzen will. Gegebenenfalls benötigen Ihre Mitarbeiter etwas Zeit, sich über Architektur oder Struktur der Lösung Gedanken machen zu können. Geben Sie Ihnen diese Zeit (max. 4h) und steigen Sie dann wieder in den Dialog ein. Mehr Details finden Sie in der blauen Box (Dialog mit dem Team).

Die Umsetzung

Das Team sollte nun in der Lage sein, ein oder zwei Anforderungen umzusetzen. Gehen Sie täglich vorbei und lassen Sie sich berichten was erreicht wurde und wo es Probleme gibt. Letztere deuten auf unklare Anforderungen oder schlicht Definitionslücken hin. Beides ist normal. Beides sollte schnell beseitigt werden. Das ist Ihre Aufgabe als Projektleiter!

Fragen Sie das Team auch, wann es schätzt mit der übertragenen Aufgabe fertig zu sein? Ist die Antwort jenseits von Übermorgen, lassen Sie das Team Ihnen die Zwischenschritte erklären. Notieren Sie diese und fragen Sie dann, wann der nächste Zwischenschritt fertig ist.

Eine Aufgabe sollte nur mit sehr guter Begründung zwei Arbeitstage oder besser nur einen Arbeitstag überschreiten. Beispiel: „Wir warten darauf, dass die Sonnenblumenkerne keimen.“ – Hier kann man die Aufgabe aber pausieren und eine neue Aufgabe annehmen.

Nach einigen Runden der Auftragsvergabe und -Umsetzung entwickeln alle ein Gefühl dafür, was in welcher Zeiteinheit geschafft werden kann.

Prognose

Wann werden Sie fertig sein oder was haben Sie, wenn die Zeit abgelaufen ist?

Das weiß niemand vorher! Da Sie aber die Rahmenbedingungen kennen, einen Urlaubsplan der Mitarbeiter haben und wissen, wie hoch die Arbeitsgeschwindigkeit ist (durchschnittliche Realisierung von Anforderungen pro Woche), können Sie in die Zukunft blicken.

Nehmen Sie einfach an, dass Sie auch in Zukunft mindestens 80% der bisherigen Leistung erreichen werden. Gehen Sie dann durch die Anforderungen und Sie sehen, wann Sie voraussichtlich was erledigt haben.

Diese Prognose wird immer besser, da sie auf Tatsachen basiert. Sie werden auch immer besser, da Sie die Anforderungen die zu groß waren und immer weiter zerlegt wurden, selbst zerlegen, bevor Sie sie dem Team präsentieren. Dadurch schaffen Sie eine eher konstante Größe an Arbeit. Das erlaubt Ihnen einen gute Prognose.

Ihnen und mir ist bewusst, dass es keine Schablone für alle Projekte gibt. Sollten Sie konkrete Fragen haben oder mal unverbindlich mit mir reden wollen, schreiben Sie mir eine kurze Email. Alles Nötige finden Sie auf meiner Kontaktseite.

Struktur: Anforderungen

  • es gibt eine priorisierte Liste
  • der oberste Punkt hat die höchste Priorität
  • nachfolgende Listeneinträge haben immer eine niedrigere Priorität
  • Das sieht dann so aus:
  1. Anforderung „Susi“
  2. Anforderung „Horst“
  3. Anforderung „Willi“
  4. Anforderung „Otto“usw.

Wichtig: Diskutieren Sie jetzt die Prioritäten 1-10 aus. Alles was danach folgt ist zunächst unwichtig.

Dialog mit dem Team

  • bleiben Sie immer im Dialog
  • wenn Sie die Teamleistung (be)werten wollen, dann nur positiv
  • Geben Sie insbesondere dann Feedback, wenn die Leistungen besser wurden
  • sind Sie mit der Leistung oder Kommunikation einzelner Mitglieder unzufrieden, sprechen Sie mit diesen unter vier Augen. Äußern Sie Zuversicht und Ihren Glauben daran, dass es besser werden kann.

Besprechen und Zerlegen der Anforderungen

Sie sollten in der Lage sein, Anforderungen schlüssig in wenigen Sätzen erklären zu können. Bilder oder sogenannte Wireframes können Sie hierbei gut unterstützen.

Können Sie Fragen des Teams nicht gleich beantworten, schreiben Sie diese auf und vertagen Sie die Klärung dieser Frage. Holen Sie sich dann so schnell es geht die notwendigen Informationen. Sollte es einen Wissensträger geben, der nicht Teil des Teams ist, integrieren Sie diesen in Ihre Planungsrunden.

Lassen Sie das Team nicht allein! Wenn das Team zu lange auf unklaren Anforderungen oder mit offenen Fragen allein ist, passiert Folgendes: Es beginnt Annahmen darüber zu treffen, was wohl gemeint sein könnte oder was die Antwort auf eine Frage sein könnte. Das gefährdet Ihr Projekt! Im Stillen getroffenen und dann undokumentierte Annahmen beeinflussen das Ergebnis, ohne dass dies einfach nachvollzogen werden kann.

Hinterfragen Sie, ob ihr Team alles richtig verstanden hat.

Jede Unklarheit lässt sich in dieser Phase noch günstig und durch miteinander reden beseitigen!