Bedste svar
Projektbaggrund beskriver den organisatoriske baggrund, som projektet finder sted i. Du bør sigte mod at gøre det forståeligt for nogen, der ikke ved noget om forretningen eller teknologien. Det skal være på højt niveau, kun et par sætninger på hvert nøgleelement. For eksempel, da jeg var leder af digitale biblioteker på British Library, ville jeg forklare, hvad British Library var, hvorfor det havde et digitalt bibliotek, hvad det digitale biblioteksprogram var, og hvilken del af det digitale bibliotekssystem, projektet påvirkede. Når du har skrevet det til et projekt, skal du kunne genbruge det til ethvert andet projekt inden for det samme program
Problemdefinition beskriver det problem, som projektet skal løse. Det skal beskrive problemet med de forretningsfordele, som du forventer at få, når projektet er afsluttet. Mange mennesker får denne forkert. Sig for eksempel, at dit projekt er at opgradere en gruppe servere fra Windows Server 2003 til 2016. Jeg har ofte set folk skrive noget som: “Problemet er, at x-, y- og z-servere kører Windows Server 2003”. Det faktum, at en server bruger et forældet operativsystem, er ikke i sig selv et problem. Du er nødt til at grave ind i det virkelige forretningsproblem, der løses. Det kan være sikkerhed, eller det kan være, at du ikke kan opfylde dine SLAer, fordi overvågningssystemet ikke understøtter 2003. Sig, at du starter projektet, og du opdager, at en af serverne ikke kan opgraderes, fordi den software, den kører, er inkompatibel. med 2016. Dit projekt er nu en fiasko. Imidlertid kører softwaren på Server 2010. Hvis du havde sagt, at problemet drejer sig om sikkerhed, kan du bare installere 2010, og projektet er stadig en succes.
Hvis du ser på, hvad PRINCE2 og Managing Succesfuld er. Programmer (MSP) siger om projekter – de handler om at indføre en kapacitet. projektets mål skal handle om de muligheder, som du forventer at være på plads ved projektets afslutning. Sig for eksempel, at du udvikler et websted til et rejsebokningsfirma. Målet er at sætte brugerne i stand til at søge efter, booke og betale for rejser med tog, taxa, rickshaw osv. Osv.
Projektbegrundelse er forretningssagen for projektet. Bare fordi der er et problem, der skal løses, betyder det ikke, at virksomheden skal bruge penge på at løse dette problem. Enhver organisation har størrelsesordener flere ting, som den kunne gøre, end den enten har tid eller penge til faktisk at opnå. Begrundelse for projekt skal fortælle læseren, hvad det forventede investeringsafkast er for projektet
Projektets omfang skal være en punktliste over, hvad projektet vil gøre, og vigtigere, hvad det ikke vil gøre. Skal projektet f.eks. Levere undervisningsmateriale? Kommer projektet til at rekruttere det team, der skal bruge outputene? Er projektets anvendelsesområde et land, en region eller et globalt?
Svar
Projektbaggrund – Dette er kun sammenhængen snarere end selve projektet. For eksempel vokser virksomheden, og det tager også mere personale. Dit projekt er en teknisk opdatering og kapacitetsforøgelse af HR-systemet. Du leverer ikke vækst eller personale. Du leverer det nye HR-system.
Problemdefinition: Dette er ikke et rent projektledelsesudtryk. Jeg vil sige, at det vedrører baggrund, fordi det spørger, hvad er problemet, der har brug for en løsning. Dit projekt leverer muligvis ikke hele løsningen, så det kan ikke løse det underliggende problem. For eksempel, din HR-opdatering vinder ikke den matchende vækst i lønsystemet.
Projektets mål: Det sædvanlige sigt er mål, og der er to typer.
Forretningsmål: Dette kan omfatte at være i stand til at klare en vækst i personalet på x\%. Du leverer ikke det – du løser kun HR. Selvom HR-systemet var det eneste, der havde brug for vækst, skal klienten se på forretningsprocesser, HR-personale osv. For at kunne udnytte det nye system, du levere. Forretningsmål er en god ting at vide og angive, MEN de er IKKE inden for din gave.
Projektmål: Dette er de resultater, som dit projekt er designet til at opnå. Disse ligger inden for din gave. er stadig på højt niveau, så bland ikke disse med leverancer.
Projektbegrundelse: Igen er dette virkelig en del af baggrunden. I høj grad hører det ikke til! Hvis en klient ønsker en stor rød stang på sit kontor og er parat til at betale for det, er det hans forretning.Nogen, ikke premierministeren, men ofte en forretningsanalytiker, skal oprette en forretningssag for at retfærdiggøre arbejdet og få udgifter godkendt af indehavere af budgetter. Normalt ville dette være a) Hvis jeg bruger X, returnerer det X + Y, eller b) hvis jeg bruger X, undgår eller mindsker vi risikomomentet Y. Dette er ikke dit job og vil allerede være gjort, før du er bedt om at definere og køre et projekt.
Projektets omfang: Projektets omfang er absolut kernen i dit domæne som PM. Omfanget definerer i så nøjagtige termer som muligt to ting: 1) Hvad vil projektet gøre? 2) Hvad vil projektet IKKE gøre? Dit projekt vil levere et nyt HR-system, men (måske) det vil ikke levere uddannelse til klientens HR-personale. Det leverer ikke ekstra HR-personale. Det inkluderer sandsynligvis HR-slutningen af lønintegration, men inkluderer sandsynligvis ikke ændringer i lønningslisten. Etc. Omfang defineres bedst på en struktureret måde. Jeg bruger POLDAT
forretningsproces, organisering, placering, data, applikation, teknologi.
Hvad ændrer dit projekt sig eller ændrer det sig ikke i disse forandringsdomæner?
Skru dette op, og du er i dybden —-