Hallo Herr Tremel, hallo Herr Hess, hallo Herr Brand, das Thema ist leider nur sehr schwer in einer kurzen Form zu diskutieren. Das Video, das Herr Brand angegeben hat, habe ich mir angesehen. Manchem stimme ich zu, manchem nicht. Einige der dort aufgeführten Argumente treffen generell zu auf jede Softwareauswahl und Einführung, nicht nur auf PM Software. Beim Argument "Versuche möglichst viele Schnittstellen abzulösen, wenn die Einführung eines PM Werkzeugs ein Misserfolg werden soll", vertrete ich die gegenteilige Sicht. Hintergrund ist der, dass ich selbst zu oft Situationen erlebt habe, in denen Projektmitarbeiter ihre Arbeitszeiten aus HR Sicht (bei Tarifmitarbeitern) in einem Zeiterfassungssystem wie z.B. SAP (Modul CATS) erfassen müssen, dann zusätzlich ihre Projektaufwände in einer ganz anderen Software für die Abteilung Finanzen erfassen müssen, damit die Aufwände dort kapitalisiert werden können, und dann kommt der Projektleiter auch noch und bittet die Teammitglieder jetzt noch zusätzlich die wirklichen Aufwände pro Vorgang in einem dritten Tool zu erfassen, weil die Art der Erfassung in den beiden vorgenannten Systemen entweder zu grob für seine Zwecke ist (Summe Ist-Tarifarbeitszeit pro Tag) war oder nicht vollständig bzw. aufgrund von Kapitalisierungsvorgaben und einer anderen Strukturierung nicht ganz korrekt ist (Erfassung der kapitalisierbaren Aufwände im zweiten Tool), und er mit der dritten Erfassung nun für seine Zwecke ein gute Projektaufwandscontrolling durchführen möchte. Spätestens dann rennt das Team aus sehr verständlichen Gründen Amok und verweigert das Anliegen des PM´s, der feststellen muss, dass er die schwächste Position von allen Stakeholdern vertritt. Die Folge davon ist, dass in der Praxis keine reale Aufwandsrückmeldung pro Vorgang erfolgt und ein wirklich aussagefähiges Aufwandscontrolling in der Realität nicht mehr möglich ist. Statt dessen wird maximal noch ein Budgettracking durchgeführt. Auf die Frage, warum das Budget überzogen werden muss, kann dann aber nicht mehr wirklich mit belastbaren Analysen geantwortet werden. Das ist dann schon der Moment, in dem ich mir wünsche, dass es ein einziges integriertes System gibt, in dem Projektmitarbeiter die Aufwände ein einziges Mal erfassen müssen (pro Vorgang), aber durch Schnittstellen sichergestellt wird, dass HR die tatsächlichen Arbeitszeiten als Summe pro Tag automatisch gemeldet bekommt, die Abteilung Finanzen vorgangsbezogen die kapitalisierbaren Aufwände pro Projektvorgang und der Projektleiter die tatsächlichen Aufwände pro Vorgang ermitteln kann, ohne dass die Mitarbeiter pro Tag mindestens 15 - 20 Minuten mit redundanten administrativen Tätigkeiten belästigt werden. Das summiert sich ganz schnell hoch und sorgt für Diskussionen und große Frustration bei allen Projektteammitgliedern einschließlich des PM. Von diesem speziellen Aspekt mal abgesehen hängt die Frage, ob eine einfache Client basierte Lösung wie Open Project oder MS Project o.ä. ausreicht oder doch eine Multiprojektfähige und serverbasierte PM Software eingesetzt wird sehr stark davon ab, wie viele Projekte in einem Bereich laufen, wie stark die Projektmanagementkultur ist und vor allem die PM Prozesse ausgeprägt sind, wie und wo die projektbezogene Ressourcenplanung für Projekte stattfindet (in den Linieneinheiten oder in einem PMO) und von dem notwendigen Berichtswesen, ebenso von der Anzahl, der Größe und der Komplexität der Projekte. Das Thema Gruppen- abteilungs-, ggf. sogar bereichsübergreifender Ressourcenplanung zum Staffing von Projekten ist übrigens auch ein ganz "spannendes" i.S.v. herausforderndes Thema und sehr relevant auch für die PM´s. Nach meiner - eher unschönen - Erfahrung mit einer bereichs- und das gesamte Portfolio abdeckenden Ressourcenplanung in Excel bin ich heute durchaus ein großer Fan von entsprechend leistungsfähiger Software, die hier das Leben für alle Stakeholder sehr viel leichter macht. Aber ja, so etwas kostet viel Zeit und viel Geld für die Einführung, lohnt sich aber meiner Meinung nach. Es gibt eben keine pauschale Antwort auf die Frage, ob und welche Software man braucht und ganz so einfach ist es nicht, dass "Weniger immer mehr ist". Es ist und bleibt eine sehr unternehmensindividuelle Entscheidung, die man schon sorgfältig treffen sollte und die sich mit dem Wachstum, der Veränderung und Weiterentwicklung von Unternehmen im Zeitablauf auch immer wieder ändern wird. Kaum jemand nimmt das erforderliche Geld in die Hand, um eine angemessene(!) PM Lösung zu identifizieren und einzuführen, um den Interessen der verschiedenen Stakeholder gerecht zu werden. Zu diesen Stakeholdern gehören eben nicht nur der PM, sondern auch HR, Finanzen, Controlling und auch die betroffenen Projektmitarbeiter. Ja, die Gefahr genau in die Situation hineinzulaufen, die Herr Brand beschreibt, sehe ich natürlich bei diesem Unterfangen und streite sie auch nicht ab. Aber das gilt generell für alle umfassenderen und integrierten IT Systeme (Bsp.: ERP Systeme) und nicht nur für die Gattung der PM Werkzeuge. Soll man deswegen von einer Lösung absehen, die tatsächlich so umfangreich ist, dass sie möglichst die Interessen mehrerer Stakeholder abdeckt? Ich denke, nein, verweise aber einschränkend nochmals auf den oben genannten Punkt, dass es auch sehr stark davon abhängt, wie projektgetrieben eine Organisation ist (Anzahl, Umfang, Komplexität der Projekte). Das "Weniger ist manchmal mehr" gilt sicher in Unternehmen, bei denen es eine sehr überschaubare Anzahl von kleinen bis mittleren Projekten gibt. Da kann man relativ hemdsärmelig und relativ gut mit einer Kombination von Excel, Access und PowerPoint und ggf. zusätzlich ein wenig MS Projekt oder Open Project und einem Kanban Board wie Trello, Asana, Microsoft Planner und ähnlichen Produkten arbeiten. Alle anderen sollten sich durchaus Gedanken machen, ob es nicht doch den Aufwand lohnt eine möglichst gute und umfassende Lösung einzuführen, trotz aller drohenden Risiken und Stolpersteinen. Aber das gilt doch generell für alle Softwareeinführungsprojekte und ein guter PM sollte in der Lage sein, diese Klippen genauso erfolgreich zu umschiffen, wie er das hoffentlich in Softwareeinführungsprojekten kann, die überhaupt nichts mit PM Werkzeugen und Prozessen zu tun haben. ;-)