IT Projekte haben den Ruf sehr kostenintensiv zu sein. Und das zu Recht! Falsche Herangehensweisen und falsche Erwartungen stehen dem Erfolg von IT Projekten im Weg. Wir unterstützten sie besser zu verstehen warum dies so ist, und wie geeignete konkrete Kostenbegrenzungsmaßnahmen aussehen damit sie ihre IT Projekte erfolgreich realisieren können.

Wir stellen ein Tool zum Abschätzen der realen Entwicklungszeit zur Verfügung. Dort sehen sie welche Projektparameter welchen Einfluß auf die Kosten eines IT Projektes haben.

Die IT Technologie befindet sich in einer sehr volatilen Entwicklung. Andere "Gewerken" sind über Jahrhunderte gereift und man kann dort auf ein stabiles Grundgerüst an Best-Practice Ansätzen zurückgreifen. In der Softwareentwicklung gibt es dieses stabiles Grundgerüst nicht. Ausnahme sind die mathematischen und algorithmischen Grundlagen.

Aus der sich entwickelnden IT Technologie ergeben sich immer neue Business Cases, was zu neuen Business Anforderungen führt.

Sowohl die sich verändernde IT Technologie als auch die sich verändernden Business Anforderungen nehmen an Komplexität zu. Als Antwort versucht man passende Vorgehensmodelle für die Softwareentwicklung zu finden.

In Summe bedeutet dies, dass IT Technologie, Business Anforderungen und Vorgehensmodelle einer permanenten Entwicklung unterworfen sind.

Sowohl das vermitteltes Fachwissen Wissen an den Hochschulen als auch Best Practice Lektüre haben daher nicht die Bedeutung wie in anderen "Gewerken". Bei der Auswahl an Mitarbeiter wird oft zu viel Wert auf Kenntnisse in konkreten Technologien und Vorgehensmodelle gelegt, statt auf analytisches Denken, selbständigen Arbeiten und Einarbeitungsfähigkeit.

Es ist wichtig zu erkennen, dass das grundsätzliche Problem, die sich kontinuierlich verändernden Technologien, Business Anforderungen und Vorgehensmodelle nicht gelöst werden kann. Stattdessen muss man Prozesse und Herangehensweisen festlegen, welche mit diesem Verhalten umgehen können:

Alle Aufgabenbereiche eines IT Projektes müssen adäquat besetzt sein. Ein Product Owner ersetzt keine Scrum Master.

Weiterführende Informationen: