Overzicht van profielen, projectrollen en verantwoordelijkheden binnen development, deployment en beheer van Power Platform oplossingen.
Deze pagina beschrijft hoe rollen en verantwoordelijkheden binnen Power Platform projecten worden verdeeld. Omdat Power Platform zowel low-code als pro-code ontwikkeling ondersteunt, werken vaak meerdere typen profielen samen: business, consultants, developers, testers, DevOps en beheer.
In Power Platform projecten kan één persoon meerdere verantwoordelijkheden hebben. Een functioneel consultant kan bijvoorbeeld zowel requirements uitwerken als configuratie uitvoeren. Een technisch consultant kan zowel developer als DevOps-verantwoordelijke zijn. Daarom is het belangrijk om onderscheid te maken tussen:
Wie iemand is of welke expertise iemand meebrengt.
Welke verantwoordelijkheid iemand in het project vervult.
Wie Responsible, Accountable, Consulted of Informed is per activiteit.
Onderstaande profielen komen vaak voor binnen Power Platform projecten. Deze profielen zijn geen RACI-kolommen, maar helpen om te begrijpen wie de projectrollen kan invullen.
Richt zich op businessdoelen, processen, requirements en waardecreatie. Helpt om de vraag van de organisatie scherp te krijgen en te vertalen naar concrete oplossingsrichting.
Vertaalt requirements naar functionele inrichting binnen Power Platform, zoals apps, schermen, datamodel, business rules, flows en gebruikersprocessen.
Richt zich op complexere technische onderdelen zoals JavaScript, plugins, Custom APIs, integraties, security-inrichting, performance en technische implementatiekeuzes.
Een businessgebruiker die zelf oplossingen bouwt met low-code tools zoals Power Apps en Power Automate. Dit kan veel snelheid geven, maar vraagt om duidelijke governance.
Is verantwoordelijk voor beheer na oplevering, zoals monitoring, incidentafhandeling, wijzigingen, toegangsbeheer en continuïteit van de oplossing.
Richt zich op ALM, pipelines, deployments, solution transport, versiebeheer en releaseprocessen tussen omgevingen.
De RACI-matrix gebruikt projectrollen. Deze rollen beschrijven niet per se een functietitel, maar een verantwoordelijkheid binnen het project. Afhankelijk van projectgrootte kan één persoon meerdere rollen vervullen.
| Afkorting | Projectrol | Beschrijving | Typisch ingevuld door |
|---|---|---|---|
| BO | Business Owner | Eindverantwoordelijk voor businesswaarde, scope en acceptatie. | Proceseigenaar, product owner of opdrachtgever |
| PM | Projectmanager / Delivery Lead | Verantwoordelijk voor planning, voortgang, afstemming, risico’s en coördinatie. | Projectmanager, delivery lead of lead consultant |
| SA | Solution Architect | Bewaakt architectuur, solution design, governance en technische richting. | Solution architect, lead consultant of senior technisch consultant |
| DEV | Developer / Consultant | Realiseert functionaliteit via configuratie, low-code en waar nodig pro-code. | Functioneel consultant, technisch consultant of citizen developer |
| QA | Tester / Quality Assurance | Valideert kwaliteit, testscenario’s, acceptatiecriteria en release readiness. | Tester, functioneel consultant, key user of QA-specialist |
| DO | DevOps Engineer | Beheert ALM, pipelines, deployments, releaseproces en versiebeheer. | DevOps engineer, technisch consultant of release verantwoordelijke |
| OPS | Operations / Beheer | Beheert de oplossing in productie, inclusief monitoring, incidenten en wijzigingen. | Functioneel beheerder, technisch beheerder of supportteam |
RACI maakt verantwoordelijkheden expliciet. Dit voorkomt dat activiteiten tussen wal en schip vallen, of dat meerdere personen denken dat iemand anders verantwoordelijk is.
| R | Responsible – Voert het werk uit. |
| A | Accountable – Is eindverantwoordelijk en neemt of accordeert de beslissing. |
| C | Consulted – Wordt vooraf geraadpleegd en levert input of expertise. |
| I | Informed – Wordt geïnformeerd over voortgang, besluit of resultaat. |
In deze fase worden scope, doel, stakeholders en backlog vastgesteld. De nadruk ligt op businesswaarde, haalbaarheid en duidelijke startvoorwaarden.
| Activiteit | BO | PM | SA | DEV | QA | DO | OPS |
|---|---|---|---|---|---|---|---|
| Scope bepalen | A | R | C | I | I | I | I |
| Stakeholders bepalen | A | R | C | I | I | I | I |
| Backlog opstellen | A | R | C | C | I | I | I |
| Definition of Ready bepalen | A | R | C | C | C | I | I |
In deze fase worden architectuur, datamodel, solution structuur en integraties bepaald. Hierbij ligt de nadruk op schaalbaarheid, beheerbaarheid en alignment met ALM+.
| Activiteit | BO | PM | SA | DEV | QA | DO | OPS |
|---|---|---|---|---|---|---|---|
| Architectuur bepalen | I | C | A | C | I | C | I |
| Datamodel ontwerpen | C | I | A | R | C | I | I |
| Solution structuur bepalen | I | C | A | R | I | C | I |
| Integraties identificeren | C | I | A | R | I | C | I |
In deze fase wordt de oplossing gebouwd. Dit kan bestaan uit configuratie, apps, flows, datamodel-uitbreidingen, scripts, plugins of integraties.
| Activiteit | BO | PM | SA | DEV | QA | DO | OPS |
|---|---|---|---|---|---|---|---|
| Configuratie (apps, forms, views) | I | I | C | R | C | I | I |
| Cloud flows / automatisering | I | I | C | R | C | I | I |
| Custom code (JavaScript, plugins, APIs) | I | I | C | R | C | I | I |
| Code review / solution review | I | I | A | R | C | C | I |
In deze fase wordt gecontroleerd of de oplossing voldoet aan requirements, acceptatiecriteria en kwaliteitsafspraken.
| Activiteit | BO | PM | SA | DEV | QA | DO | OPS |
|---|---|---|---|---|---|---|---|
| Testscenario’s opstellen | C | I | C | C | R | I | I |
| Functioneel testen | C | I | I | C | R | I | I |
| UAT / acceptatie | A | R | C | C | R | I | I |
| Release readiness beoordelen | A | R | C | C | C | C | I |
In deze fase wordt de oplossing gecontroleerd uitgerold naar test-, acceptatie- en productieomgevingen. Hierbij zijn ALM en release governance belangrijk.
| Activiteit | BO | PM | SA | DEV | QA | DO | OPS |
|---|---|---|---|---|---|---|---|
| Release planning | A | R | C | I | C | C | I |
| Deployment uitvoeren | I | I | C | I | I | R | C |
| Deployment validatie | I | R | C | C | R | C | C |
| Go-live besluit | A | R | C | I | C | C | C |
Na livegang verschuift de nadruk naar stabiliteit, monitoring, incidentafhandeling en gecontroleerde doorontwikkeling.
| Activiteit | BO | PM | SA | DEV | QA | DO | OPS |
|---|---|---|---|---|---|---|---|
| Monitoring | I | I | C | C | I | R | A |
| Incidentbeheer | I | I | C | C | I | R | A |
| Wijzigingen beoordelen | A | R | C | C | I | C | C |
| Doorontwikkeling | A | R | C | R | C | C | C |