Beste svaret
Prosjektbakgrunn beskriver organisasjonsbakgrunnen som prosjektet foregår i. Du bør sikte på å gjøre det forståelig for noen som ikke vet noe om virksomheten eller teknologien. Det skal være høyt nivå, bare et par setninger på hvert nøkkelelement. Da jeg for eksempel var sjef for digitale biblioteker ved British Library, forklarte jeg hva British Library var, hvorfor det hadde et digitalt bibliotek, hva det digitale biblioteksprogrammet var og hvilken del av det digitale bibliotekssystemet prosjektet hadde innvirkning på. Når du har skrevet det for ett prosjekt, bør du kunne bruke det til ethvert annet prosjekt innenfor det samme programmet
Problemdefinisjon beskriver problemet som prosjektet er ment å løse. Den skal beskrive problemet når det gjelder forretningsfordelene du forventer å få når prosjektet er fullført. Mange mennesker får denne feil. Si for eksempel at prosjektet ditt er å oppgradere en gruppe servere fra Windows Server 2003 til 2016. Jeg har ofte sett folk skrive noe sånt som: «Problemet er at x-, y- og z-servere kjører Windows Server 2003». Det faktum at en server bruker et foreldet operativsystem er ikke i seg selv et problem. Du må grave i det virkelige forretningsproblemet som blir løst. Det kan være sikkerhet, eller det kan være at du ikke kan oppfylle SLA-ene dine fordi overvåkingssystemet ikke støtter 2003. Si at du starter prosjektet, og at du oppdager at en av serverne ikke kan oppgraderes fordi programvaren den kjører er inkompatibel. med 2016. Prosjektet ditt er nå en fiasko. Programvaren kjører imidlertid på Server 2010. Hvis du hadde sagt at problemet handler om sikkerhet, kan du bare installere 2010, og prosjektet er fremdeles en suksess.
Hvis du ser på hva PRINCE2 og Managing Successful Programmer (MSP) sier om prosjekter – de handler om å få på plass en evne. målene for prosjektet bør handle om kapasitetene du forventer å være på plass ved slutten av prosjektet. Si for eksempel at du utvikler et nettsted for et reisebestillingsfirma. Målet er å legge til rette for at brukerne kan søke etter, bestille og betale for reiser med tog, taxi, rickshaw osv.
Prosjektbegrunnelse er business case for prosjektet. Bare fordi det er et problem som trenger løsning, betyr ikke det at virksomheten skal bruke penger på å løse det problemet. Enhver organisasjon har størrelsesordener flere ting som de kan gjøre enn det har enten tid eller penger til å faktisk oppnå. Prosjektjustering skal fortelle leseren hva forventet avkastning på investeringen er for prosjektet
Prosjektets omfang bør være en punktliste over hva prosjektet vil gjøre, og enda viktigere, hva det ikke vil gjøre. Skal prosjektet for eksempel levere opplæringsmateriell? Vil prosjektet rekruttere teamet som skal bruke utgangene? Er omfanget av prosjektet ett land, en region eller et globalt?
Svar
Prosjektbakgrunn – Dette er bare konteksten, snarere enn selve prosjektet. For eksempel vokser selskapet, og det tar også med seg flere ansatte. Prosjektet ditt er en teknisk oppdatering og kapasitetsheving av HR-systemet. Du leverer ikke vekst eller ansatte. Du leverer det nye HR-systemet.
Problemdefinisjon: Dette er ikke et rent prosjektledelsesbegrep. Jeg vil si at det er relatert til bakgrunn, fordi det spør hva som er problemet som trenger en løsning. Prosjektet ditt leverer kanskje ikke hele løsningen, så det kan ikke løse det underliggende problemet. HR-oppdateringen din vil for eksempel ikke gjøre den matchende veksten i lønnssystemet.
Mål for prosjektet: Det vanlige begrepet er mål og det er to typer.
Forretningsmål: Dette kan omfatte å være i stand til å takle en økning i personalet på x\%. Du vil ikke levere det – du fikser bare HR. Selv om HR-systemet var det eneste som trengte vekst, må klienten se på forretningsprosesser, HR-medarbeidere osv. For å kunne dra nytte av det nye systemet du levere. Forretningsmål er en god ting å vite og oppgi, MEN de ligger IKKE innenfor gaven din.
Prosjektmål: Dette er resultatene som prosjektet ditt er designet for å oppnå. Disse er innenfor din gave. er fortsatt på høyt nivå, så ikke forveksle disse med leveranser.
Prosjektbegrunnelse: Igjen, dette er virkelig en del av bakgrunnen. I stor grad hører det ikke med deg! Hvis en klient ønsker en stor rød stolpe på kontoret sitt og er forberedt på å betale for det, er det hans virksomhet.Noen, ikke statsministeren, men ofte en forretningsanalytiker, må opprette en forretningssak for å rettferdiggjøre arbeidet og få utgifter godkjent av innehavere av budsjetter. Normalt vil dette være a) Hvis jeg bruker X, vil det returnere X + Y, eller b) hvis jeg bruker X, unngår eller reduserer vi risikokostnaden Y. Dette er ikke din jobb og vil allerede ha blitt gjort før du er bedt om å definere og kjøre et prosjekt.
Prosjektets omfang: Prosjektomfanget er absolutt kjernen i domenet ditt som PM. Omfanget definerer, i så eksakte termer som mulig, to ting: 1) Hva vil prosjektet gjøre? 2) Hva vil IKKE prosjektet gjøre? Prosjektet ditt vil levere et nytt HR-system, men (kanskje) det vil ikke gi opplæring til klientens HR-ansatte. Den leverer ikke ekstra HR-ansatte. Det inkluderer sannsynligvis HR-slutten på integrering av lønn, men inkluderer sannsynligvis ikke endringer i lønn. Etc. Omfang defineres best på en strukturert måte. Jeg bruker POLDAT
forretningsprosess, organisering, plassering, data, applikasjon, teknologi.
Hva endrer prosjektet ditt, eller endrer det ikke, i disse endringsdomenene?
Skru opp dette, og du er i dypet —-