Forretningskritiske initiativer skal ledes og styres

Hvordan sikrer vi, at store forretningskritiske initiativer har fremdrift? Især de initiativer, som har mange projektdeltagere spredt over mange lokationer? Martin J. Ernst, 1Stroke giver sit bud på tre styringsniveauer.

Management

Ledelse af de forretningskritiske projekter er et af de vigtigste tiltag i en hvilken som helst offentlig eller privat virksomhed, når man vil sikre sig, at ideer bliver fulgt til dørs. Foto: Getty Images

Til hverdag arbejder jeg både med business cases, gevinstrealisering og med ledelse af forretningskritiske initiativer. Nogle vil måske spørge, om det er det i virkeligheden ikke er det samme som et projekt?

Men jeg mener, at ledelse af forretningskritiske initiativer dækker over meget og mere end ordet “projekt”.

For netop ledelse af de forretningskritiske projekter er et af de vigtigste tiltag i en hvilken som helst offentlig eller privat virksomhed, når man vil sikre sig, at ideer bliver fulgt til dørs.

Det hele starter med en business case, det forsætter med ledelse og slutter af med gevinstrealisering.

Emnet for dette indlæg er, hvordan vi sikrer, at store forretningskritiske initiativer har fremdrift. Især når der er tale om initiativer med mange projektdeltagere spredt over mange lokationer.

Fra hovedplan til distribueret aktivitetsliste
Med udgangspunkt i vores erfaring fra en lang række projekter er svaret på styring: 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.

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

Ad 1) Skab 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.

Hvad vi gør

Hovedplan

Den røde stiplede linje er en oversigt, der viser,  ”hvor er vi kommet til” dvs. dags dato linjen.

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

Ad 2) Udarbejd en produktbaseret plan for hver hovedaktivitet
For installationsprøven er der opstillet en produktbaseret plan, hvor man kan se processen og de produkter, som er nødvendige for at færdiggøre installationsprøven:

Produktbaseret plan

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:

Aktiviteter

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
Og 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, som er 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.

Gevinsthus