วิธีสร้างแผนโครงการ: 7 ขั้นตอนพร้อมตัวอย่าง

เบนท์ ฟลายบเยิร์ก ได้ศึกษาโครงการ 258 โครงการ ใน 20 ประเทศ ตลอดระยะเวลา 70 ปี9 โครงการ จาก 10 โครงการ มีค่าใช้จ่ายเกินงบประมาณโดยเฉลี่ย ค่าใช้จ่ายสูงกว่าการคาดการณ์ 28%

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

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

คู่มือนี้จะแสดงวิธีการเขียนแผนโครงการในเจ็ดขั้นตอนที่สามารถใช้ได้กับเครื่องมือใด ๆ คุณจะได้เห็นตัวอย่างจากโลกจริงในหลากหลายรูปแบบ เช่น Waterfall, Agile, การตลาด และการก่อสร้าง นอกจากนี้ยังมีการเปรียบเทียบแบบเคียงข้างกันว่าแผนงานถูกใช้งานจริงที่ไหนบ้าง: สเปรดชีต, เอกสารที่แชร์ร่วมกัน และเครื่องมือบริหารโครงการโดยเฉพาะ

แผนโครงการคืออะไร?

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

แผนโครงการที่ไม่ใช่

แผนโครงการไม่ใช่เอกสารกำหนดขอบเขตโครงการ (Charter) เอกสารกำหนดขอบเขตโครงการให้อำนาจและอนุมัติโครงการแก่ผู้จัดการโครงการ และตอบคำถามว่า "เราควรทำสิ่งนี้หรือไม่ และใครเป็นผู้รับผิดชอบ?" แผนโครงการจะเริ่มจากจุดที่เอกสารกำหนดขอบเขตโครงการสิ้นสุดลง และตอบคำถามว่า "จะทำอย่างไร, เมื่อไร, ใครเป็นผู้ทำ, และใช้ค่าใช้จ่ายเท่าใด?"

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

5 ขั้นตอนของแผนโครงการ

แผนโครงการครอบคลุมห้าขั้นตอนที่สถาบันการจัดการโครงการ (PMI)กำหนดให้เป็นวงจรชีวิตของโครงการ: การเริ่มต้น, การวางแผน, การดำเนินการ, การติดตามและควบคุม, และการปิดโครงการ.

แผนงานนี้อยู่ในขั้นตอนการวางแผน แต่ยังคงใช้งานอย่างต่อเนื่องตลอดขั้นตอนการดำเนินการและการติดตามผล แผนงานที่ปิดเมื่อสิ้นสุดขั้นตอนการวางแผนคือแผนงานที่ถูกยกเลิกตั้งแต่เนิ่นๆ

ทำไมแผนโครงการจึงมีความสำคัญ?

ข้ามแผนไป แล้วปัญหาเดิม ๆ ก็ยังคงปรากฏขึ้นอีกการขยายขอบเขตงานเกินกำหนด เพราะไม่มีใครกำหนดขอบเขตไว้ ความขัดแย้งด้านทรัพยากร เพราะสองสายงานอ้างสิทธิ์ในวิศวกรคนเดียวกัน และการพลาดกำหนดส่งงาน เพราะพึ่งพบการพึ่งพาที่ซ่อนอยู่

แผนโครงการช่วยป้องกันความล้มเหลวเหล่านั้นโดยการทำให้งานมองเห็นได้ก่อนเริ่มดำเนินการ

แผนงานเป็นเพียงแนวทางพื้นฐาน ไม่ใช่พิมพ์เขียว

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

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

มีกฎสองข้อที่ตามมา และส่วนที่เหลือของคู่มือนี้ถูกสร้างขึ้นบนพื้นฐานของกฎเหล่านี้:

แนวทางนี้กล่าวถึงสิ่งที่ Flyvbjerg เรียกว่า อคติเชิงบวก: แนวโน้มอย่างเป็นระบบที่ผู้วางแผนมักจะประเมินค่าใช้จ่าย ระยะเวลา และความเสี่ยงต่ำเกินไป ในขณะที่ประเมินผลประโยชน์สูงเกินไป แผนงานที่สร้างขึ้นในฐานะการคาดการณ์แบบคงที่จะสืบทอดอคติดังกล่าวตั้งแต่วันแรกและไม่เคยแก้ไขเลย

องค์ประกอบสำคัญของแผนโครงการ

ทุกแผนโครงการ ไม่ว่าจะอยู่ในระดับสูงหรือละเอียดลึกซึ้ง ล้วนมีองค์ประกอบหลักเดียวกัน รายการด้านล่างนี้ครอบคลุมแต่ละองค์ประกอบและสิ่งที่ควรระบุไว้

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

วิธีเขียนแผนโครงการใน 7 ขั้นตอน

เจ็ดขั้นตอนนี้สามารถใช้งานได้โดยไม่คำนึงถึงวิธีการ: Waterfall, Agile หรือแบบผสมผสาน ลำดับมีความสำคัญเพราะแต่ละขั้นตอนจะเชื่อมโยงกับขั้นตอนถัดไป การข้ามขั้นตอนจะสร้างงานที่ต้องทำซ้ำซึ่งมีค่าใช้จ่ายสูงกว่าการวางแผนอย่างถูกต้องตั้งแต่ครั้งแรก

ขั้นตอนที่ 1: กำหนดเป้าหมายและระบุผู้มีส่วนได้ส่วนเสีย

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

ตัวอย่างเช่น "ออกแบบเว็บไซต์ใหม่" คือภารกิจ. "เพิ่มอัตราการเปลี่ยนแปลงบนหน้าการกำหนดราคาให้ถึง 15% ก่อนไตรมาสที่ 3" คือเป้าหมายที่ช่วยกำหนดการตัดสินใจทุกขั้นตอนต่อไป.

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

ขั้นตอนที่ 2: กำหนดขอบเขตของโครงการและผลลัพธ์ที่ต้องการ

ขอบเขตคือเส้นแบ่งเขต ทุกสิ่งที่อยู่ภายในจะได้รับการจัดสรรทรัพยากรและกำหนดเวลาไว้; ทุกสิ่งที่อยู่นอกเหนือจะถูกเลื่อนออกไปหรือปฏิเสธอย่างชัดเจน การใช้รายการสองคอลัมน์ "อยู่ในขอบเขต/อยู่นอกขอบเขต" จะช่วยป้องกันความคลุมเครือที่อาจทำให้เกิดการขยายขอบเขตในภายหลัง

แยกแยะผลลัพธ์ของโครงการออกจากงาน ผลงานคือผลลัพธ์ที่จับต้องได้ที่ผู้มีส่วนได้ส่วนเสียจะได้รับ: "ฐานข้อมูลที่ย้ายแล้ว," "แบบจำลองการออกแบบที่ได้รับการอนุมัติ," "เอกสารประกอบ API ที่เผยแพร่แล้ว" งานคือสิ่งที่ต้องทำเพื่อผลิตผลงานนั้น ความแตกต่างนี้มีความสำคัญเพราะผู้มีส่วนได้ส่วนเสียให้ความสำคัญกับผลงาน ส่วนทีมของคุณให้ความสำคัญกับงาน

ความล้มเหลวของขอบเขตที่พบบ่อยที่สุด? การเขียนขอบเขตให้กว้างเกินไปจนไม่สามารถใช้ปฏิเสธการเพิ่มเติมได้

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

ขั้นตอนที่ 3: สร้างโครงสร้างการแบ่งงาน

นำแต่ละผลลัพธ์จากขั้นตอนที่ 2 มาแยกย่อยออกเป็นงานย่อยที่เล็กที่สุดซึ่งสามารถมอบหมาย ประเมินเวลา และติดตามได้เป็นรายบุคคล ลำดับชั้นนี้ ได้แก่ โครงการ -> ผลลัพธ์ -> งานย่อย -> งาน เป็นโครงสร้างการแบ่งงาน (WBS) ของคุณ

กฎง่ายๆ ที่มีประโยชน์: หากงานใดใช้เวลานานกว่าสองสามวัน อาจสามารถแบ่งงานออกเป็นส่วนย่อยได้

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

ตัวอย่างเช่น นี่คือลักษณะที่ปรากฏในClickUp:

ขั้นตอนที่ 4: สร้างตารางเวลาและเป้าหมายของโครงการ

นำงานย่อยในแผนผังงาน (WBS) ของคุณมาจัดลำดับขั้นตอน: งานใดที่ต้องรอให้งานอื่นเสร็จก่อน (งานที่ขึ้นต่อกัน) และงานใดที่สามารถดำเนินการไปพร้อมกันได้

หมุดหมายของโครงการเป็นเครื่องหมายแสดงการเสร็จสิ้นของขั้นตอนหรือผลลัพธ์สำคัญ เป็นจุดตรวจสอบ เช่น "เสร็จสิ้นขั้นตอนการออกแบบ" หรือ "ได้รับการอนุมัติจาก UAT แล้ว" ใช้หมุดหมายเหล่านี้เพื่อสร้างจุดทบทวนตามธรรมชาติร่วมกับผู้มีส่วนเกี่ยวข้อง สำหรับโครงการที่มีความซับซ้อน ควรแสดงตารางเวลาในรูปแบบแผนภูมิแกนต์ (Gantt chart) เพื่อให้เห็นความสัมพันธ์ระหว่างงานและเส้นทางวิกฤตได้ชัดเจน

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

ขั้นตอนที่ 5: มอบหมายบทบาทและจัดสรรทรัพยากร

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

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

กรอบงาน RACI(ผู้รับผิดชอบ, ผู้มีอำนาจ, ผู้ให้คำปรึกษา, ผู้ได้รับข้อมูล) ช่วยชี้แจงว่าใครทำอะไรโดยไม่ต้องบันทึกเอกสารมากเกินไป หากโครงการต้องการซอฟต์แวร์ใหม่หรือผู้รับเหมา จะต้องได้รับการอนุมัติควบคู่ไปกับแผนงาน

ขั้นตอนที่ 6: ประเมินความเสี่ยงและวางแผนการสื่อสาร

ระบุสิ่งที่อาจผิดพลาด ประเมินความน่าจะเป็นและผลกระทบของแต่ละความเสี่ยง และบันทึกการตอบสนองสำหรับแต่ละกรณี

บันทึกความเสี่ยงของโครงการที่พบบ่อยในทะเบียนความเสี่ยงเพื่อให้สามารถมองเห็นและรับผิดชอบได้. ตัวอย่างต่อไปนี้.

ขั้นตอนที่ 7: ได้รับการอนุมัติจากผู้มีส่วนได้ส่วนเสียและกำหนดฐานข้อมูลเริ่มต้น

แผนยังไม่เป็นทางการจนกว่าผู้สนับสนุนและผู้มีส่วนได้ส่วนเสียหลักจะให้การอนุมัติอย่างเป็นทางการ การอนุมัตินี้จะสร้างฐานโครงการ: ขอบเขต, กำหนดการ, และงบประมาณที่ได้รับการตกลงไว้ซึ่งจะใช้เป็นเกณฑ์ในการวัดการเปลี่ยนแปลงในอนาคตทั้งหมด

หากไม่มีฐานข้อมูลเริ่มต้น จะไม่มีทางแยกแยะการเปลี่ยนแปลงที่ถูกต้องตามข้อตกลงเดิมได้

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

ตัวอย่างแผนโครงการ

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

ตัวอย่างแผนโครงการแบบน้ำตก

แผนแบบน้ำตก (Waterfall plan) ดำเนินการตามลำดับดังนี้: ความต้องการ, การออกแบบ, การสร้าง, การทดสอบ, การนำไปใช้ แต่ละขั้นตอนจะสิ้นสุดด้วยประตูอย่างเป็นทางการ ผู้มีส่วนได้ส่วนเสียจะตรวจสอบงานและอนุมัติให้ดำเนินการในขั้นตอนต่อไป ไม่มีอะไรจะดำเนินต่อไปได้จนกว่าขั้นตอนก่อนหน้าจะได้รับการอนุมัติแล้ว

ลำดับตัวอย่าง:

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

เหมาะสำหรับ: โครงการที่มีข้อกำหนด กฎเกณฑ์ และข้อบังคับที่แน่นอน หรือทีมภายนอกที่ต้องการขอบเขตงานที่ชัดเจนตายตัว เหมาะสำหรับงานสัญญาภาครัฐ งานที่ต้องปฏิบัติตามข้อกำหนด และงานการผลิต

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

ตัวอย่างแผนโครงการแบบอไจล์

แผนแบบ Agile กำหนดวิสัยทัศน์ของผลิตภัณฑ์, บักค์ล็อกที่มีการจัดอันดับ, จังหวะการสปรินต์ (โดยทั่วไปคือสองสัปดาห์), และบทบาทของทีม แผนรายละเอียดจะเติบโตไปพร้อมกับการสปรินต์แต่ละครั้ง ทีมจะเรียนรู้จากแต่ละรอบและปรับเปลี่ยนตามความเหมาะสม

ลำดับตัวอย่าง:

สิ่งที่ทำให้แตกต่าง: แผนนี้ไม่จำกัดขอบเขตเกินกว่าสปรินต์ถัดไป ผู้มีส่วนได้ส่วนเสียจะเห็นแผนงานเป็น ธีม รายไตรมาส ไม่ใช่รายการผลลัพธ์ที่ต้องส่งมอบตามสปรินต์ การทบทวนย้อนกลับ (retro) คือวงจรรับฟังความคิดเห็น หากขาดสิ่งนี้ Agile จะกลายเป็นขอบเขตงานที่ขยายออกไปเรื่อย ๆ พร้อมขั้นตอนที่เพิ่มขึ้น

เหมาะสำหรับ: โครงการที่มีความต้องการเปลี่ยนแปลงบ่อย, การทำงานที่ขับเคลื่อนด้วยข้อเสนอแนะของลูกค้า, หรือทีมที่ส่งมอบงานเป็นชิ้นเล็ก ๆ Agile เป็นที่นิยมในซอฟต์แวร์, การออกแบบผลิตภัณฑ์, และเครื่องมือภายในองค์กร

ข้ามไปหาก: ผู้มีส่วนได้ส่วนเสียต้องการขอบเขตและวันที่แน่นอนตั้งแต่แรก ความยืดหยุ่นของ Agile จะส่งผลเสียต่อคุณเมื่อสัญญาเป็นแบบตายตัว

ตัวอย่างแผนโครงการแคมเปญการตลาด

แคมเปญการตลาดแบบหลายช่องทางรวบรวมเนื้อหา สื่อโฆษณาแบบชำระเงิน อีเมล และกิจกรรมต่างๆ เข้าด้วยกัน สร้างผลงานสร้างสรรค์พร้อมรอบการตรวจสอบ ประสานงานกับผู้ให้บริการภายนอก (เอเจนซี่ ฟรีแลนซ์) และเปิดตัวทุกช่องทางในวันที่กำหนด

ลำดับตัวอย่าง:

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

ความเสี่ยงที่แตกต่างอีกประการหนึ่ง: ช่องทางต่าง ๆ จะรวมกันในวันที่กำหนด แต่แต่ละช่องทางมีระยะเวลาเตรียมงานที่แตกต่างกัน การพิมพ์ต้องใช้เวลาหกสัปดาห์ โซเชียลมีเดียแบบเสียเงินต้องใช้เวลาสองสัปดาห์ อีเมลต้องใช้เวลาหนึ่งสัปดาห์ หากคุณวางแผนล่วงหน้าจากวันเริ่มต้นโครงการแทนที่จะวางแผนย้อนกลับจากวันเปิดตัว ช่องทางที่ต้องใช้เวลานานจะล่าช้าตั้งแต่วันแรก

เหมาะสำหรับ: การเปิดตัวผลิตภัณฑ์, แคมเปญตามฤดูกาล, การปรับภาพลักษณ์ใหม่, หรืองานใด ๆ ที่มีการจัดส่งผ่านช่องทางมากกว่าสองช่องทางในวันที่เดียวกัน

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

ตัวอย่างแผนโครงการก่อสร้าง

โครงการก่อสร้างดำเนินการภายใต้กฎระเบียบที่เข้มงวด (ใบอนุญาต การตรวจสอบ) และข้อจำกัดทางกายภาพที่เข้มงวด คุณไม่สามารถติดตั้งระบบไฟฟ้าได้ก่อนที่โครงสร้างจะเสร็จสมบูรณ์

ลำดับตัวอย่าง:

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

เหมาะที่สุดสำหรับ: งานใด ๆ ที่มีความพึ่งพาทางกายภาพ ความเสี่ยงจากสภาพอากาศ หรือต้องประสานงานหลายฝ่าย

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

อย่าเริ่มโปรเจกต์ถัดไปของคุณจากหน้ากระดาษเปล่าแม่แบบแผนโครงการระดับสูงของ ClickUpมอบโครงสร้างที่พร้อมใช้งานให้คุณ พร้อมสถานะงาน ช่องข้อมูลที่กำหนดเองสำหรับการติดตามการอนุมัติและการมอบหมายงานแก่ทีม และมุมมองในตัว 5 แบบ รวมถึงไทม์ไลน์และรายการสิ่งที่ต้องส่งมอบ

รับเทมเพลตฟรี

แผนโครงการควรเก็บไว้ที่ไหน?

วิธีการจะกำหนดว่าคุณจะเรียงลำดับงานอย่างไร เครื่องมือจะตัดสินว่าแผนจะอยู่รอดได้เกินสัปดาห์ที่สามหรือไม่ คุณมีสามตัวเลือก

สเปรดชีต (Google Sheets, Excel)

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

สิ่งที่ได้ผล

จุดที่มันแตก

เหมาะที่สุดสำหรับ: โครงการที่มีทีมเดียวและมีงานไม่เกิน 20 งาน โดยมีเจ้าของโครงการที่ชัดเจนเพียงคนเดียว และไม่มีการพึ่งพาซ้อนกัน

ข้ามไปหาก: มีทีมมากกว่าสองทีมที่ต้องประสานงานกัน หรือมีการเปลี่ยนแปลงกำหนดเวลามากกว่าหนึ่งครั้งต่อสัปดาห์

เอกสารที่ใช้ร่วมกัน (Google Docs, Notion, Confluence, ClickUp Docs)

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

สิ่งที่ได้ผล

จุดที่แตก

เหมาะสำหรับ: โครงการระยะสั้น (ไม่เกินหนึ่งเดือน), แผนงานที่มีเนื้อหาเชิงบรรยายมาก หรือใช้เป็น ส่วนหน้า สำหรับระบบติดตามงาน ขอบเขตและผู้ที่เกี่ยวข้องอยู่ในเอกสารนี้ งานต่าง ๆ จะถูกจัดเก็บไว้ที่อื่น

ข้ามไปหาก: คุณต้องการดูว่าใครถูกบล็อกในอะไร วันนี้

เครื่องมือ PM ที่เฉพาะเจาะจง (ClickUp, Asana, Jira, Monday)

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

สิ่งที่ได้ผล

จุดที่มันแตก

เหมาะที่สุดสำหรับ: โครงการที่มีหลายทีมเกี่ยวข้อง มีความสัมพันธ์ซึ่งกันและกันที่เปลี่ยนแปลงได้ และต้องการฐานข้อมูลที่สามารถคงอยู่ได้แม้จะมีการเปลี่ยนแปลงขอบเขต

ข้ามไปหาก: เป็นโครงการง่าย ๆ ที่มีเจ้าของเพียงคนเดียว ทีมงานเดียว ขอบเขตงานชัดเจน และระยะเวลาไม่เกินสามสัปดาห์ การทำเอกสารจะรวดเร็วกว่า

6 เหตุผลที่แผนโครงการล้มเหลว

แผนโครงการส่วนใหญ่สูญเสียแรงผลักดันด้วยเหตุผลที่คาดการณ์ได้

1. การเขียนขอบเขตงานกว้างเกินไปจนไม่สามารถปฏิเสธได้

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

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

2. การขอประมาณการจากผู้จัดการ

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

นักพัฒนาที่กำลังทำงานอยู่รู้ดีว่าจุดที่มีปัญหาอยู่ตรงไหนจริงๆ สร้างแผนงานย่อย (WBS) ร่วมกัน หรือไม่ก็ต้องเตรียมใจที่จะทำงานซ้ำ

3. การสะสมบัฟเฟอร์ทั้งหมดไว้ที่ท้ายสุด

ตารางเวลาที่เพิ่ม "ระยะเผื่อ" สองสัปดาห์ไว้ที่ท้ายโครงการสี่เดือน คือตารางเวลาที่ไม่มีระยะเผื่อจริง ระยะเผื่อนี้จะถูกตัดออกก่อนเป็นอันดับแรกเมื่อมีแรงกดดันเพิ่มขึ้น

เพิ่มเวลาสำรองในแต่ละเฟส โดยเฉพาะในขั้นตอนการทดสอบและตรวจสอบ ซึ่งเป็นช่วงที่มักใช้เวลาสำรองมากที่สุด บัฟเฟอร์ที่อยู่ภายในงานจะยังคงอยู่ ในขณะที่บัฟเฟอร์ที่อยู่ท้ายสุดจะหายไปก่อนที่โครงการจะต้องการใช้

4. การปล่อยให้คำว่า "เสร็จ" ไม่มีการกำหนดความหมาย

เมื่อไม่มีการระบุเกณฑ์การเสร็จสิ้น "เสร็จ" จะมีความหมายแตกต่างกันสำหรับผู้มีส่วนได้ส่วนเสียแต่ละคน:

เขียนความหมายของคำว่า "เสร็จสมบูรณ์" สำหรับแต่ละงานที่ต้องส่งมอบ ระบุเกณฑ์ที่ต้องปฏิบัติตาม รูปแบบที่จะใช้ และผู้ที่จะอนุมัติงานนั้น เกณฑ์ที่ไม่ชัดเจนเป็นสาเหตุหลักของการต้องทำงานซ้ำในช่วงท้ายของโครงการ

5. ปล่อยให้แผนอยู่ในไฟล์แนบอีเมล

แผนที่ไม่มีใครสามารถหาได้ก็เหมือนกับไม่มีแผนเลยในทางปฏิบัติ

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

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

6. การปฏิบัติต่อแผนงานเสมือนเป็นผลงานที่ทำเพียงครั้งเดียว

วิธีบอกที่เร็วที่สุด: วันที่แก้ไขล่าสุดของแผนงานเก่ากว่างานที่คุณเพิ่มล่าสุด หากงานได้ย้ายไปแล้วแต่แผนงานยังไม่ได้เปลี่ยนแปลง แสดงว่าแผนงานไม่ได้ควบคุมโครงการนี้มาสักระยะหนึ่งแล้ว และไม่มีใครสังเกตเห็น

ให้บล็อกเวลา 15 นาทีสำหรับการทบทวนแผนงานในทุกๆ หลักชัย และทุกครั้งที่มีการอนุมัติคำขอเปลี่ยนแปลง จุดประสงค์ไม่ใช่เพื่อเขียนแผนใหม่ทั้งหมด แต่เพื่อยืนยันว่าแผนพื้นฐานยังคงสะท้อนความเป็นจริง หรือเพื่อบันทึกจุดที่ไม่ตรงกับความเป็นจริง

วิธีที่เราสร้างและจัดการแผนงานใน ClickUp

เราไม่เขียนแผนโครงการใน Google Doc แล้วหวังว่าจะได้ผลลัพธ์ที่ดี แผนของเราอยู่ใน ClickUp ติดกับงานที่แผนนั้นอธิบายไว้โดยตรง ด้วยวิธีนี้ แผนจะไม่ล้าสมัย

เอกสารสำหรับขอบเขตและแผนที่ผู้มีส่วนได้ส่วนเสีย (ขั้นตอนที่ 1 และ 2)

ClickUp Docsประกอบด้วยคำชี้แจงขอบเขต, ตัวชี้วัดความสำเร็จ, และตารางผู้มีส่วนได้ส่วนเสีย เนื่องจากเอกสารนี้อยู่ในเวิร์กสเปซเดียวกับงานต่าง ๆ คำถามว่า "สิ่งนี้อยู่ในขอบเขตหรือไม่?" จึงสามารถตอบได้ง่าย เมื่อมีใครเสนอการเปลี่ยนแปลง เราจะชี้ให้พวกเขาดูที่เอกสารเดียวกันที่ผู้สนับสนุนได้อนุมัติไว้แล้ว ไม่ใช่เอกสาร Google Docs ที่สร้างไว้เมื่อสามเดือนก่อน

งานและงานย่อยสำหรับแผนผังงาน (ขั้นตอนที่ 3)

มุมมอง Gantt สำหรับการพึ่งพาและเส้นทางวิกฤต (ขั้นตอนที่ 4)

ลากเส้นระหว่างงานใน<14>มุมมอง Gantt ของ ClickUpเพื่อกำหนดการพึ่งพา งานที่สำคัญที่สุดจะแสดงเป็นเส้นทางวิกฤต และเมื่อมีงานใดล่าช้า งานถัดไปก็จะเลื่อนตามไปด้วย ตารางเวลาจะยังคงสมจริงโดยไม่ต้องมีใครมาสร้างใหม่ด้วยมือ นี่คือจุดที่ล้มเหลวเร็วที่สุดในสเปรดชีต และเป็นเหตุผลที่ทำให้เครื่องมือบริหารโครงการมีบทบาทสำคัญ

แดชบอร์ดสำหรับข้อมูลพื้นฐาน (ขั้นตอนที่ 7)

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

เมื่อ ClickUp ไม่เหมาะกับความต้องการของคุณ

ClickUp สร้างคุณค่าเมื่อโครงการเกี่ยวข้องกับหลายบุคคล, กำหนดเวลาที่เปลี่ยนแปลง, และการส่งต่อข้ามหน้าที่. ยิ่งงานของคุณต้องการการเชื่อมต่อมากเท่าไร, คุณก็จะได้รับคุณค่ามากขึ้นเท่านั้น.

ข้ามไปหาก: คุณเป็นฟรีแลนซ์ที่ต้องติดตามงานส่งเพียงไม่กี่ชิ้น หรือเป็นทีมที่ต้องการโมเดลทางการเงินที่ซับซ้อนและตารางข้อมูลแบบหมุนได้ เอกสารหรือสเปรดชีตแบบง่ายจะเหมาะสมกว่าในที่นี้

สร้างแผนโครงการที่ทีมของคุณจะใช้จริง

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

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

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

สมัครใช้ ClickUpวันนี้!

คำถามที่พบบ่อยเกี่ยวกับแผนโครงการ

ความแตกต่างระหว่างแผนโครงการกับแผนการบริหารโครงการคืออะไร?

แผนโครงการมุ่งเน้นไปที่ผลลัพธ์เฉพาะ, กำหนดเวลา, และทรัพยากรสำหรับโครงการเดียว แผนการจัดการโครงการ (คำศัพท์ของ PMI) มีความกว้างกว่า รวมถึงแผนการจัดการการเปลี่ยนแปลง, ความเสี่ยง, การสื่อสาร, และการจัดซื้อจัดจ้าง แผนย่อย ที่ควบคุมวิธีการจัดการโครงการ สำหรับทีมส่วนใหญ่ที่อยู่นอกสภาพแวดล้อมที่เป็นทางการของ PMI คำว่า "แผนโครงการ" ครอบคลุมทั้งสองอย่าง

คุณสามารถสร้างแผนโครงการได้โดยไม่ต้องใช้ซอฟต์แวร์การจัดการโครงการหรือไม่?

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

อะไรคือเส้นทางวิกฤตในแผนโครงการ?

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

ใครเป็นผู้รับผิดชอบในการสร้างแผนโครงการ?

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

ความแตกต่างระหว่างแผนโครงการกับตารางเวลาโครงการคืออะไร?

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

คุณควรปรับปรุงแผนโครงการบ่อยแค่ไหน?

คุณควรอัปเดตแผนโครงการในทุกๆ จุดสำคัญหลัก และเมื่อใดก็ตามที่มีการอนุมัติคำขอเปลี่ยนแปลง แผนที่สะท้อนสมมติฐานของสัปดาห์แรกในเดือนที่สามจะสร้างความมั่นใจที่ผิดพลาด PMI แนะนำให้มีการทบทวนแผนอย่างเป็นทางการในแต่ละขั้นตอนของโครงการ พร้อมกับการอัปเดตเพิ่มเติมตามความจำเป็นเมื่อความเสี่ยงเกิดขึ้นหรือมีการอนุมัติการเปลี่ยนแปลงขอบเขตผ่านกระบวนการควบคุมการเปลี่ยนแปลง