Zehn Risiken, welche Ihr Projekt in eine Katastrophe verwandeln können
•Als PPTX, PDF herunterladen•
0 gefällt mir•85 views
Murphy war ein Optimist. Alles, was passieren kann, wird passieren und dazu gehören auch die Risiken, die Ihr Projekt zum Erliegen bringen können - es sei denn, Sie ergreifen Massnahmen um sicherzustellen, dass sie nicht passieren. Ein Digitalisierungsprojekt ist letztendlich ein Softwareprojekt. Wie unterscheiden sich die Risiken eines Softwareprojekts von denjenigen eines Bauprojekts? Dieser Vortrag gibt Antwort und zeigt auf, wie das Beschaffungskonzept besser in Einklang mit dem Lieferkonzept zu bringen ist.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Mehr von Peter Stevens
Mehr von Peter Stevens (20)
Zehn Risiken, welche Ihr Projekt in eine Katastrophe verwandeln können
- 1. Zehn Risiken… Peter Stevens © 2020 Peter Stevens
- 2. Meet Peter Stevens “Mr. What Really Matters” © 2020 Peter Stevens
- 3. Jedes Projekt ist ein Sprung ins Ungewisse © 2020 Peter Stevens
- 4. Innovationen in der Beschaffung können zu wesentlich besseren Ergebnissen führen… nicht nur für den Leistungsbezieher © 2020 Peter Stevens Image: SpaceX at Unsplace
- 5. Das Risiko von Verträgen nach Aufwand besteht darin, dass man vielleicht nie ein Ergebnis bekommt. © 2020 Peter Stevens
- 6. Beispiel Projekt Orion: 15 Jahre / $18.7 Mia / Gesamte (Test-) Flugzeit: 4h 36m © 2020 Peter StevensQuelle: https://en.wikipedia.org/wiki/Orion_(spacecraft)
- 7. “Im Grunde erreichte [SpaceX] in Wochen Dinge, für die die NASA Jahre brauchen würde. Und darüber waren wir alle schockiert.” -- Garrett Reisman, NASA Astronaut, heute SpaceX Advisor © 2020 Peter StevensImage: Wikipedia
- 8. Das Commercial Cargo Programm ermöglicht wiederum das Commercial Crew Programm Orbital Sciences Cygnus SpaceX Falcon-9 © 2020 Peter StevensImages: Wikipedia, SpaceX
- 9. 6 Jahre, $6.8 Mia, Ergebnis: 2 Raumschiffe, davon eines jetzt produktiv Boeing Starliner $4.3 Mia SpaceX Crew Dragon $2.5 Mia © 2020 Peter StevensQuelle: https://observer.com/2019/11/nasa-audit-boeing-spacex-iss-ccp-mission-spacecraft-budget/ Images: Wikipedia
- 10. Was ist die Herausforderung bei der Beschaffung von Digitalisierungsprojekten? Beschaffung IT und Software © 2020 Peter StevensImages: Unsplash
- 11. Was ist die Herausforderung bei der Beschaffung von Digitalisierungsprojekte? Beschaffung IT und Software © 2020 Peter Stevens Sie wissen, was Sie brauchen Sie können nicht wissen, was Sie brauchen Sie müssen das bestellen, was Sie brauchen Images: Unsplash
- 12. Wie bringen wir Beschaffung und Agilität unter einen Hut? © 2020 Peter Stevens Agile Vertragsformen und Tipps Scrum und Risiko- management Zehn Risiken, die man mit Agilität minimiert
- 13. © 2020 Peter Stevens Warnung zum Inhalt Kann unbequeme Wahrheiten oder unangemessene Sprache enthalten
- 14. Wir werden weiterhin Verträge brauchen • Kontrolle, Eigentum definieren • Risikomanagement und Risikoverteilung • Geldfluss definieren • Kontinuität gewährleisten • Wechsel von Entscheidungsträgern • Sinneswandel • Gewährleistung der Einhaltung der geltenden Gesetze («Compliance») • Spielregeln erstellen, um die Erfolgschancen zu verbessern © 2020 Peter Stevens
- 15. Agilität ermöglicht, die Risiken der SW-Entwicklung besser in den Griff zu kriegen. © 2020 Peter Stevens Zehn Risiken, die man mit Agilität minimiert
- 16. © 2020 Peter Stevens
- 17. Die ersten Sätze legen die agile Denkweise dar Lernen Zusammenarbeit Sinn © 2020 Peter Stevens
- 18. Risiken, die das Projekt scheitern lassen: Source: Ten Agile Contracts, by Peter Stevens Drawings by L. Quattri, used by permission © 2020 Peter Stevens
- 19. Risiken, die das Projekt scheitern lassen: 1. Lieferrisiko Source: Ten Agile Contracts, by Peter Stevens Drawings by L. Quattri, used by permission © 2020 Peter Stevens
- 20. Risiken, die das Projekt scheitern lassen: 2. Zeit- und Budgetrisiko Source: Ten Agile Contracts, by Peter Stevens Drawings by L. Quattri, used by permission © 2020 Peter Stevens
- 21. Risiken, die das Projekt scheitern lassen: 3. Umfangrisiko Source: Ten Agile Contracts, by Peter Stevens Drawings by L. Quattri, used by permission © 2020 Peter Stevens
- 22. Risiken, die das Projekt scheitern lassen: 4. Marktrisiko Source: Ten Agile Contracts, by Peter Stevens Drawings by L. Quattri, used by permission © 2020 Peter Stevens
- 23. Risiken, die das Projekt scheitern lassen: 5. Technisches Risiko Source: Ten Agile Contracts, by Peter Stevens Drawings by L. Quattri, used by permission © 2020 Peter Stevens
- 24. Risiken, die das Projekt scheitern lassen: 6. Soziales Risiko Source: Ten Agile Contracts, by Peter Stevens Drawings by L. Quattri, used by permission © 2020 Peter Stevens
- 25. Risiken, die das Projekt scheitern lassen: 7. Abhängigkeiten Source: Ten Agile Contracts, by Peter Stevens Drawings by L. Quattri, used by permission © 2020 Peter Stevens
- 26. Risiken, die das Projekt scheitern lassen: 8. Stakeholder-Risiko Source: Ten Agile Contracts, by Peter Stevens Drawings by L. Quattri, used by permission © 2020 Peter Stevens
- 27. Risiken, die das Projekt scheitern lassen: 9. Veränderungs-Risiko Source: Ten Agile Contracts, by Peter Stevens Drawings by L. Quattri, used by permission © 2020 Peter Stevens
- 28. Risiken, die das Projekt scheitern lassen: 10. Wunschdenken © 2020 Peter Stevens Source: Ten Agile Contracts, by Peter Stevens Drawings by L. Quattri, used by permission
- 29. Wunschdenken ist weit verbreitet « Die Realität ist, dass alle Schätzungen Lügen sind. Um das Geschäft zu bekommen, muss der Kunde so tun, als wüsste er, was er will, und ich muss so tun, als wüsste ich, wie viel Zeit und Geld es kosten wird, es zu liefern. « Wenn wir das Spiel nicht spielen, kann ich das Geschäft nicht bekommen. « Unsere Beziehung beginnt mit einer Lüge. » Wiktor Żołnowski Mitgründer Pragmatic Coders Auszeichnung als Customer Service Leader am World Agility Forum 2019 © 2020 Peter Stevens Photo courtesy Pragmatic Coders
- 30. Bei Scrum geht es um das Management von Risiko und Komplexität © 2020 Peter Stevens Scrum und Risiko- management Zehn Risiken, die man mit Agilität minimiert
- 31. Lieferbares ProduktVision Potenziell lieferbares Produkt Mindestens alle 30 Tage muss eine Vorversion vorliegen, um das Lieferrisiko zu eliminieren Maximum 30 Tage Review: Produkt mit Stakeholdern Was bringt Wert? Planung: Was / Wie? Image © 2009-2020 Peter Stevens Licensed CC-BY-NC-ND © 2020 Peter Stevens
- 32. Lieferbares ProduktVision Potenziell lieferbares Produkt Scrum wurde konzipiert, um die Risiken der Software- Entwicklung zu minimieren. Maximum 30 Tage Review: Produkt mit Stakeholdern Was bringt Wert? Planung: Was / Wie? Image © 2009-2020 Peter Stevens Licensed CC-BY-NC-ND © 2020 Peter Stevens
- 33. Der agile Lieferant bietet Scrum Master & Entwicklungsteam Scope- und Risikomanagement Etwas, das man nach jedem Sprint benutzen oder testen kann Giftbox icon made by Freepik from www.flaticon.com © 2020 Peter Stevens
- 34. Der agile Lieferant erwartet Konstruktives Feedback bei jedem Sprint Review Einen kompetenten Product Owner Aktive Stakeholder Giftbox icon made by Freepik from www.flaticon.com © 2020 Peter Stevens
- 35. Nicht alle Projekte müssen agil sein. Klarheit möglich - klassisch Komplexität dominiert - agil © 2020 Peter Stevens
- 36. Wie passen die verschiedenen Vertragsformen mit der Agilität zusammen? © 2020 Peter Stevens Agile Vertragsformen und Tipps Scrum und Risiko- management Zehn Risiken, die man mit Agilität minimiert
- 37. Keine Vertragsform mit fixem Umfang ist agil. © 2020 Peter Stevens
- 38. Vertragsformen mit variablem Umfang können agil sein © 2020 Peter Stevens
- 39. Ein Sprint ist wie ein Baustein für Ihr Projekt. Jeder hat die gleiche Kapazität, Dauer und Kosten. © 2020 Peter StevensPhoto by Paweł Czerwiński on Unsplash
- 40. Das kaufen, was der Lieferant wirklich anbietet © 2020 Peter Stevens
- 41. Tipps für Ihren agilen Entwicklungs-Vertrag Als Leistungs- erbringer Als Leistungs- bezüger © 2020 Peter Stevens
- 42. Tipps für Ihren agilen Entwicklungs-Vertrag • Abstimmen mit dem Risiko- Management der Methodik • Product Owner wird vom Auftraggeber gestellt, mit Entscheidungskompetenz • Bei jedem Sprint soll eine neue, testfähige Version zur Verfügung gestellt werden • Behebung von Hindernissen: «CIRO» • Verträge mit festem Umfang sind nicht in Ihrem Interesse © 2020 Peter Stevens Als Leistungs- bezüger
- 43. Tipps für Ihren Entwicklungs-Vertrag • Ihr erstes Ziel • Jeden Sprint zuverlässig liefern • Bieten Sie die Kollaborationsregeln als Teil Ihres Angebotes an • z.B. Scrum • Scrum Master und Entwicklungsteam zur Verfügung stellen • Dem Projekt 100% gewidmet Als Leistungs- erbringer © 2020 Peter Stevens
- 44. Zusammenfassung © 2020 Peter Stevens Fixer Umfang ist mit Agilität nicht kompatibel Das kaufen, was der Lieferant wirklich anbietet Ihre Arbeit in der Beschaffung kann eine starke Wirkung haben
- 45. Vielen Dank – Fragen • peter@saat-network.ch • saat-network.ch • @peterstev Photo © leonardo viti - Fotolia © 2020 Peter Stevens
- 46. Coupon Code: BESCHAFFUNG20 Scrum, Product Owner, Personal Agility, and Executive Led Transformation workshops: https://saat-network.ch/course-calendarhttps://tencontracts.com © 2020 Peter Stevens
Hinweis der Redaktion
- Herzlichen Dank an Euch und die Organisatoren. Es ist ein Ehre, dass ich hier sein darf. Das Konferenz-Bild ist perfekt. Es passt genau zu den Hoffnungen aber auch zu den Risiken, die Projekte tragen.
- Meine Name ist Peter Stevens. Vom Beruf bin ich Scrum Trainer. Ich bringe Hoffnung, gesunden Menschenverstand und effektives Arbeite in Bereiche ein, wo diese eher selten Blume sind. Meine Einführung in Vertragswesen bekam ich beim Bund, in einem Projekt, welche vor ziemlich genau 20 Jahre abgeschlossen wurde. Ich bin der Erfinder vom Personal Agility System und Mitgründer vom World Agility Forum. Letztes Jahre habe ich einen mich mit dem Thema Vertragswesen beschäftigt, mit dem Ziel, eine Brücke zu bauen, zwischen Bezieher und Erbringer von agilen Dienstleistungen
- Alles was passieren kann, wird passieren, vor allem, das was schief gehen heiss. Stürzen tut weh, und Risiken eliminieren ist eine wesentliche Aufgabe im Projekt
- In der Beschaffung habt ihr eine Gelegenheit, neue Spielregeln zu definieren, die das Innovationsstandort Schweiz besser fördert. Zuerst möchte ich Euch einen Beispiel zeigen, nicht wie es gehen könnte, sondern wie es schon gegangen ist.
- Wir kennen alle das Problem von Projekte nach Aufwand. Ausser Spesen nichts gewesen
- Die Raumfahrt kennt klare Beispiele dieser Problematik. Zwei Jahre nach dem start vom Projekt Orion 2008 experimentierte die NASA mit einen neuen Beschaffungskonzept. SpaceX und 2 weitere Firmen bekamen Aufträge für die sogenannte kommerzielle Versorgungs- *Dienste” (Commercial Resupply Services) für den ISS.
- In 2010 kurz vor seinem Launch in Atlantis besuchte Astronaut Garret Reisman die SpaceX. Was er sah war erstaunlich. SpaceX könnte in nur Woche das machen, wofür NASA das X-fach an Zeit und Geld brauchen würde.
- NASA wollte die Dienste, nicht die Rakteten. Diese müssten jedoch entwickelt warden. vereinbarte testbare Ziele, Termine und feste Geldbeträge, die fliessen, wenn die Ziele erreicht werden. Dass die Raketen auch landen können, das war kein Teil der Auftrag. Die Auftragnehmer haben die geistigen Eigentumsrechte behalten, was ungeahnte Weiterentwicklung ermöglichte. CRS war ein Erfolg
- Commercial Cargo hat das Konzept bewiesen und wiederum das Commercial Crew ermöglicht. Der SpaceX Dragon hat neulich den letzten Test bestanden. Starliner wird wohl noch etwas Zeit brauchen. Der Vergleich ist jedoch klar. 1/3. der Zeit, 1/3. des Geldes, das doppelte an Ergebnisse. Und schube an die Innovation.
- Kommen wir zurück zu Erde. Die Beschaffung existiert seit ewigen Jahren und funktioniert. Die NEAT wurde gebaut. Piste 28 in Zurich wurde saniert. Seit den 90ern stossen wir bei IT-Projekten auf Grenzen.
- Bei der Landebahn man kann weitgehend wissen was man braucht. Bei IT und software, die Komplexität macht das unmöglich. Das Gesetz schreibt jedoch vor, Sie müssen genau das bestellen, was Sie brauchen, aber wir brauchen Agilität! Und Sie, in der Beschaffung, haben ein Problem.
- Wie bringen wir die Beschaffung und die Agilität unter einem Hut. Ich möchte 3 Themen beleuchten. 1. Die Agilität und die Risiken die sie minimieren soll, 2. Wie Scrum als bespiel die Risiken verwaltet, and 3. Ihnen ein paar Tipps gegen über die Vertragsformen. Bereit?
- Nur eine klein Hinweis – das ist eine Reise für Erwachsene. Immer noch bereit? Okay…
- Eines vorweg… es gibt viele Gründen warum wir Verträge noch brauchen werden. Vorher stand der Kontrolle im vordergrund. Wichtigste meines erachtens sind die Spielregeln. Durch die Spielregeln könnte man für andere Ziele als Kontrolle optimeren.
- Erfolghaben ist der Grund, warum man agil sein will. Schauen wir die Agilität an, und die Risiken die unsere Projekte bedrohen
- Der Begriff Agile entstand mit dem gleichnamigen Manifest. Heute redet man viel von der «Agile Mindset» oder Geisteshaltung.
- Wir erschliessen besser Wege… Lernen. in dem wir es tun, und andere dabei helfen… Zusammenarbeit. Unser höchstes Ziel…. Sinn. Lernen, Zusammenarbeit und Sinn sind notwendig, um Komplexität zu meistern. Wogegen kämpfen wir?
- Was kann ein Projekt zur fall bringen?
- Lieferrisiko – bekommen wir überhaupt etwas? Das Ergebnis, wenn andere Risiken ausser Kontrolle geraten sind
- Zeit- und Budgetrisiko – eigentlich dasselbe als Lieferrisiko, aber das sind die Themen die zB die Presse oder einen PUK interessiert
- Umfangrisiko – haben wir genau das bekommen, was wir bestellt haben. Relevant bei der Landebahn, aber was, wenn man nicht wissen kann, was man will?
- Marktrisiko – wenn wir es bauen, wird man es kaufen oder nutzen? Moderne Ansätze wie Scrum, Lean Startup oder Design Thinking fokussieren auf Marktrisiko
- Technische Risiko – können wir es wirklich bauen? Viele agile Methoden tragen zur Reduktion der technischen Risiko bei.
- Soziale Risiko – können die Menschen miteinander auskommen, Wenn ich geholt wird, habert's meistens hier.
- Abhangkeiten – Man braucht etwas, was man nicht selber machen kann. Das ist so was wie Lieferrisiko in die Wertschöpfungskette
- Stakeholder risiko – werden die Stakeholders ihre Meinung ändern? Orion hat darunter gelitten. Mars – Mond – Mars – Mond – wo fliegen wir hin?
- Veränderungsrisiko – problematisch jedoch notwendig wenn Sie das richtige entwickeln wollen.
- Wunschdenken –die Wahrheit ablehnen, weil es unangenehm ist.
- Ein Beispiel, Anforderungen und Schätzung. Unsere Beziehung fängt mit einer Lüge an. Irgendwann kann die Wahrheit nicht mehr ignoriert werden.
- Schauen wir, wie Scrum mit dem Thema umgeht
- Scrum schreibt vor, dass mindestens 1x pro Sprint eine funktionierende Vorversion vorliegt. Das Team und die Stakeholders kommen zusammen, um das Produkt anzuschauen und Feedback geben. um nächste Entwicklungsschritte zu informieren. Das Lieferrisiko is so gut wie verbannt (wenn man es wirklich macht) und Veränderungen können wenn sinnvoll eingeführt werden.
- Jedes Element in Scrum wurde konzipiert um die Risiken von Produktentwicklung den Griff zu bekommen. Wenn man agil arbeitet, was sollen Leistungserbringer und -bezieher von einander erwarten?
- Der agile Lieferant bietet das Entwicklungsteam inkl. Scrum Master, ein Methodik zu Umfang und Risiko-Management und bei jedem Sprint, etwas was man testen oder einsetzen kann
- Der agile Lieferant erwartet, einen Product Owner mit Entscheidungskompetenz, aktive Stakeholder, die bei den Sprint Reviews konstruktives Feedback über das Produkt geben.
- Nicht jeder Auftrag muss agil sein. Aber wo die Komplexität dominiert ist ein agiles Vorgehen notwendig. Kein Wunschdenken: Digitalisierung ist Software und Software ist Komplex!
- Wie sieht ein agilen Vertrag aus?
- Räumen wir den Wunschdenken aus: alles mit fixem Umfang ist nicht agil. Das lernen wird teuer, langsam und ineffizient. Manche Formen sind schlechter als anderen.
- Der Vertrag allein kann die Agilität nicht sicherstellen. Diese Vertragsformen sind eventuell agil Von der Agilität her, ist «nach Aufwand» nicht so schlecht, aber es gibt keine Behandlung von Risiken. Ein Kostendach bzw Endtermin kann dazu verwendet werden. Wenn man Phasenweise arbeitet, kann man die Risiken kontrollieren. NASA mit CRS und Commerical Crew hat nach diesem Modell gearbeitet, wie auch meinen damaligen Arbeitgeber für die Entwicklung von NZZ Executive, PublicJobs.ch und NZZ Domizil. «Changes for free» heisst, was noch nicht angefangen wurde, kann mit etwas vergleichbares ausgetauscht werden
- In Scrum, der Grundbaustein ist der Sprint, wo die meisten Eckdaten konstant sind. Mit Sprints werden Risiken und Umfang verwaltet. Das bietet eine natürliche Steuerungseinheit für den Vertrag
- NASA hat das Produkt eingekauft, das sie wollte. Raketen, die Abnahmekriterien erfüllen. Ob das wir Sie möglich ist, lassen wir offen. Die Alternative ist, die Leistungen zu kaufen, was der Erbringer bietet. Das sind Sprints. Das Risikomanagement ist definiert und auf Entwicklungsprojekte abgestimmt. Der Preis pro Team und Sprint ist eigentlich fix. Das macht der Einkauf einfach.
- Wie können Sie besser mit den Verträge umgehen. Ich möchte ein paar Vorschläge anbieten:
- Als Leistungsbezieher, den Vertrag mit den Risiko Management der Methodik abstimmen. Ein wichtiger Aspekt ist die Behebung von Hindernisse. «Chief Impediments Removal Officer» hiess das. Und Verträge mit festem Umfang sind nicht in Ihrem Interesse. Punkt
- Als Leistungserbringer Ihr Leben wird viel einfacher, wenn sie jeden Sprint etwas liefert, was auch funktioniert. Das ist das Basis von Vertrauen. Biete auch die Zusammenarbeitsmodell an, was für Euch am besten funktioniert. Normallerweise, dass Sie den Team and Scrum Master stellen gehört dazu