projektmanagement, traininig, medien
Um ehrlich zu sein, ist es mir selbst ein Rätsel warum, aber das Testmanagement in IT-Projekten ist jetzt über Jahre dauerhaft der meistgefragteste Content auf schlossBlog.
Die Artikel für das Projektmagazin sind bereits aus dem Jahr 2009. Die Zusammenfassung gibt es auch als Präsentation:
 |
Oder im Original beim Projektmagazin (Abodienst):
Teil 1: Ablauf und Organisation
Teil 2: Das Excel-Toolset
Heute frisch angereist zur PVM nach Hagen. Die PVM ist eine Fachtagung zweier Fachgruppen der Gesellschaft für Informatik (Vorgehensmodelle und Projektmanagement) in Kooperation mit der Fachgruppe IT-Projektmanagement der GPM e.V. und PMI Germany Chapter e.V..
Dieses Jahr geht es um nachhaltige IT-Projekte.
Morgen darf ich in einem Kompaktbriefing das Thema Ethik & Compliance in Projekten vorstellen. (Die Folien gibt es hier.)
Ethik und Compliance? Da war doch mal was… Ja, richtig dazu gibt es auch ein LinkedIn Learning Training von uns.
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:
(3) Vertraulichkeit / Confidentiality
Wenn Vertraulichkeit von besonderer Relevanz für unsere Lösung ist:
(4) Integrität / Integrity
Wenn Integrität von besonderer Relevanz für unsere Lösung ist:
(5) Verfügbarkeit / Availability
Wenn die Verfügbarkeit von besonderer Relevanz für unsere Lösung ist:
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.
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) 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.
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…
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.
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…
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
 |
