สิ่งที่เกิด#

Denver International Airport ตั้งใจเปิดปี 1993 — แต่ระบบ baggage automation ทำให้เปิดช้า 16 เดือน

ความเสียหาย:

• ค่า financing ทบทวี $1M/วัน × 16 เดือน
• Cost overrun ของระบบ baggage: $560M
• ต้องสร้างระบบ manual backup ทำคู่กัน

Project failure pattern#

1. Scope explosion กลางทาง

• เริ่มต้น: BAE Automated Systems รับ implement สำหรับ United Airlines เท่านั้น
• กลางโปรเจค: เมือง Denver ตัดสินใจ expand ให้ครอบคลุมทั้งสนามบิน
• ไม่ reset schedule + budget — keep timeline เดิม

2. ไม่มี master integrator

• Vendors หลายราย — แต่ไม่มีคนรับผิดชอบ system-of-systems
• Integration ไม่ได้ถูก plan

3. Schedule pressure

• Deadline politically driven — เมืองอยาก open ตามที่ promise ผู้ลงคะแนน
• Vendor บอก “ทำไม่ทัน” → bypassed

4. Testing skipped

• Time pressure → integration testing → cut
• รถส่ง bag ฉีกกระเป๋าตอน demo

Lesson#

Scope จาก subsystem → system-of-systems = different project — ต้อง reset estimate, schedule, team ไม่ใช่ “ขอให้ทำเหมือนเดิม แต่ใหญ่กว่า”

💡 PM principle: Scope creep + fixed schedule = disaster

สิ่งที่เกิด#

UK พยายามสร้าง electronic health record ที่ unified ทั่ว NHS (National Health Service)

ความเสียหาย:

• ตั้งงบ £6B → จริง £12B+
• National Audit Office: £10B+ wasted
• Officially dismantled 2011
• บางส่วน rescue ไป — ส่วนใหญ่ wasted

Project failure pattern#

1. Top-down design

• Government ตัดสินใจระดับ national — clinician (หมอ + พยาบาล) ไม่ engage
• ระบบ design ไม่ตรงกับ workflow จริง

2. Mega-contract = ทุกอย่างใน 1 ครั้ง

• 5 prime contractors
• Each contractor £1B+
• Big bang approach

3. Vendor failure

• Accenture pull out 2006 (เสีย £450M)
• Fujitsu contract terminated 2008
• iSoft (key software vendor) ล้มละลาย

4. Requirement instability

• NHS reform ระหว่าง project = requirement เปลี่ยน
• Spec ไม่เคย stable

5. ไม่มี clinical leadership

• IT-driven project — clinicians มอง outsider
• Adoption rate ต่ำ — แม้ระบบเสร็จก็ไม่ใช้

Lesson#

Mega-project + bottom-up adoption needed = ต้อง engage user ก่อน ไม่ใช่หลัง Big bang IT in healthcare = doom — ต้อง phased + iterative

💡 PM principle: ลูกค้าปลายทางไม่ engage → ระบบดี ก็ไม่ใช้

สิ่งที่เกิด#

T5 เป็น project building ที่ เสร็จ on time, on budget — เป็น legend ใน construction industry

แต่: วันแรก operations chaos:

• 42,000 bags lost ใน 10 วัน
• 500 flights cancelled
• BA สูญ £16M ตรง

Project failure pattern#

1. Building project ≠ operations project

• T5 building เสร็จดี
• T5 operations rollout (IT, training, baggage system) — ไม่ได้ rehearse end-to-end

2. Insufficient end-to-end testing

• ระบบ test เป็นชิ้น
• ไม่เคย test “vol full” — ระบบหัวแตก

3. Staff training ขาด

• Staff หลายคน first day = first time
• ไม่มี dry run

Lesson#

“Project complete” ≠ “Operations ready” Cutover/launch is its own project — ต้องมี dedicated team + plan + dry run

💡 PM principle: Build phase ≠ Go-live phase — แยก plan, แยก budget

สิ่งที่เกิด#

Boeing เร่งสร้าง 737 MAX แข่งกับ Airbus A320neo

ใส่ engine ใหญ่ขึ้น — เปลี่ยน aerodynamic — เพื่อ “fix” ใส่ software ชื่อ MCAS (Maneuvering Characteristics Augmentation System)

ผลลัพธ์:

• Lion Air JT610 (2018) — 189 ตาย
• Ethiopian ET302 (2019) — 157 ตาย
• รวม 346 ตาย
• Worldwide grounding 20 เดือน
• Boeing ขาดทุน $20B+

Project failure pattern (governance + PM combined)#

1. Schedule pressure overrode safety

• Airbus เริ่ม A320neo ก่อน
• Boeing ต้อง launch MAX ภายใน window แคบ
• Engineering concern → suppressed

2. Safety analysis flawed

• MCAS ใช้ single sensor input สำหรับ flight-critical system
• Assumption: pilots react in 4 seconds
• ความจริง: pilots ตกใจ 30+ seconds

3. FAA certification captured

• Boeing’s ODA program — Boeing approve เอง (regulatory capture)
• FAA review ไม่เข้ม

4. Pilot training suppressed

• ถ้าต้อง pilot training extra → simulator-cost flag
• → airlines ต้องจ่ายเพิ่ม → ขายไม่ดี
• Boeing ระบุไม่ต้อง training — ไม่บอก pilot ด้วยซ้ำว่ามี MCAS

5. Whistleblower ignored

• Engineers internal raise concern → suppressed

Lesson#

Schedule pressure + cost pressure overriding engineering judgment + captured oversight = ตาย

💡 PM principle: Safety-critical = never take shortcut — schedule second to safety

สิ่งที่เกิด#

Obamacare website launch 1 ตุลาคม 2013

Day 1: crash ภายใน 2 ชั่วโมง — 6 ของผู้ใช้แรก 8M เข้าได้

Project failure pattern#

1. Multi-vendor ไม่มี master integrator

• 55 contractors
• ไม่มี end-to-end owner
• Integration testing fail

2. Waterfall ใน fast-moving environment

• 3-year project, requirement เปลี่ยนรายเดือน
• ไม่ iterate

3. Testing ไม่พอ

• Load testing → 500 simultaneous users (เปิด day 1 = 250,000)
• ไม่มี penetration testing เพียงพอ

4. No tech leadership

• Government project — leadership = lawyer + admin
• ไม่มี CTO

Recovery#

Obama ส่ง tech surge — Silicon Valley engineers เข้ามาช่วย

• Mikey Dickerson (Google SRE) lead
• Daily standup, fast iteration, monitoring

ภายใน 2 เดือน — site stable

Lesson#

Tech project ต้องมี tech leadership Multi-vendor ต้องมี master integrator Big-bang launch = high risk — ทำ phased rollout ดีกว่า

Origin#

Fred Brooks manage IBM OS/360 (1960s) — operating system ใหญ่สุดในยุคนั้น

ตอนช้า — IBM ใส่คนเพิ่ม → ช้าลงอีก

Brooks เขียนหนังสือเป็น postmortem

Brooks’ Law#

“Adding manpower to a late software project makes it later.”

(เล่าใน EP.10)

บทเรียนอื่นจาก Brooks#

1. “No silver bullet”

• ไม่มี technique เดียวที่ให้ 10x productivity
• All progress เป็น 2x มากที่สุด ภายใน decade

2. “Plan to throw one away; you will, anyhow”

• First version ของ system ผิด — sure
• Plan ไว้ตั้งแต่ต้นว่าจะ throw away

3. “Conceptual integrity”

• ระบบที่ออกแบบโดย 1 ใจ → simpler + better
• Group design = compromise everywhere

สิ่งที่เกิด#

Therac-25 = radiation therapy machine Software bug → patient ได้ radiation 100x ที่ควรได้

6 patients ตาย หรือเสีย organ permanent

Project failure pattern#

1. Reuse software จากรุ่นเก่าโดยไม่ verify

• Therac-25 reuse code จาก Therac-20 (ที่มี hardware lock)
• Therac-25 ตัด hardware lock — software อย่างเดียว
• Software bug ที่ Therac-20 ป้องกันโดย hardware → expose ใน Therac-25

2. ไม่มี independent code review 3. Race condition — เกิดเฉพาะตอน operator พิมพ์เร็ว 4. Bug report ถูก dismiss — “ไม่ reproduce” 5. No fail-safe design

Lesson#

Safety-critical software ต้องมี independent verification + redundancy + fail-safe

Bonus: Whistleblower ignored#

Boeing, Therac-25, Wells Fargo (governance EP), FTX — pattern อมตะ: คนภายในเตือนล่วงหน้าทุกเคส — แต่ถูก suppress

ระบบ governance ที่ดี = whistleblower channel ที่ใช้งานได้