Definition der Sprint-Planung Scrum ist ein flexibles Rahmenwerk zur Entwicklung von Software, Produkten und Dienstleistungen, das auf einem inkrementellen und iterativen Ansatz basiert. Jede Iteration wird als Sprint bezeichnet. Zu Beginn eines jeden Sprints wird das Sprint Planning durchgeführt, welches als Kick-off dient. Dieses Treffen ist darauf ausgerichtet, ein wertvolles Sprint-Ziel zu definieren, das als Meilenstein zur Erreichung des Produktziels dient, und die im aktuellen Sprint zu bearbeitenden Backlog-Items zu planen. Die Struktur des Meetings basiert auf drei zentralen Fragen: Warum ist dieser Sprint wertvoll? Was kann in diesem Sprint umgesetzt werden? Wie werden die ausgewählten Sprint Backlog Items umgesetzt? Einfach ausgedrückt, initiiert die Planung den Sprint und legt die Arbeiten fest, die innerhalb des Sprints umgesetzt werden sollen. Ein gepflegtes und priorisiertes Product Backlog ist eine wichtige Voraussetzung für das Sprint Planning. Es bildet die Grundlage zur Erstellung einer Auswahl der wichtigsten und am höchsten priorisierten Backlog Items, auch als Selected Backlogs bekannt. Diese Auswahl stellt eine Art Wunschliste des Product Owners dar. Die Entwickler entscheiden gemeinsam, welche Items ins Sprint Backlog aufgenommen und umgesetzt werden. Teilnehmer des Sprint Planning Am Sprint Planning nimmt das gesamte Scrum Team teil, bestehend aus den Entwicklern, dem Scrum Master und dem Product Owner. Der Product Owner organisiert das Meeting, während der Scrum Master für die Moderation und die Einhaltung des Ablaufs verantwortlich ist. Stakeholder wie Anwender, Partner oder Vertreter aus Vertrieb oder Marketing können ebenfalls eingeladen werden, sollten jedoch hauptsächlich eine beratende Funktion einnehmen. Der Product Owner sollte idealerweise bereits vor dem Meeting mit Stakeholdern und Entwicklern über die Anforderungen gesprochen haben. Sprint Planning als Scrum Event Scrum ist ein kommunikationsintensiver Prozess mit verschiedenen Events innerhalb eines Sprints, einschließlich des Sprint Planning, Daily Scrum, Sprint Review und der Retrospektive. Auch das Backlog Refinement wird regelmäßig durchgeführt, obwohl es im Scrum Guide nicht als offizielles Event gilt. Die Vielzahl der Events betont die Bedeutung von Kommunikation und Zusammenarbeit zur Erreichung gemeinsamer Ziele. Jedes Event verfolgt dabei seine eigenen spezifischen Ziele und Zwecke. Sprint Planning 1 in der Praxis Das Sprint Planning gliedert sich in zwei Phasen: Sprint Planning 1 und 2. Sprint Planning 1 konzentriert sich auf das „Why“ und „What“ des Sprints – warum der Sprint wertvoll ist und was erreicht werden soll. Der Product Owner schlägt vor, wie das Produkt im aktuellen Sprint seinen Wert steigern könnte, wodurch die Entwickler eine klare Vision und ein besseres Verständnis der Sprint-Ziele erhalten. Daraufhin werden die Items im Selected Backlog vom Product Owner vorgestellt und mit den Entwicklern diskutiert, um technische und fachliche Hintergründe zu klären. Akzeptanzkriterien der Items werden verfeinert, und der Aufwand wird von den Entwicklern geschätzt. Die ausgewählten Items werden ins Sprint Backlog übernommen, basierend auf der maximal umsetzbaren Menge an Aufgaben. Mit dem Commitment der Entwickler zur Erreichung des Sprint-Ziels endet dieser Teil des Meetings. Sprint Planning 2 in der Praxis Nach dem Commitment der Entwickler ist die Rolle des Product Owners im Sprint Planning abgeschlossen. In der zweiten Phase diskutieren die Entwickler, meist ohne den Product Owner, über die technischen Details der Umsetzung der Sprint Backlog Items. Es wird erörtert, wie die Anforderungen praktisch umgesetzt werden können, und es werden Arbeitspakete erstellt, idealerweise in Tasks zerlegt, die eine Bearbeitungsdauer von nicht mehr als einem Tag haben sollten. Ein Taskboard, ob physikalisch oder digital, kann zur Visualisierung der Tasks genutzt werden. Am Ende dieser Phase sollte das Team in der Lage sein, dem Product Owner und dem Scrum Master zu erklären, wie sie als selbstverwaltendes Team arbeiten werden, um das Sprint-Ziel zu erreichen. Timeboxing im Sprint Planning Timeboxing ist ein wesentliches Element von Scrum. Laut Scrum Guide sollte das Sprint Planning für einen einmonatigen Sprint maximal acht Stunden dauern, wobei kürzere Sprints entsprechend weniger Zeit in Anspruch nehmen. Diese Zeit sollte gleichmäßig auf die beiden Planungsphasen verteilt werden. Der Scrum Master sorgt für die Einhaltung dieser Timebox. Tipps und Tricks beim Sprint Planning Erfahrungen aus der Praxis zeigen, dass Teams besser im Schätzen von Aufwänden werden und Störungen leichter vorhersehen können. Einige Tipps für die Sprint-Planung sind: Vereinbaren Sie einen Prozentsatz der Kapazität für Fehlerbehebungen, berücksichtigen Sie effektive Arbeitstage und nutzen Sie Fälligkeitsdaten zur Fortschrittsverfolgung. Eine klare Definition of Done unterstützt zudem die Erstellung besserer Inkremente am Ende eines jeden Sprints. Planung von potenziell lieferbaren Inkrementen Auch mit Erfahrungen und Techniken bleibt die Zukunft schwer vorhersehbar. Es gibt viele Variablen, die berücksichtigt werden müssen, und der Aufwand zur Realisierung von Anforderungen kann leicht falsch eingeschätzt werden. Scrum minimiert dieses Risiko, indem es die Erstellung von potenziell lieferbaren Inkrementen am Ende eines Sprints vorsieht. Wenn unerwartete Ereignisse eintreten, kann dennoch ein Nutzen aus den bereits entwickelten Teilen gezogen werden.
Kategorie: Allgemein
Inkrementelle Entwicklung in kurzen Zyklen: Der Scrum Sprint Scrum ist ein Framework, das die Entwicklung von Software, Produkten und Dienstleistungen unterstützt. Es verfolgt einen inkrementellen, iterativen und empirischen Ansatz und besteht aus wenigen Verantwortlichkeiten, Artefakten und fünf wichtigen Events: Sprint, Sprint Planning, Daily Scrum, Sprint Review und Sprint Retrospektive. Der Sprint bildet dabei das Herzstück von Scrum, oft als „Herzschlag von Scrum“ bezeichnet. Es handelt sich um eine zeitlich festgelegte Iteration mit konstanter Dauer und immer ähnlichen Abläufen, die auf die Umsetzung einer definierten Lösung abzielt. Eigenschaften von Scrum Sprints Ein Sprint umfasst alle Arbeiten, die zur Erreichung des Produktziels nötig sind, einschließlich der Events Sprint Planning, Daily Scrums, Sprint Review und Sprint Retrospektive. Der Sprint fungiert somit als Rahmen für die anderen vier Events. Er beginnt mit der Sprint Planung, in der das Sprint-Ziel festgelegt und entschieden wird, welche Product Backlog Items ins Sprint Backlog aufgenommen werden. Das Team verpflichtet sich anschließend auf das Sprint-Ziel. Das Ergebnis ist ein potentiell lieferbares Inkrement, wobei mehrere Auslieferungen innerhalb eines Sprints möglich sind. Ein Sprint besitzt eine festgelegte Dauer, auch als Timebox bezeichnet, die zwischen einer Woche und einem Monat liegt. Diese kurze Zeitspanne unterscheidet sich von der klassischen Iteration und hilft, Komplexität und Risiken zu minimieren. Sprints fördern Vorhersagbarkeit durch regelmäßige Überprüfung und Anpassung des Fortschritts sowie die Begrenzung des finanziellen Risikos auf die Sprint-Dauer. Täglich treffen sich die Entwickler (und ggf. der Scrum Master und der Product Owner) zum Daily Scrum, um über erledigte und anstehende Aufgaben sowie Hindernisse zu sprechen. Der Fortschritt wird oft über ein Taskboard visualisiert. Am Ende des Sprints findet ein Review statt, bei dem das Team die Ergebnisse wichtigen Stakeholdern präsentiert. Anschließend reflektiert das Team in einer Retrospektive über den letzten Sprint und entscheidet, welche Aspekte beibehalten oder verändert werden sollten. Regeln für Scrum Sprints Es gibt bestimmte Regeln, die während eines Sprints beachtet werden müssen: Änderungen, die das Sprint-Ziel gefährden könnten, sind nicht gestattet. Qualitätsziele dürfen nicht gesenkt werden. Der Umfang kann zwischen Product Owner und Entwicklern angepasst werden, sobald neue Erkenntnisse vorliegen. Der Product Owner kann einen Sprint abbrechen, wenn das Ziel überholt ist. Die Entwickler sollten idealerweise selbstständig Hindernisse beseitigen, wobei der Scrum Master bei Bedarf unterstützt. Fortschritte werden oft durch ein Burn-Down- oder Burn-Up-Chart visualisiert. Die Geschwindigkeit des Teams pro Sprint, bekannt als Velocity, dient zur Unterstützung künftiger Sprint Planungen. Ein neuer Sprint beginnt unmittelbar nach Abschluss des vorherigen. Die Dauer der Sprints wird idealerweise gemeinsam von allen Beteiligten festgelegt. Sollte es Meinungsverschiedenheiten geben, könnte der Product Owner aufgrund seiner Nähe zu den Kunden oder der Scrum Master aufgrund seines Wissens über die Teamfähigkeiten die Dauer bestimmen. Letztlich hängt es davon ab, welche Frequenz der Markt erwartet und was das Team leisten kann. Benennung von Sprints Sprints können kreativ benannt werden, um das Team zu stärken. Üblicherweise werden sie numerisch benannt, beginnend bei Sprint 0. Alternativ können auch Film- oder Songtitel, Biermarken, Künstler oder Tiere als Namensgeber genutzt werden. Verwendung von verschiedenen Sprint Metriken Viele Unternehmen verwenden die Velocity zur Planung von Sprints basierend auf Story Points. Es gibt jedoch zahlreiche weitere agile Metriken, die genutzt werden könnten, wie Anwesenheitsquote, Backlog Health, Cycle Time, Escaped Defects, Fehlerdichte, Flow-Efficiency, Kundenzufriedenheit, Lead Time, Mean Time To Repair (MTTR), Prozentsatz der Nacharbeit, Team-Moral, Time to Market, Time to Value und Work in Progress (WIP). Der Scrum Guide definiert keine festen Metriken, sodass Organisationen selbst wählen können, welche für sie am nützlichsten sind.
Scrum – ein anpassungsfähiges Rahmenwerk für komplexe Projekte und Entwicklungen. Scrum dient als Rahmenwerk für die stufenweise Planung und Umsetzung von Produkten und Dienstleistungen. Es unterstützt Unternehmen besonders dann, wenn Projekte zu Beginn zu komplex sind, um präzise geplant zu werden, wenn sich Anforderungen oder Prioritäten ändern, schnelle Mehrwerte für Kunden notwendig sind oder Risiken reduziert werden sollen. Ursprünglich für die Softwareentwicklung gedacht, findet Scrum seit vielen Jahren Anwendung im Projektmanagement und bei der Produktentwicklung in diversen Branchen und Industrien. Dieses Framework ist durch ein inkrementelles, iteratives Vorgehen charakterisiert, das aus Events, Verantwortlichkeiten und Artefakten besteht und auf Empirie (Erfahrungsbasiertes Wissen und Entscheidungsfindung durch Beobachtungen) sowie Lean Thinking (Vermeidung von Verschwendung und Fokussierung auf das Wesentliche) basiert. Funktionsweise von Scrum Die „Spielregeln“ des Frameworks sind im Scrum Guide festgelegt. In der aktuellen Version vom November 2020 werden folgende Elemente beschrieben: fünf Events, drei Verantwortlichkeiten und drei Artefakte. 5 Events 3 Verantwortlichkeiten 3 Artefakte Die Events umfassen den Sprint, das Sprint Planning, das Daily Scrum, das Sprint Review und die Sprint Retrospektive. Der Kern des Frameworks ist der Sprint, der alle anderen Events beinhaltet. Es handelt sich dabei um eine Iteration mit konstanter Dauer und ähnlichen Abläufen. Das Sprint Planning eröffnet den Sprint. Hier wird bestimmt, welchen Wert der aktuelle Sprint hat, welche Aufgaben aus dem Product Backlog in den Sprint Backlog übernommen werden und wie diese umgesetzt werden. Für jeden Sprint wird ein spezifisches Ziel vereinbart. Das Daily Scrum ist ein tägliches Ereignis zur Synchronisation, Überprüfung des Fortschritts und, falls nötig, Anpassungen. Das Sprint Review ist ein Treffen am Ende eines Sprints zur Präsentation der Ergebnisse und zur Festlegung zukünftiger Anpassungen. Die Retrospektive dient der Reflexion über Prozesse, Werkzeuge, Fähigkeiten, Teamzusammenarbeit und Herausforderungen. Die drei Verantwortlichkeiten sind der Product Owner, der Scrum Master und die Entwickler. In Scrum organisiert sich das Team selbst innerhalb festgelegter Zeitspannen (Timeboxes), mit dem Ziel, regelmäßig und frühzeitig funktionsfähige Ergebnisse zu liefern. Der Guide spricht von Verantwortlichkeiten statt Rollen. Jede Person, die an einer Entwicklung oder einem Projekt beteiligt ist, übernimmt Verantwortung für Zuständigkeiten, Aufgaben, Commitments, Zusammenarbeit und Ergebnisse. Der Name Scrum stammt aus dem Rugby-Sport und beschreibt eine Spielsituation, bei der das Spiel auf Kommando neu gestartet wird. Zusätzlich gibt es drei Artefakte: Product Backlog, Sprint Backlog und Increment. Diese Artefakte repräsentieren Aufgaben und deren Umsetzung. Das Product Backlog enthält die Elemente für ein vom Product Owner definiertes Produktziel. Das Sprint Backlog ist der Plan für den aktuellen Sprint und umfasst alle ausgewählten Product Backlog Items, die im Sprint umgesetzt werden sollen. Ziel ist es, ein Increment zu erzeugen, das einen Wert liefert, funktionsfähig ist und der Definition of Done entspricht. Mit dem Abschluss eines Sprints beginnt der nächste, wodurch die Abfolge der Events, Verantwortlichkeiten und die Arbeit mit den Artefakten von neuem startet. Vorteile von Scrum Scrum bietet eine Lösung, wenn Vorhersagen und die Erstellung realistischer Pläne bei der Entwicklung von Software und Systemen schwierig sind. Das Framework basiert auf der Erkenntnis, dass Wissen aus Erfahrung entsteht und sich Erfahrung während der Entwicklung aufbaut. Dank des iterativen Ansatzes, der Commitments auf das Product Goal, das Sprint Goal und die Definition of Done sowie dem frühzeitigen Erkennen von Hindernissen (Impediments) wird die Vorhersagbarkeit erhöht und das Entwicklungsrisiko verringert. Zusammengefasst bietet Scrum folgende Vorteile: Möglichkeit, den laufenden Prozess im Projekt anzupassen, oft als Inspect & Adapt bekannt.
Entwicklungsteam – Zusammenarbeit bei der Implementierung von Software, Produkten oder Dienstleistungen Ein Entwicklungsteam besteht aus Personen, die gemeinsam an der Umsetzung von Software, Produkten oder manchmal auch Dienstleistungen arbeiten. Häufig sind diese Teams innerhalb eines Unternehmens organisiert, doch bei Kooperationen oder Joint Ventures können sie auch aus Mitgliedern verschiedener Organisationen bestehen. Die Struktur und Arbeitsweise eines Entwicklungsteams hängt vom jeweiligen Kontext ab. Einige Organisationen setzen auf umfassende Vorgehensmodelle wie das V-Modell XT, während andere auf agile Frameworks wie Scrum zurückgreifen oder hybride Ansätze kombinieren. Letztlich müssen Organisationen entscheiden, welches Vorgehen und welches Mindset am besten zu ihrem Entwicklungsteam passt. Das Entwicklungsteam im V-Modell XT Im V-Modell XT sind zahlreiche Rollen definiert, wie zum Beispiel Hardware-Architekt, Software-Architekt, Konfigurationsmanagement-Administrator und Prüfer. Jede Rolle hat eine formale Beschreibung, die Aspekte wie Aufgaben, Befugnisse, Fähigkeitsprofil, Rollenbesetzung und Verantwortlichkeit umfasst. Für kleinere Projekte können Mitarbeiter mehrere Rollen übernehmen, solange keine Interessenkonflikte bestehen. Das Entwicklungsteam in Scrum Scrum verzichtet auf die traditionelle Rollenzuweisung im Entwicklungsteam. Der Scrum Guide 2020 ersetzt den Begriff „Rolle“ durch „Verantwortlichkeit“ und unterscheidet zwischen drei Gruppen: Scrum Master, Product Owner und Entwickler. Anstatt von einem Entwicklungsteam wird nur noch von Entwicklern gesprochen. Diese Bezeichnungen beziehen sich nicht auf Stellenbeschreibungen, sondern auf die notwendigen Verantwortlichkeiten zur Ausführung von Scrum. In Scrum gibt es keine Hierarchie zwischen den Verantwortlichkeiten oder Entwicklern. Entscheidungen werden auf fachlicher Grundlage getroffen, und die Verantwortung liegt beim Team als Ganzes, nicht bei einzelnen Mitgliedern. Die Entwickler sind verantwortlich für: In der Praxis bedeutet dies, dass Entwickler: Obwohl Scrum keine spezifischen Rollen im Entwicklungsteam vorsieht, sollten die Teammitglieder idealerweise unterschiedliche Fähigkeiten besitzen. Der Erfolg des Teams hängt stark von der Kombination dieser Fähigkeiten ab. Falls ein Mitglied nicht über bestimmte Kenntnisse verfügt, unterstützt das Team bei der Entwicklung dieser Fähigkeiten. Das Sprint-Ziel kann nur gemeinsam erreicht werden.
Die Publikation „NIST Special Publication 800-34 Rev. 1“ dient als Leitfaden für die Notfallplanung von Bundesinformations-systemen und richtet sich an staatliche Einrichtungen (NIST 2010). Dieser Text ist Teil einer Reihe von „Special Publications“ des National Institute of Standards and Technology (NIST 2013) die Abteilung, die zur United States Department of Commerce gehört, beschäftigt sich allgemein mit Computer-Sicherheit durch Sonderpublikationen in der sogenannten 800-Serie. Diese Serie wurde im Jahr 1990 ins Leben gerufen. Die Special Publication 800 Serie informiert über die Forschung, Richtlinien und Bemühungen des ITL (Information Technology Laboratory) in Bezug auf Computersicherheit sowie über die Zusammenarbeit mit Industrie, Regierung und akademischen Organisationen.
Die ISO/IEC 27001:2005 ist eine internationale Norm, die auf dem britischen Standard BS 7799-2:2002 basiert und erstmals am 15. Oktober 2005 veröffentlicht wurde. Sie definiert die Anforderungen für die Entwicklung, Implementierung, Aufrechterhaltung und kontinuierliche Verbesserung eines dokumentierten Informationssicherheits-Managementsystems, das die IT-Risiken in der gesamten Organisation berücksichtigt. Ein spezifisches Kriterium darin ist das Business Continuity Management gemäß Abschnitt A.14. Um den genannten Anforderungen gerecht zu werden, sind konkrete „Kontrollen“ festgelegt. Ein Beispiel hierfür ist das Schwachstellenmanagement gemäß der ISO 27001. Schwachstellen sind weit verbreitet, wobei der Mensch oft als die größte Schwachstelle gilt. In Abschnitt 12.6 wird insbesondere auf technische Schwachstellen abgezielt. Das Risiko besteht darin, dass Schwachstellen ausgenutzt werden könnten, um unbefugten Zugriff auf die Informationswerte der Organisation zu erlangen (Kersten, H./Reuter, J./Schröder, K.-W. 2011, S. 247). Gemäß den Vorgaben von A.13.1.2 der ISO 27001 müssen alle Mitarbeiter, Auftragnehmer und externe Nutzer von Informationssystemen und -dienstleistungen dazu verpflichtet werden, sämtliche erkannten oder vermuteten Sicherheitsschwachstellen in den Systemen und Dienstleistungen zu erfassen und zu melden. In Kapitel A.14 der ISO 27001 wird die Geschäftskontinuität behandelt. Der Bereich Business Continuity Management (BCM) gemäß dieser Vorschrift zielt auf eine ganzheitliche Betrachtung der Geschäftsprozesse ab. Es geht darum: Des Weiteren behandelt die Norm Aspekte wie Prävention, Reaktion, Business Impact Analysis, Kritikalität, Wiederanlaufklasse und Vererbung, welche im Anhang genauer erläutert werden (Kersten, H./Reuter, J./Schröder, K.-W. 2011, 252ff). Die ISO/IEC 27002:2005 behandelt elf Überwachungsbereiche, die in 39 Hauptkategorien, genannt Kontrollziele, unterteilt sind. Diese werden weiterhin in 133 Sicherheitsmaßnahmen unterteilt, um die Erreichung der übergeordneten Kontrollziele zu fördern. Ein wichtiger Unterschied zwischen den beiden Normen besteht darin, dass eine Zertifizierung gemäß ISO/IEC 27002 nicht vorgesehen ist. Wenn ein Sicherheitsmanagementsystem im Unternehmen implementiert werden soll, kann dies nur durch eine Überprüfung gemäß ISO/IEC 27001 erreicht werden. Compliance beinhaltet die Einhaltung rechtlicher Vorgaben, Sicherheitsrichtlinien und die Durchführung von Audits. Im Herbst 2013 wurden die ISO 27001 und die ISO 27002 aktualisiert. Es liegt bereits ein Entwurf für beide Anpassungen vor. Neben neuen Inhalten und neuen Nummern für die Anforderungen umfasst der Entwurf nun lediglich neun Seiten mit Anforderungen an ein ISMS. Die „controls“ sind weiterhin im Annex A aufgeführt und beziehen sich auf die neue ISO 27002. Die erste Anforderung in der überarbeiteten ISO 27001 bezieht sich auf den Enterprise Risk Management Standard ISO 31000. Im Gegensatz zur vorherigen Version, in der die Behandlungsoptionen für Risiken als Akzeptieren, Verringern, Verteilen oder Vermeiden definiert waren, werden diese spezifischen Behandlungsoptionen nicht mehr in der ISO 27001:2013 gefordert. Unternehmen haben jedoch die Möglichkeit, sie weiterhin zu verwenden. Das PDCA-Modell, das in der ISO 22301 verwendet wird, wird in der aktualisierten ISO jetzt als „continual improvement“ bezeichnet, was eine Parallele zum Kapitel 10.2 der ISO 22301 darstellt.
Der ISO/PAS 22399 Standard, auch bekannt als „Societal security – Guideline for incident preparedness and operational continuity management“, basiert auf bewährten Verfahren aus fünf verschiedenen Ländern, darunter die USA (NFPA 1600:2400), Großbritannien (BS 25999-1:2006), Australien (HB 221:2004) und Israel (INS 24001:2007). Dieser Standard stellt einen umfassenden Managementprozess dar, der potenzielle Auswirkungen auf Organisationen identifiziert und einen Rahmen zur Minimierung ihrer Effekte bietet. Anstelle eines „BCM lifecycles“ verwendet dieser ISO-Standard einen „IPOCM lifecycle“, wobei IPOCM für „incident preparedness and operational (business) continuity management“ steht. Die Verwendung des Begriffs „operational continuity“ betont die Relevanz für alle Arten von Organisationen, unabhängig davon, ob sie öffentlich oder privat, kommerziell oder gemeinnützig sind (BCM 2007). Gemeinsam veröffentlichten das britische Normungsinstitut BSI (British Standard Institution) und das Business Continuity Institute (BCI) den Standard PAS. Dieser beschreibt mithilfe des BCM-Lebenszyklus die Verbindungen zu anderen Prozessen und bewährten Verfahren. Der Standard PAS 200:2011 konzentriert sich auf das Krisenmanagement (BSi 2011). Die British Standard Institution hat versucht, eine Lücke in der Notfallvorsorgeplanung zu erkennen. Zunächst liegt der Fokus auf dem Top-Management, erst danach auf den Mitarbeitern, die für die Umsetzung, Aufrechterhaltung und Überprüfung der Krisenmanagementverfahren verantwortlich sind. PAS 200 definiert eine Krise als eine „grundlegend abnormale, instabile und komplexe Situation, die eine Bedrohung für die strategischen Ziele, den Ruf oder die Existenz einer Organisation darstellt“. Nicht erwähnt wird, dass herkömmliches Krisenmanagement neben der Sicherstellung der Ressourcen für BCM-Pläne auch die koordinierte Unterstützung der handelnden Notfallteams bei Mitarbeiterbetreuung, Versicherungsangelegenheiten und Ersatzbeschaffungen sowie die zentrale Steuerung der internen und externen Kommunikation umfasst (Zänker 2011).
Die Norm BS 25999-1 „Business Continuity Management – Teil 1: Leitfaden“ definiert die Struktur eines Management-Systems für Business Continuity Management (BCI 2006). Dies umfasst die Organisationsstruktur, die Implementierung eines Business Continuity Management Prozesses gemäss bewährten Praktiken und die Entwicklung organisatorischer Maßnahmen. Es werden keine detaillierten Schritte oder konkreten Maßnahmen für das Notfallmanagement beschrieben. Es wird auf den britischen Standard BS 25999-2 „Business Continuity Management – Part 2: Specification“ verwiesen. Der Inhalt beschreibt die Anforderungen für die Zertifizierung eines Business Continuity Managements. Das zentrale Element ist das Programmmanagement, das Verantwortlichkeiten festlegt und die kontinuierliche Aufrechterhaltung der Geschäftsprozesse gewährleistet. Der Lebenszyklus nach BS 259999 besteht aus vier Phasen, die durch die Etablierung einer BCM-Kultur in der Organisation unterstützt werden: Der BS 25999-1 bietet geeignete Methoden und Werkzeuge zur spezifischen Ausgestaltung und Unterstützung bei der Umsetzung. Der BS 25999-2 markiert den Anfang des Business Continuity Managements. Die erste Version des BS 25999 wurde im November 2006 von der British Standards Institution veröffentlicht und umfasste eine Struktur, Prozesse, Prinzipien und erste Begriffe für das Business Continuity Management. Der zweite Entwurf erschien im November 2007 und beinhaltete die Einbeziehung der Interessengruppen in die BC-Pläne. Diese Einbeziehung wurde später mit der Veröffentlichung der ISO 22301 zurückgezogen (Everbridge 2011).
Das Business Continuity Institute (BCI) wurde im Jahr 1994 in den USA ins Leben gerufen, um eine hohe Qualität und Expertise im Bereich Business Continuity Management zu fördern. Die ersten „Good Practice Guidelines“ wurden im Jahr 2002 veröffentlicht, gefolgt von der deutschen Übersetzung im Jahr 2005. Mit über 120 Seiten bieten die Richtlinien des BCI einen der wenigen praktischen Leitfäden, die als Quasi-Standards gelten. Die Struktur ist wie folgt: Sektion 1: Die Entwicklung der BCM-Richtlinien und des Programm-Managements (BCM Policy & Programme Management) umfasst. Sektion 2: Understanding the Organization in Depth. Sektion 3: Entwicklung der BCM-Strategie (Developing BCM Strategy). Sektion 4: Die Entwicklung und Umsetzung von Maßnahmen zur Geschäftskontinuität (Developing and Implementing BCM). Sektion 5: Das Durchführen, Aufrechterhalten und Überprüfen von BCM-Maßnahmen (Exercising, Maintaining & Reviewing BCM Arrangements). Sektion 6: Integration von BCM in die Organisationskultur (BCI 2006).