Die Vorprojektphase: herausfinden, was Sie wirklich brauchen

Wenn Sie mit uns sprechen, gibt es meistens einen konkreten Anlass. Eine Standardlösung deckt nicht ab, was Sie tatsächlich tun. Ein über Jahre gewachsenes System trägt nicht mehr. Oder ein wichtiger Prozess läuft über Tabellen, Mailverteiler und Zuruf und funktioniert nur so lange, wie die richtigen Kolleginnen und Kollegen im Haus sind.

In allen drei Fällen wäre es verlockend, sofort mit der Entwicklung zu beginnen. Dieser Weg sieht kürzer aus. Er ist es selten. Vor jedem Projekt steht bei uns die Vorprojektphase — der Abschnitt, in dem wir gemeinsam mit Ihnen herausfinden, was Sie wirklich brauchen und ob es sich in Ihrer bestehenden Systemlandschaft tragfähig umsetzen lässt. Und in dem Sie uns kennenlernen, bevor Sie sich für uns entscheiden.

Nicht jedes Vorhaben ist von Anfang an ein Projekt. Wenn Sie noch nicht wissen, ob Ihre Idee trägt, beginnen wir mit einem Anforderungssteckbrief: den Leitplanken Ihres Vorhabens, kurz und ohne Details. Er kostet Sie wenig Zeit und gibt Ihnen etwas in die Hand, worüber Sie im Haus entscheiden können.

Wird daraus ein Vorhaben, arbeiten wir den Steckbrief zum Fachkonzept aus. Sie müssen also nicht tief investieren, um zu erfahren, ob sich die Investition lohnt.

Wir beginnen mit der Aufnahme des Ist-Zustands. Dafür sprechen wir mit den Menschen, die den Prozess täglich ausführen — nicht nur mit denen, die ihn beschreiben können. Wir sehen uns an, was tatsächlich passiert, und werten aus, was an Dokumenten und Systemen bereits vorhanden ist.

Für uns gilt dabei eine einfache Regel: fragen, zuhören, wiederholen. Erst wenn wir Ihren Prozess in eigenen Worten zurückgeben können und Sie zustimmen, haben wir ihn verstanden.

Gerade in größeren Organisationen macht das einen Unterschied. Dort kennt häufig niemand den Prozess von Anfang bis Ende — jede Abteilung kennt ihren Abschnitt. Ein wesentlicher Teil unserer Arbeit besteht darin, diese Abschnitte zu einem durchgehenden Bild zusammenzusetzen. Für viele unserer Kunden ist dieses Bild schon für sich genommen ein Ergebnis, unabhängig von der Software, die danach entsteht.

Wir halten den Ist-Zustand überwiegend in natürlicher Sprache fest und ergänzen ihn um Prozessmodelle in BPMN. Modelle nicht, weil sie gut aussehen, sondern weil sie Lücken sichtbar machen, die in einem Fließtext untergehen. Wenn ein Pfeil ins Leere zeigt, sieht das jeder im Raum sofort.

Wir erheben dabei in einer festen Reihenfolge: erst den Normalfall, dann die Korrekturpfade, zuletzt die Ausnahmen. Das hat einen praktischen Grund. Die meisten Prozesse laufen im Normalfall reibungslos — Zeit und Geld kosten die Ausnahmen. Und genau die werden im Gespräch zuerst vergessen.

Aus dem Ist-Zustand leiten wir ab, wo Verbesserungspotenzial liegt. Wir sehen dabei auf zwei Ebenen.

Auf die einzelnen Arbeitsschritte. Wir unterscheiden, welche Schritte unmittelbar Nutzen für Ihre Kunden schaffen, welche notwendig sind, um diesen Nutzen zu erbringen, und welche schlicht Aufwand ohne Wirkung sind. Die letzte Gruppe entfällt. Der Rest wird verbessert — durch Automatisierung oder Teilautomatisierung, durch Zusammenlegung von Schritten, durch Parallelisierung dessen, was nicht nacheinander laufen muss, in einzelnen Fällen durch Auslagerung.

Auf die Übergänge. Die teuersten Stellen liegen selten in einem Arbeitsschritt, sondern zwischen zweien: Daten, die mehrfach erfasst werden, weil zwei Systeme nichts voneinander wissen. Informationen, die von Hand aus einem System in ein anderes übertragen werden. Hier prüfen wir, ob eine einheitliche Datenbasis, geeignete Schnittstellen oder die Verbindung bisher getrennter Anwendungen der bessere Weg ist.

Dabei hilft uns, dass sich vieles wiederholt. Wir entwickeln seit 1998 Software, für Unternehmen sehr unterschiedlicher Größe und Branche, und bestimmte Muster kehren immer wieder — Testinhalt (wiederkehrende Themen folgen). Diese Muster müssen wir nicht jedes Mal neu verstehen. Das gibt uns den Kopf frei für das, was bei Ihnen anders ist — und genau diese Abweichung ist ja der Grund, warum Sie Individualsoftware brauchen und kein Produkt von der Stange.

Auf dieser Grundlage entwerfen wir gemeinsam mit Ihnen den Soll-Zustand. Gemeinsam ist dabei nicht als Höflichkeit gemeint: Ein Soll-Prozess, den Ihre Leute nicht mitgetragen haben, wird später umgangen — und keine Software der Welt gleicht das aus.

Nicht jedes Problem verlangt eine eigene Software. Wenn die Analyse zeigt, dass eine Standardlösung Ihre Anforderungen abdeckt oder dass eine Änderung am Prozess genügt, sagen wir Ihnen das — auch wenn wir damit den Auftrag verlieren, über den wir gerade sprechen.

Der Grund ist nüchtern: Eine Individualsoftware, die es nicht gebraucht hätte, kostet Sie nicht nur in der Entwicklung. Sie kostet Sie über ihre gesamte Lebensdauer — in Wartung, in Weiterentwicklung und in der Abhängigkeit von demjenigen, der sie gebaut hat. Diese Rechnung machen wir lieber vorher gemeinsam auf als hinterher.

Aus dem Soll-Zustand werden Anforderungen. Wir arbeiten dabei nach den Standards des IREB, des International Requirements Engineering Board. Das bedeutet konkret:

Wir grenzen zuerst ab, worüber wir eigentlich sprechen — was zum künftigen System gehört, was zu seinem Umfeld, und an welchen Stellen beides sich berührt. Diese Grenze früh zu ziehen, erspart später die teuersten Diskussionen.

Wir unterscheiden funktionale Anforderungen — was das System können muss —, Qualitätsanforderungen — wie gut es das können muss — und Randbedingungen, die Ihnen von außen gesetzt sind. Und wir beschreiben Ihr System aus drei Blickwinkeln: seinen Daten und deren Struktur, seinen Abläufen und Funktionen sowie seinen Zuständen und deren Verhalten. Erst alle drei zusammen ergeben ein vollständiges Bild.

Anschließend priorisieren wir. Nicht alles ist gleich wichtig: Manches wird schlicht erwartet und fällt nur auf, wenn es fehlt. Manches ist umso besser, je mehr davon vorhanden ist. Und manches erwartet niemand — begeistert aber, wenn es da ist. Diese Unterscheidung entscheidet darüber, was in den ersten Ausbaustufen entsteht und was warten kann.

Eine gute fachliche Beschreibung nützt wenig, wenn sich die Lösung in Ihrer Umgebung nicht sauber umsetzen lässt. Deshalb arbeiten wir in der Vorprojektphase nicht nur fachlich, sondern auch technisch.

Die Architektur entsteht nicht erst im Projekt. Wir entwerfen sie so, dass sie zu dem passt, was bei Ihnen bereits läuft. Ihre Systemlandschaft ist über Jahre gewachsen — es gibt bestehende Fachanwendungen, Schnittstellen, Vorgaben aus Betrieb und Sicherheit. Eine Anwendung, die für sich genommen elegant ist, aber neben Ihrer Landschaft steht statt in ihr, erzeugt genau die Brüche, die wir eigentlich beseitigen wollten.

Wir planen für den Alltag, nicht für den Start. Zur Architektur gehört die Frage, was die Anwendung im laufenden Betrieb aushalten muss: wie viele Menschen gleichzeitig damit arbeiten, wie viele Vorgänge sie täglich verarbeitet und wie sich beides in den kommenden Jahren entwickeln wird. Diese Zahlen klären wir früh, weil sie über die Architektur entscheiden — und weil sie sich nachträglich nur teuer korrigieren lassen.

Wir wissen meistens schon, ob es geht. Wir entwickeln seit 1998 Software. Der praktische Wert daraus ist nicht die Jahreszahl, sondern das Urteil dahinter: Vieles, worüber anderswo spekuliert wird, haben wir in ähnlicher Form bereits gebaut. Wir sagen Ihnen deshalb früh, wenn eine Idee in Ihrer Umgebung nicht tragen wird — statt Sie das im vierten Projektmonat herausfinden zu lassen.

Und wo wir es nicht wissen, bauen wir es vorab. Wenn ein Vorhaben an einer Stelle technisch anspruchsvoll ist oder auf einer Annahme ruht, die vieles andere trägt, erstellen wir einen Proof of Concept: einen technischen Durchstich innerhalb der vorgesehenen Architektur. Es geht dabei nicht um Oberflächen, sondern allein um die Frage, ob der kritische Teil technisch trägt. Sie bekommen damit vor der Beauftragung Gewissheit statt einer Einschätzung. Einen Proof of Concept beauftragen Sie gesondert — wir sagen Ihnen vorher, warum wir ihn für nötig halten und was er kostet.

Wie weit wir technisch gehen, richtet sich nach Ihrem Vorhaben. Bei einer überschaubaren Anwendung genügt ein Architekturentwurf. Bei einem Vorhaben, das mehrere Systeme berührt oder unter Last laufen muss, investieren wir hier deutlich mehr — und sagen Ihnen, warum.

Am Ende der Vorprojektphase erhalten Sie ein Fachkonzept. Es ist überwiegend in natürlicher Sprache geschrieben, damit Ihr Fachbereich es lesen kann, und um Grafiken und BPMN-Diagramme dort ergänzt, wo ein Bild schneller trägt als ein Absatz.

Der Architekturentwurf ist Teil davon — Sie bekommen also keine getrennten Dokumente für Fachlichkeit und Technik, sondern ein Bild.

Das Fachkonzept beschreibt Ihr Vorhaben bewusst noch nicht bis ins letzte Detail. Es geht in die Breite, nicht in die Tiefe. Die Feinheiten — einzelne Masken, fachliche Entitäten, konkrete Schnittstellen — klären wir im Projekt, wenn wir sie brauchen. Alles andere wäre Aufwand für Papier, das sich unterwegs ohnehin ändert.

Wozu es dient: Das Fachkonzept ist — zusammen mit dem, was wir technisch geklärt haben — unsere Grundlage für die Kosten- und Terminschätzung und damit für Ihr Angebot.

In der Regel vereinbaren wir dabei einen Festpreis — keine Spanne und keinen Schätzwert, der später nachjustiert wird. Das können wir, weil wir seit 1998 Vorhaben dieser Art kalkulieren und wissen, was die einzelnen Bausteine kosten. Und der Preis gilt, solange sich der Umfang nicht ändert. Ändert er sich, erfahren Sie vorher, was das bedeutet — statt es am Ende auf der Rechnung zu finden.

Und wenn wir technisches Neuland betreten, schätzen wir nicht ins Blaue. Dann nehmen wir uns so lange Zeit, bis wir belastbar rechnen können — im Zweifel mit einem Proof of Concept. Lieber nennen wir Ihnen eine Woche später eine Zahl, auf die Sie sich verlassen können.

Wie umfangreich die Vorprojektphase ausfällt, hängt von der Größe Ihres Vorhabens ab, von der Zahl der beteiligten Fachbereiche und davon, wie viel bei Ihnen bereits dokumentiert ist. Wir schätzen das nach dem ersten Gespräch ein und sagen es Ihnen, bevor wir anfangen. Bei größeren Vorhaben wird die Vorprojektphase beauftragt, bei kleineren ist sie Teil des Projekts.

Die Entwicklung von Individualsoftware ist zu einem großen Teil Vertrauenssache. Sie geben ein Vorhaben in fremde Hände, das über Monate läuft und Ihre Arbeitsabläufe verändert. Diese Entscheidung sollte niemand auf Basis einer Präsentation treffen müssen.

Deshalb ist die Vorprojektphase bei uns bewusst auch eine Probe der Zusammenarbeit. Sie erleben, wie wir zuhören, wie wir nachfragen, wie wir mit Widersprüchen umgehen und ob wir Termine halten — bevor Sie das eigentliche Projekt beauftragen.

Und wenn Sie danach zu dem Schluss kommen, dass es nicht passt, ist das in Ordnung. Das Fachkonzept gehört Ihnen. Sie dürfen darüber verfügen und es ausdrücklich auch nutzen, um damit an andere Anbieter heranzutreten. Das ist keine Absichtserklärung: Die Nutzungsrechte halten wir im Angebot fest, das Sie vor der Beauftragung erhalten.

Wir räumen Ihnen dieses Recht ein, weil ein Ergebnis, das Sie nur bei uns verwenden können, kein Ergebnis ist, sondern eine Bindung.

Zur selben Frage gehört noch ein zweiter Punkt, den viele Interessenten denken, aber selten aussprechen. Wer Individualsoftware beauftragt, bindet sich enger an seinen Anbieter als beim Kauf eines Standardprodukts: Wartung und Weiterentwicklung bleiben über Jahre bei dem, der die Anwendung gebaut hat. Es ist deshalb berechtigt, vorher zu fragen, ob es diesen Anbieter dann noch gibt.

Wir entwickeln seit 1998 Software und betreuen die Anwendungen, die wir gebaut haben, im laufenden Betrieb weiter.

Ein Punkt, den wir lieber vorher ansprechen als später: Ohne Ihre Mitwirkung geht es nicht. Wir brauchen Ihre Teilnahme an Workshops, Antworten auf fachliche Rückfragen und später Ihre Beteiligung an den Tests. Das ist keine Formalie, sondern der Unterschied zwischen einer Software, die zu Ihnen passt, und einer, die an Ihnen vorbei entwickelt wurde.

Wir wissen auch, wie schwer das im Alltag ist. In den meisten Projekten kommt die Projektarbeit zur regulären Arbeit hinzu, ohne dass an anderer Stelle etwas wegfällt. Dann gewinnt der Alltag — nicht aus Unwillen, sondern weil er dringender ist. Hinzu kommt, dass mehrtägige Workshops und konzentriertes Arbeiten über längere Zeiträume für viele Fachkolleginnen und -kollegen ungewohnt sind.

Deshalb machen wir den Aufwand früh sichtbar. Wir beschreiben die Rollen im Projekt schriftlich — wer wofür verantwortlich ist, wer entscheidet, wofür eine Rolle ausdrücklich nicht zuständig ist, und wie viel Zeit sie tatsächlich braucht. Diese Beschreibung stimmen wir mit Ihrer Geschäftsführung ab.

Das ist manchmal ein unbequemes Gespräch. Es ist aber deutlich angenehmer als dasselbe Gespräch im vierten Projektmonat, wenn nichts vorangeht und niemand mehr weiß, warum.

Wir arbeiten sequenziell in festen Phasen oder agil in Releases und Sprints. Was zu Ihrem Vorhaben passt, hängt vor allem von zwei Dingen ab.

Von der Größe. Je kleiner und überschaubarer eine Anwendung ist, desto eher ist ein sequenzielles Phasenmodell der ruhigere Weg. Je größer sie ist, desto mehr spricht für ein agiles Vorgehen — über eine lange Laufzeit ändern sich ohnehin Dinge, und ein Plan, der das nicht vorsieht, wird zum Problem statt zur Hilfe.

Vom Abstraktionsgrad der Anforderungen. Lässt sich bereits in der Vorprojektphase beschreiben, was genau entstehen soll, kann sequenziell geplant werden. Bleiben die Anforderungen dagegen abstrakt — weil sich manches erst am laufenden System zeigt —, ist ein agiles Vorgehen ehrlicher als ein Plan, der nur aussieht wie einer.

Darin liegt allerdings eine Spannung, die wir offen ansprechen: Gerade wenn die Anforderungen noch unklar sind, verlangt das agile Vorgehen am meisten von Ihnen — verfügbare Fachleute, zügige Entscheidungen, regelmäßiges Testen von Zwischenständen. Wo diese Voraussetzungen nicht gegeben sind, führt Agilität nicht zu mehr Tempo, sondern zu Leerlauf auf beiden Seiten.

Wir sagen Ihnen deshalb vorher, was jedes der beiden Vorgehen von Ihnen verlangt, und empfehlen Ihnen eines. Die Entscheidung treffen Sie.

Zum Abschluss der Vorprojektphase entsteht ein weiteres Dokument, an dem wir während der gesamten Phase mitschreiben: die Project Canvas. Sie fasst auf einer Seite zusammen, worauf wir uns geeinigt haben — Ziele, Beteiligte, Anwender und deren konkreten Nutzen, Lieferobjekte, Meilensteine, Risiken, Einschränkungen und den Projektumfang.

Ein Feld dieser Seite ist uns besonders wichtig: das, in dem steht, was nicht zum Projekt gehört. Nach unserer Erfahrung entstehen die meisten Konflikte in Softwareprojekten nicht dort, wo etwas falsch gemacht wurde, sondern dort, wo zwei Seiten unausgesprochen Unterschiedliches erwartet haben. Wir schreiben deshalb nicht nur auf, was wir tun, sondern ebenso, was wir nicht tun — und wer nicht entscheidet.

Mit dieser Seite gehen beide Seiten in den Kick-off. Und beide gehen mit demselben Bild hinein.