Lean Project Management", to w swobodnym tłumaczeniu "Odchudzone zarządzanie projektami". Tłumaczenie szokuje, wiernie jednak oddaje ideę podejścia, zastosowanego wcześniej do zagadnień zarządzania produkcją (tzw. Lean Manufacturing): orientację tylko na działania przynoszące wartość organizacji i na eliminację wszelkiego marnotrawstwa.

O tym czym jest Lean PM opowiada fragment pierwszego rozdziału książki pod tym samym tytułem, autorstwa Lawrence Leacha (a przetłumaczonej i rozprowadzanej w Polsce przez nas). Natomiast o samej książce przeczytacie na stronie Lean Project Management - Osiem zasad sukcesu projektu.

Zasady Lean
Podejście Lean stosowane w produkcji koncentruje się na eliminacji marnotrawstwa, wykorzystując pięć podstawowych zasad:

1. Określenie wartości.
2. Identyfikowanie strumienia wartości (ang. value stream).
3. Przepływ.
4. Ciągnięcie (ang. pull).
5. Doskonałość.

Wszystkie te zasady pozostają w pełnej synergii z CCPM. Nawiązanie do wartości łączy się z orientacją na cel w podejściu TOC i orientacją na klienta w metodzie Six Sigma. Identyfikacja strumienia wartości dla projektów tworzy projektowy system realizacyjny. Orientacja na przepływ jest szczególnie powiązana z wielo-projektowym podejściem w TOC/CCPM, dążącym do maksymalizacji przepływu projektów przez ograniczenie. W pojedynczym projekcie łańcuch krytyczny i zarządzanie buforami realizują zasadę "pull", natomiast w systemie wielo-projektowym zasada "pull" jest implementowana przez harmonogram werbla oraz bufor zdolności.

Zasady LPM oraz Zarządzanie Ograniczeniami
Zarządzanie projektami metodą Łańcucha Krytycznego - ang. Critical Chain (Leach, 2004) łączy zasady Zarządzania Ograniczeniami (ang. Theory of Constraints), goldrattowski łańcuch krytyczny (Goldratt, 1997) oraz PMBOK^® Guide. Podstawowa zasada TOC stwierdza, że każdy system ma ograniczenie, limitujące jego wyjścia. Niektórym bardzo odpowiada to proste stwierdzenie. TOC International Certification Organization (TOC/ICO) proponuje bardziej precyzyjną definicję:

Holistyczna filozofia zarządzania stworzona przez Dr. Eliyahu M. Goldratta, której podstawą jest zasada, że złożone systemy przejawiają wrodzoną prostotę, tj. nawet bardzo złożony system, składający się z tysięcy ludzi i elementów wyposażenia może mieć w danym momencie tylko bardzo małą liczbę zmiennych - może tylko jedną (nazywaną ograniczeniem) - która faktycznie ogranicza zdolność systemu do realizacji jego celu.

Podpisuję się pod większością stwierdzeń tej definicji, chociaż jestem nieco sceptyczny w odniesieniu do słowa "holistyczna", gdyż efektywny LPM wymaga znacznie więcej niż TOC. Zasady TOC mówią o orientacji na cel, działaniu w celu maksymalizacji przepustowości systemu biznesowego oraz stosowaniu metody pięciu kroków do doskonalenia systemu; pierwszym z tych kroków jest identyfikacja ograniczenia, limitującego osiągnięcie celu systemu.

Stosując się do tych zasad i rozumiejąc, że projekty składają się z wzajemnie zależnych zadań, z których każde podlega odchyleniom czasu trwania, LPM dokonuje trzech radykalnych założeń dotyczących zarządzania projektem:

• Nie trzeba kończyć każdego zadania na czas, by zakończyć cały projekt na czas.
• Rozpoczynanie projektu wcześniej wcale nie oznacza, że zakończy się on wcześniej.
• Dodanie buforów skraca czas trwania projektu oraz jego koszt.

W kolejnych rozdziałach opisano, jak LPM realizuje te paradoksy zarówno dla pojedynczego projektu, jak i w systemie wielu projektów.

Podstawową zasadą LPM jest następująca zasada: każdy projekt, który wart jest realizacji, wart jest szybkiej realizacji. (Warto jest także od pierwszego razu wykonywać swoją pracę porządnie - sądzę, że jakość i szybkość są komplementarne, ale to całkiem inna historia.) Powody biznesowe są bardzo proste. Większość projektów zaczyna przynosić zwrot z inwestycji dopiero po ich zakończeniu. Inwestycja w projekt (przynajmniej w teorii) powinna być niemal taka sama, bez względu na czas trwania projektu. Możemy też zgodzić się ze stwierdzeniem, że dłuższy projekt będzie kosztował trochę więcej. Jednak odłóżmy to stwierdzenie na moment, gdyż mogłoby ono okazać się pomocne w punkcie, nad którym chcę, byście się zastanowili. Myślę, że możecie zgodzić się z tezą, że większość produktów projektu ma ograniczony cykl życia: istnieje moment w czasie, od którego nie będą już dostarczały pierwotnie planowanego zwrotu; przynajmniej nie bez istotnej modyfikacji projektu. Przyczyny takiego stanu rzeczy mogą być różne: zużycie, starzenie się lub zastąpienie przez lepszy, konkurencyjny produkt, będący wynikiem innego realizowanego projektu.

Tabela 1-1 porównuje realizację tego samego projektu w czasie dwóch i czterech lat. W obu przypadkach sumaryczne inwestycje na poziomie 4 milionów dolarów dają roczny cash flow w wysokości 2 milionów dolarów. Załóżmy, ze rezultat projektu (przykładowo nowy produkt) stanie się przestarzały na koniec ósmego roku. Widać, że realizacja projektu w czasie o połowę krótszym poprawia zwrot z inwestycji o 50%.

Tabela 1-1: Każdy projekt, wart realizacji, wart jest szybkiej realizacji. (Dane w tysiącach dolarów.)

Teraz rozważmy przydzielanie zasobów (pieniądze, ludzie, etc.) dla realizacji wielu projektów. Czy lepiej jest rozpocząć wszystkie projekty w tym samym czasie, rozkładając zasoby na dłuższy czas, czy też skoncentrować zasoby na projektach w sposób sekwencyjny, tak by każdy projekt zakończył się w możliwie najkrótszym czasie od momentu jego rozpoczęcia?

Przeanalizujmy ponownie tabelę 1-1 i przyjmijmy, że dysponujemy zasobami do realizacji tego szybszego projektu. Oznacza to, że zwrot z projektu zacznie się po dwóch latach. Jeśli następnie zaczniemy w trzecim roku drugi projekt i zakończymy go na koniec czwartego roku, to uzyskamy przychody w wysokości 4 milionów dolarów na początek piątego roku.

Jeśli natomiast zaczniemy oba projekty jednocześnie, dzieląc pomiędzy nie dostępne zasoby, oba będą trwały tyle, co wolniejszy projekt. Nie uzyskamy żadnych przychodów przed piątym rokiem. Definitywnie stracimy 4 miliony dolarów dochodu, możliwe do uzyskania z pierwszego projektu w roku trzecim i czwartym. Zobaczymy poniżej jak LPM implementuje tą zasadę.

Projekty IT są dobrym przykładem notorycznej słabej realizacji w odniesieniu do tradycyjnych mierników projektowych: zakresu, harmonogramu i kosztu. Częściowo w odpowiedzi na taką sytuację w ostatnich latach zaproponowano szereg podejść do realizacji projektów, mających przezwyciężyć obserwowane ograniczenia konwencjonalnego kierowania projektami. Znane są one pod różnymi nazwami lub akronimami, często należącymi do grupy tzw. "lekkich", lub "zwinnych" (ang. light, agile) podejść. Podstawową zasadą, jaką posługują się te techniki jest stworzenie gotowego do użytkowania produktu, tak szybko, jak to jest możliwe oraz jego doskonalenie w czasie. Takie podejście zgodne jest z przedstawionym powyżej argumentem stwierdzającym, że zwrot z inwestycji zaczyna się z pierwszym gotowym do użytkowania produktem. Podsumowując krótko te techniki: dzielą one duży projekt (który nazwałbym programem) na szereg mniejszych projektów. Niektóre z nich dążą nawet do tego, by produkt był dostarczany co dwa tygodnie, lub co miesiąc. Sądzę, że w tym czasie można by ciągle dostarczać produkty, maksymalizując przepływ lub przepustowość.

Chociaż podejścia "lekkie" dostarczają wiele dobrych pomysłów dla kierowania zespołem projektowym, wiele z nich nie odbiega od konwencjonalnego zarządzania projektami, wbrew temu co twierdzą ich zwolennicy. Obiecują one jednak poprawę w stosunku do złego zastosowania konwencjonalnego procesu. Najczęstszy błąd popełniany w stosunku do PMBOK^® Guide, to traktowanie go jako opisu wszystkich procesów, jakie należy realizować w każdym projekcie lub w każdym systemie projektowym. To tak jak winić restaurację za ból brzucha, ponieważ spróbowałeś wszystkich potraw z jej menu.