Det som @KAD skrev är faktiskt så det ser för många större projekt >1500h, speciellt mot industrin/kommun/stat eller där man har en motpart/beställare som driver ett parallellt industri/verksamhets projekt, och när man pratar om stora multi-nationella företag inom/utanför Sverige. Vanligtvis så kanske man behöver involvera 10+ olika team för att driva igenom de stora projekten.
Normal så ser inte en typisk utvecklare detta eftersom han/hon jobbar i sitt team och det är projektledarens roll att samla in och koordinera med andra team/projekt.
"Resurstilldelningen är baserad på hur många personer som sitter på bänken (det är inte de mest begåvade), inte när pengarna tar slut (för fort) eller hur mycket som ska göras (för få utvecklare för att klara deadline). Det blir till att lägga några manveckor på krismöten och omplanering när det blir tydligt."
Detta är typiskt när man mixar in-house med nya konsulter för utveckling och det teamet som kanske borde ta utvecklingen inte har tid eller mappar exakt mot vad som väntas levereras.
"Att skaffa fram test- och driftmiljöer samt konton och licenser till rätt utvecklare har ledtider på minst en månad och den på beställarsidan som kan göra det har tidig semester i år…"
Eftersom kod repositories ligger inom företaget som driver projektet (in-house) så måste alla nya konsulter on-boardas med nya datorer/inloggingskonton/server inloggnings konton. Licenser och rättigheter för t.ex. Azure DevOps Server, utvecklingsmiljöer, databaser måste beställas/sättas.
Nya servrar för system test/applikations integrations tester/produktion måste beställas. Server hallen börjar bli full och ledtiden för att köpa in den certifierade hårdvaran är längre än vanligt (https://www.dell.com/en-us/lp/dell-supply-chain-updates).
"Lösningen måste så klart uppfylla alla relevanta juridiska krav och interna policies. Nej, vi har inte dokumenterat vilka de är, arbetsgruppen som ska ta fram det är klara till jul. Glöm inte att halva arbetsflödet ska kunna genomföras i ett system som vi ska upphandla nästa år."
Olika länder har olika juridiska krav t.ex. av var data får sparas. Det händer att en standard lösning som redan används inte kan användas i ett land och helt plötsligt så måste en special lösning tas fram och naturligtvis så är det teamet som äger den lösningen fullbelagt de närmaste 3-4 månaderna.
Ibland så ska ett nytt COTS/SaaS system köpas in som det nya systemet som byggs ska agera med, men eftersom vilket system inte är helt bestämt så behöver man avvakta med detaljerna om vad som ska utföras däri och hur integrationen kommer att se ut.
En av många interna policies är att TLS 1.3 måste användas för all integration. Men det visar sig att en mainframe lösning som det nya systemet behöver hämta data från inte har support för det och måste uppgraderas men eftersom mainframe inte är utpekat som en prioriterat teknik så behöver infrastruktur/OS teamen lägga en extra begäran till den tekniska policy teamet att få börja arbetet.
Det som beskrev ovan finns men det är långt ifrån allt som är så komplext. Många gånger handler det om bara om att ta fram en lösning för ett verksamhets behov inom ett befintligt system. För de flesta företagslösningar så ligger 90% i backend och kanske 10% i frontend.