Projekte existieren nicht...

...zumindest nicht in der Softwareentwicklung. In den letzten zehn Jahren habe ich unzählige Male das Wort „Projekt“ gehört. Ehrlicherweise fast nie in einem sinnvollen Kontext. Nie habe ich in dieser Zeit ein erfolgreiches Projekt gesehen. Natürlich wurden Projekte unternehmenspolitisch als Erfolg verkauft, aber als wirklicher Erfolg wurden diese Projekte von der Belegschaft und Kunden nie wahrgenommen. Doch wie genau definiert sich denn ein Projekt? Im Folgenden eine Definition, die es in meinen Augen gut zusammenfasst.

„A project is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources. And a project is unique in that it is not a routine operation, but a specific set of operations designed to accomplish a singular goal“ Project Management Institute

Software ist nie fertig

Mal angenommen eine Software erfüllt einen Use Case in Perfektion, es sind keine Bugs oder Sicherheitslücken vorhanden und die Usability ist so hervorragend, dass ein Kleinkind die Anwendung bedienen kann. Selbst dann ist die Software nicht fertig! Warum? Die Welt um die Anwendung herum entwickelt sich ständig weiter. Und dies hat Auswirkungen.

Sicherheitslücken in Frameworks, Betriebssystemen oder Hardware werden erst im Laufe der Zeit entdeckt, wie bspw. Meltdown. Durch steigende Rechenleistungen sind Verschlüsselungsalgorithmen die vor einigen Jahren noch als sicher galten, mit den Möglichkeiten von heute knackbar. Eine schöne Veranschaulichung wie sich die Dauer zum Knacken eines Kennworts entwickelt hat kann hier gefunden werden. Hundertprozentige Sicherheit existiert natürlich nicht, sich deswegen nicht trotzdem zu bemühen wäre fahrlässig.

Märkte entwickeln sich weiter. Wer vor 20 Jahren ein Auto mit Verbrennungsmotor produziert hat, sieht sich heute mit Elektroautos konfrontiert. Handyhersteller, die den Umstieg zu Smartphones verschlafen haben existieren heute nicht mehr oder sind bedeutungslos. Natürlich sind es nicht immer diese extremen Szenarien, bei denen ein kompletter Hype verschlafen wurde - häufig sind es nur kleine Verbesserungen die den Unterschied machen.

Falls zum aktuellen Zeitpunkt keine bessere Lösung am Markt existiert muss dies nicht zwangsläufig so bleiben. Die Konkurrenz schläft nicht. Ist es nicht deprimierend, wenn man viel Geld in die Hand nimmt für eine individuelle Lösung und ein Jahr später könnten man für ein Bruchteil des Betrags eine bessere Lösung einkaufen? Dieses Szenario ist mir mehr als einmal untergekommen. Wird ein internes System ausgetauscht ist dies unangenehm genug - es müssen Prozesse angepasst und Mitarbeiter umgewöhnt werden - bei externen Systemen verliert man schnell Kunden oder sogar die Existenzgrundlage.

Durch neue Technologien entstehen Möglichkeiten, die früher undenkbar waren, und erfordern sein Produkt zu verbessern. So ist es heute selbstverständlich (oder sollte es zumindest sein) eine Webseite für Mobile-Devices zu optimieren oder sogar mobile-first zu konzipieren. Der nächste große Spaß für Webentwickler werden meiner Meinung nach Foldables. Doch was kommt danach? Hologramme? Wenn wir in die Vergangenheit schauen, lässt sich auf jeden Fall sagen, dass die Verbreitung von Technologie in immer kürzeren Zyklen geschieht, und wir uns dementsprechend immer schneller anpassen müssen.

Lassen wir nun estäthische Aspekte außen vor, so sollten die vorherigen Argumente ausreichen um zu zeigen, dass eine Software niemals fertig sein kann. Wird etwas anderes Versprochen, so kann dies zwangsläufig nur zu Unzufriedenheit beim Endnutzer führen.

Zum Scheitern veruteilt

Wird ein Projekt ausgeschrieben oder bei einem Dienstleister beauftragt, so beginnt das Prozedere idealerweise mit einem Pflichten- und einem Lastenheft. Natürlich sind auch agile Projekte möglich, allerdings endet dies in der Regel in einem gefährlichen Zwitter aus Wasserfallmodell und Agilität. Das Budget und der Zeithorizont sind, per Definition eines Projekts, festgelegt, das Ergebnis allerdings nicht klar spezifiziert. Verständlich, dass man da als Geldgeber Bauchschmerzen hat.

Gehen wir daher von einem klassischen Wasserfallmodell aus, bei dem eine schriftliche Anforderungsdefinition vorliegt. Und genau hier liegt der Hase im Pfeffer. Als Kunde, der häufig nicht viel Erfahrung mit der Entwicklung und dem Betrieb von Software hat, ist es denkbar schwer, alle relevanten Anforderungen zu definieren. Je größer das Projekt, umso schwerer wird es die Anforderungen sauber zu definieren oder während des Projekts schnell nach zu justieren.

Da wir leider in einer sehr monetär getriebenen Gesellschaft leben, werden Dienstleister, die realistische Aufwände in ihr Angebot schreiben oder eine vorherige ANforderungsanalyse vorschlagen üblicherweise benachteiligt. Stattdessen gewinnen die Schaumschläger, die dem Kunden das „too good to be true"-Paket versprechen. Also hohe Qualität, in kurzer Zeit zu geringen Kosten. Wie ein kluger Manager einst zu mir sagte: „Die wollen doch verarscht werden".

Die Konsequenz aus den bisherigen Worten ist, dass Projekte (fast) immer von vorne rein zum Scheitern verurteilt sind. Laut einer Studie der Firma Geneca sind übrigens 75% aller IT-Führungskräfte der Meinung, dass ihre Projekte von Anfang an zum Scheitern veruteilt sind.

Fazit

Bitte baut nur Software für das Kerngeschäft. Wenn ihr nicht vor habt auf dem Markt mit Wordpress zu konkurieren baut kein eigenes CMS-System. Wenn ihr nicht vor habt euch mit Salesforce anzulegen programmiert keine eigene CRM-Software. Softwareentwicklung ist keine Sache von ein paar Stunden nebenbei, unterschätzt es bitte nicht. Wenn ihr nicht bereit seid mindestens eine halbe Millionen pro Jahr zu investieren braucht ihr garnicht anfangen - und glaubt nicht, dass wäre nur vorrübergehend und wird bestimmt später günstiger.

Holt euch ein solides System vom Markt und lasst die letzten 10% von spezialisierten Integratoren auf eure Bedürfnisse anpassen. Das ist ein sinnvolles Projekt. Ihr gewinnt so viele Funktionen die ihr bei einer eigenen Lösung gar nicht bedacht hättet und seid in der Lage euch an die wandelnde Umgebung in der Zukunft relativ einfach anzupassen indem ihr mit einem neuen Projekt auf eine neue Version upgradet. Niemand muss das Rad neu erfinden und ihr könnt von den Erfahrungen anderer Kunden profitieren.

Wollt ihr nun aber Software für euer Kerngeschäft könnt ihr ein Projekt als Proof-of-Concept durchführen. Dafür lässt sich wunderbar ein Dienstleister engagieren - sofern das Bewusstsein vorhanden ist, dass ein Wegwerfprodukt geschaffen wird und nur die Erfahrung zählt. Ist euer MVP erfolgsversprechend solltet ihr das Thema intern aufgleisen. Alles andere kostet euch unnötig Geld und ihr verliert Kontrolle.