skip_to_content
  1. Home
  2. Wissen

Collaboration Framework Webprojekt

Mit dem Collaboration Framework setzt sich Swico für mehr Transparenz beim Initiieren von Webprojekten ein und legt so eine praxisorientierte Grundlage für eine gute Zusammenarbeit.

Das Collaboration Framework setzt Guidelines, rechtliche Grundlagen und Best Practices in einen Kontext. Die Marktteilnehmer erarbeiten die praxisbezogenen Inhalte des Frameworks und bauen diese kontinuierlich aus. 

An Roundtable-Events werden aktuelle Herausforderungen besprochen und im Konsens ins Collaboration Framework aufgenommen und weiterentwickelt. 
Dabei werden die Reibungspunkte in der Zusammenarbeit zwischen Auftraggebern und Auftragnehmern in Webprojekten aufgezeigt und Verständnis für die jeweiligen Anliegen des anderen geschaffen.

RFP oder Pitch

Richtig aufgesetzt kann ein RFP oder eine Wettbewerbspräsentation (Pitch) der Beginn einer langfristigen Zusammenarbeit sein. In der Praxis entstehen aufgrund von fehlenden oder unklaren Abmachungen nach dem Pitch oder nach der Abgabe des RFP gerne Konflikte, welche zu langwierigen Rechtsstreitigkeiten führen können – aber vor allem zu Unzufriedenheit auf beiden Seiten.

Request for Proposal (RFP)

Auf einen Pitch wird verzichtet, stattdessen wird eine Offerte verlangt. Aufgrund der Offerten werden Agenturen ausgewählt, um mit ihnen das Projekt detaillierter zu beleuchten. Der Begriff RFP umfasst hier auch Anfragen, aufgrund derer direkt entschieden wird.

Der RFP verlangt vom Auftragnehmer, eine Lösung für die Anforderungen zu entwickeln und zu beziffern. Mit dem RFP unterbreitet der Anbieter neben den Zahlen bereits erste Umsetzungsideen und Lösungsansätze für die Aufgabe, welche dem Auftraggeber ohne Entgelt/Schutzgebühr überlassen werden.

Wettbewerbspräsentationen (Pitch)

Wettbewerbspräsentationen werden ausgeschrieben,  um für ein Projekt bzw. Etat die richtige Agentur auszuwählen. Der Auftraggeber formuliert im Briefing die Aufgabenstellung des Pitches. Es bildet die Grundlage für den Pitch und ist die wesentliche Schnittstelle zwischen dem Unternehmen und den Agenturen.
 
Anhand des Briefings formuliert der Auftraggeber seine konkreten Ziele und die klare Aufgabenstellung an die Agentur. Das Briefing sollte mit dem Entscheidungsgremium des Unternehmens abgesprochen sein.

Auswahl von geeigneten Agenturen für den Pitch

Aufgrund der Präsentationen und Vorschläge wählt der Auftraggeber mithilfe von gewichteter Eignungskriterien drei Agenturen aus, die seiner Meinung nach am besten für die Aufgabe geeignet sind, und lädt diese zur Phase 2 des Auswahlverfahrens ein.

Phase 2

In der zweiten Phase des Pitch-Verfahrens soll der Auftraggeber ein vertieftes Verständnis zur Arbeitsweise und das Vorgehen des Auftragnehmers erhalten. Jetzt präsentiert der Auftragnehmer konkrete Lösungen.

Mündliches und schriftliches Briefing

Ein Muss ist ein persönliches Briefinggespräch zu Beginn der zweiten Phase. Gegenseitiges Verständnis für die Aufgabe und Kennenlernen des möglichen  zukünftigen Partners sind für die richtige Wahl der Agentur genauso wichtig wie die geleistete Arbeit im Pitch.

Angemessenes Pitch-Honorar

Das Pitch-Honorar sollte im Vorfeld festgelegt werden. Jeder Auftragnehmer darf sich überlegen, ob er zu den Konditionen mitmachen will. Ziel des Honorars ist nicht, die Kosten der Agentur zu tragen. Es soll gewährleisten, dass auch Geld fürs Projekt verfügbar ist. Sprich, es wird nicht einfach nur zum «Spass» gepitched.
Wird ein  Ausfallhonorar von CHF 3000.– angesetzt, investiert der Auftraggeber CHF 9000.–,  um die Auswahl zu treffen.
 
Neben dem Ausfallshonorar kann zudem die mögliche Nutzung eines Konzeptes, aber ohne deren Umsetzung durch den Auftragnehmer, geregelt werden. Erachtet beispielsweise der Auftragnehmer das Konzept als sehr gut, stimmt jedoch die Chemie zwischen den Parteien nicht, kann der Auftraggeber durch Zahlung eines Honorars das Konzept mit einem anderen Partner umsetzen. Durch das Honorar wird das Nutzungsrecht übertragen.
Verlierer-Agenturen erhalten in jedem Fall ein Pitch-Honorar (sog. Schutzgebühr).

Anforderung an die Präsentation

Präsentation von Konzept, Gestaltung und Machbarkeit, inkl. klickbaren Prototypen für Website oder App.

Alternativen zum Pitch/RFP

Wettbewerbspräsentationen lassen sich durch «Vorprojekte» mit potenziellen Auftraggebern umgehen. Diese eher kleinen Projekte decken einen Teil des zu realisierenden Projektes ab. In der persönlichen Zusammenarbeit an einer konkreten Aufgabe, wird beidseitig recht schnell klar, ob eine Zusammenarbeit zielführend ist. Entscheidend ist, ob das Projektteam die gleichen Werte und Vorstellungen teilt, als Team kompatibel ist – und natürlich, ob die Qualität der Artefakte den Bedürfnissen und Anforderungen entspricht. Dieser Aspekt der Zusammenarbeit – wie arbeiten die Menschen auf Auftraggeber- und Auftragnehmer-Seite zusammen – geht beim Pitch fast gänzlich unter, da lediglich Fakten, Budget und Resultate zählen.

Guidelines Requirements

Erfahrungswerte zeigen, dass sich mindestens 30 % eines Anforderungskatalogs während des Projektes ändert: Entweder fallen Anforderungen weg oder neue kommen dazu oder bestehende werden inhaltlich geändert. In den meisten Fällen können Software-Projekte nicht durchgeplant werden, da während des Projektes viele Unbekannte auftauchen oder sich die Umstände ändern. Die häufigsten, typischen Fehler:

Personas oder Vision nicht vorhanden   

  • Fehler: Die Vision oder Persona der Anwendung ist nicht klar. 
  • Risiko: Die Anforderungen sind dadurch falsch oder unklar definiert. Dadurch wird falsch investiert. 
  • Best Practice: Vision, Persona und deren Bedürfnisse am Anfang des Projektes klar definieren und sich stets daran orientieren.

Zu hoher Detailierungsgrad der Anforderungen

  • Fehler: Anforderungen bis ins letzte Detail ausdetaillieren. 
  • Risiko: Informationen und Umstände während des Projektes ändern stetig. Somit kommen neue Informationen hinzu. Wenn man an den Detailanforderungen festhält, besteht die Gefahr, an der Realität vorbei zu entwickeln. 
  • Best Practice: Die funktionalen Anforderungen werden in horizontaler (User Journey) und vertikaler Weise (einzelne, äusserst wichtige Funktionalitäten) aufgenommen. Details werden vorzu neu definiert. 

Fehlende Mitwirkung des Auftraggebers während des Projektes

  • Fehler: Auftraggeberin nimmt sich nur am Schluss des Projektes Zeit zum Testen. 
  • Risiko: So fällt erst am Schluss auf, was vergessen ging, was noch fehlt oder was für die Persona nicht passt. 
  • Best Practice: In Intervallen und in Absprache mit Auftraggeber entwickeln, testen und stetig gemäss dem höchsten Business Value anpassen.

Begriffe und Definitionen

  • Auftraggeberin 
    Ist die Partei, die den Auftrag der Entwicklung einer Applikation/Anwendung oder einer Website gibt. 
  • Auftragnehmerin
    Ist die Partei, die im Auftrag die Applikation/Anwendung oder die Website entwickelt. 

  • End-Kunde/User/Anwender
    Bezeichnet die Person, die die Applikation schliesslich nutzt.

  • Cross-funktionales Team
    Besteht aus Entwickler/innen, User Experience Spezialisten/innen, Designern, Projektleiter/in und weiteren Experten, die für das Projekt relevant sind. Sie kümmern sich direkt um das zu erarbeitende Produkt und arbeiten eng mit der Auftraggeberin zusammen. 

  • Persona
    Archetypische Darstellung des Benutzers der Applikation oder Website. Siehe auch
    Persona

  • Epics
    Grosse, grobe Themen einer Anwendung und damit auch Arbeitspakete. Siehe auch
    Anforderungsmanagement

  • Funktionale Anforderungen (FA)
    Funktionale Anforderungen beschreiben gewünschte Funktionalitäten (was soll das System tun/können?) eines Systems bzw. Produkts, dessen Daten oder Verhalten. Nichtfunktionale Anforderungen sind Anforderungen, an die Qualität, in welcher die geforderte Funktionalität zu erbringen ist.  Aus
    Funktionale Anforderungen

  • Nicht-funktionale Anforderungen (NFA)
    Die nicht-funktionalen Anforderungen beschreiben, wie gut das System die Leistung erbringen soll; sie werden vielfach als Randbedingungen und Qualitätseigenschaften verstanden. Ein Beispiel: Das Produkt soll dem Anwender innerhalb einer Sekunde antworten. Siehe auch
    Anforderung (Informatik)

  • User Journey
    Alle Schritte, die ein Nutzer geht, um ein gewisses Ziel mit einem interaktiven System zu erreichen. Sie bestehen meistens aus einer Anzahl von Website-Seiten und Entscheidungspunkten, die den Nutzer von einem Schritt zum nächsten bringen. User Journeys werden in User Journey Maps abgebildet, die diesen Weg mit allen Schritten und Erfahrungen detailliert zeigen. Siehe auch
    Netzstrategen – User Journey

Um ein Webprojekt ausführen zu können, gibt es Komponenten, die vorab definiert werden müssen: 

  • Vision, inkl. Personas 
    Durch sie entsteht das Verständnis zwischen Auftraggeberin und Auftragnehmerin zu den Zielen, zur User Experience und zum Design der Applikation. 
  • Funktionale Anforderungen (FA) – siehe Begriffe
    Grobe Definition von Funktionalitäten, welche die Applikation enthalten muss.
  • Nicht-funktionale Anforderungen (NFA)  – siehe Begriffe
    Dies sind Anforderungen, die sich übergreifend durch die ganze Applikation ziehen und bei der Umsetzung von funktionalen Anforderungen als Massstäbe gelten. 
     

Fragen zum CollaborationFramework?

palmisani_giancarlo_2553__weiss_ganz.jpg

Giancarlo Palmisani

Leiter Verbandsdienstleistungen / GL-Mitglied
+41 44 446 90 85
E-Mail

Swico Cookie Policy
Swico nutzt eigene Cookies sowie Cookies von Dritten zu Marketing-, Profilerstellungs- und Analysezwecken sowie zur erleichterten Navigation auf der Website. Bitte lesen Sie hierzu unsere Datenschutzerklärung. Klicken Sie auf SCHLIESSEN, um Cookies zu akzeptieren.