Zarządzanie projektami jest już z nami jakiś czas, np. piramida w Gizie powstała 2570 lat p.n.e. i była niewątpliwie dużym przedsięwzięciem o cechach projektu. Niestety można domniemywać, że zawiodło raportowanie (lub też zostało zniszczone) i możemy jedynie podziwiać efekt, a nie drogę dojścia do celu. Zajmijmy się czymś znacznie bliższym. Każdy kto miał chociażby krótką przygodę z zarządzeniem projektami zna Gantt’a.
Od razu rozwiejemy wątpliwości, to nie jest żaden akronim. Co raz większa skala produkcji będąca wynikiem rewolucji przemysłowej przejawiającej się chociażby wprowadzeniem linii montażowej wymuszała co raz to lepsze techniki koordynacji pracy wielkich zakładów. Henry Gantt będąc odpowiedzialnym za wdrażanie naukowych metod zarządzania w konsorcjum przedsiębiorstw produkujących stal miał za zadanie usprawnić pracę.
W 1917 roku po raz pierwszy zastosował wymyśloną przez siebie metodę harmonogramowania projektu.* I można to osiągnięcie uznać za kamień milowy w rozwoju metodyk zarządzania projektami. Pierwszą budową na ogromną skalę wykorzystującą wykres Gantta była budowa tamy Hoovera, zainicjowana przez Franka Delano Roosevelta w ramach planu New Deal. Po budowie Kanału Panamskiego to największe przedsięwzięcie cywilne realizowane przez rząd. Temat ten jest jednak tak obszerny, że pozostawimy go na odrębny wpis o rozwoju zarządzania projektami w kontekście wielkich przedsięwzięć rządowych.
Od niemalże stu lat możemy zaobserwować tryumfalny marsz zarządzania projektami. Coraz to nowe dziedziny wdrażały stopniowo rozwijającą się metodykę, dodając coś od siebie. Doczekaliśmy się w końcu standardów, najlepszych praktyk, podręczników i katechizmów.
Można naszym zdaniem powiedzieć, że zarządzanie projektami ma tak ugruntowaną pozycję, że możemy rozważać jego klasyczne oraz nowoczesne odmiany. Bowiem pojawienie się, a potem rozpowszechnienie komputerów na świecie odmieniło dotychczasowy porządek. Firmy IT z garaży i pracowni informatycznych uniwersytetów żwawo przemarszowały na Wall Street, zadomowiając się tam na dobre. Niestety charakterystyka biznesu IT, a rozwoju oprogramowania w szczególności, jest nieco odmienna od projektów z innych branż. Dobrze sprawdzona metodyka zarządzania projektami przestała się sprawdzać w nowych okolicznościach. Budżety projektów programistycznych rozciągały się w nieskończoność, daty premiery były przesuwane, a czasem finalny produkt okazywał się fiaskiem, bo nikt już na niego nie czekał.
Klasyczne zarządzanie projektami dostało zadyszki. Jednym z głównych problemów jest tutaj utrzymanie dużej innowacyjności, przy zachowaniu sformalizowanego środowiska projektu oraz hierarchicznej struktury organizacji. Szeroko pojęty rynek technologii jest tak zmienny, że również koncepcja dostarczania dojrzałego produktu końcowego klientowi nie zdaje już egzaminu. Określenie dokładnej listy wymagań względem produktu jest niemożliwe przed dokonaniem testów. Projekt więc charakteryzuje się dużą niepewnością co do rezultatów. Klasyczny model zarządzania zostaje więc postawiony przed zrealizowaniem nieokreślonego celu, a z tym nie radzi sobie zbyt dobrze. Te oraz wiele innych ograniczeń spowodowało rozwój nowych metod zarządzania projektem. Taką nową koncepcją jest właśnie cała rodzina metodyk zwinnych. W jej skład wchodzi kilka różnych koncepcji takich jak Scrum, extreme software developement i wiele innych, które jednakże stoją na podobnych fundamentach.
Przede wszystkim stanowią one zaprzeczenie klasycznego kaskadowego zarządzania projektem, gdzie kolejne etapy następują w sekwencji dostarczając dojrzały produkt. Metodyki zwinne opierają się na iteracji cyklu rozwoju produktu. Krótkie cykle, trwające zazwyczaj kilka tygodni, dostarczają produkt, który będzie stanowił bazę rozwoju. Następny cykl rozpoczyna się uwzględniając już nowe informacje i doświadczenie dotyczące dostarczonego produktu.
Najprościej filozofie zwinnego zarządzania projektem można przedstawić w 10 punktach:
Praca zorganizowana w krótkich cyklach
Kierownictwo nie przeszkadza zespołowi w trakcie trwania cyklu
Zespoły raportują klientowi a nie kierownikowi
Zespoły szacują ile potrwa dane zadanie
Zespoły decydują ile mogę przyjąć zadań w trakcie trwania jednego cyklu
Zespoły decydują jak wykonają zadanie
Zespoły same mierzą swoją wydajność
Przed rozpoczęciem cyklu zdefiniowany zostaje porządany produkt
Pożądane produkty są określane na podstawie doświadczeń użytkowników
Systematycznie usuwane są utrudnienia
Te zasady znane są już od lat i jako takie nie stanowią przełomu. Jednak stosowanie ich razem sprawia, że wiele projektów zakończyło się sukcesem. Kluczem do sukcesu tego podejścia jest zrozumienie jego integralności. Stosowanie wyłącznie niektórych rozwiązań i odrzucanie innych powoduje jeszcze gorsze efekty niż klasyczne podejście. Jeżeli jednak projekt prowadzony jest zwinnie, możemy mieć większą pewność, że zespoły wytwarzają wartość dodaną dla klienta. Obie strony zyskują na tym – klient wie, co będzie dostarczone, co więcej wie, że będzie to miało dla niego konkretną wartość. Z drugiej strony zespół skupia się tylko na pracy istotnej dla projektu, ograniczając tym samym straty. Metodyki zwinne odniosły spory sukces. Może o tym świadczyć to, że metody początkowo dedykowane wyłącznie rozwojowi oprogramowania są stosowane w coraz to nowych środowiskach.
Co więcej całe przedsiębiorstwa są obecnie zarządzane w ten sposób. Za przykład może tu posłużyć firma Saleforce, specjalizująca się w oprogramowaniu CRM oraz aplikacji biznesowych w chmurze. W 2006 roku firma widząc stopniowy zanik innowacyjności i hamujący wzrost, miała do wyboru dwie opcje, zintensyfikować dotychczasowe działania, lub też wybrać zupełnie nową drogą. Zarząd podjął decyzje przejścia na nowy model zarządzania oparty na Scrum. Decyzja okazała się niewątpliwym sukcesem. W 2011 roku CEO Salesforce Marc Benioff został mianowany przez Forbesa najcenniejszym CEO na świecie. Rok później ten sam dwutygodnik uznał Salesforce za najbardziej innowacyjną firmę w USA.
Salesforce to nie jedyna firma, zarządzana w duchu zwinnym. Prawdę mówiąc giganci IT ochoczo przechodzą na ten typ zarządzania: Apple, Amazon, Google, by wymienić tylko tych największych.
*Tak naprawdę koncepcje harmonogramu, jak również samo wyrażenie “harmonograf” wymyślił Karol Adamiecki i wzmianki pochodzą jeszcze z 1896 roku. Niestety nie opublikował on swojej koncepcji aż do 1931 roku. Koncepcja Gantta była już w tym czasie rozpowszechniona.
