แผนงานและเส้นทางวิกฤต

9 + 9 + 8 + 36 = 62 วัน ซึ่งเป็นผลบวกที่คำนวณถูกแต่ใช้ไม่ได้ · เวลาสำรองที่ใช้ได้จริงของเส้นทางคือ 9 วัน ซึ่งเป็นเวลาสำรองของทั้งเส้นทางร่วมกัน ไม่ใช่ของแต่ละงาน · 62 ÷ 9 = 6.9 เท่า

เวลาสำรองของงานที่ต่อกันเป็นลูกโซ่เป็นของร่วม ไม่ใช่ของแต่ละงาน — ถ้างานแรกใช้เวลาสำรองไป 9 วัน งานที่เหลือทั้งเจ็ดงานจะเหลือศูนย์ทันที เพราะทุกงานเลื่อนตามกันไปหมด · การบวกเวลาสำรองรายงานแล้วรายงานเป็นยอดรวมทำให้แผนดูปลอดภัยกว่าความจริงเกือบเจ็ดเท่า ซึ่งเป็นความผิดพลาดที่พบบ่อยเพราะระบบวางแผนส่วนใหญ่แสดงเวลาสำรองรายงานให้ดูง่าย แล้วคนก็บวกเอง · ผลที่เกิดจริงคือเมื่องานฐานรากช้าไป 9 วันเพราะพบดินอ่อน ทีมงานคิดว่ายังเหลือสำรองอีก 53 วัน ทั้งที่ความจริงคือใช้หมดแล้วและทุกวันที่ช้าเพิ่มจากนี้จะเลื่อนวันส่งมอบทันที · ระบบจึงไม่แสดงยอดรวมเวลาสำรองของโครงการเลย แสดงเฉพาะเวลาสำรองของแต่ละเส้นทาง และเตือนเมื่อเหลือน้อยกว่า 5 วัน · โครงการขยายคลังสินค้าโซน D ปัจจุบันเลยกำหนดไป 68 วันแล้ว ซึ่งสอดคล้องกับการที่เวลาสำรองจริงมีเพียง 9 วัน

186 + 164 + 136 = 486 งาน ✓ · การปรับวันย้อนหลัง 142 + 118 + 96 = 356 ครั้ง = 73.3% ของงานทั้งสามโครงการ · เทียบกับอีก 15 โครงการที่งานเสร็จตรงวันพอดีเพียง 24.6%

งานเสร็จตรงวันพอดีทุกงานเป็นสัญญาณเตือน ไม่ใช่ผลงาน — ในโครงการที่บันทึกตามจริง งานจะเสร็จก่อนบ้างหลังบ้าง ซึ่งอีก 15 โครงการแสดงการกระจายแบบนั้น · ตัวเลขที่บอกสาเหตุคือการปรับวันกำหนดย้อนหลัง 356 ครั้ง คิดเป็น 73.3% ของงานทั้งสามโครงการ คือเมื่องานจะเสร็จช้า วันกำหนดถูกเลื่อนตามไปด้วยก่อนบันทึกผล · นี่ไม่ใช่การปลอมแปลงข้อมูล และมักเกิดจากความเข้าใจว่าการปรับแผนให้ตรงกับความจริงคือสิ่งที่ควรทำ ซึ่งถูกในแง่การวางแผน แต่ทำให้สถิติความตรงเวลาไม่มีความหมาย · ผลคือทั้งสามโครงการนี้จะไม่มีวันปรากฏในรายการโครงการล่าช้า ไม่ว่าจะช้าแค่ไหน · ระบบจึงเก็บวันกำหนดตั้งต้นแยกจากวันกำหนดปัจจุบันเสมอ และวัดความตรงเวลาจากวันตั้งต้น ส่วนวันกำหนดปัจจุบันใช้สำหรับการวางแผนงานถัดไปเท่านั้น · การปรับวันยังทำได้ตามปกติ แต่ต้องระบุเหตุผลและระบบจะบันทึกทั้งวันเดิมและวันใหม่ไว้

5 โครงการนี้มีงานบนเส้นทางวิกฤตรวม 264 งาน = 41.1% ของงานบนเส้นทางวิกฤตทั้งหมด 642 งาน · เวลาสำรองเฉลี่ยของทั้งระบบ 12.4 วันไม่ได้รวมโครงการที่ติดลบ ซึ่งเป็นเหตุผลที่ค่าเฉลี่ยดูดีกว่าความจริง

เวลาสำรองเฉลี่ย 12.4 วันที่แสดงเป็นตัวชี้วัดหลักคำนวณจากงานที่ไม่อยู่บนเส้นทางวิกฤตเท่านั้น — ซึ่งเป็นงานที่ตามนิยามแล้วมีเวลาสำรองอยู่แล้ว ค่าเฉลี่ยนี้จึงไม่มีทางต่ำและไม่บอกอะไรเลย · ตัวเลขที่ควรดูคือเวลาสำรองของเส้นทางวิกฤตแต่ละโครงการ ซึ่งสามโครงการติดลบและอีกสองโครงการอยู่ที่ศูนย์กับสองวัน · โครงการที่เวลาสำรองเป็นศูนย์เป็นสภาวะที่แผนบอกว่าทุกอย่างต้องเป็นไปตามที่คิดไว้ทุกงาน ซึ่งไม่เคยเกิดขึ้นจริงในโครงการใด · การตอบสนองที่มักเห็นคือการอัดงานให้ทำขนานกันมากขึ้นเพื่อดึงกำหนดกลับมา ซึ่งเพิ่มความเสี่ยงแทนที่จะลด เพราะงานที่ทำขนานกันต้องใช้คนพร้อมกัน ซึ่งเชื่อมตรงกับปัญหาการจัดสรรคนในหน้า 194 · ทางเลือกที่ตรงกว่าคือลดขอบเขตหรือเลื่อนวันส่งมอบอย่างเปิดเผย ซึ่งทั้งคู่เป็น Level E ที่ต้องผ่านคณะกรรมการโครงการ · ระบบไม่เสนอทางเลือกใดให้โดยอัตโนมัติ แต่คำนวณผลของแต่ละทางให้ครบเพื่อให้คนตัดสิน

246 + 178 + 124 + 62 + 32 = 642 งาน ✓ · 38.3 + 27.7 + 19.3 + 9.7 + 5.0 = 100.0% ✓ · 642 ÷ 4,286 = 15.0% ของงานย่อยทั้งหมด

งานจัดซื้อและรอของ 178 งานคิดเป็น 27.7% ของงานบนเส้นทางวิกฤต ซึ่งเป็นกลุ่มที่ควบคุมได้น้อยที่สุดแต่วางแผนล่วงหน้าได้มากที่สุด — เวลารอของนำเข้าเป็นสิ่งที่รู้ตั้งแต่ตอนออกใบสั่งซื้อ · โครงการระบบอัตโนมัติสายการผลิตที่ล่าช้า 112 วันมีสาเหตุหลักคืออุปกรณ์นำเข้ามาช้า ซึ่งเป็นงานกลุ่มนี้ และเป็นสิ่งที่หน้า 185 ในโมดูลโลจิสติกส์พบว่าเกิดจากการเริ่มเรื่องเอกสารช้าเช่นกัน · งานขออนุญาตหน่วยงานภายนอก 62 งานเป็นกลุ่มที่ควบคุมไม่ได้จริง ๆ และควรเผื่อเวลาไว้มากกว่าที่ประเมิน ปัจจุบันหลายโครงการเผื่อไว้ตามเวลาที่หน่วยงานประกาศ ซึ่งเป็นเวลาที่ดีที่สุดที่เป็นไปได้ ไม่ใช่เวลาปกติ · งานอบรมและส่งมอบเพียง 32 งานอยู่บนเส้นทางวิกฤต ซึ่งน้อยผิดปกติ มักเป็นเพราะงานกลุ่มนี้ถูกวางไว้ท้ายสุดโดยไม่ผูกกับงานอื่น ทำให้ดูเหมือนไม่วิกฤต แต่เป็นงานที่ตัดสินว่าผู้ใช้จะใช้ระบบเป็นหรือไม่ · สามโครงการที่ปิดไปแล้วปีนี้มีปัญหาการใช้งานหลังส่งมอบด้วยเหตุนี้

วันกำหนดตั้งต้นที่ใช้วัดความตรงเวลาแก้ไม่ได้โดยพลการ แม้แต่ผู้จัดการโครงการเอง — เพราะเป็นตัวเลขที่ใช้ประเมินโครงการและประเมินคน การให้คนที่ถูกประเมินแก้ตัวตั้งวัดเองทำให้การวัดไม่มีความหมาย · สามโครงการที่ทุกงานเสร็จตรงวันพอดีเกิดจากช่องโหว่ตรงนี้ ซึ่งปิดแล้วในระบบนี้ การปรับวันยังทำได้แต่วันเดิมจะถูกเก็บไว้และใช้เป็นตัวตั้งวัดต่อไป · การเลื่อนวันส่งมอบโครงการเป็นเรื่องที่ต้องผ่านคณะกรรมการเพราะกระทบสิ่งที่เคยอนุมัติไว้ เช่นเดียวกับการเปลี่ยนขอบเขตและงบประมาณ · AI คำนวณผลของการเลื่อนได้ทั้งต่อต้นทุน มูลค่าปัจจุบันสุทธิ และโครงการอื่นที่ใช้คนกลุ่มเดียวกัน แต่ไม่เสนอว่าควรเลื่อนหรือไม่ · การปรับวันงานย่อยในกรอบทำได้ แต่ระบบจะเตือนเมื่อการปรับสะสมเริ่มกินเวลาสำรองของเส้นทางวิกฤตจนเหลือน้อยกว่า 5 วัน เพราะจากจุดนั้นการปรับครั้งถัดไปจะกระทบวันส่งมอบทันที