Der erste Tipp in Bezug auf das Projektmanagement lautet: Verwenden Sie ein Projektmanagement! Ein Tipp, der nahezu überflüssig erscheint, in der Praxis aber oftmals überhaupt nicht umgesetzt wird. Wer braucht denn eigentlich ein Projektmanagement? Jeder! Sobald es ein Projekt umzusetzen gilt, muss man dieses auch entsprechend verwalten. Nur so kann man gewährleisten, dass das Projekt auch halbwegs wie ursprünglich geplant zum Abschluss kommt.

Ist man Freelancer, so kommt man nicht umhin, dies selbst zu erledigen. Man führt die Doppelrolle meist intuitiv aus, ohne sich dessen richtig bewusst zu sein. Dies ist eines der Hauptargumente gegen Freelencer, das von Kundenseite oftmals vorgebracht wird. Technisch arbeiten diese meist einwandfrei, aber bei der Verwaltung gibt es bei einigen früher oder später Probleme.

So fällt auf, dass Freelancer Projekte mitunter nicht zielgenau fertigstellen. Auch die Erreichbarkeit ist oftmals ein Problem. Der Freelancer muss sowohl technisch eine Aufgabe erledigen (Design, Programmierung, Frontend-Entwicklung), als auch dafür Sorge tragen, dem Kunden einen Fortschritt zu präsentieren. Beides zugleich kann er nicht, daher priorisiert er es. Hier entscheidet er sich zunehmend für das, was er am Besten kann – und dies ist sehr wahrscheinlich die technische Seite.

Vielen wird das magische Dreieck [1] bekannt vorkommen. Dieses Konzept stellt die Erwartungen des Kunden (Stakeholder) als Dreieck und damit die Ecken als „Qualität“, „Zeit“ und „Kosten“ dar. Verändert man eine Komponente, so ändern sich die beiden anderen entsprechend. Will der Kunde also eine möglichst schnelle Abarbeitung seines Projekts erreichen, steigen damit die Kosten für das Projekt an oder aber die Qualität sinkt.

Ein erweitertes Schema – das sogenannte SQERT-Modell (Scope, Quality, Effort, Risk, Time) – bezieht zwei weitere Steuergrössen mit ein: Ziel (also die 100-Prozent-Umsetzung der ursprünglichen Idee) und Risiko.

Sehr wichtig ist es nun, sich mit dem Kunden zusammen auf eine Priorisierung dieser Steuergrössen zu einigen. So kann man beispielsweise übereinkommen, dass die Qualität sehr viel wichtiger als der Preis ist oder eben auch umgekehrt. Diese Priorisierung bestimmt dabei das PM erheblich, da davon alle Entscheidungen abhängen werden. Die Standard-Priorisierung in der Agentur des Autors ist beispielsweise (1) Qualität – (2) Ziel – (3) Preis – (4) Zeit – (5) Risiko.

Wie in einer beginnenden Ehe ist man sich irgendwann handelseinig geworden, gibt sich einen Vertrauensvorschuss, umgarnt sich und sagt sich unentwegt, wie gut man es findet, dass man sich gefunden hat. Der Kunde freut sich auf die Agentur und die Agentur oder der Freelancer betont, wie gut ihm das Projekt gefällt. Jeder erzählt dem anderen, dass die Zusammenarbeit perfekt verlaufen wird. Und – vor allem – man will endlich anfangen und loslegen.

Genau an diesem Punkt ist es sehr wichtig, sich – ähnlich einem Ehevertrag – sich möglichst vollständig mit Verträgen abzusichern. Dies fängt beim Angebot und den dort enthaltenen (sowie auch nicht enthaltenen) Punkten an und geht über ein möglichst ausführliches Pflichtenheft hin zu Absicherungen in Extremfällen. Folgende Verträge sollte man dringend formulieren, vorlegen und vom Kunden unterzeichnen lassen:

• AGB
• Vertrag über Arbeiten ausserhalb der Geschäftszeiten
• Angebot
• Pflichtenheft
• Projektplan

Sollte es während der Projektlaufzeit zu Unstimmigkeiten kommen, so hat man immer ein offizielles Dokument zur Hand, das die Unstimmigkeit sachlich regelt. Damit lässt man emotionalen Ausschweifungen nahezu keinen Spielraum und sorgt somit für ein unbelastetes Klima.

Bei einem Angebot sollte man nicht nur möglichst modular auflisten, was im Projekt realisiert werden soll, sondern auch das, was man erst einmal nicht einplant – so sollte (wenn man es nicht ohnehin als Angebotspunkt aufgeführt hat) dabei stehen, dass man gerne optional „Dokumentation“ und „Schulung“ oder dergleichen anbietet. Der Kunde ist nur allzu leicht in Versuchung, am Ende des Projekts zu erwarten, dass die Schulung oder eine Dokumentation doch „logischerweise“ inklusive sein müsste.

Dieser Punkt klingt eventuell überheblich, resultiert aber aus einem ganz logischen Fakt. Der Kunde kennt sich meist in der Projekt- beziehungsweise Agenturwelt nicht aus, sondern lediglich in dem Fachgebiet, für das er nun Unterstützung durch Freelancer und/oder Agenturen benötigt. Somit muss man dem Kunden die eigene Unternehmenskultur nahe bringen. Dies ist eventuell ein längerer iterativer Prozess, wodurch hier der Begriff „Erziehung“ durchaus positiv zu verstehen ist.

Wichtigster und vielleicht schwierigster Punkt ist es, dem Kunden klarzumachen, dass hier eine gegenseitige Zusammenarbeit stattfinden wird. Der Kunde ist weder besser noch schlechter als die Agentur. Man darf und sollte sich weder von großen Namen (wir sind Marktführer in xyz), Versprechungen (der Nachfolgeauftrag wartet schon) oder einem starken Ego des Verhandlungspartners irritieren lassen. Weder ist der Dienstleister auf den Kunden, noch der Kunde auf den Dienstleister angewiesen. Hat man das einmal verinnerlicht, kann man sehr viel entspannter verhandeln.

Anschließend sollte man den Kunden über die eigenen Regeln ausführlich in Kenntnis setzen. Dazu gehören insbesondere Reaktionszeiten oder (sofern vorhanden) SLAs, Arbeiten außerhalb der Geschäftszeiten, Benutzung eines Bugtrackers und ähnliches. Nur so kann man gewährleisten, dass der Kunde von Anfang an weiß, was auf ihn zukommt. Dies ist eine der Grundvoraussetzungen für ein sauberes Projektmanagement, da man die Prozesse von vornherein ordentlich definiert hat.

Im Laufe eines Projekts gilt es, viele Aufgaben zu erledigen. Der Kunde weiß natürlich nicht, welche davon gerade aktuell sind. Irgendwann einmal schaut sich der Kunde das Projekt an, indem er beispielsweise einen Demo-Link zu der gerade zu erstellenden Website anfordert. Dies ist an sich schon eine Gefahr, da der Kunde ja eine halbfertige Arbeit zu sehen bekommt, aber, das außen vor gelassen, legt er seinen Fokus auf irgendeinen Aspekt – beispielsweise die Navigation oder ein Plugin. Nun will er unbedingt weitere Information darüber: „Kann das Plugin auch eine Single-Ansicht?“ oder „Die zweite Überschrift muss drigend 10 Pixel nach unten“ oder ähnliches. Der Projektmanager ist nie so detailliert in den Aufgaben, daher muss er den entsprechenden Techniker befragen, der liefert ihm die Antwort und der Projektmanager kann diese wiederum dem Kunden zurück liefern.

Hier ist bereits zu sehen, dass einfache Rückfragen bereits ein wahres Kommunikations-Ping-Pong auslösen können. Eine direkte Rückfrage beim Entwickler scheint zwar schneller und einfacher zu sein, nimmt allerdings den Projektmanager aus der Informationschleife. Daher ist es dringend nötig, für derlei Anfragen ein automatisches System zu verwenden, auf das der Kunde, der Projektmanager und alle Techniker Zugriff haben – beispielsweise ein Ticketsystem.

Ein Projekt kann man stets in Teilprojekte und diese in elementare Aufgaben zerlegen. Dies sollte man auch dringend so handhaben, schon alleine um die Komplexität zu verringern. Hat man nun kleine, elementare Aufgaben, kann (und sollte) man diese in ein Ticketsystem wie Redmine [2] oder Mantis [3] eingeben. Diese Systeme speichern die einzelnen Tasks mit einer eindeutigen Nummer – dies ist wichtig, da man meist mehrere Projekte zur selben Zeit abarbeitet. Zusätzlich erhält man eine kurze Referenz, auf die man immer wieder verweisen kann – sei es in E-Mails, in einem Kanban-Bord (siehe übernächster Punkt) oder in Projektplänen.

Schließlich – und das ist eventuell sogar das Wichtigste – auch der Kunde kann und soll das System benutzen. Er bekommt neben einem eigenen Zugang auch eine Einweisung und kann fortan sowohl den Status des Projekts verfolgen (und kann sich somit die Nachfragen sparen), er kann beliebig (und zu jeder Zeit) dokumentieren und vor allem kann er beispielsweise von ihm gefundene Bugs dort eintragen. Hier gehen diese im Gegensatz zur E-Mail oder im persönlichen Gespräch nicht verloren, sondern sind archiviert, nachvollziehbar und vor allem dokumentiert.

Kein mittleres oder größeres Projekt arbeitet man exakt so ab, wie ursprünglich geplant. Dies hat überhaupt nichts mit der Planungstiefe zu tun. Selbst wenn man sich am Anfang noch so viel Mühe gibt – immer entstehen während der Projektlaufzeit neue Wünsche (Feature-Requests) auf Kundenseite oder Änderungen, die doch bitte „mal kurz“ eingearbeitet werden sollen.

Wer hier nicht von vornherein aufpasst, läuft in eine verheerende Falle. Während man am Anfang noch gewillt ist, eine kleine Änderung einfach „mal so“ durchzuführen (schließlich hat die Zusammenarbeit eben begonnen und auch die bereits aufgewendeten Stunden sind so minimal) stellt man dann am Ende des Projekts fest, dass man statt der prognostizierten 100 Prozent Aufwand plötzlich 110 Prozent oder mehr auf dem Zeitkonto hat. Dies mag bei kleinen Projekten noch wenig Zusatzaufwand sein – bei größeren werden da schnell mal ein paar Tausend Euro draus.

Nun ist es natürlich auch nicht möglich, Feature-Requests komplett zu „verbieten“ – der Kunde ist König und daher darf er sein Projekt natürlich auch gerne mit neuen Anforderungen anreichern – nur muss er sie auch bezahlen. Dafür empfiehlt es sich, von vornherein darauf einzugehen, wie man ein Feature-Request behandelt.

Die Agentur des Autors hat dafür beispielsweise einen Workflow via Bugtracker eingeführt. Jeder kann dort einen Feature-Request als Ticket anlegen – der Kunde (wenn er sich dessen bewusst ist), der Projektleiter aber auch der zuständige Programmier können dies entweder initial vornehmen oder ein bestehendes Ticket (das von Kunden gerne als „Bug“ deklariert wird, obwohl es ein Feature-Request ist) umwandeln. Ein definiertes Feld nimmt dann den prognostizierten Aufwand auf. Der Kunde hat nun eine vereinbarte Zeit, den Aufwand abzulehnen. Reagiert er nicht, so gilt der Aufwand als genehmigt und man kann den Feature Request ordentlich mit einer Zusatzrechnung abrechnen.

Wenn man sich bei Freelancern und Agenturen umhört, bekommt man bei der Frage nach dem Stundenlohn stets eine bestimmte Zahl genannt – eventuell noch mit Einschränkungen wie „für Design verlange ich 10 Euro mehr“ oder ähnlichen Ergänzungen. Fragt man dann aber nach, wie sich dieser Stundensatz genau zusammensetzt, so kommt meist keine ausreichende Antwort. Dabei ist eine detaillierte Zusammensetzung essenziell für das Projektmanagement [4].

Verlangt man als Freelancer oder Agentur einen zu geringen Stundensatz, hat man ständig Probleme. Man muss seinem Geld hinterherlaufen, muss Aufgaben knapper erledigen, hat weniger Zeit für Qualitätssicherung oder anderes. Liegt der Preis dagegen zu hoch, wird man – wenn man sich nicht mit der Leistung auf eben jenem Niveau bewegt – eventuell zu wenige Aufträge an Land ziehen.

Daher ist es wichtig, alle Parameter mit einzurechnen – dies ist in relativ guter Näherung relativ einfach:

• Bruttolohn der Mitarbeiter (ist man Freelancer, setzt man einen zu erreichenden Lohn ein)
• 16 Prozent Sozialschleppe (Arbeitgeberbelastung – dies gilt natürlich nur für Arbeitgeber)
• Aufwand für Miete, Strom, Internet usw.
• Hardware- und Softwarekosten
• Werbungskosten
• Sonstige Kosten

Nun errechnet man die maximal möglichen Stunden:

• Arbeitstage aller Mitarbeiter (in Bayern in 2011 waren dies beispielsweise 251)
• Abzüglich Urlaube
• Abzüglich potenzieller Krankenstand (ca. fünf Tage je Mitarbeiter)
• Multipliziert mit der Produktivität der Mitarbeiter (hier ist meist von 50-70 Prozent auszugehen)
• Geteilt durch 12 Monate mal 4,33 Wochen/Monat mal 5 Tage /Woche mal 37,5 Stunden/Woche

Dividiert man dann die Kosten durch die Stunden, hat man den mindestens benötigten Stundensatz. Für ein gesundes Wachstum inklusive einer Absicherung sollte man nun mindestens 20 Prozent mehr kalkulieren.

Gerade Freelancer tun sich schwer damit, festzulegen, was eigentlich Projektmanagement als Tätigkeit darstellt.

Die Tätigkeit umfasst dabei durchaus mehr als nur das Schreiben von Projektplänen und deren Überprüfung – zum klassischen Projektmanagement gehört viel mehr:

• Das Lesen, Antworten und Schreiben von E-Mails
• Treffen mit dem Kunden (sei es als Akquise-Meeting oder zur Präsentation der fertigen Arbeit)
• Telefonieren mit dem Kunden, um Änderungen oder Teilaspekte durchzusprechen
• Erstellen von Beschreibungen, Abläufen, Zusammenfassungen
• Überprüfung und Dokumentieren der Arbeitsschritte
• Qualitätssicherung (sofern diese nicht in einen eigenen Prozess ausgelagert ist)
• Dokumentation

Hier sieht man schnell, dass es nicht reicht, einfach ein paar Stunden auf die Rechnung zu verteilen, in der Hoffnung, dass sich dies nivelliert – hier muss man dringend mit einem eigenen Posten „Projektmanagement“ auf der Rechnung entgegen wirken. Bei kleineren Auftraggebern ist hier eventuell mehr Aufklärungsaufwand von Nöten. Bei größeren gilt es bereits als unprofessionell, wenn dieser Aufwand nicht oder nicht genügend berücksichtigt wurde – sichert er doch die ordentliche und professionelle Abarbeitung des Projekts. Aus der Erfahrung des Autors ist hier von mindestens 15 bis 20 Prozent der kompletten Auftragssumme auszugehen.

Irgendwann ist das Projekt beendet und man freut sich über das Ergebnis oder ist einfach nur froh, dass man es zu Ende gebracht hat. Manchmal wird dann mit dem Kunden gefeiert und man widmet sich dem nächsten Projekt. Doch genau hier sollte man dringend innehalten und das Projekt nochmal in Ruhe zusammen mit dem Kunden Revue passieren lassen. Nur hier hat man die Chance, über seine eigenen Fehler zu reflektieren und diese für das nächste Projekt oder den nächsten Kunden aufzuarbeiten. Fehler im Projektmanagement werden nur hier wirklich deutlich und lassen sich entsprechend ändern. Denn man darf jeden Fehler machen – aber eben nur einmal.