8 Fragen an dein Team bevor du das nächste Tech-Projekt genehmigst

Bevor du als IT-Leiter das nächste Projekt genehmigst, solltest du dir und deinem Team einige wichtige Fragen stellen. Spoiler: Die meisten sind nicht-technischer Natur.


  •  Daniel Lohausen
  •  
  • DevOps

Als Führungskraft in einer IT-Organisation warst du schon einmal in dieser Situation:

Deine IT-Mitarbeiter bitten dich, Zeit und Ressourcen in eine neue Technologie zu investieren - vielleicht ist es “das nächste große Ding” oder “etwas, das wir von Anfang an hätten tun sollen” oder “notwendig, damit wir effizient weiterentwickeln können”, und es “hilft unseren Kunden”, versteht sich.

Aber wie kann man beurteilen, ob es den Aufwand wirklich wert ist? Vielleicht hast du kein technisches Hintergrundwissen, oder es ist schon einige Zeit her, dass du selbst auf dem Gebiet gearbeitet haben - in jedem Fall ist es schwer.

Sich in die technischen Details des Vorschlags zu vertiefen, ist eine Falle - Technik wird immer komplizierter, und dein IT-Personal verfügt über das Wissen zur Beurteilung der technischen Aspekte. Nimm sie also ernst - stelle aber auch sicher, dass eine ganzheitliche Entscheidung getroffen werden kann, indem du Fragen aufwirfst, die auch die nichttechnischen Aspekte abdecken. Dies hilft ihnen auch, nicht nur über die technischen Aspekte nachzudenken, sondern auch über andere Auswirkungen.

Los geht’s:

Die Fragen

Nr. 1: Welche Geschäftsbereiche sind betroffen?

Dies ist eine wichtige Frage, um ein besseres Verständnis der geschäftlichen Auswirkungen zu erhalten. Wenn einer der großen Geschäftsbereiche betroffen ist, solltest du dir dessen bewusst sein.

Handelt es sich nur um einen unbedeutenden Geschäftsbereich oder sogar um einen, der rückläufig ist oder abgewickelt wird, lohnen sich Investitionen in die Technologie möglicherweise einfach nicht.

Wenn dein Team nicht weiß, welche Geschäftsbereiche betroffen sind, solltest du direkt Maßnahmen ergreifen, um dies im gesamten Unternehmen deutlich zu machen. Das kann so einfach sein wie eine Zuordnung zwischen technischen Komponenten und Geschäftsbereichen (oder Anwendungen), kann aber auch durch die Definition von Wertströmen realisiert werden. In jedem Fall sollte immer klar sein, wo und wie die IT Wert schafft.

Nr. 2: Was sind die Vorteile aus Kundensicht und wie lösen wir das Problem aktuell?

Eine neue Technologie ist gut und schön, aber sie sollte auch einen geschäftlichen Nutzen haben. Vielleicht ist es die Geschwindigkeit der Bereitstellung, die Sicherheit oder die Robustheit gegenüber Fehlern? Wenn es hier keinen eindeutigen Nutzen gibt, sollte das Projekt abgebrochen werden. Eine neue Technologie sollte nie einfach nur eingeführt werden, weil sie neu ist, sondern man braucht einen echten Business Case.

Um das zu verstehen, muss man natürlich wissen, wie die aktuelle technische Lösung aussieht - wie kann man sonst die potenziellen Verbesserungen beurteilen?

Nr. 3: Welche Alternativen wurden in Betracht gezogen?

Die heutige Technologielandschaft ist sehr vielfältig, so dass es immer mehrere technische Lösungen für ein bestimmtes Problem gibt. Die Suche und der Vergleich von Alternativen muss Teil des Auswahlprozesses sein.

Wenn du dir die verworfenen Alternativen ansiehst, kannst du außerdem die Prioritäten des Teams, das den Vorschlag unterbreitet, nachvollziehen (“Warum hat es sich für diese Technologie entschieden und nicht für die andere?”) und überlegen ob du damit übereinstimmst.

Neu sein reicht nicht.

Neu sein reicht nicht. Schon Schopenhauer wusste: „Das Neue ist selten das Gute, weil das Gute nur kurze Zeit neu ist.“

Nr. 4: Ist die Lösung zu komplex?

Das nenne ich die “Kubernetes-Falle”. Kubernetes ist eine Container-Plattform, die für die Unterstützung von 1000+ Containern mit hoher Zuverlässigkeit konzipiert wurde. Sie ist in hohem Maße anpassbar, aber auch komplex. Sehr komplex. Wenn nur ein paar Container ausfgeührt werden müssen, lohnt sich der Aufwand für die Einführung einer solchen Lösung wahrscheinlich nicht.

Dennoch verwenden viele Teams Kubernetes, weil es en vogue ist. Sie sind viel langsamer, als sie es mit einer einfacheren Technologie gewesen wären, profitieren aber nicht von den Vorteilen von Kubernetes, da ihre Umgebung nicht so komplex ist.

Bevor du also eine neue Technologie einführst, frag dein Team nach der Komplexität und vor allem danach, für welchen Grad an Komplexität die neue Technologie ausgelegt ist.

Nr. 5: Wie viele Personen müssen geschult werden? Wie steil ist die Lernkurve?

Teammitglieder, die eine neue Technologie einführen wollen, sind in der Regel technikaffin, d.h. sie können neue Technologien leicht erlernen und ihren Nutzen daraus ziehen.

Um jedoch das volle Potenzial auszuschöpfen, muss letztendlich jeder, der mit einer Technologie arbeitet, verstehen, wie sie funktioniert und wie sie genutzt werden kann. Dieser Schulungs- oder Ausbildungsaufwand muss geplant und bei der Betrachtung der Gesamtkosten berücksichtigt werden.

Risiko.

Risiko ist Teil jedes Vorhabens. Bereite dich vor und habe eine Plan B, wenn etwas schief geht.

Nr. 6: Wie sieht unser Rollback-Plan aus, wenn unsere Erwartungen nicht erfüllt werden?

Alles kann schief gehen, und die Einführung einer neuen Technologie ist da keine Ausnahme - vielleicht ist sie zu schwierig zu bedienen, nicht zuverlässig genug oder erfüllt eine andere Erwartung nicht.

Es ist wichtig, im Voraus zu definieren, ob es Abbruchkriterien gibt, und für den Fall eines Scheiterns vorzusorgen.

In der Regel ist es sinnvoll, einen Proof-of-Concept zu erstellen, das den Wert der neuen Technologie unter Beweis stellt, allerdings in einer isolierten Umgebung ohne Auswirkungen auf das Geschäft.

Du kannst auch in Erwägung ziehen, die neue Technologie parallel zur bestehenden Lösung laufen zu lassen, damit sie leicht verglichen werden kann. Auf jeden Fall möchtest du nicht in eine Situation geraten, in der man weiter machen muss weil die neue Technologie bereits so eng integriert ist, dass Sie sie nicht mehr rückgängig machen können.

Nr. 7: Warum jetzt?

Ein neues (technisches) Projekt ist immer eine Prioritätsentscheidung gegenüber anderen Entwicklungsaktivitäten.

Daher ist es wichtig zu wissen, ob das Projekt jetzt durchgeführt werden muss, oder ob es in der Zukunft durchgeführt werden kann. (oder besser: Ist die Durchführung zu einem späteren Zeitpunkt mit Kosten oder Risiken verbunden?).

Nr. 8: Wie zufrieden wart ihr mit den letzten fünf Technologieprojekten?

Entwickler neigen dazu, Veränderungen im technischen Bereich durch eine rosarote Brille zu sehen. Es macht immer Spaß, etwas Neues zu machen, und es hat wahrscheinlich irgendwo etwas verbessert.

Untersuchungen zeigen, dass dies der menschlichen Natur entspricht: Wenn es um komplexe Probleme geht, ziehen Menschen das Unbekannte (d.h. die neue Technologie) Dingen vor, dessen Schwächen sie nur allzu gut kennen (d.h. die Status-quo-Technologie). Dies wird sehr schön in Marianne Bellottis Buch “Kill It With Fire” (das entsprechende Kapitel ist kostenlos erhältlich) oder in der Forschungsarbeit von Bier und Connell erklärt.

So sahen auch die letzten fünf Technologieprojekte anfangs wahrscheinlich vielversprechend aus. Aber waren sie im Nachhinein wirklich den Aufwand wert, waren die Kosten so hoch wie erwartet? Wenn du dein Team dazu motivierst, die letzten Technologieprojekte wirklich zu bewerten - auch aus geschäftlicher Sicht -, werden sie ihren aktuellen Vorschlag vielleicht aus einem anderen Blickwinkel betrachten und möglicherweise überarbeiten.

Schlussfolgerung

Eine gute Entscheidungsfindung in Bezug auf neue technische Vorschläge ist eine komplexe und interessanterweise meist nicht-technische Herausforderung. Sie ist ein kritischer Erfolgsfaktor für echte technische Führung. Entscheidend ist es, von Anfang an die richtigen Fragen zu stellen. Das Ergebnis ist in der Regel nicht einfach eine Zustimmung oder Ablehnung, sondern eine Weiterentwicklung der ursprünglichen Idee. Selbst die stärksten Vorschläge werden durch eine gründliche Bewertung noch besser.

Über den Autor

img/team/lohausen.jpg Daniel Lohausen

Daniel Lohausen

Als Cloud-Architekt und Prozess-Coach vereint Daniel Lohausen zwei Kernelemente erfolgreicher Softwareentwicklung in einem ganzheitlichen Beratungsansatz. Er ist überzeugt, dass sich technische und prozedurale Innovationen positiv beeinflussen und man die besten Ergebnisse erzielt, wenn man bei beide Aspekte konstant weiter entwickelt.