Archiv der Kategorie ‘Projektmanagement‘

 
 

Security im agilen Kontext

Diese Tage kam ich in der Diskussion mit einem Kunden auf die Berücksichtigung von Security Requirements in einem agilen Kontext.

Hintergrund war, dass bislang Security vor allem für den Betrieb und für die Produktsicherheit thematisiert wird, aber Sicherheitsaspekte in der Entwicklung und in einer Projektphase noch eher stiefmütterlich behandelt werden. Auf der anderen Seite finden agile Vorgehensweisen immer weiter Einzug in die Unternehmen und die Ausgangsfrage des Kunden war, wie man Sicherheitsbelange im agilen Kontext berücksichtigen kann.

Für die Projektsicht gibt es vor allem zwei Themenstränge (und dabei müssen wir noch nicht mal zwischen agil und klassisch unterscheiden):

  • Die Sicherheit im Projekt
  • Die Entwicklung der Sicherheit für Produkt und Betrieb

Bei letzterem Punkt könnte ich mir unterschiedliche Strategien vorstellen:

  • Ein stufenweiser Hochlauf, bei dem systematisch das Sicherheitsniveau angehoben wird. (Anfangs mit einer Sandbox, dann Aufbau einer Entwicklungsumgebung, erst noch ohne Daten, dann nur mit einem Teilset der Daten, bis hin zur vollumfänglichen Produktion)
  • Vorgabe von Leitplanken (im Qualitätsmanagement gibt es dafür das Control Chart als Werkzeug).

Grundsätzlich würde ich Security-Anforderungen im Normalfall den nicht-funktionalen Anforderungen zuordnen.

Agile SW-Entwicklung fokussiert tendenziell auf funktionalen Anforderungen. Werden dabei wichtige nicht-funktionale Anforderungen vergessen, so kann dies eine Schwäche agilen Vorgehens sein.

Im Wesentlichen finden sich drei Ansätze zur Berücksichtigung von Security Requirements im agilen Kontext:

  • Eigene nicht-funktionale Einträge ins Backlog (beispielsweise eigene User Stories. Ein Kollege hat mir berichtete mir, dass er ein eigenes Backlog für Security Anforderungen aufgebaut hat.)
  • Berücksichtigung nicht-funktionaler Anforderungen als Constraints
  • Berücksichtigung als Kriterien im Definition of Done

Wenn die Vorgaben für Security oder nicht-funktionale Anforderungen allerdings zu sehr formalisiert werden, dann birgt das bereits einen kulturellen Konflikt: Ein formaler Prozess entspricht jetzt nicht ganz den agilen Vorstellungen von eigenverantwortlichem Handeln, d.h. auch da bräuchte es klar definierten Handlungsspielraum für das Team.

Maturity Ansätze fand ich zur Berücksichtigung von Security Anforderungen nicht hilfreich. Da finden sich  CMMI-Adaptionen auf agile Vorgehensweisen. Thematisiert wird aber das Vorgehensmodell an sich und nicht die Berücksichtigung nicht-funktionaler oder sicherheitsrelevanter Anforderungen.

Beitrag #723 auf schlossBlog

Neue Projektmanagement-Trainings

Mittlerweile sind die ersten 5 Trainings unseres Projektmanagement-Kurses online, ein weiters ist in der Post-Produktion und die Dreharbeiten für die nächsten Trainings stehen vor der Tür.

Die Video-Trainings sind sowohl bei video2brain als auch bei LinekdIn-Learning (kostenlos für LinkedIn-Premium-Abonnenten) verfügbar. Einzelne Demo-Filme aus dem Training kann man sich auch ohne Anmeldung ansehen (bei video2brain). Wer also neugierig geworden ist…

Die Entwicklung und Erstellung war sehr intensiv, hat aber auch wirklich Spaß gemacht.

Mit Christian, meinem Trainerpartner von visualbraindump, kann man Pferde stehlen, Thomas ist ein alter Hase was Lektorat und redaktionelle Betreuung angeht und bei der Grazer Crew von video2brain ist man in den allerbesten Händen.

Da kommt noch mehr – und ich freu mich darauf!

#Beitrag 722 auf schlossBlog

Agile Coaches in Großunternehmen

Diese Tage wurde ich zufällig Ohrenzeuge einer kleinen Gruppe von Agile Coaches in einem Großunternehmen.

Erst sprachen sie ihre Einführungsfolien durch („Da sollten wir noch auf die agilen Werte eingehen.“). Das Ganze from the scratch weil agiles Vorgehen #Neuland und so, aber groß im Kommen.

Dann war Mittag und ich durfte einem anderen Gespräch der agile Coaches folgen: „Bist du jetzt schon Senior oder noch Junior? Und wie sieht es mit deiner Zertifizierung aus?“

Klar solches Hierarchie- und Statusdenken ist voll agil.

Steht bestimmt auch im agilen Manifest… Zertifikate vor gesundem Menschenverstand.

Agiles Projektmanagement ohne ein entsprechendes Mindset ist vollkommen sinnlos.

Mit dem richtigen Mindset ist schon fast wieder die Vorgehensweise egal.

Jedes Projekt braucht Agilität. Aber die erreicht man nicht durch die Einführung von agilem Projektmanagement, sondern durch eine entsprechende Einstellung und entsprechende Verhaltenswesien. Aus diesen resultiert dann (vielleicht) wieder ein agiles Projektmanagement oder aber ein open-minded klassisches Vorgehen.

Sinnfrei eingeführtes agiles PM ist genauso bürokratischer Mist, wie jede andere ohne Verstand eingeführte Methode. Mag die Methode an sich noch so gut sein.

Beitrag #721 auf schlossBlog

Teil 2 des PM-Onlinekurses bei LinkedIn

Gelesen: Immer wieder einmalig

Doris Helzle, Immer wieder einmalig – Erfolgreich in Projekten – pfiffig und kompakt, Saulheim 2016

Das kleine Büchlein von Doris Helzle ist eine humorvolle Projekt-Fibel mit wunderbaren Zeichnungen von André Poloczek (meine Favoriten sind das Reiten des toten Pferdes und der Sprung ins Neue/Unbekannte).

Doris Helzle weiß worauf es ankommt und deswegen stehen statt Methoden die Kommunikation und das Zwischenmenschliche im Vordergrund – da bin ich ganz bei ihr!

Sie hat wunderbare Bilder (nicht nur die von André Poloczek, sondern auch im übertragenen Sinne) für uns bereit: Seien es Lampe und Papierkorb mit ihren launigen Dialogen im Projektbüro oder das perfekte Verbrechen als Projektmetapher.

Einzig in einem Punkt tue ich mich schwer: Wem sollte ich diese Büchlein, das so schön gemacht ist, empfehlen?

Alten Projekthasen? Die würden Doris Helzle gleich zustimmen und am liebsten bei einem Bierchen mit der Autorin Projektanekdoten austauschen, aber etwas wirklich Neues würde ihnen nicht geboten.

Newbies? Da habe ich etwas Bedenken, denn sehr schnell geht die Autorin über elementare Begriffe hinweg und setzt das eine oder andere Mal vielleicht etwas mehr voraus, als man von dieser Zielgruppe erwarten darf. Klar weckt die Lektüre Appetit, aber für eine Einführung ist es dann doch etwas dünn.

Zyniker? Nein, dafür ist die Autorin zu pragmatisch.

Melancholiker? Vielleicht am Ehesten. So in den tiefen Abgründen eines Projekts, abends nach getaner Arbeit, um sich gemeinsam mit gleichgesinnten „auszukotzen“? Nun, dann vielleicht doch lieber auf ein Bierchen mit Doris Helzle…

Trotz allem, aber ein schön gemachtes Buch, das bei der Lektüre ein Schmunzeln ins Gesicht zaubert!

Beitrag #719 auf schlossBlog

Teil 1 des PM-Kurses ist online!

#MethodeEgal

Ein Beitrag zur Blogparade des ProjektMagazin: „Klassisch, agil oder egal: Ist ein guter Projektleiter mit jeder Methode erfolgreich?“

Nun, diese Frage ist natürlich rhetorisch. Die meisten Teilnehmer an der Blogparade plädieren daher für das sowohl als auch, sprich:

Kompetenz des Projektleiters + Methodeneinsatz.

Gebhard Borck hebt das Zusammenspiel von Methodenkompetenz und Charakter hervor.

Tassilo Kubitz spricht etwa von sozialer Kompetenz und methodischem Vorgehen, dem möchte ich fast zustimmen, allerdings würde ich lieber von systematischen Vorgehen sprechen. Es gibt nicht EINE richtige Methode oder Vorgehensweise, sondern ein ganzes Spektrum. Der Begriff methodisches Vorgehen könnte dabei als Verengung auf eine Methode oder Vorgehensweise missverstanden werden.

Auch Alexander Blumenau weist darauf hin, dass man ohne Methodenwissen erfolgreich sein kann, dass Methoden aber dennoch wertvoll sind.

Stephan Witt betont, dass eine Methode zum Projekt und zum Team passen muss. Er greift dabei Tom Michls Forderung nach Geisteshaltung auf. Bestärkt wird dieser Fokus auf das Team auch durch Martin Dragosits: „Nicht Methoden entscheiden über den Projekterfolg, sondern Menschen.“

Eberhard Huber differenziert noch die Teambetrachtung und erinnert uns daran, dass nicht jede Gruppe, die ein Projekt bearbeitet auch ein Team ist.

Also gut – einigen wir uns auf ein sowohl als auch, aber warum?

Keine Methode der Welt kann sicherstellen, dass Sie das Richtige machen, aber Methoden können helfen, das was Sie machen richtig zu machen. Methodeneinsatz zielt auf Effizienz. Für den Projekterfolg braucht es aber vor allem auch Effektivität, daher wählt Stephan Witt ja auch als erstes Kriterium für die Methodenauswahl das Projekt oder den Projektgegenstand selbst.

Natürlich braucht es dann auch noch die Sozialkompetenz, um das Team (oder die Gruppe (oder die betroffenen Stakeholder)) mit dem Methodeneinsatz zu erreichen. Methoden sind kein Selbstzweck. Wir dürfen nicht blind ihrer eigenen Logik folgen. Für mich dienen Methoden vor allem der Facilitation. Methoden sollen befähigen. Sie sind vor allem ein Moderationswerkzeug und kein Patentrezept!

Gleiches gilt für Vorgehensweisen (klassisch, agil,…). Auch hier würde ich die gleichen Kriterien anwenden, wie Stephan Witt bei der Methodenauswahl. Ein Projekt bei dem das Vorgehen rein technisch strikt sequentiell vorgegeben ist und durch die äußeren Rahmenbedingungen auch eine Arbeitsteilung gefordert ist, kann man kaum in ein agiles Korsett zwingen. Auf der anderen Seite bringen agile Vorgehensweisen viele Rituale und Werkzeuge mit, die Kommunikation, Transparenz und Eigenverantwortung fördern, Dinge die jedem Projekt gut tun, aber das Team (die Gruppe (oder das Umfeld)) muss dafür auch bereit sein.

 

Beitrag #715 auf schlossBlog

Erklärvideo zur Context Map

Zur im vorletzten Beitrag vorgestellten Context Map gibt es jetzt auch ein eigenes Erklärvideo.

Die Downloads zum Template gibt es hier:

Context-Map DIN A4
Context-Map DIN A3
Context-Map DIN A2
Context-Map DIN A1
Context-Map DIN A0

Beitrag #714 auf schlossBlog

Was bloggst du? Mathoi Projektmanagement

Der Blog:

Mathoi Projekt Management – http://www.mathoi.eu/cms/blog/

„In (un)regelmäßigen Abständen gibt es hier Beiträge rund um’s Projektmanagement (nicht nur bei Bauprojekten). Es wird auch immer wieder mal quasi über den Tellerrand zu artverwandten Themen gebloggt.“

Die Themen:

„Alles was irgendwie (auch im Entferntesten) mit Projektmanagement und Selbst- bzw. Produktivitätsmanagement zu tun hat. Natürlich liegt ausbildungs- und tätigkeitsbedingt ein Fokus im Bereich des Projektmanagements von Bauprojekten. Besonders die Verschränkungen bzw. Überschneidungen des Projektmanagements von Bau- und Software-/IT-Projekten reizen mich beim Schreiben immer wieder.“

Der Kopf dahinter:

„Thomas ist Bauingenieur mit einem (Über)Hang zu EDV und IT. Erste Praxiserfahrungen sammelte er in den 1990ern als technischer Zeichner neben dem Studium und später als Projektmanager und in der Örtlichen Bauaufsicht bei mehreren Großprojekten im Infrastrukturbau und im Hochbau.

Heute lebt und arbeitet Thomas in Graz als freiberuflicher Projektmanager. Er ist Mitbegründer von iPROT.info und unterrichtet an der FH Joanneum am Institut für Bauplanung und Bauwirtschaft sowie an der Technischen Universität Graz am Institut für Architekturtechnologie.“

Was treibt dich an zu bloggen?

„Primär ist es wohl die Freude am Schreiben und am Projektmanagement, sowie das spannende, weit offene Themenfeld, das sich daraus ergibt.“

Und welche Themen dürfen wir in nächster Zeit von dir erwarten?

„Derzeit interessiere ich mich stark für die Digitalisierung der Baubranche. Deshalb wird es dazu in nächster Zeit immer wieder etwas zu lesen geben. Und ich möchte meine im letzten Jahr begonnen Serie zu OmniFocus (eine App für das Aufgabenmanagement) fortsetzen.“

Und was sagt der schlossBlog über Mathoi Projektmanagement gemacht?

Thomas Mathoi kenne ich seit dem ersten PM Camp und freue mich jedes Mal wie ein Schnitzel ihn wieder zu sehen. Auch wenn er die Fahne des Bauprojektmanagement hoch hält, bloggen tut er meist über allgemeine Projektmanagement-Themen. Neben der Praxis ist Thomas auch noch in der Lehre an der FH JOANNEUM in Graz unterwegs und hat mit seinen Studenten und deren Seminararbeiten openPM unterstützt. Danke, lieber Thomas!

Was bloggst du? ist eine Serie mit Blog-Vorstellungen.
Beitrag #713 auf schlossBlog

Kontextanalyse

Jedes Projekt, jede Aufgabe ist kontext- und situationsspezifisch. Entsprechend von zentraler Bedeutung sind Kontext- und Umweltanalyse. Als Freund von Graphic Facilitation ziehe ich dafür gerne Vorlagen wie die Context Map von The Groove oder in einem betriebswirtschaftlichen Umfeld die Branchenanalyse nach Michael E. Porter heran:

Was mir bisher gefehlt hat ist eine frei verwendbare Vorlage und so entstand meine eigene Fassung einer Context Map, die ich hier gerne teilen möchte und die unter Creative Commons Lizenz jedem zur Nutzung frei steht (pdf-Downloads finden sich am Ende des Artikels):

Unser Ausgangspunkt ist zunächst eine Blackbox. Das kann ein Projekt sein, eine Aufgabe, eine Dienstleistung, eine Problemstellung, ein Prozess,…

Unterzieht man unsere Blackbox einer einfachen Prozessbetrachtung, so wird es Input-Faktoren geben, also Dinge, die direkt in die Blackbox eingehen oder sie bestimmen und Output-Faktoren auf der anderen Seite. Wenn ich mit Porter ein Produkt analysieren würde, dann könnten links die Lieferanten und rechts die Kunden stehen, aber das Schema ist bewusst abstrakt und somit vielseitig einsetzbar.

Die eigentlich Umweltanalyse erfolgt in zwei Sphären oberhalb unserer Kernbetrachtung. Externe Einflüsse können wir auf einer Mikro- und einer Makroebene unterscheiden. Auf der Makroebene würden sich etwa globale Entwicklungen, technische oder volkswirtschaftliche Entwicklungen niederschlagen, diese können sich aber möglicherweise auch auf einer Mikroebene auswirken, z.B. in einem lokalen Bebauungsplan, dem Staudamm vor Ort oder der lokalen Infrastruktur. Die Darstellung verzichtet bewusst auf eine Festlegung der Kategorien einer solchen Betrachtung. Die Anzahl der „Tortenstücke“ ist willkürlich. In der Context Map von The Groove werden beispielsweise politische Faktoren und Trends, Umweltklima und klimatische Trends, technologische Faktoren, Unsicherheiten und Kundenbedürfnisse als Kategorien genannt.

Neben dieser „abstrakt, globalen“ Umweltbetrachtung können wir aber auch unseren Kernprozess noch einer näheren Untersuchung unterziehen, denn Input, der Betrachtungsgegenstand selbst (Blackbox) und Output unterliegen ihrerseits konkreten Entwicklungen und Einflüssen, was im Schema jeweils mit „Disruption & Change“ dargestellt wird. Das können kleine Veränderungen und Einflüsse sein, aber auch grundsätzliche Regeländerungen und disruptive Entwicklungen.

Die Einsatzmöglichkeiten dieser Context Map sind vielseitig. Das Schema selbst ist abstrakt und muss erst von Fall zu Fall befüllt werden, aber bitte nicht als plumpes Formular, sondern als Faciltitation-Technik. (Mehr dazu im Beitrag Canvas-Kritik.)

Hier noch die pdf-Vorlagen der Kontext-Map in verschiedenen Formaten:

Viel Erfolg beim beim praktischen Einsatz dieses Templates!

Beitrag #712 auf schlossBlog