Projekt plan. Projekt planering. Grundläggande koncept. Funktioner i resursplanering

Projektledning är en symbios av teknik och konsten att lösa en unik uppgift i tid inom den budget som avsatts för den. För att projektet ska slutföras framgångsrikt är det nödvändigt att uppnå en förståelse bland företagets ledning och RM hur det ska genomföras, av vem, när och vilken typ av arbete som ska utföras. Projektplanen betraktas inte som ett dokument, utan som en hel uppsättning dokumenterade lösningar som svarar på ovanstående frågor. Jag presenterar för din uppmärksamhet en recensionsartikel som undersöker grunderna i projektplaneringsteknik.

Kärnan i projektplanering

Projektplanering involverar många sammankopplade iterationer, varav resultatet är en enda översiktsplan. Genom projektplan kommer vi att ytterligare förstå systemet med planerade aktiviteter, dokumenterade som ett resultat av förberedelser. Detta system består av parametrar kopplade på ett speciellt sätt, vilket säkerställer att ett separat utvecklingsproblem löses. Dessa parametrar bildas baserat på ett antal funktionella områden av projektaktivitet:

• innehåll;
• deadlines;
• kosta;
• personal;
• leveranser;
• kommunikation;
• risker osv.

Planen är en viktig del av projektledningssystemet. Om PM lyckades utarbeta en detaljerad uppsättning planeringsdokument, har han rätt att förvänta sig garanterat mottagande av de erforderliga resultaten i slutet av arbetet. För detta måste timing, resurser och andra aspekter vara välplanerade. Innan en plan är framtagen är det omöjligt att veta hur mycket pengar och tid som kommer att krävas för att slutföra en unik uppgift. Utan en plan är chefen praktiskt taget berövad riktlinjer för arbetets överensstämmelse med projektets mål.

Du måste förstå att planering inte alltid i slutändan ger positiva resultat, men negativa slutsatser kan inte ge mindre, och ibland ännu större, fördelar. Hur som helst ökar effektiviteten av att investera medel, och "försvinnandet" av intjänade vinster sker inte. Projektering lägger grunden för produktivt arbete och löser följande tillämpade problem.

1. Förtydliga och detaljera evenemangets mål och resultat.
2. Bestäm sammansättningen och omfattningen av arbetet.
3. Uppskatta tidsramar och budgetkostnader.
4. Gör upp ett schema och budget för huvudfaserna eller hela projektet.
5. Gör en förfinad uppskattning av resursbehovet för varje fas eller för hela uppgiften.
6. Gör upp en resursplan.
7. Utför en riskbedömning och skapa en riskhanteringsplan.
8. Förklara detaljerna i händelsen för kunden.
9. Kom överens om planen med huvuddeltagarna.
10. Fördela ansvar för arbete och uppgifter mellan deltagarna.
11. Godkänn översiktsplanen.
12. Förtydliga interaktionsplaner och planeringshanteringsprocedurer.

Plats för projektledningsplanen i dess livscykel. Källa: PMBOK 5 Guide

Platsen för planeringsprocesser bland andra processer för projektgenomförande. Källa: PMBOK 5 Guide

Projektplanering kan inte lämnas i luften. Det föregås av initiering, och resultatet av dessa processer är själva genomförandet av projektet. Och vi känner igen ett antal viktiga punkter vid planering:

• knuten till en specifik tidpunkt i livscykeln för en unik uppgift och till dess betydande period (se diagrammen som visas ovan);
• iterativ – slutar inte efter att planerna har skrivits, kräver regelbunden uppdatering fram till den aktiva stängningsfasen;
• omfattande – inte begränsat till ett verktyg och inkluderar ett antal verktyg och relevanta utdatadokument.

Utökad sammansättning av planprocesser

Projektplanen skiljer sig från projektledningsplanen och relaterade planeringsprocesser. Som vi redan har definierat, i vid mening, menar vi med plan ett förplanerat system av aktiviteter för vilka ordningsföljden för utförande, sekvens och tidpunkt för arbetet är fastställda. I en snäv mening är en plan ett dokument som återspeglar ordningen på planerade åtgärder och deadlines för genomförande. En projektledningsplan är resultatet av reglerade planeringsprocedurer (processer), där kontrollprincipen övertas av regelbundna, reglerade rutiner för att skapa planer som dokument.

Definitioner av grundläggande planeringskoncept från PMI. Källa: PMBOK 5 Guide

Eventplanering inkluderar två grupper av processer: processer för direkt utveckling av planer och hjälpprocedurer. Utdata från ett utvecklingsblock är ett dokument som kallas en masterprojektplan. Den innehåller en kalenderplan, en evenemangsbudget och ett antal andra dokument. Sammansättningen och innehållet i arbetet, de nödvändiga resurserna för deras genomförande bestämmer sekvensen, varaktigheten och mängden av kostnaderna för deras produktion.

Potentiell riskplanering (identifiering, identifiering och bedömning) och deras hantering påverkar inte bara utvecklingen av tidsplanen utan även budgetbehov. Att tydliggöra målen, definiera gränserna för den unika uppgiften och strukturera teamet och ansvaret lägger grunden för en meningsfull projektplaneringsinsats. Därefter presenterar vi för din uppmärksamhet en modell av kopplingar mellan huvudprocedurerna för de processer som övervägs.

Modell av planeringsprocesser i projektledning

Det är känt att enligt PMI-standarden tilldelar nästan varje avsnitt av PMBOK-guiden ett helt block till planering. Baserat på diagrammet som presenteras ovan är detta ganska naturligt. PMBOK-sektionen "Project Integration Management" visar den mest holistiska bilden av planering och skapande av en enda översiktsplan. Nedan finns ett lokalt block av flödesdiagrammet för utvecklingsdata för händelsehanteringsplanen.

Lokal projektledningsplan utvecklingsdataflödesdiagram block

Det visuella blocket som presenteras ovan är anmärkningsvärt av ett antal anledningar. Kunskapsbasen om projektledning, all erfarenhet inom detta område och regelverk är avgörande för att planeringen ska lyckas. Det gäller även standarder, mjukvara, organisationsstruktur och kultur, ledningsmetoder, infrastruktur m.m. Stadgan är en viktig vägledning för planering. Dessa processer är grunden för integrationen i översiktsplanen och erbjuder följande som input för utvecklingen av dess slutliga version:

• förvaltningsplaner för projektparametrar;
• grundläggande planer för innehåll, kostnad och schema;
• planuppdateringar.

Stadier för att utveckla en kalenderplan

Som vi minns bygger projektledning på "tre pelare": arbetets innehåll, restriktioner och risker. Om en chef vet hur man arbetar bra med dessa tre parametrar, så finns det inga olösliga uppgifter för honom. Låt oss överväga utvecklingen av en kalenderplan utifrån dessa tre positioner och dela upp denna process i etapper. Vi kommer att hänvisa till det första och andra stadiet som innehållet i arbetet.

1. Stadiet för att bestämma och skriva listan över verk. Ganska ofta görs misstag på grund av att det inte går att presentera allt arbete på en gång. För att kvalitativt bestämma sammansättningen av operationer är det användbart att använda grunderna i metoden för sekventiell arbetsnedbrytning.
2. Stadiet för att bestämma genomförandet av projektet när det gäller sekvensen och varaktigheten av arbetet, som beror på tekniken för deras genomförande. För att skapa ett högkvalitativt resultat av detta steg är den redan nämnda metoden för sekventiell nedbrytning av uppgifter och expertbedömning av arbetets varaktighet med metoder som till exempel brainstorming väl lämpade.
3. Bestämma resurstillgänglighet. Evenemanget använder en mängd olika resurser: ekonomiska, material, arbetskraft, information, etc. Ur ett ekonomiskt perspektiv är det nödvändigt att koppla samman arbetsschemat med finansieringsschemat. Begreppet knappa resurser introduceras: unika specialister och kapaciteter. Detta lämnar ett avtryck i arbetets sekvens och varaktighet.
4. Definition av externa restriktioner. Dessa restriktioner inkluderar säsongsvariationer, tekniska processer för leverans av utrustning och olika externa händelser. Om vi ​​tar hänsyn till exemplet med speciella önskemål från kunden (för specifika partners) eller externa evenemang (till exempel tidpunkten för slutförandet av en scen för att sammanfalla med en nationell helgdag), så ingår sådana händelser i evenemanget i formen av milstolpar.
5. Stadiet för att skapa en riskhanteringsplan. Vi analyserar projektrisker och tar fram en insatsplan för de största hoten. Med hänsyn till denna plan slutför vi sedan schemat.

Den tredje och fjärde etappen relaterar till positionerna för restriktioner, den femte etappen - till risker. Två baser för svar (aktiv och passiv) bestämmer beslutstillfället och dess inkludering i projektplanen. Aktivt bemötande innebär att vi tar med merarbete i schemat som syftar till att minimera risker. Detta kan påverka tidpunkten för annat arbete.

Som ett exempel kan vi överväga ett projekt för att introducera en ny tjänst på marknaden. Låt oss säga att risken för bristen på efterfrågan på marknaden har identifierats. Sedan, för att minimera denna risk, är det nödvändigt att göra ytterligare forskning, och detta arbete måste ingå i schemat. Passiv respons innebär bildandet av ytterligare finansiella reserver för identifierade risker. Stadierna för att utveckla ett schema kan också presenteras i den logiska sekvens som presenteras nedan.

Logisk sekvens för att ta fram ett schema

Grundläggande projektplaneringsaktiviteter

För att skapa en översiktsplan implementerar projektledaren en serie planeringsiterationer. Under genomförandet av planeringsprocesser genereras viktiga instrumentella och slutliga dokument som tillsammans utgör översiktsplanen. Bland dem:

• hierarkisk arbetsstruktur (WBS);
• Nätverks diagram;
• kvalitetsstyrningsplan;
• projekt schema;
• budget;
• organisationsschema;
• riskregister;
• kommunikationsplan;
• huvudprojektplan.

Visuell modell av projektplaneringsprocesser

Ovan finns en modell av planeringsprocesserna för en projektuppgift. Du kan se den fullständiga sammansättningen av processerna i diagrammet. Planeringsprocesser för poolbanor är kopplade till nästan alla områden av projektledning. Många av de processer som anges i modellen kommer att ha möjlighet att presenteras i separata artiklar på vår hemsida. I detta material fokuserar vi kort på viktiga planeringsprocedurer.

1. Omfattningsdefinitionsprocessen utförs för att klargöra projektets omfattning, gränser med en beskrivning av dess produkt. Processen börjar med att klargöra evenemangets mål, dess koppling till företagets strategi och övervägande av varierande tillvägagångssätt för implementering. PM ska vara tydlig med vilket arbete som ligger utanför projektets ram och vilka produktkraven är.
2. Processen att bestämma omfattningen av arbetet. Grunden som lades i den tidigare processen utvecklas till hela skalan av nödvändiga operationer för att nå framgång. Deras struktur och sammansättning är relaterade till projektets huvudmål. WBS är det viktigaste verktyget som används av PM för att lösa problemet med den nuvarande processen.
3. Fastställande av arbetsrelationer. Den logiska sekvensen av arbetet är ämnet och syftet med denna process. Det bästa verktyget och resultatet av processimplementeringen är en nätverksmodell (diagram, graf), byggd och optimerad med PERT- och CPM-metoden.
4. Processen för att uppskatta arbetets varaktighet. Att prognostisera varaktigheten för varje aktivitet som ingår i WBS- och nätverksmodellen utförs baserat på en mängd olika tillvägagångssätt. Huvudmetoderna är bedömningsmetoder baserade på analoger, ”bottom-up”, från utförare, expert- och parametrisk bedömning.
5. Processen att bedöma resursbehov. Syftet med processen är att bestämma den erforderliga mängden mänskliga resurser, maskinresurser och mekanismer. Resurser delas in i grupper: förnybara, förbrukningsbara och finansiella.
6. Procedur för att utveckla en kalenderplan. Processen genomförs för att fastställa den beräknade tidpunkten för enskilda arbeten och projektet som helhet. Frågan om att detaljera planen är viktig. Djupet av dess utarbetande bör vara tillräckligt för att projektledaren ska kunna kontrollera arbetets framsteg och slutförandet av tilldelade uppgifter.
7. Utveckling av en masterprojektplan. Den kombinerar alla resultat av evenemangsplaneringsarbetet i ett enda integrationsdokument för projektet.

I den här artikeln har vi bekantat oss med den "maximala uppsättningen" av procedurer och dokument som skapar en projektplan. I praktiken, särskilt när projektet är medelstort eller litet i skala och är av regelbunden karaktär, krävs ofta inte överdrivna planeringsinsatser. I sådana fall kan du begränsa dig till standardlösningar för planering och en ofullständig uppsättning dokument. Samtidigt är det knappast möjligt att klara sig utan en grundläggande dokumentär som finns i en konsoliderad plan, och de ansträngningar som lagts ner på utvecklingen av den lönar sig väl.

Principer för projektplanering.

Arbetsfördelningsstruktur.

Projektering enligt tidsparametrar.

Projektnätverksplaneringsmetoder.

Organisering av projektplaneringsarbete.

Projektledning: lärobok / A.G. Ivasenko, Ya.I. Nikonova, M.V. Karkavin. – Rostov n/a: Phoenix, 2009. – P.177-212.

Mazur I.I. Projektledning: lärobok. manual för studenter som studerar inom specialiteten "Organisationsledning"/I.I. Mazur [och andra]. ; redigerad av I.I. Mazura och V.D. Shapiro. - 6:e uppl., raderad. - M.: Förlaget "Omega-L", 2010. -960 sid.

Kärnan i planering är att sätta upp mål och sätt att uppnå dem baserat på bildandet av en uppsättning arbeten (händelser, handlingar) som måste utföras, användningen av metoder och medel för att implementera dessa arbeten, koppla de resurser som krävs för deras genomförande , och samordna åtgärderna för de organisationer som deltar i projektet.

Planutvecklingsaktiviteter omfattar alla stadier av projektskapande och genomförande. Det börjar med deltagande av projektledaren (projektledaren) i utvecklingen av projektkonceptet, fortsätter med valet av strategiska beslut för projektet, såväl som i utvecklingen av dess detaljer, inklusive utarbetande av kontraktsförslag, kontraktering , utförande av arbete, och slutar med slutförandet av projektet.

På planeringsstadiet bestäms alla nödvändiga parametrar för projektgenomförande:

varaktighet för vart och ett av de kontrollerade delarna av projektet,

behovet av arbetskraft, materiella, tekniska och ekonomiska resurser,

leveranstider för råvaror, material, komponenter och teknisk utrustning,

tidpunkt och volymer för inblandning av design, konstruktion och andra organisationer.

Projektplaneringsprocesser och förfaranden måste säkerställa projektets genomförbarhet inom en given tidsram till en lägsta kostnad, inom gränserna för standardresurskostnader och med adekvat kvalitet.

I ett välorganiserat projekt bör ett specifikt ledningsorgan ansvara för genomförandet av varje mål: projektledaren för alla mål (projektuppdraget), ansvariga utförare för privata mål etc. Det vill säga att trädet av projektmål måste sammanfalla. med strukturen för den organisatoriska enhet som ansvarar för genomförandeprojektet. För detta ändamål utvecklas en så kallad ansvarsmatris, som definierar det funktionella ansvaret för projektutförare och specificerar uppsättningen av arbeten för vilka de är personligen ansvariga.

Ju högre nivå ledningsorganet har, desto mer generaliserade, aggregerade indikatorer fattar det beslut om förvaltningen av underordnade enheter. När hierarkinivån ökar, ökar tidsintervallet mellan utfärdande av planerade uppgifter, övervakning av deras genomförande, etc. Dessutom, i intervallen mellan ingripandemoment (utfärdande av planerade uppgifter, fastställande av riktmärken, etc.), arbetar enheter på lägre nivå oberoende. oberoende av enheterna samma eller intilliggande nivå. Avdelningarnas oberoende funktion måste säkerställas genom vissa resursreserver, som också måste planeras.

Huvudsyftet med planering är att bygga en modell för projektgenomförande. Det är nödvändigt att samordna projektdeltagarnas aktiviteter med dess hjälp, ordningen i vilken arbetet ska utföras etc. bestäms.

Planering är en uppsättning sammankopplade procedurer. Det första steget i projektplaneringen är utvecklingen av initiala planer, som ligger till grund för att utveckla projektbudgeten, fastställa resursbehov, organisera projektstöd, ingå kontrakt etc. Projektplanering föregår kontroll av projektet och är grunden för dess tillämpning. , eftersom en jämförelse görs mellan planerade och faktiska indikatorer.

Planering är en av de viktigaste processerna för ett projekt, eftersom resultatet av dess genomförande vanligtvis är ett unikt objekt, produkt eller tjänst. Planeringens omfattning och detalj bestäms av användbarheten av den information som kan erhållas som ett resultat av processen och beror på projektets innehåll (avsikt).

Planeringsprocessen i sig kan inte helt algoritmiseras och automatiseras, eftersom den innehåller många osäkra parametrar och ofta beror på slumpmässiga faktorer. Därför kan de planalternativ som föreslås som ett resultat av planering skilja sig om de utvecklas av olika team, vars specialister har olika bedömningar av inverkan av externa faktorer på projektet.

TILL huvudprocesser planering inkluderar:

planering och dokumentation av projektets omfattning;

göra uppskattningar, bedöma kostnaden för resurser som krävs för att slutföra projektet;

definition av arbete, bildande av en lista över specifika verk som säkerställer att projektmålen uppnås;

arrangemang (sekvens) av arbetet, identifiering och dokumentation av tekniska beroenden och restriktioner för arbetet;

bedömning av arbetets varaktighet, arbetskostnader och andra resurser som krävs för att utföra enskilda arbeten;

schemaberäkning, analys av tekniska beroenden av arbetsutförande, arbetslängd och resursbehov;

resursplanering, fastställa vilka resurser (människor, utrustning, material) och i vilka mängder som kommer att krävas för att slutföra projektarbetet. Bestämma inom vilken tidsram arbetet kan slutföras med hänsyn till begränsade resurser;

budgetering, koppla beräknade kostnader till specifika typer av aktiviteter;

skapa (utveckla) en projektplan, samla in resultaten av andra planeringsprocesser och kombinera dem till ett gemensamt dokument.

Hjälparprocesser utförs efter behov. Dessa inkluderar:

kvalitetsplanering, definiera kvalitetsstandarder som är lämpliga för ett givet projekt och hitta sätt att uppnå dem;

organisationsplanering (design), definition, kartläggning, dokumentation och fördelning av projektroller, ansvar och rapporteringsrelationer;

val av personal, bildande av ett projektteam i alla skeden av projektets livscykel, rekrytering av nödvändiga mänskliga resurser som ingår i projektet och arbete i det;

planering av kommunikation, fastställande av informations- och kommunikationsbehov hos projektdeltagare: vem behöver vilken information, när och hur den ska levereras till dem;

identifiering och bedömning av risker, fastställande av vilken osäkerhetsfaktor och i vilken utsträckning som kan påverka projektets framsteg, fastställande av gynnsamma och ogynnsamma scenarier för projektgenomförande, dokumentation av risker;

leveransplanering, bestämma vad, hur, när och med vem som ska köpas och levereras;

planera förslag, dokumentera produktkrav och identifiera potentiella leverantörer.

Att bestämma planeringsnivåer är också föremål för planering och utförs för varje specifikt projekt, med hänsyn till dess särdrag, skala, geografi, tidpunkt, etc.

Under denna process bestäms typen och antalet planeringsnivåer som motsvarar de tilldelade arbetspaketen för projektet, deras innehåll och tidsförhållanden.

Planer (grafer, nätverk) som ett uttryck för resultaten av planeringsprocesser bör tillsammans bilda någon pyramidstruktur som har egenskaperna att aggregera information, differentierad av nivåer av medvetenhetshantering, indelad i utvecklingsperioder (kortsiktig, medellång och lång sikt) -termin). Planeringsnivåer och plansystemet bör byggas med återkopplingsprinciper som säkerställer konstant jämförelse av planerade data med faktiska data och har stor flexibilitet, relevans och effektivitet.

Planeraär processen att allokera och tilldela resurser (material och mänskliga) med hänsyn till kostnaden och tiden för projektets slutförande. Planering är en av de viktigaste processerna för ett projekt, eftersom resultatet av dess genomförande vanligtvis är ett unikt objekt, produkt eller tjänst.

Grundläggande planeringsfunktioner ges nedan.

Omvandla behov till hanterbara uppgifter. Inledningsvis framträder projektet i form av krav utvecklade och överenskomna med kunden. Syftet med planeringen är att presentera dessa krav som en uppsättning individuella uppgifter, vars genomförande kan kontrolleras.

Bestämma de nödvändiga resurserna. Detaljerade planer kommer att avgöra antalet personer, utrustning som behövs och driftsförhållanden som kommer att behövas för att slutföra projektet.

Koordinering av teamarbete på projektet. Mycket ofta delas ett projekt upp i separata jobb som kan utföras parallellt. Planer gör det möjligt att samordna dessa aktiviteter genom att definiera vem som gör vad och när.

Bedömning av potentiella risker.Även om vissa risker kan identifieras vid kravformulering, upptäcks många fler efter att detaljplanering har skett. Genom att veta om förekomsten av dessa risker kan du märka dem tidigare (om de förverkligas) och förbereda dig för att ta itu med dem.

Larm när problem uppstår. Avvikelse från planen fungerar som en signal om att problem har uppstått. Planer är inte en dogm som måste följas villkorslöst. För projektledaren är det mer sannolikt att de är antaganden och ett underlag för jämförelse. Om projektet inte lever upp till förväntningarna måste planen anpassas därefter.

Grupp planeringsprocesser visas i fig. 3.10. Dessa processer kan upprepas och utgöra en del av en iterativ procedur tills ett visst resultat uppnås. Till exempel, om projektets ursprungliga slutdatum inte är acceptabelt, de resurser som krävs, kostnaden och ibland innehållet i projektet ( Projektledningsprocessgrupper

Planeringsprocessgrupp

Projekt Human Resource Management

Planera

Utveckling av en personalplan tekniska resurser

Definition

Projekttidsplanering

Definition

operationer

Kontrollera

integritet

Planering av upphandling

Projektkostnadshantering^

Kostnadsberäkning

Projektkvalitetsledning

Utveckling av en projektledningsplan

Definition

sekvenser

operationer

verksamhetsresurser

Planera

kvalitet

varaktighet

operationer

Utveckling

scheman

Projektriskhantering

Definition

Planera

förvaltning

risk

Genomföra en kvalitativ riskanalys

Genomföra kvantitativ riskanalys

Planera reaktioner på risker

Ris. ONDSKA. Planeringsprocesser

projektet måste ändras. Resultatet i detta fall blir de överenskomna villkoren, volymerna, utbudet av resurser, budget och innehåll för projektet, som motsvarar dess mål.

Planering är en nödvändig förutsättning för att utföra varje uppgift, även den enklaste. Otillräcklig planering kan resultera i projektmisslyckande eller olämpliga resultat i projektmiljön.

Planering i en eller annan form genomförs under hela projektets varaktighet. I början av ett projekts livscykel utvecklas vanligtvis en informell initial plan - en ungefärlig uppfattning om vad som kommer att behöva åstadkommas om projektet ska genomföras. Beslutet om projekturval baseras till stor del på utvärderingar av denna initiala plan. Formell och detaljerad projektering påbörjas efter att beslutet att genomföra den har fattats.

Planeringen består i att upprätta följande planer:

• utförandet av arbetet, inklusive bedömning av dess arbetsintensitet och tidsfrister;
• hantering av arbetets innehåll och omfattning;
• organisationsstruktur;
• konfigurationshantering;
• kvalitetshantering;
• riskhantering;
• upphandlingshantering;
• certifiering av designresultat och utförares aktiviteter.

Definition planeringsnivåerär också föremål för planering och genomförs för varje specifikt projekt, med hänsyn till dess särdrag, skala, geografi, tidpunkt, etc. Under denna process bestäms typen och antalet planeringsnivåer som motsvarar de tilldelade arbetspaketen för projektet, deras innehåll och tidsförhållanden.

Planer (grafer, nätverk) som ett uttryck för resultaten av planeringsprocesser bör sammantaget bilda någon pyramidformad struktur som har egenskaperna att aggregera information som är differentierad av nivåer av medvetenhetshantering, och bör ske efter utvecklingsperioder (kortsiktig, medellång sikt) -siktigt och långsiktigt). Planeringsnivåer och plansystemet måste byggas med återkopplingsprinciper, vilket säkerställer konstant jämförelse av planerade data med faktiska data, de måste ha stor flexibilitet, relevans och effektivitet.

Nätverksplaner konsolideras på grund av att den allmänna nätverksplanen består av många privata nätverksplaner. I var och en av dessa privata planer bestäms den längsta vägen. Dessa vägar sätts sedan i stället för enskilda delar av nätverket. Med hjälp av sådan gradvis aggregering erhålls nätverksplaner på flera nivåer (Fig. 3.11). Vanligtvis finns det en konceptuell plan, en strategisk plan för projektgenomförande och taktiska (detaljerade, operativa) planer.

Nätverksplan med flera projekt (för högsta ledningen)

Nivå 1

Nivå 3

Nivå 2

Nätverksplan med nyckelstadier (milstolpar)

Detaljerad nätverksplan

Ris. 3.11.Flernivånätverksplaner

Konceptuell planering, som resulterar i en konceptuell plan, är processen att utveckla grundläggande projektdokumentation, tekniska krav, uppskattningar, detaljerade scheman, kontroll- och ledningsprocedurer. Konceptuell planering sker tidigt i projektets livscykel.

Strategisk planeringär processen att utveckla strategiska, integrerade, långsiktiga planer.

Detaljerad (operativ, taktisk) planering kopplat till utvecklingen av taktiska, detaljerade planer (scheman) baserade på den hierarkiska arbetsstrukturen (WBS) för operativ ledning

på nivån för ansvariga utförare.

Planera innehållshantering. En av de vanligaste "sjukdomarna" i programvaruprojekt kallas "krypande featureism" när ett skjul för förvaring av trädgårdsredskap först läggs till den ursprungligen designade montern för en älskad hund, och sedan ett hus i flera våningar för sin ägare. Och de försöker bygga allt detta på samma grund och från samma material. Detta tillvägagångssätt har varit dödsorsaken för många programvaruutvecklingsprojekt. Därför, så snart det var möjligt att stabilisera och komma överens om WBS - den hierarkiska strukturen i arbetet, är det nödvändigt att utveckla förvaltningsplan för projektomfattning, för vilket du bör:

• identifiera källor till ändringsförfrågningar;
• upprätta ett förfarande för analys, utvärdering och godkännande/förkastande av innehållsändringar;
• fastställa förfarandet för att dokumentera innehållsändringar;
• fastställa förfarandet för att informera om ändringar i innehållet. Den första uppgiften som måste lösas när man analyserar en förfrågan

för ändringar - identifiera förändringsobjekt: krav, arkitektur, datastrukturer, källkoder, testskript, användardokumentation etc. Sedan är det nödvändigt att designa och i detalj beskriva förändringarna i alla identifierade objekt. Slutligen bör kostnaderna för att göra dessa ändringar, testa ändringarna och deras inverkan på projektets tidslinje bedömas. Detta arbete kommer att kräva tid som spenderas, och ibland betydande, av olika specialister: analytiker, designers, utvecklare, testare, såväl som en projektledare, och därför måste det beaktas i planen.

Planering av organisationsstruktur.Organisationsstruktur- detta är en överenskommen och godkänd fördelning av roller, ansvar och mål för nyckelprojektdeltagarna. Det måste nödvändigtvis innehålla följande:

• ett system för arbetsrelationer mellan projektarbetsgrupper;
• rapporteringssystem;
• bedömningar av projektets framsteg;
• beslutsfattande system.

Man bör komma ihåg att projektets organisatoriska struktur är en "levande" organism. Det börjar ta form på planeringsstadiet och bör förändras allt eftersom projektet fortskrider. Instabilitet i organisationsstrukturen (frekventa förändringar av utförare) kan bli ett allvarligt problem i projektledning, eftersom det finns en ersättningskostnad som bestäms av den tid då en ny deltagare går in i projektsammanhanget.

Planering för konfigurationshantering. En av de viktiga processerna för mjukvaruproduktion är konfigurationshantering. Mer än en bok har skrivits om detta kunskapsområde. Här ska vi bara prata om hur detta arbete ska planeras. Hanteringsplanen för projektkonfigurationen bör innehålla:

• arbeta för att säkerställa ett enda arkiv för all projektdokumentation och utvecklad programkod, vilket säkerställer säkerhet och återställning av projektinformation efter ett misslyckande;
• arbete med att sätta upp arbetsstationer och servrar som används av projektteammedlemmar;
• arbete som krävs för att organisera sammansättningen av mellanliggande versioner av systemet, såväl som dess slutliga version.

Detta arbete utförs vanligtvis av en konfigurationsingenjör. Om projektet är litet kan den här rollen vara ytterligare för en av programmerarna eller projektledaren. Att ”sprida” detta arbete över alla projektdeltagare är för det första ineffektivt. Att installera och konfigurera utvecklingsmiljöer, såsom databaser och applikationsservrar, kräver specifik kompetens och kunskap om specifika produktversioner. Om alla utvecklare måste lära sig dessa färdigheter kommer det att ta för mycket arbetstid. För det andra kan "spridningen" av konfigurationshanteringsarbetet leda till kollektivt ansvarslöshet, när ingen vet varför "projektet inte kommer att fungera" och hur man "rullar tillbaka" till den tidigare versionen.

Konfigurationshantering kan bli mycket mer komplex om projektgruppen, parallellt med utvecklingen av ny produktfunktionalitet, måste stödja flera releaser av denna produkt som tidigare installerats av olika kunder, men allt detta arbete måste tas med i projektet planen.

Kvalitetsledningsplanering. Ett annat grundläggande kunskapsområde inom mjukvaruteknik är kvalitetssäkring. Det finns olika åsikter om vad mjukvarukvalitet är och hur man effektivt säkerställer den. Låt oss begränsa oss till påståendet att kvalitetssäkring är ett ganska viktigt arbete som bör planeras i förväg och genomföras genom hela mjukvaruprojektet, och inte bara under acceptanstest.

När man planerar detta arbete är det nödvändigt att förstå att projektprodukten inte ska ha högsta möjliga kvalitet, vilket är ouppnåeligt på en begränsad tid. Den erforderliga kvaliteten på en produkt bestäms av kraven för den. Kvalitetssäkringens huvuduppgift är inte att söka efter fel i den färdiga produkten (output control), utan att förhindra dem under produktionsprocessen.

Kvalitetsledningsplan bör innehålla följande arbete:

• objektiv verifiering av överensstämmelse för mjukvaruprodukter och tekniska operationer med tillämpliga standarder, procedurer och krav;
• identifiera kvalitetsavvikelser, identifiera deras orsaker, vidta åtgärder för att eliminera dem, samt övervaka genomförandet av vidtagna åtgärder och deras effektivitet;
• förse högsta ledningen med oberoende information om avvikelser som inte åtgärdas på projektnivå.

Förtydligande av verkets innehåll och sammansättning. Förtydligande av projektets innehåll (nedbrytning) är en av de viktigaste komponenterna i projektledningsdisciplinen. Detaljering gör det möjligt att uppskatta till exempel den totala kostnaden för ett projekt genom den totala kostnaden för dess enskilda arbeten. Resultatet av att detaljera projektets innehåll är struktur för arbetsuppdelning(Work Breakdown Structure - WBS). I de flesta fall är denna struktur hierarkisk. Samtidigt är själva detaljeringsprocessen arbetsfördelningsstruktur, dvs. aktivitet för att skapa en detaljerad struktur av arbets- eller projektuppgifter.

Hierarkisk struktur av arbetet(WBS) är en resultatorienterad uppdelning av det arbete som utförs av projektgruppen för att uppnå projektmålen och önskade resultat. Med dess hjälp struktureras och bestäms hela projektets innehåll. Varje efterföljande nivå i hierarkin återspeglar en mer detaljerad definition av projektelementen. Grunden för utvecklingen av WBS är projektkonceptet, som definierar projektprodukterna och deras huvudsakliga egenskaper. WBS säkerställer att allt arbete som krävs för att uppnå projektets mål identifieras. Många projekt misslyckas inte för att de inte har en plan, utan för att planen försummar viktigt arbete som testning och buggfixning, samt projektprodukter som användardokumentation. Därför, om WBS är korrekt sammanställt, kan allt arbete som inte ingår i det inte betraktas som arbete på projektet. WBS delar upp projektet i delprojekt, arbetspaket och delpaket. Varje efterföljande nivå av nedbrytning ger konsekvent detaljering av projektinnehållet, vilket gör det möjligt att uppskatta tidpunkten och omfattningen av arbetet. WBS måste inkludera alla mellanprodukter och slutprodukter.

Det finns olika sätt att bryta ner arbetet i ett projekt. Till exempel tillhandahåller GOST 19.102-77 vattenfall närmar sig och definierar följande stadier av mjukvarusystemutveckling.

• 1) tekniska specifikationer;
• 2) preliminär design;
• 3) teknisk design;
• 4) arbetsutkast;
• 5) genomförande.

Om vi ​​följer denna standard bör dessa designprodukter vara på den första nivån av WBS. Om vi ​​var tvungna att utveckla ett automatiserat kontrollsystem för att styra en kärnreaktor eller en bemannad rymdfarkost, så är det precis vad som borde ha gjorts. Men i kommersiell mjukvaruutveckling är detta tillvägagångssätt ineffektivt.

Den moderna kommersiella mjukvaruutvecklingsprocessen måste vara inkrementell. Detta innebär att den översta nivån i projektnedbrytningen bör innehålla projektets produkter och nästa nivå bör innehålla de komponenter som dessa produkter består av. Komponenter kan ytterligare delas upp i "funktioner" - de funktioner som de måste implementera.

Att isolera komponenterna som utgör en mjukvaruprodukt är en del av design på hög nivå som bör utföras under projekteringsfasen, utan att vänta på att alla funktionskrav för mjukvaran som utvecklas ska utarbetas. Komponenter kan vara både applikationsdelsystem och infrastruktur eller nukleära sådana, till exempel ett autentiserings- och säkerhetsundersystem, ett bibliotek med visuella komponenter i ett grafiskt gränssnitt (GUI). När du gör upp en grundläggande arbetsplan bör du inte sträva efter att detaljera allt WBS-arbete så mycket som möjligt. 3-5 nivåer räcker.

I samband med detaljering används termerna "uppgifter" och "arbete" ofta omväxlande. Ändå är det mer korrekt att säga att uppgiften avgör uppnåendet av ett mellanresultat, och arbetet är en uppsättning åtgärder för att uppnå dessa resultat. Eftersom varje uppgift kräver att visst arbete utförs under givna begränsningar, kan vi säkert tala om den otvivelaktiga "kartläggningen" av uppgifter till arbete och vice versa. Detta är anledningen till utbytbarheten av termer i vardagen. Samtidigt, genom att förstå skillnaderna mellan dessa begrepp, kan du känna nyanserna i processvyn för att skapa en produkt, och därför livscykeln för projekt, inklusive programvarusystemprojekt.

I allmänhet kan vi prata om detalj: "program - projekt - uppgiften är operationen.” I fig. Figur 3.12 ger ett exempel på sådan detaljering (endast uppgiftsoperationer visas A).

Ris. 3.12.Ett exempel på användning av termer: program, projekt, uppgift, operation

Varje element i en sådan struktur är associerad med begränsningar och andra betydande egenskaper och data. Relevans hänvisar till deras nödvändighet eller användbarhet för beslutsfattande. Detaljdjupet och tillämpningsnivån för vissa termer beror på det specifika projektet, ledningskulturen, livscykelstandarder, projektets särdrag och omfattning, såväl som andra faktorer som är unika för både en specifik organisation och ett specifikt projekt.

Personligt ansvar ska etableras för alla delar av projektet (delprojekt och arbetspaket). För varje arbetspaket måste utdataresultatet vara tydligt definierat. Arbets- och projektuppskattningar ska överenskommas med nyckelteammedlemmar, ledning för det utförande företaget och vid behov med kunden. Som ett resultat av en överenskommelse åtar sig teammedlemmarna skyldigheter att genomföra projektet, och ledningen tar ansvar för att förse projektet med de nödvändiga resurserna.

WBS är ett av huvudverktygen (medlen) i projektledningsmekanismen, med hjälp av vilken graden av uppnående av projektresultat mäts. Dess viktigaste funktion är att säkerställa att alla projektdeltagare förstår och förstår hur projektet ska genomföras. Därefter kommer baslinjen att fungera som en guide för jämförelse med det aktuella genomförandet av projektet för att identifiera avvikelser.

Kostnadsuppskattning av projektet. Processen att hantera ett programvaruprojekt börjar med många aktiviteter, förenade med ett gemensamt namn projekt planering. Den första av dessa åtgärder är utföra kostnadsuppskattning av projektet. Det lägger grunden för andra projektplaneringsaktiviteter. När man utvärderar ett projekt är kostnaden för misstag extremt hög. Det är mycket viktigt att genomföra bedömningen med minimal risk.

Den största svårigheten med algoritmisk modellering av projektkostnad är beroendet av kostnadsberäkningen på egenskaperna och parametrarna för den färdiga produkten. I ett tidigt skede av projektet är det omöjligt att exakt bestämma dessa egenskaper och parametrar. Det finns många metoder för att uppskatta kostnaden för programvara som bör användas parallellt. Om resultaten är mycket olika betyder det att otillräcklig eller olämplig information använts för analysen. Programvarupris ofta bestämt i förväg i entreprenadsyfte, vilket leder till en efterföljande anpassning av systemets funktionalitet till de som skulle motsvara detta pris.

Känd projektkostnadsuppskattningsmodell B. Boema SOSOMO tar hänsyn till designegenskaper, egenskaper hos programvaran som skapas, hårdvara och personalkapacitet. Denna modell innehåller också verktyg för att bestämma varaktigheten av arbetet med ett projekt. Den tid som krävs för att slutföra arbetet beror inte direkt på antalet specialister som anlitats för projektet. Att lägga till fler personer till ett projekt som ligger efter schemat kan ytterligare försena dess slutförande.

Algoritmiska projektkostnadsmodeller används för att hantera programvaruprojekt eftersom de stöder kvantitativ parameteranalys. Dessa modeller låter dig utvärdera bidraget från varje enskild parameter till den totala kostnaden för projektet och göra en objektiv (men inte immun mot fel) jämförelse av dessa parametrar.

Projektkostnadsuppskattning- ett av de viktigaste arbetena på projektet, som bestäms utifrån kostnaden för enskilda delar av projektet, förutsättningarna för att utföra arbetet, den faktiska personalen av utförare, de metoder och verktyg som används. I kostnaden för projektet ingår även kostnaderna för att driva projektet, d.v.s. datorer, mjukvara, utrymme, möbler, telefoner, modem och mycket mer. Dessutom måste ibland extra kostnader (till exempel säkerhet) beaktas. Merkostnader för projektet inkluderar inköp av testsystem, CABE-system etc. Huvudbedömningen i projektet är kostnadsberäkning för projektet, uttryckt i arbetsdagar av artister i projektet. Denna bedömning görs i ett tidigt skede av förvaltning och planering.

Den totala kostnaden för projektet bestäms av erfarna specialister med ett fel på upp till 10%. Kostnadsuppskattning kan vara top-down, bottom-up eller baserad på kostnaden för en tidigare tillverkad design. Experter gör pessimistiska, optimistiska och realistiska bedömningar genom att intervjua alla medlemmar i arbetsgruppen och justera varje bedömning för att få den mest rimliga. I vissa arbetsgrupper kan pessimistiska och optimistiska bedömningar vara mycket olika.

Algoritmiska metoder för att uppskatta projektkostnader visa sambanden mellan projektkostnader och de faktorer som påverkar dem.

Det finns olika empiriska metoder för att uppskatta kostnaden för ett projekt, till exempel föreslås kostnaden för ett projekt bestämmas med hjälp av formeln

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

där 5 är en viss uppskattning av systemets storlek; a, b, c - empiriska konstanter; X - vektor av kostnadsfaktorer med dimension fre - regulatorisk multiplikator baserad på kostnadsfaktorer.

En mer förenklad uppskattning erhållen experimentellt uttrycks enligt följande:

KOSTNAD = 5,255 0,91 .

Dessa uppskattningar härleddes från en analys av projekt där program varierade i storlek från 4 000 till 467 000 rader kod och skrevs på 28 olika programmeringsspråk på 66 datorer. Från 12 till 11 758 manmånader ägnades åt utveckling. Andra empiriska modelleringstekniker är också kända.

De första modellerna använde prisindikatorer, tog hänsyn till personal och egenskaper hos projektet, produkten och miljön. I modellerna ingår en bedömning av tre stadier av projektledning. I det första skedet byggs en prototyp för högriskuppgifter (användargränssnitt, mjukvara, interaktionssystem, implementering etc.) och kostnader uppskattas (exempelvis antal tabeller i databasen, skärmar och rapporteringsformulär etc.) .). I det andra steget bedöms kostnaderna för design och genomförande av projektfunktionella punkter, vilka återspeglas i projektkraven. I det tredje steget avser uppskattningen den genomförda projekteringen, då storleken på systemet kan bestämmas i termer av genomförda programlinjer och andra faktorer.

Den grundläggande modellen för experimentell uppskattning av projektkostnader idag är följande ekvation:

KOSTNAD = bS c m(X),

Var bS c - primär uppskattning som justeras med hjälp av en kostnadsvektor t(X) och redovisning av antalet gamla och nya föremål; Med- en parameter som varierar från noll till en för den första etappen av projektet och från 1,01 till 1,26 för de återstående stegen.

Med ett formaliserat tillvägagångssätt baseras projektbedömningen på användningen av LOC- och FP-mått.

Konstruktiv kostnadsmodell(SOSOMO - Constructive cost model), föreslagen av B. Boehm, kombinerar de mest välkända formaliserade projektbedömningsteknikerna - LOC uppskattningar(LOC - Kodrader), som baseras på antalet rader med programkod. I processen att tillämpa denna modell bildas preliminära uppskattningar som gör det möjligt att presentera kunden med korrekta krav på kostnaden och kostnaderna för att utveckla mjukvaran, och även säkerställa möjligheten att upprätta en mjukvaruplan.

Funktionsorienterade FP-mått Istället för att beräkna LOC-poäng mäter de indirekt mjukvaruprodukten. Det är inte storleken som avses, utan produktens funktionalitet eller användbarhet. Författaren till detta mått är A. Albrecht. Att bestämma den funktionella storleken består av flera steg och börjar med att identifiera de funktioner som applikationen ska ha. International Function Point Users Group (IFPUG) har publicerat kriterier för vilka applikationsfunktioner bestäms. Vid beräkning av FP-måttet används fem informationsegenskaper: antalet externa ingångar; antal externa utgångar (utdata betyder rapporter, skärmar, utskrifter, felmeddelanden); antal externa förfrågningar; antal interna logiska filer; antal externa gränssnittsfiler.

Efter att ha samlat in all nödvändig information, fortsätt till beräkning av mått - bestämma antal funktionspekare FP (Function Points) enligt en viss formel, där värdena för ingångskompl(varje koefficient kan ta följande värden: 0 - ingen påverkan; 1 - slumpmässigt; 2 - liten; 3 - genomsnittlig; 4 - viktigt; 5 - huvud) väljs empiriskt i som ett resultat av svar på 14 frågor som kännetecknar applikationens systemparametrar.

Metoden består i att mäta alla möjligheter hos en applikation enhetligt för alla projekt och att uttrycka storleken på applikationen som ett enda tal, som sedan kan användas för att uppskatta antalet kodrader, kostnaden och tidpunkten för projektet. På grundval av den bildas mått på produktivitet, kvalitet etc.

Fördel funktionsorienterade mått är att de inte är beroende av programmeringsspråket och är lätta att beräkna i alla skeden av projektet.

Brister funktionsorienterade mätvärden - resultaten är baserade på subjektiva data snarare än direkta mätningar. Dessutom måste du ha vissa färdigheter för att tillämpa denna metod exakt och konsekvent.

Med hjälp av standardtabeller kan FP-uppskattningar enkelt omvandlas till LOC-uppskattningar, d.v.s. Beräkna antalet kodrader utifrån den funktionella storleken. Resultaten av konverteringen beror dock på vilket programmeringsspråk som används för att implementera programvaran (till exempel i Java är en enhet av funktionell storlek lika med 53 rader källkod). I sin tur låter antalet kodrader dig bestämma den totala arbetsintensiteten, uttryckt i personmånader, och projektets tidslinje.

När man utför en bedömning finns det två möjliga användningsområden för LOC- och FP-data: som uppskattningsvariabler som bestämmer storleken på varje produktelement, eller som mätvärden som samlats in under arbetet med tidigare projekt och som ingår i företagets metriska bas.

Exempel 3.1. Låt oss överväga proceduren för att utföra proceduren för att bedöma arbete baserat på ShS-måttet.

Steg 1. Ändamålsområdet för den designade produkten är uppdelat i ett antal funktioner/i,/2,/3, som var och en kan

utvärdera individuellt

Steg 2. För varje funktion/schemaläggare genererar det bästa LOC n, värsta YUS X och troligt YUS V bedömningar. I processen att skapa uppskattningar används experimentella data från den metriska basen eller intuitiva idéer från planeraren. Omfånget av möjliga uppskattningar motsvarar graden av osäkerhet.

Steg 3. För varje funktion med bedömningens förväntade värde bestäms:

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

yus.

Steg 4. Värdet av AL-prestanda för funktionsutveckling beräknas i enlighet med en av tre regler.

Regel L. För alla funktioner tas samma värde, lika med den genomsnittliga produktiviteten för PR avg, taget från den metriska basen, dvs.

PR, = PR-genomsnitt; / = 1, 2, ..., P.

Regel B. För den i-te funktionen beräknas ett anpassat prestandavärde baserat på det genomsnittliga prestandamåttet:

ys sr

MS coolt ’

Var YUS ons - genomsnittlig LOC-poäng hämtad från den metriska basen (motsvarar genomsnittlig produktivitet).

Regel B. För den i:te funktionen beräknas det justerbara prestandavärdet med den valda analogen (tagen från den metriska basen):

BOSdnI

Fru Ozhi

Användningen av regel A i ytterligare steg säkerställer minimal noggrannhet med maximal enkelhet i beräkningar. Regel B låter dig uppnå maximal noggrannhet med maximal beräkningskomplexitet.

Skede 5. Den totala kostnadsuppskattningen (person-månad) för projektet beräknas om Regel A används:

om regel B eller C används:

b1у ^ozh/

Steg 6. Den övergripande uppskattningen av projektkostnaden beräknas om regel A eller B används:

KOSTNAD = UDST genomsnitt yuS 0Zh/ ;

om regel B används:

KOSTNAD = UDST an/ ^YUS 0Zh/ ,

där UDST avg är ett mått på den genomsnittliga kostnaden för en rad programkod; UDST an, - måttenhet av kostnaden för en linje av analog (båda måtten tas från den metriska basen).

Utveckling av ett projektschema. Efter att ha bestämt arbetsintensiteten för arbetet är det nödvändigt att bestämma schemat för deras genomförande och den övergripande tidsramen för projektet, d.v.s. upprätta ett arbetsschema för projektet Grundschema representerar ett godkänt schema med specificerade tidsfaser för projektet, milstolpar och delar av arbetets hierarkiska struktur.

Grundschemat är i de flesta fall en del av kontraktet med kunden. Kontrollpunkter (milstolpar) fungera som punkter för att analysera projektets status och fatta beslut i formatet "§o eller po1 §o", därför bör de synligt visa projektets status. Det finns vissa krav för val och bildande av kontrollpunkter, till exempel är kontrollpunkten "Design är klar" oinformativ den sekventiella leveransmetoden anses vara ett mer effektivt tillvägagångssätt: den ovan nämnda kontrollpunkten är formulerad i formen "; Testning av krav 1, 3, 5 och 7 är klar.”

Om verken inte är relaterade till varandra, så kan vilket som helst av dem påbörjas och slutföras när det passar oss; allt arbete kan utföras parallellt, i vilket fall projektets minsta varaktighet är lika med varaktigheten av det längsta arbetet. Men i praktiken finns det oftast beroenden mellan jobb som kan vara "hårda", till exempel "analys - design - kodning - testning - dokumentation" av en specifik funktion, eller "mjuka", som kan revideras eller mjukas upp till exempel , det sekventiella utförandet av uppgifter av en specifik utförare kan schemaläggas till en annan entreprenör, och istället för att utveckla grundläggande programvara, som måste föregå utvecklingen av applikationsprogramvara, kan du skapa "stubbar" som efterliknar dess arbete.

Utvecklingen av en arbetsplan med deadlines för deras implementering kan utföras med hjälp av den kritiska vägmetoden CPM eller metoden för analys och utvärdering av PERT-program. Projektplanen presenteras i termer av stegen: ”Planering”, ”Design”, ”Kodning”, ”Testning” och ”Underhåll”. Planering avser fastställande av specifikationer, budget och tidsplan, samt utveckling av den övergripande projektplanen.

I projektkritisk väg metod(Kritisk väg) den längsta arbetskedjan i projektet används. Att öka varaktigheten av allt arbete i denna kedja leder till en ökning av varaktigheten för hela projektet. Det finns alltid minst en kritisk väg i ett projekt, men det kan finnas flera. Den kritiska vägen kan ändras under genomförandet av projektet.

När man utför ett projekt måste chefen först vara uppmärksam på utförandet av uppgifter längs den kritiska vägen och övervaka uppkomsten av andra kritiska vägar. Det finns en praktisk rekommendation: på den kritiska vägen bör det finnas arbete med icke-styva kopplingar, som alltid kan schemaläggas om det finns ett hot om att deadlines saknas. Arbetsschemat är uppställt enligt diagrammet som visas i fig. 3.13.

Kravschema

till projektet

Ris. 3.13.Steg för att schemalägga arbete med ett projekt

När man planerar för metod för programanalys och utvärdering En PERT-händelse eller ett datum i planen är en viss milstolpe (kontrollpunkt) längs vägen för individuellt projektarbete och används för att visa/markera slutförandestatus för vissa arbeten. Inom ramen för ett projekt använder chefer milstolpar för att identifiera viktiga delresultat som måste uppnås under projektets gång.

Den sekvens av milstolpar som definieras av chefen kallas ofta milstolpeplan (efter händelser). Att definiera en plan för att uppnå relevanta milstolpar skapar ett milstolpebaserat schema.

På planeringsstadiet kan även en nätverksuppdelning av arbetet och ett Gantt-diagram användas.

Nätverksuppdelning av arbetet(SPP) är en hierarkisk struktur för att bryta ned projektuppgifter i deluppgifter. På den lägre nivån finns arbeten som är detaljerade i aktivitetselement i nätverksmodellen av systemet av fungerande system.

Nätverksmodellen låter dig bryta ner arbetet i huvudkomponenter och delkomponenter, bestämma verksamhetsområden som syftar till att uppnå komplexa mål, fördela de ansvariga för genomförandet av individuellt arbete på projektet och slutföra rapportering som sammanfattar information om projektets resultat.

Arbetsplanen ska återspegla arbetets huvudstadier och det erforderliga arbetsläget i varje steg, uppdelningen av varje arbete i separata uppgifter, samt samband mellan arbeten, tidsintervall för att slutföra varje aktivitet, start- och sluttider för arbetet. Arbetsplanen innehåller olika typer av demonstrationer av projektfunktioner, delsystem, tillförlitlighet, skyddsutrustning etc. Plandokumenten innehåller även en uppsättning manualer och tekniker för att utföra specificerade operationer, upprätthålla systemkopplingar med andra delsystem m.m.

Arbetsplanen i form av en WBS-graf innehåller faser (stadier), steg och aktiviteter, inklusive de inledande och slutliga aktiviteterna i processen (Fig. 3.14).

Fas Och

Steg 1 Steg 2

Ris. 3.14.Steg-för-steg projektplan graf

En annan form av visuell representation av arbetsplanen kan vara Nätverks diagram, specificeras i form av en graf, vid vars hörn arbetsobjekt är belägna och på bågarna - antalet dagar (veckor) som krävs för att slutföra dem (fig. 3.15). Dessa markeringar används för att ställa in exekveringstiden för processen. Båge som lämnar initialen

Ris. 3.15.

vertex och att gå in i den sista vertexen, motsvarar tidsstämpeln "noll".

Grafen kan innehålla cykliska banor. Grafen används för att analysera kritiska vägar, d.v.s. fastställa uppgifter om varaktigheten av varje process.

Att ta fram ett schema består av att bestämma startpunkten (en händelse eller en uppsättning händelser som inträffade före starten av ett processsteg och för vilka en uppsättning villkor beskrivs, inklusive starten av processen), varaktighet (tidsintervallet under vilket processen måste framgångsrikt slutföra sitt exekvering), deadline (datum , till vilket processen helt eller delvis slutför sin exekvering) och slutpunkten för processen (kontrollpunkten där kunden kontrollerar kvaliteten på de erhållna processresultaten).

Det tydligaste sättet ett grundläggande schema kan presenteras är Gantt-diagram- Ett linjärt diagram, där projektuppgifterna representeras av tidsperioder, inklusive start- och slutdatum för deras genomförande, med hänsyn tagen till eventuella förseningar. I det här diagrammet listas planerade aktiviteter (delarna av arbetsuppdelningsstrukturen) på vänster sida, datum visas överst och aktivitetslängderna visas som horisontella staplar från startdatumet för en viss aktivitet till dess slutdatum (Figur 3.16).

Ris. 3.16. Gantt-diagram

Utförandeprocessgrupp

Projektledningsprocessgrupper

Projektkvalitetsledning

säkerhet

kvalitet

Modern projektledningsprogramvara ger visualisering av strukturen i projektdiagrammet och arbetsprocesser, till exempel det allmänt kända och ganska ofta använda projektledningssystemet. Detta gör att utvecklaren eller projektledaren kan se hur olika aktiviteter utförs - sekventiellt eller parallellt, och om de är på den kritiska vägen.

Projektplanering är en del av projektledning som involverar användning av scheman, såsom ett Gantt-diagram, för att planera arbete och sedan rapportera framsteg i en projektmiljö.

Initialt definieras projektets omfattning, men de lämpliga metoderna för att slutföra projektet är inte definierade. Efter detta steg bör de arbetsenheter som behövs för att slutföra jobbet listas och grupperas i en arbetsnedbrytningsstruktur (WBS), med hänsyn tagen till de olika uppgifternas varaktighet. Projektplanering används ofta för att organisera olika delar av ett projekt, inklusive projektplaner, arbetsbelastningar och ledning av team och människor. Logiska beroenden mellan uppgifter bestäms med hjälp av ett nätverksaktivt diagram, vilket gör att den kritiska vägen kan bestämmas.

Projektplaneringen är osäker; den måste göras innan projektet faktiskt påbörjas. Därför uppskattas uppgiftens varaktighet ofta med hjälp av ett vägt genomsnitt av optimistiska, normala och pessimistiska uppskattningar. Detta lägger till "buffertar" i planeringen för att kunna förutse förseningar (som långa godkännanden) i projektgenomförandet. Tiden i ett schema kan beräknas med hjälp av programvara för projektledning. De nödvändiga resurserna och kostnaderna för varje aktivitet kan uppskattas, vilket ger den totala kostnaden för projektet. I detta skede kan projektschemat optimeras för att uppnå rätt balans mellan resursanvändning och projektets varaktighet, i överensstämmelse med projektets mål. När ett projektschema har skapats och godkänts, blir det baslinjen (eller målschemat). Integrerade projektframsteg kommer att mätas mot ett baslinjeschema under hela projektets varaktighet. Att analysera framsteg mot ett baslinjeschema kallas för intjänat värde-metoden.

Input till projektplaneringsfasen är projektstadgan och konceptförslag. Resultaten från projektplaneringsstadiet inkluderar projektkraven, projektschemat och projektledningsplanen.

Projektplanering kan göras manuellt, men programpaket för projektledning används ofta. Sådana komplex inkluderar det professionella Oracle Primavera och det mer vardagliga MS Project.

Inom området projektledning är ett projektschema en lista över projektmilstolpar, uppgifter och leveranser, vanligtvis med ett förväntat start- och slutdatum. Dessa element uppskattas ofta mot annan information som ingår i projektschemat, såsom resursallokering, budget, uppgiftslängd, relationer, beroenden och schemalagda händelser. Ett projektschema används ofta för att planera och hantera en portfölj av projekt. Schemaelement kan vara nära kopplade till arbetsnedbrytningsstrukturen (WBS) genom nyckelhändelser, arbetsuppgifter eller kontraktsdata.

Egenskaper för projektscheman

Inom många branscher, såsom teknik och konstruktion, är det en intern planerare eller ett team av planerare som ansvarar för att utveckla och underhålla ett projektschema, beroende på projektets storlek. Planeringsmetoder är väl utvecklade och konsekvent tillämpade i alla branscher.

Det bör noteras att projektledning inte är begränsad till industrin; en vanlig människa kan använda denna metod för att organisera sitt eget liv. Vissa projektledningsprogram, mallar, diagram och exempel hjälper användare att skapa sitt schema.

Metoder för att ta fram projektscheman

Innan du skapar ett schema måste du utveckla en arbetsnedbrytningsstruktur (WBS), uppskatta kostnaderna för varje uppgift och fastställa en lista med resurser. Om dessa schemakomponenter inte är tillgängliga kan de skapas med konsensusbaserade uppskattningsmetoder som Delphi-metoden. Anledningen till detta är att själva schemat är en uppskattning: varje dag på schemat uppskattas, och om inte dessa datum är baserade på de faktiska erfarenheterna hos de personer som ska utföra arbetet, kommer schemat inte att vara korrekt.

För att ett projektschema ska vara realistiskt måste följande kriterier vara uppfyllda:

• Schemat ska ständigt (helst veckovis) uppdateras (uppdateras).
• EAS-värdet (poäng vid slutförande) måste vara lika med basvärdet.
• Arbetsbelastningen måste vara korrekt fördelad mellan teammedlemmarna (med hänsyn till helger).

INTRODUKTION

Projektledning handlar om att göra upp en plan och följa hur arbetet med den fortskrider. Följaktligen, ju bättre projektplanen är, desto noggrannare den är utformad, desto lättare är det att sedan utföra konstruktionsarbete och framgångsrikt slutföra projektet.

För att planera väl måste du först och främst ha en god uppfattning om vad ett projekt är och vilka delar dess plan består av.

Varje organisations verksamhet är att utföra operationer och projekt. Båda har mycket gemensamt, till exempel utförs de av människor, för vilka begränsade resurser avsätts.

Den största skillnaden mellan verksamhet och projekt är att verksamheten är pågående och repetitiv, medan projekten är tillfälliga och unika. Utifrån detta definieras ett projekt som en tillfällig insats som görs för att skapa en unik produkt eller tjänst. "Tillfälligt" betyder att varje projekt har ett specifikt start- och slutdatum. När vi talar om att en produkt eller tjänst är unik menar vi att den skiljer sig märkbart från liknande produkter eller tjänster.

Det unika med varje projekt skapar svårigheter att planera det, eftersom det ofta är svårt att förutse hur resultaten faktiskt kommer att uppnås. Därför är resultatet av projektaktivitet inte bara en produkt eller tjänst, utan också lärdomar, det vill säga erfarenheter som används i framtiden vid planering och genomförande av efterföljande projekt.

PROJEKT PLANERING

Planeringsstadiet är ett av de viktigaste. I detta skede bestäms projektets uppgifter, budget och tidsram. Ganska ofta förstås planering bara som att schemalägga arbete, tappa ur sikte av resurshantering, budgetering etc.

En komplett planeringsteknik inkluderar följande steg:

• 1) Definition av projektmål och deras beskrivning. Ganska ofta startar projekt utan ett tydligt mål.
• 2) Fastställande av tekniska stadier. En implementeringsteknik måste väljas för projektet, som bestämmer stadierna i projektutvecklingen. Ett av de typiska planeringsfelen är diskrepansen mellan planen och den tekniska cykeln.
• 3) För tekniska stadier är det nödvändigt att bestämma en lista över uppgifter, ange deras relationer (sekvens) och förutspådd varaktighet (beroende på de tilldelade resurserna).
• 4) Det är nödvändigt att komma överens om de resurser som tilldelas projektet. Det bör noteras att alla företagets resurser ska fördelas centralt. Ganska ofta uppstår ett planeringsfel på grund av att en del knappa resurser används samtidigt i två olika projekt samtidigt.
• 5) Om du bestämmer priserna för resurser kan budgeten också erhållas automatiskt. Ett av de typiska misstagen är att budgeten tilldelas utan att uppmärksamma den beräknade kostnaden för projektet.
• 6) Den skriftliga uppgiften, budgeten och arbetsschemat utgör det formella dokumentet "Projektplan". Ganska ofta, före starten av ett projekt, saknas några av dessa dokument konsekvenserna av detta kommer att diskuteras nedan.

För att projektplaneringen ska lyckas är ett antal faktorer viktiga och måste beaktas:

• · klass av uppgifter som ska lösas, antal kopior av den färdiga produkten, typ av arbete (utveckling, utveckling, support);
• · Val av en arbetsplan (livscykelmodell) med hänsyn till projektets komplexitet och utvecklingsteamets kapacitet;
• · erfarenhet inom ämnesområdet och utvecklingsautomationsverktyg;
• · utrusta utvecklare med automationsverktyg och hård- och mjukvarubas;
• · nivå av kundkrav på timing och kvalitet på arbetet.

I ett välorganiserat projekt bör ett specifikt ledningsorgan ansvara för genomförandet av varje mål: projektledaren, för alla mål (projektuppdrag), ansvariga utförare för privata mål, etc. Det vill säga att trädet av projektmål ska sammanfalla med strukturen för den organisatoriska enhet som ansvarar för genomförandet av projektet. För detta ändamål utvecklas en så kallad ansvarspatrix, som definierar projektutförarnas funktionella ansvar och specificerar uppsättningen av arbeten för vilka de är personligen ansvariga.

Huvudmålet med planering är att bygga en modell för projektgenomförande.

Vanliga planeringsmisstag

Planering med hjälp av fel mål. Varje projekt är till sitt innehåll avsett att lösa ett problem, tillgodose ett specifikt behov etc. Beroende på detta formuleras vissa specifika mål. Om problemet är oklart och inte tydligt formulerat så kan man stöta på ett vanligt misstag när rätt beslut fattas, men man vet inte exakt vilket specifikt problem det är.

För att undvika en sådan situation är det nödvändigt att ta reda på den verkliga grunden för arbetet: registrera - helst dokumenterat - en beskrivning av de problem och behov som måste lösas efter avslutat projekt; fastställa hur lösningen på specifika problem återspeglas i beskrivningen av projektets mål och mål. Först efter detta kan du börja planera.

Planering baserad på ofullständig data. En liknande situation är typisk när det är nödvändigt att planera arbete, vars början, och möjligen själva genomförandet, beror på resultaten av testtester eller framgångar/misslyckanden i tidigare faser.

En liknande situation uppstår ofta i projekt för utveckling och anpassning av informationssystem. Kunden har en oemotståndlig önskan att få ett färdigt verktyg så snabbt som möjligt. Men han har bara en vag uppfattning om kapaciteten hos den programvara han har valt och vad han vill automatisera. Å andra sidan vet mjukvaruleverantörerna väldigt lite om de faktiska ledningsprocesserna (funktionella, informations-, organisatoriska strukturer) i kundens organisation. Och först när de börjar genomföra projektet börjar processen med ömsesidig information och utbildning. Förtydligande av uttalandet leder till en betydande, ibland flera gånger, ökning av arbetsvolymen och en förändring av dess mål och sammansättning.

Planering genomförs med inblandning av endast planerare. En sådan planeringsorganisation kan leda till betydande förluster på grund av bristande hänsyn till viktiga faktorer. Som regel glöms till synes obetydliga detaljer eller omständigheter bort, bristande efterlevnad som ändå kan leda till kolossala förluster. Därför bör även de ansvariga för det specifika projektarbetet, de ansvariga för projektfinansieringen, för förnödenheter etc. involveras i planeringen. För att inte tala om de psykologiska aspekterna av att genomföra planen, i utvecklingen av vilka specifika artister inte deltog.

Planering utan att ta hänsyn till tidigare erfarenheter.Även med de bästa uppskattningarna, utan användning av tidigare erfarenhet av att genomföra liknande projekt, kan allvarliga planeringsfel begås.

Planera resurser utan att ta hänsyn till deras tillgänglighet. Det handlar i första hand om arbetskraftsresurser med vissa kvalifikationer och förmåga att vid en given tidpunkt komma till en given plats för att utföra arbete med projektet. Ett annat problem är om samma grupp av specialister planeras i flera samtidigt pågående projekt.

Planera utan att ta hänsyn till motivation. Som regel lockas utförare från funktionella avdelningar som har egna att arbeta med projekt. Ledning, sina egna mål och specifika uppgifter och förstås sin egen form av ersättning, som oftast inte har något att göra med projektets mål och mål. Utövare känner därför inte ansvaret och vikten av projektarbetet utan ordentliga incitament för resultatet av sin verksamhet. Men projektledaren är inte utrustad med tillräckliga rättigheter för att stimulera artister och kan inte bilda en ekonomisk incitamentsbudget baserad på projektets resultat.

Planera med överdriven detaljrikedom. När ett projekt planeras för detaljerat , problem uppstår när man analyserar, planerar och övervakar dess status - till exempel vad som är klart och vad är förseningen. Dessutom är det svårt att effektivt hantera ett stort antal resurser, fastställa tidsfördröjningar, uppskatta kostnader och utveckla realistiska scheman som är acceptabla för förvaltningsändamål. Överdriven detalj i att ta hänsyn till faktorer leder till behovet av att lösa ett stort antal konflikter, till frekventa förändringar, till behovet av konstant samordning med andra projekt som genomförs samtidigt. Men överdriven utvidgning kan också leda till problem med förlust av kontrollerbarhet. En gyllene medelväg behövs när projektet bara planerar de parametrar som kan och bör styras.

Vad du behöver för att undvika planeringsmisstag (några tips):

• · En lista över problem som ska lösas måste formuleras för projektet;
• · huvudmålet för projektet (uppdraget) måste uppmärksammas av alla deltagare;
• · Riskerna måste identifieras och, om möjligt, olyckor uteslutas.
• · det är nödvändigt att säkerställa att projektstrategin kan implementeras och uppfyller budget-, tids- och omfattningsbegränsningar (en PCTS-förbarhetsanalys genomfördes: P - Prestanda, C - Kostnad, T - Tid, S - Omfattning. Kostnaderna är en funktion av nivåutförandet P, tid T och innehåll, arbetets omfattning S);
• · förekomsten av positiva resultat av analysen av "för- och nackdelar" med projektgenomförandet (en kraftfältsanalys genomfördes, som består av en beskrivning och kvantitativ bedömning av faktorer som kan underlätta och hindra genomförandet av projektet );
• · det slutliga resultatet måste vara tydligt för alla medlemmar i projektgruppen;
• · Indikatorer för att bedöma resultaten av projektverksamheten bör bedöma läget med nödvändig noggrannhet. Det är tillrådligt att utveckla interna prestationsbedömningsskalor efter typ av arbete.

Definiera projektmål

Att sätta upp mål först innebär att projektet måste börja med en målförklaring. I detta fall måste målet registreras skriftligt i form av mätbara indikatorer.

Stadium av problemformulering, detta skede genomförs under ett konsultavtal, d.v.s. etappbetalningen är tidsbaserad. På grund av uppgiftens osäkerhet är det omöjligt att planera kostnaden i förväg. Kostnaden för scenen är ungefär lika med 10% av kostnaden för allt arbete.

Huvudprodukten av scenen är dokumentet "Problem Statement" (Product Vision).

Detta dokument bör definiera syftet med projektet och innehålla en lista över nyckelkrav utan detaljerad förklaring. Ett viktigt kriterium: trots avsaknaden av en detaljerad beskrivning måste listan vara tillgänglig för statistisk utvärdering av arbetsintensitet med en standardavvikelse (risk) inom ett acceptabelt intervall.

Utifrån ”Problem Statement” krävs att man upprättar ett ”Economic Justification”-dokument.

Detta dokument ska innehålla en statistisk bedömning av arbetsintensiteten (kostnaden) för arbetet. Däremot måste en analys av den ekonomiska effekten av genomförandet göras.

Analysen använder statistik över arbetsintensiteten (effektiviteten) i liknande projekt. I avsaknad av denna statistik är fel i uppskattningar oundvikliga, i det här fallet bör du försöka få statistik baserad på resultaten av utvecklingen/demonstrationen av prototyper.

Riskbedömningen ska uttryckas i form av ett eventuellt överskridande av arbetsintensiteten (pessimistisk bedömning). Det är från denna bedömning som man bör utgå när man bestämmer produktens totala arbetsintensitet (pris).

Som ett resultat har vi en vagt formulerad uppgift i ”Problembeskrivningen” och en kostnadsberäkning i ”Ekonomisk motivering”. Risker från oklara krav ska täckas av en pessimistisk bedömning. Villkor för att genomföra etappen: parternas undertecknande av "Problem Statement" och "Economic Justification".

Resurshantering och planering

ledningsprojektplaneringsresurs

Resurshantering är ett av de viktigaste delsystemen för projektledning. Inkluderar processerna för planering, inköp, leverans, distribution, redovisning och kontroll av resurser, vanligtvis arbetskraft och logistik. Resursförvaltningens uppgift är att säkerställa deras optimala användning för att uppnå det slutliga målet - bildandet av ett projektresultat med planerade indikatorer.

Material och tekniska resurser är råvaror, material, strukturer, komponenter, energiresurser, tekniska resurser etc.

Arbetsresurser är de som direkt arbetar med materiella och tekniska resurser.

Hanteringen av projektmaterialresurser börjar i huvudsak vid förinvesteringsfasen när man utvecklar en förstudie under planeringsfasen, resursbehoven och möjligheten att tillhandahålla dem utarbetas. Praxis visar att resurserna vid varje given tidpunkt är begränsade och därför är resurshanteringens huvuduppgifter:

• 1. Optimal resursplanering
• 2. Logistikhantering, inklusive:
  • · hantering av resursanskaffning;
  • · hantering av resursallokering.

Resursbegreppet är sammankopplat med begreppet "arbete", eftersom resurser inte avser projektet som helhet, utan specifikt arbete som utförs i en planerad sekvens som motsvarar projektets arbetsschema.

Planering och organisation av inköp och förnödenheter - det första steget i projektresurshantering. Består av steg inklusive val av leverantörer, beställningar och övervakning av leveranser.

På planeringsstadiet utförs en balanserad analys av arbetspaket och förbrukade resurser, med hänsyn till restriktioner och deras prognostiserade fördelning baserat på resursefterfrågan. Projektresursplanering ligger till grund för att fastställa resursbehov i tid och bestämma möjligheten att tillhandahålla resurser för att sluta kontrakt om inköp av resurser, planering av resursförsörjning, samt underlag för att fördela redan inköpta resurser för projektarbete.

Som en huvudkomponent i projektledning inkluderar resursplanering ett antal komponenter, inklusive:

• · utveckling och balanserad analys av arbetspaket och resurser som syftar till att uppnå projektmål;
• · utveckling av ett resursfördelningssystem och utnämning av ansvariga utförare;
• · övervaka arbetets framsteg - jämföra planerade arbetsparametrar med faktiska och utveckla korrigerande åtgärder.

Resurser fungerar som att tillhandahålla komponenter i projektarbetet, inklusive utförare, energi, material, utrustning etc. Följaktligen kan resursbehovsfunktionen kopplas till varje arbete, och resursbehovet för projektet som helhet kan beräknas med hjälp av schemaläggningsmetoder och matchningsmetoder kan säkerställa efterlevnadsbehov, tillgänglighet eller förmåga att tillhandahålla resurser.

När man planerar att tillgodose resurskraven för projektaktiviteter bör man i princip ta hänsyn till en generell regel: den totala volymen av behov för varje resurstyp vid varje tidpunkt inom projektets livscykel får inte vara mindre än den totala volymen tillgången på denna resurs vid det tillfället, med hänsyn tagen till reserver.

Projektkostnadsuppskattning

Beroende på fas i projektets livscykel och syftet med bedömningen används olika typer och metoder för att uppskatta kostnaden för projektet. Utifrån syftet med bedömningarna varierar även träffsäkerheten i sådana bedömningar. Vi kommer inte att överväga i detalj, men du måste komma ihåg att det största felet uppstår, naturligtvis, i det stabiliserande skedet av projektet, när fel i en viss version identifieras och korrigeras är det också möjligt att allt som; gjordes implementerades inte korrekt (i betydelsen teknik), men detta hänvisar redan till analfabet design.

För att uppskatta kostnaden för ett projekt måste du känna till kostnaden för de resurser som utgör projektet, den tid det tar att slutföra arbetet och kostnaden för detta arbete.

Således börjar kostnadsuppskattningen med att bestämma projektets resurs- och arbetsstruktur. Dessa uppgifter löses som en del av projektplaneringen, och kostnadsuppskattningsmodulen bör få resultatet av denna process. Kostnaden för projektet bestäms av resurserna nödvändigt för att utföra arbetet.