Gooi methodes overboord, communicatie is het smeermiddel voor projecten


Projecten – In de beginjaren van de ICT, de jaren 1950, 1960 bestonden er nog geen standaard ontwikkelmethoden voor software. Binnen organisaties die in het bezit waren van een computer werden applicaties ontwikkeld door programmeurs die een soort machtspositie in namen binnen de organisatie.

Omdat er werd niet gewerkt volgens een methode wist niemand precies wat er opgeleverd zou worden of  hoeveel het ging kosten. Er werd ontwikkeld via de zogenaamde JBF (Jan Boeren Fluitjes) methode. De behoefte aan informatie over het automatiseringsproces groeide en men probeerde het meer en meer te sturen. De OHZ (Op Hoop van Zegen) methode bracht een kleine verbetering want deze methode kende twee zekerheden: Je weet dat het schip strandt en dat de vis duur betaald wordt. Een kostbare periode van automatiseringsprojecten die vaak nergens toe leidden.

ICT Ontwikkelmethoden

Zo ontstond er meer en meer behoefte aan software ontwikkelmethoden. Hierbij wordt volgens vooropgestelde processen gewerkt aan de ontwikkeling van maatwerksoftware. Inmiddels zijn er heel veel methoden die sturing op ontwikkeling van software beogen. En even zo veel methoden zijn al weer ter ziele. Al deze methoden richten zich op het realiseren van mijlpaalproducten. D.w.z. plannen, ontwerpen, programmatuur, procedures, manuals, etc.

In grote lijnen zijn er twee soorten methoden onderscheiden; waterval methoden en iteratieve (Agile) methoden. Waterval methoden kennen een aantal fases waarbij iedere fase een mijlpaalproduct kent dat eerst goedgekeurd moet worden voordat met de volgende fase kon worden gestart. Hierdoor kan het gebeuren dat een project pas na jaren wordt opgeleverd. In die jaren staat de tijd niet stil en bleek de software niet aan te sluiten op de actuele bedrijfsvoering.
Agile methodes lossen dit probleem op door telkens binnen enkele weken een klein stukje werkende software op te leveren. Daardoor blijft aansluiting op de actuele bedrijfsvoering bestaan. Nadeel van de Agile methoden is dat het vaag blijft wanneer het systeem nu echt af is. Hierdoor is het lastig om zo’n systeem vooraf te begroten.

Waar dienen ontwikkelmethodes feitelijk voor?

Ik weet niet of jullie ooit in een groot project hebben gewerkt maar meestal is het zo dat de spanning enorm oploopt tegen de tijd dat het deadline in zicht komt. Ruzies over wie nu eigenlijk wel of niet wat had moeten doen en wie het dan alsnog moet doen. Oververhitting en overwerk. Dit ondanks de bewezen ontwikkelmethodes. Of is het juist dankzij de ontwikkelmethodes?
Binnen een project heeft iedereen zijn rol en doet enorm zijn best om zijn fase en mijlpaal zo goed mogelijk af te ronden. Daarop wordt tenslotte beoordeeld. Door de methode ligt de focus vooral bij de eigen rol en de eigen prestatie, alsof je op een eiland zit. Dit is feitelijk verkeerd want de focus zou moeten liggen bij het teameffort omdat het succes vooral afhangt van het gezamenlijke resultaat.
De mijlpaalproducten zoals die worden gemaakt zijn bedoelt als communicatiemiddel, input voor de volgende fase of voor de beheerders na oplevering. Het zijn vaak documenten die over de schutting worden gegooid. De business analist uit fase 1 is allang vertrokken als het systeem wordt opgeleverd.

Hoe kan het anders?

In mijn beleving zou heel het denken in methodes over boord gegooid moeten worden. Weer terug naar het JBF maar dan met de kennis en tools van nu. Gewoon je gezonde verstand gebruiken. Want waar gaat het nu echt fout? Juist op de overdrachtsmomenten. Het uitvragen van de requirements, het uitwerken van een functioneelontwerp, het informeren van gebruikers. Communicatie, dat is het smeermiddel binnen een project. Alle betrokkenen op de hoogte houden en weten wat ieders rol inhoudt. Je verplaatsen in een ander.

Blind doordenderen

Bij het realiseren van mijn mijlpaal moet ik me een voorstelling kunnen maken wat die ander er mee gaat doen. Welke informatie heeft hij echt nodig en wat heeft hij aan de informatie die ik hem geef. Groot gevaar daarbij is dat je een eigen invulling geeft aan wat dat dan is. Vermijdt dat zoveel mogelijk maar ga praten,ga vragen stellen, stel anderen op de hoogte van je plannen. Dus niet als een blind paard doordenderen. Het project is een gezamenlijke verantwoordelijkheid, pak het dan ook samen op. Dit geldt uiteraard niet alleen voor projecten maar voor de gehele bedrijfsvoering. Communiceren is elkaar vertellen;

  • Vertel finance wat je met de klant hebt afgesproken zodat ze een juiste factuur kunnen maken.
  • Vertel systeembeheer waarvoor die job op een bepaalde tijd moet draaien zodat er geen aanmeldingen gemist worden.
  • Vertel de gebruiker dat zijn systeem het volgende weekend gemigreerd moet worden zodat hij maandag niet voor verrassingen komt te staan (hoe vaak gaat dat niet mis?)
  • Vertel waarvoor de reorganisatie nodig is zodat men zich er op kan voorbereiden.
  • Vertel AnsaldoBreda dat het weer in Nederland hogere eisen aan een trein stelt.
  • Vertel je aandeelhouders over het teruglopen van het aantal orders.

 

Smeermiddel

Mensen worden ontzettend boos als ze ergens te laat achter komen. Ze hadden het eerder en beter moeten weten zodat ze tijdig maatregelen konden nemen.Communicatie is het smeermiddel voor projecten en voor de maatschappij. Denk gewoon aan die ander zodat alles soepel kan verlopen. Op www.itpedia.nl staat een reeks artikelen over ICT ontwikkelmethoden en het beoordelen van mijlpaalproducten. Doe er je voordeel mee.

 

Dit is gastblog van Wim Hoogenraad, eigenaar van ITpedia. Voor andere bijdrage van gastbloggers: zie hier
Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+

Een reactie plaatsen

Het e-mailadres wordt niet gepubliceerd. Verplichte velden zijn gemarkeerd met *