เริ่มต้น

หน้าแรก

Unit 8

Project Cost Planning

Unit 9

Monitoring & Control / EVA

Unit 10

Risk Management

Unit 11

Change Management

Unit 12

Project Closure

UML

ER Diagram Class Diagram Sequence Diagram

ทบทวน

Cheat Sheet ข้อสอบรวม

Unit 12 — Project Closure

1. Completion vs Closure

Project CompletionProject Closure
is about the work.is about the outcome.
ตอบคำถาม: "Did we finish building and delivering what we planned?"ตอบคำถาม: "Is this outcome accepted, transitioned, and fully wrapped up so the team can move on cleanly?"
โครงการ complete เมื่องานที่วางแผนไว้ทำเสร็จแล้ว — build ถูก ship, แคมเปญ live, อีเวนต์จัดแล้ว, รายงานวิจัยเสร็จ
  • Tasks ในแผนถูก mark done
  • Deliverables ถูกสร้าง (และมัก deploy/ส่งมอบแล้ว)
  • ทีมหยุด execute งานโครงการได้
 โครงการ closed เมื่อองค์กรเห็นพ้องว่างานเสร็จ และพร้อมให้คนอื่นรับผิดชอบ ดูแล และอ้างอิงในอนาคต
  • Acceptance — stakeholders sign off อย่างเป็นทางการ
  • Handover — ส่งต่อความเป็นเจ้าของให้ทีมที่ถูกต้อง
  • Documentation — บันทึกการตัดสินใจ deliverables และบทเรียน
  • Financial and admin wrap-up — invoices, vendor payments, contracts, access
  • Learning — บันทึก lessons learned ขณะที่ยังจำได้
Project closure is the last phase of a project — PM ยืนยันว่า client/stakeholder/customer ยอมรับ project deliverables แล้ว และถ้าผลิตภัณฑ์ยังใช้งานต่อหลังจบโครงการ ต้องจัดเตรียม maintenance

2. Type of Project Closure — 5 ประเภท

ประเภทความหมายเกิดเมื่อ
Normal Closureปิดตามปกติ บรรลุเป้าหมายและผ่านเกณฑ์การยอมรับทั้งหมดส่งมอบเสร็จ ตรงเวลาและอยู่ในงบ
Premature Closureปิด ก่อนกำหนด แต่ส่งมอบคุณค่าได้เพียงพอบรรลุวัตถุประสงค์เร็วกว่ากำหนด หรือ stakeholders พึงพอใจก่อนโครงการสิ้นสุด
Perpetual Closureโครงการดำเนินต่อไป โดยไม่มีจุดสิ้นสุดที่ชัดเจนเกิด Scope Creep ต่อเนื่อง หรือไม่มีเกณฑ์ชัดเจนว่า "เสร็จ" คือเมื่อใด
Failed Closureถูกยุติเพราะ ไม่สามารถบรรลุวัตถุประสงค์มีอุปสรรคที่แก้ไขหรือเอาชนะไม่ได้
Change Priority Closureสิ้นสุดเพราะ ปัจจัยภายนอกหรือทิศทางองค์กรเปลี่ยนตัดลดงบ ปรับโครงสร้างองค์กร หรือเปลี่ยนลำดับความสำคัญทางธุรกิจ

3. Project Closure Process — 10 ขั้น

1 Deliverable Verification & Client Acceptance 2 Final Project Performance Assessment 3 Financial Closure 4 Documentation & Archiving 5 Resource Release & Reassignment 6 Post Project Evaluation & Lesson Learned 7 Administrative Closure & Legal Requirements 8 Stakeholder Communication & Final Project Report 9 Celebrating & Recognize Contributions 10 Complete Checklist เริ่มจากลูกค้ายอมรับงาน จบด้วยการเช็ก checklist ให้ครบ
Project Closure Process 10 ขั้น
#ขั้นทำอะไร
1Deliverable Verification & Client Acceptanceตรวจว่าผลงานส่งมอบเสร็จสมบูรณ์ตามขอบเขต / ขอ การอนุมัติและยอมรับอย่างเป็นทางการ สำหรับผลงานแต่ละรายการ / จัดการข้อเสนอแนะสุดท้ายจากลูกค้า
2Final Project Performance Assessmentตรวจว่าบรรลุวัตถุประสงค์ภายใต้ ขอบเขต งบประมาณ และระยะเวลา หรือไม่ / ประเมินคุณภาพและความเบี่ยงเบนจากแผน / จัดทำรายงานผลการดำเนินงาน
3Financial Closureตรวจสอบและ กระทบยอด ทางการเงิน / ตรวจว่าใบแจ้งหนี้ส่งครบ ได้รับเงินที่ค้าง และจ่ายผู้ขาย/ผู้รับจ้างแล้ว / เก็บเอกสารการเงินฉบับสุดท้าย
4Documentation & Archivingรวบรวมเอกสาร เช่น สัญญา แผนงาน คำขอเปลี่ยนแปลง รายงาน / ตรวจว่าครบถ้วนและสะท้อนการตัดสินใจถูกต้อง / จัดเก็บอย่างปลอดภัย
5Resource Release & Reassignmentปลดสมาชิกทีมและมอบหมายไปโครงการใหม่ / คืนหรือจัดสรรอุปกรณ์ / แจ้งการสิ้นสุดการใช้ทรัพยากร
6Post Project Evaluation & Lesson Learnedจัดประชุม Lessons Learned ระบุจุดแข็งและสิ่งที่ควรปรับปรุง / บันทึกปัญหาและแนวทางแก้ / ถ่ายทอดให้ทีมอื่นใช้ประโยชน์
7Administrative Closure & Legal Requirementsตรวจสัญญาและข้อกำหนดทางกฎหมายครบ / ยืนยันว่าปฏิบัติตามกฎระเบียบ / ขอ ใบรับรองการปิดโครงการ หรือเอกสารปลดภาระ
8Stakeholder Communication & Final Project Reportจัดทำ Final Project Report / สื่อสารการเสร็จสิ้นอย่างเป็นทางการ / จัดประชุมปิดโครงการและขอบคุณผู้มีส่วนร่วม
9Celebrating Project Completion & Recognize Contributionsเฉลิมฉลองความสำเร็จร่วมกัน / ชื่นชมและยกย่องผลงานของสมาชิก
10Complete Checklistเช็กว่าทุกรายการของการปิดโครงการเสร็จครบ

4. ตัวอย่าง Closure ตามประเภทโครงการ

ประเภทโครงการเริ่มเข้าสู่ Closure เมื่อ
Software Projectfeature ทั้งหมดถูกพัฒนา ทดสอบ และ verify กับ requirements แล้ว
Marketing Campaignกิจกรรมที่วางแผนไว้ เช่น ad placements, promotions, content releases เสร็จครบ
Event Planningอีเวนต์จัดแล้ว และกิจกรรมหลังงาน เช่น จ่ายเงิน vendor, รับ feedback ผู้เข้าร่วม เสร็จแล้ว
Constructionงานก่อสร้างเสร็จ และผ่าน inspections และ acceptance criteria ที่กำหนด
Researchผลการวิจัยถูกเผยแพร่ในรายงาน วารสาร หรือการนำเสนอ

5. User Acceptance Test (UAT)

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

Development SIT UAT Go-Live Sign-off ไม่ผ่าน ส่งกลับให้แก้ไขก่อน Go-Live
UAT เป็นด่านสุดท้ายก่อนขึ้นระบบใช้งานจริง
คำถามคำตอบ
ใครทดสอบ?End user หรือตัวแทนฝ่ายธุรกิจ — ไม่ใช่ทีมพัฒนา ไม่ใช่ทีมงานโครงการ หรือ QA ภายใน
ทดสอบอะไร?Business Scenario จริง ตาม Requirement — ไม่ใช่แค่ฟังก์ชันทีละส่วน
ผลลัพธ์?อนุมัติ (Sign-off) หรือส่งกลับให้แก้ไขก่อน Go-Live

Acceptance Criteria

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

ลักษณะของ Acceptance Criteria ที่ดี (4 ข้อ):

รูปแบบ Given – When – Then

Feature: ระบบชำระเงินผ่าน QR Code
Given:   ลูกค้าเลือกสินค้าในตะกร้าและกดชำระเงิน
When:    ลูกค้าสแกน QR Code และชำระเงินสำเร็จ
Then:    ระบบต้องแสดงสถานะ "ชำระเงินสำเร็จ" ภายใน 3 วินาที
         และส่งอีเมลยืนยันให้ลูกค้าทันที

เอกสารที่ใช้ปิดงาน: Project Completion Template และ Sign-off / Client Acceptance Form

6. Post-Project Maintenance

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

รักษาเสถียรภาพ

ให้ระบบทำงานต่อเนื่องไม่สะดุด

แก้ไขข้อบกพร่อง

จัดการปัญหาที่หลุดรอดจากขั้น Production

อัปเดตให้ทันสมัย

ปรับปรุงความปลอดภัย ความเข้ากันได้กับระบบใหม่

รองรับการเปลี่ยนแปลง

ปรับระบบตามความต้องการของธุรกิจที่เพิ่มขึ้น

4 Types of Software Maintenance (ISO/IEC 14764)

#ประเภทความหมาย
1Correctiveแก้ไขข้อผิดพลาด/Bug ที่พบในขั้น Production
2Adaptiveปรับให้เข้ากับ สภาพแวดล้อมใหม่ เช่น OS, Browser, Laws
3Perfectiveปรับปรุง ประสิทธิภาพ หรือเพิ่ม Feature เล็กน้อย
4Preventiveป้องกันปัญหาในอนาคต เช่น Refactor, อัปเดต Dependency
ข้อควรคำนึง 3 ข้อ:
• SLA (Service Level Agreement) ชัดเจน — Response Time, Resolution Time สำหรับแต่ละระดับความรุนแรง
• ขอบเขตของ Maintenance — ระบุชัดว่าอะไรรวม/ไม่รวมในสัญญา ป้องกันข้อพิพาทภายหลัง
• เอกสาร Handover ครบถ้วน — System Docs, Source Code, Credentials คือกุญแจของ Maintenance ที่ราบรื่น

Warranty Period vs Maintenance Contract

Go-Live (Sign-off) Warranty Period 60-90 วัน (บางโครงการ 6-12 เดือน) Maintenance Contract ดูแลต่อเนื่อง ต่อสัญญารายปี มีค่าใช้จ่าย แก้ bug ฟรี (ไม่รวม Req. ใหม่) สัญญาแยก ลูกค้าเลือกไม่ต่อได้
หลัง Go-Live: Warranty ก่อน แล้วค่อยเข้าสัญญา Maintenance
ช่วง Warrantyหลัง Warranty หมดอายุ
  • แก้ไข bug/error ที่เกิดจากการพัฒนา โดยไม่มีค่าใช้จ่ายเพิ่ม
  • ไม่ครอบคลุม Requirement ใหม่ หรือ Enhancement
  • ระยะเวลาขึ้นกับข้อตกลงในสัญญา (ควรระบุชัดตั้งแต่ต้น)
  • เริ่มนับตั้งแต่วันที่ลูกค้า Sign-off ยอมรับงาน
  • เข้าสู่สัญญา Maintenance/Support แยกต่างหาก
  • มีค่าใช้จ่ายเพิ่มเติมตามรูปแบบที่ตกลง
  • ลูกค้าอาจเลือกไม่ต่อสัญญา ดูแลเอง หรือจ้างทีมอื่น
  • ควรวางแผนล่วงหน้าก่อน Warranty หมดอายุ
ช่วง Warranty มักไม่มีค่าใช้จ่าย เพราะ รวมอยู่ในต้นทุนโครงการตั้งแต่ต้น แต่หลังจากนั้นจะมีค่าใช้จ่ายหลายแบบ

Support Levels

ระดับชื่อทำอะไร
L1Help Desk / Service Deskรับแจ้งปัญหาเบื้องต้น ตอบคำถามการใช้งานทั่วไป และ คัดกรองปัญหาก่อนส่งต่อ
L2Technical Supportแก้ปัญหาทางเทคนิคที่ซับซ้อนขึ้น เช่น Configuration, Integration Issues
L3Development / Engineering Teamแก้ไข Bug ระดับโค้ด ปรับปรุงระบบ และจัดการปัญหาเชิงลึกที่ L1/L2 แก้ไม่ได้

ผู้ทำหน้าที่อาจเป็นทีมพัฒนาเดิม ทีม Maintenance แยก หรือ Outsource ให้บริษัทภายนอก — ขึ้นกับขนาดองค์กร/โครงการ และงบประมาณ

Case Study (Activity จากสไลด์)

บริษัท A พัฒนา Warehouse Management System ให้ลูกค้า B มา 6 เดือน ใกล้กำหนดส่งมอบ:

  • UAT 45/50 Test Case: Pass 45, Fail 3 (ปัญหา UI เล็กน้อย), Pending 2
  • System Documentation เสร็จเพียง 80%
  • Developer หลัก 1 คนกำลังจะย้ายไปโครงการอื่นใน 2 สัปดาห์
  • ลูกค้าต้องการ Go-live ให้ทันกำหนดเดิมเพื่อเปิดสาขาใหม่

แนวคิดตอบ:

  • Sign-off: ทำ conditional sign-off ได้ เพราะ 3 Fail เป็น UI เล็กน้อย ไม่ใช่ business scenario หลัก แต่ต้องปิด 2 Pending และกำหนดวันแก้ 3 Fail ในช่วง Warranty เป็นลายลักษณ์อักษร
  • Closure Checklist ที่ยังไม่พร้อม: Documentation 80%, Pending test 2 case, Knowledge Transfer ของ Developer หลัก
  • Maintenance ช่วง Warranty: ระบุว่าแก้ 3 Fail ฟรี กำหนด SLA ผู้รับผิดชอบ L1–L3 และส่งมอบ Source Code + Credentials
  • สิ่งที่ควรทำต่อ / ปรับปรุง: ทำ Knowledge Transfer ก่อน Developer ย้าย, เร่งเอกสารให้ครบ, ทำ Lessons Learned เรื่องการวางแผนเอกสารให้เสร็จก่อนช่วง UAT
← Change Management บทถัดไป: ER Diagram →