Training van molenwiekende klanten: 9 facetten

22 Oct 2014

Joris Snoek - Business Dev
+31 (0)20 - 261 14 99

Hoewel het in mijn achtertuin was, kon ik helaas niet bij DrupalCon Amsterdam zijn. Dit vanwege oplevering van een groot Drupal project die week. Dat was een gaaf project om aan te werken, dus eerlijk gezegd: zo erg vond ik het ook weer niet. Over enkele maanden staat Drupalcon Bogotá op mijn agenda, veel leuker dan Amsterdam ;)

Én.. alle video's van DrupalCon Amsterdam staan toch online, thanks to the Drupal Association.

Hierin heb ik een aantal alle interessante video's inmiddels doorgespit. En voornamelijk deze vond ik interessant: DrupalCon Amsterdam 2014: Train Wrecks & Ugly Baby Client Meetings. Mijn feest der herkenning vierde hoogtij.

Een deel van die video gaat over klant training. De toelichting van Susan Rust spreekt boekdelen en overlapt voor overgroot deel mijn visie in deze context.

Een uiteenzetting, aangevuld met enkele eigen inzichten:

Molenwiekende klanten

Klanten waarbij het interne proces zwak (of helemaal niet) opgezet is: daar zullen de project managers altijd wild rondrennen, hopen op het beste en uiteindelijk hun frustraties botvieren op klanten, leveranciers en medewerkers.

Dat doen ze omdat dat het beste is wat ze kunnen doen, dan is nou eenmaal hun 'toolset': gewoon gaan, trial en error uitvoeren en hopen dat alles goed komt.

Dit is zeker niet bij alle (potentiële) klanten het geval. Maar bij degene waar dit wél het geval is, daar probeer ik het in vroeg stadium te ontdekken. Voordat ik me commiteer aan een samenwerking.

Molenwiekende klanten sla ik absoluut niet meteen af: die zal ik moeten trainen. In hoe het wél succesvol kan werken. En daardoor alsnog een mooi project draaien en een duurzame relatie opbouwen.

9 facetten om molenwiekende klanten te voorkomen

Een overzicht van onderdelen waar een klant op voorbereid moet zijn, voordat ik een groot web project met hem aanga.

1) Reserveren uren

Om een grove indicatie te geven: als ik 800 uur begroot, dan zal de klant minstens de helft (400 uur) gereserveerd moeten hebben om het project te draaien. Ik vraag de klant om veel huiswerk te doen, maar dit is nou eenmaal noodzakelijk voor een succesvol webproject.

Er bestaat geen succesvol web-project, waarin de klant heeft gezegd: "Bel me maar als het klaar is”. Als ik signalen in die richting krijgt, dan gaat er meteen een big-ass red flag omhoog ;)

Klanten die zo denken zal ik dus moeten trainen, anders is het de achterdeur uit. Letterlijk.

2) Risico parameters

Voordat ik start aan een project probeer ik voor alle belangrijke parameters bij de klant een soort van 'risico rate' toe te kennen. Is het een start-up die wil vlammen? Of is het een pre-historische organisatie waarbij álle beslissingen langs een board moeten?

Dus ik probeer er achter te komen wat voor organisatie het is, wat voor risico's ze durven te nemen en waarvoor ze risico willen nemen.

3) Proces training

Hoe werken wij? Hoe past de klant daarin? Passen zij daar überhaupt wel in? Welke afspraken maken we over het samenwerkingsproces?

Dit gesprek heb ik voordat ik start aan een project, dan kan ik hier later op terugvallen. Als klantje opeens bad customer gaat hangen, dan geef ik aan: "Weet je nog toen we het hadden over ons samenerkingsproces, welke afspraken we hebben gemaakt? Wij hebben ons daaraan gecommitteerd, omdat dat tot succes leidt. Wij houden ons daaraan, jullie ook weer?"

En verder toelichten:

  • Hoe werkt scrum, hoe werkt een sprint.
  • Wat is de volgende fase.
  • Omgang met scope creep.
  • Wanneer is iets meerwerk.
  • Wat is 'technisch schuld' (technical debt).
  • Quality Assurance proces bij de klant (QA).
  • Acceptatie testen door de klant: user acceptance testing (UAT).
  • Deployment in OTAP omgeving (Ontwikkel-, Test-, Acceptatie- en Productieserver).

4) Burn rate

Ik overleg vooraf wat onze 'burn rate' is: wat kost een conference call, of een meeting (denk hierin aan ~ € 700,- per uur). We willen graag zoveel van deze meetings/calls houden als klant wenst, maar weet wel dat er € 700,- / uur wordt verrekend met je budget.

Geef hierin soms een beetje marge: de eerste 10 minuten zijn vrijblijvend, daarna gaat de 'burn rate klok' lopen. Op deze manier zul je nooit meer een 2 uur durende meeting of conference call hebben.

Een 2 uur durende meeting tijdens ontwikkelfase is sowieso een slecht teken: waarschijnlijk is er niet genoeg tijd besteed aan discovery & research.

5) Lancering website

Grote bedrijven hebben vaak een zeer strict server beleid. Wanneer het een internationaal bedrijf betreft, heb je zelf kans dat hosting is ge-outsourced naar bv India. Uit ervaring weet ik dat dit proces zeer stroperig kan zijn.

Ik zorg dus dat we van tevoren goed in kaart hebt, hoe lancering gaat plaatsvinden. Denk aan:

  • Welk team doet dit?
  • Welke omgeving?
  • Inlog gegevens en wat is het beleid hierin?
  • Welk proces is van toepassing op die omgeving?
  • Zijn er goedkeuringen nodig?
  • Hoe lang van te voren moet iets aangevraagd worden?
  • Is het een shared / dedicated?
  • Kan je optimalisatie applicaties gebruiken (bv Solr, Memcache en Varnish), welke versies en hoe is dat ingericht?
  • Worden er security tests gedaan, voordat de installatie live mag? Wat is het beleid hierin?

6) Training in Drupal

  • In hoeverre moet de klant getraind worden: alleen content management, of ook configuratie management, of zelfs applicatiebeheer?
  • Drupal heeft periodiek onderhoud nodig, hoe ga je daarmee om?
  • Drupal kent ook zijn bottlenecks, ik geef aan hoe we hiermee omgaan.
  • Contrib modules vs maatwerk.
  • Hoe is ons proces in implementatie van design.
  • Hoe is ons proces in implementatie van HTML / JS

7) Training in financiën

  • Hoe facturere we?
  • Hoe ga we om met budgetteringen?
  • Omgang met meerwerk.
  • Betaling laatste termijn.
  • Garantieperiode en omgang met bugs hierin en hierna.
  • Wat kost een extra gewenste deploy?

8) Wat verder ten tafel komt

  • Content deadlines.
  • Inrichten project team.
  • Omgang met communicatie tools & ticketing.
  • Wekelijkse meetings.
  • Wekelijkse QA (Quality Assurance).
  • Klant moet zich committeren aan het reserveren van genoeg tijd.

Wrap up

De laatste ‘…’ staat voor: ik kan boeken vol schrijven over bad customers en klant training. Maar bottom line is: herken een bad customer op tijd, train ze goed en laat ze hierin aan committeren. Of bonjour ze zeer vriendelijk de achterdeur uit.

Comments

Nóg meer
kennis nodig?

Check ons ons blog archief >