15.04.2020 (aktualisiert 30.05.2020)
Mein Herz jubelt! Korken knallen, Schultern werden geklopft, Menschen freuen sich und feiern. Wieder ist ein Software-Projekt gelungen. Nutzer können das neue System effektiv anwenden, Auftraggeber sehen ihren erwarteten Nutzen realisiert und der Lieferant freut sich über die problemlose Abwicklung.
Kennst Du das? Leider endet höchstens ein Drittel der IT-Projekte so oder ähnlich. Die Chaos-Studie der Standish Group zeigt seit 1994 dieses Bild. Ursachen? Zu wenig Unterstützung vom Chef, unzureichend eingebunden Nutzer, unklare Vorstellungen. Das sind Kommunikationsprobleme. Und die sind einfach zu lösen.
Wie? Verfolge meine 7-teilige Serie mit Denkanstössen, dazu Checklisten, Anleitungen und Prinzipien zum Herunterladen und Nutzen. Profitiere von meiner Erfahrung als Informatik-Ingenieur, Projektleiter und Berater und lass Dein nächstes Projekt gelingen. Jeden Samstag wächst dieser Blog um einen weiteren Aspekt. Ganz zum Schluss kannst Du ihn mit allen Zulagen als PDF-Datei herunterladen.
Diese sieben Punkte sind geplant:
«Gummibärli kaufen» ist kein Projekt, ein Haus bauen hingegen schon; das leuchtet uns ein. Aber wo ist die Grenze? Was rechtfertigt Projektorganisation und Planungsaufwand? Das sind die Kriterien.
Kriterium 1
Zwischen Süssigkeitenbeschaffung und Hausbau gibt es einen wichtigen Unterschied. Das eine tue ich laufend, das andere bloss einmal. Das eine findet kein Ende, das andere hoffentlich schon. Diese Überlegung liefert das erste Kriterium: Ein Projekt ist ein einmaliges Vorhaben mit definiertem Anfang und Ende.
Kriterium 2
Für den Bauherren ist der Hausbau ein Projekt. Ist er das für alle Beteiligten? Nein. Nicht für jene, die das täglich machen: Architekten, Bauingenieure, Handwerker und so weiter. Zwar arbeiten sie an einem Projekt, aber es ist ihr Alltag. Sie sind für diese komplexen Abläufe eingerichtet und gewohnt, sie abzuwickeln. Diese Überlegung liefert das nächste Kriterium: Was ich täglich tue, ist kein Projekt, sondern ein Auftrag.
Kriterium 3
Wenn ich eine Sache zum ersten Mal mache, ist der Erfolg davon abhängig, wie kompliziert die Aufgabe für mich ist. Entscheidend ist die Anzahl nicht vertrauter Einflussfaktoren wie beispielsweise Technologie, Auftragsgrösse oder Anwendungsgebiet. Sobald ich beim Ordnen der Einflussfaktoren ins Grübeln komme, lohnt es sich, die Abwicklung des Vorhabens in Form eines Projekts zu prüfen.
Nimm diese drei Kriterien für dein eigenes Projekt mit und wende sie direkt an. Sollte es Deiner Meinung nach zu einem Projekt kommen, dann lies weiter. Der «Projektdialog» lüftet das Geheimnis der drei Ebenen.
Als Gott den Turmbau zu Babel verhinderte, war Sprachverwirrung sein zuverlässiges Mittel. Wer Projekterfolg will, muss nicht hören, was der andere sagt; er muss verstehen, was er meint. Für Projekte gibt es eine logische Reihenfolge von Punkten, die durchgängig verstanden werden müssen.
Unternehmen betrachte ich als eine Gruppe von Menschen, die gemeinsam eine Aufgabe lösen. Mit Projekten wird entweder die Aufgabe selbst oder die Art und Weise, wie sie gelöst wird, geändert. Im Fokus stehen dabei Unternehmensziel, Prozesse und Hilfsmittel.
Denken in Ebenen
Damit Projekte gelingen, braucht es das gemeinsame Verständnis von Menschen auf mehreren Ebenen. Das herbeizuführen ist die Verantwortung des Projektleiters. Er ist idealerweise vom Anfang bis zum Schluss mit dabei. Wer wann was dazu beiträgt, erkläre ich anhand untenstehender Grafik.
Von links nach rechts sind die zu durchlaufenden Projektaufgaben dargestellt. Sie folgen logisch aufeinander. Darauf gehe ich in den nächsten fünf Beitragsteilen näher ein. Agile Methoden durchlaufen alle oder einen Teil der Aufgaben mehrmals und schärfen die einzelnen Aspekte in mehreren Schlaufen.
Nun zu den Ebenen. Grün ist die Unternehmensführung, blau sind die Prozesse und rot die gesuchten Hilfsmittel. Allen Aufgaben voran geht die unternehmerische Zielsetzung, gefolgt von den abhängigen Prozessen und den dafür erforderlichen Hilfsmitteln – in unserem Fall ist dies Software. Erfahre in den folgenden drei Punkten, wer auf der jeweiligen Ebene verantwortlich ist und was geklärt sein muss.
Ebene 1 – das Unternehmen
Wenn ein Unternehmen Ressourcen für ein Projekt bereitstellt, dann nur in der Erwartung eines Gegenwerts. Diesen genau zu verstehen ist der wichtigste Schritt überhaupt. Die beste Lösung nützt nichts, wenn sie keinen unternehmerischen Zweck erfüllt. Und wer kann diesen definieren? In erster Linie der Ideengeber. Und überprüfen kann die Idee am besten der, der das Projekt bezahlt.
In Teil 3 dieses Beitrags «Projektstart – verpass Deinem Projekt seine DNA» zeige ich Dir einen sicheren Weg, wie auf unternehmerischer Ebene eine solide Basis für das Projekt entsteht.
Ebene 2 – die Prozesse
Wer weiss, wie Brote gebacken werden? Der, der es täglich macht. Wer weiss, welche Hilfsmittel ihm dabei helfen? Ebendieser. Wenn nun die Aufgabe oder die Art und Weise der Erbringung sich ändert, wer weiss am besten, wie die Abläufe sich ändern müssen? Nochmals derselbe.
Es sind die Menschen, die für die Umsetzung der Unternehmensaufgabe verantwortlich sind, jene, die in den Prozessen arbeiten. Sie müssen das Projektziel genau verstehen, um daraus ableiten zu können, wie die Prozesse umgestaltet werden müssen, um es zu erreichen.
Wie Anforderungen angemessen und lösungsneutral erarbeitet und festgehalten werden, klärt Teil 4 dieses Beitrags «Projektinhalt – lösungsneutral definieren, was Du wirklich brauchst».
Ebene 3 – die Software
Die Änderung von Prozessen geht meistens mit der Anpassung von Hilfsmitteln einher. Software ist ein abstraktes und komplexes Hilfsmittel. Irgendjemand stellt dieses bereit. Wenn er das unternehmerische Ziel versteht, sind auch die Prozesse und damit die Wünsche an die Hilfsmittel plausibel. Nur auf dieser Basis kann er eine geeignete Lösung vorschlagen.
Wie Du aufgrund Deiner Anforderung den passenden Lieferanten für Deine Lösung findest vertieft «Projektinhalt – wie Du die passende Lösung findest, und ein paar Worte zur Chemie», der fünfte Teil dieses Beitrags.
Vorbereitung für Aufgabe 1 auf Ebene 1 – der Projektstart
Nachdem Du anhand der Projektkriterien festgestellt hast, dass Du ein Projekt aufgleisen willst, ist der nächste wichtige Schritt die Identifikation von Urheber, Bezahler und Leiter des Projekts. Das sind die drei entscheidenden Rollen für den Projektstart. Der erste hat die Projektidee, der zweite finanziert sie und der dritte trägt sie durch alle Ebenen und Aufgaben hindurch und arbeitet auf den Erfolg hin.
Und gib Deiner Idee einen griffigen Namen – eine Identifikation.
Das linke Auge ist zugekniffen, das rechte fokussiert über die rechte Hand hinweg. Der Arm zittert ganz leicht vor Anspannung. Er zieht das Stück gebogenen Drahts zu sich nach hinten. Der andere Arm hält dagegen. Dessen Daumen und Zeigefinger spannen das Gummiband nach vorne, in Richtung Ziel. Die Agraffe kurz vor ihrem Abflug ist mein Lieblingsbild für den Start eines Projekts.
Wie bei einem Projektil wird auch beim Projekt etwas nach vorne geworfen. Wikipedia erklärt: «Projekt leitet sich ab von lateinisch […] proiectus ‚nach vorn geworfen'». Ein Projekt ist quasi die Veränderung eines unpassenden Umstands, deren Umsetzung wir durch einen Blick in die Zukunft bereits erkennen.
Die Spannung im Gummiband repräsentiert die Motivation. Anvisiert wird das Ziel. Der bewirkte Effekt im Ziel ist der Nutzen.
Motivation
Das Spannungsfeld, welches uns zu einem Projekt antreibt, muss stark sein. Wenn Du willst, dass die Agraffe weit fliegt, musst Du gehörig spannen. In seinem Buch SPRINT, der Anleitung für eine agile Methode, konstatiert Jake Knapp «Je grösser die Herausforderung, desto besser der Sprint» und schiebt diese Merkpunkte hinterher: «Es steht viel auf dem Spiel», «Die Zeit ist knapp» oder «Du steckst fest». Diese Punkte können wir gut auch auf jedes Projekt anwenden.
«Mot(z)ivation» nenne ich den ersten Schritt im Initialisierungs-Workshop. «Was ist so schlecht am aktuellen Zustand, dass Du ein Projekt startest?», lautet jeweils die Frage dazu. Jeder Beteiligte notiert dann seine Punkte auf Karten und erläutert sie im Anschluss. Ähnliche Punkte werden zusammengefasst und in übergeordneten Begriffen gesammelt. Clustern nennt man das. So lassen sich aus der umfangreichen Sammlung drei negative Kernthemen herausarbeiten, über die sich die Teilnehmer einig sind.
Zielsetzung
Wer mit einer Agraffe über grosse Distanzen treffen will, braucht ein klar erkennbares Ziel. Mit drei knapp formulierten emotionalen Punkten ist dies für Dein Projekt erreicht. Jeder im Projektteam kann sich drei Punkte leicht merken.
Formulierst Du die negativen Kernthemen aus der «Mot(z)ivation» nun positiv um, setzt Du damit im Handumdrehen ein attraktives und akzeptiertes Ziel für Dein Projekt.
Nutzen
Ein herrliches «Pling» reicht dem Siebenjährigen als Lohn, wenn die Agraffe aufs Blechschild trifft. Die Freude darüber, getroffen zu haben, ist sein Nutzen.
«Gehen wir davon aus, dieses Ziel tatsächlich zu erreichen, was nützt uns das?», ist die nächste entscheidende Frage. Erneut notieren die Teilnehmer ihre Punkte auf Karten und erläutern sie. Der Blick liegt klar auf Zeit und Geld, das eingespart werden kann. Hast Du hier eine Summe, weisst Du auch sofort, was Dir dieses Projekt wert ist und kannst Deine Investitionsbereitschaft quantifizieren.
Projekte sind wie «Agraffen spicken»
Übertragen wir das Bild noch einmal auf unser Projekt, kann der symbolischen Agraffe auf ihrem Weg ins Ziel viel mehr in die Quere kommen, als der echten in den Sekundenbruchteilen ihres Fluges. Deswegen bearbeite ich neben Motivation, Zielsetzung und Nutzen noch sechs weitere Themen in meinen Initialisierungs-Workshops. Um mehr zu erfahren, lade Dir meine bewährte Arbeitsvorlage herunter oder wirf einen Blick auf meine Projekte-Hauptseite. Neun Punkte solltest Du immer vor dem Kick-off Deines Projekts klären. Damit drehst Du die Erfolgsfaktoren erheblich in Richtung Gelingen.
Wenn Du selber ein Projekt startest und diese Arbeitshilfe dazu verwenden möchtest, bestell Dir die genauhoch3 Projektinitialisierung als A0-Plakat mit passendem Arbeitsmaterial in praktischer Planrolle im Onlineshop. Brauchst Du es öfters, gibt es auch eine Variante als magnetisches Whiteboard. Schau rein.
In einem Beitrag des Gehirnforschers Gerald Hütters las ich, unser Gehirn sei darauf aus Energie zu sparen, Probleme also auf einfachstem Weg zu lösen. Wenn die Aufgabe nicht im Kopf zu lösen ist, helfen ein paar Notizen.
Darüber hinaus nehmen wir Anstrengungen nur dann in Kauf, wenn wir darauf hoffen, danach beim Erledigen unserer Aufgaben weniger Aufwand zu haben. Wir sind also bereits von Natur aus darauf programmiert, einen echten Gewinn zu erzielen. Los geht's.
Eine klare Vorstellung ist nach der Management-Unterstützung und dem Einbinden der Nutzer (siehe Projektdialog Ebenen 1 und 2) der dritte Erfolgsfaktor für Software-Projekte. Wie kommst Du aber zu einer ähnlich klaren Vorstellung Deiner Anforderung? Wie zeigst Du potenziellen Lieferanten, was Du brauchst und willst? In Deiner Vorstellung müssen Personen eine Geschichte erleben.
Vorstellung
Vorstellung meint die Phantasie eines Zustands in der Zukunft. Dabei machen wir uns Gedanken darüber was wir mit der Lösung tun wollen, aber keinesfalls wie sie das bewerkstelligt. Dazu folgendes Beispiel:
Privat plane ich das Einrichten einer kleinen Werkstatt. Aus sägerauem Holz will ich für unseren Bedarf im Haushalt Möbelprojekte realisieren. Da ich noch nie eine Werkstatt eingerichtet habe, muss ich mir einen Plan zurechtlegen. Dabei stelle ich mir die Personen vor, welche die fertig eingerichtet Werkstatt nutzen sowie die Geschichte, die sie darin erleben.
Personen
Skizziere also grob die Menschen, die in Deiner Geschichte vorkommen. (Siehe Ebene 2 von Projektdialog.)
In meinem Beispiel bin ich selber derjenige, der die Werkstatt nutzen wird. Als Freunde von mir erfuhren, dass ich eine Werkstatt einrichten will, meldeten sie bereits Ihr Interesse an, sie mitzunutzen. Darüber hinaus meldete auch meine Frau Ansprüche an den Raum an, die weniger dessen Nutzung als Werkstatt, sondern in seiner Funktion als Durchgang zum Keller betreffen. Für meine Geschichte könnte das etwa so aussehen:
Geschichte
Nun geht es darum, die Geschichte zu beschreiben. Eine gute Idee ist es, den Ablauf in zeitlicher Abfolge als Comic zu skizzieren; damit wird der Umfang sichtbar. Im Anschluss werden dann die erforderlichen Details ausgearbeitet. Je nach Projektvorgehen erfolgt dies in einem Rutsch oder iterativ.
Im Beispiel zeige ich die Geschichte anhand des Hauptnutzers auf. Im Projekt würden wir sie aus Sicht jedes Nutzers separat skizzieren.
Um Möbel herzustellen, durchläuft das Holz vier Arbeitsschritte. Zuerst werden die Klotzbretter in Bild 1 grob zugeschnitten. In Bild 2 werden sie auf Mass gebracht. Bild 3 zeigt das Erstellen von Verbindungen und Bild 4 den Zusammenbau.
Anwendungsfälle
Die Skizzen helfen, die Übersicht zu behalten. Jetzt tauchen wir in die einzelnen Arbeitsschritte ein und beschreiben sie im Detail.
Zunächst finden wir einen eindeutigen Titel. Der besteht aus zwei Worten: der Bezeichnung des bearbeiteten Objekts und der Tätigkeit, die daran ausgeführt wird. Im obigen Beispiel könnte er für Bild 1 «Klotzbrett zuschneiden» lauten.
Dem fügen wir eine Beschreibung hinzu. Wir wollen auch in einem Monat noch verstehen, was mir damit gemeint haben, und notieren wenige Sätze in einfacher und prägnanter Sprache. Für Bild 1 könnte dies so lauten: «Das Klotzbrett wird grob auf circa einen Zentimeter Übermass zugeschnitten.»
Weitere Informationen dienen dem technischen Verständnis, der Organisation und der Zielführung des Projekts. Letzteres erreichen wir mit den Fragen «Welches Projektziel verfolgt die Umsetzung dieses Anwendungsfalls?» und «Welchen Nutzen liefert die Umsetzung?». Darüber hinaus schaffen die Diskussionen ein gemeinsames Verständnis und tragen so zum Gelingen des Projekts bei.
Lade Dir meine Vorlage zum Erarbeiten der Anwendungsfälle herunter. Ich selber nutze sie gerne als A0-Plakat und arbeite mit Haftnotizen.
Am liebsten hätte ich auf dem Absatz Kehrt gemacht! Was war passiert? Mir ist eine lebendige Stadt wichtig, darum berücksichtige ich gerne lokale Läden. Für meine Hobbywerkstatt hatte ich mir im Internet einen kleinen gusseisernen Einhand-Hobel ausgeguckt – ästhetisch, durchdacht und wertig. Vor meinem inneren Auge sah ich mich bereits damit arbeiten, fühlte ihn förmlich in der Hand liegen und sah die messerscharfe Klinge hauchdünne Späne vom Holz schneiden.
Als ich nun meinen Kaufwunsch vortrug, stellte mir der Verkäufer einen funktional einwandfreien aber emotionslosen Plastikhobel auf den Tresen. «Wir haben den.» Boom! Wie ein Schlag in die Magengrube fühlte sich das an. Glücklicherweise wusste ich was ich wollte, insistierte, holte mein Handy raus und zeigte dem Verkäufer das Produkt im Internet. «Ah ja, den kann ich bestellen», meinte er nun. «Einverstanden», willigte ich ein und war erleichtert.
Verkäufer präsentieren stets ihre Lösung und wollen die an den Mann bringen. Uns interessiert aber, ob die Lösung unsere Anforderung erfüllt. Dazu hat sich ein dreistufiges Verfahren als effizient und verlässlich erwiesen.
Nutzen pro Kosten
Was eine Lösung kostet, ist egal, solange sie sich in absehbarer Zeit amortisiert. Wenn Du Lösungen bewertest, interessiert Dich darum neben dem Preis der zu erwartende Nutzen. Wenn ich Lieferanten dazu einlade ein Angebot abzugeben, verlange ich zusätzlich eine Einschätzung ihrer Lösung. Ich will pro Anwendungsfall wissen, ob sie den Nutzen ganz, teilweise oder gar nicht realisieren können. Damit erstelle ich eine aussagekräftige Nutzwertanalyse und kann eine engere Wahl treffen.
Wer kann das Wichtigste?
Wer Lieferanten frei präsentieren lässt, vergleicht immer Birnen mit Äpfeln, Jeder hebt natürlich die Vorzüge seiner Lösung hervor. Um vergleichen zu können, muss ich die Führung übernehmen. Aus meinen Anwendungsfällen suche ich die Wichtigsten fünf heraus. Das sind in der Regel die, mit einem hohen Nutzenpotenzial. Dazu überlege ich mir Beispieldaten. Daraus erstelle ich ein kurzes Drehbuch, das ich als Leitfaden vorgebe. So stelle ich sicher, immer die gleiche Sequenz präsentiert zu bekommen, die wir als Projektteam bewerten. Der Lieferant darf dann darüber hinaus, sozusagen als Kür, die Vorzüge seiner Lösung noch betonen. Die ganze Präsentation sollte allerhöchstens 60 Minuten dauern. Daraus gehen ein oder höchstens zwei Favoriten hervor.
Kann er alles?
Aufgrund der Selbsteinschätzung und der Präsentation habe ich ein grobes Bild der Lösung bekommen. Bevor ich einen Zuschlag gebe, will ich eine kleine Belastungsprobe von Lieferanten und Lösung durchführen. Darum lade ich zu einem zweiten Termin ein. Diesmal spielen wir die komplette Anforderung durch. Dazu wird der Lieferant sich bereits konzeptionelle Überlegungen machen müssen. Idealerweise notiert er sich die Erkenntnisse aus diesem Workshop und ist im Anschluss in der Lage ein verbindliches Angebot mit einem Grobkonzept abzugeben.
Ein Gewinn für beide Seiten
Dieses Vorgehen ist für beide Seite mit Aufwand verbunden. Es liefert aber eine belastbare Grundlage für die bevorstehende Verhandlung und die anschliessende Umsetzung.
Hier steht Dir die leere Vorlage einer einfachen Nutzwert-Analyse als Download zur Verfügung.
Es ist zum einen die pure Freude am reibungslosen Arbeiten, die ein gelungenes Projekt ausmacht. Zum anderen ist es die daraus resultierende wirtschaftliche Auswirkung. Dabei spielt die investierte Summe eine grosse Rolle, aber viel entscheidender ist auf lange Sicht der daraus gezogene Nutzen.
Die untenstehenden Grafiken verdeutlichen dies. Links ist viel Nutzen realisiert, rechts nur wenig. Zuerst zieht die Investition den Projektsaldo bei beiden tief unter null. Bei der Grafik links strebt er dann durch den realisierten Nutzen gegen null und darüber hinaus. Rechts wird er aufgrund des flachen Verlaufs die Gewinnzone wohl kaum erreichen, bevor die nächste Investition fällig wird. Das Projekt bleibt in vielen Fällen weit hinter dem Potenzial zurück, ist wirtschaftlich wirkungslos oder gar verlustbehaftet.
Das Beziffern von Investition und Betriebskosten ist einfach. Die Überprüfung von Nutzen ist nicht viel schwieriger, wird aber in den seltensten Fällen unternommen. Mit der Schätzung von Nutzenpotenzial für realisierte Anwendungsfälle in Teil 4 dieses Beitrags sind wir dafür aber bestens gerüstet. Wie Du Nutzen wirklich realisierst, zeigen die folgenden Abschnitte.
Konzept
Eine Lösung kann kaum je vollständig erfüllen, was gefordert ist. Es ist fast immer eine Annäherung, ein Aushandeln, möchte ich fast sagen. Beim Aufnehmen der Anforderungen machten wir uns Gedanken darüber, was wir tun wollen, aber keinesfalls wie. Das kehren wir jetzt um. Der Lieferant erklärt nun, wie er sich die Lösung vorstellt. Das erfolgt in den meisten Fällen in Workshops. Dabei wird er auch auf Punkte hinweisen, die schwierig oder aufwändig umzusetzen sind und Varianten vorschlagen. Du achtest jetzt darauf, wie gut Dein Nutzen dabei realisiert wird und priorisiert Varianten, die Dir viel bringen. Das erhält gleichzeitig die Transparenz für beide.
In der Regel liefert der Lieferant auch ein Vorgehensmodell. Du kannst Dich diesem dank Deiner guten Vorbereitung problemlos anpassen. Meistens entsteht dann ein Lösungskonzept und ein Projektplan, der es beiden Parteien ermöglicht, Projektfortschritt, Termine und Kosten genau zu überwachen und gegebenenfalls zu reagieren. Bewährt hat sich hierfür eine gemeinsame Ablage, worin die Unterlagen von beiden Seiten jederzeit eingesehen werden können.
Test
Die Weisheit «Wer misst, misst Mist», lernte ich als Elektroniker, das Plausibilisieren von Ergebnissen als Ingenieur-Student. Wer testet, muss wissen, welche Resultate er erwartet. Erneut leisten die Anwendungsfälle hervorragende Dienste. Unter Berücksichtigung von Vereinbarungen aus dem Konzept bereitest Du Testfälle vor. Software verarbeitet Daten. Zu jedem Anwendungsfall legst Du also relevante Beispieldaten fest sowie Deine Vorstellung dessen, was nach Durchführung des Anwendungsfalls an verarbeiteten Informationen vorliegen muss. Als Varianten bildest Du Testfälle mit erwartetem Verhalten bei Fehlbedienung.
So vorbereitet führst Du später die Testfälle zügig am System durch. Die Erwartungen werden entweder erfüllt oder nicht und Fehler werden als kritisch oder unkritisch eingeschätzt. Kritisch sind Fehler mit grosser Auswirkung und/oder schwerer Entdeckbarkeit. Unkritisch sind sie, wenn sie sofort auffallen und sich nicht gross negativ auswirken. Ein System kann seinen Betrieb aufnehmen, wenn keine kritischen Fehler mehr vorliegen.
Nutzen
Beim Testen der Anwendungsfälle musst Du erneut überprüfen, ob sie den geschätzten Nutzen erfüllen. Wie viel Zeit benötigten wir nach alter Arbeitsweise für einen Arbeitsschritt und wie viel jetzt? Wie häufig führen wir den Schritt aus? Der Rest ist reine Mathematik. Wenn die Ersparnisse auf diese Weise spür- und sichtbar werden, wird der Erfolg des Projekts greifbar und motiviert, das Beste rauszuholen.
Als Kinder spielten wir auf dem Schulhausplatz «Wand ab». Dafür braucht es eine Wand, parallel dazu eine Linie und einen Ball. Die Gruppe legt eine Reihenfolge fest. Der Ball wird vom ersten Spieler gegen die Wand getreten. Er versucht ihn so zu spielen, dass der Nächste ihn nicht vor der Linie abfangen kann. Gelingt dies, ist der fehlbare Spieler raus. Wer am Schluss noch drin ist, hat gewonnen. Blöd ist, wenn der Eigentümer des Balls als erster heimgeht.
Dinge dienen dazu, einen Nutzen zu bringen, das verdeutlicht dieses Beispiel. Es geht um das Spiel, nicht um den Ball. Der ist nur Mittel zum Zweck. Wann ist also ein Projekt gelungen? Erinnere Dich: «Ein Unternehmen ist eine Gruppe von Menschen, die gemeinsam eine Aufgabe lösen.» Gelungen ist ein Projekt, wenn das Lösen der Aufgabe am Ende des Projekts so ist, wie es zu Beginn des Projekts gewünscht war.
Ob Kosten und Termine eingehalten sind, siehst Du auf einen Blick. Wie sieht's aber mit dem Inhalt aus? Beim Projektstart wagtest Du einen Blick in die Zukunft. Du überlegtest, was am damaligen Status quo schlecht und somit zu verbessern sei. Du hast Ziele gesetzt, um Dich zu orientieren, so wie der Junge mit der Agraffe sein Ziel anvisiert. Idealerweise hast Du das aufgeschrieben. Nun kannst Du die Überlegungen von damals hervornehmen und nachvollziehen. Sind die Ziele erreicht? Hast Du wieder einen Ball zum Spielen?
Wie hat sich im Verlauf des Projekts die Atmosphäre im Betrieb geändert? Geht's den Mitarbeitern besser oder schlechter? Haben sich die Nutzer der Lösung einbringen können und sind sie glücklich damit? Gab es während des Projekts Konflikte? Sind die geklärt? Ist der neue Ball ein Tennisball? Macht es Spass, damit «Wand ab» zu spielen? Ist es ein Volleyball, der auf hartem Untergrund schnell kaputt geht, oder ist es ein richtig guter Fussball? Seid Ihr euch einig?
Was lief gut im Projekt, und was kann nächstes Mal besser gemacht werden? Niemand ist perfekt. Mache Fehler und lerne daraus. Sorge als Projektleiter für einen gelungenen Abschluss. Bereinige Unstimmigkeiten zwischen Auftraggeber, Nutzer, Lieferant. Wenn alles bereinigt ist, organisiere eine Feier. Lass die Korken knallen, klopfe Dir und den anderen auf die Schulter und geniesse den Erfolg. So sieht der Abschluss eines gelungenen Software-Projekts aus.
Willst Du wissen, wenn neue Texte publik werden? Lass Dich Updaten und folge mir auf linkedin.
Hast Du Fragen zu einem konkreten Projekt? Nimm Kontakt auf via Telefon, Email oder Video.
genauhoch3
Via Vitg 44
7126 Castrisch
kontakt@genauhoch3.ch
Ralph Chr. Baumgartner
dipl. ing. FH Informatik
+41 81 936 03 03
© 2022 genauhoch3 | Impressum und Datenschutz
