Direct vs Indirect#

Direct cost = ค่าใช้จ่ายที่ระบุได้กับ project นี้โดยตรง

• เงินเดือน developer ที่ทำ project นี้ 100%
• License software ที่ซื้อสำหรับ project
• Server ที่เปิดให้ project

Indirect cost = ค่าใช้จ่ายที่ allocate มาจาก overhead

• ไฟฟ้า + อินเทอร์เน็ตของ office
• เงินเดือน HR + admin (allocate %)
• Insurance + facility

ทำไมสำคัญ: Project budget ส่วนใหญ่ track แค่ direct — แต่ TCO (Total Cost of Ownership) ต้องรวม indirect ด้วย

Fixed vs Variable#

Fixed cost = ไม่ขึ้นกับปริมาณงาน

• License ปีละ X (ไม่ว่า user จะกี่คน)
• ค่าเช่า server fixed-tier

Variable cost = ขึ้นกับปริมาณงาน

• Cloud computing — ใช้เยอะจ่ายเยอะ
• Per-transaction fee
• Hourly contractor

Mixed cost = base fixed + variable on top

• AWS ปกติ — base infrastructure + per-usage

ทำไมสำคัญ: project ที่มี variable cost สูง → uncertainty สูง → ต้องมี contingency เยอะ

CAPEX vs OPEX#

CAPEX (Capital Expenditure) = ลงทุน asset ที่ใช้ระยะยาว

• ซื้อ server (ใช้ 3-5 ปี)
• พัฒนา software ที่ capitalize ได้ (ภายใต้เงื่อนไขทางบัญชี)
• ซื้อ license ตลอดชีพ

→ แสดงเป็น asset ในงบดุล, ตัด depreciation ทีละปี

OPEX (Operational Expenditure) = ค่าใช้จ่ายประจำ

• Cloud subscription รายเดือน
• เงินเดือน
• Maintenance fee

→ แสดงเป็น expense ในปีนั้น

ทำไมสำคัญสำหรับ PM:

ผู้บริหารส่วนมาก ชอบ OPEX มากกว่า CAPEX ในยุคปัจจุบัน — เพราะ:

• Tax deduction ทันที (ไม่ต้องรอ depreciate)
• Cash flow ดีกว่า (ไม่ต้องจ่ายก้อนใหญ่ครั้งเดียว)
• Flexibility — ยกเลิกได้

นี่คือเหตุผลที่ Cloud (OPEX) ดัง — แทน on-premise (CAPEX)

แต่ทั้งคู่มี trade-off — long-term cost ของ cloud อาจสูงกว่า on-premise

💡 PM context: ตอน present business case — ต้อง understand ว่า sponsor มอง project เป็น CAPEX หรือ OPEX — เพราะ tax + accounting treatment ต่างกัน

Sunk Cost — Cost ที่จมไปแล้ว#

Sunk cost = เงินที่จ่ายไปแล้ว ไม่ได้คืน

Sunk Cost Fallacy = ตัดสินใจอนาคตโดยพิจารณา sunk cost — ผิด!

ตัวอย่าง:

• Project ใช้เงินไป $5M แล้ว → ผู้บริหารบอก “ลงไปแล้ว ต้องทำต่อให้คุ้ม”
• ถูก decision: ลืม $5M ไป — ดูแค่ "ลงเพิ่มอีก$X จะได้ value $Y ไหม”
• ถ้า $X >$Y → kill project (cut loss)

Famous quote (Sherlock Holmes):

“What is past is prologue.”

ใช้แค่ตัดสินใจปัจจุบัน + อนาคต ไม่ใช่ติดอยู่กับอดีต

Real example: Concorde airplane — UK + France ลงทุนมหาศาลแล้ว → ทำต่อจน 2003 ทั้งที่ economically ไม่ make sense

1. Analogous Estimation (Top-down)#

ใช้ historical data จาก project คล้ายๆ กัน

ตัวอย่าง:

• Project A (เหมือนกัน) ใช้เวลา 6 เดือน + $2M
• Project ใหม่ (similar scope) → estimate 6 เดือน + $2M

Pro:

• เร็ว
• ใช้ตอน early phase ที่ detail ยังน้อย

Con:

• แม่นยำต่ำ (±50%)
• สมมติว่า project นั้นเหมือนกันจริง

ใช้เมื่อ: Initiation phase ที่ requirement ยังไม่ชัด

2. Parametric Estimation#

ใช้สูตรคณิตศาสตร์ + parameter ที่ measure ได้

ตัวอย่าง:

• “Code 1,000 บรรทัด ใช้ 10 person-days”
• Project ใหม่: estimate 50,000 บรรทัด → 500 person-days

หรือ:

• “Server 1 ตัว = $5K/เดือน × 10 ตัว × 12 เดือน =$600K”

Pro:

• แม่นยำกว่า analogous (±25%)
• Scale ได้ตาม parameter

Con:

• ต้องการ parameter + historical data ที่ดี
• สูตรเก่าอาจไม่ใช่กับ tech ใหม่

3. Bottom-up Estimation#

Estimate ทีละ work package → รวมทั้งหมด

ตัวอย่าง:

• Work package 1: 5 person-days × $1K =$5K
• Work package 2: 10 person-days × $1K =$10K
• …
• Work package N: …
• Total = sum

Pro:

• แม่นยำสูงสุด (±10%)
• คนที่ทำ estimate = คนที่ทำงาน → buy-in ดีขึ้น

Con:

• ใช้เวลามาก
• ต้องการ WBS ละเอียด (EP.07)

ใช้เมื่อ: Planning phase ที่ WBS เสร็จแล้ว

4. 3-Point Estimation (PERT-style for cost)#

ใช้ optimistic + most likely + pessimistic

1
Cost estimate = (O + 4M + P) / 6
2
Standard deviation = (P - O) / 6

ตัวอย่าง: Work package X

• O (โชคดี) = $80K
• M (ปกติ) = $100K
• P (โชคร้าย) = $180K

3-point estimate = (80 + 400 + 180) / 6 = $110K

Pro:

• รับ uncertainty
• บอก range ได้ (M ± 1 SD)

Con:

• ใช้เวลามากกว่า single-point
• ต้องการ judgment ของ expert

ใช้เมื่อ: Item ที่ uncertain สูง

5. Reserve Analysis#

Reserve = buffer ใน budget สำหรับ unknown

มี 2 ประเภท:

Cost Baseline#

Cost baseline = อนุมัติ budget ที่ measure performance against

1
ขั้นตอน:
2
1. WBS → identify work package
3
2. Estimate cost ของแต่ละ work package
4
3. Aggregate ขึ้นเป็น control account
5
4. Add contingency reserve
6
5. = Cost baseline
7
6. Add management reserve
8
7. = Total project budget

S-Curve#

S-curve = cumulative cost over time — รูปร่างเป็น S

1
Cost
2
  │
3
  │              _____
4
  │           __/     ← end (slow)
5
  │        __/
6
  │     __/  ← peak execution (fast spending)
7
  │   _/
8
  │  /  ← start (slow)
9
  │_/
10
  └────────────────── Time

ทำไม S-shaped?

• Start (slow): Setup phase — ramp up team, infrastructure
• Middle (fast): Execution — full team working
• End (slow): Closing — wrap up, knowledge transfer

S-curve ใช้ตอน plan + monitor — actual S-curve เทียบ planned S-curve = baseline check

Funding Limit Reconciliation#

บางบริษัท funding มา เป็นรอบ (ไตรมาส, ปี) ไม่ใช่ก้อนเดียว

ต้อง reconcile:

• Budget baseline (cumulative cost)
• กับ funding limit (cash available per period)

ถ้า cost ตามแผนเกิน funding limit period นั้น → ต้อง:

• Re-schedule activities (delay บาง work package)
• Re-negotiate funding
• Reduce scope

NPV — Net Present Value#

Concept: เงินวันนี้ != เงินในอนาคต — เพราะมี discount rate (โอกาสลงทุนทางอื่น)

สูตร:

1
NPV = Σ [Cash Flow_t / (1 + r)^t] - Initial Investment

ตีความ:

• NPV > 0 → ลงทุนคุ้ม
• NPV < 0 → ลงทุนไม่คุ้ม
• NPV = 0 → ได้ผลตอบแทนเท่ากับ discount rate พอดี

ตัวอย่าง: Project ใช้เงิน $100K วันนี้, ได้กลับ$40K ปีละครั้ง × 3 ปี, discount rate 10%

1
NPV = $40K/(1.1)¹ + $40K/(1.1)² + $40K/(1.1)³ - $100K
2
    = $36.4K + $33.1K + $30.1K - $100K
3
    = $99.6K - $100K
4
    = -$0.4K

NPV เกือบ 0 — borderline ไม่ค่อยคุ้ม

IRR — Internal Rate of Return#

Concept: discount rate ที่ทำให้ NPV = 0

ตีความ:

• IRR > Cost of Capital → ลงทุนคุ้ม
• IRR < Cost of Capital → ลงทุนไม่คุ้ม

ใช้คู่กับ NPV — IRR บอก “ผลตอบแทน %”, NPV บอก “ผลตอบแทน $“

Payback Period#

Concept: ใช้เวลาเท่าไหร่ถึงคืนทุน

ตัวอย่าง: Project $100K, save cost$25K/ปี → Payback = 4 ปี

Pro:

• เข้าใจง่าย
• ใช้ใน communication กับ non-finance audience

Con:

• ไม่คำนึง time value of money
• ไม่ดู cash flow หลัง payback

ใช้คู่กับ NPV / IRR — ไม่ใช่ standalone

TCO — Total Cost of Ownership#

Concept: ค่าใช้จ่ายรวมตลอดอายุ — ไม่ใช่แค่ purchase price

ตัวอย่าง: ซื้อ server on-premise vs cloud

On-premise (3 ปี):

• Hardware: $100K
• Setup: $20K
• Power + cooling: $5K × 3 =$15K
• Maintenance: $10K × 3 =$30K
• Backup: $5K × 3 =$15K
• Staff (admin): $50K × 3 =$150K
• TCO = $330K

Cloud (3 ปี):

• Subscription: $8K/เดือน × 36 =$288K
• Setup: $5K
• Migration: $30K
• TCO = $323K

ดูเหมือน close — แต่:

• On-premise มี one-time payment ใหญ่ (CAPEX)
• Cloud คือ scalable + flexible

TCO ทำให้เปรียบเทียบ apples-to-apples ไม่ใช่ purchase price อย่างเดียว

ROI — Return on Investment#

1
ROI = (Net Benefit / Cost) × 100%

ตัวอย่าง:

• Cost = $500K
• Net Benefit = $750K (over 3 years)
• ROI = (750-500)/500 × 100% = 50%

Pro: สื่อสารง่าย Con: ไม่บอก time value, ไม่บอก absolute size

EVM Recap#

3 numbers:

• PV = Planned Value
• EV = Earned Value
• AC = Actual Cost

2 indices:

• CPI = EV / AC — cost performance
• SPI = EV / PV — schedule performance

Forecast: ทำไงรู้ว่า project จะใช้เงินกี่บาทตอนจบ#

EAC (Estimate at Completion) — มี 4 formula:

1. EAC = AC + (BAC - EV) — assume rest ตามแผน ใช้เมื่อ: variance ไมฺ่รียก continuing pattern

2. EAC = BAC / CPI — assume rest ตาม CPI ปัจจุบัน ใช้เมื่อ: trend ปัจจุบันจะต่อไป

3. EAC = AC + [(BAC - EV) / (CPI × SPI)] — assume cost + schedule trend ใช้เมื่อ: ทั้ง cost + schedule ผิดพลาด

4. EAC = AC + new bottom-up estimate — re-estimate ของที่เหลือ ใช้เมื่อ: original estimate ไม่ valid อีกต่อไป

VAC — Variance at Completion#

1
VAC = BAC - EAC

VAC > 0 → จบ project ใช้น้อยกว่า budget VAC < 0 → จบ project ใช้เกิน budget

TCPI — To-Complete Performance Index#

1
TCPI = (BAC - EV) / (BAC - AC)

TCPI = ratio ที่ต้อง achieve เพื่อจบใน budget

ถ้า TCPI > 1.0 → ต้อง perform ดีกว่าแผน (ยาก) ถ้า TCPI < 1.0 → perform ตามแผนพอ

1. Optimism Bias#

Bent Flyvbjerg ศึกษา 16,000+ projects — พบว่า estimate optimistic เป็น default ของมนุษย์

ตัวเลขเฉลี่ย:

• IT projects: 45% over budget, 7% over time
• Mega-projects: 20-50% over budget เป็นปกติ

สาเหตุ:

• “Strategic misrepresentation” — กลัวว่า ถ้า estimate จริง project ไม่ approved
• “Reference class neglect” — ไม่ดู project คล้ายๆ ในอดีต
• Optimism ของมนุษย์เอง

แก้: Reference class forecasting — เปรียบเทียบกับ pool ของ project คล้ายๆ ในอดีต

2. Parkinson’s Law#

“Work expands so as to fill the time available for its completion.”

ภาษาคน: ให้เวลาเท่าไหร่ ทำเสร็จเท่านั้น

ตัวอย่าง: ให้ task A 5 วัน → ทีมใช้ 5 วันเสมอ ถึงแม้จริงทำได้ 2

ผลต่อ cost:

• Buffer ที่ใส่เผื่อ → ถูกใช้หมด
• ไม่มี early finish

แก้:

• Critical Chain Method (EP.07) — ไม่ใส่ buffer per task, ใส่ end ของ chain
• Aggressive deadline + reasonable buffer

3. Student Syndrome#

Student syndrome = procrastinate จนถึง deadline → rush ตอนสุดท้าย

ตัวอย่าง: deadline 30 วัน → ทำ 25 วันแรก idle, 5 วันสุดท้าย rush

ผลต่อ cost: Quality drop → rework → เกิน budget

แก้:

• Milestone ระหว่างทาง
• Incremental delivery (Agile sprint)

4. Sunk Cost Fallacy#

(เขียนข้างบนแล้ว — แต่กลับมาย้ำ)

ห้ามตัดสินใจ continue/cancel จาก “ลงทุนไปแล้วเท่าไหร่” — ดูแค่ “ลงทุนเพิ่มอีกจะได้ value ไหม”

5. Hofstadter’s Law#

“It always takes longer than you expect, even when you take into account Hofstadter’s Law.”

แม้รู้ว่า estimate optimistic — ก็ยัง estimate optimistic อยู่ดี

แก้: Reference class forecasting — ไม่ trust intuition, trust data

6. Padding ที่ผิด#

ทีมที่ defensive estimate — ใส่ buffer ใหญ่เพราะกลัวพลาด

ปัญหา:

• Total padding = double counting (Parkinson + management reserve + contingency)
• Project ใช้เวลานานกว่าที่ควร

แก้:

• Buffer ใส่ที่เดียว (อันที่ต้องตัดสินใจ visible)
• Visible to management — ไม่ใช่ hidden

7. Resource Loading ไม่สม่ำเสมอ#

ปัญหา: plan ใช้ developer 3 คน → จริงๆ มี developer แค่ 2 คน → ต้องจ้าง contractor → cost เพิ่ม

แก้:

• Resource histogram — plot resource demand over time
• Resource leveling — adjust schedule ให้ resource สม่ำเสมอ