NARZĘDZIA DO WSPOMAGANIA ZARZĄDZANIA PROJEKTAMI

W FIRMIE IBM

1. Wprowadzenie

Wraz z rozwojem gospodarczym na świecie i wzrastającą liczbą prowadzonych przedsięwzięć, coraz bardziej złożonych, pojawiła się potrzeba usystematyzowania wiedzy dotyczącej zarządzania projektami (Project Management).

Głównymi celami stawianymi przed metodyką zarządzania projektami było:

• ograniczenie ryzyka projektowego,

• ukierunkowanie projektu na zapewnienie oczekiwanych rezultatów,

• uzyskanie przez inwestora pełnej kontroli nad przebiegiem projektu.

Opierając się na danych empirycznych pochodzących z aktualnie prowadzonych oraz już zakończonych przedsięwzięć, rozpoczęto pracę nad zdefiniowaniem metodyk. Opracowane metodyki podlegają ciągłym modyfikacjom wraz ze zmianami ekonomiczno-politycznymi oraz nabywaniem nowych doświadczeń przez zespoły projektowe. Szczególnie wyraźne jest to na przykładzie młodego i niezwykle dynamicznie rozwijającego się przemysłu informatycznego, gdzie w krótkim czasie zachodzą kolejne rewolucje technologiczne.

Równolegle do prac nad metodykami trwały również poszukiwania najlepszych dróg propagowania zgromadzonej i zagregowanej wiedzy. W ten sposób rozwinęła się kolejna dyscyplina zarządzania tzw. Knowledge Management. Jednym ze strategicznych nośników wiedzy stała się technologia informatyczna. Szczególnie pomocna jest ona na tych etapach prac inwestycyjnych, gdzie w pracach projektowych wykorzystywane są różnorodne aplikacje komputerowe.

W swych pracach nad komputerowymi narzędziami wspomagającymi pracę Kierownika Projektu IBM skoncentrował się przede wszystkim na wsparciu procesów planowania i realizacji projektu. Narzędzia realizujące te zadania wchodzą w skład pakietu WSDDM (Worldwide Solution Design and Delivery Methods). Stanowią uzupełnienie funkcjonalności ogólnie dostępnych, popularnych aplikacji w miejscach, gdzie krytycznymi elementami jest wiedza i doświadczenie ludzi.

2. Metodyka Zarządzania Projektami

Podczas swych kilkudziesięciu lat istnienia firma IBM blisko współpracowała z Klientami wypracowując wspólnie zasady zarządzania przedsięwzięciami tak, aby zminimalizować prawdopodobieństwo niepowodzenia prowadzonych wspólnie projektów.

Liczba, różnorodność i zasięg prowadzonych przedsięwzięć oraz liczba osób i firm zaangażowanych do ich realizacji wymusiła stworzenie przejrzystego i uniwersalnego modelu procesu zarządzania przedsięwzięciami. Kilka grup ekspertów wewnątrz IBM pracowało równolegle nad stworzeniem metodyki zarządzania projektami dopasowanej do działalności firmy. Z największym uznaniem spotkała się metodyka opracowana w IBM UK - Management the Implementation of the Total Project (MITP). Po uznaniu przez korporację tej metodyki jako wiodącej, wprowadzono do niej kilka modyfikacji i teraz pod nazwą Project Management Methodology (PMM) jest powszechnie stosowana jako standard korporacyjny.

Właściwością opracowanej metodyki jest jej uniwersalność. Może ona być stosowana praktycznie we wszystkich rodzajach przedsięwzięć. Opisuje działania zespołu projektowego jakie muszą być wykonane aby zapewnić właściwą kontrolę zadań technicznych.

2.1. Podstawowe fazy PMM

Poniżej przedstawiono cztery fazy składające się na metodykę PMM:

• Identyfikacja Projektu,

• Inicjacja Projektu,

• Realizacja Projektu,

• Ukończenie Projektu.

Zadania powiązane z fazami Identyfikacji, Inicjacji i Zakończenia Projektu są wykonywane jednokrotnie. Natomiast zadania z fazy Realizacji Projektu są wykonywane w sposób iteracyjny i przebiegają równolegle do zadań z faz technicznych.

2.1.1. Identyfikacja Projektu

Pierwszym etapem każdego projektu jest wykonanie Studium Realizowalności przedsięwzięcia. Studium pozwala na ocenę możliwości realizacji zdefiniowanych potrzeb, identyfikację czynników krytycznych sukcesu oraz ocenę poziomu ryzyka związanego z planowaną inwestycją. Zamknięciem tej fazy jest formalna decyzja aprobująca lub odrzucająca projekt. Studium Realizowalności wykonywane jest niezależnie przez Klienta oraz Dostawcę i oparte na ograniczonej wiedzy o celach biznesowych drugiej strony.

2.1.2. Inicjacja Projektu

Na drugim etapie cyklu życia projektu następuje jego szczegółowa definicja. Odbywa się ona na specjalnych warsztatach zwanych Seminarium Definiującym Projekt (ang. Project Definition Workshop). Uczestniczą w nim wszystkie kluczowe postacie przedsięwzięcia: Sponsorzy i Kierownicy projektów zarówno ze strony Klienta jak i ze strony Dostawcy rozwiązania (może być to Dostawca zewnętrzny lub wewnętrzny), niezależni konsultanci oraz strategiczni podwykonawcy. Wspólne spotkanie pozwala na jednoznaczną definicję projektu: jego zakresu, kosztów i czasu trwania. Nominowane zostają kluczowe postacie wraz z przypisanymi im kompetencjami i zakresami odpowiedzialności. Ustanawia się strukturę zarządzania projektem wraz z procesami Zapewnienia Jakości i Zarządzania Wyjątkami. Na podstawie zatwierdzonej struktury prac wyznaczany jest plan bazowy projektu.

Niezwykle istotnym elementem tej fazy jest definicja Kryteriów Akceptacji rezultatów projektu.

2.1.3. Realizacja Projektu

W tej fazie projektu zadania realizowane są cyklicznie. Zapewniają bieżącą kontrolę i aktualizację planu projektu w stosunku do planu bazowego, zdefiniowanego w fazie Inicjacji Projektu. Uruchomione procesy zarządzania sytuacjami wyjątkowymi (ryzykiem, zmianami, problemami i błędami) zapewniają właściwą reakcję na spodziewane lub już zaistniałe zaburzenia. Regularne spotkania zespołu projektowego i raporty z przebiegu prac, jak również wewnętrzne i zewnętrzne kontrole projektu dostarczają zweryfikowanej wiedzy o rzeczywistych nakładach i postępach prac, stanie budżetu, jakości produktów projektu oraz bieżącym stanie analizy sytuacji wyjątkowych.

2.1.4. Ukończenie Projektu

Następuje formalne zamknięcie projektu i wszystkich dokumentów kontraktowych oraz zwolnienie zasobów. Przeprowadzone zostaje Spotkanie Zamykające Projekt w celu zebrania wiedzy o projekcie i uaktualnienia parametrów estymacji, udokumentowania wszystkich nowych doświadczeń zdobytych podczas realizacji przedsięwzięcia oraz oceny efektywności zastosowanych procedur i metod. W trakcie tej fazy oceniane jest również Zadowolenie Klienta z dostarczonego rozwiązania i podejmowane są ewentualne czynności, by skorygować zidentyfikowane niedociągnięcia.

2.2. Podstawowe procesy w zarządzaniu projektami

Metodyka PMM opiera się na następujących procesach:

• Zarządzanie Planem Projektu: przygotowanie planu bazowego, śledzenie postępu prac, raportowanie statusu realizacji zobowiązań.

• Zarządzanie Kontraktem: dokumentacja kontraktowa, wypełnianie zobowiązań
  kontraktowych, fakturowanie, gromadzenie funduszy.

• Zarządzanie Wyjątkami: ryzyka, zmiany, problemy i błędy.

• Zapewnienie Jakości: przeglądy jakości prowadzenia projektu pod kątem
  zgodności z metodyką.

• Zarządzanie ludźmi i organizacją projektu:
  definicja struktury organizacyjnej projektu,
  identyfikacja kluczowych osób, plan zatrudnienia,
  zarządzanie zespołem projektowym, rozwój zespołu.

2.2.1. Zarządzanie Planem Projektu

Zarządzanie Planem Projektu powiązane jest zarówno z technikami planowania jak i estymacji zasobów. W ramach tego procesu stosowane są trzy podstawowe pojęcia „plan”, „estymacja” i „harmonogram”. W metodyce PMM są one zdefiniowane następująco:

Plan określa:

• jakie zadania muszą zostać wykonane,

• kto jest za nie odpowiedzialny,

• w jakiej kolejności należy je wykonać,

• w jaki sposób zostaną wykonane.

Estymacja koncentruje się na zasobach i kosztach:

• jakie zasoby są wymagane (włącznie z pieniędzmi i czasem),

• kto je dostarczy,

• kiedy będą potrzebne,

• jak długo będą potrzebne.

Harmonogram odnosi się do czasu i sekwencji zadań:

• co zostanie wykonane,

• kiedy będzie wykonane.

Z tego punktu widzenia plan i estymacja są osobnymi, ale ściśle ze sobą powiązanymi pojęciami podczas gdy harmonogram jest połączeniem planu i estymacji z uwzględnieniem kalendarza projektu i dostępności zasobów.

2.2.2. Zarządzanie Kontraktem

Zarządzanie kontraktem składa się z dwóch niezależnych części. Pierwsza powiązana jest z etapem przygotowywania oferty, druga natomiast z etapem realizacji projektu. Niewłaściwe zarządzanie kontraktem w trakcie któregokolwiek z wymienionych etapów zwiększa prawdopodobieństwo niewypełnienia przyjętych zobowiązań. Techniki kontraktowania są przede wszystkim powiązane z zarządzaniem wdrożenia projektu i mają na celu doprowadzenie do wywiązania się z zaciągniętych zobowiązań kontraktowych. Jakkolwiek, ich realizacja jest ściśle uzależniona od właściwej definicji zakresu projektu jak i pozostałych jego parametrów w fazie przygotowania oferty.

Czasami pod wpływem presji czasu zostaje podpisany kontrakt z klientem przed potwierdzeniem na zasadzie umów „back-to-back” zobowiązań partnerów i podwykonawców. W takim przypadku muszą byś w pełni zrozumiane i zaakceptowane implikacje związane z podpisanym dokumentem.

2.2.3. Zarządzanie Wyjątkami

Do sytuacji wyjątkowych zaliczamy:

• ryzyka,

• zmiany,

• problemy,

• błędy.

Bardzo istotny, a często zaniedbywany w projektach jest proces zarządzania zmianami. Proces ten jest definiowany w trakcie Seminarium Definiującego Projekt (PDW). Przykład wpływu implementowanych zmian na termin ukończenia projektu pokazuje poniższy rysunek.

Do momentu podpisania kontraktu jego warunki, w tym i zakres, ulegają w sposób naturalny ciągłym modyfikacjom w ramach negocjacji. Proces zarządzania zmianami zostaje uruchomiony po akceptacji warunków kontraktowych, a więc na początku fazy realizacji projektu. Gdy do biura projektu trafia żądanie zmiany, poddane zostaje analizie, której efektem jest decyzja: przyjęcie zmiany, jej odrzucenie lub opóźnienie w implementacji. Efekty przyjęcia zmiany mogą mieć wieloraki wpływ na główne trzy parametry projektu: zakres, koszt i termin ukończenia. Często powodują przesunięcie terminu ukończenia projektu jak to pokazano na rysunku.

Każde rozpatrzenie żądania zmiany konsumuje czas oraz angażuje zespół projektowy, a więc kosztuje. Należy zatem uzgodnić, w jaki sposób powyższe koszty będą pokrywane. Decyzje o odrzucanych zmianach powinny być dystrybuowane do wszystkich członków zespołu projektowego, aby uniknąć pojawiania się podobnych żądań w przyszłości.

2.2.4. Zapewnienie Jakości

Zapewnienie jakości sprawowane jest podczas całego cyklu życia projektu, a więc od fazy Identyfikacji, aż po fazę Ukończenia Projektu. Przeglądy jakości odnoszą się do stylu zarządzania projektem pod kątem zgodności z metodyką.

Poniżej przedstawiono czynności odnoszące się do zapewnienia jakości. Ich sekwencja odzwierciedla cykl życia projektu z metodyki PMM:

1. Definicja standardów stosowanych w projekcie bazując na celach projektu uzgodnionych z Odbiorcą projektu. Uwzględnienie specyficznych wymagań Zapewnienia Jakości stosowanych w organizacji Klienta.

2. Identyfikacja wykwalifikowanego, niezależnego zespołu Zapewnienia Jakości znającego zarówno zagadnienia metodyki PMM jak i specyficznych wymagań Klienta.

3. Ustalenie zasad kontroli produktów w odniesieniu do ich priorytetu ważności w projekcie. Niniejsze zasady wymagają formalnej akceptacji przez wszystkie strony projektu.

4. Umieszczenie opisu kontroli jakości w opisach produktów prac w strukturze prac projektu.

5. Ustanowienie hierarchii zatwierdzania jakości produktów prac projektowych.

6. Przygotowanie planu Zapewnienia Jakości.

7. Zapewnienie, iż cały zespół projektowy został zapoznany z wymaganiami Zapewnienia Jakości.

8. Realizacja planu Zapewnienia Jakości w odniesieniu do planu projektu (produktów prac projektowych) oraz harmonogramu zewnętrznej kontroli projektu.

9. Bieżące uzupełnianie rozdziału Zapewnienie Jakości w Książce Kontrolnej Projektu.

2.2.5. Zarządzanie ludźmi i organizacją projektu

Faza PMM	Proces zarządzania	Zarządzanie i przywództwo	Komunikacja i praca grupowa	Organizacja projektu
Identyfikacja projektu	Identyfikacja i wybór kluczowych członków zespołu	Wybór metod zarządzania i przewodzenia zespołowi	Zdefiniowanie własnego zakresu odpowiedzialności i wymaganych kompetencji	Identyfikacja struktury organizacyjnej projektu
Inicjacja projektu	Ustalenie wymagań celów w odniesieniu do opisu zadań	Delegowanie i uzyskanie akceptacji przejęcia odpowiedzialności	Budowa zespołu, motywacja i spotkania	Definicja i dokumentacja struktury organizacyjnej projektu
Realizacja projektu	Przeglądy, ocena osiągnięć i kwalifikacji, doradztwo, informacja zwrotna o ocenie oraz podwyższanie umiejętności	Stosowanie metod zarządzania i przywództwa oraz przestrzeganie przyjętych zakresów odpowiedzialności	Spotkania, budowa wzajemnych relacji w pracy, formalna i nieformalna komunikacja, rozwój pracy zespołowej	Monitorowanie struktury organizacyjnej projektu
Ukończenie projektu	Docenienie sukcesu i nagrodzenie zespołu	Docenienie sukcesu i nagrodzenie zespołu	Docenienie sukcesu i nagrodzenie zespołu	Podsumowanie doświadczeń i dokumentacja

3. WSDDM - Narzędzia firmy IBM wspomagające zarządzanie przedsięwzięciami informatycznymi

Powodzenie projektu zależy w dużej mierze od zastosowania właściwej metodyki. Poprawna metodyka umożliwia poprawną definicję projektu, analizę ryzyka, systematyczne planowanie i wdrażanie rozwiązań, zarządzanie zmianami w przedsięwzięciu oraz ocenę postępu prac projektowych.

W ramach stosowanego przez IBM pakietu narzędzi do zarządzania projektami znajdują się programy:

• Planner 2

• Project Control Book 2 (PCB 2)

Planner znajduje zastosowanie w procesie przygotowywania planu projektu, natomiast Książka Kontrolna Projektu (PCB) jest wykorzystywana podczas codziennej pracy zespołu projektowego. Wspomaga organizację zespołu projektowego, zarządzanie spotkaniami oraz procesy zarządzania kontraktem, zmianami, ryzykiem i problemami.

3.1. Planner 2

Planner 2 jest aplikacją, która wspomaga Kierownika Projektu w opracowaniu planu projektu. Jej podstawową funkcją jest dostosowanie do aktualnych wymagań jednej lub więcej ścieżek projektowych spośród zdefiniowanych w Katalogu Ścieżek i Metod Projektowych.

Aplikacja składa się z trzech podstawowych części:

• Katalogu Ścieżek i Metod Projektowych,

• Przeglądarki dokonującej wizualizacji danych zawartych w katalogu,

• właściwej aplikacji Planner pozwalającej na modyfikację zdefiniowanych w Katalogu, ścieżek projektowych. Dostosowanie ich do potrzeb opracowywanych projektów, ocenę ryzyk, estymację czasu trwania przedsięwzięcia oraz wygenerowanie pliku z planem projektu i przyjętymi parametrami estymacji w formacie MS Project lub ABT Workbench.

3.1.1. Katalog Ścieżek i Metod Projektowych

Katalog zawiera dokładny opis 38 ścieżek projektów informatycznych. Ścieżki te dzielą się na dwa podstawowe rodzaje: Przygotowanie Oferty (Solution Design) i Wdrożenie Rozwiązania (Solution Delivery).

Wykaz wybranych ścieżek projektowych:

• P01 Client/Server Application Development

• P02 Infrastructure Design

• P03 Rapid Solutions

• P04 Information Engineering

• P05 Host-Based Application Development

• P06 Structured Development 1.0

• P07 Package Selection and Implementation

• P08 Package Implementation - SAP

• P09 Systems Integration and Rollout

• P10 Enhancement

• P11 Corrective Maintenance

• P13 Workflow Manager

• P14 One of a Kind

• P15 Object Technology - FastPath

• P16 Object Technology - Extended

• P22 Transformation 2000 Detailed Analysis & Planning

• P23 Transformation 2000 Implementation

• P32 Product and Rollout Services

• P33 Data Center Traditional Design and Build

• P34 Logical and Physical Connectivity

• P35 Data Center Fast Track Design Build

• P37 Europath

Każda ze ścieżek projektowych podlega dekompozycji na fazy, grupy zadań i pojedyncze zadania tworząc trójpoziomową strukturę prac.

Każde z zadań w strukturze prac projektowych ma zdefiniowane następujące parametry:

• opis zadania,

• produkty zadania,

• produkty zadań poprzedzających, które muszą być dostępne aby zrealizować niniejsze zadanie,

• role zaangażowane w realizację zadania,

• parametry estymacji czasu trwania zadania: najdłuższy, najkrótszy i sugerowany,

• techniki wykorzystywane do realizacji zadania.

Osobny rozdział Katalogu Ścieżek i Metod Projektowych został poświęcony metodyce zarządzania projektami PMM. Szczegółowa dekompozycja wszystkich zadań niezbędnych do poprawnego zarządzania przedsięwzięciem pozwala na wykorzystanie metodyki niezależnie od faktu czy opracowywany projekt należy do rodzaju Przygotowanie Oferty czy też Wdrożenie Rozwiązania.

3.1.2. Przeglądarka

Narzędzie to służy do wizualizacji danych zawartych w katalogu. Dane są zgrupowane w bloki tematyczne pozwalające na szybkie odnalezienie potrzebnych informacji:

1. Przygotowanie Oferty (zestaw ścieżek projektowych),

2. Wdrożenie rozwiązania (zestaw ścieżek projektowych),

3. Metodyka zarządzania projektami,

4. Techniki,

5. Formularze,

6. Role,

7. Słownik.

Na wydruku poniżej pokazano sposób wizualizacji zestawu dostępnych ścieżek realizacji projektów.

3.1.3. Planner

Właściwe narzędzie stosowane w procesie planowania projektu. Posiada cztery podstawowe moduły:

1. Definicja projektu.

2. Planowanie.

3. Estymacja czasu trwania projektu.

4. Transfer planu projektu do aplikacji MS Project 98 lub ABT Workbench.

W definicji projektu zawarte są wszystkie podstawowe informacje o projekcie czyli: nazwa projektu, klient, rodzaj projektu, zastosowana metodyka zarządzania projektami oraz poziom dostępu do opracowywanego planu.

W module planowania identyfikowane i analizowane są ryzyka związane przedsięwzięciem, wybierana jest ścieżka projektowa (lub grupa ścieżek albo ich wyselekcjonowane fazy), która następnie jest dostosowywana do wymagań projektowych.

W module estymacji szacowany jest czas trwania poszczególnych faz projektowych. Szacowane są zarówno fazy związane z wykonaniem zadań technicznych jak i zadań powiązanych z procesem zarządzania przedsięwzięciem oraz zadań powiązanych z procesem zarządzania ryzykiem.

Na tym etapie stosowanych jest kilka technik estymacji:

• Metoda Punktów Funkcyjnych,

• dekompozycja fazy projektu i szacowanie szczegółowe zadanie po zadaniu,

• ekstrapolacja wyników szacowania szczegółowego na pozostałe fazy,

• narzuty czasowe.

Na koniec opracowany plan projektu generowany jest w formacie MS Project 98 lub ABT Workbench. Można na niego nałożyć, przy wykorzystaniu tych narzędzi, kalendarz projektu, przypisać poszczególnym rolom dostępne zasoby i opracować harmonogram całego przedsięwzięcia.

3.2. Project Control Book 2 (PCB 2)

Książka Kontrolna Projektu (PCB 2) została opracowana na platformie Lotus Notes z pełnym wykorzystaniem funkcjonalności tego systemu w zakresie zarządzania dokumentami i pracy grupowej.

Głównym celem prowadzenia Książki Kontrolnej Projektu jest dokumentowanie wszelkich istotnych z punktu widzenia projektu decyzji i aktywności. Wewnętrzne powiązania pomiędzy dokumentami ułatwiają wypełnianie formularzy zgodnie ze zdefiniowanymi procesami.

Książka posiada 11 rozdziałów:

0. Standardy i procedury - standardowe i nowe procedury.

1. Organizacja - role i przypisane im osoby, zakres obowiązków, odpowiedzialność

2. Punkty węzłowe - opisy i terminy.

3. Plany - plan bazowy, kolejne modyfikacje i aktualny plan projektu.

4. Spotkania - agenda, raport, decyzje.

5. Ryzyka - identyfikacja, analiza, decyzja, monitorowanie.

6. Zmiany - żądanie, analiza, decyzja.

7. Problemy - raport, analiza, decyzja.

8. Błędy - raport, analiza, decyzja.

9. Kontrakty z klientem - kontrakt, aneksy, ustalenia.

10. Kontrakty z podwykonawcami - kontrakt, aneksy, ustalenia.

4. Literatura

1. Capers Jones (1996), Applied Software Measurement, McGraw-Hill

2. Meredith J.R., Mantel S.J. Jr. Project Management A Managerial Approach, John Wiley & Son

3. PMI Standard Committee (1996), A Guide to the Ptoject Management Body of Knowledge, Project Management Institute

4. Exception Management Guide, IBM Corporation

5. Financial Management Guide, IBM Corporation

6. Organization and People Management Guide, IBM Corporation

7. Project Completion Guide, IBM Corporation

8. Project Control Book Guide, IBM Corporation

9. Project Definition Guide, IBM Corporation

10. Quality Management Guide, IBM Corporation

11. Risk Management Guide, IBM Corporation

12. Work Breakdown Structure Guide, IBM Corporation

Praca pochodzi z serwisu www.e-sciagi.pl

1

Zasada tworzenia planu projektu w aplikacji Planner

Architektura aplikacji Planner

Implementacja zmian w projekcie (źródło: A. Bylicki, IBM Polska)

Model metodyki PMM

4. Ukończenie

3. Realizacja

2. Inicjacja

1. Identyfikacja

Śledzenie

Wyjątki

Ukończenie

Przegląd

Realizacja

Planowanie

Start

Organizacja

Definicja

Akceptacja

Identyfikacja

---