Struktur schlägt Chaos: Wie Citizen Developer Projekte sauber starten

Projektmanagement  |  Citizen Developer  |  Power Platform

Du kennst das: Jemand kommt auf dich zu, hat eine Idee, und du fängst motiviert an. Irgendwann steckt das Projekt fest. Anforderungen waren unklar, Zuständigkeiten fehlen, neue Ideen kommen ständig dazu. Was als kleines Automatisierungsprojekt begann, wird zum Chaos.

Das passiert nicht, weil du schlechte Arbeit machst. Es passiert, weil Citizen Developer Projekte oft ohne Struktur starten. Dabei braucht es kein großes IT-Framework. Nur ein paar klare Fragen am Anfang und eine Vorlage, die dich durch das Projekt führt.

Ich habe mir genau dafür eine Mastervorlage gebaut. Sie begleitet mich bei jedem Projekt, egal ob Excel-Automatisierung, Power Automate Flow oder Office Script. In diesem Beitrag zeige ich dir, wie sie aufgebaut ist und wie ich sie konkret beim Urlaubsantragsprojekt eingesetzt habe.

Ich erkläre dir die einzelnen Bestandteile anhand eines Beispiels für einen Urlaubsantrag, welcher automatisiert/digitalisiert werden soll.

🧩 1. Ausgangslage: Was nervt eigentlich?

Bevor du auch nur eine Zeile Code schreibst oder einen Flow baust, musst du verstehen, warum der aktuelle Prozess schlecht läuft. Klingt selbstverständlich, wird aber ständig übersprungen.

In der Vorlage halte ich zwei Dinge fest:

• IST-Zustand: Wie läuft der Prozess heute ab? Wo entstehen Fehler, Wartezeiten oder Chaos?
• SOLL-Zustand: Was ist das konkrete Ziel der Automatisierung?

Beim Urlaubsantragsprojekt war der IST-Zustand schnell klar: Urlaub wurde per E-Mail beantragt, Datumsangaben wurden vergessen, der Chef musste manuell in einer Excel-Datei nachschauen, wer schon Urlaub hat. Der SOLL-Zustand: automatische Validierung, zentrale Datenhaltung, schnellere Genehmigung und mehr Transparenz für alle.

Ohne diese Klarheit baust du am Problem vorbei.

👥 2. Akteure: Wer spielt welche Rolle?

Ein Projekt scheitert selten an der Technik. Es scheitert an fehlenden Zuständigkeiten. Deshalb kläre ich früh drei Rollen:

Rolle	Frage
Eingabeperson	Wer stößt den Prozess an?
Entscheider	Wer muss entscheiden oder freigeben?
Zuschauer / Informierte	Wer muss am Ende Bescheid wissen?

Beim Urlaubsantrag: Mitarbeitende stellen den Antrag, der Teamleiter genehmigt, und der Zeitbeauftragte muss bei Genehmigung informiert werden, damit der Urlaub ins System übernommen wird. Drei Rollen, klar definiert. Das reicht völlig.

🔄 3. Der Prozess: Erst der Happy Path

Bevor du an Ausnahmen denkst, zeichne den Standardweg. Den sogenannten Happy Path: Was passiert, wenn alles funktioniert wie geplant?

Beim Urlaubsantrag sieht das so aus:

1. Mitarbeiter füllt das Formular aus
2. Formular wird validiert (Datum, Pflichtfelder)
3. Antrag geht automatisch an den Teamleiter
4. Teamleiter genehmigt oder lehnt ab
5. Mitarbeiter erhält Rückmeldung, Zeitbeauftragter wird informiert

Erst danach kommen die Abzweigungen: Was passiert, wenn der Teamleiter nicht reagiert? Was, wenn das Datum ungültig ist? Was, wenn der Vorgesetzte wechselt? Wer zuerst die Ausnahmen plant, verliert sich im Detail.

🧰 4. Toolauswahl: UI – Logik – Daten

Citizen Developer verlieren sich oft in der Toolauswahl. Dabei hilft eine simple Dreiteilung, die ich in jeder Vorlage verwende:

• Eingabe (UI): Wo tippt der Mensch? (Power Apps, Excel, Formular)
• Logik (Engine): Wer steuert den Ablauf? (Power Automate, Office Script, VBA)
• Daten (Speicher): Wo liegt alles sauber? (SharePoint-Liste, OneDrive)

Beim Urlaubsantrag: Power Apps für die Eingabe, Power Automate für den Genehmigungsflow, SharePoint-Liste als Datenbasis. Klare Trennung, keine Überschneidungen.

⚠️ 5. Risikoanalyse: Was könnte schiefgehen?

Drei Risikokategorien reichen für Citizen Developer Projekte völlig aus:

• Menschliches Risiko: Wie verhindern wir Fehleingaben? Beim Urlaubsantrag: Datumsprüfung in Power Apps: Startdatum darf nicht in der Vergangenheit liegen.
• Prozessrisiko: Was passiert, wenn Zuständigkeiten wechseln? Der Vorgesetzte muss automatisch aus dem System ermittelt werden, nicht hardcodiert.
• Technisches Risiko: Was passiert bei Fehlern oder Zeitüberschreitungen? Beim Urlaubsantrag: Erinnerungsmail nach 24h, Eskalation nach 72h.

Damit wird aus „Hoffen, dass es klappt“ ein belastbarer Prozess.

📊 6. Erfolgskontrolle: Hat es wirklich geholfen?

Nach der Einführung kommt die Frage: War das alles sinnvoll? Ohne Feedbackschleife gibt es keine Verbesserung. Ich plane deshalb von Anfang an eine Feedbackrunde ein.

Was ich messe:

• Weniger Rückfragen beim Antragsteller?
• Schnellere Genehmigungszeiten?
• Messbare Zeitersparnis pro Antrag?
• Wird das System akzeptiert oder umgangen?

Beim Urlaubsantrag starte ich die erste Feedbackrunde vier Wochen nach der Testphase. Nicht früher. Der Prozess braucht Zeit, um sich einzuspielen.

💡 Bonus: Ideen parken statt überladen

Während der Entwicklung kommen ständig neue Ideen. „Könnten wir nicht auch…?“. Ja, könnten wir. Aber nicht jetzt.

In der Vorlage gibt es einen eigenen Bereich für Erweiterungsideen. Alles, was nicht zum aktuellen Auftrag gehört, landet dort. So bleibt das Projekt schlank und gute Ideen gehen trotzdem nicht verloren.

Beim Urlaubsantrag sind das zum Beispiel: Urlaub stornieren, mehrere Urlaubsblöcke in einem Antrag, Erinnerung, wenn der Urlaub bald beginnt. Alles sinnvoll, aber für Version 2.

⚠️ Ganz wichtig: Dokumentieren!

Das ist der Teil, den die meisten überspringen. Und der Teil, den du später am meisten vermisst.

Schreib auf:

• Warum du etwas so gebaut hast, wie du es gebaut hast
• Was du dabei gelernt hast
• Wie viel Zeit du investiert hast

Beim Urlaubsantrag führe ich ein Entwicklungstagebuch direkt in der Vorlage.
Tag 1: SharePoint-Liste aufgebaut, Indexierung gelernt.
Tag 2: Power Apps Oberfläche bereinigt, erste Validierungen eingebaut.
Tag 3: Datumsprüfung mit PowerFX umgesetzt, Mitarbeiterfeld automatisch befüllt.

Das klingt nach Aufwand. Ist es aber nicht. Fünf Minuten nach jeder Session reichen. Und wenn du sechs Monate später weißt, warum du damals eine bestimmte Entscheidung getroffen hast, wirst du dir selbst dankbar sein.

Fazit: Struktur ist kein Overhead, sie ist der Unterschied

Die Mastervorlage macht dein Projekt nicht komplizierter. Sie macht es klarer. Du weißt von Anfang an, was du baust, für wen, mit welchen Tools und was Erfolg bedeutet.

Und das Beste: Sie ist bewusst schlank gehalten. Citizen Developer Projekte sind keine IT-Großprojekte. Sie brauchen kein 50-seitiges Konzept. Sie brauchen die richtigen Fragen zur richtigen Zeit.

Die Mastervorlage kannst du dir unten herunterladen. Ich habe diese als Rohfassung und auch als Beispielfassung mit dem Urlaubsantragsprojekt als Beispiel ausgefüllt, damit du siehst, wie sie in der Praxis aussieht. Probiere sie bei deinem nächsten Projekt aus, du wirst den Unterschied merken.

Ich selbst nutze die Vorlagen in OneNote. Hier habe ich die größte Flexibilität der Organisation der Projekte und kann recht einfach auch meine visuellen Programmabläufe erstellen. Wo du am Ende aber deine Projekte dokumentierst, ist egal. Wichtig ist nur, das du sie dokumentierst und planst.

Die 8 Bausteine der Mastervorlage auf einen Blick

#	Baustein	Kernfrage
00	Auftragsschreiben	Was wurde mir genau aufgetragen?
01	Ausgangslage	Was ist der IST-Zustand, was soll der SOLL-Zustand sein?
02	Akteure	Wer gibt ein, wer entscheidet, wer muss informiert werden?
03	Der Prozess	Wie sieht der Happy Path aus?
04	Toolauswahl	Welches Tool übernimmt UI, Logik und Datenspeicherung?
05	Risikoanalyse	Was kann menschlich, prozessual oder technisch schiefgehen?
06	Erfolgskontrolle	Wann und wie messen wir den Erfolg?
07	Erweiterungsideen	Welche Ideen parken wir für später?
08	Dokumentation	Was haben wir gebaut, gelernt und wie lange hat es gedauert?