Eine Projekt-Setup-Checkliste schafft die Mindestbedingungen für koordinierte Arbeit: einen klaren Zweck, festgelegte Grenzen, zuständige Entscheider, passenden Zugriff, verstandene Abhängigkeiten und eine Möglichkeit, den Fortschritt zu prüfen. Sie soll dem Team einen verantwortungsvollen Start ermöglichen. Sie soll weder zum Papierkram-Wettbewerb werden noch den Eindruck erwecken, vor dem Lernen müsse jede Unsicherheit verschwinden.
Trennen Sie das Setup von der Detailplanung. Das Setup ermöglicht Entscheidungen und Zusammenarbeit. Die Planung entwickelt die Arbeit weiter, während Wissen entsteht. Eine sorgfältig kategorisierte Aufgabenliste ersetzt keine Einigung darüber, was das Projekt verändern soll.
Die Leitlinien der University of Massachusetts Boston zur Projektinitiierung veranschaulichen den Unterschied zwischen dem Erstellen eines Projektauftrags und der späteren Entwicklung des Plans. Die Checkliste hier ist eine allgemeine Arbeitshilfe; die Genehmigungsvorgaben Ihrer Organisation gelten weiterhin.
Die Projekt-Setup-Checkliste
| Bereich | Prüfung | Evidenz für die Bereitschaft |
|---|---|---|
| Zweck | Können wir das Problem und das beabsichtigte Ergebnis erklären? | Kurzes abgestimmtes Briefing mit Quellenevidenz |
| Umfang | Was ist enthalten, ausgeschlossen und unsicher? | Grenzen und offene Fragen sind sichtbar |
| Befugnisse | Wer kann jede wichtige Entscheidung treffen? | Benannte Entscheider und Eskalationsweg |
| Beteiligte | Wer liefert, wirkt mit und betreibt das Ergebnis? | Angenommene Zuständigkeiten und realistische Verfügbarkeit |
| Abhängigkeiten | Was müssen andere bereitstellen? | Bestätigter Beitrag oder ausdrückliche Annahme |
| Zugriff | Können Mitwirkende die erforderlichen Informationen und Werkzeuge nutzen? | Berechtigungen über genehmigte Wege geprüft |
| Arbeitssystem | Wo liegen Aufgaben, Entscheidungen, Risiken und Dokumente? | Gemeinsame Ablagen mit klarer Zuständigkeit |
| Prüfung | Wie untersuchen wir Ergebnisse und Zusammenarbeit? | Geplante Prüfpunkte und nutzbare Signale |
Eine Prüfung ist nicht abgeschlossen, nur weil ein Dokument existiert. Jemand sollte es verwenden können, um eine reale Frage zu beantworten. Kann das Briefing nicht klären, ob eine Anfrage zum Umfang gehört, muss der Abschnitt zum Umfang weiter ausgearbeitet werden.
Mit einem kurzen Projektbriefing beginnen
Beschreiben Sie das Problem, die betroffene Gruppe und die beabsichtigte Änderung in klarer Sprache. Nennen Sie die verfügbare Evidenz und ihre Grenzen. Eine angefragte Umsetzung kann als Option oder Einschränkung vorkommen, darf aber nicht den Bedarf verdecken, dem das Projekt dient.
Definieren Sie Erfolg anhand dessen, was das Team prüfen kann. „Das Portal starten“ beschreibt die Lieferung. „Nutzer können die Zielaufgabe ohne die bisherige manuelle Übergabe erledigen“ beschreibt ein Ergebnis, das überprüft werden muss. Möglicherweise brauchen Sie beides, sollten es aber nicht verwechseln.
Halten Sie zwingende Einschränkungen getrennt von Präferenzen fest. Eine gesetzliche Vorgabe, ein bestehender Vertrag und ein bevorzugter Starttermin haben unterschiedliche Auswirkungen. Nennen Sie, wer die Einschränkung bestätigt hat, damit sie bei geänderten Bedingungen überprüft werden kann.
Zuständigkeit konkret festlegen
Listen Sie die wahrscheinlichen Entscheidungen auf, bevor Sie jede Rolle aufführen. Dazu können Änderungen am Umfang, Budgetentscheidungen, die betriebliche Abnahme und offene teamübergreifende Abhängigkeiten gehören. Bestimmen Sie, wer entscheidet, wer beiträgt und wann eine Eskalation nötig ist.
Bitten Sie jede zuständige Person, die Verantwortung anzunehmen. Einen Namen in ein Dokument einzutragen schafft weder Zeit noch Befugnisse. Ist die Zuständigkeit geteilt, klären Sie, wer die unmittelbare Entscheidung koordiniert und wie Meinungsverschiedenheiten gelöst werden.
Beziehen Sie die Menschen ein, die das Ergebnis betreiben. Support, Wartung, Barrierefreiheit, Schulung oder Datenverantwortung können Arbeit vor dem Start erfordern. Diese Beteiligung gehört ins Setup und sollte nicht erst bei einer abschließenden Bereitschaftsprüfung überraschend auftauchen.
Abhängigkeiten bestätigen, statt sie vorauszusetzen
Halten Sie für jeden externen Beitrag das benötigte Ergebnis, die koordinierende Person, den spätesten sinnvollen Termin und die Evidenz für die Zusage fest. Unterscheiden Sie „angefragt“ von „angenommen“.
Fragen Sie anschließend, was passiert, wenn der Beitrag verspätet oder anders als erwartet eintrifft. Die Antwort kann eine neue Reihenfolge, einen kleineren Umfang, die Untersuchung einer Alternative oder eine Terminänderung sein. Verstecken Sie die Abhängigkeit nicht als Aufgabenstatus auf Ihrem eigenen Board.
Befindet sich das Projekt noch in der Discovery-Phase, bleiben manche Abhängigkeiten unsicher. Das ist vertretbar, wenn die Unsicherheit sichtbar ist und jemand den nächsten Evidenzschritt verantwortet. Riskant ist es, wenn der Plan den Beitrag als garantiert behandelt.
Ausgearbeitetes Beispiel: einen internen Anfrageprozess umstellen
Hypothetisches Beispiel: Ein Team will interne Anfragen aus E-Mails in einen gemeinsamen Aufnahmeprozess verlagern. Das erste Setup besteht aus einem Board, einem Zieltermin und einer Liste von Formularfeldern.
Die Checkliste deckt drei Lücken auf. Niemand ist für Ausnahmen zuständig, die nicht ins Formular passen. Von einem Betriebsteam wird Support erwartet, ohne dass seine Kapazität bestätigt ist. Historische Anfragedaten enthalten Informationen, die nicht in einen breit zugänglichen Arbeitsbereich kopiert werden sollten.
Das Team ändert das Setup, bevor es die Aufgabenliste erweitert. Es benennt eine zuständige Person für Ausnahmen, bestätigt eine erste Supportregelung und vereinbart den genehmigten Umgang mit Daten mit der zuständigen Person. Außerdem beschränkt es die erste Veröffentlichung auf eine Anfragekategorie.
Das Projekt kann nun in einer begrenzten Einführung Erkenntnisse gewinnen. Die Checkliste hat nicht jedes Risiko vorhergesagt, aber wichtige Entscheidungen sichtbar gemacht, solange sie noch kostengünstig geändert werden können.
Das Informationssystem schlank aufsetzen
Wählen Sie für jede Informationsart einen verbindlichen Ablageort. Aufgaben zeigen Arbeit und Zuständigkeit. Ein Entscheidungsprotokoll hält Wahl, Begründung und entscheidende Person fest. Ein Risikoprotokoll zeigt Unsicherheiten und Reaktionen. Referenzdokumente enthalten Material, das nicht in jede Aufgabe kopiert werden sollte.
Verlinken Sie diese Ablagen, statt doppelte Fassungen zu pflegen. Ändert sich eine Entscheidung, aktualisieren Sie den maßgeblichen Eintrag und informieren Sie die betroffenen Personen. Ein Aufgabenkommentar kann auf die Änderung verweisen, ohne eine zweite Quelle der Wahrheit zu werden.
Prüfen Sie den Zugriff mit repräsentativen Mitwirkenden. Verteilen Sie keine Zugangsdaten und umgehen Sie keine Berechtigungskontrollen, nur um die Checkliste auf „grün“ zu setzen. Kann jemand erforderliches Material nicht öffnen, lösen Sie das über den genehmigten Zugriffsprozess und halten Sie die Blockade fest.
Das Setup nach der ersten echten Arbeit überprüfen
Planen Sie eine kurze Prüfung, sobald das Team genug Erfahrung hat, um das Setup zu hinterfragen. Fragen Sie, welche Entscheidungen sich verzögert haben, welche Zuständigkeiten unklar waren und welche Informationen schwer zu finden waren.
Nutzen Sie eine agile Retrospektive für Fragen zur Zusammenarbeit. Eine einfache Retrospektiven-Idee kann helfen, vor der Diskussion Beobachtungen zu sammeln. Wählen Sie eine Verbesserung der Arbeitsweise und prüfen Sie sie mit dem Verbesserungsprozess der Retrospektive.
Reagieren Sie nicht auf jede Schwierigkeit mit einer weiteren Vorlage. Manchmal besteht die Lösung darin, einen doppelten Eintrag zu entfernen, ein Entscheidungsrecht zu klären oder einer zuständigen Person genügend Zeit zu geben.
Hinweise, dass das Projekt noch nicht bereit für eine Zusage ist
Halten Sie eine wichtige Zusage zurück, wenn niemand sie genehmigen kann, der Zieltermin von einem unbestätigten externen Beitrag abhängt oder sich das Ergebnis nicht einheitlich erklären lässt. Führen Sie sinnvolle unabhängige Discovery-Arbeit fort, bezeichnen Sie aber einen unbelegten Termin nicht als Versprechen.
Auch ungeklärter Zugriff auf sensible Daten oder fehlende betriebliche Zuständigkeit können echte Voraussetzungen sein. Die Checkliste soll solche Bedingungen sichtbar machen und keinen Anlass bieten, sie zu umgehen.
Ein verantwortungsvolles Setup kann Unbekanntes enthalten. Es braucht einen glaubwürdigen Weg, diese Punkte zu untersuchen und Entscheidungen darüber zu treffen.
Häufig gestellte Fragen
Brauchen kleine Projekte eine Setup-Checkliste?
Ja, aber passen Sie Evidenz und Dokumentation an die Arbeit an. Ein kurzes Briefing und einige ausdrückliche Entscheidungen können genügen. Ziel ist Klarheit, nicht die Nachbildung des Papierkrams eines Großprogramms.
Sollten wir die Detailplanung abschließen, bevor wir ein Projekt-Board einrichten?
Sie können früh ein Board erstellen, sollten aber Untersuchungsaufgaben von Umsetzungszusagen unterscheiden. Das Board sollte Unsicherheit sichtbar machen und nicht den Eindruck vermitteln, jeder Eintrag sei umsetzungsbereit.
Wer ist für die Setup-Checkliste zuständig?
Eine Projektleitung kann sie koordinieren, während die jeweiligen Zuständigen Entscheidungen, Aufgaben und Einschränkungen bestätigen. Eine Person kann Verfügbarkeit oder Befugnisse der anderen nicht verantwortungsvoll bescheinigen, ohne sie zu prüfen.