Bästa svaret
Projektbakgrund beskriver den organisatoriska bakgrund som projektet äger rum i. Du bör sträva efter att göra det förståeligt för någon som inte vet något om verksamheten eller tekniken. Det ska vara hög nivå, bara ett par meningar på varje nyckelelement. När jag till exempel var chef för digitala bibliotek på British Library skulle jag förklara vad British Library var, varför det hade ett digitalt bibliotek, vad det digitala biblioteksprogrammet var och vilken del av det digitala bibliotekssystemet projektet påverkade. När du har skrivit det för ett projekt bör du kunna återanvända det för alla andra projekt inom samma program
Problemdefinition beskriver problemet som projektet är tänkt att lösa. Den ska beskriva problemet i termer av de affärsfördelar som du förväntar dig att få när projektet är klart. Många människor får den här fel. Säg till exempel att ditt projekt är att uppgradera en grupp servrar från Windows Server 2003 till 2016. Jag har ofta sett människor skriva något som ”Problemet är att x-, y- och z-servrar kör Windows Server 2003”. Det faktum att en server använder ett föråldrat operativsystem är inte i sig ett problem. Du måste gräva i det verkliga affärsproblemet som löses. Det kan vara säkerhet, eller så kan det hända att du inte kan uppfylla dina SLA: er eftersom övervakningssystemet inte stöder 2003. Säg att du startar projektet och att du upptäcker att en av servrarna inte kan uppgraderas eftersom programvaran den kör är oförenlig med 2016. Ditt projekt är nu misslyckat. Men programvaran kommer att köras på Server 2010. Om du hade sagt att problemet handlar om säkerhet kan du bara installera 2010 och projektet är fortfarande en framgång.
Om du tittar på vad PRINCE2 och Managing Successful. Program (MSP) säger om projekt – de handlar om att skapa en förmåga. projektets mål bör handla om de möjligheter som du förväntar dig att vara på plats i slutet av projektet. Säg till exempel att du utvecklar en webbplats för ett resebokningsföretag. Syftet skulle vara att öka användarnas möjligheter att söka efter, boka och betala för resor med tåg, taxi, rickshaw osv.
Project Motivering är affärsmålet för projektet. Bara för att det finns ett problem som behöver lösas betyder det inte att företaget ska spendera pengar på att lösa det problemet. Alla organisationer har storleksordningar fler saker som de kan göra än det har antingen tid eller pengar att faktiskt uppnå. id = ”f1fe275139”> Projektets motivering bör berätta för läsaren vad den förväntade avkastningen på investeringen är för projektet
Projektets omfattning bör vara en punktlista över vad projektet kommer att göra och, ännu viktigare, vad det inte kommer att göra. Kommer till exempel projektet att leverera utbildningsmaterial? Kommer projektet att rekrytera det team som ska använda resultaten? Är projektets omfattning ett land, en region eller global?
Svar
Projektets bakgrund – Detta är bara sammanhanget snarare än själva projektet. Till exempel växer företaget, och det tar också mer personal. Ditt projekt är en teknisk uppdatering och kapacitetshöjning av HR-systemet. Du levererar inte tillväxt eller personal. Du levererar det nya HR-systemet.
Problemdefinition: Detta är inte en ren projektledning. Jag skulle säga att det rör bakgrund, eftersom det frågar vad som är problemet som behöver en lösning. Ditt projekt levererar kanske inte hela lösningen, så det kan inte lösa det bakomliggande problemet. Till exempel kommer din HR-uppdatering inte att matcha tillväxten i lönesystemet.
Syfte med projektet: Det vanliga term är mål och det finns två typer.
Affärsmål: Detta kan innefatta att kunna hantera en personalökning på x\%. Du kommer inte att leverera det – du fixar bara HR. Även om HR-systemet var det enda som behövde tillväxt, måste kunden titta på affärsprocesser, HR-personal, etc, för att kunna dra nytta av det nya systemet du Affärsmål är en bra sak att veta och ange, MEN de ligger INTE i din gåva.
Projektmål: Det här är resultaten som ditt projekt är utformat för att uppnå. Dessa ligger inom din gåva. är fortfarande på hög nivå, så förväxla inte dessa med leveranser.
Projektets motivering: Återigen, detta är verkligen en del av bakgrunden. I stor utsträckning är det inget av ditt företag! Om en klient vill ha en stor röd stolpe på sitt kontor och är beredd att betala för det är det hans affär.Någon, inte premiärminister, men ofta en affärsanalytiker, måste skapa ett affärsfall för att motivera arbetet och få utgifter godkända av budgetinnehavare. Normalt skulle detta vara a) Om jag spenderar X, kommer det att returnera X + Y, eller b) om jag spenderar X, undviker eller minskar vi riskkostnaden Y. Det här är inte ditt jobb och det har redan gjorts innan du är ombedd att definiera och köra ett projekt.
Projektets omfattning: Projektets omfattning är absolut kärnan i din domän som PM. Omfattningen definierar, i så exakta termer som möjligt, två saker: 1) Vad kommer projektet att göra? 2) Vad kommer INTE projektet att göra? Ditt projekt kommer att leverera ett nytt HR-system, men (kanske) kommer det inte att ge utbildning till kundens HR-personal. Det kommer inte att leverera extra HR-personal. Det inkluderar antagligen HR-slutet på löneintegration, men inkluderar förmodligen inte ändringar av lön. Etc. Omfattning definieras bäst på ett strukturerat sätt. Jag använder POLDAT
affärsprocess, organisation, plats, data, applikation, teknik.
Vad förändrar eller ändras inte ditt projekt inom dessa förändringsdomäner?
Skruva upp det här och du är i djupet —-