Veränderte Rahmenbedingungen und adaptierte Ansätze
Projektmanagement as a Service
Sebastian Gerling und Alexander Aldefeld
Im Zuge der immer komplexeren IT-Architekturen steigen die Kosten für die Steuerung gerade mittlerer und großer IT-Projekte überproportional, da die Integration, Schnittstellen und Anforderungen zeitaufwändiger und intransparenter werden. Um dieser Entwicklung entgegen zu wirken, bedarf es einer standardisierten Entwicklungs- und insbesondere Projektmanagementmethodik mit definierten Schnittstellen, In- und Output-Artefakten und einem bewährten Vorgehensmodell. Eine Lösung ist der Ansatz SharePoint Project Management as a Service (SPaaS), der die Flexibilität eines katalogbasierten Vorgehens mit der Sicherheit eines Festpreisangebots verbindet.
Die letzten Jahre haben in der IT-Branche starke Veränderungen in der Governance, der Durchführung, aber auch in der Preisgestaltung mit sich gebracht. Unternehmen haben vor dem Hintergrund steigender IT-Kosten insbesondere im Bereich IT – Betrieb, Systemintegration und Custom Application Development – angefangen, Strategien zu entwickeln, um diesen Entwicklungen entgegen zu wirken. Hierbei werden Ansätze wie Outsourcing, Preferred-Supplier-Strategien oder standardisierte Projektvorgehensmodelle implementiert. Doch gerade im Bereich komplexerer SharePoint-Projekte stoßen diese Ansätze an ihre Grenzen, da sie die Besonderheiten einer SharePoint-Entwicklung hinsichtlich Erwartungshaltung, Komplexität und der am Markt fehlenden Experten nicht erfolgreich adressieren können. Darüber hinaus steigen gerade im Bereich Projektmanagement sowohl auf Seiten der Dienstleister als auch der Kunden die Kosten durch Phänomene wie Scope Creep, Failed Deployments oder aufwändige Requirements-Engineering-Prozesse. Der hieraus resultierende Preisdruck kann zu einer Verschlechterung der Lieferergebnisse und teilweise auch zu Projektabbrüchen führen.
Der oben erwähnte Ansatz des standardisierten Projektvorgehens (bspw. nach PMI oder Prince2) greift aufgrund von Spezialitäten der SharePoint-Entwicklung nur eingeschränkt im Bereich des Custom Application Developments und steigert mit seiner Orientierung an Standarddokumenten die Kosten für die Implementierung von SharePoint-Projekten deutlich. Um dieser Entwicklung entgegen zu wirken wurde das SharePoint-Projektemanagement-as-a-Service-Angebot entwickelt. Es basiert auf einem Katalog von SharePoint-spezifischen Artefakten, die zu einem Festpreis geordert werden können. Je nach Komplexität des Projekts, die sich nach dem Entwicklungsaufwand, der Anzahl der involvierten Abteilungen/Dienstleister und der Systemumgebung richtet, werden die Artefakte in die Kategorie simple, medium und complex eingeordnet und haben damit auch einen auf unterschiedlichen Preisen basierenden Erstellungsaufwand. Gleichzeitig determiniert die Komplexität auch, welche Artefakte aus dem Framework „mandatory“ sind, so sind beispielsweise für simple SharePoint-Projekte detaillierte Testcases ausreichend, wohingegen komplexe Projekte eines detaillierten Testplans incl. Releaseplan, Regressionsmanagement und einer User-Acceptance-Testmethode bedürfen. Alle Artefakte können zum Festpreis geordert werden, wodurch es dem Kunden ermöglicht wird, von vornherein eine detaillierte Kostenplanung zu erstellen. Dieser Festpreis gilt sowohl für die Steuerung von eigenen Ressourcen in der Entwicklung als auch beim reinen Projektmanagement im Auftrag des Kunden und der Steuerung eines anderen Dienstleisters im Rahmen der Trennung von Managementaufgaben. Vorteil des SPaaS-Ansatzes ist die Möglichkeit, ihn in bestehende Vorgehensmodelle zu integrieren und dabei sowohl den Anforderungen des bestehenden Vorgehens als auch den SharePoint-Projektanforderungen gerecht zu werden.
SPaaS im Detail
Das SPaaS-Framework soll nun im Folgenden anhand von verschiedenen SharePoint-Artefakten im Detail erläutert werden. Solche SharePoint-spezifischen Artefakte lassen sich in den unterschiedlichsten Bereichen finden. Von der SharePoint-Infrastruktur (inkl. der Backup-und-Restore-Thematik) über den Bereich der Informationsarchitektur (Navigationsstruktur) bis zum gesamten Themenkomplex Development und Deployment. Der entsprechende Lösungsansatz muss helfen, alle diese Themen während eines Projekts nach Best Practices zu adressieren und sollte hierbei auf den Erfahrungen aus vorhergehenden Projekten, Artefakten und Lessons Learned aufsetzen.
Das SPaaS-Framework umfasst deswegen eine Vielzahl von SharePoint-spezifischen Projektmanagement- und Serviceartefakten, die durch Quality Gates, verzahnte Checklisten und spezielle Prozesse miteinander verbunden sind.
Die Artefakte bestehen beispielsweise aus Checklisten, Templates und Abnahmekriterien, die im Rahmen eines SharePoint-Projekts hilfreich für die erfolgreiche Durchführung sind. Um den verschiedenen Charakteren von kleinen, großen bzw. einfachen oder komplexen SharePoint-Projekten sowie den unterschiedlichen technischen Fokussen gerecht zu werden, gibt es Artefakte für die unterschiedlichen Themen und Bereiche. Diese reichen von der Infrastrukturplanung über das Berechtigungskonzept und der Informationsarchitektur, Guidelines der Applikationsentwicklung bis hin zum Betriebshandbuch und einem Deployment Guide für Anpassungen und Lösungen.
In keinem Projekt werden sämtliche Artefakte benötigt, aber die Flexibilität ist einer der Vorteile des „SharePoint Projektmanagement as a Service“-Frameworks – es können exakt die Artefakte in den Vorgehensmodellen des Kunden eingebaut werden, die für dieses Projekt erforderlich sind.
Abb. 1: Integration von SPaaS in das Kundenframework
Abbildung 1 zeigt in einem Prozessschaubild, wie sich die Artefakte des „SharePoint Projektmanagement as a Service“-Frameworks in das vorhandene Kundenvorgehensmodell integrieren. Dabei können die Artefakte aus dem Katalog zu verschiedenen Zeitpunkten im Projektverkauf eingebunden werden. Die Anzahl und die Kombination der einzubindenden Bestandteile des Frameworks sind dabei flexibel.
Release Notes – nachvollziehbare Deployments
Release Notes sind kurze Dokumente, die dem Kunden zusammen mit Installationspaketen übergeben werden. Dies können zu testende, fertige oder erweiterte Lösungen sein. Release Notes geben den Mitarbeitern des Kunden einen Überblick über die Lösung und Hilfestellung bei typischen Vorgängen, wie der Installation oder Deinstallation.
Im Kopf der Release Note stehen die so genannten „Package Informations“, sie geben grundsätzliche Angaben zu dem gelieferten Gegenstand, wie dem Namen des Pakets, die Version, ob sich das Paket noch in der Entwicklung befindet oder bereits final getestet wurde (Abb. 2). Zudem wird angegeben, für welche Umgebung(en) das Paket entwickelt wurde und wie es zu verteilen ist. Diese Informationen sind für den Empfänger, wie zum Beispiel einen Administrator, wichtig, um über das weitere Vorgehen zu entscheiden. So wird anhand des „Release Types“ entschieden, auf welcher Umgebung das Paket installiert wird. Mit dieser Information kann verhindert werden, dass ein noch nicht fertiges Paket in eine Produktionsumgebung gelangt. Ebenso hilft die Information bzgl. des „Target Environment“ dabei, nicht die Übersicht zu verlieren, wenn der Kunde mehr als eine Umgebung hat. Besonders in hybriden Architekturen (Cloud- und On-Premise-Farmen im Mischbetrieb) ist diese Information wichtig, um die Lauffähigkeit zu sichern.
Abb. 2: Beispiel Header Release Notes
Der zweite Abschnitt der Release Notes beschreibt den Inhalt des Pakets genauer. Es werden alle SharePoint-Lösungen, Dokumente und PowerShell-Skripte referenziert, um dem Empfänger das Verwenden der Lösung zu erleichtern, bspw.:
- Solution Package: customer.workflow.customsolution.wsp
- Deployment-Skript: SharePoint Deployment Guide for CustomSolution.docx
- Installation-Skript: Install-CustomSolution.ps1
- Update-Skript: Update-CustomSolution.ps1
- Remove-Skript: Remove-CustomSolution.ps1
Die Referenzen auf die einzelnen Skripte sorgen für Klarheit bzgl. des Umgangs mit dem Paket. Besonders bei großen Lösungen, die aus mehreren Teilen bestehen, möchte der Administrator eine klare Vorgabe bekommen, wie die gelieferten Pakete zu handhaben sind. Wären diese Informationen nicht vorhanden, würden Features ggf. manuell eingespielt oder in der falschen Reihenfolge installiert und aktiviert werden. Dies hat Fehler zur Folge und kann den Aufwand für das Deployment unnötig erhöhen.
Der dritte Abschnitt stellt den Versionsverlauf mittels eines Change Logs dar. So ist für den Empfänger nachvollziehbar, welche Änderungen (wie z. B. Bugfixes) in die aktuelle Version eingeflossen sind. Diese Nachvollziehbarkeit hilft zudem, das Testing im Anschluss zu steuern. Es werden im Change Log die Nummer, Typisierung und Beschreibung der Änderung erfasst (Tabelle 1).
Change Log
#9960
Type: Bug
Search should be accessible in Quick Launch via …
#9963
Type: Bug
All Site Templates and Features should be...
