ตัวอย่าง: 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” — ไม่ได้ซื้อ “การพิมพ์โค้ด”

💡 Connect to CISA D3-24: CISA D3 พูดถึง “WBS ต้อง deliverable-based ไม่ใช่ task-based” — ตอนนี้คุณเข้าใจว่าทำไม

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 = ห่วงโซ่กิจกรรมที่ห้ามล่าช้า

ถ้า activity ใน critical path ช้า 1 วัน — ทั้งโปรเจคช้า 1 วัน ถ้า activity ที่ไม่อยู่ใน critical path ช้า — อาจไม่กระทบ (มี slack)

ตัวอย่างง่ายๆ#

Project มี 5 activities:

• A: 3 วัน (เริ่มต้น)
• B: 4 วัน (หลัง A)
• C: 2 วัน (หลัง A, parallel กับ B)
• D: 5 วัน (หลัง B)
• E: 1 วัน (หลัง C + D)

2 paths:

• Path 1: A → B → D → E = 3 + 4 + 5 + 1 = 13 วัน
• Path 2: A → C → E = 3 + 2 + 1 = 6 วัน

Critical path = Path 1 (ยาวสุด) Slack ของ C = 13 - 6 = 7 วัน (C ช้าได้ 7 วัน ก่อนกลายเป็น critical)

สูตร CPM#

Forward pass (หา earliest start/finish):

• ES (Earliest Start) ของ task = max(EF ของ predecessors)
• EF (Earliest Finish) = ES + Duration

Backward pass (หา latest start/finish):

• LF (Latest Finish) ของ task = min(LS ของ successors)
• LS (Latest Start) = LF - Duration

Slack/Float = LS - ES (หรือ LF - EF — ค่าเดียวกัน)

Activity ที่อยู่ critical path: Slack = 0

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

1. Focus management attention — ใส่พลังงานกับ task ใน critical path ก่อน 2. Schedule compression — อยากเร่ง project? เร่งใน critical path เท่านั้น (เร่งใน non-critical = wasted) 3. Risk management — task ใน critical path = high risk, ต้องมี mitigation

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