Projektledare AI beteende: Wait Effect och Override Bias du måste känna till

Projektledare AI beteende visar två paradoxala mönster som kan förstöra projekt: du väntar för länge när AI varnar (Wait Effect), eller ignorerar AI när den har rätt (Override AI bias). PhD-forskning från University of Southampton baserad på 22 projektledare avslöjar att AI inte automatiskt förbättrar beslut – den kan faktiskt förvärra Escalation of Commitment om du inte förstår ditt eget beteende. När AI säger “projektet är i riskzonen” men du tänker “AI förstår inte vårt unika projekt”, aktiverar du Override bias. När AI säger “agera nu” men du tänker “låt oss vänta och se nästa veckas data”, aktiverar du Wait Effect. Båda leder till eskalering.

The Wait Effect: Varför AI-data får dig att vänta istället för agera

Upptäckt: Projektledare som får AI-baserad early warning reagerar långsammare än de utan AI. Paradoxen: mer data = långsammare action.

Mekanismen:

Du får AI-rapport: “75% risk för cost overrun inom 4 veckor baserat på current velocity och burn rate”. Din reaktion är inte omedelbar corrective action, utan:

1. “Låt oss vänta på nästa veckans data” – mer data känns tryggare än beslut nu
2. “AI kan ha fel, projektet är unikt” – rationaliserar inaction
3. “Vi kan vända det när det blir tydligare” – optimism bias förstärks av att “vi har tid”

Varför händer detta?

• Dynamic project data: AI uppdateras kontinuerligt, så du tänker “om jag väntar får jag bättre data”
• Information asymmetry: Du vet saker AI inte vet, så du diskontar AI:s varning
• False security: AI:s precision (75%) skapar illusion av kontroll – “det är ju inte 100%, så vi kan vänta”

Praktisk konsekvens: Studien visar att projektledare med AI-system i genomsnitt agerar 2-3 veckor senare än de utan AI när warning signs uppstår. Detta är tillräckligt för att många projekt eskalerar bortom recovery point.

Din motåtgärd:

Implementera mandatory action window. När AI trigger warning över threshold (t.ex. 70% risk), du har 48 timmar att antingen:

• Implementera corrective action, ELLER
• Explicit dokumentera varför du overridar AI (forced accountability)

Utan deadline fallback:ar du till Wait Effect.

Override AI Bias: När du ignorerar AI av fel skäl

Upptäckt: Projektledare override:ar AI:s recommendations i 60% av fallen, men bara 30% av dessa overrides är justified baserat på outcome.

Trigger factors:

1. Project Uniqueness Perception

“AI är tränad på andra projekt, men vårt projekt är unikt”. Detta är ofta sant – ditt projekt HAR unika aspekter. Men det betyder inte att alla warning patterns är irrelevanta.

Exempel från studien: PM i construction project säger “AI varnar för delay men den förstår inte att vår vendor är ultra-reliable”. AI baserade varning på att material delivery date hade flyttats 3 gånger. PM ignorerade eftersom “de lovar leverans”. Projektet försändes med 6 veckor.

Motåtgärd: Separera “unika inputs” från “unika patterns”. Ditt projekt kan ha unika stakeholders, tech stack, team – men delay patterns (3 date changes = high risk) är generaliserbara. Fråga: “Är det INPUT som är unikt eller OUTCOME PATTERN?”

2. Explainable AI (XAI) Problem

När AI inte kan förklara WHY, du är mer benägen att ignorera. Black box model säger “70% risk” utan förklaring = låg trust.

Studien visar att när XAI används (AI visar vilka faktorer driver prediction), override rate sjunker från 60% till 35%.

Praktiskt: Kräv XAI från dina AI vendors. SHAP, LIME eller liknande explainability tools bör vara standard. Om AI säger “high risk” men inte kan visa att det är pga velocity decline + scope creep + team turnover, hur ska du veta om det är relevant warning?

3. Information Asymmetry Rationalization

“Jag vet saker AI inte vet, så AI:s varning är inte giltig”. Ofta sant – du har kontext AI saknar. Men detta blir excuse för inaction.

Studien visar två typer:

• Legitimate asymmetry: Du vet att key developer återvänder nästa vecka, så current velocity är temporary dip. AI ser bara velocity drop.
• Wishful asymmetry: Du “vet” att teamet kommer hinna ikapp, men baserat på gut feeling, inte evidens.

Motåtgärd: När du override:ar AI baserat på information asymmetry, forced documentation: “AI varnar för X. Jag override:ar för att Y (specify information AI saknar). Om Y inte materializes inom Z dagar, jag pivoterar till AI:s recommendation.”

Detta tvingar dig skilja mellan legitimate och wishful asymmetry.

Trust in AI: Variabeln som minskar båda biases

Studiens viktigaste fynd: trust in AI medierar både Wait Effect och Override bias.

Högt trust = lägre Wait Effect: Om du litar på AI agerar du snabbare när den varnar. Högt trust = lägre Override bias: Om du litar på AI är du mindre benägen att ignorera pga project uniqueness.

Men här är komplexiteten: trust måste vara calibrated, inte blind.

Uncalibrated trust patterns från studien:

Overtrust (blind faith): PM följer AI slaviskt utan att använda egen judgment. Exempel: AI säger “add 2 developers” baserat på velocity. PM gör det utan att fundera på om problemet faktiskt är developer count eller något annat (requirements churn, technical debt).

Undertrust (systematic doubt): PM systematiskt diskontar AI oavsett track record. Även när AI har 85% historical accuracy på liknande projects, PM tänker “AI kan inte förstå vårt projekt”.

Calibrated trust: PM använder AI som en av flera inputs, validerar AI:s assumptions, och justerar baserat på kontext.

Hur bygga calibrated trust:

1. Track AI performance över tid i ditt sammanhang

Dokumentera: När AI varnade, vad hände? När du override:ade, var det rätt beslut?

Exempel-metrics:

• AI warning accuracy: 78% av AI high-risk warnings blev faktiska issues
• Override success rate: 40% av dina overrides var justified (projektet fortsatte on track)
• Wait penalty: Mediantid från AI warning till action = 18 dagar, mediantid till eskalering efter warning = 22 dagar (bara 4 dagar margin!)

2. Explainable AI + context validation

När AI varnar, kolla:

• Vilka faktorer driver prediction? (XAI)
• Är dessa faktorer relevanta för mitt projekt? (context check)
• Vad är historical accuracy när dessa faktorer var närvarande? (calibration)

3. Feedback loops med AI vendor

Om du systematiskt override:ar AI för vissa project types eller situations, feed detta tillbaka till AI modellen. Kanske din project type verkligen HAR unika patterns som borde tränas in.

Fem konkreta interventions för att motverka bias

1. Forced Action Window (mot Wait Effect)

Policy: Vid AI warning >70% risk, 48h deadline för action eller dokumenterad rationale. Ingen “wait and see” utan explicit justification.

Implementation: Dashboard trigger som eskalerar till sponsor om du inte agerar eller dokumenterar inom 48h.

2. Override Accountability Log (mot Override bias)

Template: “AI recommends [X]. I override because [Y]. If [condition Z] not met by [date], I commit to [fallback action].”

Review: Quarterly review av override log med team. Vilka overrides var justified? Pattern recognition.

3. XAI Mandatory för All Predictions

Requirement: AI leverantör måste provide explainability för alla warnings. Ingen black box predictions.

Practical: SHAP values, feature importance, eller similar for varje warning.

4. Trust Calibration Dashboard

Track:

• AI warning → actual outcome (accuracy rate)
• Your override → actual outcome (override success rate)
• Wait time from warning to action (responsiveness)

Visualization: Gör detta visible för dig själv och team. Calibrated trust bygger på evidens, inte feeling.

5. De-biasing Through Scenario Planning

När AI varnar OCH du vill override, forced exercise:

“Scenario A: I override, projektet continues, AI was wrong. Outcome: [describe]” “Scenario B: I override, AI was right. Outcome: [describe]” “Scenario C: I follow AI, implement correction. Outcome: [describe]”

Quantify expected value för varje scenario. Detta bryter både Wait Effect (forced decision) och Override bias (explicit cost-benefit).

Systematic Literature Review insikter

Avhandlingen inkluderar SLR på AI i PM med 63 artiklar. Nyckelinsikter:

AI applications i PM fokuserar på:

• Schedule optimization (mest forskat)
• Cost estimation
• Risk prediction
• Resource allocation

Men minimal forskning på: Projektledares faktiska beteende när de använder AI (detta är vad avhandlingen fyller).

Metodologisk gap: De flesta studier testar AI-modeller på historical data, men inte hur projektledare reagerar på AI:s outputs i real-time.

Praktiskt för dig: När du utvärderar AI-verktyg, fråga inte bara “hur accuracy är modellen?” utan också “finns det evidens för hur projektledare faktiskt använder och reagerar på denna AI:s outputs?”

Från teori till praktik: Din implementation roadmap

Vecka 1: Bias Awareness Audit

Granska dina senaste 3 projekt där AI var involverad:

• Hur många gånger gav AI early warnings?
• Hur snabbt agerade du efter warning?
• Hur många gånger override:ade du AI?
• Vad blev outcome i de fallen?

Identifiera ditt personliga bias-pattern.

Månad 1: Trust Calibration

Sätt upp dashboard för att tracka:

• AI warning accuracy i dina projekt
• Din override success rate
• Average wait time från warning till action

Kvartal 1: Policy Implementation

Implementera mandatory action window policy. Test det på 2-3 projekt. Mät om average response time förbättras.

År 1: Organizational Learning

Bygg organisational override log. Dela learnings quarterly. Identifiera patterns där AI systematically missar (dessa borde feeda tillbaka till modellen) vs patterns där projektledare systematically override:ar felaktigt (dessa behöver training/awareness).

Projektledare AI beteende är inte deterministiskt – det påverkas av trust, explainability, project uniqueness perception och information asymmetry. Men nu när du känner till Wait Effect och Override bias kan du designa systems och policies som motverkar dem. AI är bara så bra som de beslut du fattar baserat på den. Frågan är inte om AI är perfekt, utan om du använder den på rätt sätt.

Källa: “Understanding Project Managers’ Behaviour when using Artificial Intelligence for Project Control” av Fredrik Kockum, University of Southampton, publicerad maj 2025.