Zum Inhalt springen

Artikel mit den Schlagwörtern ‘Projektmanagement’

Bessere Risikoprävention durch dynamische Schutzmaßnahmen

Durch die Dynamisierung der Schutzmaßnahmen kann man auch einer heterogenen Risikolage Herr werden. Bei gleichem Investment kann das Sicherheitsniveau und damit der Return On Investment signifikant gesteigert werden. Dieser Artikel basiert darauf, dass wir uns der Risikolage eines Unternehmens von den Prozessen her nähern: Kostenreduzierung durch prozessbasierte Risikoanalyse.

Ausgangslage

Zu oft ist die genaue Risikolage eines Unternehmens nur unzulänglich bekannt. Man weiß, dass die Anlagen des Unternehmens einem Risiko unterliegen. Schließlich sind technische Einrichtungen in ihrer Gesamtheit immer irgendwie gefährdet. Wo aber genau die Risiken liegen und welcher Art diese sind, ist oft unklar. Daher wird dem allgemeinen Risiko mit einer großen Feuerpatsche entgegen getreten. Oder lassen Sie es mich anders ausdrücken: Das Unternehmen breitet über den gesamten Anlagenpark eine gleichbleibend stabile (oder eher instabile) “Feuerdecke” aus.

Weiterlesen

End-to-end example of process based risk analysis – Part 1

In two preceding articles (Cost cutting by process based risk analysis – Part 1 and Part 2) I have described a process based method that helps us to identify mission critical activities und sub processes. The idea is to find a way that enables us to focus our protective measures on the technical equipment, which is involved in those critical activities. Thereby, we could reduce measures to those sensitive entities rather than protecting any equipment around our premises.

As I was asked for an end-to-end example several times I designed a small process, which is about controlling a business premises of a small refinery. This company has three risks to take care of. In case it happens (not very likely, though) a fire is a massive danger because it could destroy the entire company. An accident regarding an oil leakage is much more probable to happen. But let us assume that the company is able to handle it on its own. Therefore, the severity is not too high. As the company secures its premises with a fence, which is electronically controlled, we will have to manage alarms of that kind as well. This process is located at the central guard duty, which is operated by the company.

Please, consider this as an example. I know it lacks real world’s complexity. No refinery will work that simply. But, as I said, this is only a construct to provide an understanding of this approach. Weiterlesen

Use Cases Teil 1: Nutzerziele und fliegende Fische

Use Cases gehören zum Alltag der IT. Kein größeres Projekt kommt ohne sie aus. Die ganze Welt schreibt Use Cases. Wirklich? Dass ich diesen Artikel schreibe, mag erkennen lassen, dass ich da meine Zweifel habe. Meine These: Viele sogenannte Use Cases sind gar keine. Ich möchte im Folgenden darstellen, wie ich dazu komme. Da das Thema umfangreich ist, teile ich die Betrachtung in zwei Artikel auf:

  1. Differenzierung zwischen Nutzerziel und Unterfunktion.
  2. Wie beschreibe ich ein Nutzerziel (Use Cases Teil 2: Pure Fachlichkeit ist keine Lösung – aber ein gutes Problem).

Der Begriff Use Case lässt sich im Deutschen am besten mit Anwendungsfall übersetzen. Hier passt die wortgetreue Übersetzung sogar ganz gut. Ein Use Case beschreibt, wie ein Nutzer (Aktor) mit einem System in Interaktion tritt, um ein bestimmtes Ziel zu erreichen. Wenn ich hier vom Erreichen eines Ziels spreche, so steckt dahinter zweifelsohne eine Intention. Und die können nur Menschen bzw. Gruppen von Menschen haben. Genau genommen können Use Cases aber auch die Interaktion zwischen verschiedenen Systemen beschreiben. Diese spezielle Form von Use Cases möchte ich hier nicht diskutieren. Mir geht es an dieser Stelle ausschließlich um die Use Cases, die beschreiben, wie ein menschlicher User mit einem System interagiert, um ein fachliches Ziel zu erreichen. Warum ich das fachliche Ziel hervorhebe, lege ich später dar. Weiterlesen

Das Eiserne Dreieck: Ignorieren auf eigene Gefahr

In einem kurzen Video spricht Philippe Back über die drei Aspekte im Projektgeschäft. Das Video ist in Englisch. Ich möchte den Beitrag allen Projektmanagern wärmstens empfehlen. Wenn es im Projekt schief geht, ist das Eiserne Dreieck vermutlich missachtet worden. Ich möchte Philippes Vortrag kurz zusammenfassen.

Die drei Ecken (Aspekte) sind:

  • Scope (also das, was vom Projekt geleistet werden soll)
  • Qualität
  • Zeit

Weiterlesen

Ein weiteres Missverständnis: Usability Tests sind teuer

In einem vorigen Artikel schrieb ich schon über verschiedene Usability-Missverständnisse (Usability – Schluss jetzt mit den Missverständnissen!). Ich möchte die Sammlung noch ein wenig erweitern.

Gerne werden an allen Ecken und Enden Kosten gespart. Und da wird gerne auf Usability Tests verzichtet: “Das hat ja schließlich ein guter Designer entworfen…” Nun, auch Designer sind nur Menschen und können Fehler machen. Die sollte man schon aus Gründen des Investitionsschutzes frühestmöglich aufdecken. Und dazu sind eben Usability Tests da. Doch nun zu den Kosten. Denkt man an solche Tests, fallen häufig Stichwörter wie Usability Labor, Eye Tracking, Erhebungskampagnen, statistische Validierung etc. Ja, das kann alles dazu gehören – muss es aber nicht. Die Buchung und Beauftragung eines professionellen Usability-Labors ist kostenaufwendig. Aber selbst das lohnt sich in den meisten Fällen. Ich möchte hier aber zwei sehr einfache Testmethoden vorstellen, die mit wenig Aufwand durchzuführen sind und dennoch wertvolle Erkenntnisse liefern.

Papierprototypen-Test

Wie zuvor schon kurz erwähnt braucht man für diesen Test noch nicht mal lauffähigen Sourcecode. Es reichen Papierskizzen, die man aus dem Entwurfsprozess (frühe Konzeptionsphase) extrahiert. Diese Skizzen (Mockups) fallen da ja eh an, da man anhand dieser die Benutzerinteraktion durchdenkt und visualisiert. Nun überlegt man, welche Szenarien man mit welchen Nutzern überprüfen möchte. Man wählt die entsprechenden User Interface-Skizzen aus und lädt die Testteilnehmer ein. Eine Auswahl von fünf bis sechs Testteilnehmern sollte reichen. Mehr Teilnehmer erhöhen den Erkenntnisgewinn in der Regel nicht. Und statistisch belastbare Aussagen wird man auch mit 20 Teilnehmern nicht erreichen. Darum geht es aber auch gar nicht. Und wer keine sechs Teilnehmer “loseisen” kann, beschränkt sich eben auf zwei. Lieber einen kleinen Test machen als gar keinen!

Weiterlesen

Ohne UML in die Word-Falle

Über das Management in der UML-Falle habe ich bereits geschrieben. In dem Artikel habe ich darzustellen versucht, dass es eine große Gefahr birgt, wenn man sich in großen Projekten im Rahmen einer Spezifikation auf die Erstellung von UML-Diagrammen beschränkt und auf detaillierte textliche Erklärungen verzichtet. Man hat zwar schöne Fachklassen- und Use Case Diagramme, die gute Übersichten liefern. Die fachlichen Details – und die sind spätestens für die Entwickler unverzichtbar – gehen aber verloren.

Das andere Extrem

Doch es gibt auch das andere Extrem: den Versuch einer kompletten Fachspezifikationen in einem einzigen Dokument. Und das auch noch ohne grafische Übersichten.

Weiterlesen

Usability – Schluss jetzt mit den Missverständnissen!

Der folgende Artikel ist in einem internen Newsletter meines Arbeitgebers Steria Mummert Consulting erschienen. Er wendet sich an Berater und Projektmanager, die in der Regel keine Usability Professionals sind. Dennoch könnte der Artikel auch hier den ein oder anderen interessierten Leser finden. Zusätzlich habe ich einige Links zu anderen Artikeln eingefügt.

Begrifflichkeit: Usability ist ein Kunstwort (use + ability) und beschreibt die Gebrauchstauglichkeit eines Gegenstandes oder einer Software. Usability ist heute kein Luxus mehr sondern eine unumgängliche Voraussetzung für den wirtschaftlichen Erfolg. Leider wird der Begriff von zu vielen als leere Hülse verwendet – mehr als Buzz Word denn als Prio-1-Projektziel. Unter dem Begriff der Usability werden heute auch alle Aktivitäten zusammengefasst, die geeignet sind, eben diese Usability zu erreichen. Begegnen Ihnen Schlagwörter wie User Experience Design, User Interaction Design, User Interface Design, Usability Testing, User Centered Design usw., so hat das alles mit Usability zu tun.

Was kann man um das Thema Usability alles falsch machen? Leider mehr als ich hier aufzeigen kann. Ich möchte im Folgenden nicht auf die Dos and Don’ts des Screen Designs eingehen. Die Liste wäre extrem lang. Jenseits schräger Maskengestaltung und wirren Dialogsalats sehe ich ein gravierendes Problem darin, dass sich um das Thema Usability viele Missverständnisse ranken. Einige möchte ich aufdecken. Vielleicht erreichen wir so eine größere Bereitschaft, in dieses Thema zu investieren und so bessere Software anbieten zu können. Weiterlesen

Das Web-Etwas als Eierlegendewollmilchsau

Als Berater werde ich häufig mit der Frage nach meinem Profil konfrontiert. Das ist ja auch erstmal sehr gut so. Wäre ja schlimm, wenn keiner nach mir fragte. Dann sehe ich einen Auszug aus dem Anforderungsprofil – und rolle mit den Augen.

Da wird nach einem Oberflächenentwickler gesucht, der ausgewiesene Expertise in den Bereichen Usability und Web Accessibility haben soll. Andererseits wird auch mal nach einem GUI-Designer gesucht, der von JavaScript bis php so ziemlich alles beherrscht, was an Scripting-Sprachen auf dem Markt ist. Natürlich das alles kombiniert mit zehn Jahren Erfahrung im Rational Unified Process (RUP) und UML 2.0.

Was wird da eigentlich gesucht? Die Eierlegendewollmilchsau! Keiner wird sagen, dass er das alles gleichermaßen beherrscht. Wie kommt das? Es sind Qualifikationen aus ganz unterschiedlichsten Professionen, die da zusammengeworfen werden.

Stellt Euch folgende klassische Stellenausschreibung vor:
Gesucht wird ein Zimmermann mit erwiesener Erfahrung als Möbelbauer, insbesondere Entwurf und Umsetzung von Intarsien unter Berücksichtigung konstruktiver Gebäudemerkmale.

Weiterlesen