Introducere

proiectele sunt adesea mijloacele de operaționalizare a planurilor strategice ale unei organizații. Sunt avute în vedere proiecte de dezvoltare a produselor și serviciilor și de obținere a eficienței operaționale. Afacerile devin din ce în ce mai proiectizate, iar cheltuielile globale pentru proiecte sunt de ordinul a multe miliarde de dolari anual (Williams, 2005). Motivele sunt evidente. Proiectele oferă o oportunitate de a utiliza practici de management de proiect care promovează utilizarea eficientă și eficace a resurselor. Cu toate acestea, în ciuda progreselor în disciplina și profesia de management de proiect, experiența comună sugerează că multe proiecte eșuează (Williams, 2005), ceea ce subliniază importanța și necesitatea îmbunătățirii proceselor și performanței managementului de proiect.

în general, organizațiile se străduiesc să implementeze cele mai bune practici de management de proiect tradițional—bazate pe standardele PMI—pentru a îndeplini obiectivele proiectului și pentru a satisface așteptările clienților. Cu toate acestea, nu toate procesele și practicile recomandate ale corpului de cunoștințe de management al proiectului (Ghidul PMBOK al proiectului) pot fi relevante pentru fiecare proiect. Adesea, o abordare selectivă are sens în adoptarea proceselor și practicilor de management de proiect pentru a se potrivi nevoilor specifice ale proiectului, pe baza dimensiunii, tipului, complexității și industriei în care se desfășoară proiectul. O astfel de nevoie de o abordare diferită a gestionării proiectelor IT este bine documentată în literatura de management de proiect.

proiectele de Dezvoltare Software se confruntă adesea cu provocări conflictuale de a dezvolta produse software într-un ritm accelerat, dezvoltându-le în același timp cu o robustețe pentru a le face fiabile (Boehm, 2002). Proiectele IT, care urmăresc să țină pasul cu evoluțiile tehnologice în schimbare rapidă, suferă adesea modificări ale domeniului de aplicare în timpul etapelor de planificare și implementare. În consecință, proiectele IT au provocări diferite de proiectele tradiționale. Mai multe ajustări și modificări ale practicilor tradiționale de management de proiect sunt dezvoltate și practicate pentru proiectele IT, introducând astfel noi metodologii de management de proiect, cum ar fi managementul de proiect agil.

metodologia de management de proiect Agile—cu adaptabilitatea sa mai mare la domeniul de aplicare în schimbare frecventă—utilizează planificarea iterativă sau pe etape și integrarea continuă. Principiul cheie este de a menține domeniul de aplicare al proiectului moale. Metodologia promovează colaborarea și are ca rezultat creșterea satisfacției clienților. Cu toate acestea, agile nu este o soluție completă pentru dezvoltarea de software într-un ritm rapid, în timp ce satisface cerințele clienților de robustețe și fiabilitate. În acest context, Boehm (2002) a recomandat o combinație de management de proiect tradițional și metodologie de dezvoltare de software agil, care este fezabilă și preferabilă. O abordare complementară ar fi dezvoltarea unei abordări bazate pe riscuri, care să fie adaptată pentru a păstra beneficiile atât ale metodelor agile, cât și ale celor bazate pe plan și, în același timp, pentru a atenua multe dintre slăbiciunile lor (Boehm & Turner, 2003).

această lucrare de cercetare își propune să examineze propunerile de mai sus (Boehm, 2002; Boehm & Turner, 2003) ale unei abordări combinate pentru gestionarea proiectelor de consultanță IT, care sunt diferite de proiectele IT. Proiectele de consultanță IT sunt concepute pentru a gestiona și a oferi sprijin proiectelor IT. Ele sunt adesea inițiate în sectorul guvernamental. Proiectele de consultanță IT nu sunt proiecte de dezvoltare software; mai degrabă, ele oferă suport de proiect proiectelor IT.

în acest studiu ne propunem să dezvoltăm o înțelegere a modului în care practicile agile de management de proiect sunt relevante pentru proiectele de consultanță IT. Obiectivele studiului sunt de a identifica beneficiile utilizării managementului de proiect agil, adecvarea acestuia și ce aspecte ale managementului tradițional de proiect pot fi combinate cu managementul de proiect agil pentru proiectele de consultanță IT pentru a îmbunătăți performanța proiectului. În secțiunea următoare, folosind o analiză amplă a literaturii de specialitate a metodologiei de management de proiect agile, am identificat caracteristicile esențiale ale metodei agile și abordarea lor unică în gestionarea proiectelor în comparație cu managementul de proiect tradițional. Revizuirea literaturii a ajutat la dezvoltarea unei înțelegeri a conceptelor cheie și a beneficiilor utilizării dezvoltării de software agile. Mai mult, pe baza rezultatelor analizei literaturii de specialitate, am dezvoltat și prezentat o metodă de cercetare folosind un chestionar structurat pentru a dezvolta o înțelegere a proiectelor de consultanță IT. Analiza și discuția datelor, prezentate ulterior, oferă informații și constatări importante ale studiului. Încheiem lucrarea cu rezultatele cercetării și recomandările noastre pentru proiectele de consultanță IT.

Revizuirea literaturii

practicile tradiționale de management de proiect, care sunt conduse de o planificare cuprinzătoare, pot fi utilizate atunci când specificațiile proiectului sunt clar definite. Pe de altă parte, atunci când specificațiile sunt supuse unor modificări frecvente pe durata de viață a proiectului, abordarea tradițională a gestionării proiectelor poate să nu funcționeze eficient. Proiectele de dezvoltare Software sunt adesea concepute cu specificații minime, provocând modificări frecvente ale acestor specificații în timpul implementării proiectului. Mai mult, duratele de dezvoltare a proiectelor software sunt scurte. Metodele Agile, în comparație cu tehnicile tradiționale de management de proiect, sunt potrivite pentru proiectele de dezvoltare software datorită duratei scurte de dezvoltare a acestor proiecte (Hanakawa & Okura, 2004).

în general, diverse metode de dezvoltare software, cum ar fi managementul de proiect agil, promit o satisfacție sporită a clienților, rate mai mici de defecte, timpi de dezvoltare mai rapizi și servesc ca soluție la cerințele proiectului în schimbare rapidă (Boehm & Turner, 2003). Spre deosebire de managementul de proiect agil, un model stage-gate folosește un proces de lucru de la ideea conceptului la un produs care este livrat în cele din urmă. Acest model dezvoltă fazele ciclului de viață al managementului de proiect pe baza diferitelor etape de dezvoltare a produsului pentru gestionarea proiectelor. O distincție importantă între un model stage-gate și un management de proiect agil este că primele încercări de a minimiza modificările cerințelor, astfel încât produsul să fie finalizat la timp (Karistrom & Runeson, 2005). O altă metodă de dezvoltare a software-ului este SCRUM, care este un set de principii de management de proiect care utilizează echipe mici inter-funcționale și autogestionate (Schatz & Abdelshafi, 2005). SCRUM cere ca fiecare membru al echipei și proprietar de produs să lucreze împreună la începutul fiecărui element de dezvoltare, iar metodologia acționează ca un înveliș în jurul proceselor de dezvoltare existente. Prin urmare, Schatz și Abdelshafi au susținut că SCRUM nu va avea un plan de bază pentru a măsura succesul proiectului. Cu toate acestea, managementul de proiect agil este luat în considerare pentru acest studiu datorită flexibilității și adaptabilității sale mai mari la proiectele de dezvoltare software.

pe lângă beneficiile discutate mai sus, metodologia agile este aplicabilă mediilor turbulente și în continuă schimbare (Highsmith & Cockburn, 2001). Mai mult, metoda agile subliniază adaptabilitatea la piață, tehnologie și proces (Mellor, 2005). Metodologia agile este o abordare care se va concentra mai întâi pe caracteristici importante și, ca rezultat, va căuta feedback timpuriu cu privire la caracteristici (Karistrom & Runeson, 2005). Odată identificate caracteristici importante, managerul de proiect se va asigura că nu există întârzieri. Karistrom și Runeson au indicat că procesul agil ar evita înghesuirea resurselor, a planurilor fixe și sprijinirea planurilor pe termen lung.

cu toate acestea, metodologia agile nu este potrivită pentru toate proiectele de dezvoltare software. Citându-l pe Scott Ambler, dezvoltatorul metodei agile, Boehm (2002) a recomandat metodologia tradițională de gestionare a proiectelor bazată pe plan pentru software-ul de asigurare, cum ar fi sistemele critice pentru viață.

metoda agile, datorită mediului său de proiect exigent caracterizat prin haos și incertitudine, au nevoie de echipe de proiect formate din oameni talentați pentru a satisface nevoile și cerințele provocatoare. Citând un studiu de cercetare realizat de Constantine (2001), Boehm (2002) a sugerat că metodele agile necesită oameni foarte capabili. Mai mult, agile nu este potrivit pentru echipe mai mari (Highsmith & Cockburn, 2001), deoarece necesită o muncă în echipă strâns coordonată pentru a reuși, iar echipele cu peste 15 sau 20 de dezvoltatori cresc dificultatea gestionării proiectului (Constantine, 2001).

este evident că metoda agile folosește Echipe coerente (Karistrom & Runeson, 2005). Karistrom și Runeson au identificat caracteristici agile suplimentare, cum ar fi sarcini mici și ușor de gestionat, integrare continuă și testare automată. În consecință, echipele de proiect agile se caracterizează printr-o bună comunicare internă, o calitate superioară și un sentiment de control (Karistrom & Runeson). Cu toate acestea, ei au în vedere o potențială izolare pentru echipa agilă.

în ceea ce privește comunicarea, gestionarea bazată pe documente a progresului și controlul calității, o practică obișnuită în managementul tradițional de proiect nu se potrivește cu metoda de dezvoltare software agilă (Hanakawa & Okura, 2004). Interacțiunea față în față pentru realinierea continuă a obiectivelor de dezvoltare este de obicei preferată în metodologiile agile (Melnik & Mauer, 2004). Subliniind diferența dintre metodele tradiționale și cele agile, Melnik și Mauer au sugerat că transferul scurt de cunoștințe și comunicarea și colaborarea directă sunt preferate în dezvoltarea de software, spre deosebire de practicile tradiționale de management de proiect, unde sunt utilizate lanțuri lungi de transfer de cunoștințe, care sunt adesea susceptibile la distorsiuni și pierderi de informații.

una dintre diferențele importante dintre practicile tradiționale de management de proiect bazate pe plan și metodele agile este că metodele agile captează agilitatea din cunoștințele tacite ale echipei de proiect, mai degrabă decât cunoștințele explicite, adesea folosite sub formă de documente și planuri în managementul tradițional de proiect (Boehm, 2002).

o altă diferență este cantitatea și tipul de documentație creată pentru proiecte. Managementul de proiect tradițional bazat pe Plan pune accentul pe planificarea detaliată, monitorizarea și controlul documentelor. Raționamentele de proiectare, documente care exprimă motive și justificări, sunt create folosind o procedură extrem de automatizată, iar aceste raționamente de proiectare servesc drept documentație agilă (Sauer, 2003).

Coram și Bohner (2005) au identificat caracteristici comune ale metodei agile: colaborare, echipe mici, programe de lansare scurte, box de timp și testare constantă. Managerul de proiect este responsabil pentru asigurarea unui mediu extrem de colaborativ. În acest scop, metoda agile încurajează echipele mici și câteva sub-Echipe pe proiect pentru a încuraja colaborarea. În consecință, este posibil ca metoda agilă să necesite mai puțin proces și planificare pentru a coordona activitățile echipei. Metoda agile folosește, de asemenea, programe de lansare scurte, care pot varia de la două săptămâni la șase luni. Time boxing este un concept care impune o durată fixă pentru lansarea livrabilelor proiectului, ceea ce ajută la reducerea placării cu aur și a creepului de aplicare. Testarea constantă asigură calitatea și integrarea produsului. Mai mult, Coram și Bohner au sugerat că managerii de proiect trebuie să urmărească progresul și să ia decizii de afaceri cu accent pe răspunsul la schimbare, mai degrabă decât să urmeze un plan specific.

boxul timpului duce la o planificare imprevizibilă prin cea mai bună presupunere, iar datele fixe ar putea aduce surprize neașteptate în faza de dezvoltare (Patton, 2003). O altă consecință a acestui proces iterativ de planificare a proiectului este că metoda agile nu poate monitoriza progresul pe baza procentului complet (Patton, 2003).

implicarea sub-echipelor mici în planificare va duce la ingineri motivați de dezvoltare software; problemele tehnice sunt ridicate la începutul proiectului și va exista puțină rezistență în implementare (Karistrom & Runeson, 2005). În plus, definirea domeniului de aplicare al proiectului cu o abordare agilă ar duce la reducerea costurilor (Mcgovern, 2002). Metoda agile folosește planificarea bazată pe cerințe și ne va permite, de asemenea, să controlăm domeniul de aplicare (McGovern).

folosind toate referințele și discuțiile de până acum și altele (Little Greene, Phillips, Pilger & Poldervaart, 2004; Little, 2005; Abrahamsson, Warsta, Siponen, & Ronkainen, 2003; Ilieva, Ivanov, & Stefanova, 2004; Lindvall, 2004), Tabelul 1 oferă o comparație sumară între practicile tradiționale și cele agile de management de proiect.

Tabelul 1: Comparație între Agile și managementul de proiect tradițional

faza proiectului	tradițional	agil
inițierea	proiect formalizat capabilitate calitate cerințe previzibile, evoluție politici formale de comunicare abordare de înaltă asigurare și stabilitate	prioritizate povești informale cazuri de testare schimbări rapide imprevizibile informale, față în față comunicare schimbare radicală și abordare rapidă a valorii
planificare	documentat cunoștințe documentate explicite plan Formal abordare cuprinzătoare domeniu de aplicare bine definit schimbare lentă a domeniului de aplicare (aprobat) predictibilitate optimizare alocare de resurse bazată pe Plan risc scăzut din cauza planurilor planul inflexibil și domeniul de aplicare utilizarea extensivă a controlului calității și a instrumentelor planul și afacerea proiect program bazat pe Plan	plan flexibil condus mai puțin documentat cunoștințe interpersonale tacite plan iterativ abordare bazată pe Cerințe schimbarea domeniului de aplicare schimbări frecvente, radicale imprevizibile bazate pe Cerințe, felxibile alocarea resurselor bazate pe nevoi risc ridicat, imprevizibil plan flexibil și domeniu de aplicare fără utilizare a instrumentelor de calitate datorită modificărilor domeniului de aplicare proiect bazat pe afaceri și nevoi bazat pe timp schedule
Execution	Extensive design Longer increments Detailed execution plan Comprehensive scope change control Contractual and scope-based procurement Integration during integration Large teams for execution	Simple design Short increments Iterative and reactive execution plan Easy refactoring Requirement-based procurement Continuous integration echipe mici pentru execuție
monitorizare și control	control cantitativ documentat-planuri și proceduri de testare valoarea câștigată pentru urmărirea costurilor proiectului săptămânal și lunar	controlul calitativ cazurile de testare executabile definesc testarea schimbarea frecventă a liniei de bază instrumente grafice Simple pentru raportare
Closeout	abordare sistematică a contractului closeout ușor de capturat lecții învățate lecții explicite și tacite învățate	lipsa de orientări (Termeni și Condiții) dificil de capturat lecțiile învățate Tacit-lecții învățate intensiv în cunoaștere

Rezumatul revizuirii literaturii

metodologia de management de proiect Agile este frecvent utilizată pentru proiectele de dezvoltare software. Are o adaptabilitate mai mare la domeniul de aplicare în schimbare frecventă. În consecință, managementul de proiect agil utilizează planificarea iterativă sau pe etape și integrarea continuă pe toată durata de viață a proiectului. Principiul cheie în managementul de proiect agil este de a menține domeniul de aplicare al proiectului moale. Metoda de management de proiect Agile este diferită de o metodă tradițională de management de proiect prin atribuirea importanței factorilor care sunt considerați în mod tradițional neimportanți. Agile atribuie o importanță relativ mai mare:

• persoane fizice și interacțiuni asupra proceselor și instrumentelor
• executarea proiectului Peste documentație cuprinzătoare
• colaborarea cu clienții peste negocierea contractului
• răspuns la schimbare peste un plan de proiect

metoda agile subliniază flexibilitatea pentru a satisface nevoile proiectului. Mai mult, se bazează pe feedback-ul clienților pentru a iniția modificări ale unui plan de proiect. Metodologia utilizează abordarea de identificare a utilizatorilor finali adecvați și a obiectivelor acestora pentru a formula rezultatele proiectului și pentru a satisface nevoile performante ale proceselor de afaceri. Avantajele utilizării metodei agile includ creșterea satisfacției clienților, rate mai mici de defecte și timpi de dezvoltare mai rapizi. În plus, metoda agile este un răspuns la cerințele în schimbare rapidă, deoarece utilizează feedback timpuriu cu privire la caracteristicile tehnologice ale livrabilelor proiectului. Metoda agilă asigură că cerințele nu sunt înghesuite. Caracteristicile cheie ale metodei agile sunt comunicarea eficientă în cadrul și în afara echipei de proiect și demonstrarea flexibilității în adăugarea mai multor cerințe.

aceste beneficii ar ajuta organizațiile să ofere servicii mai bune pentru clienți. Mai mult, acestea sunt relevante în economia actuală, unde Globalizarea și o filozofie de marketing liber afectează percepțiile clienților în creșterea așteptărilor de a livra produse și/sau servicii mai rapid, mai ieftin și mai bun.

cu toate acestea, metoda agile nu este lipsită de deficiențe, așa cum se poate observa în tabelul 1. Schimbarea frecventă a domeniului de aplicare duce la dificultăți în monitorizarea progresului proiectului. De asemenea, nu este ușor să surprinzi cunoștințele tacite sub forma lecțiilor învățate. Controlul schimbării domeniului de aplicare, documentația, planul cuprinzător, managementul calității și managementul riscurilor sunt beneficii importante ale managementului tradițional de proiect de care putem fi privați atunci când folosim metoda agile.

metodologia cercetării

am folosit atât interviuri personale, cât și chestionare pentru a colecta datele. Am elaborat un chestionar structurat format din două secțiuni. Prima secțiune a fost concepută pentru a surprinde detalii despre proiect și caracteristicile acestuia. Această secțiune cuprinde 13 întrebări, care sunt legate de demografia proiectului și practicile de management al proiectului. Acestea au fost prezentate participanților la studiu cu o opțiune de a oferi răspunsuri deschise atunci când este necesar.

a doua secțiune s-a axat pe declarațiile practice de management de proiect, iar participanților li s-a cerut să răspundă la aceste declarații pe o scară de cinci puncte, 1 indicând „nu sunt de acord cu tărie” și 5 indicând „sunt de acord cu tărie.”Următoarele afirmații au fost utilizate abordând principii comune importante ale practicilor de management de proiect, precum și servind la contrastarea practicilor tradiționale și agile de management de proiect.

• criteriile de măsurare a succesului proiectului se bazează pe obiectivele și obiectivele proiectului.
• proiectul este condus de cerințe.
• proiectul este adaptabil la schimbare.
• în opinia dvs., eforturile de management de proiect au obținut rezultate așteptate
• interacțiunile față în față și lanțurile de comunicare mai scurte au o importanță mai mare decât procesele și instrumentele.
• echipa se concentrează pe execuția proiectului Peste documentația completă.
• colaborarea cu clienții peste negocierea contractului funcționează mai bine pentru echipa ta.
• proiectul are un domeniu de aplicare bine definit.
• practici de management de proiect urmați PMBOK ghid de viață al proiectului ciclu de viață.
• planificarea iterativă sau etapizată a proiectului este urmată pentru proiect.
• proiectul are cerințe de documentare, cum ar fi respectarea standardelor, cum ar fi ISO9000, OMB 300.
• procedurile de testare a acceptării utilizatorilor (UAT) sunt urmate pe tot parcursul proiectului.
• managerul de proiect este împuternicit să ia decizii legate de proiect fără intervenția clientului.

răspunsurile la aceste afirmații sunt analizate împreună cu întrebările corespunzătoare din primul set de 13 întrebări. Împreună, răspunsurile la ambele secțiuni au oferit o înțelegere detaliată a proiectului pentru o analiză semnificativă.

rezultatele studiului

chestionarul a fost structurat pentru a capta date despre 20 de proiecte de consultanță IT, care erau în desfășurare la momentul cercetării. Dintre proiecte, 65% sunt proiecte de tip contract de timp și material, iar restul sunt de tip Preț fix ferm (FFP). Dintre proiectele de timp și materiale, 55% au o durată a proiectului mai mare de doi ani.

majoritatea echipelor de proiect sunt mici: doar 15% au 10 sau mai mulți membri. În ceea ce privește comunicarea între membrii echipei de proiect, 60% dintre respondenți au utilizat doar comunicarea formală pentru nevoile proiectului; 30% au folosit atât comunicarea formală, cât și cea informală, iar restul de 10% s-au bazat doar pe metode informale.

unul din doi respondenți a indicat că proiectele lor au folosit un plan de proiect. Într-o întrebare conexă, din acele proiecte care nu aveau un plan de proiect, 80% nu au folosit nici planificarea iterativă.

schimbarea domeniului de aplicare este un aspect important al acestui studiu. Dintre proiecte, 70% s-au confruntat cu modificări ale domeniului de aplicare cel puțin o dată. Dintre cei care au experimentat schimbarea domeniului de aplicare al proiectului, 60% au experimentat-o de mai mult de două ori. În timp ce clientul decide schimbarea domeniului de aplicare, consultantul—cu acordul clientului—poate include planul de control al calității în planul de management al proiectului. Când au fost întrebați dacă au un plan de control al calității pentru proiectul lor, 65% dintre respondenți au indicat că nu au utilizat un plan de control al calității.

rezultate discuție și analiză

rezultatele cercetării au fost analizate examinând cu atenție orice interrelație între o întrebare și toate celelalte întrebări în primul rând pentru a valida rezultatele și în al doilea rând, pentru a dezvolta strategii eficiente de management. În plus, aceste rezultate au fost analizate în vederea examinării practicilor agile și tradiționale de management de proiect care pot fi utilizate în combinație pentru a dezvolta o abordare robustă de management de proiect pentru proiectele de consultanță IT.

criterii de succes ale proiectului bazate pe obiectivele și obiectivele sale

un proiect este considerat de succes atunci când își îndeplinește obiectivele și obiectivele. Doar 60% dintre respondenți au fost de acord cu afirmația: „criteriile de măsurare a succesului proiectului se bazează pe obiectivele și obiectivele proiectului.”Aproximativ 30% dintre respondenți nu au fost de acord. Analiza ulterioară a arătat că motivul dezacordului a fost că aceste proiecte se confruntau cu condiții și cerințe în continuă schimbare sau clientul nu era clar cu privire la proiect. În cele din urmă, aceste proiecte se confruntau cu schimbări frecvente ale domeniului de aplicare. Într-un anumit caz, obiectivele și obiectivele proiectului s-au schimbat.

este interesant de observat că nu există nicio asociere între faptul că criteriile de succes ale unui proiect sunt derivate din obiectivele sale și schimbarea domeniului de aplicare, tipul de proiect și existența unui plan de proiect. Cu alte cuvinte, derivarea criteriilor de proiect din planul strategic al organizației nu are nicio influență asupra schimbării domeniului de aplicare și dacă proiectul are un plan.

cerințe de proiect

de obicei, un plan de proiect detaliat este elaborat după ce cerințele sponsorului proiectului sunt identificate în mod clar. Dezvoltarea planului de proiect și executarea acestuia, în principiu, ar trebui să fie determinate de aceste cerințe. Prin urmare, ne-am aștepta ca managerii de proiect să fie de acord cu afirmația: „proiectul este condus de cerințe.”Rezultatele studiului arată că doar 60% dintre respondenți au spus că proiectele lor sunt conduse de cerințe. Aproximativ 20% dintre respondenții care nu au fost de acord cu declarația au indicat că proiectele lor sunt executate fără a utiliza un plan de proiect.

aproximativ 20% dintre respondenții care au fost neutri ca răspuns la această declarație sunt managerii de proiect care nu au experimentat nicio schimbare de domeniu în proiectele lor. Toți ceilalți respondenți, cei care au fost de acord sau nu au fost de acord cu declarația, au experimentat schimbări de domeniu de aplicare cel puțin o dată în proiectele lor actuale.

în general, dacă un proiect nu este implementat conform planului său, putem presupune că cerințele nu sunt identificate sau se așteaptă ca cerințele proiectului să se schimbe în timpul executării sale. În acest studiu, însă, nu putem stabili o astfel de asociere între „implementarea proiectului fără utilizarea planului de proiect” și „proiectul nu este condus de cerințe”, deoarece doar 50% dintre cei care au fost de acord cu a doua declarație au gestionat și proiecte fără a utiliza un plan.

adaptabilitate la schimbare

optsprezece din 20 de proiecte au răspuns cu succes schimbărilor din proiect. Adaptabilitatea la schimbare este considerată o caracteristică primară pentru ca un proiect să fie candidat pentru utilizarea metodologiei agile de management de proiect. Proiectele de consultanță IT reprezentate în acest studiu au demonstrat că au adaptabilitate pentru a face față schimbărilor de domeniu.

eforturile de management de proiect realizate rezultate așteptate

rezultatele sugerează că clientul este mulțumit de rezultat în majoritatea proiectelor (70%). Cu toate acestea, aceste răspunsuri nu au fost asociate cu răspunsurile la alte întrebări importante ale sondajului despre progresul proiectului și produsul dezvoltat din perspectiva managerului de proiect. Motivele sunt evidente. Proiectele se confruntau încă cu depășiri de timp și Costuri. În timp ce rezultatul final în livrarea produsului software este satisfăcător, procesele de management de proiect nu au fost executate cu succes. Concluzia ar putea fi că adoptarea practicilor tradiționale de management de proiect, cum ar fi dezvoltarea etapelor, monitorizarea și controlul, ar fi ajutat la gestionarea cu succes a proiectului.

importanța comunicării față în față versus procese

comunicarea este cheia înțelegerii rolurilor, responsabilităților, politicilor și procedurilor legate de proiecte și încurajarea colaborării. În cele din urmă, comunicarea duce la o echipă de proiect coezivă și încurajează membrii echipei să colaboreze și să participe la luarea deciziilor. Șapte din zece manageri de proiect care au participat la studiu au fost de acord că interacțiunile față în față și lanțurile de comunicare mai scurte au primit mai multă importanță decât procesele și instrumentele.

rezultatele arată o asociere puternică între importanța comunicării față în față și mijloacele de comunicare între membrii echipei de proiect. Cei care nu au fost de acord că comunicarea față în față este mai importantă decât procesele proiectului au folosit comunicarea informală între membrii echipei de proiect, în timp ce cei care au considerat comunicarea față în față ca fiind mai importantă au folosit atât comunicarea formală, cât și cea informală.

concentrați-vă pe execuția proiectului asupra documentației

documentația proiectului este adesea trecută cu vederea și, în consecință, organizațiile sunt private de lecțiile importante învățate în planificarea și execuția proiectului. Având în vedere că toate proiectele reprezentate în acest studiu sunt proiecte ale guvernului federal, este interesant de menționat că 70% dintre managerii de proiect care au răspuns au fost de acord că echipele lor s-au concentrat pe execuția proiectului în comparație cu crearea unei documentații complete. În câteva cazuri în care managerii de proiect au considerat că documentația este mai importantă decât execuția proiectului, investigațiile ulterioare au arătat că clientul a fost indecis cu privire la proiect în toate aceste cazuri.

colaborarea cu clienții asupra negocierii contractului

negocierea contractului este o caracteristică esențială a proiectelor externe. În timpul negocierilor, ambele părți s-ar concentra pe protejarea propriilor interese. Negocierea contractului poate avea loc în diferite etape ale proiectului. Este de dorit să abordăm aceste probleme prin colaborare, în special în timpul implementării proiectului; în caz contrar, va duce la probleme precum prelungirea contractului. Având în vedere că toate proiectele reprezentate în acest studiu sunt contracte, este încurajator să observăm că mai mult de jumătate dintre managerii de proiect care au răspuns (60%) consideră că colaborarea cu clienții este mai importantă decât negocierea contractelor. Ei au sugerat că colaborarea funcționează mai bine pentru echipele de proiect.

unde au existat dezacorduri, implicând că colaborarea nu este la fel de importantă ca negocierea, două fapte interesante au fost asociate cu aceste proiecte. Toate celelalte proiecte au folosit contactul direct ca mijloc de comunicare cu părțile interesate ale proiectului, dar aceste proiecte au folosit comunicarea în lanț, iar clientul a fost, de asemenea, indecis cu privire la proiect. Ambii factori implică condiții dificile de colaborare.

proiectul și un domeniu de aplicare bine definit al proiectului

proiectele sunt de obicei asociate cu incertitudini și factori necunoscuți, care duc la ambiguitate. În consecință, domeniul de aplicare și specificațiile detaliate nu pot fi dezvoltate în faza incipientă a proiectului. Domeniul de aplicare al proiectului se schimbă continuu pe tot parcursul proiectului. Uneori, obiectivele originale ale proiectului se pot schimba și ele. Dintre proiectele analizate, 40% au un domeniu de aplicare bine definit, în timp ce alte 45% nu.

cu toate acestea, 80% din proiecte au suferit modificări de domeniu de aplicare cel puțin o dată, ceea ce validează argumentele prezentate anterior.

practici de management de proiect și Ghidul PMBOK al proiectului ciclul de viață al proiectului

Ghidul PMBOK al proiectului a dezvoltat un proces elaborat al ciclului de viață al managementului de proiect; este exhaustiv și cuprinzător. Cu toate acestea, nu este necesar ca fiecare proces al ciclului de viață al managementului de proiect al Ghidului PMBOK XV să fie aplicat fiecărui proiect. Adoptarea sa ar trebui să fie specifică proiectului. Așa cum era de așteptat, 45% dintre managerii de proiect au urmat practicile de management al proiectului din ciclul de viață al proiectului PMBOK ghid de la 7, iar alți 45% nu au făcut-o.

planificarea iterativă sau etapizată a proiectului

definiția domeniului de aplicare și planul de management al proiectului fac parte din planul de proiect. După cum s-a discutat anterior, dezvoltarea detaliată a domeniului de aplicare și a specificațiilor nu poate fi dezvoltată la începutul proiectului. În consecință, domeniul de aplicare al proiectului se schimbă continuu pe tot parcursul proiectului, ceea ce subliniază importanța planificării iterative sau pe etape a proiectului, o caracteristică importantă a metodei agile. Când au fost întrebați dacă planificarea iterativă sau etapizată a proiectului este urmată sau nu, jumătate dintre respondenți au indicat da și doar 15% nu au urmat planificarea iterativă a proiectului. Este interesant de observat că toți cei care nu au fost de acord cu practica planificării iterative a proiectului nu au avut în primul rând un plan de proiect.

documentație și respectarea standardelor

documentația de proiect servește ca referință pentru analiza datelor istorice și ajută organizațiile să îmbunătățească continuu procesele de management de proiect și să dezvolte standarde. Documentația va ajuta, de asemenea, la identificarea lecțiilor învățate și la modificarea sistemelor de management de proiect care vor duce la maturitatea managementului de proiect. OMB300 și ISO9000 servesc drept ghiduri în proiectarea sistemelor de documentare a proiectului. Mai exact, multe proiecte guvernamentale trebuie să respecte liniile directoare OMB300. Dintre respondenți, 80% au spus că proiectele IT pe care le gestionează au cerințe de documentare precum respectarea standardelor precum ISO9000 și OMB300. Cu toate acestea, aceste cerințe pentru proiectele de consultanță IT sunt aplicabile într-o măsură limitată.

proceduri de testare a acceptării utilizatorilor

satisfacția clienților este măsura principală a calității și succesului pentru elementele livrabile ale proiectului. Prin urmare, procedurile de testare a acceptării utilizatorilor sunt considerate importante. Chiar și în cazul livrabilelor de proiect mai puțin tangibile, cum ar fi serviciul, măsura de bază a succesului proiectului este satisfacția clienților. Cu toate acestea, este subiectiv. Doar 30% dintre respondenți au declarat că au urmat procedurile de testare a acceptării utilizatorilor pe tot parcursul proiectului, iar 45% dintre respondenți nu au făcut-o.

abilitarea de a lua decizii legate de proiect

în general, managerilor de proiect ar trebui să li se acorde o mână liberă pentru a lua decizii legate de proiect fără intervenția clientului, atunci când aceste decizii nu au niciun impact major asupra domeniului de aplicare al proiectului sau a rezultatelor proiectului. Doar 15% au fost de acord că managerul de proiect este împuternicit să ia decizii legate de proiect fără intervenția clientului. Aproximativ 40% au rămas neutri, iar restul de 45% au declarat că managerul de proiect nu are această putere. Având în vedere că aceste proiecte sunt proiecte externe și guvernamentale, aceste rezultate au sens.

concluzie

rezultatele studiului nostru arată că majoritatea proiectelor sunt determinate de cerințe. Aproape toate proiectele reprezentate în acest studiu au demonstrat că sunt adaptabile la schimbare. Comunicarea informală este considerată mai importantă decât procesele și sistemele formale. Având în vedere că proiectele din studiu sunt legate de munca guvernamentală, rezultatele arată că echipa de proiect s-a concentrat pe execuția proiectului Peste o documentație cuprinzătoare. În plus, colaborarea cu clienții asupra negocierii contractelor funcționează mai bine pentru echipele de proiect. Schimbarea frecventă a domeniului de aplicare al proiectului semnifică importanța planificării iterative sau pe etape a proiectului; o caracteristică importantă a managementului de proiect agil. Având în vedere că toate proiectele de consultanță IT reprezentate în acest studiu sunt contracte, rezultatele studiului încurajează adoptarea formală a metodologiei agile pentru proiectele de consultanță IT și combinarea acestora cu practicile tradiționale de management de proiect, cum ar fi dezvoltarea și monitorizarea milestone-ului, procedurile de acceptare a utilizatorilor și practicile de management al calității.

adecvarea metodei agile pentru proiecte este o obligație contractuală legată de documentele privind planificarea, monitorizarea și controlul proiectului. Proiectele asociate cu guvernul federal au de obicei cerințe semnificative de documentare, cum ar fi respectarea standardelor precum ISO9000 și OMB300; ar trebui să fim atenți la modificarea metodei agile pentru astfel de proiecte.

provocarea este de a menține agilitatea, răspunsul rapid la schimbare, planuri flexibile și simple, integrarea continuă și alte beneficii ale metodei agile, încorporând în același timp unele dintre procesele cuprinzătoare ale practicilor tradiționale de management de proiect.