Worin unterscheiden sich IoT-Projekte eigentlich von anderen IT-Projekten?
Seit 15 Jahren machen wir nun IoT Projekte zusammen mit unseren Kunden. Gut, früher hießen diese Projekte noch anders. In dieser Zeit haben sich die Projektmanagementmethoden weiterentwickelt, und auch wir arbeiten heute überwiegend agil. Wir nutzen beispielsweise Scrum nicht nur für unsere Software-Projekte, sondern setzen auch Methoden wie Kanban im normalen Projektmanagement ein.
Aktuell sind wir nun Konsortialpartnern in einem Green Microgrid Projekt in Südafrika, das zum Ziel hat, aus Solarenergie und grünen Rohstoffen grüne Energieträger wie Methanol und Wasserstoff zu erzeugen. Das ist eine tolle und spannende Herausforderung und für uns eines der größten Projekte, an dem wir jemals gearbeitet haben.
Unsere Rolle als IoT-Experten wird in dem Konsortium die sein, alle Informationen zwischen den einzelnen Produktionsteilen zu erheben, zu sichern und auszuwerten, um eine übergreifende End2End Produktionssicherung zu gewährleisten. Aber auch das Reporting ist sehr wichtig, denn letztlich muss der gesamte Prozess der Produktionskette immer wieder zertifiziert werden, um sicherzustellen, dass wir auch entsprechend der Vorgaben wirklich grüne Energieträger herstellen werden. Dementsprechend ist das ein klassisches IoT-Feld, bei dem es um die Erhebung großer Datenmengen geht, um Data Analytics und Prediction.
Funktionieren in diesem Umfeld agile Projektmanagementmethoden?
Kann ich dem Kunden wirklich sagen, dass ich zuerst ein MVP – oder schlimmer noch, einen Prototypen – bauen werde, um dann zu bewerten, ob mein Ansatz korrekt ist und meine Annahmen für das Pricing des Gesamtprojektes in etwa stimmen? Oder ist dann nicht schon im Worst Case viel zu viel Geld in den Sand gesetzt worden? Geht ein Investor einen solchen Ansatz mit, wenn das finale Projekt im zweistelligen Millionenbereich Kosten produzieren wird?
Das hat mich dazu veranlasst, unsere Projektmanagementmethoden, mit denen wir in den letzten Jahren erfolgreich Projekte umgesetzt, haben noch einmal zu hinterfragen. Ich habe einen Tag investiert, um Best Practices im Internet zu recherchieren, um mit Kollegen zu sprechen und habe versucht, mich in den berühmten Helikopter zu setzen, um eine abstrakte, bessere Sicht auf die Dinge zu bekommen. Hier sind meine Erkenntnisse.
Wo sind die Unterschiede?
Die erste Frage war, ob es wirklich einen eklatanten Unterschied zwischen IoT Projekten und normalen IT Projekten gibt oder ob sich die Projektmanagementansätze gleichen? Das Ergebnis hat mich nicht wirklich überrascht. Sehr oft sind die Ansätze absolut austauschbar. Der größte Unterschied liegt darin, dass bei IoT Projekten häufig eine sehr viel größere Anzahl von Devices gehandelt werden muss, was natürlich Aufwände in der Provisionierung in der Überwachung und vor allen Dingen in der Anschaffung und im Ersatzteilmanagement voraussetzt. Auch das Thema Sicherheit und vor allen Dingen die Cybersicherheit stehen bei IoT Projekten häufig im Vordergrund, da wir alle wissen, dass viele Devices und ein hohes Kommunikationsaufkommen dazwischen sehr viele Einfallstore für Angriffe öffnet.
Man kann die Best Practices für solche Projekte am besten wie folgt zusammenfassen.
- Beginnen Sie mit einem klaren Plan: Definieren Sie die Ziele, Anforderungen und den Zeitplan Ihres Projekts klar und deutlich.
- Verwenden Sie agile Methoden: Agile Methoden wie Scrum und Kanban helfen Ihnen, flexibel auf ändernde Anforderungen zu reagieren und Ihr Projekt termingerecht abzuschließen.
- Investieren Sie in die Sicherheit: Stellen Sie sicher, dass Ihr IoT-System vor unbefugtem Zugriff und Cyberangriffen geschützt ist.
- Testen Sie Ihr System gründlich: Stellen Sie sicher, dass Ihr IoT-System in der realen Umgebung zuverlässig funktioniert.
- Überwachen Sie Ihr System kontinuierlich: Überwachen Sie die Leistung und Sicherheit Ihres Systems und nehmen Sie bei Bedarf Anpassungen vor.
Aber wie gesagt: wir können den Begriff IoT aus diesen Best Practices getrost weglassen und dort fast alle anderen Buzzword einsetzen und sind schon fertig für unseren Projektansatz in einem anderen Bereich.
Je größer desto Wasserfall?
Die nächste Frage ist, ob sich ein Investor darauf einlässt bei sehr hohen Projektkosten den Ansatz mit einem MVP oder Prototypen mitzugehen? Will der Investor nicht viel eher von vornherein eine Sicherheit haben, dass ein solches Projekt in Time und in Budget umgesetzt werden kann? Ist es hier nicht Zeit für Wasserfall?
Nun, dazu kann man wirklich sehr lange Google befragen, ohne eine aussagekräftige Antwort zu bekommen. Letztlich ist es hier von entscheidender Bedeutung, wen man im Markt kennt und welche Erfahrungen man schon gemacht hat. Natürlich helfen hier auch Erfahrungen aus Großkonzernen enorm weiter. Gott sei Dank bin ich schon alt genug und auch schon in vielen Großkonzernen gewesen, so dass ich meine, diese Frage aus der Erfahrung gut einordnen zu können. Spätestens wenn ich in einen hohen sechsstelligen Kostenbereich komme, wird kein Manager eines Großkonzerns und kein Verwalter eines Investmentfonds einen komplett agilen Projektansatz mitgehen. Es ist absolut und zwingend notwendig, im Vorfeld belastbare Zahlen auf den Tisch zu legen und extrem genau die zu erwartenden Kosten abzuschätzen. Selbstredend wird natürlich auch noch eine ROI Betrachtung und in unserem Fall natürlich auch die Nachhaltigkeit peinlichst genau kalkuliert werden müssen. Es ist eine andere Frage, ob ich im Rahmen des Projekts dann nicht doch agile Methoden einsetzen kann, um meine Ziele zu erreichen. Aber niemand gibt sich zu Beginn des Projektes damit zufrieden, erst einmal einen Prototyp zu bauen und dann nach dem Ansatz „wird schon funktionieren“ und „wir hören einfach mit einem Increment auf, wenn das Geld alle ist“ weiterzumachen. Das wirft nochmal ein neues Licht auf den agilen Ansatz und auf die Erstellung eines MVPs in Großprojekten. Es stellt sich vor allen Dingen auch die Anschlussfrage, ob das, was in kleinen Projekten funktioniert, auch in großen Projekten funktionieren kann und andersherum.
Und nun?
Die Erkenntnis somit auch ein Punkt zu bringen: gutes Projektmanagement bedeutet, sich nicht auf eine Methode festzulegen und nicht sklavisch immer ein und denselben Ansatz zu verfolgen. Und es gibt viele Methoden, die das heutzutage schon erkannt haben. Entscheidet man sich für eine klassische Projektmanagementmethode wie zum Beispiel Prince2, hat man auch dort eine Flexibilität und sogar eine Verantwortung, seine Projektmanagementmethoden zielgerichtet und vorausschauend einzusetzen. Agile Projektmanagementmethoden gehen dabei sogar noch einen Schritt weiter; verlagern sie doch die Verantwortung für den Projekterfolg auf das gesamte Team. Das funktioniert – wie wir alle wissen – allerdings nur wenn das Team diesen agilen Mindset auch komplett verinnerlicht hat. Last not least hat auch ITIL 4 einen großen Schritt auf mehr Flexibilität hin unternommen und erlaubt die Prozessdefinitionen in viel größerer Freiheit als noch die Vorversion ITIL3.
Wie starten wir als PERK nun in unser Green Microgrid Project? Nun, so wie wir es eigentlich immer machen: sehr flexibel in der Wahl unserer Waffen. Und auch wenn andere Firmen auf festgelegte Beratungsansätze und Methodiken schwören, die ihnen ein klares und spitzes Profil geben und ihnen den Vertrieb vereinfachen, sind wir nach wie vor Fans von dem Ansatz, den Kunden, das Problem und das Ziel zu verstehen, bevor wir uns auf irgendeine Methode festlegen. Das fühlt sich manchmal an wie „wir schauen einmal und gucken und machen dann was“ und manch einer mag auch denken, dass wir keinen klaren Plan zu haben scheinen. In Wirklichkeit bin ich davon überzeugt, dass es genau andersherum ist. Denn wir sind die IoT-Architekten. Und keine Bauingenieure oder Mauer, die nach den immer gleichen Methoden arbeiten…
Neueste Kommentare