39 PROJEKTMANAGEMENT AKTUELL · 35. Jahrgang · 02/ 2024 DOI 10.24053/ PM-2024-0030 Agile Transformation auf den Führungsetagen Projekt-Governance von klassisch bis agil Dorothee Feldmüller, Gerhard Ortner Für eilige Leser | Gute Projekt-Governance ist ein wichtiger Erfolgsfaktor der Projektarbeit, die zunehmend mit agilen Ansätzen erfolgt, wobei das Spektrum in der Praxis von hybridem Vorgehen, d. h. plangesteuerter Projektarbeit mit einigen agilen Praktiken, bis zu durchgehend agilem Arbeiten in skalierten Ansätzen wie SAFe reicht. Dabei stellt sich die Frage, wie Projekt-Governance angemessen an die jeweilige Arbeitsweise anzupassen ist. Wir machen im Folgenden einen Vorschlag zur Kategorisierung der agilen Ansätze und stellen Handlungsempfehlungen für die Projekt-Governance vor. Besondere Herausforderungen ergeben sich auch bei der Koexistenz verschiedener Ansätze in einer Organisation. Unsere Überlegungen richten sich an PMOs sowie Projekt- und Managementverantwortliche, die Projekt-Governance in ihren Organisationen gestalten oder reflektieren. Schlagwörter | Projektauftraggeber, Lenkungsausschuss, Projekt Management Office, Projekt-Portfoliomanagement, Senior Management, Projekt-Governance, Agile Projekt Governance, SAFe Bewusst gestaltete und gelebte Projektsteuerung durch die Führungskräfte einer Organisation-- sogenannte „Projekt-Governance“ ist ein wichtiger Erfolgsfaktor für Projektarbeit ([1], [2] bzw. [3], [4], [5]). Die wichtigsten Rollen und Bestandteile von Projekt-Governance sind in Standards beschrieben ([6], [7]). Bei zunehmend agilen Ansätzen unterschiedlicher Ausprägung in der Projektarbeit- - man spricht von „agiler Transformation“ in den Organisationen- - muss auch die Projekt-Governance „transformiert“ werden- - wie kann dies angemessen erfolgen? Motivation Projekt-Governance spielt eine entscheidende Rolle in agilen Projekten, indem sie Struktur und Richtlinien zur effektiven Umsetzung bietet. In agilen Umgebungen, die Flexibilität und Anpassungsfähigkeit betonen, gewährleistet eine klare Governance eine ausgewogene Balance zwischen Agilität und Kontrolle / Steuerung. Durch klare Rollen, Verantwortlichkeiten und Entscheidungswege trägt die Governance zur Effizienz bei, indem sie Teams dabei unterstützt, ihre Ziele zu erreichen, ohne den Rahmen zu sprengen. Die Wichtigkeit der Projekt-Governance in agilen, aber auch allen anderen Kontexten begründet sich in der Sicherstellung von Transparenz und Kommunikation. Governance- Mechanismen wie regelmäßige Reviews und klare Berichtsstrukturen fördern die Transparenz über den Projektfortschritt und ermöglichen rechtzeitige Anpassungen. Dies ist entscheidend, um Risiken zu minimieren und den Erfolg des Projekts zu sichern. Des Weiteren dient eine effektive Governance in agilen Projekten als Bindeglied zwischen Stakeholdern und (agilen) Teams. Sie hilft, unterschiedliche Erwartungen zu harmonisieren und die Ausrichtung auf die übergeordneten strategischen Ziele zu gewährleisten. Dadurch wird das Vertrauen der Stakeholder gestärkt und die Akzeptanz gefördert. Zusammenfassend ist eine gut durchdachte Projekt-Governance von entscheidender Bedeutung für den Erfolg aller Projekte. Sie schafft eine Struktur, die Flexibilität ermöglicht, ohne dabei die Kontrolle zu verlieren, und stellt sicher, dass das Projektteam auf Kurs bleibt, um Mehrwert zu liefern und die Bedürfnisse aller Beteiligten zu erfüllen. Herausforderungen der jüngeren Zeit sind die Koexistenz und geforderte Kooperation verschieden agiler Ansätze in den Projektportfolios. Die immer breitere Methodenvielfalt führt dabei zu einigen Unterschieden aber auch zu vielen Gemeinsamkeiten aus dem Blickwinkel der Governance. In manchen Wissen | Projekt-Governance von klassisch bis agil 40 PROJEKTMANAGEMENT AKTUELL · 35. Jahrgang · 02/ 2024 DOI 10.24053/ PM-2024-0030 Bereichen, wie der Produktentwicklung, wird auch der Projektbegriff teilweise zurückgedrängt (z. B. bei SAFe). Nach welchen Vorgehensmodellen Organisationen Projektarbeit leisten, ist durchaus unterschiedlich, und auch wenn von agilem Vorgehen gesprochen wird, ist durchaus nicht eindeutig, was damit gemeint ist. In der Praxis scheint hybrides und selektives Vorgehen zu dominieren-- so zeigt es die letzte Studie „Status Quo Agile“ ([8], S. 13 f.). Mit hybridem Vorgehen ist eine Mischung von agilen und traditionell plangesteuerten Ansätzen in einem Projekt bzw. in der Entwicklungsarbeit gemeint, mit selektivem Vorgehen eine gezielte Auswahl entweder agiler oder plangesteuerter Methoden für ein spezifisches Projekt. Bei den Teilnehmenden der Studie hat ein Drittel der Befragten ein Scaling Framework im Einsatz, das verbreiteteste Framework ([8], S. 100) ist das unter dem Namen „SAFe“ bekannte Scaled Agile Framework von Leffingwell ([9]). Mit diesem Framework wird eine Produktentwicklung unterstützt, die ohne den Begriff „Projekt“ auskommt: Die Entwicklung erfolgt inkrementell innerhalb von „Trains“, die es kundenorientiert zu koordinieren gilt. SAFe ist eine mittlerweile etablierte Methode, um agile Prinzipien in großen Unternehmen zu skalieren. Seine Besonderheiten liegen in der Struktur, die auf drei Ebenen- - Portfolio, Value Stream und Team- - aufbaut. Diese Hierarchie ermöglicht eine klare Verbindung zwischen strategischer Ausrichtung und operativer Umsetzung. Einzigartig an SAFe ist seine Betonung der Ausrichtung auf Wertstromebene, wodurch Unternehmen in der Lage sind, den Fluss der Wertschöpfung zu optimieren. Das Framework integriert Lean und agile Praktiken, um Wertkontinuität, schnelle Lieferung und hohe Qualität zu gewährleisten. Die klare Definition von Rollen und Verantwortlichkeiten (Governance! ) innerhalb von SAFe erleichtert die Zusammenarbeit und das Verständnis der verschiedenen Ebenen. Es fördert eine gemeinsame Sprache und ermöglicht eine effiziente Kommunikation über organisatorische Grenzen hinweg. Ein weiteres Merkmal von SAFe ist seine Anpassungsfähigkeit. Das Framework bietet verschiedene Konfigurationen, um den spezifischen Bedürfnissen und Kontexten von Unternehmen gerecht zu werden. Dadurch kann es flexibel auf unterschiedliche Unternehmensgrößen und Industrien zugeschnitten werden. Die Auswahl des geeigneten Ansatzes und insbesondere die Koordination gleichzeitig vorhandener verschiedener agiler Ansätze ist eine aktuelle und relevante Herausforderung, wie auch die Kooperation zwischen Teilbereichen einer Organisation, die einerseits mit Projekten und Projekt-Portfolios und andererseits mit einem SAFe-Framework „ohne Projekt“ arbeiten. Wie kann man z. B. als Projektverantwortlicher für ein plangesteuert aufgesetztes Hardware-Projekt dafür sorgen, dass die benötigte Software-Komponente in time im „Train“ umgesetzt wird-- wenn die Entwickelnden im Software- Bereich nach SAFe arbeiten? Der Anspruch, Business Value durch Projektbzw. Entwicklungsarbeit zu schaffen, ist allen Ansätzen gemeinsam. Ob und welche Anforderungen wann umgesetzt werden, und auf welcher Ebene darüber entschieden wird, darin unterscheiden diese sich stark. So bringt die nach reiner Lehre dezentrale Priorisierung nach SAFe-Regeln im IT-Bereich für die zentrale Organisation durchaus Herausforderungen, wie das obige Beispiel verdeutlichen soll. Vorschlag zur Kategorisierung der Ansätze Um einen Überblick über in der Praxis verwendete agile bzw. hybride Ansätze zum Vorgehen im Projekt zu erhalten, schlagen wir eine Kategorisierung der Ansätze wie folgt vor: • (Rein) Plangesteuertes Vorgehen (auch oft als „klassisch“ oder „traditionell“ bezeichnet): Die Projektdurchführung erfolgt nach sorgfältiger Planung des gesamten Projektablaufs. • Hybrider Ansatz: Ein plangesteuertes Vorgehen auf der Makro-Ebene, d. h. bei der Phasen-Modellierung des gesamten Projektablaufs, wird gemischt mit agilen Praktiken wie Dailys oder Sprints auf der Mikro-Ebene, in der Regel in einer oder mehreren Projektphasen, oft bei der Durchführung, aber auch bei Anforderungserhebung oder Konzeptarbeit. • Hybride Projektorganisation: Ein plangesteuertes Vorgehen auf der Makro-Ebene wird gemischt mit agilen Praktiken und agilen Rollen wie Product Owner, Scrum Master und Development Team, oft in der Durchführungsphase. Der Unterschied zu der vorhergehenden Kategorie besteht darin, dass agile Rollen in der Projektorganisation genutzt werden. • (Rein) Agile Projektorganisation: Ein Projekt wird rein nach einer agilen Methodik durchgeführt, prominentestes Vorgehensmodell dabei ist heute Scrum ([8], S. 51). • Agil im Großen: Die Arbeit in der Entwicklungsarbeit einschließlich des Portfolio-Management erfolgt projektübergreifend bzw. „ohne Projekte“ agil nach einem skalierten Abbildung 1: Governance-Ebenen nach PM² [6] für plangesteuerten und hybriden Ansatz Wissen | Projekt-Governance von klassisch bis agil 41 PROJEKTMANAGEMENT AKTUELL · 35. Jahrgang · 02/ 2024 DOI 10.24053/ PM-2024-0030 agilen Modell wie z. B. SAFe, daneben gibt es in der Regel Projekte für andere temporäre Vorhaben. Im Folgenden gehen wir auf verschiedene Aspekte, die die Project-Governance betreffen, für diese Kategorien ein. Governance-Ebenen und -Rollen Die aus traditionellen Ansätzen bekannten Governance-Ebenen und -Rollen werden in agilen Settings nicht sofort und komplett durch andere Strukturen ersetzt, sondern Stück für Stück angepasst je weiter eine Organisation sich vom plangesteuerten Vorgehen hin zu einer agilen Organisationsform entwickelt. Dabei verschieben sich die Managementebenen, auf denen Governance stattfindet, und neue Rollen verdrängen bisher gelebte Rollenbilder je agiler die Organisation agiert. Auch die Verantwortungskette, die ein Projekt über den Lebenszyklus begleitet (Verantwortung für den Business Case, für die saubere Projektabwicklung und Verantwortung für die Generierung des Nutzens) verschiebt sich mit den unterschiedlichen Rollenträgern. Damit verbunden verschieben sich natürlich im Weiteren auch die Kompetenzen, die Führungskräfte für das erfolgreiche Umsetzen von Vorgaben in den unterschiedlichen Ausprägungsformen mitbringen sollten. Wendet man die in den PM² Empfehlungen der EU-Kommission ([6], S. 23) für Governance-Ebenen und Rollen an, lassen sich damit aus unserer Sicht drei Varianten für die verschiedenen Ansätze darstellen: • Im plangesteuerten wie im hybriden Ansatz ist eine Verteilung der Verantwortlichkeiten auf bis zu vier Ebenen der Governance hilfreich wie in Abbildung 1 dargestellt: Von „unten“ nach „oben“ in der Hierarchie sind dies-- über dem Performing Layer mit dem Projektteam-- der Managing Layer, Directing Layer, Steering Layer und Business Governing Layer. Die vier Ebenen sind in jedem Projekt implizit vorhanden, aber nicht immer explizit benannt und involviert. • In der hybriden Projektorganisation gibt es im Performing Layer sowie im Managing Layer andere Rollen-- etwa einen Product Owner, den wir je nach Ausprägung der Rolle im Managing Layer oder im Performing Layer verorten, sowie das Developer Team und den Scrum Master, die wir im Performing Layer sehen. Aus Gründen der Gewohnheit wie auch dem Wunsch, „einen“ verantwortlichen Ansprech- Abbildung 2: Governance-Ebenen nach PM² [6] für (rein) agile Projektorganisation nach Scrum partner zu definieren, wird dabei oft noch die Rolle der Projektleitung im Managing Layer gelebt. • Bei einer rein agilen Projektorganisation- - wir gehen hier von der Nutzung von Scrum aus-- gibt es keine Unterscheidung zwischen Managing Layer und Performing Layer, und es gibt auch keine Projektleitung und kein Business Management mehr. Diese gehen in die auf Augenhöhe miteinander arbeitenden Rollen von Product Owner, Scrum Master und Developer Team über, wie in Abbildung 2 dargestellt. Die Definition von Projekten bei einer agilen Projektorganisation erfordert den gleichen Überbau wie im traditionellen Ansatz: ein Auftraggeber und Auftragnehmer für das Projekt, ein Lenkungsausschuss, die ihrerseits als übergeordnete Kontroll-Instanz eine Geschäftsleitung oder von ihr beauftragte Gremien zur übergeordneten Steuerung der Projekte über sich wissen. Bei SAFe hingegen kommen neue Rollen ins Spiel: ein Business Owner, Product Manager und Release Train Engineer treten in Steuerungsrollen ein, deren Verantwortungsbereich ganz anders definiert ist. Unterschiede In den Aufgaben, Befugnissen und Verantwortlichkeiten ergeben sich mit Übergang zu einer agilen Projektorganisation bzw. bei rein agilem Vorgehen deutliche Verschiebungen: Beim plangesteuerten Ansatz ist der Auftraggeber verantwortlich, den Nutzen bzw. Projekt-Erfolg zu definieren, der im Projekt erarbeitet und am Ende im Tagesgeschäft idealerweise auch eintritt. Mit dem iterativen Vorgehen im Projekt und der Integration eines Product Owner in die Projektorganisation, der den Nutzen verantwortet, wird der Projekt-Erfolg („Value“) während des Projektablaufs viel stärker integriert betrachtet. Genau dies hat das agile Vorgehen dem plangesteuerten Ansatz voraus. Wir haben- - ausgehend vom traditionellen Ablauf-- versucht, dies in Abbildung 3 darzustellen. Um von der agilen Projektorganisation zu profitieren, gibt ein Projektauftraggeber bzw. Lenkungsausschuss Verantwortung an den von diesen gestellten Product Owner ab. Die Herausforderung kann sein, dies auch wirklich umzusetzen und die Selbstorganisation des Scrum Team-- Product Owner, Scrum Master und Developer Team- - untereinander zu res- Wissen | Projekt-Governance von klassisch bis agil 42 PROJEKTMANAGEMENT AKTUELL · 35. Jahrgang · 02/ 2024 DOI 10.24053/ PM-2024-0030 pektieren. Dafür braucht es auf Seiten der Steuerungsebene Kompetenzen im agilen Vorgehen. Die gegenseitigen Erwartungen, die die verschiedenen Governance-Ebenen-- zum Beispiel Auftraggeber an ihre Projektleitungen aber auch umgekehrt-- aneinander haben, wurden in der Vergangenheit für plangesteuerte Modelle schon öfter untersucht ([1]). Auch hier haben wir eine für das traditionelle Vorgehen erstellte Darstellung versucht anzupassen, siehe Abbildung 4, wobei wir die wesentlichen Anpassungen in rot dargestellt haben: In der agilen Welt tritt das (Scrum-)Team an die Stelle von Projektleitung und Projektteam, und die Selbstorganisation des Teams erfordert für dieses mehr Spielraum, und auch mehr Interaktion mit der Steuerungsebene („nicht offene Tür, sondern selbst zum Team gehen“). Was in der traditionellen Projekt-Welt der Business Case ist, dem kommt der Gedanke der Produktvision unseres Erachtens am nächsten. Diese ist auch im Performing Layer, also im Scrum Team zu verstehen und in die tägliche Arbeit einzubeziehen, und andererseits von den Steuerungsebenen fortwährend zu prüfen und ggf. anzupassen. Von allen Beteiligten wird mehr Nutzenorientierung verlangt. Es kann nicht oft genug darauf hingewiesen werden, dass auf den Steuerungsebenen die Selbstorganisation wie auch die am „Value“ orientierte nicht von vornherein fest umrissene Leistung, die erbracht werden soll, herausfordernde Veränderungen im Selbstverständnis als Führungskraft bedeuten. Kompetenz im Sinne von Wissen, Verstehen und Wollen dieses anderen agilen Ansatzes sind hier von essenzieller Bedeutung. Herausforderungen einer agilen Portfolio- Steuerung Die agile Portfolio-Steuerung birgt einige spezifische Herausforderungen, denen Organisationen gegenüberstehen. Eine davon ist die Balance zwischen Flexibilität und strategischer Ausrichtung. Die Vielzahl agiler Initiativen kann zu einer Fragmentierung der Ressourcen führen, was eine klare Priorisierung und Ausrichtung erschwert. Des Weiteren stellen die Dynamik und Geschwindigkeit agiler Projekte eine Herausforderung dar. Traditionelle Portfolio-Management-Ansätze sind möglicherweise nicht agil genug, um mit schnellen Veränderungen und unvorhergesehenen Risiken Schritt zu halten. Abbildung 3: Aufgaben und Verantwortlichkeiten in der agilen Projektorganisation: ein Product Owner wird integriert, um fortlaufend den Projekt-Erfolg abzusichern Abbildung 4: Gegenseitige Erwartungen der Governance- Ebenen bei agilem Vorgehen nach Scrum Wissen | Projekt-Governance von klassisch bis agil 43 PROJEKTMANAGEMENT AKTUELL · 35. Jahrgang · 02/ 2024 DOI 10.24053/ PM-2024-0030 Ein weiteres Hindernis ist die Transparenz über das gesamte Portfolio hinweg. Ohne klare Sichtbarkeit und einheitliche Metriken kann es schwierig sein, den Status, Fortschritt und Wertbeitrag der einzelnen Projekte zu verstehen. Die Einführung von flexiblen und anpassungsfähigen Rahmenwerken für die Portfolio-Steuerung sowie die Nutzung von Tools (z. B. auch bald auf KI Basis) zur transparenten Visualisierung und Verfolgung des Portfolios können ebenfalls helfen, eine effektive agile Portfolio-Steuerung zu ermöglichen. Dem agilen Gedanken entsprechend, muss Governance im agilen Kontext auch ein Projekt-Portfolio „agiler“ steuern, worunter wir nicht nur mehr Flexibilität in den jeweiligen Projekt-Anforderungen, sondern auch mehr Flexibilität im Portfolio verstehen. Sich ergebende Chancen auf Mehrwerte und Wettbewerbsvorteile müssen kurzfristig geprüft werden und auch zu Lasten laufender Projekte aufgegriffen und umgesetzt werden können. Taborda und Mohammed [10] sprechen von „emergent strategy“, durch die sich agile Governance auszeichnet. Bechtel et al. ([11]) finden negative Effekte klassischer Praktiken in der Portfolio-Steuerung wie die Existenz eines Business Case, strategische Klarheit und Kontrolle auf die Qualität der Teamarbeit in agilen Projekten, weil sie vermutlich die Freiheit und Kreativität der Teamarbeit einschränken. Zur agilen Portfolio-Steuerung gibt es derzeit kaum gesicherte Erkenntnisse, die Forschung steht noch am Anfang. Sicherlich zu betrachten sind in diesem Kontext folgende Fragestellungen: • Häufigkeit der Prüfung von neu sich ergebenden Business Chancen und deren Potentialen; • Möglichkeiten, aufgrund vorhandener Budget-Puffer Chancen kurzfristig aufzugreifen; • Dauer der Entscheidungsfindung für Änderungen am Projekt-Portfolio; • Review und Retrospektive des Prozesses der Portfolio- Steuerung, einschließlich des Aufwandes für das „Front End Loading“ im PPM. Insgesamt erfordert die agile Portfolio-Steuerung ein Umdenken traditioneller Ansätze, um eine flexible, transparente und strategisch ausgerichtete Verwaltung von agilen Initiativen zu ermöglichen. Lösungsansätze zu Kooperation von „Projektwelt“ und SAFe Wir kommen zurück auf die eingangs gestellte Frage: Wie kann man z. B. als Projektverantwortlicher für ein plangesteuert aufgesetztes Hardware-Projekt dafür sorgen, dass die benötigte Software-Komponente in time im „Train“ umgesetzt wird- - wenn die Entwickelnden im Software-Bereich nach SAFe arbeiten- - und die Priorisierung der IT-Aktivitäten dezentral im IT-Bereich erfolgt auf Basis des dort bekannten Beitrags zur Wertschöpfung? Die erste Herausforderung für die Praxis besteht darin, das Problem überhaupt zu erkennen bzw. vorauszusehen. Eine im klassischen Vorgehensmodell geübte und auch weiterhin damit arbeitende Projektleitung wird unter Umständen gar nicht voraussehen, dass die benötigte Software-Komponente nicht wie bislang gewohnt zum von außen vorgegebenem Termin erstellt wird und schlimmstenfalls wird man zu Beginn einmal „auf die Nase fallen“. Ist das Problem erkannt und soll die Umstellung auf SAFe nicht „ausgehebelt“ werden, dann gilt es, den Bedarf für die von außen benötigte Software-Komponente in die Sprache von SAFe zu übersetzen. Zum Beispiel kann die Software- Komponente als Epic mit entsprechendem Value und (externem) Owner in ein geeignetes Backlog eingehen und durch angemessenen Informationsfluss während Priorisierung und Bearbeitung ein für beide beteiligte Bereiche passender Ablauf sichergestellt werden. Zusammenfassung und Ausblick Insgesamt lässt sich aus unserer Sicht sagen, dass Projekt- Governance angepasst werden muss, sofern agile Rollen in der Projektorganisation gelebt werden sollen. Ein „Einmischen“ von einigen agilen Praktiken in ein traditionelles Arbeiten-- von uns hybrider Ansatz genannt-- erfordert keine wesentlichen Anpassungen in der Governance und kann damit in traditionellen Strukturen leicht als ein erster Schritt in agiles Arbeiten umgesetzt werden. Wirklich agiles Arbeiten geht mit neuen Rollen einher, für die die Kompetenzen von allen Beteiligten, auch von den steuernden Führungskräften, erworben werden müssen, und es geht hier nicht nur um Wissen, sondern um Verstehen, Wollen, Engagement auf allen Ebenen. Wo die wichtigsten Unterschiede liegen, haben wir in den Abbildungen zu verdeutlichen versucht. Der Übergang zu einer agilen Organisation, die Produkte nach SAFe oder vergleichbaren Frameworks entwickelt, bringt noch ganz neue Herausforderungen, auf die wir erste Antworten gefunden haben. Genauso wie es für die „agilisierte“ Portfolio-Steuerung erste Antworten, aber noch wichtige offene Fragen gibt. Einen Einblick in die gelebte Praxis soll daher eine für den Frühling und Sommer 2024 geplante Befragung bzw. Studien in der D-A-CH-Region liefern, an der die trinationalen Fachgruppe „PM goes Boardroom“ derzeit arbeitet. Neben der in dieser Arbeit genannnten Literatur ist die Fachgruppe, zu der außer den beiden Autoren auch Praktiker aus großen Unternehmen gehören, bei denen derzeit in Teilbereichen SAFe eingeführt wird bzw. worden ist, eine wesentliche empirische Quelle. Wir danken allen Mitgliedern der Fachgruppe für den bereichernden Austausch. Literatur [1] Feldmüller, Dorothee; Hunziker, Thomas; Ortner, Gerhard; Rudischer, Christian: Projektauftraggeber und Lenkungsausschuss als Erfolgsfaktor, in: projekt MANAGE- MENT aktuell 3 / 2020, Nürnberg 2020, S. 53-59. [2] Feldmüller, D. ; Hunziker, T.; Ortner, G.; Atzor, M.: Project Governance-- Verbesserungspotenziale für eine erfolgreiche Projektsteuerung. Zeitschrift Führung + Organisation zfo Ausgabe 03 / 2022, S. 157-164. [3] Joslin, R., Müller, R.: The relationship between project governance and project success. International journal of project management, 34(4), 2016, S. 613-626. [4] Ul Musawir, A., Serra, C. E. M., Zwikael, O., Ali, I.: Project governance, benefit management, and project success: Towards a framework for supporting organizational stra- 44 PROJEKTMANAGEMENT AKTUELL · 35. Jahrgang · 02/ 2024 DOI 10.24053/ PM-2024-0030 tegy implementation. International Journal of Project Management, 35(8), 2017, S. 1658-1672. [5] The Standish Group: Chaos Manifesto 2012: The Year of the Executive Sponsor. The Standish Group, 2012. [6] PM² project management methodology guide, EU Commission, https: / / op.europa.eu / en / publication-detail/ -/ publication / 0e3b4e84-b6cc-11e6-9e3c-01aa75ed71a1 [7] GAPPS Global Alliance for Project Performance Standards: A Guiding Framework for Project Sponsors, GAPPS, 2015, https: / / globalpmstandards.org / downloads/ [8] Komus, Ayelt et al. Studie Status Quo ( Scaled ) Agile 2019 / 20. www.status-quo-agile.net. Abruf am 21. 12. 2023 [9] https: / / www.scaledagileframework.com/ , abgerufen am 21. 12. 2023 [10] Taborda, Louis J.; Mohammed, Mansoor. Exploring Agile Project Governance. Anzam Conference, Perth 2021. [11] Bechtel, Jadena; Kaufmann, Carsten; Kock, Alexander. Agile projects in nonagile portfolios: How project portfolio contingencies constrain agile projects’ teamwork quality. IEEE Transactions on Engineering Management, 2021, 69. Jg., Nr. 6, S. 3514-3528. Eingangsabbildung: iStock.com / qnula Prof. Dr. rer. nat. Dorothee Feldmüller Prof. (FH) Prof. Dr. rer. nat. Dorothee Feldmüller ist Professorin für Wirtschaftsinformatik am Campus Velbert / Heiligenhaus der Hochschule Bochum. Zuvor war die promovierte Mathematikerin lange Jahre tätig als IT-Projektleiterin und Beraterin. Seit 2004 ist sie aktiv bei der GPM. Anschrift: Hochschule Bochum Campus Velbert / Heiligenhaus, Kettwiger Str. 20, 42 579 Heiligenhaus, Tel. +49 2056 5848 - 16 721 eMail: d.feldmueller@gpm-ipma.de Prof. (FH) Mag. Dr. Gerhard Ortner Prof. (FH) Mag. Dr. Gerhard Ortner ist Fachbereichsleiter für Projektmanagement in den Studiengängen PM & IT (BA) bzw. PM & Organisation (MA) an der Fachhochschule des BFI Wien. U.a. arbeitet er derzeit auch im ISO Technical Committee 258 an der Weiterentwicklung internationaler PM Normen mit. Anschrift: FH des BFI Wien, Wohlmutstr. 22, A-1020 Wien eMail: gerhard.ortner@fh-vie.ac.at Welche Möglichkeiten haben Start-ups und KMUs, mit den gegebenen Mitteln und Fähigkeiten ihre Zielmärkte so zu analysieren, dass sich adäquate Entscheidungen treffen lassen? Welche Quellen und Strategien eignen sich für eine sachgemäße Marktrecherche und welche Entscheidungsmethoden sollten zum Einsatz kommen? Einer der häufigsten Gründe, warum Start-ups, Solo-Entrepreneure und Innovationsprojekte von KMUs scheitern, ist der, dass sie ihre Märkte falsch einschätzen. In diesem Buch erfahren Sie, welche Methoden und Prozesse geeignet sind, um ein Scheitern zu vermeiden. Dabei wird die Marktrecherche eng an die Entwicklung des Geschäftsmodells gekoppelt und es werden konkret umsetzbare Handlungsempfehlungen gegeben, welche die besonderen Herausforderungen innerhalb der frühen Gründungsphase und im Innovationsprozess berücksichtigen. Sebastian Pioch Von der Marktrecherche zum innovativen Geschäftsmodell Erfolgskonzepte für Start-ups und KMUs 1. Auflage 2024, 191 Seiten, €[D] 29,90 ISBN 978-3-381-11081-0 eISBN 978-3-381-11082-7 wissenschaften \ Soziologie \ Theaterwissenschaft \ Geschichte \ Spracherwerb \ Philosophie \ Medien- und Kommunikationswissenschaft \ Linguistik \ Literaturgeschichte \ Anglistik \ Bauwesen \ Fremdsprachendidaktik \ DaF \ Germanistik \ Literaturwissenschaft \ Rechtswissenschaft \ Historische Sprachwissenschaft \ Slawistik \ Skandinavistik \ BWL \ Wirtschaft \ Tourismus \ VWL \ Maschinenbau \ Politikwissenschaft \ Elektrotechnik \ Mathematik & Statistik \ Management \ Altphilologie \ Sport \ Gesundheit \ Romanistik \ Theologie \ Kulturwissenschaften \ Soziologie \ Theaterwissenschaft Linguistik \ Literaturgeschichte \ Anglistik \ Bauwesen \ Fremdsprachendidaktik \ DaF \ Germanistik \ Literaturwissenschaft \ Rechtswissenschaft \ Historische Sprachwissenschaft \ Slawistik \ Skandinavistik \ BWL \ Wirtschaft \ Tourismus \ VWL \ Maschinenbau \ Politikwissenschaft \ Elektrotechnik \ Mathematik & Statistik \ Management \ Altphilologie \ Sport \ Gesundheit \ Romanistik \ Theologie \ Kulturwissenschaften \ Soziologie \ Theaterwissenschaft \ Geschichte \ Spracherwerb \ Philosophie \ Medien- und Kommunikationswissenschaft \ Linguistik \ Literaturgeschichte \ Anglistik \ Bauwesen Narr Francke Attempto Verlag GmbH + Co. KG \ Dischingerweg 5 \ 72070 Tübingen Tel. +49 (0)7071 97 97 0 \ Fax +49 (0)7071 97 97 11 \ info@narr.de \ www.narr.de Anzeige