Aufwandsschätzung als Kernaufgabe des IT-Managements

Der starke Fokus auf Kosten/Nutzen erfordert eine genauere Planung zukünftiger und post mortem Analyse vergangener Projekte. Das Multiprojektmanagement hat die Aufgabe anstehende Projekte einer einheitlichen Bewertung zu unterziehen. Vor dem Hintergrund knapper Investitionsbudgets stellt sich vor dem Anfang der Projekte die Frage nach strategischer Relevanz und Wirtschaftlichkeit. Die Ertragsmessung von IT-Projekten gilt bis heute zu den größten Herausforderungen. Die Probleme der monetären Quantifizierung von IT-Systemen liegen vor allem in der Darstellung dieser Erträge in Nutzengrößen.[1] Eine weitere Herausforderung besteht darin die Aufwände für diese Projekte im Vorfeld genauer zu schätzen um zugeteilte Ressourcen optimiert auszulasten.  Ein Schätzverfahren für Projekte im MPM muss somit den Anforderungen, Projekte im Vorfeld nach deren Kosten/Nutzen zu bewerten und dem Wunsch nach exakten Informationen, gerecht werden. Valide Schätzungen der zu erwarteten Entwicklungsaufwände sind für IT-Projekte der erste und wichtigste Erfolgsfaktor. Die Genehmigung des Projektes durch das MPM hängt grundlegend von der Wirtschaftlichkeit des geplanten Projektes ab. Der Nutzen muss höher sein als die Kosten, sonst gelangt das Projekt nicht über den Projektantrag hinaus. Die Dringlichkeit einer aufwändigen Schätzung für IT-Projekte wird von den meisten Unternehmen unterschätzt. Der qualitative und kommerzielle Projekterfolg hängt maßgeblich von einer genauen Schätzung ab, mit der Voraussetzung, dass das geplante Produkt möglichst ausführlich spezifiziert ist. Doch gerade in der agilen Entwicklung ist eine möglichst exakte Produktspezifikation, wie sie im Wasserfallmodell zu finden ist, nicht möglich. Statt zu Projektstart auf der Basis eines detaillierten Pflichtenheftes einen fixen Projektplan für die Projektlaufzeit zu erstellen, wird in einem agilen Vorgehen wie SCRUM[2] das Projekt im Release Plan nur grob in Sprints[3] gesplittet, in denen, vom Entwicklerteam, definierte Funktionsumfänge bereitgestellt werden.[4] Fehler in der Schätzung haben in der Regel weitreichende und fatale Auswirkungen auf die Durchführung eines Projektes. Großzügige Schätzungen oder hohe Unsicherheitsgrade die den Blick auf die wesentlichen Aufgaben und Risiken vermeiden, werden für Entwicklungsprojekte schon mit dem Start zu einer hohen Bürde. Das nächsten Abschnitte stellen die gängigsten Schätzmethoden vor.

Übersicht bekannter Schätzmethoden

Die vermeintliche Genauigkeit algorithmischer Verfahren wird hoch gepriesen. In der Projektpraxis vieler Unternehmen werden diese Verfahren aber kaum genutzt. Die nächste Abbildung gibt einen Überblick und eine grobe Klassifizierung der bekanntesten Schätzmethoden.

Klassifizierung

Klassifizierung der Schätzmethoden (in Anlehnung zu [5])

Empirische Schätzmethoden nutzen Erfahrungen und Referenzinformationen aus vergangenen Projekten deren Qualität stark von der Ähnlichkeit und Vergleichbarkeit abgeschlossener Projekte abhängt. Algorithmische Verfahren errechnen den Aufwand für ein Softwareprojekt mit Hilfe mathematischer Formeln und dem Durchlaufen einer Reihe von Schritten.

Analogiemethode

In der Analogiemethode werden Daten aus bereits abgeschlossenen Projekten als Grundlage für das zu schätzende Projekt herangezogen. Die vorherigen Projekte müssen vergleichbar mit dem geplanten Projekt sein. Der Aufwand der in der Vergangenheit angefallen ist, ist für Unterschiede in Aufgabenstellung und Realisierungsbedingungen entsprechend anzupassen. Das umzusetzende Projekt muss hohe Ähnlichkeiten zu bereits durchgeführten Entwicklungen aufweisen. Datenquellen können entweder eine eigene Erfahrungsdatenbank, empirische Untersuchungen oder Benchmarks sein. Die Verwendung der Analogiemethode wird mit einer Abfolge von 3 Schritten beschrieben.[6]

  • Für das zu schätzende Projekt wird die aus der Aufgabenstellung, Umfang und Schwierigkeitsgrad ein Leistungsprofil erstellt.
  • In zweiten Schritt werden die Unterschiede zwischen dem geplanten und dem abgeschlossenen Projekt ermittelt
  • Im letzten Schritt wird das Delta zwischen abgeschlossenem und neuem Projekt bestimmt und bewertet.

Die Vorteile der Analogiemethodik sind die frühe Verfügbarkeit der Ergebnisse und der geringe Aufwand. Trotzdem lassen sich die Zahlen nicht optimal vergleichen weil eine hohe Voraussetzung bezüglich der Qualität der Daten besteht. Diese Methode ist somit für Prototypprojekte ungeeignet da vergleichbare Projekte meistens nicht vorhanden sind.[7]

Agile COCOMO II

Es gibt sehr viele Kostenschätzmodelle die auf Basis des COCOMO Modells entwickelt wurden. Agile COCOMO II ist eine solche Schätzmethode welches vom Center for Software Engineering der Univeristy of Southern California entwickelt wurde. Sie enthält das vollständig parametrische COCOMO Model und ist eine analogiebasierte Schätzung. Die webbasierte Anwendungen ist über die Seite der University of Southern California[8] zu erreichen. Noch gibt es zu dieser Methode zu wenige empirische Untersuchungen die einen Einsatz in der Praxis empfehlen.

Function Point Analyse (FPA)

Die Function Point Analyse (auch –Analyse oder –Methode) wurde in den 1970er und 1980er Jahren von Allan J. Albrecht für das Unternehmen IBM entwickelt. Die FPA misst die Größe einer Anwendung objektiv und unabhängig von technischen Randbedingungen.[9] Alan J. Albrecht hat die Problematik der Codemessung erkannt und führte das Function-Point-Maß ein, welches zur damaligen Funktionsmodellierung mit Funktionsbäumen (HIPO-Diagramm) passte. In einem weiteren Beitrag wurde die Zählmethode näher erläutert[10]. Ziel der FPA war die Eliminierung der Einflüsse, die sich aus der Verwendung unterschiedlicher Programmiersprachen ergeben und eine Schätzung zu einem früheren Zeitpunkt. Ausgangspunkt der Schätzungen sind Funktionen, die die Geschäftsvorfälle aus Sicht der Anwender abdecken sollen. Vorteile durch Function Points:

  • Klar definierte Vorgehensweise
  • Gute Vergleichsmöglichkeit
  • Nicht Lines of Code sondern die Anforderungen stehen im Vordergrund

Nachteile:

  • Anforderungen nicht immer einer Kategorie zuordenbar
  • Großer Aufwand für große Projekte
  • Kategorienaufgliederung veraltet und somit nach objektorientierten Kriterien nicht nachvollziehbar
  • Baukastenprinzip vernachlässigt Abhängigkeiten und Synergien zwischen Programmteilen

Die FPA wurde noch einmal von Barry W. Boehm erweitert indem er den Fokus von der Umsetzungsdauer hin zur Komplexität eines Features verschoben hat. Warum trotzdem das Schätzen der Komplexität, wie man es aus dem Planning Poker in Scrum kennt, nicht weiter verfolgt werden sollte, wird im Blogbeitrag „Schätzmethoden in der Praxis“ unter „Warum Schätzen in abstrakten Maßen nicht ausreicht“ erläutert.

Bewertung der bekanntesten Schätzmethoden

Tendenziell gelten empirische Verfahren als weniger aufwändig, algorithmische Verfahren dafür als genauer und standardisierter.  In der nächsten Tabelle werden die gängigen Bewertungen der wichtigsten Schätzverfahren aufgezeigt. [11]

Methode Komplexität Vorteile Nachteile
Function Points eher hoch Quasistandard, Transparenz Datenbasis nötig, teilw. Subjektiv
COCOMO II mittel bis hoch gut für erste grobe Schätzung, Toolunterstützung Größenbestimmung muss vorliegen
Expertenschätzung gering bis mittel schnell und flexibel Subjektivität, Transparenz
Analogieverfahren gering bis mittel schnell für ähnliche Projekte nicht anwendbar für neuartige Projekte, Datenbasis nötig
Prozentsatzmethode gering früh einsetzbar nach erster Phase Datenbasis nötig, Varianz für neue Projekte

Quellen: [1] Wieczorrek, H. W. & Mertens, P., 2005. Management von IT-Projekten. Berlin Heidelberg: Springe Verlag. , S. 215 – 216)
[2] Scrum (englisch für Gedränge) ist ein Vorgehensmodell der Softwaretechnik. Quelle: Wikipedia
[3] Stellt einen festgelegten Zyklus (Iteration) in der Regel von zwei bis vier Wochen dar, bei dem das Produkt entwickelt wird.
[4]Kesten, R., Müller, A. & Schröder, H., 2012. IT-Controlling. München: Franz Vahlen GmbH.
[5] Plewan, H.-J., 2006. Methodische Aufwandsschätzung aus Sicht eines agilen Projektmanagements. Agiles Projektmanagement, pp. 83-100.
[6] Biethahn, Mucksch & Ruf, 2004. Ganzheitliches Informationsmanagement., S. 208)
[7] Litke, H.-D., 2007. Projektmanagement. München: Hanser.
[8] Agile Cocomo II Sunset.usc.edu
[9] Albrecht, A. J., 1979. Measuring Application Development Productivity, Procedure of Joint SHARE. GUIDE and IBM Symposium, Oktober.
[10] Vgl.  (Albrecht & Gaffney, Software function, source lines of code, and development effort prediction: A software science validation ;, 1983)
[11] Plewan, H.-J., 2006. Methodische Aufwandsschätzung aus Sicht eines agilen Projektmanagements. Agiles Projektmanagement, pp. 83-100.

Schätzmethoden in der agilen Praxis

Gerade für den agilen Projektmanager lohnt sich ein Blick auf einige empirische Studien, wie weit verschiedene Schätzverfahren verbreitet sind. Eine gute Übersicht findet sich in Molokken & Jorgensen, 2003. Auf Basis dieser Daten kann man auf folgende grobe Verbreitung schließen:

 

Abb. 3 Verbreitung der Schätzverfahren[1]

Zwischen 70 % und 80 % der Befragten schätzen die Aufwände mit der Expertenschätzung. In vielen Publikationen werden aber fast umgekehrt proportional die Expertenschätzung nur zu ca. 17 % behandelt.[2] Hier scheint die unternehmerische Praxis weit entfernt von der Theorie zu liegen. Auf die Frage warum die Expertenschätzung so weit verbreitet ist bietet Jorgensen in derselben Studie einige Antworten an. Es gibt danach keinen Beweis dass algorithmische Verfahren genauer als empirische Verfahren bzw. als Expertenschätzungen sind. Die 15 verglichenen Studien zeigen, dass gerade die Expertenschätzung in der Genauigkeit der Schätzungen weit vorne liegt. Fünf Studien sahen die höchste Genauigkeit in der Expertenschätzung, drei in algorithmischen Verfahren und zwei im Analogieverfahren. Die restlichen fünf fielen Unentschieden aus.

Die Expertenschätzung als Einstiegspunkt für zuverlässige Schätzungen

Die Expertenschätzung ist ein Prognoseverfahren bei dem das Wissen eines ausgewählten Personenkreises genutzt wird.  Die Expertenschätzung ist gleichzeitig die am weitesten verbreitete Schätzmethode. Sie gilt als weniger aufwändig aber dafür ist sie nicht standardisiert weil standardisierte Verfahren auf einem definierten Prozess mit geprüften und einheitlichen Eingangsparametern beruhen.[3]

Der Expertenschätzung sollte zu Beginn zumindest ein einfaches Regelwerk wie sie in Conboy’s Cost Estimation in Agile Software Projects[4] und Jorgensens Practical Guidelines for Expert-Judgement-Based Software Effort Estimation[5] beschrieben, vorgelegt werden.

  • Keine Vermischung von Schätzung, Planung und Angebotserstellung
  • Beteiligung von Entwicklern und Managern
  • Beteiligung von Schätzern mit ähnlichen Projekterfahrungen
  • Schätzergebnisse kombinieren
  • Begründung jeder Schätzung
  • Erst schätzen, wenn die Anforderungen festgelegt sind
  • Dokumentation der Erfahrungen.

Warum Schätzen in abstrakten Maßen nicht ausreicht

Ein wichtiger Unterschied zu klassischen Schätzverfahren liegt zunächst in der Unterscheidung zwischen Komplexität und Aufwand. In vielen Büchern der agilen Softwareentwicklung wird empfohlen die User-Stories in Komplexität zu schätzen weil diese besser zu handhaben sind. In der agilen Projektpraxis wurde aber die Erfahrung gemacht, dass man sich zwar immer auf bestimmte User-Stories bzw. Komplexitäten „committet“ (geeinigt) hat, jedoch war für das Multiprojektmanagement der Nutzen oder der Aufwand eines Komplexitätspunktes nicht greifbar. Deswegen ist die Messung der Team Velocity[6] unumgänglich um später sagen zu können: „ Unser Team schafft 74 Story-Points pro Sprint (10 Tage)“. Der Umfang eines fachlichen Features lässt sich in einem abstrakten Komplexitätsmaß (z.B. Function Points) ausdrücken. Der Aufwand zur Umsetzung leitet sich dann aus weiteren Faktoren ab. Die Umrechnung in Aufwand muss somit auch mit in die Schätzung einfließen.

Planning Poker auf Basis von Story Points

Die Planning Poker Methode ist eine sehr einfache Methode, um Backlog Items oder User Stories zu schätzen und findet im SCRUM seine Anwendung. Sie nimmt verhältnismäßig kurze Zeit in Anspruch und beruht auf der Expertenschätzung. Nach dem die Anforderungen mit Hilfe einer Story Map in User Stories zerlegt worden sind, werden diese in Story Points geschätzt, die relative Schätzungen der Komplexität, des Aufwands oder der Dauer einer Story sind. Die Schätzung muss im Team erfolgen die dann auch verantwortlich für diese Schätzung ist.[7] Planning Poker wird mit Planning-Poker-Karten gespielt.  Dazu bekommt jedes Teammitglied ein Kartenset die mit der unreinen Fibonacci-Reihe nach Cohn (0, 1, 2, 3, 5, 8, 13, 20, 40, 100) nummeriert sind. Eine User Story wird dann ausgewählt und vom Product Owner beschrieben und eventuelle Fragen geklärt. Wenn alle Fragen geklärt sind, wählt jedes Teammitglied eine Karte aus, die den Wert repräsentiert, der diesem Teammitglied als korrekt erscheint. Erst wenn alle Mitglieder sich entschieden haben, werden die Karten gleichzeitig aufgedeckt. Die beiden Teammitglieder mit dem höchsten und dem niedrigsten Schätzwert erläutern wie sie auf die jeweiligen Werte gekommen sind. Durch diese Erläuterungen und dem Informationsaustausch werden Dinge klargestellt die evtl. noch geklärt werden müssen. Die Schätzung wird daraufhin wiederholt. In der Regel sind die Zahlen dann angeglichen. Der Moderator fragt dann, ob man sich auf den am meisten genannten Wert einigen kann. Ist dies der Fall wird die User Story mit den Story Points versehen. Dieses Verfahren gibt gute Schätzwerte ab, jedoch sollte zu Beginn einer solchen Schätzung die einzelnen Werte klar definiert werden. Eine gute Möglichkeit ist es, wenn das Team sich auf eine Beispielhafte User Story mit einem Story Point einigt. Diese „Prototyp Story“ muss auch nach dem Zeitaufwand bewertet werden. Dies erfolgt durch Erfahrungswerte aus früheren Sprints oder der Team Velocity.



[1] (Molokken & Jorgensen, 2003)

[2] Vgl.  (Jorgensen, A Review of Studies on Expert Estimation of Software Development Effort, 2004)

[3] (Buglione & Abran, 2007, S. 273)

[4] Vgl.  (Conboy & Keaveney, 2005)

[5] Vgl.  (Jorgensen, 2005)

[6] Team Geschwindigkeit

[7] Vgl. (Cohn, 2010, S. 107)

Ja zu Aufwandsschätzungen – aber wann?

Der richtige Zeitpunkt der Aufwandsschätzung ist ein wichtiger Aspekt für jedes Software-Entwicklungsprojekt. Voraussichtliche Aufwände sollen möglichst früh und möglichst genau geschätzt werden. Die erste Aufwandsschätzung wird von den Projektmanagern meistens sehr früh eingefordert. Meistens sind das aber Schätzwerte die zu ungenau sind. Die Cone of Uncertainty, eine Verlaufsbeschreibung von Unsicherheiten in einem Projekt, besagt, dass eine Schätzung vor der Anforderungsphase im Durchschnitt noch mit einer Unsicherheit von Faktor 4 belastet ist. Die Varianz von 4x bis 0,25 bedeutet, dass ein auf 12 Monate geschätztes Projekt am Ende tatsächlich zwischen 3 und 48 Monate dauern kann.[1]

Cone of Uncertainty[2]

Infolgedessen verweigern die Entwickler Aussagen zu jeglichen Aufwänden um bei einem Scheitern die Konsequenzen einer verbindlichen Schätzung zu umgehen. Eine verbindliche Schätzung wird in der mir bekannten Praxis generell nicht gegeben, trotzdem werden die Entwickler wegen Aussagen wie „Wir werden ungefähr zu diesem Zeitpunkt fertig“ an die Wand genagelt, wenn dieser Zeitpunkt überschritten wird.

Trotzdem ist es wichtig, dass die Entwickler beziehungsweise der Projektleiter eine Schätzung am Anfang eines Projektes abgeben. Diese Angaben sind wichtig für die Projek- und Ressourcenplanung. Agile Teams schätzen Aufwände nur für kurze Sprints, diese reichen aber für eine langfristige Projektplanung nicht aus. Beiden Parteien, dem Programm- oder Multiprojektmanagement und den Entwicklern muss die Unsicherheit einer Schätzung bewusst sein. Mit einer strukturierten Vorprojektphase die konform mit den agilen Prinzipien ist, können zudem die Unsicherheitsfaktoren (auch wenn es nur zu einem geringen Teil ist) gemindert werden. Diese Schätzungen sollten mit jedem Sprint oder Meilenstein nachjustiert werden.



[1] Vgl. (McConnell, 1997)

[2] Quelle Microsoft.com

Day 6: Las Vegas.2

Wieder in Las Vegas angekommen. Diesmal in das Hotel Stratosphere mit dem höchsten Gebäude in Las Vegas.
Der Check-In war wieder mal direkt im Casino. Die Rezeptionistin war so freundlich und gab uns ein Zimmer in den oberen Stockwerken.
Das Hotelzimmer war diesmal überdimensional. Die Suite hatte einen wundervollen Ausblick auf den Strip inklusive Whirlpool. Für Entspannung war aber keine Zeit, zuerst wollten wir uns die Gegend um das Stratosphere anschauen. Dieser Trip ging aber ganz kurz. Nach den ersten 20 Metern vom Hotel entfernt kommen einem betrunkene Gruppen entgegen, man wird von Dealern angesprochen ob man Drogen jeder Art kaufen möchte.
Ohne Drogen zu kaufen und ausgeraubt worden zu sein kehrten wir um, denn wir hatten im preisgekrönten Restaurant „Top of the World“ einen Tisch reserviert. Dieser befindet sich an der Turmspitze und die Tische stehen auf einer sich langsam drehenden Plattform. Hier sollte man sich für einen der Tische direkt am Fenster bemühen, ist zwar mit etwas längeren Wartezeiten verbunden, aber man bekommt von den Angestellten einen Pager der dann vibriert wenn ein Tisch frei geworden ist. Die Zeit überbrückt man dann in der Lounge welcher sich ein Stockwerk über dem Restaurant befindet. Die Aussicht vom Restaurant ist sehr schön und man blickt über das Lichtermeer von Las Vegas.
Ab und an fliegen Bungee Jumper vorbei was für manche Schrecksekunden sorgt. Man begegnet hier einsamen Hochzeitspärchen die ihre schnelle, vielleicht auch unüberlegte Trauung feiern und die Business-Elite von Las Vegas. Hier gab es den besten Steak den ich bis dato gegessen habe, es war die Empfehlung des besten und einarmigen Kellners: Prime Creekstone Farm New York Steak with Peppercorn Sauce.

5.Day: Zion National Park

Erleuchtung. Etwas anderes kann ich zu dem was ich gesehen habe nicht sagen.

Der Zion National Park liegt ca. 170 km nördlich vom Grand Canyon. Unser Hotel in Page war das Comfort Inn & Suites Page. Auf dem Weg haben wir eine düstere Strecke hinter uns gelassen. Je näher man an den Zion National Park gekommen ist, umso mehr tote Rehe lagen am Straßenrand.

Nach dem 18. Kadaver haben wir aufgehört zu zählen. Es machte den Anschein als seien diese Tiere von vorbeifahrenden Autos gerammt, zuerst haben wir an Jäger gedacht aber dies ist recht unwahrscheinlich. Ab dem Entry Schild zum Nationalpark färbte sich der Asphalt im charakteristischen Rot. Es ging ca. 30 Minuten lang bergab. Hier haben wir kurz vor der Einfahrt zum ersten Tunnel einen View Point entdeckt, jedoch gab es keine Möglichkeit umzukehren. Somit haben wir beschlossen, wenn wir wieder diese Straße zurückfahren sollten werden wir uns das auf alle Fälle anschauen.
Der Zion National Park ist eines der schönsten Orte an dem ich war. Eine Wanderung am kleinen Bach entlang – unberührte Landschaft – Kletterpartien. Alles was das Herz begehrt.
Man bemerkt immer wieder am Straßenrand parkende Autos – hier sollte man selbst auch halten und zumindest mal schauen ob es da was zu entdecken kann. Nach Grand Canyon ging diese Taktik auf und wir entdeckten unglaublich schöne Orte an denen man sonst vorbeigefahren wäre.
Aber egal was man im Zion erlebt und entdeckt, obwohl unsere Route durch den Zion National Park weiter ging, entschieden wir uns doch noch einmal umzukehren und die halbe Stunde Strecke zum vorher erwähnten View Point auf uns zu nehmen.
Hat es sich gelohnt?
Verdammte Sch….e – JA

Hier läuft und klettert man einen langen Pfad durch bergige Landschaften und Schluchten. Manchmal weiß man nicht wohin und versucht Fußabdrücke zu finden. Es ist der menschliche Instinkt der einen den richtigen Weg finden lässt. Auf einer unscheinbaren Anhöhe begegnet man 7 Stufen. Mit Led Zeppelins Worten zu sagen „Stairway to Heaven“.

Steigt man diese Stufen hoch begegnet man der Erleuchtung mit dem ich diesen Beitrag begonnen habe. Jetzt hat sich die Amerika Reise gelohnt.

4.Day: Grand Canyon

UN-GLAUB-LICH
Da wir für einen Besuch im Grand Canyon relativ unvorbereitet waren sind wir in Tusayan erst einmal zur Touristeninformation gegangen. Ich dachte immer, dass man so etwas doch spielend einfach selbst organisieren kann. Die Infos die wir da bekamen waren Gold wert. Er stattete uns mit einer Karte aus redete am Anfang irgend ein wirres Zeug und machte irgendwelche Kreuze und Notizen rein. Männer können bekanntlich nicht zwei Dinge auf einmal machen – hier wurde diese Theorie noch einmal bestätigt. Eine abschließende Frage habe ich ihm gestellt, welches ich euch im Wortlaut (übersetzt natürlich) mitteilen möchte:

Ich: Wie soll ich meinen Tag gestalten? Weil wir wollen noch Antilope Canyon besichtigen.
Er: Wie meinst du das?
Ich: Ich meine, soll ich die Hälfte des Tages hier verbringen und die Hälfte des Tages Antilope Canyon? Oder soll ich Grand Canyon länger einplanen und nur einen kurzen Abstecher nach Antilope machen?
Er: Du kommst an den Grand Canyon, stellst dich dorthin…dann erlebst du diese gigantische Aussicht. Wenn du dich dann innerhalb einem Tag von diesem Wunder losreißen kannst – dann kannst du noch zum Antilope Canyon gehen.

Am Ende des Tages haben wir Antilope Canyon nicht besucht!

Ich bin heute wirklich einem Wunder begegnet. Grand Canyon kennt man zwar von Filmen, Fotos und Erzählungen. Das Erlebnis kann aber weder mit Erzählungen, noch mit Fotos beschrieben werden. Man muss es wirklich selbst gesehen haben. Wir fuhren gestern die ganze Zeit durch eine flache Landschaft Richtung Tusayan, man sah einen kleinen Hügel weit weit weg und wir dachten uns „Das kann doch nicht der Grand Canyon sein“ da ist ja unser Hügel in der Ortschaft größer. Aber dort anzukommen und vor einer Riesen-Kraterlandschaft zu stehen hätten wir nicht erwartet. Wir fuhren erst auf den Parkplatz vom Grand Canyon Visitor Center – der Eintritt ohne Annual Pass kostet pro Fahrzeug um die 25 $. Von hier, hat uns unser Touristeninformant geraten, sollen wir den Fußpfad nehmen der gute 1-1,5 Stunden dauert. Es hat sich zu 100 Prozent gelohnt. Diese Route ist sehr gut zu laufen, asphaltierte Wege und Aussichtsplattformen, für Mutige gab es auch Stellen die nicht abgesichert waren. Aber man bedenke – die meisten Unfälle passieren an Stellen die abseits vom Pfad sind. Deswegen sollte man hier sehr vorsichtig sein und für einen tollen Schnappschuss nicht sein Leben riskieren.
Der Ausblick ist wirklich überwältigend – man muß jedesmal wenn man kurz stehen bleibt und in die Ferne blickt tief einatmen.

Wie vorhin schon beschrieben kann man es nicht beschreiben – auch mit den Fotos die ich jetzt hinzufüge wird es nicht anders werden. Trotzdem kann ich ja einen Versuch starten.

Weiter Richtung Westen gibt es noch den Grand View Point mit einem alten Aussichtsturm mit Indianer-Kunstwerken bemalt, während der Autofahrt gibt es immer lohnenswerte „View Points“ an denen man auf jeden Fall anhalten sollte. Hier gibt es immer besondere Aussichtsplattformen die es Wert sind gesehen zu werden.

Wir sind dann noch zu den Antilopes gefahren, habe dort auch im Touristenzentrum gefragt (bekommt man ja wertvolle Tipps) und die Dame meinte, man könne für eine Stunde hin, aber die charakteristischen Sonnenstrahlen die in diesen Canyon fallen und den Felsformationen rot leuchten lassen, sind um diese Jahreszeit leider nicht vorhanden.
Es war auch schon spät – also entschieden wir uns diese Station zu überspringen und weiter zum nächsten Hotel in Page zu fahren, denn morgen steht Zion National Park auf dem Plan.

 

3.Day: Hoover Damm

Da wir heute später als geplant losgefahren sind werden wir Grand Canyon erst am 4. Tag besichtigen. Dafür besuchen wir heute den Hoover Damm und fahren über einen Umweg über die Route-66 nach Tusayan ins Best Western
Den Hoover Damm haben wir am Ende gerade einmal 30 Minuten besucht. Die Aussicht von der Autobahnbrücke aus ist sehr empfehlenswert.

Die Route 66 ist eine Straße. (Punkt)
Die passende Musik, die passende Zeit, das passende Gefährt – Ok. dann ist sie vielleicht ein bisschen mehr. Aber zu einem WOW Effekt im Jahre 2013 wo die Route 66 nur noch als Umweg gilt hat es nicht gereicht. Ich möchte keinem Route-66 Fanatiker zu nahe treten, es ist eine schöne Strecke aber kein „Poah Hammer, voll das coole Feeling“ Gefühl.

Am Abend waren wir dann in Tusayan. In Amerika habe ich bis heute nichts gescheites gegessen gehabt – bis wir zufällig über diesen Mexikaner gestolpert sind. „Plaza Bonita“ rundum alles perfekt gewesen. Außer die Getränke, mir ist aufgefallen, dass alle offenen Getränke halb oder ganz voll von den Gästen zurückgelassen werden. Leider ist mir das erst nachdem wir die Getränke bestellt und bekommen haben aufgefallen. Das Wasser mit denen die Cola oder Sprite-Konzentrate gemischt werden schmeckt schrecklich nach aufbereitetem Wasser oder als wären die Leitungen noch aus den Zeiten des wilden Westens. Das Essen aber war köstlich. Steak und Chicken. Zwar sehr dünn aber geschmacklich fast nicht zu toppen.

Das Hotel ist besser wie vom Excalibur in Las Vegas. Sehr gepflegt und top ausgestattet.
So ging der Tag dann auch seinem Ende entgegen. Am nächsten Tag ist dann endlich Grand Canyon an der Reihe.

2.Day: Las Vegas

Dieser Tag in Vegas ging für die meisten morgens um 6 zu Ende. Für uns hat er erst begonnen. Den Jetlag fast überwunden, sind wir morgens um 4 hellwach gewesen. Das erste woran ich gedacht habe? Kaffe!
Im Excalibur gibt es an jeder Ecke Café Shops. Das Casino ist sogar morgens um 6 Uhr unglaublich voll. Liegt wohl daran, dass es in den Casinoräumen keine einzigen Fenster gibt, auch die Türen nach außen sind abgedunkelt.
Ab 9:00 hieß es dann erst einmal frühstücken gehen. Das haben wir im Las Vegas Premiu Outlet South erledigt – es gab Kebob ( was bei uns in Deutschland Kebab nennen). Es gibt mehr als genug Einkaufsmöglichkeiten hier. Jedem zu empfehlen.

Bevor es dann draußen doch zu heiß wurde ging es wieder zurück an den Pool im Excalibur. Eindruck? Lassen wir das lieber! Für ein Sonnenbad ist es ok, aber das Wasser und der teils schmierige Boden ( wahrscheinlich Überreste von den Partynächten ) lassen es ein Kurzaufenthalt werden.

Nach dem Pool Aufenthalt bei ca 32 Grad ging es ins Nachtleben. Zuerst ging es ins direkt gegenüberliegende Luxor. Hier ist der Vorteil zu Ägypten: In die Pyramide kommt man kostenlos rein. Alles sehr edel und ein eher älteres Publikum. Getoppt konnte das nur noch von Mandalay Bay! Ich glaube, wenn es in Las Vegas DIE Adresse gibt, dann ist es das Mandalay Bay – Prunk und Luxus überall wo man hinblickt. So stellt man sich ein Casino vor – die Unterschiede sind wie Tag und Nacht. Das Casino im Excalibur ist zwar nett anzusehen aber es hatte ein etwas schmuddeligen Touch – fühlte sich an wie eine überdimensionale deutsche Spielhalle in Mallorca. Im Mandalay Bay schaut man aufmerksam um sich herum ob man nicht zufällig Robert De Niro begegnet. Hier kann man das Feeling von Goodfellas und Casino hautnah miterleben.

Am nächsten Tag geht es für uns nach Tusayan ins Best Western Hotel. Von hier aus ist es ein Katzensprung zum Grand Canyon. Sind gespannt!

1.Day: Las Vegas

image

Viva Las Vegas heißt uns willkommen. Eingecheckt im Hotel Excalibur. Nach einem anstrengenden Flug mit US-Airways nach Philadelphia gings nach der Immigration inkl. 2nd. Level Security Check mit einem Inlandflug nach Las Vegas. Das Erste was mir auffällt sind die relativ jungen Stewardess. Alle im Schnitt von 50 Jahren. (Ironie endet hier) Finde ich persönlich sehr positiv-im Inlandflug hatten wir einen um die 55 Jahre alten Steward, bin bis jetzt mit Abstand keinem freundlicherem Personal begegnet. Das wichtigste Mitbringsel bis jetzt, sind die Ohropax (Baby on Board) was zu neidischen Blicken geführt hat – als wäre ich mit einem Ferrari vorgefahren. Tja, Understatements müssen nicht gleich 250.000 € kosten.
Nackenkissen und eigene Kopfhörer waren auch sehr praktisch (einfacher Standard Klinkenanschluss). Vom ersten Eindruck kann ich nur berichten, dass wenn man vom Flugzeug aussteigt einem die Spielautomaten direkt reingrätschen. Zur Gepäckausgabe kommt man über eine Tram. Den Mietwagenschalter erreicht man über einen Shuttleservice(Ausgang 11).
Die Check-Ins im Excalibur kann man nicht mit anderen Check-Ins vergleichen, die Schalter befinden sich direkt am Hotel Casino und macht den Eindruck einer Massenabfertigung von partywütigen Mittzwanzigern. Das Hotel ist auch in anderen Punkten nicht mit anderen mir bekannten Hotels zu vergleichen, man wird mit Farben und Klingeln und lachend kreischenden Tönen überflutet. Trotzdem sind alle Bediensteten immer sehr freundlich und zuvorkommend.

Nachdem wir die Gepäckstücke ins Zimmer getan haben machten wir uns auf um die Stadt der Sünden zu erkunden. Die berühmtesten Hotels sind alle direkt nebenaneinder gereiht. Angrenzend zum Excalibur ist das MGM Grand Hotel, New York New York, Luxor, Mandalay Bay usw. Man ist sehr selten draußen auf der Straße, denn die Hotels erreicht man nahtlos über Brücken oder Durchgängen. Die Leute sollen ja schließlich keine Minute ohne Geld auszugeben verbringen. Leider (oder zum Glück) fehlte uns die Erfahrung im Casino und Spielautomatengeschäft, weswegen es uns nicht gereizt hat unser ganzes Vermögen auf Rot zu setzen. Las Vegas entwickelt sich aber mehr und mehr in eine Entertainment-Stadt. Mit unzähligen Shows wie Cirque de Soleil, Titanic, Blue Man Group, Copperfield, Celine Dion, Michael Jackson One versuchen die Hotels die Menschenmasse zu unterhalten. Leider hatten wir keinen Platz mehr für Cirque de Soleil. Vielleicht bekommen wir in knapp 4 Tagen wieder da sind.
Nachdem uns die Müdigkeit wieder zurück ins Hotelzimmer gelockt hat wollte ich am nächsten Morgen mal kurz das amerikanische Fernsehen näher kennenlernen. Hier war dann gleich in den Breaking News eine Schießerei im Bally’s Hotel (auch direkt am Strip) vor dem Nachtclub mit 3 Toten. Welcome to Vegas.