Sprint/oplevering

Een websysteem implementatie voor een grotere organisatie is vaak complex. De Frameworks zijn in de kern zeer uitgebreid en eenvoudig uitbreidbaar. Veiligheid en beschikbaarheid van een eindoplossing moet steeds in de gaten worden gehouden. We hebben te maken met veel betrokken functionarissen en systemen. Een bestaand systeem vaak ook met deels nog actuele content en functionaliteit. De grote vraag van elk individu (vanuit hun eigen rol (!)) is dan ook altijd:

WAT KRIJGEN WE NU EIGENLIJK WANNEER?!

Uitgangspunt

Een klant heeft een RFP geschreven met daarbij bijlagen. De leverancier heeft in grote lijnen gecommuniceerd:

1. wat wel en niet kan
2. hoe de requirements worden ingevuld
3. welke randvoorwaarden er gesteld worden
4. wat het kost
5. wanneer het geleverd kan worden

So far so good.

Wat kan er gebeuren?

1. de geleverde informatie is minder compleet dan aangenomen
2. de informatie is tegenstrijdig op inhoud
3. de informatie is al achterhaald door voortschrijdende tijd
4. de vorm is ongeschikt om te communiceren naar alle betrokkenen

DAAROM IS EEN GEZAMENLIJKE BASIS VAN RAPPORTEN OP INHOUD BELANGRIJK

Vaste aanhaakpunten

Er zijn een aantal in zekere mate vaste punten om op aan te haken:

Functionaliteit

Het Framework waarin het systeem wordt gemaakt

De organisatie doelstellingen

Het bestaande systeem

De indeling in sprints

2Value implementatiemethode

2Value's(intern en extern) overeen gekomen richtlijnen.

Variabel

Zie Variabele vluchtige elementen in een webimplementatieproject.

Functionaliteit

Wat 2Value heeft aangeboden heeft een 1 op 1 aansluiting op de aanvraag/RFP van de klant. (zie voor meer Contractmanagement en Bevindingen. Een gegeven is de inhoud, een ander gegeven is wanneer dat wordt gedaan en tot resultaat leidt en de case in de casetracker

In de casetracker wordt het proces gevolgd en de inhoud centraal geregistreerd, aangevuld, becommentarieerd, werk verdeeld, en de status wordt bijgehouden.

Belangrijk is om het aanbod voorop te stellen: Wat krijgen we?!

Draaitabel

Om helder aan te geven wat de klant krijgt,

1. gebruiken we normale mensentaal; technische verhandeling naar de achtergrond als normale mensentaal niet specifiek genoeg is en tot verkeerde verwachtingen e.a. onduidelijkheden kan leiden
2. staat de functionaliteit voorop
3. de verbinding naar de actuele case EN genummerde requirement(s) staat in aparte kolommen erbij.

Aanvullende uitdagingen voor een leverancier

1. "Garbage in, garbage out" De leverancier laat de resultaten zien. Ook de kwaliteit en kwantiteit van de tussenresulaten. Dat leidt wel eens tot teleurstellingen over inhoud die aan het adres van de boodschapper worden geuit.
2. Resources: zonder volledig bronmateriaal kan een bouwer van websystemen zijn/haar werk niet doen. Of moet het vaak herhalen. Om dat laatste te voorkomen gaat 2Value pas aan het werk als de resources er zijn. Dat past ook binnen de projectmanagement aanpak die wij adopteren: de zwakste schakel als uitgangspunt.
3. Honderden pagina, duizenden details: In een aanbiedingsfase investeert de leverancier voor in de aanbieding en in de relatie om een opdracht gegund te krijgen. Het is echter nooit en te nimmer mogelijk om alle details van aanleveringen en ingangsdocumenten te beoordelen. De verantwoording voor de sluitende aanlevering, zodat een leverancier er wat mee kan, ligt bij de opdrachtgever. Maar leg dat maar eens uit.