1. Home
  2. Blog
  3. ‘One size fits all’? Ga toch weg!

‘One size fits all’? Ga toch weg!

Het verschil tussen een goede wijn en een topwijn zit hem in de nuance. Dat geldt ook voor de aanpak van een IT project. Generaliseren blijkt een verraderlijke valkuil. Er zijn wel degelijk verschillen, hoe subtiel ook. Het ene kantoor is nou eenmaal het andere niet. En dat geldt uiteraard ook voor leveranciers en de oplossingen die worden geboden. Tijd om de ‘one size fits all’ mythe te ontkrachten. 

Als ik iets geleerd heb in de 15 jaren dat ik projecten uitvoer voor advocatenkantoren, is het wel dat het missen van enige nuance in deze branche al snel leidt tot totale verontwaardiging.  

 

Een voorbeeld 

Een kantoor is teleurgesteld in de leverancier van een softwarepakket. Er is niet geleverd wat volgens het kantoor was afgesproken. De leverancier begrijpt vervolgens niets van de ontsteltenis en van de commotie die daarop volgt. 

Iedereen kan zich vast een beeld vormen van een dergelijke situatie. Het is te gemakkelijk om dan maar te zeggen dat beide partijen beter hadden moeten communiceren en verwachtingen hadden moeten managen. Vooral als blijkt dat ze niet exact dezelfde taal spreken en zelfs in een totaal andere belevingswereld opereren. Dat is gewoonweg niet altijd direct duidelijk voor partijen en daar sta je dan met je beste intenties.  

Aannames: de moeder van alle blunders 


Het maakt niet uit of je nu wel of niet gehinderd wordt door enig besef van de heersende rangorde en kantoordynamiek. En wie je beter niet op de tenen kunt trappen als je danst met complexiteit en tegenstrijdige belangen. Zolang je maar probeert om aannames te voorkomen. Ze zijn de doodsteek voor elk project. Daarom de top 5 van veelvoorkomende aannames op een rij. 

 

De 5 meest voorkomende aannames binnen IT-projecten 
 

Aanname 5: We spreken dezelfde taal
Iedereen die iets te verkopen heeft, zorgt ervoor dat hij/zij de taal van de doelgroep spreekt. Dat moge duidelijk zijn. Maar dat wil nog niet zeggen dat je elkaar ook echt begrijpt. Dit is niet alleen van toepassing op de relatie tussen het kantoor en de leverancier, maar ook intern. Wordt het doel, het gewenste resultaat en wat daarvoor gedaan moet worden door iedereen op dezelfde wijze geïnterpreteerd? Is het ook duidelijk wie, wat, wanneer doet en wat de consequentie is als het niet gebeurt?  

 

Aanname 4: Gedoe moet worden voorkomen 
Een project zorgt per definitie voor een verandering, hoe klein dan ook. Zodra er echter gedoe ontstaat, wordt er met man en macht geprobeerd dit de kop in te drukken en worden projecten zelfs gestopt. Terwijl gedoe aangeeft dat het project serieus genomen wordt. Waarom zou je je anders druk maken? Moet er iets veranderen en spreken de aanjagers dezelfde taal? Anticipeer dan op gedoe. Zonder wrijving geen glans. 

 

Aanname 3: We weten wat we doen 
De werkprocessen die een project raakt, moeten opnieuw beschreven worden. Maar er wordt lang niet altijd goed nagedacht over hoe die processen daadwerkelijk lopen en welke problemen zich daarbij voordoen. Terwijl het juist dié problemen zijn, die het project dient op te lossen. Een leverancier kan hier overigens lang niet altijd bij helpen. Zie het als een chef-kok die in een vreemde keuken een culinair hoogstandje moet bereiden. Dat kan alleen als iedereen weet wat er wanneer verwacht wordt en er toegang is tot de juiste middelen op het juiste moment.    

 

Aanname 2: Het kan er prima bij gedaan worden 
Bij de start van een project wordt vaak heel enthousiast een representatieve samenstelling van medewerkers gezocht. Maar een representatieve afspiegeling is niet genoeg. Een interne projectleider benoemen, die managen zonde van zijn tijd vindt, of teamleden laten aanhaken zonder commitment, tijd en kennis is onzinnig en contraproductief. Niet iedereen beschikt over de juiste vaardigheden om een nuttige bijdrage te kunnen leveren aan een degelijk project. En degenen die daar wel over beschikken, moeten daar dan ook voor vrij gespeeld worden.  
 

En met stip op nummer 1 van veel voorkomende aannames: one size fits all

 

Er bestaat altijd een spanning tussen eigenbelang en het belang van de groep. Het is zaak te zoeken naar een goede balans. Dit is voor elk kantoor anders en een delicaat proces. Acceptatie leidt tot inbedding van de nieuwe situatie in de organisatie. Voor elk project geldt dus dat de mate van gebruikersacceptatie bepaalt of het project een succes is of niet. Ervaring heeft mij geleerd dat het verschil maar al te vaak in de nuance zit.  

Kijken we even terug naar de hierboven genoemde aannames 5 tot en met 2. Wil je deze voorkomen dan horen daar de volgende controlevragen bij om verder uit te werken: 

 

  • Wat is het doel, het gewenste resultaat en wat moet daarvoor gedaan worden? Is dit voor iedereen onmiskenbaar duidelijk? 
  • Is er aandacht voor gedoe dat voortkomt uit de individuele verschillen in beleving? Op welke wijze wordt dit geadresseerd? 
  • Zijn werkprocessen duidelijk en uitvoerig beschreven en is er zicht op de knelpunten die opgelost moeten worden? 
  • Beschikt iemand intern over de nodige vaardigheden om het project te leiden? En is er intern de nodige kennis om input te leveren voor het project? Kan voor deze personen voldoende tijd hiervoor vrijgemaakt worden?   

 

De invulling van deze vragen is voor elk kantoor verschillend. Maar een ‘one size fits all’-softwarepakket of een ‘one size fits all’ invoeringsproject biedt nauwelijks tot geen ruimte hiervoor. Als het gaat om een softwarepakket dan is een ‘one size fits all’-pakket voor de wat kleinere kantoren vaak nog prima inzetbaar, maar ook absoluut niet voor alle kantoren! Ik zou dus hoogstens spreken van een ‘one size fits many’-pakket. Als het echter gaat om de invoering van een – ongeacht welk –  softwarepakket, durf ik na al die  jaren zonder meer te zeggen dat niet één zo’n project hetzelfde is. Er zijn nou eenmaal verschillen, hoe subtiel ook. Als je dat niet erkent, ga je ook voorbij aan het onderscheidend vermogen van kantoren waar tegenwoordig zo hard aan wordt gewerkt.  
 
Wat mij betreft mag dus de ‘one size fits all’-mythe op nummer 1 van de lijst met veelvoorkomende aannames. 

 

Durf te differentiëren 


Door relevante verschillen te vinden, kun je differentiëren en het onderscheidend karakter van kantoor benadrukken. Het is niet voor niets dat steeds meer kantoren een externe projectmanager inschakelen om de gewenste resultaten te bereiken. Een externe projectmanager kan een effectieve vertaalslag maken tussen vraag en aanbod en levert meerwaarde voor zowel een kantoor als een leverancier. Het is bij voorkeur iemand die de taal van het kantoor én van de leverancier machtig is. Iemand die in staat is om te differentiëren en de broodnodige nuance aan te brengen. Iemand die waakt voor aannames en functioneert als verbindingsschakel tussen de business en IT. Maar dan wel iemand die op basis van ervaring en kennis van de markt en haar spelers weet wat er te (be)halen valt.

 

Groet, Marjan

System.FormatException: String "1151" is not a valid udi.
   at Umbraco.Core.Udi.ParseInternal(String s, Boolean tryParse, Boolean knownTypes, Udi& udi)
   at Umbraco.Core.Udi.Parse(String s)
   at System.Linq.Enumerable.WhereSelectArrayIterator`2.MoveNext()
   at System.Linq.Buffer`1..ctor(IEnumerable`1 source)
   at System.Linq.Enumerable.ToArray[TSource](IEnumerable`1 source)
   at Umbraco.Core.Models.PublishedContent.PublishedPropertyType.ConvertSourceToInter(IPublishedElement owner, Object source, Boolean preview)
   at System.Lazy`1.CreateValue()
   at System.Lazy`1.LazyInitValue()
   at Our.Umbraco.DocTypeGridEditor.Models.DetachedPublishedProperty.<.ctor>b__7_1()
   at System.Lazy`1.CreateValue()
   at System.Lazy`1.LazyInitValue()
   at Our.Umbraco.DocTypeGridEditor.Models.DetachedPublishedProperty.GetValue(String culture, String segment)
   at Umbraco.Web.PublishedPropertyExtension.Value[T](IPublishedProperty property, String culture, String segment, Fallback fallback, T defaultValue)
   at Umbraco.Web.PublishedElementExtensions.Value[T](IPublishedElement content, String alias, String culture, String segment, Fallback fallback, T defaultValue)
   at Lime.Core.Models.RoundImagePicker.get_RoundImage()
   at ASP._Page_Views_Partials_DTGE_grid_roundImagePicker_cshtml.Execute() in C:\home\site\wwwroot\Views\Partials\DTGE\grid_roundImagePicker.cshtml:line 4
   at System.Web.WebPages.WebPageBase.ExecutePageHierarchy()
   at System.Web.Mvc.WebViewPage.ExecutePageHierarchy()
   at System.Web.WebPages.WebPageBase.ExecutePageHierarchy(WebPageContext pageContext, TextWriter writer, WebPageRenderingBase startPage)
   at Umbraco.Web.Mvc.ProfilingView.Render(ViewContext viewContext, TextWriter writer)
   at System.Web.Mvc.Html.PartialExtensions.Partial(HtmlHelper htmlHelper, String partialViewName, Object model, ViewDataDictionary viewData)
   at Our.Umbraco.DocTypeGridEditor.Web.Extensions.HtmlHelperExtensions.RenderDocTypeGridEditorItem(HtmlHelper helper, IPublishedElement content, String editorAlias, String viewPath, String previewViewPath, Boolean isPreview)
   at ASP._Page_app_plugins_doctypegrideditor_render_DocTypeGridEditor_cshtml.Execute() in C:\home\site\wwwroot\app_plugins\doctypegrideditor\render\DocTypeGridEditor.cshtml:line 28
   at System.Web.WebPages.WebPageBase.ExecutePageHierarchy()
   at System.Web.Mvc.WebViewPage.ExecutePageHierarchy()
   at System.Web.WebPages.WebPageBase.ExecutePageHierarchy(WebPageContext pageContext, TextWriter writer, WebPageRenderingBase startPage)
   at Umbraco.Web.Mvc.ProfilingView.Render(ViewContext viewContext, TextWriter writer)
   at System.Web.Mvc.Html.PartialExtensions.Partial(HtmlHelper htmlHelper, String partialViewName, Object model, ViewDataDictionary viewData)
   at ASP._Page_Views_Partials_grid_editors_Base_cshtml.Execute() in C:\home\site\wwwroot\Views\Partials\grid\editors\Base.cshtml:line 20

Marjan Hermkes

Marjan is een specialist op het gebied van ICT & innovatie. Als geen ander is zij in staat een brug te slaan tussen IT en de gebruiker. Met een vakkundige kijk vertaalt zij mogelijkheden naar uw bedrijfsvoering en werkprocessen.

LEES MEER OVER MARJAN