Is er een piloot aan boord?: technisch document

'Is er een piloot aan boord? Wil hij of zij op de oproeptoets drukken?' is een oproep die geen enkele passagier ooit hoopt te horen. Opnieuw las ik het opmerkelijke bericht van een soortgelijk waargebeurd incident dat plaatsvond in december 2013. Nadat zich een spoedgeval voordeed met de piloot van een vlucht vanaf Des Moines in de Verenigde Staten, deed de copiloot een oproep aan eventuele piloten die zich onder de passagiers zouden bevinden. Gezagvoerder Mark Gongol, een piloot van een B1-bommenwerper van de Amerikaanse luchtmacht, meldde zich in de cockpit. Het vliegtuig maakte een veilige landing en de bemanning en alle passagiers bleven ongedeerd.

Het is een mooi verhaal, maar de reden dat ik het herlas was iets totaal anders. Een potentiële klant van ons kwam laatst langs en vroeg of zijn bedrijf een pilot mocht uitvoeren van onze tijdroostersoftware voor een zakelijk project. Dit soort telefoontjes laten me altijd even de adem inhouden. Als iemand in een vliegtuig 'piloot' zegt, dan weet iedereen wat er wordt bedoeld. Maar als een softwaretester 'pilot' zegt, dan weet ik het zo net nog niet.

De term 'pilot' in de wereld van de software wordt vaak gebruikt in combinatie met andere interessante evaluatiemethoden, zoals 'haalbaarheidsstudie'. Laten we eens kijken wat deze termen betekenen en hoe ze het beste kunnen worden gebruikt in uw eigen zakelijke evaluatieproces.

Haalbaarheidsstudie

Deze term is al vele jaren oud en populair in de elektrotechniek. Het 'breadborden' van een printplaat werd uitgevoerd om na te gaan of de schakeling mogelijk was, niet om deze in productie te nemen. Bij een haalbaarheidsstudie wordt vaak meer tijd doorgebracht achter de werkbank dan bij het maken van de productieplaat, maar de enige schade die je kon toebrengen was aan de printplaat waaraan je werkte. Het was een goedkope methode zonder al te veel risico om te bewijzen dat een elektrische schakeling het gewenste resultaat kon opleveren.

Om in softwaretermen te spreken: een haalbaarheidsstudie moet worden ontworpen om iets te bewijzen. Als potentiële klanten mij vragen of ik ze kan helpen bij een haalbaarheidsstudie voor software voor bedrijfsprojectbeheer of een bedrijfsrooster, geef ik altijd hetzelfde antwoord: "Welke concepten wilt u bewijzen?"

Hierna volgt meestal een stilte en een verbijsterde uitdrukking.

Als u een haalbaarheidsstudie wilt uitvoeren en u geen idee hebt wat u wilt bewijzen, hoe weet u dan of deze kans van slagen heeft? Dat kunt u gewoon niet weten.

Waarom wil iemand dan überhaupt een haalbaarheidsstudie uitvoeren? Het vaste antwoord is dat de vragende partij waarschijnlijk niet beschikt over de benodigde steun van het management om de software te implementeren waarnaar ze onderzoek doen en hopen dat als ze het management kunnen laten zien dat de software het gewoon doet, ze het vanzelf goed zullen vinden en willen implementeren. In dit geval ligt de 'studie' bij het management en de 'haalbaarheid' is het hele idee van de zakelijke software.

Als het zo eenvoudig was het management ervan te overtuigen dat het zakelijke project en de roostersoftware uiterst geschikt zijn, dan zouden we er veel meer van implementeren.

Het is echter uiterst onwaarschijnlijk dat het werk dat u steekt in de implementatie van dit exemplaar van de haalbaarheidsstudie dezelfde steun krijgt als het implementeren van een bedrijfssysteem. Als een organisatie een bedrijfssysteem implementeert, zoals een systeem voor een rooster of projectbeheer, komt er nogal wat bij kijken om er een succes van te maken. Ten eerste moet er input zijn van het management en de direct verantwoordelijken voor elk aspect van de organisatie dat bij de implementatie is betrokken. Vervolgens is er tijd nodig voor configuratie, hulp van de technische diensten bij het koppelen aan andere systemen, steun van het management, tijd voor trainingen en, inderdaad, geld.

Als u dit allemaal niet hebt, wat is dan het systeem dat u met uw haalbaarheidsstudie wilt voltooien? Hooguit een fractie van waarop u had gehoopt. In deze tijd van 'in de cloud' kunt u waarschijnlijk toegang krijgen tot een systeem dat volledig wordt gehost, zodat u zich tenminste geen zorgen hoeft te maken over de aankoop van servers en software. Maar beschikken over een systeem maakt slechts een klein deel uit van het werk dat moeten worden gedaan voor alleen maar een basisimplementatie van uw systeem uit de haalbaarheidsstudie.

Het valt dus gemakkelijk te begrijpen waarom een organisatie zal aarzelen aanzienlijke financiële middelen en resources te besteden aan de implementatie van iets dat van grote invloed kan zijn op de hele organisatie. Het is een exercitie met een hoog risico. Normaliter praten we bij software voor bedrijfsprojectbeheer over de voordelen, maar het is makkelijk voor te stellen dat bij een mislukking van datzelfde project de schade even groot kan zijn. Het beperken van de risico's is dus een duidelijk punt van zorg. Maar als de werkelijke uitdaging eruit bestaat het management van de voordelen van het systeem te overtuigen, dan zijn er betere manieren. Bij HMS Software focussen we ons op onder meer de volgende technieken:

  1. Spreek met een echte, al bestaande klant.

    We zijn gezegend met een paar geweldige klanten die over het algemeen zeer tevreden zijn. Als een nieuwe, potentiële klant zijn zorgen uitspreekt over waar ze aan gaan beginnen, maken we samen met een bestaande klant met dit bedrijf een afspraak. Vaak is de bestaande klant zo vriendelijk als gastheer op te treden voor een persoonlijke ontmoeting. Soms voeren de klanten onderlinge telefoongesprekken waar wij bewust geen deel van uitmaken. We vragen de bestaande klant zowel het goede nieuws als de problemen met ons te delen.

  2. Laten we het bewijzen.

    Als u echt een haalbaarheidsstudie hebt die bewezen moet worden, laat ons u dan helpen deze te bewijzen. Er zijn geldige redenen voor het feit dat sommige aspecten van sommige implementaties eerst bewezen moeten worden. Mogelijk is er bij de implementatie sprake van zeer grote volumes van een bepaald type data. Zo werd ons ooit gevraagd of onze oplossing ook werkte bij een bijzonder grote werkbelasting van een project. We zijn gevraagd software te laten werken met bepaalde browsers of bepaalde databases, of de software te koppelen aan specifieke versies van bepaalde externe systemen. Als dat het soort concept is dat de evaluatie blokkeert, dan zijn degenen die het best die uitdaging kunnen aangaan de deskundigen op dit gebied zelf.

  3. U kunt hierin getraind worden.

    In het geval waarbij een potentiële klant absoluut wil weten of het systeem werkt met de data die door hun personeel worden gebruikt, laden we de data in een gehost systeem, voeren een, volgens de wens van de klant, minimaal noodzakelijke configuratie uit en geven we de personen die erbij betrokken zijn een korte training. We geven er sterk de voorkeur aan erbij aanwezig te zijn om te kunnen helpen met de demonstratie. Als dat niet kan, vragen we om inzage van het script of de demonstratie die de betrokkenen gebruiken en we vragen of we het mogen aanpassen of de mensen te trainen.

Waar is de pilot als je hem nodig hebt?

En hoe zit het met het pilotproject? Dat is al beter, of niet? Dat zou kunnen. Als u bent gevraagd een pilot te maken voor een implementatie van een bedrijfsrooster of bedrijfsprojectbeheersysteem, moet u eerst de doelstellingen bepalen. Als alle doelstellingen over de haalbaarheidsstudie gaan, is er geen sprake van een pilot.

Een pilot is een reële, bij de productie betrokken, live implementatie. Er is gewoonlijk een deel van de gebruikers bij betrokken die met het te testen systeem gaan werken, dus een pilot kost enige tijd. Hoewel de behoeften van alle beoogde gebruikers vanaf het begin in overweging worden genomen, richt de pilot zich op het uitvoeren van een echte implementatie voor de gebruikers van de pilot. Zij zullen feitelijk hun projecten gaan beheren of feitelijk hun roosters gaan invullen aan de hand van het nieuwe systeem.

De uitdagingen waarvoor een complete productie-implementatie komt te staan, zullen ook door de pilotimplementatie worden ervaren, met uitzondering van het volume of de complexiteit van de data. De meest voorkomende problemen bij pilotprojecten die ik heb gezien, zijn een gebrek aan steun, een te klein budget, te weinig tijd en resources en, waarschijnlijk het meest funest, een gebrek aan duidelijke doelstellingen om vast te stellen of de pilot is geslaagd.

Dat wil niet zeggen dat het pilotproject slecht is. Het uitvoeren van een pilot kan heel slim zijn. Het kan de kans verkleinen op negatieve gevolgen voor de hele organisatie ten gevolge van een onvolledige of slecht geconfigureerde implementatie. Maar om een pilotproject tot een succes te maken kost denkkracht.

Onlangs zijn we begonnen aan een tamelijk grote implementatie voor een organisatie in de publieke sector. Het verheugende hiervan is dat de organisatie al de tijd die ze nodig heeft voor het voltooien van de test al heeft besteed. Ze hebben hun keuze voor het bedrijfssysteem gemaakt. Gelukkig is die voor dat van ons. We hebben het afgelopen jaar met hun testteam samengewerkt om hun technische vragen te kunnen beantwoorden, maar nu is alle aandacht gericht op de gevolgen voor de dagelijkse gang van zaken van de mensen in deze organisatie.

Ze stelden voor dat we zes maanden gaan samenwerken met een redelijk grote groep die desondanks slechts tien procent uitmaakt van de hele groep. Er is voldoende budget, de pilot heeft de steun van het topmanagement en we hebben genoeg tijd om assistentie te kunnen bieden bij alles wat we normaliter bij een dergelijke implementatie doen. De groep die op dit project wordt gezet, zal er voorlopig in productie mee werken. Het is dus niet alleen maar een test. Dit is eerder een eerste fase van de implementatie, geen oefening om te zien hoe het uitpakt. Nu alles gereed staat, zien we hoopvol uit naar de resultaten aan het eind van het jaar.

In het kort

Pilotprojecten en projecten voor een haalbaarheidsstudie horen nu eenmaal bij bedrijfssoftware, maar als u er een overweegt, kunt u er een succes van maken door alle betrokkenen te wijzen op enkele belangrijke succesfactoren:

  1. Zorg er in de eerste plaats voor dat uw doelstellingen helder zijn geformuleerd.

  2. Verzeker u er vervolgens van dat het management begrijpt wat u nodig hebt en dat u over voldoende geld, resources en tijd kunt beschikken, zodat u deze doelen kunt verwezenlijken.

  3. Zorg er ten slotte voor dat u een projectplan maakt en dat u het beheert als elk ander project in uw portfolio.

Over de auteur

Chris Vandersluis is president en oprichter van HMS Software, een in Montreal, Canada gevestigde Microsoft Certified Partner. Hij studeerde economie aan de McGill-universiteit en heeft ruim 30 jaar ervaring met het automatiseren van projectbeheersystemen. Hij is sinds lange tijd lid van het Project Management Institute (PMI) en was een van de oprichters van de afdelingen van de Microsoft Project-gebruikersgroepen (MPUG) in Montreal, Toronto en Quebec. Chris heeft geschreven voor Fortune, Heavy Construction News, het tijdschrift Computing Canada, PMNetwork van PMI en Project Times. Hij doceert projectbeheer voor gevorderden aan de McGill-universiteit en geeft regelmatig lezingen op bijeenkomsten van verenigingen van projectbeheerders in Noord-Amerika en elders. HMS Software is uitgever van TimeControl, een project-georiënteerd systeem voor tijdregistratie en is een Microsoft Project Solution Partner sinds 1995.

U kunt via e-mail contact opnemen met Chris Vandersluis op chris.vandersluis@hms.ca

Als u meer artikelen van Chris Vandersluis over EPM wilt lezen, kunt u zijn blog EPM Guidance raadplegen op http://www.epmguidance.com/?page_id=39 (Engelstalig).

Uw Office-vaardigheden uitbreiden
Training verkennen
Als eerste nieuwe functies krijgen
Deelnemen aan Office Insiders

Was deze informatie nuttig?

Bedankt voor uw feedback.

Hartelijk dank voor uw feedback! Het lijkt ons een goed idee om u in contact te brengen met een van onze Office-ondersteuningsagents.

×