Sukces projektu

Czym jest sukces projektu?

Wiele pisze się o tym, że większość projektów nie mieści się w budżecie, przekracza terminy, a ostateczny zakres jest daleki od planowanego. Jednak czy to oznacza, że projekt nie odniósł sukcesu?

Nie bezpośrednio, chyba, że tak zostały określone jego kryteria.

Sukcesem może zakończyć się projekt, który przekroczył budżet i nie zmieścił się w terminie, a porażką może okazać się projekt, w którym obydwie te wartości zostały dotrzymane.

I tu dochodzimy do sedna. Niewiele projektów ma na początku zdefiniowane kryteria sukcesu.

Z klasycznego punktu widzenia do kryteriów sukcesu należą:

  • nie przekroczenie budżetu,
  • zgodność z harmonogramem,
  • zgodność wykonania z planowanym zakresem.

Zmieniające się trendy doprowadziły do sformułowania kolejnych dwóch kryteriów:

  • utrzymanie jakości na określonym poziomie,
  • zadowolenie Klienta.

Ja poniżej wyodrębniłem trochę więcej potencjalnych kryteriów sukcesu projektu. Należy się im dokładnie przyjrzeć przed rozpoczęciem każdego projektu.

Każde kryterium należy dokładnie zdefiniować (PM + Sponsor) oraz nadać wagę (Sponsor):

  • 1 – krytyczne,
  • 2 – bardzo ważne,
  • 3 – istotne,
  • 4 – akceptowalne zmiany.

W ten sposób powstaje matryca kompromisów.

Trzeba mieć  świadomość, że im wyższe wagi poszczególnych kryteriów, tym droższy projekt. Brak określonych kryteriów oznacza niemożliwość stwierdzenia, czy projekt odniósł sukces.

W projekcie najwyższą wagę powinny mieć maksymalnie 2 kryteria, bardzo ważne powinny być natomiast nie więcej niż 3 z nich.

Jeżeli produkt (wytworzony w ramach projektu) odnosi sukces, to nie oznacza od razu, że sukcesem był projekt. Być może dało się go zrealizować dwa razy taniej, a sukces produktu byłby większy gdyby oddano go przed premierą produktu konkurencyjnego.

Project Manager powinien być oceniany i premiowany na podstawie sukcesów jego projektów.

Przykładowa lista kryteriów sukcesu

  1. Osiągnięcie celów projektu
  2. Zadowolenie Klienta
  3. Zadowolenie Odbiorców (Użytkowników)
  4. Zadowolenie Członków Zespołu Projektowego i Project Managera
  5. Zgodność z harmonogramem, np.:
    1. Zgodność na poziomie całego harmonogramu
    2. Zgodność na poziomie kamieni milowych
    3. Zgodność na poziomie etapów
    4. Zgodność terminu zakończenia projektu
  6. Zgodność z budżetem, np.:
    1. Utrzymanie poszczególnych elementów budżetu
    2. Utrzymania poszczególnych grup budżetowych
    3. Nie przekroczenie budżetu całego projektu
    4. Zaoszczędzenie
  7. Zgodność z zakresem, np.:
    1. Wykonanie wszystkich najważniejszych elementów
    2. Wykonanie w ramach projektu wszystkich zaplanowanych zadań
    3. Utrzymanie dokładnie takiego zakresu jak zaplanowano
  8. Zachowanie jakości na określonym poziomie
  9. Udany produkt (Sukces produktu)
  10. Właściwe zarządzanie ryzykiem, np.:
    1. Uniknięcie zagrożeń
    2. Odpowiednia reakcja na nieprzewidzianą sytuację

Jeżeli macie jakieś pomysły na rozbudowanie powyższej listy, to zapraszam do komentowania tego wpisu…

Sukces projektu
Tagged on:         

2 thoughts on “Sukces projektu

  • 2010-05-25 at 19:42
    Permalink

    A ja ciągle sądzę, że uznaniowe nagradzanie jest lepsze, bo inny stworzony system nagradzania albo będzie zbyt skomplikowany, a przez to drogi w obsłudze i niezrozumiały, albo prosty, przez co może prowadzić do maksymalizacji wskaźnika, a nie jakości pracy.

    Inną sprawą jest, że wymaga to tego, aby przełożeni przewyższali kompetencją PMów, a także, aby zbudowane zostało zaufanie PMów do przełożonych.

  • 2010-06-06 at 14:51
    Permalink

    Ostatnio przeczytałem książkę (e-book) Doktryna jakości napisaną przez Andrzeja Blikle.
    Przeczytałem ją jednym tchem i polecam ją każdemu managerowi, a nawet każdemu pracownikowi. Autor wyraźnie wskazuje wady uznaniowego wynagradzania i jego wpływ na jakość. Podaje też przykłady rozwiązań – wzorowane na najnowszych standardach w tym zakresie. Z przyjemnością porozmawiałbym o tematach zawartych w tej książce. Obecnie tworzę dla mojej firmy propozycję systemu wynagradzania, który – mam nadzieję – od przyszłego roku zostanie wdrożony.

    Co do drugiej części Twojej wypowiedzi, wychodzę z założenia, że szef PMa wcale nie musi posiadać wszystkich jego kompetencji (choć byłoby to pożądane). Jak by nie patrzeć, PM często musi posiadać wiedzę specjalistyczną połączoną ze zdolnościami interpersonalnymi (przewodzenie Zespołowi, kontakt z Klientem i Podwykonawcami). Przełożony PMa (o ile istnieje – przecież z założenia Project Manager powinien być poza strukturą funkcjonalną) powinien rozumieć pracę PMa, jej ograniczenia i możliwości. Zaufanie pojawi się tam, gdzie pojawi się współpraca obydwu tych osób.

Comments are closed.