Project Management ist OpenTechnologyApps integriertes Template für die Form, in der die meisten Teams tatsächlich arbeiten: Externe Anfragen kommen irgendwo herein, jemand entscheidet, was es wert ist, gemacht zu werden, und erst dann wird daraus nachverfolgte Lieferarbeit. Das Template hält diese beiden Dinge in wirklich getrennten Queues, nicht nur in getrennten Ansichten derselben Liste.
Was verfolgt wird
| Queue | Was dort liegt |
|---|---|
| Request Intake | Das öffentliche Portal landet hier — keine Anmeldung für den Anfragenden nötig. Jede Anfrage wird trianiert und freigegeben, bevor sie zu echter Arbeit wird. |
| Initiatives & Epics | Die kanonische Elternebene — jedes Epic lebt genau einmal hier |
| Product Backlog | Freigegebene Arbeit, noch nicht für einen Sprint committed |
| Active Sprint | Committete Arbeit in Bearbeitung |
| Risks & Milestones | Getrennt von der Lieferarbeit verfolgt, damit ein Risiko nicht in einem Sprint-Board untergeht |
| Weekly Reports | Ein Zusammenfassungselement pro Zyklus |
Das Portal ist das eigentliche Unterscheidungsmerkmal
Aktivieren Sie das Portal für Request Intake, und externe Stakeholder — Kunden, andere Teams, jeder ohne Konto — bekommen ein sauberes Einreichungsformular. Was sie einreichen, landet in Intake, durchläuft Triage Status (New → In Triage → Approved/Rejected/Duplicate) und ein Decision-Feld, und erst eine freigegebene Anfrage wird zu echter Backlog-Arbeit. Eine abgelehnte oder doppelte Anfrage bleibt als geschlossener Datensatz sichtbar, statt gelöscht zu werden — die Intake-Spur bleibt erhalten, nicht gelöscht.
Diese strukturelle Trennung ist der Punkt: Nichts extern Eingereichtes kann direkt in einen aktiven Sprint springen. Es muss zuerst die Triage durchlaufen, wie alles andere auch.
Zehn Automatisierungen, alle zustandsverändernd
Keine reinen Kommentar-Automatisierungen hier — jede der zehn bewegt tatsächlich etwas:
- Eine als Compliance markierte Anfrage springt automatisch auf dringend
- Eine freigegebene Triage-Entscheidung schaltet das Element auf in Bearbeitung
- Eine abgelehnte oder doppelte Anfrage schließt sich selbst
- Committete Arbeit wechselt auf in Bearbeitung
- Ein blockiertes Element springt auf hohe Priorität
- Kritischer Schweregrad erzwingt dringende Priorität
- Ein Health-Feld auf Rot erzwingt dringende Priorität
- Überfällige Arbeit wird eskaliert
- Ein Element ohne Update seit 7 Tagen wird zur Überprüfung markiert
Zwei Dashboards, und eine Sache, die sie bewusst nicht behaupten
Portfolio & Sprint deckt die Lieferseite ab: ein Epic → Work-Item-Hierarchiebaum, Health-nach-strategischer-Ausrichtung-Aufschlüsselungen, ein Fälligkeitsdatum-Kalender und ein Diagramm der im Zeitverlauf erstellten Elemente. Intake & Backlog deckt die Triage-Seite ab: Anfragen nach Triage-Status, nach Kategorie, nach Typ.
Bei einem Widget lohnt sich Präzision: Das Diagramm „Items Created Over Time" ist genau das — eine Erstellungsrate, keine Sprint-Velocity. Echte Velocity braucht abgeschlossene Story Points, gemessen gegen die tatsächlichen Termine eines abgeschlossenen Sprints, und dieses Template hat noch keine Sprint-Entitäten mit Start-/Enddatum — Sprint ist hier ein Kategoriefeld (Current Sprint / Next Sprint / Backlog), kein vollständiger Sprint-Datensatz. Das Dashboard behauptet keine Zahl, die es nicht belegen kann.
Dieselbe Ehrlichkeit gilt für die Hierarchie: Initiative existiert als Elementtyp, aber die tatsächlich funktionierende Eltern-Kind-Verknüpfung heute ist zweistufig — Epic → Work Item. Eine echte dreistufige Initiative → Epic → Work-Item-Hierarchie ist noch nicht in den Seeder eingebaut.
Noch keine Playbooks
Anders als IT Device Audits fünf kommt Project Management heute noch ohne Playbooks. Die Queue- und Feldstruktur steht für ein Triage-Runbook oder eine Sprint-Planungs-Checkliste bereit — eines zu bauen liegt vorerst bei Ihnen.
So bekommen Sie es
Neues Projekt → Project Management aus der Template-Auswahl auf opentechnologyapp.com. Sechs Queues, vierzehn Elementtypen, zehn Automatisierungen und zwei Dashboards — aktivieren Sie das Portal bei Request Intake, sobald Sie bereit sind, dass externe Anfragen irgendwo Reales landen.