Transcript Chapter 14 The Implementation Plan and Project Closure  การน าแผนไปใช้งานและการปิดโครงการ

Chapter 14
 The Implementation Plan and Project Closure
 การนาแผนไปใช้งานและการปิ ดโครงการ
Chapter 14 Objectives
 อธิบายถึงสามแนวทางในการ information implementation and installation: (1)
direct cutover, (2) parallel, และ (3) phased รวมทั้งเปรี ยบเทียบข้อดี ข้อเสี ยของแต่
ละแนวทาง
 อธิ บายถึงกระบวนการต่าง ๆ ที่เกี่ยวข้องกับการปิ ดโครงการเพื่อมัน่ ใจว่า โครงการ
ถูกปิ ดตามขั้นตอนอย่างถูกต้อง
 บ่งชี้การทบทวนหรื อการประเมินโครงการ 4 แนวทาง คือ: (1) individual
performance review, (2) postmortem review, (3) project audit, and (4) evaluation
of the project’s MOV.
Project Implementation
 เน้นที่การติดตั้ง หรื อ การส่ งมอบ project’s major deliverable ซึ่ งก็คือระบบสารสนเทศ
ที่ถูกสร้างขึ้น หรื อ ถูกซื้ อมา
 แผนการดาเนินการ 3 แบบ คือ:
 Direct cutover
 Parallel
 Phased
Direct Cutover
Direct Cutover
 ระบบเก่าถูกปิ ด (shut down) และ ระบบใหม่ถูกเปิ ดใช้งาน (turned on)
 อาจเหมาะสม เมื่อ:
 วิกฤติในเรื่ องส่ งมอบให้เร็ ว (Quick delivery)
 ระบบเก่าแย่และต้องการเปลี่ยนให้เร็ วที่สุด
 ระบบไม่วกิ ฤติต่อภารกิจ
 ความเสี่ ยงของการ direct cutover:
 ไม่ราบรื่ นเสมอไป – เหมือนเดินแบบกายกรรมไต่เชือกที่ไม่มีตาข่ายรองรับ
 ผลอาจเกิด ความล่าช้า ผูใ้ ช้กระวนกระวาย สู ญเสี ยรายได้ พลาด deadlines
 เกิดแรงกดดันและบีบคั้นกับ project team
Parallel
Parallel






ระบบเก่าและระบบใหม่ทางานขนานกัน (run concurrently)
เหมาะสม ถ้าปั ญหาหรื อข้อบกพร่ องของระบบส่ งผลกระทบต่อองค์อย่างมาก
ถือว่ามี safety net หรื อ backup ในกรณี ที่เกิดปั ญหา
สามารถก่อให้เกิดความเชื่อมัน่ ในระบบใหม่
ใช้เวลานานกว่าและทรัพยากรมากกว่าเมื่อเทียบกับแบบ direct cutover
สร้างแรงกดดันให้กบั ผูใ้ ช้มากขึ้น
Phased
Phased
 ระบบถูกนามาใช้เป็ นโมดูลเป็ นกลุ่ม หรื อ ส่ วน ๆ แล้วค่อย ๆ เพิม่ ขึ้น
 ยอมให้ใช้แนวทางการกาหนดกลุ่มและการบริ หารสาหรับการนาโมดูลของระบบมา
ใช้ในต่างแผนกกันหรื อต่างสถานที่กนั
 ประสบการณ์ในอดีตสามารถใช้เป็ นแนวทางและช่วยทาให้การนามาใช้ราบรื่ นมาก
ขึ้น
 ใช้เวลานานและงบประมาณอาจบานปลายเมื่อเทียบกับแนวทางแบบ direct cutover
 ปั ญหาที่เกิดขึ้นในเฟสก่อนหน้าจะส่ งผลกระทบกับเฟสถัดมา และหมายกาหนดการ
โดยรวม
Administrative Closure





ปกติ (Normal) – เป็ นไปตามแผน
ก่อนเวลา (Premature) – ปิ ดก่อน แม้วา่ จะไม่เสร็ จสมบูรณ์
ไม่มีวนั จบ (Perpetual) – ทาไปเรื่ อย ๆ ไม่มีวนั จบ
ล้มเหลว (Failed) – ไม่สาเร็ จ – cost of completion > MOV
เปลี่ยนความสาคัญ (Changed Priority) – เนื่องจาก resource constraints,
misjudged value, needs changes, “ถูกแขวน (starvation)”
Realities of Project Closure






สมาชิกของทีมต้องไปเกี่ยวข้องกับงานที่ถูกมอบหมายไว้ล่วงหน้าแล้ว
ข้อบกพร่ องยังคงมีอยู่ (Bugs still exist)
ทรัพยากรหมด
งานเอกสารจะเป็ นเรื่ องสาคัญ
ถึงวันที่ตอ้ งส่ งมอบ แต่ทาไม่ได้
The players อาจหวงแหน(สิ่ งของ)ด้วยความตกใจ
Project Sponsor Acceptance
 Shortsighted vs. Knowledgeable Sponsors
 โอกาสในการยอมรับโครงการจะเพิม่ ขึ้น เมื่อ:
 Acceptance criteria ถูกกาหนดไว้ชดั เจนใน early stages of project
 Completion of all project deliverables and milestones ทั้งหมดถูกทาเป็ นเอกสาร
Administrative Closure
 The Final Project Report includes
 การสรุ ปโครงการ (Project Summary)
 การเปรี ยบเทียบสิ่ งที่กาหนดไว้ในแผนกับสิ่ งที่เป็ นจริ ง
 เรื่ องที่ยอดเยีย่ ม (Outstanding Issues)
 รายการเอกสารของโครงการทั้งหมด (Project Documentation List)
Administrative Closure
 The Final Meeting and Presentation
 เพื่อเป็ นการสื่ อสารว่า project เสร็ จสิ้ นแล้ว
 ทาการส่ งมอบระบบ (อย่างเป็ นทางการ)จากทีมไปสู่ องค์กร
 รับรู ้วา่ จะต้องช่วยเรื่ องอะไรบ้าง (เมื่อส่ งมอบไปแล้ว)
 Formal signoff
Administrative Closure
 Closing the Project – requirements include:
1. ทวนสอบ สิ่ งที่ตอ้ งส่ งมอบทั้งหมด เรื่ องที่คงั่ ค้าง เสร็ จสิ้ นแล้ว
2. ทวนสอบการยอมรับอย่างเป็ นทางการของโครงการ ของ project sponsor หรื อ
customer
3. เสาะหาและรวบรวม project deliverable ทั้งหมดแล้วทาให้เป็ นเอกสาร
4. วางแผนส่ งมอบทรัพยากรที่ใช้ในโครงการทั้งหมด (เช่น project team members,
technology, equipment, facilities, etc.).
5. วางแผนประเมินและทบทวนสมาชิกของ project team และตัวโครงการ
6. ปิ ด all project accounts.
7. วางแผนเลี้ยงฉลองเพื่อแสดงให้เห็นว่า end of a (successful) project.
Project Evaluation
 Individual Performance Review
 เริ่ มด้วยการประเมินผลงานของแต่ละคน
 หลีกเลี่ยงคาถาม “ทาไมคุณถึงไม่ทาอย่างนั้น อย่างนี้”
 เน้นที่ specific behaviors, not the individual.
 คงเส้นคงวาและยุติธรรม
 การทบทวนควรให้แนวทางในการปรับปรุ งประสิ ทธิภาพการทางาน
Project Evaluation
 Postmortem Review – ระหว่างผูจ้ ดั การโครงการและทีมทาโครงการ
 ทบทวน initial project’s MOV.
 ทบทวน project scope, schedule, budget, และ quality objectives.
 ทบทวนแต่ละ project deliverable
 ทบทวน project plans และ Project Management Body of Knowledge
(PMBOK) areas
 ทบทวน project team performance.
Project Evaluation
 การตรวจประเมินโครงการ (Project Audit)
 ควรทาโดยผูต้ รวจประเมินจากภายนอกองค์กร (outside Auditor) ผูซ้ ่ ึ ง:
 ไม่มีส่วนเกี่ยวข้องหรื อผลประโยชน์กบั โครงการ
 ได้รับการยอมรับจากคนทัว่ ไป ไม่เอนเอียงและยุติธรรม
 เป็ นผูท้ ี่ยนิ ดีที่จะฟัง
 นาเสนอแบบไม่กลัวการโต้แย้งในเรื่ องที่สนใจเป็ นพิเศษ
 ดาเนินการแบบก่อให้เกิดผลประโยชน์สูงสุ ดต่อองค์กร
 มีความรู ้ในโครงการและประสบการณ์ในวงกว้าง
Project Evaluation
 การประเมินความสาเร็ จของโครงการ – The MOV
 โครงการบรรลุ MOV ที่กาหนดไว้หรื อไม่?
 sponsor/customer มีความพึงพอใจหรื อไม่?
 การบริ หารโครงการดีเพียงพอหรื อไม่?
 ผูบ้ ริ หารโครงการและทีมทาตัวเหมาะสมในเชิงนัยแห่ งความเป็ นมืออาชีพ
และจรรยาบรรณหรื อไม่?
 อะไรคือสิ่ งที่ทาถูกต้อง?
 อะไรที่เราสามารถทาให้ดีข้ ึนได้ในครั้งต่อไป?
จบหัวข้อ 14
 คาถาม ………..