Project Deliverables คืออะไร?
สิ่งที่โครงการส่งมอบ (Project Deliverables) มีอยู่ 3 แบบ ขึ้นอยู่กับว่าโครงการเรากำลังทำมันเกี่ยวกับอะไร
เราเรียกสิ่งที่โครงการเราส่งมอบไปยังเจ้าของโครงการว่า "Project Deliverable" ซึ่งในทุก ๆ วันของการทำโครงการเราก็จะใช้เวลาส่วนมากไปกับการสร้างหรือพัฒนาเจ้า Project Deliverables เหล่านี้ให้เกิดขึ้นมานั่นแหล่ะ ซึ่งเราแบ่งประเภทของ Project Deliverables ได้ 3 แบบ ขึ้นอยู่กับว่าโครงการของเราเป็นโครงการประเภทไหนและเป้าหมายของโครงการคืออะไร ในบางโครงการเราส่งมอบผลิตภัณฑ์ (Products) ให้กับเจ้าของโครงการ บางโครงการเราส่งมอบการให้บริการ (Services) บางครั้งเราส่งมอบผลลัพธ์ (Results)
ผลิตภัณฑ์ (Products): Project Deliverabes ประเภทนี้เป็นได้ทั้งชิ้นงานที่จับต้องได้และที่จับต้องไม่ได้ ในตัวอย่างของเรา จานบินถือเป็น Project Deliverables ประเภท Products เพราะเราส่งมอบเป็นลำ ๆ ให้กับเจ้าของโครงการ ส่วนซอฟต์แวร์ที่เราใช้ติดตามตำแหน่งของจานบินก็ถือเป็น Products เช่นกัน
ตัวอย่างของ Project Deliverables ประเภทนี้บนโลกของเรา เช่น เว็บไซต์ บ้าน โรงไฟฟ้า รูปปั้นอลังการ ฯลฯ เป็นต้น
การให้บริการ (Services): ในตัวอย่างของเรา การฝึกอบรมช่างซ่อมบำรุงจานบินเป็น Project Deliverables ประเภทนี้
ตัวอย่างอื่น ๆ บนโลกของเรา เช่น การศึกษาผลกระทบด้านสิ่งแวดล้อม การสำรวจตลาด การสร้าง Partnership ให้ระหว่างสองบริษัท การค้นคว้าวิจัย เป็นต้น
ผลลัพธ์ (Results): ถ้าเราบอกว่าในโครงการของเรา ชุมชนบนดาวคูคูมากกว่า 30% ต้องรู้จักโครงการจานบินของเราและให้การสนับสนุน นี่คือตัวอย่างของ Project Deliverables ประเภท Results ที่โครงการของเราต้องส่งมอบ ซึ่งการจะทำให้เกิดผลลัพธ์ปลายทางนี้ขึ้นมา เราอาจจะต้องจัดแคมเปญ โฆษณา ทำกิจกรรม Roadshow อะไรต่าง ๆ
ตัวอย่างอื่น ๆ เช่น คนในประเทศได้รับการศึกษาในระดับมหาวิทยาลัยมากขึ้น 30% กว่าในปัจจุบัน ชุมชนในพื้นที่ห่างไกลมีไฟฟ้าใช้ 100% เป็นต้น
โครงการที่มี Project Deliverables แบบ Results ถือเป็นโครงการที่อาจจะมีความท้าทายมากที่สุด เพราะว่าเราต้องรับผิดชอบในการทำผลลัพธ์ดังกล่าวให้เกิดขึ้นมาไม่ว่าจะโดยการสร้าง Products หรือ Services เพื่อส่งเสริมให้เกิด Results นั้นขึ้น บางครั้ง Results ดังกล่าวจะเกิดขึ้นหรือไม่ขึ้นอยู่กับการเอา Products หรือ Services ไปใช้อย่างเหมาะสมด้วย
โครงการด้านการพัฒนาที่มักดำเนินการโดยองค์กรไม่แสวงหาผลกำไร NGO องค์การด้านการพัฒนาระหว่างประเทศ (เช่น UN ฯลฯ) มักจะมี Project Deliverables ในลักษณะที่เป็น Results
ซึ่งไม่ว่า Project Deliverables คืออะไร สุดท้ายมันจะส่งมอบคุณค่าอะไรบางอย่างให้กับเจ้าของโครงการหรือกลุ่มเป้าหมาย ก่อให้เกิดประโยชน์ (Benefits) ขึ้นมา เช่น โครงการจานบินของเราจะทำให้ชุมชนบนดาวคูคูสามารถเดินทางไปไหนมาไหนได้อย่างสะดวกมากขึ้น
บางครั้งเราไม่ได้ส่งมอบคุณค่าเพียงแค่ครั้งเดียวตอนจบโครงการ เพราะฉะนั้น ผลลัพธ์ระหว่างทางก็ถือเป็น Project Deliverables ได้เหมือนกัน เช่น ซอฟต์แวร์สำหรับติดตามตำแหน่งของจานบินอาจจะแบ่งการส่งมอบเป็น 3 รอบ (เวอร์ชั่น 1, 2 และ 3) ดังนั้น เวอร์ชั่น 3 ถือเป็นสิ่งที่โครงการส่งมอบขั้นสุดท้าย (Final Deliverables) แต่เวอร์ชั่น 1 และ 2 ก็ถือเป็น Project Deliverables ที่โครงการต้องส่งมอบด้วยเช่นกัน
(ดูเรื่องการส่งมอบโครงการแบบต่าง ๆ ใน Delivery Cadence)
เป้าหมายของการส่งมอบโครงการ
Stakeholder ยอมรับและพอใจในสิ่งที่โครงการส่งมอบ
Stakeholders (ผู้มีส่วนได้ส่วนเสีย) มีความพึงพอใจกับ Project Deliverables (สิ่งที่โครงการส่งมอบ) ของเรา โดยเฉพาะเจ้าของโครงการ นั่นก็หมายความว่า Project Deliverables ของเราจะต้องถูกส่งมอบตรงตามขอบเขตที่ตกลงกันไว้ เป็นไปตามความต้องการ และมีคุณภาพในระดับที่เหมาะสม
จานบินที่เราส่งมอบในโครงการตัวอย่างจะต้องเป็นไปตามขอบเขตที่ตกลงกันไว้ คือ 100 ลำ เพราะฉะนั้นเราจะส่งมอบแค่ 90 ลำไม่ได้ (แต่ถ้าเกิน 100 ลำก็อาจจะโอเคนะ) ซึ่งทุก ๆ ลำที่ส่งมอบไปก็จะต้องมีขีดความสามารถเป็นไปตามที่เจ้าของโครงการต้องการ (สามารถเดินทางได้จากฟากนึงของดาวไปยังอีกฝั่งโดยที่ไม่ต้องเติมเชื้อเพลิงระหว่างทาง จุชาวดาวคูคูได้อย่างน้อย 20 คน และสัมภาระอีก 2 ตัน มีเบาะนวดเพื่อความสะดวกสบาย ฯลฯ)
นอกจากนี้ ถึงแม้ว่าเราจะส่งมอบจานบินตามขอบเขตและความต้องการแล้ว เราก็ต้องทำให้มั่นใจว่าจานบินของเรามีคุณภาพที่ดี ไม่ใช่ว่าใช้ ๆ ไปสัก 1 ปีแล้วเจ๊งไปครึ่งนึง กระจกหลุด เครื่องยนต์พังบ่อย ๆ ถ้าเราทำพวกนี้ได้ครบก็น่าจะทำให้ Stakeholders พอใจ
สอดคล้องกับภาพใหญ่
เราทำโครงการภายใต้องค์กรของเรา เพราะฉะนั้น Project Deliverables ต้องสอดคล้องและมีส่วนส่งเสริมนโยบาย ความต้องการ หรือเป้าหมายในระดับสูง ไม่ว่าจะเป็นทั้งในส่วนขององค์กรเรา หรือทางฝั่งเจ้าของโครงการหรือลูกค้าของเราไม่มากก็น้อย
โครงการจานบินของเราควรจะต้องตอบโจทย์ของเป้าหมายและวัตถุประสงค์ของหน่วยงานเรา เช่น เราเป็นบริษัทที่ให้บริการด้านการขนส่งสาธารณะ โครงการจานบินนี้เลยตอบโจทย์ในการขยายตลาดของเรา แต่ถ้าเราเป็นบริษัทด้านโทรคมนาคมขายเทคโนโลยีการสื่อสารแบบไร้สาย การทำโครงการจานบินอาจจะไปทำให้ชาวคูคูลดการใช้ระบบการสื่อสารของเราลงแล้วไปใช้การเดินทางไปมาแทน ถ้าเป็นแบบนี้แปลว่าโครงการจานบินเราจะไปแย้งกับวัตถุประสงค์และเป้าหมายของบริษัทเรา
เกิดการใช้ประโยชน์จริง
Project Deliverables จะถูกนำไปใช้งานต่อโดยเจ้าของโครงการ บางครั้งการใช้งานเกิดขึ้นภายหลังจากที่เราส่งมอบโครงการไปแล้ว ซึ่งการใช้งาน Project Deliverables จะต้องก่อให้เกิด Benefit (ประโยชน์) ขึ้นมา บางครั้งเราอาจจะต้องมี Benefit Realization Plan เพื่อประเมินว่าสิ่งที่โครงการส่งมอบนำไปสู่ประโยชน์ปลายทางจริงรึเปล่า
เมื่อก่อนการทำโครงการจะโฟกัสไปที่ Project Deliverables เป็นหลัก แต่ในระยะหลัง ๆ ได้มีกระแสให้เรามุ่งเน้นมากขึ้นไปยัง Benefits ที่เกิดขึ้นจากการทำโครงการด้วย เราเลยอาจจะต้องมีการเข้าไปประเมินประโยชน์ที่เกิดขึ้นจากการทำโครงการ ซึ่งอาจจะเกิดขึ้นหลังจากที่เราส่งมอบโครงการไปแล้ว อย่างไรก็ตาม เราต้องเข้าใจด้วยว่าการสร้าง Benefits จาก Project Deliverables ขึ้นอยู่กับหลาย ๆ ปัจจัย บางอย่างอยู่นอกเหนือกับความควบคุมของเรา
ในโครงการตัวอย่างของเรา การใช้บริการขนส่งจานบินจะเกิดขึ้นหลังจากที่เราส่งมอบโครงการไปแล้ว ซึ่งสุดท้ายการใช้บริการดังกล่าวควรจะต้องก่อให้เกิดประโยชน์ขึ้นมา เช่น ชุมชนดาวคูคูไปเจอญาติที่อีกฝั่งของโครงการได้บ่อยขึ้น ถ้ากลุ่มเป้าหมายของโครงการเราคือชุมชนบนดาวคูคูทั้งหมด แต่บริการขนส่งจานบินสาธารณะตอบโจทย์เฉพาะแค่คนใน 2 หมู่บ้าน (เพราะมีแต่เส้นทางวิ่งถี่ ๆ แค่ระหว่างสองหมู่บ้านนี้) ก็อาจจะแปลว่าโครงการเราไม่ได้ก่อให้เกิดประโยชน์อย่างแท้จริง
Project Team เข้าใจความต้องการและเป้าหมายปลายทาง
ไม่ว่าจะเป็นโครงการแบบไหนก็ตาม ความเข้าใจ Requirements (ความต้องการ) เป็นสิ่งที่ขาดไม่ได้ ซึ่งไม่ได้แปลว่า Project Manager (ผู้จัดการโครงการ) เข้าใจ Requirements ต่าง ๆ เพียงคนเดียว แต่ Project Team ทุกคนควรที่จะต้องเข้าใจ Requirements เหล่านั้นด้วย รวมถึงสามารถเชื่อมโยงในสิ่งที่ตัวเองทำตรงหน้ากับภาพใหญ่ของโครงการได้
ในโครงการตัวอย่างของเรา Project Team ที่เข้าใจว่าโครงการจานบินสาธารณะทำขึ้นมาเพื่อตอบโจทย์การเดินทางทั้งสองส่วน ทั้งในระยะทางสั้น ๆ และข้ามไปยังอีกฟากของดาว โดยในมุมมองของเจ้าของโครงการ (มาดามเฟลอร์) หมู่บ้านบนภูเขาทางเหนือเป็นจุดที่มีความต้องการมากที่สุดเพราะมีแหล่งปลูกพืชขนาดใหญ่ที่ยังไม่ได้มีการค้าขายกับส่วนอื่น ๆ (บางครั้ง Requirements แบบนี้จะไม่ได้ปรากฎบนเอกสารอะไรแบบชัดเจนโดยตรง ถือเป็น Hidden Requirements หรือความต้องการที่ซ่อนอยู่) เมื่อรู้แล้วเวลาที่ Project Team สามารถตัดสินใจทำอะไรต่าง ๆ ได้สอดคล้องกับเป้าหมายดังกล่าว เช่น โครงการนี้อาจจะมีข้อจำกัดด้านการเงินทำให้ต้องค่อย ๆ แบ่งเฟสทำ ดังนั้นในเฟสแรกเราก็อาจจะหยิบหมู่บ้านบนภูเขาดังกล่าวมาเปิดเส้นทางก่อน แล้วค่อย ๆ ไล่เปิดเส้นทางอื่น ๆ ตามมา)
