Ein Projekt
Dieses Wort „Projekt“ bringt mich noch irgendwann um den Verstand. Ständig höre ich den Spruch „Daraus müssen wir ein neues Projekt machen“….. Leider höre ich den Satz viel zu selten in den richtigen Momenten, wenn es darum geht ein Projekt richtig durchzuplanen. Dann ist es an der Zeit viele kleinere Projekte aus einem zu großen Projekt zu erstellen. Es geht nicht darum aus jeder Supportaufgabe ein Projekt zu basteln. Mein Erachtens ist es die Kunst zu erkenne, ob ich einen Prozess für wiederkehrende Aufgaben definieren und etablieren muss oder ob ich tatsächlich vor einem „Projekt“ stehe, welches geplant und durchgeführt werden muss.
Unterschied Projekt/Prozess hervorheben.
Versuchen wir mal anhand von 2 Beispielen den Unterschied zwischen einem Prozess und einem Projekt besser herauszuheben.
Nehmen wir als Beispiel die Entwicklung eines Termintool, welches die Termine zwischen Kunden und den Kundenbetreuern organisiert. Die Branche ist dabei irrelevant, denn sowas gibt es von einer Versicherung bis hin zum Physiotherapeuten.
Egal ob das Tool individuell entwickelt wird, oder eine vorhandene Software installiert und konfiguriert wird. Bei dieser „Einrichtung“ handelt es sich um ein Projekt, welches als Ziel ein lauffähiges System ist, im Live-Betrieb. Nach der erfolgreichen Einrichtung:“Projekt abgeschlossen“…. könnte man meinen. Aber wir kennen es alle, während der Einrichtung kommt manchmal häufiger manchmal weniger folgende Frage: „Könnte man nicht noch dieses und jenes anders oder besser machen?“. Und schon landen CRs im Backlog und möchten bearbeitet werden. Gehören die CRs nun noch zum Projekt? Das war doch abgeschlossen!? Und hier kommen wir in eine Grau-Zone, welches Missverständnisse zwischen Auftragnehmer und Auftraggeber nur so sprudeln lässt.
Nach meinem Ansatz sind mit dem Start der Entwicklung / Installierung der Software 2 Prozesse gestartet. Wichtig ist, dass auch Prozesse einmal Zz Ende gehen können, wenn Sie nicht mehr gebraucht werden, aber dazu später mehr, denn das Thema „Abschluss“ ist zu wichtig um in einem Nebensatz behandelt zu werden.
Der erste Prozess – Betrieb der Plattform
Sobald der erste Termin in der Datenbank gespeichert wurde müssen die Prozesse greifen: Benachrichtigung des Kundenbetreuers, Löschen des Termins nach einer bestimmten Zeit, Aktualisierung von Statistiken / Reportings usw.
Der zweite Prozess – Weiterentwicklung
Gehen wir davon aus, der erste Step, die erste Entwicklungsstufe des Tools ist abgeschlossen und live. Basis-Funktionalitäten funktionieren. Doch die Wunschliste des Kunden ist lang und erst im Alltag werden noch viel mehr wünsche dazu kommen. Zum Beispiel die automatische Übertragung der Termine auf den Exchange der Kundenberater oder die individuelle Gestaltung der GUI mit dem Corporate Design des Auftraggebers.
Wie bekomme ich jetzt all die Wünsche in die Plattform? Neues Projekt? Ja, dass wäre ein Ansatz, jedoch muss auch hier direkt beachtet werden, zu Beginn des Projektes werden meistens wieder nicht alle Wünsche vollständig definiert sein. Somit baut sich wieder ein neues Backlog auf. Das muss alles warten bis das zweite Projekt abgeschlossen wurde und erst dann kann das neue Projekt gestartet werden. Mehr als ungünstig Vorallem wenn dringende Wünsche oder sogar Pflichten (Gesetze, Datenschutz-Themen) dazwischen kommen.
Also gehen wir wieder zurück zum Prozess und machen eine regelmäßige Entwicklung daraus mit kleineren Teilprojekten/Aufgaben. Der Kunde stellt eine Anfrage auf die Dinge die er haben will und wir erzählen ihm welche Auswirkungen das hat. Und anschließend erfolgt die Umsetzung. So bekommt der Kunde für jede Anforderung oder Wunsch ein direktes Feedback und versteht die Auswirkungen.
Wenn jetzt einer schreit: „Ja das ist doch ganz klar agile Entwicklung“…… Klappe halten, hinsetzen und weiterlesen. Die Beschreibung hat erstmal noch nichts mit agiler Entwicklung zu tun, denn es ist überhaupt nicht klar, ob der Kunde ein feste Budget hat und nach dem Maximalprinzip handelt oder er Minimale Anforderungen erstmal fertig haben möchte und anschließend guckt, welche Features er noch benötigt, denn ich 90% Fälle wissen die Kunden nicht was Sie im Endeffekt haben wollen. Schon gar nicht in der IT. Dieser Sachverhalt ist auch übrigens das größte Problem der Industrie in Verbindung mit IT-Aufträgen, aber auch dazu später mehr.
Zusammenfassung
Ich möchte euch klar machen, dass die Definition eines Projektes wohl überlegt seien sollte.
Mich stört zum Beispiel an dem Wort „Projekt“ ein Fakt der in jedem Management / Leitung – Buch zur Definition eines „Projektes“ gehört. Und zwar das ein Projekt ein sogenanntes „Ende“ hat. In der IT ist diese Aussage sehr selten zutreffend! Das muss gerade in die Köpfe der Kunden/Auftraggeber. Siehe Beispiel oben. Und das ist sehr triviales Projekt.
Das beste Beispiel ist hierbei die Software-Entwicklung. Wenn ich dort Anfange eine neue Software ins Leben zu rufen, dann benötigt diese Software dauerhaft Pflege. Denn wenn Software dies nicht erfährt, ist die bald tatsächlich am Ende. Moderne Unternehmen wissen um diesen Sachverhalt und große Software-Projekte starten mit dem Wissen „Dieses Stück Software hat eine begrenzte Lebensdauer“. Und das ist auch gut so. Ich nehme hier gerne das Beispiel der Android-Plattform. Eine Entwicklung eines großen und umfassenden Systems, welches durch den Wettbewerb dazu verdammt ist, sich ständig weiterzuentwickeln und neue Funktionen den Usern zur Verfügung zu stellen. Auf der anderen Seite steht die Pflege der Software im Bereich Sicherheit. Eine solches System ist ständigen Angriffen ausgesetzt und die Hacker heutzutage sind sehr einfallsreich.
Wie schafft es also Google dieses Projekt „Android“ so gut am leben zu erhalten. Es wird einfach nicht als „Projekt“ angesehen. Sondern verschiedene Stufen (Versionsnummer) stellen die Projekte dar. Diese haben einen Lebenszyklus und werden von vornherein so kreiert, dass Sie durch den Nachfolger abgelöst werden können und anschließend wieder nahezu vollständig von der Bildfläche verschwinden. Und hier ziehe ich gerne wieder den Vergleich zu Produkten anderer Branchen Heran. Ein Auto hat auch eine gewisse Lebensdauer und verschwindet dann irgendwann in der Schrottpresse und die Branche versteht das.
Was bedeutet dies also für uns Führungskräfte in der IT in Bezug auf Projekte. Zunächst sollte sich bei jeder Aufgabe / Email / Anfrage die Frage gestellt werden: Was habe ich da vor mir? Ein neues Projekt? Ein Prozess? Eine Frage? Und ganz wichtig, unter was versteht meine Gegenseite das ganze? Denn nur so kann ich Missverständnisse vermeiden. Ich muss mich in meinen Gegenüber reindenken und seinen Blickwinkel zu dem jeweiligen Thema erkennen/verstehen. Erst wenn ich das habe und mir dafür die Bestätigung eingeholt habe, kann ich das Thema so steuern wie ich es für richtig halte und wie es natürlich meistens am sinnvollsten ist für den Kunden und mich 🙂
Über die Blickwinkel und wie ich diese erkenne und Bestätigen lasse, gehe ich in den jeweiligen folgenden Kapiteln näher ein.
Bleiben wir bei dem Thema „Projekt“. Ich würde es gerne für die folgenden Zeile umtaufen wollen zu dem Wort „Thematik“. Und zwar beschreibe ich damit verschiedene Anforderungen die an eine Führungskraft in der IT gestellt werden und wie ich verschiedene Blickwinkel zu den Thematiken entwickeln kann. Für mich gibt es dazu die folgenden Thematiken in der IT:
- Angebote individuell
- Angebote Produkt
- Aufträge
- öffentliche Anfragen
- Emails/Telefonate(immer schriftlich bestätigen lassen)