Ein Sondermaschinenbauer mit 90 Mitarbeitern führt 15 Projekte gleichzeitig. Werkzeuge: eine Excel-Datei pro Projekt, ein gemeinsames Laufwerk, E-Mail und der Flur. Es funktioniert – bis es nicht mehr funktioniert. Und der Moment, in dem es nicht mehr funktioniert, ist selten das Projekt selbst. Es ist der Punkt, an dem drei Projekte gleichzeitig dieselbe Person brauchen und niemand die drei Excel-Dateien nebeneinander gelegt hat.
Standish (CHAOS 2020) zählt nur 31 % aller Projekte als erfolgreich. Bei Unternehmen ohne strukturiertes Projektsystem liegt die Quote niedriger, und der Grund dafür liegt oft vor dem eigentlichen Projektstart: in der Art, wie Information organisiert ist.
Wie sieht Projektmanagement der Zuruf konkret aus?
Die meisten technischen Unternehmen unter 200 Mitarbeitern arbeiten so. Nicht aus Nachlässigkeit, sondern weil es bis zu einer bestimmten Größe funktioniert hat. Die typischen Merkmale:
- Der Projektplan ist eine Excel-Tabelle. Zeilen sind Vorgänge, Spalten sind Wochen, Zellen sind farbig. Abhängigkeiten stehen nicht drin. Wenn sich etwas verschiebt, verschiebt jemand die Farben.
- Status wird per E-Mail abgefragt. „Kurze Frage: Wie weit seid ihr mit der Steuerung?" Die Antwort kommt am nächsten Tag, geht an vier Personen, wird von zweien gelesen.
- Entscheidungen werden im Flur getroffen. Der Konstruktionsleiter und der Projektleiter einigen sich zwischen Kaffeemaschine und Büro auf eine Änderung. Protokoll: keines. Der Einkauf erfährt es zwei Wochen später.
- Ressourcen werden zugerufen. „Kannst du nächste Woche bei Projekt B helfen?" – „Wenn A bis Freitag fertig ist." A wird nicht fertig. B wartet.
- Wissen liegt bei Personen. Der Projektleiter weiß, was der Kunde wirklich will. Der Konstrukteur weiß, warum Modul 3 so gebaut ist. Fällt einer von beiden aus, steht das Projekt.
Betroffen sind Geschäftsführer und technische Leiter in wachsenden Unternehmen, die merken, dass die Zahl der Projekte schneller wächst als die Fähigkeit, sie zu überblicken. Die Konsequenz zeigt sich meist nicht in einem spektakulären Scheitern, sondern in einer wachsenden Zahl von Projekten, die „irgendwie zu spät" und „irgendwie zu teuer" werden.
Welche Zahlen zeigen, wo die Grenze liegt?
PMI (Pulse of the Profession 2020) berichtet, dass Organisationen, die Projektmanagement nicht als strategische Kompetenz behandeln, 67 % mehr Projekte komplett scheitern sehen. „Strategische Kompetenz" meint hier nicht Zertifikate, sondern Struktur: gemeinsame Daten, definierte Prozesse, projektübergreifende Sicht.
Standish (CHAOS 2020) zeigt: Kleine Projekte haben eine Erfolgsquote von rund 90 %, große unter 10 %. Was in Excel funktioniert, funktioniert bei kleinen Projekten. Die Grenze liegt nicht bei der Projektgröße allein, sondern bei der Anzahl gleichzeitiger Projekte, die um dieselben Ressourcen konkurrieren.
Formstack (2018) fand, dass 54 % der Manager schlechte Kommunikation und wiederholte Fehler als größtes Effizienzproblem nennen – beides direkte Folgen von Information, die per E-Mail und Zuruf fließt.
Warum scheitern Projekte vor dem Start?
„Vor dem Start" heißt: Der Fehler ist eingebaut, bevor die erste Konstruktionsstunde gebucht wird. Vier Mechanismen:
1. Es gibt keine Kapazitätsprüfung
Der Auftrag kommt, der Termin steht im Vertrag. Ob die Konstruktion in den geplanten Wochen frei ist, weiß niemand – weil die Auslastung nirgends steht. Das Projekt startet mit einer Kapazitätsannahme, die auf Hoffnung beruht. Der erste Konflikt kommt in Woche 4 und ist damit kein Zufall, sondern eine Folge der fehlenden Prüfung.
2. Es gibt keinen belastbaren Plan
Die Excel-Tabelle hat keine Abhängigkeiten. Wenn die Elektrik auf die Mechanik wartet, steht das nicht in der Datei, sondern im Kopf des Projektleiters. Verschiebt sich die Mechanik, verschiebt sich in der Tabelle nichts – bis jemand daran denkt. Der Plan ist von Anfang an eine Absichtserklärung, keine Prognose.
3. Es gibt keine gemeinsame Wahrheit
Der Vertrieb hat dem Kunden Version A der Spezifikation zugesagt. Das Engineering arbeitet mit Version B, weil es eine E-Mail mit Änderungen gab, die der Vertrieb nicht gesehen hat. Beide sind sicher, richtig zu liegen. Der Konflikt fällt bei der Abnahme auf.
Solange Information in E-Mail-Ketten lebt, gibt es keine Stelle, an der „der aktuelle Stand" verbindlich definiert ist. Jeder hat seinen eigenen.
4. Es gibt keine Übersicht über das Ganze
15 Excel-Dateien sind 15 Sichten auf 15 Projekte. Keine davon zeigt, dass Projekt 3, 7 und 11 in KW 40 alle die Montagehalle brauchen. Diese Information existiert erst, wenn jemand die Dateien manuell zusammenführt – und das passiert nicht wöchentlich, weil es einen halben Tag kostet.
Der Portfolio-Blick fehlt nicht, weil niemand ihn will. Er fehlt, weil er mit diesen Werkzeugen nicht bezahlbar ist.
Was ist der grundsätzliche Weg heraus?
Der Wechsel von Zuruf zu System ist keine Frage der Werkzeugauswahl, sondern der Reihenfolge. Wer mit einem Tool beginnt, ohne die Struktur zu klären, bekommt das Chaos digital. Vier Schritte:
- Eine Projektliste mit einheitlichen Feldern. Bevor irgendein Plan detailliert wird: Welche Projekte gibt es, wer leitet sie, welche Termine sind vertraglich, welche Ressourcen brauchen sie grob? Das ist eine Tabelle mit 15 Zeilen – aber eine gemeinsame, nicht 15 eigene.
- Kapazität als Datenbestand. Wer ist für Projektarbeit verfügbar, mit wie vielen Stunden pro Woche, mit welchen Skills? Das ist die Basis für die Frage: „Können wir den Auftrag annehmen?" Ohne diese Basis ist jede Annahme ein Blindflug.
- Pläne mit Abhängigkeiten. Jeder Vorgang hat Vorgänger. Verschiebt sich einer, verschieben sich die Nachfolger. Das klingt banal, ist aber der Unterschied zwischen einer Tabelle und einem Plan.
- Eine Quelle für den aktuellen Stand. Änderungen werden an einem Ort erfasst, nicht per E-Mail verteilt. Wer den Stand wissen will, schaut nach – statt zu fragen.
Diese vier Schritte lassen sich mit unterschiedlichen Werkzeugen umsetzen. Entscheidend ist, dass sie in dieser Reihenfolge angegangen werden. Ein Werkzeug ohne Kapazitätsdaten und ohne Abhängigkeiten ist eine teurere Excel-Tabelle.
Praxisbeispiel: Vom Zuruf zum System in 90 Tagen
Ein Hersteller von Fördertechnik mit 110 Mitarbeitern führte 18 Projekte mit Auftragswerten zwischen 150.000 € und 1,2 Mio. €. Werkzeuge: Excel, E-Mail, wöchentliches Projektleitermeeting.
Auslöser für den Wechsel: Im Herbst kollidierten vier Projekte in der Inbetriebnahme. Zwei Inbetriebnehmer, vier Kunden, drei davon mit Vertragsstrafe. Ergebnis: 76.000 € Vertragsstrafen, zwei Wochen Fremdpersonal für 28.000 €, ein Kunde verloren.
Die Analyse zeigte: Alle vier Termine standen seit Monaten in vier Excel-Dateien. Niemand hatte sie übereinandergelegt. Der Konflikt war seit Mai sichtbar – für jeden, der die Dateien nebeneinander geöffnet hätte. Das hatte niemand getan.
Der Wechsel in drei Phasen:
| Phase | Zeitraum | Maßnahme | Ergebnis |
|---|---|---|---|
| 1 | Woche 1–3 | Gemeinsame Projektliste mit 18 Projekten, vertraglichen Terminen, Projektleitern, groben Ressourcenbedarfen | Erstmals eine Sicht auf alle Projekte |
| 2 | Woche 4–8 | Kapazitätserfassung für 34 Projektmitarbeiter: Verfügbarkeit, Grundlast, Skills | Drei weitere Konflikte für Q1 sichtbar, alle lösbar |
| 3 | Woche 9–13 | Pläne mit Abhängigkeiten für die 8 größten Projekte, eine gemeinsame Änderungsliste | Statusmeeting von 2 h auf 45 min, weil Daten vorher sichtbar sind |
Nach zwölf Monaten: keine Inbetriebnahme-Kollision, Vertragsstrafen null, zwei Aufträge abgelehnt – bewusst, weil die Kapazitätsprüfung ergab, dass sie nicht termingerecht lieferbar gewesen wären. Beide Ablehnungen wären vorher Zusagen gewesen.
Fazit
Technische Projekte scheitern per Excel und Zuruf nicht an der Ausführung, sondern an der Ausgangslage: Sie starten ohne Kapazitätsprüfung, ohne Abhängigkeiten, ohne gemeinsame Wahrheit und ohne Portfolio-Blick. Der Wechsel zu einem System ist kein Werkzeugwechsel, sondern ein Strukturwechsel – und er beginnt mit der Frage, welche Projekte es überhaupt gibt und wer sie mit welcher Kapazität umsetzt.
---
*Mehr zu modernem Projektmanagement in technisch komplexen Projekten: Aligia*