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.

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 I ​

Warum Projektplanung wichtig ist.

Das Projektgeschäft ist bekanntermaßen ziemlich tückisch. Oft gibt es Probleme, die man erst im Nachhinein erkennt und selten nimmt sich jemand die Zeit die Probleme aus der Vergangenheit wirklich zu reflektieren und auszuwerten. Das führt dazu, dass einige Projektleiter mit großer Erfahrung ein Projekt zum Erfolg führen können. Hauptsächlich dann, wenn genügend Probleme der aus vorhergehenden Projekten bereits bekannt sind und man weiß wie man damit umgeht. Kommen zu viele unbekannte Probleme oder ist der Projektleiter nicht erfahren in dieser Materie, wird irgendwann der kritische Punkt überschritten, bei dem das Projektteam die Fehler nicht mehr ausgleichen oder korrigieren kann. In diesem Fall wird das Projekt dann ein Desaster.

Viele Firmen, die ich kennen gelernt habe sind der Meinung, dass sie mit Projekten umgehen können. Eben weil sie ausreichend Projekte absolviert haben, bei denen das Ergebnis letzten Ends den Erwartungen des Kunden entsprochen hat – oder zumindest die Mindestanforderungen erfüllt hat. Am Ende zählt nur noch das Ergebnis und der Weg dorthin verschwindet oft im Gedächtnis des Einzelnen. Selten wird das Projekt noch einmal reflektiert oder gar Erkenntnisse schriftlich festgehalten.

Aus diesem Grund möchte ich in dieser Beitragsserie mal über meine persönlichen Erfahrungen der größten Projektfehler berichten und mögliche Gegenmaßnahmen zeigen. Leider sind das alles keine magischen Werkzeuge, die alles einfach machen, sondern nur Strukturen und Prozesse, die Initial erst einmal wieder Mehraufwände verursachen, bevor sie ihre Magie wirken können. Ein gewisses Maß an Vertrauen und auch Durchsetzungsvermögen gegenüber den Projektbeteiligten ist also durchaus notwendig.

Keine ausreichende Planung zu Beginn eines Projektes

Tatsächlich ist die mangelnde Planung am Anfang oft schon der Grundstein für das Fiasko. Dabei waren die Absichten gut. Der Kunde hat Zeitdruck, es geht nur um einen sehr überschaubaren Projektrahmen oder der Entwickler hat ohnehin schon signalisiert, dass er genau weiß was zu tun ist oder man möchte man Zeit aufholen. Es gibt diverse Gründe dafür den Projektstart ad hoc durchzuführen und einfach mal loszulegen. Oft ist die Ursache auch nicht bei einem einzelnen Grund zu suchen, sondern ergibt sich aus einer Summe verschiedener Teile.

Und dann passiert es. Zum Beispiel hat sich der entscheidende Entwickler krank gemeldet. Der Zeitplan ist aufgrund von Fehlern im Projekt nun unhaltbar geworden und es ist viel zu spät aufgefallen um noch Gegenmaßnahmen zu ergreifen. Der überschaubare Projektrahmen wurde durch diverse kleinere Änderungen aufgebläht, ohne das es aufgefallen ist. Die Architektur hat sich durch diese kleineren Änderungen nun doch entscheidend geändert.

Das Ergebnis ist oftmals verheerend. Der mangelnde Pflegeaufwand am Anfang zieht sich dann meistens wie ein roter Faden durch das Projekt. Änderungswünsche werden nicht dokumentiert, Probleme nicht an den Kunden kommuniziert und der Druck auf die Projektmitarbeiter wird immer größer. Da nicht klar ist, welche Anforderung wann und wie rein kam, wird einfach gemacht was der Kunde sagt. Man weiß nicht mehr, wie genau er seine Anfrage gestellt hat und irgendwann ist das Geld alle und das Produkt noch nicht fertig. Beide Parteien streiten sich um das Produkt und am Ende wird das Projekt entweder eingestampft oder unter enormen Kosten zu Ende geführt. Niemand ist glücklich und voraussichtlich war es das letzte Projekt in dieser Konstellation.

So könnte zumindest der Extremfall aussehen. Normalerweise ist es so, dass die Mitarbeiter des Zulieferers mit Überstunden, Vermutungen und einer gewissen Bugtoleranz doch noch das Ziel erreichen. Der Kunde ist zwar nicht glücklich, doch die Fehler werden mit dem nächsten und übernächsten Release gefixt und das Projekt unter „Erfahrung“ verbucht. Leider wieder ohne Retrospektive.

Dieses Beispiel zeigt wie leicht aus gutem Willen am Anfang und der Idee die eigene Agilität zu demonstrieren ein Desaster werden kann. Doch was hilf dagegen? Natürlich, Struktur. Sonst hätte ich den Beitrag ja nicht so eingeleitet. Aus meiner Sicht gibt es einige Grundsätzliche Dinge, die beim Projektstart auf jeden Fall erledigt werden müssen. In welcher Ausbaustufe das ganze Stattfindet, hängt dabei vom jeweiligen Projektumfang ab und einige Sachen können auch zunächst grob Skizziert und später ausdefiniert werden. Aber zumindest die Grundstrukturen sollten da sein.

Ein Projektplan auf Basis der Schätzung

Für das Projekt wurde initial irgendetwas geschätzt. Sonst hätte man den Auftrag ja nicht bekommen. Das sind die Zahlen, die für einen ersten Projektplan als Grundgerüst dienen. Welche Pakete wurden vereinbart, welche Zahlen stehen in PT für welche Rolle daran. Gibt es Abgabetermine und wer kann die Rollen besetzen. Je detaillierter dieser Projektplan definiert werden kann, umso besser sind die Ergebnisse später messbar. Doch es reicht am Anfang auch ein grobes Gerüst als Richtschnur. So sehen wir zumindest, wenn etwas völlig aus dem Ruder läuft und wir gegensteuern oder den Kunden informieren müssen.

Personalplanung auf Basis des Projektplans

Damit die richtigen Leute für mein Projekt zur Verfügung stehen muss ich diese auch einplanen. Je früher und weitreichender ich diese Planung durchführen kann, desto höher ist die Chance, dass meine Leute auch verfügbar sind. Damit ich nicht rate, wann ich welche Leute benötige, sollte der Projekt- und Meilensteinplan vorher zumindest in einem ersten Stand sein. Somit weiß ich, dass ich nach Meilenstein M1 die Person XY benötige, da sie eine Kernkompetenz für die Erbringung von M2 hat. Natürlich kann ich noch nicht auf den Tag genau sagen welche Personen ich von Anfang bis Ende benötige. Aber über den Projektplan bekomme ich eine Vorstellung und kann die Leute in dem betreffenden Zeitraum zumindest schon einmal vorplanen. Mit jedem Statusmeeting und jedem erfolgreichen Modul, dass abgeschlossen wurde, kann ich den Projektplan nachschärfen und auch die Personalplanung optimieren. Somit wird nicht nur für mich, sondern auch meine Leute der eigentliche Termin immer greifbarer und andere Projekte können sich nach dieser Planung immer besser richten.

Klärung der Abnahmekriterien der ersten Meilensteine / Sprints etc.

Bis zum nächsten Meilenstein, besonders am Anfang, gibt es oft sehr viel zu tun. Auch Dinge, die eigentlich nichts mit meiner Zielerreichung zu tun haben, sondern bereits vorgeplant werden für spätere Schritte. Damit man das eigentliche Ziel des aktuellen Meilensteins nicht aus den Augen verliert und sich in Details verstrickt, sollte für jeden Meilenstein klare Abnahmekriterien definiert sein. Was muss erreicht werden, damit der Kunde glücklich ist? In Scrum würden diese Aspekte einen möglichst hohen Wert in Story Points bekommen und somit zeitnah erledigt werden. Während die Arbeiten für später oder die weniger relevanten Nebentätigkeiten entsprechend herunter priorisiert werden. Dies hilft jedem einen klaren Blick auf das Ziel zu behalten und dem Projektleiter die Erreichbarkeit des Ziels und den aktuellen Status leichter zu messen.

Definition und Beschaffung der benötigten Arbeitsmaterialien

Es hört sich total trivial an, doch oftmals ist genau hier der Knackpunkt von vielen Projekten. Spätestens beim Projekt-Kick-Off muss klar sein, welche Arbeitsmaterialien benötigt werden, wer diese beschafft und wann die Arbeitsfähigkeit hergestellt ist. Erst dann – und wirklich erst dann – lohnt es sich mit einem Team in das Projekt einzusteigen. Bis zu diesem Zeitpunkt sollten lediglich die Experten für die Arbeitsmaterialien arbeiten und alle anderen Personen in anderen Aufgaben aktiv sein. Zu diesen Arbeitsmaterialien gehören in unserer Welt VSTS (TFS)-Projekt, Entwicklungsmaschinen, Zugriffe auf Kundensysteme, vollständige Anforderungen (zumindest für die ersten 2 Sprints), Ansprechpartner, Architekturkonzepte, Testkonzepte und ähnliches. So lange diese Bausteine nicht verfügbar sind und problemlos ihre Aufgabe erfüllen ist jede Art von operativer Hektik kontraproduktiv und wird letzten Ends die Qualität des Projektes untergraben und einem später wieder auf die Füße fallen.

Klärung der Aufgabenbereiche und Rollen

Auch das klingt einfach. Ein Entwickler soll natürlich den Code schreiben! Dafür haben ihr ihn ja dazu genommen! Ja, schon. Aber was denn noch? Ist er für das Aufsetzen der Entwicklungsmaschine zuständig? Ist der Architekt für Kundenkommunikation zuständig? Ist der Qualitätsmanager für die Erstellung der Testfälle zuständig? Für jeden Mitarbeiter sollte es ein gezieltes Onboarding in das Projekt geben. Wenn dies nicht möglich ist, sollte das Onboarding zumindest zentral in einem Projekt-Kick-Off stattfinden. Am Ende muss sich der Mitarbeiter genau auf diese Rollenbeschreibungen verlassen können und sich auch direkt darauf committen. Denn nur so ist sichergestellt, dass er eine implizite Andeutung nicht überhört hat. Gerade bei den oben genannten Beispielen ist dies nicht zwangsläufig so und der Kollege fühlt sich vielleicht gar nicht zuständig, obwohl der Projektleiter es eigentlich genau so gemeint hat. Deshalb lieber einmal zu viel sagen, was der Kollege machen soll und ihn das auch noch einmal in eigenen Worten wiederholen lassen, damit alle auf den selben Stand sind. Besonders bei langen Projekten bietet sich außerdem an, diese Aufgaben noch einmal schriftlich zu fixieren, damit sie nicht in Vergessenheit geraten. In Scrum könnte man diese dann zum Teil der Retrospektive machen. Waren wirklich alle Teammitglieder in Ihrer Rolle aktiv? Sind sie gut damit klar gekommen, oder bestehen irgendwo Lücken, die es zu schließen gilt?

Mehr zum Thema?

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.