Pamiętam dobrze, że nie zdążyłem jeszcze zakończyć pierwszy powierzony mi projekt a sponsor zaproponował mi pracę na dwoma kolejnymi. Jak prowadzić wiele projektów przy ograniczonych zasobach? Jakie daje to korzyści a jakie zagrożenia? O czym trzeba pamiętać?

Prowadzenie projektu z zespołem powoływanym tylko na potrzebę jednego, ściśle określonego przedsięwzięcia, samo w sobie wymagało ode mnie umiejętności zarządzania wieloma projektami jednocześnie. Przecież równolegle pracowałem na etacie, w firmie, gdzie realizowałem powierzane mi zadania, często także o charakterze projektowym. Inaczej jednak organizuje się pracę, jeśli jedynym współdzielonym elementem jest kierownik projektu. Zdecydowanie inaczej pracuje się, gdy toczące się równolegle projekty korzystają z tych samych zasobów. Pomocna okazała się tu metoda łańcucha krytycznego.

Zarządzanie wieloma projektami rozpocząć trzeba od odpowiedzenia sobie na pytanie, czemu ma służyć ewentualne zrównoleglenie prac. Pozwoli to określić warunki, których spełnienie decydowało będzie o inicjowaniu lub przesunięciu w czasie kolejnych projektów. Oczywistym celem prowadzenia więcej niż jednego projektu jest szybsze ich realizowanie. Więcej projektów toczy się jednocześnie – więcej się wkrótce zakończy. Praktyka pokazuje, że nie wiele trzeba aby, żadne ze składowych tego zdania nie była prawdziwa (ani więcej, ani wkrótce, ani zakończyła). Aby się o tym przekonać wystarczy przypomnieć sobie co się dzieje ze słabym komputerem z systemem Windows, gdy uruchomimy na nim zbyt wiele aplikacji na raz. Może się okazać, że z żadnej z nich nie da się korzystać. Pozostaje wyłączyć komputer lub jeśli to jeszcze możliwe ?zabić? zbędne programy.

Dlatego przed uruchomieniem kolejnego projektu trzeba dobrze się zastanowić czy to w ogóle jest możliwe i czy przypadkiem inny nie wymaga obsługi w pierwszej kolejności.

W moim przypadku kolejność uruchamianych projektów jasno wyznaczał plan budowy i rozwoju portfela produktów. Pewne zmiany wprowadzały tu poszczególne wdrożenia i płynące z niech sygnały od Klientów.

Nawet najbardziej wyczekiwany przez sponsora projekt nie może być inicjowany jeśli jego równoległe prowadzenie nie będzie uzasadnione. Przed podjęciem takiej decyzji wykonałem analizę wpływu nowego projektu na projekt już realizowany. Analizę tę ułatwiało podobieństwo struktur harmonogramów obu przedsięwzięć. Główne zadania harmonogramu wyznaczał bowiem kaskadowy model budowania oprogramowania. Na schemacie poniżej umieściłem przykład harmonogramu. Zadania o tym samym kolorze realizowane są przez te same zasoby.

Wspólną realizację dwóch harmonogramów ograniczały zadania realizowane przez krytyczne zasoby zespołu programistów (kolor czerwony). Implementacja została zaplanowana tak aby maksymalnie wykorzystać czas tych ekspertów. Takie podejście wymuszały koszty utrzymania tego zespołu i przyjęty model rozliczeń. Modyfikację tego zadania utrudniały ustalenia już poczynione z zespołem oraz ryzyko, że jakiekolwiek zmiany w tej części harmonogramu negatywnie wpłyną na całość prac. Kolejne prace programistyczne musiały się zacząć po zakończeniu tych już zaplanowanych. Dodatkowo na wypadek przedłużania się prac nad kodem programu, założono pewien bufor czasowy oddzielający implementacje obu projektów (kolor szary). Dzięki temu problemy z pierwszym projektem nie przełożyłyby się na drugi projekt. Założenie te determinowały sposób planowania nowego harmonogramu. Analiza i projektowanie nowego systemu mogła się toczyć równolegle z implementacją pierwszego. Umożliwiały to wolne zasoby. Podobnie testowanie i wdrażanie. Pewny problem stanowiło zaplanowanie dokumentowania. Umożliwiło to jednak niepełne wykorzystanie potrzebnych zasobów. Jedynym utrudnieniem w pewnym momencie była konieczność dokumentowania obu projektów równolegle. Charakter tej pracy pozwalał jednak przypuszczać, że takie połączenie nie wpłynie niekorzystnie na projekt.

Analiza możliwość uruchomienia kolejnego projektu dała również wskazówki na wypadek konieczności uruchamiania kolejnych projektów.

• Dla dobra zarządzania zespołem i jakości implementacji, zadania kodowania powinny następować po sobie. Koszty jednoczesnego kodowania dwóch programów przewyższą korzyści. Dodatkowy czas na przełączanie się pomiędzy projektami, trudniejsza organizacja pracy w tym testowania, dodatkowe źródła błędów, frustracja zespołu. Zasadę tę można znieść po uruchomieniu kolejnego zespołu programistów.
• Uwzględnienie buforu między kolejnymi implementacjami może dać więcej czasu na przygotowanie projektów kolejnych aplikacji. W ten sposób mógłby się pojawić pewien zapas materiałów, które czekałyby na deficytowy zasób koderów. Jeśli pojawiłaby się dostępność tych fachowców, możliwe byłoby zapewnienie im pracy.
• Najmniej obciążonym zasobem są wdrożeniowcy. Pozwala to uruchamiać kolejne projekty czysto wdrożeniowe.

Reguły te wraz ze swoim uzasadnieniem były cennym narzędziem w rozmowach ze sponsorem.