IT-projektstyringsbetingelser, du skal kende

Bemærk: Denne artikel er baseret på og en opdatering af Tom Mochals artikel, Mini-ordliste: Projektstyringsbetingelser, du skal kende.

Hver disciplin har sit eget ordforråd, og projektledelse er ingen undtagelse. En del af processen med succes implementering af projektledelse i din organisation er at standardisere terminologien. På den måde, når en person taler om risici, omfang, problemer, krav og andre projektledelsesmæssige problemer, ved alle andre, hvad han eller hun refererer til. Denne ordliste indeholder almindelige udtryk, der bruges i projektstyring og kan hjælpe med at starte standardiseringsprocessen i din organisation.

Antagelse

Der kan være eksterne omstændigheder eller begivenheder, der skal forekomme for at projektet skal få succes (eller det skulle ske for at øge dine chancer for succes). Hvis du mener, at sandsynligheden for, at begivenheden finder sted, er acceptabel, kan du angive den som en antagelse. En antagelse har en sandsynlighed mellem 0 og 100%; det vil sige, det er ikke umuligt, at begivenheden finder sted (0%), og det er ikke en kendsgerning (100%) - den er et sted imellem. Antagelser er vigtige, fordi de sætter den kontekst, i hvilken hele resten af ​​projektet er defineret. Hvis en antagelse ikke kommer igennem, er estimatet og resten af ​​projektdefinitionen muligvis ikke længere gyldigt.

Klient / kunder

Den person eller gruppe, der er den direkte modtager af et projekt eller en tjeneste, er klienten / kunden. Dette er de mennesker, som projektet gennemføres for (indirekte modtagere er interessenter). I mange organisationer kaldes interne modtagere "klienter", og eksterne modtagere kaldes "kunder", men dette er ikke en hård og hurtig regel.

Begrænsninger

Begrænsninger er begrænsninger, der er uden for projektteamets kontrol og skal styres rundt. Det er ikke nødvendigvis problemer. Projektlederen skal dog være opmærksom på begrænsninger, fordi de repræsenterer begrænsninger, som projektet skal udføre inden for. Datobegrænsninger indebærer for eksempel, at visse begivenheder (måske slutningen af ​​projektet) skal forekomme inden for bestemte datoer. Ressourcer er næsten altid en begrænsning, da de ikke er tilgængelige i en ubegrænset forsyning.

Omkostningsafvigelse

Omkostningsvariansen (CV) bruges til at måle omkostningsforskellen mellem et projekts indtjente værdi (EV) og de faktiske omkostninger (AC) for at levere fremskridt til dato (CV = EV - AC). I ansøgning indikerer positive CV'er, at projektet er under budget, da det leverer mere værdi end påløbende omkostninger. Hvis projektet har et negativt CV, er det over budgettet. Selv positive CV'er bør undersøges for årsag.

Kritiske vej

Den kritiske sti er sekvensen af ​​aktiviteter, der skal afsluttes i henhold til skemaet, for at hele projektet skal afsluttes efter planen. Det er den længste varighed sti gennem arbejdsplanen. Hvis en aktivitet på den kritiske sti er forsinket med en dag, vil hele projektet blive forsinket med en dag (medmindre en anden aktivitet på den kritiske sti kan accelereres med en dag). ( Læs: Hvorfor kritisk sti er kritisk for projektstyring)

Deliverable

En leverbar er ethvert konkret resultat, der produceres af projektet. Alle projekter skaber leverancer, som kan være dokumenter, planer, computersystemer, bygninger, fly osv. Interne leverancer produceres som en konsekvens af gennemførelsen af ​​projektet og er normalt kun nødvendige af projektteamet. Eksterne leverancer oprettes til klienter og interessenter. Dit projekt kan oprette en eller flere leverancer.

Optjent værdi

Optjent værdi (EV) er en EV-ledelsesterm, der bruges til at bestemme det samlede arbejde, der er afsluttet på et bestemt tidspunkt. Et projekts EV bestemmes ved at tilføje alle de budgetterede omkostninger for hver opgave i projektplanen. Den faktiske EV-beregning kan bruge en række beregningsmetoder, herunder 0-100%, 50-50% eller en faktisk procentdel til at bestemme en opgaves krediterede værdi.

Funktionel leder

Den funktionelle manager er den person, du rapporterer til inden for din funktionelle organisation. Dette er typisk den person, der foretager din præstationsanmeldelse. Projektlederen kan også være en funktionel leder, men han eller hun behøver ikke at være det. Hvis din projektleder er forskellig fra din funktionelle manager, bruger din organisation sandsynligvis matrixstyring.

Gantt kort

Et Gantt-diagram er et søjlediagram, der viser aktiviteter som blokke over tid. Begyndelsen og slutningen af ​​blokken svarer til begyndelsen og slutdatoen for aktiviteten.

Problem

Et spørgsmål er et stort problem, der vil hindre projektets fremskridt, og som ikke kan løses af projektlederen og projektteamet uden hjælp udefra. Projektledere bør proaktivt håndtere spørgsmål gennem en defineret problemstyringsproces.

Livscyklus

Livscyklus henviser til den proces, der bruges til at bygge de leverancer, der er produceret af projektet. Der er mange modeller til en projektlivscyklus. Til softwareudvikling kan hele livscyklus bestå af planlægning, analyse, design, konstruktion / test, implementering og support; dette er et eksempel på en "vandfald" livscyklus. Andre livscyklusser inkluderer iterativ udvikling, implementering af pakke og forskning og udvikling. Hver af disse livscyklusmodeller repræsenterer en tilgang til at bygge videre på dit projekts leverancer. ( Læs: Projektledere skal forstå livscyklusarbejdet)

Milestone

En milepæl er en planlægningsbegivenhed, der angiver færdiggørelsen af ​​en større levering eller et sæt relaterede leverancer. En milepæl har pr. Definition varigheden på nul og ingen indsats. Der er ikke noget arbejde, der er forbundet med en milepæl. Det er et flag i arbejdsplanen for at indikere, at noget andet arbejde er afsluttet. Normalt bruges en milepæl som et projektcheckpoint til at validere, hvordan projektet skrider frem. I mange tilfælde er der en beslutning, f.eks. Validering af, at projektet er klar til at fortsætte, og som skal træffes ved en milepæl.

Objektiv

Et mål er en konkret redegørelse, der beskriver, hvad projektet prøver at opnå. Målet skal skrives på et lavt niveau, så det kan evalueres ved afslutningen af ​​et projekt for at se, om det blev nået. Projektets succes bestemmes ud fra, om projektmålene blev nået. En teknik til at skrive et mål er at sikre, at det er specifikt, målbart, opnåeligt / opnåeligt, realistisk og tidsbundet (SMART).

Program

Et program er den paraplystruktur, der er oprettet for at styre en række relaterede projekter. Programmet producerer ikke nogen projektleverancer - projektteamene producerer dem alle. Formålet med programmet er at give den overordnede retning og vejledning, at sikre, at de relaterede projekter kommunikerer effektivt, at give et centralt kontaktpunkt og fokus for klienten og projektteamene og at bestemme, hvordan individuelle projekter skal defineres til Sørg for, at alt arbejde bliver afsluttet med succes.

Programleder

En programleder er personen med myndighed til at styre et program. (Bemærk, at dette er en rolle. Programlederen kan også være ansvarlig for et eller flere af projekterne inden for programmet.) Programlederen leder den overordnede planlægning og styring af programmet. Alle projektledere i programmet rapporterer til programlederen.

Projekt

Et projekt er en midlertidig struktur til at organisere og styre arbejdet og i sidste ende at opbygge en bestemt defineret levering eller et sæt leverancer. Per definition er alle projekter unikke, hvilket er en grund til, at det er vanskeligt at sammenligne forskellige projekter med hinanden.

Projektets baseline

Projektets baseline bruges til at etablere det originale sæt af budget og planlægge skøn baseret på det godkendte projektomfang forud for projektgennemførelsen. Effektive projektledere sammenligner projektets baseline med den aktuelle projektstatus for at bestemme specifikke omkostninger eller planlægge afvigelser.

Projektdefinition (charter)

Inden du starter et projekt, er det vigtigt at kende projektets overordnede mål, såvel som omfanget, leverancer, risici, antagelser, projektorganisationsplan osv. Projektdefinitionen (eller charter) er det dokument, der indeholder dette relevante Information. Projektlederen er ansvarlig for at oprette projektdefinitionen. Dokumentet skal godkendes af sponsoren for at indikere, at projektlederen og sponsoren er enige om disse vigtige aspekter af projektet.

Projektledelseskontor

Project Management Office (PMO) er en organisation i en virksomhed, der udvikler og håndhæver projektstyringsprocesser, værktøjer og teknikker. En PMO kan dannes på et programniveau, et afdelingsniveau eller på virksomhedsniveau. En PMO giver typisk support til program- eller porteføljestyring, projektporteføljestyring, ressourcestyring og problem- og risikostyring.

Projektleder

Projektlederen er personen med myndighed til at styre et projekt. Projektlederen er 100% ansvarlig for de processer, der bruges til at styre projektet. Han eller hun har også personaleadministrationsansvar for teammedlemmer, selvom dette deles med teammedlemets funktionelle manager. Processerne, der bruges til at styre projektet, inkluderer definition af arbejdet, opbygning af arbejdsplan og budget, styring af arbejdsplan og budget, omfangshåndtering, problemstyring, risikostyring osv.

Projektfase

En fase er en vigtig logisk gruppering af arbejdet med et projekt. Det repræsenterer også afslutningen af ​​en større leverbar eller et sæt relaterede leverancer. I et it-udviklingsprojekt kan logiske faser være planlægning, analyse, design, konstruktion (inklusive test) og implementering.

Projektplan

Projektplanen (ikke at forveksle med projektplanen) er det dokument, der beskriver de processer, værktøjer og teknikker, der bruges til at styre og styre projektet. Almindelige processer inkluderer specifikke processniveauprocesser såsom ændringsstyring, problemstyring, risikostyring, dokumentstyring og tidsstyring til opdateringer af projektplaner.

Projektplan / arbejdsplan

Projektplanen er ofte forbundet med Microsoft Project eller et lignende planlægningsværktøj. Projektplanen er en række opgaver med varigheder, ressourcer og specifikke afhængigheder, der forudsiger projektets slutdato.

Projekt hold

Projektteamet består af de heltids- og deltidsressourcer, der er tildelt til arbejde med projektets leverancer. De er ansvarlige for at forstå det arbejde, der skal afsluttes; færdiggørelse af tildelt arbejde inden for budgettet, tidslinjen og kvalitetsforventningerne; informere projektlederen om spørgsmål, omfangsændringer og problemer med hensyn til risiko og kvalitet; og proaktiv kommunikation af status og styring af forventninger.

Anmodning om forslag

Anmodningen om forslag (RFP) er en formel anmodning, der bruges af organisationer til at identificere potentielle løsninger og tjenester fra en liste over leverandører. Baseret på RFP vil organisationen identificere en mindre liste over leverandører, der skal udstede en anmodning om tilbud. ( Læs: Fem tip til en bedre anmodning om forslag)

Anmodning om tilbud

En anmodning om tilbud er en formel anmodning til en leverandør om at levere faktiske omkostninger for en bestemt tjeneste eller omfang af arbejdet. Klienten giver typisk en sælger et sæt krav og instruktioner til, hvordan man reagerer på anmodningen. Sælgeren leverer sit svar, herunder detaljer om løsningen, antagelser og prisfastsættelse.

Krav

Krav er beskrivelser af, hvordan et produkt eller en tjeneste skal handle, vises eller udføre. Krav henviser generelt til funktionerne og funktionerne i de leverancer, du bygger på dit projekt. Krav betragtes som en del af projektomfanget. Omfang på højt niveau defineres i din projektdefinition (charter). Kravene danner det detaljerede omfang. Når dine krav er godkendt, kan de ændres gennem administrationsprocessen for omfangsændring.

Risiko

Der kan være potentielle eksterne begivenheder, der vil have en negativ indflydelse på dit projekt, hvis de forekommer. Risiko henviser til kombinationen af ​​sandsynligheden for, at begivenheden vil finde sted, og virkningen på projektet, hvis begivenheden finder sted. Hvis kombinationen af ​​sandsynligheden for forekomst og indvirkningen på projektet er for stor, skal du identificere den potentielle begivenhed som en risiko og sætte en proaktiv plan for at styre risikoen.

Planlæg varians

Tidsplanvariansen (SV) er en EV-styringsterm, der bruges til at måle projektets tidsplanpræstation ved at sammenligne projektets EV med projektets baserede planlagte værdi (PV). Formlen er SV = EV - PV. Et positivt SV indikerer, at projektet ligger foran planen, mens et negativt SV angiver, at projektet ligger bag planen.

Anvendelsesområde

Omfang er den måde, du beskriver projektets grænser på; det definerer, hvad projektet skal levere, og hvad det ikke vil levere. Omfang på højt niveau indstilles i din projektdefinition (charter) og inkluderer alle dine leverancer og grænser for dit projekt. Det detaljerede omfang identificeres gennem dine forretningskrav. Eventuelle ændringer til dine projektleverancer, grænser eller krav kræver godkendelse gennem omfangsændringsstyring.

Omfang forandringsstyring

Formålet med styring af omfangsændring er at styre ændringer, der opstår til tidligere godkendte omfangsangivelser og krav. Omfang er defineret og godkendt i omfanget af projektdefinitionen (charter) og de mere detaljerede forretningskrav. Hvis omfanget eller forretningskravene ændres i løbet af projektet (og normalt betyder det, at klienten ønsker yderligere elementer), er estimaterne for omkostninger, indsats og varighed muligvis ikke længere gyldige. Hvis sponsoren accepterer at inkludere det nye arbejde i projektomfanget, har projektlederen ret til at forvente, at det aktuelle budget og frist vil blive ændret (normalt forhøjet) for at afspejle dette ekstra arbejde. Denne nye estimerede omkostning, indsats og varighed bliver det godkendte mål.

Undertiden tænker projektlederen, at omfangsstyring betyder, at man skal fortælle klienten "nej." Det gør projektlederen nervøs og ubehagelig. Den gode nyhed er dog, at styring af omfang handler om at få sponsor til at træffe de beslutninger, der vil resultere i ændringer i projektomfang. ( Læs: Lær hemmeligheden bag effektiv styring af omfangsændringer)

Sponsor (udøvende sponsor og projekt sponsor)

Sponsoren er den person, der har den ultimative autoritet over projektet. Den udøvende sponsor leverer projektfinansiering, løser problemer og ændringer i omfanget, godkender større leverancer og giver retning på højt niveau. Han eller hun er også mestre af projektet i organisationen. Afhængigt af projektet og organisatorisk niveau for den udøvende sponsor, kan han eller hun delegere den daglige taktiske ledelse til en projekt sponsor. Hvis den er tildelt, repræsenterer projekt sponsoren den daglige sponsor og træffer de fleste af de beslutninger, der kræver sponsorgodkendelse. Hvis beslutningen er stor nok, vil projekt sponsoren føre den til den udøvende sponsor.

Stakeholder

Specifikke personer eller grupper, der har en indsats i resultatet af projektet, er interessenter. Normalt er interessenter fra virksomheden og kan omfatte interne klienter, ledelse, ansatte, administratorer osv. Et projekt kan også have eksterne interessenter, herunder leverandører, investorer, samfundsgrupper og regeringsorganisationer.

Styringskomité

En styregruppe er normalt en gruppe interessenter på højt niveau, der er ansvarlige for at give vejledning om den overordnede strategiske retning. De indtager ikke stedet som en sponsor, men hjælper med at sprede det strategiske input og buy-in til en større del af organisationen. Styringskomitéen er især værdifuld, hvis dit projekt har indflydelse i flere organisationer, fordi det tillader input fra disse organisationer til beslutninger, der berører dem.

Vandfaldsmetodik

En vandfaldsmetodik er en forudsigelig livscyklusmetodologi med sekventielle faser, der inkluderer analyse, design, udvikling, test og implementering. Forudsigelige metoder fungerer godt, når kravene og design er veldefineret, som det findes i konstruktions- eller fremstillingsprocesserne. Til softwareprojekter anbefales en smidig metode til trods for den overflod af vandfaldsmetodologier, der findes på tværs af industrier.

Arbejdsfordeling struktur

Arbejdsfordelingsstrukturen (WBS) er en liste over større leverancer, som projektgruppen vil gennemføre i løbet af projektet. WBS er organiseret i et hierarki og nedbrydes typisk i flere underniveauer. Et WBS kan bruges til visuelt at definere projektet i mindre bidder, så teamet bedre kan forstå og planlægge de aktiviteter, der er nødvendige for at gennemføre leverancer. Diagrammeværktøjer såsom Microsoft Visio eller mind mapping værktøjer som Mindjet eller MindGenius kan bruges til at opbygge et visuelt WBS. ( Læs: Fem tip til opbygning af en arbejdsfordelingsstruktur)

Arbejdsplan (tidsplan)

Projektets arbejdsplan fortæller dig, hvordan du vil gennemføre projektet. Den beskriver de krævede aktiviteter, sekvensen af ​​arbejdet, hvem der er tildelt arbejdet, et skøn over, hvor stor indsats der kræves, hvornår arbejdet forfalder, og anden information af interesse for projektlederen. Arbejdsplanen giver projektlederen mulighed for at identificere det arbejde, der kræves for at afslutte projektet, og tillader også projektlederen at overvåge arbejdet for at afgøre, om projektet er i timeplan.

Agil projektstyringsterminologi

Agile metodologi

En smidig metodologi er en adaptiv systemudviklingsmetode til systemudvikling, der leverer software i inkrementelle bidder, der er kendt som iterationer eller sprints. I smidig udvikling er tiden fast, og rækkevidden tillades at flyde fra en iteration til en anden baseret på holdets brugerhistoriske fremskridt. En smidig metode anvendes bedst, når kravene ikke er veldefinerede. ( Læs: Fem agile projektstyringsmigrationstips)

Udbrænd diagram

Et nedbrændt diagram er en grafisk afbildning af det resterende arbejde tilbage mod tiden i en iteration. En projektets efterslæb eller timer kan udtrykkes på den lodrette akse, mens tiden er angivet på den vandrette akse. Et nedbrændt diagram bruges ofte til at bestemme, hvornår arbejdet skal afsluttes på et projekt eller en iteration.

Epic

Et epos er et sæt relaterede brugerhistorier. De betragtes også som en "rigtig stor brugerhistorie."

gentagelse

En iteration er et iterativ udviklingskoncept, der skaber en kort tidsramme til at levere et sæt softwarefunktioner eller brugerhistorier. Hver iteration inkluderer typiske vandfaldsaktiviteter såsom analyse, design, udvikling og test, men alligevel er de tidsboksede inden for et vindue på en til fire uger. Ved afslutningen af ​​en iteration gennemgås fremskridtene med erhvervskunden, og anbefalede ændringer kan integreres i fremtidige iterationer.

Planlægning af poker

Planning Poker er et estimeringsspil skabt af Mike Cohn fra Mountain Goat Software. Planlægning af poker bruges til at estimere individuelle brugerhistorier som en teamaktivitet. Holdet samler og gennemgår brugerhistorier ad gangen. Når historier præsenteres, diskuterer teamet brugerhistorien og giver et estimat af værket fra deres eget kortstykke. Alle estimater præsenteres og diskuteres, indtil teamet når frem til en konsensus.

Frigøre

En frigivelse er et sæt arbejdssoftware, der leveres til erhvervskunden som et resultat af et sæt iterationer. Under udgivelsesplanlægning gennemgår team en produktets efterslæb for at organisere brugerhistorier i de specifikke udgivelser og iterationer, der leverer et funktionelt produkt til erhvervskunden.

Scrum

Scrum er en iterativ udviklingsmetodologi, der bruges til at styre softwareprojekter. I scrum-baserede projekter er der ikke en specifik projektleder, der leder projektteamopgaver; holdet er selvstyret, og med-lokaliserede teammedlemmer er afhængige af kommunikation over dokumentation for effektiv projektlevering. ( Læs: Få en oversigt over Scrum agile-projektmetoden)

Sprint

En sprint er et scrum-baseret agile metodekoncept, der ligner en iteration. En sprint er tidsbokset til at levere et specifikt sæt brugerhistorier og producere arbejdsfunktioner inden for en bestemt tidsperiode. Under sprintplanlægning specificerer erhvervskunden eller produktejer brugerhistoriens prioritet, og udviklingsholdet forpligter sig til muligheden for en given sprint. Under en sprint kan brugerhistorier fjernes fra sprintomfanget, men nye historier kan ikke tilføjes; dette giver projektholdene mulighed for at fokusere på sprintens mål og levere hurtigt.

Historiepunkter

Et historiepunkt er en relativ estimeringsmetode, der bruges til at bestemme størrelsen på brugerhistorier, så hold kan bestemme, hvor meget arbejde der kan udføres under en iteration. Historiepunkter kan udtrykkes i en simpel Fibonacci-sekvens, t-shirtstørrelser eller et relativt antal. Ved at tilføje antallet af brugerhistorier og tilknyttede historipunkter kan projektgruppen fastlægge sin hastighed til fremtidig iterationsplanlægning.

Brugerhistorie

En brugerhistorie er en smidig version af et projektkrav. En brugerhistorie består af et par sætninger, der definerer, hvem, hvad og hvorfor for et givet krav og kan dokumenteres på indekskort eller sticky notes. Brugerhistorier er skrevet af erhvervsbrugeren for at kommunikere softwarebehovet eller - ønsket. Brugerhistorier er beregnet til at være kortfattet, da kommunikation mellem forretnings- og udviklingsholdet bruges til at uddybe brugerhistorien og udvikle arbejdssoftware. Eksempel fra Mike Cohn: "Som en, jeg vil". ( Læs: Brugerhistorier: Udgangspunktet i smidig udvikling)

© Copyright 2020 | mobilegn.com