Blog-Titel

Technologische Voraussetzungen für Agilität

Sun, 01 Jan 2023 13:15:38 GMT

Technologische Voraussetzungen für Agilität

Um auf agile Weise Software zum Beispiel mittels Scaled Agile Framework (SAFe) entwickeln zu können, müssen wesentliche agile Softwaretechniken vorhanden sein bzw. vorgängig umgesetzt werden (Mathis, 2018):

Emergentes Design und Architektur
Automatisiertes Testen und testgetriebene bzw. Test-First-Entwicklung
Refaktorisierung
Versionsverwaltung und kontinuierliche Integration
Pair-Programming/Pair-Work
Clean Code

Die oben aufgeführten Punkte sind einzelne Praktiken aus der agilen Softwareentwicklung, die für einen nachhaltigen Erfolg notwendig sind. Im Rahmen einer Nutzung von SAFe ist eine integrierte Qualitätskultur in einem Unternehmen erforderlich. Es ist eine irrige Annahme, durch weniger Qualität die Geschwindigkeit erhöhen zu können. Gemäss Mathis führen Fehler und andere Mängel in der Softwareentwicklung dazu, dass sich fatale Nebeneffekte ergeben; werden diese toleriert, verzögert sich die Entwicklung und wird weniger vorhersehbar. Um mit mehreren Scrum-Teams in SAFe skalieren zu können, ist es unabdingbar, dass eine Qualitätskultur gelebt wird.

Im Rahmen von SAFe wird von den Teams erwartet, dass diese eine testgetriebene Entwicklung durchführen sowie Fehler selbstständig entdecken und korrigieren, bevor sie ein Inkrement ausliefern. Gemäss Mathis sind Bugs keine Flüchtigkeitsfehler, sondern ein Indiz dafür, dass ein Entwicklungsprozess lückenhaft oder nicht optimal strukturiert ist. Im Gegensatz zu Scrum geht SAFe nicht von vierwöchigen Sprints, sondern von zweiwöchigen Iterationen aus. Um dieses Tempo halten zu können, ist es unabdingbar, dass Fehler umgehend behoben werden. Für die Fehlererkennung setzt agile Softwareentwicklung auf automatisierte Tests, um sicherstellen zu können, dass das auszuliefernde Inkrement (Software) funktionstüchtig ist.

Mathis führt zwei weitere Gründe an, die für eine Einhaltung dieser Qualitätskultur sprechen. Technisch zieht ein gebrochener Build es nach sich, dass sich neue Fehler unerkannt ein-schleichen und die Behebung überproportional aufwendiger wird. Die Vorteile eines stabilen Prozesses und einer zuverlässigen Aussage über den Stand der Entwicklung gehen verloren. Psychologisch vollzieht sich ein Bedeutungsverlust der Anforderung, möglichst fehlerfreie Software zu entwickeln – damit werden neue Fehler nicht mehr als gravierendes Problem wahrgenommen.

DevOps

Um agile Produkte entwickeln zu können, müssen Unternehmen neben den organisatorischen auch technologische Massnahmen treffen, damit ein Framework wie SAFe funktionieren kann. Das zentrale Ziel aller agilen Teams in SAFe ist die erfolgreiche Ausführung bzw. Lieferung funktionsfähiger Sprints und Releases der Programmziele des ART-PI. Dabei legt SAFe den Fokus auf DevOps als Voraussetzung. Deswegen nutzt SAFe auch sogenannte Enabler-Features. Enabler sind technische Initiativen, die dazu dienen, notwendige Fähigkeiten des Systems bereitzustellen.

Enabler kommen auf allen vier Ebenen vor und wurden vor-her als ‹Architektur-Epics›, ‹Architektur-Features› und ‹User-Storys› bezeichnet.

Die Teams planen ihre Tätigkeiten, demonstrieren ihre Lösungen, lernen gemeinsam aus Fehlern und verbessern und optimieren den Prozess sowie den Code fortlaufend, ähnlich wie dies aus anderen Methoden wie Total-Quality-Management (TQM) bekannt ist. Dadurch wird vermieden, dass sich die Teams ausschliesslich auf lokale Belange konzentrieren. Stattdessen arbeiten sie gemeinsam lösungsorientiert auf das übergeordnete Ziel hin bzw. fokussieren sich darauf, Lösungen zu erforschen, zu integrieren, bereitzustellen und freizugeben.

SAFe Prinzipien für einen effektiven Entwicklungsfluss

Wie die meisten Frameworks basiert auch SAFe auf bestehenden Modellen, die erfolgreich sind, und bedient sich ihrer. So nutzt SAFe unter anderem die Prinzipien von Don Reinertsen (2009) mit einer geringfügigen Erweiterung. Die Integration des Systemdenkens hat in SAFe eine besondere Bedeutung, wie es William Edwards Deming (2000) formuliert hat:

Ein System muss eine Intention haben, um zielgerichtet zu funktionieren.
Eine Optimierung eines Teils muss nicht das Gesamtsystem optimieren.
Ein System kann sich schneller als sein langsamster Integrationspunkt bewegen.
Ein kontinuierlicher Verbesserungsprozess sorgt für langfristigere Systemoptimierung als eine punktuelle Verbesserung.

Mit einem ergänzenden Einbezug des Managements stützt SAFe sich auf eine weitere These Demings (1993): Nur das Management kann ein System verändern. Daher nimmt SAFe das Management für die Entwicklung und die Strukturierung von Leadership (Führung) und Firmenkultur explizit in die Pflicht.

Um einen organisatorischen Nutzen mit einer agilen PM-Methodik wie SAFe erzielen zu können, ist es erforderlich, dass die technische Infrastruktur die agilen Anforderungen erfüllen kann. Wird dieser Punkt nicht oder zu wenig beachtet, besteht die Gefahr, dass die vermeintliche ‹Agilität› des Unternehmens sich als reines ‹Wunschdenken› entpuppt.

Literaturverzeichnis:

Scaled Agile Framework (2021). SAFe 5.0 Framework. Retrieved from https://www.scaledagileframework.com/
Mathis, C. (2018). SAFe - das Scaled Agile Framework: Lean und Agile in großen Unternehmen skalieren (2., überarbeitete und aktualisierte Auflage). Heidelberg: dpunkt.verlag.
Reinertsen, Donald G. (2009). The principles of product development flow. Celeritas.
Deming, Wiliam Edwards (1993). The new economics for industry, government, education.
Deming, Wiliam Edwards (2000). Out of the Crisis.

Vorgehensmodelle für die IT-Forensik

Tue, 27 Dec 2022 18:45:59 GMT

Welche Vorgehensmodelle für die IT-Forensik gibt es und welche Phasen beinhalten die Vorgehensmodelle?

Mit der zunehmenden Digitalisierung hat die Bedeutung der IT-Forensik in den letzten zwanzig Jahren zugenommen. Um Spuren zu sichern, analysieren und auszuwerten ist eine strukturierte, korrekte Vorgehensweise Pflicht, damit allfällige Beweise vor Gericht anerkannt und in Rechtsverfahren verwendet werden können.

Was ist IT-Forensik?

Die IT-Forensik ist ein Teilgebiet der Forensik und beschäftigt sich mit der methodischen Analyse von Vorfällen auf IT-Systemen und der gerichtsverwertbaren Sicherung von Beweisen. Ziel ist es, exakt festzustellen, welche Aktionen auf einem IT-System stattgefunden haben und wer Verursacher oder Verantwortlicher hierfür ist. (Luber 2018)

Welche Vorgehensmodelle kennt die IT-Forensik?

In der IT Forensik haben sich drei Vorgehensmodelle primär etabliert: das Modell des Bundesamts für Sicherheit in der Informationstechnik (BSI), das Modell des National Institute of Standards and Technology (NIST) und das Secure, Analyse, Present Modell, kurz SAP. Daneben gibt es weitere, weniger verbreitete Modelle, z.B. nach Eoghan Casey (Casey 2004) oder (Kruse and Heiser 2001). Diese Liste hat auf keinen Fall den Anspruch abschliessend zu sein, wir werden uns aber auf die drei Grossen konzentrieren.

Welche Phasen beinhalten die Vorgehensmodelle?

Die drei etablierten Vorgehensmodelle haben gemein, dass die Vorgehensweisen in Phasen unterteilt werden, die sich auf den ersten Blick ähneln. Unterschiede finden sich allerdings beim Beginn der beschriebenen Phasen und deren Abgrenzung voneinander.

SAP

Die Phasen des SAP-Modells sind auch gleich namens spendend: Secure, Analyse, Present. (Tietze Frank 2013)

In der Secure Phase werden alle vorhandenen Daten – unabhängig davon, ob ein juristischer Zusammenhang besteht – gesichert. Dabei spielt das Vier-Augen-Prinzip eine wichtige Rolle, um schlussendlich beweisen zu können, dass die Daten vor der Sicherung nicht verändert worden sind. Es ist für die Validität der Analyse zentral, dass die gesicherten Daten exakt dem Zustand der Systeme entsprechen und in keiner Weise verändert werden!

In der Analysephase werden die gesicherten Daten ausgewertet, Spuren festgestellt und darauf basierend Argumentationsketten entwickelt. Die entstehenden Ergebnisse sollen in diesem Schritt laufend reflektiert werden, um Fehlschlüsse und Lücken direkt zu erkennen und eine solide und nachvollziehbare Argumentation zu erhalten.

In der Present Phase werden die erarbeiteten Ergebnisse zielgruppengerecht aufgearbeitet und präsentiert. In dieser Phase liegt der Schwerpunkt darauf, dass auch technischen Laien der Ermittlungsprozess nachvollziehbar dargelegt werden kann.

NIST

Im Jahr 2006 hat das NIST ein eigenes Modell zur Durchführung von forensischen Verfahren publiziert (Kent et al. 2006). Das NIST unterteilt sein Modell in die Schritte Data Collection (Datensammlung), Examination (Untersuchung), Analysis (Analyse) und Reporting (Berichterstattung) und orientiert sich dabei weitestgehend am SAP-Vorgehensmodell. Der zentrale Unterschied besteht in der Aufteilung der Analysephase in die Phasen Examination und Analysis. Ziel ist, dass in der Phase Examination der Fokus rein auf die Sammlung von Fakten gelegt werden kann, die in der anschliessenden Phase der Analysis zu Information zusammengeführt werden können, wodurch eine Argumentationskette entsteht.

Die vorausgehende Phase der Data Collection und die abschliessende Phase des Reportings entsprechen weitestgehend den Phasen des SAP-Modells.

Figure 2 Forensischer Prozess nach NIST (Kent et al. 2006)

BSI

Das BSI-Vorgehensmodell beschreibt im Leitfaden für IT-Forensik sieben Phasen, die für den Erfolg einer forensischen Untersuchung zu beachten sind. (Bundesamt für Sicherheit in der Informationstechnik 2011)

strategische Vorbereitung
operative Vorbereitung
Datensammlung
Datenextraktion
Datenanalyse
Abschlussbericht
Dokumentation

Im Zentrum stehen hier die Schritte des SAP-Modells in einer abgewandelten Form, das BSI Modell unterscheidet sich aber von SAP und dem Modell vom NIST, indem es vorbereitende Schritte beschreibt, die der Betreiber eines IT-Systems vor einem Ereignis ergreifen kann. Die strategische Vorbereitung nimmt dabei explizit Bezug auf Massnahmen, die prophylaktisch umgesetzt werden können, während die operative Vorbereitung Massnahmen zur Vorbereitung des eigentlichen forensischen Prozesses beschreiben. Weiter kennt das BSI-Modell die Phase Dokumentation, die den gesamten Prozess begleitet und in einer Art Protokoll festhält.

Fazit

Unsere Recherchen haben gezeigt, dass sich heutzutage im Bereich der IT-Forensik die Modelle von BSI, NIST & SAP etabliert haben. Obwohl die Modelle sich bei den einzelnen Schritten im Detail unterscheiden, sind sie sich in den zentralen Schritten doch sehr ähnlich.

Literaturquellen

Publication bibliography
Bundesamt für Sicherheit in der Informationstechnik (2011): Leitfaden IT-Forensik.
Casey, Eoghan (2004): Digital evidence and computer crime. Forensic science, computers and the Internet. 2nd ed. London, San Diego, Calif: Academic Press. Available online at https://search.ebscohost.com/login.aspx?direct=true&scope=site&db=nlebk&db=nlabk&AN=189464 .
Kent, K.; Chevalier, S.; Grance, T.; Dang, H. (2006): Guide to integrating forensic techniques into incident response. Recommendations of the National Institute of Standards and Technology. NIST. Gaithersburg, MD.
Kruse, Warren G.; Heiser, Jay G. (2001): Computer forensics. Incident response essentials. Boston MA: Addison-Wesley.
Luber, Stefan (2018): Was ist IT-Forensik? In Security-Insider, 11/12/2018. Available online at https://www.security-insider.de/was-ist-it-forensik-a-774063/ , checked on 11/10/2021.
Tietze Frank, et al. (2013): Grundlagen der IT-Forensik.

Links:

Nationales Zentrum für Cybersicherheit (2021) https://www.antiphishing.ch/de/
Was ist IT-Forensik: https://www.security-insider.de/was-ist-it-forensik-a-774063/
Das SAP-Modell: https://de.wikibooks.org/wiki/Disk-Forensik/_Richtlinien/_Das_SAP-Modell

Ursachen für das Scheitern von Projekten

Mon, 26 Dec 2022 08:26:00 GMT

Nur 19 % der Projekte werden erfolgreich abgeschlossen

Gemäss der Studie «The Future of Project Management: Global Outlook 2019», welche auf einer Umfrage unter 500 Organisationen in 57 Ländern und unterschiedlichen Branchen basiert (KPMG, S. 6–7),

können nur 19 % der Projekte erfolgreich abgeschlossen werden,
werden nur 30 % der Projekte in der entsprechenden Zeit fertiggestellt,
wird nur bei 36 % der Projekte das Budget eingehalten,
konnten lediglich 58 % der durchgeführten Projekte den ursprünglich vereinbarten Umfang liefern und
sind nur 46 % der Stakeholder mit den Lieferergebnissen der Projekte zufrieden.

Eine weitere Studie, welche das Project Management Institute 2020 durchführte, zeigt, dass 67 % der Unternehmen aus verschiedenen Branchen, welche das Projektmanagement als strategische Kompetenz für den Wandel unterschätzen, Schwierigkeiten haben, Projekte erfolgreich umzusetzen und entsprechend bei der Umsetzung ihrer Projekte scheitern.

Weiter zeigt sich (PMI, 2020, S. 1–2), dass weltweit 1 Mrd. USD für Programme und Projekte ausgegeben wird sowie aufgrund unzureichender Projektleistungen im Durchschnitt 114 Mio. USD verschwendet werden . Damit wird ersichtlich, dass der grösste Teil der Projekte den gewünschten Nutzen bzw. die Investitionen nicht oder nur teilweise erfüllt – in den meisten Fällen mit Mehrkosten und Terminverzögerungen.

Ursachen für das Scheitern von Projekten

Gemäss einem Bericht von Soren Lauesen (2020, S. 72061) scheitern drei Viertel aller Informatiksoftwareprojekte an einer Vielzahl von Faktoren. Obwohl der Funktionsumfang reduziert wird, überschreiten die Projekte die Zeit- und Kostenvorgaben. In einer im Dezember 2008 durchgeführten Projektmanagementstudie war bei 44 % der gescheiterten Projekte auffällig, dass die drei Hauptkriterien ‹Qualität›, ‹Zeit› sowie ‹Kosten und Ressourcen›, die ein Projekt ausmachen, gleich häufig genannt wurden (Deutsche Gesellschaft für Projektmanagement & PA Consulting Group, 2008).

In einer im Jahr 2015 veröffentlichten Studie von Hays wurden über 200 Entscheider aus verschiedenen Branchen bezüglich des Projektmanagements interviewt. Demnach scheitert knapp jedes sechste Projekt in erster Linie aus drei Gründen:

Die Projektplanung sei nicht realistisch, wie 72 % der befragten Entscheider feststellten.
Relevante Entscheidungen würden nicht getroffen (67 %).
Zwischen den projektbeteiligten Fachbereichen mangele es an Kooperation (65 %).

Gemäss der Studie der Wirtschaftsprüfungsgesellschaft KPMG (Whittaker, 1999, 23 ff) werden lediglich 26 % aller IT-Projekte zeitgerecht beendet und 28 % aller Projekte gestoppt. Zudem übersteigen 46 % die geplanten Kosten, wobei das Go-live-Datum nicht eingehalten werden kann oder der erforderliche Funktionsumfang laut Projektauftrag nicht erreicht wird.

Scheinbar reagieren die Entscheidungsträger nicht, zu spät oder erst dann, wenn öffentlicher Druck entsteht, z. B. im Fall der Schweizerischen Exportrisikoversicherung (SERV) nach einem kritischen Bericht der EFK («Schweizerische ExportRisikoVersicherung stoppt 9-Millionen-Projekt», 2021). Die Ergebnisse all dieser Studien verstärken den Verdacht, dass die Steuerungsgremien auch massgeblich für den Misserfolg dieser Programme und Projekte verantwortlich sind.

Die fortlaufende Prüfung, ob ein Programm- oder Projekt auf Kurs ist oder den Projektauftrag einhält, ist fortlaufend unter anderem mittels der Projektstatusberichte kritisch zu verifizieren.

Literaturverzeichnis:

KPMG. The future of project management: Global Outlook 2019.
Project Management Institute® (2020). Pulse of the Profession® 2020: Research Highlights by Region and Industry.
Soren Lauensen. (2020). IT Project Failures, Causes and Cures.
Deutsche Gesellschaft für Projektmanagement & PA Consulting Group (2008). Ergebnisse der Projektmanagement Studie 2008: Erfolg und Scheitern im Projektmanagement.
Whittaker, B. (1999). What went wrong? Unsuccessful information technology projects. In-formation Management & Computer Security, 7(1), 23–30. https://doi.org/10.1108/09685229910255160 .
Schweizerische Exportrisikoversicherung stoppt 9-Millionen-Projekt (3. Dezember 2021). insideit. https://www.inside-it.ch/post/schweizerische-exportrisikoversicherung-stoppt-9-millionen-projekt-20211203 .

Projektreporting- Wichtiges Element für Steuerungsgremien

Tue, 24 May 2022 18:51:36 GMT

Projektreporting

Anhand des Reportings, welches die Projektleitung in der Regel monatlich einmal ausführt, erhalten die Projektausschuss-Mitglieder Einsicht in folgende Themen:

Gesamtbeurteilung des Projekts
Status zu Kosten bzw. Aufwand
Meilensteine
Personalressourcen
Ergebnisse bzw. Qualität
Risiken

Je nach Organisation wird in den meisten Fällen die Vorperiode mit der aktuellen Berichtsperiode dargestellt, sodass der Trend zu einer Verschlechterung oder einer Verbesserung direkt ersichtlich ist. Das Reporting ist neben dem direkten Austausch mit der Projektleitung für den Projektausschuss (PA) ein essenzielles Instrument, um Rückfragen und allfällige unterstützende Korrekturmassnahmen einleiten zu können. Alle Projektleiterinnen und Projektleiter müssen die Bewertungen nach den gleichen Prinzipien vornehmen, damit die Steuerungsgremien der Programm- und Projektorganisationen überall die gleichen Informationsgrundlagen verfügen.

Ein Punkt, der in den Steuerungsgremien besonders beachtet werden sollte, sind die Risiken. Einerseits muss die Projektleitung sich aktiv mit Risiken im Projekt befassen und diese fortlaufend überwachen. Andererseits muss das Steuerungsgremium sich regelmässig mit diesen kritisch auseinandersetzen. Das Steuerungsgremium hat einen wesentlichen Einfluss darauf, welche Risikotoleranz akzeptiert wird oder wie mit den jeweiligen Risiken umgegangen werden soll, wie die nachfolgende Auflistung zeigt:

Vermeidung (avoid)

Beseitigung des Risikos bzw. des Problems durch die Beseitigung der Ursache einschliesslich der Beendigung des Projekts, da ein Projekt resp. das verfolgte Vorhaben an sich ebenfalls ein Risiko darstellen kann.

Übertragen (transfer)

Indem wir eine andere Partei für das Risiko haftbar machen, übertragen wir das Risiko. Dies erreichen wir z. B. durch Versicherungen, Erfüllungsgarantien und Gewährleistungen, oder Outsourcing, um das Eigentum und die Haftung für Risiken durch die Beschaffung an eine andere Partei zu übertragen.

Abschwächen (mitigate)

Die Abschwächung eines Risikos kann ggf. mit entsprechenden Massnahmen, welche wir treffen, reduziert werden, sodass sich die Eintrittswahrscheinlichkeit oder die Auswirkungen verringern.

Eskalieren (escalate)

Die Eskalation wird verwendet, wenn das Projektteam oder der Auftraggeber zustimmt, dass eine Bedrohung den Rahmen des Projekts oder die vorgeschlagene Reaktion die Kompetenzbefugnisse z. B. in Bezug auf das Budget der Projektleitung und/oder der Auftraggeber/-in überschreitet.

Akzeptieren (accept)

Wir akzeptieren das vorhandene Risiko mit den möglichen Auswirkungen beim Eintreten, ergreifen aber keine proaktiven Massnahmen.

Der Projektausschuss muss sich aktiv mit dem Risikomanagement auseinandersetzen, um zum Erfolg eines Projekts beitragen zu können. Sind die Risiken, welche ein Projekt mit sich bringt, besonders hoch, kann und soll die Beendigung des Projekts in Betracht gezogen werden.

Der Projektauftrag - Die Grundlage für ein erfolgreiches Projekt

Tue, 24 May 2022 15:29:15 GMT

Der Projektauftrag

Wie im Beitrag ‹Ursachen für das Scheitern von Projekten› erläutert, wird als eine der häufigsten Ursachen für das Scheitern von Projekten u. a. die Projektplanung erwähnt. Ein Projekt besteht aus den drei Dimensionen ‹Umfang›, ‹Zeit› und ‹Kosten bzw. Ressourcen›.

Das bed eutet, dass auf der Steuerungsebene klar sein muss, welche Vorgaben der Projektleitung gemacht oder wie die drei Kriterien priorisiert werden. Denn von diesen fällt ein Kriterium immer negativ aus (Geirhos, 2011, S. 110–111):

schnell und günstig wird nicht gut
schnell und gut wird nicht günstig
günstig und gut wird nicht schnell

Unabhängig von der gewählten Projektmethode ist zwingend ein Projektauftrag zu formulieren, der möglichst einen detaillierten Umfang (Scope) hat und fortlaufend im Rahmen eines strikten Change-Management-Prozesses aktuell zu halten ist. Vor der Freigabe eines Projektauftrages muss das Steuerungsgremium den gleichen Kontext für alle Stakeholder sicherstellen. Das heisst, es muss der Nutzen geklärt werden, den die Stakeholder sich nach erfolgter Umsetzung des Projekts bzw. des Change erhoffen. Dies muss von Anfang an erfolgen, damit der Projektauftrag entsprechend präzisiert wird oder allfällige Prämissen und Abgrenzungen entsprechend ergänzt werden. Es kann sein, dass ein Projekt nicht alle Bedürfnisse vollumfänglich abdeckt, was sich aber so klären und festhalten lässt.

Verbindliche Terminvorgaben werden nur dann gemacht, sofern es regulatorische Vorgaben seitens des Gesetzgebers gibt. In vielen Unternehmen wird zuerst der Projektleitung der Endtermin mitgeteilt, obwohl der Umfang noch nicht besprochen worden ist. Wunschtermine können vorsichtig geäussert werden. Falls sie bonusrelevant sind, empfiehlt es sich, dies transparent zu kommunizieren. Es kann angenommen werden, dass die Projektleitung im Nachhinein den Grund dafür erfahren wird, weshalb der Fertigstellungstermin schon bekannt ist, obwohl das Projekt noch nicht begonnen hat. Sie sollte die Chance erhalten, das Projekt zu initialisieren, die Anforderungen abzuklären und die Projektplanung realistisch mit dem Team abzustimmen. Wenn der Auftraggeber oder der PA hier bereits Druck ausübt und die Projektleitung sich diesem fügt, besteht das Risiko, dass diverse Schritte entweder nicht fundiert abgeklärt werden oder das Projektteam den Termin ‹akzeptiert› und passiv zeigt, dass die Planung von Anfang an unrealistisch war. Der Terminplan kann ambitioniert ausgelegt werden, aber das Projektteam muss eine Chance haben, die definierten Ziele erreichen zu können. Folgende Massnahmen sind mit der Projektleitung zu prüfen:

Verdichten des Terminplans bzw. Verkürzung mittels Fast Tracking (InLoox GmbH, 2022b): Dabei werden Vorgänge, die i. d. R. nacheinander stattfinden, parallel ausgeführt.

Verkürzung des Terminplans mittels Crashing (InLoox GmbH, 2022a): Bei dieser Methode werden mehr Ressourcen für eine Aufgabe eingesetzt, um die Fertigstellung schneller erreichen zu können. Diese Methode kann in der Realität nur selten angewendet werden. Denn gewisse Arbeiten lassen sich durch den höheren Einsatz von Ressourcen nicht beschleunigen und wir haben die entsprechenden Ressourcen nicht immer mit der notwendigen fachlichen Qualifikation sowie Erfahrung zur Verfügung.

Einsatz eines während des Projekts vollständig der Projektleitung unterstellten dedizierten Projektteams : In Matrixorganisationen besteht für das Projekt das Risiko, dass die zugesicherten Ressourcen teilweise auch für z. B. Betriebsthemen eingesetzt werden. Je nach Unternehmensorganisation und -kultur kommt erschwerend hinzu, dass zwischen den Abteilungen und Teams keine konstruktive Zusammenarbeit gepflegt wird, sondern die Projektleitung jeden Schritt anstossen und überwachen muss. In solchen Fällen ist es hilfreich, dass die entsprechenden Projektmitarbeiter von einem Ort aus für das Projekt gemeinsam tätig sind.

Prozesse – Erteilen von Ausnahmebewilligungen : Es ist allgemein bekannt, dass grosse Organisationen über eine komplexere Prozesslandschaft verfügen als kleine inhabergeführte Unternehmen. Als PA-Mitglieder sollten wir versuchen zu verstehen, wo wir organisatorische Hindernisse haben und wie wir die Projektleitung hier unterstützen können, z. B. indem wir den Freigabeprozess vereinfachen.

Lessons Learned: Damit stellen wir sicher, dass allfällige Verbesserungsmassnahmen aus vergangenen ähnlichen Projekten in die Planung und Organisation einfliessen.

Stellen wir als Projektausschussmitglied die richtigen Fragen in Bezug auf den Kontext, die Terminplanung etc. und setzen wir allfällige Massnahmen bereits in Form eines überarbeiteten Projektauftrages um, ist die Wahrscheinlichkeit grösser, dass das Vorhaben erfolgreich starten wird. In dem überarbeiteten Projektauftrag sollte dann der Kontext verständlich und präzise beschrieben sein. Auch sollten entsprechende Prämissen und Abgrenzungen sowie organisatorische unterstützende Massnahmen für das Projekt enthalten sein.

Literaturverzeichnis:

Geirhos, M. (2011). IT-Projektmanagement. http://gxmedia.galileo-press.de.s3.amazonaws.com/leseproben/2875/galileocomputing_it_projektmanagement.pdf
InLoox GmbH. (2022a). Crashing / Verdichtung — Projektmanagement: Definitionen, Einführungen und Vorlagen. http://projektmanagement-definitionen.de/glossar/crashing/
InLoox GmbH. (2022b). Fast Tracking — Projektmanagement: Definitionen, Einführungen und Vorlagen. http://projektmanagement-definitionen.de/glossar/fast-tracking/

Mögliche Motivationsfaktoren für Wirtschaftskriminalität

Mon, 25 Apr 2022 18:45:31 GMT

Mögliche Motivationsfaktoren für Wirtschaftskriminalität

Die Wirtschaftskriminalität ist ein Thema, wovon grundsätzlich jede Organisation betroffen sein könnte. Um besser verstehen zu können, was mögliche Motive für die Verletzung ethischer Richtlinien oder von Compliance-Richtlinien sind, gehen wir in diesem Beitrag näher auf diese ein (Heissner, 2014):

Motiv: soziales Statusstreben

Jeder will erfolgreich sein und seinen Lebensstandard halten oder verbessern. Dies ist meistens mit dem Streben nach sozialem Status und Anerkennung verbunden.

Motiv: Notlagen und Verpflichtungsgefühl

Finanzielle Notlagen können Menschen in Situationen bringen, in denen sie wirtschaftliche Straftaten begehen oder sich einen Weg suchen, um in kurzer Zeit ein zusätzliches Einkommen zu generieren.

Motiv: Hörigkeit gegenüber Autoritäten

Auch Autoritätshörigkeit kann ein Motiv sein, abweichend zu handeln. Wenn alle Anweisungen von Vorgesetzten vorbehaltlos ausgeführt werden – wie es in vielen Konzernen gängig ist – steigt das Korruptions- und Betrugsrisiko. Denn ein anonymes Melden und Anzeigen solcher Handlungen wie durch Whistleblowing-Systeme wird hier nicht als Aufrichtigkeit, sondern als Verrat erlebt.

Motiv: Pragmatismus

Betriebswirtschaftlicher Pragmatismus kann auch zum Motiv wirtschaftskrimineller Handlungen werden, wenn zum Beispiel an einen Verkäufer eines grossen Baukonzerns gedacht wird, welcher schon 20 Jahre oder länger für sein Unternehmen tätig ist und eine gewisse Routine entwickelt hat, die ‹Tricks› beinhaltet, um beispielsweise Prozesse zu umgehen oder mit Gefälligkeiten Aufträge zu erhalten.

Motiv: Unwissenheit

Zwar ist Unwissenheit nicht straffrei. In der Beurteilung und Sanktionierung von Wirtschaftskriminalität muss trotzdem beachtet werden, ob ein Delikt vorsätzlich oder fahrlässig begangen wurde. Ein Unternehmen bzw. das Steuerungsgremium muss sicherstellen, dass die Mitarbeiter sowohl die gesetzlichen als auch die Compliance-Richtlinien und deren Veränderungen verstehen sowie anwenden.

Motiv: Karrierestreben

Das Karrierestreben Einzelner kann zum Motiv für Wirtschaftskriminalität werden. Wer aufsteigen will, kommt fast zwangsläufig in die Situation, Bilanzen, Zeugnisse und sonstige Unterlagen zu manipulieren oder zu fälschen.

Motiv: Langweile

Auch Langeweile kann zum Motiv doloser Handlungen werden. Der Reiz, Grenzen auszuloten und zu überschreiten, ist tief im Menschen verankert und sollte nicht unter-schätzt werden.

Motiv: Leistungsdruck

Ein häufiger Fall bei der Entstehung von Korruption ist der Druck auf die Performance von Angestellten. Oftmals unterschätzen Führungskräfte den Leistungsdruck auf ihre Mitarbeiter. Sind Zielvorgaben zu ambitioniert oder unmöglich zu erreichen, sind Manipulation und Fälschung häufig der einzige sich bietende Ausweg.

Motiv: Rache

Immer wieder kommen Mitarbeiter in Situationen, in denen sie sich gedemütigt oder persönlich angegriffen fühlen.

Motiv: soziale Anerkennung

Häufig wünschen sich Mitarbeiter im Verkauf und Vertrieb Anerkennung. Durch gelegentliches Lob, ehrliche Wertschätzung sowie aktives Zuhören von Führungskräften könnten manche Delikte im Vorfeld verhindert werden.

Motiv: Gruppenzwang

In Unternehmensbereichen wie dem Einkauf, dem Handel oder dem Aussendienst wird häufig erwartet, uneingeschränkt zu kooperieren.

In einer multikulturellen Gesellschaft kann nicht davon ausgegangen werden, dass alle Mitarbeiter eines Unternehmens und seiner Partnerfirmen die gleichen Moralvorstellungen haben. Wir können nicht davon ausgehen, dass alle Menschen die gleichen Moralvorstellungen haben, und zwar unabhängig von der Herkunft und der Kultur, zeigt der Fall von Pierin Vincenz, der aktuell die Schweizer Gerichte und die Medienlandschaft beschäftigt (Nordwestschweiz Netz, 2020). Hierbei ist zu entscheiden, ob es moralisch vertretbar ist, dass ein angestellter Geschäftsführer mit einem Jahresgehalt von über 2 Mio. Schweizer Franken insgesamt über 200'000 Schweizer Franken für Champagner, Cabaret-Besuche und Stripperinnen ausgegeben, mit der Firmenkreditkarte bezahlt und als Geschäftsspesen abgerechnet hat. Dieses Beispiel zeigt, dass das Definieren, Kommunizieren und die fortlaufende Sensibilisierung hinsichtlich ethischer Richtlinien von zentraler Bedeutung sind. Bei nationalen und insbesondere bei internationalen Programmen oder Projekten gewinnt diese Thematik entsprechend an Bedeutung, wenn Mitarbeiter unterschiedlicher Kulturen involviert sind.

Es ist daher für Unternehmen empfehlenswert, über alle Hierarchiestufen hinweg klar definierte ethische Richtlinien zu definieren, die Mitarbeiter über diese zu orientieren und diese anzuwenden.

Literaturverzeichnis:

Heißner, S. (2014). Erfolgsfaktor Integrität: Wirtschaftskriminalität und Korruption erkennen, aufklären, verhindern (2. Aufl.). Springer eBook
Nordwestschweiz Netz (10. November 2020). Ex-Raiffeisen-Chef - Geld, Macht und Sex: Pierin Vincenz und die männliche Illusion der Unverwundbarkeit. Aargauer Zeitung AG. https://www.aargauerzeitung.ch/leben/geld-macht-und-sex-pierin-vincenz-und-die-mannliche-illusion-der-unverwundbarkeit-ld.1277444

Was ist ein komplexes Projekt?

Fri, 17 Dec 2021 16:19:32 GMT

Was ist ein komplexes Projekt?

Das Thema ‹Agilität› hat sich in den letzten Jahren zu einem Trendthema auf vielen unternehmerischen Führungsebenen entwickelt. Die agile Vorgehensweise, welche ihren Ursprung in der Softwareentwicklung hat, wird zunehmend auf andere firmeninterne Bereiche ausgeweitet: So kann beispielsweis die Anwendung von Scrum unter anderem damit begründet werden, komplexe Projekte unkomplizierter und effizienter abwickeln zu können, wie die folgende Abbildung zeigt.

Aber was ist ein komplexes Projekt? Hier stellen wir immer wieder fest, dass es sehr unterschiedliche Ansichten gibt, insbesondere im agilen Bereich. Während Product Owner und Scrum Master Ihre Tätigkeiten als komplexe Projekte bezeichnen, teilen Berufsprojektleiter diese Sichtweise nicht oder nicht immer. Auch denken wir, dass man in vielen Fällen nicht von Projekten sprechen kann, da es sich gemäss Definition nicht um Projekte handelt. Dabei möchte ich keineswegs die Vorhaben welche z. B. mit Scrum ausgeführt werden nicht wertschätzen, im Gegenteil. Die Umsetzung der jeweiligen Sprints sind teilweise sehr anspruchsvoll und fordern von den Scrum Team viel ab. Beginnen wir zuerst mal bei der Definition eines Projekts. Wann können wir von einem Projekt reden?

Gemäss der Norm ‹DIN 69901› lautet die Definition für ein Projekt wie folgt (Haagen 2010):

«Ein Projekt ist ein Vorhaben, das im Wesentlichen durch Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist, wie z. B.: Zielvorgabe, zeitliche, finanzielle, personelle oder andere Bedingungen, Abgrenzungen gegenüber anderen Vorhaben und projektspezifische Organisation.»

Brunno Jenni (Trainer & Dozent bei der Beratungsfirma SPOL AG) formuliert noch präziser, was unter einem Projekt zu verstehen ist (Honegger 2020):

«Projekte sind in sich abgegrenzte, komplexe und/oder komplizierte Aufträge, deren Erfüllung eine Organisation bedingt, die für die Umsetzung der Tätigkeiten eine Projektmethode anwendet, mit der alle anfallenden Arbeiten geplant, gesteuert, durchgeführt und kontrolliert werden können.»

Generell werden unter Projekten keine wiederkehrenden Prozesse oder routinierten Betriebstätigkeiten verstanden.

So gesehen können die Tätigkeiten zahlreicher Scrum Teams in Organisationen gemäss Definition nicht als Projekte bezeichnet werden, weil das Scrum Framework mit den Sprints keine klaren Zielvorgaben mittels einem Projektauftrag festlegt, welche Leistungen bis wann und zu welcher finanziellen Investition erbracht wird. Aus meiner Sicht geht ein Projektsponsor bei rein nach Scrum geführten Vorhaben ein grösseres Risiko ein, als wenn seine Anforderungen nach klassischen oder nach hybriden Projektmethoden realisiert werden. Weiter bleibt das Scrum Team im Gegensatz zu klassischen Projekten längerfristig bestehen. Auch wenn jeder Sprint in sich als ein kleines, abgeschlossenes Vorhaben betrachtet wird, zu dem sich das Scrum Team verpflichtet, die geplanten Tätigkeiten im Rahmen der gesetzten Frist zu erledigen, erfüllt Scrum die Definition eines Projekts aus meiner Sicht nicht.

Unter dem Begriff ‹komplexe ICT-Projekte› verstehen wir Projekte, welche folgende Merkmale erfüllen:

Es handelt sich nicht nur um ein reines Software-Entwicklungsprojekt.
Es sind mehrere interne und/oder externe Organisationseinheiten involviert.
Es sind mehrere Stakeholder mit divergierenden Interessen involviert.
Es müssen regulatorische Vorgaben berücksichtigt und eingehalten werden.
Es müssen mehrere technische und organisatorische Elemente und Schnittstellen implementiert oder angepasst werden.

Scrum hat durchaus seine Existenzberechtigung und wird vor allem in der Softwareentwicklung erfolgreich eingesetzt. Für die Umsetzung von komplexen Projekten betrachten wir aufgrund unserer Erfahrungen der vergangenen Jahre den Einsatz einer klassischen oder hybriden Projektmanagementmethode als erfolgversprechender.

Literaturverzeichnis:

Hagen Stefan . (2010). Wann ist ein Projekt ein Projekt? https://pm-blog.com/2010/03/15/wann-ist-ein-projekt-ein-projekt/
Honegger, B. D. (2020). Beats Biblionetz - Begriffe: Projekt. Rhoneetrieved from https://www.beat.doebe.li/bibliothek/w00889.html

Hybrides Projektmanagement

Wed, 02 Dec 2020 15:56:59 GMT

Hybrides Projektmanagement

Laut Duden.de (Duden 2021b) wird der Begriff ‹hybrid› als «eine Mischung, ein Gebilde aus zwei oder mehreren Komponenten» definiert. Wenn im Projektmanagement von hybriden Modellen gesprochen wird, ist entweder die Kombination von zwei oder mehr Projektmanagement-Methoden gemeint oder die situationsabhängige Auswahl und der Einsatz einzelner Elemente bzw. Methoden durch den Projektleiter in einem Projekt.

Aber wann macht den ein hybrides Projektmanagementmodell Sinn?

Hybride Projektmanagementmethoden sind bei komplexen ICT-Projekten sinnvoll und kommen vermehrt zum Einsatz, wo nebst der Software Entwicklung auch Anpassungen im Bereich der Infrastruktur und der Unternehmensorganisation vorgenommen werden soll. Hybrides Projektmanagement ist die Königsdisziplin, da hier die Projektleitung die eingesetzten Methoden klassisch wie auch agil verstehen und beherrschen muss.

Spätestens mit der siebten Edition von PMI , welche im August 2021 veröffentlicht wurde, hat sich PMI von den Prozessen und Wissensgebieten verabschiedet und beinhaltet neu 12 Leitprinzipien, die stark na die 12 Prinzipien des agilen Manifests erinnern. Mit dieser radikalen Änderung soll der Glaubenskrieg beendet werden und der Ansatz zur Anwendung kommen, welcher am erfolgversprechendsten ist. In IPMA werden hybride Ansätze unterstützt, wobei sich diese aus den jeweiligen Kompetenzbereichen zusammensetzen. In komplexen ICT-Projekten zerlegt die Projektleitung den Projektauftrag auch in begrenzte, unkomplizierte Arbeitsaufträge (sog. Drill-Down), um die Komplexität zu reduzieren. Dies ähnelt dem Product Backlog im Scrum-Konzept. Der Projektleiter agiert in IPMA und PMI agil und prüft situativ, welche Lösung für die Zielerreichung am erfolgversprechendsten ist, bevor er diese anwendet.

HERMES unterstützt ebenfalls ein agiles Projektmanagement für die Entwicklung von Produkten und Systemen, wobei hier auf die Scrum-Methodik zurückgegriffen wird. Das Zusammenspiel erfolgt so, dass Scrum innerhalb der Softwareentwicklung und HERMES-spezifisch angewendet wird. HERMES-spezifisch bedeutet hier, dass ein eindeutiger Start und ein eindeutiges Ende definiert werden. In HERMES kann die Rolle des Product Owner durch den Business-Analysten, den Projektleiter des Anwenders, die Anwendungsverantwortlichen oder den IT-Architekten übernommen werden.

Vor dem Beginn der Softwareentwicklung muss ein Entscheid über die Systemarchitektur getroffen werden. Die sonstigen Abläufe und Events gleichen denen in Scrum. Das Scrum-Team in HERMES wird ebenfalls durch den Product Owner respektive das Product Backlog und nicht durch den Projektleiter gesteuert. Alle anderen Gruppen, die ausserhalb des Entwicklungsbereichs tätig sind, werden von der Projektleitung beauftragt und koordiniert. Die nachfolgende Abbildung zeigt eine hybride Form, die auf HERMES und Scrum basiert:

Im offiziellen Scrum-Konzept werden hingegen keine Anpassungen oder hybriden Formen zugelassen, da es sich aus Sicht der Erfinder dann nicht mehr um Scrum handeln würde (Schwaber und Sutherland 2020).

Die Akzeptanz von hybriden PM-Methoden, die bereits heute eingesetzt werden, ist in den Bundesbetrieben hoch. Die Projektleitung sollte die Entscheidung bezüglich der anzuwendenden Methodik situativ treffen, sofern diese innerhalb der Unternehmensorganisation die Kompetenz dazu hat. In vergangenen Vorhaben konnten wir hybride Projektmanagement-Methoden, in denen HERMES und Scrum kombiniert wurden, bereits erfolgreich anwenden.

Agile wie klassische Methoden haben eindeutig ihre Vor- und Nachteile. Eine Kombination von beiden Ansätzen ist daher aus unserer Sicht am erfolgversprechendsten. Die Bundesbetriebe haben aktuell keine andere Möglichkeit, als ein hybrides Modell zu wählen, da HERMES als Standard vorgegeben ist. Von den hier erwähnten PM-Methoden bietet PMI wie auch IMPA aus meiner Sicht die besten Ansätze, weil der Projektleiter mit seinen Fähigkeiten (Kompetenzen) situativ für das Projekt entscheiden kann, welche Vorgehensweise am erfolgversprechendsten ist. Letztendlich ist dies das Hauptziel, dass alle Projekte verfolgen (sollten).