Een eigen tool bouwen: waar moet je rekening mee houden?
Ieder (complex) project vraagt om ondersteuning bij het samenwerken en het opslaan, delen en terugvinden van belangrijke informatie. Online ritselt het van de apps en de tools die hierbij helpen. Sommige zijn erg algemeen, anderen juist specialistisch. Wij zijn groot voorstander van het gebruiken van die bestaande tools. Want waarom zelf het wiel uitvinden als anderen het al slim hebben bedacht? Maar, soms kom je er met standaard niet uit. En daarom maakten we de gedurfde keuze om zelf een tool te ontwikkelen. In dit artikel delen we de lessen die we hebben geleerd tijdens het traject.
Ons bureau is gespecialiseerd in professioneel belangenmanagement in onder andere infrastructuur, beleid en zorg. De projecten waaraan we werken, zijn meestal groot en hebben veel stakeholders met ieder hun eigen belangen. De betrokken partijen variëren van ministeries en bedrijven, tot individuen. Om in deze complexe omgeving te komen tot een gedragen oplossing, werken we volgens onze SOM-methode. We zijn een klein team met daar omheen een flexibele schil van adviseurs. Adequate informatie-uitwisseling, intern en extern, is belangrijk. En als we onze positie in de markt willen behouden, moeten we de methode slimmer ondersteunen dan met Word- en Excel-documenten.
Een eigen tool?
Tijdens de projecten die we tegenkomen wordt binnen een korte tijd veel informatie verzameld over issues en stakeholders die een rol spelen. Er worden historische gegevens in kaart gebracht, maar ook de mate waarin stakeholders invloed uitoefenen, of er ‘hot’ items zijn in de media en of het gaat om een emotioneel beladen onderwerp. Deze wirwar aan informatie wordt met elkaar in verband gebracht, geanalyseerd en voorzien van een passende strategie. De tools die we kenden waren daarvoor niet toereikend: ze konden slechts voorzien in een deel van dit proces of vereisten complex maatwerk.
Van scratch beginnen en zelf iets bouwen, leek ons daarom in dit geval een beter idee. Voor zo’n kleine organisatie is die keuze risicovol, want het vergt een grote investering ten opzichte van het inzetten van (vaak goedkope) online tools. De tool moet doelgericht bijdragen aan de ‘core‘ dienstverlening, om van toegevoegde waarde te zijn voor klanten en de investeringskosten terug te verdienen. Het doel van de ontwikkeling bestond uit:
- Tijd besparen door informatie één keer in te voeren
- Nuttige informatie bewaren en slim hergebruiken voor andere projecten
- De bestaande methode breder in organisaties verankeren, niet alleen de direct betrokkenen werken er mee, maar het hele projectteam.
- De resultaten van de analyses overzichtelijk presenteren en voortgang inzichtelijk maken
- Met deze bovenstaande punten het professioneel belangenmanagement optimaliseren en daarmee bijdragen aan het halen van projectdoelstellingen.
En, het ligt voor de hand maar wordt vaak vergeten: het moest een oplossing worden die gebruikers willen gebruiken!
Snel schakelen, intensief samenwerken en helderheid
Om niet te verzanden in een oneindig ontwikkeltraject en een bodemloze put van kosten, kozen we met ons kleine team voor een flexibele aanpak van snel schakelen, intensief samenwerken en helderheid over verwachtingen. Onderstaande lessen hebben wij geleerd tijdens het traject:
1. Kijk door de bril van de gebruiker
Voorafgaand aan het traject hebben we klanten gevraagd naar wat zij zochten in een ondersteunende tool. Maar ook tijdens het traject hebben we klanten steeds gevraagd om mee te denken en te doen. Dat was niet altijd makkelijk, want je wilt (juist aan je eigen klanten!) graag iets laten zien wat af is. We zijn er van overtuigd dat we, door onszelf te dwingen dit toch te doen, een tool hebben gemaakt die beter past bij de behoefte van de eindgebruiker. En daarmee is voor ons ook de kans op wederverkopen van de tool vergroot.
2. Stel prioriteiten
Wat doen we nu en wat kan later? Dat is een vraag die we vaak hebben gesteld. Dat was ook hard nodig, want voordat je het weet begint de lijst met wensen uit te dijen en ben je bezig een allesomvattende softwareoplossing te bouwen. Dat was nu net niet de bedoeling! Dus prioriteren, herrijken en wensen in ‘de ijskast’ zetten.
En hoe we ook ons best hebben gedaan, achteraf gezien hebben we toch teveel tijd besteed aan functionaliteiten die niet de kern vormen van ons werk, bijvoorbeeld een agenda en takenlijst. We zouden nu meer plezier hebben van twee extra rapportages. Pas als je het echt gebruikt, kom je er achter wat belangrijk is. Een volgende keer zouden we de tool nog sneller in gebruik nemen, om te ervaren welke functionaliteiten we missen en die vervolgens toe te voegen.
3. Houd het vizier op de toekomst gericht
In een ontwikkeltraject is het soms lastig om verder te kijken dan de dagelijkse ontwikkeling van de tool. Maar om de tool verkoopbaar op te zetten dwongen we onszelf om in de toekomst te blijven kijken. Een aantal onderwerpen is moeilijk, zoals beveiliging van gegevens en de koppeling met applicaties die klanten zelf gebruiken, waardoor het gauw van het vizier verdwijnt. Maar ze kunnen wel doorslaggevend zijn voor klanten om het in hun organisatie in te zetten.
We hebben de beveiliging en de koppeling met applicaties gedurende het traject bij de kop gepakt en er voor gezorgd dat er in de ontwikkeling rekening gehouden is met toekomstige wensen van klanten. Denk bijvoorbeeld aan de mogelijkheid om met SharePoint te koppelen. Die koppeling zelf is nog niet ontwikkeld, maar door de juiste keuze voor techniek te maken, is dat in de toekomst wel mogelijk.
4. Testen, testen, testen…
Om een tool spic en span op te leveren, is veel en uitgebreid testen noodzakelijk. Dat hebben we vooral aan het einde van het traject te weinig gedaan. Maanden later kwamen we nog relatief veel bugs tegen, waarvan best een aantal door onze klanten werd aangedragen. Met een grondig testplan en een aantal dagen dedicated testen, hadden we dat kunnen voorkomen.
Het resultaat
Onderstaande afbeeldingen geven een impressie van SOM SET, de tool die we gebouwd hebben.
A hell of a job!
De ontwikkeling van deze app was ‘a hell of a job‘. We hebben vooraf onderschat hoeveel werk het is! Ook hadden we meer tijd nodig dan gedacht om de inhoudelijke kennis van onze werkwijze over te dragen aan het ontwikkelteam, om te komen tot een waardevolle tool.
Maar het was ook ‘a hell of a job’ omdat het resultaat er zeker mag zijn! Onze klanten en wij zijn heel tevreden met het resultaat. De reacties zijn positief. Klanten geven aan dat deze tool het werken met onze methode vergemakkelijkt en de tijdsinvestering vermindert. Daar zijn we trots op! Het heeft geleid tot meer duidelijkheid en uniformiteit, en dus ook een hogere kwaliteit van de analyses. Natuurlijk blijven er wensen voor verbeteringen, maar we hopen dat we die, juist vanwege de aanpak en geleerde lessen, in de toekomst samen met klanten en met de partijen met wie we hebben samengewerkt, snel en slim kunnen realiseren.
Herken je onze obstakels? Wat zijn jouw ervaringen met het ontwikkelen van eigen tools, in plaats van bestaande oplossingen gebruiken?
SOM SET is ontworpen en gebouwd door Mixit en Xuntos voor WesselinkVanZijst. Foto intro met dank aan Fotolia.