Ledernes Hovedorganisations valg af platform
Ledernes Hovedorganisation har i flere år anvendt Sitecore som CMS platform og det var oplagt, at fortsætte på platformen da Sitecore annoncerede version 9. Men organisationen var kommet i tvivl om hvorvidt Sitecore fortsat var det rigtige valg for dem.
Den eksisterende Sitecore løsning har over årene vokset sig stor og var blevet uoverskuelig. Men det mest problematiske, bestod i, at platformen ikke kunne efterleve organisationens forretningsmål. Mål om, at yde bedre service til medlemmer ved hjælp af personalisering mv. var ikke muligt på deres nuværende platform.
Så inden en afgørende beslutning blev truffet, var det vigtigt at foretage en grundig analyse. Udfordringen bestod i at træffe det rigtige valg ud fra et forretningsmæssigt perspektiv.
Sitecore puls – analyseproces
Det var derfor nu, en analyse skulle foretages. Skulle Ledernes Hovedorganisation fortsætte med Sitecore som platform? Og i så fald, hvad ville det kræve?
Pintle blev involveret i analyseprocessen. Opgaven bestod i at kortlægge, hvilke tiltag der var nødvendige at implementere, for at Ledernes Hovedorganisation kunne opnå deres forretningsmål. Et omfattende analysedokument blev udarbejdet og det beskrev i detaljer hvordan en fremtidig løsning burde implementeres for, at understøtte organisationens mål og målsætninger.
Dokumentet bestod også af en omfattende kodeanalyse gennemgang, som havde til formål, at få overblik over den eksisterende løsning.
Resultatet af analysen var en lang række indsatsområder, som kortlagde en komplet rekonstruktion af Ledernes sites. Herunder bl.a. vigtigheden ved, at implementere Helix principper og derigennem opnå fleksibilitet via en modulopbygget arkitektur.
Ledernes Hovedorganisation valgte Sitecore 9
På baggrund af analyse dokumentet og en række møder, faldt valget til sidst på, at Sitecore fortsat var den rigtige platform til organisationen. Valget blev truffet ud fra en forretningsmæssig vurdering om, at Sitecore som platform, fortsat er den stærkeste platform til, at favne de målsætninger organisationen har. Organisationen har nogle helt konkrete målsætninger, som består i, en tættere kommunikation til deres medlemmer. Og med det i mente, er Sitecore den bedste platform til, at føre disse målsætninger ud i livet.
Hele baggrunden for vores opgradering var, at vi ville muliggøre personalisering. Vi er i processen med at integrere et par af vores datakilder til Sitecore, og så glæder vi os til opbygningen af profiler, regler og små flows, så vi kan få det testet af. Derudover har vi fået mulighed for at split-teste, hvilket vi kun har testet af i mindre omfang indtil videre.
Kelvin Ellenton Jensen, Senior Content Manager
Læs mere om vores puls service her.
Metode og projektteam
Analyse dokumentet beskrev hvordan en rekonstruktionsproces burde implementeres. Analyse dokumentet blev derfor udgangspunkt for selve processen. Et projekt af denne størrelse med så mange ubekendte faktorer, kræver en stram styret proces for at lykkedes.
Og da Lederne samtidig havde nogle helt konkrete krav, hvis projektet skulle blive en realitet, var det vigtigt at vælge den rigtige proces. Kravene til projektet så således ud:
- Kalendertid. Projektet måtte ikke tage for lang tid at gennemføre. Der var ikke “råd” til, at stå stille på det forretningsmæssige i længere tid. Med andre ord, projektet skulle løses inden for 5-6 måneder.
- Økonomi. Projektet skulle løses inden for budget.
- Kvalitet. Det var afgørende, at projektet skulle løse den konkrete problemstilling. Så Lederne fremadrettet kan opfylde deres forretningsmæssige målsætninger.
Agil tilgang – SCRUM
En stor og uoverskuelig løsning, hvor der eksisterer mange ukendte parametre, kræver en fleksibel proces. Derfor faldt valget naturligt på den agile metode. Der var brug for en metodik, hvor der løbende kunne afdækkes problemstillinger, samtidig med der var fremdrift i udviklingen.
SCRUM modellen
SCRUM kan være en ret tidskrævende proces at implementere. Hvis ikke alle projektdeltagere i projektteamet er bekendt med processen, kan det i værste fald forhale og forsinke processen yderligere. Derfor var det vigtigt, at balancere modellen i forhold til projektet.
Vi valgte tidligt, at inkludere de metoder og værktøjer fra SCRUM, som gav mening og værdi for projektet. Dermed valgte vi bevidst, at skære områder fra, som vi mente blot ville tage mere tid fra projektet uden at tilføre tilsvarende værdi.
Man kan hurtigt bruge rigtigt mange ressourcer hvis man skal imødekomme alle møder, planlægning og re-planlægning sessioner som SCRUM foreskriver. Så det var vigtigt, at skære ind til benet og sikre, at økonomien og tiden ikke blev opslugt af mødeaktiviteter. Men samtidig var det vigtigt, at balancere således, at der ikke gik noget information tabt.
Det var nyt for os – særligt i forretningen – at være så aktiv en del af udviklingen som vi var her, og det gav selvfølgelig en lidt stejl læringskurve i starten. Til gengæld føler jeg også, at vi er meget bedre klædt på til den løbende drift og udvikling af platformen, og det gav også et bedre produkt. Projektet var kæmpe stort og involverede et væld af features, integrationer og en hel selvbetjeningsløsning, men den agile tilgang hjalp til at nedbryde og styre det, hvilket også betød, at vi kom i mål til tiden, til budgettet og i den forventede kvalitet, -konstaterer Kelvin.
Ledernes Hovedorganisation – Balanceret SCRUM model
Den balancerede model bestod af ét SCRUM team. Dette inkluderede én Product owner (PO), én SCRUM-master og dedikerede projektdeltagere, bestående af udviklere, testere og fagfolk.
Da projektet bestod af mange ubekendte faktorer for hele teamet, var det essentielt, at nedbryde projektet i en overordnet backlog. Velvidende, at denne backlog ville ændre sig undervejs, blev projektet opdelt i sprints af 3 ugers varighed.
Hver sprint inkluderede én sprint planlægning, én refinement (grooming) og én sprint demo. I hele forløbet blev der af projektteamet udarbejdet user-stories for foruddefinerede epics som projektet bestod af. User-stories viste sig, at være et meget vigtigt redskab for, at styre processen i forhold til forventningsafstemning og senere test.
Vores løsning var stor og kompleks, og hverken vi eller Pintle havde det fulde overblik, da vi gik i gang. Her hjalp både metodikken, men også det leverede opgaveoverblik fra Pintle i meget høj grad. Det betød, at vi hele tiden kunne kigge fremad, mens der blev arbejdet løs, så vi kunne prioritere ting ind eller ud af vores backlog. Der var rigeligt med forhindringer og læringer undervejs i projektet, men på trods af det, så lancerede vi projektet til tiden. Faktisk lidt før tid, pointerer Kelvin.