Business Analytics Audit

In de laatste project fase of na het afsluiten van een Performance Management (PM) of Business Intelligence (BI) project is het essentieel om alle lessons learned vanuit de verschillende project fases te verzamelen en deze te transformeren in een set van aanbevelingen naar toekomstige projecten toe. Naast deze typische finale project activiteiten vanuit een evaluatie perspectief, is het ook aan te raden om een, zij het op periodische of ad-hoc basis, PM of BI project review of kortweg project audit uit te voeren.

Een project audit voorziet een opportuniteit om bepaalde issues, bezorgdheden en uitdagingen aan de oppervlakte te brengen die opgedoken zijn gedurende de gehele project cyclus. De hoofddoelstelling van het uitvoeren van een project review is het identificeren van de mogelijke fouten die gemaakt werden gedurende het project of om te identificeren waar mogelijk fouten kunnen optreden indien bepaalde veranderingen met betrekking tot de huidige processen niet worden doorgevoerd. Tegelijkertijd laat een audit toe om de activiteiten met een hoge graad van tevredenheid te identificeren en die als dusdanig hebben bijgedragen tot het succes van het project, zodanig dat men in staat is om deze activiteiten te herhalen in toekomstige projecten.

Een project audit zal – ondere andere – alle onderstaande punten in overweging nemen bij het interviewen van de hoofdspelers tijdens het project en bij het bekijken van het belangrijkste materiaal dat werd gecreëerd gedurende het project.

Wanneer we een project opstarten is het uitermate belangrijk dat een methodologie wordt gehanteerd die geschikt is voor de uit te voeren job. Deze methodologie dient aangepast te worden aan de specifieke zaken die van belang kunnen zijn binnen een PM of BI project. Binnen PM of BI projecten is het verder van vitaal belang dat, om het momentum te behouden en om het vertrouwen van de business te garanderen, de algemene tijdslijn van het project gerespecteerd blijft en in lijn loopt met het originele plan. Om dit te verwezenlijken wordt een project typisch opgesplitst in verschillende project iteraties zodanig dat de business noden binnen een redelijke termijn beantwoord kunnen worden en dat er zo spoedig mogelijk een aanvang kan genomen worden met het leveren van toegevoegde waarde en uiteindelijk een bepaalde ROI. Binnen deze methodologie dient duidelijk beschreven te worden wat, wanneer en door wie wordt uitgevoerd binnen het project.

Dit kan verwezenlijkt worden door:

  • Het opsplitsen van het project in fases die makkelijk kunnen gemanaged, toegewezen en getraceerd worden in functie van hun voortgang
  • Het duidelijk positioneren van de juiste deliverables aan elke fase en de daarbijhorende activiteiten die geïntegreerd voorgesteld worden door middel van templates in functie van consistentie en eenvoud. Bijvoorbeeld:
    • Wanneer dient een bron analyse te gebeuren?
    • Wat is de strengheid en de hoeveelheid aan data kwaliteitsproblemen die kan verwacht worden?
    • Dient ‘iets’ te gebeuren binnen de design fase, of eerder in de build fase of mogelijk zelfs op ad-hoc basis?
    • Hoe dienen we dit alles te managen vanuit het perspectief van rollen en verantwoordelijkheden?
    • Hoe en waar dienen de belangrijkste design beslissingen gemanaged te worden?
    • ...
  • Het toevoegen van quality assurance filters voor elke fase en/of deliverable in de vorm van key criteria die mee bepalen of een volgende fase al dan niet gestart kan worden
    • Bijvoorbeeld: aan welke key criteria dient voldaan te worden bij een bron-doel design? Wat dient er te gebeuren met de criteria die niet gehaald worden?
  • Het toevoegen van ownership voor elke fase en/of deliverable en de daarbij horende quality assurance filters.

Binnen een PM of BI methodologie, dient voldoende tijd voorzien te worden voor het verzamelen en bewaken van alle requirements. Deze requirements zullen de basis vormen voor de PM of BI oplossing die gebouwd zal worden. Een onderscheid kan gemaakt worden tussen functionele requirements, die toegevoegde waarde bieden aan de business; bijvoorbeeld: report ‘xyz’ en niet-functionele requirements, die de karakteristieken, eigenschappen en kwaliteiten definiëren van de te bouwen oplossing; bijvoorbeeld: ’s nachts kan er maximaal 3 uur benut worden voor het geheel van alle ETL processen. In dit voorbeeld, kan deze niet-functionele requirement zeer cruciaal worden binnen de build en technische test fases. Hier kan het bijvoorbeeld aan te raden zijn, gegeven het kritische tijdsgegeven, om de build en de technische test fases op te splitsen in kleinere delen die elk apart kunnen gemanaged worden met als einddoel voor ogen om te komen tot een zo klein mogelijk totaal-hoeveelheid aan tijd te spenderen aan het geheel van ETL processen.

In functie van de requirements, is het aangewezen om deze SMART te definiëren ( (S = Specific, M = Measurable, A = Attainable, R = Realistic, T = Timely), waarbij idealiter zo veel mogelijk het interpreteren van requirements wordt vermeden. Naast de definitie van de requirements zelf dient de nodige aandacht besteed te worden aan een duidelijke eigenaar, versionering (zijn er requirements die geschrapt worden, maar later toch opnieuw opduiken? Hoe wordt change gemanaged? Hoe worden change requests verwerkt en getraceerd?) en een daarbijhorende prioritisering.

In functie van project management, dienen alle betrokken personen en hun daarbij horende rollen duidelijk gedefinieerd te worden.

  • Hoe en wanneer zal de formele en informele communicatie tussen alle actoren gebeuren?
  • Wordt knowledge transfer tussen de verschillende teams en individuen correct ingevuld?
  • Zijn alle van toepassing zijnde deliverables goedgekeurd op het juiste moment en door de juiste mensen?
  • Wordt de informatie gedistribueerd aan de juiste personen?
  • Wordt versie controle en versie historiek correct gehanteerd voor zowel documentatie als eindproducten?
  • Zijn de mensen met de juiste skills toegewezen aan de activiteiten?
  • Welke veronderstellingen, constraints en uitsluitingen werden gedefinieerd en werden deze gerespecteerd? Worden project issues, data kwaliteits-issues en risico’s op de correct manier gemanaged?

In functie van project planning,

  • Werd er voldoende tijd voorzien voor alle geplande activiteiten?
  • Wat met afhankelijkheden tussen sub-fases of bepaalde activiteiten?
  • Werden sommige taken weggelaten en waarom? Hebben alle taken een geplande start en eind datum, een eigenaar en uitvoerder(s) toegewezen?
  • Is er een boeking systeem voor actuele prestaties beschikbaar? Hebben alle personen geboekt op de juiste fases en/of activiteiten?
  • Wat zijn de uitzonderingen die veel minder of veel meer tijd gekost hebben en wat zijn daarvoor de redenen?
  • Welke tools worden gebruikt voor project management en document management?

Het testen van een PM of BI oplossing is gericht naar het vaststellen of een bepaalde oplossing aan de vereiste requirements voldoet door het demonstreren dat de oplossing klaar is voor gebruik en het detecteren van alle defecten. Het is belangrijk om zo vroeg mogelijk in het project reeds aan het testen te denken. Naast de eigenlijke uitvoering van de testen en het daarbijhorende bug fixing, dient er een grondige voorbereiding te gebeuren om er voor te zorgen dat het testen zo efficiënt en grondig mogelijk kan gebeuren.

Hieronder worden enkele voorbereidingstaken opgesomd:

  • Het definiëren van de algemene scope (wat wordt er getest en in welke mate van detail) en de test aanpak ervan.
  • Het definiëren van rollen en verantwoordelijken met betrekking tot de testen.
  • Het definiëren van de test levels (unit testen, integratie testen, regressie testen, performantie test (van bakc-end & front-end perspectief), gebruikers acceptatie testen, transitie testen).
  • De creatie van test scenario’s (test scripts).
  • Het definiëren van acceptatie criteria die gebruikt kunnen worden bij het bepalen of een test succesvol was of niet.
  • Het definiëren van test prioriteiten wanneer de tijd voor het testen gereduceerd wordt omwille van bepaalde redenen.
  • Het definiëren van de test omgevingen; welk test level dient op welke omgeving toegepast te worden.
  • Het definiëren van de test planning.
  • Het vastleggen van een test tool set voor het capteren van de test scenario’s en de daarbijhorende test resultaten, defecten en opvolging van deze laatste. Definitie van issues types & issues statussen.
  • Het definiëren van een algemene opvolgingsmethode en/of –tool.

Alle bovenstaande punten zijn slechts voorbeelden van zaken die geverifieerd dienen te worden tijdens het uitvoeren van een project audit, die tracht een antwoord te geven op de vraag of het project correct gemanaged werd of niet.

Contacteer ons voor meer informatie rond deze Performance Management & Business Intelligence Audit.