Über Leads und Heroes

Hilfe! Wir brauchen einen Wissensträger!

Viele Firmen verfügen inzwischen über einen Ansatz für den Aufbau von Wissen in neuen und sich wandelnden Themenbereichen.  Das Consulting kennt sie als Lead, die IT-Buden nennen es Hero. Microsoft nennt diese Menschen Evangelists. Allein gemein ist die Idee. Wir schaffen eine Position, die Wissen schafft, geeignete Methoden entwickelt und in diese dann in die Breite trägt.

Nun klingt diese Stellenbeschreibung doch etwas diffus. Und leider ist es meistens auch genau das. Es ist schwer zu sagen was alles Teil dieser Stelle ist. Muss er die Technologie sicher beherrschen? Muss er alle Neuerungen auf dem Themengebiet kennen? Muss er die Entscheidung treffen, wohin sich die Firma auf seinem Gebiet entwickelt und auf welchen Aspekt der Technologie sie sich konzentriert? Muss er die Kollegen schulen? Muss er gleichzeitig noch Umsatz in Projekten bringen?

Wir sehen schon an diesen wenigen, spontanen Fragen, dass wir hier im Prinzip sowohl einen erfahrenen Projektmitarbeiter, einen technischen Manager, einen Mentor, einen Trainer, einen Strategen und einen Fachexperten suchen. Wenn wir diese Fragen alle mit einer Person abdecken wollen, wird es wohl nur sehr, sehr wenige Menschen geben, die diesem Profil entsprechen.

Drei Säulen der Verantwortung

Und was könnte der Ausweg sein? Nun, das ist nicht leicht zu sagen und hängt auch sehr stark an der Ausrichtung und der Kultur des Unternehmens. Ich sehe die Führungskultur zunächst einmal dreigeteilt. Die erste Ebene ist die Mitarbeiterführung. Also das klassische Linienmanagement. Nennen wir sie Managing Consultants.

Als zweite Ebene würde ich die Fachbereichsleitung sehen. Also die Manager, die entscheiden in welche Richtiung der jeweilige Fachbereich entwickelt wird. Müssen die Entwickler also ehr Frontend-Technologien aufbauen oder doch im Backend? Wer hat das Potenzial und das Interesse die jeweilige Technik zu erlernen und zu vertiefen? Und das Ganze unabhängig der eigentlichen Linienorganisation. Ich kenne hierfür den Begriff Principal Consultant als höchste Instanz für die Weiterentwicklung.

Als drittes Standbein sind dann genau diese Experten zu sehen. Leute, die sich sehr tief mit einer Technik oder Materie beschäftigt haben und dort das Wissen in die Breite tragen und als Eskalationsinstanz und Retter in der Not fungieren, wenn etwas auf technologische Schwierigkeiten stößt. Hier findet sich der Hero oder auch Lead Consultant/Developer/etc.

Wie kann das gestaltet werden?

Was genau soll den nun dieser Experte tun? Oder wie kann ein Fachverantwortlicher sich Rückhalt für seine Technologieentscheidung schaffen? Schließlich hemmt es jeden Fortschritt, wenn sich in der eigenen Firma plötzlich zwei Lager bilden. Nun, ich persönlich favorisiere hierfür Führungskonzepte, wie sie für Agile Teams entwickelt wurden. Hier die für mich wichtigsten Punkte:

Feedbackkultur stärken und fest in Projektabläufe integrieren

Ja super. Die alte Leier. Aber was ist gemeint? Nur wenn wir die Gelegenheiten nutzen und am Ende eines Sprints, eines erfolgreichen Projektes, oder bei einer besonderen Situation – z.B. ein Vortrag – positives Feedback äußern, entsteht Vertrauen in die Mangementstruktur und auch Selbstvertrauen.  Dieser Vertrauensvorschuss ist notwendig um bei Fehlschlägen konstrutive Kritik zu äußern und vor allem eine Diskussion zwischen den Beteiligten zu entfachen. Aus Fehlschlägen entstehen neue Möglichkeiten und aus der Diskussion können kreative Ideen und neue Lösungswege entstehen. Außerdem kann der Verantwortliche hier Werbung für sein neues Konzept, seine neue Technologie oder was auch immer machen. Wie hätte er die Situation anders gehandhabt, bzw. was hat er gelernt und was würde er gerne im nächsten Projekt anders versuchen. Genau aus diesen Impulsen entsteht Veränderung und die Akzeptanz der Gruppe.

Konkrete und verblindliche Aussagen

Dieser Punkt gehört zum ersten. Es geht nicht nur darum konstruktives Feedback zu geben, sondern auch in Antworten eine Verbindlichkeit und Verlässlichkeit zu schaffen. Lasst uns in dem nächsten Sprint XY verändern. Und am Ende des Sprints möchte ich eine Auswertung und Einschätzung von jedem über die Maßnahme. Wenn es euch nicht gefällt, werden wir daran feilen. Wenn ihr es ablehnt, suchen wir einen anderen Weg. Das ist konkret, messbar und verlässlich. Diese Aussagen schaffen Vertrauen und ebnen den Weg für den dritten Punkt.

Aus Ideen werden Herausforderungen und Ziele

Hat man sein Team, seine Kollegen oder wen auch immer erst einmal soweit, dass sie bereit sind das neue Konzept zu probieren, so muss man dies auch ganz konkret ausdefinieren. Mitarbeiter A wird versuchen den Workflow über die neue Technologie zu entwickeln. Wir notieren die Aufwände und klassifizieren sie nach Erstaufwänden und wirklicher Arbeitszeit. Außerdem gibt dieser dann am Ende des Workflows eine kleine Demonstration sowohl von der fertigen Komponente als auch der eingesetzen Technologie. Und damit die Motivation erhalten bleibt, wird er die Aufgabe mit Mitarbeiter B machen und diese werden sich dabei austauschen und vorantreiben. Wir geben den Mitarbeitern also die Verantwortung und setzen das Vertrauen darauf, dass sie die Aufgabe lösen. Zugleich möchten wir über ein Erfassungssystem kontrollieren können, welche Aufgaben konkret welche Zeiten benötigt haben. Nicht, weil wir die Mitarbeiter gängeln wollen, sondern um zu ermitteln, ob diese Technologie konkurrenzfähig ist. Dies kann man auch soweit treiben, dass beide Kollegen anonym ihre Zeiten auf das gleiche Modul erfassen (z.B. mit Excel). Schließlich wollen wir verhindern, dass die Mitarbeiter absichtlich weniger Zeit eintragen um nicht schlecht da zu stehen. Hier werden die Themen Vertrauen und Selbstvertrauen zum ersten Mal auf eine echte Belastung gestellt. Und dies erfordert eine saubere Feedbackkultur, bei der keiner Angst vor den Resultaten hat.

Vertrauenswürdigkeit und eine positive Einstellung

Wichtig ist zu verstehen, was der Manager/Experte in seiner Position darstellt. Er ist die Referenz auf seinem Gebiet oder der Entscheider. Eine Person, die Respekt verdient und an der man sich orientiert. Von daher ist es hier auch essentiell, dass man für eine Kollegen ein offenes Ohr hat, die Probleme vertraulich behandelt und mit ihnen gemeinsam eine Lösung findet. Aufgaben, die übrigens auch einiges an Zeit veranschlagen werden und entsprechend in der Auslastung berücksichtigt werden sollten. Ganz wichtig ist, dass dieser Kollege die Lust auf das neue ausstrahlen muss. Das er motivieren muss. Eine positive Einstellung desjenigen der das Thema treibt, wirkt sich unmittelbar auf die Gruppe aus. Und natürlich muss er die Leute auch dann noch mitreißen können, wenn etwas nicht gelaufen ist wie es soll. Zumindest dann, wenn es die grundsätzliche Entscheidung nicht infrage stellt.

Entscheidungen treffen

Das führt zum nächsten Punkt. Ist eine Technologie oder Methode einmal erroriert, darf der Verantwortliche auch nicht davor zurückschrecken eine Entscheidung zu treffen. Dies ist besonders dann schlimm, wenn seine Idee sich als unwirksam oder zu kostenaufwendig herausstellt. Selbst dann, wenn die Kollegen vielleicht für die neue Idee begeistern, sie aber einfach unwirtschaftlich ist. Wichtig ist hier wieder, klar zu kommunizieren und die Gründe offenzulegen. Das zuvor aufgebaute Vertrauen ist dabei wieder ein maßgeblicher Faktor.

Hinterfragen des Status Quo

Eigentlich selbstverständlich für uns, aber hier der Vollständigkeit halber aufgeführt. Man sollte sich natürlich nie auf den Erfolgen ausruhen und immer auch ein Auge darauf haben, was künftig kommt um somit gewappnet zu sein. Bspw. wurden in den letzten Jahren viele Firmen von O365 und dem App-Modell überrascht und sind bis heute nicht wirklich dafür aufgestellt.

Vorbildfunktion

Auch das sollte natürlich selbstverständlich sein. Ein Verantwortlicher sollte immer gut sichtbar und offen eine Vorbildfunktion erfüllen, Entscheidungen in die Breite tragen und dafür auch einstehen. Ein Verantwortlicher sollte sich so verhalten, wie er es auch von den Kollegen in seinem Verantwortungsbereich erwartet.

Erfolge sichtbar machen

Und wenn schließlich eine neue Technologie oder Methode eingeführt wurde kommt das Sahnehäubchen. Die neue Kompetenz und die neuen Fähigkeiten des Teams sichtbar machen. Hier ist alles vertreten. Von internen und externen Vorträgen, von Dokumentationen und Trainings, von Success-Stories oder neuem Marketing-Material. Besonders wenn es um neue Technologien oder Methoden geht, die einen von der Masse abhebt, gilt es nun dieses Expertenwissen zu versilbern. Auch dies ist natürlich die Aufgabe des Verantwortlichen.

Projektsteckbrief

Oft wird man gefragt, ob man nicht mal schnell dies oder das übernehmen kann. Oder – im Falle eines Managers – ob man nicht jemanden für dies oder jenes parat hat. Ruck-Zuck entsteht ein Hin- und hergeschreibe, bei dem die Details geklärt werden und es geht schnell mal eine halbe Stunde oder mehr ins Land, bevor überhaupt das wesentliche geklärt ist. Klar, man könnte einfach den Höhrer in die Hand nehmen und anrufen. Aber in der Regel wird geschrieben.

Damit solche Eskapaden reduziert werden, habe ich ein Tool übernommen, was mein alter Chef gerne eingesetzt hat. Wobei Tool schon zuviel gesagt ist. Ein kleiner Steckbrief für Projekte, damit man schnell eine Übersicht bekommt.

Der Steckbrief

Projektname: (Gib dem Kind einen Namen. Im Idealfall ist die Projektablage auch unter dem Namen zu finden)

Projektbeschreibung: (Beschreibe das Thema und mit 2-3 Sätzen.)

Projektleiter: (Wer ist bei uns Hauptverantwortlicher?)

Kunde: (Wer will dieses Projekt. Im Idealfall Kunde und Abteilung)

Ansprechpartner: (Wer ist beim Kunden verantwortlich)

Aufwand: (Wie groß wird das Ganze voraussichtlich. Eine Range reicht auch aus [z.B. 50-100 PT])

Benötigte Rollen: (Entwicklung, Testmanagement, Architektur, Infrastruktur, Suche, UI, UX …)

Technologien und Fähigkeien: (SharePoint 2007, O365, Clientside Development, Serverside Development, AnguarJS, Taxonomy Termstores, Projektmanagement etc…)

Diese Fragen sind aus meiner Sicht schnell beantwortet und geben einen guten ersten Eindruck von einem Projekt. Außerdem können Sie für ein Projektstammblatt verwendet werden und machen Themen vergleichbar.

Die 7 W-Fragen im Anforderungsmanagement

Nachdem es nun einige Zeit ruhig war auf meinem Blog, melde ich mich nun wieder mit einem Evergreen für Softwareprojekte zurück.

Hintergründe der Kundenanforderung

Der Kunde hat eine Idee. Er hat einen Bedarf für eine neue Softwarelösung erkannt oder möchte eine bestehende Software ablösen. Z.B. weil die Lizenzen für die aktuelle Version auslaufen oder die Plattform als ganzes abgeschafft werden soll.

Je nachdem woher er kommt fallen beide Szenarien schon einmal unterschiedlich aus. Hat der Kunde nur eine diffuse Vorstellung wie „Ich würde gerne meine Personalplanung und Urlaubsverwaltung automatisieren.“,  dann ist er in der eigentlichen Umsetzung noch nicht festgelegt und muss hier ggf. sogar Stück für Stück an die technologische Plattform mit ihren Möglichkeiten und Grenzen herangeführt werden.

Möglichkeit Zwei ist, dass er diese Software bereits kennt und nutzt. Er würde allerdings gerne eine neue, moderne Umsetzung haben. Entweder, weil die alte Plattform strategisch abgelöst wird, oder weil er selbst von der alten genervt ist. Im Fall einer strategischen Entscheidung ist dies wiederum schwieriger, da er eventuell gar nicht wechseln will und man zusätzlich noch gegen Widerstände ankämpfen muss. Möchte er selbst den Wechsel, fällt auch die Beratung leichter. In beiden Fällen ist die Situation hier, dass der Kunde bereits seine Software kennt und er entsprechende Vorstellungen und Erwarutungshaltungen hat. Er wird davon ausgehen, dass die neue Applikation im Prinzip ein besserer Klon der Altsoftware ist. Besser deshalb, weil er ja jetzt die Möglichkeit hat, neue Funktionalitäten einbauen zu lassen, die er schon immer haben wollte.

Doch selbst bei einem Neusystem wird der Kunde nicht unvoreingenommen an die Sache herangehen. So wird er heutzutage natürlich mit einem Smartphone arbeiten und kennt die schicken – oder auch mal weniger gelungenen – Apps aus dem jeweiligen Store. Vielleicht ist er sogar ein Apple-User und ist es entsprechend gewohnt alles möglichst unkompliziert zu haben. Ein guter Vorsatz. Allerdings ist eine Vereinfachung oft schwerer zu erreichen als alles zu übernehmen. Und das bedeutet entsprechende Mehrkosten.

Was die W-Fragen sind und ihr Mehrwert

Und schon sind wir voll im Thema. Wie bringen wir die Anforderungen des Kunden zu Papier? Wie unterscheiden wir „Must Have“ von „Nice To Have“? Wie bringen wir die Designanforderungen des Kunden und die User Experience im Preis unter? Was ist überhaupt der Preis / Aufwand den wir dafür aufrufen können und sollten? Und ist unser Ansprechpartner denn eigentlich die richtige Ansprechperson für das Thema?

Für genau diese Themen entlehnen wir eine Technik, die bereits vielerorts eingesetzt wird und sich über viele Jahre bewährt hat. Wer bereits einmal die Rettungsdienste angerufen hat, oder von seinen Eltern darüber aufgeklärt wurde, dem werden die W Fragen ein Begriff sein. „Was ist passiert?  Wo ist es passiert? Wie viele Verletzte gibt es? Wer war beteiligt?“ Später wird man dann noch fragen, „Wie ist es passiert? Was war der Auslöser“ etc. Wir sehen, die W-Fragen sind eine effektive Methode schnell an zielgerichtete Informationen zu gelangen. Eine Technik, die übrigens auch im Journalismus oftmals erfolgreich eingesetzt wird. Wenn es also für die Experten der Informationsbeschaffung und Verarbeitung hilfreich ist, wieso dann nicht auch für unsere Anforderungsanalyse?

Diese Technik liegt übrigens auch den User Stories zugrunde, ist dort allerdings weniger detailliert.
„Als <ROLLE> möchte ich <ANFORDERUNG> um zu erreichen, dass <NUTZEN>„.
Dahinter stecken die Fragen Wer, Was und Warum. Diese 3 Fragen bilden auch tatsächlich den Kern unseres Modells. Doch sind sie meist nur ausreichend, wenn es bereits ausreichend Fachwissen gibt und der Projektleiter / Anforderungsmanager / Entwickler weiß, wie er das im Interesse des Kunden umsetzen kann, sodass es sich harmonisch in das Gesamtbild einfügt. Vielleicht kennt der neue Benutzer die Standardfunktionen meiner Plattform oder vielleicht erwartet er eine App. Wie wichtig ist ein stimmiges Design? Ist es für intern oder extern? Diese Fragen werden in einer User Story  nicht oder nur zufällig erfasst und umrissen. Meist benötigt man dennoch ein Rahmenwerk, welches die Umgebungsparameter erfasst und definiert. Genau hier greift das Modell der W-Fragen und erweitert die User Stories und reichert sie mit weiteren Infromationen an.

Die W-Fragen im Detail

Nun aber genug Geplänkel. Welche W-Fragen wollen wir nutzen und was erreichen wir dadurch? Fangen wir mit den Klassikern der User Story an.

Was möchten Sie tun?
Hier geht es darum den konkreten Anwendungsfall zu beschreiben. Der Kunde wird etwas sagen wie „Ich möchte einen Knopf zum Drucken haben.“ Damit ist in diesem einfachen Fall zwar impliziert was er möchte, doch es ist keine Antwort auf die Frage, was er tun möchte. Er hätte auch antworten können „Ich möchte das Gelbe Formular„. Möchte er wirklich das Formular? Oder ist damit nicht etwas anderes impliziert? Hier gilt es nachzufragen. Was genau möchten Sie tun? Oder um zur Zweiten Frage zu kommen:

Wozu möchten Sie das?
Die Frage bezieht sich auf das Was. Wir versuchen damit den Kunden zum Nachdenken anzuregen. Wozu möchten Sie das Gelbe Formular? Wir fragen hier also nach dem Zweck. Im Fall wird herauskommen, dass er eigentlich einen Passierschein A38 benötigt um eine andere Aufgabe zu lösen. Diese Aufgabe hat eine Abhängigkeit zu unserer aktuellen User Story. Aha!

Das Gleiche hätte auch beim Drucken herauskommen können. Wozu genau möchten Sie das Dokument ausdrucken? Vielleicht möchte er es archivieren oder genehmigen lassen? In beiden Fällen könnte man auch eine papierlose Alternative anbieten, welche den Prozess innerhalb der Software hält. Nur, weil er es bisher so gemacht hat, heißt das ja nicht, dass dies auch für die aktuelle Lösung der beste Weg ist. Wir sehen, schon diese beiden Fragen bringen uns wesentlich näher an das eigentliche Geschehen.

Wer tut das?
Die nächste Frage ist wieder ein Klassiker. Wer ist die handelnde Person oder Gruppe? Ist es der Manager? Oder ist es vielleicht ein Mitarbeiter im Außendienst? Vielleicht sogar ein Externer? Die Definition der Person bringt uns auch direkt die besonderen Eigenschaften des Handelnden. Der Manager ist also der Linienvorgesetzt. Sehr gut, damit kann man vielleicht schon etwas automatisieren. Der Außendienstmitarbeiter hat keinen direkten VPN Zugang, sondern muss sich Anmelden. Dann wissen wir, dass wir eine entsprechende offene Schnittstelle nach Außen brauchen. Ggf. sogar mit entsprechenden Sicherheitsmaßnahmen. Die nächste Frage schließt sich daran an.

Wie tut er das?
Was beim Außendienstler vielleicht noch intuitiv erfasst werden kann, gibt durch die Frage nach dem Wie Gewissheit. Der Außendienstler macht das beispielsweise über sein Smartphone. Entsprechend brauchen wir also eine Webseite, die mit der Darstellung auf dem Handy kompatibel ist. Oder er benötigt sogar eine App, damit gewisse Sicherheitsmechanismen auf dem Firmengerät umgesetzt werden können.

Wann passiert das?
Diese Frage gibt Rückschlüsse auf Abhängigkeiten und eventuelle wiederkehrende Ereignisse. Das Drucken der Seite passiert, wenn die Genehmigung über den digitalen Weg fehlgeschlagen ist. Ah! Das ist interessant. Hier kann man direkt die anderen Fragen wieder aufgreifen. Wieso ist es fehlgeschlagen, wie kann man es umgehen, etc. Aber in diesem Fall ergibt sich, dass es sich um einen digitalen Archivierungsprozess handelt und wenn dieser nicht funktioniert, gibt es die Handlungsanweisung das Dokument auf Papier auszudrucken und abzuheften. Eine Lösung könnte sein, dass wir das Wann verändern. Wenn der Archivierungsdienst fehlschlägt, weil er z.B. gerade gewartet wird, dann versuchen wir es nach X Minuten/Stunden erneut.

Wo passiert das?
Die Frage nach dem Ort kann wieder vielschichtig sein. An welcher Stelle soll dieser Druckknopf sein? Gibt es eventuell eine Bedingung dafür? „Wenn das Archivieren fehlgeschlagen ist, dann soll der Knopf oben Rechts erscheinen“ Oder viel plastischer, wo soll denn ausgedruckt werden? Wieder aha! Es gibt also einen Drucker in einem speziell gesicherten Archivierungsraum, in dem diese Dokumente zwischengelagert werden. Und dieser ist nur über eine ganz spezielle Schnittstelle erreichbar. Gut, wieder etwas, dass wir berücksichtigen müssen.

Wieso machen Sie es so?
Und schließlich die Ketzerfrage. Wieso gerade so? Gibt es einen zwingenden Grund dafür? Oder könnten wir es eventuell smarter gestalten? Wieso möchten Sie umbedingt, dass das Dokument per sofort und sicher archiviert ist? Vielleicht kommt heraus, dass alle paar Minuten ein Lösch-Job über fertige Dokumente läuft, da es hierfür eine gewisse rechtliche Anforderung gibt? Wäre es dann aber nicht viel sicherer, wenn der Lösch-Job den Status „Archiviert“ abfragt? Und wenn das archivieren fehlschlägt, könnte er das Dokument in einen geschützten, Bereich verschieben, auf dem es keiner einsehen kann. Dieser ist zwar kein Archiv im rechtlichen Sinne, kann jedoch als Zwischenstation genutzt werden, bis die Archivschnittstelle wieder läuft. Vielleicht ist es ja sogar sinnvoll, eine zweite, unabhängige Archivierungsfunktion zu nutzen, die in dasselbe Archiv geht? Wenn die Anforderung ein PDF-A an Ort X ist, dann könnte das ja auch durch eine andere Software bewerkstelligt werden, sofern die erste in Wartung ist. Oder wie wäre es mit zwei unabhängigen Servern, die den Dienst betreiben und nacheinander gewartet werden?

Zusammenfassung und Fazit

Wir sehen bereits anhand dieses einfachen Beispiels, welche Macht und welcher Nutzen in den W-Fragen steckt, und wie sie die User Story erweitern. In unserem Beispiel war die User Story „Als Außendienstmitarbeiter möchte ich etwas drucken können, um die Daten immer sicher abzulegen.“ Aus dieser Story haben wir durch die 7 Fragen, die natürlich auch mehrfach und mit unterschiedlicher Formulierung genutzt werden, sehr viel mehr herausgeholt. Wir wissen, es geht darum, dass ein Dokument immer verlustsicher vor einem Lösch-Job archiviert werden muss. Dieser Job ist wichtig, damit kein anderer auf dieses Dokument zugreifen kann, da es sich um eine rechtliche Anforderung handelt. Der Außendienstler muss in der Lage sein dieses Dokument auch von außen über sein Smartphone zu archivieren. Entsprechend benötigen wir eine Schnittstelle, die noch dazu abgesichert sein muss, da das Formular ja nicht in fremde Hände geraten darf. Und schließlich haben wir noch das bewährte Vorgehen hinterfragt und eine Alternative zum Ausdrucken angeboten, die nun vom Kunden bewertet wird.

Natürlich ist diese Arbeit sehr aufwendig. Wenn wir sie für jede einzelne User Story durchführen, haben wir alleine in der Anforderungsermittlung sehr viel zu tun. Doch es lohnt sich. Denn je klarer eine Anforderung ist, desto genauer können wir abschätzen, was eigentlich zu tun ist. Was dem Kunden hier wirklich wichtig ist und wo wir vielleicht nur Schleifen am Nachthemd haben. Wenn wir diesen kritischen Pfad einer Anforderung ermitteln, können wir auch leichter die Umsetzungszeit, die Testaufwände (gemessen auch an der Kritikalität) und damit schlussendlich die Kosten ermitteln. Außerdem können wir dem Kunden genau erklären was wir vorhaben und wie die Kosten zustande kommen. Die Glaskugel, mit der wir Aufwände abschätzen wird damit um vieles klarer und das Risiko für beide Seiten kleiner. Die Tiefe der Fragen und die Zeit, die wir dafür aufwenden, hängen dann natürlich wieder davon ab, wie kritisch das jeweilige Thema ist und wie der Rahmen für das Gesamtprojekt ist.

Projekte in der Krise VI

Die Übernahme von internen Fremdprojekten

Nachdem wir uns im letzten Beitrag damit beschäftigt haben, was alles bei externen Fremdprojekten schiefgehen kann, kommen wir nun zu den internen. Wo der Unterschied ist? Nun, zum einen sind die Kollegen meist noch greifbar. Zum anderen spielt hier aber auch ein gutes Stück Politik mit hinein und die Gefahr einem Kollegen auf die Füße zu treten.

Das Szenario

Gehen wir von folgendem Szenario aus. Eine Abteilung innerhalb des Unternehmens hat seit einigen Jahren bereits einen SharePoint im Einsatz. Es gibt jemanden, der sich recht gut damit auskennt. Das meiste hat er sich autodidaktisch beigebracht und auch für viele Probleme seiner Kollegen eine schnelle Lösung gefunden. Nicht immer ganz sauber, aber immer so, dass es weitergeholfen hat. Nun ist er jedoch an einem Punkt angelangt, indem die weitere Pflege dieser Plattform sich zeitlich nicht mehr mit seinen anderen Aufgaben vereinbaren lässt. Also soll die Site Collection (sprich die Webseite, auf der die Lösung betrieben wird) nun in die Obhut der internen IT übergeben werden. Wir als externe Consultants werden genau von dieser IT-Abteilung als Ratgeber mit dazu gezogen.

Die Herausforderung

Nun beginnt die eigentliche Aufgabe. Denn oft sind solche Projekte nur sehr schwer zu administrieren und zu erweitern. Wieso? Nunja, derjenige, der bisher den SharePoint erweitert und die Änderungen vorgenommen hat war kein IT-Spezialist, sondern ist in diese Rolle hineingewachsen. Für unser Beispiel war es ein Mitarbeiter der Buchhaltung und hat kleinere Tools und Lösungen für ebenjene Abteilung erstellt. Das Problem dabei ist jedoch, dass ihm damit auch das Handwerkszeug eines IT-Spezialisten fehlt. Das bedeutet, dass in der Regel alle Änderungen „mal schnell“ durchgeführt wurden und damit nichts dokumentiert wurde. Es gibt also keine Architekturübersicht, Anforderungsdokumente, Änderungshistorie oder dergleichen. Alles, was man vermutlich hat sind ein paar Änderungswünsche oder Fehlerbeschreibungen von der Abteilung.

Gut, immerhin ist der Kollege, der das Tool erstellt hat, noch verfügbar. Doch er hat diese Anwendung über Jahre erstellt und weiß selbst nicht mehr genau, wo er was nun gemacht hat. Das war ja schließlich auch der Grund wieso er es letztlich abgegeben hat. Denn all dies wird ihm zu viel und es würde die Abteilung inzwischen billiger kommen, wenn es durch den IT-Support betreut wird, als wenn man einen weiteren Kollegen ausschließlich für diese Seite beschäftigen würde. Das Problem des Beraters und der IT-Abteilung hier ist offensichtlich. Man muss versuchen möglichst viel Informationen abzugreifen und durch möglichst gezielte Fragen der Erinnerung des Abteilungskollegen auf die Sprünge helfen. Doch man sollte unter allen Umständen vermeiden den Kollegen zu sehr vor den Kopf zu stoßen oder seine Arbeit zu hart zu kritisieren. Das würde für Verdruss auf beiden Seiten sorgen und im Notfall zieht der Kollege die Reißleine und beschränkt seine Zusammenarbeit nur noch auf das Nötigste

Die Herangehensweise

Tatsächlich weiß der Kollege in der Regel selbst, dass er hier nicht das Gelbe vom Ei produziert hat. Schließlich kommt er selbst nicht mehr damit zurecht. Daher sollte man versuchen eine positive Art zu dem Kollegen zu finden. Ja, das Projekt ist nicht gut, aber die Aufgabe ist nun einmal gestellt und nun gilt es erst einmal eine Bestandsaufnahme zu machen. Anschließend muss man dann entscheiden wie es weitergeht. Wichtig ist vor allem, dass man hier nicht in schlechte Stimmung verfällt. Nur allzu leicht kann dies passieren, wenn man das Projekt zu nah an sich heran lässt oder es mit dem gewohnten Maßstab vergleicht. Entscheidend ist tatsächlich hier, dass man sich klar macht, dass es ein Hobbyprojekt war und der Kollege es gut gemeint hat. Nur mit dieser Einstellung kann man ein solches Projekt stemmen ohne sich selbst zu verschleißen.

Okay, wir gehen also positiv an die Sache heran (Tschakka!). Also machen wir als erstes mal eine Bestandsaufnahme um herauszufinden was überhaupt möglich ist. Welche Version ist im Einsatz, welche Features sind aktiviert, welche Third-Party-Tools finden Verwendung und wo hatte der Kollege welche Rechte. Mit diesen Fragen lässt sich das Tätigkeitsfeld erst einmal einschränken. Anschließend schauen wir uns die Probleme an, die mit der Anwendung gemeldet wurden. All diese Informationen erfassen wir jetzt natürlich sauber in unsere ALM Tool (z.B. dem TFS oder VSTS), damit die Erkenntnisse künftig sauber dokumentiert an einem Ort abgelegt sind.

Nachdem wir nun das Gefühl haben, dass wir zumindest die Rahmenparameter kennen und uns auch die Anwendung schon einmal angeschaut haben, reden wir mit dem Kollegen. Welche Probleme hat er mit seiner Anwendung behoben, an welche Änderungen kann er sich noch erinnern, wo sind die Knackpunkte an denen er gescheitert ist. Ich denke, in einem positiven (!) Gespräch kann man etwa 70-80 % der Applikation in Erfahrung bringen und die häufigsten Anwendungsfälle identifizieren. Natürlich schreiben wir auch hier wieder alles mit was wir erfahren und bringen es anschließend in eine geeignete Form, sodass wir auch künftig damit arbeiten können.

Gut, damit sollten wir jetzt zumindest schon einmal die wesentlichen Rahmendaten kennen. Wir wissen über die Technologie, die groben Strukturen der Applikation, die Probleme und auch über den Wissensstand des Kollegen bescheid. Daraus können wir also schon einmal herleiten, was er vermutlich getan hat und wozu er einfach nicht in der Lage war. Wenn wir dieses Wissen nun mit der Applikation und den aufgetretenen Problemen abgleichen können wir vielleicht schon das meiste identifizieren und benennen.

Die Übernahme

Der nächste Punkt ist dann der eigentlich Entscheidende. Ist das Projekt geeignet um die Probleme zu lösen, die es aktuell gibt und ist es möglich das Projekt auch in Zukunft sauber zu warten? Wenn nicht, macht es Sinn das Projekt neu aufzusetzen? Das wäre auch dann sinnvoll, wenn es ausreichend Änderungsvorschläge und Verbesserungspotenzial gibt, damit die Abteilung einen echten Mehrwert von der Weiterentwicklung hat. Gibt es dafür entsprechendes Budget und die Bereitschaft, dann ist dieser Weg zu bevorzugen. In der Regel ist es jedoch so, dass genau dieses Budget eben fehlt. Deshalb hat der Kollege ja angefangen alles in Eigenregie umzusetzen. Also was jetzt?

Die Lösung ist ähnlich wie auch bei externen Projekten. Man muss eine Kostenaufstellung machen. Dazu sollte man sich fragen, welche Laufzeit für das Projekt erwartet werden kann. Sind solche Zahlen nicht lieferbar würde ich von einer geschätzten Laufzeit von 5 Jahren ausgehen. Denn in der Regel wird eine Plattform innerhalb dieser Zeit durch ihren Nachfolger abgelöst und auch ansonsten ist der Zeitraum groß genug um zu zeigen wie groß die Initialen und die Folgekosten sind. Nun stellt man also die Initialen Kosten für die Übernahme bzw. für die Neuerstellung und den Betrieb für die nächsten Jahre gegenüber. Man nennt die Risiken bewertet diese mit Multiplikatoren. Am Ende werden 2 Zahlen herauskommen. Welche Kosten entstehen für die Übernahme bzw. Neuentwicklung des Projektes im vermuteten Zeitraum. Natürlich gibt es dort immer etwas Spielraum und die Zahlen sind nicht final. Dennoch bieten sie einen guten Einblick mit welcher Größenordnung gerechnet werden muss.

Ist diese Zahl weit jenseits der erwarteten und veranschlagten Kosten für das Projekt sollte man auch als IT-Abteilung bereit sein ein Projekt abzulehnen oder zumindest an die nächste Instanz zu eskalieren. Was passiert, wenn es zur Eskalation kommt, darüber werden wir uns in einem anderen Beitrag unterhalten.

Mehr zum Thema?

Projekt „Intranet Relaunch“ II

Die Analyse des Business Consultants

Im ersten Teil der Serie haben wir über die Ausgangssituation des Projektes „Intranet Relaunch“ geredet. Zur Erinnerung, es geht um folgendes:

Ein Unternehmen hat 300 Mitarbeiter und möchte ein ihr bestehendes Intranet ablösen. Das bestehende Intranet beinhaltet aktuell Nachrichten aus dem Konzern, eine Wissensbibliothek, ein Workflow für die Urlaubsfreigabe und eine Anwendung für die Arbeitszeiterfassung. All diese Module existieren bereits seit einigen Jahren und wurden 2011 von einem externen Dienstleister nach dem Stand der Technik mit SharePoint 2010 umgesetzt.

Wir haben festgestellt, dass 3 Experten verschiedener Fachrichtungen die Erstanalyse des Bestandssystems vornehmen werden. In diesem Beitrag beschäftigen wir uns mit der Arbeit des Business Consultants.

Was ist die Aufgabe des Business Consultants?

Der Business Consultant dient ganz allgemein gesagt der Kommunikation zwischen dem Kunden und dem Lieferanten. Er wird in der Regel durch den Lieferanten bereitgestellt und sieht seine Aufgabe darin alle notwendigen Informationen für das Projekt von den Beteiligten einzuholen und so aufzubereiten, dass sie durch die Umsetzungsexperten verwendet werden können. Der Business Consultant ist also das Ohr am Kunden und gerade in der Anfangsphase sein wichtigster Ansprechpartner.

Im Idealfall kombiniert ein Business Consultant das branchenspezifische Wissen seines Kunden mit den Kenntnissen der Technologie, auf der das Projekt umgesetzt werden soll. Außerdem verfügt er über gute analytische und soziale Fähigkeiten, sodass er durch gezieltes Nachfragen und Recherchieren beim Kunden einen möglichst genauen Einblick in die Anwendungsfälle der Anforderung bekommt.

Die Aufgabe des Business Consultants ist es nicht, sich bereits eine Lösung für die Probleme auszudenken, sondern hauptsächlich die Use Cases oder User Stories des Kunden zu ermitteln. Durch sein technologisches Wissen kann er außerdem bereits Fragen stellen, die technologietypische Szenarien aufgreifen oder bekannte Probleme abgrenzen. Außerdem kann er alternative Möglichkeiten aufzeigen, wenn eine Vorstellung des Kunden aufgrund der Technologie so nicht umsetzbar ist.

All dies geschieht natürlich nicht auf einmal, sondern der Business Consultant begleitet das Projekt von dem ersten Kontakt nach Angebotsausschreibung bis zum Konzept und der Übergabe an die Umsetzungsteams. Und oftmals begleitet der Business Consultant dann auch die Änderungswünsche und ggf. auch das Testmanagement des Projektes bis zum Abschluss des Projektes.

Die Analyse des Business Consultants

Wir haben jetzt also festgestellt, dass der Business Consultant das Ohr am Kunden ist. Und genau so wird er seine Arbeit starten. In dieser ersten Bestandsanalyse stellt sich für Ihn zunächst die Frage der Stakeholder-Struktur. Dafür muss er folgende Informationen einholen:

Wer ist die Fachseite, die das Intranet betreut?

Diese Frage ist wichtig um zu bestimmen, aus welcher Richtung die Anforderungen kommen werden und wie es um das fachliche und technische Verständnis bestellt ist.

In unserem Beispiel stellt sich heraus, dass das Marketing auch das Intranet betreibt. Sie stellen redaktionelle Inhalte bereit, organisieren Veranstaltungen und Pflegen den Inhalt in der Wissensdatenbank. Für die Arbeitszeiterfassung und Urlaubsverwaltung ist das HR noch in den Prozess eingebunden. Allerdings interessieren sich diese sich hauptsächlich für ihre Export-Funktionalität, welche die Daten aus dem SharePoint in ein Excel transferiert.

Was war der Auslöser das Intranet neu auszuschreiben?

Diese Frage ist natürlich wichtig um zu bestimmen was der größte Schmerz ist und an welcher Stelle bei der Neukonzeptionierung besondere Sorgfalt und Aufmerksamkeit geboten ist um nicht alte Probleme zu wiederholen.

In unserem Beispiel ist der größte Schmerz, dass der Support für das Intranet nicht mehr gewährleistet ist. Allerdings gibt es noch weitere nostalgische Punkte, die im Gespräch mit der Fachseite ans Licht kommen. So ist es den Redakteuren ein Dorn im Auge, dass für jeden Artikel ein Freigabeworkflow durchlaufen werden muss. Schließlich sind sie ja die Experten und immer wenn der freigebende Manager nicht da ist, liegt der Artikel möglicherweise so lange, bis das Thema schon wieder veraltet ist. Außerdem finden sie die Wissensbibliothek so nicht mehr zeitgemäß und möchten es auf Wiki mit redaktioneller Prüfung umstellen um so schneller neue Informationen zu erhalten und selbst weniger Pflegeaufwand investieren zu müssen.

Was ist die Meinung der IT-Abteilung, die das Intranet technisch wartet?

Natürlich werden in so einem Projekt auch die Experten der IT zu ihrer Meinung befragt. Schließlich ist es in der Regel diese Abteilung, welche das Projekt später betreibt und den Support dafür erbringt. Wo lagen die aktuellen Schwierigkeiten der Anwendung und wo die meisten Supportfälle? Müssen einige Prozesse vereinfacht werden? Auch diese Kollegen haben erkannt, dass eine Vertreterregelung her muss, da immer wieder administrativ eingegriffen werden musste, wenn ein Kollege im Urlaub war oder die Firma sogar ganz verlassen hat. Alle Verantwortlichen sollen künftig also nicht mehr direkt im Workflow definiert werden, sondern über eine Mappingtabelle, welche sich ohne Deployment pflegen lässt. Natürlich entsteht hier gerade ein Widerspruch mit den Aussagen der Fachseite, doch in dieser Phase kann man das getrost erst einmal aufnehmen und später eine Lösung dafür finden. Auch, dass die IT-Abteilung bereits sehr stark in Lösungen denkt und nicht in Problemen ist typisch und kann so mitgenommen werden.

Was sagen die Endnutzer zu dem Intranet?

Ein Punkt, der immer wieder gerne vergessen wird, ist die Befragung der Endnutzer. Schließlich sind sie es, die das Produkt nutzen sollen. Und wenn der Nutzer das Intranet nicht annimmt wird versuchen dem Ganzen möglichst aus dem Weg zu gehen. Etwas, das natürlich nicht im Sinne der Redakteure und der Geschäftsführung liegt, die schließlich viel Zeit und Geld in dieses Projekt investieren.

Wie also macht an so eine Endnutzerbefragung? Es gibt einige Wege, die sich bewährt haben und wenn möglich alle genutzt werden sollten. Das üblichste ist eine Mitarbeiterumfrage. Dabei wird allen Mitarbeitern des Unternehmens ein Fragebogen zugeschickt mit der Bitte diesen bis zu einem gewissen Datum zu beantworten. Natürlich sollte man an dieser Stelle auch genau erklären, welchen Einfluss sie damit auf die Entwicklung des Intranets haben. Diese Umfragen finden in der Regel anonymisiert statt, damit die Mitarbeiter keine Repressalien fürchten müssen. Dennoch sollte man die Möglichkeit einräumen sich direkt bei dem verantwortlichen Business Consultant zu melden und dort im Vertrauen einige Punkte loszuwerden. Manchmal gibt es Dinge, welche die Leute nicht schriftlich angeben wollen. In so einem Fall kann es weiterhelfen. Allerdings sollte man nicht damit rechnen, dass diesen Service allzu viele Leute in Anspruch nehmen. Doch wenn sie es tun, sind die Erkenntnisse daraus meist Gold wert.

Neben der Mitarbeiterumfrage kann man sich noch stichprobenartig direkt mit einigen Leuten unterhalten. Das können einerseits Leute sein, die man spontan in der Kantine für 15 Minuten entführt und bittet ihre Eindrücke zu schildern, oder es können Leute sein die den Betreibern des Intranets schon häufiger durch intelligente Fragen oder besondere Schwierigkeiten aufgefallen sind. Derartige Leute helfen oft gerne, da sie selbst ebenfalls ein Interesse haben, dass das Intranet verbessert wird und auch deren Erkenntnisse sind viel wert.

In unserem Beispiel zeigen die Umfragen nun hauptsächlich, dass Leute Schwierigkeiten damit haben in der Wissensbibliothek das zu finden was sie suchen. Außerdem finden sie die Anwendung für die Arbeitszeiten zu langsam und zu kompliziert. In den Kommentaren kommt heraus, dass einige Schattentabellen in Excel führen, damit sie auch später noch Auswertungen über ihre Arbeitszeit und die einzelnen Aufgaben führen können. Ein Mitarbeiter hat sogar ein recht kreatives Excel herumgeschickt, welches so viel Logik enthält, dass man es schon fast als Tool bezeichnen kann. Es ermöglicht Auswertungen über verschiedene Projekte und Zeiträume. Die Befragung ergab, dass dieses Tool in unterschiedlichsten Versionen – teilweise auch kaputt – bei vielen Kollegen eingesetzt und  und immer wieder weiter kopiert wird. Eine Entwicklung, der auf jeden Fall im neuen Intranet entgegen gewirkt und durch eine gemanagte Applikation ersetzt werden sollte. Denn in diesem Tool weiß niemand so genau ob die Zeiten auch stimmen die es ausgibt. Zumindest bei den Versionen, die noch funktionieren…

Das Ergebnis der Analyse

Nachdem der Business Consultant mit seinen Umfragen, Mitarbeiterbefragungen und der groben Anforderungsaufnahme seiner Auftraggeber fertig ist erstellt er aus all diesen Informationen ein Dokument, welches den Status Quo darstellt. Es handelt sich hierbei nicht um das Lasten- oder Pflichtenheft, sondern spiegelt lediglich die Meinung der Firma zu dem Intranet wieder. Doch diese Informationen, Anregungen, Auswertungen und Ideen helfen dabei dem Kunden vor Augen zu führen wo die Stärken und Schwächen des Systems liegen. Welche Module sind bereits gut gelöst und sollten auf jeden Fall auch im neuen System so weitergeführt werden? Wo genau liegen die Probleme der Anwender und welche technischen Herausforderungen gilt es zu meistern? Dieses Papier ist die Grundlage, auf welcher der Auftraggeber ein aussagefähiges und belastbares Lastenheft definieren kann, welches die nächste Version auch wirklich weiterbringt. Man könnte sogar sagen, dass dieses Vorgehen ein professionelles Projekt auszeichnet, denn es versucht den Nutzen für seine Anwender zu maximieren, sodass man für jeden eingesetzten Euro möglichst viel zurück bekommt.

Im nächsten Teil der Serie werden wir uns anschauen, wie ein Infrastruktur Consultant das System bewertet.

 

Angebot und Schätzung III

Im dritten Teil der Serie geht es nun darum, wie die Ressourcenplanung das Angebot und die Schätzung beeinflussen sollten. Ein Thema, was viel zu oft völlig losgelöst betrachtet wird nach dem Motto „Na, wenn die uns beauftragen, dann schauen wir mal weiter.“ Ein Thema, dass sicherlich von nicht geringer wirtschaftlicher Bedeutung ist. Doch warum das nur die eine Seite der Medaille ist, dass möchte ich heute erörtern.

Zur Erinnerung, in dieser Serie möchte ich mich mit diesen Fragen auseinander setzen:

Weitere interessante Meinungen zu diesem Thema könnt ihr außerdem hier finden:

Die Ressourcenfrage

Ein aus meiner Sicht sehr wichtiges Thema bei der Abschätzung ist, welche Ressourcen für das Projekt überhaupt in Frage kommen. Oftmals ist es so, dass das Angebot eines Projektes für einen gewissen Zeitraum gedacht ist. Das bedeutet 2 Dinge. Einmal hat das Angebot eine Gültigkeitsdauer, in der man dem Kunden zusichert, dass dieses Angebot gilt. Zum anderen gibt es einen Umsetzungszeitraum für das akquirierte Projekt, der zum Angebotszeitpunkt meist schon feststeht.

Im Idealfall schätzen ausgewiesene Experten das jeweilige Projekt. Oftmals sind es Lead Consultants oder erfahrene Senior Consultants, die genau in dieser Anfrage bereits einige Projekte umgesetzt haben und damit vertraut sind. Die Schätzung richtet sich dann nach deren Erfahrung und wird entsprechend abgeschätzt. Da man nun davon ausgeht, dass es eventuell auch ein normaler Consultant sein könnte, der vielleicht etwas weniger Erfahrung hat, wird ein gewisser Prozentsatz aufgeschlagen. Sagen wir, der normale Consultant hat lediglich 2 Projekte gemacht, während der Senior Consultant bereits 8 Projekte in diesem Bereich gemacht hat. Der Senior schlägt also großzügig 10 – 15 % auf die geschätzten Umsetzungsaufwände auf.

Und hier beginnen nun die Probleme. Denn im Angebot wir natürlich noch nicht der Weg zum Ziel beschrieben. Diese Informationen sind noch Interna und werden erst bei erfolgreichen Auftragsabschluss in ein Konzept gegossen. Sonst könnte der Kunde schließlich das Konzept nehmen und es einfach einem anderen Wettbewerber vorlegen und hätte damit schon einen Gutteil des Geldes für die Konzeption eingespart.

Jetzt gehen wir davon aus, dass das Angebot wie üblich 30 Tage oder eventuell sogar länger gültig ist. Der Ersteller der Schätzung ist inzwischen Vollzeit bei einem Kunden vor Ort und nicht für die Konzeption verfügbar. Ab und an wird er vielleicht telefonisch erreichbar sein, doch viel mehr ist einfach nicht drin. Die Kollegen, die das Konzept nun aufschreiben wundern sich über die Zahlen und versuchen daraus etwas zu stricken. Aufgrund der unterschiedlichen Vorgeschichte kommen sie auf einen anderen Lösungsansatz oder bewerten das Testmanagement und ähnliche Aspekte anders. Insgesamt wird die Zeit genau aufgebraucht, die im Angebot veranschlagt wurde. Der Puffer, den der Vorgänger eingeplant hat, wird für Extras oder schönere Lösungen aufgebraucht.

Schließlich beginnt die eigentliche Umsetzung nach der Freigabe und ein Team aus weniger erfahrenen Consultants kommt unter der Leitung eines Projektmanagers zum Einsatz. Ein Senior Consultant ist mit 2 Tagen pro Woche für Unterstützung und Architektur eingeplant. Doch schon jetzt ist klar, dass er nur wenig helfen kann, da seine Hauptaufgabe die Pflege der ALM-Tools und Planung der technischen Kapazitätsverteilung ist.

Insgesamt kann so ein Projekt immer wieder gut gehen, wenn keine groben Fehler passieren, doch es kann auch leicht ins Gegenteil umschlagen und die Marge, die man mit dem Projekt erzielen will wird aufgebraucht, sodass unter dem Strich ein Nullsummenspiel herauskommt. Kommen dann noch weitere Probleme dazu, kann es sogar zu einem Minusgeschäft werden.

Der bessere Ansatz

Der bessere Ansatz erfordert bessere Planung und ist leider oft auch nicht mit dem Alltagsgeschäft vereinbar. Es geht darum, dass der Consultant, der die Schätzung übernimmt, später auch in der entscheidenden Rolle als Lead in dem Projekt mitmacht. Das würde bedeuten, dass der Schätzer der Entwicklungsbereiche später genau diese Konzeption übernimmt und dann auch als Ansprechpartner zur Verfügung steht. Er muss nicht zwangsläufig der technische Projektleiter sein, doch er sollte zumindest 1-2 Tage die Woche für technische Rückfragen bereitstehen. Im Idealfall ist er natürlich selbst in dem Projekt. Meine jetzige Firma macht das oft ziemlich gut, indem für einen definierten Zeitraum die Personen fest zugesagt werden. Diese Festlegung auf einzelne, konkrete Personen kann natürlich nicht über Monate aufrecht erhalten werden und erfordert etwas Vorlaufzeit.

Ein Gangbarer Kompromiss wäre aus meiner Sicht, dass die Personen für einen gewissen Zeitraum – zum Beispiel 14 Tage – fest für das Projekt reserviert werden. Bestellt der Kunde innerhalb dieser Zeit, kann er fest damit rechnen, dass er auch die Experten bekommt, die ihn mit dem Konzept überzeugt haben. Wird dieser Termin überschritten, so ist das nicht mehr gegeben und der Kunde muss dafür sensibilisiert werden. Im Idealfall ist dann zumindest ein Wissenstransfer des Konzepters zu dem neuen Team möglich. Man sollte also zumindest in der Anlaufzeit den führenden Architekten einen Tag die Woche für das Projekt abbestellen können.

Fazit

Leider ist das alles etwas abstrakt und in der Praxis nie so einfach umsetzbar. Aus meiner Sicht sollte aus diesem Beitrag vor allem eins mitgenommen werden. Es ist wichtig, dass der Konzepter des Angebots auch in den späteren Phasen so gut wie möglich eingebunden wird. Wird dies nicht getan, sind gravierende Abweichungen ehr die Regel als die Ausnahme und die Schätzung vom Anfang ist nicht mehr valide.

 

Projekte in der Krise V

Übernahme von externen Fremdprojekten

Nach einem interessanten Kommentar auf meinem letzten Artikel dieser Reihe nun also der versprochene Beitrag. Was ist zu beachten, wenn man ein Projekt übernimmt, dass vorher von einem anderen Dienstleister oder von der Fachseite betreut wurde. Für beide Fälle gibt es unterschiedliche Fallsticke, die ich nun einzeln beleuchten will.

Projekte eines externen Dienstleisters

Ohje. Schon beim ersten Überblick wird es klar. Die Dokumentation ist mangelhaft, veraltet oder schlicht gar nicht vorhanden. Anforderungen wurden zumeist per E-Mail gestellt und möglichst schnell abgehandelt. Getestet hat der Kunde auf Zuruf. Der letzte Dienstleister hat das Projekt gerade so und nur mit erheblichen Mehrkosten und Zeitverzug über die Bühne bringen können. Der Kunde ist bereits stinksauer und ahnt, was er für sein Geld bekommen hat. Dennoch ist er froh, dass das Projekt jetzt abgeschlossen ist und die Anwendung läuft. Jetzt, in der zweiten Phase soll die Performance erhöht und die Stabilität und Zuverlässigkeit gesteigert werden. Im Anschluss soll die Anwendung in den Managed Service übergehen, da es sich um ein kritisches Produkt handelt.

So oder so ähnlich kann sich ein Projekt darstellen, wenn der Anbieter gewechselt werden soll. Und direkt ist anzumerken „Vorsicht!“. Denn der Kunde wechselt den Anbieter bei einem Entwicklungsprojekt erst dann, wenn er wirkliche Schmerzen hat oder ihm schlicht kein anderer Weg bleibt. Das kann sein, weil die Kosten zu hoch waren, das Vertrauensverhältnis zerstört wurde, die Ziele meilenweit verfehlt wurden oder aber auch, weil beim Dienstleister zu viele Leute das Projekt oder die Firma verlassen haben und nun ohnehin die Expertise knapp wird.

Bei solchen Projekten ist also höchste Vorsicht geboten und man muss eine große Unsicherheit in Kauf nehmen. Eine große Unsicherheit bedeutet in unserem Business nun meistens leider erhöhte Risikoaufschläge und damit erhebliche Mehrkosten für den Auftraggeber. Noch dazu ist besonders das Managed Service Thema bei solchen Projekten ein gefährliches Pflaster, da es Service Level Agreements voraussetzt und damit meistens strenge Reaktionszeiten verbunden sind. Was passiert, wenn ein kritischer Fehler in der Anwendung nicht gefunden werden kann? Welche Vertragsstrafen werden dann für den Auftragnehmer fällig? Derartige Konstrukte können einen Auftrag schnell unwirtschaftlich werden lassen oder gar Verluste einbringen.

Der Umgang mit dem Kunden

Doch nun zum Wesentlichen. Wie gehe ich mit so einem Kunden um? Wie kann ich ihn für dieses Thema sensibilisieren, dass das Projekt leider eine größere Baustelle ist, als er gehofft hat? Eventuell werden dadurch schließlich auch seine (Jahres-)Ziele über den Haufen geschmissen und er muss sich vor höherer Stelle rechtfertigen.

Mir selbst ist einmal der Fehler unterlaufen, dass wir ein Projekt zu heftig und zu früh kritisiert haben. Auch wenn wir unsere Kritik mit konkreten Beispielen untermauern konnten, war dies dennoch ein Problem. Denn das Vertrauensverhältnis des Auftraggebers zu seinem letzten Dienstleister war über das Projekt zerrüttet und der Kunde entsprechend misstrauisch. Es gelang nur unter erheblichem eigenen Einsatz das Projekt doch noch zu retten. Das führte soweit, dass es zahlreiche größere und kleinere Hilfstools für das eigentliche Programm gab um Fehler wieder zu korrigieren oder zu überprüfen.

Nun kamen wir und bereits in den ersten Tagen sahen wir, welche Qualität das Programm hatte und das es quasi unwartbar war. Doch der Kunde fühlte sich davon angegriffen und war der Meinung, dass die Reaktion überzogen wurde um mehr Budget herauszuhandeln. Tatsächlich boten wir als erstes eine Refactoring-Phase an, die allein das bereitgestellte Budget für ein Jahr Support aufgebraucht hätte. Daraufhin bügelte der Kunde diesen Vorstoß ab und war künftig auch nicht mehr bereit Aufwände für Refactoring bereitzustellen. Doch was hätten wir anders machen können?

Die Möglichkeiten

Im Prinzip bleiben bei so einem Projekt dann nur 2 Möglichkeiten. Wenn man merkt, dass das Produkt nicht wartbar ist, sollte man gegebenenfalls die bisher investierten Aufwände – selbst wenn es Presales Aufwände waren – abschreiben und das Projekt ablehnen. Natürlich kann dies zur Folge haben, dass der Kunde einen dann auch nicht für weitere Projekte beauftragt. Daher ist das eine Frage der Abwägung.

Die zweite Möglichkeit erfordert mehr Fingerspitzengefühl und sollte nur in strategisch wichtigen Projekten versucht werden. Die Gefahr, dass das Projekt dennoch nicht erfolgreich ist, oder der Kunde sich querstellt sind relativ hoch und man sollte sich einen Fehlschlag leisten können. Es ist auch wichtig, dass dieses Bewusstsein sowohl bei den Beratern vor Ort als auch beim Management gegeben ist und man diesen Schritt wirklich gehen will. In diesem Fall kann man eine ausgedehnte Analysephase voranstellen, das Produkt sauber untersuchen und eine Risikobetrachtung durchführen. Jeder Punkt, der den Beratern auffällt muss sauber katalogisiert und bewertet werden. Wichtig sind aus meiner Sicht folgende Punkte:

Wahrscheinlichkeit – Wie hoch ist die Gefahr, dass das Risiko eintritt?
Auswirkungen – Wie groß sind die Auswirkungen für das Projekt?
Kosten – Wie groß sind die Kosten (z.B. Personentagen oder Euro) um das Problem zu beheben?

Jeder dieser Punkte bekommt nun eine Wertigkeit von 1-3, wobei eins für gering und drei für enorm stehen. Haben nun mindestens 2 Kriterien eine mittlere, oder ein Kriterium eine hohe Wertigkeit, dann sollte das Risiko detailliert bewertet werden. Das bedeutet:

  • Eine konkrete Beschreibung des Risikos
  • Beschreibung der Ursache
  • Beschreibung der Auswirkungen
  • Was kostet es, wenn wir das Risiko nicht beheben (in Form eines Risikoaufschlages)
  • Was kostet es, wenn wir das Risiko beseitigen (in Form von z.B. Refactoring)
  • Welche Auswirkungen hat das Risiko auf ein späteres SLA?
  • Ist das Risiko so groß, dass wir das Projekt deshalb nicht annehmen können, wenn es nicht beseitigt wird?

Das Ergebnis dieser detaillierten Betrachtung der Probleme gibt beiden Seiten eine objektive Verhandlungsgrundlage und man kann entscheiden wie man mit welchen Risiken umgeht. Die Lösungen können sein, dass man das Risiko trägt und Aufschläge verrechnet, dass man das Risiko beseitigt, oder auch, dass der Auftragnehmer das Risiko trägt und keine zusätzlichen Aufschläge dafür verrechnet. Auf jeden Fall hat man so eine managementtaugliche Betrachtung des Projektes, welches die Schmerzen des Auftragnehmers auch gut sichtbar macht.

Doch bedenkt bitte, dass selbst nach einer sehr aufwendigen Vorbetrachtung – unter umständen sogar als Teil des Angebots und damit unfaktoriert – es immer noch möglich sein muss aus dem Projekt auszusteigen. Es darf nicht sein, dass man sich mit dieser Betrachtung so hohe Kosten auf bürgt, dass man keine Möglichkeit mehr hat auszusteigen.

Tja, jetzt bin ich gerade mal bei der Hälfte und schon haben wir wieder 1000 Wörter zusammen. Daher wird der Umgang mit internen Projekten jetzt nun doch in den 6. Teil der Serie verschoben. Aber ich danke auf jeden Fall für die tolle Anregung! 🙂

Mehr zum Thema?

Projekt „Intranet Relaunch“ I

Was erwartet euch in dieser Serie?

Wie bereits erwähnt ist mein Schwerpunkt die Technologiefamilie SharePoint mit all Ihren Facetten. Von OnPrem bis O365 und Apps, von 2007 bis 2016, von InfoPath und Nintex über C# bis zum JavaScript Object Model ist diese Landschaft sehr vielschichtig und bietet für große Unternehmen viele Einsatzmöglichkeiten über – aus der IT gesehen – lange Zeiträume.

Oft ist es nun so, dass ein Kunde, wenn er zu uns kommt, bereits eine Technologie für eine Fragestellung im Einsatz hat. Nehmen wir mal als Beispiel ein Intranet. Es gibt also bereits ein Portal, auf das die Nutzer zugreifen können um sich über Unternehmensinhalte zu informieren. Hier beginnt unsere neue Serie, die sich damit beschäftigt, wie man ein neues Intranet am Beispiel von O365 SharePoint einführen könnte. Mein Fokus soll dabei nicht auf den technischen, sondern den organisatorischen Schwierigkeiten liegen, die ein Kunde damit hat.

Wir werden bei der IT beginnen, welche das Intranet nicht länger Supporten möchte. Davon ausgehend ein Vorprojekt durchführen, eine Ausschreibung starten, die Bewerberauswahl durchführen, das Konzept erstellen und abnehmen, ein Team zusammenstellen, das Projekt mit all seinen Zwischenschritten durchführen, die Meetings abhalten, die Tests abnehmen, die Anwender schulen, das Projekt live schalten und schließlich den Support für das neue Intranet initiieren.

Es handelt sich also um einen vollständigen Zyklus, den ein solches Projekt durchlaufen muss und wird somit auch einen Querschnitt und zahlreiche Verweise auf alle Themen liefern, die ich auch sonst in diesem Blog so behandelte. Ich freue mich über fleißige Leser und Feedback zu meinen Artikeln. Viel Spaß beim Lesen!

Bestandsaufnahme

Für diese Serie nehmen wir ein kleines Beispiel. Ein Unternehmen hat 300 Mitarbeiter und möchte ein ihr bestehendes Intranet ablösen. Das bestehende Intranet beinhaltet aktuell Nachrichten aus dem Konzern, eine Wissensbibliothek, ein Workflow für die Urlaubsfreigabe und eine Anwendung für die Arbeitszeiterfassung. All diese Module existieren bereits seit einigen Jahren und wurden 2011 von einem externen Dienstleister nach dem Stand der Technik mit SharePoint 2010 umgesetzt.

Die IT stellt nun fest, dass es für diese Version in Zukunft keinen Mainstream Support mehr geben wird. Damit widerspricht die Lösung einer internen Richtlinie und muss abgelöst werden. Also informiert sie die zuständige Fachabteilung und veranlasst, dass nach einer neuen Lösung gesucht wird.

Der Fachseite selbst fehlt die entsprechende Expertise um den Wechsel eines Intranets durchzuführen. Also beauftragt sie in einem Vorprojekt zunächst einmal ein Beratungshaus damit den Status Quo zu ermitteln und die notwendigen nächsten Schritte auszuloten. Das Beratungshaus stellt dafür zunächst 3 Consultants bereit. Zum einen Infrastrukturspezialisten, welcher einen Health Check für die SharePoint-Infrastruktur durchführt. Der zweite Consultant ist ein Softwarearchitekt, welcher den Aufbau des Intranets analysiert. Als letztes schickt das Unternehmen noch einen Business Consultant. Er hat in dieser Phase die wahrscheinlich wichtigste Funktion. Denn er wird die Nutzer des alten Intranets ansprechen und über Interviews und Umfragen versuchen einen Blick in den Alltag dieser Kollegen zu erhalten.

Diese 3 Themen werden auch den Einstiegspunkt für uns in das Thema „Relaunch Intranet“ sein und einzeln in jeweils einem Beitrag behandelt werden.

Die Management Summary

Immer wieder ein Thema, dass mir über den Weg läuft. Ein Dokument ist geschrieben, 170 Seiten ist es dick geworden. Viele einzelne Themen wurden zu Modulen zusammengefasst und alle davon sind irgendwie wichtig. Und nun steht noch drohend eine einzelne Überschrift am Anfang des Papiers. „Management Summary“, „Overview“ oder etwas ähnliches. Was zur Hölle schreibe ich in die Management Summary?

Ich bin bei meinen Recherchen auf ein gutes PDF Dokument der Universität Göttingen gestoßen, die das Thema kurz und prägnant auf 3 Seiten erläutert. Außerdem liefert es zwei verschiedene Leitfäden für komplett neue Konzepte und für Änderungsanträge. Sehr lesenswert aus meiner Sicht und deshalb auch verlinkt!

Managment_Summary.pdf

SharePoint Customizations – wann nutze ich welches (DEV)-Modell?

Ein Kollege von mir ist auf einen exzellentes Webcast von „SharePoint Patterns & Practices“ gestoßen, dass ich euch nicht vorenthalten möchte. In dem 48 minütigen Beitrag geht es darum, welche Art der Entwicklung wann Sinn ergibt. Dabei werden folgende Typen betrachtet:

  • SharePoint Farm / Sandbox solutions – WSPs
  • SharePoint add-in model
  • Single page apps / externally hosted apps
  • SharePoint Framework

Die Betrachtung richtet sich dabei nach den Kriterien Wirtschaftlichkeit, Flexibilität, Zukunftssicherheit und O365 Fähigkeit.

Das Video habe ich euch direkt eingebunden. Den kompletten Beitrag findet ihr hier: SharePoint PnP Webcast – SharePoint Customizations – When to use which model?