Gestaltung von Ausschreibungen agiler IKT- Projekte · 2020. 2. 14. · , die Einführung und Realisierung erfolgt meist im Rahmen von Projek-ten. Um Projekte der Eidgenossenschaft

Gestaltung von Ausschreibungen agiler IKT- Projekte

als

Abschlussarbeit des CAS ICT-Beschaffungen

an der

Wirtschafts- und Sozialwissenschaftlichen Fakultät

der Universität Bern

eingereicht bei

Dr. Wolfgang Straub und Dr. Matthias Stürmer Forschungsstelle Digitale Nachhaltigkeit

Institut für Wirtschaftsinformatik

von

Marten, Christian

von Frick AG

Bern, 31.10.2019

Zusammenfassung

Zusammenfassung Jährlich werden, durch die öffentliche Hand, im Zusammenhang mit der Rea-

lisierung von IKT- Projekten, IKT- Leistungen und IKT- Systeme für rund 1.8

Milliarden Franken1 beschafft.

Die zunehmende Digitalisierung der Prozesse und Aufgaben der Ver-

waltung und die damit einhergehende Digitale Transformation stellen die öf-

fentlichen Verwaltungsstellen vor neue Schwierigkeiten. Insbesondere die Ge-

schwindigkeit der Technologieentwicklung und der erwarteten Umsetzungs-

dauer sind die grosse Herausforderung.

Entscheidend für die erfolgreiche Beschaffung und die zugehörige Re-

alisierung dieser IKT- Projekte sind die gewählte Vorgehensweise und die

Rahmenbedingungen. Bereits in der Phase der Initialisierung wird der Grund-

stein für ein erfolgreiches Vorhaben gelegt. Ein wesentlicher Hebel ist dabei

die Verwendung von Methoden und Vorgehensweisen, welche eine rasche

Vorhabenumsetzung gewährleisten.

Heute werden von den Anspruchsgruppen laufend Ergebnisse gefor-

dert, die herkömmlichen Methoden vermögen dies nur bedingt zu leisten.

Um im Projektverlauf laufend Ergebnisse liefern zu können, muss auf agile

Methoden zurückgegriffen werden, was bereits in frühen Phasen und in kür-

zeren Zyklen der Vorhaben zur Wertschöpfung führt. Ebenso können Ände-

rungen früher als sonst erkannt und umgesetzt werden.

Es gibt keine generelle Regel nach welcher man den Einsatz von agilen

Phasen in den Projekten bestimmen kann, weder nach Art des Vorhabens

noch nach Entwicklungsanteil. Generell aber kann abgeleitet werden, dass je

kürzer die Zeitverhältnisse, je höher die Komplexität und je neuartiger das Vor-

haben, sich der Einsatz agiler Methoden lohnt um rascher Ergebnisse und

wertschöpfende Anteile zu erzeugen. Es spielt dabei keine Rolle ob alle

Schritte oder nur Teile agil abgearbeitet werden.

1 www.Beschaffungsstatistik.ch (besucht 16.10.2019)

http://www.beschaffungsstatistik.ch/

Zusammenfassung

Damit diese neuen Methoden Erfolg haben können, ist ein hohes Mass

an Flexibilität und Anpassungsfähigkeit des Managements, der Organisation

und der Mitarbeiter eine Voraussetzung, ebenso verschmelzen teilweise die

klassischen Rollenmodelle des Auftraggebers und Auftragnehmers, da es sich

in der agilen Vorhabens- Abwicklung um ein Kooperationsmodell handelt.

Durch geschicktes Strukturieren des Vorhabens, der Beschaffungs-

und Vorgehensschritte mit den jeweils zugehörigen vertraglichen Regelungen,

kann die Vergabestelle Projekte risikobewusst realisieren.

Die aktuell gegebenen rechtlichen Rahmenbedingungen lassen den Beschaf-

fungsstellen entsprechenden Spielraum, es gilt diesen zu nutzen!

"Die Erfahrung nimmt ein furchtbar hohes Schulgeld, aber sie lehrt wie sonst

keiner." Thomas Carlyle

Inhaltsverzeichnis I

Inhaltsverzeichnis ZUSAMMENFASSUNG I INHALTSVERZEICHNIS I 1 EINLEITUNG 1

1.1 Ausgangslage 1

1.2 Problemstellung 2

1.3 Zielsetzung 3

1.4 Aufbau der Arbeit, Methodisches Vorgehen 3

2 THEORIE 4 2.1 Projekt 4

2.1.1 Begriff Projekt und Projektarten 4

2.2 Agilität in Projekten 4

2.2.1 Begriff Agilität 4

2.2.2 Agilität und Projektarten 5

2.2.3 Agilität in den Projekten 6

2.3 Beschaffung 6

2.3.1 Grundlagen 6

2.3.2 Beschaffungsverfahren 7

2.3.3 Verfahrenswahl 8

2.3.4 Kriterien und Spezifika 8

2.3.5 Zuschlag 8

2.3.6 Vertrag 8

3 AGILITÄT IN DER ÖFFENTLICHEN BESCHAFFUNG 9 3.1 Grundlagen 9

3.1.1 Eigenheiten der IKT- Projekte im öffentlichen Sektor 9

3.1.2 Generisches Projekt- Phasenmodell 9

3.1.3 Allokation von agilen Phasen im Projekt 10

3.2 Bedürfnisse der Projektleiter 10

3.2.1 Research 10

3.2.2 Chancen 11

3.2.3 Risiken 11

Inhaltsverzeichnis II

3.2.4 Abhängigkeiten der Chancen und Risiken 11

3.2.5 Transformation der Abhängigkeiten in Anforderungen und

Kriterien 12

3.2.6 Umfang des Pflichtenheftes 12

3.3 Vorbereitung von Beschaffungen mit Agilität 13

3.3.1 Erfolgsfaktoren 14

3.3.2 Set Up des Vorhabens 14

3.3.3 Zusammenarbeit Lieferant und Auftraggeber und Vorgehen 15

3.4 Rechtliche Gestaltungsmöglichkeiten 16

3.4.1 Ablauf der Phasen gemäss BöB / VöB 16

3.4.2 Beschaffungsphasen in der Wirtschaft 16

3.4.3 Kombination der Phasen 17

3.4.4 Schlussfolgerungen 18

4 AGILE BESCHAFFUNGEN DURCHFÜHREN 19 4.1 Agile Vorhaben 19

4.1.1 Formulierung des Bedarfes 19

4.1.2 Möglichkeiten im Beschaffungsdesign 20

4.1.3 Beispiel aus der Praxis 20

4.1.4 Die Herausforderung in der Praxis 21

4.1.5 Phasen RFI / RFP / RFQ 22

4.1.6 Voraussetzungen zur erfolgreichen Umsetzung 22

4.1.7 Vertragliche Regelungen bei Agilität 23

4.1.8 Weitere Rahmenbedingungen und Schlussfolgerungen 24

5 SCHLUSSFOLGERUNGEN UND AUSBLICK 26 ANHANG A 27 ABBILDUNGSVERZEICHNIS 29 TABELLENVERZEICHNIS 30 ABKÜRZUNGSVERZEICHNIS 31 LITERATURVERZEICHNIS 32 SELBSTÄNDIGKEITSERKLÄRUNG 34 VERÖFFENTLICHUNG DER ARBEIT 35

Kapitel 1: Einleitung 1

1 Einleitung 1.1 Ausgangslage Die zunehmende Digitalisierung der Leistungen und Prozesse in der Wirt-

schaft macht auch vor der Verwaltung nicht Halt und führt in den kommenden

Jahren zu einer zunehmenden Zahl an IKT- Projekten welche in immer kürze-

rer Zeit umgesetzt werden müssen. In der Schweiz beschafft die öffentliche

Hand jährlich für rund 1.8 Milliarden Franken IKT- Leistungen und IKT- Sys-

teme2, die Einführung und Realisierung erfolgt meist im Rahmen von Projek-

ten.

Um Projekte der Eidgenossenschaft unter anderem einheitlich abwickeln zu

können, wird in der Bundesverwaltung die Projektmanagement-Methode

HERMES eingesetzt. Die Projektmanagementmethode HERMES3 ist ein Bun-

desstandard und wird auch vom Bund weiterentwickelt. Die Projektmanage-

mentmethode HERMES steht als offener Standard eCH-0054 frei zur Verfü-

gung und ist vom Verein eCH anerkannt4. Zahlreiche Kantone, Städte, Bil-

dungsinstitutionen und Unternehmen aus der Privatwirtschaft haben HERMES

erfolgreich eingeführt.

Organisationen des öffentlichen Rechts sind in vielerlei Hinsicht auch rechtli-

chen Rahmenbedingungen unterworfen. Zahlreiche politische Vorgaben, Ge-

setze, Verordnungen, Strategien, Bundesrats- sowie Bundesbeschlüsse etc.

geben den Verwaltungseinheiten oder Organisationen die Rahmenbedingun-

gen vor.

2 www.Beschaffungsstatistik.ch (besucht 16.10.2019) 3 https://www.isb.admin.ch/isb/de/home/themen/projektmanagement.htmlisb.ch (besucht 16.10.2019) 4 https://www.ech.ch/standards/39036 (besucht 16.10.2019)

http://www.beschaffungsstatistik.ch/https://www.isb.admin.ch/isb/de/home/themen/projektmanagement.htmlisb.chhttps://www.ech.ch/standards/39036


1.2 Problemstellung Haupttreiber der IKT- Projekte der öffentlichen Hand sind neue oder sich wan-

delnde Technologien und die Digitalisierung der Verwaltung (Digitale Trans-

formation5 der Verwaltungs- Prozesse und Leistungen).

Die sich daraus ergebenden Einflussfaktoren auf die IKT- Projekte der öffent-

lichen Hand sind (Brüesch et al 2017): "Die Bedürfnisse der Bürgerinnen und

Bürger; die Digitalisierung der Verwaltung; Effiziente Prozesse; Flexible Archi-

tekturen."

Initiativen / ProjekteEinflussfaktoren

Bedürfnisse

Digitalisierung

Prozessoptimierung/Effizienzsteigerung

Flexibilisierung der Architekturen

Digitale- ZugängePortale

Guichet- Publique

Acta NovaPortale, Infostar,

Polizeisysteme, eIDERP Systeme (zBsp SAP)Partnetschaften (SIS etc)

Acta NovaPortale, Infostar, Polizeisysteme

Steuersysteme (ESTV), DazitERP Systeme (zBsp SAP)Partnetschaften (SIS etc)

IKT- Strategie des BundesCloud Computing

End- to End ServicesRechenzentren des BundesBü

rger

Polit

ikVe

rwal

tung

Kost

en

SPAN

NU

NG

SFEL

DRe

cht

Tech

nolo

gie

Entw

ickl

ung

etc.

Abbildung 1: Einflussfaktoren, Initiativen / Projekte und Spannungsfeld

Das Spannungsfeld in dem sich die IKT- Vorhaben und die Verwaltung befin-

den ist auch massgeblich von rechtlichen, politischen, finanziellen und tech-

nologischen Rahmenbedingungen geprägt (siehe Abbildung 1).

Agile Vorgehensweisen versuchen diesem Spannungsfeld gerecht zu werden.

Jedoch stehen agil geführte Projekte oft in Konflikt mit den Möglichkeiten der

Beschaffungsstellen, Vorhaben dieser Art vertragsrechtlich abzubilden/umzu-

setzen.

5 https://searchcio.techtarget.com/definition/digital-transformation (besucht 16.10.2019)

https://searchcio.techtarget.com/definition/digital-transformation


1.3 Zielsetzung Im Rahmen der vorliegenden Arbeit wird die Anwendung und Umsetzung agi-

len Projektmanagements und agiler Arbeitsmethoden im Rahmen von öffent-

lichen Beschaffungen näher betrachtet.

Eine genauere Betrachtung der Vorhabenarten und deren Klassifikation ist

entscheidend für das Umsetzen der Projekte. Es wird insbesondere darauf

eingegangen, welche Möglichkeiten im Rahmen des Beschaffungsdesigns be-

stehen.

Die aktuellen Bedürfnisse der Projektleiter zur Umsetzung von Vorhaben in

einem komplexen Umfeld werden erhoben und deren Umsetzungsmöglichkei-

ten näher betrachtet.

Konkrete Ansätze, welche es ermöglichen Agilität in den Beschaffungsprozess

und die Umsetzung zu integrieren, werden anhand eines Praxisbeispiels erar-

beitet.

Weiteres Augenmerk wurde auf die Rahmenbedingungen und die zugehörigen

vertraglichen Regelungen gelegt, welche für die Möglichkeiten agile Methoden

einzusetzen entscheidend sind.

1.4 Aufbau der Arbeit, Methodisches Vorgehen Zur Beantwortung der Fragen wurden mittels Recherche die Themata Agilität,

Agilität in öffentlichen Beschaffungen sowie das Design von Beschaffungen

näher untersucht.

Mittels der Grundlagen und eigenen Erfahrungen, wie auch den Bedürfnissen

der Bedarfs- und Beschaffungsstellen, wurde das Thema Agilität in der Be-

schaffung in Bezug auf den Beschaffungsprozess und die rechtlichen Rah-

menbedingungen von der Vorhabens- / Bedarfsplanung bis zur Umsetzung

des Vorhabens analysiert.

Kapitel 2: Theorie 4

2 Theorie Nachfolgend werden die wichtigsten Begriffe in Zusammenhang mit agilen

Vorhaben und Methoden definiert, erläutert und im Kontext mit den rechtlichen

Rahmenbedingungen des öffentlichen Beschaffungswesens erörtert.

2.1 Projekt 2.1.1 Begriff Projekt und Projektarten In der Literatur kann keine einheitliche Definition zum Begriff Projekt gefunden

werden. Meist wir das Deutsche Institut für Normung zitiert, welches ein Pro-

jekt als "Vorhaben, das im Wesentlichen durch seine Einmaligkeit der Bedin-

gungen in ihrer Gesamtheit gekennzeichnet ist (z.B. Zielvorgabe, zeitliche, fi-

nanzielle, personelle oder andere Begrenzungen, Abgrenzungen gegenüber

anderen Vorhaben, projektspezifische Organisation)ʺ (Deutsches Institut für

Normung, DIN 69901, Ausgabe 1987‐08; zitiert z.B. in: Bech und Wolff 2003;

Casutt 2005). Zu den Merkmalen von Projekten äussert sich Madauss (1994),

was in Anlehnung an Madauss (1994: 490ff.) wie folgt festgehalten werden

kann: Komplexität, Aussergewöhnlichkeit, Neuartigkeit, Einmaligkeit, Interdis-

ziplinarität, Rechtlich‐organisatorische Zuordnung, Zeitliche Determination,

Aufgabenbezogenes Budget und Ziele.

Des Weiteren können Projektarten unterschieden werden (Bech und Wolff

2003) und differenzieren sich wie folgt: Investitionsprojekte, Forschungs- und

Entwicklungsprojekte, Organisationsprojekte und IKT‐Projekte.

2.2 Agilität in Projekten 2.2.1 Begriff Agilität Agiles Projektmanagement ist ein Begriff der eine Gruppe von Entwicklungs-

methoden umfasst, welche auf iterativer Entwicklung basieren. Das zugrunde-

liegende Konzept geht auf ein Toyota Produktionssystem (Ohno 1988) und

Agile Herstellung zurück (Gunasekaran 1999). Agiles Projektmanagement

wird vorwiegend in der Software-Entwicklung genutzt (Dyba und Dingsoyr

2008).

Agilität ist eine zunehmend genutzte Form der Arbeitsorganisation, welche das

Ziel verfolgt die Entwicklung von Ergebnissen in kurzen interaktiven Zyklen zu


ermöglichen6. Damit agile Methoden Erfolg haben können, ist sowohl ein ho-

hes Mass an Flexibilität und Anpassungsfähigkeit der Organisation als auch

der Mitarbeiter eine Voraussetzung.

Bedingt durch das agile Vorgehen, werden im Projektverlauf laufend Ergeb-

nisse geliefert, was bereits in frühen Phasen der Vorhaben zur Wertschöpfung

führt. Ebenso können Änderungen früher als sonst erkannt und umgesetzt

werden.

2.2.2 Agilität und Projektarten Um entscheiden zu können ob agile Techniken einen Mehrwert gegenüber

anderen Techniken (zB. Wasserfallmethode) generieren, muss man zuerst

einmal die Projektart bestimmen. Betrachtet man dies aus der Sicht der Infor-

mations- und Kommunikations- Technologie, können folgende Projekttypen

unterschieden werden:

System- / Softwarebeschaffung System- Softwareadaption System- Softwareentwicklung

HERMES unterscheidet hingegen Szenarien welche gegenüber den Inhalten

und Zielen offener definiert sind:

IT- Standardanwendung IT- Individualanwendung Dienstleistung / Produkt Organisationsanpassung Individuelles Szenario

Die vorgenannten Szenarien werden dann mittels des 4 Phasenmodells von

HERMES (Phase Initialisierung, Phase Konzept, Phase Realisierung und

Phase Einführung) und der zugehörigen Module realisiert. Im Zentrum stehen

bei der Realisierung der Module die Aufgaben und damit die zu erarbeitenden

Ergebnisse.

6 https://www.aoe.com/de/agile.html#c18250 (besucht 16.10.2019)

https://www.aoe.com/de/agile.html#c18250


2.2.3 Agilität in den Projekten Betrachtet man die verschiedenen Projekttypen oder Szenarien und setzt sie

in Kontext zu agilen Entwicklungsmethoden (namentlich Scrum, Scrumban,

Kanban, Devops und Designthinking), so kann daraus geschlossen werden,

dass sich agile Vorgehensweisen hauptsächlich bei grösseren Entwicklungs-

anteilen anbieten.

In der Privatwirtschaft werden meist kleinere bis mittlere Projekte mit Agilität

realisiert. Auch im öffentlichen Sektor haben Projekte zugenommen, welche

mittels agilen Techniken umgesetzt werden. Das Ergebnis einer repräsentati-

ven Umfrage (Unterwegs zu digitalen Welten, 2018) bei 954 deutschen Unter-

nehmen zeigt, dass nur 18% der Unternehmen meist oder dauernd agile Me-

thoden anwenden und 17% gelegentlich. Eine Umfrage in der Schweiz

(swissq.it 2018) ergab zur Verbreitung von agilen Methoden einen Anstieg von

2016 mit 40% auf einen Wert von 58.7% im 20187.

2.3 Beschaffung 2.3.1 Grundlagen Im Zentrum einer jeden Beschaffung steht der Bedarf. Die öffentliche Hand

beschafft, unter Verwendung von öffentlichen Mitteln, in Erfüllung ihrer Aufga-

ben, Waren, Güter und oder Dienstleistungen am Markt.

Organisationen des öffentlichen Rechts oder solche die subventioniert sind,

unterstehen dem Beschaffungsrecht und haben die Regelungen zur Beschaf-

fung von Gütern und Dienstleistungen einzuhalten.

Für Bundesbehörden der Schweiz gilt: - das Government Procurement Agreement (GPA) sowie, - das Bundesgesetz (BöB) sowie die zugehörige Verordnung über das

öffentliche Beschaffungswesen. Für Behörden der Kantone und Kommunen gilt die:

- das Government Procurement Agreement (GPA) sowie, - die Interkantonale Vereinbarung über das öffentliche Beschaffungswe-

sen (IVöB) sowie, - die jeweiligen kantonalen Gesetzgebungen und Verordnungen zum

Beschaffungswesen. 7http://swissq-1.hs-si-

tes.com/tb2018?__hstc=163417059.4a6c55272fc0a2bcd086ebafb507d57f.1571804560370.15718045

60370.1571893751043.2&__hssc=163417059.6.1571893751043&__hsfp=1387771005 (besucht

24.10.2019)

http://swissq-1.hs-sites.com/tb2018?__hstc=163417059.4a6c55272fc0a2bcd086ebafb507d57f.1571804560370.1571804560370.1571893751043.2&__hssc=163417059.6.1571893751043&__hsfp=1387771005http://swissq-1.hs-sites.com/tb2018?__hstc=163417059.4a6c55272fc0a2bcd086ebafb507d57f.1571804560370.1571804560370.1571893751043.2&__hssc=163417059.6.1571893751043&__hsfp=1387771005http://swissq-1.hs-sites.com/tb2018?__hstc=163417059.4a6c55272fc0a2bcd086ebafb507d57f.1571804560370.1571804560370.1571893751043.2&__hssc=163417059.6.1571893751043&__hsfp=1387771005


Alle Beschaffungen haben das Prinzip der Gleichbehandlung, der Transpa-

renz, des Wettbewerbs und des wirtschaftlichen Einsatzes der Mittel zu befol-

gen (Art 1, BöB).

Die rechtlichen Grundlagen lassen den Verwaltungseinheiten im Grundsatz

die Freiheit den Beschaffungsgegenstand zu definieren (Anforderungen / Las-

tenheft) und mittels welcher Kriterien sie die Angebote bewerten wollen.

Hingegen regelt der Gesetzgeber sehr genau wie das Beschaffungsverfahren

abzulaufen hat und gibt Einschränkungen bei den Kriterien und deren Gewich-

tung vor.

2.3.2 Beschaffungsverfahren Der Vergabestelle stehen folgende Verfahrensarten zur Verfügung:

Das offene Verfahren (Art. 14 BöB und Art. 34 VöB) ist grundsätzlich bei je-dem Auftragswert möglich. Es erfolgt eine öffentliche Ausschreibung im amtli-

chen Publikationsorgan (www.simap.ch) und jedermann kann ein Angebot ein-

reichen. Der Zuschlag erfolgt an denjenigen der die bekannt gegebenen Krite-

rien am besten erfüllt.

Das selektive Verfahren (Art. 15 BöB und Art. 34 VöB) ist auch bei jedem Auftragswert möglich. Es erfolgt ebenfalls eine öffentliche Ausschreibung im

amtlichen Publikationsorgan, jedoch kann die Vergabestelle in einem Zwi-

schenschritt die geeignetsten Anbieter auswählen und deren Anzahl be-

schränken. Nur die zugelassenen Anbieter werden dann zur Angebotsabgabe

eingeladen.

Das freihändige Verfahren (Art. 16 BöB und Art. 36 VöB) kann bei niedrigen Auftragswerten oder bei fehlendem Wettbewerb angewandt werden. Die

Vergabe erfolgt frei und ohne formelles Verfahren und der Zuschlag ist, wenn

im Staatsvertragsbereich angewandt, auf der amtlichen Publikationsplattform

bekannt zu geben.

Das Einladungsverfahren (Art. 35 VöB) ist primär bei mittleren Auftragswer-ten möglich (Art. 35 Abs. 3 Bst.a bis f). Dabei werden wenigstens drei Anbieter

anhand eines Pflichtenhefts (oft auch Lastenheft genannt) zur Angebotsab-

gabe eingeladen. Der Zuschlag erfolgt an denjenigen der die bekannt gege-

benen Kriterien am besten erfüllt.

http://www.simap.ch/


2.3.3 Verfahrenswahl Primär wird das anzuwendende Verfahren durch den Auftragswert (Art. 6 und

Art. 7 BöB) bestimmt.

Sekundär wird berücksichtigt, ob die zu beschaffenden Güter und oder Dienst-

leistungen dem Gesetz oder der Verordnung unterstellt sind.

2.3.4 Kriterien und Spezifika Bei den anzuwendenden Kriterien können grundsätzlich zwei Arten unter-

schieden werden.

Die Eignungskriterien (Art. 9 BöB und Art. 9 VöB) beziehen sich auf die

wirtschaftliche, technische und finanzielle Leistungsfähigkeit des Anbieters.

Die Zuschlagskriterien welche insbesondere Termin, Qualität, Preis,

Wirtschaftlichkeit, Betriebskosten, Kundendienst, Zweckmässigkeit der Leis-

tung, Ästhetik, Umweltverträglichkeit und technischen Wert berücksichtigen

(Art. 21 BöB) dienen zur Bestimmung des wirtschaftlich günstigsten Angebo-

tes.

2.3.5 Zuschlag Das wirtschaftlich günstigste Angebot erhält den Zuschlag (Art. 21 BöB).

2.3.6 Vertrag Nach dem Zuschlag erfolgt in der Regel der Vertragsschluss. Artikel 29 BöB

sieht einen schriftlichen Vertragsschluss vor, welcher grundsätzlich die allge-

meinen Geschäftsbedingungen des Bundes zu berücksichtigen hat.

Kapitel 3: Agilität in der Beschaffung 9

3 Agilität in der öffentlichen Beschaffung Nachfolgend werden die Eigenheiten, Bedürfnisse und Rahmenbedingungen

in Zusammenhang mit IKT- Projekten näher ergründet und erläutert, sowie die

Vorbereitung und Gestaltung solcher Vorhaben.

3.1 Grundlagen 3.1.1 Eigenheiten der IKT- Projekte im öffentlichen Sektor In den letzten Jahren hat die öffentliche Verwaltung damit begonnen ihre Pro-

zesse zu digitalisieren, mit dem Ziel, Leistungen der Verwaltung effizienter zu

gestalten und für den Bürger/die Bürgerin softwarebasiert auch online anzu-

bieten (Brown 2001, Goldfinch 2007 und Hardy 2008). Softwarebeschaffung

und IKT- Projekte im öffentlichen Sektor sind aber aufgrund besonderer Rah-

menbedingungen schwieriger umzusetzen als im privaten Sektor. Gesetzliche

Rahmenbedingungen (BöB, VöB, FHG et al) regulieren die Beschaffungs- und

damit verbundene Aktivitäten und Prozesse (Edquist, Hommen und Tsipouri

2000).

Die Geschwindigkeit mit der in der Verwaltung Innovationen und Entwicklun-

gen umgesetzt werden können ist allgemein geringer als im privaten Sektor

(Brown 2001 und Janowski 2015).

3.1.2 Generisches Projekt- Phasenmodell Zur Ableitung eines generischen Projekt-Phasenmodells können bestehende

Projektmanagementstandards und Methoden herangezogen werden.

Standard/ Methode

Initi

alis

ieru

ng/

Initi

ieru

ng

Def

initi

on /

Kon

-ze

ptio

n

Plan

ung

Um

setz

ung

/ Re-

alis

ieru

ng

Con

trol

ling

/ St

euer

ung

Einf

ühru

ng/ A

b-sc

hlus

s

ISO 21500 X X X X X X DIN 69901-1 X X X X X X PMI PMBOK 5 X X X X X X SIA 112-2014 X X X X X HERMES 5 X X X X Haupt- / Ustü- Prozess H H U H U H

Tabelle 1: Projektmethoden / Standards und deren Phasen


Durch Hinzufügen der Prozessoptik (Hauptprozesse / Unterstützungspro-zesse) lassen sich als gemeinsamer Nenner die Phasen:

- Initialisierung, - Konzeption, - Realisierung und - Einführung

unterscheiden.

3.1.3 Allokation von agilen Phasen im Projekt Allen Projekten gemeinsam sind die Dimensionen Zeit, Komplexität und Neu-

artigkeit. Es gibt keine generelle Regel, nach welcher man den Einsatz von

agilen Phasen in den Projekten bestimmen kann, weder nach Art des Vorha-

bens noch nach Entwicklungsanteil. Generell aber kann abgeleitet werden,

dass je kürzer die Zeitverhältnisse, je höher die Komplexität und je neuartiger

das Vorhaben, sich der Einsatz agiler Methoden lohnt um rascher Ergebnisse

und wertschöpfende Anteile zu erzeugen.

3.2 Bedürfnisse der Projektleiter 3.2.1 Research Im Rahmen dieser Arbeit wurden strukturierte Interviews mit 4 Projektleitern

geführt. Ziel dieser Interviews war es Einsicht in die Erfahrungen der Projekt-

leiter mit der Anwendung agiler Methoden zu gewinnen und wie sie diese im

Rahmen von deren Beschaffungsprojekten einsetzen.

Hauptfokus der Interviews lag dabei auf den Chancen und Risiken die mit dem Einsatz von agilen Methoden verbunden sind.

Die Dauer der Interviews lag zwischen 65 und 110 Minuten und sie wurden

zwischen Mitte August und Mitte Oktober 2019 durchgeführt. Die Ergebnisse

der Interviews wurden notiert und zur Inhaltsanalyse (Krippendorff 2012)

transkribiert. Da die Ergebnisse der Transkription komplex und nicht direkt zu-

ordenbar waren, wurde unter Zuhilfenahme von offener Codierung (Krippen-

dorff 1989) die Daten in Gruppen und Untergruppen zusammengefasst. Die

Ergebnisse, welche in dieser Arbeit präsentiert werden, sind ebenfalls im An-

hang enthalten.


3.2.2 Chancen Die Projektleiter haben folgende Chancen und Opportunitäten identifiziert:

• Iterative Ziel- / Ergebnisentwicklung • Laufende Stakeholder Integration • Intensiver /dauernder Info-Austausch mit den Stakeholdern • Klarere / überschaubarere Verantwortungen • Bessere Ressourcenallokation

3.2.3 Risiken Folgende Risiken wurden durch die Projektleiter identifiziert:

- Keine konkreten Projektziele - Ungenaue Architektur und Spezifikation der IKT Lösung - Unbekannte Ressourcenbedarfe / schwierige Allokation - Mangelndes Committment der Führung - Ungenügende Bedarfsträgereinbindung (Benutzer/Betreiber) - Unklare Zuständigkeiten / Verantwortlichkeiten

3.2.4 Abhängigkeiten der Chancen und Risiken Nachfolgend werden die Chancen und Risiken mit den Abhängigkeiten ver-

bunden. Chancen Abhängigkeiten Risiken

Iterative Ziel- / Ergebnis-entwicklung

Vorgehen / Vertrag / Lie-

ferergebnisse / Annahme

der Leistungen

Keine konkreten Projekt-ziele

Laufende Stakeholder In-tegration

Kommunikation / Vorgaben /

Changemanagement / Be-

trieb und Wartung

Ungenaue Architektur- und Spezifikation der IKT Lösung

Intensiver / dauernder Info-Austausch mit den Stakeholdern

Kommunikation / Ressour-

cen / Einbindung / Ziele

Ungenügende Bedarfsträ-gereinbindung (Benut-zer/Betreiber)

Klarere / überschaubarere Verantwortungen

Unterstützung / Umsetzung /

Tragbarkeit / Vorgehen

Mangelndes Committment der Führung

Bessere Ressourcenallo-kation

Planung / Verfügbarkeit / Be-

schaffung / Beistellungen /

Know How

Unbekannte Ressourcen-bedarfe / schwierige Allo-kation

Tabelle 2: Chancen / Risiken und deren Abhängigkeiten


3.2.5 Transformation der Abhängigkeiten in Anforderungen und Krite-rien

Nachfolgend werden die Perspektiven und die Zielsetzungen mit den Umset-

zungsmöglichkeiten (Anforderung / Kriterium) verbunden.

Perspektive Anforderung / Kriterium Zielsetzung Gegenstandsbe-zogen

- Basisanforderungen / Ar-chitektur Blueprint

- Use Cases / User stories

Iterative Ziel- / Ergebnis-entwicklung

Anbieterbezogen - Risikomanagement - Risikozuschläge - Agile agreement / frame-

work

Laufende Stakeholder In-tegration

Anbieterbezogen - Changemanagement - Zusammenarbeitsverein-

barung - Eskalationsprozess

Intensiver / dauernder Info-Austausch mit den Stakeholdern

Gegenstandsbe-zogen

- Rahmenvertrag mit Optio-nen oder Abrufen

- Absprungpunkte im Ver-trag

Klarere / überschaubarere Verantwortungen

Anbieterbezogen - Kapazitäten und Skalie-rung

- Skills der Mitarbeiter - Assessment der Mitarbei-

ter

Bessere Ressourcenallo-kation

Tabelle 3: Perspektiven / Zielsetzungen - Anforderungen / Kriterien

3.2.6 Umfang des Pflichtenheftes Das Pflichtenheft ist der wesentlichste Bestandteil der Ausschreibung, darin

sind die Kriterien (Eignungs- und Zuschlagskriterien als auch die technische

Spezifikation) für die Vergabe mit ihrer Definition aufzuführen.

Vergabekriterien dürfen nicht diskriminierend sein und sind für jede Vergabe

entsprechend zu definieren. Die technischen Spezifikationen sind so genau

als irgend möglich zu definieren, da nach Abschluss des Vertrags der Leis-

tungsgegenstand nicht mehr geändert werden kann.


3.3 Vorbereitung von Beschaffungen mit Agilität Wie bei allen Vorhaben, kommt der Vorbereitung von Projekten, ob mit Agilität

oder ohne, besondere Bedeutung zu. Es geht darum ganz gezielt die Voraus-

setzungen für den Projekterfolg zu schaffen. Dazu müssen die richtigen Berei-

che beeinflusst werden.

Die durch die Agilität gewollten kürzeren Zyklen in den Projekten mit fortlau-

fender früher Lieferung von Ergebnissen erhöht die Erfolgsrate und führen zu

einem iterativen Prozess-Design, Prototyping, Entwicklung, Testing und

Deployment von kleineren Elementen ("CHAOS" Studie der Standish Group

20148).

In diesem Kontext spricht man auch von "growing" Software, dabei wird der

Benutzer eingebunden, jede Komponente hat einen Besitzer oder eine kleine

Anspruchsgruppe und die Anforderungen respektive Erwartungen werden re-

alistischer gesetzt, ebenso hat jede Komponente präzise und klare Ziele. Soft-

warekomponenten und kleinere Projekte tendieren dazu auch weniger kom-

plex zu sein.

"Projekte einfacher zu gestalten ist eine sinnvolle Bemühung, da Komplexität

nur zu Konfusion und erhöhten Kosten führt!" (Standish Group 2014)

Nachfolgend werden die entscheidenden Einflussgrössen näher beleuchtet.

Projekterfolg

Erfolgsfaktoren Projekt Set-Up

ZusammenarbeitVorgehen

Abbildung 2: Einflussfaktoren auf Projekterfolg

8 The Standish Group Report, CHAOS, 2014 https://www.projectsmart.co.uk/white-papers/chaos-re-port.pdf (besucht 16.10.2019)

https://www.projectsmart.co.uk/white-papers/chaos-report.pdfhttps://www.projectsmart.co.uk/white-papers/chaos-report.pdf


3.3.1 Erfolgsfaktoren Buckow und Hoch (2007) sehen die Rolle der Verwaltungsführung als ent-

scheidend an. Die Führung muss ein prozessorientiertes IKT‐Projektmanage-

ment von der Entwicklung bis zur Nutzung der IKT‐Lösung unterstützen und

ermöglichen. Daher beziehen sich die von ihnen identifizierten Erfolgsfaktoren

konsequent auf das IKT‐Projektmanagement: - IT‐Projekten als Management Issue - Steigerung der Akzeptanz durch Einbindung der Nutzer; - Einbinden externer Kompetenz und Dienstleister; - Neben klaren Zielen auch Nutzenidentifikation; - Zweckgerichtete Spezifikation der IKT‐Lösung; - Ausschreibung von IT‐Projekten in zeitlichen Abschnitten; - Rahmenverträge mit Lieferanten; - Konsequente Orientierung der Spezifikationen am Bedarf; - Klares Changemanagement für nachträgliche Spezifikationen; - Begleitendes Controlling; - Konsequentes schlüssiges Risikomanagement; - Konsequentes Nutzenmanagement mit Kennzahlen oder klaren Zielvereinbarungen.

3.3.2 Set Up des Vorhabens Nebst den vorgenannten Erfolgsfaktoren ist die Phase Initialisierung eine sehr

entscheidende Projektphase.

Abbildung 3: Phasen nach HERMES (Quelle hermes.admin.ch)

"Die Abbildung zeigt schematisch die Ergebnisse der Anforderungsdefinition und Systementwicklung eines IT-Systems im Projektablauf.

• In der Phase Initialisierung werden im Rahmen der Studie die Ziele festgelegt und die Anforderungen soweit erarbeitet, dass Varianten gebildet, die Variantenwahl getroffen, sowie der Projektauftrag erstellt werden kann.


• In der Phase Konzept werden die in der Studie dokumentierten Gro-banforderungen als Systemanforderungen konkretisiert und vervoll-ständigt. In Detailstudien werden projektspezifische Lösungskonzepte erarbeitet, welche Teil der Systemarchitektur sind, das System mit den Prozessen, der Funktionalität, den Systemkomponenten und ihrer Ein-bindung über Schnittstellen ins Systemumfeld beschreiben.

• Auf der Grundlage der Systemarchitektur wird die Detailspezifikation erstellt und darauf basierend das System entwickelt.

• In der Phase Einführung wird das System aktiviert und anschliessend der Entscheid zur Abnahme getroffen.

Die Spezifizierung und Realisierung des IT-Systems kann mit dem Modul agile Entwicklung flexibel gesteuert werden."9

3.3.3 Zusammenarbeit Lieferant und Auftraggeber und Vorgehen Es ist ausserordentlich wichtig, bereits in der Initialisierungsphase eine klare

Vorstellung bezüglich der Zusammenarbeit und des Vorgehens zu haben. Die

Hauptfragen die sich dabei stellen sind:

- Wie will ich mit den Lieferanten zusammenarbeiten und was sind die Ergebnisse die er zu erstellen hat?

- Wie sieht der Zeitplan aus und wo sind gegebenenfalls Exit- Punkte für einen Aus-stieg?

- Wie kann ich überprüfen ob wir auf dem richtigen Weg sind? - Was soll und oder muss ich bereitstellen, damit das Vorhaben Erfolg haben kann? - Welche Ergebnisse kann ich direkt umsetzten / einführen / integrieren? - Welche rechtlichen Rahmenbedingungen sind massgebend und welchen Hand-

lungsspielraum haben wir? - Etc….

Auf Basis der Antworten kann das Vorgehen und das passende vertragliche

Rahmenwerk, wie auch das geeignetste Beschaffungsverfahren bereits in der

Phase Initialisierung weitestgehend bestimmt werden.

Fazit: Agile Projektmethoden beeinflussen sämtliche Phasen eines Projektes, beginnend mit der Initialisierung in welcher der Grundstein für eine erfolgreiche

Umsetzung gelegt wird. Zwar finden die grössten Auswirkungen der Agilität in

der Realisierungsphase des Projektes statt, jedoch betrifft die Agilität sämtli-

che Stakeholder und Lieferobjekte des Vorhabens.

9 http://www.hermes.admin.ch/onlinepublikation/index.xhtml?element=supportingmaterial_phasenmo-dell_anforderungen.html (besucht 16.10.2019)

http://www.hermes.admin.ch/onlinepublikation/index.xhtml?element=supportingmaterial_phasenmodell_anforderungen.htmlhttp://www.hermes.admin.ch/onlinepublikation/index.xhtml?element=supportingmaterial_phasenmodell_anforderungen.html


3.4 Rechtliche Gestaltungsmöglichkeiten 3.4.1 Ablauf der Phasen gemäss BöB / VöB Beschaffungen können einerseits nach den in den rechtlichen Rahmenbedin-

gungen vorgesehenen Phasen abgewickelt werden.

Abbildung 4: Übersicht Verfahren (Quelle bbl.admin.ch) 10

3.4.2 Beschaffungsphasen in der Wirtschaft Die in der Wirtschaft bekannten Beschaffungsprozesse sind RFI (Request for

Information), RFP (Request for Proposal) und RFQ (Request for Quotation).

3.4.2.1 RFI (Request for Information) Ein RFI ist normalerweise der Erste Schritt im Beschaffungsprozess und wen-

det sich an einen breiten Anbieterkreis. Die in diesem Schritt gewonnenen In-

formationen dienen in erster Linie dazu die Funktionen, Konditionen und

Preise zu verstehen. Mit dem RFI wird der Grundstein für das weitere Vorge-

hen gelegt. Die gewonnenen Daten sind meist: - Informationen über Lieferanten, deren Strategie, Fokus, Organisation, Finanzen,

Leistungsfähigkeit und Angebotsspektrum 10 https://intranet.bbl.admin.ch/bbl_kp/de/home/beschaffen/beratungs-support-kbb/vorlagen/2--schritt--

erstellung-der-ausschreibungsunterlagen.html (besucht 16.10.2019)

https://intranet.bbl.admin.ch/bbl_kp/de/home/beschaffen/beratungs-support-kbb/vorlagen/2--schritt--erstellung-der-ausschreibungsunterlagen.htmlhttps://intranet.bbl.admin.ch/bbl_kp/de/home/beschaffen/beratungs-support-kbb/vorlagen/2--schritt--erstellung-der-ausschreibungsunterlagen.html


- Die Breite des Angebotes am Markt - Die Marktverhältnisse - Die Dynamik des Marktes - Die Markttrends und die relevanten Treiber - Erkenntnisse über Preismodelle und Preise - Informationen zum Wettbewerb unter den Anbietern

3.4.2.2 RFP (Request for Proposal) Im Rahmen eines RFP werden den Anbietern bereits geschäftliche Anforde-

rungen (business requirements) übergeben. Der Lieferant hat die volle Freiheit

eine passende Lösung zu den Anforderungen zu suchen oder zu gestalten

und seine Kreativität, Leistungsfähigkeit und auch die Vorzüge seiner Techno-

logie darzulegen.

Der Nachteil von sehr offen gestalteten RFPs ist die schwierige Vergleichbar-

keit der Proposals.

3.4.2.3 RFQ (Request for Quotation) Der RFQ ist die Möglichkeit für selektionierte Lieferanten zu wettbewerbsfähi-

gen Preisen eine Lösung anzubieten. Normalerweise sind die Ergebnisse ei-

nes RFQ sehr gut zu vergleichen (exakte Beschreibung der Lösung mit allen

Angaben zur Beschaffung).

Es besteht auch die Möglichkeit, je nach Beschaffungsrahmenbedingungen

mehrere Angebotsrunden vorzunehmen. Im Rahmen des öffentlichen Be-

schaffungswesens wird in der Regel nur eine Runde vorgenommen.

3.4.3 Kombination der Phasen Im Rahmen einer Beschaffung können, zum Beispiel in einem selektiven Ver-

fahren, die Vorgehensweisen aus beschaffungsrechtlicher Sicht und die Vor-

gehensweise der Wirtschaft miteinander kombiniert werden. Die Nachfol-

gende Tabelle 4 zeigt dies beispielhaft auf:


Beschaffungsrechtliche Sicht RFx Möglichkeiten

Einladung für Antrag auf

Teilnahme

RFI - Form der Marktabklärung - Feedback zu Lösungsmöglichkei-

ten

RFP - Lösungsansätze - Form des "Dialogs" zwischen RFI

/ RFQ - Gemeinsame Lösungs- /Vorge-

hensentwicklung Einladung zur Angebots-

abgabe

RFQ - Lösungsentwicklung durch Liefe-rant

Vertrag / Umsetzung

- Lösungsentwicklung durch Liefe-rant

- Gemeinsame Lösungsentwick-lung

Tabelle 4: Beschaffungsverfahren - Mischvarianten

3.4.4 Schlussfolgerungen Die oben angeführte Kombination der Phasen ermöglicht eine Form des "Dia-

loges", welche dem Dialog im Sinne von Art. 26 VöB wohl ähnlich ist, jedoch

nicht dieselben Ausprägungen und Bedingungen hat. Wird diese Vorgehens-

weise noch mit einer funktionalen Spezifikation im Sinne von Art. 16a Abs. 2

VöB ergänzt, ist ein erhebliches Mass an Agilität gegeben.

Es können auch weitere / andere Kombinationsmöglichkeiten gewählt werden.

Wichtig ist in jedem Fall, dass die rechtlichen Vorgaben eingehalten werden

und die Grundprinzipien des Beschaffungswesens: - Wahrung des Wettbewerbs, - Transparenz des Verfahrens, - die Gleichbehandlung aller Anbieter und - der wirtschaftliche Einsatz der staatlichen Mittel

gewährleistet bleiben.

Kapitel 4: Agile Beschaffung durchführen 19

4 Agile Beschaffungen durchführen Nachfolgend wird, auch unter Zuhilfenahme eines Beispiels aus der Praxis

dargelegt wie ein Vorhaben zu dessen agiler Abwicklung strukturiert und auf-

gesetzt werden kann.

4.1 Agile Vorhaben 4.1.1 Formulierung des Bedarfes Bereits bei der Formulierung des Bedarfes sehen sich der Bedarfsträger, die

Beschaffungsstelle und die Benutzer mit einem Umfeld konfrontiert, welches

Liedtka et al (2017, S.4) wie folgt charakterisiert: - Zunehmend komplexer werdende Probleme (wicked problems); - Stakeholder können sich nicht auf die Problemdefinition und etwaige Lösungen ei-

nigen; - Mitarbeiter der Verwaltung verhalten sich Risiko-Avers und nicht innovativ; - Entscheidungsträgern fehlen teilweise grundlegende Informationen; - Politische Entscheide und Entscheidträger richten sich an kurzfristigen Zielen aus

und - die Kundenerwartungen an Verwaltungen steigen bei gleichzeitig abnehmenden

Ressourcen.

Die Koordination und der Abgleich stetig ändernder Business Anforderungen

ist eine Herausforderung in jedem Softwareentwicklungs- oder IKT- Projekt. In

agilen Projekten wird dem hauptsächlich begegnet indem das Entwicklungs-

team regelmässig und direkt mit dem Benutzer, bezüglich des Requirements

Engineerings kommuniziert (Sommerville 2005, Bjarnason 2011).

Die Dokumentation der Anforderungen erfolgt öfter als Test- Case denn als

spezifizierte Anforderung, dies führt zu einer Aufwandreduktion, da nicht zwei

verschiedene Spezifikationen parallel ajour gehalten werden müssen.

Im VBS wird für eine erfolgreiche Projektabwicklung EAMod eingesetzt. Die

Fachbereiche beschreiben mit EAMod ihr fachliches Umfeld (Business Ana-

lyse) sowie Treiber, Ziele und Grobanforderungen für Vorhabenanträge. In den

Projekten erfasst der Anwender seine Anforderungen, Prozesse, Schutzob-

jekte, Informationsflüsse sowie den Systemkontext (i.e. «Footprint» des Pro-

jektes). Der Beschaffer ergänzt und verfeinert die Anforderungen und beauf-


tragt die Industrie basierend auf den in EAMod modellierten Daten. Der zu-

künftige Lieferant dokumentiert die Lösungsarchitektur. Der Betreiber definiert

die benötigten Plattformen und Systeme/Services. Ebenso werden die Bedürf-

nisse des Lebenswegmanagements erfasst. Eine gemeinsame Stammdaten-

verwaltung und entsprechende Libraries unterstützen alle Beteiligten.11

Aus dem System können dann die Anforderungen in der gewünschten Form

exportiert werden, z Bsp als Use-Case's und oder Test Case's etc.

4.1.2 Möglichkeiten im Beschaffungsdesign Sind die Anforderungen als User- Stories und oder als Use-Cases spezifiziert,

kann zusammen mit dem Lieferanten bereits in einer ersten Phase (i.e. RFP)

eine Art Kernsystem skizziert werden.

Werden Spezifikationen oder in diesem Fall Use-Cases definiert, so können

diese auch als funktionale Spezifikation verwendet werden. Der Lieferant hat

dann im Rahmen des RFP die Möglichkeit, das Zielsystem genauer zu be-

schreiben und die Funktionskataloge (Spezifikation der Funktionen und deren

Komplexität) selbst zu definieren (Innovation seitens Anbieter).

4.1.3 Beispiel aus der Praxis Anhand der Beschaffung (aus Gründen des Informationsschutzes entspre-

chend verfremdet und IKT- System S4711 genannt), können wir den Projekt

Set-Up und die Vorbereitung der Beschaffung genauer betrachten.

Das IKT- System S4711 weist Schnittstellen zu 5 weiteren Systemen auf und

dient zur Grund- und Systemdatengenerierung welche zur Nutzung anderer

Systeme relevant sind. Diese Daten müssen dann an die Umsysteme überge-

ben werden. Die zur Grund- und Systemdatengeneration relevante Parameter

müssen von den Umsystemen an das IKT- System S4711 übergeben werden.

11 https://vbs-portal.ifc1.ifr.intra2.admin.ch/sites/20661/EAMod/Dokumente/40%20Publikatio-

nen/01%20Flyer/86_030_d_EAmod_Booklet_2018.pdf (besucht 16.10.2019)

https://vbs-portal.ifc1.ifr.intra2.admin.ch/sites/20661/EAMod/Dokumente/40%20Publikationen/01%20Flyer/86_030_d_EAmod_Booklet_2018.pdfhttps://vbs-portal.ifc1.ifr.intra2.admin.ch/sites/20661/EAMod/Dokumente/40%20Publikationen/01%20Flyer/86_030_d_EAmod_Booklet_2018.pdf


IKT- System 4711

System 4712

System 4713

System 4714

System 4715System 4716

System 47XX

Systemlandschaft

Abbildung 5: Systemlandschaft IKT- System 4711

Die Abbildung 5 zeigt die geschilderte Situation, welche per se keine Beson-

derheit ist und die aktuelle Komplexität in der IKT- Systemwelt widerspiegelt.

Mit zunehmender Vernetzung, Digitalisierung und der Transformation der Pro-

zesse und Aufgaben, hat sich die Komplexität allgemein gesteigert.

4.1.4 Die Herausforderung in der Praxis Die besondere Herausforderung besteht darin, dass nicht alle Systeme auf der

Zeitachse jeweils in derselben Projektphase sind (siehe Abbildung 6).

Nutzung

MS20 : ProjektauftragMS25 : ShortlistMS30: Beschaffungsreife/Real.MS40 : Einführung/SchulungMS50: Nutzung/Projektabschluss

Initialisierung• Anforderungen• Studien• Grundlagendok• Projektauftrag• …

Konzept / Evaluation• Ausschreibung• Trp Vsu / Tech Erpr• Vertrag• Typenwahl • …

Realisierung• Serieproduktion

resp Entwicklung• Einbau in Fz• Schulungsunterl• Ausbildung Instrukt.• …

Einführung• Schulung• ÜbergabeSystem

an LBA• Projektabschluss• …

Glossar/Lieferobjekte

Initialisierung Konzept/Eval. Einführung20 30 5025 Realisierung 40

4711 4712 4713 4714 4715 4716

Quelle: HERMES VBS und MatV

Grun

dlag

en/

Abhä

ngig

keite

n

Abbildung 6: Projektphasen der Systemlandschaft


Wie die Abbildung 6 zeigt, werden in der Phase Initialisierung Studien / Grund-

lagendokumente erstellt, welche einen Einfluss auf die Konzeption / Evalua-

tion, die Realisierung, Einführung oder auch Nutzung der Umsysteme haben

und umgekehrt. Dieser Herausforderung kann begegnet werden, indem in den

verschiedenen Vorhaben agil gearbeitet wird und sie in gemeinsam koordinier-

ten und gesteuerten Programmen zusammengefasst werden.

4.1.5 Phasen RFI / RFP / RFQ Im vorliegenden Fall wurde eine Kombination aus RFI / RFP / RFQ und dem

Selektiven Verfahren gewählt. In der ersten Phase wurde ein RFI auf simap.ch

publiziert und den interessierten Unternehmen die relevanten Anforderungen

übergeben um einen Lösungsvorschlag (ein Kernsystem) zu erarbeiten.

Dieser Lösungsvorschlag wurde anhand von Kriterien wie angewendete Tech-

nologie, Innovationsgrad der Lösung, Eignung und Fähigkeiten des Anbieters,

Lösungen zu realisieren, bewertet. Die besten 3 Unternehmen wurden in einer

zweiten Phase (RFP) ersucht, das Kernsystem mit wesentlichen Funktionali-

täten zu ergänzen. Diese Phase erfolgte in enger Zusammenarbeit mit dem

Benutzer und den Spezialisten, um einen guten Einblick in die Zusammenar-

beit zu erhalten und das gemeinsame Vorgehen zu erarbeiten. Die Beurteilung

erfolgte mittels Kriterien, welche sich nun auf die Lösungen und die Umset-

zung des Systems bezogen. In einer dritten Phase wurde dann zusammen mit

einem Lieferanten auf Basis der gemeinsam erarbeiteten Vorgehensweise das

System agil entwickelt.

4.1.6 Voraussetzungen zur erfolgreichen Umsetzung Derzeit ist Agiles- Projektmanagement und agile Entwicklung in der Verwal-

tung eine viel diskutierte Materie. In Estland wird die digitale Transformation

der Verwaltung bereits seit Jahren vorangetrieben und der Einsatz agiler Me-

thoden ist dabei ein Thema (Soe und Drechsler 2018).

In der Schweiz hingegen ist das "Wasserfallmodell" nach wie vor die am häu-

figsten eingesetzte Vorgehensweise, welche den Abschluss einer Pro-

jektphase nach der anderen impliziert (Sumrell 2007).

Wie am Praxisbeispiel gezeigt, kann dies zu Ineffizienzen führen da der stete

Wandel und die Abhängigkeiten untereinander dabei nicht in genügendem


Masse berücksichtigt werden. Agile Vorgehensweisen verfolgen einen ande-

ren Ansatz und sind bei Dingsøyr, Nerur, Balijepally, und Moe (2012) als Fä-

higkeit definiert: "sich stetem Wandel anzupassen und schnell und flexibel die

darauf nötigen Antworten geben zu können."

4.1.7 Vertragliche Regelungen bei Agilität Die klassischen Rollenmodelle Auftraggeber und Auftragnehmer verschmel-

zen teilweise, da es sich in der agilen Vorhabens- Abwicklung um ein Koope-

rationsmodell handelt. Agile Vorhaben bewegen sich im Spannungsfeld der

Interessen des Auftraggebers und des Auftragnehmers (Preis, Leistungen,

Termine etc.).

Die Beschaffungsstelle hat meist keinen klaren Zielwert (zum Budget- und

Haushaltsabgleich) ebenso fehlt ein eindeutiger Leistungsumfang bei agilen

Projekten. Die Beschaffungsstellen verfügen aktuell über wenig Erfahrung mit

agilen Vorhaben und deren Umsetzung (Verträge, Vereinbarungen, Projekt-

controlling etc.).

Die Beteiligten tragen bei agilen Vorhaben die auftretenden Risiken ge-

meinsam, das ist eine neue Situation insbesondere im Behördenumfeld, in

welchem Risiken stets vermieden oder ausgelagert werden.

Das agile-agreement ist das Tool welches die vorgenannten Themata regeln

soll und eine gemeinsame Basis für die Umsetzung Agiler Vorhaben schafft.

Zielsetzungen des agile-agreement sind:

- 1) einen festen Kostenrahmen und Leistungsumfang festzulegen; - 2) Termine definieren; - 3) Zusammenarbeit und Vorgehen festlegen sowie Eskalationsmechanismen definie-

ren.

Dazu bedarf es einer:

- 4) "Scope governance" zur Steuerung des Leistungsumfangs; - 5) "Safety and Risk Share" Vereinbarung zur Risikomitigation; - 6) Einbindung eines "agile.codex" auf Basis des Agile Manifests12 für eine erfolgrei-

che Zusammenarbeit (Kooperationsmodell).

12 https://agilemanifesto.org/ (besucht 19.10.2019)


Die Bedingungen der Zusammenarbeit und das allgemeine Vorgehen (3;6),

terminliche Eckwerte zum Vorhaben (2), die Vereinbarung zur Aufsicht und

Steuerung des Umfangs des Vorhabens (4), die Vereinbarungen zur Risiko-

Mitigation (5) sowie die wesentlichen Funktionen des Zielsystems (funktionale

Spezifikation) können mit einem Rahmenvertrag für die Dauer des Vorhabens

geregelt werden.

Die einzelnen Entwicklungsschritte können dann auf Basis dieser Vereinba-

rung und zu diesen Bedingungen als Einzelvertrag abgearbeitet werden. Wei-

tere Regelungen betreffend den Entwicklungsschritt können im Einzelvertrag

getroffen werden.

Dies ermöglicht eine Risikobeurteilung auf Basis der erarbeiteten / vor-

handenen Ergebnisse und des nächsten geplanten Schrittes. Es kann somit

auch nach jedem Teilschritt gestoppt werden.

Die im Rahmenvertrag enthaltene funktionale Spezifikation gewährleis-

tet, dass sich die Entwicklungsschritte an den Funktionen des Zielsystems

ausrichten.

4.1.8 Weitere Rahmenbedingungen und Schlussfolgerungen Je nach gewähltem Vorgehen kommt es zu vorvertraglichen Verhand-

lungen respektive Zusammenarbeit. Bereits das blosse führen von Vertrags-

verhandlungen kann bei den Beteiligten erhebliche Aufwendungen verursa-

chen und einen Partner davon abhalten, andere mögliche Vertragsschlüsse

zu tätigen respektive diese zu verfolgen, all dies im Vertrauen darauf, dass ein

Vertrag Zustandekommen wird. (Bucher 1988).

Die verhandelnden Parteien haben selbst im Stadium der Vertragsver-

handlungen und unabhängig von einem späteren Vertragsabschluss, auch

Sorgfalts- und Aufklärungspflichten.

Dies kann zur Haftung aus "culpa in contrahendo"13 führen, unabhängig davon

ob später ein Vertrag zustande kommt oder nicht.

13 Gesetzlich ist die culpa in contrahendo nicht allgemein geregelt, obwohl die Rechtsprechung

und auch die Lehre sie als eigenständigen Haftungstatbestand anerkennen (siehe dazu auch

BGE 134 III 390, 130 III 345 und 121 III 350).


Die Beschaffungsstelle hat diesem Umstand Rechnung zu tragen und bei vor-

vertraglichen Leistungen potentieller Anbieter eine Entschädigung vorzuse-

hen. Das BöB sieht unter anderem für den Dialog in Art. 24 Abs. 3 Bst c. eine

entsprechende Entschädigung vor.

Bei Rüstungsbeschaffungen bestehen für die Behörden zusätzliche

Einschränkungen im Freiheitsgrad, da zur Reife der Vorhaben spezielle Vor-

gaben gelten (Verordnung des VBS über die Beschaffung, die Nutzung und

die Ausserdienststellung von Material, Materialverordnung VBS, MatV, SR

514.20).

Die rechtlichen Vorgaben in der Bundesverwaltung ermöglichen agile Vorha-

ben. Agile-Vereinbarungen und die zugehörigen Vertragswerke stellen jedoch

die Zuständigen, namentlich das Management und die Juristen, vor neue Her-

ausforderungen.

Besonders die "Definition of Done" (DoD) ist eine der grössten Herausforde-

rungen. DoD heisst in diesem Fall, dass der Benutzer die User- Story, anhand

genau definierter Kriterien (Code-Review, Funktionstest etc.) abgenommen

und akzeptiert hat.

Durch geschicktes Strukturieren des Vorhabens, der Beschaffungs- Vorge-

hensschritte mit den jeweils zugehörigen vertraglichen Regelungen, kann die

Vergabestelle Vorhaben risikobewusst realisieren.

Kapitel 5: Schlussfolgerungen / Ausblick 26

5 Schlussfolgerungen und Ausblick Vorhaben mittels agiler Methoden oder agilem Projektmanagement um-

zusetzen scheint insbesondere bei einem komplexen Umfeld und einem ho-

hen Komplexitätsgrad angezeigt.

Wie in Kapitel 3 und folgenden dargelegt, gibt es nicht die Vorgehensweise zur Umsetzung eines Vorhabens, sondern vielmehr ist die genaue Voranalyse

und der Inhalt des Vorhabens entscheidend dafür wie vorgegangen werden

kann.

Abraham Maslow schrieb 1966: „Ich glaube, es ist verlockend, wenn

das einzige Werkzeug, das man hat, ein Hammer ist, alles zu behandeln, als

ob es ein Nagel wäre.“ (Abraham H. Maslow: The Psychology of Science: A

Reconnaissance, S. 15)

Agilität ist grundsätzlich durch den Projektset-Up und das gewählte ge-

meinsame Vorgehen (Kunde / Lieferant) zu begünstigen und kann nicht nur

durch spezielle Kriterien / Anforderungen motiviert werden. Entscheidend da-

für sind der Inhalt und der Kontext der Beschaffung (e.g. Architekturwandel

von Silosystemen zu Plattformen).

Entscheidend für den Erfolg sind die gegebenen Rahmenbedingungen,

Integration des Managements, Integration der Benutzer, Integration des Liefe-

ranten und die Interaktion der Projektleitung mit allen Beteiligten.

Es geht darum die vorhandenen Methoden und Vorgehensweisen an das Vor-

haben anzupassen und nicht nur eine Methode zu wählen, ohne sich um deren

Umsetzbarkeit Gedanken zu machen.

Die aktuellen Rahmenbedingungen ermöglichen mehr Agilität als von den Be-

schaffungsstellen momentan genutzt wird. Durch geschicktes Strukturieren

des Vorhabens, der Beschaffungs- und Vorgehensschritte mit den jeweils zu-

gehörigen vertraglichen Regelungen, kann die Vergabestelle Projekte risiko-

bewusst realisieren.

Die Erweiterung der Projektmanagementmethode HERMES um das

Modul Agilität war ein Schritt in die richtige Richtung.

Wünschenswert wäre eine weitere Anpassung von HERMES indem Agilität

eine über alle Projektphasen anzuwendende Arbeitsmethodik würde.

Anhang 27

Anhang A 1) Fragenkatalog und Übertragung in Unter- Gruppen

Anhang 28

2) Ergebnisse der Interviews und Übertragung in Gruppen

Abbildungsverzeichnis 29

Abbildungsverzeichnis Abbildung 1: Einflussfaktoren, Initiativen / Projekte und Spannungsfeld ........ 2

Abbildung 2: Einflussfaktoren auf Projekterfolg ............................................ 13

Abbildung 3: Phasen nach HERMES (Quelle hermes.admin.ch) ................. 14

Abbildung 4: Übersicht Verfahren (Quelle bbl.admin.ch) ............................. 16

Abbildung 5: Systemlandschaft IKT- System 4711 ...................................... 21

Abbildung 6: Projektphasen der Systemlandschaft ...................................... 21

Tabellenverzeichnis 30

Tabellenverzeichnis Tabelle 1: Projektmethoden / Standards und deren Phasen .......................... 9

Tabelle 2: Chancen / Risiken und deren Abhängigkeiten ............................. 11

Tabelle 3: Perspektiven / Zielsetzungen - Anforderungen / Kriterien ........... 12

Tabelle 4: Beschaffungsverfahren - Mischvarianten .................................... 18

Abkürzungsverzeichnis 31

Abkürzungsverzeichnis

BöB Bundesgesetz über das öffentliche Beschaffungswesen

BOK Body of Knowledge

DIN Deutsches Institut für Normung

DoD Definition of Done

EAMod Enterprise Architecture Modelling

IKT Informations- und Kommunikationstechnologie

ISO International Organization for Standardization

IT Informations- Technologie

PM Projektmanager

PMI Project Management Institute

RFI Request for Information

RFP Request for Proposal

RFQ Request for Quotation

RKW RKW Rationalisierungs- und Innovationszentrum der

Deutschen Wirtschaft e.V

SIA Schweizerischer Ingenieur und Architektenverein

VBS Departement für Verteidigung Bevölkerungsschutz und

Sport

VöB Verordnung über das öffentliche Beschaffungswesen

Literaturverzeichnis 32

Literaturverzeichnis Bech, K. und U. Wolff (2003). Projektmanagement‐Fachmann. Band 1. Esch-born, RKW. Bjarnason, E. Wnuk K. Regnell, B. (2011): A case study on benefits and side-effects of agile practices in large-scale requirements engineering. Proceed-ings of the 1st Workshop on Agile Requirements Engineering. ACM. Brown, T. (2001). “Modernisation or failure? IT development projects in the UK public sector,” Financial Accountability & Management, vol. 17, no. 4, pp. 363-381. Brüesch, C. Mertes, A. Flick Witzig, M. Giger M-A., Steinbrecher, M. Digitale Verwaltung: eine Studie des Institutes für Verwaltungs-Management (IVM) und KPMG Schweiz, ZHAW Zürcher Hochschule für Angewandte Wissen-schaften, 2017 Bucher, E. Obligationenrecht OR, Allgemeiner Teil (2. Auflage 1988) Ver-pflichtungen im Rahmen vorvertraglicher Beziehungen; Haftung aus «culpa in contrahendo», Schulthess Verlag, (S 277-288). Buckow, H. und D. J. Hoch (2007). Leitlinien für das Management von IT‐Projekten im öffentlichen Sektor. Handbuch E‐Government Strategien, Lö-sungen und Wirtschaftlichkeit. A. Zechner. Stuttgart, Fraunhofer IRB Verlag: 237‐240. Casutt, C. (2005). Projekt ‐ oder geht es auch einfacher? Projektmanage-ment, Handbuch für die Praxis. H.‐D. Litke. München, Carl Hanser. Dingsøyr, T., Nerur, S., Balijepally, V., und Moe, N. B. (2012). A decade of agile methodologies: Towards explaining agile software development. Jour-nal of Systems and Software, 85(6), 1213–1221. https://doi.org/10.1016/j.jss.2012.02.033 Dyba, T., und Dingsoyr, T. (2008). Empirical studies of agile software devel-opment: A systematic review. Information and Software Technology, 50(9-10), 833-859. Edquist, C. Hommen, L. and Tsipouri, L. (2000) “Policy implications,” in Pub-lic technology procurement and innovation, C. Edquist, L. Hommen and L. Tsipouri Eds. New York, Ny, USA: Springer Science+Business Media, pp. 301-311. Gunasekaran, A. (1999). Agile manufacturing: A framework for research and development. International Journal of Production Economics, 62(1–2), 87-105.

Literaturverzeichnis 33

Hardy, C. A. and Williams, S. P. (2008) “E-government policy and practice: a theoretical and empirical exploration of public e-procurement,” Government Information Quarterly, vol. 25, no. 2, pp. 155-180. Janowski, T. (2015). “Digital government evolution: from transformation to contextualization,” Government Information Quarterly, vol. 32, no. 3, pp. 221-236. Krippendorff, K. (2012). Content analysis: An introduction to its methodology. Thousand Oaks, CA, USA: Sage Publications Inc. Krippendorff, K. (1989) “Content analysis,” in International encyclopedia of communication (Vol. 1), Barnouw, E. Gerbner, G. Schramm, W. Worth, T. L. and Gross, L. Eds. New York, NY, USA: Oxford University Press, 1989, pp. 403-407. Liedtka, J. / Salzman, R. / Azer, D., (2017): Design Thinking for the Greater Good. Columbia University Press: New York. Madauss, B. J. (1994). Handbuch Projektmanagement mit Handlungsanlei-tungen für Industriebetriebe, Unternehmensberater und Behörden. Stuttgart, Schäffer‐Poeschel. Ohno, T. (1988). Toyota production system: Beyond large-scale production. Cambridge, MA: Productivity. Soe, R.-M., und Drechsler, W. (2018). Agile local governments: Experimenta-tion before imple-mentation. Government Information Quarterly, 35(2), 323–335. Sommerville, I. (2005). Integrated Requirements Engineering: A Tutorial. IEEE Softw. 22, 16–23. Sumrell, M. (2007). From Waterfall to Agile – How does a QA Team Transi-tion? In Proceedings of the Agile Conference (AGILE), 291–295. Unterwegs zu digitalen Welten, Trendstudie von Tata Consultancy Services (TCS) und Bitkom Research www.studie-digitalisierung.de, 2018

http://www.studie-digitalisierung.de/

Selbständigkeitserklärung 34

Selbständigkeitserklärung „Ich erkläre hiermit, dass ich diese Arbeit selbstständig verfasst und keine anderen

als die angegebenen Quellen benutzt habe. Alle Stellen, die wörtlich oder sinngemäss

aus Quellen entnommen wurden, habe ich als solche gekennzeichnet. Mir ist be-

kannt, dass andernfalls der Senat gemäss Artikel 36 Absatz 1 Buchstabe o des Ge-

setzes vom 5. September 1996 über die Universität zum Entzug des aufgrund dieser

Arbeit verliehenen Titels berechtigt ist.“

…………………………..

Avenches VD, 30.10.2019 Christian Marten

s i g .

Veröffentlichung 35

Veröffentlichung der Arbeit

� Hiermit erlaube ich, meine Arbeit auf der Website der Forschungsstelle Di-

gitale Nachhaltigkeit zu veröffentlichen.

� Hiermit erlaube ich, meine Arbeit den anderen Teilnehmenden des CAS

ICT-Beschaffungen (alle Jahrgänge) über ILIAS zugänglich zu machen.

� Ich möchte auf eine Veröffentlichung meiner Arbeit verzichten.

Die Benotung der Arbeit erfolgt unabhängig davon, ob die Arbeit veröffentlicht

werden darf oder nicht.

…………………………..

Avenches VD, 30.10.2019 Christian Marten

s i g .

ZusammenfassungInhaltsverzeichnis1 Einleitung1.1 Ausgangslage1.2 Problemstellung1.3 Zielsetzung1.4 Aufbau der Arbeit, Methodisches Vorgehen

2 Theorie2.1 Projekt2.1.1 Begriff Projekt und Projektarten

2.2 Agilität in Projekten2.2.1 Begriff Agilität2.2.2 Agilität und Projektarten2.2.3 Agilität in den Projekten

2.3 Beschaffung2.3.1 Grundlagen2.3.2 Beschaffungsverfahren2.3.3 Verfahrenswahl2.3.4 Kriterien und Spezifika2.3.5 Zuschlag2.3.6 Vertrag

3 Agilität in der öffentlichen Beschaffung3.1 Grundlagen3.1.1 Eigenheiten der IKT- Projekte im öffentlichen Sektor3.1.2 Generisches Projekt- Phasenmodell3.1.3 Allokation von agilen Phasen im Projekt

3.2 Bedürfnisse der Projektleiter3.2.1 Research3.2.2 Chancen3.2.3 Risiken3.2.4 Abhängigkeiten der Chancen und Risiken3.2.5 Transformation der Abhängigkeiten in Anforderungen und Kriterien3.2.6 Umfang des Pflichtenheftes

3.3 Vorbereitung von Beschaffungen mit Agilität3.3.1 Erfolgsfaktoren3.3.2 Set Up des Vorhabens3.3.3 Zusammenarbeit Lieferant und Auftraggeber und Vorgehen

3.4 Rechtliche Gestaltungsmöglichkeiten3.4.1 Ablauf der Phasen gemäss BöB / VöB3.4.2 Beschaffungsphasen in der Wirtschaft3.4.2.1 RFI (Request for Information)3.4.2.2 RFP (Request for Proposal)3.4.2.3 RFQ (Request for Quotation)

3.4.3 Kombination der Phasen3.4.4 Schlussfolgerungen

4 Agile Beschaffungen durchführen4.1 Agile Vorhaben4.1.1 Formulierung des Bedarfes4.1.2 Möglichkeiten im Beschaffungsdesign4.1.3 Beispiel aus der Praxis4.1.4 Die Herausforderung in der Praxis4.1.5 Phasen RFI / RFP / RFQ4.1.6 Voraussetzungen zur erfolgreichen Umsetzung4.1.7 Vertragliche Regelungen bei Agilität4.1.8 Weitere Rahmenbedingungen und Schlussfolgerungen

5 Schlussfolgerungen und AusblickAnhang AAbbildungsverzeichnisTabellenverzeichnisAbkürzungsverzeichnisLiteraturverzeichnisSelbständigkeitserklärungVeröffentlichung der Arbeit

Documents

Gestaltung von Ausschreibungen agiler IKT- Projekte · 2020. 2. 14. · , die Einführung und Realisierung erfolgt meist im Rahmen von Projek-ten. Um Projekte der Eidgenossenschaft