Warning: The magic method OCDI\OneClickDemoImport::__wakeup() must have public visibility in /customers/0/1/6/daypay.no/httpd.www/wp-content/themes/onecom-express/importer/inc/OneClickDemoImport.php on line 121
Warning: Cannot modify header information - headers already sent by (output started at /customers/0/1/6/daypay.no/httpd.www/wp-content/themes/onecom-express/importer/inc/OneClickDemoImport.php:121) in /customers/0/1/6/daypay.no/httpd.www/wp-includes/rest-api/class-wp-rest-server.php on line 1831
Warning: Cannot modify header information - headers already sent by (output started at /customers/0/1/6/daypay.no/httpd.www/wp-content/themes/onecom-express/importer/inc/OneClickDemoImport.php:121) in /customers/0/1/6/daypay.no/httpd.www/wp-includes/rest-api/class-wp-rest-server.php on line 1831
Warning: Cannot modify header information - headers already sent by (output started at /customers/0/1/6/daypay.no/httpd.www/wp-content/themes/onecom-express/importer/inc/OneClickDemoImport.php:121) in /customers/0/1/6/daypay.no/httpd.www/wp-includes/rest-api/class-wp-rest-server.php on line 1831
Warning: Cannot modify header information - headers already sent by (output started at /customers/0/1/6/daypay.no/httpd.www/wp-content/themes/onecom-express/importer/inc/OneClickDemoImport.php:121) in /customers/0/1/6/daypay.no/httpd.www/wp-includes/rest-api/class-wp-rest-server.php on line 1831
Warning: Cannot modify header information - headers already sent by (output started at /customers/0/1/6/daypay.no/httpd.www/wp-content/themes/onecom-express/importer/inc/OneClickDemoImport.php:121) in /customers/0/1/6/daypay.no/httpd.www/wp-includes/rest-api/class-wp-rest-server.php on line 1831
Warning: Cannot modify header information - headers already sent by (output started at /customers/0/1/6/daypay.no/httpd.www/wp-content/themes/onecom-express/importer/inc/OneClickDemoImport.php:121) in /customers/0/1/6/daypay.no/httpd.www/wp-includes/rest-api/class-wp-rest-server.php on line 1831
Warning: Cannot modify header information - headers already sent by (output started at /customers/0/1/6/daypay.no/httpd.www/wp-content/themes/onecom-express/importer/inc/OneClickDemoImport.php:121) in /customers/0/1/6/daypay.no/httpd.www/wp-includes/rest-api/class-wp-rest-server.php on line 1831
Warning: Cannot modify header information - headers already sent by (output started at /customers/0/1/6/daypay.no/httpd.www/wp-content/themes/onecom-express/importer/inc/OneClickDemoImport.php:121) in /customers/0/1/6/daypay.no/httpd.www/wp-includes/rest-api/class-wp-rest-server.php on line 1831
{"id":896,"date":"2022-04-25T14:38:49","date_gmt":"2022-04-25T13:38:49","guid":{"rendered":"https:\/\/www.daypay.no\/?p=896"},"modified":"2022-04-25T14:43:09","modified_gmt":"2022-04-25T13:43:09","slug":"sjekkliste-for-a-handtere-prosjekter","status":"publish","type":"post","link":"https:\/\/www.daypay.no\/sjekkliste-for-a-handtere-prosjekter\/","title":{"rendered":"Sjekkliste for \u00e5 h\u00e5ndtere prosjekter"},"content":{"rendered":"\n
Har du noen gang \u00f8nsket deg en kort liste over elementer du kan holde “i sjakk” mens du administrerer prosjekter? Denne korte listen vil inneholde n\u00f8kkeltiltak som, hvis alltid holdt i sjakk og balanse, ville f\u00f8re deg til prosjektsuksess? Klart det er viktig \u00e5 f\u00f8lge bransjeprosjektretningslinjene fra Project Management Institute og innenfor Project Management Professional (PMP) Certification, men det er viktig \u00e5 alltid ha disse n\u00f8kkeltiltakene i forgrunnen HELE VEIEN gjennom prosjektet – fra begynnelsen til fullf\u00f8ring. Noen ganger kan disse faktorene overses eller glemmes, eller tenkes p\u00e5 som “ikke n\u00f8dvendig” i hastverket for \u00e5 f\u00e5 i gang et prosjekt. St\u00e5 opp og stopp galskapen, s\u00f8rg for at du har en klar sti f\u00f8r du pr\u00f8ver \u00e5 komme deg til m\u00e5let ditt\u2026 Ellers vil du g\u00e5 deg vill underveis.<\/p>\n\n\n\n
N\u00f8kkeltiltak:<\/p>\n\n\n\n
F\u00f8r du i det hele tatt ser p\u00e5 forretningskrav eller bruker mye tid p\u00e5 et prosjekt, s\u00f8rg for at du vet: en. Hvem er den ut\u00f8vende sponsoren og f\u00e5 f\u00f8lgende informasjon direkte fra den sponsoren: Jeg. Prosjektintensjoner og omfang ii. Hva prosjektet IKKE er eller hva som er utenfor omfanget iii. Hvem “kundene” er for prosjektet. (mange ganger er kunder interne i organisasjonen) iv. Hvis et avkastningsdokument er opprettet og hva som forventes av et ROI-dokument. Hvilke omr\u00e5der av virksomheten forventes avkastning? v. Prosjektbudsjett og hvordan utgifter godkjennes vi. Forventede prosjektsuksessfaktorer vii. At de \u00f8nsker at dette prosjektet skal g\u00e5 videre p\u00e5 det n\u00e5v\u00e6rende tidspunkt, hvis ikke, n\u00e5r skal det starte viii. Forventet tidslinje for ferdigstillelse av prosjektet ix. Enighet om \u00e5 sette bedriftens ressurser p\u00e5 prosjektet for \u00e5 f\u00e5 det til x. N\u00f8dvendig prosjektstatus og rapportering xi. Avtale om kommunikasjonsplan til sponsorer, kunder og andre ber\u00f8rte parter xii. Enighet om tildelt prosjektleder og st\u00f8tte fra sponsor om at hvis det er problemer med prosjektet som krever oppmerksomhet fra den ut\u00f8vende sponsoren, at sponsoren vil gi st\u00f8tte for \u00e5 oppn\u00e5 vedtaket b. Skriv deretter all denne informasjonen skriftlig, vanligvis i et slags prosjektinitieringsdokument, og deretter signerer alle prosjektledere, sponsorer og kunder og CIO dokumentet. Jeg kan ikke stresse hvor viktig denne delen er. Jeg kan ikke understreke hvor mange ganger vi har kommet til slutten av et prosjekt og minst \u00e9n av disse partene (sponsorer, kunder eller CIO) sier at de aldri har godtatt noen del av den dokumenterte informasjonen i prosjektinitieringsdokumentet. Dette er spesielt viktig for systemimplementeringsprosjekter ettersom det kan g\u00e5 mye tid mellom prosjektet ble igangsatt og det endelige produktet leveres.<\/li>
Forretningskrav en. Det er sv\u00e6rt viktig, f\u00f8r du snakker med noe IT-personell (hvis prosjektet involverer intern IT \u2013 som, hvis det er systemimplementering, det mest sannsynlig vil gj\u00f8re det) eller produktleverand\u00f8rer, at du tar deg tid til \u00e5 dokumentere alle forretningskrav fra alle. kunder. Dokumentasjon av forretningskrav b\u00f8r som et minimum inneb\u00e6re \u00e5 g\u00e5 gjennom f\u00f8lgende trinn: Jeg. Identifisere fageksperter og prosjektrepresentanter fra hver del av virksomheten som fungerer som dine kunder for sluttresultatet av prosjektet. 1. Identifiser gjeldende problem eller behov 2. Dokumentere aktuelle prosesser 3. Diskuter hva som ikke fungerer med prosessen 4. Gjennomg\u00e5 resultater de \u00f8nsker \u00e5 se for \u00e5 st\u00f8tte virksomheten og analyser de m\u00e5 utf\u00f8re for \u00e5 administrere virksomheten ii. I dokumentasjonen for forretningskrav, IKKE bruk tid p\u00e5 \u00e5 diskutere hva systemer eller teknologi vil tillate dem. Diskuter hva som trengs for virksomheten. Ikke la kundene pr\u00f8ve \u00e5 definere en prosess rundt systemer eller teknologi. Teknologi er der for \u00e5 st\u00f8tte virksomheten, ikke for \u00e5 diktere hvordan en virksomhet skal drives. Ikke bekymre deg, alle de tekniske delene vil komme sammen senere. iii. Dokumenter alle forretningskrav som diskutert med alle kundegrupper og fageksperter. Pass p\u00e5 at du spesifiserer problemene og behovene, hvordan det skader virksomheten, hva som trengs, og hvordan det vil hjelpe virksomheten. V\u00e6r spesifikk. Denne informasjonen vil hjelpe deg \u00e5 sette sammen ROI-dokumentet for \u00e5 v\u00e6re sikker p\u00e5 at kostnadene og de forventede fordelene er i tr\u00e5d med hva prosjektsponsoren(e) forventer. Noen prosjektledere kan v\u00e6re uenige her og si at avkastningen b\u00f8r gj\u00f8res f\u00f8r de kommer til virksomhetens kravstadiet. Imidlertid har jeg alltid funnet at nye investeringsomr\u00e5der (kostnad) og avkastning p\u00e5 investeringen presenterer seg n\u00e5r de g\u00e5r gjennom prosessen for oppdagelse av forretningskrav.<\/li>
iv. S\u00f8rg alltid for \u00e5 tenke p\u00e5 hvordan et produkt skal brukes og hvordan rapportering vil kreves. Dette kan virkelig f\u00e5 deg til slutt hvis du ikke f\u00f8lger n\u00f8ye med p\u00e5 forh\u00e5nd under kravfasen.<\/li>
v. Du vil deretter matche forretningskravene til omfanget du opprettet i prosjektinitieringsdokumentet, eller endre omfanget, noe som vil kreve en endring av prosjektinitieringsdokumentet som krever nye signaturer.<\/li>
vi. N\u00e5r det riktige settet med krav er dokumentert og det stemmer overens med prosjektets omfang, s\u00f8rg for \u00e5 igjen ha prosjektsponsorer, kunder (husk, kunder kan v\u00e6re interne eller eksterne), og CIO som erkjenner at dette er forretningskravene, at prosjektet er aktive og sponsede, og at de er enige om \u00e5 g\u00e5 videre til neste prosjektfaser. Dette stykket er spesielt viktig, ettersom folk har en tendens til \u00e5 glemme eller si ting som “Jeg har aldri sagt det” n\u00e5r du kommer lenger i prosjektet. Du kan alltid bringe dem tilbake til den opprinnelige dokumentasjonen og signaturene.<\/li>
F\u00e5r du ikke underskrifter, er du en sittende and.<\/li><\/ol>\n\n\n\n
N\u00e5 er det p\u00e5 tide \u00e5 finne ut hvordan du skal oppfylle disse forretningskravene. Dette f\u00f8rer vanligvis til en kj\u00f8ps- eller byggebeslutning. Det vil si, kj\u00f8p programvare fra en leverand\u00f8r som spesialiserer seg p\u00e5 den type produkt som trengs, eller bygg med internt IT-personell. Forretningskravdokumentet er ditt grunnlag for \u00e5 evaluere kj\u00f8ps- eller byggebeslutningen. Ikke g\u00e5 bort; ikke utvide omfanget eller budsjettet uten \u00e5 g\u00e5 tilbake gjennom avmeldingsprosessen. Hvis du “kj\u00f8per” et produkt fra en leverand\u00f8r, gj\u00f8r den f\u00f8rste “nedskj\u00e6ringsprosessen” for \u00e5 finne de beste programvareproduktene som samsvarer med forretningskravene.<\/li>
N\u00e5 som du har din toppliste over programvarekonkurrenter, f\u00e5 demonstrasjoner utf\u00f8rt av leverand\u00f8rene for kundegruppen(e). De kan hjelpe til med \u00e5 stemme p\u00e5 det valgte produktet. Det er avgj\u00f8rende \u00e5 f\u00e5 buy-in fra kundene dine hvert trinn p\u00e5 veien.<\/li>
Hvis mulig, er det en god id\u00e9 \u00e5 utf\u00f8re en pr\u00f8vefase med 2 toppleverand\u00f8rer for \u00e5 se hvordan forretningskravene samsvarer med produktet.<\/li>
Etter pr\u00f8vefasen, kom tilbake med kundene dine for \u00e5 demonstrere produktene mot forretningskravene. Deretter f\u00e5r kundene dine gj\u00f8re sitt endelige valg. P\u00e5 det tidspunktet m\u00e5 du s\u00f8rge for at det er skrevet et teknisk spesifikasjonsdokument som samsvarer med forretningskravene. Form\u00e5let med det tekniske spesifikasjonsdokumentet er \u00e5 demonstrere innenfor produktet, hvordan forretningskrav vil bli oppfylt, hvilke forretningskrav som ikke kan oppfylles eller bare kan oppfylles delvis, og IT-kravene til produktet. V\u00e6r sikker p\u00e5 at du, f\u00f8r du starter en st\u00f8rre utviklingsfase, har g\u00e5tt tilbake til dine sponsorer, kunder og CIO eller andre representanter for IT-parter for \u00e5 bli enige om spesifikasjonene og avtalen for \u00e5 g\u00e5 videre. Denne fasen vil ogs\u00e5 kreve en oppdatert prosjektplan som beskriver hele utviklingsplanen, ressurskrav og engasjement fra involverte parter.<\/li>
S\u00f8rg for \u00e5 gj\u00f8re en “pulssjekk” med dine kunder og sponsorer p\u00e5 mange punkter gjennom utviklingssyklusen. Dette vil sikre at kundene dine ikke blir overrasket over sluttresultatet eller at du ikke har g\u00e5tt helt ned p\u00e5 en vei som de ikke \u00f8nsket eller at du utviklet noe feil. Det er mye bedre \u00e5 fange disse tingene mens utviklingen fortsatt p\u00e5g\u00e5r \u2013 tidslinjen din vil sannsynligvis bli p\u00e5virket mye mindre p\u00e5 denne m\u00e5ten OG oppfatningen av prosjektsuksess hos kunder og sponsorer vil v\u00e6re mye h\u00f8yere p\u00e5 denne m\u00e5ten. Til syvende og sist er det best \u00e5 ikke ha noen slike “hang-ups” under utviklingsprosessen. Men det er sannsynligvis ikke realistisk \u00e5 forvente at du ikke vil ha noen. Det er prosjektlederens jobb \u2013 \u00e5 jobbe gjennom slike problemer og likevel fullf\u00f8re prosjektet i tide.<\/li>
N\u00e5r utviklingsfasen er fullf\u00f8rt, er det viktig at du ikke bare har dokumentert hvordan du bruker produktet, men hvordan det p\u00e5virker forretningsprosessene. Det vil kreve diskusjon med kundegrupperepresentanter om hva systemet n\u00e5 skal gj\u00f8re, og hvordan den nye prosessen skal se ut. Det er viktig \u00e5 ha dette dokumentet og v\u00e6re i samr\u00e5d med kundegrupperepresentanter F\u00d8R en eventuell produktutrulling skjer. Hvis du gj\u00f8r dette, kan du forvente en mye jevnere trenings- og utrullingsfase av produktet enn om du bare pr\u00f8ver \u00e5 kaste produktet ut der. Dersom du ikke har en n\u00f8ye planlagt oppl\u00e6rings- og utrullingsfase, vil alt arbeidet ditt g\u00e5 i vasken, og prosjektet vil mest sannsynlig ikke oppleves som noen stor suksess.<\/li>
Under utrullings- og oppl\u00e6ringsfasen er det ekstremt viktig \u00e5 kommunisere hva brukerne m\u00e5 gj\u00f8re dersom de trenger hjelp til produktet.<\/li><\/ol>\n\n\n\n
Har du noen gang \u00f8nsket deg en kort liste over elementer du kan holde “i sjakk” mens du administrerer prosjekter? Denne korte listen vil inneholde n\u00f8kkeltiltak som, hvis alltid holdt i sjakk og balanse, ville f\u00f8re deg til prosjektsuksess? Klart det er viktig \u00e5 f\u00f8lge bransjeprosjektretningslinjene fra Project […]<\/p>\n","protected":false},"author":2,"featured_media":2121,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_oct_exclude_from_cache":false,"_uag_custom_page_level_css":"","footnotes":""},"categories":[1],"tags":[],"yoast_head":"\n
Sjekkliste for \u00e5 h\u00e5ndtere prosjekter - DayPay<\/title>\n\n\n\n\n\n\n\n\n\n\n\n\t\n\t\n\t\n\n\n\n\t\n\t\n\t\n