zarzadzanie projektami informatycznymi, ŚCIĄGI Z RÓŻNYCH DZIEDZIN, zarzadzanie


Projekty biznesowe, w tym projekty informatyczne, służą wprowadzaniu zmian w firmie.

Z  tego powodu ich realizacja wymaga należytego traktowania w przedsiębiorstwie i jest zagadnieniem szczególnie ważnym - oddziałuje bowiem na zasoby firmy przeznaczone do projektui  ma wpływ na późniejsze działanie firmy po zakończeniu

projektu (wprowadzeniu zmiany).

Rola projektów winna być w odpowiedni sposób umiejscowiona w strategii przedsiębiorstwa, tak, aby wychodząc z tej strategii, planować, organizować i realizować projekty biznesowe, czyli skutecznie wprowadzać zmiany w przedsiębiorstwie.

PROJEKT

(definicja wg British Standards 6079):

niepowtarzalny zestaw skoordynowanych działań o określonych punktach początkowym i końcowym, podejmowanych przez jednostkę lub organizację dla zrealizowania określonych celów, przy określonych parametrach, odnoszących się do czasu, kosztów i efektów.

Projekt powinien mieć ściśle określone:

Klasyczne standardy zarządzania obejmujące:

nie spełniają wprost wymogów projektów.

ZARZĄDZANIE PROJEKTEM

(definicja wg British Standards 6079):

jest to planowanie, monitorowanie i nadzorowanie wszelkich aspektów projektu oraz motywowanie wszystkich osób, zaangażowanych w przedsięwzięcie, z wykorzystaniem wiedzy odpowiednich narzędzi i technik w celu osiągnięcia założonych celów projektu terminowo i zgodnie z założonymi kosztami, jakością i skutecznością.

Projekt informatyczny ma dwa wymiary:

Za pierwszy odpowiadają kierownicy projektu,

za drugi kierownicy zespołów informatyków.

Procesy kierownicze:

Planowanie projektu

Kosztorysowanie projektu

Tworzenie harmonogramu

Organizowanie zespołów

Przygotowanie kontraktu

Zarządzanie zmianami

Zarządzanie jakością

Zarządzanie ryzykiem

Zarządzanie komunikacją

Procesy produkcyjne:

Specyfikacja wymagań

Specyfikacja architektury

Analiza wymagań

Projektowanie systemu

Implementacja

Integracja i testowanie

Instalacja

Szkolenia i wdrożenie

Pielęgnacja systemu

Rodzaje projektów informatycznych:

Produkcja oprogramowania

Integracja systemowa

Usługi instalacyjne

Usługi serwisowe (serwis sprzętu i pielęgnacja oprogramowania)

Usługi wdrożeniowe

...

jakie jeszcze?


C
ykl życia projektu
(procesy produkcyjne)

Projekt informatyczny zawsze oznacza nową sytuację, nieznane warunki realizacji, a także bardzo ograniczony zakres i przydatność doświadczeń.

Sformalizowane gromadzenie, analizowanie i wykorzystywanie najlepszych praktyk projektowych - najlepszy sposób na wypracowanie i twórcze zastosowanie własnej metodyki produkcji oprogramowania, jego wdrożenia i pielęgnowania.

Czynniki ryzyka:
- brak zaangażowania zarządu,
- niejasne określenie wymagań przez użytkownika
(słabo zdefiniowany zakres prac),
- klient nie przygotowany do swojej roli,
-  brak oceny ryzyka i planów awaryjnych,
-  niewłaściwy proces wprowadzania zmian i brak
marginesu bezpieczeństwa (budżet na zmiany: 5...25%),
- zmieniająca się struktura organizacyjna,
- zmieniające się przepisy prawne,
- nieumiejętność wybrania odpowiedniej technologii
informatycznej,
- niezadawalający przebieg procesu tworzenia systemu,
- niedostateczne wytestowanie.

Największym zagrożeniem projektów informatycznych są ludzie:
- informatycy wszystko
wiedzą,
- użytkownicy cudu
oczekują.

Elementy dobrej praktyki:

Dokumentacja inicjująca projekt powinna zawierać co najmniej:
- określenie celu biznesowego projektu wraz z uzasadnieniem,
- opis organizacji zespołu projektowego,
- definicję zakresu przedsięwzięcia (produkty i usługi),
- dokumentację koncepcji technicznej,
- plan projektu,
- plan zapewnienia jakości,
- procedury kontroli i raportowania przebiegu prac,
- ocenę ryzyka.

Dokumentacja musi objąć cztery główne wymiary projektu: zakres, czas, budżet i jakość.

Typowa struktura organizacyjna:
- Sponsor Projektu,
- Komitet Sterujący,
- Szef Projektu,
- Zespoły techniczne,
- Komitet Kontroli Zmian.

Zależnie od skali i potrzeb danego projektu zaleca się rozważenie potrzeby określania dalszych ról:
- Szef Projektu ze strony klienta,
- Szefowie zespołów technicznych,
- Komitet Akceptacyjny i zespoły do spraw testów akceptacyjnych,
- Szef Jakości,
- Biuro Projektu.

W projektach mniejszych, nie wymagających licznej obsady kadrowej, należy dążyć do maksymalnego uproszczenia struktury organizacyjnej.

W dużych projektach koszty zarządzania projektem mogą osiągać nawet 20-50% łącznego budżetu projektu.

Komitet Sterujący Projektu:
- przewodniczący Ktoś z zarządu,
- sponso
r Ktoś z zarządu (odpowiedzialny za budżet projektu),
- członkowie
Dyrektorzy najważniejszych departamentów Dyrektor departamentu informatyki, przedstawiciele Wykonawcy.

Szef Projektu
pełni kluczową rolą w całym przedsięwzięciu.
Co raz częściej powołuje się dwóch Szefów: ze strony dostawcy i klienta. Wspólnie tworzą oni Zarząd Projektu - operacyjną komórkę, kierującą pracą wszystkich zespołów.
Według British Standard (BS 4335:1987)
Szefem Projektu jest osoba, której przekazano uprawnienia i odpowiedzialność w celu ogólnego zarządzania zasobami projektu (w aspektach technicznych i kosztowych) oraz motywowania wszystkich zainteresowanych.

Elementy dobrej praktyki:
W metodyce PRINCE 2 dokument inicjująca projekt ang. PID - Project Initiation Document ma następującą strukturę:
1. Cel dokumentu
Co projekt ma osiągnąć?
Dlaczego osiągnięcie tych celów jest istotne?
Kto będzie realizował zarządzanie projektem (role i zakresy odpowiedzialności)?
Jak i kiedy omówione tu przygotowania zostaną zrealizowane?
2. Tło projektu
Wszelkie źródła przedsięwzięcia, poprzednie raporty czy dokumentacja, jakie mogą wpływać na prace projektowe, inne powiązane projekty.

3. Cele projektu
Konkretnie i mierzalne. Warto rozdzielić cele projektu (np. oczekiwane daty, profil wydatków) i jego wyniki (co ma być rezultatem produktów końcowych projektu podczas ich użytkowania po zakończeniu prac)
4. Zakres, wyłączenia, interfejsy
Zakres to główne obszary, funkcje, procesy itp., jakie mają być objęte projektem. Wyłączenia i interfejsy opisują, co znajduje się w projekcie, a co pozostaje poza nim. Interfejsy to logiczne powiązania z innymi działaniami, np. sposób wykorzystania tworzonych informacji, dalszy rozwój powstałych produktów itp.

5. Produkty
Lista oczekiwanych i pożądanych produktów, rezultatów, wyników, jakie projekt winien stworzyć lub uzyskać.
6. Korzyści biznesowe
Powody podjęcia projektu - z punktu widzenia osób finansujących działania. Projekt powinien być mierzony również w zakresie korzyści biznesowych, do czego niezbędna jest Analiza Kosztów i Korzyści.
7. Ograniczenia i zagrożenia
Ograniczenia pod względem czasu, zasobów, funduszy i akceptacji. Jest to określenie zasobów projektu, do których nie może on sięgnąć. Uzupełnienie ograniczeń i wyłączeń, szczególnie odnośnie sfery biznesowej. Wszelkie inne założenia przyjęte w związku z realizacją projektu.

8. Organizacja projektu
Wskazanie osób tworzących Zespół Zarządzania Projektem - Szefa Projektu, Komitetu Sterującego, Audytora-Szefa Jakości, Szefów Zespołów. Dla każdej z tych ról koniecznie trzeba wskazać zakresy odpowiedzialności.
9. Plan Jakości
Opis podejścia stosowanego przez zespół wykonawczy dla dostarczenia produktów spełniających oczekiwania jakościowe użytkowników. Często wskazuje się tu standardy jakościowe dostawcy.
10. Kryteria akceptacji
Zdefiniowanie w kategoriach mierzalnych wszystkiego, co ma powstać jako rezultaty projektu.
11. Plan Projektu
Zestawienie głównych produktów, działań i zasobów niezbędnych dla uzyskania oczekiwanych wyników projektu. Plan Projektu jest podstawą nadzorowania postępu i kosztów w każdym etapie prac.
12. Sposoby Kontroli Projektu
Częstotliwość oczekiwanych przeglądów przez Kierownictwo. Przeglądy te w postaci Ocen Zakończenia Etapów mają na celu przegląd projektu w jego ważnych momentach (ang. milestones) dla zatwierdzenia już wykonanych prac i przyznania zasobów na kolejny etap. Trzeba też opisać organizację raportowania bieżącego (format, przeznaczenie, częstotliwość): wykonawców dla klienta/użytkownika, zespołów wykonawczych dla Szefa Projektu itd.

13. Obsługa problemów i zarządzanie zmianami Wskazanie dopuszczalnej tolerancji projektu, opis Procedury Obsługi Problemów do stosowania przy wystąpieniu odchyleń od przyjętego planu. Zalecane jest też przygotowanie szczegółowej procedury Kontroli Zmian.
14. Plany awaryjne.
Określenie planów awaryjnych, jakie zostały przewidziane w planach projektu. Powinny one być uzupełnione Analizą Ryzyka.
Tutaj:
Podpis Szefa Projektu: ....

Podpis Klienta/Użytkownika: ...
Podpis Przewodniczącego Komitetu Sterującego .......

Data: ...

PLANOWANIE.

Bywa, że zarządzanie projektem sprowadza się po prostu do obsługi jego planów. Takie zwężenie zagadnienia jest fatalnym błędem, o opłakanych skutkach dla powodzenia przedsięwzięcia.

Planowanie istotnie jest niezwykle ważną częścią pracy Szefa Projektu - dlatego niezbędne jest nabycie przez niego odpowiedniej wiedzy, zagadnień, technik i problemów z obszaru planowania projektu.

Plan projektu to:
- racjonalny opis zadania i sposobu jego wykonania,
- narzędzie do osiągania celu (pomiar, korekty),
- „mapa przyszłości” - obraz tego, czego należy oczekiwać
w projekcie,
- narzędzie „kupowania” sponsora i zespołu - sposób
pozyskiwania zaufania i współpracy.

Od strony technicznej planowanie stanowi:
- narzędzie koordynacji działań zespołu i podwykonawców,
- sposób koordynowania posiadanych zasobów,
- podstawę mierzenia postępu i kontrolowania projektu,
- podstawę kontroli zmian,

Plan służy do:

-Planowania zasobów

-planowania kosztów

-kontroli postępu

-rozliczenia się z pracy

Techniki planowania
Najbardziej znanym wymiarem planowania jest planowanie działań i czasu. Wykonuje się to przy użyciu rozmaitych technik, z których najbardziej popularne to:
- WBS - struktura działań (ang.
Work Break- Down Structure),
- Sieć PERT - schemat powiązanych działań,
- Wykres Gantta.

Diagram PERT
Przy pomocy tej techniki wygodnie jest prowadzić analizę tzw. ścieżki krytycznej, czyli zestawu kolejnych czynności, których łączny czas realizacji daje najdłuższy przebieg w projekcie. Sieć daje również przejrzysty obraz zależności między poszczególnymi działaniami.

Planowanie Według Produktów
polega na rozpoczęciu planowania od określenia produktów projektu: najpierw produktów głównych/końcowych (zwykle wymienianych w kontrakcie lub innych dokumentach projektu), następnie produktów pośrednich (niezbędnych do wytworzenia produktów końcowych), ewentualnie również produktów technicznych, nie wymaganych przez klienta/odbiorcę.

Z kolei dla każdego produktu określa się zestaw czynności i działań prowadzących do jego wytworzenia. Po ustaleniu działań
- w postaci prostej listy - należy wzbogacić ją o zależności
i przekształcić w listę hierarchiczną, a następnie umieścić ją
w kalendarzu projektu, uzupełnić o zasoby realizacyjne,
skorygować harmonogram o dostępność zasobów itd.

Szacowanie projektu.

Oszacowaniu w projekcie informatycznym podlega wiele rzeczy - począwszy od najbardziej naturalnych, takich jak: pracochłonność, wydajność pracownika, wielkość zatrudnienia w każdej fazie projektu, koszty w różnych przekrojach i czasie, zasoby materialne potrzebne do realizacji projektu (urządzenia i ich obciążenie, materiały, itp.), aż po mniej oczywiste: straty czasu na działania nieprodukcyjne, kwalifikacje pracowników, jakość dostaw i obsługi, zagrożenia realizacji projektu. Nawet takie elementy, jak założenia, według których realizowany jest projekt, są w wielu przypadkach jedynie szacunkiem. Szacuje się ponadto czas pracy w firmie (nie zawsze jest to równo osiem godzin), liczbę podróży służbowych do klienta, czas dojazdu, itp.

Metody szacowania projektów

Szacowanie zasobów w projektach informatycznych jest kombinacją dobrych danych historycznych (doświadczeń) i metod ich wykorzystania w nowych przypadkach. Metody są różne i zwykle wykorzystywane są łącznie, tj. do oszacowania zasobów projektu wykorzystuje się równocześnie dwie metody lub więcej. Można wyróżnić następujące możliwe sposoby szacowania zasobów projektów informatycznych:

Typowe straty czasu związane z realizacją projektu to:

Pamiętaj o regule 40-20-40:

- 40% czasu projektu powinno zajmować planowanie, analiza wymagań i projekt systemu,

- 20% czasu - kodowanie,

- a pozostałe 40% - testowanie i pielęgnacja.

Nie kieruj nowych pracowników do spóźnionego projektu, bo zakończy się on jeszcze później.

(prawo Brooksa - przyczyn należy szukać w zwiększeniu strat czasu na komunikację pomiędzy członkami zespołu z jednej strony i niepodzielnością pewnych prac - z drugiej)

Procedury kontroli i moment ich wystąpienia w projekcie powinny być opisane w Planie Projektu.

Ustanowienie procedur kontroli to opisanie:

Kontrola postępu prac, poprzez:

raporty okresowe:

tygodniowe, miesięczne, kwartalne, z zakończenia fazy/etapu, notatki ze spotkań Zarządu Projektu i Komitetu Sterującego

raporty z przeglądów (przewidzianych w Planie Projektu):

z testowania, z przeglądu dokumentacji,

z Przeglądu Jakości, raporty z Audytu itd.

raporty problemowe (nie przewidziane w planie)

notatki ze spotkań roboczych

Kontrola produktu.

Przeglądy produktów projektu na różnych etapach jego realizacji:

- wyników analizy,

- projektu systemu,

- kodu programów,

- procesu testowania,

- instalacji,

- wdrożenia systemu i szkolenia użytkownika,

- pielęgnacji systemu.

Testowanie oprogramowania (oczywiście opis wymagań użytkownika stanowi podstawę do testowania):

- iteracyjne,

- wstępujące i zstępujące,

- funkcyjne (śledzenie wymagań),

- testowanie regeneracji (symulowanie awarii)

- efektywności (wielkość zbiorów, czas odpowiedzi)

- wyczerpujące (wszelkie możliwe dane i sytuacje), ale jest niewykonalne! Wojny Gwiezdne

Plan testów oprogramowania zawiera:

- Cel testowania (co jest testowane i po co?)

- Miejsce i termin testu (gdzie i kiedy?)

- Opis testu (opis danych testowych wejść i wyjść)

- Procedury testowania (jak przeprowadzić test?)

a Raport z testów zawiera:

- Protokół z decyzjami (do uzupełnienia, do poprawy, brak funkcji) wraz z werdyktem

- Listę problemów wymagających uwagi

Jakość w projekcie

Nie może zapewnić jakości

w projekcie bez efektywnego zarządzania

Poul Beynon-Davies.

Cechy opisujące jakość SI nie są i nie mogą być jednorodne.

Model jakości oprogramowania MacCalla:

1. Działanie (funkcjonowanie) programu

2. Modyfikowalność programu

3. Mobilność programu

Innym modelem jest drzewo jakości wg Brinkwortha:

1. Cechy funkcjonalne

1.1. Widoczne dla użytkownika

- funkcjonalność

- raportowanie działań

- słownictwo

- samokontrola

- odporność na błędy

- zrozumiałość

1.2. Ukryte przed użytkownikiem

- jakość modelu danych

- integralność danych

- testowalność

- gotowość

2. Cechy niefunkcjonalne

2.1. Widoczne dla użytkownika

- wydajność

- pojemność

- interfejs

- wspomaganie

- dostępność

- archiwizowalność

- zabezpieczenia

2.2. Ukryte przed użytkownikiem

- przenośność

- wydajność

- bezpieczeństwo

- rozszerzalność

- konfigurowalność

- modyfikowalność

- możliwość ponownego użycia

Normy jakości oprogramowania

Norma międzynarodowa ISO 9000-3: „The Application of ISO 9001 to Software”

Wytyczne do stosowania normy ISO-9001 podczas opracowywania, dostarczania i obsługiwania oprogramowania

(PN-ISO 9000-3: 1994)

Plan Jakości

za jego realizację odpowiedzialni są WSZYSCY członkowie

zespołu projektowego - zarówno po stronie klienta,jak i dostawcy.

Zgodnie z teorią TQM (kompleksowe zarządzanie jakością, ang. Total Quality Management) jakość dotyczy kultury CAŁEJ organizacji.

Jednym z elementów tej metody jest ciągłe usprawnianie procesów - na pierwszym planie znajdują się nie stanowiska zajmowane przez pracowników, lecz realizowane przez nich działania. W. Edwards Deming zaproponował, żeby wprowadzać ciągłe zmiany w firmie, nakierowane na jakość, zgodnie z cyklem PDCA (ang. Plan-Do-Check-Act, tzw. KOŁO DEMINGA). Zarządzanie procesami rozumiane jest jako systematyczne, strukturalne podejście do analizy ciągłego usprawniania i kontroli działań w celu zwiększenia jakości produktów i usług.

Plan Jakości powinien zawierać m.in.:

Szef Jakości - zarządzanie jakością.


Szef Jakości powinien być mianowany przez Komitet Sterujący i jemu też podlega. Jego praca nie ma charakteru kontrolera Szefa Projektu. W poprawnie zdefiniowanych projektach obaj Szefowie ściśle współpracują ze sobą, wspólnie przyczyniając się do sukcesu przedsięwzięcia.
Kompetencji Szefa Jakości podlegają wszystkie zagadnienia związane z projektem w kontekście jakości: plany i wszelka dokumentacja zarządcza, tworzone produkty i ich testy, praca zespołów technicznych i kontakty z poddostawcami, gospodarka finansowa i zarządzanie ryzykiem. Mimo tak szerokiego opisania roli Szefa Jakości nie jest to zwykle praca „na pełny etat”.

Każde wprowadzanie zmian, czyli realizacja projektu, jest ryzykowne - może być szansą lub stać się zagrożeniem.

Ta oczywista prawda musi przekładać się na pragmatykę zarządzania przedsięwzięciami - jeżeli uzna się występowanie zagrożeń, to należy uwzględnić dotychczasowe doświadczenia projektowe i nie rozpoczynać przedsięwzięcia bez analizy ryzyka.

Typowy proces zarządzania ryzykiem wyróżnia zwykle fazy:

IDENTYFIKACJI, ANALIZY I KONTROLI RYZYKA.

W procesie identyfikacji ryzyka posługujemy się najczęściej następującymi narzędziami:

Analiza ryzyka

dostarcza informacji (ilościowego oszacowania niepożądanych skutków), pozwalających na podjęcie decyzji, co do sposobu ograniczenia ryzyka.

Powszechnie używaną miarą ryzyka jest spodziewana wartość kosztowa, jako iloczyn:

ryzyko = prawdopodobieństwo * skutek

Kontrola ryzyka w projekcie to proces nieustannego:

Przede wszystkim należy jednak zaakceptować fakt istnienia ryzyka niepowodzenia projektu.

Nie ma też prostej metody na 100% osiągnięcie sukcesu w projekcie

- istnieją jedynie sposoby na zmniejszenie prawdopodobieństwa porażki.

Najważniejszym z nich jest zastosowanie sprawdzonej metodyki realizacji projektów. Zasada ta dotyczy każdego większego projektu, w każdej branży.

Nowy system zrealizuje tylko te wymagania, które wcześniej wykryli i opisali analitycy.
Informatycy i użytkownicy skazani są na współpracę.

Przeprowadzone wiosną 1995 roku - w ramach projektu ESPITI - badania ankietowe 10 tys. europejskich firm produkujących oprogramowanie wykazały, że 65 % swoich problemów firmy upatrują w specyfikacji
i zarządzaniu wymaganiami klienta.
Dowodzi to niezbicie, że pod koniec XX wieku głównym problemem jest nie to, jak budować systemy informatyczne, ale to, jak i od kogo dowiedzieć się, jakie są rzeczywiste potrzeby, wymagania i oczekiwania przyszłego użytkownika.

Elementy dobrej praktyki:

Realizacja przedsięwzięć informatycznych powinna być poprzedzona analizą potrzeb użytkownika, której produktem jest dokument określający wymagania na system informatyczny.
Norma PN-ISO 9000-3:1994: pkt 5.3
Należy dotrzeć do wszystkich kluczowych przyszłych użytkowników systemu !!!

Inżynieria oprogramowania jest praktycznym zastosowaniem odpowiedniego zestawu technik do całego procesu opracowania oprogramowania.

Typowe modele produkcji oprogramowania:

- Model kaskadowy,

- Rapid Application Development (RAD)

- Model sekwencyjny,

- Prototypowanie,

- Model spiralny,

Trzy najważniejsze zasady inżynierii oprogramowania to:

1. Zestaw technik jest użyty w celu poprawienia jakości i produktywności.

2. Techniki te są stosowane w sposób zdyscyplinowany, a nie dowolny.

3. Techniki te są stosowane do całego procesu opracowania oprogramowania.

INŻYNIERIA WYMAGAŃ JEST KLUCZOWYM ELEMENTEM INŻYNIERII OPROGRAMOWANIA !

Jakość pracy analityka

Inżynieria wymagań jest określeniem, pod którym kryją się wszystkie działania zmierzające do wypracowania i przeprowadzenia racjonalnych i systematycznych procedur:

Pojęcie to odnosi się do ogólnej metodyki zdobywanie wszelkich informacji, mających charakter wymagań, a w szczególności do etapu analizy wymagań oprogramowania, który jest naturalnym rozwinięciem fazy ogólnego opisu systemu (patrz: inicjacja projektu).

Pozyskiwanie wymagań od użytkownika:

Istnieje wiele gotowych inżynierskich metod pozyskiwania, analizy i specyfikacji wymagań, takich jak JAD, RAD, analiza strukturalna, analiza obiektowa, prototypowanie, Oracle CASE, UML itd.

Metody te oferują sprawdzone w praktyce rozwiązania szczegółowych działań, prowadzących do pomyślnego określenia wymagań użytkownika oraz odwzorowania ich na specyfikację pozwalającą na realizację systemu.

Zarządzanie Zmianami.

rys

Zarządzanie Zmianami.
Przed podjęciem decyzji o wprowadzeniu zmian do projektu analizuje się:
- rozmiar i zakres zmian,
- złożoność,
- ograniczenia czasowe,
- wpływ na bieżący stan projektu (prace skończone i przyszłe),
- zasoby wymagane do realizacji,
- koszt,
- ryzyko niepowodzenia,
- politykę firmy, produktu, projektu,
- wymagania udziałowców,
- alternatywne sposoby realizacji zmian.


Przed podjęciem decyzji należy rozważyć następujące aspekty wprowadzenia zmiany:
- Czy zmiana nie jest na tyle poważna, że bardziej opłaca się stworzyć
nowy produkt?
- Czy lepiej zmienić istniejące fragmenty systemu, czy też dobudować
nowy moduł, komponent?
- Czy zmiana ma dotyczyć wszystkich klientów korzystających z
systemu, czy jedynie ich części, a więc czy z jednego produktu robią
się dwa produkty?
- Jak zmiana wpłynie na wydajność systemu: poprawi ją, pogorszy czy
pozostawi bez zmian?
- Jaki jest konieczny zakres modyfikacji elementów towarzyszących
programowi, a więc w dokumentacji technicznej, w dokumentacji
użytkowej, w programach szkoleń itp.?

Komitet Kontroli Zmian - zarządzanie zmianami.
Podstawą prac i rozliczania postępu jest tzw. Linia Główna Projektu, którą stanowią: plan i wszystkie zatwierdzone później zmiany. Na początku jest to pierwszy plan zatwierdzony przez Komitet Sterujący do realizacji.

Komitet Kontroli Zmian składa się z przedstawicieli obu stron: dostawcy i  klienta, gdyż jest ciałem mediacyjnym. Często, choć nie jest to konieczne, w Komitecie uczestniczą obaj Szefowie Projektu, zwykle wspomagani przez najważniejszych specjalistów technicznych (np. projektanta systemu, architekta, szefa testów itp.)

Zamknięcie projektu

poprawa procesów w zarządzaniu projektami jest możliwa, jeżeli zespół ma okazję na refleksję nad swoją dotychczasową pracą i uczy się w ten sposób na swoich błędach, ale i sukcesach.

Ewaluacja zrealizowanego projektu możliwa jest, jeżeli wcześniej zaplanujemy zbieranie i archiwizowanie informacji na temat projektu - zgromadzona wówczas baza wiedzy posłuży do oceny i porównania.

Ewaluacja:

NIE SZUKAMY WINNEGO !

ZAPISUJEMY WNIOSKI !

SKUPIAMY SIĘ NA OBSZARACH, NA KTÓRYCH MOŻNA UZYSKAĆ NAJWIĘKSZĄ POPRAWĘ

Opublikować wyniki i wdrożyć wyniki ewaluacji.

LIST OTWARTY DO ZESPOŁÓW PROJEKTOWYCH:

I DYSKUSJA

Szef Projektu pełni kluczową rolą w całym przedsięwzięciu.

Szefem Projektu jest osoba, której przekazano uprawnienia i odpowiedzialność w celu ogólnego zarządzania zasobami projektu (w aspektach technicznych i kosztowych) oraz motywowania wszystkich zainteresowanych.

Pierwotnie stanowisko „kierownika projektu” zostało utworzone przy złożonych i  dynamicznie zmiennych pracach (projektach) w przemyśle obronnym i farmaceutycznym.

Działalność Szefa Projektu:

Jak widać oczekiwania w stosunku do kierowników projektów są wyjątkowo wysokie ...

Rola Kierownika Projektu

Potrzeba pracy zespołowej - Kierownik projektu musi pamiętać o prawidłowych relacjach z zespołem projektowym - od umiejętności zbudowania przedsiębiorczego zespołu zależy sukces projektu. Zespół realizuje wspólne cele, przy pomocy ustalonych przez Szefa Projektu standardów działania.

Konflikty w zespole, wynikające z dużego stresu, napiętych harmonogramów, błędów i porażek pojawiających się w trakcie pracy, muszą być przez Szefa Projektu rozpoznawalne i w porę usuwane.

Konflikt między ludźmi jest to proces antagonizmu, który pojawia się zawsze, gdy jedna osoba lub jednostka organizacji podważa osiągnięcia drugiej [Johns Istota i natura konfliktu, 1992].

Szef Projektu powinien pamiętać, że:

- konflikt zawsze związany jest z działaniami ludzi,

- nie można go wyeliminować,

- gdy jest nierozpoznany staje się zagrożeniem,

-/+ jeśli się go bada i analizuje

-/+ można mu zapobiec,

-/+ jeśli zna się naturę konfliktu,

+ można nim sterować

+i uzyskiwać lepsze efekty tych samych działań.

W zasadzie można wyróżnić trzy drogi prowadzące do poprawy zachowań przywódczych:

- Poprzez doświadczenie - learning by doing

- Poprzez obserwację - learning from others

- Poprzez edukację - learning in the classroom or on your own

J. Adair sformułował Krótki kurs budowania zespołu dla menedżera:

Jaką masz na ten temat opinię?

Czy mógłbyś to zrobić, proszę?

Przepraszam, że popełniłem błąd ...

Świetnie się spisałeś ...

Dziękuję Ci ...

My ...

Ja ...

Szef Projektu powinien zwracać uwagę na etapy rozwoju grupy i dążyć do jej ewolucji w kierunku wysoce efektywnego zespołu, w którym występuje efekt synergii - to znaczy wynik uzyskiwany przez zespół jest większy od sumy wyników indywidualnych członków zespołu. Aby to osiągnąć należy:

(wg. A. L. McGinnisa)

Delegować to:

1. Jasno określić zadania i cele.

2. Użyć narzędzi motywujących.

3. Opisać zakres uprawnień.

4. Udzielić pomocy i szkolenia.

5. Określić TERMIN wykonania zadania

6. Zachęcać do udzielania informacji zwrotnej.

7. Ustalić harmonogram sprawozdawczości.

8. Zwięzłość przekazu.

9. Dobór słownictwa.

10. Użycie słów kluczowych.

Poniższe zalecenia (best practices) i ostrzeżenia (worst practices) pochodzą od największych autorytetów w dziedzinie zarządzania projektami i produkcją oprogramowania, którzy tworzą grupę opracowującą narzędzia do doskonalenia procesów wytwarzania oprogramowania dla Departamentu Obrony USA.

Grupa ta zorganizowana jest pod nazwą Software Program Managers Network (www.spmn.com)

Zalecenia (best practices):

Ostrzeżenia (worst practices):

Tom DeMarco i Timothy Lister

zwracają ogromną uwagę na „miękkie” aspekty zarządzania informatykami, podkreślając, że produktywność zespołów może różnić się o rzędy wielkości, nie z powodu różnic w wyszkoleniu, czy stosowaniu odmiennych technik, ale właśnie z powodu sposobu, w jakim członkowie zespołu informatyków komunikują się ze sobą i ze światem użytkownika na poziomie wymiany informacji, a zwłaszcza emocji.

„Peopleware: Productive Projects and Teams”

Praca pochodzi z serwisu www.e-sciagi.pl



Wyszukiwarka

Podobne podstrony:
zarządzanie projektami - ściąga, ŚCIĄGI Z RÓŻNYCH DZIEDZIN, zarzadzanie
Zarządzanie informacją - systemy CRM, ŚCIĄGI Z RÓŻNYCH DZIEDZIN, zarzadzanie
Zarządzanie projektami ekonomicznymi i organizacyjnymi, ŚCIĄGI Z RÓŻNYCH DZIEDZIN, zarzadzanie
zarządzanie projektem, ŚCIĄGI Z RÓŻNYCH DZIEDZIN, zarzadzanie
Zarządzanie kadrami - ściąga 3, ŚCIĄGI Z RÓŻNYCH DZIEDZIN, zarzadzanie
Zarzadzanie Zasobami Ludzkimi, ŚCIĄGI Z RÓŻNYCH DZIEDZIN, zarzadzanie
Zarządzanie - test 1, ŚCIĄGI Z RÓŻNYCH DZIEDZIN, zarzadzanie
Międzynarodowe zarządzanie zasobami ludzkimi, ŚCIĄGI Z RÓŻNYCH DZIEDZIN, zarzadzanie
organizajca i zarządzanie sp, ŚCIĄGI Z RÓŻNYCH DZIEDZIN, zarzadzanie

więcej podobnych podstron