Mit dem Satztyp "Project" kann die Erstellung eines aktuellen Produktrelease überwacht werden. Dieser Datensatz kann einen Produktnamen, Informationen zum Release sowie die Gruppe aller dem Projekt zugeordneten Iterationen enthalten. Außerdem kann er Informationen zu den Komponenten eines Projekts enthalten.
Jedes Mal, wenn der Quellcode geändert wird, wird ein Build der Anwendung erstellt und geprüft, ob die Qualität der Anwendung für einen Test ausreicht. Ist das der Fall, wird der Build auf den Testservern für den Test implementiert. Dieses Muster, nach dem Codeänderungen bereitgestellt, Builds der Anwendung erstellt und Anwendungstests durchgeführt werden, hat unabhängig vom Umfang oder von der Größe eines Release Gültigkeit (z. B. großangelegte Überprüfung einer vorhandenen Anwendung, Patch-Code oder Hotfix). Treten Fehler auf, werden diese protokolliert, und der Quellcode wird zur Fehlerbehebung geändert. Anschließend muss die Anwendung erneut erstellt und wieder auf den Testservern implementiert werden.
Die ALM-Datensätze Baseline und Build können für Projekte, die UCM-Integrationen (Unified Change Management) von IBM Rational ClearCase bzw. ClearQuest nutzen, verwendet werden, aber auch für Projekte, bei denen das nicht der Fall ist. Diese Datensätze können auch verwendet werden, um sicherzustellen, dass Projekte, Produktreleases oder Informationen für Kunden ordnungsgemäß bereitgestellt werden. Beispielsweise kann mit diesen Datensätzen die Übertragung von Informationen aus dem Entwicklungs- in den Testbereich automatisiert werden, d. h., die Tester werden darüber informiert, welche Produkt-Builds die Fixes für bestimmte Anforderungen enthalten.
In diesem Muster stehen alle Aktivitäten in Beziehung zueinander. Während Entwickler Funktionen implementieren und Fehler korrigieren, müssen die Releaseentwickler wissen, welcher Quellcode in den Build eingefügt oder wann der Build erstellt werden soll (d. h., wenn die gesamte erwartete Arbeit abgeschlossen ist). Wenn Probleme mit dem Build auftreten, müssen die Releaseentwickler feststellen, ob die Ursache im Build-Script selbst zu suchen ist oder ob ein Fehler vom Entwicklungsteam verursacht wurde. Gleichzeitig müssen die Tester wissen, wann ein geeigneter Build getestet werden kann, welche Funktionen im Build enthalten sind und welche Tests für den Build auszuführen sind. Jedes Mal, wenn ein Fehler gemeldet wird, müssen Angaben zu den Testfällen, in denen der Fehler ermittelt wurde, gemacht werden, die auch Rückverweise auf die ursprüngliche Anforderung enthalten. Wenn der Entwickler den Fehler behebt und den Code bereitstellt, beginnt der Zyklus erneut.
In Softwareentwicklungsprojekten werden ständig neue Builds erstellt. Alle Entwicklungsteams müssen sich dieselben Frage stellen, nämlich, was im Build implementiert und was getestet werden soll. Im Datensatz Build können Teams Informationen zu einem Build, einschließlich des Build-Status, erfassen. Mit dem Datensatz Baseline kann nachvollzogen werden, welche Aktivitäten in jedem Build bereitgestellt werden. Außerdem kann der Status bestimmter Aktivitäten zu einem bestimmten Zeitpunkt überprüft werden. Über die Datensätze "Baseline", "Build" und "Activity" können Tester sich darüber informieren, was getestet werden soll und welche Tests bereits für den Build ausgeführt wurden.