Bei den meisten IT-Projekten wird als erstes über neue Infrastrukturen oder Software gesprochen. Aber auch hier gilt der allgemeine Berater-Ansatz: "Der Kunde soll nicht von der Lösung, die er denkt zu brauchen, erzählen, sondern von den Anforderungen, die eine neue Lösung erfüllen soll!"

Sehr häufig passiert es, dass IT-Verantwortliche etwas bestellen/kaufen von dem sie denken es zu benötigen, es aber den tatsächlichen Bedarf häufig nur in Teilen (oder gar nicht) trifft. Beispielsweise könnte dieses eine Software sein, die nur einen Teil der tatsächlichen Anforderungen erfüllt oder ein Speichersystem das einfach zu langsam für die notwendigen Schreib-/Lese- Zugriffe der darauf gespeicherten Datenbanken ist. All das passiert, wenn keine adäquate Anforderungsanalyse durchgeführt worden ist und diese in die Lösungsfindung einfließt. Bei der Lösungsentwicklung gilt der Grundsatz; eine Lösung darf nicht undersized aber auch nicht oversized sein, sie muss den Anforderungen entsprechen. Dieses verhindert auch unnötige Investition in nicht erforderliche Kapazitäten.

Grundsätzlich gilt bei allen Veränderungen, auch in der IT, eine entsprechende Dokumentationsnotwendigkeit. Viele Unternehmen haben ein tolles Asset-Management, gerne auch ein Konfiguration Management. Sie wissen dann genau wie ihre IT-Landschaft aktuell aussieht. Eine Frage des 'Warum' kann in der Regel aber niemand beantworten. Mit Glück ist es eventuell noch in den Köpfen einzelner Mitarbeiter vorhanden. Aber IT-Betrieb ist keine Glückssache. Wenn von Dokumentation und Konzepten gesprochen wird kommt häufig wenig Begeisterung auf. Dokumentation gilt zu oft als unliebsam. Sie zu erstellen kostet nur Geld (Zeit) und bringt keinen Umsatz oder löst Probleme. Das stimmt, hinsichtlich der Investition in Zeit und Geld, aber das Argument macht eine vernünftige Dokumentation deshalb noch lange nicht unnötig. Die Erfahrung hat gezeigt, vernünftig dokumentierte Veränderungen in der IT haben ein deutliche geringeres Risiko von Ausfällen und Problemen bei der Implementierung, als schlecht oder nicht dokumentierte Veränderungen. Hinzu kommen noch die nachträglichen Veränderungen wenn die Abhängigkeiten der Einzelsysteme untereinander als Teile des Gesamtsystems nicht entsprechend dokumentiert wurde. Dann besteht das Risiko von Ausfällen, selbst bei noch so kleinen Veränderungen.

Bei der Konzept- und Design-Erstellung geht es nicht darum einen Haufen unnötigen Papiers zu produzieren, sondern klar und pragmatisch, in der jeweilig angebrachten Detailschärfe, die Lösung zu beschreiben.

Wurden alle Anforderungen vollständig aufgenommen, bilden sie die Grundlage für das Konzept. 

Hier wird dokumentiert:

Ist das Konzept erstellt, gibt es einen Review Prozess. Ein Konzept muss von allen Stakeholdern entsprechend abgenommen werden. Hier gilt es vor Allem zu klären:

Es gibt IT-Projekte, die können wunderbar mit Agilen (Projektmanagement) Methoden durchgeführt werden. Das hilft dem Business stetig kleine Verbesserungen und Funktionen zu erhalten ohne sehr lange auf die vollständige Lösung zu warten. Dieses ist in der Regel aber Softwareentwicklungsprojekten vorbehalten. Infrastrukturprojekte dagegen haben zwar auch entsprechende Review- und Testzyklen ist eine Hardware aber einmal bestellt ist sie selten kostenneutral veränderbar und wird über die kommenden Jahre abgeschrieben. Infrastrukturprojekte haben dann in der Praxis eher einen Wasserfallansatz im Projektmanagement. Daher ist es um so wichtiger, Veränderungen in der Infrastruktur einem adäquaten Designprozess zu unterwerfen der das Risiko minimiert und die Investitionen schützt. 

Im Logischen Design wird die vollständige Lösung auf logischer Ebene beschrieben, inclusive aller Abhängigkeiten und angrenzenden Technologien. Ein logisches Design hat einen Detaillierungs- und Darstellungsgrad, so dass die Stakeholder die Lösung nachvollziehen und prüfen können, sie aber auch als Grundlage für das Physische Design funktioniert.  Ist der Detaillierungsgrad zu "low-level" besteht das Risiko das es von den Stakeholdern nicht gelesen oder eventuell auch nicht verstanden wird. Ist es zu "high-level" fehlen wichtige Informationen die zur Ableitung des Physischen Design benötigt werden. 

Typischer Weise wird folgendes dokumentiert:

Ändern sich die Anforderungen, ist eine Anpassung des Designs erforderlich. Hier ist die Kritikalität und Umfang einer eventuellen Änderung zu prüfen und zu bewerten. Bei kleinen Änderungen könnte es sein, dass diese kaum Auswirkungen auf die Lösung haben und das Konzept als solches nicht verändern. Es besteht jedoch immer das Risiko das Konzept komplett überarbeiten zu müssen. Dieses sollte aus Gründen der Sorgfalt auch erfolgen und nicht "unbemerkt" irgendwann nur im Logischen Design oder Physichen Design "auftauchen". Veränderungen können erhebliche Auswirkungen auf die Zeitlinie und Kosten von Projekten haben. Die Stakeholder müssen daraufhin entscheiden ob eine Abänderung des Konzeptes verbunden mit einer Zeitverzögerung und/oder Kostenerhöhung des Projektes akzeptabel ist oder die geänderten Anforderungen in keinem Verhältnis zum Aufwand darstellt und das Projekt mit den ursprünglichen Parametern weiterarbeiten soll.

Die Abnahme des logischen Designs erfolgt nicht nur von den Stakeholdern sonder auch von den Verantwortlichen der Betriebsmannschaften, da sie zum einen die Implementierung der Lösung mit begleiten aber auch später den Service für die Lösung übernehmen werden. 

Im Grunde beschreibt das Physische Design die gleichen Komponenten wie das Logische Design und sollte daher auch den gleichen strukturellen Aufbau haben. Der wichtigste Unterschied, im Physischen Design werden die exakten Konfigurationen dokumentiert.

Wenn eine neue Lösung korrekt geplant wird, passt sie auch genau auf die Anforderungen. Es wird keine Investition getätigt die vielleicht passt oder auch nicht oder nur zum Teil. Es ensteht ein Investitionsschutz. "Das was ich kaufe ist auch genau das was ich brauche."

Die tatsächliche Nutzungsdauer der Anlagen erhöht sich. Hat ein Projekt eine vernünftige Designphase ist danach allen Beteiligten klar wie, wo und weshalb die Geräte oder Software konfiguriert werden. Es gibt keine Überraschungen mehr. Wird Infrastruktur ohne eine vernünftige Planung bestellt, können die neuen Geräte noch so gut den Anforderungen entsprechen, häufig scheitert es aber bei der Implementierung an so einfach Dingen wie verfügbare Netzwerkports oder Rackspace in den Standorten/Rechenzentren. Eine genaue Planung lassen auch die ganzen Vorarbeiten zu, so dass Geräte nach ihrer Lieferung unmittelbar angeschlossen und konfiguriert werden können, ohne das dann erst neue Leitungen verlegt werden müssen. In der Realität vergehen bei ungenauer Planung teilweise Monate bis ein System produktiv ist. Jeder Monat Verzögerung bedeutet aber Kosten ohne Nutzen für ein Unternehmen.