5 คำถามสำคัญที่คนบริหารโครงการต้องตอบให้ได้
เพราะปัญหาของโครงการ อาจไม่ได้เกิดจากคนทำงานไม่เก่ง แต่เกิดจากความเข้าใจที่ไม่ตรงกัน
โดย KCT Academy | IT Project Management Fundamentals (IPM 101)
เคยไหมครับ…
โครงการเริ่มต้นด้วยความมั่นใจ ทุกฝ่ายประชุมร่วมกัน มีแผนงาน มีผู้รับผิดชอบ และมีกำหนดส่งมอบชัดเจน
แต่เมื่อเริ่มทำงานจริง ปัญหาก็ค่อย ๆ ปรากฏขึ้น
ลูกค้าบอกว่า “เรื่องนี้ต้องมีอยู่แล้วไม่ใช่หรือ”
ทีมงานตอบว่า “แต่ไม่ได้ระบุไว้ในขอบเขตงาน”
ผู้บริหารถามว่า “ทำไมเพิ่งมาบอกว่ามีปัญหา”
ส่วนผู้จัดการโครงการก็พยายามประสานงานทุกฝ่าย จนบางครั้งใช้เวลาไปกับการแก้ความเข้าใจผิด มากกว่าการบริหารงานให้เดินหน้า
น่าสนใจว่า ปัญหาเหล่านี้ไม่ได้เกิดจากการขาดความสามารถทางเทคนิคเสมอไป
แต่เกิดจากการที่ทุกคนกำลังทำงานอยู่ในโครงการเดียวกัน โดยมีความเข้าใจต่อโครงการนั้นแตกต่างกัน
นี่คือเหตุผลที่การบริหารโครงการระดับพื้นฐาน ไม่ควรเริ่มต้นด้วยการสอนเครื่องมือที่ซับซ้อน แต่ควรเริ่มจากการสร้างความเข้าใจร่วมกัน
โดยเฉพาะสองเรื่องที่พบปัญหาบ่อยที่สุด ได้แก่
Scope Management การบริหารขอบเขตงาน
Communication Management การบริหารการสื่อสาร
และทั้งสองเรื่องนี้สามารถเริ่มต้นได้ด้วยคำถามง่าย ๆ เพียง 5 ข้อ
1. WHAT: ตกลงต้องทำอะไร และไม่ทำอะไร
หลายโครงการไม่ได้มีปัญหาเพราะทีมงานทำงานไม่ครบ แต่มีปัญหาเพราะแต่ละฝ่ายเข้าใจคำว่า “งานที่ต้องทำ” ไม่เหมือนกัน
ตัวอย่างเช่น องค์กรต้องการพัฒนาระบบ Customer Portal เพื่อให้ลูกค้าตรวจสอบสถานะคำขอได้ด้วยตนเอง
ทีมพัฒนาเข้าใจว่าต้องสร้างหน้าจอแสดงสถานะ
ฝ่ายธุรกิจคาดหวังว่าระบบต้องแจ้งเตือนลูกค้าผ่าน LINE ด้วย
ส่วนผู้บริหารคาดหวังว่าระบบนี้จะช่วยลดจำนวนการโทรเข้า Call Center
ทั้งสามฝ่ายไม่ได้คิดผิด แต่กำลังพูดถึงคนละเรื่อง
การบริหารขอบเขตงานจึงต้องทำให้ชัดว่า งานใดอยู่ในขอบเขต งานใดไม่อยู่ในขอบเขต และสิ่งที่กำลังพัฒนาต้องตอบโจทย์อะไร
บทเรียนสำคัญ: สิ่งที่ไม่ได้ตกลงให้ชัดตั้งแต่ต้น มักกลายเป็นข้อขัดแย้งในภายหลัง
2. DONE: เสร็จแบบไหน จึงจะถือว่ายอมรับได้
คำว่า “เสร็จแล้ว” อาจมีความหมายแตกต่างกันระหว่างผู้พัฒนา ผู้ใช้งาน และผู้บริหาร
ทีม IT อาจบอกว่าเสร็จ เพราะพัฒนาระบบครบทุกฟังก์ชัน
ผู้ใช้งานอาจบอกว่ายังไม่เสร็จ เพราะขั้นตอนการใช้งานยุ่งยาก
ผู้บริหารอาจตั้งคำถามว่า แล้วระบบนี้ช่วยลดภาระงานได้จริงหรือไม่
สิ่งที่ผู้บริหารโครงการต้องทำ คือกำหนด Acceptance Criteria หรือเกณฑ์การยอมรับงานให้ชัดเจน
เช่น ระบบต้องแสดงสถานะได้ถูกต้อง ผู้ใช้งานสามารถทำรายการตามขั้นตอนที่กำหนด และระบบผ่านการทดสอบตามเงื่อนไขที่ตกลงกัน
อย่างไรก็ตาม การส่งมอบงานผ่านเกณฑ์ ไม่ได้หมายความว่าประโยชน์ทางธุรกิจจะเกิดขึ้นทันทีเสมอไป จึงต้องแยกการยอมรับผลงานออกจากการติดตามผลหลังใช้งานจริง
บทเรียนสำคัญ: อย่ารอให้งานเสร็จแล้วค่อยถามว่า แบบไหนจึงจะเรียกว่าเสร็จ
3. CHANGE: ถ้ามีการขอเปลี่ยน ต้องทำอย่างไร
การเปลี่ยนแปลงไม่ใช่สิ่งผิดปกติของโครงการ
โดยเฉพาะโครงการ IT ที่ความต้องการทางธุรกิจ เทคโนโลยี และข้อจำกัดต่าง ๆ อาจเปลี่ยนแปลงระหว่างดำเนินงาน
ปัญหาจึงไม่ใช่การมีคนขอเปลี่ยนงาน
แต่คือการเปลี่ยนงานโดยไม่มีใครประเมินผลกระทบ
สมมติว่าลูกค้าขอเพิ่มฟังก์ชันใหม่ และบอกว่า “เพิ่มนิดเดียวเอง”
คำถามที่ผู้จัดการโครงการควรถามไม่ใช่เพียงว่า “ทำได้ไหม”
แต่ต้องถามด้วยว่า
การเปลี่ยนแปลงนี้กระทบเวลาเท่าไร ต้องใช้งบประมาณเพิ่มหรือไม่ มีผลต่อระบบส่วนอื่นอย่างไร และใครมีอำนาจอนุมัติ
สิ่งสำคัญคือ ต้องแยกให้ได้ก่อนว่าเป็นความต้องการใหม่ งานที่ตกลงไว้แต่ยังทำไม่ครบ หรือข้อผิดพลาดที่ต้องแก้ไข เพราะแต่ละกรณีอาจมีวิธีจัดการและความรับผิดชอบแตกต่างกัน
บทเรียนสำคัญ: การบริหารการเปลี่ยนแปลง ไม่ใช่การปฏิเสธคำขอ แต่คือการทำให้ทุกฝ่ายเห็นผลกระทบก่อนตัดสินใจ
4. WHO: ใครรับผิดชอบ และใครตัดสินใจ
ประโยคที่ได้ยินบ่อยในโครงการคือ
“คิดว่าอีกฝ่ายจัดการแล้ว”
“เรื่องนี้ต้องรอผู้บริหาร”
“ไม่แน่ใจว่าใครมีอำนาจอนุมัติ”
ปัญหาเหล่านี้สะท้อนว่า โครงการอาจมีทีมงานครบ แต่ยังไม่มีความชัดเจนเรื่องบทบาทและอำนาจตัดสินใจ
ผู้บริหารโครงการจึงต้องแยกให้ได้ว่า ใครเป็นผู้ลงมือทำ ใครรับผิดชอบผลลัพธ์ ใครต้องให้ความเห็น และใครมีอำนาจอนุมัติ
ตัวอย่างเช่น การเปลี่ยนฟังก์ชันของระบบอาจต้องให้ Business Owner ยืนยันความจำเป็น ให้ทีม IT ประเมินผลกระทบ และให้ผู้มีอำนาจตามโครงสร้างโครงการอนุมัติ
Project Manager มีหน้าที่ทำให้การตัดสินใจเกิดขึ้นอย่างมีข้อมูล ไม่ได้หมายความว่าต้องเป็นผู้ตัดสินใจทุกเรื่องด้วยตนเอง
บทเรียนสำคัญ: การมีคนรับผิดชอบงาน ไม่ได้แปลว่ามีคนรับผิดชอบการตัดสินใจ
5. COMMUNICATE: ต้องบอกใคร เรื่องอะไร และเมื่อไร
หลายองค์กรเข้าใจว่าการสื่อสารที่ดีคือการประชุมบ่อย ส่งอีเมลจำนวนมาก หรือรายงานความคืบหน้าอย่างสม่ำเสมอ
แต่จำนวนครั้งของการสื่อสารไม่ได้รับประกันว่าทุกฝ่ายจะเข้าใจตรงกัน
ลองนึกถึงโครงการที่ทีมพัฒนาพบว่าระบบอาจส่งมอบไม่ทันกำหนด
หากทีมงานรู้ปัญหา แต่ไม่ได้แจ้ง Project Manager อย่างทันท่วงที ผู้บริหารก็อาจไม่ทราบว่าต้องตัดสินใจจัดสรรทรัพยากรเพิ่มเติม
การสื่อสารที่ดีจึงต้องตอบให้ได้ว่า
ใครจำเป็นต้องรู้ข้อมูลนี้ เขาต้องรู้อะไร ต้องรู้เมื่อไร และต้องดำเนินการหรือตัดสินใจเรื่องใดต่อ
โดยเฉพาะเมื่อเกิดปัญหาสำคัญ การสื่อสารต้องไม่หยุดอยู่แค่การรายงาน แต่ต้องนำไปสู่การแก้ไขและการตัดสินใจ
บทเรียนสำคัญ: การสื่อสารที่ดี ไม่ได้วัดจากจำนวนข้อความที่ส่ง แต่วัดจากความเข้าใจและการตัดสินใจที่เกิดขึ้น
จาก 5 คำถาม สู่การบริหารโครงการที่ทำได้จริง
หากพิจารณาให้ดี ทั้ง 5 คำถามมีความสัมพันธ์กันอย่างใกล้ชิด
WHAT ทำให้รู้ว่าต้องทำอะไร
DONE ทำให้รู้ว่าผลงานต้องเป็นอย่างไร
CHANGE ทำให้รับมือกับสิ่งที่เปลี่ยนไป
WHO ทำให้รู้ว่าใครต้องรับผิดชอบและตัดสินใจ
COMMUNICATE ทำให้ทุกฝ่ายได้รับข้อมูลที่จำเป็นในเวลาที่เหมาะสม
คำถามเหล่านี้ไม่ใช่สิ่งทดแทนกระบวนการบริหารโครงการทั้งหมด แต่เป็นจุดเริ่มต้นที่ช่วยให้ผู้เรียนระดับพื้นฐานเข้าใจหลักการสำคัญ และสามารถนำไปใช้กับงานจริงได้ทันที
เพราะในความเป็นจริง โครงการจำนวนไม่น้อยไม่ได้สะดุดเพราะขาดเทคโนโลยีหรือขาดคนเก่ง
แต่สะดุดเพราะขอบเขตไม่ชัด ข้อตกลงไม่ตรงกัน การเปลี่ยนแปลงไม่ได้รับการจัดการ และปัญหาไม่ได้ถูกสื่อสารไปยังผู้ที่ควรตัดสินใจ
บทสรุป: ทำเสร็จ ไม่ได้แปลว่า สำเร็จ
ลองนึกถึงโครงการพัฒนาระบบที่ส่งมอบตรงเวลา ใช้งบประมาณตามแผน และผ่านการตรวจรับเรียบร้อยแล้ว
แต่หลังเปิดใช้งาน กลับไม่มีใครอยากใช้ระบบ ลูกค้ายังคงต้องโทรศัพท์สอบถามเหมือนเดิม และพนักงานยังต้องทำงานซ้ำซ้อน
ในมุมของการส่งมอบ โครงการอาจถือว่าทำเสร็จแล้ว
แต่ในมุมของธุรกิจ ประโยชน์ที่ตั้งใจให้เกิดขึ้นอาจยังไม่เกิดขึ้นจริง
นี่คือความแตกต่างที่ผู้บริหารโครงการทุกคนควรเข้าใจ
เราไม่ได้บริหารโครงการเพียงเพื่อให้งานเสร็จ แต่เพื่อให้สิ่งที่ลงมือทำช่วยแก้ปัญหาและทำให้องค์กรดีขึ้นจริง
และก่อนเริ่มโครงการครั้งต่อไป ลองถามทีมงานด้วยคำถามง่าย ๆ ว่า
“พวกเรากำลังเข้าใจตรงกันจริง ๆ หรือเพียงแค่คิดว่าเข้าใจตรงกัน?”
เพราะบางครั้ง การใช้เวลาเพียงเล็กน้อยเพื่อสร้างความชัดเจนตั้งแต่ต้น อาจช่วยลดเวลา ความเสียหาย และความขัดแย้งที่ต้องตามแก้ไขไปตลอดทั้งโครงการ
