Jedes Projekt kann irgendwann an einen Punkt kommen, an der die Probleme unüberwindlich erscheinen. Die notwendigen Ressourcen fehlen, ein Lieferant hält sich nicht an zugesagte Termine, der wichtigste Mitarbeiter wird aus dem Team abgezogen, die nachträglichen Änderungswünsche des Auftraggebers bringen die Planung durcheinander. Womöglich stellt sich plötzlich noch heraus, dass manche Dinge aus technischen Gründen nicht so machbar sind wie man sich das bei der Planung gedacht hatte.
In solchen Situationen kann es passieren, dass Projektleiter und Team sich frustriert darüber auslassen, was sich alles quer stellt, wer Schuld daran ist, wieso die Probleme nicht zu meistern sind und so weiter. Es bringt jetzt aber nichts, nach Ursachen und Schuldigen zu suchen. Die Lage ist, wie sie ist. Man muss daraus das Beste machen.
Einem jungen Team wurde ein Auftrag zur Entwicklung eines Software-Systems erteilt. Der Auftraggeber wollte sich damit am Gesundheitsmarkt etablieren. Neben der persönlichen Betreuung chronisch Kranker sollte im Rahmen eines Forschungsprojekts untersucht werden, ob eine derartige Betreuung nachweislich die Gesundheit positiv beeinflusst. Wenn ja, wäre dies ein neuer Ansatz für die Kostensenkung im Gesundheitswesen.
Für das neue Unternehmen war dieser Auftrag eine gute Gelegenheit, sich zu profilieren. Sollte der Kunde mit seinem Konzept am Markt erfolgreich sein, hofften sie auf weitere Nachfrage nach ähnlichen Systemen.
Nun passierte leider im Projekt alles auf einmal: Das System, auf dem die Anwendung hergestellt wurde, funktionierte nicht wie gewünscht. Ein externes Teammitglied verließ unter unglücklichen Bedingungen das Team und hinterließ Module, die nicht verwertbar waren. Außerdem stellte sich heraus, dass bestimmte Testdaten nicht stimmten.
Wenn Ihr Projekt ins Schlingern oder zum Stillstand kommt, dann fragen Sie zunächst: "Was brauchen wir, damit die Arbeit weitergehen kann?" Mit dieser ersten Frage wird das Problem sachlich beleuchtet. Das führte zu einer Bestandsaufnahme des Problems. Die jungen Entwickler machten einen Plan, was sie sich so schnell wie möglich besorgen mussten: neue Daten, zwei neue Mitarbeiter und mehr Informationen vom Auftraggeber.
Gehen Sie dann mit der Frage "Wieso ist es nicht so, wie es sein müsste?" den Ursachen auf den Grund. Hier wurde lediglich erst einmal festgehalten, was eventuell für spätere Regressansprüche sinnvoll wäre. Bei anderen Projekten könnte man hier auch Ideen sammeln, wie man dem eigenen Management gegenüber Verzögerungen verargumentiert.
Diese ersten beiden Fragen provozieren vielleicht bitteres Beklagen über andere Menschen oder widrige Umstände. Das mag emotional tröstlich sein, hilft aber letztlich nicht weiter.
Entscheidend ist die dritte Frage: "Was können wir tun, damit die Arbeit weitergeht?"
Bei dieser Frage ging es unserer Gruppe um zwei Themen:
