(problemy) projektu

Transkrypt

(problemy) projektu

Zarządzanie projektów
Część 2
Role w zarządzaniu projektami
• Menadżer (kierownik) projektu - prowadzący projekt
nie powinien przeszkadzać swoim pracownikom, a jest to
rzadka umiejętność przywódcy*
• Sponsor projektu (finansujący, wspierający, naczelne
kierownictwo)
• Członek zespołu (ang. project team)
• Przedstawiciel użytkownika
• Pracownik działu wsparcia technicznego
• Lider
• Klient - odbiorca projektu
*
Michał Hałas, To ludzie robią przedsięwzięcia, I Konferencja Project
Management - Doświadczenia i Metody, http://www.spmp.org.pl
Chief Project Officer
Chief Project Officer
Project Portfolio Manager
Project Portfolio Manager
Strategic Project Office Director Strategic Project Office Director
Manager of Project Support
Manager of Project Support
Manager of Project Managers
Manager of Project Managers
Project Management Mentor
Project Management Mentor
Program Manager
Program Manager
Project Manager
Project Manager
Project Team Leader
Project Team Leader
Project Support Team Member Project Support Team Member
Project Controller
Project Controller
Project Planner
Project Planner
Project Scheduler
Project Scheduler
Outlines Project Management Job Descriptions
http://www.pmsolutions.com/press/113004.htm
•
•
•
•
Jaki jest sens danej roli?
Jakie wymagania wobec kandydata stawia dana rola?
Jakie kursy i trening są niezbędne?
Jak oceniać osoby, które wykonują te role, jakie kryteria
stosować?
• Jak oceniać potrzeby firmy w dziedzinie zarządzania
projektami?
Kierownik projektu
• Kierownik projektu
- dodatkowe źródło kosztów?
- pośrednik między użytkownikami a ekipą projektu
- kierownik projektu nie gwarantuje jego powodzenia
• Co kierownik projektu może wnieść do projektu?
• Jakie cechy są wymagane od kierownika projektu?*
- wiedza o celach biznesu;
- wiedza techniczna - technologiczna - możliwość łączenia w
całość poszczególnych komponentów projektu
- wiedza w dziedzinie podejmowania decyzji - uczenie się na
własnych błędach - najbardziej powszechnie, najbardziej
kosztownie
* The Standish Group, „Extreme chaos”, http://www.standishgroup.com
Kierownik projektu
• Jakie cechy są wymagane od kierownika projektu?*
- język użytkownika biznesowego i język technologii tłumaczenie na język zespołu projektowego wymagań
użytkowników biznesowych
- wiedza o procesach - planowanie, kontrola, tworzenie
harmonogramów
- orientacja nie tylko w całości, ale i w szczegółach. Globalne
spojrzenie na projekt jest dobre dla sponsora, a nie dla
kierownika projektu.
- umiejętności zorganizowania pracy zespołu - tworzenie
atmosfery
- umiejętności komunikacji i koordynacji pracy zespołu
Kierownik projektu
• Zamiast być odpowiedzialny za własną pracę,
odpowiedzialny za pracę innych osób*.
• Nie próbować wykonać wszystkich spraw samodzielnie.
Przy małych projektach lub w krótkim okresie czasu ta strategia
może zdać egzamin, ale nie przy dłuższych lub złożonych
projektach.
Jeżeli stosujemy tę strategię w dłuższym okresie to jest pewną
drogą do porażki projektu.
• Wiedza w programowaniu jest potrzebną przy programowaniu.
Ta wiedza nie jest gwarancją, że osoba będzie dobrym
kierownikiem projektu**.
* Sanjay Murthi, Learning to Successfully Manage Teams and
Delegate Work, http://www.developer.com
** Arun Jayaraman, Twenty Points for Effective Software Project
Management, Wipro Technologies
Kierownik projektu
• Jak delegować zadania i zapewnić ich wykonanie przy
minimalnym zamieszaniu?
• Kierownik projektu nie jest rozliczany na podstawie jego własnej
pracy, a po tym jak jest realizowany projekt w całości.
• Do obowiązków kierownika projektu należą:
- wspomagać zespół przy pracy nad projektem;
- podnosić ducha członków ekipy.
• Określić jakie są zadania zespołu.
• Określić z kierownictwem firmy za co kierownik projektu jest
odpowiedzialny.
Sanjay Murthi, Learning to Successfully Manage Teams and
Kierownik projektu
• Określić w formie pisemnej jak będzie mierzony postęp projektu
i jego sukces.
• Zrobić listy głównych celów projektu.
• Określić, jakie są mocne i słabe strony zespołu.
• Budować i podtrzymywać świadomość zespołu.
• Każdy członek zespołu musi rozumieć jaka jest jego rola i
odpowiedzialność w projekcie
• Opracować scenariusze, jak postępować w sytuacji, kiedy
projekt ma opóźnienie.
• Wybrać osobę zastępcę kierownika projektu wśród członków
zespołu
Kierownik projektu
• Szkolić zespół, szczególnie zastępcę kierownika projektu.
Zastępca kierownika projektu powinien przyjmować więcej
odpowiedzialności za projekt. Jedna z możliwości realizacji tego
celu jest podział większych zespołów na podzespoły. Zastępca
kierownika projektu może być odpowiedzialny za pracę
podzespołu. Tak samo każdy członek ekipy powinien być
szkolony w odpowiedzialności za wykonaną przez niego pracę.
• Aktywnie podchodzić do poszukiwania i rozwiązywania
problemów.
• Prowadzić cotygodniowe, jeżeli nie ma możliwości codziennych
spotkań z ekipą, na których są rozważane etapy i problemy
związane z projektem.
• Planować z wyprzedzeniem
Przedstawiciel użytkownika
• Cechy przedstawiciela użytkowników, które przyczyniają się do
zakończenia projektów sukcesem.
- Wiedza na temat funkcji biznesowych, które mają być
realizowane przez budowaną aplikację;
- Widza technologiczna - zbyt duża wiedza technologiczna
może doprowadzić do opóźnienie projektu;
- Wiedza o procesach biznesowych;
- Komunikatywność
Sponsor projektu
• Jakie cechy powinien posiadać sponsor projektu?
- Globalna wizja projektu - jak projekt się wpisuje w rozwój
organizacji, jaka jest strategiczna rola projektu;
- Aktywne zaangażowanie sponsora w obronę i promowanie
projektu
- Zrozumienie metodologii zarządzania procesów w firmie
- Autorytet lub figurant - sukces czy porażka projektu
Specyfika projektów IT
• Czym się różni zarządzanie projektów informatycznych od
zarządzania projektami w innych branżach?
• Jakie są specyficzne cechy projektów w obszarze IT?
• Projekty w branży IT są przerywane, nie dlatego że są bardzo
złożone, ale raczej wskutek złego zarządzania.
• Wiedza w programowaniu jest potrzebna przy programowaniu.
Ta wiedza nie jest gwarancją, że osoba będzie dobrym
kierownikiem projektu.
• Jakie specyficzne wyzwania są związane z realizacją projektów
w dziedzinie IT?
Specyfika projektów IT*
• Praca na odległość (zdalna praca) – członkowie zespołu
projektowego mogą być rozproszeni geograficzne, co stwarza
problemy przy komunikacji. To zjawisko ma szczególną wagę,
kiedy mamy uczestników, między którymi są różnice kulturowe
oraz pracują w różnych strefach czasowych, między którymi jest
różnica czasu większa niż 8 godzin.
• Brak możliwości zobaczenia gotowego wyrobu. Przy projektach
budowlanych jest przedstawiana makieta przyszłego budynku,
tak samo jest przy statkach czy samochodach. Przy
oprogramowaniu jest trudno zaprezentować gotowy produkt
przed finalnym użytkownikiem przed jego zakończeniem.
* Arun Jayaraman, Twenty Points for Effective Software Project
Specyfika projektów IT*
• Kierowanie ludzi, którzy wiedzą więcej niż kierownik projektu.
Kierownik projektu bardzo często będzie w sytuacjach, kiedy
programiści, projektanci itd., będą posiadali większą wiedzę niż
on w dziedzinie technologii, programowania. Wtedy powstaje
problem jak podejmować decyzje w sytuacji, kiedy menedżer
projektu jest mniej kompetentnym niż wykonawcy projektu.
• Zmiany w technologii i możliwości zmiany pracy. Przy
projektach IT mamy do czynienia z najnowszą technologią.
Osoby, które tworzą rozwiązania mają możliwości wyboru
miejsca pracy. Powstaje problem jak zatrzymać utalentowanych
członków zespołu do zakończeniu projektu, jak ich motywować.
Jak zapewnić względną niezależność projektu od zmian w
zespole.
Warunki powodzenia/porażki
(problemy) projektu
Jeżeli posiadamy świadomość co do czynników, które są
najczęstszym powodem niepowodzeń projektów mamy szansę
ich uniknięcia, poprzez monitorowanie, przewidywanie
wystarczających zasobów oraz kontrolę realizacji projektu.
(problemy) projektu
Jakie czynniki decydują o sukcesie projektu?
Jak zdefiniować porażkę (ang. Failure)
• Porażka projektu <> przerywanie projektu
- skala oceny nieudanych projektów
- specyfikacja, wymagania,
- termin,
- budżet
• Dobre planowanie
• Brak metodologii / Stosowanie standardowej metodologii
• sformalizowane zarządzanie projektów na poziomie firmy;
• Współpraca wielu użytkowników poprzez efektywną
komunikację
(problemy) projektu
• Zagrożone projekty są przerywane w wcześniejszych fazach
zanim stanie się za późno i budżet jest przekroczony.
• Zmienność założeń funkcjonalnych
• Brak jednoznacznie określonych założeń użytkowników
• Złe zbieranie (sformułowanie) wymagań użytkowników
• Brak wsparcia przez naczelne kierownictwo (top management) brak sponsora projektu
• Zbyt wygórowany (ambicjonalny) projekt
• Brak dostępu do źródeł danych
• Budowa wielu interfejsów jest mało efektywna
• Konflikt między członkami ekipy realizującej projekt.
(problemy) projektu
• Zła ocena czasu niezbędnego do realizacji projektu
- zbyt długi okres realizacji - projekt dostarcza rozwiązanie,
które jest przestarzałe*
* Paul Chin, Cold Case File Why Projects Fail, may 6, 2003,
http://itmanagement.eartweb.com/cio/article.php/2201981
(problemy) projektu
„projekt, który „musi sie powieść” jest w myśl panującej w wielu
korporacjach zasady Dilberta - najprawdopodobniej z góry
skazany na porażkę.” *
* Borys Stokalski, Perspektywy zarządzania projektami wobec
nowych wyzwań IT, II Konferencja Project Management Perspektywy i Doświadczenia, http://www.spmp.org.pl
(problemy) projektu*
• Projekt ukierunkowany na klienta. Zespól rozumie problemy
klienta i wagę jaką dla firmy ma dostarczenie produktu, który
spełni w 100% oczekiwania i potrzeby użytkowników
biznesowych.
• Uznanie dla pracy członków zespołu.
• Rozsyłanie harmonogramu projektu do wszystkich ludzi z ekipy,
daje możliwość budowania świadomości i znaczenia ich roli
wpływającej na zakończenie projektu z powodzeniem.
• Strategia wykonania projektu. Posiadanie dobrego projektu i
harmonogramu nie jest gwarancją powodzenia projektu.
• Wybór technologii ma decydujący wpływ na wynik projektu.
• Uczestnicy projektu powinny dobrze rozumieć jaka
funkcjonalność biznesowa jest wymagana od produktu,
rozwiązania. Wiedza technologiczna, programistyczna nie
zawsze jest powiązana z wiedzą biznesową.
• Jaka metodologia będzie stosowana. Metodologia, która jest
dobra przy jednym projekcie przy następnym może doprowadzić
do porażki, jeżeli jest nieadekwatna.
• Spotkania w celu analizy przebiegu projektu (tygodniowe /
dwutygodniowe)
- ekipa jest permanentne informowana jak jest przestrzegany
harmonogram,
- jakie zmiany nastąpiły w projekcie / organizacji
- jakie zadania mają być zrealizowane do następnego spotkania
- w jakim stopniu są wykonane zadania z poprzedniego
spotkania
• Spotkania kierownika projektu z poszczególnymi członkami
ekipy pojedynczo lub w małej grupie
• Telekonferencje <-> wyjazdy
• Stymulowanie ludzi do poszukiwania błędów (ang. Bugs) w
oprogramowaniu w możliwie najwcześniejszych etapach.
Koszty korygowania błędów. Błędy przy projektowaniu bazy
danych....
• Szkolenie ekipy
Stworzenie atmosfery sprzyjającej wymianie wiedzy,
doświadczenia i poszukiwania wiedzy. Repozytorium wiedzy
dotyczącej projektu
• Stosowanie standardów i procedur, metodologii, narzędzi,
szablonów (ang. Templates)
• Rotacja ekipy
- różne funkcje, docenić wartość dobrej roboty;
- być w stanie zakończyć projekt w terminie, nawet jak odejdzie
jedna lub więcej osób - zastępstwo.
• Bilans praca / reszta
• Szacowanie (ocena) projektu
- w różnych cyklach realizacji projektu;
- różne metodologie
- różne osoby
• Szacowanie - estymacje zależą od typu projektu.
• Według profesora z MIT, Erik Brynjolfsson, „Jeżeli projekt w
obszarze IT się zakończy powodzeniem to każdy
zainwestowany w niego 1 USD przynosi 6 USD zysku”*.
• Ocena ryzyka
- podniesienie kwalifikacji kierowników projektu w tym obszarze
- wykorzystywanie sformalizowanych instrumentów i narzędzi do
oceny ryzyka;
- przeprowadzanie spotkań roboczych w celu oceny ryzyka;
* The Standish Group, Radical CENTS, http://www.standishgroup.com
(problemy) projektu
• Ocena ryzyka związanego z projektem- system VirtualADVISOR
- system ekspertowy zbudowany na bazie analizy 40 000
projektów, opracowany kwestionariusz zawierający 300 pytań
- szacowanie kosztów operacyjnych nowych rozwiązań dla
różnych systemów operacyjnych*
• jaki jest koszt niepowodzenia projektu?**
• Jak niepowdzenie wpłynie na wiarygodność działu IT,
kierownika projektu, zespołu, sponsora projektu?
http://www.sybase.com/sb_content/1027266/The_Standish_Group.pdf
** Craig Utley, Hurtownie danych - jak zwiększyc szanse powodzenia,
Systemy IT, Nr 9 2004, p. 61 - 65
•
W USA projekty w sektorze IT zostały sklasyfikowane przez Standish
Group w następujących kategoriach (udział %)
Typ projektu
Udział %
Rozpoczynany od zera z użyciem tradycyjnych
33%
języków programowania
Modyfikacja zakupionej aplikacji
15%
Rozpoczynany od zera z użyciem modelowania
13%
obiektowego
13%
Rozwinięty z użyciem częściowo opracowanych
komponentów i częściowo zakupionych
Znacznie zmiany w zakupionej aplikacji
12%
Zakupione komponenty połączone w aplikacji
9%
Zakupiona aplikacja wdrożona bez zmian
5%
•
•
•
*
Ocena projektu przez kierownika projektu - kryteria funkcji typu
projektu
- funkcjonalność rozwiązania / wymagania klienta (zakładana
funkcjonalność)
- linie kodu
- godziny programowania.
Estymacja projektu = Najlepsze szacunki * 2,5
<-> Powodzenie projektu
- bezpieczny dla kierownika projektu
- atrakcyjny dla sponsora projektu
Jakie mierniki stosować do oceny projektów?
- time to market (czas niezbędny do wypuszczenia na rynek)
- całkowity, krańcowy koszt wymaganej funkcjonalności
- ROI
The Standish Group, „Extreme chaos”, http://www.standishgroup.com
• Waga poszczególnych czynników dla powodzenia projektu
Czynnik
Wsparcie przez naczelne kierownictwo
Zaangażowanie użytkowników biznesowych
Doświadczony kierownik projektu
Klarowne cele biznesowe
Minimalny zakres projektu
Standardowa infrastruktura oprogramowania
Podstawowe wymagania
Formalna metodologia
Rzetelne szacunki
Inne
*
Udział %
18
16
14
12
10
8
6
6
5
5
• Wpływ roli kierownika projektu na jego powodzenie czy kierownik projektu zwiększa szansę sukcesu projektu?
• Koncentracja na regułach biznesu, a nie na technologii.
• Integracja nowego rozwiązania wśród istniejących aplikacji
*
(problemy) projektu
• Kto jest inicjatorem, motorem projektu - dział IT, sponsor,
użytkownicy biznesowi?
• Projekt w konflikcie z oddziałem, grupą pracowników ....
• Zagrożenie projektu dla działu i pracowników ....
• Przeciąganie rozpoczęcia projektu.
• „Wzbogacanie” wymagań w stosunku do projektu w czasie jego
realizacji, po zaakceptowaniu planów, terminów, zasobów.
(problemy) projektu
„Tajemnicą sukcesu jest przede wszystkim przygotowanie”
Henry Ford
Jakość
• „Prawie wszystko w poprawie jakości osiąga się dzięki
upraszczaniu: projektu, obróbki, ustawienia, procesów i
procedur”. Tom Peters*
* Tom Peters, ,,In search of excellence" (1982), Thomas Peters,
Robert Waterman Jr., Poszukiwanie doskonałości w biznesie,
MEDIUM, Warszawa 2000
ROI
•
•
•
•
•
•
•
•
Jak projekt wpłynie na wyzwania, które stoją przed nami?
Jak z perspektywy biznesu można zdefiniować misję firmy?
Jak projekt wpłynie na procesy biznesowe?
W jakim obszarze pomyślna realizacja projektu przyniesie
wzrost konkurencyjności firmy?
Co pracownicy zyskują na wdrożeniu projektu?
Co sponsor projektu zyska po jego realizacji?
Jaki problem biznesowy, użytkowników końcowych rozwiąże
nasz projekt?
Jak on rozwiąże problemy i usprawni procesy w firmie?
- automatyzacja procesu zamówień przez klientów (XML..)
- automatyzacja procesu zamówień do dostawców (XML..)
ROI
• Metodologie oceny ROI
- jakie dane są wymagane;
- kazusy dostarczane przez sprzedawców rozwiązań*
- bliskość gałęzi do naszej branży;
- rozmiar firmy w stosunku do naszej;
• Co brać pod uwagę i czego nie brać przy ocenie ROI
- koszty przestoju (cost of downtime)
• Jakie są widełki w których się może zmieniać ROI (najbardziej
pesymistyczne, najbardziej optymistyczne)
* Gantry Group, Eye on ROI: Buying with ROI - Your Vendor’s ROI and
You, DM Review April 28, 2005, www.dmreview.com
Technologia a ROI
• Kiedy koszty technologii się zwrócą?
• Jaki jest przewidywany cykl życia wybranej technologii, kiedy
będzie potrzeba zastąpienia jej przez inną?
• Jak technologia się wpisuje w strategię technologiczną firmy, jak
współdziała ze stosowaną w firmie technologią?
• Jak wybrana technologia przyczyni się do wzrostu wydajności
pracy?
• Jaki będzie koszt wzrostu wydajności pracy?
• Jaka jest cena opanowania danej technologii?
- licencje
- szkolenia
- konsulting ze strony dostawcy technologii, produktu, narzędzia
Technologia a ROI
• Jakie jest wsparcie wybranej technologii?
• W jakim stopniu technologia jest dojrzała?
• Jeżeli technologia jest OPEN SOURCE jakie są gwarancje jej
rozwoju, wsparcia przy napotkaniu problemów?
• Czy technologia nie wchodzi w konflikt z innymi technologiami?
• Celem - nie jest opanowanie technologii dla samej technologii
ponieważ programiści chcą się nauczyć kolejnego języka,
narzędzia, bazy danych...
• Cel to użycie technologii do osiągnięcia celów biznesowych
firmy!
• Czy ta technologia może być zastosowana w innych procesach,
działach...
ROI
• „Arkusze kalkulacyjne nie dostarczają całej historii”*
• „Wartość dla kogo”*
• „Największą pułapką przy podejmowania decyzji związanych z
technologią w biznesie jest pośpiech przyjmowania rozwiązania
bez pełnego zrozumienia leżących u podstaw potrzeb.”
• „Jest trudno bezpośrednio powiązać wyniki firmy z wynikami
danego projektu”**
* Jack Brennan, Show Me The Value, Your CEO is counting on you to
make sure technology investments really pay off,
http://www.cio.com/archive/050102/perspective.html
** Cathy Benko, Does Your Project Portfolio Reflect Your Strategic Intent?,
SAP NetWeaver magazine, Premiere Issue
Wybór projektów do realizacji
spośród dostępnych projektów
• Jak sprawić, aby był wybrany do realizacji nasz projekt wśród
portfeli projektów?
- Priorytet projektu dla firmy (fuzje i przyjęcia)
- Sponsor projektu
- Kierownik projektu
- ROI / Ryzyko projektu
- Niezbędne środki do realizacji projektu
- Przy jakich okolicznościach, warunkach, projekt będzie
wstrzymany
• Co realizacja projektu przyniesie dla firmy, dla sponsora, dla
użytkownika, dla przedstawiciela handlowego?*
* Dave Rochlin, Does Your Project Portfolio Reflect Your Strategic
Intent, SAP NetWeaver Magazine, Vol 1, No 1, p. 48 – 50
• Czy portfel waszych projektów odzwierciedla wasze
strategiczne cele?*
• „Portfelem projektów organizacji jest prawdziwa miara jej
zamierzeń”....„Zapewnia, że kluczowe projekty i inicjatywy są
zbieżne ze strategicznymi celami firm” ...
• Jeżeli chcemy wiedzieć, gdzie będziemy jutro, patrzmy w
inwestycje, które robimy dzisiaj, nie w plany”... „Jeżeli wasze
portfolio (portfel) nie jest zbieżne z tym co mówicie, do czego
chcecie dojść, dysponujecie dwiema możliwościami: Zmienić to
co mówicie, do czego chcecie dojść na ile wasze portfolio
(portfel) pozwala, lub zrobić zmiany w waszym portfolio”
* Cathy Benko, Does Your Project Portfolio Reflect Your Strategic Intent?,
•
Ocena portfolio (portfelu projektów) nie jest jednorazowym aktem.
Portfel musi być regularnie analizowany. Po akceptacji projektu,
najtrudniej jest go wstrzymać, zaniechać. Ale priorytety firmy, rynku, lub
motywacje mogą zmienić projekt na nieistotny. Również są
kontynuowane zmiany w technologii.” ...
• „Duże projekty związane z infrastrukturą muszą być rozpatrzone
ponowne, jeżeli jest zmiana w kierunkach strategii.”*...
• Według danych firmy badawczej i konsultingowej Gartner, organizacje,
które stosują rygorystyczne kryteria do przeniesienia projektów od fazy
wymagań do fazy rozwoju oszczędzają więcej niż 25% kosztów
związanych z opóźnieniem lub zaniechaniem projektu**.
* Cathy Benko, Does Your Project Portfolio Reflect Your Strategic Intent?,
** Bob Wourms, Pharmaceutical Organizations Discover new Way to Stay
Ahead of the Game: Project management Outsourcing, Pharmaceutical
Processing, September 2003, http://www.pharmpro.com
• „W czasie niepewności jest lepiej adaptować się do przyszłości,
niż przewidywać ją.” ...”Zrobić porfolio (portfel) projektów
wariantowych, niż zakładać na kilku dużych wielomilionowych
projektów - „poject chunking” - „kawałki projektów”.. „obniża
ryzyko, tworzy szybciej wartość dla firmy, dodaje więcej
punktów podejmowania decyzji, obniża dylemat wstrzymania
pojedynczych projektów...”
• „Project chunking (dziełenie projektu na kawałki) obniża
jednocześnie okres zwrotu i ryzyka, dodając elastyczność.”
• „tworzyć komponenty, które mogą być wielokrotnie użyte..”
* Cathy Benko, Does Your Project Portfolio Reflect Your Strategic
Intent?, SAP NetWeaver magazine, Premiere Issue
Rola narzędzi informatycznych
• Blisko 60% udanych projektów w USA używało narzędzi
wspomagających zarządzanie projektem.
• Platforma do komunikacji między użytkownikami, sponsorem,
kierownikiem projektu i zespołem projektowym
• Narzędzia do zarządzania projektami
• Rolą narzędzia jest wspomaganie pracy zespołu i procesu
zarządzania projektem.
Innowacje metodologiczne w
zarządzaniu projektami
•
•
•
•
Balanced Score Card (BSC) - Zrównoważona Karta Wyników
Workflow management (zarządzanie przepływu dokumentów)
TQM - Total Quality Management
Portfolio Management - stosowanie selekcji i nadawanie
priorytetów oceny projektach na bazie kosztów i zysków*
• Project Management Office (PMO) - Biuro projektów - centralny
oddział w organizacji, które odpowiada za planowanie,
zarządzanie i wykonywanie wszystkich projektów w ramach
firmy, komitet zarządzający projektami w organizacji
• Outsourcing project management - outsourcing zarządzanie
projektów
* Debbie Bigelow, Four Top Project Managemenet Priorities of
Fortuen 500 Companies, PM Solutions, www.pmsolutions.com
• Atmosfera w firmie - czy wszyscy popierają projekt, jak
pozyskać zwolenników wśród przeciwników projektu
• W Projektach IT*:
– Adaptive Managament http://www.adaptuvesd.com
– Extreme Programming http://www.extremeprogramming.org
• Kiedy stosować te innowacje - wówczas, kiedy one powodują,
że projekty są bardziej zyskowne i realizowane z większym
powodzeniem.
* Borys Stokalski, Perspektywy zarządzania projektami wobec
Outsourcing project management - outsourcing zarządzanie projektów
•
•
–
–
–
–
–
*
Presja - szybko dostarczyć nowe produkty na rynek, nie przekraczając budżetu, zgodnie z
wymaganiami jakości, wyprzedzając konkurencję
Outsourcing zarządzania projektami – zalety:
Długofalowe rozwiązanie, efektywne kosztowo, zwalnia zasoby w firmach. Zasoby te można
wykorzystać na szybsze dostarczenie produktu na rynek, badanie i rozwój nowych
produktów, podniesienie efektywności procesów biznesowych...
Firmy potrzebują od 5 do 7 lat, aby przygotować we własnym zakresie ekipę, posiadającą
certyfikaty Project Management Professional (PMP)
Natychmiast rośnie procent projektów zakończonych sukcesem.
Transfer wiedzy, konsultant zewnętrzny <–> zespół firmy. Pracownicy organizacji lepiej
zaczynają rozumieć zarządzanie projektami, stosowanie metryki do oceny projektów.
Zmniejsza rotację pracowników. Koszty związane z rotacją kierownika projektu dochodzą do
150% kosztów płacowych.
Bob Wourms, Pharmaceutical Organizations Discover new Way to Stay Ahead of the Game:
Project management Outsourcing, Pharmaceutical Processing, September 2003,
http://www.pharmpro.com
Innowacje technologiczne w
(technology innovations in PM)
•
•
•
•
Web enabled
Linux enabled
Part of ERP (E-Business Suite)
Jeden interfejs - Web lub / oraz
Ms Excel (Open Office) enabled (export do)
Kultura zarządzania projektami
• Zarządzanie projektami - podstawa do wykreowania w
organizacji kultury Zarządzania Zmianą!
• Projektowa organizacja firmy - odejście od tradycyjnej
hierarchicznej struktury organizacyjnej, w kierunku płaskiej
struktury ułatwiającej komunikację.
• „Ja to moje projekty... Projekty to ja....
Projekty powinny/mogą/MUSZĄ stać się T-O-B-Ą! ...
My żyjemy, by wykonywać... Projekty... Zamień każde „zadanie”
w projekt”. (Tom Peters)
Kultura zarządzania projektami
• System zarządzania wiedzą w firmie
• System współdzielenia się wiedzą w firmie
• System uczenia się organizacji
Zarządzania projektami IT w erze
gospodarki elektronicznej
• Szybkość zmian (Alvin Toffler Trzecia fala, PIW, Warszawa
1985)
• Porywa nas tsunami zmian technologicznych i technicznych –
tracimy orientację.... Dokonuje się rewolucja tradycyjnego
miejsca pacy. Nikt rozsądny nie spodziewa się już, że spędzi
całe życie w jednej firmie....Układy scalone skolonizują
wszystkie nasze rutynowe zajęcia*.
* Tom Peters, In search of excellence, Thomas Peters, Robert
Waterman Jr., Poszukiwanie doskonałości w biznesie,
MEDIUM, Warszawa 2000
• Zmiana punktu koncentracji z:
– terminu,
– budżetu,
– dostarczanie produktu, który w maksymalnym stopniu spełnia
wymagania (tradycyjne podejście)
– ukierunkowane na zmiany. „Kaprysy rynku i presja konkurencji nie
pozwalają na szczegółowe określenie zakresu prac w momencie
planowania nowej inicjatywy, zaś w trakcie jej realizacji
uniemożliwiają stabilizację wymagań, zmuszając do nieustannej
weryfikacji założeń dotyczących terminów realizacji i kryteriów
opłacalności”**.
** Borys Stokalski, Perspektywy zarządzania projektami wobec
Zmiany w
• procesach biznesowych
• wymaganiach użytkowników
• infrastrukturze i sprzęcie
• systemach operacyjnych
• aplikacjach
• technologii
Zarządzania projektów IT w erze
gospodarki elektronicznej*
„... Zamiast konkretnego terminu pojawia się pojęcie terminu
wejścia (time-to-market), który jest wypadkową wielu zmiennych
czynników. Zamiast konkretnego zestawu wymagań, możemy
mówić o subiektywnym modelu wartości (value proposition)
wyznaczającym satysfakcję „konsumenta rezultatów projektu”.
Również utrzymanie budżetu zostaje zastąpione przez bardziej
elastyczne pojęcie utrzymania opłacalności przedsięwzięcia.
Zamiast szczegółowego planu całego przedsięwzięcia pojawia
się pojęcie strategii realizacji projektu oraz bieżące planowanie
obejmujące stosunkowo krótki horyzont czasowy.”
*
Borys Stokalski, Perspektywy zarządzania projektami wobec
On-demand - na żądanie
Tradycyjny cykl rozwoju oprogramowania a nowy model rozwoju i dostarczania
usług
On-demand
- Usługi na żądanie - centrum danych - serwer, system operacyjny, baza
danych, serwer aplikacji, CRM, ERP....
- Nowy typ relacji między użytkownikiem a dostawcą usługi (aplikacji) (ang.
Service Provider) zamiast kupować licencję kupuje się czas użytkowania
aplikacji
- Dostępna natychmiast
- Dostarcza wartość, przy niższych kosztach (30 do 60% w stosunku do
tradycyjnego modelu), lepszej jakości serwisu
*
Neil Singhal and Bill McBeath, How On-Demand is Radically Changing the
Enterprise Software Industry,
http://www.dmreview.com/editorial/newsletter_article.cfm?articleId=1027175
On-demand - na żądanie
Neil Singhal and Bill McBeath, How On-Demand is Radically Changing the Enterprise Software Industry
http://www.dmreview.com/editorial/newsletter_article.cfm?articleId=1027175

(problemy) projektu

Transkrypt

Podobne dokumenty

Komputerowe wspomaganie zarządzania projektami