สารบัญ
📚 EP นี้เป็นตอนที่ 8 ของ mini-series Project Management 101 — สารบัญรวม อยู่ที่นี่
3 หัวข้อใหญ่ใน PMBOK ที่ตำราภาษาคน skip บ่อย แต่ project ใหญ่ทุกที่ใช้:
- Risk Management — เรื่องที่อาจไป pear-shape
- Quality Management — ส่งมอบของที่ใช้ได้จริง
- Procurement — จัดซื้อ + vendor
แต่ละหัวข้อเป็นวิชาแยกได้เลย — ตอนนี้สรุปภาพใหญ่ให้คุยกับ PM ตัวจริงรู้เรื่อง
ส่วนที่ 1: Risk Management
Risk คืออะไร
Risk = ความไม่แน่นอนที่อาจกระทบเป้าหมาย
ไม่จำเป็นต้องเป็นเรื่องร้าย — ก็มี opportunity (positive risk) ที่ควรคว้า
ตัวอย่าง risks ใน project ติดตั้ง CRM:
- Vendor ส่งมอบช้า → Negative
- Key developer ลาออก → Negative
- New tool feature เพิ่มเข้ามาฟรี → Positive (opportunity!)
- กฎหมาย PDPA เปลี่ยน → Negative
Risk Cycle: 4 ขั้น
1. Identify → 2. Assess → 3. Treat → 4. Monitor ↑ │ └───────────── ต่อเนื่อง ────────────────┘Step 1: Identify
ทำยังไง:
- Brainstorming กับทีม — “อะไรที่อาจไม่เป็นไปตามแผน”
- Lessons learned จาก project เก่า
- Expert interview
- Checklist จาก industry
- SWOT analysis
- Premortem (Gary Klein) — “สมมติว่า project ล้มแล้ว — ล้มเพราะอะไร”
ผลลัพธ์: Risk register (ดู step 4)
Step 2: Assess
แต่ละ risk วัด 2 มิติ:
- Probability (ความน่าจะเกิด) — 1 ถึง 5
- Impact (ผลกระทบ) — 1 ถึง 5
Risk Score = Probability × Impact (1-25)
Risk Heatmap:
Impact 1 2 3 4 5P 5 | 5 10 15 20 25 |r 4 | 4 8 12 16 20 |o 3 | 3 6 9 12 15 |b 2 | 2 4 6 8 10 |. 1 | 1 2 3 4 5 |- 1-5: Low (สีเขียว)
- 6-12: Medium (เหลือง)
- 15-25: High (แดง — ต้องจัดการก่อน)
Step 3: Treat — 4 strategies
| Strategy | ทำอะไร | ตัวอย่าง | ใช้กับ |
|---|---|---|---|
| 1. Avoid | ไม่ทำ activity ที่มี risk | ไม่ขยายไปประเทศที่ political risk สูง | high probability + high impact |
| 2. Mitigate | ลด probability หรือ impact | ติด firewall ลด cyber risk, train ทีมเพิ่มลด skill risk | medium-high risk ที่ control ได้ |
| 3. Transfer | โอน risk ไปคนอื่น | ซื้อ insurance, outsource ไป vendor ที่รับ risk แทน | financial risk, specialty risk |
| 4. Accept | ยอมรับ — มี 2 แบบ (ดูด้านล่าง) | — | low risk, หรือ high risk ที่ไม่มีทางแก้คุ้มค่า |
Accept มี 2 แบบ:
- Active acceptance — มี contingency plan ไว้ (เงิน 10% ของ project budget)
- Passive acceptance — ไม่ทำอะไร เกิดค่อยแก้
Step 4: Monitor — Risk Register
Risk Register = living document ที่เก็บ risk ทั้งหมด:
| ID | Risk | Prob | Impact | Score | Strategy | Owner | Status |
|---|---|---|---|---|---|---|---|
| R-01 | Vendor ส่งช้า | 3 | 4 | 12 | Mitigate | PM | Open |
| R-02 | Key dev ลาออก | 2 | 5 | 10 | Mitigate (cross-train) | TL | Open |
| R-03 | PDPA เปลี่ยน | 1 | 5 | 5 | Monitor | Legal | Open |
| R-04 | Cloud cost เกิน | 4 | 3 | 12 | Active accept (buffer) | PM | Mitigated |
Update รายอาทิตย์ — risk ใหม่เกิด, risk เก่า status เปลี่ยน
Quote ของ Tim Lister
“Risk management is how adults manage projects.”
ไม่จัดการ risk = หวัง luck
ส่วนที่ 2: Quality Management
QA vs QC — คนสับสนเยอะที่สุด
QA — Quality Assurance = process ที่ป้องกันไม่ให้ defect เกิด
- ออกแบบ process ดี
- Standard ที่ทีมต้อง follow
- Training
- Code review process
- Preventive
QC — Quality Control = inspection ของ output ที่เกิดแล้ว
- Test
- Inspection
- Audit ของ deliverable
- Detective
ตัวอย่างเทียบ
Project: build e-commerce site
QA:
- Coding standard ที่ทุกคน follow
- Pull request review process
- Definition of Done
- Pair programming guideline
QC:
- Manual testing
- Automated test suite
- UAT
- Bug bash session
ทั้งคู่จำเป็น — QA ป้องกัน, QC จับสิ่งที่หลุด
Cost of Quality
แบ่งค่าใช้จ่ายเรื่อง quality เป็น 4 หมวด:
Cost of Conformance (ลงทุนเพื่อ quality):
- Prevention — training, process design, tools
- Appraisal — testing, inspection, audit
Cost of Non-conformance (เสียเพราะ quality ไม่ดี): 3. Internal failure — rework ก่อน release (debug, retest) 4. External failure — rework หลัง release (customer complaint, refund, lawsuit, brand damage)
Rule of thumb (Crosby)
ค่า prevention 1 บาท = saves 10 บาท ของ internal failure = saves 100 บาท ของ external failure
ลงทุน prevention คุ้มที่สุด — แต่บริษัทส่วนใหญ่ลงทุน external failure เพราะ visible สุด
Quality Frameworks
1. PDCA (Plan-Do-Check-Act) — Deming วงจร continuous improvement:
- Plan: ตั้ง standard
- Do: ทำตาม
- Check: วัดผล
- Act: ปรับปรุง
2. Six Sigma ลด defect ให้เหลือ 3.4 ต่อล้าน opportunities (DPMO)
- DMAIC — Define, Measure, Analyze, Improve, Control
- ใช้ใน manufacturing เป็นหลัก, software บางที่ก็ใช้
3. ISO 9001 มาตรฐาน quality management ระดับสากล
- Process documentation
- Audit รอบ
- Continuous improvement
4. Total Quality Management (TQM) Philosophy ทั้งบริษัท — quality เป็นเรื่องของทุกคน ไม่ใช่แค่ QC team
Benchmarking — 6 ขั้นตอนปรับปรุง process จาก reference ภายนอก
Benchmarking = กระบวนการเปรียบเทียบ process / product / service ของบริษัทเรากับ enterprise ที่ถูกยอมรับว่าเป็น world-class ในเรื่องนั้น แล้วเรียนรู้สิ่งที่เขาทำดีกว่ามาปรับใช้ — เป็น tool หลักของ continuous improvement (คู่กับ PDCA / Six Sigma / TQM)
ตัวอย่าง: บริษัทขนส่งไทยอยาก improve on-time delivery rate ไป benchmark กับ FedEx / DHL ดูว่าเขาทำกระบวนการ sorting + routing ยังไงถึงได้ on-time 98%
Benchmarking ตามที่ ISACA CRM อธิบาย มี 6 ขั้นตอน:
| ขั้น | ชื่อ | ทำอะไร |
|---|---|---|
| 1 | Plan | ระบุ critical process ที่จะ benchmark + ตั้ง measurement criteria + วาง data collection plan |
| 2 | Research | หา benchmarking partner (enterprise ที่เป็น reference) + ทำข้อตกลงร่วม (เช่น confidentiality + data sharing) |
| 3 | Observe | เก็บข้อมูลจริง — ไปเยี่ยมชม partner, สัมภาษณ์, รวบรวม metrics ตาม plan |
| 4 | Analyze | วิเคราะห์ gap ระหว่าง process ของเรากับ partner — gap อยู่ตรงไหน ใหญ่แค่ไหน |
| 5 | Adapt | แปล finding เป็น core principle → strategy → action plan ของบริษัทเรา (ไม่ใช่ copy-paste — adapt ให้เข้ากับ context) |
| 6 | Improve | นำ action plan ไปทำ + วัดผล + วน loop ใหม่ — benchmarking คือ continuous ไม่ใช่ one-shot |
กับดัก ⚠️: Benchmarking = copy partner ทั้งหมด
ผิดครับ ขั้นที่ 5 (Adapt) สำคัญที่สุด — partner ที่ best-in-class ทำงานใน context ของเขาเอง (ขนาดบริษัท, ลูกค้า, ตลาด, regulation). Copy ดิบๆ มักไม่ work — ต้อง extract principle มาก่อน แล้วค่อย design implementation ที่เข้ากับ context เรา
💡 PM context: Benchmarking มัก trigger โดย gap analysis ใน project initiation phase — เห็น gap แล้วถึงรู้ว่าควร benchmark กับใคร. ผลของ benchmark กลับมาเป็น input ของ business case + project scope
ส่วนที่ 3: Procurement / Vendor Management
ทำไม PM ต้องรู้ procurement?
เพราะ project ใหญ่ส่วนมาก ไม่ได้ build ทุกอย่างเอง — ซื้อ + outsource
ตัวอย่าง project ติดตั้ง CRM:
- ซื้อ CRM software (Salesforce / HubSpot / Zoho)
- จ้าง implementation partner
- ซื้อ training service
- ซื้อ ongoing support contract
ทุกอันต้องผ่าน procurement process
Procurement Documents (เรียงตามลำดับ)
1. RFI — Request for Information
- ใช้: ตอน early — สำรวจตลาดมี vendor อะไรบ้าง
- ไม่ใช่ commitment ซื้อ
- Output: shortlist of capable vendors
2. RFP — Request for Proposal
- ใช้: หา solution complex ที่ vendor ต้อง propose ทาง
- Vendor ส่งมา: solution + price + timeline + team
- ใช้ scoring matrix ตัดสิน
- Output: selected vendor
3. RFQ — Request for Quotation
- ใช้: รู้ว่าต้องการอะไรชัดแล้ว — แค่ขอราคา
- ปกติ commodity ที่ specs ตรงกัน
- Output: lowest price (มักจะ) win
Contract Types — สำคัญมาก
มี 3 ประเภทหลัก ที่ risk allocation ต่างกันสุดขั้ว:
1. Fixed-Price (FP) / Lump Sum
Vendor รับ risk:
- ตกลงราคา + scope ชัด
- เกิน scope = vendor เสียเอง
- ใช้เวลานานกว่าที่ promise = vendor เสีย
Buyer มั่นใจ: ราคา fix
ใช้เมื่อ:
- Scope ชัด, requirement stable
- ตัวอย่าง: ติดตั้ง software A ที่ standard config
ข้อระวัง:
- Vendor มี incentive cut quality ลด cost
- Change request หลัง sign = แพงมาก
2. Time & Materials (T&M)
Buyer รับ risk:
- จ่ายตามชั่วโมงที่ vendor ทำ + cost วัสดุ
- ไม่มี cap (จนกว่าจะ negotiate)
Vendor มั่นใจ: ได้เงินตามจริง
ใช้เมื่อ:
- Scope ไม่ชัด, requirement พัฒนาไป
- ตัวอย่าง: R&D, custom development แบบ exploratory
ข้อระวัง:
- Cost overrun risk สูง
- Vendor ไม่มี incentive ให้ทำเร็ว
3. Cost-Plus (CR)
Buyer รับ risk + จ่าย fee:
- จ่าย actual cost + fee (% หรือ fixed)
- Variants:
- Cost Plus Fixed Fee (CPFF) — fee คงที่
- Cost Plus Incentive Fee (CPIF) — fee เพิ่ม/ลดตาม performance
- Cost Plus Award Fee (CPAF) — fee ขึ้นกับ subjective evaluation
ใช้เมื่อ:
- Big defense / aerospace project
- Scope ไม่สามารถระบุล่วงหน้าได้ (R&D ใหญ่)
ข้อระวัง:
- Vendor มี incentive ใช้เงินเยอะ (เพราะ fee เป็น %)
- Common ใน government contract — ที่มาของ “cost overrun” ที่ดังๆ
Risk allocation matrix
Buyer risk Vendor risk ▲ ▲ │ │ T&M ─────┘ └───── Fixed Price
Cost-Plus = Buyer risk สูงสุดVendor Management หลัง sign contract
- SLA (Service Level Agreement) — เกณฑ์ performance ที่ vendor ต้องตอบ (uptime 99.5%, response <1 hour)
- KPIs — track monthly
- Penalty / bonus clauses
- Exit clauses — ออกได้ยังไงถ้า vendor ทำไม่ได้
- Knowledge transfer — ป้องกัน vendor lock-in
เครื่องมือ classic — ทุกหัวข้อใช้ใน phase ไหน
ย้อนกลับไปที่ EP.02 lifecycle:
| หัวข้อ | Phase ที่ใช้ |
|---|---|
| Risk identification | Initiation + Planning |
| Risk register | Planning + Monitoring |
| Risk treatment | Execution + Monitoring |
| QA process | Planning + Execution |
| QC inspection | Execution |
| RFP/RFQ | Planning |
| Contract negotiation | Planning |
| Vendor management | Execution + Monitoring |
สรุป EP นี้
Risk:
- 4 ขั้น: Identify → Assess (P×I) → Treat (Avoid/Mitigate/Transfer/Accept) → Monitor
- Risk Register = living document
- “Risk management is how adults manage projects”
Quality:
- QA (preventive process) ≠ QC (detective inspection)
- Cost of Quality = Conformance (prevent + appraisal) + Non-conformance (internal + external failure)
- ลงทุน prevention คุ้มสุด
Procurement:
- RFI → RFP → RFQ
- 3 contract types: FP (vendor risk), T&M (buyer risk), Cost-Plus (buyer risk + fee)
- ทุก contract ต้องมี SLA + exit clause
EP ต่อไป — เมื่อทีมโต 50+ คน ใช้ scaled framework — SAFe vs LeSS + Conway’s Law + Brooks’ Law
