SharePoint

De Business is de Beperkende Factor

20 januari 2012

“Zeg Ellen, kan deze site over 2 weken klaar zijn voor gebruik?” vroeg een opdrachtgever wel eens.
“Wat mij betreft wel”, zei ik dan altijd, “maar ik heb geleerd dat de business, jij dus, de beperkende factor is”.
De opdrachtgever keek dan altijd een beetje vreemd.
Het is natuurlijk heel begrijpelijk dat iemand zijn of haar nieuwe site snel wil gaan gebruiken. Vaak is er een probleem, of een goed idee, en dat wil de opdrachtgever zo snel mogelijk opgelost of in werking hebben. Iemand anders doet de configuratie van de site,
als opdrachtgever geef je wat controle uit handen, en het is dus heel logisch dat je afstemt wanneer het af is. We hebben allemaal projectmanagement gedaan, toch?

Maar de opdrachtgever heeft natuurlijk ook zijn of haar eigenlijk werk, en dat gaat altijd voor. Er moeten producten gemaakt en verkocht worden, er moeten klanten worden bezocht, en rapportages gemaakt. Daarnaast weet een opdrachtgever niet precies wat er
van hem of haar verwacht wordt. Zij/hij geeft een briefing, ik begrijp precies wat ze willen, en het is over 2 weken klaar, is de heersende gedachte.

Helaas is dat niet altijd het geval. Ik kan iets niet goed begrepen hebben, functionele eisen
moeten soms een beetje anders worden ingewilligd dan verwacht en hebben dan bepaalde consequenties, of het blijkt dat het proces in de werkelijkheid toch net even wat anders loopt dan was gebriefd. Kortom: je moet regelmatig met de opdrachtgever afstemmen en
hij/zij moet ook testen of het voldoet aan de eisen en inpasbaar is in het proces.

Hoe hebben we geprobeerd om dit in goede banen te leiden?
[listdot]

  • We gaven vooraf aan wat hun verantwoordelijkheden waren, zoals het geven van informatie zodat wij een kleine business case konden maken, testen, en het introduceren van de site bij hun doelgroep. (Dagelijks beheer konden ze eventueel uitbesteden).
  • Als er alternatieve oplossingen waren, maakten we die zoveel mogelijk meteen, zodat ze meerdere oplossingen tegelijk konden testen.
  • We legden uit wat “testen” precies betekent.
  • We spraken meteen af wanneer ze tijd moesten inplannen om te testen.
  • We vertelden hen dat we, na een gemiste deadline van hun kant, geen garanties meer konden geven op de timing van finale oplevering.

[/listdot]

Vooral de laatste 2 punten leverden meestal direct een wat langere oplevertermijn op :-). Overigens waren die 2 weken niet echt gek; we hebben zelfs wel eens iets opgeleverd binnen 2 dagen. We hebben ook wel eens 6 maanden over een configuratie gedaan, maar
dat was dan ook een hele zware configuratie, een heel belangrijk proces en met een opdrachtgever in Australië. En er zijn zelfs wel projecten geweest van een jaar maar die hadden dan meestal een “Onwillige” als opdrachtgever.
Over het algemeen was de echte “in-elkaar-klik-tijd” voor ons een paar uur, maar de totale doorlooptijd een week of 4.

Hebben jullie nog tips om realistische verwachtingen van de business te bewerkstelligen?

Dit is het tweede deel van de “leerpunten” van onze centrale configuratie–service. Het eerste deel is “De 80-120 regel”.

You Might Also Like

Geen reacties

Plaats een reactie