Co trzeba rozumieć ze świata pozaprojektowego, aby skutecznie kierować projektem? Jak zarządzać czymś, co jest trochę projektem i trochę nim nie jest?
Projekt „czysty”
Czym byłby projekt „czysty”? Byłby idealnie zgodny z definicją czyli byłoby to unikalne, tymczasowe przedsięwzięcie podejmowane po to, aby wytworzyć tzw. business product. Business product to coś, dzięki czemu sponsorowi będzie lepiej. Ów business product jest jednocześnie nie do kupienia ot tak, z półki. Musimy go wytworzyć naszym projektem, wykorzystując specjalnie zorganizowane pod ten cel zasoby.
A gdyby potrzebny nam business product dało się kupić z półki? Wtedy cena byłaby zapewne korzystniejsza niż suma budżetowa projektu. A gdyby nawet nie, to na pewno zyskalibyśmy na czasie. Gdyby potrzebne nam business products dało się produkować seryjnie, to odpadłby nam cały kłopot związany z organizowaniem się do projektowej pracy, itp. Gdyby …
To gdybanie ma bardzo głęboki sens. Prowadzi nas do świata, w którym interesariusze są znani bez potrzeby przeprowadzania ich analizy, rezerwy na ryzyko i zmiany ograniczają się do niewielkich dopuszczalnych odchyleń od planu, zasoby są domyślnie zorganizowane i prealokowane. To świat procesów, który doskonali się poprzez powtarzalność. W tym świecie nasz projektowy business product byłby wytworzony sprawniej. Czy możemy jakoś to wykorzystać?
Wskazówka
Gdyby projekt można było pozbawić cech projektu i „przemalować” na proces, efektywność zauważalnie wzrośnie. Efektywność zależy bowiem wprost od unikalności: im większa, tym większa niepewność i wynikający z niej narzut na próby i błędy nazywane, zależnie od kontekstu, ryzykiem lub zmianą.
Pogranicze #1: Mały rozwój
Dla każdego ważnego systemu informatycznego, po wdrożeniu kreuje się 3 procesy. Są to: utrzymanie, wsparcie, oraz proces (sic!) rozwoju. Każde pojedyncze zlecenie rozwojowe spełnia definicję projektu (unikalne, tymczasowe, etc.). Problem w tym, że jest zbyt małe, aby zastosować dlań kanoniczny zestaw do zarządzania projektem zawierający kartę projektu, plan projektu, realizację z raportowaniem i zarządzaniem zmianą oraz zamknięcie z raportem końcowym, rozliczeniem oraz przekazaniem produktów do użytkowania z utrzymaniem. Sięgamy więc do wytycznych zarządzania portfelowego zawartych w The Standard for Portfolio Management, z jednoczesnym uproszczeniem i wystandaryzowaniem konstrukcji pojedynczego projektu.
Mały rozwój – przykład
Wybrana grupa menedżerów ma prawo zamawiać zmiany do systemu informatycznego. Kierownik odpowiedzialny za rozwój tego systemu ma do dyspozycji zasoby do ich realizacji. Każdą zmianę (zlecenie rozwojowe) wycenia metodą uproszczoną. Stosuje wycenę w osobodniach [MD] szacowanych na oprogramowanie zmiany (zlecenia), bo doświadczenie pokazało, że programiści są najbardziej krytycznym zasobem, a na podstawie MD programistów można również szacować pracochłonność analizy, testów, określać zapotrzebowanie na środowiska techniczne itd.
Zleceń rozwojowych zawsze jest więcej niż zdolności „fabryki zmian” do ich realizacji. W związku z tym zgłoszenia po wstępnej selekcji są wyceniane, a następnie ustawiane w kolejce do realizacji, albo odrzucane. Decyzje te podejmowane są podczas rutynowych spotkań administratora biznesowego z właścicielem systemu i kierownikiem odpowiedzialnym za rozwój. Nawiasem mówiąc, całe to zarządzanie bardzo przypomina proces (sic!) zarządzania zmianą stosowany w większych projektach. Nieprawdaż?
Rys. 1 Mały rozwój systemu informatycznegoPogranicze nr #2: Produkcja zleceniowa
Zlecenie produkcyjne w produkcji zleceniowej lub małoseryjnej spełnia definicję projektu: jest unikalny klient, z jego unikalnym zakresem do realizacji, z unikalną dla tego klienta wyceną i unikalnym dla zlecenia kompletem project baselines. Niezbyt unikalne są zasoby. Zakres zlecenia też nie jest tak do końca unikalny, bo jest jakąś wersją czy kombinacją tego, co jest w ofercie katalogowej.
Projekty wokół produkcji zleceniowej – przykład
Przedsiębiorstwo produkujące aparaturę elektryczną dla przemysłu jest zarządzane portfelowo. Istnieje portfel mniej lub bardziej potencjalnych kontraktów (zamówień od klientów), który kontrolowany jest przez zespół handlowy oraz zarząd. Konsekwencją pracy zespołu handlowego jest lista konkretnych zleceń produkcyjnych, które są dalej kontrolowane przez produkcję, w formie portfela zleceń produkcyjnych. Na rzecz produkcji pracuje logistyka, która, zależnie od potrzeby, stosuje gotowe sprawdzone schematy współpracy z dostawcami (czyli procesy) albo kreuje wewnętrzne małe projekty ukierunkowane na pozyskanie danej dostawy. Mamy więc trzy obszary funkcjonalne z trzeba współzależnymi portfelami projektów.
Produkcja zleceniowa jest realizowana według specyfikacji tworzonych w wyspecjalizowanej komórce w produkcji, nazywanej nieprzypadkowo działem rozwoju. Dział rozwoju ma swoje własne projekty, których produktem głównym jest zawsze specyfikacja. Niezależnie jednak od charakteru konkretnego zlecenia produkcyjnego (badawczo-rozwojowe, marketingowe, realizacyjne dla klienta), dla produkcji istnieje po prostu jeden portfel zleceń produkcyjnych otrzymywanych z działu rozwoju.
W szerszej perspektywie zlecenia produkcyjne to jeden z istotnych elementów unikalnych większych całości. Na przecięciu oczekiwań handlowców, działu rozwoju, produkcji i logistyki powstają małe unikalne programy projektów. Składają się z projektu rozwojowego (specyfikacja, prototypy, zlecenia produkcyjne rozwojowe), zadań zaopatrzeniowych (których nikt nie nazywa nawet projektami), zleceń produkcyjnych oraz… przyszłych potencjalnych projektów dla klientów. Zasadą jest, że jednym ze zleceń produkcyjnych w programie jest produkcja na zlecenie klienta. To zapewnia orientację programów na rynek.
Z powyższego przykładu wychodzi ciekawa kombinacja procesowo zarządzanych podobnych projektów i unikalnych programów projektów złożonych z typowych projektów.
Rys. 2 Portfele i programy projektów w przedsiębiorstwie z produkcją zleceniowąSposoby na poprawę efektywności
Idąc w kierunku ograniczania unikalności, prędzej czy później dotrzemy do typowych metod optymalizacji procesów. Wśród nich bardzo skuteczna jest standaryzacja produktów zarządzania, standaryzacja w szeroko rozumianej organizacji pracy oraz, jeśli to możliwe, standaryzacja typowych business products. Sięgając do teorii:
- The Standard for Portfolio Management, 3rd ed. zaleca spójność w obszarach risk, communication, resources oraz zaleca tzw. performance management framework.
- PMBOK® Guide 5th ed. oczekuje, że na starcie projektu skorzystamy z corporate knowledge base, wykorzystamy „gotowce”, a na koniec projektu uaktualnimy tę bazę o nasze lessons learned.
Wybrane praktyczne przykłady:
- Karta zlecenia, zamówienia, zmiany – będąca uproszczonym odpowiednikiem karty projektu, zastępującym również plan projektu (project management plan),
- Plan zlecenia produkcyjnego będący odpowiednikiem planu projektu ograniczonego do baselines,
- Gotowe domyślne specyfikacje zakresu np. typowy zakres usługi zaprojektowania wnętrza domu lub biura stosowany przez firmy projektujące wnętrza,
- Wystandaryzowane listy interesariuszy z listami zagadnień ułatwiającymi zdefiniowanie przyszłej współpracy, np. lista ról potrzebnych do przeprowadzenia instalacji produkcyjnej w środowisku systemów informatycznych,
- Wystandaryzowane procedury postępowania dla typowych zagrożeń – najczęściej w formie procedur zapewnienia jakości np. wymóg angażowania dostawców, którzy przeszli proces wewnętrznej certyfikacji, obowiązek uzyskania pozytywnej opinii od głównego architekta IT w sprawie dopuszczenia danego rozwiązania informatycznego do wykorzystania w projekcie,
- Stosowanie tych samych szablonów dokumentów niezależnie od rodzaju projektu.
Podsumowanie
Można pokusić się o stwierdzenie, że sukces firm prowadzących biznes projektowy wymaga umiejętności „uprocesowienia” swoich projektów, zbalansowania unikalności i powtarzalności, selekcji tego co w danym przypadku najlepsze.
Produkcja zleceniowa zawsze jest de facto portfelem projektów. W małym rozwoju mamy de facto portfel mikroprojektów. To są tylko dwie rodziny przykładów. Są inne. Np. wielkie przedsiębiorstwa wprowadzają procedury, aby „uprocesowić” powtarzalne elementy w swoich projektach. Kto z nas nie słyszał o procedurach zakupowych? Kto w IT nie słyszał o release management?
A na koniec zastanówmy się, jak opanowano w IT problem z kontrolą projektów nie do opanowania? Są projekty, w których zawczasu wiadomo, że ich zakres nie da się określić przed rozpoczęciem pracy nad tym zakresem, i wiadomo, że zakres ten jest tak unikalny, że będzie pływał. Rozwiązaniem okazał się proces złożony z takich samych iteracji, które różniły się „tylko” zakresem. Agile jest także pograniczem!
Pozostaje mi na koniec życzyć Czytelnikom udanej eksploracji pogranicza.
Trener w firmie ValueTank, niezależny kierownik dużych projektów wdrożeniowych IT oraz niezależny doradca w dziedzinie zarządzania. Specjalizuje się w kierowaniu projektami o wysokim ryzyku niepowodzenia, budżetowaniu projektów oraz controllingu w IT. Prowadzi zajęcia z zarządzania projektami ma studiach MBA na Akademii Leona Koźmińskiego oraz z controllingu i budżetowania w IT na studiach podyplomowych „Efektywne Zarządzanie IT w przedsiębiorstwie” w Szkole Głównej Handlowej. Posiada certyfikat PMP, PRINCE2 Foundation oraz Gartner TCO Ekspert. Jest członkiem PMI Poland Chapter.