Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.


14.11.2008

So erkennen Sie, wie es wirklich um Ihr Projekt steht

Norbert Hanke
Es gibt bewährte Checklisten und Strukturierungsmethoden, um Risiken und Chancen eines Projekts zu überblicken. Aber sie verraten nur die halbe Wahrheit.

Versteckte Untiefen auszuloten, eine "Second Agenda" aufzuspüren oder das latente Wissen um die wirkliche Projektsituation abzufragen ist für Außenstehende schwierig. Mit standardisierten Methoden lässt sich diese Aufgabe nicht lösen.

Ungleich hilfreicher sind sieben - zum Teil verblüffend einfache und leicht umsetzbare - Ideen, mit deren Hilfe sich jedes Projekt ad hoc bewerten lässt.

1) Fassen Sie Anliegen und Inhalt des Projekts auf einer Seite zusammen.

Durch einen solchen kurzen Text sollte sich ein Außenstehender, aber nicht völlig Fachfremder (vulgo: "sachverständiger Dritter") gut informiert fühlen. Dabei können drei Phänomene auftreten:

  • Die Beschreibung fällt deutlich kürzer aus als eine Seite. In diesem Fall haben Sie das Projekt offenbar nicht ganz verstanden. Zudem stellt sich die Frage, ob die Form eines eigenen Projekts überhaupt notwendig ist. Denn wenn sich ein Sachverhalt so schlicht erklären lässt, wäre er ja eventuell auch innerhalb der vorhandenen Strukturen zu bewältigen.

  • Die Beschreibung fällt deutlich länger aus als eine Seite. Auch dann hapert es meist am Verständnis für das Projekt. Ansonsten ließe sich von dessen Komplexität angemessen abstrahieren. Oder aber das Anliegen ist wirklich so komplex, dass es innerhalb eines Projekts kaum strukturierbar ist. In diesem Fall wäre zu fragen, ob es nicht in unterschiedliche Projekte oder Releases aufgespalten werden sollte.

  • Die Beschreibung passt mehr oder weniger genau auf eine Seite. Gut so!

2) Skizzieren Sie die wichtigen Elemente der Projektorganisation auf einer Seite.

Kommen Sie hier mit deutlich weniger als einer DIN-A4-Seite aus, haben Sie entweder die Projektorganisation nicht verstanden, oder es gibt einen erheblichen Anteil an informellen Strukturen, oder aber die Projektorganisation ist unzureichend, beispielsweise weil die Führungsspanne zu groß ist.

Passt das Organigramm hingegen nicht auf eine Seite und entspricht die umfangreiche Skizze wirklich der Realität, so handelt es sich um eine ziemlich komplexe Struktur. Hier besteht die Gefahr, dass Projektmitarbeiter in ihnen nicht unmittelbar einsichtigen Strukturen arbeiten müssen. Beispielsweise sollten Berichts- und Eskalationsstrukturen allen Projektbeteiligten gegenwärtig sein, ohne dass sie dafür dicke Dokumentationen wälzen müssen.

3) Nennen Sie fünf Möglichkeiten, das Projekt todsicher scheitern zu lassen.

Doch, doch, solche Risiken gibt es immer und jederzeit. Suchen Sie so lange, bis Sie fünf davon gefunden haben. Ziehen Sie dann die detaillierten Projektunterlagen zurate. Sind dort alle selbst gefundenen Risiken genannt und mit Gegenmaßnahmen belegt, so ist das ein beruhigendes Indiz für ein (real oder latent) existierendes Risiko-Management.

10projects.de

Nutzen Sie die Vorteile der Community-Plattform 10projects.de und stellen Sie Ihre Projekte dort ein.

So geht es:

  • Anmeldeformular unter www.10projects.de ausfüllen;

  • persönliches Profil mit Kontaktdaten und Foto (optional) anlegen;

  • in die Rubrik "Projekte" Informationen über Ablauf und Zielerreichung Ihres IT-Vorhabens einstellen;

  • entscheiden, ob Sie Ihr Projekt einem definierten Kreis präsentieren oder öffentlich machen wollen.

Das bringt es:

  • ständigen Erfahrungsaustausch unter IT-Profis;

  • erhöhte Sichtbarkeit in der Branche, vor allem bei IT-Entscheidern;

  • potenzielle Unterstützung in kritischen Projektphasen;

  • Personal-Recruitment der anderen Art.

Haben Sie mehr Risiken gefunden als die Projektleitung, so teilen Sie es ihr mit. Auf diese Weise wird sie nicht nur schlauer, sondern bekommt auch einen Anstoß, sich mit dem Risiko-Management auseinanderzusetzen. Selbstverständlich ist anschließend der Umgang mit den Risiken zu verfolgen. Werden Sie nur benannt und beplant oder auch durch geeignete Maßnahmen wirksam bekämpft?

4) Beschreiben Sie alles, was dazu führt, dass der Auftraggeber zufrieden ist.

Das Erreichen der Projektziele ist nicht das einzige Kriterium für den Erfolg. Beispielsweise könnte das Projekt ja einen Beitrag zu einem größeren und längerfristigen Plan leisten, und wenn sich dieses übergeordnete Vorhaben ändert, wird auch das Projekt anders gewichtet. Dann wären die Projekt-Stakeholder vielleicht enttäuscht, obwohl die Ziele objektiv erreicht sind. Wer ein Häuschen im Grünen baut, kann es noch so hübsch einrichten; er wird unzufrieden sein, wenn später die Einflugschneise des Flughafens genau dorthin verlegt wird.

Zudem können sich die Erfolgskriterien während einer längeren Projektlaufzeit verändern. Es ist also nützlich, die Liste der Kriterien regelmäßig zu überarbeiten - erst recht bei Veränderungen von Strukturen, Personen oder Rahmenbedingungen.

Erstellen Sie eine Liste der Ergebnisse, die laut Planung bereits vorliegen müssten.

So lässt sich der tatsächlich erreichte Stand mit den Erwartungen vergleichen. Wenn sich eine Diskrepanz ergibt, ist das - für sich allein genommen - nicht automatisch schlecht. Die Bewertung hängt ab vom erbrachten Nutzen, vom benötigten Aufwand, von den Erwartungen der Projektbeteiligten etc. Zunächst sollten die Schätz- und Planungsprämissen noch einmal genauer angesehen werden. Darüber hinaus stellen sich folgende Fragen:

  • Welche Ursachen werden für das Zurückbleiben hinter den Erwartungen genannt? Und wie hat das Projekt darauf regiert?

  • Mussten Ergebnisse erarbeitet werden, die sich erst später als notwendig erwiesen haben, aber in der Planung übersehen wurden?

  • Trafen Zulieferungen verspätet ein, oder waren sie unzureichend?

  • Gab es Entscheidungsdefizite?

Analog dazu ist es nicht per se als gut zu bewerten, wenn die Ergebnisse mit der Projektplanung übereinstimmen. Vor allem, wenn es sich um ein sehr komplexes Vorhaben handelt, muss man sich folgende Fragen stellen:

  • Warum wurden die Ergebnisse planmäßig erreicht? War die Planung etwa zu komfortabel?

  • Oder wurde die Berichterstattung sprachlich kreativ gestaltet?

  • Mit welchen Nachteilen (zum Beispiel Qualitätseinbußen oder Auslassen wesentlicher Schritte) wurde die Planerfüllung erkauft? Wirken sich diese Unterlassungen später nachteilig aus?

  • Oder profitierte das Projekt von positiven Seiteneffekten anderer Bereiche? Und könnten diese Effekte auch Nachteile an anderer Stelle mit sich bringen?

6) Befreien Sie die Statusberichte von sinnfreien Formatierungselementen.

Entfernen Sie Hintergründe, Farbverläufe und aufpeppende Grafikelemente, setzen Sie alle Texte im selben Font. Und dann drucken Sie das Ergebnis auf einem Schwarzweißdrucker aus. Ist es noch einigermaßen nachvollziehbar, dann haben sich die Autoren zumindest um formale Verständlichkeit bemüht. Aber oft stellen sich die Berichte ohne ihre Formatierungen als heilloses Chaos dar - auch wenn man bei der Entfernung die größtmögliche Sorgfalt und Geschicklichkeit walten ließ. Dann muss sich der Verfasser den Verdacht einer gewollt intransparenten Berichterstattung gefallen lassen.

Um den Inhalt zu prüfen, hilft im zweiten Schritt ein wenig Textanalyse weiter:

  • Ohne Verben ist eine Darstellung von Zusammenhängen und Begründungen nicht möglich.

  • Stress und Unsicherheit bei der Berichterstellung führen zu unvollständigen und unverständlichen Formulierungen.

  • Vergebliche Eskalationsversuche oder Desinteresse bei der Berichterstellung schlagen sich in identischen Formulierungen in aufeinanderfolgenden Berichten nieder.

  • Als Arbeitsinstrument eignet sich ein Statusbericht nur, wenn er Redaktionszeitpunkt, Verantwortlichkeiten und Autoren nennt sowie eine einheitliche und angemessene Gliederung aufweist.

  • Übermäßige Substantivierung ("Beamtendeutsch") kann eine gewisse Distanz zum Inhalt andeuten, inhaltsarmes Wortgeklingel ("Beratersprech") auf Hilflosigkeit hinweisen; aufwändige Satzkonstruktionen zeigen an, dass jemandem die sprachliche Form wichtiger war als der Inhalt.

7) Nennen Sie zu jedem Satz des Statusberichts mindestens einen Beleg.

In vielen Statusberichten gibt es Behauptungen, die nicht belegt werden. Manchmal werden Belege für diese Sätze angeführt, aber niemand versteht sie - vielleicht deshalb, weil Unverständlichkeit Absicht war. Dabei ist es doch ganz einfach:

  • Wird die teilweise Fertigstellung eines Konzepts gemeldet (gern genommen wird hier die Formulierung: "zu 80 Prozent"), so müssten sich eigentlich bereits Fragmente des Dokuments vorweisen lassen.

  • Sind Unzulänglichkeiten beim Staffing das Thema, so sollte ein Personalprofil vorzeigbar sein - und jemand, der sein ernsthaftes Bemühen um geeignetes Personal beschreiben kann.

  • Die Zufriedenheit hinsichtlich der vorliegenden Ergebnisse lässt sich mit den dokumentierten Ergebnissen einer ersten Zufriedenheitsstudie belegen.

  • Heißt es wiederholt, das Projekt befinde sich "im Plan", so liegt dieser Aussage gewiss eine ausreichend detaillierte Planung zugrunde, an der sich die Ergebnisse messen lassen.

  • Eine Klage über Entscheidungsdefizite ist leichter nachvollziehbar, wenn die Eskalationsmöglichkeiten nachweislich ausgeschöpft wurden.

Ja, und dann gibt es auch noch den ganz trivialen Normalfall: dass das Projektteam einfach nur einen guten Job macht. (qua)