IT Project Management คืออะไร? การจัดการโปรเจค IT และเขียน Documentation อย่างมืออาชีพ 2026

บทนำ: ทำไม IT Project Management และ Documentation ถึงเป็นทักษะที่ขาดไม่ได้?

ในโลก IT มีโปรเจคมากมายที่ล้มเหลว — สถิติจาก Standish Group Chaos Report ระบุว่า โปรเจค IT มีอัตราความล้มเหลวสูงถึง 66% ไม่ว่าจะเป็นเกินงบ, เกินเวลา, หรือส่งมอบไม่ตรงตาม requirement สาเหตุหลักไม่ใช่เรื่องเทคนิค แต่เป็นเรื่อง การจัดการโปรเจคที่ไม่ดี และ ขาด documentation ที่เพียงพอ

IT Professional หลายคนเก่งเรื่อง technical — ติดตั้ง server ได้, configure network ได้, เขียน code ได้ แต่เมื่อต้อง “จัดการโปรเจค” กลับทำไม่ถูกทาง ไม่รู้จะเริ่มยังไง ไม่รู้จะ track progress อย่างไร ไม่รู้จะสื่อสารกับ stakeholders อย่างไร แล้วเมื่อโปรเจคเสร็จก็ไม่มี documentation ให้คนที่มาดูแลต่อ

บทความนี้จะครอบคลุมทั้ง IT Project Management ตั้งแต่พื้นฐาน, methodologies ที่ใช้จริง, เครื่องมือ, การจัดการ risk/change/vendor ไปจนถึง IT Documentation ทุกประเภทที่ IT Professional ต้องเขียนเป็น พร้อม certification paths สำหรับคนที่ต้องการพัฒนาตนเองในสาย project management

ส่วนที่ 1: IT Project Management Fundamentals — พื้นฐานที่ต้องรู้

1.1 IT Project คืออะไร?

Project ตามนิยามของ PMI (Project Management Institute) คือ “ความพยายามชั่วคราวที่ทำเพื่อสร้างผลิตภัณฑ์ บริการ หรือผลลัพธ์ที่เป็นเอกลักษณ์” คำสำคัญคือ ชั่วคราว (มีเริ่มต้นและสิ้นสุด) และ เป็นเอกลักษณ์ (ไม่ใช่งาน routine)

IT Project คือ โปรเจคที่เกี่ยวข้องกับเทคโนโลยีสารสนเทศ ตัวอย่างเช่น:

ตัวอย่าง IT Projects:

Infrastructure Projects:
├── ย้าย Data Center ไปตึกใหม่
├── Upgrade Core Switch ทั้งองค์กร
├── Deploy WiFi 6E ทุกชั้น
├── ติดตั้ง Firewall/UTM ใหม่
└── วาง Fiber Optic ระหว่างอาคาร

Software/Application Projects:
├── พัฒนาระบบ ERP ใหม่
├── Migrate จาก On-Premise ไป Cloud
├── Deploy Microsoft 365 ทั้งองค์กร
├── ติดตั้ง ITSM Tool (ServiceNow, Jira)
└── ปรับปรุงระบบ CRM

Security Projects:
├── Implement Zero Trust Architecture
├── Deploy EDR Solution ทุก Endpoint
├── ISO 27001 Certification
├── ทำ Penetration Testing
└── ติดตั้งระบบ SIEM

Digital Transformation Projects:
├── ย้ายระบบทั้งหมดไป Azure/AWS
├── Implement DevOps pipeline
├── Deploy AI/ML solutions
├── IoT deployment ใน factory
└── Digital workplace transformation

1.2 Project Management Triple Constraint

หัวใจของ project management คือการจัดการ Triple Constraint — 3 ข้อจำกัดหลักที่ส่งผลกระทบซึ่งกันและกัน:

Triple Constraint (Iron Triangle):

              SCOPE
             /                 /                  /  Quality           /   (center)          /                       TIME ──────── COST

ถ้าเพิ่ม Scope → ต้องเพิ่ม Time หรือ Cost หรือทั้งสอง
ถ้าลด Time → ต้องลด Scope หรือเพิ่ม Cost
ถ้าลด Cost → ต้องลด Scope หรือเพิ่ม Time
Quality ขึ้นอยู่กับสมดุลของทั้ง 3 ปัจจัย

ตัวอย่างจริง:
"ผู้บริหารอยากได้ระบบ ERP ใหม่ ภายใน 3 เดือน งบ 2 ล้าน"
├── Scope: ระบบ ERP เต็มรูปแบบ (ใหญ่มาก)
├── Time: 3 เดือน (สั้นเกินไป)
├── Cost: 2 ล้าน (น้อยเกินไป)
└── PM ต้องเจรจา: ลด scope, เพิ่มเวลา, หรือเพิ่มงบ

1.3 Project Management Process Groups

ตาม PMBOK (Project Management Body of Knowledge) โปรเจคทุกโปรเจคมี 5 กลุ่มกระบวนการ (Process Groups):

5 Process Groups:

1. Initiating (เริ่มต้น)
   ├── Define project at high level
   ├── Identify stakeholders
   ├── Create Project Charter
   └── Get authorization to proceed

2. Planning (วางแผน) ★ สำคัญที่สุด
   ├── Define scope in detail (WBS)
   ├── Create schedule (Gantt chart)
   ├── Estimate budget
   ├── Plan quality, risk, communication
   ├── Identify resources needed
   └── Create Project Management Plan

3. Executing (ดำเนินงาน)
   ├── Direct and manage work
   ├── Acquire and manage team
   ├── Manage stakeholder engagement
   ├── Implement quality assurance
   └── Procure resources

4. Monitoring & Controlling (ติดตามและควบคุม)
   ├── Track progress vs plan
   ├── Manage changes
   ├── Control scope, schedule, cost
   ├── Monitor risks
   ├── Report status
   └── Validate deliverables

5. Closing (ปิดโปรเจค)
   ├── Formal acceptance of deliverables
   ├── Release resources
   ├── Document lessons learned
   ├── Archive project documents
   └── Celebrate success!

ส่วนที่ 2: Waterfall vs Agile — เลือก Methodology ให้เหมาะกับ IT Project

2.1 Waterfall Methodology

Waterfall เป็น methodology ดั้งเดิมที่ทำงานเป็นลำดับขั้นตอน (sequential) — เสร็จขั้นตอนหนึ่งก่อนค่อยไปขั้นตอนถัดไป เหมือนน้ำตกที่ไหลลงทิศทางเดียว

Waterfall เหมาะกับ IT Projects ที่ requirement ชัดเจนตั้งแต่เริ่ม ไม่ค่อยเปลี่ยนแปลง เช่น infrastructure projects (ย้าย data center, วาง network cable), hardware deployment, compliance projects

Waterfall สำหรับ IT Project:

Requirements → Design → Implementation → Testing → Deployment → Maintenance

ตัวอย่าง: โปรเจคย้าย Data Center
├── Requirements: สำรวจ rack space, power, cooling ที่ต้องการ
├── Design: วาง floor plan, network topology, migration sequence
├── Implementation: ย้ายอุปกรณ์ตาม plan ทีละ rack
├── Testing: ทดสอบทุกระบบหลังย้ายเสร็จ
├── Deployment: switch traffic มาที่ DC ใหม่
└── Maintenance: monitor & fine-tune

ข้อดี Waterfall:
+ ง่ายต่อการเข้าใจและจัดการ
+ Documentation ละเอียด
+ ควบคุม scope ได้ดี
+ เหมาะกับ fixed-price contracts
+ มี milestones ชัดเจน

ข้อเสีย Waterfall:
- ไม่ยืดหยุ่นต่อ requirement changes
- ผู้ใช้เห็นผลลัพธ์ตอนท้ายโปรเจค
- ถ้าเจอปัญหาตอนหลัง ต้อง rework เยอะ
- ไม่เหมาะกับโปรเจคที่ requirements ไม่ชัด

2.2 Agile Methodology

Agile เป็นแนวทางที่ทำงานเป็นรอบสั้นๆ (iterations/sprints) ส่งมอบผลลัพธ์บ่อยๆ และรับ feedback เพื่อปรับปรุงอย่างต่อเนื่อง เหมาะกับ software development projects หรือ IT projects ที่ requirements อาจเปลี่ยนแปลง

Agile frameworks ที่นิยมใช้กับ IT Projects ได้แก่ Scrum (ทำเป็น Sprint 2-4 สัปดาห์), Kanban (continuous flow, visualize work), SAFe (Scaled Agile Framework สำหรับองค์กรใหญ่)

Agile สำหรับ IT Project:

Sprint 1 → Sprint 2 → Sprint 3 → ... → Release

ตัวอย่าง: โปรเจค Deploy ITSM Tool
Sprint 1 (2 สัปดาห์): ติดตั้ง platform + Incident Management module
Sprint 2 (2 สัปดาห์): Configure workflows + user training
Sprint 3 (2 สัปดาห์): Change Management module + integrations
Sprint 4 (2 สัปดาห์): Problem Management + reporting
Sprint 5 (2 สัปดาห์): Knowledge Base + self-service portal
Sprint 6 (2 สัปดาห์): Fine-tune + go-live preparation

ข้อดี Agile:
+ ยืดหยุ่น รับ changes ได้ง่าย
+ User เห็นผลลัพธ์เร็ว (ทุก Sprint)
+ ลด risk จากการ deliver ทีละน้อย
+ Team collaboration ดีมาก
+ Continuous improvement

ข้อเสีย Agile:
- Scope creep ถ้าไม่ควบคุมดี
- ต้องมี stakeholder engagement สูง
- Documentation อาจน้อยกว่า Waterfall
- ยากต่อการ estimate budget/timeline ล่วงหน้า
- ไม่เหมาะกับ fixed-price contracts

2.3 Hybrid Approach — ทางเลือกที่นิยมในปี 2026

ในความเป็นจริง โปรเจค IT หลายตัวใช้ Hybrid Approach ที่ผสมผสาน Waterfall และ Agile เข้าด้วยกัน ตัวอย่างเช่น ใช้ Waterfall สำหรับ overall project phases (initiation, planning, closing) แต่ใช้ Agile สำหรับ execution phase ที่ต้อง deliver ทีละส่วน

เลือก Methodology ให้เหมาะสม:

┌───────────────────┬───────────────┬───────────────┐
│ ลักษณะโปรเจค      │ Waterfall     │ Agile         │
├───────────────────┼───────────────┼───────────────┤
│ Requirements ชัด  │ ✓ เหมาะมาก   │ △ ได้แต่เปลือง│
│ Requirements ไม่ชัด│ ✗ ไม่เหมาะ   │ ✓ เหมาะมาก   │
│ Fixed budget/time │ ✓ ควบคุมได้   │ ✗ ยาก         │
│ DC Migration      │ ✓ ★           │ △             │
│ Software Dev      │ △             │ ✓ ★           │
│ Network Deploy    │ ✓ ★           │ △             │
│ Cloud Migration   │ △ Hybrid      │ ✓ ★           │
│ Security Project  │ ✓             │ △             │
│ ITSM Deploy       │ △ Hybrid      │ ✓             │
│ ERP Implementation│ △ Hybrid      │ △ Hybrid      │
└───────────────────┴───────────────┴───────────────┘
★ = Best fit, ✓ = Suitable, △ = Possible, ✗ = Not recommended

ส่วนที่ 3: เครื่องมือ Project Management ที่ IT ต้องรู้

3.1 Project Charter — เอกสารเริ่มต้นโปรเจค

Project Charter เป็นเอกสารที่สำคัญที่สุดในการเริ่มโปรเจค เป็น “ใบอนุญาต” ให้ project manager เริ่มทำงานได้ ประกอบด้วย:

Project Charter Template สำหรับ IT Project:

PROJECT CHARTER
═══════════════════════════════════════════════

Project Name: Network Infrastructure Upgrade 2026
Project Manager: [ชื่อ PM]
Sponsor: [ชื่อ CIO/IT Director]
Date: [วันที่]

1. Project Purpose / Business Need
   "ระบบ network ปัจจุบัน (Cisco 2960) อายุ 8 ปี
   ไม่รองรับ 10Gbps และ WiFi 6E ส่งผลให้ user
   ประสบปัญหา network ช้า และ downtime บ่อย"

2. Project Objectives
   - Upgrade core/distribution switches เป็น 10G
   - Deploy WiFi 6E access points ทุกชั้น
   - ลด network downtime จาก 8 hrs/month → <1 hr/month
   - รองรับ user growth 30% ใน 3 ปีข้างหน้า

3. High-Level Requirements
   - Core switch: L3, 10G, redundant (2 ตัว)
   - Distribution switch: L2/L3, 1G/10G uplink (8 ตัว)
   - Access Point: WiFi 6E, PoE (40 ตัว)
   - ไม่กระทบ production >30 นาที per switch

4. High-Level Risks
   - Vendor delay ส่งอุปกรณ์
   - Compatibility issues กับ existing infrastructure
   - Downtime ระหว่าง migration
   - Budget overrun จากราคาอุปกรณ์ขึ้น

5. Budget Estimate: 3,500,000 THB (+/- 25%)
6. Timeline: 4 months (Q2-Q3 2026)
7. Stakeholders: IT Director, Finance, HR, Operations

APPROVED BY:
Sponsor: _________________ Date: _______
PM: _____________________ Date: _______

3.2 Work Breakdown Structure (WBS)

WBS (Work Breakdown Structure) คือการแบ่งงานใหญ่ออกเป็นงานย่อยๆ จนถึงระดับที่สามารถ assign, estimate, track ได้ เป็นเครื่องมือที่ PM ต้องใช้ทุกโปรเจค

WBS ตัวอย่าง: Network Infrastructure Upgrade

1.0 Network Infrastructure Upgrade
├── 1.1 Planning & Design
│   ├── 1.1.1 Site Survey & Assessment
│   ├── 1.1.2 Network Design (L2/L3 topology)
│   ├── 1.1.3 Equipment Specification & RFQ
│   ├── 1.1.4 Vendor Selection & PO
│   └── 1.1.5 Migration Plan & Schedule
│
├── 1.2 Procurement
│   ├── 1.2.1 Core Switches (2 units)
│   ├── 1.2.2 Distribution Switches (8 units)
│   ├── 1.2.3 Access Points (40 units)
│   ├── 1.2.4 Cabling & Accessories
│   └── 1.2.5 Software Licenses
│
├── 1.3 Implementation
│   ├── 1.3.1 Lab Setup & Pre-Configuration
│   ├── 1.3.2 Core Switch Installation (Weekend 1)
│   ├── 1.3.3 Distribution Switch Migration (Week 2-5)
│   │   ├── 1.3.3.1 Floor 1 (Weekend 2)
│   │   ├── 1.3.3.2 Floor 2 (Weekend 3)
│   │   ├── 1.3.3.3 Floor 3 (Weekend 4)
│   │   └── 1.3.3.4 Floor 4 (Weekend 5)
│   ├── 1.3.4 WiFi AP Deployment (Week 6-7)
│   └── 1.3.5 Network Monitoring Setup
│
├── 1.4 Testing & Validation
│   ├── 1.4.1 Performance Testing
│   ├── 1.4.2 Failover Testing
│   ├── 1.4.3 User Acceptance Testing
│   └── 1.4.4 Security Audit
│
└── 1.5 Closure
    ├── 1.5.1 Documentation & As-Built Diagrams
    ├── 1.5.2 Knowledge Transfer to Operations
    ├── 1.5.3 Lessons Learned
    └── 1.5.4 Project Sign-Off

WBS Rules:
- ระดับล่างสุด (Work Package) ควรใช้เวลา 8-80 ชั่วโมง
- 100% Rule: WBS ต้องครอบคลุมงานทั้งหมด
- Deliverable-oriented: แต่ละ item ต้องมี deliverable ชัดเจน

3.3 Gantt Chart — ตารางเวลาโปรเจค

Gantt Chart เป็นเครื่องมือที่ใช้แสดง schedule ของโปรเจคในรูปแบบ bar chart แสดง tasks, ระยะเวลา, dependencies, milestones เป็นที่นิยมมากในการจัดการโปรเจค IT

Gantt Chart ตัวอย่าง (Text-based):

Task                    | Apr W1 | Apr W2 | Apr W3 | Apr W4 | May W1 | May W2 |
─────────────────────────┼────────┼────────┼────────┼────────┼────────┼────────┤
Site Survey             | ████   |        |        |        |        |        |
Network Design          |   ████ | ████   |        |        |        |        |
RFQ & Vendor Select     |        | ████   | ████   |        |        |        |
★ PO Approved           |        |        |    ◆   |        |        |        |
Equipment Delivery      |        |        |  █████ | █████  |        |        |
Pre-Configuration       |        |        |        | ████   |        |        |
★ Ready for Install     |        |        |        |     ◆  |        |        |
Core Switch Install     |        |        |        |   ████ |        |        |
Dist. Switch Migration  |        |        |        |        | █████  | █████  |
WiFi AP Deploy          |        |        |        |        |        | ████   |
Testing                 |        |        |        |        |        |  ████  |
★ Go-Live               |        |        |        |        |        |     ◆  |

████ = Task duration    ◆ = Milestone    ★ = Key milestone

Dependencies:
- Network Design → RFQ (Finish-to-Start)
- Vendor Select → Equipment Delivery (FS)
- Equipment Delivery → Pre-Configuration (FS)
- Pre-Configuration → Core Switch Install (FS)
- Core Switch Install → Dist. Switch Migration (FS)

เครื่องมือสำหรับสร้าง Gantt Chart ที่นิยมใช้ได้แก่ Microsoft Project (มาตรฐานอุตสาหกรรม), Monday.com (cloud-based, ใช้ง่าย), Jira + Gantt plugin (สำหรับ Agile teams), Asana (free tier ใช้ได้ดี), ClickUp (feature มาก ราคาย่อมเยา), GanttProject (open-source, ฟรี)

3.4 RACI Matrix — กำหนดบทบาทชัดเจน

RACI Matrix เป็นเครื่องมือที่ช่วยกำหนดว่าใครมีบทบาทอะไรในแต่ละงาน ป้องกันปัญหา “ไม่รู้ว่าใครรับผิดชอบ” หรือ “ทุกคนคิดว่าคนอื่นทำ”

RACI Matrix:

R = Responsible  (ทำงาน — คนลงมือทำ)
A = Accountable  (รับผิดชอบ — เจ้าภาพ ต้องมี 1 คนต่อ task)
C = Consulted    (ปรึกษา — ให้ input ก่อนทำ)
I = Informed     (แจ้งให้ทราบ — รับรู้เมื่อเสร็จ)

ตัวอย่าง RACI สำหรับ Network Upgrade Project:

┌──────────────────┬────────┬────────┬────────┬────────┬────────┐
│ Task             │ PM     │ NetEng │ SysAdm │ SecTeam│ CIO    │
├──────────────────┼────────┼────────┼────────┼────────┼────────┤
│ Network Design   │ A      │ R      │ C      │ C      │ I      │
│ Equipment RFQ    │ R      │ C      │ I      │ I      │ A      │
│ Switch Install   │ I      │ R      │ C      │ I      │ I      │
│ WiFi Deploy      │ I      │ R      │ R      │ I      │ I      │
│ Security Config  │ I      │ R      │ I      │ A      │ I      │
│ Testing          │ A      │ R      │ R      │ R      │ I      │
│ Go-Live Approval │ R      │ C      │ C      │ C      │ A      │
│ Documentation    │ A      │ R      │ R      │ C      │ I      │
│ Budget Approval  │ R      │ I      │ I      │ I      │ A      │
└──────────────────┴────────┴────────┴────────┴────────┴────────┘

กฎของ RACI:
- ทุกแถวต้องมี A อย่างน้อย 1 คน (ไม่เกิน 1 คน)
- ทุกแถวต้องมี R อย่างน้อย 1 คน
- ถ้ามี A เยอะเกินไป = authority ไม่ชัด
- ถ้า R เยอะเกินไป = ต้องแบ่ง task ให้ย่อยลง

ส่วนที่ 4: Risk Management สำหรับ IT Projects

4.1 ทำไม Risk Management ถึงสำคัญ?

โปรเจค IT มีความเสี่ยงสูงโดยธรรมชาติ — เทคโนโลยีเปลี่ยนเร็ว, ความซับซ้อนสูง, dependencies มาก การจัดการ risk อย่างเป็นระบบช่วยลดโอกาสที่โปรเจคจะล้มเหลว

Risk Management Process:

1. Risk Identification (ระบุความเสี่ยง)
   ├── Brainstorming กับ team
   ├── Review lessons learned จาก past projects
   ├── SWOT Analysis
   ├── Checklist จาก industry standards
   └── Expert interviews

2. Risk Analysis (วิเคราะห์ความเสี่ยง)
   ├── Qualitative: Probability x Impact matrix
   │   ┌────────────┬──────┬────────┬──────────┐
   │   │ Prob\Impact│ Low  │ Medium │ High     │
   │   ├────────────┼──────┼────────┼──────────┤
   │   │ High       │ Med  │ High   │ Critical │
   │   │ Medium     │ Low  │ Medium │ High     │
   │   │ Low        │ Low  │ Low    │ Medium   │
   │   └────────────┴──────┴────────┴──────────┘
   └── Quantitative: Expected Monetary Value (EMV)
       EMV = Probability × Impact (in THB)

3. Risk Response Planning (วางแผนรับมือ)
   ├── Avoid: เปลี่ยนแผนเพื่อหลีกเลี่ยง risk
   ├── Mitigate: ลดโอกาสหรือผลกระทบ
   ├── Transfer: โอน risk ให้คนอื่น (insurance, vendor)
   ├── Accept: ยอมรับ risk (ถ้า impact ต่ำ)
   └── Escalate: ส่งต่อให้ level ที่สูงกว่า

4. Risk Monitoring (ติดตาม)
   ├── Review risk register ทุก sprint/week
   ├── Update status ของ existing risks
   ├── Identify new risks
   └── Report to stakeholders

4.2 Risk Register สำหรับ IT Project

Risk Register เป็นเอกสารที่บันทึก risk ทั้งหมดของโปรเจค พร้อมแผนรับมือ ต้อง update ทุกสัปดาห์ ตัวอย่าง:

Risk Register — Network Upgrade Project:

┌────┬──────────────────┬──────┬────────┬──────────┬──────────────────┐
│ ID │ Risk Description │ Prob │ Impact │ Score    │ Response Plan    │
├────┼──────────────────┼──────┼────────┼──────────┼──────────────────┤
│ R1 │ อุปกรณ์ส่งช้า    │ High │ High   │ Critical │ สั่ง 8 สัปดาห์  │
│    │ กว่า lead time   │      │        │          │ ก่อน install date│
├────┼──────────────────┼──────┼────────┼──────────┼──────────────────┤
│ R2 │ Switch migration │ Med  │ High   │ High     │ ทำ weekends +   │
│    │ ทำให้ downtime   │      │        │          │ rollback plan    │
│    │ เกินกำหนด        │      │        │          │ พร้อมเสมอ       │
├────┼──────────────────┼──────┼────────┼──────────┼──────────────────┤
│ R3 │ Config ไม่ compatible│ Med│ Med    │ Medium   │ Lab testing ก่อน │
│    │ กับ legacy devices│     │        │          │ deploy จริง      │
├────┼──────────────────┼──────┼────────┼──────────┼──────────────────┤
│ R4 │ Key engineer ลาออก│ Low │ High   │ Medium   │ Cross-train team │
│    │ ระหว่างโปรเจค    │      │        │          │ + document ทุกอย่าง│
├────┼──────────────────┼──────┼────────┼──────────┼──────────────────┤
│ R5 │ Budget overrun   │ Med  │ Med    │ Medium   │ 10% contingency  │
│    │ จากราคาขึ้น      │      │        │          │ + fixed price PO │
└────┴──────────────────┴──────┴────────┴──────────┴──────────────────┘

ส่วนที่ 5: Change Management — การจัดการการเปลี่ยนแปลง

5.1 Change Management ในบริบท IT Project

Change Management มี 2 ความหมายใน IT:

1) IT Change Management (ITIL): กระบวนการจัดการการเปลี่ยนแปลงในระบบ IT เช่น การเปลี่ยน firewall rule, upgrade server, deploy software ต้องผ่าน Change Advisory Board (CAB) approve

2) Organizational Change Management: กระบวนการจัดการการเปลี่ยนแปลงในองค์กร — ทำอย่างไรให้คน (users, stakeholders) ยอมรับและปรับตัวกับระบบ IT ใหม่ ตัวอย่างเช่น เมื่อ deploy Microsoft 365 แทน Google Workspace ต้องจัดการ “คน” ด้วย ไม่ใช่แค่ “ระบบ”

5.2 ADKAR Model

ADKAR เป็น change management model ที่นิยมใช้ในองค์กร IT พัฒนาโดย Prosci ประกอบด้วย 5 ขั้นตอน:

ADKAR Model:

A — Awareness (ตระหนักรู้)
├── ทำไมต้องเปลี่ยน? อะไรคือปัญหาของระบบเดิม?
├── Communication: email, town hall, presentation
└── ตัวอย่าง: "ระบบ email เดิมเกิด outage 5 ครั้ง/เดือน
    ทำให้เสียเวลาทำงาน 40 ชม./เดือน"

D — Desire (ความต้องการ)
├── ทำให้คนอยากเปลี่ยน ไม่ใช่แค่รู้ว่าต้องเปลี่ยน
├── What's in it for me? (WIIFM)
├── Identify change champions ในแต่ละ department
└── ตัวอย่าง: "ระบบใหม่จะมี mobile app ให้ทำงานได้ทุกที่
    และ storage เพิ่มจาก 5GB เป็น 50GB"

K — Knowledge (ความรู้)
├── Training ให้คนรู้วิธีใช้ระบบใหม่
├── จัดทำ training materials, videos, quick guides
├── Hands-on workshops
└── ตัวอย่าง: จัด training Microsoft 365 ให้ทุก department
    3 sessions × 2 ชม. ต่อ department

A — Ability (ความสามารถ)
├── ให้ support ช่วงแรกที่เปลี่ยน (hypercare period)
├── Help desk, floor walkers, FAQ
├── Practice opportunities
└── ตัวอย่าง: 2 สัปดาห์แรก มี IT support ประจำทุกชั้น
    + dedicated Teams channel สำหรับถามปัญหา

R — Reinforcement (เสริมแรง)
├── ติดตามว่าคน adopt ระบบใหม่จริงไหม
├── Celebrate success, share positive feedback
├── Address resistance ที่เหลืออยู่
└── ตัวอย่าง: ประกาศผล "Department ที่ adopt เร็วที่สุด"
    + collect feedback สำหรับ improvement

ส่วนที่ 6: Status Reporting & Vendor Management

6.1 Project Status Report

PM ต้องรายงาน status ของโปรเจคเป็นประจำ ให้ stakeholders ทราบว่าโปรเจคเป็นอย่างไร สิ่งสำคัญคือต้องสื่อสารแบบ executive-friendly — ไม่ technical เกินไป เน้น status, risks, actions needed

Weekly Status Report Template:

PROJECT STATUS REPORT
═════════════════════════════════════
Project: Network Infrastructure Upgrade
Report Date: 2026-04-08
PM: [ชื่อ PM]

OVERALL STATUS: 🟡 YELLOW (มี risks ต้อง monitor)

Summary:
Week 3 of 16. Planning phase 80% complete.
Network design approved. RFQ sent to 3 vendors.

┌──────────────┬────────┬────────────────────────┐
│ Area         │ Status │ Notes                  │
├──────────────┼────────┼────────────────────────┤
│ Schedule     │ GREEN  │ On track               │
│ Budget       │ GREEN  │ Within estimate        │
│ Scope        │ GREEN  │ No changes             │
│ Risk         │ YELLOW │ Lead time concern      │
│ Resources    │ GREEN  │ Team allocated         │
└──────────────┴────────┴────────────────────────┘

Key Accomplishments This Week:
• Network design document approved by CIO
• RFQ sent to Cisco, Aruba, Juniper
• Lab environment setup completed

Planned Next Week:
• Vendor presentations (3 sessions)
• Complete migration plan draft
• Begin test configurations in lab

Issues & Risks:
• [RISK] Cisco lead time may be 10-12 weeks
  Action: Evaluate Aruba as alternative
• [ISSUE] Lab server needs RAM upgrade for testing
  Action: PO submitted, expected delivery Friday

Decisions Needed:
• Approve vendor selection by April 15
• Confirm maintenance window schedule with Operations

6.2 Vendor Management สำหรับ IT Projects

โปรเจค IT ส่วนใหญ่ต้องทำงานกับ vendors — ไม่ว่าจะเป็นการซื้ออุปกรณ์, จ้าง system integrator, หรือ subscribe cloud service การจัดการ vendor ให้ดีเป็นสิ่งสำคัญ:

RFP/RFQ Process: เมื่อต้องเลือก vendor ควรทำ Request for Proposal (RFP) หรือ Request for Quotation (RFQ) เพื่อเปรียบเทียบ options อย่างเป็นระบบ กำหนด evaluation criteria ชัดเจน เช่น ราคา 40%, คุณภาพ 30%, support 20%, timeline 10%

SLA Management: กำหนด Service Level Agreement ให้ชัดเจนก่อนเริ่มงาน ระบุ response time, resolution time, uptime guarantee, penalties ถ้าไม่ทำตาม SLA

Contract Management: อ่าน contract ให้ละเอียด โดยเฉพาะ scope of work, payment terms, warranty, liability ถ้าไม่แน่ใจ ปรึกษาฝ่ายกฎหมาย

6.3 Budget Tracking

การ track budget เป็นหน้าที่สำคัญของ PM ต้องรู้ตลอดเวลาว่าใช้งบไปเท่าไหร่ เหลือเท่าไหร่ มีแนวโน้มจะเกินหรือไม่:

Budget Tracking — Earned Value Management (EVM):

Key Metrics:
├── PV (Planned Value): งบที่ plan ว่าจะใช้ ณ จุดนี้
├── EV (Earned Value): มูลค่างานที่ทำเสร็จจริง ณ จุดนี้
├── AC (Actual Cost): เงินที่ใช้จริง ณ จุดนี้
│
├── SV (Schedule Variance) = EV - PV
│   SV > 0 = ahead of schedule
│   SV < 0 = behind schedule
│
├── CV (Cost Variance) = EV - AC
│   CV > 0 = under budget
│   CV < 0 = over budget
│
├── SPI (Schedule Performance Index) = EV / PV
│   SPI > 1.0 = ahead of schedule
│   SPI < 1.0 = behind schedule
│
└── CPI (Cost Performance Index) = EV / AC
    CPI > 1.0 = under budget
    CPI < 1.0 = over budget

ตัวอย่าง:
Budget: 3,500,000 THB
ณ เดือนที่ 2:
PV = 1,200,000 (plan จะใช้ 1.2M ณ จุดนี้)
EV = 1,000,000 (ทำงานเสร็จ = มูลค่า 1M)
AC = 1,100,000 (ใช้เงินจริง 1.1M)

SV = 1,000,000 - 1,200,000 = -200,000 → BEHIND schedule
CV = 1,000,000 - 1,100,000 = -100,000 → OVER budget
SPI = 1,000,000 / 1,200,000 = 0.83 → ช้ากว่า plan 17%
CPI = 1,000,000 / 1,100,000 = 0.91 → เกินงบ 9%

EAC (Estimate at Completion) = Budget / CPI
= 3,500,000 / 0.91 = 3,846,154 THB
→ คาดว่าจะเกินงบ 346,154 THB ถ้า trend นี้ดำเนินต่อ

ส่วนที่ 7: IT Documentation — ประเภทเอกสารที่ IT Professional ต้องเขียน

7.1 ทำไม Documentation ถึงสำคัญ?

IT Professional จำนวนมากเกลียดการเขียน documentation — "ผมเป็นช่าง IT ไม่ใช่นักเขียน" แต่ในความเป็นจริง documentation คือสิ่งที่แยก IT Professional ระดับ "ดี" ออกจากระดับ "เยี่ยม" เหตุผลที่ documentation สำคัญ:

Knowledge Preservation: เมื่อคนลาออก ถ้าไม่มี documentation ความรู้ก็หายไปด้วย องค์กรต้องเสียเวลาและค่าใช้จ่ายมหาศาลในการ "เรียนรู้ใหม่"

Consistency: ถ้าไม่มี SOP ทุกคนทำงานคนละแบบ ผลลัพธ์ก็ไม่สม่ำเสมอ documentation ช่วยให้ทุกคนทำตามมาตรฐานเดียวกัน

Faster Troubleshooting: เมื่อเกิดปัญหาตอนตี 3 ถ้ามี runbook ที่ดีจะแก้ได้เร็วกว่าหา "คนรู้" มาช่วย

Compliance: ISO 27001, PCI-DSS, SOC 2 ล้วนกำหนดให้ต้องมี documentation

Onboarding: คนใหม่ที่เข้ามาสามารถเรียนรู้ได้เร็วถ้ามี documentation ดีๆ

7.2 ประเภท IT Documentation

ประเภทเอกสาร IT ที่ต้องรู้:

1. Network Diagrams (แผนผังระบบเครือข่าย)
   ├── Physical Topology: แสดงการเชื่อมต่อจริง
   ├── Logical Topology: แสดง IP, VLAN, routing
   ├── Rack Diagrams: แสดงตำแหน่งอุปกรณ์ใน rack
   └── ต้อง update ทุกครั้งที่เปลี่ยนแปลง!

2. Runbooks (คู่มือปฏิบัติงาน)
   ├── Step-by-step procedures สำหรับงาน routine
   ├── ตัวอย่าง: "วิธี restart service X เมื่อ alert Y เกิด"
   ├── เขียนให้คนใหม่ทำตามได้
   └── ต้องมี troubleshooting steps

3. SOPs (Standard Operating Procedures)
   ├── ขั้นตอนมาตรฐานสำหรับงานสำคัญ
   ├── ตัวอย่าง: "ขั้นตอนการสร้าง user account ใหม่"
   ├── ผ่าน approval process
   └── Review ทุก 6-12 เดือน

4. Knowledge Base Articles (KB)
   ├── บทความแก้ปัญหาเฉพาะเรื่อง
   ├── ตัวอย่าง: "แก้ปัญหา VPN ไม่ connect บน Windows 11"
   ├── เขียนจาก incidents ที่เกิดบ่อย
   └── อาจเปิดให้ end-user ดูได้

5. As-Built Documents
   ├── เอกสารที่อธิบายว่าระบบถูก build อย่างไร
   ├── IP addresses, configurations, passwords
   ├── สร้างหลังจาก deploy เสร็จ
   └── เป็น reference สำหรับ operations team

6. System Design Documents
   ├── Architecture diagrams
   ├── Data flow diagrams
   ├── Integration specifications
   └── Capacity planning

7. Disaster Recovery Plan (DRP)
   ├── ขั้นตอนกู้คืนระบบเมื่อเกิดภัยพิบัติ
   ├── RTO/RPO specifications
   ├── Contact lists
   └── Test ทุก 6-12 เดือน

8. Change Management Records
   ├── บันทึกทุก change ที่ทำกับระบบ
   ├── Who, What, When, Why
   ├── Approval records
   └── Rollback procedures

7.3 การเขียน Runbook ที่ดี

Runbook เป็น documentation ที่ IT Operations ใช้บ่อยที่สุด — เป็นคู่มือ step-by-step สำหรับทำงาน routine หรือแก้ปัญหาเฉพาะเรื่อง ตัวอย่าง:

RUNBOOK: Database Backup Verification
═══════════════════════════════════════

Purpose: ตรวจสอบว่า daily database backup สำเร็จทุกวัน
Owner: DBA Team
Last Updated: 2026-04-01
Review Date: 2026-10-01

Prerequisites:
- SSH access to db-primary-01
- Read access to /backup/mysql/
- Monitoring dashboard access (Grafana)

Procedure:
─────────
Step 1: Check backup job status
   $ ssh db-primary-01
   $ cat /var/log/backup/mysql_backup_$(date +%Y%m%d).log
   Expected: "Backup completed successfully"
   If FAILED → Go to Troubleshooting section

Step 2: Verify backup file
   $ ls -la /backup/mysql/
   Expected: File dated today, size > 5 GB
   $ md5sum /backup/mysql/latest.sql.gz
   Compare with: /backup/mysql/latest.md5

Step 3: Test restore (weekly only - every Monday)
   $ mysql -u restore_test -p < /backup/mysql/latest.sql
   Expected: No errors, row counts match production
   Document results in: [SharePoint link]

Step 4: Verify offsite copy
   Check S3 bucket: s3://company-backup/mysql/
   Expected: Today's file present and matches size

Troubleshooting:
─────────────────
Backup job failed:
1. Check disk space: df -h /backup/
   If full → Archive old backups to S3, delete local
2. Check MySQL status: systemctl status mysql
   If down → Follow "MySQL Recovery" runbook
3. Check cron job: crontab -l | grep backup
   If missing → Restore from /etc/cron.d/mysql-backup

Escalation:
- Level 1: DBA on-call (ext. 1234)
- Level 2: DBA Manager (ext. 5678)
- Level 3: IT Director (ext. 9012)

7.4 การเขียน SOP ที่ได้มาตรฐาน

SOP (Standard Operating Procedure) เป็นเอกสารที่เป็นทางการกว่า Runbook ต้องผ่าน approval process และ review เป็นประจำ:

SOP Template:

STANDARD OPERATING PROCEDURE
═══════════════════════════════════════

SOP Number: IT-SOP-042
Title: New Employee IT Onboarding
Version: 2.1
Effective Date: 2026-01-15
Next Review: 2027-01-15
Author: IT Service Desk Manager
Approved By: IT Director

1. PURPOSE
   กำหนดขั้นตอนมาตรฐานสำหรับการ setup IT ให้พนักงานใหม่
   เพื่อให้พนักงานพร้อมทำงานตั้งแต่วันแรก

2. SCOPE
   ครอบคลุมพนักงาน full-time, contract ทุกตำแหน่ง
   ไม่รวม: interns, visitors

3. RESPONSIBILITIES
   - HR: แจ้ง IT ล่วงหน้า 5 วันทำการก่อนเริ่มงาน
   - IT Service Desk: ดำเนินการตาม procedure นี้
   - IT Security: Approve access requests

4. PROCEDURE
   4.1 เมื่อได้รับ request จาก HR (Day -5):
       □ สร้าง ticket ใน ITSM system
       □ ตรวจสอบข้อมูลพนักงาน (ชื่อ, ตำแหน่ง, department)
       □ กำหนด IT equipment ตาม role

   4.2 สร้าง Accounts (Day -3):
       □ Active Directory account
       □ Email account (Microsoft 365)
       □ VPN account (ถ้าจำเป็น)
       □ Application accounts ตาม role
       □ Set temporary password

   4.3 เตรียมอุปกรณ์ (Day -2):
       □ Laptop: install OS, join domain, install software
       □ Monitor, keyboard, mouse
       □ Headset (ถ้า role ต้องใช้)
       □ Phone setup (extension assignment)
       □ Test ทุกอย่างก่อนส่งมอบ

   4.4 วันเริ่มงาน (Day 0):
       □ ส่งมอบอุปกรณ์
       □ IT Orientation (30 นาที)
       □ ให้ login credentials
       □ ลงทะเบียน MFA
       □ ทดสอบ access ทุกระบบ
       □ ให้ IT Support contact information

5. RECORDS
   เก็บ ticket records ใน ITSM ≥ 3 ปี

6. REVISION HISTORY
   v2.1 (2026-01-15): เพิ่ม MFA setup step
   v2.0 (2025-07-01): เปลี่ยนจาก Google → M365
   v1.0 (2024-01-01): Initial version

ส่วนที่ 8: Documentation Tools — เครื่องมือสำหรับเขียนเอกสาร IT

8.1 Confluence (Atlassian)

Confluence เป็น wiki/documentation platform ที่นิยมที่สุดในวงการ IT โดยเฉพาะองค์กรที่ใช้ Jira อยู่แล้ว ข้อดีคือ integrate กับ Jira ได้ดีมาก, templates มาให้เยอะ, search ทำงานดี, version control built-in ข้อเสียคือ UI อาจซับซ้อน, ราคาสูงสำหรับ team ใหญ่, performance อาจช้าเมื่อ page เยอะ

8.2 Notion

Notion เป็น all-in-one workspace ที่ได้รับความนิยมเพิ่มขึ้นมากในช่วงไม่กี่ปีที่ผ่านมา สามารถใช้เป็น wiki, project management, database ได้ในที่เดียว ข้อดีคือ UI สวย ใช้ง่ายมาก, flexible, templates มีให้เลือกเยอะ, มี AI features ข้อเสียคือ search ยังไม่ดีเท่า Confluence, offline mode จำกัด, permissions ยังไม่ granular พอสำหรับ enterprise

8.3 GitBook

GitBook เหมาะกับ developer documentation — sync กับ Git repositories ได้, เขียนด้วย Markdown, มี version control ผ่าน Git ข้อดีคือ Markdown-based, clean UI, Git integration, API documentation support ข้อเสียคือ เหมาะกับ developer docs มากกว่า general IT documentation, free tier จำกัด

8.4 Wiki.js

Wiki.js เป็น open-source wiki ที่สวยงามและ powerful — self-hosted ได้, สนับสนุน Markdown, WYSIWYG editor, multiple authentication backends ข้อดีคือ ฟรี, self-hosted (data อยู่กับเรา), feature ครบ, UI modern ข้อเสียคือ ต้อง self-host (ต้องดูแล server), community เล็กกว่า Confluence

8.5 Microsoft SharePoint

สำหรับองค์กรที่ใช้ Microsoft 365 SharePoint เป็นตัวเลือกที่สมเหตุสมผลเพราะรวมอยู่ใน license อยู่แล้ว ข้อดีคือ integrate กับ M365, permissions ดีมาก, workflow automation (Power Automate) ข้อเสียคือ UI ไม่ค่อยดี, จัดการ pages ยาก, search ดีเฉพาะถ้า set up ถูก

Documentation Tools Comparison:

┌───────────────┬────────────┬────────────┬──────────┬──────────┬──────────┐
│ Feature       │ Confluence │ Notion     │ GitBook  │ Wiki.js  │SharePoint│
├───────────────┼────────────┼────────────┼──────────┼──────────┼──────────┤
│ ราคา          │ $$-$$$     │ $-$$       │ $-$$     │ Free/OSS │ ใน M365  │
│ Ease of Use   │ ★★★        │ ★★★★★      │ ★★★★     │ ★★★      │ ★★       │
│ IT Doc        │ ★★★★★      │ ★★★★       │ ★★★      │ ★★★★     │ ★★★      │
│ Search        │ ★★★★       │ ★★★        │ ★★★★     │ ★★★      │ ★★★      │
│ Permissions   │ ★★★★       │ ★★★        │ ★★★      │ ★★★★     │ ★★★★★    │
│ Self-Host     │ ✓ (DC)     │ ✗          │ ✗        │ ✓        │ ✗/Hybrid │
│ Templates     │ ★★★★★      │ ★★★★★      │ ★★★      │ ★★★      │ ★★★      │
│ API           │ ★★★★       │ ★★★★       │ ★★★★     │ ★★★      │ ★★★★     │
│ Best For      │ Enterprise │ Startup/   │ Dev/API  │ SMB      │ M365 org │
│               │ IT teams   │ SMB        │ Docs     │          │          │
└───────────────┴────────────┴────────────┴──────────┴──────────┴──────────┘

ส่วนที่ 9: Network Diagram Tools — เครื่องมือวาดแผนผังระบบ

9.1 draw.io (diagrams.net)

draw.io (ปัจจุบันเปลี่ยนชื่อเป็น diagrams.net) เป็นเครื่องมือวาด diagram ที่ดีที่สุดในตลาด — ฟรี ทั้ง online version และ desktop app มี stencils สำหรับ network devices (Cisco, AWS, Azure, GCP) พร้อมใช้ สามารถ export เป็น PNG, SVG, PDF, XML ได้ integrate กับ Confluence, Google Drive, OneDrive, GitHub ได้

สำหรับ IT Professional แนะนำ draw.io เป็นอันดับแรกเพราะ ฟรี, feature ครบ, community ใหญ่, stencil library มาก

9.2 Lucidchart

Lucidchart เป็น cloud-based diagramming tool ที่สวยงามและใช้ง่ายมาก ข้อดีคือ real-time collaboration ดีมาก, templates มากมาย, integrate กับ Confluence/Jira/Slack, auto-import network topology ได้ ข้อเสียคือ มีค่าใช้จ่าย (free tier จำกัดมาก), ต้อง online เท่านั้น

9.3 Microsoft Visio

Visio เป็นมาตรฐานอุตสาหกรรมมายาวนาน — ได้รับความนิยมในองค์กร enterprise โดยเฉพาะที่ใช้ Microsoft ecosystem ข้อดีคือ feature ครบสุด, stencil library ใหญ่สุด, Visio Viewer ฟรี, integrate กับ SharePoint ข้อเสียคือ ราคาแพง, Windows only (มี web version แต่จำกัด), learning curve สูง

9.4 Network Diagram Best Practices

Network Diagram Best Practices:

1. Layer Separation
   ├── Physical Diagram: สายเชื่อมต่อจริง, rack location
   ├── Logical Diagram: IP addresses, VLANs, routing
   └── Application Flow: data flow ระหว่าง applications

2. Naming Convention
   ├── ใช้ hostname ที่สื่อความหมาย
   │   ดี: bkk-core-sw01 (Bangkok, Core, Switch, #01)
   │   ไม่ดี: switch1
   ├── แสดง IP addresses ที่สำคัญ
   └── แสดง interface names (Gi0/1, Eth1/1)

3. Color Coding
   ├── Red: WAN/Internet links
   ├── Blue: LAN/Internal links
   ├── Green: Management network
   ├── Yellow: DMZ
   └── Gray: Out of scope / planned

4. Must-Have Information
   ├── Title, date, version number, author
   ├── Legend (อธิบาย symbols & colors)
   ├── Scale/Scope (อะไรอยู่ใน diagram อะไรไม่)
   ├── IP subnets for each segment
   └── Revision history

5. Keep It Updated!
   ├── Update ทุกครั้งที่ change ระบบ
   ├── Version control (v1.0, v1.1, v2.0)
   ├── Store ใน central location (SharePoint/Confluence)
   └── Annual review & verification

ส่วนที่ 10: Post-Implementation Review & Lessons Learned

10.1 Post-Implementation Review (PIR)

หลังจากโปรเจค go-live แล้ว สิ่งที่ PM ต้องทำคือ Post-Implementation Review (PIR) — ประเมินว่าโปรเจคประสบความสำเร็จหรือไม่ อะไรทำได้ดี อะไรต้องปรับปรุง

Post-Implementation Review Checklist:

1. Objectives Achievement
   □ โปรเจคบรรลุ objectives ที่ตั้งไว้หรือไม่?
   □ Deliverables ครบตาม scope หรือไม่?
   □ Quality ได้ตาม requirements หรือไม่?

2. Schedule Performance
   □ เสร็จตรงเวลาหรือไม่? (SPI)
   □ ถ้าช้า: สาเหตุคืออะไร?
   □ Milestones ไหนที่ miss?

3. Budget Performance
   □ ใช้งบตาม estimate หรือไม่? (CPI)
   □ ถ้าเกิน: ทำไม?
   □ ค่าใช้จ่ายที่ไม่ได้คาด?

4. Stakeholder Satisfaction
   □ User พอใจกับผลลัพธ์หรือไม่?
   □ Sponsor พอใจหรือไม่?
   □ Team member feedback?

5. Risk Management Effectiveness
   □ Risk ที่ identify ไว้เกิดขึ้นจริงไหม?
   □ Risk ที่ไม่ได้ identify เกิดขึ้นไหม?
   □ Response plans ทำงานได้ดีหรือไม่?

6. Lessons Learned ★ สำคัญที่สุด
   □ What went well? (ทำต่อไป)
   □ What didn't go well? (ปรับปรุง)
   □ What would we do differently? (เปลี่ยนแปลง)
   □ Document & share กับองค์กร

10.2 Lessons Learned — การเก็บบทเรียน

Lessons Learned เป็นส่วนที่สำคัญที่สุดของ PIR แต่มักถูกมองข้าม ทุก IT Project ไม่ว่าจะสำเร็จหรือล้มเหลว มีบทเรียนที่มีค่า ถ้าไม่ document และ share บทเรียนเหล่านี้จะหายไปและองค์กรจะทำผิดซ้ำ

Lessons Learned Template:

┌────┬──────────────────┬──────────┬───────────────────┐
│ #  │ Lesson           │ Category │ Recommendation    │
├────┼──────────────────┼──────────┼───────────────────┤
│ 1  │ Vendor lead time │ Procure- │ สั่งอุปกรณ์ก่อน  │
│    │ นานกว่าที่คาด   │ ment     │ plan 2 เดือน      │
│    │ (12 สัปดาห์ vs  │          │ มี backup vendor  │
│    │ estimate 8)      │          │ เสมอ             │
├────┼──────────────────┼──────────┼───────────────────┤
│ 2  │ Lab testing ช่วย │ Testing  │ จัดสรร lab ให้ทุก │
│    │ เจอปัญหา config  │          │ โปรเจค ไม่ข้าม   │
│    │ ก่อน deploy จริง │          │ ขั้นตอนนี้เด็ดขาด│
├────┼──────────────────┼──────────┼───────────────────┤
│ 3  │ Weekly status    │ Communi- │ รายงานสั้น กระชับ │
│    │ report ช่วยให้   │ cation   │ ทุกสัปดาห์ ใช้    │
│    │ stakeholder มี   │          │ RAG status        │
│    │ confidence       │          │ (Red/Amber/Green) │
├────┼──────────────────┼──────────┼───────────────────┤
│ 4  │ Change freeze    │ Change   │ หยุด change อื่น  │
│    │ ระหว่าง migration│ Mgmt     │ ระหว่าง migration │
│    │ ลด risk ได้มาก  │          │ window เสมอ       │
└────┴──────────────────┴──────────┴───────────────────┘

ส่วนที่ 11: Certifications สำหรับสาย IT Project Management

11.1 PMP (Project Management Professional)

PMP จาก Project Management Institute (PMI) เป็น certification ที่ได้รับการยอมรับมากที่สุดในโลกสำหรับ project manager ข้อกำหนด: ต้องมีประสบการณ์ PM อย่างน้อย 3 ปี (ถ้ามีปริญญาตรี) หรือ 5 ปี (ถ้าไม่มี) + 35 ชม. PM education สอบ 180 ข้อ ใน 230 นาที ผสม Predictive, Agile, Hybrid เงินเดือน PMP holder สูงกว่า non-PMP เฉลี่ย 25-33%

11.2 PRINCE2

PRINCE2 (Projects IN Controlled Environments) เป็น PM methodology ที่นิยมในยุโรป, UK, ออสเตรเลีย มี 2 ระดับ: Foundation (พื้นฐาน) และ Practitioner (ประยุกต์ใช้) ข้อดีคือ structured methodology ที่ชัดเจน เหมาะกับองค์กรที่ต้องการ governance ที่เข้มงวด ไม่ต้องมีประสบการณ์ก่อนสอบ Foundation ได้

11.3 CAPM (Certified Associate in Project Management)

CAPM จาก PMI เป็น entry-level certification สำหรับคนที่เริ่มต้นสาย PM ไม่ต้องมีประสบการณ์ PM ก่อน (ต้องมี 23 ชม. PM education) เหมาะกับ IT Professional ที่ต้องการเริ่มเข้าสู่ project management

11.4 Certification Roadmap สำหรับ IT PM

IT Project Management Certification Path:

Entry Level (0-2 ปี):
├── CAPM (PMI) — PM fundamentals
├── PRINCE2 Foundation — Methodology basics
├── Google Project Management Certificate — Beginner
└── CompTIA Project+ — IT-focused PM basics

Mid Level (2-5 ปี):
├── PMP (PMI) ★ Gold standard
├── PRINCE2 Practitioner
├── PMI-ACP (Agile Certified Practitioner)
├── CSM (Certified ScrumMaster)
└── SAFe Agilist

Senior Level (5+ ปี):
├── PgMP (Program Management Professional)
├── PfMP (Portfolio Management Professional)
├── PMI-RMP (Risk Management Professional)
└── Management/Leadership certifications

IT-Specific Additions:
├── ITIL 4 Foundation/CDS — IT Service context
├── TOGAF — Enterprise Architecture
├── CGEIT (ISACA) — IT Governance
└── DevOps certifications

ส่วนที่ 12: Documentation Best Practices 2026

12.1 Documentation as Code

แนวทางใหม่ที่ได้รับความนิยมในปี 2026 คือ Documentation as Code (Docs as Code) — ใช้เครื่องมือเดียวกับที่ developers ใช้ในการเขียน code มาเขียน documentation เช่น Markdown, Git version control, CI/CD pipeline สำหรับ build documentation

Docs as Code Workflow:

1. เขียน documentation ในรูปแบบ Markdown (.md)
2. จัดเก็บใน Git repository (GitHub, GitLab)
3. Review ผ่าน Pull Request (peer review)
4. CI/CD pipeline auto-build เป็น website
5. Deploy ไปยัง static site (GitHub Pages, Netlify)

เครื่องมือ Docs as Code:
├── MkDocs — Python-based, Material theme สวยมาก
├── Hugo — Go-based, เร็วมาก
├── Docusaurus — React-based (Facebook/Meta)
├── Sphinx — Python documentation standard
└── Jekyll — GitHub Pages default

ข้อดี Docs as Code:
+ Version control (ดู history, diff, blame ได้)
+ Peer review ผ่าน PR (quality control)
+ Automation (auto-build, auto-deploy)
+ Developer-friendly (ใช้ tools เดียวกัน)
+ Search & navigation ดี (generated sites)

ข้อเสีย:
- Learning curve สำหรับ non-developers
- ต้อง setup infrastructure (Git, CI/CD)
- ไม่เหมาะกับ documentation ที่ non-technical คน edit

12.2 AI-Assisted Documentation

ในปี 2026 AI tools ช่วยเขียน documentation ได้มากขึ้นมาก:

การใช้ AI ช่วยเขียน documentation: ใช้ AI ช่วย draft runbooks จาก bullet points, ใช้ AI สรุป meeting notes เป็น action items, ใช้ AI แปลง CLI outputs เป็น KB articles, ใช้ AI ช่วย review documentation หา inconsistencies

แต่ต้องจำไว้ว่า AI เป็นแค่เครื่องมือช่วย ไม่สามารถแทน human review ได้ ต้อง verify ข้อมูลที่ AI สร้างขึ้นเสมอ โดยเฉพาะ technical details เช่น IP addresses, commands, configurations

12.3 10 Golden Rules ของ IT Documentation

10 Golden Rules ของ IT Documentation:

1. Write for your audience
   └── เขียนให้คนที่จะใช้ ไม่ใช่เขียนให้ตัวเอง
       "ถ้าคนใหม่ที่เพิ่งเข้ามาอ่านแล้วทำตามได้ไหม?"

2. Keep it simple
   └── ใช้ภาษาที่เข้าใจง่าย ไม่ใช้ศัพท์เทคนิคเกินไป
       หรือถ้าต้องใช้ ให้อธิบาย

3. Use consistent formatting
   └── Headings, numbering, fonts ต้องสม่ำเสมอ
       ใช้ template มาตรฐาน

4. Include screenshots & diagrams
   └── ภาพช่วยให้เข้าใจได้เร็วกว่าข้อความ
       "A picture is worth a thousand words"

5. Date & version everything
   └── ทุก document ต้องมี: วันที่สร้าง, วันที่ update,
       version number, ผู้เขียน

6. Make it searchable
   └── ใช้ keywords ที่คนจะค้นหา
       จัดหมวดหมู่ให้ดี, tag ให้ครบ

7. Review & update regularly
   └── ข้อกำหนดขั้นต่ำ: review ทุก 6-12 เดือน
       Update ทุกครั้งที่ระบบเปลี่ยน

8. Store in a central location
   └── ที่เดียว ที่ทุกคนเข้าถึงได้
       ไม่ใช่เก็บใน laptop ส่วนตัว

9. Test your procedures
   └── ให้คนอื่นลองทำตามที่เขียน
       ถ้าทำไม่ได้ ต้อง revise

10. Delete outdated docs
    └── Document ที่ outdated อันตรายกว่าไม่มีเลย
        เพราะอาจทำให้คนทำตามข้อมูลผิดๆ

สรุป: IT Project Management & Documentation Checklist

IT Project Management และ Documentation เป็นทักษะที่ IT Professional ทุกคนต้องพัฒนา ไม่ว่าคุณจะเป็น Network Engineer, System Admin, Developer, หรือ IT Manager การจัดการโปรเจคอย่างเป็นระบบและเขียน documentation ที่ดีจะทำให้งานมีคุณภาพ, ลด risk, และสร้างคุณค่าให้กับองค์กร

IT Project Management Checklist:

□ เขียน Project Charter ก่อนเริ่มทุกโปรเจค
□ สร้าง WBS เพื่อแบ่งงานให้ชัดเจน
□ ทำ Gantt Chart / Sprint Plan สำหรับ scheduling
□ กำหนด RACI ให้ชัดเจน
□ ทำ Risk Register และ update ทุกสัปดาห์
□ รายงาน Status ให้ stakeholders สม่ำเสมอ
□ จัดการ Change อย่างเป็นระบบ
□ Track Budget ด้วย EVM
□ ทำ Post-Implementation Review ทุกโปรเจค
□ เก็บ Lessons Learned และ share กับองค์กร

IT Documentation Checklist:

□ Network Diagrams up-to-date
□ Runbooks สำหรับทุก critical process
□ SOPs สำหรับงาน routine สำคัญ
□ Knowledge Base articles จาก common issues
□ As-Built documents สำหรับทุกระบบ
□ DR Plan ที่ test แล้ว
□ เลือก documentation tool ที่เหมาะกับองค์กร
□ Review & update documents ตาม schedule
□ Store ใน central location ที่ accessible
□ ฝึก team ให้เขียน documentation เป็น culture

การเริ่มต้นไม่ยาก — เริ่มจากโปรเจคเล็กๆ เขียน Project Charter 1 หน้า, WBS ง่ายๆ, status report ทุกสัปดาห์ แล้วค่อยๆ เพิ่ม maturity จนเป็นกระบวนการที่แข็งแกร่ง สำหรับ documentation เริ่มจาก network diagram 1 แผ่น และ runbook 1 ชิ้นสำหรับ process ที่สำคัญที่สุด แล้วค่อยๆ สร้างเพิ่ม เมื่อทำสม่ำเสมอ จะกลายเป็น culture ที่ทุกคนในทีมร่วมมือกัน