Stelling: Dure ICT'er meld niet wat hij/zij gedaan heeft.

[Verwijderd]

Voor mijn (stage)onderzoek heb ik graag jullie mening over het volgende:

Een IT'er (+€100 p.u.) komt bij de klant (consultant), is de gehele dag aan het werk en gaat aan het eind van de dag naar huis, zonder dat hij/zij duidelijk gecommuniceerd heeft naar de klant wat er exact is gebeurd.

Belanghebbende: Werkgever, Klant, IT'er

De klant krijgt hierdoor geen duidelijk beeld van het probleem (en waar de dure uren precies aan besteed zijn). Daarnaast zal de klant zo minder snel genegen zijn om de IT'er vaker te laten komen.

Hoe zouden jullie hiermee om gaan als werkgever zijnde, met de kennis in acht neming dat de IT'er, eigenlijk helemaal geen zin heeft om alles uit te leggen en verantwoorden aan de klant?

Bedankt.

[DopdeDouwer]

Simpel, ik zou als opdrachtgever niet betalen zonder specificatie.
Lijkt me logisch, daarom zullen de procedures van de werkgever ook een terugkoppeling naar de opdrachtgever ingebouwd hebben. Doet een werknemer dit niet, heeft hij een probleem met de werkgever.

Volgens mij is dit een situatie die niet vaak zal voorkomen.

[ Voor 49% gewijzigd door DopdeDouwer op 22-05-2013 10:55 ]

[André]

De ervaring leert dat als een klant om uitleg gaat vragen er geen goed werk geleverd is. Als alles naar wens is en de zaken gedaan worden waarvoor de IT'er ingehuurd is zul je niemand horen, totdat het ergens niet goed gaat. Dan wordt er vaak om uitleg van de werkzaamheden gevraagd, en de IT'er (die niets te verbergen heeft als het goed is) zal die direct geven. Geeft hij die niet, heeft hij gewoon geen goed verhaal.

[goldcard]

Verwijderd schreef op woensdag 22 mei 2013 @ 10:50:
....met de kennis in acht neming dat de IT'er, eigenlijk helemaal geen zin heeft om alles uit te leggen en verantwoorden aan de klant?

Op zich een aardig onderwerp om over te discussieren, maar deze laatste aanname is waardeloos. Wanneer je als opdrachtgever zo'n instelling hebt ten opzichte van externe consultants, dan moet je ze gewoon niet in dienst nemen.

[paazei]

Dan mag meneer de IT-er wel heel snel en veel resultaat laten zien als hij zich te goed voelt om zijn werkzaamheden te verantwoorden. Kan hij dit niet dan moet je baas wel van heel goed vertrouwen zijn om hem voor dat loon in te huren en niet een vast bedrag af te spreken voor een geleverde dienst.

[goldcard]

En dan nog iets.
Je schrijft "de klant heeft dan geen duidelijk beeld van het probleem". Volgens mij is ook dat geen juiste stelling.

Wanneer een opdrachtgever een externe consultant in dienst neemt, zal de OG al een probleem hebben. Dit probleem (of nieuwe uitdaging) zal hij met zijn interne medewerkers niet kunnen oplossen (ivm kennis of capaciteit), waarna een externe consultant wordt ingehuurd. Het probleem zal dus altijd (en sowieso op abstract niveau) duidelijk moeten zijn voor de OG. Geen probleem - geen inhuur externe consultants.

Wat voor de OG belangrijk is, is dat de opdrachtomschrijving voor de ON duidelijk is. Omschrijf als op te leveren eindresultaat niet alleen de oplossing zelf, maar ook de manier waarop deze oplossing te beheren is en waaruit deze oplossing bestaat.

Het managen van (zowel internen als externen) op dagbasis met tijdsverantwoording op kwartierniveau is management 1.0. Ga uit van een gespecificeerde quote vooraf, bespreek regulier de voortgang en laat de ON duidelijk maken wanneer er sprake is van meerwerk. Betaal in gedeeltes en de laatste som na afloop bij tevredenheid.

[Stoffel]

Ik ben over het algemeen de IT'er in deze situatieschets, en mijn ervaring is inderdaad dat klanten zelden vragen om een verantwoording. Meestal is dat omdat ik ben ingehuurd om iets specifieks te doen en het vrij makkelijk te beoordelen is of dat is gebeurd of niet. Toch maak ik altijd een kort werkverslagje (ook al hoeft de klant het niet) vanwege de positieve indruk die het achterlaat en om later nog te kunnen achterhalen wat ik heb gedaan. Dat ben ik zelf na een paar maanden meestal ook wel weer vergeten namelijk.

Ik zie niet echt in waarom de opdrachtgever in jouw situatie een externe IT'er zou inhuren als hij zelf niet precies weet wat er dient te gebeuren?

[Radical1980]

Het roept bij mij wel wat vragen op.

Er is een consultant aan het werk. Ik neem aan dat deze persoon een opdracht heeft gekregen?

Als mijn verwarming stuk is, zal ik deze graag gerepareerd zien. Iemand krijgt hier opdracht voor. Ik hoef van de monteur geen uitleg wat hij heeft gedaan, de verwarming werkt wel of werk niet. Ik hoef als klant geen duidelijk beeld te krijgen van het probleem. Vreemde aanname.

Laatste aanname is ook een bijzondere. Waarom zal een specialist niet willen uitleggen wat hij heeft gedaan?

[Radical1980]

Gezien de reacties en over melding gesproken:

Wat ben je precies aan het onderzoeken?

[Tsjipmanz]

André heeft gelijk. Pas wanneer het niet goed gaat zal er normaal gesproken om uitleg gevraagd worden.

Er is natuurlijk ook nog een aantal andere dingen van belang, zoals de bedrijfsgrootte (voor een klein bedrijfje is externe inhuur relatief veel duurder dan voor een multinational), de aard en de grootte van de opdracht (klus van 8 uren is een ander verhaal dan klus van 600 uren), en in hoeverre de opdrachtgever zelf kan inschatten hoeveel tijd het werk ongeveer in beslag neemt.

In het geval ik weinig budget had, geen verstand van IT en ik moest iemand voor één dag inhuren, zou ik vooraf een korte specificatie vragen van waaraan de IT'er verwachtte de uren te besteden, en achteraf even snel met hem om tafel of het ongeveer ook zo uitgepakt is. En als hij dat zou weigeren, dan zou ik iemand anders inhuren.

[Verwijderd]

Bedankt voor jullie reacties. Het komt eigenlijk voort uit het volgende; Management ziet de IT vaak als een hoge kostenpost, zonder dat zij echt kunnen meten of het zinvol is. 'als de IT-afdeling het zegt, dan zal dat wel zo zijn' vaak omdat zij te weinig kennis in huis hebben om zelf te kunnen beoordelen of dat ook wel echt zo is. Pas als het management overtuigd is, zullen zij vaker open staan voor meer IT budget. Misschien is het inderdaad een idee om een dagelijkse duidelijke 'rapportage' te maken, die ook in te zien is door de opdrachtgever. Het betreft projecten van bijv. minimaal een paar maanden / half jaar.

[Verwijderd]

Een duurbetaalde Consultant kan vaak bepaalde kunstjes uitvoeren, aan de hand van kennis, ervaring, opleiding en inzicht, die over het algemeen niet door interne medewerkers kunnen (of mogen) worden uitgevoerd. Dat een klant dus niet altijd even goed op de hoogte is van wat een Consultant precies doet, of heeft gedaan, spreekt voor zich. Immers als de kennis en know-how er was geweest binnen de onderneming, dan had je die Consultant lekker thuis laten zitten.

Onze klanten (ik ben toevallig Consultant) hebben een probleem, of wens, of vraagstuk, of wat dan ook, en willen daarvoor een oplossing aanschaffen. Ze vertrouwen er vervolgens op dat we ook daadwerkelijk leveren wat we hebben verkocht en dat gaat eigenlijk altijd zonder problemen, en zonder dat de klant aan het eind van de dag een specificatie wil hebben van de door ons uitgevoerde werkzaamheden. Wel vind er zo nu en dan een stukje kennisoverdracht klaar, zodat de beheerders het door ons geïmplementeerde kunnen beheren. Maar we gaan niet stap-voor-stap iedere muisklik die we hebben gemaakt uitleggen en verantwoorden. Dat kan wel, maar dan wordt de rekening ook gewoon twee keer zo hoog. Ik probeer wel altijd zoveel mogelijk de klant erbij te betrekken, maar vaak is dat gewoon niet the way to go. Als ik een SAN configureer dan hoeft de klant echt niet te weten hoe ik dat precies doe, want het is een eenmalig proces, wat ik door kennis en ervaring in een relatief korte tijd voor elkaar weet te krijgen. De klant daarentegen interesseert het totaal niet hoe ik het doe, als ik het maar doe. Dat ze vervolgens het SAN zelf willen beheren is logisch, en daar kunnen ze desgewenst tekst en uitleg over krijgen.

Uiteindelijk moet je natuurlijk wel verantwoording uitleggen, wat positief kan zijn (het werkt) of negatief (het werkt (nog) niet).

Het belangrijkste, in mijn ogen, is dat je goed met de klant communiceert en de klant bij het project betrekt. Dan krijgen ze er ook een beetje feeling bij en krijg je achteraf ook geen gezeik over de hoeveelheid uren die je eraan hebt besteed, terwijl de klant niet weet wat er nou precies is gebeurd. Hoe dan ook, communicatie is en blijft key, vooral voor externen. Je hoeft niet alles uit te leggen, maar als je in hoofdlijnen communiceert wat je hebt gedaan, wat je nu aan het doen bent en nog van plan bent om te gaan doen, dan kom je een heel eind bij de meeste klanten.

[t_captain]

Het gros van de IT-ers is ingezet (tegen een uurtarief tussen de 50,- en 100,-) op projecten bij de klant in huis. Ik denk dat dit business model zo'n beetje 80% van de services markt betreft. Bij dergelijke projecten ga je hopelijk geen voortgangsrapportage per uur doen. Eerder per week. En in agile projecten heb je vaak een dagelijkse scrum waarin je kort benoemt waar je mee bezig bent.

Dit is niet te vergelijken met bijvoorbeeld een advocaat, die vaak projecten doet van 4...40 uur tegen een uurtarief waar je 3 of 4 IT-ers voor huurt. Die advocaat factureert natuurlijk veel gedetailleerder.

[Tsjipmanz]

Verwijderd schreef op woensdag 22 mei 2013 @ 11:25:
Bedankt voor jullie reacties. Het komt eigenlijk voort uit het volgende; Management ziet de IT vaak als een hoge kostenpost, zonder dat zij echt kunnen meten of het zinvol is. 'als de IT-afdeling het zegt, dan zal dat wel zo zijn' vaak omdat zij te weinig kennis in huis hebben om zelf te kunnen beoordelen of dat ook wel echt zo is. Pas als het management overtuigd is, zullen zij vaker open staan voor meer IT budget. Misschien is het inderdaad een idee om een dagelijkse duidelijke 'rapportage' te maken, die ook in te zien is door de opdrachtgever. Het betreft projecten van bijv. minimaal een paar maanden / half jaar.

Goed punt. Het management (soms zelf het management van IT-afdelingen) heeft ook vaak echt geen idee hoe complex sommige projecten zijn, simpelweg omdat ze weinig verstand hebben van IT of ingepakt worden door optimistische schattingen van mensen die al even weinig kennis van zaken hebben..

Dat gezegd hebbende, wordt er binnen de IT ook enorm veel onnodig geld verbrast , bv door een beheersorganisatie die veel te bureaucratisch is ingericht, of projecten die op driekwart zijn en dan plotseling onder druk van de business worden gestaakt.

Meestal is er niet een groter IT budget nodig, maar moet het geld gewoon slimmer worden besteed.

[chime]

Veel hangt ervan af wat er overeengekomen is te rapporteren.

Men moet wel duiding kunnen geven wat men aan het doen is - maar vergelijk het met een bouwvakker die je aan uurtarief je huis laat metsen - ook die gaat niet supergedetailleerd kunnen zeggen wat ie welk uur aan het doen was.

Veel problemen ontstaan ook door gebrek aan communicatie en troebelheid (teveel procedures, laagjes, ... )
Ook vraagt men vaak pas detaillering op een moment dat het eigenlijk al te laat is - extra overhead van indekkende managers / x-keren doorgeven wat nu gedaan wordt / is dan gewoon de doodssteek.

Soit, ik ben nogal stevig voorstander van agile werken:
- korte feedbacklus met de klant (wekelijks, 2-wekelijk, maandelijks): wat de klant toelaat om sneller te corrigeren.
- dagelijks overzicht van wat er gebeurd
- klant kan regelmatig prioriteiten bijwerken / maar project ook inkorten bvb.
- op het einde van elke sprint is er toch iets werkbaars, dus de totale investering is zelden verloren.
Dit in tegenstelling tot van die super grote projecten waar men op het einde alles even aan elkaar wilt gaan liggen knopen en ontdekt dat dat toch niet goed werkt => eigenlijk is er dan dus gewoon een enorme berg code met weinig tot geen nut.
- klant wordt als het ware wat opgeleid: krijgt toch vaak een beter beeld van de kost van aanpassingen.

[Hydra]

t_captain schreef op woensdag 22 mei 2013 @ 11:28:
Het gros van de IT-ers is ingezet (tegen een uurtarief tussen de 50,- en 100,-) op projecten bij de klant in huis.

Als je fulltime bij een klant 'in huis' zit is het gewoon detachering. Helaas wordt iedereen te pas en te onpas 'consultant' genoemd.

[Bonsaiboom]

Hydra schreef op woensdag 22 mei 2013 @ 15:01:
[...]


Als je fulltime bij een klant 'in huis' zit is het gewoon detachering. Helaas wordt iedereen te pas en te onpas 'consultant' genoemd.

Ik zit fulltime bij een klant 'in huis' en ben wel degelijk 'consultant'. Het kan best.


Ik heb het op meerdere manieren gehad, maar meestal was een verantwoording per uur wel prima, op hoog niveau.

Als ik echt per kwartier zou moeten gaan verantwoorden, dan zou ik gek worden van wat ik allemaal moet uitspecificeren. Daar hebben zij ook echt niets aan.

[demichel]

Tsja, aan 100€ per uur kun je natuurlijk ook wel een uurtje per dag spenderen om een verslag van de overige 7 uur uit te tikken maar als klant zou ik toch liever 8 volle productieve uren zien.

Als de "dure ICT'er" er een loopje mee neemt dan komt dat vroeg of laat toch uit.

[ Voor 18% gewijzigd door demichel op 22-05-2013 17:06 ]

[GoldenSample]

Die klant heeft toch een 'pobleem'/opdracht die moet worden opgelost? Als je niet weet wat die IT-er doet/mee bezig is op macro niveau, waarom is hij er dan?

Het is voor veel mensen nogal out of the box maar eigenlijk is er maar één relevante parameter voor de klant: of zijn probleem opgelost is voor een goede prijs/kwaliteit. Eigenlijk is het natuurlijk niet zo relevant of je dit laat doen door een briljant iemand die 100 euro vraagt en 90% van de tijd met z'n benen omhoog zit of dat het door een wat gewoner persoon word gedaan welke gewoon flink aan het werk is en ook 100 euro vraagt. Mits ze natuurlijk de zelfde kwaliteit leveren . De eerste zal nogal wat weerstand ondervinden, van nummer twee word gezegd dat hij goed en hard werkt. Persoonlijk zou ik liever de eerste hebben, als die een fuck-up maakt heeft hij nog de mogelijkheid om een tandje bij te zetten.

Verder verantwoording op micro niveau is leuk maar vaak tijd verspilling. Als je in details moet gaan uitleggen wat je doet snapt de klant er vaak weinig van of hij is zo makkelijk om de tuin te leiden dat het een betekenisloze verantwoording is.

Zelfde werkt overigens met managers die geen vakinhoudelijke kennis hebben over het gene dat ze 'managen', worden ook nogal eens in het ootje genomen. Dit is denk ik het eigenlijke probleem. Ik doe dan product ontwikkeling van fysieke producten en heb al tijdens mijn studies en stages het zelfde zien gebeuren, mensen die mij gaan aansturen op dingen waar ze TOTAAL GEEN verstand van hebben. Tja daar geloof ik niet in, ik ben benieuwd in hoeverre dat soort mensen zelf ook doorhebben dat er 'om hen heen' gewerkt word of er gewoon van onderaf dingen doorgedrukt worden. (iets wat jij denk ik weer vertaald als; het management overtuigen)

[ Voor 42% gewijzigd door GoldenSample op 22-05-2013 17:04 ]

[Ikke_Niels]

Dit is vrij simpel:

Het ligt eraan wat de klant wenst, (bezoeks)verslagen per dag? Of een samenvatting per week?
Het kost tijd om te maken voor degene die ingehuurd wordt (ofwel minder effectief) maar het is ook meteen een stukje naslagwerk.

Ofwel goede afspraken maken met de consultant die je inhuurt.

[Hydra]

Ikke_Niels schreef op woensdag 22 mei 2013 @ 17:43:
Dit is vrij simpel:

Het ligt eraan wat de klant wenst, (bezoeks)verslagen per dag? Of een samenvatting per week?

Mijn ervaring is dat een klant gewoon z'n probleem opgelost wil hebben en zolang dat maar gebeurt geen enkele interesse heeft in dergelijke verslagen. Pas als "shit hits the fan" komen zulke dingen naar boven en is kunnen uitleggen waar je je tijd aan besteed hebt belangrijk. En dat gebeurt over 't algemeen als je de tijd die je ingeschat hebt overschrijdt.

[The Eagle]

Verwijderd schreef op woensdag 22 mei 2013 @ 10:50:
Voor mijn (stage)onderzoek heb ik graag jullie mening over het volgende:

Een IT'er (+€100 p.u.) komt bij de klant (consultant), is de gehele dag aan het werk en gaat aan het eind van de dag naar huis, zonder dat hij/zij duidelijk gecommuniceerd heeft naar de klant wat er exact is gebeurd.

Topictitel zegt "duur". Dat is subjectief. 100 euro per uur is voor mij vrij normaal. Pas 250 euro per uur vind ik vrij aan de prijs - maar kan ook voor een specialist een schijntje zijn

Belanghebbende: Werkgever, Klant, IT'er

De klant krijgt hierdoor geen duidelijk beeld van het probleem (en waar de dure uren precies aan besteed zijn). Daarnaast zal de klant zo minder snel genegen zijn om de IT'er vaker te laten komen.

Hoe zouden jullie hiermee om gaan als werkgever zijnde, met de kennis in acht neming dat de IT'er, eigenlijk helemaal geen zin heeft om alles uit te leggen en verantwoorden aan de klant?

Bedankt.

Het probleem zit hem hier niet eens bij de IT'er zelf, maar bij de klant. De klant is namelijk degene die de opdracht verstrekt. Normaal gesproken laat je als Klant / opdrachtgever bij Werkgever /IT-bedrijf een estimate maken over wat iets ongeveer moet kosten, qua uren en evt andere resources. Dat noemen ze een RFP - Request for Proposal. Op basis van het proposal gaat de opdrachtgever akkoord. Daardoor is van te voren normaal gesproken helder wat er moet gebeuren, tegen welk tarief, en wat de hoeveelheid te spenderen uren is, voor alle partijen. Duurt iets langer dan gepland (meerwerk), dan staat over het algemeen in het contract tussen opdrachtgever en opdrachtnemer wie die uren moet betalen en hoe daar mee omgegaan wordt.
De IT'er zelf is slechts een derde partij in dit verhaal; die schrijft simpelweg zijn uren op een daarvoor aan hem verstrekte Time & Expenses code, welke hij laat aftekenen door de opdrachtgever. Inhoudelijk zal het de klant meestal een zorg wezen hoe iets opgelost wordt, als het maar opgelost wordt. Er hoeft inhoudelijk dan ook niks op papier te staan - nergens voor nodig. Kost alleen maar extra tijd en dus budget voor de klant. Ik ken maar weinig klanten die een detailrapport van gedane werkzaamheden willen.

Een beetje anders wordt het als een bedrijf een freelancer inhuurt. Dan zijn IT'er en opdrachtnemer de zelfde. maar dan nog zal $klant met een opdracht moeten komen en er vooraf afspraken gemaakt worden aan de hand van een contract, ook mbt evt meerwerk. Dus normaal gesproken moet alles gewoon op papier staan

Ergo: ik zie het probleem niet zo, iig niet voor de IT'er of zijn werkgever. Hooguit bij de klant.

[Xanaroth]

Verwijderd schreef op woensdag 22 mei 2013 @ 10:50:
Voor mijn (stage)onderzoek heb ik graag jullie mening over het volgende:

Een IT'er (+€100 p.u.) komt bij de klant (consultant), is de gehele dag aan het werk en gaat aan het eind van de dag naar huis, zonder dat hij/zij duidelijk gecommuniceerd heeft naar de klant wat er exact is gebeurd.

Belanghebbende: Werkgever, Klant, IT'er

De klant krijgt hierdoor geen duidelijk beeld van het probleem (en waar de dure uren precies aan besteed zijn). Daarnaast zal de klant zo minder snel genegen zijn om de IT'er vaker te laten komen.

Hoe zouden jullie hiermee om gaan als werkgever zijnde, met de kennis in acht neming dat de IT'er, eigenlijk helemaal geen zin heeft om alles uit te leggen en verantwoorden aan de klant?

Bedankt.

stap 1. je hebt een klus.
stap 2. je huurt een it-er in voor die klus.
stap 3. je spreekt een prijs af samen met de randvoorwaarden (wat, wanneer etc).
stap 4. wat kan jou het schelen wat hij doet, de totale prijs en uitkomst liggen toch vast. Desnoods speelt ie de hele dag mario kart, zolang de klus maar naar voldoening (zie randvoorwaarden) klaar is - zo niet dan betaal je niet.

Oftewel, de ICTer bepaalt zn eigen uurloon door hoe hard hij/zij werkt. Werkt ook buiten de ICT trouwens zo - je koopt een totaal product, geen setje uren en hoopt dat er iets goeds gebeurt in die tijd.
Vandaar ook dat je heel erg veel overwerk en weekenden werkt bij dat soort banen - je wilt een klus zo snel mogelijk afronden zodat je weer beschikbaar bent op het moment dat de volgende klus zich aan doet. Werk je traag, dan loop je klussen mis en verdien je vanzelfsprekend minder.

[ Voor 8% gewijzigd door Xanaroth op 22-05-2013 18:53 ]

[Stoffel]

Xanaroth schreef op woensdag 22 mei 2013 @ 18:50:
[...]


stap 1. je hebt een klus.
stap 2. je huurt een it-er in voor die klus.
stap 3. je spreekt een prijs af samen met de randvoorwaarden (wat, wanneer etc).
stap 4. wat kan jou het schelen wat hij doet, de totale prijs en uitkomst liggen toch vast. Desnoods speelt ie de hele dag mario kart, zolang de klus maar naar voldoening (zie randvoorwaarden) klaar is - zo niet dan betaal je niet.

Zo werkt het in de IT vrijwel nooit hoor, tenzij je een specialist of leverancier treft die pas bezig is. Je kan bij mij een fixed price offerte krijgen, maar dan betaal je zo'n dikke premium dat ik erna lekker op vakantie ga. Waarom? Omdat het probleem nooit duidelijk is, de requirements ook niet, er allemaal politieke spelletjes in iedere organisatie spelen waardoor een beslissing van wie je ook spreekt niets hoeft te betekenen (en dat kun je ook niet inschatten want je kent het bedrijf niet) en nog vele andere risico's. Daarom is het gewoon uurtje factuurtje en kan ik (desgevraagd) mijn uren verantwoorden. Daarvoor werk ik efficient en hard, maar ga ik zeker het financiële risico niet nemen dat de klant zijn zaken niet op orde heeft.

[ZeRoC00L]

Simpel, je kunt wachten tot de ITer naar je toe komt, of naar de ITer toegaan en vragen wat ie nu gedaan heeft. Als je daarmee wacht tot 5 uur, tja, logisch dat ie ook naar huis wil, dus om half 5 even overleggen wat de status is en wat er gebeurt is.

[Reacher]

Management informatie is niet het probleem van de consultant. De stelling slaat ook nergens op, externe expertise huur je niet in omdat je budget op moet maar omdat er vraag naar is. De projectleider, manager en de lijn organisatie moeten duidelijk stellen welke informatie en rapportages zij nodig hebben. Waar uitleg nodig is zal een goed / sterk management hier dan ook om vragen.

Dit bij ict / consultant neer te leggen is precies het probleem, slap management en het probleem verplaatsen.

[Radical1980]

Tsjipmanz schreef op woensdag 22 mei 2013 @ 11:42:
[...]


Goed punt. Het management (soms zelf het management van IT-afdelingen) heeft ook vaak echt geen idee hoe complex sommige projecten zijn, simpelweg omdat ze weinig verstand hebben van IT of ingepakt worden door optimistische schattingen van mensen die al even weinig kennis van zaken hebben..

Dat gezegd hebbende, wordt er binnen de IT ook enorm veel onnodig geld verbrast , bv door een beheersorganisatie die veel te bureaucratisch is ingericht, of projecten die op driekwart zijn en dan plotseling onder druk van de business worden gestaakt.

Meestal is er niet een groter IT budget nodig, maar moet het geld gewoon slimmer worden besteed.

Ik kan haast niet anders dan jouw bericht opsplitsten. Overigens zitten er wat mij betreft nog teveel aannames in het bericht waardoor de reactie misschien niet iets is wat je verwacht.

Het management (soms zelf het management van IT-afdelingen) heeft ook vaak echt geen idee hoe complex sommige projecten zijn, simpelweg omdat ze weinig verstand hebben van IT of ingepakt worden door optimistische schattingen van mensen die al even weinig kennis van zaken hebben..
Dat het management geen idee heeft, kan een bewuste keuze zijn. Ze hebben mensen die zich daar mee bezig houden, waarom moeten ze dan over inhoudelijke kennis beschikken? Ze vertrouwen op de mensen die het werk uitvoeren. Vind ik persoonlijk geen vreemde gedachte om vertrouwen in iemands kennis en kunde te hebben.

Wat overigens ook een mogelijkheid is dat ze er wel verstand van hebben maar net doen of ze er geen verstand van hebben. Om wat voor reden dan ook.

Ze kunnen ook ingepakt worden door andere mensen. Maar dit kan soms ook politiek zijn of met belangen te maken hebben die niet duidelijk zijn.

Dat gezegd hebbende, wordt er binnen de IT ook enorm veel onnodig geld verbrast , bv door een beheersorganisatie die veel te bureaucratisch is ingericht, of projecten die op driekwart zijn en dan plotseling onder druk van de business worden gestaakt.
Dit kan allemaal met belangen te maken hebben die soms tegenstrijdig zijn.

Dat er verspilling plaats vindt binnen de IT is helder. Ik ken overigens haast geen branche waar er geen sprake van verspilling is.

Meestal is er niet een groter IT budget nodig, maar moet het geld gewoon slimmer worden besteed.
Hier verwacht nog iets van een voorbeeld. Bij welk project had het geld slimmer besteed moeten worden en waar aan? Omdat hier het woord "meestal" wordt gebruikt, is er sprake van meerdere projecten.

[JaQ]

Reacher schreef op woensdag 22 mei 2013 @ 20:51:
Management informatie is niet het probleem van de consultant. De stelling slaat ook nergens op, externe expertise huur je niet in omdat je budget op moet maar omdat er vraag naar is. De projectleider, manager en de lijn organisatie moeten duidelijk stellen welke informatie en rapportages zij nodig hebben. Waar uitleg nodig is zal een goed / sterk management hier dan ook om vragen.

Dit dus.

Ik ben ook zo'n consultant die je probleem komt oplossen voor een significant tarrief. Het is voor mij gebruikelijk om vooraf vast te stellen hoe en in welke vorm een rapportage over de verrichte werkzaamheden wordt geleverd. Het is voor mij ook gebruikelijk om vooraf vast te stellen welk probleem ik op kom lossen, je wilt wel kunnen meten of je succesvol bent geweest...

Persoonlijk kan ik mij niet voorstellen dat er bedrijven zijn die consultants inhuren zonder dat er een probleemstelling is (kan wel heel high level zijn, "het performt niet" is zo'n fraaie ) Maar mocht TS toevallig een onderneming kennen die graag gratis geld weggeeft aan consultants zoals ik enkel voor aanwezig zijn dan zijn er ongetwijfeld geinteresseerden.

Oftewel: wat een ongelovelijke flauwekulstelling, er is toch geen serieuze onderneming die op deze wijze met haar budget omspringt?

Ik denk overigens wel dat er voldoende ICT-ers (zowel internen als ingehuurde helden) zijn die beslissen voor de beslissers in het bedrijf wat juist is, vaak door het niet begrijpelijk genoeg maken van informatie en persoonlijke voorkeur. Het zit nou eenmaal niet in de aard van een ICT-er om een probleem niet op te lossen (of een systeem niet te optimaliseren), terwijl dat soms toch echt het goedkoopste is. Ook dnenk ik dat er voldoende managers zijn die niet kunnen overdragen op welke gronden zijn beslissingen maken, waardoor ze niet de juiste informatie krijgen om uiteindelijk te kunnen beslissen.

Zou die C in ICT dan toch terecht zijn? :-)

[Jaymz]

JaQ schreef op woensdag 22 mei 2013 @ 21:56:
[...]

Dit dus.

Ik ben ook zo'n consultant die je probleem komt oplossen voor een significant tarrief. Het is voor mij gebruikelijk om vooraf vast te stellen hoe en in welke vorm een rapportage over de verrichte werkzaamheden wordt geleverd. Het is voor mij ook gebruikelijk om vooraf vast te stellen welk probleem ik op kom lossen, je wilt wel kunnen meten of je succesvol bent geweest...

Persoonlijk kan ik mij niet voorstellen dat er bedrijven zijn die consultants inhuren zonder dat er een probleemstelling is (kan wel heel high level zijn, "het performt niet" is zo'n fraaie ) Maar mocht TS toevallig een onderneming kennen die graag gratis geld weggeeft aan consultants zoals ik enkel voor aanwezig zijn dan zijn er ongetwijfeld geinteresseerden.

Ze zijn er; de situaties waarbij ik dat heb zien gebeuren gaan vaak samen met het overslaan van wat jij in je eerste alinea aanhaalt; In heldere taal duidelijk krijgen wat de bedoeling is, wat de verwachtingen zijn en hoe de verschillende partijen elkaar op de hoogte houden

[Reacher]

Die situaties laten dan ook ruimte voor inzichten van de consultant. Je mag verwachten dat de consultant zal handelen in het belang van de opdrachtgever / oplossing.

Ik heb net nogmaals de stelling gelezen en ik val wederom over

Management ziet de IT vaak als een hoge kostenpost, zonder dat zij echt kunnen meten of het zinvol is.

Dan moet management zich afvragen of ze de taak automatisering/informatisering en algehele ICT niet moet beleggen bij een persoon welke de vertaling naar management kan maken. Ik kom zelden nog organisaties tegen die zo zwart-wit bezig zijn. ICT is een 'enabler' en inmiddels in veel bedrijven/organisaties een primair proces of een grote ondersteuner van het het primaire proces.

Ik krijg toch sterk het idee dat TS misschien eens op stage bezoek moet gaan bij meerdere organisaties voor je dit soort zaken helder kunt overzien.

[Tsjipmanz]

Radical1980 schreef op woensdag 22 mei 2013 @ 21:07:
[...]

Het management (soms zelf het management van IT-afdelingen) heeft ook vaak echt geen idee hoe complex sommige projecten zijn, simpelweg omdat ze weinig verstand hebben van IT of ingepakt worden door optimistische schattingen van mensen die al even weinig kennis van zaken hebben..
Dat het management geen idee heeft, kan een bewuste keuze zijn. Ze hebben mensen die zich daar mee bezig houden, waarom moeten ze dan over inhoudelijke kennis beschikken? Ze vertrouwen op de mensen die het werk uitvoeren. Vind ik persoonlijk geen vreemde gedachte om vertrouwen in iemands kennis en kunde te hebben.

Wat overigens ook een mogelijkheid is dat ze er wel verstand van hebben maar net doen of ze er geen verstand van hebben. Om wat voor reden dan ook.

Ze kunnen ook ingepakt worden door andere mensen. Maar dit kan soms ook politiek zijn of met belangen te maken hebben die niet duidelijk zijn.

Ik ga tot op zekere hoogte met je mee, maar je zal toch wel een bepaalde mate van affiniteit moeten hebben met IT. Persoonlijk zou ik nooit pakweg een manager van een zorginstelling of iemand die al zn hele leven in de registeraccountancy zit, leiding laten geven over afdeling Informatievoorziening neerzetten binnen een groot bedrijf. Of je moet echt uitzonderlijk goeie mensen onder je hebben, maar die zouden dan net zo goed zo'n vacature kunnen vervullen. Naast het feit dat een bepaalde basisbegrip van methodieken en frameworks als ITIL, BISL, Prince II mooi is meegenomen, moet je ook begrijpen hoe complex bepaalde projecten en programma's kan zijn en hoeveel extra werk wijzigingen in scope tot gevolg kunnen hebben. Wat je in de praktijk wel eens ziet is dat onwetend management worden "ingepakt" (zoals jij het noemt) door babbelzieke projectleiders. Signalen uit de lijn worden vervolgens (al dan niet bewust) genegeerd, waardoor projecten soms jammerlijk mislukken of financieel uit de hand lopen, terwijl dit voorkomen had kunnen worden. En met enige ervaring binnen de IT-branche is de kans dat dit gebeurt al een stuk kleiner.

Dat gezegd hebbende, wordt er binnen de IT ook enorm veel onnodig geld verbrast , bv door een beheersorganisatie die veel te bureaucratisch is ingericht, of projecten die op driekwart zijn en dan plotseling onder druk van de business worden gestaakt.
Dit kan allemaal met belangen te maken hebben die soms tegenstrijdig zijn.

Dat er verspilling plaats vindt binnen de IT is helder. Ik ken overigens haast geen branche waar er geen sprake van verspilling is.

Dat is waar, maar ik denk dat je in ondersteunende branches geen voorbeelden kan noemen waar de verspilling groter (en meer onnodig) is dan de automatisering. Ik heb meegemaakt dat een organisatie zo bureaucratisch is ingericht, dat het uitvoeren van een change die voor een programmeur misschien 5 minuten werk is, een doorlooptijd van zo'n 6 weken heeft. En er gaat minimaal 30 manuur papierwerk en goedkeuringen inzitten. Dat moet je niet willen als bedrijf, dan ben je te ver doorgeschoten en is er iets fundamenteel mis.

Meestal is er niet een groter IT budget nodig, maar moet het geld gewoon slimmer worden besteed.
Hier verwacht nog iets van een voorbeeld. Bij welk project had het geld slimmer besteed moeten worden en waar aan? Omdat hier het woord "meestal" wordt gebruikt, is er sprake van meerdere projecten.

Vraag een willekeurig iemand die wat werkervaring heeft binnen de automatisering en ze zullen je een voorbeeld kunnen noemen. Recent heb ik bij mijn huidige opdrachtgever dat door een beroerde planning van een projectmanager en desinteresse/onkunde aan de kant van de stuurgroep, op het laatste moment nog allerhande dure externen moesten worden ingeschakeld om een bepaalde omgeving in te richten.
Of bij de implementatie van een peperduur stuk software, iets meer tijd en geld besteden aan een analyse vooraf hoe deze het beste gebruikt kan worden door het bedrijsfonderdeel die het moet gaan gebruiken, en het creeëren van draagvlak. Hiermee voorkom je dat je straks met een duur pakket zit dat door niemand wordt gebruikt omdat het hen "door IT door de strot wordt geduwd".

[abeker]

Bonsaiboom schreef op woensdag 22 mei 2013 @ 16:23:
[...]
Ik zit fulltime bij een klant 'in huis' en ben wel degelijk 'consultant'. Het kan best.

Ik denk dat Hydra doelt op het feit dat een consultant advies aan bedrijven geeft. Veel 'consultants' die fulltime bij een klant zijn (gedetacheerd of whatever) houden zich maar weinig bezig met daadwerkelijk advies geven maar meer met implementatie van een systeem, ontwikkeling van software etc.

Wat voor consultant TS voor ogen heeft is mij onduidelijk. De situatieschets is niet compleet, maar zoals ik het interpreteer lijkt het op "X doet het niet meer, ingehuurde persoon heeft een dag gewerkt, X werkt weer". Van een adviserende rol lijkt hier in ieder geval geen sprake te zijn.

In deze situatie zou ik wel minimaal antwoord willen hebben op:
"Hoe is het probleem opgelost?"
"Wat is de oorzaak van het probleem?"
"Is het een incident of een structureel probleem?"
"Is er wat gedaan om het probleem in de toekomst te voorkomen?"
"Wat voor mogelijkheden zijn er om het probleem in de toekomst te voorkomen?"

Gezien de antwoorden hier zit niet iedereen daar op te wachten, maar zeg nu zelf: een rekening van de garage waar niet op gespecificeerd staat welke uren gemaakt zijn en wat voor onderdelen vervangen zijn, accepteer je toch ook niet?

[Radical1980]

Ik ben het deels met je eens. Wat ik met name belangrijk vind bij het bouwen van systemen dat het management zelf de werkprocessen in grote lijnen kent of iemand daarvoor te beschikking heeft. Dan hoeft deze persoon geen IT kennis te hebben maar wel weten wat hij nodig heeft om zijn afdeling goed te laten functioneren. Dit kan bijvoorbeeld door de juiste IT toepassingen te hebben of deze te ontwikkelen. Met betrekking tot het inpakken vraag ik mij af wat de toegoevegde waarde is van bijvoorbeeld een projectleider die niet het belang van zijn belanghebbende of stakeholder dient.

Ten aanzien van verspilling schiet dit mij dit direct binnen: zorgsector, bouw

Zorgsector zowel door de bureaucratie maar ik zoiets eenvoudigs dat ongebruikte medicijnen worden weggegooid. Heb bijvoorbeeld wel eens door een fout de verkeerde medicijnen ontvangen. Kan ze terugbrengen maar deze kunnen niet meer opnieuw worden uitgegeven.

De bouw als voorbeeld omdat sommige werkzaamheden door verschillende partijen worden uitgevoerd. Dan moet net zoals in de IT wel eens op elkaar worden gewacht. Soms langer dan men wil.

Uiteraard zijn er voorbeelden van projecten te noemen waar je van kunt zeg "het had achteraf beter gekund.". Zoals reeds eerder gezegd er zijn ook andere sectoren waar die zelfde uitspraak van toepassing is. Ik vind alleen de suggestie dat het met minder ook wel kan als mensen slimmer handelen kort door de bocht. Het kan eenmaal voorkomen dat er tegengestelde belangen in een project aanwezig zijn maar omdat dit te wijten aan de omvang van het budget? Persoonlijk ben ik er niet van overtuigd dat met opzet niet de juiste werkzaamheden worden verricht.

Tsjipmanz schreef op woensdag 22 mei 2013 @ 11:42:
[...]Meestal is er niet een groter IT budget nodig, maar moet het geld gewoon slimmer worden besteed.

Overigens mis ik een voorbeeld van "het geld gewoon slimmer besteden". Het klinkt in de theoretisch gezien goed en logisch maar hoe ziet zoiets er uit? Wanneer is iemand op een "slimme manier zijn geld aan het besteden" en wanneer niet?

[Tsjipmanz]

Radical1980 schreef op donderdag 23 mei 2013 @ 09:49:
[...]
Overigens mis ik een voorbeeld van "het geld gewoon slimmer besteden". Het klinkt in de theoretisch gezien goed en logisch maar hoe ziet zoiets er uit? Wanneer is iemand op een "slimme manier zijn geld aan het besteden" en wanneer niet?

Voorbeeldje: wat je regelmatig ziet is dat de afstemming tussen projecten en beheer erg beroerd is. De projectleider vinkt zijn checklijstje met doelen af, schrijft een close-out rapport en gaat verder met zijn volgende project. Kennisoverdracht is voor een projectleider soms niet meer dan een USB-stick met een paar gig aan documentatie ergens afgeven. Vaak is er na afloop van een project niet precies duidelijk welke (nieuwe) taken en werkzaamheden waar in de organisatie zijn belegd, zijn er knowledge gaps waardoor mensen soms hun werk niet (goed) kunnen doen en de oplostijd van incidenten onnodig hoog is.

Als je je geld "slimmer" had besteed, zou je bijvoorbeeld een PMO kunnen neerzetten die zich focust op de transitie van project naar beheer. Is niet gratis, maar bespaart je een hoop ellende achteraf.

En hiervoor had ik ook al een voorbeeld genoemd he, een uitgebreidere en diepgravender analyse voordat je dure OTS-software gaan aanschaffen en uitrollen, zodat je ook zeker weet dat het aansluit op de manier van werken van een bedrijfsonderdeel. Bij lokale overheden heb ik wel eens paketten gezien die in de basis best goed werken, maar door een beroerde analyse vooraf en dito uitrol simpelweg niet gebruikt werden.

Maar goed, hoe interessant de discussie oko, we gaan wel een beetje offtopic