เริ่มจาก Planned vs Actual แต่ต้องมองให้ลึกกว่าตัวเลขรวม

พื้นฐานของ รายงานความก้าวหน้างานก่อสร้าง คือการเปรียบเทียบสิ่งที่ควรเกิดขึ้นตามแผนกับสิ่งที่เกิดขึ้นจริง เช่น

Planned 72% → Actual 67% → Variance -5%

แต่หากหยุดดูเพียง Overall Progress ปัญหาบางส่วนอาจถูกซ่อนอยู่ในตัวเลขเฉลี่ย โครงการที่มีหลายอาคาร หลายชั้น หรือหลายยูนิต จึงควรสามารถแยกดู Progress ตามโครงสร้างของงานได้ เช่น อาคาร ชั้น Zone Unit ประเภทงาน หรือผู้รับเหมา

ตัวอย่างเช่น แม้ Overall Progress จะยังใกล้เคียงแผน แต่บางพื้นที่อาจล่าช้าอย่างต่อเนื่อง ขณะที่อีกพื้นที่ทำงานเร็วกว่ากำหนดจนตัวเลขเฉลี่ยทำให้ความผิดปกติดูไม่ชัด การดู Planned vs Actual ในระดับที่ละเอียดขึ้นจึงช่วยให้ PM รู้ว่า Variance ที่เห็นในภาพรวมกำลังเกิดขึ้นจากตรงไหน

เมื่อ Progress ต่ำกว่าแผน ต้องรู้ให้ได้ว่างานไหนกำลังดึงโครงการไว้

เมื่อพบว่า Actual Progress ต่ำกว่า Planned Progress คำถามถัดไปไม่ควรหยุดอยู่ที่ “ล่าช้ากี่เปอร์เซ็นต์” แต่ควรระบุให้ได้ว่า ความล่าช้านั้นมาจาก Activity หรือพื้นที่ใด

แทนที่จะรายงานเพียงว่า … งานล่าช้า 5% … ข้อมูลที่นำไปใช้ต่อได้ควรชี้ให้เห็นมากกว่านั้น เช่น งานติดตั้งระบบชั้น 8–10 ต่ำกว่าแผน และเป็นส่วนหลักที่ทำให้ Progress รวมลดลง

การแยก Delay ลงไปถึงระดับ Activity หรือพื้นที่ช่วยให้ PM จัดลำดับความสำคัญได้ดีขึ้น เพราะงานที่ล่าช้าไม่ได้มีผลต่อโครงการเท่ากันทั้งหมด บาง Activity สามารถขยับเวลาได้โดยไม่กระทบงานส่วนอื่น ขณะที่บางงานหากล่าช้าเพียงไม่กี่วัน อาจทำให้งานที่รอต่ออยู่ไม่สามารถเริ่มได้ตามแผน

รู้ว่างานล่าช้ายังไม่พอ ต้องรู้ว่า Delay เกิดจากอะไร

การเห็นว่างานไหนต่ำกว่าแผนช่วยให้ PM รู้ว่าต้องเข้าไปดูตรงไหน แต่ยังไม่เพียงพอสำหรับการตัดสินใจว่าจะจัดการอย่างไร เพราะ Delay ที่เกิดจากแรงงานไม่เพียงพอ ย่อมต้องใช้วิธีจัดการต่างจากการรอวัสดุ รอแบบ หรือรออนุมัติ 

สาเหตุที่พบได้ในโครงการอาจมาจากหลายด้าน ตัวอย่างที่เคยได้เห็น ก็เช่น จำนวนแรงงานไม่เพียงพอ วัสดุส่งเข้าหน้างานล่าช้า เครื่องจักรไม่พร้อม รอแบบหรือข้อมูลเพิ่มเติม รอการอนุมัติ งานก่อนหน้าไม่แล้วเสร็จ พบ Defect ที่ต้องแก้ไขก่อนทำงานต่อ มีการเปลี่ยนแปลงแบบ สภาพพื้นที่ไม่พร้อม ปัญหาการประสานงานระหว่างผู้รับเหมา เป็นต้น

หากโครงการบันทึกสาเหตุของ Delay ด้วยโครงสร้างเดียวกันอย่างต่อเนื่อง ข้อมูลเหล่านี้จะเริ่มมีประโยชน์มากกว่าการแก้ปัญหาเฉพาะหน้า 

เมื่อมองย้อนหลังหลายสัปดาห์หรือหลายโครงการ องค์กรจะเริ่มเห็น Pattern ได้ว่า ความล่าช้าเกิดจากปัจจัยใดบ่อยที่สุด และสามารถนำข้อมูลกลับไปใช้ปรับการวางแผนหรือวิธีทำงานในโครงการถัดไป

Delay บางงานไม่ได้กระทบแค่งานที่กำลังทำ

ความสำคัญของงานที่ล่าช้าไม่ได้วัดจากจำนวนวันที่ Delay เพียงอย่างเดียว แต่ต้องดูด้วยว่างานนั้นเชื่อมต่อกับอะไร ตัวอย่างเช่น

งานระบบชั้น 10 ล่าช้า
↓
งานปิดฝ้าเริ่มไม่ได้
↓
งานตกแต่งภายในเลื่อนตาม
↓
เสี่ยงกระทบ Milestone ส่งมอบพื้นที่

เมื่อเห็นความเชื่อมโยงในลักษณะนี้ ทีมจะไม่ได้มอง Delay เป็นเพียงสถานะสีแดงในรายงาน แต่สามารถประเมินได้ว่าปัญหาใดมีโอกาสส่งผลต่อเนื่องไปยัง Schedule ของโครงการ PM จึงแยกได้ชัดขึ้นว่า Issue ใดสามารถติดตามตามปกติ และ Issue ใดควรถูกยกระดับเพื่อเร่งการตัดสินใจ

รายงานที่ดีควรพาทีมไปถึง Action ไม่ใช่จบแค่การรับรู้ปัญหา

อีกปัญหาหนึ่งที่พบได้ในการประชุม Progress คือ ทุกคนรับรู้ว่ามีงานล่าช้า แต่เมื่อกลับมาประชุมรอบถัดไป ปัญหาเดิมยังคงถูกพูดถึงอีกครั้ง สิ่งที่ขาดในกรณีนี้ไม่จำเป็นต้องเป็นข้อมูลสถานะ แต่อาจเป็นความชัดเจนว่า ใครต้องทำอะไร และต้องเสร็จเมื่อไร

เมื่อพบปัญหา Progress Report จึงควรเชื่อมต่อไปถึง Action ที่ต้องดำเนินการ ผู้รับผิดชอบ Due Date สถานะปัจจุบัน รายการที่เกินกำหนด และผลหลังดำเนินการ

เพราะการรู้ว่ามีปัญหาเกิดขึ้นยังไม่ทำให้สถานการณ์เปลี่ยน จนกว่าข้อมูลนั้นจะถูกเปลี่ยนเป็น Action ที่มีเจ้าของและสามารถติดตามต่อได้