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 — แยก 2 ตัวที่ confusing#

ก่อนเข้า WBS ขอแยกศัพท์ที่หลายคนสับสน:

• OBS (Object Breakdown Structure) — แตก ผลลัพธ์ของระบบ (object/component) ออกเป็นชั้น ๆ ตอบว่า “ระบบจะมีอะไรบ้าง”
• WBS (Work Breakdown Structure) — แตก งาน ที่จะทำเพื่อสร้าง object พวกนั้น ตอบว่า “ต้องทำอะไรบ้างเพื่อให้ได้ของ”

โปรเจ็คที่ดีมักทำ OBS ก่อน → ใช้ OBS เป็น input ของ WBS

WBS — Work Breakdown Structure#

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

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

WBS ต้อง deliverable-based แต่ละกล่องคือ “สิ่งที่จะส่งมอบ” ไม่ใช่ “งานที่คนต้องทำ”

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

• “ประชุม 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. ไม่ใช่ วิธีเดียวกัน

Function Point Analysis (FPA)#

ก่อน estimate cost ต้อง estimate size ของ software ก่อน และ FPA คือเทคนิคที่ ISACA mention บ่อยที่สุด

หลักการ: วัด size จาก functionality ที่ user เห็น count 5 ตัวประกอบ:

1. Number of user inputs
2. Number of user outputs
3. Number of user enquiries
4. Number of files
5. Number of external interfaces

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

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

SLOC (Source Lines of Code) = วิธีเก่าที่นับบรรทัด code ปัจจุบันแทบไม่ใช้แล้ว เพราะ language ต่างกัน + abstraction level สูงขึ้น (low-code, GUI builder)

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 ตัดเองโดยอ้าง “เพราะทำไม่ทัน”