Zurück zur Methodenübersicht

Ziele

Ziele: Basis

Einleitung Ziele

Dieses Kapitel behandelt die methodische Unterstützung des wichtigen Themas Auftragsklärung. Zum Beispiel wird beantwortet, mit welchen Methoden man die Auftragsklärung unterstützen kann, welche Zielklassen man unterscheidet, wie man priorisiert, wie man Ziele konkret beschreibt und wie man Zielkonflikte identifiziert und löst.

Gut formulierte Ziele sind wegen vieler Funktionen ein Erfolgsfaktor in Projekten

Gut formulierte Ziele erfüllen viele Funktionen im Projekt. Umgekehrt sind schlecht formulierte laut vieler Untersuchungen eine der Top-Ursachen für gescheiterte Projekte.

Es gibt viele Projektmanagement-Methoden, mit denen die Auftragsklärung zwischen Auftraggeber und Projektteam verbessert werden kann.

Zielklassen des magischen Dreiecks priorisieren als Vorratsentscheidung für das ganze Projekt

Für den Begriff magisches Dreieck gibt es zahlreiche Definitionsversuche, die zumindest mich alle nicht zufrieden stellen. Deshalb verzichte ich an dieser Stelle auf eine Definition. Stattdessen beschreibe ich nur die Quintessenz des magischen Dreiecks: In einem Projekt kann man die 3 Zielklassen “Leistung”, “Kosten” und “Termin” nicht unabhängig voneinander verändern. Zwischen jeder Zielklasse besteht ein Konkurrenzverhältnis: Wenn der Auftraggeber ein zusätzliches Leistungsmerkmal haben möchte, wird das in der Regel mehr kosten und/oder zu einem späteren Fertigstellungstermin führen. Daran ist aber m.E. nichts Magisches sondern das ist gesunder Menschenverstand.

Im Rahmen der Auftragsklärung ist es sehr empfehlenswert, schon auf auf der Ebene der Zielklassen eine eindeutige Rangliste der Zielklassen zu bilden und mit dem Auftraggeber zu vereinbaren. Der Hauptvorteil einer solchen Vorratsentscheidung: Die Projektleitung kann viele Einzelentscheidungen schnell und ohne Rücksprache mit dem Auftraggeber treffen - entsprechende Befugnisse vorausgesetzt.

Beispiel: Angenommen, man hätte als Projektleiter die Befugnis, einen Teil des Budgets selbstständig für externe Berater auszugeben. Damit würde er aber das Kostenziel nicht mehr erreichen. Über die grundsätzlichen Prioritäten wurde aber nicht mit dem Auftraggeber nicht gesprochen. Jetzt fällt eine wichtige Engpassressource für mehrere Wochen aus und kann intern nicht ersetzt werden. Der Auftraggeber ist 8 Wochen auf Abenteuerurlaub im Dschungel und nicht erreichbar. Nach seiner Rückkehr fragt der Projektleiter, ob er das Geld für einen externen Berater ausgeben darf, um den Termin zu halten. Damit würde er aber das Kostenziel verfehlen. Der bekommt daraufhin eine harte Kritik des Auftraggebers, warum er das nicht schon längst gemacht habe. Jetzt hätten wir 8 Wochen Zeit verschwendet. Habe er denn nicht gewusst, dass ihm der Termin viel wichtiger ist als die Erreichung des Kostenziels? In der Projektpraxis, die ich kennengelernt habe, wird die Antwort leider recht oft sein: “Nein, das habe ich nicht gewusst”.

Der Grund für diese Ineffizienz in der Projektabwicklung liegt aus meiner Sicht vor allem an zwei Gründen:

  • Das Prinzip der Vorratsentscheidung auf Basis klarer Priorisierungen ist unbekannt.
  • Das Prinzip der Vorratsentscheidung ist zwar bekannt, wird von einem unrealistisch kritischen Menschenbild überlagert. Motto: Was ist das denn für ein seltsamer Vorschlag, lieber Projektleiter? Ich erwarte selbstverständlich, dass sie alle vereinbarten Ziele erreichen, daran messe ich Sie. Also, dass Sie die Leistungsziele erreichen und das innerhalb der verabredeten Zeit und ohne Budgetüberschreitung. Dahinter steckt oft die Vorstellung, dass sich Projektleitung und Team z.B. nicht mehr anstrengen, effizient und kostenbewusst zu agieren, wenn das Kostenziel nur Prio 3 bekommt. Die Idee der Vorratsentscheidung, nämlich in der konkreten Entscheidungssituation in Orientierung an dieser grundsätzlichen Priorisierung schnell und konsistent zur grundlegenden Priorisierung zu entscheiden, wird vom kritischen Menschenbild überlagert.

Die Benennung klarer Leistungsziele schafft eindeutige Ergebnisse und gewährleistet effiziente und effektive Projektsteuerung

Leistungsziele beschreiben greifbare Ergebnisse am Projektende. Idealerweise lassen sie sich messen. Typische Beispiele: Eigenschaften eines Produkts, Funktionen eines Systems und Features eines Gesamtlieferobjekts. Beispiel: „Die Software verarbeitet 10.000 Datensätze pro Stunde fehlerfrei.“

⚠️ Leistungsziele beschreiben den gewünschten Zustand am Ende des Projekts. Nicht eine Tätigkeit.

Abgrenzung: Leistungsziele und soziale Ziele

  • Leistungsziele: Sie beschreiben Ergebnisse, die der Kunde nutzen kann. Am Projektende übergibt man sie inklusive Dokumentation. Solche Übergaben sind mit sozialen Zielen nur selten möglich. Beispiel: Ein Motor mit klar definierten Emissionswerten. Kernfrage: Was kann der Kunde danach konkret einsetzen? Leistungsziele sind in der Regel Gegenstand von Abnahmen.
  • Soziale Ziele: Soziale Ziele betreffen nicht das Ergebnisobjekt selbst. Beispiel: Eine umweltfreundliche Produktion des Motors. Das Produkt bleibt gleich. Der Herstellungsprozess ändert sich. Soziale Ziele lassen anders als Leistungsziele sich nicht „in die Hand drücken“. Sie wirken indirekt. Sie sind in der Regel kein Gegenstand von Abnahmen.

💡 Bei einem zusammenhängenden Lieferobjekt könnten zum Beispiel einzelne Komponenten, die möglichst unabhängig voneinander sind, als einzelne Leistungsziele aufgeführt werden. Bei unabhängigen Lieferobjekten bietet sich die getrennte Darstellung der einzelnen Lieferobjekte als Leistungsziele an. Der Vorteil unabhängiger Leistungsziele: Der Auftraggeber kann separat priorisieren. Beispiel: Ein Kunde bestellt eine App und ein Schulungskonzept. Beide Ergebnisse lassen sich unabhängig bewerten und priorisieren.

Sollten Zwischenziele in der Zielhierarchie oder nur im Phasenplan dargestellt werden? Siehe Vertiefung

Soziale Ziele klären, um Akzeptanz zu sichern und formalen Erfolg wirksam zu machen

Soziale Ziele betreffen Zufriedenheit, Zusammenarbeit, Entwicklung, Wirkung und Reputation.
Sie entscheiden oft über den wahrgenommenen Projekterfolg. Auch dann, wenn Termine, Kosten und Leistungen stimmen, also das magische Dreieck im engeren Sinn erfüllt ist. Beispiele:

  • Zufriedene Stakeholder betreffen Auftraggeber, Projektteam und Anwender sowohl in Bezug auf die Einbindung als auch in Bezug auf die Zufriedenheit mit dem Endergebnis. Diese Zufriedenheit ist oft entscheidend für den Projekterfolg. Selbst, wenn man formal das magische Dreieck erreicht hat, nutzt das wenig, wenn wichtig Stakeholder unzufrieden sind. Das mag ungerecht wirken, nutzt aber nichts: Unzufriedene Stakeholder entwerten formale Zielerreichung. Beispiele für soziale Ziele, mit denen Stakeholderzufriedenheit angestrebt wird:
    • Der Auftraggeber erhält klare, gestufte Informationen.
    • Die Projektleitung ermöglicht durch pyramidale Kommunikation eine schnelle und effiziente Entscheidungsfindung.
    • Das Projektteam vermeidet Dauerüberstunden.
    • Anwender fühlen sich ernst genommen und eingebunden.
  • Gute Zusammenarbeit im Team. Beispiel: Der Teamgeist wächst durch transparente Zusammenarbeit. Die Projektkultur prägt spätere Vorhaben positiv.
  • Gezielte Kompetenzentwicklung. Projekte können gezielt zur Personalentwicklung beitragen. Das gilt für Fachwissen, Methoden und Zusammenarbeit. Beispiel: Ein Teammitglied lernt Projektsteuerung im laufenden Projekt. Das Lernen “on the Job” unterstützt die Arbeit, steht aber nicht im Mittelpunkt.
  • Nachhaltige Wirkung. Beispiele: Ein Projekt achtet bewusst auf regionale Wertschöpfung. Oder es vermeidet soziale Nachteile für Betroffene.
  • Stärkung von Vertrauen und Ruf. Reputationsziele überschneiden sich mit Nutzenzielen, für die die Projektleitung klassisch nicht verantwortlich ist. Die Abgrenzung ist oft unscharf.

Grenzfälle sozialer Ziele: Manche sozialen Ziele werden bewusst Teil des Lieferumfangs. Dann verlieren sie ihren informellen Charakter. Beispiel: Die Akzeptanz einer Nutzergruppe ist vertraglich zugesichert. Damit wird sie zum Leistungsziel.

Kosten und Termine fokussieren und dadurch Klarheit für Entscheidungen schaffen

Terminziele und Kostenziele bilden den Rahmen für die Leistungsziele: Innerhalb welches zeitlichen Rahmens und zu welchen Kosten soll das Projekt abgewickelt werden?

💡 Tipps:

  • Man muss nicht jedes Leistungsziel in Kosten- und Terminzielen spiegeln. Entscheidend ist mehr, was den Auftraggeber während der Auftragsklärung wirklich interessiert. Besonders interessant für die meisten Auftraggeber sind zum Beispiel das Gesamtbudget und besonders teure Einzelkomponenten. Alles andere lenkt ab. Beispiel:
    • Ein System besteht aus Software und Spezialhardware. Die Hardware ist der größte Kostenblock. Genau diese Kosteninformation hilft bei der Priorisierung.
    • Teure Einzelkomponenten zeigen Risiken.
    • Sie zeigen auch, wo sich Einsparungen lohnen.
    • Der Ausweis solcher Kostenziele macht also handlungsfähig. Insofern sollten nicht alle Kosten gleich behandelt werden. Sonst gehen die echten Kostentreiber unter.
    • Nicht alle Ziele mit aufgeführten Kosten sind automatisch Kostenziele. Beispiel: Wenn ich durch mein Projekt die zukünftigen Releasewechselkosten auf x Euro beschränken soll, ist das ein Leistungsziel und kein Kostenziel. Die langfristigen Releasewechselkosten haben nichts mit dem Kostenrahmen zu tun, innerhalb dessen das Projekt abwickelt werden soll.
  • Top-Down oder Bottom-Up klar unterscheiden: Gibt der Auftraggeber ein Budget vor, gilt es ab dem ersten Briefing sofort und oft ohne Verhandlungsmöglichkeit. Beispiel: Der Auftraggeber nennt drei Millionen Euro. Diese Zahl gehört direkt in die Zielhierarchie. So erkennt der Auftraggeber, dass man sein Briefing verstanden hat.

Buttom-Up: Kosten ohne Budgetvorgabe bewusst spät nennen
Gibt es keine Budgetvorgabe, gilt Zurückhaltung. Die Kosten sollten so spät wie möglich genannt und im Projektauftrag vereinbart werden. Zu früh genannte Schätzungen bleiben oft im Kopf des Auftraggebers, so dass Enttäuschungen vorprogrammiert sind. Zu frühe Kosten schaden oft mehr als fehlende Kosten, weil sie zu inoffiziellen Preiszusagen werden können. Spätere Anpassungen wirken dann wie Fehler.

Um sich zu schützen, sollte man Kostenschätzungen so spät wie möglich und immer mit den jeweiligen Rahmenbedingungen, Annahmen und der Kalkulation mitliefern. Bei internen Projekten sollte auch die Kalkulation transparent dargestellt werden.

Terminziele schlank halten und spezielle Auftraggebervorgaben zurückspiegeln: Projektstart und Projektende sollten zumindest im Auftrag vereinbart werden. Taggenaue Zwischenziele sollten in der Definitionsphase nur erfasst werden, wenn es der explizite Wunsch des Auftraggebers gewesen ist. Beispiel: Der Auftraggeber verlangt einen Prototyptermin. Dieser Termin gehört ins Zielsystem, um zu demonstrieren, dass man den Wunsch des Auftraggebers verstanden hat. Interne Meilensteine aus dem Phasenplan gehören, wie schon oben erwähnt, aus meiner Sicht nur in den Phasenplan, wenn sie der Grobplanung des Projekts entsprechen und kein expliziter Wunsch des Auftraggebers gewesen sind.

Effiziente Auftragsklärung mit übersichtlicher Zielhierarchie

Zielhierarchie bezeichnet die strukturierte Ordnung von Zielen nach Ebenen, wobei übergeordnete Ziele schrittweise durch darunterliegende Teilziele (wie zum Beispiel Zielklassen) und Einzelziele konkretisiert werden.

Die Zielhierarchie ist eine empfehlenswerte Methode zur Ermittlung der Ziele: Viele Auftraggeber und Entscheidungsträger sind bei der Auftragsklärung gerne auf der Helikopterperspektive unterwegs und überlassen die “Operationalisierung der Ziele” ab einem bestimmten Detaillierungsgrad gerne dem Fachbereich (Siehe auch SMART-Formel). Das globale Ziel bzw. das Oberziel fasst den Projektauftrag für die Projektleitung zusammen. Es verdichtet Einzelziele zu einer klaren Leitlinie. Die Projektleitung und wichtige Stakeholder erkennen sofort, was am Ende beim Projekt zu welchen Rahmenbedingungen herauskommen soll. Mit einer eigenen (z.B. kursiven) Formatierung könnte man sogar ausgewählte Nutzenziele unterbringen, um das Projektmarketing zu erleichtern und Stakeholder, die das Projekt z.B. mit Ressourcen unterstützen sollen, den Nutzen direkt zu vermitteln, die das Projekt in der Anwendungsphase auch für sie hat. Die eigene Formatierung und Erläuterung in einer Legende als Nutzenziel ist nötig, um zu verdeutlichen, dass das Nutzenziel (klassisch) nicht zum offiziellen Projektauftrag der Projektleitung gehört, obwohl man sich als Projektleiter natürlich während des Projekts als Unternehmertyp auch daran zu orientieren kann.

💡 Ob man irgendwann im Verlauf der Auftragsklärung oder nach Abschluss der Auftragsklärung die grafische Struktur beibehält, ist auch von der Abbildung einiger Projektmanagement-Methoden in Templates abhängig. Verbreitet ist es z.B., Excel-Templates für Methoden wie Zielhierarchie, Stakeholder oder Risiken zu verwenden. Es ist legitim, die weitere Verwaltung der Ziele irgendwann aus einer grafischen Struktur in eine tabellarische Struktur zu übertragen. Zu Beginn der Auftragsklärung empfehle ich aber immer die Erarbeitung einer grafischen Struktur in einem Workshopformat - zum Beispiel mit Post-ITs.

Das Oberziel wird in einer Zielhierarchie also in Teil- und Einzelziele heruntergebrochen. Die folgenden Varianten können - abhängig von Situation und persönlichem Geschmack - genutzt werden:

  • Grafische Zielhierarchie bis inklusive Ebene der Messkriterien und des Ausmaßes (eher bei kleineren Projekten)
  • Grafische Zielhierarchie ohne die Ebene der Messkriterien und des Ausmaßes. Diese letzte Ebene wird in eine eigene Zieltabelle verlagert. Die Verbindung und Konsistenz zwischen Zielhierarchie und Zieltabelle wird dabei über eine eindeutige ID hergestellt, die jedes Ziel erhält. Die grafische Zielhierarchie wird dann mit dem Auftraggeber besprochen, die detaillierten Vorgaben werden mit dem Fachbereich vereinbart. Dieses Verfahren ist bei größeren Projekten oft empfehlenswert.
  • Tabellarische Zieltabelle inklusive der Ebene der Messkriterien und des Ausmaßes.

Bei den Verfahren der Zielermittlung kann zwischen werden zwischen Top-Down-Verfahren (Zielvorgabe durch Auftraggeber), Bottom-UP-Verfahren (Zielableitung durch Verbesserungsvorschläge der operativen Ebene) und Gegenstromverfahren (Kombination beider Verfahren) unterschieden werden.

Dabei wird die Auftragsklärung in der Regel nicht in einem Meeting beendet, sondern in diversen Iterationsschleifen immer wieder Feintuning mit dem Auftraggeber betrieben. Oft weiß der Auftraggeber selbst nicht so genau, was er überhaupt möchte. In diesem Fall liegt es an der Projektleitung, auf Basis eines oft eher dürren und unstrukturierten Briefings einen ersten Vorschlag in der Struktur der Zielhierarchie zu machen - gerne auch versehen mit einem ersten Priorisierungsvorschlag. Es ist dabei legitim, nicht nur die Wünsche des Auftraggebers in einer bestimmte Struktur abzubilden, sondern auch eigene Annahmen zu treffen und plausible Ergänzungen vorzunehmen. Diese würde man dann im nächsten Treffen dem Auftraggeber zeigen:

  • Um eine Bestätigung vom Auftraggeber zu bekommen, ob man die letzten Wünsche korrekt eingearbeitet hat
  • Um eine Bestätigung vom Auftraggeber zu bekommen, ob die Annahmen und antizipierten Zusatzwünsche sinnvoll sind.

💡 Manchmal wird in meinen PM-Trainings die Idee formuliert, man müsse dem Auftraggeber für ein wirksames erstes Briefing Mindestvorgaben machen. Ohne eine gewisse Mindestsubstanz könne die Projektleitung mit diesem iterativen Auftragsklärungsprozess nicht sinnvoll starten. Dazu kann ich nur aus langjähriger Erfahrung sprechen: Die wenigsten internen und externen Auftraggeber werden sich an Vorgaben halten. Selbst, wenn in einer AKV-Rollenbeschreibung eine Mindeststruktur wie Lieferobjekte, Kosten- und Terminvorstellung, Nichtziele, Priorisierung des magischen Dreiecks vorgesehen sein sollte: In der von mir erlebten Praxis ist das Briefing mal gut und mal weniger gut. Sinnvoller ist für mich die folgende Überlegung: “Der Auftraggeber soll alle nur irgendwie zugängliche Informationen zu einem möglichen Projekt bereitstellen.” Und es aushalten, dass man als professioneller Projektleiter viele Fragen stellen wird und der Auftrag nicht in einer Iterationsschleife stehen wird. Das kann man auch gerne selbstbewusst und klar als Projektleiter ankündigen. Auch wenn es für die meisten Auftraggeber nicht besonders angenehme ist, immer wieder mit erweiterten Zwischenständen der Zielhierarchie auf Basis eines ersten groben Briefings konfrontiert zu werden: Erfahrungsgemäß nehmen sie die Projektleitung als professionell und nicht als praxisfern und zu formalistisch wahr. Wenn die “Pragmatismus-Keule” ausgepackt wird: “Jetzt seien Sie doch mal pragmatisch und fangen einfach mal an, der Rest wird sich schon klären”, sollte man bei planbasierten Ansätzen auf der Hut sein. Wenn das Projekt im Chaos versinkt, sind die “pragmatischen Auftraggeber” oft die Ersten, die die Projektleitung mit den Worten kritisieren: “Sie hätten mir mehr “challengen” müssen, Sie sind doch der Profi”.

💡 Die Formulierung eines zusammenfassenden Oberziels ist oft leichter, wenn alle Einzelziele klar sind und sich sinnvoll verdichten lassen.

💡 Ziele werden im Passiv beschrieben, um den zukünftigen Zustand am Ende des Projekts zu symbolisieren. Also besser “Software eingeführt” statt “Software einführen”.

Dieser Tipp mag sich zunächst wie eine Kleinigkeit anfühlen. Aber erfahrungsgemäß ist die Wirkung dieses kleinen grammatikalischen Kniffs sehr groß. Wenn man Ziele im Infinitiv (Grundform eines Verbs) schreibt, rutscht man schnell in eine granulare Todo-Liste ab. Dann wird nicht nur der gewünschte Endzustand sondern sehr stark auch der Weg zum Endzustand beschrieben. Verben im Infinitiv werden oft als zukünftige Todos und nicht als gewünschter Endzustand interpretiert. Das reduziert die Qualität der Auftragsklärung oft stark. Die notwendigen Aktivitäten zur Zielerreichung werden vielmehr im sogenannten Projektstrukturplan beschrieben.

Nichtziele sollten immer angesprochen werden, um bei der Abnahme keine Enttäuschungen beim Auftraggeber zu erzeugen. Beispiel: „Lieber Auftraggeber, ich habe verstanden, dass Sie sich das Folgende von uns nicht wünschen. Habe ich Sie da richtig verstanden?“ Oft kommen dann implizite Erwartungen und Missverständnisse ans Tageslicht. Mögliches Vorgehen: Mit verschiedenen Sparringspartnern (erfahrene Spezialisten, Projektleiter ähnlicher Projekte) zusammensetzen und mit Ihnen eine Liste mit möglichen weiteren Erwartungen des Auftraggebers erstellen. Bei der ersten Demonstration dieser möglichen Nichtziele kommt oft die Antwort, dass der Auftraggeber bestimmte Ziel bzw. Projektinhalte im Projekt sieht und sogar fest davon ausgegangen ist, dass sie zum Projekt gehören. Häufige Aussagen: “Das ist doch Standard, da muss man doch gar nicht drüber sprechen.” Genau das ist der Satz, der sehr gefährlich für die Akzeptanz und den Erfolg des Projekts ist, wenn er erst am Ende des Projekts bei der Abnahme geäußert wird. Deshalb ist es von großer Bedeutung, diese Diskussion soweit wie möglich im Rahmen der Auftragsklärung zu führen.

💡 Meist sind Nichtziele leichter auf Basis bereits smarter operationalisierter Ziele zu beschreiben.

Ziele sollten konsequent während der Auftragsklärung priorisiert werden. Prioritäten ersetzen während der Projektabwicklung Debatten durch Handlungsfähigkeit. So können viele Abstimmungen entfallen und das Projekt gewinnt deutlich an Tempo.

Die Priorisierung noch während der Auftragsklärung dient als “Entscheidungsvorrat”. Der Auftraggeber legt die Prioritäten einmal verbindlich mit Hilfe der Projektleitung fest. Die Projektleitung kann bei entsprechenden Befugnissen darauf aufbauend eigenständig und damit schnell und effizient viele Detailentscheidungen während der Umsetzung treffen. Und das oft ohne notwendige Kontaktierung des - ggf. gerade nicht verfügbaren - Auftraggebers. Die Prioritäten gehören zum Projektauftrag.

Hintergrund zur Vorratsentscheidung: Man kann eine Vorratsentscheidung mit dem Reisverschlussverfahren auf der Autobahn vergleichen. Wenn sich zwei Autos bei einer Fahrbahnverengung treffen, ist es üblich, sich abwechselnd einzufädeln. Also abwechselnd das Auto von der linken Spur und dann wieder von der rechten Spur. Dadurch diese klare Regel läuft der Verkehr effizient und gleichzeitig durch die Fahrbahnverengung. Ohne diese allgemein bekannte Regel müsste jedes neue Paar von Autofahrern bilateral aushandeln, was deutlich länger dauert und ineffizienter ist. Das Pendant zum Reißverschlussverfahren als Regel ist in Projekten die klare Priorisierung im Projekt als Regel.

⚠️ Um Missverständnisse zu vermeiden: Die Priorisierung sagt nicht, womit in der Planung des Projekts begonnen wird. Sie dient ausschließlich als Orientierung für Entscheidungen während der Projektabwicklung und wird häufig im Projektauftrag festgehalten.

In der Zielhierarchie können auch die Projektziele grafisch mit den Unternehmenszielen verbunden werden. Siehe Vertiefung

Alternative Strukturierung der Zielhierarchie nach Ergebnisziele und Vorgehenszielen

In der Literatur finden sich alternative Strukturierungskonzepte für die Einzelziele und Zielklassen. Recht verbreitet neben der Struktur des magischen Dreiecks ist auch eine Struktur in Ergebnisziele und Vorgehensziele. Die Unterschiede sind m.E. eher gering und insofern auch Geschmacksache:

  • Das Wort “Ergebnisziel” betont mehr als das Wort “Leistungsziel”, was am Ende des Projekts als Ergebnis vorliegen muss.
  • Oft werden die sozialen Ziele auch den Ergebniszielen zugeordnet. Ich ordne die sozialen Ziele aber lieber der Kategorie Vorgehensziele zu. Gründe:
    • Wenn wichtige Stakeholder das Ergebnis der Projektergebnisse bewerten sollen, kommt das zumindest bezüglich der formalen Ziele schon über die Abnahmekriterien zum Ausdruck. Eine zusätzliche Zielsetzung in der Kategorie “soziale Ziele”, die sich auf die Erreichung der formalen Ziele bezieht, wäre insofern redundant und verwirrend.
    • Wenn wichtige Stakeholder von den formalen Zielen abweichende Ziele haben, wird man diese - unter Umständen politisch sensible - Information eher nicht in einer offiziellen Zielhierarchie zum Ausdruck bringen, sondern eher in der Methode “Stakeholdermanagement”, welche man nur mit wenigen Vertrauten teilt und nicht auf ein öffentlich zugängliches Projektlaufwerk legt.
    • Einen eigenständigen zusätzlichen Aspekt, den die sozialen Ziele beitragen können, sehe ich eher in der Abwicklung des Projekts und im Umgang mit wichtigen Stakeholdern. Die jetzt aufgeführten Beispiele hätten dann also eher einen “Vorgehenszielcharakter”:
      • Können z.B. Überstunden im Projektteam vermieden werden? Werden die ggf. als sehr wichtig eingeschätzten Teamregeln eingehalten?
      • Wird der Auftraggeber regelmäßig informiert und mit genau den richtigen Informationen in eine Situation gebracht, angemessene Entscheidungen zu treffen?
      • Werden regionale Lieferanten in das Projekt einbezogen?
      • Lernt das Projektteam etwas für zukünftige Projekte dazu? Hier könnten typische Personalentwicklungsziele untergebracht werden.
    • Aus meiner Sicht ist es dann auch naheliegend, vom Auftraggeber definierte Rahmenbedingungen in den Vorgehenszielen zu hinterlegen. Diese Rahmenbedingungen haben nicht unbedingt immer etwas mit sozialen Zielen im engeren Sinne zu tun. Beispiel:
      • Berücksichtigung wichtiger Regularien im Bereich Compliance
      • Abwicklung des Projekts mit einem hybriden Projektmanagement-Ansatz
    • Solche speziellen Vorgehensziele können natürlich auch zusätzlich zur Zielhierarchie auf einem Extra-Slide als Anhang ausgeführt werden. Im Projektsteckbrief würden sie bei besonderer Bedeutung ebenfalls stehen. In weiter oben dargestellten Struktur der Zielhierarchie im magischen Dreieck passt sie m.E. nirgends genau hin. Das liegt aber auch daran, dass ich der Einfachheit halber Leistungsziele eng als Ergebnisziele interpretiere. Wenn man eine etwas weitere Interpretation zulässt, kann man das Vorgehen im Projekt natürlich auch als weiteres Leistungsziele in dieser Zielklasse direkt in der Zielhierarchie aufführen. Im oben beschriebenen Beispiel habe ich das Einzelziel “hybrider PM-Ansatz” weggelassen.
    • Letztlich ist die Frage, ob soziale Ziele zu Leistungszielen gehören oder ob die Art der Projektabwicklung zusammen mit den sozialen Zielen in der Zielhierarchie aufgeführt wird oder nicht, nirgends eindeutig definiert. Die Geschmäcker auch in der einschlägigen Fachliteratur gehen auseinander.

💡 Ich würde dieses Fragen (Strukturvariante Zielhierarchie, Zuordnung sozialer Ziele, Zuordnung sonstiger Rahmbedingungen) immer davon abhängig machen, welche Struktur der Auftraggeber bevorzugt und welche Einzelziele ihm so wichtig sind, dass sie unbedingt in der Zielhierarchie Eingang finden sollten. Wenn bestimmte Einzelziele nicht so entscheidend sind, aber trotzdem in den Projektauftrag Eingang finden sollen, stehen ja noch immer die Anlagen zur Verfügung, in denen z.B. auch die SMARTen Zielkriterien und Abnahmenkriterien Eingang finden, die dann von beauftragten Fachspezialisten des Auftraggebers überprüft werden, aber die nicht mit ihm persönlich auf Ebene der Zielhierarchie besprochen werden müssen.

  • Es liegt auf der Hand, dass bei einer Strukturierung der Zielhierarchie in Ergebnis- und Vorgehensziele die Terminziele und Kostenziele zu den Vorgehenszielen gehören. Sie haben eher den Charakter von Rahmenbedingungen und können Gegensatz zu den Ergebniszielen nicht abgenommen werden:
    • Bei Terminüberschreitung erhält man als Projektleiter ggf. eine negative Bewertung, aber man kann eine vorübergehende Abnahme mit der Auflage einer Nachbesserung ja nicht dadurch zu einer endgültigen Abnahme machen, in dem man sich in eine Zeitmaschine setzt und dieses Mal schneller arbeitet.
    • Ähnliches gilt bei den Kostenzielen. Kein Kunde wird die Abnahme bei einem perfekten Produkt, das sämtliche Abnahmekriterien erfüllt, verweigern. Bei einem Werkvertrag mit Fixpreis ist das ohnehin aus seiner Sicht kein Problem, weil er in aller Regel nur den vereinbarten Fixpreis bezahlen wird. Bei einer Abwicklung nach Time and Material wird in der Regel nachbudgetiert, aber eine “Heilung” bei zu viel verwendeten Budget ist auch hier nicht durch das Projektteam nicht möglich. Es sei denn, alle legen zusammen und zahlen die Differenz aus dem privaten Geldbeutel;-).

💡 Grundsätzlicher Hinweis für die einzelnen Methoden: Projektleitungen sollten die meisten Planungselemente im Projektmanagement mit eindeutigen IDs kennzeichnen (Beispiel “L1” für Leistungsziel 1). Das ermöglicht den sauberen Transfer in Folgeanalysen und Maßnahmen. Inkonsistenzen und Verwechslungen können so deutlich reduziert werden.

Priorisierung auf Ebene der Zielklassifizierung

Zunächst sollten Ziele auf Ebene der Zielklassifizierungen (Leistung, Kosten und Termine) durch eine Nummerierung eindeutig priorisiert werden.

Priorisierungsbeispiel Investitionsprojekt: Der Produktionsstart ist an einen festen Kundentermin gekoppelt. Jede Verzögerung hätte direkte Auswirkungen auf Lieferzusagen und Umsatz. Die Halle muss daher pünktlich fertiggestellt werden – zur Not mit reduzierter technischer Ausstattung oder provisorischen Lösungen. Beispielhafte Konsequenz in der Projektabwicklung:

  • Wenn sich die Lieferung spezieller Maschinen verzögert, wird zunächst mit Standardanlagen gestartet. Nachrüstungen erfolgen später.
  • Das Projektteam darf eigenständig Entscheidungen treffen, die den Termin sichern – auch wenn dies Mehrkosten bedeutet.

Sonderfall soziale Ziele: Verzicht auf Priorisierung auf Ebene der Zielklassifizierung: Soziale Ziele sind eine vergleichsweise heterogene Zielklassifizierung. Es wäre aus meiner Sicht methodisch wenig sinnvoll, alle „sozialen Ziele“ einfach zum Beispiel mit der „Prio 4“ pauschal zu behandeln.

Unter sozialen Zielen werden die unterschiedlichsten Ziele vermischt wie Teamziele (Motivation, Überstundenvermeidung, Kompetenzentwicklung), Stakeholder-Zufriedenheit (Auftraggeber, Anwender, Öffentlichkeit), Reputationsziele, Nachhaltigkeit / gesellschaftliche Wirkung, Organisationsentwicklung. Diese Gruppen haben keine gemeinsame Prioritätslogik, sondern völlig unterschiedliche Relevanz für Projektleitung und Auftraggeber.

Priorisierung auf Ebene der Einzelziele

Zusätzlich zur Priorisierung auf Ebene der Zielklassifizierung ist es empfehlenswert, die einzelne Ziele innerhalb einer Klassifizierung als Muss, Soll oder Kann markiert.

  • Muss-Ziele sind erfolgskritisch. Wird eines nicht erreicht, gilt das Projekt als gescheitert.
  • Soll-Ziele beeinflussen die Zufriedenheit wichtiger Stakeholder deutlich. Werden sie nicht erreicht, sinkt die Zufriedenheit dieser Stakeholder deutlich.
  • Kann-Ziele sind optional und haben keinen negativen Effekt bei Nichterreichung.

Die Priorisierung über dieses Schema ist auf Ebene der Einzelziele empfehlenswert und meines Erachtens besser geeignet als eine Nummerierung:

  • Ein Ranking aller Einzelziele von 1 bis z.B. 15 wäre sicher “pseudopräzise”
  • Ein Ranking aller Einzelziele innerhalb einer Zielklasse wäre ggf. auch ein pragmatischer Ansatz:
    • Bei vielen Einzelzielen innerhalb einer Zielklasse läuft man aber meiner Meinung nach in das Problem der Pseudopräzision.
    • Für viele Stakeholder ist die oben beschriebene Definition der Muss-, Soll- und Kannziele gut greifbar und recht eindeutig. Sie hat nur zur Konsequenz, dass man sich bei zwei Sollzielen zusätzliche Gedanken machen muss, welches Ziel eine höhere Priorität hat (siehe Kapitel Umgang mit Zielkonflikten). Das sind unter Umständen gar nicht so viele Ziele und in der Gesamtbilanz weniger aufwändig, also jedes Einzelziel in ein eindeutiges Ranking zu bringen.

Letztlich ist die Art und Weise der Priorisierung ein auch Geschmacksache. Entscheidend ist, dass in einem Projekt die Prioritäten besprochen werden.

💡 Wenn die Leistungsziele als möglichst unabhängige Lieferobjekte formuliert werden, fällt die Priorisierung oft leichter bzw. wird erst ermöglicht. So wäre es z.B. nicht sinnvoll, eine bestimmte Funktionalität als Kannziel zu kategorisieren, wenn sie technische Voraussetzung für ein Mussziel ist. Das ist im obigen Beispiel sicher nicht der Fall: Auf das PMO-Konzept als Kannziel kann sicher verzichtet werden, ohne dass sich das negativ auf das PM-Handbuch als Mussziel negativ auswirken würde.

Mit einem Big Picture zusätzliche Klarheit in die Auftragsklärung bringen

Ein Big Picture ist die kompakte visuelle Darstellung des Projekts in Form eines Bildes und sinnvoller verbaler Erläuterungen. Ein gutes Big Picture enthält dabei eine sinnvolle gut verständliche Mischung aus aussagekräftigen Zeichnungen / Bildern und verbaler Erläuterung.

  • Es stellt Ziel, Nutzen, Projektgegenstand und strategische Einbettung übersichtlich dar und zeigt zentrale Schnittstellen sowie Rahmenbedingungen. Typischerweise enthält es auch eine klare Abgrenzung von In-Scope- und Out-of-Scope-Themen.
  • Es sollte einfach und verständlich sein, um als gute Diskussionsgrundlage zu dienen.
  • Nur Bilder und nur Text stellen kein Big Picture dar. Es muss eine Mischung aus Bildern und Text sein.
  • Bei Projekten mit eher abstrakten Lieferobjekten ist die Visualisierung etwas schwieriger als bei Projekten mit physischen Lieferobjekten – aber trotzdem gut möglich.
  • Grundsätzlich und erst recht in einer Workshopsituation muss kein optisches Meisterwerk abgeliefert werden. Es dient der gemeinsamen Orientierung und verhindert Detaildiskussionen ohne Gesamtbezug.

💡 Ich habe gute Erfahrungen damit gemacht, bei der Auftragsklärung das Big Picture neben die Zielhierarchie zu hängen.

Mit SMARTer Zielbeschreibung die Voraussetzung für die Zielfunktionen schaffen und ggf. mit MVP-Idee arbeiten

Die Überführung vager Ziele in konkrete Handlungsziele heißt Operationalisierung.

Einzelziele sind zu Beginn der Auftragsklärung oft nur vage beschrieben. Im Verlauf der Auftragsklärung sollte die Projektleitung im eigenen Interesse diese vagen Ziele in konkrete Handlungsziele überführen, also Kriterien für die Erreichung der Projektziele mit dem Auftraggeber verhandeln. Im Rahmen dieser Verhandlung bzw. Auftragsklärung wird genau beschrieben, was genau erreicht werden soll und woran sich der Erfolg zeigt. Ein Ziel wird dadurch handhabbar für Planung, Steuerung und Kontrolle, es wird “operationalisiert”, konkret und überprüfbar. Nur mit einer Operationalisierung kommen die vielen Vorteile von Projektzielen (siehe Zielfunktionen) zum Tragen. Das Team weiß zum Beispiel, worauf es hinarbeitet, und kann fachliche Entscheidungen sicherer treffen. Konkrete Ziele schaffen Orientierung im Alltag und erlauben am Projektende eine faire Bewertung des Ergebnisses. Vage Absichten wie „Verbesserung der Zusammenarbeit“ helfen dagegen kaum im Projektalltag.

Operationalisierung bedeutet nicht zwangsläufig Zahlen festzulegen. Eine Quantifizierung hilft jedoch, weil sie Vergleiche erleichtert und Diskussionen verkürzt. In Organisationsprojekten nutzt die Projektleitung oft Indikatoren, etwa klare Zustände oder beobachtbare Veränderungen, statt harter Kennzahlen.

Die SMART-Formel unterstützt als Akronym die Operationalisierung von Zielen als Denkhilfe. Sie zwingt dazu, Ziele aus verschiedenen Blickwinkeln zu prüfen, ohne sie künstlich zu verkomplizieren.

Spezifisch heißt verständlich und eindeutig, sodass keine Auslegungsspielräume bleiben. Das “S” steht in der Zieltabelle sowohl für Messkriterium als auch das Ausmaß. Messbar heißt überprüfbar, etwa durch Zahlen, Termine oder klar beschriebene Zustände. Das “M” steht in der Zieltabelle nur für das Ausmaß. Akzeptiert heißt, dass das Team die Ziele als fair empfindet, z.B. weil Kriterien und Maßstab klar sind. Das “A” bezieht sich auf das WOLLEN. Haben die Teammitglieder das Ziel verinnerlicht? Identifizieren sie sich damit? Ohne Akzeptanz droht Dienst nach Vorschrift. Erfahrungsgemäß steigt die Akzeptanz des Teams automatisch schon dann, wenn die Projektziele spezifisch und messbar formuliert sind. Realistisch heißt, dass Fähigkeiten, Kapazitäten und Rahmenbedingungen zusammenpassen und dennoch fordern. Das “R” bezieht sich also auf das KÖNNEN. Beispiel für eine Abgrenzung von “A” zu “R”: Ein Vertriebsleiter setzt das Ziel: “Wir steigern den Umsatz im nächsten Quartal um 30 % durch 100 zusätzliche Kaltakquise-Anrufe pro Mitarbeiter und Woche.” Es ist Realistisch (R): Der Markt gibt das Potenzial her, die Telefone funktionieren und die Mitarbeiter haben theoretisch die Arbeitszeit dafür. Das Ziel wird aber NICHT Akzeptiert (A): Das Team hasst Kaltakquise, fühlt sich vom Chef überrumpelt und empfindet die Vorgabe als unfairen Druck. Hier fehlt also die Akzeptanz, das Ziel sabotiert oder verfehlt. Terminierbar heißt, dass ein Zeitpunkt festgelegt ist, häufig zur Abnahme oder zu Meilensteinen. In der frühen Phase der Auftragsklärung spreche ich lieber von “terminierbar”, weil die grobe Terminplanung bzw. Phasenplanung ggf. zum Zeitpunkt der Auftragsklärung noch nicht vorliegt. Bei einer Top-Down-Vorgabe des Terminziels durch den Auftraggeber wäre das natürlich etwas anderes.

⚠️ Die SMART-Kriterien nur dienen als Gedankenstütze, besonders zu Beginn der Auftragsklärung. Die SMART-Formel sollte also nicht, wie man es manchmal beobachten kann, explizit in der Zieltabelle dargestellt, um jeden einzelnen Bestandteil abzuhaken.

⚠️ Bitte nicht jedes Einzelziel vollständig nach allen SMART-Kriterien zu formulieren. Das ist oft weder möglich noch nötig. Alle Projektziele sollten nur in ihrer Gesamtheit SMART sein.

Je nach Interessenslage des Auftraggebers kann sich der Projektleiter dazu entschließen, Leistungsziele direkt in der Zielhierarchie oder nur als Teil der Zielkriterien darzustellen. Siehe Vertiefung

Ein Teil der SMARTen Zieldefinition fließt in die Abnahmekriterien: Das sind die zwischen Auftraggeber und Auftragnehmer vereinbarten Kriterien, die erfüllt sein müssen, damit das Projekt abgenommen wird. Die SMARTen Zielkriterien beantworten in erster Linie die Frage, ob das Produkt richtig - also entsprechend der Spezifikation - gebaut worden ist (Verifizierung). Schwerpunkt der Abnahme ist in vielen Fällen die Validierung, welche die Frage beantwortet, ob das richtige Produkt gebaut worden. Ob also das Produkt in seinen wesentlichen Funktionen in einer ganz konkreten Anwendungssituation von einem typischen Vertreter der Endanwender genutzt werden kann.

Sind die Abnahmekriterien erfüllt, kann die Abnahme erfolgen. In einer gängigen Definition liegt eine Abnahme als unternehmerische Entscheidung vor, dass ein Ergebnis nach der Abnahmeprüfung den Vereinbarungen entspricht.

💡 Die Abnahmekriterien sollten - genau wie das Abnahmeverfahren - vertraglich hinterlegt werden, um bei der eigentlichen Abnahme Ärger zu vermeiden.

Freigabe: Von der Abnahme ist die Freigabe zu unterscheiden, mit welcher die zuständige Stelle der Organisation die Einsatz des abgenommenen Produkts genehmigt. Die Freigabe wird dabei nicht unbedingt vom Auftraggeber vorgenommen. Ebenso muss nicht das gesamte Produkt auf einen Schlag freigegeben werden, um zum Beispiel den Fachbereich nicht zu überfordern.

Ein Minimal Viable Product (MVP) ist im planbasierten Projektumfeld (z. B. Organisationsentwicklung, Prozess- oder IT-Einführung) das minimale Set an Ergebnissen/Zielen, ohne die das Projektziel nicht als erreicht gilt. Ohne diese Eigenschaften stellt das Produkt für den Kunden keinen Wert dar und ist nicht nutzbar.

Das MVP legt also offen, was ein Projekt mindestens liefern muss. Diese Mindestmenge an Ergebnissen schafft Nutzen und verhindert Stillstand des Betriebs. Es geht um funktionale Existenzbedingungen für den Projekterfolg und nicht um Markttests.

Insofern ist es aus meiner Sicht sicher kein Fehler, den MVP im klassischen Projektumfeld über Mussziele und ausgewählten Kriterien abzubilden, die man dann als Musskriterien bezeichnet. Beispiel: Ein Team führt ein neues HR-System ein und stellt sicher, dass Gehaltsabrechnungen pünktlich laufen. Alles andere kann warten.

Mit der Zielbeziehungsmatrix riskante Zielbeziehungen (konkurrierend, widersprechend) finden

Eine Zielbeziehungsmatrix zeigt Zielkonflikte. Die Projektleitung erkennt durch einen paarweisen Vergleich aller Ziele systematisch, wo Ziele sich behindern.

Zielkonkurrenz bedeutet, dass die Verfolgung eines Ziels ein anderes Ziel schwächt. Die Projektleitung möchte beide Ziele erreichen. Im Projektalltag muss sie jedoch oft Abstriche machen. Sie sollte deshalb rechtzeitig klären, bei welchem Ziel sie weniger ambitioniert vorgeht und warum.

Priorisierung legt Vorräte an Entscheidungen. Die Projektleitung trifft also eine Entscheidung, bevor der Konflikt eskaliert. Das beschleunigt später schwierige Gespräche und reduziert emotional geführte Diskussionen. Beispiel: Ein Unternehmen möchte möglichst viele Sonderfunktionen aus einem Alt-System in ein neues SAP-System übernehmen. Gleichzeitig wünscht es ein wartungsarmes System, das günstige und schnelle Updates erlaubt. Die Übernahme vieler Sonderlösungen erschwert aber Updates deutlich. Hier hilft eine Priorisierung, sonst verzetteln sich Teams in endlosen Diskussionen

⚠️ Teams priorisieren oft nur offensichtliche Zielkonflikte zwischen Leistung, Kosten und Terminen. Sie übersehen dabei mögliche Zielkonkurrenzen zwischen Leistungszielen. Gerade dort steckt oft das größere Risiko.

Widersprechende Ziele bedeutet, dass man nur entweder das eine oder das andere Ziel anstreben kann, weil sich bei Ziele ausschließen.

Widersprechende Ziele stellen ein Risiko im Projekt dar, wenn keine klare Entscheidung gefällt wird. Beispiel: Ein wichtiger Stakeholder aus dem Fachbereich möchte im Projekt zur Einführung von Projektmanagement die bisher übliche “Doppelspitze” aus Fachprojektleitung und IT-Projektleitung abschaffen und die Gesamtverantwortung immer dem Fachbereich geben. Ein anderer wichtiger Stakeholder (IT-Bereichsleiter) möchte das auf keinen Fall. Dahinter steckt die noch offen ausgesprochene Angst vor dem Verlust von Einfluss. Bei sich widersprechenden Zielen sollte sich der Auftraggeber klar entscheiden, welches Ziel er verfolgen möchte. Meine Empfehlung ist, solche Widersprüche nicht zu ignorieren, sie lösen sich in der Regel nicht von selbst auf.

Neutrale Ziele: Die Erreichung eines Ziels hat keine Auswirkung auf die Erreichung eines anderen Ziels.

Leider betrifft das erfahrungsgemäß die wenigsten Zielbeziehungen, was ja eine Zielbeziehungsmatrix oft erforderlich macht. Trotzdem ist es aus meiner Sicht sinnvoll, auch die neutralen Ziele einzutragen, weil man sich um diese Zielbeziehungen nicht weiter kümmern muss.

Identische Zielbeziehungen: Wenn man in der Zielbeziehungsmatrix bemerkt, dass man in der Zielhierarchie zwei unterschiedlich formulierte Ziele hinterlegt hat, die aber inhaltlich identisch sind, muss man solche Ziele zusammenführen bzw. eines der beiden wegen Redundanz streichen.

Komplementäre Zielbeziehungen: Die Erreichung eines Ziels wirkt sich positiv auf die Erreichung eines anderen Ziels aus.

Z.B. dürfte sich das Ziel “Entwicklung eines schadstoffarmen Motors” gleichzeitig positiv auf die Erreichung eines weiteren Ziels “Reduzierung des CO2-Ausstoßes auswirken”. Man sollte als Projektleitung diese beiden Ziele entweder zu einem großen neuen Ziel zusammenführen oder die Zielhierarchie erweitern und sie unter einem gemeinsamen übergeordneten Ziel einordnen.

Bei der Priorisierung von zwei konfliktären Einzelzielen auf derselben Ebene (Muss, Soll und Kann) hilft eine Einzelanalyse

Zwei konfliktäre Ziele können gleich wichtig wirken. Die Projektleitung sollte in solchen Fällen mit dem Auftraggeber klären, welches Ziel im Zweifel vorgeht und die beiden Ziele in ein klares Ranking bringen (Zielkonkurrenz) oder sich für ein Ziel klar entscheiden (widersprechende Ziele). Das schafft Orientierung und senkt Entscheidungszeit im Alltag.

Eine kurze Einzelanalyse wie in der obigen Tabelle hilft bei der Abstimmung mit dem Auftraggeber. Die Projektleitung sollte sich dabei auf konkurrierende oder widersprechende Ziele beschränken. Niemand gewinnt, wenn jede mögliche Zielpaarung mühsam verglichen wird. Die zuvor genannte Zielbeziehungsmatrix bringt Ordnung in das Zielgefüge und zeigt die kritischen Paare schnell auf.

Auch konfliktäre Mussziele sollten in die Analyse integriert werden:

  • Auch zwei Mussziele können sich widersprechen, was beim ersten Brainstorming ggf. noch nicht aufgefallen war. Erst die Einzelanalyse deckt so einen Widerspruch auf und erleichtert den Entscheidungsweg.
  • Auch wenn kein Widerspruch vorliegt sondern “nur” Konkurrenz ist es aus meiner Sicht sinnvoll, die entsprechenden Mussziele in ein Ranking zu bringen. Es erleichtert zumindest die Frage, welches Mussziel im Zweifel noch stärker verfolgt wird. Das ist aus meiner Sicht auch kein Widerspruch zu der Grundaussage, dass beide Ziele grundsätzlich erreicht werden müssen, damit das Projekt nicht gescheitert ist.
  • Natürlich müssen nicht alle Mussziele automatisch in diese Einzelanalyse einbezogen werden. Wenn die Mussziele neutral oder komplementär sind, kann man wie gesagt auf solche Einzelbetrachtungen verzichten.

💡 Pragmatischer Lösungsansatz: Ich würde die Detailanalyse mit Begründung nur bei Zielen derselben Einzelpriorität (Muss, Soll oder Kann) und einer konfliktären Zielbeziehung (konkurrierend oder widersprechend). Wenn es z.B. einen Zielkonflikt zwischen einem Sollziel und einem Kannziel gibt, ist der Zielkonflikt durch die vorgenommene Priorisierung bereits gelöst. Natürlich kann man auch auf dem Standpunkt stehen, zuerst alle konfliktären Ziele einer Einzelanalyse in der Tabelle zu unterziehen und erst danach die Priorisierung der Ziele für die Zieltabelle abzuleiten. Aber das wäre eben kein pragmatischer Aufwand und aus meiner Sicht unverhältnismäßig.

Grundkenntnisse im Anforderungsmanagement zahlen sich für die Projektleitung meist aus

Die Unterscheidung von “Zielen” und “Anforderungen” ist nicht einfach:

  • Beide werden als Bedingung oder Fähigkeit bezeichnet, die zur Lösung eines Problems benötigt wird.
  • Beide müssen beide in Summe SMART beschrieben werden.

Unterscheidungsversuch – basierend auf verschiedenen Literaturquellen:

  • Ziele sind besonders „charakteristische“ Bedingungen oder Fähigkeiten
  • Ziele werden in Zielhierarchien eher kurz und knapp dargestellt
  • Anforderungen konkretisieren die Ziele und werden häufig viel umfangreicher und bei IT-Anforderungen oft nach einer bestimmten Syntax dargestellt. Sie zählen zu den wichtigsten Inhalten eines klassischen und umfangreichen Lastenheftes

Zwischen einer ausführlichen Zielformulierung und einer knappen Anforderung werden auch erfahrene Projektmanager kaum exakt unterscheiden können.

Ziele: Vertiefung

Zwischenziele und Zwischenabnahmen

Meilensteine in einem Phasenplan können zwar als Zwischenziele auf dem Weg zu den Projektzielen beschrieben werden, die am Ende vorliegen müssen. Wenn diese Zwischenziele aber keine eigenständigen Lieferobjekte darstellen, die vorab zur Nutzung für die Anwender abgenommen werden, sollten sie aus meiner Sicht nicht in die Zielhierarchie für die Diskussion mit dem Auftraggeber aufgenommen werden. Diese Art “Zwischenziele” werden ja bereits im Phasenplan hinterlegt, der meist ebenfalls mit dem Auftraggeber besprochen wird. Beispiel für ein solches Zwischenziel: “Testkonzept abgeschlossen”. Die Aufzählung dieser Zwischenziele in zwei verschiedenen Methoden (Zielhierarchie und Phasenplan) würde meiner Meinung nach für unnötige Redundanz führen und birgt damit unnötiges Potenzial von Missverständnissen. Anders verhält es sich bei echten Teilabnahmen, die oft bei teuren Investitionsprojekten anzutreffen sind. Beispiel: “Zwischenabnahme Tiefgarage” (Der Auftraggeber nutzt sie bereits als Bausstellenparkplatz). Oder “Zwischenabnahme Erdgeschoss” (Einzelhändler zieht ein und eröffnet)

💡 Zwischenabnahmen oder Teilabnahmen werden oft bei teuren Investitionsprojekten für Zahlungsmeilensteine verabredet. Man sollte nur prüfen, ob die unterschiedlichen Gewährleistungsfristen der abgenommenen Teilergebnisse effizient verwaltet werden können. Hier sollte immer Rücksprache mit der Rechtsabteilung geführt werden.

Leistungsziele in Zielhierarchie oder in den Zielkriterien

Die Benennung von Leistungszielen entweder in der Zielhierarchie oder erst in den Zielkriterien von den folgenden Aspekten ab:

  • Projektinhalt: Bei einem sehr umfangreichen Projektinhalt muss man sich in der Diskussion der Zielhierarchie automatisch beschränken und sich auf das Wesentliche konzentrieren. Je größer also das Projekt, desto mehr Details werden in die Tabelle mit den Messkriterien (oder in entsprechende Lasten- und Pflichtenhefte) geschoben, welche dann oft von zuständigen Fachspezialisten mit der Projektleitung besprochen werden.
  • Interessenslager des Auftraggebers:
    • Beispiel 1: Wenn ich vermute, dass z.B. die “Einführung von Projektmanagement-Software” eher ein Sollziel oder sogar ein Kannziel sein könnte, aber gleichzeitig viel Kosten verursacht, sollte ich es für die Diskussion in der Zielhierarchie aufführen. So kann vermieden werden, dass später der Auftraggeber in irgendeiner Präsentation lange nach Projektstart fragt, warum für diesen unwichtigen Projektinhalt “PM-Software” ein so hoher Anteil des Projektbudgets ausgegeben wird. *Es versteht sich von selbst, dass solche - für den Auftraggeber wahrscheinlich wichtigen - Leistungsziele dann auch als eigene Kostenziele aufgeführt werden, sofern der Anteil am Budget sehr hoch ist.
    • Beispiel 2:
      • Dem einen Auftraggeber mag “einfaches PM-Handbuch” in der Zielhierarchie genügen. Den Rest überlässt er der Detaildiskussion des Projektleiters mit dem Fachbereichs. Zur Umsetzung des noch schwammigen Begriffs “einfach” würden dann Projektleitung und Fachbereich zum Beispiel “Begehbarkeit im Intranet mit maximal 2 Klicks” festlegen und in der Tabelle mit den Zielkriterien eintragen.
      • Dem anderen Auftraggeber ist diese Begehbarkeit im Intranet vielleicht ein persönliches Anliegen, was er mit dem Projektleiter selbst besprechen möchte. Dann würde ich als Projektleiter dieses Details als eigenes Leistungsziele auf dem Level der Zielhierarchie darstellen.
  • Bereitschaft des Auftraggebers, und dem Ausmaß, mit dem er sich in Details der Auftragsklärung einbringen möchte. Das hängt von Motivation und Art der Führung ab:
    • Es gibt Auftraggeber, die unterschiedlich stark für ein Projekt brennen. Die einen müssen vielleicht ein aus ihrer Sicht uninteressantes Projekt übernehmen und wollen deshalb so wenig wie möglich mit dem Projekt zu tun haben.
    • Es gibt Auftraggeber, die ihrem Fachbereich vertrauen und viel delegieren und deshalb nur die große Linie mit der Projektleitung besprechen wollen. Andere Auftraggeber, die - aus welchem Grund auch immer - eher zum Mikromanagement neigen, mischen nach meiner Erfahrung sehr gerne und ausführlich bei der Diskussion um noch so kleine Fachthemen mit.

Verbindung Zielhierarchie mit Unternehmenszielen

Die Unternehmensziele würden dann an der Spitze der Zielhierarchie stehen, darunter kämen zum Beispiel die Nutzenziele gemäß dem Business Case des Projekts und dann erst die konkreten Projektziele, die für den Abwicklungserfolg durch die Projektleitung erreicht werden sollen. Für das Projektmarketing kann das von Vorteil sein, weil man zum Beispiel zurückhaltenden Führungskräften auf einen Blick die Vorteile des Projekts verdeutlichen kann. Allerdings sollte man über eine entsprechende Formatierung optisch die Verantwortungsbereich von Anwendungs- und Abwicklungserfolg voneinander abgrenzen.

💡 Wichtige Nutzenziele können in das Oberziel integriert werden. Bei vielen Stakehoderdiskussionen ist eine schnelle Visualisierung nützlich, warum sich das Projekt für das Unternehmen lohnt. Sicherheitshalber sollten die Nutzenziel dann in kursiv bzw. in einer anderen Formatierung dargestellt werden, weil die Projektleitung klassisch nicht für den Anwendungserfolg des Projekts verantwortlich ist. Das sollte auch visuell deutlich gemacht werden.