ตัวอย่าง: Project ติดตั้ง CRM#

WBS:

1
1. CRM Implementation
2
   1.1 Requirements
3
       1.1.1 Sales requirements
4
       1.1.2 Marketing requirements
5
       1.1.3 Customer service requirements
6
   1.2 Configuration
7
       1.2.1 Account model
8
       1.2.2 Contact model
9
       1.2.3 Opportunity pipeline
10
   1.3 Integration
11
       1.3.1 ERP integration
12
       1.3.2 Email integration
13
   1.4 Migration
14
       1.4.1 Data extraction (legacy)
15
       1.4.2 Data transformation
16
       1.4.3 Data load
17
   1.5 Training
18
   1.6 Go-live

ทุก item เป็น deliverable (สิ่งที่ส่งมอบได้) ไม่ใช่ task

กฎสำคัญของ WBS#

• 1. 100% rule — ทุก scope ต้องอยู่ใน WBS — ลืม = ไม่ได้ทำ
• 2. Deliverable-based — noun ไม่ใช่ verb (อย่าใส่ “design” “build” — ใส่ “Design document” “Built module”)
• 3. 8/80 rule — work package (leaf node) ใช้เวลา 8 ชั่วโมง — 80 ชั่วโมง ใหญ่กว่า split, เล็กกว่า รวม
• 4. Mutually exclusive — work package ห้าม overlap

WBS สร้างยังไง#

Top-down decomposition:

1. เริ่มจาก deliverable สุดท้าย (level 1)
2. แบ่งเป็น major component (level 2)
3. แบ่งต่อจนถึง work package (level 3-5)
4. เลิก decompose เมื่อ:
   • ใช้เวลา 8-80 ชั่วโมง
   • มี clear deliverable
   • Estimate ได้แม่นยำ

ทำไม WBS ต้องเป็น deliverable ไม่ใช่ task?#

เพราะถ้าเป็น task — task list เปลี่ยนได้ตามวิธีทำ แต่ deliverable เป็นข้อตกลงกับลูกค้า

ลูกค้าซื้อ “Built module” — ไม่ได้ซื้อ “การพิมพ์โค้ด”

แต่ — task หายไปไหน? อยู่ที่ Work Package#

หลายคนอ่านถึงตรงนี้แล้วงงครับ ถ้า WBS เป็น deliverable หมด แล้ว task ที่ต้องทำจริงๆ อยู่ที่ไหน?

คำตอบ — task อยู่ใน Work Package (กล่องล่างสุดของ WBS)

ลองเทียบกับการ สร้างบ้าน:

ระดับ zoom out (โครงสร้าง WBS) — ที่เห็นในแผนผัง:

1
สร้างบ้าน
2
├── ฐานราก ส่งมอบเสร็จ           ← deliverable
3
├── โครงสร้างหลัก ส่งมอบเสร็จ      ← deliverable
4
└── ระบบไฟฟ้า ส่งมอบเสร็จ          ← deliverable

ทุกกล่อง = ของที่ส่งมอบได้ (noun)

ระดับ zoom in (เปิด leaf node ออกดู):

1
"ฐานราก ส่งมอบเสร็จ" (Work Package)
2
   tasks ภายใน:
3
   - ขุดดิน
4
   - เทคอนกรีต
5
   - ฝัง rebar
6
   - ตรวจรับงาน

task อยู่ข้างใน Work Package — ไม่อยู่ในโครงสร้าง WBS

WBS = tree ของ deliverable ที่แต่ละ leaf เก็บ task ไว้ข้างใน — ไม่ใช่ flat task list, ไม่ใช่ deliverable-only tree ที่ลอยอยู่. มี 2 ชั้น zoom

💡 Connect to CISA D3-24: CISA D3 พูดถึง “WBS ต้อง deliverable-based” + ใช้ OBS (object breakdown structure) เป็น tool ที่มาก่อน WBS อีกชั้น. ลึกกว่าใน D3.24

Modern Gantt (Microsoft Project, Asana, Monday.com)#

เพิ่มของไว้ใน Gantt:

• Dependencies (arrow ระหว่าง bar)
• Critical path (ขีดสีแดง)
• % Complete (แถบสีในแท่ง)
• Milestone (เพชร ◆)
• Resource assignment

Gantt + WBS#

Gantt มาจาก WBS — WBS บอก อะไร, Gantt บอก เมื่อไหร่

1
WBS: 1.4.1 Data extraction
2
        ↓
3
Gantt: [████] week 5-6

Concept ที่สำคัญที่สุดใน Project Scheduling#

Critical Path = ห่วงโซ่กิจกรรมที่ห้ามล่าช้า ถ้างานบนเส้นนี้ช้า 1 นาที โปรเจคทั้งโปรเจคช้า 1 นาที ส่วนงานที่อยู่นอกเส้นนี้ช้านิดหน่อยอาจไม่กระทบ เพราะมี slack (เวลาว่างซ่อนอยู่) คอยรองรับ

ตัวอย่าง: ทำแซนด์วิชไข่#

เอาของในครัวมาเล่าน่าจะเห็นภาพชัดสุดครับ สมมติจะทำ “แซนด์วิชไข่” 1 ชิ้น มี 3 งาน:

หน้าตา dependency:

graph LR
  A["A: อบขนมปัง<br/>3 นาที"] --> C["C: ประกบ<br/>1 นาที"]
  B["B: ทอดไข่<br/>2 นาที"] --> C
  style A fill:#fca5a5,color:#000
  style C fill:#fca5a5,color:#000
  style B fill:#bbf7d0,color:#000

Step 1 — Forward pass (คิดเดินหน้า หา ES, EF)#

สูตร:

• ES (Earliest Start) = max(EF ของงานก่อนหน้า) ถ้าเริ่มเลยได้ ก็ ES = 0
• EF (Earliest Finish) = ES + Duration

ลองเดินจากต้น:

→ โปรเจคใช้เวลาทั้งหมด 4 นาที (EF ของงานสุดท้าย)

สังเกตว่า C ต้องเริ่มที่นาทีที่ 3 ถึงไข่จะทอดเสร็จตั้งแต่นาทีที่ 2 ก็ต้องนั่งรอขนมปังอยู่ดี

Step 2 — Backward pass (คิดถอยหลัง หา LS, LF)#

สูตร:

• LF (Latest Finish) = min(LS ของงานต่อไป) งานท้ายสุดเอาค่า EF เป็นจุดตั้ง
• LS (Latest Start) = LF − Duration

เดินถอยจากท้าย:

Step 3 — Slack = LS − ES (ถ่วงได้กี่นาทีก่อนพัง)#

Intuition ของ Slack: ทำไมทอดไข่ช้า 1 นาทียังไม่พัง? เพราะยังไง C ก็ต้องรอขนมปัง 3 นาทีอยู่ดี ทอดไข่เสร็จเร็วกว่าก็แค่นั่งรอเฉยๆ นี่แหละคือ “slack” — เวลาว่างที่ซ่อนอยู่ในแผน

Step 4 — Critical Path = งานที่ Slack = 0#

จากตาราง A → C คือ Critical Path ถ้าอยากให้แซนด์วิชเสร็จเร็วขึ้น เร่งทอดไข่ไม่ช่วย เพราะมันไม่ใช่ critical ต้องไปเร่งอบขนมปัง (ซื้อขนมปังสำเร็จมาเลยมั้ย? ใช้เตาอบที่ร้อนกว่า?) นั่นแหละคือสิ่งที่ CPM ตอบ

ทำไม CPM สำคัญใน real life#

• 1. Focus management attention ใส่พลังงานกับ task บน critical path ก่อน งานนอกเส้นมี slack รองรับอยู่
• 2. Schedule compression อยากเร่ง project? เร่งบน critical path เท่านั้น (เร่งงานนอกเส้น = ทุ่มเงินฟรี เพราะมันไม่ใช่ตัวกำหนดวันจบ)
• 3. Risk management งานบน critical path = high risk ต้องมี mitigation plan + buffer แยกต่างหาก

Difference จาก CPM#

CPM ใช้ fixed duration — แม่นยำ ใช้กับงานที่เคยทำมาก่อน

PERT ใช้ probabilistic duration — สำหรับงานที่ไม่แน่นอน

PERT estimate (3-point estimation)#

ทุก activity มี 3 ค่า:

• O (Optimistic) — เร็วสุดถ้าโชคดี
• M (Most Likely) — ปกติ
• P (Pessimistic) — ช้าสุดถ้าเจอปัญหา

สูตร:

1
PERT estimate = (O + 4M + P) / 6
2
Standard deviation = (P - O) / 6
3
Variance = ((P - O) / 6)²

ตัวอย่าง#

Activity X:

• O = 3 วัน (เร็วสุด)
• M = 5 วัน (ปกติ)
• P = 11 วัน (ช้าสุด)

PERT estimate = (3 + 4×5 + 11) / 6 = 34/6 = 5.67 วัน SD = (11 - 3) / 6 = 1.33

ใช้ค่านี้ใน schedule แทน fixed duration

เมื่อไหร่ใช้ PERT vs CPM#

ในชีวิตจริง — ผสมใช้ — เรียก “CPM analysis with PERT estimates”

ปัญหาที่ EVM แก้#

ถ้า project ใช้ budget ไป 80% แล้ว — เกือบเสร็จไหม?

คำตอบ: ไม่รู้! เพราะ “เงิน 80%” ไม่ได้บอก “งาน 80%”

EVM แก้โดยใช้ 3 ตัวเลข:

3 Numbers ของ EVM#

1. PV — Planned Value (เคยเรียก BCWS = Budgeted Cost of Work Scheduled) “ตามแผน วันนี้น่าจะเสร็จงานมูลค่าเท่าไหร่”

2. EV — Earned Value (เคยเรียก BCWP = Budgeted Cost of Work Performed) “จริงๆ วันนี้เสร็จงานมูลค่าเท่าไหร่”

3. AC — Actual Cost (เคยเรียก ACWP = Actual Cost of Work Performed) “ใช้เงินไปจริงเท่าไหร่”

Indices#

SPI — Schedule Performance Index = EV / PV

• SPI = 1.0 → on schedule
• SPI < 1.0 → behind schedule (เช่น 0.8 = ช้ากว่าแผน 20%)
• SPI > 1.0 → ahead of schedule

CPI — Cost Performance Index = EV / AC

• CPI = 1.0 → on budget
• CPI < 1.0 → over budget (เช่น 0.85 = ใช้เงินเกินแผน 15%)
• CPI > 1.0 → under budget

ตัวอย่าง: Project 6 เดือน, budget 6M บาท#

วันที่ 90 (เดือนที่ 3 — กลาง project):

• PV = 3M (ตามแผนน่าจะเสร็จงานมูลค่า 3M)

• EV = 2.4M (จริงๆ เสร็จงานมูลค่า 2.4M)

• AC = 2.7M (ใช้เงินไปแล้ว 2.7M)

• SPI = 2.4 / 3.0 = 0.8 → behind 20%

• CPI = 2.4 / 2.7 = 0.89 → over budget 11%

สถานการณ์: ทั้งช้าและเกินงบ

Forecast: EAC (Estimate at Completion)#

ถ้า trend นี้ต่อไป — จบ project ใช้เงินเท่าไหร่?

EAC = BAC / CPI

จากตัวอย่าง: BAC = 6M, CPI = 0.89 EAC = 6 / 0.89 = 6.74M

แปลว่า: ถ้าไม่แก้อะไร project จะใช้เงินเกินงบ 0.74M (12.5%)

EVM ใช้กับ Agile ได้ไหม?#

ได้ในบางรูปแบบ — เรียก “AgileEVM” หรือ “Agile Earned Value”:

• Story point → เป็น “value”
• Sprint cadence → measure ทุก sprint

แต่ purist ของ Agile ไม่ค่อยใช้ — เพราะ EVM assume scope fixed

กฎทอง: ต้องมี W ที่ชัดเจน#

ปัญหาที่เจอบ่อย: ทีม mark ทุกอย่างเป็น Must — เพราะกลัว stakeholder โกรธ

ผลลัพธ์: ไม่มี priority จริง = ทำทุกอย่าง = ทำไม่ทัน

แก้: บังคับให้ at least 20% เป็น Won’t have — กรองให้ตัดสินใจจริง

ใช้ MoSCoW เมื่อไหร่#

• ใน sprint planning
• ใน release planning
• ตอน scope negotiation กับ sponsor

ทำไม project ใหญ่ๆ ช้าเสมอ — 3 พฤติกรรมที่ทีมเป็นกันหมด#

ก่อนเข้า 4 steps ของ CCM ทำความเข้าใจปัญหาที่มันแก้ก่อนครับ

1. Parkinson’s Law — “งานจะขยายเต็มเวลาที่ให้” ให้ 10 วัน ก็ใช้ 10 วัน ทั้งที่จริงๆ 5 วันก็เสร็จได้ คนไม่อยากส่งงานก่อนกำหนด เพราะกลัวว่ารอบหน้าจะถูกบีบเวลา หรือกลัวเหมือนประเมินเวลาเผื่อไว้มากเกิน

2. Student Syndrome — “รอใกล้ deadline ค่อยเริ่ม” เหมือนเด็กที่ทำการบ้านคืนสุดท้าย ให้เวลา 10 วัน → รอวันที่ 8 ค่อยลงมือ → พอเจอปัญหาตอน hour-11 ก็สายไปแล้ว

3. Bad Multitasking — “กระโดดไปมาระหว่าง task” คนเดียวต้องทำ A, B, C พร้อมกัน → ทำ A ครึ่งหนึ่ง สลับไป B สลับไป C → ทุกอย่างเสร็จช้าหมดเพราะ context switching

ผลลัพธ์คือทีมประเมินเวลาเผื่อ (safety buffer) ไว้แล้ว แต่ buffer หายฟรีเพราะ 3 พฤติกรรมข้างบน CCM 4 steps คือยาแก้พฤติกรรม 3 ข้อนี้โดยตรง

Step 1 — Resource Leveling (จัดคิวคนก่อน)#

จุดที่ CCM แยกทางกับ CPM ชัดเจน

• CPM (เน้นงาน): ถ้างาน A กับ B ไม่ได้รอกัน → ทำพร้อมกัน (parallel)
• CCM (เน้นคน): ถ้า A กับ B ต้องใช้ “คนเดียวกัน” → ทำพร้อมกันไม่ได้ ต้องเรียง sequence

กลับมาที่ตัวอย่างแซนด์วิช ตอนแรกเราอบขนมปัง + ทอดไข่ พร้อมกันได้ เพราะมี 2 มือ 2 เตา แต่ถ้า:

• มีคนทำคนเดียว และมีเตาเดียว
• ต้องอบขนมปังก่อน (3 นาที) แล้วค่อยทอดไข่ (2 นาที) แล้วค่อยประกบ (1 นาที)

Critical Chain = 3 + 2 + 1 = 6 นาที (ไม่ใช่ 4 นาทีแบบ CPM)

เส้นทางใหม่ที่เกิดจาก “คิวงานของคน/ทรัพยากร” เรียกว่า Critical Chain

Step 2 — Aggressive Estimation (หั่นเวลาเผื่อทิ้งครึ่ง)#

พอได้ Critical Chain แล้ว CCM บังคับ “รีดไขมัน” ออกจากแต่ละงาน

ปกติทีมประเมินแบบ “Safe Estimate” (มั่นใจ 90% ว่าทันแน่) งานที่ทำจริง 5 วัน บอก 10 วัน เผื่อปัญหา

CCM ให้หั่นทิ้งครึ่ง เหลือเฉพาะเวลาทำงานแบบ “ตึงมือสุดๆ” (50% confidence)

• 10 วัน → หั่นเป็น 5 วัน
• ทุกงานในโปรเจคทำแบบเดียวกันหมด

ฟังดูบ้าใช่มั้ยครับ 555+ แต่มีเหตุผล เวลาเผื่อ 5 วันที่หั่นออก ยังไงมันก็จะหายเพราะ Parkinson’s + Student Syndrome อยู่แล้ว CCM ไม่ได้ทิ้ง แต่เอามารวมกองใหม่ใน Step 3

Step 3 — Project Buffer (กองกลางท้ายโปรเจค)#

เวลาเผื่อที่หั่นจากทุกงาน ไม่คืนให้ทีม แต่ เอามาแปะรวมไว้ท้าย Critical Chain

ตัวอย่าง:

• งาน 3 ชิ้น หั่นได้ชิ้นละ 5 วัน → รวม 15 วัน
• CCM ใช้แค่ครึ่งเดียว (~7-8 วัน) เป็น Project Buffer
• แปะไว้ก่อนวันส่งมอบ

graph LR
  T1["งาน 1<br/>(หั่นแล้ว)"] --> T2["งาน 2<br/>(หั่นแล้ว)"] --> T3["งาน 3<br/>(หั่นแล้ว)"] --> PB["Project<br/>Buffer"] --> END[ส่งมอบ]
  style PB fill:#fbbf24,color:#000
  style END fill:#86efac,color:#000

ข้อดี 3 ข้อ:

1. วันส่งมอบโดยรวมสั้นลง เพราะ buffer รวมน้อยกว่าผลรวมของ buffer ทุกคน
2. ใครช้าก็เบิกจากกองกลาง แทนที่จะแบกความเครียดเอง
3. PM แค่จับตาดู Buffer Consumption ถ้ากินเร็วเกินครึ่งทาง = สัญญาณว่า project มีปัญหา

Step 4 — Feeding Buffer (โช้คอัพสายรอง)#

ในโปรเจคจริงมี “สายงานรอง” ที่ไม่ได้อยู่บน Critical Chain แต่ต้องเชื่อมเข้ามาทีหลัง

ปัญหา: ถ้าสายรองช้า ก็กระเด็นไปเตะ Critical Chain ให้ช้าตาม

วิธีแก้: ใส่ Feeding Buffer ตรงจุดที่สายรองจะเข้ามาเชื่อม เหมือนโช้คอัพรถซับแรงกระแทก ไม่ให้ความล่าช้าของสายรองทะลุเข้าสาย critical

graph LR
  M1["สายหลัก 1"] --> M2["สายหลัก 2"] --> END[ส่งมอบ]
  S1["สายรอง"] --> FB["Feeding<br/>Buffer"] --> M2
  style FB fill:#fbbf24,color:#000
  style END fill:#86efac,color:#000

CPM vs CCM — เทียบกันตรงๆ#

สมการสรุปง่ายๆ#

Critical Chain = ลำดับงาน (Logical) + คิวคน (Resource) + บริหาร Buffer รวม

ข้อจำกัด#

• ทีมต้องเปิดใจ หั่นเวลาเผื่อทิ้งครึ่ง ฟังดูเหมือนถูกบีบ ถ้าไม่อธิบาย Project Buffer ดีๆ ทีมจะต้านแน่นอน
• ต้อง track buffer consumption ทุกอาทิตย์ overhead เพิ่ม
• ไม่เข้ากับ Agile เพราะ Agile assume scope flex แต่ CCM assume scope fix
• เหมาะกับ project มีเดดไลน์ตายตัว + ทรัพยากร share เยอะ (R&D, construction, manufacturing)