We hebben de neiging om nieuwe technologie te behandelen, zoals de Heilige Graal, een baken van licht en het antwoord op alles wat langzaam, inefficiënt en oud is. En dat kan ook - als het wordt geïmplementeerd met een vrachtwagen vol planning en vooruitziende blik.
Maar goed, we weten allemaal hoe dat gaat.
Tijdens mijn regeringsjaren, waar het soms voelde alsof we een spel van technologische inhaalslag speelden dat onmogelijk te winnen was, leerde ik wat er kan gebeuren als deze vooruitziendheid als vanzelfsprekend wordt beschouwd. Het lijkt iets minder op de Heilige Graal en veel meer op kostenoverschrijdingen, vertragingen en ingewikkelde oplossingen voor anders eenvoudige problemen.
Zoals ik heb geleerd, is een van de belangrijkste sleutels tot een succesvol technologieproject de harmonieuze relatie tussen het zakelijke team en het technologieteam. Mijn ervaring was dat het zakelijke team vaak de verandering aanstuurde (we hebben bijvoorbeeld een complexer systeem nodig om de federale subsidie-uitgaven te volgen), maar we konden geen kleine vooruitgang boeken zonder de ontwikkelaars en IT-projectmanagers die het konden maken gebeuren. Projecten eindigden vaak verre van harmonieus, het resultaat van in wezen verschillende talen spreken en het handhaven van enorm verschillende verwachtingen (een verandering die mij bijvoorbeeld klein leek, bleek vaak belangrijk voor de ontwikkelaars).
Maar business en technologie kunnen - en moeten - vrienden zijn. Het goede nieuws? Harmonie bereiken is echt niet zo ingewikkeld. Zoals elke samenwerking heeft het te maken met de frequentie en kwaliteit van communicatie, een onderling overeengekomen reeks doelen en een plan voor het aanpakken van de bijna onvermijdelijke verschuiving van die doelen. Hier zijn een paar basisrichtlijnen om de kloof tussen bedrijfstechnologie te beheren.
1. Probeer de vereisten de eerste keer vast te leggen
Beschouw zakelijke vereisten als een blauwdruk. Je zou geen schetsmatige set blauwdrukken voor een huis tekenen, ze bij de aannemer afleveren en hem geluk wensen. Je zou niet terugkomen drie weken in de bouw en hem vragen om een derde verdieping en een vierde badkamer toe te voegen, en misschien een erker in de woonkamer. En je zou zeker niet je blauwdrukken tekenen zonder de input van een architect en een ingenieur.
Een technologieproject is niet zo anders. Het moet met precisie worden ontworpen, en zodra het ontwikkelen begint, is het niet altijd gemakkelijk om wijzigingen aan te brengen zonder de hele basis te beïnvloeden. Daarom is het cruciaal om vanaf het begin zo uitgebreid mogelijk te zijn en de input en expertise te krijgen die u nodig hebt terwijl u nadenkt over wat de oplossing nodig heeft. Interview eindgebruikers om inzicht te krijgen in de uitdagingen waarmee ze worden geconfronteerd en hoe ze de nieuwe technologie precies moeten gebruiken. Maak geen aannames en laat geen delen van de planning achter voor later.
2. Maar erken dat je er een paar zult missen
Dat gezegd hebbende, vond ik het bijna onmogelijk om alle functies voor te stellen die we nodig hadden tijdens de abstracte planningsfasen. Als het systeem eenmaal in ontwikkeling was, realiseerden we ons onvermijdelijk dat we vergaten te vragen om een geavanceerde zoekfunctie of een knop 'opslaan en doorgaan'. Toen we de ontwikkelaars benaderden om hen vriendelijk te vragen om aan deze nieuwe verzoeken te voldoen, stuitten we vaak op frustratie. Misschien zou de nieuwe verandering van hen vereisen dat ze het werk dat ze al hadden gedaan ongedaan maken en delen van de oplossing opnieuw ontwerpen. Misschien hebben we ons voorgesteld dat het twee uur zou duren, terwijl het in feite een dag zou duren.
Het is mogelijk dat je deze onthullingen later in het spel niet kunt voorkomen, dus het beste wat je kunt doen is een buffer bouwen om ze op te vangen. Voeg een extra week toe aan uw initiële tijdlijn en een extra 5-10% aan uw budget. Veel organisaties, die erkennen hoe vaak verwachtingen veranderen, hebben een agile benadering van ontwikkeling gehanteerd, waarbij technologie in fasen wordt uitgerold om periodieke herevaluatie mogelijk te maken. Wat je aanpak ook is, maak niet de fout te denken dat je aan alles hebt gedacht vanaf het begin. Het gebeurt bijna nooit.
3. Weet Scope Creep wanneer je het ziet
Naarmate het project vordert en nieuwe behoeften aan het licht komen, is het belangrijk om onderscheid te maken tussen degenen die u echt nodig hebt en degenen die u alleen maar wilt. Als je je ontwikkelaars vraagt om elke bel en fluit aan te passen die de geest kan bedenken, leidt dit meestal tot eindeloze projecten en te complexe eindresultaten. Elk nieuw verzoek, voordat het wordt gedaan, moet prioriteit krijgen.
Als u een functie overweegt, stel uzelf dan enkele basisvragen: werkt het systeem zonder? Hoeveel tijd kost het om te implementeren en hoeveel voordeel wordt uiteindelijk geleverd aan de eindgebruiker? Als we wachten tot een toekomstige release om dit aan te pakken, gaat er dan iets verloren? Het is een oefening van prioritering, en aan alles kan een status van hoog, gemiddeld of laag worden toegewezen. Als het laag is, plaats het dan op een figuratieve parkeerplaats - ik heb gehoord dat bedrijven documenten met 'droomontwikkelingsverzoeken' hebben waaraan iedereen ideeën kan toevoegen en de ingenieurs op hun gemak kunnen bladeren. Het kan altijd opnieuw worden bekeken als onderdeel van een reeks verbeteringen die moeten worden doorgevoerd zodra het project van de grond is gekomen en met succes is uitgevoerd.
4. Ontwikkel een gemeenschappelijke taal
Elk nieuw systeem heeft als kern een reeks bedrijfsdoelstellingen. Hiermee kunt u meer gegevens vastleggen, een bestaand proces stroomlijnen of nieuwe diensten aanbieden aan uw klanten. Het is van cruciaal belang dat het zakelijke team en het technologieteam gaan zitten voordat met enig werk is begonnen en deze doelen communiceren. De bedrijfsdoelstellingen mogen niet verloren gaan in een zee van tech-talk, en ze moeten goed in gedachten blijven tijdens elke fase van het werk.
Het ontwikkelen van een gemeenschappelijke taal betekent niet alleen het stellen van collectieve doelen, maar het bijhouden van de voortgang op een manier die voor iedereen werkt. Bedrijven en technologie kunnen verschillende hulpmiddelen gebruiken om hun werk te meten, maar er moet ten minste één visie op gedeelde vooruitgang zijn. Dit kan zo eenvoudig zijn als een projectplan of een spreadsheet met afgesproken velden, zoals datums en doelen en percentage voltooid, zodat iedereen toegang heeft tot de status van elke taak die moet worden voltooid. Het doel is om een situatie te vermijden waarin het zakelijke team denkt dat ze halverwege zijn en het technische team zegt dat ze maar een kwart zijn - iedereen moet hetzelfde begrip hebben van wat er is gedaan en wat er nog te doen is.
Je mag spreken in businessplannen en PowerPoints, en ze kunnen spreken in code, maar tenzij je vanaf het begin duidelijk communiceert, kom je nooit uit Babel. Een succesvol technologieproject gaat over een ontmoeting van de geest - niet alleen in het begin, maar bij elke stap. Erken je aannames en probeer er niet teveel te maken. Hoe kleiner de kloof tussen business en technologie, hoe gemakkelijker het is om samen uw bruggen over te steken.
