Projektų valdymo raidos istorija. Informacinių technologijų valdymas

Visuotinai pripažįstama, kad projektų valdymas yra labai jaunas mokslas, tačiau iš tikrųjų pagrindinės jo sąvokos buvo suformuluotos dar XIX amžiaus pabaigoje. Šioje paskaitoje sužinosite, kokią įtaką šiuolaikinei vadybos teorijai darė šimtmečio mokslinės idėjos, socialinė praktika ir verslo požiūriai.

Projektavimo technologijų panaudojimo galima rasti net senovėje. Bet kuris iš septynių pasaulio stebuklų tam tikra prasme gali būti laikomas užbaigtu socialiniu projektu. Tačiau vis dėlto mąstymas projektais, sąmoningas ir plačiai paplitęs projektinio požiūrio taikymas technologijose, versle, galiausiai – socialinėje sferoje – paskutinio XX amžiaus trečdalio reiškinys. Tačiau jau praėjusio šimtmečio pradžioje įvyko dizaino raidos sprogimas, ypač galingas inžinerijos srityje.

Daiktų, mašinų ir ryšių projektavimas buvo atliktas remiantis projektavimo technologija. 20-aisiais projekto idėja tiesiog sklandė ore, užfiksuojant įvairias veiklos sritis. Pavyzdžiui, viena iš madingų to meto pedagogikos krypčių buvo projektinio metodo naudojimas, kurio kūrimas, remiantis amerikiečių filosofo, pedagogo ir psichologo Johno Dewey teorinėmis idėjomis, priklausė Williamui Hurdui Kilpatrickui ir kitiems eksperimentuotojams. švietimo srityje.

Projektų valdymas šiuolaikine forma pradėjo atsirasti tik prieš kelis dešimtmečius. Nuo septintojo dešimtmečio pradžios. įmonės ir įstaigos pradėjo suvokti veiklos organizavimo projektų pagrindu naudą. Šis į projektus orientuotas požiūris išsivystė, kai darbuotojai pripažino esminį bendravimo ir bendradarbiavimo poreikį, kuris sujungia skirtingų skyrių, profesijų ir, kai kuriais atvejais, ištisų pramonės šakų žmonių darbą.

Šiandien projektų valdymo pagrindus galima pavaizduoti naudojant projekto trikampį – simbolį, kurį išpopuliarino Haroldas Kerzneris savo reikšmingame darbe Projektų valdymas: sisteminis planavimo, planavimo ir kontrolės metodas.

Norėdami atsekti, kaip projektų valdymas išsivystė nuo pagrindinių valdymo principų, grįžtame į istoriją iki XIX amžiaus pabaigos – laikotarpio, kuriam būdingas vis sudėtingesnis verslo pasaulis. Impulsas priimti svarbius sprendimus, tapęs projektų valdymo metodikos pagrindu, buvo didelės apimties valdžios projektai. JAV pirmasis tikrai didelis vyriausybės projektas buvo transkontinentinio geležinkelio statyba, pradėta 1860 m. Netikėtai vadovams teko didžiulė užduotis – organizuoti tūkstančių darbuotojų fizinį darbą, taip pat apdoroti precedento neturinčius didelius kiekius. žaliavų.

XIX amžiaus pabaigoje Frederickas Tayloras (1856–1915) pradėjo išsamius darbo tyrinėjimus. Jis taikė mokslinius samprotavimus, įrodydamas, kad darbą galima analizuoti ir tobulinti išskiriant elementarias jo sudedamąsias dalis. Jis pritaikė savo idėjas sprendžiant problemas, susijusias su plieno gamyklomis, pavyzdžiui, pilant smėlį ir kėlimo bei judančių dalių problemas. Prieš tai buvo manoma, kad vienintelis būdas padidinti našumą – priversti darbuotojus dirbti sunkiau ir ilgiau. Priešingai šiai idėjai, Taylor pristatė efektyvaus darbo koncepciją. Įrašas ant Taylor antkapinio paminklo Filadelfijoje liudija jo indėlio į vadybos istoriją svarbą: „Mokslinės vadybos tėvas“.

Tayloro mokinys Henry Ganttas (1861–1919) labai išsamiai ištyrė operacijų seką. Jo vadybos tyrimai buvo skirti laivų statybai Pirmojo pasaulinio karo metais. Ganto diagramos, įskaitant užduočių juostas ir etapų žymeklius, rodo visų proceso užduočių seką ir trukmę. Ganto diagramos pasirodė esąs toks naudingas analizės įrankis vadovams, kad beveik šimtmetį išliko beveik nepakitusios. Tik 1990-ųjų pradžioje. „Microsoft Office Project“ pirmą kartą į užduočių segmentus buvo įtrauktos santykių eilutės, kurios atspindi tikslesnes užduočių priklausomybes.

Laikui bėgant šios eilutės pradėjo rodyti dar daugiau duomenų „Microsoft Office Project“. Taigi, pažangos rodikliai atsirado, palyginti su bazine verte, nuokrypiais ir linijomis, atspindinčiais užduoties būklę tam tikru momentu.

Henrio Ganto pasiekimams atminti Amerikos mechanikos inžinierių draugija įsteigė jo vardo medalį.

Taylor, Gantt ir kitų darbas projektų valdymą pavertė atskira verslo funkcija, kuriai reikia studijų ir disciplinos. Prieškario metais rinkodaros požiūriai, industrinės psichologijos principai ir žmonių santykiai ėmė tapti neatsiejama projektų valdymo dalimi.

Antrojo pasaulinio karo metais dėl vyriausybės ir karinių projektų sudėtingumo bei darbo išteklių mažinimo atsirado poreikis kurti naujas organizacines struktūras. Sukurtos sudėtingos tinklo diagramos, vadinamos PERT diagramomis, ir kritinio kelio metodas, kad vadovai galėtų geriau kontroliuoti labai sudėtingus, daug inžinerijos reikalaujančius projektus (pvz., kovines sistemas, kurioms reikia daugybės užduočių ir kelių veiklų skirtingu laiku).

Šie metodai netrukus buvo pradėti taikyti visose pramonės šakose, nes vadovai ieškojo naujų strategijų ir kontrolės priemonių, kad galėtų susidoroti su augimu sparčiai besivystančiame, aršios konkurencijos pasaulyje. 1960-ųjų pradžioje. Įmonės verslo operacijoms pradėjo taikyti bendrųjų sistemų teorijų principus. Richardas Johnsonas, Fremontas Kastas ir Jamesas Rosenzweigas savo knygoje „Sistemų teorija ir valdymas“ pristatė šiuolaikinę įmonę žmogaus kūno pavidalu – su skeletu, raumenimis, kraujotakos ir nervų sistemomis ir kt.

Šiandien požiūris į įmones kaip į žmogaus organizmus rodo, kad tam, kad įmonė išliktų ir klestėtų, visos jos funkcinės dalys turi veikti darniai, kad būtų pasiekti tam tikri tikslai, tai yra projektai. Po 1960 m šis požiūris į projektų valdymą pradėjo įgauti modernias formas. Nors per šį laikotarpį buvo sukurti skirtingi verslo modeliai, jie visi turėjo bendrą struktūrą: projekto vadovas vadovauja projektui, formuoja darbo komandą, užtikrina integraciją ir bendradarbiavimą darbo procese horizontaliai tarp skirtingų padalinių.

Per pastaruosius dešimt metų projektų valdymas toliau tobulėjo. Išryškėjo dvi reikšmingos tendencijos.

· Planavimas iš apačios į viršų. Ši tendencija pabrėžia paprastą projekto struktūrą, trumpesnius projektų ciklus, efektyvų komandos bendradarbiavimą ir gilesnį komandos narių įsitraukimą bei sprendimų priėmimą. Ši tendencija populiariai žinoma kaip judrus projektų valdymas ir apima susijusias metodikas, tokias kaip Scrum, Crystal, Extreme Programming, Unified Process ir kt.

· Planavimas ir analizė iš viršaus į apačią. Šiai tendencijai būdingi visos įmonės sprendimai dėl projektų portfelio, kurį organizacija turėtų turėti, taip pat duomenų gavybos technologijų naudojimas, kad informacija būtų aiškiau pateikta portfelyje.

Projektų valdymo metodų raida mūsų šalyje atitiko pasaulinę PM raidą šiek tiek atsiliekant nuo Vakarų, kurią 50–90-aisiais daugiausia lėmė kompiuterizavimo ir informacinių technologijų atsilikimas, taip pat praktinis projektų valdymo taikymas, dėl jų paklausos stokos pastaruoju metu egzistuojančios planinės-skirstomos ekonomikos ir administracinio-komandinio valdymo metodų.

Projektų valdymo patirties Rusijoje tyrimo, žinių kaupimo ir PM metodikos formavimo rezultatai leidžia išskirti tris pagrindinius PM kūrimo proceso etapus:

1. Ikirevoliucinis- Projektų valdymo žinių srities elementų, koncepcijų, skaičiavimo standartų, gamybos procesų atvaizdavimo modelių ir kt. kilmė ir jų pritaikymas praktikoje;

2. sovietinis– centralizuoto planavimo sistemos, į programą nukreipto požiūrio, valdymo struktūrų ir dokumentų rinkinio, tinklo planavimo ir automatizuoto valdymo sistemų bei kitų projektų valdymo metodikos elementų sukūrimas;

3. Modernus– profesionalaus projektų valdymo, pagrįsto moderniomis koncepcijomis ir naujomis pažangiomis technologijomis, raidos etapas. Integruotas sisteminis požiūris į projektų valdymo metodus. Į projektus orientuoto požiūrio į projektų ir programų įgyvendinimą įvairiose tikslinės veiklos srityse platus visoje šalyje diegimas.

2003 m. birželį Maskvoje vykusiame pirmame pasauliniame projektų valdymo kongrese Rusijos istorijoje buvo parodyti naujausi pasiekimai projektų valdymo srityje Rusijoje. Šiandien projektų valdymas plačiai naudojamas įvairiose veiklos srityse ir ūkio sektoriuose, įskaitant (mažėjančia įgyvendinimo masto tvarka):

Valstybiniai ir tarptautiniai projektai – 18 proc.

Inovacijos, MTEP – 18 proc.

Informacinės technologijos – 16 proc.

Pramonė ir transportas – 13 proc.

Energija (nafta, dujos, elektra) – 11 proc.

Statyba – 8 proc.

socialinė sritis 8 proc.

telekomunikacijos – 5 proc.

Kita (žiniasklaida, bankai) – 3 proc.

Šiandien Rusijoje, pradėjus vykdyti prioritetinius nacionalinius projektus ir tokius projektus kaip žiemos olimpinės žaidynės - SOCHI 2014, susidomėjimas ir dėmesys projektiniam požiūriui labai išaugo, susidarė itin palanki situacija tolimesniam 2014 m. Projektų valdymo profesija.

Per pastaruosius 17 metų buvo sukurtos objektyvios prielaidos plataus masto projektų valdymo plėtrai ir taikymui Rusijoje. Tačiau projektų valdymo problemos vis dar labai menkai remiamos visuomenės ir žiniasklaidos. Todėl pagrindinis artimiausios ateities uždavinys – sukurti motyvacijos ir paskatų sistemą plačiai plėtoti ir taikyti projektų valdymą, kad tuo pagrindu būtų užtikrinta novatoriška mūsų ekonomikos ir visos visuomenės plėtra bei transformacija.

Tobulėjant projektų valdymo technologijoms, kaip matyti iš pateiktos lentelės, palaipsniui plėtėsi projektinės veiklos mastai.

1 lentelė. Projekto veiklų apimtis.

Projektų valdymas (Project management, iš anglų kalbos - Project Management) - yra žinių pritaikymas (asmeninis įgijo patirties, pasaulinė – „geriausia praktika“ ir įmonė), įgūdžiai ir kompetencijos (įgimti – minkštieji įgūdžiai ir įgyti – sunkūs įgūdžiai), įrankiai ir metodai (standartai, metodikos, technikos, žymėjimai, informacinės sistemos ir tt) projektiniam darbui, su kuriais turi atitikti šiam projektui keliamus reikalavimus subalansavus keturias sudedamąsias dalis – turinį, laiką, sąnaudas (trigubas apribojimus) ir kokybę (žr. 1 pav.), neseniai buvo pridėtas dar vienas penktasis komponentas – rizika. Projekto valdymas reiškia aiškų ir apgalvotą projekto planą, nukrypimų nuo plano sumažinimą, projekto rizikos mažinimą ir veiksmingą projekto pokyčių valdymą.

1 pav. Trigubi projekto apribojimai.

Daugeliui valstybinių ir komercinių įmonių programos ir projektai yra labai svarbūs. Per programas ir projektus, taip pat projektų portfelį daugelis organizacijų turi galimybę ženkliai padidinti savo pelną efektyviai įgyvendindamos savo strateginį planą, naudodamos įvairius metodus ir geriausią projektų valdymo praktiką. Projektai vaidina svarbų vaidmenį formuojant produkto koncepciją, kuriant produktą ir pateikiant jį į rinką bei toliau didinant produkto pardavimą. Įgyvendinant projektus sukuriamos naujos ar modernizuojamos gamybos priemonės, naujos informacinės sistemos, naudingi atradimai, technologiniai proveržiai. Restruktūrizavimo ar valdymo pertvarkymo projektai lemia bendrą sąnaudų ir produkto gamybos sąnaudų sumažėjimą. Projektų valdymas yra gyvybiškai svarbus tolesniam sėkmingam bet kokios smulkaus, vidutinio, stambiojo verslo ir valstybinių įmonių organizacijos veikimui ir plėtrai, taip pat pasaulinių socialinių ir technologinių programų įgyvendinimui šalies viduje ir tarptautiniu lygiu.

Tikslas diegti ir nuolat tobulinti projektų valdymo procesus ir metodus, remiantis standartais ir pasauline praktika, vyriausybinėse ir komercinėse organizacijose, yra padidinti programų, projektų ir portfelių įgyvendinimo efektyvumą per numatytą laiką, išteklius (darbo jėgą), biudžetą ir galutinio produkto ar paslaugos kokybę.

Šiuolaikinis projektų valdymas kelia šias užduotis:

• garantuoja, kad kiekvienas sumanytas ir patvirtintas vykdyti projektus atitiks nustatytus aukščiausio lygio strateginius tikslus, o projekto tikslų pasiekimas yra realizuojamas esant priimtinam rizikos lygiui (konkurencinė, ekonominė, politinė, techninė, kaštų ir laiko komponentai);
• leisti planuoti, kontroliuoti ir valdyti kiekvieną atskirą projektą kartu su visais kitais, kad visi projektai būtų vykdomi efektyviai ir pasiektų numatytą tikslą. Projekto tikslas suprantamas kaip organizacijos strateginio tikslo pasiekimas per numatytą laiką ir patvirtintą biudžetą.

Projektų valdymo raidos istorija

Šiuolaikiniai projektų valdymo metodai ir standartai pagrįsti žmonijos patirtimi, sukaupta per kelis tūkstančius metų. Kad ir kaip tai skambėtų banaliai, bet kaip pavyzdį galime pateikti gerai žinomus septynis pasaulio stebuklus: Egipto piramidžių statybą, Aleksandrijos švyturį ar Rodo koloso statybą ir kt. Visi šie objektai yra pagrįsti titanišku žmonių darbu, ne tik fiziniu, bet ir projektuojant šiuos statybos projektus. Įgyvendinant tokius projektus, buvo padaryta daugybė atradimų, panaudotos inovatyviausios to meto technologijos, panaudota didžiulė resursų (darbo, materialinių ir nematerialių) suma. Valstybinės struktūros ir organizacijos prisiėmė visą atsakomybę už tokių projektų įgyvendinimą, palaipsniui kaupė patirtį organizuojant darbus, planuojant darbus ir kt.

Projektų valdymo požiūriu pagrindinį indėlį į discipliną įnešė tokie XX amžiaus pradžios mokslininkai, pramonininkai ir praktikai:

• Frederickas Tayloras – suformavo mokslinio darbo ir valdymo organizavimo principus.
• Henry Fordas, „autoritarinio projektų/gamybos valdymo“ įkūrėjas, pirmasis panaudojo pramoninę surinkimo liniją.
• Administracinės vadybos mokyklos įkūrėjas Henri Fayol apibūdino vieningos vadybos teorijos pagrindus.
• Henry Gantt – suformavo struktūrinį požiūrį į apimtį, laiko ir darbo valdymą, sukūrė ir panaudojo diagramą kaip priemonę, vaizduojančią projekto užduočių trukmę ir seką.
• Garringtonas Emersonas yra efektyvios ekonominės veiklos teorijos pradininkas ir racionalaus gamybos valdymo šalininkas.

Pirmieji kokybiniai žingsniai į priekį plėtojant projektų valdymą buvo padaryti XX amžiuje, prieškario metais. Galima sakyti, kad tuo metu projektų valdymas pradėjo formuotis kaip savarankiška disciplina. 2 paveiksle pateikti reikšmingi projektų valdymo raidos įvykiai ir etapai.

2 pav. Pagrindiniai projektų valdymo plėtros etapai.

Sulaukus 30–50 metų, daromi pirmieji atradimai ir formuojamos pagrindinės technologijos, naudojamos iki šiol. Projektų valdymas pradeda įgyti struktūrinių savybių:

• 1937 m. – amerikiečių mokslininkas Gulickas pirmą kartą sukūrė matricinę organizaciją, skirtą sudėtingiems projektams valdyti ir įgyvendinti;
• 1956 – „Du Pont de Nemours Co.“ įkūrė grupę projektų valdymo metodams ir priemonėms kurti;
• 1957 – Remington Rand komanda, vadovaujama Kelly ir Walker, sukūrė kritinio kelio metodą (CPM) su programinės įrangos diegimu UNIVAC kompiuteryje;
• 1957-58 – programai „Polaris“ (JAV karinis jūrų laivynas) buvo sukurta ir išbandyta PERT tinklo planavimo sistema;
• 1959 m. – Andersono komitetas (NASA) pasiūlė sisteminį projekto valdymo metodą pagal jo gyvavimo ciklo etapus, kuriame ypatingas dėmesys buvo skiriamas priešprojektinei analizei;
• 1956–1958 m. sukurti tinklo planavimo metodai ir technikos davė galingą impulsą projektų valdymo plėtrai;
• PM plėtra šeštajame dešimtmetyje baigėsi Gaddiso paskelbimu Harvard Business Review – pirmajame apibendrinančiame straipsnyje apie projektų valdymą.

60-ieji - tinklo planavimo metodų kūrimas:

• Plėtojant projektų valdymą, pagrindinis dėmesys skiriamas PERT ir CPM metodams;
• Tinklų planavimo metodų populiarinimas ir bandymai šiuos metodus taikyti įvairiose veiklos srityse;
• Matricinės organizacijos formos atsiradimas ir tolesnis organizacinių formų vystymasis;
• Amerikiečių mokslininkai P. Lawrence ir J. Lorsch, J. Galbraith ir kiti aprašė integracijos mechanizmų tipus ir jų Naudojimo sąlygos;
• 1966 – sukurta integruota logistikos sistema ir alternatyvus tikimybinio tinklo planavimo metodas GERT.

70-ieji – sisteminio požiūrio į projektų valdymą kūrimas:

• Visapusiškas tinklo planavimo ir valdymo metodų kūrimas ir diegimas;
• Įstatymų leidybos lygmeniu JAV CPM sulaukia paramos;
• Įgyvendindami projektą, jie pradeda atsižvelgti ne tik į vidinę, bet ir į išorinę aplinką (ekonominius, aplinkos, socialinius ir kt.);
• 1971 m. – pirmieji formalaus požiūrio į konfliktų sprendimą bandymai;
• 1977 – atsiranda konfliktų valdymo metodai;
• 1977 - 1979 - Projektų valdymo organizacinių struktūrų formavimas;

Visame pasaulyje kuriasi profesionalios projektų valdymo organizacijos:

• IPMA (Tarptautinė projektų valdymo asociacija, Europa) – Tarptautinė projektų valdymo asociacija;
• PMI (Project Management Institute, JAV) – Projektų valdymo institutas.

Atskirai verta paminėti, kad 1987 m. buvo išleistas pirmasis PMBoK (Project Management Body of Knowledge) leidimas. Ši metodika vėliau taps tarptautiniu projektų valdymo standartu ir perims geriausią praktiką bei pasaulinę patirtį. Iki šiol PMBoK yra plačiausiai naudojama metodika visame pasaulyje. Daugelis standartų yra pagrįsti PMBoK metodika.

Nenuvertinkite Rusijos ir Sovietų Sąjungos patirties plėtojant projektų valdymą. Pirmosios tendencijos ir požiūriai atsirado valdant Nikolajui II.

• 1825 m. – pirmieji fundamentalūs M.M. Speranskis.
• 1900-ieji - P.A. praktinių valdymo metodų taikymas ir tobulinimas. Stolypinas.
• 1920-ieji - kūriniai A.K. Gastevui dėl mokslinio darbo organizavimo ir valdymo; Rusijos Federacijos CIT sukūrimas. Vėliau Gastevo darbas tapo liesos gamybos (Lean Production) pagrindu naudojant Toyota metodą.
• 1930-ieji - praktinė patirtis, įgyta vykdant pirmųjų penkerių metų planų projektus. Pagal kurią buvo pritaikyta ir išplėtota daug požiūrių ir valdymo metodų, akcentuojant darbo išteklių valdymą.
• 1946 – 1961 m - atominių ginklų ir raketų bei kosmoso technologijų kūrimo projektų įgyvendinimas SSRS. Neįkainojama kartų patirtis, SSRS pramonės plėtros aukso amžius.
• 1970-ieji - programinės įrangos taikymas ir kūrimas bei sisteminis projektų valdymo metodas SSRS, kūrimas įvairiuose šalies ūkio sektoriuose automatizuotos valdymo sistemos organizacijoms ir įmonėms (ACS).
• 1990-ieji - tarptautinių procesų ir projektų valdymo metodų taikymas, patirties formavimas ir kaupimas. Sovietinės projektų valdymo asociacijos SOVNET atidarymas, profesionalių paslaugų ir projektų valdymo programinės įrangos produktų rinkos formavimas. Nacionalinės projektų vadovų mokymo ir atestavimo programos, pagrįstos tarptautiniais reikalavimais ir standartais, formavimas ir įgyvendinimas.

Požiūrių į projektų valdymą įvairovė

Įvairūs požiūriai į projektų valdymą plačiai paplito visame pasaulyje ir paveikė visas žmogaus veiklos sritis. Šie metodai atsispindi metodologijose, kurias kuria įvairios asociacijos ir organizacijos. Šiuo metu susikūrė daug profesinių asociacijų, kurios labai sparčiai plečiasi:

• PMI asociacija – Projektų valdymo institutas – turi filialus 39 šalyse, o šio instituto nariai gyvena 80 šalių.
• IPMA asociacija – Tarptautinė projektų valdymo asociacija – tai tarptautinis tinklas, apimantis 28 nacionalines projektų valdymo bendruomenes.
• APM asociacija – Projektų valdymo asociacija – yra IPMA dalis.
• PDMA asociacija – Produktų vystymo vadybos asociacija – kurios pagrindinė idėja yra produktų kūrimo valdymas.
• Asociacija AACE – Cost Engineering pažangos asociacija – skirta kaštų inžinerijos plėtrai.

Nepaisant to, kad galutiniai rezultatai yra įvairūs produktai, sukurti skirtingose ​​pramonės šakose, požiūris į projektų valdymą jose yra gana panašus. Pats projektas nėra galutinis rezultatas, teisingiau sakyti, kad projektas yra naujo ir unikalaus galutinio rezultato kūrimo procesas. Tie patys projektų valdymo principai taikomi projektams ir programoms visose žmogaus veiklos srityse, nors yra didelių požiūrių ir procesų skirtumų, kurie priklauso nuo konkrečios dalykinės srities.

Organizacijos ir projektų valdymas

Visas organizacijas galima suskirstyti į du pasaulinius tipus. Pirmoji apima į projektus orientuotas organizacijas, kuriose projektai yra pagrindinis verslas. Šiam tipui priskiriamos architektūros, projektavimo ir inžinerijos įmonės, programinės įrangos kūrėjai, telekomunikacijų įmonės, konsultacinės organizacijos ir įvairiose profesinės veiklos srityse paslaugas teikiančios įmonės, įskaitant įmones, kurios pelną gauna įgyvendindamos projektus. Tokių įmonių augimo strategijas atspindi įmonės siūlomų projektų dydis, pobūdis, pristatymo būdas ir tipas bei tai, kaip tokie projektai yra aprūpinami ištekliais (vidinis tiekimas) sutarties sudarymo metu.

Antrasis organizacijos tipas yra priklausomas nuo projektų, kurių augimas ir plėtra priklauso nuo projektų. Tai prekes ir paslaugas siūlančios organizacijos. Projektai ir programos tokiose organizacijose finansuojami ir remiami pirmiausia iš vidaus. Tai plataus vartojimo prekių, farmacijos produktų ir kt.

Projektų valdymo vaidmenys ir dalyviai

• Projektų valdymo komitetas – kolegialus organas, priimantis strateginius sprendimus dėl tam tikrų vykdomų projektų konkrečioje organizacijoje. Paprastai tokie sprendimus priimantys organai kuriami didelėse organizacijose.
• Projektų biuras – struktūrinis padalinys, kurio užduotys apima projektų valdymo metodo įgyvendinimą, plėtojimą ir palaikymą. Kartais Projektų biuras (Projektų valdymo biuras) suprantamas kaip laikinas struktūrinis padalinys, organizuojamas konkrečiam projektui. Tokio padalinio užduotys apima tiesioginį didelio projekto valdymą.
• Projekto vadovas – pagrindinis projekto valdymo vaidmuo. Pagrindinė užduotis – organizuoti darbą su projektu ir pasiekti numatytus tikslus, atsižvelgiant į tam tikrus apribojimus ir prielaidas. Už kokybišką ir savalaikį projekto vykdymą atsako projekto vadovas.
• Projekto valdymo komanda – atsiskaito projekto vadovui ir padeda jam organizuoti darbą. Projekto vadovas dalį savo pareigų deleguoja projekto valdymo komandos nariams. Tarp kitų galima išskirti šiuos vaidmenis: Projekto administratorius (projekto dokumentų srautas, komunikacija), Rizikos valdymo vadovas (planavimas, rizikos kontrolė), Projekto architektas (atsakingas už sprendimo vientisumą) ir kt.
• Projekto komanda – tai likę dalyviai (atlikėjai), dalyvaujantys projekto uždaviniuose.

Įmonės projektų valdymo sistema

Įmonės projektų valdymo sistema (toliau – CPVS) – tai būtinų ir vientisų komponentų paketas, per kurį organizacijoje vykdomas formalizuotas ir efektyvus projektų valdymas. Šių komponentų įdiegimas užtikrina sistemos vientisumą ir jos efektyvumą. Klasikinėje versijoje išskiriami šie komponentai: Projekto biuras, PMIS, Metodika.

Projektų valdymo informacinės sistemos

Šiuo metu egzistuoja kelių tipų sistemos (ISMS), per kurias organizacijoje vykdomas projektų ir portfelio valdymo procesų automatizavimas. Pirmasis tipas yra serverio sprendimai ( „Microsoft Enterprise“ projektų valdymas,Oracle Primavera ir kt.); Antrasis tipas – debesų technologijos (SaaS, PaaS sprendimai); Trečias tipas yra mišrus.

„Iš visų iššūkių, su kuriais susidūrė NASA siųsdama žmogų į Mėnulį, kontrolė buvo bene sunkiausia.

— Rogeris Launis, NASA istorikas

Per visą istoriją žmonija sukaupė įspūdingą sąrašą sėkmingai įgyvendintų sudėtingų projektų. Nuo Gizos piramidžių statybos iki žmogaus išsiuntimo į Mėnulį – drąsiausios žmogaus pastangos reikalavo koordinuoto tūkstančių žmonių darbo. O tai reiškia sudėtingą projektų valdymo sistemą.

Ir nors tik nedaugelis iš mūsų susidurs su tokio masto užduotimis, dauguma šio tinklaraščio skaitytojų vienaip ar kitaip susidurs su projektų valdymu. PMI skaičiavimais, iki 2020 m. bus – ir daugeliui kitų specialistų dažnai teks vadovauti mini projektams, bent jau asmeniniu lygmeniu.

Paprastai tariant, projektų valdymas yra visko, ko reikia tikslui pasiekti, valdymas ir organizavimas – laiku ir, žinoma, neviršijant biudžeto. Nesvarbu, ar tai naujos programinės įrangos kūrimas, rinkodaros kampanijos vykdymas ar žmonių nusileidimas Marse, projektų valdymas leidžia pasiekti sėkmės.

Visi projektai skirtingi. Nėra tobulos projektų valdymo sistemos, kuri tiktų bet kokio tipo projektams. Taip pat nėra sistemos, kuri tiktų kiekvienam vadovui ir būtų patogi visiems komandos nariams. Tačiau per projektų valdymo egzistavimą buvo sukurta daug veiksmingų metodų, metodų ir standartų, kuriuos galima pritaikyti. Šiandien kalbėsime apie populiariausius iš jų.

Sukurti metodai labai skiriasi vienas nuo kito. Jie skiriasi taikymo sritimis, detalumu, savarankiškumu ir formalizavimu. Pavadinime juos pavadinome „metodais“, kad būtų patogu, tačiau iš tikrųjų straipsnyje pateikiami projektų valdyme naudojami standartai, sąvokos, metodai ir sistemos. Šio straipsnio tikslas – pateikti kuo platesnę esamų projektų valdymo metodų apžvalgą.

Šiame straipsnyje apžvelgsime:

• Klasikinis projektų valdymas
• Judrus
• Scrum
• Liesos
• Kanbanas
• ŠešiSigma
• PRINCAS2

Ir prieš nagrinėdami konkrečius metodus, atsakykime į akivaizdų klausimą - „Kam mums apskritai reikalingos projektų valdymo sistemos ir metodai?– Žinoma, trumpai pažvelkime į projektų valdymo istoriją ir apibrėžkime pagrindinius projektų valdymo terminus.

Kodėl „projektų valdymas“?

Neilo Armstrongo ir Buzzo Aldrino vardai amžinai įeis į istoriją kaip vieno didžiausių žmonijos laimėjimų – žmogaus išsilaipinimo Mėnulyje – simboliai. Tačiau prie šio įvykio daugiausia prisidėjo 400 000 NASA darbuotojų ir 20 000 įmonių bei universitetų, kurie kartu dirbo „Apollo“ misijoje.

1961 metais Johnas Kennedy iškėlė užduotį nuleisti žmogų ant Žemės palydovo ir grąžinti jį atgal – nepaisant to, kad tuo metu NASA žmogų į kosmosą išsiuntė tik 15 minučių. Toks ambicingas tikslas pareikalavo neįtikėtinai daug išteklių, bendradarbiavimo, inovacijų ir planavimo.

Remiantis NASA knyga „Managing the Moon Program“, pagrindinė problema nebuvo „ ką daryti?" ir tame „ kaip padaryti tiek daug per tiek trumpa laika? Pasak Johnsono kosmoso centro inžinerijos vadovo daktaro Maxo Fageto (Lyndono B. Johnsono kosmoso centras, JSC), tada NASA neįsivaizdavo, kaip visus būtinus veiksmus sutalpinti į 10 metų. Todėl pirmasis žingsnis buvo „projektą suskaidyti į valdomus etapus“.

Tada buvo svarbu paspartinti kiekvieną atskirą etapą ir užtikrinti, kad kiekviename etape dirbančios komandos ir įmonės efektyviai bendrautų tarpusavyje ir laiku pasiektų rezultatus. Ši užduotis buvo patikėta daktarui George'ui E. Mulleriui, kuris vadovavo kiekvienai „Apollo“ projekto daliai – nuo ​​Baltųjų rūmų iki mažiausios dalies tiekėjo. Kad būtų lengviau valdyti projektą, jis nusprendė projektą suskirstyti į 5 sritis: programų valdymą, sistemų inžineriją, testavimą, patikimumą ir kokybę bei skrydžio operacijas. Apollo programos valdymo schema parodyta figūra 1.

Kaip pažymi pats Muelleris, ši 5 žingsnių sistema, pavadinta „GEM etapais“ pagal Dr. Muellerio inicialus, buvo sukurta „sutelkti dėmesį į gaminio testavimą ir sukūrimą, kad jis būtų išbandytas“. Programos kontrolė nustatė, ką reikia padaryti, valdė biudžetus ir reikalavimus, tvarkė programos elementų tarpusavio ryšius. Sistemų inžinerijos skyrius buvo atsakingas už naujų prietaisų ir komponentų kūrimą, Testavimas buvo atsakingas už tai, kad šie nauji elementai veiktų, Patikimumas ir kokybė tikrino sukurtus elementus, kad atitiktų reikalavimus ir standartus, o Skrydžių operacijos buvo atsakinga už tai, kad šie mazgai. dirbs skrydžio metu.

Daugelis iš pradžių skeptiškai žiūrėjo į Mullerio pasiūlytą metodą, tačiau galiausiai jam pavyko įtikinti programos narius, kad reikia vadovautis šiuo algoritmu. Ši sistema įrodė savo efektyvumą – projektas buvo užbaigtas sėkmingai, o, galima sakyti, pergalingai, anksčiau nei buvo numatytas terminas. Tai buvo įmanoma tik suskaidžius didelio masto projektą į valdomus, pakartojamus žingsnius, leidžiančius daugeliui atskirų įmonių ir specialistų dirbti tokiu pačiu tempu. Taip projektų valdymas įrodė savo efektyvumą kosminėse lenktynėse.

Trumpa projektų valdymo istorija

Projektų valdymą sugalvojo ne NASA ar daktaras Miuleris. Egipto piramidės ir Didžioji kinų siena yra priešistorinių epochų projektų valdymo produktai. Deja, nėra dokumentinių įrodymų, kaip šie projektai buvo įgyvendinami ir valdomi, o dabartinis projektų valdymas yra atskirtas nuo praėjusių amžių žinių.

Akivaizdžiausias būdas įgyvendinti projektą yra suskirstyti jį į etapus arba atskiras užduotis. Kaip kulinarinis receptas – nusiperki ingredientus, teisingai sumaišai, gamini ir patieki. Paprasčiausias projektų valdymo įrankis – tai veiksmų, kuriuos reikia atlikti norint pasiekti tikslą, kontrolinis sąrašas. Paprasta ir veiksminga.

Tačiau jei esate virtuvės šefas ir ruošiate ne vieną patiekalą, o kelis, pavyzdžiui, salotas (kurių gaminimas susideda iš 3 etapų) ir desertą (kurį tereikia patiekti), tuomet jums reikės įrankis, leidžiantis sekti laiką, praleistą prie kiekvieno iš jų, ir laiką, kada jie turėtų būti paruošti. Ir čia į pagalbą ateina vienas iš pirmųjų modernių projektų valdymo įrankių: Ganto diagrama, pateikta ant 2 pav.

Savarankiškai išrado K O Korolio Adameckio ir Henry L. Gantt vaidmuo XX amžiaus pradžioje Ganto diagramoje rodomas projekto tvarkaraštis, pagrįstas užduočių pabaigos ir užbaigimo datomis. Į jį įrašomos užduotys, jų trukmės ir ryšiai, o tada apskaičiuojamas kritinis kelias – ilgiausia tarpusavyje susijusių užduočių grandinė, lemianti projekto trukmę. Įvairių užduočių pradžios ir pabaigos santykiai yra labai svarbūs – juk negalite patiekti svečių sriubos, kol jos neišvirėte?

Taigi, tipinis projektas labai panašus į vakarienės ruošimo ir patiekimo projektą, tik turi daug daugiau užduočių, santykių, terminų ir išteklių rūšių. Projektams su trumpais terminais Ganto diagrama padeda nuspręsti, kada geriausia pradėti tam tikras užduotis, siekiant sutrumpinti įgyvendinimo laiką. O projektams su dideliais išteklių apribojimais Ganto diagrama suteikia galimybę sudaryti diagramą įvykiais pagrįstos proceso grandinės forma, skirta išteklių planavimui.

Skirtingiems projektams reikalingas skirtingas kontrolės lygis. Pavyzdžiui, jei publikuojate straipsnių seriją, griežti terminai nėra tokie svarbūs. Daug svarbiau yra aiškus procesas, kurio metu galima susisteminti kiekvieną straipsnį, sudaryti kiekvieno iš jų metmenis, gauti atsiliepimų, taisyti, baigti straipsnį, perskaityti ir publikuoti. Užuot valdę laiką ir išteklius, valdote procesą.

Tokiems projektams geriau tinka Agile projektų valdymo metodai ir susiję metodai, tokie kaip Lean, Kanban ir kiti. Taip pat yra metodų, leidžiančių valdyti ir darbo eigą, ir laiką, ir išteklius – 6 Sigma ir Scrum.

Populiarios projektų valdymo sistemos

Per visą projektų valdymo istoriją buvo sukurta daug įvairių projektų valdymo metodų, kurie atitiktų beveik visus poreikius. Net jei nesiruošiate siųsti vyro į Mėnulį ir neturite tiek resursų, vis tiek rasite sau tinkamą įrankį. Svarbiausia yra suprasti, kas jūsų projektui yra svarbiausia – terminai, ištekliai, proceso laikymasis ar keli veiksniai iš karto – ir tada pasirinkti projekto valdymo metodą, orientuotą į šio rodiklio pasiekimą.

Prieš apžvelgdami populiariausius metodus, apibrėžkime keletą pagrindinių terminų.

Pagrindinės projektų valdymo sąlygos

Judrus: Lankstus iteracinis-inkrementinis požiūris į projektų ir produktų valdymą, orientuotas į dinamišką reikalavimų formavimą ir jų įgyvendinimo užtikrinimą dėl nuolatinės sąveikos savarankiškai besiorganizuojančiose darbo grupėse, susidedančiose iš įvairių sričių specialistų. Yra daug metodų, pagrįstų Agile idėjomis, iš kurių populiariausi yra Scrum ir Kanban.

Kritinis kelias: Nuolatinė darbų ir įvykių seka nuo pradinio iki galutinio įvykio, kuriai užbaigti reikia daugiausiai laiko.

Procesų įvykių grandinė (EPC diagrama): diagrama, parodanti projekto darbų vykdymo seką pagal išteklių prieinamumą ir darbo krūvį

Laiko rezervas: Laikas, per kurį darbų pradžia gali būti atidėta, nedarant įtakos bendrai projekto trukmei. Taigi, darbas kritiniame kelyje turės nulį.

Gairės (kontrolinis taškas,etapas): Pagrindinis įvykis, žymintis, pavyzdžiui, etapo pabaigą. Ganto diagramoje nurodoma užduotis, kurios trukmė yra nulis.

Projekto vadovas (projekto vadovas,projektąvadovasP.M. ): Projekto komandos vadovas, atsakingas už projekto valdymą (projekto planavimą, įgyvendinimą ir užbaigimą).

Ištekliai: Projekto įgyvendinimui būtini elementai. Ištekliai apima laiką, įrangą, medžiagas, darbuotojus ir kt.

Sprintas (Sprintas): Nuo savaitės iki mėnesio trunkanti iteracija (darbo ciklas) Scrum, kurios metu sukuriama klientui vertingo produkto ar jo elemento darbinė versija.

„Klasikinis“ arba „tradicinis“ projektų valdymas: Plačiausiai naudojamas projektų valdymo metodas, pagrįstas vadinamuoju „krioklio“ arba kaskadiniu ciklu, kai užduotis perkeliama nuosekliai per srautą primenančius etapus.

Klasikinis projektų valdymas

Akivaizdžiausias būdas padaryti jūsų projektą lengviau valdomą – suskaidyti jo vykdymo procesą į nuoseklius etapus. Būtent šia linijine struktūra remiasi tradicinis projektų valdymas. Šia prasme jis primena kompiuterinį žaidimą – jūs negalite pereiti į kitą lygį nebaigus ankstesnio. Darbo eigos schema parodyta 3 pav.

Šis požiūris orientuotas į projektus, kuriuose yra griežti užduočių sekos apribojimai. Pavyzdžiui, statant namą – negalima statyti sienų be pamatų.

Paprastai yra 5 klasikinio projekto valdymo etapai, tačiau, jei to reikia projektui, galima pridėti papildomų etapų.

5 tradicinio valdymo etapai:

1 etapas. Iniciacija. Projekto vadovas ir komanda apibrėžia projekto reikalavimus. Šiame etape dažnai rengiami susitikimai ir minčių šturmo sesijos, siekiant nustatyti, koks turėtų būti projekto produktas.

2 etapas. Planavimas.Šiame etape komanda nusprendžia, kaip ji pasieks ankstesniame etape užsibrėžtą tikslą. Šiame etape komanda išsiaiškina ir detalizuoja projekto tikslus ir rezultatus bei su juo susijusių darbų apimtis. Remdamasi šia informacija, komanda sudaro tvarkaraštį ir biudžetą, įvertina rizikas ir nustato suinteresuotąsias šalis.

3 etapas. Vystymas.Šis etapas įgyvendinamas ne visiems projektams, paprastai tai yra planavimo etapo dalis. Kūrimo fazėje, būdinga technologiniams projektams, nustatoma būsimo projekto ir/ar gaminio konfigūracija bei techninės priemonės jai pasiekti. Pavyzdžiui, IT projektuose šiame etape pasirenkama programavimo kalba. ( Vidaus praktikoje šis etapas paprastai nėra išskiriamas, o terminas „plėtra“ nenaudojamas - apytiksliai. vertimas)

4 etapas. Diegimas ir testavimas.Šiame etape vyksta tikrasis pagrindinis projekto darbas – kodo rašymas, pastato statymas ir panašiai. Vadovaujantis parengtais planais, pradedamas kurti anksčiau apibrėžtas projekto turinys, vykdoma kontrolė pagal pasirinktas metrikas. Antroje šio etapo dalyje prekė yra testuojama, patikrinama, ar ji atitinka Užsakovo ir suinteresuotų šalių reikalavimus. Testavimo dalyje nustatomi ir ištaisomi gaminio trūkumai.

5 etapas. Projekto stebėjimas ir užbaigimas. Priklausomai nuo projekto, šį etapą gali sudaryti paprastas projekto rezultatų perdavimas Klientui arba ilgas bendravimo su klientais procesas, siekiant pagerinti projektą ir padidinti jų pasitenkinimą bei palaikyti projekto rezultatus. Pastaroji taikoma projektams klientų aptarnavimo ir programinės įrangos srityje.

Tai, kas aprašyta aukščiau, yra pagrindas, kuriuo remiantis kuriami įvairūs projektų valdymo metodai. Įvairūs projektai reikalauja skirtingų įgyvendinimo fazių – vieni reikalauja trijų etapų, kiti – kur kas daugiau. Kartais naudojamas vadinamasis „iteracinis krioklys“, kurio kiekvienas etapas yra subprojektas, kurio metu užduotys įgyvendinamos fiksuotomis iteracijomis. Tačiau esmė išlieka ta pati – projektas suskirstytas į etapus, kurie vykdomi griežtai apibrėžta seka.

Dėl to, kad klasikinis projektų valdymas yra griežtai susietas su užduočių vykdymo laiku, paprastai iš anksto numatytu planavimo etape, kalendoriaus ir tinklo planavimo įrankiai puikiai tinka įgyvendinti projektus pagal šį metodą. Labiausiai paplitęs planavimo ir tinklo planavimo įrankis yra anksčiau minėta Ganto diagrama. Yra daug įrankių jai sukurti – nuo ​​paprastų skaičiuoklių, pvz., „Excel“ ir „Smartsheet“, iki profesionalių programinės įrangos paketų, tokių kaip „Microsoft Project“ ir „Primavera“.

Klasikinio projektų valdymo stipriosios pusės

Šiandien dažnai sakoma, kad klasikinis krioklio metodas yra pasenęs, tačiau jis negalvoja prarasti pozicijų. Didelis šio požiūrio privalumas yra tai, kad klientas ir įmonės vadovybė jau pirmajame projekto etape turi nuspręsti, ką jie nori gauti. Ankstyvas įtraukimas suteikia projektui tam tikro stabilumo, o planavimas leidžia supaprastinti projekto įgyvendinimą. Be to, šis metodas apima veiklos stebėjimą ir testavimą, kuris yra būtinas realiems įvairaus dydžio projektams.

Potencialiai klasikinis požiūris leidžia išvengti streso dėl to, kad kiekviename etape yra laisvo laiko, skirto bet kokioms komplikacijoms ir rizikoms. Be to, tinkamai atlikus planavimo etapą, projekto vadovas visada žino, kokius išteklius turi. Net jei šis įvertinimas ne visada tikslus.

Klasikinio projektų valdymo trūkumai

Pagrindinė klasikinio projektų valdymo silpnybė – nepakantumas pokyčiams. Tokių sistemų kaip „Lean“ ir „Kanban“ kūrimu garsėjančios „Toyota“ vadovybė dažnai kritikuojama dėl klasikinio požiūrio, kurdama programinę įrangą savo įmonei, o būtent dėl ​​lankstumo stokos.

Pagrindinis klasikinio požiūrio pagrindas dabar yra statybos ir inžineriniai projektai, kuriuose projekto turinys išlieka beveik nepakitęs viso projekto metu. Tačiau jei jūsų projekte ištekliai ir laikas nėra pagrindiniai apribojimai, o projekto turinys gali keistis, galbūt turėtumėte atidžiau pažvelgti į kitas projektų valdymo sistemas.

Judrus

Kaip minėta anksčiau, ne visi projektai gali būti struktūrizuoti taip, kad juos būtų galima įgyvendinti naudojant klasikinį projektų metodą. Grįžtant prie mūsų pavyzdžio su šefu: vieno patiekalo ruošimas puikiai dera su „krioklio“ principu, tačiau laiku paruošti ir patiekti keturių patiekalų vakarienę bus beveik neįmanoma, jei kaskart teks laukti, kol bus baigtas vienas patiekalas. kitas.

Ir čia atsiranda „Agile“ – lanksčių pasikartojančių projektų ir produktų valdymo metodų šeima. Pagal šį metodą projektas nedalomas į nuoseklias fazes, o į mažus subprojektus, kurie vėliau „surenkami“ į gatavą produktą. Veikimo schema parodyta 5 pav.

Taigi inicijavimas ir aukščiausio lygio planavimas vykdomas visam projektui, o tolesni etapai: kūrimas, testavimas ir kiti atliekami kiekvienam mini projektui atskirai. Tai leidžia greičiau perkelti šių mini projektų rezultatus, vadinamuosius prieaugius, o pradedant naują subprojektą (iteraciją), galima atlikti jo pakeitimus be didelių išlaidų ir įtakos likusiai projekto daliai.

Nepaisant to, kad Agile į madą atėjo palyginti neseniai, kartotinės plėtros idėja nėra nauja. (apie pasirodymo istorijąAgile galima skaityti – apytiksliai). Lanksčių metodikų šeima savo dabartinį pavadinimą gavo 2001 m., paskelbus Agile Manifestą, kuriame buvo nustatytos pagrindinės lanksčios programinės įrangos kūrimo vertybės ir principai, pagrįsti komandiniu darbu ir prisitaikymu, netgi „meile“ pokyčiams.

Pats „Agile“ nėra projektų valdymo metodas. Tai greičiau idėjų ir principų rinkinys, kaip turėtų būti įgyvendinami projektai. Jau remiantis šiais principais ir geriausia praktika buvo sukurti individualūs lankstūs metodai arba, kaip kartais jie vadinami, karkasai: Scrum, Kanban, Crystal ir daugelis kitų. Šie metodai gali labai skirtis vienas nuo kito, tačiau jie vadovaujasi tais pačiais principais.

StiprybėsJudrus

Svarbiausias Agile privalumas – lankstumas ir pritaikomumas. Jis gali prisitaikyti prie beveik bet kokių organizacijos sąlygų ir procesų. Būtent tai lemia dabartinį jo populiarumą ir tai, kiek pagal tai sukurta įvairių sričių sistemų.

Vienas iš Agile principų yra toks: „Reaguoti į pokyčius yra svarbiau nei laikytis plano“. Dėl šio greito ir gana neskausmingo reagavimo į pokyčius daugelis didelių įmonių siekia padaryti savo procesus lankstesnius. Be to, „Agile“ puikiai tinka neribotiems projektams, pavyzdžiui, kuriant paslaugą ar tinklaraštį.

Agile sritis – naujų, inovatyvių produktų kūrimas. Tokiuose produkto kūrimo projektuose yra didelis neapibrėžtumas, o informacija apie produktą atskleidžiama projekto eigoje. Tokiomis sąlygomis „krioklio“ projekto įgyvendinimas tampa neįmanomas - nėra informacijos planavimui.

Silpnosios pusėsJudrus

Skirtingai nuo PRINCE2 ir PMBOK, Agile nėra nei metodika, nei standartas. Agile – tai principų ir vertybių rinkinys. Silpnybė ta, kad kiekviena komanda turės savarankiškai susikurti savo valdymo sistemą, vadovaudamasi Agile principais. Tai sudėtingas ir ilgas procesas, kuriam reikės pokyčių visoje organizacijoje – nuo ​​procedūrų iki pagrindinių vertybių. Tai sudėtingas kelias ir ne visos organizacijos gali tai padaryti.

Šis kelias iš pokyčių lyderio pareikalaus ne tik žinių ir užsispyrimo, bet ir rimtų administracinių resursų bei išlaidų. Laimei, yra paruoštų praktikų rinkinių, kurie palengvina judrią organizacijos transformaciją. Tokie rinkiniai apima „Scrum framework“, „Kanban“ metodą ir daugelį kitų – „Crystal“, „LeSS“, „SAFe“, „Nexus“.

Scrum

1986 m. sukurta „Agile“ sistema laikoma labiausiai struktūrizuota „Agile“ šeima. Sukurta 1986 m., ji sujungia klasikinio proceso elementus ir judraus požiūrio į projektų valdymą idėjas. Rezultatas buvo labai subalansuotas lankstumo ir struktūros derinys.

Vadovaudamasi „Agile“ nurodymais, „Scrum“ suskaido projektą į dalis, kurias Klientas gali iš karto panaudoti vertei gauti, vadinamą produkto atsilikimu. Ir nepaisant to, kad „produkto atsilikimas“ yra gana teisingas vertimas ir naudojamas profesinėje literatūroje, Rusijos praktikoje dažniausiai naudojamas tiesiog „atsilikimas“. Tada šioms dalims pirmenybę teikia Produkto savininkas – Kliento atstovas komandoje. Svarbiausi „gabalai“ yra pirmieji, kurie atrenkami vykdyti „Sprint“ – taip vadinamos „Scrum“ iteracijos, trunkančios nuo 2 iki 4 savaičių. Sprinto pabaigoje Klientui pateikiamas darbinis gaminio priedas – tie labai svarbūs „gabalai“, kuriuos jau galima naudoti. Pavyzdžiui, svetainė su dalimi funkcijų arba programa, kuri jau veikia, nors ir iš dalies. Po to projekto komanda pradeda kitą Sprintą. Sprinto trukmė yra fiksuota, tačiau komanda ją pasirenka savarankiškai projekto pradžioje, atsižvelgdama į projektą ir savo veiklos rezultatus.

Siekiant užtikrinti, kad projektas atitiktų Užsakovo reikalavimus, kurie laikui bėgant linkę keistis, prieš kiekvieno Sprinto pradžią neįvykdytas projekto turinys įvertinamas iš naujo ir jame atliekami pakeitimai. Šiame procese dalyvauja visi – projekto komanda, Scrum Master (Scrum Master, projekto komandos vadovas) ir Produkto savininkas. Ir atsakomybė už šį procesą tenka kiekvienam.

Kaip jau minėta, Produkto savininkas yra Kliento atstovas projekte arba atstovauja visiems būsimo projekto klientams, jei Kliento nėra. Norėdami tai padaryti, jis turi gerai žinoti jų poreikius ir mąstymo būdą, taip pat suprasti produktą ir jo gamybos technologiją. Scrum Master skirtas padėti projekto dalyviams geriau suprasti ir priimti Scrum praktikos vertybes, principus ir normas. Jis yra lyderis ir tarpininkas tarp išorinio pasaulio ir komandos. Jo užduotis – užtikrinti, kad niekas netrukdytų komandai savarankiškai ir patogiai atlikti pavestas užduotis. Komanda yra atsakinga už tai, kad sprinto pabaigoje būtų atliktos visos reikalingos užduotys ir įvykdyti pristatymai.

Pagrindinė „Scrum“ procesų struktūra sukasi apie 5 pagrindinius susitikimus: atsilikimų derinimas, „Sprint“ planavimas, kasdieniai susitikimai, „Sprint“ užbaigimas ir „Sprint“ retrospektyva.

Daugeliui Scrum gali atrodyti sunkiai įgyvendinamas – naujas procesas, nauji vaidmenys, daug delegacijų ir visiškai nauja organizacinė struktūra. Tačiau tai lankstus, tačiau struktūrizuotas požiūris į projekto įgyvendinimą, kuris, skirtingai nei neaiškūs ir bendri Agile principai, neleis darbui pakrypti netinkama linkme.

StiprybėsScrum

Scrum buvo sukurtas projektams, kuriems reikia „greitų pergalių“ ir tolerancijos pokyčiams. Be to, ši sistema tinkama situacijoms, kai ne visi komandos nariai turi pakankamai patirties toje srityje, kurioje įgyvendinamas projektas – nuolatinis komandos narių bendravimas leidžia kai kurių darbuotojų patirties ar kvalifikacijos stokai pasinaudoti informacija ir pagalba kolegos.

Internetinis televizijos kanalas „Netflix“ yra puikus greito rezultatų pateikimo pavyzdys. Resursų svetainė kas dvi savaites atnaujinama Scrum dėka, kuri leidžia ne tik dirbti dideliu greičiu, bet ir kaupia vartotojo patirtį bei leidžia identifikuoti klientams svarbiausius dalykus.

Kiekvienos iteracijos metu kūrėjai prideda ir išbando naujas svetainės funkcijas ir pašalina tas, kurių klientai nenaudojo. „Netflix“ komandos teigimu, pagrindinis „Scrum“ pranašumas yra tai, kad jis leidžia „greitai žlugti“. Užuot ilgai ir didelėmis išlaidomis ruošiant didelį leidinį, Scrum kas dvi savaites pristatomas mažas dydis. Juos lengva atsekti ir, jei kas nors nepavyksta, greitai pataisyti.

Silpnosios pusėsScrum

Scrum yra labai reiklus projekto komandai. Ji turėtų būti nedidelė (5-9 žmonės) ir daugiafunkcinė – tai yra, komandos nariai turi turėti daugiau nei vieną projektui įgyvendinti reikalingą kompetenciją. Pavyzdžiui, programinės įrangos kūrėjas turi turėti žinių apie testavimą ir verslo analizę. Tai daroma tam, kad dalis komandos „nestovėtų be darbo“ skirtinguose projekto etapuose, o darbuotojai galėtų padėti ir pakeisti vieni kitus.

Be to, komandos nariai turi būti „komandos žaidėjai“, aktyviai prisiimti atsakomybę ir mokėti organizuotis. Rasti tokią brandžią komandą labai sunku!

Scrum netinka visoms komandoms ir organizacijoms dar ir todėl, kad siūlomas procesas gali netikti konkretaus produkto kūrimui – pavyzdžiui, pramoninei mašinai ar pastato statybai.

Liesos

„Agile“ liepia suskirstyti darbą į mažus, valdomus paketus, tačiau nenurodo, kaip valdyti to paketo kūrimą. Scrum siūlo mums savo procesus ir procedūras. Savo ruožtu „Lean“ prie „Agile“ principų prideda darbo eigos diagramą, kad kiekviena iteracija būtų užbaigta tokia pačia kokybe.

Lean, kaip ir Scrum, darbas yra suskirstytas į mažus pristatymo paketus, kurie įgyvendinami atskirai ir savarankiškai. Tačiau Lean programoje yra kiekvieno pristatymo paketo kūrimo darbo eiga, kurios veiksmai yra panašūs į sukurtus projektui Apollo. Kaip ir klasikiniame projektų valdyme, tai gali būti planavimo, kūrimo, gamybos, testavimo ir pristatymo etapai – arba bet kokie kiti etapai, reikalingi kokybiškam projektų įgyvendinimui.

Lean fazės ir jų lankstumas leidžia būti tikriems, kad kiekviena projekto dalis bus įgyvendinta taip, kaip reikia. Lean neturi aiškių etapų ribų, kaip ir Scrum neturi Sprint ribų. Be to, skirtingai nei klasikinis projektų valdymas, Lean leidžia lygiagrečiai atlikti kelias užduotis skirtinguose etapuose, o tai padidina lankstumą ir padidina projekto vykdymo greitį.

Kaip ir „Agile“, „Lean“ yra labiau sąvoka, mąstymo būdas, o ne kažkas, kas įkalta akmenyje. Naudodami Lean idėjas galite savarankiškai sukurti sistemą, atitinkančią jūsų projektų valdymo reikalavimus.

StiprybėsLiesos

Jei jums patinka Agile idėjos, tačiau projektas reikalauja labai pastovios kokybės ir preciziško vykdymo, Lean pateikia įrankių rinkinį šiems reikalavimams patenkinti. Lean derina lankstumą ir struktūrą kaip Scrum, bet šiek tiek kitaip.

Silpnosios pusėsLiesos

Ne kiekviena projekto dalis reikalauja vienodai išsamaus ir kruopštaus tyrimo ir dėmesio. Tačiau Lean prisiima būtent tokį požiūrį į kiekvieną užduotį ir etapą. Tai yra pagrindinis trūkumas naudojant „Lean“ dideliems ir nevienalyčiams projektams.

Be to, skirtingai nei Scrum, Lean nesiūlo aiškios darbo eigos projekto „gabalams“ įgyvendinti, o tai prisideda prie projekto laiko pratęsimo. Šią problemą galima išspręsti efektyviai vadovaujant ir aiškiai bendraujant – svarbiausia atsiminti tai.

Kanbanas

„Lean“ pati savaime atrodo šiek tiek abstrakčiai, tačiau kartu su „Kanban“ ją lengviau naudoti kuriant savo projektų valdymo sistemą. 1953 m. Toyota inžinieriaus Taiichi Ono sukurtas Kanban yra labai panašus į pramoninės gamybos schemą. Į šio proceso įvestį patenka metalo gabalas, o išėjime gaunama baigta dalis. Taip pat „Kanban“ gaminio prieaugis perduodamas iš etapo į etapą, o pabaigoje yra paruošta pristatyti prekė.

Be to, Kanban kūrėją įkvėpė prekybos centrai, būtent jų principas – „lentynose laikykite tik tai, ko reikia klientui“. Todėl „Kanban“ leidžia palikti nebaigtą užduotį viename iš etapų, jei pasikeitė jos prioritetas ir yra kitų neatidėliotinų užduočių. Neredaguotas tinklaraščio straipsnis, įrašas be paskelbimo datos arba funkcijos, kuri gali būti neįtraukta į gaminį, kodo dalis yra normalu Kanban darbui.

„Kanban“ yra daug ne toks griežtas nei „Scrum“ – jis neriboja sprintų laiko, nėra jokių vaidmenų, išskyrus produkto savininką. „Kanban“ netgi leidžia komandos nariui vienu metu valdyti kelias užduotis, o to „Scrum“ neleidžia. Taip pat susitikimai dėl projekto statuso niekaip nereglamentuojami – galite tai daryti jums patogiu metu arba išvis nedaryti.

Norėdami dirbti su Kanban, turite apibrėžti darbo eigos etapus. Kanbane jie vaizduojami kaip stulpeliai, o užduotys vaizduojamos specialiomis kortelėmis. Kortelė juda etapais, tarsi dalis gamykloje juda nuo mašinos prie mašinos, ir kiekviename etape užbaigimo rodiklis tampa didesnis. Dėl to gauname gaminio elementą, paruoštą pristatymui klientui. Lenta su stulpeliais ir kortelėmis gali būti tikroji arba elektroninė – net ir čia Kanban netaiko jokių apribojimų vartotojams.

Jūsų pačių „Kanban“ sistema gali būti tokia lanksti, kokios norite – daugeliu atžvilgių „Kanban“ yra „Agile“ idėjos vizualizacija. Tačiau „Kanban“ turi 4 ramsčius, ant kurių remiasi visa sistema:

1. Kortelės: Kiekvienai užduočiai sukuriama individuali kortelė, kurioje įrašoma visa reikalinga informacija apie užduotį. Taigi visa reikalinga informacija apie užduotį visada yra po ranka.
2. Užduočių skaičiaus viename etape apribojimas: Kortelių skaičius viename etape yra griežtai reglamentuotas. Dėl to iš karto tampa aišku, kada operacijų sraute atsiranda „užstrigimas“, kuris greitai pašalinamas.
3. Nuolatinis srautas: Užduotys iš neatsilikimo pridedamos prie srauto prioriteto tvarka. Taigi darbas niekada nesustoja.
4. Nuolatinis tobulėjimas (Kaizen)kaizen)): Nuolatinio tobulėjimo koncepcija Japonijoje atsirado XX amžiaus pabaigoje. Jo esmė – nuolatinė gamybos proceso analizė ir produktyvumo gerinimo būdų paieška.

StiprybėsKanbanas

Kaip ir „Scrum“, „Kanban“ puikiai tinka gana darnioms komandoms, turinčioms gerą bendravimą. Tačiau skirtingai nei „Scrum“, „Kanban“ neturi griežtų terminų, o tai naudinga motyvuotoms ir patyrusioms komandoms.

Teisingai nustatytas ir valdomas „Kanban“ gali būti labai naudingas projekto komandai. Tikslus komandos darbo krūvio apskaičiavimas, teisingas apribojimų nustatymas ir dėmesys nuolatiniam tobulėjimui – visa tai leidžia Kanban rimtai taupyti išteklius ir laikytis terminų bei biudžeto. Ir visa tai derinama su lankstumu.

Silpnosios pusėsKanbanas

Dažnai galite išgirsti, kad „Kanban“, skirtingai nei „Scrum“, leidžia dirbti su beveik bet kokia komanda. Tačiau taip nėra. Kanban geriausiai tinka komandoms, kurių narių įgūdžiai sutampa. Tokiu būdu jie gali padėti vienas kitam įveikti sunkumus sprendžiant problemas. Be to Kanbanas nebus toks efektyvus, koks galėtų būti. Be to, kaip jau minėta, Kanban geriau tinka tais atvejais, kai nėra griežtų terminų. Jei terminai yra griežti, geriau naudoti klasikinį metodą arba Scrum.

6 sigmos (šešios sigmos)

„Motorola“ kartu su „Toyota“ taip pat prisidėjo prie pasaulinio projektų valdymo plėtros. Bendrovės inžinierius Billas Smithas 1986 metais sukūrė 6 Sigma koncepciją. Tai labiau struktūrizuota Lean nei Kanban versija, kuri prideda daugiau planavimo taupyti išteklius, gerinti kokybę ir sumažinti defektų bei problemų skaičių.

Galutinis projekto tikslas – klientų pasitenkinimas gaminio kokybe, kurį galima pasiekti nuolat tobulinant visus projekto aspektus, remiantis išsamia rodiklių analize. 6 Sigma koncepcija skiria ypatingą dėmesį kylančių problemų šalinimui.

Tam buvo pasiūlytas 5 žingsnių procesas, žinomas kaip DMEDI:

• Apibrėžimas (Apibrėžti): Pirmasis etapas labai panašus į kitų projektų valdymo sistemų ankstyvuosius etapus. Jame nustatomas projekto turinys, renkama informacija apie projekto prielaidas, keliami tikslai.
• Matavimas (Priemonė): 6 Sigma yra orientuota į kiekybinių duomenų apie projektą rinkimą ir analizę. Šiame etape nustatoma, kokie rodikliai lems projekto sėkmę ir kokius duomenis reikia rinkti ir analizuoti.
• Studijuoti (Naršyti): Tyrimo etape projekto vadovas nusprendžia, kaip komanda gali pasiekti užsibrėžtus tikslus ir įvykdyti visus reikalavimus laiku ir neviršijant biudžeto. Šiame etape labai svarbu, kad projekto vadovas spręsdamas iškylančias problemas mąstytų už rėmų ribų.
• Vystymas (Sukurti):Šiame etape įgyvendinami ankstesniuose etapuose priimti planai ir sprendimai. Svarbu suprasti, kad šiame etape jums reikia detalaus plano, kuriame būtų aprašyti visi veiksmai, reikalingi jūsų tikslams pasiekti. Taip pat šiame etape matuojama projekto eiga.
• Kontrolė (Kontrolė): Pagrindinis 6 Sigma metodikos etapas. Pagrindinė jos užduotis – ilgalaikis projektų įgyvendinimo procesų tobulinimas. Šiame etape reikia kruopščiai dokumentuoti išmoktas pamokas, analizuoti surinktus duomenis ir pritaikyti įgytas žinias tiek projektuose, tiek visoje įmonėje.

6 Sigma yra labai panaši į Kanban, tik su nustatytais užduočių įgyvendinimo etapais – planavimu, tikslų nustatymu ir kokybės testavimu. Labiausiai tikėtina, kad naudojant 6 Sigma bus žymiai daugiau komandos susitikimų nei naudojant Kanban, tačiau projekto įgyvendinimo procesas yra labiau struktūrizuotas ir komandai sunkiau nuklysti. Ir, kaip ir Kanban, 6 Sigma gana nesunkiai pritaikoma konkrečios įmonės ar komandos poreikiams. Griežtas reikalavimas yra tik kruopštus projekto rodiklių matavimas ir kontrolė įgyvendinimo etapuose – be to neįmanomas nuolatinis ilgalaikis projekto įgyvendinimo procesų tobulinimas.

6 Sigma stipriosios pusės

6 Sigma koncepcija suteikia aiškią projekto įgyvendinimo ir nuolatinio proceso tobulinimo sistemą. Apibrėždami tikslus, tada atidžiai juos analizuodami ir peržiūrėdami, gausite kiekybinių duomenų, kad geriau suprastumėte projektą ir priimtumėte geresnius sprendimus. Nors duomenų rinkimas, analizavimas ir pamokų rengimas gali užtrukti, tai pagerins ir optimizuos projektų įgyvendinimo procesus ir taip sutaupys resursus ateityje.

6 Sigma tinka sudėtingiems projektams, apimantiems daug naujų ir sudėtingų veiklų. Toks požiūris leidžia įgyvendinti projekto elementus, mokytis iš klaidų ir gerinti kokybę ateityje.

6 Sigma trūkumai

6 Sigma problema yra ta, kad nors pagrindinis deklaruojamas tikslas yra sumažinti išlaidas ir padidinti efektyvumą, dažnai iškyla klientų pasitenkinimas. Atsižvelgiant į kai kuriuos tikslus skirtinguose projekto etapuose, komandos dažnai susipainioja dėl prioritetų, o to išvengti nėra lengva.

Be to, pagrindinis „6 Sigma“ leitmotyvas yra: „Visada viską galima padaryti dar geriau“. Tai gali demotyvuoti darbuotojus, kurie nesijaučia patenkinti savo darbu. Be to, jei projektas yra vienkartinis ir įmonė neplanuoja įgyvendinti panašių projektų ateityje, visos analizės ir pamokų mokymosi išlaidos gali būti veltui.

PRINCAS2

NASA nėra vienintelė vyriausybinė organizacija, prisidėjusi prie projektų valdymo plėtros. Didžiosios Britanijos vyriausybė jau seniai vertina projektų valdymo efektyvumą, todėl 1989 metais buvo sukurta britų PRINCE2 metodika. Pavadinimas kilęs iš akronimo " PR objektus IN C kontroliuojamas E aplinkos versija 2 “, o tai reiškia „Projektai valdomoje aplinkoje, 2 versija“. Skirtingai nuo judrių metodų, PRINCE2 nesiima kartotinio požiūrio į projektą. Jei PRINCE2 lyginsime su kitais produktais, tai jį galima palyginti su klasikinio požiūrio į projektų valdymą ir 6 Sigma dėmesio kokybei hibridu.

PRINCE2 metodika, skirtingai nei, pavyzdžiui, PMBOK žinių visuma, neapima:

• Specializuoti projektų valdymo aspektai, pavyzdžiui, specifiniai pramonės šakai;
• Konkreti projektų valdymo praktika ir įrankiai, pvz., Ganto diagrama, WBS ir kt.

PRINCE2 orientuojasi į projekto valdymo aspektus, išreikštus 7 principais, 7 procesais ir 7 projekto temomis.

• 7 principai apibrėžia bendrąsias projektų valdymo pagal PRINCE2 taisykles, apibrėžia metodikos pagrindus;
• 7 procesai apibrėžia žingsnius pažangai per projekto ciklą;
• 7 temos – aspektai, kurie stebimi siekiant projekto sėkmės.

Projekto pradžioje PRINCE2 prašo mūsų apibrėžti 3 pagrindinius projekto aspektus:

• Verslo aspektas (ar šis projektas duos naudos?)
• Vartotojo aspektas (kokio produkto reikia, ką darysime?)
• Išteklių aspektas (ar turime pakankamai, kad pasiektume savo tikslą?)

PRINCE2 turi aiškiau apibrėžtą projekto komandos struktūrą nei dauguma projektų valdymo metodų. Taip yra dėl to, kad PRINCE2 yra orientuotas į didelio masto vyriausybės projektus ir dideles organizacijas.

Pagal PRINCE2, kiekvienas komandos narys turi aiškų vaidmenį kiekviename iš 7 procesų:

• Projekto pradžia (Pradėtiing aukštyna projektą): Šio proceso metu paskiriamas projekto vadovas ir nustatomi bendri gaminio veikimo reikalavimai. Projekto vadovas, kurio pagrindinis dėmesys skiriamas detalėms, atsiskaito projekto valdymo komitetui, kuris yra atsakingas už bendrą projekto valdymą. Iniciatyvinis komitetas užtikrina, kad projektas tęstųsi, ir galiausiai yra atsakingas už projekto sėkmę.
• Projekto inicijavimasa projektą): Šio proceso metu projekto vadovas parašo „Projekto inicijavimo dokumentą“, kuriame pateikiamas etapinis projekto planas. Etapai gali trukti skirtingą laiką, tačiau, kaip ir klasikiniame požiūryje, jie eina griežtai vienas po kito.
• Projektų valdymas (Directing a projektą): Šis procesas leidžia Valdymo komitetui prisiimti bendrą atsakomybę už projekto sėkmę, nesiveliant į smulkmenas, kurios priklauso projekto vadovo kompetencijai.
• Scenos kontrolėmolva a etapas): Įgyvendinant projektą, net ir esant idealioms sąlygoms, bus atlikti tam tikri pakeitimai. Stage Control procesas įgyvendina vieną iš PRINCE2 principų – valdymo išimties tvarka principą. Projekto vadovo pareiga yra stebėti nukrypimus nuo numatytų projekto parametrų, susijusių su terminais, turiniu, biudžetu ir pan.. Jeigu šie nukrypimai viršija Iniciatyvinio komiteto projekto vadovui suteiktus įgaliojimus ( PRINCE2 terminologijoje – tolerancijos), projekto vadovas privalo informuoti Iniciatyvų komitetą ir pasiūlyti būdus, kaip išeiti iš susidariusios situacijos.
• Produkto kūrimo valdymas (Valdymas Produktas Pristatymas): Produkto kūrimo valdymo procesas yra projekto vadovo ir komandos vadovo sąveika kuriant vieną iš projekto produktų. Projekto vadovo pareigos šiame procese apima įgaliojimų sukurti produktą delegavimą komandos vadovui ir sukurto produkto priėmimą.
• Etapo ribų valdymas (vading a etapas riba): Šio proceso metu projekto vadovas pateikia Valdymo komitetui visą reikalingą informaciją, kad būtų galima įvertinti baigto etapo rezultatus ir priimti sprendimą dėl perėjimo į kitą etapą.
• Projekto užbaigimas (uždarymasa projektą): Vienas iš PRINCE2 skirtumų yra tas, kad projekto užbaigimo procesas nėra išskiriamas į atskirą etapą ar etapą, kaip taikant klasikinį požiūrį, o vykdomas kaip galutinio produkto kūrimo etapo dalis. Proceso tikslas – patvirtinti, kad projekto produktas buvo priimtas arba projektas nebegali suteikti nieko naudingo.

PRINCE2 gali būti pritaikytas bet kokio dydžio ir bet kokios temos projektams. Metodikoje pateikiamos konkrečios rekomendacijos, kaip pakeisti projekto gyvavimo ciklą, pavyzdį ir privalomų dokumentų rinkinį pagal projekto poreikius.

Privalumai PRINCE2

• Prisitaikymas prie organizacijos savybių;
• Galimybė turėti aiškų vaidmenų ir pareigų pasiskirstymo aprašymą;
• Dėmesys projekto produktams;
• Tam tikri valdymo lygiai;
• Dėmesys ekonominiam pagrįstumui;
• Projektavimo darbų seka;
• Dėmesys patirties kaupimui ir nuolatiniam tobulėjimui.

PRINCE2 trūkumai

• Pramonės praktikos trūkumas;
• Trūksta specialių įrankių darbui projekte.

Geriausia projektų valdymo sistema... Jums!

Projektų valdymas yra mokslas, bet tai nėra tikslusis mokslas. Šioje srityje nėra nepajudinamų pamatų ar universalių sprendimų. Jei pavyksta rasti metodą, kuris idealiai tinka jūsų projektui, įvertinkite, kad jums labai pasisekė, nes dauguma mažiau pasisekusių vadovų turi įdėti pastangų kurdami ir konfigūruodami savo projektų valdymo sistemas. Šios sistemos gali būti sudarytos iš esamų sistemų elementų arba netgi sukurtos visiškai nuo nulio, kaip buvo „Apollo“ misijos atveju. Svarbiausia yra naudoti tai, kas suteiks bent šiek tiek struktūros ir leis prisiminti, kas svarbu jūsų projektui.

Projektų valdymo teorija, kaip mokslas, atsirado XX amžiaus antroje pusėje, nors jos užuomazgų galima rasti statant Egipto piramides. Valdymo krizė biurokratinėse organizacinėse struktūrose, įmonių nesugebėjimas greitai ir adekvačiai reaguoti į išorinės aplinkos pokyčius, sprendžiamų užduočių sudėtingumas ir įvairovė lėmė projektų valdymo poreikio suvokimą.

Naujo požiūrio į valdymą praktinio įgyvendinimo postūmis buvo šeštojo dešimtmečio antroje pusėje JAV sukurti tinklų planavimo metodai ir technikos. XX amžiuje Tačiau projektų valdymo teorija plačiai paplito tik atsiradus asmeniniams kompiuteriams ir kuriant specializuotas programas. Šiandien be projektų valdymo nebeįsivaizduojama inovatyvių įmonių veikla, didelių tarptautinių programų įgyvendinimas statybos, erdvės plėtros ir daugybės kitų srityse. Projektų valdymas sukuria pranašumus, reikalingus verslui sėkmingai veikti konkurencingoje rinkos aplinkoje.

Projektų valdymas užsienyje

Kaip viskas prasidėjo

Projektų valdymo metodų kūrimo pradžia gali būti siejama su 1917 m. Būtent tuo metu Ganto kūryba tapo plačiai paplitusi. Kitas žingsnis buvo amerikiečių mokslininko Gulicko (1937) sukurta matricinė organizacinė struktūra, kuri padidino sudėtingų projektų įgyvendinimo efektyvumą. Tokiu būdu buvo ruošiamasi pereiti nuo biurokratinių organizacinių struktūrų prie lankstesnių, adaptyvių, kurios labiau atspindėjo projektų valdymo specifiką.

40-ieji

40-aisiais XX amžiuje Projekto įgyvendinimas vis dar vyko linijinėse organizacinėse struktūrose. Šioje sistemoje projektas palaipsniui perėjo nuo vieno tiesioginio vadovo atsakomybės prie kito. Norėdamas gauti operatyvinę informaciją apie projekto įgyvendinimą užsakovas turėjo susirasti tiesioginį vadovą, kuris tuo momentu buvo atsakingas už projektą. Mažiems projektams tai buvo paprasta, tačiau augant projekto mastui ir sudėtingumui gauti operatyvinės informacijos tapo vis sunkiau, juolab kad anksčiau projektą vykdę tiesioginiai vadovai nebeatsako už rezultatą.

50-ieji

50-aisiais XX amžiuje Nuo Šaltojo karo pradžios JAV strateginis tikslas buvo užtikrinti karinį pranašumą prieš SSRS. Gynybos ministerijai tapo akivaizdu, kad tradicinės valdymo sistemos rėmuose neįmanoma susidoroti su tokiomis užduotimis kaip strateginio bombonešio B52, povandeninio laivo „Polaris“ kūrimas ir kt. viso projekto. Tokiu žmogumi tapo projekto vadovas.

Iki šeštojo dešimtmečio pabaigos. Projektų valdymo teorija sulaukė pripažinimo daugelyje NASA ginklų ir kosmoso projektų. Vykdydami šiuos projektus užsakovai reikalavo, kad tiekėjai ir rangovai taip pat naudotų projektų valdymo priemones. Tačiau projektų valdymo įtaka kitoms verslo veiklos sritims vis dar nebuvo reikšminga.

Projektų valdymas vystėsi atsižvelgiant į klientų poreikius. Vyriausybės vykdomuose projektuose rangovų ir subrangovų skaičius buvo toks didelis, kad reikėjo sukurti projekto dalyvių sąveikos metodus, etapus ir standartus. Įvesta planavimo pagal gyvavimo ciklo etapus praktika, suformuotos sąnaudų kontrolės ir stebėsenos sistemos ir kt. Vyriausybei reikėjo užtikrinti, kad valstybės lėšos būtų naudojamos tikslingai ir efektyviai, visiškai laikantis planų. Tuo pačiu metu privačios įmonės projektų valdymo išlaidas suvokė kaip pridėtines išlaidas ir nematė jokios praktinės prasmės naudoti tokias teorijas, kurios jų požiūriu nebuvo veiksmingos.

60-ieji

60-aisiais XX amžiuje įmonių vadovai pradėjo suvokti būtinybę sukurti valdymo sistemą ir organizacinę struktūrą, adekvačią sparčiai besikeičiančioms išorinės aplinkos sąlygoms. Ir kuo sudėtingesni uždaviniai buvo keliami įmonėms, tuo didesnį poreikį jautė vadovai naujai valdymo sistemai. Iki 60-ųjų pabaigos. projektų valdymas tapo nepakeičiamu atributu tokiose dinamiškose veiklos srityse kaip statyba, aukštųjų technologijų įrangos plėtra, informacinės technologijos, gynybos pramonė ir kt.

Tačiau net jei įmonės pripažino projektų valdymo teoriją, projektų valdymo procesų pobūdis išliko neformalus. Linijinėse organizacinėse struktūrose, gaminant žemų technologijų produktus, projektus valdė funkciniai vadovai. Toks požiūris buvo priimtinas, atsižvelgiant į santykinį atliekamų užduočių paprastumą ir gerą vadovų bendravimą.

70-80 metų

70-aisiais - 80-ųjų pradžioje. XX amžiuje Kai kurios įmonės suprato į projektus orientuoto požiūrio į projektų valdymą poreikį dėl atliekamo darbo masto ir sudėtingumo, taip pat dėl ​​to, kad esamoje tradicinio ar neformalaus projektų valdymo sistemoje neįmanoma išspręsti susikaupusių problemų. Iki to laiko buvo daug publikacijų projektų valdymo klausimais, o įmonės galėjo nustatyti, kuriose veiklos srityse reikalingas į projektus orientuotas požiūris į projektų valdymą.

Pradinis perėjimas nuo tradicinio valdymo prie projektinio valdymo vidutiniškai trunka 2–3 metus. Šį laikotarpį lėmė organizacinės struktūros pokyčiai, teisių ir pareigų pasiskirstymas įmonėje bei kiti pokyčiai, kurių dauguma yra susiję su darbuotojų ir vadovų elgesiu.

90-ieji

90-aisiais XX amžiuje Daugelis įmonių suprato, kad projektų valdymas yra gyvybiškai svarbus siekiant užtikrinti veiklos konkurencingumą. Individualioms įmonėms projektų valdymo įgyvendinimo problemos sprendimas tapo vienu iš rimčiausių iššūkių.

Pradiniame etape įmonė suvokia, kad reikia įgyvendinti projekto valdymą. Dažniausiai tai vyksta žemesniajame ir viduriniame lygmenyse, kur vyksta praktinis projektų įgyvendinimas. Tada ši situacija įvertinama, o gauta informacija perduodama aukščiausio lygio vadovybei.

Įjungta aukščiausios vadovybės sprendimų priėmimo fazė perėjimas prie projektų valdymo turi būti oficialiai paskelbtas ir įmonės vadovybės remiamas. Įjungta priėmimo fazė pagal linijos vadovybę parama turėtų būti skirta naujai tiesioginių vadovų valdymo sistemai diegti. Įjungta augimo fazė Kuriama projektų valdymo metodika – vyksta planavimas, kontrolė, taikomų kompiuterinių programų parinkimas. Įjungta brandos fazėįmonė taiko ankstesniame etape įdiegtas projektų valdymo priemones.

Pastaraisiais metais projektų valdymas vis daugiau laiko skiria vidinio keitimosi informacija plėtrai, kompiuterių taikomųjų programų apimčių išplėtimui, valdymo metodų ir priemonių tobulinimui. Noras standartizuoti šios srities metodiką lemia, kad artimiausiu metu bus sukurti pasauliniai projektų valdymo standartai.

Projektų valdymas SSRS ir Rusijoje

Vėlyva pradžia

Projektų valdymo teorija Rusijoje pradėta taikyti paskutiniame XX amžiaus dešimtmetyje, nors kai kurie jos elementai buvo naudojami dar gerokai prieš tai. Tyrėjai pastebi, kad kai kurios projektų valdymo priemonės Rusijoje atsirado 1930-aisiais. Perėjimas prie tos pačios rūšies serijinės gamybos užtikrino srautinio darbo organizavimo plėtrą įgyvendinant būsto statybos projektus.

Srauto gamybos teorijos tobulinimas prisidėjo prie kitų projektų valdymo elementų kūrimo Rusijoje. Tuo metu planavimo ir valdymo pagrindas buvo Ganto modeliai ir ciklogramos, taip pat jų skaičiavimo ir optimizavimo metodai. Iš sovietų mokslininkų, prisidėjusių kuriant nepertraukiamos gamybos statybose teoriją ir organizavimą, galima išskirti O. A. Wutke (1932), M. V. Vavilovą (1932–1942), A. V. Baranovsky (1936), A. A. Garmash (1939), V. I. Baturina (1940–1949), M. S. Budnikova (1941–1962), E. I. Varenik (1956–1963) ir kt.

Pasirodžius publikacijoms apie JAV sukurtus tinklo metodus, nemažai sovietų mokslininkų, tarp kurių galima pavadinti S. P. Nikanorovą (1961–1962), A. I. Teimaną (1963), Yu. A. Avdejevą (1963), paskelbė pirmąjį. buitinių darbų šia tema. 1971–1974 metais G. M. Adelsonas-Velskis, V. I. Voropajevas ir M. V. Šeinbergas sukūrė apibendrintus tinklo modelius (GNM), kurie turi tam tikrų pranašumų, palyginti su Vakarų analogais, aprašydami sudėtingus projektus su įvairiais ryšiais tarp darbų ir įvairių tipų laiko apribojimų.

Tuo pat metu D. I. Golenko (1968–1973), K. A. Antonavichyus (1971) ir S. I. Livshits (1971) sukūrė stochastinius ir alternatyvius modelius, kuriuose buvo atsižvelgta į atskirų projekto komponentų tikimybinį pobūdį.

Šie projektų valdymo įrankiai, vadinami tinklo planavimo ir valdymo metodais (NPC), buvo plačiai naudojami nuo 1970 m. Iki 1975 m. SPM metodai buvo naudojami 17–18% statybos projektų. Tinklo metodų kūrimas buvo glaudžiai susijęs su kompiuterių tobulėjimu. Pirmosios elektroninės kompiuterinės sistemos projektų valdymui 1970 m. apėmė laiko ir sąnaudų analizę, optimizuojant laiką ir darbų kainą. Čia ypač domina V. I. Sadovskio (1965), A. A. Avdejevo (1968–1975), E. E. Abelio (1969), N. V. Skrydlovo (1974) ir kt.

Sąvokų pakeitimas

SSRS visada buvo itin svarbus plano, o ne atskirų projektų įgyvendinimas, todėl SPU panaudojimas atskiriems objektams davė tik vietinį efektą, o kai kuriais atvejais lėmė pagrindinių rodiklių pablogėjimą. . Aštuntojo dešimtmečio viduryje. išryškėjo poreikis integruoti SPU panaudojimą organizuojant visos įmonės veiklą. Nuo individualių projektų valdymo buvo palaipsniui pereita prie įmonės veiklos valdymo. Tuo pačiu metu pasirodė pirmosios kelių projektų valdymo programinės įrangos sistemos: „Calibration-2“ (NIIASS Gosstroy, Ukrainos SSR, Kijevas, direktorius V.I. Sadovskis, 1965–1968), „AKKORD“ (Sibiro hidrodinamikos institutas). SSRS mokslų akademijos filialas, Kijevas). Novosibirskas, direktorius Yu. A. Avdeev, 1971–1976) ir kt.

Devintajame dešimtmetyje buvo toliau plėtojamas kelių projektų valdymas. sukūrus automatizuoto valdymo sistemas (AVS) įvairių šalies ūkio sektorių įmonėms. Automatizacija įvyko įvairiose projektų valdymo srityse: projektavimo (CAD), gamybos paruošimo, procesų valdymo (APCS), apskaitos ir kt.

Kitas vidaus projektų valdymo sistemų kūrimo etapas buvo integruotų sistemų, kuriose visi projekto kintamieji sąveikauja vienoje informacinėje aplinkoje, sukūrimas. Šioje aplinkoje vyko informacijos srautų formalizavimas ir analizė naudojant kompiuterius. Didėjantis atliekamų užduočių sudėtingumas ir centralizuotoje ekonomikoje priimamų sprendimų įtakos sferos plėtra lėmė, kad 1980 m. integruotos automatizuotos valdymo sistemos (IACS). Integracijos procesas vyko dviem kryptimis – horizontalia, susijusia su gaminio gamyba, ir vertikalia, teikiančia sistemų valdymą.

Tyrinėdamas valdymo procesų sudėtingumą, profesorius V. V. Pozdnyakovas (1981) suformulavo bendrą šio proceso modelį kaip „koordinavimo atsilikimą nuo gamybos ir valdymo funkcijų specializacijos“ tokiose sistemose. Jis taip pat pasiūlė vieną iš būdų, kaip įveikti tokį atsilikimą, remiantis projektų valdymo metodika (1991). Šiandien automatizuotos valdymo sistemos kūrimo patirtis yra daugelio projektų valdymo sistemų diegimo ir konfigūravimo pagrindas.

1990 metų pabaigoje SSRS buvo įkurta Sovietų projektų valdymo asociacija (SOVNET), kuri tapo Tarptautinės projektų valdymo asociacijos (IPMA) nare. Nuo to laiko pradėtos kurti projektų valdymo priemonės ir priemonės, kurios atsižvelgė į buitinę įmonių finansinės ir ekonominės veiklos specifiką. Sovietmečiu Rusijos projektų valdymo sėkmė (ASU, IASU) buvo siejama su įmonių finansine-ūkine veikla, nukreipta į valstybę. Pereinant prie rinkos santykių, reikėjo keisti projektų valdymo sistemų plėtros vektorių. Šiuo atžvilgiu ypač vertinga buvo turtinga Vakarų patirtis kuriant profesionalias projektų valdymo sistemas. Todėl vietinių projektų valdymo įrankių kūrimas vyko dviem keliais:

1. Savo įrankių, taikomųjų kompiuterinių programų ir kt., įskaitant pagrįstus automatizuotomis valdymo sistemomis ir automatizuotomis valdymo sistemomis, kūrimas.
2. Vakarietiškų įrankių pritaikymas Rusijos ekonomikos valdymo specifikai.

Šiandien, kai Rusija tapo pasaulinės bendruomenės dalimi, projektų vadovai prisidėjo prie šios profesinės veiklos srities plėtros mūsų šalyje. Rusijos specialistai dalyvauja tarptautiniuose projektų valdymo forumuose, kongresuose ir konferencijose, o tai prisideda prie šiuolaikinių žinių kaupimo ir keitimosi patirtimi šiose srityse pasauliniu mastu.

Per pastaruosius 10 metų projektų valdymas sulaukė daugelio Rusijos įmonių vadovų pripažinimo. Ir tai nenuostabu – juk iš projektų valdymo perspektyvos galima ne tik svarstyti beveik bet kokią kryptingą veiklą, bet ir pasiekti padidintą pastarosios efektyvumą naudojant patikrintus metodus ir priemones. Taigi, projektinės pramonės šakose (statybos, novatoriškos plėtros, programinės įrangos ir kt.) efektyvumas žymiai padidėja! Šiuolaikinėje Rusijos rinkos ekonomikoje projektų valdymas tampa būtinu veiksniu, užtikrinančiu daugelio įmonių konkurencinį pranašumą.

Peržiūrų: 5 494

1 tema. Pagrindinės projektų valdymo sąvokos

Paskaitos metmenys

Būtinos sąlygos pereiti prie projektų valdymo. Projektų valdymo metodų kūrimo raida. Projektų valdymo plėtros etapai Rusijoje.

2.Pagrindinės projektų valdymo sąvokos.

Projekto samprata ir projektų valdymas. Išskirtiniai projekto bruožai. Skirtumas tarp projekto ir programos.

Projekto aplinka.

Projekto gyvavimo ciklas.

Projekto klasifikacija

Projekto dalyviai.

Projektų valdymo programinės įrangos pasirinkimas

Projektų valdymo metodo ir jo sampratos raidos istorija

Kodėl tai svarbu ( skaidrė ) :

30% projektų žlunga

53% projektų baigiami vidutiniškai 1,9 karto viršijus biudžetą

Tik 16 % projektų įgyvendinami laiku ir neviršija biudžeto

Pagrindinių terminų ir profesinės kalbos žinios būtinos norint suprasti teorinius projekto valdymo pagrindus ir praktiniam tarpusavio supratimui projekte.

Futrell teigimu, 17% programinės įrangos projektų nesėkmių paaiškinama tuo, kad vėlesniuose etapuose kūrėjai atranda skirtingą reikšmę kasdieniniams reikalavimams ir terminams, dėl kurių „sutardavo“.

Šiuolaikinė organizacija gali egzistuoti ir sėkmingai konkuruoti rinkoje tik nuolat tobulėjanti ir prisitaikanti prie kintančių verslo sąlygų. Šiuolaikinio gyvenimo ritmo pagreitėjimas didina įmonių funkcionavimo nestabilumą, verčia vykdyti dažnas ir greitas transformacijas, prisitaikyti prie išorinių sąlygų. Projekto veikla leidžia mums susidoroti su šia užduotimi.

Naujo požiūrio į valdymo objektą pagrindas – projektų valdymo koncepcija, kuri dabar tapo visose išsivysčiusiose šalyse pripažinta investicinės veiklos vykdymo metodika.

(skaidrė ) Projektų valdymas užsienyje atsirado praėjusio amžiaus 30–50-aisiais. 1937 m. amerikiečių mokslininkas L. Gulickas sukūrė pirmąją matricinę organizacinę struktūrą, skirtą sudėtingiems projektams valdyti ir įgyvendinti. Pirmą kartą visiškai praktiškai pritaikytas 1953–1954 metais JAV karinių oro pajėgų bendrų projektų padaliniuose, specialiųjų ginklų projektuose, o 1955 metais – JAV karinio jūrų laivyno Specialiųjų projektų skyriuje.

(skaidrė ) 70-aisiais buvo tęsiamas tinklų planavimo ir valdymo sistemų kūrimas ir diegimas. Taigi, tinklo analizės technika ir jos kompiuterinės programos pirmą kartą pristatomos JAV mokymo įstaigose kaip privalomi inžinerijos dalykai.

Metodai ir įrankiai kuriami remiantis sisteminiu požiūriu ir sistemų teorija, efektyviai naudojami struktūrizuojant problemas ir optimizuojant tikslų nustatymo funkcijas.

Pažangūs sistemų analizės metodai taikomi valdymo sprendimų efektyvumo didinimo srityje įgyvendinant pačius įvairiausius projektus. Projektų valdymo metodika sėkmingai apima žaidimų teorijos metodus, sprendimų medžio metodus ir kitas sprendimų analizės priemones neapibrėžtumo ir rizikos sąlygomis.

(skaidrė ) Devintajame dešimtmetyje buvo suvoktas didelis partnerystės ir koordinuoto projekto komandos darbo vaidmuo ir svarba. Rizikos valdymas įvardijamas kaip nepriklausoma projektų valdymo disciplina.

Galiausiai, ketvirtos kartos kompiuteriai ir jų pagrindu sukurtos naujos informacinės technologijos leidžia efektyviau panaudoti projektų valdymo metodus ir įrankius tokiems tikslams kaip planavimas, planavimas, kontrolė, laiko, sąnaudų, išteklių analizė ir kt. pradėtas plačiai naudoti ne tik didelėse, bet ir vidutinėse bei mažose įmonėse.

Intensyviai plėtojama veikla, skirta nustatyti ir apibendrinti geriausią projektų valdymo patirtį. 1987 metais JAV buvo išleistas kolektyvinis Amerikos projektų valdymo instituto (PMI) narių darbas „Project Management Body of Knowledge“ (PMBoK, paskutinis leidimas išleistas 2013 m.), kuriame buvo įvardyta vieta, kur vaidmuo ir struktūra. projektų valdymo metodai ir priemonės bei jų indėlis į bendrą valdymą.

Projektų valdymas pagaliau iškilo kaip tarpdisciplininė profesinės veiklos sritis.

(skaidrė ) Dešimtajame dešimtmetyje buvo toliau kuriamos naujos projektų valdymo sritys, kurios apėmė:

tobulinti į projektus orientuotų organizacinių struktūrų kūrimo ir įgyvendinimo metodus;

projektų valdymo taikymo netradicinėse srityse galimybių ir naudingumo suvokimas; socialinėje ir ekonominėje srityje; dideli tarptautiniai projektai ir kt.;

tiria projektų valdymo panaudojimo viešojo administravimo ir tarpvalstybiniuose bei viešuosiuose tarptautiniuose projektuose ir programose galimybes;

tarptautinių ir nacionalinių projektų vadovų sertifikavimo programų kūrimas ir įgyvendinimas;

globalizacijos, unifikavimo ir standartizavimo procesų projektų valdymo srityje poreikio ir galimybės suvokimas, taip pat jų įgyvendinimo pradžia;

naujų standartų projektų valdymo srityje kūrimas, įskaitant standartą „Projektų valdymo sistemos brandos lygiai“;

naujų informacinių technologijų kūrimo ir naudojimo projektų valdyme, remiantis pasauliniu kompiuterių tinklu internetu, pradžia;

intensyvus projektų rizikos valdymo metodų kūrimas;

Projekto personalo valdymo tobulinimas remiantis šiuolaikiniais socialinių ir psichologinių mokslų pasiekimais, pirmiausia pasiekimais komandos valdymo srityje.

Projektų valdymas Rusijoje atsirado 1930-aisiais industrializacijos laikotarpiu. Tuo metu sovietų valstybė ėmėsi daugybės precedento neturinčių projektų, tokių kaip Dniepro hidroelektrinė, visos Rusijos elektrifikacijos sistemos statyba, anglies ir geležies rūdos telkinių plėtra, didelių teritorinių pramoniniai kompleksai.

Prieškariu buvo sukurta ir įgyvendinta nemažai didelių programų, kurios suvaidino svarbų vaidmenį šalies industrializacijoje.

Tarp jų galima paminėti Turksibo statybą, Volgos regiono naftos turtų plėtrą, metalurgijos bazės sukūrimą šalies rytuose, „Didžiosios Volgos“ statybą, Uralo-Kuznecko sukūrimą. kompleksas ir kt.

Tokia veikla reikalavo aukšto organizuotumo lygio.

Remiantis šiais pirmaisiais augančios pramoninės statybos patirtimis, šalyje buvo sukurta srauto teorija, kuri tapo šiuolaikinio mokslinio darbo ir gamybos valdymo organizavimo pagrindu. Serijinės gamybos augimas, visų pirma būsto statybos srityje, prisidėjo prie nuolatinio statybos projektų įgyvendinimo darbų organizavimo teorijos ir praktikos kūrimo. 1931 m. Izmailovskio kaime (Maskva), paskui Dachnoe kaime (Leningrade) ir Kemerove in-line metodu buvo sėkmingai pastatyti nauji gyvenamųjų namų kvartalai.

Visiškai užtikrintai galima teigti, kad projektų valdymo pamatai Rusijoje buvo padėti nuo 30-ųjų iki 60-ųjų pradžios. Projekto įgyvendinimo planavimas ir kontrolė šiuo laikotarpiu remiasi deterministiniais tiesiniais Ganto modeliais, ciklogramomis bei grafinių-analitinių metodų panaudojimu jų skaičiavimui ir optimizavimui.

Tinklo planavimo ir valdymo metodų diegimas ir tobulinimas (60 m.).

Šiuolaikinių projektų valdymo metodų kūrimas SSRS prasidėjo 1959 m., kai pasirodė pirmieji amerikiečių leidiniai apie tinklo metodus (CPM ir PERT).

70-ųjų pradžioje buvo sukurti originalūs tinklo modeliai, lankstesni ir galingesni nei jų užsienio kolegos. Kartu buvo tobulinami alternatyvių tinklo modelių kūrimo metodai.

Projektų valdymo programinės įrangos sistemų kūrimas (70 m.).

Tinklo planavimo ir valdymo metodų naudojimas iš pradžių buvo glaudžiai susijęs su kompiuterių naudojimu. Pirmosios projektų valdymo programinės įrangos sistemos, pasirodžiusios SSRS 70-ųjų pradžioje, savo laiku buvo gana progresyvios. Jie galėjo atlikti laiko ir sąnaudų analizę, įskaitant darbo ir projektų laiko ir sąnaudų optimizavimą, taip pat išspręsti išteklių paskirstymo problemas ir buvo pagrįsti originaliomis idėjomis ir algoritmais. Visų pirma, buvo sukurta keletas euristinių išteklių paskirstymo algoritmų. Šie algoritmai turėjo galimybę mokytis savarankiškai ir buvo aprūpinti patogia vartotojo sąsaja; jų pagalba buvo galima atlikti sudėtingų situacijų loginę analizę. Panašūs algoritmai vis dar gali būti naudingi kuriant projektų valdymo sistemas.

Buvusiai SSRS buvo būdingas visos organizacijos tikslų vyravimas prieš atskirų projektų įgyvendinimo tikslus, todėl tinklo planavimo ir valdymo naudojimas atskiruose objektuose davė lokalų efektą ir dažnai neigiamai paveikė bendrus organizacijos plano įgyvendinimo rezultatus. . Tapo aišku, kad būtina visus pagal organizacijos programą vykdomus projektus ir užsakymus aprėpti tinklo planavimu ir valdymu, siekiant visapusiškiau ir efektyviau panaudoti jos pajėgumus, darbo ir materialinius išteklius ir taip užtikrinti geresnį plano įgyvendinimą. . Plano prioritetas buvo didesnis nei individualaus projekto prioritetas.Štai kodėl aštuntojo dešimtmečio viduryje projektų valdymo raida palaipsniui perėjo nuo pavienių projektų valdymo prie visos organizacijos, vykdančios daug projektų vienu metu, veiklos valdymo. Tada buvo pirmosios programinės įrangos sistemos, skirtos kelių projektų valdymui. Jie apima: "Kalibravimas-2"(NIIAS Gosstroy iš Ukrainos TSR, Kijevas, vadovas V.I. Sadovskis, 1965 m. 1968), "Planas"(NIIES Gosstroy ESSR, vadovai L. G. Golubas, E. N. Lyašenko ( 1972–1976 m).

Programos-tikslinis valdymas (80s).

Sisteminio požiūrio pagrindu 80-aisiais Sovietų Sąjungoje buvo sukurta programos-tikslinio valdymo koncepcija, kurią galima laikyti visaverčiu projektų valdymo analogu, kuris tuo metu vystėsi užsienyje. Tam tikri šios koncepcijos metodai ir priemonės buvo veiksmingesni už užsienio sprendimus.

Programos-tikslinis valdymas apėmė ir valstybės ūkio valdymą, ir konkrečių projektų įgyvendinimą. Tuo metu vyravusio centralizuoto požiūrio į valdymą dėka buvo sukurta efektyvi įvairių ekonomikos valdymo lygių tikslų integravimo sistema.

Per tą patį laikotarpį Maskvos vadybos instituto specialistai sukūrė pagrindines projektų valdymo organizacines priemones, kurios buvo sėkmingai išbandytos įgyvendinant įvairaus masto ir turinio projektus. Sukurtos tokios priemonės kaip tinklo matricos, informacinių technologijų modeliai (tuo metu vadinti loginėmis informacijos diagramomis), administracinio valdymo užduočių skirstymo matricos.

Praktinio į programą nukreipto požiūrio taikymo rezultatas buvo daugybė tikslinių kompleksinių programų (TCP), skirtų integruoti teritorinius, sektorinius ir tikslinio valdymo principus sprendžiant nacionalines problemas.

Rusijos įėjimas į pasaulinę projektų valdymo bendruomenę (90-ieji – dabar).

90-ųjų pradžioje Rusija pateko į „projektų valdymo pasaulį“ ir tapo visateise projektų valdymo bendruomenės nare. Visos pasaulinės projektų valdymo plėtros tendencijos vienaip ar kitaip pradėjo reikštis mūsų šalyje.

Iki šiol projektų valdymas tapo pripažinta investavimo metodika visose išsivysčiusiose šalyse. Tačiau projektų valdymas tapo tikrai savarankiška disciplina dėl žinių, gautų tiriant bendruosius projektams būdingus modelius visose veiklos srityse, taip pat metodų ir priemonių, sėkmingai taikomų įvairiems projektams (1 lentelė). ( skaidrė )

1 lentelė Projektų valdymo metodų raida