Ein Punkt, der mir beim aufsetzen der Seite wichtig war, ist die Selbstreflektion und Review auf meinen eigenen Projektalltag (dies natürlich ohne Personen oder Firmen zu nennen).

Ein wichtiger Punkt dabei ist, aus Fehlern zu lernen – die so genannten “Lessons Learned“.

Erwartungshaltung im Projekt

Die Symptome

Das Projekt mit dem Kunden ist klar, die Anforderungen und der Umfang (Lieferungen der Software, Dokumentation etc.) sind soweit bekannt und das Projektteam arbeitet eine Spezifikation mit dem Kunden aus. Das Team stellt die erste Version der Spezifikation (in Word mit Tabellen, Grafiken und Screenshots) fertig und übergibt es dem Kunden zum Review.

Ergebnis: Kunde ist überrascht über den Inhalt und hat mit etwas anderem gerechnet

Ein weiteres Beispiel: Das Team arbeitet vor sich hin und entwickelt nach der Spezifikation die Funktionen aus, ein anderes Team arbeitet bereits an der Dokumentation. Nach einem Monat wird der erste Teil der Software sowie der Dokumentation geliefert.

Ergebnis: Auch hier klafft die Erwartungshaltung an das Ergebnis mit dem gelieferten auseinander.

In beiden Fällen ist der Kunde “enttäuscht” oder überrascht und erzeugt auf beiden Seiten Ernüchterung und Mehraufwand, im schlimmsten Fall sogar Verzug im Projektplan!

Die Ursache

Ist ganz klar! Der Mensch!

Die ist nicht mal negativ zu bewerten, sondern es liegt in der Natur des Menschen, dass die Erwartungshaltung oder Wertesystem von Person zu Person unterschiedlich ist. Selbst bei Projekten im Deutschsprachigen Raum, gar wenn es nur in einem Bundesland ist, führt zwangsläufig zu diversen Wertesystemen.

Auf Grund des heutigen demografischen Wandels sind wir mit Diversität (siehe auch Diversity Management) im Unternehmen und in Projekt konfrontiert. Dies führt angesichts der Unterschiede in Kultur, Religion, Alter und Soziales Umfeld zu verschiedenen Wertesystemen und in Folge Dessen zu verschiedenen Meinungen, Einschätzungen und Ergebnissen!

Die Lösung

Sicherlich keine Ultimative Lösung für alle Probleme, jedoch sollte man im Vorfeld eines Projektes sicherstellen, dass man zwischen den Projektteams (Auftraggeber und -nehmer) ein einheitliches Verständnis für die Ergebnisse erzielt. Im Vorfeld sollte klar sein, wie das Projekt gehandhabt wird und was in welcher Form geliefert wird.

Speziell wenn es um Themen wie

• Spezifikation
• Projektberichte
• Dokumentation
• Lieferung

geht, sollte man im Vorfeld ein klares “commitment” erzielen und festhalten.

Dem Kunden und Auftragnehmer sollte klar sein, wie die Dokumente in Form und Inhalt geliefert werden und wie die Kommunikation stattfindet (Zeitlich, Form etc.).

Wenn es um die Umsetzung von Softwareprojekten geht, dann sollte man im Rahmen der Entwicklung bereits in frühen Phasen bereits abgeschlossene Funktionialitäten dem Kunden präsentieren und nicht erst nach Abschluss des Releases. Hier hat sich der Termin vor Ort beim Kunden bewährt um das geleistete direkt im Testsystem oder Prototypen zu zeigen. Alternativ kann man für sowas auch Webkonferenztools nutzen wie WebEx oder GoToMeeting (beides Kostenpflichtig). Im OpenSource Bereich hat sich Mikogo bewährt.

Mit diesen Mitteln lässt sich eine Online-Konferenz planen und durchführen und das System über Screensharing präsentieren. Vor allem nützlich, wenn der Weg zum Kunden weiter ist und Kosten sparen möchte.

Fazit

Mit einer klaren Kommunikation und Klärung der Erwartungshaltung und damit Schaffung einer einheitlichen Sicht lassen sich viele Probleme, Stress und Kosten mindern.