Nieuws

Projectaanpak fase 4: Technische- en functionele analyse

Om van elk project plan een digitaal succes te maken werkte PHPro haar eigen werkwijze uit: onze PHPro Roadmap. Vandaag lichten we graag fase 4 toe: De technische- en functionele analyse. 

Discovery

De eerste reeks workshops maken deel uit van wat we de "discovery" of ontdekkingsfase noemen. Na de discovery wordt er een steerco gepland om de deliverables van deze fase te bespreken. Deze deliverables zijn:

1. High-level context diagram

Elk project vereist een globaal overzicht van de componenten die in je project aan bod komen, met daarbij ook een goed beeld op de integraties. Dit diagram is ook de houvast voor onze klanten en de projectmanager om een overzicht te hebben van welke informatie wordt uitgewisseld, in welke richting informatie wordt uitgewisseld, hoe vaak informatie wordt uitgewisseld (frequentie & volume) en welke functionaliteit wordt beoogd. Dankzij dit high-level context diagram is ook de scope en de complexiteit van het project veel duidelijker.

Hieronder enkele voorbeelden van een high-level context diagram:

contect diagram 1
context diagram 2

2. Work breakdown structure

De WBS biedt een kader voor het project. Hier wordt het werk opgedeeld in hiërarchisch definieerbare stappen waarbij concrete hoofdactiviteiten worden opgedeeld in logische deelactiviteiten. Op deze manier kan het werk worden onderverdeeld in ontwikkeling, planning en kosten. Voor de WSB-workshop wordt de informatie uit het pre-sales traject als basis genomen. Tijdens de workshop wordt dit beoordeeld en indien nodig aangepast.

De WBS helpt ons ook bij het monitoren van de scope en het vormgeven van het project. De WBS zorgt er later ook voor dat het voor iedereen binnen het project duidelijk is wat er al gedaan is en welke deelactiviteiten nog moeten volgen om het project tot een goed einde te brengen.

Hieronder een voorbeeld van een WBS:

 

 

work breakdown structure

3. Functional Requirements Document

Het is heel belangrijk om een beter beeld te krijgen van wat er nodig is. We houden steeds een goed overzicht bij van alle gewenste features, en of de impact realistisch is binnen het budget. Op basis van deze informatie krijgen we een document dat een duidelijk beeld geeft van de features die moeten worden geïmplementeerd in de software-oplossing.

 

Het document bevat de nodige informatie op het gebied van

  • Datamanipulatie
  • Gegevensverwerking
  • Andere integraties die digitaal zullen worden uitgevoerd.
 
Het document kan ook gerelateerde informatie bevatten zoals:
  • Prestatie-eisen
  • Beveiligingsdetails
  • Beperkingen waarbinnen het platform moet functioneren.
 
Naast functionele eisen kunnen ook niet-functionele eisen in dit document worden opgenomen. Het gaat hierbij om UX-, prestatie- en onderhoudseisen.

In een ideale wereld worden user stories al in de discovery fase aangemaakt en verwerkt in het Functional Requirements Document. Dit geeft de stakeholders een gedetailleerde beschrijving van de taken die een gebruiker met de softwareoplossing kan doen en zorgt voor meer duidelijkheid en richting voor de stakeholder(s). Doorgaans worden de users stories (verder) uitgewerkt na de discovery fase.

Soms kunnen ook schetsen en wireframes worden opgenomen in het document. Deze kunnen helpen om UI-ontwerpeisen te schetsen tijdens analyse & ontwerp, navigatielogica te specificeren en te bepalen hoe schermen aan elkaar worden gekoppeld.

4. Budgetinschatting

De budgetinschatting wordt (opnieuw) gemaakt op basis van de gegevens in het Functional Requirements Document. Het budgetvoorstel is opgesplitst in epics: dit zijn afzonderlijke onderdelen die cruciaal zijn voor zowel de stakeholders als het team dat verantwoordelijk is voor het design en de ontwikkeling. Een globaal kostenvoorstel geeft de stakeholders een idee van hoeveel investering er nodig is gedurende de tijd die nodig is om het platform te bouwen, te testen en te installeren. Dankzij de discovery fase is het mogelijk om een budgetvoorstel te leveren met nauwkeurigere schattingen.

5. High-level Projectplan

Het high-level projectplan brengt de reikwijdte van het project in kaart met het budget en de tijdslijn. Het is meestal managementgericht: projectmanagers en stakeholders zorgen voor de informatie binnen het high-level projectplan. In dit plan wordt vermeld wie de stakeholders van het project zijn, wat het doel is van het project, wat is de status van de budgetten, wanneer het project klaar zou zijn (roadmap), wat zijn de risico's, ....

Samen zorgen deze documenten ervoor dat 80-90% van de scope van het traject vastligt, met andere woorden, het grote geheel is duidelijk(er)!

Functionele analyse

Terwijl we een goed beeld opbouwen van hoe onze applicatie eruit zal zien en vooral wat de vereisten zijn, kijken we hoe dit geïmplementeerd kan worden en waar de technische moeilijkheden liggen. In de technische- en functionele analyse (die doorgaans parallel loopt met de wireframing en het design) worden de gewenste features in kaart gebracht, diepgaand geanalyseerd en afgetoetst met de huidige setup, integraties, tools, plugins en API’s. Op deze manier wordt in overleg met de klant en op basis van onze functionele en technische kennis van het platform, in combinatie met budget en planning, de scope van het project vastgelegd.

Op basis van deze analyse maken we een meer concrete budgetinschatting en kan de ontwikkeling van start gaan.

De verschillende workshops worden tijdens de kick-off meeting vastgelegd, en afhankelijk van de personen die per topic aanwezig moeten zijn, wordt de agenda bepaald. In grote lijnen worden volgens topics doorgaans besproken, uiteraard sterk afhankelijk van de business case:

  1. Architectuur, integraties & basis opzet
    - High level architectuur
    - Magento opzet
    - Integraties
    - Informatie architectuur
    - Product types
     
  2. Basis pagina's
    - Header, footer & Navigatiemenu
    - Homepage
    - Product model
    - Categorie pagina
    - Product detail pagina - visueel
    - Shopping cart
    - Checkout
    - Search & search results
    - Blog
    - Store locator
    - My account
     
  3. B2B
    - Company structure
    - Shared catalog
    - Pricing
    - Quotes
     
  4. Product details
    - Master data
    - Stock
    - Prijzen
    - Taksen
     
  5. Checkout processen
    - Shipment
    - Payment
    - Order flow
    - Facturatie
    - Retour & RMA
     
  6. Search, CMS
    - Search configuratie voor advanced search
    - CMS
       - Basis / Advanced CMS features 
       - FAQ, Over Ons, ...
     
  7. SEO, Legal & Rapportering
    - Technical SEO & Keyword research
    - Rapportering, tracking & dashboarding
    - Legal: GDPR, cookie consent, privacy policy,...
     
  8. Andere
    - Performance
    - Gifts
    - ...

Wat mag je verwachten?

Het eindresultaat van deze fase is een document met een exacte omschrijving van het te ontwikkelen platform.
De uitwerking van dit document gebeurt in Confluence, en kan dus ten allen tijde online gevolgd en geraadpleegd worden.

Na goedkeuring van dit analysedocument kan er een nieuwe inschatting worden opgemaakt voor de volgende fases.

Maak van jouw projectplan een digitaal succes!

Heb je een digitaal project waarvan je een succes wil maken? Geloof jij ook in een bewezen projectaanpak als stevige basis voor een geslaagd project? Neem dan zeker contact met ons op!