Web 2.0 mal praktisch (25) – Teamwork ohne Email, endlich das ideale Kollaborations- und Projektmanagement-Tool! asana.com

Nach Tests von unzähligen Projektmanagement- und Kollaborationswerkzeugen ist der Geschäftsmann für seine Person fündig geworden! Asana macht Telezusammenarbeit und Projektabwicklung wirklich einfacher und ist super zu bedienen!

Projektmanagement und Teamkollaboration einfach gemacht - asana.com
Projektmanagement und Teamkollaboration einfach gemacht – asana.com

Der Geschäftsmann ist ein Knowledgeworker, Notebook und Smartphone sind Ihm, was Anderen Kelle und Lot sind. Er hockt ausgesprochen viel am Bildschirm und er arbeitet mit Leuten von nah und auch von fern zusammen. Da liegt es auf der Hand, dass er seine zu verrichtenden Aufgaben auch am Screen organisiert. Und Projekte gehen mit einem Tool besser von der Hand, auch wenn man nie vergessen sollte, die beteiligten Leute auch direkt anzusprechen und nicht nur anszusprechen.

Doch zurück zu den Tools: In der Vergangenheit hat er diverseste PM– oder GTD-Tools ausprobiert und geschrieben: Sein “Evernote für Dummies” ist ein beachteter Post und Evernote ist beim Gmann immer noch hoch im Kurs. In seiner inzwischen über 20-teiligen “Web 2.0 mal Praktisch” – Reihe hat er u. A. über seine Erfahrungen mit Samepage. Auch Trello und Basecamp hat er versucht und einige Kleinprojekte hat er mit dem inzwischen von Salesforce wieder eingestellten Do.com (inzwischen haben die ein ähnliches Werkzeug namens Chatter am Start) abgewickelt.

Ausgezeichnete Integration der Projekttasks in den Gmail-Kalender
Ausgezeichnete Integration der Projekttasks in den Gmail-Kalender

Doch jetzt ist er mit Asana (Wikipedia) ausserordentlich zufrieden. Egal ob Wasserfall-Modell, agile Projekte oder Lean-Startupkampagnen, asana ist für alles geeignet. Das Produkt des Facebook Gründungsmitglieds Dustin Moskovitz und des Entwicklers Justin Rosenstein, wurde wohl ursprünglich zur Produktivitätssteigerung von Projekten bei Facebook entwickelt. Es ist aber so gut, dass es wirklich für alle ToDo- und Projektabwicklungstasks gebraucht werden kann! Der Geschäftsmann ist schlicht und einfach begeistert. Einfache Erfassung der Tasks, gute Möglichkeiten zur Aufbau von Hierarchien und Gruppierung der Aufgaben. Superschöne und effiziente Zuordnung der Tasks an Projektmitarbeiter und eine ausgesprochen effiziente Integration von Social Functions in die Projektarbeit! (z.B können Dritte Ihre Supportbereitschaft zu einem Task kundtun, man kann sich gegenseitig followen und natürlich gibt es auch Likes 😉 Und das UI ist echt der HammerI Teamwork ohne Email eben! Eine gut designte Software erleichtert die Arbeit doch ungemein. Was es nicht ist: Es ist kein Projektrapportierungstool, weder für Arbeitszeiten oder zum Projektcontrolling. Klar gibt es Task-Kontrolle aber für Projektauswertungen ist es nicht gebaut. Und es ist auch kein Projektplanungstool mit Gant- oder Balkendiagrammen und so. Probiert es aus und sagt dem Geschäftsmann, was Ihr davon halten tut!

So Long, Euer Gmann 2.0

PS: Ein Projektmanagement-Tool macht noch lange keinen Projektleiter! Mehr zu Projektmanagement erfahren Sie hier unter der Kategorie Projektmanagement

 

 

 

Wieso Geschäftsmodell Innovation oder -Entwicklung zwingend etwas mit Agilität zu tun hat – Lean Startup, Business Model Generation & Agile

Mehr als nur agil: Das Lean-Modell ergänzt oder ersetzt zukünftig die Wasserfall-Projektmodelle.

Viele organisatorische Problemstellungen oder “Herausforderungen” werden früher oder später in irgendein Softwaresystem gegossen oder zumindest durch Software unterstützt. Und Software, zumindest grössere Lösungen, führt man mit Projekten ein. Weitverbreitet ist dabei das Wasserfall-Prinzip, so wie es der Geschäftsmann 2.0 in Dutzenden Projekten (gegen 50) gemacht hat.

Innovation: Am Anfang ist eine (Geschäfts-) idee oder ein Geschäftsmodell nur ein Satz von Hypothesen. Das Gleiche gilt für das Produkt und die angepeilten Kunden
Innovation: Am Anfang ist eine Idee oder ein Geschäftsmodell nur ein Satz von Hypothesen. Das Gleiche gilt für das Produkt und die Kunden

LEAN: Will man dagegen LAUFEND innovativ sein, oder befindet man sich am (zeitlichen) Anfang einer Organisation (=Startup) oder einer Marktleistung, dann ist die (Software-) Projektabwicklung Gift für die Innovation. Man will anhand des MVP (Minimum Viable Product) schnell Fehler machen! Man will die Fehler messen und schnell Gegensteuer geben, sprich man will schnell Lernen und Erfahrungen machen, z.B auch unter Zuhilfenahme von A/B Tests.

 

 

Maximaler Lerneffekt pro Zyklus Bei der Gmod-Innovation oder in Startupphasen versucht man also besser, möglichst viele kurze Iterationen zu machen. Man hält das Ausmass des Schadens möglichst klein und es wird schnell nachjustiert. Weiter wird so grob wie möglich und so detailliert wie nötig entwickelt, aber die Veränderungen der Kundenreaktion werden so genau wie möglich gemessen! So etwas kann nur “Agile Entwicklung”!

Schlanke, iterative Explorationstechnik der Leistung/ Produkt unter Zuhilfenahme der kundengetriebenen Entwicklung
Schlanke, iterative Explorationstechnik der Leistung/ Produkt
unter Zuhilfenahme der kundengetriebenen Entwicklung

Agile Enwicklung versus Wasserfall-basierte Entwicklung: Eine Definition

Definition Agiles Entwicklung ist ein iteratiives und inkrementelles Entwicklungsmodell zur Erstellung von Produkten (Hardware, Software oder Dienstlleistungen) und bietet die Flexibilität auf Kunden-Feedback zu reagieren. Es wird akzeptiert, dass Kundenbedürfnisse und die endgültige Produktspezifikation vorgängig nicht vollständig definiert werden können. Agil ist die Antithese des Wasserfall-Modells.

Definition Wasserfall Entwicklung ist ein linear und sequentiell aufgebautes Entwicklungsmodell zur Erstellung von Produkten (Hardware, Software oder Dienstleistungen) auf Basis einer Schritt-für-Schritt Methode. Das ganze Produkt und dessen Spezifikationen werden allesamt vorgängig definiert. Jede Phase des Wasserfalls werden/können einem benannten Projektteam zugeordnet werden, um eine bessere Projekt- und Terminkontrolle sicherstellen zu können. Wasserfall ist die Antithese des Agilen Entwicklungsmodells.

Mehr zu Wasserfall, insbesondere Hermes 5 gibt es hier. Und hier kann ein weiterer Beitrag zum Spannungsfeld Wasserfall vs. Agil nachgelesen werden.

Startup: Geschäftsmodell Innovation oder Startups von Organisationen: Agilität und Lernfähigkeit der Organisation stehen im Vordergrund, nicht Termine, Kosten und vermeintliche Qualität (Es könnte Qualität eines falschen Produktes sein)
Geschäftsmodell Innovation oder Startups von Organisationen: Agilität und Lernfähigkeit der Organisation stehen im Vordergrund, nicht Termine, Kosten und vermeintliche Qualität (Es könnte Qualität eines falschen Produktes sein)

———————————–

Agile Development is the engineering method used to develop products (hardware, software or services) iteratively and incrementally with flexibility to react to customer feedback. It recognizes that customer needs and the final product spec cannot be fully defined a priori. Agile is the antithesis of Waterfall Development.

Waterfall Development is the engineering process used to devlop products (hareware, software or services) linearly, sequentially, with a stage-by-stage method. The entire product an all features are spexcified up-front. Each waterfall stage is assigned to a separate team to ensure greater project and deadline control. Waterfall is the antithesis of Agile Development.

(Steve Blank: The Step-by-Step Guide for Building a Great Company)

Noch mehr dazu: Mehr dazu: Das neue theoretische Rüstzeug für den Geschäftsmann / Unternehmer / Führungskraft des 21. Jahrhunderts 

Die Unterschiede von Hermes 5 zu Hermes 2003 – Grobübersicht (Teil 4)

Delta Hermes 2003 zu Hermes 5 – Dieser Artikel eignet sich nur für Hermes Profis. Hier werden die Unterschiede von Hermes 5 zu Hermes 2003 angeschaut. Die Angaben sind ohne Gewähr und repräsentieren lediglich die persönlichen Beobachtungen des Geschäftsmannes 2.0, welcher das Thema im Detail analysiert hat und als Projektleiter mit jahrelanger Hermes-Erfahrung (und Hermes-Zertifikat), die ‘alte’ Version auch noch kennt. Vorneweg: Der Gmann 2.0 meint, Hermes 5 ist gut! Besser als das ‘alte’ Hermes 2003.

  1. Man unterscheidet neu zwischen Stammorganisation und Projektorganisation
  2. Im Projekt soll nun der Betreiber von Anfang an mit dabei sein (Triumvirat Ersteller, Betreiber und Anwender)
  3. Die komplette Ergebnisorientierung der Methodik wurde mit dieser Version endlich geschafft
  4. Es gibt nicht mehr nur Hermes-Systementwicklung und Hermes-Systemadaptation sondern Szenarien: IT-Standardanwendung, IT-Individualanwendung, Dienstleistung/Produkt, Geschäftsorganisation und ein individuelles Szenario.
  5. Ganz wichtig: Szenarien bestehen aus Modulen, Module bestehen aus Aufgaben, Aufgaben beinhalten Ergebnisse.
  6. Es gibt neu auch ein Szenario “IT-Individualanwendung agil” – wobei dieses mit Vorsicht zu geniessen ist (Siehe folgenden Post dieser Blogserie). Man beachte aber trotzdem die Seiten 161ff – Kapitel Agiles PM mit HERMES und SCRUM
  7. Die Phase Voranalyse ist verschwunden
  8. Der Term Tailoring ist verschwunden, dafür gibt es neu die Module und im Speziellen das Kapitel “Planung” (Planungsanleitung S. 154)
  9. Es braucht nicht immer alle Module  (Die mit einem * braucht’s immer)
  10. Der Projektplan und das Projekthandbuch wurden im Projektmanagementplan zusammengefasst
  11. Dem Umstand, dass Projekte in ein Projektportfoliomanagement eingebettet sein können wird neu auch Rechnung getragen (S. 18 / S. 147ff) und hat mehr Gewicht (siehe Grafik)
  12. Es gibt ein neues Lieferobjekt Projekteskalationsprozess
  13. Beschaffung” ist nun auch ein Hermes-Lieferobjekt, Nein, Entschuldigung es ist sogar ein Modul! (Was man nicht sieht, ist ob die Beschaffung produktespezifisch oder produkteneutral durchgeführt werden kann/muss/darf)
  14. Es gibt neu ein Deliverable “Studie” während Initialisierungsphase – Was man früher in der Voranalyse machte, macht man jetzt in der Initialisierung mit der Studie
  15. Somit gibt es auch keinen “Bericht Voranalyse” mehr, das Ergebnis heisst neu “Studie”.
  16. Das Gleiche ist mit dem “Bericht Konzept” passiert, dieses Ergebnis gibt es Hermes 5 nicht mehr. Neu kommt dem wohl – zumindest im Szenario IT-Individualentwicklung – die Aufgabe “Systemkonzept erarbeiten” am nächsten. Die Resultate dieser Aufgabe sind “Situationsanalyse”, “Systemanforderungen”, “Detailstudie” und “Systemarchitektur”
  17. Der Projektauftrag ist jetzt nicht mehr eine Handlung, sondern ein Dokument
  18. Das ehemalige Submodell Projektmarketing ist verschwunden – Neu hat man Stakeholdermanagement und Kommunikation und das gibt dann auch neue Ergebnisse wie z.B eine
  19. Stakeholdermanagement-Liste
  20. Das ehemalige Submodell Riskmanagement ist neu ein Teil der Projekt-Governance (S. 143)
  21. Die Ergebnisse Systemanforderungen und die Systemarchitektur wurden nun zusammengefasst in “Systemkonzept erarbeiten” (Aufgabe)
  22. Die Phasen Initialisierung und Konzept haben die fast die gleichen Prüfkriterien und die gleichen Abbruchkriterien.
    • Prüfkriterien: Bei der Initialisierung prüft man ob man das Projekt starten soll
    • Prüfkriterien: Bei der Konzeptpahse prüfr man, ob man das Projekt realisieren soll
    • Abbruchkriterien: Bei beiden Phasen prüft man ob man abbrechen soll: “Mögliche Gründe für eine Beendigung sind Unwirtschaftlichkeit, zu hohe Risiken, fehelende Realisierbarkeit, fehlende Übereinstimmung mit den Zielen und Strategien der Organisation”
  23. ERST in der Phase Konzept sind die ungefähren Projektkosten bekannt! (s. 19)
  24. Viele neue Module anstelle einige wenige alte Submodelle. Die ehemaligen Submodelle
    • Konfigurationsmanagement
    • Risikomanagement
    • Qualitätssicherung
    • Projektmarketing

    sind nun alles Aufgaben im Modul Projektführung

  25. Wie gesagt sind Projektmarketing und Riskmanagement sind wieder in die Projektführung ‚zurückgewandert’ (S.30 Projektführung), es gibt aber klar die Rolle eines Qualitäts- und Risikomanagers (S. 67)
  26. Die Stammorganisation hat zwei neue Organisationseinheiten zu betreiben:
    • Kompetenzzentrum Projektmanagement, Synonym ist PMO (Projektmanagementoffice)
    • Controlling & Vorgabestellen (z.B eine Governance-Abteilung)
  27. Bei “Entwicklung Agil” führt der Projektleiter das Product Backlog, auch führt er “Protokoll” bei Sprints (Der Geschäftsmann 2.0 ist damit wirklich nicht einverstanden, das ist schlicht und einfach Nonsens. Es gibt keinen PL bei agiler Softwareentwicklung und wenn eine Hermes Rolle das Product Backlog führen müsste, dann wäre es wohl am ehesten die Rolle “Geschäftsprozessverantwortlicher” oder vielleicht noch der “Business Analyst” (Mehr zu “agil” im nächsten Beitrag “Hermes 5 und Agile SW-Entwicklung“).
  28. Konfigurationsmanagement heisst neu “Änderungsmanagement führen” (S. 77)
  29. Die ehemalige Konfigurationsidentifikation und der KM-Plan sind teilweise in das Dokument Änderungsstatusliste eingeflossen
  30. Es gibt eine Reihe neu benannter Konzepte: Produktkonzept, Betriebskonzept, Integrationskonzept, Einführungskonzept, Geschäftsorganisationskonzept, Migrationskonzept, Testkonzept, Systemkonzept
  31. Das Systemkonzept ist ein Merge von Systemarchitektur und Systemanforderungen (welche es aber auch immer noch als eigenständige Deliverables gibt)
  32. Das Referenzhandbuch H5 geht auch (eben schön im Sinne der Ergebnisorientierung) explizit auf Entscheide ein. Es wird beschrieben dass Entscheide zu treffen sind bei:
    • Entscheid zu SCRUM
    • Entscheid zu ISDS-Konzept
    • Entscheid zum Projektabschluss
    • Entscheid zum Zuschlag
    • Entscheid zur Abnahme der Migration
    • Entscheid zur Abnahme
    • Entscheid zur Ausschreibung
    • Entscheid zur Betriebsaufnahme
    • Entscheid zur Projektfreigabe
    • Entscheid zur Variantenwahl
    • Entscheid zur Vorabnahme
  33. Der Projektauftrag (ist neu ein Dokument und kein Vorgang) beinhaltet weite Teile der Kapitelstruktur des ehemaligen Dokuments Voranalyse.
  34. Es gibt auch neu einen Projektinitialisierungsuaftrag
  35. Das Projekthandbuch und der Projektplan sind neu in den Projektmanagementplan eingeflossen
  36. “Neue” Optiken sind ebenfalls in Hermes 5 eingeflossen
    1. Nachhaltigkeit (S. 149)
    2. Finanzielle Steuerung und Führung (S. 153)
    3. Release Management
    4. Vorgehen bei Programmen – Programm Management

 

h5-PTDC0001
Hermes 5 und Projektporfoliomanagment

Hä? Nicht verstanden – Einige Sachen hat der Geschäftsmann 2.0 im neuen Hermes 5 Referenzhandbuch nicht begriffen, nicht verstanden oder er meint diese seien falsch:

  • S. 83 Entscheid zu SCRUM treffen – nicht verstanden
  • S. 113 “Die Einführung von SCRUM hat einen klaren Start und ein klares Ende“. Nicht begriffen – Ja, klar hat SCRUM auch ein klares Ende, aber SCRUM kennt keinen klaren Endtermin, oder?
  • S. 113 bei Sprints durchführen heisst es im Absatz “Hermes Spezifisch”: Die Projektleitung überträgt dem SCRUM-Team die Verantwortung für die Durchführung eines Sprints” – nicht verstanden. Sollte es nicht eher heissen: “Der Product-Owner (den es im Hermes ja so nicht gibt) überträgt dem SCRUM-Team die Verantwortung für die Erstellung des Produkts? –> Man versteht, wieso das bei Hermes 5 so ist, denn ab S. 161 gibt es ein Spezialkapitel zu Hermes und SCRUM und dort sieht man, dass die Autoren es als nicht möglich erachten SCRUM für den ganzen Projektzyklus zu verwenden sondern nur für den Teil, wenn entwickelt wird.

Fazit: Einiges bleibt gleich, vieles ist neu und das meiste ist besser: Hermes 5 ist ein Gewinn!

Beitragsserie Hermes 5:

  1. Einleitung und Anlass
  2. Eine kurze Übersicht für PM-Profis und Hermes-Kenner
  3. Anstelle Tailoring: Szenarien und Module
  4. Die Unterschiede von Hermes 5 zu Hermes 2003 – Grobübersicht
  5. Hermes 5 und agile Softwareentwicklung (SCRUM) – Ein Lösungsansatz
  6. Wie geht es weiter?

Mehr zu Hermes 5: Update 18.3.2014 Aufgrund der regen Nachfrage gibt es nun einen Hermes-Bereich, mit Grundlagen, Erklärungen, Mindmaps, Lernhilfen und sogar mit echten Prüfungsfragen: http://geschaeftsmann20.com/projektmanagement