Projekt informatyczny w całej jego rozciągłości da się porównać do skomplikowanej maszyny składającej się z przeróżnych trybików, przekładni, silników i pasów transmisyjnych. Nie można jednak zapomnieć, że w przestrzeni projektowej każdy detal ma znaczenie, a co najważniejsze – głos w procesie zarządzania projektem.
Kontekst wpływu programisty na realizowany przez niego projekt jest najczęściej osadzony w dziedzinie jego umiejętności wytwarzania lub testowania oprogramowania. Za chleb powszedni podstawowego pracownika uważa się więc dostarczenie lub sprawdzenie określonych w planie rozwiązań, względnie przedyskutowanie i określenie obszaru prac prowadzonych w danej iteracji projektu – i to w zasadzie tyle, jeśli chodzi o klasyczny zakres obowiązków dewelopera. Pozostałe obowiązki, w tym ogólnie ujęte „prowadzenie projektu”, scedowane są na kierowników szczebli wszelakich. Czy wyraźnie postawiona granica jest korzystna biznesowo, czy po prostu wygodna tak dla programistów jak i kierowników?
Stosowanie jasnego rozgraniczenia odpowiedzialności z pewnością poprawia przejrzystość hierarchii organizacji. Niezazębiające się obowiązki poszczególnych ról w projekcie brzmią jak marzenie każdego kierownika – wiadomymi są adresaci różnego rodzaju pytań technicznych, biznesowych czy infrastrukturalnych. Ciężko jest jednak uzyskać pełen obraz sytuacji, bazując jedynie na statusie prac nad postępem projektu. Choć śledzenie progresu jest jedną z najważniejszych metryk, wzięcie pod uwagę innych czynników wpływających na realizowane zadania wydaje się być przynajmniej rozsądnym podejściem, zwłaszcza gdy w planie działania występują ryzyka związane choćby z opóźnieniem wdrożenia finalnej implementacji. Jak zatem podejść do zdefiniowania czynników mających wpływ na ryzyko przedsięwzięcia?
Chcąc otrzymać jasny ogląd sytuacji w projekcie, należy uwzględnić wiele punktów widzenia. Brzmiące jak truizm powyższe zdanie, przestaje być oczywiste w momencie planowania konkretnych zadań – wszak stanowi ono kolejną zmienną, którą trzeba uwzględnić w harmonogramie. Jednak to właśnie głos programistów winien być rozpatrzony, gdy mowa jest o najmniejszych składowych każdego etapu prac. Chęć usłyszenia ich zdania należy więc odpowiednio zaznaczyć, na przykład pozwalając członkom zespołu ocenić prawdopodobieństwo powodzenia projektu w założonych ramach czasowych, a także stwarzając przestrzeń do konstruktywnej krytyki rzeczywistości, która nie pozwoliła im skutecznie realizować powierzonych zespołowi zadań.
Powyższe rozwiązania są jedynie przykładami wsparcia sprzężenia zwrotnego w projekcie. Te oraz wszystkie inne procesy usprawniające komunikację na różnych poziomach abstrakcji organizacji muszą spełniać podstawowy warunek chęci słuchania siebie nawzajem w celu dostarczenia rozwiązania o jak najwyższej jakości.