Viele Software-Projekte scheitern. Viele Software-Projekte verlaufen zäh. Maßgeblichen Anteil an diesem Scheitern trägt fehlende Kommunikation.
"Das war mir nicht klar" heißt es dann. Oder anders herum: "Der kommt mit seinen Sachen immer so spät um die Ecke." Was kann das Team machen, um diese Kommunikationslücken zu stopfen?

Nach Wikipedia [Link] ist ein Projekt
"ein Satz von abgestimmten, gelenkten Tätigkeiten mit Anfangs- und Endtermin besteht und durchgeführt wird, um unter Berücksichtigung von Zwängen bezüglich Zeit, Ressourcen [...] und Qualität ein Ziel zu erreichen."
Viele Tätigkeiten in Unternehmen heißen zwar Projekte, entsprechen aber nicht der obigen Definition. Die Projekte werden nach der SWBLM-Methode ("So wie beim letzten Mal-Methode") durchgeführt. Wenn das Projektvorgehen SWBLM unterliegt, wird das eigentliche Vorgehen nicht reflektiert: "Wir machen das so wie immer - das können wir".
Aber auch die Zusammensetzung des Teams selbst wird mit SWBLM nicht hinterfragt. Es finden sich dann Personen, die sich für das Thema zuständig fühlen oder für das Thema abgeordnet werden. Der eigene Beitrag und die eigene Rolle bleiben aber bei dieser ungefähren Zuordnung im Unklaren.
Findet nun die Auseinandersetzung über das Projektziel mit dem Auftraggeber oder der Auftraggeberin nur schriftlich - im schlimmsten Fall nur über das schriftliche Angebot statt, ist das Scheitern vorprogrammiert. Und selbst diese Abstimmung unterliegt häufig SWBLM. "Das haben wir doch schon so mal ähnlich für XYZ gemacht - können wir nicht einfach das Angebot kopieren?"
In allen Bereichen, die für das Projekt entscheidend sind, nämlich:
- Projektziel
- Projektvorgehen
- Projektparameter
- Projektteam
hat keine oder eine nicht ausreichende Kommunikation stattgefunden. Diese Nicht-Definitionen werden dem Team im Laufe "des Projekts" auf die Füße fallen. Doch es ist gerade dies alles - während des Aufsetzens des Projekts - zu definieren und zu klären:
- Welche Projektmethode nutzt das Team?
- Wie misst das Team den Projekterfolg?
- Wie sichert das Team den Projekterfolg dauerhaft ab?
Um den Projekterfolg dauerhaft abzusichern, muss ein Team verstehen, welche betriebswirtschaftlichen Ziele mit dem Projekt erreicht werden sollen. Dann kann das Team den eigenen Beitrag zu diesem Ziel ermitteln und abstimmen:
- Wie lange wird das Projektergebnis voraussichtlich betrieben werden?
- Wie häufig werden Änderungen am System vorgenommen werden?
- Ist eine hohe Anpassungs- und Veränderungsrate für den Geschäftserfolg des Projektergebnisses essentiell?
Diese Fragen bestimmen maßgeblich das Maß der Testabdeckung und das Testvorgehen im Projekt selbst. Um dieses passgenau zu konzipieren, muss das Team mit den Auftraggebern und Auftraggeberinnen ins Gespräch kommen. Dieses Gespräch ist direkt und persönlich zu führen. Ein Verschieben dieser Anforderungen ins Schriftliche ist der erste Schritt ins Scheitern. Schriftlich formulierte Anforderungen neigen dazu, zu klein oder zu groß zu werden.
Direkte, mündliche Kommunikation sollte schriftlich dokumentiert werden. Aus dieser Dokumentation heraus werden die Parameter für ein dem Projektziel angemessene, testgestützte Entwicklung abgeleitet. Aber auch dieses Ergebnis ist mit dem Auftraggeber oder der Auftraggeberin abzustimmen - direkt & persönlich. Um das Ergebnis für beide Seiten nachvollziehbar zu präsentieren, sollte das Team die Vor- und Nachteile des gewählten Verfahrens in Risiken umrechnen. Sind diese allen Beteiligten klar -- und haben sich alle Beteiligten offen für den entsprechenden Weg ausgesprochen -- können alle Beteiligten auch gut und sicher mit diesen Risiken umgehen. Und so das Projekt zum Erfolg führen.
CrossPosting des Blogs "Hanser Update" | Dieser Artikel ist als flankierende Maßnahme zur Veröffentlichung des Buches ""Software-Qualität in PHP-Projekten", 2. Auflage entstanden.
- Nächster Artikel: Liebeserklärung an Marina
- Vorheriger Artikel: Ankündigung: Froscon 8 | Vortrag + Workshop
Kommentar schreiben