wprowadzenie
projekty są często środkiem do operacjonalizacji planów strategicznych organizacji. Przewiduje się projekty mające na celu rozwój produktów i usług oraz zwiększenie efektywności operacyjnej. Biznes staje się coraz bardziej projektowany, a globalne wydatki na projekty są rzędu wielu miliardów dolarów rocznie (Williams, 2005). Powody są oczywiste. Projekty dają możliwość stosowania praktyk zarządzania projektami, które promują efektywne i efektywne wykorzystanie zasobów. Jednak pomimo postępu w dziedzinie zarządzania projektami i zawodu, wspólne doświadczenie sugeruje, że wiele projektów zawodzi (Williams, 2005), co podkreśla znaczenie i potrzebę poprawy procesów zarządzania projektami i wydajności.
ogólnie rzecz biorąc, organizacje dążą do wdrożenia najlepszych praktyk tradycyjnego zarządzania projektami-opartych na standardach PMI-aby osiągnąć cele projektu i spełnić oczekiwania klientów. Jednak nie wszystkie zalecane procesy i praktyki zarządzania projektami (PMBOK ® Guide) mogą być istotne dla każdego projektu. Często selektywne podejście ma sens w przyjmowaniu procesów i praktyk zarządzania projektami do konkretnych potrzeb projektu w oparciu o jego wielkość, rodzaj, złożoność i branżę, w której projekt jest podejmowany. Taka potrzeba odmiennego podejścia do zarządzania projektami IT jest dobrze udokumentowana w literaturze dotyczącej zarządzania projektami.
projekty programistyczne często borykają się ze sprzecznymi wyzwaniami związanymi z tworzeniem oprogramowania w przyspieszonym tempie, jednocześnie rozwijając je z solidnością, aby były niezawodne (Boehm, 2002). Projekty informatyczne, mające na celu dotrzymanie kroku szybko zmieniającym się technologiom, często ulegają zmianom w zakresie na etapie planowania i wdrażania. W związku z tym projekty IT mają wyzwania, które różnią się od tradycyjnych projektów. W projektach IT opracowuje się i praktykuje szereg dostosowań i modyfikacji do tradycyjnych praktyk zarządzania projektami, wprowadzając w ten sposób nowe metodologie zarządzania projektami, takie jak zwinne zarządzanie projektami.
zwinna metodologia zarządzania projektami—z większą możliwością dostosowania do często zmieniającego się zakresu—wykorzystuje iteracyjne lub stopniowe planowanie i ciągłą integrację. Kluczową zasadą jest utrzymanie miękkiego zakresu projektu. Metodologia sprzyja współpracy i skutkuje zwiększeniem satysfakcji klienta. Agile nie jest jednak kompletnym rozwiązaniem do tworzenia oprogramowania w szybkim tempie, przy jednoczesnym spełnieniu wymagań klienta w zakresie solidności i niezawodności. W tym kontekście Boehm (2002) zalecił połączenie tradycyjnego zarządzania projektami i zwinnej metodologii tworzenia oprogramowania, która jest wykonalna i korzystna. Uzupełniającym podejściem byłoby opracowanie podejścia opartego na ryzyku, które jest dostosowane do zachowania korzyści zarówno z metod zwinnych, jak i opartych na planie, a jednocześnie złagodzenia wielu ich słabości (Boehm & Turner, 2003).
niniejsza praca badawcza ma na celu zbadanie powyższych propozycji (Boehm, 2002; Boehm & Turner, 2003) połączonego podejścia do zarządzania projektami konsultingowymi IT, które różnią się od projektów IT. Projekty IT consulting są tworzone w celu zarządzania projektami IT i zapewnienia ich wsparcia. Są one często inicjowane w sektorze rządowym. Projekty konsultingowe IT nie są projektami programistycznymi; raczej zapewniają wsparcie projektowe dla projektów IT.
w tym badaniu dążymy do zrozumienia, jak zwinne praktyki zarządzania projektami są istotne dla projektów doradztwa IT. Celem badania jest określenie korzyści płynących z zastosowania zwinnego zarządzania projektami, jego przydatności i jakie aspekty tradycyjnego zarządzania projektami można połączyć ze zwinnym zarządzaniem projektami w projektach konsultingowych IT w celu poprawy wydajności projektu. W następnej części, korzystając z obszernego przeglądu metodyki agile project management, zidentyfikowaliśmy istotne cechy metody agile i ich unikalne podejście do zarządzania projektami w porównaniu do tradycyjnego zarządzania projektami. Przegląd literatury pomógł w zrozumieniu kluczowych pojęć i korzyści płynących z używania zwinnego oprogramowania. Ponadto, w oparciu o wyniki przeglądu literatury, opracowaliśmy i przedstawiliśmy metodę badawczą wykorzystującą ustrukturyzowany kwestionariusz w celu opracowania zrozumienia projektów konsultingowych IT. Analiza danych i dyskusja, przedstawione następnie, dostarczają ważnych spostrzeżeń i wniosków z badania. Artykuł kończymy wynikami badań i rekomendacjami dla projektów doradztwa IT.
Przegląd literatury
tradycyjne praktyki zarządzania projektami, które są napędzane przez kompleksowe planowanie, mogą być stosowane, gdy specyfikacje projektu są jasno określone. Z drugiej strony, gdy specyfikacje podlegają częstym zmianom w trakcie trwania projektu, tradycyjne podejście do zarządzania projektami może nie działać skutecznie. Projekty programistyczne często są tworzone z minimalnymi specyfikacjami, co powoduje częste zmiany tych specyfikacji podczas realizacji projektu. Ponadto czas rozwoju projektu oprogramowania jest krótki. Metody zwinne, w porównaniu z tradycyjnymi technikami zarządzania projektami, są odpowiednie dla projektów programistycznych ze względu na krótki czas ich rozwoju (Hanakawa & Okura, 2004).
ogólnie rzecz biorąc, różne metody tworzenia oprogramowania, takie jak zwinne zarządzanie projektami, obiecują większe zadowolenie klientów, niższe wskaźniki defektów, szybsze czasy rozwoju i służą jako rozwiązanie szybko zmieniających się wymagań projektowych (Boehm & Turner, 2003). W przeciwieństwie do zwinnego zarządzania projektami, model stage-gate wykorzystuje proces pracy Od pomysłu koncepcyjnego do produktu, który jest ostatecznie dostarczany. Model ten rozwija fazy cyklu życia zarządzania projektami w oparciu o różne etapy rozwoju produktu do zarządzania projektami. Ważnym rozróżnieniem między modelem stage-gate a zwinnym zarządzaniem projektami jest to, że poprzednie próby zminimalizowania zmian wymagań, aby produkt został ukończony na czas (Karistrom & Runeson, 2005). Inną metodą tworzenia oprogramowania jest SCRUM, czyli zbiór zasad zarządzania projektami wykorzystujących małe, wielofunkcyjne i samodzielne zespoły (Schatz & Abdelshafi, 2005). SCRUM wymaga, aby każdy członek zespołu i właściciel produktu pracowali razem na początku każdego elementu rozwoju, a metodologia działa jak owijka wokół istniejących procesów rozwoju. W związku z tym Schatz i Abdelshafi twierdzili, że SCRUM nie będzie miał podstawowego planu pomiaru sukcesu projektu. Jednak zwinne zarządzanie projektami jest brane pod uwagę w tym badaniu ze względu na większą elastyczność i możliwość dostosowania do projektów programistycznych.
oprócz korzyści omówionych powyżej, metodologia agile ma zastosowanie do burzliwych i stale zmieniających się środowisk (Highsmith & Cockburn, 2001). Ponadto metoda agile kładzie nacisk na zdolność adaptacji do rynku, technologii i procesu (Mellor, 2005). Metodologia zwinna to podejście, które najpierw skupi się na ważnych funkcjach, a w rezultacie będzie szukać wczesnych informacji zwrotnych na temat funkcji (Karistrom & Runeson, 2005). Po zidentyfikowaniu ważnych funkcji kierownik projektu zapewni, że nie będzie opóźnień. Karistrom i Runeson wskazali, że proces zwinny pozwoli uniknąć zapchania zasobów, stałych planów i wspierania planów długoterminowych.
jednak zwinna metodologia nie jest odpowiednia dla wszystkich projektów programistycznych. Powołując się na Scotta Amblera, twórcę metody agile, Boehm (2002) zalecił tradycyjną, opartą na planie metodologię zarządzania projektami dla oprogramowania asekuracyjnego, takiego jak systemy o znaczeniu krytycznym dla życia.
metoda agile, ze względu na wymagające środowisko projektowe charakteryzujące się chaosem i niepewnością, potrzebuje zespołów projektowych składających się z utalentowanych ludzi, aby sprostać wymagającym potrzebom i wymaganiom. Powołując się na badania przeprowadzone przez Constantine ’ a (2001), Boehm (2002) zasugerował, że metody zwinne wymagają wysoce zdolnych ludzi. Ponadto agile nie jest odpowiedni dla większych zespołów (Highsmith & Cockburn, 2001), ponieważ wymaga ściśle skoordynowanej pracy zespołowej, aby odnieść sukces, a zespoły z więcej niż 15 lub 20 deweloperami zwiększają trudności w zarządzaniu projektem (Constantine, 2001).
oczywiste jest, że metoda agile wykorzystuje spójne zespoły (Karistrom & Runeson, 2005). Karistrom i Runeson zidentyfikowali dodatkowe funkcje zwinne, takie jak małe i łatwe do zarządzania zadania, ciągła integracja i automatyczne testowanie. W związku z tym zwinne zespoły projektowe charakteryzują się dobrą komunikacją wewnętrzną,wyższą jakością i poczuciem kontroli (Karistrom & Runeson). Przewidują jednak potencjalną izolację dla zwinnego zespołu.
w zakresie komunikacji, zarządzania postępem w oparciu o dokumenty i kontroli jakości, powszechna praktyka w tradycyjnym zarządzaniu projektami nie pasuje do zwinnej metody tworzenia oprogramowania (Hanakawa & Okura, 2004). Interakcja twarzą w twarz w celu ciągłego dostosowywania celów rozwoju jest zwykle preferowana w metodykach zwinnych (Melnik & Mauer, 2004). Podkreślając różnicę między tradycyjnymi i zwinnymi metodami, Melnik i Mauer zasugerowali, że krótki transfer wiedzy oraz bezpośrednia komunikacja i współpraca są preferowane w tworzeniu oprogramowania, w przeciwieństwie do tradycyjnych praktyk zarządzania projektami, w których stosuje się długie łańcuchy transferu wiedzy, które często są podatne na zniekształcenia i utratę informacji.
jedną z istotnych różnic między planowymi tradycyjnymi praktykami zarządzania projektami a metodami zwinnymi jest to, że metody zwinne wychwytują zwinność na podstawie milczącej wiedzy zespołu projektowego, a nie wyraźnej wiedzy, często używanej w formie dokumentów i planów w tradycyjnym zarządzaniu projektami (Boehm, 2002).
kolejną różnicą jest ilość i rodzaj dokumentacji tworzonej dla projektów. Tradycyjne zarządzanie projektami oparte na planie kładzie nacisk na szczegółowe planowanie, monitorowanie i kontrolowanie dokumentów. Uzasadnienie projektowe, dokumenty, które wyrażają powody i uzasadnienia, są tworzone przy użyciu wysoce zautomatyzowanej procedury, a te uzasadnienie projektowe służą jako zwinna dokumentacja (Sauer, 2003).
Coram i Bohner (2005) zidentyfikowali wspólne cechy metody zwinnej: współpracę, małe zespoły, krótkie harmonogramy wydań, Boks czasowy i ciągłe testowanie. Kierownik projektu jest odpowiedzialny za zapewnienie środowiska o wysokiej współpracy. W tym celu metoda agile zachęca małe zespoły i kilka pod-zespołów na projekt do wspierania współpracy. W konsekwencji metoda agile może wymagać mniej procesu i planowania w celu koordynacji działań zespołu. Metoda agile wykorzystuje również krótkie harmonogramy wydań, które mogą się różnić od dwóch tygodni do sześciu miesięcy. Time boxing to koncepcja, która narzuca stały czas na wydanie rezultatów projektu, co pomaga zmniejszyć złocenie i pełzanie zakresu. Ciągłe testowanie zapewnia jakość produktu i integrację. Co więcej, Coram i Bohner zasugerowali, że kierownicy projektów muszą śledzić postępy i podejmować decyzje biznesowe, kładąc nacisk na reagowanie na zmiany, a nie na przestrzeganie konkretnego planu.
czas boksu prowadzi do nieprzewidywalnego planowania według najlepszych przypuszczeń, a ustalone terminy mogą przynieść nieoczekiwane niespodzianki w fazie rozwoju (Patton, 2003). Innym rezultatem tego iteracyjnego procesu planowania projektu jest to, że metoda agile nie może monitorować postępu w oparciu o procent kompletny (Patton, 2003).
zaangażowanie małych pod-zespołów w planowanie spowoduje zmotywowanych inżynierów rozwoju oprogramowania; problemy techniczne są poruszane na wczesnym etapie projektu i nie będzie mały opór w realizacji (Karistrom & Runeson, 2005). Ponadto zdefiniowanie zakresu projektu za pomocą zwinnego podejścia skutkowałoby redukcją kosztów (Mcgovern, 2002). Metoda agile wykorzystuje planowanie oparte na wymaganiach, a także pozwoli nam kontrolować zakres (McGovern).
wykorzystując wszystkie odniesienia i dyskusje do tej pory i inne (Little Greene, Phillips, Pilger & Poldervaart, 2004; Little, 2005; Abrahamsson, Warsta, Siponen, & Ronkainen, 2003; Ilieva, Ivanov, & Stefanova, 2004; Lindvall, 2004), Tabela 1 zawiera podsumowanie porównania tradycyjnych i zwinnych praktyk zarządzania projektami.
Tabela 1: Porównanie zwinnego i tradycyjnego zarządzania projektami
| faza projektu | tradycyjny | zwinny |
| wszczęcie postępowania |
|
|
| planowanie |
|
|
| Execution |
|
|
| monitorowanie i kontrola |
|
|
| Closeout |
|
|
Metodologia zwinnego zarządzania projektami jest powszechnie stosowana w projektach programistycznych. Ma większą zdolność adaptacji do często zmieniającego się zakresu. W konsekwencji, zwinne zarządzanie projektami wykorzystuje iteracyjne lub stopniowe planowanie i ciągłą integrację przez cały okres trwania projektu. Kluczową zasadą w zwinnym zarządzaniu projektami jest utrzymanie miękkiego zakresu projektu. Zwinna metoda zarządzania projektami różni się od tradycyjnej metody zarządzania projektami, przypisując znaczenie czynnikom tradycyjnie uznawanym za nieistotne. Agile przypisuje stosunkowo większe znaczenie:
- osoby i interakcje ponad procesami i narzędziami
- realizacja projektu ponad kompleksową dokumentacją
- Współpraca z klientami ponad negocjacjami umów
- reakcja na zmianę planu projektu
metoda agile kładzie nacisk na elastyczność w zaspokajaniu potrzeb projektowych. Ponadto opiera się na opiniach klientów, aby zainicjować zmiany w planie projektu. Metodologia wykorzystuje podejście do identyfikacji odpowiednich użytkowników końcowych i ich celów do formułowania rezultatów projektu i zaspokajania potrzeb wykonawczych procesów biznesowych. Zalety stosowania metody agile to zwiększona satysfakcja klienta, niższe wskaźniki wad i szybszy czas rozwoju. Ponadto metoda agile jest odpowiedzią na szybko zmieniające się wymagania, ponieważ wykorzystuje wczesne informacje zwrotne na temat cech technologicznych rezultatów projektu. Metoda agile zapewnia, że wymagania nie są zapchane. Kluczowe cechy metody agile to efektywna komunikacja w zespole projektowym i poza nim oraz wykazana elastyczność w dodawaniu kolejnych wymagań.
korzyści te pomogłyby organizacjom zapewnić lepszą obsługę klienta. Ponadto są one istotne w obecnej gospodarce, w której globalizacja i filozofia wolnego marketingu wpływają na postrzeganie klientów w podnoszeniu oczekiwań dotyczących dostarczania produktów i / lub usług szybciej, taniej i lepiej.
jednak metoda zwinna nie jest pozbawiona wad, co widać w tabeli 1. Często zmieniający się zakres prowadzi do trudności w monitorowaniu postępów projektu. Ponadto nie jest łatwo uchwycić milczącą wiedzę w formie wyciągniętych wniosków. Kontrola zmian zakresu, dokumentacja, kompleksowy plan, zarządzanie jakością i zarządzanie ryzykiem to ważne zalety tradycyjnego zarządzania projektami, których możemy być pozbawieni stosując metodę agile.
Metodologia badań
do zbierania danych wykorzystaliśmy zarówno wywiady osobiste, jak i kwestionariusze. Opracowaliśmy ustrukturyzowany kwestionariusz składający się z dwóch sekcji. Pierwsza sekcja została zaprojektowana, aby uchwycić szczegóły dotyczące projektu i jego cech. Ta sekcja składa się z 13 pytań, które są związane z demografią projektów i praktykami zarządzania projektami. Zostały one przedstawione uczestnikom badania z opcją udzielenia odpowiedzi otwartych, gdy jest to konieczne.
druga sekcja skupiała się na oświadczeniach dotyczących praktyki zarządzania projektami, a uczestnicy zostali poproszeni o udzielenie odpowiedzi na te oświadczenia w pięciopunktowej skali, przy czym 1 oznacza „zdecydowanie się nie zgadzam”, a 5 oznacza „zdecydowanie się Zgadzam.”Poniższe stwierdzenia zostały użyte w odniesieniu do ważnych wspólnych założeń praktyk zarządzania projektami, a także służą kontrastowi tradycyjnych i zwinnych praktyk zarządzania projektami.
- kryteria mierzenia sukcesu projektu opierają się na założeniach i założeniach projektu.
- projekt opiera się na wymaganiach.
- projekt można dostosować do zmian.
- Twoim zdaniem, wysiłki zarządzania projektami osiągnęły oczekiwane rezultaty
- bezpośrednie interakcje i krótsze łańcuchy komunikacyjne mają większe znaczenie niż procesy i narzędzia.
- zespół koncentruje się na realizacji projektu nad kompleksową dokumentacją.
- Współpraca z klientami nad negocjacjami umów działa lepiej dla Twojego zespołu.
- projekt ma dobrze zdefiniowany zakres projektu.
- praktyki zarządzania projektami są zgodne z cyklem życia projektu PMBOK® Guide.
- projekt ma wymagania dokumentacyjne, takie jak przestrzeganie norm, takich jak ISO9000, OMB 300.
- procedury testów akceptacji użytkowników (UAT) są przestrzegane w całym projekcie.
- kierownik projektu jest uprawniony do podejmowania decyzji związanych z projektem bez interwencji klienta.
odpowiedzi na te stwierdzenia są analizowane w połączeniu z odpowiednimi pytaniami z pierwszego zestawu 13 pytań. Odpowiedzi w obu sekcjach dostarczyły szczegółowych informacji na temat projektu w celu przeprowadzenia merytorycznej analizy.
wyniki badań
kwestionariusz został skonstruowany tak, aby uchwycić dane dotyczące 20 projektów konsultingowych IT, które były w toku w czasie badań. Spośród projektów 65% to projekty typu time and material contract, a pozostałe to SOLID fixed price (FFP). Wśród projektów czasowych i materialnych 55% mA Czas trwania projektu ponad dwa lata.
większość zespołów projektowych jest mała: tylko 15% mA 10 lub więcej członków. W odniesieniu do komunikacji między członkami zespołu projektowego, 60% respondentów wykorzystało tylko formalną komunikację dla potrzeb projektu; 30% stosowało zarówno formalną, jak i nieformalną komunikację, a pozostałe 10% opierało się wyłącznie na nieformalnych metodach.
jeden na dwóch respondentów wskazał, że ich projekty wykorzystały plan projektu. W powiązanym pytaniu, z tych projektów, które nie miały planu projektu, 80% również nie korzystało z planowania iteracyjnego.
zmiana zakresu jest ważnym aspektem tego badania. Spośród projektów 70% przynajmniej raz doświadczyło zmiany zakresu. Spośród tych, którzy doświadczyli zmiany zakresu projektu, 60% doświadczyło jej więcej niż dwa razy. Podczas gdy klient decyduje o zmianie zakresu, konsultant—za zgodą klienta-może włączyć plan kontroli jakości do planu zarządzania projektem. Na pytanie, czy mają plan kontroli jakości dla swojego projektu, 65% respondentów stwierdziło, że nie stosuje planu kontroli jakości.
wyniki Dyskusja i analiza
wyniki badań zostały przeanalizowane poprzez dokładne zbadanie wszelkich powiązań między pytaniem a wszystkimi innymi pytaniami, po pierwsze w celu potwierdzenia wyników, a po drugie w celu opracowania skutecznych strategii zarządzania. Ponadto wyniki te zostały przeanalizowane w celu zbadania, które zwinne i tradycyjne praktyki zarządzania projektami mogą być stosowane w połączeniu w celu opracowania solidnego podejścia do zarządzania projektami konsultingowymi IT.
kryteria sukcesu projektu w oparciu o jego cele i cele
projekt uznaje się za udany, gdy spełnia swoje cele i cele. Tylko 60% respondentów zgodziło się z oświadczeniem: „kryteria pomiaru sukcesu projektu opierają się na celach i celach projektu.”Około 30% respondentów nie zgodziło się. Dalsza analiza wykazała, że powodem nieporozumień było to, że projekty te doświadczały stale zmieniających się warunków i wymagań lub klient nie był jasny co do projektu. Ostatecznie projekty te przechodziły częste zmiany zakresu. W jednym konkretnym przypadku cele projektu uległy zmianie.
warto zauważyć, że nie ma związku między faktem, że kryteria sukcesu projektu wynikają z jego celów i zmiany zakresu, rodzaju projektu, a istnieniem planu projektu. Innymi słowy, wyprowadzenie kryteriów projektu z planu strategicznego organizacji nie ma wpływu na zmianę zakresu i czy projekt ma plan.
wymagania projektu
zazwyczaj szczegółowy plan projektu jest opracowywany po wyraźnym zidentyfikowaniu wymagań sponsora projektu. Opracowanie planu projektu i jego realizacja, co do zasady, powinny być podyktowane tymi wymogami. Dlatego można by oczekiwać, że kierownicy projektów zgodzą się ze stwierdzeniem: „projekt napędzany jest wymaganiami.”Wyniki badań pokazują, że tylko 60% respondentów stwierdziło, że ich projekty są napędzane przez wymagania. Około 20% respondentów, którzy nie zgadzali się z oświadczeniem, wskazało, że ich projekty są realizowane bez użycia planu projektu.
około 20% respondentów, którzy byli neutralni w odpowiedzi na to stwierdzenie, to kierownicy projektów, którzy nie doświadczyli żadnej zmiany zakresu w swoich projektach. Wszyscy pozostali respondenci, którzy zgodzili się lub nie zgodzili się z oświadczeniem, co najmniej raz doświadczyli zmiany zakresu w swoich bieżących projektach.
ogólnie rzecz biorąc, jeśli projekt nie jest realizowany zgodnie z jego planem, możemy założyć, że wymagania nie zostały zidentyfikowane lub oczekuje się, że wymagania projektu zmienią się podczas jego realizacji. W tym opracowaniu nie możemy jednak ustanowić takiego związku między „realizacją projektu bez wykorzystania planu projektu” a „projektem nie kierują wymagania”, ponieważ tylko 50% tych, którzy zgodzili się z drugim stwierdzeniem, również zarządzało projektami bez użycia planu.
adaptacja do zmian
osiemnaście z 20 projektów z powodzeniem zareagowało na zmiany w projekcie. Zdolność adaptacji do zmian jest uważana za podstawową cechę projektu jako kandydata do stosowania zwinnej metodologii zarządzania projektami. Projekty konsultingowe IT reprezentowane w tym badaniu wykazały, że mają zdolność adaptacji do radzenia sobie ze zmianą zakresu.
wysiłki zarządzania projektami osiągnęły oczekiwane rezultaty
wyniki sugerują, że klient jest zadowolony z rezultatów w większości projektów (70%). Odpowiedzi te nie były jednak związane z odpowiedziami na inne ważne pytania ankietowe dotyczące postępu projektu i produktu opracowanego z perspektywy kierownika projektu. Powody są oczywiste. Projekty wciąż przeżywały przekroczenia czasu i kosztów. Podczas gdy efekt końcowy w dostarczaniu oprogramowania jest zadowalający, procesy zarządzania projektami nie zostały pomyślnie wykonane. Wnioskować może, że przyjęcie tradycyjnych praktyk zarządzania projektami, takich jak opracowywanie kamieni milowych, monitorowanie i kontrolowanie, pomogłoby skutecznie zarządzać projektem.
znaczenie komunikacji twarzą w twarz a procesy
komunikacja jest kluczem do zrozumienia ról, obowiązków, polityk i procedur związanych z projektami i zachęcania do współpracy. Ostatecznie komunikacja prowadzi do spójnego zespołu projektowego i zachęca członków zespołu do współpracy i udziału w podejmowaniu decyzji. Siedmiu na dziesięciu kierowników projektu, którzy wzięli udział w badaniu, zgodziło się, że interakcjom twarzą w twarz i krótszym łańcuchom komunikacyjnym nadano większe znaczenie niż procesom i narzędziom.
wyniki pokazują silny związek między znaczeniem komunikacji twarzą w twarz a środkami komunikacji między członkami zespołu projektowego. Ci, którzy nie zgadzali się, że komunikacja twarzą w twarz jest ważniejsza niż procesy projektowe, korzystali z nieformalnej komunikacji między członkami zespołu projektowego, podczas gdy ci, którzy uważali komunikację twarzą w twarz za ważniejszą, korzystali zarówno z komunikacji formalnej, jak i nieformalnej.
koncentracja na realizacji projektu nad dokumentacją
dokumentacja projektowa jest często pomijana i w związku z tym organizacje są pozbawione ważnych wniosków wyciągniętych z planowania i realizacji projektu. Biorąc pod uwagę, że wszystkie projekty reprezentowane w tym badaniu są projektami rządu federalnego, warto zauważyć, że 70% odpowiedzi kierowników projektów zgodziło się, że ich zespoły skupiają się na realizacji projektu w porównaniu z tworzeniem kompleksowej dokumentacji. W kilku przypadkach, w których kierownicy projektu uznali, że dokumentacja jest ważniejsza niż realizacja projektu, dalsze dochodzenie wykazało, że klient był niezdecydowany co do projektu we wszystkich tych przypadkach.
Współpraca z Klientem w negocjacjach umów
negocjacje umów są istotną cechą projektów zewnętrznych. Podczas negocjacji obie strony skupiłyby się na ochronie własnych interesów. Negocjowanie umowy może odbywać się na różnych etapach projektu. Pożądane jest rozwiązywanie tych problemów poprzez współpracę, w szczególności podczas realizacji projektu; w przeciwnym razie doprowadzi to do problemów, takich jak przedłużenie umowy. Biorąc pod uwagę, że wszystkie projekty reprezentowane w tym badaniu są umowami, warto zauważyć, że ponad połowa odpowiadających kierowników projektów (60%) uważa współpracę z klientami za ważniejszą niż negocjacje umów. Zasugerowali, że współpraca działa lepiej dla zespołów projektowych.
tam, gdzie było nieporozumienie, sugerujące, że współpraca nie jest tak ważna jak negocjacje, z tymi projektami wiązały się dwa interesujące fakty. Wszystkie inne projekty wykorzystywały bezpośredni kontakt jako środek komunikacji z interesariuszami projektu, ale te projekty wykorzystywały komunikację łańcuchową, a klient był niezdecydowany co do projektu. Oba te czynniki oznaczają trudne warunki współpracy.
projekt i dobrze zdefiniowany zakres projektu
projekty zwykle wiążą się z niepewnością i nieznanymi czynnikami, które prowadzą do niejednoznaczności. W związku z tym nie można opracować szczegółowego zakresu i specyfikacji na wczesnym etapie projektu. Zakres projektu stale się zmienia w trakcie trwania projektu. Czasami pierwotne cele projektu również mogą ulec zmianie. Spośród ankietowanych projektów 40% ma dobrze określony zakres, podczas gdy kolejne 45% nie.
jednak 80% projektów przynajmniej raz doświadczyło zmiany zakresu, co potwierdza przedstawione wcześniej argumenty.
praktyki zarządzania projektami i cykl życia projektu PMBOK® Guide
PMBOK® Guide opracował skomplikowany proces zarządzania cyklem życia projektu, który jest wyczerpujący i wyczerpujący. Nie jest jednak konieczne, aby każdy proces cyklu życia PMBOK® Guide project management był stosowany do każdego projektu. Jego przyjęcie powinno być dostosowane do konkretnych projektów. Zgodnie z oczekiwaniami, 45% kierowników projektów zastosowało się do praktyk zarządzania projektami w cyklu życia projektu PMBOK® Guide, a kolejne 45% nie.
iteracyjne lub etapowe Planowanie projektu
definicja zakresu i plan zarządzania projektem są częścią planu projektu. Jak wspomniano wcześniej, szczegółowe opracowanie zakresu i specyfikacji nie może być opracowane na wczesnym etapie projektu. W związku z tym Zakres projektu stale się zmienia, co podkreśla znaczenie iteracyjnego lub etapowego planowania projektu, ważną cechą metody agile. Na pytanie, czy iteracyjne lub etapowe planowanie projektu jest przestrzegane dla projektu, czy nie, połowa respondentów stwierdziła, że tak, a tylko 15% nie przestrzegało iteracyjnego planowania projektu. Warto zauważyć, że wszyscy ci, którzy nie zgadzali się z praktyką iteracyjnego planowania projektu, nie mieli planu projektu w pierwszej kolejności.
dokumentacja i przestrzeganie norm
dokumentacja projektowa służy jako punkt odniesienia do analizy danych historycznych i pomaga organizacjom w ciągłym doskonaleniu procesów zarządzania projektami i opracowywaniu standardów. Dokumentacja pomoże również zidentyfikować zdobyte doświadczenia i zmodyfikować systemy zarządzania projektami, które doprowadzą do dojrzałości zarządzania projektami. OMB300 i ISO9000 służą jako przewodniki w projektowaniu systemów dokumentacji projektowej. W szczególności wiele projektów rządowych wymaga przestrzegania wytycznych OMB300. 80% respondentów stwierdziło, że zarządzane przez nich projekty informatyczne mają wymagania dokumentacyjne, takie jak przestrzeganie norm ISO9000 i OMB300. Wymogi te dla projektów doradztwa informatycznego mają jednak zastosowanie w ograniczonym zakresie.
procedury testowe akceptacji użytkowników
zadowolenie klienta jest podstawową miarą jakości i sukcesu elementów dostarczanych do projektu. Dlatego też procedury testowe akceptacji użytkowników są uważane za ważne. Nawet w przypadku mniej namacalnych rezultatów projektu, takich jak usługa, podstawową miarą sukcesu projektu jest zadowolenie klienta. Jest to jednak subiektywne. Tylko 30% respondentów stwierdziło, że w całym projekcie stosowało się do procedur testowych akceptacji użytkowników, a 45% respondentów nie.
upoważnienie do podejmowania decyzji związanych z projektem
ogólnie rzecz biorąc, kierownicy projektów powinni mieć wolną rękę w podejmowaniu decyzji związanych z projektem bez interwencji klienta, gdy decyzje te nie mają większego wpływu na zakres projektu lub rezultaty projektu. Tylko 15% zgodziło się, że kierownik projektu jest uprawniony do podejmowania decyzji związanych z projektem bez interwencji klienta. Około 40% pozostało neutralnych, a pozostałe 45% stwierdziło, że kierownik projektu nie ma takiej mocy. Biorąc pod uwagę, że projekty te są projektami zewnętrznymi i rządowymi, wyniki te mają sens.
podsumowanie
nasze wyniki badań pokazują, że większość projektów jest napędzana wymaganiami. Prawie wszystkie projekty reprezentowane w tym badaniu wykazały, że można je dostosować do zmian. Nieformalna komunikacja jest uważana za ważniejszą niż formalne procesy i systemy. Biorąc pod uwagę, że projekty w badaniu są związane z pracami rządowymi, wyniki pokazują, że zespół projektowy koncentruje się na realizacji projektu nad kompleksową dokumentacją. Ponadto współpraca z klientami nad negocjacjami umów działa lepiej dla zespołów projektowych. Częsta zmiana zakresu projektu oznacza znaczenie iteracyjnego lub etapowego planowania projektu; ważna cecha zwinnego zarządzania projektami. Biorąc pod uwagę, że wszystkie projekty konsultingowe it reprezentowane w tym badaniu są umowami, wyniki badań zachęcają do formalnego przyjęcia zwinnej metodologii dla projektów konsultingowych IT i łączenia ich z tradycyjnymi praktykami zarządzania projektami, takimi jak rozwój i monitorowanie kamienia milowego w oparciu o plan, procedury akceptacji użytkowników i praktyki zarządzania jakością.
przydatność metody zwinnej dla projektów to zobowiązanie umowne związane z dokumentami dotyczącymi planowania, monitorowania i kontroli projektu. Projekty związane z rządem federalnym zwykle mają istotne wymagania dokumentacyjne, takie jak przestrzeganie norm takich jak ISO9000 i OMB300; powinniśmy zachować ostrożność w modyfikowaniu zwinnej metody dla takich projektów.
wyzwaniem jest utrzymanie zwinności, szybkiej reakcji na zmiany, elastycznych i prostych planów, ciągłej integracji i innych korzyści płynących z metody agile, przy jednoczesnym włączeniu niektórych kompleksowych procesów tradycyjnych praktyk zarządzania projektami.