Wenn das Verhältnis zwischen technischem und planerischem Personal nicht mehr stimmt, fangen die Grabenkämpfe um die Ressourcen in einer Unternehmung an. Deswegen sollte die Zahl der Projektmanager tiefer sein als die der Ingenieure.

Von Dorian Selz, Nektoon

Die meisten kleinen und mittleren Unternehmungen sind voll von Leuten mit dem Titel “Project Manager”. Gleich vorweg: Dabei handelt es sich wahrscheinlich um den grundlegendsten Job in jeder Unternehmung. Wenn Ihre Techies nichts drauf haben, haben Sie jedenfalls fehlerhaften Code, aber Beharrlichkeit wird eine Lösung bringen. Wenn Ihre Marketingleute nichts können, haben Sie sicherlich Schwierigkeiten, Ihre Botschaft an die Menschheit zu bringen, aber mit etwas externer Hilfe wird’s schliesslich klappen. Wenn das Management nichts taugt, wird der Verwaltungsrat das Problem hoffentlich schnell lösen.

Aber wenn eine Projekt-Managerin versagt, hast Du ein echtes Problem. Warum? Sie ist diejenige, welche die Fäden eines Projekts in den Händen hält. Wenn sie gut ist, “passieren” die Dinge – oder eben Projekte – einfach so. Wenn sie die Fäden nicht zusammenhält, wird das Projekt scheitern.

Dennoch haben zu viele Firmen zu viele Projektmanager, die zu viele unnütze Dinge managen. Diesen Report, jenen Chart, viele Meetings, noch mehr E-Mail. Ihr Beitrag zum ganzen? Nichts, oder schlimmer: Negativ.

Das liegt daran, dass die meisten Unternehmen von Geschäftsleuten geführt werden und nicht von Ingenieuren. Beide Gruppen tendieren dazu, sich mit ihresgleichen abzugeben. Es ist ganz einfach leichter, eine gemeinsame Sprache zu finden. Also stellen Geschäftsleute weitere Geschäftsleute an, zum Beispiel Projekt-Manager. Und weil die meisten Organisationen immer einen Haufen zu erledigen haben, nicht zuletzt, um die Egos einiger Leute an der Spitze zu befriedigen, werden haufenweise Projektmanager angeheuert.

Das Resultat ist ein Überfluss an Projektmanagern. Gleichzeitig bleibt die Zahl der Ingenieure meistens die gleiche (Sie wissen schon: Fokus auf Kosten und Headcount und all sowas…)

In einer Marktwirtschaft gibt es zwei Lösungen für dieses Problem: Entweder der Preis oder die Nachfrage wird sich anpassen, bis der Markt sich bereinigt.

Unglücklicherweise reden wir nicht vom freien Markt, sondern von einer geschlossenen Firma. Was also wird passieren?

Jeder Projektmanager hat eine bestimmte Anzahl Zielvorgaben. Aber die Ingenieur-Ressourcen sind zu deren Erreichung zu gering. In der Folge setzt eine heftiger politischer Wettbewerb im Kampf um die knappen Ressourcen ein. Die Mitarbeiter fangen an, sich auf den internen Wettstreit zu konzentrieren, statt sich um die Kunden zu kümmern.

Diese Situation wollten wir bei local.ch vermeiden. Wir haben grundsätzlich keine Projektmanager angeheuert. Wie also kamen wir über die Runden?

• In einem 32köpfigen Team mit 22 Ingenieuren hatten wir zwei technische Direktoren. Ihre Aufgabe war es, reibungslose technische Abläufe zu garantieren. Auf der einen Seite waren sie die primären Ansprechpartner für die Businessleute mit deren Anliegen. Zweitens haben sie sich um die technische Ausrichtung insgesamt gekümmert.
• Wie im letzten Beitrag beschrieben, haben wir local.ch in mehrere Bausteine aufgeteilt und jedem ein Team und eine Teamführung zugeordnet (wir hatten ein Frontend-, ein Backend- , ein Inserate-, ein Guide-, ein Karten- und ein Mobile-Team, wobei einige Mitarbeiter in mehreren Teams waren.)
• Jedes Team war selber zuständig für seine Vorgaben, Ziele und die passende und zeitgerechte Umsetzung. Jedes Team würde so ausgerichtet, dass es nicht zu Überschneidungen und Wettbewerb mit einem andren Team kam.
• Wir haben uns jeden Donnerstag getroffen um die übergeordneten strategischen Ziele zu definieren und die unmittelbaren Verbesserungen des nächsten Release abzustimmen. Wir haben mit einem generellen Überblick angefangen und mit einem Abstimmungstreffen aller Teamleader weiter gemacht, an welchem teilnehmen konnte, wer immer ein Problem in die Runde werfen wollte. Wenn der Grundsatzplan festgelegt war, delegierten wir die Teilaufgaben an die Teams. Wir haben uns sehr bemüht, diese Sitzungen auf die prioritären Fragen zu beschränken, indem alle Folgeaufgaben und – Probleme an die zuständigen Gruppen weitergereicht wurden. “Sehr bemüht” heisst: Manchmal ist es uns nicht gelungen. Aber wo ist das schon nicht so?
• Wir haben auf flexible Entwicklungsmethoden gesetzt. Mehr dazu in einem nächsten Artikel.

Das Resultat – mit allen Nachteilen – waren sehr konzentrierte Teams. Sie haben Verantwortung übernommen und eigene Themen angepackt. Sie waren stolz darauf, alles schnell und effizient und ohne Aufsicht zu erledigen. Dinge wurden einfach erledigt. Und das geschah sehr bald: Am Frontend hatten wir fast tägliche neue Releases, im Backend waren sie dicht dran.

Wahre Verantwortung ist ein hervorragender Motivator.

Das Grundrezept besteht aus einer transparenten Aufteilung in Bausteine und klar zugeordnete Verantwortung. Plus ein Maximum an Delegation von Entscheidungsgewalt aufgrund einiger einfacher und allgemeingültiger Regeln.

Und dann heisst es: Einen Schritt zurück treten und exzellente Leute ihre Arbeit erledigen lassen.

Das englischsprachige Original dieses Artikels steht im Blog von Nektoon.

• Bauanleitung für Startups: Der Kunde ist König (8. Mai 2009)
• Bauanleitung für Startups: Die Summe der Teile (18. Mai 2009)
• Bauanleitung für Startups: Projektmanager-Inflation (3. Juni 2009)
• Bauanleitung für Startups: Projektmanagement mit Scrum (22. Juni 2009)
• Bauanleitung für Startups: Wiki statt Office (10. Juli 2009)
• Bauanleitung für Startups: Prozesse und Kontrolle mit Jira (24. Juli 2009)
• Bauanleitung für ein Startup: Share Nothing Architecture (11. August 2009)
• Bauanleitung für Startups: Automation – Keiner da… (19. August 2009)
• Bauanleitung für Startups: Virtualisierung – wirklich keiner da… (8. September 2009)
• Bauanleitung für Startups: Irren ist menschlich, Testing nötig (7. Oktober 2009)
• Bauanleitung für Startups: Eine Nation von Netzwerken (15. Oktober 2009)