Programma van eisen en wensen Inzake de Europese aanbesteding Agile Ontwikkelteams met kenmerk INK

Bijlage I

Programma van eisen en wensen Inzake de Europese aanbesteding Agile Ontwikkelteams met kenmerk INK12.214.4 Versie 1

Datum: Opgesteld door: Kenmerk van dit document:

19-12-2012 Het CAK (KvK-nummer: 27139750) INK12.214.4

Inhoudsopgave Inleiding .................................................................................................................................................... 3 Ontwikkelproces ...................................................................................................................................... 3 2.1 Inleiding ............................................................................................................................................ 3 2.2 Werkproces extern Ontwikkelteam ................................................................................................... 4 2.3 Continue verbetering......................................................................................................................... 4 2.4 Nadere uitwerking Agile ontwikkelproces.......................................................................................... 5 2.4.1 Inleiding ........................................................................................................................................ 5 2.4.2 Rollen en verantwoordelijkheden.................................................................................................. 5 2.4.3 Refinement ................................................................................................................................... 6 2.4.4 Sprintplanning............................................................................................................................... 7 2.4.5 Realisatie ...................................................................................................................................... 8 2.4.6 Demo ............................................................................................................................................ 9 2.4.7 Regressietest................................................................................................................................ 9 2.4.8 Retrospective.............................................................................................................................. 10 2.4.9 Scrum of scrums ......................................................................................................................... 11 2.5 Kritische performance indicatoren................................................................................................... 11 3 Sturende processen............................................................................................................................... 13 3.1 Contractmanagement ..................................................................................................................... 13 3.1.1 Inleiding ...................................................................................................................................... 13 3.1.2 Klanttevredenheid....................................................................................................................... 14 3.1.3 Operationeel contractmanagement............................................................................................. 16 3.1.4 Tactisch contractmanagement.................................................................................................... 17 3.2 Planning en control ......................................................................................................................... 18 3.2.1 Inleiding ...................................................................................................................................... 18 3.2.2 Procesbeschrijving...................................................................................................................... 18 3.2.3 Kwartaalplan ............................................................................................................................... 19 3.3 Kwaliteitsmanagement.................................................................................................................... 19 3.4 Financieel management.................................................................................................................. 20 3.4.1 Inleiding ...................................................................................................................................... 20 3.4.2 Prijs per sprint – nacalculatie ...................................................................................................... 20 3.4.3 Prijs per story point – nacalculatie .............................................................................................. 22 3.4.4 Eisen ten aanzien van tarifering.................................................................................................. 22 3.5 Overlegstructuur ............................................................................................................................. 23 3.6 Risico management ........................................................................................................................ 24 3.7 Escalatieprocedure ......................................................................................................................... 25 4 Eisen en wensen t.a.v. Ontwikkelteams............................................................................................... 25 4.1 Inleiding .......................................................................................................................................... 25 4.2 Samenstelling Ontwikkelteams ....................................................................................................... 26 4.3 Contractering Ontwikkelteam .......................................................................................................... 29 4.4 Logistieke eisen .............................................................................................................................. 29 4.5 Opleiding......................................................................................................................................... 30 4.6 Resultaatverantwoordelijkheid Ontwikkelteams .............................................................................. 30 4.7 Administratieve eisen inzet medewerkers....................................................................................... 32 5 Bijlagen bij het programma van eisen en wensen .............................................................................. 33 1 2

INK12.214.4

pagina 2 van 33

19-12-2012

1

Inleiding

Dit document bevat de eisen en wensen die het CAK stelt aan de Europese aanbesteding “Agile ontwikkelteams” en is een integraal onderdeel van het Beschrijvend Document met kenmerk INK12.214.4. Het kenmerk van onderhavige aanbesteding Agile ontwikkelteams is INK12.214. De op te geven prijzen dienen inclusief alle eisen en wensen te zijn, tenzij anders wordt vermeld. In het programma van eisen en wensen wordt nader ingegaan op de gevraagde dienstverlening t.a.v. Agile Ontwikkelteams. De opbouw is weergegeven in onderstaande tabel: Hoofdstuk 2 Ontwikkelproces

In het ontwikkelproces worden de raakvlakken tussen Inschrijver en het CAK beschreven. Omdat de Ontwikkelteams complementair zijn aan de interne Ontwikkelteams van het CAK is er voor gekozen om de raakvlakken te baseren op de Agile ontwikkelmethodiek Scrum. Per deelproces is de omschrijving, de aanleiding, het doel, de deelnemers en de input en output beschreven. De procesbeschrijvingen zijn aangevuld met een tabel met activiteiten en rollen en verantwoordelijkheden. De procesbeschrijvingen zijn aangevuld met specifieke eisen t.a.v. bijvoorbeeld KPI’s en rapportage.

Hoofdstuk 3 Sturende processen

De sturende processen sturen op de input en output van het ontwikkelproces. Specifiek wordt aandacht besteed aan contractmanagement, planning & control, kwaliteitsmanagement, financieel management en risicomanagement. Tevens is de overlegstructuur opgenomen waarin de sturende processen samenkomen. Het hoofdstuk Ontwikkelteams richt zich op de samenstelling van een Ontwikkelteams en overige randvoorwaarden omtrent de werkzaamheden van Ontwikkelteams. Tevens wordt ingegaan op het toekomstige scenario waarbij afgerekend wordt op basis van resultaat i.p.v op gemaakte uren.

Hoofdstuk 4 Ontwikkelteams

De wijze waarop eisen en wensen zijn beschreven is nader uitgewerkt in hoofdstuk 4.4, “minimumeisen en subgunningscriteria” van het Beschrijvend Document. Tevens is daar opgenomen op welke wijze de wensen beoordeeld worden als onderdeel van de subgunningscriteria prijs en kwaliteit. Voor het indienen van de inschrijving zal onderhavige bijlage van het Beschrijvend Document inregraal als word document ter beschikking worden gesteld zodat inschrijvers op eenvoudige wijze de tabellen kunnen invullen waarin de eisen en wensen zijn opgenomen.

2

Ontwikkelproces

2.1

Inleiding

Het ontwikkelproces binnen het CAK is gebaseerd op Agile. Binnen de Agile methodiek worden op dit moment elementen van de ontwikkelmethodiek Scrum gehanteerd. Op het raakvlak van CAK en de toekomstige leverancier is er vooralsnog voor gekozen om hiervoor de in de markt bekende elementen uit Scrum voor te gebruiken. Van deze elementen zijn de processen inclusief activiteiten, rollen en verantwoordelijkheden uitgeschreven. In Figuur 1 is de relatie tussen de processen weergegeven.

INK12.214.4

pagina 3 van 33

19-12-2012

Figuur 1 Ontwikkelproces

2.2

Werkproces extern Ontwikkelteam

Binnen het CAK wordt de Agile methodiek Scrum gebruikt in de Ontwikkelteams. Deze methodiek is verder uitgewerkt in het Scrum handboek uit bijlage 1. De gehanteerde werkbeschrijving zoals deze binnen de huidige Ontwikkelteams gehanteerd wordt is bijgevoegd in Bijlage 2. Hierin is een concept van het uniforme werkproces voor softwareontwikkeling nader uitgewerkt. De uitwerking van het uniforme werkproces is nog in ontwikkeling. Aangezien het de bedoeling is dat de Ontwikkelteams van inschrijver complementair zijn aan de interne Ontwikkelteams, is het beschreven interne werkproces ook van toepassing op de inschrijver. De wijze waarop Inschrijver haar Ontwikkelteam(s) aanstuurt is een verantwoordelijkheid van de Inschrijver. Nr.

Omschrijving eis/wens

Ja/Nee

Toelichting

Scrum procesbeschrijving E1.

Inschrijver conformeert zich aan de binnen het CAK gebruikte procesbeschrijvingen als zijnde opgenomen in Bijlage 1 en Bijlage 2 (zie Hoofdstuk 5 Bijlagen bij het programma van eisen en wensen).

n.v.t.

E2.

De gehanteerde processen binnen het CAK worden op dit moment verder doorontwikkeld met als gevolg dat de processen met raakvlakken met de inschrijver mogelijkerwijs zouden kunnen veranderen. Voor zo ver van invloed op de Inschrijver, zullen deze wijzigingen via de Nota van Inlichtingen gecommuniceerd worden. Indien wijzigingen in de processen gedurende de raamovereenkomst plaats vinden dan werkt de winnende inschrijver mee aan deze procesverandering waarbij Inschrijver en het CAK in onderling overleg de procesverandering doorvoeren.

n.v.t.

2.3

Continue verbetering

Onderdeel van Agile ontwikkeling is het continue verbeteren van het ontwikkelproces. Omdat Agile zich kenmerkt door het ontwikkelen in korte iteraties, waarbij de scope niet bevroren is, is het continue verbeteren

INK12.214.4

pagina 4 van 33

19-12-2012

een gezamenlijke verantwoordelijkheid van het CAK en de Inschrijver . Zo is het een verantwoordelijkheid van het CAK om er voor te zorgen dat de specificaties helder en testbaar zijn en in de juiste volgorde ontwikkeld gaan worden. Het is de verantwoordelijkheid van het Ontwikkelteam om te sturen op de input van het Ontwikkelteam teneinde de condities te scheppen om te verbeteren. Om continue verbeteringen te monitoren worden KPI’s gehanteerd die toezien op de kwaliteit en productiviteit van het Ontwikkelteam. Indien op basis van deze KPI’s blijkt dat er geen verbetering plaatsvindt, dan dienen de oorzaken hiervan benoemd te worden en dienen er verbeterafspraken gemaakt te worden. Om het continue verbeteringsproces te faciliteren zijn in paragraaf 2.4 de processen uitgeschreven op het raakvlak van Inschrijver en het CAK. In paragraaf 2.5 zijn de KPI’s met betrekking dat Agile ontwikkeling uitgewerkt waar minimaal over gerapporteerd dient te worden. Als sturend proces is o.a. kwaliteitsmanagement ingericht.

2.4

Nadere uitwerking Agile ontwikkelproces

2.4.1

Inleiding

In dit hoofdstuk wordt nader ingegaan op de Agile ontwikkelmethodiek zoals deze bij het CAK momenteel functioneert. Als leidraad voor de Agile processen is Scrum als methodiek gehanteerd. De reden hiertoe is dat deze methodiek op dit moment gehanteerd wordt binnen het CAK voor de eigen Agile Ontwikkelteams. Aangezien de Ontwikkelteams van Inschrijver complementair zijn aan de interne Ontwikkelteams, is er voor gekozen om dezelfde processen te hanteren als voor Scrum gehanteerd worden. De beschreven processen geven het raakvlak tussen het externe Ontwikkelteam en het CAK aan. Per stap in het proces wordt aangegeven wat de rollen en verantwoordelijkheden zijn en welke input en output bij de processtap behoren.

2.4.2

Rollen en verantwoordelijkheden

De gehanteerde rollen binnen de uitgewerkte processtappen zijn in deze paragraaf globaal beschreven. Voor de verantwoordelijkheden wordt het RACI-model gebruikt. Rollen Rol

Omschrijving

Backlog manager

De Backlog manager is eindverantwoordelijk voor de backlog items welke besproken worden tijdens de sprint planning. De Backlog manager is gepositioneerd bij application development. De Product Owner is verantwoordelijk voor de afstemming van de product backlog items met de stakeholders en doet voorstellen t.a.v. de prioritering van back log items. De Product Owner is gepositioneerd bij de interne klant van de afdeling application development De Scrum Master is eindverantwoordelijk voor het goed functioneren en coachen van het Ontwikkelteam. De Scrum Master hanteert hiervoor de methoden gebaseerd op Scrum. De Scrum Master maakt deel uit van het Ontwikkelteam en wordt door de Inschrijver geleverd. Het Ontwikkelteam is een zelfsturend multidisciplinair team van de Inschrijver waarbij de individuele teamleden gezamenlijk verantwoordelijk zijn voor de realisatie van product backlog items en het testen van de gerealiseerde deliverables. Een stakeholder is een belanghebbende in de te ontwikkelen product backlog items. Informatie Management is binnen het CAK o.a. verantwoordelijk voor het beheren van informatiebeleid en –planning, het leveren van de architectuur, portfoliomanagement, gegevensbeleid en metagegevensmanagement, functioneel beheer, informatie integratie & business intelligence, beheren procesarchitectuur,

Product Owner

Scrum Master

Ontwikkelteam

Stakeholder Informatie Management

INK12.214.4

pagina 5 van 33

19-12-2012

kwaliteits/continuïteit management en risk management. RACI model Het RACI-model is een matrix die gehanteerd wordt om de rollen en verantwoordelijkheden vast te leggen. Binnen het RACI-model worden de volgende letters gehanteerd om de verantwoordelijkheden bij de verschillende rollen aan te geven: R (Responsible, NL: Verantwoordelijk) degene die verantwoordelijk is voor de uitvoering. Verantwoording wordt afgelegd aan de persoon die accountable is. A (Accountable, NL: Eindverantwoordelijk) degene die (eind)verantwoordelijk, bevoegd is en goedkeuring geeft aan het resultaat. Als het erom gaat, moet hij/zij het eindoordeel kunnen vellen, mandaat hebben. C (Consulted, NL: Raadplegen) iemand die meehelpt in de uitvoering (behalve als RASCI wordt gebruikt, dan wordt dat via de S aangegeven) of vooraf geraadpleegd wordt. Dit is tweerichtingscommunicatie. Deze persoon geeft (mede) richting aan het resultaat, hij/zij wordt voorafgaand aan beslissingen of acties geraadpleegd. I (Informed, NL: Informeren) iemand die geïnformeerd wordt over de beslissingen, over de voortgang, bereikte resultaten enz. Dit is eenrichtingscommunicatie. De invulling van de rollen en verantwoordelijken kunnen aan de zijde van het CAK gedurende de contractperiode wijzigen en hebben daarmee impact op de procesbeschrijvingen zoals hieronder zijn weergegeven. Eventuele wijziging in de rollen en verantwoordelijkheden zullen vooraf kenbaar worden gemaakt aan de gecontracteerd leverancier(s) voor onderhavige aanbesteding. Nr.


Ja/Nee

Toelichting

Rollen en verantwoordelijkheden E3.

Inschrijver gaat akkoord met een eventuele wijziging in de rollen en verantwoordelijkheden gedurende de contractperiode aan de zijde van het CAK. Eventuele wijzigingen hebben geen invloed op de rollen, verantwoordelijkheden en beloningsstructuur aan de zijde van de Inschrijver tenzij gezamenlijk anders wordt overeengekomen.

2.4.3

n.v.t.

Refinement

Aspect

Omschrijving

Omschrijving

In het Refinement proces stemmen de stakeholders en het ontwikkelteam de inhoud van vooraf benoemde userstories af. De backlog items worden verduidelijkt aan het Ontwikkelteam. Userstories kunnen inplannen bij de sprintplanning Verduidelijken backlog items teneinde het stempel “conform Definition of Ready” op het backlog item te kunnen plakken en het maken van een globale schatting van de hoeveelheid werk per backlog item. In bijlage 4 is ter illustratie een voorbeeld opgenomen van een definition of ready document. Product Owner, stakeholders, Backlog manager, Informatie management Scrum Master, Ontwikkelteam Selectie van de Product backlog Product backlog items, die conform “definition of ready” zijn en daardoor in te schatten / planbaar zijn. Registratie in de product backlog

Aanleiding Doel

Deelnemers CAK Deelnemers inschrijver Input Output Relatie met andere processen

INK12.214.4

pagina 6 van 33

19-12-2012

Tabel 1 RACI tabel refinement

Ja/Nee

R R A A C

C I I R A

I I I R R

Informatie management


Ontwikkelteam

Nr.

A A C C C

Scrum Master

C I R R C

Product Owner

Stakeholder

Organiseren dat de juiste rollen aan tafel zit Organiseren refinement meeting Vaststellen acceptatiecriteria Verduidelijken backlog items Per item vaststellen of aan de definition of ready is voldaan

Backlog manager

Activiteit

C I I R C

Toelichting

Refinement E4.

Inschrijver gaat akkoord met de activiteiten, rollen en verantwoordelijkheden behorende bij het proces refinement.

2.4.4

n.v.t.

Sprintplanning

Aspect

Omschrijving

Omschrijving

In de sprintplanning wordt bepaald welke product backlog items meegenomen worden in een sprint. Per ingepland product backlog item dient een prioritering aangegeven te worden. Na vaststellen van de prioritering kan een stippellijn geplaatst worden om onderscheid aan te brengen welke backlog items met grote zekerheid gerealiseerd worden en welke backlog items wellicht gerealiseerd kunnen worden. Gevulde product backlog Inplannen product backlog items welke meegenomen worden in de sprint Product Owner, Backlog manager Scrum Master, Ontwikkelteam Geprioriteerde Product backlog met items die voldoen aan de Definition of Ready Sprintplanning Realisatie

Aanleiding Doel Deelnemers CAK Deelnemers inschrijver Input Output Relatie met andere processen

Tabel 2 RACI tabel sprintplanning

INK12.214.4

pagina 7 van 33

C

R I C R I I I R

C I A

I I R

A A A C

R R R R

19-12-2012


A AR C A I I I A

Ontwikkelteam

Backlog manager

C I I C

Scrum Master

Stakeholder

Organiseren dat de juiste kennis aan tafel zit Organiseren sprintplanningsmeeting Per backlog item omvang vaststellen in Story Points Per backlog item vaststellen van de prioritering Rapportage werkelijk gemaakte uren sprint n-1 (vorige sprint) Vaststellen maximaal te realiseren Story Points Plaatsen stippellijn Vaststellen sprintplanning

Product Owner

Activiteit

C C C

C

Nr.


Ja/Nee

Toelichting

Realisatie E5.

Inschrijver gaat akkoord met de activiteiten, rollen en verantwoordelijkheden behorende bij het proces sprintplanning.

2.4.5

n.v.t.

Realisatie

Aspect

Omschrijving

Omschrijving

In de realisatiefase worden de te ontwikkelen backlogitems als opgenomen in de sprintplanning door het Ontwikkelteam gerealiseerd. Vrijgave gebeurd in de Demo als beschreven in paragraaf 2.4.6 op basis van de definition of done (Zie bijlage 5 voor een voorbeeld) Sprintplanning met backlog items Ontwikkelen, testen en vrijgave van alle items in de sprintplanning. Vrijgave ?? mist tekst Backlog manager, Productowner / stakeholder Scrum Master, Ontwikkelteam Sprintplanning , definition of done, ontwikkelstandaarden, bevindingen uit regressietest voorgaande sprint(s) Afgerond product dat voldoet aan de definition of done, rapportage Kwaliteitsmanagement Contractmanagement


Tabel 3 RACI tabel realisatie Stakeholder

Backlog manager

Product Owner

Scrum Master

Ontwikkelteam

Toepassen richtlijnen en standaarden t.b.v. de ontwikkeling Oplossen impediments Ontwikkelen sprintplanningsitems in Be Informed Systeemtesten van sprintplanningsitems Code inchecken in versiebeheer en voorzien van een label Opstellen systeemdocumentatie Opstellen vrijgave advies Opstellen oplever instructies Voortgangsrapportage KPI rapportage

I I I -

C R -

C I I I I

A A A A A A A A A A

R R R R R R R R R R

Nr.


Ja/Nee

I I I I

Toelichting

Realisatie E6.

Inschrijver gaat akkoord met de activiteiten, rollen en verantwoordelijkheden behorende bij het proces realisatie.

n.v.t.

E7.

De voortgangsrapportage bevat tenminste een indicatie over het wel

n.v.t.

INK12.214.4

pagina 8 van 33

19-12-2012


Activiteit

C -

of niet tijdig kunnen realiseren van de sprintplanning. Daarnaast wordt hierin ook vermeld of er zaken zijn geconstateerd, die niet de onderhanden items raken, maar waarvan het advies is deze op termijn te realiseren (dus nu op de productbacklog te plaatsen). Voortgangsrapportage dient plaats te vinden zodra er een aanwijzing is dat de sprintplanning niet behaald kan worden.

2.4.6

Demo

Aspect

Omschrijving

Omschrijving

In een demo worden de ontwikkelde backlog items uit een sprintplanning gepresenteerd aan de Product Owner en stakeholders. Op basis van de demo wordt de sprint (globaal) geaccepteerd of niet.

Aanleiding Doel Deelnemers CAK Deelnemers inschrijver Input Output

Relatie met andere processen

De onderliggende acceptatiecriteria maken deel uit van het document “definition of done”. In Bijlage 5 is een voorbeeld gegeven van een “definition of done”document. Gerealiseerde items uit een sprint Vrijgave van gerealiseerde items voor gebruikers acceptatietest Product Owner, Backlog manager, Stakeholder Scrum Master, Ontwikkelteam Gerealiseerde producten in een sprint, Definition of done Vrijgegeven producten uit een sprint (gereed voor regressie en gebruikersacceptatie test) Na afloop van de demo rapporteren over KPI’s van afgelopen sprints Kwaliteitsmanagement Contractmanagement

Tabel 4 RACI tabel demo Activiteit

Stakeholder

Product Owner

Backlog manager

Scrum Master

Ontwikkelteam


Organiseren dat de juiste kennis aan tafel zit Organiseren demosessie Inhoudelijke presentatie gerealiseerde sprintplannings items Acceptatie van de sprint Na afronden demo rapporteren over KPI’s van afgelopen sprints

C I I R

R C C RA I

A RA C R I

C I A C AR

I I R C

C O I C

Nr.


Ja/Nee

Toelichting

Demo E8.

Inschrijver gaat akkoord met de activiteiten, rollen en verantwoordelijkheden behorende bij het proces demo.

2.4.7

INK12.214.4

n.v.t.

Regressietest

pagina 9 van 33

19-12-2012

De regressietest is een intern CAK-proces dat ter informatie is opgenomen omdat het raakvlakken heeft met de ontwikkelprocessen sprintplanning en realisatie. Aspect

Omschrijving

Omschrijving

In een regressietest wordt de bestaande functionaliteit binnen een applicatie in combinatie met de uit de demo vrijgegeven items getest om te beoordelen of de gehele applicatie nog steeds conform specificatie functioneert. Vrijgave sprint items demo Borgen werking applicatie bij toevoeging functionaliteit Regressietestteam, Backlog manager (ik zou deze rol opnemen om te zorgen date r een link is tussen je realisatie en je regressietest. Het regressietestteam test, de backlog manager zorgt ervoor dat vragen beantwoord worden) Vrijgegeven producten in een demo, acceptatiecriteria Geen bevindingen: alle producten van de sprint worden opgeleverd Wel bevindingen: geen enkel product van de sprint wordt opgeleverd, alle bevindingen worden in dan lopende sprint opgelost.

Aanleiding Doel Deelnemers CAK

Deelnemers inschrijver Input Output


2.4.8

Sprintplanning, realisatie

Retrospective

Aspect

Omschrijving

Omschrijving

Ter afsluiting van een sprint houdt het Ontwikkelteam een meeting waarbij gekeken wordt naar verbeterpunten en punten die gekoesterd moeten worden. Hierbij kan breder gekeken worden dan het Ontwikkelteam alleen. Ook de rol van de Product Owner, stakeholder en de kwaliteit van de input kan onderdeel uitmaken van een retrospective. Afsluiting van een sprint. Continue verbeteren van teamprestaties van het Ontwikkelteam Product Owner, Backlog manager Scrum Master, Ontwikkelteam Rapportage, resultaten realisatie, demo en regressietest Retrosamenvatting inclusief afgeronde acties vorige retrosamenvatting. De retrosamenvatting bevat o.a. de koesterpunten en verbeterpunten

Aanleiding Doel Deelnemers CAK Deelnemers inschrijver Input Output


Kwaliteitsmanagement

Tabel 5 RACI tabel retrospective Activiteit

Stakeholder

Backlog manager

Product Owner

Scrum Master

Ontwikkelteam


Organiseren retrospective Begeleiden retrospective Verslaglegging verbeteren koesterpunten CAK Verslaglegging verbeteren koesterpunten Ontwikkelteam Retrosamenvatting

I I -

C C R I I

C R I I

RA RA A A AR

C I R C

I -

Nr.


INK12.214.4

Ja/Nee

pagina 10 van 33

Toelichting

19-12-2012

Demo E9.

Inschrijver gaat akkoord met de activiteiten, rollen en verantwoordelijkheden behorende bij het proces retrospective.

2.4.9

n.v.t.

Scrum of scrums

Aspect

Omschrijving

Omschrijving

Voor de doorontwikkeling van de systemen bij het CAK wordt gewerkt met meerdere Ontwikkelteams. Alle teams voeren aanpassingen in dezelfde codebase door. De teams worden zo goed mogelijk op autonome onderdelen ingezet, maar door de onderlinge afhankelijkheid is continue technisch inhoudelijke afstemming noodzakelijk. (Minimaal) Twee maal per week wordt een afstemsessie belegd, waarbij een afvaardiging van elk team (scrummasters) elke op de hoogte brengt van de werkzaamheden binnen het team. Hierdoor kunnen knelpunten en afhankelijkheden tijdig worden gesignaleerd en ondervangen.


Met meerdere Ontwikkelteams tegelijkertijd aan één systeem ontwikkelen Vroegtijdig signaleren en ondervanging van knelpunten en afhankelijkheden. Backlog manager, Scrum Master (m.i. zijn hier ook de scrummasters van de andere ontwikkelteams bij aanwezig) Scrum Master, Ontwikkelteam Sprintplanning per Ontwikkelteam met bijbehorende user stories die voldoen aan de definition of ready. In technische zin afstemmen afhankelijkheden Sprintplanning, Realisatie

Nr.


Ja/Nee


AR AR AR

Ontwikkelteam

Backlog manager

-

Scrum Master

Stakeholder

Organiseren scrum of scums Begeleiden scrum of scrums Deelnemen aan scrum of scrums

Product Owner

Activiteit

C

C -

C -

R

Toelichting

Scrum of scrums E10. Inschrijver gaat akkoord met de activiteiten, rollen en verantwoordelijkheden behorende bij het proces scrum of scrums.

2.5

n.v.t.

Kritische performance indicatoren

INK12.214.4

pagina 11 van 33

19-12-2012

Ten behoeve van het sturen op prestaties van Ontwikkelteams is het van belang om deze prestaties meetbaar te maken en hierop te rapporteren. Deze prestaties worden Kritisch Performance Indicatoren (KPI’s) genoemd. Onder prestaties wordt o.a. verstaan de productiviteit, kwaliteit en voorspelbaarheid. Nr.


Ja/Nee

Toelichting

KPI’s Ontwikkelteams E11. Inschrijver dient de productiviteit per sprint meetbaar te maken in de vorm van een Kritische Performance Indicator. De productiviteit wordt gemeten door het totaal aantal bestede uren door het team te delen door het aantal story points per sprint.

n.v.t.

Toelichting (voorbeeld): Wanneer er tijdens een sprint 28 story points gerealiseerd worden met een Ontwikkelteam van 7 mensen in 2 weken, dan is het totaal aantal bestede uren 7 * 40 * 2 = 560 uur. Dit leidt tot een KPI waarde van 20 uur per story point. W1.

Beschrijf op welke wijze de manier van vaststellen van story points binnen een Ontwikkelteam geobjectiveerd wordt ten einde de omvang per story point over meerdere sprints eenduidig te houden.

n.v.t.

Beoordeling: Beoordeling vindt plaats op basis van de volgende niet limitatieve lijst van beoordelingselementen: • Compleetheid van de beantwoording in relatie tot de wens; •

De relevantie van de beantwoording in relatie tot de wens;

•

De te bereiken consistentie;

•

De mate waarin de aangedragen methode uitgevoerd en

gecontroleerd kan worden. Het aantal woorden dat gebruikt mag worden is bij voorkeur niet meer dan 500. Bij overschrijding van het aantal woorden kunnen niet relevante uitweidingen leiden tot puntenaftrek. E12. Inschrijver dient de voorspelbaarheid van de sprintplanning meetbaar te maken in de vorm van een KPI en hier per sprint over te rapporteren. W2.

Op welke wijze meet u de voorspelbaarheid van de sprintplanning als bedoeld in Eis E12 en op welke wijze gebruikt u deze KPI om de voorspelbaarheid te vergroten.

n.v.t.



•

De te bereiken consistentie;

•

De mate waarin de aangedragen methode uitgevoerd en

gecontroleerd kan worden. Het aantal woorden dat gebruikt mag worden is bij voorkeur niet meer dan 500. Bij overschrijding van het aantal woorden kunnen niet relevante uitweidingen leiden tot puntenaftrek E13. Inschrijver dient de kwaliteit per sprint meetbaar te maken in de vorm van een KPI en hier per sprint over te rapporteren.

W3.

Op welke wijze meet u de kwaliteit per sprint als bedoeld in Eis E13 en op welke wijze gebruikt u deze KPI om de kwaliteit te vergroten op wijze die verifieerbaar is door het CAK.

INK12.214.4

pagina 12 van 33

n.v.t.

19-12-2012



•

De bruikbaarheid van de aangedragen KPI;

•

De mate waarin de aangedragen methode uitgevoerd kan

worden. Het aantal woorden dat gebruikt mag worden is bij voorkeur niet meer dan 500. Bij overschrijding van het aantal woorden kunnen niet relevante uitweidingen leiden tot puntenaftrek W4.

Welke aanvullende KPI’s gaat u hanteren op het gebied van prestaties van een Ontwikkelteam? Leg hierbij uit op welke wijze u de KPI’s meet en rapporteert. Geef tevens aan waarom zijn deze KPI’s van waarde zijn voor het CAK.

n.v.t.



•

De bruikbaarheid van de aangedragen KPI’s;

•

De mate waarin de aangedragen KPI’s objectief zijn vast te

stellen. Het aantal woorden dat gebruikt mag worden is bij voorkeur niet meer dan 1000. Bij overschrijding van het aantal woorden kunnen niet relevante uitweidingen leiden tot puntenaftrek. W5.

Op welke wijze rapporteert u de KPI’s. In de beantwoording dient een voorbeeldrapportage opgenomen te worden.

n.v.t.

Beoordeling: Beoordeling vindt plaats op basis van de volgende niet limitatieve lijst van beoordelingselementen: • De wijze waarop KPI’s geduid kunnen worden door het CAK; •

De mate waarin historische ontwikkeling van de KPI’s zichtbaar zijn.

3

Sturende processen

3.1

Contractmanagement

3.1.1

Inleiding

Het CAK is voornemens om contractmanagement in te richten inzake de beoogde Raamovereenkomst. Contractmanagement wordt omschreven als het op operationeel niveau managen van alle contractueel vastgelegde verantwoordelijkheden, verplichtingen, procedures, afspraken, voorwaarden en tarieven rond een bepaalde overeenkomst plus het managen van alle onduidelijkheden (bron: Cats CM®). Het CAK heeft haar ambitie op het gebied van contractmanagement vertaald in de navolgende activiteiten: 1. het pro-actief managen van alle afspraken, verplichtingen, voorwaarden, aannames, verwachtingen en doelstellingen met betrekking tot het contractueel bepaalde tussen CAK en Opdrachtnemers; INK12.214.4

pagina 13 van 33

19-12-2012

2. het elimineren van gebreken, hiaten, onduidelijkheden en verschil van interpretatie in de onder 1 genoemde aspecten; 3. het volgens afspraak of op verzoek tijdig (laten) verschaffen van zo correct mogelijke informatie met betrekking tot status, voortgang, financiën, risico’s, besluiten, acties en openstaande issues aan interne opdrachtgevers en het verantwoordelijke management; 4. het organiseren, voeren en administreren van het noodzakelijke overleg tussen CAK en Opdrachtnemers; 5. het managen van niet contractueel vastgelegde, maar voor partijen wel belangrijke aspecten of nevendoelstellingen. Contractmanagement kan pas tot goede resultaten leiden als betrokken partijen op een pro-actieve en transparante wijze invulling geven, respectievelijk bijdragen, aan deze activiteiten. Belangrijke pijlers van het proces contractmanagement zijn de sturing op basis van Kritische Performance Indicatoren(KPI’s) en klanttevredenheid. In paragraaf 2.5 wordt nader ingegaan op de KPI’s. In paragraaf 3.1.2 wordt beschreven op welke wijze klanttevredenheid wordt bepaald. Organisatorisch wordt er onderscheid gemaakt tussen operationeel contractmanagement (paragraaf 3.1.3) en tactisch contractmanagement (paragraaf 3.1.4).

3.1.2

Klanttevredenheid

Klanttevredenheid is een belangrijk contractsturingsmechanisme voor het CAK en maakt onderdeel uit van het tactisch contractmanagement. Klanttevredenheid is een afgeleide van de wijze waarop de inschrijver en het CAK samenwerken om de doelen van het CAK te realiseren. Voorwaarde voor klanttevredenheid is dat het CAK en de inschrijver van elkaar op de hoogte zijn van de afbakening waarbinnen presteren mogelijk is. Derhalve wordt klanttevredenheid op een gestructureerde wijze periodiek vastgesteld waarbij per deelelement altijd gemotiveerd dient te worden waar een gegeven waardeoordeel op gebaseerd is. Hierdoor weten inschrijver en het CAK voortdurend van elkaar op welke elementen de focus moet liggen om de klanttevredenheid te continueren of te verhogen. De klanttevredenheidsindicator is het middel waarmee klanttevredenheid wordt vastgesteld. De klanttevredenheidsindicator is een mandje van deelelementen waarbij per deelelement een waardeoordeel wordt gegeven. De klanttevredenheidsindicator is als volgt opgebouwd: Element

Omschrijving

Beoordelaars

Weging

Toegevoegde waarde tot stand komen backlog items

Met de toegevoegde waarde tot stand komen backlog items wordt bedoeld de proactieve bijdrage die de inschrijver levert aan het refinement proces om de doelstelling van de klant zo goed mogelijk in te vullen. Aspecten die een rol spelen zijn de wijze waarop de functionaliteit wordt ingevuld, de onderhoudbaarheid, wijze waarop aan de doelstellingen van informatiemanagement wordt voldaan. Samengevat spelen zowel de technische alsmede de functionele kwaliteit een rol. Met de betrouwbaarheid wordt bedoeld de mate waarin de inschrijver haar afspraken nakomt.

Product Owner Backlog Manager

25%


20%

Met de kwaliteit van de output wordt de output van een Ontwikkelteam bedoeld. De wijze waarop voldaan wordt aan de definition of done, de kwaliteit van de documentatie en de kwaliteit van


25%

Betrouwbaarheid

Kwaliteit output

INK12.214.4

pagina 14 van 33

19-12-2012

Proactiviteit

Reactiviteit

de code spelen hier o.a. een rol. Met proactiviteit wordt bedoeld de wijze waarop een Ontwikkelteam proactief handelt om de doelstellingen van de klant te verwezenlijken. Reactiviteit ziet toe op de snelheid waarmee inschrijver bevindingen oppakt.


20%


10%

Per onderdeel wordt één maal per kwartaal een gemotiveerde score gegeven in het bereik van 0-10 waarop de leverancier een gemotiveerd weerwoord geeft en indien wenselijk maatregelen aankondigt om de klanttevredenheid te verhogen. In ieder periodiek overkoepelend tactisch contractmanagementoverleg wordt de definitieve beoordeling vastgesteld. Het resultaat is een waarde voor de kwaliteitstevredenheidsindicator. Nr.


Ja/Nee

Toelichting

Klanttevredenheid CAK -> inschrijver E14. Inschrijver gaat akkoord met de wijze waarop de klanttevredenheid wordt vastgesteld en de daarmee samenhangende activiteiten die de inschrijver moet uitvoeren om de klanttevredenheid vast te stellen (het geven van een gemotiveerd weerwoord, het indienen van verbetervoorstellen, opleveren additionele rapportage om deelelementen van de klanttevredenheidsindicator te objectiveren)

n.v.t.

E15. Inschrijver gaat akkoord met het streven naar een minimale waarde voor de klanttevredenheidsindicator van 7.

n.v.t.

E16. Inschrijver gaat akkoord met het nemen van maatregelen om de klanttevredenheid te verhogen.

n.v.t.

E17. Indien de klanttevredenheid gedurende een periode van 6 maanden minder dan een 6 bedraagt, dan is het CAK gerechtigd de nadere overeenkomst waaronder het Ontwikkelteam is ingehuurd, alsmede de raamovereenkomst te ontbinden.

n.v.t.

W6.

Welke maatregelen neemt u om in algemene zin en in specifieke zin als bedoeld in eis E14, te sturen op de klanttevredenheid teneinde een hoge klanttevredenheid te realiseren.

n.v.t.

Uit de beschrijving dient te blijken op welke wijze de maatregelen in opzet, bestaan en werking worden geïntegreerd in de samenwerking met het CAK. De beschrijving dient specifiek van toepassing te zijn op de klantrelatie met het CAK. Beoordeling: Beoordeling vindt plaats op basis van de volgende niet limitatieve lijst van beoordelingselementen: • Compleetheid van de beantwoording in relatie tot de wens; •


•

De robuustheid van de maatregelen;

• De effectiviteit van de maatregelen. Het aantal woorden dat gebruikt mag worden is bij voorkeur niet meer dan 1000. Bij overschrijding van het aantal woorden kunnen niet relevante uitweidingen leiden tot puntenaftrek

INK12.214.4

pagina 15 van 33

19-12-2012

Het CAK is voornemens om, bij een klanttevredenheidsindicator van meer dan 8, het Ontwikkelteam te belonen. Hierbij kunt u bijvoorbeeld denken aan een ontspanningsactiviteit voor het gehele Ontwikkelteam gedurende werktijd. De precieze uitwerking van deze beloning wordt gedurende de contractfase nader uitgewerkt. De gedachte hierachter is dat de beloning bij de leden van het Ontwikkelteam terecht moet komen i.p.v. bij de leverancier, aangezien er een directe relatie is tussen de prestaties van het Ontwikkelteam en de klanttevredenheidsindicator. Klanttevredenheid is een wederkerig middel. Ook de leverancier dient een waardeoordeel te geven over het CAK met als doel het verbeteren van de wijze waarop het opdrachtgeverschap door het CAK wordt ingericht. Nr.


Ja/Nee

Toelichting

Klanttevredenheid Inschrijver -> CAK W7.

Op welke wijze gaat u bovengenoemde klanttevredenheid aangaande het CAK meten?

n.v.t.



•

De objectiviteit van de klanttevredenheidsmeting;

•

De uitvoerbaarheid van verbetervoorstellen om de

klanttevredenheid te verhogen. Het aantal woorden dat gebruikt mag worden is bij voorkeur niet meer dan 1000. Bij overschrijding van het aantal woorden kunnen niet relevante uitweidingen leiden tot puntenaftrek

3.1.3

Operationeel contractmanagement

Aspect

Omschrijving

Omschrijving

Binnen het operationeel contractmanagementoverleg wordt invulling gegeven aan contractmanagement als beschreven in paragraaf 3.1.1. Het operationeel contractmanagement ziet met name toe op de uitvoering van de ontwikkelproces gerelateerde deelprocessen. Uitvoering geven aan contractmanagement Het op operationeel niveau managen van alle contractueel vastgelegde verantwoordelijkheden, verplichtingen, procedures, afspraken, voorwaarden en tarieven rond een bepaalde overeenkomst plus het managen van alle onduidelijkheden Product Owner, Backlog manager (de Backlog manager kan als operationeel contractmanager gezien worden) Scrum Master, Accountmanager O.a. maar niet uitsluitend: Retrosamenvattingen Inzet per medewerker en factuurvoorstellen Rolling forecast Interne en externe risicomatrix KPI’s Verslagen contractmanagement Verslag contractmanagement inclusief: status van gemaakte afspraken binnen het contractmanagement overleg (mate van opvolging); bijgewerkte interne en externe risicomatrix duiding KPI’s

Aanleiding Doel

Deelnemers CAK Deelnemers inschrijver Input

Output

Relatie met andere processen INK12.214.4

Financieel management pagina 16 van 33

19-12-2012

Planning en control Retrospective

Tabel 6 RACI tabel operationeel contractmanagement

Ja/Nee

Accountmanager


Scrum Master

Nr.

Product Owner

Organiseren operationeel contractmanagementoverleg Aanleveren rapportage per sprint Aanleveren factuurvoorstellen Aanleveren rolling forecast Verslaglegging

Backlog manager

Activiteit

RA R

C R

C R C

C A RA

R A

A R

I

I

Toelichting

Operationeel contractmanagement E18. Inschrijver gaat akkoord met de activiteiten, rollen en verantwoordelijkheden behorende bij operationeel contractmanagement

3.1.4

n.v.t.

Tactisch contractmanagement

Aspect

Omschrijving

Omschrijving

Binnen het tactisch contractmanagement wordt invulling gegeven aan contractmanagement als beschreven in paragraaf 3.1.1. Het tactisch contractmanagement ziet met name toe op de kwaliteit en klanttevredenheid Uitvoering geven aan contractmanagement Het op operationeel niveau managen van alle contractueel vastgelegde verantwoordelijkheden, verplichtingen, procedures, afspraken, voorwaarden en tarieven rond een bepaalde overeenkomst plus het managen van alle onduidelijkheden Manager Application Development (de Manager Application Development kan als contracteigenaar gezien worden), Backlog manager, Inkoop Scrum Master, Accountmanager O.a. maar niet uitsluitend: Klanttevredenheid Rolling forecast Interne en externe risicomatrix KPI’s Verslagen operationeel contractmanagement Resultaten eventuele audits op kwaliteit Contract Performance Rapportage (CPR) conform de separaat bijgevoegde CPR template. (zie Bijlage 3 in Hoofdstuk 5 Bijlagen bij het programma van eisen en wensen) Financieel management Planning en control Kwaliteitsmanagement Ontwikkelproces

Aanleiding Doel

Deelnemers CAK Deelnemers inschrijver Input

Output


INK12.214.4

pagina 17 van 33

19-12-2012

Tabel 7 RACI tabel tactisch contractmanagement

R I C

I C

Accountmanager

Ja/Nee

C R I

Scrum Master


C R I

Inkoop

Nr.

A A A A A A A

Hierbij geen PO uitnodigfen

Organiseren tactisch contractmanagementoverleg Opstellen klanttevredenheidsindicator (CAK -> leverancier) Klantevredenheid leverancier -> CAK (zie W7) Opstellen CPR Aanleveren rolling forecast Schriftelijke reactie op CPR Verslaglegging

Backlog manager

Manager application development

Activiteit

R I I R I I R

C I R I I C C

C I R I I R C

Toelichting

Tactisch contractmanagement E19. Inschrijver gaat akkoord met de activiteiten, rollen en verantwoordelijkheden behorende bij tactisch contractmanagement

3.2

n.v.t.

Planning en control

3.2.1

Inleiding

Het proces planning en control ziet toe op de benodigde capaciteit afgezet in de tijd van zowel interne als externe Ontwikkelteams. Zaken als het vergroten van ontwikkelcapaciteit binnen een Ontwikkelteam of het installeren van een compleet Ontwikkelteam komen binnen dit proces aan de orde. Planningen binnen Ontwikkelteams die in het ontwikkelproces reeds benoemd zijn maken geen onderdeel uit van dit proces. Het planning en control proces is bedoeld om vroegtijdig te kunnen anticiperen op wijzigingen in de benodigde ontwikkelcapaciteit.

3.2.2

Procesbeschrijving

Aspect

Omschrijving

Omschrijving

Met het proces planning en control wordt vroegtijdig inzage gegeven in de toekomstig benodigde ontwikkelcapaciteit De inschatting van de benodigde capaciteit ontwikkeling neemt toe of af Vroegtijdig anticiperen op capaciteitswijzigingen teneinde leverancier en het CAK in de gelegenheid te stellen om vroegtijdig resources te reserveren of vrij te geven. Manager application development, Backlog manager, Inkoop


INK12.214.4

Accountmanager Capaciteitsplanning, rapportages ontwikkelproces Rolling forecast Financieel management, contractmanagement, ontwikkelproces, escalatieprocedure

pagina 18 van 33

19-12-2012

Tabel 8 Planning en control

C I

I I R

R R R

Accountmanager leverancier

Ja/Nee

Inkoop


R I I I

AR AR A A A A A

Backlog manager

Nr.

I I


Organiseren planning en control overleg Aanleveren capaciteitsplanning Aanleveren beschikbare resources Aanleveren rapportages ontwikkelproces Actueel maken rolling forecast Resources reserveren of afbouwen bij inschrijver Nadere overeenkomst sluiten of wijzigen

Product Owner

Stakeholder

Activiteit

C I R I R R

Toelichting

Planning en control E20. Inschrijver gaat akkoord met de activiteiten, rollen en verantwoordelijkheden behorende bij het proces planning en control.

3.2.3

n.v.t.

Kwartaalplan

Het resultaat van het proces planning en control is een voortschrijdend kwartaalplan. In een voortschrijdend kwartaalplan wordt inzage gegeven in de benodigde middelen, de planning en de kengetallen uit het ontwikkelproces. Op basis van het kwartaalplan stemmen leverancier en het CAK de toekomstige afname van capaciteit af zodat de leverancier bijtijds resources kan reserveren. Indien uit het kwartaalplan blijkt dat de benodigde ontwikkelcapaciteit niet ingevuld kan worden waardoor de continuïteit van het CAK in het gedrang komt, zal er overgegaan worden tot escalatie.

3.3

Kwaliteitsmanagement

Aspect

Omschrijving

Omschrijving

Kwaliteitsmanagement is het proces waarbij zowel de kwaliteit van de leverancier als de kwaliteit van het CAK op een gestructureerde wijze gemanaged wordt. Kwaliteitsmanagement is een continue proces waarbij periodiek, als onderdeel van het proces contractmanagement, de resultaten worden besproken en verbetermaatregelen worden afgekondigd. Het bewaken van de kwaliteit van de input en output van Ontwikkelteams en het doorvoeren van verbeteringen teneinde de kwaliteit te verhogen.

Doel

Deelnemers CAK Deelnemers inschrijver Input Output Relatie met andere processen

INK12.214.4

Manager application development, Backlog Manager, Project Owner Accountmanager, scrummaster Rapportage met KPI’s uit het ontwikkelproces, verbetervoorstellen retrospective proces, bevindingen uit beheer, bevindingen uit audits, verbeterplan Verbeterplan Ontwikkelproces en contractmanagement

pagina 19 van 33

19-12-2012

Tabel 9 Kwaliteitsmanagement

Nr.

I I


Ja/Nee

A A A A A A A

R

Scummaster

R R R R R R I

Accountmanager leverancier

Backlog manager

I I I

Ontwikkelteam CAK

Product Owner

Organiseren periodieke bespreking Aanleveren input overleg Aanleveren input verbeterplan Penvoerder verbeterplan Bewaken voortgang verbetervoorstellen Afroepen externe audit Uitvoeren interne audit


Activiteit

C I R

C R R

R I C

R I C

Toelichting

Planning en control E21. Inschrijver gaat akkoord met de rollen en verantwoordelijkheden in het proces kwaliteitsmanagement.

n.v.t.

E22. Inschrijver verleent alle medewerking aan een externe kwaliteitsaudit. Hierbij is de maximale frequentie van een externe audit één maal per jaar. Een externe audit wordt minimaal 2 sprints van te voren aangekondigd.

n.v.t.

E23. Inschrijver verleent alle medewerking aan een interne kwaliteitsaudit. Bij een interne kwaliteitaudit beoordeelt een intern ontwikkelteam van het CAK de kwaliteit van bijvoorbeeld de code en documentatie.

n.v.t.

3.4

Financieel management

3.4.1

Inleiding

Met Financieel management wordt sturing gegeven aan de kosten in relatie tot de geleverde prestaties. De kosten hebben betrekking op de ingezette Ontwikkelteams. In dit hoofdstuk wordt uiteengezet op welke wijze Ontwikkelteams gefactureerd mogen worden. Het uitgangspunt hierbij is een prijs per sprint die in rekening gebracht mag worden. De opbouw van de prijs per sprint wordt in de navolgende paragrafen uiteengezet. Hierbij is onderscheid gemaakt tussen een scenario op basis van nacalculatie en een scenario op basis van een prijs gerelateerd aan het aantal gerealiseerde storypoints. Tot slot zijn in paragraaf 3.4.4, Eisen ten aanzien van tarifering, de minimum eisen opgenomen die van toepassing zijn op het aanbieden van tarieven van de gevraagde functieprofielen alsmede de te hanteren indexeringsmethode van de tarieven gedurende de contractperiode.

3.4.2

Prijs per sprint – nacalculatie

Ieder Ontwikkelteam wordt initieel op basis van nacalculatie afgerekend. Afrekenen op basis van nacalculatie houdt in dat de prijs per sprint berekend wordt op basis van de werkelijk gemaakte uren per ingezet functieprofiel. De toegestane functieprofielen zijn benoemd in paragraaf 4.2. De werkelijk gemaakte uren dienen hierbij per sprint gerapporteerd te worden (Zie activiteit 2.4.4 Sprintplanning). INK12.214.4

pagina 20 van 33

19-12-2012

Een voorbeeld van de gevraagde rapportage per sprint is in onderstaande tabel opgenomen. Op de kolom korting zijn W8 en W14 van toepassing: Naam

Functieprofiel

Anna Scrum Master Bertus Senior Ontwikkelaar Cindy Senior Ontwikkelaar Dirk Medior Ontwikkelaar Ed Medior Ontwikkelaar Frederique Senior tester Gerard Medior tester Totaal: Aantal gerealiseerde story points Prijs per story point

Nr.

Periode in dienst 26 wk 26 wk 5 wk 26 wk 26 Wk 26 Wk 26 Wk

Tarief per uur

Korting

€ 100,€ 100,€ 100,€ 75.€ 75,€ 100,€ 75,-

Netto tarief

0 0 30% 0 0 0 0

Ingeplande uren

€ 100,€ 100,€ 70,€ 75.€ 75,€ 100,€ 75,-


Ja/Nee

Werkelijke uren

64 64 64 64 64 64 64

58 70 64 64 64 64 50

Totaal € 5.800,€ 7.000,€ 4.480,€ 4.800,€ 4.800,€ 6.400,€ 3.750,€ 37.030,23 € 1.610,-

Toelichting

Prijs per sprint – nacalculatie E24. Inschrijver gaat akkoord met de wijze waarop de prijs per sprint bepaald wordt.

n.v.t.

E25. Inschrijver dient per sprint een rapportage te overleggen welke minimaal de informatie uit bovengenoemd voorbeeld bevat.

n.v.t.

E26. De prijs per story point dient ten gevolge van een toename in de productiviteit af te nemen. Indien de prijs per story point toeneemt dan dient inschrijver in de gevraagde rapportage aan te geven wat de oorzaak hier van is. Indien de oorzaak bij het Ontwikkelteam ligt dan dient inschrijver aan te geven welke maatregelen er genomen gaan worden om de prijs per story point te laten afnemen.

n.v.t.

Om te stimuleren dat het Ontwikkelteam zo lang mogelijk in dezelfde bezetting bijeen blijft heeft het de voorkeur dat inschrijver bij vervanging van een deelnemer van het Ontwikkelteam een korting geeft over de eerste 250 gewerkte uren van de nieuwe deelnemer. Nr.


Ja/Nee

Toelichting

Korting tarief bij vervanging E27. Inschrijver geeft een korting van minimaal 10% op het overeengekomen uurtarief bij vervanging van Ontwikkelteamleden door verloop. De korting geldt voor de nieuwe deelnemer aan het Ontwikkelteam die de plaats in neemt van een lid van het Ontwikkelteam die het team om wat voor reden dan ook verlaat. De korting is van toepassing op de eerste 250 werkelijk gemaakte uren door de nieuwe medewerker.

n.v.t.

Het CAK en Inschrijver kunnen in voorkomende gevallen overeenkomen om af te zien van de korting. Een situatie waarin dit voor zou kunnen komen is bijvoorbeeld bij het op initiatief van het CAK wijzigen van teamstelling. Bijvoorbeeld bij een verzoek om meer senioriteit aan te brengen of bij splitsing van teams bij afname van een tweede Ontwikkelteam. Toelichting: Door verloop binnen een team gaat kennis verloren en moet een

INK12.214.4

pagina 21 van 33

19-12-2012

nieuw Ontwikkelteamlid ingewerkt worden. W8.

Welke aanvullende korting op het uurtarief, als bedoeld in eis E27, bent u bereid te geven? De aanvullende korting dient te worden opgegeven als één kortingspercentage dat geldig is gedurende de gehele periode van 250 uur. Het opgegeven kortingspercentage is onderdeel van het subgunningscriterium prijs.

3.4.3

n.v.t.

Prijs per story point – nacalculatie

Indien een Ontwikkelteam volledig is ingewerkt en de productiviteit stabiliseert, dan kunnen partijen overeen komen om op basis van een prijs per story point af te rekenen. De prijs per story point is gebaseerd op historische gegevens betreffende de prijs per sprint en het aantal gerealiseerde story points per sprint. Nr.


Ja/Nee

Toelichting

Prijs per storypoint – nacalculatie E28. Inschrijver is bereid om bij stabilisatie van de productie over te gaan op het afrekenen op basis van een prijs per story point.

n.v.t.

E29. Inschrijver gaat er mee akkoord dat expertschattingen in story points aan een audit onderworpen mogen worden indien het CAK en de Inschrijver verschillen van inzicht hebben over de omvang van een story point. Indien uit een audit van een nader te bepalen onafhankelijke derde blijkt dat de omvang van een story point kleiner is geworden dan bij aanvang van het afrekenen per story point, dan wordt de omvang van een story point gecorrigeerd en daarmee ook, in alle redelijkheid, de reeds in rekening gebrachte story points.

n.v.t.

3.4.4

Eisen ten aanzien van tarifering

Ten aanzien van de aan te bieden tarieven in Bijlage J Prijsopgave, gelden de volgende minimumeisen: Nr.


Ja/Nee

Toelichting

Eisen ten aanzien van tarifering E30. De door Inschrijver aangeboden tarieven dienen reëel/marktconform te zijn. Zogenaamde “manipulatieve Inschrijvingen” zijn niet toegestaan.

n.v.t.

E31. Het door Inschrijver aangeboden tarief van een senior ontwikkelaar mag niet lager zijn dan een medior ontwikkelaar.

n.v.t.

E32. Het door Inschrijver aangeboden tarief van een senior tester mag niet lager zijn dan een medior tester

n.v.t.

E33. Het door Inschrijver aangeboden tarief van een medior ontwikkelaar en medior tester mag niet lager zijn dan het tarief van een junior ontwikkelaar / opleidingsplek

n.v.t.

E34. Het tariefverschil binnen één functiestap binnen een functieprofiel (bijvoorbeeld de stap van medior naar senior) mag nooit meer dan

n.v.t.

INK12.214.4

pagina 22 van 33

19-12-2012

50% bedragen. E35. Het tarief van een scrummaster mag niet meer dan 10% hoger zijn dan het hoogst aangeboden tarief voor senior ontwikkelaar of senior tester.

n.v.t.

E36. Inschrijver is verplicht de door het CAK verzochte functies tegen de door Inschrijver opgegeven tarieven te leveren.

n.v.t.

E37. Alle prijzen dienen vermeld te zijn in euro’s en exclusief BTW.

n.v.t.

E38. De op te geven prijzen dienen inclusief al het gestelde in dit Beschrijvend Document inclusief bijlagen te zijn, zoals, maar niet beperkt tot: • alle gestelde eisen/wensen en (algemene) voorwaarden; • het gestelde in hoofdstuk 1.8 van het beschrijvend document scope van de opdracht; • álle overige (bijkomende) diensten en leveringen, zoals bv. consultancy, documentatie, periodiek overleg, rapportages, verzekeringen en reis- en verblijfskosten van (personeel van) Opdrachtnemer.

n.v.t.

E39. Gedurende de looptijd van de raamovereenkomst factureert Opdrachtnemer, in verband met de nakoming van zijn verplichtingen, uitsluitend datgene wat is opgenomen in zijn Inschrijving.

n.v.t.

E40. Alle prijzen zijn vast gedurende de eerste twee jaar van de raamovereenkomst.

n.v.t.

3.5

Overlegstructuur

Om een efficiënte en vooral effectieve formele communicatie tussen de betrokken contractpartijen op de verschillende besturingsniveaus en gedurende de contract life cycle te garanderen wordt de volgende overlegstructuur geïmplementeerd (zie onderstaande tabel). Voor elk overleg zijn de volgende zaken beschreven: - De deelnemers aan beide zijden; - De onderwerpen die besproken worden tijdens het overleg; - De frequentie van het overleg en/of de reden van het overleg; - De vorm van het overleg;

Operationeel per sprint Overleg

Frequentie (per sprint)

Onderwerp, deelnemers aan beide zijden

Sprintplanning Refinement Demo Retrospective Scrum of scrums

1 2 1 1 4

Zie proces paragraaf 2.4.4 Zie proces paragraaf 2.4.3 Zie proces paragraaf 2.4.6 Zie proces paragraaf 2.4.8 Zie proces paragraaf 2.4.9

Operationeel overkoepelend Overleg

Frequentie

Inschrijver

CAK

Onderwerp

Contractoverleg

Per 2 sprints

Scrum Master Optioneel

Backlog manager Optioneel:

O.a. maar niet beperkt tot:

INK12.214.4

pagina 23 van 33

19-12-2012

Accountmanager

Product Owner

•

Functioneren Ontwikkelteam

•

Rapportage

•

Kwaliteit backlog

•

Functioneren samenwerking

•

Klanttevredenheid

•

Rolling forecast

Tactisch / strategisch Overleg

Frequentie

Inschrijver

CAK

Tactisch overleg

1x per kwartaal

Scrum Master Accountmanager

Manager application development, Backlog manager, , Inkoop Optioneel: interne klant, Systeemeigenaar, Product Owner

Strategisch overleg

Nr.

Alleen indien daar aanleiding voor is.

n.t.b.

Onderwerp



Ja/Nee

O.a. maar niet beperkt tot: •

Rapportage

•

KPI’s

•

Kwaliteit leverancier

•

Kwartaalplan met forecast

•

Klanttevredenheid

•

Kwaliteit backlog

O.a. maar niet beperkt tot: •

Contract

•

KPI’s

•

Klanttevredenheid

•

Ontwikkelingen CAK

Toelichting

Overlegstructuur E41. Geef per overleg aan welke personen namens inschrijver vertegenwoordigd zijn.

3.6

Risico management

Het beheersen van risico’s is van groot belang. Derhalve wil het CAK weten op welke wijze de inschrijver met risico’s om gaat. Het CAK maakt een selectie uit de door inschrijver benoemde risico’s en beheersmaatregelen. Deze risico’s en beheersmaatregelen worden integraal onderdeel van de overeenkomst. Daarnaast kunnen risico’s en beheersmaatregelen in overleg tussen het CAK en de inschrijver worden aangevuld. Nr.


Ja/Nee

Toelichting

Risico management W9.

Geef per proces (ontwikkelproces en sturende processen) de interne risico’s en beheersmaatregelen aan. Met interne risico’s wordt bedoeld, risico’s binnen de invloedsfeer van de inschrijver. Gebruik hierbij de volgende indeling 1. risico inclusief kans en impact; 2. beheersmaatregelen; 3. processen waarbij het risico zich voor doet; 4. overleg waarbij de risico’s en maatregelen besproken worden (zie overlegstructuur).

INK12.214.4

pagina 24 van 33

n.v.t.

19-12-2012


De relevantie van de risico’s;

• De kwaliteit van de beheersmaatregelen. Het aantal woorden dat gebruikt mag worden is bij voorkeur niet meer dan 1000. Bij overschrijding van het aantal woorden kunnen niet relevante uitweidingen leiden tot puntenaftrek W10. Geef per proces (ontwikkelproces en sturende processen) de externe risico’s en beheersmaatregelen aan. Met externe risico’s wordt bedoeld, risico’s buiten de invloedsfeer van de inschrijver. Gebruik hierbij de volgende indeling 1. risico inclusief kans en impact; 2. beheersmaatregelen; 3. processen waarbij het risico zich voor doet; 4. overleg waarbij de risico’s en maatregelen besproken worden (zie overlegstructuur). Beoordeling: Beoordeling vindt plaats op basis van de volgende niet limitatieve lijst van beoordelingselementen: • Compleetheid van de beantwoording in relatie tot de wens; •

n.v.t.

De relevantie van de risico’s;

• De kwaliteit van de beheersmaatregelen. Het aantal woorden dat gebruikt mag worden is bij voorkeur niet meer dan 1000. Bij overschrijding van het aantal woorden kunnen niet relevante uitweidingen leiden tot puntenaftrek

3.7

Escalatieprocedure

Voor het oplossen van geschillen dient er een adequate escalatieprocedure overeen gekomen te worden. Na afstemming tussen Inschrijver en het CAK wordt de escalatieprocedure onderdeel van de overeenkomst. Nr.


Ja/Nee

Toelichting

Escalatieprocedure E42. Inschrijver dient een escalatieprocedure te overleggen met daarin opgenomen de escalatieniveaus, de bijbehorende personen en een beschrijving van het mandaat van de bijbehorende personen.

4

Eisen en wensen t.a.v. Ontwikkelteams

4.1

Inleiding

In dit hoofdstuk worden de eisen en wensen ten aanzien van Ontwikkelteams uiteengezet. Een Ontwikkelteam is de groep mensen die zo lang mogelijk in dezelfde samenstelling bijeen zijn ten einde de productiviteitgroei te maximeren. Derhalve geeft het CAK commitment af om een Ontwikkelteam ten minste voor 9 maanden af te nemen. Onderdeel van de periode van 9 maanden is een proeftijd (zie paragraaf . 4.3) In de praktijk zal er sprake van verloop zijn binnen Ontwikkelteams en wordt er ruimte voor junior ontwikkelaars / opleidingsplekken. In de eisen en wensen zijn wordt hierin aandacht besteedt aan de financiële impact die dit heeft op de productiviteit. INK12.214.4

pagina 25 van 33

19-12-2012

4.2

Samenstelling Ontwikkelteams

Inschrijver is in beginsel verantwoordelijk dat er binnen Ontwikkelteams voldoende kennis en ervaring aanwezig is om te ontwikkelen op basis van het platform Be Informed. Echter, het CAK stelt een aantal minimum eisen t.a.v. rollen binnen de Ontwikkelteams die minimaal ingevuld dienen te worden. Op deze wijze borgt het CAK een minimale kennis en ervaring binnen het team. De rest van de teamsamenstelling is de verantwoordelijk van de inschrijver onder de voorwaarde dat het Ontwikkelteam aantoonbaar presteert (Zie KPI’s en klanttevredenheid) Het CAK maakt onderscheidt tussen de volgende functies. Functie

Omschrijving

Benodigde opleiding / ervaring

Denk niveau

Aantal jaren ervaring

Senior ontwikkelaar

De senior ontwikkelaar is verantwoordelijk voor de structuur en de herbruikbare patterns in het Be Informed business process platform. De senior ontwikkelaar onderhoud contacten met de architecten van het CAK en speelt een coördinerende rol binnen het project.

Be Informed Academy (senior specialist) of daarmee overeenstemmend en/of aantoonbare ervaring waaruit blijkt dat de senior specialist op het gevraagde kennisniveau opereert.

HBO/WO

5

HBO

3

HBO

1

HBO

5

HBO

3

Medior ontwikkelaar

Junior ontwikkelaar / opleidingsplek

Senior tester

Medior tester

INK12.214.4

De medior ontwikkelaar analyseert kennis en proces domeinen in samenwerking met domein experts en gebruikers. De medior ontwikkelaar gebruikt de resultaten van de analyse om knowledge models en case management configuraties in Be Informed studio te creëren

De junior ontwikkelaar analyseert kennis en proces domeinen in samenwerking met domein experts en gebruikers. De junior ontwikkelaar gebruikt de resultaten van de analyse om knowledge models en case management configuraties in Be Informed studio te creëren

De senior tester is verantwoordelijk voor de test strategie, het master test plan en aanpak. De senior tester onderhoud contacten met de architecten van het CAK en speelt een coördinerende rol binnen het project De medior tester controleert en test de ontwikkelde applicatie om te bepalen of het voldoet aan de functionele en technische vereisten.

Een senior ontwikkelaar heeft tenminste 5 jaar aantoonbare ervaring met systeemontwikkeling en minimaal drie jaar aantoonbare ervaring met Be Informed ontwikkeling. Be Informed Academy (specialist) of daarmee overeenstemmend of aantoonbare ervaring waaruit blijkt dat de specialist op het gevraagde kennisniveau opereert. Een medior ontwikkelaar heeft tenminste drie jaar aantoonbare ervaring met softwareontwikkeling en minimaal één jaar ervaring met Be Informed ontwikkeling. Be Informed Academy (specialist) of daarmee overeenstemmend of aantoonbare ervaring waaruit blijkt dat de specialist op het gevraagde kennisniveau opereert. Er is geen specifieke werkervaring vereist op het gebied van Be Informed ontwikkeling. De junior ontwikkelaar dient minimaal één jaar ervaring te hebben op het gebied van softwareontwikkeling. Be Informed Academy (test coördinator) of daarmee overeenstemmend of aantoonbare ervaring waaruit blijkt dat de senior tester op het gevraagde kennisniveau opereert.

Be Informed Academy (test engineer) of daarmee overeenstemmend of aantoonbare ervaring waaruit blijkt dat de medior tester op het gevraagde

pagina 26 van 33

19-12-2012

Scrum Master

De scrummaster is verantwoordelijk om het team maximaal te laten presteren. De scrummaster hanteert hiervoor de scrum methodiek.

kennisniveau opereert. Aantoonbaar ervaring met de rol scrummaster. Goede communicatieve en coördinerende vaardigheden zijn essentieel voor de uitvoering van de rol scrummaster.

HBO

5

De scrummaster mag een dubbelrol zijn in die zin dat een ontwikkelaar of tester tegelijkertijd scrummaster kan zijn.

Op basis van bovenstaande rollen gelden de navolgende eisen en wensen voor de samenstelling van een Ontwikkelteam: Nr.


Ja/Nee

Toelichting

Samenstelling Ontwikkelteam E43. Ieder Ontwikkelteam dient minimaal één senior ontwikkelaar te bevatten.

n.v.t.

E44. Ieder Ontwikkelteam dient minimaal één medior ontwikkelaar te bevatten. De rol van medior ontwikkelaar kan ook door een senior ontwikkelaar ingevuld worden.

n.v.t.

E45. Ieder Ontwikkelteam dient minimaal één medior tester te bevatten.

n.v.t.

E46. In ieder Ontwikkelteam dient minimaal één persoon de rol van scrummaster te vervullen

n.v.t.

E47. Ieder Ontwikkelteam mag maximaal twee junior ontwikkelteamleden bevatten.

n.v.t.

E48. Het totaal aantal personen binnen een Ontwikkelteam is bij aanvang van de opdracht 7 personen tenzij anders overeengekomen.

n.v.t.

W11. Op welke wijze probeert u neergang in de productiviteit te beperken in de situatie dat zich teamwijzigingen voordoen.

n.v.t.



•

De uitvoerbaarheid van de maatregelen;

• De effectiviteit van de maatregelen; Het aantal woorden dat gebruikt mag worden is bij voorkeur niet meer dan 500. Bij overschrijding van het aantal woorden kunnen niet relevante uitweidingen leiden tot puntenaftrek. W12. Op welke wijze biedt u aanvullende ondersteuning aan het Ontwikkelteam.

n.v.t.

Toelichting: Te denken valt bijvoorbeeld aan het gebruik van een kennisbank met codeerpatronen waar ontwikkelaars van inschrijver gratis gebruik van kunnen maken. Beoordeling: Beoordeling vindt plaats op basis van de volgende niet limitatieve lijst van beoordelingselementen: • Compleetheid van de beantwoording in relatie tot de wens;

INK12.214.4

pagina 27 van 33

19-12-2012

•


• De toegevoegde waarde van de aanvullende ondersteuning; Het aantal woorden dat gebruikt mag worden is bij voorkeur niet meer dan 500. Bij overschrijding van het aantal woorden kunnen niet relevante uitweidingen leiden tot puntenaftrek. W13. Voor het uitvoeren van de gevraagde dienstverlening is het van groot belang dat de inschrijver voldoende deskundigheid ter beschikking heeft ten einde een goede invulling te geven aan de gevraagde dienstverlening.

n.v.t.

Het Ontwikkelteam met inbegrip van de scrummaster dient over voldoende deskundigheid en ervaring beschikken om op een goede wijze invulling te geven aan de gevraagde dienstverlening. Inschrijver dient aan te geven met welke samenstelling van het Ontwikkelteam het aantreedt. Hierbij dienen de functieprofielen en eisen, als in onderhavige paragraaf benoemd, gehanteerd te worden. De maximum prijs per sprint, uitgaande van 2 weken per sprint, mag 40.000 euro excl. BTW te bedragen. Hierbij dient uitgegaan te worden van een compleet Ontwikkelteam. De gehanteerde tarieven dienen overeen te komen met de tarieven die door inschrijver zijn opgegeven in het prijzenformulier O.a. de volgende kennisgebieden zijn van belang en dienen geborgd te zijn binnen het team: • Kennis van Scrum; • Kennis Be Informed; • Kennis van regelingssystemen; • Kennis van TMAP. Geef aan op welke wijze voornoemde relevante kennis om uitvoering te geven aan de opdracht, geborgd is binnen het Ontwikkelteam. Geef tevens aan hoeveel uur ieder Ontwikkelteamlid per sprint aanwezig is en onderbouw daarbij de prijs per sprint. U kunt de relevante competenties van de betreffende Ontwikkelteamleden onderbouwen met het overleggen van CV’s. Indien het CAK dat wenselijk acht wordt de invulling geverifieerd en zo nodig bijgesteld door het houden van een interview met door het CAK aangewezen Ontwikkelteamleden. Beoordeling: Beoordeling vindt plaats op basis van de volgende niet limitatieve lijst van beoordelingselementen: • Compleetheid van de beantwoording in relatie tot de wens; •


•

De mate waarin de relevante competenties in genoemde kennisgebieden zijn ingevuld;

•

De senioriteit van de Ontwikkelteamleden;

• De mate waarin relevante kennis verenigd is één persoon. Het aantal woorden dat gebruikt mag worden is bij voorkeur niet meer dan 1000. Bij overschrijding van het aantal woorden kunnen niet relevante uitweidingen leiden tot puntenaftrek. E49. Inschrijver is verplicht om bij afroep van een Ontwikkelteam tenminste de in W13 aangeboden mix van kennis en ervaring aan te bieden.

n.v.t.

E50. Inschrijver is verplicht om bij vervanging van Ontwikkelteamleden de competenties van het team van ontwikkelaars op minimaal hetzelfde niveau te behouden tenzij anders overeengekomen.

n.v.t.

INK12.214.4

pagina 28 van 33

19-12-2012

4.3

Contractering Ontwikkelteam

Ontwikkelteams worden door middel van het afsluiten van een nadere overeenkomst onder de raamovereenkomst gecontracteerd. Onderdeel van het installeren van een Ontwikkelteam is tenminste een intake gesprek met de Scrum Master van het Ontwikkelteam. Tevens zal er een proeftijd worden opgenomen. In onderstaande tabel met eisen wordt hier nader op ingegaan. Nr.


Ja/Nee

Toelichting

Contractering Ontwikkelteam E51. Inschrijver gaat akkoord met een intakegesprek met de Scrum Master van het te contracteren Ontwikkelteam. In het intakegesprek wordt beoordeeld of de Scrum Master over de vereiste vaardigheden beschikt om het Ontwikkelteam te leiden. Tevens wordt beoordeeld of de Scrum Master voldoende vaardigheden heeft om als afgevaardigde van het Ontwikkelteam deel te nemen aan de verschillende overleggen met het CAK.

n.v.t.

Het CAK is gerechtigd om op basis van het intakegesprek de voorgestelde Scrum Master af te wijzen. Indien de Scrum Master wordt afgewezen dan dient Inschrijver zo spoedig mogelijk een nieuwe Scrum Master voor te stellen waar vervolgens weer een intakegesprek mee gehouden gaat worden. E52. Na het aantreden van een Ontwikkelteam geldt een proefperiode van 4 sprints. Indien in onderling overleg gedurende de contractperiode de sprintduur wijzigt, dan neemt dientengevolge de duur van de proefperiode toe, tenzij partijen in onderling overleg de criteria per sprint aanpassen waarop getoetst wordt.

n.v.t.

In de proefperiode wordt op de volgende zaken getoetst: Sprint 2: voldoen aan de opgelegde standaarden; Sprint 3: betrouwbaarheid sprintplanning; Sprint 4: klanttevredenheid Indien naar oordeel van het CAK het Ontwikkelteam onvoldoende presteert op de hierboven aangegeven criteria dan wordt de proefperiode met 2 sprints verlengd. Indien na afloop van de verlengde proefperiode het Ontwikkelteam naar oordeel van het CAK nog steeds onvoldoende presteert op van toepassing zijnde criteria, dan kan de afgesloten nadere overeenkomst ontbonden worden alsmede de raamovereenkomst ontbonden worden.

E53. De levertijd voor de afroep van een Ontwikkelteam is maximaal 6 weken. Indien Inschrijver niet binnen de gestelde levertijd in staat is om het gevraagde Ontwikkelteam te laten aanvangen met de werkzaamheden en Inschrijver heeft nog niet eerder een Ontwikkelteam geleverd, dan volgt een direct opeisbare boete van € 50.000,- voor Inschrijver.

4.4

n.v.t.

Logistieke eisen

De ontwikkelstraat bevindt zich op de locatie van het CAK te Den Haag. Derhalve is de locatie van de werkzaamheden Den Haag. Indien in de toekomst de ontwikkelwerkzaamheden zich lenen voor een locatie INK12.214.4

pagina 29 van 33

19-12-2012

anders dan het CAK en het CAK verleent hier goedkeuring voor, dan zijn andere locaties bespreekbaar. Indien gedurende de contractperiode een andere locatie dan het CAK wordt overeengekomen dan worden in een nadere overeenkomst aanvullende afspraken gemaakt ten aanzien van compensatie voor veranderende kosten. Nr.


Ja/Nee

Toelichting

Locatie werkzaamheden E54. Inschrijver gaat er mee akkoord dat de locatie waar de werkzaamheden plaatsvinden op locatie van het CAK is op door het CAK ter beschikking gestelde ontwikkelstraten.

n.v.t.

E55. Inschrijver gaat akkoord met de huisregels als zijn opgenomen in de document “snel wegwijs voor externen en uitzendkrachten”. In bijlage 6 van het PvE is dit document opgenomen.

n.v.t.

4.5

Opleiding

Het CAK heeft in de marktconsultatie aangegeven dat er ruimte is voor opleiding van medewerkers binnen een Ontwikkelteam. In paragraaf 4.2 uit zich dat in de vorm van het functieprofiel junior ontwikkelaar. De junior ontwikkelaar dient tenminste door de Inschrijver zelf opgeleid te worden op het gebied van Be Informed. Nadat aangetoond kan worden dat de junior ontwikkelaar over de benodigde basiskennis beschikt om binnen het Be Informed te ontwikkelen, kan een junior ontwikkelaar deelnemen aan een Ontwikkelteam. Voor het gebruik maken van ontwikkelplekken gelden de volgende aanvullende eisen en wensen: Nr.


Ja/Nee

Toelichting

Opleiding E56. Indien Inschrijver bij een reeds operationeel Ontwikkelteam gebruik wenst te maken van opleidingsplekken dan dient dit altijd in overleg met het CAK plaats te vinden. Het CAK kan hierbij zonder opgaaf van redenen haar toestemming onthouden aan opleidingsplekken.

n.v.t.

Toelichting: Opleidingsplekken kunnen impact op de productiviteit en de productiviteitsontwikkeling hebben. Het CAK wil op basis van een inschatting op de voornoemde impact hier over kunnen besluiten. Indien opleidingsplekken aanvullend zijn op een bestaand Ontwikkelteam dan kan dit financiële consequenties hebben. W14. Inschrijver biedt junior ontwikkelaars gedurende het eerste half jaar na in dienst treden van een Ontwikkelteam tegen gereduceerd tarief aan. Dit gereduceerde tarief dient te worden opgegeven als één kortingspercentage dat geldig is gedurende het gehele half jaar. Het opgegeven kortingspercentage is onderdeel van het subgunningscriterium prijs.

4.6

n.v.t.

Resultaatverantwoordelijkheid Ontwikkelteams

Het CAK beoogt met het outsourcen van Agile Ontwikkelteams ontzorgt te worden op het gebied van het aansturen van individuele teamleden. Voorwaarde hiervoor is dat het team is zijn totaliteit aangestuurd kan worden op de prestaties. Vanuit dat uitgangspunt heeft het CAK een marktconsultatie gehouden waarin o.a. gezocht is naar ervaringen van de markt op gebied van afspraken omtrent resultaatverantwoordelijkheid en INK12.214.4

pagina 30 van 33

19-12-2012

bijbehorende afrekenmechanismen. Het beeld dat de marktconsultatie heeft gegeven was dat het voor het Be Informed platform lastig is om objectieve meetmethoden overeen te komen teneinde op basis van output af te rekenen. De belangrijkste oorzaak hiervoor zijn o.a. het ontbreken van ervaringscijfers op het gebied van Be Informed ontwikkeling. Daarnaast zou het Agile gedachtegoed zich niet voor het afrekenen op basis van resultaat. Het aansturen van Ontwikkelteams op basis van de KPI’s, als gespecificeerd in paragraaf 3.1.2 en door leverancier aangevuld, biedt enig houvast maar geeft geen garanties dat het Ontwikkelteam naar beste kunnen presteert. Idealiter zou het CAK met een ingewerkt Ontwikkelteam afspraken willen maken over vaste prijzen per vooraf gedefinieerde hoeveelheid werk waarbij het uitgangspunt is dat er een eerlijke prijs betaald wordt voor de te ontwikkelen functionaliteit. Hierbij geldt het uitgangspunt dat het Ontwikkelteam alleen product backlog items accepteert die aan de Definition of Ready voldoen. Nr.


Ja/Nee

Toelichting

Resultaatverantwoordelijkheid Ontwikkelteams W15. Welke kengetallen bouwt u op per sprint om op termijn afrekening op basis van resultaat mogelijk te maken? (Resultaat zijn de opleveringen die voldoen aan de definition of done alsmede de mate waarin de sprintplanning behaald wordt).

n.v.t.



•

De objectiviteit van de kengetalen;

•

de senioriteit van de Ontwikkelteamleden;

• en de mate waarin kennis verenigd is één persoon. Het aantal woorden dat gebruikt mag worden is bij voorkeur niet meer dan 1000 Bij overschrijding van het aantal woorden kunnen niet relevante uitweidingen leiden tot puntenaftrek. W16. Op welke wijze komt op basis van de in W15 overlegde kengetallen een fixed price tot stand en wat zijn de mogelijkheden tot het bijstellen van de fixed price indien het CAK de kengetallen of correctiefactoren bestrijdt?

n.v.t.



•

De robuustheid van de berekende fixed price;

•

De mogelijkheden voor het CAK om de kengetallen en/of

correctiefactoren te weerleggen. Het aantal woorden dat gebruikt mag worden is bij voorkeur niet meer dan 500 Bij overschrijding van het aantal woorden kunnen niet relevante uitweidingen leiden tot puntenaftrek. W17. Wanneer gedurende de sprint blijkt dat de hoeveelheid werk meer is dan begroot, welke acties onderneemt u om binnen de afgegeven planning te blijven?

n.v.t.

Beoordeling:

INK12.214.4

pagina 31 van 33

19-12-2012

Beoordeling vindt plaats op basis van de volgende niet limitatieve lijst van beoordelingselementen: • Compleetheid van de beantwoording in relatie tot de wens; •


• De uitvoerbaarheid van de acties; Het aantal woorden dat gebruikt mag worden is bij voorkeur niet meer dan 500 Bij overschrijding van het aantal woorden kunnen niet relevante uitweidingen leiden tot puntenaftrek. W18. Hoe lang dient het Ontwikkelteam opgericht te zijn voordat het CAK eenzijdig kan eisen dat ontwikkeling op basis van fixed price worden afgerekend conform de in wens W16 opgegeven methodiek?

n.v.t.

Beoordeling: >= 12 maanden: 0 punten; >= 9 maanden < 12 maanden: 5 punten; > 6 maanden < 9 maanden: 10 punten.

4.7

Administratieve eisen inzet medewerkers

Voordat medewerkers van inschrijver hun werkzaamheden kunnen beginnen dienen een aantal zaken geregistreerd te worden bij het CAK. Nr.


Ja/Nee

Toelichting

Administratieve eisen inzet medewerkers E57. Bij aanvang van de werkzaamheden dient de medewerker van inschrijver de volgende zaken in te leveren danwel bij het CAK te ondertekenen: kopie paspoort (inleveren); verklaring medische gegevens (invullen); geheimhoudingsverklaring (tekenen); VOG (inleveren); Indien van toepassing een kopie VAR (inleveren)

n.v.t.

Een bewijs van aanvraag van de VOG dient binnen drie werkdagen na de start van de tijdelijke medewerker te zijn ingediend bij de ‘HR office’ van het CAK. Binnen vier weken dient de originele VOG in bezit te zijn van het CAK. Indien binnen deze termijn van vier weken de VOG (nog) niet is ingeleverd, dan kan de nadere overeenkomst worden beëindigd, zulks voor rekening en risico van leverancier De kopie VAR is alleen van toepassing indien inschrijver ZZP’ers inzet. Gedragsregels worden door het CAK uitgereikt. Daarnaast worden enkele medische gegevens geregistreerd die het CAK helpt in geval van calamiteiten. Het CAK realiseert zich dat het afgeven van deze medische gegevens door de tijdelijke ICT medewerker op vrijwillige basis gebeurt.

INK12.214.4

pagina 32 van 33

19-12-2012

5

Bijlagen bij het programma van eisen en wensen

Separaat zijn de volgende bijlagen bijgevoegd: Bijlage 1: Scrum handboek Bijlage 2: Interne procesbeschrijving ontwikkeling (Application Development proces v0.6) Bijlage 3: Template Contract Performance Rapportage (CPR) Bijlage 4: Voorbeeld definition of ready Bijlage 5: Voorbeeld definition of done Bijlage 6: Snel wegwijs voor externen en uitzendkrachten

INK12.214.4

pagina 33 van 33

19-12-2012

Programma van eisen en wensen Inzake de Europese aanbesteding Agile Ontwikkelteams met kenmerk INK

Recommend Documents