ลูกค้าปิดการตรวจสอบเว็บไซต์ด้วยคำขอสุดท้ายว่า: “ในขณะที่กำลังทำอยู่ ช่วยเพิ่มหน้าจองด้วยได้ไหม?” ฟังดูง่ายพอสมควร และทีมก็ตกลงโดยไม่ปรับปรุงขอบเขตโครงการ สองสัปดาห์ต่อมา หน้าจองนั้นจำเป็นต้องมีการบูรณาการระบบการชำระเงินและการตรวจสอบนโยบายความเป็นส่วนตัว และเอเจนซีต้องใช้เวลาเพิ่มอีกหนึ่งสัปดาห์กับงานที่ไม่ได้คาดการณ์ไว้ตั้งแต่แรก
นี่คือวิธีที่การขยายขอบเขตโครงการเกิดขึ้น โครงการจะขยายตัวขึ้นอย่างค่อยเป็นค่อยไปผ่านคำขอที่ดูเหมือนเล็กน้อย ในขณะที่งบประมาณ กำหนดเวลา และทรัพยากรเดิมยังคงไม่เปลี่ยนแปลง แม้แต่ผู้จัดการโครงการที่มีประสบการณ์ก็อาจไม่ทันสังเกตการเพิ่มส่วนนี้ เมื่อขอบเขตโครงการที่ตกลงกันไว้อยู่ในเอกสารหนึ่ง แต่การทำงานจริงกลับขยายตัวขึ้นในที่อื่น
เพื่อป้องกันปัญหานี้ คุณจำเป็นต้องมีวิธีการที่ชัดเจนในการกำหนดขอบเขตงานที่รวมอยู่ ประเมินคำขอใหม่ และรักษาให้โครงการสอดคล้องกับสิ่งที่ได้รับการอนุมัติแล้ว คู่มือนี้จะนำคุณไปทำความเข้าใจเกี่ยวกับสาเหตุของปัญหาการขยายขอบเขตงาน และเจ็ดขั้นตอนในการจัดการปัญหานี้ก่อนที่จะส่งผลกระทบต่อกำหนดเวลา งบประมาณ หรือทีมของคุณ
สรุปสั้นๆ
การขยายขอบเขตงานเกิดขึ้นเมื่องานขยายเกินขอบเขตที่ตกลงกันไว้ โดยไม่มีการปรับเปลี่ยนแผนโครงการให้สอดคล้องกัน สิ่งนี้อาจทำให้ค่าใช้จ่ายเพิ่มขึ้น ทรัพยากรถูกใช้จนเกินขีดจำกัด และส่งผลกระทบต่อกำหนดการส่งมอบ แม้ว่าจะไม่มีผลลัพธ์ใหม่ปรากฏในรายการงานก็ตาม
เพื่อควบคุมให้อยู่ภายใต้การควบคุม:
- กำหนดขอบเขตให้ชัดเจน: กำหนดว่าอะไรถูกรวมไว้ อะไรถูกยกเว้น และอะไรถือว่างานเสร็จสมบูรณ์
- ตัดสินใจอย่างมีข้อมูล: ประเมินว่าคำขอใหม่จะส่งผลกระทบต่อข้อผูกพันที่มีอยู่อย่างไร รวมถึงความพึ่งพาซึ่งกันและกัน ค่าใช้จ่าย และความสามารถในการดำเนินงานที่มีอยู่
- ติดตามความพยายามจริง: เปรียบเทียบงานที่ได้รับการอนุมัติกับงานที่กำลังดำเนินการและงานที่เสร็จสิ้นแล้ว รวมถึงเวลาที่ใช้ไปกับกิจกรรมที่ไม่ได้วางแผนไว้
จำไว้: แม้แต่คำขอที่คุณอาจปฏิเสธในท้ายที่สุด ก็อาจกินเวลาโครงการไปกับการหารือ การตรวจสอบความเป็นไปได้ และการประมาณการ ก่อนที่จะดำเนินการประเมินผลกระทบอย่างละเอียด ให้ตรวจสอบก่อนว่าคำขอนั้นสนับสนุนเป้าหมายโครงการที่ตกลงกันไว้หรือไม่ สำหรับการเปลี่ยนแปลงที่ซับซ้อน ให้จำกัดความพยายามในการประเมินขั้นต้น และขอการอนุมัติก่อนที่จะดำเนินการตรวจสอบอย่างลึกซึ้ง
การขยายขอบเขตโครงการคืออะไร?
การขยายขอบเขตงาน (scope creep) คือการขยายตัวที่ไม่ได้รับการควบคุมของงานที่ตกลงกันในโครงการ โดยไม่มีการปรับเปลี่ยนงบประมาณ กำหนดเวลา หรือทรัพยากรให้สอดคล้องกัน ตามข้อมูลจากสถาบันการจัดการโครงการ (PMI) การขยายขอบเขตงานนี้สามารถส่งผลกระทบทั้งต่องานที่ดำเนินการในโครงการและผลิตภัณฑ์สุดท้ายที่จะส่งมอบ
จุดสำคัญคือว่างานใหม่ดังกล่าวได้รับการตรวจสอบ อนุมัติ และบันทึกไว้แล้วหรือไม่ การเพิ่มผลลัพธ์งานอีกอย่างหนึ่งเมื่อโครงการดำเนินมาถึงครึ่งทางถือเป็นการเปลี่ยนแปลงขอบเขตโครงการ การปล่อยให้ทีมทำงานกับงานนั้นโดยไม่ประเมินความพยายามเพิ่มเติมหรือปรับแผนเดิม คือจุดเริ่มต้นของปัญหาขอบเขตโครงการที่ขยายตัว
เพื่อระบุการเพิ่มส่วนงานเหล่านี้ ทีมจำเป็นต้องมีจุดอ้างอิงขอบเขตงานที่ได้รับการตกลงร่วมกัน ซึ่งกำหนดงานที่ได้รับการอนุมัติ รวมถึงผลลัพธ์ที่ส่งมอบเกณฑ์การรับมอบ และส่วนที่ไม่รวมอยู่ในขอบเขตงาน ขอบเขตงานสามารถบันทึกขอบเขตเหล่านี้ได้ ส่วนโครงสร้างการแบ่งงาน (WBS) จะจัดระเบียบผลลัพธ์ที่ส่งมอบให้เป็นแพ็กเกจงานที่เล็กกว่า
การขยายขอบเขตโครงการ vs. การเปลี่ยนแปลงขอบเขตที่ได้รับการอนุมัติ
ทั้งสองกรณีอาจเริ่มต้นจากคำขอใหม่จากลูกค้าหรือข้อเสนอแนะภายในองค์กร สิ่งที่แยกทั้งสองกรณีนี้คือวิธีที่ทีมประเมินและจัดการกับงานที่เสนอมา
| หมวดหมู่ | การขยายขอบเขตโครงการ | การเปลี่ยนแปลงขอบเขตที่ได้รับการอนุมัติ |
|---|---|---|
| วิธีจัดการ | งานเริ่มขึ้นโดยไม่มีการตรวจสอบหรืออนุมัติอย่างเป็นทางการ | คำขอจะได้รับการประเมินและอนุมัติก่อนที่จะเริ่มทำงาน |
| ผลกระทบต่อทรัพยากร | ความพยายามเพิ่มเติมถูกดูดซับไปโดยไม่มีการปรับเปลี่ยนตามข้อตกลง | ประเมินผลกระทบต่อค่าใช้จ่าย ความสามารถ และกำหนดเวลา |
| ใครเป็นผู้อนุมัติ | ไม่มีคำตัดสินใจที่ชัดเจนหรือได้รับการอนุมัติ | ผู้รับผิดชอบโครงการ ลูกค้า หรือผู้สนับสนุนโครงการที่ได้รับการแต่งตั้ง |
| เส้นฐานขอบเขต | ขอบเขตงานที่ได้รับการอนุมัติและงานที่ดำเนินการจริงเริ่มไม่สอดคล้องกัน | ข้อมูลพื้นฐานและแผนโครงการได้รับการอัปเดต |
| ผลลัพธ์ | ค่าใช้จ่ายที่ไม่ได้วางแผนไว้ ความล่าช้า หรือปริมาณงานเพิ่มเติม | การเปลี่ยนแปลงที่ได้รับการตกลงกัน พร้อมด้วยความคาดหวังที่ชัดเจนและข้อแลกเปลี่ยน |
การขยายขอบเขตโครงการ vs. การเพิ่มคุณสมบัติเกินความจำเป็น
Gold plating เป็นรูปแบบหนึ่งของ scope creep ที่เกิดขึ้นเมื่อทีมเพิ่มการปรับปรุงเกินกว่าข้อกำหนดที่ตกลงกันไว้ โดยไม่ได้รับการร้องขอ นักออกแบบอาจเพิ่มแอนิเมชันที่ซับซ้อนลงในเว็บไซต์ หรือผู้พัฒนาอาจสร้างฟีเจอร์เพิ่มเติม เพราะพวกเขาเชื่อว่าสิ่งนั้นจะช่วยปรับปรุงผลิตภัณฑ์
แม้ว่าการเพิ่มส่วนงานเหล่านี้อาจเกิดจากความตั้งใจที่ดี แต่ยังคงใช้เวลาและทรัพยากรที่ยังไม่ได้รับการอนุมัติ นอกจากนี้ ยังอาจก่อให้เกิดความต้องการใหม่ในการทดสอบ การบำรุงรักษา หรือการตรวจสอบ
หลักการควบคุมขอบเขตงานที่ใช้ในกรณีนี้ยังคงเหมือนเดิม ก่อนที่จะเพิ่มงานเพิ่มเติม ให้ตรวจสอบว่างานดังกล่าวอยู่ในขอบเขตของข้อกำหนดที่ได้รับการอนุมัติและเกณฑ์การรับมอบหรือไม่ หากไม่อยู่ในขอบเขตดังกล่าว ทีมควรเสนอให้พิจารณาเป็นการเปลี่ยนแปลง และต้องได้รับการอนุมัติก่อนที่จะดำเนินการต่อ
การขยายขอบเขตโครงการนั้นดีหรือร้าย?
การขยายขอบเขตโครงการมักก่อให้เกิดปัญหา เนื่องจากมันนำงานที่โครงการไม่ได้คาดการณ์ไว้เข้ามา อย่างไรก็ตาม คำขอที่อยู่เบื้องหลังการขยายขอบเขตนี้อาจมีประโยชน์ได้ เช่น ฟีเจอร์ใหม่อาจช่วยปรับปรุงผลิตภัณฑ์ หรือผลลัพธ์เพิ่มเติมอาจช่วยให้ลูกค้าบรรลุเป้าหมายทางธุรกิจ ปัญหาจะเกิดขึ้นเมื่อทีมรับการเพิ่มส่วนนี้โดยไม่ตรวจสอบว่ามันจะส่งผลต่องานที่กำลังดำเนินการอยู่อย่างไร
สำหรับเอเจนซี ผลกระทบมักปรากฏในอัตรากำไร สมมติว่าโครงการแบบค่าบริการคงที่ถูกประมาณการไว้ที่ 100 ชั่วโมงแรงงาน แต่สุดท้ายใช้ไป 115 ชั่วโมง ชั่วโมงเพิ่มเติม 15 ชั่วโมงนั้นไม่ถูกเรียกเก็บเงิน ทำให้ต้นทุนแรงงานเพิ่มขึ้น 15% หากต้นทุนต่อชั่วโมงยังคงไม่เปลี่ยนแปลง สำหรับทีมภายในองค์กร ต้นทุนอาจไม่ชัดเจนนัก เนื่องจากพนักงานต้องแบ่งเวลาให้กับการทำงานหลายอย่างที่มีลำดับความสำคัญแข่งขันกัน และโครงการอื่น ๆ อาจล่าช้ากว่ากำหนด
เมื่อจัดการผ่านกระบวนการขอเปลี่ยนแปลงอย่างเป็นทางการ งานเพิ่มเติมสามารถกลายเป็นโอกาสที่มีค่าได้ ลูกค้าสามารถอนุมัติค่าบริการที่สูงขึ้น ตกลงกับกำหนดเวลาใหม่ หรือเปลี่ยนผลลัพธ์ที่ส่งมอบเดิมเป็นผลลัพธ์ใหม่ได้ หลังจากนั้น ทีมงานสามารถปรับตัวรับมือกับการเปลี่ยนแปลงได้ โดยมีความคาดหวังที่ชัดเจนเกี่ยวกับสิ่งที่จำเป็นในการส่งมอบงาน
อะไรเป็นสาเหตุของ Scope Creep? 5 สาเหตุที่พบบ่อย
การขยายขอบเขตโครงการอาจเริ่มขึ้นตั้งแต่ขั้นตอนการวางแผนโครงการ หรือเกิดขึ้นเมื่องานดำเนินไป นี่คือห้าสาเหตุที่พบบ่อย และวิธีที่แต่ละสาเหตุอาจส่งผลต่อขอบเขตโครงการที่ตกลงกันไว้
1. ข้อกำหนดโครงการที่ไม่ชัดเจน
เอกสารกำหนดขอบเขตที่ระบุว่าจะ “ออกแบบเว็บไซต์ใหม่” ไว้เปิดช่องให้ตีความได้หลายทาง มันครอบคลุม 2 หน้าหรือ 10 หน้า? ใครจะเป็นผู้จัดเตรียมเนื้อหา และมีการแก้ไขกี่รอบ?
เมื่อข้อกำหนดของโครงการไม่ระบุรายละเอียดเหล่านี้ให้ชัดเจน คุณและลูกค้าอาจเริ่มทำงานด้วยความคาดหวังที่แตกต่างกัน สิ่งที่ฝ่ายหนึ่งมองว่าเป็นคำขอเพิ่มเติม ฝ่ายอีกฝ่ายอาจคิดว่ามันถูกรวมไว้ตั้งแต่ต้น
2. คำขอเล็กๆ ที่ข้ามขั้นตอนการอนุมัติ
ขนาดแบนเนอร์เพิ่มเติม รอบการแก้ไขอีกครั้ง หรือการเปลี่ยนแปลงรูปแบบเล็กน้อย อาจดูไม่มีอันตรายเมื่อถูกกล่าวถึงในระหว่างการประชุม เนื่องจากแต่ละคำขอดูเหมือนเป็นเรื่องเล็กน้อย จึงง่ายที่จะตกลงและดำเนินการต่อโดยไม่บันทึกความพยายามเพิ่มเติมนั้น
เมื่อคำขอเหล่านี้สะสมขึ้น คุณจะต้องจัดการงานที่มากกว่าที่วางแผนไว้เดิม โดยไม่มีบันทึกที่ชัดเจนว่าเวลาที่เพิ่มเข้ามามีเท่าใด หรือใครเป็นผู้อนุมัติ
3. การเปลี่ยนแปลงในลำดับความสำคัญของผู้มีส่วนได้ส่วนเสีย
ผู้มีส่วนได้ส่วนเสียใหม่สามารถนำลำดับความสำคัญที่ขัดแย้งกันเข้ามาในช่วงกลางโครงการได้ ตัวอย่างเช่น ผู้อำนวยการฝ่ายการตลาดที่เพิ่งได้รับการแต่งตั้งต้องการปรับทิศทางแคมเปญใหม่เพื่อมุ่งสู่กลุ่มลูกค้าองค์กร ในขณะที่ผู้สนับสนุนโครงการเดิมยังคงคาดหวังว่าจะได้รับทรัพยากรที่ได้รับการอนุมัติตั้งแต่ช่วงเริ่มต้นโครงการ
หากไม่มีอำนาจการตัดสินใจที่ชัดเจน คุณอาจต้องเผชิญกับความคาดหวังที่ขัดแย้งกัน แผนผังผู้มีส่วนได้ส่วนเสียในโครงการจะช่วยให้ชัดเจนว่าความคิดเห็นของใครมีอิทธิพลต่องาน และใครมีสิทธิ์ตัดสินใจขั้นสุดท้ายเมื่อลำดับความสำคัญเปลี่ยนแปลง
4. การปรับปรุงที่ยังไม่ได้รับการอนุมัติจากทีม
คุณสามารถปรับปรุงผลงานที่ส่งมอบได้ต่อไปแม้หลังจากที่มันได้ตรงตามข้อกำหนดที่ตกลงกันแล้ว ซึ่งมักเกิดขึ้นเมื่อการตรวจสอบภายในไม่มีจุดหยุดที่ชัดเจน และทุกความคิดใหม่หรือการปรับปรุงจะกลายเป็นงานใหม่ที่ต้องทำให้เสร็จก่อนการส่งมอบ
เมื่อเวลาผ่านไป การปรับปรุงและทดลองเพิ่มเติมเหล่านี้จะกินเวลาที่จัดสรรไว้สำหรับงานที่ได้รับการอนุมัติแล้ว โครงการยังคงขยายตัวต่อไป แม้ว่าลูกค้าจะไม่ได้ขอเพิ่มงานใหม่ใดๆ เลย
5. การติดตามขอบเขตงานที่ไม่ดีระหว่างการดำเนินการ
เอกสารกำหนดขอบเขตที่ละเอียดอาจกลายเป็นข้อมูลล้าสมัยได้ หากคุณหยุดตรวจสอบให้สอดคล้องกับงานที่กำลังดำเนินการอยู่ ตัวอย่างเช่น การเพิ่มการบูรณาการใหม่ลงในแบ็กโลกการพัฒนาหลังการส่งมอบงานทางเทคนิค และคุณกำหนดเวลาดำเนินการโดยไม่ตรวจสอบว่างานดังกล่าวอยู่ในขอบเขตที่ได้รับการอนุมัติแล้วหรือไม่
หากไม่มีการเปรียบเทียบอย่างสม่ำเสมอระหว่างผลลัพธ์ที่วางแผนไว้กับงานที่กำลังดำเนินการ งานเพิ่มเติมเหล่านี้จะค่อยๆ แทรกซึมเข้าไปในโครงการ ความไม่สอดคล้องกันนี้มักปรากฏให้เห็นได้ชัดเจนก็ต่อเมื่อตรวจสอบงบประมาณที่เหลืออยู่ หรือเมื่อตระหนักว่ากำหนดการส่งมอบได้ล่าช้าไปแล้ว
ข้อมูลสั้นๆ: แม้จะมีวิจารณญาณทางธุรกิจที่แข็งแกร่ง ก็ไม่สามารถรับประกันได้ว่าโครงการจะอยู่ภายในขอบเขตที่ตกลงกันไว้ได้ ในรายงานPulse of the Profession 2025 ของ PMI ผู้เชี่ยวชาญที่มีความเข้าใจทางธุรกิจสูงรายงานว่ามีความสอดคล้องกับงบประมาณ (73% เทียบกับ 68%) และกำหนดเวลา (63% เทียบกับ 59%) ที่ดีกว่าเพื่อนร่วมวิชาชีพ อย่างไรก็ตาม รายงานดังกล่าวไม่พบความแตกต่างที่มีนัยสำคัญทางสถิติในเรื่องขอบเขตโครงการที่ขยายตัวระหว่างทั้งสองกลุ่ม
แม้ว่าการวิจัยนี้ไม่ได้อธิบายว่าทำไมสิ่งนี้จึงเกิดขึ้น แต่มันชี้ให้เห็นถึงข้อจำกัดของการพึ่งพาความเชี่ยวชาญของบุคคลเพียงอย่างเดียว การกำหนดกฎเกณฑ์ที่ชัดเจนสำหรับการตรวจสอบคำขอ การอนุมัติงานเพิ่มเติม และการอัปเดตข้อผูกพันของโครงการ จะช่วยให้คุณมีวิธีการจัดการการเปลี่ยนแปลงที่สม่ำเสมอมากขึ้น
วิธีป้องกันและจัดการกับการขยายขอบเขตโครงการในปี 2026: 7 ขั้นตอน
เพื่อป้องกันการขยายขอบเขตโครงการ ให้ตกลงกันให้ชัดเจนว่าโครงการจะส่งมอบผลลัพธ์อะไร และจะจัดการกับคำขอใหม่ ๆ อย่างไร ขั้นตอนทั้งเจ็ดนี้จะช่วยคุณจัดการกับการเปลี่ยนแปลงได้ ไม่ว่าคุณจะติดตามงานผ่านสเปรดชีต เอกสารที่ใช้ร่วมกัน หรือเครื่องมือจัดการโครงการ
ขั้นตอนที่ 1: กำหนดสิ่งที่รวมอยู่และสิ่งที่ไม่รวมอยู่ในโครงการ
เขียนลงผลลัพธ์ที่ตกลงกันไว้ ข้อกำหนดของผลลัพธ์เหล่านั้น และเกณฑ์ที่คุณจะใช้เพื่อรับงาน กำหนดขอบเขตที่ชัดเจนสำหรับการแก้ไขและงานเพิ่มเติม
นอกจากนี้ ให้ระบุให้ชัดเจนว่าสิ่งใดอยู่นอกขอบเขตงาน สำหรับการออกแบบใหม่เว็บไซต์ 12 หน้า ให้ชี้แจงให้ชัดเจนว่าข้อตกลงนั้นรวมถึงการเขียนเนื้อหา การถ่ายภาพ การบูรณาการกับระบบของฝ่ายที่สาม และหน้าเพิ่มเติมหรือไม่ เมื่อมีใครขอเพิ่มงาน คุณก็จะมีข้อมูลอ้างอิงที่ชัดเจน
สำหรับโครงการของลูกค้า ให้ตรวจสอบรายละเอียดเหล่านี้ในช่วงขั้นตอนการรับลูกค้าเข้าโครงการและขอความตกลงเป็นลายลักษณ์อักษรก่อนเริ่มงาน ส่วนสำหรับโครงการภายในองค์กร ให้เขียนคำชี้แจงขอบเขตงานอย่างละเอียด และเชื่อมโยงกับเอกสารกำหนดวัตถุประสงค์โครงการ
คู่มือนี้จะแสดงวิธีเปลี่ยนคำอธิบายโครงการที่กว้างขวางให้เป็นข้อกำหนดที่ชัดเจนและสามารถทดสอบได้:
ขั้นตอนที่ 2: แบ่งขอบเขตงานที่ได้รับการอนุมัติออกเป็นงานที่จัดการได้
สร้างโครงสร้างการแบ่งงาน (WBS) เพื่อแบ่งผลลัพธ์ที่ตกลงกันไว้เป็นแพ็กเกจงานที่เล็กกว่าแม่แบบโครงสร้างการแบ่งงานสามารถช่วยคุณวางแผนงาน ประเมินปริมาณงาน และกำหนดผู้รับผิดชอบ
จากนั้น ให้เชื่อมโยงแต่ละงานในโครงการกับผลลัพธ์ที่ส่งมอบหรือแพ็กเกจงาน ในสเปรดชีต ให้เพิ่มคอลัมน์ “ผลลัพธ์ที่ส่งมอบ” เพื่อแสดงว่าแต่ละงานสนับสนุนขอบเขตงานที่ได้รับการอนุมัติอย่างไร ในเครื่องมือบริหารจัดการโครงการ ให้ใช้ “งานหลัก” หรือ “ฟิลด์ที่กำหนดเอง” เพื่อสร้างความเชื่อมโยงเดียวกัน
รวมงานต่างๆ เช่น การทดสอบและการประสานงานโครงการ ลงในแผนการแบ่งงานของคุณ ให้ผู้มีส่วนได้ส่วนเสียที่เกี่ยวข้องตรวจสอบและอนุมัติกรอบงานพื้นฐานทั้งหมด ใช้กรอบงานพื้นฐานนี้เพื่อตรวจสอบว่างานใหม่เหล่านั้นควรรวมอยู่ในโครงการหรือไม่
ขั้นตอนที่ 3: กำหนดความรับผิดชอบที่ชัดเจนในการตัดสินใจเกี่ยวกับขอบเขตงาน
ก่อนเริ่มงาน ให้กำหนดว่าใครจะเป็นผู้ตรวจสอบคำขอเปลี่ยนแปลง และใครมีสิทธิ์อนุมัติคำขอเหล่านั้น ตัวอย่างเช่น ผู้จัดการโครงการอาจประเมินคำขอแต่ละข้อ ในขณะที่ลูกค้าหรือผู้สนับสนุนโครงการจะอนุมัติการเปลี่ยนแปลงเกี่ยวกับค่าใช้จ่าย ผลลัพธ์ที่ส่งมอบ หรือกำหนดเวลา
หากมีหลายแผนกร่วมรับผิดชอบงาน ให้ใช้แมทริกซ์ RACIเพื่อกำหนดว่าใครเป็นผู้ดำเนินการงาน ใครเป็นผู้รับผิดชอบผลลัพธ์ ใครเป็นผู้ให้ข้อมูล และใครที่จำเป็นต้องรับข้อมูลอัปเดต
เขียนบทบาทเหล่านี้ลงและแบ่งปันให้ทุกคนที่เกี่ยวข้องทราบ การกำหนดความรับผิดชอบที่ชัดเจนจะช่วยป้องกันการอนุมัติที่ขัดแย้งกัน และแสดงให้ผู้มีส่วนได้ส่วนเสียทราบว่าควรส่งคำขอใหม่ไปที่ใด
ขั้นตอนที่ 4: บันทึกคำขอใหม่ไว้ในที่เดียว
เลือกสถานที่เดียวเพื่อบันทึกการเปลี่ยนแปลงที่เสนอ เช่น แบบฟอร์มขอเปลี่ยนแปลง บันทึกที่ใช้ร่วมกัน หรือรายชื่อโครงการ โดยแต่ละคำขอควรอธิบาย:
- สิ่งที่ผู้ขอต้องการเพิ่มหรือเปลี่ยนแปลง
- เหตุผลที่พวกเขาต้องการการเปลี่ยนแปลง
- ผู้ขอ
- ผลลัพธ์ที่ได้รับผลกระทบ
เมื่อมีใครนั้นเสนอคำขอระหว่างการโทรหรือการสนทนาแบบไม่เป็นทางการ ลองตอบด้วยวิธีนี้: “ผมจะบันทึกคำขอนี้ไว้ และตรวจสอบว่ามันจะส่งผลต่อกำหนดเวลาและงบประมาณอย่างไร ก่อนที่เราจะตกลงรับงานเพิ่มเติม”
วิธีนี้ช่วยบันทึกคำขอและให้เวลาคุณประเมินก่อนที่จะตัดสินใจใช้แบบฟอร์มคำขอเปลี่ยนแปลงมาตรฐานเพื่อเก็บข้อมูลรายละเอียดที่เหมือนกันทุกครั้ง
ปรับกระบวนการให้สอดคล้องกับการเปลี่ยนแปลง หากการแก้ไขอยู่ภายในข้อกำหนดที่ตกลงกันไว้ ให้จัดการมันเป็นส่วนหนึ่งของขอบเขตงานที่มีอยู่
ขั้นตอนที่ 5: ประเมินผลกระทบทั้งหมดก่อนอนุมัติการเปลี่ยนแปลง
ก่อนที่จะรับการเปลี่ยนแปลง ให้ประเมินปริมาณงานเพิ่มเติมที่จะเกิดขึ้น และตรวจสอบว่ามันจะส่งผลกระทบต่องบประมาณ ความสามารถของทีม ความสัมพันธ์ระหว่างงานต่าง ๆ และกำหนดการส่งมอบอย่างไร
อย่ามองเพียงแค่งานที่ระบุในคำขอเท่านั้น ฟีเจอร์ใหม่ของเว็บไซต์อาจใช้เวลาเพียงไม่กี่ชั่วโมงในการพัฒนา แต่ทีมอาจต้องปรับแก้การออกแบบ ดำเนินการทดสอบเพิ่มเติม อัปเดตเอกสาร และขอความเห็นชอบจากลูกค้าอีกครั้ง
เพื่อระบุค่าใช้จ่ายเพิ่มเติมเหล่านี้ ให้ถามว่า:
- งานหรือผลลัพธ์ที่ส่งมอบที่มีอยู่ใดบ้างที่จำเป็นต้องปรับเปลี่ยน?
- คำขอนี้จะก่อให้เกิดความพึ่งพา ความต้องการในการทดสอบ หรือการอนุมัติจากฝ่ายที่สามหรือไม่?
- ทีมสามารถจัดงานให้เข้ากับตารางเวลาปัจจุบันได้หรือไม่ และยังคงสามารถปฏิบัติตามข้อผูกพันอื่น ๆ ได้หรือไม่?
- หากคุณกำลังปรับเปลี่ยนผลลัพธ์ที่ส่งมอบ งานใหม่ดังกล่าวมีระดับความพยายาม ความเสี่ยง และเวลาในการตรวจสอบที่คล้ายกันหรือไม่?
แบ่งปันผลการประเมินของคุณกับผู้ที่มีอำนาจอนุมัติการเปลี่ยนแปลง และให้ตัวเลือกที่ชัดเจนแก่พวกเขา:
- อนุมัติงานเพิ่มเติมและปรับงบประมาณ กำหนดเวลา หรือจำนวนบุคลากร
- ย้ายคำขอไปยังขั้นตอนถัดไป พร้อมด้วยแผนการส่งมอบเฉพาะสำหรับคำขอนั้น
- เปลี่ยนผลลัพธ์ที่ส่งมอบที่มีอยู่ หากผลกระทบโดยรวมอยู่ในระดับที่ยอมรับได้
- ปฏิเสธหรือเลื่อนการขอหากมันไม่สอดคล้องกับลำดับความสำคัญของโครงการ
บันทึกผลการประเมินและตัดสินใจขั้นสุดท้ายเป็นลายลักษณ์อักษรการสื่อสารที่ชัดเจนกับผู้มีส่วนได้ส่วนเสียจะช่วยให้ทุกคนเข้าใจถึงการเปลี่ยนแปลงที่ได้รับการอนุมัติและผลกระทบของมันต่องานที่เหลือ
ขั้นตอนที่ 6: อัปเดตฐานข้อมูลขอบเขตโครงการหลังจากได้รับการอนุมัติ
เมื่อผู้ตัดสินใจอนุมัติการเปลี่ยนแปลงแล้ว ให้อัปเดตเอกสารโครงการก่อนที่จะเริ่มงานเพิ่มเติม ปรับปรุงคำชี้แจงขอบเขต โครงสร้างงาน (WBS) รายการงาน งบประมาณ และกำหนดการ ในทุกส่วนที่การเปลี่ยนแปลงมีผลกระทบ
ตัวอย่างเช่น ผลลัพธ์ใหม่ที่สร้างขึ้นอาจจำเป็นต้องมีแพ็กเกจงานและงานย่อยเป็นของตัวเอง กำหนดผู้รับผิดชอบ กำหนดเกณฑ์การรับมอบ และพิจารณาความสัมพันธ์ที่พึ่งพาใหม่
เก็บรักษาข้อตกลงเดิมและบันทึกการแก้ไขแต่ละครั้งที่ได้รับการอนุมัติไว้ สิ่งนี้ช่วยให้คุณติดตามการเปลี่ยนแปลงได้ และช่วยให้ผู้มีส่วนได้ส่วนเสียสามารถตรวจสอบข้อกำหนดปัจจุบันได้
ขั้นตอนที่ 7: ตรวจสอบขอบเขตโครงการอย่างสม่ำเสมอ
ทุกสัปดาห์ ให้เปรียบเทียบขอบเขตงานที่ได้รับการอนุมัติกับงานที่ทีมของคุณกำลังดำเนินการ ตรวจสอบรายชื่องาน บันทึกคำขอเปลี่ยนแปลง และความคืบหน้าเทียบกับผลลัพธ์ที่วางแผนไว้ นอกจากนี้ ให้เปรียบเทียบจำนวนชั่วโมงหรือค่าใช้จ่ายที่เกิดขึ้นจริงกับประมาณการของคุณด้วย
ตรวจสอบงานที่เสร็จสิ้นเมื่อเร็วๆ นี้ ชั่วโมงที่บันทึกไว้ รวมถึงงานที่ยังค้างอยู่ สมาชิกในทีมอาจเริ่มและเสร็จสิ้นคำขอที่ยังไม่ได้รับการอนุมัติระหว่างการตรวจสอบรายสัปดาห์ งานดังกล่าวจะไม่ปรากฏในรายชื่องานที่กำลังดำเนินการอีกต่อไป แม้ว่าจะใช้เวลาของโครงการไปแล้วก็ตาม
ถัดไป ให้ตรวจสอบงานที่ไม่เกี่ยวข้องกับผลลัพธ์ที่ได้รับการอนุมัติ งานที่เริ่มทำก่อนการอนุมัติ และงานที่ใช้ความพยายามมากกว่าที่วางแผนไว้ ตรวจสอบสาเหตุก่อนที่จะถือว่าสิ่งเหล่านี้เป็น Scope Creep การเกินขอบเขตอาจสะท้อนถึงการประมาณการที่ไม่แม่นยำ ความซับซ้อนที่ไม่คาดคิด หรือการทำงานซ้ำ
สำหรับเอเจนซีซอฟต์แวร์บันทึกเวลาทำงานของเอเจนซีสามารถช่วยติดตามชั่วโมงที่คิดค่าบริการและชั่วโมงที่ไม่คิดค่าบริการ รวมถึงแจ้งเตือนความพยายามเพิ่มเติมตั้งแต่เนิ่นๆ กำหนดเกณฑ์เพื่อตรวจสอบอย่างละเอียดยิ่งขึ้น โดยพิจารณาจากงบประมาณและระดับความล่าช้าที่โครงการสามารถรับมือได้
บันทึกข้อมูลสั้นๆ ของแต่ละปัญหา สาเหตุ และวิธีที่คุณแก้ไขมัน ใช้รูปแบบที่เกิดขึ้นซ้ำๆ เพื่อระบุจุดที่กระบวนการจัดการขอบเขตโครงการของคุณจำเป็นต้องปรับปรุง
ตัวอย่างการขยายขอบเขตโครงการในโครงการต่าง ๆ
การขยายขอบเขตโครงการสามารถส่งผลกระทบต่อทุกด้าน ตั้งแต่ผลลัพธ์ที่ส่งมอบให้ลูกค้าไปจนถึงการนำระบบไปใช้ภายในองค์กร ตัวอย่างต่อไปนี้แสดงให้เห็นว่าโครงการประเภทต่าง ๆ สามารถขยายเกินขอบเขตเดิมได้อย่างไร และคุณสามารถทำอย่างไรเพื่อป้องกันปัญหาเดียวกัน
1. โครงการของหน่วยงาน: งานเพิ่มเติมที่เกินกว่าผลลัพธ์ที่ตกลงกันไว้
เอเจนซีหนึ่งลงนามสัญญาเพื่อปรับปรุงภาพลักษณ์ทางภาพของลูกค้า ซึ่งรวมถึงโลโก้ใหม่ คู่มือแบรนด์ และรอบการแก้ไขสองครั้ง เมื่อโครงการดำเนินไปครึ่งทาง ลูกค้าขอเพิ่มเทมเพลตสำหรับโซเชียลมีเดียและชุดสไลด์นำเสนอเป็นส่วนหนึ่งของแพ็กเกจการสร้างแบรนด์
เอเจนซีตกลงที่จะรวมสินทรัพย์เหล่านั้นเข้าไปโดยไม่จำเป็นต้องทบทวนสัญญาใหม่ อย่างไรก็ตาม สินทรัพย์เพิ่มเติมเหล่านั้นต้องการกระบวนการออกแบบ การให้ข้อเสนอแนะ และการอนุมัติเป็นของตัวเอง ซึ่งทำให้ต้องใช้เวลาหลายชั่วโมงจากโครงการของลูกค้าอื่น ๆ
วิธีจัดการ: กำหนดสินทรัพย์เพิ่มเติมให้เป็นผลลัพธ์ที่ส่งมอบแยกต่างหาก และประมาณการค่าใช้จ่ายก่อนที่จะตกลงรับงาน เสนอให้ลูกค้าเลือกเป็นบริการขยายเพิ่มเติมแบบมีค่าใช้จ่าย หรือจัดกำหนดเวลาให้ดำเนินการในขั้นตอนถัดไป ในขณะที่ยังคงส่งมอบแพ็กเกจการสร้างแบรนด์เดิมให้เสร็จตามกำหนดเวลา
2. แคมเปญการตลาด: การขยายเข้าสู่ตลาดใหม่หลังจากได้รับการอนุมัติ
การเปิดตัวผลิตภัณฑ์ถูกวางแผนไว้สำหรับตลาดเดียวในขั้นต้น แต่ผู้มีส่วนได้ส่วนเสียตัดสินใจขยายไปยังอีกสองภูมิภาคหลังจากอนุมัติแผนการตลาดแล้ว ทีมการตลาดจึงจำเป็นต้องมีข้อความที่ปรับให้เหมาะสมกับแต่ละตลาด ทรัพย์สินสร้างสรรค์เพิ่มเติม และบทวิจารณ์ที่เฉพาะเจาะจงสำหรับตลาดแต่ละแห่ง
เนื่องจากวันที่เปิดตัวและทรัพยากรที่มีอยู่ไม่เปลี่ยนแปลง งานเพิ่มเติมจึงเริ่มขัดแย้งกับแคมเปญเดิม การอนุมัติงานสร้างสรรค์ใช้เวลานานขึ้น และแผนการเปิดตัวที่วางไว้มีความเสี่ยงที่จะล่าช้ากว่ากำหนด
วิธีจัดการ: รักษาการเปิดตัวในตลาดเดิมตามกำหนดการเดิม และประเมินภูมิภาคเพิ่มเติมอย่างแยกกัน การเปิดตัวแบบเป็นขั้นตอนช่วยให้คุณสามารถจัดการเรื่องการปรับให้เหมาะสมกับท้องถิ่น การอนุมัติจากหน่วยงานท้องถิ่น และความต้องการด้านทรัพยากรได้ โดยไม่ส่งผลกระทบต่อพันธสัญญาที่มีอยู่
3. การพัฒนาซอฟต์แวร์: การเพิ่มข้อกำหนดใหม่ระหว่างสปรินต์
ทีมพัฒนามีข้อผูกพันที่จะส่งมอบฟีเจอร์การค้นหาภายในสปรินต์หนึ่ง แต่เมื่อถึงครึ่งทาง ผู้มีส่วนได้ส่วนเสียกลับขอเพิ่มฟังก์ชันวิเคราะห์ข้อมูลเพิ่มเติม และขอให้ทีมพัฒนาจัดให้เสร็จภายในสปรินต์เดียวกัน
ผู้พัฒนาเริ่มทำงานกับตั๋วงานใหม่โดยไม่ตรวจสอบผลกระทบต่อเป้าหมายสปรินต์ เมื่อความจุถูกจัดสรรไปให้ฟีเจอร์เพิ่มเติม การทดสอบและการเสร็จสิ้นงานเดิมจึงถูกเลื่อนออกไป
วิธีจัดการ: ให้ Product Owner ประเมินคำขอใหม่และจัดลำดับความสำคัญใน Product Backlog หากคำขอใดจำเป็นต้องได้รับการพิจารณาอย่างจริงจังใน Sprint ปัจจุบัน นักพัฒนาและ Product Owner สามารถเจรจาใหม่เกี่ยวกับ Sprint Backlog ได้ โดยยังคงรักษา Sprint Goal ไว้
4. โครงการภายในองค์กร: ขยายการเปิดตัวโดยไม่เพิ่มทรัพยากร
สำนักงานบริหารโครงการภายใน (PMO) มีแผนที่จะนำเครื่องมือบริหารงานใหม่มาใช้ในฝ่ายขาย หลังจากมีการสาธิตเบื้องต้น ฝ่ายการเงินและฝ่ายทรัพยากรมนุษย์ได้ขอสิทธิ์เข้าถึงก่อนที่โครงการทดลองจะเสร็จสิ้น
การขยายการนำระบบไปใช้จะก่อให้เกิดข้อกำหนดด้านสิทธิ์การเข้าถึง ความต้องการด้านการฝึกอบรม และภาระงานด้านการสนับสนุนที่เพิ่มขึ้น หากไม่มีความสามารถในการดำเนินการเพิ่มเติม กรมเดิมจะได้รับความสนใจน้อยลง และระดับการนำระบบไปใช้จริงก็เริ่มลดลง
วิธีจัดการ: ให้ดำเนินการและประเมินผลการเปิดตัวในขั้นต้นให้เสร็จสิ้นก่อนที่จะขยายไปยังแผนกอื่น ๆ ใช้ผลการทดลองเพื่อประมาณการความพยายามในการฝึกอบรม ความต้องการในการตั้งค่า และความสามารถในการสนับสนุนสำหรับแต่ละขั้นตอนใหม่ สิ่งนี้จะช่วยให้คุณมีพื้นฐานที่ชัดเจนยิ่งขึ้นในการอนุมัติการขยายการเปิดตัวและกำหนดกำหนดเวลาที่เป็นจริง
ตัวอย่างจากโลกจริง: โครงการไอทีของรัฐบาลที่ใช้เวลาเกือบสี่ปี
การศึกษาตัวอย่างของ PMI ปี 2004 ได้อธิบายถึงโครงการแปลงเอกสารเป็นภาพของหน่วยงานรัฐบาลกลางสหรัฐฯ เพื่อดำเนินการตามคำขอข้อมูลสาธารณะ โครงการนี้มีระยะเวลาการส่งมอบที่คาดการณ์ไว้ระหว่าง 18 ถึง 24 เดือน และงบประมาณประมาณ 10 ล้านดอลลาร์
อย่างไรก็ตาม การศึกษาตัวอย่างของ PMIพบว่าโครงการดังกล่าวมีผู้แทนผู้ใช้ประมาณ 50 คนซึ่งมีความยากลำบากในการตกลงกันเกี่ยวกับข้อกำหนด เมื่อการพัฒนาดำเนินไป กลุ่มต่าง ๆ ได้ขอเปลี่ยนแปลงผลลัพธ์ที่ส่งมอบที่มีอยู่ บางครั้งก็เกิดขึ้นหลายสัปดาห์หลังจากส่งเวอร์ชันก่อนหน้านี้ไปแล้ว
เนื่องจากไม่มีอำนาจตัดสินใจที่ชัดเจน คำขอเหล่านี้จึงยังคงถูกส่งต่อไปเรื่อยๆ ในกระบวนการพัฒนา เอกสารต้องผ่านการแก้ไขซ้ำแล้วซ้ำอีก ข้อกำหนดก็ยิ่งจัดการได้ยากขึ้น และงานที่เสร็จสิ้นแล้วก็ยังต้องมีการปรับเปลี่ยนเพิ่มเติม
สิ่งที่เดิมคาดว่าจะใช้เวลา 18 ถึง 24 เดือน แต่สุดท้ายกลับใช้เวลาเกือบสี่ปี
ข้อสรุป: แม้ข้อกำหนดที่บันทึกไว้อย่างชัดเจนก็ไม่สามารถป้องกันการขยายขอบเขตโครงการได้ หากผู้มีส่วนได้ส่วนเสียสามารถกลับมาทบทวนการตัดสินใจซ้ำๆ โดยไม่มีกลไกการอนุมัติที่ชัดเจน การกำหนดให้ชัดเจนว่าใครมีสิทธิ์ตัดสินใจขั้นสุดท้าย เมื่อใดที่การรับฟังความคิดเห็นจะปิดลง และว่าการเปลี่ยนแปลงจะส่งผลต่อแผนโครงการอย่างไร สามารถป้องกันการแก้ไขซ้ำๆ ที่อาจทำให้การส่งมอบโครงการล่าช้าได้
Agile สามารถป้องกันการขยายขอบเขตโครงการได้หรือไม่?
Agile ช่วยคุณตอบสนองต่อความต้องการที่เปลี่ยนแปลงได้ แต่มันไม่ป้องกันการขยายขอบเขตโครงการโดยอัตโนมัติ ใน Scrum, Product Backlog จะพัฒนาไปพร้อมกับการที่คุณเข้าใจความต้องการของผู้ใช้มากขึ้น รับข้อเสนอแนะ และปรับลำดับความสำคัญ Product Owner เป็นผู้จัดการการเปลี่ยนแปลงเหล่านี้ เพื่อให้งานยังคงสอดคล้องกับเป้าหมายของผลิตภัณฑ์
ความเสี่ยงนี้จะเกิดขึ้นเมื่อรายการใหม่ใน Product Backlog กลายเป็นข้อผูกมัดในการส่งมอบ โดยไม่พิจารณาว่าโครงการสามารถรองรับได้จริงในความเป็นจริง ตัวอย่างเช่น การเพิ่ม audit trail เข้าไปใน Product Backlog หลังจากทดสอบกับผู้ใช้ เป็นวิธีตอบสนองต่อข้อเสนอแนะที่สมเหตุสมผล แต่การสัญญาว่าจะรวมมันไว้ในเวอร์ชันที่จะปล่อยออกมาต่อไป พร้อมกับทุกฟีเจอร์ที่วางแผนไว้เดิม และภายในกำหนดเวลาเดียวกัน อาจก่อให้เกิดการขยายขอบเขตโครงการ
เพื่อจัดการปัญหานี้ ให้แยกสิ่งที่คุณกำลังพิจารณาสำหรับผลิตภัณฑ์ออกจากสิ่งที่คุณได้สัญญาว่าจะส่งมอบ เมื่อมีข้อกำหนดใหม่ที่กลายเป็นความสำคัญ ให้ทบทวนคาดการณ์การปล่อยเวอร์ชัน และตัดสินใจว่าจำเป็นต้องเลื่อนฟีเจอร์ที่มีอยู่ เปลี่ยนวันที่ส่งมอบ หรือจัดสรรทรัพยากรเพิ่มเติมหรือไม่
คู่มือ Scrumสนับสนุนความยืดหยุ่นนี้ผ่านการปรับปรุงและจัดลำดับความสำคัญของงานในแบ็กล็อกอย่างต่อเนื่อง คุณสามารถปรับเปลี่ยนผลิตภัณฑ์ต่อไปได้ พร้อมทั้งรักษาความคาดหวังที่ชัดเจนเกี่ยวกับสิ่งที่แต่ละเวอร์ชันจะส่งมอบ
ข้อผิดพลาดทั่วไปในการขยายขอบเขตโครงการ (และวิธีแก้ไข)
การกำหนดขอบเขตโครงการที่ชัดเจนและกระบวนการอนุมัติการเปลี่ยนแปลงจะช่วยให้คุณจัดการกับคำขอใหม่ได้ แต่ขอบเขตโครงการอาจยังคงขยายตัวได้ผ่านข้อเสนอแนะจากการทบทวน การใช้เงินสำรองของโครงการ และเวลาทำงานล่วงเวลาที่ไม่ได้ติดตาม ให้ระวังสามข้อผิดพลาดต่อไปนี้:
1. การปล่อยให้เกณฑ์การรับมอบเปลี่ยนแปลงระหว่างการทบทวน
ผลลัพธ์ที่ส่งมอบอาจตรงตามข้อกำหนดที่ตกลงกันทุกประการ แต่ยังคงมีคำขอให้เพิ่มงานเพิ่มเติมได้ ตัวอย่างเช่น คุณส่งมอบแดชบอร์ดที่มีตัวชี้วัดที่ได้รับการอนุมัติแล้ว แต่ในขั้นตอนการตรวจสอบครั้งสุดท้าย ผู้มีส่วนได้ส่วนเสียกลับขอการคำนวณเพิ่มเติมและตัวเลือกการรายงานก่อนที่จะอนุมัติ
หากคุณถือว่าการเพิ่มเติมเหล่านั้นเป็นข้อกำหนดที่ต้องได้รับการอนุมัติ คุณก็จะเปลี่ยนนิยามของคำว่า “เสร็จสิ้น” แผนโครงการอาจแสดงผลลัพธ์ที่ส่งมอบเหมือนเดิม แม้ว่าปริมาณงานจะเพิ่มขึ้นก็ตาม
วิธีดำเนินการ: เปรียบเทียบข้อเสนอแนะจากการทบทวนกับเกณฑ์การรับมอบที่ตกลงกันไว้ แก้ไขทุกสิ่งที่ยังไม่ตรงตามข้อกำหนดเหล่านั้น ประเมินคำขอเพิ่มคุณสมบัติใหม่ผ่านกระบวนการอนุมัติการเปลี่ยนแปลง บันทึกสิ่งที่ผู้มีส่วนได้ส่วนเสียยอมรับและเวลาที่รับมอบ โดยเฉพาะเมื่อผลลัพธ์ต้องผ่านหลายรอบการทบทวน
2. การมองเวลาสำรองเป็นกำลังการผลิตที่ว่าง
คุณควรจัดเวลาหรืองบประมาณสำรองไว้เพื่อรับมือกับความเสี่ยงของโครงการ เช่น ปัญหาทางเทคนิคหรือความล่าช้าในการอนุมัติจากฝ่ายภายนอก หากช่วงสัปดาห์แรกๆ ดำเนินไปอย่างราบรื่น คุณอาจเริ่มใช้ส่วนสำรองนั้นเพื่อรับมือกับคำขอใหม่
เมื่อนั้น ความเสี่ยงจะกลายเป็นปัญหาจริง และเวลาหรืองบประมาณที่คุณต้องการก็ถูกใช้ไปหมดแล้วกับงานเพิ่มเติม
วิธีดำเนินการ: กำหนดให้ชัดเจนว่างบประมาณสำรองครอบคลุมอะไรบ้าง และใครมีสิทธิ์อนุมัติการใช้เงินส่วนนี้ บางโครงการอนุญาตให้ทีมใช้งบประมาณสำรองนี้สำหรับการเปลี่ยนแปลงเล็กน้อยที่ได้รับการอนุมัติแล้ว แต่แม้ในกรณีนี้ ก็ควรตรวจสอบคำขอแต่ละครั้งก่อนที่จะใช้งบประมาณสำรอง ติดตามจำนวนเงินที่เหลืออยู่ และตรวจสอบว่ายังมีเพียงพอที่จะครอบคลุมความเสี่ยงที่คุณได้ระบุไว้หรือไม่
3. รับมือกับงานเพิ่มเติมผ่านการทำงานล่วงเวลา
โครงการสามารถดำเนินไปตามกำหนดเวลาได้แม้ขอบเขตจะขยายตัวออกไป สมาชิกในทีมอาจต้องทำงานเกินเวลาเพื่อจัดการกับคำขอเพิ่มเติม และไม่บันทึกความพยายามนั้นไว้ในบันทึกโครงการ
คุณอาจเสร็จงานตามกำหนดเวลา แต่การทำงานใช้เวลานานกว่าที่วางแผนไว้ หากคุณใช้โครงการนั้นเพื่อประมาณการงานในอนาคต คุณอาจกำหนดกำหนดเวลาที่ขึ้นอยู่กับชั่วโมงเพิ่มเติมเดียวกัน
วิธีดำเนินการ: ติดตามเวลาทั้งหมดที่ใช้ไปกับโครงการ รวมถึงเวลาทำงานล่วงเวลาและงานนอกเวลาที่กำหนดไว้ เปรียบเทียบเวลาจริงกับเวลาที่คาดการณ์ไว้ และตรวจสอบช่องว่างที่เกิดขึ้นซ้ำๆ สิ่งนี้ช่วยให้คุณระบุงานที่ไม่ได้วางแผนไว้ก่อนที่กำหนดเวลาจะล่าช้า และให้พื้นฐานที่มั่นคงสำหรับการวางแผนความจุในอนาคต
ClickUp ช่วยคุณควบคุมการขยายขอบเขตโครงการได้อย่างไร
การเปลี่ยนแปลงที่ได้รับการอนุมัติจะมีประโยชน์ก็ต่อเมื่อทีมทำงานตามข้อกำหนดล่าสุด ซึ่งหมายความว่าต้องรักษาความเชื่อมโยงระหว่างการตัดสินใจ งานที่ได้รับผลกระทบ และความต้องการด้านทรัพยากร เพื่อให้ทุกคนทราบว่าต้องส่งมอบอะไร
ClickUpรวมส่วนต่าง ๆ ของการจัดการขอบเขตโครงการไว้ในพื้นที่ทำงานเดียว คุณสามารถติดตามคำขอใหม่ ติดตามงานที่ได้รับการอนุมัติ และตรวจสอบสัญญาณที่บ่งชี้ว่าโครงการอาจต้องการเวลาหรืองบประมาณเพิ่มเติม
เริ่มต้นด้วยแม่แบบคำขอเปลี่ยนแปลงของ ClickUp ซึ่งประกอบด้วยแบบฟอร์มคำขอเปลี่ยนแปลง สนามข้อมูลกำหนดเอง ผลกระทบต่อขอบเขต และสถานะต่าง ๆ เช่น คำขอใหม่, กำลังตรวจสอบ และ พร้อมดำเนินการ ทุกครั้งที่ส่งแบบฟอร์มจะสร้างงานใหม่ ให้มอบหมายงานนั้นให้กับผู้ตรวจสอบ และติดตามความคืบหน้าผ่านกระบวนการอนุมัติ
จากนั้น ให้เชื่อมโยงแต่ละคำขอเข้ากับงานที่ได้รับผลกระทบ:
- ตรวจสอบคำขอเทียบกับขอบเขตงานที่ได้รับการอนุมัติ ใช้ClickUp Docsเพื่อบันทึกผลลัพธ์ที่คาดหวัง สิ่งที่ไม่รวมอยู่ในขอบเขต และเกณฑ์การรับมอบงาน เชื่อมโยงเอกสารขอบเขตงานกับงานคำขอ เพื่อให้ผู้ตรวจสอบสามารถกำหนดได้ว่างานดังกล่าวอยู่ในขอบเขตที่ได้รับการอนุมัติแล้วหรือจำเป็นต้องได้รับการอนุมัติแยกต่างหาก
- ระบุงานที่การเปลี่ยนแปลงจะส่งผลกระทบ ใช้ฟีเจอร์ "Relationships" ในClickUp Tasksเพื่อเชื่อมโยงคำขอไปยังงานส่งมอบที่ได้รับผลกระทบ บันทึกผลกระทบต่อขอบเขตงานในCustom Fields และเพิ่มการประมาณเวลาสำหรับงานการดำเนินการ การทดสอบ และการตรวจสอบ
- ตรวจสอบความจุก่อนที่จะให้คำมั่น ใช้มุมมองปริมาณงาน (workload view) ที่แสดงวันที่ของงาน, เวลาที่คาดการณ์ไว้ และความจุที่ตั้งค่าไว้ เพื่อประเมินว่าทีมสามารถรับมือกับการเปลี่ยนแปลงได้หรือไม่ ใช้ผลการประเมินนั้นเพื่อเสนอการจัดสรรงานใหม่, กำหนดเวลาส่งงานใหม่ หรือเลื่อนระยะการส่งมอบออกไป
- ส่งคำขอไปให้ผู้ตรวจสอบและบันทึกการตัดสินใจ ตั้งค่าClickUp Automationsเพื่อกำหนดผู้ตรวจสอบหรือแจ้งให้เจ้าของขอบเขตทราบเมื่อมีคำขอที่ต้องการการพิจารณา ให้ผู้อนุมัติที่มีอำนาจบันทึกการตัดสินใจและเปลี่ยนแปลงค่าใช้จ่ายหรือกำหนดเวลาที่ตกลงกันไว้ แยกคำขอที่ถูกปฏิเสธหรือเลื่อนออกไปจากงานที่ได้รับการอนุมัติ
- อัปเดตแผนและติดตามความพยายามจริง หลังจากได้รับการอนุมัติ ให้แก้ไขเอกสารขอบเขต งานที่ได้รับผลกระทบ งบประมาณ และกำหนดการ แล้วย้ายคำขอไปยังสถานะ “For Implementation” ในแดชบอร์ด ClickUp ให้เปิดใช้งาน “Show Time Estimates” ในบัตร Time Reporting เพื่อเปรียบเทียบชั่วโมงที่คาดการณ์กับชั่วโมงที่ติดตามได้สำหรับงานที่มีข้อมูลเวลาบันทึก ตรวจสอบการเกินเวลาอย่างละเอียดก่อนที่จะถือว่าเป็นการขยายขอบเขตเพิ่มเติม
ประเมินคำขอเปลี่ยนแปลงด้วย ClickUp Brain²
ใช้ClickUp Brain²เพื่อตรวจสอบการเปลี่ยนแปลงที่เสนอมาพร้อมกับขอบเขตงานที่ได้รับการอนุมัติและบันทึกงานที่เกี่ยวข้อง ตัวอย่างเช่น ให้ถามว่า: “เปรียบเทียบคำขอชุดสไลด์การนำเสนอนี้กับขอบเขตงานด้านแบรนด์ที่ได้รับการอนุมัติ ระบุผลลัพธ์เพิ่มเติม รอบการแก้ไข หรือการอนุมัติที่จำเป็น และอ้างอิงบันทึกที่คุณใช้”
ตรวจสอบการเปรียบเทียบก่อนส่งให้ลูกค้าทราบ ขอให้ Brain² สรุปการเปลี่ยนแปลงที่เสนอ การประมาณการที่ได้บันทึกไว้ ข้อผูกพันที่ได้รับผลกระทบ และคำถามที่ยังต้องการคำตอบ ให้ทีมผู้ดำเนินการยืนยันปริมาณงานและความสัมพันธ์ระหว่างงาน จากนั้นส่งข้อมูลที่จำเป็นให้ผู้อนุมัติที่มีอำนาจ เพื่อตัดสินใจรับอนุมัติ เลื่อนการพิจารณา หรือปฏิเสธคำขอ
ตรวจสอบการขยายขอบเขตโครงการและความเสี่ยงในการส่งมอบร่วมกับ ClickUp Super Agents
เพื่อการกำกับดูแลอย่างใกล้ชิดยิ่งขึ้นซูเปอร์เอเจนต์ ClickUpสองคนสามารถช่วยคุณตรวจพบการขยายขอบเขตโครงการที่อาจเกิดขึ้น และเข้าใจผลที่ตามมาได้:
- Scope Creep Detector Agent: เปรียบเทียบงานปัจจุบันกับโครงการเดิมหรือจุดอ้างอิงของสปรินต์ มันจะแจ้งเตือนเกี่ยวกับงานใหม่ ข้อกำหนดที่ขยายตัว และผลลัพธ์ที่เปลี่ยนแปลง รวมถึงวัดการขยายตัวของขอบเขตงานตั้งแต่ขั้นตอนการวางแผน สถานะการอนุมัติที่สม่ำเสมอหรือสนามข้อมูลที่กำหนดเอง (Custom Fields) สามารถช่วยแยกแยะการเปลี่ยนแปลงที่ได้รับการอนุมัติออกจากส่วนที่เพิ่มเข้ามาซึ่งจำเป็นต้องได้รับการตรวจสอบ
- Risk Assessment Analyzer Agent: ตรวจสอบกำหนดเวลา การจัดสรรทรัพยากร และความสัมพันธ์ระหว่างงาน เพื่อประเมินความเสี่ยงในการส่งมอบ ตัวอย่างเช่น งานเพิ่มเติมอาจทำให้ผู้พัฒนาต้องรับภาระมากเกินไป หรือทำให้จุดสำคัญที่ขึ้นอยู่กับงานนั้นตกอยู่ในความเสี่ยง ตัวเอเจนต์นี้สามารถแจ้งเตือนปัญหาและเสนอมาตรการแก้ไขตามระดับความรุนแรงของปัญหา
กำหนดสิทธิ์การเข้าถึงของตัวแทนแต่ละคนให้สามารถเข้าถึงข้อมูลพื้นฐานที่เกี่ยวข้อง บันทึกงาน และผลการอนุมัติ และให้เจ้าของขอบเขตโครงการตรวจสอบผลการตรวจสอบดังกล่าว
เหมาะสำหรับ: หน่วยงานและทีมข้ามหน้าที่ที่ต้องจัดการกับคำขอเปลี่ยนแปลงที่เกิดขึ้นบ่อยครั้ง ผลลัพธ์ที่แบ่งปันร่วมกัน และงบประมาณโครงการ
ข้ามส่วนนี้ไปหาก: คุณกำลังดำเนินโครงการขนาดเล็กและระยะสั้นที่มีผู้เกี่ยวข้องไม่มาก และสามารถบันทึกการเปลี่ยนแปลงได้อย่างน่าเชื่อถือในสเปรดชีต
ป้องกันไม่ให้การขยายขอบเขตโครงการกลายเป็นค่าใช้จ่ายที่ซ่อนเร้น
โครงการหนึ่งอาจเสร็จสิ้นตามกำหนดเวลาและทำให้ลูกค้าพอใจ แต่ยังคงต้องเผชิญกับปัญหาการขยายขอบเขตงาน ทีมอาจต้องรับมือกับงานเพิ่มเติมโดยการทำงานล่วงเวลา ใช้เงินสำรอง หรือยืมเวลาจากโครงการอื่น บนกระดาษ ทุกอย่างดูดี แต่ความพยายามที่ต้องใช้เพื่อให้โครงการเสร็จสิ้นกลับบอกเล่าเรื่องราวที่ต่างออกไป
การจัดการการขยายขอบเขตโครงการหมายถึงการตระหนักถึงการแลกเปลี่ยนผลประโยชน์เหล่านี้ในขณะที่ยังมีโอกาสที่จะเจรจาปรับเปลี่ยนได้ คุณสามารถรับคำขอใหม่ ปรับเปลี่ยนข้อผูกพันที่มีอยู่ หรือเก็บงานไว้ทำในขั้นตอนต่อไป สิ่งสำคัญคือต้องตัดสินใจก่อนที่จะมีใครลงทุนเวลาไปแล้ว
เมื่อโครงการขยายตัว ClickUp จะแสดงการตัดสินใจเหล่านั้นให้เห็นได้ชัดเจนควบคู่กับงานที่ได้รับผลกระทบ เริ่มต้นด้วยแม่แบบคำขอเปลี่ยนแปลง (Change Request Template) เพื่อให้ทุกการรับภาระงานใหม่เป็นไปอย่างมีเจตนาและสามารถตรวจสอบได้ จากนั้น ใช้พื้นที่ทำงานของ ClickUp ที่กว้างขึ้นเพื่อวางแผนงาน ประสานงานการส่งต่อ และติดตามการส่งมอบตามความต้องการของโครงการที่เปลี่ยนแปลงไป
คำถามที่มักถูกถามเกี่ยวกับ Scope Creep
คำอื่นที่หมายถึง "scope creep" คืออะไร?
คำพ้องความหมายที่พบบ่อย ได้แก่ การขยายขอบเขตความต้องการ (requirement creep), อาการใส่ทุกอย่าง (kitchen sink syndrome), การขยายขอบเขตภารกิจ (mission creep), และการขยายขอบเขตคุณสมบัติ (feature creep) คำว่า mission creep ใช้ส่วนใหญ่ในโครงการของรัฐบาลและทหาร ส่วน feature creep ใช้กับผลิตภัณฑ์ซอฟต์แวร์ การขยายขอบเขตคุณสมบัติ (feature creep) มีขอบเขตที่แคบกว่า เนื่องจากครอบคลุมเฉพาะคุณสมบัติของผลิตภัณฑ์ ในขณะที่การขยายขอบเขตโครงการ (scope creep) ครอบคลุมทั้งโครงการ
ทำอย่างไรเพื่อปฏิเสธการขยายขอบเขตโครงการกับลูกค้า?
อธิบายว่าส่วนใดของคำขออยู่นอกขอบเขตที่ตกลงกันไว้ หากเป็นไปได้ ให้ประมาณเวลาและค่าใช้จ่าย แล้วเสนอตัวเลือก: เพิ่มส่วนนั้นเข้าไปพร้อมกับการปรับงบประมาณและกำหนดเวลาที่ตกลงกันไว้ ย้ายไปทำในขั้นตอนถัดไป หรือเปลี่ยนเป็นงานที่มีระดับความพยายามและความเสี่ยงเทียบเท่ากัน หากคำขอนั้นจะส่งผลกระทบต่อข้อผูกพันที่มีอยู่ ให้อธิบายว่าทำไมคุณไม่สามารถรับคำขอได้
ทำอย่างไรเพื่อกู้คืนโครงการที่ประสบปัญหาการขยายขอบเขตแล้ว?
เริ่มด้วยการตรวจสอบงานที่ยังเหลืออยู่เทียบกับขอบเขตงานที่ได้รับการอนุมัติล่าสุด ระบุส่วนที่เพิ่มเข้ามาแต่ยังไม่ได้รับการอนุมัติ ประเมินปริมาณงานที่จำเป็นเพื่อเสร็จสิ้น และตัดสินใจว่าจะเลื่อนหรือตัดส่วนใดออก จากนั้นตกลงกับผู้สนับสนุนโครงการเกี่ยวกับแผนการกู้คืน ซึ่งรวมถึงการเปลี่ยนแปลงใดๆ ในงบประมาณ ทรัพยากร หรือกำหนดเวลา
คุณตัดสินใจอย่างไรว่าการเปลี่ยนแปลงขอบเขตงานนั้นควรรับไว้หรือไม่?
ลองใช้เวลาสักครู่เพื่อชั่งน้ำหนักระหว่างประโยชน์ที่คาดว่าจะได้รับกับค่าใช้จ่าย ความพยายาม และความเสี่ยงที่เพิ่มขึ้น เปรียบเทียบคำขอดังกล่าวกับตัวเลือกอื่น ๆ เช่น การเลื่อนออกไป หรือการแทนที่ผลลัพธ์ที่มีอยู่ หากการเปลี่ยนแปลงดังกล่าวสนับสนุนเป้าหมายของโครงการโดยไม่ทำให้เสียเวลาจากงานที่มีลำดับความสำคัญสูงกว่า ก็อาจเป็นตัวเลือกที่ดีที่ควรพิจารณา
การเกินงบประมาณทุกครั้งหมายความว่าเป็นผลจาก scope creep หรือไม่?
ไม่ โครงการอาจเกินงบประมาณได้แม้ไม่มีการเพิ่มงาน ค่าใช้จ่ายแรงงานที่สูงขึ้น การประมาณการที่ไม่แม่นยำ และการทำงานซ้ำที่คาดไม่ถึง ล้วนเป็นสาเหตุที่ทำให้ค่าใช้จ่ายเกินงบประมาณได้ Scope creep เกิดขึ้นเมื่องานที่ตกลงกันไว้ขยายตัวออกไปโดยไม่มีการอนุมัติหรือปรับเปลี่ยนอย่างเหมาะสม ตรวจสอบขอบเขตพื้นฐานก่อนที่จะสันนิษฐานว่าความต้องการเพิ่มเติมเป็นสาเหตุของการเพิ่มขึ้น