หากคุณเคยเล่น Super Mario คุณคงรู้จักช่วงเวลานั้นดี: เวลาบนนาฬิกากำลังหมดลง คุณพลาดการกระโดดจุดเดิมสองครั้งแล้ว และคุณกำลังตัดสินใจว่าจะลองอีกครั้งหรือหาทางอื่น คุณต้องตัดสินใจและรับมือกับผลลัพธ์
โครงการต่างๆ จะทำให้คุณเผชิญกับสถานการณ์ที่คล้ายกัน เมื่องานล่าช้า คุณอาจเลื่อนกำหนดเวลา จ้างผู้ช่วยเพิ่มเติม หรือลดขอบเขตงาน แต่ในกรณีนี้ การเลือกของคุณจะส่งผลกระทบต่องบประมาณและข้อผูกพันของผู้อื่น ดังนั้น การตัดสินใจเหล่านั้นจึงจำเป็นต้องมีอำนาจในการดำเนินการ คุณต้องรู้ว่าการเปลี่ยนแปลงใดที่คุณสามารถอนุมัติได้เอง และเปลี่ยนแปลงใดที่จำเป็นต้องได้รับการอนุมัติจากผู้อื่น
กรอบงานการบริหารโครงการกำหนดกฎเกณฑ์เหล่านี้ก่อนที่จะเริ่มทำงาน นี่คือวิธีการสร้างกรอบงานดังกล่าว พร้อมตัวอย่างจริงที่แสดงให้เห็นว่าทีมจัดการกับการเปลี่ยนแปลงและการอนุมัติอย่างไร
TL;DR: การกำกับดูแลโครงการกำหนดว่าใครมีสิทธิ์อนุมัติการตัดสินใจ เมื่อใดทีมต้องรายงานปัญหาขึ้นระดับสูง และผู้สนับสนุนโครงการจะประเมินอย่างไรว่าโครงการนั้นยังคุ้มค่าที่จะได้รับทุนต่อไปหรือไม่
สร้างกรอบงานของคุณโดยกำหนดผู้อนุมัติ กำหนดขีดจำกัดด้านค่าใช้จ่าย กำหนดเวลา ขอบเขตงาน และความเสี่ยง รวมถึงตกลงกันเกี่ยวกับกำหนดเวลาในการตอบสนอง เก็บคำขอการอนุมัติและผลการตัดสินใจไว้ในบันทึกที่ทุกคนสามารถเข้าถึงได้ และทบทวนกฎเกณฑ์ในแต่ละขั้นตอนของโครงการ
สำหรับโครงการที่มีความเสี่ยงต่ำ เอกสารกำหนดขอบเขตโครงการขั้นพื้นฐาน ขีดจำกัดการอนุมัติ และบันทึกการตัดสินใจ อาจเพียงพอแล้ว แต่เมื่อความเสี่ยงทางการเงิน ความพึ่งพา หรือข้อกำหนดทางกฎหมายเพิ่มขึ้น ก็ควรเพิ่มการทบทวนอย่างเป็นทางการและการกำกับดูแล
การบริหารจัดการโครงการคืออะไร?
การบริหารจัดการโครงการคือกรอบงานที่ประกอบด้วยบทบาท สิทธิในการตัดสินใจ และกลไกควบคุม ซึ่งช่วยให้โครงการสอดคล้องกับเป้าหมายขององค์กร ตั้งแต่ขั้นตอนการอนุมัติจนถึงการปิดโครงการ
PMI อธิบายว่าการกำกับดูแลเป็นหน้าที่การกำกับดูแลที่ครอบคลุมวงจรชีวิตของโครงการ และสอดคล้องกับแบบจำลองการกำกับดูแลขององค์กร ในคำง่ายๆ การกำกับดูแลกำหนดทิศทางและกฎการตัดสินใจ ส่วนการบริหารโครงการครอบคลุมการวางแผนและการดำเนินการประจำวันภายในกฎเหล่านั้น
กรอบงานนี้ยังกำหนดว่าใครจะเป็นผู้ประเมินว่าโครงการนั้นยังคุ้มค่าที่จะได้รับทุนหรือไม่ เมื่อค่าใช้จ่าย ความเสี่ยง และประโยชน์ที่คาดการณ์ไว้เปลี่ยนแปลงไป ผู้สนับสนุนโครงการจะใช้กรณีธุรกิจ (business case) ซึ่งบันทึกประโยชน์ที่คาดการณ์ไว้ ค่าใช้จ่าย และเหตุผลในการลงทุนของโครงการ เพื่อประเมินว่าการดำเนินโครงการต่อไปยังมีความเหมาะสมหรือไม่ เมื่อเงื่อนไขเปลี่ยนแปลงไป
ระบบการบริหารจัดการโครงการที่อิงตามระดับความทนทานทำงานอย่างไร?
ระบบการบริหารจัดการที่อิงตามระดับความทนทาน (tolerance-based governance) ให้คุณมีพื้นที่ในการจัดการงานและกำหนดเวลาภายในขอบเขตที่ตกลงกันไว้ หากคาดว่าจะเกินขอบเขตที่ตกลงกันไว้ ให้แจ้งปัญหานี้กับผู้อนุมัติที่ได้รับการแต่งตั้ง
ข้อจำกัดดังกล่าวใช้กับแผนเฉพาะ คุณอาจมีระดับความทนทานที่ต่างกันสำหรับโครงการโดยรวม แต่ละขั้นตอน และงานย่อยแต่ละส่วน การอยู่ภายในงบประมาณหรือกำหนดเวลาโดยรวม ไม่ได้หมายความว่าคุณมีสิทธิ์ที่จะเกินข้อจำกัดของขั้นตอนนั้น
PRINCE2 เรียกวิธีการนี้ว่า จัดการตามข้อยกเว้น (manage by exception) นี่คือวิธีที่มันอาจทำงานได้ระหว่างการเปิดตัวเว็บไซต์ใหม่:
- แผนที่ได้รับการอนุมัติ: การทดสอบควรใช้เวลาสามสัปดาห์ โดยอนุญาตให้เพิ่มเวลาได้สูงสุดหนึ่งสัปดาห์
- การคาดการณ์: เมื่อถึงครึ่งทางของการทดสอบ หัวหน้าทีม QA ประเมินว่ากระบวนการนี้จะใช้เวลาทั้งหมด 5 สัปดาห์ ซึ่งเกินขีดจำกัด 4 สัปดาห์
- การตัดสินใจ: คุณเสนอให้ดำเนินการงานที่เหลือไปพร้อมกันเพื่อรักษาวันที่เปิดตัว แต่คณะกรรมการกำกับดูแลต้องอนุมัติแผนขั้นตอนที่แก้ไขแล้วตามกฎของโครงการนี้
การดำเนินการงานที่เหลือไปพร้อมกันอาจช่วยให้การเปิดตัวเป็นไปตามกำหนดเวลา แต่การทดสอบจะยังคงใช้เวลานานกว่าสี่สัปดาห์ที่อนุญาตไว้ ซึ่งหมายความว่าคุณยังต้องได้รับการอนุมัติจากคณะกรรมการกำกับดูแลเพื่อปรับเปลี่ยนแผนการทดสอบ เมื่อคณะกรรมการอนุมัติแผนที่ปรับปรุงแล้วและกำหนดขอบเขต คุณจะจัดการงานประจำวันภายในขอบเขตที่กำหนดไว้
การกำกับดูแลโครงการ vs. การบริหารโครงการ: ความแตกต่างคืออะไร?
ผู้จัดการโครงการและผู้สนับสนุนอาจมองการเปลี่ยนแปลงเดียวกัน แต่เห็นปัญหาที่แตกต่างกัน
สำหรับผู้จัดการ การส่งมอบงานที่ล่าช้าหมายความว่าต้องหาวิธีใหม่เพื่อเสร็จสิ้นงาน ส่วนสำหรับผู้สนับสนุน อาจหมายความว่าต้องตัดสินใจว่าการเปิดตัวที่ล่าช้ากว่านั้นคุ้มค่ากับค่าใช้จ่ายทางธุรกิจหรือไม่ ทั้งสองฝ่ายล้วนมีส่วนได้ส่วนเสียในผลลัพธ์ แต่พวกเขาไม่ได้ตัดสินใจในประเด็นเดียวกัน
| มิติ | การบริหารจัดการโครงการ | การบริหารโครงการ |
|---|---|---|
| ประเด็นหลัก | โครงการนี้ยังคุ้มค่ากับค่าใช้จ่ายและความเสี่ยงหรือไม่? | ทีมสามารถส่งมอบผลลัพธ์ที่ตกลงกันไว้ได้อย่างไร? |
| ใครเป็นผู้นำโครงการ | ผู้สนับสนุนหรือกลุ่มกำกับดูแล พร้อมด้วยการสนับสนุนจาก PMO เมื่อจำเป็น | ผู้จัดการโครงการและทีมดำเนินการ |
| การตัดสินใจทั่วไป | การจัดหาเงินทุน การเปลี่ยนแปลงสำคัญ การอนุมัติแต่ละขั้นตอน และการตัดสินใจว่าจะดำเนินการต่อหรือไม่ | ลำดับงาน, การจัดสรรบุคลากร, วันที่กำหนด และการแก้ไขปัญหาภายในขอบเขตที่ตกลงกัน |
| บันทึกหลัก | กรณีธุรกิจ, กฎการอนุมัติ และบันทึกการตัดสินใจ | แผนการส่งมอบ, ตารางเวลา และบอร์ดงาน |
ในหลายโครงการ สำนักงานบริหารโครงการ (PMO) อาจกำหนดมาตรฐานการรายงานและการอนุมัติที่ใช้ร่วมกัน แต่สิ่งนี้ไม่ได้หมายความว่ามันมีอำนาจในการตัดสินใจทุกเรื่องเกี่ยวกับการจัดสรรงบประมาณหรือขอบเขตโครงการ คู่มือของเราเกี่ยวกับกรอบงานการบริหารจัดการ PMOอธิบายบทบาทที่กว้างขึ้นของ PMO
องค์ประกอบของกรอบงานการบริหารจัดการโครงการมีอะไรบ้าง?
การบริหารจัดการโครงการตั้งอยู่บนสามเสาหลัก ได้แก่ โครงสร้างองค์กร บุคลากร และข้อมูล ตามที่อธิบายไว้ในหนังสือProject Management 2.0ของ Harold Kerzner โครงสร้างครอบคลุมสายการรายงานและขั้นตอนการอนุมัติ บุคลากรมีบทบาทและสิทธิในการตัดสินใจ ส่วนข้อมูลให้หลักฐานที่จำเป็นสำหรับการตัดสินใจ
เพื่อนำเสาหลักเหล่านี้ไปปฏิบัติเอกสารการประชุมของ PMIได้เสนอองค์ประกอบด้านการกำกับดูแล 8 ประการที่คุณสามารถปรับใช้ได้ตามความเหมาะสม รายการตรวจสอบด้านล่างนี้แสดงให้เห็นว่าแต่ละองค์ประกอบครอบคลุมเรื่องใด และเอกสารหรือกระบวนการใดที่คุณจำเป็นต้องรักษาไว้
| ส่วนประกอบ | คำถามที่ต้องตอบ | เอกสารที่จำเป็นต้องจัดทำ |
|---|---|---|
| แบบจำลองการบริหารจัดการ | โครงการนี้ต้องการการกำกับดูแลในระดับใด? | แนวทางที่ได้รับการตกลงกันและบันทึกไว้ในเอกสารกฎบัตรหรือแผนการบริหารจัดการ |
| ความรับผิดชอบและหน้าที่ | ใครเป็นเจ้าของงาน และใครมีสิทธิ์อนุมัติการตัดสินใจ? | แมทริกซ์ RACI และสิทธิการตัดสินใจที่ระบุเป็นลายลักษณ์อักษร |
| การมีส่วนร่วมและการสื่อสารกับผู้มีส่วนได้ส่วนเสีย | ใครจะได้รับผลกระทบ และคุณจะรักษาการมีส่วนร่วมของพวกเขาอย่างไร? | แผนผังผู้มีส่วนได้ส่วนเสียและแผนการสื่อสาร |
| การประชุม | การตัดสินใจใดที่จำเป็นต้องจัดประชุม และใครควรเข้าร่วมประชุม? | กำหนดวัตถุประสงค์การประชุม ผู้เข้าร่วมประชุม และอำนาจการตัดสินใจ |
| การรายงาน | ผู้ตัดสินใจจำเป็นต้องรู้อะไร และเมื่อใด? | กำหนดการรายงาน, รายงานสถานะ และรายงานกรณีผิดปกติ |
| การจัดการความเสี่ยงและปัญหา | คุณจะประเมินข้อกังวลและตัดสินใจเมื่อใดที่จะส่งเรื่องขึ้นระดับสูงได้อย่างไร? | ทะเบียนความเสี่ยงหรือบันทึก RAID พร้อมรายชื่อผู้รับผิดชอบและเกณฑ์การยกระดับปัญหา |
| การรับรอง | คุณจะตรวจสอบอย่างไรเพื่อให้มั่นใจว่าการส่งมอบและรายงานมีความน่าเชื่อถือ? | ทบทวนเกณฑ์การประเมิน มาตรการวัดผลการดำเนินงาน และการตรวจสอบความมั่นใจ |
| กระบวนการควบคุม | คุณจะติดตามผลการดำเนินงานและจัดการกับการเปลี่ยนแปลงในแผนที่ได้รับการอนุมัติอย่างไร? | เกณฑ์พื้นฐานที่ตกลงกันไว้, ขีดจำกัดความทนทาน และกระบวนการควบคุมการเปลี่ยนแปลง |
สำหรับการอนุมัติ ให้ตรวจสอบว่าบันทึกของคุณครอบคลุมมากกว่าการมอบหมายงานหรือไม่แมทริกซ์ RACIสามารถแสดงได้ว่าใครเป็นผู้รับผิดชอบต่อผลลัพธ์ของงาน แต่ไม่จำเป็นต้องระบุชัดเจนว่าใครมีสิทธิ์อนุมัติการใช้จ่ายเพิ่มเติมหรือการขยายกำหนดเวลา ให้บันทึกอำนาจนั้นไว้ในสิทธิ์การตัดสินใจของคุณ แล้วใช้กระบวนการควบคุมการเปลี่ยนแปลงเพื่อกำหนดว่าคำขอจะส่งถึงผู้อนุมัติอย่างไร
คุณยังต้องแยกแยะระหว่างความเสี่ยงกับปัญหา: ความเสี่ยงอาจเกิดขึ้นได้ ส่วนปัญหาคือสิ่งที่เกิดขึ้นแล้ว ความล่าช้าที่อาจเกิดขึ้นจากผู้จัดหาเป็นความเสี่ยง ส่วนการส่งสินค้าไม่ทันกำหนดเป็นปัญหาที่จำเป็นต้องดำเนินการแก้ไข ติดตามความเสี่ยงและปัญหาในแบบฟอร์มทะเบียนความเสี่ยงและบันทึกปัญหา หรือใช้บันทึก RAID ที่มีหมวดหมู่และเจ้าของที่แยกกัน
เคล็ดลับ:คู่มือ RACI vs. RAIDอธิบายว่า RAID ช่วยรวมความเสี่ยง สมมติฐาน ปัญหา และความพึ่งพาไว้ในบันทึกเดียวได้อย่างไร
ใครเป็นผู้รับผิดชอบด้านการกำกับดูแลโครงการ?
ผู้สนับสนุนโครงการ (project sponsor) มักจะเป็นผู้รับผิดชอบกรณีธุรกิจ (business case) และยังคงต้องรับผิดชอบต่อมูลค่าของโครงการ ผู้จัดการโครงการ (project manager) จะดำเนินการตามขอบเขตที่ตกลงกันไว้ โดยมีคณะกรรมการกำกับดูแล (steering committee) หรือสำนักงานบริหารโครงการ (PMO) ดำเนินการกำกับดูแลตามความจำเป็น
บทบาทที่จำเป็นจะขึ้นอยู่กับความซับซ้อนและระดับความเสี่ยงของโครงการ โครงการขนาดเล็กอาจต้องการเพียงผู้สนับสนุนและผู้จัดการโครงการเท่านั้น ส่วนงานที่ข้ามหลายแผนกอาจต้องการคณะกรรมการกำกับดูแลเพื่อแก้ไขความขัดแย้งในลำดับความสำคัญและตรวจสอบการเปลี่ยนแปลงสำคัญ
| บทบาท | หน้าที่หลัก | ขอบเขตอำนาจ |
|---|---|---|
| ผู้สนับสนุนโครงการ | รับผิดชอบในการจัดทำกรณีธุรกิจ จัดหาเงินทุน และประเมินว่าโครงการควรดำเนินการต่อหรือไม่ | จำเป็นต้องได้รับการอนุมัติระดับสูงยิ่งขึ้นสำหรับข้อตัดสินใจที่เกินขอบเขตอำนาจหน้าที่ |
| คณะกรรมการกำกับดูแล | ทบทวนกรณีข้อยกเว้นสำคัญ แก้ไขความขัดแย้งระหว่างทีม และให้แนวทางในการตัดสินใจสำคัญ | สามารถอนุมัติการเปลี่ยนแปลงได้เฉพาะภายในขอบเขตอำนาจที่ได้รับการมอบหมายเท่านั้น |
| PMO | กำหนดมาตรฐานการบริหารจัดการ สนับสนุนการรายงาน และตรวจสอบการปฏิบัติตามกระบวนการที่ตกลงกัน | อำนาจการอนุมัติขึ้นอยู่กับขอบเขตความรับผิดชอบ |
| ผู้จัดการโครงการ | วางแผนการดำเนินการ จัดสรรทรัพยากร และตัดสินใจภายในขอบเขตที่ตกลงกัน | ส่งเรื่องที่เกินอำนาจของตนไปยังระดับที่สูงขึ้น |
| หัวหน้าทีมโครงการและหัวหน้ากลุ่มงาน | ดำเนินการงานที่ได้รับมอบหมาย แจ้งความเสี่ยง และเสนอแนวทางแก้ไข | ส่งการตัดสินใจที่เกินอำนาจของบุคคลนั้นไปยังระดับที่สูงขึ้นตามขั้นตอนที่ตกลงกันไว้ |
ก่อนที่จะส่งคำขอไปยังคณะกรรมการกำกับดูแล ให้ตรวจสอบว่าคณะกรรมการดังกล่าวมีอำนาจอนุมัติการเปลี่ยนแปลงได้หรือไม่ หรือเพียงให้คำแนะนำเท่านั้น คณะกรรมการอาจสนับสนุนการจัดสรรงบประมาณเพิ่มเติม 30,000 ดอลลาร์เพื่อแก้ไขปัญหาคุณภาพข้อมูล แต่อำนาจตัดสินใจขั้นสุดท้ายในการใช้จ่ายเงินยังคงอยู่ที่ CFO ในกรณีนี้ คุณยังคงต้องได้รับการอนุมัติจาก CFO ก่อนที่จะจัดสรรงบประมาณ
บันทึกขอบเขตเหล่านี้ไว้ในเอกสารโครงการหรือแผนการบริหารจัดการโครงการ รวมถึงการกำหนดว่าข้อขัดแย้งที่ยังไม่ได้รับการแก้ไขจะส่งไปให้ใครเพื่อตัดสินใจขั้นสุดท้าย สำหรับคำขอเร่งด่วน ให้กำหนดผู้อนุมัติสำรองที่มีอำนาจที่ได้รับมอบหมายครอบคลุมการตัดสินใจดังกล่าว
วิธีสร้างกรอบงานการบริหารโครงการใน 6 ขั้นตอน
เริ่มจากเอกสารกำหนดโครงการ (project charter) และแผนที่ได้รับการอนุมัติ แล้วใช้ขั้นตอนต่อไปนี้เพื่อกำหนดกฎเกณฑ์ที่คุณจะปฏิบัติตามระหว่างการดำเนินการโครงการ
ขั้นตอน 1: ระบุการตัดสินใจที่อาจจำเป็นต้องได้รับการอนุมัติ
ระบุการตัดสินใจที่อาจส่งผลต่องบประมาณ ขอบเขต การส่งมอบ หรือประโยชน์ที่คาดการณ์ไว้ของโครงการ รวมถึงการอนุมัติที่วางแผนไว้ เช่น การอนุญาตให้เริ่มขั้นตอนต่อไป และการตัดสินใจที่เกิดจากการเปลี่ยนแปลง เช่น การตัดสินใจว่าจะดำเนินการต่อหรือไม่เมื่อกรณีธุรกิจเปลี่ยนแปลง
สำหรับทุกการตัดสินใจ ให้บันทึก:
- Trigger: เงื่อนไขที่ทำให้การตัดสินใจเป็นสิ่งจำเป็น
- หลักฐาน: ข้อมูลที่จำเป็นสำหรับการประเมินตัวเลือกต่าง ๆ
- กำหนดเวลา: เวลาล่าสุดที่สามารถตัดสินใจได้ก่อนที่ตัวเลือกจะลดลงหรือส่งผลต่อการส่งมอบ
ปล่อยให้ผู้ที่รับผิดชอบงานเป็นผู้ตัดสินใจในเรื่องงานประจำ
อ่านเพิ่มเติม: วิธีเขียนเอกสารกำหนดโครงการ (พร้อมตัวอย่าง)
ขั้นตอนที่ 2: กำหนดขอบเขตความยอมรับได้สำหรับค่าใช้จ่าย กำหนดเวลา ขอบเขตงาน และความเสี่ยง
ค่าความคลาดเคลื่อนกำหนดว่าผลลัพธ์สามารถแตกต่างจากแผนที่ได้รับการอนุมัติได้มากเพียงใดภายในขอบเขตอำนาจที่มีอยู่ ให้ตกลงเกี่ยวกับขีดจำกัดเหล่านี้กับผู้สนับสนุนหรือคณะกรรมการกำกับดูแลก่อนเริ่มงาน
โครงการของคุณมีงบประมาณที่ได้รับการอนุมัติจำนวน $420,000 ผู้สนับสนุนกำหนดขอบเขตความคลาดเคลื่อนของค่าใช้จ่ายไว้ที่ 5% และให้สิทธิ์คุณใช้เงินเพิ่มเติม $21,000 ทำให้วงเงินการใช้จ่ายของคุณเพิ่มขึ้นเป็น $441,000 การคาดการณ์ค่าใช้จ่ายที่ $440,000 ยังอยู่ภายในวงเงินที่ได้รับอนุมัติ หากการคาดการณ์เพิ่มขึ้นเป็น $448,000 ให้ขอความเห็นชอบจากผู้สนับสนุนก่อนที่จะดำเนินการใช้จ่ายเพิ่มเติม
กำหนดข้อจำกัดอื่นๆ ให้ชัดเจนเช่นกัน:
- กำหนดเวลา: วันที่เสร็จสิ้นสามารถเลื่อนได้มากเพียงใดก่อนที่จะต้องได้รับการอนุมัติ
- ขอบเขต: ข้อกำหนดหรือผลลัพธ์ที่ท่านสามารถเปลี่ยนแปลงได้ภายในอำนาจของท่าน
- ความเสี่ยง: ระดับความเสี่ยงที่คุณสามารถยอมรับได้ และเหตุการณ์ที่จำเป็นต้องได้รับการตรวจสอบทันที
เชื่อมโยงแต่ละระดับความทนทานกับแผนที่มันครอบคลุมแผนการจัดการความเสี่ยงสามารถช่วยคุณกำหนดระดับขีดจำกัดความเสี่ยงได้ ทั้งนี้ขึ้นอยู่กับโครงการ คุณอาจจำเป็นต้องกำหนดขีดจำกัดที่ชัดเจนสำหรับคุณภาพ ประโยชน์ หรือความยั่งยืนด้วย
ขั้นตอนที่ 3: มอบสิทธิ์การตัดสินใจให้กับบุคคลที่ได้รับการแต่งตั้ง
กลับไปยังรายชื่อการตัดสินใจของคุณ และกำหนดผู้อนุมัติสำหรับแต่ละข้อ จากนั้นระบุผู้ที่จะเตรียมข้อเสนอแนะ และผู้ที่จำเป็นต้องให้ข้อมูลเพิ่มเติม
แยกความรับผิดชอบเหล่านี้ออก:
- ผู้รับผิดชอบข้อเสนอแนะ: รวบรวมข้อมูลหลักฐาน ประเมินทางเลือก และเสนอแนวทางแก้ไข
- ผู้อนุมัติ: อนุมัติหรือปฏิเสธข้อเสนอภายในขอบเขตอำนาจที่ได้รับมอบหมาย
- ผู้ให้คำปรึกษา: ให้ความรู้ความเชี่ยวชาญหรืออธิบายว่าการตัดสินใจดังกล่าวจะส่งผลต่องานของพวกเขาอย่างไร
สำหรับการตัดสินใจของคณะกรรมการ ให้บันทึกไว้ว่ากระบวนการบรรลุข้อตกลงเป็นอย่างไร และใครเป็นผู้บันทึกผลการตัดสินใจ นอกจากนี้ ให้กำหนดผู้แทนที่มีอำนาจ พร้อมด้วยกฎเกณฑ์ที่ชัดเจนว่าเมื่อใดผู้แทนดังกล่าวสามารถเข้าดำเนินการแทนได้
ขั้นตอนที่ 4: กำหนดเส้นทางการส่งต่อปัญหาและเวลาตอบสนอง
การส่งเรื่องขึ้นระดับสูงควรให้ข้อมูลที่เพียงพอแก่ผู้อนุมัติเพื่อตัดสินใจ ใช้รายงานข้อยกเว้นแบบสั้นที่ครอบคลุม:
- ขีดจำกัดที่ตกลงกันและคาดการณ์ล่าสุด
- ผลกระทบที่อาจเกิดขึ้นต่อโครงการ
- ตัวเลือกที่มีอยู่และคำแนะนำของคุณ
- กำหนดเวลาสำหรับการตัดสินใจ
กำหนดเวลาตอบกลับให้สอดคล้องกับช่วงเวลาที่คุณต้องดำเนินการ หากผู้จัดหาต้องการคำตอบในวันศุกร์ การขอการอนุมัติก่อนวันพฤหัสบดีจะให้เวลาเพียงพอสำหรับการดำเนินการตามการตัดสินใจ
นอกจากนี้ ให้กำหนดว่าจะดำเนินการอย่างไรหากไม่ทันกำหนดเวลา ระบุผู้ติดต่อที่ได้รับมอบหมายต่อไป และกำหนดว่างานที่ได้รับผลกระทบต้องหยุดชั่วคราวหรือไม่แม่แบบแมทริกซ์การยกระดับปัญหาเหล่านี้ให้รูปแบบเริ่มต้นที่คุณสามารถปรับให้เหมาะสมกับกระบวนการอนุมัติของโครงการของคุณ
ขั้นตอนที่ 5: ทำให้การตัดสินใจที่ยังค้างอยู่สามารถค้นหาได้ง่าย
ให้ผู้อนุมัติสามารถเห็นภาพรวมของคำขอที่รอการพิจารณาของพวกเขาได้ แต่ละรายการควรแสดงว่าเรื่องใดต้องการการตัดสินใจ ผู้รับผิดชอบคือใคร และกำหนดเวลาเสร็จสิ้นเมื่อใด สำหรับกรณีข้อยกเว้น ให้รวมการคาดการณ์และขีดจำกัดความเสี่ยงไว้ด้วย ให้เก็บหลักฐานสนับสนุนที่เชื่อมโยงกับคำขอไว้ เพื่อให้ผู้อนุมัติสามารถตรวจสอบการประมาณการ ผลกระทบ และตัวเลือกต่าง ๆ ได้
มุมมองแบบเรียลไทม์ เช่นในตัวอย่างแดชบอร์ดโครงการเหล่านี้ สามารถช่วยคุณติดตามคำขอเมื่อสถานการณ์เปลี่ยนแปลงได้รายงานสถานะประจำยังคงสามารถครอบคลุมจุดสำคัญและความคืบหน้าได้ แต่ไม่ควรซ่อนคำขออนุมัติไว้ในส่วนอัปเดตงาน
คุณสามารถสร้างแดชบอร์ดโครงการที่รวมกำหนดเวลา ปัญหาที่ขัดขวาง และตัวชี้วัดประสิทธิภาพไว้ในหน้าจอเดียวได้ภายในเวลาไม่ถึง 15 นาที นี่คือคู่มือสั้นๆ เพื่อช่วยคุณเริ่มต้น:
ขั้นตอนที่ 6: บันทึกการตัดสินใจและทบทวนกรอบงาน
บันทึกการตัดสินใจทุกครั้งเมื่อมีการตัดสินใจ รวมถึงผู้อนุมัติ วันที่ ตัวเลือกที่พิจารณา เหตุผล และขั้นตอนการติดตามผล
การอนุมัติอาจจำเป็นต้องปรับเปลี่ยนงบประมาณ กำหนดเวลา หรือขอบเขตงานพื้นฐาน ให้ดำเนินการปรับเปลี่ยนดังกล่าวผ่านกระบวนการควบคุมการเปลี่ยนแปลง เชื่อมโยงบันทึกที่แก้ไขแล้วกับบันทึกการตัดสินใจ และแจ้งให้ทุกคนที่เกี่ยวข้องทราบว่าพวกเขากำลังทำงานตามแผนใดในขณะนี้
ในการทบทวนแต่ละขั้นตอน ให้ประเมินว่ากรอบงานดังกล่าวช่วยให้คุณตัดสินใจได้ทันเวลาหรือไม่:
- ผู้อนุมัติได้ตอบกลับก่อนที่จะต้องดำเนินการหรือไม่?
- ความรับผิดชอบและขอบเขตการอนุมัติชัดเจนหรือไม่?
- การเปลี่ยนแปลงตามขั้นตอนปกติได้ก่อให้เกิดการยกระดับปัญหาที่ไม่จำเป็นหรือไม่?
- มีข้อกังวลสำคัญใดที่ถูกยกขึ้นช้าเกินไปหรือไม่?
ใช้คำตอบเพื่อเสนอการเปลี่ยนแปลงต่อกรอบงานดังกล่าว การปรับเปลี่ยนระดับความทนทานหรือสิทธิในการตัดสินใจที่ได้รับการปรับปรุงแล้ว ก็จำเป็นต้องได้รับการอนุมัติเช่นกัน เมื่อได้รับการตกลงแล้ว ให้เผยแพร่ข้อมูลดังกล่าวผ่านแผนการสื่อสารก่อนที่จะเริ่มขั้นตอนต่อไป
โครงการของคุณต้องการการกำกับดูแลในระดับใด?
หกขั้นตอนดังกล่าวสามารถนำไปใช้กับโครงการใดก็ได้ แต่ระดับการกำกับดูแลควรสอดคล้องกับค่าใช้จ่าย ความเสี่ยง ความพึ่งพา และผลที่ตามมาจากการตัดสินใจที่ผิดพลาด PRINCE2 เรียกว่าปรับให้เหมาะสมกับโครงการ
ตัวอย่างเช่น โครงการนำร่องที่มีเพียงทีมเดียวอาจต้องการเพียงผู้สนับสนุนและขั้นตอนการอนุมัติที่ชัดเจนเท่านั้น แต่หากโครงการเริ่มจัดการข้อมูลการชำระเงิน คุณอาจจำเป็นต้องมีการตรวจสอบความปลอดภัยอย่างเป็นทางการ แม้ว่าขนาดของทีมจะยังไม่เปลี่ยนแปลง
ตารางด้านล่างนี้เป็นจุดเริ่มต้นสำหรับการเลือกโครงสร้างของคุณ โปรดพิจารณาขนาดในตารางเป็นตัวอย่างเท่านั้น ไม่ใช่กฎตายตัวที่ขึ้นอยู่กับจำนวนสมาชิกในทีมหรือระยะเวลาของโครงการ
| ขนาด | โปรไฟล์ทั่วไป | บทบาทในการกำกับดูแล | การรายงาน | มาตรการควบคุม |
|---|---|---|---|---|
| ขนาดเล็ก | ทีมเดียว งานที่มีความเสี่ยงต่ำ ความพึ่งพาที่น้อย | ผู้สนับสนุนและผู้จัดการโครงการ | อัปเดตสั้นๆ ตามจุดที่ตกลงกันไว้; แจ้งข้อยกเว้นทันทีเมื่อเกิดขึ้น | ขีดจำกัดการอนุมัติและบันทึกการตัดสินใจที่เรียบง่าย |
| Medium | มีหลายทีมหรือผู้รับจ้าง, ทรัพยากรที่ใช้ร่วมกัน, ผลกระทบต่อธุรกิจอยู่ในระดับปานกลาง | ผู้สนับสนุน, ผู้จัดการโครงการ และกลุ่มกำกับดูแล (หากจำเป็น) | การตรวจสอบความคืบหน้าอย่างสม่ำเสมอ; การขอข้อยกเว้นตามความจำเป็น | RACI, บันทึกความเสี่ยง, การอนุมัติการเปลี่ยนแปลง และการทบทวนในแต่ละขั้นตอน |
| ขนาดใหญ่ | ความเสี่ยงทางการเงินสูง ความสัมพันธ์ที่ซับซ้อน หรืองานที่อยู่ภายใต้การกำกับดูแล | ผู้สนับสนุน, คณะกรรมการกำกับดูแล, และ PMO หรือหน่วยงานตรวจสอบอิสระตามความจำเป็น | การตรวจสอบความคืบหน้าอย่างสม่ำเสมอและการส่งต่อปัญหาอย่างรวดเร็ว | ขั้นตอนการอนุมัติอย่างเป็นทางการ (stage gates), การควบคุมการเปลี่ยนแปลง, บันทึกการตรวจสอบ (audit trail), และการตรวจสอบอย่างอิสระเมื่อจำเป็น |
ควรตั้งเป้าหมายให้โครงสร้างการบริหารโครงการเป็นแบบที่เรียบง่ายที่สุด แต่ยังคงให้ผู้ตัดสินใจมีข้อมูลและอำนาจเพียงพอที่จะดำเนินการได้ บันทึกการตัดสินใจของคุณไว้ในเอกสารกำหนดโครงการ (Project Charter) แล้วทบทวนอีกครั้งหากขอบเขตหรือความเสี่ยงมีการเปลี่ยนแปลง
การบริหารจัดการโครงการในปฏิบัติ: การเปิดตัวระบบ CRM ของมหาวิทยาลัยแมนเชสเตอร์
ศูนย์นวัตกรรมวิศวกรรมกราฟีน (Graphene Engineering Innovation Centre) ของมหาวิทยาลัยแมนเชสเตอร์ต้องการระบบ CRM เพื่อติดตามคำสอบถามและจัดการกระบวนการรับลูกค้าใหม่ CEO เป็นผู้ริเริ่มโครงการ ผู้อำนวยการฝ่ายพัฒนาธุรกิจเป็นประธานคณะกรรมการโครงการ และผู้จัดการโครงการ Nathan Lumb เป็นผู้รับผิดชอบการดำเนินการ
ทีมได้กำหนดเพดานค่าใช้จ่ายซอฟต์แวร์ไว้ที่ 20 ปอนด์ต่อผู้ใช้ต่อเดือน และต้องการการสนับสนุนสำหรับผู้ใช้สูงสุด 50 คนกรณีศึกษาที่เผยแพร่แล้วอธิบายว่ากระบวนการอนุมัติและการทบทวนในแต่ละขั้นตอนได้ส่งผลต่อการดำเนินงานอย่างไร:
- กำหนดความต้องการก่อนซื้อ Lumb ได้เตรียมเอกสารสรุปโครงการและแผนคร่าวๆ เพื่อขออนุมัติ หลังจากนั้น ผู้มีส่วนได้ส่วนเสียได้ตกลงกันเกี่ยวกับกระบวนการรับลูกค้าใหม่ ก่อนที่ทีมจะจัดซื้อระบบ CRM
- กำหนดจุดตรวจสอบสำหรับการส่งมอบ ทีมได้จัดแบ่งกระบวนการจัดซื้อ การกำหนดค่า การทดสอบ การปรับใช้ และการส่งมอบเป็นขั้นตอนต่าง ๆ ผู้มีส่วนได้ส่วนเสียได้ตรวจสอบแผนและตกลงกันเกี่ยวกับระบบรายงานและชุดงาน
- แก้ไขปัญหาความล่าช้าในการอนุมัติ ความเห็นที่ขัดแย้งกันของผู้มีส่วนได้ส่วนเสียทำให้การตกลงกันเกี่ยวกับกระบวนการล่าช้า Lumb จึงกำหนดกำหนดเวลาสำหรับการรับข้อเสนอแนะและการอนุมัติเพื่อนำไปสู่การตัดสินใจ
- จัดการการตรวจสอบความปลอดภัย ฝ่าย IT ได้ตั้งคำถามเกี่ยวกับความปลอดภัยของระบบบนคลาวด์ ซึ่งทำให้การอนุมัติการจัดซื้อถูกเลื่อนออกไป ทีมได้ตอบคำถามของฝ่าย IT และรอการอนุมัติ ผู้จัดการโครงการได้จัดการปัญหานี้โดยไม่ขอปรับแผนขั้นตอนใหม่ เนื่องจากคำตอบที่ให้อยู่ภายในแผนที่คณะกรรมการได้อนุมัติไว้แล้ว
- ใช้ข้อเสนอแนะระหว่างการนำระบบไปใช้ การตอบสนองที่ล่าช้าจากผู้ขายทำให้ผู้ใช้ต้องรอคำตอบ ทีมงานได้จัดทำบันทึกบทเรียน แบ่งปันคำตอบทุกสัปดาห์ และจัดฝึกอบรมเพิ่มเติม
เมื่อการกำกับดูแลต้องการหลักฐานที่ชัดเจนยิ่งขึ้น: Crossrail
โครงการ Crossrail แสดงให้เห็นถึงปัญหาด้านการกำกับดูแลที่แตกต่างออกไป: ผู้นำมีหน้าที่กำกับดูแลอย่างเป็นทางการ แต่ขาดแผนการดำเนินการที่เป็นจริง
ตามรายงานปี 2019 ของสำนักงานตรวจบัญชีแห่งชาติ:
- 2010: แพ็กเกจการสนับสนุนทางการเงินที่ประกาศไว้มีมูลค่า 14.8 พันล้านปอนด์
- ตั้งแต่ปี 2015: ปัญหาเริ่มปรากฏขึ้น แต่โครงการยังคงดำเนินการตามแผนเพื่อเปิดส่วนกลางในเดือนธันวาคม 2018
- สิงหาคม 2018: Crossrail ประกาศว่าจะไม่สามารถเปิดบริการตามกำหนดการเดิมได้
- เดือนธันวาคม 2018: แพ็กเกจการจัดหาเงินทุนเพิ่มขึ้นเป็น 17.6 พันล้านปอนด์ ซึ่งสูงกว่าระดับปี 2010 ถึง 2.8 พันล้านปอนด์
NAO ระบุว่าการกำหนดเวลาที่แน่นเกินไป การจัดสัญญา และการขาดแผนงานที่เป็นจริง เป็นหนึ่งในสาเหตุของค่าใช้จ่ายเพิ่มเติม ข้อสรุปของ NAO ชัดเจนว่า Crossrail “ยังคงยึดมั่นในมุมมองที่ไม่สมจริงว่าสามารถเสร็จสิ้นโครงการตามกำหนดเวลาเดิมได้”
ข้อสรุป: ตัวอย่างจากมหาวิทยาลัยแมนเชสเตอร์แสดงให้เห็นว่าขั้นตอนที่ตกลงกันและเส้นทางการอนุมัติช่วยนำทางการดำเนินการโครงการอย่างไร ส่วนโครงการ Crossrail แสดงให้เห็นว่าทำไมการควบคุมดังกล่าวจึงจำเป็นต้องมีการคาดการณ์ที่น่าเชื่อถือด้วย: ผู้ตัดสินใจไม่สามารถประเมินได้ว่าควรดำเนินการตามแผนต่อไปหรือไม่ หากกำหนดเวลาที่รายงานมาไม่เป็นจริง
ระบบการบริหารโครงการทำงานอย่างไรในทีมแบบ Agile?
ทีม Agile จำเป็นต้องมีพื้นที่เพื่อปรับลำดับความสำคัญตามการเรียนรู้ การกำกับดูแลกำหนดเป้าหมาย งบประมาณ และขอบเขตการอนุมัติ ที่ทีมสามารถใช้เพื่อตัดสินใจในเรื่องเหล่านั้น
ใน Scrum ผู้เป็นเจ้าของผลิตภัณฑ์ (Product Owner) จะจัดลำดับความสำคัญของ Product Backlog ส่วนผู้พัฒนาจะวางแผนวิธีการส่งมอบงานที่เลือกไว้สำหรับแต่ละ Sprint ระหว่างการทบทวน Sprint (Sprint Review) ทีม Scrum และผู้มีส่วนได้ส่วนเสียจะตรวจสอบผลลัพธ์และหารือเกี่ยวกับขั้นตอนต่อไป
การอภิปรายเหล่านี้สามารถเปิดเผยความต้องการทางธุรกิจที่เปลี่ยนแปลงไปหรือความเสี่ยงต่อเป้าหมายผลิตภัณฑ์ได้ อย่างไรก็ตาม การทบทวนสปรินต์ (Sprint Review) ไม่สามารถแทนที่การอนุมัติงบประมาณเพิ่มเติมหรือการเปลี่ยนแปลงที่เกินอำนาจของทีมได้
ตัวอย่างเช่น ข้อเสนอแนะจากผู้ใช้แสดงให้เห็นว่าขั้นตอนการชำระเงินของแอปนั้นสับสน Product Owner สามารถจัดลำดับการปรับปรุงขั้นตอนการชำระเงินให้ขึ้นสูงในรายการงานที่รอทำ (backlog) ได้ หากการเปลี่ยนแปลงดังกล่าวต้องการงบประมาณเพิ่มเติม หรืออาจทำให้การส่งมอบล่าช้าเกินกำหนดที่ตกลงกันไว้ ทีมต้องได้รับการอนุมัติผ่านกระบวนการกำกับดูแลโครงการ
ข้อผิดพลาดทั่วไปในการบริหารจัดการโครงการและวิธีแก้ไข
การได้รับอนุมัติไม่เสมอไปหมายความว่าการดำเนินการจะดำเนินไปอย่างราบรื่น ผู้ตรวจสอบอาจไม่สังเกตเห็นช่องว่างในหลักฐาน มองข้ามข้อกังวลจากผู้ใช้ หรืออนุมัติงานด้วยเงื่อนไขที่ไม่มีใครสังเกตเห็น
โปรดระวัง 5 ข้อผิดพลาดต่อไปนี้ เมื่อคุณนำกรอบงานไปใช้ในปฏิบัติ:
| ข้อผิดพลาด | วิธีแก้ไข |
|---|---|
| การทบทวนในแต่ละขั้นตอนกลายเป็นเพียงพิธีการ | กำหนดข้อกำหนดที่ชัดเจนสำหรับการก้าวสู่ขั้นตอนต่อไป เช่น การผ่านการทดสอบของผู้ใช้และการแก้ไขข้อบกพร่องที่สำคัญ ผู้ตรวจสอบควรตัดสินใจว่าจะอนุมัติ อนุมัติพร้อมเงื่อนไข หรือระงับงานจนกว่าข้อบกพร่องจะได้รับการแก้ไข |
| ผู้ใช้ได้รับการปรึกษาช้าเกินไป | ให้ผู้ที่จะเป็นผู้ใช้หรือผู้จัดการผลลัพธ์เข้าร่วมในขั้นตอนการทบทวนการออกแบบและการรับมอบ สำหรับการนำระบบ CRM มาใช้ ให้ขอให้ฝ่ายปฏิบัติการขายตรวจสอบกระบวนการทำงานและสนามข้อมูลก่อนการอนุมัติการออกแบบ บันทึกข้อกังวลที่ยังไม่ได้รับการแก้ไข และมอบหมายให้บุคคลรับผิดชอบในการตอบกลับ |
| สถานะโดยรวมที่แสดงเป็นสีเขียวอาจซ่อนปัญหาในสายงานไว้ | อย่ามองเพียงคะแนนสรุปเท่านั้น โครงการอาจดำเนินตามกำหนดเวลา แต่การบูรณาการที่สำคัญอาจล้มเหลวในการทดสอบ รายงานสายงานหลักแยกกัน พร้อมหลักฐานที่สนับสนุนสถานะของแต่ละส่วน |
| การอนุมัติแบบมีเงื่อนไขจะถือเป็นการอนุมัติอย่างเต็มรูปแบบ | บันทึกทุกเงื่อนไข ผู้รับผิดชอบ และกำหนดเวลาที่ต้องแก้ไข ให้ระบุชัดเจนว่างานใดสามารถดำเนินการต่อได้ และงานใดต้องรอ จากนั้นตรวจสอบให้แน่ใจว่าเงื่อนไขทั้งหมดได้รับการปฏิบัติตามก่อนที่จะปล่อยงานที่ได้รับผลกระทบ |
| ประโยชน์ไม่ได้รับการติดตามหลังจากส่งมอบโครงการ | กำหนดผู้รับผิดชอบทางธุรกิจเพื่อวัดผลลัพธ์หลังการปิดโครงการ และรายงานผลกลับไปยังผู้สนับสนุนโครงการ ตกลงกันเกี่ยวกับตัวชี้วัด วันที่ทบทวน และมาตรการที่จะดำเนินการหากผลลัพธ์ไม่เป็นไปตามเป้าหมาย |
วิธีดำเนินการบริหารจัดการโครงการใน ClickUp
เมื่อการคาดการณ์เกินขีดจำกัดที่ตกลงกันไว้ ผู้สนับสนุนโครงการของคุณต้องการมากกว่าแค่คำเตือน พวกเขาต้องการทราบผลกระทบที่คาดการณ์ได้ ตัวเลือกต่าง ๆ และกำหนดเวลาในการตัดสินใจClickUpช่วยให้คุณเก็บคำขอนี้ไว้พร้อมกับหลักฐานและงานโครงการที่ได้รับผลกระทบ
ให้กฎการอนุมัติอยู่ใกล้กับงาน
เริ่มต้นด้วยแม่แบบแผนการบริหารจัดการ ClickUp ซึ่งรวมถึงมุมมอง “บทบาทและหน้าที่” และสนามข้อมูลที่กำหนดเอง “อำนาจการตัดสินใจ” ที่คุณสามารถปรับให้เหมาะสมกับกระบวนการอนุมัติของคุณได้
ใช้ClickUp Docsเพื่อบันทึกค่าความคลาดเคลื่อน (tolerances) เส้นทางการส่งต่อปัญหา (escalation routes) และเวลาตอบสนอง (response times) เชื่อมโยงแผนงานกับงานที่ต้องได้รับการอนุมัติ (approval tasks) เพื่อให้ผู้ตรวจสอบสามารถตรวจสอบกฎเกณฑ์ที่อยู่เบื้องหลังแต่ละคำขอได้
เปลี่ยนกรณีพิเศษให้เป็นคำขออนุมัติ
จากจุดนั้น คุณสามารถกำหนดขั้นตอนการทำงานสำหรับกรณีที่เกินขอบเขตได้ มาลองนำตัวอย่างจากขั้นตอนที่ 2 มาประยุกต์ใช้กัน โดยผู้จัดการโครงการสามารถอนุมัติการใช้จ่ายได้สูงสุด $441,000
- ติดตามการคาดการณ์: เพิ่มฟิลด์กำหนดเองประเภท "จำนวน" หรือ "เงิน" ลงในงานของโครงการ เพื่อระบุค่าใช้จ่ายรวมที่คาดการณ์
- ส่งข้อยกเว้น: เพิ่มฟิลด์แบบดรอปดาวน์ “ต้องการการอนุมัติ” (Approval Required) ลงในงานของโครงการ เมื่อผู้จัดการโครงการทำเครื่องหมายการคาดการณ์ที่มีมูลค่าเกิน $441,000 เพื่อขอการอนุมัติ ให้ใช้ClickUp Automationเพื่อมอบหมายงานให้กับผู้สนับสนุนโครงการ และเปลี่ยนสถานะของงานเป็น “รอการอนุมัติ” (Pending Approval)
- ตรวจสอบคำขอ: เชื่อมโยงการประมาณราคาของผู้ขายและตัวเลือกที่เสนอเข้ากับงาน ผู้สนับสนุนสามารถตรวจสอบหลักฐาน บันทึกการตัดสินใจ และมอบหมายงานติดตามผล
ให้ผู้สนับสนุนโครงการเห็นภาพรวมของเรื่องที่ยังรอการตัดสินใจ
เพื่อการกำกับดูแลอย่างต่อเนื่องแดชบอร์ดของ ClickUpสามารถรวมข้อมูลทั้งหมดไว้ในมุมมองเดียว ใช้การ์ด Calculation เพื่อแสดงค่าใช้จ่ายที่คาดการณ์ไว้ และการ์ด Task List ที่กรองไว้เฉพาะงานที่รอการอนุมัติ แสดงชื่อผู้รับผิดชอบ กำหนดเวลา และ Custom Fields ที่เกี่ยวข้อง เพื่อให้ผู้สนับสนุนสามารถเปิดแต่ละคำขอและตรวจสอบรายละเอียดได้
เมื่อการเปลี่ยนแปลงที่ได้รับการอนุมัติส่งผลต่อการส่งมอบ ผู้จัดการโครงการสามารถอัปเดตงานและวันที่ที่เกี่ยวข้องได้ โดยไม่สูญเสียเหตุผลเบื้องหลังการตัดสินใจ
สำหรับโครงการขนาดเล็ก แผนการบริหารจัดการและรายการอนุมัติร่วมกันอาจเพียงพอแล้ว เมื่อจำนวนคำขอเพิ่มขึ้น ให้เพิ่มระบบอัตโนมัติและแดชบอร์ด
ราคา ClickUp
ผู้ใช้ ClickUp พูดว่าอย่างไร?
ที่Savills ทีม IT ระดับภูมิภาครับผิดชอบการกำกับดูแลการนำซอฟต์แวร์มาใช้ โครงการโครงสร้างพื้นฐาน และการส่งมอบจากผู้จำหน่ายใน 14 ภูมิภาคในเอเชีย
ก่อน: ผู้จัดการโครงการรวบรวมข้อมูลอัปเดตจากประเทศต่าง ๆ และรวมประมาณ 20 เอกสาร PowerPoint เข้าด้วยกันเพื่อจัดทำรายงาน CIO รายเดือน ผู้นำต้องพึ่งพาวงจรการรายงานดังกล่าวเพื่อรับภาพรวมของโครงการ
ด้วย ClickUp: ข้อมูลโครงการที่แชร์กันจะถูกส่งตรงไปยังแดชบอร์ด CIO แบบเรียลไทม์ ผู้นำสามารถเห็นได้ว่าโครงการใดกำลังดำเนินไปอย่างราบรื่น และโครงการใดต้องการความสนใจ ในขณะที่ทีมทำงานจากข้อมูลเดียวกันเกี่ยวกับคำขอ การเปลี่ยนแปลง และปัญหา
ผลลัพธ์: ทีมโครงการ 10 คนประหยัดเวลาได้มากกว่า 50 ชั่วโมงต่อเดือน โดยจัดการคำถามจากผู้รับจ้างและการส่งต่องานผ่านการหารือเกี่ยวกับงาน ผู้จัดการโครงการใช้เวลาน้อยลงในการประสานงานข้ามเขตเวลาและเตรียมรายงาน ในขณะที่ทีมผู้นำมีภาพรวมที่อัปเดตของพอร์ตโฟลิโอ
เหมาะที่สุดสำหรับ: ทีมข้ามหน้าที่ที่ต้องจัดการกับคำขอเปลี่ยนแปลงและการอนุมัติที่เกิดขึ้นบ่อยครั้ง ซึ่งผู้สนับสนุนโครงการจำเป็นต้องเข้าถึงการคาดการณ์โครงการ เอกสารสนับสนุน และประวัติการตัดสินใจ โดยไม่ต้องตามหาข้อมูลอัปเดตจากทีมต่าง ๆ
ข้ามส่วนนี้ไปหาก: คุณต้องการระบบการบริหารจัดการ ความเสี่ยง และการปฏิบัติตามกฎระเบียบ (GRC) ที่เฉพาะเจาะจง สำหรับการตรวจสอบอย่างเป็นทางการและการควบคุมตามกฎระเบียบ หรือโครงการของคุณมีขนาดเล็กพอที่จะจัดการได้ด้วยเอกสารกำหนดขอบเขตโครงการและบันทึกการตัดสินใจขั้นพื้นฐาน
คุณควรจัดตั้งระบบการกำกับดูแลในระดับใด?
สำหรับโครงการขนาดเล็กที่มีความเสี่ยงต่ำ ซึ่งมีทีมเดียวและผู้ตัดสินใจที่ชัดเจน เอกสารกำหนดขอบเขตโครงการขั้นพื้นฐาน ขีดจำกัดการอนุมัติ และบันทึกการตัดสินใจ อาจเพียงพอแล้ว คุณไม่จำเป็นต้องมีคณะกรรมการกำกับดูแลแยกต่างหากหรือแผนการบริหารจัดการที่ละเอียด
ใช้กรอบงานการบริหารโครงการอย่างเป็นทางการมากขึ้น เมื่อการตัดสินใจเกี่ยวข้องกับหลายแผนก มีค่าใช้จ่ายสูง ส่งผลกระทบต่อข้อบังคับทางกฎหมาย หรืออาจก่อให้เกิดความล่าช้าที่ก่อให้เกิดค่าใช้จ่ายสูง กำหนดผู้อนุมัติ กำหนดเกณฑ์การส่งเรื่องขึ้นระดับสูง และตกลงจุดตรวจสอบก่อนเริ่มงาน
ClickUp ช่วยให้คุณเก็บคำขอการอนุมัติ หลักฐานสนับสนุน และบันทึกการตัดสินใจไว้พร้อมกับโครงการ เพื่อให้ทีมสามารถติดตามได้ว่าอะไรได้รับการอนุมัติและเหตุผลที่อยู่เบื้องหลัง
คำถามที่มักถูกถามเกี่ยวกับการกำกับดูแลโครงการ
ความแตกต่างระหว่างการบริหารจัดการโครงการกับการรับรองคุณภาพโครงการคืออะไร?
การบริหารโครงการกำหนดว่าใครเป็นผู้ตัดสินใจและอำนาจที่พวกเขามี ส่วนการตรวจสอบความมั่นใจในโครงการจะตรวจสอบว่าแผน รายงาน และระบบควบคุมให้ข้อมูลที่น่าเชื่อถือแก่ผู้เกี่ยวข้องหรือไม่ ตัวอย่างเช่น การตรวจสอบความมั่นใจอย่างอิสระอาจประเมินว่าโครงการพร้อมที่จะเริ่มดำเนินการหรือไม่ ก่อนที่คณะกรรมการกำกับดูแลจะตัดสินใจ
คุณจะวัดได้อย่างไรว่าการกำกับดูแลโครงการมีประสิทธิภาพหรือไม่?
ติดตามว่ากระบวนการตัดสินใจอนุมัติใช้เวลานานเท่าใด ความถี่ที่กำหนดเวลาตัดสินใจถูกพลาด และว่าการดำเนินการที่ตกลงกันในการทบทวนแต่ละขั้นตอนได้รับการดำเนินการเสร็จสิ้นตามกำหนดเวลาหรือไม่ คุณยังสามารถตรวจสอบความถี่ที่การเปลี่ยนแปลงถูกดำเนินการโดยไม่ได้รับการอนุมัติที่จำเป็นได้อีกด้วย ทบทวนแนวโน้มเหล่านี้ในแต่ละขั้นตอนของโครงการ เพื่อดูว่าระบบการบริหารจัดการโครงการช่วยให้ทีมตัดสินใจได้อย่างทันเวลาและมีข้อมูลครบถ้วนหรือไม่
จะเกิดอะไรขึ้นหากผู้สนับสนุนโครงการลาออกกลางทาง?
องค์กรควรแต่งตั้งผู้สนับสนุนชั่วคราวหรือผู้แทน และยืนยันอำนาจการตัดสินใจของพวกเขา หลังจากนั้น ผู้จัดการโครงการสามารถรายงานให้พวกเขาทราบเกี่ยวกับกรณีธุรกิจ ความเสี่ยงปัจจุบัน การอนุมัติที่ยังรออยู่ และคำมั่นสัญญาด้านการจัดหาเงินทุน จนกว่าอำนาจจะถูกโอนอย่างเป็นทางการ ทีมไม่ควรสันนิษฐานว่าผู้บริหารคนอื่นสามารถอนุมัติการตัดสินใจเดียวกันได้
ระบบการบริหารจัดการโครงการทำงานร่วมกับผู้รับจ้างภายนอกอย่างไร?
ผู้รับจ้างภายนอกสามารถรายงานความเสี่ยง เสนอการเปลี่ยนแปลง และจัดการงานภายในขอบเขตสัญญาได้ อย่างไรก็ตาม การเปลี่ยนแปลงค่าใช้จ่าย ขอบเขตงาน หรือเงื่อนไขการส่งมอบที่ได้ตกลงกันไว้ ต้องปฏิบัติตามกระบวนการควบคุมการเปลี่ยนแปลงในสัญญาและกฎการอนุมัติขององค์กร กำหนดให้ชัดเจนว่าใครมีสิทธิ์รับมอบผลงาน อนุมัติการเปลี่ยนแปลงสัญญา และแก้ไขข้อพิพาท ก่อนที่ผู้รับจ้างจะเริ่มทำงาน
ความแตกต่างระหว่างจุดสำคัญของโครงการ (project milestone) และจุดตรวจสอบขั้น (stage gate) คืออะไร?
จุดสำคัญ (milestone) หมายถึงเหตุการณ์สำคัญหรือผลลัพธ์ที่เสร็จสิ้นแล้ว เช่น การเสร็จสิ้นการทดสอบผู้ใช้ ส่วนจุดตัดสินใจ (stage gate) คือจุดตัดสินใจที่ผู้มีส่วนได้ส่วนเสียที่มีอำนาจจะตรวจสอบหลักฐานและตัดสินใจว่าโครงการสามารถดำเนินการต่อได้หรือไม่ การบรรลุจุดสำคัญไม่ได้หมายความว่าขั้นตอนถัดไปได้รับการอนุมัติโดยอัตโนมัติ