businesscase.dk > Nyheder > artikler om business case > 3 styringsniveauer af forretningskritiske initiativer

3 styringsniveauer af forretningskritiske initiativer

Vi har fået et indlæg fra en af eksperterne i 1stroke om styringsniveauer af forretningskritiske initiativer. Partner, Martin J. Ernst, 1stroke fortæller:

I 1stroke arbejder vi ud over business case og gevinstrealisering også med ledelse af forretningskritiske initiativer. Nogle vil måske spørge om det er det samme som et projekt? Men vi mener, at ordet “projekt” ikke er dækkende for dét, vi laver. Vi sikrer, at det, som er anset som en af de vigtigste tiltag i en virksomhed, bliver fulgt til dørs. Det starter med en business case, det forsætter med ledelse og slutter af med gevinstrealisering.

Emnet for denne blog er, hvordan vi sikrer at store forretningskritiske initiativer har fremdrift. Især initiativer med mange projektdeltagere spredt over mange lokationer.

 

Fra hovedplan til distribueret aktivitetsliste

Vi i 1stroke har i mange år stået i spidsen for sådanne projekter. Og svaret på styring er applikationer til aktivitetsstyring, hvor man kan følge med i fremdriften af vigtige detaljer uden at miste overblikket. Vi kalder det også en distribueret aktivitetsliste.

Dette kan ske i hvilket som helst system. I dette eksempel er JIRA fra Atlassian anvendt. Vi får ikke noget for at nævne dem, men grunden til at det er valgt som eksempel, er, at det er det seneste værktøj, vi har anvendt.

I det hele taget virker det som ganske sund fornuft, men det viser sig i mange omgange, at lige netop sans for detaljen på store komplekse projekter er afgørende for, at implementeringen bliver en succes eller ej.

Vores tilgang er heller ikke revolutionerende og er allerede kendt fra planlægning af produktioner, supply chain, personaledisponering mm.

 

What we do:

  1. Skaber en hovedplan
  2. For hver hovedaktivitet i hovedplanen udarbejder vi en produktbaseret plan, hvor processen bliver afklaret
  3. Vi nedbryder den produktbaseret plan i konkrete aktiviteter flankeret af issues (emner), fejl, testcases, ændringsanmodninger

 

Ad 1) Skabe en hovedplan

I den nedenstående figur er vist en hovedplan, hvor bl.a. Funktionsprøve, Slutbrugertest, Overtagelsesprøve, Installationsprøven etc. er en hovedaktivitet.

 

Den røde stiplede linje er ”hvor er vi kommet til” dvs. dags dato linjen.

I det følgende stiller vi skarpt på selve Installationsprøven.

 

Ad 2) For hver hovedaktivitet i hovedplanen udarbejd en produktbaseret plan, hvor processen bliver afklaret

For installationsprøven er der opstillet denne produktbaseret plan, hvor man kan se processen og de produkter, som er nødvendige for at færdiggøre installationsprøven:

 

 

Af figuren kan vi se, at der først skal udarbejdes en testplan (som produkt), og derefter følger en godkendelse af denne plan (som produkt). Umiddelbart derefter kan tre produkter fremstilles på samme tid: Udarbejdelse af testdrejebog/testcases, installationsvejledning og installationsscripts. Når de tre produkter er færdige, kan selve installationen starte og så fremdeles.

 

Ad 3) Nedbryd den produktbaserede plan i konkrete aktiviteter

Nedenfor er eksemplet på en aktivitet, hvor både en planlagt opgave, issue, bugs etc. er repræsenteret. Fra eksemplet overfor (den produktbaseret plan), så er det produktet ”1. Installation”, som er vist her:

 

 

Af den ovenstående figur ses, at der er en række ”JIRA”s, som knytter sig til dette produkt (JIRAs er fælles betegnelsen for opgave, issue, bug, etc.). Det er således muligt at knytte både JIRAs af typen ”fejl”, ”planlagte opgaver”, ”issues”, ”testcases” etc. til et produkt. Det gør det muligt både at have en struktur, som ikke nødvendigvis skal laves om og have den fleksibilitet til at bryde opgaver så langt ned, som det er nødvendigt (og så ikke længere).

 

Brug af Confluence til projektdokumentation og overblik

Udfordringen med JIRA er, at hvis man ikke strukturerer sig via de felter af metadata, som applikationen stiller til rådighed, så mister man lynhurtigt overblikket. Et forretningskritisk projekt kan nemt starte på 5.000 aktiviteter og kan til slut blive langt flere ”JIRAs”.

Derfor er det vigtigt, at man sikrer sig et overblik via views i JIRA eller via sider i Confluence, hvor opgaver kan vises i et overskueligt format. Det er også muligt at oprette forskellige grafer, som viser fremdrift, overblik over fejlmængde etc. Som alt andet god design så skal man starte med rapporteringsbehovet, før man designer løsningen. JIRA kan efterfølgende konfigureres til det behov (inkl. rapporteringsbehov) man har.

 

Sammenhæng med business casen og gevinstrealisering

Der er en helt klar sammenhæng mellem business casen og gevinstrealisering og den ovenstående beskrivelse af god styring i projektet. Bl.a. Stephen Jenner (forfatter til Benefit Realisation” og bidragsyder til bl.a. MSP) siger i hans model, at det er vigtigt man har implementeret en god metode, og at man har en god styring af dette.

Se figuren nedenfor:

 

Hvis du vil vide mere er du velkommen til at kontakte: Martin J. Ernst på mail eller telefon +45 2991 1122