Ik heb vorige week het boekje "Getting Real" gelezen. Een aantal Tammo's kent dit boek al (verplicht leesvoer voor HNS heb ik begrepen), het beschrijft een methode voor internet software ontwikkeling en het zou me verbazen als er lezers zijn die er niet enthousiast van worden (al is het alleen maar door de aanstekelijke en zeer directe schrijfstijl). Bottom line: Houd projecten en producten zo simpel als mogelijk, liever iets af in twee weken met minimale functionaliteit (zodat je kunt starten) dan in 4 maanden met allerlei features die het succes van het product in de weg staan. Het levert de auteurs (37signals) zeer succesvolle producten op als BaseCamp als directe tegenaanval op de projectmanagementtools van MS (MS project en Sharepoint teamsites).
Met een aantal overcomplexe SharePoint projecten achter de rug klinkt het allemaal als muziek in de oren. Maar kan het ons ook lukken om terug te gaan naar de basis, en niets dan de basis? Een aantal voors en tegens:
Ja, dat kan:
- Wij doen de projecten, dus wij kiezen onze eigen methode;
- WPPA is tenslotte ook al een methode waarin simpel begonnen wordt en met behoud van de juiste moraal de complexiteiten iteratief worden toegevoegd;
- Want we zullen wel moeten, nu is de overdracht van met name SharePoint portals naar de organisatie veel te moeilijk, en de back-to-basic benadering is de enige uitweg hierin;
Nee, dat kan niet:
- In tegenstelling tot bij de auteurs bouwen we niet onze eigen producten. We zijn dus niet in charge waar het gaat om de te bouwen features. Deze liggen al vast in de offerteaanvraag, of moeten aansluiten bij bestaande (en vaak complexe) processen in de organisatie;
- We hebben een functionele specificatie op papier nodig, want elk punt dat niet is uitgewerkt levert aan het eind van het traject discussie op en een kans op een afloop die slecht is voor het projectrendement;
- De enige mogelijkheid om met een dergelijke insteek een project te doen is op basis van budget-, of time boxing. Deze methode vraagt een bijna profetische inzicht aan de projectleider en de projectdeelnemers (hoe lang zijn we na de bouw bezig met fixen van issues als we nu met ontwerpen gaan stoppen) en blijkt indien toegepast steeds weer niet aan te sluiten bij de belevingswereld van de stakeholders, waarvoor iedere teruggang in functionaliteit als teleurstelling wordt ervaren.
Vooralsnog zie ik in het laatste rijtje dat elke stap die we in de richting van Getting Real willen zetten gepaard moet gaan met heropvoeding van de klant:
- Het liefst al voordat ze bij ons komen, zodat het niet in de salesfase al mis gaat door expliciet de functionaliteit vast te leggen.
- We moeten klanten overtuigen dat minder functionaliteit een weg is naar succes.
- We moeten het vertrouwen winnen bij de klant zodat een functioneel voorstel niet als contract gebruikt hoeft te worden.
- We moeten deliverables op zo'n manier te omschrijven dat de klant los van de functionaliteit toch houvast heeft en ons op het resultaat kan afrekenen.
Klinkt als een lang en complex project 
Stapje voor stapje dus maar weer, bewustwording is de eerste. Bij deze.