Sėkmingo projekto įgyvendinimo sąlygos, veiksniai ir kriterijai. Projekto sėkmės kriterijai Projekto valdymo sėkmės ir nesėkmės kriterijai

Daugelis organizacijų yra orientuotos į projektus. Įmonės egzistuoja gaudamos naujus projektus ir sėkmingai juos įgyvendindamos. Sėkmingai užbaigti projektai yra pagrindas, ant kurio organizacija kuria savo ateitį. Nesvarbu, ar jie susiję su naujų produktų kūrimu, pastatų statymu, gamybos pajėgumų didinimu, ar naujos kompiuterinės sistemos įdiegimu.

Projektų valdymas yra būtinas norint veiksmingai koordinuoti ir valdyti organizaciją, užtikrinant, kad teisingi veiksmai būtų atliekami tinkamu laiku, visiškai suprantant pasekmes. Projektų valdymo menas apima galimybę pasiekti tikslus, laikantis nustatytų finansinių, materialinių, žmogiškųjų, laiko ir kitų išteklių apribojimų.

Tačiau daugumoje įmonių projektai ne visada vyksta sklandžiai. Jie netelpa į kasdienio darbo rutiną. Pasaulyje žinoma analitikos įmonė „Gartner“ skaičiuoja, kad 66% didelio masto projektų nepasiekia užsibrėžtų tikslų. komerciniais tikslais, baigiami pavėluotai arba gerokai peržengia biudžetą. „Standish“ grupė, kuri stebi tik IT projektų sėkmę ir nesėkmes, nesėkmingus projektus apibrėžia kaip viduryje atsisakytus projektus ir įvertina nesėkmių procentą 15%. Tuo pačiu metu „brokuoti“ projektai (apibrėžiami kaip projektai, kurių išlaidos viršytos, terminai praleisti ir projektai, kurių rezultatai nepatenkinami) sudaro 51% visų IT projektų.

Kodėl tiek daug projektų ir toliau žlunga net vis daugiau dėmesio skiriant kokybiškam projektų valdymui ir vis daugiau patyrusių ir kompetentingų projektų vadovų?

Galleno institutas ir Tarptautinis besimokančių organizacijų ir inovacijų institutas Miunchene atliko sėkmingų ir nesėkmingų projektų priežasčių tyrimą. Jie padarė išvadą, kad priežastys gedimai yra mažiau pramoninio, ekonominio ar techninio pobūdžio, ir yra iš esmės susiję su verslumo kultūra, bendravimu ir informaciniais procesais apie projektą .

Pasak A. Golovino, projektas žlugs tris kartus :

  • kai sukuriami nerealūs planai arba, jei reikia, neperžiūrimi. Tai reiškia, kad jie bus nuplėšti;
  • kai projekto rengėjas nėra susipažinęs su projektų valdymu ir valdo projektą kaip įprastą veiklą. Tuomet skyrių vadovai nežino, ką daryti: pagrindiniai projekto darbai ar užduotys;
  • kai projekto rengėjas, kurdamas projekto komandą, orientuojasi ne į asmenines savybes, o į pareigas. Tada projekto komandos nariai negali atlikti projekto užduočių.

Netiksliai apibrėžti rezultatai ir apimtis, organizacinio įsipareigojimo stoka, prastas išteklių paskirstymas ir rizikos kontrolė, prastas projektų valdymas su netinkamais komponentais ir kt. - dėl bet kurios iš šių priežasčių projektas gali žlugti.

Pagrindinė projekto problemų priežastis yra projekto vadovo gebėjimas spręsti problemas, tuo pačiu sumažinant riziką. Jis turi būti stiprus lyderis, gebantis bendrauti su įmonės vadovybe ir patenkinti lūkesčius valdant išteklius.

Prastas projekto apibrėžimas taip pat yra pagrindinė projekto nesėkmės priežastis, pradedant patvirtinimo etapu. Nepakankamas atskaitomybės ir atsakomybės lygis atitinkamu aukštesniu lygiu neigiamai veikia projekto sėkmę per visą jo gyvavimo ciklą. Jei užsakovas projektui nesuvaldo ar juo ypač nesidomi, yra tikimybė, kad projektas žlugs.

Apskritai reikia pažymėti, kad pagrindinės projekto nesėkmės priežastys yra:

  • Reikalavimai: Neaišku, savitarpio supratimo stoka, prioritetų trūkumas, prieštaringas, dviprasmiškas, netikslus.
  • Ištekliai: Išteklių trūkumas, konfliktai dėl išteklių, pagrindinių išteklių apyvarta, prastas planavimas.
  • Laikas: Pernelyg glausta, nereali, per daug optimistiška.
  • Planavimas: remiantis nepakankamais duomenimis, neatsižvelgiama į viską, nepakankamai detalių, klaidingi skaičiavimai.
  • Rizika: Nenustatytas ar išrastas, kontrolės nebuvimas.

„Standish“ grupė tuo įsitikinusi su labiausiai svarbūs veiksniai projekto sėkmė ar nesėkmė yra, pagal svarbą:

  • Klientų dalyvavimas.
  • Aukščiausios vadovybės palaikymas.
  • Patyręs projektų vadovas.

Remiantis tiek užsienio, tiek vidaus ekspertų tyrimais, dauguma kliūčių sutvarkyti nesėkmingą projektą, tai yra :

  • Įtikinti savininkus priimti pakeitimus, būtinus, kad projektas būtų sėkmingai užbaigtas, neatsižvelgiant į masto, biudžeto, išteklių ir kt. Pokyčius;
  • prastas bendravimas ir savininko dalyvavimas, aiškumo ir pasitikėjimo stoka;
  • prieštaringos politikos ir prioritetų;
  • problema rasti pakankamai kvalifikuotų išteklių projektui užbaigti;
  • trūksta metodikos ar procesų, kad projektas būtų grąžintas į vėžes.

Tyrimo metu buvo nustatyta daug veiksnių, turinčių įtakos sėkmei ištaisyti situaciją su projektu, tačiau svarbiausia yra projekto vadovas, kuris yra svarbiausias komandos narys, galintis paveikti rezultatą, sumažinti riziką ar atsikratyti iš viso jų. Paprastai už probleminio projekto gelbėjimą atsakingas projekto vadovas.

Kiti veiksniai sėkmingai užbaigiant probleminį projektą apėmė standartinės probleminio projekto vykdymo ar gelbėjimo metodikos egzistavimą, įmonės dydį ir pramonės šaką, kurioje ji vykdo veiklą.

Raktas į probleminio projekto išsaugojimą yra pastangos. Kai įmonė nusprendžia savo energiją nukreipti į problemas, keliančias pavojų projektui, ji padidėja.

Sprendimą išsaugoti projektą priima: aukščiausioji vadovybė (50%įmonių), rėmėjas (16%), skyriaus vadovas (16%) arba projekto vadovas (13%). Mažesnėse įmonėse rėmėjas (24%) arba projekto vadovas (24%) turi daug daugiau galių balsuoti už projekto išsaugojimą. Rečiau šį sprendimą priima skyriaus vedėjas (5 proc.).

Praktinės projektų valdymo patirties apibendrinimas rodo, kad dažniausiai žingsniai, kaip išsaugoti projektą , tai yra :

  • komunikacijos ir valdymo modernizavimas (62%);
  • projekto tikslų peržiūra - jo apimties sumažinimas, finansavimo peržiūra (60%);
  • išteklių pridėjimas arba pašalinimas (58%);
  • techninių problemų sprendimas (49%);
  • projekto vadovo pakeitimas arba konsultanto samdymas (36 proc.).

Įmonės, neturinčios metodikos, dažniau renkasi pakeisti projekto vadovą nei tos, kurios yra įsisavinusios metodiką (atitinkamai 22 proc. Ir 9 proc.). Jie taip pat labiau linkę pasitelkti išorės konsultantus projektui gelbėti (26%, palyginti su 11%).

Paprastai probleminio projekto gelbėjimo operacijos yra gana sėkmingos. Beveik trys ketvirtadaliai probleminių projektų (74 proc.) Buvo sėkmingai užbaigti, 18 proc. Vis dar vyksta, todėl galutiniai rezultatai nėra žinomi. Tik 4% yra tikrai suklysti, o 3% yra uždaryti dėl verslo priežasčių.

Sėkmingam projekto įgyvendinimui yra du esminiai veiksniai. Pirmas iš jų yra greičiau techninė projekto valdymo pusė... Jis daugiausia susijęs su planavimu ir išlaidų įvertinimu, projektų valdymu ir kontrole, rizikos valdymu, kokybės valdymu, projekto dokumentacija ir rezultatų vertinimu. Antras veiksnys yra projekto vadovo vadybinė kompetencija.

Įmonės, neturinčios standartinės projekto metodikos, ne visada vertina šiuos įgūdžius nei tos, kurios turi tokią metodiką (78% pirmųjų kalbėjo apie projektų vadovo kvalifikacijos svarbą, o 96% - pastarosios).

Beveik visos atsakančios organizacijos (92 proc.) Tai nurodė projekto vadovo įgūdžiai yra labai svarbūs(64 proc.) Arba tiesiog svarbu (28 proc.) Sėkmingam probleminio projekto gelbėjimo veiksmui.

Svarbu, kad atsakomybė už projekto įgyvendinimą visuose valdymo etapuose (planavimas, įgyvendinimas, kontrolė, analizė, pakeitimai) tenka vienam asmeniui - projekto vadovas. Tai sutelks atsakomybės sritį ir pagerins sprendimų priėmimo proceso efektyvumą.

Sėkmingas projekto įgyvendinimas priklauso ne tik iš projektų vadovų ir vadovų, bet ir iš daugelio kitų projekto komandos narių. Jų veiksmai taip pat turėtų būti reglamentuoti, motyvuoti ir siekti, kad rezultatas būtų ne tik laiku, bet ir kokybiškas.

Svarbus komponentas yra holistinė vaidmenimis pagrįsta kiekvieno individualaus projekto ir viso portfelio valdymo koncepcija... Reikėtų apibrėžti vaidmenis, jų vietą organizacinėje struktūroje, teises ir pareigas, kvalifikacijos reikalavimus. Projekto vaidmenų pavyzdžiai gali būti: projekto vadovas, projekto asistentas, plėtros specialistas, statybos vadovas, statybos specialistas, statybos koordinatorius, dizaino specialistas, vertintojas ir kt.

Dar vienas iš sėkmingo projekto kriterijų- tai gebėjimas pasirinkti „pagrindinį pastangų taikymo tašką“, gebėjimas sutelkti dėmesį į prioritetines užduotis, kurių sprendimas lemia didelę pažangą tikslo link.

Projekto tikslai pasiekiami veiksmais. Projekto vadovas yra įpareigotas nuolat stebėti projekto etapų įgyvendinimą laiku ir išteklių sunaudojimą. Sugaišto laiko ne visada galima kompensuoti, net ir didinant išteklius.

Stebina tai, kad net ir sumaniausiai suplanuotas projektas gali pasiekti tašką, kuriame sunku nustatyti, kaip viskas vyksta. Tačiau būtent tai reikia žinoti norint nukreipti pastangas tikslo link. Be vienos ar kitos stebėjimo sistemos - sekant darbo eigą - neįmanoma būti tikram, kad vadovas projekto „laikosi pirštu ant pulso“.

Laiku ir tiksliai atliekami veiksmai yra bet kurio projekto sėkmės pagrindas. , kurios pagrindas yra organizacinė disciplina - gebėjimas veikti „čia ir dabar“. Projekto veiklos patirtis rodo, kad visų projekto dalyvių drausmės ir įsipareigojimų laikymasis didina sėkmės tikimybę.

Tarp kitų projektų valdymo sėkmės veiksniai reikėtų skambinti:

  • patyrusio projekto vadovo įvedimas ir pakankamų teisių suteikimas jam atlikti būtinus pakeitimus;
  • papildomų, kvalifikuotų išteklių pritraukimas;
  • biudžeto padidėjimas;
  • atviras bendravimas, lūkesčių apibrėžimas ir atsakomybės tarp sprendimų priėmėjų nustatymas;
  • projekto pertvarkymas.

Pokalbis su patyrusiais projektų vadovais, kad sužinotumėte, ar koks yra svarbiausias projekto sėkmės komponentas, parodė, kad yra jos įgyvendinimas... Dažniausiai projektai pagal nutylėjimą yra įstrigę nei dėl klaidų planuojant ar paskirstant išteklius.

Viskas prasideda viršuje. Vadovybė turi žinoti projekto kainą ir apimtį. Nepakanka patvirtinti projekto sąmatą. Kad projektas būtų sėkmingas, visi jo dalyviai turi žinoti, kad vadovybė visiškai palaiko šį įvykį, projektas turi didžiausią prioritetą ir jo sėkmė yra tiesiogiai susijusi su įmonės ateitimi.

Lyderystė dėl savo padėties gali turėti didelę teigiamą įtaką mąstymui apie išteklių panaudojimą projekte. Tai gali padėti jums dar prieš pradedant projektą įsitikinti, koks yra protingas išteklių planavimas. Gali reikalauti kurti papildomus scenarijus, kad būtų galima sužinoti, kas įmanoma ir kas ne.

Nesuformavus tam tikros projekto vykdymo kultūros, projekto vadovas yra bejėgis paveikti savo pažangos tikslo link. Tikslinės datos nustatomos, tada praleidžiamos - projekto tvarkaraštis tampa noru, o ne veiksmų planu. Tuo pačiu metu visi pralaimi, bet labiausiai - kompanija. Vykdytojų įsipareigojimai turėtų būti suderinti su atitinkamais vadovybės įsipareigojimais.

Vadovas negali judėti į priekį be realių koordinuotų projekto komandos veiksmų. Priklausomai nuo projekto apimties, šią sutartį galima pakeisti priskiriant darbus projekto dalyviams. Daugeliu atvejų projekto komandą sudaro darbuotojai iš visų įmonės padalinių. Jei komandos nariai neskiria pakankamai dėmesio darbui prie projekto, manydami, kad šis darbas yra mažiau svarbus nei jų kasdienės pareigos, projektas dreifuos ir nepastebimai, bet natūraliai, tai pasieks nelaimę.

Jei įsipareigojimai bus įvykdyti, projektas judės į priekį. Tačiau norint, kad viskas įvyktų laiku, būtina parengti projekto tvarkaraštį. Darbo planas yra tvarkaraštis, kuris yra realus numatomo projekto elgesio modelis. .

Projektų vadovams terminas „tvarkaraštis“ turi labai specifinę reikšmę. Jų požiūriu, projekto tvarkaraštis nėra toks, jei jame nėra išsamios visų veiklų, reikalingų projektui užbaigti, analizės; realius kiekvienai veiklai reikalingo laiko įvertinimus; ir, pagaliau, apgalvoti santykiai tarp skirtingų darbo rūšių.

Nors projektų valdymas naudoja tokius terminus kaip pradžia-pabaiga, terminologija toli gražu nėra tokia svarbi kaip turinys: kaip darbas susijęs vienas su kitu (kokia technologija).

Akivaizdu, kad laiko / išlaidų kreivės tyrimas prieš pradedant projektą leidžia įmonei priimti teisingą sprendimą patvirtinant projekto tvarkaraštį.

Kartu šie elementai suteikia atsakymą į klausimą: ką reikia padaryti ir iki kokios datos? Ne mažiau svarbus yra klausimas, kaip, kokie ištekliai - žmonės, įranga, konstrukcijos ir kt. - reikalingi kiekvienam darbui? Ar prireikus jie bus prieinami? Kaip galima išspręsti išteklių konfliktus?
Jei projekto vadovas žino faktinius plano išteklių poreikius ir kaip susidoroti su išteklių trūkumu, tada projekto planavimo dalis yra baigta.

Projekto planavimas reikalauja gebėjimo nustatyti, kiek laiko užtruks užduotis, ypač jei ji susijusi su kūrybine ar intelektualine veikla, neatsižvelgiant į tai, kiek jai reikia išteklių. Deja, klaidingi projekto trukmės skaičiavimai pirminio planavimo metu dažnai priimami pernelyg ramiai, klaidingai darant prielaidą, kad viskas bus baigta laiku, o sugaištą laiką visada galima kompensuoti perskirstant išteklius.

Kai kurių projektų tvarkaraštis grindžiamas teorija, kad norėdami pasiekti norimų rezultatų galite be galo padidinti žmonių skaičių ir sutrumpinti darbo laiką. Kai kuriose situacijose padeda padidinti išteklių kiekį. Kartais ne. Kartais tai daro daugiau žalos nei naudos.

Frederickas P. Brooksas, vyriausiasis plėtros projektų vadovas Operacinė sistema„IBM 360“ mano, kad daugeliu atvejų žmogaus mėnesio planavimas yra mitas. Jei plėtros projektas nesilaiko terminų, padidinus išteklių skaičių, projekto trukmė iš tikrųjų pailgėja - dėl papildomų darbuotojų apmokymo, jų darbo ir komunikacijos problemų stebėjimo. Pasak Brookso, tai prilygsta benzino naudojimui gaisrui gesinti.

Kai dirbate su projektu už grafiko geriausias variantas- tai projekto laiko ar masto pasikeitimas. Blogiausia yra reikalauti kompensuoti prarastą laiką. Nesunku įtikinti, kad kai kuriuos darbus galima pagreitinti nepakenkiant kokybei. Popieriuje kokybė išlieka. Realybėje reikalavimai tiesiog sumažinami.

Vadovavimo konsultacijų įmonės „McKinsey“ ataskaitoje, paskelbtoje žurnale „Fortune“, apskaičiuota, kad kai kurie projektai, užbaigti laiku, bet viršijantys biudžetą, yra 140% pelningesni nei tuo atveju, jei jie būtų biudžete, bet vėluotų šešis mėnesius.

Apibendrinant tai, kas išdėstyta pirmiau, reikėtų remtis duomenimis, gautais Šv. projekto sėkmės kriterijai :

  1. Bendras pasirengimas pokyčiams... Sėkmingose ​​organizacijose vyrauja filosofija, pagrįsta šiais principais: „gyvenk ir mokykis“, „tas, kuris nieko nedaro, neklysta“, „nėra tokios problemos, su kuria negalėtume susidoroti“.
  2. Konfliktų kultūra... Sėkminguose projektuose konfliktai sprendžiami konstruktyviai ir atvirai. Yra nemokamas keitimasis informacija ir nuomonėmis, taip pat atvirumas kritikai.
  3. Asmeninė projekto darbuotojų atsakomybė... Projektų sėkmė tiesiogiai susijusi su projekto darbuotojų asmeninės atsakomybės laipsniu ir galimybe savarankiškai organizuotis. Kuo daugiau galių turi kiekvienas asmuo, tuo greičiau jis yra pasirengęs prisiimti atsakomybę, tuo didesnė jo asmeninė iniciatyva ir motyvacija. Kita vertus, mažos galios skatina pasyvumą ir net pasipriešinimą.
  4. Pasitikėjimo kultūra... Žmoniškai maloni atvirumo, nuoširdumo ir sąžiningumo atmosfera bendraujant tarpusavyje padidina projekto sėkmės tikimybę. Esant pasitikėjimo kultūrai, klaidų daroma mažiau, o sprendimus priima visi, o vėliau jie įgyvendinami.
  5. Trūksta hierarchijos... Projektai buvo ypač sėkmingi tuomet, kai projekto darbas vyko komandoje, kur hierarchija neturėjo jokio vaidmens organizuojant projektą arba bent jau buvo sumažinta iki minimumo. Nelanksti hierarchija blokavo projekto darbuotojų kūrybiškumą ir motyvaciją nesėkminguose projektuose.
  6. Bendravimo ir informacijos kultūra. Projektai buvo ypač sėkmingi, kai komandoje karaliavo intensyvaus keitimosi informacija ir atviro bendravimo atmosfera, t.y. aukštas viešumo lygis. Geras bendravimas šiuo atžvilgiu reiškia gerą bendradarbiavimą ir atvirkščiai. Intensyvus bendravimas tarp skirtingų funkcinių sričių lemia tai, kad abipusis supratimas auga, o darbuotojai gali pažvelgti ne tik į savo sferos „lėkštę“, o tai lemia labiau pagrįstus sprendimus.

Taigi, apibendrinus projektų valdymo patirtį, paaiškėjo, kad projekto konkurencingumas turėtų būti nuolat didinamas, pasiekiant maksimalų jo vartotojo ir išlaidų charakteristikų atitikimą esamiems ir potencialiems užsakovo poreikiams. Įgyvendinimas Konkurencinis pranašumas remiasi vertės esme, kuri yra pranašumo įgijimo šaltinis (materialinės, nematerialiosios, piniginės, socialinės ir kitos vertybės), ir priklauso nuo jos turinio, kilmės šaltinio, pasireiškimo dinamiškumo, pasiskirstymo masto ir kitų sąlygų.

Kas yra sėkmingas projektas?

Birželio 8 d., Vykdant trečiąją tarptautinę projektų valdymo savaitę, kurią organizavo „Spider Ukraine Management Technologies“, vyko seminaras „Projekto sėkmė - kriterijai, valdymas, verslo kultūra“.

Į paprastą klausimą „kada projektas laikomas sėkmingu“ dažnai galima atsakyti akivaizdžiu atsakymu. Projektas yra sėkmingas, kai yra pasiekti projekto tikslai ir tuo pačiu metu jis yra baigtas laiku ir neviršijant biudžeto. Tačiau ne visada įmanoma atsakyti į paprastą klausimą. Bet kokiu atveju, daugelyje renginių, kuriuose projektų valdymo tema yra vienaip ar kitaip aptariama, kartais kyla aršių diskusijų, kas turėtų būti laikoma sėkmingu projektu. „Spider Ukraine Management Technologies“ organizuotame seminare Maskvos PMI skyriaus garbės pirmininkas generalinis vadybininkas„Spider Management Technologies“ (Maskva) Vladimiras Libersonas pristatė savo požiūrį šia tema.

Projektų tipai

Pasak V. Libersono, visų pirma būtina atsižvelgti į tai, kad projektai gali turėti skirtingus tikslus ir sėkmės kriterijus. Šiuo požiūriu visi projektai turėtų būti suskirstyti į tris tipus.

  • Verslo projektai buvo orientuoti į pelno didinimą (pavyzdžiui, projektas pagal sutartį).
  • Organizaciniai (infrastruktūros) projektai, skirti verslo procesams tobulinti ir įgyvendinami naudojant vidinius organizacijos išteklius (tai apima ir IT projektus).
  • Socialiniai ar politiniai projektai - jie nesiekia pelno.

Projektai konkuruoja tarpusavyje dėl išteklių, ir tai yra svarbus jų sėkmės vertinimo aspektas.

Projekto sėkmė yra anapus

Teisingai įvertinti projekto sėkmę nėra nereikšminga užduotis. Šiuo atveju iškyla problema, kad verslo projekto pelnas atsiranda naudojant projekto produktą, t.y. tai įvyksta už paties projekto gyvavimo ciklo ribų. Tai reiškia, kad projektas turėtų būti nukreiptas į maksimalų pelną per visą produkto gyvavimo ciklą. Tačiau pats pelno dydis vis dar mažai ką sako, turėtumėte sutelkti dėmesį ekonominis efektyvumas investicijos į produkto gyvavimo ciklą. Reikėtų nepamiršti, kad projektas yra tik vienas iš pirmųjų šio gyvenimo ciklo etapų.

Sėkmę įvertins NPV ir IRR

Jei remiamės tuo, kad projekto sėkmė vertinama pagal investicijų į produktą efektyvumą, tada tokio efektyvumo rodikliai yra žinomi. Šiems tikslams dažnai naudojama verslo metrika.

  • Grynosios nuolaidos (NPV). Jei NPV> 0, tada investicijos į projektą yra patrauklesnės nei vien pinigų laikymas banke.
  • Vidinė grąžos norma (IRR). IRR parodo, kaip efektyviai naudojami pinigai.
  • Atsipirkimo laikotarpis. Kuo toliau žvelgiame į ateitį, tuo mažiau tikslūs mūsų įverčiai ir didesnė rizika. Todėl įdomu žinoti, ar mūsų investicijos atsipirks ir kada.

Kuriam iš rodiklių bus teikiama pirmenybė, viskas priklauso nuo organizacijos politikos. Kalbant apie politinius projektus, jie nėra tiesiogiai orientuoti į pelną. Jų tikslas yra netiesioginis pelnas - pavyzdžiui, reputacijos kūrimas (būsimiems užsakymams gauti). Mes taip pat gauname netiesioginį poveikį iš organizacinių projektų. Abiem šiais atvejais V. Libersonas rekomenduoja pateikti būsimų pajamų įvertinimus (net jei ekspertų vertinimai).

Vykdyti projektą kaip verslą?

Remdamasis verslo sėkmės projekto vertinimais, pranešėjas padarė pagrįstą išvadą, kad projekto vadovas iš tikrųjų turėtų būti verslininkas ir įvertinti toli siekiančius verslo rezultatus. Tai gali gerai veikti verslo projektuose, pavyzdžiui, investiciniuose. Tačiau atrodo, kad čia reikėtų užduoti nemažai klausimų. Pirma, kas geriau: mokyti verslininką valdyti projektus ar mokyti projekto vadovą versle. Antra, kaip sujungti į vieną pareigūnas projekto vadovo funkcijos produkto gyvavimo ciklo projekto vietoje; ir proceso vadovo funkcija produkto veikimo etape. Iš esmės tai įmanoma, jei projektą vertiname aukščiausiu verslo lygiu pagal ideologiją, kaip atskiros verslo kryptys valdomos valdose. Tada reikalingas verslo projektų vadovas, kuris yra atsakingas už į projektą orientuotą verslą, jis taip pat turi sudaryti sutartis. Šiuo atveju serijoje organizacinės struktūros gali susidaryti situacija, kai klasikinis projekto komandos nario - projekto rėmėjo - vaidmuo iš esmės derinamas su projekto užsakovo - aukščiausio lygio vadovo, kuris turi subalansuoti išteklius tarp skirtingų projekto sričių, vaidmeniu. Trečia, verslo projektų vadovas netinka visais atvejais. Pavyzdžiui, gamyklose, rengiant gamybą, vykdoma daug organizacinių projektų, kurių vadovai yra įvairūs vadovai ir specialistai.

Šių projektų yra tiek daug, kad kiekvienam projektui tiesiog nepakanka gamyklos verslininkų. Ketvirta, net ir vykdant statybos verslo projektą, kurio metu buvo užsakytas pastatas parduotuvei, projekto vadovas negali būti atsakingas už tolesnį prekybos ploto veiklos efektyvumą.

Ne verslo vertinimai

Tačiau iš tikrųjų atsakymas į minėtus klausimus buvo kitoks, universalesnis, nebūtinai susietas su minėtais verslo veiklos rodikliais. Sudaromas rodiklių, kuriuos įmonė laiko tinkamais efektyvumui įvertinti, sąrašas. Kiekvienas šiame sąraše esantis projektas yra vertinamas (pavyzdžiui, naudojant 10 balų sistemą), o kiekvienas rodiklis padauginamas iš projekto svarbos įvertinimo, o gauti sąrašo taškai sumuojami. Taigi projektai bus vertinami pagal efektyvumą pagal patvirtintą rodiklių sąrašą. Jei nereikia naudoti NPV ir IRR, tai reiškia, kad verslininkas-projektų vadovas nėra būtinas, o tai reiškia, kad eilinis projekto vadovas „nesikandžioja“ į produkto gyvavimo ciklą, o „gamina“. projekto gyvavimo ciklas.

Kaip susieti komandos sėkmę su projekto sėkme

Kartu su projekto sėkmės klausimu yra ir projekto komandos sėkmės klausimas. Visiškai akivaizdu, kad projekto komanda gali būti sėkminga, tačiau pats projektas negali; galima ir priešingai. Iš tiesų komanda atitiko projekto apribojimus, tačiau paaiškėjo, kad projektas buvo nuostolingas - jo tikslai komandai buvo nustatyti neteisingai. Arba, priešingai, komanda pasiekė rezultatą vėluodama ir viršydama biudžetą, tačiau tuo pat metu, kalbant apie pelną, projektas pasirodė esąs sėkmingas. Kad projektas būtų sėkmingas, būtina sujungti projekto komandos ir projektą įgyvendinančios organizacijos interesus. Tai lemia priimti kriterijai ir motyvacijos sistema. Kriterijai turėtų būti tokie, kad valdymo sprendimų tinkamumą būtų galima įvertinti nužudymo vietose. Pavyzdžiui, ar verta išleisti pinigų, kad paspartintumėte įgyvendinimą, ar sutaupyti pinigų, bet pavėluoti - kaip tai vėl sugrįš į ateitį.

Sėkmės ir nesėkmės kriterijai

Siekdamas sujungti projekto komandos ir organizacijos interesus, V. Libersonas kaip sėkmės kriterijų pasiūlė tokį požiūrį. Ateityje tam tikru momentu nustatomas tam tikras pelno (nuostolių) lygis. Projekto sėkmę lemia nurodyto pelno lygio viršijimas (nuostolių mažinimas). Tai leis nustatyti visus dabartinius sprendimus, atsižvelgiant į tai, ar iki šio momento padidinsime, ar sumažinsime pelną. Tiesą sakant, tai reiškia, kad vienos dienos kaina nustatoma pavėluotai arba prieš projektą. Įvertinus tokį lengvai suprantamą rodiklį, sudėtingas daugiafunkcinis sprendimų priėmimo procesas labai supaprastina projekto valdymą ir padidina jo patikimumą. Šis metodas taip pat supaprastina projektų portfelio valdymą, nes leidžia įvertinti išteklių perkėlimo iš vieno projekto į kitą rezultatus. Panašiai būtina nustatyti projekto nesėkmės kriterijų. Pavyzdžiui, minimalus pelno lygis tam tikru momentu projektą paverčia ekonomiškai nepatrauklios kategorijos. Labai svarbu, kad verslo kultūra nesusietų projekto nesėkmės su komandos nesėkme. Be to, būtina, kad laiku būtų nutrauktas projektas ir papildyta įmonės žinių bazė apie nesėkmes. Vadovaujantis sėkmės ir nesėkmės kriterijais, turėtų būti kuriama ir visos komandos, ir atskiro jos nario motyvacija. Tuo pačiu metu turite sekti laiką, kurį darbuotojai skiria užduotims atlikti.

„Trys scenarijai“ prieš projekto riziką

Iš pradžių bet kokie planuojant projektus naudojami įvertinimai turėtų apimti galimų verčių diapazonus. Tačiau, kad ir kokie geri būtų vertinimo kriterijai, reikia turėti omenyje, kad juose visada yra neapibrėžtumo elementas. Dėl įvykių ir sąlygų neapibrėžtumo kyla projekto rizika. Todėl projektų valdymui reikalingas rizikos valdymas, o PMBoK vadove (PMI projekto valdymo žinių bazė) buvo įvesta speciali dalis apie rizikos valdymo procesus. V. Libersonas pateikė savo šio skyriaus interpretacijos versiją. Apskritai tai sutampa su tuo, kas pateikiama klasikiniuose visos įmonės rizikos valdymo kursuose. Galų gale, daugelio jų pobūdis yra tas pats projektų valdymo, finansų, IT ir gamybos srityse. Kalbant apie rizikos modeliavimo metodą, pranešėjas siūlo pakeisti Monte Karlo metodą, gražų teoriškai ir prastai įgyvendintą praktikoje, „trijų scenarijų“ (optimistinio, labiausiai tikėtino, pesimistinio) metodu, o riziką vertinti ne tikimybėmis. sėkmės, bet pagal jų tendencijas. Trys scenarijai naudojami ištekliams ir kritiniams keliams įvertinti. Šiuo atveju kritinis grafikas sudaromas atsižvelgiant į draudimo rezervus (buferius). Pokalbio su šių eilučių autoriumi metu V. Libersonas išreiškė mintį, kad visas projektų valdymas galiausiai priklauso nuo šių rezervų valdymo. Todėl „taikiu būdu“ įvairaus lygio „atsakomybės“ rezervų sąskaita būtina numatyti penkis (!) Biudžetus - atlikėjo, komandos, vadovybės, sutarties ir sutarties nutraukimo taško. sutartis.
Kompiuterinis modeliavimas yra raktas į sėkmę

V. Libersonas savo požiūrį į projekto sėkmę patvirtino pateiktais pavyzdžiais kompiuterio programa projektų valdymas „Spider Project“. Jis parodė, kaip apibrėžti sėkmės kriterijus, taip pat jų vaidmenį ir vietą oficialiame projekto modelyje. Tas pats pasakytina apie riziką. O kai programa sukėlė tendencijas, paaiškėjo, kad formaliai teisingi veiksmai lėmė nuostolius, o veiksmai, skirti padidinti išlaidas ir praleistus terminus, atnešė pelno. Be programinės įrangos, skirtos projektų modeliavimui, visiškai neįmanoma pamatyti povandeninės projekto rizikos ledkalnio dalies. Pasak pranešėjo, jokia programa, išskyrus projektą „Voras“, neturi draudimo rezervų ir rizikos valdymo mechanizmo.

Tai, kas buvo pristatyta seminare, buvo labai aktualu, nes seminaro metu klausytojai uždavė daug klausimų (klausė patarimo) - „pagal skaudžius“ iš savo praktikos. „Aprašymas“ apie realias klausytojų situacijas pridėjo daug specifikos. Tai leido atvykusiems į seminarą kartu su gilia teorine medžiaga gauti ir praktiniai patarimai kaip padaryti projektą sėkmingą.

-Borisas Ždanovas, žurnalo „Įmonių sistemos“ vyriausiasis redaktorius

Projekto sėkmės kriterijai- rodiklių rinkinys, leidžiantis įvertinti projekto sėkmės laipsnį.

Projektų valdymo sėkmės kriterijai- projektų valdymo efektyvumo rodikliai.

Projekto sėkmė, paprastai tai reiškia, kad visos suinteresuotosios šalys gauna jų lūkesčius atitinkančius rezultatus, tradiciškai suformuluotus tikslų ir reikalavimų forma. Jei tokie tikslai ir reikalavimai suformuluoti, projekto sėkmės kriterijai gali būti kiekybiniai rodikliai, atspindintys projekto tikslų pasiekimo laipsnį ar tam tikrų reikalavimų įvykdymą.

Aiškus ir nedviprasmiškas šių kriterijų apibrėžimas yra privaloma užduotis pradiniame projekto etape. Projekto vadovas su visais projekto dalyviais turėtų nustatyti sėkmės rodiklius ir susitarti dėl jų.

Bendras projekto sėkmės kriterijus yra projekto tikslų pasiekimas numatytu laiku ir neviršijant numatytų išteklių.

Pagrindinis kriterijų reikalavimas yra nedviprasmiškas ir aiškus jų apibrėžimas. Kiekvienam projektui ir kiekvienam užsakovui turi būti apibrėžti, įvertinti ir išanalizuoti sėkmės kriterijai.

Tai, kad nepasiekiami projekto pradžioje nustatyti tikslai, ne visada reiškia, kad projektas žlugs. Tačiau jei projekto metu šalių nuomonė apie projekto tikslus ir uždavinius pasikeičia, šie pokyčiai turėtų atsispindėti atitinkamuose sėkmės kriterijuose.

Projektų valdymo sėkmė yra susijusi su projekto sėkme, tačiau jie nėra tas pats. Galima sėkmingai valdyti projektą, kuris vėliau bus nutrauktas praradus aktualumą, pavyzdžiui, pasikeitus įmonės strategijai. Jei projekto sėkmė paprastai siejama su tikėtino verslo rezultato pasiekimu, tai projekto valdymo sėkmė dažniausiai siejama su tokiais kriterijais, kaip projekto terminų ir išlaidų laikymasis, pristatymo laiku, komunikacijos kokybė, atsakas laikas atsirasti kylančioms rizikoms ir problemoms ir pan.

Jei dėl vykstančių pokyčių projektas praranda savo aktualumą, būtina apsvarstyti galimybes keisti koncepciją arba priimti sprendimą uždaryti šį projektą.

Apibrėžimas sėkmės kriterijus projektas yra rezultato aktualumą jo pasiekimo metu.

Pačioje projekto pradžioje labai patartina išanalizuoti galimų projekto nesėkmių priežastis (galimas rizikos sritis).

Pagrindinės projekto nesėkmės priežastys gali būti:

Neaiškūs tikslai;

Nepakankamas finansavimas;

Keisti verslo prioritetus;

Aukščiausios vadovybės paramos trūkumas;

Neveiksminga komanda (projekto personalo kvalifikacija);

Nepakankamai efektyvi sąveika projekte;

Savivaldos trūkumas;

Nepakankamai efektyvus bendravimas;

Motyvacijos stoka (reiškia vidinę riziką);

Būtina išbandyti projektą dėl „galimų nesėkmių priežasčių“: ar projekto tikslai yra pakankamai aiškūs? Kiek patikimi investuotojai? Ar projekto komanda yra kvalifikuota? Ar jos motyvacijos pakanka?

Sėkmės ir nesėkmės kriterijai yra tarpusavyje susiję. Tačiau laikui bėgant jie gali keistis, ypač keičiantis situacijai rinkoje.

Tęsinys ...

Šiandien noriu trumpai papasakoti apie projektų ir projektų vadovų sėkmės kriterijus.

Bet pirmiausia turite atsakyti į klausimą „kas yra projektas“ :)

Kas yra projektas

Tai pirmas klausimas, į kurį turi atsakyti bet kuris vadovas.

Ne akivaizdu, bet projektų valdymas sunkesnis nei „įprastas“, vadinamasis „reguliarus valdymas“. Skyriaus ar pavaldinių valdymas yra vienas dalykas. Projektų valdymas yra visiškai kitas dalykas.

Dauguma projektų valdymo metodikų yra didelės apimties. Pavyzdžiui, naujausias „vadovų biblijos“ PMBoK leidimas yra beveik 1000 puslapių, „Prince2“, IPMA ir kitų vadovai (apie juos - kitą kartą) taip pat nemaži.

Lyderio gyvenime svarbu išmokti greitai suprasti „projektas yra prieš jus ar ne“, kad nebūtų eikvojama energija (ir bandymai ištraukti 1 000 puslapių metodiką, kurioje galite apsieiti su trupučiu kraujo ).

Vienas iš pirmųjų atradimų yra tas, kad pati aukščiausioji vadovybė, kaip taisyklė, gerai nesupranta, kur yra projektai, o kur ne. Tie. Nereikia tikėtis, kad jums kažkas buvo patikėta, pavadinta projektu ir jau gerai pagalvojote. Praktiškai projektai vadinami bet kuo, tai jūs (projekto vadovas) turite patikrinti, kas buvo pasakyta, ar jie yra tinkami.

Mums reikia apibrėžimo, kuris padėtų suskirstyti paskirtas užduotis į tas, kurių reikia projekto požiūris ir tuos, kuriuos (laimei) galima išspręsti lengviau, pritaikius daugumai žmonių labiau pažįstamą „įprastą valdymą“.

Termino apibrėžimas

Prisiminkime arba „Google“ daugiau ar mažiau klasikinį apibrėžimą. Mes susiduriame su kažkuo panašiu: „Projektas yra įvykis, skirtas tikslui pasiekti, riboti ištekliai laike ir susijęs su unikalaus rezultato pasiekimu“.

Tokia formuluotė yra įprasta. Įskaitant patį PMBoK. Problema: jiems gaila. Iš jų neaišku pagrindinis dalykas - kuo projektas skiriasi nuo „ne projekto“.

Netikite manimi? Pabandykite rasti bent vieną bet kokios veiklos pavyzdį, kuris neatitinka šio apibrėžimo?

Aiškinantis pavyzdžiu

Eini į darbą arba ryte pasigamini kiaušinienę.

Ar ši veikla skirta tikslui pasiekti? Žinoma, tikslas yra gana konkretus (atvykite į paskirties vietą, gaukite pakankamai).

Laikas ribotas? Neabejotinai! Negalite pusryčiauti pusę dienos ar praleisti dieną kelyje.

Ar ištekliai riboti? Vėlgi, taip. Turite suprantamą sumą, kurią galite ir neprieštaraujate išleisti kelyje. Arba kiaušinienės atveju šaldytuve - vos keliolika kiaušinių. Jei juos sunaudosite, liksite be pusryčių.

Ar tokį darbą reikėtų vadinti projektu? Žinoma ne! Kas yra 1000 puslapių kiaušinių kepimo metodikos. Galite susidoroti su viena intuicija ir sveiku protu.

Jei keptus kiaušinius gamintumėte ne vienas, o su šeima, perduodami vienas kitam keptuvę, tada pusryčių gaminimas vis tiek nevirstų projektu, vis tiek pakaktų intuicijos.

Apie trenerių patosą

Daugelis projektų valdymo trenerių mėgsta patosą ir yra linkę perdėti. Kartais jie sako: „Viskas pasaulyje yra projektas“. Arba „projektų valdymas yra labai senas įgūdis, pirmieji projektai yra tūkstančių metų senumo - čia, Egipto piramidės ...“.

Drįstu teigti - senovės egiptiečiai pastatė Egipto piramidę ne tik kaip projektas, kaip ir kiaušinienės paruošimas. Aplink mus (laimei) yra daug mažiau projektų, nei atrodo. Ir įprasta, šiuolaikine to žodžio prasme, visavertis projektų valdymas susiformavo maždaug prieš 50–70 metų (vargu ar daugiau).

Tačiau grįžkime prie kiaušinienės.

Dabar įsivaizduokite, kad jūsų laukia sunkesnė užduotis. Pasigaminkite sau (ar savo šeimai) daugiau nei tik kiaušinienę. Artėja koks nors įvykis (vaiko gimtadienis). Norite padaryti staigmeną - imkitės stručio kiaušinienės.

Įkainiai kyla į viršų. Vis dar yra laiko apribojimų (pavyzdžiui, netrukus bus gimtadienis). Yra tik vienas kiaušinis, jį nusipirkote iš stručių ūkio. Jūs labai mažai žinote apie stručius ir nesate tikri, ar sugebėsite juos tinkamai iškepti. Net neaišku, ar tilps į įprastą keptuvę ir ar apvalkalas teisingai sulūš. Jūs tikrai nenorite suklysti ir sugadinti savo vaiko staigmenos.

Ir tokioje situacijoje jūsų veikla vis labiau ima panašėti į projektą. Jūs pradedate planuoti atidžiau (palyginti su įprastais pusryčiais) - naršote internete, išsiaiškinate, „kaip kepti“, „kaip sulaužyti“, pasirenkate specialią keptuvę (ar net nusipirkote tinkamą parduotuvėje, apskaičiuokite laiką) Nebūtinai visi 1000 PMBoK puslapių bus naudojami šiam požiūriui, tačiau yra daug elementų, kurių net nepagalvotumėte naudoti įprastiems pusryčiams ar kelionei į biurą.

Kas pasikeitė

Leiskite pasiūlyti savo apibrėžimą.

Projektą vadinsime užduotimi, kuri yra būdinga tuo pačiu metu:

  • galūnė,
  • didelis neapibrėžtumas.

Baigtumas yra „rėmas“, terminų ir išteklių apribojimas.

Didelis neapibrėžtumas reiškia, kad nėra aišku, kaip išspręsti užduotį. Tik tada, kai įvykdomos abi sąlygos - taikykite projektų valdymą.

Pagalvokite apie pagrindines pramonės šakas ir pramonės šakas, kuriose vyrauja projektų valdymas: pavyzdžiui, IT ar taikomąjį mokslą. Kai pradedamas kūrimo ir įgyvendinimo projektas programinės įrangos produktas arba į rinką išleisti naują vaistą. narkotikų - jie paprastai turi rėmelį. Įmonė turi tam tikrą biudžetą ir gali sau leisti tam tikrą laiką investuoti į plėtrą. Bet tada pinigai turi grįžti. Tuo pačiu metu užduotis, kurią turi išspręsti programinės įrangos inžinieriai, technologai ir mokslininkai, dažnai neturi suprantamo algoritmo, ji yra prastai nuspėjama ir gali veikti daug rizikos (turime iš dalies priimti principą „įsitraukti į mūšį, pamatysime ten “).

Būtent šioje situacijoje požiūris iš įprasto valdymo darbo yra labai menkas. Kai tuo pat metu yra ir labai standžių rėmų (baigtinumas), ir didelis neapibrėžtumas.

Štai kodėl (mano nuomone) statyba Egipto piramidės Senovės egiptiečiai - ne projektas. Trūksta bent vieno iš parametrų. Ir tai yra baigtinumas.


Egipto piramidžių statyba nėra projektas

Piramidės statyba prasidėjo, kai gimė faraonas. Jis turėjo būti baigtas iki jo mirties. Jei kūdikystėje nebuvo mirties, greičiausiai statybos truko mažiausiai 20–30 metų. Išteklių (žmonių, medžiagų) taip pat netrūko. Nuomonės skiriasi - ar piramidę statė vergai, ar laisvi samdiniai, bet, bet kuriuo atveju, veikė principas - „ar kažkas nutiko? Priimkime daugiau žmonių “. Jei turite neribotą laiką ir (arba) biudžetą, anksčiau ar vėliau susidorosite su bet kokia užduotimi. Net ir su labai sudėtingu. Ir tau labai nesuprantama. Nuo penkto, dešimto ar dvidešimto karto po didžiulių išlaidų jums pasiseks.

Egipto piramidžių pavyzdys šiuolaikinis pasaulis- kažkokia valstybė projektus. Arba kai kurių produktų įmonių darbas (dažniau IT srityje). Kai įmonė pagamino tam tikrą IT produktą, o po to daugelį metų jį tobulina, tobulina, parduoda vis daugiau naujų klientų, plečia paslaugų skaičių. Kol tokia įmonė nepasiekia naujo išsivystymo lygio, tačiau ji jau yra labai turtinga - jai nereikia projektų valdymo (įsivaizduokite „Google“ ar „Facebook“). Dabar tai milžiniškos korporacijos, užsiimančios įvairiais projektais - nuo automobilių ir palydovų kūrimo iki medicinos ir finansų kūrimo. Bet kai jie turėjo 1 labai sėkmingą produktą (paieškos variklį arba Socialinis tinklas), o jų kūrimą galėtų nustatyti kaip vienintelę užduotį (kuriai jie galėtų išleisti bent neribotą pinigų sumą). Tokiai „Google“ ir tokiai „Facebook“ nereikėtų projektų valdymo.

Operatyvinė veikla yra kas

Kartais minima vadinamoji „operatyvinė veikla“. Tai akivaizdžiausias pavyzdys, kurį galima įsivaizduoti, kai projektų valdymas visai nereikalingas.

Operacinei veiklai būdingas abiejų principų pažeidimas: (begalybė) ir (neapibrėžtumas).

Pavyzdys - automobilių surinkimo gamyklos darbas. Gamykla, kurioje veikia konvejeris. Ja važiuoja automobiliai. Kažkas užsiima kėbulo dažymu, ratų, žibintų, sėdynių ir pan. Ši veikla sąlyginai yra begalinė (ji kartosis kiekvieną dieną, kol gamykla bus uždaryta arba šios markės mašinų gamyba bus apribota). Tai labai nuspėjama (gerai žinoma, kiek automobilių galima pagaminti per pamainą, koks bus „išmetimas“ dienos, savaitės, mėnesio, metų pabaigoje). Projektų valdymo principų taikymas tokiomis sąlygomis neduos jokios naudos (viską tik apsunkins ir sujauks).

Kitas operatyvinės veiklos pavyzdys yra darbas Techninė pagalba IT srityje. Skambučių centras ar svetainė priima paraiškas, jos paskirstomos pagal tam tikrą algoritmą tarp darbuotojų, kurie arba pateikia vartotojui žodines rekomendacijas, arba pašalina nedidelius defektus. Toks darbas primena surinkimo liniją: mažos, dažniausiai to paties tipo įvesties užklausos, nuspėjamas jų apdorojimo algoritmas. Bent jau tol, kol kalbama apie didelio masto sistemos restruktūrizavimą. Tokiomis sąlygomis projektų valdymas taip pat nenaudingas.

Tačiau kai susiduriate su užduotimi, kuri yra labai neapibrėžta ir baigtinė (apimtis), projektų valdymas yra geriausias (su keliomis išlygomis) būdas ją išspręsti šiandien.

Projekto sėkmės kriterijai

Kalbant apie projekto apibrėžimą, svarbu paminėti sėkmės kriterijus. Kas yra „sėkmingas vadovas“? Kas yra „sėkmingas projektas“? O kas laikoma nesėkme?

Atsakymą jau seniai sukūrė metodininkai.

Sėkmingas projektas yra tas, kuris atitiko iš anksto nustatytą terminą, išlaidas (ir kitus išteklius), suteikė klientui tai, ko jis paprašė, ir tuo pat metu yra patenkinti pagrindiniai suinteresuotieji subjektai.

Tai skamba sudėtingai, bet lengvai perteikiama vienoje nuotraukoje. Įsivaizduokite trikampį (jie jau kurį laiką nustojo piešti jį PMBoK, bet esmė niekur nedingo). Trikampis turi tris kraštines = terminai, pinigai, turinys. Centre yra besišypsanti šypsenėlė. Viskas.

Tai yra jūsų sėkmingo projekto kriterijai.

„Edge“ - tai, su kuo susitariama su klientu prieš pradedant projektą. Paprastai - tokie susitarimai paprastai yra aukšto lygio, tačiau jie taip pat neliečiami. Ar pažadėjote per 12 mėnesių pastatyti 9 aukštų mūrinį namą ir turėsite 1 mln. Daryk!

Koks bus šis namas, kaip atrodys balkonai, kokios įmonės liftus jame įrengti - antras klausimas. Dėl to dar reikia susitarti, galbūt projekto metu. Tačiau preliminarūs susitarimai - nedelsiant. Prieš projekto pradžią. Paprastai jie įrašomi į hiperlakonišką dokumentą, vadinamą „projekto chartija“ (apie tai kitą kartą).

Taigi, prieš pradėdami dirbti, turite apibrėžti tris projekto aspektus. Sąvokos („baigsime ne vėliau kaip“), pinigai („projekto biudžetas ne didesnis kaip ...“) ir turinys 2-3 sakiniais („ką mes darome ir ko nedarome“). Šiuos veidus simbolizuoja paveikslėlyje esantis trikampis.

Jie turi būti pasiekti, kad būtų patenkinti pagrindiniai (ne visi, bet pagrindiniai) projekto suinteresuotieji subjektai (pagrindiniai vartotojai ir kliento atstovai, jūsų vadovybė, pagrindiniai reguliuotojai ir kai kurie kiti). Šį pasitenkinimą simbolizuoja šypsenėlės veidas trikampio viduje.

Kaip tapti geru vadybininku

Geras projektų vadovas skiriasi nuo blogo projektų vadovo tuo, kad baigdamas jis patenka į trikampį ir džiugina pagrindinius suinteresuotuosius subjektus.

Apskritai visos metodikos yra orientuotos į tai, kaip projekto pradžioje pakankamai tiksliai suformuoti trikampį ir ką daryti pakeliui, kai atsiranda nukrypimų (praleisti įvertinimai, atsirado naujų reikalavimų, pasikeitė klientų atstovas ir pan.).

Vadovui nesiseka, jei jis nežino, kaip išlaikyti projektą trikampyje (dėl ko jis pats sutiko pradžioje). Arba, jei jo projektai bus baigti „pagal biudžetą ir laiku bei griežtai laikantis techninių specifikacijų“, tačiau klientas lieka labai nepatenkintas ir nusivylęs (šypsenėlės veidas trikampyje nuleistais lūpų kampais). Kitas nesėkmės pavyzdys: projektas baigtas iš pradžių paskirto trikampio ribose, klientas yra patenkintas, tačiau komanda persistengė - jame esantys žmonės yra demotyvuoti, daugelis, gavę projekto premiją, padavė atsistatydinimo laišką. Įmonės vidinė reputacija sugadinta, sunku ir brangu ieškoti naujų specialistų darbo rinkoje. Tokiu atveju aukščiausioji įmonės vadovybė greičiausiai bus nepatenkinta. Ir tai taip pat yra pagrindinės suinteresuotosios šalys (juk projektas buvo atliktas iš jų pinigų - jie buvo tie, kurie mokėjo jūsų atlyginimą kaip vadovas ir visi darbuotojai).

Projekto valdymas yra pusiausvyros veiksmas: kaip apibrėžti trikampį (laiko ir pinigų turinys) ir jo neprarasti, ir pasiekti pagrindinių projekto suinteresuotųjų šalių pasitenkinimą. Tai yra pagrindinis dalykas, kurį reikia atsiminti apie projekto sėkmės kriterijus.

Straipsnis parašytas remiantis projekto valdymo mokymo kursu.

Kaip minėta aukščiau, kiekvienas projektas turėtų turėti iš anksto nustatytus tikslus.

Projekto tikslai yra svarbiausias projekto valdymo elementas, nuo kurio galiausiai priklauso projekto sėkmė.

Pateiksime tokį pavyzdį. Didelė įmonė pradeda diegti informacijos valdymo sistemą, skirtą sąveikai su sandorio šalimis. Įmonės vadovybė projekto komandai ir būsimam rangovui pareiškia atlikti darbus, tikslus:

· Didinti sąveikos su rangovais efektyvumą;

· Didinti įmonės klientų ratą;

· Padidinti teigiamų vartotojų atsiliepimų skaičių ir sumažinti skundų skaičių.

Projekto komanda įgyvendina projektą neviršydama biudžeto, tačiau vėluoja du mėnesius. Pasibaigus projektui vartotojai nesinaudoja informacine sistema, įmonės vadovybė pripažįsta projektą nesėkmingu ir atleidžia projekto vadovą. Reikėtų pažymėti, kad daugeliu atžvilgių šios nesėkmės priežastis yra neteisingas projekto tikslų nustatymas.

Pirma, tikslai nėra konkretūs. Klientų bazę galima padidinti 20 sandorio šalių, o tai, žinoma, yra labai maža, tačiau, nepaisant to, užtikrina užsibrėžto tikslo „Padidinti įmonės klientų bazę“ įvykdymą. Panaši situacija ir su vartotojų atsiliepimų skaičiumi. Be to, šių tikslų pasiekimą galima įvertinti tik tada, kai informacinės sistemos vartotojai pradeda joje dirbti ir po tam tikro laiko įveda atitinkamus duomenis.

Antra, kaip paaiškėjo iki projekto pabaigos, pagrindinis tikslas, į kurį projekto komanda neatsižvelgė, buvo projekto užbaigimas iki gruodžio 31 d., Nes iki tos dienos įmonės vadovybė turėjo pranešti valdybai tikslo įgyvendinimą. Kadangi pranešti apie rezultatus buvo neįmanoma, vadovų veikla apskritai buvo pripažinta nesėkminga.

Trečia, projekto tikslais ir atliekant darbus nebuvo atsižvelgta į įmonės darbuotojų - galutinių informacinės sistemos vartotojų - interesus ir norus, dėl to buvo pradėtas naudoti sistemos sabotažas.



Taigi neatsargus tikslų nustatymas dažnai lemia projekto nesėkmę.

Projekto tikslai turi atitikti SMART reikalavimus (specifinis - specializuotas, matuojamas - matuojamas, aktyviai įtakojamas - aktualus, realistiškas - realistiškas, ribotas laikas - ribotas laikas).

Pateiktame pavyzdyje reikėjo apibrėžti tikslus:

Pasibaigus projektui, 90% darbuotojų naudojasi informacinė sistema;

· Sistemoje yra naujausių duomenų;

· Per šešis mėnesius nuo sistemos naudojimo padidinti įmonės klientų bazę 20%;

· Padidinti teigiamų klientų atsiliepimų skaičių 10% ir sumažinti skundų skaičių 10% per šešis sistemos naudojimo mėnesius.

Šie tikslai atitinka SMART ir leidžia projekto komandai bei įmonės vadovybei objektyviai sekti projekto sėkmės metriką.

Siekiant įvertinti projekto tikslų įgyvendinimą, pristatomi projekto sėkmės kriterijai. Projektas sėkmingas, jei:

· Atlikta laiku;

· Neviršijant numatyto biudžeto;

· Patenkinus klientus.

Projekto gyvavimo ciklas

Kiekvienas projektas, neatsižvelgiant į jo sudėtingumą ir jo įgyvendinimui reikalingų darbų kiekį, vystydamasis eina per tam tikras būsenas: nuo būsenos, kai „projekto dar nėra“, iki būsenos, kai „projekto nebėra“.

Projekto pradžia siejama su jo įgyvendinimo pradžia ir investicijų pradžia Pinigai ją vykdant.

Projekto pabaiga gali būti:

· Objektų, projekto rezultatų paleidimas, jų eksploatavimo pradžia ir projekto rezultatų panaudojimas;

· Projektą vykdančio personalo perkėlimas į kitą darbą;

· Nurodytų projekto rezultatų pasiekimas;

· Projekto finansavimo nutraukimas;

· Pradėti įgyvendinti esminius projekto pakeitimus, kurie nebuvo numatyti pradinėje koncepcijoje (modernizavimas);

· Objektų, projekto rezultatų pašalinimas iš veiklos.

Paprastai tiek darbo prie projekto pradžios faktas, tiek jo likvidavimo faktas įforminami oficialiuose dokumentuose.

Būsenos, per kurias praeina projektas, vadinamos etapais (etapais, etapais).

Nėra universalaus požiūrio į projekto įgyvendinimo procesą suskirstyti į etapus. Spręsdami tokią užduotį patys, projekto dalyviai turėtų vadovautis savo vaidmeniu projekte, savo patirtimi ir konkrečiomis projekto sąlygomis. Todėl praktiškai projekto skirstymas į etapus gali būti labai įvairus - svarbiausia, kad toks padalijimas atskleistų keletą svarbių kontrolės taškų („etapų“), kurių eigoje galima pamatyti Papildoma informacija ir įvertinamos galimos projekto plėtros kryptys.

Kiekvienas etapas turi baigtis išmatuojamu, patikrinamu rezultatu. Kiekvieno etapo pabaigoje priimamas sprendimas pradėti naują etapą arba uždaryti (išsaugoti) projektą.

Savo ruožtu kiekvieną pasirinktą fazę (etapą) galima suskirstyti į kito lygio fazes (etapus) (pakopas, pakopas) ir kt.

Projekto gyvavimo ciklo pavyzdys parodytas fig. 1.3.

Atspindėta:

· Projekto etapai;

· Gairės kiekvieno etapo pradžioje ir pabaigoje;

· Kiekvieno etapo rezultatai.

Daugelio etapų nustatymas dideliuose projektuose yra susijęs ne tik su ilga šių objektų statybos trukme (10-15 metų), bet ir su poreikiu nuodugniau koordinuoti projekte dalyvaujančių organizacijų veiksmus.

Apsvarstykite projekto savybių pasikeitimą per visą gyvavimo ciklą.

Projekto metu tai didėja ir smarkiai mažėja, kai pav. 1.4
):

· Išlaidų lygis;

· Personalo darbo krūvio lygis.

Kas didėja projekto eigoje (1.5 pav.)
):

· Sėkmingo projekto užbaigimo tikimybė;

· Pakeitimų kaina;

· Klaidų taisymo kaina.

Kas mažėja projekto metu (1.6 pav.)
):

· Projekto neapibrėžtumas / rizika;

· Dalyvių gebėjimas daryti įtaką galutinėms projekto produkto savybėms;

· Dalyvių gebėjimas daryti įtaką projekto produkto kainai.

Yra ryšys tarp projekto gyvavimo ciklo ir produkto gyvavimo ciklo.

Produkto gyvavimo ciklą sudaro etapai, kurie stebimi atsižvelgiant į įmonės gamybos ir kontrolės poreikius. Iš esmės projekto gyvavimo ciklą sudaro vienas ar keli produkto gyvavimo ciklai.

Jei projekto rezultatas yra susijęs su produktu, tarp jų gali būti įvairių rūšių santykių gyvenimo ciklai... Pavyzdžiui, naujo produkto kūrimas pats gali būti projektas. Arba galite pateikti pavyzdį, kai įgyvendinamas projektas, skirtas pagerinti esamo produkto našumą.