Hvilke roller og ansvar bør aftales ved softwareimplementering?

Hvorfor roller og ansvar skal aftales tidligt

Ifølge median.dk's gennemgang af typiske årsager fejler softwareprojekter sjældent på teknologien. Bliver et projekt forsinket, overskrider budgettet eller leverer ikke den forventede værdi, får teknologien ofte skylden. De største problemer opstår typisk længe før første linje kode.

Mange projekter starter med en løsningsidé i stedet for en forståelse af problemet. Ledelsen, brugerne og leverandøren har ofte forskellige opfattelser af, hvad projektet skal opnå, og udviklingen begynder alligevel. Uden afstemte forventninger fra starten bliver uenigheder senere næsten uundgåelige.

Det praktiske modtræk er at skrive aftalerne ned tidligt: navn på beslutningsejer, navn på krav-ejer, navngivne brugerrepræsentanter, hvor beslutninger dokumenteres, og hvem der kan eskalere hvad til hvem. Uklarhed om roller og beslutningskompetence står på median.dk's liste over, hvad der typisk går galt; klarhed over ansvar og beslutninger står på listen over alternativet.

Uklare vs. klare roller – konsekvenser for projektkørsel

Beslutningskompetence: Hvem ejer beslutningerne?

Et softwareprojekt involverer typisk ledelse, forretning, brugere, IT-afdeling og eksterne leverandører. Ved ingen, hvor beslutningsretten ligger, eller hvem der ejer kravene, opstår misforståelser og forsinkelser hurtigt.

Aftal derfor beslutningskompetencen i lag. Hvilke beslutninger kan projektgruppen selv træffe? Hvilke kræver en forretningsmæssig beslutning, og hvilke kræver ledelsen? Hvem kan sige nej til en ændring?

Og hvor længe må en eskaleret beslutning ligge, før den blokerer arbejdet? Før en beslutningslog, hvor hver post har dato, beslutning, beslutningsejer og konsekvens for tid, scope og økonomi. Nye deltagere skal kunne læse den uden mundtlig overlevering.

Før opstart er et af median.dk's kontrolspørgsmål, om alle kender beslutningsvejene. Er svaret nej, er det billigere at afklare nu end midt i en konflikt om en ændring.

Krav, scope og prioritering: Hvem ejer hvad?

Efterhånden som projektet udvikler sig, opstår næsten altid nye idéer og ønsker. Hver ændring kan virke lille, men tilsammen kan de ændre projektets omfang markant. Uden systematisk håndtering bliver både tidsplan og budget hurtigt urealistiske.

Aftal en krav-ejer i forretningen med mandat til at prioritere, og en fast vej for ændringsanmodninger: skriftlig beskrivelse, begrundelse, vurdering af konsekvenser for tid, pris og kvalitet samt en registreret beslutning. Beslutningen skal samtidig sige, hvad der tages ud eller udskydes i stedet, så omfanget ikke vokser ved hvert ja.

Enkle kriterier hjælper: Er ændringen nødvendig for det problem, projektet skal løse, eller er den et ønske, der kan vente til en senere version?

Succeskriterierne skal aftales sammen med kravene. Ifølge median.dk bør ledelsen før opstart kunne svare på, om man er enige om, hvad succes betyder. Uden aftalte kriterier kan ingen senere afgøre, om løsningen leverede den forventede værdi, og diskussionen ender i fortolkninger i stedet for målinger.

Forretningens og brugernes rolle gennem hele forløbet

Et softwareprojekt er ikke kun et IT-projekt. Ser brugerne først løsningen kort før ibrugtagning, er det ofte for sent at rette grundlæggende problemer. Løbende dialog med forretningen er afgørende for, at løsningen faktisk understøtter de arbejdsprocesser, den er udviklet til.

Aftal derfor navngivne brugerrepræsentanter med tid i kalenderen, ikke en rolle uden ansigt. Beslut, hvordan daglige arbejdsgange beskrives og godkendes, hvornår brugerne deltager i afprøvning, og hvem der siger ja til ændringer i en arbejdsgang, så ikke kun systemets funktioner vurderes.

Forretningens villighed til at prioritere er en forudsætning, der skal bekræftes før opstart. Et af median.dk's spørgsmål til ledelsen er: Er forretningen klar til at prioritere og involvere sig? Melder forretningen sig først ind, når løsningen er færdig, er der reelt ingen modpart til at træffe beslutninger undervejs.

Følger med brugere fra start – fordele vs. udfordringer

IT, leverandør og drift: Grænseflader og ansvar

Et softwareprojekt involverer typisk både intern IT, eksterne leverandører og efterfølgende drift. Aftal derfor, hvem der ejer teknik og arkitektur, hvem der ejer leverandøraftalen, hvem der er kontaktperson ved fejl, og hvem der træffer beslutninger om ændringer i det tekniske setup.

Kompleksiteten vokser hurtigt, når integrationer, eksisterende data og ændrede arbejdsgange kommer i spil. Også organisatoriske ændringer øger kompleksiteten.

Beskriv grænseflader konkret. Hvilke systemer udveksler data? Hvem ejer datakvaliteten i kildesystemet?

Hvem har ansvar for fejl mellem to systemer? Hvem stiller test- og driftsmiljøer til rådighed?

Overdragelsen til drift er et selvstændigt aftalepunkt. Beslut, hvad der skal være på plads, før driften overtager ansvaret. Beslut også, hvem der yder support i den første periode efter ibrugtagning.

Afklar, hvordan fejl rapporteres og prioriteres mellem drift, intern IT og leverandør. Ellers bliver uenighed om ansvar til uenighed om, hvor hurtigt en fejl skal rettes.

Adgangsstyring og identiteter: Hvem administrerer hvad?

Den fællesoffentlige referencarkitektur for brugerstyring definerer identitets- og adgangsstyring som administration og kontrol af brugere, identifikationsmidler og adgang til tjenester. Formålet er at sikre, at de rette brugere har adgang til de rette IT-systemer og data, mens alle andre afvises.

Aktiviteterne opdeles bredt i administration og adgangskontrol. Administrationen omfatter registrering og udstedelse af identifikationsmidler, der bruges til at autentificere og verificere en brugers digitale identitet, samt registrering af attributter som brugernavn, roller og rettigheder.

Adgangskontrollen omfatter autentificering, hvor brugerens digitale identitet godkendes og verificeres; attribut-attestation, hvor en digital identitets egenskaber godkendes og verificeres; og selve udførelsen af adgangskontrol, der afgør, hvilke funktioner og data en bruger får adgang til.

Adgangsstyringen udføres på baggrund af adgangspolitikker, der bygger på det besluttede niveau for informationssikkerhed, og som regulerer adgang til egne systemer og til eksterne parter. Aftal derfor, hvem der ejer politikkerne, hvem der registrerer og afregistrerer brugere, hvem der attesterer rettigheder, og hvor ofte attestationen gentages.

Afregistrering er lige så vigtig som registrering: En fratrådt medarbejders konto skal lukkes af en navngiven person, ikke af en tilfældig kollega.

Robotter, apps og enheder som identiteter

Referencarkitekturen for brugerstyring dækker ikke kun personer. Den viser, hvordan principperne bruges til at styre software-robotter som separate identiteter med egne identifikationsmidler, og den er udvidet med beskrivelser af, hvordan principperne kan anvendes på identitets- og adgangsstyring af apps og enheder (IoT).

Det giver en konkret regel at aftale: En robot, en app eller en enhed skal have sin egen identitet og sine egne rettigheder og må ikke låne en medarbejders konto. Knyt hver maskinidentitet til en ejer i organisationen, og beslut hvem der attesterer dens rettigheder.

Beslut også, hvad der sker, når integrationen eller enheden udfases, eller når den medarbejder, der oprindeligt satte den op, forlader organisationen.

Kommunikation, dokumentation og forventningsafstemning

Mange projekter lider under, at information ikke deles mellem de rigtige personer. Beslutninger træffes på møder uden at blive dokumenteret, og forventninger ændres, uden at alle involverede informeres. Resultatet er, at forskellige parter arbejder ud fra forskellige forståelser af projektet.

Aftal derfor ét sted, hvor beslutninger ligger, og hvem der opdaterer det. Aftal en fast kadence for status til ledelse, forretning, brugere, leverandør og drift, og hvem der informerer hvem, når scope, tidsplan eller succeskriterier ændres.

Ændringer i forventninger skal især ud af mødelokalet og ud til dem, der planlægger deres arbejde efter dem. En kommunikationsansvarlig betyder ikke, at alle andre holder op med at kommunikere. Det betyder, at én kan svare på, hvor en beslutning står skrevet, og hvornår den sidst blev bekræftet over for de berørte parter.

Kompleksitet og organisatoriske ændringer

Mange projekter virker enkle ved første øjekast. Når integrationer, data og nye arbejdsgange kommer i spil, og organisationen skal ændre sig, vokser kompleksiteten hurtigt. Det betyder ikke, at projektet er dømt til at mislykkes, men kompleksiteten skal anerkendes og håndteres fra begyndelsen.

Aftal derfor en ejer af kortlægningen: integrationspunkter og snitflader mellem systemer, datakilder og datakvalitet, hvilke arbejdsgange der ændres, og hvordan medarbejderne bliver klar til at arbejde på en ny måde. Organisatoriske ændringer har brug for deres egen ejer og tidsplan, fordi oplæring, bemanding og ændrede procedurer ikke følger den tekniske udrulning af sig selv.

En enkel ansvarsmodel at aftale på et tidligt møde

Beslutningsejer træffer de beslutninger, der ikke kan træffes i projektgruppen, og har mandat til at sige nej. Krav-ejer er forretningsansvarlig for krav, prioritering og ændringsanmodninger. Forretningsrepræsentant kan frigive medarbejdertid og prioritere mellem forretningsområder.

Brugerrepræsentant kender den daglige drift og de arbejdsgange, løsningen skal understøtte. IT-ansvarlig dækker teknik, integrationer, miljøer og sikkerhed. Leverandørkontakt dækker aftaler, ændringer og økonomi over for den eksterne part.

Adgangsadministrator står for registrering og udstedelse af identifikationsmidler og registrering af attributter som roller og rettigheder. Attestationsansvarlig godkender og verificerer en digital identitets egenskaber og dermed rettighederne. Kommunikationsansvarlig holder beslutningsloggen opdateret og informerer de berørte parter.

Rollerne skal knyttes til de fire spørgsmål fra median.dk, som ledelsen bør kunne svare ja til, før projektet går i gang. Spørgsmålene er: Ved vi, hvilket problem der skal løses? Er vi enige om, hvad succes betyder?

Kender alle beslutningsvejene? Er forretningen klar til at prioritere og involvere sig? Er et svar nej, mangler en rolle eller beslutningsvej stadig at blive aftalt.

Tilføj de aftalepunkter, der er specielle for dette projekt. Hvem ejer adgangspolitikkerne? Hvem ejer maskinidentiteter som robotter, apps og enheder?

Hvem ejer kortlægningen af integrationer og data? Hvordan kommer ændringer fra brugerne og ind i prioriteringen? Skriv navne på, ikke kun titler.

Aftaleproces for roller og ansvar ved softwareimplementering

Vigtige kontrolspørgsmål fra median.dk før projektstart

Konklusion: Aftal ansvar før implementeringen begynder

De aftaler, der betyder mest, handler om beslutningskompetence, krav og scope, forretningsinvolvering, adgangsstyring, kommunikation og håndtering af kompleksitet. De kan skrives på én side med navne, beslutningsveje, ændringsprocedure og kontaktpunkter for adgang og attestation og bruges som tjekliste på et tidligt møde, før udviklingen begynder.

Uden klare aftaler om roller og ansvar øges risikoen for forsinkelser og budgetoverskridelser. Uklare roller og beslutningskompetence skaber misforståelser. Ændringer uden systematisk håndtering gør tidsplan og budget urealistiske. En forretning, der først kommer ind kort før ibrugtagning, kan ikke nå at rette grundlæggende problemer.

Samtidig skal kompleksiteten i integrationer, datakilder, nye arbejdsgange og organisatorisk forandring anerkendes og have en ejer fra begyndelsen.