In dieser Episode erklärt unser Gast Steve, worauf man achten muss, wenn man ein Softwareprojekt startet, ungeachtet dessen, ob es sich um Ihr eigenes Projekt oder ein Projekt mit einem externen IT-Partner handelt.
Steve und Jarosław besprechen Themen, die bei einem Auftaktmeeting relevant sein könnten, anhand eines bereits durchgeführten Projekts für Fareshare, eine britische nationale Wohltätigkeitsorganisation, die den Hunger bekämpft und gegen Lebensmittelverschwendung vorgeht. Das Projekt im Rahmen dessen die Gestaltung und Entwicklung einer skalierbaren, maßgeschneiderten Lösung für den Umgang mit Überschüssen von Lebensmittellagern realisiert wurde, wurde von Steve gemanagt und von den Technikern von Future Processing programmiert.
Die Episode endet mit einer Zusammenfassung von 3 Elementen, die im Zuge des Projektstartstadiums nicht fehlen dürfen, um das Risiko des Scheiterns des Projekts zu minimieren.
Unsere Gäste:
Steve Baker ist ein unabhängiger IT-Berater mit einem enormen Hintergrundwissen über Betriebssysteme, Design, Architektur und Softwareentwicklung. Steve und sein Beratungsbüro, Vermillion IT, unterstützen Unternehmen dabei, ihre Prozesse zu untersuchen, zu beurteilen welche Arten von Systemen sie benötigen und, falls erforderlich, das Projekt durchzuführen, um diese Lösung zu liefern.
Jarosław Granat ist Future Processing’s Head of Client Engagement, der sich für die Gewährleistung des höchsten Serviceniveaus für die Kunden des Unternehmens einsetzt. Er hat Computerwissenschaften und Wirtschaftspsychologie studiert und arbeitet bereits seit 10 Jahren im IT-Bereich.
Das Transkript der Episode
Jarosław Granat (JG): Hallo, mein Name ist Jaroslaw Granat und ich möchte Sie zu dieser Episode von IT Leadership Insights by Future Processing begrüßen. Der Start eines Projekts ist definitiv keine stressfreie Aktivität. Mit einem externen Partner kann es noch schlimmer werden. Wir besprechen heute und zeigen einige Beispiele, wie man es richtig macht. Wir stellen Ihnen einige Fallstudien und optimale Empfehlungen vor. Zusammen mit dem brillanten Steve Baker, einem freiberuflichen IT-Berater und Inhaber des IT-Unternehmens Vermilion. Hallo Steve.
Steve Baker (SB): Vielen Dank und danke, dass Sie mich empfangen haben.
JG: Steve, für diejenigen, die die vorherige Episode nicht gesehen haben, als wir darüber sprachen, ob man eine Software kaufen oder selbst bauen soll. Könnten Sie sich bitte kurz vorstellen?
SB: Wie Sie bereits gesagt haben, bin ich ein unabhängiger IT-Berater mit einem recht umfangreichen Hintergrund in der Softwareentwicklung. Heute verdiene ich meinen Lebensunterhalt durch Mitarbeit in Unternehmen, die sich mit Geschäftsprozessen beschäftigen, indem ich herausfinde, welche Software sie zur Problemlösung benötigen, und bei einer daraus resultierenden Entwicklung führe ich das auf Wunsch aus.
JG: Sicher. Steve, jede Aktion, die wir durchführen, oder jedes Projekt, egal ob im Berufsleben oder in der Privatwirtschaft, folgt dem gleichen Weg: Die Art, wie wir es beginnen und die Art der Ergebnisse, die wir erzielen können. Je besser wir beginnen, desto bessere Ergebnisse erzielen wir, und ich denke, das gilt auch für die Softwareentwicklung. Daher meine Frage an Sie: Welche Elemente sollten bei der Projekteröffnung und beim Projektstart berücksichtigt werden?
SB: Bevor ich zu Ihnen kam, um mit Ihnen zu sprechen, habe ich meine Kollegen diesbezüglich befragt. Und unter uns gesagt, wir haben eine Art Top 3 gefunden.
JG: In Ordnung.
SB: Das erste ist der Start. Ein System zusammenzustellen, ist sowohl eine soziale Aktivität als auch eine technische Aktivität.
JG: Okay.
SB: Ein wichtiger Teil eines Auftaktmeetings besteht also darin, alle miteinander bekannt zu machen, sowie die Interessenvertreter und einige Endanwender einzubinden, um das Entwicklungsteam zu treffen und umgekehrt. Was wir versuchen, ist, ein gewisses Engagement beider Parteien für das Projekt zu entwickeln. Ein Auftaktmeeting ist also der beste Tipp.
JG: Würden Sie sagen, dass der Start eines Projekts nur das Auftaktmeeting ist oder dass noch mehr oder etwas im Voraus dazugehört?
SB: Nun, der Start ist eher ein Prozess, so dass Sie wahrscheinlich nicht alle Startaktivitäten in nur einem Meeting erledigen werden. Wenn wir alle Senior Stakeholder einbeziehen und Sie nicht die ganze Zeit in einer Eröffnungssitzung mit Diskussionen verbringen wollen(denn Entwickler lieben die stundenlange Diskussion darüber, wie sie ihre Git-Zweigstellen nennen sollen) sollte die Aufgabenstellung sein, in einem separaten Meeting das gesamte Set der Infrastruktur-Entwicklungsumgebung und all diese Dinge zu erfassen. Zum eigentlichen Projektstart würde ich zunächst die Stakeholder einbeziehen und vorstellen. Die erste Aufgabe ist also, ein Auftaktmeeting zu organisieren und zweitens wird die Gelegenheit genutzt, sich zu einigen, was Sie nach dem Projekt zu erreichen versuchen. Lassen Sie mich Ihnen ein Beispiel nennen. Sie und Ihr Partner entscheiden, dass Sie ausgehen werden und dass Sie am Samstag einen tollen Abend haben werden. Für Sie bedeutet das, ein schönes, ruhiges Essen in einem Restaurant.
JG: Das stimmt.
SB: Für den Partner bedeutet das, bis vier Uhr morgens in einen Nachtclub zu gehen. Sie sind sich einig, dass das Ausgehen am Samstagabend eine gute Idee ist, aber Sie haben völlig andere Vorstellungen davon, wie dies aussehen soll. Und so ist es auch in Projekten. Sie wollen ebefalls nicht, dass die Leute nach dem Startschuss aus dem Meeting gehen und unterschiedliche Vorstellungen davon haben, was Sie erreichen wollen. Ziel des Treffens ist es, dieses Ziel zu setzen und die Vorstellung darüber, , wie der entsprechende Erfolg aussieht. Wenn Sie sich nicht zuerst mit den Stakeholdern einigen, sind Sie wahrscheinlich auch nicht in der Lage, die Entwicklung zu starten. Alle Kollegen waren sich einig, dass dies einer der häufigsten Gründe für das Scheitern ist, in denen es keine gemeinsame Einigung darüber gibt, wie ein erfolgreiches Projekt aussehen soll.
JG: Wie stellt man sicher, dass man das richtige Engagement aller Beteiligten bekommt? Es kingt zu schön, um wahr zu sein: Jeder teilt das gleiche Ziel, jeder kennt die Vision. Aber eigentlich bin ich mir nicht sicher, welche Erfahrungen Sie haben, und ich weiß, dass es nicht immer so passiert. Also gibt es eine Tendenz der Beteiligten: „Okay, meine Arbeit hier ist erledigt. Das ist es, was getan werden musste, also auf Wiedersehen, und viel Glück weiter.
SB: Und mangelndes Engagement ist einer der häufigsten Faktoren für das Scheitern von Projekten. Es ist schwierig, es handelt sich immerhin um ein menschliches Unternehmen: Man muss versuchen, die Stakeholder zu überzeugen, anzuerkennen, dass sie nicht nur eine finanzielle Beteiligung daran haben, sondern auch eine Quelle der Expertise sind. Das Entwicklungsteam wird Tausende von Fragen haben, von denen viele nur die Stakeholder beantworten können und die relativ schnell beantwortet werden müssen. Zurück zum Zweck des Starts: Es geht darum, die Stakeholder, ich will nicht sagen zu unterrichten, sondern sie einzubeziehen, und sie haben nicht nur Rechte, sondern sie haben auch Verantwortung für das Projekt. Sie sollten versuchen, das hervorzuheben und sie einzubeziehen, so dass sie nicht nur für den ersten Startschuss, sondern während des gesamten Prozesses in das Projekt einbezogen werden.
JG: Würden Sie sagen, dass es einen Unterschied gibt, wie Sie ein Projekt mit einer externen Partei im Vergleich zu dem internen Projekt in Ihrem Unternehmen starten?
SB: Ja, viele Dinge sind gleich, aber wahrscheinlich sind die wichtigsten Unterschiede, dass ein externes Unternehmen nichts über Ihr Unternehmen weiß, oder es ist unwahrscheinlich, dass es etwas über Ihr Unternehmen weiß. Wenn Sie also mit einem internen Entwicklungsteam arbeiten, haben die Teammitglieder wahrscheinlich in diesem Geschäft gearbeitet und wissen, was sie tun. Ich nehme mir also ein wenig Zeit, um zu beschreiben, was das Unternehmen macht, welches die kritischen Erfolgsfaktoren sind. Vielleicht bringe ich ein paar Flussdiagramme, Diagramme, oder ähnliches ein, um zu erklären, was das Unternehmen macht. Zweitens werden Sie von einem anderen Ort aus arbeiten, genau wie der Product Owner oder Projektmanager, was auch immer Ihre Rolle ist, und Ihre Interessenvertreter werden wahrscheinlich nicht im selben Raum wie das Entwicklungsteam sein. Es gibt also einige Dinge, die man durcharbeiten muss, um herauszufinden, wie man auf Distanz zusammenarbeiten kann. Das Projekt, das ich mit FareShare hier durchgeführt habe, begann mit einem Scrum als Prozessmodell, und das ist ganz gut, denn es ist ein Standardprodukt, ein Framework aus dem Projektbetrieb. Es hat definierte Rollen, Verantwortlichkeiten und es hat definierte Prozesse. Das bedeutete, dass wir beide wussten, wie der Prozess aussah, obwohl wir räumlich getrennt waren. Jetzt können und sollten Sie Ihren Prozess anpassen, aber ein Framework für Standardprozesse, das Ihr externer Lieferant und Sie vereinbaren können, ist ein ziemlich guter Ausgangspunkt. Letztendlich kann man wohl sagen, dass man eine Kunden-Lieferantenbeziehung hat.
JG: Okay.
SB: Aber wenn Sie als Kunde zu diesem Auftaktmeeting gehen, denke ich, dass es Ihre Chance ist, dem Lieferanten zu zeigen, dass Sie ein guter Kunde sind. Sie werden pünktlich erscheinen. Sie geben an, dass das, was Sie sagen, auch tun werden. Sie werden ein guter Kooperationspartner sein, denn das schafft Vertrauen beim Lieferanten, der darauf bauen kann, dass Sie wissen, was Sie tun, und das Vertrauen in die Anfangsphase des Projekts geht ziemlich weit.
JG: Schauen wir uns reale Fälle an. Sie erwähnten FareShare, ein Projekt für eine britische Wohltätigkeitsorganisation, die Lebensmittelabfälle verhindert. Könnten Sie bitte ein wenig über dieses Projekt erzählen und wie der Auftakt dieses Projekts durchgeführt wurde, weil es ein ziemlicher Erfolg war?
SB: Wahrscheinlich sollte man sich darüber unterhalten, was FareShare leistet. Sie vertreiben auf dem Straßenweg Artikel aus der Lieferkette, was bedeutet, dass sie Lebensmittel aus dem Vertriebskanal des Supermarktes und von Herstellern beziehen und diese in großen Mengen an mehrere tausend wohltätige Partnerorganisationen in ganz Großbritannien verteilen. FareShare hat ein eher ungewöhnliches Geschäftsmodell, nicht viele Unternehmen verschenken Dinge, also haben wir darüber gesprochen, und wir haben eine Art Desktop-Tabletop-Spiel gespielt, ein Modell eines Tages im Leben von FareShare. Wir haben also eine kleine Übung auf dem Brett gemacht, mit einigen beweglichen Post-It Notizen und ähnlichenDingen, quasi ein Spiel, um das Geschäftsmodell zu veranschaulichen. Was dort auch geschah, war, dass Future Processing ebenfalls ein paar der Teammitglieder teilnehmen ließ, um an dem Tag mit FareShare zu arbeiten, was gut war. Sie sammelten Erfahrungen darüber, was FareShare vor Ort tat, und das war eine gute Praxis. Das ist sehr gut. Das Letzte, was wir beim Start getan haben, ist etwas ungewöhnlich, aber wir hatten uns bereits früher mit Systemen beschäftigt, die das gleiche leisteten, was FareShare heute macht; also haben wir zum Auftaktmeeting ein Software-Design oder eine Softwarearchitektur mitgebracht, die wir verwenden wollten, weil wir wussten, dass es funktionieren würde. Wir sprachen mit dem Team darüber, und das bedeutete am Ende des Auftakts, dass wir nicht nur über die Dinge gesprochen hatten, wie oben angegeben, nämlich über das Geschäftsmodell und wie der Erfolg aussieht, sondern wir hatten auch die ersten Ansätze, wie die Software organisiert werden sollte. Das war also schonmal sehr gut.
JG: In Ordnung, mir gefällt dieser Teil der Diskussion, wenn man darüber spricht, wie wichtig es ist, die Division zu verstehen und die Menschen einzubeziehen, denn neben dem offensichtlichen Kennenlernen des Unternehmens und des Geschäfts steigert es wirklich die Motivation des Teams. Ich spüre, wenn ich mit den Teams in Future Processing arbeite, dass das Wissen um die Funktionsweise des Unternehmens den Menschen positive Energie gibt.
SB: Okay, das ist gut. Was ich sonst noch zu jedem sagen würde, der bei der Verarbeitung solcher Dinge dabei ist oder daran arbeitet, ist auf den Lieferanten zu hören. Achten Sie auf Sätze des Lieferanten wie: „Wenn Sie dies tun, wird das Team motivierter sein”. Sie wissen also, dass dieser wahrscheinlich viel mehr Erfahrung in der Arbeit mit Outsourcing-Projekten hat, also hören Sie auf das, was er ihnen zu sagen hat und auf seinen Rat.
JG: Okay Steve, zusammenfassend gesagt, was kann getan werden, um das Risiko eines Projektversagens zu minimieren, wenn wir uns auf den Projektstart konzentrieren?
SB: Das wichtigste, wie ich schon sagte, ist, überhaupt eines zu haben. Nummer zwei: Stellen Sie sicher, dass Sie sich einig sind, was Sie mit diesem Projekt erreichen wollen. Und drittens: Sie sollten Sie sich darauf einigen, wie Ihr erster Prozess aussehen wird, insbesondere wenn Sie mit einem externen Entwickler arbeiten. Sie wollen nicht Ihre ersten Iterationen damit verbringen, darüber zu streiten, wie Sie vorgehen sollen. Vereinbaren Sie die anfängliche Ausgangsposition, da Sie die Arbeitsweise im weiteren Projektverlauf jederzeit anpassen können.
JG: In Ordnung, Steve, vielen Dank für die interessante Diskussion und für Ihre Tipps.
SB: Sehr gerne.
JG: Vielen Dank, dass Sie sich diese Episode von IT Leadership Insights by Future Processing angesehen haben. Wenn Sie dies hilfreich fanden und es Ihnen gefallen hat, teilen Sie es bitte und empfehlen Sie es Ihren Freunden und Kollegen, die dieses Wissen benötigen, und lassen Sie uns wissen, ob es etwas gibt, worüber wir in weiteren Episoden sprechen sollen. Bis zum nächsten Mal.