Übungsaufgaben zur Vorbereitung eines Projekts

Kopiere den Text in ein KI-Sprachmodell Deiner Wahl und passe Kompetenzstufe, Anzahl, Bearbeitungszeit und Szenario bei Bedarf an. Wie die Aufgaben aufgebaut sind, beschreibt der Artikel Wie sind die Aufgaben aufgebaut?. Prüfe die Ergebnisse mit dem Lehrartikel: KI-Sprachmodelle machen Fehler.

Erstelle neue Übungsaufgaben zum Thema „Vorbereitung eines Projekts“.

Bauplan: Halte Dich an Aufbau, Kompetenzstufen, Operatoren,
Anforderungsbereiche, Punkte und Zeitschätzung, die im Artikel
https://oer-informatik.de/aufgaben-aufbau beschrieben sind.

Fachliche Grundlage:
- https://oer-informatik.de/projekt-vorbereitung
- Stilbeispiel: https://oer-informatik.de/projekt-vorbereitung-uebungsaufgaben

Die Aufgaben sollen Inhalte zu diesen Schlagwörtern abdecken:
- Projektvorbereitung
- Magisches Dreieck
- Vision
- Mission
- Planning Poker
- Business Case
- Benefit
- Realisierungsalternativen
- Projektsteckbrief
- Lenkungsausschuss

Kompetenzstufe: Kernkompetenz (alternativ: Basiskompetenz, Profilkompetenz, Expertise)
Anzahl: 1 Aufgabe mit Teilaufgaben
Bearbeitungszeit in Minuten ca.: <5 bis 30 min>
Szenario: eines der Szenarien aus dem Bauplan

Vorgehen:
1. Lies zuerst die verlinkten Artikel. Kannst Du keine Webseiten
   abrufen, sag mir das, statt zu raten.
2. Steht bei einer Angabe noch ein Platzhalter in <…>, frag mich
   zuerst danach. Richte Punkte und Zahl der Teilaufgaben nach der
   Bearbeitungszeit (ca. 0,9 min je Punkt).
3. Gib je Aufgabe Titel mit Kompetenzstufe, Ausgangssituation und
   Teilaufgaben mit Operator und Punktzahl aus, dazu die geschätzte
   Bearbeitungszeit.
4. Gib die Beispiellösungen mit Punkteverteilung erst aus, wenn ich
   danach frage.

Je 1 Punkt für eine der folgenden Eigenschaften (höchstens 4 Punkte):

• zeitlich begrenzt (fester Anfang und fester Endtermin)

• einzigartig (auch wenn sich manche Projekte ähneln)

• häufig interdisziplinär, über mehrere Bereiche oder Abteilungen hinweg

• führt eine Veränderung herbei: Das Projektziel ist ein neuer Soll-Zustand

• findet in einem unsicheren Umfeld statt und birgt Risiken

Je 1 Punkt: Zeit (Terminziel), Kosten (Kostenziel), Qualität (Sachziel).

Die drei Zielkategorien hängen voneinander ab und konkurrieren miteinander: Verbessert man eine, verschlechtert sich mindestens eine andere. Es lassen sich immer nur zwei zugleich optimieren (2 Punkte). Beispiel: Soll ein Produkt in hoher Qualität sehr schnell fertig werden, müssen viele Personalstunden parallel in das Projekt fließen – es wird teuer. Alle drei Ziele zugleich zu erreichen, gelänge nur mit „Magie“ (1 Punkt für ein passendes Beispiel oder diese Erklärung des Namens).

Je 1 Punkt:

• 1 strategisches Ziel: konkret, prüfbar, mit Termin; leitet sich aus der Strategie in Satz 3 ab.

• 2 Mission: beschreibt wertorientiert, wie die Schule heute auf die Vision hinarbeitet.

• 3 Strategie: nennt ein Haupthandlungsfeld und einen konkreten Weg, aber noch keinen messbaren Zielwert.

• 4 Vision: emotionales, abstraktes Zukunftsbild.

• 5 Projektziel: ein einzelnes Vorhaben mit festem Termin, das zum strategischen Ziel in Satz 1 beiträgt.

• 6 Strategie: Handlungsfeld mit konkretem Weg (Lernplattform, Fortbildung).

Die Vision (Satz 4) beschreibt einen erstrebenswerten Zustand in der Zukunft, der emotional anspricht, aber nicht direkt überprüfbar ist (1 Punkt). Die Mission (Satz 2) beschreibt, wie das RRB im Hier und Jetzt und mit welchen Werten (wertschätzend, praxisnah, mit den Betrieben) auf diese Vision hinarbeitet; zusammen bilden beide das Leitbild (1 Punkt).

Ein Projekt muss zu den Zielen der Organisation beitragen; im Business-Case nennt die Projektbegründung das Ziel, das im Fokus steht, und der Projektnutzen nimmt Bezug auf strategische Ziele (1 Punkt). Kennt Thomas Becker das Leitbild, kann er zeigen, dass „RatzFahrt“ zum strategischen Ziel „weniger Verspätungen“ (Satz 1) und damit zur Strategie „Erreichbarkeit“ beiträgt – das stärkt die geschäftliche Rechtfertigung, und fällt das Ziel weg, muss das Projekt neu bewertet werden (1 Punkt).

Zutreffend sind die Aussagen 5 und 6. Je 1 Punkt für jede richtig angekreuzte bzw. richtig nicht angekreuzte Aussage:

• 1 trifft nicht zu: Planning Poker liefert Schätzungen, keine exakten Zeiten.

• 2 trifft nicht zu: Story Points sind eine relative Einheit ohne festen Umrechnungsfaktor in Stunden oder Tage; erst über die Erfahrung mehrerer Iterationen lässt sich abschätzen, wie viele Punkte ein Team in einer bestimmten Zeit schafft.

• 3 trifft nicht zu: Liegen die Schätzungen auseinander, begründen in der Regel die Personen mit dem höchsten und dem niedrigsten Wert ihre Einschätzung; danach wird erneut geschätzt.

• 4 trifft nicht zu: Gerade unterschiedliche Erfahrungen und Blickwinkel (z. B. Entwicklung, Test, Betrieb) decken übersehene Aufwände auf.

• 5 trifft zu: Story Points beschreiben Komplexität bzw. Aufwand einer Aufgabe.

• 6 trifft zu: Aufgaben werden im Vergleich zueinander geschätzt („doppelt so aufwendig wie …“).

Je 1 Punkt:

• Output: die Gesamtheit der Produkte, die im Projekt entstehen (das Projektprodukt).

• Outcome: das Ergebnis bzw. die Geschäftsänderung, die durch den Einsatz der Projektprodukte erreicht wird (z. B. geänderte Abläufe, verkürzte Bearbeitungszeit).

• Benefit: der eigentliche, messbare Nutzen dieser Änderung, der ein strategisches Ziel der Organisation fördert und oft erst lange nach Projektende messbar ist (z. B. Kosteneinsparung, Nachhaltigkeit, Imagegewinn).

Je 1 Punkt für ein passendes Beispiel, etwa:

• Output: die Web-App „RatzFahrt“ mit der anonymen Anzeige auf den Flurmonitoren (samt Dokumentation).

• Outcome: Auszubildende verabreden Fahrgemeinschaften über die App, statt einzeln mit dem Auto anzureisen oder auf schlecht getaktete Busse und Bahnen angewiesen zu sein.

• Benefit: weniger Verspätungen an Berufsschultagen, geringere Fahrtkosten für die Auszubildenden oder weniger CO₂ durch weniger Einzelfahrten – messbar z. B. über die Zahl der vermittelten Fahrten oder der Verspätungen je Monat, aber erst nach einiger Zeit im Betrieb.

Je Alternative 2 Punkte für einen stimmigen Weg mit mindestens zwei konkreten Schritten, z. B.:

• Selbst entwickeln („Make“): Anforderungen mit SV, Andrea Wolf und Schul-IT erheben, Projektteam und Zeitplan bis zum Start festlegen, die App iterativ entwickeln und testen, Hosting und Flurmonitore mit der Schul-IT OWL einrichten, Datenschutzprüfung vor dem Start, Betrieb und Pflege nach Projektende regeln (z. B. Übergabe an das nächste Projektteam).

• Einkaufen („Buy“): Angebot und Nutzungsbedingungen prüfen (Datenschutz, Mindestalter, Kündigungsfristen), ggf. weitere Angebote einholen, Auftragsverarbeitungsvertrag schließen, Zusatzmodul für die Flurmonitore klären, Plattform einrichten lassen, Konten und Regeln des RRB konfigurieren, Nutzende informieren.

• Nicht durchführen: keine Projektkosten; die SV organisiert Fahrgemeinschaften weiter über Aushänge und Chatgruppen, ggf. mit einer Anleitung, welche Daten dort nicht geteilt werden sollen; nach einiger Zeit (z. B. ein Schuljahr) neu prüfen, ob sich die Lage geändert hat.

Je 1 Punkt, z. B.:

• Vorteil: schnell einsatzbereit (vier Wochen) und erprobt, die Pflege übernimmt der Anbieter.

• Nachteil: Minderjährige Auszubildende dürfen sie nicht nutzen; kein Login über das Schulkonto; laufende Kosten von 1.080 € im Jahr plus Zusatzmodul; Abhängigkeit vom Anbieter.

1 Punkt für eine eindeutige Entscheidung, je 1 Punkt für ein passendes Argument aus der Situation. Beispiel für „Selbst entwickeln“: Viele Auszubildende sind minderjährig und wären von der eingekauften Plattform ausgeschlossen; die Eigenentwicklung kann die Einwilligung der Erziehungsberechtigten, das Schulkonto und die anonyme Monitoranzeige von Anfang an abbilden. Außerdem ist das Projekt Teil der Ausbildung – die Entwicklungsleistung kostet die Schule kaum Geld, die Pflege nach Projektende muss aber geregelt werden.

Eine begründete Entscheidung für „Einkaufen“ (z. B. weil der Starttermin sicher gehalten werden soll und die Pflege dauerhaft gesichert ist, mit der Bedingung, dass der Anbieter Minderjährige zulässt) ist ebenso richtig.

Die Alternative ist der Vergleichsmaßstab: Nur wenn Kosten und Risiken der anderen Wege einen Nutzen gegenüber dem bisherigen Zustand bringen, ist das Projekt geschäftlich gerechtfertigt (1 Punkt). Der Business-Case wird über die ganze Projektlaufzeit gepflegt; fällt die Rechtfertigung später weg (z. B. weil der Busverkehr besser getaktet wird), ist „nicht durchführen“ bzw. der Abbruch die richtige Entscheidung (1 Punkt).

Der Projektsteckbrief fasst alle Informationen aus der Vorbereitungsphase zusammen, damit der Lenkungsausschuss bzw. die Auftraggeberin entscheiden kann, ob das Projekt gestartet wird (1 Punkt). Bestandteile (je 0,5 Punkte, höchstens 2 Punkte): Business-Case-Entwurf, Projektrollen (z. B. als Organigramm), Projektprodukte mit Verweis auf ihre Beschreibungen; 0,5 Punkte zusätzlich, wenn erkennbar ist, dass der Business-Case der wesentliche Bestandteil ist.

Je Feld 1 Punkt, wenn die Angabe zur Situation passt und dem Zweck des Feldes entspricht:

Annahmen müssen gekennzeichnet sein; andere stimmige Einträge sind möglich. Punktabzug, wenn im Projektnutzen nur das Produkt (die App) oder die Geschäftsänderung (Fahrgemeinschaften) statt des messbaren Nutzens steht.

Je Rolle 1 Punkt für eine passende Person mit Begründung, z. B.:

• Unternehmensvertretung: Petra Schulze-Albers – sie verantwortet das Schulbudget und achtet darauf, dass das Projekt den Zielen des RRB dient.

• Benutzervertretung: eine Vertreterin oder ein Vertreter der SV, z. B. Ben Richter als Fahrer, ggf. zusammen mit Andrea Wolf als künftiger Administratorin – sie benennen die Anforderungen der Nutzenden.

• Lieferantenvertretung: Svenja Krämer (Schul-IT OWL, liefert Netz, Hosting und Monitore) und Oksana Melnyk für das FIA-Projektteam, das die App entwickelt.

Thomas Becker gehört als Projektleitung nicht selbst in den Lenkungsausschuss, sondern erhält von ihm die Entscheidungstoleranzen.

1,5 Punkte für vier passende Produkte, 0,5 Punkte für die richtige Kennzeichnung, z. B.: Web-App „RatzFahrt“ mit Flurmonitor-Anzeige (Spezialistenprodukt), Liste der User Stories bzw. Anforderungen, Zeitplan, Datenschutzkonzept mit Einwilligungsformular, Testprotokolle, Betriebshandbuch für die Schul-IT.