#631 Informationssicherheit – Guiding Questions

Bei dem ganzen Hype, der dem Thema Informationssicherheit in den letzten Jahren widerfahren ist, darf man eines nicht vergessen: Informationssicherheit ist kein Selbstzweck, sie dient lediglich zur Sicherstellung des eigentlichen Geschäftszweckes/des eigentlichen Auftrags. Demnach gilt: Business first!

Beim Thema Informationssicherheit darf es nicht um die Befriedigung aus Normen abgeleiteter Anforderungen gehen, sondern es ist stets eine Abwägung aus Business Sicht. Dies gilt insbesondere, da es eine 100%-Sicherheit nicht gibt, insofern ist Informationssicherheit immer auch ein Risikomanagement-Prozess.

Bei einem großen Rollout-Projekt zur Implementierung eines IT-Security-Prozesses im IT Service-Management, mussten wir lernen, dass wir die Kollegen immer wieder überfordert haben. Zum Einen ging die eben erwähnte Business-Perspektive in den Köpfen immer wieder verloren, zum Anderen verloren die Kollegen bei der Vielzahl der Security Requirements schnell den Überblick und haben den Wald vor lauter Bäumen nicht mehr gesehen. Da wurden dann technische Betriebs-Details  formal mit dem Provider geklärt, anstatt sich grundsätzlich mit der Frage auseinander zu setzen, was (im konkreten Fall) eine Cloud-Lösung überhaupt ist und ob man die eigenen Daten wirklich in fremde Hände geben möchte. Natürlich braucht es auch dedizierte Anforderungen, aber ohne ein entsprechendes Mindset wurde die Bearbeitung schnell zum sinnentleerten Papiertiger.

Vor diesem Hintergrund habe ich eine Reihe von Guiding Questions formuliert, um die Kollegen wieder “abzuholen”. Natürlich gilt als oberster Grundsatz die Orientierung am Geschäftszweck (1), dann ist ein generelles Lösungsverständnis erforderlich (2) um überhaupt die klassischen Dimensionen der Informationssicherheit bearbeiten zu können (3-5). Zur Visualisierung habe ich mich des IT Security Canvas bedient:

(1) Business first!

(2) Lösung & Architektur
Um ein allgemeines Verständnis unserer Lösung zu entwickeln:

  • Wie sieht das generelle Design/die Architektur der Lösung aus?
  • Gibt es Schnittstellen zu anderen Systemen?
  • Wo sind diese Systeme räumlich angesiedelt?
  • Wo werden Daten gespeichert, verarbeitet oder transportiert?
  • Welche Parteien sind involviert (Benutzer, Administratoren, Dienstleister,…)?
  • Gibt es ein IT-Service-Management?


 
 
 
 
 

(3) Vertraulichkeit / Confidentiality
Wenn Vertraulichkeit von besonderer Relevanz für unsere Lösung ist:

  • Welche Personengruppen und Systeme sind beteiligt bzw. haben Zugriff?
  • Deckt die Zugriffskontrolle all diese ab?
  • Werden Verschlüsselungstechniken eingesetzt? Bei der Speicherung? Bei der Übertragung?


 
 
 
 
 

(4) Integrität / Integrity
Wenn Integrität von besonderer Relevanz für unsere Lösung ist:

  • Wie kann ein Integrationsverlust bemerkt werden?
  • Gibt es Optionen zur Wiederherstellung?
  • Werden unterstützende Features wie Plausibilisierungen, Verschlüsselung, Backups, etc. genutzt?


 
 
 
 
 

(5) Verfügbarkeit / Availability
Wenn die Verfügbarkeit von besonderer Relevanz für unsere Lösung ist:

  • Ist unsere Lösung in einem IT Disaster Recovery und/oder in einem Business Continuity Management zu berücksichtigen?
  • Decken Disaster Recovery und Business Continuity Pläne alle beteiligten Systeme und Parteien ab?

#630 Erklärvideo 1.0

Rein zufällig bin ich beim Surfen durch einige TED-Videos darüber gestolpert, dass mittlerweile eine ganze Reihe von Videos der leider schon verstorbenen Management-Trainerin Vera F. Birkenbihl auf YouTube zur Verfügung stehen.

Sie hat in einer Zeit vor den Internet-Erklärvideos bereits eigene Videos veröffentlicht, die uns in ihrer eigenen Machart auch wieder zu neuen Videos inspirieren können. Das Handschriftliche und Gezeichnete in ihren Videos sind nicht nur Visualisierung, sondern auch Taktgeber für ihre Erklärungen. Im Gegensatz zu perfektionierten Hochglanzvideos, die den Betrachter und seine Lerngeschwindigkeit vergessen, passiert dies  Vera F. Birkenbihl mit ihren Ausführungen und Darstellungen nicht. Weniger ist mehr. Es kommt nicht auf die perfekte Videoproduktion an, sondern auf die Kunst der Erklärung, (aber das war ein anderer Post hier auf schlossBlog).

#629 Gelesen: the art of explanation

 

Lee Lefever, The art of explanation. Making your ideas, product, and services easier to understand, Hoboken 2013, ISBN-13: 978-1-118-43429-1 

 

Lee Lefever ist einer der “Urväter” der Erklärvideos im Internet. Zusammen mit seiner Frau Sachi betreibt er in Seattle Common Craft. die mit ihren Erklärvideos u.a. für Google, Dropbox oder Twitter und viele mehr in den vergangenen Jahren immer wieder für Aufsehen gesorgt haben.

Witziger Weise lag sein Buch The art of explanation bereits auf meinem Schreibtisch, noch bevor mich Torsten Koerting auf dem PM Camp RheinMain in die Welt der Erklärvideos gezogen hat.

Allerdings ist die Art of explanation kein Erklärvideo-Buch! Zwar beschreibt Lefever seine Arbeitsweise und referenziert auch auf viele Erklärvideos, aber in seinem Buch versucht er erfolgreich die Mechanismen und die Philosophie des Erklärens ganz unabhängig vom gewählten Medium zu vermitteln:

“The art of explanation is unlike the ability to draw or write poetry; it is more about perspective, or orienting yourself around the idea that explanations are creations, made of facts, that represent a new way of approaching an idea.”

Als Bausteine für Erklärungen identifiziert er: das gemeinsame Verständnis (agreement), dem Kontext, die Story, Verbindungen, Beschreibungen und Schlussfolgerungen.

Lefever zeigt, dass wir je nach Vorkenntnis einen unterschiedlichen Bedarf der Vermittlung des Warum und des Wie einer Sache haben. Er führt uns in das Storytelling ein, in dem er Leitfragen stellt, ein Basic Story Format aufzeigt und uns aber auch auf die Grenzen des Storytelling hinweist.

Er zeigt uns Beschränkugnen un0 Randbedingungen auf und legt uns Vereinfachungen ans Herz. Lefever betont die Bedeutung des Schreibprozesses (auch für andere Medien)  und beschäftigt sich mit Visual Thinking (hier freut sich der visualPM). Beim Thema Visualisierung verweist er auf Dan Roam´s Napkin Academy.

The art of explanation ist ein kluges, aber auch ein erstaunlich leises Buch. Hinter einem so klassisch aufgemachten Buch mit dezenten Illustrationen würde man kaum eine so erfolgreiche Videoproduktion erwarten, aber sein Erfolgsgeheimnis – Die Kunst des Erklärens – gibt uns Lee Lefever trotzdem preis.

#628 Die andere Barcamp-Doku – Streamcamp

Hier hatte ich ja schon auf das Streamcamp 2014 hingewiesen. Und wie es sich bei Streaming-Spezialisten nicht anders gehört, haben die Kollegen ihr Barcamp gleich als mit Vieostreams dokumentiert, nachzuschauen bei Hannes Schleeh:

http://schleeh.de/streamcamp-2014-hands-on-workshop-fuer-streaming/

 

#627 Kreativität und Kreativitätstechniken

Gerade eben habe ich eine Generalüberholung des openPM-Artikels Kreativität & Kreativitätstechniken abgeschlossen. Aber was heißt abgeschlossen, eigentlich ist dies erst der Anfang:

Die Übersicht der Kreativitätsmethoden lässt sich sicher noch erweitern, um Links zu Methodenbeschreibungen ergänzen und das eine oder andere Kreuz in der Beschreibungsmatrix sollte vielleicht noch korrigiert werden.

Beim weiteren Ausbau bin ich aber hoffentlich nicht allein, sondern wünsche mir möglichst viele Mitstreiter! Also wer Lust hat ist herzlich eingeladen den Artikel  (oder auch einen anderen Artikel auf openPM) zu erweitern oder zu ergänzen. Es reicht schon, wenn ihr einen interessanten Link ergänzt, einen Tippfehler verbessert, oder,  oder…

Und neue Artikel sind selbstverständlich auch erlaubt!

#626 Reporting, BI & Big Data

Reporting ist ein Klassiker.
BI (Business Intelligence) und Big Data sind allgegenwärtige Buzz Words.
Zeit sich hier einmal dem Thema zu widmen und das nicht nur für Projektmanager.

Möglichkeiten und Grenzen von Big Data

Ein Beispiel für die Nutzung von Big Data ist der Fall des Autobahn-Snipers: Ein frustrierter LKW-Fahrer schießt während der Fahrt über mehrere Jahre aus seiner Fahrzeugkabine auf andere Fahrzeuge. Überführt wird er letztlich über eine systematische Auswertung von Kennzeichen-Erfassungen auf deutschen Autobahnen. Der Aufwand dafür beträchtlich, sowohl in finanzieller als auch in zeitlicher Hinsicht.
Nicht nur im Zusammenhang mit dem NSA-Skandal wird die Aussagekraft von Kommumikations-Metadaten immer wieder thematisiert. Dimitri Tokmetzis zeigt auf netzpolitik.org, was allein schon Metadaten über uns aussagen.
Oder haben Sie sich schon einmal gewundert, was soziale Netzwerke bereits über uns wissen ohne, dass wir es ihnen gesagt haben (z.B. weil unsere Kontakte uns in ihrem Adressbuch führen oder es ungewöhnliche Schnittmengen in den Kontakten unserer Kontakte gibt).
Big Data per se ist weder gut noch böse. Die Möglichkeiten sind einerseits beeindruckend aber andrerseits auch beängstigend. Wir können uns nicht davor verschließen, aber um so wichtiger ist eine kritische Auseinandersetzung mit dem Thema. Wir haben in der digitalen Welt bereits einen Kontrollverlust über unsere Daten erlitten .(Diese Tage erscheint hierzu das Buch: Das neue Spiel von Michael Seemann – siehe auch sein Blog ctrl-Verlust.) Wer argumentiert, er hätte nichts zu verbergen, ist naiv, denn aus der Kombination an sich “harmloser” Daten entsteht mitunter eine kritische Information. Stellen Sie doch einmal einen Kreditantrag oder unterziehen sich der Gesundheitsprüfung für den Abschluss einer Versicherung und Sie sind schneller in Erklärungsnöten, als Sie sich vorstellen können.

Garbage in – Garbage out

Worüber auch Big Data nicht hinwegtäuschen kann sind die elementaren Grundprinzipien der Datenverarbeitung. Nach wie vor gilt Garbage in – Garbage out. Nur in der Flut der Daten vergessen wir manchmal welches Datum tatsächlich ein Information enthält und welches nicht oder überbewerten oder missinterpretieren dessen Informationsgehalt. Wir können unser Reporting und unsere Prozesse beliebig optimieren, aber wenn der Inhalt nicht stimmt…

Nicht Äpfel mit Birnen vergleichen

Natürlich dürfen wir auch nicht Äpfel mit Birnen vergleichen (inhaltlich).
Und zeitliche Synchronität wäre für die Vergleichbarkeit auch schön.

Korrelationen nicht mit Kausalität verwechseln

Bei der Interpretation von Daten dürfen wir selbstverständlich auch nicht Korrelationen mit Kausalitäten verwechseln. Handelt es sich tatsächlich um Ursache-Wirkungsbeziehungen oder möglicherweise nur um 2 Symptome der gleichen Krankheit…

Unwort: Komplexitätsreduktion

Es ist i.d.R. eine irrige Annahme, dass sich Komplexität reduzieren lässt. Eine Reduktion hilft uns vielleicht bei der Erfassung des Überblicks oder in Bezug auf Facetten, sie reduziert aber nicht die Komplexität des realen Systems und verführt uns so zu möglichen Kurzschlüssen und Fehlentscheidungen. Wir sollten uns gerade auch bei der Erstellung von Reports und Auswertungen stets ihrer Unvollkommenheit bewusst sein. Mitunter ist hier weniger mehr: Wenige Zahlen, die wir aber vernünftig einordnen und erklären können, deren Grenzen uns bewusst sind, sind besser als pseudowissenschaftliche Tiefe, deren Grundannahmen auf fragilen Mauern stehen, uns aber aufgrund ihrer vermeintlichen Exaktheit eine falsche Glaubwürdigkeit suggeriert. Allzu oft tappen wir in eine psychologische Falle und glauben viel leichter an die Richtigkeit einer Aussage, weil sie vermeintlich bis auf 2-Nachkommastellen belegt ist.

#625 Was tun wenn´s brennt?

Für die zweite Ausgabe des ProjektSMag hat Tim Dettmer u.a. mich gefragt, was ich tun würde wenn ein Risiko mit hoher Tragweite eintritt. Hier meine Antwort:

  • (1) Orientieren – Meine „Lieblingswerkzeuge sind hierbei der MindManager und visuelle Hilfsmittel wie der openPM-Canvas (den ich auch selber mitentwickelt habe).
  • (2) Kommunizieren & Transparenz – Kommunikation ist der Erfolgsfaktor in Projekten schlechthin. Ohne Kommunikation gibt es keine Transparenz. Die Kommunikation muss dabei konstruktiv, also lösungsorientiert sein. Schuldzuweisungen, Fingerpointing, etc. sind gerade in Krisenzeiten zwar beliebt, aber kontraproduktiv
  • (3) Verbindliches Handeln – Ich brauche nicht die x-te Revision eines Projektplans, oft reicht schon eine einfache Aufgabenliste mit klaren Verantwortlichkeiten, die dann aber auch verbindlich umgesetzt und verfolgt wird.

#624 Gelesen: Projektmanagement im Verlag

 

Holger Zimmermann, Projektmanagement im Verlag, Berlin, Boston 2014, ISBN 978-3-11-032377-1

 

Wie Douglas Adams Leser wissen, hat sich der Hitchhiker gegenüber der Encyclopedia Galactica im Wesentlichen durchgesetzt, weil auf seinem Umschlag in großen, freundlichen Buchstaben steht: DON`T PANIC! Wenn mich jemand fragt, worin sich “Projektmanagement im Verlag” von anderen guten Projektmanagement-Einführungen unterscheidet, dann würde ich ganz im Sinne Adams antworten: Mit seinem Verweis auf openPM!

Ist ja auch kein Wunder – Holger ist eines unserer Gründungsmitglieder bei openPM und sein Buch ist eine sehr solide Einführung in “klassisches” Projektmanagement. Den zweiten Teil des Titels “…im Verlag” kann man getrost streichen. Was inhaltlich beschrieben wird, ist vollkommen branchenunabhängig, lediglich die Beispiele und einzelne Randbemerkungen entstammen der Verlagswelt (“Neue Buchreihe mit Webportal”), das ist aber keine Schwäche, ganz im Gegenteil. Umfang und Detaillierung sind vollkommen angemessen. Es handelt sich nicht um ein allumfassendes Nachschlagewerk, sondern um eine verständliche Einführung. Der Lernende wird nicht mit schierer Masse erschlagen, sondern intelligent mit vielen wegweisenden und mitunter auch relativierenden Hinweisen durch die Materie geführt.

Sehr gut gefallen haben mir die 32 Fragen, die durch das Buch (und durch Projekte) führen. Weiter gefallen haben mir die Abgrenzungen zwischen Routineprozess und Projekt, die Nutzung von Routineprozessen in Projekten (z.B. bei der Buchhaltung) und die Verantwortung in Projekten und in Routineprozessen.

Ein bisschen scheint mir das Buch technisch orientiert und etwas planungslastig, auch wenn ein nochmaliger Blick ins Inhaltsverzeichnis eigentlich eine ausgewogene Mischung zeigt. Aber keine Angst – Holger kennt sehr wohl die Grenzen der Planung, Es finden sich zahlreiche kluge Hinweise, die Einsatz und Zweck relativieren:

“Projektplanung ist nicht mehr und nicht weniger als gemeinsames, systematisches Nachdenken darüber, wie die Projektziele erreicht werden könnten.”

Dem würde auch kein Verfechter eines agilen Projektmanagement widersprechen, der eine solche Planung halt nur auf den nächsten Sprint beschränken würde.

“Sinn eines Projektplans ist nicht die Einhaltung des Plans. Ein Plan ist ein Hilfsmittel, […]”

Es geht um eine pragmatische Planung. es geht nicht um Vorgaben sondern und Abstimmungsprozesse. Planung ist auch nicht elitär, sondern sollte alle einbeziehen (“gemeinsames Nachdenken”).

Das Buch folgt dem Projektablauf, von der Auftragsklärung inkl. Risiken und Projektzielen, Projektplanung, Projektsteuerung bis zum Projektabschluss. Etwas unglücklich finde ich dabei, dass einige Themen, wie Rollen, Stakeholder oder die Projektkommunikation die durchgehend relevant sind, dabei erst im Kapitel Projektsteuerung erläutert werden. Das führt bei mir wahrscheinlich zu diesem falschen Eindruck der Überbetonung von Planung. Einem PM-Anfänger würde ich auf jeden Fall als weitere Lektüre beispielsweise Projektführung für Profis von Berta Schreckeneder ans Herz legen. Dort werden genau die anderen Facetten abgedeckt. (Und für den Spaß natürlich Tom De Marcos “Der Termin“).

Das Buch enthält einige (Formular-)Vorlagen, die QR-Codes führen dann aber in einen Webshop, in dem diese käuflich erworben werden können.

Im letzten Kapitel vor dem Schlusswort skizziert Holger noch wie ein Projektmanagement-Standard in ein Unternehmen (Verlag) eingeführt werden könnte, von der Definition eines Projektmanagement-Prozesses, der Qualifizierung der Mitarbeiter bis hin zu Pilotprojekten.

Agiles Projektmanagement spielt in dieser Einführung kein große Rolle, wenn gleich Holger treffend deren Qualitätsorientierung durch die Fokussierung auf funktionsfähige Resultate beschreibt, aber agil ist halt noch viel mehr, auch wenn die damit verbundene Grundsatzdebatte das einen PM-Newbie vielleicht an dieser Stelle nur abschrecken würde.

#623 schlossBlog wird 8


Kaum zu glauben, aber der schlossBlog wird in diesen Tagen 8 Jahre alt!

Älter wie meine Tochter, manchmal auch frecher wie sie…

Nicht ganz so alt wie mein Sohn, aber der Blog hat ja auch Vorläufer-Aktivitäten in statischen Firmenseiten und privaten Web-Versuchen, die ihn dann altersmäßig auch noch überholen. Langsam erklären sich die grauen Haare auf meinem Kopf.

Zeit allen Lesern und Begleitern zu danken. Ich freue mich schon auf die vielen Themen und Ideen, die hier, auf openPM oder an anderen Stellen noch vor uns liegen!

#622 Ein Logo für den visualPM

Martin Hausmanns UZMO ist schuld! Jetzt hat auch der visualPM sein eigenes Logo. Entstanden aus dem Spiel mit Stift und grafischen Elementen: