iTLasts.nl

Voor informatieanalyse en Ontwerp, Informatiemanagement, Projectleiding en Beheer

Dutch English French German Italian Portuguese Russian Spanish

tli3nwtrans

service

Get Adobe Flash player
Woensdag, 20 september 2017

qu-ootje

Ik mis mijn ex nog steeds, maar het is er niet meer zo ver naast.
Design is niet alleen hoe iets eruit ziet en hoe het voelt. Design is hoe het werkt.
Steve Jobs

Mijn websites

  

 

 

 

Mijn Forever-site

 

 

Bekijk ook mijn andere sites:

 

  

 

Mijn persoonlijke site

 

 

 

 

en verder:

 

 

 

 

 

View Ton Lit's profile on LinkedIn

 

Websites van mijn werkgevers:

 

Mijn visie

Mijn visie

Even een paar willekeurige koppen uit de vakpers:

 

 

 

 

 

 

 

 

 

Falend ICT-project kost politieacademie miljoenen

Eindelijk schot in onderzoek falende overheids-ICT

Zijn “mensen en cultuur” dé oorzaken van falende Agile ICT-projecten?

CBR onderzoekt klachten over ICT-problemen

Ict-problemen bij gemeente Amsterdam nog ernstiger dan gedacht

Rekenkamer: politie faalt bij aanpak ICT-problemen
Telfort kampt met waterval aan ICT-problemen

290 miljard dollar kwijt aan falende IT

 

Blijkbaar hebben we het nog niet helemaal onder controle met onze state of the art informatievoorziening.  Wie zei er ook alweer dat het een vak was zoals "De Bouw"?  Overigens ook in "De Bouw" worden nog zat cartastrofes veroorzaakt. Blijkbaar is het nog niet allemaal gesneden koek.

Ik heb de wijsheid ook zeker niet in pacht, maar tot nu toe zijn zulke catastrofes mij (en dus mijn opdrachtgevers) wel bespaard gebleven. Ik denk dat ik een simpele visie heb op het toepassen van ICT: Maak het niet te moeilijk; blijf in de belevingswereld van de mensen die de toepassing(en) gaan gebruiken en hou het dus "simpel". De menselijke maat is het uitgangspunt.

En wat is die menselijke maat? In ieder geval kleine stappen maken. En herhalen. Dicht bij de belevingswereld blijven. Dat betekent dus dat je niet met 7-mijlslaarzen van de hen bekende materie weg moet lopen. Je moet je klant/gebruiker aan de hand mee kunnen voeren en niet sleuren! Prototypen is dus een prachtige oplossing! En daar worden we dus toch weer "gered" door de ICT. Prototypen is tegenwoordig bijna kinderspel met de huidige talen en techniieken!

Hoe moet dat dan met complexe systemen? Wel.. wanneer je een probleem maar zo veel mogelijk opdeelt in kleine eenheden dan kom je uiteindelijk vanzelf op eenvoudig oplosbare problemen terecht. Dat was toch de essentie van de systeemleer? Toegegeven.. een complex systeem blijft een complex systeem wanneer je het weer op moet bouwen uit die eenvoudige oplossingen. Maar ja daar hebben wij ICT-ers voor doorgeleerd!

 

De methode......

..... doet het niet.. Professor Van Rees schreef het al in de jaren 80 van de vorige eeuw. Er is niet één methode/methodiek of (analyse)techniek die algemeen geldend is en overal werkt. Elke methode is ontstaan in een bepaald soort situatie en heeft daar zijn nut (gehad). Je moet alleen kijken in welke omstandigheden welke methode nuttig kan zijn.

Het effect van een methode heeft te maken met de omgeving waarin de methode moet worden toegepast, de omvang van het project,. de kennis en kunde van de leverende en de ontvangende partijen, de mate van (on)zekerheid waaronder gewerkt moet worden etc. etc..

Waterval versus cyclisch

IPMA, PRINCE2, PMW,OPEN, PMBok, EVO, Lean Six Sigma, SDLC, BPR...

Agile, Scrum, (D)SDM, RUP, UML, RAD,JAD....

Yourdon, ISAC, NIAM, SADT, BSP, ORM, DFD, ERM..

(Ben ik al op de helft?)


Ik stam nog uit de puur lineaire tijd. SDM was heilig. Het werd destijds ook nog beschouwd als een projectbeheermethodiek. Wat het niet was/is! Het schijnbare voordeel dat je eerst grondig en in een aantal fasen nadacht over de specificaties werd altijd teniet gedaan door het feit dat je het model toch nooit zo kon verkopen dat de ontvangende partij exact wist wat er gemaakt zou worden. Dus ontaarde het traject vrijwel altijd in een gevecht over het al dan niet wijzigien van de specificaties in een latere fase. 
Je kunt nog zo mooi praten en schrijven, het lukt je nooit om een levend beeld te geven van wat er gemaakt gaat worden.

Ook al hebben we meer en meer te maken met mensen die gewend zijn aan het werken met de computer, dat wil niet zeggen dat ze ons ook zomaar kunnen volgen.

 

De methode en techniek moeten nooit een doel op zich zijn. En als we dan een methodiek hebben geadopteerd, gebruik hem dan niet als keurslijf. Dat is ook nooit de bedoeling geweest van de bedenker(s) daarvan.

Het geldt ook voor de ontwikkeltechnieken. Kijk goed naar de doelgroep voor wie je ze gebruikt. Analisten communiceren anders dan materiedeskundigen. Dus misschien moeten we die verschillende groepen ook verschillende beelden i.c. analyse- en presentatietechnieken verstrekken. Tenslotte gaat het erom dat je kan overbrengen wat er gaat gebeuren.

Onze technieken hebben als doel het uitvoeren van de functionele decompositie. Een klant/gebruiker ziet werkzaamheden, geen modules.

Als het even kan kies ik zelf voor de communicatie met opdrachtgever en belangengroepen voor een zeer simpele schematechniek, nl. DataFlow Diagrams (DFD's). Het is naaar mijn mening één van de weinige schematechnieken die zowel door ICT-professionals als door materiedeskundigheden ééneenduidig begrepen wordt en op een simpele manier een overzicht geeft van actoren, activiteiten en data. Het vloeit (flowt) echt naar mijn mening. EN het is een eenvoudige techniek met niet te veel conventies.

Het enige dat "beter" werkt is een prototype (vind ik dan he?). Maar het is geen haarlemmerolie. Zoals al gezeg: kijk altijd naar het soort project, de omgeving en de omstandigheden. Als een bepaalde aanpak zichzelf bewezen heeft in een organisatie wie ben jij dan om daar eens even de bezem doorheen te halen en een heel andere aanpak te kiezen?
 

Netwerken? Niet gewoon maar met meetmatch.

Zó ontmoet je de mensen die het meest waardevol voor je zijn!

 

BitterBallenBorrel Groene Hart
Tulip Inn Bodegraven

 

Agenda voor alle borrels in Nederland

 
seattle 5k
slidebar