Ü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.

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?

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?

Projekte in der Krise IV

Wie ein Projekt seiner Ausbaustufe das Leben schwer machen kann

Puh. Es war ein harter Weg, doch das Projekt steht endlich. Wir befinden uns in der Abnahmephase. Einige kleinere Findings und Nice-To-Have-Wünsche hat der Kunde noch. Wir haben noch etwas Budget in unserem Projekt und diese letzten Aufgaben werden gerade realisiert. Der Business Consultant hat das Ohr direkt am Kunden und wir erfüllen diese neuen Anforderungen quasi in Realtime. Ein kurzes Meeting mit dem Kunden, eine Mail an den Entwickler und los. Der Kunde testet jede neue Funktionalität direkt am System. Damit das knappe Restbudget für die Extras noch reit, machen wir sie schnell direkt auf dem System, welches bald live gehen soll. Der Code wird dann anschließend gesammelt in das Quellcodeverwaltungssystem eingecheckt. Der letzte Code, der letzte Test, Booya!

Der GoLive verläuft weitgehend problemlos. Die Codes sind JavaScript und andere Frontend-Logik, die wir in das Produktivsystem eingespielt haben. Damit musste die Seite nun nur noch öffentlich bekannt gemacht und die Rechte für die Benutzergruppen gesetzt werden. Alles läuft weitgehend glatt. Kleinere Bugfixes im Livesystem werden ebenfalls zeitnah gefixt. Die Akzeptanz ist hoch, die Stimmung gut.

Die Zeit vergeht. Das System läuft stabil, die Endnutzer arbeiten damit und entwickeln neue Ideen für Verbesserungen und neue Use Cases. Da das System wichtig ist, hat das Steering Board die wichtigsten Vorschläge und neuen Anforderungen gesammelt und ein neues Paket geschnürt. Das Projekt geht in Phase II und aufgrund der guten Leistung sind auch wir wieder als Entwicklungs- und Consultingmannschaft mit dabei.

Leider ist das damalige Entwicklungsteam inzwischen in anderen Projekten eingesetzt und nur sporadisch erreichbar. Daher wird ein neues Team eingesetzt. Der Business Consultant und Projektleiter konnten glücklicherweise aus anderen Projekten abgezogen werden und somit stehen zumindest an der Kundenfront die gleichen Ansprechpartner. Ein mehr oder weniger typisches Setting für eine Folgebeauftragung also.

Die Phase II

Und so beginnt es von Neuem. Doch schon bei Beginn liegt Ärger in der Luft. Die Entwicklermannschaft hat sich in die Dokumente der Anforderungsphase eingearbeitet und auch die INT- und QA-Maschine angesehen. Irgendwie ist es passiert, dass in den Anforderungs- und CR-Dokumenten etwas anderes steht, als im INT-System umgesetzt wurde. Das QA-System scheint sich außerdem ebenfalls in einzelnen Aspekten vom INT-System zu unterscheiden. Zudem geistern immer wieder E-Mails von dem letzten Entwicklerteam durch den Raum, die noch etwas anderes verkünden.

Klar, es war ja etwas hektisch zu Projektende. Aber im Quellcodesystem sind ja die aktuellsten Sources hinterlegt. Dann erneuern wir INT- und QA-System eben. Und schon tauchen die nächsten Fragen auf. Scheinbar wurden die Codes ohne oder unzureichendem Kommentar eingecheckt. Auch lassen sich daraus keine Pakete mehr erkennen weil gleich mehrere Pakete auf einmal eingecheckt wurden. Also lassen sich daraus keine Rückschlüsse auf Änderungen und Bugs schließen und auch der aktuelle Stand lässt sich so nicht eindeutig ermitteln. Na schön. Also installieren wir alles und schauen es uns an.

Der Business Consultant drängelt inzwischen etwas, da er für die neuen Anforderungen gerne einige Konzeptpapiere erstellen würde. Doch dazu braucht er Daten aus dem Bestandssystem und auch einige Screenshots.

Und nun wieder das Entwicklerteam, denn es ist leider wurden auch noch einige Konfigurationen nicht aktualisiert und nun funktionieren einige Funktionen nicht. Schließlich muss ein Entwickler der letzten Phase aus einem anderen Projekt losgeeist werden, damit dieser die Konfigurationen einstellen kann.

All das verzögert leider auch unsere Phase II immer weiter und der Anfangs gute Eindruck des Kunden wird leider getrübt. Natürlich kann man die Aufwände durch entsprechende Mehrarbeit wieder hereinholen, doch nun müssen auch die Dokumentationen aus Phase I noch nachbereitet werden. Und da nicht mehr alle Anforderungen vorhanden sind und man sich dem Kunden gegenüber natürlich auch keine Blöße geben will, wird man nie völlig aus dieser Klemme herauskommen und immer wieder gezwungen sein Dinge nach zu dokumentieren und durch Mehraufwände auszugleichen.

Was kann man tun?

Die Lösung ist natürlich offensichtlich und greift die Prinzipien aus dem ersten Teil der Serie auf. Nicht nur ein Projektplan muss sauber erstellt werden, sondern auch alle Änderungen im späteren Prozess müssen nachgetragen und aktualisiert werden. Man sollte bei der Umsetzung eines Projektes immer auch den gesamten Application Lifecycle im Blick haben. Was passiert, wenn eine Phase II kommt, oder ich die Applikation ablösen und auf eine neue Plattform heben will? Wir profitieren selbst davon, dass wir sauber dokumentieren und auch neue Anforderungen nachhalten. Denn wenn man gute Arbeit geleistet hat, ist es sehr wahrscheinlich, dass ein Kunde auch für den Folgeauftrag wieder den gleichen Dienstleister auswählt, anstatt sich der Gefahr auszusetzen mit einem etwas günstigeren Anbieter neues Lehrgeld zahlen zu müssen. Im Idealfall wirkt sich saubere Arbeit also sogar auf den Tagessatz aus, da man einen guten Ruf durchaus auch mal etwas höhere Kosten ausgleichen kann.

Und im Detail?

Soweit die Theorie. Aber was kann man denn nun ganz konkret tun? Nun, ich empfehle das ALM-Tool Visual Studio Online (ehem. Team Foundation Server). Durch geringe Kosten, hohe Verfügbarkeit und gute Skalierbarkeit bietet dieses Tool nahezu für jede Anwendung optimale Voraussetzungen. Außerdem bietet es diverse Werkzeuge für das ALM-Management. Zum Beispiel bei der Erfassung von Requirements, Tasks, Bugs, Issues, Testcases und ähnlichem, oder bei der Planung von Teams, Sprints und Kanban Boards. Aber auch für die Abbildung großer Projekte mit unterschiedlichen Epics, Features und User Stories ist es gut geeignet. Außerdem kann man die erstellen Dokumente oder auch Quellcode direkt zu jedem dieser Elemente direkt referenzieren. Die Vorteile sind so vielseitig, dass es für eine eigene Serie reicht. Deshalb soll dies nur als Anregung gedacht sein, sich selbst zu informieren. Oder natürlich auf ebenjene Serie zu warten. 🙂

Mehr zum Thema?

Meetingkultur

Worauf man bei Meetings achten sollte

Während meines bisherigen Arbeitslebens habe ich verschiedenste Arten und Organisationsformen von Meetings und Schulungen erlebt. Einige empfand ich und meine Kollegen als extrem zielgerichtet und wirkungsvoll. Es wurden Dinge beschlossen und die Umsetzung sauber geplant. Die Leute gingen motiviert und mit einer Vision aus dem Raum. Bei anderen Meetings hatte ich das Gefühl das mein Hirn in Watte gepackt ist. Man hört zwar zu, doch es interessiert einen nicht. Die dritte große Kategorie waren Meetings, bei denen wohl selbst der Veranstalter nicht wusste, worum es eigentlich ging und bei denen es schnell in ein unorganisiertes Durcheinander ausgeartet ist.

Doch woher kommen diese Unterschiede? Gibt es Regeln, die man beachten sollte? Und bringen diese Wirklich einen Mehrwert? In diesem Beitrag soll es genau darum gehen. Was muss bei einem Meeting beachtet werden.

Vor dem Meeting

Die Vorbereitung eines Meetings ist ebenso wichtig wie das Meeting selbst. Man sollte sich bewusst machen, dass man bei einem Meeting eine große Anzahl (3 oder mehr) von Personen in einem Raum versammelt um gemeinsam einen Sachverhalt zu klären oder eine Entscheidung herbeizuführen. Hierbei sollte einem immer klar sein, dass hierfür enorme Mengen an Arbeitszeit aufgewendet werden. Bei einem Meeting über 2 Stunden und mit 4 Personen ist bereits ein ganzer Arbeitstag aufgewendet. Umso wichtiger ist es, dass der Veranstalter möglichst viele Informationen bereits im Vorfeld bereitstellt und seine Anfragen und Klärungsabsichten möglichst klar formuliert. Hierfür eignet sich am besten direkt die Einladung, die beispielsweise über Outlook versendet wird.

Das Wichtigste ist dabei direkt der Titel, mit dem diese Einladung versendet wird. Steht dort prägnant um was es in diesem Meeting gehen soll? Wenn es nicht möglich ist den Zweck dieses Meetings in einem einfachen Titel zu umschreiben, sollte man noch einmal grundsätzlich über die Ausrichtung dieses Meetings nachdenken. Ist die Aufgabenstellung für das Meeting überhaupt geeignet? Sind die Fragen und Aufgaben prägnant genug um in einem solchen Meeting geklärt zu werden? Erst wenn man einen prägnanten Titel (z.B. Sprintplanungsmeeting, Klärung des Bugs XY, Mentoring für Person ABC) hat, sollte man hier fortfahren.

Ebenso wichtig ist der Empfängerkreis. Lade ich wirklich nur die Personen ein, die direkt in die Entscheidung eingebunden werden sollen? Haben die Personen also einen wichtigen Beitrag zu leisten? Wenn es nur darum geht, dass diese Personen ein oder zwei Anmerkungen machen sollen, oder an einem Teilproblem mitwirken, wäre es dann vielleicht besser, diese Personen gesondert zu einem anderen Termin einzuladen? Oder ist es dem Veranstalter möglich die Informationen bereits im Vorfeld einzuholen, sodass auf die Personen verzichtet werden kann? Es wäre ja auch möglich diese Leute einfach per Skype zu dem Meeting dazu zu holen, wenn es notwendig wird. So könnten diese den Rest des Meetings fernbleiben und während dieser Zeit etwas anderes machen.

Kommen wir zum Text der Einladung. Dieser sollte mindestens eine Agenda enthalten, in welcher die Sachverhalte erläutert werden, um die es im Meeting geht. Im Idealfall wird bereits so gut wie möglich vorgearbeitet und die Anfrage möglichst klar kommuniziert. Auch weiterführende Links zur Projektablage oder ähnlichem können hier weiterhelfen. Es sollte nach Möglichkeit alles enthalten sein, was den Beteiligten im Vorfeld hilft ein detailliertes Bild von der Situation zu bekommen. Da es sich bei den meisten Meetings um kein völlig neues Thema handelt und die Kollegen meistens schon recht genau wissen worum es gehen könnte, ist die Agenda mit einigen Details angereichert meist auch schon genug. Wichtig ist, dass klar hervor geht, welche Frage geklärt oder welcher Sachverhalt bearbeitet werden soll.

Die Uhrzeit und Dauer des Meetings sind natürlich auch wichtig. Man sollte bereits im Vorfeld die Terminkalender der Beteiligten überprüfen, damit es hier nicht zu Terminüberschneidungen kommt. Wenn möglich sorgt auch eine gewisse Vorlaufzeit dafür, dass die Kollegen sich eventuell den Termin freischaufeln können.

Während des Meetings

Okay, die Vorbereitungen sind also getroffen. Die Kollegen nehmen an dem Meeting teil und es beginnt. Was ist nun zu beachten? Als erstes sollte der Meeting-Leiter natürlich noch einmal in eigenen Worten erklären worum es in dem Meeting geht und was aus seiner Sicht die zu erzielenden Ergebnisse sind. Anschließend sollte er die Sicht der Beteiligten einholen, die eventuell noch etwas zu dieser Zielsetzung beitragen können. Wichtig ist,´dass die Veranstaltung der Diskussion und Lösungsfindung zwischen den Teilnehmern dienen soll. Es ist an dieser Stelle also meist wenig ratsam

Eventuell ist es auch so, dass nicht alle Meeting-Teilnehmer die gleiche Relevanz haben. So kann es durchaus sein, dass einige Kollegen nur für Teilbereiche der Aufgabenstellung benötigt werden. Diese Teilbereiche sollte man dann natürlich nach vorne verschieben um die Arbeitszeit der Kollegen möglichst wenig mit dem Meeting zu belasten. Ist ihre Aufgabe erledigt, können diese Kollegen dann wieder zu ihrer eigentlichen Arbeit zurückkehren.

Wichtig ist dabei, dass alle getroffenen Entscheidungen, alle Aufgaben und alle Unklarheiten, die in diesem Meeting auftreten auch protokolliert werden. Während eines Meetings ist es oft so, dass viele Aussagen getroffen und oftmals auch schnelle Entscheidungen getroffen werden. Teilweise auch unter der Annahme, dass jeder diese Aufgabe verstanden, akzeptiert und für sich irgendwie notiert oder gespeichert hat. Dabei sind jedoch nicht alle Entscheidungen für alle Mitarbeiter gleich wichtig und manche Kollegen merken sich eventuell eine Entscheidung nicht, da diese aus ihrer aktuellen Situation nichts mit ihnen zu tun hat. Erst wesentlich später wird dieser Aspekt – vielleicht aufgrund eines Rollenwechsels oder aufgrund einer falschen Einschätzung des Kollegen – wieder interessant und relevant. Aus genau diesem Grund ist es wichtig, dass es während eines Meetings einen Protokollführer gibt, der alle neuen Entscheidungen, Fragen und Aussagen notiert. Das kann über einen PC, Clipboard, Block oder sonst einem Medium geschehen. Zu diesem Zeitpunkt ist möglichst leichte Handhabung wichtiger als Struktur!

Hat ein Kollege seine Aufgaben in einem Meeting erfüllt – bspw. muss der Programmierer nicht für Design-Fragen bleiben. Hier reicht später eine Zusammenfassung – sollte man seine Aufgaben und die mit ihm gewonnen Erkenntnisse noch einmal kurz zusammenfassen, sodass alle Parteien eine ähnliche Vorstellung davon haben. Aufgrund der subjektiven Wahrnehmung der Teilnehmer ist eine identische Vorstellung eines Sachverhalts meist nicht möglich und auch an dieser Stelle lassen sich Unklarheiten nur reduzieren, nicht jedoch ausschließen. Ist diese Zusammenfassung erfolgt, sollte man den Kollegen auch von dem Rest des Meetings freistellen. Oftmals werden Kollegen von Anfang bis Ende in einem Meeting gehalten, obwohl sie nur einen sehr speziellen Aspekt betreuen. Dies führt zu Frust über das Meeting bei dem Kollegen und verschlingt unnötig die kostbare Projektzeit. Eine Zusammenfassung der wichtigsten Themen im Nachgang wird später noch genauer beleuchtet und dient diesen Kollegen als Verständnisbasis des restlichen Meetings.

Während des gesamten Meetings hat der Meeting-Leiter vor allem eine Aufgabe. Er koordiniert die Teilnehmer und sorgt dafür, dass die Diskussionen in den richtigen Bahnen verläuft. Sobald ein Teilnehmer zu ausschweifend wird oder sich zu sehr in Details verstrickt, sollte der Meeting-Leiter diesen Kollegen freundlich aber bestimmt zurück zum eigentlichen Thema führen. Schnell verlieren sich die Teilnehmer sonst in Diskussionen, bei denen wieder nur ein Teil der Teilnehmer wirklich etwas zu sagen hat, oder das eigentliche Thema wird nicht bearbeitet und bleibt liegen. Natürlich kann dies bei einem wichtigeren Thema durchaus sinnvoll sein, sofern es auch hier wieder dokumentiert wird. Wichtig ist jedoch wie gesagt, dass der Meeting-Leiter die Sorge dafür trägt, dass der eigentliche Fokus des Meetings nicht aus den Augen verloren wird.

Nähert sich das Meeting dem Ende sollte der Meeting-Leiter noch einmal die getroffenen Vereinbarungen, Entscheidungen, offenen Fragen etc. zusammenfassen, sodass jeder noch einmal überprüfen kann, ob auch alle für ihn relevanten Ergebnisse vertreten sind oder er noch etwas anmerken, hinzufügen oder klarstellen möchte. Dies ist auch dann wichtig, wenn das Meeting sich als zu kurz herausgestellt hat. In diesem Fall sollten bereits die wichtigsten Punkte für die unmittelbare Zukunft geklärt sein. Die Zwischenergebnisse werden noch einmal zusammengefasst und die Punkte für den Folgetermin besprochen.

Da die Kollegen in aller Regel Folgetermine oder reguläre Aufgaben haben, sollte das Ende des Termins stets eingehalten werden. In Ausnahmen kann der Meeting-Leiter die Kollegen fragen, ob sie mit einer Verlängerung des Termins einverstanden wären. In diesem Fall sollte jedoch auch geprüft werden, ob der gebuchte Raum noch frei ist.

Nach dem Meeting

Ist das Meeting abgeschlossen, sollte der Meeting-Leiter die erarbeiteten Erkenntnisse verarbeiten und ablegen. Zum einen sollte er die zuvor mündliche Zusammenfassung nun noch einmal schriftlich an alle Teilnehmer versenden. Zum einen ist dies eine Gedächtnisstütze für die Kollegen, zum anderen haben eventuell Kollegen das Meeting vorzeitig verlassen.

Gibt es zu diesem Meeting außerdem noch Stakeholder, also Leute, die an den Ergebnissen interessiert sind ohne direkt Mitsprache zu haben, können auch diese eine Zusammenfassung erhalten. Diese ist meist verkürzt gegenüber der internen Zusammenfassung, da dieser Personenkreis deutlich weniger in der Materie und meist nur an den eigentlichen Ergebnissen interessiert ist. Dafür kann es notwendig werden, weitere Erklärungen in die Zusammenfassung einzubinden. Zum Beispiel für spezielle Sachverhalte oder Fachbegriffe.

Alle erarbeiteten Ergebnisse müssen schließlich noch auffindbar abgelegt werden. Das kann zum Beispiel in einem speziellen Projekt- oder Themenraum sein. Der Link sollte ebenfalls an die Zusammenfassung – zumindest bei den beteiligen Kollegen – angehangen werden.

Tut das Not, dass da so viel Arbeit reingesteckt wird?

Jetzt kann ich schon hören, wie einige sich insgeheim fragen, ob das alles Not tut. Das kann man doch auch viel schneller machen und so hat man ja einen Riesenaufwand! Ja, den Aufwand will ich nicht leugnen. Trotzdem ist das aus meiner Sicht die richtige Vorgehensweise, wenn man ein Meeting zu einem wichtigen, verbindlichen Thema machen will. Die Frage, die ich mir ehr stelle ist, warum ich ein Meeting aufsetzen will, wenn  ich keine verbindlichen Aussagen haben möchte. In diesem Fall könnte ich mich schließlich auch mit den Kollegen beim Mittag oder auf einen Kaffee treffen.

Ein Meeting hat für mich immer einen offiziellen Charakter und sollte auch so gelebt werden. Es muss eine Hürde geben ein Meeting einzuberufen, da man sonst nur noch in solchen Veranstaltungen hängt. Typische Beispiele für ein Meeting sind aus meiner Sicht die Meilensteinplanung, Eskalationsmeetings, Phasenabschlussmeetings oder die Scrum-Meetings. Und ja, selbst bei dem Daily Scrum gibt es diese Form. Wir haben einen festen Teilnehmerkreis, jeder berichtet möglichst flott was er geleistet hat, was er vor hat und was ihn hindert. Und diese Erkenntnisse werden dann schriftlich im Sprint-Backlog und der Impediments-Liste erfasst. Eine Zusammenfassung kann hier entfallen, da die Liste für jeden zugänglich ist und es bekannt ist, dass die Ergebnisse hier abgelegt sind.

Von daher meine Bitte, überlegt euch ob ihr ein Meeting benötigt. Und wenn, dann führt es so aus, dass auch in ein paar Wochen noch klar ist, was besprochen wurde und wo ich die Ergebnisse finden kann.

Zusammenfassung

Vor dem Meeting:

  • wähle einen Titel der möglichst treffend ist
  • lade nur ein, wer wirklich notwendig ist
  • mache ggf. mehrere Meetings mit unterschiedlichen Teilnehmern
  • schreibe eine Agenda zum Meeting
  • verlinke, wenn notwendig, auf weiterführende Informationen und Projekträume
  • fasse die konkreten Anforderungen verständlich zusammen
  • wähle eine Zeit, in der die Personen zeit haben oder kläre mit verhinderten Personen, ob sie den Termin zwischenschieben können

Während dem Meeting:

  • Fasse den aktuellen Stand anfangs zusammen
  • Fasse die konkreten Aufgaben und Fragestellungen zusammen
  • Es ist eine Diskussionsrunde. Verzichte auf PowerPoints und Monologe
  • Lass die Teilnehmer notwendige Ergänzungen machen
  • Behandele zuerst die Themen, bei denen Kollegen vorzeitig das Meeting verlassen können
  • Notiere jede Entscheidung, Frage oder Erkenntnis mit
  • Fasse den aktuellen Stand auch am Ende des Termins zusammen
  • Vereinbare direkt einen Folgetermin, wenn dieser notwendig ist
  • Verlängere den Termin nur in Ausnahmen und mit Zustimmung der Beteiligten

Nach dem Meeting:

  • Eine Meeting-Zusammenfassung mit den wichtigsten Ergebnissen und Entscheidungen wird an alle Teilnehmer versendet
  • Erarbeitete Ergebnisse werden auffindbar abgelegt
  • Eine verkürzte Zusammenfassung kann eventuell an Stakeholder versendet werden, sofern sinnvoll

Rollen und Verantwortung

Bei einer Ausschreibung bin ich über 2 Begriffe gestoßen, die ich selbst so nie unterschieden habe, bei denen es mir jedoch jetzt sinnvoll erscheint. Es geht um die Rollen Software-Architect und Software-Engineer. Hättet ihr gewusst, wo die Unterscheidung liegt? Nun, über diese und weitere Rollen möchte ich in diesem Beitrag berichten und versuchen ein einheitliches Verständnis zu schaffen. Zumal diese Begriffe nie wirklich vereinheitlicht wurden. Diese Liste erhebt jedoch keinen Anspruch auf Vollständigkeit und natürlich können mehrere Rollen auch von einer Person ausgeübt werden.

Projektleiter
Er ist die Person, die ein Projekt zusammen hält und den Überblick hat. Er arbeitet am besten, wenn er wie ein Fluglotse agieren kann. Selbst ist er an der Umsetzung nicht beteiligt, sondern ist derjenige, der alle Informationen über Das Projekt hat. Er kennt den großen Status des Projektes, weiß welche Pakete aktuell umgesetzt werden, welche abgeschlossen sind und wo es Probleme gibt. Außerdem benennt er die Verantwortlichkeiten im Projekt und sorgt dafür, dass die Leute auch entsprechend handeln und handeln können. Er berichtet in regelmäßigen Abständen an den Kunden und das Projekt-Controlling.

Teil-Projektleiter
In besonders großen und interdisziplinären Projekten, kann es sein das ein z.B. technischer und ein fachlicher Projektleiter den Hauptprojektleiter unterstützen. Sie nehmen die gleichen Funktionen der Koordinierung wahr und berichten an den Projektleiter. Alle interdisziplinären Entscheidungen und sehr wichtige Teilprojektentscheidungen werden durch oder in Absprache mit dem den Hauptprojektleiter getroffen.

(Software-)Architekt
Der Architekt ist derjenige, der für die gesamte Lösung das große Bild erstellt. Er entscheidet welche Technologien und Applikationen verwendet werden. Soll der SharePoint mit dem SQL reden? Dann ist das eine Architekturentscheidung. Auch ob eine Farm-Solution oder CSOM eingesetzt wird obliegt ihm. Ferner bestimmt er zusammen mit dem Projektleiter die Entwicklungsmethodik. Arbeit nach Scrum oder V-Modell zum Beispiel. Er berichtet an den (Teil-)Projektleiter. Ihm unterstellt sind die Ingenieure aller Disziplinen.

Qualitätsmanager
Bei dem Qualitätsmanager handelt es sich um eine interdisziplinäre Rolle. Ähnlich wie beim Projektleiter handelt er am besten, wenn er nicht direkt in das Projekt eingebunden wurde, sondern als Stabsstelle des Projektleiters fungiert. Er prüft die Arbeitsergebnisse aller Disziplinen und gibt wenn notwendig Verbesserungsvorschläge oder verweist auf Standards. In seiner Verantwortung liegt, dass das Projekt sauber abgewickelt wird. Wenn Kompromisse im Projekt eingegangen werden, überwacht er, dass diese sauber dokumentiert und wenn notwendig durch den Kunden zur Kenntnis genommen oder abgesegnet werden. Er berichtet an den Projektleiter und wenn notwendig an das Projekt-Controlling.

(Software-, Test-) Ingenieur
Der Ingenieur ist für die konkrete Umsetzung verantwortlich und überwacht diese. Während der Architekt die Entwicklungsmethodik und Technologie vorgegeben hat, kümmert sich der Ingenieur um die konkreten Schnittstellen und die Einhaltung der Richtlinien. Er ist quasi der Erste der Entwickler und sorgt auch dafür das die einzelnen Module und Pakete reibungslos miteinander laufen.

Neben dem Softwareingenieur gibt es hier auch den Testingenieur. Seine Aufgaben gleichen sich in einer anderen Fachrichtung. Er überwacht die Erstellung und Ausführung der Tests und prüft dabei immer wieder, ob die Qualitätsrichtlinien auch sauber umgesetzt wurden.

(UX-, Software-, Test-) Designer
Der Designer ist dafür verantwortlich, dass das Frontend ansprechend und den Anforderungen gemäß umgesetzt wird. Während der Softwaredesigner sich um das Design der Oberflächen kümmert, kümmert sich der UX-Designer darum, dass der User ein möglichst leicht zu bedienendes Produkt erhält und die Klickpfade kurz und verständlich bleiben. Beide sind in der Regel dem Softwareingenieur unterstellt.

Der Testdesigner erstellt die Testszenarien für die Anforderungen und sorgt dafür, dass alle Akzeptanzkriterien abgehandelt werden. Er ist dem Testingenieur unterstellt.

(Software-) Entwickler
Der Entwickler ist für die Realisierung der Anforderungen zuständig. Er berichtet im Rahmen der Projektmeetings an die Vorgesetzten und ist für seine Arbeitspakete und deren Qualität verantwortlich. Er ist der einzige, der einem Produkt wirklich etwas hinzufügt.

Tester
Der Tester nutzt die Arbeitspakete des Testdesigners und führt diese aus. Er dokumentiert Widersprüche zwischen Software und Tests und teilt diese in den Projektmeetings mit. Seine Arbeitsresultate sind notwendig um die einzelnen Testphasen abzuschließen. Der Tester kann sowohl durch den Lieferanten als auch durch den Kunden oder auch gemischt besetzt werden.

Consultant
Der Consultant ist der Berater des Kunden. Er nimmt die Anforderungen auf und bringt sie in eine standardisierte Form, sodass diese durch die Softwareentwicklung in ein konkretes Arbeitspaket interpretiert und umgesetzt werden kann. Er nimmt auch Änderungswünsche auf und kommuniziert diese in beide Richtungen.

Was ist Application Lifecycle Management (ALM)?

Application Lifecycle Management beschreibt einen ganzheitlichen Ansatz, der eine Anwendung während allen Phasen der Software begleitet. Er definiert Artefakte und Rollen und sorgt dafür, dass die einzelnen Schritte der Realisierung eingehalten und geprüft werden. Der Sinn von ALM liegt in einer Steigerung der Gesamtqualität der Software und der Zusammenarbeit mit dem Kunden, sowie in einer möglichst weitgehenden Standardisierung von Einzelschritten, dass Mitarbeiter der gleichen Rolle in verschiedenen. Der Gesamtprozess untergliedert sich dabei in verschiedene Phasen, die nachfolgend einzeln beschrieben werden.

Analyse- und Anforderungsphase

In diesem Schritt wird der konkrete Bedarf des Kunden ermittelt und in seinem betriebswirtschaftlichen Gesamtkontext bewertet. Ziel ist es die Bedürfnisse des Kunden so konkret wie möglich zu verstehen um in der nächsten Phase einen geeigneten Lösungsansatz dafür auszuwählen.

Typische Artefakte dieser Phase sind das Lasten- und Pflichtenheft, welche mit ersten Mockups und ersten Designentwürfen angereichert werden können. Auch Entwicklungs-, Design- und andere Richtlinien des Kunden sollten zu diesem Zeitpunkt durch den Kunden bekannt gemacht werden.

Beteiligte Personen in dieser Phase sind der Kunde und die Business Consultants. Weitere Personen wie Architekten und Designer können bei Bedarf unterstützen.

 Konzeptionsphase

Die Konzeptionsphase nutzt die Erkenntnisse aus der Anforderungsphase und wählt einen geeigneten Lösungsansatz für die Problemstellung aus. Während der Konzeptionsphase kann es immer wieder zu Rücksprüngen in die Analyse- und Anforderungsphase kommen, wenn Anforderungen nicht präzise genug waren oder neue Gesichtspunkte erneute Fragen aufstellen. Ziel dieser Phase ist es, einen Lösungsansatz zu wählen, der den Bedürfnissen des Kunden entspricht und auch robust genug ist, um künftige Änderungen und Weiterentwicklungen abzubilden.

Typischerweise werden während der Konzeptionsphase ein Grob- und ein Feinkonzept erstellt, welche um weitere Konzepte für Design, Software-Architektur, Release Management und Test Management ergänzt werden sollten.

Beteiligte Personen in der Konzeptionsphase sind Projektleiter, Software-Architekten, Qualitätsmanager und Designer. Business Consultants und ggf. die Kundenseite können bei Bedarf unterstützen.

 Realisierungsphase

Die Realisierungsphase umfasst die eigentliche Umsetzung einer Lösung und geht vom Aufsetzen der Entwicklungs- und Abnahmeumgebungen über die Entwicklung der Software und begleitenden Dokumente bis zur Installation der Lösungen in der Integrationsumgebung. Am Ende dieser Phase müssen die Anforderungen des Kunden durch das Umsetzungsteam vollständig implementiert, dokumentiert und getestet sein.

Artefakte dieser Phase sind die eigentliche Lösung, Deployment-Skripte, das Installations-, Administrations- und Benutzerhandbuch, sowie durch den Entwickler ausgeführte Testszenarien und Unit Tests.

In dieser Phase tragen Entwickler, Designer und Tester die Hauptlast der Arbeit. Ergänzt werden diese durch Projektleiter, Software-Architekten und Qualitätsmanager, welche die Ausführung überwachen und steuern.

 Qualitätssicherungsphase

Die Qualitätssicherungsphase beginnt mit dem Abschluss der Realisierung und dem Beginn des Abnahmeprozesses. Der Abnahmeprozess startet, wenn die Entwicklung der Software abgeschlossen und die Tests durch den Entwickler erfolgreich ausgeführt werden konnten. Der Test durch den Entwickler kann z.B. auf einer Entwicklungs- oder Integrationsumgebung ausgeführt worden sein.

Die Qualitätssicherungsphase selbst umfasst den Review aller erstellten Dokumente und Testfälle, sowie die Prüfung der Software anhand der Testfälle. Außerdem können hier weitere Mittel wie Exploratory Tests genutzt werden, um die Qualität weiter zu steigern. Werden Fehler gefunden, werden diese Dokumentiert und an das Realisierungsteam zurück gespiegelt. Diese haben dann in einer Nachbereitungsphase die Möglichkeit diese Fehler zu beseitigen. Fehler gelten wiederum als behoben, wenn Software, Dokumentation und Testfälle vollständig korrigiert wurden. Ist die Nacharbeit erfolgreich abgeschlossen erfolgt eine neue Prüfungsphase. Nacharbeit- und Prüfungsphase wechseln sich so lange ab, bis keine Fehler an dem Produkt mehr gefunden werden. Das Produkt kann dann an den Kunden zur Abnahme übergeben werden. Wenn dann keine Nacharbeit mehr anfällt, ist diese Phase abgeschlossen.

Ergebnis dieser Phase sind, dass das Produkt auf allen Abnahmeumgebungen (z.B. Integrationsumgebung und QA-Umgebung) erfolgreich getestet werden konnte. Dies wird üblicherweise in einem Abnahmedokument festgehalten. Weitere Artefakte können das Statusprotokoll der ausgeführten Tests oder auch ein Protokoll der Unit Tests sein.

Hauptverantwortlich in dieser Phase sind der Qualitätsmanager und die Tester. Weitere Aufgaben übernehmen der Ressourcen aus der Realisierungsphase. Die Abnahme am Ende der Qualitätssicherungsphase erfolgt durch den Kunden.

 Release- und Deployment-Phase

Die Release und Deployment Phase beschäftigt sich mit der Paketierung und Auslieferung der Software auf die Produktivumgebung. Hierfür sollte über ein Build-Werkzeug, wie zum Beispiel den Team Foundation Server (Visual Studio Online), nach einem standardisierten Vorgehen eine Release-Version des Produktes erzeugt und paketiert werden. Dieses Paket kann anschließend entweder vollautomatisiert oder administrativ über Deployment-Skripte auf dem Produktivsystem installiert werden. Sind beide Optionen nicht gangbar wird ein ausführliches Installationshandbuch benötigt, welches ebenfalls den ALM-Prozess durchlaufen muss.

Ein weiterer wichtiger Punkt dieser Phase ist die Versionierung der Software. Es muss sichergestellt werden, dass jede Version beim Kunden wartbar bleibt und auch zukünftige Bugfixes in eine alter Version übernommen werden können. Die Informationen dafür sollten aus dem Release Management Konzept kommen.

In dieser Phase findet beim Kunden auch die Schulung der künftigen Anwender des Produktes statt, sofern dies erforderlich ist. Die Schulungsunterlagen dafür sind entweder bereits in der Realisierungs- und Qualitätssicherungsphase entstanden, oder können während der Release-Phase erstellt werden. Wichtig ist, dass auch diese einen Review durch das Qualitätsteam erhalten. Die Schulung beim Kunden wird anschließend entweder durch einen Business Consultant oder den Kunden selbst vorgenommen.

Ziel der Release und Deployment Phase ist ein vollständiger Rollout der Installation mit optionaler Schulung der Anwender und Go Live der Anwendung. Ist diese Phase abgeschlossen kann das eigentliche initiale Umsetzungsprojekt als abgeschlossen betrachtet werden und das Produkt wird in den Managed Service überführt.

Hauptverantwortlich für diese Phase ist der Release Manager und das Operation-Team, der entweder vom Zulieferer oder dem Kunden selbst gestellt wird. Zuarbeiten können durch Business Consultants und den Kunden erfolgen.  

Wartungs- und Optimierungsphase

Diese Phase dauert in der Regel am längsten, auch wenn der Zulieferer hiervon meist nur wenig merkt. Das Produkt ist live geschaltet und die Anwender benutzen das Produkt in ihrem Arbeitsalltag. In der Regel betreut ein Support-Team das Produkt und löst die Probleme die nach der Entwicklung im Umgang mit dem Produkt entstehen. Diese können durch Fehlverhalten der Nutzer, eine fehlerhafte Konfiguration des Produktes oder echte Programmierfehler entstanden sein.

Während dieser Phase kann es durchaus vorkommen, dass weitere Versionen des Programms durch den ALM-Zyklus gebracht werden. Ziel in der Wartungs- und Optimierungsphase ist es, solche Änderungen als Updates einzuplanen und den reibungsfreien Betrieb sicherzustellen, sodass es auf den Arbeitsalltag möglichst geringe Auswirkungen hat.

Hauptverantwortlich für diese Phase sind das Operation-Team und gegebenenfalls die Mitglieder des Managed Service für dieses Produkt beim Zulieferer.