Projekti plaan. Projekti planeerimine. Põhimõisted. Ressursiplaneerimise tunnused

Projektijuhtimine on sümbioos tehnoloogiast ja unikaalse ülesande õigeaegse lahendamise kunstist selleks eraldatud eelarve piires. Projekti edukaks lõpuleviimiseks on vaja saavutada ettevõtte juhtkonna ja RM-i vahel arusaam, kuidas seda ellu viia, kes, millal ja milliseid töid peab tegema. Projektiplaani ei käsitleta kui üht dokumenti, vaid kui tervet dokumenteeritud lahenduste komplekti, mis vastavad ülaltoodud küsimustele. Esitan teie tähelepanu ülevaateartiklile, mis uurib projekti planeerimise tehnoloogia põhitõdesid.

Projekti planeerimise olemus

Projekti planeerimine hõlmab paljusid omavahel seotud iteratsioone, mille tulemuseks on ühtne üldplaan. Projektiplaani kaudu mõistame paremini kavandatud tegevuste süsteemi, mis on dokumenteeritud koostamise tulemusena. See süsteem koosneb erilisel viisil ühendatud parameetritest, mis tagavad eraldi arendusprobleemi lahendamise. Need parameetrid moodustatakse projektitegevuse mitmete funktsionaalsete valdkondade põhjal:

• sisu;
• tähtajad;
• maksumus;
• personal;
• tarvikud;
• side;
• riskid jne.

Plaan on projektijuhtimissüsteemi võtmeelement. Kui peaministril õnnestus koostada üksikasjalik planeerimisdokumentide kogum, siis on tal õigus eeldada, et töö lõppedes saadakse nõutud tulemused garanteeritud. Selleks tuleb ajastus, ressursid ja muud aspektid hästi planeerida. Kuni plaan pole välja töötatud, on võimatu teada, kui palju raha ja aega kulub ainulaadse ülesande täitmiseks. Ilma plaanita jääb juht praktiliselt ilma juhistest töö vastavuse kohta projekti eesmärkidele.

Peate mõistma, et planeerimine ei anna alati lõppkokkuvõttes positiivseid tulemusi, kuid negatiivsed järeldused võivad tuua mitte vähem ja mõnikord isegi suuremat kasu. Igal juhul suureneb vahendite investeerimise efektiivsus ja teenitud kasumi "hajumist" ei toimu. Projekti planeerimine paneb aluse tootlikule tööle ja lahendab järgmised rakendusprobleemid.

1. Täpsustage ja täpsustage ürituse eesmärke ja tulemusi.
2. Määrake töö koostis ja ulatus.
3. Hinnake ajakavasid ja eelarvekulusid.
4. Koostage põhietappide või kogu projekti ajakava ja eelarve.
5. Tehke iga etapi või kogu ülesande ressursivajaduse täpsustatud hinnang.
6. Koostage ressursiplaan.
7. Tehke riskianalüüs ja koostage riskidele reageerimise plaan.
8. Selgitage kliendile sündmuse üksikasju.
9. Leppige kava põhiosalistega kokku.
10. Jaotage osalejate vahel vastutus töö ja ülesannete eest.
11. Kinnitada üldplaneering.
12. Selgitage suhtlemisplaane ja planeerimise juhtimisprotseduure.

Projekti juhtimisplaani koht selle elutsükli etapis. Allikas: PMBOK 5 juhend

Planeerimisprotsesside koht muude projekti elluviimise protsesside hulgas. Allikas: PMBOK 5 juhend

Projekti planeerimist ei saa õhku jätta. Sellele eelneb algatamine ja nende protsesside väljundiks on projekti tegelik täitmine. Ja me mõistame mitmeid olulisi planeerimise punkte:

• seotud konkreetse ajapunktiga unikaalse ülesande elutsüklis ja selle olulise perioodiga (vt ülaltoodud diagramme);
• iteratiivne – ei lõpe pärast plaanide kirjutamist, vajab regulaarset uuendamist kuni aktiivse sulgemise faasini;
• kõikehõlmav – ei piirdu ühe tööriistaga ning sisaldab mitmeid tööriistu ja asjakohaseid väljunddokumente.

Planeerimisprotsesside laiendatud koosseis

Projektiplaan erineb projektijuhtimisplaanist ja sellega seotud planeerimisprotsessidest. Nagu juba defineerisime, peame laiemas tähenduses plaani all ette planeeritud tegevuste süsteemi, mille jaoks on paika pandud tööde teostamise järjekord, järjestus ja ajastus. Kitsas tähenduses on plaan dokument, mis kajastab kavandatud tegevuste järjekorda ja elluviimise tähtaegu. Projektijuhtimisplaan on reguleeritud planeerimisprotseduuride (protsesside) tulemus, milles kontrolli põhimõtte võtavad üle regulaarsed reguleeritud protseduurid planeeringute kui dokumentide koostamiseks.

Põhiliste planeerimiskontseptsioonide definitsioonid PMI-st. Allikas: PMBOK 5 juhend

Ürituste planeerimine hõlmab kahte protsesside rühma: plaanide vahetu väljatöötamise protsessid ja abiprotseduurid. Arendusploki väljund on dokument, mida nimetatakse üldprojekti plaaniks. See sisaldab kalendriplaani, ürituse eelarvet ja mitmeid muid dokumente. Töö koosseis ja sisu, nende teostamiseks vajalikud ressursid määravad kindlaks nende valmistamise järjekorra, kestuse ja kulude suuruse.

Võimalike riskide planeerimine (identifitseerimine, tuvastamine ja hindamine) ja nende juhtimine ei mõjuta mitte ainult ajakava kujunemist, vaid ka eelarvevajadusi. Eesmärkide selgitamine, unikaalse ülesande piiride määratlemine ning meeskonna ja vastutuse struktureerimine loob aluse sisukale projektiplaneerimise pingutusele. Järgmisena toome teie tähelepanu alla vaadeldavate protsesside põhiprotseduuride vaheliste seoste mudeli.

Projektijuhtimise planeerimisprotsesside mudel

Teadaolevalt eraldab PMI standardi järgi peaaegu iga PMBOK juhendi jaotis planeerimisele terve ploki. Ülaltoodud diagrammi põhjal on see üsna loomulik. PMBOK rubriik “Projektide integratsiooni juhtimine” näitab kõige terviklikumat pilti planeerimise juhtimisest ja ühtse üldplaani loomisest. Allpool on sündmuste korraldamise plaani arendusandmete vooskeemi lokaalne plokk.

Kohaliku projektijuhtimise kava väljatöötamise andmevooskeemi plokk

Ülaltoodud visuaalne plokk on tähelepanuväärne mitmel põhjusel. Projektijuhtimise alane teadmistebaas, kõik selles valdkonnas omandatud kogemused ja regulatsioonid on planeerimise õnnestumiseks hädavajalikud. See kehtib ka standardite, tarkvara, organisatsiooni struktuuri ja kultuuri, juhtimismeetodite, infrastruktuuri jms kohta. Harta on planeerimise peamine juhend. Need protsessid on üldplaani integreerimise aluseks ja pakuvad selle lõpliku versiooni väljatöötamiseks sisenditena järgmist:

• projekti parameetrite haldusplaanid;
• sisu, maksumuse ja ajakava põhiplaanid;
• plaani uuendused.

Kalendriplaani koostamise etapid

Nagu mäletame, on projektijuhtimine üles ehitatud “kolmele sambale”: töö sisule, piirangutele ja riskidele. Kui juht oskab nende kolme parameetriga hästi töötada, siis pole tema jaoks lahendamatuid ülesandeid. Vaatleme kalenderplaani väljatöötamist nende kolme positsiooni vaatenurgast ja jagame selle protsessi etappideks. Töö sisuks nimetame esimest ja teist etappi.

1. Tööde nimekirja määramise ja kirjutamise etapp. Üsna sageli tehakse vigu sellest, et kõiki töid ei ole võimalik korraga esitleda. Toimingute koosseisu kvalitatiivseks määramiseks on kasulik kasutada järjestikuse töö jaotamise meetodi põhitõdesid.
2. Projekti teostamise kindlaksmääramise etapp tööde järjestuse ja kestuse osas, mis sõltuvad nende rakendamise tehnoloogiast. Selle etapi kvaliteetse tulemuse loomiseks sobib hästi juba mainitud ülesannete järjestikuse jaotamise meetod ja töö kestuse eksperthinnang, kasutades selliseid meetodeid nagu näiteks ajurünnak.
3. Ressursi kättesaadavuse määramine. Üritus kasutab mitmesuguseid ressursse: rahalisi, materiaalseid, tööjõudu, teavet jne. Rahaliste vahendite vaatenurgast on vajalik siduda töögraafik finantseerimisgraafikuga. Tutvustatakse nappide ressursside mõistet: ainulaadsed spetsialistid ja võimed. See jätab jälje tööde järjestusele ja kestusele.
4. Väliste piirangute määratlus. Need piirangud hõlmavad hooajalisust, seadmete tarnimise tehnoloogilisi protsesse ja mitmesuguseid väliseid sündmusi. Kui võtta arvesse tellija erisoovide (konkreetsete partnerite puhul) või väliste sündmuste näidet (näiteks etapi valmimise ajastus, mis langeb kokku riigipühaga), siis on sellised sündmused sündmuse hulka arvatud. verstapostide vorm.
5. Riskireageerimisplaani koostamise etapp. Analüüsime projekti riske ja töötame välja peamiste ohtude lahendamise plaani. Seda plaani arvesse võttes koostame ajakava lõplikult.

Kolmas ja neljas etapp on seotud piirangute positsioonidega, viies etapp - riskidega. Kaks reageerimise alust (aktiivne ja passiivne) määravad otsuse tegemise hetke ja selle lisamise projektiplaani. Aktiivne reageerimine tähendab, et lisame ajakavasse lisatööd, mille eesmärk on riskide minimeerimine. See võib mõjutada muude tööde ajastust.

Näitena võime kaaluda projekti uue teenuse turule toomiseks. Oletame, et on tuvastatud selle nõudluse puudumise oht turul. Seejärel on selle riski minimeerimiseks vaja teha täiendavaid uuringuid ja see töö tuleb ajakavasse lisada. Passiivne reageerimine tähendab täiendavate rahaliste reservide moodustamist tuvastatud riskide jaoks. Graafiku koostamise etapid saab esitada ka allpool esitatud loogilises järjestuses.

Loogiline jada ajakava koostamiseks

Projekti planeerimise põhitegevused

Üldplaani koostamiseks viib projektijuht ellu mitmeid planeerimise iteratsioone. Planeerimisprotsesside läbiviimisel genereeritakse olulised instrumentaal- ja lõppdokumendid, mis kokku moodustavad üldplaneeringu. Nende hulgas:

• hierarhiline tööstruktuur (WBS);
• võrguskeem;
• kvaliteedijuhtimise plaan;
• projekti ajakava;
• eelarve;
• organisatsiooni skeem;
• riskiregister;
• kommunikatsiooniplaan;
• üldprojekti plaan.

Projekti planeerimise protsesside visuaalne mudel

Ülal on projektiülesande planeerimisprotsesside mudel. Protsesside täielikku koostist näete diagrammil. Basseiniradade planeerimise protsessid on seotud peaaegu kõigi projektijuhtimise valdkondadega. Paljusid mudelis määratletud protsesse on võimalik tutvustada meie veebisaidil eraldi artiklites. Selles materjalis keskendume lühidalt peamistele planeerimisprotseduuridele.

1. Ulatuse määratlemise protsess viiakse läbi, et selgitada projekti ulatust, piire koos selle toote kirjeldusega. Protsess algab ürituse eesmärkide, selle seose ettevõtte strateegiaga selgitamisega ning erinevate elluviimise lähenemiste kaalumisega. Peaministril peab olema selge, millised tööd jäävad projekti raamest välja ja millised on tootenõuded.
2. Töö ulatuse määramise protsess. Eelmises protsessis rajatud alused arendatakse välja kõigiks vajalikeks operatsioonideks edu saavutamiseks. Nende struktuur ja koostis on seotud projekti põhieesmärgiga. WBS on peamine tööriist, mida peaminister kasutab praeguse protsessi probleemi lahendamiseks.
3. Töösuhete kindlaksmääramine. Tööde loogiline jada on selle protsessi teema ja eesmärk. Protsessi juurutamise parimaks töövahendiks ja tulemuseks on PERT- ja CPM-meetodil ehitatud ja optimeeritud võrgumudel (diagramm, graafik).
4. Töö kestuse hindamise protsess. Iga WBS-is ja võrgumudelis sisalduva tegevuse kestuse prognoosimine toimub erinevate lähenemisviiside alusel. Peamisteks meetoditeks on hindamismeetodid, mis põhinevad analoogidel, “alt-üles”, sooritajatelt, ekspert- ja parameetriline hindamine.
5. Ressursivajaduse hindamise protsess. Protsessi eesmärk on määrata kindlaks vajalik hulk inimressursse, masinaressursse ja mehhanisme. Ressursid jagunevad rühmadesse: taastuvad, tarbitavad ja rahalised.
6. Kalendriplaani koostamise kord. Protsess viiakse läbi üksikute tööde ja projekti kui terviku eeldatava aja määramiseks. Oluline on planeeringu täpsustamise küsimus. Selle läbitöötamise sügavus peaks olema piisav, et projektijuht saaks kontrollida töö edenemist ja määratud ülesannete täitmist.
7. Üldprojekti plaani koostamine. See ühendab kõik ürituste planeerimise töö tulemused ühtseks projekti integratsioonidokumendiks.

Selles artiklis tutvusime projektiplaani koostavate protseduuride ja dokumentide "maksimaalse kogumiga". Tegelikkuses, eriti kui projekt on keskmise või väikese ulatusega ja korrapärane, ei ole sageli vaja liigseid planeerimispingutusi. Sellistel juhtudel võite piirduda standardsete planeerimislahenduste ja mittetäieliku dokumentide komplektiga. Samas vaevalt saab ilma koondplaanis paika pandud elementaarse dokumentaalfilmita hakkama ja selle arendamiseks kulutatud vaev tasub end kuhjaga ära.

Projekti planeerimise põhimõtted.

Tööde jaotuse struktuur.

Projekti planeerimine ajaparameetrite järgi.

Projekti võrgu planeerimise meetodid.

Projekti planeerimise töö korraldamine.

Projektijuhtimine: õpik / A.G. Ivasenko, Ya.I. Nikonova, M.V. Karkavin. – Rostov n/a: Phoenix, 2009. – P.177-212.

Mazur I.I. Projektijuhtimine: õpik. juhend erialal “Organisatsiooni juhtimine” õppivatele üliõpilastele/I.I. Mazur [ja teised]. ; toimetanud I.I. Mazura ja V.D. Shapiro – 6. väljaanne, kustutatud. - M.: Kirjastus "Omega-L", 2010. -960 lk.

Planeerimise olemus seisneb eesmärkide ja nende saavutamise viiside püstitamises, lähtudes teostatavate tööde (sündmuste, toimingute) komplekti moodustamisest, nende tööde teostamise meetodite ja vahendite kasutamisest, nende elluviimiseks vajalike ressursside sidumisest. ja projektis osalevate organisatsioonide tegevuste koordineerimine.

Plaani arendustegevused hõlmavad kõiki projekti loomise ja teostamise etappe. See algab projektijuhi (projektijuhi) osalemisega projekti kontseptsiooni väljatöötamisel, jätkub projekti strateegiliste otsuste valikuga, samuti selle detailide väljatöötamisega, sh lepinguettepanekute koostamisega, lepingute sõlmimisega. , tööde teostamine ja lõpeb projekti valmimisega.

Planeerimisetapis määratakse kõik projekti elluviimiseks vajalikud parameetrid:

projekti iga kontrollitava elemendi kestus,

vajadus tööjõu, materiaalsete, tehniliste ja rahaliste ressursside järele,

tooraine, materjalide, komponentide ja tehnoloogiliste seadmete tarneajad,

projekteerimis-, ehitus- ja muude organisatsioonide kaasamise ajastus ja mahud.

Projekti planeerimise protsessid ja protseduurid peavad tagama projekti teostatavuse etteantud aja jooksul minimaalsete kuludega, standardsete ressursikulude piires ja piisava kvaliteediga.

Hästi korraldatud projektis peaks iga eesmärgi elluviimise eest vastutama konkreetne juhtorgan: projektijuht kõigi eesmärkide eest (projektimissioon), vastutavad täitjad eraeesmärkide eest jne. See tähendab, et projekti eesmärkide puu peab ühtima projekti rakendamise eest vastutava organisatsiooniüksuse struktuuriga. Selleks on väljatöötamisel nn vastutusmaatriks, mis määratleb projekti teostajate funktsionaalsed kohustused ja määrab tööde komplekti, mille teostamise eest nad isiklikult vastutavad.

Mida kõrgem on juhtorgani tase, seda üldistatumate, agregeeritud näitajate alusel teeb ta otsuseid allüksuste juhtimise kohta. Hierarhia taseme kasvades pikeneb ajavahemik planeeritud ülesannete väljastamise, nende täitmise jälgimise jms vahel. Lisaks töötavad madalama tasandi üksused iseseisvalt sekkumishetkede vahel (planeeritud ülesannete väljastamine, võrdlusnäitajate määramine jne). olenemata samal või kõrvutiasetsevatest üksustest. Osakondade iseseisev toimimine peab olema tagatud teatud ressursireservidega, mida on vaja ka planeerida.

Planeerimise põhieesmärk on luua projekti elluviimiseks mudel. Selle abil on vaja koordineerida projektis osalejate tegevust, määratakse tööde tegemise järjekord jne.

Planeerimine on omavahel seotud protseduuride kogum. Projekti planeerimise esimene etapp on esialgsete plaanide väljatöötamine, mis on aluseks projekti eelarve väljatöötamisel, ressursivajaduse määramisel, projektitoetuse korraldamisel, lepingute sõlmimisel jne. Projekti planeerimine eelneb projekti kontrollimisele ja on selle rakendamise aluseks. , kuna võrreldakse planeeritud ja tegelikke näitajaid.

Planeerimine on projekti üks olulisemaid protsesse, kuna selle elluviimise tulemuseks on tavaliselt unikaalne objekt, toode või teenus. Planeerimise ulatuse ja detailsuse määrab protsessi tulemusena saadava info kasulikkus ning see sõltub projekti sisust (kavatsusest).

Planeerimisprotsessi ennast ei saa täielikult algoritmiseerida ja automatiseerida, kuna see sisaldab palju ebakindlaid parameetreid ja sõltub sageli juhuslikest teguritest. Seetõttu võivad planeerimise tulemusena välja pakutud planeeringuvariandid erineda, kui need on välja töötatud erinevate meeskondade poolt, kelle spetsialistidel on erinev hinnang välistegurite mõjule projektile.

TO põhiprotsessid planeerimine sisaldab:

projekti ulatuse planeerimine ja dokumenteerimine;

kalkulatsioonide koostamine, projekti lõpuleviimiseks vajalike ressursside maksumuse hindamine;

tööde määratlemine, konkreetsete tööde nimekirja moodustamine, mis tagavad projekti eesmärkide saavutamise;

tööde korraldus (järjestus), tehnoloogiliste sõltuvuste ja tööpiirangute tuvastamine ja dokumenteerimine;

üksikute tööde teostamiseks vajalike tööde kestuse, tööjõukulude ja muude ressursside hindamine;

graafiku arvutamine, tööde teostamise tehnoloogiliste sõltuvuste, töö kestuse ja ressursivajaduse analüüs;

ressursside planeerimine, määrates kindlaks, milliseid ressursse (inimesed, seadmed, materjalid) ja millistes kogustes projektitöö tegemiseks vaja läheb. Piiratud ressursse arvestades määrata kindlaks, millise aja jooksul saab tööd lõpetada;

eelarve koostamine, hinnanguliste kulude sidumine konkreetset tüüpi tegevustega;

projektiplaani koostamine (töötamine), muude planeerimisprotsesside tulemuste kogumine ja nende ühendamine ühiseks dokumendiks.

Abistamisprotsessid teostatud vastavalt vajadusele. Need sisaldavad:

kvaliteedi planeerimine, antud projektile vastavate kvaliteedistandardite määratlemine ja nende saavutamiseks viiside leidmine;

organisatsiooni planeerimine (disain), projekti rollide, vastutuse ja aruandlussuhete määratlemine, uurimine, dokumenteerimine ja jaotamine;

personali valik, projektimeeskonna moodustamine projekti elutsükli kõikides etappides, projekti kaasatud ja selles töötamine vajaliku inimressursi värbamine;

kommunikatsiooni planeerimine, projektis osalejate info- ja suhtlusvajaduste kindlaksmääramine: kes millist infot vajab, millal ja kuidas see neile edastada;

riskide tuvastamine ja hindamine, määramatuse teguri kindlaksmääramine ja mil määral võib projekti kulgu mõjutada, projekti elluviimiseks soodsate ja ebasoodsate stsenaariumide määramine, riskide dokumenteerimine;

tarnete planeerimine, selle määramine, mida, kuidas, millal ja kellega osta ja tarnida;

kavandamise ettepanekud, tootenõuete dokumenteerimine ja potentsiaalsete tarnijate tuvastamine.

Planeeringutasandite määramine on samuti planeerimise teema ja seda tehakse iga konkreetse projekti puhul, arvestades selle eripära, ulatust, geograafiat, ajastust jne.

Selle käigus määratakse projekti jaoks eraldatud tööpakettidele vastavate planeerimistasandite tüüp ja arv, nende sisulised ja ajalised seosed.

Plaanid (graafikud, võrgustikud) planeerimisprotsesside tulemuste väljendusena peaksid moodustama koos mingi püramiidse struktuuri, millel on informatsiooni koondamise omadused, mis eristuvad teadlikkuse juhtimise tasemete, arenguperioodide (lühiajaline, keskpikk ja pikaajaline) järgi. -tähtaeg). Planeerimistasandid ja planeeringute süsteem tuleks üles ehitada tagasiside põhimõtete alusel, mis tagavad planeeritud andmete pideva võrdlemise tegelike andmetega ning on suure paindlikkuse, asjakohasuse ja efektiivsusega.

Planeerimine on ressursside (materjali ja inimressursside) eraldamise ja määramise protsess, võttes arvesse projekti valmimise maksumust ja aega. Planeerimine on projekti üks olulisemaid protsesse, kuna selle elluviimise tulemuseks on tavaliselt unikaalne objekt, toode või teenus.

Põhiline planeerimisfunktsioonid on toodud allpool.

Vajaduste muutmine juhitavateks ülesanneteks. Esialgu ilmub projekt välja töötatud ja tellijaga kokku lepitud nõuetena. Planeerimise eesmärk on esitada need nõuded üksikute ülesannete kogumina, mille täitmist on võimalik kontrollida.

Vajalike ressursside määramine. Detailplaneeringud määravad kindlaks inimeste arv, vajalikud seadmed ja töötingimused, mida projekti lõpuleviimiseks on vaja.

Projekti meeskonnatöö koordineerimine. Väga sageli jagatakse projekt eraldi töödeks, mida saab paralleelselt lõpetada. Plaanid võimaldavad neid tegevusi koordineerida, määratledes, kes mida ja millal teeb.

Võimalike riskide hindamine. Kuigi nõuete koostamise käigus võidakse tuvastada mõningaid riske, avastatakse palju rohkem pärast üksikasjalikku planeerimist. Nende riskide olemasolu teadmine võimaldab teil neid varem märgata (kui need realiseeruvad) ja valmistuda nendega tegelemiseks.

Häire probleemide ilmnemisel. Plaanist kõrvalekaldumine on signaal probleemide ilmnemisest. Plaanid ei ole dogma, mida tuleb tingimusteta järgida. Projektijuhi jaoks on need pigem oletused ja võrdlusaluseks. Kui projekt ootustele ei vasta, tuleb plaani vastavalt korrigeerida.

Grupp planeerimisprotsessid näidatud joonisel fig. 3.10. Neid protsesse saab korrata ja need moodustavad osa iteratiivsest protseduurist, kuni saavutatakse teatud tulemus. Näiteks kui projekti esialgne valmimiskuupäev ei ole vastuvõetav, siis nõutavad ressursid, maksumus ja mõnikord ka projekti sisu ( Projektijuhtimise protsesside rühmad

Planeerimisprotsessi rühm

Projekti personalijuhtimine

Planeerimine

Personalijuhtimise plaani koostamine tehnilisi ressursse

Definitsioon

Projekti aja juhtimine

Definitsioon

operatsioonid

Kontroll

terviklikkus

Hangete planeerimine

Projekti kulude juhtimine^

Kulude prognoos

Projekti kvaliteedijuhtimine

Projektijuhtimisplaani koostamine

Definitsioon

järjestused

operatsioonid

operatsioonide ressursse

Planeerimine

kvaliteet

kestus

operatsioonid

Areng

kavad

Projekti riskijuhtimine

Definitsioon

Planeerimine

juhtimine

risk

Kvalitatiivse riskianalüüsi läbiviimine

Kvantitatiivse riskianalüüsi läbiviimine

Riskidele reageerimise kavandamine

Riis. KURI. Planeerimisprotsessid

Projekti tuleb muuta. Tulemuseks on sel juhul projekti eesmärkidele vastavad kokkulepitud tähtajad, mahud, ressursside valik, eelarve ja sisu.

Planeerimine on iga, isegi kõige lihtsama ülesande täitmise vajalik eeldus. Ebapiisav planeerimine võib kaasa tuua projekti ebaõnnestumise või ebasobivad tulemused projektikeskkonnas.

Ühes või teises vormis planeerimine toimub kogu projekti kestuse jooksul. Projekti elutsükli alguses koostatakse tavaliselt mitteametlik esialgne plaan – ligikaudne ettekujutus sellest, mida on vaja projekti elluviimiseks teha. Projektivaliku otsus põhineb suuresti selle esialgse kava hinnangutel. Formaalne ja detailne projekti planeerimine algab pärast selle elluviimise otsuse tegemist.

Planeerimine koosneb järgmise koostamisest plaanid:

• töö tegemine, sealhulgas selle töömahukuse ja tähtaegade hindamine;
• töö sisu ja ulatuse juhtimine;
• organisatsiooniline struktuur;
• Konfiguratsiooni juhtimine;
• kvaliteedijuhtimine;
• riskijuhtimine;
• hangete haldamine;
• projekteerimistulemuste ja esinejate tegevuse sertifitseerimine.

Definitsioon planeerimise tasemed on ka planeerimise teema ja viiakse läbi iga konkreetse projekti puhul, arvestades selle eripära, ulatust, geograafiat, ajastust jne. Selle käigus määratakse projekti jaoks eraldatud tööpakettidele vastavate planeerimistasandite tüüp ja arv, nende sisulised ja ajalised seosed.

Plaanid (graafikud, võrgustikud) planeerimisprotsesside tulemuste väljendusena peaksid moodustama agregaadis mingi püramiidse struktuuri, millel on teadlikkuse juhtimise tasemete järgi eristuvad info koondamise omadused ja mis peaksid olema ešeloneeritud arenguperioodide kaupa (lühiajaline, keskmine). - pikaajaline ja pikaajaline). Planeerimistasandid ja planeeringute süsteem peavad olema üles ehitatud tagasiside põhimõtetel, tagades planeeritud andmete pideva võrdlemise tegelike andmetega, need peavad olema suure paindlikkuse, asjakohasuse ja efektiivsusega.

Võrguplaanid koondatakse tänu sellele, et võrgu üldplaan koosneb paljudest eravõrguplaanidest. Kõigis neis eraplaanides määratakse pikim tee. Need teed asetatakse seejärel võrgu üksikute osade asemele. Sellise järkjärgulise liitmise abil saadakse mitmetasandilised võrguplaanid (joonis 3.11). Tavaliselt on olemas kontseptuaalne plaan, projekti elluviimise strateegiline plaan ja taktikalised (üksikasjalikud, operatiivsed) plaanid.

Võrguplaan mitme projektiga (kõrgemale juhtkonnale)

1. tase

3. tase

2. tase

Võrguplaan koos põhietappidega (eesmärgid)

Detailne võrguplaan

Riis. 3.11.Mitmetasandilised võrguplaanid

Kontseptuaalne planeerimine, mille tulemuseks on kontseptuaalne plaan, on projekti põhidokumentatsiooni, tehniliste nõuete, kalkulatsioonide, üksikasjalike ajakavade, kontrolli- ja juhtimisprotseduuride väljatöötamise protsess. Kontseptuaalne planeerimine toimub projekti elutsükli alguses.

Strateegiline planeerimine on strateegiliste, integreeritud ja pikaajaliste plaanide väljatöötamise protsess.

Üksikasjalik (operatiivne, taktikaline) planeerimine seotud operatiivjuhtimise hierarhilisel tööstruktuuril (WBS) põhinevate taktikaliste üksikasjalike plaanide (graafikute) väljatöötamisega

vastutavate täitjate tasemel.

Planeerige sisuhaldus.Üks levinumaid tarkvaraprojektide "haigusi" on nn "hiiliv funktsionism" kui algselt kavandatud putkale lisatakse esmalt aiatööriistade hoidmiseks mõeldud kuur armastatud koerale ja seejärel mitmekorruseline maja selle omanikule. Ja seda kõike üritatakse ehitada samale vundamendile ja samadest materjalidest. Selline lähenemine on põhjustanud paljude tarkvaraarendusprojektide surma. Seega, niipea kui oli võimalik stabiliseerida ja kokku leppida WBS - töö hierarhiline struktuur, on vaja välja töötada projekti ulatuse juhtimiskava, mille jaoks peaksite:

• teha kindlaks muudatustaotluste allikad;
• kehtestab sisumuudatuste analüüsi, hindamise ja kinnitamise/tagasilükkamise korra;
• määrab sisumuudatuste dokumenteerimise korra;
• määrab sisumuudatustest teavitamise korra. Esimene ülesanne, mis tuleb päringu analüüsimisel lahendada

muudatuste jaoks - identifitseerida muudatusobjektid: nõuded, arhitektuur, andmestruktuurid, lähtekoodid, testskriptid, kasutaja dokumentatsioon jne. Seejärel on vaja kavandada ja üksikasjalikult kirjeldada muudatusi kõigis tuvastatud objektides. Lõpuks tuleks hinnata nende muudatuste tegemise kulusid, muudatuste testimist ja nende mõju projekti ajakavale. See töö nõuab erinevatelt spetsialistidelt: analüütikutelt, disaineritelt, arendajatelt, testijatelt, aga ka projektijuhilt aega ja mõnikord ka märkimisväärset kulu ning seetõttu tuleb sellega plaanis arvestada.

Organisatsiooni struktuuri planeerimine.Organisatsiooniline struktuur- see on projekti võtmeosaliste rollide, kohustuste ja eesmärkide kokkulepitud ja kinnitatud jaotus. See peab tingimata sisaldama järgmist:

• projekti töörühmade töösuhete süsteem;
• aruandlussüsteem;
• projekti edenemise hinnangud;
• otsuste tegemise süsteem.

Tuleb meeles pidada, et projekti organisatsiooniline struktuur on "elav" organism. See hakkab kujunema planeerimisetapis ja peaks projekti edenedes muutuma. Organisatsioonilise struktuuri ebastabiilsus (esinejate sagedased vahetused) võib saada projektijuhtimises tõsiseks probleemiks, kuna tekib asenduskulu, mille määrab uue osaleja projekti konteksti sisenemise aeg.

Konfiguratsioonihalduse planeerimine.Üks olulisi tarkvaratootmisprotsesse on Konfiguratsiooni juhtimine. Sellest teadmistevaldkonnast on kirjutatud rohkem kui üks raamat. Siin räägime ainult sellest, kuidas seda tööd tuleks planeerida. Projekti konfiguratsioonihaldusplaan peaks sisaldama:

• töötama selle nimel, et tagada kogu projekti dokumentatsiooni ja väljatöötatud programmikoodi jaoks ühtne hoidla, tagades projekti teabe ohutuse ja taastamise pärast rikkeid;
• töö projektimeeskonna liikmete kasutatavate tööjaamade ja serverite seadistamisel;
• süsteemi vaheväljaannete kokkupanemise korraldamiseks vajalik töö, samuti selle lõplik versioon.

Seda tööd teeb tavaliselt konfiguratsiooniinsener. Kui projekt on väike, võib see roll olla täiendav mõnele programmeerijale või projektijuhile. Selle töö “hajutamine” kõikidele projektis osalejatele on esiteks ebaefektiivne. Arenduskeskkondade, nagu andmebaasid ja rakendusserverid, installimine ja konfigureerimine nõuab spetsiifilisi pädevusi ja teadmisi konkreetsete tooteversioonide kohta. Kui kõik arendajad peavad neid oskusi õppima, võtab see liiga palju tööaega. Teiseks võib konfiguratsioonihaldustöö “laialiminek” kaasa tuua kollektiivse vastutustundetuse, kui keegi ei tea, miks “projekt ei tööta” ja kuidas “tagasi” eelmisele versioonile “kerida”.

Konfiguratsioonihaldus võib muutuda palju keerulisemaks, kui projektimeeskond peab paralleelselt uue toote funktsionaalsuse väljatöötamisega toetama mitut selle toote väljalaset, mida erinevad kliendid varem installisid, kuid kogu selle tööga tuleb projektis arvestada. plaan.

Kvaliteedijuhtimise planeerimine. Teine tarkvaratehnika põhiteadmiste valdkond on kvaliteedi tagamine. Selle kohta, mis on tarkvara kvaliteet ja kuidas seda tõhusalt tagada, on erinevaid arvamusi. Piirdugem tõdemusega, et kvaliteedi tagamine on üsna oluline töö, mis tuleb ette planeerida ja läbi viia kogu tarkvaraprojekti vältel, mitte ainult vastuvõtutestide käigus.

Seda tööd planeerides tuleb mõista, et projektitoode ei tohiks olla võimalikult kõrge kvaliteediga, mis on kättesaamatu piiratud aja jooksul. Toote nõutava kvaliteedi määravad sellele esitatavad nõuded. Kvaliteedi tagamise põhiülesanne ei ole mitte vigade otsimine valmistootes (väljundkontroll), vaid nende vältimine tootmisprotsessi käigus.

Kvaliteedijuhtimise plaan peaks sisaldama järgmist tööd:

• tarkvaratoodete ja tehnoloogiliste toimingute kehtivatele standarditele, protseduuridele ja nõuetele vastavuse objektiivne kontrollimine;
• kvaliteedihälvete väljaselgitamine, nende põhjuste väljaselgitamine, meetmete rakendamine nende kõrvaldamiseks, samuti võetud meetmete rakendamise ja nende tulemuslikkuse jälgimine;
• kõrgema juhtkonna sõltumatu teabe pakkumine mittevastavuste kohta, mida projekti tasandil ei lahendata.

Töö sisu ja koostise selgitamine. Projekti sisu selgitamine (dekomposiit) on projektijuhtimise distsipliini üks olulisemaid komponente. Detaileerimine võimaldab hinnata näiteks projekti kogumaksumust selle üksikute tööde kogumaksumuse kaudu. Projekti sisu täpsustamise tulemus on töö jaotuse struktuur(Work Breakdown Structure – WBS). Enamasti on see struktuur hierarhiline. Samal ajal on detaileerimisprotsess ise töö jaotuse struktuur, st. tegevus, et luua töö- või projektiülesannete üksikasjalik struktuur.

Töö hierarhiline struktuur(WBS) on projektimeeskonna poolt projekti eesmärkide ja nõutavate tulemuste saavutamiseks tehtud töö tulemustele orienteeritud jaotus. Tema abiga struktureeritakse ja määratakse kogu projekti sisu. Iga järgmine hierarhia tase peegeldab projekti elementide üksikasjalikumat määratlust. WBS-i arendamise aluseks on projekti kontseptsioon, mis määratleb projekti tooted ja nende peamised omadused. WBS tagab, et kõik projekti eesmärkide saavutamiseks vajalikud tööd tehakse kindlaks. Paljud projektid ebaõnnestuvad mitte sellepärast, et neil pole plaani, vaid seetõttu, et plaan jätab tähelepanuta olulised tööd, nagu testimine ja vigade parandamine, aga ka projektitooted, nagu kasutajadokumentatsioon. Seega, kui WBS on õigesti koostatud, ei saa projekti tööks lugeda ühtegi tööd, mis selles ei sisaldu. WBS jagab projekti alamprojektideks, tööpakettideks ja alampakettideks. Iga järgmine jaotusaste annab projekti sisu järjepideva detaili, mis võimaldab hinnata töö ajastust ja ulatust. WBS peab sisaldama kõiki vahe- ja lõpptooteid.

Projekti töö tükeldamiseks on erinevaid viise. Näiteks GOST 19.102-77 näeb ette kose lähenemine ja määratleb järgmise tarkvarasüsteemi arendamise etapid.

• 1) tehnilised kirjeldused;
• 2) eelprojekt;
• 3) tehniline projekt;
• 4) tööprojekt;
• 5) rakendamine.

Kui järgime seda standardit, peaksid need disaintooted olema WBS-i esimesel tasemel. Kui me peaksime tuumareaktori või mehitatud kosmoselaeva juhtimiseks välja töötama automatiseeritud juhtimissüsteemi, siis just seda oleks tulnud teha. Kaubandustarkvara arenduses on see lähenemisviis aga ebaefektiivne.

Kaasaegne kommertstarkvara arendusprotsess peab olema järkjärguline. See tähendab, et projekti lagunemise tipptasemel peaksid olema projekti tooted ja järgmisel tasemel - komponendid, millest need tooted koosnevad. Komponendid saab täiendavalt jaotada "funktsioonideks" - funktsioonideks, mida nad peavad rakendama.

Tarkvaratoote moodustavate komponentide eraldamine on kõrgetasemelise disaini element, mis tuleks läbi viia projekti planeerimise etapis, ootamata kõigi arendatava tarkvara funktsionaalsete nõuete väljatöötamist. Komponendid võivad olla nii rakenduste alamsüsteemid kui ka infrastruktuuri või tuumasüsteemid, näiteks autentimise ja turvalisuse alamsüsteem, graafilise liidese (GUI) visuaalsete komponentide raamatukogu. Põhitööplaani koostamisel ei tohiks püüda kõiki WBS-i töid võimalikult üksikasjalikult kirjeldada, piisab 3-5 tasemest.

Detailistamise kontekstis kasutatakse termineid "ülesanded" ja "töö" sageli vaheldumisi. Siiski on õigem öelda, et ülesanne määrab vahetulemuse saavutamise ja töö on tegevuste kogum nende tulemuste saavutamiseks. Kuna iga tööülesanne eeldab teatud töö tegemist etteantud piirangutega, siis saab kindlasti rääkida ülesannete vaieldamatust tööks “kaardistamisest” ja vastupidi. See on igapäevaelus terminite vahetatavuse põhjus. Samas võimaldab nende mõistete erinevuste mõistmine tunnetada toote loomise protsessivaate nüansse ja seega ka projektide, sealhulgas tarkvarasüsteemi projektide elutsüklit.

Üldiselt saame rääkida detail: "programm - projekt - ülesanne on operatsioon." Joonisel fig. Joonis 3.12 pakub sellise detaili näite (näidatud on ainult ülesande toimingud A).

Riis. 3.12.Näide mõistete kasutamisest: programm, projekt, ülesanne, operatsioon

Sellise struktuuri iga element on seotud piirangute ja muude oluliste omaduste ja andmetega. Asjakohasus viitab nende vajalikkusele või kasulikkusele otsuste tegemisel. Teatud terminite detailsus ja rakendusaste oleneb konkreetsest projektist, juhtimiskultuurist, elukaare standarditest, projekti spetsiifikast ja ulatusest, aga ka muudest nii konkreetse organisatsiooni kui ka konkreetse projekti jaoks ainulaadsetest teguritest.

Isiklik vastutus tuleb kehtestada kõigi projekti osade (alamprojektide ja tööpakettide) eest. Iga tööpaketi puhul peab väljundtulemus olema selgelt määratletud. Töö- ja projektihinnangud tuleb kokku leppida võtmemeeskonna liikmete, teostava ettevõtte juhtkonna ja vajadusel tellijaga. Kokkuleppe tulemusena võtavad meeskonnaliikmed endale kohustuse projekti elluviimiseks ning juhtkond vastutab projektile vajalike ressurssidega varustamise eest.

WBS on projektijuhtimise mehhanismi üks peamisi tööriistu (vahendeid), mille abil mõõdetakse projekti tulemuste saavutamise astet. Selle kõige olulisem ülesanne on tagada, et kõik projektis osalejad mõistaksid ja mõistaksid, kuidas projekti tehakse. Edaspidi on lähtejoon juhendiks, mille abil võrrelda projekti praeguse elluviimisega, et tuvastada kõrvalekaldeid.

Projekti maksumuse kalkulatsioon. Tarkvaraprojekti haldamise protsess algab paljude tegevustega, mida ühendab ühine nimi projekti planeerimine. Esimene neist toimingutest on projekti maksumuse kalkulatsiooni tegemine. See paneb aluse teistele projekti planeerimistegevustele. Projekti hinnates on vigade hind ülikõrge. Väga oluline on hindamine läbi viia minimaalse riskiga.

Projekti maksumuse algoritmilise modelleerimise peamiseks raskuseks on kuluhinnangu sõltuvus valmistoote omadustest ja parameetritest. Projekti varases staadiumis on neid omadusi ja parameetreid võimatu täpselt määrata. Paralleelselt kasutatava tarkvara maksumuse hindamiseks on palju meetodeid. Kui saadud tulemused on väga erinevad, tähendab see, et analüüsiks kasutati ebapiisavat või sobimatut informatsiooni. Tarkvaratoote hind sageli lepingu sõlmimise eesmärgil eelnevalt kindlaks määratud, mis toob kaasa süsteemi funktsionaalsuse hilisema kohandamise selliseks, et see vastaks sellele hinnale.

Kuulus projekti maksumuse prognoosimise mudel B. Boema SOSOMO võtab arvesse disainiomadusi, loodava tarkvara omadusi, riistvara ja personali võimalusi. See mudel sisaldab ka tööriistu projekti töö kestuse määramiseks. Tööde valmimiseks kuluv aeg ei sõltu otseselt projekti jaoks palgatud spetsialistide arvust. Kui lisate ajakavast maas projekti rohkem inimesi, võib selle valmimise aeg veelgi edasi lükata.

Algoritmilisi projektide kuluarvestusmudeleid kasutatakse tarkvaraprojektide haldamiseks, kuna need toetavad kvantitatiivset parameetrianalüüsi. Need mudelid võimaldavad teil hinnata iga üksiku parameetri panust projekti kogumaksumusse ja teha nende parameetrite objektiivset (kuigi mitte vigadeta) võrdlust.

Projekti maksumuse prognoos- projekti üks olulisemaid töid, mille määramisel lähtutakse projekti üksikute osade maksumusest, tööde teostamise tingimustest, teostajate tegelikust koosseisust, kasutatavatest meetoditest ja töövahenditest. Projekti maksumus sisaldab ka projekti läbiviimise kulusid, s.o. arvutid, tarkvara, ruum, mööbel, telefonid, modemid ja palju muud. Lisaks tuleb mõnikord arvestada lisakuludega (näiteks turvalisus). Projekti lisakulud hõlmavad testimissüsteemi, CABE süsteemi jms ostmist. Peamine hinnang projektis on projekti maksumuse kalkulatsioon, mida väljendatakse esinejate projektiga tehtud tööpäevades. See hindamine viiakse läbi juhtimise ja planeerimise varajases staadiumis.

Projekti kogumaksumuse määravad kogenud spetsialistid veaga kuni 10%. Kulude prognoos võib olla ülalt-alla, alt-üles või põhineda varem valmistatud disaini maksumusel. Eksperdid annavad pessimistlikke, optimistlikke ja realistlikke hinnanguid, küsitledes kõiki töörühma liikmeid ja kohandades iga hinnangut, et saada kõige usutavam. Mõnes töörühmas võivad pessimistlikud ja optimistlikud hinnangud olla väga erinevad.

Algoritmilised meetodid projekti kulude hindamiseks näidata seoseid projekti kulude ja neid mõjutavate tegurite vahel.

Projekti maksumuse hindamiseks on erinevaid empiirilisi lähenemisviise, näiteks tehakse ettepanek määrata projekti maksumus valemi abil

HIND = (a + b?)t(X),

kus 5 on teatud hinnang süsteemi suurusele; a, b, c - empiirilised konstandid; X - dimensiooniga kulutegurite vektor reede - kuluteguritel põhinev regulatiivne kordaja.

Eksperimentaalselt saadud lihtsustatud hinnang väljendatakse järgmiselt:

KULU = 5,255 0,91.

Need hinnangud saadi selliste projektide analüüsist, kus programmide suurus oli 4000 kuni 467 000 koodirida ja need olid kirjutatud 28 erinevas programmeerimiskeeles 66 arvutis. Arendustööle kulus 12–11 758 inimkuud. Tuntud on ka teisi empiirilisi modelleerimistehnikaid.

Esimestes mudelites kasutati hinnanäitajaid, võeti arvesse personali ja projekti, toote ja keskkonna omadusi. Mudelid sisaldavad hinnangut projektijuhtimise kolmele etapile. Esimeses etapis ehitatakse kõrge riskiga ülesannete jaoks (kasutajaliides, tarkvara, interaktsioonisüsteem, juurutamine jne) prototüüp ja hinnatakse kulusid (näiteks tabelite arv andmebaasis, ekraanid ja aruandlusvormid jne. .). Teises etapis hinnatakse projekti nõuetes kajastuvad projekti funktsionaalsete punktide kavandamise ja elluviimise kulud. Kolmandas etapis viitab hinnang valminud projektile, kui süsteemi suurust saab määrata täidetud programmiridade ja muude tegurite järgi.

Tänapäeval on projekti kulude eksperimentaalse hindamise põhimudel järgmine võrrand:

KULU = bS c m(X),

Kus bS c - esmane hinnang, mida korrigeeritakse kuluvektori abil t(X) ning vanade ja uute objektide arvu arvestus; Koos- parameeter, mis varieerub nullist üheni projekti esimese etapi puhul ja 1,01 kuni 1,26 ülejäänud etappide puhul.

Formaaliseeritud lähenemise korral põhineb projekti hindamine LOC ja FP mõõdikute kasutamisel.

Konstruktiivne kulumudel(SOSOMO – Konstruktiivne kulumudel), mille on välja pakkunud B. Boehm, ühendab endas kõige tuntumaid formaliseeritud projektide hindamise tehnikaid – LOC hinnangud(LOC – koodiread), mis põhinevad programmikoodi ridade arvul. Selle mudeli rakendamise käigus koostatakse esialgsed hinnangud, mis võimaldavad esitada kliendile korrektsed nõuded tarkvara arendamise kuludele ja kuludele ning tagavad ka tarkvaraplaani koostamise võimaluse.

Funktsioonidele orienteeritud FP mõõdikud LOC-skooride arvutamise asemel mõõdavad nad kaudselt tarkvaratoodet. Arvestatakse mitte suurust, vaid toote funktsionaalsust või kasulikkust. Selle mõõdiku autor on A. Albrecht. Funktsionaalse suuruse määramine koosneb mitmest etapist ja algab funktsioonide kindlaksmääramisega, mis rakendusel peaksid olema. Rahvusvaheline funktsioonipunktide kasutajate rühm (IFPUG) on avaldanud kriteeriumid, mille alusel määratakse rakenduse funktsioonid. FP mõõdiku arvutamisel kasutatakse viit infotunnust: väliste sisendite arv; väliste väljundite arv (väljundid tähendavad aruandeid, ekraane, väljatrükke, veateateid); väliste päringute arv; sisemiste loogiliste failide arv; väliste liideste failide arv.

Pärast kogu vajaliku teabe kogumist jätkake mõõdikute arvutamine - määrata funktsiooninäitajate arv FP (funktsioonipunktid) teatud valemi järgi, kus sisendi keerukuse korrigeerimise koefitsientide väärtused (iga koefitsient võib võtta järgmisi väärtusi: 0 - ei mõjuta; 1 - juhuslik; 2 - väike; 3 - keskmine; 4 - oluline 5 - peamine) valitakse empiiriliselt sisse 14 küsimuse vastuse tulemusena, mis iseloomustavad rakenduse süsteemiparameetreid.

Meetod seisneb rakenduse kõigi võimaluste ühtlases mõõtmises mis tahes projekti jaoks ja rakenduse suuruse väljendamises ühe numbrina, mille abil saab seejärel hinnata koodiridade arvu, projekti maksumust ja ajastust. Selle alusel moodustuvad tootlikkuse, kvaliteedi jms mõõdikud.

Eelis funktsioonile orienteeritud mõõdikud seisnevad selles, et need ei sõltu programmeerimiskeelest ja on kergesti arvutatavad projekti mis tahes etapis.

Puudused funktsioonile orienteeritud mõõdikud – tulemused põhinevad pigem kaudsetel kui otsestel mõõtmistel; Lisaks peavad teil olema teatud oskused selle meetodi täpseks ja järjepidevaks rakendamiseks.

Kasutades standardtabeleid, saab FP hinnanguid kergesti teisendada LOC hinnanguteks, s.t. Funktsionaalse suuruse järgi arvutage koodiridade arv. Teisenduse tulemused sõltuvad aga tarkvara realiseerimiseks kasutatavast programmeerimiskeelest (näiteks Javas võrdub üks funktsionaalse suuruse ühik 53 lähtekoodi reaga). Koodiridade arv võimaldab omakorda määrata kogu tööjõumahukuse, väljendatuna inimkuudes, ja projekti ajakava.

Hindamise läbiviimisel on LOC ja FP andmetel kaks kasutusvõimalust: hinnangumuutujatena, mis määravad iga tooteelemendi suuruse, või mõõdikutena, mis kogutakse töö käigus varasemate projektide kallal ja mis sisalduvad ettevõtte mõõdikute baasis.

Näide 3.1. Vaatleme ShS-i mõõdiku alusel töö hindamise protseduuri läbiviimise korda.

1. etapp. Disainitud toote kasutusala on jagatud mitmeks funktsiooniks/i,/2,/3, millest igaüks saab olla

hinnata individuaalselt

2. etapp. Iga funktsiooni/plaanija loob parima LOC n, halvim YUS X ja tõenäoline YUS V hinnangud. Hinnangute koostamise protsessis kasutatakse meetermõõdustiku baasil saadud eksperimentaalseid andmeid või planeerija intuitiivseid ideid. Võimalike hinnangute vahemik vastab esitatud määramatuse astmele.

3. etapp. Iga funktsiooni jaoks f t hinnangu eeldatav väärtus määratakse:

YUS I + YUS X + 4 BOC^ jahuti = 6"

yus.

4. etapp. Funktsiooni arendamise AL-jõudluse väärtus arvutatakse vastavalt ühele kolmest reeglist.

Reegel L. Kõikide funktsioonide jaoks võetakse sama väärtus, mis on võrdne PR avg keskmise jõudlusega, mis on võetud meetrilisest baasist, st.

PR = PR avg; / = 1, 2, ..., P.

Reegel B. i-nda funktsiooni jaoks arvutatakse kohandatud toimivusväärtus keskmise toimivuse mõõdiku põhjal:

ys sr

MS lahe ’

Kus YUS kolmap - keskmine LOC skoor, mis on võetud meetermõõdustiku alusel (vastab keskmisele tootlikkusele).

Reegel B. i-nda funktsiooni jaoks arvutatakse reguleeritav jõudlusväärtus valitud analoogi abil (võetuna meetermõõdustiku alusel):

BOSdnI

proua Ozhi

Reegli A kasutamine edasistes etappides tagab minimaalse täpsuse ja arvutuste maksimaalse lihtsuse. Reegel B võimaldab saavutada maksimaalse täpsuse arvutuste maksimaalse keerukusega.

Lava 5. Projekti kogumaksumuse kalkulatsioon (inimkuus) arvutatakse reegli A kasutamisel:

kui kasutatakse reeglit B või C:

b1у ^ozh/

6. etapp. Projekti maksumuse üldhinnang arvutatakse, kui kasutatakse reeglit A või B:

KULU = UDST avg yuS 0Zh/ ;

kui kasutatakse reeglit B:

KULU = UDST an/ ^YUS 0Zh/ ,

kus UDST avg on programmikoodi ühe rea keskmise maksumuse mõõdik; UDST an, - analoogi ühe rea maksumuse mõõdik (mõlemad mõõdikud on võetud meetrika baasist).

Projekti ajakava koostamine. Pärast tööde töömahukuse kindlaksmääramist on vaja kindlaks määrata nende rakendamise ajakava ja projekti üldine ajakava, s.o. koostada projekti töögraafik Põhiline ajakava esindab kinnitatud ajakava koos projekti kindlaksmääratud ajafaaside, verstapostide ja töö hierarhilise struktuuri elementidega.

Põhigraafik on enamikul juhtudel kliendiga sõlmitud lepingu osa. Kontrollpunktid ( verstapostid) toimivad punktidena projekti oleku analüüsimisel ja otsuste tegemisel formaadis “§o või po1 §o”, nii et need peaksid projekti staatust nähtavalt näitama. Kontrollpunktide valikule ja moodustamisele kehtivad teatud nõuded, näiteks kontrollpunkt “Disain on lõpetatud” on väheinformatiivne, tõhusamaks lähenemiseks peetakse järjestikust kohaletoimetamise meetodit: eelpool nimetatud kontrollpunkt on sõnastatud kujul “; Nõuete 1, 3, 5 ja 7 testimine on lõpetatud.

Kui tööd ei ole omavahel seotud, siis saab ükskõik millise neist alustada ja lõpetada siis, kui see meile sobib; kõiki töid saab teha paralleelselt, sel juhul on projekti minimaalne kestus võrdne pikima töö kestusega. Kuid praktikas on tööde vahel tavaliselt sõltuvusi, mis võivad olla "rasked", näiteks konkreetse funktsiooni "analüüs - projekteerimine - kodeerimine - testimine - dokumenteerimine" või "pehme", mida saab näiteks üle vaadata või pehmendada. , saab konkreetse täitja ülesannete järjestikuse täitmise ümber ajastada mõnele teisele töövõtjale ning põhitarkvara arendamise asemel, mis peab eelnema rakendustarkvara arendamisele, saate luua selle tööd jäljendavaid “kärpeid”.

Tööplaani koostamise tähtaegadega nende rakendamiseks saab läbi viia kriitilise tee meetodil CPM või PERT programmide analüüsi ja hindamise meetodil. Projektiplaan on esitatud etappide lõikes: “Planeerimine”, “Disain”, “Kodeerimine”, “Testimine” ja “Hooldus”. Planeerimine hõlmab spetsifikatsioonide, eelarve ja ajakava kindlaksmääramist, samuti projekti üldise plaani väljatöötamist.

IN projekti kriitilise tee meetod(Kriitiline tee) kasutatakse projekti pikimat tööde ahelat. Mis tahes töö kestuse suurendamine selles ahelas toob kaasa kogu projekti kestuse pikenemise. Projektis on alati vähemalt üks kriitiline tee, kuid neid võib olla mitu. Kriitiline tee võib projekti teostamise ajal muutuda.

Projekti elluviimisel peab juht esmalt tähelepanu pöörama ülesannete täitmisele kriitilisel teel ning jälgima teiste kriitiliste teede tekkimist. On praktiline soovitus: kriitilisel teel peaks olema töö mittejäigade ühendustega, mida saab alati ajastada, kui on oht tähtaegadest mööda minna. Töögraafik koostatakse vastavalt joonisel fig. 3.13.

Nõuete ajakava

projekti juurde

Riis. 3.13.Projekti tööde ajastamise sammud

Kui plaanite programmi analüüsi ja hindamise meetod PERT-i sündmus või kuupäev plaanis on teatud verstapost (kontrollpunkt) üksiku projektitöö teekonnal ja seda kasutatakse teatud tööde valmimise oleku kuvamiseks/märgistamiseks. Projekti kontekstis kasutavad juhid verstaposte, et teha kindlaks olulised vahetulemused, mis tuleb projekti käigus saavutada.

Sageli nimetatakse juhi poolt määratletud verstapostide jada verstaposti plaan (sündmuste järgi). Asjakohaste verstapostide saavutamiseks plaani määratlemine loob verstapostipõhise ajakava.

Planeerimisetapis saab kasutada ka tööde võrgujaotust ja Gantti diagrammi.

Võrgu töö jaotus(SPP) on hierarhiline struktuur projektiülesannete alamülesanneteks jaotamiseks. Madalamal tasemel on töösüsteemide süsteemi võrgumudelis tegevuselementideks detailselt tööd.

Võrgumudel võimaldab jagada töö põhikomponentideks ja alamkomponentideks, määrata keeruliste eesmärkide saavutamisele suunatud tegevusvaldkonnad, jagada projektiga individuaalse töö teostamise eest vastutavad isikud ja täita projekti tulemuste kohta kokkuvõtvat teavet.

Tööplaan peab kajastama töö põhietappe ja igas etapis vajalikku tööseisu, iga töö jaotust eraldi tööülesanneteks, samuti tööde omavahelisi seoseid, iga tegevuse sooritamise ajavahemikke, tööde alustamise ja lõpetamise aegu. Tööplaan sisaldab erinevat tüüpi projekti funktsioonide, alamsüsteemide, töökindluse, kaitsevahendite jms demonstratsioone. Plaanidokumentides on ka komplekt juhendeid ja tehnikaid määratud toimingute tegemiseks, süsteemiühenduste säilitamiseks teiste alamsüsteemidega jne.

WBS-i graafiku kujul olev tööplaan sisaldab faase (etappe), samme ja tegevusi, sealhulgas protsessi alg- ja lõpptegevusi (joonis 3.14).

Faas Ja

1. samm Samm 2

Riis. 3.14.Samm-sammult projektiplaani graafik

Teine tööplaani visuaalse esituse vorm võiks olla võrguskeem, täpsustatud graafiku kujul, mille tippudes asuvad tööelemendid, ja kaaredel - nende täitmiseks vajalike päevade (nädalate) arv (joonis 3.15). Neid märke kasutatakse protsessi täitmisaja määramiseks. Initsiaalist lahkuv kaar

Riis. 3.15.

tippu ja lõpptippu sisenedes vastab ajatemplile “null”.

Graafik võib sisaldada tsüklilisi teid. Graafikut kasutatakse kriitiliste radade analüüsimiseks, st. määrake iga protsessi kestus.

Ajakava koostamine koosneb alguspunkti (sündmus või sündmuste kogum, mis toimus enne protsessietapi algust ja mille jaoks on kirjeldatud tingimuste kogum, sealhulgas protsessi algus), kestuse (ajavahemik, mille jooksul protsess peab oma täitmise edukalt lõpule viima), tähtaeg (kuupäev , milleni protsess täielikult või osaliselt lõpetab) ja protsessi lõpp-punkt (kontrollpunkt, kus klient kontrollib saadud protsessitulemuste kvaliteeti).

Kõige selgem viis põhigraafiku esitamiseks on Gantti diagramm- lineaarne diagramm, kus projekti ülesanded on esitatud ajaperioodide kaupa, sealhulgas nende rakendamise algus- ja lõppkuupäevad, võttes arvesse võimalikke viivitusi. Sellel diagrammil on vasakus servas loetletud kavandatud tegevused (tööjaotuse struktuuri elemendid), ülaosas kuvatakse kuupäevad ja tegevuste kestused horisontaalsete ribadena alates antud tegevuse alguskuupäevast kuni selle lõpetamise kuupäevani (joonis 3.16).

Riis. 3.16. Gantti diagramm

Täitmisprotsessi rühm

Projektijuhtimise protsesside rühmad

Projekti kvaliteedijuhtimine

Turvalisus

kvaliteet

Kaasaegne projektijuhtimise tarkvara võimaldab visualiseerida projektigraafiku struktuuri ja tööprotsesse, näiteks laialt tuntud ja praktikas üsna sageli kasutatav projektijuhtimissüsteem. See võimaldab arendajal või projektijuhil näha, kuidas erinevaid tegevusi tehakse – järjestikku või paralleelselt ning kas need on kriitilisel teel.

Projekti planeerimine on osa projektijuhtimisest, mis hõlmab ajakavade (nt Gantti diagrammi) kasutamist töö planeerimiseks ja seejärel projektikeskkonnas edusammudest aru andmiseks.

Esialgu määratletakse projekti ulatus, kuid pole määratletud sobivaid meetodeid projekti lõpetamiseks. Pärast seda sammu tuleks töö lõpetamiseks vajalikud tööüksused loetleda ja rühmitada tööjaotuse struktuuri (WBS), võttes arvesse erinevate ülesannete kestust. Projekti planeerimist kasutatakse sageli projekti erinevate valdkondade, sealhulgas projektiplaanide, töökoormuse ning meeskondade ja inimeste juhtimise korraldamiseks. Ülesannete vahelised loogilised sõltuvused määratakse võrgu aktiivse diagrammi abil, mis võimaldab määrata kriitilise tee.

Projekti planeerimine on ebakindel; seda tuleb teha enne projekti tegelikku algust. Seetõttu hinnatakse ülesannete kestust sageli optimistlike, normaalsete ja pessimistlike hinnangute kaalutud keskmise põhjal. See lisab planeerimisse puhvreid, et oleks võimalik ennetada viivitusi (nt pikki kinnitusi) projekti rakendamisel. Ajakavas olevat aega saab arvutada projektihaldustarkvara abil. Iga tegevuse jaoks vajalikke ressursse ja kulusid saab hinnata, andes projekti kogumaksumuse. Selles etapis saab projekti ajakava optimeerida, et saavutada õige tasakaal ressursside kasutamise ja projekti kestuse vahel, mis on kooskõlas projekti eesmärkidega. Kui projekti ajakava on loodud ja heaks kiidetud, saab sellest lähte- (või siht) ajakava. Integreeritud projekti edenemist mõõdetakse kogu projekti kestuse jooksul algse ajakava alusel. Edenemise analüüsimist baasgraafiku alusel nimetatakse teenitud väärtuse meetodiks.

Projekti planeerimise faasi sisenditeks on projekti põhikiri ja kontseptsiooniettepanekud. Projekti planeerimise etapi väljundid hõlmavad projekti nõudeid, projekti ajakava ja projekti juhtimisplaani.

Projekti planeerimist saab teha käsitsi, kuid sageli kasutatakse projektijuhtimise tarkvarapakette. Selliste komplekside hulka kuuluvad professionaalne Oracle Primavera ja igapäevasem MS Project.

Projektijuhtimise valdkonnas on projekti ajakava loend projekti verstapostidest, ülesannetest ja tulemustest, tavaliselt koos eeldatava algus- ja lõppkuupäevaga. Neid elemente hinnatakse sageli projekti ajakavas sisalduva muu teabe alusel, nagu ressursside jaotus, eelarve, ülesannete kestused, seosed, sõltuvused ja ajastatud sündmused. Projektide ajakava kasutatakse tavaliselt projektide portfelli kavandamisel ja haldamisel. Ajakava elemendid võivad olla tihedalt seotud tööjaotuse struktuuriga (WBS) võtmesündmuste, tööaruande või lepinguandmete kaudu.

Projekti ajakavade omadused

Paljudes tööstusharudes, näiteks inseneri- ja ehitusvaldkonnas, on projekti ajakava väljatöötamine ja säilitamine olenevalt projekti suurusest ettevõttesisese planeerija või planeerijate meeskonna ülesanne. Planeerimismeetodid on hästi välja töötatud ja järjepidevalt rakendatud kõikides tööstusharudes.

Tuleb märkida, et projektijuhtimine ei piirdu ainult tööstusega; tavaline inimene saab seda meetodit kasutada oma elu korraldamiseks. Mõned projektihaldusprogrammid, mallid, diagrammid ja näited aitavad kasutajatel ajakava koostada.

Projekti ajakavade koostamise meetodid

Enne ajakava koostamist peate välja töötama tööjaotuse struktuuri (WBS), hindama iga ülesande kulusid ja määrama ressursside loendi. Kui need ajakava komponendid pole saadaval, saab need luua konsensuspõhiste hindamismeetoditega, näiteks Delphi meetodiga. Põhjus on selles, et ajakava ise on hinnanguline: iga graafikus olev päev on hinnanguline ja kui need kuupäevad ei põhine tööd tegema hakkavate inimeste tegelikel kogemustel, siis ajakava ei ole täpne.

Selleks, et projekti ajakava oleks realistlik, peavad olema täidetud järgmised kriteeriumid:

• Ajakava tuleb pidevalt (soovitavalt iganädalaselt) uuendada (täiendada).
• EAS-i väärtus (skoor lõpetamisel) peab olema võrdne baasväärtusega.
• Koormus peab olema meeskonnaliikmete vahel õigesti jaotatud (arvestades nädalavahetusi).

SISSEJUHATUS

Projektijuhtimine seisneb plaani koostamises ja sellega seotud töö edenemise jälgimises. Seega, mida parem on projektiplaan, seda täpsemini see koostatakse, seda lihtsam on seejärel projekteerimistööd läbi viia ja projekti edukalt lõpule viia.

Et hästi planeerida, peate ennekõike omama head ettekujutust sellest, mis on projekt ja millistest elementidest see plaan koosneb.

Iga organisatsiooni tegevus on operatsioonide ja projektide läbiviimine. Mõlemal on palju ühist, näiteks teevad neid inimesed, mille jaoks on eraldatud piiratud ressursse.

Peamine erinevus toimingute ja projektide vahel seisneb selles, et toimingud on pidevad ja korduvad, samas kui projektid on ajutised ja ainulaadsed. Sellest lähtuvalt määratletakse projekti kui ajutist pingutust ainulaadse toote või teenuse loomiseks. "Ajutine" tähendab, et igal projektil on konkreetne algus- ja lõppkuupäev. Kui me räägime toote või teenuse unikaalsusest, siis peame silmas, et see erineb märgatavalt sarnastest toodetest või teenustest.

Iga projekti ainulaadsus tekitab raskusi selle planeerimisel, kuna sageli on raske ennustada, kuidas tulemused tegelikult saavutatakse. Seetõttu pole projektitegevuse tulemuseks mitte ainult toode või teenus, vaid ka saadud õppetunnid ehk kogemused, mida kasutatakse edaspidi järgnevate projektide kavandamisel ja teostamisel.

PROJEKTI PLANEERIMINE

Planeerimise etapp on üks olulisemaid. Selles etapis määratakse kindlaks projekti ülesanded, eelarve ja ajakava. Üsna sageli mõistetakse planeerimise all vaid tööde ajastamist, ressursside haldamise, eelarvestamise jms silmist kaotamist.

Täielik planeerimistehnika sisaldab järgmisi samme:

• 1) Projekti eesmärkide määratlemine ja nende kirjeldus. Üsna sageli algavad projektid ilma selge eesmärgita.
• 2) Tehnoloogiliste etappide määramine. Projektile tuleb valida teostustehnoloogia, mis määrab projekti arendamise etapid. Üks tüüpilisi planeerimisvigu on lahknevus plaani ja tehnoloogilise tsükli vahel.
• 3) Tehnoloogiliste etappide jaoks on vaja määrata ülesannete loend, näidata nende seosed (järjestus) ja prognoositav kestus (olenevalt määratud ressurssidest).
• 4) Vajalik on kokku leppida projektile eraldatavad vahendid. Tuleb märkida, et kõik ettevõtte ressursid tuleb jaotada tsentraalselt. Üsna sageli tekib planeerimisviga sellest, et mõningaid nappe ressursse kasutatakse samaaegselt kahes erinevas projektis korraga.
• 5) Kui määrate ressursside hinnad, saab eelarve ka automaatselt hankida. Üks tüüpilisi vigu on see, et eelarve määratakse ilma projekti prognoositavale maksumusele tähelepanu pööramata.
• 6) Kirjalik ülesanne, eelarve ja töögraafik moodustavad vormikohase „Projektiplaani” dokumendi. Üsna sageli on enne projekti algust mõni neist dokumentidest puudu, selle tagajärgi käsitletakse allpool.

Seega on projekti planeerimise õnnestumiseks olulised mitmed tegurid, mida tuleb arvesse võtta:

• · lahendatavate ülesannete klass, valmistoote eksemplaride arv, töö liik (arendus, arendus, tugi);
• · tööplaani (elutsükli mudeli) valimine arvestades projekti keerukust ja arendusmeeskonna võimalusi;
• · kogemus ainevaldkonnas ja arendusautomaatika vahendites;
• · arendajate varustamine automatiseerimisvahendite ning riist- ja tarkvarabaasiga;
• · klientide nõudmiste tase töö ajastamise ja kvaliteedi osas.

Hästi korraldatud projektis peaks iga eesmärgi elluviimise eest vastutama konkreetne juhtorgan: projektijuht, kõigi eesmärkide eest (projekti missioon), vastutavad eraeesmärkide täitjad jne. See tähendab, et projekti eesmärkide puu peab ühtima projekti elluviimise eest vastutava organisatsiooniüksuse struktuuriga. Selleks on väljatöötamisel nn vastutuspatriks, mis määratleb projekti teostajate funktsionaalsed kohustused ja täpsustab tööde komplekti, mille teostamise eest nad isiklikult vastutavad.

Planeerimise põhieesmärk on luua projekti elluviimiseks mudel.

Levinud planeerimisvead

Planeerimine valede eesmärkidega. Iga projekt on oma sisult mõeldud probleemi lahendamiseks, konkreetse vajaduse rahuldamiseks jne. Sõltuvalt sellest sõnastatakse teatud konkreetsed eesmärgid. Kui probleem on ebaselge ja selgelt sõnastatud, siis võib õige otsuse tegemisel kokku puutuda levinud veaga, kuid pole täpselt teada, mis konkreetse probleemiga on tegu.

Sellise olukorra vältimiseks on vaja välja selgitada töö tegelik alus: fikseerida - soovitavalt dokumentaalselt - kirjeldus probleemidest ja vajadustest, mis tuleb projekti lõpetamisel lahendada; teha kindlaks, kuidas konkreetsete probleemide lahendus kajastub projekti eesmärkide ja eesmärkide kirjelduses. Alles pärast seda võite alustada planeerimist.

Planeerimine mittetäielike andmete põhjal. Sarnane olukord on tüüpiline siis, kui on vaja planeerida töid, mille algus ja võib-olla ka selle teostamise fakt sõltub testkatsete tulemustest või eelmiste faaside õnnestumistest/ebaõnnestumisest.

Sarnane olukord tuleb sageli ette ka infosüsteemide arendamise ja kohandamise projektides. Kliendil on vastupandamatu soov saada valmis tööriist nii kiiresti kui võimalik. Siiski on tal vaid ähmane ettekujutus valitud tarkvara võimalustest ja sellest, mida ta automatiseerida soovib. Teisest küljest teavad tarkvara tarnijad väga vähe tegelikest juhtimisprotsessidest (funktsionaalsed, info-, organisatsioonilised struktuurid) kliendi organisatsioonis. Ja alles siis, kui nad hakkavad projekti ellu viima, algab vastastikuse teavitamise ja koolituse protsess. Väite täpsustamine toob kaasa töömahu olulise, mõnikord mitmekordse suurenemise ning selle eesmärkide ja koosseisu muutumise.

Planeerimine toimub ainult planeerijate kaasamisel. Selline planeerimisorganisatsioon võib oluliste tegurite arvestamata jätmise tõttu kaasa tuua olulisi kahjusid. Reeglina ununevad pealtnäha tähtsusetud detailid või asjaolud, mille täitmata jätmine võib aga kaasa tuua kolossaalseid kaotusi. Seetõttu tuleks planeerimisse kaasata ka konkreetse projektitöö eest vastutajad, projekti rahastamise, tarnete jms eest vastutajad. Rääkimata plaani elluviimise psühholoogilistest aspektidest, mille väljatöötamisel konkreetsed tegijad kaasa ei löönud.

Planeerimine eelnevat kogemust arvestamata. Isegi parimate hinnangute korral, ilma varasemaid kogemusi sarnaste projektide elluviimisel kasutamata, võib teha tõsiseid planeerimisvigu.

Ressursside planeerimine nende saadavust arvestamata. See puudutab ennekõike teatud kvalifikatsiooniga tööjõuressursse ja võimet jõuda kindlal ajal kindlasse kohta, et projektiga seotud tööd teha. Probleemiks on ka see, kui sama spetsialistide grupp on planeeritud mitmesse samaaegselt käimasolevasse projekti.

Planeerimine motivatsioone arvestamata. Reeglina meelitatakse projektidega töötama esinejaid funktsionaalsetest osakondadest, millel on oma. Juhtimine, oma eesmärgid ja konkreetsed ülesanded ning loomulikult oma töötasu vorm, millel pole tavaliselt projekti eesmärkide ja eesmärkidega mingit pistmist. Seetõttu ei tunne esinejad projektitöö vastutust ja olulisust ilma korralike stiimuliteta oma tegevuse tulemustele. Kuid projektijuhil ei ole piisavalt õigusi esinejate stimuleerimiseks ja ta ei saa projekti tulemuste põhjal moodustada rahalist ergutuseelarvet.

Planeerimine liigse detailiga. Kui projekt on liiga detailselt planeeritud , probleemid tekivad selle seisundi analüüsimisel, planeerimisel ja jälgimisel – näiteks, mis on valmis ja mis on viivitus. Lisaks on raske tõhusalt hallata suurt hulka ressursse, määrata viivitusi, hinnata kulusid ja koostada realistlikke, juhtimiseesmärkidel vastuvõetavaid ajakavasid. Liigne detailsus tegurite arvessevõtmisel toob kaasa vajaduse lahendada tohutul hulgal konflikte, sagedasi muudatusi, vajaduseni pidevalt kooskõlastada teiste samaaegselt teostatavate projektidega. Kuid liigne laienemine võib põhjustada ka probleeme kontrollitavuse kaotamisega. Kuldset keskteed on vaja siis, kui projektis planeeritakse ainult neid parameetreid, mida saab ja tuleks kontrollida.

Mida on vaja planeerimisvigade vältimiseks (mõned näpunäited):

• · projekti jaoks tuleb sõnastada lahendamist vajavate probleemide loetelu;
• · projekti (missiooni) põhieesmärk tuleb juhtida kõigi osalejate tähelepanu alla;
• · tuleb tuvastada riskid ja võimalusel välistada õnnetused;
• · on vaja tagada, et projekti strateegiat on võimalik ellu viia ning see vastaks eelarve-, aja- ja mahupiirangutele (viidi läbi PCTS teostatavusanalüüs: P - Performance, C - Cost, T - Time, S - Scope. Kulud on a taseme täitmise funktsioon P, aeg T ja sisu, töö maht S);
• · projekti elluviimise plusside ja miinuste analüüsi positiivsete tulemuste olemasolu (viidi läbi jõuvälja analüüs, mis koosneb projekti elluviimist soodustada või takistada võivate tegurite kirjeldamisest ja kvantitatiivsest hindamisest );
• · lõpptulemus peab olema kõigile projektimeeskonna liikmetele arusaadav;
• · projekti tegevuste tulemuste hindamise indikaatorid peaksid hindama asjade seisu vajaliku täpsusega. Soovitav on välja töötada ettevõttesisesed tulemuslikkuse hindamise skaalad tööliikide kaupa.

Projekti eesmärkide määratlemine

Esmalt eesmärkide seadmine tähendab, et projekt peab algama eesmärgi avaldusega. Sel juhul tuleb eesmärk kirjalikult fikseerida mõõdetavate näitajate kujul.

Probleemi sõnastamise etapp, see etapp viiakse läbi konsultatsioonilepingu alusel, s.o. etapimakse on ajapõhine. Ülesande ebakindluse tõttu ei ole võimalik selle maksumust ette planeerida. Lava maksumus on ligikaudu 10% kogu töö maksumusest.

Etapi põhitooteks on dokument “Probleemiavaldus” (Product Vision).

See dokument peaks määratlema projekti eesmärgi ja sisaldama põhinõuete loetelu ilma üksikasjaliku selgituseta. Oluline kriteerium: vaatamata üksikasjaliku kirjelduse puudumisele peab loetelu võimaldama statistiliselt hinnata tööjõu intensiivsust standardhälbega (riskiga) vastuvõetavas vahemikus.

„Probleemiavalduse“ alusel on nõutav „Majandusliku põhjenduse“ dokumendi koostamine.

See dokument peab sisaldama statistilist hinnangut töö tööjõumahukuse (maksumuse) kohta. Teisest küljest tuleb teha rakendamise majandusliku mõju analüüs.

Analüüsis kasutatakse sarnaste projektide tööjõumahukuse (efektiivsuse) statistikat. Selle statistika puudumisel on vead hinnangutes vältimatud, sellisel juhul peaksite proovima saada statistikat prototüüpide arendamise/esitlemise tulemuste põhjal.

Riskihinnang peab väljenduma võimaliku töömahukuse ületamise vormis (pessimistlik hinnang). Sellest hinnangust tuleks lähtuda toote kogu tööjõumahukuse (hinna) määramisel.

Sellest tulenevalt on meil “Probleemi avalduses” ebamääraselt sõnastatud ülesanne ja “Majanduslikus põhjenduses” hinnanguline maksumus. Ebaselgetest nõuetest tulenevad riskid tuleb pessimistlikult hinnata. Etapi läbimise tingimus: poolte poolt allkirjastatud “Probleemiavaldus” ja “Majanduslik põhjendus”.

Ressursijuhtimine ja planeerimine

juhtimisprojekti planeerimise ressurss

Ressursihaldus on projektijuhtimise üks peamisi alamsüsteeme. Hõlmab ressursside, tavaliselt tööjõu ja logistika planeerimise, ostmise, tarnimise, jaotamise, arvestuse ja kontrolli protsesse. Ressursijuhtimise ülesanne on tagada nende optimaalne kasutamine lõppeesmärgi saavutamiseks - projekti tulemuse kujundamiseks koos planeeritud näitajatega.

Materiaalsed ja tehnilised ressursid on toorained, materjalid, struktuurid, komponendid, energiaressursid, tehnoloogilised ressursid jne.

Tööjõuressursid on need, kes otseselt töötavad materiaalsete ja tehniliste ressurssidega.

Projekti materiaalsete ressursside juhtimine algab sisuliselt investeeringueelses faasis, kui planeerimisfaasis koostatakse tasuvusuuringud, töötatakse välja ressursivajadused ja nende pakkumise võimalus. Praktika näitab, et igal ajahetkel on ressursid piiratud ja seetõttu on ressursside haldamise peamised ülesanded järgmised:

• 1. Optimaalne ressursside planeerimine
• 2. Logistika juhtimine, sealhulgas:
  • · ressursside hankimise juhtimine;
  • · ressursside jaotamise juhtimine.

Ressursside mõiste on omavahel seotud mõistega "töö", kuna ressursid ei ole seotud projekti kui tervikuga, vaid konkreetse tööga, mida tehakse kavandatud järjestuses, mis vastab projekti töögraafikule.

Ostude ja tarvikute planeerimine ja korraldamine - projekti ressursside juhtimise esimene etapp. Koosneb etappidest, sealhulgas tarnijate valimine, tellimuste esitamine ja tarnete jälgimine.

Planeerimisetapis viiakse läbi tööpakettide ja tarbitud ressursside tasakaalustatud analüüs, võttes arvesse piiranguid ja nende prognoositavat jaotust ressursivajaduse graafikute alusel. Projekti ressursiplaneerimine on aluseks ressursivajaduse õigeaegse väljaselgitamisel ja ressursside hankimise võimaluste määramisel ressursside ostulepingute sõlmimiseks, ressurssidega varustamise planeerimiseks, samuti juba ostetud ressursside jaotamiseks projektitöödeks.

Projektijuhtimise põhikomponendina sisaldab ressursside planeerimine mitmeid komponente, sealhulgas:

• · projekti eesmärkide saavutamisele suunatud tööpakettide ja ressursside väljatöötamine ja tasakaalustatud analüüs;
• · ressursside jaotussüsteemi arendamine ja vastutavate täitjate määramine;
• · tööde edenemise jälgimine - planeeritud tööparameetrite võrdlemine tegelikega ja parandusmeetmete väljatöötamine.

Ressursid toimivad projektitöö komponentidena, sealhulgas teostajad, energia, materjalid, seadmed jne. Sellest lähtuvalt saab ressursivajaduse funktsiooni seostada iga tööga ning projekti kui terviku ressursivajadust saab arvutada ajakava meetodite ja sobitamismeetodid võivad tagada vastavusvajadused, kättesaadavuse või ressursside pakkumise.

Põhimõtteliselt tuleks projekti tegevuste ressursivajaduse täitmise kavandamisel arvestada ühe üldreegliga: iga ressursitüübi nõuete kogumaht projekti elutsükli igal ajahetkel ei tohi olla väiksem kui kogumaht. selle ressursi kättesaadavust sel hetkel, võttes arvesse reserve.

Projekti maksumuse prognoos

Olenevalt projekti elutsükli etapist ja hindamise eesmärgist kasutatakse projekti maksumuse hindamiseks erinevaid tüüpe ja meetodeid. Sõltuvalt hinnangute eesmärkidest on ka selliste hinnangute täpsus erinev. Me ei käsitle üksikasjalikult, kuid peate meeles pidama, et suurim viga ilmneb loomulikult projekti stabiliseerimisetapis, kui tuvastatakse ja parandatakse vigu teatud versioonis ei olnud õigesti rakendatud (tehnoloogia mõttes), kuid see viitab juba kirjaoskamatule disainile.

Projekti maksumuse hindamiseks peate teadma projekti moodustavate ressursside maksumust, töö tegemiseks kuluvat aega ja selle töö maksumust.

Seega algab kulude prognoosimine projekti ressursi- ja tööstruktuuri määramisest. Need ülesanded lahendatakse projekti planeerimise osana ja selle protsessi tulemused peaks saama kuluhinnangu moodul. Projekti maksumuse määravad vahendid töö tegemiseks vajalik.