Mit einer auf dem Kopf stehenden Pyramide lassen sich schematisch die Anforderungen (Englisch: Requirements) an ein Produkt, System oder einen Prozess darstellen. Die Pyramidenform ergibt sich aus der Priorisierung der einzelnen Anforderungen. Es wird vermutlich wenige besonders wichtige Anforderungen, aber sehr viele „nette“ Zusatzanforderungen geben – auf die möglicherweise sogar verzichtet werden kann ohne die Grundeigenschaften des Systems zu gefährden.

Grundsätzlich können zwei Arten von Anforderungen unterschieden werden: funktionale und nichtfunktionale Anforderungen.

Funnktionale Anforderungen legen fest, was ein System tun soll. Nichtfunktionale Anforderungen spiegeln eher Qualitätseigenschaften und Randbedingungen wieder. Solche können z.B. Zuverlässigkeit, Look & Feel, Benutzbarkeit, Leistung und Effizienz, Betrieb und Umgebungsbedingungen, Wartbarkeit, Änderbarkeit, Sicherheitsanforderungen, Korrektheit, Flexibilität oder Skalierbarkeit sein.

In der Darstellung hier, werden die nichtfunktionalen Anforderungen noch einmal gebündelt in relativ systemnahe Anforderungen, wie beispielsweise das Handling und die Benutzerführung, Sicherheitanforderungen oder Security-Requirements und sonstige nichtfunktionale Anforderungen.

Der ursprüngliche Post stammt aus dem Jahr 2017.

Noch beschäftigen sich alle mit Digitalisierung. Der Hype ist in vollem Gang, da stellt t3n in Heft 54 die Frage: Was kommt danach?
Klingt spannend – finde ich.

Wer heute sich auf die Digitalisierung konzentriert, verpasst der nicht schon den nächsten Trend und wird erst recht abgehängt?
Aber was heißt schon Digitalisierung?

Ist Digitalisierung überhaupt die richtige Fragestellung?
Müssen wir nicht unsere Modelle permanent in fragestellen um erfolgreich bleiben zu können?
Und das Thema Digitalisierung streift dabei nur den technologischen Aspekt.

Die schöpferische Zerstörung des guten, alten Schumpeter ist dabei doch wichtiger, oder?

Achja, zu meiner t3n-Weihnachtslektüre: Ich habe sie wieder weggelegt. Eine Mogelpackung, weil sie die Digitalisierung letztlich nur aufwärmt. Erste Spuren von dem, was danach kommt, konnte ich leider nicht entdecken.

Digitalisierung, Cloud und agile Vorgehensweisen sind Anzeichen einer sich verändernden IT in Unternehmen. Die einen versuchen sich an einem Paradigmenwechsel, die anderen wollen sich gar selbst abschaffen. Wenn das „Business“ IT-Leistungen von der Stange in der Cloud zusammenstellt und einkauft, braucht es dann überhaupt noch klassische IT in Unternehmen?

So etwas wie einen Application Manager braucht es dann künftig nicht mehr, entgegnete mir jüngst ein Kunde.

Aber das greift zu kurz.

Auch wenn klassische IT-Abteilungen Auflösungserscheinungen haben, wenn das Pendel gerade wieder von der zentralen IT zu dezentralen Lösungen im Business ausschlägt, sich Rollen und Aufgabenverteilungen ändern: Verantwortlichkeiten lösen sich nicht in Luft auf und müssen auch in der neuen Welt wahrgenommen werden. Außerdem müssen Kompetenz und Know-how erhalten bleiben.

Auch in der neuen Welt wird es jemanden geben, der die IT-Lösungen (aus der Cloud) konfiguriert und zusammenstellt – einen Architekten. Der ist künftig vielleicht wieder im Business und nicht mehr in der IT angesiedelt. Es wird zweifellos Veränderungen geben.  Er ist dann eher ein Service-Manager mit einem weniger technischen Profil, der Konfiguration und Einkauf vornimmt, aber letztlich behält er immer noch eine Gesamtverantwortung. Die lässt sich nicht delegieren. Der beste Cloudanbieter kann nicht wissen, wie wir sein Produkt einsetzen und wofür, mit welchen anderen Produkten, anderer Hersteller wir es kombinieren, wem wir Zugriffsrechte geben und welche Anforderungen wir haben.

Wenn wir IT-Abteilungen abschaffen, müssen wir dem Rechnung tragen, dass wir die neuen Rollen auch entsprechend befähigen. Auch ein Service-Manager im Business muss Sicherheitsanforderungen und Compliance sicherstellen. Die Cloudanbieter sind dabei seine Partner, aber verantwortlich bleibt er letztlich selbst. Die Welt wird nicht weniger komplex.

Mit einer auf dem Kopf stehenden Pyramide lassen sich schematisch die Anforderungen (Englisch: Requirements) an ein Produkt, System oder einen Prozess darstellen. Die Pyramidenform ergibt sich aus der Priorisierung der einzelnen Anforderungen. Es wird vermutlich wenige besonders wichtige Anforderungen, aber sehr viele „nette“ Zusatzanforderungen geben – auf die möglicherweise sogar verzichtet werden kann ohne die Grundeigenschaften des Systems zu gefährden.

Grundsätzlich können zwei Arten von Anforderungen unterschieden werden: funktionale und nichtfunktionale Anforderungen.

Funnktionale Anforderungen legen fest, was ein System tun soll. Nichtfunktionale Anforderungen spiegeln eher Qualitätseigenschaften und Randbedingungen wieder. Solche können z.B. Zuverlässigkeit, Look & Feel, Benutzbarkeit, Leistung und Effizienz, Betrieb und Umgebungsbedingungen, Wartbarkeit, Änderbarkeit, Sicherheitsanforderungen, Korrektheit, Flexibilität oder Skalierbarkeit sein.

In der Darstellung hier, werden die nichtfunktionalen Anforderungen noch einmal gebündelt in relativ systemnahe Anforderungen, wie beispielsweise das Handling und die Benutzerführung, Sicherheitanforderungen oder Security-Requirements und sonstige nichtfunktionale Anforderungen.
 

Mein geschätzter Kollege Till sagt immer:“Jedes Problem beginnt mit einer Excel-Liste, dann wird eine Datenbank daraus und schließlich eine Applikation.“

Die Zwischenstadien „Schmierzettel“ und Sharepoint-Liste überspringt er gleich.

Vielleicht aus gutem Grund. Aktuell strapaziere ich Sharepoint, mit einem Access-Frontend, dass mehrere Sharepointlisten zusammenführt.

Und man glaubt gar nicht, wie schnell man an die Grenzen von Sharepoint stößt. Auch wenn eine SQL-Datenbank darunter liegt, so sind doch insbesondere dem Web-Frontend einige Einschränkungen geschuldet: So sollten es beispielsweise nicht mehr als 5000 Datensätze in einer Tabelle sein, mehrwertige Felder sind ganz BÖSE und Bulk-Jobs, also Massenbearbeitung, z.B. durch eine Aktualisierungsabfrage aus Access sollte nicht mehr als 100 Datensätze umfassen.

Auf diese und eine Reihe weiterer Einschränkungen verweist selbst Micsrosoft im Technet.

Warum wir trotzdem Sharepoint nutzen? Als Provisorium und zur Vorbereitung der späteren Applikation. Till hat doch Recht…

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?

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 (Amazon Affiliate Link) 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.

Ein Produkt aus dem Hause Schloß – unverwechselbar und voller unglaublicher Energien: SAP Hannah

Ursprünglicher Beitrag #564

Das Buch Pragmatisches IT-Projektmanagement (PITPM)  (Amazon Affiliate Link) von Niklas Spitczok von Brisinski, Guy Vollmer und Ute Weber-Schäfer liegt jetzt ganz frisch in der 2., überarbeiteten Auflage vor. Es ist eines der ehrlichsten PM-Bücher, das genau das einhält, was es verspricht:

• Klassisches Projektmanagement á la PMI/PMBOK
• Drastisch abgespeckt mit Fokus auf Softwareentwicklungsprojekte, sogar noch schlanker als in der 1. Auflage.
• Obwohl es die Prozessdarstellung des PMBOK aufgreift bleibt es ein Praxisbuch (Kompliment für diese gelungene Gradwanderung)!
• Pragmatisch mit vielen Office-Templates, die unter Creative Commons-Lizenz auch Nicht-Lesern nach Registrierung  auf http://www.pitpm.net/ zur Verfügung stehen

Das sind die starken Seiten des Buches, die  es schon alleine zu einer Kaufempfehlung machen.

An seine Grenzen stößt es da, wo auch der PMBOK an seine Grenzen stößt. Nicht verwunderlich, aber schade.

Ich muss gestehen, dass ich während der Lektüre den PMBOK wieder aus dem Regal gezogen habe und dabei auch die vierte mit der aktuellen fünften Ausgabe verglichen habe. Dort haben im Rahmen der Projektprozesse  auch agile Gedanken (zumindest rudimentär) Einzug erhalten. Im PMBOK werden explizit iterativ, inkremmentelle Projektlebenszyklen und adaptive Projektlebenszyklen unterschieden (damit hat es sich aber schon wieder mit der Agilität).

Im PITPM habe ich den Eindruck das Agilität noch weiter nur auf iteratives Vorgehen reduziert wird. Die mit agilen Methoden einhergehenden strukturellen Änderungen, Rollenänderungen, Rituale und neuen Artefakte bleiben komplett auf der Strecke. „Agilos“ werden als Leser enttäuscht sein. Für euch gilt: Finger weg! Aber wer ein Arbeitsbuch und/oder Vorlagen für „klassisches“ Projektmanagement in der IT sucht, ist genau richtig.

Hier findet man von Anforderungserhebung, Stakeholderanalyse,  Earned Value Analyse, bis hin zu Test und Abnahme das klassische PM-Handwerkszeug. Und zwar nicht overengineert, sondern bewusst pragmatisch. Aber das hat uns ja der Titel auch versprochen. Und was er verspricht, das hält er auch.

Niklas Spitczok von Brisinski, Guy Vollmer, Ute Weber-Schäfer: Prgamatisches IT-Projektmanagement. Softwareentwicklungsprojekte auf Basis des PMBOK Guide führen, 2. überarbeitete und aktualisierte Auflage, dpunkt.verlag, Heidelberg 2014

Und noch ein Canvas… Nachdem der visualPM schon beim openPM-Canvas seiner Leidenschaft für die Visualisierung komplexer Themen nachgegangen ist, experimentiert er gerade wieder mit einer neuem Canvas: Einem it-security-canvas.

Dieser Canvas ordnet die Rubriken der ISO 27001:2013 (Wikipedia)  um ein stilisiertes System-Use-Case-Diagramm und erlaubt so auch eine visuelle Darstellung und Verknüpfung von IT-Security-Themen. Storytelling wird so auch für abstrakte Themen, wie IT-Sicherheit möglich. In einem ersten Anwendungsfall, habe ich versucht Defizite und Handlungsbedarfe im Vertrag mit einem IT-Service-Provider transparent herauszuarbeiten. Ich kann mir auch vorstellen den Canvas in verschiedenen Versionen als Poster weiter zu entwickeln, um Risks, Threats und Controls der relevanten Gebiete darzustellen.

Wer auch mit der it security canvas experimentieren will, ist hierzu herzlich eingeladen. Vorlagen gibt es in A0, A3 und A4 als pdf-download:

• it security canvas A4
• it security canvas A3
• it security canvas A0

Kommentare als Feeback sind herzlich willkommen!