CMMI Version 2 overblik

CMMI - eller Capability Maturity Model Integration - er en model baseret på best practice for forretningskritiske processer og for etablering/forbedring af processer. CMMI V2 udkom i 2018 og indeholder i langt større omfang eksempler fra den agile praksis.

CMMI Version 2 overblik

Share:
    Indhold       ► De 5 modenhedstrin   ► CMMI set fra en organisation   ► CMMI modellens struktur   ► CMMI Practice Areas   ► Modenhed - hvordan det opleves i organisationen  ► Resumé og nyttige links

austin-distel-1590560-unsplash.jpg

CMMI modellens indhold i overordnede træk

CMMI - eller Capability Maturity Model Integration - er en model baseret på best practice for forretningskritiske processer og for etablering/forbedring af processer.  CMMI giver flere muligheder for anvendelse, som i tabellen herunder beskrives ud fra en "landkort" metafor.  CMMI er idag ejet af ISACA og modellen kan købes her  CMMI Institute.

CMMI som landkort
Uden CMMI Med CMMI
Uden at vide hvor man er, er landkortet uden værdi CMMI kan bruges til at måle organisationens modenhed - styrker og svagheder og dermed sige noget om, hvor man er.
Uden at kende destinationen, giver landkortet ikke muligheden for at nå målet. CMMI giver modenhedstrinene et forretningsmæssigt og relevant mål for forbedringsrejsen.
Uden at kunne læse landkortets information som højdekurver og landemærker, så er det svært at finde den optimale vej til destinationen. CMMI's detaljerede beskrivelser af praksis på en række områder giver tilstrækkelige information til at oversætte dette til forretningstilpasset praksis.

 

De 5 modenhedstrin

De 5 modenhedstrin har været en del af modellen helt fra start, og er en stærk måde at kommunikere, at modning af organisationen kan gennemføres i flere etaper, der hver især skaber stor værdi. 

CMMI's 5 modenhedstrin

 

Tryk på overskrifterne herunder for at læse mere om de forskellige modenhedsniveauer.

CMMI Modenhedsniveau 1

CMMI opstiller ingen krav til at være på modenhedsniveau 1. Organisationer er her kendetegnet ved hyppige forsinkelser og fordyrelser af projekter samt lav tro på at følge processer og stor optimisme omkring ressourcebehovet. Denne cocktail leder til mange overraskelser og til meget uplanlagt overarbejde. Ineffektivitet, der nogle gange er uerkendt, er typisk høj, eks. vil projektressourcer til at rette egne fejl (eng. rework) typisk udgøre 35-45%. Succeser skyldes primært kompetente medarbejdere, der evner at samarbejde effektivt i uformelle netværk, dog ofte også kombineret med mange møder med mange interessenter. Projekter må ofte kæmpe unødigt hårdt for at op at opnå succes.

CMMI Modenhedsniveau 2

Succesfuld projekteksekvering er livsnerven i udviklingsorganisationer, så det er det første, der skal fokus på, og som skaber tillid fra omverdenen. Derfor bruges projektformen (klassisk såvel som agil) på en disciplineret måde understøttet af grundlæggende processer. Projektet har planer og beskrevne processer, men sidstnævnte behøver endnu ikke være ens på tværs af projekter. Ledelsen bidrager ved at gøre organisationens forventninger klare, stille nødvendige ressourcer til rådighed, samt ved at fastlægge ansvarsforholdene for projektets deltagere og interessenter.

Hvad gør man:

  • Etablerer projekter som ramme for at gennemføre opgaver
  • Forøger forudsigelighed for projekter gennem basale mekanismer såsom klare kunde- og produktkrav, planlægning og opfølgning understøttet af målinger
  • Beskriver de processer, der skal bruges, og sikre, at de fungerer efter hensigten i projektet
CMMI Modenhedsniveau 3

Dette niveau tager sit naturlige udgangspunkt i allerede velfungerende processer i organisationen. Da den basale projektevne er på plads, efterspørges standardiserede processer (f.eks. ensartet estimering, rapportering, risikostyring og engineering) herunder fortsat mulighed for at skræddersy dem til det enkelte projekt. Uddannelse i processen kombineret med et forbedringsfokus hjælper med til at holde procesbeskrivelserne så korte og koncise som mulige, at forøge medarbejdernes effektivitet og at skabe projektmobilitet (der arbejdes på nogenlunde samme måde, der hvor det giver mening).

Hvad gør man:

  • Etablerer den tekniske proces, med de til organisationen passende elementer af krav, arkitektur, design, konstruktion, review, integration, test og leverance
  • Harmoniserer og spreder fælles processer, understøttet af organisatorisk uddannelse
  • Bruger disse processer i projekterne og involverer alle relevante interessenter
  • Bruger risikostyring aktivt på alle niveauer i organisationen
CMMI Modenhedsniveau 4

På dette niveau arbejdes med at forstå og forbedre produkt- og projektkritiske processer (f.eks. review, systemtest, estimering). Dette ved at ramme det ønskede kvalitetsniveau ved systematisk at fjerne årsager til uønsket variation. Midlerne er i høj grad baseret på flere og bedre brug af de målinger, som blev indført på modenhedsniveau 2. Der bruges statistisk proceskontrol (SPC), Six Sigma og andre kvantitative metoder, som er relevante på dette modenhedsniveau, fordi processerne nu er, eller nærmer sig at være stabile.

Hvag gør man:

  • Reducerer den variation, som altid findes ved udførelse af processer – eksempelvis estimeringens nøjagtighed eller kvalitetssikringens effektivitet
  • Bruger organisatoriske erfaringer og data for at opnå bedre forudsigelighed og træfsikkerhed gennem statistiske målinger af kritiske forhold omkring projektgennemførelse og processer
  • Definerer kvantitative mål, der danner udgangspunkt for planlægning og styring af projektet
CMMI Modenhedsniveau 5

Hvor modenhedsniveau 4 handlede om at ramme de definerede kvalitetsmål, så handler dette øverste modenhedsniveau om at optimere indsats og resultat. Fokus retter sig derfor mod at finde de bedste forbedringer og at gennemføre disse via et smidigt procesapparat, som har stor omstillingsevne. De bedste forbedringer findes ved estimering af cost/benefit baseret på den forretningsmæssige værdi og tilgængelige historiske data.

Hvad gør man:

  • Optimerer gennem kontinuert forbedring
  • Prioriterer forbedringer efter beregnet cost/benefit

Modellens kerneprocesser set fra en organisation

CMMI modellens Practice Areas er herunder fordelt i et "organisationsdiagram", hvor centrum består af den konkrete produktudvikling i et konkret projekt.

cmmi2_system_tegning.png

CMMI Level 2

Begynder vi med niveau 2 processerne (Blå kasser), så bliver

"Business objectives"omsat til nogle få forretningsrelevante målinger (fx omkostninger, tid, kvalitet) via "Managing Performance og Measurement"processen (MPM), og roller og ansvar, ressource-allokering, godkendelser mv. sikret gennem "Governance"processen.

"Needs and Requirements"- dvs kundekrav og kundebehov omsættes via "Requirements Development & Management"til en række funktionelle og ikke-funktionelle krav og ændringsstyres undervejs.

"Work", som tager udgangspunkt i kundekravene, bliver estimeret via "Estimating", og indgår i en planlægningsproces via "Planning"som leverer tidsplaner, ressourcebehov, interessent- og kommunikationsplaner og andre typiske planlægningselementer, og som efter en review og godkendelsesproces indgår i en efterfølgende projektproces og følges op på via "Monitor & Control". 

"Performance Insight" benytter sig af de målinger, som MPM processen leverer, og hertil sikrer "Process Quality Assurance", at projektet følger de aftalte processer, som projektet har opstillet via "Implementation Infrastructure", der fx leverer projektets værktøjer og metoder.

"Configuration Management"processen sikrer, at projektet versions- og ændringsstyrer dokumentation, sourcekode, test samt andre artefakter, der måtte indgå i produktet eller projektet. "Supplier Agreement Management"processen sikrer styring af eventuelle underleverandører til projektet.

CMMI Level 3

Når vi har forankret Niveau 2 processerne i tilstrækkelig grad, udvider vi kompetencerne med at kortlægger niveau 3 processerne (Grønne kasser).

"Business objectives" udvides nu med "Process Asset Development", som sikrer, at vi får beskrevet vore processer i et ledelsessystem (fx ISO9001 baseret QMS), og "Process Management" processen sikrer, at vi får indsamlet værdifuld information om forbedringer på en måde, så det kan genbruges af efterfølgende projekter, som finder disse informationer i QMS'et såvel som i styrede databaser "Organisational Process Assets". Eksempler på dette kan være blivende dokumentation om vore produkter, system arkitekturer og deres tilhørende estimater, test-databaser, værktøjer og metoder.
"Work"udvides med "Risk and Opportunity Management", da en niveau 2 organisation har opnået tilstrækkeligt erfaring og overskud til at håndtere risici på et organisatorisk niveau.
"Organisational Training"sikrer, at udviklingsorganisationens kompetencer opbygges og vedligeholdes ud fra de strategiske og organisatorisk mål "Business objectives", herunder at folk er uddannede i at bruge de organisatoriske processer, værktøjer og metoder.
"Needs and Requirements"udvides med en række tekniske processer. 
"Technical Solution"oversætter kravene til arkitektur, design, kode med metoder og værktøjer, som har bevist, at de leverer produkter med tilstrækkelig kvalitet. 
"Product Integration"sikrer, at projektet planlægger system integration i en hensigtsmæssig rækkefølge - der fx tager højde for risici omkring nye interfaces samt sikrer release af produktet. 
"Peer Reviews"sikrer tidlig kvalitetssikring af vigtig dokumentation, kode og test. "Verification & Validation"sikrer, at projektet får planlagt test and validering på en hensigtsmæssig måde, så projektet dels leverer det korrekt produkt ud fra aftalte krav, men også sikrer, at produktet passer til kundens brugssituation. "Causal Analysis & Resolution"sikrer, at vi lærer af vore fejl og forstår, hvorfor de opstår. Vi sørger også for, at læringen indgår i at forbedrer processer mv. på en måde, så fejlene ikke opstår igen."Decision Analysis & Resolution"processen benytter vi, når vi skal træffe komplicerede valg, hvor det er hensigtsmæssigt at opstille flere muligheder og udvælge den rette ud fra nogle aftalte parametre. 

En CMMI Niveau 3 organisation samler sine læringer og best practices i et QMS, og det inkluderer naturligvis også Niveau 2 processern (de blå i diagrammet), der nu løftes til et organisatorisk niveau. Et eksempel kunne være, at organisationen indfører en fælles metode for estimering. 

CMMI Level 4 og 5

På disse niveauer udvides kravene til udvalgte Practice Areas (se næste afsnit). Herunder har vi forsøgt at kondensere, hvad niveauerne i praksis går ud på. 

Level 4:Opbyggede historiske data for centrale områder, fx system test, fejl, estimater, analyseres nu ved hjælp af statistiske metoder, så afvigelser og fordeling forstås langt bedre og dermed kan indgå i en væsentlig forbedret forudsigelsesevne af eksempelvis leveringstidspunkt, omkostningsniveau, kvalitetsniveau for produkterne. Evnen sikrer desuden, at organisationen langt tidligere opdager problemer, der måtte være undervejs.

Level 5:På dette tidspunkt mestrer organisationen alle Practice Areas og benytter statistisk proceskontrol af de forretningskritiske processer. 

Sammenfattende kan det dog siges, at organisationens høje modenhed medfører væsentlig større konkurrenceevne og ikke mindst evnen til at indgå i væsentlig større kompleksitet - kundemæssigt, produktmæssigt, branchemæssigt.

Det leder til behovet for yderligere indsigt og ikke mindst omstillingsevne. Derfor udvides kravene til implementeringen af Causal Analysis and Resolution og Managing Performance & Measurement på en måde, som understøtter konstant forbedring og introduktion af nye metoder, nye teknologier og nye værktøjer - uden at øge risikoniveauet og momentum i organisationen.

Det er i høj grad den data-drevne performance, der sikrer at styringen bevares - niveauet kan sammenlignes med et Formel 1 team - alle processer er under kontrol, alle bilens væsentlige parametre er overvåget under løbet, som justeres efter forholdene, og kaldes i pit, når det er nødvendigt. Hele mandskabet i et F1 team er indforstået med dette og nyder tilværelsen i et high-performance team - og belønnes rigeligt derefter.

CMMI modellens struktur

CMMI er struktureret i 3 niveauer, som det fremgår i nedenstående tabel. 
Practice Areas med Blå forkortelse hører til modenhedsniveau 2 og med Grønt, til modenhedsniveau 3.

Practice Areas tabel.png

Der er fire Categories, som hver især indeholder et antal Capability Areas, som igen indeholder specifikke Practice Areas (svarende til fagdiscipliner).

Doing

Dette er den udførende kategori og består af tre capability areas, der primært stiller krav til de medarbejdere, der udfører udvikling, test og kvalitetssikring

  • Ensuring Quality
  • Engineering & Developing Products
  • Selecting & Managing Suppliers

Managing

Dette er den styrende kategori og består af følgende tre capability areas

  • Planning & Managing Work
  • Managing Business Resillience
  • Managing the Workforce

Det er med andre ord processer, der omfatter projektledelse og linjeledelsens understøttelse af dette.

Enabling

Supporting Implementation er det eneste Capability Area i kategorien, hvor den primære disciplin er konfigurationsstyring (CM).  Causal Analysis & Resolution (CAR) sikrer at vi lærer af vore fejl og undgår dem og Decision Analysis & Resolution (DAR) processen sikrer, at vi træffer beslutninger på et oplyst grundlag - fx ved at opstille et antal mulige løsninger på et teknologisk problem eller udvælgelsen af leverandører, og et antal parametre, vi ønsker at bedømme løsningsmulighederne på (fx økonomi, kvalitet, langsigtede mål, tidligere performance).

Improving

Improving består af følgende Capability Areas

  • Sustaining Habit & Persistence
  • Improving Performance

Improving kategorien sikrer i fællesskab, at de udviklede processer rent faktisk skaber værdi og løbende bliver justeret og tunet, så de passer til virksomhedens behov, konkurrencevilkår og ikke mindst strategi. Det rette procesejerskab (governance) med roller og ansvar tilknyttet hver forretningsproces sikrer at ledelsen er tæt på processen værdiskabelse og korrekte performance.

 

CMMI Practice Areas

Hvert Practice Area, der er niveauet med alle beskrivelserne, er beskrevet ved 

  1. Titel ("Practice Area Title")
  2. Overordnet formål ("Intent")
  3.  Overordnet værdi ("Value")
  4. Practice forkortelse
  5. Målsætning ("Statement")
  6. Værdiskabelse, når målsætning opnås ("Value") 
  7. En eller flere eksempler fra praksis ("Explanatory information")

De ialt 20 Practice Areas er fordelt på forskellige modenhedsniveau'er ("Maturity Level" - ML), jf nedenstående tabel.Practice Areas modenhedstabel.png

Således kan virksomheden begynde med et fokus på at få modenhedsniveau 2 (ML2) og få disse evner implementeret og skabe værdi, inden der bygges ovenpå med ML3 evnerne.

Det skal understreges, at implementering af hver Practice Area vil skabe værdi i sig selv. Den største værdi skabes dog, når samtlige PA'er implementeres for et modenhedsniveau, da de understøtter hinandens muligheder for succes.

Et eksempel på et Practice Area: Requirements Development and Management

1.     Practice Area Title
Requirements Development and Management
2.     Intent
Elicit requirements, ensure common understanding by stakeholders, and align requirements, plans, and work products.
3.     Value
Ensure that customers' needs and expectations are satisfied.
4.     Practice Summary
Level 1
      RDM 1.1                 Record requirements
Level 2
    RDM 2.1                 Elicit stakeholder needs, expectations, constraints, and interfaces or 
                                         connections.
   RDM 2.2                 Transform stakeholder needs, expectations, constraints, and interfaces
                                        or connections into prioritized customer requirements.
    RDM 2.3 -> 2-6       Etc.
Level 3
    RDM 3.1                 Develop and keep requirements updated for the solution and its 
                                        components.
    RDM 3.2 -> 3.4

Herefter forklares hvert enkelt punkt, fx RDM 1.1 ud fra Målsætning, Værdiskabelse og flere eksempler "Explanatory Information", fx hvordan RDM skal forstås i en agil kontekst.

 

Modenhed - hvordan opleves det i hverdagen på de forskellige niveauer?

I dette afsnit vil vi beskrive nogle typiske oplevelser fra hverdagen på modenhedsniveauerne 1, 2 og 3. Vi tager udgangspunkt i tre arketypiske aktører (persona): Projektchefen, projektlederen og udvikleren.

Modenhedsniveau 1 - "Get the job done"

ML1 - Projektchefen

ML1 - Projektchefen

Projektchefen har travlt, for der er flere projekter i gang end den egentlige kapacitet muliggør. Så derfor har chefen travlt med at “motivere” projekterne til at skabe resultater – også selvom det forekommer urealistisk eller optimistisk i bedste fald.

Projektchefen synes, at de informationer, der kommer fra projekterne, er upålidelige og bliver rapporteret på forskellige måder. Pris, tid og indhold synes altid at blive ringere end planlagt. Projektchefen føler derfor et stort behov for at involvere sig i projekterne ved at give mange gode råd og ved at hjælpe med at styre arbejdet (eng. micro management).

Der er rift om nøglemedarbejdere, som alle ved kan levere varen. Højprioritetsprojektet får typisk disse, og de resterende projekter må derfor klare sig med de tilgængelige personer. Det er svært at danne sig et overblik over, hvem der arbejder på hvad, for projektchefen har ikke en samlet og ajourført oversigt over ressourceanvendelse eller alle opgaver i relation til porteføljen af projekter.

ML1 - Projektlederen

ML1 - Projektlederen

Projektlederen er nøglepersonen i projektet og har typisk rigtig travlt, for projektlederen har jonglørens rolle – det er det muliges kunst, der er mantraet. Der kræves ofte en stor indsats for at holde projektet på ret kurs, og alt arbejdet falder i projektlederens kurv. Eftersom det er svært at delegere, så bliver projektlederen en ensom og tit overbebyrdet person. 

Projektlederen oplever en meget dynamisk hverdag; kravene ændrer sig, aftaler svigtes, personer forlader projektet med kort varsel (typisk som følge af kunderelaterede problemer), projektchef eller anden linjeledelse blander sig i projektet, og det er svært at få et reelt overblik over fremdriften. Planlægningshorisonten er kort – en dag eller uge ad gangen – for planerne må ændres løbende som følge af at rammer og forudsætninger flyder. Projektlederen bruger megen tid på at kæmpe sig til nye medarbejdere – og såfremt det lykkes – at beholde disse. Projektlederen må investere megen energi på at kommunikere status opadtil og bliver afkrævet forklaringer af diverse afvigelser eller problemer.

ML1 - Udviklerne

ML1 - Udviklerne

Udviklerne arbejder på hver sin måde i projekterne og i organisationen. Valg af metoder og værktøjer foregår tilfældigt og er typisk drevet af projektbehov og er derfor sjældent koordineret. Det giver ofte anledning til frustration, at brugen af og sammenhæng mellem værktøjer og metoder ikke hænger sammen på tværs af projekterne eller afdelingerne.

Men da fastlæggelse af standarder og metoder for arkitektur, design og implementering (eks. kodning) ingenlunde er trivielt, hverken fra et teknisk eller ledelsesmæssigt perspektiv, så kræves der tid og ressourcer til at foretage de rigtige valg, og begge dele er der stor knaphed af i en modenhedsniveau 1 organisation.

De dygtigste og mest erfarne synes, at det er godt, for hver person har sine egne isolerede opgaver, mens andre har svært ved at blive produktive. Når opgaven er færdig, så spørger udvikleren projektlederen, hvad næste opgave er. Men ofte kommer der ændringer i opgaverne eller nye opgaver pga. nye prioriteter. Udviklerne har lyst til at gøre tingene rigtig, men har hver sin idé om, hvad “rigtigt” er, ligesom der sjældent er tid til at gøre det “rigtige”. Den erfarne medarbejder bygger måske et “travlhedsværn” op, dvs. indbygger tidsbuffere i alle opgaver for at kunne håndtere den store usikkerhed.

Modenhedsniveau 2 - Projektorganisationen er født

ML2 - Projektchefen

ML2 - Projektchefen

Projektchefen er ikke længere så involveret i det konkrete arbejde i projekterne, da planerne er mere realistisk funderede nu, og der er indsigt i projekternes status. Identificerede aktiviteter gennemføres som planlagt og projektchefen oplever nu, at projektledere og medarbejdere forventer konsekvensanalyser inden nye aktiviteter accepteres.

Øget bevidsthed om organisationens kapacitet medfører, at en langt større del af de iværksatte aktiviteter gennemføres, men der igangsættes færre end da organisationen var på modenhedsniveau 1.

Projektchefen modtager troværdige og ikke mindst korte og mere koncise fremdriftsrapporteringer i samme form fra projekterne med fokus på projektmål og udviser derfor større tillid til projektledelsen.

ML2 - Projektlederen

ML2 - Projektlederen

Projektlederen har nu en meget længere planlægningshorisont, da planerne er begyndt at være realistiske og faseopdelte. Realismen kommer dels af, at projektlederen arbejder sammen med udviklerne omkring beskrivelse og estimering af opgaverne og dels af, at disse estimater respekteres af ledelsen, da de nu er kvantificerede. Projektet har også god gavn af, at processerne er nedskrevne bl.a. fordi, der er mere klarhed om arbejdsfordelingen og projektlederne derfor nu kan uddelegere nogle af sine arbejdsopgaver.

Projektgruppen ved nu, hvad kravene er, fordi de er dokumenterede, aftalte og ændres på en systematisk måde, der bygger på konsekvensberegninger. Projektlederen har øje for fremdriften i produktet, som findes i og kontrolleres gennem konfigurationsstyringssystemet. Dette giver blandt andet information om arbejdsprodukternes færdiggørelsesgrad, og ved faseskift gennemgås kvaliteten af de arbejdsprodukter, der forventes færdige. Gennemsigtigheden har ledt til en klarere forståelse og større grad af tillid mellem projektleder og udviklere. Der er ikke længere brug for “brandslukning” i projekterne.

ML2 - Udviklerne

ML2 - Udviklerne

Udviklerne får mere arbejdsro, da ressourceallokeringen er tilstrækkelig og baseret på udviklernes estimater. Derfor kan flere opgaver gennemføres efter projektplanen, som alle kender, da den ofte kommunikeres (eks. er skrevet ud i stort format og hængt op).

Dette har medført at udviklerne tager egne estimater og deadlines meget seriøst og stræber efter at levere som planlagt. Udviklerne er aktivt involveret i projektets styring og med til review af planer. Udviklerne er mindre stressede, da kravene til dem er mere klare, og da meget mere arbejde kan ske indenfor normal arbejdstid. Der er desuden langt større overskud til at få en positiv projektkultur, der bedre kan håndtere eventuelle problemer, inden de vokser sig for store.

Med større krav om forudsigelighed og estimeringssikkerhed engageres udviklerne i at udvælge udviklingsmetoder og -værktøjer, og der bliver plads til at eksperimentere med disse – både i projekt- og afdelingsregi, og allerede i en modenhedsniveau 2 organisation vil der være forsigtige tegn på at arbejde hen mod fælles udviklingsrutiner.

Modenhedsniveau 3 - Fælleskab og fagligt fokus

ML3 - Projektchefen

ML3 - Projektchefen

Projektchefen glæder sig over de fælles processer (f.eks. samlet i en projektmodel), som gør opstartstiden for projekter kortere, idet alle nu ved, hvad der skal laves hvornår, hvorfor og hvor­dan. Desuden er ressourceallokering blevet nemmere, da afhængigheden af bestemte medarbejdere er langt mindre.

Projektchefen har også lettere ved at dokumentere, manglende kapacitet i organisationen til at igangsætte et projekt – alternativt at være præcis omkring de nødvendige ressourcer. Det er blevet lettere at håndtere pres fra den øvrige organisation på en konstruktiv måde.

Rapporteringen fra projekter er blevet mere homogen, og konsekvent dataopsamling øger pålideligheden af fremdriftsstatus. Det er blevet nemmere for projektchefen at arbejde med projekterne som en portefølje fremfor individuelle projekter, og sandsynligvis samles projekter nu i programmer, så der kan gennemføres systematisk roadmap- og porteføljestyring.

Projektchefen har fået nye nøglepersoner. På modenhedsniveau 1 var de foretrukne medarbejdere dem, som kunne løse fejl og problemer (også dem, som de selv var skyld i) – nu værdsættes de medarbejdere, som undgår at skabe fejl og identificerer problemer/risici i tide.

ML3 - Projektlederen

ML3 - Projektlederen

Projektlederen planlægger og styrer projekterne ved hjælp af en stor værktøjskasse med velafprøvede processer, metoder og skabeloner baseret på best practice og tilgængelige erfaringer i organisationen. Projektlederen har typisk selv bidraget til procesforbedringer, fordi det nu er kulturen i organisationen at styrke fagligheden. 

Med fælles processer er erfaringsdata til brug for estimering blevet bedre. Tidligere kunne projekter bruge egne historiske data, men først når projektet havde været i gang et stykke tid. Nu er der, allerede fra start, pålidelige data fra lignende projekter eller opgaver til rådighed. Organisationen vil desuden evne at sammensætte projekter i større programmer for at sikre bedre integration og overblik. Herigennem kan der arbejdes med integrerede produktteams, som omfatter forskellige tekniske discipliner (eks. mekanik, elektronik, og software) såvel som eventuel produktion, installation, service, markedsføring og sikkerhedsgodkendelser. 

Med mere stabilitet i bemanding, adgang til kompetence, færre uforudsigeligheder samt en respekteret projektledelsesdisciplin, har projektlederen for alvor skiftet fokus fra at håndtere interne kriser til at se fremad og udad. Fokus bliver at styre interessenter, skabe stabilitet og håndtere risici i samråd med ledelsen eller styregruppe.

ML3 - Udviklerne

ML3 - Udviklerne

Udviklerne glæder sig over den faglighed, der er opnået omkring , at de tekniske discipliner nu har fået fokus, og at der rent faktisk lyttes til tekniske input f.eks. i valg af løsningsmodel, valg af teknologi, tredjeparts produkter eller udviklingsmetoder. Opnåede erfaringer deles mellem projekter og afdelinger og den øgede samstemmighed omkring metoder fremmer desuden evnen til at vælge og arbejde med de rette udviklingsværktøjer på tværs af organisationen. Det leder til en øget procesorientering og professionalisering blandt udviklerne.

Produktiviteten ses forbedret gennem design- og kode­standarder, modulbiblioteker samt evt. automatisering af kodning, integration- og testprocesser. Udviklerne oplever derved, at der er tid og ressourcer til at tænke kreativt og finde på nye innovative løsninger.

Organisationen tilbyder uddannelse i processerne og de understøttende fagligheder, og udviklerne lader sig uddanne til deres roller inden de begynder at bestride dem. Nye medarbejdere vil opleve en stærk organisationskultur og vil ikke finde det nødvendigt at indføre egne arbejdsgange, men derimod at bidrage til organisationens måde at arbejde på. Kompetenceudvikling ses ikke mere som et individuelt anliggende, men som en organisatorisk indsats for organisationens skyld — for processernes skyld, så resultater opnås efter hensigten.

Resumé og nyttige links

Vi håber, at vi med denne artikel har bidraget til din forståelse af, hvordan CMMI rammeværket hænger sammen, og at vi har givet dig indsigt ,i hvordan arbejdet med CMMI kan øge performance og værdiskabelse i din organisation. Gennem at fokusere på at få nødvendige ledelses- såvel som udviklingsmæssige fagdiscipliner på plads i en værdiskabende rækkefølge, kan du opnå væsentlige bedre resultater i din organisation. Det er vigtigt at understrege, at det ikke behøver at kræve en stor papirtiger...

Vi har i Proces360 personligt implementeret og oplevet denne forbedring - i forskellige højkonkurrence-brancher og over længere tid.

Ønsker du en uddybning af modellen, stiller vi også gerne til rådighed for et uforpligtende møde.

Læs evt. mere om CMMI her (CMMI Institute):

CMMI Transition til Version 2 (Del 3)
CMMI og Agile

Arkiv