Sorry, maar als ik je sommage lees blijft het incompetentie vanuit de klant. Je kunt het verklaren door wat je zegt over geld, politiek of over hoe men met verschillende verantwoordelijkheden te maken heeft - dat geeft meer aan dat jezelf (als instelling) niet de zaken op orde heeft.
En als je intern al je zaken niet goed op orde kunt krijgen wat verwacht je dan van een extern bureau?
Laat ik even per stuk je reactie doornemen:
Dus vanaf dat moment zijn deze grote leveranciers meesters in het vooral vaag houden zodat ze juridisch niet verantwoordelijk kunnen worden gesteld en het de-railen van elke vorm van logica zodat het buiten budget gaat raken.
Hier ben je bij als opdrachtgever. Er is een deadline wanneer iets af moet zijn. Voor iets af moet zijn dan moet je wel voor een bepaalde tijd weten wat er precies gemaakt moet worden. M.a.w als de leverancier het bewust vaag houdt kun jij als opdrachtgever toch stellen dat je verwacht dat de deadline behaald wordt? Je kunt het zo moeilijk maken als je wil, maar je kunt als opdrachtgever ook eisen dat bepaalde zaken duidelijk zijn voor periode x zodat een deadline behaald kan worden.
Voorbeeld: als je vanaf 0 een huis wil laten bouwen en je wil over 2 jaar er wonen. Dan ga je niet 2 jaar wachten tot de architect een keer een duidelijk plaatje heeft terwijl je weet dat het zeker 1 jaar duurt om te bouwen...
Deze leverancier zou daarna een gedetaileerde intake moeten doen met alle stakeholders, een goed plan moeten maken, maar de rekening loopt al, de PO's staan al klaar en de uren worden al geteld.
PO's? bedoel je Product Owners? Die *zijn* er toch al? Aan de opdrachtgever kant mag ik hopen? Als je serieus een PO moet inhuren om jouw belang te vertegenwoordigen dan vraag je al om problemen...
Architectuur vinden ze niet belangrijk ... zolang ze juridisch niet aansprakelijk zijn zal het ze een biet zijn, de opdrachtgevers hebben vaak geen goede architecten in dienst om dit op welke manier dan ook maar in goede banen te leiden. Devops wordt dan toegepast zonder basis blokken te defineren, een prima concept om vooral in kleine groepen totaal andere oplossingen te kiezen.
Ik neem aan dat 'ze' de gemeente / opdrachtgever is. Architectuur is in die zin belangrijk dat het o.a. je nonfunctionals (die vanuit wetgeving ook worden gedicteerd) regelt. Je kunt security niet even erbij plakken, dat moet in de basis goed zitten bijv. Dus als men (opdrachtgever) dat niet belangrijk vind - dan hebben ze niet in de gaten dat ze hier aan moeten voldoen. Dit is ook deels verantwoording bij de opdrachtgever.
Basis documentatie, hierbij leunt de opdrachtgever op de leverancier die immers beloofd heeft om dit helder te krijgen en alles boven water te krijgen voordat ze beginnen. (wat natuurlijk niet wordt gedaan, of passief wordt tegengehouden door ambtenaren die bang zijn dat ze overbodig worden)
Hier speelt inderdaad een andere rol - de opdrachtgever zelf heeft zijn zaakjes niet op orde. Wat er mist is dus een verantwoordelijke (intern) bij de opdrachtgever die de boel stuurt. Deze kan sturen/eisen/managen dat de zaken wel helder worden gemaakt. Ongeacht wat ambtenaren ervan vinden.
Non-funcitonals zijn geen eisen bij een aanbesteding maar moeten beschreven worden door de partij die het aanneemt in detail. Wel worden er grove lijnen uitgezet dat het aan bepaalde richtlijnen moet voldoen, deze zijn vaak alleen toegepast op de huidige (te vervangen) infrastructuur.
Zie architectuur. Zelfde idee.
Project managment is vaak uitbesteed omdat dit soort instellingen vinden dat het niet hun core buisnes is en wordt vaak extern in gehuurd, soms zelfs bij het project. Deze hebben er dus alle belang bij om het zo lang mogelijk te laten duren door rookschermen en andere methodes toe te passen. Niemand van de mensen intern wil verantwoordelijk zijn als het mis gaat dus controlle is er bijna niet.
Hier stip je een heel goed punt aan. In feite zegt de opdrachtgever: "ik heb een opdracht, maar ik wil alleen dat het gebeurd en verder niets - oh en ik weet ook niet precies wat ik wil". M.a.w. er mist totale verantwoordelijkheid voor de uitkomst noch het proces.
Ik snap best dat je voor complexe IT vraagstukken een project management deel laat inhuren door de leverancier. Maar inderdaad, de PO's vanuit de leverancier hebben dubbele belangen. Enerzijds het project afronden, anderzijds voor de leverancier zo veel mogelijk omzet harken.
Wat het 'echte' probleem is is:
Niemand van de mensen intern wil verantwoordelijk zijn als het mis gaat dus controlle is er bijna niet.
En dit snap ik nooit. Als je als organisatie iets *wil*. Dan zorg je er toch voor dat je het krijgt? Er moet toch op z'n minst *iemand* verantwoordelijk worden gesteld voor de uitkomst hiervan? En als niemand bereid is dit te doen, zou je als gemeente dit project simpelweg niet moeten uitvoeren. Zelfs als het van hoger hand komt kun je het terug geven. Dan heb je een andere discussie natuurlijk: waarom wil niemand dit oppakken?
Dit soort instellingen net als gemeentes en rijksoverheid zijn budget geile onderdelen binnen een bedrijf dat zo ontzettend veel verschillende producten moet opleveren dat geen enkel commercieel bedrijf zijn handen eraan zou willen branden. Denk maar na een gemeente doet niet alleen basis administratie, paspoorten maar ook wegenbouw, subsidies, schuld sanering etc. etc. allemaal disiplines die je nooit onder het dak van 1 bedrijf zou vinden. Deze onderdelen vechten allemaal om dezelfde centen die elk jaar binnenkomen. Sabotage en andere passieve vormen van tegenwerking zijn hierbij niet geschuwd en geaccepteerd (immers het bestuur zijn politieke partijen die elkaar op exact dezelfde manier elke 4 jaar besmeuren)
Wat dat betreft gun ik dit soort instellingen meer marktwerking. Dan raken de neuzen misschien iets meer dezelfde kant op (voor wie doen we dit allemaal). Overigens is het niet uniek dat budget verdeeld wordt over afdelingen, dat is in het bedrijfsleven net zo.
Wat de rest van dat stukje betreft - ik zou bijna zeggen dat is puur mensenwerk en heeft niets met IT te maken.
Waterval is niet meer hip. Alles moet agile en scrum met devops. De opdrachtgever daarintegen kan geeneens fatsoenlijk een waterval doen dus ga in een hybride vorm proberen om alles voor elkaar te krijgen. Zonder duidelijke opdracht, zonder goede intake, zonder archtecturele basisblokken en principes , in een politieke organisatie waar de afdelingen vechten om geld en macht.
Yes Agile - de heilige graal... ;-) De grap is, als de leverancier werkelijk agile zou zijn en zich vast houdt aan de principes die eruit voortvloeien - dan zou een project nooit lang bestaan. In mijn ogen zou een project dan niet eens kunnen aanvangen (helemaal als je het in SCRUM wil doen) aangezien de basisvoorwaarden niet voldaan zijn. Maar aangezien de meeste organisatie waterscrum doen of Scrum In Name Only is het meer de modus "we doen maar wat en noemen het Agile".
Wat mist zijn mensen die durven te zeggen dat er iets *niet* kan gebeuren mits er aan bepaalde voorwaarden is voldaan. Zo kun je geen zinnig project starten zonder goed te weten wat het doel is bijv.
Wat dat betreft zijn deze IT projecten die altijd falen een gevalletje: "Vage vraag -> vaag antwoord". En dat kost bakken met geld. Aan de andere kant, we hebben er een hoop mensen (consultants) blij mee gemaakt en de economie gespekt...

De klant organisatie is niet imcompetent, maar heeft hele andere prioriteiten (per individue in andere volgorde)
1. niet de schuld krijgen
2. meer budget binnenharken ten kosten van anderen
3. niet willen veranderen, want veranderen is eng
4. Baanbehoud
5. mocht je ergens verantwoordelijk voor lijken, zo snel mogelijk dit naar een ander weten te krijgen.
6. niet je kop boven het maaiveld uitsteken
Afgaande op het rijtje is mijn conclusie anders. De klant is wel degelijk incompetent en wel om reden: zie rijtje.
Ik wil niet alle schuld bij de klant neerleggen, zeker niet. Maar het is op z'n minst een gedeelde schuld.
Het is jammer, want door dit soort berichten krijgt IT een slechte naam. En ik vind het deels terecht. Een IT organisatie zou ook professioneler kunnen zijn en de opdracht terug kunnen geven met als conclusie: "Dit is niet te doen, we komen nooit uit op een goed resultaat". Zonder plan en doelstellingen blijft het maar doorkabbelen en beland je uiteindelijk in een krant of tweakers.net artikel dat je medeverantwoordelijk bent voor een IT fiasco...
Een organisatie die niet weet waar het heen wil zal overal heen gaan en nergens terecht komen. Dat geld zowel voor de opdrachtgever als de opdrachtnemer.