Steering Committee ≠ Project Manager#

นี่คือกับดักข้อสอบที่เห็นบ่อย

Steering Committee = กรรมการระดับผู้บริหาร (CFO, CIO, head of business unit ที่เกี่ยวข้อง) ทำหน้าที่ oversight ของโปรเจ็ค ตัดสินเรื่องใหญ่ เปลี่ยน scope, อนุมัติ budget เพิ่ม, แก้ปัญหาที่ escalate มาจาก PM, อนุมัติให้ผ่าน gate ระหว่าง phase

Project Manager (PM) = คน รันโปรเจ็ครายวัน ตามงาน ออก status report จัด resource ส่ง deliverable escalate ปัญหาให้ Steering ถ้าตัดสินเองไม่ได้

สองตำแหน่งคนละเลเวลกัน ห้ามแทนกัน

Project Sponsor#

คนที่ลงนามให้โปรเจ็คนี้เกิด มักเป็น executive ที่ได้ประโยชน์จากระบบใหม่ตรงที่สุด เช่น CFO ถ้าเป็นโปรเจ็ค ERP, head of sales ถ้าเป็น CRM

Sponsor ไม่ได้รันโปรเจ็ค แต่เป็นคนที่ ปกป้องโปรเจ็ค เมื่อมีคนตั้งคำถามหรือ budget ถูกตัด และเป็นคนที่ business case ต้องโน้มน้าวให้ได้

Quality Assurance Function#

ทีมที่ตรวจคุณภาพของ deliverable ระหว่างทาง ไม่ใช่หลัง deliver เสร็จแล้วค่อยตรวจ

IS Auditor — และความตึงเครียดของบทบาท#

นี่คือเรื่องที่อยากย้ำต่อจากตอน 23

IS auditor เข้าโปรเจ็คได้ใน 2 บทบาท:

บทบาท A: ที่ปรึกษาฝัง (consultant / advisor) — เข้าไปช่วย review WBS, ตรวจ test plan, แนะนำ control design ให้ฝังเข้า requirements ตั้งแต่ต้น

บทบาท B: ผู้ตรวจอิสระ (auditor) — เข้าไปตรวจหลังจบ phase หรือหลัง go-live เพื่อให้ assurance ต่อ board / audit committee

สำคัญ: ทำได้ทีละบทบาทเท่านั้น ถ้าเข้าไปบทบาท A ลึกแค่ไหน ความเป็นอิสระในการทำบทบาท B ของระบบเดียวกันจะเสียไปตามระดับการมีส่วนร่วม

นี่คือเหตุผลที่ Section 3.8 (postimplementation review) จะย้ำว่า PIR ต้องทำโดย auditor ที่ ไม่เคย มีส่วนร่วมในโปรเจ็คมาก่อน ไม่ใช่เพราะ ISACA จู้จี้ แต่เพราะคนที่เข้าไป design control แล้วมาตรวจ control ของตัวเองจะ rationalize เสมอ

กลับไปอ่าน ตอน 02 และ ตอน 04 ของ Domain 1 ที่คุยเรื่อง independence — Domain 3 คือบททดสอบ independence ที่หนักที่สุดของ auditor

องค์ประกอบของ business case ที่ดี#

ผม distill จากที่อ่านมาแบบนี้ครับ business case ที่ผ่าน auditor ต้องตอบคำถามเหล่านี้ได้ครบ:

• ปัญหาธุรกิจที่จะแก้ คืออะไร ระบุเชิงวัดได้ (เช่น “ลด cycle time ของการปิดเดือนจาก 10 วันเหลือ 3 วัน”) ไม่ใช่ “เพิ่มประสิทธิภาพ”
• ทางเลือกที่พิจารณา รวมทางเลือก “ไม่ทำอะไรเลย” ด้วย ถ้า business case ไม่มีทางเลือกนี้ = น่าสงสัยว่าเป็นเอกสารโน้มน้าว
• ROI / NPV / payback period ตัวเลขที่มี methodology ชัด ไม่ใช่ตั้งใจปั้นให้สวย
• ตัวชี้วัดที่จะใช้วัดผลหลัง go-live ถ้าวัดไม่ได้ตั้งแต่แรก postimplementation review ก็จะวัดไม่ได้
• Risk หลักของโปรเจ็ค และวิธี mitigate

Kill Points / Major Gates#

Kill point = จุดตรวจระหว่าง phase ที่ Steering Committee ตัดสินได้ว่า “ไปต่อ” หรือ “หยุด”

หลายโปรเจ็คเริ่มต้นด้วย business case ที่ดี แต่ 6 เดือนต่อมา บริบทธุรกิจเปลี่ยน คู่แข่งออก solution ที่ดีกว่า, technology platform เก่ากว่าที่คิด, business unit ที่ sponsor ถูกปิดไปเลยก็มี

ถ้าไม่มี kill point โปรเจ็คจะวิ่งต่อด้วย momentum จนจบ ทั้งที่ business case ใช้ไม่ได้แล้ว

มุม IS auditor: ถาม steering committee ว่า “kill point ครั้งสุดท้ายที่คุณ review business case อีกครั้งคือเมื่อไหร่” คำตอบที่บอก “approve ตอน kickoff แล้วก็ run มาเรื่อยๆ” = red flag

IS Auditor ใน feasibility study ทำอะไร#

หลักง่ายๆ ครับ auditor review ไม่ใช่ create

ถ้า auditor เป็นคนเขียน feasibility study เอง ก็เสีย independence ทันที เหมือนคนที่เสนอราคาเป็นคนตรวจราคาตัวเอง

สิ่งที่ auditor ทำใน feasibility study:

• ตรวจว่า ผู้มีส่วนได้เสียครบ ไหม — user groups ที่จะใช้ระบบมี representative ใน study ไหม
• ตรวจว่า ROI ที่อ้าง verifiable ไหม — methodology ในการคำนวณตรงไปตรงมา ตัวเลขมีที่มาที่ไป
• ตรวจว่า alternative ที่พิจารณาครอบคลุม ไหม — มีทางเลือก “ไม่ทำ” รวมอยู่หรือไม่
• ตรวจว่า vendor proposal สมเหตุสมผล ไหม (ถ้ามี vendor RFP)
• ตรวจว่า milestone + sign-off มีและได้รับการอนุมัติจากระดับที่เหมาะสม

มุมที่ผู้บริหารต้องเข้าใจ: Auditor ที่ review feasibility study ไม่ได้มา “ขัดขา” เขามาช่วยให้ business case ที่ผ่านไปแล้ว defend ได้ตอน postimplementation review เพราะถ้า benefit ที่ระบุใน business case วัดไม่ได้ ตอนนั้น โปรเจ็คนี้จะถูก label ว่า “ล้มเหลว” ทั้งที่อาจจะสำเร็จจริง

Project Charter — เอกสารที่ “เปิด” โปรเจ็ค#

Project charter = เอกสารที่ project sponsor เซ็นอนุมัติให้โปรเจ็คนี้เกิดอย่างเป็นทางการ ระบุ:

• วัตถุประสงค์ของโปรเจ็ค
• Stakeholder หลัก
• Scope กว้าง ๆ
• Project manager ที่ได้รับมอบอำนาจ
• ทรัพยากรที่ approved ในระดับ high-level

ถ้าไม่มี charter project manager ทำงานโดยไม่มี mandate ที่ verifiable เมื่อมีคนตั้งคำถามว่า “ใครให้คุณทำเรื่องนี้”

Kickoff + Charter Meeting#

ก่อนเริ่มงานจริง โปรเจ็คที่ดีมี kickoff meeting อย่างเป็นทางการ:

• Charter meeting — sponsor + PM + key stakeholder คุยกันรอบแรก ทำความเข้าใจ charter ร่วมกัน
• Kickoff meeting — PM แจ้งทีมเรื่อง next steps, role, timeline เริ่มต้น
• Scope statement — เอกสารที่ระบุ deliverable ทุกตัวที่ต้องส่งมอบเพื่อบรรลุวัตถุประสงค์

ทุก milestone communication ตั้งแต่จุดนี้ถูก document เป็น project artifacts เพื่อ traceability และ audit ทีหลัง

SMART — กฎเหล็กของ project objectives#

กับดัก: “ทำให้ระบบดีขึ้น” = วัตถุประสงค์โปรเจ็ค

ผิดครับ วัตถุประสงค์ที่ดีต้อง SMART:

• Specific — เฉพาะเจาะจง ไม่กว้าง
• Measurable — วัดได้ด้วยตัวเลข
• Attainable — ทำได้จริงด้วยทรัพยากรที่มี
• Realistic — สมเหตุสมผลในบริบทธุรกิจ
• Timely — มี deadline ชัด

มุม IS auditor: วัตถุประสงค์ที่ไม่ SMART = วัดผลไม่ได้ ตอน PIR (ตอน 30) จะตอบไม่ได้ว่าโปรเจ็คสำเร็จหรือไม่

OBS vs WBS — ตามที่ CRM 28th edition เขียน#

ก่อนเข้า WBS ขอแยกศัพท์ที่ CRM ใช้ — และเป็นจุดที่หลายคนงงเพราะ CRM เองก็ใช้คำที่ดูจะขัดกัน:

ลำดับการทำ — OBS ก่อน → WBS ตาม. OBS ตอบว่า “ของที่จะส่งคืออะไร” → WBS ตอบว่า “เพื่อสร้างของพวกนั้น ต้องทำงานอะไรบ้าง”

เห็นภาพแบบสร้างบ้าน — OBS vs WBS ต่างกันยังไง#

ลองนึกว่าจะ สร้างบ้าน 1 หลัง ครับ

OBS = “บ้านนี้จะมีอะไรบ้าง” — แตก ของ

1
บ้าน
2
├── โครงสร้าง
3
│   ├── ฐานราก
4
│   ├── เสา
5
│   └── หลังคา
6
├── ระบบไฟฟ้า
7
│   ├── สายไฟ
8
│   ├── เต้ารับ
9
│   └── ตู้ควบคุม
10
└── ระบบประปา
11
    ├── ท่อน้ำดี
12
    ├── ท่อน้ำเสีย
13
    └── สุขภัณฑ์

ทุกกล่อง = ของจริงที่จับต้องได้ (ฐานราก, เสา, สายไฟ, ท่อน้ำ) — เป็น noun ทั้งหมด

WBS = “ต้องทำอะไรเพื่อสร้างของพวกนั้น” — แตก งาน

1
สร้างบ้าน
2
├── ฐานราก ส่งมอบเสร็จ           ← deliverable
3
│   └── (Work Package: ขุดดิน + เทคอนกรีต + ฝัง rebar)
4
├── โครงสร้างหลัก ส่งมอบเสร็จ      ← deliverable
5
│   └── (Work Package: ตั้งเสา + ติดคาน + มุงหลังคา)
6
└── ระบบไฟฟ้า ส่งมอบเสร็จ          ← deliverable
7
    └── (Work Package: เดินสายไฟ + ติดเต้ารับ + test ระบบ)

ทุกกล่องของ WBS = deliverable (ของที่ส่งมอบเสร็จแล้ว) — แต่ใน leaf node (กล่องล่างสุด) มีรายการ task ซ่อนอยู่

ความตึงในตำราที่ทำให้คนงง: “WBS = tasks” vs “WBS = deliverables”#

นี่คือจุดที่ CRM 28th edition เขียนตึงในย่อหน้าเดียวกัน — และ exam ใช้ความตึงนี้ออกข้อสอบ:

• CRM ประโยคแรก: “WBS is designed to enumerate all the tasks necessary to build the elements of the OBS”
• CRM ประโยคถัดมา: “The structure of the WBS is constructed around deliverables, not tasks”

อ่านครั้งแรกเหมือนขัดกัน — ขัดกันไหม? ไม่ขัด ถ้าอ่านระดับ zoom ให้ถูก:

WBS เป็นทั้งสองอย่าง ในเวลาเดียวกัน — แค่อยู่คนละชั้น zoom

• ถ้ามองจากภายนอก (zoom out) → เห็น tree ของ deliverable
• ถ้าเปิด leaf node ออกดู (zoom in) → เห็น checklist ของ task

WBS ไม่ใช่ tree ของ task ที่ flat — เป็น tree ของ deliverable ที่แต่ละ leaf เก็บ task ไว้ข้างใน

กับดัก exam: ถ้าโจทย์ถามว่า WBS structured around อะไร → ตอบ deliverables. ถ้าถามว่า WBS ใช้เพื่ออะไร → ตอบ “enumerate tasks เพื่อสร้าง elements ของ OBS”. 2 ประโยคนี้ทั้งคู่ถูก เพียงแต่ตอบคำถามคนละ zoom level

ภาพรวมลำดับการคิด: OBS → WBS → Task#

graph LR
  A["1. OBS<br/>(ส่งของอะไร)<br/>= บ้าน + โครงสร้าง + ไฟฟ้า"] -->
  B["2. WBS<br/>(deliverable ระดับงาน)<br/>= ฐานราก/เสา/หลังคา ส่งเสร็จ"] -->
  C["3. Work Package<br/>(task ลึกสุด)<br/>= ขุดดิน + เทคอนกรีต"]
  style A fill:#a5b4fc,color:#000
  style B fill:#86efac,color:#000
  style C fill:#fcd34d,color:#000

• OBS = ภาพใหญ่ของของที่จะส่ง — “บ้าน 1 หลังประกอบด้วย 3 ระบบ”
• WBS = แตก OBS เป็น deliverable ที่ส่งมอบได้ทีละชิ้น — “ฐานรากส่งเสร็จ → โครงสร้างส่งเสร็จ → ไฟฟ้าส่งเสร็จ”
• Work Package = leaf node ของ WBS ที่บอกว่าต้องทำ task อะไรบ้างเพื่อ produce deliverable นั้น

หมายเหตุ — ทำไม PMP / business school ส่วนใหญ่สอนแค่ “WBS = deliverable” ไม่พูด OBS#

ในวงการ project management ทั่วไป — ไม่ค่อยใช้ OBS แยก. PMP สอน WBS เป็น “tree ของ deliverable” ตรงๆ และเก็บ task ไว้ใน Work Package (เหมือนที่ CRM ก็พูด)

แต่ CISA CRM แยก OBS ออกมาเป็น tool ต่างหาก เพราะวงการ IS audit ต้องการ trace ว่า “system component ไหนของ solution ↔ task ไหนใน implementation” — ต้องการ 2 มุมมอง

ผลที่ตามมา:

• ถ้าทำงาน PM ทั่วไป → ใช้ WBS อย่างเดียว ก็พอ (PM ซีรีส์ของ blog EP.07 เน้นแบบนี้)
• ถ้าสอบ CISA → ต้องรู้ทั้ง OBS → WBS chain ตามที่ CRM เขียน

WBS — Work Breakdown Structure#

WBS คือการแบ่งโปรเจ็คออกเป็น deliverable เป็นชั้นๆ ตั้งแต่ระดับใหญ่ไปเล็ก

กับดักที่เห็นบ่อยที่สุด: WBS ≠ task list ที่ flat

WBS ต้อง deliverable-based แต่ละกล่องคือ “สิ่งที่จะส่งมอบ” ไม่ใช่ “งานที่คนต้องทำ” — task ละเอียดถูกซ่อนอยู่ใน Work Package ที่เป็น leaf node

ตัวอย่างที่ผิด:

• “ประชุม requirements 5 ครั้ง” ← นี่คือ task ไม่ใช่ deliverable
• “ทดสอบระบบ 3 สัปดาห์” ← เหมือนกัน task ไม่ใช่ deliverable

ตัวอย่างที่ถูก:

• “Requirements specification document v1.0” ← นี่คือ deliverable
• “UAT test results report” ← deliverable

หลักของ WBS:

• Deliverable-based ไม่ใช่ task-based
• Work Package (WP) ที่ระดับล่างสุดควรไม่ยาวเกิน 10 วันทำงาน ถ้านานกว่านั้น แบ่งย่อยลงไปอีก
• WP ควร เป็นอิสระ ส่งมอบแยกได้ ไม่ผูกกับ WP อื่นจนแก้ไม่ได้

Gantt Chart#

แผนภูมิแท่งตามเวลา แสดงว่า activity ไหนเริ่ม-จบเมื่อไหร่ ใครรับผิดชอบ

ดูง่าย เห็น dependency ระหว่าง activity ได้ แต่ไม่ได้บอก เส้นทางวิกฤต ของโปรเจ็ค

CPM — Critical Path Method#

ระบุ ลำดับ activity ที่ยาวที่สุด ของโปรเจ็ค activity ที่อยู่บน critical path ถ้าล่าช้า = โปรเจ็คทั้งโปรเจ็คล่าช้า

CPM ใช้ single time estimate ต่อ activity สมมติว่าเรารู้ duration แน่นอน

PERT — Program Evaluation and Review Technique#

ต่างจาก CPM ตรงที่ PERT ใช้ 3 estimates ต่อ activity:

• Optimistic (ทุกอย่างไปดี)
• Most Likely (สถานการณ์ปกติ)
• Pessimistic (ทุกอย่างพัง)

แล้วคำนวณ expected duration ด้วยสูตรที่ถ่วงน้ำหนัก most likely หนักกว่า ผลลัพธ์เป็น probability-based completion time ไม่ใช่จุดเดียว

กับดัก: CPM กับ PERT ใช้แทนกันได้ในข้อสอบ ไม่ได้ครับ CPM = single estimate (deterministic), PERT = 3 estimates (probabilistic)

EVA — Earned Value Analysis#

ตัวชี้วัดที่ตอบคำถามว่า “โปรเจ็คได้งานจริงเท่าไหร่ เทียบกับเงินที่จ่ายไปและเวลาที่ใช้”

ลองนึกถึงการสร้างบ้านครับ ถ้าจ่ายเงินไป 50% แต่บ้านสร้างเสร็จแค่ 30% มี gap ที่บอกว่าโปรเจ็คมีปัญหาแน่นอน

EVA วัด:

• Schedule variance — ช้ากว่าหรือเร็วกว่าแผน
• Cost variance — แพงกว่าหรือถูกกว่าแผน
• Estimate at completion — ถ้า trend ปัจจุบันรันต่อไปจะจบที่ราคาเท่าไหร่

มุม IS auditor: ถ้าโปรเจ็คไม่ทำ EVA หรือทำแต่ไม่ report ให้ Steering Committee auditor เจอ control gap ทันที เพราะไม่มีใครรู้ว่าโปรเจ็คจริงๆ อยู่ที่ไหนของแผน

5 วิธีประเมินต้นทุนโปรเจ็ค IS#

CRM ระบุ 5 วิธีหลัก แต่ละแบบมี trade-off ระหว่าง ความเร็ว กับ ความแม่น:

กับดักของ exam: “วิธีไหนแม่นที่สุด” — bottom-up. “วิธีไหนเร็วที่สุด” — analogy. ไม่ใช่ วิธีเดียวกัน

FPA — Function Point Analysis (เทคนิค sizing ที่ ISACA mention บ่อยที่สุด)#

ก่อน estimate cost ต้อง estimate size ของ software ก่อน — และ FPA (Function Point Analysis / การวิเคราะห์จุดฟังก์ชัน) คือเทคนิคที่ ISACA mention บ่อยที่สุด

หลักการ: FPA วัด size จาก functionality ที่ user เห็น ไม่ใช่จากจำนวนบรรทัด code — count 5 ตัวประกอบ:

1. Number of user inputs (ฟอร์มที่ user กรอก)
2. Number of user outputs (รายงานที่ระบบออก)
3. Number of user inquiries / enquiries (หน้า query ข้อมูล)
4. Number of files (logical data store ภายในระบบ)
5. Number of external interfaces (จุดเชื่อมต่อระบบอื่น)

แต่ละตัวถูก weight ตาม complexity (simple / average / complex) แล้วรวมเป็น function point count ที่ใช้เป็นฐานคำนวณ effort + cost

Concrete example ที่ผมชอบใช้คิด: ลองนึกว่ากำลังจะเขียน ระบบลงทะเบียนนักเรียนของโรงเรียน — FPA จะนับว่ามี:

• input form กี่หน้า (ลงทะเบียนใหม่, แก้ข้อมูล, ย้ายห้อง) → สมมติ 5 → average complexity weight 4 → 5 × 4 = 20 FP
• output report กี่ฉบับ (รายชื่อนักเรียน, ใบเสร็จค่าเทอม, รายงานเข้าเรียน) → สมมติ 4 → 4 × 5 = 20 FP
• inquiry screen กี่หน้า (ค้นหานักเรียน, ดูประวัติ) → 3 → 3 × 4 = 12 FP
• logical file (นักเรียน, ครู, ห้องเรียน, ค่าเทอม) → 4 → 4 × 10 = 40 FP
• external interface (ส่งข้อมูลให้กระทรวง, ดึงข้อมูลจากระบบบัตรประชาชน) → 2 → 2 × 7 = 14 FP

รวม ~106 FP — เอาตัวเลขนี้คูณกับ productivity rate (เช่น 8 hours/FP ของทีม) = ประเมิน effort ได้ก่อนเริ่มเขียน code บรรทัดแรก

มุมที่ต้องรู้สำหรับ exam: ISACA บอกว่า candidate ควรรู้จัก FPA concept แต่ ไม่ทดสอบการคำนวณ FPA จริง รู้แค่ว่ามันเป็น indirect measure ของ software size + ใช้กับ business application ได้ดี (แต่ไม่เหมาะกับ OS / process control / communication / embedded software — ที่ COCOMO เหมาะกว่า)

COCOMO — Boehm’s Constructive Cost Model#

COCOMO (Constructive Cost Model / โมเดลประเมินต้นทุนเชิงสร้างสรรค์) คือ parametric cost model ที่ Barry Boehm พัฒนาในปี 1981 — เป็นทางเลือกของ FPA สำหรับ software ที่ไม่ใช่ business app

Input หลัก ที่ COCOMO ใช้คำนวณ:

• SLOC (Source Lines of Code) ที่ประเมินไว้
• Cost drivers ของโปรเจ็ค (เช่น ความซับซ้อนของ product, ประสบการณ์ของทีม, ข้อจำกัด performance, ความเสถียรของ requirement)

COCOMO มี 3 variants ที่ละเอียดต่างกัน:

มุมที่ต้องรู้สำหรับ exam: จำคู่ FPA ↔ COCOMO ให้ได้

• FPA = sizing technique เหมาะกับ business app วัดจาก function ที่ user เห็น
• COCOMO = cost model เหมาะกับ OS / embedded / process control ใช้ SLOC + cost drivers

SLOC — Source Lines of Code (เทคนิคเก่าสุด)#

SLOC (Source Lines of Code / จำนวนบรรทัด source code) = วิธีเก่าที่สุดในการวัด software size — นับบรรทัด code โดยตรง มี 2 แบบ:

• Physical SLOC — นับทุกบรรทัดในไฟล์ รวม comment + บรรทัดว่าง
• Logical SLOC — นับเฉพาะ executable statement ตัด comment + บรรทัดว่างออก

ทำไมยังต้องรู้: เพราะ COCOMO ใช้ SLOC เป็น input หลัก และเพราะ exam ยังถาม

ข้อจำกัด ที่ทำให้ปัจจุบันแทบไม่ใช้ standalone:

• Language-dependent — เขียนสิ่งเดียวกัน Python อาจใช้ 10 บรรทัด แต่ Java 50 บรรทัด → เทียบข้าม language ไม่ได้
• Gamified ง่าย — developer ที่ถูกวัดด้วย SLOC อาจเขียน code ยาวเกินจำเป็นเพื่อให้ “ตัวเลขสวย”
• Abstraction level สูงขึ้น — low-code, GUI builder, AI code generation ทำให้ “บรรทัด” ไม่สะท้อน complexity จริง

กับดัก exam: “SLOC = direct measure ของ productivity ของ developer” — ผิด SLOC วัด output ปริมาณ ไม่ได้วัด value หรือ quality. ทีมที่เขียน 100 บรรทัด เพื่อแก้ bug ที่ทีมอื่นเขียน 1,000 บรรทัดทิ้งไว้ = productive กว่ามาก ไม่ใช่ productive น้อยกว่า

Timebox Management — บริหารงานเป็นกล่องเวลา#

หลักการ: กำหนด เวลาคงที่ + ทรัพยากรคงที่ สำหรับ deliverable หนึ่ง ถ้าทำไม่ทันใน timebox = ลด feature ไม่ใช่ขยายเวลา

ใช้บ่อยใน prototyping + RAD + Agile เพราะบังคับให้ทีม prioritize feature สำคัญก่อน

ข้อดี:

• บังคับให้ตัดสิน trade-off ตั้งแต่แรก ไม่ใช่ตอนใกล้ deadline
• ลด scope creep เพราะเพิ่ม feature ต้องตัด feature อื่นออก
• Forecast เวลาง่ายกว่า แต่ละ timebox มี deadline ชัด

ข้อระวัง:

• ทีมอาจ skip QA/test เพื่อ “ส่ง timebox ทัน” ต้องมี definition of done ที่รวม quality checks
• Feature ที่ถูก descope อาจไม่กลับมาได้ ต้อง track ใน backlog

มุม IS auditor: ในโปรเจ็คที่ใช้ timebox ขอดูว่าการตัด feature ผ่าน change control formal ไหม ไม่ใช่ developer ตัดเองโดยอ้าง “เพราะทำไม่ทัน”