Podcasts about projektrisiken

Die Rüstungsindustrie steht seit Wochen im Rampenlicht der Finanzmärkte. Ist der Boom wirklich nachhaltig? Wiederholt sich ein gefährliches Muster vergangener Hypes? Das nächste Finanz-Seminar ist in Planung. Wer dabei sein möchte oder Fragen hat, meldet sich gerne. Einfach E-Mail an: krapp@abatus-beratung.com Viel Spaß beim Hören, Dein Matthias Krapp (Transkript dieser Folge weiter unten)   NEU!!! Hier kannst Du Dich kostenlos für meinen Minikurs registrieren und reinschauen. Es lohnt sich: https://portal.abatus-beratung.com/geldanlage-kurs/    

Vor Risiken verschließt man gerne die Augen. Das gilt für große Projekte, in denen die Beteiligten selbst offensichtliche Risiken gerne einfach nicht wahrhaben wollen. Und umso mehr gilt es für kleinere Projekte: »Das wird schon hinhauen«, lautet hier meistens die Devise. Ein Fehler! Projektrisiken verschwinden nicht, nur weil wir uns weigern, sie zur Kenntnis zu nehmen. In der heutigen Sendung geht es deshalb um die Frage, wie man Risiken im Projekt entdeckt.

Vor Risiken verschließt man gerne die Augen. Das gilt für große Projekte, in denen die Beteiligten selbst offensichtliche Risiken gerne einfach nicht wahrhaben wollen. Und umso mehr gilt es für kleinere Projekte: »Das wird schon hinhauen«, lautet hier meistens die Devise. Ein Fehler! Projektrisiken verschwinden nicht, nur weil man sich weigert, sie zur Kenntnis zu nehmen.Mehr zu dieser Sendung erfahren Sie unter www.projekt-safari.de/podcasts.

Heute erkläre ich euch wie ihr die Risiken eures wichtigen Projektes oder die Schwächen eurer Präsentation innerhalb weniger Minuten entdeckt und wie man diese Risiken reduziert - mit einem PreMortem. Diese aus meiner Sicht simpelste Risikovermeidungs-Methode benutze ich bei meinem Design Thinking Workshops fast immer.  #DesignThinking, #futureskills, #Innovation, #Kreativität - absurd einfach erklärt --- Send in a voice message: https://anchor.fm/simply-good-life/message

Risikomanagement ist Projektmanagement für Erwachsene. In dieser Episode zeige ich Dir 50 Projektrisiken, die Du unbedingt kennen solltest. Ich habe die Risiken nach unterschiedlichen Gruppen sortiert, so dass Du Dich leichter orientieren kannst. In dieser Episode erfährst Du: - Was sind Risiken - Welche 50 Projektrisiken solltest Du unbedingt kennen Zusätzlich findest Du die Projektrisiken als Checkliste in der Online-Bibliothek: https://bibliothek.projektmanagement-maschinenbau.de Link zur Episode https://www.projektmanagement-maschinenbau.de/pmmb092

Klassischerweise wird versucht, Projektrisiken durch Projektmanagement wegzuverwalten. Das klappt nicht immer, weil ein Teil der Risiken aus der natürlichen Unsicherheit kommt, die daher kommt, dass Sie mit attraktiven Produktentwicklungen zwangsweise Neuland betreteten. Risiken können also nicht wegverwaltet werden. Das ist zwar ein wichtiger Schritt, es braucht aber noch mehr Elemtente.

Nachdem mich 2 Hörerzuschriften mit der Bitte erreicht haben, doch mal eine Podcastfolge über das Thema Risikomanagement zu machen, habe ich mich entschlossen die Folge heute und nächstes Mal ganz diesem Thema zu widmen. Risikomanagement ist eine präventive Maßnahme, sowohl für Unternehmen und insbesondere für Projekte. Es ist das Radar der Projektleitung. Risikomanagement dient dazu, besonnen potenzielle Projektrisiken zu beleuchten und sie durch geeignete Maßnahmen entweder unwahrscheinlicher machen, oder die Auswirkungen beim Eintritt maximal zu vermindern. Dafür ist ausreichend Zeit einzuplanen. Ein Projekt, das sich im ständigen „Firefighting Mode“ befindet, hat meist keine Zeit mehr um Risiken zu managen. Solche Projekte agieren nicht mehr, sondern sie reagieren nur noch. Im ersten Teil dieser Folge beschäftigen wir uns mit den Grundlagen des Risikomanagements. Was ist der Unterschied zwischen einem Risiko und einem Problem und wie geht man mit ihnen um? Welche Strategien gibt es mit Risiken umzugehen. Diese und noch weitere Fragen werden in dieser Folge behandelt. In der kommenden folge beschäftigen wir uns dann mit der Frage, wie Risikomanagement im Projekt effizient eingeführt wird. Weitere Informationen finden Sie unter www.Bundesvereinigung-ITPM.de

Anforderungsmanagement Der Fachbuchautor Christof Ebert schreibt in seinem Buch „Systematisches Requirement Engineering“: „Früher dachte ich, Termin und Budgetüberschreitungen kommen von schlechter Schätzung. Dann dachte ich, sie kommen von hoher Komplexität. Heute weiß ich, dass sie davon kommen, dass praktisch alle Projekte zu spät begonnen werden. Dann fehlt die Zeit für die Anforderungsanalyse und Planung. Damit ist das Scheitern vorprogrammiert.“ (Ebert, 2012) Die Einsicht deckt sich auch mit meinen Erfahrungen der letzten 20 Jahre. Und das unabhängig ob es sich um Auftragsentwicklungen, oder interne Unternehmensprojekte handelt. Es wird viel Zeit in die Akquise und die Verhandlungen zu einem Projekt gesteckt. Der Auftrag liegt auf dem Tisch und das Projektteam steht womöglich auch schon in den Startlöchern. Jetzt müssen sie schnell produktiv werden. Da ist die Verlockung groß, die Anforderungen nicht weiter ins Detail zu zerlegen und abzustimmen, sondern schon mal beginnen zu lassen. Aber was versteht man eigentlich genau unter einer „Anforderung“? Eine Anforderung beschreibt, was der Kunde, Auftraggeber oder Benutzer vom zu entwickelnden Produkt erwartet (Nutzen, Eigenschaften, Verhalten, Attribute, Mehrwert) „Könntest Du mir bitte sagen, welchen Weg ich von hier aus nehmen soll?“, fragt Alice im Wunderland die Katze am Wegesrand. „Das hängt vor allem davon ab, wohin Du gehen willst“, antwortet diese. „Ich weiß es nicht…“, sagte Alice. „Dann ist es egal, wohin Du gehst“, antwortet die Katze. (Carroll, 1865) Auch wenn dieser amüsante Dialog aus dieser herrlichen Geschichte witzig anmutet, steckt doch sehr viel Weisheit darin. Ohne ein klares Ziel, wird uns der Weg den wir gehen irgendwo hinbringen. Auf das IT Projektgeschäft übertragen ist es damit aber reiner Zufall wenn wir das treffen, was der Kunde eigentlich wollte. Viel höher ist die Wahrscheinlichkeit dass wir völlig daneben liegen. Fällt das in einem frühen Projektstadium auf, können mittels Changerequest vielleicht noch notwendige Änderungen eingesteuert werden. Je später im Zeitverlauf eines Projektes aber noch Änderungen durchgeführt werden, desto größer sind die Auswirkungen. Das betrifft sowohl Wechselwirkungen mit der Änderungen mit bereits realisierten Systemteilen, als auch Auswirkungen bestehende Dokumentationen und Architekturen. Damit ist ein Designfreeze so früh wie möglich anzustreben und ab dann Änderungen nur noch über einen geregelten Prozess zuzulassen. Dieser intensiv zu managende Änderungsprozess muss die Auswirkungen von ChangeRequests transparent machen. Dafür ist kompetentes Personal einzuplanen. Nur wenn die Auswirkungen und damit Risiken einer Änderung im Detail klar sind, kann über ihre Umsetzung entschieden werden. Mit diesem kleinen Ausflug in das Änderungsmanagement wird klar, dass es deutlich besser ist, Änderungen nach Möglichkeit zu vermeiden. Ist diese Aussage aber richtig, wenn man sich moderne agile Entwicklungsmethoden ansieht, die Änderungen willkommen heißen? Ich glaube ja, denn auch bei agilen Methoden sind klare Anforderung die Basis für den Projekterfolg. Doch Anforderungen sind per Definition unsicher. Christof Ebert schreibt dazu in seinem Buch, dass sich Anforderungen mit einer monatlichen Rate, die 1-5% des gesamten Projektauftrags betragen ändern. Das heißt, dass von Anforderungen, die mit insgesamt 100 Personenwochen Projektaufwand abgeschätzt wurden, sich pro Monat Anforderungen im Umfang von bis zu 5 Wochen ändern! Diese 5 Wochen relative Änderung sind nicht immer mit 5 Personenwochen Aufwand zu erledigen. Stellen Sie sich vor, dass die Änderung erst kommt, nachdem die Anforderung bereits integriert ist. Dann kann eine Änderung ein Vielfaches des ursprünglich dafür notwendigen Aufwands betragen. Diese Hebelwirkung unterstreicht nochmals den Geschäftsnutzen eines systematischen Requirement Engineerings. Was über dieser 5% Änderungsrate pro Monat liegt, gefährdet den Projektverlauf massiv und die daraus resultierenden Projektrisiken können nur mit iterativen oder agilen Vorgehensweisen kompensiert werden. Die Standish Group erstellt seit 1994 alljährlich den Chaos Report der sich mit dem Erfolg- bzw. Misserfolg von IT Projekten beschäftigt. Sie gehört zu den bekanntesten und wichtigsten Langzeitstudien im Bereich Projektmanagement, seit 1994 wurden über 40.000 Einzelprojekte wissenschaftlich untersucht. Die Studie unterteilt in Typ1, Typ2 und Typ3 Projekte. • Typ 1 • Projekt erfolgreich abgeschlossen: Das Projekt wurde rechtzeitig, ohne Kostenüberschreitung und mit dem ursprünglich geforderten Funktionsumfang abgeschlossen. • Typ 2 • Projekt teilweise erfolgreich: Das Projekt wurde abgeschlossen, es kam jedoch zu Kosten- und/oder Zeitüberschreitungen oder es wurde nicht der vollständige geplante Funktionsumfang erreicht. • Typ 3 • Projekt nicht erfolgreich: Das Projekt wurde abgebrochen. Die Studie untersucht Ursachen für Erfolg und Misserfolg und stellt eine Korrelation zwischen Erfolgswahrscheinlichkeit und Projektgröße fest. Die festgestellten Haupterfolgsfaktoren sind: 1. Einbindung der Endbenutzer 2. Unterstützung durch das obere Management 3. Klare Anforderungen Die Hauptpunkte, die zum Scheitern der Projekte führen sind: 1. fehlende Zuarbeit durch Benutzer 2. unvollständige/unklare Anforderungen 3. häufige Anforderungsänderungen (http://de.wikipedia.org, 2015) Auch wenn die Studie in den letzten Jahren stark unter Kritik stand und vor allem die von der Standish Group unbelegten Abbruchzahlen angezweifelt werden, die Studie bestätigt das Paradigma moderner Projektmanagementsysteme, klare Anforderungsdefinition und intensive Einbindung der aller Stakeholder in das Projekt zu forcieren. Interessant in diesem Zusammenhang ist auch die Beobachtung, dass in Krisenzeiten wie in den Jahren 2001 nach dem 11. September und 2008 in der Wirtschaftskrise die vermeintlich unnötigen Ausgaben für Anforderungsmanagement und Reviews drastisch reduziert wurden. Dies hatte jeweils dramatischen Einfluss auf die Projekterfolge der betreffenden Jahre. Christof Ebert resümiert in seinem Buch „Technologische Herausforderungen sind keine gravierenden Projektrisiken. Schlechtes Projektmanagement dagegen schon.“ (Ebert, 2012) Doch wo sind die Schwierigkeiten zu klaren Anforderungen zu kommen? Da ist wie oben bereits erwähnt häufig einfach der Zeitfaktor. Doch wie wichtig es für den Anforderungsmanager ist, Anforderungen immer weiter herunter zu brechen und zu hinterfragen zeigt die Praxis. Mit den folgenden Beispielen möchte ich das etwas deutlicher machen: • Beispiel1: Der Auftraggeber erwähnt Funktionen nicht, weil sie für ihn selbstverständlich sind o Hier muss die Devise lauten, „denken Sie nicht für Ihren Auftraggeber, sondern lassen Sie es sich erklären“. Der Auftraggeber und seine Vertreter sind in der Regel die Spezialisten für das was am Ende herauskommen soll. Als Anforderungsanalyst lässt man sich hier häufig schnell dazu verleiten zu glauben verstanden zu haben und nicht weiter fragen. Sprechen Sie aus was Sie glauben verstanden zu haben und lassen Sie sich ihre Auffassung bestätigen. Sie kennen die Bedürfnisse des Kunden und das was er braucht, niemals so gut wie er selbst. Eine der Schlüsselregeln im Requirement Engineering besagt, dass man dem Kunden das liefern muss was er will und nicht das, was er (vermeintlich) braucht. • Beispiel2: Schwammig formuliere Anforderungen o Schwammige Formulierungen sind irgendwie tierisch bequem- für beide Seiten. Deshalb sind sie ja auch so beliebt. Der Auftraggeber soll sich festlegen- weiß aber im Detail vielleicht gar nicht so genau was er will. Gut wenn die Formulierung da butterweich formuliert ist und man da am Ende noch jede Menge Interpretationsspielraum hat was eigentlich gemeint war. o Auf der anderen Seite ist da natürlich die Auftragnehmer Seite. Auch hier sind schwammige Formulierungen eine bequeme Sache- vor allem wenn man noch nicht so genau weiß wie man es machen will und was das Ergebnis wirklich alles können wird. o Schwammige Anforderungen sind also allseits beliebt- zumindest in der Definitionsphase der Anforderungen. Spätestens wenn es an die Realisierung geht, fallen diese mit aller Gewalt auf die Füße. Dann hagelt es Changerequests und Designfehler wegen unklarer Anforderungslage • Beispiel3: Anforderungen die erst spät klar werden o Je innovativer und komplexer ein Projekt ist, desto höher ist die Wahrscheinlichkeit, dass sowohl von Auftraggeber- als auch von Auftragnehmer Seite Anforderungen erst sehr spät in der Realisierungsphase klar werden. Dieser Gefahr entgegnet man durch eine gründliche Anforderungsanalyse in der die künftigen Anwendungsszenare durchgespielt und immer wieder auf Konsistenz geprüft werden. Daraus ergeben sich die 3 Hauptrisiken des Anforderungsmanagements: • Fehlende Anforderungen o Es ist wichtig zu aller erst den Business Case des Kunden zu verstehen. Mit dem Verständnis für den Business Case, wird der Nutzen klar, der für den Kunden nach erfolgreicher Projektrealisierung entstehen soll. o Das blose Abfragen all dieser Anforderungen macht eine Anforderungsspezifikation aber noch lange nicht vollständig. Es ist wichtig den Grund, die Querbeziehung zwischen den Anforderungen und die Perspektive aus der heraus die Anforderung formuliert wurde zu verstehen. • Falsche Anforderungen o So wie man vergeblich nach fehlerfreier Software sucht, so muss man auch von fehlerhaften Anforderungen ausgehen. Doch qualitativ unzureichende Anforderungen die widersprüchlich-, inkonsistent-, lückenhaft sind, oder Denkfehler aufweisen führen nicht nur zu ständigen ChangeRequests, sie reduzieren auch die Arbeitsmotivation des Projektteams das durch solche Anforderungen zunehmend orientierungsloser wird. o Nur durch frühzeitiges validieren und verifizieren der Anforderungen, werden Fehler aufgedeckt. Die späteren Anwendungsszenare sind immer und immer wieder durchzuspielen um solche Fehler aufzudecken. o Am besten machen das erfahrungsgemäß die Tester. Diese haben ein Händchen für das Fehlerpotenzial und entdecken bei Reviews sehr viel mehr Fehler als Projektmanager oder Architekten. Darüber hinaus, ist es ein hervorragendes Training für die eigentlichen Tests, denn dadurch sind die Anwendungsszenare bestens bekannt. • Sich ändernde Anforderungen o Anforderungen deren Änderungen nicht kontrolliert werden, führen zu Termin und Kostenüberschreitungen und haben negativen Einfluss auf die Qualität o Auf keinen Fall dürfen Änderungen durchgeführt werden, deren Auswirkungen nicht analysiert und bewertet wurden. o Ab der zweiten Projekthälfte ist es ratsam, nur noch sehr wichtige Änderungen ohne größere Auswirkungen zuzulassen. o Ich wurde kürzlich von einem sehr jungen Softwareentwickler gefragt, ob man meiner Meinung nach jedes Projekt und sei es noch so klein, managen muss? Ich antwortete ihm, dass selbst ein Kleinstprojekt ein funktionierenden Änderungsmanagement benötig. Nur so ist dokumentiert, welche Anforderungen aktuell gültig sind und wo Änderungen anstehen. Hast Du Deinem Kunden erst einmal einen Termin auf Basis der vereinbarten Anforderungen versprochen, wirst Du es häufig erleben dass schon kurze Zeit danach die ersten Änderungswünsche hereinschneien. Das ist zwar ganz normal- muss aber abgefangen werden. Denn meist handelt es sich ja nur um „Kleinigkeiten“ die man doch noch so mitmachen kann. Doch auch vermeintliche Kleinigkeiten haben Wechselwirkung mit anderen Systemteilen, erhöhen die Komplexität und den Testaufwand. Ehe man sich versieht baut man sich mit einer solchen Kleinigkeit einen Fehler an ganz anderer Stelle ein. Und wenn man es erst einmal zugelassen hat, dass der Auftraggeber noch Anforderungen nachschieben darf, wird man das sehr schnell kaum noch unterbinden können. Und wie soll das Projekt dann zum vereinbarten Termin fertig werden? Änderungen erzeugen Aufwand für Realisierung, Test und Dokumentation und der muss sich auf die benötigte Realisierungszeit niederschlagen. Man müsste sich ja unterstellen lassen, den Aufwand nicht ehrlich kalkuliert zu haben, wenn Änderungen möglich sind, ohne dass dies Auswirkung auf Zeit und Geld hat. Nur wer Änderungen kontrolliert, hat die Möglichkeit die Erreichung der Projektziele zu kontrollieren. So, für heute möchte ich damit Schluss machen. In der nächsten Folge greifen wir dieses Thema wieder auf ich möchte Ihnen dann etwas über die verschiedenen Arten von Anforderungen erzählen. Bis dahin wünsche ich Ihnen viele grüne Meilensteine tschüss und bye bye Ihr Andreas Haberer Literaturverzeichnis Carroll, L. (1865). Alice im Wunderland. USA: Bassermann, Edition, 2014. Ebert, C. (2012). Systematisches Requirements Engineering. Stuttgart: dpunkt.Verlag Heidelberg. http://de.wikipedia.org. (1. 01 2015). Von http://de.wikipedia.org/wiki/Chaos-Studie: http://de.wikipedia.org/wiki/Chaos-Studie abgerufen Weitere Informationen finden Sie unter www.Bundesvereinigung-ITPM.de