Ein kleiner Beitrag zum Thema Consulting
Immer wieder stellen wir fest, dass viele unserer Kunden vergleichbare Hürden bei der Umsetzung von Technologieprojekten haben: Dazu zählen insbesondere nur grob bekannte Funktionalitäten, bereits vor der Planungsphase feststehende Fertigstellungstermine und damit verbunden ein augenscheinlich unerlässlicher sofortiger Start der Programmiertätigkeiten.
Die folgende Geschichte projiziert wahre Gegebenheiten aus unterschiedlichen Kunden-Kontexten und Branchen auf unsere fiktive Beispielfirma „W(irklich) N(ur) E(in) Platzhalter GmbH", in diesem Fall ein mittelständiges Maschinenbauunternehmen mit Sitz in Deutschland.
Und wir nehmen nicht zu viel von der Story vorweg, wenn wir jetzt schon so viel verraten: Der Dienstleister in dieser Geschichte ist kein Zauberkünstler. Er hält sich nur an drei Regeln:
Egal, wie groß der Druck ist, gehe methodisch und strukturiert vor.
Nutze dabei so viel Methodik wie nötig und so wenig wie möglich.
Akzeptiere niemals das Argument „Dafür ist keine Zeit!", wenn dadurch das Risiko unkalkulierbar wird.
Nimm dir Zeit, wenn`s schnell gehen muss.
Sag nicht einfach „Ja und Amen", sondern priorisiere und behalte stets dein Ziel im Blick.
Die Investition in einen Workshop mit allen Stakeholdern kann ein ganzes Jahr retten.
Nachvollziehbare Aufwandsschätzungen und die Priorisierung anhand von echten Bedürfnissen anstatt von Wünschen öffnen Augen (und Tore und Budgets).
Gemeinsam mehr erreichen.
Verlasse bekannte Denkmuster und biete gewinnbringende Lösungsalternativen an.
Beziehe alle Beteiligten mit ein.
Jeder macht das, was er am besten kann – (externe) Profis sind nicht umsonst Spezialisten auf ihrem Gebiet.
Die Ausgangssituation – wirklich nur ein Platzhalter oder Real Life?
Das Vertriebsteam der WNE Platzhalter GmbH hat in der Verkaufsverhandlung die Auslieferung der Maschine mit einer neuen Software zugesagt, um den anvisierten Preis beim Kunden durchsetzen zu können. Nun herrscht wie so oft Zeitdruck, denn der Auslieferungstermin naht, doch die Entwicklung der Software hinkt hinterher. Darüber ist natürlich niemand besonders glücklich, denn
- Die Geschäftsführung braucht den Umsatz, um ihr Jahresziel zu erreichen.
- Der Vertrieb benötigt den Auftrag als Referenz für weitere offene Verkaufschancen und möchte die neue Software auf der bevorstehenden Messe bewerben und vertreiben.
- Das Produktmanagement sieht in der neuen Software die Chance, endlich alle sinnvollen Anforderungen für die Zukunft unterzubringen, der Zeitplan dafür ist aber nun wohl zu knapp.
- Die Entwicklungsabteilung ist mit dem operativen Geschäft bereits zu 110 % ausgelastet und kann kein weiteres Projekt gebrauchen.
- Fertigung und Montage stehen unter Druck, da für die Entwicklung der Software bereits fertige Anlagenteile benötigt werden, die im Zeitplan kaum beizubringen sind.
- Na, finden Sie sich schon wieder?!
Und so nehmen die Dinge ihren Lauf – oder: Chaos vorprogrammiert
Aus der Not heraus entscheidet man sich für die Einstellung eines neuen Software-Entwicklers, der dieses Projekt übernehmen soll. In Zeiten des Fachkräftemangels dauert dieser Prozess drei Monate – drei wichtige Monate, die dem Projekt nun fehlen und den Druck nochmals erhöhen. Über einen Headhunter gelingt es schließlich, einen technischen Experten anzuheuern – für immense Gehaltsvorstellungen inklusive Ablösung beim vorherigen Arbeitgeber.
Der Entwickler V. Ollprofi macht sich selbstbewusst an die Arbeit und programmiert fleißig Stunde um Stunde. 10-Stunden-Tage und Wochenendarbeit sind keine Seltenheit. Acht Wochen vor Auslieferung der Maschine ist die Software fertig und wird aufgespielt. Stolz auf seine Arbeit lädt Ollprofi die gesamte Mannschaft ein, um seine neue Software zu präsentieren. Leider muss er feststellen, dass die Verbindung zur Maschine nicht hergestellt werden kann. Die Schnittstelle an der SPS ist nicht kompatibel mit seinem Maschinen-Interface. „Das haben die Automatisierer wieder verrissen, es war doch klar, dass die Schnittstelle so aussehen muss", denkt sich Ollprofi. Durch einen mit groben Worten und schlechter Laune gespickten „Rettungseinsatz“ schafft man es zumindest soweit, dass Ollprofi die neue Benutzeroberfläche präsentieren kann.
Doch die Präsentation läuft anders als geplant. „Das ich mir irgendwie anders vorgestellt", ist der meist gehörte Kommentar. Funktionalitäten fehlen, sind schwer zu finden oder liefern nicht erwartungskonforme Ergebnisse. Der Geschäftsführer N. I. Meinerhaut bricht die Präsentation schließlich erbost ab. Er muss nun dem Kunden erklären, dass die versprochene Software nicht Teil der Auslieferung sein wird. Der Kunde nimmt die Maschine trotzdem, fordert Schadenersatz und gibt der WNE ein weiteres Jahr Zeit, die Software zu liefern.
Jetzt ist externe Hilfe gefragt
Ollprofi hat nach dem niederschmetternden Feedback und den darauffolgenden Schuldzuweisungsspielen die Nase voll und kündigt. Nach hitzigen Debatten, wie es nun weitergehen könne, bringt der Entwicklungsleiter I. Ertrinkeinarbeit einen externen Dienstleister ins Spiel. Bisher hat man zwar keine guten Erfahrungen mit Externen gemacht, aber aufgrund der aktuellen Situation sieht niemand eine Alternative.
Nach einem ersten Vorgespräch unterbreitet der Dienstleister ein Angebot. Meinerhaut und Ertrinkeinarbeit schauen nur kurz auf die Stundensätze und stoßen dann unmittelbar die Beauftragung an, schließlich gilt es keine Zeit zu verlieren. Umso verblüffter sind sie, dass sich der Dienstleister gerade jetzt Zeit nehmen will – um aus Fehlern zu lernen und die Entwicklung der Software diesmal systematisch anzugehen. Und das stehe und falle nun mal mit der Erhebung von Anforderungen, mahnt der Dienstleister.
Anforderungen definieren: Was brauche ich wirklich?
Man einigt sich auf einen Anforderungs-Workshop. Auf seine Frage, wer von den einzelnen Abteilungen teilnehmen werde, speist man den Dienstleister ab: „Sprechen Sie mit Herrn E. Wigimunternehmen, der kann Ihnen alle Anforderungen mitteilen." Die Forderung nach einem Teilnehmer pro Abteilung führt zwar zunächst zu Debatten à la „Für so etwas haben wir keine Zeit!“ und „Die Leute kriegt man nicht alle unter einen Hut", doch der Dienstleister kann sich letztendlich durchsetzen.
Schnell stellt sich heraus, dass der Ansatz gar nicht so akademisch ist wie gedacht und sehr unterschiedliche Sichtweisen auf die neue Software herrschen. Alle Anforderungen werden methodisch gesammelt und die Teilnehmer sind positiv überrascht, wie viele „neue" Anforderungen in der kurzen Zeit zutage gefördert werden und vor allem, „an wie viel man noch nie gedacht hat". Eine Priorisierung scheint kaum möglich, denn alle Teilnehmer sind sich einig, dass ALLE Anforderungen wichtig sind und für den Kunden benötigt werden.
Doch die Aufwandsschätzung des Dienstleisters ergibt, dass diese Anforderungen noch nicht einmal mit einem 100-Personen-Team in einem Jahr umgesetzt werden könnten. Die Geschäftsführung schaltet sich ein und prüft den Vertrag mit dem Kunden. Dabei wird sehr schnell klar, dass viele der Anforderungen zwar „nice to have“ für den Kunden wären, jedoch keine vertragliche Grundlage dafür existiert. Daher konzentriert sich die Priorisierung der Anforderungen nun zunächst auf die vertraglichen Pflichten, doch der verbleibende Aufwand ist nach wie vor zu hoch für den knappen Zeitraum. Der Dienstleister schlägt vor, den Endkunden in die Priorisierung mit einzubeziehen. Dieser ist glücklich, mitreden zu können („Das hatten wir bisher noch bei keinem Maschinenbauer!") und zeigt sich bei der Priorisierung milde. Das erste Release ist nun abgesteckt.
Zukunftsfähige Software-Architektur und Usability nicht vergessen
Parallel zu den Verhandlungen macht sich der Dienstleister Gedanken zur Software-Architektur, die so aufgebaut sein sollte, dass sie alle Anforderungen technisch unterstützt. So ist es auch in Zukunft möglich, Erweiterungen vorzunehmen, ohne das ganze Konzept wieder über den Haufen werfen zu müssen. Um dem Endkunden die Bedienung der zahlreichen Funktionalitäten zu erleichtern, entscheidet die WNE, eine Usability-Engineering-Phase in der Entwicklung mit einzuplanen. Hierbei wird der Aufbau der Bedienführung gemeinsam mit den Anwendern beim Endkunden zunächst anhand von groben Entwürfen überprüft. Diese Mock-Ups werden so lange verfeinert, bis eine optimale, soll heißen möglichst intuitive Bedienung erreicht ist.
Happy End
Die so wichtigen Vorarbeiten sind jetzt getan – eine entscheidende Grundlage für das Happy End des Projektes. Die Entwicklung der eigentlichen Software startet nun – an der engen Zusammenarbeit hält man aber weiterhin fest: Alle vier Wochen treffen sich der Dienstleister und die WNE zum Iterationsreview. Hierbei werden Teilergebnisse getestet, begutachtet und entschieden, ob das Projekt in die richtige Richtung geht. Auch der Endkunde wird regelmäßig an den Zwischenständen beteiligt.
Der Endkunde erhält zum vertragsmäßig vereinbarten Zieltermin sein erstes Release. Glücklich darüber, so tief in die Entwicklung eingebunden worden zu sein, sagt er sogar zu, als Referenz zu dienen und den „Knacks im Projekt" dabei nicht zu erwähnen. Anstelle der ursprünglichen Schadensersatzforderungen willigt er ein, weitere Funktionalitäten aus dem Product Backlog (also noch nicht umgesetzte Anforderungen) kostenfrei zu erhalten.
Und die Moral von der Geschicht'?
Wer seine Anforderungen kennt, der sich nicht im Chaos verrennt.
Zu guter Letzt noch eine gute Nachricht: Lernen Sie aus den Fehlern der wahrscheinlich gar nicht mal so fiktiven Beispielgeschichte.
Ein Anruf genügt, wir beraten Sie gerne!
