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 ให้ฝัง into 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 ว่า “ล้มเหลว” ทั้งที่อาจจะสำเร็จจริง

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 ทันที เพราะไม่มีใครรู้ว่าโปรเจ็คจริงๆ อยู่ที่ไหนของแผน