Wymienione zadania mają wiele wspólnego z planowaniem działań, analizą ryzyka, zapewnieniem jakości itd. Wszystkie nieustannie przewijają się przez projekt w fazie realizacji i trudno je formalnie wyróżnić, tym bardziej że właściwą strukturę zarządzania konfiguracją tworzy hierarchia zadań, kompetencji i odpowiedzialności za projekt i poszczególne jego produkty. Programista ma praktycznie wolną rękę we wprowadzaniu zmian do swojego modułu, pod warunkiem że nie wpływają one na uzgodniony w projekcie interfejs modułu. Zmiana interfejsu lub inne działania o większym zakresie wymagają koordynacji i zgody szefa zespołu programistów, czuwającego nad pewnym, większym pakietem lub podsystemem przyszłego produktu. Kierownik zespołu programistów musi z kolei uzgadniać zmiany z koordynatorem odpowiedzialnym za integrację podsystemów itd. Na każdym poziomie znajduje się osoba, która ma prawo zatwierdzać zmiany w projekcie stosownie do swoich kompetencji i zakresu prac, za które odpowiada. Osoba ta ma także obowiązek dopilnowania, aby wszelkie zmiany były odpowiednio raportowane i archiwizowane, a te, które zostały przyjęte do realizacji, także monitorowane, aż do momentu ich ostatecznego wprowadzenia.

Przy takim ujęciu problemu, zespół ds. zarządzania konfiguracją jest "rozproszony" w całym projekcie, składając się z różnych osób w hierarchii projektu, spełniających określone zadania na swoim "odcinku pracy". Mimo to, praktyczne jest wyróżnienie na najwyższych poziomach projektu wyspecjalizowanego ciała formalnie koordynującego wszystkie działania, tzw. kolegium ds. zmian projektowych. Głównym zadaniem kolegium, w odróżnieniu od zadań dotychczas opisanych, jest ocena i autoryzacja zmian projektowych w szerszym kontekście.

Praktycy zarządzania konfiguracją formułują następujące zasady, którymi należy kierować się podczas planowania związanych z nią działań i zespołów:

Autoryzacja zmian - wszelkie zmiany na każdym poziomie projektu muszą być zatwierdzone do realizacji przez osoby wyznaczone, jako odpowiedzialne za zmiany.

Jednoosobowa odpowiedzialność - każda decyzja o wprowadzeniu zmiany musi być zatwierdzona przez konkretną osobę, która bierze za nią odpowiedzialność. W praktyce podstawy do takiej decyzji są zawsze wypracowywane kolegialnie, opiniowane przez ekspertów itd. Podjęcie decyzji jest jednak zawsze jednoosobowe.

Specjalizacja - każda osoba odpowiedzialna za zmiany musi mieć podany zakres swoich kompetencji, tzn. określony produkt, fazę projektową, za którą bezpośrednio odpowiada. Nie może podejmować decyzji o zmianach w obszarach leżących poza jej odpowiedzialnością.

Racjonalizacja - z pewnymi decyzjami dotyczącymi szczególnie ważnych modyfikacji projektu nie wolno się spieszyć. Wymagają one zastanowienia, licznych konsultacji itd. Należy jednak zawsze wyważyć ryzyko niepowodzenia, koszt i czas wprowadzenia zmian, jak i podobne atrybuty ich zaniechania lub opóźnienia. Szczególnie ważne jest, aby szybko ustosunkowywać się do propozycji zgłaszanych przez użytkownika systemu, gdyż tutaj "czas odpowiedzi" ma największe znaczenie.

Po zaplanowaniu systemu zarządzania konfiguracją i wypełnieniu go początkową informacją projektową, zaczyna on żyć własnym życiem, którego główną misją jest uaktualnianie zawartości. Może być ono skutkiem zgłaszania różnych zmian w elementach konfiguracji projektu.

Zgłoszenia niezgodności

Niezgodności są to zmiany zgłaszane zwykle w wyniku oceny działającego oprogramowania lub produktów poszczególnych etapów jego realizacji. Dotyczą one zwykle:

Błędów w wymaganiach - na skutek złego rozpoznania wymagań, oprogramowanie (produkt) zawiera błędy.

Błędów w projekcie - są to błędy popełnione w fazie projektowania i implementowania poprawnych wymagań.

Naruszenia standardów - są to wszelkie przekroczenia zewnętrznych lub wewnętrznych standardów, wytycznych, procedur dotyczących planowanych działań oraz produktów pośrednich i końcowych.