Budowa Zespołu – Komitet Sterujący projektu Dynamics AX

Wstęp

Komitet Sterujący projektu Dynamics AX, ma najczęściej strukturę zaprezentowaną na poniższym rysunku:

Komitet sterujący projektu Dynamics AX

Przedstawiony wyżej podział jest pochodną zawieranych umów na wdrożenia systemu ERP. W większości z nich zachodzi ostre rozgraniczenie obowiązków pomiędzy klientem a dostawcą. To jest klient odpowiada za:

  • udostępnienie informacji dotyczących procesów biznesowych;
  • wymagań stawianych przed aplikacją;
  • dostępów do środowisk;
  • etc.

Dostawca zobowiązany jest do:

  • przełożenia wymagań na działający system IT
  • etc.

Umowy te jednocześnie stoją w sprzeczności z postanowieniami zarówno zwinnych jak i klasycznych metodyk zarządzania projektami. Które jasno stanowią o jednoosobowej odpowiedzialności czy to Product Ownera (w przypadku metodyk zwinnych) czy Kierownika Projektu (dla metodyk klasycznych).

Stąd, podział zaprezentowany na rysunku powyżej. W szczególności nominowanie 2 kierowników projektów po stronie dostawcy oraz klienta, stanowi grzech pierworodny wdrożeń ERP.

Komitet Sterujący projektu Dynamics AX a dwuwładza projektowa

Dwuwładza w projekcie prowadzi do licznych nieporozumień, niedopowiedzeń a co gorsza przenosi się w dół na 2 zespoły projektowe. Które w sytuacjach stresowych (np. podjęcie decyzji o uruchomieniu produkcyjnym systemu) stają po przeciwnych stronach barykady. Zaczynając się wzajemnie zwalczać i udowadniać swoje racje zamiast kierować się dobrem projektu. W/w problem jest bardzo rzadko prawidłowo adresowany przez decydentów projektowych.  Czujność Komitetu Sterującego zostaje uśpiona faktem że problemy wynikające z dwuwładzy w projekcie narastają z powoli. Podobnie jak frustracja obu stron. A w momencie wybuchu konfliktu to członkowie komitetu sterującego starają się pogodzić zwaśnione strony. Gdzie nigdy nie powinni dopuścić do wytworzenia takiego podziału.

Zadania Kierownika Projektu

Wróćmy zatem do zadań Kierowników projektu tj. zarządzania 4 składowymi projektu:

  1. Zakresem wdrożenia;
  2. Jakością dostarczanych produktów;
  3. Harmonogramem prac;
  4. Budżetem wdrożenia;

aby pozostawały one ze sobą w równowadze. W praktyce oznacza to, że Kierownik Projektu jest odpowiedzialny za dostarczenie produktu o określonej jakości. Spełniającego określone wymagania w zaplanowanym czasie oraz budżecie. Oznacza to iż kierownik projektu odpowiedzialny jest za każdy z w/w elementów zarządzania. Mając jednocześnie pełnię swobody podejmowania decyzji w ich obrębie. Taka sytuacja ma miejsce w przypadku kiedy mamy jednego Kierownika Projektu. Co jednak dzieje się kiedy mamy ich 2? Najczęściej następuje podział kompetencji według poniższego schematu:

  1. Zakres wdrożenia – Kierownik Projektu po stronie klienta;
  2. Jakość dostarczanych produktów – Kierownik Projektu po stronie klienta;
  3. Budżet projektu – Kierownik Projektu po stronie dostawcy;
  4. Harmonogram wdrożenia – Kierownik Projektu po stronie dostawcy;

Taki podział obowiązków wydaje się dosyć naturalny w świetle etapu sprzedażowego, w których to klient dyktuje wymagania co do systemu (w tym wymagania jakościowe) a zatem nimi zarządza. Natomiast to dostawca określa jak szybko jest w stanie dostarczyć produkt oraz za jaką cenę. Zatem przez domniemanie zarządza tymi dwoma elementami. Problemem jednak nie jest sam proces sprzedażowy a dalsze fazy już po podpisaniu umowy na wdrożenie systemu. Klient w sposób zupełnie naturalny dalej dąży do zachowania podziału ustalonego w ramach poprzedniego etapu projektowego. Ignoruje jednocześnie ryzyko utrzymania projektu w równowadze przy 2 kierownikach projektu.

W ramach niniejszego artykułu zaproponujemy ewentualne rozwiązanie wyżej wymienionego problemy poprzez zmianę struktury projektowej. Rozważymy 2 odmienne warianty, który z nich jest bardziej przystający do realiów projektu, czytelnik będzie musiał podjąć samodzielnie.

WARIANT I – Wprowadzenie Pojedynczej Roli Kierownika Projektu

Komitet sterujący projektu Dynamics AX w wariancie I ma klasyczną budowę zaczerpniętą z metodyki PRINCE 2 lub PMI.

Komitet sterujący projektu Dynamics AX

W strukturze tej mamy pojedynczą rolę Kierownika Projektu podlegającego bezpośrednio pod Komitet Sterujący projektu. Kierownicy projektów po stronie dostawcy oraz klienta zostają przesunięci do roli Kierowników Zespołów którzy dostarczają produkty w ramach prac projektowych.

WARIANT II – Wprowadzenie Zespołu Zarządzania Projektem

Drugi wariant zakłada powstanie osobnego ciała określanego mianem Zespołu Zarządzania Projektem. W skład tego ciała wchodzi klasyczna konstrukcja Komitetu Sterującego znana z metodyki PRINCE 2 oraz Kierownik Projektu niezwiązany z żadną ze stron (dostawca, klient).

Komitet sterujący projektu Dynamics AX

Dalsze relacje pomiędzy Zespołem Zarządzania Projektem a pozostałymi członkami Zespołu Projektowego przebiegają według poniższego diagramu.

Komitet sterujący projektu Dynamics AX

Na pierwszy rzut oka oba warianty są ze sobą tożsame, jedyna różnica polega na zmianie nazewnictwa stanowisk. Należy jednak wziąć pod uwagę łatwiejszą implementację Wariantu II. Większość firm wdrożeniowych dysponuje gotową metodyką zarządzania projektem. W większości z nich rola Kierownika Projektu po stronie Dostawcy oraz Klienta jest zdefiniowana zgodnie z wariantem II. Zatem nagła zmiana nazewnictwa może powodować niepotrzebny zamęt wewnątrz zespołu wdrożeniowego oraz aktualizację dokumentacji. Dodatkowym benefitem wprowadzenia dodatkowego gremium (Zespołu Zarządzania Projektem) jest okazja do usystematyzowania obowiązków oraz odpowiedzialności poszczególnych członków Komitetu Sterującego na etapie podpisywania umowy wdrożeniowej.

Odrębnym tematem (poruszonym w kolejnym artykule) jest struktura organizacyjna projektów SCRUMowych (Agile).

Podsumowanie

Przedstawione wyżej warianty są do siebie bardzo zbliżone. Opierają się na jednym bardzo istotnym celu: nie można delegować żadnego z 4 elementów zarządzania projektem:

  1. Zakresem wdrożenia;
  2. Jakością dostarczanych produktów;
  3. Harmonogramem prac;
  4. Budżetem wdrożenia;

Za każdy z nich musi być odpowiedzialna 1 osoba.

Wybór odpowiedniej osoby może nastręczać poważnych problemów. Z jednej strony Sponsorem Projektu jest klient, zatem naturalnie będzie on chciał współpracować z osobą do której ma zaufanie. Jednak znalezienie kandydata z odpowiednią wiedzą i doświadczeniem w ramach firmowych zasobów ludzkich jest często niemożliwe. Odpowiednią wiedzę oraz doświadczenie posiadają kadry po stronie dostawcy jednak ich stronniczość powoduje ograniczone zaufanie sponsora biznesowego. Optymalnym rozwiązaniem jest zatem zatrudnienie osoby z „zewnątrz”, która zostanie bezpośrednio zatrudniona po stronie klienta.

Patrząc przez pryzmat własnych doświadczeń uważam że odpowiednie zorganizowanie struktury zarządzania projektem jest jednym z kluczowych czynników powodzenia projektu. Dzięki temu Komitet Sterujący wyeliminuje szereg stresujących sytuacji oraz uniknie większości z zaistniałych sporów na linii klient dostawca.

Literatura:

Zarządzanie projektami IT. Przewodnik po metodykach

Autor:
Adam Koszlajda

ISBN:
83-246-1804-X

Format:
158x235

Liczba stron:
360

Cena:
57.00zł

PMO. Praktyka zarządzania projektami i portfelem projektów w organizacji

Autor:
Seweryn Spałek, Maciej Bodych

ISBN:
978-83-246-2774-5

Format:
140x208

Liczba stron:
208

Cena:
69.00zł

Zarządzanie projektami ze Scrum. Twórz produkty, które pokochają klienci

Autor:
Roman Pichler

ISBN:
978-83-246-8526-4

Format:
140x208

Liczba stron:
168

Cena:
39.00zł

Komitet sterujący projektu Dynamics AX

Komitet sterujący projektu Dynamics AX

One response to “Budowa Zespołu – Komitet Sterujący projektu Dynamics AX”

  1. dmca pisze:

    Thank you for every other magnificent post.
    Where else could anybody get that type of info in such an ideal method of writing?
    I’ve a presentation subsequent week, and I am at the search for such
    info.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

three × three =