รายงานวิจัย

การบริหารโครงการเทคโนโลยีสารสนเทศ
Information Technology Project Management

ผศ.ดร. วราภรณ จิรชีพพัฒนา

คณะสถิติประยุกต

ตุลาคม ๒๕๕๑

สถาบันบัณฑิตพัฒนบริหารศาสตร
สถาบันบัณฑิตพัฒนบริหารศาสตร
๑๑๘ ถนนเสรีไทย คลองจัน่ บางกะป
กรุงเทพมหานคร ๑๐๒๔๐
ประเทศไทย

โทร : ๖๖๒-๓๗๕-๘๙๗๒
โทรสาร: ๖๖๒-๓๗๔-๒๗๕๙
E-mail : rcadmin@nida.ac.th

© ๒๕๕๑ โดยสถาบันบัณฑิตพัฒนบริหารศาสตร
สงวนสิทธิ์ : การคัดลอก การจัดเก็บไวในระบบที่จะเรียกกลับมาใชใหม หรือ
การส ง ผ า นในรู ป แบบใด หรื อ วิ ธี ก ารใด ไม ว า ทางไฟฟ า
เครื่องกล การถายสําเนา การอัดเสียง หรือวิธีการอื่นใด ตองขอ
อนุญาตจาก สถาบันบัณฑิตพัฒนบริหารศาสตร
ยกเวน การนํา เสนอที่ป ระชุมทางวิชาการและนํา ไปตีพิม พเผยแพรใ น
วารสารทางวิ ช าการทั้ ง ในประเทศและต า งประเทศ และการ
เผยแพรอื่น ๆ ที่ไมใชการหาผลประโยชนเชิงพาณิชย
ขอความและความคิดเห็นใดในสิ่งพิมพฉบับนี้ เปนของผูเขียน/คณะวิจัย มิใช
ของสถาบันบัณฑิตพัฒนบริหารศาสตร สถาบันบัณฑิตพัฒนบริหารศาสตรขอสงวน
สิทธิ์ที่จะไมรับผิดชอบตอความเสียหายที่เกิดขึ้นกับบุคคลหรือทรัพยสินอันเปนผล
มาจากสิ่งใดในรายงานฉบับนี้
การบริหารโครงการเทคโนโลยีสารสนเทศ
Information Technology Project Management
 อนาคตขององคการขึ้นอยูกบั ความสามารถในการใชเทคโนโลยีสารสนเทศที่องคการทวีการ
ลงทุนอยางมากมาย แตจากผลการดําเนินการกลับพบวาสวนใหญโครงการเทคโนโลยีสารสนเทศไม
ประสบความสําเร็จตามที่องคการคาดหวัง ถึงแมวา สถานการณจะดีขึ้นเรื่อยๆ ก็ตาม การที่สถานการณ
ดีขึ้นเนื่องจากองคการใหความสําคัญกับการบริหารโครงการ ดังนัน้ จึงสงผลใหเกิดความตองการ
ผูจัดการโครงการที่มีความสามารถมากขึน้
สถาบันการศึกษาตางๆ ไดบรรจุวิชา การบริหารโครงการเทคโนโลยีสารสนเทศ ไวในหลักสูตร
ทางดานเทคโนโลยีสารสนเทศ แตตําราการบริหารโครงการสวนใหญจะเนนทางดานบริหาร วิศวกรรม
และเศรษฐศาสตร สวนตําราภาษาไทยสําหรับการบริหารโครงการเทคโนโลยีสารสนเทศมีนอยมาก
ผูเขียนจึงไดเรียบเรียงตํารา ”การบริหารโครงการเทคโนโลยีสารสนเทศ” ตามแนวทางการบริหาร
โครงการที่กําหนดโดย Project Management Institute (PMI) สถาบันแหงนี้ไดกาํ หนดวาคนทีจ่ ะเปน
ผูจัดการโครงการที่มีความสามารถตองมีความรู 9 ดานคือ การบริหารการบูรณาการ การบริหาร
ขอบเขต การบริหารเวลา การบริหารคาใชจาย การบริหารคุณภาพ การบริหารทรัพยากรมนุษย การ
บริหารความเสี่ยง การบริหารการสื่อสาร และการบริหารการจัดซื้อจัดจาง ตําราเลมนี้จงึ เรียบเรียงตาม
องคความรูดังกลาว
ในการเรียบเรียงตําราเลมนี้ ผูเขียนขอขอบคุณ สถาบันบัณฑิตพัฒนบริหารศาสตร ที่
สนับสนุนคาใชจาย คณะกรรมการสงเสริมการวิจยั ของสถาบันที่เห็นความสําคัญของตําราและใหความ
เห็นชอบ ผูอานตนฉบับที่ใหขอเสนอแนะทีเ่ ปนประโยชน
ผูเขียนหวังวาตํารา “การบริหารโครงการเทคโนลียีสารสนเทศ” เลมนี้จะเปนประโยชน
สําหรับนักศึกษาสาขาการจัดการระบบสารสนเทศ วิทยาการคอมพิวเตอร เทคโนโลยีสารสนเทศ และ
สาขาอื่นที่เกีย่ วของในมหาวิทยาลัยตางๆ รวมทั้งบุคคลที่เกี่ยวของกับการบริหารโครงการเทคโนโลยี
สารสนเทศในองคการทัง้ ภาครัฐและเอกชน

คณะสถิติประยุกต วราภรณ จิรชีพพัฒนา

สถาบันบัณฑิตพัฒนบริหารศาตร ตุลาคม 2551
 หนา
คํานํา
1 บทนํา
1.1 สาเหตุความลมเหลวของโครงการ 1-1
1.2 ความหมายของโครงการ 1-2
1.3 ความหมายของการบริหารโครงการ 1-4
1.4 บทบาทของผูจ ัดการโครงการ 1-6
1.5 ซอฟตแวรจัดการโครงการ 1-9
1.6 สรุป 1-10
คําถามทายบท 1-10
2 การบริหารโครงการและบริบทเทคโนโลยีสารสนเทศ
2.1 บทนํา 2-1
2.2 วิธีการเชิงระบบ 2-1
2.3 ตัวแบบวงกลมสามวงสําหรับการบริหารโครงการ 2-2
2.4 ความเขาใจองคการ 2-3
2.5 การบริหารผูมสี วนไดเสีย 2-10
2.6 ขั้นตอนโครงการและวงจรชีวิตของโครงการ 2-11
2.7 วงจรชีวิตการพัฒนาซอฟตแวร 2-13
2.8 วงจรชีวิตของโครงการกับวงจรชีวิตการพัฒนาซอฟตแวร 2-14
2.9 กลุมกระบวนการบริหารโครงการ 2-14
2.10 บริบทของโครงการเทคโนโลยีสารสนเทศ 2-20
2.11 สรุป 2-21
คําถามทายบท 2-22
3 การบริหารการบูรณาการ
3.1 บทนํา 3-1
3.2 การวางแผนเชิงกลยุทธ และการเลือกโครงการ 3-2
3.3 พัฒนาเอกสารสิทธิ์โครงการ 3-11
3.4 กําหนดขอบเขตงานเบื้องตน 3-12
 หนา
3.5 แผนการบริหารโครงการ 3-12
3.6 การปฏิบัติงานโครงการ 3-18
3.7 การติดตามและการควบคุมงานโครงการ 3-20
3.8 การควบคุมการเปลี่ยนแปลงแบบบูรณาการ 3-20
3.9 การปดโครงการ 3-26
3.10 สรุป 3-27
คําถามทายบท 3-27
4 การบริหารขอบเขตโครงการ
4.1 บทนํา 4-1
4.2 การวางแผนขอบเขต และแผนการบริหารขอบเขต 4-2
4.3 การกําหนดขอบเขต และขอกําหนดขอบเขตโครงการ 4-5
4.4 การสรางโครงสรางจําแนกงาน 4-8
4.5 การทวนสอบขอบเขต 4-15
4.6 การควบคุมขอบเขต 4-16
4.7 สรุป 4-18
คําถามทายบท 4-18
5 การบริหารเวลาโครงการ
5.1 บทนํา 5-1
5.2 การกําหนดกิจกรรม 5-2
5.3 การเรียงลําดับกิจกรรม 5-3
5.4 การประมาณการทรัพยากรกิจกรรม 5-7
5.5 การประมาณการชวงระยะเวลากิจกรรม 5-8
5.6 การพัฒนาตารางเวลา 5-10
5.6.1 แผนภูมิแกนต 5-10
5.6.2 วิธีเสนทางวิกฤต 5-13
5.6.3 การจัดตารางเวลาหวงโซวกิ ฤต 5-23
5.6.4 เทคนิคการทบทวนและการประเมินผลการทํางาน: เทคนิค PERT 5-28
5.7 การควบคุมตารางเวลา 5-31
5.8 สรุป 5-33
คําถามทายบท 5-34
 หนา
6 การบริหารคาใชจายโครงการ
6.1 บทนํา 6-1
6.2 การบริหารคาใชจายโครงการคืออะไร 6-1
6.3 การประมาณการคาใชจาย 6-2
6.3.1 เทคนิคและเครื่องมือสําหรับการประมาณการคาใชจาย 6-2
6.3.2 การประมาณการขนาดของซอฟตแวรดวยฟงกชนั พอยท 6-4
6.3.3 การประมาณการแรงงานดวยวิธีโคโคโม 6-19
6.3.4 ปญหาที่พบโดยทั่วไปของการประมาณการคาใชจายดานเทคโนโลยี 6-40
สารสนเทศ
6.3.5 ตัวอยางการประมาณการคาใชจาย 6-41
6.4 การทํางบประมาณคาใชจา ย 6-47
6.5 การควบคุมคาใชจาย 6-48
6.6 สรุป 6-54
คําถามทายบท 6-55
7 การบริหารคุณภาพโครงการ
7.1 บทนํา 7-1
7.2 การบริหารคุณภาพคืออะไร 7-1
7.3 การวางแผนคุณภาพ 7-2
7.4 การประกันคุณภาพ 7-4
7.5 การควบคุมคุณภาพ 7-5
7.6 เครื่องมือ และเทคนิคสําหรับการควบคุมคุณภาพ 7-6
7.6.1 เครื่องมือพืน้ ฐานสําหรับการควบคุมคุณภาพ 7-6
7.6.2 การสุมตัวอยางเชิงสถิติ 7-11
7.6.3 ซิกสซิกมา 7-11
7.6.4 การทดสอบและการทวนสอบ 7-15
7.7 การบริหารคุณภาพสมัยใหม 7-17
7.7.1 การบริหารคุณภาพของเดมมิง 7-17
7.7.2 การบริหารคุณภาพของจูราน 7-20
7.7.3 ครอสบี และขอบกพรองเปนศูนย 7-21
 หนา
7.7.4 อิชิคาวาและวงกลมคุณภาพ 7-23
7.7.5 มาตรฐานไอเอสโอ 7-24
7.8 ตัววัด 7-24
7.9 ตัวแบบวุฒิภาวะความสามารถแบบบูรณาการ 7-32
7.9.1 ตัวแบบที่เปนตัวแทนแบบขัน้ ตอน 7-33
7.9.2 ตัวแบบที่เปนตัวแทนแบบตอเนื่อง 7-37
7.10 การปรับปรุงคุณภาพโครงการเทคโนโลยีสารสนเทศ 7-41
7.11 สรุป 7-43
คําถามทายบท 7-44

8 การบริหารทรัพยากรมนุษยโครงการ
8.1 บทนํา 8-1
8.2 ทฤษฎีในการบริหารคน 8-2
8.2.1 ทฤษฎีการจูงใจ 8-2
8.2.2 ทฤษฎีอํานาจและอิทธิพลของธรรมเฮียนและไวลมอน 8-6
8.2.3 ทฤษฎีการปรับปรุงประสิทธิผลของโควีย 8-8
8.3 การวางแผนทรัพยากรมนุษย 8-10
8.3.1 ผังโครงสรางโครงการ 8-10
8.3.2 การมอบหมายงานใหกับทีมงานยอย 8-13
8.3.3 ตารางการมอบหมายความรับผิดชอบ 8-15
8.3.4 แผนการบริหารกําลังพลและแผนภูมิแทงทรัพยากร 8-15
8.4 การไดทีมงาน 8-16
8.4.1 การคัดเลือกสมาชิกทีมงาน 8-16
8.4.2 การมอบหมายงานใหกับสมาชิก 8-18
8.4.3 การบรรจุทรัพยากร 8-21
8.4.4 การจัดระดับทรัพยากร 8-22
8.4.5 การกําหนดตารางเวลาการใชทรัพยากรภายใตขอจํากัดดานทรัพยากร 8-24
8.5 การพัฒนาทีมงานโครงการ 8-25
8.6 การบริหารทีมงาน 8-28
8.7 สรุป 8-30
 หนา
คําถามทายบท 8-32
9 การบริการการสื่อสารโครงการ
9.1 บทนํา 9-1
9.2 การวางแผนการสื่อสาร 9-2
9.3 การกระจายสารสนเทศ 9-4
9.4 การรายงานการปฏิบัติงาน 9-9
9.5 การบริหารผูมสี วนไดเสีย 9-10
9.6 ขอเสนอแนะสําหรับการปรับปรุงการสื่อสารโครงการใหดขี ึ้น 9-11
9.7 สรุป 9-19
คําถามทายบท 9-20

10 การบริหารความเสี่ยงโครงการ
10.1 บทนํา 10-1
10.2 การวางแผนบริหารความเสีย่ ง 10-2
10.3 ประเภทของความเสีย่ งทางเทคโนโลยีสารสนเทศ 10-4
10.4 การระบุความเสี่ยง 10-7
10.5 การวิเคราะหความเสีย่ งเชิงคุณภาพ 10-11
10.6 การวิเคราะหความเสีย่ งเชิงปริมาณ 10-17
10.7 การวางแผนตอบสนองความเสี่ยง 10-20
10.8 การควบคุมและติดตามความเสี่ยง 10-22
10.9 สรุป 10-23
คําถามทายบท 10-24

11 การบริหารการจัดซื้อจัดจาง
11.1 บทนํา 11-1
11.2 การวางแผนการซื้อและการไดมา 11-2
11.3 การวางแผนการทําสัญญา 11-8
11.4 การรองขอคําตอบจากผูขาย 11-9
11.5 การเลือกผูขาย 11-9
11.6 การบริหารสัญญา 11-10
 หนา
11.7 การปดสัญญา 11-11
11.8 สรุป 11-12
คําถามทายบท 11-13

12 การติดตั้งระบบ การปดโครงการและการประเมิน
12.1 บทนํา 12-1
12.2 การติดตั้งระบบสารสนเทศ 12-1
12.3 การปดโครงการ 12-4
12.4 การประเมินโครงการ 12-10
12.5 สรุป 12-12
คําถามทายบท 12-14

13 การบริหารการเปลี่ยนแปลง
13.1 บทนํา 13-1
13.2 ธรรมชาติของการเปลี่ยนแปลง 13-2
13.3 การวางแผนการบริหารการเปลี่ยนแปลง 13-6
13.4 การจัดการกับความขัดแยงและการตอตาน 13-12
13.5 สรุป 13-15
คําถามทายบท 13-17
บรรณานุกรม
ดัชนี
บทนํา หนา 1-1

1.1 สาเหตุความลมเหลวของโครงการ
แสตนดิสกรุปไดทําการสํารวจความคิดเห็นของผูจัดการโครงการเทคโนโลยีสารสนเทศจํานวน
365 คน โดยไดทํารายงานผลการสํารวจที่เรียกวา CHAOS ในรายงานไดระบุสาเหตุความลมเหลวที่
สําคัญของโครงการมี 5 สาเหตุคือ
• การมีสวนรวมของผูใช ถาผูใ ชมีสวนรวม โอกาสที่โครงการจะประสบความสําเร็จมาก
ขึ้น เนื่องจากผูใชจะใหเวลากับทีมงานเพื่อบอกความตองการ ชวยออกแบบสวน
ประสานกับผูใช (user interface) ชวยทดสอบ รวมทัง้ ชวยทีมงานในชวงการนําระบบ
ไปใชงาน
• การสนับสนุนจากผูบริหาร เนื่องจากการพัฒนาระบบสารสนเทศตองเกี่ยวของกับ
หลาย ๆ หนวยงาน จึงตองมีผูบริหารที่มตี ําแหนงสูง คอยแกปญหาทีอ่ าจจะเกิดขึน้ ได
• ความชัดเจนของความตองการ การเขียนความตองการตองกําหนดขอบเขตของงาน
วามีแคไหน เนื่องจากธรรมชาติของผูใชเปลี่ยนความตองการอยูเรื่อย ๆ ความตองการ
เกิดขึ้นใหมอยูเ รื่อย ๆ ผูจัดการโครงการตองพิจารณาวาการเปลี่ยนแปลงที่เกิดขึ้นตรง
นั้นเกินขอบเขตของงานหรือไม ถาความตองการเขียนไมชัดเจนจะทําใหเกิดปญหา
การโตแยง หรือเนื้องานอาจเพิ่มขึ้น ซึง่ จะมีผลใหโครงการไมสามารถปดได
• การวางแผนโครงการที่เหมาะสม การวางแผนจะทําใหเรารูว างานที่ตองทํามีอะไร
คาใชจาย ทรัพยากรที่ตองการใช เวลาทีต่ องเสร็จ ใครรับผิดชอบ งานไหนตองเกิดขึ้น
กอน ถาไมมกี ารวางแผน จะมีผลทําใหระยะเวลาของโครงการตองขยาย คาใชจาย
สูงขึ้น หรืออาจทําใหโครงการตองยุติกลางคัน
• ความคาดหวังตอโครงการทีส่ อดคลองกับสภาพความเปนจริง ทีมงานจะตองไมสราง
ความคาดหวังของผูใชที่มีตอโครงการเกินจริง เพราะถาสุดทายแลวผูใชพบวาระบบ
ไมสามารถทําไดอยางทีท่ ีมงานเคยพูดไว จะทําใหผูใชผิดหวังอยางรุนแรง และเกิด
ความรูสึกตอตาน

ผศ.ดร. วราภรณ จิรชีพพัฒนา

บทนํา หนา 1-2

การบริหารโครงการเปนวิธีการหนึง่ ที่จะเพิม่ โอกาสที่โครงการจะประสบความสําเร็จ เพราะ

เปนการนําเอาเครื่องมือตาง ๆ มาชวยในการกําหนดแผนการดําเนินโครงการ ติดตามงานที่ทาํ การ
ประมาณคาใชจายและทรัพยากรอยางเหมาะสม การบริหารโครงการมีประโยชนดังนี้
• มีการควบคุมที่ดี ทัง้ ทางดานการเงิน บุคลากร และทรัพยากรอื่นๆ
• ความสัมพันธกับลูกคาดีขึ้น
• เวลาในการพัฒนานอยลง
• คาใชจายต่าํ
• ระบบงานมีคณ ุ ภาพและนาเชื่อถือ
• กําไรเพิ่มขึน้
• ผลผลิตเพิ่มขึน้
• การประสานงานภายในทีมดีขึ้น
• ขวัญพนักงานดีขึ้น

1.2 ความหมายของโครงการ
โครงการ หมายถึง ความพยายาม (การกระทํา) ชัว่ คราวที่ใชเพื่อสรางผลิตผล บริการหรือ
ผลลัพธทมี่ ีลักษณะพิเศษ ไมเหมือนใคร โครงการมีคุณลักษณะดังนี้
• มีวัตถุประสงค ทุกโครงการควรมีวัตถุประสงคที่ชัดเจน เชน ติดตั้งเครื่องคอมพิวเตอร
และซอฟตแวรเพื่อสนองตอบการสอบถามของลูกคาใหเพิ่มขึ้นรอยละ 95
• มีอัตลักษณของตนเอง
• มีระยะเวลา โครงการมีเวลาเริ่มตนและสิ้นสุด
• พัฒนาโดยวิธกี ารคอยๆ ทํารายละเอียดเพิ่มขึ้น ในชวงแรกโครงการจะถูกกําหนด
อยางกวางๆ เมื่อเวลาผานไปรายละเอียดของโครงการเริ่มชัดเจน
• ใชทรัพยากร ทรัพยากรประกอบดวยคน ฮารดแวร ซอฟตแวร เงิน และทรัพยสินอืน่ ๆ
หลายโครงการเปนโครงการที่เกี่ยวของกับหลายหนวยงาน ซึง่ ตองการคนจาก
หนวยงานที่เกีย่ วของ หรือมาจากหนวยงานภายนอกองคการ
• มีเจาของ หรือมีผูใหการสนับสนุน โครงการทีม่ ีผูเกี่ยวของหลายกลุมควรมีคนที่
รับผิดชอบหลัก เพื่อกําหนดทิศทาง ขอบเขตของงาน และสนับสนุนดานการเงินกับ
โครงการ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

บทนํา หนา 1-3

• มีความไมแนนอน เนื่องจากแตละโครงการมีลักษณะเฉพาะ ไมเหมือนกัน บางครั้งจึง

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

โครงการมีขอจํากัด 3 เรื่องคือ ขอบเขตของโครงการ เวลา และคาใชจาย ขอจํากัดนี้มี

ผลกระทบตอความสําเร็จของโครงการ
ขอบเขตของโครงการ: งานที่โครงการตองทําคืออะไร อะไรคือสิ่งที่ลูกคาหรือผูสนับสนุน
คาดหวังจากโครงการ
เวลา: เวลาทีต่ องการใช ตารางเวลาของโครงการ
คาใชจาย: งบประมาณโครงการ

รูปที่ 1.1 ความสัมพันธระหวางขอจํากัดโครงการ (Schwalbe, 2007)

รูปที่ 1.1 แสดงความสัมพันธระหวางขอจํากัดโครงการ การบริหารขอจํากัดจึงเปนการแลก

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

ผศ.ดร. วราภรณ จิรชีพพัฒนา

บทนํา หนา 1-4

รูปที่ 1.2 สวนที่เกี่ยวของกับการบริหารโครงการ (ปรับปรุงจาก Schwalbe, 2007)

1.3 บริหารโครงการคืออะไร
การบริหารโครงการคือ การประยุกตความรู ทักษะ เครื่องมือ และเทคนิค เขากับกิจกรรมของ
โครงการเพื่อใหงานออกมาตรงกับความตองการของโครงการ ผูจัดการโครงการตองอํานวยความสะดวก
ใหกระบวนการทั้งหมดทํางานใหตรงกับความตองการและความคาดหวังของผูใชหรือลูกคา รูปที่ 1.2
แสดงสวนที่เกีย่ วของกับการบริหารโครงการซึ่งประกอบดวยผูมีสวนไดสวนเสียกับโครงการ ความรูการ
บริหารโครงการ เครื่องมือและเทคนิคการบริหารโครงการ
• ผูมีสวนไดสวนเสียกับโครงการคือ บุคคลที่เกี่ยวของ หรือไดรับผลกระทบจากกิจกรรม
ตางๆ ของโครงการ รวมถึงผูส นับสนุนโครงการ ทีมงาน เจาหนาที่สนับสนุนลูกคา ผูใช
ผูคา และแมแตผูที่อยูตรงขามกับโครงการ
• ความรูการบริหารโครงการเปนความรูความสามารถที่สาํ คัญที่ผูจัดการโครงการตอง
พัฒนา ความรูนี้มี 9 ดาน โดย 4 ดานเปนความรูหลักในการบริหารโครงการ สวนอีก
5 ดานเปนความรูท่สี นับสนุนการบริหารโครงการ ความรูเหลานีไ้ ดถูกกําหนดโดย
สถาบันการบริหารโครงการ (Project Management Institute (PMI)) ซึ่งเปนสถาบัน
ที่ออกใบรับรองบุคคลที่ผานการทดสอบความรูท ั้ง 9 ดาน สถาบันไดออกแนวทางการ
บริหารโครงการที่กาํ หนดความรูท ั้ง 9 ดานในเอกสารทีช่ ื่อ PMBOK® Guide 2002
o ความรูหลัก ประกอบดวย
ƒ การบริหารขอบเขตโครงการ (project scope management) เปนการ
กําหนด และบริหารขอบเขตงานทัง้ หมดทีต่ องการเพื่อใหงานโครงการเสร็จ
สมบูรณ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

บทนํา หนา 1-5

ƒ การบริหารเวลาโครงการ (project time management) เปนการประมาณ

เวลาที่ตองการใชเพื่อใหงานเสร็จสมบูรณ พัฒนาตารางเวลาโครงการ
และการควบคุมใหโครงการเสร็จตามเวลา
ƒ การบริหารคาใชจายโครงการ (project cost management) เปนการ
เตรียมและบริหารงบประมาณโครงการ
ƒ การบริหารคุณภาพโครงการ (project quality management) เพื่อให
แนใจวาโครงการมีคุณภาพตามที่ไดกาํ หนด
o ความรูที่สนับสนุนการบริหารโครงการ
ƒ การบริหารการบูรณาการโครงการ (project integration management)
เปนการประสานความรูการบริหารโครงการทุกดานเพื่อใหงานของ
โครงการสามารถทําออกมาพรอมกัน ในเวลาที่กําหนด
ƒ การบริหารทรัพยากรมนุษยโครงการ (project human resource
management) เปนความรูท ี่ตระหนักถึงการใชคนที่เกี่ยวกับโครงการ
อยางมีประสิทธิผล
ƒ การบริหารการสื่อสารโครงการ (project communication management)
เกี่ยวกับการสราง การรวบรวม การกระจาย การจัดเก็บขอมูลโครงการ
ƒ การบริหารความเสี่ยงโครงการ (project risk management) เปนการระบุ
การวิเคราะห การตอบสนองตอความเสีย่ งที่เกี่ยวของกับโครงการ
ƒ การบริหารการจัดซื้อจัดจาง (project procurement management) เปน
การจัดหาสินคาและบริการจากนอกองคการ
• เครื่องมือและเทคนิคการบริหารโครงการเปนสิ่งที่ชวยใหผูจัดการโครงการและทีมงาน
ทํางานที่เกี่ยวกับความรู 9 ดาน เครื่องมือและเทคนิคที่นยิ มใชในการบริหารเวลาคือ
แผนภูมิแกนต (Gantt chart) ผังเครือขายโครงการ (project network diagram) และ
การวิเคราะหเสนทางวิกฤต (critical path analysis) ตารางที่ 1.1 แสดงเครื่องมือและ
เทคนิคที่ใชในความรูการบริหารโครงการ 9 ดาน

ผศ.ดร. วราภรณ จิรชีพพัฒนา

บทนํา
ตารางที่ 1.1 เครื่องมือและเทคนิคที่ใชในความรูก ารบริหารโครงการ 9 ดาน
ความรู
การบริหารการบูรณาการ
การบริหารขอบเขต
การบริหารเวลา
การบริหารคาใชจาย
การบริหารคุณภาพ
การบริหารทรัพยากรมนุษย
การบริหารการสื่อสาร
การบริหารการจัดซื้อจัดจาง
การบริหารความเสี่ยง
1.4 บทบาทของผูจัดการโครงการ
บทบาทของผูจ ัดการโครงการในแตละองคการมีความแตกตางกัน
โครงการสวนใหญมี ดังนี้
ผศ.ดร. วราภรณ จิรชีพพัฒนา
หนา 1-6
(Schwalbe, 2007)
เทคนิคและเครื่องมือ
วิธีการเลือกโครงการ ระเบียบวิธีการบริหารโครงการ การวิเคราะหผูมีสวนไดเสีย
เอกสารสิทธิ์โครงการ (project charters) แผนการบริหารโครงการ ซอฟตแวรการ
บริหารโครงการ คณะกรรมการควบคุมการเปลี่ยนแปลง การบริหารคอนฟกกรูเรชัน
การประชุมทบทวนโครงการ ระบบการอนุมัติงาน
ขอกําหนดขอบเขตโครงการ โครงสรางจําแนกงาน ขอกําหนดของงาน แผนการ
บริหารขอบเขต การวิเคราะหความตองการ การควบคุมการเปลี่ยนขอบเขต
แผนภูมิแกนต ผังเครือขายโครงการ การวิเคราะหเสนทางวิกฤต เทคนิคการทบทวน
และประเมินผลการทํางาน (PERT) ตารางเวลาโซหวงวิกฤต การเรงรัดเวลา
(crashing) เสนทางลัด (fast track) การทบทวนหลักไมล (milestones)
มูลคาปจจุบัน อัตราผลตอบแทนจากการลงทุน การวิเคราะหการจายคืนทุน แฟม
ธุรกิจ (business case) การบริหารมูลคาที่ไดรับ การบริหารกลุมโครงการ (project
portfolio management) ประมาณการคาใชจาย แผนการบริหารคาใชจาย
ซอฟตแวรดานการเงิน
ซิกสซิกมา (six sigma) ผังควบคุมคุณภาพ ผังพาเรโต ผังกางปลา หรือ ผังอิชิคาวา
การตรวจสอบคุณภาพ (quality audit) ตัวแบบวุฒิภาวะ (maturity models)
วิธีการเชิงสถิติ
เทคนิคการจูงใจ การฟงอยางเห็นอกเห็นใจ (empathic listening) สัญญาทีมงาน
ผังการมอบหมายความรับผิดชอบ แผนภูมิแบบแทงทรัพยากร การจัดระดับ
ทรัพยากร การสรางทีม
แผนการบริหารการสื่อสาร การบริหารความขัดแยง การเลือกสื่อการสื่อสาร
โครงสรางพื้นฐานการสื่อสาร รายงานสถานภาพ แมแบบ เว็บไซตโครงการ
การวิเคราะหการทําหรือการซื้อ สัญญา คํารองขอขอเสนอโครงการ หรือขอเสนอ
ราคา การเลือกแหลงสินคาหรือบริการ การตอรอง การจัดซื้อจัดจางแบบ
อิเล็กทรอนิกส
แผนการบริหารความเสี่ยง ผังผลกระทบ/ความเปนไปได การจัดลําดับความเสี่ยง
การจําลองแบบมอนติ คารโล (Monte Carlo simulation) การติดตามความเสี่ยง
สิบอันดับแรก
แตบทบาทที่ผูจัดการ
บทนํา หนา 1-7

• กําหนดขอบเขตโครงการ
• กําหนดผูมีสว นไดสวนเสีย ผูตัดสินใจและวิธีดําเนินการ
• พัฒนารายละเอียดของงาน
• ประมาณเวลาที่ตองการ
• พัฒนาผังการบริหารโครงการเริ่มแรก
• กําหนดทรัพยากรและงบประมาณที่ตองการ
• ประเมินความตองการ
• ระบุและประเมินความเสี่ยง
• เตรียมแผนฉุกเฉิน
• กําหนดความพึ่งพาระหวางกิจกรรม
• กําหนดและตามรอยหลักไมลที่วิกฤต
• มีสวนรวมในขัน้ ตอนการทบทวน
• ปกปองรักษาทรัพยากรทีจ่ ําเปน
• บริหารกระบวนการควบคุมการเปลี่ยนแปลง
• รายงานสถานภาพโครงการ

PMBOK® Guide 2002 ไดเสนอแนะวาผูจ ัดโครงการทีด่ ีควรมีทักษะที่หลากหลาย โดยเฉพาะ

ในเรื่องตอไปนี้
• ความรูการบริหารโครงการ
• ประยุกตความรู มาตรฐาน และกฎระเบียบ
• ความรูสภาวะแวดลอมโครงการ ผูจัดการโครงการตองเขาใจการเปลีย่ นแปลง และ
การทํางานในองคการ สภาวะแวดลอมทางดานการเมือง และกายภาพ
• ความรูและทักษะทัว่ ไปดานการบริหาร ผูจ ัดการโครงการควรเขาใจประเด็นที่สาํ คัญที่
เกี่ยวของกับการบริหารดานการเงิน บัญชี การจัดซื้อจัดจาง การตลาด สัญญา การ
ผลิต การกระจายสินคา การสงกําลังบํารุง (logistics) หวงโซอุปทาน การวางแผนเชิง
ยุทธศาสตร การวางแผนเชิงกลยุทธ การบริหารการปฏิบัติงาน โครงสรางองคการ
การบริหารพฤติกรรมบุคคล

ผศ.ดร. วราภรณ จิรชีพพัฒนา

บทนํา หนา 1-8

• ทักษะทางดานมนุษยสัมพันธ ผูจดั การโครงการควรมีทักษะดานการสื่อสารที่มี

ประสิทธิผล การมีอิทธิพลเพือ่ ใหงานสําเร็จ การเปนผูน ํา การกระตุน การตอรอง การ
จัดการความขัดแยง และการแกปญหา

มีคําถามวา ผูจ ัดการโครงการเทคโนโลยีสารสนเทศควรมีทักษะอะไรบาง บางคนคิดวา ทักษะ

ที่สําคัญของผูจ ัดการโครงการเทคโนโลยีสารสนเทศคือ ความรูความเขาใจเทคโนโลยีทตี่ องใชใน
โครงการ แตไมจําเปนตองเปนผูเชี่ยวชาญในเทคโนโลยีเฉพาะอยาง เพียงแตผูจัดการโครงการตองมี
ความรูพอที่จะสรางทีมงานที่เขมแข็ง ถามคําถามทีถ่ ูกตอง จัดการใหงานเดินไปตามแผนที่วางไว บาง
คนกลับคิดวาทักษะที่สาํ คัญสําหรับผูจัดการโครงการเทคโนโลยีสารสนเทศคือ มีความรูทางธุรกิจที่ดี
เพื่อนําทีมงานในสงงานที่ตรงกับความตองการทางธุรกิจ
เปนการยากทีผ่ ูที่มีความรู หรือมีพื้นฐานทางเทคโนโลยีสารสนเทศเพียงเล็กนอยจะเปน
ผูจัดการโครงการเทคโนโลยีสารสนเทศขนาดใหญ เพราะเปนการยากที่จะทํางานรวมกับผูจัดการคนอื่น
และผูขายสินคาหรือบริการ และยากที่จะไดรับการยอมรับจากทีมงาน อยางไรก็ตาม ผูจัดการโครงการ
เทคโนโลยีสารสนเทศขนาดใหญ ไมจําเปนตองเปนผูเชี่ยวชาญดานเทคโนโลยีสารสนเทศ แตควรมี
ประสบการณการทํางานในเทคโนโลยีทหี่ ลากหลาย รวมทั้งควรเขาใจวา โครงการทีก่ ําลังบริหารจะชวย
เสริมหรือขยายธุรกิจไดอยางไร มีหลายบริษทั ที่ผูจดั การดานธุรกิจที่ดีสามารถเปนผูจัดการโครงการ
เทคโนโลยีสารสนเทศที่ดีมาก เพราะเขาเหลานัน้ จะเนนที่การทําใหโครงการตอบสนองความตองการทาง
ธุรกิจ และไววางใจใหทีมงานจัดการในรายละเอียดทางดานเทคโนโลยี
เปนทีน่ า เสียใจที่คนหลายคนทีท่ ํางานดานเทคโนโลยีสารสนเทศไมตองการพัฒนาความรูและ
ทักษะใดๆ นอกจากทักษะทางดานเทคโนโลยี เขาเหลานี้ไมเห็นวา ทักษะดานมนุษยสัมพันธ และธุรกิจ
จะพัฒนาประสิทธิภาพการทํางาน จากการศึกษาพบวา การเปนผูน าํ ที่มีประสิทธิผลควรมีคุณลักษณะที่
ระบุในตารางที่ 1.2 ผูนําทีม่ ีประสิทธิผลตองเปนผูสรางทีม ผูสื่อสาร มีความเชื่อมัน่ ในตนเองสูง เนนที่
ผลลัพธ กําหนดเปาหมาย
ความเปนผูนาํ (leadership) และการบริหาร (management) ใชแทนกัน แตที่จริงแลวมีความ
แตกตางกัน โดยทั่วไป ผูน ําเนนเปาหมายระยะยาว และวัตถุประสงคทกี่ วาง กระตุน บุคคลใหบรรลุ
เปาหมายเหลานี้ สวนผูจัดการเนนจัดการกับรายละเอียดแตละวัน เพือ่ ใหบรรลุเปาหมายเฉพาะ บางคน
จึงกลาววา “ผูจัดการทําสิ่งใหถูก สวนผูน าํ ทําสิ่งที่ถูก” (Managers do things right, and leaders do
the right things) “ผูนํากําหนดวิสัยทัศน ผูจัดการทําใหบรรลุวิสัยทัศน” (Leaders determine the
vision, and managers achieve the vision) อยางไรก็ตาม ผูจัดการโครงการโดยมากมีบทบาททั้งผูน ํา
และผูจัดการ ผูจัดการโครงการที่ดีรูวา คนเปนผูทาํ และทําลายโครงการ ดังนัน้ ผูจัดการโครงการตองเปน

ผศ.ดร. วราภรณ จิรชีพพัฒนา

บทนํา หนา 1-9

ผูนําใหทีมไปสูความสําเร็จ ตองมีวสิ ัยทัศนในการชี้นาํ โครงการ ผูจัดการโครงการตองมีทกั ษะการบริหาร

เชน จัดการงานของโครงการใหมีประสิทธิผล

ตารางที่ 1.2 คุณลักษณะที่สําคัญสําหรับการเปนผูจ ัดการโครงการที่มปี ระสิทธิผลกับผูจดั การ

โครงการที่ไมมีประสิทธิผล (Schwalbe, 2006)
ผูจัดการโครงการทีม่ ีประสิทธิผล ผูจัดการโครงการทีไ่ มมีประสิทธิผล
ชักนําโดยใชตัวอยาง กําหนดตัวอยางที่ไมดี
มีวิสัยทัศน เปนคนที่ไมแนใจตัวเอง
มีความเชี่ยวชาญทางเทคนิค ขาดความเชี่ยวชาญทางเทคนิค
เปนคนตัดสินใจ เปนผูสื่อสารที่ไมดี
เปนผูสื่อสารที่ดี เปนผูกระตุนหรือชักจูงที่ไมดี
เปนผูกระตุนหรือชักจูงที่ดี
คัดคานผูบริหารระดับสูงเมื่อจําเปน
สนับสนุนสมาชิกในทีม
กระตุนหรือสงเสริมความคิดใหมๆ

1.5 ซอฟตแวรบริหารโครงการ
ซอฟตแวรบริหารโครงการในตลาดแบงออกเปน 3 กลุมใหญๆ ดังนี้
• เครื่องมือระดับพื้นฐาน (low-end tools) เครื่องมือเหลานี้มฟี งกชนั การบริหารงาน
พื้นฐาน เชน สรางแผนภูมิแกนต เหมาะกับโครงการขนาดเล็ก ผูใ ชคนเดียว เชน
Milestones Simplicity โดย KIDASA Software, Inc.
• เครื่องมือระดับกลาง (midrange tools) เปนเครื่องมือทีพ่ ัฒนาจากเครื่องมือ
ระดับพื้นฐาน เหมาะกับโครงการขนาดใหญขึ้น ผูใชหลายคน และหลายโครงการ
เครื่องมือระดับนี้สามารถสรางแผนภูมิแกนต ผังเครือขาย (network diagrams) ชวย
การวิเคราะหเสนทางวิกฤต การจัดสรรทรัพยากร การตามรอยโครงการ (tracking
project) การรายงานสถานภาพโครงการ ตัวอยางของเครื่องมือระดับนี้คือ Microsoft
Project
• เครื่องมือระดับสูง (high-end tools) หรือเครื่องมือจัดการโครงการระดับองคการ
(enterprise project management) สามารถจัดการโครงการขนาดใหญมากๆ
กระจายการทํางานหลายกลุม สรุปรวมแตละโครงการใหเห็นภาพรวมทุกโครงการของ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

บทนํา หนา 1-10

องคการ สามารถบูรณาการกับโปรแกรมจัดการฐานขอมูลองคการ สามารถเขาถึง

ผานอินเทอรเน็ต

1.6 สรุป
โครงการหมายถึงความพยายาม (การกระทํา) ชัว่ คราวที่ใชเพื่อสรางผลิตผล บริการหรือ
ผลลัพธทมี่ ีลักษณะพิเศษ ไมเหมือนใคร โครงการมีลักษณะที่ไมเหมือนกัน ชั่วคราว และพัฒนาแบบ
คอยๆ เพิ่ม โครงการตองการทรัพยากร มีผูสนับสนุนโครงการ และเกี่ยวของกับความไมแนนอน
ขอจํากัดของการบริหารโครงการคือ การบริหารขอบเขต เวลา และคาใชจายของโครงการ
การบริหารโครงการเปนการประยุกตองคความรู ทักษะ เครื่องมือ และเทคนิคเขากับกิจกรรม
โครงการ เพื่อใหตรงกับความตองการ ผูม ีสวนไดเสียคือ คนที่เขารวมหรือไดรับผลกระทบจากกิจกรรม
กรอบงานสําหรับการบริหารโครงการรวมถึงผูมีสวนไดเสีย ความรูการบริหารโครงการดานตางๆ และ
เทคนิคและเครื่องมือการบริหารโครงการ ความรู 9 ดานคือ การบริหารการบูรณาการโครงการ ขอบเขต
เวลา คาใชจา ย คุณภาพ ทรัพยากรมนุษย การสื่อสาร ความเสีย่ ง และการบริหารการจัดซื้อจัดจาง จาก
การศึกษาแสดงใหเห็นวา การสนับสนุนของผูบริหารระดับสูง การมีสวนรวมของผูใ ช ผูจัดการโครงการที่
มีประสบการณ และวัตถุประสงคที่ชัดเจนคือ สิ่งสําคัญตอความสําเร็จของโครงการ
ผูจัดการโครงการมีบทบาทสําคัญในการชวยใหโครงการและองคการประสบความสําเร็จ
ผูจัดการโครงการตองทํางานหลายหนาที่ มีทักษะทีห่ ลากหลาย และพัฒนาทักษะในการบริหารโครงการ
อยางตอเนื่อง มีทักษะในการพัฒนาระบบงานตางๆ โดยเฉพาะความเปนผูนาํ

คําถามทายบท
1. โครงการคืออะไร และมีคุณลักษณะอะไร
2. ขอจํากัดของโครงการคืออะไร จงอธิบาย
3. การบริหารโครงการคืออะไร
4. จงอธิบายกรอบการบริหารโครงการ
5. ผูจัดการโครงการมีบทบาทอะไร
6. ทักษะอะไรที่ผจู ัดการโครงการควรมี
7. เพราะเหตุใดความเปนผูน ําจึงมีความสําคัญตอผูจัดการโครงการ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารโครงการและบริบทเทคโนโลยีสารสนเทศ หนา 2-1

2.1 บทนํา
ทฤษฎีและแนวความคิดเกี่ยวกับการบริหารโครงการไมยากแกการเขาใจ แตสิ่งทีย่ ากคือ การ
ใชทฤษฎีและแนวความคิดในสภาพแวดลอมที่หลากหลาย ผูจัดการโครงการตองตระหนักถึงประเด็น
ตางๆ ที่แตกตางกันในการบริหารโครงการ เนื่องจากแตละโครงการมีเอกลักษณภายใตสภาวะแวดลอม
ของโครงการนัน้ ๆ เนื้อหาของบทนี้จะครอบคลุมสวนประกอบบางสวนที่เกีย่ วของกับความเขาใจ
สภาพแวดลอมโครงการ เชน วิธีการเชิงระบบ ความเขาใจองคการ การบริหารผูมีสวนไดเสีย ความ
เขาใจความสัมพันธระหวางวงจรชีวิตโครงการกับวงจรชีวิตการพัฒนาซอฟตแวร ความเขาใจบริบทของ
โครงการเทคโนโลยีสารสนเทศ และกลุม กระบวนการบริหารโครงการ

2.2 วิธีการเชิงระบบ
ถึงแมวา โครงการจะเปนการรวมตัวกลุมคนชั่วคราวเพื่อสรางผลิตผลหรือใหบริการ แตผูจัด
การโครงการไมสามารถดําเนินโครงการแยกออกจากองคการ โครงการจะตองทํางานในสภาวะแวดลอม
ขององคการในระดับกวาง และผูจัดการโครงการจําเปนตองพิจารณาโครงการภายใตบริบทเชิงองคการ
เพื่อจัดการสถานการณที่สลับซับซอนไดอยางมีประสิทธิผล ผูจัดการโครงการจําเปนตองใชมุมมองแบบ
องครวม หรือการคิดเชิงระบบ (systems thinking)
วิธีการเชิงระบบคือ วิธกี ารเชิงวิเคราะหแบบองครวมเพือ่ การแกปญหาที่สลับซับซอน เปน
วิธีการที่รวมการใชปรัชญาระบบ (systems philosophy) การวิเคราะหระบบ (systems analysis) และ
การบริหารระบบ (system management) ปรัชญาระบบคือ ตัวแบบภาพรวมทัง้ หมดสําหรับการคิด
เกี่ยวกับสิ่งตางๆ เสมือนระบบ การวิเคราะหระบบคือ วิธีการแกปญ  หาที่ตองมีการกําหนดขอบเขตของ
ระบบ การแบงระบบเปนสวนๆ การระบุและการประเมินปญหา โอกาส ขอจํากัด และความตองการ
จากนั้น นักวิเคราะหระบบตรวจสอบคําตอบที่เปนทางเลือกสําหรับการปรับปรุงสถานการณปจจุบัน
กําหนดทางเลือกที่ดีที่สุด (optimum) หรืออยางนอยทางเลือกทีพ่ ึงพอใจ (satisfactory) หรือแผนการ
ดําเนินการ รวมทัง้ ตรวจสอบแผนกับระบบทั้งหมด การบริหารระบบหมายถึงประเด็นเชิงธุรกิจ
เทคโนโลยี และองคการที่เกีย่ วกับการสราง การบํารุงรักษา และการทําการเปลีย่ นแปลงใหกับระบบ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารโครงการและบริบทเทคโนโลยีสารสนเทศ หนา 2-2

การใชวิธกี ารเชิงระบบมีความสําคัญตอความสําเร็จของการบริหารโครงการ ผูบริหารระดับสูง

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

2.3 ตัวแบบวงกลมสามวงสําหรับการบริหารโครงการ
รูปที่ 2.1 คือ ตัวแบบวงกลมสามวงสําหรับการบริหารโครงการจัดหาคอมพิวเตอรโนตบุค
(notebook computer) วงกลมแตละวงหมายถึง ธุรกิจ (business) องคการ (organization) และ
เทคโนโลยี (technology) ทัง้ สามวงมีผลกระทบอยางสูงตอการเลือก และการบริหารโครงการใหสาํ เร็จ

วิทยาลัยมีคาใชจายอะไร
นักศึกษาตองเสียคาใชจายอะไร
ผลกระทบตอการลงทะเบียนคืออะไร

ธุรกิจ

องคกร เทคโนโลยี

โครงการจัดหาโนตบุคกระทบตอนักศึกษาทั้งหมดหรือ
เฉพาะนักศึกษาบางสาขา
โครงการนี้กระทบตอนักศึกษาที่มีเครื่องคอมพิวเตอรแลว
อยางไร
ใครเปนคนอบรมใหกับนักศึกษาและพนักงานของคณะ
ใครเปนผูบริหารและสนับสนุนการอบรม
โนตบุคควรจะใชระบบปฏิบัติการแบบใด
ซอฟทแวรอะไรที่ควรจะลงในเครื่องโนตบุค
รายละเอียดขอกําหนดฮารดแวรมีอะไร
ฮารดแวรจะมีผลกระทบตอ LAN
และการเขาถึงอินเตอรเน็ตอยางไร

รูปที่ 2.1 ตัวแบบวงกลมสามวงสําหรับการบริหารโครงการ (Schwalbe, 2007)

ผูมีวิชาชีพทางเทคโนโลยีสารสนเทศชอบวุน วายอยูก ับเทคโนโลยี การแกปญหาที่เกิดขึ้นในแต

ละวัน และชอบกังวลกับปญหาของคน หรือการเมืองที่ปรากฎในองคการ ขณะเดียวกัน ผูม ีวิชาชีพทาง
เทคโนโลยีสารสนเทศยังละเลยประเด็นสําคัญทางธุรกิจ เชน ความคุมคาทางดานการเงิน การใชวิธี
แบบองครวมชวยใหผจู ัดการโครงการบูรณาการประเด็นทางธุรกิจ และองคการเขามาในการวางแผน

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารโครงการและบริบทเทคโนโลยีสารสนเทศ หนา 2-3

2.4 ความเขาใจองคการ
2.4.1 กรอบขององคการ
องคการสามารถมองดวยกรอบที่แตกตางกันได 4 กรอบคือ กรอบโครงสราง กรอบ
ทรัพยากรมนุษย กรอบการเมือง และกรอบสัญลักษณ ผูจัดการโครงการตองเรียนรูที่จะทํางานกับกรอบ
เหลานี้
• กรอบโครงสราง (structural frame) เปนกรอบทีเ่ นนโครงสรางองคการ ความ
แตกตางของบทบาท และความรับผิดชอบของกลุม เพื่อใหบรรลุเปาหมายและ
นโยบายที่กาํ หนดโดยผูบริหารสูงสุด รวมทั้งการประสานงานและการควบคุม
ประเด็นสําคัญที่เกี่ยวกับเทคโนโลยีสารสนเทศคือ องคการควรใหบุคลากรทาง
เทคโนโลยีสารสนเทศรวมศูนยที่แผนกหนึ่ง หรือกระจายไปอยูในแผนกตางๆ เปน
ตน
• กรอบทรัพยากรมนุษย (human resources frame) เปนกรอบที่เนนความ
สอดคลองกันระหวางความตองการขององคการกับความตองการของคน ซึง่ จะไม
คอยสอดคลองกัน เชน โครงการจะมีประสิทธิภาพ ถาบุคลากรทํางานอาทิตยละไม
นอยกวา 80 ชั่วโมง เปนเวลาหลายเดือน ตารางการทํางานนี้ขัดแยงกับชีวิตของ
บุคลากร ประเด็นทางเทคโนโลยีสารสนเทศที่เกีย่ วของกับกรอบทรัพยากรมนุษย
คือ การขาดแคลนบุคลากรที่มีทกั ษะทางเทคโนโลยีสารสนเทศภายในองคการ และ
ตารางเวลาที่ไมสอดคลองกับความเปนจริงที่บีบบังคับโครงการ
• กรอบการเมือง (political frame) เปนกรอบที่เนนการเมืองของบุคคลและการเมือง
ขององคการ การเมืองในองคการจะอยูในรูปของการแขงขันระหวางกลุม หรือ
ระหวางบุคคล เพื่ออํานาจและความเปนผูน ํา กรอบการเมืองสมมุตวิ าองคการคือ
การรวมกันของบุคคลตางๆ และกลุมที่สนใจ การตัดสินใจที่สําคัญคือ การจัดสรร
ทรัพยากรที่ขาดแคลน การแขงขันกันเพื่อใหไดทรัพยากรที่ขาดแคลนทําใหเกิด
ความขัดแยง และการใชอํานาจเพื่อใหไดทรัพยากรนัน้ ผูจัดการโครงการตองให
ความสนใจในประเด็นการเมืองและอํานาจ ผูจัดการตองรูวาใครเปนฝายตรงขาม
ใครสนับสนุนโครงการ ประเด็นที่สาํ คัญทางเทคโนโลยีสารสนเทศที่เกีย่ วของกับ
กรอบการเมืองคือ การเคลื่อนยายอํานาจจากการทํางานรวมศูนยไปยังหนวย
ปฏิบัติงาน หรือจากผูจัดการตามหนาที่ (functional manager) เปน ผูจัดการ
โครงการ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารโครงการและบริบทเทคโนโลยีสารสนเทศ หนา 2-4

• กรอบสัญลักษณ (symbolic frame) เปนกรอบที่เนนสัญลักษณ และความหมาย

สิ่งที่สาํ คัญในเหตุการณใดๆ ในองคการอาจไมใชสิ่งที่ไดเกิดขึ้นจริงๆ แตตอง
พิจารณาที่ความหมาย เชน การที่ผบู ริหารสูงสุดขององคการเปดการประชุม
โครงการเปนสัญญาณที่ดี หรือเปนการคุกคาม กรอบสัญลักษณยังมีความสัมพันธ
กับวัฒนธรรมองคการ เชน การแตงกาย จํานวนชัว่ โมงการทํางาน การดําเนินการ
ประชุม โครงการเทคโนโลยีสารสนเทศหลายๆ โครงการเปนโครงการระหวาง
ประเทศ และมีผูมีสวนไดเสียมาจากวัฒนธรรมทีห่ ลากหลาย ความเขาใจ
วัฒนธรรมเหลานี้เปนสวนทีส่ ําคัญของกรอบสัญลักษณ

2.4.2 โครงสรางองคการ
โครงสรางองคการมี 3 แบบคือ โครงสรางตามหนาที่ (functional structure) โครงสราง
แบบโครงการ (project structure) และโครงสรางแบบแมทริกซ (matrix structure) ดังแสดงในรูปที่ 2.2
โครงสรางองคการมีอิทธิพลตอโครงการสรุปในตารางที่ 2.1

โครงสรางตามหนาที่
โครงสรางตามหนาทีม่ ีลักษณะเปนลําดับขั้น โดยมีผูบริหารสูงสุดอยูร ะดับบนสุดที่
รองประธาน หรือ ผูจัดการฟงกชันตางๆ ตองรายงาน เชน ผูจัดการโรงงาน ผูจัดการทรัพยากรมนุษย
ผูจัดการเทคโนโลยีสารสนเทศ เปนตน พนักงานแตละแผนกจะมีความเชี่ยวชาญเฉพาะ โครงสรางตาม
หนาทีเ่ ปนโครงสรางที่ยืดหยุน ในการใชบุคลากรทํางานใหโครงการ เนื่องจากบุคลากรสามารถกลับไป
ทํางานประจําของตนไดทันทีที่โครงการสิน้ สุด โครงการสามารถใชผูเชี่ยวชาญในแผนกทํางานนอกเวลา
ได ในทางตรงกันขาม โครงสรางองคการแบบนี้สง ผลกระทบตอโครงการคือ ผูจัดการโครงการไมมี
อํานาจบังคับบัญชา การขอความรวมมือจากแผนกอืน่ ๆ อาจทําไดยาก แตละแผนกมุง เนนแตโครงการ
ของตนเอง บุคลากรอาจใหความสนใจนอย เพราะคิดวาเปนการเพิ่มภาระ

โครงสรางแบบโครงการ
โครงสรางแบบโครงการมีโครงสรางเปนลําดับขั้นเชนเดียวกัน แตแทนที่จะเปนรอง
ประธาน หรือผูจัดการที่รายงานตอผูบริหารสูงสุด กลับเปนผูจัดการแผนงาน (program) ที่รายงานตอ
ผูบริหารสูงสุด ผูรวมงานในแผนงานมีทักษะทีห่ ลากหลายเพื่อทํางานโครงการตางๆ ไดสมบูรณ
โครงสรางองคการแบบนี้สามารถทําโครงการไดเสร็จอยางรวดเร็ว ผูจดั การโครงการมีอํานาจเต็มที่ และ
มีผูรวมงานที่อทุ ิศเวลาใหกับโครงการอยางเต็มที่ โดยมีเปาหมายรวมกัน การสื่อสารกับผูบริหารระดับสูง
ทําไดอยางรวดเร็ว ถึงแมวาผูจัดการโครงการจะมีอาํ นาจสูงสุดในโครงสรางแบบโครงการ แตการจัดแบบ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารโครงการและบริบทเทคโนโลยีสารสนเทศ หนา 2-5

นี้ไมมีประสิทธิภาพ การมอบหมายพนักงานใหทํางานเต็มเวลา เปนการใชทรัพยากรไมเหมาะสม เชน

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

รูปที่ 2.2 โครงสรางองคการ (Schwalbe, 2007)

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารโครงการและบริบทเทคโนโลยีสารสนเทศ หนา 2-6

โครงสรางแบบแมทริกซ
โครงสรางแบบแมทริกซเปนโครงสรางทีผ่ สมของโครงสรางทัง้ สองทีก่ ลาวมาแลว มี
ลักษณะเปนกริด บุคลากรของโครงการรายงานตอผูจดั การตามหนาที่ และผูจ ดั การโครงการ เชน
บุคลากรทางเทคโนโลยีสารสนเทศสวนใหญจะทํางานหลายโครงการ แตตองรายงานตอผูจัดการแผนก
เทคโนโลยีสารสนเทศและผูจดั การจากแผนกตางๆ โครงสรางแบบนีย้ ังแบงออกเปน 3 แบบยอยคือ
(ตัวอยางโครงสรางทัง้ 3 แบบ แสดงในรูปที่ 2.3)
• โครงสรางแมทริกซแบบออนๆ (weak matrix) เปนโครงสรางที่ยงั คงรักษา
คุณลักษณะหลายอยางของโครงสรางตามหนาที่ ผูจัดการโครงการเปนเพียงผู
ประสานงาน สวนทีมงานคือ บุคลากรทีม่ าจากแผนกตางๆ ที่เกีย่ วของ ซึ่งยัง
ทํางานประจําของตนแตมีสมรรถภาพเหลือพอที่จะทํางานใหโครงการ โดย
ผูจัดการตามหนาที่จะเปนผูสั่งการใหคนในแผนกของตนทํางานเพิ่มขึน้ จาก
งานประจํา การใหความสําคัญแกงานของโครงการจึงขึ้นอยูกับผูจัดการตาม
หนาที่ โครงสรางองคการลักษณะนี้ ผูจดั การตามหนาที่ยงั คงมีอํานาจ สวน
ผูจัดการโครงการจะทําหนาที่ประสานกิจกรรมของโครงการซึ่งกระจายอยูตาม
แผนกตางๆ เขาดวยกัน
• โครงสรางแมทริกซแบบสมดุล (balanced matrix) เปนโครงสรางทีต่ ระหนักถึง
ความจําเปนตองมีผูจัดการโครงการ โดยเลือกตัวแทนจากแผนกใดแผนกหนึง่
มาเปนผูจัดการโครงการ แตไมมีอํานาจเต็มที่ ผูจัดการโครงการมีหนาที่
วางแผนโครงการ กําหนดตารางเวลางาน ความกาวหนาของงาน เปนตน สวน
ผูจัดการตามหนาที่รับผิดชอบจัดคนทํางาน และงบประมาณ ผูจัดการทั้งสอง
ฝายตองทํางานรวมกันอยางใกลชิด และรวมกันใหความเห็นชอบในการ
ตัดสินใจดานเทคนิคและทางดานการปฏิบัติงาน
• โครงสรางแมทริกซแบบเขมขน (strong matrix) เปนโครงสรางทีม่ ีคณ ุ ลักษณะ
ของโครงสรางแบบโครงการหลายประการ มีผูจัดการโครงการทําหนาที่เต็ม
เวลาและมีอาํ นาจเต็มที่ในการควบคุมและสั่งการทีมงาน สวนผูจดั การตาม
หนาที่ควบคุมการจัดคนในฝายหรือแผนกของตนใหโครงการ ซึง่ คนที่ไดรับ
มอบหมายใหไปทําโครงการบางคนอาจจะทํางานเต็มเวลาหรือบางเวลาก็ได
ขึ้นอยูกับความตองการของโครงการในชวงเวลาตางๆ บุคคลในทีมงานตอง
รายงานการทํางานใหผูจัดการโครงการและผูจัดการตามหนาที่

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารโครงการและบริบทเทคโนโลยีสารสนเทศ หนา 2-7

รูปที่ 2.3 โครงสรางแมทริกซทั้ง 3 แบบ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารโครงการและบริบทเทคโนโลยีสารสนเทศ หนา 2-8

การจัดโครงสรางโครงการแบบแมทริกซสามารถทําใหเกิดความยืดหยุน ในการใช
ประโยชนจากทรัพยากรและผูเชี่ยวชาญขององคการ ผูเชี่ยวชาญตางๆ ก็ยังคงอยูในหนวยงานของตน
จึงไมเกิดปญหาการโอนคืนบุคลากร หลังจากโครงการปด ในทางกลับกัน โครงสรางแบบแมทริกซอาจ
ทําใหเกิดความขัดแยงระหวางผูจัดการหนวยงานกับผูจดั การโครงการ รวมทัง้ การแยงชิงทรัพยากรที่มี
จํากัดใหกับงานของตน ผูรว มโครงการอาจตองเผชิญกับปญหาที่ตอ งมีผูบังคับบัญชาอยางนอย 2 คน
ซึ่งผิดหลักการบริหารการจัดการ

ตารางที่ 2.1 อิทธิพลของโครงสรางองคการตอโครงการ (PMBOK® Guide 2004)

ลักษณะโครงการ ประเภทโครงสรางองคการ
ตามหนาที่ แมทริกซ โครงการ
แมทริกซ • •
แบบออนๆ

อํานาจของผูจัดการโครงการ นอย หรือ ไม จํากัด ต่ํา – ปาน ปานกลาง – สูง - เกือบ
มี กลาง สูง สมบูรณ
ผูควบคุมงบประมาณโครงการ ผูจัดการตาม ผูจัดการตาม ผสม ผูจัดการ ผูจัดการ
หนาที่ หนาที่ โครงการ โครงการ
บทบาทของผูจัดการโครงการ ไมเต็มเวลา ไมเต็มเวลา เต็มเวลา เต็มเวลา เต็มเวลา

พนักงานบริหารงานของโครงการ ไมเต็มเวลา ไมเต็มเวลา ไมเต็มเวลา เต็มเวลา เต็มเวลา

2.4.3 วัฒนธรรมองคการ
วัฒนธรรมองคการคือ สมมติฐาน (assumptions) คานิยม (values) และพฤติกรรม
(behaviors) ที่เปนลักษณะพิเศษของการทํางานขององคการหนึง่ ในองคการเดียวกันสามารถมี

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารโครงการและบริบทเทคโนโลยีสารสนเทศ หนา 2-9

วัฒนธรรมยอยได แผนกเทคโนโลยีสารสนเทศอาจมีวฒ ั นธรรมองคการที่ตา งจากแผนกการเงิน

วัฒนธรรมองคการมีอํานาจมาก และหลายๆ คนเชื่อวามันเปนสาเหตุของปญหาหลายๆ ปญหาของ
องคการ สตีเฟน พี รอบบินส (Stephen P. Robbins) ไดระบุลักษณะ 10 ประการของวัฒนธรรม
องคการ ดังนี้
• ความเปนสมาชิก (member identity) หมายถึง ระดับความเปนสมาชิกของ
พนักงานขององคการมากกวาความเปนสมาชิกของประเภทของงานหรืออาชีพ
เชน ผูจัดการโครงการหรือสมาชิกในทีมมีความรูสึกวา เขาอุทิศเวลาใหกับองคการ
หรือโครงการมากกวางานของพวกเขา วัฒนธรรมองคการทีพ่ นักงานมีความเปน
สมาชิกตอองคการสามารถชักนําไปสูวัฒนธรรมโครงการที่ดี
• ใหความสําคัญกับกลุม (group emphasis) หมายถึง ระดับที่กิจกรรมถูกจัดตาม
กลุมหรือทีมมากกวาตามบุคคล วัฒนธรรมองคการทีเ่ นนงานกลุมเปนวัฒนธรรมที่
ดีที่สุดสําหรับการบริหารโครงการ
• เนนคน (people focus) หมายถึง ระดับที่การตัดสินใจของผูบริหารทีน่ ําผลกระทบ
ตอบุคคลในองคการมาพิจารณา ผูจัดการโครงการอาจมอบหมายงานใหกบั คน
โดยไมไดพิจารณาความตองการสวนบุคคล หรือผูจัดการโครงการอาจรูจักแตละ
คนดีและมอบหมายงานตามความตองการของแตละคน ดังนัน้ ผูจัดการโครงการที่
ดีตองทําใหเกิดสมดุลระหวางความตองการสวนบุคคลกับความตองการของ
องคการ
• บูรณาการเปนหนวยเดียว (unit integration) หมายถึง ระดับทีห่ นวยงาน หรือ
แผนกภายในองคการไดรับการสนับสนุนใหประสานงานกัน วัฒนธรรมองคการทีม่ ี
บูรณาการเปนหนวยเดียวสูงจะทําใหงานของผูจัดการโครงการงาย
• การควบคุม (control) หมายถึง ระดับที่กฎ นโยบาย และการควบคุมโดยตรงถูก
นํามาใชเฝาดูและควบคุมพฤติกรรมพนักงาน ผูจดั การโครงการตองทําใหเกิด
สมดุลในการควบคุม
• ระดับการยอมรับความเสี่ยง (risk tolerance) หมายถึง ระดับที่พนักงานไดรับการ
สนับสนุนใหกา วราว ใหคิดสิ่งใหม และคนหาความเสี่ยง (risk seeking) องคการที่
มีวัฒนธรรมดังกลาว จะทําใหพนักงานมีความสามารถจัดการกับความเสีย่ ง
วัฒนธรรมองคการที่มีความทนทานตอความเสีย่ งสูงจะดีที่สุดสําหรับการบริหาร
โครงการ เนือ่ งจากโครงการเกี่ยวของกับเทคโนโลยีใหมๆ ความคิดใหมๆ และ
กระบวนการใหมๆ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารโครงการและบริบทเทคโนโลยีสารสนเทศ หนา 2-10

• เกณฑการใหรางวัล (reward criteria) หมายถึง ระดับที่การใหรางวัลเปนไปตาม

ประสิทธิภาพของพนักงานมากกวาอาวุโส ความชื่นชอบ หรือปจจัยอื่นที่ไมใช
ปจจัยทางประสิทธิภาพ ผูจดั การโครงการและสมาชิกในทีมจะทํางานไดดีที่สุดเมื่อ
การใหรางวัลขึ้นกับประสิทธิภาพ
• ระดับการยอมรับความขัดแยง (conflict tolerance) หมายถึง ระดับที่พนักงาน
ไดรับการสนับสนุนใหแสดงความขัดแยง และการวิจารณอยางเปดเผย คนรูสึก
สบายใจกับการโตเถียงความขัดแยงอยางเปดเผย
• มุงเนนวิธีการหรือเปาหมาย (means-ends orientation) หมายถึง ระดับที่การ
บริหารเนนผลลัพธมากกวาเทคนิค และกระบวนการที่ใชเพื่อใหไดผลลัพธ องคการ
ที่ใชวิธที ี่สมดุลจะเหมาะกับงานของโครงการ
• เนนระบบเปด (open-system focus) หมายถึง ระดับทีก่ ารติดตามและสนองตอบ
การเปลี่ยนแปลงในสภาวะแวดลอมภายนอก

จะเห็นไดวาวัฒนธรรมองคการมีความสัมพันธกับการบริหารโครงการที่ประสบ
ความสําเร็จ งานของโครงการประสบความสําเร็จในวัฒนธรรมองคการที่ความเปนพนักงานขององคการ
กิจกรรมที่เนนกลุม มีการบูรณาการระหวางหนวยงานทีส่ ูง ระดับการยอมรับความเสี่ยงสูง ใหรางวัลตาม
ผลงงาน ระดับการยอมรับความขัดแยงสูง เนนระบบเปด และเนนสมดุลระหวางคนกับองคการ การ
ควบคุม และวิธีการ

2.5 การบริหารผูมีสวนไดเสีย
ผูมีสวนไดเสียโดยทัว่ ไปจะรวมถึงผูสนับสนุนโครงการทีมงาน พนักงานสนับสนุน และลูกคา
ของโครงการ นอกจากนี้ ยังรวมถึงผูบริหารระดับสูง ผูจดั การแผนกอืน่ ๆ และผูจัดการโครงการตางๆ ผูมี
สวนไดเสียยังหมายถึงคนนอกโครงการ เชน ลูกคา คูแขง ผูจัดหาสินคาหรือบริการ (suppliers) หนวย
ราชการ เปนตน
เนื่องจากวัตถุประสงคของการบริหารโครงการคือ เพื่อใหบรรลุความตองการของโครงการ
และเปนทีพ่ อใจของผูมีสวนไดเสีย ดังนั้น จึงเปนสิง่ สําคัญสําหรับผูจดั การโครงการที่ตองใชเวลา เพื่อ
กําหนดผูมีสว นไดเสีย ทําความเขาใจ และบริหารความสัมพันธกับผูมีสวนไดเสียทั้งหมดของโครงการ
การใชกรอบขององคการทั้ง 4 กรอบสามารถชวยใหผูจดั การโครงการบรรลุความคาดหวังของผูมีสว นได
เสีย การบริหารคนกลุมนี้ตองการสิง่ ตอไปนี้

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารโครงการและบริบทเทคโนโลยีสารสนเทศ หนา 2-11

• คํามั่นของผูบริหารระดับสูง (management commitment) ระดับคํามั่นและการ

สนับสนุนที่ไดรับจากผูบริหารระดับสูงเปนปจจัยที่สาํ คัญที่ชวยใหผูจัดการโครงการนํา
โครงการไปสูค วามสําเร็จ ดังไดกลาวมาแลววา โครงการเปนสวนหนึง่ ของสภาวะ
แวดลอมเชิงองคการ จึงมีปจจัยหลายตัวที่มีผลกระทบตอโครงการที่ผูจัดการโครงการ
ไมสามารถควบคุมได การสนับสนุนจากผูบริหารจึงเปนปจจัยที่สําคัญตอความสําเร็จ
ของโครงการ คํามั่นของผูบริหารระดับสูงจึงสําคัญตอผูจัดการโครงการเนื่องจาก
ผูจัดการโครงการตองการสิ่งตอไปนี้
ƒ ทรัพยากรทีเ่ พียงพอ
ƒ การอนุมัติความตองการของโครงการ
ƒ ความรวมมือจากสวนตางๆ ขององคการ
ƒ พี่เลี้ยงและโคช
• คํามั่นองคการตอเทคโนโลยีสารสนเทศ (organizational commitment to information
technology) องคการตองเห็นคุณคาของเทคโนโลยีสารสนเทศ ตองบูรณาการ
เทคโนโลยีสารสนเทศเขากับธุรกิจ และแตงตั้งรองประธานเปนผูบริหารระดับสูงของ
หนวยงานเทคโนโลยีสารสนเทศ ผูบริหารระดับสูงตองสงเสริมใหมกี ารใชเทคโนโลยี
สารสนเทศในองคการ
• มาตรฐานองคการ (organizational standards) มาตรฐาน หรือแนวทาง (guidelines)
สามารถชวยการบริหารโครงการใหงายขึน้ มาตรฐานหรือแนวทาง ไดแก แบบฟอรม
หรือ แมแบบ (template) สําหรับเอกสารโครงการ เชน แผนโครงการ แนวทางการ
รายงานสารสนเทศตอผูบริหารระดับสูง เปนตน

2.6 ขั้นตอนโครงการและวงจรชีวิตของโครงการ
วงจรชีวิตของโครงการคือ ชุดงานของขั้นตอนโครงการ โดยแตละขั้นตอนจะกําหนดงานที่ตอง
ทํา ทําเมื่อไร ใครเปนคนทํา สิง่ ที่ไดจากงานคืออะไร (deliverables) การควบคุมและอนุมัติงานจะทํา
อยางไร สิ่งที่ไดจากงานคือ ผลิตผลหรือบริการ (เชน รายงาน การอบรม ชิ้นสวนฮารดแวร หรือโปรแกรม
บางสวน)
ในขั้นตอนแรกของวงจรชีวิตของโครงการมีความตองการใชทรัพยากรนอย และมีระดับความ
ไมแนนอนสูงสุด ผูมีสว นไดเสียของโครงการมีอิทธิพลสูงสุดตอคุณลักษณะของผลิตผลสุดทายของ
โครงการ หรือแมแตผลลัพธทเี่ กิดขึ้นในชวงแรกของโครงการ ระหวางชวงกลางของวงจรชีวิตของ
โครงการ ความแนนอนจะเพิ่มขึน้ และความตองการใชทรัพยากรเพิ่มขึ้นมากกวาชวงเริ่มตนและชวง

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารโครงการและบริบทเทคโนโลยีสารสนเทศ หนา 2-12

สุดทายของโครงการ ในขั้นตอนสุดทายเปนขั้นตอนที่เนนความตองการของโครงการตรงกับที่ผูสนับสนุน
โครงการอนุมตั ิหรือไม
ขั้นตอนโครงการของแตละโครงการมีความแตกตางกัน ขึ้นอยูกับลักษณะของโครงการและ
อุตสาหกรรม แตขั้นตอนที่พบในการบริหารโครงการโดยทั่วไปประกอบดวย 2 ขั้นตอนใหญ 4 ขัน้ ตอน
ยอยคือ ความเปนไปไดของโครงการ (project feasibility) และการไดโครงการ (project acquisition)
ขั้นตอนความเปนไดของโครงการยังประกอบดวย แนวความคิด (concept) และการพัฒนา
(development) สวนขั้นตอนการไดโครงการประกอบดวย การปฏิบตั ิงาน (implementation) และปด
โครงการ (close-out) ขั้นตอนของโครงการไดแสดงในรูปที่ 2.4

ความเปนไปไดของโครงการ การไดโครงการ

แนวความคิด การพัฒนา การปฏิบัติงาน การปดโครงการ

แผนการบริหาร แผนโครงการ แพคเกจงานสุดทาย งานเสร็จสมบูรณ

ประมาณการคาใช ประมาณการงบ ประมาณการคาใช บทเรียนที่ไดรับ

ตัวอยางสิ่งที่ได จายแนนอน
จายเบื้องตน ประมาณคาใชจาย
จากแตละระยะ
โครงสรางจําแนก โครงสรางจําแนกงาน รายงานการปฏิบัติงาน การยอมรับของลูกคา
งาน 3 ระดับ มากกวา 6 ระดับ

รูปที่ 2.4 ขั้นตอนของวงจรชีวิตโครงการ (Schwalbe, 2007)

ในขั้นตอนแนวความคิดของโครงการ ผูจัดการโครงการจะบรรยายโครงการอยางคราวๆ
พัฒนาแผนของโครงการแบบสรุป หรือระดับสูงมากๆ (high-level) ซึ่งแผนจะบรรยายถึงความตองการ
โครงการ และแนวความคิดเบื้องตน ประมาณการคาใชจายอยางหยาบๆ และกําหนดงานที่ตองทํา
โดยรวม งานที่ตองทําจะจําแนกเปนงานยอย กําหนดเอกสารที่ตองผลิต เชน ในโครงการคอมพิวเตอร
โนตบุค ทีมงานเริ่มศึกษาแนวความคิดที่จะเพิ่มการใชเทคโนโลยี พัฒนาแผนการบริหารทีม่ โี ครงการ
ขนาดเล็กเพื่อสํารวจทางเลือกในการเพิ่มการใชเทคโนโลยีสารสนเทศ ประมาณการคาใชจายสําหรับ
โครงการสํารวจนี้ จําแนกงานโครงการสํารวจ สํารวจขอมูลจากนักเรียนและพนักงานวิทยาลัย ประเมิน
การอยางหยาบวา การใชเทคโนโลยีสารสนเทศจะมีผลกระทบตอคาใชจายและการขึ้นทะเบียนอยางไร
สุดทายขัน้ ตอนนี้จะไดรายงานที่นาํ เสนอผลการศึกษา
ขั้นตอนการพัฒนาเปนขัน้ ตอนทีท่ ีมงานสรางแผนโครงการที่ละเอียดมากขึ้น การประมาณ
การคาใชจายถูกตองมากขึน้ และการจําแนกงานลงรายละเอียดมากกวาเดิม สมมุติวาในขั้นตอน

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารโครงการและบริบทเทคโนโลยีสารสนเทศ หนา 2-13

แนวความคิดไดเสนอแนะวา การใหนักเรียนมีคอมพิวเตอรโนตบุคเปนแนวทางที่จะเพิ่มการใชเทคโนโลยี
สารสนเทศ ทีมงานตองขยายแนวความคิดตอในขั้นตอนนี้ ถานักเรียนซื้อหรือเชาคอมพิวเตอรโนตบุค
แลว ทีมงานอาจตองตัดสินใจฮารดแวรและซอฟตแวรที่ตองใชมีอะไร จะคิดเงินกับนักเรียนเทาไร จะ
จัดการอบรมและบํารุงรักษาเครื่องอยางไร จะบูรณาการการใชเทคโนโลยีใหมกับวิชาปจจุบันอยางไร ถา
รายงานจากขัน้ ตอนแรกเสนอวา คอมพิวเตอรโนตบุคเปนแนวความคิดที่ไมดีสําหรับวิทยาลัย ทีมงานก็
ไมตองทํางานในขั้นตอนที่สอง
ขั้นตอนที่สามของวงจรชีวิตของโครงการคือ การปฏิบัติงาน ในขั้นตอนนี้ ทีมงานประมาณการ
คาใชจายไดอยางถูกตอง และสงงานที่ตองการ มีการทํารายงานผลการทํางานตอผูม ีสวนไดเสีย สําหรับ
โครงการคอมพิวเตอรโนตบุคนั้น ทีมงานตองหาฮารดแวรและซอฟตแวร ติดตั้งอุปกรณเครือขาย สงมอบ
คอมพิวเตอรโนตบุคใหนกั เรียนและพนักงาน
ขั้นตอนสุดทายคือ ปดโครงการ งานทุกอยางเสร็จสมบรูณ ไดรับการยอมรับจากผูใชทั้ง
โครงการ ทีมงานบันทึกประสบการณที่ไดจากโครงการ ทีมงานอาจสํารวจความคิดเห็นของนักเรียนและ
พนักงานวิทยาลัย ตรวจสอบสัญญากับผูขายสินคาวาเสร็จสิ้นสมบรูณหรือไม จายเงินเรียบรอยหรือไม
สงมอบโครงการใหกับหนวยงานอื่นตอไป

2.7 วงจรชีวิตการพัฒนาซอฟตแวร
วงจรชีวิตการพัฒนาซอฟตแวรโดยปกติประกอบดวยขัน้ ตอน การวางแผน การวิเคราะห การ
ออกแบบ การสรางและติดตั้ง และการบํารุงรักษา ขั้นตอนดังกลาวไดถูกจัดการหลายรูปแบบ จึงทําให
เกิดวงจรชีวิตการพัฒนาซอฟตแวรรูปแบบตางๆ สวนใหญวงจรชีวิตการพัฒนาซอฟตแวรที่ใชกนั มีดังนี้
• วงจรชีวิตแบบน้ําตก (waterfall life cycle model) เปนการพัฒนาที่มีการกําหนด
ขั้นตอนการพัฒนาที่ชัดเจนคือ วิเคราะหระบบ ออกแบบระบบ พัฒนาระบบ ทดสอบ
ระบบ ติดตั้งระบบ และบํารุงรักษาระบบ ขั้นตอนตางๆ ทําแบบเรียงลําดับ วิธีการนีม้ ี
สมมุติฐานวาความตองการไมเปลี่ยนแปลงหลังจากไดกําหนดแลว
• วงจรชีวิตแบบกนหอย (spiral life cycle model) ไดพฒ
ั นาขึน้ จากประสบการณการใช
วิธีการพัฒนาแบบน้ําตก ในความเปนจริง วงจรชีวิตการพัฒนาซอฟตแวรเปนแบบซ้ําๆ
หรือกนหอยมากกวาแบบเรียงลําดับ โดยแตละงานที่ทาํ แบงออกเปน 4 สวนคือ
วางแผน วิเคราะหและขจัดความเสีย่ ง พัฒนางาน
• วงจรการพัฒนาแบบเพิ่ม (incremental development life cycle model) เปนการ
พัฒนาซอฟตแวรแบบกาวหนา สงมอบซอฟตแวรทลี่ ะสวน แลวคอยๆ เพิ่ม
ความสามารถของระบบไปเรื่อยๆ จนระบบมีความสามารถสมบูรณ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารโครงการและบริบทเทคโนโลยีสารสนเทศ หนา 2-14

• วงจรชีวิตแบบตนแบบ (prototyping life cycle model) เปนการพัฒนาซอฟตแวรโดย

การใชตนแบบในการทําความเขาใจความตองการของผูใ ชใหชัดเจน ทีมงานตอง
พัฒนาตนแบบใหผูใชเห็นและทดลองใช ถาผูใชยงั ไมพอใจ ทีมงานจะทําการแกไข แลว
นํามาใหผูใชพจิ ารณาใหม ถาผูใชพอใจตนแบบนัน้ ทีมงานจะนําตนแบบไปใชในการ
ออกแบบรายละเอียดของระบบที่แทจริง หรืออาจนําตนแบบนัน้ ไปติดตั้งใหกับผูใชเลย
ก็ได ทั้งนี้ขึ้นอยูกับโครงการ
• วงจรชีวิตการพัฒนาระบบงานแบบรวดเร็ว (rapid application development life
cycle model) เปนการพัฒนาโดยการใชเครื่องมือที่ชวยใหทีมงานพัฒนาซอฟตแวรได
อยางรวดเร็ว เชน CASE JAD ใชภาษา 4th GL การพัฒนาซอฟตแวรดวยวิธกี ารนี้ตอง
แลกเปลี่ยนกับคุณภาพของซอฟตแวร เนือ่ งจากตองจํากัดกิจกรรมทีต่ องดําเนินการให
เหลือนอยที่สดุ
• การโปรแกรมแบบเขมขน (extreme programming (XP)) เปนการพัฒนาซอฟตแวรที่
สอดคลองกับความตองการที่สภาวะแวดลอมเปลี่ยนอยางรวดเร็ว การพัฒนาดวยวิธนี ี้
จะใชทีมพัฒนาคูเพื่อสงเสริมการทํางานประสานกัน และเพิ่มประสิทธิภาพ ผูพัฒนา
ซอฟตแวรตองเขียนและทดสอบโปรแกรมเอง
• วงจรชีวิตแบบสกรัม (scrum life cycle model) เปนการพัฒนาแบบซ้ําๆ ที่เนนความ
ตองการทีเ่ ปลีย่ นแปลง แตละวันทีมงานทัง้ หมดจะประชุมกันชวงเวลาสัน้ ๆ วาวันนี้
จะตองทําอะไรใหสําเร็จ สมาชิกจะระบุอปุ สรรค และผูจัดการโครงการจะตองจัดการ
กับอุปสรรคนั้น วิธกี ารนี้ตองการผูน ําที่เขมแข็ง

2.8 วงจรชีวิตของโครงการกับวงจรชีวิตการพัฒนาซอฟตแวร
จากที่กลาวมาแลวขางตน เราจะเห็นไดวา วงจรชีวิตของโครงการและวงจรชีวิตการพัฒนา
ซอฟตแวรดูเหมือนวาจะคลายคลึงกัน แตวงจรชีวิตของโครงการเนนทีก่ ระบวนการการจัดการโครงการ
ขณะที่วงจรการพัฒนาซอฟตแวรเนนที่การสรางและการทําใหเกิดระบบสารสนเทศ จากรูปที่ 2.5 เราจะ
เห็นวาจริงๆ แลว วงจรชีวิตการพัฒนาซอฟตแวรเปนสวนหนึง่ ของวงจรชีวิตของโครงการ เพราะหลายๆ
กิจกรรมสําหรับการพัฒนาระบบสารสนเทศเกิดขึ้นระหวางเฟสการปฏิบัติงาน

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารโครงการและบริบทเทคโนโลยีสารสนเทศ หนา 2-15

รูปที่ 2.5 วงจรชีวิตของโครงการกับวงจรชีวิตการพัฒนาซอฟตแวร

(ปรับจาก Marchewka, 2006)

2.9 กลุมกระบวนการบริหารโครงการ
กระบวนการคือ ชุดของกิจกรรมที่เกี่ยวของกันเพื่อสรางหรือทําผลิตภัณฑหรือบริการตาม
ความตองการที่ไดกําหนด กระบวนการบริหารโครงการแบงออกเปน 5 กลุมคือ กลุมกระบวนการริเริ่ม
กลุมกระบวนการวางแผน กลุมกระบวนการปฏิบัติงาน กลุม กระบวนการติดตามและควบคุม และกลุม
กระบวนการปด กลุมกระบวนการเหลานี้มีปฏิกิรยิ าตอกัน ผลลัพธของกลุม กระบวนการหนึง่ จะ
กลายเปนขอมูลนําเขาของอีกกลุมกระบวนการ เชน กลุม กระบวนการติดตามและควบคุมเปน
กระบวนการทีค่ อยติดตามและควบคุมงานทีก่ ําลังทําระหวางกลุมกระบวนการหนึง่ ในขณะเดียวกัน
กลุมกระบวนการติดตามและควบคุมยังตองติดตามและควบคุมงานทัง้ โครงการ ผลลัพธจาก
กระบวนการนีจ้ ะนํามาเปนขอมูลยอนกลับไปสูการดําเนินการแกไข หรือปองกัน เพื่อใหสอดคลองกับ
แผนบริหารโครงการ การประยุกตกระบวนการบริหารโครงการเปนการทํางานซ้าํ ๆ และหลายๆ
กระบวนการถูกทําซ้ําและทบทวน ผูจัดการโครงการและทีมงานรับผิดชอบในการกําหนดวาจะใช
กระบวนการอะไรจากกลุมกระบวนการตางๆ และใครเปนคนทํา

2.9.1 กลุมกระบวนการริเริ่ม
กลุมกระบวนการริเริ่มประกอบดวยกระบวนการที่ชว ยใหมีการมอบอํานาจอยาง
เปนทางการเพื่อใหเริ่มโครงการใหมหรือเฟสของโครงการ บอยครั้งทีก่ ระบวนการริเริ่มทําโดยองคการ
หรือโดยกระบวนการจัดทําแผนงาน ซึ่งอาจกําหนดขอบเขตโครงการไมชัดเจน ขอบเขตนี้จะถูกนําไปเปน
ขอมูลเริ่มตนของโครงการ ตัวอยางเชน กอนเริ่มตนกิจกรรมของกลุมกระบวนริเริ่ม องคการตองกําหนด
ความจําเปนทางธุรกิจ หรือความตองการ ความเปนไปไดของโครงการใหมอาจดําเนินการผาน
กระบวนการประเมินทางเลือกเพื่อหยิบทางเลือกที่ดีที่สุด องคการตองสรางความชัดเจนของ
วัตถุประสงคของโครงการ รวมทั้งเหตุผลวาทําไมโครงการนี้จึงเปนทางเลือกทีด่ ีที่สุดที่จะตอบสนอง
ความตองการ กรอบการทํางานของโครงการจะชัดเจน ถามีการบันทึกกระบวนการเลือกโครงการ
สําหรับโครงการที่มหี ลายเฟส กระบวนการริเริ่มจะถูกดําเนินการระหวางเฟสถัดไป เพื่อตรวจสอบ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารโครงการและบริบทเทคโนโลยีสารสนเทศ หนา 2-16

สมมุติฐานและการตัดสินใจที่ไดทําขึน้ ระหวางกระบวนการพัฒนาเอกสารสิทธิ์โครงการ และ

กระบวนการพัฒนาขอกําหนดโครงการเบื้องตน ในตอนแรก
โครงการขนาดใหญ หรือซับซอนอาจแบงโครงการเปนเฟสๆ การทบทวน
กระบวนการริเริ่มตอนตนของแตละเฟสชวยรักษาจุดเนนความจําเปนทางธุรกิจที่โครงการไดกําหนดไว
เงื่อนไขการเขาสูกระบวนการไดรับการตรวจสอบ รวมทั้งการมีทรัพยากที่ตองการ จากนัน้ ผูจ ัดการ
โครงการจึงตัดสินใจวาโครงการพรอมที่จะเดินตอไปหรือไม หรือโครงการควรยืดเวลาออกไป หรือยุติ
ระหวางเฟสถัดไปของโครงการ การตรวจสอบความถูกตอง และการพัฒนาขอบเขตโครงการยังคง
ดําเนินการตอไป การทํากระบวนการริเริม่ ซ้ําในแตละเฟสถัดไปชวยหยุดโครงการ ถาองคการไมตองการ
โครงการนั้นอีกตอไป
โดยทัว่ ไป การใหลูกคา และผูมีสวนไดเสียอื่นๆ เขามามีสวนรวมในชวงแรกๆ จะทํา
ใหโอกาสของการเปนเจาของโครงการรวมกัน การยอมรับสิ่งที่สง มอบ และความพึงพอใจของลูกคาและ
ผูมีสวนไดเสียอื่นๆ ดีขึ้น เนือ่ งจากการยอบรับดังกลาวมีความสําคัญตอโครงการ กลุมกระบวนการริเริ่ม
เปนกระบวนการที่ทาํ ใหโครงการ หรือเฟสโครงการเริ่มตน และผลลัพธของกลุมกระบวนการนีเ้ ปนการ
กําหนดความมุงหมาย วัตถุประสงคโครงการ และใหอํานาจกับผูจัดการโครงการใหเริ่มตนโครงการ
กระบวนการทีจ่ ัดอยูในกลุมนี้คือ การพัฒนาเอกสารสิทธิ์โครงการ และการพัฒนาขอกําหนดขอบเขต
โครงการเบื้องตน

2.9.2 กลุมกระบวนการวางแผน
กลุมกระบวนการวางแผนชวยรวบรวมสารสนเทศจากหลายๆ แหลง เพื่อจัดทําเปน
แผนบริหารโครงการ กลุม กระบวนการนี้ประกอบดวยกระบวนการที่สําคัญคือการระบุ การกําหนด
ขอบเขตโครงการ คาใชจาย และตารางเวลาโครงการ เนื่องจากมีการพบขอมูลใหมๆ การวิเคราะหเพิ่ม
จึงตองทําหลายรอบ ดังนั้น การเปลี่ยนแปลงอยางมีนัยสําคัญที่เกิดขึน้ ตลอดวงจรชีวิตโครงการเปนสิ่งที่
ทําใหทีมงานโครงการจําเปนตองกลับไปทํากระบวนการวางแผนใหม หรืออาจตองกลับไปทํากระบวน
การริเริ่มบางกระบวนการ
การย้ํากระบวนการวางแผนบอยๆ มีผลกระทบตอแผนบริหารโครงการ แผนบริหาร
โครงการที่ไดรับการปรับปรุงจะใหขอมูลทีเ่ มนยํามากขึ้น รวมทั้งยังจํากัดกิจกรรมหรือประเด็นที่เกีย่ วของ
กับการดําเนินการของเฟส ขณะที่วางแผนโครงการ ทีมงานโครงการควรใหผูมีสวนไดเสียที่เหมาะสมเขา
มามีสวนรวม เพราะบุคคลเหลานี้มที กั ษะและความรูในการพัฒนาแผนบริหารโครงการและแผนยอย
เนื่องจากกระบวนการกลัน่ กรองและขอมูลยอนกลับไมสามารถทําไดตลอด องคการจึงควรมีการกําหนด
ขั้นตอนการยุติกระบวนการวางแผน

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารโครงการและบริบทเทคโนโลยีสารสนเทศ หนา 2-17

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

2.9.3 กลุมกระบวนการปฏิบัตงิ าน
กลุมกระบวนการปฏิบัติงานประกอบดวยกระบวนการที่ทาํ ใหงานทีก่ าํ หนดในแผน
บริหารโครงการเสร็จสมบูรณตามความตองการของโครงการ ทีมงานโครงการควรกําหนดกระบวนการ
อะไรที่ตองการใชสําหรับโครงการ กลุมกระบวนการนีเ้ กี่ยวของกับการประสานคนและทรัพยากร รวมทั้ง
การบรูณาการและดําเนินกิจกรรมของโครงการใหเปนไปตามแผนบริหารโครงการ
ความแปรปรวนจากการปฏิบัติงานเปนสาเหตุใหทีมงานโครงการตองทําการวาง
แผนใหม ความแปรปรวนนี้อาจเปน ระยะเวลาของกิจกรรม ทรัพยากรที่มีให หรือความเสี่ยงที่ไม
สามารถคาดการณได ความแปรปรวนเหลานี้อาจกระทบ หรือไมกระทบแผนบริหารโครงการก็ได แต
ทีมงานตองวิเคราะหความแปรปรวน ผลการวิเคราะหสามารถทําใหเกิดคําขอเปลี่ยนแปลงที่อาจปรับ
แผนการบริหารโครงการ และสรางบรรทัดฐานใหม ถึงแมวา กลุมกระบวนการปฏิบัติงานเปนสวนหนึ่ง
ของทุกๆ เฟสของโครงการ แตสวนใหญแลว กระบวนการปฏิบัติงานจะเกิดขึ้นระหวางเฟสปฏิบัติงาน
ของวงจรชีวิตโครงการ

2.9.4 กลุมกระบวนการติดตามและควบคุม
กลุมกระบวนการติดตามและควบคุมประกอบดวยกระบวนการทีเ่ ฝาดูการปฏิบัติ
งานของโครงการ ดังนัน้ ทีมงานโครงการสามารถระบุปญหาที่อาจจะเกิดไดทนั เวลา และกําหนดวิธีการ
หรือการกระทําเพื่อแกไข เพือ่ ควบคุมการดําเนินโครงการ ทีมงานโครงการควรกําหนดกระบวนการอะไร
ที่ตองใชสําหรับโครงการโดยเฉพาะ ประโยชนที่สาํ คัญที่ไดจากกลุม กระบวนการนี้คือ การดําเนิน
โครงการไดรับการเฝาดู และวัดอยางสม่าํ เสมอ เพื่อระบุความแปรปรวนจากแผนบริหารโครงการ กลุม
กระบวนการติดตามและควบคุมยังรวมถึงการควบคุมการเปลี่ยนแปลง และการแนะนําวิธีการปองกัน
ปญหาที่อาจเกิดขึ้น
การติดตามอยางตอเนื่องทําใหทีมงานโครงการไดเขาใจลึกซึ้งถึงสถานของ
โครงการ และชี้ใหเห็นสวนที่ตองการความเอาใจใสเพิม่ กลุมกระบวนการนี้ไมไดติดตามและควบคุม
เฉพาะงานที่กาํ ลังทําภายในกลุมกระบวนหนึง่ ๆ เทานัน้ แตยงั ติดตามและควบคุมการทํางานของทั้ง
โครงการ ในกรณีที่โครงการมีหลายเฟส กลุมกระบวนการติดตามและควบคุมยังใหขอมูลยอนกลับ
ระหวางเฟส เพื่อใหการแกไขและการปองกันสามารถนําโครงการกลับมาใหสอดคลองกับแผนบริหาร

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารโครงการและบริบทเทคโนโลยีสารสนเทศ หนา 2-18

โครงการ ถาความแปรปรวนทําลายวัตถุประสงคโครงการ ทีมงานโครงการควรกลับไปยังกระบวนการ

วางแผนที่อยูในกลุมกระบวนการวางแผน การทบทวนใหขอเสนอการปรับปรุงแผนบริหารโครงการ

2.9.5 กลุมกระบวนการปด
กลุมกระบวนการปดรวมถึงกระบวนที่ใชเพื่อยุติทกุ กิจกรรมอยางเปนทางการของ
โครงการหรือเฟสหนึ่งของโครงการ กลุมกระบวนการนี้สอบทวนวากระบวนการที่กําหนดในทุกกลุม
กระบวนเสร็จสมบูรณ เพื่อปดโครงการ หรือเฟสของโครงการ

2.9.6 ความสัมพันธระหวางกลุม กระบวนการกับวงจรชีวติ โครงการ

จากรูปที่ 2.6 แสดงกลุมกระบวนการและความสัมพันธระหวางในแงของระดับของ
กิจกรรมปกติ กรอบเวลา และการทับซอน ระดับของกิจกรรมและชวงเวลาของแตละกลุมกระบวนการ
แตกตางกันทุกโครงการ โดยปกติ กลุมกระบวนการริเริม่ จะดําเนินการในตอนเริ่มโครงการ ตามดวยกลุม
กระบวนการวางแผน กลุม กระบวนการปฏิบัติงาน กลุมกระบวนการติดตามและควบคุม และกลุม
กระบวนการปด โดยปกติ กระบวนการปฏิบัติงานตองการทรัพยากรและเวลาประมาณรอยละ 50-60
ตามดวยกระบวนการวางแผน ซึง่ ใชเวลาประมาณรอยละ 15-25 สวนกระบวนการริเริ่มและกระบวนการ
ปดใชเวลาและทรัพยากรนอยที่สุด ประมาณรอยละ 5-10 การติดตามและควบคุมที่ดําเนินการตลอด
โครงการ โดยทั่วไปใชประมาณรอยละ 5-15 ของเวลาและทรัพยากรทัง้ หมด อยางไรก็ตาม ทุกโครงการ
มีเอกลักษณ ดังนัน้ จึงอาจมีขอยกเวนไมเปนไปตามที่กลาว

รูปที่ 2.6 ระดับของกิจกรรมและการคาบเกี่ยวกันของกลุมกระบวนการตลอดเวลาโครงการ

(Schwalbe, 2007)

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารโครงการและบริบทเทคโนโลยีสารสนเทศ หนา 2-19

กลุมกระบวนการไมใชเฟสของวงจรชีวิตของโครงการ กระบวนการของกลุม
กระบวนการไมตองทําเรียงตามลําดับดังกลาวขางตน เพียงแตโดยสวนใหญแลว กระบวนการของแตละ
กลุมกระบวนการจะปฏิบัติเรียงลําดับ รูปที่ 2.7 แสดงใหเห็นถึงความสัมพันธของกลุมกระบวนการกับ
วงจรชีวิตของโครงการ เชน กระบวนการบางกระบวนของกลุมกระบวนการติดตามและควบคุมจะมีการ
ดําเนินการตั้งแตชวงเวลาตนๆ เชน ในการพัฒนาเอกสารสิทธิ์โครงการ ผูจัดการโครงการตองติดตามวา
ทีมงานและผูม ีสวนไดเสียดําเนินการไปตามแผนบริหารโครงการหรือไม กระบวนการติดตามการพัฒนา
เอกสารสิทธิ์โครงการจึงเกิดขึ้นระหวางเฟสแนวความคิดของวงจรชีวติ โครงการ กระบวนการวางแผนก็
เชนเดียวกันทีอ่ าจตองมีการทบทวน ปรับปรุงแผนใหมในชวงกลางของโครงการ เปนตน ดังนัน้ ทุกเฟส
ของวงจรชีวิตของโครงการจะมีทกุ กลุมกระบวนการ แตจํานวนกระบวนการของแตละกลุมกระบวนการ
แตกตางกันไปในแตละเฟสของวงจรชีวิตของโครงการ

รูปที่ 2.7 กลุม กระบวนการกับวงจรชีวติ โครงการ

2.9.7 ความสัมพันธระหวางกลุม กระบวนการกับความรูการบริหารโครงการ

เราสามารถจัดกระบวนการของแตละกลุมกระบวนการเขากับความรูก ารบริหาร
โครงการทั้ง 9 ดาน ตารางที่ 2.2 แสดงภาพรวมของความสัมพันธของกระบวนการบริหารโครงการทั้ง 44
กระบวนการของกลุมกระบวนการที่โดยปกติจะถูกดําเนินการใหเสร็จสมบูรณกับความรู 9 ดาน
กระบวนการทีแ่ สดงในตารางเปนกระบวนการหลักที่ไดกาํ หนดใน PMBOK® Guide Third Edition
หลายๆ องคการใชสารสนเทศของสถาบันบริหารโครงการ (Project Management Institute (PMI)) เปน
พื้นฐานสําหรับการพัฒนาระเบียบวิธีการบริหารโครงการของตนเอง

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารโครงการและบริบทเทคโนโลยีสารสนเทศ หนา 2-20

ตารางที่ 2.2 ภาพรวมของความสัมพันธของกระบวนการบริหารโครงการกับความรู 9 ดาน

กลุมกระบวนการบริหารโครงการ
ความรู
ริเริ่ม วางแผน ปฎิบัติงาน ติดตามและควบคุม ปด
การบริหาร พัฒนาเอกสารสิทธิ์ พัฒนาแผนบริหารโครงการ กํากับและบริหารการ ติดตามและควบคุม ปดโครงการ
การบูรณา โครงการ ปฏิบัติงานโครงการ งานของโครงการ
การ พัฒนาขอกําหนด ควบคุมการ
ขอบเขตโครงการ เปลี่ยนแปลงแบบ
เบื้องตน บูรณาการ
การบริหาร วางแผนขอบเขต ทวนสอบขอบเขต
ขอบเขต กําหนดขอบเขต ควบคุมขอบเขต
โครงการ สรางโครงสรางจําแนกงาน
การบริหาร กําหนดกิจกรรม ควบคุมตารางเวลา
เวลา เรียงลําดับกิจกรรม
ประมาณการทรัพยากรของ
กิจกรรม
ประมาณการระยะเวลาของ
กิจกรรม
พัฒนาตารางเวลา
การบริหาร ประมาณการคาใชจาย ควบคุม
คาใชจาย ตั้งงบประมาณคาใชจาย คาใชจาย
การบริหาร วางแผนคุณภาพ ดําเนินการประกัน ดําเนินการควบคุม
คุณภาพ คุณภาพ คุณภาพ
การบริหาร วางแผนทรัพยากรมนุษย คนหาทีมงานโครงการ บริหารทีมงาน
ทรัพยากร พัฒนาทีมงานโครงการ โครงการ
มนุษย
การบริหาร วางแผนการสื่อสาร กระจายสารสนเทศ รายงานผลการ
การสื่อสาร ปฏิบัติงาน
บริหารผูมีสวนไดเสีย
การบริหาร วางแผนบริหารความเสี่ยง ควบคุมและติดตาม
ความเสี่ยง ระบุความเสี่ยง ความเสี่ยง
วิเคราะหความเสี่ยงเชิง
คุณภาพ
วิเคราะหความเสี่ยงเชิง
ปริมาณ
วางแผนตอบสนองความเสี่ยง
การบริหาร วางแผนการจัดซื้อและการ ขอคําตอบจากผูขาย บริหารสัญญา ปดสัญญา
การจัดซื้อจัด ไดมา เลือกผูขาย
จาง วางแผนการทําสัญญา

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารโครงการและบริบทเทคโนโลยีสารสนเทศ หนา 2-21

2.10 บริบทของโครงการเทคโนโลยีสารสนเทศ
ธรรมชาติของโครงการเทคโนโลยีสารสนเทศมีความหลากหลาย ตั้งแตโครงการที่เนน
ฮารดแวรประเภทคอมพิวเตอรสวนบุคคลไปจนถึงเครื่องคอมพิวเตอรขนาดใหญ รวมทั้งอุปกรณเคลื่อนที่
สวนโครงการพัฒนาซอฟตแวรมีความหลากหลายเชนเดียวกัน ตั้งแตการพัฒนาซอฟตแวรดวย Excel
บนเครื่องคอมพิวเตอรที่ไมเชือ่ มตอกับเครือขาย ระบบพาณิชยอิเล็กทรอนิกสที่ใชภาษาทีท่ นั สมัย
โครงการเทคโนโลยีสารสนเทศยังสนับสนุนทุกอุตสาหกรรม และงานทางธุรกิจ การบริหารโครงการ
เทคโนโลยีสารสนเทศแตละอุตสาหกรรมจะไมเหมือนกัน
เนื่องจากธรรมชาติของโครงการเทคโนโลยีสารสนเทศทีห่ ลากหลาย จึงสงผลใหคนที่เกี่ยวของ
กับโครงการมีภูมิหลังที่หลากหลาย มีทักษะที่แตกตางกัน สมาชิกในทีมอาจจบดานธุรกิจ คณิตศาสตร
หรือศิลปศาสตร เพื่อใหมมุ มองที่ตางกัน ถึงแมจะมีพื้นความรูท ี่ไมเหมือนกัน แตตําแหนงในโครงการ
เหมือนกัน เชน นักวิเคราะหธุรกิจ โปรแกรมเมอร ผูเชี่ยวชาญเครือขาย นักวิเคราะหฐานขอมูล
ผูเชี่ยวชาญการประกันคุณภาพ ผูเชี่ยวชาญดานความปลอดภัย วิศวกรฮารดแวร วิศวกรซอฟตแวร การ
ที่โครงการเทคโนโลยีสารสนเทศตองการคนที่มที ักษะ แตบุคคลที่มีความเชี่ยวชาญไมชอบอยูในองคการ
หนึง่ ๆ นาน หลายๆ โครงการจึงจางคนที่มคี วามเชีย่ วชาญจากภายนอกเขามารวมโครงการ
ตําแหนงทางดานเทคโนโลยีสารสนเทศอาจสะทอนถึงเทคโนโลยีที่ตางกันที่ผูดํารงตําแหนงตอง
มีทักษะในเทคโนโลยีนั้นๆ จึงทําใหสมาชิกแตละคนไมเขาใจซึ่งกันและกัน เพราะแตละคนใชเทคโนโลยีที่
ตางกัน ความหลากหลายในเทคโนโลยีทาํ ใหเกิดปญหาคือ การเปลีย่ นแปลงอยางรวดเร็ว โครงการกําลัง
จบในขณะทีท่ มี คนพบเทคโนโลยีใหมที่ทาํ ใหโครงการตรงกับความตองการทางธุรกิจในระยะยาว
ผูจัดการโครงการ และสมาชิกในทีมจึงเผชิญกับงานที่ทา ทาย

2.11 สรุป
ในการทํางานของโครงการ ผูจัดการโครงการจําเปนตองใชวิธีการเชิงระบบ และจําเปนตอง
พิจารณาโครงการที่มากกวาบริบทเชิงองคการ
องคการมี 4 กรอบที่แตกตางกันคือ โครงสราง ทรัพยากรมนุษย การเมือง และสัญลักษณ
ผูจัดการโครงการจําเปนตองเขาใจกรอบองคการเหลานี้ กรอบโครงสรางเนนความแตกตางของบทบาท
และความรับผิดชอบของกลุม เพื่อใหบรรลุเปาหมายและนโยบายที่กาํ หนดโดยผูบริหารระดับสูง กรอบ
ทรัพยากรมนุษยเนนที่การสรางความกลมกลืนระหวางความตองการขององคการและความตองการของ
คน กรอบการเมืองกลาวถึงการเมืองขององคการและของบุคคล สวนกรอบสัญลักษณเนนที่สัญลักษณ
และความหมาย

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารโครงการและบริบทเทคโนโลยีสารสนเทศ หนา 2-22

โครงสรางขององคการหนึง่ ๆ มีนยั ยะที่สาํ คัญตอผูจัดการโครงการ โดยเฉพาะในแงของขนาด

ของอํานาจที่ผจู ัดการโครงการมี โครงสรางพืน้ ฐานองคการมี 3 แบบคือ โครงสรางตามหนาที่ แมทริกซ
และโครงการ ผูจัดการโครงการจะมีอาํ นาจมากที่สุดในโครงสรางแบบโครงการ รองลงมาคือ โครงสราง
แบบแมทริกซ และมีอํานาจนอยที่สุดในโครงสรางตามหนาที่
วัฒนธรรมองคการกระทบตอการบริหารโครงการเชนเดียวกัน วัฒนธรรมที่พนักงานมีความเปน
สมาชิกที่เขมแข็ง วัฒนธรรมที่กิจกรรมงานเนนงานแบบกลุม วัฒนธรรรมที่มีการบูรณาการเปนหนวย
เดียวที่สงู ระดับการยอมรับความเสีย่ งสูง ใหรางวัลตามผลงาน ระดับการยอมรับความขัดแยงสูง เนน
ระบบเปด และเนนสมดุลเกี่ยวกับคน การควบคุม และวิธีการ เปนวัฒนธรรมที่โครงการอยากใหมี
มากกวาวัฒนธรรมองคการแบบอื่นๆ
ผูมีสวนไดเสียของโครงการคือ บุคคลและหนวยงานทีเ่ กีย่ วของกับโครงการ หรือความสนใจของ
เขาเหลานัน้ อาจถูกกระทบทั้งทางบวกหรือทางลบ อันเปนผลจากการทําโครงการ หรือความเสร็จ
สมบูรณของโครงการ ผูจัดการโครงการตองกําหนดผูมสี วนไดเสีย และเขาใจความตองการที่แตกตางกัน
ของผูมีสวนไดเสียของโครงการทั้งหมด
คํามั่นสัญญาของผูบริหารระดับสูงมีความสําคัญตอความสําเร็จของโครงการ เนื่องจาก
โครงการกระทบหลายสวนในองคการ ผูบ ริหารระดับสูงตองชวยเหลือผูจัดการโครงการ คํามัน่ องคการ
ตอโครงการเทคโนโลยีสารสนเทศก็มีความสําคัญเชนเดียวกัน การพัฒนามาตรฐานและแนวทางชวย
องคการในการบริหารโครงการ
วงจรชีวิตโครงการคือ ขั้นตอนโครงการ ขั้นตอนโครงการแบบดั้งเดิมประกอบดวย แนวความคิด
การพัฒนา การปฏิบัติงาน และการปดโครงการ วงจรชีวิตการพัฒนาซอฟตแวรประกอบดวย วงจรชีวิต
แบบน้ําตก แบบกนหอย การพัฒนาแบบเพิ่มขึ้น แบบเรงดวน การโปรแกรมอยางเขมขน และการพัฒนา
แบบสกรัม ผูจ ัดการโครงการตองเขาใจวงจรชีวิตแตละแบบ วงจรชีวติ การพัฒนาซอฟตแวรเปนสวนหนึง่
ของวงจรชีวิตโครงการ
โครงการควรทํางานแตละขั้นตอนใหสําเร็จเพื่อสงตอไปยังขั้นตอนตอไป การทบทวนการบริหาร
ควรเกิดขึ้นเมือ่ จบแตละขั้นตอน เพื่อใหโครงการยังคงเปนไปตามที่วางแผนไว และเพื่อกําหนดวา
โครงการควรทําตอ เปลี่ยนทิศทาง หรือยุติ
การบริหารโครงการประกอบดวยกระบวนการจํานวนหนึ่งที่เชื่อมโยงกัน กระบวนการบริหาร
โครงการจัดเปน 5 กลุมกระบวนการคือ กลุมกระบวนการริเริ่ม กลุมกระบวนการวางแผน กลุม
กระบวนการปฏิบัติงาน กลุม กระบวนการติดตามและควบคุม และกลุมกระบวนการปด ระดับการเกิด
กระบวนการเหลานี้แตกตางกันในแตละเฟสของโครงการ และทุกกลุมกระบวนการจะเกิดในทุกเฟสของ
โครงการ ดังนั้น กลุมกระบวนการจึงไมใชเฟสของวงจรชีวิตของโคงการ โดยปกติ กลุมกระบวนการ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารโครงการและบริบทเทคโนโลยีสารสนเทศ หนา 2-23

ปฏิบัติงานตองใชเวลาและทรัพยากรมากที่สุด ตามดวยกลุมกระบวนการวางแผน การจัดกระบวนการ

บริหารโครงการหลักของแตละกลุมกระบวนการเขากับความรู 9 ดานใหภาพรวมวากระบวนการอะไร
เกี่ยวของกับความรูการบริหารโคงการดานใด
ผูจัดการโครงการตองพิจารณาหลายๆ ปจจัย เนื่องจากบริบทโครงการเทคโนโลยีสารสนเทศไม
ซ้ํากัน ธรรมชาติที่แตกตางกันของโครงการและความหลากหลายในธุรกิจและเทคโนโลยีที่พวั พันกับ
โครงการ โดยเฉพาะการทาทายตอการบริหาร การนําทีมงานที่มีสมาชิกที่มที ักษะเฉพาะ และความ
เขาใจการเปลีย่ นแปลงเทคโนโลยีอยางรวดเร็ว เปนปจจัยที่สําคัญ

คําถามทายบท
1. จงอธิบายการนํามุมมองแบบระบบมาใชกับการบริหารโครงการ
2. อธิบายกรอบองคการ 4 กรอบ
3. กรอบองคการทําใหผูจัดการโครงการเขาใจบริบทเชิงองคการสําหรับโครงการที่รับผิดชอบ
อยางไร
4. อธิบายความแตกตางระหวางโครงสรางองคการแบบฟงกชัน แมทริกซ และโครงการ
5. อธิบายโครงสรางองคการแตละแบบกระทบตอการบริหารโครงการอยางไร
6. จงอธิบายวัฒนธรรมองคการมีความสัมพันธอยางไรกับการบริหารโครงการ
7. จงอธิบายความสําคัญของคํามั่นสัญญาของผูบริหารระดับสูงตอความสําเร็จของโครงการ
8. อธิบายความแตกตางระหวางวงจรชีวิตโครงการกับวงจรชีวิตการพัฒนาซอฟตแวร
9. จงอธิบายความสัมพันธระหวางกลุมกระบวนการกับวงจรชีวิตของโครงการ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการบูรณาการโครงการ หนา 3-1

3.1 บทนํา
การบริหารการบูรณาการเกีย่ วของกับการประสานองคความรูการบริหารโครงการดานตางๆ
ตลอดวงจรชีวติ ของโครงการ การบูรณาการนี้ทาํ ขึ้นเพื่อใหแนใจวาทุกชิ้นสวนของโครงการเกิดขึน้ พรอม
กัน ณ เวลาที่เหมาะสม เพื่อใหโครงการประสบความสําเร็จอยางสมบูรณ การบูรณาการประกอบดวย
กระบวนการหลัก 7 กระบวนการ คือ
• พัฒนาเอกสารสิทธิ์โครงการ (develop the project charter) เปนการทํางานกับผูมี
สวนไดเสีย เพือ่ จัดทําเอกสารที่อนุมัติโครงการอยางเปนทางการ
• พัฒนาขอบเขตงานเบื้องตน (develop the preliminary project scope statement)
เปนการพัฒนาขอกําหนดขอบเขตโครงการ ซึ่งเปนการเขียนอธิบายขอกําหนดในระดับสูง
• พัฒนาแผนการบริหารโครงการ (develop the project management plan) เปนการ
จัดทําเอกสารเพื่อบันทึกการกระทําที่จาํ เปนสําหรับ กําหนด เตรียมการ บูรณาการ และ
ประสาน แผนยอยทัง้ หมดใหเปนแผนบริหารโครงการ
• กํากับและบริหารการปฏิบตั ิงานโครงการ (direct and manage project execution)
เปนการปฏิบัติงานตามกิจกรรมของโครงการทีว่ างแผนไว เพื่อบรรลุความตองการของ
โครงการที่ไดกําหนดในขอกําหนดขอบเขตโครงการ
• ติดตามและควบคุมงานโครงการ (monitor and control the project work) เปนการ
ติดตามและควบคุมกระบวนการที่ดําเนินการในระยะตางๆ ของโครงการ เพื่อใหตรงกับ
วัตถุประสงคทกี่ ําหนดในแผนบริหารโครงการ
• ดําเนินการควบคุมการเปลี่ยนแปลงแบบบูรณาการ (perform integrated change
control) เปนการทบทวนคําขอเปลี่ยนแปลง การอนุมัตกิ ารเปลี่ยนแปลง และควบคุมการ
เปลี่ยนแปลงที่จะเกิดกับสิ่งที่สงมอบ (deliverables)
• ปดโครงการ (close the project) เปนการสิ้นสุดการกิจกรรมทั้งหมดของโครงการ เพื่อ
ปดโครงการอยางเปนทางการ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการบูรณาการโครงการ หนา 3-2

กอนที่จะทําการพัฒนาเอกสารสิทธิ์โครงการอยางเปนทางการ องคการตองเลือกโครงการที่จะ
ทํา โดยผานกระบวนการตัดสินใจอยางเปนทางการ การเลือกโครงการจะไดกลาวในหัวขอตอไป
ขั้นตอนการวางแผน
ผลลัพธที่ได
เทคโนโลยีสารสนเทศ

เชื่อมโยงยุทธศาสตรเทคโนโลยีสารสนเทศกับพันธกิจและ
การวางแผน วิสัยทัศนขององคการ
ยุทธศาสตร
เทคโนโลยี กําหนดสวนธุรกิจหลัก
สารสนเทศ
บันทึกกระบวนการธุรกิจหลักที่สามารถไดประโยชนจาก
การวิเคราะหธุรกิจ เทคโนโลยีสารสนเทศ
กําหนดโครงการที่มีศักยภาพ
การวางแผนโครงการ
กําหนดขอบเขตโครงการ ประโยชน และ ขอจํากัด
การจัดสรรทรัพยากร เลือกโครงการเทคโนโลยีสารสนเทศ
มอบหมายทรัพยากร

รูปที่ 3.1 แสดงกระบวนการวางแผนสําหรับการเลือกโครงการเทคโนโลยี

สารสนเทศ (Schwalbe, 2007)

3.2 การวางแผนเชิงยุทธศาสตร และการเลือกโครงการ

3.2.1 การกําหนดโครงการทีม่ ีศกั ยภาพ

รูปที่ 3.1 แสดงกระบวนการวางแผนสําหรับการเลือกโครงการเทคโนโลยีสารสนเทศ ใน
ขั้นตอนแรกคือ การเชื่อมโยงแผนยุทธศาสตรเทคโนโลยีสารสนเทศกับแผนยุทธศาสตรขององคการ การ
วางแผนยุทธศาสตรเปนการกําหนดวัตถุประสงคระยะยาว โดยการวิเคราะหจุดออนจุดแข็งขององคการ
การศึกษาโอกาสและสิ่งคุกคาม การทํานายแนวโนมในอนาคต การคาดการณความตองการสําหรับ
ผลิตภัณฑใหมหรือบริการใหม ดังนัน้ ในกระบวนการวางแผนเทคโนโลยีสารสนเทศจึงจําเปนที่ตองมี
ผูจัดการจากหนวยงานอืน่ ที่ไมใชหนวยงานเทคโนโลยีสารสนเทศมาชวย เพราะจะชวยคนดาน
เทคโนโลยีสารสนเทศเขาใจยุทธศาสตรองคการ และกําหนดกลุม ธุรกิจที่สามารถสนับสนุนแผน
เทคโนโลยีสารสนเทศ
หลังจากกําหนดเปาหมายเชิงยุทธศาสตรแลว ขั้นตอนตอไปสําหรับการวางแผนคือ
การเลือกโครงการเทคโนโลยีสารสนเทศโดยการวิเคราะหเชิงธุรกิจ การวิเคราะหนี้วางโครงราง
กระบวนการธุรกิจที่เกีย่ วของกับการบรรลุเปาหมายเชิงยุทธศาสตร และชวยกําหนดวากระบวนการ
ธุรกิจใดไดประโยชนจากเทคโนโลยีสารสนเทศมากที่สดุ ขั้นตอนถัดไปคือ เริ่มตนการกําหนดโครงการ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการบูรณาการโครงการ หนา 3-3

เทคโนโลยีสารสนเทศที่มีศักยภาพ พรอมกับขอบเขตโครงการ ประโยชน ขอจํากัด สวนขั้นตอนสุดทาย

คือ การเลือกโครงการที่จะนํามาดําเนินการ และการกําหนดทรัพยากรสําหรับการดําเนินโครงการ

3.2.2 การเชื่อมโยงเทคโนโลยีสารสนเทศใหสอดคลองกับยุทธศาสตรทางธุรกิจ
การกําหนดและการเลือกโครงการเทคโนโลยีที่เหมาะสมจะงายขึ้น ถาองคการทําให
เทคโนโลยีสารสนเทศสอดคลองกับธุรกิจ แผนยุทธศาสตรขององคการควรชี้นํากระบวนการเลือก
โครงการเทคโนโลยีสารสนเทศ องคการตองพัฒนายุทธศาสตรการใชเทคโนโลยีสารสนเทศ เพื่อกําหนด
วายุทธศาสตรนี้จะสนับสนุนวัตถุประสงคขององคการอยางไร ยุทธศาสตรเทคโนโลยีสารสนเทศตองทํา
ใหสอดคลองกับแผนยุทธศาสตรทางธุรกิจขององคการ
วิธีการที่ใชในการทําใหโครงการเทคโนโลยีสารสนเทศเปนไปในทิศทางเดียวกับแผน
ยุทธศาสตรทางธุรกิจขององคการคือ แนวความคิดที่เนนการใชเทคโนโลยีสารสนเทศสนับสนุนแผน
ยุทธศาสตรและทําใหไดเปรียบเชิงการแขงขัน

3.2.3 การเลือกโครงการ
องคการสวนใหญเชื่อในการตัดสินใจเลือกโครงการของผูจ ัดการโครงการที่มี
ประสบการณ อยางไรก็ตามองคการจําเปนตองกําหนดรายชื่อโครงการที่มีศกั ยภาพใหแคบลง การเลือก
โครงการมีเทคนิคทีน่ ิยมใชกนั 5 เทคนิคคือ การเนนทีค่ วามตองการขององคการ การจัดกลุมโครงการ
เทคโนโลยีสารสนเทศ การวิเคราะหดานการเงิน การใชตัวแบบใหคะแนนถวงน้ําหนัก และการใชบัตร
คะแนนสมดุล (balanced scorecard)

การเนนที่ความตองการขององคการ
เมื่อตองตัดสินใจวาโครงการใดไดรับการคัดเลือก ผูบริหารระดับสูงตองเนน
โครงการที่ตรงกับความตองการของหนวยงานสวนใหญขององคการ โครงการทีก่ ลาวถึงความตองการ
ขององคการในแนวกวางมีโอกาสทีจ่ ะไดรับการคัดเลือก เพราะเปนโครงการทีม่ ีความสําคัญตอองคการ
วิธีการหนึ่งที่จะเลือกโครงการตามเทคนิคนีค้ ือ พิจารณาวาโครงการตรงกับเงื่อนไขทีส่ ําคัญ 3 ขอหรือไม
เงื่อนไขที่สาํ คัญคือ ความตองการ เงิน และความตัง้ ใจ คนในองคการเห็นรวมกันถึงความตองการ
โครงการหรือไม องคการมีความตัง้ ใจและมีกําลังที่จะสนับสนุนเงินสําหรับการทําโครงการหรือไม คนใน
องคการมีความตั้งใจสูงที่จะทําใหโครงการสําเร็จหรือไม ขณะที่โครงการดําเนินการ องคการตองทําการ
ประเมินความตองการ การเงิน และความตั้งใจของแตละโครงการใหม เพื่อดูวา โครงการควรทําตอ หรือ
ยุติ หรือตองกลับมานิยามความตองการใหม

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการบูรณาการโครงการ หนา 3-4

การจัดกลุมโครงการเทคโนโลยีสารสนเทศ
การจัดกลุมโครงการเทคโนโลยีสารสนเทศเพื่อใชประเมินโครงการอาจจัดกลุม
ออกเปนโครงการประเภทสนองตอบตอปญหา โอกาส หรือ เปนโครงการที่สงั่ ใหดําเนินการ
ปญหาคือ สถานการณที่ไมนาพอใจที่ขดั ขวางไมใหองคการบรรลุเปาหมาย
ปญหาอาจเปนปญหาทีม่ ีในปจจุบันหรือปญหาที่คาดวาอาจจะเกิดในอนาคต เชน ผูใชโครงการอาจ
ประสบปญหาการเขาไปใชระบบสารสนเทศ หรือเขาใชขอมูลที่ทนั สมัย เพราะระบบไดถูกใชเต็มกําลัง
แลว การตอบสนองปญหาดังกลาว องคการสามารถริเริ่มโครงการเพื่อขยายระบบปจจุบัน โดยการเพิ่ม
เสนทางการเขาถึง หรือปรับฮารดแวรใหมีความสามารถมากขึน้ ดวยการเพิม่ หนวยความจํา หรือที่เก็บ
ขอมูล หรือเปลี่ยนตัวประมวลผลใหเร็วขึน้
โอกาสคือ โอกาสทีจ่ ะปรับปรุงองคการ เชน โครงการที่เกีย่ วกับการพัฒนา
ระบบใหมที่สามารถทํารายไดใหกับองคการอยางมหาศาล
สั่งการคือ ความตองการใหมที่สงั่ การจากผูบริหาร รัฐบาล หรือองคการ
ภายนอกที่มีอทิ ธิพล เชน โครงการเปนจํานวนมากที่เกีย่ วของกับเทคโนโลยีดานการแพทยตอ งเจอกับ
ความตองการที่รัฐบาลกําหนดอยางกวดขัน
มันเปนการงายที่จะไดรับการอนุมัติและไดรับเงินสําหรับโครงการที่ไดตอบ
ปญหาและตอบสนองสิง่ ที่สงั่ การจากผูมีอาํ นาจ เพราะองคการตองการที่จะหลีกเลี่ยงไมใหธุรกิจตอง
บาดเจ็บ ดังนัน้ ปญหาและการสั่งการควรจะไดรับการแกไขโดยเร็ว แตผูจัดการตองใชระบบเพือ่ คิดและ
คนหาโอกาสสําหรับปรับปรุงองคการผานโครงการเทคโนโลยีสารสนเทศ
การจัดกลุมอีกประเภทคือ การจัดกลุมตามเวลาทีโ่ ครงการจะเสร็จสมบูรณ หรือ
วันที่โครงการจะตองทํา เชน โครงการทีม่ ีศักยภาพที่จะเสร็จภายในเวลาที่กําหนด โครงการที่มศี ักยภาพ
ที่จะเสร็จในวันทีท่ ี่กาํ หนด บางโครงการสามารถทําเสร็จไดเร็วมาก เชน 2-3 อาทิตย หรือ 2-3 วัน
หลายๆ องคการมีสวนงานที่สนับสนุนผูใชสุดทาย โดยสวนงานสนับสนุนนี้จะจัดการโครงการเล็กๆ ที่
สามารถทําเสร็จไดอยางรวดเร็ว ถึงแมวา โครงการเทคโนโลยีสารสนเทศสามารถทําเสร็จไดอยางรวดเร็ว
โครงการเหลานี้ก็จาํ เปนตองจัดลําดับความสําคัญของโครงการ
การจัดกลุมประเภทที่ 3 คือ การจัดกลุมตามลําดับความสําคัญโดยรวมของ
โครงการ หลายๆ องคการจัดกลุมโครงการเทคโนโลยีสารสนเทศเปนกลุมที่มีความสําคัญ สูง ปานกลาง
หรือต่ํา ซึง่ โครงการใดจะมีความสําคัญสูง หรือต่ํา ขึน้ กับสภาพแวดลอมของธุรกิจปจจุบัน เชน ถา
องคการมีความจําเปนอยางยิ่งที่จะลดคาใชจายในการดําเนินธุรกิจโดยเร็ว โครงการที่มีศกั ยภาพที่จะ
ชวยลดคาใชจา ยก็จะถูกจัดอยูในกลุมที่มคี วามสําคัญสูง องคการจะเลือกที่จะดําเนินโครงการในกลุมที่
มีความสําคัญสูงกอน ถึงแมวาโครงการที่มีความสําคัญปานกลาง หรือต่ําจะสามารถทําเสร็จไดภายใน
เวลาที่นอยกวาก็ตาม

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการบูรณาการโครงการ หนา 3-5

การวิเคราะหดานการเงิน
การพิจารณาดานการเงินมีความสําคัญตอการเลือกโครงการ โดยเฉพาะ
ชวงเวลาที่เศรษฐกิจไมดี โครงการตางๆ ตองไดรับการพิจารณาอนุมัติกอน และการพยากรณดาน
การเงินเปนสวนที่สาํ คัญที่ตอ งระบุในเอกสารธุรกิจ (business case) วิธีการพื้นฐานสําหรับวิเคราะห
การลงทุนประกอบดวย การวิเคราะหมูลคาปจจุบันสุทธิ ((net present value (NPV)) อัตราผลตอบแทน
จากการลงทุน (return on investment (ROI) และการวิเคราะหระยะเวลาการคืนทุน (payback
analysis) ผูจัดการโครงการทํางานเกีย่ วของกับผูบ ริหารระดับสูง เพราะฉะนัน้ ผูจัดการโครงการตอง
เขาใจที่จะสื่อสารภาษาเดียวกัน

• การวิเคราะหมูลคาปจจุบนั สุทธิ
มูลคาปจจุบนั สุทธิคือ การคํานวณเงินสุทธิที่คาดวาจะไดรับหรือสูญ
เสียจากโครงการ โดยการลด (discounting) กระแสเงินสดเขาและออกในอนาคตที่คาดวาจะเกิดจาก
เวลาหนึง่ ยอนกลับมาถึงเวลาปจจุบัน การลดนี้จะลดเปนเปอรเซนตที่เราเรียกวาอัตราสวนลด (discount
rate) ซึ่งเปนอัตราที่องคการคาดวาจะไดรับคืนจากโครงการ โดยปกติผูบริหารจะเปนผูกาํ หนด อัตรา
สวนลด
องคการควรพิจารณาโครงการที่มีคามูลคาปจจุบันสุทธิเปนบวก
เพราะหมายความวามูลคาที่คืนกลับจากการทําโครงการเกินกวาคาใชจายที่ลงทุน (cost of capital) คา
มูลคาปจจุบนั สุทธิที่คํานวณไดถึงแมวาเปนบวกแตถามีคานอยกวาผลตอบแทนการลงทุนดวยวิธกี ารอื่น
องคการอาจตัดสินใจไมลงทุนโครงการเทคโนโลยีสารสนเทศ สูตรการคํานวณมูลคาปจจุบันสุทธิมีดงั นี้

มูลคาปจจุบนั สุทธิ = -I0 + Σ (กระแสเงินสดสุทธิ / (1 + r)t)

โดยที:่
I = คาใชจายทั้งหมด หรือการลงทุนของโครงการ (total cost or investment of the
project)
r = อัตราสวนลด (discount rate)
t = ชวงระยะเวลา (time period)

ถาสมมุติใหอตั ราสวนลดคือ รอยละ 8 และเราคาดวาจะมีกระแสเงิน

เขา-ออกในแตละป ทั้งหมด 5 ปดังตารางที่ 3.1 เราสามารถคํานวณหาคากระแสเงินสดที่หกั ลดแลวใน
แตละปไดดังตารางที่ 3.2 เมื่อรวมกระแสเงินทีห่ ักลดของทุกปแลวเราจะไดมูลคาปจจุบันสุทธิ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการบูรณาการโครงการ หนา 3-6

ตารางที่ 3.1 กระแสเงินสดที่คาดวาจะไดรับในเวลา 5 ป (Marchewka, 2006)

ปที่ 0 ปที่ 1 ปที่ 2 ปที่ 3 ปที่ 4
กระแสเงินสดไหลเขารวม 0 150,000 200,000 250,000 300,000
กระแสเงินสดไหลออกรวม 200,000 85,000 125,000 150,000 200,000
กระแสเงินสดสุทธิ (200,000) 65,000 75,000 100,000 100,000

ตารางที่ 3.2 การคํานวณคามูลคาปจจุบันสุทธิ (Marchewka, 2006)

เวลา การคํานวณ กระแสเงินสดที่ลดแลว กระแสเงินสดสะสม
ปที่ 0 (200,000) (200,000)
ปที่ 1 65,000/(1 + .08)1 60,185 (139,815)
ปที่ 2 75,000/(1 + .08)2 64,300 (755,15)
ปที่ 3 100,000/(1 + .08)3 79,383 3,868
ปที่ 4 100,000/(1 + .08)4 73,503 77,371
มูลคาปจจุบันสุทธิ (NPV) 77,371

คามูลคาปจจุบันสุทธิที่คาํ นวณไดมีคาเปนบวก แสดงวาโครงการนี้ให

ผลตอบแทนทีค่ ุมการลงทุน โปรดจําไววา ถาอัตราสวนลดมีคาเพิม่ ขึ้น คามูลคาปจจุบนั สุทธิมีคาลดลง

• การวิเคราะหอัตราผลตอบแทนจากการลงทุน
อัตราผลตอบแทนจากการลงทุนเปนตัวชีว้ ดั ทางการเงินที่สําคัญตัว
หนึง่ ที่บอกถึงมูลคาที่คาดวาจะไดรับจากการลงทุนในโครงการ สูตรการคํานวณมีดงั นี้

อัตราผลตอบแทนจากการลงทุน = (กําไรที่คาดวาจะไดรับทั้งหมดหลังจากคิดอัตราสวนลดแลว
- คาใชจายทัง้ หมดที่ไดคิดอัตราสวนลดแลว) / คาใชจายทัง้ หมดที่ไดคิดอัตราสวนลดแลว

จากตารางที่ 3.1 เราสามารถคํานวณอัตราผลตอบแทนจากการลงทุน

โดยใชอัตราสวนลดรอยละ 8 ไดโดยการคํานวณหากระแสเงินสดไหลเขารวมทีห่ กั ลดแลว และกระแส
เงินสดไหลออกรวมทีห่ ักลดแลวดังแสดงในตารางที่ 3.3 อัตราผลตอบแทนจากการลงทุนจึงคํานวณได
ดังนี้

อัตราผลตอบแทนจากการลงทุน= (731,000 – 653,050) / 653,050 = 11.94%

ผศ.ดร. วราภรณ จิรชีพพัฒนา

 การบริหารการบูรณาการโครงการ หนา 3-7

ตารางที่ 3.3 ตัวอยางการคํานวณอัตราผลตอบแทนจากการลงทุน (Marchewka, 2006)

ปที่ 0 ปที่ 1 ปที่ 2 ปที่ 3 ปที่ 4 รวม
กระแสเงินสดไหลเขา
0 150,000 200,000 250,000 300,000 900,000
รวม
กระแสเงินสดไหลเขา 139,500 172,000 197,500 222,000
0 731,000
รวมที่หักลดแลว (150,000*.93) (200,000*.86) (250,000*.79) (300,000*.74)
กระแสเงินสดไหลออก
200,000 85,000 125,000 150,000 200,000 760,000
รวม
กระแสเงินสดไหลออก 79,050 107,500 118,500 148,000
200,000 653,050
รวมที่หักลดแลว (85,000*.93) (125,000*.86) (150,000*.79) (200,000*.74)

• การวิเคราะหระยะเวลาการคืนทุน
วิธีการวิเคราะหระยะเวลาการคืนทุนเปนการพิจารณาวาโครงการตอง
ใชเวลานานเทาไรจึงจะไดรายไดคุมเงินลงทุนเริ่มแรก (Initial Investment) โดยมีสูตรการคํานวณดังนี้

ระยะเวลาการคืนทุน = เงินลงทุนเริ่มตน / กระแสเงินสดสุทธิเฉลี่ยตอป

จากตารางที่ 3.1 เราสามารถคํานวณระยะเวลาที่คุมทุนไดดังนี้

เงินลงทุนเริ่มตน = 200,000
กระแสเงินสดสุทธิเฉลี่ยตอป = ผลรวมของกระแสเงินสดสุทธิ/จํานวนป
= (65,000 + 75,000 + 100,000 + 100,000)/5
= 68,000
ระยะเวลาการคืนทุน =200,000 / 68,000 = 2.94 = 3 ป

การหาระยะเวลาการคืนทุนยังสามารถใชขอมูลจากการคํานวณมูลคา
ปจจุบันสุทธิ โดยการคํานวณกระแสเงินสดสะสมของแตละป ถาปใดมีกระแสเงินสดสะสมเปนบวก
แสดงวาปนั้นคือ ปที่โครงการไดทุนคืน ดังตัวอยางในตารางที่ 3.2 โครงการจะคืนทุนในปที่ 3 เพราะ
กระแสเงินสดสะสมมีคาเปนบวกในปนั้น
ถึงแมวา การวิเคราะหระยะเวลาการคืนทุนจะเปนวิธีตรงไปตรงมา
และงายแกการเขาใจ แตมันไมไดพิจารณามูลคาของเงินตามระยะเวลาที่ผา นไป อยางไรก็ตาม วิธกี ารนี้

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการบูรณาการโครงการ หนา 3-8

ก็ยังมีประโยชนสําหรับการพิจารณาความเสี่ยงของการลงทุน เพราะการลงทุนทีม่ ีความเสีย่ งยอมตองใช

เวลานานถึงจะไดรายไดคุมการลงทุน

การใชตวั แบบใหคะแนนถวงน้ําหนัก
ตัวแบบใหคะแนนถวงน้ําหนักเปนวิธีการสําหรับการเปรียบเทียบโครงการโดย
พิจารณาจากผลรวมของคะแนนที่ไดในแตละเงื่อนไข แตเงื่อนไขดังกลาวมีความสําคัญที่แตกตางกัน เรา
จึงควรกําหนดน้ําหนักของแตละเงื่อนไข การถวงน้ําหนักนัน้ โดยปกติเราใชเปอรเซ็นต และมีผลรวมของ
น้ําหนักทัง้ หมดคือ 100 ดังตัวอยางในตารางที่ 3.4 จากตารางดังกลาว เราจะเห็นวาคะแนนรวมของ
โครงการไดคะแนนสูงสุดคือ 8.5 ดังนัน้ เราจึงควรเลือกโครงการ ค สวนสูตรการคํานวณคือ
n
Total Score = ∑ Wi Ci
i =1

โดยที่
Total Score คือ คะแนนรวมทั้งหมด
Wi คือ น้ําหนักของเงื่อนไข
Ci คือ คะแนนของเงื่อนไข

ตารางที่ 3.4 ตัวอยางการใชตัวแบบการใหคะแนนถวงน้ําหนัก (Marchewka, 2006)

เงื่อนไข น้ําหนัก โครงการ ก โครงการ ข โครงการ ค
อัตราผลตอบแทนจากการลงทุน 15% 2 4 10
การเงิน ระยะเวลาการคืนทุน 10% 3 5 10
มูลคาปจจุบันสุทธิ 15% 2 4 10
ความสอดคลองกับวัตถุประสงคเชิงยุทธศาสตร 10% 3 5 8
องคการ
ความเปนไปไดที่จะบรรลุวัตถุประสงคของ
10% 2 6 9
โครงการ
มีสมาชิกในทีมที่มีทักษะ 5% 5 5 4
ความสามารถในการบํารุงรักษา 5% 4 6 7
โครงการ
เวลาที่ใชในการพัฒนา 5% 5 7 6
ความเสี่ยง 5% 3 5 5
ความพึงพอใจของลูกคา 10% 2 4 9
ภายนอก
สวนแบงการตลาดที่เพิ่มขึ้น 10% 2 5 8
คะแนนรวม 100% 2.65 4.85 8.50

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการบูรณาการโครงการ หนา 3-9

การใชบัตรคะแนนสมดุล
องคการที่ใชบตั รคะแนนสมดุลตองสรางชุดตัววัด หรือตัวชี้วัดผลการดําเนินงาน
(key performance indicators (KPI)) สําหรับแตละมุมมอง ซึ่งมี 4 มุมมองคือ มุมมองทางดานการเงิน
ลูกคา กระบวนการภายในองคการ และการเรียนรูและนวัตกรรม ตัววัดของแตละมุมมองจะถูกนํามาใช
ในการสรางรายงาน หรือบัตรคะแนนสําหรับองคการเพื่อใหผูบริหารสามารถติดตามประสิทธิภาพของ
องคการได มุมมองทั้ง 4 ดานทําใหเกิดสมดุลในแงของประโยชนทั้งที่จับตองได หรือประเมินได และ
ประโยชนที่จับตองไมได หรือประเมินไดยาก วัตถุประสงคระยะสัน้ และระยะยาว รูปที่ 3.2 แสดง
ตัวอยางการใชบัตรคะแนนสมดุล

รูปที่ 3.2 ตัวอยางของบัตรคะแนนสมดุล (Marchewka, 2006)

• มุมมองดานการเงิน
วิธีการบัตรคะแนนสมดุลกระตุนใหผูบริหารใหพิจารณาตัววัดอื่น
นอกเหนือจากตัววัดทางการเงินแบบดัง้ เดิม เพื่อใหประสบความสําเร็จเชิงยุทธศาสตร ตัววัดทางการเงิน
สวนใหญมีประโยชนทาํ ใหเราเขาใจวาองคการทํางานอยางไรในอดีต และบางองคการใชตัววัดนี้ในการ
กํากับองคการโดยการเฝาดูการเปลี่ยนแปลงของตัววัด อยางไรก็ตาม ตัววัดการเงินแบบดั้งเดิมยังคงมี
ความสําคัญและเปนหลักสําหรับการประกันวายุทธศาสตรขององคการไดรับการดําเนินการอยาง
เหมาะสม ทีส่ ําคัญกวานัน้ คือ วิธีการนี้เปนสื่อการเชื่อมโยงประสิทธิภาพทางการเงินกับการลูกคา การ
ปฏิบัติงานภายใน และการลงทุนในพนักงานและโครงสรางพืน้ ฐานที่สนับสนุนการทํางาน ถึงแมวาตัววัด
การเงินดั้งเดิม เชน อัตราผลตอบแทนการลงทุน มูลคาปจจุบันสุทธิ และอัตราผลตอบแทนภายใน จะ
ยังคงมีประโยชน หลายองคการใชตัววัดการเงินแบบใหมคือ มูลคาที่เพิ่มทางเศรษฐศาสตร (economic

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการบูรณาการโครงการ หนา 3-10

value added (EVA)) ซึ่งเปนเครื่องมือวัดวาองคการไดรับรายไดมากกวาทุนจริงที่ลงไป มูลคาที่เพิ่มทาง

เศรษฐศาสตรคํานวณโดยการพิจารณาคาใชจายของหนี้สิน (เชน อัตราดอกเบี้ยทีธ่ นาคารคิดจาก
องคการ) และคาใชจายของความยุติธรรม (เชน เงินที่ผูถือหุนอาจไดรับจากที่อื่น ถาเอาเงินไปลงทุน
อยางอืน่ ) มูลคาที่เพิ่มทางเศรษฐศาสตรที่มีคาเปนบวกหมายถึงผูบริหารสรางความมัง่ คั่งใหกับองคการ

• มุมมองดานลูกคา
เปนมุมมองทีส่ ะทอนใหเห็นวา องคการทํางานอยางไรจากความคิดของ
ลูกคา สรางความพึงพอใจใหกับลูกคามากนอยแคไหน ความพึงพอใจของลูกคาเปนสิ่งที่บอกเราวา เรา
สามารถดําเนินธุรกิจแบบเดิม หรือควรหาธุรกิจใหม ดังนั้น ตัววัดความพึงพอใจของลูกคาสามารถ
เชื่อมโยงไปยังรางวัลดานการเงิน การวัดทีย่ ึดลูกคาเปนหลักอาจกําหนดระดับความพึงพอใจของสินคา
และบริการขององคการ และสินคาและบริการสงมอบไดดีแคไหน

• มุมมองดานกระบวนการภายใน
มุมมองนี้เนนที่กระบวนการทั้งระยะสั้นและระยะยาวที่องคการตองทํา
ใหดี เพื่อใหบรรลุวัตถุประสงคของลูกคาและดานการเงิน ความพึงพอใจของลูกคาสามารถบรรลุผาน
การปรับปรุงกิจกรรมการทํางานขององคการ ซึ่งนําไปสูก ารปรับปรุงประสิทธิภาพทางการเงิน ดังนั้นตัว
วัดควรเนนที่ประสิทธิภาพและประสิทธิผลของกระบวนการขององคการ

• มุมมองดานการเรียนรูและนวัตกรรม
ความสามารถ สมรรถภาพ และแรงจูงใจของคนในองคการเปน
ตัวกําหนดผลไดจากกิจกรรมการทํางาน ประสิทธิภาพดานการเงิน และระดับความพึงพอใจของลูกคา
ดังนัน้ องคการตองเชื่อมัน่ อยางมากในคนขององคการ ความสามารถขององคการที่จะคิดสิ่งใหมและ
การเรียนรูระดับบุคคลเปนสิง่ ทีว่ ิกฤต บัตรคะแนนสมดุลสนับสนุนการลงทุนสําหรับอนาคต โดยการให
ความสําคัญของการลงทุนในคนและการลงทุนในโครงสรางพืน้ ฐานสําหรับมนุษยเชนเดียวกับการลงทุน
ในโครงสรางพืน้ ฐานทางกายภาพและทางเทคนิค ตัววัดสําหรับมุมมองนี้คือ การอบรม การรับรอง และ
การอยูและความพึงพอใจของพนักงาน

การวัดมูลคาของโครงการเทคโนโลยีสารสนเทศตาม 4 มุมมองดังกลาว บังคับ

ใหผูบริหารพิจารณาผลกระทบและบริบทของโครงการในมุมกวาง

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการบูรณาการโครงการ หนา 3-11

3.3 พัฒนาเอกสารสิทธิ์โครงการ
หลังจากผูบริหารระดับสูงตัดสินใจวาโครงการใดควรดําเนินการแลว สิ่งที่สําคัญที่โครงการ
ตองทําคือ ตองใหคนอืน่ ๆ ในองคการรับรูเกี่ยวกับโครงการ ซึง่ สามารถทําไดหลายรูปแบบ แตมีรูปแบบที่
นิยมใชกันคือ เอกสารสิทธิโ์ ครงการซึง่ เปนเอกสารที่แสดงวัตถุประสงคและการบริหารโครงการ เอกสาร
นี้อนุมัติใหผูจดั การโครงการสามารถใชทรัพยากรองคการ เพื่อทําใหโครงการเสร็จสมบูรณ โดยปกติ
ผูจัดการโครงการจะเปนตัวหลักในการพัฒนาเอกสารสิทธิ์โครงการ บางองคการอาจใชจดหมายตกลง
กัน บางองคการใชเอกสารทีย่ าว หรือสัญญาที่เปนทางการ ผูม ีสวนไดเสียหลักของโครงการควรเซ็นตใน
เอกสารสิทธิ์โครงการ เพื่อประกาศขอตกลงดานความตองการ และเจนตนาของโครงการ เอกสารสิทธิ์
โครงการเปนผลลัพธหลักของกระบวนการเริ่มแรก ดังนัน้ เอกสารนี้จงึ เปรียบเสมือนขอตกลงหรือสัญญา
ระหวางผูสนับสนุนโครงการและทีมงาน
ในเอกสารสิทธิ์โครงการประกอบดวยหัวขอตอไปนี้ แตผูจัดการโครงการสามารถปรับให
สอดคลองกับโครงการและองคการได
• ชื่อโครงการ
• ผูมีสวนไดเสียโครงการ ซึง่ ประกอบดวย ชือ่ ตําแหนง เบอรโทรศัพท อีเมล โดยระบุ
ถึงการเขามามีสวนรวมอยางไร เมื่อไร
• คําอธิบายโครงการ ซึง่ ประกอบดวยภาพรวม หรือเบื้องหลังของโครงการ ปญหา
หรือโอกาส วัตถุประสงคของโครงการ ภาพรวมผลกระทบที่อยากใหเกิด
• ขอบเขตโครงการประกอบดวยสิ่งที่รวมและไมรวมในโครงการ
• ระยะเวลาโครงการที่ระบุวนั เริ่มตนและวันสิ้นสุดโครงการ วันที่คาดวางานที่สง มอบ
หลักเสร็จ หลักไมล และระยะโครงการ
• งบประมาณโครงการ
• ประเด็นดานคุณภาพที่ตองการ
• ทรัพยากรทีป่ ระกอบดวยคน เทคโนโลยี หรือสิ่งอํานวยความสะดวกตางๆ เพื่อ
สนับสนุนทีมงาน
• สมมุติฐานและความเสีย่ ง เชนสมมติฐานที่ใชประมาณการคาใชจาย ความเสีย่ งที่
สําคัญ ความเปนไปไดที่จะเกิด และผลกระทบ รวมทัง้ ขอจํากัดตางๆ
• การบริหารโครงการ ซึ่งประกอบดวย การรายงานความกาวหนา การบริหารการ
เปลี่ยนแปลง การบริหารคุณภาพ การไดพนักงาน และการพัฒนาทีม
• การยอมรับและอนุมัติ ประกอบดดวยชื่อ ลายเซ็น และวันที่อนุมัติ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการบูรณาการโครงการ หนา 3-12

• เอกสารอางอิง
• ความหมายคําศัพทเฉพาะ
• ภาคผนวก

3.4 กําหนดขอบเขตงานเบื้องตน
ขอบเขตงานเบื้องตนคือ เอกสารที่ใชยืนยันความเขาใจขอบเขตโครงการรวมกัน เอกสารนี้จะ
อธิบายในรายละเอียดของงานที่ตองการทําใหสําเร็จ และเปนเครื่องมือสําคัญที่จะปองกันการขยาย
ขอบเขตโครงการ (scope creep – แนวโนมของขอบเขตโครงการที่จะใหญขนึ้ ๆ) นอกจากนี้เอกสาร
ขอบเขตงานชวยสรางขอกําหนดขอบเขตงานเริ่มแรกระหวางที่โครงการเพิ่งเริ่มตน ดังนัน้ ทีมงาน
โครงการทั้งหมดสามารถเริ่มถกเถียงและทํางานทีเ่ กี่ยวกับขอบเขตโครงการ ทีมงานจะเตรียมราย
ละเอียดของขอบเขตโครงการมากขึน้ ขอบเขตโครงการนี้จะมีหลายเวอรชันและแตละเวอรชันจะมี
รายละเอียดมากขึ้นๆ เมื่อโครงการไดเดินหนา พรอมกับมีขอมูลมากขึ้นสําหรับทํารายละเอียดขอบเขต
โครงการ
โครงการที่มีความซับซอนจะมีขอบเขตโครงการทีย่ าว สวนโครงการเล็กมีขอบเขตโครงการที่
สั้น โดยสวนใหญเอกสารนีจ้ ะประกอบดวย วัตถุประสงคโครงการ คุณลักษณะและความตองการของ
ผลิตภัณฑหรือบริการ อาณาเขตโครงการ (boundaries) สิ่งที่ตองสงมอบ เงื่อนไขการยอมรับโครงการ
ขอจํากัดและสมมติฐานโครงการ โครงสรางองคการของโครงการ รายการความเสีย่ งเบื้องตน สรุปตาราง
การทํางาน ประมาณการคาใชจายเบื้องตน การบริหารคอนฟกรูเรชัน่ (configuration management)
และรายละเอียดของความตองการที่ไดรบั อนุมัติ

3.5 แผนการบริหารโครงการ
แผนการบริหารโครงการคือ เอกสารที่ใชในการประสานแผนยอยทัง้ หมดของโครงการ และ
เพื่อชี้นาํ การดําเนินงานและควบคุมโครงการ แผนตางๆ ที่ไดสรางตามองคความรูดานอื่นๆ จะนํามา
พิจารณาเปนสวนยอยของแผนการบริหารโครงการ แผนการบริหารโครงการจะบันทึกสมมติฐานที่ใชใน
การวางแผน และการตัดสินใจเลือกทางเลือก รวมทัง้ อํานวยความสะดวกในการสื่อสารระหวางผูมีสวน
ไดเสีย กําหนดเนื้อหาของแผน ระยะเวลาสําหรับการทบทวนการบริหารที่สาํ คัญ และเปนบรรทัดฐาน
(baseline) สําหรับการวัดความกาวหนาและควบคุมโครงการ แผนการบริหารโครงการควรพลวัต
ยืดหยุน พรอมที่จะเปลีย่ น เมื่อสภาพแวดลอมหรือโครงการเปลี่ยน แผนเหลานี้ควรชวยผูจัดการโครงการ
ในการนําทีมงานและประเมินสถานภาพโครงการ เพือ่ สรางแผนการบริหารที่ดี ผูจัดการโครงการตอง

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการบูรณาการโครงการ หนา 3-13

ฝกฝนศิลปการบริหารการบูรณาการโครงการ เนื่องจากขอมูลที่ใชมาจากองคความรูการบริหารโครงการ
ทั้งหมด

3.5.1 เนื้อหาของแผนการบริหารโครงการ
แผนการบริหารโครงการประกอบดวย 1) การแนะนําโครงการหรือภาพรวม
โครงการ 2) การจัดการโครงการ 3) การบริหารและกระบวนทางเทคนิคที่ใชกับโครงการ 4) งานที่ตอ งทํา
5) ตารางการทํางาน และ 6) คาใชจาย
ในสวนของการแนะนําหรือภาพรวมของโครงการประกอบดวยหัวขอทีไ่ มนอยกวา
หัวขอตอไปนี้
• ชื่อโครงการ ทุกโครงการตองมีชื่อที่ไมซา้ํ และควรหลีกเลี่ยงความสับสนกับ
โครงการที่สัมพันธกัน
• รายละเอียดโครงการและความตองการอยางสัน้ ๆ รายละเอียดควรสอดคลอง
กับเปาหมายและชัดเจน รวมทัง้ เหตุผล การเขียนควรหลีกเลีย่ งคําศัพททาง
เทคนิค และควรมีการประมาณราคาและเวลาอยางคราวๆ
• ชื่อผูสนับสนุนโครงการ ขอมูลสําหรับติดตอผูสนับสนุน
• ชื่อผูจัดการโครงการ และสมาชิกหลัก
• สิ่งที่ไดจากโครงการคือ ผลผลิตที่โครงการจะทําออกมาเปนสวนหนึ่งของ
โครงการ เชน ซอฟตแวรสําเร็จรูป ฮารดแวร รายงานเชิงเทคนิค เอกสารการ
อบรม เปนตน
• รายชื่อเอกสารอางอิงที่สําคัญ รายชื่อเอกสารที่สาํ คัญ หรือการประชุม ที่
สัมพันธกับโครงการชวยใหผูมีสวนไดเสียของโครงการเขาใจประวัติความ
เปนมา ในสวนนี้ควรอางถึงแผนที่สรางจากองคความรูอื่นๆ ดังนัน้ แผนการ
บริหารโครงการควรอางอิงและสรุปสวนที่สําคัญของแผนการบริหารขอบเขต
โครงการ การบริหารตารางเวลา การบริหารคาใชจาย การบริหารคุณภาพ การ
บริหารความเสี่ยง และการบริหารการจัดซื้อจัดจาง
• รายการนิยามคําและความหมายของตัวยอ หลายๆ โครงการโดยเฉพาะ
โครงการเทคโนโลยีสารสนเทศเกี่ยวของกับคําศัพทอุตสาหกรรมเฉพาะ หรือ
คําศัพททางเทคโนโลยี ดังนั้นควรมีคํานิยามและความหมายของตัวยอ เพื่อ
ชวยไมใหเกิดความเขาใจผิด

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการบูรณาการโครงการ หนา 3-14

รายละเอียดของการจัดการโครงการมีดังนี้
• ผังโครงสรางของโครงการ เพื่อแสดงเสนทางของอํานาจการบริหาร ความ
รับผิดชอบ และการสื่อสารของโครงการ
• ความรับผิดชอบ แผนโครงการควรอธิบายงานและกิจกรรมที่สาํ คัญของ
โครงการ และระบุคนที่รับผิดชอบงานนัน้ ผังการมอบหมายความรับผิดชอบ
เปนเครื่องมือที่ใชในการแสดงขอมูลสวนนี้
• ขอมูลที่เกี่ยวกับกระบวนการที่เกีย่ วของหรือขอมูลองคการอื่นๆ โครงการอาจมี
ความจําเปนตองบันทึกกระบวนการหลักของโครงการ เชน ถาโครงการ
เกี่ยวกับการปลอยซอฟตแวรที่ยกระดับ ดังนัน้ ไดอะแกรม หรือเสนเวลาของ
ขั้นตอนหลักทีเ่ กี่ยวกับกระบวนการนี้ชว ยใหทกุ ๆ คนที่เกี่ยวของเห็น
กระบวนการทีช่ ัดเจน

ในสวนของแผนการบริหารโครงการจะอธิบายวิธีการบริหารและวิธีการเชิงเทคนิค
ซึ่งควรมีขอมูลดังนี้
• วัตถุประสงคการบริหาร เปนสวนที่อธิบายมุมมองโครงการของผูบริหาร
ระดับสูง และขอจํากัดหรือสมมุติฐานของโครงการ
• การควบคุมโครงการ สวนนี้อธิบายวาเราจะติดตามความกาวหนาและจัดการ
การเปลี่ยนแปลงอยางไร จะมีการทบทวนสถานภาพรายเดือน และราย 3
เดือนหรือไม มีแบบฟอรมเฉพาะหรือผังการติดตามความกาวหนาโครงการ
หรือไม โครงการจะใชการบริหารมูลคาที่ไดรับในการประเมินและติดตาม
ประสิทธิภาพหรือไม ผูบริหารระดับใดที่เปนผูอนุมัตกิ ารเปลี่ยนแปลง
• การบริหารความเสี่ยง สวนนี้จะอธิบายคราวๆ วาทีมงานโครงการจะระบุ
บริหาร และควบคุมความเสีย่ งอยางไร ควรอางถึงแผนการบริหารความเสี่ยง
• การจัดคน สวนนี้อธิบายจํานวนคนและประเภทของคนที่โครงการตองการ ควร
อางถึงแผนการจัดการคน
• กระบวนการทางเทคนิค สวนนี้อธิบายระเบียบวิธกี ารทีโ่ ครงการอาจใช และ
อธิบายวาจะบันทึกขอมูลอยางไร เชน โครงการทางเทคโนโลยีสารสนเทศทํา
ตามระเบียบวิธีการการพัฒนาซอฟตแวรโดยเฉพาะ หรือใช CASE โดยเฉพาะ
หลายๆ บริษทั หรือลูกคามีรูปแบบเฉพาะสําหรับการจัดทําเอกสารทางเทคนิค

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการบูรณาการโครงการ หนา 3-15

ดังนัน้ การทําใหกระบวนการเทคนิคในแผนการบริหารโครงการเกิดความ
ชัดเจนจึงเปนสิ่งสําคัญ

ในสวนถัดไปของแผนการบริหารโครงการควรอธิบายงานที่ทาํ และอางอิงแผนการ
บริหารขอบเขต โดยมีหัวขอดังนี้
• แพคเกจงานหลัก โดยปกติ ผูจัดการโครงการจะจัดการงานเปนแพคเกจงาน
หลายแพคเกจ โดยการใชโครงสรางจําแนกงาน และเขียนขอกําหนดขอบเขต
งานเพื่ออธิบายงานในรายละเอียด สวนนีค้ วรสรุปอยางคราวๆ ถึงแพคเกจงาน
หลักสําหรับโครงการ และอางถึงแผนบริหารขอบเขตโครงการตามความ
เหมาะสม
• สิ่งที่สง มอบหลัก สวนนี้ควรแสดงรายการและอธิบายสิง่ ที่สง มอบหลัก พรอม
กับอธิบายคุณภาพที่คาดหวัง
• ขอมูลอื่นๆ ที่เกีย่ วของกับงาน สวนนี้จะเนนขอมูลสําคัญที่เกี่ยวกับโครงการ
เชน รายการฮารดแวร และซอฟตแวรเฉพาะ เพื่อใชกับโครงการ หรือ
คุณลักษณะเฉพาะที่ตองทําตาม ผูจ ัดการโครงการควรบันทึกสมมุติฐานที่
สําคัญที่ใชในการกําหนดงานของโครงการ

ในสวนของตารางเวลาโครงการควรมีหวั ขอดังนี้
• ตารางเวลาโดยสรุป เปนตารางสรุปเวลาของโครงการในหนึง่ หนากระดาษ ถา
เปนโครงการทีซ่ ับซอน ตารางเวลาสรุปอาจแสดงสิ่งทีส่ งมอบหลักและวันที่
วางแผนวาจะเสร็จสมบูรณ แตถาเปนโครงการขนาดเล็ก ตารางเวลาสรุปอาจ
• แสดงงานทัง้ หมดพรอมเวลาในรูปของผังแกนต (Gantt chart) ตารางเวลา
ละเอียด สวนนี้จะใหขอมูลเกี่ยวกับตารางเวลาโครงการละเอียดมากขึ้น โดย
แสดงความพึงพา (dependencies) กันของกิจกรรมที่สามารถมีผลกระทบตอ
ตารางเวลาโครงการ เชน อาจกลาวถึงงานหลักที่ไมสามารถเริ่มตนจนกวา
หนวยงานภายนอกจะใหเงิน ผังเครือขาย (network diagram) สามารถแสดง
ความพึงพาของกิจกรรม
• ขอมูลอื่นๆ ที่เกีย่ วของกับตารางเวลา เชน สมมุติฐานที่ใชในการเตรียม
ตารางเวลาโครงการ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการบูรณาการโครงการ หนา 3-16

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

3.5.2 การใชแนวทางเพื่อสรางแผนการบริหารโครงการ
หลายๆ องคการมีแนวทางสําหรับใชสรางแผนการบริหารโครงการ นอกจากนี้
ซอฟตแวรสําเร็จรูปสําหรับบริหารโครงการมีแฟมตัวแบบหลายๆ แบบสําหรับใหผูใชซอฟตแวรเลือกใช
เปนแนวทางในการสรางแผน อยางไรก็ตาม เราไมควรสับสนระหวางแผนการบริหารโครงการกับผัง
แกนต แผนการบริหารโครงการจะรวมเอกสารการวางแผนทัง้ หมด โดยการรวมแผนที่ไดสรางขึ้นจาก
องคความรูดานอื่นๆ สวนผังแกนตเปนผังที่แสดงตารางเวลาการทํางานเทานั้น ตารางที่ 3.5 คือ ตัวอยาง
มาตรฐานของ IEEE 1058-1998 ที่อธิบายเนื้อหาของแผนการบริหารโครงการซอฟตแวร (software
project management Plan (SPMP))

ตารางที่ 3.5 ตัวอยางเนื้อหาของ SPMP (Schwalbe, 2007)

หัวขอใหญ หัวขอยอย
ภาพรวม • จุดมุงหมายขอบเขตและวัตถุประสงค
• สมมุติฐานและขอจํากัด
• สิ่งที่ผลิตหรือทํา
• สรุปงบประมาณและเวลาวิวัฒนาการของแผน
การจัดการโครงการ • จุดประสานกับภายนอก
• โครงสรางภายในบทบาทและความรับผิดชอบ
แผนกระบวนการเชิง • แผนการเริ่มโครงการ (การประมาณการ คณะทํางาน การไดทรัพยากร และการอบรบ
บริหาร คณะทํางาน)

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการบูรณาการโครงการ หนา 3-17

หัวขอใหญ หัวขอยอย
• แผนงาน (กิจกรรม เวลา ทรัพยากร และการจัดสรรงบประมาณ)
• แผนการควบคุม
• แผนการบริหารความเสี่ยงแผนการปดโครงการ
แผนกระบวนการทาง • ตัวแบบกระบวนการ
เทคนิค • วิธกี าร เทคนิค และเครื่องมือ
• แผนโครงสรางพื้นฐานแผนการยอบรับผลิตภัณฑ
แผนกระบวนการ • แผนการบริหารคอนฟกรูเรชัน
สนับสนุน • แผนการสอบทวนและตรวจสอบความถูกตอง
• แผนจัดทําเอกสาร
• การประกันคุณภาพ
• การทบทวนและตรวจสอบ
• แผนการแกปญหา
• แผนการบริหารผูรับชวงแผนการปรับปรุงกระบวนการ

3.5.3 การวิเคราะหผูมีสวนไดเสีย
การวิเคราะหผูมีสวนไดเสียคือ การบันทึกขอมูลของผูที่เกีย่ วของหลักของโครงการ
เชน ชื่อ หนวยงานของผูมีสว นไดเสียหลัก บทบาทของคนเหลานี้ในโครงการ ขอเท็จจริงเกี่ยวกับผูมีสวน
ไดเสียแตละคน ระดับความสนใจในโครงการ อิทธิพลตอโครงการ และขอแนะนําสําหรับการจัดการ
ความสัมพันธกับผูมีสวนไดเสียแตละคน เนื่องจากการวิเคราะหผูมีสว นไดเสียมีขอมูลที่ออนไหว จึงไม
ควรรวมในแผนโครงการโดยรวม ในหลายกรณี การวิเคราะหนี้จะมีเฉพาะผูจัดการโครงการและสมาชิก
หลักของโครงการเทานัน้ ที่เห็นขอมูล ตารางที่ 3.6 คือ ตัวอยางการวิเคราะหผูมีสว นไดเสีย ซึ่งเราจะเห็น
ไดวาผูมีสวนไดเสียแตละคนมีลักษณะอยางไร ผูจัดการโครงการและทีมงานควรเตรียมการอยางไรจึงจะ
ทํางานไดตามที่คนเหลานี้คาดหวัง

ตารางที่ 3.6 ตัวอยางการวิเคราะหผูมสี วนไดเสีย (Schwalbe, 2007)

ประพันธ นุสรา จุมพล ครรชิต สันติ
องคการ ผูบริหารอาวุโส ทีมงานโครงการ ทีมงานโครงการ ผูขายฮารดแวร ผูจัดการโครงการ
ภายใน ของโครงการอื่น
ในองคการ
บทบาทใน ผูสนับสนุนโครงการ ผูเชี่ยวชาญ DNA หัวหนา จัดหาเครื่องมือ คูแขงในเรื่อง
โครงการ และเปนหนึ่งในผู โปรแกรมเมอร อุปกรณบางอยาง ทรัพยากรองคการ
กอตั้งบริษัท เปนผูกอ ตั้งบริษัท

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการบูรณาการโครงการ หนา 3-18

ประพันธ นุสรา จุมพล ครรชิต สันติ

ขอเท็จจริง เงียบ สั่ง ชอบ ปริญญาเอกทาง ฉลาดมาก เปน รูวาเราสามารถ เปนคนดี เปนหนึง่
รายละเอียด เนน ชีววิทยา ทํางาน โปรแกรมเมอรที่ดี ทําใหเขารวย ถา ในคนเกาแกที่สุด
ธุรกิจ จบ MBA จาก ดวยงาย ที่สุด มีอารมณขนั งานนี้สําเร็จ ของบริษัท มีลกู 3
แสตนฟอรด ใชเครื่องชวยเดิน คนเรียนระดับ
วิทยาลัย
ระดับความ สูงมาก สูงมาก สูง สูงมาก ต่ํา - ปานกลาง
สนใจ
ระดับอิทธิพล สูงมาก สามารถ เปนผูเชีย่ วชาญใน สูง ยากที่จะหาคน ต่ํา ต่ํา - ปานกลาง
ลมเลิกโครงการ เรื่องที่สําคัญตอ แทน มีผูขายรายอื่น
ความสําเร็จ
ขอเสนอแนะ รายงานอยาง ทําใหแนใจวาเธอ พยายามทําใหเขา ใหเวลาที่เพียง เขารูวาโครงการ
เพื่อบริหาร สม่ําเสมอ ใหเปน ไดทบทวน มีความสุขเพื่อให พอที่จะสง ของเขามี
ความสัมพันธ ผูนําการสนทนา ทํา รายละเอียด เขาอยูกับบริษัท ฮารดแวร ความสําคัญนอย
ในสิ่งที่เขาพูดอยาง ขอกําหนด และนํา ชอบอาหาร กวา แตเรา
รวดเร็ว การทดสอบ เม็กซิกัน สามารถเรียนรู
สามารถทํางาน จากเขาได
บางอยางจากบาน

3.6 การปฎิบัติงานโครงการ
การบริหารและการกํากับการปฏิบัติงานโครงการเกีย่ วของกับการจัดการและการทํางาน
ตามที่ไดอธิบายในแผนการบริหารโครงการ เวลาสวนใหญของโครงการใชในการดําเนินโครงการ และ
เปนงบประมาณสวนใหญของโครงการ ผูจัดการโครงการจําเปนตองเนนที่การนําทีมและบริหาร
ความสัมพันธกับผูมีสวนไดเสีย เพื่อทําใหแผนบริหารโครงการประสบความสําเร็จ การบริหารทรัพยากร
มนุษย และการบริหารการสื่อสารเปนสิง่ สําคัญที่จะทําใหโครงการประสบความสําเร็จดวย ถาโครงการ
เกี่ยวของกับความเสีย่ งขนาดใหญ หรือตองใชทรัพยากรจากภายนอก ผูจัดการโครงการจําเปนตอง
เชี่ยวชาญในการบริหารความเสี่ยงและการจัดซื้อจัดจาง มีสถานการณที่ไมซา้ํ กันหลายแบบเกิดขึ้น
ระหวางการดําเนินโครงการ ดังนัน้ ผูจ ัดการโครงการตองยืดหยุน และสรางสรรคในการจัดการกับ
สถานการณตา งๆ

3.6.1 การวางแผนการประสานงานและการปฏิบัติงานตามแผน
การบริหารการบูรณาการโครงการมองการวางแผนโครงการและการปฏิบัติงานเปน
กิจกรรมที่ผกู กันและแยกกันไมออก เมือ่ ปฏิบัติงานแลว ผูจัดการโครงการอาจตองมีการปรับปรุงแผน
บริหารโครงการ การปรับปรุงแผนควรสะทอนความรูท ี่ไดจากการทํางานที่เสร็จสมบูรณกอนหนานี้

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการบูรณาการโครงการ หนา 3-19

วิธีการแบบสามัญสํานึก (commonsense approach) เปนวิธกี ารทําใหการประสานงานระหวางการ

พัฒนาแผนและการปฏิบัติงานดีขึ้น กลาวคือ ใครทีท่ าํ งานใด ควรเปนผูวางแผนการทํางานนัน้ ดังนัน้
บุคลากรโครงการทัง้ หมดจําเปนทีจ่ ะพัฒนาทัง้ ทักษะการวางแผนและการปฏิบัติงานโครงการ และ
ตองการประสบการณในเรื่องเหลานี้

3.6.2 การใหความเปนผูนําที่เขมแข็งและวัฒนธรรมเชิงสนับสนุน
ความเปนผูนาํ ที่เขมแข็ง และวัฒนธรรมองคการเชิงสนับสนุนเปนสิง่ ที่สาํ คัญ
ระหวางการดําเนินโครงการ ผูจัดการโครงการตองชักนําทีมงาน โดยการใชตัวอยางเพื่อแสดงใหเห็น
ความสําคัญของการสรางแผนที่ดี และทําตามแผน ถาผูจัดการโครงการทําตามแผนที่ตนเองไดวางไว
สมาชิกในทีมมีแนวโนมที่จะทําแบบเดียวกัน
การดําเนินโครงการที่ดีตองการวัฒนธรรมองคการเชิงสนับสนุน เชน ถาองคการมี
แนวทางที่มีประโยชนและมีแบบสําหรับการบริหารโครงการทีท่ ุกคนสามารถทําตาม มันจะเปนการงาย
สําหรับผูจัดการโครงการและทีมงานทีจ่ ะวางแผนและทํางานของเขา ถาองคการใชแผนโครงการเปน
ฐานสําหรับการทํางานและติดตามความกาวหนาระหวางการปฏิบัติงาน วัฒนธรรมองคการแบบนี้จะ
สงเสริมความสัมพันธระหวางการวางแผนและการปฏิบัติงาน ในทางกลับกัน ถาองคการไมวัด
ความกาวหนาของงานกับแผน ผูจัดการโครงการและทีมงานจะผิดหวัง
ถึงแมวา จะมีวฒ
ั นธรรมองคการเชิงสนับสนุน บางครัง้ ผูจ ัดการโครงการจําเปนตอง
แหกกฎเพื่อผลิตผลลัพธของโครงการใหทนั เวลา เชน ถาโครงการหนึง่ ตองใชซอฟตแวรที่ไมตรงกับ
มาตรฐานขององคการ ผูจดั การโครงการตองใชทักษะทางการเมืองเพื่อโนมนาวผูม ีสวนไดเสียทีเ่ ห็นวา
ตองใชซอฟตแวรที่ไมตรงกับมาตรฐาน การแหกกฎองคการตองใชความเปนผูนาํ ที่เกง การสื่อสาร และ
ทักษะทางการเมือง

3.6.3 การมีตน ทุนความรูและประสบการณดานผลิตภัณฑ ธุรกิจ และระบบงาน

ในการปฏิบัติงานตามแผน ผูจัดการโครงการเทคโนโลยีสารสนเทศควรที่จะมี
ประสบการณเชิงเทคนิคมากอน เชน ถาผูจัดการโครงการเคยเปนผูนําในการออกแบบระบบงานรวม
(joint application design (JAD)) เพื่อกําหนดความตองการ ประสบการณนี้เปนประโยชนสําหรับ
ผูจัดการโครงการที่จะเขาใจภาษาทางธุรกิจ และภาษาของผูเชี่ยวทางเทคนิค
โครงการเทคโนโลยีสารสนเทศหลายโครงการมีขนาดเล็ก ดังนั้น ผูจดั การโครงการ
อาจตองทํางานเชิงเทคนิคบางงาน หรือเปนพี่เลีย้ งสมาชิกทีมงานเพือ่ ทํางานใหเสร็จ สําหรับโครงการ
ขนาดใหญ ความรับผิดชอบพื้นฐานของผูจัดการโครงการคือ นําทีมและสื่อสารกับผูมีสวนไดเสียหลัก

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการบูรณาการโครงการ หนา 3-20

ผูจัดการโครงการไมมีเวลาที่จะทํางานเชิงเทคนิคใดๆ ในกรณีนี้ ผูจัดการโครงการควรเขาใจธุรกิจและ

ระบบงาน

3.7 การติดตามและการควบคุมงานโครงการ
การติดตามงานโครงการประกอบดวยการเก็บรวบรวมขอมูล การวัด การกระจายขอมูลการ
ทํางาน และยังรวมถึงการประเมินการวัด และการวิเคราะหแนวโนมเพื่อกําหนดวาจะทําการปรับปรุง
กระบวนการอะไร ทีมงานโครงการควรติดตามการทํางานของโครงการเพื่อประเมินสถานภาพโดยรวม
และชี้ใหเห็นถึงสวนที่ตองการไดรับความใสใจเปนพิเศษ
ในการติดตามและควบคุมโครงการตองใชขอมูลจากแผนการบริหารโครงการ ประสิทธิภาพ
การทํางาน รายงานการปฏิบัติงาน และคําขอการเปลี่ยนแปลง ผลลัพธที่สาํ คัญของการติดตามและการ
ควบคุมงานคือ คําแนะนําการกระทําเพือ่ การแกไข หรือการปองกัน ซึง่ จะชวยปรับปรุงประสิทธิภาพ
โครงการ หรือลดความเสี่ยงที่เกีย่ วของ เชน ถาสมาชิกโครงการไมรายงานชั่วโมงการทํางาน การกระทํา
เพื่อแกไขปญหาอาจเปนการแสดงใหสมาชิกคนนั้นเห็นวิธีการบันทึกขอมูล หรือบอกใหรูถึงเหตุผลวา
ทําไมเขาจําเปนตองทํา สวนตัวอยางการกระทําเพื่อปองกัน เชน การปรับปรุงจอภาพของะบบการ
ติดตามเวลาเพื่อหลีกเลี่ยงขอผิดพลาดในอดีตที่คนทํากันบอยครั้ง

3.8 การควบคุมการเปลี่ยนแปลงแบบบูรณาการ
การควบคุมการเปลี่ยนแปลงที่บูรณาการประกอบดวยการระบุ การประเมิน และการบริหาร
การเปลี่ยนแปลงตลอดวงจรชีวิตโครงการ วัตถุประสงคที่สาํ คัญของการควบคุมการเปลี่ยนแปลงที่
บูรณาการ มี 3 ขอ คือ
• สรางอิทธิพลตอปจจัยทีก่ อใหเกิดความเปลี่ยนแปลง เพื่อใหแนใจวาการเปลี่ยนแปลง
นั้นเปนประโยชนตอโครงการและองคการ การเปลี่ยนแปลงทําใหผูจดั การโครงการและ
ทีมงานตองแลกกับมิติที่สาํ คัญของโครงการเชน ขอบเขตงาน เวลา คาใชจาย และ
คุณภาพ
• การสื่อสารการเปลี่ยนแปลง ผูจัดการโครงการตองรูสถานภาพของแตละสวนของ
โครงการตลอดเวลา ผูจัดการโครงการตองสื่อสารการเปลี่ยนแปลงทีส่ ําคัญกับผูบริหาร
ระดับสูงและผูมีสวนไดเสียทีส่ ําคัญ
• การจัดการการเปลี่ยนแปลงที่เกิดขึ้นจริง ซึง่ เปนหนาที่ของผูจัดการโครงการและทีมงาน
ผูจัดการโครงการตองดําเนินการอยางมีวนิ ัยในการบริหารโครงการ เพื่อชวยลดจํานวน
การเปลี่ยนแปลงที่เกิด

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการบูรณาการโครงการ หนา 3-21

แผนการบริหารโครงการเปนบรรทัดฐานสําหรับการระบุ และการควบคุมการเปลี่ยนแปลง
โครงการ ดังนั้น แผนบริหารโครงการที่เปนบรรทัดฐานคือ แผนการบริหารโครงการที่อนุมัติรวมกับการ
เปลี่ยนแปลงที่ไดรับการอนุมัติ ในแผนการบริหารโครงการประกอบดวยสวนทีอ่ ธิบายงานทีจ่ ะทําของ
โครงการ ในสวนนี้ของแผนจะอธิบายถึงสิ่งสําคัญที่ตองทําออกมา (key deliverables) ผลผลิตของ
โครงการ และความตองการดานคุณภาพ ในสวนของตารางการทํางานจะมีวันทีง่ านเสร็จตามแผน สวน
แผนงบประมาณเปนคาใชจา ยทีว่ างแผนไวสําหรับการทําสิ่งที่สําคัญ สมาชิกในทีมตองเนนทีก่ ารสงมอบ
งานตามแผนที่ไดวางไว ถาทีมงานหรือใครบางคนเปนสาเหตุใหเกิดการเปลี่ยนแปลงระหวางการดําเนิน
โครงการ ทีมงานตองทบทวนแผนการบริหารโครงการ และใหผูสนับสนุนโครงการพิจารณาอนุมตั ิ แผนที่
ไดรับการอนุมตั ิจะกลายเปนบรรทัดฐานใหมสําหรับการติดตามและควบคุมโครงการตอไป
คํารองขอเปลี่ยนแปลงเปนสิ่งทีพ่ บในโครงการและเกิดในหลายรูปแบบ อาจมาในรูปของการ
พูด การเขียน อยางเปนทางการ หรือไมเปนทางการ เชน การขอเปลี่ยนแปลงการติดตั้งเครื่องบริการอาจ
ไดรับการรองขอระหวางการประชุม เปนตน ถาการเปลี่ยนแปลงไมมีผลกระทบทางลบตอโครงการ
ผูจัดการโครงการอาจตอบตกลง ณ ตอนนั้นก็ได
อยางไรก็ตาม สิ่งสําคัญคือ ผูจัดการโครงการตองบันทึกการเปลีย่ นแปลง เพื่อหลีกเลี่ยง
ปญหาที่อาจเกิดขึ้นไดในอนาคต สมาชิกทีมควรปรับปรุงแผนการดําเนินโครงการดวย แตการ
เปลี่ยนแปลงหลายๆ เรื่องมีผลกระทบอยางมากตอโครงการ เชน ลูกคาเปลี่ยนใจเกีย่ วกับจํานวน
ฮารดแวร และมีผลกระทบตอขอบเขต และคาใชจายของโครงการ ทีมงานตองนําเสนอการเปลีย่ นแปลง
ที่สําคัญในรูปแบบของเอกสาร และควรมีกระบวนการทบทวนเปนทางการสําหรับการวิเคราะห และการ
ตัดสินใจวาจะอนุมัติการเปลีย่ นแปลงเหลานี้หรือไม
การเปลี่ยนแปลงเปนสิง่ หลีกเลี่ยงไมไดและเกิดกับโครงการเทคโนโลยีสารสนเทศ เชน การ
เปลี่ยนแปลงเทคโนโลยี การเปลี่ยนแปลงบุคลากร การเปลี่ยนแปลงลําดับความสําคัญ การควบคุมการ
เปลี่ยนแปลงอยางระมัดระวังจึงเปนปจจัยที่สําคัญตอความสําเร็จของโครงการ

3.8.1 การควบคุมการเปลีย่ นแปลงโครงการเทคโนโลยีสารสนเทศ

การบริหารการเปลี่ยนแปลงโครงการเปนกระบวนการสื่อสารและตอรองเกี่ยวของ
กับวัตถุประสงคโครงการ และความคาดหวังของผูมีสว นไดเสียโครงการ การเปลี่ยนแปลงเปนสิ่งที่
เกิดขึ้นตลอดวงจรชีวิตของโครงการ แตการเปลี่ยนแปลงอาจเปนประโยชนตอบางโครงการ เชน สมาชิก
ทีมงานคนพบวา เทคโนโลยีทางดานฮารดแวรหรือซอฟตแวรใหมที่สามารถตอบสนองความตองการของ
ลูกคาโดยใชเงินและเวลาทีน่ อ ยลงกวาเดิม ทีมงานและผูมีสว นไดเสียที่สาํ คัญควรเปดใหทําการ
เปลี่ยนแปลงในโครงการ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการบูรณาการโครงการ หนา 3-22

ทุกโครงการมีการเปลี่ยนแปลง และการจัดการมันเปนสิ่งที่สําคัญในการบริหาร
โครงการ โดยเฉพาะโครงการเทคโนโลยีสารสนเทศ เนื่องจากโครงการประเภทนีเ้ กี่ยวของกับฮารดแวร
และซอฟตแวรที่มีการปรับปรุงใหทนั สมัยบอยๆ ผูจดั การโครงการควรสรางความคุนเคยกับการ
เปลี่ยนแปลง เชน สรางความยืดหยุน ใหกับแผนและการดําเนินโครงการ ลูกคาของโครงการเทคโนโลยี
สารสนเทศควรเปดโอกาสใหสามารถทําโครงการใหบรรลุวัตถุประสงคดวยวิธีตา งๆ ถึงแมวา ผูจ ัดการ
โครงการ ทีมงาน และลูกคาจะยืดหยุน แตการเปลีย่ นแปลงควรมีระบบการควบคุมการเปลี่ยนแปลง
อยางเปนทางการ
ระบบการควบคุมการเปลี่ยนแปลงเปนกระบวนการที่ไดกาํ หนดอยางเปนทางการที่
อธิบายวา เมือ่ ไร และอยางไร ที่เอกสารโครงการที่เปนทางการอาจถูกเปลี่ยนแปลง และยังอธิบายวา
ใครมีอํานาจทีจ่ ะทําการเปลีย่ นแปลง การบริหารคอนฟกรูเรชันเปนวิธกี ารที่ใชในการควบคุมการ
เปลี่ยนแปลง

3.8.2 การบริหารคอนฟกรูเรชัน
การบริหารคอนฟกรูเรชันเปนสวนที่สาํ คัญสวนหนึง่ ของการควบคุมการเปลี่ยน
แปลงที่บูรณาการ เพราะจะทําใหเราแนใจวารายละเอียดของผลิตภัณฑถูกตองและสมบูรณ การบริหาร
คอนฟกรูเรชันประกอบดวยการระบุคอนฟกรูเรชัน (configuration identification) การควบคุมเวอรชัน
(version control) การควบคุมการเปลี่ยนแปลง (change control) การตรวจสอบ (auditing) และการ
รายงาน (reporting) ในกรณีที่เปนโครงการขนาดใหญ ผูจัดการโครงการอาจมอบหมายใหสมาชิกของ
โครงการทําหนาที่บริหารคอนฟกรูเรชัน ซึ่งเรียกวาผูเชีย่ วชาญการบริหารคอนฟกรูเรชัน

การระบุคอนฟกรูเรชัน
คอนฟกรูเรชันคือ สิ่งตางๆ (items) ที่จัดทําขึ้นในชวงเวลาที่ระบบงานยังคง
ถูกใชงาน ตัวอยางของคอนฟกรูเรชัน ไดแก ขอกําหนดเฉพาะของระบบ แผนการบริหารโครงการ
ขอกําหนดความตองการของผูใช คูมือผูใช รายละเอียดการออกแบบระบบสารสนเทศ แผนการทดสอบ
ผลการทดสอบ โปรแกรม คูมือการติดตั้ง รายละเอียดฐานขอมูล ขอมูล รายละเอียดคุณลักษณะของ
ฮารดแวร และอุปกรณตางๆ เปนตน
เพื่อการควบคุมคอนฟกรูเรชัน ทีมงานโครงการตองกําหนดรหัส พรอมกับชื่อ
ของคอนฟกรูเรชันแตละชิ้น ซึ่งจะทําใหทมี งานสามารถอางอิงถึงคอนฟกรูเรชันไดตรงกัน ตัวอยางเชน
714F-RTC-SRS
714-MTEP
โดยที่

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการบูรณาการโครงการ หนา 3-23

714 หมายถึง หมายเลขโครงการ

RTC หมายถึง Real Time Control
SRS หมายถึง Software Requirement Specification
MTEP หมายถึง Master Test and Evaluation Plan

การควบคุมเวอรชัน
การควบคุมเวอรชันคือ การจัดการเวอรชนั ที่แตกตางกันของคอนฟกรูเรชันที่
เกิดขึ้นระหวางที่ระบบยังใชงาน การควบคุมเวอรชันทําใหทีมงานสามารถบันทึกและตามรอยสถานภาพ
ของคอนฟกรูเรชันที่สาํ คัญได วิธีการที่ควบคุมที่ใชกนั มานานคือ การใชตัวเลขกํากับ ตัวอยางเชน 714F-
RTC-SRS.2 และ714-MTEP.3 ตัวเลข 2 และ 3 ที่อยูหลังจุดคือ เวอรชนั ของเอกสาร

ตระหนักถึงความตองการการเปลี่ยนแปลง

ผูใชสงคําขอเปลี่ยนแปลง

ผูพัฒนาประเมินสิ่งที่ผูใชขอเปลี่ยนแปลง

สรางรายงานการเปลี่ยนแปลง
ผูมีอํานาจความคุมการเปลี่ยนแปลงตัดสินใจ

เขาคิวคําขอเปลี่ยนแปลงเพื่อดําเนินการ ปฏิเสธคําขอเปลี่ยนแปลง
แจงผูใช
มอบหมายพนักงานใหทําการแกไขคอนฟกรูเรชัน

นําคอนฟกรูเรชันออกจากที่เก็บ

ทําการเปลี่ยนแปลง

ทบทวน/ตรวจสอบการเปลี่ยนแปลง
ทําการประกันคุณภาพและกิจกรรมการทดสอบ

นําคอนฟกรูเรชันที่เปลี่ยนแปลงแลวเขาที่เก็บ

สรางซอฟตแวรเวอรชันใหม

ทบทวน/ตรวจสอบการเปลี่ยนแปลง

รูปที่ 3.3 กระบวนการควบคุมการเปลีย่ นแปลง (Pressman, 2005)

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการบูรณาการโครงการ หนา 3-24

การควบคุมการเปลีย่ นแปลง
การเปลี่ยนแปลงเปนสิง่ สําคัญและไมสามารถหลีกเลี่ยงได แตการเปลี่ยน
แปลงเพียงเล็กนอยโดยโปรแกรมเพียงคนเดียวอาจทําใหระบบลมเหลวได สําหรับโครงการขนาดใหญ
ถาปราศจากการควบคุมการเปลี่ยนแปลงจะทําใหเกิดความโกลาหลกับโครงการ การควบการเปลี่ยน
แปลงจะมีคณะกรรมการควบคุมการเปลี่ยนแปลงซึง่ เปนกลุมคนที่แตงตั้งเปนทางการ เพื่อรับผิดชอบ
การอนุมัติ หรือปฎิเสธการเปลี่ยนแปลงทีจ่ ะเกิดกับโครงการ หนาที่เบื้องตนของคณะกรรมการนี้คือ ให
แนวทางสําหรับการเตรียมคําขอเปลี่ยนแปลง การประเมินคําขอเปลี่ยนแปลง และการบริหารการ
ดําเนินการของการเปลีย่ นแปลงที่ไดรับการอนุมัติ องคการควรมีผูมีสว นไดเสียหลักเปนกรรมการ และมี
กรรมการอื่นๆ ที่หมุนเวียนตามความจําเปน ซึ่งแตกตางกันในแตละโครงการ สวนกระบวนการการ
ควบคุมการเปลี่ยนแปลงไดแสดงในรูปที่ 3.3
กระบวนการควบคุมการเปลีย่ นแปลงเริ่มตนดวยผูใชสง คําขอเปลี่ยนแปลง
และคําขอนั้นจะถูกประเมินทั้งทางดานเทคนิค ผลกระทบที่เกิดขึ้น และคาใชจายสําหรับการ
เปลี่ยนแปลงนั้น ผูประเมินจัดทํารายงานผลการประเมินใหผูมีอํานาจควบคุมการเปลี่ยนแปลงเปนผู
ตัดสินใจ และกําหนดลําดับความสําคัญของการเปลีย่ นแปลง ถาคําขอเปลี่ยนแปลงไดรับอนุมัติ พรอม
ทั้งออกคําสั่งการเปลี่ยนแปลง ผูที่ไดรับมอบหมายจะมีสิทธิท์ ี่จะไปนําคอนฟกรูเรชันที่เกี่ยวของออกจาก
ฐานขอมูลโครงการโดยผานกระบวนการควบคุมการเขาถึงคอนฟกรูเรชัน หลังจากผานการตรวจสอบ
ระบบเรียบรอยแลว ทีมงานจึงปลอยระบบเวอรชันใหมใหกับผูใช
ลว ต
ขแ จก

คอน
กไ บเ
)

ฟ
ที่แ อ็อ

(เวอ กรูเรช
ชัน ัน

รชัน ัน อ็อ
อร ูเรช

บรร บเจ
(เว ฟกร

ทัดฐ กต
น

าน)
คอ


เจ กต
คอน ็อบ น)
ฟ
(เวอ กรูเรช ัชน อ ัดฐา
ูเร ท
รชัน ัน อ
ที่คัด ็อบเจ ฟ กร ันบรร
น ช
ออก กต
มา) คอ เวอร
(

รูปที่ 3.4 ตัวอยางการควบคุมการเขาถึงคอนฟกรูเรชั่น (Pressman, 2005)

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการบูรณาการโครงการ หนา 3-25

รูปที่ 3.4 เปนตัวอยางกระบวนการควบคุมการเขาถึงคอนฟกรูเรชัน่ การนํา

สิ่งที่เปนบรรทัดฐานออกไปทําการแกไขจะสามารถดําเนินการนําออกไปไดเพียงคนเดียว คนอื่นจะ
สามารถนําสิง่ ที่เปนบรรทัดฐานนี้ออกไปไดก็ตอเมื่อคนแรกไดนําเอาสิ่งที่เปนบรรทัดฐานที่ผานการตรวจ
สอบแลวเขามาเก็บในฐานขอมูลโครงการ คอนฟกรูเรชันที่เปลีย่ นแปลงและผานการตรวจสอบความ
ถูกตองจะไดรบั การกําหนดหมายเลขเวอรชันใหใหม ทัง้ นี้เพื่อปองกันไมใหเกิดขอผิดพลาดในคอนฟกรูเร
ชัน

การตรวจสอบคอนฟกรูเรชัน
การระบุ การควบคุมเวอรชัน และการควบคุมการเปลี่ยนแปลงชวยให
ทีมงานสามารถรักษาระเบียบของคอนฟกรูเรชันได มิฉะนัน้ แลวโครงการจะเกิดสภาพวุนวาย อยางไรก็
ตาม เราจะแนใจไดอยางไรวาการเปลีย่ นแปลงไดรับดําเนินการอยางเหมาะสม คําตอบคือ เราตอง
ตรวจสอบวาการเปลี่ยนแปลงไดรับการปรับปรุงแกไขถูกตองหรือไม ซึง่ เราตั้งคําถามตอไปนี้
• การเปลี่ยนแปลงที่ระบุในคําสั่งการเปลีย่ นแปลงไดรับการดําเนินการ
หรือไม มีการเปลี่ยนแปลงเพิ่มเติมอืน่ ๆ รวมอยูห รือไม
• มีการใชวธิ ีการทบทวนแบบเปนทางการเพื่อประเมินความถูกตองทาง
เทคนิคหรือไม
• มีการดําเนินการตามกระบวนการพัฒนาซอฟตแวร หรือตามมาตรฐานที่
กําหนดหรือไม
• มีการเนนสิง่ ทีเ่ ปลี่ยแปลงในคอนฟกรูเรชันหรือไม มีการระบุวันที่
เปลี่ยนแปลง ชื่อผูเปลี่ยนแปลงหรือไม
• มีการจดบันทึกและรายงานการเปลี่ยนแปลงหรือไม
• คอนฟกรูเรชันที่เกีย่ วของไดรับการปรับปรุงอยางเหมาะสมหรือไม

การรายงานสถานภาพของคอนฟกรูเรชัน
การรายงานสถานภาพนี้เปนการรายงานวา เกิดอะไรขึ้น ใครทํา ทําเมื่อไร
และเรื่องอื่นๆ ที่อาจมีผลกระทบตอคอนฟกรูเรชัน เสนทางไหลของสารสนเทศสําหรับการรายงานนี้ได
แสดงในรูปที่ 3.3 แตละครั้งที่คอนฟกรูเรชันที่การกําหนดรหัสใหม แตละครั้งที่มกี ารอนุมัติการ
เปลี่ยนแปลง หรือแตละครั้งที่มีการดําเนินการตรวจสอบคอนฟกรูเรชัน ตองมีการรายงานการดําเนินการ
ทุกครั้ง รายงานนี้จะจัดเก็บเขาฐานขอมูลเพื่อใหผูเกีย่ วของสามารถเรียกใชขอมูลการเปลี่ยนแปลงได ซึ่ง

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการบูรณาการโครงการ หนา 3-26

จะชวยใหขจัดปญหาที่แตละคนไมรูวาใครทําอะไร และสิ่งนัน้ มีการเปลี่ยนไปเปนอะไร เมื่อไร ดังนั้น การ

สื่อสารระหวางบุคคลจะไดรับการปรับปรุงใหดีขึ้น
ผูจัดการโครงการควรใชรายงานการปฎิบัติงานทัง้ ทางวาจาและเขียน เพื่อ
ชวยกําหนดและจัดการการเปลี่ยนแปลงโครงการ การสื่อสารอยางไมเปนทางการก็เปนการสื่อสารที่
สําคัญเชนเดียวกัน ผูจัดการโครงการอาจจัดใหมีการประชุมแบบยืนอาทิตยละครั้ง เพื่อสื่อสารสิ่งที่
สําคัญที่สุดตอโครงการอยางรวดเร็ว
การสื่อสารเปนสิ่งที่สําคัญสําหรับโครงการเพื่อแจงและประสานขอมูลที่
ทันสมัยที่สุด ผูจัดการโครงการมีหนาที่ที่จะบูรณาการการเปลี่ยนแปลงทั้งหมดของโครงการ เพื่อให
โครงการยังคงอยูกับรองกับรอย ผูจัดการโครงการ และทีมงานตองพัฒนาระบบเพื่อแจงทุกคนที่ไดรับ
ผลกระทบจากการเปลีย่ นแปลงไดทันเวลา

3.9 การปดโครงการ
กระบวนการสุดทายของการบริหารการบูรณาการโครงการคือ การปดโครงการ เพื่อทําการปด
โครงการ ผูจดั การโครงการตองจบทุกกิจกรรมและสงมอบงานที่สมบูรณหรืองานทีถ่ ูกยกเลิกไปยังบุคคล
ที่เหมาะสม ผลลัพธหลักของการปดโครงการมีดังนี้
• ขั้นตอนการปดเชิงบริหาร ทีมงานและผูมีสวนไดเสียพัฒนากระบวนการปดโครงการ
เปนขั้นเปนตอน โดยเฉพาะอยางยิง่ ขั้นตอนการปดโครงการควรกําหนดกระบวนการ
อนุมัติสําหรับสิ่งที่สง มอบทัง้ หมด
• ขั้นตอนการปดสัญญา หลายๆ โครงการมีสัญญาซึ่งเปนขอตกลงที่ผกู พันทางกฎหมาย
กระบวนการปดสัญญาอธิบายวิธีการสําหรับทําใหแนใจวาสัญญาสมบูรณ รวมทั้งการ
สงมอบสินคาและบริการและการจายเงิน
• ผลิตภัณฑ หรือบริการสุดทาย ผูสนับสนุนโครงการสนใจวาผลิตภัณฑและบริการที่
ไดรับตรงตามที่คาดไวเมื่อตอนที่อนุมัติโครงการ ผูจัดการโครงการตองดําเนินการให
ไดรับการยอมรับในผลิตภัณฑหรือบริการอยางเปนทางการ
• ปรับปรุงทรัพยสินกระบวนขององคการ ทีมงานควรเตรียมรายการเอกสารโครงการ
ขอมูลในอดีตที่ถูกสรางในรูปแบบที่มีประโยชน สารสนเทศที่ไดจากขอมูลในอดีตนี้ถือ
วา เปนทรัพยสินจากกระบวนการ เชน ทีมงานเขียนรายงานบทเรียนที่ไดเรียนรูเมื่อ
สิ้นสุดโครงการ และสารสนเทศนี้เปนทรัพยสนิ ที่มีประโยชนอยางใหญหลวงสําหรับ
โครงการในอนาคต

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการบูรณาการโครงการ หนา 3-27

3.10 สรุป
การบริหารการบูรณาการเปนองคความรูทมี่ ีความสําคัญที่สุด เพราะเปนองคความรูที่ผูกองค
ความรูอื่นๆ ทัง้ หมดเขาดวยกัน ผูจ ัดการโครงการควรเนนที่องคความรูสวนนี้
กอนการเลือกโครงการมาดําเนินการ องคการควรทําตามกระบวนการวางแผนเชิงยุทธศาสตร
โครงการเทคโนโลยีสารสนเทศ ควรสนับสนุนยุทธศาสตรเชิงธุรกิจโดยรวม เทคนิคที่นยิ มใชในการเลือก
โครงการประกอบดวยการมุงเนนความตองการองคการแนวกวาง การจัดกลุมโครงการ การทําการ
วิเคราะหทางการเงิน การพัฒนาตัวแบบการใหคะแนนแบบถวงน้าํ หนัก และการใชบัตรคะแนนสมดุล
การบริหารการบูรณาการโครงการประกอบดวยกระบวนการพัฒนาเอกสารสิทธิโ์ ครงการ
กระบวนการพัฒนาขอบเขตงานเบื้องตน กระบวนการพัฒนาแผนการบริหารโครงการ กระบวนการ
กํากับและบริหารการดําเนินโครงการ กระบวนการติดตามและควบคุมงานโครงการ กระบวนการ
ดําเนินการควบคุมการเปลี่ยนแปลงแบบบูรณาการ และกระบวนการปด
เพื่อใหการบูรณางานตางๆ ของโครงการราบรื่น ผูจัดการโครงการควรทําการวิเคราะหผูมีสวน
ไดเสียโครงการ เนื่องจากบุคคลเหลานีม้ อี ิทธิพลทัง้ ทางบวกและลบตอโครงการ อยางไรก็ตามขอมูลการ
วิเคราะหผูมีสว นไดเสียเปนขอมูลที่ออนไหว ผูจัดการโครงการไมควรรวมอยูในแผนบริหารโครงการ
ระหวางการดําเนินโครงการ ผูจัดการตองกํากับและบริหารการดําเนินโครงการ กระบวนการ
ดังกลาวจําเปนตองมีการวางแผนประสานงานและการดําเนินการตามแผน การใหความเปนผูนําที่
เขมแข็งและวัฒนธรรมเชิงสนับสนุน และการมีตนทุนความรูและประสบการณดานผลิตภัณฑ และดาน
ระบบงาน
สําหรับกระบวนการควบคุมการเปลี่ยนแปลงแบบบูรณาการควรมีการบริหารคอนฟกรูเรชัน
โดยมีคณะกรรมการเปนกลุม คนที่แตงตัง้ เปนทางการ เพื่อรับผิดชอบการอนุมัตกิ ารเปลี่ยนแปลง สวน
การบริหารคอนฟกรูเรชันประกอบดวยการระบุคอนฟกรูเรชัน การควบคุมเวอรชนั การควบคุมการ
เปลี่ยนแปลง การตรวจสอบ และการรายงาน

คําถามทายบท
1. อธิบายการบริหารการบูรณาการโครงการ
2. การบริหารการบูรณาการโครงการมีความสัมพันธอยางไรกับวงจรชีวิตการพัฒนาโครงการ
3. อธิบายพอสังเขปถึงกระบวนการการวางแผนเชิงยุทธศาสตร
4. จงใชขอมูลที่ใหคํานวณหาคา ROI NPV และระยะเวลาคืนทุน
สมมุติวาโครงการมีคาใชจา ยและกําไรภายใน 4 ปดังนี้
ปที่ 1 มีคาใชจาย 100,000 บาท ในปที่ 2-4 มีคาใชจายปละ 25,000 บาท

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการบูรณาการโครงการ หนา 3-28

ปที่ 1 ประมาณการวากําไรที่ไดเปนศูนย ปถัดไปคาดวาจะไดกําไรปละ 80,000 บาท

อัตราสวนลดเปน 8%
5. เพราะเหตุใดเอกสารสิทธิโ์ ครงการและขอบเขตโครงการเบื้องตนจึงทําใหเกิดการบรูณาดาน
ตางๆ ของโครงการ
6. จงอธิบายการบริหารคอนฟกรูเรชัน
7. เพราะเหตุใดการควบคุมการเปลี่ยนแปลงจึงเปนปจจัยที่สง ผลถึงความสําเร็จของโครงการ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารขอบเขตโครงการ หนา 4-1

4.1 บทนํา
สิ่งทีย่ ากที่สุดอยางหนึ่งในการบริหารโครงการคือ การกําหนดขอบเขตโครงการ ขอบเขต
หมายถึงงานทั้งหมดทีเ่ กี่ยวของกับการสรางผลิตผล (product) ของโครงการ และกระบวนการทีน่ ํามาใช
ในการสรางขอบเขต สิ่งที่สง มอบ (deliverable) หมายถึง ผลิตผลที่ไดจัดทําขึ้นเปนสวนหนึ่งของโครงการ
สวนสิง่ ที่สง มอบที่เกี่ยวของกับผลิตผลอาจเปนฮารดแวรหรือซอฟตแวร สวนที่สงมอบที่เกี่ยวกับ
กระบวนการ ไดแก เอกสารการวางแผน หรือรายงานการประชุม ผูมสี วนไดเสียโครงการตองตกลงกันวา
ผลิตผลของโครงการคืออะไร
การบริหารขอบเขตโครงการประกอบดวยกระบวนการกําหนดและการควบคุมวาอะไรที่รวม
หรือไมรวมในโครงการ เพือ่ ใหแนใจวาทีมงานและผูมสี วนไดเสียโครงการมีความเขาใจตรงกันวาโครงการ
จะผลิตผลิตผลอะไร และกระบวนการอะไรที่ทีมงานจะใชในการสรางผลิตผล กระบวนการบริหาร
โครงการมี 5 กระบวนการ คือ
• การวางแผนขอบเขต (scope planning) เกี่ยวของกับการตัดสินใจวาจะกําหนด สอบ
ทวน และควบคุมขอบเขตอยางไร และโครงสรางจําแนกงานจะสรางอยางไร ผลลัพธ
หลักของกระบวนการวางแผนขอบเขตโครงการคือ แผนการบริหารขอบเขต
• การกําหนดขอบเขต (scope definition) เกี่ยวของกับการทบทวนเอกสารสิทธิโ์ ครงการ
และขอกําหนดขอบเขตเบื้องตนที่ไดสรางขึ้นระหวางกระบวนการริเริม่ และระหวาง
กระบวนการวางแผน รวมทั้งคําขอเปลีย่ นแปลงที่ไดรับการอนุมัติ ผลลัพธหลักของการ
กําหนดขอบเขตคือ ขอกําหนดขอบเขตโครงการ คําขอการเปลี่ยนแปลง และแผนการ
บริหารโครงการที่ไดปรับปรุง
• การสรางโครงสรางจําแนกงาน (creating the Work Breakdown Structure (WBS))
เกี่ยวของกับการจําแนกสิ่งสงมอบหลักของโครงการใหเล็กลง ใหสามารถจัดการได
ผลลัพธสําคัญของกระบวนการคือ โครงสรางจําแนกงาน
• การทวนสอบขอบเขต (scope verification) เกี่ยวของกับการยอมรับขอบเขตงาน
อยางเปนทางการ ผูม ีสวนไดเสียหลักของโครงการ (เชน ลูกคา และผูส นับสนุนโครงการ)
ทําการตรวจตรา และรับสิ่งที่สง มอบของโครงการอยางเปนทางการ ถาสิ่งที่สง มอบไม
สามารถยอมรับได ลูกคาหรือผูมีสวนไดเสียจะขอใหเปลี่ยนแปลง ซึ่งจะกลายเปน

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารขอบเขตโครงการ หนา 4-2

คําแนะนําสําหรับการแกไข ผลลัพธหลักของกระบวนการคือ สิ่งที่สงมอบที่ไดรับการ

ยอมรับ การเปลี่ยนแปลงทีร่ องขอ และการแกไขที่ไดรับจากคําแนะนํา
• การควบคุมขอบเขต (Scope Control) เกี่ยวของกับการควบคุมการเปลี่ยนแปลง
ขอบเขตโครงการ ซึ่งเปนสิ่งทีท่ าทายตอโครงการเทคโนโลยีสารสนเทศ การควบคุม
ขอบเขตรวมถึงการกําหนด การประเมิน และการทําใหเกิดการเปลี่ยนแปลงขอบเขต
โครงการตามที่ไดรับอนุมัติในขณะที่โครงการเดินหนา การเปลี่ยนแปลงขอบเขตมักมี
ผลกระทบตอความสามารถของทีมงานทีจ่ ะทํางานใหสอดคลองกับเวลาและคาใชจา ย
โครงการ ดังนั้น ผูจัดการโครงการตองชัง่ น้าํ หนักใหดีระหวางคาใชจา ยกับประโยชนที่ได
จากการเปลี่ยนแปลงขอบเขตโครงการ ผลลัพธหลักของกระบวนการคือ คําขอการ
เปลี่ยนแปลง การแกไขตามคําแนะนํา และขอกําหนดขอบเขตโครงการที่ปรับปรุง
โครงสรางจําแนกงาน และพจนานุกรมโครงสรางจําแนกงาน ขอบเขตงานที่เปนบรรทัด
ฐาน (baseline) แผนการบริหารโครงการ

4.2 การวางแผนขอบเขต และแผนการบริหารขอบเขต

ขั้นตอนแรกของการบริหารขอบเขตโครงการคือ การวางแผนขอบเขต ปจจัยดานขนาด ความ
ซับซอน ความสําคัญและปจจัยอื่นๆ จะกระทบตอความพยายามทีต่ องใชในการวางแผนโครงการ เชน
การทํางานของทีมงานเพื่อยกระดับระบบบัญชีองคการทั้งหมดทีม่ ีสาขามากกวา 50 แหง และกระจายไป
ทั่วประเทศ ควรใชเวลาจํานวนทีเ่ หมาะสมในการวางแผนขอบเขต โครงการที่ยกระดับฮารดแวรและ
ซอฟตแวรสําหรับบริษัทบัญชีขนาดเล็กที่มีพนักงานเพียง 5 คนมีความจําเปนตองใชแรงงานที่นอยกวาใน
การวางแผนขอบเขต ไมวาจะเปนกรณีใด ทีมงานตองตัดสินใจวาจะกําหนดขอบเขตอยางไร พัฒนา
ขอกําหนดขอบเขตที่ละเอียด สรางโครงสรางจําแนกงาน ทวนสอบขอบเขต และควบคุมขอบเขต
ผลลัพธที่สาํ คัญของการวางแผนขอบเขตคือ แผนการบริหารขอบเขต ซึ่งเปนเอกสารที่รวม
คําอธิบายวาทีมควรจะเตรียมขอกําหนดขอบเขตโครงการอยางไร จะสรางโครงสรางจําแนกงานอยางไร
จะทวนสอบความสมบูรณสิ่งที่สง มอบอยางไร และจะควบคุมคําขอการเปลี่ยนแปลงขอบเขตอยางไร
ตารางที่ 4.1 เปนตัวอยางของแผนการบริหารขอบเขตโครงการยกระดับเทคโนโลยีสารสนเทศ
ขอมูลที่นาํ มาใชในการวางแผนการบริหารขอบเขตโครงการคือ เอกสารสิทธิ์โครงการ (project
charter) ขอกําหนดขอบเขตเบื้องตน และแผนการบริหารโครงการ สวนตารางที่ 4.2 แสดงเอกสารสิทธิ์
โครงการ เอกสารนี้ใหขอมูลพื้นฐานสําหรับการตัดสินใจ โดยอธิบายเปาหมายขอบเขตอยางกวางๆ
วิธีการโดยรวมที่จะบรรลุเปาหมายโครงการ และบทบาทความรับผิดชอบหลักของผูมีสวนไดเสียที่สําคัญ
ของโครงการ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารขอบเขตโครงการ หนา 4-3

ตารางที่ 4.1 ตัวอยางของแผนการบริหารขอบเขตโครงการยกระดับเทคโนโลยีสารสนเทศ

(Schwalbe, 2007)
แผนการบริหารขอบเขต
11 มีนาคม 2548
ชื่อโครงการ: โครงการยกระดับเทคโนโลยีสารสนเทศ
บทนํา
จุดมุงหมายของเอกสารนี้คือ เพื่อใหคําแนะนําและแนวทางสําหรับการเตรียมเอกสารการบริหารโครงการที่สําคัญที่
เกี่ยวของกับโครงการ
การเตรียมขอกําหนดขอบเขต
ขอกําหนดขอบเขตเบื้องตนจะเปนพื้นฐานสําหรับการเตรียมขอกําหนดโครงการที่ละเอียดมากขึ้น ขอกําหนดขอบเขต
จําเปนตองไดรับการทบทวนโดยผูมีสวนไดเสียหลัก โดยเฉพาะอยางยิ่ง ผูสนับสนุนโครงการ ผูขายที่มีศักยภาพ และผูใชสิ่ง
ที่โครงการสงมอบ ขอกําหนดขอบเขตจัดทําตามแมแบบที่บริษัทมีให และตองแนใจวามีผูเชี่ยวชาญใสขอมูลในการกําหนด
ขอบเขต เนื่องจากขอกําหนดขอบเขตจะมีรายละเอียดมากขึ้นและยาวขึ้นเมื่อโครงการกาวหนา ดังนั้น จึงควรมีการจํากัด
ความยาว สวนรายละเอียดของขอกําหนดขอบเขตใหใสเปนเอกสารแนบ เชน คําอธิบายผลิตภัณฑ คุณลักษณะ มาตรฐาน
องคการ เปนตน ขอกําหนดขอบเขตแตละเวอรชันตองมีขอความบอกชัดเจน รวมทั้งวันที่ เพื่อใหแนใจวาทุกคนใช
ขอกําหนดขอบเขตเวอรชันลาสุด การเปลี่ยนแปลงและเพิ่มเติมจะตองเนนใหเห็นชัดเจน และสื่อสารไปยังบุคคลที่เหมาะสม
ขอกําหนดขอบเขตจะเปดเผยบนเวบไซตของโครงการโดยมีการปองกันดวยรหัสลับ
การสรางโครงสรางจําแนกงาน
ทีมงานโครงการจะทํางานรวมกันเพื่อสรางโครงสรางจําแนกงาน ผูสนับสนุนโครงการและคณะกรรมการกํากับจะทบทวน
โครงสรางจําแนกงาน เพื่อใหแนใจวางานที่ตองทําใหเสร็จสมบูรณของโครงการถูกรวมในโครงสรางจําแนกงาน ทีมงาน
โครงการจะทบทวนโครงสรางจําแนกงานของโครงการที่มีลักษณะที่คลายกัน ทบทวนแนวทางการจําแนกโครงสรางงาน
ขององคการ และเนนที่การกําหนดสิ่งที่สงมอบทั้งหมดที่ตองการของโครงการ ทีมงานโครงการจะกําหนดงานที่ตองทํา
สําหรับสิ่งสงมอบแตละชิ้น ซึ่งจะไดรับการทบทวนและตกลงโดยผูจัดการโครงการ ผูสนับสนุนโครงการ และคณะกรรมการ
กํากับ แนวทางโดยทั่วไปที่ใชสําหรับการกําหนดระดับรายละเอียดคือ ระดับลางสุดของโครงสรางจําแนกงาน โดยปกติควร
จะใชเวลาไมเกิน 2 อาทิตยในการทํางานใหเสร็จ โครงสรางจําแนกงานสามารถแกไขไดตามความจําเปน และตองไดรับการ
อนุมัติจากผูสนับสนุนโครงการ และคณะกรรมการกํากับ
การทวนสอบความสมบูรณของสิ่งสงมอบของโครงการ
ผูจัดการโครงการจะทํางานรวมกับผูสนับสนุนโครงการ และคณะกรรมการกํากับเพื่อพัฒนากระบวนการสําหรับการทวน
สอบความสมบูรณของสิ่งที่สงมอบ โดยทั่วไป ผูสนับสนุนโครงการจะรับหนาที่การสอบทวนความสมบูรณของสิ่งที่สงมอบ
หลัก ผูบริหารสัญญาจะเขามาเกี่ยวของในการทวนสอบความสมบูรณของสิ่งสงมอบที่มาจากแหลงภายนอก สัญญาจะมี
ขอความที่อธิบายกระบวนการทวนสอบขอบเขตโครงการ
การบริหารคําขอการเปลี่ยนแปลงขอบเขตโครงการ
ทุกคําขอการเปลี่ยนแปลงขอบเขตโครงการที่อาจมีผลกระทบที่มีนัยสําคัญตอความตองการและระยะเวลาของโครงการ
ตองทําตามขั้นตอนการเปลี่ยนแปลงที่เปนทางการตามที่ระบุในเอกสารแนบ แบบฟอรมคําขอเปลี่ยนแปลงจะไดรับการ
ทบทวน โดยกลุมคนที่ไดรับการมอบหมาย ขั้นตอนการเปลี่ยนแปลงเปนสิ่งที่สําคัญเพื่อปองกันไมใหขอบเขตโครงการขยาย

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารขอบเขตโครงการ หนา 4-4

ตารางที่ 4.2 ตัวอยางเอกสารสิทธิ์โครงการ (Schwalbe, 2007)

ชื่อโครงการ: โครงการยกระดับเทคโนโลยีสารสนเทศ
วันที่เริ่มโครงการ: 15 มกราคม 2549 วันที่สิ้นสุดโครงการ: 15 กันยายน 2549
ผูจัดการโครงการ: ศุภชัย รุงโรจน โทร: 02-456-7890 อีเมล: supachai@hotmail.com
วัตถุประสงคโครงการ: เพื่อยกระดับฮารดแวรและซอฟตแวรสําหรับพนักงานประมาณ 2,000 คน ภายใน 8 เดือน ตาม
มาตรฐานใหมของบริษัทดังเอกสารประกอบ การยกระดับอาจสงผลตอเครื่องบริการ (server) รวมทั้งเครื่อขาย ฮารดแวร
และซอฟตแวร งบประมาณสําหรับฮารดแวรและซอฟตแวรคือ 40,000,000 บาท และงบประมาณสําหรับคาแรงคือ
1,000,000 บาท
วิธีการ:
• ปรับปรุงฐานขอมูลรายการเทคโนโลยีสารสนเทศที่มีอยูใหถูกตอง เพื่อกําหนดความจําเปนที่ตองยกระดับ
• ประมาณการรายละเอียดคาใชจายสําหรับโครงการ และรายงานใหผูบริหารระดับสูงดานเทคโนโลยีสารสนเทศ
• ออกคําขอขอเสนอราคาฮารดแวรและซอฟตแวร
• ใชพนักงานภายในใหมากที่สุดเทาที่จะเปนไปไดสําหรับการวางแผน วิเคราะห และติดตั้ง
บทบาทและความรับผิดชอบ
ชื่อ บทบาท ความรับผิดชอบ
ธนินทร วรประเสริฐ กรรมการผูจัดการ สนับสนุนโครงการ ติดตามโครงการ
ปญญา วารี ผูบริหารระดับสูงดานเทคโนโลยี ติดตามโครงการ จัดหาพนักงานโครงการ
สารสนเทศ
ศุภชัย รุงโรจน ผูจัดการโครงการ วางแผน และดําเนินการโครงการ
สาธิต กิจจา ผูอํานวยการการปฎิบัติงาน พี่เลี้ยงศุภชัย รุงโรจน
เทคโนโลยีและสารสนเทศ
จัดพนักงานโครงการ ออกบันทึกความจําถึง
นฤมล จันทนหอม รองประธานดานทรัพยากรมนุษย
พนักงานทั้งหมดเกี่ยวกับโครงการ
รัชนี กลิ่นจันทน ผูอํานวยการจัดซื้อ ชวยเหลือในการซื้อฮารดแวรและซอฟตแวร
ลายเซ็นของบุคคลขางตน
ธนินทร วรประเสริฐ ศุภชัย รุงโรจน นฤมล จันทนหอม
ปญญา วารี สาธิต กิจจา รัชนี กลิ่นจันทน
ความคิดเห็น:
“โครงการนี้ตองทําเสร็จภายใน 9 เดือนไมชากวานี้” ปญญา วารี ผูบริหารระดับสูงดานเทคโนโลยีสารสนเทศ
“เรามีสมมุติฐานวามีพนักงานเพียงพอและรับปากวาจะสนับสนุนโครงการนี้ งานตองทําสร็จในเวลาเพื่อหลีกเลี่ยงการ
ขัดจังหวะ และใหทํางานนอกเวลา ” ปญญา วารี และศุภชัย รุงโรจน ฝายเทคโนโลยีสารสนเทศ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารขอบเขตโครงการ หนา 4-5

เอกสารขนาดสั้นนี้มีสารสนเทศสําคัญจะชวยผูจัดการโครงการและทีมงานในการวางแผนการ
บริหารโครงการ นอกจากนี้ ยังมีขอมูลอื่นทีก่ ระทบตอการบริหารขอบเขตอยางไร เชน ขอมูลทางดาน
นโยบายและขัน้ ตอนการทํางานที่เกีย่ วของกับการวางแผน ขอมูลในอดีตของโครงการกอนหนานี้ ปจจัย
ทางสภาพแวดลอม เชน โครงสรางขององคการหรือเงื่อนไขการตลาด
เทคนิคและเครื่องมือที่ใชสําหรับการวางแผนขอบเขตคือ แมแบบ (template) และมาตรฐาน
รวมทัง้ ความคิดเห็นของผูเ ชีย่ วชาญ เชน ถาโครงการเกี่ยวกับการพัฒนาฐานขอมูล สมาชิกทีมงานตอง
ตัดสินใจวา จะใชการวิเคราะหและออกแบบระบบมาตรฐานวิธีใด เชน การสรางผัง E-R การใชยูสเคส
การใชผังการไหลขอมูล และอื่นๆ เพื่อชวยบันทึกขอบเขต ความคิดเห็นของผูเ ชีย่ วชาญถูกนํามาใชเพื่อ
ชวยตัดสินใจเลือกวิธที ี่ดีที่สดุ ในการบริหารขอบเขตโครงการ เชน องคการมักจางผูเ ชี่ยวชาญจากภายนอก
เพื่อประเมินและแนะนําซอฟตแวรสําเร็จรูป และชวยในการบริหารการซื้อและติดตั้งซอฟตแวรใหม

4.3 การกําหนดขอบเขต และขอกําหนดขอบเขตโครงการ

ขั้นตอนตอไปของการบริหารขอบเขตโครงการคือ การกําหนดงานที่โครงการตองทํา การ
กําหนดขอบเขตที่ดีมีความสําคัญตอความสําเร็จของโครงการอยางมาก เพราะมันชวยทําใหเกิดความ
แมนยําในเรื่องเวลา คาใชจาย และการประมาณการทรัพยากร ขอบเขตที่ดีชวยเปนบรรทัดฐาน
(baseline) สําหรับการวัดประสิทธิภาพ และควบคุมโครงการ และยังชวยการสื่อสารงานและความ
รับผิดชอบที่ชัดเจน เครื่องมือและเทคนิคที่ใชในการกําหนดขอบเขตคือ การวิเคราะหผลิตผล การกําหนด
ทางเลือกในการทํางาน ความเขาใจและการวิเคราะหความตองการของผูมีสวนไดเสียโครงการ และการใช
ดุลพินิจของผูเชี่ยวชาญ ผลลัพธของการกําหนดขอบเขตโครงการคือ ขอกําหนดขอบเขตโครงการ
ดังที่ไดอธิบายในเรื่องการบริหารการบูรณาการโครงการ ทีมงานโครงการพัฒนาขอกําหนด
ขอบเขตเบื้องตนในขั้นตอนการริเริ่มโครงการ ซึ่งเปนสวนหนึ่งขององคความรูดานการบริหารการบูรณา
การโครงการ เอกสารนี้ พรอมดวยเอกสารสิทธิ์โครงการ นโยบาย ขัน้ ตอน และคําขอเปลี่ยนแปลงที่อนุมัติ
เปนขอมูลพืน้ ฐานสําหรับการสรางขอกําหนดขอบเขตโครงการ ตารางที่ 4.3 เปนตัวอยางขอกําหนด
ขอบเขตโครงการเบื้องตน

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารขอบเขตโครงการ หนา 4-6

ตารางที่ 4.3 ตัวอยางขอกําหนดขอบเขตโครงการเบือ้ งตน (Schwalbe, 2007)

ชื่อโครงการ: โครงการบริหารอินทราเน็ต
วันที:่ 15 มิถุนายน 2548 เตรียมโดย: สมคิด ดังประสงค ผูจัดการโครงการ (02-555-78091)
somkid_d@hotmail.com
ความเหมาะสมของโครงการ: นพดล เจริญกิจ กรรมการผูจัดการของบริษัทที่ปรึกษานพดลและเพื่อน ไดรองขอ
โครงการนี้เพื่อชวยใหบริษัทบรรลุเปาหมายเชิงยุทธศาสตรของบริษัท อินทราเน็ตใหมจะชวยใหลูกคาปจจุบันและลูกคา
ในอนาคตไดเห็นความเชี่ยวชาญของบริษัทเพิ่มขึ้น โดยผานสวนตางๆ ของอินทราเน็ต โครงการนี้จะลดคาใชจายภายใน
และเพิ่มความสามารถทํากําไรโดยการใหเครื่องมือมาตรฐาน เทคนิค แมแบบ และความรูการบริหารโครงการกับที่
ปรึกษาภายในทั้งหมดของบริษัท งบประมาณสําหรับโครงการคือ 5,000,000 บาท คาใชจายสําหรับการปฎิบัติงาน
หลังจากโครงการเสร็จสมบูรณปละ 500,000 บาท แตละปคาดวาจะมีกําไร 800,000 บาท สิ่งที่สําคัญคือโครงการ
สามารถเลี้ยงตัวเองไดภายใน 1 ป
คุณลักษณะของผลิตผล และความตองการ
1. แมแบบและเครื่องมือ: อินทราเน็ตจะใหผูใชที่ไดรับอนุญาตใหดาวนโหลดแฟม ผูใชสามารถสรางเอกสารการบริหาร
โครงการ และชวยใหผูใชสามารถใชเครื่องมือบริหารโครงการ แฟมเหลานี้จะเปนไมโครซอฟตเวิรด เอ็กซเซล แอค
เซ็ซ หรือ HTML หรือ PDF
2. การสงงานของผูใช: ผูใชไดรับการสงเสริมใหสงแฟมงานทางอีเมลตามตัวอยางแมแบบและเครื่องมือไปยังผูดูแลเว็บ
ผูดูแลเว็บสงแฟมตอไปยังบุคคลที่เหมาะสมที่จะทบทวน และถาแฟมงานไดรับการพิจารณาวาเหมาะสมถูกตอง
แฟมจะสงไปยังอินทราเน็ต
3. บทความ: บทความจะใสในอินทราเน็ต ถาไดรับอนุญาตจากเจาของลิขสิทธิ์ รูปแบบของบทความคือ PDF ผูจัดการ
โครงการอาจอนุญาตบทความที่อยูในรูปแบบอื่นwfh
4. การขอบทความ: อินทราเน็ตจะมีสวนสําหรับใหผูใชขอใหคนใดคนหนึ่ง ของบริษัทคนหาบทความที่ตองการ
ผูจดั การ PMO ตองอนุมัติคําขอเปนอันดับแรก และกําหนดคาธรรมเนียมการใชบริการ
5. เชื่อมโยง: การเชื่อมโยงภายนอกทั้งหมดจะทดสอบทุกอาทิตย การเชื่อมโยงที่ขาดจะไดรับการซอมหรือเอาออก
ภายใน 5 วันทําการหลังจากที่พบ
6. คุณลักษณะ “ถามผูเชี่ยวชาญ” ตองงายและเชิญชวนใหถาม และแจงกลับวาไดรับคําถามทันที รวมทั้งสามารถสง
คําถามตอไปยังผูเชี่ยวชาญที่เหมาะสม (เพราะมีการบํารุงรักษาฐานขอมูลผูเชี่ยวชาญของระบบ) และสามารถบอก
สถานะภาพของคําถามที่ไดตอบ ระบบตองรับการจากเงินคาคําปรึกษา
7. ความมั่นคง: อินทราเน็ตตองมีระดับความมั่นคงหลายระดับ พนักงานภายในทั้งหมดจะเขาถึงอินทราเน็ตทั้งหมด
เมื่อพนักงานใสขอมูลสวนตัว ขอมูลบางสวนของอินทราเน็ตเปดเผยสูสาธารณะจากเว็บไซตของบริษัท สวนอื่นของ
อินทราเน็ตจะเปดใหลูกคาปจจุบัน โดยสอบทวนกับฐานขอมูลลูกคาปจจุบัน อินทราเน็ตอีกสวนมีใหสําหรับผูที่จาย
คาธรรมเนียมเมื่อเขามาใช
8. การคนหา: อินทราเน็ตตองมีฟงกชันคนหาสําหรับผูใช โดยคนหาตามหัวขอ คําสําคัญ เปนตน
9. อินทราเน็ตตองสามารถเขาถึงไดโดยการใชเบราวเซอรมาตรฐาน ผูใชตองมีซอฟตแวรประยุกตที่เหมาะสมเพื่อเปด
แมแบบและเครื่องมือ
10. อินทราเน็ตตองเปดใหบริการ 24 ชั่วโมง 7 วันตอสัปดาห โดยมี 1 ชั่วโมงสําหรับการบํารุงรักษาระบบ และอื่นๆ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารขอบเขตโครงการ หนา 4-7

ถึงแมวา เนื้อหาจะเปลี่ยนไปตามโครงการ ขอกําหนดขอบเขตโครงการอยางนอยควรมี

คําอธิบายโครงการ ที่ประกอบดวยวัตถุประสงคโดยรวมของโครงการ และเหตุผลสนับสนุนโครงการ
คําอธิบายรายละเอียดสิ่งที่สง มอบทัง้ หมด และคุณลักษณะของผลิตผลและบริการทีต่ องการ
ในขอกําหนดขอบเขตโครงการควรบันทึกเงื่อนไขความสําเร็จของโครงการ รวมทัง้ สารสนเทศ
อื่นที่เกี่ยวของกับขอบเขต เชน อาณาเขตโครงการ (project boundary) เงื่อนไขการยอมรับผลิตผล
สมมุติฐานและขอจํากัดโครงการ และการจัดโครงสรางโครงการ ความเสี่ยง ประมาณการคาใชจา ย การ
บริการคอนฟกรูเรชัน เปนตน นอกจากนี้ขอกําหนดขอบเขตโครงการควรอางอิงถึงเอกสารตางๆ เชน
คุณลักษณะของผลิตภัณฑ หรือเอกสารนโยบาย ซึง่ อาจกระทบตอวิธกี ารผลิตสินคาหรือบริการ โครงการ
เทคโนโลยีสารสนเทศที่พฒ ั นาซอฟตแวรควรมีรายละเอียดฟงกชนั และรายละเอียดการออกแบบ ซึ่งควร
ถูกอางอิงในขอกําหนดขอบเขตที่ละเอียดมากขึ้น

ตารางที่ 4.4 ตัวอยางการกําหนดขอบเขตใหละเอียดมากขึน้ (Schwalbe, 2007)

เอกสารสิทธิ์โครงการ:
การยกระดับอาจกระทบเครื่องบริการ (server) …….
ขอกําหนดขอบเขตเบื้องตน:
เครื่องบริการ: ถาตองการเครื่องบริการเพิ่มเพื่อสนับสนุนโครงการนี้ เครื่องบริการตองเขากันไดกับเครื่องบริการ
ที่มีอยู ถามันจะคุมคามากกวาที่ขยายเครื่องที่มีอยูเดิม คําอธิบายที่ละเอียดของการขายตองสงใหผูบริหาร
ระดับสูงดานเทคโนโลยีสารสนเทศอนุมัติ ดูขอกําหนดเครื่องบริการในเอกสารแนบ กรรมการผูจัดการตอง
อนุมัติแผนละเอียดที่อธิบายเครื่องบริการและสถานที่ตั้งอยางนอย 2 อาทิตยกอนติดตั้ง
ขอกําหนดขอบเขตโครงการฉบับที่ 1:
เครื่องบริการ: โครงการนี้ตองการซื้อเครื่องบริการเพิ่ม 10 เครื่อง เพื่อสนับสนุนเว็บ เครือขาย ฐานขอมูล
ระบบงาน และการพิมพ โดยกําหนดให 2 เครื่องตอฟงกชันดังกลาว รายละเอียดของเครื่องบริการมีใน
ภาคผนวก 8 พรอมกับแผนการติดตั้งเครื่องบริการ

ขณะที่เวลาผานไป ขอบเขตโครงการจะชัดเจนและเฉพาะเจาะจงมากขึ้น ดังเชนตัวอยางใน

ตารางที่ 4.4 ที่แสดงใหเห็นวาขอบเขตจากตารางที่ 4.2 ไดกลายเปนขอบเขตที่ละเอียดมากขึน้ เมื่อทีมงาน
ไดรับสารสนเทศมากขึ้นและมีการตัดสินใจเกี่ยวกับขอบเขตโครงการ เชน ผลิตผลที่ตองการไดรับการ
อนุมัติใหซื้อหรือมีการเปลี่ยนแปลง ทีมงานควรปรับปรุงขอกําหนดโครงการใหม และควรตั้งชื่อแฟมเก็บ
ขอกําหนดขอบเขตโครงการใหตางกัน การปรับปรุงเหลานี้ตองมีการปรับแผนการบริหารขอบเขต
ขอกําหนดขอบเขตโครงการที่ทนั สมัยจะเปนเอกสารสําคัญสําหรับการพัฒนาและยืนยันความ
เขาใจขอบเขตโครงการ เพราะในเอกสารอธิบายรายละเอียดงานที่ตองทําใหสาํ เร็จ และเปนเครื่องมือที่
สําคัญสําหรับการประกันความพึง่ พอใจของลูกคา และปองกันการขยายขอบเขต

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารขอบเขตโครงการ หนา 4-8

4.4 การสรางโครงสรางจําแนกงาน
หลังจากสิน้ สุดการดําเนินการกระบวนการวางแผนและการกําหนดขอบเขต ขั้นตอนตอไปใน
การบริหารขอบเขตคือ การสรางโครงสรางจําแนกงานซึง่ คือ การจัดกลุมสิ่งที่สง มอบของงานที่ไดกําหนด
ในขอกําหนดขอบเขตโครงการ เนื่องจากโครงการสวนใหญเกี่ยวของกับคนและสิ่งที่สง มอบจํานวนมาก
จึงเปนสิง่ สําคัญที่ตองจัดการและแบงงานเปนสวนๆ โครงสรางจําแนกงานเปนเอกสารพืน้ ฐานในการ
บริหารโครงการ เชนการวางแผนและการจัดการตารางการทํางานของโครงการ คาใชจาย ทรัพยากร และ
การเปลี่ยนแปลง เนื่องจากโครงสรางจําแนกงานกําหนดขอบเขตทั้งหมดของโครงการ ผูเชี่ยวชาญการ
บริหารโครงการบางคนเชื่อวาไมควรทํางานที่ไมปรากฎในโครงสรางจําแนกงาน ดังนั้น จึงเปนสิง่ สําคัญที่
ตองพัฒนาโครงสรางจําแนกงานที่ดี
ขอกําหนดขอบเขตโครงการและแผนการบริหารโครงการคือ ขอมูลพื้นฐานสําหรับการสราง
โครงสรางจําแนกงาน เทคนิคและเครื่องมือหลักคือ แมแบบ โครงสรางจําแนกงาน การแตกงาน หรือการ
แบงสิ่งที่สง มอบเปนชิน้ เล็กๆ ผลลัพธของกระบวนนี้คือ โครงสรางจําแนกงาน พจนานุกรมโครงสราง
จําแนกงาน ขอบเขตงานที่เปนบรรทัดฐาน (scope baseline) และปรับปรุงขอกําหนดขอบเขตโครงการ
และแผนการบริหารขอบเขต

อินทราเน็ต

เพจของฝายการ
แบบเว็บไซต แบบโฮมเพจ เพจของฝายขาย
ตลาด

แผนที่ไซต ขอความ ขอความ ขอความ

แบบกราฟก ภาพ ภาพ ภาพ

โปรแกรม ไฮเปอรลิงค ไฮเปอรลิงค ไฮเปอรลิงค

รูปที่ 4.1 ตัวอยางโครงสรางจําแนกงานตามผลิตภัณฑ (Schwalbe, 2007)

โครงสรางจําแนกงานเปนรูปตนไมของกิจกรรม คลายกับผังโครงสรางองคการ ทีมงานสามารถ

สรางโครงสรางจําแนกงานไดทั้งตามผลิตภัณฑและตามขั้นตอนของโครงการ หลายๆ คนชอบทีจ่ ะสราง
โครงสรางจําแนกงานตามผลิตภัณฑในรูปของผังกอน เพื่อใหเห็นภาพทัง้ โครงการ ดังรูปที่ 4.1 โครงการ
อินทราเน็ตประกอบดวยผลิตภัณฑหลัก 4 อยางคือ แบบเว็บไซต โฮมเพจสําหรับอินทราเน็ต เพจของฝาย
การตลาด และเพจของฝายขาย ในทางกลับกัน โครงสรางจําแนกงานสําหรับโครงการเดียวกันสามารถจัด

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารขอบเขตโครงการ หนา 4-9

ตามขั้นตอนของโครงการไดดังรูปที่ 4.2 ซึ่งประกอบดวยขั้นตอนแนวความคิด การออกแบบ การพัฒนา

เว็บไซต การสิ้นสุด และการสนับสนุน

รูปที่ 4.2 ตัวอยางการสรางโครงสรางจําแนกงานตามขั้นตอนของโครงการ (Schwalbe, 2007)

โครงสรางจําแนกงานยังสามารถแสดงในรูปของตารางทีม่ ีรายการงานที่ทาํ เปนกลุมๆ

และมีการยอหนา ดังตารางที่ 4.5

ตารางที่ 4.5 ตัวอยางการแสดงโครงสรางจําแนกงานในรูปของตาราง (Schwalbe, 2007)

1.0 แนวความคิด
1.1 ประเมินระบบปจจุบัน
1.2 กําหนดความตองการ
1.2.1 กําหนดความตองการของผูใช
1.2.2 กําหนดเนื้อหาความตองการ
1.2.3 กําหนดความตองการระบบ
1.2.4 กําหนดเจาของเครื่องบริการ
1.3 กําหนดฟงกชันเฉพาะ
1.4 กําหนดความเสี่ยง และวิธีการบริหารความเสี่ยง
1.5 การพัฒนาแผนโครงการ
1.6 สรุปความตองการใหทีมพัฒนาเว็บ
2.0 การออกแบบเว็บไซต
3.0 การพัฒนาเว็บไซต
4.0 การสิ้นสุด
5.0 การสนับสนุน

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารขอบเขตโครงการ หนา 4-10

รูปที่ 4.3 แสดงโครงสรางจําแนกงานตามขั้นตอนในรูปแบบของแผนภูมิแกนต โดยใชโครงสราง

จําแนกงานจากตารางที่ 4.5
โครงสรางจําแนกงาน ตารางเวลา

รูปที่ 4.3 ตัวอยางแผนภูมิแกนต (Schwalbe, 2007)

โครงสรางจําแนกงานในรูปที่ 4.1 4.2 4.3 และ ตารางที่ 4.5 ไดนําเสนอสารสนเทศในรูปแบบ

ของลําดับขั้น (hierarchical form) ระดับ 0 ของโครงสรางจําแนกงานเปนตัวแทนโครงการทัง้ หมด และ
เปนระดับบนสุด (แตมีบางแหลงเรียกระดับบนสุดวาระดับ 1 แทนระดับ 0 ) ระดับ 1 เปนตัวแทนผลิตผล
หรือขั้นตอนหลักของโครงการ ระดับ 2 เปนกลุมผลิตผลยอยของผลิตผลระดับที่ 1 หรือขั้นตอนยอยจาก
ระดับที่ 1 เชน ในรูปที่ 4.2 หัวขอ “แนวความคิด” ประกอบดวยขัน้ ตอนยอยอีก 6 ขั้นตอนคือ ประเมิน
ระบบปจจุบัน กําหนดความตองการ กําหนดฟงกชนั งานเฉพาะ กําหนดความเสี่ยงและวิธีการบริหาร
ความเสีย่ ง พัฒนาแผนโครงการ และสรุปความตองการใหกับทีมงานเว็บ ภายใตระดับ 2 มีงานยอย ซึง่
เรียกวาระดับ 3 ในขั้นตอน “กําหนดความตองการ” ประกอบดวยขัน้ ตอนยอยอีก 4 ขั้นตอนคือ กําหนด
ความตองการผูใช กําหนดความตองการเนื้อหา กําหนดความตองการเครื่องบริการ และกําหนดความ
ตองการเจาของเครื่องบริการ
ตามรูปที่ 4.2 ระดับต่ําที่สดุ คือ ระดับ 3 งานที่อยูในระดับนี้เรียกวา แพ็กเก็จงาน (work
package) ซึ่งผูจัดการโครงการจะใชในการควบคุมและติดตามงาน โดยทั่วไป แตละแพ็กเก็จงานใน
โครงสรางจําแนกงานควรมีขนาดประมาณ 80 ชั่วโมงการทํางาน แพ็กเก็จงานอาจคิดไดในแงของความ
รับผิดชอบและการรายงาน หรืออาจเปนฮารดแวร หรืออุปกรณเฉพาะ เชน เครื่องบริการเฉพาะ (specific
server)

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารขอบเขตโครงการ หนา 4-11

มีหลายคนสับสนระหวางงานโครงสรางจําแนกงานกับงานในรายละเอียดขอกําหนดของงาน
งานในโครงสรางจําแนกงานแทนงานที่จาํ เปนทําเพื่อใหโครงการเสร็จสมบูรณ แตรายละเอียดขอกําหนด
ของงานเปนคุณลักษณะของผลิตภัณฑที่โครงการจะตองสงมอบ
ขอหวงใยอีกประการหนึ่งคือ เมื่อสรางโครงสรางจําแนกงานเราจะจัดการโครงสรางจําแนกงาน
อยางไร เพราะมันจะเปนพืน้ ฐานสําหรับการบริหารตารางเวลาโครงการ เราควรมุงไปที่งานอะไรที่
จําเปนตองทําใหสําเร็จ และทําอยางไร ไมใชเมื่อไรงานจะทําเสร็จ อาจกลาวไดอีกอยางคือ งานไม
จําเปนตองพัฒนาแบบเรียงลําดับ เราสามารถสรางโครงสรางจําแนกงานโดยการใชกลุมกระบวนการ
บริหารโครงการของวงจรชีวติ โครงการที่ประกอบดวย การริเริ่มโครงการ การวางแผน การปฏิบัตกิ าร การ
ควบคุมโครงการ และ การปดโครงการ ดังแสดงในระดับที่ 1 รูปที่ 4.2 การทําเชนนี้ ไมเพียงแตทีมงานจะ
ทําตามวิธกี ารปฎิบัติการบริหารโครงการทีด่ ีแลว งานในโครงสรางจําแนกงานยังนํามาเชื่อมเขากับเวลาได
งายขึน้

รูปที่ 4.4 ตัวอยางแผนภูมิแกนตสาํ หรับโครงการอินทราเน็ตทีจ่ ัดตามกลุมกระบวนการบริหาร

โครงการ (Schwalbe, 2007)

รูปที่ 4.4 แสดงโครงสรางจําแนกงานและแผนภูมิแกนตสําหรับโครงการอินทราเน็ตที่จัดตาม

กลุมกระบวนการบริหารโครงการทั้ง 5 กลุม งานภายใตหัวขอ “การริเริ่มโครงการ” ประกอบดวย การเลือก
ผูจัดการโครงการ การสรางทีม การพัฒนาเอกสารสิทธิ์โครงการ งานภายใตการวางแผนประกอบดวยการ
พัฒนาขอกําหนดขอบเขต การสรางโครงสรางจําแนกงาน การพัฒนาและปรับปรุงแผนอื่นๆ ใหดีขน้ึ สวน
งานแนวความคิด การออกแบบเว็บไซต การพัฒนาเว็บไซต การสิ้นสุดโครงการ และการสนับสนุน ซึง่
แสดงในโครงสรางจําแนกงานระดับ 1 ในรูปที่ 4.2 ไดกลายเปนหัวขอ โครงสรางจําแนกงานระดับ 2
ภายใตหัวขอ “การดําเนินโครงการ” ของรูปที่ 4.4 งานที่ดําเนินการสวนนี้จะแตกตางไปตามโครงการ แต
หลายงานภายใตกลุมกระบวนการบริหารโครงการอื่นๆ มีความคลายคลึงกันทุกโครงการ ถาเราไมใชกลุม

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารขอบเขตโครงการ หนา 4-12

กระบวนการบริหารโครงการในโครงสรางจําแนกงาน เราสามารถมีกลุม ระดับ 1 ทีเ่ รียกวา “การบริหาร

โครงการ” เพือ่ ใหแนใจวางานที่เกีย่ วกับการบริหารโครงการไดใสไวในบัญชี โปรดจําไววา งานทัง้ หมดควร
ระบุไวในโครงสรางจําแนกงาน รวมทั้งการบริหารโครงการ
บางโครงการผูจ ัดการโครงการชอบที่จะรวมงานที่สงมอบทุกงานไวในโครงสรางจําแนกงาน ซึ่ง
ควรตองสอดคลองกับขอกําหนดโครงการ และเอกสารสิทธิ์โครงการ นอกจากนี้ ยังมีสงิ่ ที่สาํ คัญอีกเรื่อง
หนึง่ คือ ควรใหทีมงานทั้งโครงการ และลูกคามีสวนในการสรางและทบทวนโครงสรางจําแนกงาน เพราะ
คนที่จะเปนคนทํางานควรชวยวางแผนงาน การจัดประชุมกลุมเพื่อพัฒนา โครงสรางจําแนกงานจะชวย
ทุกคนเขาใจวา งานอะไรตองทํางานใหเสร็จ และทําอยางไร โดยใคร

4.4.1 วิธีการทีช่ วยในการพัฒนาโครงสรางจําแนกงาน

มีหลายวิธีการที่ทีมงานโครงการสามารถใชในการพัฒนาโครงสรางจําแนกงาน วิธีการ
เหลานี้ไดแก การใชแนวทาง วิธีอุปมา วิธกี ารจากระดับบนสูระดับลางและวิธีการจากระดับลางขึ้นสู
ระดับบน และวิธีการจัดผังความคิด

การใชแนวทาง
องคการหลายองคการมีขอแนะนําและแมแบบสําหรับการพัฒนาโครงสราง
จําแนกงาน พรอมตัวอยางที่ไดจากโครงการกอนหนานี้ เชน สถาบันการบริหารโครงการ (Project
Management Institute) ไดพัฒนามาตรฐานการปฏิบตั ิสําหรับชี้แนะการสรางและการประยุกตโครงสราง
จําแนกงานกับการบริหารโครงการ (ดูไดจาก www.pmi.org) เอกสารนี้มีตวั อยางโครงสรางจําแนกงาน
จากโครงการตางๆ

วิธีอุปมา
วิธีอุปมาเปนการใชโครงสรางจําแนกงานของโครงการทีค่ ลายคลึงกับโครงการที่
กําลังทํามาเปนจุดตั้งตน บางองคการจะเก็บโครงสรางจําแนกงาน และเอกสารโครงการอื่นๆ เพื่อชวยการ
ทํางานของทีมงาน ซึง่ จะชวยใหการทํางานมีประสิทธิมากขึ้น

วิธีการจากระดับบนสูระดับลางและวิธีการจากระดับลางขึ้นสูร ะดับบน
ผูจัดการโครงการสวนใหญรูสึกวาการทําโครงสรางจําแนกงาน ดวยวิธีการจาก
ระดับบนสูระดับลางจะสะดวก วิธีการนีเ้ ริ่มจากงานทีใ่ หญที่สุดของโครงการและแตกงานนัน้ ออกเปนงาน
รอง กระบวนการนี้เปนการทําใหงานใหมรี ายละเอียดมากขึ้นๆ รูปที่ 4.2 คือ ตัวอยางของงานที่แตกลงถึง

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารขอบเขตโครงการ หนา 4-13

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

วิธีการจัดผังความคิด
การจัดผังความคิดคือ เทคนิคที่ใชกิ่งกานทีแ่ ตกออกเปนรัศมีจากความคิดหลักเพื่อ
จัดโครงสรางความคิด แทนที่จะเขียนงานออกมาเปนรายการ หรือพยายามที่จะสรางโครงสรางจําแนก
งานทันที การจัดผังความคิดยอมใหคนเขียน หรือวาดภาพความคิดในรูปแบบที่ไมใชเปนเสน การทําเชนนี้
ทําใหมองเห็นภาพมากกวา การจัดกลุมงานสามารถเปดใหแตละคนสรางสรรคความคิดใหมๆ และเพิ่ม
การมีสวนรวมของทีมงาน
กา
รบ
ริห
ารโ
คร
งก
าร

รูปที่ 4.5 ตัวอยางการใชเทคนิคการจัดผังความคิดในการสรางโครงสรางจําแนกงาน

(Schwalbe, 2007)

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารขอบเขตโครงการ หนา 4-14

รูปที่ 4.5 แสดงการนําเทคนิคการจัดผังความคิดเพื่อสรางโครงสรางจําแนกงาน

ของโครงการยกระดับเทคโนโลยีสารสนเทศ วงกลมตรงกลางแทนโครงการทัง้ โครงการ แตละกานที่เปน
รัศมีออกจากวงกลมแทนงานหลัก หรืองานในระดับ 1 ของโครงสรางจําแนกงาน เชน งานปรับปรุงสินคา
คงคลัง เสนกิง่ ที่แตกจากกาน หรืองานหลัก 2 งาน เรียกวางานรองคือ งานปรับปรุงฐานขอมูล และงาน
ดําเนินการสินคาคงคลังทางกายภาพ งานรองงานที่ 2 ยังแตกออกเปนแขนง หรืองานยอยอีก 3 งาน
ทีมงานสามารถเพิ่มกิ่งกานและแขนงไปไดเรื่อยๆ จนกวาไมสามารถคิดอะไรตอไดอีก
หลังจากทําผังการจัดความคิดแลว ทีมงานควรแปลงไปเปนผังแบบผังโครงสราง
องคการ หรือตาราง ดังรูปที่ 4.6 การจัดผังความคิดสามารถนํามาใชสําหรับการพัฒนาโครงสรางจําแนก
งานดวยวิธีบนลงลาง หรือลางขึ้นบน นอกจากนี้ เราสามารถใชการจัดผังความคิดเอกสารสําหรับการสง
มอบงานแตละชิ้นไดเชนกัน โดยการใสงานที่ตองสงมอบไวตรงกลาง แลวใสเอกสารที่ตองสงมอบที่
เกี่ยวกับงานชิน้ นัน้
โครงการยกระดับ
เทคโนโลยีสารสนเทศ

การบริหาร ปรับปรุงสินคา การไดฮารดแวร ติดตั้งฮารดแวร

โครงการ คงคลัง และซอฟตแวร และซอฟตแวร

ปรับปรุงฐาน
นับสินคาคงคลัง เครื่องบริการ ฮารดแวรผูใช
ขอมูล

อาคาร 1 อาคาร 2 อาคาร 3

แล็ปท็อป เดสกท็อป

รูปที่ 4.6 ผลจากแปลงการใชผังจัดการความคิดไปเปนแบบผังโครงสราง (Schwalbe, 2007)

4.2.2 พจนานุกรมโครงสรางจําแนกงานและขอบเขตงานที่เปนบรรทัดฐาน
พจนานุกรมโครงสรางจําแนกงานใชอธิบายรายละเอียดเกี่ยวกับงานแตละงาน เชน
ความหมายของงาน คาใชจายในการทํางานนัน้ ใหสาํ เร็จ ทรัพยากรที่ตองการ ผูรบั ผิดชอบเปนตน สวน
รูปแบบของพจนานุกรมมีหลายรูปแบบขึ้นกับความตองการของโครงการ บางโครงการเปนการอธิบาย
แพ็กเกจงานอยางสัน้ ๆ หนึ่งยอหนา แตสําหรับโครงการที่มีความซับซอนอาจตองอธิบายแพ็จเกจงานหนึง่
หนากระดาษ ผูจัดการโครงการควรตกลงกับทีมงานและผูสนับสนุนโครงการวาตองการรายละเอียดขนาด
ใด พจนานุกรมนี้จะเปนบรรทัดฐานของงานตอไป

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารขอบเขตโครงการ หนา 4-15

4.2.3 คําแนะนําสําหรับการสรางโครงสรางจําแนกงานและพจนานุกรมโครงสรางจําแนก
งาน
การสรางโครงสรางจําแนกงานและพจนานุกรมโครงสรางงานที่ดีควรพิจารณาคําชีแ้ นะ
ดังนี้
• งานควรปรากฎเพียงที่เดียวในโครงสรางงาน
• งานที่ปรากฎในโครงสรางจําแนกงานระดับสูงคือ ผลรวมของงานยอยที่อยู
ภายใตงานนัน้
• งานควรมีผูรับผิดชอบเพียงคนๆ เดียว ถึงแมวาอาจจะมีหลายคนทํางานนั้น
• โครงสรางจําแนกงานตองสอดคลองกับวิธีท่งี านนัน้ ทําจริงๆ
• สมาชิกทีมงานควรเกีย่ วของกับการพัฒนาโครงสรางจําแนกงาน เพือ่ ใหแนใจ
วามีความสอดคลองและเปนการซื้อสมาชิกเขาโครงการ
• งานแตละงานตองบันทึกในพจนานุกรมโครงสรางจําแนกงาน เพื่อใหแนใจวา
เขาใจขอบเขตของงานถูกตองวาอะไรที่รวมอยูในงาน อะไรไมรวม
• โครงสรางจําแนกงานควรเปนเครื่องมือที่ยดื หยุนเพื่อรองรับการเปลี่ยนแปลง

4.5 การทวนสอบขอบเขต
การทวนสอบขอบเขตเกี่ยวพันกับการยอมรับความสมบูรณของขอบเขตโครงการอยางเปน
ทางการโดยผูม ีสวนไดเสีย การยอมรับนี้จะทําสําเร็จไดดวยการตรวจตราสิ่งสงมอบหลักและการลงนาม
ยอมรับ
การทวนสอบขอบเขตตางจาการควบคุมคุณภาพในแงที่วา การทวนสอบขอบเขตจะเนนทีก่ าร
ยอมรับสิ่งที่สง มอบ ขณะที่การควบคุมคุณภาพจะเนนที่คุณภาพของสิ่งที่สงมอบเปนไปตามที่ระบุไว
หรือไม โดยทั่วไปแลว การควบคุมคุณภาพควรทํากอนการทวนสอบขอบเขต แตทั้ง 2 กระบวนการ
สามารถทําไปพรอมกันได
ทีมงานโครงการตองพัฒนาเอกสารของผลิตผลและขั้นตอน เพื่อประเมินวาผลิตผลถูกตองและ
เปนทีพ่ งึ พอใจ และเพื่อใหมกี ารเปลี่ยนแปลงขอบเขตใหนอยที่สุด จึงเปนสิ่งจําเปนทีต่ องทําการทวนสอบ
ขอบเขตโครงการใหดี
ขอมูลหลักที่นาํ มาใชในการทวนสอบขอบเขตโครงการคือ ขอกําหนดขอบเขตโครงการ
พจนานุกรมโครงสรางจําแนกงาน แผนการบริหารขอบเขตโครงการ และสิ่งที่สง มอบ เครื่องมือทีใ่ ชทําการ
ทวนสอบขอบเขตคือ การตรวจตรา (inspection) ของลูกคา ผูสนับสนุน หรือผูใชตรวจตรางานหลังจาก

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารขอบเขตโครงการ หนา 4-16

ไดรับมอบงาน ผลลัพธหลักของการทวนสอบขอบเขตโครงการคือ สิ่งสงมอบที่ไดรับการยอมรับ คําขอ

เปลี่ยนแปลง วิธีการแกไขทีไ่ ดรับการแนะนํา

4.6 การควบคุมขอบเขต
การควบคุมขอบเขตคือ การควบคุมการเปลี่ยนแปลงทีม่ ีตอขอบเขตโครงการ การเปลี่ยนแปลง
อาจเกิดจากปจจัยหลายประการ เชน ผูใชมักไมแนใจจริงๆ วาตองการใหจอภาพหนาตาเปนอยางไร หรือ
ฟงกชันอะไรทีจ่ ําเปนจริงๆ ที่จะทําใหการทํางานทางธุรกิจดีขึ้น ผูพ ฒ
ั นาไมแนใจจริงๆ วาจะแปลความ
ตองการของผูใ ชอยางไร และตองจัดการกับการเปลี่ยนแปลงทางเทคโนโลยีตลอดเวลา เปนตน
เปาหมายของการควบคุมขอบเขตคือ การควบคุมปจจัยที่เปนสาเหตุการเปลีย่ นแปลง การ
ประกันวาการเปลี่ยนแปลงไดรับการดําเนินการตามขั้นตอนที่ไดพัฒนาขึ้นเปนสวนหนึ่งของการควบคุม
การเปลี่ยนแปลงที่บูรณาการ และการบริหารการเปลี่ยนแปลงเมื่อมันเกิดขึน้ การเปลี่ยนแปลงอัน
เนื่องจากขอบเขตที่ควรตระหนักมี 3 สาเหตุคือ
• การคลําหาขอบเขต (scope grope) หมายถึง ทีมงานโครงการไมมีความสามารถในการ
กําหนดขอบเขตโครงการ สถานการณเชนนี้มกั เกิดขึน้ ในชวงแรกของโครงการ เพราะ
ทีมงานและผูส นับสนุนมีปญ  หาความเขาใจวาอะไรที่โครงการควรตองทํา การคลําหา
ขอบเขตสามารถทําใหลดนอยลงโดยการกําหนดเปาหมายใหชัดเจน
• การขยายขอบเขต (scope creep) หมายถึง การเพิม่ เติมคุณลักษณะหลังจากขอบเขต
โครงการไดรับการอนุมัติ ทีมงานโครงการอาจสนใจหรือมีความคิดใหมขณะทีโ่ ครงการ
กําลังดําเนินการ ความกระตือรือรนในการเพิ่มความคิดเหลานี้สามารถเบี่ยนเบนความ
ตั้งใจ การเพิม่ คุณลักษณะและฟงกชันทีผ่ ูสนับสนุนโครงการไมไดขอและไมจําเปนทําให
ขอบเขตขยายไปโดยไมจําเปน ซึง่ จําเปนตองควบคุมตลอดโครงการเพราะจะทําใหเวลา
งบประมาณเกินกวาที่กาํ หนด
• การกาวกระโดดของขอบเขต (scope leap) หมายถึง การเปลี่ยนแปลงอยางมีนัยสําคัญ
ในขอบเขตโครงการ เชน โครงการพาณิชยอิเลคทรอนิกสของธนาคารกําหนดขอบเขตแต
แรกที่จะใหบริการใหมแกลกู คา แตมีการเปลี่ยนแปลงโครงการใหระบบพาณิชย
อิเลคทรอนิกสตองสามารถรองรับเงินทุนในตลาดเปดที่ไมไดกําหนดไวแตแรก ดังนั้น การ
เพิ่มฟงกชันที่เปลี่ยนขอบเขตและจุดเนนของโครงการ การกาวกระโดดของขอบเขต
สามารถเกิดจากการเปลี่ยนสภาพแวดลอม ธุรกิจ การแขงขัน อันสงผลตอเปาหมายของ
โครงการ องคการควรตองคิดคุณคาของโครงการปจจุบันใหม ถาการเปลีย่ นแปลงนี้
สําคัญ องคการอาจจะยุติโครงการปจจุบนั และเริ่มตนโครงการใหม

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารขอบเขตโครงการ หนา 4-17

เพื่อหลีกเลี่ยงความลมเหลวของโครงการ ผูจัดการโครงการเทคโนโลยีสารสนเทศควรปรับปรุง
การไดขอมูลจากผูใช และลดความไมสมบูรณและการเปลี่ยนแปลงความตองการ โดยมีคําแนะนําดังนี้

4.6.1 คําแนะนําสําหรับการปรับปรุงการไดขอ มูลจากผูใช

• พัฒนากระบวนการเลือกโครงการที่ดี ทุกโครงการควรมีผูสนับสนุนจากหนวยงาน
ผูใช ไมใชใครก็ไดจากหนวยงานเทคโนโลยีสารสนเทศ ทีมงานควรจัดทําสารสนเทศ
ของโครงการใหพรอม เพื่อหลีกเลี่ยงการทํางานซ้าํ ซอน และใหแนใจวามีการ
มอบหมายใหคนทํางานที่สาํ คัญ
• มีผูใชรวมในทีมงาน บางองคการตองการใหผูจัดการโครงการมาจากฝายธุรกิจไมใช
กลุมเทคโนโลยีสารสนเทศ บางองคการอาจกําหนดใหเปนผูจัดการโครงการรวมที่มา
จากทั้งสองฝาย อยางไรก็ตาม ผูใชควรไดรับมอบหมายใหเขารวมโครงการแบบเต็ม
เวลา ในกรณีที่เปนโครงการขนาดใหญ
• มีการประชุมสม่ําเสมอโดยมีกําหนดการ
• สงงานใหผูใชและผูสนับสนุนสม่ําเสมอ
• ไมสัญญาที่จะสงงานที่ไมสามารถทําไดภายในกรอบเวลา
• กําหนดสถานที่ของผูใชใหใกลกับผูพฒั นา

4.6.2 คําแนะนําสําหรับการลดความตองการที่ไมสมบูรณและการเปลี่ยนความตองการ
• พัฒนาและทําตามกระบวนการบริหารความตองการที่ไดกําหนดขั้นตอนการหา
ความตองการ
• ใชเทคนิคตางๆ เชน ตนแบบ (prototype) ยูเคส (Use Case) และการออกแบบ
ระบบงานรวม (joint application design (JAD))
• เขียนความตองการและคอยทําใหเปนปจจุบัน เพื่อพรอมใหใช
• สรางฐานขอมูลการบริหารความตองการสําหรับบันทึกและควบคุมความตองการ
• มีการทดสอบที่เพียงพอ เพือ่ ทวนสอบวาผลิตผลโครงการทํางานไดตามที่คาดหวัง
• ใชกระบวนการทบทวนการเปลี่ยนแปลงความตองการทีข่ อมา
• กําหนดวันที่เสร็จ
• จัดสรรทรัพยากรสําหรับการจัดการคําขอเปลี่ยนแปลง

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารขอบเขตโครงการ หนา 4-18

4.7 สรุป
การบริหารขอบเขตโครงการเกี่ยวพันกับกระบวนการที่ตองใหแนใจวาโครงการไดกําหนดงานที่
ตองทําทัง้ หมด และเฉพาะงานที่ตองการ เพื่อใหโครงการเสร็จสมบูรณ กระบวนการประกอบดวย การ
วางแผนขอบเขต การกําหนดขอบเขต การสรางโครงสรางจําแนกงาน การทวนสอบขอบเขต และการ
ควบคุมขอบเขต
ขั้นตอนแรกของการบริหารขอบเขตโครงการคือ การวางแผนขอบเขตเพื่อสรางแผนการบริหาร
ขอบเขต แผนนี้มีคําอธิบายวาทีมงานจะเตรียมรายละเอียดขอกําหนดขอบเขต สรางโครงสรางจําแนกงาน
ทวนสอบความสมบูรณสิ่งทีส่ งมอบ และควบคุมคําขอเปลี่ยนขอบเขตโครงการ ไดอยางไร
ขอกําหนดโครงการถูกสรางในกระบวนการกําหนดขอบเขต เอกสารนีป้ ระกอบดวยคําอธิบาย
ของผลิตผลโครงการแบบยอ สรุปสิ่งที่ตองสงมอบทั้งหมด สิ่งทีก่ ําหนดความสําเร็จของโครงการ
ขอกําหนดโครงการมักมีหลายเวอรชั่น เพื่อใหสารสนเทศมีความทันสมัย
โครงสรางจําแนกงานคือ การจัดกลุมงานของโครงการที่กําหนดขอบเขตทั้งหมด โครงสราง
จําแนกงานเปนฐานสําหรับการวางแผนและการบริหารตารางเวลา คาใชจาย ทรัพยากร และการ
เปลี่ยนแปลงของโครงการ พจนานุกรมโครงสรางจําแนกงานคือ เอกสารที่อธิบายสารสนเทศอยางละเอียด
เกี่ยวกับหัวขอแตละขอในโครงสรางจําแนกงาน การสรางโครงสรางจําแนกงานทีด่ ีจะสรางยากเนื่องจาก
ความซับซอนของโครงการ วิธีการสรางโครงสรางจําแนกงานมีหลายวิธี เชนการใชขอแนะนํา วิธอี ุปมา วิธี
บนลงลาง วิธลี างขึ้นบน และการจัดผังความคิด
การทวนสอบขอบเขตประกอบดวยการยอมรับขอบเขตโครงการอยางเปนทางการโดยผูมีสวน
ไดเสีย การควบคุมโครงการเกี่ยวกับการเปลี่ยนแปลงขอบเขตโครงการ ซึง่ มีประเด็นทีท่ ําใหขอบเขต
เปลี่ยนคือ การคลําหาขอบเขต การขยายขอบเขต การกาวกระโดดของขอบเขต การบริหารขอบเขต
โครงการที่ไมดีมีผลใหโครงการลมเหลว

คําถามทายบท
1. เพราะเหตุใดการบริหารขอบเขตจึงสําคัญตอโครงการเทคโนโลยีสารสนเทศ
2. จงอธิบายกระบวนการบริหารขอบเขตโครงการ
3. จงอธิบายวิธีการตางๆ ที่ใชในการสรางโครงสรางจําแนกงาน
4. จงอธิบายผลกระทบตอโครงการอันเนื่องจากการขยายขอบเขต สามารถหลีกเลี่ยงไดหรือไม
จงใหเหตุผล
5. จงอธิบายความแตกตางระหวางการขยายขอบเขตกับการกาวกระโดดของขอบเขต

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารเวลาโครงการ หนา 5-1

5.1 บทนํา
โครงการเทคโนโลยีสารสนเทศหลายโครงการลมเหลวในแงของการทํางานใหสอดคลองกับ
ขอบเขต เวลา และคาใชจา ยโครงการ ผูจดั การโครงการชอบกลาววา การสงมอบโครงการทันเวลาเปน
เรื่องทาทายทีส่ ุดเรื่องหนึง่ และประเด็นตารางเวลาเปนสาเหตุของความขัดแยงตลอดชวงเวลาของ
โครงการ ความแตกตางของรูปแบบการทํางานของแตละคน และวัฒนธรรมก็เปนสาเหตุอยางหนึง่ ของ
ความขัดแยง ซึ่งจะไดเรียนรูใ นเรื่องการบริหารทรัพยากรมนุษยตอไป บางคนชอบตารางเวลาที่ละเอียด
และเนนความสมบูรณของงาน คนอื่นอาจชอบใหตารางเวลายืดหยุนและเปดกวาง วัฒนธรรมทีต่ างกัน
ทําใหคนมีทัศนคติเกี่ยวกับตารางเวลาตางกัน เชน บางประเทศปดธุรกิจตอนบายหลายชั่วโมงสําหรับ
การงีบหลับตอนเทีย่ ง ประเทศอื่นๆ อาจมีศาสนาที่ตางกัน และวันหยุดประจําปที่ตา งกัน วัฒนธรรมอาจ
ทําใหคนมีการรับรูหรือความเขาใจคุณธรรมการทํางานทีต่ างกันเชนกัน บางวัฒนธรรมใหคุณคากับการ
ทํางานหนักและยึดตารางการทํางาน ขณะที่วฒ ั นธรรมอื่นอาจใหคุณคากับการผอนคลายและยืดหยุน
เนื่องจากมีความเปนไปไดตางๆ ทีท่ ําใหเกิดความขัดแยงตารางเวลา จึงเปนสิง่ สําคัญที่
ผูจัดการโครงการจะตองใชการบริหารเวลาโครงการที่ดี เพื่อชวยเพิม่ ประสิทธิภาพการทํางานในเรื่องของ
ตารางเวลา การบริหารเวลาโครงการเกีย่ วของกับกระบวนการตางๆ 6 กระบวนการคือ
• การกําหนดกิจกรรม (activity definition) เปนการกําหนดกิจกรรมเฉพาะทีท่ ีมงาน
โครงการและผูมีสวนไดเสียตองทําเพื่อจัดทําสิง่ ที่ตองสงมอบของโครงการ กิจกรรมหรือ
งานคือ ชิน้ งานที่ปรากฏในโครงสรางจําแนกงาน ซึง่ มีระยะเวลา คาใชจาย และทรัพยากร
ที่ตองใชในการทํางาน ผลลัพธของกระบวนการนี้คือ รายการกิจกรรม คุณลักษณะของ
กิจกรรม รายการหลักไมล (milestone list) และการเปลีย่ นแปลงที่ไดรับการรองขอ
• การเรียงลําดับกิจกรรม (activity sequencing) เปนการกําหนดและการบันทึก
ความสัมพันธระหวางกิจกรรมของโครงการ ผลลัพธหลักของกระบวนการคือ ผังเครือขาย
ตารางเวลาโครงการ การเปลี่ยนแปลงที่ไดรับการรองขอ และปรับปรุงรายการกิจกรรมและ
คุณลักษณที่ไดรับการปรับปรุง
• การประมาณการทรัพยากรของกิจกรรม (activity resource estimating) เปนการ
ประมาณการปริมาณทรัพยากร (เชน คน เครื่องมือ และวัตถุดิบ) ทีท่ ีมงานควรใชเพื่อ
ทํางานกิจกรรมของโครงการ ผลลัพธหลักของกิจกรรมคือ ความตองการทรัพยากรสําหรับ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารเวลาโครงการ หนา 5-2

กิจกรรม โครงสรางจําแนกงาน และคุณลักษณะของกิจกรรมและปฏิทินทรัพยากรที่ไดรับ

การปรับปรุง
• การประมาณการระยะเวลากิจกรรม (activity duration estimating) เปนการประมาณ
การเวลาการทํางานสําหรับทํากิจกรรมแตละกิจกรรมใหสมบูรณ ผลลัพธของกระบวนการ
คือ ประมาณการระยะเวลากิจกรรม และคุณลักษณะของกิจกรรมที่ไดรับการปรับปรุง
• การพัฒนาตารางเวลา (schedule development) เปนการวิเคราะหลําดับของกิจกรรม
การประมาณการทรัพยากรกิจกรรม และการประมาณชวงระยะเวลาของกิจกรรม เพื่อ
สรางตารางการทํางาน รวมทั้งปรับปรุงความตองการทรัพยากร คุณลักษณะกิจกรรม
ปฏิทินโครงการ และแผนการบริหารโครงการ ผลลัพธคือ ตารางเวลาโครงการ บรรทัดฐาน
ตารางเวลา (schedule baseline) การเปลี่ยนแปลงที่ไดรองขอ
• การควบคุมตารางเวลา (schedule control) เปนการควบคุม และการจัดการการ
เปลี่ยนแปลงที่มีผลตอตารางเวลาโครงการ รวมทั้งปรับปรุงบรรทัดฐานโครงการ รายการ
กิจกรรมและคุณลักษณะ และแผนการบริหารโครงการ ผลลัพธคือ การวัดผลการ
ดําเนินงาน การเปลี่ยนแปลงที่รองขอ และคําแนะนําเพือ่ แกไขปญหา

5.2 การกําหนดกิจกรรม
เอกสารสิทธิ์โครงการกลาวถึงวันเริ่มตน วันสุดทายของโครงการ และขอบเขตของโครงการ
เบื้องตน เอกสารนี้จึงเปนจุดตั้งตนสําหรับการเพิม่ รายละเอียดใหมากขึ้น ในเอกสารนี้ยงั มีการประมาณ
เงินที่จัดสรรใหโครงการ ผูจัดการโครงการและทีมงานเริ่มพัฒนารายการกิจกรรมและคุณลักษณะที่
ละเอียด รวมทัง้ รายการหลักไมลได โดยใชขอมูลจากเอกสารสิทธิ์โครงการ ขอกําหนดขอบเขต
โครงสรางจําแนกงาน พจนานุกรมโครงสรางจําแนกงาน และแผนการบริหารโครงการ
รายการกิจกรรมคือ กิจกรรมตางๆ ที่ปรากฎในตารางเวลาโครงการ รายการกิจกรรมควรมีชื่อ
กิจกรรม ตัวชีว้ ัดกิจกรรม คําอธิบายกิจกรรมอยางยอ สวนคุณลักษณะกิจกรรม (activity attribute) คือ
ขอมูลของแตละกิจกรรมทีเ่ กี่ยวของกับตารางเวลา เพือ่ ชวยใหเกิดความเขาใจในกิจกรรมนั้นมากขึ้น เชน
กิจกรรมสุดทายกอนหนา (predecessors) กิจกรรมตามหลัง (successors) ความสัมพันธเชิงตรรกะ
ความตองการทรัพยากร ขอจํากัด วันที่ตองการใชทรัพยากร และสมมุติฐานที่เกีย่ วของกับกิจกรรม
หลักไมลของโครงการคือ เหตุการณที่สําคัญที่ไมมีระยะเวลา หลักไมลสมบูรณไดตอง
ประกอบดวยการทํางานหลายกิจกรรม ตัวของหลักไมลเองคลายกับเครื่องหมายทีช่ วยในการกําหนดวา
มีกิจกรรมใดบางที่จําเปนที่จะทําใหหลักไมลนั้นเกิดขึ้นอยางสมบูรณ ถาหลักไมลเสร็จสมบูรณจะ
หมายความวางานตางๆ ทีก่ ําหนดสําหรับหลักไมลนั้นเสร็จสมบูรณเชนกัน หลักไมลจึงเปนเครื่องมือทีม่ ี

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารเวลาโครงการ หนา 5-3

ประโยชนสาํ หรับการกําหนดเปาหมาย และการติดตามความกาวหนา หลักไมลของโครงการอาจเปน

ความสมบูรณของเอกสารและลูกคาไดลงชื่อรับรอง เชน เอกสารการออกแบบ และแผนการทดสอบ
ความสมบูรณของสินคา เชน มอดูลซอฟตแวร หรือการติดตั้งฮารดแวรใหม กระบวนการที่สาํ คัญที่
เกี่ยวของกับความสมบูรณของงาน ไดแก การประชุมทบทวนความตองการ การทดสอบซอฟตแวร เปน
ตน
เปาหมายของกระบวนการกําหนดกิจกรรมคือ เพื่อใหแนใจวาทีมงานโครงการมีความเขาใจ
งานทัง้ หมดทีต่ องทําอยางสมบูรณ จากนั้น เราจึงสามารถเริ่มตนจัดตารางเวลางานได เชน มีงานที่
เรียกวา “เขียนรายงานผลการศึกษา” ทีมงานควรเขาใจวาหมายความวาอะไร กอนที่ตัดสินใจที่เกี่ยวกับ
ตารางเวลา เชน รายงานควรยาวเทาไร ตองทําสํารวจหรือคนหาอยางหนักเพื่อที่จะเขียนรายงานหรือไม
คนเขียนรายงานตองมีทกั ษะระดับใด นอกจากนี้ การกําหนดงานจะชวยทีมงานโครงการคิดวางานที่จะ
ทํานั้นตองใชเวลานานเทาไร และใครควรเปนคนทํา
ระหวางการดําเนินกระบวนการกําหนดกิจกรรม ผูจัดการโครงการจะสรางโครงสรางจําแนก
งาน เชน งาน “เขียนรายงานผลการศึกษา” อาจแตกเปนงานยอยที่อธิบายขั้นตอนทีเ่ กี่ยวของในการผลิต
รายงาน เชน การพัฒนาการสํารวจ การบริหารการสํารวจ การวิเคราะหผลการสํารวจ การทําการคนควา
การเขียนรางรายงาน การตรวจแกไขรายงาน และสุดทายคือ การจัดทํารายงาน
ทีมงานโครงการควรทบทวนรายการกิจกรรม และคุณลักษณะของกิจกรรมกับผูมสี วนไดเสีย
กอนยายไปทําขั้นตอนตอไปของการบริหารเวลาโครงการ ถาทีมงานไมทบทวนเวลาของกิจกรรมเหลานี้
เราอาจสรางตารางเวลาที่ไมเปนจริง และสงมอบผลงานที่ไมสามารถรับได เชน ถาผูจัดการโครงการ
ประมาณเวลาในการเขียนรายงานผลการศึกษาเพียง 1 วัน และใหพนักงานฝกหัดเปนผูเขียนรายงานได
เพียง 20 หนา ผลที่ไดคือ ลูกคาไมพอใจอยางมาก เพราะคาดหวังวาทีมงานจะมีการคนควา การสํารวจ
อยางหนัก และรายงานควรประมาณ 200 หนา การกําหนดงานใหชัดเจนจึงเปนสิ่งสําคัญสําหรับทุก
โครงการ ถามีความเขาใจงานของกิจกรรมไมถูกตองแลว การเปลีย่ นแปลงอาจจําเปนตองทํา

5.3 การเรียงลําดับกิจกรรม
หลังจากกําหนดกิจกรรมแลว ขั้นตอนตอไปของการบริหารเวลาโครงการคือ การเรียงลําดับ
กิจกรรม ซึง่ ประกอบดวย การทบทวนรายการกิจกรรมและคุณลักษณะ ขอกําหนดขอบเขตโครงการ
รายการหลักไมล และการเปลี่ยนแปลงทีไ่ ดรับการอนุมตั ิ การเรียงลําดับกิจกรรมยังรวมถึงการกําหนด
ความสัมพันธหรือความพึ่งพิงระหวางกิจกรรม

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารเวลาโครงการ หนา 5-4

5.3.1 ความพึง่ พิง

ความพึ่งพิงหรือความสัมพันธ มีความเกี่ยวของกับการเรียงลําดับกิจกรรมหรืองาน
โครงการ เชน กิจกรรมหนึ่งตองเสร็จกอนที่อีกกิจกรรมจะเริ่ม สมาชิกในทีมงานสามารถทํางานไดหลาย
งานพรอมกันหรือไม กิจกรรมสามารถทําซอน (overlap) ไดหรือไม การกําหนดความสัมพันธ หรือความ
พึ่งพิงระหวางกิจกรรมมีผลกระทบอยางมีนัยสําคัญตอการพัฒนาและการบริหารตารางเวลาโครงการ
ความพึ่งพิงของกิจกรรมโครงการเกิดจากเหตุผลพืน้ ฐาน 3 ประการดังนี้
• ความพึ่งพิงทีต่ องมี (mandatory dependencies) เปนความพึง่ พิงที่ซอนอยู
ในธรรมชาติของงานที่กาํ ลังทํา เชน เราไมสามารถทดสอบโปรแกรม
คอมพิวเตอรไดจนกวาโปรแกรมจะเขียนเสร็จ
• ความพึ่งพิงทีก่ ําหนดขึ้นเอง (discretionary dependencies) เปน
ความสัมพันธที่กําหนดโดยทีมงาน เชน ทีมงานไมเริ่มการออกแบบอยาง
ละเอียด จนกวาผูใชเซ็นตรับงาน ซึง่ เปนความสัมพันธที่ทมี งานไดตกลงกัน
• ความพึ่งพิงภายนอก (external dependencies) เปนความสัมพันธระหวาง
กิจกรรมโครงการและกิจกรรมนอกโครงการ เชน การติดตั้งระบบปฏิบัติการ
ใหมและซอฟตแวรอื่นๆ อาจขึ้นกับการสงมอบฮารดแวรใหมจากผูขาย
ถึงแมวา การสงมอบฮารดแวรใหมอาจไมอยูในขอบเขตของโครงการ เราควร
เพิ่มความพึ่งพิงกิจกรรมภายนอกโครงการ เพราะการสงมอบชาอาจจะกระทบ
ตารางเวลา

การกําหนดความพึง่ พิงของกิจกรรมเปนสิง่ สําคัญที่ตองทํารวมกับผูม ีสว นไดเสีย บาง

องคการมีแนวทางทีก่ ารกําหนดความพึง่ พิงโดยพิจารณาจากโครงการที่มีลักษณะงานคลายคลึงกัน บาง
องคการเชื่อความชํานาญของคนที่ทาํ งานโครงการนัน้ ๆ
หลายองคการไมเขาใจความสําคัญของการกําหนดความพึ่งพิงของกิจกรรม และไมใช
มันในการบริหารเวลาโครงการ ลําดับของกิจกรรมสามารถนําไปใชประโยชนกับเครือ่ งมือทีม่ ีอยู เชน ผัง
เครือขาย การวิเคราะหเสนวิกฤต ผลลัพธของการเรียงลําดับกิจกรรมคือ ผังเครือขายตารางเวลา

5.3.2 ผังเครือขาย
ผังเครือขายเปนเทคนิคที่ใชแสดงความสัมพันธ หรือการจัดลําดับของกิจกรรมโครงการ
บางคนเรียกผังเครือขายวา เปนผังเครือขายตารางเวลา หรือ ผัง PERT รูปที่ 5.1 แสดงตัวอยางผัง
เครือขายอยางงายของโครงการ Z ซึ่งใชวธิ ีการแบบแสดงกิจกรรมบนลูกศร (activity-on-arrow (AOA))

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารเวลาโครงการ หนา 5-5

จากรูป ตัวอักษร A แทนกิจกรรมที่ไดจากโครงสรางจําแนกงาน และกระบวนการกําหนดกิจกรรม ลูกศร

แทนการเรียงลําดับกิจกรรม หรือความสัมพันธระหวางงาน เชน กิจกรรม A ตองทําใหเสร็จกอนกิจกรรม
D กิจกรรม D ตองทําเสร็จกอนกิจกรรม J เปนตน โหนดคือ จุดเริ่มตนและสิ้นสุดของกิจกรรมหนึง่ ๆ โดย
โหนดแรกคือ จุดเริ่มตนของโครงการ และโหนดสุดทายแทนจุดสิน้ สุดของโครงการ

รูปที่ 5.1 ผังเครือขายแสดงกิจกรรมบนลูกศรของโครงการ Z

ถึงแมวา AOA งายแกการเขาใจและการสราง วิธีอื่นทีใ่ ชกันมากอีกวิธีคือ แผนภูมกิ าร

จัดลําดับกอนหลังของงาน (precedence diagram) หรือ ผังแบบแสดงกิจกรรมบนโหนด (activity-on-
node (AON)) รูปที่ 5.2 เปนตัวอยางของผังเครือขายการจัดลําดับกอนหลังของงาน โดยชื่อกิจกรรม
และระยะเวลาการทํากิจกรรมนั้น แสดงในโหนด เสนลูกศรแสดงความสัมพันธระหวางกิจกรรม

รูปที่ 5.2 ผังเครือขายการจัดลําดับกอนหลังของงาน หรือ AON

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารเวลาโครงการ หนา 5-6

แผนภูมิการจัดลําดับกอนหลังของงานหรือแบบ AON มีการใชมากกวาและมีขอดีมา

กวาแบบ AOA คือ 1) ซอฟตแวรการบริหารโครงการใชวิธีการแบบแผนภูมิการจัดลําดับกอนหลังของ
งาน 2) หลีกเลี่ยงความจําเปนตองใชกิจกรรมดัมมี (dummy activities) ซึ่งเปนกิจกรรมที่ไมมีระยะเวลา
และทรัพยากร แตจําเปนตองใชบางโอกาสบนผังเครือขายแบบ AOA เพื่อแสดงความสัมพันธเชิงตรรกะ
ระหวางกิจกรรม กิจกรรมดัมมี่แทนดวยเสนลูกศรประ และมีระยะเวลาเปนศูนย เชน จากรูปที่ 5.1
กิจกรรม A มากอนกิจกรรม D กิจกรรม B มากอนกิจกรรม E และ F ถามีความพึ่งพิงระหวางกิจกรรม B
และ D ดวย เราตองลากเสนประ ระหวางโหนด 1 และโหนด 2 ดังแสดงในรูปที่ 5.3 3) แผนภูมิการ
จัดลําดับกอนหลังของงานแสดงความพึ่งพิงตางๆ ของงาน ขณะทีผ่ ังเครือขายแบบ AOA ใชเฉพาะ
ความพึ่งพิงแบบสิ้นสุด-เริ่มตน

รูปที่ 5.3 ผังเครือขายที่แสดงความสัมพันธแบบดัมมี

รูปที่ 5.4 แสดงประเภทความพึ่งพิงระหวางกิจกรรมที่สามารถเกิดขึน้ ทามกลางกิจกรรม

โครงการ หลังจากที่เรากําหนดเหตุผลสําหรับความพึง่ พิงระหวางกิจกรรม (ความพึ่งพิงที่ตองมี ที่กําหนด
ขึ้นเอง และความพึง่ พิงภายนอก) เราตองกําหนดประเภทความพึง่ พิงซึ่งมี 4 ประเภทคือ
• สิ้นสุด-เริ่มตน (finish-to-start) คือ ความสัมพันธที่กจิ กรรม “จาก (from)” ตอง
เสร็จกอน กิจกรรม “ถึง (to)” จึงจะสามารถเริ่มตนทํางานได เชน ทานไมสามารถ
จัดการอบรมผูใช (งาน B) ไดจนกวาซอฟตแวรหรือระบบใหมไดติดตั้ง (งาน A)
ความสัมพันธนี้เปนความสัมพันธทพี่ บบอย และผังเครือขายแบบ AOA ใช
ความสัมพันธแบบนี้เทานัน้
• เริ่มตน-เริ่มตน (start-to-start) คือ ความสัมพันธที่กจิ กรรม “จาก (from)” ไม
สามารถเริ่มไดจนกวากิจกรรม “ถึง (to)” ไดเริ่มแลว ดังนั้น กิจกรรมทัง้ 2 สามารถ
เริ่มพรอมกันได (parallel) ลักษณะความสัมพันธแบบนี้ ทําใหเราสามารถรน

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารเวลาโครงการ หนา 5-7

ระยะเวลาโครงการได แตไมจําเปนตองเสร็จพรอมกัน เชน เราอาจเริ่มบันทึกขอมูล

(งาน B) ทันทีที่เราเริ่มเก็บขอมูล (งาน A)
• สิ้นสุด-สิ้นสุด (finish-to-finish) คือ ความสัมพันธทกี่ ิจกรรม “จาก (from)” ตองทํา
ใหเสร็จกอนกิจกรรม “ถึง (to)” จึงจะเสร็จได ดังนัน้ งานหนึง่ ไมสามารถเสร็จได
กอนที่อีกงานหนึง่ เสร็จ เชน การควบคุมคุณภาพ (งาน B) ไมสามารถเสร็จกอนที่
การผลิต (งาน A) จะเสร็จ ถึงแมวา สองงานสามารถทําไดในเวลาเดียวกัน
• เริ่มตน-สิ้นสุด (start-to-finish) คือ ความสัมพันธทกี่ ิจกรรม “จาก (from)” ตองเริ่ม
กอนกิจกรรม “ถึง (to)” จึงจะเสร็จได ความสัมพันธนี้ไมคอยไดใช แตก็เหมาะกับ
บางกรณี เชน ระบบงานเดิมถูกยกเลิก (งาน B) เมื่อระบบใหมเริ่มใชงาน (งาน A)

ความพึ่งพิงของงาน ตัวอยาง คําอธิบาย

สิ้นสุด-เริ่มตน (finish-to-start) A งาน (B) ไมสามารถเริ่มได
จนกวางาน (A) จะเสร็จ
B

เริ่มตน-เริ่มตน (start-to-start) A งาน (B) ไมสามารถเริ่มได

จนกวางาน (A) จะเริ่ม
B

สิ้นสุด-สิ้นสุด (finish-to-finish) A งาน (B) ไมสามารถเสร็จได

จนกวางาน (A) จะเสร็จ
B

เริ่มตน-สิ้นสุด (start-to-finish) A งาน (B) ไมสามารถเสร็จได

จนกวางาน (A) จะเริ่ม
B

รูปที่ 5.4 ประเภทความพึง่ พิงของงาน (Schwalbe, 2007)

5.4 การประมาณการทรัพยากรของกิจกรรม
กอนที่เราจะสามารถประมาณการระยะเวลาของแตละกิจกรรม เราตองรูวาจํานวนและ
ประเภททรัพยากรที่จะกําหนดใหกับแตละกิจกรรม ลักษณะของโครงการและองคการจะกระทบกับการ
ประมาณการทรัพยากร เครื่องมือที่ชวยในการประมาณการทรัพยากรประกอบดวย ความคิดเห็นของ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารเวลาโครงการ หนา 5-8

ผูเชี่ยวชาญ ทางเลือกที่มีให การประมาณการขนาดขอมูลและซอฟตแวร ผูที่จะชวยกําหนดทรัพยากรที่

จําเปนสําหรับโครงการควรเปนคนที่มีประสบการณและความเชีย่ วชาญในโครงการที่คลายกัน
ขอมูลที่สําคัญที่นาํ มาใชในการประมาณการคือ รายการกิจกรรม คุณลักษณะกิจกรรม
แผนการบริหารโครงการ ปจจัยเชิงสภาพแวดลอม ทรัพยากรที่มีใหใชได นอกจากนี้ ขอมูลจากโครงการ
ในอดีตจะชวยบอกจํานวนคนหรือจํานวนชั่วโมงที่โดยปกติใชในการทํางานกิจกรรม
การระดมสมองและการประเมินทางเลือกทีเ่ กี่ยวของกับทรัพยากรเปนเทคนิคที่สาํ คัญในการ
ประมาณการทรัพยากร เนื่องจากโครงการสวนใหญเกี่ยวพันกับทรัพยากรมนุษยจํานวนมาก และ
คาใชจายสวนใหญคือ คาจาง โครงการจึงควรไดความคิดที่ชัดเจนจากคนตางๆ เพื่อชวยพัฒนา
ทางเลือก และชี้ประเด็นทีเ่ กี่ยวของกับทรัพยากรตั้งแตเนิ่นๆ การประมาณการทรัพยากรควรไดรับการ
ปรับปรุงเมื่อมีรายละเอียดมากขึ้น เนื่องจากทรัพยากรที่สําคัญในการดําเนินโครงการเทคโนโลยี
สารสนเทศคือ พนักงาน ดังนัน้ กิจกรรมการประมาณการทรัพยากรจะกลาวโดยละเอียดในบทบริหาร
ทรัพยากรมนุษย
ผลลัพธของกระบวนการประมาณการทรัพยากรคือ รายการความตองการใชทรัพยากรของ
กิจกรรม โครงสรางจําแนกทรัพยากร (resource breakdown structure) โครงสรางจําแนกทรัพยากรคือ
โครงสรางลําดับขั้นที่ระบุทรัพยากรของโครงการตามกลุม และประเภท กลุมทรัพยากรอาจประกอบดวย
นักวิเคราะห โปรแกรมเมอร และผูทดสอบ ภายใตโปรแกรมเมอรอาจมีประเภทโปรแกรมเมอร เชน จาวา
โปรแกรมเมอร หรือ โคบอลโปรแกรมเมอร ขอมูลเหลานี้มีประโยชนในการกําหนดคาใชจาย การได
ทรัพยากร และอื่นๆ

5.5 การประมาณการระยะเวลากิจกรรม
หลังจากกําหนดกิจกรรม ความพึ่งพิง และประมาณการทรัพยากรของกิจกรรม ขั้นตอนตอไป
ในการบริหารโครงการคือ การประมาณการระยะเวลาของกิจกรรม (duration) ระยะเวลานี้รวมถึง
ปริมาณเวลาจริงที่ใชกับกิจกรรมบวกกับเวลาที่เผื่อ (elapsed time) เชน ถึงแมวา การทํางานอาจใชเวลา
หนึง่ อาทิตย หรือ หาวันทําการเพื่อทํางานที่แทจริง การประมาณชวงเวลาอาจเปนสองอาทิตยเผื่อเวลา
พิเศษใหสาํ หรับตองใชเพื่อไดขอมูลจากภายนอก นอกจากนี้ทรัพยากรที่กาํ หนดใหกับงานจะกระทบการ
ประมาณการระยะเวลา
คนทัว่ ไปสับสนระหวางระยะเวลากับแรงงาน แรงงานคือ จํานวนวันทํางานหรือชั่วโมงการ
ทํางานที่ตองใชเพื่อทํางานใหสมบูรณ สวนระยะเวลาสัมพันธกับเวลาที่ประมาณการ แตไมใชการ
ประมาณแรงงาน เชน สมมุติวา งานหนึง่ ใชเวลา 5 วัน และกําหนดวาใน 1 วัน ทํางานได 8 ชั่วโมง ดังนัน้
แรงงานที่ใชในการทํางานนัน้ จึงเทากับ 40 ชั่วโมง สวนระยะเวลาคือ 5 วัน ซึง่ อาจตองเพิ่มเวลาที่ตอง

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารเวลาโครงการ หนา 5-9

คอยขอมูลถาจําปน ดังนั้น สมาชิกทีมงานตองบันทึกสมมุติฐานของตนเมื่อกําหนดประมาณการ

ระยะเวลากิจกรรม นอกจากนี้ คนที่ทาํ งานจริงควรมีสวนในการประมาณการเวลา เพราะเปนคนที่ถกู
ประเมินประสิทธิภาพ ถาการเปลี่ยนแปลงขอบเขตเกิดขึ้นกับโครงการ เวลาที่ประมาณการไวควรไดรับ
การปรับปรุงเพื่อสะทอนการเปลี่ยนแปลงนี้
การประมาณการระยะเวลาของกิจกรรมใชขอมูลหลายอยาง เชน ขอกําหนดขอบเขตโครงการ
รายการกิจกรรม คุณลักษณะกิจกรรม ความตองการทรัพยากรของกิจกรรม ปฎิทินทรัพยากร และ
แผนการบริหารโครงการ รวมทั้งขอมูลจากโครงการที่ผา นมา ทีมงานควรทบทวนความถูกตองของการ
ประมาณการระยะเวลา ถาทีมงานพบวาการประมาณการทัง้ หมดยาวหรือสั้นเกินไป ทีมงานควร
ปรับปรุงการประมาณการใหสะทอนความจริงที่ไดเรียนรูม า สิง่ ที่สาํ คัญที่สุดในการทําการประมาณการ
ระยะเวลากิจกรรมคือ การมีทรัพยากรใหใช โดยเฉพาะทรัพยากรมนุษย ทักษะเฉพาะอะไรที่คนจําเปน
เพื่อทํางาน ระดับทักษะใดที่คนที่ไดรับมอบหมายใหทาํ งานในโครงการตองมี จํานวนคนเทาใดทีเ่ ราคาด
วาควรมีเพื่อทํางานในโครงการ
ผลลัพธของกิจกรรมการประมาณการระยะเวลาคือ คุณลักษณะกิจกรรมที่ปรับปรุง (ถามี)
และการประมาณการระยะเวลาของแตละกิจกรรม ระยะเวลาที่ประมาณการเปนตัวเลขเต็มจํานวน เชน
4 อาทิตย หรืออาจเปนชวง เชน 3-5 อาทิตย หรือประมาณการโดยใชการประมาณการตัวเลขสามตัว
(three-point estimate) ซึ่งประกอบดวย
• ระยะเวลาที่คาดคะเนในแงดี (optimistic) เปนระยะเวลาที่สนั้ ทีส่ ุดที่คาดวาจะทํา
กิจกรรมนัน้ แลวเสร็จเมื่อทุกสิ่งทุกอยางดําเนินไปดวยดี
• ระยะเวลาที่คาดคะเนวาจะเกิดขึ้นไดมากที่สุด (most likely) เปนระยะเวลาปกติที่คาด
วาจะทํากิจกรรมนั้นแลวเสร็จ เปนระยะเวลาที่มีความนาจะเปนเกิดขึน้ ไดมากที่สุด หรือ
เปนระยะเวลาที่เกิดบอย
• ระยะเวลาที่คาดคะเนในแงราย (pessimistic) เปนระยะเวลาทีน่ านทีส่ ุดที่คาดวาจะทํา
กิจกรรมนัน้ แลวเสร็จ เมื่อมีสถานการณทเี่ ลวรายเกิดขึ้น

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

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารเวลาโครงการ หนา 5-10

5.6 การพัฒนาตารางเวลา
การพัฒนาตารางเวลาใชผลลัพธจากกระบวนการบริหารเวลาทัง้ หมดกอนหนานี้ เพื่อกําหนด
วันเริ่มตนและวันสุดทายของโครงการ เปาหมายของการพัฒนาตารางเวลาคือ การสรางตารางโครงการ
ที่เปนจริง ตารางเวลานี้จะเปนพืน้ ฐานสําหรับการติดตามความกาวหนาของโครงการ ผลลัพธหลักของ
กระบวนการพัฒนาตารางเวลาคือ ตารางเวลาโครงการ ความตองการทรัพยากร คุณลักษณะกิจกรรม
ปฎิทินโครงการ และแผนการบริหารโครงการ เทคนิคและเครือ่ งมือที่ชว ยในกระบวนการพัฒนา
ตารางเวลามีดังนี้
• แผนภูมิแกนต (Gantt chart) เปนเครื่องมือที่ใชในการแสดงขอมูลตารางโครงการ
• การวิเคราะหเสนทางวิกฤต (critical path analysis) เปนเครื่องมือที่สาํ คัญสําหรับการ
ควบคุมและพัฒนาตารางเวลาโครงการ
• การจัดตารางเวลาโซวิกฤต (critical Chain Scheduling) เปนเทคนิคที่ใชกรณีที่มี
ทรัพยากรจํากัด
• การวิเคราะห PERT เปนเครื่องมือสําหรับการประเมินความเสี่ยงตารางเวลาของ
โครงการ

5.6.1 แผนภูมิแกนต
แผนภูมิแกนตหรือแผนภูมิแทง เปนแผนภูมิที่ใหรูปแบบมาตรฐานสําหรับการแสดง
ขอมูลตารางโครงการ โดยการแสดงรายการกิจกรรมโครงการ และวันเริ่มตนวันสิ้นสุดของกิจกรรมใน
รูปแบบปฎิทิน รูปที่ 5.5 คือ ตัวอยางแผนภูมิแกนตแบบงายๆ สําหรับโครงการ Z สวนรูปที่ 5.6 แสดง
แผนภูมิแกนตที่มีความซับซอนมากขึ้น กิจกรรมที่ในแผนภูมิจะตองสอดคลองกับโครงสรางจําแนกงาน

รูปที่ 5.5 ตัวอยางแผนภูมิแกนตแบบงายๆ

ความหมายของสัญญลักษณตางๆ ในรูปที่ 5.6 มีดังนี้

• สัญญลักษณรูปเพชรสีดําแทนหลักไมล

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารเวลาโครงการ หนา 5-11

• แทงดําหนาพรอมลูกศรที่จดุ เริ่มตนและจุดสุดทาย แทนงานสรุป

• แทงแนวนอนสีออน แทนระยะเวลาของงานแตละงาน
• ลูกศรที่เชื่อมสัญญลักษณเหลานี้ แสดงความสัมพันธหรือความพึง่ พิงระหวาง
งาน

รูปที่ 5.6 ตัวอยางแผนภูมิโครงการออกตัวซอฟตแวร

เราสามารถใชแผนภูมิเพื่อประเมินความกาวหนาของโครงการ โดยการแสดงขอมูล
ตารางเวลาที่แทจริง (actual schedule) ซึ่งเรียกแผนภูมิการติดตามผล (Tracking Gantt Charts) ดัง
แสดงในรูปที่ 5.7 แผนภูมินี้จะเปรียบเทียบตารางเวลาที่ไดวางแผนไวกับตารางเวลาที่แทจริง วันที่ของ
เวลาที่วางแผนไว (planned dates) เรียกวาวันที่บรรทัดฐาน (baseline dates) และตารางเวลาทั้งหมด
ที่ไดรับการอนุมัติเราเรียกวา”บรรทัดฐานตารางเวลา” (schedule baseline) แผนภูมิการติดตามผล
ประกอบดวยวันเริ่มตนและสิ้นสุดจริงสําหรับงานแตละงาน พรอมกับวันเริ่มตนและสิ้นสุดตามแผนของ
แตละงาน จากตัวอยางจะเห็นวาโครงการเสร็จสมบูรณ แตมีหลายงานที่คลาดเคลื่อนจากวันทีท่ ี่ได
วางแผนไว

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารเวลาโครงการ หนา 5-12

รูปที่ 5.7 ตัวอยางแผนภูมิการติดตามผล (Schwalbe, 2007)

เพื่อใหแผนภูมิแกนตเปนเครื่องมือในการประเมินความกาวหนาโครงการ แผนภูมกิ าร
ติดตามผลไดเพิ่มเติมสัญญลักษณดังนี้
• ในแผนภูมิปรากฏแทงแนวนอนสําหรับงานเพิ่มอีก 1 แทง ซอนกัน โดยแทง
แนวนอนที่อยูข างบนจะแทนชวงระยะเวลาของงานตามที่ไดวางแผนไว สวนแทง
แนวนอนแทงลางจะแทนชวงระยะเวลาการทํางานจริง ถาแทงแนวนอนตัวบนสัน้
กวาแทงตัวลาง แสดงวางานใชเวลาที่มากกวาที่กาํ หนดไวในแผน ดังเชนงานที่ 1.2
ในรูปที่ 5.7 ในทางกลับกัน ถาแทงแนวนอนตัวบนยาวกวาแทงตัวลาง แสดงวางาน
ใชเวลาในการทํานอยกวาทีก่ ําหนดในแผน สวนแทงลายแนวนอนคือ ชวงเวลาที่
วางแผนไวของงานสรุป (summary tasks) สวนแทงสีดําทีม่ าเชื่อมตอแทงลาย
แนวนอนจะแสดงความกาวหนาของงานสรุป เชน งานหลักที่ 2 แสดงถึงชวงเวลา
จริงที่ใชในการทํางานมากกวาที่วางแผนไว
• สัญญลักษณรูปเพชรสีขาวใชแทนหลักไมลที่ลื่นไถล (slipped milestone) ซึ่ง
หมายถึงกิจกรรมหลักไมลทาํ เสร็จชากวาที่วางแผนไวตั้งแตแรก เชน งานสุดทาย
เปนตัวอยางของหลักไมลทลี่ ื่นไถล เพราะรายงานสุดทายและการนําเสนอทําเสร็จ
สมบูรณชากวาทีว่ างแผน

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารเวลาโครงการ หนา 5-13

• รอยละที่อยูท างขวามือของแทงแนวนอนที่แสดงถึงรอยละของงานที่ทาํ เสร็จของแต

ละงาน เชน รอยละ 100 หมายความวางานเสร็จ รอยละ 50 หมายถึงงานอยู
ระหวางดําเนินการ และเสร็จแลวรอยละ 50

ขอดีของการใชแผนภูมิคือ มีรูปแบบมาตรฐานสําหรับการแสดงขอมูลตารางการทํางาน
ที่แทจริง และที่วางแผน นอกจากนี้มนั ยังงายแกความเขาใจ และในการสราง แตแผนภูมิมีขอเสียหลักคือ
มันไมไดแสดงความสัมพันธหรือความพึ่งพิงระหวางงาน ถาแผนภูมิถูกสรางโดยซอฟตแวรการบริหาร
โครงการ และงานตางๆ ถูกเชื่อมโยงกัน แลวแผนภูมจิ ะแสดงความพึ่งพิงระหวางงาน แตจะไมชัดเจน
เหมือนกับที่แสดงในผังเครือขาย

5.6.2 วิธีเสนทางวิกฤต
วิธีเสนทางวิกฤต (CPM) หรือการวิเคราะหเสนทางวิกฤตใชเทคนิคการทําผังเครือขาย
เพื่อใชในการคาดการณชวงระยะเวลาทัง้ หมดของโครงการ เสนทางวิกฤตของโครงการคือ ชุดของ
กิจกรรมทีก่ ําหนดเวลาที่เร็วที่สุดที่โครงการสามารถทําไดเสร็จสมบูรณ ซึ่งเปนเสนทางที่ยาวที่สุดในผัง
เครือขาย และกิจกรรมเหลานี้ไมสามารถลาชาได ถากิจกรรมบนเสนทางวิกฤตลาชาจะทําใหวนั สิ้นสุด
โครงการตองเลื่อนไป

5.6.2.1 การสรางผังเครือขาย
ดังที่กลาวมาแลววา ผังเครือขายมี 2 แบบคือ ผังเครือขายแบบแสดง
กิจกรรมบนโหนด (AON) และ แบบแสดงกิจกรรมบนเสนลูกศร (AOA) สําหรับเอกสารชุดนี้จะอธิบาย
วิธีการสรางผังเครือขายแบบ AON เนื่องจากซอฟตแวรที่สําคัญหลายตัวใชวิธีการนี้
การเขียนผังเครือขายโครงการจะเริ่มตนดวยโหนดเริ่มตน (start node)
จากนั้นจึงวาดโหนดอืน่ ตามมาโดยพิจารณาลําดับการตอเนื่องของกิจกรรมดวย เชน จากตารางที่ 5.1 มี
กิจกรรม A และ B ที่ไมมีกิจกรรมกอนหนา ดังนัน้ เราจึงวาดโหนด A และ B แยกจากกันจากโหนดเริ่มตน
ซึ่งเปนกิจกรรมกอนหนากิจกรรมทั้งสอง เราเรียกกิจกรรมเริ่มตนวากิจกรรมดัมมี่ (dummy activity)
กิจกรรมนี้เปนกิจกรรมที่ไมมจี ริงและไมมีเวลาในการดําเนินการ รวมทัง้ ไมมีการใชทรัพยากรใดๆ จากนั้น
เราจะลากเสนความสัมพันธกอนหลัง (precedence relationships) ซึ่งเปนเสนลูกศร ระหวางกิจกรรม
เริ่มตนกับกิจกรรม A และ กิจกรรม B เสนลูกศรเปนเสนที่แสดงวากิจกรรมเริ่มตนเปนกิจกรรมเกิดกอน
กิจกรรม A และ B

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารเวลาโครงการ หนา 5-14

ตารางที่ 5.1 กิจกรรมและกิจกรรมสุดทายกอนหนา (predecessors)

(Heizer and Render, 2004)
กิจกรรม กิจกรรมสุดทายกอนหนา ชวงระยะเวลา (อาทิตย)
A - 2
B - 3
C A 2
D A, B 4
E C 4
F C 3
G D, E 5
H F, G 2

จากนั้นเราจึงวาดโหนดสําหรับกิจกรรม C แตกิจกรรม C เปนกิจกรรมที่

เกิดขึ้นหลังจากกิจกรรม A เราจึงวาดเสนลูกศรจากกิจกรรม A ไปยังกิจกรรม C เชนเดียวกัน เราวาด
โหนดสําหรับกิจกรรม D แตมีกิจกรรม A และ B เปนกิจกรรมที่มากอน ดังนัน้ เราวาดเสนลูกศรจาก A ไป
D และจาก B ไป D ดังแสดงในรูปที่ 5.8 และเมือ่ เราทําแบบเดียวกับกิจกรรมที่เหลือ เราจะไดผัง
เครือขายโครงการที่สมบูรณดังรูปที่ 5.9

กิจกรรม A มากอน กิจกรรม C

A C

เริ่มตน

B D

กิจกรรม A และ B มากอนกิจกรรม D

รูปที่ 5.8 ตัวอยางสวนหนึง่ ของการวาดผังเครือขายโครงการแบบ AON

(Heizer and Render, 2004)

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารเวลาโครงการ หนา 5-15

รูปที่ 5.9 ตัวอยางผังเครือขายโครงการที่สมบูรณ

(Heizer and Render, 2004)

เมื่อเราไดวาดผังเครือขายโครงการเสร็จแลว ขั้นตอนตอไปเราจะ
กําหนดเวลาเริม่ ตนและเวลาสิ้นสุดของแตละกิจกรรม จากตารางที่ 5.1 เราสามารถรูว าเวลาในการ
ดําเนินโครงการทั้งหมดคือ 25 อาทิตย แตหลายๆ กิจกรรมสามารถทําไปพรอมๆ กันได ดังนัน้ เวลาทั้ง
โครงการอาจนอยกวา 25 อาทิตยได เพื่อใหรูวา โครงการตองใชเวลาเทาไร เราจะตองทําการวิเคราะห
เสนทางวิกฤตของผังเครือขาย

5.6.2.2 การหาเสนทางวิกฤต
เสนทางวิกฤตคือ เสนทางทีย่ าวที่สุดของผังเครือขาย เพือ่ หาเสนวิกฤต เรา
จะตองคํานวณคาเวลาเริ่มและเวลาสิน้ สุดของแตละกิจกรรม เวลาทีต่ องคํานวณหามีดังนี้

เวลาเริ่มตนเร็วที่สุด (Earliest start (ES)) คือ เวลาเร็วที่สุดที่กจิ กรรมหนึง่

สามารถเริ่มตนทําได โดยสมมติวากิจกรรมกอนหนาทัง้ หมดไดทําเสร็จแลว
เวลาเสร็จเร็วที่สุด (Earliest finish (EF)) คือ เวลาที่เร็วที่สุดที่กจิ กรรมหนึง่
สามารถทําเสร็จได
เวลาเริ่มตนลาชาที่สุด (Latest start (LS)) คือ เวลาที่ชาที่สุดทีก่ ิจกรรม
หนึง่ สามารถเริ่มตนทําได โดยไมมีผลทําใหเกิดความลาชาแกโครงการ
เวลาเสร็จชาทีส่ ุด (Latest finish (LF)) คือ เวลาที่ชาที่สุดที่กจิ กรรมหนึง่
สามารถทําเสร็จได โดยไมมีผลทําใหเกิดความลาชาแกโครงการ

การจะคํานวณหาเวลาทั้ง 4 คาดังกลาวขางตน เราจะใชวิธีการ 2 วิธีคือ

เสนทางไปขางหนา และเสนทางยอนกลับ (forward and backward passes) วิธีการแรกจะนํามาใชใน

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารเวลาโครงการ หนา 5-16

การหา ES และ EF สวนวิธีการหลังใชสาํ หรับหา LS และ LF รูปที่ 5.10 แสดงสัญญลักษณของเวลาทัง้

4 คาในโหนด

รูปที่ 5.10 สัญญลักษณทใี่ ชในโหนด (Heizer and Render, 2004)

เสนทางไปขางหนา (forward pass) เปนการกําหนดตารางเวลาตาม

เสนทางไปขางหนา เพื่อหา ES และ EF รวมทัง้ เวลาที่ตองใชในการดําเนินโครงการ การสรางเสนทางไป
ขางหนามีกฏดังนี้
สําหรับกรณี ES มีกฏวา กอนทีก่ ิจกรรมจะสามารถเริ่มได ทุกกิจกรรมที่มา
กอนหนาที่ติดกับกิจกรรมทีต่ องการหา ES ตองทําเสร็จ กิจกรรมเริ่มตนมีคา ES และ EF เปน 0 ถา
กิจกรรมมีเพียงกิจกรรมเดียวที่มากอน คา ES ของกิจกรรมมีคาเทากับ EF ของกิจกรรมที่มากอน ถา
กิจกรรมนัน้ มีหลายกิจกรรมที่มากอน คา ES ของกิจกรรมคือ คาสูงสุดของคา EF ของกิจกรรมที่มากอน
กิจกรรมทีก่ ําลังพิจารณาทุกกิจกรรม
สวน EF ของกิจกรรมคือ ผลรวมของเวลาของ ES ของกิจกรรม และเวลา
การทํางานของกิจกรรม ดังนั้น
EF = ES + ระยะเวลาของกิจกรรม (duration)

จากรูปที่ 5.11 จะเห็นไดวา กิจกรรม Start ไมมีกิจกรรมใดที่มากอน ดังนั้น

เราจึงกําหนดให ES ของกิจกรรม Start เปน 0 EF ของกิจกรรม Start มีคาเปน 0 เชนกัน ตอไปเรา
พิจารณากิจกรรม A และ B กิจกรรมทั้งคูม ีกิจกรรม Start เทานัน้ ที่มากอน เมื่อใชกฎของเวลาเริ่มตนเร็ว
ที่สุด ES ของทั้งกิจกรรม A และ B จึงมีคาเทากับคา EF ของกิจกรรม Start ซึ่งมีคาเปน 0 สวนคา EF
ของกิจกรรม A มีคาเทากับ ES ของกิจกรรม A บวกกับระยะเวลาการทํางานของกิจกรรม A (0+2)
ผลลัพธคือ 2 สวนคา EF ของกิจกรรม B มีคาเทากับ 3

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารเวลาโครงการ หนา 5-17

EF of A = ES of ES of C = F
A +2 EF of A 4 7
ES of A C
A 3
0 2 2 4
E
2 2 4 8
H
4 13 15
Start
0 0 Activity
Name =Max(2,3) 2
0 D
ES EF 3 7 G
8 13
B
0 3 4
5
3 Activity ES= Max(EF of D, EF of E)
Duration = Max(8,7) = 8

รูปที่ 5.11 ตัวอยางเสนทางไปขางหนาของโครงการในตารางที่ 5.1 (Heizer and Render, 2004)

กิจกรรม C เปนกิจกรรมทีต่ ามหลังกิจกรรม A คา ES ของกิจกรรม C จึง

เทากับคา EF ของกิจกรรม B (2) และคา EF ของกิจกรรม C เทากับ 4 (2+2)
แตกิจกรรม D เปนกิจกรรมที่ตามหลังกิจกรรม A และ B เพราะฉะนัน้
กิจกรรม D จะเริ่มตนไดเร็วที่สุด ตองหลังจากที่กจิ กรรม B ดําเนินการเสร็จแลว ดังนัน้ คา ES ของ
กิจกรรม D คือคาที่สูงที่สุดของคา EF ของกิจกรรมที่มากอนกิจกรรม D คา ES ของกิจกรรม D จึงมีคา
เปน 3 และคา EF ของกิจกรรม D เทากับ 7 (3+4)
สวนกิจกรรม E และ F มีคา ES เทากันคือ 4 (เทากับ EF ของกิจกรรม C)
แต EF ของกิจกรรม E เทากับ 8 (4+4) ขณะที่ EF ของกิจกรรม F เทากับ 7 (4+3)
กิจกรรม G มีทั้งกิจกรรม D และ E ที่มากอน โดยการใชกฎการหาเวลาที่
เริ่มตนเร็วที่สดุ เราจะไดคา ES ของกิจกรรม G โดยพิจารณาจากคาสูงสุดระหวางคา EF ของกิจกรรม D
และกิจกรรม E ซึ่งคือ 8 และคา EF ของกิจกรรม G เทากับ 13 (8+5)
กิจกรรมสุดทายคือ กิจกรรม H ซึ่งมีกิจกรรม G และ F ที่ตองทําใหเสร็จ
กอน ดังนัน้ คา ES ของกิจกรรม H จึงมีคา 13 และคา EF เทากับ 15 (13+2)

เสนทางยอนกลับ (Backward pass) ในการกําหนดตารางเวลาตาม

เสนทางยอนกลับจะทําใหเราสามารถหาเวลาเริ่มตนชาที่สุด (LS) และเวลาที่เสร็จชาที่สุด (LF) ของ
กิจกรรม รวมทั้งเวลายืดหยุน (slack) การสรางเสนทางยอนกลับจะเริม่ จากกิจกรรมสุดทายของผัง

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารเวลาโครงการ หนา 5-18

เครือขายโครงการ โดยกําหนดคา LF กอน หลังจากนั้นจึงกําหนด LS กฏสําหรับการหาคาเวลาทัง้ สองมี

ดังนี้
กฏสําหรับการหาเวลา LF คือ LF ของกิจกรรมสุดทายเทากับ EF แตถา
กิจกรรมนัน้ มีกิจกรรมที่ตามมาเพียงกิจกรรมเดียว คา LF ของกิจกรรมนั้นเทากับคา LS ของกิจกรรมที่
ตามมา แตถากิจกรรมนัน้ มีกิจกรรมที่ตามมามากกวาหนึง่ กิจกรรม คา LF ของกิจกรรมนั้นคือ คา LS ที่
นอยที่สุดของกิจกรรมที่ตามมาทั้งหมด
สวนกฏการกําหนดคา LS คือ ความแตกตางระหวางเวลาที่เสร็จชาที่สดุ
กับเวลาการทํางานของกิจกรรมนั้น ดังนัน้
LS = LF –ระยะเวลาของกิจกรรม

ผลการเดินถอยหลัง จะได LF และ LS ดังรูปที่ 5.12

F
ES EF 4 7
A
0 2 C 10 13
2 4 3
LS 0 2
2 2 4 LF = Min(LS of E, LS of F)
2
= Min(4,10) = 4
LF = Min(2,4)
0 Start 0 H
=2 E 13 15
4 8
0 0 13 15
0 Activity 4 8 2
Name 4
B D G LS = EF of
0 3 3 7 8 13 project
1 4 4 8 8 13
3 4 5
Activity LS = LF- 4
Duration

รูปที่ 5.12 ตัวอยางเสนทางยอนกลับของโครงการในตารางที่ 5.1 (Heizer and Render, 2004)

จากรูปที่ 5.12 การหา LS และ LF จะเริ่มจากกิจกรรมสุดทาย โดยใหคา

LF ของกิจกรรมสุดทายเทากับ EF ของกิจกรรมสุดทาย ดังนั้น LF ของกิจกรรม H จึงเทากับ 15 โดยใช
กฎการหา LS เราจะได LS ของกิจกรรม H คือ ผลตางระหวางคา LF กับระยะเวลาการทํากิจกรรม ซึ่งมี
คาเทากับ 13 (15-2)

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารเวลาโครงการ หนา 5-19

แตเนื่องจากกิจกรรม H ทําตามหลังกิจกรรม G และ F ซึ่งการเริ่มกิจกรรม

H ทําไดก็ตอเมื่อกิจกรรมทัง้ สองตองแลวเสร็จ ดังนัน้ LF ของกิจกรรม G และ F เทากับ LS ของกิจกรรม
H ซึ่งเทากับ 13 สวน LS ของกิจกรรม G เทากับ 8 (13 – 5) และ LS ของกิจกรรม F เทากับ 10 (13 – 3)
ในทํานองเดียวกัน เราสามารถหาคา LF ของกิจกรรม E ไดเทากับ 8
(เทากับ LS ของกิจกรรม G) และ LS ของกิจกรรม E ไดเทากับ 4 (8-4) เชนเดียวกัน คา LF ของกิจกรรม
D เทากับ 8 (เทากับ LS ของกิจกรรม G) และ LS ของกิจกรรม D ไดเทากับ 4 (8-4)
สวนกิจกรรม C เปนกิจกรรมที่มากอนกิจกรรม E และ F โดยกฎของเวลา
เสร็จที่ชาที่สุด เราจะหา LF ของกิจกรรม C ได 4 ซึ่งพิจารณาจากคาทีน่ อยที่สุดระหวางคา LS ของ E
และ F (4, 10) จากนัน้ เราจะหาคา LS ของกิจกรรม C ไดเทากับ 2 (4 – 2)
ตอไปเราคํานวณหาคา LF และ LS ของกิจกรรม B ไดเทากับ 4 (เทากับ
LS ของกิจกรรม D ) และ 1 (4 – 3) ตามลําดับ
สวนคา LF ของกิจกรรม A คํานวณไดเชนเดียวกับการหาคา LF ของ
กิจกรรม C โดยจะไดคา LF เทากับ 2 (คาที่นอยที่สุดระหวาง 2 และ 4) และคา LS จะได 0
จากนั้นเราตองคํานวณหาเวลายืดหยุน เพื่อกําหนดเสนทางวิกฤต เวลา
ยืดหยุน (slack time) คือ วลาเผื่อเหลือเผือ่ ขาดที่กิจกรรมสามารถลาชา โดยไมทาํ ใหโครงการเกิดความ
ลาชาตามไปดวย
เวลายืดหยุน = LS – ES หรือ เวลายืดหยุน = LF – EF

ตารางที่ 5.2 เวลายืดหยุน ของโครงการ (Heizer and Render, 2004)

กิจกรรม ES EF LS LF เวลายืดหยุน อยูบนเสนวิกฤต
LS-ES หรือไม
A 0 2 0 2 0 Y
B 0 3 1 4 1 N
C 2 4 2 4 0 Y
D 3 7 4 8 1 N
E 4 8 4 8 0 Y
F 4 7 10 13 6 N
G 8 13 8 13 0 Y
H 13 15 13 15 0 Y

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารเวลาโครงการ หนา 5-20

กิจกรรมที่มีคา เวลายืดหยุนเปนศูนย เรียกวากิจกรรมวิกฤต และเปน

กิจกรรมที่อยูบ นเสนทางวิกฤต เสนทางวิกฤตเปนเสนทีเ่ ริ่มจากกิจกรรมเริ่มตนและจบที่กิจกรรมสุดทาย
ของโครงการ และมีเฉพาะกิจกรรมวิกฤตเทานั้น ตารางที่ 5.2 แสดงเวลายืดหยุน ของโครงการ และรูปที่
5.13 แสดงเสนทางวิกฤตของโครงการในตารางที่ 5.1 ซึ่งคือ เสน Start-A-C-E-G-H โดยมีเวลาเทากับ
2+2+4+5+2 =15

A C F
0 2 2 4 4 7
0 2 2 4 10 13
2 2 3
E H
Start Slack=0 Slack=0 4 8 Slack=6
0 0 13 15
4 8 13 15
0 0 4
0 2
B D Slack=0 G
0 3 3 7 8 13
1 4 4 8 8 13
3 4 5
Slack=1 Slack=1 Slack=0
รูปที่ 5.13 แสดงเสนทางวิกฤต (Heizer and Render, 2004)

เสนทางวิกฤตแสดงเวลาที่สนั้ ที่สุดที่โครงการสามารถทํางานไดเสร็จ
สมบูรณ ถึงแมวาเสนทางวิกฤตคือ เสนทางทีย่ าวที่สดุ แตเปนเวลาทีน่ อยที่สุดทีใ่ ชเพื่อทําใหโครงการ
เสร็จสมบูรณ ถามีหนึง่ หรือมากกวาหนึ่งกิจกรรมบนเสนทางวิกฤตใชเวลาที่มากกวาทีว่ างแผน
ตารางเวลาทั้งโครงการจะลืน่ ไถล นอกเสียจากวาผูจัดการโครงการจะทําการแกไขความลาชา
ประเด็นหนึ่งของการวิเคราะหเสนทางวิกฤตที่อาจทําใหเกิดความสับสน
คือ เสนทางวิกฤตสามารถมีไดมากกวา 1 เสนหรือไม เสนทางวิกฤตมีการเปลี่ยนหรือไม เสนทางวิกฤต
สามารถมีไดมากกวา 1 เสนทาง ผูจัดการโครงการควรติดตามการทํางานของกิจกรรมบนเสนทางวิกฤต
อยางใกลชิด เพื่อหลีกเลี่ยงความลาชาของโครงการ ถาโครงการมีเสนทางวิกฤตมากกวา 1 เสนทาง
ผูจัดการโครงการตองจับตาดูทุกเสนทาง
เสนทางวิกฤตของโครงการสามารถเปลี่ยนไดขณะที่โครงการเดินหนา เชน
สมมติวา กิจกรรม A C D G และ H ทั้งหมดเริ่มตนและสิ้นสุดตามแผนที่วางไว และสมมติวา กิจกรรม D
ใชเวลามากกวา 4 วัน เปน 6 วัน มันทําใหเสนทาง B-D-G-H ยาวกวาเสนทางอืน่ และกลายเปนเสนทาง
วิกฤตใหมอีกเสน ดังนัน้ เสนทางวิกฤตสามารถเปลี่ยนได

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารเวลาโครงการ หนา 5-21

5.6.2.3 การวิเคราะหเสนทางวิกฤตเพือ่ แลกกับเวลาของโครงการ

ถาผูจัดการโครงการรูวา งานหนึง่ บนเสนทางวิกฤตชากวาเวลาทีก่ ําหนดใน
ตารางเวลา ผูจัดการโครงการจําเปนตองตัดสินใจที่จะทําอะไรกับงานที่ลา ชา โดยพิจารณาวา
ตารางเวลาสามารถตอรองใหมกับผูม ีสวนไดเสียของโครงการหรือไม มีทรัพยากรพอที่จะจัดสรรเพิ่ม
ใหกับงานหรือไม จะเปนไปไดหรือไมที่โครงการจะเสร็จชากวาทีก่ ําหนด
เทคนิคที่สามารถชวยผูจัดการโครงการใหสามารถลดระยะเวลาของ
เสนทางวิกฤตใหสั้นลง เราเรียกวาการเรงรัดเวลา (crashing) เนื่องจากวิธีเสนทางวิกฤตมีการใชเวลา 2
ชุดคือ เวลาปกติ หรือ เวลามาตรฐาน (normal or standard time) เพื่อใชในการคํานวณหาเวลาเริ่มตน
และเวลาสิน้ สุดของกิจกรรม ดังนัน้ คาใชจา ยของกิจกรรมจึงเปนตนทุนปกติ (normal cost) เวลาอีกชุด
หนึง่ คือ เวลาที่สั้นที่สุดที่ใชในการทํากิจกรรมนั้นใหเสร็จ เราเรียกวา เวลาเรงรัด (crash time) คาใชจาย
ของเวลาเรงรัดจึงเรียกตนทุนเรงรัด (crash cost) ดังนัน้ โดยปกติตนทุนเวลาเรงรัดที่ใชในการทํา
กิจกรรมใหเสร็จจึงสูงกวาตนทุนปกติ
ขั้นตอนในการลดระยะเวลาโครงการ มีดงั นี้

ขั้นตอนที่ 1 คํานวณ ตนทุนเรงรัดเวลาตอ 1 ชวงเวลา ของแตละกิจกรรม

ในผังเครือขาย เชน 1 อาทิตย ถาตนทุนเรงรัดเวลาเปนเสนตรงตามเวลา สูตรที่ใชคอื
ตนทุนเรงรัดเวลาตอ 1 ชวงเวลา = (ตนทุนเรงรัดเวลา–ตนทุนปกติ) / (เวลา
ปกติ– เวลาเรงรัด)
ขั้นตอนที่ 2 หาเสนทางวิกฤตในผังเครือขายโครงการ แลวระบุกจิ กรรม
วิกฤต
ขั้นตอนที่ 3 ถามีเสนทางวิกฤตเพียง 1 เสน ใหเลือกกิจกรรมบนเสนทาง
วิกฤตที่ (ก) สามารถทําใหสนั้ ลง และ (ข) ตนทุนเรงรัดเวลาตอ 1 ชวงเวลามีคานอยที่สุด ใหเรงรัดเวลา
ของกิจกรรมนี้ 1 ชวงเวลา ถามีเสนทางวิกฤตมากกวา 1 เสนทาง ใหเลือกกิจกรรมที่ตองการเรงรัดเวลา
จากเสนทางวิกฤตแตละเสนที่มีคุณลักษณะดังนี้ (ก) กิจกรรมที่ถกู เลือกยังสามารถทําใหเวลานอยลงได
และ (ข) ตนทุนเรงรัดเวลาทัง้ หมดตอ 1 ชวงเวลาของทุกกิจกรรมที่ถกู เลือกต่ําที่สุด ใหเรงรัดเวลาของแต
ละกิจกรรมครั้งละ 1 ชวงเวลา กิจกรรมหนึง่ อาจอยูบนเสนทางวิกฤตมากกวา 1 เสนทาง
ขั้นตอนที่ 4 ปรับปรุงเวลาของทุกกิจกรรม ถาไดเวลาที่ตอ งการ ใหหยุด แต
ถายังไมได ใหกลับไปทําขัน้ ตอนที่ 2

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารเวลาโครงการ หนา 5-22

ตารางที่ 5.3 ขอมูลเวลา-ตนทุนปกติและการเรงรัด (Heizer and Render, 2004)

เวลา (อาทิตย) ตนทุน (บาท) อยูบนเสน
ตนทุนเรงรัดเวลา
วิกฤต
ปกติ เรงรัด ปกติ เรงรัด ตอ 1 ชวงเวลา
หรือไม
A 2 1 22,000 22,750 750 Y
B 3 1 30,000 34,000 2,000 N
C 2 1 26,000 27,000 1,000 Y
D 4 3 48,000 49,000 1,000 N
E 4 2 56,000 58,000 1,000 Y
F 3 2 30,000 30,500 500 N
G 5 2 80,000 84,500 1,500 Y
H 2 1 16,000 19,000 3,000 Y

ตัวอยางการลดระยะเวลาโครงการและการคํานวณคาใชจายในการเรงเวลา
จากตัวอยางโครงการในตารางที่ 5.1 ที่มรี ะยะเวลาในการดําเนินโครงการ
ทั้งหมด 15 อาทิตย สมมติวาผูบริหารใหเวลาเพียง 13 อาทิตย และตารางที่ 5.3 แสดงเวลาปกติ และ
เวลาเรงรัดในการทํางานแตละกิจกรรม และตนทุนปกติ พรอมตนทุนเรงรัดเวลา
กิจกรรม B มีเวลาปกติ 3 อาทิตย และเวลาเรงรัดคือ 1 อาทิตย ซึ่ง
หมายความวากิจกรรม B สามารถทําเสร็จภายใน 1 อาทิตย ดังนั้น จึงลดเวลาไดถงึ 2 อาทิตย ตนทุนที่
เพิ่มขึ้นคือ 4,000 บาท (ความแตกตางระหวางตนทุนเรงรัดเวลากับตนทุนปกติ (34,000 – 30,000))
ดังนัน้ ตนทุนเรงรัดเวลาคือ อาทิตยละ 2,000 บาท
A C F
0 1 1 3 3 6
0 1 9 12
1 1 2 3 3
E H
Start Activity A was 3 7 12 14
0 0
crashed by 1 week 3 7 12 14
0 0 4
0 2
B D G
0 3 3 7 7 12
0 3 3 7 7 12
3 4 5
รูปที่ 5.14 เสนทางวิกฤตใหมหลังจากการรนเวลาการทํางานของกิจกรรม A 1 อาทิตย
(Heizer and Render, 2004)

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารเวลาโครงการ หนา 5-23

เสนทางวิกฤตขณะนี้คือ A-C-E-G-H กิจกรรมวิกฤตทีม่ ีตนทุนเรงรัดเวลาที่

นอยที่สุดคือ กิจกรรม A (750) ดังนั้นถาลดเวลาการทํางานของกิจกรรม A จะทําใหเวลาทัง้ โครงการลด
ไป 1 อาทิตย เหลือเปน 14 อาทิตย โดยมีตนทุนเพิม่ 750 บาท และกิจกรรม A ไมสามารถลดเวลาการ
ทํางานไดตอไปอีก
ถึงตอนนี้ เสนทาง A-C-E-G-H ยังคงเปนเสนทางวิกฤตที่มีเวลาทั้งหมด 14
อาทิตย แตมีเสนทางใหมที่เปนเสนทางวิกฤตอีกคือ B-D-G-H ที่มีระยะเวลา 14 อาทิตยเชนกันดังรูปที่
5.14 แตเรายังจําเปนตองลดเวลาการทํางานของกิจกรรมวิกฤตของเสนทางวิกฤตทั้งสองลงอีก เราตอง
เลือกกิจกรรมจากเสนวิกฤตเสนทางละกิจกรรม โดยยึดหลักการทีว่ า คาใชจายในการลดเวลาตองนอย
ที่สุด ดังนั้นกิจกรรมวิกฤตทีจ่ ะลดเวลาลงคือ กิจกรรม C และ D หรือ D และ E หรือ กิจกรรม G ซึ่ง
คาใชจายทั้งสองทางเลือกแรกคือ 2,000 บาท สวนคาใชจายของกิจกรรม G คือ 1,500 บาท จากการ
วิเคราะหดังกลาว ผูจัดการโครงการควรเลือกลดเวลาการทํางานของกิจกรรม A และ G เพราะตนทุน
นอยที่สุด คือ 750 + 1,500 = 2,250 บาท และเวลาของโครงการลดลงเหลือ 13 อาทิตยตามที่ตองการ

5.6.3 การจัดตารางเวลาโซวกิ ฤต (Critical Chain Scheduling)

ตารางเวลาโซวิกฤตเปนเทคนิคอีกเทคนิคหนึง่ ที่ใชในการจัดการกับตารางเวลาของ
โครงการใหเสร็จตามวันที่กาํ หนด โดยการประยุกตทฤษฎีขอจํากัด (Theory of Constraint) ทฤษฎี
ขอจํากัดเปนปรัชญาการบริหารทีพ่ ัฒนาโดย โกลดแรตต (Goldratt) ซึง่ ยึดหลักความจริงทีว่ า ระบบที่
ซับซอนใดๆ ณ จุดเวลาใดๆ จะมีขอจํากัดที่จํากัดความสามารถของระบบที่จะบรรลุเปาหมายของระบบ
เพื่อใหระบบไดรับการปรับปรุงใหดีขึ้นอยางชัดเจน ขอจํากัดตางๆ ควรระบุออกมา และระบบตองไดรับ
การบริหาร โดยมีขอจํากัดเหลานั้นอยูในใจ การจัดตารางเวลาโซวิกฤตแตกตางจากวิธีการแบบเสนทาง
วิกฤต วิธกี ารหลังไมไดตระหนักถึงการจัดสรรทรัพยากรที่หายากหรือขาดแคลน (scare resources) ผู
ประมาณการอาจจะสมมติวาทรัพยากรตางๆ ที่ตองการมีพรอมใหสาํ หรับกิจกรรมของโครงการ
การจัดตารางเวลาโซวิกฤตตระหนักถึงทรัพยากรที่จํากัด และรวมเวลาที่เปนตัวกันชน
(buffer) ทั้งหมดของแตละงานเขาไวดวยกัน เพื่อปองกันวันที่โครงการเสร็จสมบูรณไมใหลาชา
แนวความคิดที่สําคัญทีเ่ กี่ยวของกับการจัดตารางเวลาโซวิกฤตคือ การทํางานหลายงาน การประมาณ
การระยะเวลา (duration estimation) อาการแบบนักเรียน (student syndrome) กฎพารคินสัน
(Parkinson’s law) และกันชนเวลา (time buffers)
การทํางานหลายงาน เกิดขึ้นเมื่อทรัพยากรทํางานมากกวาหนึง่ งาน สถานการณนี้
เกิดขึ้นบอยๆ ในโครงการ พนักงานไดรับหมอบหมายใหทาํ งานหลายงานในโครงการเดียวกัน หรือตาง
โครงการ จากรูปที่ 5.15 สมมติวาพนักงานทํางานที่แตกตางกัน 3 งาน เรียก งานที่ 1 งานที่ 2 และ งาน
ที่ 3 ถาพนักงานไมทาํ งานหลายงานพรอมกัน แตทํางานใหเสร็จทีละงานเรียงลําดับ งานที่ 1 ทําเสร็จ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารเวลาโครงการ หนา 5-24

หลังจากเวลาผานไป 10 วัน งานที่ 2 ทําเสร็จหลังจากเวลาผานไป 20 วัน และงานที่ 3 ทําเสร็จหลังจาก

เวลาผานไป 30 วัน ดังนั้นจึงใชเวลาในการทํางาน 3 งาน เปนเวลา 30 วัน อยางไรก็ตาม เพราะหลายๆ
คนที่อยูในสถานการณเชนนี้พยายามทําใหเจาของงานทุกคนพอใจ พนักงานชอบเฉลี่ยเวลาในการ
ทํางานหลายๆ งาน โดยทํางานที่ 1 เปนชวงเวลาหนึง่ แลวจึงไปทํางานที่ 2 และงานที่ 3 หลังจากนัน้ จึง
กลับมาทํางานที่ 1 ใหม เปนดังนี้ไปเรื่อยๆ ดังรูปที่ 5.16 การทํางานแบบหลายงานตามตัวอยางจะพบวา
งานที่ 1 เสร็จหลังจากเวลาผานไป 20 วันแทนที่จะเปน 10 วัน งานที่ 2 เสร็จหลังจากเวลาผานไป 25 วัน
และงานที่ 3 ยังคงเสร็จวันที่ 30 การทํางานหลายงานพรอมกันสามารถทําใหงานลาชาไดเพราะตอง
เสียเวลาในการเริ่มตนงานใหมอีกครั้ง ซึ่งตองเสียเวลาในการทบทวนสิ่งที่ไดทํามากอนหนานี้ ดังนัน้
เวลาที่ตองใชในการทํางานจึงเพิม่ ขึ้น

รูปที่ 5.15 การทํางานทีละงาน (Schwalbe, 2007)

รูปที่ 5.16 การทํางานหลายงาน (Schwalbe, 2007)

การจัดตารางโซวิกฤตสมมติวาทรัพยากรไมทํางานหลายงาน หรืออยางนอยตองใหทาํ
หลายงานนอยที่สุด พนักงานไมควรถูกมอบหมายงาน 2 งานพรอมกัน ทฤษฎีโซวิกฤตเสนอวา ควรมี
การจัดลําดับความสําคัญของงาน ดังนั้นคนทีท่ ํางานมากกวา 1 งานในเวลาเดียวกันจะไดรูวา งานไหน
สําคัญ การปองกันการทํางานหลายงานพรอมกันเปนการหลีกเลี่ยงความขัดแยงทางทรัพยากร และเวลา
ที่เสียไปในการเริ่มตนงาน เมื่อมีการเปลีย่ นงาน
การประมาณการเวลาทํางาน แนวความคิดที่จาํ เปนเพื่อการปรับปรุงวันสิน้ สุด
โครงการดวยการจัดตารางเวลาโซวิกฤตคือ การเปลีย่ นวิธีทเี่ ราทําการประมาณการเวลาทํางาน หลายๆ
คนเพิ่มเวลาเผื่อเหลือเผื่อขาด (contingency) หรือเวลาที่ปลอดภัย (safety time) ซึ่งจะเปนชวง

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารเวลาโครงการ หนา 5-25

ประมาณ 50 – 90 % ของเวลาที่ไดประมาณการ เชน ถาประมาณการวา งานที่ 1 ทําเสร็จในเวลา 2 วัน

เพื่อความปลอดภัย ผูประมาณการจะเพิม่ เวลาการทํางานอีกประมาณ 50 – 90 % คือ 1 – 2 วัน ดังนัน้
งานที่ 1 จะถูกกําหนดใหใชเวลา 3 – 4 วัน
อาการแบบนักเรียน โกลดแรตตไดกลาววาพฤติกรรมการทํางานของคนมีลักษณะ
คลายกับพฤติกรรมของนักเรียนทีท่ ํางานสงครู นักเรียนสวนใหญจะไมรีบทํางานใหเสร็จกอน แตจะคอย
ใหใกลเวลาสงงานจึงจะเริ่มทํางานนัน้ ดังนัน้ ถาเราใหเวลามากเทาไร คนจะใชเวลาทั้งหมดเทาที่
กําหนดให ซึ่งเปนไปตามกฎพารคินสัน
กันชนเวลา การจัดตารางเวลาโซวิกฤตจะขจัดเวลาที่เผื่อไวของแตละงานออก และ
สรางกันชนโครงการ (project buffer) ไวทายสุดของงานสุดทาย กอนถึงวันสิน้ สุดโครงการ การจัดตาราง
โซวิกฤตยังปกปองงานบนโซวิกฤตไมใหลา ชา โดยการใชกันชนการปอน (feeding buffers) ซึ่งเปนเวลา
เพิ่มตองานสุดทายของเสนทางที่ปอนเขาสูโ ซวิกฤต การประมาณการงานแบบการจัดตารางเวลาโซ
วิกฤตควรจะสัน้ กวาวิธีการดั้งเดิม เพราะแตละงานไมมีกนั ชนของมันเอง การไมมีกันชนงานหมายความ
วาการเกิดกฏพารคินสัน ควรนอยลง

5.6.3.1 ขั้นตอนการพัฒนาตารางเวลาโซวิกฤต
วิธีการจัดการตารางเวลาดวยโซวกิ ฤตเหมือนกับการจัดการตารางเวลา
ดวยวิธกี ารดั้งเดิมคือ มีการสรางผังเครือขาย กําหนดเสนทางวิกฤต และกําหนดทรัพยากรใหกับกิจกรรม
บนเสนทางวิกฤต หลังจากจุดนี้การจัดการตารางเวลาดวยโซวกิ ฤตมีวธิ กี ารมีขั้นตอนการดําเนินการดังนี้

• การสรางผังเครือขายตารางเวลาเริ่มเร็วที่สุด (earliest time)

รูปที่ 5.17 แสดงตารางเวลาการทํางานที่เริ่มเร็วที่สุดของโครงการที่มี
งาน 5 งาน ตารางเวลานี้สรางเหมือนตารางเวลาที่ใชวธิ ี CPM ระยะเวลาของโครงการคาดวาจะเสร็จใน
80 วัน ในรูปนีเ้ สนทางวิกฤตคือ A1.1 A1.2 และ A3

รูปที่ 5.17 ตารางเวลาที่เริ่มเร็วทีส่ ุด

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารเวลาโครงการ หนา 5-26

• การปรับเปลีย่ นจากตารางเวลาเริ่มเร็วที่สุดเปนตารางเวลาเริ่ม
ชาที่สุด (latest time) และการกําหนดทรัพยากร
ผูจัดการโครงการที่ใชการจัดการตารางเวลาโซวกิ ฤตจะปรับเปลี่ยน
ตารางเวลาจากรูปที่ 5.17 (ซึ่งเปนตารางเวลาสรางจากแนวความคิดทีว่ าเริ่มงานเร็วที่สุด) มาเปน
ตารางเวลาที่งานเริ่มชาที่สุด ดังรูปที่ 5.18 การปรับเปลี่ยนนี้ไดขจัดเวลาที่เผื่อของงานทุกงานออก โดย
ปกติจะหักออกประมาณรอยละ 50 (จากการศึกษาของโกลดแรตต) จากนัน้ ผูจัดการโครงการได
กําหนดใหสมาชิกของทีมงาน 4 คนรับผิดชอบการทํางาน

รูปที่ 5.18 ตารางเวลาที่เริ่มชาทีส่ ุดและการกําหนดทรัพยากร

• การแกปญหาความขัดแยงดานทรัพยากร
จากรูปที่ 15.18 พบวามีปญ หาความขัดแยงดานทรัพยากร เนื่องจาก
มีการมอบหมายใหเขียวทํางาน 2 งาน คือ A1.2 และ A2.2 ที่ตองทํางานพรอมกัน ตามหลักการของการ
จัดการตารางเวลาโซวิกฤตทีไ่ มใหพนักงานทํางานหลายงานในเวลาเดียวกัน ทางแกปญหามีได 2
วิธีการ ดังแสดงในรูปที่ 5.19 วิธีการแรกใหเขียวทํางาน A1.2 เสร็จกอนจึงเริ่มทํางาน A2.2 ดังนั้นเวลา
ของโครงการจะเพิ่มเปน 45 วัน สวนวิธกี ารที่ 2 กําหนดใหเขียวทํางาน A2.2 กอนแลวจึงทํางาน A1.2
ดวยวิธกี ารนี้ ระยะเวลาของโครงการเปน 40 วัน เราอาจคิดวาวิธีการที่ 2 นาจะดีกวาวิธกี ารแรก
เนื่องจากระยะเวลาของโครงการสัน้ กวา แตอยาลืมวา ณ ขณะนี้เรายังไมไดเพิ่มกันชนใดเขาไปใน
ตารางเวลา
• กําหนดเสนโซวิกฤต กันชนโครงการ และกันชนการปอน
หลักการของการจัดการตารางเวลาโซวิกฤตคือ การปกปองทรัพยากร
อันจํากัดและวันสิน้ สุดโครงการ โดยการใชกันชน (buffer) กันชนที่สาํ คัญมี 2 ประเภทคือ กันชน
โครงการ และ กันชนการปอน ขนาดของกันชนทัง้ สองนี้ โกลดแรตตไดเสนอแนะวาควรเปนครึ่งหนึง่ ของ
ระยะเวลาของงานที่อยูบนเสนทางที่ตองอยูกอนจุดที่ตองใสกันชน โดยไมรวมชองวาง กอนกําหนดกัน

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารเวลาโครงการ หนา 5-27

ชนทัง้ 2 ประเภท เราตองหาเสนโซวิกฤตกอน เสนโซวิกฤตเปนเสนทางที่ยาวที่สุดในบรรดาเสนทาง

ทั้งหมดทีป่ รากฎในผังเครือขาย

รูปที่ 5.19 ความขัดแยงดานทรัพยากรจุดแรก

สําหรับทางเลือกแรกมีเสนทาง 2 เสนทางคือ A1.1-A1.2-A2.2-A3

และ A2.1-A2.2-A3 แตเสนทางแรกเปนเสนโซวิกฤตเนื่องจากเปนเสนทางที่ยาวที่สุด จากนั้นใหเพิ่มกัน
ชนการปอนขนาด 5 วัน (50% ของเวลาของกิจกรรม A2.1) ระหวางงาน A2.1 กับ A2.2 เนื่องจากงาน
A2.1 เปนงานที่ปอนเขาสูเสนทางวิกฤต สุดทายจึงเพิ่มกันชนโครงการขนาด 22 วัน (50% ของ
(15+10+5+15) ตอจากงาน A 3 ระยะเวลาของโครงการจึงเปน 67 วัน ดังแสดงในรูปที่ 5.20

รูปที่ 5.20 ตารางเวลาโซวิกฤตของทางเลือกแรก

สวนทางเลือกที่สอง มีเสนทาง 2 เสนคือ A1.1-A1.2-A3 และ A2.1-

A2.2-A1.2-A3 ทั้งคูเปนเสนโซวิกฤต เนื่องจากใชเวลา 40 วันเทากันทัง้ 2 เสน เราจึงสามารถหยิบ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารเวลาโครงการ หนา 5-28

เสนทางใดมาดําเนินการกําหนดกันชนการปอนและกันชนโครงการก็ได ทั้ง 2 เสนทางใหระยะเวลา

โครงการเทากันคือ 70 วัน ซึง่ มากกวาทางเลือกที่ 1 รูปที่ 5.21 แสดงผลลัพธของการดําเนินการดังกลาว

รูปที่ 5.21 ตารางเวลาโซวกิ ฤตของทางเลือกทีส่ อง

สําหรับเสนโซวิกฤตเสนแรกนั้น เราเพิ่มกันชนการปอนขนาด 8 วัน

(ประมาณ 50% ของผลรวมของงาน A2.1 และ A2.2) ระหวางงาน A2.2 กับ A1.2 เนื่องจาก งาน A2.2
เปนงานสุดทายของเสนทางที่ปอนเขาสูเสนโซวกิ ฤต จากนัน้ เราจึงเพิม่ กันชนโครงการขนาด 22 วัน ไว
หลังงานสุดทายของเสนโซวกิ ฤต สวนเสนโซวิกฤตเสนที่ 2 เราทําทํานองเดียวกันกับเสนแรก
ลีช (Leach) ไดเสนอวิธีการคํานวณขนาดกันชนโครงการและกันชน
การปอนใหคิดจากรากที่สองของผลรวมของความแตกตางระหวางเวลาที่ใชทํางานเดิมกับเวลาทีล่ ดลง
ยกกําลังสอง สมมุติวา เสนทางวิกฤตมี 4 งาน แตละงานใชเวลา 2 อาทิตย ดังนั้นเสนทางนี้ใชเวลา
ทั้งหมด 8 อาทิตย แตถาเราขจัดเวลาที่เผื่อของแตละงานออก เวลาทั้งหมดจึงเปน 4 อาทิตย (ลดลง 50
%) ผลตางระหวางเวลาเดิมกับเวลาที่ลดลงของแตละงานยกกําลังสองคือ 12 เมื่อรวมทุกงานจะไดผล
รวมเปน 4 และรากที่สองของ 4 คือ 2 ดังนัน้ ขนาดกันชนจึงเปน 2 อาทิตย

5.6.4 เทคนิคการทบทวนและการประเมินผลการทํางาน: เทคนิค PERT

PERT เปนเทคนิการบริหารเวลาโครงการอีกเทคนิคหนึ่ง ที่ใชประมาณการระยะเวลา
โครงการ เมื่อมีความไมแนนอนเกี่ยวกับการประมาณชวงระยะเวลาการทํางานแตละกิจกรรมสูง โดยเริ่ม
จากการจัดทําโครงสรางจําแนกงานออกเปนงานหรือกิจกรรมตางๆ งานสุดทายกอนหนา ระยะเวลาที่
คาดในการดําเนินงานแตละงาน จากนัน้ นําขอมูลมาจัดทําผังเครือขายงาน โดยอาศัยเทคนิคแบบ AON

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารเวลาโครงการ หนา 5-29

หรือแบบ AOA ก็ได แตการคาดคะเนระยะเวลาในการดําเนินงานแตละงาน ใชการประมาณการเวลาที่

นาจะเปนไปได (probabilistic time estimate) ที่ประกอบดวยคา 3 คา ดังที่ไดกลาวในหัวขอที่ 5.5
• ระยะเวลาที่คาดคะเนในแงดี (optimistic) กําหนดใหแทนดวย a
• ระยะเวลาที่คาดคะเนวาจะเกิดขึ้นไดมากที่สุด (most likely) กําหนดให
แทนดวย b
• ระยะเวลาที่คาดคะเนในแงราย (pessimistic) กําหนดใหแทนดวย c

ดังนัน้ ระยะเวลาของแตละกิจกรรมที่ไดจากการคาดคะเนเราเรียกวาระยะเวลา
คาดหวังทีก่ ิจกรรมจะแลวเสร็จ (expected duration: te) หรือคาเฉลี่ยแบบถวงน้ําหนัก (weighted
average) โดยมีสูตรดังนี้
a+4b+c
te =
6

เราสามารถวัดความแปรปรวนที่ระยะเวลาของกิจกรรมอาจแตกตางไปจากระยะเวลา
คาดหวังที่คาํ นวณไดจากสูตร สูตรคํานวณหาความแปรปรวนคือ
2
⎛c-a⎞
ความแปรปรวน (variance) v= ⎜ ⎟
⎝ 6 ⎠

ถาคาความแปรปรวนสูงแสดงวาระยะเวลาที่เกิดขึ้นจริงอาจแตกตางไปจากระยะเวลา
คาดหวังคอนขางมาก ซึง่ แสดงวากิจกรรมมีโอกาสแลวเสร็จหลังระยะเวลาคาดหวังไดมาก
ตารางที่ 5.4 เปนตัวอยางการคํานวณระยะเวลาคาดหวัง คาความแปรปรวน จาก
ขอมูลในตารางที่ 5.4 เราสามารถเขียนผังเครือขายได โดยใชหลักเดียวกับวิธีการเสนทางวิกฤต แต
เนื่องจากผลทีไ่ ดเปนคาเดียวกับคาในตารางที่ 5.1 ดังนั้นรูปผังเครือขายที่เขียนขึ้นดวยวิธี PERT จึง
เหมือนกับรูปที่ 5.13 และมีคาที่เกีย่ วของดังนี้

ระยะเวลาคาดหวังของโครงการ = 15 =ระยะเวลาของเสนทางวิกฤต
ความแปรปรวนของโครงการ = 0.11+0.11+1.00+1.78+0.11 = 3.11

จากขอมูลดังกลาว ผูจดั การโครงการสามารถหาความนาจะเปนทีโ่ ครงการจะเสร็จ

ภายในระยะเวลาตางๆ ได โดยอาศัยวิธีการทางสถิตคิ ํานวณหาคาตัวแปรสุมแบบปกติมาตรฐาน (Z
value) และตารางปกติมาตรฐาน คาความนาจะเปนหาไดดังนี้

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารเวลาโครงการ หนา 5-30

t s -t e
Z=
v te
โดยที่
Z คือ คาตัวแปรสุมแบบปกติมาตรฐาน
ts คือ ระยะเวลาที่โครงการแลวเสร็จตามเปาหมายที่กาํ หนด
te คือ ระยะเวลาที่คาดวาโครงการจะแลวเสร็จ
v t คือ ระยะเวลาแปรปรวนไปจากระยะเวลาที่คาดวาโครงการจะแลวเสร็จ
e

จากตัวอยางตารางที่ 5.4 ความนาจะเปนที่โครงการจะเสร็จภายใน 16 อาทิตยคือ

0.7157 แสดงวาโอกาสที่โครงการจะเสร็จคือ 71.57 %

16 -15
Z=
3.11
= 0.57

เมื่อนําคา Z ที่ไดไปเปดตารางปกติ (normal table) เราจะไดคาความนาจะเปนเทากับ

0.7157

ตารางที่ 5.4 ตัวอยางการคํานวณระยะเวลาคาดหวัง คาความแปรปรวน

(Heizer and Render, 2004)
ระยะเวลาคาดหวัง ความแปรปรวน
กิจกรรม ระยะเวลา (อาทิตย)
(อาทิตย) (อาทิตย)
a b c t = (a+4b+c)/6 ((c-a)/6)2
A 1 2 3 2.00 0.11
B 2 3 4 3.00 0.11
C 1 2 3 2.00 0.11
D 2 4 6 4.00 0.44
E 1 4 7 4.00 1.00
F 1 2 9 3.00 1.78
G 3 4 11 5.00 1.78
H 1 2 3 2.00 0.11

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารเวลาโครงการ หนา 5-31

5.7 การควบคุมตารางเวลา (Schedule Control)

การควบคุมตารางเวลาเปนกระบวนการสุดทายของการบริหารเวลา เปาหมายของการควบคุม
ตารางเวลาคือ เพื่อใหโครงการแลวเสร็จตามกําหนดเวลา ผูจัดการโครงการควรรูสถานภาพของ
ตารางเวลา ปจจัยสาเหตุการเปลี่ยนตารางเวลา และการบริหารการเปลี่ยนแปลงที่เกิดขึ้น
ขอมูลนําเขาหลักที่ใชในการควบคุมตารางเวลาคือ บรรทัดฐานตารางเวลา (schedule
baseline) รายงานประสิทธิภาพการทํางาน คํารองขอเปลี่ยนแปลงทีไ่ ดรับอนุมัติ และแผนการบริหาร
ตารางเวลา เครื่องมือและเทคนิคที่นาํ มาใชในขั้นตอนนีค้ ือ
• รายงานความกาวหนา
• ระบบควบคุมการเปลี่ยนแปลงตารางเวลา
• ซอฟตแวรการบริหารโครงการ
• ผังเปรียบเทียบตารางเวลา เชน แผนภูมิการติดตามผล
• การวิเคราะหความแปรปรวน
• การบริหารประสิทธิภาพ เชน มูลคาที่ไดรับ (earned value)

ผลลัพธของการควบคุมตารางเวลาคือ การวัดประสิทธิภาพการทํางาน การเปลีย่ นแปลงตามที่

ขอ คําแนะนําสิ่งที่ควรแกไข และการปรับปรุงบรรทัดฐานตารางเวลา รายการกิจกรรม คุณลักษณะ
กิจกรรม แผนการบริหารโครงการ และทรัพยสนิ ทางกระบวนการเชิงองคการ เชน รายงานบทเรียนที่ได
เรียนรูที่เกี่ยวของกับการควบคุมตารางเวลา
มีประเด็นหลายประเด็นเกี่ยวของกับการควบคุมการเปลีย่ นแปลงตารางเวลาโครงการ
ประเด็นที่สาํ คัญประเด็นแรกคือ ตองแนใจวาตารางโครงการสอดคลองกับความเปนจริง ประเด็นตอมา
คือ การใชระเบียบวินัย และความเปนผูน าํ เพื่อเนนความสําคัญของการทําตามตารางโครงการ ถึงแมวา
ผูจัดการมีเครื่องมือและเทคนิคหลากหลายชวยในการพัฒนาและบริหารโครงการ แตผูจัดการโครงการ
ตองจัดการกับประเด็นที่เกี่ยวของกับคนเพือ่ ใหโครงการยังคงเปนไปตามแผน นอกจากนี้ ผูจดั การ
โครงการควรตรวจสอบความจริงที่จะชวยใหผูจัดการโครงการบริหารการเปลี่ยนแปลงที่มีตอตาราง
โครงการ

5.7.1 การตรวจสอบความเปนจริงของการกําหนดตารางเวลา
การตรวจสอบความจริงนัน้ ประเด็นแรกที่ผูจัดการโครงการควรทําคือ ทบทวนราง
ตารางเวลาที่โดยปกติจะมีในเอกสารสิทธิโ์ ครงการ ถึงแมวารางนี้จะมีเฉพาะวันเริ่มตนและวันสิน้ สุด
โครงการ แตเอกสารสิทธิโ์ ครงการนี้ใหขอ มูลเริ่มตน ตอไปผูจัดการโครงการและทีมงานควรเตรียม

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารเวลาโครงการ หนา 5-32

ตารางเวลาโครงการที่ละเอียด และใหผูมสี วนไดเสียโครงการอนุมัติ เพื่อเปนการใหคํามั่นสัญญา พรอม

ทั้งการมีสวนรวมจากสมาชิกทีมงานทัง้ หมด ผูบริหารระดับสูง ลูกคาและผูมีสวนไดเสียคนอื่นๆ
การตรวจสอบเปนความจริงอีกประเด็นคือ การสอบทวนความกาวหนาของตารางเวลา
เพราะเพียงแคสมาชิกทีมงานบอกวางานเสร็จตามเวลา ไมไดหมายความวามันจะเปนเชนนัน้ ผูจ ัดการ
โครงการตองทบทวนงานจริงๆ และพัฒนาความสัมพันธที่ดีกับสมาชิกทีมงานเพื่อใหแนใจวา งานเสร็จ
ตามทีว่ างแผน หรือมีการรายงานการเปลี่ยนแปลงตามความตองการ
ผูบริหารไมชอบความแปลกใจ ดังนัน้ ผูจดั การโครงการตองสื่อสารสถานภาพโครงการ
ใหชัดเจนและซื่อสัตย เมื่อมีความขัดแยงที่รนุ แรงเกิดขึ้นที่อาจกระทบตอตารางเวลา ผูจัดการโครงการ
ตองแจงผูบริหารระดับสูงและทํางานรวมกันเพื่อแกปญหาความขัดแยง

5.7.2 การทํางานกับคน
การทํางานรวมกับคนหลายๆ คนนัน้ สิง่ ที่ยากลําบากไมใชประเด็นทางเทคนิคแตเปน
คน การสรางเครือขายที่ดีและตารางเวลาที่ละเอียดเปนทักษะที่สาํ คัญของผูจัดการโครงการ ผูจ ัดการ
โครงการควรมีสมาชิกคนหรือสองคนรับผิดชอบประสานงานเอาขอมูลจากคนตางๆ เพื่อสรางและ
ปรับปรุงตารางเวลา การกระจายรายละเอียดตารางเวลาใหสมาชิกดําเนินการ ทําใหผูจัดการโครงการ
สามารถเนนภาพรวมและนําพาโครงการได ทักษะความเปนผูนาํ หลายๆ อยางชวยผูจัดการโครงการ
ควบคุมการเปลี่ยนแปลงตารางเวลา ทักษะเหลานี้คือ ทักษะการใช
• อํานาจอยางเปนทางการ
• สิ่งจูงใจ
• ระเบียบวินัย
• การตอรอง

สิ่งสําคัญสําหรับผูจัดการโครงการคือ ใหอํานาจกับสมาชิกทีมงานใหรับผิดชอบตอ
กิจกรรมของตนเอง การใหสมาชิกทีมงานชวยสรางตารางที่ละเอียดและใหสารสนเทศทีท่ ันสมัยเปนการ
ใหอํานาจทีมงานรับผิดชอบตอการกระทําของตนเอง ผลลัพธที่ไดคือ สมาชิกทีมงานจะรูสึกผูกมัดตนเอง
กับโครงการ
ผูจัดการโครงการยังสามารถใชสิ่งจูงใจทางดานการเงิน หรือสิ่งจูงใจอื่นๆ เพื่อกระตุน
คนใหทํางานใหตรงกับเวลาที่คาดหมาย บางครั้งผูจัดการโครงการอาจใชอํานาจแบบบังคับ หรือสิ่งจูงใจ
เชิงลบเพื่อหยุดคนที่ไมทาํ ตามเวลาทีก่ ําหนด

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารเวลาโครงการ หนา 5-33

ผูจัดการโครงการยังตองใชระเบียบวินัยเพื่อควบคุมตารางเวลา ผูจัดการโครงการ
เทคโนโลยีสารสนเทศพบวา การกําหนดวันที่แนนอนสําหรับหลักไมลที่สําคัญ จะชวยลดการเปลี่ยน
ตารางเวลาใหนอยลง การยืนหยัดกับวันที่ตองเสร็จ และการวางแผนการวิเคราะหที่เหมาะสมแตแรกๆ
ชวยใหแตละคนเนนที่จะทําสิ่งที่สาํ คัญที่สดุ ตอโครงการ
ผูจัดการโครงการและสมาชิกทีมงานจําเปนตองฝกทักษะการตอรองทีด่ ี ลูกคาและ
ผูบริหารจะกดดันคนในทีมงานใหโครงการใชเวลานอยทีส่ ุด บางคนโทษวาตารางเวลาโครงการ
เทคโนโลยีสารสนเทศนานเกินกวาที่กําหนด เนื่องจากการประมาณการไมดี แตบางคนกลาววาปญหา
คือ ผูพัฒนาซอฟตแวร และคนอื่นๆ ที่มีอาชีพทางเทคโนโลยีสารสนเทศไมสามารถปกปองการประมาณ
การของพวกตน เมื่อฝายการตลาด ฝายขาย หรือผูบริหารระดับสูงบอกใหประมาณการเวลาโครงการให
สั้นลง ที่เปนเชนนี้ เนื่องจากคนทางดานเทคโนโลยีสารสนเทศสวนใหญมีอายุนอยกวาผูมีสวนไดเสียที่
ผลักดันใหเวลาของโครงการสั้นกวาเดิม จึงทําใหเขาเหลานัน้ ขาดความเหมาะสมที่จะตั้งคําถามตอ
ความคิดเห็นของผูอาวุโส มันจึงเปนสิ่งสําคัญที่ผจู ัดการโครงการและสมาชิกทีมงานที่จะปองกันการ
ประมาณการของตน และเรียนรูการตอรองกับความตองการของผูมีสว นไดเสียของโครงการ

5.8 สรุป
การบริหารเวลาโครงการเปนกระบวนการทีส่ ําคัญกระบวนการหนึง่ ในการบริหารโครงการ
เทคโนโลยีสารสนเทศ เนื่องจากโครงการเทคโนโลยีสารสนเทศสวนใหญดําเนินการเกินเวลาที่กาํ หนดไว
กระบวนการสําคัญที่เกีย่ วของกับการบริหารเวลาโครงการคือ การกําหนดกิจกรรม การเรียงลําดับ
กิจกรรม การประมาณการทรัพยากรของกิจกรรม การประมาณการระยะเวลาการทํางานของกิจกรรม
การพัฒนาตารางเวลาโครงการ และการควบคุมตารางเวลา
การกําหนดกิจกรรมประกอบดวยการกําหนดกิจกรรมเฉพาะที่ตองทําเพื่อผลิตสิ่งที่สง มอบของ
โครงการ สวนการกําหนดลําดับของกิจกรรมนั้น เปนการกําหนดความสัมพันธหรือความพึง่ พิงกัน
ระหวางกิจกรรม เหตุผลสําคัญ 3 ขอในการสรางความสัมพันธคือ 1) ความสัมพันธโดยธรรมชาติของ
งาน เรียกวาความพึ่งพิงที่ตอ งมี 2) ความสัมพันธทกี่ ําหนดโดยทีมงาน เรียกวาความพึ่งพิงแบบอิสระ 3)
และความสัมพันธระหวางกิจกรรมโครงการและกิจกรรมนอกโครงการ เรียกวาความพึง่ พิงภายนอก
กิจกรรมตางๆ ตองมีการเรียงลําดับเพื่อใชในการวิเคราะหเสนทางวิกฤต ผังเครือขายเปนเทคนิคที่คน
ชอบใชสําหรับการแสดงการเรียงลําดับกิจกรรม วิธีที่ใชในการสรางผังคือ PERT/CPM และ แผนภูมิ
แสดงการจัดลําดับกอนหลังของงาน หรือ AON ความสัมพันธระหวางกิจกรรมมี 4 ประเภทคือ สิน้ สุด –
เริ่มตน สิน้ สุด – สิ้นสุด เริ่มตน – เริ่มตน และ เริ่มตน – สิน้ สุด

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารเวลาโครงการ หนา 5-34

การประมาณการทรัพยากรของกิจกรรมเปนการกําหนดปริมาณและประเภทของทรัพยากรที่
จะกําหนดใหกับแตละกิจกรรม ธรรมชาติของโครงการและองคการจะกระทบตอการประมาณการ
ทรัพยากร สวนการประมาณการระยะเวลาของกิจกรรมคือ การคาดคะเนเวลาทีก่ ิจกรรมตองใชเพื่อให
กิจกรรมนัน้ เสร็จสมบูรณ การประมาณการเวลาจะรวมทั้งเวลาที่ใชในการทํางานจริงและเวลาที่เผื่อ
การพัฒนาตารางเวลาโครงการนัน้ ผูจดั การโครงการชอบใชแผนภูมิแบบแกนตในการแสดง
ตารางเวลาโครงการ แผนภูมิติดตามผลแบบแกนตแสดงขอมูลตารางเวลาโครงการที่เกิดขึน้ จริงและที่
วางแผนไว
วิธีการเสนวิกฤตใชคาดการณระยะเวลาทัง้ หมดของโครงการ เสนทางวิกฤตของโครงการคือ
ชุดของกิจกรรมที่กาํ หนดวันที่โครงการเสร็จสมบูรณเร็วที่สุด เสนทางวิกฤตเปนเสนทางที่ยาวทีส่ ุดในผัง
เครือขาย กิจกรรมที่อยูบนเสนทางวิกฤตเปนกิจกรรมที่ไมมีเวลายืดหยุน ถามีกจิ กรรมใดบนเสนทาง
วิกฤตลืน่ ไถล โครงการทั้งโครงการจะลาชาไปดวย นอกเสียจากผูจดั การโครงการจะทําการเรงรัดเวลา
ซึ่งเปนเทคนิคที่ผูจัดการโครงการสามารถรนระยะเวลาโครงการ โดยการเพิ่มทรัพยากรเปนพิเศษ
การจัดตารางเวลาโซวิกฤตเปนการประยุกตทฤษฎีขอจํากัดดานทรัพยากร การทํางานหลาย
งานและกันชนเวลา เพื่อชวยใหโครงการเสร็จตรงกับที่กาํ หนด
เทคนิคการ PERT คือ เทคนิคที่ใชประมาณการชวงเวลาโครงการ โดยใชเมื่อการประมาณการ
ชวงเวลาของแตละกิจกรรมมีความไมแนนอนสูง วิธีการนี้ใชคา 3 คาคือ เวลาที่สนั้ ที่สุด เวลาที่เกิดขึ้น
มากที่สุด และเวลาที่ยาวที่สดุ
ถึงแมวา เทคนิคการจัดตารางเวลามีความสําคัญมากๆ โครงการสวนใหญลมเหลว เพราะ
เนื่องจากประเด็นทางดานคน ไมใชมาจากผังเครือขายที่ไมดี มันเปนสิ่งสําคัญทีผ่ ูจัดการโครงการตอง
กําหนดตารางเวลาโครงการใหสอดคลองกับความเปนจริง และยอมใหมีความไมแนนอนทีจ่ ะเกิดขึ้น
ตลอดวงจรชีวติ โครงการ ผูจัดการโครงการตองมีทักษะดานความเปนผูนาํ ทีจ่ ะชวยควบคุมการเปลี่ยน
ตารางเวลาโครงการ

คําถามทายบท
1. เพราะอะไรคนถึงคิดวาประเด็นทางดานตารางเวลาจึงเปนสาเหตุของความขัดแยงของโครงการ
2. เพราะเหตุใดการกําหนดกิจกรรมจึงเปนกระบวนการแรกในกระบวนการบริหารเวลาโครงการ
3. เพราะเหตุใดการเรียงลําดับกิจกรรมของโครงการจึงมีความสําคัญ
4. เพราะเหตุใดปจจัยดานคนจึงมีผลกระทบตอการบริหารโครงการมากกวาปจจัยทางดานเทคเนิค
5. ทําอยางไรจึงจะสามารถลดหรือควบคุมการเปลี่ยนแปลง

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารเวลาโครงการ หนา 5-35

6. จากขอมูลในตารางที่กาํ หนดใหทานเขียนผังเครือขายแบบ AON หาระยะเวลาของโครงการ

และ เสนทางวิกฤต
กิจกรรม กิจกรรมสุดทายกอนหนา ระยะเวลา ผูดําเนินการ
A - 4 เล็ก
B A 7 แมว
C A 8 แมว
D A 14 เล็ก
E B, C 5 แดง
F E 4 แดง
G D, F 6 เล็ก

7. อธิบายแนวความคิดทีเ่ กี่ยวของกับการจัดการตารางเวลาโซวกิ ฤต
8. อธิบายความแตกตางระหวางการจัดการตารางเวลาแบบเสนทางวิกฤตกับเสนโซวกิ ฤต
9. จากตารางในขอ 6 ใหสรางตารางโซวิกฤต

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-1

6.1 บทนํา
โครงการเทคโนโลยีสารสนเทศมีการติดตามการใชจายใหตรงตามเปาหมายงบประมาณไมดี
พอ จากผลการศึกษาในอดีตพบวา สวนใหญคาใชจายของโครงการเกินกวางบประมาณที่ไดรับการ
อนุมัติ โชคดีที่ปริมาณงบประมาณทีเ่ กินกวาแผนไดลดลงอยางตอเนื่อง ถึงแมวา โครงการเทคโนโลยี
สารสนเทศมีการพัฒนาการควบคุมคาใชจายดีขึ้น แตโครงการสวนใหญกย็ ังมีคา ใชจายที่เกิน
งบประมาณ หรือไมก็ถูกยกเลิกโครงการกอนที่จะเสร็จสมบูรณ
โดยปกติ คาใชจายวัดออกมาในรูปของเงินที่ตองจายเพื่อใหไดสนิ คาหรือบริการที่สามารถ
นําไปใชในเรื่องอื่น ดังนัน้ มันจึงเปนสิ่งที่สําคัญทีผ่ ูจัดการโครงการตองเขาใจการบริหารคาใชจาย
โครงการ ผูมอี าชีพทางดานเทคโนโลยีสารสนเทศหลายๆ คนมีปฏิกิริยาตอคาใชจายที่เกินดวยการยิ้ม
พวกเขาเหลานี้รูวาคาประมาณการคาใชจา ยโครงการเทคโนโลยีสารสนเทศนั้นมีคาต่ําตั้งแตตน เพราะ
โครงการเริ่มพรอมกับความตองการที่ไมชดั เจน จึงเปนธรรมดาที่คาใชจา ยของโครงการเกินกวาที่
วางแผนไว
การไมใหความสําคัญตอการประมาณการคาใชจายตามความเปนจริงเปนเพียงสวนหนึ่งของ
ปญหา คนดานเทคโนโลยีสารสนเทศสวนใหญชอบคิดวาการเตรียมการประมาณคาใชจายคือ งานของ
นักบัญชี แตในทางตรงกันขาม การเตรียมการประมาณการคาใชจายที่ดีเปนทักษะที่ตองมีในผูทมี่ ีอาชีพ
ทางดานเทคโนโลยีสารสนเทศ
เหตุผลหนึ่งทีถ่ ูกยกมาอางถึงการที่คาใชจา ยเกินงบประมาณบอยครั้งคือ โครงการเทคโนโลยี
สารสนเทศเกีย่ วของกับเทคโนโลยีใหมๆ หรือกระบวนการธุรกิจใหม ซึ่งยังไมผานการทดสอบ จึงมีความ
เสี่ยงซอนอยู แตจากการศึกษาของสแตนดิสกรุปพบวามีหลายโครงการที่ใชเทคโนโลยีใหมกลับไมมี
ปญหาเรื่องคาใชจายกับเทคโนโลยีที่ยงั ไมไดรับการทดสอบ แตสิ่งทีจ่ ําเปนที่โครงการตองมีคือ การ
บริหารคาใชจา ยโครงการ

6.2 การบริหารคาใชจายโครงการคืออะไร
การบริหารคาใชจายโครงการคือ กระบวนการที่ทาํ ใหแนใจวาทีมงานโครงการดําเนินโครงการ
เสร็จสมบูรณภายใตวงเงินงบประมาณที่ไดรับการอนุมตั ิ ผูจัดการโครงการตองแนใจวาโครงการไดรับ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-2

การนิยามที่ดี มีการประมาณการเวลาและคาใชจายทีถ่ ูกตอง มีงบประมาณที่สอดคลองกับความจริง

กระบวนการบริหารคาใชจายมี 3 กระบวนการคือ
• การประมาณการคาใชจาย (cost estimating) คือ การประมาณการคาใชจายของ
ทรัพยากรทีจ่ ําเปนทีจ่ ะทําใหโครงการเสร็จสมบูรณ ผลลัพธหลักที่ไดจากกระบวนการ
นี้คือ ประมาณการคาใชจายของกิจกรรม การเปลี่ยนแปลงที่รองขอ และการปรับปรุง
แผนการบริหารคาใชจาย ซึ่งเปนสวนหนึง่ ของแผนการบริหารโครงการ
• การตั้งงบประมาณคาใชจา ย (cost budgeting) เกี่ยวของกับการจัดสรรคาใชจายที่
ประมาณการใหกับงานแตละงาน เพื่อสรางเปนบรรทัดฐาน (baseline) สําหรับการวัด
การดําเนินงาน ผลลัพธของกระบวนการการตั้งงบประมาณคาใชจา ยคือ บรรทัดฐาน
คาใชจาย การเปลี่ยนแปลงที่รองขอ และการปรับปรุงแผนการบริหารโครงการ
• การควบคุมคาใชจาย (cost control) คือ การควบคุมการเปลี่ยนแปลงงบประมาณ
โครงการ ผลลัพธหลักของกระบวนการนี้คือ การวัดผลการดําเนินงาน การ
เปลี่ยนแปลงที่รองขอ คําแนะนําเพื่อแกไข การปรับปรุงแผนการบริหารโครงการ
รวมทัง้ แผนการบริหารคาใชจาย ประมาณการคาใชจาย และบรรทัดฐานคาใชจา ย
(cost baseline)

6.3 การประมาณการคาใชจาย
ถาตองการทําใหโครงการเสร็จสมบูรณดวยขอจํากัดทางงบประมาณ ผูจัดการโครงการตองทํา
การประมาณอยางจริงจัง การประมาณการคาใชจายตองมีรายละเอียดสนับสนุน รายละเอียด
ประกอบดวย กฎและสมมุติฐานที่ใชในการประมาณการ คําอธิบายโครงการ (ขอกําหนดขอบเขต และ
โครงสรางจําแนกงานยอย เปนตน) ที่ใชเปนพืน้ ฐานการประมาณการ และรายละเอียดเทคนิคและ
เครื่องมือการประมาณการคาใชจาย
ในหัวขอนี้จะอธิบายการประมาณการแบบตางๆ เทคนิคและเครื่องมือสําหรับการประมาณ
การ ปญหาที่เกีย่ วของกับการประมาณการคาใชจายเทคโนโลยีสารสนเทศ และตัวอยางรายละเอียด
ของการประมาณการคาใชจา ยสําหรับโครงการเทคโนโลยีสารสนเทศ

6.3.1 เทคนิคและเครื่องมือสําหรับการประมาณการคาใชจาย
การพัฒนาการประมาณการคาใชจายที่ดีทําไดยาก แตโชคดีที่มีเทคนิคและเครื่องมือ
หลายอยางใหชวยในการประมาณการ เทคนิคที่นยิ มใชกันมี 4 วิธีคือ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-3

• การประมาณการจากความคลายคลึง โดยการใชคาใชจายจริงจากโครงการที่
คลายคลึงกันกอนหนานี้มาเปนฐานสําหรับการประมาณการคาใชจายของ
โครงการปจจุบัน เทคนิคนีต้ องใชการตัดสินใจของผูเชีย่ วชาญ และเปนเทคนิค
ที่เสียคาใชจายนอยกวาวิธกี ารอื่นๆ ขณะเดียวกันความถูกตองต่าํ ดวยเชนกัน
วิธีการนี้ใหคาํ ตอบนาเชื่อถือมากที่สุดถาโครงการกอนหนานี้มีขอเท็จจริงที่มี
ความคลายคลึงกับโครงการที่กําลังประมาณการ นอกจากนี้กลุมที่เตรียมการ
ประมาณการคาใชจายตองมีความเชี่ยวชาญเพื่อกําหนดวาแตละสวนของ
โครงการควรมีคาใชจายเพิ่มหรือนอยกวาโครงการทีน่ ํามาใชเปนฐาน อยางไร
ก็ตาม ถาโครงการที่ถูกประมาณการเกี่ยวของกับภาษาการโปรแกรมที่ใหม
หรือทํางานกับฮารดแวรหรือเครือขายที่ใหม เทคนิคการประมาณการโดยการ
เปรียบเทียบอาจจะใหผลการประมาณการที่ต่ํามาก
• การประมาณการจากลางขึ้นบน เปนการประมาณการงานแตละงานเปน
รายการ หรือกิจกรรม และรวมคาประมาณการที่ไดเปนคาใชจายทัง้ โครงการ
บางครั้งเรียกวาตนทุนกิจกรรม (activity based costing) ความถูกตองของ
การประมาณการขึ้นอยูก ับขนาดของงานแตละงาน และประสบการณของผู
ประมาณการ ถามีโครงสรางจําแนกงานยอยที่ละเอียดให ผูจัดการโครงการ
อาจใหผูรับผิดชอบแตละชุดงานประมาณการคาใชจายของชุดงานที่ตนเอง
รับผิดชอบ หลังจากนั้นผูจัดการโครงการรวมคาใชจายที่ประมาณการเพื่อ
คํานวณเปนคาใชจายในระดับที่สูงขึ้น ในที่สุดผูจัดการโครงการจะไดประมาณ
การคาใชจายทั้งโครงการ การทําใหงานมีขนาดเล็กจะเพิ่มความถูกตองของ
การประมาณการคาใชจาย เพราะคนทีถ่ ูกกําหนดใหทํางานเปนผูประมาณการ
แทนที่จะใหคนที่ไมคนุ เคยกับงานเปนผูประมาณการ ขอเสียของการประมาณ
การแบบนี้คือ ใชเวลาในการทํามาก และทําใหเสียคาใชจายสําหรับการ
ประมาณการสูงตามไปดวย
• ตัวแบบพาราเมตริก เปนเทคนิคการประมาณการคาใชจาย โดยการใชตัวแบบ
เชิงคณิตศาสตรเพื่อประมาณการคาใชจาย ตัวแบบพาราเมตริกอาจประมาณ
การตามภาษาการโปรแกรมที่โครงการใช ระดับความเชีย่ วชาญของ
โปรแกรมเมอร ขนาดและความซับซอนของขอมูลที่เกี่ยวของ และอืน่ ๆ ตัว
แบบพาราเมตริกจะประมาณการไดนาเชือ่ ถือเมื่อสารสนเทศในอดีตที่ถูก
นํามาใชสรางตัวแบบถูกตอง

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-4

ตัวแบบพาราเมตริกที่นยิ มใชคือ ตัวแบบโคโคโม (Constructive Cost Model

(COCOMO)) เปนการประมาณการคาใชจายการพัฒนาซอฟตแวรโดย
พิจารณาจากพารามิเตอร เชน จํานวนบรรทัดของโปรแกรม หรือจํานวน
ฟงกชันพอยท (function point) ตัวแบบนี้พัฒนาโดย แบรรี โบแอม (Barry
Boehm) สวนฟงกชนั พอยทคือ การประเมินฟงกชันของระบบงานที่อสิ ระจาก
เทคโนโลยี เชน จํานวนขอมูลนําเขา (input) และจํานวนขอมูลสงออก
(output) จํานวนแฟมขอมูลที่ถูกบํารุงรักษา และใชรวมกับระบบอื่น เปนตน
จํานวนฟงกชนั สามารถแปลงเปนจํานวนบรรทัดของโปรแกรมไดโดยการ
พิจารณาจากตารางเปรียบเทียบ สวน COCOMO เปนตัวแบบทีพ่ ฒ ั นาขึน้ มา
ใหม ที่ใหเราประมาณการคาใชจาย ความพยายามในการปฏิบัติงาน (effort)
และระยะเวลาสําหรับโครงการ ตัวแบบพาราเมตริกจึงชวยประมาณการ
คาใชจาย โดยไมตองมีขอจํากัดในเรื่องความสามารถในการตัดสินใจของคน
วิธีการประมาณการดวยพารามิเตอรจะอธิบายพอสังเขปในหัวขอถัดไป
• เครื่องมือที่เปนคอมพิวเตอร เชน สเปรดชีค และซอฟตแวรบริหารโครงการ
สามารถทําการประมาณการคาใชจายตางๆ เครื่องมือนี้ถาใชอยางเหมาะสม
สามารถชวยปรับปรุงความถูกตองของการประมาณการ นอกจากนีย้ ังมี
เครื่องมือที่มีความสามารถสูงเพื่อชวยการประมาณการ

6.3.2 การประมาณการขนาดของซอฟตแวรดว ยฟงกชันพอยท

ฟงกชันพอยทเปนวิธีการวัดขนาดของซอฟตแวรที่เสนอโดย เอลบรีซ (Albrecth) โดย
พิจารณาจากลักษณะทางฟงกชนั งานของระบบงาน ผูจ ัดการโครงการ/นักวิเคราะหระบบจะตองทําการ
นับคาของพารามิเตอรทงั้ หมด 5 พารามิเตอรคือ จํานวนขอมูลทีน่ ําเขาจากภายนอก (external input
(EI)) จํานวนขอมูลที่สงออกไปภายนอก (external output (EO)) จํานวนการสอบถามจากภายนอก
(external inquiry (EQ)) จํานวนแฟมขอมูลภายในเชิงตรรกะ (internal-logical file (ILF)) และจํานวน
แฟมขอมูลเชือ่ มประสานกับภายนอก (external interface file (EIF)) ดังแสดงในรูปที่ 6.1 แตละ
พารามิเตอรจะมีนา้ํ หนักแตกตางกันขึน้ อยูกับความซับซอน หรือความงายของแตละพารามิเตอร
น้ําหนักและวิธีการคํานวณดังรูปที่ 6.2

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-5

รูปที่ 6.1 การวิเคราะหฟง กชันพอยท (Marchewka, 2006)

รูปที่ 6.2 แสดงพารามิเตอรและน้ําหนักที่ใชในการคํานวณขนาดของซอฟตแวร

การคํานวณหาขนาดของซอฟตแวรของะระบบมีขั้นตอนดังนี้
• กําหนดขอบเขตของระบบงาน
• นับจํานวนพารามิเตอร 5 ประเภท
• กําหนดระดับความซับซอน (งาย, ปานกลาง, ซับซอน) ของฟงกชนั แตละตัว
• คํานวณหาปจจัยปรับความซับซอนเพื่อใชในการปรับจํานวนฟงกชนั ปจจัยปรับ
ความซับซอนมี ทั้งหมด 14 ตัว
• คํานวณฟงกชนั พอยท

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-6

กําหนดขอบเขตของระบบงาน
• ถาระบบงานนัน้ มีการวางแผนที่จะพัฒนาเปนหลายระยะ (มีมากกวา 1 โครงการ)
ใหประมาณการแยกแตละโครงการออกจากกัน ดังนัน้ แตละโครงการใหนับจํานวน
พารามิเตอรตางๆ อิสระจากกัน
• ถาเปนระบบงานเดี่ยวแตมีขนาดใหญ เปนโครงการเดียว แตโครงการไดแบง
ระบบงานใหญใหเปนระบบงานยอยเพื่อลดความซับซอนดังรูปที่ 6.3 การแบง
ระบบงานนีเ้ ปนการแบงขอบเขตใดๆ ภายในโครงการเพื่อใชในการนับจํานวน
ฟงกชันพอยทเทานัน้ ดังนั้น ขอมูลนําเขาจากภายนอกและขอมูลสงออกไปภายนอก
ระหวางระบบงานยอยนี้จะไมถูกนับ เชนเดียวกัน เราไมนับแฟมขอมูลที่เชื่อม
ประสานระหวางระบบงานยอย สวนแฟมขอมูลภายในเชิงตรรกะใหนับที่ระบบงาน
ยอยที่เปนระบบงานบํารุงรักษาขอมูลนัน้

S1 S2

S3 S4

รูปที่ 6.3 แสดงการแบงระบบงาน

จากรูปที่ 6.3 ระบบงาน S เปนระบบงานที่ใหญ แบงออกเปน 4 ระบบงานยอย (S1,

S2, S3 และ S4) ถามีการสงขอมูลเขา-ออกระหวางระบบงานยอย หรือมีการใช
แฟมขอมูลภายในรวมกัน หรือมีการสงขอความระหวางระบบงานยอย พารามิเตอร
เหลานี้จะไมถกู นับ ดังตัวอยางที่แสดงในรูปที่ 6.4 ในรูปนี้ ระบบงานยอย S1 จะนับ
เฉพาะ A0 และ D1 เทานั้น สวนระบบงานยอย S2 ไมมีพารามิเตอรใดที่ถูกนับ
ดังนัน้ ขนาดของระบบงานยอย S2 เปน 0 เมื่อหาขนาดของระบบงานยอยทัง้
หมดแลว จึงนําคาที่ไดมารวมกันเปนขนาดของระบบงานทัง้ หมด

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-7

รูปที่ 6.4 การนับพารามิเตอรกรณีโครงการเดียวประกอบดวยระบบงานยอย

การนับพารามิเตอร
ดังที่ไดกลาวมาแลวขางตนวาพารามิเตอรที่ใชสําหรับหาขนาดของระบบงานมี 5
พารามิเตอร แตละตัวมีความหมายและวิธีการนับที่แตกตางกันดังนี้
• ขอมูลนําเขาจากภายนอก (EI)
EI หมายถึง ขอมูลที่มาจากระบบงานภายนอก หรือจากผูใช และขาม
ขอบเขตของระบบงานจากภายนอกเขามาภายใน เพือ่ บํารุงรักษาแฟมขอมูลภายในเชิงตรรกะ ดังนั้น
ขอมูลจากภายนอกจะถูกนํามาเพิ่ม หรือลบออก หรือปรับปรุงในแฟมขอมูลภายในระบบงาน ตัวอยาง
ของ EI เชน จอภาพที่ใหผใู ชบันทึกขอมูลโดยใชแปมพิมพหรือเมาส หรือขอมูลสถานะการเงินของลูกคา
ที่สงจากระบบบัญชีลูกหนี้มายังระบบงานขายและปรับปรุงแฟมขอมูลลูกคาที่อยูในระบบงานขาย การ
นับจํานวน EI ตองนับขอมูลนําเขาจากภายนอกที่ไมซ้ํา ถารูปแบบจอภาพรับขอมูลตางกัน (ขอมูลที่
นําเขาแตกตางกัน) หรือตรรกะการประมวลผลตางกัน ใหถือวาขอมูลนําเขานัน้ ไมซา้ํ กัน
การจัดกลุมความซับซอนของ EI นัน้ กลุมผูใชฟงกชันพอยทนานาชาติ
(International Function Points User Group (IFPUG) ไดกําหนดใหพจิ ารณาจากจํานวนชนิดสวนยอย
ขอมูล (data element types (DET)) หรือจํานวนฟลด และจํานวนแฟมขอมูลที่ถกู อางอิง (file types
referenced (FTR)) หลังจากนัน้ จึงกําหนดระดับความซับซอนโดยใชตารางที่ 6.1
การพิจารณา DET ของขอมูลนําเขาจากภายนอก
ƒ ไมใชฟลดที่เกิดซ้ําๆ กัน (repeated field)
ƒ นับจํานวนขอมูลที่ผูใชบันทึกเขามาในระบบงานในมุมมองของ
ผูใช แทนทีจ่ ะนับจํานวนฟลดที่จัดเก็บในแฟมขอมูล เชน ขอมูลที่
อยู ซึ่งในตารางขอมูลอาจเก็บแยกเปนหลายฟลด แตในแงของ
ผูใชแลวขอมูลที่อยูคือ ขอมูลเพียง 1 ตัวเทานัน้

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-8

ƒ ขอมูลที่เขาสูระบบงานอาจเขามาดวยวิธกี ารที่แตกตางกัน เพื่อ

กระตุนการประมวลผลแบบเดียวกัน ใหนับขอมูลที่เขามาเหลานั้น
เพียง 1 ตัวเทานัน้
การพิจารณาแฟมขอมูลที่ถกู อางอิงของขอมูลนําเขา
ƒ นับแฟมขอมูลภายในเชิงตรรกะที่ไดรับการบํารุงรักษาโดยขอมูลที่
เขามาจากภายนอก (EI)
ƒ นับแฟมขอมูลภายในเชิงตรรกะหรือแฟมขอมูลเชื่อมประสานกับ
ภายนอกที่ถกู อานระหวางการประมวลผลขอมูลนําเขาจาก
ภายนอก
ƒ ในกรณีที่แฟมขอมูลภายในเชิงตรรกะนัน้ เปนแฟมที่ถกู อานและ
ถูกเขียนดวยขอมูลนําเขา ใหนับเพียง 1 แฟมเทานัน้

ตารางที่ 6.1 ความซับซอนของขอมูลนําเขา (EI)

จํานวนแฟมขอมูลที่ถูกอางอิง (FTR) จํานวนขอมูลที่เขาถึง (DET)
<5 5-15 > 15
0 or 1 ต่ํา ต่ํา ปานกลาง
2 ต่ํา ปานกลาง สูง
>2 ปานกลาง สูง สูง

• ขอมูลสงออกไปภายนอก (EO)
EO คือ ขอมูลที่สงออกนอกขอบเขตของระบบงาน เชน รายงาน ขอความ
ยืนยัน ผลรวมที่ไดจากการคํานวณ กราฟ หรือแผนภูมิ เปนตน ขอมูลสงออกนีอ้ าจถูกสงไปยังจอภาพ
เครื่องพิมพ หรือระบบงานอืน่ การนับจํานวน EO ตองไมนับซ้าํ การพิจารณาวา EO ซ้ําหรือไมนนั้ เราจะ
พิจารณาจากรูปแบบและตรรกะการประมวลผลวาแตกตางกันหรือไม เชน ถามีรายงานยอดขายสินคา
จําแนกตามชองทางการจําหนายตามเดือน หรือสาขา หรือผูขายสินคา ถาฟลดของรายงานเหมือนเดิม
(ถึงแมวา จะแสดงในรูปแบบที่แตกตางจากเดิม) รวมทัง้ ผลรวมตามสดมภและการคํานวณไมตา งกัน เรา
จะนับ 1 EO แตถาผลรวมมีวิธีการรวมทีแ่ ตกตาง และการคํานวณไมซ้ํากันในแตละแบบ เราจะนับ EO
นั้นวาเปน EO ใหม
การจัดกลุมความซับซอนของ EO นัน้ IFPUG ไดเสนอการจัดกลุมความ
ซับซอนของ EO โดยพิจารณาจากจํานวนขอมูล (DET) และจํานวนแฟมขอมูลที่ถูกอางอิง (FTR)
หลังจากนั้นจึงกําหนดระดับความซับซอนโดยใชตารางที่ 6.2 การพิจารณา DET และ FTR มีดังนี้

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-9

การพิจารณา DET ของขอมูลสงออก

ƒ ไมนับฟลดที่เกิดซ้ําๆ กัน
ƒ ในกรณีที่เปนขอความที่ตอบกลับไปนอกระบบงานเพื่อแสดง
ขอผิดพลาดทีเ่ กิดขึ้นระหวางการประมวลผล หรือยืนยันวาการ
ประมวลผลเสร็จสมบูรณ ซึ่งขอความอาจมีมากกวา 1 จุด ใหนับรวม
ทั้งหมดเปนขอมูล 1 ตัว
ƒ ไมนับตัวแปรที่นับจํานวนหนาของรายงาน หรือตําแหนงของขอมูล
หรือคําสั่งการเปลี่ยนหนา หรือวันที/่ เวลา ที่สรางโดยระบบ
ƒ ไมนับชื่อรายงาน เลขที่จอภาพ ชื่อสดมภ
ƒ ไมนับฟลดในแฟมขอมูลภายในเชิงตรรกะที่ถูกบํารุงรักษาระหวาง
การประมวลผลผลลัพธภายนอก ถาฟลดเหลานั้นไมสง ออกไปนอก
ขอบเขตระบบงาน
ƒ นับขอมูลที่เปนขอความเปน 1 DET โดยที่ขอความนั้นอาจ
ประกอบดวย คําเดียว ประโยคเดียว ยอหนาเดียวหรือหลายยอหนา

การพิจาณาแฟมขอมูลทีถ่ ูกอางอิงของขอมูลสงออกไปภายนอกนัน้ ใช

หลักการเดียวกับแฟมขอมูลที่ถูกอางอิงของขอมูลนําเขา

ตารางที่ 6.2 ความซับซอนของขอมูลสงออกภายนอก (EO)

จํานวนแฟมขอมูลที่อางอิง (FTR) จํานวนขอมูล (DET) ที่เขาถึง
<6 6-19 > 19
0 or 1 ต่ํา ต่ํา ปานกลาง
2 or 3 ต่ํา ปานกลาง สูง
>3 ปานกลาง สูง สูง

• แฟมขอมูลภายในเชิงตรรกะ (ILF)
ILF คือ แฟมขอมูลภายในเชิงตรรกะที่เก็บขอมูลที่อยูภายในระบบงาน
แฟมขอมูลนี้ถกู บํารุงรักษาโดยระบบงานที่กําลังพิจารณา เชน แฟมใบสั่งซื้อ แฟมสินคา สําหรับ
ระบบงานขายเปนตน แฟมขอมูลนี้อาจประกอบดวยระเบียนหลายประเภท เชน แฟมขอมูลใบสั่งซื้อ
สินคาจะประกอบดวยขอมูลใบสั่งซื้อสวนหัว และขอมูลรายละเอียดการสั่งซื้อ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-10

• แฟมขอมูลเชื่อมประสานกับภายนอก (EIF)
EIF คือ แฟมขอมูลที่ใชรวมกันกับระบบงานอื่น แฟมขอมูลนี้ถูกบํารุงรักษา
โดยระบบงานภายนอก เชน แฟมขอมูลการชําระเงินของลูกคาที่ระบบงานขายเรียกใช แตระบบงาน
บัญชีลูกหนี้เปนระบบที่บาํ รุงรักษาแฟมขอมูลการชําระเงินเปนตน
IFPUG ไดเสนอการจัดกลุมความซับซอนของแฟมขอมูลภายในเชิงตรรกะ
และแฟมขอมูลเชื่อมประสาน โดยพิจารณาจากจํานวนชนิดสวนยอยขอมูล (DET) และจํานวนประเภท
ระเบียน (record element types (RET)) ในแฟมขอมูลภายในเชิงตรรกะ หรือแฟมขอมูลเชื่อมประสาน
กับภายนอก หลังจากนั้นจึงกําหนดระดับความซับซอนโดยใชตารางที่ 6.3
การพิจารณาขอมูล (DET)
ƒ ขอมูลหรือแอตทริบิวตที่ถกู บํารุงรักษาโดยที่แอตทริบิวตนั้นตองไมซา้ํ
กัน หรือเปนแอตทริบิวตเรียกออกมาจาก ILF หรือ EIF ขอมูลเหลานี้
เปนขอมูลที่ผูใชเขาใจ เชน เลขที่เช็ค จํานวนเงิน วันที่ ผูจา ยเงิน
เลขที่บัญชี ที่ถูกบํารุงรักษาในแฟมขอมูลรายการบัญชีเช็ค ใหนับ
ขอมูลแตละตัว
ƒ ถามีระบบงาน 2 ระบบหรือมากกวา ทําการบํารุงรักษา หรืออางอิง
ขอมูลใน ILF หรือ EIF เหมือนกัน แตฟลดตางกัน ใหนบั เฉพาะฟลดที่
ใชในแตละระบบงานเพื่อกําหนดขนาดของ ILF หรือ EIF
การพิจารณาประเภทระเบียน (RET)
ƒ ประเภทระเบียน (RET) คือ กลุมยอยของขอมูลที่ผูใชสามารถเขาใจ
ได ซึ่งเก็บอยูใ น ILF หรือ EIF กลุมยอยของขอมูลนีจ้ ะปรากฎเปน
เอนทิตียอยในผัง E-R ที่เรียกวาความสัมพันธแบบพอ-ลูก เชน ใน
แฟมขอมูลพนักงาน ผูใชเขาใจวาขอมูลทัว่ ไปของพนักงานจัดเก็บใน
แฟมนี้ ถามีขอมูลการขึ้นเงินเดือนและขอมูลชั่วโมงการทํางานเปน
ขอมูลสวนหนึง่ ของขอมูลพนักงาน และขอมูลดังกลาวเปนเอนทิตี
ยอยของเอนทิตีพนักงาน เราจึงนับวาแฟมขอมูลพนักงานมี 2 RET
ƒ ถาไมมีกลุม ยอย ใหนับ ILF หรือ EIF เปน 1 RET

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-11

ตารางที่ 6.3 ระดับความซับซอนของแฟมขอมูล

จํานวนรายการ (RET) จํานวนขอมูล (DET)
< 20 20-50 > 50
1 ต่ํา ต่ํา ปานกลาง
2-5 ต่ํา ปานกลาง สูง
>5 ปานกลาง สูง สูง

• การสอบถามจากภายนอก (EQ)
EQ ประกอบดวยขอมูลนําเขาจากภายนอกและขอมูลสงออกไปภายนอก
ขอมูลนําเขาจากภายนอกถูกสงเขาสูระบบงานเพื่อดึงขอมูลจาก ILF หรือ EIF แลวแสดงผลลัพธทันที ไม
มีสูตรทางคณิตศาสตร หรือคํานวณ และไมสรางขอมูลโดยการคํานวณ (derived data) นอกจากนี้ ILF
ตองไมถูกบํารุงรักษาระหวางประมวลผล สําหรับการนับจํานวน EQ ใหนับขอมูลนําเขาและขอมูลนํา
ออกรวมกันเปน 1 EQ
สวนการจัดระดับความซับซอนของ EQ ใหแบงการพิจารณาเปน 2 สวนคือ
สวนขอมูลนําเขาจากภายนอกจะพิจารณาระดับความซับซอนตามหลักเกณฑของ EI สวนที่เปนขอมูล
สงออกภายนอกระบบจะพิจารณาระดับความซับซอนตามหลักเกณฑของ EO สําหรับการพิจารณา
ระดับความซับซอนของ EQ นัน้ ๆ เราจะตองนําระดับที่ไดจากทั้ง 2 สวนมาพิจารณารวมกันแลวเลือก
ระดับความซับซอนที่สงู ที่สดุ เชน ถาระดับความซับซอนของขอมูลนําเขาจากภายนอกมีคาปานกลาง
และระดับความซับซอนของขอมูลสงออกไปภายนอกมีคา เปนซับซอน เราจะจัดวา EQ นั้นมีคา ระดับ
ความซับซอนสูง

กําหนดคาของปจจัยปรับฟงกชันพอยท
การคํานวณหาขนาดของซอฟตแวรโดยการพิจารณาจากฟงกชนั งานที่ผูใชจะไดรับหรือ
ใชงานยังไมเพียงพอในการกําหนดขนาดของซอฟตแวรทแี่ ทจริง ดังนัน้ ผูจัดการโครงการตองพิจารณา
ประเด็นคุณลักษณะโดยทั่วไปของระบบวามีความซับซอนมากนอยแคไหน คุณลักษณะที่ใชในการ
พิจารณามีทงั้ หมด 14 ตัว ขัน้ ตอนการคํานวณหาคาของปจจัยความซับซอนมี 3 ขั้นตอนดังนี้
• ประมาณการระดับอิทธิพลของแตละปจจัย (14 ปจจัย) ที่มีตอระบบ
14
• รวมคาระดับอิทธิพลที่ได ( ∑ Fi ) และนํามาคํานวณคาปจจัยปรับคาฟงกชัน
i =1

พอยท (value adjustment factor (VAF)) ตามสูตรดังนี้

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-12

14
VAF = 0.65 + (0.01 ∑ Fi )
i =1

• คูณ VAF กับ จํานวนฟงกชนั พอยทที่ไดคํานวณไว

ปจจัยปรับความซับซอน (VAF)
ปจจัยปรับความซับซอนมี 14 ตัว แตละตัวจะมีคาตั้งแต 0 ถึง 5 โดยที่
0 หมายถึง ไมปรากฎ หรือ ไมมีอิทธิพล
1 หมายถึง มีอิทธิพลนอย
2 หมายถึง มีอิทธิพลพอประมาณ
3 หมายถึง มีอิทธิพลปานกลาง
4 หมายถึง มีอิทธิพลอยางมีนัยสําคัญ
5 หมายถึง มีอิทธิพลอยางมาก
ตอไปนี้คือ ปจจัยและความหมายของปจจัยทัง้ 14 ตัว

1. การสื่อสารขอมูล (data communication) หมายถึง ระดับที่ระบบงานสื่อสาร

โดยตรงกับหนวยประมวลผล ขอมูลที่ใชในระบบงานถูกสงและรับผานสิง่ อํานวย
ความสะดวกดานการสื่อสาร (communication facilities) เครื่องปลายทางที่ตอ
เขาหนวยควบคุม (control unit) จัดวาเปนการใชสงิ่ อํานวยความสะดวกดานการ
สื่อสาร รวมทั้งโปรโตคอลที่ใชในการสงผานหรือแลกเปลี่ยนขอมูลระหวางระบบ
หรืออุปกรณ
2. การประมวลผลขอมูลแบบกระจาย (distributed data processing) หมายถึง
ระดับที่ระบบงานสงขอมูลระหวางสวนประกอบ (component) ของระบบงาน
3. สมรรถนะ (performance) หมายถึง ระดับเวลาที่สนองตอบ (response time)
และปริมาณงาน (throughput) มีอิทธิพลตอการพัฒนาระบบงาน ไมวาจะเปนการ
ออกแบบ การพัฒนา การติดตั้ง และการสนับสนุน
4. คอนฟกรูเรชันถูกใชอยางมาก (heavily used configuration) หมายถึง ระดับการ
จํากัดการใชทรัพยากรคอมพิวเตอรมีอิทธิพลตอการพัฒนาระบบงาน เชน ผูใช
ตองการใหระบบงานทํางานบนอุปกรณที่มีอยูและอุปกรณนั้นอาจถูกใชอยางมาก
5. อัตราธุรกรรม (transaction rate) หมายถึง ระดับที่อัตราธุรกรรมทางธุรกิจมี
อิทธิพลตอการพัฒนาระบบงาน อัตราธุรกรรมสูงจะมีอทิ ธิพลตอการออกแบบ การ
ติดตั้งและการสนับสนุนระบบงาน

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-13

6. การนําเขาขอมูลออนไลน (online data entry) หมายถึง ระดับที่ขอมูลถูกนําเขา

ผานธุรกรรมแบบเชิงโตตอบ (interactive transaction)
7. ประสิทธิภาพผูใช (end user efficiency) หมายถึง ระดับการคํานึงถึงปจจัยดาน
มนุษย (human factor) และความงายการใชงานของผูใช
8. การปรับปรุงแบบออนไลน (online update) หมายถึง ระดับที่ ILF ถูกปรับปรุงแบบ
ออนไลน
9. การประมวลผลซับซอน (complex processing) ระดับที่ตรรกะการประมวลผลมี
อิทธิพลตอการพัฒนาระบบงาน
10. ความสามารถนํากลับมาใชใหม (reusability) หมายถึง ระดับที่โปรแกรมใน
ระบบงานไดรับการออกแบบ พัฒนาและสนับสนุนเพือ่ ใหสามารถนํากลับมาใชได
อีก
11. ความงายในการติดตั้ง (installation ease) หมายถึง ระดับความยากงายในการ
แปลงผัน (conversion) และติดตั้ง
12. ความงายเชิงปฏิบัติงาน (operational ease) หมายถึง ระดับที่ระบบงานใหความ
เอาใจใสตอลักษณะเชิงปฏิบัติงาน เชน กระบวนการเริม่ งานเครื่อง (start-up) การ
สํารอง การกูค ืน (recovery) ระบบงานควรลดความตองการการกระทําดวยมือให
นอยที่สุด เชน การใสเทป การยกกระดาษ
13. สถานที่ติดตั้งหลายที่ (multiple sites) หมายถึง ระดับที่ระบบงานถูกพัฒนา
สําหรับติดตั้งหลายแหง หรือสําหรับองคกรผูใชหลายแหง
14. การเปลี่ยนแปลงทําไดคลอง (facilitate change) หมายถึง ระดับทีร่ ะบบงานถูก
พัฒนาใหงายแกการปรับปรุงแกไขตรรกะการประมวลผล หรือโครงสรางขอมูล

การเปลี่ยนจากฟงกชันพอยทเปนจํานวนบรรทัดของโปรแกรม
เมื่อทราบจํานวนฟงกชันพอยทแลว เราสามารถเปลี่ยนเปนจํานวนบรรทัดของ
โปรแกรม (lines of code (LOC)) ได ซึ่งจํานวน LOC ที่ไดขึ้นอยูกับภาษาที่เลือกใชในการเขียน
โปรแกรม ตารางที่ 6.4 คือ ตารางเทียบคาระหวางฟงกชนั พอยท (FP) และ LOC

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-14

ตารางที่ 6.4 ตารางเทียบคาระหวางฟงกชันพอยทและ LOC (Pressman, 2005)

ภาษาการโปรแกรม LOC/FP (เฉลี่ย) ภาษาการโปรแกรม LOC/FP (เฉลี่ย)
Access 35 Java 63
Ada 154 JavaScripty 58
APS 86 JCL 91
ASP 69 62 Lotus Notes 21
Assembler 337 Oracle 30
C 162 PeopleSoft 33
C++ 66 Perl 60
Clipper 38 PL/1 78
COBOL 77 Powerbuilder 32
Dbase IV 52 RPGII/III 61
Excel47 46 SAS 40
Focus 43 Smalltalk 26
FORTRAN 105 SQL 40
FoxPro 32 VBScript36 34
Informix 42 Visual Basic 47

ตัวอยางการนับพารามิเตอร
จากรูปที่ 6.5 เปนผังการไหลของขอมูลระบบงานพนักงานที่แบงออกเปนระบบงานยอย
4 ระบบคือ ระบบบํารุงรักษาขอมูลพนักงาน (employee maintenance) ระบบมอบหมายงาน (job
assignment) ระบบบํารุงรักษางาน (job maintenance) และระบบการออกรายงานสถานทีท่ ํางานของ
พนักงาน (location reporting) ผลการนับพารามิเตอรแสดงในตารางที่ 6.5 สวนการพิจารณา
พารามิเตอรตางๆ และคาสมมุติความซับซอนมีดังนี้
• ขอมูลนําเขาจากภายนอก (EI)
ƒ new-employee: ปานกลาง (2 FTR: employee, location; 10 DET)
ƒ delete-employee: งาย (2 FTR: employee, job-assignment; 3 DET)
ƒ modify-info: ปานกลาง (2 FTR: employee, location; 10 DET)
ƒ assign-emp-job : ปานกลาง (3 FTR: employee, job, job-assignment;
6 DET)
ƒ transfer-emp-job : ปานกลาง (3 FTR: employee, job, job-
assignment; 6 DET)

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-15

ƒ evaluate-emp-job : งาย (1 FTR: job-assignment; 6 DET)

ƒ delete-assignment-job : งาย (1 FTR: job-assignment; 4 DET)
ƒ newjob : งาย (1 FTR: job, 6 DET)
ƒ delete-job: งาย (2 FTR: job, job-assignment; 3 DET)
ƒ mod-des: งาย (1 FTR: job, 6 DET)

รูปที่ 6.5 ผังการไหลของขอมูลระบบงานพนักงาน

• ขอมูลสงออกไปภายนอก (EO)
ƒ employee-report : ปานกลาง (2 RET: employee, location; DET: 6-
19)

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-16

ƒ job-assignment-report : ปานกลาง (3 RET: employee, job-

assignment, job; DET: 6-19)
ƒ job-report : งาย (1 RET; DET: 3)
ƒ locat-report : ปานกลาง (2 RET: location, employee; DET: 6)
• แฟมขอมูลภายในเชิงตรรกะ (ILF)
ƒ employee ประกอบดวย 2 RET และ 8 DET (ไมนับเปน RET เพราะมี
กลุมขอมูลยอย) จัดเปนระดับงาย
o employee_name
o social_security_number
o number_dependents
o type_code (salaried or hourly)
o location_name (FK)
o salaried_employee (นับ RET 1)
• supervisory_level
o hourly_employee (นับ RET 2)
• standard_hourly_rate
• collective_bargaining_unit_number
ƒ job-assignment ประกอบดวย 1 RET และ 5 DET จัดเปนระดับงาย
o effective_date
o salary
o performance_rating
o job_number (FK)
o employee_SSN (FK)
ƒ job ประกอบดวย 1 RET และ 4 DET จัดเปนระดับงาย
o job_name
o job_number
o job_description
o pay_grade
• แฟมขอมูลประสานกับภายนอก (EIF)
ƒ Location ประกอบดวย 1 RET และ 3 DET จัดเปนระดับงาย

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-17

o location_name
o address
o interoffice_code
• การสอบถามจากภายนอก (EQ)
ƒ employee-inquiry และ e-Q-response: งาย (1 RET; 10 DET รวม
ขอความแสดงขอผิดพลาด และ command key)
ƒ job-assign-inquiry และ ja-Q-response: งาย (1 RET; 7 DET รวม
ขอความแสดงขอผิดพลาด และ command key)
ƒ job-inquiry และ j-Q-response: งาย (1 RET; 6 DET รวมขอความแสดง
ขอผิดพลาด และ command key)
ƒ locat-inquiry และ l-Q-response : งาย (1 RET; 5 DET รวมขอความ
แสดงขอผิดพลาด และ command key)

ตารางที่ 6.5 ผลการนับพารามิเตอรของตัวอยางในรูปที่ 6.5

เมื่อคํานวณหาคาของฟงกชนั พอยทแลว เราจึงหาคาของปจจัยปรับความซับซอน

(VAF) ทัง้ 14 ตัว ซึ่งสมมติมคี าดังตารางที่ 6.6

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-18

ตารางที่ 6.6 คาของปจจัย 14 ตัว

คุณลักษณะของระบบงาน ระดับอิทธิพล
การสื่อสารขอมูล (data communication) 3
การกระจายการประมวลผล (distributed data processing) 2
ประสิทธิภาพ (performance) 4
คอนฟกกรูเรชันถูกใชอยางมาก (heavily used configuration) 3
อัตราธุรกรรม (transaction rate) 3
การนําเขาขอมูลออนไลน (online data entry) 4
ประสิทธิภาพผูใช (end user efficiency) 4
การปรับปรุงออนไลน (online update) 3
การประมวลผลซับซอน (complex processing) 3
ความสามารถนํากลับมาใชใหม (reusability) 2
ความงายในการติดตั้ง (installation ease) 3
ความงายเชิงปฏิบัติงาน (operational ease) 3
สถานที่ติดตั้งหลายที่ (multiple sites) 1
การเปลี่ยนแปลงทําไดคลอง (facilitate change) 2
ผลรวม 40

จากนั้นจึงคํานวณหาคาปจจัยปรับคาฟงกชันพอยท (VAF)) ตามสูตรดังนี้

14
VAF = 0.65 + (0.01 ∑ Fi )
i =1

= 0.65 + (0.01 X 40)

= 1.05

ดังนัน้ จํานวนฟงกชันพอยทของระบบพนักงานที่ไดหลังจากพิจารณาคุณลักษณะ
ทั่วไปของระบบคือ 91 X 1.05 = 95.55
เมื่อเราทราบขนาดของซอฟตแวรที่เราจะพัฒนาแลว เราสามารถคําณวนคาใชจา ยใน
สวนนี้ไดโดยการประมาณการจากขอมูลเดิมที่มีอยู เชน สมมุติวา 1 ฟงกชนั พอยท มีคาใชจายเฉลี่ย
10,000 บาท ดังนัน้ 95.55 ฟงกชันพอยทจึงคิดเปนคาใชจายเทากับ 955,500 บาท
โดยปกติ การหาคาใชจา ยเฉลี่ยของการพัฒนาซอฟตแวร เราตองพิจารณาจาก
โครงการที่พัฒนาซอฟตแวรที่มีคุณลักษณะใกลเคียงกัน คาประมาณการควรใชวิธีการตัวเลขสามตัว
(three-point estimate) เชนเดียวกับทีก่ ลาวในเรื่องการบริหารเวลาโครงการ เพื่อลดความเสี่ยงในการ
ประมาณการผิดพลาด

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-19

6.3.3 การประมาณการแรงงานดวยวิธีโคโคโม (COCOMO)

COCOMO มีชื่อเต็มคือ COnstruction COst MOdel พัฒนาโดย โบแอม (ค.ศ. 1981)
ซึ่งเรียกวา COCOMO81 หรือ COCOMOI โดยมีวัตถุประสงค เพือ่ ประมาณการแรงงานและเวลาที่ตอง
ใชในการพัฒนาซอฟตแวร ตอมาปค.ศ. 2000 โบแอม ไดพัฒนาปรับปรุงตัวแบบ COCOMO ใหมให
สอดคลองกับวิธีการพัฒนาซอฟตแวรที่เปลี่ยนไปจากเดิมอยางมากมาย ตัวแบบใหมนี้จงึ เรียกวา
COCOMO2000 หรือ COCOMOII

6.3.3.1 COCOMOI
COCOMOI เปนตัวแบบทีป่ ระมาณการแรงงาน (effort) และระยะเวลาที่ใช
จํานวนบรรทัดของโปรแกรม (LOC) ประกอบดวยตัวแบบ 3 แบบ สําหรับในทีน่ ี้จะอธิบายเพียงแค 2 ตัว
แบบแรกเทานัน้
• ตัวแบบระดับพื้นฐาน (basic model) ประมาณการแรงงานโดยไมมตี ัว
ปรับคา
• ตัวระดับแบบกลาง (intermediate model) ตัวแบบที่มกี ารพัฒนาจากตัว
แบบระดับพื้นฐาน แตมีความละเอียดมากขึ้น โดยมีการปรับคาที่ไดจาก
ตัวแบบแรกดวยตัวขับเคลื่อนคาใชจาย (cost driver)
• ตัวแบบระดับสูง (advanced model) มีการประมาณการแบบเดียวกับ
ตัวแบบระดับกลาง แตการคํานวณแรงงานและการประเมินตัวขับเคลือ่ น
คาใชจายจะทําในแตละเฟสของการพัฒนาระบบงาน

ขั้นตอนการประมาณการ
1. จัดประเภทของระบบงานที่กําลังพิจารณา ซึ่งมี 3 ประเภท ตอไปนี้
• ประเภทออกานิก (organic mode)
ƒ ทีมงานทีพ่ ัฒนามีขนาดเล็ก
ƒ ระบบงานมีขนาดเล็ก ประมาณไมเกิน 50 KLOC
ƒ พัฒนาภายในสภาวะแวดลอมภายในองคการ (in-house
environment)
ƒ ทีมงานมีความคุนเคย หรือมีประสบการณกบั ระบบงานทีจ่ ะ
พัฒนา
ƒ สามารถตอรอง ขอปรับเปลีย่ นรายละเอียดของซอฟตแวรได

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-20

ƒ ระบบงานพัฒนาอยูบนสภาวะแวดลอมทีค่ งที่ (stable

environment)
ƒ อัลกอริทึมของการประมวลผลไมมีความซับซอน
ƒ ระยะเวลาในการพัฒนาไมเปนตัวกดดันตอผูพัฒนามากนัก
• ประเภทเซมิดีเทช (semi-detached mode)
ƒ คนในทีมมีทั้งคนที่มีและไมมีประสบการณในระบบงานทีก่ ําลัง
พัฒนา
ƒ คนในทีมทุกคนมีประสบการณในระบบงานที่เกี่ยวของปานกลาง
ƒ มีแรงกดดันจากระยะเวลาของโครงการบาง
ƒ ระบบงานมีขนาดปานกลาง ประมาณไมเกิน 300 KLOC
ƒ อัลกอริทึมของการประมวลผลมีความซับซอนพอประมาณ
• ประเภทเอมเบนเด็ด (embedded mode)
ƒ ทีมงานไมมีความคุน เคย หรือไมมีประสบการณกับระบบงานที่จะ
พัฒนา
ƒ ขอกําหนดของระบบงานทีพ่ ัฒนาไมสามารถเปลี่ยนแปลงได อัน
เนื่องมาจากขอจํากัดตางๆ
ƒ ตองพัฒนาระบบงานทีท่ ํางานรวมกับอุปกรณเฉพาะ หรือระบบ
พัฒนาขึ้นโดยผูกกับกฎ ระเบียบ หรือขั้นตอนการดําเนินงานอยาง
เครงครัด
ƒ ตองพัฒนาระบบงานภายในเวลาทีก่ ําหนด
ƒ อัลกอริทึมของการประมวลผลมีความซับซอน
ƒ ตองทดสอบความถูกตองอยางมาก
2. คํานวณหาแรงงานปกติและระยะเวลาการพัฒนาระบบงาน โดยมีสูตร
การคํานวณของแตละตัวแบบดังนี้
• ตัวแบบระดับพื้นฐาน
แรงงาน (คน-เดือน) = a x KLOCb
ระยะเวลาการพัฒนา = c x แรงงานd
โดยที่ a, b, c, d มีคาดังตารางที่ 6.7

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-21

ตารางที่ 6.7 คาพารามิเตอรสําหรับตัวแบบระดับพืน้ ฐาน

ประเภทระบบงาน a b c d
ออกานิก 2.4 1.05 2.5 0.38
เซมิดีเทช 3.0 1.12 2.5 0.35
เอมเบนเด็ด 3.6 1.20 2.5 0.32

ตัวอยาง : สมมุติวาระบบงานมีขนาด 33.3 KLOC และ ระบบงานเปนแบบเซ-

มิดีเทช จะคํานวณแรงงาน ระยะเวลา และจํานวนคนไดดังนี้
แรงงาน (คน-เดือน) = 3.0 x KLOC1.12
= 3.0 x 33.31.12
= 152 คน-เดือน
ระยะเวลา = 2.5 x1520.35
= 14.5 เดือน
จํานวนคน = 152 / 14.5
= 11 คน
• ตัวระดับแบบกลาง
แรงงาน (คน-เดือน) = a x KLOCb x ตัวขับเคลื่อนคาใชจาย
ระยะเวลา = c x แรงงานd
โดยที่ a, b, c, d มีคาดังตารางที่ 6.8

ตารางที่ 6.8 คาพารามิเตอรสําหรับตัวแบบระดับกลาง

ประเภทระบบงาน a b c d
ออกานิก 3.2 1.05 2.5 0.38
เซมิดีเทช 3.0 1.12 2.5 0.35
เอมเบนเด็ด 2.8 1.20 2.5 0.32

3. คํานวณหาปจจัยปรับแรงงาน (effort adjustment factor)

ถาการคํานวณหาแรงงานโดยใชตัวแบบระดับกลาง ผูจดั การโครงการจะตอง
ปรับคาของแรงงานปกติที่คาํ นวณไดจากขอ 2 ดวยปจจัยปรับแรงงาน ซึง่ ได
จากตัวขับเคลือ่ นคาใชจาย (cost driver) ที่มี 15 ตัว แบงเปน 4 กลุม ดัง
ตารางที่ 6.9

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-22

ตารางที่ 6.9 ตัวขับเคลื่อนคาใชจาย

คุณลักษณะดาน คุณลักษณะดาน คุณลักษณะดานบุคคล คุณลักษณะดาน
ระบบงาน (product คอมพิวเตอร (computer (personnel attributes) โครงการ (project
attributes) attributes attributes)
ความตองการดานความ ขอจํากัดดานเวลาการ ความสามารถนักวิเคราะห การเขียนโปรแกรมแบบ
เชื่อถือของระบบงาน ประมวลผล (execution ระบบ (analyst ทันสมัย (modern
(reliability requirement) time constraints) capability) programming practices)
ขนาดของฐานขอมูล ขอจํากัดดานพื้นที่เก็บ ประสบการณกับเครื่องจักร เครื่องมือในการพัฒนา
(database size) ขอมูล (storage เสมือน (virtual machine ซอฟตแวร (software
constraints) experience) tools)
ความซับซอนของ เครื่องจักรที่ใชกับ ความสามารถของ ระยะเวลาที่ตองการใชใน
ระบบงาน (product ระบบงานเปลี่ยนแปลงงาย โปรแกรมเมอร การพัฒนาระบบงาน
complexity) (virtual machine (programmer capability) (required development
volatility) schedule)
เวลาที่สงงานเขา ประสบการณดานภาษา
ประมวลผลจนกระทั่งไดผล การโปรแกรมที่จะใชในการ
ลัพธ (computer พัฒนาซอฟตแวร
turnaround time) (programming language
experience)
ประสบการณในระบบงาน
ที่จะพัฒนา (application
experience)

ตัวขับเคลื่อนคาใชจายแตละตัวจะมีอัตราแตกตางกันตั้งแตต่ํามาก (very
low) จนกระทัง่ สูงเปนพิเศษ (extra high) ซึ่งแตละระดับจะมีคาแตกตางกัน
ดังแสดงในตารางที่ 6.10 ผูจัดการโครงการจะตองระบุใหไดวาตัวขับเคลื่อน
คาใชจายแตละตัวมีคาเทาไร แลวจึงนําคาของตัวขับเคลื่อนคาใชจายทุกตัว
มาคูณกัน จากนัน้ จึงนําผลคูณของตัวขับเคลื่อนคาใชจายทั้งหมดไปคูณกับ
แรงงานปกติทไี่ ดจากขอ 2 ตารางที่ 6.11 และ 6.12 จะชวยใหผจู ัดการ
โครงการสามารถกําหนดระดับของตัวขับเคลื่อนคาใชจายแตละตัว เชน
ความเชื่อถือของระบบงาน (RELY) จะไดระดับสูงมาก (1.40) ถาระบบงาน
นั้นมีผลกระทบตอชีวิตมนุษย หรือสถานภาพการเงินขององคการอยางรุนแรง

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-23

แตถาระบบงานลมเหลวแลวมีผลเพียงแคทําใหเกิดความไมสะดวกในการ
ทํางานเทานั้น คาระดับของ RELY ในกรณีจะต่ํามาก (0.75)
สําหรับความซับซอนของระบบงาน (CPLX) นั้น ผูจัดการโครงการจะกําหนด
ระดับของตัวขับเคลื่อนคาใชจายไดโดยพิจารณาจากตารางที่ 6.12 ถา
ระบบงานมีการคํานวณที่มีสตู รการคํานวณทางคณิตศาสตรหรือสถิติที่
ซับซอน คาระดับของ CPLX จะสูงมาก (1.30) แตถา เปนการคํานวณงายๆ
คาระดับของ CPLX จะต่ํา (0.70) สวนตารางที่ 6.13 คือ ตัวอยางการกําหนด
ระดับและคาของตัวขับเคลื่อนคาใชจาย

ตารางที่ 6.10 ระดับของตัวขับเคลื่อนคาใชจาย (Boehm 1981)

ระดับ
ตัวขับเคลื่อนคาใชจาย ต่ํา ต่ํา ปกติ สูง สูง สูงเปน
มาก มาก พิเศษ
คุณลักษณะดานระบบงาน (product attributes)
RELY (ความตองการดานความเชื่อถือของระบบงาน) 0.75 0.88 1.00 1.15 1.40
DATA (ขนาดของฐานขอมูล) 0.94 1.00 1.08 1.16
CPLX (ความซับซอนของระบบงาน) 0.70 0.85 1.00 1.15 1.30 1.65
คุณลักษณะดานคอมพิวเตอร (computer attributes)
TIME (ขอจํากัดดานเวลาการประมวลผล) 1.00 1.11 1.30 1.66
STOR (ขอจํากัดดานพื้นที่เก็บขอมูล) 1.00 1.06 1.21 1.56
VIRT (เครื่องจักรที่ใชกับระบบงานเปลี่ยนแปลงงาย) 0.87 1.00 1.15 1.30
TURN (เวลาที่สงงานเขาประมวลผลจนกระทั่งไดผลลัพธ) 0.87 1.00 1.07 1.15
คุณลักษณะดานบุคคล (personnel attributes)
ACAP (ความสามารถนักวิเคราะหระบบ) 1.46 1.19 1.00 0.86 0.71
AEXP (ประสบการณในระบบงานที่จะพัฒนา) 1.29 1.13 1.00 0.91 0.82
PCAP (ความสามารถของโปรแกรมเมอร) 1.42 1.17 1.00 0.86
VEXP (ประสบการณกับเครื่องจักรเสมือน) 1.21 1.10 1.00 0.90
LEXP (ประสบการณดานภาษาการโปรแกรมที่จะใชในการ 1.14 1.07 1.00 0.95
พัฒนาซอฟตแวร)
คุณลักษณะดานโครงการ (project attributes)
MODP (การเขียนโปรแกรมแบบทันสมัย) 1.24 1.10 1.00 0.91 0.82
TOOL (การใชเครื่องมือในการพัฒนาซอฟตแวร) 1.24 1.10 1.00 0.91 0.83
SCED (ระยะเวลาที่ตองการใชในการพัฒนาระบบงาน) 1.23 1.08 1.00 1.04 1.10

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-24

ตารางที่ 6.11: การกําหนดระดับใหกบั ตัวขับเคลื่อนคาใชจาย (Boehm 1981)

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-25

ตารางที่ 6.12 การกําหนดระดับใหกบั ความซับซอนของระบบงาน (product complexity) กับประเภทมอดูล(Boehm 1981)

ระดับ การดําเนินการควบคุม (Control Operations)
ต่ํามาก คําสั่งเขียนเรียงลําดับพรอมกับตัวดําเนินการ
(operator) ที่ไมไดซอนในอีกกระบวนงานหนึ่ง (non-
nested) เพียงเล็กนอย: DOs, CASEs,
IFTHENELSEs. เพรดิเคตงายๆ
ต่ํา การซอนในของตัวกระทําแบบตรงไปตรงมา สวน
ใหญเปนเพรดิเคตงายๆ
ปกติ โดยสวนใหญการซอนในงายๆ มีการควบคุมระหวาง
มอดูลบาง ตารางการตัดสินใจ
สูง ตัวดําเนินการที่ซอนในสูงพรอมกับเพรดิเคตผสม
หลายตัว เชน คิวและการควบคุมแบบเรียงทับซอน
(stack) มีการควบคุมความสัมพันธระหวางมอดูล
พอสมควร.
สูงมาก การโปรแกรมแบบเรียกซ้ําและการกลับเขาใหม การ
จัดการการขัดจังหวะที่ไดจัดลําดับตายตัว
สูงเปน การจัดตารางเวลาทรัพยากรหลายอยางพรอมกับการ ยากและไมมีโครงสรางเชน การวิเคราะหเสียง
พิเศษ เปลี่ยนลําดับความสําคัญอยางพลวัต การควบคุม รบกวนที่แมนยําสูง ขอมูลสโทแคสติก
ระดับไมโครโปรแกรม
การดําเนินการคํานวณ (Computational
Operations)
สมการที่งาย: เชน A = B+C *(D-E)
สมการระดับกลาง, เชน.
D = SQRT (B**2-4, *A*C*)
ใชรูทีนทางคณิตศาสตรและสถิติ การดําเนินการ
เมทริกซ/เวคเตอรพื้นฐาน
การวิเคราะหเชิงตัวเลขพื้นฐาน เชน การ
ประมาณคาในชวงหลายตัวแปร (multivariate
interpolation), สมการเชิงอนุพันธสามัญ. การ
ตัดออก การปดทิ้ง
ยากแตมีโครงสราง เชน สมการใกลเคียงกับเมท
ริกซเอกฐาน (near-singular matrix), สมการเชิง
อนุพันธยอย
การดําเนินการขึน้ กับอุปกรณ (Device-
dependent Operations)
อาน, เขียนขอความสั่งดวยรูปแบบงาย
ไมจําเปนตองมีความรูความเขาใจคุณ
ลักษณะเฉพาะของอุปกรณรับเขา/สงออก หรือ
หนวยประมวลผล
การประมวลขอมูลรับเขา/สงออก รวมทั้งการ
เลือกอุปกรณ การตรวจสอบสถาน และการ
ประมวลผลขอผิดพลาด
การดําเนินการรับเขาสงออกระดับกายภาพ
(การแปลที่อยู ที่เก็บระดับกายภาพ เชน คนหา
อาน) การซอนเหลื่อมระหวางรับเขา/สงออก
เหมาะที่สุด
รูทีนสําหรับการวินิจฉัยการขัดจังหวะ การบริการ ทําใหใชไดทั่วไป แฟมแบบพารามิเตอร การสราง
การพลาง การจัดการเสนทางการสื่อสาร
การโปรแกรมพึงพิงเวลาอุปกรณ การดําเนินการ
ระดับไมโครโปรแกรม
การดําเนินการจัดการขอมูล (Data
Management Operations)
แถวลําดับ (arrays ) งายๆ ในหนวยความจําหลัก
จัดแฟมขอมูลยอยแฟมเดียว ไมมีการเปลี่ยน
โครงสรางขอมูล ไมมีการแกไข ไมมีแฟมขอมูล
ระหวางกลาง
ขอมูลนําเขาหลายแฟม และมีแฟมขอมูลสงออก
เพียงแฟมเดียว การเปลี่ยนเชิงโครงสรางอยางงาย
การแกไขอยางงาย
มีการเรียกใชรูทีนยอยที่มีวัตถุประสงคเฉพาะ เชน
การปรับโครงสรางขอมูลที่ซับซอนระดับระเบียน
แฟม การประมวลผลคําสั่ง การคนหาที่เหมาะสม
ผูกกันสูง โครงสรางเชิงสัมพัธพลวัต การจัดการ
ขอมูลดวยภาษาธรรมชาติ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-26

ตารางที่ 6.13 ตัวอยางการกําหนดระดับและคาของตัวขับเคลื่อนคาใชจาย

ตัวขับเคลื่อน ตัวคูณ
สถานการณ ระดับ
คาใชจาย แรงงาน
RELY ซอฟตแวรลมเหลวมีผลดานการเงินที่รุนแรง สูง 1.15
DATA 20,000 ไบต ต่ํา 0.94
CPLX การประมวลผลการสื่อสาร สูงมาก 1.30
TIME จะใช 70% ของเวลที่มีให สูง 1.11
STOR 45Kจาก 64K (70%) สูง 1.06
VIRT ใชไมโครโพเซสเซอรที่ขายทั่วไป ปกติ 1.00
TURN เฉลี่ย 2 ชั่วโมง ปกติ 1.00
ACAP นักวิเคราะหอาวุโสที่เกง สูง 0.86
AEXP 3 ป ปกติ 1.00
PCAP โปรแกรมเมอรอาวุโสที่เกง สูง 0.86
VEXP 6 เดือน ต่ํา 1.10
LEXP 12 เดือน ปกติ 1.00
MODP เทคนิคสวนใหญใชมา 1 ป สูง 0.91
TOOL เครื่องมือระดับมินิคอมพิวเตอรพื้นฐาน ต่ํา 1.10
SCED 9 เดือน ปกติ 1.00
EAF 1.35

6.3.3.2 COCOMOII
โบแอมไดพิจารณาถึงการเปลี่ยนแปลงการพัฒนาซอฟตแวรหรือระบบงาน
ในปจจุบันที่มวี ิธีการพัฒนาที่แตกตางไปจากป ค.ศ. 1981 COCOMO81 มีสมมติฐานวา ซอฟตแวร
พัฒนาตามกระบวนการแบบน้ําตก และซอฟตแวรสวนใหญพัฒนาจากจุดเริ่มตนทั้งหมด เมือ่ มีการ
เปลี่ยนวิธีการพัฒนาซอฟตแวรอยางมากมายตั้งแตรุนแรกที่นาํ เสนอผูใ ช เชน การพัฒนาใชวิธีการ
พัฒนาตนแบบ (prototyping) การพัฒนาโดยการนําซอฟตแวรแตละสวนมาประกอบเปนระบบงาน
(components composition) หรือการพัฒนาดวยภาษารุนที่ 4 (4th generation language) ระบบงาน
เดิมที่มีอยูถ ูกรือ้ ปรับเพื่อสรางซอฟตแวรใหม ดังนัน้ ตัวแบบที่กาํ หนดใน COCOMOI จึงไมเหมาะสมกับ
วิธีการพัฒนาแบบใหมดังกลาว โบแอมจึงทําการวิจัยและนําเสนอตัวแบบใหมสาํ หรับการประมาณการ
แรงงาน ตัวแบบใหมจึงเรียก COCOMOII ซึ่งมี 3 ตัวแบบ COCOMOII เปนตัวแบบสําหรับการประมาณ
การเปนระยะๆ ตามรายละเอียดของขอมูลที่ผูจัดการโครงการ/นักวิเคราะหระบบไดรับ ซึ่งจะทําใหการ
ปรับคาแรงงานที่ตองใชใกลเคียงความเปนจริงมากยิง่ ขึน้

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-27

ตัวแบบ 3 ระดับของ COCOMOII มีดังนี้

• ระยะการพัฒนาตนแบบชวงตน (The Early Prototyping Level)
เปนตัวแบบที่ใชสําหรับการประมาณแรงงานในชวงเริ่มตนของโครงการที่
ผูจัดการโครงการ/นักวิเคราะหระบบยังไมทราบรายละเอียดของระบบงาน
แตจะทราบฟงกชันงานคราวๆ การประมาณการจึงใชอ็อบเจกตพอยท
(object points) ตัวแบบนี้จึงเหมาะกับการพัฒนาระบบดวยวิธกี ารใช
ซอฟตแวรตางๆ ที่มีมาประกอบกัน
• ระยะการออกแบบชวงตน (The Early Design Level)
เปนตัวแบบที่ใชสําหรับประมาณแรงงาน เมื่อผูจัดการโครงการ/นักวิเคราะห
ระบบ ทราบความตองการแลว การประมาณนี้จะประมาณการโดยใชฟงกชัน
พอยทแลวปรับเปน LOC และมีชุดของปจจัยที่ไมยุงยากมาใชในการปรับ
คาที่ไดประมาณการ
• ระยะหลังจากการออกแบบสถาปตยกรรม (The Post-architecture
Level)
เปนตัวแบบที่ใชในการประมาณการขนาดของซอฟตแวรใหแมนยํามากขึ้น
หลังจากออกแบบสถาปตยกรรมระบบงานแลว ตัวแบบของระดับนี้มีสูตร
เชนเดียวกับระดับการออกแบบระยะแรก แตมีชุดของปจจัยที่เขมขนมาปรับ
คาอีกชุด

การประมาณการแรงงานสําหรับระยะการพัฒนาตนแบบชวงตน
ตัวแบบการคํานวณแรงงาน คือ
แรงงาน (PM) = (NOP x (1 - %reuse/100))/PROD
โดยที่
PM = แรงงาน (คน-เดือน)
NOP = อ็อบเจกตพอยทใหม (New Object Point)
%reuse = รอยละของซอฟตแวรทนี่ าํ กลับมาใชใหม
PROD = ผลผลิตเพิ่ม

ขั้นตอนการคํานวณ
1. นับจํานวนอ็อบเจกตพอยทที่ประกอบเปนระบบงาน อ็อบเจกตไดแก
จอภาพ รายงาน และสวนประกอบที่เปน 3 GL (3 General language)

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-28

2. จัดระดับของอ็อบเจกตแตละอ็อบเจกต ซึ่งมี 3 ระดับคือ งาย ปานกลาง

และยาก การจัดวาแตละอ็อบเจกตจะอยูร ะดับใดนั้น ใหพิจารณาตาม
ประเภทของอ็อบเจกตออกเปน 2 ประเภทคือ จอภาพ และรายงาน ระดับ
ของอ็อบเจกตแตละประเภทไดแสดงในตารางที่ 6.14 กรณีที่อ็อบเจกต
เปนจอภาพจะพิจารณาจํานวนทรรศนะ (view) ที่จอภาพนั้นตองใชในการ
แสดง และจํานวนแหลงของตารางขอมูล สวนกรณีที่อ็อบเจกตเปน
รายงาน จะตองพิจารณาจํานวนสวน (section) ที่รายงานนัน้ ตองมี และ
จํานวนแหลงของตารางขอมูลเชนเดียวกับกรณีที่อ็อบเจกตเปนจอภาพ

ตารางที่ 6.14 ตารางการจัดระดับความยาก-งายของอ็อบเจกต

จอภาพ รายงาน
จํานวน # และแหลงของตารางขอมูล จํานวน # และแหลงของตารางขอมูล
ทรรศนะ รวมทั้งหมด รวมทั้งหมด รวม สวน รวมทั้งหมด รวมทั้งหมด รวม
< 4 (<2 srvr < 8 (<2/3 ทั้งหมด 8+ < 4 (<2 srvr < 8 (<2/3 ทั้งหมด 8+
< 3 clnt) srvr < 3-5 (<3 srvr >5 < 3 clnt) srvr < 3-5 (<3 srvr >5
clnt) clnt) clnt) clnt)
<3 งาย งาย ปานกลาง 0 หรือ 1 งาย งาย ปานกลาง
3-7 งาย ปานกลาง ยาก 2 หรือ 3 งาย ปานกลาง ยาก
>8 ปานกลาง ยาก ยาก 4+ ปานกลาง ยาก ยาก
srvr คือ เครื่องบริการที่มีตารางขอมูลที่ใชรวมกันเพื่อออกรายงาน หรือแสดงจอภาพ
clnt คือ เครื่องลูกขายที่มีตารางขอมูลที่ใชรวมกันเพื่อออกรายงาน หรือแสดงจอภาพ

3. ใหนา้ํ หนักความยาก-งายของแตละอ็อบเจกตเพื่อสทอนใหเห็นถึงแรงงาน
ที่ตองใชในการสรางอ็อบเจกตนั้นๆ น้ําหนักความยาก-งายของอ็อบเจกต
แตละประเภทแสดงในตารางที่ 6.15

ตารางที่ 6.15 น้ําหนักความยาก-งายของอ็อบเจกต

ความซับซอน-น้ําหนัก
ประเภทอ็อบเจกต
งาย ปานกลาง ยาก
จอภาพ 1 2 3
รายงาน 2 5 8
3GL Component 10

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-29

4. ใหหาผลรวมของอ็อบเจกตพอยทหลังจากถวงน้าํ หนักของอ็อบเจกตพอยท
ทุกๆ ตัว
5. ประมาณรอยละของการนําโปรแกรมกลับมาใชใหม แลวคํานวณหาอ็อบ
เจกตพอยทใหมที่ตองพัฒนา (NOP) โดยมีสูตรการคํานวณดังนี้
NOP = (Object-Points) (100 - %reuse)/100
6. กําหนดระดับผลผลิตเพิ่ม (PROD) โดยที่ PROD สามารถหาไดจากตาราง
ที่ 6.16

ตารางที่ 6.16 ตารางแสดงการกําหนดระดับผลผลิตเพิ่ม (PROD)

ประสบการณและความสามารถของผูพัฒนา ต่ํามาก ต่ํา ปกติ สูง สูงมาก
วุฒิภาวะและความสามารถของ ICASE ต่ํามาก ต่ํา ปกติ สูง สูงมาก
PROD 4 7 13 25 50

7. ประมาณการแรงงานที่ตองใช (PM) = NOP/PROD

การประมาณการแรงงานสําหรับระยะการออกแบบชวงตน
ตัวแบบการประมาณแรงงานสําหรับระดับนี้คือ
แรงงาน (effort) = 2.94 x SizeB x M+ PMauto โดยที่
Size คือ ขนาดของระบบงานวัดเปนกิโลบรรทัด (KLOC) ซึ่งคํานวณไดจาก
จํานวนฟงกชนั พอยท
M คือ ผลคูณของตัวคูณแรงงาน (effort multipliers) เพื่อปรับคาของ
แรงงานใหสอดคลองกับลักษณะของระบบงานและโครงการ ตัวคูณมี
ทั้งหมด 7 ตัวคือ
ƒ RCPX ความนาเชื่อถือและความซับซอนของระบบงาน
(reliability and complexity)
ƒ RUSE โปรแกรมที่นาํ กลับมาใชใหม (reuse required)
ƒ PDIF ความยากของแพล็ตฟอรม (platform difficulty)
ƒ PERS ความสามารถของบุคคลากร (personal capability)
ƒ PREX ประสบการณของบุคลากร (personal experience)

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-30

ƒ FCIL สิ่งอํานวยความสะดวกในการพัฒนาระบบงาน
(support facilities)
ƒ SCED แรงกดดันจากตารางเวลาการพัฒนา (schedule)
M = PERS x RCPX x RUSE x PDIF x PREX x FCIL x SCED
ตัวคูณแรงงานมีคาดังในตารางที่ 6.17

ตารางที่ 6.17 ระดับของตัวขับเคลื่อนคาใชจายสําหรับระยะการออกแบบชวงตน

ระดับ
ตัวขับเคลื่อนคาใชจาย ต่ําเปน ต่ํามาก ต่ํา ปกติ สูง สูงมาก สูงเปน
พิเศษ พิเศษ
RCPX 0.49 0.60 0.83 1.00 1.33 1.91 2.72
RUSE 0.95 1.00 1.07 1.15 1.24
PDIF 1.00 1.00 1.00
PERS 2.12 1.62 1.26 1.00 0.83 0.63 0.50
PREX 1.59 1.33 1.12 1.00 0.87 0.74 0.62
FCIL 1.43 1.30 1.10 1.00 0.87 0.73 0.62
SCED 1.43 1.14 1.00 1.00 1.00

PMauto คือ แรงงานที่ตองใชสําหรับการแปลโปรแกรมอัตโนมัติ (automatic

translation) ซึ่งตองคํานวณดวยสูตรดังนี้
Adapted KLOC x (AT/100)
PMauto = โดยที่
ATPROD
Adapted KLOC คือ จํานวนคําสัง่ ของโปรแกรมที่นาํ มาใชใหมและตอง
เปลี่ยนแปลง โดยมีหนวยนับเปนกิโล ดังนัน้ Adapted
KLOC นี้จะไมรวมใน Size เพื่อไมใหเกิดการนับซ้าํ
AT (automated translation) คือ รอยละของคําสั่งที่นาํ มาปรับรื้อ
(reengineering) โดยการแปลอัตโนมัติ คาของ AT แสดง
ในตารางที่ 6.18
ATPROD คือ คาผลผลิตเพิ่มโดยปริยาย (default productivity
value) สําหรับการแปลงโปรแกรมอัตโนมัติ ซึ่งมีคา 2400
คําสั่งตอคน-เดือน

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-31

ตารางที่ 6.18 รอยละของโปรแกรมทีน่ ํามาปรับรื้อ

เปาหมายการปรับรื้อ AT (รอยละการแปลอัติโนมัติ)
การประมวลผลแบบกลุม (batch processing) 96%
กลุมพรอมกับ SORT (batch with SORT) 90%
กลุมพรอมกับ DBMS (batch with DBMS) 88%
กลุม SORT, DBMS (batch, SORT, DBMS) 82%
เชิงโตตอบ (Interactive) 50%

B มีคาระหวาง 0.91 – 1.23 ขึ้นอยูกับความใหมของโครงการ ความ

ยืดหยุน ของการพัฒนา กระบวนการแกไขความเสีย่ ง ความเกาะติดของ
ทีมงาน และระดับวุฒิภาวะของกระบวนการขององคการ การหาคา B
ทําไดดังนี้
5
B = 0.91 + 0.01 x ∑ SF
j=1
j โดยที่

SFj (scale factors) คือ ปจจัยที่มีผลตอการประหยัดแรงงานจากขนาดของ

ระบบที่มีขนาดแตกตางกัน j มีคาตั้งแต 1 ถึง 5 ความหมายและคาของ
SF ทั้ง 5 ตัวแสดงในตารางที่ 6.19 และ 6.20 ตามลําดับ สวนการ
กําหนดระดับของ SF แตละตัวแสดงในตารางที่ 6.21-6.24

ตารางที่ 6.19 ความหมายของปจจัยที่มีผลตอการประหยัดแรงงาน

ขนาดปจจัย
PREC (precedentedness)
FLEX (development flexibility)
RESL (architecture/risk resolution)
TEAM (team cohesion)
PMAT (process maturity)
ความหมาย
ระดับความคลายคลึงกับโครงการที่ไดพัฒนามาแลว
ระดับความยืดหยุนของการพัฒนาซอฟตแวร
ขนาดการวิเคราะหความเสี่ยงมากนอยแคไหน
ทีมงานพัฒนารูจักและทํางานรวมกันมากนอยแคไหน
กระบวนการพัฒนามีวุฒิภาวะระดับใด ซึ่งขึ้นอยูกับ CMM

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-32

ตารางที่ 6.20 คาของปจจัยที่มีผลตอการประหยัดแรงงาน

ปจจัย ต่ํามาก ต่ํา ปกติ สูง สูงมาก สูงเปนพิเศษ
PREC ไมคุนเคยเลย ไมคุนเคยเปน คุนเคยบาง โดยทั่วไป คุนเคยอยาง คุนเคยอยาง
สวนใหญ คุนเคย มาก ทะลุปรุโปรง
6.20 4.96 3.72 2.48 1.24 0.00
FLEX ไมยืดหยุน ยืดหยุนเปนครั้ง ยืดหยุนบาง โดยทั่วไป ตรงกันบาง เปาหมายทั่วไป
คราว ตรงกัน
5.07 4.05 3.04 2.03 1.01 0.00
RESL นอย (20%) บาง (40%) บอย (60%) ทั่วๆ ไป (75%) สวนใหญ เต็ม (100%)
(90%)
7.07 5.65 4.24 2.83 1.41 0.00
TEAM ปฏิสัมพันธกัน ปฏิสัมพันธยาก ปฏิสัมพันธกัน รวมมืออยาง รวมมืออยางสูง ปฏิสัมพันธ
ยากมาก บาง อยางธรรมดา มาก อยางไรรอยตอ
5.48 4.38 3.29 2.19 1.10 0.00
PMAT CMM ระดับ 1 CMM ระดับ 1 CMM ระดับ 2 CMM ระดับ 3 CMM ระดับ 4 CMM ระดับ 5
ต่ํา สูง
7.80 6.24 4.68 3.12 1.56 0.00

ตารางที่ 6.21 การจัดระดับ PREC

ต่ํามาก ต่ํามาก ปกติ/สูง สูงเปนพิเศษ
ความเขาใจวัตถุประสงคของระบบงาน ทั่วไป มาก ทะลุปรุโปรง
ประสบการณการทํางานกับระบบที่เกี่ยวของ ปานกลาง มาก ยาวนาน
การพัฒนาพรอมกันของฮารดแวรใหมที่เกี่ยวของและขั้นตอนการ อยางมาก ปานกลาง บาง
ปฏิบัติงาน
ตองการมีสถาปตยกรรมการประมวลผลขอมูล และอัลกอริทึมใหม มาก บาง นอย

ตารางที่ 6.22 การจัดระดับ FLEX

คุณลักษณะ ต่ํามาก ปกติ/สูง สูงเปนพิเศษ
ความตองการใหซอฟตแวรตรงกับความตองการที่กําหนดไวกอน สมบูรณ มาก ธรรมดา
ความตองการใหซอฟตแวรตรงกับขอกําหนดการเชื่อมประสาน สมบูรณ มาก ธรรมดา
ภายนอก
มีคุณลักษณะไมยืดหยุนทั้ง 2 อยางขางตนพรอมกับเงินที่จายคา สูง กลาง ต่ํา
ทําใหสมบูรณเร็วกวาที่กําหนด

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-33

ตารางที่ 6.23 การจัดระดับ RESL

ลักษณะ ต่ํามาก ต่ํา ปกติ สูง สูงมาก สูงเปน
พิเศษ
แผนจัดการความเสี่ยงระบุประเด็น ไมมี เล็กนอย บาง ธรรมดา สวนใหญ สมบูรณ
ความเสี่ยงที่วิกฤตทั้งหมด กําหนด
หลักไมลสําหรับการแกไขความ
เสี่ยงโดย PDR หรือ LCA
ตารางเวลา งบประมาณ และหลัก ไมมี นอย บาง ธรรมดา สวนใหญ สมบูรณ
ไมลภายในโดยผาน PDR หรือ
LCA ตรงกับแผนจัดการความเสี่ยง
รอยละของระยะเวลาการพัฒนาที่ 5 10 17 25 33 40
อุทิศใหกับการสรางสถาปตยกรรม
ตามวัตถุประสงคทั่วไปของระบบ
รอยละของเวลาที่นัก 20 40 60 80 100 120
สถาปตยกรรมระดับสูงใหกับ
โครงการ
มีเครื่องมือสนับสนุนสําหรับการ ไมมี นอย บาง ดี มาก สมบูรณ
แกไขประเด็นความเสี่ยง การ
พัฒนา และการทวนสอบ
ขอกําหนดสถาปตยกรรม
ระดับของความไมแนนอนของตัว อยางมาก มีนัยสําคัญ มาก บาง นอย นอยมาก
ขับเคลื่อนสถาปตยกรรมหลัก:
พันธกิจ การเชื่อมประสานกับผูใช,
COTS, ฮารดแวร, เทคโนโลยี,
ประสิทธิภาพ
จํานวนและความวิกฤตของ > 10 5-10 2-4 1 >5 <5
ประเด็นความเสี่ยง วิกฤต วิกฤต วิกฤต วิกฤต ไมวิกฤต ไมวิกฤต
PDR = การทบทวนการออกแบบซอฟตแวร (Product Design Review)
LCA = สถาปตยกรรมวงจรชีวิติ (Life Cycle Architecture)

ตารางที่ 6.24 การจัดระดับ TEAM

ลักษณะ ต่ํามาก ต่ํา ปกติ สูง สูงมาก สูงเปน
พิเศษ
ความสอดคลองกับวัตถุประสงคและวัฒนธรรมของ นอย บาง ธรรมดา มาก อยางมาก เต็ม
ผูมีสวนไดเสีย
ความสามารถ ความเต็มใจของผูมีสวนไดเสียเพื่อ นอย บาง ธรรมดา มาก อยางมาก เต็ม

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-34

ลักษณะ ต่ํามาก ต่ํา ปกติ สูง สูงมาก สูงเปน

พิเศษ
เอื้อกับวัตถุประสงคของผูมีสวนไดเสียคนอื่น
ประสบการณของผูมีสวนไดเสียในการปฏิบัติงาน ไมมี นอย นอย ธรรมดา มาก ยาวนาน
แบบเปนทีม
การสรางทีมผูมีสวนไดเสียเพื่อบรรลุวิสัยทัศนและ ไมมี นอย นอย ธรรมดา มาก ยาวนาน
คํามั่นรวมกัน

การประมาณการแรงงานระยะหลังจากการออกแบบ
ตัวแบบสําหรับการประมาณการแรงงานในระยะนี้นนั้ โบแอมใชตัวแบบพื้นฐาน
เชนเดียวกับตัวแบบของระดับการออกแบบชวงตน แตตัวคูณแรงงานแตกตางกัน (17 ตัว) สูตรพื้นฐาน
คือ
แรงงาน (Effort) หรือ PM = A x SizeB x M + PMauto
A = 2.94
การประมาณการจํานวนบรรทัดของโปรแกรมทั้งหมด (size) ขึ้นอยูกบั ปรับปรุง
โปรแกรมเดิมที่มีอยูใหกลับมาใชใหม (reuse) โดยมีสตู รการคํานวณหา KLOC ที่เทียบเทากับการเขียน
โปรแกรมใหมคือ

Equivalent KLOC หรือ Size = Adapted KLOC x (1-AT/100) x AAM โดยที่

AAF = (0.4 x DM) + (0.3 x CM) + (0.3 x IM)

Adapted KLOC คือ จํานวนคําสั่งของโปรแกรมที่นาํ มาใชใหมที่ตองปลี่ยนแปลง

AT คือ รอยละของคําสั่งทีน่ ํามาปรับรื้อ (reengineering) โดยการแปล
อัตโนมัติ คาของ AT แสดงในตารางที่ 6.18
AAM (adaptation adjustment modifier) คือ แรงงานที่ใชในการทําใหโปรแกรม
ที่ปรับแลวทํางานเขากับซอฟตแวรที่มีอยู ซึ่งขึน้ กับปจจัยอื่นๆ อีก

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-35

AAM มีสูตรการคํานวณ 2 สูตร การเลือกใชสูตรใดตองพิจารณาจาก

คา AAF วามีคามากกวา 50 หรือไม
AAF (adaptation adjustment factor) คือ ปริมาณแรงงานที่ใชปรับปรุง
ซอฟตแวรที่มอี ยูเดิม ประกอบดวยปจจัย 3 ตัว คือ DM CM และ IM
DM (percent design modified) คือ รอยละของการออกแบบที่ถกู แกไข เพื่อ
ปรับใหสอดคลองกับวัตถุประสงค หรือสภาวะแวดลอมใหม (เปนการ
ประมาณเชิงความคิดเห็น)
CM (percent code modified) คือ รอยละของคําสั่งทีถ่ ูกแกไข เพื่อปรับให
สอดคลองกับวัตถุประสงค หรือสภาวะแวดลอมใหม
IM (percent of integration required for adapted software) คือ รอยละของ
แรงงานที่ตองการเพื่อใชบูรณาการซอฟตแวรที่ถูกปรับใหเขากับ
ซอฟตแวรโดยรวม และเพื่อใชในการทดสอบซอฟตแวร โดยเทียบกับ
ปริมาณแรงงานในการบูรณาการและทดสอบซอฟตแวรขนาดเดียวกัน
ตามปกติ
AA (assessment and assimilation) คือ การประเมินวามอดูลของซอฟตแวรที่
นํากลับมาใชใหมเหมาะสมกับระบบงานหรือไม รวมทัง้ การบูรณาการ
คําอธิบายของมอดูลที่นาํ กลับมาใชใหมรวมเขากับคําอธิบาย
ซอฟตแวรภาพรวม AA ประมาณเปนรอยละ ตารางที่ 6.25 แสดง
อัตราการเพิม่ ของ AA

ตารางที่ 6.25 อัตราการเพิ่มของ AA

รอยละ ระดับของแรงงาน
0 ไมมี
2 การคนหามอดูลพื้นฐาน และเอกสาร
4 การประเมินและทดสอบมอดูลบางมอดูล เอกสาร
6 การประเมินและทดสอบมอดูลพอสมควร เอกสาร
8 การประเมินและทดสอบมอดูลอยางมากมาย เอกสาร

SU (software understanding increment) คือ การพยายามทําความเขาใจ

ซอฟตแวรที่มอี ยูเดิม ซึ่งพิจารณาจาก 3 ปจจัยคือ โครงสราง
(structure) ความชัดเจนของระบบงาน (application clarity) และ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-36

การอธิบายดวยตัวเอง (self description) คาของ SU หาไดจาก

ตารางที่ 6.26
UNFM (unfamiliarity with the software) คือ ความไมคุนเคยระบบงานของ
โปรแกรมเมอร อัตราของ UNFM แสดงในตารางที่ 6.27
ถา DM หรือ CM มีคา 0 คือ ไมมีการปรับปรุงซอฟตแวร SU จะไมตอ งใชคือ มีคา
เปน 0 เชนกัน

ตารางที่ 6.26 อัตราความเขาใจซอฟตแวร

ต่ํามาก ต่ํา ปกติ สูง สูงมาก
โครงสราง การเชื่อมติดของ การเชื่อมติดของ โครงสรางดี การเชื่อมติดของ มีความเปนมอดูล
คําสั่งในมอดูลต่ํา คําสั่งในมอดูล พอควร มีจุดออน คําสั่งในมอดูลสูง
มาก การซอน
มาก การเชื่อมกัน ปานกลาง-ต่ํา บางที่ การเชื่อมกัน สารสนเทศใน
ระหวางมอดูลสูง การเชื่อมกัน ระหวางมอดูลต่ําขอมูล/โครงสราง
โปรแกรมยุงเหยิง ระหวางมอดูลสูง ควบคุม
ความชัดเจน ไมสอดคลอง มีความสัมพันธ มีความสัมพันธ มีความสัมพันธดี มีความสัมพันธ
ของ ระหวางโปรแกรม บางระหวาง ปานกลางระหวาง ระหวางโปรแกรม ระหวางโปรแกรม
ระบบงาน และระบบงานที่ โปรแกรมและ โปรแกรมและ และระบบงานที่ และระบบงานที่
กําลังพัฒนา ระบบงานที่กําลัง ระบบงานที่กําลัง กําลังพัฒนา กําลังพัฒนาอยาง
พัฒนา พัฒนา ชัดเจน
การอธิบาย โปรแกรมคลุมเครือ มีคําอธิบาย มีคําอธิบาย มีคําอธิบาย โปรแกรมอธิบาย
ดวยตนเอง เอกสารไมครบ ไม โปรแกรมบางสวน โปรแกรมและ โปรแกรมดี เอกสาร ตัวเอง เอกสาร
ทันสมัย ไมชัดเจน เอกสารมี เอกสารปานกลาง มีประโยชน มี ทันสมัย ไดรับการ
ประโยชนบาง จุดออนบางสวน จัดการดี
อัตราของ SU 50 40 30 30 10

ตารางที่ 6.27 อัตราของUNFM

อัคราเพิ่ม UNFM ระดับความไมคุนเคย
0.0 คุนเคยโดยสมบูรณ
0.2 สวนใหญคุนเคย
0.4 คอนขางคุนเคย
0.6 คุนเคย
0.8 สวนใหญใมคุนเคย
1.0 ไมคุนเคยเลย

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-37

โบแอมไดเสนอแนวทางการประมาณปจจัยตางๆ สําหรับซอฟตแวรทถี่ ูกปรับเขาสู

สภาวะแวดลอมใหม COCOMOII ไดแบงโปรแกรมออกเปน 4 กลุม สวนคาของ
พารามิเตอรตางๆ ของแตละกลุมแสดงในตารางที่ 6.28 กลุมของโปรแกรมมี
ดังนี้คือ
• โปรแกรมใหม (new code) คือ ซอฟตแวรที่พัฒนาใหมทั้งหมดตั้งแต
เริ่มตน (scratch)
• โปรแกรมที่ปรับ (adapted code) คือ โปรแกรมทีป่ รากฏอยูกอน
(preexisting code) ไดรับการปรับแกเพื่อใชงานกับระบบใหม
• โปรแกรมนํากลับมาใชใหม (reused code) คือ โปรแกรมที่ปรากฏอยู
กอนไมมีการปรับแก หรือโปรแกรมเดิมทีม่ ีอยู (as is) โปรแกรมกลุมนี้
เปรียบเสมือนคําสั่งที่อยูในกลองดํา เพียงแตนําโปรแกรมนั้นมาติดตั้ง
(plug) แลวใชงาน
• โปรแกรมที่มีขาย (off-the-shelf software หรือ COTS) โดยทั่วไป
ซอฟตแวรของกลุมนี้จัดไวเชนเดียวกับกลุม ที่ 3 ถาไมมกี ารปรับแก สิง่
ที่แตกตางคือ โปรแกรมกลุมนี้มีคําสัง่ ใหมที่นาํ มาใชรว มกัน

ตารางที่ 6.28 แนวทางการกําหนดพารามิเตอรของซอฟตแวรที่ปรับเขาสูส ภาวะแวดลอมใหม

พารามิเตอร
กลุมของโปรแกรม
DM CM IM AA SU UNFM
ไมสามารถ
โปรแกรมใหม
ใชได
0-100+%
0-100%
0-100% โดยปกติ IM
ธรรมดาแลว
โปรแกรมที่ปรับ โดยปกติ > ปานกลาง 0-8% 0-50% 0-1
>DM และ
0% และสามารถ
ตอง > 0%
>100%
0-100%
โปรแกรมนํากลับมาใช ยากที่จะเปน
0% 0% 0-8% ไมสามารถใชได
ใหม 0% แตอาจ
นอยมากๆ
โปรแกรมที่มีขาย 0% 0% 0-100% 0-8% ไมสามารถใชได

สวนการหาคา M ของตัวแบบระดับนี้จะประกอบดวยตัวคูณแรงงานทีม่ ากกวา

ของระดับการออกแบบระยะแรก ตัวคูณของระดับหลังจากการออกแบบสถาปตยกรรมนัน้ โบแอมได

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-38

กําหนดมใหมที ั้งหมด 17 ตัว ความหมายของตัวคูณแรงงานและการกําหนดระดับของตัวคูณแรงงาน

ทั้งหมด แสดงในตารางที่ 6.29 และ 6.30 ตามลําดับ

ตารางที่ 6.29 ความหมายของตัวคูณแรงงาน

ตัวคูณแรงงาน ความหมาย
RELY (ความตองการ ระดับของผลกระทบที่เกิดขึ้น ถาซอฟตแวรทํางานไมไดอยางที่ตั้งใจ ถามีผลกระทบเพียงแค
ดานความเชื่อถือของ ทํางานไมสะดวก ระดับของตัวคูณจะต่ํามาก แตถาผลกระทบนั้นทําใหเกิดความเสี่ยงที่เปน
ระบบงาน) อันตรายตอชีวิตของมนุษย ระดับของตัวคูณจะสูงมาก
DATA (ขนาด เปนตัวคูณที่วัดผลกระทบที่เกิดขึ้นจากการทดสอบฐานขอมูลที่มีขนาดใหญ เนื่องจาก
ฐานขอมูล) แรงงานที่ตองใชสรางขอมูลทดสอบโปรแกรม โดยพิจารณาจากสัดสวนของขนาดของ
ฐานขอมูลที่กําลังทดสอบ (หนวยเปนไบต) กับขนาดของโปรแกรม (LOC)
CPLX (ความซับซอน ความซับซอนของซอฟตแวรพิจารณาจากการปฏิบัติงาน 5 ดานคือ ดานการควบคุม ดานการ
ของระบบงาน) คํานวณ ดานการอิงกับอุปกรณตอพวงกับคอมพิวเตอร ดานการจัดการขอมูล และดานการ
จัดการการโตตอบกับผูใช การกําหนดระดับพิจารณาจากตารางที่ 6.12
RUSE (พัฒนาขึ้นมา ระดับแรงงานที่ตองใชเพื่อสรางสวนประกอบ สําหรับการนํากลับมาใชใหมของโครงการ
เพื่อใหสามารถนํา ปจจุบันและอนาคต แรงงานนี้ตองใชเพื่อการออกแบบใหใชไดทั่วไป การเขียนเอกสาร การ
กลับมาใชใหมได) ทดสอบที่ตองมีการทดสอบอยางมากเพื่อใหแนใจวาสามารถนําไปใชกับระบบงานอื่นๆ ได
DOCU (เอกสารตรงกับ ความเหมาะสมของเอกสารของโครงการตอความจําเปนของวงจรชีวิตการพัฒนาซอฟตแวร
ความตองการของวงจร ถาวงจรชีวิตการพัฒนาจํานวนมากมีความจําเปนตองมีเอกสาร ระดับของ DOCU จะต่ํามาก
ชีวิต) แตถามีความจําเปนอยางยิ่ง ระดับของ DOCU จะสูงมาก ๆ เชนกัน
TIME (ขอจํากัดดาน เวลาของคอมพิวเตอรที่มีใหระบบใชทํางาน ถาเวลานอยกวา 50% TIME จะมีระดับปกติ แต
เวลาการประมวลผล) ถาเวลาของคอมพิวเตอรมีใหถึง 95% TIME จะจัดวาสูงมากๆๆ
STOR (ขอจํากัดดาน รอยละของพื้นที่ของหนวยเก็บหลักที่ใหระบบงานใช
เวลาการประมวลผล)
PVOL (การเปลี่ยน แพลตฟอรมของระบบเปลี่ยนแปลงบอยหรือไม ถาไมคอยเปลี่ยน PVOL จะสูงมาก แตถา
แพลตฟอรม) เปลี่ยนบอย คา PVOL จะต่ํามาก แพล็ตฟอรมหมายถึง ฮารดแวร ซอฟตแวร
(ระบบปฏิบัติการ ระบบจัดการฐานขอมูล ฯลฯ)
ACAP (ความสามารถ ระดับความสามารถของทีมนักวิเคราะหระบบ โดยพิจารณาจากความสามารถ ประสิทธิภาพ
ของนักวิเคราะหระบบ) ความสามารถในการสื่อสารและประสานงาน ถาระดับอยูที่เปอรเซ็นตไทล 15 ระดับของ
PCAP จะต่ํามาก แตถาอยูที่เปอรเซ็นตไทลที่ 90 ระดับของ PCAP จะจัดวาสูงมาก
PCAP (ความสามารถ ระดับความสามารถของทีมโปรแกรมเมอร โดยพิจารณาจาก ความสามารถ ประสิทธิภาพ
ของโปรแกรมเมอร) ความสามารถในการสื่อสารและประสานงาน ถาระดับอยูที่เปอรเซ็นตไทล 15 ระดับของ
PCAP จะต่ํามาก แตถาอยูที่เปอรเซ็นตไทลที่ 90 ระดับของ PCAP จะจัดวาสูงมาก

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-39

ตัวคูณแรงงาน ความหมาย
PCON (ความตอเนื่อง รอยละการลาออกจากงานของพนักงานโครงการใน 1 ป ถาประมาณ 3% แสดงวาการ
ของบุคลากร) ทํางานมีความตอเนื่องสูงมาก แตถา 48% แสดงวาความตอเนื่องต่ํามาก
APEX (ประสบการณใน ระดับประสบการณในระบบงานที่จะพัฒนาของทีมงาน ถาทีมงานมีประสบการณต่ํากวา 2
ระบบงาน) เดือน ระดับของ APEX ต่ํา และจะสูงมาก ถาทีมมีประสบการณ 6 ป หรือมากกวา
PLEX (แพลตฟอรม) ระดับประสบการณในแพลตฟอรมที่ใชในการพัฒนาระบบงาน
LTEX (ประสบการณใน ระดับประสบการณในการใชเครื่องมือในการวิเคราะห ออกแบบ และพัฒนาระบบงาน
การเครื่องมือและภาษา)
TOOL (การใชเครื่องมือ ความสามารถ อายุและการบูรณาการของเครื่องมือที่ใช
ในการพัฒนาซอฟตแวร)
SITE (พัฒนาสําหรับ สถานที่ที่ตั้งของทีมงานมีหลายที่ ซึ่งจะพิจารณาจาก 2 ปจจัยคือ ลักษณะของสถานที่ของ
ติดตั้งหลายที่) ทีมงานวาเปนระหวางประเทศ ระหวางเมือง ภายในอาคารเดียวกัน หรือสวนอีกปจจัยคือ
การสนับสนุนการสื่อสารระหวางกัน เชน ไปรษณีย โทรศัพท การสื่อสารทางอิเลคโทรนิกส
การปฎิสัมพันธแบบสื่อผสม เปนตน
SCED (ระยะเวลาที่ รอยละการลด-ขยายระยะเวลาการพัฒนาจากระยะเวลาอยางนอยที่สุดที่ตองใชของโครงการ
ตองการใชในการพัฒนา
ระบบงาน)

ตารางที่ 6.30 ระดับของตัวขับเคลื่อนคาใชจาย

ระดับ
ตัวขับเคลื่อนคาใชจาย ต่ํามาก ต่ํา ปกติ สูง สูงมาก สูงเปน
พิเศษ
RELY 0.82 0.92 1.00 1.10 1.26
DATA 0.90 1.00 1.14 1.28
CPLX 0.73 0.87 1.00 1.17 1.34 1.74
RUSE 0.95 1.00 1.07 1.15 1.24
DOCU 0.81 0.91 1.00 1.11 1.23
TIME 1.00 1.11 1.29 1.23
STOR 1.00 1.05 1.17 1.46
PVOL 0.87 1.00 1.15 1.30
ACAP 1.42 1.19 1.00 0.85 0.71
PCAP 1.34 1.15 1.00 0.88 0.76
PCON 1.29 1.12 1.00 0.90 0.81
APEX 1.22 1.10 1.00 0.88 0.81

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-40

ระดับ
ตัวขับเคลื่อนคาใชจาย ต่ํามาก ต่ํา ปกติ สูง สูงมาก สูงเปน
พิเศษ
PLEX 1.19 1.09 1.00 0.91 0.85
LTEX 1.20 1.09 1.00 0.91 0.84
TOOL 1.17 1.09 1.00 0.90 0.78
SITE 1.22 1.09 1.00 0.93 0.86 0.80
SCED 1.43 1.14 1.00 1.00 1.00

การประมาณการเวลาที่ใชในการพัฒนาระบบงาน
ตัวแบบสําหรับการประมาณการเวลาที่ใชในการพัฒนาระบบงานของ
COCOMOII เปนตัวแบบที่ใชทงั้ ระยะการออกแบบชวงตน และระยะหลังจากการออกแบบ
สถาปตยกรรม ตัวแบบสําหรับการประมาณการเวลาคือ
( 0.48x (B- 0.91)) ⎤ SCED%
TDEV = ⎡ 3.67x ( PMNS ) x
⎢⎣ ⎥⎦ 100
โดยที่ TDEV = ระยะเวลาที่ตองใชในการพัฒนาซอฟตแวร
PMNS = ประมาณการแรงงาน (คน-เดือน) โดยไมรวมตัวคูณแรงงาน SCED
และ PMauto
SCED% = เปอรเซ็นตการลด-ขยายเวลาการพัฒนาของตัวคูณแรงงาน SCED
ดังที่กลาวมาแลว

6.3.4 ปญหาทีพ ่ บโดยทั่วไปของการประมาณการคาใชจายดานเทคโนโลยีสารสนเทศ

ถึงแมวา จะมีเทคนิคและเครือ่ งมือเพื่อชวยประมาณการคาใชจาย การประมาณการ
คาใชจายยังคงไมถูกตอง โดยเฉพาะโครงการที่เกี่ยวของกับเทคโนโลยีใหมหรือการพัฒนาซอฟตแวร
ทอม เดอมาโคร (Tom DeMarco) ไดใหเหตุผล 4 ขอที่การประมาณการคาใชจายไมถูกตอง และได
เสนอวิธกี ารบางวิธีเพื่อแกไขความไมถกู ตองเหลานี้
1. การประมาณการคาใชจายสําหรับโครงการซอฟตแวรขนาดใหญเปนงานที่
ซับซอน ตองใชความพยายามมาก การประมาณการหลายๆ โครงการตองทํา
อยางรวดเร็วและกอนที่จะไดความตองการของระบบที่ชดั เจน
2. คนทีท่ ําการประมาณการคาใชจายไมคอยมีประสบการณในการประมาณการ
โดยเฉพาะโครงการขนาดใหญ ถาองคการใชเทคนิคการบริหารโครงการที่ดี

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-41

และพัฒนาระบบการเก็บขอมูลของโครงการและการประมาณการทีน่ า เชื่อถือ
ขอมูลเหลานี้จะชวยปรับปรุงการประมาณการขององคการ การใหคนดาน
เทคโนโลยีสารสนเทศไดรับการอบรมและดูแลการประมาณการคาใชจายจะ
ชวยปรับปรุงประมาณการคาใชจายไดดีขึ้น
3. มนุษยมีใจโอนเอียงเขาหาการประมาณต่ํากวาที่ควรจะเปน เชน ผูม ีอาชีพทาง
เทคโนโลยีสารสนเทศอาวุโส หรือผูจัดการโครงการอาจทําการประมาณการ
ตามความสามารถของตน โดยลืมวายังมีคนทีม่ ีประสบการณนอยรวมทีม ซึ่ง
ตองใชเวลามากขึ้น นอกจากนี้ ผูประมาณการอาจลืมวา ถาโครงการขนาด
ใหญ องคการจะมีคาใชจา ยพิเศษสําหรับการบูรณาการและการทดสอบ
4. ผูบริหารอยากไดคาประมาณการที่ชว ยใหองคการชนะการประมูลสัญญา
ขนาดใหญ หรือใหไดรับเงินสนับสนุนจากองคการ ดังนัน้ ผูบริหารระดับสูงหรือ
ผูมีสวนไดเสียตองการไดระยะเวลาหรือคาใชจายทีน่ อยกวาคาประมาณการ
ผูจัดการโครงการตองประมาณการคาใชจา ยและเวลาทีถ่ ูกตอง แลวใชทักษะ
การตอรองและความเปนผูน าํ เพื่อยืนยันคาที่ประมาณการได

6.3.5 ตัวอยางการประมาณการคาใชจาย
วิธีการที่ดีที่สดุ ในการเรียนรูวากระบวนการประมาณการคาใชจายทําอยางไรคือ
การศึกษาจากตัวอยางการประมาณการคาใชจาย การประมาณการทุกโครงการไมเหมือนกัน เพราะแต
ละโครงการมีความแตกตางกัน
กอนเริ่มการประมาณการคาใชจาย เราตองรวบรวมขอมูลเกี่ยวกับโครงการใหมากที่สุด
เทาที่จะมากได รวมทั้งกฎเกณฑพนื้ ฐานและสมมุติฐานสําหรับการประมาณการ ขอมูลตัวอยางการ
ประมาณการคาใชจายสําหรับโครงการสํารวจมีขอมูลมีดังนี้ (Schwalbe, 2007)
• โครงการนี้ไดมีการทําการศึกษารายละเอียดและพิสูจนแนวความคิดเพื่อแสดงให
เห็นความเปนไปไดที่จะพัฒนาฮารดแวรและซอฟตแวรที่นกั สํารวจตองการ และ
เชื่อมโยงอุปกรณใหมเขากับระบบสารสนเทศ การพิสูจนแนวความคิดของโครงการ
ทําโดยการใชอุปกรณมือถือตนแบบ (prototype) และซอฟตแวรที่มฟี ง กชนั พืน้ ฐาน
และเชื่อมโยงกับระบบกําหนดตําแหนงบนโลก (global positioning systems
(GPS)) และระบบฐานขอมูลอื่นๆ ของรัฐบาลทีน่ ักสํารวจใช องคการมีขอมูลเพื่อ
ชวยประมาณการคาแรงงาน โดยเฉพาะขอมูลสําหรับการพัฒนาซอฟตแวร รวมทั้ง
มีขอมูลบางสวนที่ชวยการประมาณการคาใชจายสําหรับอุปกรณมือถือ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-42

• เปาหมายหลักของโครงการคือ เพื่อผลิตอุปกรณมือถือ 100 เครื่อง ตามดวยการ

พัฒนาซอฟตแวร (โดยเฉพาะสวนเชื่อมประสานกับผูใช) ทดสอบระบบใหมใน
ภาคสนาม และอบรมการใชระบบใหมใหกับนักสํารวจจํานวน 100 คนจากเมืองที่
ไดคัดเลือก องคการคาดวาจะมีสัญญาใหผลิตอุปกรณจํานวนมากอันเนื่องจาก
ความสําเร็จของโครงการนี้
• โครงสรางจําแนกงานยอยสําหรับโครงการนี้มีดังนี้
1. การบริหารโครงการ
2. ฮารดแวร
2.1 อุปกรณมอื ถือ
2.2 เครื่องบริการ (server)
3. ซอฟตแวร
3.1 ซอฟตแวรที่มีใบอนุญาต
3.2 การพัฒนาซอฟตแวร
4. การทดสอบ
5. การอบรมและสนับสนุน
6. การสํารอง
• คาใชจายตองประมาณออกมาตามโครงสรางจําแนกงานยอยและตามเดือน
ผูจัดการโครงการจะรายงานความกาวหนาของโครงการโดยการใชการวิเคราะหมลู
คาที่ไดรับ (earned value)
• คาใชจายตองประมาณการออกเปนตัวเงิน เนื่องจากระยะเวลาโครงการ 1 ป จึงไม
ตองนําอัตราเงินเฟอมารวมในการประมาณการ
• โครงการจะถูกบริหารโดยสํานักงานโครงการรัฐบาล โครงการนีม้ ีผูจดั การโครงการ
ที่ทาํ งานครึ่งเวลา สมาชิกอีก 3 คนที่ชว ยบริหารสวนตางๆ ของโครงการ และใช
ความเชีย่ วชาญของพวกเขาในการพัฒนาซอฟตแวร การอบรม และการสนับสนุน
• โครงการเกีย่ วของกับการซื้ออุปกรณมือถือจากบริษทั ที่ผลิตอุปกรณมือถือตนแบบ
ถาใหผลิต 100 เครื่อง คาใชจายประมาณ 20,000 บาท ตอเครื่อง โครงการยัง
ตองการเครื่องบริการ (server) เพิ่มเติม 4 เครื่อง เพื่อใชงานซอฟตแวรสําหรับ
อุปกรณมือถือและสําหรับการบริหารโครงการ
• โครงการตองการมีซอฟตแวรที่มีใบอนุญาตสําหรับ GPS และระบบภายนอกอีก 3
ระบบ การพัฒนาซอฟตแวรประกอบดวยการพัฒนาสวนเชื่อมประสานกับผูใชแบบ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-43

กราฟกสสําหรับอุปกรณมือถือ ระบบชวยเหลือแบบออน-ไลน และมอดูลใหม

สําหรับการติดตามการดําเนินงานของนักสํารวจ
• อุปกรณและซอฟตแวรตองการการทดสอบอยางยืดยาว
• การอบรมจะเปนการอบรมที่มีผูสอนในสถานที่ตางๆ จํานวน 5 แหง โดยให
หนวยงานภายนอกทําการอบรม รวมถึงการพัฒนาเอกสารการอบรม การจัดเวลา
การอบรม การจัดใหมีความชวยเหลือ (help desk support) เปนเวลา 3 เดือน เมื่อ
นักสํารวจเริ่มการใชอุปกรณในภาคสนาม มีสมาชิกโครงการ 2 คนใหความ
ชวยเหลือการอบรม
• เพราะมีความเสี่ยงหลายประการที่เกี่ยวของกับโครงการ จึงใหมีการสํารอง
งบประมาณคิดเปนรอยละ 20 ของคาประมาณการทัง้ หมด
• ผูจัดการโครงการตองพัฒนาตัวแบบที่เปนคอมพิวเตอรสําหรับการประมาณการ
ซึ่งจะทําใหงา ยในการเปลี่ยนแปลงขอมูลนําเขา เชน จํานวนชัว่ โมงการทํางานของ
พนักงานในการทํากิจกรรมตางๆ หรืออัตราคาจาง

เพราะการประมาณการตองคาดการณออกมาตามโครงสรางจําแนกงานยอยและราย
เดือน ลําดับแรกทีมงานควรทบทวนรางตารางเวลาโครงการ และกําหนดสมมุติฐานเพิม่ เติมตามความ
จําเปน จากนัน้ ทีมงานประมาณการคาใชจายตามรายการในโครงสรางจําแนกงานยอยแตละรายการ
แลวกําหนดวันทีท่ ี่งานนัน้ จะเริ่มทํา ตอไปนี้คือ สมมุติฐานและขอมูลเพิ่มเติมสําหรับการประมาณการ
คาใชจายแตละหมวดของโครงสรางจําแนกงานยอย
1. การบริหารโครงการ: การประมาณคิดคาตอบแทนสําหรับผูจัดการโครงการ
รอยละ 50 ของเวลาของสมาชิกทีมงาน จํานวนชัว่ โมงของสมาชิกที่เหลือจะถูก
แบงเทาๆ กันระหวางการพัฒนาซอฟตแวร การทดสอบ และกิจกรรมการอบรม
ผูเชี่ยวชาญงบประมาณของโครงการเสนอใหผูจัดการโครงการไดอัตราคาเแรง
ชั่วโมงละ 4,000 บาท สําหรับสมาชิกทีมงานแตละคนทีท่ ํางานเต็มเวลาได
คาแรงชั่วโมงละ 2,000 บาท และทํางานเฉลี่ยเดือนละ 160 ชั่วโมง ดังนัน้ เวลา
ทั้งหมดสําหรับผูจัดการโครงการคือ 960 (160/2 X 12 = 960) คาใชจายของ
การบริหารโครงการยังรวมคาใชจายสําหรับสมาชิก โดยสมมุติวา จํานวน
ชั่วโมงการทํางานของสมาชิกทีมงานทุกคนรวม 160 ชั่วโมงตอเดือน (160 X
12 = 1,920) นอกจากนี้ ยังรวมคาแรงของพนักงานตามสัญญา ซึง่ ประมาณ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-44

การโดยคิดรอยละ 10 ของคาใชจายของการพัฒนาซอฟตแวรและการทดสอบ
(10%X(11,940,000+2,600,000))
2. ฮารดแวร
2.1 อุปกรณมือถือ: 100 เครื่อง ประมาณการโดยคูคาที่เครื่องละ
20,000 บาท
2.2 เครื่องบริการ: จํานวน 4 เครื่อง ประมาณการเครื่องละ 150,000
บาท ตามราคาเครื่องที่ไดซอื้ ลาสุด
3. ซอฟตแวร
3.1 ซอฟตแวรที่มีใบอนุญาต: มีการตอรองราคาซอฟตแวรสําหรับ
อุปกรณมือถือกับผูขายแตละราย เนื่องจากโอกาสที่จะมีสัญญา
มูลคาขนาดใหญคอนขางสูงถาระบบทํางานไดดี คาใชจายจึง
คาดวาจะต่ํากวาปกติ คาซอฟตแวรสําหรับอุปกรณมือถือคาดวา
เปน 6,000 บาท ตอเครื่อง
3.2 การพัฒนาซอฟตแวร: การประมาณการนี้จะใช 2 วิธี การ
ประมาณการคาแรง และฟงกชนั พอยท แลวเลือกใชคาประมาณ
การที่สงู สุด แตถาคาประมาณการตางกันมากกวารอยละ 20
ผูจัดการโครงการตองหาวิธกี ารที่สามมาทําการประมาณการ
4. การทดสอบ: ผลจากโครงการที่คลายคลึงกัน จึงคาดวาคาใชจา ยในการ
ทดสอบจะประมาณรอยละ 10 ของคาใชจา ยซอฟตแวรและฮารดแวร
5. การอบรมและการสนับสนุน: ผลจากโครงการที่คลายคลึงกัน การอบรมจะ
ประมาณตอคนที่เขารับการอบรม บวกคาเดินทาง คาใชจายตอคนที่เขารับการ
อบรม (100 คน) ประมาณ 15,000 บาท/คน สําหรับผูบรรยายและสมาชิก
ทีมงานมีคาเดินทางคือ 1,000 บาท/วัน/คน ซึ่งจะใชวันเดินทางทั้งหมด
ประมาณ 12 วัน คาแรงสําหรับสมาชิกทีมงานจะรวมในการประมาณการนี้
ดวย เพราะใหสมาชิกทีมงานชวยในการอบรมและใหการสนับสนุนหลังจาก
การอบรม ซึ่งประมาณ 300 ชั่วโมง
6. การสํารอง : เงินสํารองจะประมาณรอยละ 20 ของคาประมาณการทัง้ หมด

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-45

ตารางที่ 6.31 การประมาณการคาใชจา ยโครงการสํารวจ (ปรับปรุงจาก Schwalbe, 2007)

ผลรวม
# หนวย/ คาใชจาย/ ผลรวม % ของ
รายการโครงสรางงานยอย ยอย
ชม. บาท/ชม. (บาท) ผลรวม
(บาท)
1. การบริหารโครงการ 9,025,400 27.06%
1.1 ผูจัดการโครงการ 960 4,000 3,840,000
1.2 สมาชิกทีมงานโครงการ 1,920 2,000 3,840,000
1.3 พนักงานตามสัญญา (10% ของคา
1,345,400
พัฒนาซอฟตแวร และทดสอบ)
2. ฮารดแวร 2,600,000 7.80%
2.1 อุปกรณมอื ถือ 100 20,000 2,000,000
2.2 เครื่องบริการ 4 150,000 600,000
3. ซอฟตแวร 12,540,000 37.60%
3.1 ใบอนุญาต 100 6,000 600,000
3.2 การพัฒนาซอฟตแวร* 11,940,000
4. การทดสอบ (10% ของคาใชจาย
1,514,000 1,514,000 4.54%
ทั้งหมดของฮารดแวรและซอฟตแวร)
5. การอบรมและสนับสนุน 2,112,000 6.33%
5.1 คาใชจายของผูที่เขาอบรม 100 15,000 1,500,000
5.2 คาเดินทาง 12 1,000 12,000
5.3 สมาชิกทีมงานโครงการ 300 2,000 600,000
6. เงินสํารอง (20% ของคาประมาณ
5,558,280 5,558,280 16.67%
การทั้งหมด)
ประมาณการคาใชจายทั้งหมด 33,349,680

หลังจากนั้น ทีมงานโครงการพัฒนาตัวแบบคาใชจายโดยการใชขอมูลขางตน ตารางที่

6.31 แสดงสรุปคาใชจายตามโครงสรางจําแนกงานยอยจากขอมูลขางตน โครงสรางจําแนกงานยอย
แสดงในสดมภแรก บางรายการมีการจําแนกใหละเอียดมากขึน้ เชน หมวดการบริหารโครงการ
ประกอบดวย 3 รายการ เพื่อคํานวณคาใชจายสําหรับผูจัดการโครงการ สมาชิกทีมงาน และคูส ัญญา
เพราะคนเหลานี้จะทํากิจกรรมการบริหารโครงการบางกิจกรรม สวนสดมภอื่นๆ จะมีสดมภสําหรับใส
จํานวนชัว่ โมง และคาใชจายตอชั่วโมง
รายการพัฒนาซอฟตแวรมีเครื่องหมาย * คือ รายการที่อางถึงการประมาณการที่
ละเอียดในตารางที่ 6.32 ในตารางดังกลาวไดแสดงรายละเอียดการประมาณการพัฒนาซอฟตแวร ซึ่งมี
2 วิธีตามที่ไดกําหนดไว โดยวิธกี ารประมาณการคาแรงไดคาใชจายทัง้ หมด 11,940,000 บาท สวนวิธี

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-46

ฟงกชันพอยทประมาณการคาใชจายได 11,718,000 บาท จากการที่ไดกําหนดไววาคาใชจายการ

พัฒนาซอฟตแวรจะเลือกคาที่สงู สุดจากการประมาณการ 2 วิธี ดังนั้น คาใชจา ยการพัฒนาของโครงการ
สํารวจจึงมีคา 11,940,000 บาท
ผูจัดการโครงการควรใหหลายๆ คนทบทวนการประมาณการ หลังจากทีป่ ระมาณ
การคาใชจายทั้งหมดไดรับการอนุมัติ ทีมงานสามารถจัดสรรคาใชจายแตละเดือนตามตารางเวลาของ
โครงการและเวลาที่ตองใชคา ใชจายที่กาํ หนด

ตารางที่ 6.32 การประมาณการคาใชจา ยการพัฒนาซอฟตแวร (ปรับปรุงจาก Schwalbe, 2007)

คาใชจาย/ ผลรวมยอย
รายการโครงสรางงานยอย # ชม. การคํานวณ
บาท/ชม. (บาท)
1. การประมาณการพนักงาน
พนักงานตามสัญญา 3,000 2,700 8,100,000 3,000*2,700
สมาชิกทีมงาน 1,920 2,000 3,840,000 1,920*2,000
รวมประมาณการคาใชจายพนักงาน 11,940,000 ผลรวมของ 2 คาขางบน

ฟงกชัน
2. การประมาณการฟงกชันพอยท จํานวน น้ําหนัก การคํานวณ
พอยท
ขอมูลนําเขาจากภายนอก 10 6 60 10*4
แฟมขอมูลเชือ่ มประสานภายนอก 7 7 49 3*7
ขอมูลสงออกภายนอก 5 5 25 4*5
การสอบถามจากภายนอก 6 4 24 6*4
แฟมขอมูลเชิงตรรกะภายใน 9 10 90 7*10
ผลรวมของคาฟงกชันพอยท
ผลรวมฟงกชันพอยท 248
ขางตน
ปจจัยปรับคาฟงกชันพอยท 1.35 คาสมมุติ
ผลรวมฟงกชันพอยททั้งหมด 334.8
จํานวนชั่วโมงการทํางานทั้งหมด (14 ชม./1
4,687 334.8*14
ฟงกชันพอยท)
คาใชจาย/ชั่วโมง (2,500 บาท/ชั่วโมง) 2,500 คาที่ไดจากผูเชี่ยวชาญ
ผลรวมการประมาณการฟงกชันพอยท 11,718,000 4,687*2,500

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-47

6.4 การทํางบประมาณคาใชจาย
การทํางบประมาณคาใชจา ยโครงการเปนการจัดสรรประมาณการคาใชจายใหกับงานแตละ
งานตลอดทั้งโครงการ งานเหลานีย้ ึดตามโครงสรางจําแนกงานยอยของโครงการ ดังนัน้ โครงสราง
จําแนกงานยอยจึงเปนขอมูลนําเขาที่จาํ เปนสําหรับกระบวนการทํางบประมาณคาใชจาย เชนเดียวกัน
ขอกําหนดขอบเขตโครงการ ปฏิทนิ ทรัพยากร สัญญา และแผนการบริหารคาใชจายใหขอมูลที่เปน
ประโยชนตอการทํางบประมาณคาใชจาย การทํางบประมาณคาใชจายทําใหเกิดบรรทัดฐานคาใชจาย
ซึ่งเปนงบประมาณตามระยะเวลาที่ผูจัดการโครงการสามารถใชเพื่อวัดและติดตามประสิทธิภาพ
คาใชจาย การประมาณการคาใชจายสําหรับแตละกิจกรรมหลักของโครงการเปนการใหขอมูลพื้นฐาน
สําหรับการควบคุมคาใชจายโครงการแกผูจัดการโครงการและผูบริหารระดับสูง
การทํางบประมาณคาใชจา ย ผูจัดการโครงการตองพิจารณาการเปลี่ยนแปลงที่รองขอหรือการ
ทําใหความตองการชัดเจนดวย เพราะอาจมีผลใหปรับปรุงแผนการบริหารคาใชจา ย การทํางบประมาณ
คาใชจายยังเปนขอมูลแสดงความตองการเงินทุนโครงการ เชน บางโครงการตองมีเงินทุนทั้งหมดให
ตั้งแตเริ่มโครงการ แตโครงการอื่นตองการเงินทุนเปนชวงๆ บรรทัดฐานคาใชจา ยแสดงถึงความตองการ
เงินทุนในแตละเดือน องคการอาจตองทําการปรับบรรทัดฐานคาใชจา ยเพื่อหลีกเลีย่ งปญหาดานการเงิน
ถาความตองการเงินทุนนัน้ มากกวาที่องคการคาดวาจะสนับสนุนได

รูปที่ 6.6 บรรทัดฐานคาใชจายโครงการสํารวจ (ปรับปรุงจาก Schwalbe, 2007)

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-48

จากตัวอยางโครงการสํารวจที่ไดกลาวมาแลว ทีมงานโครงการอาจใชประมาณการคาใชจาย
จากตารางที่ 6.31 พรอมกับตารางเวลาโครงการและขอมูลอื่นๆ เพื่อจัดสรรคาใชจายสําหรับแตละเดือน
รูปที่ 6.6 เปนตัวอยางของบรรทัดฐานคาใชจายสําหรับโครงการนี้ ทีมงานควรบันทึกสมมุติฐานทีไ่ ดใชใน
การจัดทําบรรทัดฐานคาใชจา ย และใหผูเชีย่ วชาญหลายๆ คนทบทวน

6.5 การควบคุมคาใชจาย
การควบคุมคาใชจายโครงการเกี่ยวของกับการติดตามประสิทธิภาพคาใชจาย การประกันวา
การเปลี่ยนแปลงโครงการที่เหมาะสมเทานัน้ ที่จะนําเขามาทบทวนบรรทัดฐานคาใชจา ย รวมทั้งการแจง
ผูมีสวนไดเสียของโครงการทราบถึงการเปลี่ยนแปลงที่ไดรับอนุมัติและกระทบตอคาใชจาย ขอมูลนําเขา
สําหรับกระบวนการควบคุมคาใชจายประกอบดวย บรรทัดฐานคาใชจา ย รายงานผลการดําเนินงาน คํา
ขอเปลี่ยนแปลง และความตองการเงินทุน สวนผลลัพธของกระบวนการนี้คอื แผนบริหารโครงการที่
ปรับปรุงใหทนั สมัย และการปรับปรุงทรัพยสินกระบวนการเชิงองคการ เชน เอกสารบทเรียนที่ไดเรียนรู
เทคนิคและเครื่องมือหลายๆ อยางชวยการควบคุมคาใชจายโครงการ เชน ไมโครซอฟตโปร
เจค อยางไรก็ตาม องคการควรมีระบบควบคุมการเปลี่ยนแปลง เพื่อกําหนดขั้นตอนสําหรับการ
เปลี่ยนแปลงบรรทัดฐานคาใชจาย ระบบควบคุมการเปลี่ยนแปลงคาใชจายเปนสวนหนึ่งของระบบ
ควบคุมการเปลี่ยนแปลงที่บรู ณาการ เนื่องจากงานหลายๆ งานของโครงการไมเดินหนาเหมือนทีก่ าํ หนด
ในแผน ดังนัน้ ผูจัดการโครงการจึงควรมีการทบทวนคาใชจายที่ประมาณการ เครื่องมือที่มีประสิทธิภาพ
ที่ชวยควบคุมคาใชจายโครงการคือ การประชุมทบทวนผลการดําเนินงาน และการวัดผลการดําเนินงาน
คนจะทํางานดีขึ้น เมื่อรูวา ตองรายงานความกาวหนา หรือถูกตรวจสอบ ถึงแมวาจะมีวิธกี ารบัญชี
หลายๆ วิธีใหใชสําหรับการวัดผลการดําเนินงาน วิธกี ารควบคุมคาใชจายที่มีประสิทธิภาพมากๆ คือ
การบริหารมูลคาที่ไดรับ (earned value management (EVM))
การบริหารมูลคาที่ไดรับคือ เทคนิคการวัดผลการดําเนินโครงการที่ใชขอมูลขอบเขตงาน เวลา
และคาใชจาย ผูจัดการโครงการและทีมงานสามารถทราบวาโครงการทํางานไดตรงกับขอบเขต เวลา
และคาใชจายไดดีอยางไร โดยการใสขอมูลจริงแลวเปรียบเทียบกับบรรทัดฐาน บรรทัดฐานคือ แผน
โครงการตั้งแตแรกรวมกับการเปลี่ยนแปลงที่ไดรับอนุมตั ิ ขอมูลจริงประกอบดวยรายการของโครงสราง
จําแนกงานยอยทําไดสมบูรณหรือไม หรืองานทําไดสมบูรณประมาณเทาใด งานเริ่มตนและจบจริงๆ
เมื่อไร และคาใชจายจริงในการทําใหงานเสร็จสมบูรณ
ในอดีต การบริหารมูลคาที่ไดรับถูกนํามาใชกับโครงการรัฐบาลขนาดใหญ อยางไรก็ตาม ใน
วันนี้ มีบริษทั จํานวนมากและมากขึน้ ไดตระหนักถึงคุณคาของการใชเครื่องมือนี้ในการควบคุมคาใชจาย

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-49

การบริหารมูลคาที่ไดรับเกี่ยวพันกับการคํานวณพารามิเตอร 3 ตัวสําหรับแตละกิจกรรม หรือกิจกรรม

สรุปจากโครงสรางจําแนกงานยอยของโครงการ พารามิเตอรทั้ง 3 ตัวมีดังนี้
• ผลงานที่ควรทําไดตามแผนคิดจากราคางบประมาณ (budgeted cost of work
scheduled (BCWS)) หรือมูลคาที่ไดวางแผนไว (planned value (PV)) หรือ
งบประมาณของกิจกรรมหนึง่ เชน สมมติโครงการหนึง่ มีกิจกรรมสรุปของการซื้อ
และการติดตั้งเครื่องบริการเว็บเครื่องใหม ซึ่งใชเวลา 1 อาทิตย และคาแรงทัง้ หมด
10,000 บาท ดังนัน้ BCWS ของกิจกรรมนี้คือ 10,000
• คาใชจายจริงของงานที่ไดทาํ (actual cost of work performed (ACWP))
คาใชจายจริง (actual cost (AC)) คือ คาใชจายทางตรงและทางออมที่เกิดขึ้นเพื่อ
ทํากิจกรรมใหสําเร็จในชวงทีก่ ําหนด เชน สมมุติวาใชเวลา 2 อาทิตยและคาใชจาย
20,000 บาท สําหรับการซื้อและติดตั้งเครื่องบริการเว็บเครื่องใหม สมมุติวาอาทิตย
แรกคาใชจายที่เกิดขึ้นจริงคือ 15,000 บาท และคาใชจา ยจริงที่เกิดขึน้ อาทิตยที่ 2
คือ 5,000 บาท จํานวนเงินเหลานี้เปนคาใชจายจริงสําหรับกิจกรรมแตละอาทิตย

ตารางที่ 6.33 แสดงการคํานวณมูลคาที่ไดรับจริง (Schwalbe, 2007)

กิจกรรม อาทิตยที่ 1
มูลคาที่ไดรับ (EV) 10,000 x 75% = 7,500
มูลคาที่วางแผน (PV) 10,000
คาใชจายจริง (AC) 15,000
ความผันแปรของคาใชจายจริง จากงบประมาณตามแผน (CV) 7,500 – 15,000 = -7,500
ความผันแปรดานเวลาเทียบกับแผน (SV) 7,500 – 10,000 = -2,500
ดัชนีการดําเนินงานดานคาใชจาย (CPI) 7,500/15,000 = 50%
ดัชนีการดําเนินงานดานเวลา (SPI) 7,500/10,000 = 75%

• ผลงานทีท่ ําไดคิดจากราคางบประมาณ (budgeted cost of work performed

(BCWP)) หรือ มูลคาที่ไดรบั (earned value (EV)) คือ การประมาณการมูลคาของ
งานที่ไดทาํ โดยคํานวณตามงบประมาณคาใชจา ยของโครงการหรือกิจกรรมที่
วางแผนตั้งแตแรก และอัตราประสิทธิภาพของทีมงานที่กําลังทํางานโครงการหรือ
กิจกรรม อัตราประสิทธิภาพการทํางาน (rate of performance (RP)) คือ สัดสวน
ของงานทีเ่ สร็จจริงกับรอยละของงานที่วางแผนไววาจะทําเสร็จในชวงเวลาที่
กําหนด เชน สมมุติวา เวลาผานไป 1 อาทิตย การติดตั้งเครื่องบริการทําเสร็จไป 3

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-50

ใน 4 อัตราของการทํางานคือ รอยละ 75 (75/100) เพราะภายใน 1 อาทิตย

ตารางเวลาที่วางแผนไวบอกวางานควรเสร็จรอยละ 100 แตงานไดทาํ เสร็จไปเพียง
รอยละ 75 ตารางที่ 6.33 แสดงการคํานวณมูลคาที่ไดรับจริงหลังจากทํางานไป 1
อาทิตย ซึ่งคือ 7,500 บาท

ตารางที่ 6.34 เปนตารางที่สรุปสูตรที่ใชในการบริหารมูลคาที่ไดรับ ซึ่งประกอบดวยมูลคาที่

ไดรับ ความผันแปรของคาใชจายจริง จากงบประมาณตามแผน (CV) ความผันแปรดานเวลาเทียบกับ
แผน (SV) ดัชนีการดําเนินงานดานคาใชจา ย (CPI) ดัชนีการดําเนินงานดานเวลา (SPI) คาใชจายที่คาด
วาตองใชเพื่อใหงานเสร็จสมบูรณ (estimate at completion (EAC)) และเวลาที่คาดวาตองใชเพื่อให
งานเสร็จสมบูรณ (estimated time to complete)

ตารางที่ 6.34 แสดงสรุปสูตรที่ใชในการบริหารมูลคาที่ไดรับ (Schwalbe, 2007)

Term สูตร
มูลคาที่ไดรับ (EV) EV = PV to date x RP
ความผันแปรของคาใชจายจริง จากงบประมาณตามแผน (CV) CV = EV - AC
ความผันแปรดานเวลาเทียบกับแผน (SV) SV = EV - PV
ดัชนีการดําเนินงานดานคาใชจาย (CPI) CPI = EV/AC
ดัชนีการดําเนินงานดานเวลา (SPI) SPI = EV/PV
คาใชจายที่คาดวาตองใชเพื่อใหงานเสร็จสมบูรณ(EAC) EAC = งบประมาณคาใชจายที่ตั้งไวตั้งแตแรก
(BAC)/CPI
เวลาที่คาดวาตองใชเพื่อใหงานเสร็จสมบูรณ ระยะเวลาที่ตั้งไวตั้งแตแรก/SPI

• ความผันแปรของคาใชจายจริง จากงบประมาณตามแผน (CV)) คือ BCWP –

ACWP หรือ EV – AC ถาคา CV ติดลบหมายความวาการทํางานนั้นคาใชจาย
มากกวาทีว่ างแผนไว แตถาคา CV เปนคาบวกแสดงวาการทํางานนัน้ ใชคาใชจาย
นอยกวาที่วางแผนไว
• ความผันแปรดานเวลาเทียบกับแผน (SV) คือ BCWP – BCWS หรือ EV – PV ถาคา
SV ติดลบหมายความวาการทํางานนั้นใชเวลามากกวาทีว่ างแผนไว แตถาคา SV
เปนคาบวกแสดงวาการทํางานนั้นใชเวลานอยกวาที่วางแผนไว
• ดัชนีการดําเนินงานดานคาใชจาย (CPI) คือ สัดสวนระหวาง BCWP กับ ACWP
หรือ EV กับ AC ถาคา CPI มีคาเทากับ 1 หรือ 100% แสดงวาคาใชจายจริงเทากับ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-51

คาใชจายงบประมาณที่ตงั้ ไว ถาคา CPI นอยกวา 1 หรือ 100% แสดงวาโครงการใช

เงินมากกวางบประมาณ แตถาคา CPI มากกวา 1 หรือ 100% แสดงวาโครงการใช
เงินนอยกวางบประมาณที่ตงั้ ไว
• ดัชนีการดําเนินงานดานเวลา (SPI) คือ สัดสวนระหวาง BCWP กับ BCWSหรือ EV
กับ PV ถาคา SPI มีคาเทากับ 1 หรือ 100% แสดงวาโครงการทํางานไดตาม
ตารางเวลาที่วางแผนไว ถาคา SPI นอยกวา 1 หรือ 100% แสดงวาโครงการลาชา
กวาตารางเวลา แตถา คา SPI มากกวา 1 หรือ 100% แสดงวาโครงการทํางานไดเร็ว
กวาตารางเวลา
• คาใชจายที่คาดวาตองใชเพือ่ ใหงานเสร็จสมบูรณ (EAC) เปนประมาณการ
คาใชจายใหม ภายใตเงื่อนไขที่วา ไมมีสงิ่ ใดที่เลวรายลง ซึ่งไดจากงบประมาณ
ทั้งหมดที่ตงั้ ไวตั้งแตแรก (original total budget หรือ budget at completion
(BAC)) หารดวย CPI แตถามีสิ่งใดที่เลวรายลงอยางตอเนื่องในอัตราเดิม คา EAC
สามารถคํานวณจาก BAC/(CPI*SPI)
• เวลาที่คาดวาตองใชเพื่อใหงานเสร็จสมบูรณ คือ ตารางเวลาที่ตั้งไวตั้งแตแรก
(original schedule) หารดวย SPI

การคํานวณมูลคาที่ไดรับตองทําทุกกิจกรรมของโครงการเพื่อประมาณการมูลคาทีไ่ ดรับของ
ทั้งโครงการ บางกิจกรรมอาจใชเงินเกินงบประมาณหรือลาชากวาเวลาที่กาํ หนด แตกิจกรรมอื่นอาจใช
เงินนอยกวางบประมาณที่ตงั้ ไวหรือทํางานไดเร็วกวาเวลาที่กาํ หนด ดังนัน้ การรวมมูลคาที่ไดรบั ของทุก
กิจกรรมทําใหผูจัดการโครงการสามารถวัดการทํางานของโครงการในภาพรวมได
รูปที่ 6.7 คือ ตัวอยางการคํานวณมูลคาที่ไดรับสําหรับโครงการหนึง่ ป โครงการนีไ้ ดวางแผน
คาใชจายทั้งหมด 10,000,000 บาท สเปรดชีตแสดงคาใชจายจริงและขอมูลประสิทธิภาพสําหรับ 5
เดือนแรก หรือจนถึงเดือนพฤษภาคม RP ในสดมภ Q ของสเปรดชีตคือ สัดสวนของรอยละของงานที่
เสร็จจริงกับรอยละของงานทีเ่ สร็จตามทีว่ างแผน มูลคาที่ไดรับ (EV) สําหรับแตละกิจกรรมคํานวณโดย
การคูณคาอัตราประสิทธิภาพการทํางาน (RP) กับมูลคาทีว่ างแผน (PV) ตัวอยางเชน งานในแถวที่ 7 มี
คา PV เทากับ 800,000 บาท ณ สิ้นเดือนพฤษภาคม รอยละของงานที่เสร็จตามทีว่ างแผนคือ 75 และ
รอยละของงานที่เสร็จจริงคือ 50 คา RP คือ 50 หารดวย 75 หรือรอยละ 66.7 มูลคาที่ไดรับจึงไดจาก
800,000 คูณกับ 66.7% ซึ่งเทากับ 533,000 บาท จากการคํานวณคาใชจา ยทัง้ หมดทีว่ างแผนไว
คาใชจายจริงทั้งหมด และมูลคาที่ไดรับ เราสามารถหาคาความผันแปรของคาใชจาย ความผันแปรของ
ตารางเวลา ดัชนีประสิทธิภาพคาใชจา ย และดัชนีประสิทธิภาพเวลา (แถว A20 ถึง B26) คาความผัน

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-52

แปรของคาใชจายและเวลาเปนคาติดลบ ซึ่งหมายความวาโครงการมีการใชเงินมากกวางบประมาณ
และลาชากวาแผนที่วางไว

รูปที่ 6.7 การคํานวณมูลคาที่ไดรับของโครงการหนึ่งป (Schwalbe, 2007)

เพื่อติดตามการดําเนินโครงการ ผูจัดการโครงการควรวาดกราฟที่แสดงคามูลคาที่ไดรบั รวมกับ

คาอื่นๆ ดังรูปที่ 6.8 จากรูปดังกลาวจะชวยใหผูจัดการโครงการไดมองเห็นวาโครงการทํางานอยางไร ถา
โครงการทําไปตามแผน โครงการจะเสร็จใน 12 เดือน ดวยคาใชจา ยทัง้ หมด 10,000,000 (BAC) แตจาก
รูปเราจะเห็นวาคาใชจายจริง (AC) อยูเหนือเสน EV ตลอด แสดงวาคาใชจายเปนไปตามแผนหรือ
มากกวาแผน เสน PV คอนขางใกลกับเสน EV เพียงแตสูงเพียงเล็กนอยในเดือนสุดทาย ซึง่ หมายความ
วาโครงการเปนไปตามตารางเวลา จนกระทั่งเดือนสุดทายโครงการชากวาแผน
ผังมูลคาที่ไดรับแสดงใหเราเห็นลักษณะการทํางานของโครงการอยางรวดเร็ว ถามีปญหาดาน
คาใชจายและเวลารุนแรง ผูบ ริหารระดับสูงอาจตัดสินใจยุติโครงการ หรือกระทําการแกไข คาประมาณ
การคาใชจายที่ตองใชเพื่อใหงานเสร็จสมบูรณ (EAC) เปนขอมูลที่สําคัญเพื่อตัดสินใจเกี่ยวกับ
งบประมาณ โดยเฉพาะถาเงินทุนทัง้ หมดมีจํากัด การบริหารมูลคาที่ไดรับจึงเปนเทคนิคที่สําคัญ เพราะ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-53

มันชวยผูบริหารระดับสูงและผูจัดการโครงการประเมินความกาวหนาและตัดสินใจทางบริหารอยางมี
เหตุผล มูลคา

รูปที่ 6.8 ผังมูลคาที่ไดรบั ของโครงการหลังจาก 5 เดือน (Schwalbe, 2007)

ถาการบริหารมูลคาที่ไดรับเปนเครื่องมือควบคุมคาใชจายทีท่ รงประสิทธิภาพ แตทําไมทุกๆ

องคการถึงไมใชมัน ทําไมโครงการรัฐบาลถึงใช แตโครงการเชิงพาณิชยหลายๆ โครงการกลับไมใช
เครื่องมือนี้ มีเหตุผล 2 ขอที่องคการไมใชการบริหารมูลคาที่ไดรับ คือ
• การบริหารมูลคาที่ไดรับเนนการติดตามผลการดําเนินงานจริงกับผลการ
ดําเนินงานที่วางแผน หลายๆ องคการโดยเฉพาะโครงการเทคโนโลยีสารสนเทศ
ไมมีขอมูลการวางแผนที่ดี ดังนัน้ การติดตามผลการดําเนินงานกับแผนอาจ
สรางขอมูลการชี้นําที่ผิดพลาด นอกจากนัน้ การที่ตองคอยติดตามประมาณการ
คาใชจายที่เกิดขึ้นเร็วๆ นี้ และคาใชจายจริงที่เกีย่ วของเปนเรื่องที่ยงุ ยาก
• การประมาณการรอยละความสมบูรณของงานอาจสรางขอมูลชี้นาํ ทีผ่ ิดพลาด

เพื่อทําใหการบริหารมูลคาที่ไดรับงายแกการใช องคการสามารถปรับปรุงระดับของ
รายละเอียด และยังคงเก็บเกี่ยวประโยชนจากเทคนิคนี้ ตัวอยางเชน เราสามารถกําหนดใหงานที่ยงั ไม
เริ่มมีคาความสมบูรณของงานเปนรอยละ 0 สวนงานทีม่ ีความกาวหนามีคา เปนรอยละ 50 และสําหรับ
งานที่เสร็จมีคาเปนรอยละ 100 การกําหนดใหรอยละความสมบูรณของงานอยางงายๆ แบบนี้ จะให
ขอมูลสรุปเพียงพอสําหรับผูจ ัดการเพื่อดูวา ในภาพรวมโครงการทํางานไดดีอยางไร หลายๆ คนแสดง

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-54

ความกังวลในการพยายามเก็บขอมูลที่ละเอียด คิวทิน เฟลมมิง (Quentin Fleming) อธิบายวาเราไม

ตองเก็บขอมูลที่ระดับแพคเกจงาน (work package) เพือ่ ใชบริหารมูลคาที่ไดรับ แตเราควรเก็บขอมูลชุด
งานในโครงสรางจําแนกงานยอยที่เนนงานที่ตองสงมอบ ตัวอยางเชน เราอาจมีโครงสรางจําแนกงาน
ยอยสําหรับบานที่มีรายการตางๆ ของแตละหองในบาน เพียงแคการเก็บมูลคาที่ไดรับสําหรับแตละหอง
อาจใหสารสนเทศที่มีความหมาย แทนทีพ่ ยายามเก็บขอมูลละเอียดของแตละองคประกอบของหอง เชน
การปูพนื้ การตกแตง การเดินสายไฟ และ อื่นๆ เปนตน
อาจกลาวโดยสรุปวา การบริหารมูลคาที่ไดรับคือ วิธีพื้นฐานทีม่ ีไวเพื่อการบูรณาการผลการ
ดําเนินงาน คาใชจายและตารางเวลา มันสามารถเปนเครื่องมือทีม่ ีประสิทธิภาพสําหรับผูจัดการ
โครงการและผูบริหารระดับสูงใชในการประเมินผลการดําเนินงานโครงการ

6.6 สรุป
การบริหารคาใชจายโครงการคือ จุดออนดั้งเดิมของโครงการเทคโนโลยีสารสนเทศ ผูจัดการ
เทคโนโลยีสารสนเทศตองใหความสําคัญของการบริหารคาใชจาย และรับหนาทีท่ าํ ความเขาใจเกีย่ วกับ
แนวความคิดพื้นฐานเกี่ยวกับคาใชจาย การประมาณการคาใชจาย การทํางบประมาณ และการควบคุม
คาใชจาย
การประมาณการคาใชจายเปนสวนที่สาํ คัญมากๆ ของการบริหารโครงการ ซึง่ มีเครื่องมือและ
เทคนิคหลายอยางที่ชว ยการประมาณการคาใชจาย เชน การประมาณการโดยการเปรียบเทียบความ
คลายคลึง การประมาณการจากลางขึ้นบน ตัวแบบพาราเมตริก และเครื่องมือที่เปนคอมพิวเตอร
ตัวอยางตัวแบบพาราเมตริกคือ ฟงกชันพอยท และCOCOMO
การตั้งงบประมาณคาใชจา ยเกี่ยวของกับการจัดสรรคาใชจายใหกับงานแตละงาน ผูจัดการ
โครงการตองเขาใจวาองคการเตรียมงบประมาณอยางไร เพื่อใหการประมาณการโครงการไปดวยกันได
การควบคุมคาใชจายประกอบดวยการติดตามการใชจา ยเงิน การทบทวนการเปลี่ยนแปลง
และการแจงผูม ีสวนไดเสียโครงการถึงการเปลี่ยนแปลงที่มีผลตอคาใชจาย การบริหารมูลคาที่ไดรับเปน
วิธีการสําคัญที่ใชสําหรับการวัดผลการดําเนินโครงการ การบริหารมูลคาที่ไดรับบูรณาการขอมูลขอบเขต
คาใชจาย และตารางเวลา

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-55

คําถามทายบท
1. ทําไมผูมีอาชีพทางดานเทคโนโลยีสารสนเทศอาจมองขามการบริหารคาใชจายโครงการ
และสิ่งนี้อาจมีผลกระทบตอความสําเร็จของโครงการอยางไร
2. อธิบายหลักการพื้นฐานของการบริหารคาใชจาย
3. อธิบายวาการบริหารมูลคาที่ไดรับสามารถนํามาใชวัดผลการดําเนินงานไดอยางไร
4. เพราะเหตุใดการบริหารมูลคาที่ไดรับจึงไมคอยใชในการบริหารคาใชจา ย
5. จาก DFD ที่กาํ หนด ใหหาพารามิเตอรทงั้ 5 ตัว

6. สมมุติวาระบบงานในขอ 5 เขียนดวยภาษา VB พารามิเตอรทั้ง 5 ตัวมีระดับความซับซอน

เปนงาย และ ปจจัยปรับคาฟงกชนั พอยท (VAF) มีคาเปน 0.94 ใหทา นใชตัวแบบ
COCOMO ระดับกลางในการคํานวณหาแรงงาน เวลา และจํานวนพนักงานทีต่ องใชใน
การพัฒนางานชิ้นนี้ โดยกําหนดใหประเภทของโครงการเปนแบบเซมิดีเทช โดยทีม่ ีคาของ
ตัวขับเคลื่อนคาใชจายและลักษณะของโครงการดังตอไปนี้
• ขนาดของฐานขอมูลตอขนาดของโปรแกรม (DB bytes/program SLOC)
ประมาณ 300
• ความนาเชื่อถือ ของระบบตองสูงกวาปกติเล็กนอยเพราะระบบตองประมวล
เกี่ยวกับคําสัง่ ซื้อของลูกคา
• ขั้นตอนวิธีการสําหรับการประมวลผลไมมคี วามยุง ยากหรือตองคิดหาวิธีการใหมๆ
มาชวย

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคาใชจายโครงการ หนา 6-56

• ระบบที่พฒ ั นาบนฮารดแวรและซอฟตแวรที่ทกุ ปจะมีการเปลี่ยนแปลงไมมาก

• ประสบการณของทีมงานในระบบงานประเภทนี้มีประมาณ 3 ป โดยที่สมาชิก
ในทีมคุน เคยกับการพัฒนาระบบงานประเภทนี้
• เริ่ม มีการใชเทคนิคทางดานการโปรแกรมในการออกแบบ และเขียนโปรแกรม
• ประสบการณในภาษาที่ใชพัฒนาโปรแกรมประมาณ 8 เดือน
• ระบบจะตองใชเวลาเฉลีย่ ในการประมวลผลนับแตสั่งใหทํางานจนกระทั่งไดผล
ลัพธกลับมานอยกวา 5 นาที
7. ขอมูลที่กําหนดใหขางลางนีเ้ ปนขอมูลของโครงการหนึง่ ป จงใชขอมูลที่ใหตอบคําถาม
ตอไปนี้
ก. คาความผันแปรของคาใชจาย คาความผันแปรของตารางเวลา ดัชนีผลการ
ดําเนินงานของคาใชจาย และดัชนีผลการดําเนินงานของตารางเวลา มีคาเทาใด
ข. โครงการทํางานเปนอยางไร ชาหรือเร็วกวาตารางเวลา ใชเงินมากกวาหรือนอยกวา
งบประมาณทีก่ ําหนดในแผน
ค. คํานวณหาคา EAC
ง. คํานวณหาระยะเวลาที่ตองใชเพื่อใหโครงการเสร็จสมบูรณ
PV = 2,300,000
EV = 2,000,000
AC = 2,500,000
BAC = 1,200,000

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคุณภาพโครงการ หนา 7-1

7.1 บทนํา
คําวา “คุณภาพ” สําหรับแตละคนมีความหมายที่แตกตางกัน แลวแตมุมมองของแตละคน
เชน ถาเราเปรียบเทียบคุณภาพของรถยนต 2 คัน คันแรกเปนรถทีห่ รูหราราคาแพง ที่นงั่ หุม ดวยหนังและ
มีสิ่งอํานวยความสะดวกทุกอยาง สวนรถยนตอีกคันเปนรถราคาประหยัดที่สามารถขับพาไปที่ตางๆ ได
ไมมีสิ่งอํานวยความสะดวกในรถยนต หลายๆ คนคิดวารถยนตคนั ที่ราคาแพงมีคุณภาพสูงกวา ถึงแมวา
รถยนตที่ราคาแพงมีฟงกชันเพิ่มเติมมากกวารถยนตที่ราคาถูกกวา แตคาบํารุงรักษาก็มีราคาแพงดวย
สวนรถยนตราคาถูกกวาอาจมองดูวา ดี ถารถยนตนนั้ มีความปลอดภัยสูงกวามาตรฐานที่กาํ หนด
ดังนัน้ การจะกําหนดวาสินคาใดมีคุณภาพนั้น ตองพิจารณาจากหลายปจจัย ไมใชเฉพาะ
ฟงกชันการทํางานเทานั้น คุณลักษณะอื่นๆ เชน ความปลอดภัย หรือการบริการหลังการขาย อาจเปน
ปจจัยที่สาํ คัญตอลูกคา เชนเดียวกันกับการพัฒนาซอฟตแวร เราสามารถสรางระบบที่มีฟง กชนั งานที่ดี
มาก แตฟง กชันเหลานัน้ ทํางานไมดี มีขอผิดพลาดเกิดตลอดเวลา ในทางกลับกัน ถาเราพัฒนา
ระบบงานทีม่ ฟี งกชันการทํางานที่จาํ กัด แตมีขอผิดพลาดเล็กนอย เราอาจสรุปวาระบบงานหลังมี
คุณภาพมากกวาระบบงานแรก เพราะฉะนัน้ เราจึงจําเปนตองกําหนดและบริหารคุณภาพของโครงการ
ใหสอดคลองกับความคาดหวังผูมีสวนไดสวนเสียใหมากที่สุด
แนวคิดและปรัชญาการบริหารคุณภาพไดรับความสนใจมานานหลายป หลายๆ องคการตางๆ
ใหความสนใจในเรื่องนี้อยางมาก และไดริเริ่มโครงการปรับปรุงคุณภาพผลิตภัณฑ เชน ไอเอสโอ (ISO)
ซิกสซิกมา (six sigma) ตัวแบบวุฒิภาวะความสามารถแบบบูรณาการ (Capability Maturity Model
Integration (CMMI)) นอกจากนี้ ยังมีแนวคิดการบริหารคุณภาพของผูรูอีกมากมาย เชน เดมมิง
(Deming) จูราน (Juran) อิชิคาวา (Ishikawa) และครอสบี (Crosby) รวมทัง้ โครงการตองมีการกําหนด
ตัววัด (metrics) เพื่อใหเราทราบวาสิง่ ทีโ่ ครงการดําเนินการไดคุณภาพหรือไม

7.2 การบริหารคุณภาพโครงการคืออะไร
วัตถุประสงคการบริหารคุณภาพคือ เพื่อใหแนใจวาโครงการจะตอบสนองความตองการที่
โครงการไดรับมอบหมาย ทีมงานตองพัฒนาความสัมพันธที่ดีกับผูมีสว นไดเสียที่สําคัญ โดยเฉพาะผูใช
หลัก เพื่อใหเขาใจวาคุณภาพมีความหมายอยางไรกับบุคคลเหลานี้ เนื่องจากในที่สุดแลวผูใชจะเปนผู
ตัดสินวาซอฟตแวรมีคุณภาพที่รับไดหรือไม

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคุณภาพโครงการ หนา 7-2

ไอเอสโอ (ISO) ไดนิยามวา “คุณภาพ” คือ คุณลักษณะตางๆ ของซอฟตแวรเติมเต็มความ

ตองการของผูใ ช ผูเชี่ยวชาญบางคนนิยามคุณภาพโดยพิจารณาจากความสอดคลองกับความตองการ
(conformance to requirement) และความเหมาะสมกับการใชประโยชน (fitness to use) ความ
สอดคลองกับความตองการหมายถึง กระบวนการและผลิตภัณฑของโครงการตรงกับที่รายละเอียดที่ได
เขียนไว สวนความเหมาะสมกับการใชประโยชนหมายถึง ผลิตภัณฑสามารถใชไดตามที่ไดตั้งใจไว เชน
ถาโครงการสงมอบเครื่องคอมพิวเตอรที่ปราศจากแปนพิมพ หรือจอภาพ เพราะทิ้งไวในหองเก็บของ
ลูกคายอมไมพอใจเพราะเครื่องคอมพิวเตอรไมเหมาะกับการใชงาน เนื่องจากลูกคามีสมมุติฐานที่การ
สงมอบตองมีอุปกรณครบ
การบริหารคุณภาพโครงการคือ กระบวนการที่ตองทําเพื่อใหแนใจวาโครงการจะตอบสนอง
ความตองการตามที่โครงการไดกําหนดไว กระบวนการบริหารคุณภาพโครงการมี 3 กระบวนการหลักคือ
• การวางแผนคุณภาพ
• การประกันคุณภาพ
• การควบคุมคุณภาพ

การบริหารคุณภาพโครงการจะเนนทั้งกระบวนการและผลิตภัณฑของโครงการ ผลิตภัณฑของ
โครงการที่สําคัญที่สุดคือ ระบบสารสนเทศที่ทีมงานตองสงมอบ ดังนัน้ ระบบจะตองสอดคลองกับความ
ตองการ และความเหมาะสมกับการใชประโยชนตามทีก่ ลาวมาแลว สวนกระบวนการหมายถึง กิจกรรม
วิธีการ วัตถุดบิ และการวัด ที่ใชเพื่อผลิตผลิตภัณฑหรือบริการ เราสามารถมองวากระบวนการเหลานี้
เปนสวนหนึง่ ของโซคุณภาพ (quality chain) ที่ผลลัพธของกระบวนการหนึง่ เปนสิ่งนําเขาของ
กระบวนการบริหารโครงการอื่น
โดยที่โครงการเนนที่ผลิตภัณฑและโซของกระบวนการ การจัดการโครงการสามารถใช
ทรัพยากรใหมปี ระสิทธิผลและประสิทธิภาพมากกวาเดิม ลดขอผิดพลาด และตรงกับหรือมากกวาที่ผูมี
สวนไดเสียของโครงการคาดหวัง ความลมเหลวดานความตองการคุณภาพจะสงผลเชิงลบกับโครงการ
นอกจากนี้ ยังทําใหเกิดการทํางานเพิ่ม หรือทํางานซ้ํา ทําใหโครงการตองขยายเวลา และเพิ่ม
งบประมาณ

7.3 การวางแผนคุณภาพ
การวางแผนคุณภาพคือ การกําหนดมาตรฐานคุณภาพที่เกี่ยวกับโครงการ และทําอยางไรจึง
จะทําใหไดตามมาตรฐานเหลานัน้ ผูจัดการโครงการตองมีความสามารถในการคาดการณสถานการณ
และเตรียมกิจกรรมที่ใหไดผลลัพธที่ตองการ ปจจุบนั การบริหารคุณภาพทีท่ ันสมัยคือ การปองกัน

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคุณภาพโครงการ หนา 7-3

ขอบกพรอง (defects) โดยการเลือกวัตถุดิบที่เหมาะสม การอบรม การสอนใหคนซึมทราบในคุณภาพ

และวางแผนกระบวนการที่แนใจวาไดผลลัพธทเี่ หมาะสม
การออกแบบการทดลองเปนเทคนิคการวางแผนคุณภาพอยางหนึง่ ทีช่ วยในการกําหนดตัว
แปรที่มีอิทธิพลสูงสุดตอผลลัพธโดยรวมของกระบวนการหนึง่ การเขาใจตัวแปรที่กระทบตอผลลัพธเปน
เรื่องที่สําคัญมากในการวางแผนคุณภาพ เชน การใชการออกแบบการทดลองกับประเด็นเรือ่ งการได-
เสียระหวางคาใชจายกับระยะเวลา ถาคาใชจายของโปรเกรมเมอรระดับรองและที่ปรึกษามีมูลคานอย
กวาโปรแกรมเมอรอาวุโสและที่ปรึกษา แตเราไมสามารถคาดไดวาเขาเหลานัน้ ทํางานสมบูรณในระดับ
เดียวกันในเวลาเทากัน การออกแบบการทดลองเพื่อคํานวณคาใชจา ยและชวงเวลาทีน่ อยที่สุด โดยการ
ผสมผสานบุคลากรในรูปแบบตางๆ จะชวยใหเราสามารถวางแผนไดเหมาะสมมากขึ้น
การวางแผนคุณภาพยังรวมถึงการสื่อสารการกระทําที่ถกู ตองเพื่อใหแนใจวาคุณภาพอยูใน
รูปแบบที่สมบูรณและเขาใจได ดังนั้น ในแผนจะตองอธิบายปจจัยที่สําคัญทีม่ ีสวนรวมใหผลผลิตที่ได
ตรงกับความตองการของลูกคา กระบวนการวางแผนจําเปนตองใชนโยบายองคการที่เกีย่ วกับคุณภาพ
ขอบเขตของโครงการและรายละเอียกผลิตภัณฑ และมาตรฐานและกฎเกณฑที่เกีย่ วของ ผลลัพธหลักที่
ไดจากกระบวนการวางแผนคือ แผนการบริหารคุณภาพ และรายการตรวจสอบคุณภาพ (checklists)
ตลอดวงจรชีวติ โครงการ
ลักษณะขอบเขตที่สําคัญของโครงการเทคโนโลยีสารสนเทศที่กระทบคุณภาพประกอบดวย
• ฟงกชันงาน (functionality) คือ ระดับที่ระบบทํางานตามภาระงานที่ไดตั้งใจไว
สวนลักษณะ (feature) คือ คุณลักษณะพิเศษของระบบที่ดึงดูดผูใช ดังนัน้ มันจึงเปนสิ่งสําคัญที่ตอ งทํา
ใหเกิดความชัดเจนวา งานและลักษณะอะไรที่ระบบจะตองทํา และอะไรที่เหมาะสมที่สุด เชน งานที่
ระบบตองทําไดคือ ผูใชสามารถติดตามยอดขายของเครื่องมือทางการแพทยจําแนกตามกลุมเครื่องมือ
แพทย สวนลักษณะที่ตองมีคือ สวนเชื่อมประสานกับผูใชตองเปนกราฟก ที่มีไอคอน เมนู และความ
ชวยเหลือแบบออนไลน
• ผลลัพธของระบบ คือ จอภาพและรายงานที่ระบบสรางเปนสิ่งที่สาํ คัญที่ควรจะ
กําหนดใหชัดเจนวาจอภาพและรายงานควรมีหนาตาอยางไร
• การดําเนินงาน หมายถึง ผลิตภัณฑหรือบริการสามารถทํางานไดตามความตั้งใจ
ใชงานของลูกคาได ดังนั้น เพื่อใหไดการออกแบบระบบที่มีคุณภาพการดําเนินงาน
สูง ผูมีสว นไดเสียโครงการตองพิจารณาประเด็นตอไปนี้
ƒ ขนาดของขอมูลและธุรกรรมที่ระบบตองจัดการ
ƒ จํานวนผูใชระบบพรอมๆ กัน
ƒ อัตราการเพิม่ ของผูใช

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคุณภาพโครงการ หนา 7-4

ƒ ประเภทของอุปกรณที่ระบบจะตองทํางานดวย
ƒ ชวงเวลาระหวางที่สงคําขอและไดรับขอมูลกลับ (response time)
• ความนาเชื่อถือ คือ ความสามารถที่ผลิตภัณฑหรือบริการทํางานไดตามที่คาดหวัง
ภายใตเงื่อนไขปกติ โดยสวนใหญผลิตภัณฑเทคโนโลยีสารสนเทศไมมีความ
นาเชื่อถือ 100 เปอรเซ็นต แตผูมีสวนไดเสียตองกําหนดระดับทีค่ าดหวัง เชน
จํานวนชัว่ โมงที่ผูใชเต็มใจทีจ่ ะไมสามารถใชระบบได
• ความสามารถบํารุงรักษา คือ ความงายของการบํารุงรักษาผลิตภัณฑ เชน มีการ
สนับสนุนใหความชวยเหลือ

7.4 การประกันคุณภาพ
การประกันคุณภาพจะรวมกิจกรรมทัง้ หมดที่เกี่ยวของกับการตอบสนองมาตรฐานคุณภาพ
สําหรับโครงการ เพื่อสงมอบผลิตภัณฑและบริการที่มคี ุณภาพ รวมทั้งเพื่อการปรับปรุงคุณภาพอยาง
ตอเนื่อง ผูบริหารระดับสูงตองเปนผูน ําและใหพนักงานทุกคนมีบทบาทในการประกันคุณภาพ
มีเครื่องมือหลายอยางที่ใชในการวางแผนคุณภาพที่สามารถนํามาใชในการประกันคุณภาพ
เชน การออกแบบการทดลองดังที่ไดกลาวมาแลว การวัดเปรียบเทียบสมรรถนะ (benchmarking) เปน
อีกวิธีการที่ชว ยสรางความคิดสําหรับการปรับปรุงคุณภาพโดยการเปรียบเทียบการปฏิบัติงานหรือ
คุณลักษณะของผลิตภัณฑของโครงการกับขององคการอื่น เชน ถาคูแขงมีระบบสนับสนุนการบริหาร
สําหรับผูบริหารระดับสูงที่เวลาเฉลี่ยที่ระบบไมทํางานเพียงวันละชั่วโมงตอสัปดาห เวลาเฉลี่ยดังกลาว
อาจเปนเกณฑเปรียบเทียบสมรรถนะ ผังกางปลาหรือผังอิชิคาวาทีจ่ ะกลาวตอไปเปนเครื่องมือชวยใน
การปรับปรุงคุณภาพโดยการคนหารากของปญหาคุณภาพ บางองคการมีแมแบบ (template) สําหรับ
การพัฒนาแผนตางๆ ที่เกี่ยวกับการประกันคุณภาพดังตัวอยางในตารางที่ 7.1

ตารางที่ 7.1 ตัวอยางแมแบบของแผนประกันคุณภาพ (Schwalbe, 2007)

1.0 รางแผนประกันคุณภาพ (Draft Quality Assurance Plan)
1.1 บทนํา (Introduction)
1.2 ความมุงหมาย (Purpose)
1.3 นโยบาย (Policy Statement)
1.4 ขอบเขต (Scope)
2.0 การบริหาร (Management)
2.1 โครงสรางองคการ (Organizational Structure)
2.2 บทบาทและความรับผิดชอบ (Roles and Responsibilities)

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคุณภาพโครงการ หนา 7-5

2.2.1 การติดตามเชิงเทคนิค/ผูบริหารอาวุโส (Technical Monitor/Senior Management)

2.2.2 หัวหนางาน (Task Leader)
2.2.3 ทีมประกันคุณภาพ (Quality Assurance Team)
2.2.4 คณะทํางานเชิงเทคนิค (Technical Staff)
3.0 เอกสารที่ตองการ (Required Documentation)
4.0 ขั้นตอนการประกันคุณภาพ (Quality Assurance Procedures)
4.1 ขั้นตอนการตรวจตลอด (Walkthrough Procedure)
4.2 กระบวนการทบทวน (Review Process)
4.2.1 ขั้นตอนการทบทวน (Review Procedures)
4.3 กระบวนการตรวจสอบ (Audit Process)
4.3.1 ขั้นตอนการตรวจสอบ (Audit Procedures)
4.4 กระบวนการประเมินผล (Evaluation Process)
4.5 การปรับปรุงกระบวนการ (Process Improvement)
5.0 ขั้นตอนการรายงานปญหา (Problem Reporting Procedures)
5.1 ขั้นตอนการรายงานความไมสอดคลอง (Noncompliance Reporting Procedures)
6.0 ตัววัดการประกันคุณภาพ (Quality Assurance Metrics)
ภาคผนวก (Appendix)
แบบฟอรมรายการตรวจสอบการประกันคุณภาพ (Quality Assurance Checklist Forms)

เครื่องมือสําคัญอีกอยางที่ชว ยในการประกันคุณภาพคือ การตรวจสอบคุณภาพ (quality

audit) ซึ่งเปนการทบทวนอยางมีโครงสรางที่ชว ยระบุบทเรียนที่ไดเรียนรูที่อาจปรับปรุงการทํางานของ
โครงการปจจุบันหรือโครงการอนาคต ผูตรวจสอบคุณภาพอาจจะเปนคนในองคการ หรือองคการอื่นที่มี
ความเชีย่ วชาญในการตรวจสอบคุณภาพ

7.5 การควบคุมคุณภาพ
การควบคุมคุณภาพเปนการติดตามผลของโครงการเพือ่ ใหแนใจวาผลงานเหลานั้นเปนไปตาม
มาตรฐาน ขณะเดียวกัน การควบคุมคุณภาพชี้ใหเห็นวิธที ี่จะปรับปรุงคุณภาพโดยรวม ผลที่ไดจากการ
ควบคุมคุณภาพมี 3 อยางคือ การตัดสินใจยอมรับ การทํางานใหม และการปรับกระบวนการ
• การตัดสินใจยอมรับ คือ การกําหนดวาเราจะยอมรับหรือปฏิเสธผลิตภัณฑหรือบริการ
ที่เปนสวนหนึง่ ของโครงการ ถาเรายอมรับผลิตภัณฑหรือบริการ แสดงวาผลิตภัณฑ
หรือบริการที่ไดรับการตรวจสอบวาถูกตอง แตถาผูม สี วนไดเสียของโครงการปฏิเสธ
ผลิตภัณฑหรือบริการ ผูรับผิดชอบตองนําผลิตภัณฑหรือบริการนั้นกลับไปทําใหม

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคุณภาพโครงการ หนา 7-6

• การทํางานใหม เปนกิจกรรมที่ทําเนื่องจากงานถูกปฏิเสธวาไมสอดคลองการความ
ตองการหรือรายละเอียดที่กาํ หนดไว การทํางานใหมมผี ลอันเนื่องมาจากการ
เปลี่ยนแปลงที่ไดรับการรองขอ การแกไขขอบกพรอง การปองกันขอบกพรอง การ
ทํางานใหมอาจมีคาใชจายทีแ่ พง ดังนัน้ ผูจดั การโครงการควรหลีกเลีย่ ง
• การปรับกระบวนการ คือ การแกไขหรือปองกันปญหาคุณภาพตามตัววัดคุณภาพ ซึง่
มีผลตอการปรับบรรทัดฐานคุณภาพ (quality baseline) และแผนการบริหารโครงการ

7.6 เครื่องมือ และเทคนิคสําหรับการควบคุมคุณภาพ

การควบคุมคุณภาพจะใชเครื่องมือและเทคนิคซึง่ จะกลาวในสวนนี้ คือ เครื่องมือพืน้ ฐาน
สําหรับการควบคุมคุณภาพ 7 ชนิด การสุมตัวอยางเชิงสถิติ (statistical sampling) ซิกสซิกมา (six
sigma) และ การทดสอบและการทวนสอบ (testing and verification)

7.6.1 เครื่องมือพื้นฐานสําหรับการควบคุมคุณภาพ
เครื่องมือพืน้ ฐานสําหรับการควบคุมคุณภาพมี 7 ชนิดคือ แผนภูมิแสดงเหตุและผล
(cause and effect diagram) ผังการควบคุม (control chart) ผังการวิ่งของขอมูล (run chart) ผังการ
กระจายขอมูล (scatter diagram) แผนภูมิแบบแทง (histogram) ผังพาเรโต (pareto chart) และผังการ
ไหลของงาน (flowchart)

แผนภูมิแสดงเหตุและผล
แผนภูมิแสดงเหตุและผล หรือผังกางปลา หรือผังอิชิคาวา เปนเครื่องมือที่ชวยให
เรายอนกลับไปหารากของปญหา รูปที่ 7.1 แสดงสาเหตุของปญหาที่ลูกคาไมสามารถเขาระบบได
สาเหตุหลักของปญหาอาจเนื่องมาจาก ระบบฮารดแวร ฮารดแวรของผูใชแตละคน การอบรม หรือ
ซอฟตแวร แผนภูมิแสดงเหตุและผลยังแสดงใหเห็นถึงสาเหตุยอยทีท่ ําใหเกิดสาเหตุหลักได เชน สาเหตุ
หลักคือ ฮารดแวรของผูใชที่มีผลทําใหลกู คาไมสามารถเขาระบบได สวนสาเหตุยอ ยคือ หนวยความจํา
ไมพอ หนวยประมวลผลมีความสามารถต่ํา หรือที่เก็บขอมูลไมพอ ถาผูใชสวนใหญไมสามารถเขาใช
ระบบไดเนื่องจากหนวยความจําไมพอ ทางแกอาจเปนการเพิ่มหนวยความจํา แตถาผูใชสวนใหญไม
สามารถเขาระบบไดเพราะลืมรหัสผาน การแกปญหาจะเร็วและเสียคาใชจายนอย

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคุณภาพโครงการ หนา 7-7

รูปที่ 7.1 ตัวอยางผังกางปลาของอิชิคาวา (Schwalbe, 2007)

ผังการควบคุม
ผังการควบคุมเปนผังที่แสดงผลของกระบวนตามเวลาในรูปแบบกราฟ
วัตถุประสงคหลักของผังการควบคุมคือ เพื่อปองกันขอบกพรองมากกวาตรวจหาขอบกพรองหรือปฏิเสธ
ผลลัพธที่ไดจากกระบวนการ ผังการควบคุมทําใหเราสามารถกําหนดวากระบวนอยูในการควบคุมหรือ
นอกการควบคุม กระบวนการที่อยูในการควบคุมไมจําเปนตองปรับแก แตถากระบวนการอยูน อกการ
ควบคุม เราจําเปนตองหาสาเหตุ และปรับกระบวนการใหถูกตอง หรือขจัดสาเหตุ ผังการควบคุมใชเพื่อ
ติดตามการผลิตสินคา แตเราสามารถนําผังการควบคุมมาใชติดตามปริมาณและความถี่ของคํารองขอ
เปลี่ยนแปลง ขอผิดพลาดในเอกสาร ความแปรปรวนของคาใชจายและเวลา และอื่นๆ ที่เกีย่ วของกับ
การบริหารโครงการ ผังการควบคุมทําใหเราเห็นพฤติกรรมของกระบวนการใดกระบวนการหนึ่ง ผังการ
ควบคุมทุกผังจะมีเสนกลาง และเสนขอบเขตระดับบนและระดับต่ํา เสนกลางแทนคาเฉลี่ย โดยปกติชวง
ควบคุมจะถูกกําหนดไวที่ ±3 σ

รูปที่ 7.2 ตัวอยางผังการควบคุม (Schwalbe, 2007)

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคุณภาพโครงการ หนา 7-8

รูปที่ 7.2 คือ ตัวอยางการผังควบคุมกระบวนการผลิตไมบรรทัดไมขนาด 12 นิ้ว ที่

ผลิตโดยเครื่องจักร แตละจุดในผังแทนการวัดความยาวของไมบรรทัดที่ไดจากสายการผลิต สเกลแนวตั้ง
แสดงขอบเขตสูงสุดและต่ําสุดที่ลูกคาเปนผูกําหนดวาไมบรรทัดที่จะซื้อทั้งหมดตองอยูระหวาง 11.90-
12.10 นิ้ว ผูผลิตไดออกแบบใหกระบวนการผลิตสามารถผลิตไมบรรทัดยาวระหวาง 11.91 และ 12.09
นิ้ว
เสนจุดไขปลาแสดงตําแหนงความเบีย่ งเบนมาตรฐานที่ 1 σ 2 σ และ 3 σ ทั้งที่
สูงและต่ํากวาคาเฉลี่ย ถาบริษัทตองการใหไมบรรทัดผลิตออกมาในชวง 11.91 – 12.09 นิ้ว บริษทั ตอง
ควบคุมการผลิตที่ 3 σ ผลผลิตที่อยูในชวงนีม้ ีรอยละ 99.73
การวิเคราะหรปู แบบในขอมูลกระบวนการเปนสิ่งสําคัญของการประกันคุณภาพ
กฎเจ็ดจุดสามารถนํามาใชหารูปแบบของขอมูลได กฎนีก้ ลาววาถาขอมูลทั้งหมด 7 คา อยูตา่ํ กวา
คาเฉลี่ย สูงกวาคาเฉลีย่ หรือขอมูลทั้งหมดเพิ่มขึ้นหรือลดลง แสดงวากระบวนการจําเปนตองไดรับการ
ตรวจสอบ ในรูปที่ 7.2 จุดที่ละเมิดกฎนีถ้ ูกแสดงดวยดาว สําหรับกระบวนการผลิตไมบรรทัด ขอมูลนี้
ชี้ใหเห็นวาควรมีการปรับความแมนยําของอุปกรณ เชน เครื่องตัดไมสําหรับทําไมบรรทัดจําเปนตอง
ปรับแตงใหม หรือใบมีดอาจตองเปลี่ยน

มค. กพ. มีค. เมย. พค. มิย. กค. สค. กย. ตค. พย. ธค.

ขอบกพรองประเภทที่ 1 ขอบกพรองประเภทที่ 2 ขอบกพรองประเภทที่ 3

รูปที่ 7.3 ตัวอยางผังการวิ่งของขอมูล (Schwalbe, 2007)

ผังการวิง่ ของขอมูล
ผังการวิ่งของขอมูลแสดงถึงประวัติและรูปแบบของความแปรปรวนของ
กระบวนการตามเวลา โดยแสดงขอมูลเปนเสนตรงที่มีจดุ กําหนดตามลําดับการเกิด เราสามารถใชผัง
การวิง่ ของขอมูลเพื่อทําการวิเคราะหแนวโนมสําหรับการพยากรณผลลัพธในอนาคตจากผลลัพธในอดีต
รูปที่ 7.3 เปนตัวอยางที่แสดงขอบกพรอง 3 ประเภท เราจะเห็นวาขอบกพรองประเภทที่ 1 มีขอบกพรอง

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคุณภาพโครงการ หนา 7-9

เพิ่มขึ้นไปเรื่อยๆ สวนขอบกพรองประเภทที่ 2 นั้น มีจํานวนขอบกพรองลดลงในหลายเดือน แลวคงที่ แต

ขอบกพรองประเภทที่ 3 มีจาํ นวนขอบกพรองแบบขึ้นๆ ลงๆ

ผังการกระจายขอมูล
ผังการกระจายขอมูลแสดงความสัมพันธระหวาง 2 ตัวแปร ถาจุดตางๆ ที่เขาใกล
เสนทแยงมุมมากขึ้น ตัวแปรทั้งสองมีความสัมพันธกนั มากขึ้น รูปที่ 7.4 เปนตัวอยางของผังการกระจาย
เพื่อศึกษาวาอัตราความพึ่งพอใจของผูใชระบบมีความสัมพันธกับอายุของผูตอบคําถามหรือไม เรา
พบวาผูใชที่อายุนอย มีอัตราความพอใจระบบต่ํา

รูปที่ 7.4 เปนตัวอยางของผังการกระจายขอมูล (Schwalbe, 2007)

แผนภูมิแบบแทง
แผนภูมิแบบแทงแสดงการกระจายของตัวแปร แทงแตละแทงแทนคุณลักษณะของ
ปญหาหรือสถานการณ และความสูงของแทงแสดงความถี่ของคุณลักษณะนัน้ รูปที่ 7.5 แสดงจํานวน
การรองเรียนของลูกคาในแตละสัปดาห

รูปที่ 7.5 ตัวอยางแผนภูมิแบบแทง (Schwalbe, 2007)

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคุณภาพโครงการ หนา 7-10

ผังพาเรโต
ผังพาเรโตชวยเราระบุปญหาการผลิตและลําดับความสําคัญ โดยพิจารณาจาก
ความถี่ หรืออาจกลาวไดวาผังพาเรโตนี้เปนเครื่องชวยจําแนกขอบเขตปญหาตามระดับความสําคัญของ
สภาพความเสียหายโดยแสดงเปนแผนภูมแิ ทง สําหรับในกรณีโครงการเทคโนโลยีสารสนเทศ การ
วิเคราะหแบบพาเรโต เปนวิธีการชวยเรากําหนดปจจัยที่มีสวนรวมทีส่ ําคัญตอปญหาคุณภาพมากที่สุด
ในระบบ บางครั้งการวิเคราะหแบบนีเ้ รียกวากฎ 80-20 ซึ่งหมายความวา รอยละ 80 ของปญหามาจาก
สาเหตุรอยละ 20 ผังพาเรโตจะชวยชี้สว นที่เปนปญหาและการจัดลําดับความสําคัญ ตัวแปรที่อธิบายใน
แผนภูมิแทงเรียงลําดับตามความถีท่ ี่เกิดขึ้น ดังตัวอยางในรูปที่ 7.6
จํานวนการรองเรียนของสัปดาหนี้

รูปที่ 7.6 ตัวอยางผังพาเรโต (Schwalbe, 2007)

จากรูปที่ 7.6 จะเห็นวาคํารองเรียนกลุมที่มีจาํ นวนสูงสุดคือ ปญหาการเขาสูร ะบบ

(log-in) รองลงมาคือ ปญหาระบบปดขัง (system locks up) ซึ่งปญหาทั้งสองกลุม นี้เมื่อรวมกันแลวคิด
เปนเกือบรอยละ 80 ของจํานวนคํารองเรียนทั้งหมด ถาโครงการตองการลดคํารองเรียนลง ตองเนนที่ทาํ
ใหการเขาใชระบบงายขึ้น
อยางไรก็ตาม ผูจัดการโครงการที่ดีตองแบงประเภทคํารองเรียนตามความรุนแรงของ
ปญหา เนื่องจากในการแกไขปญหาที่รนุ แรงจะมีคาใชจา ยสูง บริษัทควรทบทวนคํารองเรียนทั้งหมดกอน
ตัดสินใจดําเนินการ

ผังการไหลของงาน
ผังการไหลของงานแสดงตรรกะและการไหลของกระบวนการที่ชวยใหเราวิเคราะห
ปญหาเกิดขึ้นไดอยางไร และจะปรับปรุงกระบวนการไดอยางไร ผังการไหลของงานแสดงถึงกิจกรรม จุด
การตัดสินใจ และลําดับการประมวลสารสนเทศ ดังแสดงในรูปที่ 7.7

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคุณภาพโครงการ หนา 7-11

คํารองที่ สงไปยังผูที่
ยอมรับ ทําหนาที่ตัด
สินใจ

ลงนามในสวน แจงผูรองเรียน
ยอมรับหรือ ใช
ที่อนุมัติ และลงบันทึก
ไม ? เขาระบบ
ไม
บันทึกงานที่
ตองการให
ทําเพิ่มเติม

รูปที่ 7.7 ตัวอยางผังการไหลของงาน (Schwalbe, 2007)

7.6.2 การสุมตัวอยางเชิงสถิติ
การสุมตัวอยางเชิงสถิติเปนความคิดหลักในการบริหารคุณภาพโครงการ เนื่องจากใน
การควบคุมคุณภาพจําเปนตองเก็บรวมรวมขอมูลมาใชเพื่อการวิเคราะห แตขอมูลมีจํานวนมาก เราไม
สามารถใชขอมูลทั้งหมดได ดังนัน้ เราจึงจําเปนตองสุมตัวอยาง เพื่อเปนตัวแทนของประชากรทีเ่ ราสนใจ
สูตรงายๆ สําหรับการสุมตัวอยางคือ

ขนาดของตัวอยาง = 0.25 X (ปจจัยความแนนอน/ขอผิดพลาดที่สามารถรับได)2

ปจจัยความแนนอนหมายถึง ระดับความแนนอนที่เราไมตองการใหเกิดความแปรปรวน
ในตัวอยาง ซึ่งคํานวณไดจากตารางที่ 7.2

ตารางที่ 7.2 ปจจัยความแนนอนที่นิยมใช

ความแนนอนที่ตองการ ปจจัยความแนนอน
95% 1.960
90% 1.645
80% 1.281

7.6.3 ซิกสซิกมา
ซิกสซิกมาเปนระบบที่เบ็ดเสร็จและยืดหยุน เพื่อการบรรลุความสําเร็จสูงสุดทางธุรกิจ
และความคงอยูของธุรกิจ การขับเคลื่อนซิกสซิกมาตองอาศัยความเขาใจความตองการของลูกคา การใช

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคุณภาพโครงการ หนา 7-12

ขอเท็จจริง ขอมูล และการวิเคราะหเชิงสถิติ พรอมกับความตั้งใจอยางแข็งขันในการบริหาร การปรับปรุง

และการสรางกระบวนการทางธุรกิจใหม
เปาหมายความสําเร็จของซิกสซิกมาคือ การทําใหผลิตภัณฑหรือบริการมีขอบกพรอง
ขอผิดพลาด ไมเกิน 3.4 ตอลานโอกาส ซึง่ รายละเอียดจะไดอธิบายตอไป องคการสามารถนําหลักการ
ของซิกสซิกมาไปใชในการออกแบบและการผลิตสินคา การชวยเหลือลูกคา หรือ กระบวนการใหบริการ
ลูกคาอื่นๆ
โดยปกติ โครงการที่ใชหลักการของซิกสซิกมาเพื่อควบคุมคุณภาพจะดําเนินการ 5
กระบวนการทีเ่ รียก ดีเมอิ (DMAIC) ซึ่งมาจากการนิยาม (Define) การวัด (Measure) การวิเคราะห
(Analyze) การปรับปรุง (Improvement) และการควบคุม (Control)
• การนิยาม คือ การกําหนดปญหา/โอกาส กระบวนการ และความตองการของ
ลูกคา (เชน คํารองเรียน ผลการสํารวจ คําแนะนํา และการวิจัยตลาด) เชน ลด
เวลา คาใชจาย หรือขอบกพรอง เปาหมายเหลานี้เปนบรรทัดฐานหรือ
มาตรฐานสําหรับการปรับปรุงกระบวนการ
• การมาตรวัด เปนการวัดวาปญหา/โอกาส กระบวนการ หรือความตองการของ
ลูกคาที่องคการไดกําหนดขึ้นนัน้ ประสบความสําเร็จหรือไม ทีมงานซิกสซิกมา
มีหนาที่กําหนดมาตรวัดที่เกีย่ วของ ซึง่ กําหนดในรูปของขอบกพรองตอโอกาส
(defects per opportunity) การคํานวณมาตรวัดเริ่มตนจากการนิยามมาตร
วัด แลวรวบรวมขอมูล ประมวลผล และแสดงผล
• การวิเคราะห คือ การนําผลจากการวัดมาใชในการพินิจพิเคราะหรายละเอียด
กระบวนการ เพื่อหาโอกาสปรับปรุง ทีมงานซิกสซกิ มาจะตรวจตราและทวน
สอบขอมูลเพือ่ พิสูจนสาเหตุที่แทจริงของปญหาที่สงสัย เครื่องมือทีส่ ําคัญคือ
ผังกางปลา
• การปรับปรุง คือ การสรางคําตอบหรือวิธีการปรับปรุงกระบวนการหรือ
แกปญหา คําตอบสุดทายที่ไดจะถูกตรวจสอบหรือเห็นชอบจากผูสนับสนุน
โครงการ จากนัน้ ทีมงานซิกสซิกมาพัฒนาแผนนํารองเพื่อทดสอบคําตอบ ทีม
ซิกสซิกมาทบทวนผลจากการทดสอบแบบนํารองเพื่อทําใหคําตอบดีขึ้น
หลังจากนั้นจึงดําเนินการตามคําตอบที่ไดปรับปรุงแลว
• การควบคุม คือ การติดตามและควบคุมใหผลการปรับปรุงมีเสถียรภาพ ผัง
การควบคุมเปนเครื่องมือหนึง่ ที่ชว ยในเฟสควบคุม

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคุณภาพโครงการ หนา 7-13

การนําซิกสซกิ มามาใชมีหลักการดังนี้
• กําหนดใหหลักการซิกสซิกมาเปนพันธกิจขององคการ ผูบริหารระดับสูง และ
พนักงานทุกระดับจะตองเขามามีสว นรวม การอบรมหลักการนี้เปนสิ่งที่ตอง
ลงทุนสูง แตองคการจะไดผลตอบแทนคือ งานหรือบริการที่มีคุณภาพดวย
ตนทุนที่ตา่ํ
• การอบรมซิกสซิกมาจะใชระบบเข็มขัด (belt system) แบบการเรียนคาราเต ผู
เขารับการอบรมจะไดเข็มขัดสีตางๆ ถาไดเข็มขัดสีเหลืองหมายถึง ผูเ ขารับการ
อบรมไดรับการอบรมในระดับที่จําเปนเทานั้น ซึ่งโดยปกติประมาณ 2-3 วัน
เต็มสําหรับทีมงานที่ทาํ งานกับโครงการซิกสซิกมาแบบไมเต็มเวลา กลุมเข็มขัด
สีเขียวหมายถึง ผูเขารับการอบรมเต็ม 2-3 อาทิตย สวนกลุมเข็มขัดสีดํา
หมายถึง กลุมคนทีท่ ํางานโครงการซิกสซิกมาแบบเต็มเวลา และเขารับการ
อบรม 4-5 อาทิตยเต็ม นอกจากนี้ ยังมีกลุมเข็มขัดดําที่เปนผูเชี่ยวชาญที่มี
ประสบการณ ทําหนาทีเ่ ปนทรัพยากรทางเทคนิค และเปนพี่เลีย้ งใหกลุมระดับ
ที่ต่ํากวา
• องคการที่ใชหลักการซิกสซิกมาไดประสบความสําเร็จตองเต็มใจที่จะยอมรับ
วัตถุประสงคทแี่ ตกตางกันในเวลาเดียวกัน เชน ตองการเปนองคการที่
สรางสรรคและมีเหตุมีผล เนนที่ภาพรวม และรายงานรายละเอียด ลด
ขอผิดพลาดและทําสิง่ ตางๆ ใหเสร็จรวดเร็ว และทําใหลูกคามีความสุขและทํา
เงินไดมากๆ ซึง่ มีวัตถุประสงคขัดแยงกัน
• ซิกสซิกมาทํางานภายใตปรัชญาที่เนนที่ลกู คา และพยายามตอสูเพื่อขจัดของ
เสีย ยกระดับคุณภาพ และปรับปรุงประสิทธิภาพการเงิน

รูปที่ 7.8 การกระจายปกติและความเบี่ยนเบนมาตรฐาน

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคุณภาพโครงการ หนา 7-14

เนื่องจากความคิดของซิกสซิกมาคือ การปรับปรุงคุณภาพโดยการลดความแปรปรวน
คําวาซิกมาหมายถึงความเบี่ยงเบนมาตรฐาน ซึ่งใชวัดความแปรปรวนที่เกิดขึ้นจากการกระจายของ
ขอมูล คาความเบี่ยงเบนมาตรฐานต่ําหมายความวากลุมขอมูลใกลชิดกับคาเฉลี่ย และมีความ
แปรปรวนระหวางขอมูลนอย ถาคาความเบีย่ งเบนมาตรฐานสูงหมายความวาขอมูลหางจากคาเฉลี่ย
และมีความแปรปรวนคอนขางมาก
จากรูปที่ 7.8 แสดงการกระจายขอมูลแบบปกติ การกระจายแบบปกติใดๆ ที่รอ ยละ
68.3 ของประชากรอยูภายใน 1 คาเบี่ยงเบนมาตรฐาน (1 σ ) รอยละ 95.5 ของประชากรอยูภายใน 2
คาเบี่ยงเบนมาตรฐาน (2 σ ) และรอยละ 99.7 ของประชากรอยูใน 3 คาเบี่ยงเบนมาตรฐาน (3 σ ) คา
เบี่ยงเบนมาตรฐานเปนปจจัยหลักในการกําหนดจํานวนขอบกพรองทีพ่ บในประชากรที่จะยอมรับได

ตารางที่ 7.3 ซิกมาและจํานวนขอบกพรอง (Schwalbe, 2007)

รอยละของประชากรภายใน จํานวนขอบกพรองตอ
ชวง +/- ซิกมา
แตละชวง พันลาน
1 68.27 317,300,000
2 95.45 45,400,000
3 99.73 2,700,000
4 99.9937 63,000
5 99.999943 57
6 99.9999998 2

ตารางที่ 7.3 แสดงความสัมพันธระหวางคาเบี่ยงเบนมาตรฐานกับรอยละของประชากร

ภายในชวงซิกมา และจํานวนขอบกพรองตอพันลาน ±6σ หมายความวามีขอบกพรองเพียง 2 หนวย
ตอพันลานหนวย
แทนที่จะวัดจํานวนขอบกพรองตอหนวย (เชน ตอเครื่อง ตอใบ หรือตอโปรแกรม) ซิกส
ซิกมาวัดจํานวนขอบกพรองจากจํานวนของโอกาส เชน อาจมีหลายๆ ขอผิดพลาดในใบเรียกเก็บเงิน
เชน สะกดชื่อผิด ที่อยูผิด วันที่ใหบริการไมถูก และคํานวณผิด ดังนัน้ อาจมีโอกาสเกิดขอบกพรองไดถึง
100 จุดในใบเรียกเก็บเงินหนึ่งใบ ตารางที่ 7.4 คือ ตารางปรับคาซิกมา โดยที่อัตราผลตอบแทน (yield)
แทนจํานวนหนวยที่จัดการไดถูกตองตลอดขั้นตอนกระบวนการ จากตารางดังกลาว ณ 6 ซิกมา
หมายความวาขอบกพรองไมเกิน 3.4 จุดตอลานโอกาส

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคุณภาพโครงการ หนา 7-15

ตารางที่ 7.4 ตารางปรับคาซิกมา (Schwalbe, 2007)

จํานวนขอบกพรองตอลาน
ซิกมา อัตราผลตอบแทน (yield)
โอกาส
1 31.0% 690,000
2 69.2 % 308,000
3 93.3% 66,800
4 99.4% 6,210
5 99.97% 230
6 99.99966% 3.4

ถึงแมวา แนวความคิดของซิกสซิกมาเริ่มใชในอุตสาหกรรมการผลิต แตหลายเทคนิค

ของซิกสซิกมาสามารถนํามาใชไดโดยตรงกับโครงการพัฒนาซอฟตแวร เชน จํานวนขอผิดพลาดใน
คําสั่ง ชวงเวลาที่ระบบขัดของ

7.6.4 การทดสอบและการทวนสอบ
การทดสอบเปนงานที่เกือบขัน้ ตอนสุดทายของกระบวนการพัฒนาระบบ บางองคการ
คิดวาการทดสอบทํากอนการสงระบบงานใหกับลูกคาเพือ่ ใหระบบงานมีคุณภาพระดับหนึง่ แตความ
จริงแลวการทดสอบจําเปนตองทําระหวาง หรือเกือบทุกเฟสของวงจรชีวิตการพัฒนาระบบ สําหรับการ
ทดสอบระบบงานประกอบดวย
• การทดสอบหนวยยอย คือ กระบวนการทดสอบคําสั่งของมอดูลที่โปรแกรมเมอร
เขียนเพื่อใหคอมพิวเตอรทาํ งานอยางใดอยางหนึ่ง โดยมีวัตถุประสงคเพื่อคนหา
และแกไขขอผิดพลาดที่เกิดเทาที่จะเปนไปได กอนที่มอดูลนั้นจะถูกนําไปบูรณา
การกับมอดูลอื่นๆ ถาขอผิดพลาดถูกพบหลังจากการรวมหลายมอดูลเขา
ดวยกันแลว ขอผิดพลาดจะแกไขลําบากขึน้ และคาใชจา ยสูง การทดสอบวิธีการ
นี้เนนที่ตรรกะการประมวลผล และโครงสรางขอมูลภายในขอบเขตของมอดูล
• การทดสอบการบูรณาการ คือ การทดสอบพฤติกรรมของกลุมมอดูล เพื่อหา
ขอผิดพลาดทีไ่ มอาจตรวจพบจากการทดสอบหนวยยอย เชน การเชือ่ มประสาน
ไมเขากัน คาของพารามิเตอรไมใชคาที่คาดหวัง หรือ หนวยความจําไมพอ เมื่อ
พบขอผิดพลาดที่เกิดขึ้น ผูรับผิดชอบตองหาวามอดูลไหนทีเ่ กิดขอผิดพลาด
พรอมกับหาสาเหตุของขอผิดพลาด ในการทดสอบ ผูร ับผิดชอบตองสรางกรณี
ทดสอบ (test cases) และขอมูลเพื่อทดสอบเสนทางควบคุม (control paths) ที่

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคุณภาพโครงการ หนา 7-16

เปนไปไดทั้งหมด ยิ่งมีการทดสอบเสนทางควบคุมมากเทาไร เราจะมั่นใจที่พบ

ขอผิดพลาดทีส่ ําคัญมากขึน้ เทานัน้
• การทดสอบระบบ คือ การทดสอบการบูรณาการทัง้ ระบบ หรือระบบงานยอย
เพื่อใหแนใจวาระบบไมทาํ งานผิดปกติ และระบบทํางานไดตามที่ผพู ฒ ั นาเขาใจ
วาตรงกับความตองการของผูใช การทดสอบระบบที่สําคัญมีดังนี้
ƒ การทดสอบความสามารถใชงานได (usability testing) เปนการ
ทดสอบเพื่อดูวาระบบทํางานไดตรงกับความตองการของผูใชหรือไม
ƒ การทดสอบสมรรถนะ (performance testing) เปนการทดสอบวา
ระบบสามารถทํางานไดตามเกณฑหรือไม เชน เวลาตอบสนองกลับ
(response time) จํานวนการสอบถาม หรือจํานวนธุรกรรมที่ตอง
สามารถประมวลผลไดภายใน 1 นาที
ƒ การทดสอบความมัน่ คง (security testing) เปนการทดสอบระบบการ
ปองกันการเจาะทะลุเขาสูระบบงาน
ƒ การทดสอบการกูคืน (recovery testing) เปนการทดสอบวาเมื่อระบบ
ลมเหลวแลว วิธีการกูคืนที่กาํ หนดไวนนั้ สามารถดําเนินการไดถูกตอง
• การทดสอบการยอมรับ เปนการทดสอบวาระบบไดตอบสนองความตองการ
ของผูใชหรือไม โดยปกติ การทดสอบนี้เปนการทดสอบขั้นสุดทายกอนสงมอบ
ระบบงานใหผใู ช ผูทที่ ําการทดสอบในขั้นนี้จงึ เปนผูใชงานจํานวนมาก ซึ่งจะ
ทําใหผูพัฒนาระบบงานไดทราบวาระบบยังขาดฟงกชนั งานอะไร หรือฟงกชัน
งานใดที่ยงั ทํางานไดไมตรงกับที่ผูใชตองการ รวมถึงจอภาพ การไหลของ
จอภาพ และรายงานตางๆ ดวย

สําหรับแนวความคิดของการทวนสอบเกิดขึ้นมากวา 20 ป ในอุตสาหกรรมการบิน ซึง่ ให

ความสําคัญกับซอฟตแวรทที่ ํางานตามทีต่ ั้งใจไวทงั้ หมดอยางถูกตองและอยางนาเชื่อถือ เพราะ
ขอผิดพลาดใดๆ ในโปรแกรมสามารถสงผลใหเกิดหายนะ และคาใชจายมากมาย การทวนสอบนั้น
มุงเนนที่กิจกรรมกระบวนการที่เกี่ยวของของโครงการ เพื่อใหแนใจวาผลิตภัณฑ หรือสิ่งที่สง มอบตรงกับ
ความตองการที่กําหนดไวกอ นการทดสอบขั้นสุดทายจะเริ่มขึ้น การทวนสอบประกอบดวยการทบทวน 3
ประเภทคือ
• การทบทวนทางเทคนิค เพื่อใหแนใจวาผลลัพธสอดคลองกับความตองการที่
กําหนดไว การทบทวนประเภทนีย้ งั รวมถึงการทบทวนงานวาสอดคลองกับ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคุณภาพโครงการ หนา 7-17

ตามมาตรฐานตางๆ ดวย เชน มาตรฐาน GUI มาตรฐานการโปรแกรมและ

เอกสาร การตั้งชื่อ เปนตน วิธีการที่นยิ มใชในการทบทวนเชิงเทคนิคคือ การ
ตรวจตลอดและการตรวจตรา การตรวจตลอดคือ กระบวนการทบทวนที่
โปรแกรมเมอร หรือนักออกแบบพากลุมของโปรแกรมเมอรหรือนักออกแบบ
ตรวจตลอดโปรแกรมหรือแบบที่ออกไว เพือ่ ดูวาโปรแกรม หรือแบบทีอ่ อกนั้น
ถูกตองตามความตองการและมาตรฐานหรือไม สวนการตรวจตราคือ การ
ทบทวนโดยเพือ่ นรวมงาน โดยมีรายการคุณลักษณะทีส่ ําคัญใหกับผูต รวจใช
ระบุขอผิดพลาด รายการคุณลักษณะนี้ไดรับการปรับปรุงหลังจากการเก็บ
ขอมูล
• การทบทวนทางธุรกิจ คือ การทบทวนเพื่อใหแนใจวาผลิตภัณฑนนั้ มีฟง กชนั
งานที่ตองการตามทีก่ ําหนดในขอบเขตโครงการ อยางไรก็ตาม การทบทวน
ทางธุรกิจมีวัตถุประสงคเพื่อใหผลงานสมบูรณ ใหสารสนเทศที่จาํ เปนและ
ตองการสําหรับเฟสหรือกระบวนการถัดไป ตรงกับมาตรฐานทีก่ ําหนดไว
ลวงหนา และสอดคลองกับระเบียบวิธีของโครงการ
• การทบทวนเชิงบริหาร เปนการทบทวนโดยการเปรียบเทียบความกาวหนาที่
แทจริงกับแผนที่เปนบรรทัดฐานของโครงการ โดยทัว่ ๆ ไป ผูจัดการโครงการ
เปนผูรับผิดชอบนําเสนอความกาวหนาของโครงการเพื่อใหเห็นสถานภาพของ
โครงการที่ชัดเจน ประเด็นตางๆ ตองไดรับการแกไข ปรับทรัพยากร หรือ
ตัดสินใจวาจะยังคงโครงการหรือยุติโครงการ นอกจากนี้ ผูบริหารอาจทบทวน
โครงการเพื่อดูวาโครงการทํางานไดตามขอบเขต ระยะเวลา งบประมาณ และ
คุณภาพหรือไม

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

7.7.1 การบริหารคุณภาพของเดมมิง
เดมมิงเปนนักสถิติและศาสตราจารยทมี่ หาวิทยาลัยนิวยอรก เขาเปนที่รูจกั จากงาน
เกี่ยวกับการควบคุมคุณภาพในประเทศญี่ปุน เดมมิงไปประเทศญี่ปุนตามคําเชิญของรัฐบาลญี่ปุน เพื่อ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคุณภาพโครงการ หนา 7-18

ชวยปรับปรุงประสิทธิภาพและคุณภาพการผลิต เดมมิงสอนผูผลิตชาวญี่ปนุ วาคุณภาพหมายถึงประ

สิทธิที่เพิม่ ขึ้นและคาใชจายที่ต่ําลง อุตสาหกรรมอเมริกาไมตระหนักถึงทฤษฎีของเดมมิง จนกระทั่ง
ผูผลิตชาวญี่ปนุ ไดเริ่มผลิตสินคาที่ทา ทายสินคาอเมริกาอยางมาก โดยเฉพาะอุตสาหกรรมรถยนต
บริษัทฟอรดจึงรับวิธีการของเดมมิง และไดพบวาคุณภาพและยอดขายดีขึ้นอยางมากมาย หลังจากที่
เห็นผลงานที่ดีเยี่ยมในประเทศญี่ปุน บริษัทอเมริกาหลายๆ บริษทั ไดเชิญใหเดมมิงชวยสรางโปรแกรม
การปรับปรุงคุณภาพในโรงงานของตน
เดมมิงไดกําหนดขั้นตอนการบริหารคุณภาพ 4 ขั้นตอน คือ 1) วางแผน (plan) สําหรับ
การปรับปรุงคุณภาพ และระบุตัววัดที่เหมาะสม 2) ทํา (do) ตนแบบหรือการทดลองของแผนหรือตัววัด
ขนาดเล็ก 3) ตรวจสอบ (check) ผลกระทบของการดําเนินการของแผนการทดลอง 4) กระทํา (act) ตอ
สารสนเทศที่ไดรับจากการเรียนรู ขั้นตอนนี้มชี ื่อเรียกยอวา PDCA และแทนดวยวงกลมเดมมิง
(Demming circle) ดังรูปที่ 7.9

รูปที่ 7.9 PDCA ของเดมมิง

ปรัชญาและงานสอนของเดมมิงไดสรุปออกมา 14 ขอดังนี้

1. สรางความมัน่ คงใหกับจุดมุง หมายในการปรับปรุงระบบและบริการ องคการควร

กําหนดวัตถุประสงคใหชัดเจน และควรกลาวถึงทิศทางขององคการทั้งในปจจุบัน
และอนาคต การปรับปรุงควรทําอยางตอเนื่อง ถึงแมวาจะทําไดเพียงเล็กนอยก็
ตาม เพราะในที่สุดแลวองคการจะสามารถสรางการปรับปรุงมากขึน้ ผลลัพธที่ไดนี้
ไดจากการขจัดสิ่งทีท่ ําลายคุณภาพ เชน ขอบกพรองในสินคาที่ซื้อมา และเปลี่ยน
พฤติกรรมและทัศนคติของพนักงาน
2. ยอมรับปรัชญาใหมๆ ผูจัดการโครงการตองตื่นตัวกับความทาทาย เรียนรูความ
รับผิดชอบ และรับหนาที่ผนู าํ การเปลีย่ นแปลง
3. ยุติการตรวจตราเพื่อใหบรรลุคุณภาพ คุณภาพไมไดเกิดจากการคัดผลิตภัณฑที่
บกพรองโดยการใชวิธีการตรวจตราอยางหนัก คุณภาพเกิดจากการปรับปรุง

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคุณภาพโครงการ หนา 7-19

กระบวนการผลิต เดมมิงเสนอวิธีใหบรรลุคุณภาพดวยการควบคุมกระบวนการ
ดวยวิธกี ทางสถิติ
4. หยุดการเลือกผูขายโดยดูจากราคาเพียงอยางเดียว สินคาราคาต่าํ ไมใชสินคาที่
ราคาถูกสุด ถาสินคานัน้ ไมมีคุณภาพ และโดยเฉพาะ ถาผูขายไมใหบริการ
บํารุงรักษาที่เหมาะสม เดมมิงเสนอใหทาํ งานกับผูขายเพียงเจาเดียวที่ขายสินคาที่
มีคุณภาพ และสรางความสัมพันธกับคูคา ในระยะยาว ซึ่งจะทําใหคาใชจา ย
ทั้งหมดต่ํา
5. ปรับปรุงกระบวนการอยางตอเนื่อง การปรับปรุงประสิทธิภาพควรเปนงานที่ไมมี
ทางสิ้นสุด วัตถุประสงคไมควรเพื่อแกปญหา แตเปนการใหคํามั่นเพื่อการปรับปรุง
ที่ตอเนื่อง
6. จัดใหมีโปรแกรมการอบรมสําหรับการปรับปรุงคุณภาพ ขณะทีก่ ารศึกษาและการ
อบรมเปนคาใชจาย แตในระยะยาวแลว การขาดการศึกษาและการอบรมอาจทํา
ใหเสียเงินมากกวา การปรับปรุงประสิทธิภาพบรรลุไดดวยคน ดังนั้น คนเหลานี้จงึ
ควรไดรับการศึกษาและอบรมสําหรับงานที่ตองทํา ทุกคนตองไดรับการอบรมอยาง
ดี ความรูเปนสิ่งที่สาํ คัญตอการปรับปรุงคุณภาพ
7. สรางความเปนผูนาํ บทบาทพืน้ ฐานของผูบริหารคือ การเปนผูน าํ และความเปน
ผูนํานี้ควรจะเนนที่การปรับปรุงคุณภาพอยางตอเนื่อง ผูบริหารตองรับหนาที่เปน
ผูนําในการทําใหปรัชญาการบริหารคุณภาพเกิดขึ้น
8. ขับความกลัวออกไป พนักงานอาจหลีกเลี่ยงการแสดงความคิด และยอมรับ
ความผิด เพราะกลัวสูญเสียสถานภาพ ตําแหนงและแมแตงาน ดังนัน้ ผูบริหารตอง
ทําใหพนักงานรูสึกปลอดภัยในการสื่อสารบทเรียนที่ไดจากความผิดพลาดของตน
เพราะความผิดพลาดอาจใหคุณคาในการทํางานครัง้ ตอไป
9. ทําลายสิ่งกีดขวางระหวางหนวยงานองคการ คุณภาพจะทําไดดีทส่ี ุดโดยมีคนใน
แตละหนวยงานในองคการเขาใจหนวยงานอื่นและสื่อสารกันอยางสม่าํ เสมอ
สมาชิกตองทํางานเปนทีม
10. ขจัดสโลแกน เนื่องจากไมมีประโยชน สโลแกนปราศจากวิธีการ การควบคุมที่
เหมาะสม และคํามั่นของผูบ ริหาร การหาและการแกปญ  หากระบวนการและสินคา
อยางตอเนื่องนําไปสูการปรับปรุงคุณภาพที่ดีขึ้น
11. ขจัดโควตาและเปาหมายเชิงตัวเลข ภาระกิจที่ตองทําตามเปาหมายเชิงปริมาณจะ
ดึงคนทีท่ ํางานดีท่สี ุดใหถอยหลังและเครียดกวาคนที่ทที่ ํางานต่ํากวาคาเฉลี่ย ตัว

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคุณภาพโครงการ หนา 7-20

วัดตางๆ ไมควรกลายเปนวัตถุประสงคหลักของทัง้ องคการและการบริหาร

ผูบริหารควรใชความเปนผูน าํ แทน
12. ขจัดสิ่งกีดขวางความภาคภูมิใจในทักษะของงาน ประสิทธิภาพงานควรถูกประเมิน
และใหรางวัลในแงของคุณภาพ ไมใชโดยการจัดลําดับประจําป
13. สรางโปรแกรมการศึกษาและการปรับปรุงตัวเอง การศึกษาและการปรับปรุงตัวเอง
เปนสิ่งสําคัญสําหรับทุกคนในองคการ องคการสามารถสงเสริมการศึกษาดวยการ
สนับสนุนคาใชจา ย
14. ใหทุกคนมีสว นรวมเพื่อบรรลุการปรับเปลีย่ น การปรับเปลี่ยนเปนหนาที่ของทุกคน
ทุกคนตองมีสว นในการปรับปรุงกระบวนการและสินคาใหมีคุณภาพ

7.7.2 การบริหารคุณภาพของจูราน
จูรานไดสอนผูผ ลิตชาวญี่ปุนถึงการทําอยางไรจึงจะปรับปรุงประสิทธิภาพการผลิต เขา
ไดเขียนหนังสือคูมือการควบคุมคุณภาพ โดยเนนที่ความสําคัญของคํามัน่ ของผูบ ริหารระดับสูงเพื่อการ
ปรับปรุงคุณภาพอยางตอเนือ่ ง จูรานไดพฒ ั นาสามเหลีย่ มคุณภาพ หรือสามเหลีย่ มจูรานที่ประกอบดวย
การวางแผนคุณภาพ การปรับปรุงคุณภาพ และการควบคุมคุณภาพ แตละดานมีขนั้ ตอนดังนี้
• การวางแผนคุณภาพ
ƒ กําหนดวาใครคือลูกคา
ƒ กําหนดความตองการของลูกคาเหลานี้
ƒ แปลความตองการของลูกคาใหเปนภาษาของเรา
ƒ พัฒนาผลิตภัณฑที่สามารถตอบสนองความตองการเหลานี้
ƒ ทําคุณลักษณะผลิตภัณฑใหดีที่สุดซึ่งจะตรงกับความตองการทัง้ ของเรา
และลูกคา
• การปรับปรุงคุณภาพ
ƒ พัฒนากระบวนการที่สามารถผลิตผลิตภัณฑ
ƒ ทําใหกระบวนการดีที่สุด
• การควบคุมคุณภาพ
ƒ พิสูจนวากระบวนการที่ไดพัฒนาสามารถผลิตผลิตภัณฑภายใตเงือ่ นไข
การปฎิบัติงาน
ƒ สงผานกระบวนการนั้นเขาสูก ารดําเนินการ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคุณภาพโครงการ หนา 7-21

จูรานไดเนนความแตกตางระหวางมุมมองคุณภาพของผูผ ลิตกับมุมมองของลูกคา
ผูผลิตเนนคุณภาพในแงของความสอดกับความตองการ แตลูกคาเนนคุณภาพในแงของความเหมาะกับ
การใชงาน ไมใชเพียงแคตรงกับความตองการทีก่ ําหนดในรายละเอียด จูรานไดกําหนด 10 ขั้นตอนการ
บริหารคุณภาพดังนี้
• สรางความตระหนักถึงความตองการและโอกาสสําหรับการปรับปรุง
• กําหนดเปาหมายของการปรับปรุง
• จัดการใหถงึ เปาหมาย (จัดตั้งหนวยงานคุณภาพ ระบุปญหา เลือกโครงการ
มอบหมายทีมงาน กําหนดผูใ หความสะดวก)
• จัดอบรม
• ดําเนินโครงการเพื่อแกปญหา
• รายงานความกาวหนา
• ใหการระลึกถึงผูมีสวนรวม
• สื่อสารผลลัพธ
• รักษาคุณภาพใหคงอยู
• รักษาโมเมนตัมโดยการทําการปรับปรุงรายปใหเปนสวนหนึง่ ของระบบปกติ
และเปนสวนหนึ่งของกระบวนการขององคการ

7.7.3 ครอสบี และขอบกพรองเปนศูนย

ครอสบีไดพัฒนาความคิดของเขาหลายเรือ่ งจากประสบการณการทํางานใน
สายการผลิต เขาทํางานในหลายตําแหนงทีเ่ กี่ยวกับการควบคุมคุณภาพ เขาไดเสนอใหองคการควร
พยายามใหงานไมมีขอบกพรอง หรือขอบกพรองเปนศูนย เขาไดเนนวาคาใชจายของคุณภาพทีต่ ่ําจะ
รวมคาใชจายทั้งหมดของสิง่ ที่ไมทาํ ใหถกู ตองตั้งแตแรก เชน การทํางานใหม สูญเสียชั่วโมงการทํางาน
ของคนและเครื่องจักร คาประกัน เปนตน ครอสบีไดพัฒนา 14 ขั้นตอนของการปรับปรุงคุณภาพ
• ทําใหชัดเจนวาผูบริหารใหคํามั่นเกี่ยวกับคุณภาพ
• สรางทีมปรับปรุงคุณภาพโดยมีตัวแทนจากแตละหนวยงาน
• กําหนดปญหาคุณภาพที่เกิดในปจจุบันและที่มีศักยภาพในการปรับปรุง
• ประเมินคาใชจายของคุณภาพ
• ใหทุกคนตระหนักถึงประเด็นคุณภาพ
• ทําการแกไขปญหาที่ไดระบุจากขั้นตอนกอนหนานี้

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคุณภาพโครงการ หนา 7-22

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

ครอสบียังไดระบุอาการ 5 อยางที่จาํ เปนตองมีการบริหารคุณภาพ

• โดยทัว่ ไปสินคาหรือบริการทีผ่ ลิตมีความแตกตางจากความตองการของลูกคา
และหรือมาตรฐานที่ไดตกลง
• องคการมีการทํางานใหมอยางมากมาย และการทําการแกไขในสินคาที่สง
มอบแลว เพื่อใหคงความพึงพอใจของลูกคา
• ผูบริหารลมเหลวในการเปนผูนําคุณภาพ มาตรฐาน หรือแมแตนิยาม ผลจาก
ความไมเต็มใจนี้ทาํ ใหคนแตละคนพัฒนาคุณภาพตามความคิดของตน
• ผูบริหารไมตระหนักถึงคาใชจายแทจริงของสินคาที่ไมสอดคลองกับคุณภาพ
หรือคาใชจายที่ทาํ ใหสนิ คามีคุณภาพตามมาตรฐาน และความตองการของ
ลูกคา ผลที่ตามมาคือ ใชเงินทําในสิ่งที่ไมถกู ตอง และจําเปนตองทําใหม
• ผูบริหารปฏิเสธสาเหตุหลักของปญหาเกี่ยวกับคุณภาพ

ครอสบีไดพัฒนา 4 ปรัชญาการบริหารคุณภาพดังนี้
• คุณภาพไดรับการนิยามวา คุณภาพคือ ความสอดคลองกับความตองการของ
ลูกคา ไมใชสนิ คาที่ดี
• คุณภาพจะทําไดสําเร็จโดยการปองกันขอบกพรอง ไมใชการประเมินสินคา
• มาตรฐานคุณภาพคือ ไมมีขอ บกพรอง ไมใชระดับคุณภาพต่ําสุดที่ยอมรับได

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคุณภาพโครงการ หนา 7-23

• คุณภาพถูกวัดดวยราคาทีต่ องจายถาไมตรงกับความตองการของลูกคา ไมใช

วัดดวยตัวชีว้ ัด

7.7.4 อิชิคาวาและวงกลมคุณภาพ
อิชิคาวาเชื่อวาการปรับปรุงคุณภาพคือ กระบวนการตอเนื่องทีข่ ึ้นอยูกับทุกระดับใน
องคการ จากผูบริหารระดับสูงลงมาถึงคนงานทุกคน ในประเทศญี่ปุน ความเชื่อนีน้ าํ ไปสูการใชวงกลม
คุณภาพ (quality circle (QC)) ที่มีสมาชิกทุกคนในองคการเขารวม ในการทํา QC นิยมใชผงั กางปลา
สําหรับชวยหารากของสาเหตุของปญหาคุณภาพ อิชิคาวาไดเสนอคุณลักษณะสําคัญ 6 ประการสําหรับ
ทําใหงานมีคณ
ุ ภาพ
• การควบคุมคุณภาพทัง้ องคการหมายถึง ทุกหนวยงานและพนักงานทุกระดับ
เขามารวมในการทํางานอยางเปนระบบทีช่ ี้นําโดยนโยบายคุณภาพที่เขียนโดย
ผูบริหารระดับสูง ผลที่ตามมาคือ นักพัฒนาซอฟตแวรใหคํามัน่ ทีจ่ ะผลิตงานที่
มีคุณภาพ
• การตรวจสอบการควบคุมคุณภาพโดยผูบริหารระดับสูง ซึ่งจะออกตรวจเยี่ยม
แตละหนวยงานเพื่อหาอุปสรรคและขจัดมัน โดยปกติ การตรวจสอบซอฟตแวร
เปนหนาที่ของผูเชี่ยวชาญดานคุณภาพซอฟตแวร แตทีมงานตรวจสอบของ
ผูบริหารตองประเมินคุณภาพซอฟตแวรเปนระยะๆ การสนทนาโดยตรงกับผูใช
ซอฟตแวร ผูจัดการคุณภาพซอฟตแวร และผูจัดการการพัฒนาซอฟตแวรจะ
ชวยผูบริหารคนพบอุปสรรค
• การอบรมและการศึกษาในเรื่องการควบคุมคุณภาพสําหรับทุกคนในทุก
หนวยงานและทุกระดับ เพราะการควบคุมคุณภาพทัง้ องคการตองการใหทุก
คนมีสวนรวม การอบรมเริม่ แรกควรทําทีห่ นวยงานประกันคุณภาพซอฟตแวร
กอน แลวจึงขยายไปยังหนวยงานอืน่ ๆ
• กิจกรรมวงกลมคุณภาพเปนกลุมคนกลุม เล็กๆ ที่อาสาที่จะทําการควบคุม
คุณภาพในหนวยงานที่สังกัด ผังกางปลาเปนเครื่องมือที่สําคัญสําหรับทีมงาน
ในการวิเคราะหสาเหตุที่เปนไปไดทั้งหมด ทีมงานจะใหความสนใจกับสาเหตุ
นั้นและหมุนไปหาสาเหตุถดั ไปเพื่อขจัดมัน
• การประยุกตใชวิธีเชิงสถิติ เชน การวิเคราะหแบบพาเรโต แผนภูมิสาเหตุและ
ผล แผนภูมิแบบแทง ผังการกระจายขอมูล วิธกี ารทางสถิติอาจชวยให
นักพัฒนาซอฟตแวรดังไดกลาวมาแลว

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคุณภาพโครงการ หนา 7-24

• กิจกรรมสงเสริมการควบคุมคุณภาพใหไดรับรางวัลระดับชาติ ซึ่งจะทําให
ลูกคาเกิดความมั่นใจในคุณภาพสินคา

7.7.5 มาตรฐานไอเอสโอ
องคการไอเอสโอ ไดพัฒนาชุดมาตรฐานไอเอสโอ9001:2000 เปนมาตรฐานประกัน
คุณภาพที่ใชสาํ หรับวิศวกรรมสวนชุดคําสัง่ ซึง่ ครอบคลุมหัวขอ 5 หัวขอดังนี้
• ระบบบริหารคุณภาพ ประกอบดวยขอกําหนดทั่วไป ขอกําหนดการจัดเตรียม
เอกสารทัว่ ไป คูมือคุณภาพ การควบคุมเอกสาร และการควบคุมบันทึก
คุณภาพ
• ความรับผิดชอบของฝายบริหาร ประกอบดวยความมุงมัน่ ของฝายบริหาร
มุงเนนที่ลูกคา นโยบายคุณภาพ การวางแผน ความรับผิดชอบ อํานาจหนาที่
และการสื่อสาร การสื่อสารภายใน การทบทวนของฝายบริหาร
• การจัดการทรัพยากร ประกอบดวยการจัดสรรทรัพยากร ทรัพยากรบุคคล
สาธารณูปโภค สภาวะแวดลอมการทํางาน
• การทําใหผลิตภัณฑบรรลุผล ประกอบดวยการวางแผนใหผลิตภัณฑบรรลุผล
กระบวนการทีเ่ กี่ยวของกับลูกคา การออกแบบและการพัฒนา การจัดซื้อ
กระบวนการผลิตและบริการ การควบคุมอุปกรณ การเฝาติดตาม และการ
วัดผล
• การตรวจวัด การวิเคราะหและปรับปรุง ประกอบดวยบททัว่ ไป การตรวจวัด
และการติดตามผล การควบคุมผลิตภัณฑสิ่งที่ไมเปนไปตามขอกําหนด การ
วิเคราะหขอมูล การปรับปรุง

7.8 ตัววัด
ตัววัด (metric) เปนตัววัดเชิงปริมาณทีบ่ อกถึงคุณลักษณะของระบบ สวนประกอบ หรือ
กระบวนการวามีคุณลักษณะตามทีก่ ําหนดไวหรือไม เชน คุณลักษณะดานความสมบูรณ ความสามารถ
ในการบํารุงรักษาระบบ โดยที่ตัววัดประกอบดวยมาตรวัด (measure) ตั้งแต 2 ตัวมาเปรียบเทียบกัน แต
ตัววัดจะใหสารสนเทศที่สมบูรณกวามาตรวัด เชน มาตรวัดคุณภาพของซอฟตแวรคือ จํานวน
ขอผิดพลาด แตจํานวนขอผิดพลาดอยางเดียวอาจทําใหเขาใจผิดไดวาซอฟตแวรที่มีจาํ นวนขอผิดพาด
นอยมีคุณภาพดีกวาซอฟตแวรที่มีขอผิดพลาดมาก เนื่องจากถานําจํานวนคําสัง่ ทั้งหมดของซอฟตแวร

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคุณภาพโครงการ หนา 7-25

มาเปรียบเทียบดวย จะทําใหเกิดความเขาใจที่ชัดเจนมากขึ้นวา เมื่อเปรียบเทียบกับขนาดของซอฟตแวร

แลว ซอฟตแวรที่มีจาํ นวนขอผิดพลาดมากเมื่อเทียบกับขนาดของซอฟตแวรแลว ปรากฎวามีสดั สวนที่
นอยกวาซอฟตแวรที่มีจํานวนขอผิดพลาดนอย ตัววัดอาจเปนตัวชี้วัด (indicator) หรือตัววัดสมรรถนะ
(benchmark) คุณลักษณะของอุตสาหกรรมซอฟตแวร เชน สมมติวาความสามารถในการเขียนคําสั่ง
ของโปรแกรมเมอรโดยเฉลี่ยควรเปน 5 ฟงกชันพอยตตอเดือน ถาโปรแกรมเมอรขององคการของเราโดย
เฉลี่ยเขียนได 4 ฟงกชนั พอยต ซึ่งต่าํ กวาตัววัดสมรรถนะของอุตสาหกรรม ดังนั้นจะเห็นไดวา การใชมาตร
วัดเพียงตัวเดียวอาจทําใหเกิดการตัดสินใจที่ผิดพลาดได บางคนจะเรียกตัววัดวามาตรวัด

7.8.1 ประเภทของตัววัด
ตัววัดแบงออกเปน 3 ประเภทคือ ตัววัดกระบวนการ ตัววัดผลิตภัณฑ และตัววัด
โครงการ ตัวอยางและคําอธิบายตัววัดจากมารชูการและซอมเมอรวิว (Marchewka. 2006 และ
Sommerville. 2001) ไดแสดงในตารางที่ 7.5 รายละเอียดของตัววัดสามารถศึกษาเพิ่มเติมไดจาก
หนังสือ “Software Metrics” เขียนโดย เฟนตัน (Fenton) และ ฟลบเจอร (Pfleeger)
• ตัววัดกระบวนการ คือ ตัววัดที่ใชวัดคุณภาพของกระบวนการพัฒนาซอฟตแวร
เชน กระบวนการที่คน หาและขจัดขอบกพรองออกจากซอฟตแวร ซึง่ มีวธิ ีการ
คํานวณดังนี้

ประสิทธิภาพการขจัดขอบกพรอง = จํานวนขอผิดพลาด/(จํานวนขอผิดพลาด +
จํานวนขอบกพรอง)

ขอผิดพลาดคือ ขอผิดพลาดที่เกิดขึ้นกอนสงมอบผลิตภัณฑ
ขอบกพรองคือ ขอผิดพลาดที่เกิดขึ้นหลังสงมอบผลิตภัณฑ
• ตัววัดผลิตภัณฑ คือ ตัววัดที่เนนคุณภาพของผลิตภัณฑที่ผลิตออกมา และ
ความพึ่งพอใจของลูกคาตอผลิตภัณฑ เชน ความครบถวนของผลิตภัณฑ
ความนาเชื่อถือ (reliability) หรือความซับซอนของการออกแบบ เปนตน
ตัวอยางตัววัดความนาเชื่อถือคือ เวลาขัดของเฉลี่ย (mean time between
failure (MTBF)) ซึ่งมีวธิ ีการคํานวณดังนี้

MTBF = MTTF + MTTR

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคุณภาพโครงการ หนา 7-26

MTTF (mean time to failure) คือ เวลาเฉลี่ยที่ระบบขัดของ

MTTR (mean time to repair) คือ เวลาเฉลี่ยที่ใชในการซอมระบบให
สามารถกลับมาใชงานได
• ตัววัดโครงการ คือ ตัววัดทีใ่ ชควบคุมกระบวนการบริหารโครงการเพื่อใหแนใจ
วาโครงการบรรลุวัตถุประสงค รวมทั้งควบคุมเวลา และงบประมาณ เชน งาน
ที่ลาชา งานที่ใชเงินเกินงบประมาณ การเปลี่ยนแปลงขอบเขตงาน เปนตน
ตัวอยางวิธกี ารคํานวณตัววัดงานที่ลา ชาคือ

งานที่ลา ชา = จํานวนงานที่เริ่มดําเนินการแลว แตไมเสร็จตามเวลาที่คาดไว

ตารางที่ 7.5 ตัวอยางตัววัดกระบวนการ ผลิตภัณฑ และ โครงการ

ตัววัด
กระบวนการ
อัตราที่พบขอบกพรอง (defect arrival rate)
ขอบกพรองตามเฟส (defects by phase)
ขอบกพรองคงคาง (defect backlog)
ชวงเวลาที่ใชในการแกไข (fix response time)
การแกไขที่บกพรอง (defective fixes)
ผลิตภัณฑ
เวลาขัดของเฉลี่ย (mean time to failure)
ความหนาแนนของขอบกพรอง (defect density)
ขอบกพรองที่ลูกคาพบ (customer found
defects)
ความเหนียวแนน (cohesion)
การควบคู (coupling)
แฟนอิน/แฟนเอาต (fan-in/fan-out)
คําอธิบาย
จํานวนขอบกพรองที่พบในชวงเวลาหนึ่ง
จํานวนขอบกพรองที่พบในแตละเฟสของโครงการ
จํานวนขอบกพรองที่รอการแกไข
เวลาเฉลี่ยที่ใชในการแกไขขอบกพรองหนึ่งขอ
จํานวนการแกไขที่สรางขอบกพรองใหม
เวลาเฉลี่ยที่ซอฟตแวรไมสามารถทํางานได
จํานวนขอบกพรองตอจํานวนคําสั่งในโปรแกรม หรือฟงกชัน
พอยท
จํานวนขอบกพรองที่พบโดยลูกคา
จํานวนมอดูลที่มีความเหนียวแนนเชิงฟงกชันตอจํานวนมอดูล
ทั้งหมด
จํานวนการเชื่อมตอกับมอดูล
แฟนอิน คือ มาตรวัดจํานวนฟงกชันที่มาเรียกมอดูล X ที่เรากําลัง
พิจารณา สวนแฟนเอาต คือ จํานวนฟงกชันที่ถูกเรียกโดยมอดูล
X ถาคาของแฟนอินสูง หมายความวา มอดูล X ผูกติดกับฟงกชัน
อื่นๆ การแกไขมอดูล X จะมีผลกระทบอยางมาก ถาคาของแฟน
เอาตสูง แสดงวาโดยภาพรวมแลว มอดูล X มีความซับซอนสูง
อาจเปนเพราะความซับซอนของตรรกะการควบคุมตองประสาน

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคุณภาพโครงการ หนา 7-27

ตัววัด
ความยาวของโปรแกรม
ความพึงพอใจของลูกคา (customer
satisfaction)
โครงการ
คํารองขอเปลี่ยนแปลงขอบเขต (scope change
requests)
การอนุมัติการเปลี่ยนขอบเขต (scope change
approvals)
งานที่เกินเวลา (overdue tasks)
งานที่ควรเริ่มตนทําแลว (tasks that should have
started)
งานที่เกินงบประมาณ (over budgeted tasks)
มูลคาที่ไดรับ (earned value)
ทรัพยากรที่จัดสรรใหมากเกินไป (over allocated
resources)
อัตราการลาออก (turnover)
จํานวนชั่วโมงการอบรม (training hours)
คําอธิบาย
กับฟงกชันที่มอดูล X เรียกใช
โดยปกติ โปรแกรมที่ยาวมีความซับซอน
ตัวชี้วัดตัวหนึ่งที่ใชวัดความพึงพอใจของลูกคา โดยใชสเกลตั้งแต
1 (ไมพอใจมาก) จนถึง 5 (พอใจมาก)
จํานวนการเปลี่ยนแปลงขอบเขตที่รองขอโดยลูกคาหรือ
ผูสนับสนุน
จํานวนการเปลี่ยนแปลงขอบเขตที่ไดรับการอนุมัติ
จํานวนงานที่เริ่มทําแตไมเสร็จตามวันหรือเวลาที่กําหนด.
จํานวนงานที่ควรเริ่มแลวแตยังไมไดเริ่ม
จํานวนงานที่มีคาใชจายในการทํางานใหเสร็จมากกวา
งบประมาณที่กําหนด
คาใชจายของงานที่ไดทําคิดตามงบประมาณ (BCWP)
จํานวนทรัพยากรที่ไดรับมอบหมายงานมากกวาหนึ่ง
จํานวนสมาชิกของโครงการที่ลาออกหรือยุติการทํางาน
จํานวนชั่วโมงการอบรมตอสมาชิกโครงการหนึ่งคน

7.8.2 กระบวนการสรางตัววัด
กระบวนการทีใ่ ชในการสรางตัววัดมีขั้นตอนดังนี้
• การสรางสูตรตัววัดคือ การสรางมาตรวัด (measure) หรือตัววัดคุณลักษณะ
ของซอฟตแวรที่กําลังพิจารณา การสรางสูตรตัววัดมีหลักการดังนี้
ƒ กําหนดวัตถุประสงคการวัดกอนการรวบรวมขอมูล
ƒ นิยามตัววัดใหชัดเจน ไมกาํ กวม
ƒ ควรสรางตัววัดจากทฤษฎีทเี่ ปนจริงสําหรับโดเมนของระบบงานนั้นๆ
เชน ตัววัดการออกแบบควรสรางจากทฤษฎีการออกแบบ
ƒ ควรตัดแตงตัววัดใหเหมาะสมกับผลิตภัณฑและกระบวนการแตละ
อยางใหดีที่สุด

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคุณภาพโครงการ หนา 7-28

• การรวบรวมขอมูล เปนการใชกลไกเพื่อรวบรวมขอมูลทีต่ องการมาคํานวณหา

คาของมาตรวัด หรือตัววัดทีไ่ ดกําหนดไว การรวบรวมขอมูลควรมีวิธกี ารที่จะ
ทําอยางไรจึงจะเก็บขอมูลไดโดยอัตโนมัติ
• การวิเคราะหคือ การคํานวณตัววัด และการใชเครื่องมือทางคณิตศาสตรเพื่อ
การวิเคราะหขอ มูลที่ไดเก็บรวบรวม
• การแปลผลเปนการประเมินผลผลลัพธของตัววัดที่ได เพือ่ ใหเขาใจในคุณภาพ
ของคุณลักษณะของซอฟตแวร ทีมงานคุณภาพควรมีแนวทางการแปลผล และ
ขอเสนอแนะสําหรับแตละตัววัด
• การยอนกลับเปนการใหขอเสนอแนะจากการแปลผลตัววัด แลวสงกลับไปยัง
ทีมพัฒนาซอฟตแวร เพื่อดําเนินการปรับปรุงงาน หรือปรับตัววัดใหเหมาะสม

ความ า
สามา รุงรักษ
รถเคล
ื่อนยา ลี่ยน การท ามารถบํา
ย การปรับเป ร บ
ซอฟต ทวน ควา
มส
แว
าใ ชใหม
 ซอฟต แวร
ความย
ับ ม ืดหยุน
นํากล
มสามารถ
ควา
ควา
มสา
อง มาร
าม ถูกต ถใน
คว การ
ใชงา
น

รูปที่ 7.10 ปจจัยในการพิจารณาคุณภาพภายนอกของซอฟตแวรของเม็คคอล (1977)

(Pfleeger, 2001)

7.8.3 ตัววัดคุณภาพซอฟตแวรของเม็คคอล
เม็คคอล ไดเสนอปจจัยในการพิจารณาคุณภาพภายนอกของซอฟตแวรมี 3 กลุม 11
ปจจัย ดังแสดงในรูปที่ 7.10 สวนความหมายของปจจัยภายแสดงในตารางที่ 7.6

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคุณภาพโครงการ หนา 7-29

ตารางที่ 7.6 ความหมายของปจจัยวัดคุณภาพซอฟตแวร

ปจจัย ความหมาย
กลุมปจจัยคุณภาพดานการปฏิบัติงานของซอฟตแวร (product operation quality factors)
• ความถูกตอง (correctness) ซอฟตแวรสอดคลองกับขอกําหนดมากนอยแคไหน ตรงกับวัตถุประสงคของลูกคา
หรือไม
• ความนาเชื่อถือ (reliability) ซอฟตแวรสามารถทํางานไดถูกตองตามที่คาดไวแคไหน สามารถใชงานได
ตลอดเวลาหรือไม
• ความสามารถในการใชงาน การเรียนรู การสั่งงาน การเตรียมขอมูลนําเขา และการแปลผลลัพธตองใชความ
(usability) เพียรพยายาม (effort) มากนอยแคไหน
• ประสิทธิภาพ (efficiency) ระดับปริมาณทรัพยากรที่ซอฟตแวรตองใชในการทํางาน
• บูรณภาพ (integrity) ระดับความสามารถในการปองกันคนที่ไมมีสิทธิไมใหเขาถึงซอฟตแวรหรือขอมูล
กลุมปจจัยคุณภาพดานการปรับเปลี่ยน (product transition quality factors)
• ความสามารถเคลื่อนยาย ความพยายามที่ตองใชในการยายซอฟตแวรจากฮารดแวรหนึ่งไปยังฮารดแวรหนึ่ง
(portability) หรือจากซอฟตแวรระบบหนึ่งไปยังซอฟตแวรระบบอีกระบบหนึ่ง
• ความสามารถนํากลับมาใชใหม ระดับที่โปรแกรมสามารถนํากลับมาใชในระบบงานอื่น
(reusability)
• ความสามารถในการทํางาน ความพยายามที่ตองใชในการเชื่อมประสานกับระบบอื่น
ระหวางระบบ (interoperability)
กลุมปจจัยคุณภาพดานการทบทวน (product revision quality factors)
• ความสามารถบํารุงรักษา ระดับความพยายามที่ตองใชในการแกไขขอผิดพลาดในซอฟตแวร
(maintainability)
• ความยืดหยุน (flexibility) ระดับความพยายามที่ตองใชในการดัดแปร หรือแกไขซอฟตแวร
• ความสามารถทดสอบ ความพยายามที่ตองใชในการทดสอบโปรแกรม เพื่อใหแนใจวาซอฟตแวรทํางานได
(testability) อยางถูกตองตามที่ลูกคาตองการ

แตละปจจัยดังกลาวขางตนมีตัววัดสําหรับการวัดคุณภาพของปจจัยนั้นๆ ดังแสดงใน
ตารางที่ 7.7 ซึ่งจะเห็นวาตัววัดตัวหนึ่งสามารถใชวัดปจจัยคุณภาพไดมากกวา 1 ปจจัย ความหมายของ
ตัววัดแตละตัวแสดงในตารางที่ 7.8

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคุณภาพโครงการ หนา 7-30

ตารางที่ 7.7 ปจจัยคุณภาพ 11 ปจจัย 23 ตัววัด

ความสามารถในการทํางาน
ความสามารถในการใชงาน

ความสามารถนํากลับมาใช
ความสามารถเคลื่อนยาย

ความสามารถบํารุงรักษา

ความสามารถทดสอบ
ความนาเชื่อถือ

ระหวางระบบ

ความยืดหยุน
ประสิทธิภาพ
ความถูกตอง

บูรณภาพ

ใหม
ความสามารถตามรอย
(traceability)
ความสมบูรณ (completeness)
ความสอดคลอง (consistency)
ความแมนยํา (accuracy)
ความทนทานตอขอผิดพลาด (error
tolerance)
ประสิทธิภาพการปฎิบัติงาน
(execution efficiency)
ประสิทธิภาพที่เก็บขอมูล (storage
efficiency)
การควบคุมการเขาถึง (access
control)
การตรวจสอบการเขาถึง (access
audit)
ความสามารถในการปฏิบัติ
(operability)
การอบรม (training)
ความสามารถสื่อสาร
(communicativeness)
ความงาย (simplicity)
ความกระทัดรัด (conciseness)
ความเปนเครื่องมือ
(instrumentation)
การอธิบายดวยตัวเอง (self-
descriptiveness)
ความสามารถในการขยาย
(expandability)
ลักษณะทั่วไป (generality)
สภาพมอดุลาร (modularity)

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคุณภาพโครงการ หนา 7-31

ความสามารถในการทํางาน
ความสามารถในการใชงาน

ความสามารถนํากลับมาใช
ความสามารถเคลื่อนยาย

ความสามารถบํารุงรักษา

ความสามารถทดสอบ
ความนาเชื่อถือ

ระหวางระบบ

ความยืดหยุน
ประสิทธิภาพ
ความถูกตอง

บูรณภาพ

ใหม
ความเปนอิสระจากระบบซอฟตแวร
(software system independence)
ความเปนอิสระจากเครื่องจักร
(machine independence)
การรวมกันของการสื่อสาร
(communication commonality)
การรวมกันของขอมูล (data
commonality)

ตารางที่ 7.8 ความหมายของตัววัดคุณภาพซอฟตแวร

ตัววัด ความหมาย
ความสามารถตามรอย (traceability) ความสามารถในการตามรอยแบบ หรือสวนโปรแกรมกลับไปยังความ
ตองการ
ความสมบูรณ (completeness) ระดับที่ฟงกชันที่ตองการไดรับการดําเนินการครบถวน
ความสอดคลอง (consistency) มีการใชเทคนิคการออกแบบ และเอกสารหลักฐานในรูปแบบเดียวกัน
ทั้งโครงการ
ความแมนยํา (accuracy) ความแมนยําของการคํานวณและการควบคุม
ระดับการยอมรับขอผิดพลาด (error ความเสียหายที่เกิดขึ้นเมื่อซอฟตแวรประสบขอผิดพลาด
tolerance)
ประสิทธิภาพการปฎิบัติงาน (execution ประสิทธิภาพการใชเวลาในการทํางานของโปรแกรม
efficiency)
ประสิทธิภาพที่เก็บขอมูล (storage efficiency) ประสิทธิภาพการใชที่สําหรับจัดเก็บขอมูล
การควบคุมการเขาถึง (access control) ความสามารถในการควบคุมผูไมมีสิทธิ์ไมใหเขาใชซอฟตแวรและขอมูล
การตรวจสอบการเขาถึง (access audit) ความงายในการตรวจสอบความสอดคลองกับมาตรฐาน
ความสามารถในการปฏิบัติ (operability) ความงายในการปฏิบัติการ
การอบรม (training) ระดับที่ชวยใหผูใชใหมสามารถใชระบบ
ความสามารถสื่อสาร (communicativeness) ระดับที่ผูใชสามารถเขาใจการทํางานของระบบ
ความงาย (simplicity) ระดับความยาก-งายในการทําความเขาใจโปรแกรม
ความกระทัดรัด (conciseness) ความกระชับของคําสั่งที่เขียนในโปรแกรม
ความเปนเครื่องมือ (instrumentation) ระดับที่โปรแกรมติดตามการทํางานของตัวเองและชี้ขอผิดพลาดที่

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคุณภาพโครงการ หนา 7-32

ตัววัด ความหมาย
เกิดขึ้น
การอธิบายดวยตัวเอง (self-descriptiveness) ระดับที่โปรแกรมเปนเอกสารที่มีความหมาย
ความสามารถในการขยาย (expandability) ระดับที่แบบเชิงสถาปตยกรรม โครงสรางขอมูล หรือขั้นตอน สามารถ
ขยายได
ลักษณะทั่วไป (generality) สวนโปรแกรมสามารถประยุกตใชไดกวางแคไหน
สภาพมอดุลาร (modularity) สวนโปรแกรมแยกอิสระตามฟงกชัน
ความเปนอิสระของระบบซอฟตแวร (software ระดับที่เปนอิสระจากคุณลักษณะของภาษาการโปรแกรม ลักษณะ
system independence) ระบบปฏิบัติการ หรือเงื่อนไขบังคับอื่นๆ ที่ไมใชมาตรฐาน
ความเปนอิสระของเครื่องจักร (machine ระดับที่ซอฟตแวรเปนอิสระจากเครื่องจักรที่มันตองทํางาน
independence)
การรวมกันของการสื่อสาร (communication ระดับการใชมาตรฐานในการเชื่อมตออุปกรณ โปรโตคอล หรือความ
commonality) กวางแถบความถี่ (bandwidth)
การรวมกันของขอมูล (data commonality) การใชโครงสรางขอมูลและประเภทขอมูลที่เปนมาตรฐานทั้งซอฟตแวร

เมื่อตองการหาคุณภาพของแตละปจจัย เราตองกําหนดสูตรตัววัดตางๆ ของแตละ

ปจจัย พรอมน้าํ หนักของแตละตัววัด หลังจากนั้นจึงนําคาตัววัดคูณกับน้ําหนัก ตัวอยางเชน

Fflexibility = a1 * Complexity + a2 * Concision + a3 * Consistency + ….

โดย a1, a2, a3, … คือ น้ําหนักของตัววัด

7.9 ตัวแบบวุฒิภาวะความสามารถแบบบูรณาการ
ป 1988 สถาบันวิศวกรรมซอฟตแวร (SEI) ไดพัฒนาตัวแบบวุฒิภาวะความสามารถสําหรับวัด
องคการวามีระดับการพัฒนาซอฟตแวรระดับใดที่เรียกวา CMM (Capability Maturity Model) ซึ่งตัว
แบบดังกลาวมีหลายตัวแบบ เชน ตัวแบบวุฒิภาวะความสามารถสําหรับซอฟตแวร (SW-CMM) ตัวแบบ
วุฒิภาวะความสามารถสําหรับวิศวกรรมระบบ (system engineering CMM) เปนตน
ตอมาในป ค.ศ. 2003 สถาบันวิศวกรรมซอฟตแวรไดพัฒนากระบวนการแบบเบ็ดเสร็จเพื่อเปน
แนวทางใหองคการบรรลุระดับวุฒิภาวะและความสามารถระดับตางๆ ที่เรียกวา CMMI (Capability
Maturity Model Integration) CMMI มี 2 ตัวแบบคือ ตัวแบบทีเ่ ปนตัวแทนแบบขั้นตอน (staged
representation) และตัวแบบที่เปนตัวแทนแบบตอเนือ่ ง (continuous representation) ทั้ง 2 ตัวแบบจะ
ประกอบดวย กลุมกระบวนการ (process area) เปาหมายเฉพาะ วิธีปฏิบัติเฉพาะ (specific goals
and practices) เปาหมายทัว่ ไปและวิธีปฏิบัติทั่วไป (general goals and practices) แตตัวแบบที่เปน

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคุณภาพโครงการ หนา 7-33

ตัวแทนแบบตอเนื่องจะเนนที่ความสามารถของกลุมกระบวนการ โดยวัดเปนระดับความสามารถ
(capability level (CL)) ของกลุมกระบวนการแตละกลุม สวนตัวแบบที่เปนตัวแทนแบบขั้นตอนเนนที่
วุฒิภาวะองคการ โดยวัดเปนระดับวุฒิภาวะ (maturity level (ML)) ของกลุมกระบวนการหลายกลุม
กระบวนการ โครงสรางโดยรวมของตัวแบบทั้งสองจะประกอบดวยสวนประกอบที่สาํ คัญคือ
• กลุมกระบวนการ ประกอบดวยกลุมวิธีปฏิบัติที่สัมพันธกันในเรื่องทีเ่ มือ่ ดําเนินการแลวทํา
ใหเกิดการปรับปรุงในเรื่องนั้นอยางมีนยั สําคัญ ตัวแบบทั้งสองของ CMMI มีกลุม
กระบวนการรวมกัน
• เปาหมายเฉพาะ เปนเปาหมายที่ใชกับกลุมกระบวนการและกําหนดคุณลักษณะเฉพาะที่
บรรยายถึงสิ่งที่ตองทําเพื่อตอบสนองกลุม กระบวนการนัน้
• วิธีปฏิบัติเฉพาะ คือ กิจกรรมที่สําคัญเพื่อการบรรลุเปาหมายเฉพาะทีเ่ กี่ยวของ
• เปาหมายทัว่ ไป คือ เปาหมายเดียวกันที่ปรากฏในหลายกลุมกระบวนการ แตละกลุม
กระบวนการมีเปาหมายทัว่ ไปเพียง 1 เปาหมาย
• ลักษณะรวม มี 4 ลักษณะคือ
ƒ พันธกิจในการดําเนินงาน (commitment to perform (CO))
ƒ ความสามารถในการดําเนินงาน (ability to perform (AB))
ƒ การกํากับการนําไปใชจริง (directing implementation (DI))
ƒ การทวนสอบการดําเนินการ (verification implementation (VE))
• วิธีปฏิบัติทวั่ ไป เปนวิธีปฏิบัติที่เปนสวนหนึง่ ขององคการเพื่อใหแนใจวา กระบวน การที่
เกี่ยวของกับกลุมกระบวนการจะมีประสิทธิผล สามารถนํามาทําซ้าํ และคงอยู วิธีปฏิบัติ
จัดตามเปาหมายทั่วไป และลักษณะรวม

7.9.1 ตัวแบบที่เปนตัวแทนแบบขั้นตอน
เปนตัวแบบที่เสนอวิธกี ารอยางเปนระบบและมีโครงสรางเพื่อปรับปรุงกระบวนครั้งละ
ขั้น การบรรลุแตละขั้นจะเปนฐานสําหรับขั้นตอไป ตัวแทนแบบขั้นตอนกําหนดลําดับการทํากลุม
กระบวนการตามระดับวุฒิภาวะจากระดับเริ่มตนจนถึงระดับที่ดีที่สุด
ตัวแบบนี้ประกอบดวยวิธีปฏิบัติทั่วไปและวิธปี ฏิบัติเฉพาะที่สัมพันธกันสําหรับชุดกลุม
กระบวนการทีไ่ ดกําหนดไวแลวเพื่อปรับปรุงการดําเนินงานโดยรวมขององคการ โครงสรางโดยรวมของ
ตัวแบบนี้แสดงในรูปที่ 7.11 ระดับวุฒิภาวะขององคการนี้เปนวิธีทํานายการดําเนินงานขององคการ
ภายใตระเบียบวินยั ทีก่ ําหนด จากประสบการณจากหลายๆ องคการแสดงใหเห็นวา องคการทํางานไดดี
ที่สุดเมื่อองคการใชความพยายามในการปรับปรุงกระบวนการแตละครัง้ ไปที่จํานวนกลุมกระบวนการที่

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคุณภาพโครงการ หนา 7-34

สามารถบริหารจัดการได ตัวแบบที่เปนตัวแทนแบบขัน้ ตอน CMMI มีระดับวุฒิภาวะ 5 ระดับ ดังแสดง

ในรูปที่ 7.12
ระดับวุฒิภาวะ

กลุมกระบวนการ 1 กลุมกระบวนการ 2 กลุมกระบวนการ n

เปาหมายเฉพาะ เปาหมายทั่วไป
ลักษณะรวม

พันธกิจในการ ความสามารถใน การกํากับการ การตรวจสอบการ

วิธีปฏิบัติเฉพาะ ดําเนินงาน การดําเนินงาน นําไปใชจริง ดําเนินการ

วิธีปฏิบัติทั่วไป

รูปที่ 7.11 โครงสรางโดยรวมของตัวแบบที่เปนตัวแทนแบบขั้นตอน

(Chrissis, et.al. 2007)

เนนที่การปรับปรุงกระบวนการอยางตอเนื่อง ดีที่สุด
5
จัดการเชิง
กระบวนการถูกวัดและควบคุม
4 ปริมาณ

กระบวนการไดถูกจัดสําหรับองคการ, นิยาม
3 และเปนปฏิบัติการเชิงรุก
จัดการ
กระบวนการไดถูกจัดสําหรับโครงการ,
2 และมักเปนการตอบสนองเหตุการณ

กระบวนการไมสามารถคาดการณได, เริ่มตน
1 ควบคุมไมเพียงพอ
และเปนการตอบสนองเหตุการณ

รูปที่ 7.12 ระดับวุฒิภาวะของตัวแบบที่เปนตัวแทนแบบขั้นตอน (Ahern, et.al, 2004)

วุฒิภาวะระดับ 1: ระดับเริ่มแรก (initial level)

เปนระดับทีก่ ระบวนการเปนกระบวนการเฉพาะกิจ และสับสน ไมสามารถคาดการณ
กระบวนการได ขาดการควบคุม โดยปกติ องคการไมจัดหาสภาวะแวดลอมที่คงที่ ความสําเร็จของ
องคการประเภทนี้ขึ้นกับความสามารถและความเกงของคนในองคการ และไมใชการใชกระบวนการ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคุณภาพโครงการ หนา 7-35

นอกจากความสับสนแลว องคการผลิตผลิตภัณฑและบริการที่ทาํ งานได แตการผลิตนั้นจะเกิน

งบประมาณและไมตรงกับระยะเวลาของโครงการ
วุฒิภาวะระดับ 1 นัน้ องคการสัญญาเกินจริง การยกเลิกกระบวนการในเวลาวิกฤติ และไม
สามารถทําความสําเร็จซ้าํ ไดอีก

วุฒิภาวะระดับ 2: ระดับจัดการ (managed level)

วุฒิภาวะระดับ 2 นี้ กระบวนการของโครงการไดถูกวางแผนและทําตามนโยบายของ
องคการ โครงการใชคนที่มที ักษะที่มที รัพยากรเพียงพอที่จะสรางผลลัพธ และผูม ีสว นไดเสียที่เกีย่ วของ
โครงการไดรับการติดตาม ควบคุมและทบทวน และประเมิน เมื่อโครงการกําหนดวิธีปฏิบัติของ
กระบวนการเหลานี้ โครงการดําเนินการและจัดการตามแผนที่ไดบันทึกไว ระเบียบวินัยกระบวนการที่
สะทอนในวุฒภิ าวะระดับสองชวยใหแนใจวาวิธีปฏิบัติทมี่ ีอยูจะยังคงอยูในชวงเวลาที่ตรึงเครียด
ณ ระดับนี้ ผูบริหารสามารถเห็นหรือทราบสถานภาพของผลของงาน และการใหบริการตาม
แผนที่กาํ หนด พันธกิจทีถ่ ูกกําหนดโดยผูมีสวนไดเสียที่เกี่ยวของจะไดรับการทบทวนตามความจําเปน
ผลของงานไดรับการทบทวนกับผูมีสว นไดเสีย และไดรับการควบคุมอยางเหมาะสม งานและบริการ
ตอบสนองรายละเอียดของกระบวนการ มาตรฐานและขั้นตอนที่ไดกาํ หนด

วุฒิภาวะระดับ 3: ระดับนิยาม (defined level)

กระบวนการมีลักษณะทีช่ ัดเจนและเขาใจได กระบวนการมีรายละเอียดตามมาตรฐาน
ขั้นตอน และวิธีการ องคการกําหนดชุดกระบวนการมาตรฐาน และปรับปรุงตลอดมา กระบวนการ
มาตรฐานใชสรางความสอดคลองทั้งองคการ โครงการกําหนดกระบวนการของโครงการเอง โดยแกไข
จากกระบวนการมาตรฐานขององคการตามแนวทางการแกไขที่องคการไดกําหนด
ความแตกตางระหวางวุฒิภาวะระดับที่ 2 และ 3 คือ ขอบเขตของมาตรฐาน คําอธิบาย
กระบวนการ และขั้นตอน สําหรับวุฒิภาวะระดับ 2 นัน้ มาตรฐาน คําอธิบายกระบวนการ และขั้นตอน
อาจแตกตางกันในแตละโครงการ แตวุฒภิ าวะระดับ 3 มาตรฐาน คําอธิบายกระบวนการ และขัน้ ตอน
จะถูกตบแตงจากกระบวนการมาตรฐานขององคการ เพื่อใหเหมาะกับโครงการนัน้ ๆ ผลลัพธที่ไดคือ
กระบวนการทีด่ ําเนินการทั่วทั้งองคการสอดคลองกันมากขึ้น ยกเวนสวนที่แตกตางกันไดตามทีอ่ นุญาต
ในแนวทางการแกไข นอกจากนี้กระบวนการของระดับ 3 ไดอธิบายรายละเอียดและเขมงวดมากกวา
กระบวนการของระดับ 2 กระบวนการในระดับ 3 กลาวชัดเจนถึงวัตถุประสงค ขอมูลนําเขา เงื่อนไขการ
เขา กิจกรรม บทบาท มาตรวัด ขั้นตอนการทวนสอบ ผลลัพธ และเงื่อนไขการออก ระดับนี้ กระบวนการ
ไดรับการบริหารเชิงรุกโดยการใชความเขาใจความสัมพันธของกิจกรรมกระบวนการและมาตรวัดที่
ละเอียดของกระบวนการ ผลงานของกระบวนการและบริการ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคุณภาพโครงการ หนา 7-36

วุฒิภาวะระดับ 4: ระดับจัดการเชิงปริมาณ (quantitatively managed level)

องคการกําหนดวัตถุประสงคเชิงปริมาณสําหรับคุณภาพและประสิทธิภาพของกระบวนการ
และใชมันเปนเงื่อนไขในการบริหารกระบวนการ วัตถุประสงคเชิงปริมาณถูกกําหนดตามความตองการ
ของลูกคา ผูใชสุดทาย องคการ และผูดําเนินการทํากระบวนการ คุณภาพและประสิทธิภาพกระบวนการ
ถูกบริหารโดยสถิติและถูกจัดการตลอดชีวติ ของกระบวนการ
สําหรับกระบวนการยอยจะมีมาตรวัดประสิทธิภาพของกระบวนการทีล่ ะเอียด และจะถูก
รวบรวมและวิเคราะหเชิงสถิติ มาตรวัดคุณภาพและประสิทธิภาพจะรวมอยูในคลังมาตรวัดขององคการ
เพื่อสนับสนุนการตัดสินใจตามขอเท็จจริง พรอมทั้งระบุสาเหตุเฉพาะทีท่ ําใหกระบวนการมีความ
แปรปรวน ตนตอของสาเหตุนี้จะไดรับการแกไขเพื่อปองกันการเกิดความแปรปรวนในอนาคต
ความแตกตางระหวางวุฒิภาวะระดับที่ 3 และ 4 คือ ความสามารถทํานายประสิทธิภาพ
ของกระบวนการ สําหรับวุฒิภาวะระดับที่ 4 นัน้ ประสิทธิภาพกระบวนการถูกควบคุมดวยเทคนิคทาง
สถิติ และเทคนิคเชิงปริมาณอื่นๆ และสามารถทํานายอยางเชิงปริมาณได สวนระดับที่ 3 กระบวนการ
สามารถทํานายไดเฉพาะเชิงคุณภาพ

วุฒิภาวะระดับ 5: ระดับดีที่สุด (optimizing)

องคการปรับปรุงกระบวนการอยางตอเนื่องตามสาเหตุของความแปรปรวนทีซ่ อนใน
กระบวนการ โดยการทํานวัตกรรมกระบวนการและการปรับปรุงเชิงเทคโนโลยี องคการกําหนด
วัตถุประสงคของการปรับปรุงกระบวนการเชิงปริมาณ ทบทวนอยางตอเนื่องเพื่อสะทอนการ
เปลี่ยนแปลงวัตถุประสงคทางธุรกิจ และใชเปนเกณฑในการจัดการการปรับปรุงกระบวนการ มีการ
วัดผลกระทบของการปรับปรุงกระบวนการ และทําการประเมินเทียบกับวัตถุประสงคการปรับปรุง
กระบวนการตามที่ไดกาํ หนดไว
ความแตกตางระหวางวุฒิภาวะระดับที่ 4 และ 5 คือ ประเภทความแปรปรวน ณ วุฒิภาวะ
ระดับ 4 องคการจะตระหนักถึงการกําหนดสาเหตุเฉพาะของความแปรปรวนของกระบวนการ และ
ความสามารถทํานายผลเชิงสถิติ ถึงแมวากระบวนการอาจใหผลลัพธที่สามารถคาดการณได แตผลที่ได
นั้นอาจไมเพียงพอที่จะบรรลุวัตถุประสงคทไี่ ดกําหนดไว สวนระดับที่ 5 นั้น กระบวนการจะไดรับการ
สนใจเกี่ยวกับสาเหตุรวมของการแปรปรวนของกระบวนการ และการเปลี่ยนแปลงกระบวนการเพือ่ ทําให
ประสิทธิภาพของกระบวนการดีขึ้น (นั่นคือ การยายคาเฉลี่ยของประสิทธิภาพของกระบวนการใหสูงขึน้
หรือลดความแปรปรวน)
ตัวแบบที่ตัวแทนเปนแบบขัน้ ตอนมีกลุมกระบวนการทัง้ หมด 25 กลุม ดังแสดงในตารางที่
7.9

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคุณภาพโครงการ หนา 7-37

ตารางที่ 7.9 กลุมกระบวนการของตัวแบบที่ตัวแทนเปนแบบขัน้ ตอน

ระดับ CMMI กลุมกระบวนการ
ระดับจัดการ การจัดการความตองการ (requirements management)
การวางแผนโครงการ (project planning)
การติดตามและควบคุมโครงการ (project monitoring and control)
การบริหารขอตกลงกับผูขาย (supplier agreement management)
การวัดและการวิเคราะห (measurement and analysis)
การประกันคุณภาพผลิตภัณฑและกระบวนการ (process and product quality assurance)
การจัดการคอนฟกรูเรชัน (configuration management)
ระดับนิยาม การพัฒนาความตองการ (requirements development)
คําตอบเชิงเทคนิค (technical solution)
การบูรณาการผลิตภัณฑ (product integration)
การทวนสอบ (verification)
การตรวจสอบวาใชการได (validation)
การมุงเฉพาะสวนกระบวนการเชิงองคการ (organizational process focus)
การนิยามกระบวนการเชิงองคการ (organizational process definition)
การอบรมเชิงองคการ (organizational training)
การจัดการโครงการแบบบูรณาการ (integrated project management)
การจัดการความเสี่ยง (risk management)
การทําทีมแบบบูรณาการ (integrated teaming)
การจัดการผูขายแบบบูรณาการ (integrated supplier management)
การวิเคราะหการตัดสินใจ และการแกไข (decision analysis and resolution)
สภาพแวดลอมเชิงองคการสําหรับการบูรณาการ (organizational environment for
integration)
ระดับจัดการเชิง กระบวนการเชิงองคการสําหรับการดําเนินงาน (organizational process for performance)
ปริมาณ
การบริหารโครงการเชิงปริมาณ (quantitative project management)
ระดับดีที่สุด นวัตกรรมเชิงองคการ และการเตรียมพรอม (organizational innovation and deployment)
การวิเคราะหเชิงเหตุผลและการแกไข (casual analysis and resolution)

7.9.2 ตัวแบบที่เปนตัวแทนแบบตอเนื่อง
ตัวแบบนี้ยอมใหองคการเลือกวาจะใชความพยายามในการปรับปรุงกลุมกระบวนการ
ใดที่ดีที่สุดสําหรับองคการ กลุมกระบวนการแบงออกเปน 4 หมวด คือ การบริหารกระบวนการ การ
บริหารโครงการ การวิศวกรรม และการสนับสนุน เมือ่ เลือกกลุมกระบวนการแลว องคการตองเลือก

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคุณภาพโครงการ หนา 7-38

ระดับความสามารถที่ตองการ เชน องคการอาจตองการใหกลุมกระบวนการหนึง่ บรรลุระดับ

ความสามารถระดับที่ 2 ขณะที่อีกกลุม กระบวนการหนึง่ องคการตองการใหบรรลุระดับความสามารถ
ระดับที่ 4

รูปที่ 7.13 โครงสรางโดยรวมของตัวแบบที่เปนตัวแทนแบบตอเนื่อง

(Chrissis, et.al., 2007)

ระดับความสามารถประกอบดวยเปาหมายทั่วไปและวิธีปฏิบัติทั่วไปที่สมั พันธกนั ซึง่

สามารถปรับปรุงกระบวนการขององคการที่เกี่ยวของกับกลุมกระบวนการ กลุมกระบวนการมีวิธปี ฏิบัติที่
ไดจัดในลักษณะที่สนับสนุนการเติบโตและการปรับปรุงของกลุมกระบวนการแตละกลุม วิธีปฏิบตั ิทั่วไป
จัดเปนกลุมเรียกวาระดับความสามารถดังแสดงในรูปที่ 7.13 ตัวแบบนี้ประกอบดวยระดับความสามารถ
6 ระดับ ดังแสดงในรูปที่ 7.14 แตละระดับมีความหมายดังนี้

รูปที่ 7.14 ระดับความสามารถของตัวแบบที่เปนตัวแทนแบบตอเนื่อง

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคุณภาพโครงการ หนา 7-39

ความสามารถระดับ 0: ระดับไมสมบูรณ (incomplete level)

กระบวนการทีไ่ มสมบูรณคือ กระบวนการที่ไมไดดําเนินการ หรือไมไดดําเนินการบางสวน
เปาหมายเฉพาะของกลุม กระบวนการอยางนอยหนึ่งเปาหมายไมไดรับการตอบสนอง และสําหรับระดับ
นี้ไมมีเปาหมายทั่วไปเพราะไมมีเหตุผลที่จะจัดใหมีกระบวนการที่ดาํ เนินการบางสวน

ความสามารถระดับ 1: ระดับดําเนินการ (performed level)

กระบวนที่ไดรับการดําเนินการคือ กระบวนการที่ตอบสนองเปาหมายเฉพาะทัง้ หมดของ
กลุมกระบวนการ กระบวนการที่ไดรับการดําเนินการจะสนับสนุนและทําใหงานทีจ่ ําเปนเพื่อผลิตงานที่
ไดกําหนดไว
ถึงแมวา ระดับความสามารถระดับนี้มีผลใหมีการปรับปรุงอยางมาก การปรับปรุงนัน้ อาจ
สูญหายตามกาลเวลา ถาไมไดเปนการดําเนินงานทีเ่ ปนสวนหนึง่ ของการดําเนินการขององคการ การทํา
ใหเปนงานขององคการชวยใหแนใจวาการปรับปรุงจะไดรับการบํารุงรักษา

ความสามารถระดับ 2: ระดับจัดการ (managed level)

กระบวนการทีไ่ ดรับการจัดการคือ กระบวนการที่ไดรบั การดําเนินการโดยองคการมี
โครงสรางพื้นฐานระดับพื้นฐานสําหรับสนับสนุนกระบวนการ กระบวนการไดรับการวางแผนและทําตาม
นโยบายขององคการ ใชคนที่มีทกั ษะผูซ ึ่งมีทรัพยากรพอเพียงเพื่อผลิตสิ่งที่กาํ หนด มีผูมีสวนไดเสียเขา
รวมในกระบวนการ งานและผลของงานถูกติดตาม ควบคุมและทบทวน และถูกประเมินตาม
รายละเอียดของกระบวนการ
ความแตกตางระหวางความสามารถระดับ 1 กับระดับ 2 คือ กระบวนการที่ไดรับการ
จัดการนัน้ อยูในแผน และประสิทธิภาพของกระบวนการถูกจัดการตามแผน การแกไขทําเมื่อผลไดที่
แทจริงและประสิทธิภาพตางจากแผนอยางมีนยั สําคัญ กระบวนการระดับ 2 นี้ บรรลุวัตถุประสงคของ
แผนและทําใหกระบวนการเปนงานสวนหนึ่งขององคการ ระเบียบวินยั ของกระบวนการในระดับนีช้ วยให
องคการแนใจวาวิธีปฏิบัติทมี่ ีอยูจะยังคงอยูในชวงเวลาที่ตึงเครียด

ความสามารถระดับ 3: ระดับนิยาม (defined level)

กระบวนการทีไ่ ดรับการนิยามคือ กระบวนการที่ไดรับการจัดการ (ระดับความสามารถ
ระดับที่ 2) ที่ไดรับการตบแตงจากกระบวนการมาตรฐานขององคการตามแนวทางการแกไขที่องคการ
กําหนดใหเหมาะกับโครงการ
ความแตกตางระหวางกระบวนการที่ไดรับการจัดการกับกระบวนการทีไ่ ดรับการนิยาม คือ
ขอบเขตของมาตรฐาน รายละเอียดกระบวนการ และขัน้ ตอน สําหรับกระบวนการที่ไดรับการจัดการนัน้

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคุณภาพโครงการ หนา 7-40

คําอธิบาย มาตรฐาน และขั้นตอนของกระบวนการที่ใชกับโครงการเฉพาะโครงการหนึง่ อาจแตกตางกัน

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

ความสามารถระดับ 4: ระดับจัดการเชิงปริมาณ (quantitatively managed)

กระบวนการทีไ่ ดรับการจัดการเชิงปริมาณคือ กระบวนการที่ไดรับการนิยามที่ถูกควบคุม
โดยการใชเทคนิคเชิงสถิติและเชิงปริมาณอื่นๆ มีการกําหนดวัตถุประสงคเชิงปริมาณสําหรับคุณภาพ
และประสิทธิภาพของกระบวนการ และถูกใชเปนเกณฑในการจัดการกระบวนการ มีการใชสถิติเพื่อให
เขาใจในคุณภาพและประสิทธิภาพของกระบวนการนั้น

ความสามารถระดับ 5: ระดับที่ดีที่สุด (optimizing)

กระบวนการทีด่ ีที่สุดคือ กระบวนการที่ไดรับการจัดการเชิงปริมาณที่ไดรับการปรับปรุงตาม
ความเขาใจในสาเหตุของความแปรปรวนที่ซอนอยูในกระบวนการ จุดเนนของกระบวนการที่ดีที่สุดคือ
การปรับปรุงประสิทธิภาพของกระบวนการอยางตอเนื่อง

ตัวแบบที่ตัวแทนเปนแบบตอเนื่องมีกลุมกระบวนการทัง้ หมด 25 กลุม ซึง่ สามารถจัดได 4

หมวด ดังแสดงในตารางที่ 7.10 กลุมกระบวนการนี้จาํ แนกออกตามหมวดดังนี้

ตารางที่ 7.10 หมวดและกลุมกระบวนการของตัวแบบที่ตัวแทนเปนแบบตอเนื่อง

หมวดกระบวนการ กลุมกระบวนการ
การจัดการกระบวนการ (process การมุงเฉพาะสวนของกระบวนการเชิงองคการ (organizational process
management) focus)
การนิยามกระบวนการเชิงองคการ (organizational process definition)
การอบรมเชิงองคการ (organizational training)
กระบวนการเชิงองคการสําหรับการดําเนินงาน (organizational process for
performance)

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคุณภาพโครงการ หนา 7-41

หมวดกระบวนการ กลุมกระบวนการ
นวัตกรรมเชิงองคการ และการเตรียมพรอม (organizational innovation and
deployment)
การจัดการโครงการ (project การวางแผนโครงการ (project planning)
management) การควบคุมและติดตามโครงการ (project monitoring and control)
การบริหารขอตกลงกับผูขาย (supplier agreement management)
การจัดการโครงการแบบบูรณาการ (integrated project management)
การจัดการความเสี่ยง (risk management)
การทําทีมแบบบูรณาการ (integrated teaming)
การจัดการผูขายแบบบูรณาการ (integrated supplier management)
การบริหารโครงการเชิงปริมาณ (quantitative project management)
การวิศวกรรม (engineering) การพัฒนาความตองการ (requirements development)
การจัดการความตองการ (requirements management)
คําตอบเชิงเทคนิค (technical solution)
การบูรณาการผลิตภัณฑ (product integration)
การทวนสอบ (verification)
การตรวจสอบวาใชการได (validation)
การสนับสนุน (support) การจัดการคอนฟกรูเรชัน (configuration management)
การประกันคุณภาพผลิตภัณฑและกระบวนการ (process and product
quality assurance)
การวัดและการวิเคราะห (measurement and analysis)
สภาพแวดลอมเชิงองคการสําหรับการบูรณาการ (organizational
environment for integration)
การวิเคราะหการตัดสินใจ และการแกไข (decision analysis and resolution)
การวิเคราะหเชิงเหตุผลและการแกไข (casual analysis and resolution)

7.10 การปรับปรุงคุณภาพโครงการเทคโนโลยีสารสนเทศ
ในสวนนี้เสนอคําแนะนําสําหรับการวางแผนคุณภาพ การประกันคุณภาพ และการควบคุม
คุณภาพ ประเด็นที่ควรนํามาพิจารณาสําหรับการปรับปรุงคุณภาพของโครงการเทคโนโลยีสารสนเทศมี
ดังนี้
• ความเปนผูนาํ ผูบริหารตองประกาศปรัชญาและยอมรับเรื่องคุณภาพของสินคาและ
บริการของบริษัทอยางเปนทางการ ทําโปรแกรมอบรมพนักงานทั้งองคการในเรื่อง
ความคิดและหลักการของคุณภาพ ทําใหโปรแกรมการวัดเกิดขึ้นเพือ่ ใชติดตามระดับ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคุณภาพโครงการ หนา 7-42

คุณภาพ และแสดงออกถึงความสําคัญของคุณภาพ เมื่อพนักงานทุกคนเขาใจและ

ยืนยันการผลิตผลิตภัณฑที่มีคุณภาพสูง แสดงวาผูบ ริหารไดสงเสริมความสําคัญของ
คุณภาพ
• ตนทุนของคุณภาพ คือ คาใชจายที่ทาํ ใหผลิตภัณฑและบริการสอดคลองกับความ
ตองการ และเหมาะสมกับการใชงาน ซึง่ ประกอบคาใชจา ย 4 กลุมคือ
ƒ คาใชจายในการปองกันเปนคาใชจายในการวางแผน และทํางานตามโครงการเพื่อ
ไมใหเกิดขอบกพรอง หรือมีขอบกพรองในระดับที่ยอมรับได ตัวอยางกิจกรรมการ
ปองกัน เชน การอบรม การศึกษารายละเอียดที่เกี่ยวกับคุณภาพ การสํารวจ
คุณภาพของผูข าย
ƒ คาใชจายในการประเมินเปนคาใชจายของการประเมินกระบวนการและผลลัพธ
เพื่อใหแนใจวาไมมีขอบกพรอง หรือมีขอบกพรองในชวงที่สามารถยอมรับได
กิจกรรมที่เกี่ยวกับการประเมิน เชน การตรวจตราและการทดสอบผลิตภัณฑ การ
บํารุงรักษา ตรวจตราและทดสอบอุปกรณ และการประมวลขอมูลและการออก
รายงาน
ƒ คาใชจายที่เกิดจากการลมเหลวภายในคือ คาใชจา ยเพื่อแกไข และชี้ขอผิดพลาด
กอนที่ลูกคาไดรับผลิตภัณฑ กิจกรรมทีจ่ ัดอยูในคาใชจายกลุม นี้ เชน ทํางานใหม
คาธรรมเนียมการจายบิลชา คาใชจายคลังสินคาอันเนื่องจากขอบกพรอง
คาใชจายในการแกไขการออกแบบ เปนตน
ƒ คาใชจายที่เกิดจากการลมเหลวภายนอกคือ คาใชจายที่เกีย่ วกับขอผิดพลาด
ทั้งหมดที่ไมถกู พบและแกไขกอนสงใหกบั ลูกคา เชน คารับประกัน คาอบรม
พนักงานบริการภาคสนาม คาการจัดการกับคํารองเรียน ความสูญเสียทางธุรกิจ
เปนตน
• อิทธิพลเชิงองคการ ปจจัยสถานทีท่ ํางาน และคุณภาพ จากการศึกษาของเดแมคโคร
และลิสเตอรพบวาประเด็นเชิงองคการมีอทิ ธิพลตอประสิทธิภาพมากกวาสภาวะ
แวดลอมเชิงเทคนิค หรือภาษาการโปรแกรม การจัดสถานทีท่ ํางาน และสภาวะ
แวดลอมการทํางานทีเ่ งียบเปนปจจัยสําคัญตอการปรับปรุงประสิทธิภาพ ทั้งสองจึง
เสนอแนะผูบริหารวาตองมุง เนนที่ปจจัยสถานทีท่ ํางานเพื่อปรับปรุงประสิทธิภาพ และ
คุณภาพ เขายังกลาวอีกวาปญหาประสิทธิภาพการทํางานและการลมเหลวของ
โครงการไมใชปญหาเชิงเทคนิค แตเปนปญหาเชิงสังคม บริษัทควรลดการเมืองในที่
ทํางาน และใหสถานที่ทาํ งานแกคนที่เกง ใหความรับผิดชอบทางดานปญญา และให

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคุณภาพโครงการ หนา 7-43

ทิศทางเชิงกลยุทธ หลังจากนั้นปลอยใหคนเหลานีท้ าํ งาน งานของผูจดั การคือ ทําความ

เปนไปไดสําหรับคนเพื่อทํางานโดยการขจัดสิ่งกีดขวางเชิงการเมือง
• ความคาดหวังและความแตกตางทางวัฒนธรรมกับคุณภาพ ผูจัดการโครงการที่มี
ประสบการณทราบดีวา ประเด็นที่สาํ คัญของการบริหารคุณภาพโครงการคือ การ
จัดการความคาดหวัง ผูมีสว นเกี่ยวของแตละคนมีความคาดหวังที่แตกตางกัน มันจึง
เปนสิ่งสําคัญมากที่ตองเขาใจความคาดหวังของคนเหลานี้ และบริหารความขัดแยงที่
อาจเกิดจากความคาดหวังทีแ่ ตกตางกันนี้ เชน ลูกคาหลายคนรูสึกเซ็ง เมื่อไมสามารถ
เขาถึงสารสนเทศไดภายใน 2-3 วินาที ในอดีต ชวงเวลาดังกลาวยอมรับได แตผูใช
ปจจุบันคาดหวังวาระบบทํางานไดเร็วกวา ความคาดหวังแตกตางกันตามวัฒนธรรม
องคการ หรือภาคทางภูมิศาสตร ใครที่เดินทางไปยังสวนตางๆ ขององคการมีความ
คาดหวังที่ไมเหมือนกับคนทีอ่ ยูที่เดียวตลอดเวลา

7.11 สรุป
แนวความคิดเกี่ยวกับคุณภาพคือ การตอบสนองความตองการที่ไดระบุไวของผูมสี วนไดเสีย
ความสอดคลองกับความตองการ และการสงมอบสิ่งที่เหมาะกับการใชประโยชน
การบริหารคุณภาพโครงการประกอบดวยการวางแผนคุณภาพ การประกันคุณภาพ และการ
ควบคุมคุณภาพ การวางแผนคุณภาพกําหนดมาตรฐานคุณภาพที่เกี่ยวของกับโครงการ และทําอยางไร
จึงจะไดคุณภาพตามทีก่ ําหนด การประกันคุณภาพเกี่ยวของกับการประเมินผลการดําเนินงานใน
ภาพรวมของโครงการเพื่อใหแนใจวาโครงการจะทํางานใหมีคุณภาพตามมาตรฐาน การควบคุมคุณภาพ
เปนการติดตามผลของโครงการเพื่อใหแนใจวาผลนั้นตรงตามมาตรฐานคุณภาพ และการกําหนดวิธีเพื่อ
ปรับปรุงคุณภาพโดยรวม
มีเทคนิคและเครื่องมือหลากหลายที่เกี่ยวของกับการบริหารคุณภาพโครงการ ผังกางปลาชวย
คนหารากสาเหตุของปญหา ผังพาเรโตชวยกําหนดสิง่ ที่มีสว นรวมที่สําคัญที่รับผิดชอบปญหาคุณภาพ
มากที่สุด การสุมตัวอยางเชิงสถิติชวยกําหนดตัวเลขทีส่ อดคลองกับความจริงเพื่อการวิเคราะหประชากร
ซิกสซิกมาชวยบริษัทปรับปรุงคุณภาพโดยการลดความบกพรอง ความเบี่ยงเบนมาตรฐานวัดความ
แปรปรวนในขอมูล ผังการควบคุมแสดงขอมูลเพื่อชวยรักษาใหกระบวนการอยูในการควบคุม การ
ทดสอบเปนเทคนิคที่สําคัญในการพัฒนาและการสงผลิตภัณฑเทคโนโลยีสารสนเทศที่มีคุณภาพสูง
มีคนหลายๆ คนมีสวนรวมในการพัฒนาการบริหารคุณภาพทีท่ นั สมัย คนเหลานี้ไดแก เดมมิง
จูราน ครอสบี้ และอิชิคาวา เปนตน ทุกวันนี้ หลายๆ องคการใชแนวความคิดของคนเหลานี้ ซึ่งมีอิทธิผล

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารคุณภาพโครงการ หนา 7-44

ตอหลักการซิกสซิกมา และไอเอสโอ9000:2000 ชวยองคการเนนถึงความสําคัญของการปรับปรุง

คุณภาพ
การปรับปรุงคุณภาพของโครงการเทคโนโลยีสารสนเทศยังมีชองทางอีกมาก ความเปนผูนาํ ที่
เขมแข็งชวยเนนความสําคัญของคุณภาพ การเขาใจตนทุนของคุณภาพชวยสงเสริมการปรับปรุง
คุณภาพ การจัดสถานที่ทาํ งานที่ดีสามารถปรับปรุงคุณภาพและประสิทธิภาพ ความเขาใจความ
คาดหวังและความแตกตางดานวัฒนธรรมสัมพันธกับการบริหารคุณภาพโครงการ การพัฒนาและทํา
ตามตัวแบบวุฒิภาวะสามารถชวยองคการปรับปรุงกระบวนการบริหารโครงการอยางเปนระบบ เพื่อเพิ่ม
คุณภาพและอัตราความสําเร็จของโครงการ

คําถามทายบท
1. อธิบายกระบวนการหลักการบริหารคุณภาพโครงการ
2. ฟงกชันงาน ผลลัพธของระบบ ประสิทธิภาพ ความนาเชือ่ ถือ และความตองการบํารุงรักษา
ระบบมีผลกระทบตอการวางแผนคุณภาพอยางไร
3. จงอธิบายคุณภาพของซอฟตแวรของเม็คคอล
4. ปญหาที่เกิดขึน้ จากการใชตวั วัดมาประเมินคุณภาพของโครงการและผลงาน
5. วิจารณการประยุกตใชวธิ ีการบริหารคุณภาพของของผูรู เชน เดมมิง จูราน อิชิคาวา และครอส
บี กับโครงการเทคโนโลยีสารสนเทศ
6. เพราะเหตุใด CMMI จึงทําใหซอฟตแวรมคี ุณภาพ
7. ประโยชนของตัววัดที่มีตอการบริหารโครงการ
8. คาใชจายเกี่ยวกับคุณภาพมีอะไรบาง พรอมทั้งอธิบายและยกตัวอยาง
9. ทานมีความคิดเห็นอยางไรกับขอเสนอแนะของผูรูดานคุณภาพวา ทีมงานโครงการควรเนนที่
การปองกันมากกวาการตรวจตราหาขอบกพรองหลังจากงานทําเสร็จแลว
10. เพราะเหตุใดความเปนผูน ําจึงเปนปจจัยสําคัญในการปรับปรุงคุณภาพของสินคาและบริการ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารทรัพยากรมนุษย หนา 8-1

8.1 บทนํา
มนุษยคือ ทรัพยสนิ ที่มีคา ทีส่ ุดในองคการ เปนผูก ําหนดความสําเร็จและลมเหลวขององคการ
และโครงการ ผูจัดการโครงการสวนใหญมีความเห็นตรงกันวาการบริหารทรัพยากรมนุษยใหมีประสิทธิผล
เปนเรื่องที่ยากและทาทาย การบริหารทรัพยากรมนุษยเปนเรื่องทีส่ ําคัญของการบริหารโครงการ โดย
เฉพาะโครงการเทคโนโลยีสารสนเทศ เนื่องจากคนที่มีคณ ุ สมบัติยอมหายากและยากแกรักษาไว
การบริหารทรัพยากรมนุษยคือ กระบวนการใชคนที่เกีย่ วของกับโครงการใหมีประสิทธิผลมาก
ที่สุด การบริหารทรัพยากรมนุษยรวมถึงผูม ีสวนไดเสียของโครงการทัง้ หมด เชน ผูสนับสนุน ลูกคา สมาชิก
ทีมงานโครงการ เจาหนาที่สนับสนุน ผูขาย เปนตน โดยมีกระบวนการบริหารดังนี้
• การวางแผนทรัพยากรมนุษย (human resource planning) คือ กระบวนการกําหนด
บทบาท ความรับผิดชอบ และสายการบังคับบัญชา ผลลัพธของกระบวนการคือ บทบาท
และความรับผิดชอบของทีมงาน ผังโครงสรางองคการของโครงการ และแผนการบริหารคน
• การไดทมี งาน (acquiring the project team) เปนกระบวนการไดคนที่ตองการมาทํางาน
ใหกับโครงการ ผลลัพธของกระบวนการคือ การกําหนดคนทํางาน ขอมูลทรัพยากรบุคคลที่
มีใหใช แผนการบริหารคนทีไ่ ดรับการปรับปรุง
• การพัฒนาทีมงานโครงการ (developing the project team) เปนกระบวนการสราง
ทักษะใหสมาชิกทีมงานแตละคนและทักษะกลุม เพื่อเพิ่มความสามารถการทํางานของ
โครงการ การสรางทีมงานเปนสิ่งที่ทา ทายผูจัดการโครงการ ผลลัพธของกระบวนการคือ
การประเมินความสามารถของทีมงาน
• การบริหารทีมงานโครงการ (managing the project team) คือ กระบวนการติดตาม
การดําเนินงานของสมาชิกทีมงาน การสรางแรงจูงใจสมาชิก การใหขอมูลยอนกลับทีท่ ัน
ตอเวลา การแกความขัดแยง และการประสานการเปลี่ยนแปลง เพื่อชวยเพิ่มความสามารถ
โครงการ ผลลัพธของโครงการคือ การเปลีย่ นแปลงที่รองขอ คําแนะนําใหแกไขหรือปองกัน
แผนการบริหารโครงการที่ปรับปรุง

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารทรัพยากรมนุษย หนา 8-2

8.2 หลักในการบริหารคน
นักทฤษฎีดานการบริหาร และจิตวิทยาเชิงองคการ-อุตสาหกรรม ไดอุทิศตัวทําวิจยั และคิดคน
ทฤษฎีตางๆ ใหกับสาขาการบริหารคนที่ทาํ งาน ประเด็นเชิงจิตวิทยาที่กระทบการทํางานของคน และการ
ทํางานของคนจะดีไดอยางไร ในหัวขอนี้จะทบทวน 1) ทฤษฎีการจูงใจของ อับราฮัม มาสโลว (Abraham
Maslow) เฟรดเดอริก เฮอรซเบอรก (Frederick Herzberg) เดวิด แมคคลิแลนด (David McClelland)
และ ดักกลาส แมคเกรเกอร (Douglas McGregor) 2) ทฤษฎีอทิ ธิพลตอคนทํางานและการลดความ
ขัดแยง และผลกระทบของอํานาจตอทีมงานโครงการของ ธรรมเฮียนและไวลมอน (Thamhain และ
Wilemon) และ 3) ทฤษฎีทําอยางไรคนและทีมงานสามารถกลายเปนคนทํางานไดมีประสิทธิผลมากขึ้น
ของ สตีเฟน โควีย (Stephen Covey)

8.2.1 ทฤษฎีการจูงใจ (Motivation Theories)

การจูงใจมี 2 ประเภทคือ การจูงใจจากภายใน (intrinsic motivation) และ การจูงใจจาก
ภายนอก (extrinsic motivation) การจูงใจจากภายใน เปนการจูงใจทีเ่ กิดจากความตองการของบุคคลนั้น
บุคคลตองการรวมในกิจกรรมตางๆ ก็เนือ่ งมาจากความตองการความสนุก หรือความสุขของตนเอง เชน
บางคนรักการอาน เขียน หรือเลนเครื่องดนตรี เพราะกิจกรรมเหลานีท้ ําใหพวกเขามีความรูสึกดี ในทาง
ตรงกันขาม การจูงใจจากภายนอก เปนการจูงใจทีเ่ กิดจากปจจัยภายนอก ไมไดเปนความตองการของ
บุคคลนั้น คนบางคนทําบางสิ่งบางอยางเพื่อรางวัล หรือหลีกเลี่ยงการลงโทษ เชน เด็กบางคนอาจไมชอบ
เลนเครื่องดนตรี แตพวกเขาก็เลนเพราะพวกเขาไดรับรางวัลหรือการทําโทษ ทําไมคนบางคนไมตองการ
แรงจูงใจจากภายนอกเพื่อทํางานใหมีคณ ุ ภาพสูง ในขณะที่บางคนตองการแรงจูงใจนอกอยางมากเพื่อ
ทํางานประจําวัน ทําไมเราไมสามารถไดคนที่มปี ระสิทธิภาพสูงๆ มาทํางานทีง่ ายๆ ดังนั้น ความเขาใจ
พื้นฐานของทฤษฎีแรงจูงใจจะชวยใหใครที่ทาํ งานกับผูอ ื่นใหเขาใจตัวเองและผูอนื่

รูปที่ 8.1 ลําดับขั้นความตองการของมาสโลว (Schwalbe, 2007)

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารทรัพยากรมนุษย หนา 8-3

8.2.1.1 ลําดับขัน้ ความตองการของมาสโลว

รูปที่ 8.1 แสดงลําดับขั้นความตองการของมาสโลว ซึง่ กลาววาพฤติกรรม
ของคนถูกชีน้ าํ หรือจูงใจโดยลําดับความตองการ ความตองการเรียงตามลําดับดังนี้ ความตองการพื้นฐาน
ทางดานรางกาย ความตองการความมั่นคงปลอดภัย ความตองการดานสังคม ความตองการไดรับการยก
ยองจากผูอื่น และความตองการความสําเร็จในชีวิตตามที่ตนเองตัง้ ไว มาสโลวกลาววา ความตองการ
ระดับลางเปนความตองการที่ตองมีกอนความตองการทีอ่ ยูระดับบน ความหมายของความตองการแตละ
ลําดับขั้นมีดังนี้
• ความตองการพื้นฐานทางดานรางกาย (physiological needs) เปน
ความตองการขั้นพืน้ ฐานเพือ่ สนองความสามารถดํารงชีวิตอยูได เชน
อาหาร น้าํ ที่อยู อากาศเครื่องนุง หม เปนตน
• ความตองการความปลอดภัย (safety needs) เปนความตองการให
ตนเองมีความปลอดภัยทางดานรางกาย และความมัน่ คงทางดาน
เศรษฐกิจ ความตองการระดับนี้ทาํ ใหคนหลีกเลีย่ งความโรคภัยไขเจ็บ
และแสวงหาความมัน่ คง เชน ยา เครื่องปองกันอันตราย อาหารเสริม
อุปกรณบริหารรางกาย การประกันชีวิต และงานที่มั่นคง เปนตน
• ความตองการดานสังคม (social needs) เมื่อความตองการทางดาน
รางกายและความตองการความมัน่ คงปลอดภัยไดรับการสนองตอบจน
เปนทีพ่ อใจแลว คนจะเริม่ มีความตองการดานสังคม ซึ่งเปนความ
ตองการความรักความเมตตา ความรูสึกเปนสวนหนึง่ ของชุมชน เชนการ
รวมกิจกรรมทางสังคม สิ่งของที่แสดงถึงความสัมพันธภาพที่ดีตอกัน
ระหวางบุคคล (เชน บัตรอวยพร ของขวัญ) การเปนสมาชิกชมรม และ
สโมสรตางๆ
• ความตองการเกียรติยศชื่อเสียง (esteem needs) เปนความตองการการ
ยอมรับและความเชื่อถือจากเพื่อนรวมงานและเจานาย การยกยองชมเชย
เมื่อทํางานสําเร็จ ซึ่งทําใหคนรูสึกวาตนเองมีคุณคา เชน การประกาศ
เกียรติคณุ ถวยรางวัล โลเกียรติยศ ใบปริญญา การทํากิจกรรมเพื่อสังคม
อาสาสมัคร แมแตการใชจายฟุมเฟอย อวดมั่งมีก็จัดวาเปนพฤติกรรมของ
คนที่ตองการใหบุคคลอื่นชืน่ ชมนับถือ
• ความตองการความสําเร็จในชีวิตตามที่ตนเองตัง้ ไว (self actualization
needs) เปนความตองการขั้นสูงสุดที่บุคคลพยายามกระทําสิง่ ตางๆ เพื่อ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารทรัพยากรมนุษย หนา 8-4

แสดงศักยภาพที่แทจริงของตนเอง เปนการสรางความภาคภูมิใจใหกับ
ตนเอง โดยสิ่งที่ไดรับไมไดเปนทรัพยสนิ เงินทอง แตเปนความพึงพอใจ
และความภูมิใจที่ไดกระทําในสิ่งที่เติมเต็มความสามารถและเหมาะสม
กับตนเอง เปนการคนพบตนเองและมีความสุขที่แทจริง เชน งานที่ทา ทาย
หรือที่บุคคลพอใจ สถานที่หรือสถานการณที่สรางใหบุคคลเกิดความสุข
ทางใจ เปนตน

คนทีท่ าํ งานในโครงการเทคโนโลยีสารสนเทศสวนใหญจะไดรับการสนอง
ตอบความตองการพื้นฐานทางดานรางกายและความมั่นคงปลอดภัย ถาบางคนตองรับอุบัติเหตุ หรือตก
งานทันทีทนั ใด ความตองการทางกายและความปลอดภัยจะมาเปนอันดับแรก เพื่อจูงใจสมาชิกทีมงาน
ผูจัดการโครงการตองเขาใจแรงจูงใจของแตละคน โดยเฉพาะอยางยิง่ ความตองการดานสังคม การไดรับ
การยกยองและการเติบโตของตนเอง สมาชิกทีมงานทีม่ าใหมอาจจูงใจดวยความตองการดานสังคม บาง
องคการจัดงานสังคมสําหรับพนักงานใหม แตอาจมีสมาชิกทีมงานคนอืน่ คิดวา งานดังกลาวเปนการ
ลวงล้าํ เวลาสวนตัว พวกเขาตองการใชเวลากับเพื่อนและความครอบครัวหรือทํางานที่ระดับสูงมากกวา
ลําดับขั้นความตองการของมาสโลวกลาวถึงความหวังและความเติบโต
กาวหนา คนตองการทํางานเพื่อควบคุมจุดหมายปลายทางชีวิตของตนเอง และตอสูเพื่อบรรลุความ
ตองการที่สงู ขึน้ ผูจัดการโครงการทีป่ ระสบความสําเร็จตองเขาใจความตองการและเปาหมายบุคคล
เพื่อใหการจูงใจที่เหมาะสม และทําใหการทํางานมีประสิทธิภาพสูงสุด

8.2.1.2 ทฤษฎีแรงจูงใจของเฮอรซเบอรก
จากการศึกษาการจูงใจในสภาพการทํางาน เฮอรเบอรกไดพบวามีปจ จัยที่
แตกตางกันสองปจจัยที่กระทบตอพฤติกรรมการทํางานของคน ปจจัยที่ทาํ ใหคนพอใจงานเรียกวาสิ่งจูงใจ
(Motivator) เชน ความสําเร็จ การยกยองนับถือ งานทีท่ าทาย ความรับผิดชอบ และความกาวหนา สวน
ปจจัยทีท่ ําใหคนไมพอใจงานเรียกวา ไฮยีน (Hygiene) เชน นโยบายบริษัท ระเบียบการบริหารงาน สภาพ
การทํางาน เงินเดือนและผลประโยชน ความสัมพันธระหวางบุคคลในองคการ และเงื่อนไขการทํางานทาง
กายภาพ หากวาสิง่ ตางๆ เหลานี้ไดรับการดูแลเอาใจใสอยางพอเพียง ความไมพอใจก็จะหายไป ดังนัน้ ไฮ
ยีนจึงเปนปจจัยที่ใชปองกันการเกิดความไมพอใจ แตไมไดทําหนาทีเ่ ปนเครื่องจูงใจบุคคลใหทํางานใหมี
ผลผลิตหรือบริการในระดับที่สูงขึน้ ได

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารทรัพยากรมนุษย หนา 8-5

8.2.1.3 ทฤษฎีความตองการของแมคคลิแลนด
เดวิด แมคคลิแลนดเสนอวา ความตองการเฉพาะของแตละคนไดมาหรือ
เรียนรูตามเวลาและถูกปรับโดยประสบการณชีวิต ความตองการที่ไดมาแบงเปน 3 ประเภทคือ
ความสําเร็จ (achievement) สัมพันธภาพ (affiliation) และอํานาจ (power)
• ความตองการทํางานใหมีผลสัมฤทธิ์ (need for achievement หรือ
nAch) คนที่มีความตองการความสําเร็จสูงจะคนหาสิง่ ที่ดีกวาและมี
แนวโนมที่จะหลีกเลี่ยงสถานการณที่มีความเสี่ยงสูงเพือ่ เพิ่มโอกาสให
บรรลุบางสิ่งทีม่ ีคาสูง ผูท ี่ตองการความสําเร็จตองการขอมูลยอนกลับเปน
ประจํา และชอบทํางานคนเดียว หรือทํางานกับคนอื่นทีไ่ ดรับความสําเร็จ
ผูจัดการควรใหผูตองการความสําเร็จสูงทําโครงการทีท่ า ทายและมี
เปาหมาย เงินไมใชสิ่งจูงใจที่สําคัญสําหรับคนเหลานี้
• ความตองการสัมพันธภาพ (need for affiliation หรือ nAff) คนที่มีความ
ตองการสัมพันธภาพสูงจะพึงพอใจกับความสัมพันธทสี่ อดประสานกับคน
อื่นๆ และตองการความยอมรับจากผูอื่น คนเหลานีม้ ีแนวโนมที่จะทําตาม
บรรทัดฐาน (norm) ของกลุม และชอบงานที่เกี่ยวของกับการโตตอบกับ
คน ผูจัดการควรพยายามสรางสภาวแวดลอมการทํางานตรงกับความ
ตองการของคนที่มีความตองการสัมพันธภาพ
• ความตองการอํานาจ (need for power หรือ nPow) คนที่ตองการ
อํานาจชื่นชอบทั้งอํานาจเชิงบุคคลและอํานาจเชิงสถาบัน (personal and
institutional power) คนทีต่ องการอํานาจเชิงบุคคลตองการสัง่ ผูอื่น และ
ตองการเปนนาย คนที่ตอ งการอํานาจเชิงสถาบันหรืออํานาจเชิงสังคม
ตองการจัดการผูอื่น เพื่อเปาหมายขององคการ ผูบ ริหารควรใหคนที่
ตองการอํานาจเชิงสถาบันหรือสังคมมีโอกาสทํางาน เพราะจะมุง เนนการ
บรรลุเปาหมายเชิงองคการ

8.2.1.4 ทฤษฎี X และทฤษฎี Y ของแมคเกรเกอร

แมคเกรเกอรไดเสนอแนวคิดเกี่ยวกับพฤติกรรมของแรงงาน 2 แนวคิดคือ
ทฤษฎี X และ ทฤษฎี Y โดยที่ ทฤษฎี X มีสมมติฐานวา คนโดยเฉลี่ยไมชอบทํางาน เกียจคราน หลีกเลี่ยง
การทํางาน คนจะทํางานก็ตอเมื่อไดรับคําสั่ง และชอบหลีกเลีย่ งความรับผิดชอบ มีความทะเยอทะยาน

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารทรัพยากรมนุษย หนา 8-6

นอย และตองการความมั่นคง ปลอดภัยเหนือกวาสิ่งอืน่ ใด ดังนัน้ ผูจ ัดการโครงการที่เชื่อทฤษฎี X จะใช

การบังคับ ขมขู และการควบคุม เพื่อใหคนใชความพยายามทีท่ ํางานใหบรรลุวัตถุประสงค
สวนทฤษฎี Y เปนทฤษฎีทมี่ แี นวความคิดตรงกันขามกับทฤษฎี X กลาวคือ คนไมได
มีนิสัยที่ไมชอบการทํางาน แตเต็มใจที่จะทํางานโดยไมตองมีผูควบคุม คนงานเชื่อวาการใชความพยายาม
ทั้งทางรางกายและสติปญญาในการทํางานนั้นเปนความสุขอยางหนึง่ รวมทั้งเปนผูที่คอยแสวงหาโอกาส
ที่จะปรับปรุงตนเองใหมีประสิทธิภาพสูงขึ้น ผูจัดการโครงการที่เชื่อทฤษฎี Y จะสนับสนุนการมีสวนรวม
ของคนในทีมงาน และการสรางความสัมพันธทีดีระหวางกัน ไมตองมีการควบคุมคนงานอยางใกลชิด ให
โอกาสพนักงานใชความคิดของตนเอง

8.2.2 ทฤษฎีอาํ นาจและอิทธิพลของธรรมเฮียนและไวลมอน

ธรรมเฮียนและไวลมอนไดศกึ ษาวิธที ี่ผูจัดการโครงการใชเพื่อจัดการกับคนงาน และวิธี
การเหลานี้สมั พันธกับความสําเร็จของโครงการอยางไร ธรรมเฮียนและไวลมอน ไดระบุอิทธิพล 9 ตัวที่
ผูจัดการโครงการสามารถนํามาใชดงั นี้
• อํานาจ (authorities) อํานาจตามลําดับขั้นการบังคับบัญชาทีถ่ ูกตองในการ
ออกคําสั่ง
• การมอบหมาย (assignment) ความสามารถของผูจัดการที่จะมอบหมายงาน
ในอนาคต
• งบประมาณ (budget) ความสามารถของผูจัดการเพื่อใหอํานาจผูอนื่ ใชเงินที่
ไดจัดใหกับโครงการ
• การสงเสริม (promotion) ความสามารถในการเลื่อนตําแหนงของพนักงาน
• เงิน (money) ความสามารถในการขึ้นคาจางและผลประโยชนตา งๆ ของ
พนักงาน
• การลงโทษ (penalty) ความสามารถในการทําโทษ
• งานทาทาย (work challenge) ความสามารถในการใหงานที่ใหความสนุก
และทาทายการทํางานกับพนักงาน ซึ่งตรงกับปจจัยที่เปนแรงจูงใจภายในของ
บุคคล
• ความเชีย่ วชาญ (expertise) ความรูความสามารถพิเศษของผูจัดการ
โครงการที่ผูอื่นเห็นความสําคัญ
• ความเปนเพื่อน (friendship) ความสามารถในการสรางความสัมพันธฉนั ท
เพื่อนระหวางผูจัดการโครงการกับคนอืน่

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารทรัพยากรมนุษย หนา 8-7

ผูบริหารระดับสูงใหอํานาจกับผูจัดการโครงการ สวนปจจัยการมอบหมาย งบประมาณ

การสงเสริม เงิน และการลงโทษอาจใชหรือไมใชอิทธิพลที่มาพรอมกับตําแหนงผูจัดการโครงการ ไม
เหมือนกับปจจัยอํานาจที่มาพรอมกับตําแหนงผูจัดการโครงการ การสรางและการใชประโยชนจาก
ปจจัยพืน้ ฐานที่เหลือเปนสิง่ สําคัญ เชน ผูจัดการโครงการสามารถชักจูงพนักงานโดยการใหงานที่ทา ทาย
นอกจากนี้ ผูจัดการโครงการตองเรียนรูความสามารถเพื่อชักจูงโดยการใชความเชีย่ วชาญและความเปน
เพื่อน
ธรรมเฮียนและไวลมอนพบวา โครงการมีโอกาสที่จะลมเหลวมาก ถาผูจัดการโครงการ
เชื่อถือการใชอํานาจ เงิน หรือการลงโทษ อยางมาก ถาผูจ ัดการโครงการใชงานที่ทา ทายและความ
เชี่ยวชาญเพื่อชักจูงคน โครงการมีโอกาสสําเร็จมากกวา
อิทธิพลมีความสัมพันธกับอํานาจ อํานาจคือ ความสามารถทีจ่ ะบังคับพฤติกรรมเพือ่ ให
คนทําสิ่งที่เขาไมอยากทํา อํานาจมีความหมายที่แรงกวาอิทธิพล โดยเฉพาะเราชอบใชเพื่อบังคับคนให
เปลี่ยนพฤติกรรม อํานาจมี 5 ประเภทคือ
• อํานาจในการขูบังคับ (coercive power) เปนอํานาจที่สามารถใชลงโทษผูอื่น
ได หรือขมขู เพื่อใหคนทําสิง่ ที่ไมอยากทํา อํานาจนี้มีฐานมาจากความกลัว
• อํานาจที่ไดมาอยางถูกตองตามทํานองครองธรรม (legitimate power) เปน
อํานาจที่เกิดจากการกําหนดขององคการ ซึ่งเปนอํานาจหนาที่ตามสายการ
บังคับบัญชา อยางไรก็ตาม อํานาจประเภทนี้จะเปนที่ยอมรับก็ตอเมื่อบุคคล
หรือสมาชิกในองคการยอมรับอํานาจนี้ นอกจากนีย้ ังขึ้นอยูกับวา คนที่ใช
อํานาจนัน้ ไดใชอํานาจไปอยางถูกตองตามทํานองครองธรรมหรือไม ถาไม
เปนไปตามเงือ่ นไขดังกลาว อํานาจนี้ก็จะไมเปนทีย่ อมรับ ถาผูบริหารระดับสูง
ใหอํานาจเชิงองคการแกผูจดั การโครงการ ผูจัดการโครงการสามารถใช
อํานาจนี้ใหถูกตองเชนเดียวกัน
• อํานาจที่ไดจากการยอมรับในความเชี่ยวชาญ (expert power) เปนการใช
ความรูความเชี่ยวชาญที่บุคคลอื่นยอมรับ เพื่อใหคนเปลี่ยนพฤติกรรมของ
ตนเอง ถาคนรูวาผูจัดการโครงการเปนผูเ ชี่ยวชาญ คนก็จะเชื่อและทําตาม
ดังนัน้ ภายในองคการคนที่มีอาํ นาจนีจ้ ะมีอิทธิพลอยางมากตอบุคคลอื่นที่
เกี่ยวของ ปริมาณของอํานาจะเพิม่ ขึ้นไดโดยการศึกษาเพิ่ม หรือความขาด
แคลนผูรูในเรื่องนัน้ ๆ ดังนัน้ ผูท ี่มีความเชี่ยวชาญสวนใหญไมคอยถายทอด
หรือฝกอบรมความรอบรูใหกับผูอื่นไปจนหมด

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารทรัพยากรมนุษย หนา 8-8

• อํานาจในการใหรางวัล (reward power) เปนการใชสิ่งจูงใจเพื่อชักนําให

คนทํางาน รางวัลเปนไดทั้ง เงิน สถานภาพ การระลึกถึง การสงเสริม การให
งานพิเศษ นักทฤษฎีแรงจูงใจหลายคนแนะนําวารางวัลบางอยาง (เชน งานที่
ทาทาย ความสัมฤทธิ์ผล และการระลึกถึง) ทีช่ ักจูงใหคนเปลีย่ นพฤติกรรม
หรือทํางานหนักขึ้นจริงๆ
• อํานาจที่ไดมาจากการเปนทีด่ ึงดูดใจ (referent power) เปนอํานาจที่ขึ้นอยู
กับบารมีของแตละบุคคล คนสามารถยึดคนบางคนดวยอํานาจจากคุณ
ลักษณะของบุคคล และคนเหลานี้จะทําในสิ่งที่คนที่มีอาํ นาจเชนนีพ้ ูด ดังนั้น
ผูที่มีอํานาจดานนี้จะตองพยายามคงไวซงึ่ ศรัทธาหรือความคาดหวังจากผูอื่น
หากมีการแสดงออกถึงพฤติกรรมที่ทาํ ใหศรัทธานั้นหมดไปหรือทําใหความ
คาดหมายจากผูอื่นเปลี่ยนไป อํานาจนีก้ ็จะลดลงหรือหมดไป ตัวอยางของ
บุคคลทีมีอํานาจนี้คือ มหาตมะคานธี

ผูจัดการโครงการตองเขาใจประเภทของอิทธิพลและอํานาจที่สามารถใชในสถาน
การณที่แตกตางกัน ผูจัดการโครงการใหมๆ จะเนนที่การใชอํานาจตามตําแหนง โดยเฉพาะการจัดการกับ
สมาชิกทีมงานหรือพนักงานสนับสนุน ผูจัดการโครงการเหลานีล้ ะทิ้งความสําคัญของอํานาจจากรางวัล
และอิทธิพลจากงานทีท่ าทาย คนจะสนองตอบที่ดีกับผูจัดการโครงการที่จงู ใจพวกเขาดวยงานที่ทา ทาย
และการบังคับเชิงบวก ผูจดั การโครงการจึงควรเขาใจความคิดพืน้ ฐานของอํานาจและอิทธิพล และควร
ปฏิบัติโดยการใชอํานาจและอิทธิพลเพื่อประโยชนของตนเองและทีมงาน

8.2.3 ทฤษฎีการปรับปรุงประสิทธิผลของโควีย
สตีเฟน โควีย ผูเขียนหนังสือ “The 7 Habits of Highly Effective People” ไดนํางานของ
มาสโลว เฮอรซเบอรก และคนอื่นๆ มาขยาย เพื่อพัฒนาวิธีการสําหรับชวยคนและทีมงานใหกลายเปนคน
ที่ทาํ งานมีประสิทธิผลมากขึน้ สตีเฟน โควียไดเสนออุปนิสัย 7 อยางทีท่ ําใหคนมีประสิทธิผลมากขึ้น
อุปนิสัย 7 อยางมีดงั นี้
• เปนผูกระทํากอน (be proactive) คนเรานัน้ หากไมเปนผูกระทํากอนก็จะเปน
ผูถูกกระทํา (reactive) คนที่เปนคนเฉื่อย ไมยอมคิดไมยอมสรางอะไร ก็จะถูก
สิ่งแวดลอมมากระทบหรือนําพาบังคับใหตองทําอยางนัน้ อยางนี้ไปตามสภาพแวด
ลอมแบบนั้นเรียกวาเปนผูท ถี่ ูกกระทํา แตในทางตรงกันขาม คนทีอ่ ยูในประเภทที่
เปนผูกระทําจะเปนผูเลือกทีจ่ ะทําหรือจะไมทําสิง่ ใดๆ ดวยเหตุดวยผลของเขาเองคือ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารทรัพยากรมนุษย หนา 8-9

คิดวาตัวเองเปนผูกาํ หนดชีวิตของตน ทั้งนี้ดวยการพิจารณาไวกอน ไมใชวาถึงเวลา

แลวคอยคิดจะทํา เพราะสุดทายแลวก็จะกลายเปนผูถูกกระทําและตอบสนองตอ
สิ่งแวดลอมเหมือนเดิม โควียเชื่อวาคนมีความสามารถที่จะเลือกการตอบสนองของ
เขาเองตอสถานการณที่แตกตางกัน ผูจ ัดการโครงการตองเปนคนกระฉับกระเฉง
วองไว คาดการณ และวางแผนสําหรับปญหา และการเปลี่ยนแปลงตอโครงการ
นอกจากนี้ผจู ดั การโครงการยังสามารถกระตุนสมาชิกทีมงานใหเปนคนวองไวในการ
ทํากิจกรรมของโครงการ
• เริ่มตนดวยจุดมุงหมายในใจ (begin with the end in mind) โควียเสนอวา คน
สนใจกับคุณคาของตัวเอง สิ่งที่ตองการทําใหสําเร็จ โควียเสนอใหกาํ หนดพันธกิจ
เพื่อชวยใหคนเขาถึงอุปนิสัยนี้ หลายองคการและโครงการมีพันธกิจที่ชวยคนเนน
เปาหมายหลักของเขา
• ทําสิง่ ที่สาํ คัญกอน (put first things first) โควียไดพัฒนาระบบการบริหารเวลาและ
เมทริกซ เพื่อชวยคนจัดลําดับเวลาของตนเอง เขาแนะนําวาคนสวนใหญควรใหเวลา
ทําในสิ่งที่สําคัญมาก แตไมใชงานดวน ผูจัดการโครงการจึงควรใหเวลากับการ
พัฒนาแผนโครงการตางๆ การสรางความสัมพันธกับผูมีสว นไดเสียหลักของ
โครงการ และการติดตามการทํางานของสมาชิกทีมงาน
• คิดแบบชนะ-ชนะ (think win-win) โควียไดเสนอวาความคิดแบบชนะ-ชนะเปน
ทางเลือกที่เหมาะสมกับสถานการณสวนใหญ เมื่อเราใชวิธีการนี้ ทั้งสองฝายไมมี
ฝายใดพายแพเสียประโยชน แบบนี้เรียกวาคิดและทําแบบชนะ-ชนะ ซึ่งจริงๆ แลว
อาจจะมีคนเขาใจผิดวาเปนการ "ประนีประนอม" แตจริงๆ แลวไมใช เพราะวาการ
ประนีประนอมนั้น คูกรณีอาจจะเสียประโยชนทงั้ สองฝายก็เปนได การคิดและทํา
แบบชนะ-ชนะนี้จะตองเกิดอยูบนพื้นฐานของทัศนคติที่ดแี ละตองการใหไดประโยชน
เทาเทียมกันทัง้ สองฝายในระยะยาว ในบางครั้งฝายใดฝายหนึ่งอาจจะตองเสีย
เปรียบกอน แตในที่สุดแลว เมื่อดําเนินการตามแผนทั้งหมดแลว ทั้งสองฝายจะตอง
ไดประโยชนทงั้ คูเทาๆ เทียมกัน
• เขาใจผูอื่นกอน แลวจึงใหผอู ื่นเขาใจ (seek first to understand then to be
understood) การฟงแบบอารมณรวม (empathic listening) คือ การฟงดวยความ
ตั้งใจเพื่อเขาใจเพราะเราจะเนนการเขาใจผูอื่นจริงๆ โดยลืมความสนใจสวนตัว เพือ่
ตองการเขาใจผูอื่นจริงๆ เราตองเรียนรูทจี่ ะปรับจุดสนใจไปยังผูอื่นกอน เมื่อเราทํา
การฟงแบบอารมณรวม เราสามารถเริ่มการสื่อสาร 2 ทางได อุปนิสยั นี้สําคัญมาก

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารทรัพยากรมนุษย หนา 8-10

สําหรับผูจัดการโครงการเพือ่ ที่จะไดเขาใจความตองการและความคาดหวังของผูมี
สวนไดเสียโครงการจริงๆ
• ประสานพลัง (synergize) ทีมงานโครงการสามารถประสานพลังโดยการสราง
ผลิตภัณฑรวมกันที่ดีกวาทีค่ นๆ เดียวทํา โควียยงั เนนถึงความสําคัญของคุณคาที่
ตางกันในแตละคนเพื่อใหเกิดการรวมพลัง การประสานพลังเปนสิ่งจําเปนกับ
โครงการเชิงเทคนิคที่สงู ๆ โครงการสรางความกาวหนาทางเทคโนโลยีสารสนเทศ
ใหญๆ เกิดขึ้นจากการประสานพลัง
• ลับเลื่อยใหคมอยูเสมอ (sharpen the saw) เมื่อเราใชเวลาในการฝกฝนหรือชารจ
แบตเตอรี่ แสดงวาเราใหเวลากับการทําใหรางกาย จิตใจ สดชื่น ซึ่งชวยใหคน
หลีกเลี่ยงการทํางานมากเกินไป ผูจัดการโครงการตองแนใจวาพวกเขาและสมาชิก
ทีมงานมีเวลาพักผอน

ดักกลาส รอสส (Douglas Ross) ไดแตงหนังสือ “Applying Covey’s Seven Habits to

a Project Management” รอสสเสนอวาอุปนิสัยที่ 5 (เขาใจผูอื่นกอน แลวจึงใหผูอนื่ เขาใจ) เปนอุปนิสัยที่
แยกผูจัดการโครงการที่ดีจากผูจัดการโครงการที่แย หรือปานกลาง เนื่องจากคนมีแนวโนมที่เนนเรื่องของ
ตนเองแทนที่จะพยายามเขาใจมุมมองคนอื่น การฟงแบบอารมณรวมสามารถชวยผูจัดการโครงการและ
สมาชิกทีมงานคนหาวาอะไรคือสิ่งจูงใจคนที่ตา งกัน เมื่อผูจัดการโครงการและสมาชิกเริ่มปฎิบตั ิการฟง
แบบอารมณรวม พวกเขาจะสามารถสื่อสารและทํางานรวมกันเพื่อกระเทาะปญหาไดอยางมีประสิทธิผล

8.3 การวางแผนทรัพยากรมนุษย
การวางแผนทรัพยากรมนุษยสําหรับโครงการประกอบดวย การกําหนดบทบาทโครงการ ความ
รับผิดชอบ และสายการบังคับบัญชา กระบวนการนี้ ผูจัดการโครงการสรางผังโครงสรางเชิงองคการของ
โครงการ แผนการบริหารคน และการกําหนดบทบาทและความรับผิดชอบ ซึ่งแสดงในผังการมอบหมาย
ความรับผิดชอบ (responsibility assignment matrix (RAM)) กอนที่จะสรางผังโครงสรางโครงการ
ผูบริหารระดับสูงและผูจัดการโครงการตองระบุวาบุคคลประเภทใดที่ตอ งการจริงๆ เพื่อใหแนใจวา
โครงการจะสําเร็จ

8.3.1 ผังโครงสรางโครงการ
คงจํากันไดวาธรรมชาติของโครงการเทคโนโลยีสารสนเทศมีทมี งานทีม่ ีภูมิหลัง และ
ทักษะที่แตกตางกัน มันเปนการยากที่จะบริหารกลุมคนที่ไมเหมือนกัน ดังนัน้ การกําหนดโครงสรางเชิง

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารทรัพยากรมนุษย หนา 8-11

องคการสําหรับโครงการเปนสิ่งสําคัญ หลังจากการระบุทักษะที่สาํ คัญและประเภทของคนที่ตองการ

สําหรับโครงการแลว ผูจัดการโครงการและสมาชิกทีมงานควรสรางผังโครงสรางองคการของโครงการ ซึง่
แบงออกเปน 3 ประเภทคือ
• โครงสรางแบบประชาธิปไตยกระจายอํานาจ (democratic decentralized
structure (DD)) โดยมีโครงสรางดังรูปที่ 8.2 โครงสรางแบบนี้ เปนโครงสรางที่
มีการกระจายอํานาจอยางเต็มที่ ไมมีการควบคุม ไมมีชั้นการบังคับบัญชา ทุก
คนมีความเทาเทียมกัน เสมอภาคกัน ถาแตละคนมีขอมูลขาวสารจะสงผาน
ขอมูลใหกันและกันโดยไมตองผานการอนุมัติจากใคร ยังคงมีหวั หนาทีม แต
หัวหนาทีมไมมีอํานาจสั่งการ จะทําหนาที่เปนเพียงผูประสานงานกับ
บุคคลภายนอก หัวหนาทีมจะถูกเลือกจากสมาชิกคนใดคนหนึง่ ในทีม ผลงานที่
ไดจะเปนของกลุม การตัดสินใจตองไดรับความเห็นชอบจากสมาชิก โครงสราง
ของทีมงานแบบนี้ จะเหมาะกับงานประเภทนวัตกรรม การสรางผลิตภัณฑใหมๆ
ที่ตองใชความอิสระในการคิดคนและอาศัยความคิดสรางสรรค

รูปที่ 8.2 โครงสรางองคการโครงการแบบประชาธิปไตยกระจายอํานาจ (Mantei, 1981)

• โครงสรางแบบประชาธิปไตยและควบคุม (democratic centralized structure

(DC)) ดังแสดงในรูปที่ 8.3 ลักษณะทีมงานที่มีผูจัดการโครงการเปนผูควบคุม
โครงการทั้งหมด แตมีหวั หนาทีมงานยอย โดยผูจ ัดการโครงการจะแบงงานให
แตละทีม และหัวหนาทีมงานยอยเปนผูรับผิดชอบงานที่ผจู ัดการโครงการ
มอบหมาย มีการกําหนดชัดเจนวาใครคือหัวหนาทีมงานยอย มีอํานาจตาม
ตําแหนง และมีใครที่อยูภายใตการบังคับบัญชาบาง สมาชิกของทีมงานยอย
สามารถทํางานไดอิสระเหมือนกับโครงสรางองคการของโครงการแบบแรก ผูที่
อยูในทีมยอยสามารถสื่อสารกันไดอยางอิสระ แตถาสมาชิกจะสื่อสารนอกทีม
ยอยจะตองผานหัวหนาทีมงานยอยกอน

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารทรัพยากรมนุษย หนา 8-12

รูปที่ 8.3 โครงสรางองคการของโครงการแบบประชาธิปไตยและควบคุม (Mantei, 1981)

• โครงสรางแบบควบคุมและรวมศูนย หรือหัวหนาทีมโปรแกรมเมอร (controlled

centralized structure (CC) or chief programmer team) เปนโครงสรางทีม่ ี
การควบคุมอยางเขมงวด คนในทีมไมสามารถสื่อสารกันเองได ตองผาน
ผูจัดการโครงการทุกครั้ง โครงสรางนี้ใชกับโครงการที่มีความตองการที่ชัดเจน
และผูจัดการโครงการมีความชํานาญในระบบงานนั้น รูปแบบโครงสรางประเภท
นี้แสดงในรูปที่ 8.4

รูปที่ 8.4 โครงสรางองคการของโครงการแบบควบคุมและรวมศูนยหรือ

หัวหนาทีมโปรแกรมเมอร (Mantei, 1981)

การเลือกโครงสรางองคการของโครงการสามารถพิจารณาไดจาก 7 ปจจัย โดยในตาราง

ที่ 8.1 แสดงคุณลักษณะของปจจัยที่สอดคลองกับโครงสรางองคการของโครงการ

ตารางที่ 8.1 ปจจัยที่มีผลตอการเลือกโครงสรางองคการของโครงการ (Mantei, 1981)

ประเภทโครงสรางองคการ DD DC CC
ความยากของโครงการ / ปญหา
• สูง X
• ต่ํา X X
ขนาดของโปรแกรม
• ใหญ X X
• เล็ก X
เวลาที่ทีมงานอยูดวยกัน
• สั้น X X

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารทรัพยากรมนุษย หนา 8-13

ประเภทโครงสรางองคการ DD DC CC
• ยาว X
ปญหาสามารถแยกเปนสวน ๆ
• สูง X X
• ต่ํา X
ระบบตองมีความนาเชื่อถือ
• สูง X X
• ต่ํา X
วันสงมอบ
• เลื่อนไมได X
• ยืดหยุน X X
การสื่อสารกับคนอื่น
• สูง X
• ต่ํา X X

8.3.2 การมอบหมายงานใหกบั ทีมงานยอย

รูปที่ 8.5 แสดงกรอบงานสําหรับการกําหนดและการมอบหมายงาน กระบวนการ
ประกอบดวย 4 ขั้นตอนคือ
• การกําหนดความตองการของโครงการเปนครั้งสุดทาย
• การกําหนดวางานจะทําอยางไรจึงจะสําเร็จ
• การแตกงานออกเปนชิน้ งานที่สามารถจัดการได
• การมอบหมายความรับผิดชอบงาน

กระบวนการมอบหมายงานใหกับทีมงานยอยและนิยามงานเปนงานทีท่ ําในระยะการ
เริ่มตนโครงการ เปนกระบวนการที่ทาํ ซ้าํ หลายรอบเพื่อใหงานออกมาดี คํารองขอขอเสนอโครงการ หรือ
รางสัญญาเปนขอมูลพืน้ ฐานสําหรับการนิยามและกําหนดความตองการครั้งสุดทาย ซึ่งตอมาจะถูกบันทึก
เปนเอกสารในสัญญาสุดทาย และเปนบรรทัดฐานสําหรับการอางอิงทางเทคนิค ถาไมมีคํารองขอขอเสนอ
โครงการ ผูจดั การโครงการอาจใชเอกสารสิทธิ์โครงการ และขอกําหนดขอบเขต เปนพืน้ ฐานสําหรับการ
นิยามและการกําหนดความตองการครั้งสุดทาย ระยะตอไปคือ ผูจัดการโครงการตัดสินใจเลือกวิธกี ารเชิง
เทคนิคสําหรับการทํางาน เชน การแตกงานควรใชวิธีการแตกผลิตภัณฑหรือ กระบวนการเปนหลัก งาน
บางงานควรใชบริการจากหนวยงานภายนอก หรือทําสัญญายอยแลวใหบริษัทอื่นมาทํา เมื่อทีมงาน

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารทรัพยากรมนุษย หนา 8-14

ตัดสินใจเลือกวิธีการเชิงเทคนิคแลว ทีมงานจึงแตกโครงสรางจําแนกงาน เพื่อกําหนดชิน้ งานในขนาดที่

สามารถจัดการได (ไดกลาวในบทการบริหารขอบเขตโครงการ) หลังจากนัน้ ทีมงานพัฒนานิยามกิจกรรม
เพื่อกําหนดงานที่เกี่ยวของในแตละกิจกรรมในโครงสรางจําแนกงาน (ดูในการบริหารเวลาโครงการ)
ขั้นตอนสุดทายคือ การมอบหมายงานใหกบั ทีมงานยอย

รูปที่ 8.5 กระบวนการมอบหมายและนิยามงาน (Schwalbe, 2007)

เมื่อผูจัดการโครงการและทีมงานไดแตกงานเปนชิน้ งานยอยที่สามารถจัดการได
ผูจัดการโครงการมอบหมายงานใหกับทีมงานยอย ผูจัดการโครงการชอบมอบหมายงานโดยดูวา งาน
เหมาะกับทีมงานใด ซึ่งแสดงในผังโครงสรางองคการโครงการ เชน ทีมวิศวกรรมซอฟตแวร ทีมพัฒนา
ซอฟตแวร และทีมพัฒนางานฮารดแวร เปนตน

รูปที่ 8.6 ตัวอยางของผังการมอบหมายความรับผิดชอบ (RAM) (Schwalbe, 2007)

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารทรัพยากรมนุษย หนา 8-15

8.3.3 ผังการมอบหมายความรับผิดชอบ
ผังการมอบหมายความรับผิดชอบ (responsibility assignment matrices (RAM)) คือ
ผังที่แสดงการจับคูระหวางงานของโครงการที่แสดงใน WBS กับทีมที่รับผิดชอบทีจ่ ะทํางานนั้น รูปที่ 8.6
คือ ตัวอยางของผังการมอบหมายความรับผิดชอบ ทางที่ดีที่สุดสําหรับกรณีที่เปนโครงการเล็กคือ การ
กําหนดคนแตละคนใหกับกิจกรรมที่แตกยอย แตทางที่มีประสิทธิผลที่สุดสําหรับโครงการขนาดใหญคือ
การกําหนดงานใหกบั หนวยงานของโครงการหรือทีมงานยอย

รูปที่ 8.7 การแสดงบทบาทของผูมสี วนไดเสียโดยใช RAM (Schwalbe, 2007)

นอกจากนีเ้ ราสามารถใชผงั การมอบหมายความรับผิดชอบ เพื่อกําหนดกิจกรรมงานที่

ละเอียดกับผูม ีสวนไดสวนเสียของโครงการดังแสดงในรูปที่ 8.7 ในรูปไดแสดงวา ผูมีสวนไดเสียคนใดตอง
รับผิดชอบ (accountable) หรือเพียงแคมสี วนรวมในสวนหนึ่งของโครงการ (participant) หรือใหขอมูลที่
ตองการ (input) หรือทบทวน (review) หรือลงชื่อรับรอง (sign-off)

8.3.4 แผนการบริหารกําลังพลและแผนภูมแิ ทงทรัพยากร

ผลลัพธของการวางแผนทรัพยากรมนุษยคือ แผนการบริหารกําลังพล ซึ่งจะอธิบายวาคน
จะถูกเพิ่มเขาและเอาออกจากทีมงานเมื่อไรและอยางไร แผนนี้เปนสวนหนึ่งของแผนบริหารโครงการ แผน
บริหารกําลังพลอาจอธิบายประเภทคนทีต่ องการทํางานกับโครงการ เชน จาวาโปรแกรมเมอร
นักวิเคราะหธรุ กิจ ผูออกแบบฐานขอมูล เปนตน และระบุจํานวนคนของแตละประเภทที่ตองการแตละ
เดือน นอกจากนี้อาจอธิบายวาทรัพยากรเหลานี้จะไดมาอยางไร การอบรม การใหรางวัล เปนตน
แผนการบริหารกําลังพลรวมแผนภูมิแทงทรัพยากร ซึ่งแสดงจํานวนทรัพยากรที่ไดรับการ
มอบหมายใหกับโครงการ รูปที่ 8.8 แสดงตัวอยางแผนภูมิแทงทรัพยากรทีใ่ ชกับโครงการเทคโนโลยี
สารสนเทศเปนเวลา 6 เดือน สดมภแทนจํานวนคนทีต่ องการในแตละประเภทในแตละเดือน หลังจาก
กําหนดคนที่ตอ งการของโครงการแลว ขัน้ ตอนตอไปในการบริหารทรัพยากรมนุษยคือ การหาพนักงานที่
จําเปนและพัฒนาทีมงานโครงการ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารทรัพยากรมนุษย หนา 8-16

รูปที่ 8.8 ตัวอยางแผนภูมิแทงทรัพยากร (Schwalbe, 2007)

8.4 การไดทีมงาน
การไดคนทางดานเทคโนโลยีสารสนเทศทีม่ ีคุณสมบัติตามตองการเปนเรื่องที่สําคัญ มีการ
กลาวกันวา ผูจัดการโครงการคือ คนทีฉ่ ลาดที่สุดในทีม แตทาํ การสรรหาพนักงานไมดี ในการสรรหา
พนักงานใหมควรมีการกําหนดประเภทและจํานวนคนทีต่ องทํางานกับโครงการ ณ เวลาที่เหมาะสม

8.4.1 การคัดเลือกสมาชิกทีมงาน
หลังจากการพัฒนาแผนการบริหารคน ผูจ ัดการโครงการตองทํางานรวมกับผูอื่นในองค
การเพื่อคัดเลือกคนเฉพาะใหกับโครงการ หรือหาพนักงานที่ตองการเพิ่ม องคการตองแนใจวา คนที่จัด
ใหกับโครงการนั้นมีทักษะตรงกับที่ตองการมากที่สุด
องคการทีท่ าํ การสรรหาพนักงานไดดีจะมีแผนกําลังพลทีด่ ี แผนนีจ้ ะบอกจํานวนและ
ประเภทคนทีม่ ีอยูในองคการปจจุบัน และจํานวนคนและประเภทของคนที่คาดวาจําเปนสําหรับโครงการ
ปจจุบันและสําหรับโครงการที่จะมีในเวลาอันใกล ความสําคัญของแผนกําลังพลคือ การบํารุงรักษาความ
สมบูรณและความถูกตองของคลังทักษะของบุคคลากร จากการศึกษาวิจยั พบวา พนักงานออกจากงาน
เนื่องจาก
• ไมมีอะไรที่แตกตาง
• ไมไดรับการระลึกถึงอยางเหมาะสม
• ไมไดเรียนรูอะไรใหม หรือกาวหนา

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารทรัพยากรมนุษย หนา 8-17

• ไมชอบเพื่อนรวมงาน
• ตองการไดรับเงินมากขึน้

การคัดเลือกสมาชิกโครงการนั้น ผูจัดการโครงการควรเลือกสมาชิกทีมงานที่มี
คุณลักษณะดังนี้
• สามารถแกปญ  หา ผูจัดการโครงการตองคัดเลือกบุคคลที่สามารถทํางาน
ภายใตภาวะความไมแนนอน รูปญหาและวิธีการแกปญ  หา
• ใหคํามัน่ สัญญา ผูจัดการโครงการตองการคนที่ใหความสําคัญกับบทบาท
หนาที่และความรับผิดชอบที่ไดรับ โดยที่ไมจําเปนตองคอยเตือน
• รับผิดชอบรวมกัน สมาชิกทีมงานตองรับทั้งผลสําเร็จและลมเหลวรวมกัน
เมื่อสมาชิกคนใดมีปญหา สมาชิกคนอื่นควรอาสาเขาชวยเหลือ
• ยืดหยุน สมาชิกตองเต็มใจทีจ่ ะปรับตัวเขาสถานการณตา งๆ
• ใหความสําคัญกับงาน สมาชิกตองสามารถทําใหงานที่ไดรับมอบหมาย
เสร็จตามแผนของโครงการ
• สามารถทํางานกับเวลาที่จํากัด สมาชิกตองเผชิญกับปญหางานทีค่ นอืน่
รับผิดชอบเกิดความลาชา สมาชิกโครงการตองสามารถหาวิธกี ารทํางานให
ภายในเวลาที่เหลือ
• ไววางใจและสนับสนุนซึง่ กันและกัน สมาชิกในทีมตองไววางใจและ
สนับสนุนซึง่ กันและกัน สมาชิกตองเห็นใจกันและพรอมที่จะชวยเหลือกัน
เมื่อตองการ
• ใหความสําคัญกับทีม สมาชิกตองตระหนักถึงทีมกอนตนเอง การใชคํา
สนทนาวา “ฉัน” กับ “เรา” จะเปนตัวชี้วา สมาชิกคนนัน้ ใหความสําคัญกับ
ทีมหรือไม
• เปดเผย สมาชิกที่เปดเผยจะแสดงออกถึงมุมมอง คําตอบของปญหาที่
ตนเองคิดวาดีที่สุดสําหรับทีม และโครงการ
• สามารถทํางานขามหนวยงาน โครงการตองการสมาชิกที่สามารถทํางานกับ
คนที่มาจากฝง ธุรกิจ ซึ่งมีความคิดและมุมมองที่ตางไปจากคนดาน
เทคโนโลยีสารสนเทศ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารทรัพยากรมนุษย หนา 8-18

• สามารถใชเครือ่ งมือการบริหารโครงการ โครงการมีการวางแผนดวย

ซอฟตแวรทหี่ ลากหลาย สมาชิกควรมีความคุน เคยกับซอฟตแวรเหลานี้
เนื่องจากสมาชิกอาจตองใหขอมูลสถานภาพของงาน ความกาวหนาของ
งานผานซอฟตแวรโดยตรง

8.4.2 การมอบหมายงานใหกบั สมาชิก

เมื่อไดคนมาแลว ผูจัดการโครงการจะมอบหมายงานใหกับสมาชิก ผลลัพธของ
กระบวนการนีค้ ือ การกําหนดพนักงานใหกับงาน ขอมูลทรัพยากรที่มีใหใช และการปรับปรุงแผนการ
บริหารคน กอนที่ผูจดั การโครงการจะทําการมอบหมายงาน ผูจัดการโครงการตองทําการประเมิน
ความสามารถของพนักงานกอนวา ใครมีความสามารถในการทําแตละกิจกรรมเทาใด โดยประเมิน
ออกมาเปนคาใชจาย ดังแสดงในตารางที่ 8.2 จากนัน้ จึงมอบหมายงานใหแตละคนโดยคํานึงถึงทักษะ
และเวลา ซึ่งมีขั้นตอนการทําดังนี้

ขั้นตอนที่ 1 นําคาทีน่ อยทีส่ ุดของแตละแถวลบออกจากทุกคาในแถวนั้น หลังจาก

นั้น นําคาที่นอยที่สุดของแตละสดมภลบออกจากทุกคาในสดมภนนั้
ขั้นตอนที่ 2 ขีดเสนทั้งแนวตั้งและแนวนอนที่ครอบคลุม 0 ทุกตัวในตารางให
จํานวนเสนนอยที่สุด นับจํานวนเสน ถาจํานวนเสนเทากับจํานวนแถว
หรือสดมภคาใดคาหนึง่ แสดงวาตารางการมอบหมายงานเปนตาราง
ที่เสียคาใชจายนอยที่สุด ใหไปทําขั้นตอนที่ 4
ขั้นตอนที่ 3 ถาจํานวนเสนไมเทากับจํานวนแถวหรือสดมภ ใหนําคาทีน่ อยที่สุดที่
ไมไดถูกตัดดวยเสนไปลบออกจากทุกคาที่ไมมีเสนตัดผาน บวก
จํานวนเดียวกันนีก้ ับคาที่เสนมาตัดกัน แลวกลับไปขั้นตอนที่ 2
ขั้นตอนที่ 4 ทําการมอบหมายงานทีม่ ีคา 0 ใหกับบุคคลที่อยูในตําแหนงเดียวกัน
ในตาราง

ตัวอยางการมอบหมายงาน
สมมุติให A, E, H กิจกรรมกลุมที่ 1
B, C กิจกรรมกลุมที่ 2
D, F, G กิจกรรมกลุมที่ 3
I, J กิจกรรมกลุมที่ 4

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารทรัพยากรมนุษย หนา 8-19

โดยที่แตละกลุมกิจกรรมสามารถทําโดยพนักงาน 4 คนดวยคาใชจา ยที่แตกตางกันดัง

แสดงในตารางที่ 8.2 คาใชจายของแตละคนในการทํากิจกรรมแตละกลุมอาจไดจากการประมาณการของ
ผูจัดการโครงการหรือผูเชี่ยวชาญ หรือใชขอมูลที่เกิดขึ้นในอดีตของโครงการที่มีงานลักษณะที่เหมือนกับ
งานของโครงการที่เรากําลังดําเนินการ

ตารางที่ 8.2 คาใชจายของแตละคนในการทํากิจกรรมแตละกลุม

กลุมกิจกรรม
1 2 3 4
สุชาติ 18 10 15 12
ประวัติ 15 13 10 11
กิตติ 16 8 16 13
สุวรรณี 14 11 12 9

ขั้นตอนที่ 1 นําคาทีน่ อยทีส่ ุดในแตละแถว ไปลบทุกคาในแตละแถว ผลที่ไดคือ

ตารางที่ 8.3 คาทีน่ อยที่สุดแตละแถวมีดงั นี้
แถวที่ 1 คือ 10
แถวที่ 2 คือ 10
แถวที่ 3 คือ 8
แถวที่ 4 คือ 9

ตารางที่ 8.3 ผลการลบคาที่นอยที่สุดของแตละแถว (ขั้นตอนที่ 1)

กลุมกิจกรรม
1 2 3 4
สุชาติ 8 0 5 2
ประวัติ 5 3 0 1
กิตติ 8 0 8 5
สุวรรณี 5 2 3 0

นําคาทีน่ อยทีส่ ุดของแตละสดมภลบออกจากทุกคาในสดมภนั้น

ผลที่ไดคือ ตารางที่ 8.4 คาที่นอยที่สุดของแตละสดมภมีดังนี้
สดมภที่ 1 คือ 5
สดมภที่ 2 คือ 0

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารทรัพยากรมนุษย หนา 8-20

สดมภที่ 3 คือ 0
สดมภที่ 4 คือ 0

ตารางที่ 8.4 ผลการลบคาที่นอยที่สุดของแตละสดมภ (ขั้นตอนที่ 1)

กลุมกิจกรรม
1 2 3 4
สุชาติ 3 0 5 2
ประวัติ 0 3 0 1
กิตติ 3 0 8 5
สุวรรณี 0 2 3 0

ขั้นตอนที่ 2 ขีดเสนทัง้ แนวตั้งและแนวนอนที่ครอบคลุม 0 ทุกตัวในตารางโดยให

จํานวนเสนนอยที่สุด ผลที่ไดคือ ตารางที่ 8.5

ตารางที่ 8.5 ผลการดําเนินการตามขั้นตอนที่ 2

กลุมกิจกรรม
1 2 3 4
สุชาติ 3 0 5 2
ประวัติ 0 3 0 1
กิตติ 3 0 8 5
สุวรรณี 0 2 3 0

จํานวนแถวคือ 4 จํานวนสดมภคือ 4 สวนจํานวนเสนทีเ่ ขียนคือ 3

ดังนัน้ ตองทําขั้นตอนที่ 3
ขั้นตอนที่ 3 นําคาทีน่ อยที่สดุ ที่ไมไดถูกตัดดวยเสน ซึง่ คือ 2 ไปลบออกจากทุก
คาที่ไมมีเสนตัดผาน บวกจํานวนเดียวกันนี้ (2) กับคาที่เสนมาตัด
กัน แลวกลับไปขั้นตอนที่ 2 ผลลัพธจากขัน้ ตอนนี้คือ ตารางที่ 8.6
ซึ่งไดจํานวนเสนเทากับจํานวนแถวและจํานวนสดมภ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารทรัพยากรมนุษย หนา 8-21

ตารางที่ 8.6 ผลการดําเนินการขั้นตอนที่ 3

กลุมกิจกรรม
1 2 3 4
สุชาติ 1 0 3 0
ประวัติ 0 5 0 1
กิตติ 1 0 6 3
สุวรรณี 0 4 3 0

ขั้นตอนที่ 4 ทําการมอบหมายงานที่มีคา 0 ใหกับบุคคลที่อยูในตําแหนงเดียวกัน

ในตาราง โดยพิจารณาจากแถวหรือสดมภที่มีคา 0 จํานวนนอย
ที่สุด ดังนัน้ กิตติที่มีกลุม กิจกรรมที่ 2 เพียงกลุมเดียวทีม่ ีคา 0
ดังนัน้ สุชาติจงึ เหลืองานกลุม กิจกรรมที่ 4 เทานัน้ ที่เปน 0 สุชาติจึง
ควรไดงานกลุม นี้ไป สวนสุวรรณีและประวัติมีจํานวน 0 เทากัน แต
สุวรรณีมีคาใชจายกิจกรรมที่ 1 นอยกวาประวัติ จึงไดรับมอบหมาย
ใหทาํ งานกลุมกิจกรรมที่ 1 ดังนัน้ สุวรรณีจงึ ควรรับผิดชอบกิจกรรม
ที่ 3 คาใชจายมีดังนี้
กิตติ กิจกรรมกลุมที่ 2 8,000 บาท
สุชาติ กิจกรรมกลุมที่ 4 12,000 บาท
สุวรรณี กิจกรรมกลุมที่ 1 14,000 บาท
ประวัติ กิจกรรมกลุมที่ 3 10,000 บาท
รวมคาใชจายทั้งหมด 44,000 บาท

8.4.3 การบรรจุทรัพยากร
ในบทการบริหารเวลาโครงการไดอธิบายถึงการใชผงั เครือขาย เพื่อชวยผูจัดการโครงการ
บริหารตารางเวลาโครงการ ปญหาหนึง่ ในกระบวนการจัดตารางเวลาโครงการคือ ประเด็นของการมีและ
การใชทรัพยากร มาตรวัดความสําเร็จทีส่ ําคัญของผูจดั การโครงการคือ ผูจัดการโครงการสามารถสราง
ความสมดุลระหวางการดําเนินงาน เวลา และคาใชจายใหดีไดอยางไร ในระหวางชวงเวลาวิกฤต มันมี
ความเปนไปไดบางที่จะเพิ่มทรัพยากร เชน พนักงาน ใหกับโครงการ โดยมีคาใชจายเล็กนอย หรือไมมี
เปาหมายของผูจัดการโครงการคือ ตองประสบความสําเร็จโดยปราศจากการเพิ่มคาใชจา ยหรือเวลา
กุญแจสําคัญเพื่อความสําเร็จคือ การบริหารทรัพยากรมนุษยอยางมีประสิทธิผล
เมื่อมีการมอบหมายพนักงานกับโครงการ ผูจัดการโครงการสามารถใชเทคนิคที่จะชวย
ใหการใชพนักงานไดอยางมีประสิทธิผล เทคนิคดังกลาวคือ การบรรจุทรัพยากร และการจัดระดับ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารทรัพยากรมนุษย หนา 8-22

ทรัพยากร การบรรจุทรัพยากรคือ ปริมาณของทรัพยากรแตละอยางที่ปรากฎในตารางเวลาชวงระยะเวลา

หนึง่ การบรรจุทรัพยากรจะชวยผูจัดการโครงการพัฒนาความเขาใจเกี่ยวกับความตองการของโครงการที่
มีตอทรัพยากรองคการพรอมกับตารางเวลาของแตละคน ผูจัดการโครงการนิยมใชแผนภูมิแทงเพื่อแสดง
ความผันแปรในการบรรจุทรัพยากร ซึ่งชวยในการกําหนดความตองการพนักงาน หรือชวยในการระบุ
ปญหาการจัดพนักงาน

รูปที่ 8.9 ตัวอยางแผนภูมิแทงที่แสดงพนักงานที่ไดรับมอบหมายงานมากเกินไป

แผนภูมิแทงทีแ่ สดงการใชทรัพยากรสามารถบอกใหผูจดั การโครงการรูวา มีการใหงาน

กับคนหรือกลุม มากเกินไปหรือไม ดังแสดงในรูปที่ 8.9 จากรูปพบวา วิยะดาไดรับมอบหมายใหทาํ งานแต
บางวันมากเกินไป ตัวเลขเปอรเซ็นตบนแกนตั้งแทนเปอรเซ็นตของเวลาของวิยะดาที่ถูกจัดสรรใหทํางาน
ใหกับโครงการ แกนนอนดานบนแทนเวลาเปนวัน

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

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารทรัพยากรมนุษย หนา 8-23

ผังเครือขายในรูปที่ 8.10 แสดงกิจกรรม A B และ C ที่สามารถเริ่มพรอมกัน กิจกรรม A

มีระยะเวลาการทํางาน 2 วัน และใชคน 2 คนทํางาน กิจกรรม B ใชเวลาทํางาน 5 วันและใชคน 4 คน
กิจกรรม C ใชเวลา 3 วัน และใชคน 2 คน แผนภูมิแทงดานลางซายแสดงการใชทรัพยากร ถาทุกกิจกรรม
เริ่มตนวันแรก สวนแผนภูมแิ ทงดานลางขวา แสดงการใชทรัพยากร โดยเปลี่ยนใหกจิ กรรม C ทํางานชา 2
วันตามเวลายืดหยุน ทีก่ ิจกรรมนั้นมี ทําใหแผนภูมิแทงดานลางขวาเปนแบบสม่ําเสมอ ดังนัน้ กิจกรรมได
ถูกจัดใหมวี ันวางนอยที่สุดใหประหยัดเวลาและคนทํางาน เนื่องจากสามารถลดจํานวนคนทํากิจกรรม B
จาก 6 คนเปน 4 คน
ผังเครือขายโครงการที่แสดงกิจกรรม A, B และ C
พรอมระยะเวลา กิจกรรม A มีเวลายืดหยุน 3 วัน และ
กิจกรรม C มีเวลายืดหยุน 2 วัน สมมุติวา กิจกรรม A
มีคนทํางาน 2 คน กิจกรรม B มีคนทํางาน 4 คน
และกิจกรรม C มีตนทํางาน 2 คน

การใชทรัพยากร การใชทรัพยากร ถากิจกรรม C ลาชาไป 2 วัน

ถาทุกกิจกรรมเริ่มวันแรก ตามเวลายืดหยุนของกิจกรรม

รูปที่ 8.10 แสดงตัวอยางการจัดระดับทรัพยากร (Schwalbe, 2007)

การจัดระดับทรัพยากรมีประโยชนหลายประการคือ
• การบริหารจัดการนอยลง เมื่อมีการใชทรัพยากรคงที่ เชน ผูจัดการโครงการ
บริหารจัดการคนทีท่ ํางานแบบไมเต็มเวลาที่ไดกําหนดวาทํางานอาทิตยละ 20
ชั่วโมง ไดงายกวาคนทีจ่ ัดเวลาแบบ 10 ชั่วโมง 1 อาทิตย 40 ชั่วโมงอีกอาทิตย
และอาทิตยถดั มาอีก 5 ชั่วโมง
• ผูจดั การโครงการอาจใชนโยบายแบบจัส-อิน-ไทม (Just-in-time) กับผูรับจาง
ตอ เชน ผูจ ดั การโครงการอาจตองการจัดระดับทรัพยากรที่เกี่ยวพันกับงานที่
ตองทําโดยที่ปรึกษาการทดสอบ การจัดระดับอาจทําใหโครงการใชทปี่ รึกษา
ภายนอกเต็มเวลา 4 คน เพื่อทําการทดสอบเปนเวลา 4 เดือน แทนที่จะ
กระจายงานออกไปตามเวลา
• มีปญหากับบุคคลากรโครงการและแผนกบัญชีนอยลง การเพิ่มและการลด
จํานวนพนักงานจะสรางงานเพิม่ และเกิดความสับสน

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารทรัพยากรมนุษย หนา 8-24

• ปรับปรุงจิตใจ คนชอบความสม่ําเสมอในงานของตน มันคอนขางเครียด

สําหรับคนที่ไมรูวาแตละอาทิตย หรือแตละวัน ตองทํางานโครงการใด และกับ
ใคร

8.4.5 การกําหนดตารางเวลาการใชทรัพยากรภายใตขอจํากัดดานทรัพยากร
ในกรณีที่แรงงานมีไมเพียงพอที่จะสนองความตองการในชวงเวลาที่มคี วามตองการ
แรงงานได ผูจัดการโครงการตองจัดลําดับกิจกรรมและจัดสรรคนอยางเหมาะสม เพื่อใหโครงการเกิด
ความลาชานอยที่สุด และไมใชแรงงานเกินกวาจํานวนสูงสุดที่มีอยู ปญหาในการกําหนดเวลาการใช
ทรัพยากรเปนปญหาที่สลับซับซอน ถาโครงการนัน้ เปนโครงการขนาดใหญและใชทรัพยากรตางๆ
มากมายหลายชนิด และทรัพยากรทีจ่ ํากัดหลายชนิด นักวิชาการบางคนไดนาํ เสนอใหใชตัวแบบทาง
คณิตศาสตรในการหาคําตอบที่เหมาะสม เชน วิธีโปรแกรมเสนตรง (linear programming) ซึ่งเปนวิธที ี่
ตองใชขอมูลคอนขางมากในการสรางตัวแบบ ทําใหวิธีการทางคณิตศาสตรไมสะดวกในทางปฏิบัติ
วิธีการอีกวิธที นี่ ิยมใชกันคือ วิธีการฮิวริสติก (heuristics) ซึ่งเปนกฎงายๆ ในการ
แกปญหาที่มคี วามซับซอนมากๆ โดยกําหนดกฎในการตัดสินใจทีจ่ ะจัดสรรบุคคลใหกับกิจกรรมใดกอน
หรือหลังกิจกรรมใด ผลที่ไดจากการจัดสรรไมไดเปนคําตอบที่ดที สี่ ุด แตเปนคําตอบทีน่ าพึงพอใจ
(satisfaction) วิธีการฮิวริสติกกําหนดกฎในการจัดลําดับ (priority) ของกิจกรรมหากบุคลากรมีไม
เพียงพอ กฎทีส่ ําคัญมีดังนี้
• กําหนดบุคลากรใหกับงานทีม่ ีเวลายืดหยุนนอยที่สุด (minimum slack first)
• กําหนดบุคลากรใหกับงานทีใ่ ชเวลาในการดําเนินการสั้นที่สุด (shortest task first)
• กําหนดบุคลากรใหกับงานทีเ่ ริ่มเร็วที่สุด (earliest task first)
• กําหนดบุคลากรใหกับงานทีใ่ ชคนมากที่สดุ (most resources first)
• กําหนดบุคลากรใหกับงานทีม่ ีกิจกรรมวิกฤตตามหลังมากที่สุด (most critical
followers) กิจกรรมใดมีกิจกรรมวิกฤตตามหลังมากที่สดุ จะไดรับการจัดสรรคนให
กอนกิจกรรมอื่น
• กําหนดบุคลากรใหกับงานทีม่ ีกิจกรรมตามหลังมากที่สดุ (most successors)
กิจกรรมใดที่มกี ิจกรรมตามหลังมากที่สุดจะไดรับการจัดสรรบุคลากรกอน
ถึงแมวา กิจกรรมเหลานั้นจะไมไดเปนกิจกรรมวิกฤตก็ตาม

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารทรัพยากรมนุษย หนา 8-25

8.5 การพัฒนาทีมงานโครงการ
ถึงแมวา ผูจัดการโครงการประสบความสําเร็จในการคัดสรรคนที่มีทกั ษะเพื่อมาทํางาน แตเรา
ตองแนใจวาคนเหลานี้สามารถทํางานดวยกันไดเปนทีม เพื่อบรรลุเปาหมายโครงการ เปาหมายหลักของ
การพัฒนาทีมงานโครงการคือ เพื่อชวยคนทํางานดวยกันอยางมีประสิทธิผลเพื่อปรับปรุงประสิทธิภาพ
โครงการ
บรูซ ทักแมน (Bruce Tuckman) ตีพิมพตัวแบบสี่ขนั้ ของการพัฒนาทีมงานในปค.ศ. 1965
และปรับปรุงเพิ่มขั้นในปค.ศ. 1970 ตัวแบบทักแมนมี 5 ขั้นดังนี้
• กอรางสรางทีมงาน (forming) เปนขั้นตอนการแนะนําสมาชิกทีม เพื่อใหเกิดความรูจัก
คุนเคยกัน และทําความเขาใจ มีการกําหนดบทบาทหนาที่ของแตละคน ผลงานที่
คาดหวัง และความสัมพันธระหวางสมาชิกทีมงานโครงการ ทีมงานโครงการสามารถ
ผานขั้นตอนนีไ้ ปสูขั้นตอนตอไปเมื่อสมาชิกโครงการเริ่มเปนสวนหนึง่ ของทีม
• เกิดพายุ (storming) เนื่องจากการสรางทีมงานจะมีสมาชิกใหมทําใหสมาชิกทีมมี
ความเห็นที่แตกตางกันวาทีมควรจะทํางานอยางไร แมวาสมาชิกจะยอมรับวาตนเปน
สวนหนึง่ ของทีมงานโครงการ แตก็ยงั ตอตานการบังคับของกลุม สมาชิกทดสอบซึ่งกัน
และกัน และเกิดความขัดแยงภายในทีม เมื่อสมาชิกยอมรับความเปนผูนาํ ของผูจ ัดการ
โครงการ ทีมงานโครงการจะผานขัน้ ตอนนี้
• สรางบรรทัดฐาน (norming) การแกปญ  หาความขัดแยงตองตกลงบรรทัดฐานและการ
ปฏิบัติของกลุมรวมกัน รวมทัง้ วิธีการการตัดสินใจ การรวมงาน การประชุมและ
กระบวนการทํางาน เมื่อทีมไดตัดสินใจในบรรทัดฐาน คนใหมที่เขามารวมตองไดรับการ
อธิบายถึงบรรทัดฐาน สมาชิกทีมงานไดพฒ ั นาความสัมพันธใหมีความใกลชิดมากยิ่งขึ้น
• ปฏิบัติงาน (performing) เมื่อบรรทัดฐานไดรับการยอมรับ กลุมสามารถใชบรรทัดฐาน
เพื่อบรรลุงานของกลุม สมาชิกปฏิบัติงานตามหนาที่ของตนอยางเต็มที่เพื่อใหบรรลุ
วัตถุประสงคของโครงการ
• สลายตัว (adjourning) เมื่อทีมงานโครงการปฏิบัติงานบรรลุวัตถุประสงคของโครงการ
แลว ทีมงานจะเขาสูขั้นตอนสลายตัว ซึง่ เปนการแยกกันของสมาชิกทีมงานกลับไปยัง
หนวยงานตนสังกัดเดิม

ตัวแบบการพัฒนาทีมงานโครงการดังกลาวขางตนใหขอแนะนําในการบริหารโครงการที่สําคัญ
คือ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารทรัพยากรมนุษย หนา 8-26

• ผูจัดการโครงการตองทุม เทความสนใจใหกับทีมงาน เพื่อชวยใหทีมงานสามารถพัฒนา

มาถึงขั้นตอนการปฏิบัติงานอยางรวดเร็ว โครงการจึงจะไมเกิดความลาชา
• ตัวแบบนี้ใหกรอบที่ทําใหสมาชิกเขาใจการพัฒนาของทีม ผูรวมทีมมีสวนรวมพัฒนาตาม
ตัวแบบ ซึ่งจะชวยทําใหสมาชิกโครงการยอมรับสภาพความตึงเครียดที่จะเกิดขึ้นในขั้น
เกิดพายุ และพยายามมุงสูข ั้นตอนทีม่ ีประสิทธิภาพมากขึ้น
• ผูจัดการโครงการตองมีบทบาทสําคัญในการสรางบรรทัดฐาน ซึง่ เปนขัน้ ตอนที่มีสวน
สนับสนุนอยางสําคัญตอระดับประสิทธิภาพของขัน้ ตอนปฏิบัติงาน

8.5.1 การจัดสมดุลของทีมงาน
สมาชิกของทีมประกอบดวยพนักงานหลายคนมารวมตัวกัน เพื่อใหโครงการสําเร็จตาม
วัตถุประสงค การเลือกสมาชิกมารวมทีมนอกจากจะพิจารณาจากคุณลักษณะที่กลาวมากอนหนานี้แลว
ผูจัดการโครงการยังพิจารณาพฤติกรรมเชิงสังคมของสมาชิกดวย การจัดสมดุลของทีมเปนปจจัยความ
สําเร็จที่สาํ คัญอีกปจจัยหนึ่ง ปจจัยเชิงสังคมทําใหแบงคนออกเปน 4 กลุมดังนี้
• การรับการเปลี่ยนแปลง (assimilating) คนประเภทนี้เกงในการรวบรวม และการ
แทนขอมูลในรูปแบบใหม เนนที่ความคิดและแนวคิดมากกวาบุคคล คนประเภทนี้
ชอบใชขอมูลและตัวแบบอธิบายสถานการณจากมุมมองกวาง ดังนัน้ คนพวกนี้ให
ความสนใจในสิ่งที่สมเหตุสมผลมากกวาคานิยมเชิงปฏิบัติใดๆ (practical value)
ไมใชคนที่ใหความสําคัญกับผลลัพธ เราจะพบคนกลุมนีใ้ นอาชีพทางเทคนิค หรือ
เชี่ยวชาญเฉพาะ เชน นักพัฒนาระบบ ดังนัน้ คนประเภทนีเ้ หมาะกับการเปนผู
กําหนดปญหาและโอกาส
• ความแตกตาง (diverging) คนประเภทนี้ชอบคนหาทางเลือกและมองสถาน
การณจากมุมมองทีห่ ลากหลาย เปนพวกสังเกตการณมากกวาลงมือกระทําเอง
ชอบการระดมสมอง คิดนอกกรอบ และเสนอวิธกี ารอื่นนอกเหนือจากวิธีการที่ได
กําหนดไวแลว คนกลุมนี้จงึ เหมาะกับงานประเภทเสนอความคิดใหมๆ
• การปรับใหเหมาะสม (accommodating) เปนกลุม คนที่ใหความสําคัญกับผลลัพธ
และตองการผลักดันสิ่งตางๆ ไปสูการปฏิบัติ เปนพวกปรับตัวและเปลี่ยนแปลงงาย
ในสถานการณตางๆ เกงในการทําใหงานเกิดขึ้น เปนคนลงมือทํางานดวยตัวเอง
และเปนสมาชิกในทีมที่ดี คนกลุมนี้เปนพวกนักแกปญหา เชื่อถือขอมูลจากบุคคล
มากกวาการวิเคราะหทางเทคนิค ในฐานะเปนสมาชิกของทีม ผูจัดการโครงการ
สามารถไวใจคนประเภทนี้ไดเพราะจะชวยทําใหทีมงานแข็งแกรง เปนผูอํานวย

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารทรัพยากรมนุษย หนา 8-27

ความสะดวกและประสานงานที่ดี รวมทัง้ เปนผูรักษาสันติภาพดวย ดังนัน้ คน

ประเภทนี้เหมาะกับการเปนผูดําเนินงานตามแผน
• การรวมกัน (converging) คนเปนเภทนี้จะรวบรวมสารสนเทศเขาดวยกันเพื่อแก
ปญหา เปนผูห าคําตอบมากกวาเปนคนดําเนินการเอง จุดแข็งของพวกเขาขึ้นอยู
กับความสามารถในการนําแนวคิด ตัวแบบ และความคิดไปสูการปฏิบัติ เปนพวก
ที่ชอบทํางานเชิงเทคนิคและปญหามากกวาจะทํางานที่เกี่ยวของกับคน เปนคนที่
เกงในการเลือกตัวเลือกที่ดที ี่สุด สําหรับการเปนสมาชิกทีมงาน คนเหลานี้เปนพวก
ที่เนนผลลัพธ คนประเภทนี้ขับเคลื่อนทีมงานใหทํางานโดยการชวยทีมเลือกวิธีการ
ที่ดีที่สุดสําหรับสถานการณ และระดมทีมงานใหทํางาน สรุปแลวคนประเภทนี้จึง
เหมาะกับการประเมินและจัดลําดับความคิด หรือทางเลือก

สมมติวาทีมงานที่มีคนประเภทรวมกัน แตไมมีคนประเภทคิดแตกตางเลย ผลที่เกิดขึ้น

คือจะไมมีใครคอยกระตุนใหทีมงานคนหาทางเลือกอืน่ ๆ ทําใหเรารีบรอนตัดสินใจตามที่คนประเภท
รวมตัวบอกใหทีมงานทํา หรือการที่ทมี งานไมมีคนประเภทปรับตัวใหเขาหากัน จะทําใหทีมงานขาดคนที่
จะประสานงานกับคนที่เกี่ยวของกับโครงการ เปนตน

8.5.2 การอบรม
ผูจัดการโครงการจะแนะนําใหคนเขารับการอบรมหลักสูตรเฉพาะ เพื่อเปนการพัฒนา
ทีมงานและเปนการพัฒนาความสามารถของแตละคนใหดีขึ้น การใหการอบรมแบบจัส-อิน-ไทม เปนสิ่ง
สําคัญ การอบรมบางครั้งใชเวลามาก หลายองคการจัดใหมีการเรียนรูดวยระบบอิเลคทรอนิกสสําหรับ
พนักงานขององคการ ดังนัน้ พนักงานสามารถเรียนทักษะเฉพาะ ณ เวลา และสถานที่ใดก็ได นอกจากนี้ใน
บางครั้ง การอบรมแบบอิเลคทรอนิกส ประหยัดคาใชจายไดมากกวาวิธกี ารอบรมแบบดั้งเดิม ผูจัดการ
โครงการตองแนใจวาเวลาและวิธีการสงมอบการอบรมเหมาะสมกับสถานการณเฉพาะ องคการพบวา
องคการจะประหยัดถาอบรมพนักงานปจจุบันในเรื่องเฉพาะมากกวาการจางคนใหมที่มที ักษะที่ตอ งการ

8.5.3 ระบบการยอมรับนับถือและรางวัล
เครื่องมือสําคัญอีกอยางหนึง่ ที่ใชในการสงเสริมการพัฒนาทีมคือ ระบบรางวัลและการ
ยอมรับนับถือ ถาผูจัดการโครงการใหรางวัลทีมงาน ผูบ ริหารไมควรคํานึงถึงผลงานของสมาชิกแตละคน
แตถาผูจัดการโครงการจะใชวิธีการใหรางวัลแกสมาชิกรายบุคคล ผูจดั การโครงการควรนําวิธีการนี้มาใช
กับบุคคลที่สมาชิกทีมงานโครงการสวนใหญตางยอมรับ เพื่อมิใหเกิดปญหาการตอตานหรือเกิดความ
ขัดแยงในกลุมสมาชิกทีมงาน

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารทรัพยากรมนุษย หนา 8-28

รางวัลที่ผูจัดการโครงการจะใหกับทีมงาน หรือสมาชิกโครงการ อาจเปนไดทงั้ ที่เปนตัว

เงิน หรืออาจเปนสิ่งที่ทาํ ใหเกิดความภาคภูมิใจในผูรับ และสามารถจดจําไปไดนานๆ บางองคการเสนอ
ใหรางวัลเปนการเดินทางทองเทีย่ ว บัตรของขวัญใหไปรับประทานอาหารในภัตตาคาร บัตรชมภาพยนตร
หรือคํายกยองชมเชยในที่ประชุมหรือตอสาธารณะเปนตน
ผูจัดการโครงการตองประเมินผลการดําเนินงานของทีมงานอยางตอเนื่อง เมื่อพบวาสวน
ใดที่แตละคนหรือทั้งทีมสามารถปรับปรุง ผูจัดการโครงการควรคนหาวิธีที่ดที ี่สุดเพือ่ พัฒนาคนของตนและ
ปรับปรุงการดําเนินงาน

8.6 การบริหารทีมงาน
หลังจากการประเมินผลการดําเนินงานของทีม ผูจดั การโครงการตองตัดสินใจถามีการขอ
เปลี่ยนแปลงโครงการ หรือมีการแนะนําใหแกไขหรือปองกัน หรือใหปรับปรุงแผนบริหารโครงการ ผูจัดการ
โครงการตองใชทักษะทางดานคนเพื่อคนหาวิธีการที่ดที สี่ ุด และบริหารสมาชิกโครงการแตละคน

8.6.1 เทคนิคและเครื่องมือสําหรับการบริหารทีมงานโครงการ
มีเทคนิคและเครื่องมือหลายอยางที่ชว ยการบริหารทีมดังนี้
• การเฝาสังเกตและการสนทนา (observation and conversation) มันเปนการ
ยากที่จะประเมินสมาชิกทีมงานวาทํางานดีหรือไม หรือพวกเขารูสึกกับงาน
อยางไร ถาผูจัดการโครงการไมเคยดู หรือสนทนาประเด็นเหลานี้ ผูจัดการ
โครงการหลายๆ โครงการชอบทําการบริหารโดยการเดินรอบๆ เพื่อใหเห็นกับตา
และไดยินกับหูจริงๆ การสนทนาอยางเปนทางการและไมเปนทางการเกี่ยวกับ
โครงการวาเปนอยางไร เปนไปดวยดีหรือไม จะเปนวิธกี ารใหขอมูลที่สําคัญ
สําหรับกรณีพนักงานเสมือน (virtual workers) ผูจัดการโครงการควรเฝาสังเกต
และสนทนางานและประเด็นตางๆ ผานไปรษณียอิเลคทรอนิกส โทรศัพท หรือ
สื่อการสื่อสารอื่นๆ
• การประเมินผลการดําเนินโครงการ (project performance appraisals) ความ
จําเปนและประเภทการประเมินผลการดําเนินโครงการจะแตกตางไปตามระยะ
เวลาของโครงการ ความซับซอนของโครงการ นโยบายองคการ สัญญา และการ
สื่อสารที่เกีย่ วของ ถึงแมวา ผูจัดการโครงการไมประเมินผลการดําเนินโครงการ
ของสมาชิกอยางเปนทางการ การใหขอมูลยอนกลับกับสมาชิกทีท่ ันตอเวลายัง
เปนสิ่งสําคัญ ถาสมาชิกสงงานชา ผูจัดการโครงการควรหาเหตุผลสําหรับ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารทรัพยากรมนุษย หนา 8-29

พฤติกรรมนี้ และดําเนินการที่เหมาะสมในการแกสิ่งที่เกิดขึ้น ถาความลาชา

เกิดขึ้นเพราะมีคนในครอบครัวมีปญหาและทําใหไมมีสมาธิ หรือสมาชิกวาง
แผนที่จะออกจากโครงการ สาเหตุที่เกิดขึ้นมีผลกระทบอยางแรงตอการเลือก
การกระทําของผูจัดการโครงการตอปญหาที่เกิดขึ้น
• การบริหารความขัดแยง (conflict management) มีโครงการจํานวนไมมากที่
เสร็จสมบูรณ โดยไมมีความขัดแยง ความขัดแยงบางประเภทเปนเรื่องที่ดีตอ
โครงการ บางประเภทก็ไมใช การบริหารการสื่อสารโครงการไดกลาวถึงวิธีการ
หลายวิธที ี่จะจัดการกับความขัดแยง มันเปนเรื่องสําคัญที่ผูจัดการโครงการควร
เขาใจกลยุทธสําหรับจัดการความขัดแยงและควรบริหารความขัดแยงกอนลวง
หนา รายละเอียดของการบริหารความขัดแยงจะไดกลาวในบทตอๆ ไป
• บันทึกประเด็น (issue logs) ผูจัดการโครงการหลายคนเก็บบันทึกประเด็นตางๆ
เพื่อทําเปนเอกสาร และติดตามประเด็นที่จาํ เปนเพือ่ แกปญหาอยางมี
ประสิทธิผล ประเด็นที่บนั ทึกประกอบดวยหัวขอตอไปนี้
ƒ จุดที่เกิดความคิดเห็นที่แตกตาง
ƒ สถานการณทจี่ ําเปนตองทําใหเกิดความชัดเจน หรือสืบสวน
ƒ ความกังวลโดยทั่วไปที่จําเปนตองบันทึก
ประเด็นที่สามารถทํารายการทํางานของทีมงานควรประกาศใหสมาชิกทราบ
และทําการแกไขประเด็นเหลานัน้ ผูจัดการโครงการควรตั้งคนใดคนหนึ่งเพื่อแก
ประเด็นแตละประเด็น และกําหนดวันที่คาดวาจะแกไขเสร็จ

8.6.2 คําแนะนําทัว่ ไปสําหรับการบริหารทีม

ผูจัดการโครงการที่มปี ระสิทธิผลตองเปนผูนําทีมที่ดี ขอแนะนําสําหรับผูจดั การเพื่อ
บริหารใหทีมงานมีประสิทธิภาพมีดังนี้
• อดทนและเมตตาตอทีม ใหนกึ สิ่งที่ดีที่สดุ ของสมาชิก ไมคิดวาสมาชิกทีมงาน
ขี้เกียจและไมระมัดระวัง
• แกปญหาแทนการวากลาวและชวยแกปญ  หา โดยการเนนทีพ่ ฤติกรรมไมใช
ตัวบุคคล
• กําหนดการประชุมทีม่ ีประสิทธิผล สม่าํ เสมอ ใหเนนที่วัตถุประสงคโครงการ
และสรางผลลัพธทางบวก

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารทรัพยากรมนุษย หนา 8-30

• ใหเวลาทีมงานในการผานชวงการสรางทีมงานพืน้ ฐาน ไมคาดหวังทีมงาน

ทํางานดวยประสิทธิภาพสูงสุด
• จํากัดขนาดของทีมงานไวที่ 3-7 คน
• วางแผนกิจกรรมทางสังคมบาง เพื่อชวยสมาชิกทีมงาน และผูมีสว นไดเสีย
โครงการอื่นๆ ไดรูจักกันไดดีขึ้น
• เนนอัตลักษณทีม สรางธรรมเนียมทีท่ ําใหสมาชิกทีมสนุกสนาน
• ทะนุถนอมสมาชิกทีมงานและกระตุนสงเสริมใหพวกเขาชวยเหลือกัน ใหการ
อบรมที่จะชวยแตละคนและทีมงานทัง้ ทีมใหกลายเปนทีมงานทีท่ ํางานอยาง
ประสิทธิผล
• ประกาศผลสัมฤทธิ์ของแตละคนและของทีมงาน
• ถาเปนไปไดควรมีกิจกรรมรวมกับสมาชิกเสมือน (virtual team member) มี
การประชุมแบบพบปะ หรือทางโทรศัพทตอนเริ่มตนโครงการเสมือน หรือตอน
แนะนําสมาชิกเสมือน คัดเลือกคนอยางระมัดระวังเพื่อใหแนใจวาพวกเขา
สามารถทํางานไดอยางมีประสิทธิผลในสภาพแวดลอมเสมือน กําหนดให
ชัดเจนถึงการสื่อสารของสมาชิกเสมือน

การพัฒนาและการบริหารทีมเปนภาระที่สาํ คัญของโครงการเทคโนโลยีสารสนเทศ
ผูจัดการโครงการเทคโนโลยีสารสนเทศตองเนนที่การฟงอยางรวมอารมณกับผูอื่น เพื่อใหรูความกังวลของ
พวกเขา และสรางสภาพแวดลอมที่แตละคนและทีมงานสามารถเติบโตและเจริญรุงเรือง

8.7 สรุป
มนุษยคือ ทรัพยสนิ ที่สาํ คัญที่สุดในองคการและโครงการ ดังนัน้ จึงจําเปนที่ผูจัดการโครงการ
ตองเปนผูบริหารทรัพยากรมนุษยที่ดี กระบวนการสําคัญที่เกี่ยวกับการบริหารทรัพยากรมนุษยคอื การ
วางแผนทรัพยากรมนุษย การไดสมาชิกทีมงาน การพัฒนาทีมงานโครงการ และการบริหารทีมงาน
โครงการ
ประเด็นทางจิตวิทยาทีก่ ระทบตอการทํางานของคนคือ การจูงใจ อิทธิพลและอํานาจ และ
ความมีประสิทธิผล มาสโลวไดพัฒนาลําดับขั้นความตองการที่ประกอบดวย ความตองการพืน้ ฐาน
ทางดานรางกาย ความตองการความมัน่ คงปลอดภัย ความตองการดานสังคม ความตองการเกียรติยศ
ชื่อเสียง และความตองการความสําเร็จในชีวิตตามที่ตนเองตัง้ ใจไว ความตองการเหลานี้เปนตัวกระตุน
พฤติกรรม เมือ่ ความตองการไดรับการสนองตอบแลว มันไมใชตัวกระตุนอีกตอไป

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารทรัพยากรมนุษย หนา 8-31

เฮอรซเบอรกไดแสดงความแตกตางระหวางสิง่ จูงใจและปจจัยไฮยีน ตัวอยางปจจัยไฮยีนไดแก

เงินเดือนสูง หรือสภาพแวดลอมการทํางานที่ดงึ ดูด ถาปจจัยเหลานี้ไมปรากฎ จะทําใหเกิดความไมพอใจ
สวนความสัมฤทธิ์ ความระลึกถึง ความรับผิดชอบ และการเติบโตคือ ปจจัยที่สนับสนุนความพึงพอใจงาน
และจูงใจพนักงาน
แมคคลิแลนดเสนอทฤษฎีความตองการทีไ่ ดจากการเรียนรูตามเวลา และไดรับการปรับโดย
ประสบการณชีวิต ความตองการที่ไดมามี 3 ประเภทคือ ความสัมฤทธิ์ สัมพันธภาพ และความตองการ
อํานาจ
แมคเกรเกอรไดพัฒนาทฤษฎี X และทฤษฎี Y ที่อธิบายวิธีการทีแ่ ตกตางกันเพือ่ การบริหาร
พนักงานตามสมมุติฐานของการจูงใจพนักงาน ทฤษฎี Y สมมุติวา คนมองงานเปนเรื่องธรรมชาติ และชี้วา
รางวัลที่มนี ัยสําคัญคือ ความพึงพอใจในเรื่องการยอมรับนับถือจากผูอ ื่น และความตองการความสําเร็จ
ในชีวิตตามทีต่ นเองตั้งใจไว
ธรรมเฮียนและไวลมอนระบุอิทธิพล 9 อยางที่ผจู ัดการโครงการสามารถใชในการบริหาร
โครงการ อิทธิพลเหลานีป้ ระกอบดวย อํานาจ การมอบหมาย งบประมาณ การสงเสริม เงิน การลงโทษ
ความทาทายของงาน ความเชี่ยวชาญ และความเปนเพื่อน ความสําเร็จของโครงการเกี่ยวของกับผูจัดการ
โครงการที่ใชความทาทายของงานและความเชี่ยวชาญเพื่อชักจูงพนักงาน สวนความลมเหลวของ
โครงการเกีย่ วของกับการใชอํานาจ เงิน หรือการลงโทษมากเกินไป
อํานาจคือ ความสามารถทีม่ ีอิทธิพลตอพฤติกรรมเพื่อใหคนมาทําสิ่งที่เขาไมอยากทํา อํานาจมี
5 ประเภทคือ อํานาจในการขูบังคับ อํานาจที่ไดมาอยางถูกตองตามทํานองครองธรรม อํานาจที่ไดจาก
การยอมรับในความเชีย่ วชาญ อํานาจในการใหรางวัล และอํานาจที่ไดจากการเปนทีด่ ึงดูดใจ
ผูจัดการโครงการสามารถใชอุปนิสัย 7 อยางของสตีเฟน โควีย เพือ่ ชวยตัวเขาเองและทีมงาน
โครงการใหกลายเปนผูทาํ งานที่มปี ระสิทธิผลมากขึ้น อุปนิสัย 7 อยางประกอบดวย เปนผูก ระทํากอน
เริ่มตนดวยจุดมุงหมายในใจ ทําสิ่งที่สําคัญกอน คิดแบบชนะ/ชนะ เขาใจผูอื่นกอน แลวจึงใหผอู ื่นเขาใจ
ประสานพลัง และลับเลื่อยใหคมเสมอ การใชการฟงแบบอารมณรวมคือ ทักษะที่สําคัญของผูจัดการ
โครงการที่ดี
การวางแผนทรัพยากรมนุษยประกอบดวย การกําหนด การมอบหมาย และการบันทึกหนาที่
โครงการ ความรับผิดชอบ และสายการบังคับบัญชา เครื่องมือสําคัญสําหรับการกําหนดบทบาทและ
ความรับผิดชอบของโครงการคือ ผังการมอบหมายความรับผิดชอบ (RAM) แผนการบริหารพนักงาน และ
แผนภูมิแทงทรัพยากร
การไดทีมงานคือ การไดพนักงานที่เหมาะสมมาทํางานใหกบั โครงการ องคการตองใชวิธีใหม
เพื่อหาและรักษาพนักงานเทคโนโลยีสารสนเทศที่ดี

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารทรัพยากรมนุษย หนา 8-32

การบรรจุทรัพยากรแสดงปริมาณของทรัพยากรแตละอยางที่ตองการใชในชวงเวลาเฉพาะ
แผนภูมิแทงแสดงการบรรจุทรัพยากรและชี้ใหเห็นการใชทรัพยากรมากเกินไป สวนการจัดระดับทรัพยากร
คือ เทคนิคสําหรับการแกปญหาความขัดแยงทางทรัพยากรโดยการเลื่อนงาน ทรัพยากรที่ไดรับการจัด
ระดับตองไมมีการจัดการมาก คาใชจา ยต่าํ สรางปญหาทางบัญชีและบุคคลการนอย และทําใหจติ ใจดีขึ้น
ทักษะสําคัญ 2 อยางที่ผจู ัดการโครงการทีด่ ีตองมีคือ การพัฒนาทีม และการบริหารทีม การ
ทํางานเปนทีมชวยใหคนทํางานอยางมีประสิทธิผลมากขึน้ เพื่อบรรลุเปาหมายโครงการ ผูจ ัดการโครงการ
ควรแนะนําการอบรมใหแตละบุคคล เพื่อปรับปรุงทักษะที่เกีย่ วของกับการทํางานเปนทีม รวมทั้งจัดสมดุล
ของทีมงาน และจัดระบบการยอมรับและรางวัลที่กระตุน การทํางานเปนทีม ผูจัดการโครงการสามารถใช
เทคนิคและเครื่องมือหลายอยาง เชน การสังเกตและสนทนา การประเมินผลการดําเนินโครงการ การ
บริหารความขัดแยง และบันทึกประเด็น เพือ่ ชวยใหการบริหารทีมงานมีประสิทธิผล

คําถามทายบท
1. จงสรุปกระบวนการบริหารทรัพยากรมนุษย
2. จงอธิบายวางานของมาสโลว เฮอรเบอรก แมคคลีแลนด แมคเกรเกอร และโควีย เกีย่ วของกับการ
บริหารโครงการอยางไร
3. จงอธิบายความแตกตางของโครงสรางองคการของโครงการทั้ง 3 ประเภท
4. จงอธิบายลักษณะของโครงการแบบใดจึงเหมาะกับโครงสรางองคการของโครงการทั้ง 3 ประเภท
5. จงอธิบายความแตกตางระหวางการบรรจุทรัพยากรกับการจัดระดับทรัพยากร
6. จงอธิบายความสําคัญของการจัดสมดุลยของทีมงาน
7. จงอธิบายทักษะที่ผูจัดการโครงการตองมีเพื่อการบริหารทัพยากรมนุษย
8. จงอธิบายหลักเกณฑการเลือกสมาชิกทีมงาน
9. จากขอมูลที่กาํ หนดใหหาวาพนักงานคนใดควรทํางานอะไรจึงเสียคาใชจายนอยที่สดุ

กลุมกิจกรรม
1 2 3 4
สมชาย 6 0 0 2
มาลิสา 3 3 0 0
ภรณี 0 4 8 5
สุดา 5 0 3 0

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการสื่อสารโครงการ หนา 9-1

9.1 บทนํา
ผูเชี่ยวชาญหลายคนเห็นพองกันวา ภัยคุกคามทีย่ ิ่งใหญตอความสําเร็จของโครงการใดๆ
โดยเฉพาะโครงการเทคโนโลยีสารสนเทศคือ ความลมเหลวในการสื่อสาร จากการสํารวจของสแตนดิส
กรุปป 2001 พบวา ปจจัยที่มีความสัมพันธกับความสําเร็จของโครงการเทคโนโลยีสารสนเทศคือ การ
สนับสนุนของผูบริหารระดับสูง การมีสว นรวมของผูใช ประสบการณของผูจัดการโครงการ และความ
ชัดเจนของวัตถุประสงคเชิงธุรกิจ ปจจัยทั้งหมดจะสงผลใหโครงการประสบความสําเร็จหรือไมขึ้นอยูกับ
ผูจัดการโครงการและทีมงานมีทกั ษะการสื่อสารที่ดีหรือไม
งานดานเทคโนโลยีสารสนเทศมีการเปลี่ยนแปลงอยูตลอดเวลา และการเปลี่ยนแปลงเหลานี้
นํามาซึง่ ศัพทเทคนิคเปนจํานวนมาก เมื่อผูมีอาชีพดานคอมพิวเตอรตองสื่อสารกับผูที่ไมมีอาชีพดาน
คอมพิวเตอร ศัพทเทคนิคทําใหเกิดความยุงยากและซับสน ไมเวนแมแตคนในอาชีพเดียวกัน
ระบบการศึกษาสําหรับผูสาํ เร็จการศึกษาดานเทคโนโลยีสารสนเทศไดเนนการสงเสริมทักษะ
เชิงเทคนิคมากกวาทักษะเชิงสังคมและการสื่อสาร โปรแกรมที่สอนไมคอยมีวิชาดานการสื่อสาร (เชน
การพูด การเขียน และการฟง) จิตวิทยา สังคมวิทยา และมนุษยวิทยา คนชอบคิดวาเปนการงายทีจ่ ะ
สรางทักษะที่ไมใชเทคนิค แตแทที่จริงแลวมันเปนทักษะที่สําคัญ จากการศึกษาวิจยั จํานวนมากไดแสดง
วาผูมีอาชีพดานเทคโนโลยีสารสนเทศมีความจําเปนที่ตอ งมีทกั ษะทางดานสังคมศาสตร และการสื่อสาร
มากพอๆ กับทักษะทางดานเทคนิค
เปาหมายการบริหารการสื่อสารโครงการคือ เพื่อใหแนใจวาสารสนเทศของโครงการไดสราง
ขึ้นมาอยางเหมาะสม ทันสมัย ไดรวบรวม จัดเก็บ และไดแพรกระจายไปยังผูตองการใชถกู ตอง การ
บริหารการสื่อสารมี 4 กระบวนการคือ
• การวางแผนการสื่อสาร (communications planning) เปนการกําหนด
สารสนเทศ และการสื่อสารที่ผูมีสวนไดเสียตองการ นัน่ คือ ใครตองการสารสนเทศ
อะไร เมื่อไร จะใหสารสนเทศนั้นอยางไร
• การกระจายสารสนเทศ (information distribution) เปนการสงสารสนเทศที่
ตองการใหผมู สี วนไดเสียของโครงการทันเวลา

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการสื่อสารโครงการ หนา 9-2

• การรายงานผลการปฎิบตั ิงาน (performance reporting) เปนการรวบรวม และ

กระจายสารสนเทศการปฎิบัติงาน รวมทัง้ รายงานสถานภาพ การวัดความกาวหนา
และการคาดการณ
• การบริหารผูม ีสวนไดเสีย (managing stakeholder) เปนการบริหารการสื่อสาร
ใหตอบสนองความตองการ และความคาดหวังของผูมีสว นไดเสียของโครงการ

9.2 การวางแผนการสื่อสาร
เนื่องจากการสื่อสารเปนเรื่องที่สาํ คัญมากที่ทกุ โครงการควรมีการวางแผนการบริหารการ
สื่อสาร แผนนี้เปนเอกสารที่เสนอแนะการสื่อสารของโครงการ และเปนสวนหนึง่ ของแผนการบริหาร
โครงการโดยรวม แผนการบริหารการสื่อสารควรมีประเด็นดังนี้
• ความตองการการสื่อสารของผูมีสวนไดเสียของโครงการ
• สารสนเทศที่ตอ งการสื่อสาร รวมทัง้ รูปแบบ เนื้อหา และระดับของรายละเอียด
• ใครเปนผูรับสารสนเทศ และใครที่เปนผูผลิต
• วิธีการหรือเทคโนโลยีที่ควรใชเพื่อสงสารสนเทศ
• ความถี่ของการสื่อสาร
• ขั้นตอนสําหรับการแกไขประเด็นตางๆ
• ขั้นตอนการทบทวนสําหรับการปรับปรุงแผนการบริหารการสื่อสาร
• อภิธานศัพท

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

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการสื่อสารโครงการ หนา 9-3

ตารางที่ 9.1 ตัวอยางการวิเคราะหการสื่อสารสําหรับผูมีสวนไดเสียของโครงการ

(Schwalbe, 2007)
ผูมีสวนไดเสีย ชื่อเอกสาร รูปแบบเอกสาร บุคคลที่ติดตอ วันถึงกําหนด
ลูกคาที่เปนผูบริหาร
รายงานสถานภาพ กระดาษ ชนิดา หรือ ดวงตา วันแรกของเดือน
โครงการประจําเดือน
ลูกคาที่เปนพนักงาน รายงานสถานภาพ กระดาษ นฤมล หรือ แกวตา วันแรกของเดือน
ดานธุรกิจ โครงการประจําเดือน
ลูกคาที่เปนพนักงาน รายงานสถานภาพ อีเมล ธารทอง หรือ รัศมี วันแรกของเดือน
ดานเทคนิค โครงการประจําเดือน
ผูบริหารภายใน รายงานสถานภาพ กระดาษ วิมาดา วันแรกของเดือน
โครงการประจําเดือน
พนักงานภายในดาน รายงานสถานภาพ อินทราเน็ต เจษฎา วันแรกของเดือน
ธุรกิจและเทคนิค โครงการประจําเดือน
ผูรับชวงการอบรม แผนการอบรม กระดาษ สมยศ 11/1/2548
ผูรับชวงทาง แผนการทําให อีเมล กรรณิกา 6/1/2548
ซอฟตแวร ซอฟตแวรเกิดขึ้น

หลายๆ โครงการไมมีสารสนเทศเริ่มตนอยางเพียงพอในการสื่อสาร แตผูจัดการโครงการ

ผูบริหารระดับสูง และทีมงานชอบคิดเอาเองวาชองทางการสื่อสารที่มีอยูน นั้ เพียงพอที่จะถายทอด
สารสนเทศ ปญหาการใชชองทางการสือ่ สารที่มีอยูเดิมคือ ผูมีสวนไดเสียแตละกลุมมีความตองการ
สื่อสารแตกตางกัน การสรางแผนการบริหารการสื่อสาร และการทบทวนกับผูมีสว นไดเสียแตเนิน่ ๆ จะ
ชวยปองกันและลดปญหาการสื่อสารที่จะตามมา ถาองคการมีหลายโครงการ การพัฒนาการจัดการการ
สื่อสารใหสอดคลองกันจะชวยใหองคการทํางานไดราบรืน่ เนื่องจากหลายโครงการอาจมีผูมีสวนไดเสีย
บางคนเหมือนกัน การพัฒนาแผนการบริหารการสื่อสารที่ประสานกันจึงเปนสิง่ สําคัญ
การสื่อสารโครงการควรปรากฎในโครงสรางจําแนกงาน เพื่อใหแนใจวาการรายงานสาร
สนเทศที่สําคัญเปนงานทีท่ มี งานตองทําสงดวย ถาการรายงานสารสนเทศถูกกําหนดเปนกิจกรรมใน
โครงสรางจําแนกงาน มันจะทําใหการรายงานกลายเปนสิง่ สําคัญที่ทีมงานตองสรางความเขาใจให
ชัดเจนวาสารสนเทศอะไรของโครงการทีต่ องรายงาน เมื่อไร รายงานอยางไร และใครรับผิดชอบที่จะ
สรางรายงาน เปนตน

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการสื่อสารโครงการ หนา 9-4

9.3 การกระจายสารสนเทศ
การสงสารสนเทศของโครงการไปยังบุคคลที่ตองการในเวลาที่กําหนดและในรูปแบบที่มี
ประโยชนเปนสิ่งที่สาํ คัญพอๆ กับการพัฒนาสารสนเทศ นอกจากนี้ ผูจัดการโครงการและทีมงานตอง
ตัดสินใจวาใครรับสารสนเทศอะไร รวมทั้งตองตัดสินใจวา วิธกี ารใดเปนวิธกี ารสงสารสนเทศที่ดีทสี่ ุด ซึ่ง
คําตอบจะไดจากการตอบคําถามตอไปนี้
• เพียงพอหรือไมที่จะสงรายงานที่เปนเอกสาร
• การประชุมอยางเดียวเปนวิธกี ารกระจายสารสนเทศโครงการที่มปี ระสิทธิผลหรือไม
• การสื่อสารดวยการประชุม และดวยเอกสารเปนที่ตองการหรือไม
• วิธีการอะไรทีด่ ีที่สุดสําหรับการกระจายสารสนเทศ

หลังจากตอบคําถามเหลานี้ ผูจัดการโครงการ และทีมงานจะไดขอมูลสําหรับการตัดสินใจวิธที ี่ดี

ที่สุดเพื่อกระจายสารสนเทศ ในการพิจารณาการกระจายสารสนเทศควรตระหนักถึงการใชเทคโนโลยี
การสื่อสารแบบทางการและไมเปนทางการ และความซับซอนของการสื่อสาร

9.3.1 การใชเทคโนโลยีเพื่อเพิม่ การกระจายสารสนเทศ

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

9.3.2 วิธีการแบบทางการและไมเปนทางการสําหรับการกระจายสารสนเทศ
วิธีการสื่อสารมี 2 รูปแบบคือ การสื่อสารแบบทางการ (formal) และการสื่อสารแบบไม
เปนทางการ (informal) การสื่อสารแบบทางการอาจเปนการสื่อสารสารสนเทศในรูปแบบเอกสาร เชน
เอกสารขอกําหนดขอบเขตโครงการ เอกสารการออกแบบรายละเอียดของระบบงาน เปนตน หรืออาจ
เปนการประชุมที่มีการนัดหมายและมีวาระการประชุม สวนการสื่อสารอยางไมเปนทางการอยูในรูปของ
การสนทนา หรือประชุมกันโดยไมมวี าระการประชุม การสื่อสารแบบไมเปนทางการอาจอยูในรูปของ
เอกสารก็ไดแตเอกสารนัน้ ไมใชเอกสารทีเ่ ปนทางการ เชน โนต

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการสื่อสารโครงการ หนา 9-5

การที่สมาชิกทีมงานสงรายงานสถานภาพโครงการที่เปนเอกสารทางการใหกับผูจดั การ
โครงการและผูมีสวนไดเสียคนอื่นๆ โดยคิดเอาเองวาทุกๆ คนที่ตองการสารสนเทศจะอานรายงานนัน้
ความคิดดังกลาวเปนความคิดที่ไมถูกตองเสมอ การสื่อสารโดยการพูดเปนวิธีการที่มีประสิทธิผลพอๆ
กันกับการสื่อสารดวยเอกสาร แตนักวิชาชีพทางเทคนิคชอบละเลยวิธีที่ไมเปนทางการ คนที่ไมใชนัก
วิชาชีพทางเทคนิคอาจใชการสนทนาแลกเปลี่ยนสารสนเทศแทนการอานรายงานที่ละเอียด หรืออีเมล
หรือเว็บเพจ
แทนที่จะเนนการไดสารสนเทศโดยการอานเอกสารเชิงเทคนิค ผูรวมงานและผูบริหาร
ตองการรูจักบุคคลที่ทํางานใหกับโครงการ และพัฒนาความสัมพันธแบบเชื่อใจกับคนเหลานี้ โดยใชการ
อภิปรายแบบไมเปนทางการเกี่ยวกับโครงการ ผูเ ชี่ยวชาญหลายคนเชื่อวาความแตกตางระหวาง
ผูจัดการที่ดีกบั ผูจัดการโครงการที่ยอดเยีย่ มคือ ความสามารถในการรักษาความสัมพันธ และใชทักษะ
การฟงอยางตัง้ ใจ
การกระจายสารสนเทศอยางมีประสิทธิผลขึ้นกับผูจัดการโครงการและสมาชิกในทีมที่มี
ทักษะการสื่อสารที่ดี การสื่อสารมีหลายมิติ เชน การเขียน การพูด และการฟง บุคคลในโครงการ
จําเปนตองใชทุกมิติในการปฏิบัติงานประจําวัน นอกจากนี้ แตละคนจะสนองตอบทางบวกกับประเภท
การสื่อสารที่แตกตางกัน เชน ผูอุปถัมภโครงการอาจตองการที่จะรับรูโดยการอภิปรายแบบไมเปน
ทางการที่จัดอาทิตยละครั้ง ผูอุปถัมภโครงการจะใหขอคิดเห็นเกี่ยวกับโครงการระหวางการสนทนาแบบ
ไมเปนทางการมากกวาการใหขอคิดเห็นผานการสื่อสารรูปแบบอื่น การพบปะกันชวงสัน้ ๆ จะมี
ประสิทธิผลมากกวาการสื่อสารทางอิเลคทรอนิกส โดยเฉพาะสารสนเทศที่ออนไหว

9.3.3 การกระจายสารสนเทศทีส่ ําคัญใหมีประสิทธิผลและทันเวลา

รายงานที่เขียนหลายๆ ฉบับละเลยทีจ่ ะใหสารสนเทศทีส่ ําคัญ รายงานควรมีสารสนเทศ
เชิงเทคนิคที่ละเอียดที่จะกระทบตอการทํางานของลักษณะเฉพาะของผลิตภัณฑ หรือบริการที่องคการ
กําลังผลิต รวมทั้งยังควรบันทึกการเปลี่ยนแปลงรายละเอียดเชิงเทคนิคที่อาจมีผลกระทบการทํางานของ
ผลิตภัณฑ
คนมีแนวโนมที่จะไมรายงานขาวราย การสื่อสารดวยการพูดผานการประชุม และการ
พูดคุยอยางไมเปนทางการชวยใหสารสนเทศที่สาํ คัญทัง้ ทางบวกและลบเปดเผย การสื่อสารดวยการพูด
ยังชวยสรางความสัมพันธระหวางบุคลากรโครงการกับผูมีสวนไดเสียของโครงการใหเขมแข็งขึ้น คนชอบ
ปฏิสัมพันธเพือ่ ใหไดความรูส ึกที่แทจริงวาโครงการเปนอยางไร
เนื่องจากโครงการเทคโนโลยีสารสนเทศตองการการประสานงานมาก จะเปนการดีทจ่ี ะ
มีการประชุมสัน้ ๆ และบอยๆ เชน ผูจัดการโครงการบางโครงการตองการใหบุคลากรโครงการเขาประชุม
แบบยืนทุกอาทิตย หรือทุกเชา ขึน้ กับความตองการของโครงการ ประชุมแบบยืนจะไมมีเกาอี้ ดังนั้น จึง

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการสื่อสารโครงการ หนา 9-6

เปนการบังคับบุคลากรพบปะกันโดยเนนเฉพาะสารสนเทศที่ตองการสื่อสารจริงๆ ถาบุคลากรไมสามารถ
มาพบกันได คนเหลานี้จะสือ่ สารผานโทรศัพท อีเมล การสงขอความ หรือใชเทคโนโลยีอื่นๆ เพื่อสงเสริม
ใหมีการพบปะกัน ซึ่งเปนการสื่อสารแบบไมเปนทางการ

9.3.4 การเลือกสื่อการสื่อสารทีเ่ หมาะสม

สื่อที่ใชในการสื่อสารมีหลายประเภท เชน กระดาษ โทรศัพท ไปรษณียเสียง อีเมล การ
ประชุม เว็บไซต ตารางที่ 9.2 แสดงใหเห็นวาสื่อประเภทตางๆ เหมาะกับความตองการการสื่อสารที่
แตกตางกัน เชน ถาเราตองการประเมินคํามัน่ ของผูมีสวนไดเสียโครงการ การประชุมอาจเปนสื่อที่
เหมาะสมที่สดุ หรือการโทรศัพทเปนสื่อที่เหมาะสมรองลงมา สวนสื่ออื่นๆ ไมควรใช ดังนัน้ ผูจัดการ
โครงการตองประเมินความตองการขององคการ โครงการ และแตละบุคคล เพื่อกําหนดสื่อการสือ่ สารที่
จะใชและเมื่อไร

ตารางที่ 9.2 การเลือกสื่อสําหรับการสือ่ สาร (Schwalbe, 2007)

ไปรษณีย
เหตุการณ เอกสาร โทรศัพท อีเมล ประชุม เว็บไซต
เสียง
การประเมินคํามั่น 3 2 3 3 1 3
การสรางเอกฉันท 3 2 3 3 1 3
การไกลเกลี่ยความขัดแยง 3 2 3 3 1 3
การแกไขความเขาใจผิด 3 1 3 3 2 3
การกําหนดพฤติกรรมเชิงลบ 3 2 3 2 1 3
การแสดงความสนับสนุนหรือชื่นชม 1 2 2 1 2 3
การสงเสริมการคิดสรางสรรค 2 3 3 1 3 3
การสรางขอกําหนดใหหนักแนน 3 2 2 3 1 3
การสงเอกสารอางอิง 1 3 3 3 3 1
การเสริมอํานาจของบุคคล 1 2 3 3 1 2
การบันทึกถาวร 1 3 3 1 3 1
การคงความลับ 2 1 2 3 1 3
การสงสารสนเทศธรรมดา 3 2 1 1 2 3
การสรางคําขอธรรมดา 3 3 1 1 3 3
การใหคําสั่งที่ซับซอน 3 3 3 2 1 2
1 = เหมาะสมมากที่สุด 2 = ปานกลาง 3 = ไมเหมาะสม

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการสื่อสารโครงการ หนา 9-7

9.3.5 ความตองการการสื่อสารแบบสวนบุคคลและแบบกลุม
เรื่องที่สําคัญมากเรื่องหนึ่งของการกระจายสารสนเทศคือ ผูจัดการโครงการและทีมงาน
ควรเขาใจความตองการการสื่อสารของแตละคน คนมีบุคลิกเฉพาะที่แตกตางกัน ซึง่ จะกระทบ
ความชอบที่แตกตางกัน เชน ถาทานตองการยกยองสมาชิกทีมงานทํางานดี สมาชิกคนนัน้ เปนคนไม
ชอบสังสรรค ทานควรยกยองสมาชิกคนนั้นเปนการสวนตัว แตถา สมาชิกเปนคนชอบสมาคม ทานควร
ใหคนอื่นๆ ไดทราบการทํางานที่ดีของสมาชิกคนนัน้ คนที่รับรูโดยสัญชาตญาณตองการความเขาใจวา
สิ่งตางๆ นัน้ สอดคลองกับภาพใหญอยางไร ขณะที่คนที่ใชเหตุผลจะชอบรายละเอียดอยางเปนขั้นเปน
ตอน นักคิดอาจตองการรูเหตุผลที่มาทีไ่ ปที่ซอนในสารสนเทศ สวนคนที่ใชความรูสึกตองการรูวา
สารสนเทศกระทบเขา และคนอื่นๆ อยางไร
เปนเรื่องที่คอนยากที่ผูรับขอความจะแปลไดตรงกับที่ผสู งตั้งใจจริงๆ ดังนัน้ จึงเปนสิ่ง
สําคัญที่โครงการตองจัดหาวิธีการสื่อสารหลายๆ วิธี และสภาพแวดลอมที่สงเสริมใหมีการพูดคุยอยาง
เปดเผย คนทีม่ ีอาชีพทางดานเทคโนโลยีสารสนเทศมีบคุ ลิกภาพเฉพาะที่ตา งจากคนทัว่ ไป เชน เปนคน
ไมชอบสังคม ใชสัญชาตญาณ เนนการคิด บุคลิกภาพที่แตกตางนีส้ ามารถนํามาซึ่งการสื่อสารที่ผิดกับ
คนที่ชอบสังคม และใชความรูสึก เชน การเขียนแนะนําการใชระบบสําหรับผูใชโดยบุคคลทางดาน
เทคโนโลยีสารสนเทศอาจไมใหขั้นตอนที่ละเอียดที่ผูใชตอ งการ ผูใชหลายๆ คนชอบการประชุมแบบพบ
หนา เพื่อเรียนรูวาจะใชระบบใหมอยางไร แทนที่จะพยายามทําตามคําแนะนําผูใชทเี่ ขียนไมชัดเจน
สถานทีท่ างภูมิศาสตรและภูมิหลังทางวัฒนธรรมกระทบตอการสื่อสารโครงการ ถาผูมี
สวนไดเสียอยูใ นประเทศตางๆ จะเปนการยากหรือเปนไปไมไดที่จะจัดตารางเวลาการสื่อสารสองทาง
ระหวางชัว่ โมงการทํางานปกติ ภาษาเปนสาเหตุทาํ ใหเกิดปญหาการสื่อสาร คําเหมือนกันอาจมี
ความหมายทีต่ างกันในภาษาที่ตา งกัน คนทีม่ าจากวัฒนธรรมหนึง่ จะชอบวิธีการสื่อสารที่ไมสะดวก
สําหรับคนอืน่ เชน ผูจัดการในบางประเทศยังไมยนิ ยอมใหคนงานที่ตาํ แหนงต่าํ กวา หรือผูห ญิงที่จะ
นําเสนองานอยางเปนทางการ เปนตน

9.3.6 กําหนดทีส่ ําหรับการสื่อสารขาวราย

สิ่งสําคัญอีกประการหนึ่งของการสื่อสารคือ การสื่อสารขาวที่ไมดี หรือขาวรายของ
โครงการ เนื่องจากในบางครั้งสมาชิกอาจไมกลาทีจ่ ะบอกขาวรายดวยตนเอง การที่โครงการจัดหาที่
สําหรับใหขา วสารดานลบก็จะเปนประโยชน เชน มีกระดานติดขาว หรือมีเว็บสําหรับลงขาวทีไ่ มดีตอ
โครงการ เปนตน

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการสื่อสารโครงการ หนา 9-8

9.3.7 การกําหนดจํานวนชองทางการสื่อสาร
การกระจายสารสนเทศตองคํานึงถึงจํานวนคนที่ตองสื่อสาร ถาจํานวนคนที่เขามามี
สวนเกี่ยวของกับโครงการมีจํานวนเพิ่มขึน้ การสื่อสารจะเพิ่มความซับซอนมากขึ้น เพราะจํานวนเสนทาง
การสื่อสารไปยังบุคคลตางๆ จะเพิม่ ขึ้นดวย สูตรในการคํานวณชองทางการสื่อสารอยางงายๆ คือ

จํานวนชองทางการสื่อสาร = n(n-1)/2
โดยที่ n คือ จํานวนคนที่เกี่ยวของกับโครงการ

จากรูปที่ 9.1 แสดงตัวอยางผลกระทบของจํานวนคนตอชองทางการสื่อสาร สมมุติวา

ถาโครงการมีคนเกี่ยวของ 2 คน จํานวนชองทางการสือ่ สารจะมีเพียง 1 ชองทาง (2 (2-1)/2 = 1) ถามี
คนเพิ่มขึน้ เปน 3 คน จํานวนชองทางการสื่อสารจะเปน 3 ชองทาง (3(3-1)/2 = 3) แตถาคนเพิ่มเปน 4
คน จํานวนชองทางจะเพิม่ ขึ้นเปน 6 ชองทาง (4(4-1)/2 = 6) เราจะเห็นวา ถาจํานวนคนในโครงการเกิน
3 คน จํานวนชองทางจะเพิ่มอยางรวดเร็ว ผูจัดการโครงการควรจํากัดขนาดของทีมงาน เพื่อหลีกเลี่ยง
ความซับซอนของการสื่อสาร

รูปที่ 9.1 ผลกระทบของจํานวนคนตอชองทางการสื่อสาร (Schwalbe, 2007)

ผูสื่อสารที่ดีควรพิจารณาปจจัยตางๆ กอนตัดสินใจวาจะกระจายสารสนเทศอยางไร
รวมทัง้ ขนาดของกลุม ประเภทของสารสนเทศ และสือ่ สําหรับการสื่อสารที่เหมาะสม คนทัว่ ไปนิยมใช
อีเมลมาก เพราะใชงา ย คาใชจายในการสงสารสนเทศไปยังคนจํานวนมากไมแพง การสื่อสารที่ไมดีจะ
เพิ่มความเปนไปไดที่ทําใหเกิดขอผิดพลาดสูง โครงการขนาดใหญมสี ารสนเทศที่เคลื่อนไหวจํานวนมาก
ซึ่งทําใหการสือ่ สารเสียหายไดงาย การสื่อสารจึงเปรียบเสมือนน้ํามันหลอลื่นที่ทาํ ใหทุกอยางทํางาน
ดวยกันอยางเหมาะสม

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการสื่อสารโครงการ หนา 9-9

อยางไรก็ตาม มีสถานการณที่เราไมสามารถประชุมพบหนากันได เราตองสงอีเมลให

กลุมคนกลุม ใหญ เชน โครงการเสมือน (virtual project) ผูมีอาชีพดานเทคโนโลยีสารสนเทศที่ทาํ งานบน
โครงการเสมือน ไมคอยมีโอกาสพบหนาผูส นับสนุนโครงการ หรือสมาชิกคนอื่นๆ หรือผูมีสวนไดเสียของ
โครงการ ในสภาพแวดลอมแบบโครงการเสมือน ผูจัดการโครงการจําเปนอยางยิง่ ที่จะตองพัฒนา
วิธีการสื่อสารใหชัดเจน ซึง่ อาจใชอีเมล การสงขอความผานเว็บไซตของโครงการ หรืออาจใชการ
โทรศัพท แตโดยทั่วไปแลวสมาชิกโครงการตองวางใจกับการสื่อสารแบบเขียน

9.4 การรายงานการปฏิบัติงาน
การรายงานการปฏิบัติงานเปนการแจงผูมสี วนไดเสียใหทราบถึงทรัพยากรทีก่ ําลังถูกใช
เพื่อใหบรรลุวตั ถุประสงคโครงการ รายงานการปฏิบัติงานตองใชขอมูลที่สําคัญคือ สารสนเทศเกี่ยวกับ
การปฏิบัติงานและการวัดผลการปฏิบัติงาน วันที่คาดวาจะเสร็จ การวัดและการควบคุมคุณภาพ
โครงการ แผนการบริหารโครงการ คําขอเปลี่ยนแปลงที่ไดรับอนุมัติ และผลงานที่สงมอบ การรายงาน
การปฏิบัติงานที่สาํ คัญคือ รายงานการปฏิบัติงานที่ไดดําเนินการไปแลว และการคาดการณสิ่งที่ตองทํา
ตอไป รายงานการปฏิบัติงานปกติจะมีการรายงานสถานภาพ หรือรายงานความกาวหนา
• รายงานสถานภาพ (status reports) จะอธิบายวา ณ เวลาหนึง่ โครงการอยู ณ จุดใด
ในแงของงาน เวลา และคาใชจาย เชน จนถึงวันนี้โครงการใชเงินไปเทาไร เวลาที่ใชใน
การทํางานหนึง่ ๆ งานทีก่ ําลังทําอยูจะทําเสร็จตามแผนหรือไม รายงานสถานภาพมี
หลายรูปแบบขึ้นอยูกับความตองการของผูมีสวนไดเสีย
• รายงานความกาวหนา (progress reports) อธิบายวา อะไรทีท่ ีมงานทําสําเร็จ ณ
ชวงเวลาหนึ่ง หลายๆ โครงการใหสมาชิกแตละคนเตรียมรายงานความกาวหนา
ประจําเดือน หรือประจําอาทิตย ผูน ําทีมจะรายงานความกาวจากสารสนเทศที่ไดจาก
รายงานความกาวหนาของสมาชิก

สวนการคาดการณเปนการทํานายสถานภาพและความกาวหนาในอนาคตของโครงการ โดย
ใชขอมูลในอดีต และแนวโนม เชน การคาดการณเวลา และเงินทีใ่ ชเพื่อใหโครงการเสร็จ ผูจดั การ
โครงการควรใชการบริหารมูลคาที่ไดรับ (earned value) ในการคาดการณดังกลาว
เทคนิคอืน่ ที่สาํ คัญสําหรับการรายงานการปฏิบัติงานคือ การประชุมทบทวนสถานภาพ การ
อภิปรายเกี่ยวกับประเด็นที่สาํ คัญแบบพบปะ ผูจัดการโครงการหลายโครงการใชการประชุมทบทวน
สถานภาพประจําเพื่อแลกเปลี่ยนขอมูลทีส่ ําคัญ และกระตุนใหพนักงานทํางานใหกา วหนา การประชุม

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการสื่อสารโครงการ หนา 9-10

แบบนี้บางทีก่ ลายเปนสนามตอสูเมื่อเกิดความขัดแยงระหวางกลุม ผูจัดการโครงการควรกําหนดกฎการ

ประชุมเพื่อควบคุมความขัดแยง และควรทํางานเพื่อแกปญหาที่อาจเกิดขึ้น

9.5 การบริหารผูมีสวนไดเสีย
ผูจัดการโครงการตองเขาใจและทํางานกับผูมีสวนไดเสียทีห่ ลากหลาย ดังนั้น ผูจัดการ
โครงการควรเนนวาทําอยางไรจึงสามารถใชการสื่อสารเพื่อสนองตอบความตองการและความคาดหวัง
ของผูมีสวนไดเสีย นอกจากนี้ ผูจดั การโครงการจําเปนตองวางวิธกี ารเพื่อกําหนดและแกปญหา
เครื่องมือที่ชว ยไดคือ การใชผังบริหารความคาดหวัง (expectations management matrix) และบันทึก
ประเด็น (issue log)
ผังการบริหารความคาดหวังจะชวยใหความคาดหวังชัดเจน ผังนี้ประกอบดวยรายการตัววัด
ความสําเร็จพรอมลําดับ ความคาดหวัง และแนวทางการดําเนินการที่เกีย่ วกับตัววัดแตละตัว ดัง
ตัวอยางที่แสดงในตารางที่ 9.3 เราอาจเพิม่ ตัววัดความสําเร็จ เชน การบรรลุความคาดหวังดานคุณภาพ
การบรรลุระดับความพึงพอใจของลูกคา การทําไดตรงกับ ROI ทีค่ าดการณไวหลังจากโครงการเสร็จ
สมบูรณ

ตารางที่ 9.3 ตัวอยางผังบริหารความคาดหวัง (Schwalbe, 2007)

มาตรวัด ลําดับ ความคาดหวัง แนวทาง
ความสําเร็จ ความสําคัญ
ขอบเขต 2 ขอกําหนดขอบเขตความตองการที่ เนนที่ความตองการที่จําเปนตองมีกอน
จําเปนตองมีและความตองการที่ไม พิจารณาความตองการที่ไมจําเปน
จําเปนตองชัดเจน
เวลา 1 โครงการตองเสร็จสมบูรณในวันที่ ผูอุปถัมภโครงการและผูจัดการแผนงาน
กําหนด ทุกๆ งานที่สําคัญตองเสร็จ ตองไดรับแจง เมื่อมีประเด็นใดๆ ที่อาจ
ตามที่กําหนด และตารางเวลา กระทบตอเปาหมายตารางเวลา
สอดคลองกับความเปนจริง
คาใชจาย 3 โครงการนี้สําคัญตอองคการ ถาทาน มีกฎเขมงวดเกี่ยวกับคาใชจายโครงการ
สามารถใหเหตุผลความจําเปนถึง และมีขั้นตอนเพิ่มขึ้น คาใชจายเปนสิ่ง
ความตองการเงินเพิ่มไดอยางชัดเจน สําคัญมากๆ แตมันเปนสิ่งที่ทําให
ผูบริหารสามารถอนุมัติได ตารางเวลาตรงตามเวลาที่กําหนด
รวมทั้งเปาหมาย
อื่นๆ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการสื่อสารโครงการ หนา 9-11

เครื่องมืออีกตัวหนึ่งที่ชวยบริหารผูมีสว นไดเสียคือ บันทึกประเด็น (issue log) ประเด็นคือ

เนื้อหาสาระ (matter) ของคําถามหรือขอโตเถียงที่อาจขัดขวางความสําเร็จของโครงการ บันทึกประเด็น
คือ เครื่องมือสําหรับบันทึกและติดตามการแกไขประเด็นของโครงการ ตารางที่ 9.4 ไดแสดงบันทึก
ประเด็นที่ผูจัดการโครงการอาจนําไปใชได ในบันทึกประเด็นประกอบดวย เลขที่ประเด็น รายละเอียด
ของประเด็น ผลกระทบของประเด็นนัน้ ตอโครงการ วันทีร่ ายงานประเด็น ผูรายงาน ผูไดรับมอบหมายให
แกไข ลําดับความสําคัญของประเด็น วันที่กาํ หนดใหรายงานกลับ ความคิดเห็นที่เกี่ยวกับประเด็น
ผูจัดการโครงการควรแกประเด็นตางๆ ใหเร็วที่สดุ เทาที่จะเร็วได กิจกรรมของโครงการจึงสามารถ
เดินหนาไปได สิ่งที่สาํ คัญอีกประการหนึง่ คือ ผูจัดการโครงการตองไมจมปลักอยูก บั ประเด็นมากเกินไป
ผูจัดการโครงการบางคนอาจเลือกไมบนั ทึกประเด็นที่มีความสําคัญต่ํา หรือประเด็นเล็กๆ ที่สามารถ
แกไขไดโดยไมตองบันทึกไว
ความเขาใจความคาดหวังของผูมีสวนไดเสียสามารถชวยการบริหารประเด็น เนื่องจาก
ประเด็นใดที่เกี่ยวของกับความคาดหวัง ประเด็นนัน้ ควรไดรับความสนใจเปนพิเศษจากผูจัดการโครงการ
อยางไรก็ตาม ประเด็นที่ไมไดรับการแกไขสามารถกลายเปนแหลงของความขัดแยง

ตารางที่ 9.4 ตัวอยางบันทึกประเด็น (Schwalbe, 2007)

ประ คําอธิบาย ผลกระทบ วันที่ ผูรายงาน ผูรับ ลําดับ วันที่ถงึ สถาน หมายเหตุ
เด็นที่ ประเด็น ตอโครงการ รายงาน มอบหมาย ความ กําหนด ภาพ
สําคัญ
1 คาใชจาย คาใขจาย 10 มิย สถาพร ทวีศักดิ์ ปาน 30 มิย. ปด ผูอุปถัมภโครงการ
เครื่องบริการ โครงการ กลาง ตกลงที่จะเพิ่มเงิน
เพิ่มขึ้นจากที่ เพิ่มขึ้น เพื่อใหโครงการ
วางแผน 10% เล็กนอย เสร็จตามกําหนด
2 สมาชิก 2 คน จําเปนตอง 25 กค. เจนตา ปยะวัฒน สูง 31 กค. เปด ถาปยะวัฒนไม
ลาออกจาก มอบหมาย สามารถมอบหมาย
โครงการ พนักงานใหม พนักงานใหมได
ภายใน 1 อาทิตย
เขาควรคุยกับทนง
ศักดิ์โดยตรง
อื่นๆ

9.6 ขอเสนอแนะสําหรับการปรับปรุงการสื่อสารโครงการใหดีขึ้น
ดังที่ไดทราบกันดีแลววา การสื่อสารที่ดีมีความสําคัญตอการบริหารและความสําเร็จของ
โครงการเทคโนโลยีสารสนเทศ การบริการสื่อสารเปนการทําใหแนใจวา 1) สารสนเทศที่จําเปนสงไปยัง
คนที่ควรไดในเวลาที่ตองการ 2) ไดรายงานและขอมูลยอนกลับเหมาะสม และมีประโยชน 3) มี

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการสื่อสารโครงการ หนา 9-12

กระบวนการบริหารที่เปนทางการในการบริหารผูมีสวนไดเสียของโครงการ ในสวนนี้จะใหขอเสนอแนะ
สําหรับการทําใหการสื่อสารดีขึ้น ซึ่งประกอบดวย แนวทางการบริหารความขัดแยง การพัฒนาทักษะ
การสื่อสารใหดีขึ้น การจัดการประชุมใหมีประสิทธิผล การใชอีเมลใหมีประสิทธิผล การใชแมแบบ
สําหรับการสื่อสารโครงการ และการพัฒนาโครงสรางการสื่อสาร

9.6.1 การใชทักษะการสื่อสารเพื่อการบริหารความขัดแยง
โครงการเทคโนโลยีสารสนเทศขนาดใหญตองใชความพยายามสูง ราคาแพง ตองการ
ทรัพยากรมาก และมีผลกระทบอยางรุนแรงตอวิธีการทํางานของคนในองคการ เมื่อมีผูมีสวนไดเสียมาก
โครงการยอมหนีความขัดแยงไมได เมื่อโอกาสความขัดแยงสูง การสื่อสารที่ดีเปนสิ่งจําเปน
ความขัดแยงที่มีมากที่สุดจะเกี่ยวกับตารางเวลาของโครงการ สวนความขัดแยงอื่น
ประกอบดวย การกําหนดคนทํางาน ประเด็นทางเทคนิค วิธีการจัดการ บุคลิกลักษณะ และคาใชจาย
ผูจัดการโครงการจําเปนตองพัฒนาและใชทรัพยากรบุคคลและทักษะการสื่อสาร เพื่อชวยกําหนดและ
บริหารความขัดแยงของโครงการ ผูจดั การโครงการควรชี้นําทีมงานของตนในการพัฒนาบรรทัดฐาน
สําหรับการจัดการความขัดแยงตางๆ ที่อาจเกิดขึ้นกับโครงการ เชน ทีมงานควรรูวาพฤติกรรมที่ไมให
ความเคารพตอผูมีสวนไดเสียเปนพฤติกรรมที่ไมเหมาะสม หรือสมาชิกของทีมงานไดรับการคาดหวังวา
ตองพยายามแกไขความขัดแยงเล็กๆ ดวยตนเองกอนทีจ่ ะสงไประดับที่สูง เบลกค และ เมาตัน (Blake
และ Mouton (1964)) ไดกําหนดวิธี พื้นฐานในการจัดการความขัดแยงดังนี้
• การเผชิญหนา (confrontation) ผูจัดการโครงการใชวิธีการเผชิญหนาหรือ
วิธีการการแกปญหา (problem solving approach) เมื่อพบกับความขัดแยง
ในกรณีที่มีความคิดเห็นแตกตางกัน โดยใหกลุมคนที่ไดรับผลกระทบทํางาน
ดวยกันเพื่อหาวิธีการที่ดีที่สดุ ในการแกความขัดแยง จากการวิจัยพบวา
ผูจัดการโครงการชอบวิธกี ารเผชิญหนาเพือ่ แกไขความขัดแยงมากที่สดุ
• การประนีประนอม (compromise) วิธกี ารนี้ ผูจัดการโครงการใชการใหและ
การรับ (give and take approach) เพือ่ การแกความขัดแยง โดยการตอรอง
และคนหาคําตอบที่จะนํามาซึ่งความพอใจของทุกฝายที่โตเถียง คูกรณีแตละ
ฝายตางก็ไดประโยชน และตองเสียประโยชนบา ง มิใชฝายหนึง่ ไดหรือเสียแต
ฝายเดียว
• การไกลเกลี่ย (smoothing) ผูจัดการโครงการลดความสําคัญ หรือหลีกเลี่ยง
ความแตกตาง แตใหความสําคัญกับสวนทีท่ ุกฝายเห็นตรงกัน

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการสื่อสารโครงการ หนา 9-13

• การบังคับ (forcing) เปนวิธกี ารที่เหมือนกับวิธีการชนะ-แพ (win-lose

approach) ผูจัดการโครงการใชอํานาจที่เปนทางการของตนจัดการกับความ
ขัดแยง โดยอาศัยกฎเกณฑและระเบียบตางๆ
• การถอนตัว (withdrawal) ผูจัดการโครงการลาถอย หรือถอนจากความขัดแยง
เปนวิธีการที่เหมาะสมนอยที่สุดในการจัดการความขัดแยง

ผูจัดการโครงการควรรูวา ความขัดแยงไมใชสิ่งเลวรายทัง้ หมด ในความจริงแลว ความ

ขัดแยงอาจเปนเรื่องดี ความขัดแยงสรางผลลัพธที่สาํ คัญ เชน ความคิดใหม ทางเลือกที่ดีขึ้น และการ
กระตุนใหทํางานหนักขึ้น แตความขัดแยงเชิงอารมณอนั มีผลจากบุคลิกภาพไมตรงกัน และความเขาใจ
ผิด จะทําใหประสิทธิภาพการทํางานต่าํ ลง ผูจ ัดการโครงการควรสรางสภาพแวดลอมที่สงเสริม และ
รักษาความขัดแยงที่เปนบวก

9.6.2 การพัฒนาทักษะการสื่อสารใหดีขนึ้
บางคนเกิดมามีทักษะการสื่อสารที่ดี บางคนมีทกั ษะทางดานเทคนิค เปนการยากทีจ่ ะ
หาคนที่มที ักษะทั้งสองอยาง คนที่มีอาชีพทางดานเทคโนโลยีสารสนเทศที่มที ักษะทางดานการสื่อสารจะ
ทําใหกาวหนาในอาชีพ โดยเฉพาะถาตองการเปนผูจ ัดการโครงการที่ดี
องคการสวนใหญใชเงินจํานวนมากในการฝกอบรมทางดานเทคนิคใหกับพนักงานของ
องคการ พนักงานแตละคนสนใจที่จะเขาเรียนวิชาที่เปนเทคโนโลยีทที่ ันสมัยมากกวาวิชาที่พฒ
ั นาทักษะ
ทางดานการสือ่ สาร การอบรมทักษะทางดานการสื่อสารมีกิจกรรมการแสดงบทบาท (role-playing)
ระหวางการอบรมผูเขารวมมีโอกาสไดสรางทักษะเฉพาะในกลุมเล็กๆ การอบรมจะบันทึกการนําเสนอ
ของผูเขารวมเปนดิวทิ ัศน เพื่อนํามาเปดใหเจาตัวไดดู การลงทุนการฝกอบรมและการนําเสนอจะให
ผลตอบแทนอยางมากมายตอบุคคลนั้น ตอโครงการ และตอองคการ ทักษะเหลานีจ้ ะอยูอยางยาวนาน
มากกวาทักษะทางเทคนิคหลายอยาง
ขณะที่องคการไดกลายเปนองคการระดับโลก องคการตองลงทุนในดานการปรับปรุง
การสื่อสารกับคนจากตางประเทศ และตางวัฒนธรรม การไมเขาใจวาจะสื่อสารอยางไรใหมีประสิทธิผล
กับคนทีม่ ีวัฒนธรรมและภูมหิ ลังตางกันสามารถทํารายโครงการและธุรกิจได มีการอบรมหลายวิชาที่
อบรมเกี่ยวกับใหการตระหนักทางวัฒนธรรม ธุรกิจระดับนานาชาติของตนเอง และการสรางทีมงาน
ระดับนานาชาติ
ถาผูจัดการโครงการยอมใหพนักงานนําเสนองานไมดี เขียนรายงานเลอะเทอะ ตอตาน
คนที่มาจากตางวัฒนธรรม หรือประพฤติไมดีในการประชุม พนักงานจะไมยอมรับการปรับปรุงทักษะ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการสื่อสารโครงการ หนา 9-14

การสื่อสารของตนเอง ดังนัน้ องคการที่ประสบความสําเร็จจะใหเวลากับการเตรียมรางรายงานและการ

นําเสนอ และใหความคิดเห็นกับรางนัน้ นอกจากนี้ การใหเวลาสําหรับการประชุมที่ไมเปนทางการกับ
ลูกคาจะเปนวิธีการปฏิบัติทดี่ ี เพื่อชวยพัฒนาความสัมพันธ การปรับปรุงการสื่อสารใหดีขึ้นสามารถทํา
ไดดวยการวางแผนที่เหมาะสม ความเปนผูนําจากผูบริหารระดับสูง

9.6.3 การจัดการประชุมใหมปี ระสิทธิผล

การจัดประชุมไมดีสามารถมีผลกระทบที่เสียหายแกโครงการ เชน การประชุมเปด
โครงการ (kickoff meeting) ที่แยมากๆ อาจเปนสาเหตุใหผูมีสวนไดเสียที่สาํ คัญตัดสินใจไมสนับสนุน
โครงการตอไป หลายๆ คนบนวา เสียเวลาไปโดยไมจําเปน เนื่องจากการประชุมที่วางแผนไมดี หรือ
จัดการประชุมไมกระชับ ตอไปนี้คือแนวทางที่จะชวยใหเวลาที่ใชในการประชุมดีขึ้น
• หลีกเลี่ยงการประชุม ผูจดั การโครงการไมควรใชการประชุม ถาผูจัดการ
โครงการมีวิธกี ารอื่นที่สามารถทําใหบรรลุวัตถุประสงคได เชน ผูจัดการ
โครงการรูวา การจางคนตองไดรับการอนุมตั ิจากผูบริหารระดับสูง ซึง่ อาจใช
เวลาเปนอาทิตย หรือมากกวานัน้ เพื่อที่จะนัดเวลาประชุมที่ใชเวลาเพียงสิบ
นาที แตเนื่องจากเปนการจางที่จาํ เปนเรงดวน ผูจัดการโครงการอาจใช
โทรศัพทอธิบายสถานการณ และตัดสินใจในคําขอจางพนักงาน ซึ่งจะเร็วและ
มีประสิทธิผลกวาการประชุม
• กําหนดวัตถุประสงคและผลที่ตองการไดจากการประชุม ในการประชุมควร
ระบุใหชัดเจนวา ผลลัพธจากการประชุมคืออะไร กําหนดวัตถุประสงคให
ชัดเจนสําหรับผูเขารวมประชุม เพราะไมเชนนัน้ ทุกคนจะคิดแตเรื่องของตนเอง
• กําหนดผูท ี่ควรเขาประชุม การประชุมจะมีประสิทธิผลที่สุดถาจํานวนคน
ผูเขารวมนอยที่สุด โดยเฉพาะถาตองตัดสินใจ แตการประชุมแบบอื่นอาจตอง
มีผูเขารวมจํานวนมาก ดังนัน้ จึงเปนสิง่ จําเปนที่ตองกําหนดวาใครควรเขารวม
ประชุมโดยพิจารณาจากวัตถุประสงค และสิ่งที่อยากไดจากการประชุม
• สงระเบียบวาระการประชุมใหกับผูเขาประชุมรวมลวงหนา การประชุมจะ
ไดผลมากที่สดุ ถาผูเขารวมประชุมไดเตรียมตัว โดยการอานรายงาน รวบรวม
ขอมูล พวกมืออาชีพบางคนปฏิเสธการเขารวมประชุมถาไมไดรับระเบียบวาระ
การประชุมลวงหนา ความตองการระเบียบวาระการประชุมบังคับใหผูจัดการ
ประชุมตองวางแผนการประชุม และใหผทู ี่จะเขารวมประชุมมีโอกาสตัดสินใจ
วาตองการเขาประชุมจริงๆ หรือไม

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการสื่อสารโครงการ หนา 9-15

• เตรียมเอกสารประกอบการประชุม อุปกรณ และอื่นๆ ลวงหนา การจัดทํา

เอกสารประกอบการประชุมทําใหผูจัดการประชุมจัดการความคิดตางๆ ของ
ตนเอง ซึง่ จะชวยการประชุมมีประสิทธิผลมากขึ้น นอกจากนี้ผูจัดการประชุม
จําเปนที่จะตองจัดเตรียมหองประชุม อุปกรณที่จําเปน อาหาร และเครื่องดื่ม
• จัดการประชุมอยางมืออาชีพ ในการจัดประชุม ผูจัดประชุมควรมีการแนะนํา
คน รวมทั้งกลาวถึงวัตถุประสงคการประชุม และกฎทีผ่ ูเขาประชุมตองปฏิบัติ
ผูจัดการโครงการควรเตรียมคนสําหรับควบคุมเวลา สงเสริมใหเกิดการมีสวน
รวม สรุปประเด็นสําคัญ และทําใหเกิดการตัดสินใจที่ชดั เจน รวมทัง้ มอบหมาย
ใหคนใดคนหนึ่งจดรายงานการประชุม และสงรายงานการประชุมใหเร็วที่สุด
รายงานการประชุมควรสั้นและเนนประเด็นการตัดสินใจ และการกระทําที่
สําคัญที่ไดจากการประชุม
• สรางความสัมพันธ การสรางความสัมพันธระหวางผูเขารวมประชุมขึ้นกับ
วัฒนธรรมขององคการ

9.6.4 การใชอีเมลใหมีประสิทธิผล
เนื่องจากคนสวนมากใชอีเมล แตไมใชวาอีเมลจะชวยใหการสื่อสารดีขึ้น อีเมลไมใชสื่อ
ที่เหมาะสําหรับการสื่อสารหลายๆ อยาง ในตารางที่ 9.2 ไดแสดงใหเห็นวา อีเมลไมเหมาะกับการ
ประเมินคํามั่น การสรางเอกฉันท การไกลเกลี่ยความขัดแยง การแกไขความเขาใจผิด การสรางขอ
กําหนดใหหนักแนน การเสริมอํานาจของคน หรือการคงความลับ
ถึงแมวา คนจะรูวาเมื่อไรจึงจะใชอีเมลสําหรับการสื่อสาร แตผูใชไมตระหนักถึง
ความสามารถใหมๆ ของอีเมล และไมไดรับการอบรมวาจะใชความสามารถใหมเหลานี้ไดอยางไร เชน
การใชสมุดที่อยู การสรางชุดผูรับอีเมล การจัดเรียงอีเมล การคนหาขอความ การใชซอฟตแวรเพื่อ
ปองกันการสงขอความอิเลคทรอนิกสท่ไี รสาระ การสงตอขอความไปยังบุคคลอื่น เปนตน
นอกจากการใชฟงกชันตางๆ แลว เราก็ยังตองรูวาควรจะใชถอยคําอะไร จึงจะทําใหเกิด
ความชัดเจน เชน ชื่อเรื่อง ควรเขียนใหชัดเจนและสื่อถึงเนื้อหาในอีเมล การเขียนไมชดั เจนอาจทําใหเกิด
ความเขาใจผิด หรือสับสน ผูรับอาจลบทิง้ โดยไมอาน
ระบบอีเมลควรปองกันอีเมลโฆษณา หรือขอความอิเลคทรอนิกสที่ไรสาระ แตผูใชนอ ย
คนจะรูวิธกี ารทํา ผูจ ัดการโครงการสามารถชวยใหผูมีสว นไดเสียของโครงการใชอีเมลไดอยางมี
ประสิทธิผล และไมเสียเวลากับอีเมลที่ไมตอ งการ ตอไปนี้คือ แนวทางการใชอีเมลใหมีประสิทธิผล

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการสื่อสารโครงการ หนา 9-16

• สารสนเทศที่ถกู สงทางอีเมลควรเหมาะกับสื่อประเภทนี้ ถาสามารถสื่อสาร

สารสนเทศดวยการโทรศัพท หรือการประชุม ใหใชวิธีเหลานัน้
• ใหแนใจวาสงอีเมลไปยังคนที่ตองการ ไมควรใชการสงถึงทุกคนอยางอัตโนมัติ
• ใชชื่อเรื่องใหมคี วามหมาย ผูอานสามารถรูว าอีเมลมีเนื้อหาอะไรไดอยาง
รวดเร็ว ไมควรตอบกลับอีเมลอยางตอเนือ่ ง โดยไมเปลีย่ นชื่อเรื่อง
• จํากัดเนื้อหาของอีเมลไวเรื่องเดียว ถามีเรือ่ งที่แตกตางกันใหสง อีเมลใหม
• เนื้อหาของอีเมลควรชัดเจนและกระชับ ควรอานอีเมลอกี ครั้งกอนสงออก ตรวจ
คําสะกดโดยการใชฟงกชันตรวจคําสะกด ถาตองตอบคําถามหลายขอ ควรใส
ตัวเลขหนาคําตอบ
• จํากัดจํานวนและขนาดของเอกสารแนบ แตถาเปนเอกสารขนาดใหญใหใช
การเชื่อมโยงไปยังเอกสารแทนการแนบไฟล
• ใหลบอีเมลที่ไมจําเปนตองเก็บหรือตอบกลับ ไมเปดอีเมลที่ไมสําคัญ ใช
ความสามารถของซอฟตแวรในการกัน้ ขอความเพื่อปองกันเมลที่เปนขยะ
• ใหแนใจวาซอฟตแวรปองกันไวรัสไดรับการปรับปรุงใหทันสมัย ไมเปดไฟลที่
แนบมา ถาไมรูแหลงที่มา
• ตอบกลับอีเมลอยางรวดเร็ว ถาเปนไปได
• ถาตองการเก็บอีเมล ใหสรางโฟลเดอร ตั้งชื่อใหมีความหมายสําหรับเก็บอีเมล
ที่ตองการ
• เรียนรูการใชความสามารถทีส่ ําคัญของซอฟตแวรอีเมล

9.6.5 การใชแมแบบสําหรับการสื่อสารโครงการ
เพื่อใหการทําการสื่อสารงายขึ้น ผูจ ัดการโครงการจําเปนตองมีตัวอยางและแมแบบ
สําหรับการสื่อสารที่รวมกัน เชน คําอธิบายโครงการ เอกสารสิทธิโ์ ครงการ รายงานการปฏิบัติงานราย
เดือน การนําเสนอรายงานสถานภาพ เอกสารที่ดจี ากโครงการในอดีตเปนแหลงตัวอยางที่ดี และชวยผูที่
ไมเคยเขียนหรือไมเคยนําเสนอโครงการมากอน ผูจัดการโครงการควรหาและพัฒนาตัวอยางและ
แมแบบ เพื่อใหมีการใชเอกสารและแมแบบรวมกัน ตัวอยางของเอกสารที่ควรมีแมแบบไดแก แฟมธุรกิจ
เอกสารสิทธิ์โครงการ ขอบเขตโครงการ การวิเคราะหผมู ีสวนไดเสีย โครงสรางจําแนกงาน แผนภูมิแกนต
และการประมาณคาใชจาย

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการสื่อสารโครงการ หนา 9-17

รูปที่ 9.2 ตัวอยางแมแบบสําหรับคําอธิบายโครงการ (Schwalbe, 2007)

รูปที่ 9.2 คือ ตัวอยางแมแบบสําหรับคําอธิบายโครงการยาว 1 หนากระดาษ

แบบฟอรมนี้สามารถใชแสดงขอมูลโดยสรุปทั้งหมดของโครงการ ซึ่งอาจนํามาใชในการประชุมรายงาน
ผูบริหารราย 3 เดือน คําอธิบายโครงการควรประกอบดวย วัตถุประสงคโครงการ ขอบเขต สมมุติฐาน
คาใชจาย และระยะเวลา รวมทัง้ ผลลัพธหลัก และหลักไมลของโครงการ ตารางที่ 9.5 เปนแมแบบ
สําหรับรายงานความกาวหนารายเดือน ในรายงานประกอบดวย งานที่ทาํ สําเร็จในเดือนนัน้ แผนสําหรับ
เดือนถัดไป ประเด็นที่สาํ คัญ และการเปลี่ยนแปลง

ตารางที่ 9.5 ตัวอยางแมแบบสําหรับรายงานความกาวหนารายเดือน (Schwalbe, 2007)

1. สิ่งที่ทําสําเร็จสําหรับเดือนมกราคม:
• อธิบายสิ่งที่ทําสําเร็จที่สําคัญที่สุด ใหสัมพันธกับแผนภูมิแกนตของโครงการ
• อธิบายสิ่งที่ทําเสร็จอื่นๆ ที่สําคัญ ถามีประเด็นใดไดรับการแกไขจากเดือนที่แลว ใหแสดงดวย
2 วางแผนสําหรับเดือนกุมภาพันธ:
• อธิบายหัวขอที่สําคัญที่สุดที่จะทําใหสําเร็จในเดือนถัดไป ใหสัมพันธกับแผนภูมิแกนตของโครงการ
• อธิบายหัวขออื่นๆ ที่สําคัญที่จะทําใหสําเร็จ
3 ประเด็น: แสดงประเด็นที่สําคัญที่พบหรือที่ยังคงสําคัญอยางสรุป
4. การเปลี่ยนโครงการ (คําอธิบายและวันที่): แสดงคํารองขอเปลี่ยนแปลงที่ไดรับอนุมัติ รวมทั้งวันที่เปลี่ยนแปลง
และคําอธิบายอยางสรุป

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการสื่อสารโครงการ หนา 9-18

เอกสารทัง้ หมดของโครงการจะประกอบดวยรายงานจํานวนมากดังนี้
• คําอธิบายโครงการ
• ขอเสนอ
• สัญญาที่ไดรับการแกไข และของเดิม และเอกสารการยอมรับของลูกคา
• แผนและตารางเวลาที่ไดแกไขรวมทั้งของเดิม (โครงสรางจําแนกงาน แผนภูมิ
แกนต และผังเครือขาย ประมาณการคาใชจาย แผนการบริหารการสือ่ สาร)
• เอกสารการออกแบบ
• รายงานโครงการฉบับสุดทาย
• สิ่งที่สง มอบ (deliverables)
• รายงานการตรวจสอบ (audit report)
• รายงานบทเรียนที่ไดเรียนรู
• สําเนารายงานสถานภาพทัง้ หมด รายงานการประชุม การแจงการ
เปลี่ยนแปลง และเอกสารที่เขียนขึ้น หรือเอกสารอิเล็กทรอนิกสอื่นๆ

ผูจัดการโครงการและสมาชิกทีมงานควรเตรียมรายงานบทเรียนที่ไดเรียนรูทงั้ หมด
รายงานบทเรียนที่ไดเรียนรูค ือ การบันทึกสิ่งสําคัญที่ไดจาการทํางานโครงการ สมาชิกทีมงานทุกคนตอง
เขียนบทเรียนที่ไดอยางสัน้ ๆ บางโครงการใหหวั หนาทีม หรือผูบริหารโครงการเขียนรายงานคนเดียว
รายงานเหลานี้เปนการสะทอนที่มีคา เพื่อใหรูวางานอะไรที่ทาํ จริง หรืองานอะไรที่ไมไดทํา เนื่องจากแต
ละคนเรียนรูดวยวิธีที่ตา งกัน และมีความเขาใจลึกซึ้งตางกัน ดังนัน้ การไดขอมูลมากกวาหนึง่ คนจะได
ประโยชนมากกวาขอมูลจากคนคนเดียว รายงานบทเรียนที่เรียนรูเปนแหลงขอมูลที่ดีเยี่ยมสําหรับ
โครงการในอนาคต
ผูจัดการโครงการจะรวบรวมสารสนเทศทัง้ หมดที่ไดจากรายงานบทเรียนที่เรียนรูมาทํา
เปนรายงานสรุปของโครงการ หัวขอที่ไดอภิปรายในรายงานบทเรียนที่ไดเรียนรูจะสะทอนวาเปาหมาย
ของโครงการบรรลุหรือไม โครงการประสบความสําเร็จหรือไม สาเหตุของความแปรปรวนของโครงการ
เหตุผลที่เลือกการกระทําเพือ่ แกไขปญหา และการใชเครื่องมือและเทคนิคการบริหารโครงการตางๆ บาง
โครงการ

9.6.6 การพัฒนาโครงสรางพื้นฐานเพื่อการสื่อสาร
โครงสรางพื้นฐานเพื่อการสื่อสารคือ ชุดของเครื่องมือ เทคนิค และหลักการที่เปน
พื้นฐานสําหรับการถายทอดสารสนเทศระหวางคน เครื่องมือรวมถึงอีเมล ซอฟตแวรการบริหารโครงการ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการสื่อสารโครงการ หนา 9-19

กรุปแวร เครื่องสงแฟกซ โทรศัพท ระบบประชุมทางไกล ระบบจัดการเอกสาร และซอฟตแวรประมวลผล

คํา (word processing software) ตัวอยางเทคนิค เชน แนวทางการรายงานและแมแบบ กฎและ
ขั้นตอนการประชุม กระบวนการตัดสินใจ วิธีการแกปญหา การแกความขัดแยง เทคนิคการตอรอง สวน
ตัวอยางของหลักการคือ การจัดสภาพแวดลอมสําหรับการสนทนาแบบเปด โดยการใชวิธกี ารพูดแบบ
ตรง และการทําตามหลักจริยธรรมที่ตกลง

9.7 สรุป
ความลมเหลวของการสื่อสารเปนภัยคุกคามความสําเร็จของโครงการอยางยิ่ง โดยเฉพาะ
โครงการเทคโนโลยีสารสนเทศ การสื่อสารคือ น้ํามันหลอลื่นทีท่ ําใหโครงการดําเนินไปอยางราบรื่น การ
บริหารการสื่อสารโครงการประกอบดวย การวางแผนการสื่อสาร การกระจายสารสนเทศ การรายงาน
การปฏิบัติงาน และการบริหารผูมีสวนไดเสีย แผนการบริหารการสื่อสารควรทําขึ้นสําหรับทุกโครงการ
การวิเคราะหผูมีสวนไดเสียสําหรับการสื่อสารโครงการชวยกําหนดการสื่อสารที่จําเปนสําหรับบุคคลที่
ตางกัน
วิธีการกระจายสารสนเทศโครงการมีหลากหลายทัง้ ที่เปนทางการและไมเปนทางการ ทั้งการ
เขียนและการพูด การกําหนดสื่อที่เหมาะสมที่สุดสําหรับการกระจายสารสนเทศของโครงการเปนสิ่งที่
สําคัญมาก ผูจัดการโครงการและทีมงานควรใหความสําคัญกับการสรางความสัมพันธ ขณะเดียวกัน
จํานวนชองทางการสื่อสารเพิ่มขึ้นอยางมากมาย ถามีจาํ นวนคนที่ตองการสื่อสารมาก
การรายงานการปฏิบัติงานเกี่ยวของกับการรวบรวม การกระจายสารสนเทศเกี่ยวกับการ
ดําเนินงานของโครงการวาสอดคลองเปาหมายของโครงการแคไหน ทีมงานโครงการสามารถใชตัววัดที่
เรียกวา มูลคาที่ไดรับ (earned value) และขอมูลความกาวหนารูปแบบอื่นๆ สําหรับการสื่อสารและการ
ประเมินการปฏิบัติงานโครงการ การประชุมทบทวนสถานภาพโครงการเปนสวนสําคัญของการสื่อสาร
การติดตามและการควบคุมโครงการ
การบริหารผูมสี วนไดเสียประกอบดวย การบริหารการสื่อสารเพื่อใหสนองความตองการและ
ความคาดหวังของผูมีสวนไดเสียโครงการ และยังรวมถึงการกําหนดและบริหารประเด็นตางๆ
เพื่อปรับปรุงการสื่อสารใหดขี ึ้น ผูจัดการโครงการและทีมงานตองพัฒนาทักษะในการบริหาร
ความขัดแยงรวมทัง้ ทักษะการสื่อสาร การแกไขความขัดแยงเปนสิง่ สําคัญของการบริหารการสื่อสาร
สาเหตุสาํ คัญของความขัดแยงสวนใหญมาจากตารางเวลา ลําดับความสําคัญ การจัดพนักงาน ความ
คิดเห็นเชิงเทคนิค ขั้นตอนวิธีการ คาใชจาย และบุคลิกภาพ วิธีการที่ดีที่สุดในการบริหารความขัดแยง
คือ ใชวิธีการแกปญหา (problem-solving approach) ขอแนะนําอืน่ ๆ สําหรับการปรับปรุงการสื่อสาร

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการสื่อสารโครงการ หนา 9-20

ประกอบดวย การเรียนรูทจี่ ะจัดประชุมใหมีประสิทธิผล การใชอีเมลใหมีประสิทธิผล การใชแมแบบ

สําหรับการสื่อสารสารสนเทศโครงการ และการพัฒนาโครงสรางพืน้ ฐานสําหรับการสื่อสาร

คําถามทายบท
1. แผนการบริหารการสื่อสารควรระบุเรื่องอะไร
2. การวิเคราะหผูมีสวนไดเสียชวยในการเตรียมและทําแผนการบริหารการสื่อสารอยางไร
3. อภิปรายขอดีขอเสียของวิธกี ารกระจายสารสนเทศของโครงการ
4. เพราะเหตุใดการเพิ่มคนในโครงการจึงมีผลกระทบตอการบริหารการสื่อสาร
5. วิธีการบริหารความขัดแยงมีอะไร จงอธิบาย
6. เพราะเหตุใดการใชอีเมลจึงมีผลกระทบทางลบกับการสือ่ สาร ทัง้ ๆ ที่เปนสื่อที่ราคาถูกที่สุด
7. อภิปรายการใชบันทึกประเด็นเพื่อชวยการบริหารผูมีสวนไดเสีย
8. ทานเห็นดวยหรือไมกับขอเสนอแนะการปรับปรุงการสือ่ สารใหดีขึ้น ใหทานเสนอแนะ
เพิ่มเติม

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารความเสี่ยงโครงการ หนา 10-1

10.1 บทนํา
ความเสีย่ งโดยนิยามทั่วไปคือ ความเปนไปไดของการสูญเสียหรือบาดเจ็บ ซึง่ เปนนิยามดาน
ลบที่มีความไมแนนอนมาเกี่ยวของ อยางไรก็ตาม ยังมีความเสีย่ งทีเ่ ปนบวกดวย ความเสีย่ งที่เปนบวก
เปนสิ่งที่ดีทเี่ กิดกับโครงการ ดังนั้น ความเสี่ยงคือ ความไมแนนอนที่สามารถมีผลทั้งดานบวกและดาน
ลบตอการบรรลุวัตถุประสงคของโครงการ ความเสี่ยงที่มีผลดานลบเปรียบเหมือนการประกันภัย สวน
ความเสีย่ งที่มผี ลดานบวกเปรียบเหมือนการลงทุนในโอกาส
การบริหารความเสี่ยงโครงการเปนการระบุ การวิเคราะห และการสนองตอบตอความเสีย่ ง
ตลอดชีวิตของโครงการ การบริหารความเสี่ยงมีผลตอความสําเร็จของโครงการอยางมีนยั สําคัญ รวมทัง้
มีผลตอการเลือกโครงการ การกําหนดขอบเขตของโครงการ การพัฒนาตารางเวลาและประมาณ
คาใชจายที่สอดคลองกับความจริง การบริหารความเสี่ยงยังชวยผูมีสวนไดเสียเขาใจธรรมชาติของ
โครงการ โดยการนําสมาชิกของทีมมารวมกันกําหนดจุดแข็งและจุดออน และชวยบูรณาการองคความรู
ดานตางๆ ของการบริหารโครงการ
องคการหรือบุคลากรมีการบริหารความเสีย่ งที่แตกตางกัน ซึ่งขึน้ อยูวา องคการหรือบุคคลนั้น
มีระดับการยอมรับความเสีย่ ง (risk tolerance) หรืออรรถประโยชนความเสีย่ ง (risk utility) ระดับใด
ระดับการยอมรับความเสี่ยงคือ ปริมาณความพอใจที่ไดรับจากผลลัพธของการตัดสินใจ ซึง่ ทําใหเรา
สามารถจัดบุคคลากรหรือองคการเปน 3 ประเภทคือ
• หลีกเลี่ยงความเสี่ยง (risk averse) คือ องคการหรือบุคคลที่ไมชอบความเสีย่ ง
เมื่อองคการหรือบุคคลตองเผชิญความเสีย่ งที่ใหผลตอบแทนไมเทากัน องคการ
หรือบุคคลจะเลือกทําสิง่ ที่มคี วามเสีย่ งนอยที่สุด ถึงแมวาผลตอบแทนจะนอยกวา
การทําอีกสิง่ หนึ่ง องคการหรือบุคคลจะทําประกันเพื่อไมตองแบกรับความเสีย่ ง
• เปนกลางกับความเสีย่ ง (risk neutral) คือ องคการหรือบุคคล ทีพ่ ยายามทําใหเกิด
ภาวะสมดุลระหวางความเสีย่ งกับเงินที่ตองจาย
• คนหาความเสีย่ ง (risk seeking) คือ องคการหรือบุคคลที่ชอบทําในสิ่งที่ให
ผลตอบแทนสูง ถึงแมวา ความเสี่ยงจะสูงก็ตาม และพรอมที่จะจายคาความเสีย่ ง
นั้น

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารความเสี่ยงโครงการ หนา 10-2

เปาหมายของการบริหารความเสี่ยงคือ ความพยายามที่จะใหมีความเสี่ยงดานลบใหไดนอย
ที่สุด และพยายามเพิม่ ความเสี่ยงดานบวกใหไดมากที่สดุ ความเสีย่ งที่เรารูเปนความเสี่ยงที่เราสามารถ
จัดการไดกอน ซึ่งตางจากความเสีย่ งที่เราไมรู ดังนั้น ผูจัดการโครงการจึงจําเปนที่จะตองพยายามหา
ความเสีย่ งใหไดมากที่สุด เพือ่ จะไดจัดการกับความเสี่ยงไดกอน หรือรับมือกับความเสี่ยงไดอยางถูกตอง
การบริหารความเสี่ยงมีทั้งหมด 6 ขั้นตอนคือ
• การวางแผนบริหารความเสี่ยง (risk management planning) เปนการตัดสินใจ
วาเราจะทําอยางไรกับความเสี่ยงโครงการ กิจกรรมการบริหารความเสี่ยงมีอะไร
โดยการทบทวนขอกําหนดขอบเขตโครงการ แผนการบริหารโครงการ และปจจัย
เชิงสภาพแวดลอมองคการ
• การระบุความเสี่ยง (risk identification) เปนการกําหนดความเสี่ยงอะไรทีม่ ี
ความเปนไปไดที่จะมีผลตอโครงการ และบันทึกคุณลักษณะของความเสี่ยงแตละ
เรื่อง
• การวิเคราะหความเสี่ยงเชิงปริมาณ (quantitative risk analysis) เปนการ
ประมาณการผลความเสีย่ งในเชิงปริมาณ
• การวิเคราะหความเสี่ยงเชิงคุณภาพ (qualitative risk analysis) เปนการ
จัดลําดับความสําคัญตามความเปนไปไดและผลกระทบของการเกิดความเสีย่ ง
• การวางแผนตอบสนองความเสี่ยง (risk response planning) เปนการกําหนด
ขั้นตอนในการลดภัยคุกคาม
• การควบคุมและติดตามความเสีย่ ง (risk monitoring and control) เปนการ
ติดตามความเสี่ยงที่ไดระบุไว การระบุความเสีย่ งใหม การดําเนินการตามแผน
ตอบสนองความเสี่ยง และประเมินประสิทธิผลของกลยุทธ ตลอดชีวติ โครงการ

10.2 การวางแผนบริหารความเสี่ยง
การวางแผนบริหารความเสีย่ งคือ กระบวนการของการตัดสินใจวาจะทําอยางไรกับความ
เสี่ยง และวางแผนกิจกรรมการบริหารความเสี่ยงสําหรับโครงการ ผลลัพธของกระบวนการนี้คือ แผนการ
บริหารความเสี่ยง ซึง่ บันทึกขั้นตอนสําหรับบริหารความเสี่ยงตลอดทัง้ โครงการ ทีมงานควรจัดประชุม
การวางแผนตัง้ แตเนิ่นๆ เพื่อชวยกันพัฒนาแผนบริหารความเสีย่ ง การพัฒนาแผนนี้ ทีมงานควรนํา
นโยบายการบริหารความเสีย่ ง และรายงานบทเรียนที่ไดรับจากโครงการกอนมารวมในการวางแผนดวย
รวมทัง้ ตองทบทวนระดับการยอมรับความเสี่ยงของผูมีสว นไดเสียวาเปนบุคคลที่จัดอยูในกลุมความ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารความเสี่ยงโครงการ หนา 10-3

เสี่ยงประเภทใด เชน ถาผูสนับสนุนโครงการเปนคนที่กลัวความเสี่ยง ทีมงานตองใชวิธีการบริหารความ

เสี่ยงที่แตกตางจากผูสนับสนุนโครงการทีช่ อบความเสีย่ ง
แผนบริหารความเสี่ยงจะบอกวาการบริหารความเสี่ยงสําหรับแตละโครงการจะทําอยางไร
แผนนี้จะเปนแผนยอยแผนหนึ่งในแผนบริหารโครงการ หัวขอที่ควรจะปรากฎในแผนการบริหารความ
เสี่ยงมีดงั นี้
• ระเบียบวิธ:ี โครงการนี้จะทําอยางไรกับการบริหารความเสี่ยง ใชเครื่องมืออะไร
แหลงขอมูลใดที่มีขอมูลให
• บทบาทและความรับผิดชอบ: ใครรับผิดชอบงานอะไรที่เกี่ยวกับการบริหารความ
เสี่ยง สิง่ ที่ไดจากงานทีท่ ําคืออะไร
• งบประมาณและตารางเวลา: งบประมาณและเวลาทีใ่ ชในการทํางานที่เกีย่ วกับ
ความเสีย่ ง
• กลุมความเสี่ยง: กลุมความเสี่ยงที่สาํ คัญที่ควรกลาวถึงสําหรับโครงการนี้มีอะไร
โครงสรางจําแนกความเสีย่ ง
• ผลกระทบและความนาจะเปนของความเสี่ยง: ประเมินผลกระทบและความนาจะ
เปนของความเสี่ยงแตละเรื่องไดอยางไร ใชวิธีการอะไรในการใหคะแนนและแปล
ความหมาย วิธกี ารอะไรที่ใชในการวิเคราะหความเสีย่ งเชิงปริมาณและเชิง
คุณภาพ
• เอกสารความเสี่ยง: รูปแบบของรายงานและกระบวนการรายงานที่จะนํามาใชกบั
กิจกรรมการบริหารความเสีย่ ง

นอกจากแผนการบริหารความเสี่ยงแลว ควรมีแผนสํารอง (contingency plan) แผนทางถอย

(fallback plan) และเงินทุนสํารอง (contingency reserves)
• แผนสํารอง (contingency plan) คือ แผนทางเลือกที่จะนํามาใชในกรณีที่
เหตุการณเสีย่ งที่ไมพึงปารถนาเกิดขึ้น เชน ทีมงานรูวา ซอฟตแวรรุนใหมอาจออก
ไมทันที่จะใชสาํ หรับโครงการ ทีมงานอาจมีแผนสํารองใหใชซอฟตแวรรุนเกาที่มีอยู
แผนสํารองจึงเปนแผนที่จะปองกันหรือลดผลเสียของเหตุการณเสี่ยงที่เกิดขึ้น แผน
สํารองจะจัดทําเหมือนแผนทั่วๆ ไป คือ จะตองตอบคําถามวา จะทําอะไร ทําที่ไหน
ทําอยางไร ใครทํา และมีคา ใชจายเทาใด ถาผูจัดการโครงการไมมีแผนสํารอง ก็จะ
ทําใหเกิดความลาชา หรือสับสนวุน วาย เมื่อมีเหตุการณเสี่ยงเกิดขึน้

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารความเสี่ยงโครงการ หนา 10-4

• แผนทางถอย (fallback plan) เปนแผนที่ไดพัฒนาสําหรับความเสีย่ งทีม่ ีผลกระทบ

สูงตอวัตถุประสงคของโครงการ และความพยายามที่จะลดความเสีย่ งไมมี
ประสิทธิผล เชน นักศึกษาใหมอาจมีแผนหลักและแผนสํารองหลายแผนวาจะอยูท ี่
ไหนเมื่อจบการศึกษา แตถา ไมมีแผนไหนเลยที่ใชได แผนทางถอยอาจคืออาศัยอยู
ที่บานชั่วระยะเวลาหนึง่ บางครั้งแผนสํารองกับแผนทางถอยใชเรียกแทนกันได
• เงินทุนสํารอง (contingency reserves) เปนเงินทุนที่จัดตั้งขึ้นเพื่อนําออกมาใช
จายในกรณีที่เกิดความผิดพลาดจากการประมาณรายรับ ประมาณการรายจาย
หรือเกิดความผิดพลาดที่ไมไดประมาณการรายจายสําหรับบางกิจกรรมไว หรือ
เกิดเหตุการณเสี่ยงตางๆ ที่ทาํ ใหตองมีคาใชจายเพิ่ม เชน ถาโครงการหนึง่ เกิด
เหตุการณที่ตองใชความรูใหมที่สมาชิกไมมีประสบการณ และทีมงานไมไดระบุไว
วาเปนความเสี่ยง ผูสนับสนุนโครงการอาจจัดงบเพิ่มจากเงินสํารองเพื่อจางที่
ปรึกษาขางนอกมาอบรมและใหคําปรึกษาแกสมาชิกในทีมเกีย่ วกับเทคโนโลยีใหม
เงินทุนสํารองนี้แบงเปน 2 สวนคือ เงินทุนสํารองงบประมาณของโครงการ
(budget reserves) เพื่อใชจายในกรณีที่เกิดเหตุการณเสี่ยงกับกิจกรรมของ
โครงการ อีกสวนหนึง่ คือ เงินทุนสํารองดานการบริหาร (management reserves)
เพื่อใชจายในกรณีที่เกิดเหตุการณเสี่ยงทีก่ ระทบตอโครงการโดยรวม

10.3 ประเภทของความเสี่ยงทางเทคโนโลยีสารสนเทศ
ชวอบี (Schwalbe, 2007) ไดกลาวถึงประเภทความเสีย่ งที่องคการนิยมตั้งคําถามแบง
ออกเปน 5 กลุมคือ
• ความเสีย่ งดานตลาด (market risk)
ƒ ถาโครงการเทคโนโลยีสารสนเทศเปนโครงการที่สรางผลิตภัณฑหรือ
บริการใหม โครงการนี้จะมีประโยชนตอองคการหรือไม หรือสามารถทํา
ตลาดใหกับผลิตภัณฑอื่นหรือไม
ƒ ผูใชจะยอมรับและใชผลิตภัณฑหรือบริการหรือไม
ƒ มีใครอื่นที่สรางผลิตภัณฑหรือบริการที่ดีกวาหรือเร็วกวาหรือไม ซึ่งจะทํา
ใหโครงการเสียเวลาและเงิน
• ความเสีย่ งดานการเงิน (financial risk)
ƒ องคการสามารถสนับสนุนโครงการใหดําเนินการไดหรือไม
ƒ ผูมีสวนไดเสียจะมั่นใจในการคาดการณทางการเงินไดอยางไร

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารความเสี่ยงโครงการ หนา 10-5

ƒ โครงการจะทําไดตามคามูลคาปจจุบันสุทธิ อัตราผลตอบแทนจากการ
ลงทุน และระยะเวลาการคืนทุนที่ไดประมาณการณหรือไม ถาทําไมได
องคการสามารถสนับสนุนโครงการใหดําเนินการตอไปไดหรือไม
ƒ โครงการนี้เปนทางเลือกที่ดีทสี่ ุดที่จะใชทรัพยากรการเงินขององคการ
หรือไม
• ความเสีย่ งดานเทคโนโลยี (technology risk)
ƒ โครงการนี้มีความเปนไปไดเชิงเทคนิคหรือไม
ƒ โครงการจะใชเทคโนโลยีที่มวี ุฒิภาวะ หรือใชเทคโนโลยีที่ล้ําหนาหรือไม
ƒ เมื่อไรจึงตัดสินใจวาจะใชเทคโนโลยีอะไร
ƒ ฮารดแวร ซอฟตแวรและเครือขายทํางานไดอยางเหมาะสมหรือไม
ƒ เทคโนโลยีนี้จะมีใหใชทันเวลาหรือไม
ƒ เทคโนโลยีนี้อาจลาสมัยกอนผลิตภัณฑจะผลิตออกมาหรือไม
• ความเสีย่ งดานคน (people risk)
ƒ องคการมีหรือสามารถหาบุคคลากรที่มที กั ษะที่เหมาะสมเพื่อทําให
โครงการเสร็จสมบูรณหรือไม
ƒ บุคคลากรมีทกั ษะเชิงเทคนิคและเชิงบริหารหรือไม
ƒ บุคคลากรมีประสบการณเพียงพอหรือไม
ƒ ผูบริหารอาวุโสสนับสนุนโครงการหรือไม
ƒ มีผูสนับสนุนโครงการหรือไม
ƒ องคการมีความคุนเคยกับลูกคาหรือผูสนับสนุนหรือไม
ƒ ความสัมพันธกับลูกคาหรือผูสนับสนุนโครงการดีแคไหน
• ความเสีย่ งดานโครงสราง/กระบวนการ (structure/process risk)
ƒ โครงการจะเสนอการเปลีย่ นแปลงระดับใดกับขั้นตอนทางธุรกิจและสวนที่
เกี่ยวกับผูใช
ƒ มีกลุมผูใชที่แตกตางจํานวนมากแคไหนที่โครงการจําเปนตองตอบสนอง
ความตองการ
ƒ ระบบอื่นทีโ่ ครงการตองทํางานรวมมีมากแคไหน
ƒ องคการมีกระบวนการอยูแลวที่จะทําใหโครงการเสร็จสมบูรณหรือไม

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารความเสี่ยงโครงการ หนา 10-6

โครงสรางจําแนกความเสีย่ งเปนเครื่องมือที่เปนประโยชนสําหรับผูจัดการโครงการทีจ่ ะ
พิจารณาความเสี่ยงที่มีศักยภาพในกลุมทีแ่ ตกตางกัน รูปที่ 10.1 คือ ตัวอยางการจําแนกความเสีย่ ง โดย
การใชผังโครงสรางองคการ ความเสี่ยงไดจัดเปน 4 กลุมคือ ความเสี่ยงเชิงธุรกิจ ความเสีย่ งเชิงเทคนิค
ความเสีย่ งเชิงองคการ และความเสีย่ งเชิงการบริหารโครงการ ภายใตความเสีย่ งเชิงธุรกิจจะมีความ
เสี่ยงทางดานคูแขง ความเสี่ยงดานผูขาย ความเสี่ยงดานกระแสเงินสด สวนความเสีย่ งเชิงเทคนิค
ประกอบดวยความเสีย่ งทางฮารดแวร ซอฟตแวร และเครือขาย ความเสีย่ งเชิงองคการจะมีความเสี่ยง
ดานการสนับสนุนของผูบริหารระดับสูง การสนับสนุนของผูใช การสนับสนุนของทีมงาน และความเสีย่ ง
ดานการบริหารโครงการจะรวมถึงความเสีย่ งการประมาณการ ความเสี่ยงดานการสื่อสาร และความ
เสี่ยงดานทรัพยากร

รูปที่ 10.1 ตัวอยางโครงสรางจําแนกความเสี่ยง (Schwalbe, 2007)

การจําแนกความเสี่ยงอาจใชเทคนิคอืน่ ที่ไมใชผังโครงสรางองคการก็ได เชน การจําแนก

โครงสรางความเสี่ยงในลักษณะเดียวกับสารบัญหนังสือ ซึ่งเหมาะกับกรณีที่ความเสี่ยงมีความซับซอน
ความเสีย่ งที่ถกู จําแนกสามารถนําเสนอใหอยูในหนาเดียว ทําใหผูจัดการโครงการสามารถวิเคราะห
ความเสีย่ งไดสะดวก
ความเสีย่ งยังสามารถจําแนกตามองคความรูเกี่ยวกับการบริหารโครงการ 9 ดาน เชน ความ
เสี่ยงทางดานขอบเขตโครงการ ความเสีย่ งทางดานเวลา ความเสีย่ งทางดานคาใชจาย และความเสี่ยง
ทางดานคุณภาพ ดังตัวอยางในตารางที่ 10.1

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารความเสี่ยงโครงการ หนา 10-7

ตารางที่ 10.1 ตัวอยางการจัดความเสีย่ งที่เกีย่ วกับความรูการบริหารโครงการ

(Schwalbe, 2007)
กลุมความรู ความเสี่ยง
การบูรณาการ การวางแผนไมเพียงพอ การจัดสรรทรัพยากรไมดี การบริหารการบูรณาการไมดี ขาดการ
ทบทวนโครงการ
ขอบเขต การนิยามขอบเขตโครงการหรือกลุมงานไมดี นิยามไมสมบูรณ
เวลา ความผิดพลาดในการประมาณเวลา หรือทรัพยากรที่มีใหใช ความผิดพลาดในการกําหนด
เสนทางวิกฤต การจัดการและการจัดสรรเวลาลอยตัว (floating time) ไมดี ปลอยผลิตภัณฑที่
ไดเปรียบเชิงการแขงขันเร็วไป
คาใชจาย ความผิดพลาดในการประมาณการ ประสิทธิภาพ คาใชจาย หรือเงินสํารองไมพอเพียง
คุณภาพ ทัศนคติตอคุณภาพไมดี การออกแบบ/วัตถุดิบต่ํากวามาตรฐาน โปรแกรมประกันคุณภาพไม
เพียงพอ
ทรัพยากรมนุษย การจัดการความขัดแยงไมดี โครงสรางองคการของโครงการและการนิยามความรับผิดชอบไม
ดี ขาดผูนํา
การสื่อสาร ขาดความระมัดระวังในการวางแผน หรือการสื่อสาร ขาดการปรึกษากับผูมีสวนไดเสียหลัก
ความเสี่ยง ละเลยความเสี่ยง ขาดความชัดเจนในการวิเคราะหความเสี่ยง การบริหารการประกันคุณภาพ
ไมดี
การจัดซื้อจัดจาง ไมสามารถบังคับตามเงื่อนไขของสัญญา ความสัมพันธเชิงปรปกษกับผูขาย/ผูใหบริการ

10.4 การระบุความเสี่ยง
การระบุความเสี่ยงคือ กระบวนการของความเขาใจวาเหตุการณใดทีม่ ีศักยภาพที่จะทําราย
โครงการ หรือสงเสริมใหโครงการดีขึ้น การระบุความเสี่ยงที่มีศักยภาพเปนเรื่องที่จําเปน เราตองระบุ
ความเสีย่ งอยางตอเนื่องตามการเปลี่ยนแปลงของสภาวะแวดลอม เราไมสามารถบริหารโครงการได ถา
เราไมทราบวาสิ่งใดคือความเสี่ยง
ทีมงานเริ่มกระบวนการระบุความเสีย่ งโดยการทบทวนเอกสารโครงการ สารสนเทศปจจุบัน
และในอดีตที่เกี่ยวของกับองคการ และสมมุติฐานที่อาจมีผลตอโครงการ เครื่องมือและเทคนิคที่ชวยใน
การระบุความเสี่ยงที่ใชกนั มี 7 ชนิดคือ การระดมความคิด เทคนิคการประชุมกลุมแบบนอมินอล
(nominal group technique) เทคนิคเดลฟาย (Delphi technique) การสัมภาษณ การวิเคราะหสาเหตุ
ของปญหา การวิเคราะห SWOT และบทเรียนจากโครงการในอดีต

10.4.1 การระดมความคิด
เปนเทคนิคทีก่ ลุมพยายามทีจ่ ะสรางความคิด หรือหาคําตอบสําหรับปญหา
เฉพาะ โดยการรวบรวมความคิดจากคนหลายคนพรอมๆ กัน วิธกี ารนี้ทาํ ใหกลุมสามารถสรางรายการ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารความเสี่ยงโครงการ หนา 10-8

ความเสีย่ งที่สมบูรณครบถวน และนําไปวิเคราะหความเสี่ยงเชิงปริมาณและคุณภาพตอไป เมื่อได

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

10.4.2 เทคนิคการประชุมกลุมแบบนอมินอล
เปนเทคนิคสําหรับการระบุความเสีย่ งที่พยายามใหเกิดสมดุล และเพิ่มการมีสวน
รวมของผูเขารวมประชุม โดยมีหลักการดังนี้
• สมาชิกแตละคนจะเขียนความคิดของตนลงในกระดาษ โดยไมมีการ
พูดคุยหรือปรึกษา
• แตละความคิดของแตละคนจะนํามาเขียนบนบอรดหรือกระดาษ
• กลุมอภิปรายและทําความชัดเจนแตละความคิด
• แตละคนจะจัดลําดับและความสําคัญของความคิดที่ไดเสนออยาง
เงียบๆ
• กลุมจะเริ่มอภิปรายการจัดลําดับและความสําคัญของความคิด
• แตละคนจัดลําดับและความสําคัญของความคิดอีกครั้ง
• สรุปลําดับความสําคัญของความคิด

10.4.3 เทคนิคเดลฟาย
เปนวิธีการที่ชว ยหลีกเลี่ยงผลดานลบจากกลุมที่ใชเทคนิคการระดมความคิด
แนวคิดพืน้ ฐานของเทคนิคเดลฟายคือ เพื่อใหไดความคิดเห็นเปนเอกฉันทจากคณะผูเชี่ยวชาญผูท ําการ
คาดการณเกีย่ วกับการพัฒนาในอนาคต เทคนิคนี้เปนเทคนิคที่เปนระบบ ขั้นตอนการพยากรณขึ้นกับ
ขอมูลนําเขาจากบุคคลอิสระและไมทราบวาเปนขอมูลของใคร เทคนิคเดลฟายจะเปนการตั้งคําถามแลว
ใหผูเชี่ยวชาญแตละคนตอบคําถามนัน้ คําตอบจะนํามาประมวลผล ผลทีไ่ ดจะสงกลับไปยังคณะ
ผูเชี่ยวชาญอีกครั้ง ดังนัน้ ผูเ ชี่ยวชาญจะไมทราบวาผลที่ไดนั้นเปนของผูเชี่ยวชาญคนใด เมื่อผูเ ชี่ยวชาญ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารความเสี่ยงโครงการ หนา 10-9

พิจารณาผลแลว จะใหผลปอนกลับเพื่อกลับไปประมวลผลใหม และนําไปใชในรอบตอไป กระบวนการ

จะเปนเชนนี้จนกระทั่งไดความเห็นเปนเอกฉันท

10.4.4 การสัมภาษณ
เปนเทคนิคที่ใชเก็บรวบรวมขอเท็จ-จริงจากผูมีสวนไดเสียของโครงการ โดยการ
เผชิญหนา โทรศัพท หรือไปรษณียอิเล็กทรอนิกส การสัมภาษณคนที่มปี ระสบการณจากโครงการที่มี
ลักษณะคลายคลึงกับโครงการที่เรากําลังจะดําเนินการ วิธีการนี้เปนวิธกี ารทีส่ ําคัญสําหรับการระบุ
ความเสีย่ งที่มศี ักยภาพ การเตรียมการสัมภาษณเปนสิง่ ที่สําคัญ ทีมงานควรสรางคําถามเพื่อใชเปนแนว
ทางการสัมภาษณ แตคุณภาพของสารสนเทศที่ไดมาขึน้ อยูกับทักษะของผูสัมภาษณและผูถูกสัมภาษณ
คอนขางสูง รวมทั้งกระบวนการการสัมภาษณดวย

10.4.5 การวิเคราะหสาเหตุของปญหา
เปนเทคนิคที่ใชผังกางปลาของอิชิคาวาที่ใชในการวิเคราะหคุณภาพของ
ผลิตภัณฑ ผังกางปลาสามารถนํามาใชเพือ่ ทําความเขาใจสาเหตุหรือปจจัยของความเสี่ยงใดความเสี่ยง
หนึง่ ดังรูปที่ 10.2 ที่แสดงสาเหตุของการลาออกของสมาชิกหลักของทีม โดยมีปจจัยหลักประกอบดวย
โอกาสที่ดีกวา ประสิทธิภาพการทํางานต่าํ สภาพแวดลอมของทีมงานไมดี การทํางานที่มากเกินไป ซึ่ง
แตละปจจัยหลักยังมีสาเหตุที่ทาํ ใหเกิดปจจัยอีก เชน สาเหตุทที่ าํ ใหเกิดโอกาสที่ดีกวาประกอบดวย
คาจางที่สงู กวา ความกาวหนา สิ่งทาทายใหมๆ เปนตน

รูปที่ 10.2 ผังกางปลาสําหรับการวิเคราะหสาเหตุของความเสี่ยง (Marchewka, 2006)

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารความเสี่ยงโครงการ หนา 10-10

ขั้นตอนการวิเคราะหสาเหตุของความเสีย่ งดวยผังกางปลามีดังนี้
• ระบุความเสีย่ งในแงของภัยคุกคามและโอกาส
• ระบุปจจัยหลักที่สามารถเปนสาเหตุทที่ ําใหเกิดความเสีย่ ง
• ระบุปจจัยยอยหรือสาเหตุของแตละปจจัยหลัก
• ตรวจสอบแกไขทําผังจนกระทั่งไดผังที่สมบูรณ

10.4.6 การวิเคราะห SWOT

เปนเทคนิคที่ใชในการวางแผนเชิงกลยุทธ การวิเคราะห SWOT สามารถใชใน
การระบุความเสี่ยงได โดยทีมงานจะเนนความเสีย่ งในมุมมองระดับสูงหรือกวาง ทีมงานจะพิจารณาใน
รายละเอียดวาจุดแข็งขององคการคืออะไร จุดออนที่เกี่ยวของกับโครงการคืออะไร และอะไรคือโอกาส
และภัยคุกคามโครงการ ทีมงานจะระบุประเด็นที่ไดลงในตาราง 4 ชอง ดังรูปที่ 10.3

รูปที่ 10.3 การวิเคราะห SWOT

10.4.7 บทเรียนจากโครงการในอดีต
เปนการวิเคราะหความเสี่ยงโดยการพิจารณาบทเรียนที่โครงการอื่นที่ได
ดําเนินการมาแลว และไดทาํ การบันทึกความเสีย่ งที่แตละโครงการไดประสบ พรอมทั้งวิธกี ารที่ใชในการ
แกไขความเสีย่ งนั้น การเลือกบทเรียนนมาใชนั้นตองเลือกจากโครงการที่มีลักษณะใกลเคียงกัน
ตารางที่ 10.2 ทะเบียนความเสี่ยง (Schwalbe, 2007)
ความนาจะเปน
กลุมความเสี่ยง

การตอบสนอง

เจาของความ
ที่มีศักยภาพ
สาเหตุของ
ความเสี่ยง

ความเสี่ยง

สถานภาพ
ผลกระทบ
คําอธิบาย
ลําดับที่

ตัวกระตุน
เลขที่

เสี่ยง

R44 1
R21 2
R7 3

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารความเสี่ยงโครงการ หนา 10-11

ผลลัพธหลักของกระบวนการระบุความเสีย่ งคือ รายการความเสี่ยงและขอมูลอื่นๆ ที่จาํ เปน

ในการสรางทะเบียนความเสี่ยง (risk register) ทะเบียนความเสี่ยงคือ เอกสารที่เปนผลลัพธของ
กระบวนการบริหารความเสีย่ งตางๆ ซึง่ แสดงในรูปของตาราง (ตารางที่ 10.2) ทะเบียนความเสี่ยงใช
บันทึกเหตุการณเสี่ยงที่มีศักยภาพทั้งในแงลบและแงบวกตอโครงการ เชน ความลมเหลวของ
ประสิทธิภาพของผลิตภัณฑ เวลาที่งานเสร็จไดเลื่อนไป ขาดแคลนพนักงาน หรือการไดรับความรวมมือ
ที่ดีจากบริษทั ที่ผลิตสินคาทีม่ ีคุณภาพ เปนตน เนื้อหาทีป่ รากฎในทะเบียนความเสีย่ งประกอบดวย
• เลขที่ความเสีย่ ง
• ลําดับที่ของความเสีย่ ง
• ชื่อของเหตุการณเสี่ยง
• คําอธิบายเหตุการณเสี่ยง
• กลุมความเสี่ยง
• สาเหตุของความเสี่ยง
• ตัวกระตุนความเสี่ยง
• การตอบสนองความเสี่ยง
• เจาของความเสี่ยง
• ความนาจะเปนที่จะเกิดความเสี่ยง
• ผลกระทบตอโครงการ
• สถานภาพความเสี่ยง เชน ความเสี่ยงเกิดหรือยัง กลยุทธที่ตอบสนอง
ความเสีย่ งสมบูรณหรือไม ความเสีย่ งยังคงเกี่ยวของกับโครงการอีกหรือไม

10.5 การวิเคราะหความเสี่ยงเชิงคุณภาพ
การวิเคราะหความเสีย่ งเชิงคุณภาพประกอบดวย การประเมินโอกาสและผลกระทบของ
ความเสีย่ งที่ไดระบุ การกําหนดขนาดและลําดับความสําคัญ ตัวอยางวิธีการทีใ่ ชวิเคราะหความเสี่ยง
เชน การใชผังความนาจะเปน/ผลกระทบ (probability/impact chart) ตารางผลกระทบความเสี่ยง (risk
impact table) กรอบการจัดกลุมความเสีย่ งของทูสเลอร (Tusler’s risk classification schema) ตนไม
การตัดสินใจ (decision trees) มูลคาทางการเงินที่คาดหวัง (expected monetary value) และดุลย
พินิจของผูเชี่ยวชาญ (expert judgment)

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารความเสี่ยงโครงการ หนา 10-12

10.5.1 การใชผงั ความนาจะเปน/ผลกระทบ

ผูจัดการโครงการสามารถกําหนดความนาจะเปนและผลกระทบบนผังความ
นาจะเปน/ผลกระทบ บนผังนี้จะแสดงความเปนไปไดสัมพัทธของการเกิดความเสี่ยงบนแกนหนึง่ และ
แสดงผลกระทบสัมพัทธของการเกิดความเสี่ยงบนอีกแกนหนึ่ง ซึ่งจะชวยผูจัดการโครงการสามารถให
ความสนใจกับความเสีย่ งทีส่ ําคัญได โดยแกนแตละดานจะกําหนดมาตรวัดเปน 3 ระดับ คือ ต่ํา ปาน
กลาง และสูง ดังแสดงในรูปที่ 10.4
จากรูปที่ 10.4 จะเห็นวาความเสีย่ งที่ผูจดั การโครงการควรใหความสําคัญมาก
ที่สุดคือ ความเสี่ยงที่ตกอยูในกลุมที่ 7 เนื่องจากโอกาสทีจ่ ะเกิดความเสีย่ งสูงและเมื่อเกิดแลวจะมี
ผลกระทบตอโครงการสูงเชนกัน สวนความเสี่ยงที่ตกอยูใ นกลุมที่ 3 ผูจัดการโครงการอาจจะไมตองให
ความสนใจในขณะนี้ ถึงแมวากลุม ที่ 6 และ 9 ความนาจะเปนที่จะเกิดความเสีย่ งนี้จะต่ํา แตถา เกิดแลว
จะมีผลกระทบที่รุนแรงตอโครงการ

รูปที่ 10.4 ผังความนาจะเปน/ผลกระทบ (Schwalbe, 2007)

บางโครงการ ทีมงานจะใชเทคนิคทีเ่ รียกวาปจจัยความเสี่ยง (risk factor) ซึ่งเปน

ตัวเลขที่แสดงภาพรวมของความเสีย่ งของเหตุการณนั้นตามความนาจะเปนของการเกิดความเสีย่ งกับ
ผลกระทบหรือผลที่ตามมาของความเสีย่ งนัน้ ความนาจะเปนของการเกิดความเสีย่ งสามารถประมาณ
การไดโดยขึ้นอยูปจจัยหลายปจจัยตามธรรมชาติที่เปนเอกลักษณของแตละโครงการ เชน ปจจัยที่
นํามาใชประเมินความเสี่ยงทางดานฮารดแวรและซอฟตแวรอาจมี วุฒิภาวะของเทคโนโลยี ความ
ซับซอนของเทคโนโลยี และการใหความสนับสนุน เปนตน ผลกระทบของการเกิดความเสีย่ งอาจเปนผล
การดําเนินงานไมไดตามเปาหมาย รวมทัง้ เวลาและคาใชจาย

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารความเสี่ยงโครงการ หนา 10-13

ความเสี่ยงสูง

ความเสี่ยง
ปานกลาง

ความเสี่ยง
ต่ํา

ผลที่ตามมาของความลมเหลว

รูปที่ 10.5 ตัวอยางของการใชปจจัยความเสี่ยง (Schwalbe, 2007)

รูปที่ 10.5 เปนตัวอยางของการใชปจจัยความเสีย่ ง โดยแสดงถึงความนาจะเปน

ของความลมเหลวและผลทีต่ ามมาของความลมเหลวสําหรับเทคโนโลยีทนี่ ําเสนอ จุดแตละจุดแสดงถึง
เทคโนโลยีที่มศี ักยภาพสําหรับโครงการ เทคโนโลยีตางๆ ไดจัดออกเปน 3 กลุม คือ กลุมที่ความเสี่ยงสูง
กลุมที่มีความเสี่ยงปานกลาง และกลุมที่มีความเสี่ยงต่ํา โดยพิจารณาจากความนาจะเปนของความ
ลมเหลวและผลที่ตามมาของความลมเหลว จากรูปดังกลาว ผูจัดการโครงการควรที่จะลงทุนใน
เทคโนโลยีที่มคี วามเสีย่ งต่ําหรือความเสีย่ งปานกลาง ไมควรลงทุนในเทคโนโลยีที่มคี วามเสีย่ งสูง เราจะ
เห็นไดวา การใชปจจัยความเสี่ยงเปนการนําเสนอภาพทีห่ นักแนนกวาการแคระบุวาความนาจะเปนหรือ
ผลที่ตามมาของความเสี่ยงคือ สูง ปานกลาง หรือต่ํา

10.5.2 ตารางผลกระทบความเสีย่ ง
เปนเทคนิคที่ผจู ัดการโครงการสามารถนํามาใชในการวิเคราะหและจัดลําดับ
ความสําคัญของความเสี่ยง ผลกระทบความเสีย่ งไดจากผลคูณของความนาจะเปนของการเกิดความ
เสี่ยงกับระดับผลกระทบของความเสีย่ งนั้นที่เกิดขึ้นกับโครงการ ดังตัวอยางในตารางที่ 10.3 ในสดมภ
แรกจะแสดงความเสีย่ งที่เราไดจากขั้นตอนแรกของกระบวนการบริหารความเสี่ยง สดมภที่ 2 แสดง
ความนาจะเปนที่ความเสีย่ งนั้นจะเกิด สดมภที่ 3 คือ ระดับผลกระทบของความเสีย่ ง ซึ่งกําหนดตั้งแต
1–10 โดยที่ 1 หมายถึงผลกระทบเล็กนอย หรือแทบไมมผี ลกระทบตอโครงการ สวน 10 หมายถึง ความ
เสี่ยงมีผลกระทบรุนแรงที่สดุ ตอโครงการ สดมภที่ 4 เปนคะแนนความเสี่ยงที่ไดจากการนําคาในสดมภที่
2 คูณกับคาในสดมภที่ 3 การคํานวณหาคะแนนความเสีย่ งจะชวยใหการจัดลําดับความสําคัญของ
ความเสีย่ งงายขึ้น

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารความเสี่ยงโครงการ หนา 10-14

ตารางที่ 10.3 ตัวอยางตารางผลกระทบความเสี่ยง (Marchewka, 2006)

ความเสี่ยง (ภัยคุกคาม) ความนาจะ ผลกระทบ คะแนน
เปน (P) (I) P*I
0-1 0-10
สมาชิกหลักของทีมงานออกจากโครงการ 0.40 4 1.6
ลูกคาไมสามารถกําหนดขอบเขตและความตองการ 0.50 6 3.0
ลูกคามีประสบการณปญหาการเงิน 0.10 9 0.9
ลูกคา/ผูใชยอมรับเวลาสนองตอบ 0.80 6 4.8
เทคโนโลยีไมบูรณาการกับระบบงานที่มี 0.60 7 4.2
ผูจัดการดานฟงกชันนําทรัพยากรของโครงการออกไป 0.20 3 0.6
ลูกคาไมสามารถไดรับใบอนุญาต 0.05 7 0.4

10.5.3 กรอบการจัดกลุมความเสีย่ งของทูสเลอร

ทูสเลอรไดเสนอวาความเสีย่ งสามารถจัดได 4 ประเภท ดังรูปที่ 10.6 โดยแตละ
ประเภทมีความหมายดังนี้คอื
• กลุมลูกแมว (kittens) เปนกลุมที่มีความนาจะเปนทีจ่ ะเกิดความเสี่ยงต่ํา
และมีผลกระทบตอโครงการต่ําดวย ความเสีย่ งกลุมนี้ไมคอยเปนแหลง
ของปญหา ดังนัน้ เวลาและทรัพยากรไมควรอุทิศเพื่อตอบสนองภัย
คุกคามเหลานี้
• กลุมลูกหมา (puppies) กลุม นี้คลายกับความเสีย่ งกลุมลูกแมว แตความ
เสี่ยงกลุม นี้จะกลายเปนแหลงของความยุง ยากไดรวดเร็ว เนื่องจากเปน
กลุมที่มีความนาจะเปนที่จะเกิดความเสี่ยงสูง ความเสีย่ งกลุม นี้ตองไดรับ
การเฝาดู เพื่อที่เราจะไดจัดการกับมันกอนที่มนั จะกลายเปนความเสีย่ งที่มี
ความซับซอนที่ยากแกการจัดการ
• กลุมเสือ (tigers) เปนกลุมความเสีย่ งที่มคี วามนาจะเปนที่จะเกิดสูง และ
มีผลกระทบสูง คลายกับชื่อของเสือที่เปนสัตวที่อันตราย จึงเปนกลุมความ
เสี่ยงที่ตองทําใหเกิดความเปนกลางใหเร็วที่สุด
• กลุมจระเข (alligators) จระเขเปนสัตวที่ไมอันตราย ถาเรารูวามันอยูท ี่
ไหน เราสามารถหลีกเลีย่ งได ความเสี่ยงกลุมนีก้ ็เชนเดียวกัน เราสามารถ
หลีกเลี่ยงไดถา เรารูวา ความเสี่ยงคืออะไร ความเสี่ยงกลุมนี้มีความนาจะ
เปนทีจ่ ะเกิดต่าํ แตผลกระทบที่เกิดขึ้นจากความเสีย่ งจะสูง

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารความเสี่ยงโครงการ หนา 10-15

รูปที่ 10.6 การจัดกลุมความเสีย่ งของทูสเลอร (Marchewka, 2006)

10.5.4 มูลคาทางการเงินที่คาดหวัง
การใชวิธกี ารนี้จะมีการคํานวณมูลคาทางการเงินที่คาดหวัง ซึง่ เปนผลคูณของ
ความนาจะเปนของการเกิดเหตุการณเสี่ยงและมูลคาทางการเงินของเหตุการณนนั้ ดังตัวอยางตารางที่
10.4 จากตารางดังกลาว ผูจ ัดการโครงการเชื่อวาโครงการมีโอกาสนอยที่จะเสร็จกอน 20 วัน หรือชาไป
20 วัน ถาโครงการเสร็จกอน หรือภายในกําหนดจะไดผลตอบแทนทีส่ ูง ถาโครงการเสร็จชาจะตองเสีย
คาใชจายเพิ่ม ผลตอบแทนทีค่ าดวาจะไดรับโดยรวม คือ 87,000 บาท

ตารางที่ 10.4 ตารางมูลคาทางการเงินที่คาดหวัง (Marchewka, 2006)

A B
A*B
ตารางเวลาความเสี่ยง ความนาจะ คาใชจาย
(พันบาท)
เปน (พันบาท)
โครงการเสร็จสมบูรณเร็ว 20 วัน 0.05 200 10
โครงการเสร็จสมบูรณเร็ว 10 วัน 0.20 150 30
โครงการเสร็จสมบูรณตามเวลาที่กําหนด 0.50 100 50
โครงการเสร็จสมบูรณชา 10 วัน 0.20 - -
โครงการเสร็จสมบูรณชา 20 วัน 0.05 (50) (3)
1.00 87
มูลคาทางการเงิน
ที่คาดหวัง

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารความเสี่ยงโครงการ หนา 10-16

10.5.5 ตนไมการตัดสินใจ
ตนไมการตัดสินใจเปนเทคนิคการวิเคราะหที่ชว ยเลือกการกระทําในสถานการณ
ที่ซึ่งผลลัพธในอนาคตไมแนนอน โดยการคํานวณหามูลคาทางการเงินที่คาดหวัง รูปที่ 10.7 แสดง
ตัวอยางตนไมการตัดสินใจ จากรูป สมมติวาโครงการกําลังเผชิญกับปญหาคาใชจายและระยะเวลา
ดําเนินโครงการเกินกวาทีก่ าํ หนดในแผนบริหารโครงการ ผูจัดการโครงการพยายามที่จะลดเวลาที่ใชใน
การทดสอบระบบงาน เพื่อทําใหสถานภาพโครงการกลับมาใหไดตามแผนที่ไดกาํ หนดไวเดิม ผูจัดการ
โครงการตองตัดสินใจวาทีมงานโครงการควรทําการทดสอบระบบงานแบบสมบูรณตามแผน หรือจะลด
เวลาการทดสอบใหสั้นลงโดยการทดสอบแบบจํากัด คาใชจายในการทดสอบแบบสมบูรณคือ 100,000
บาท แตผูจัดการโครงการเชื่อวามีโอกาสรอยละ 95 ที่โครงการจะผลิตงานไดตามมาตรฐานคุณภาพที่
ลูกคากําหนด โดยไมมีการทํางานใหมหรือมีคาใชจายเพิม่ ขณะเดียวกัน โอกาสที่ระบบงานจะไมไดตาม
มาตรฐานคุณภาพเพียงรอยละ 5 ซึ่งผูจดั การโครงการเชื่อวามีงานเพียงเล็กนอยทีต่ องทําใหมเพือ่ ใหได
มาตรฐาน ในกรณีนี้ โครงการตองมีคาใชจายเพิ่ม 20,000 บาท
ถาผูจัดการโครงการเลือกทีจ่ ะลดระยะเวลาการทดสอบโดยการจํากัดการ
ทดสอบ จะทําใหโอกาสที่ระบบงานมีคุณภาพตามมาตรฐานต่ําลง ระบบงานที่ไมไดมาตรฐานจะทําให
เกิดคาใชจายในการทํางานใหม หรือตองแกไขขอผิดพลาด ถาคาใชจายในการทดสอบระบบงานแบบ
จํากัดจะลดลงเหลือ 80,000 บาท แตโอกาสที่ระบบงานจะทดสอบผานมาตรฐานคุณภาพมีเพียงรอยละ
30 ในขณะทีโ่ อกาสที่ระบบงานไมผานมาตรฐานมีถงึ รอยละ 70 ซึง่ ทําใหเกิดคาใชจาย 80,000 บาท
และอาจทําใหเสียเวลาอีกดวย
เมื่อคํานวณหามูลคาทางการเงินที่คาดหวังของแตละทางเลือกแลว ผูจัดการ
โครงการจะตัดสินใจทางเลือกใดขึ้นอยูกบั ปจจัยอื่นอีก เชน ผูจัดการโครงการเปนกลุมคนประเภทใดดังที่
กลาวในบทนํา ลักษณะของโครงการ หรือความสามารถในการตอรองกับลูกคา เปนตน

รูปที่ 10.7 ตัวอยางตนไมการตัดสินใจ (ปรับปรุงจาก Marchewka, 2006)

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารความเสี่ยงโครงการ หนา 10-17

10.5.6 ความคิดเห็นของผูเชี่ยวชาญ
หลายๆ องคการเชื่อในความรูสึก และประสบการณของผูเชี่ยวชาญในการ
วิเคราะหความเสี่ยงเชิงคุณภาพ ผูเชี่ยวชาญสามารถจัดกลุมความเสี่ยงโดยปราศจากเทคนิคที่ยงุ ยาก
แตทีมงานควรบันทึกความคิดเห็นของผูเ ชีย่ วชาญดวย การประเมินความเสี่ยงดวยวิธีนจี้ ะใชการ
สอบถามผูเชีย่ วชาญวาในการดําเนินโครงการนั้น จะมีเหตุการณที่ไมพึงปรารถนาเหตุการณใดเกิดขึ้น
บาง โอกาสทีจ่ ะเกิดเหตุการณนั้นมีมากนอยเทาใด และผลกระทบจะรุนแรงมากนอยอยางไร
ผูเชี่ยวชาญจะประเมินความเสี่ยงหรือผลกระทบออกมาเปนระดับคือ สูง ปานกลาง หรือต่ํา อยางไรก็
ตาม ผูเชี่ยวชาญแตละคนอาจประเมินเหตุการณเสี่ยงเหตุการณเดียวกันแตกตางกัน ทั้งนี้เนื่องมากจาก
ระดับการยอมรับความเสี่ยงของแตละบุคคลอาจแตกตางกัน

10.6 การวิเคราะหความเสี่ยงเชิงปริมาณ
การวิเคราะหความเสีย่ งเชิงปริมาณเปนการวิเคราะหที่ใชเทคนิคเชิงคณิตศาสตร หรือสถิติ ที่
ชวยใหผจู ัดการโครงการสามารถสรางตัวแบบของสถานการณความเสีย่ งที่สนใจ เทคนิคที่นยิ มนํามาใช
ในการวิเคราะหดวยแนวทางนี้คือ การกระจายความนาจะเปนแบบตอเนื่อง (continuous probability
distribution) การจําลอง (simulation) การวิเคราะหความไว (sensitivity analysis)

10.6.1 การกระจายความนาจะเปนแบบตอเนื่อง
การกระจายความนาจะเปนแบบตอเนื่องที่นยิ มใชคือ การกระจายแบบปกติ
(normal distribution) และการกระจายแบบ PERT (PERT distribution) รูปที่ 10.8 เปนการกระจาย
แบบปกติและสมมาตร ซึง่ มีกฎความนาจะเปนดังนี้
• ประมาณ 68% ของคาทัง้ หมดจะตกในชวงระหวาง ±1σ ของคาเฉลีย่
• ประมาณ 95% ของคาทัง้ หมดจะตกในชวงระหวาง ±2σ ของคาเฉลีย่
• ประมาณ 99% ของคาทัง้ หมดจะตกในชวงระหวาง ±3σ ของคาเฉลีย่

ดังนัน้ ถาเรารูวาความนาจะเปนของเหตุการณเสี่ยงเปนแบบปกติ เราสามารถ

คาดการณผลที่จะเกิดดวยความเชื่อมั่นระดับหนึง่ เชน ถางานของโครงการมีเวลาการทํางานเฉลี่ย 10
วัน มีคาเบี่ยนเบนมาตรฐาน 2 วัน จากกฎดังกลาว เราสามารถประมาณการณไดวา งานของโครงการจะ
เสร็จภายใน 6-14 วัน ดวยความเชื่อมั่น 95 เปอรเซ็นต (μ±2σ = 10±2×2) และเรายังสามารถกลาวไดวา
งานสามารถเสร็จภายใน 4-16 ดวยความเชื่อมั่น 99 เปอรเซ็นต (μ±3σ = 10±3×2)

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารความเสี่ยงโครงการ หนา 10-18

รูปที่ 10.8 การกระจายแบบปกติ (Marchewka, 2006)

สวนการกระจายแบบ PERT นัน้ ตองมีคาประมาณการ 3 คาคือ

a = คาที่คาดคะเนในแงดี (optimistic estimate)
m = คาที่เปนไปไดมากที่สุด (most likely estimate)
b = คาที่คาดคะเนในแงราย (pessimistic estimate)
คาเฉลี่ย PERT = (a+4m+b)/6
คาเบี่ยนเบนมาตรฐาน PERT = (b-a)/6

รูปที่ 10.9 การกระจายแบบ PERT (Marchewka, 2006)

การกระจายแบบ PERT นํามาใชในการคํานวณระยะเวลาที่คาดหวังวากิจกรรมจะแลว

เสร็จ สมมติวา รูปที่ 10.9 เปนตัวอยางของการกระจายของกิจกรรมหนึง่ โดยมีคา a = 2, m = 4 และ b

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารความเสี่ยงโครงการ หนา 10-19

= 8 ดังนัน้ คาเฉลี่ยระยะเวลาของกิจกรรมนั้นเทากับ 4.33 วัน คาเบี่ยนเบนมีคา เทากับ 1 วัน ซึ่ง

หมายความวา มีโอกาสรอยละ 50 ทีก่ จิ กรรมนั้นจะเสร็จกอน 4.33 วัน และมีโอกาสรอยละ 50 ที่
กิจกรรมนัน้ จะเสร็จชากวา 4.33 วัน
นอกจากนี้ การกระจายแบบ PERT ยังชวยใหผูจัดการโครงการทราบวาความนาจะเปน
ที่โครงการจะเสร็จตามเปาหมายที่กาํ หนดมีมากนอยเพียงใด ดังที่ไดกลาวมาแลวในบทที่ 5

10.6.2 การจําลอง
การจําลองเปนวิธกี ารวิเคราะหความเสี่ยงที่สลับซับซอนมาก แบบจําลองที่
นํามาใชในการวิเคราะหพฤติกรรมของระบบคือ การวิเคราะหแบบมอนติ คารโล (Monte Carlo
analysis) ตัวแบบนี้จะจําลองผลลัพธของตัวแบบหลายครั้ง เพื่อการกระจายเชิงสถิติของผลลัพธที่
คํานวณได การวิเคราะหแบบมอนติ คารโล สามารถคาดการณวาความนาจะเปนของโครงการทีจ่ ะเสร็จ
ภายในวันที่กาํ หนด หรือความนาจะเปนทีค่ าใชจายจะเทากับหรือนอยกวาคาที่กําหนด
ตัวอยางในรูปที่ 10.10 คือ ผลจากการจําลองแบบมอนติ คารโลของตารางเวลา
โครงการ ทางซายมือของรูปที่ 10.10 คือ ผังแสดงสมดมภและเสนโคงรูป S ความสูงของแตละสดมภ
หมายถึงจํานวนครั้งที่ (จํานวนตัวอยาง) โครงการเสร็จภายในชวงเวลาที่กําหนดระหวางทีท่ ําการจําลอง
ในตัวอยางนี้ ชวงเวลาที่กาํ หนดคือ 2 วันทําการ และการจําลองทํางาน 250 ครั้ง สดมภแรกแสดงวา
โครงการทําเสร็จใน 1/29/02 เพียง 2 ครั้งระหวางการจําลอง เสนโคงรูป S แสดงความนาจะเปนสะสม
ของโครงการทีเ่ สร็จตามวันหรือกอนวันทีก่ าํ หนด ขางขวาของรูปแสดงขอมูลในแบบตาราง ตัวอยางเชน
มีความนาจะเปนรอยละ 10 ที่โครงการจะทําเสร็จใน 2/8/02 โอกาสที่โครงการทําเสร็จใน 2/17/02 มี
รอยละ 50 และ โอกาสรอยละ 90 ทีโ่ ครงการทําเสร็จใน 2/25/02

รูปที่ 10.10 ตัวอยางการวิเคราะหแบบมอนติ คารโล

สําหรับการจําลองผลลัพธของตารางเวลาโครงการ (Schwalbe, 2006)

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารความเสี่ยงโครงการ หนา 10-20

10.6.3 การวิเคราะหความไว
การวิเคราะหความไวคือ การดูผลกระทบที่เกิดขึ้นกับผลได เมื่อมีการ
เปลี่ยนแปลงตัวแปรหนึง่ หรือมากกวาหนึง่ เชน การจายเงินกูแตละเดือนจะเปนอยางไร ถาอัตราดอกเบี้ย
ที่กําหนดแตกตางกัน หรือระยะเวลาการชําระเงินกูเปลีย่ นไป

รูปที่ 10.11 ตัวอยางการวิเคราะหความไวสําหรับการกําหนดจุดคุมทุน (Schwalbe, 2007)

เราสามารถนําการวิเคราะหความไวมาชวยในการตัดสินใจ เชน นาํ มาใชในการ

วิเคราะหจุดคุมทุนตามสมมุติฐานที่แตกตางกันวาเราควรจะดําเนินงานนัน้ ตอไปหรือไม หรือควรจะใช
เวลาในการดําเนินการเทาไรจึงจะไมขาดทุนเปนตน รูปที่ 10.11 เปนตัวอยางของการใช Excel ในการ
แสดงจุดคุมทุนของสินคา ซึ่งขึ้นอยูก ับราคาขายตอชิ้น คาใชจา ยในการผลิตตอชิ้น และคาใชจายคงที่
รายเดือน จากขอมูลปจจุบนั จุดคุมทุนอยูที่ยอดขาย 6,250 ชิ้น ผูใชสามารถเปลี่ยนขอมูลนําเขา และดู
ผลกระทบที่เกิดขึ้นกับจุดคุมทุนที่อยูในผัง
ทีมงานโครงการสามารถสรางตัวแบบที่คลายคลึงกันนี้ เพื่อกําหนดความไวของ
ตัวแปรตางๆ ของโครงการ เชน ทีมงานอาจสรางตัวแบบการวิเคระหความไว เพื่อประมาณการณกาํ ไร
ของงาน โดยการพิจารณาจากจํานวนชั่วโมงในการทํางานงานนั้น คาใชจายตอชั่วโมง เปนตน

10.7 การวางแผนตอบสนองความเสี่ยง
หลังจากที่องคการไดระบุและประมาณความเสี่ยงแลว เราตองพัฒนาวิธีการตอบสนองความ
เสี่ยงที่เหมาะสม กลยุทธตอบสนองความเสี่ยงดานลบมี 4 กลยุทธคือ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารความเสี่ยงโครงการ หนา 10-21

• การหลีกเลี่ยงความเสีย่ ง (risk avoiding) โดยการขจัดสาเหตุของความเสีย่ ง เชน

ทีมงานไมคุนเคยกับฮารดแวรหรือซอฟตแวร ซึ่งทําใหเกิดความเสี่ยงที่มีนยั สําคัญ
ดังนัน้ การใชฮารดแวรหรือซอฟตแวรที่คนุ เคยเปนการหลีกเลี่ยงความเสี่ยง
• การยอมรับความเสี่ยง (risk acceptance) เนื่องจากโอกาสหรือความนาจะเปนทีจ่ ะ
เกิดเหตุการณเสี่ยงนั้นมีนอยมาก ในทางกลับกัน ในกรณีที่ความนาจะเปนของการเกิด
เหตุการณเสีย่ งอาจจะคอนขางสูง แตสงผลกระทบนอยมากตอเวลาและงบประมาณ
โครงการ ซึง่ ไมคุมกับคาใชจายที่ตองเสียไปในการลดความเสีย่ ง จึงเปนเหตุผลที่
ผูจัดการโครงการตัดสินใจยอมรับความเสีย่ งนั้นไวโดยไมทําอะไร ดังนั้น เพื่อจัดการกับ
ความเสีย่ งในกรณีนี้ ผูจัดการโครงการควรตั้งเงินทุนสํารอง และจัดทําแผนสํารอง
• การโอนความเสี่ยง (risk transfer) หรือยายผลของความเสี่ยงและความรับผิดชอบไป
ยังบุคคลที่สาม เชน การซื้อประกันฮารดแวร ถาเครื่องเสียหาย บริษทั รับประกันตองหา
เครื่องมาทดแทนตามทีก่ ําหนดในสัญญา
• การบรรเทาความเสี่ยง (risk mitigation) หรือลดผลกระทบของความเสี่ยงโดยการลด
ความนาจะเปนของเหตุการณ เชน ใชพนักงานที่มีความชํานาญ การใชเทคนิคการ
วิเคราะหและทดสอบทีห่ ลากหลาย จัดระบบควบคุมและตรวจสอบความกาวหนาของ
งานเปนระยะ ตารางที่ 10.5 แสดงตัวอยางการบรรเทาความเสี่ยงดานเทคนิค
คาใชจาย และตารางการปฏิบัติงาน

ตารางที่ 10.5 ตัวอยางวิธกี ารบรรเทาความเสี่ยง (Schwalbe, 2007)

ความเสี่ยงทางเทคนิค
เนนการสนับสนุนทีมงานและ
หลีกเลี่ยงโครงสรางโครงการแบบโดด
เดี่ยว
เพิ่มอํานาจผูจัดการโครงการ
ปรับปรุงการจัดการปญหาและการ
สื่อสาร
เพิ่มความถี่การติดตามโครงการ
ใชโครงสรางจําแนกงาน และการ
บริหารเสนทางวิกฤต
ความเสี่ยงดานคาใชจาย
เพิ่มความถี่การติดตามโครงการ
ใชโครงสรางจําแนกงาน และการ
บริหารเสนทางวิกฤต
ปรับปรุงการสื่อสาร ความเขาใจ
เปาหมายโครงการ และการสนับสนุน
ทีมงาน
เพิ่มอํานาจผูจัดการโครงการ
ความเสี่ยงดานตารางเวลา
เพิ่มความถี่การติดตามโครงการ
ใชโครงสรางจําแนกงาน และการ
บริหารเสนทางวิกฤต
เลือกผูจัดการโครงการที่มี
ประสบการณมากที่สุด

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารความเสี่ยงโครงการ หนา 10-22

ทันทีทมี่ ีการระบุความเสี่ยงของโครงการและกลยุทธแลว ทีมงานควรจัดทําแผนการ

ตอบสนองความเสี่ยง ซึง่ ประกอบดวยหัวขอตอไปนี้
• ชื่อความเสีย่ ง
• ตัวจุดชนวนความเสีย่ งที่แสดงวาความเสีย่ งนั้นไดเกิดขึน้ หรือยัง
• เจาของความเสี่ยง
• การตอบสนองความเสี่ยง

10.8 การควบคุมและติดตามความเสี่ยง
การควบคุมและติดตามความเสี่ยงเปนการดําเนินการตามกระบวนการบริหารความเสี่ยงและ
แผนบริหารความเสี่ยง เพื่อสนองตอบเหตุการณเสี่ยง การดําเนินตามกระบวนการบริหารความเสี่ยงคือ
การทําใหแนใจวาความเสีย่ งที่ไดระบุไวไดรับการดําเนินการจากทีมงานตลอดโครงการ ความเสี่ยงทีถ่ ูก
ระบุอาจไมมีเนื้อหาสาระ หรือความนาจะเปนของการเกิดความเสีย่ งอาจลดลงได ความเสี่ยงใหมอาจ
เกิดขึ้นขณะทีโ่ ครงการดําเนินการ การกําหนดทรัพยากรใหมอาจมีความจําเปนอันเปนผลจากการ
เปลี่ยนแปลงในขนาดของผลกระทบของความเสีย่ ง
การดําเนินการตามแผนการบริหารความเสี่ยงประกอบดวยการติดตามความเสีย่ งตามหลัก
ไมลที่ไดกําหนดไวและการตัดสินใจโดยคํานึงถึงความเสีย่ ง และกลยุทธการตอบสนองของความเสี่ยง
เหลานี้ มันอาจจําเปนที่ตองปรับเปลี่ยนกลยุทธ ถาความเสี่ยงนัน้ กลับกลายเปนไมมีผล หรือไมปรากฎ
ทีมงานตองนําความเสี่ยงนัน้ ออกจากรายการความเสี่ยงที่มีศกั ยภาพ

ตารางที่ 10.6 ตัวอยางการตามรอยความเสีย่ ง 10 อันดับแรก (Schwalbe, 2007)

การจัดลําดับรายเดือน
หัวขอความเสี่ยง เดือนนี้ เดือนที่ จํานวน ความกาวหนาในการแกความ
แลว เดือน เสี่ยง
การวางแผนไมเพียงพอ 1 2 4 กําลังทําการทบทวนแผนทั้งโครงการ
การนิยามขอบเขตของโครงการ 2 3 3 จัดประชุมกับลูกคาของโครงการและ
ไมดี ผูสนับสนุนเพื่อทําใหขอบเขตของ
โครงการชัดเจน
ขาดผูนํา 3 1 2 เพิ่งกําหนดผูจัดการโครงการคนใหม
หลังจากผูจัดการคนกอนลาออก
การประมาณการคาใชจายไมดี 4 4 3 กําลังทบทวนการประมาณการ
คาใชจาย
การประมาณการเวลาไมดี 5 5 3 กําลังทบทวนการประมาณระยะเวลา

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารความเสี่ยงโครงการ หนา 10-23

การติดตามความเสีย่ งที่อยูใ น10 อันดับแรก (top ten risk tracking) เปนเทคนิคที่ใชในการ

ติดตามความเสี่ยงตลอดโครงการ โดยการกําหนดการทบทวนความเสีย่ งที่สําคัญเปนประจํา ซึ่งอาจจะ
เปนทุกเดือน หรือทุก 2 อาทิตย การทบทวนจะเริ่มจากการสรุปสถานภาพของความเสี่ยง 10 อันดับแรก
ของโครงการ การสรุปประกอบดวยลําดับที่ปจจุบันของความเสี่ยง ลําดับที่กอนหนานี้ จํานวนครั้งที่
ความเสีย่ งนี้ปรากฎ และสรุปความกาวหนาการแกความเสี่ยงตัง้ แตครั้งกอน ดังตัวอยางในตารางที่ 10.6
จากตัวอยางจะเห็นวาความเสี่ยงมีการเปลี่ยนแปลงลําดับที่ทุกเดือน เชน ความเสีย่ งการ
วางแผนไมเพียงพอ เมื่อเดือนที่แลวจัดอยูอันดับที่ 2 แตในเดือนปจจุบันความเสี่ยงนี้ไดเลื่อนเปนอันดับ
แรก และปรากฎมาแลวถึง 4 เดือน สวนความเสีย่ งเรื่องการขาดผูน ํา เมื่อเดือนที่ผา นมาอยูอนั ดับ 1 แต
เมื่อมีการมอบหมายใหผูจัดการโครงการคนใหม ความเสี่ยงนี้เปลี่ยนอันดับเปน 3

10.9 สรุป
ความเสีย่ งคือ ความไมแนนอนที่มีผลกระทบทัง้ ทางบวกและทางลบตอการบรรลุวัตถุประสงค
ของโครงการ โดยธรรมชาติ โครงการมีความเสีย่ ง องคการที่ประสบความสําเร็จตองตระหนักถึงคุณคา
ของการบริหารความเสี่ยงโครงการ การบริหารความเสี่ยงเปนการลงทุน ดังนัน้ จึงมีคาใชจายในการระบุ
ความเสีย่ ง การวิเคราะหความเสี่ยง การกําหนดแผนทีจ่ ะจัดการความเสี่ยงเหลานัน้ คาใชจายรวมถึง
เวลา และการวางแผนทรัพยากร
ระดับการยอมความเสีย่ งหรืออรรถประโยชนความเสี่ยงคือ ขนาดความพึงพอใจที่ไดรับจาก
การจายคืน (payoff) เราจึงแบงคนออกเปนคนที่คนหาความเสีย่ ง คนทีห่ ลีกเลีย่ งความเสีย่ ง และคนที่
เปนกลาง
การบริหารความเสี่ยงคือ กระบวนการที่ทมี งานประเมินผลกระทบความเสีย่ งอยางตอเนื่อง
กําหนดความนาจะเปนของเหตุการณเสีย่ ง และกําหนดผลกระทบ รวมทัง้ การวิเคราะหและกําหนดกล
ยุทธเพื่อจัดการความเสี่ยง กระบวนการบริหารความเสีย่ งมี 6 กระบวนการคือ การวางแผนการบริหาร
ความเสีย่ ง การระบุความเสี่ยง การวิเคราะหความเสี่ยงเชิงปริมาณ การวิเคราะหความเสีย่ งเชิงคุณภาพ
การวางแผนตอบสนองความเสี่ยง และการควบคุมติดตามความเสี่ยง
การวางแผนจัดการความเสีย่ งคือ กระบวนการการตัดสินใจวาจะจัดการความเสีย่ งดวยวิธีใด
และวางแผนกิจกรรมการบริหารความเสี่ยง แผนการบริหารความเสี่ยงคือ ผลลัพธหลักทีไ่ ดจาก
กระบวนการการวางแผนจัดการความเสี่ยง แผนสํารองเปนการกําหนดการกระทําไวลวงหนาทีท่ ีมงาน
โครงการจะทํา ถาเหตุการณเสี่ยงที่ไดระบุไวเกิดขึ้น แผนทางถอยเปนแผนสําหรับความเสี่ยงที่มี
ผลกระทบตอการบรรลุวัตถุประสงคของโครงการสูง และจะถูกดําเนินการถาความพยายามลดความ
เสี่ยงไมมีประสิทธิผล เงินทุนสํารองคือ เงินที่ผูสนับสนุนโครงการหรือองคการมีอํานาจใชเพื่อใชแกไข
ปญหาโครงการใหลดระยะเวลาที่เกินไปจากแผนบริหารโครงการใหกลับไปสูระดับที่ยอมรับได

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารความเสี่ยงโครงการ หนา 10-24

โครงการเทคโนโลยีสารสนเทศมีความเสี่ยงในเรื่องขาดการมีสวนรวมของผูใช ขาดการ
สนับสนุนของผูบริหารระดับสูง ความตองการไมชัดเจน การวางแผนไมดี เปนตน การจําแนกโครงสราง
ความเสีย่ งเปนเครื่องมือที่เปนประโยชนที่จะชวยผูจัดการโครงการพิจารณาความเสี่ยงที่มีศักยภาพใน
กลุมที่แตกตางกัน รายการความเสีย่ งที่พบในโครงการตางๆ สามารถชวยในการระบุความเสี่ยง ดังเชน
เทคนิคการรวบรวมความเสีย่ งอื่น เชน การระดมสมอง เทคนิคเดลฟาย การสัมภาษณ และการวิเคราะห
SWOT ทะเบียนความเสีย่ งคือ เอกสารที่เก็บเหตุการณเสี่ยงที่มีศักยภาพและขอมูลที่เกีย่ วของ ซึง่ แสดง
ในรูปของตาราง เหตุการณเสี่ยงหมายถึงเหตุการณไมแนนอน ที่อาจเกิดขึ้นและทําใหโครงการเสียหาย
หรือทําใหโครงการดีขึ้น
ความเสีย่ งสามารถประเมินไดทั้งแบบเชิงคุณภาพ และแบบเชิงปริมาณ เครื่องมือสําหรับ
วิเคราะหความเสี่ยงคุณภาพประกอบดวย การใชผังความนาจะเปน/ผลกระทบ ตารางผลกระทบความ
เสี่ยง กรอบการจัดกลุมความเสี่ยงของทูสเลอร ตนไมการตัดสินใจ มูลคาทางการเงินที่คาดหวัง และดุลย
พินิจของผูเชี่ยวชาญ เครื่องมือสําหรับการวิเคราะหความเสี่ยงเชิงปริมาณประกอบดวย การกระจาย
ความนาจะเปนตอเนื่อง การจําลอง การวิเคราะหความไว
กลยุทธการตอบสนองความเสี่ยงมี 4 อยางคือ การหลีกเลี่ยง การยอมรับ การโอน และการ
บรรเทา การหลีกเลี่ยงความเสี่ยงคือ การขจัดความเสี่ยง การยอมรับความเสีย่ งหมายถึงการยอมรับผลที่
ตามมาของความเสี่ยง ถาเกิดความเสี่ยงนัน้ การโอนความเสี่ยงคือ การยายผลที่ตามมาของความเสี่ยง
และความนาจะเปนไปยังบุคคลที่สาม การบรรเทาความเสี่ยงคือ การลดผลกระทบของเหตุการณเสี่ยง
โดยการลดความนาจะเปนของการเกิด
การควบคุมและติดตามความเสี่ยงประกอบดวยการดําเนินการตามกระบวนการบริหารความ
เสี่ยงและแผนการบริหารความเสี่ยง เพื่อตอบสนองความเสี่ยง โดยการใชการติดตามความเสีย่ งทีอ่ ยู 10
อันดับแรก ผลของกระบวนการนี้คือ คําขอเปลี่ยนแปลง ขอเสนอแนะใหแกไข การกระทําเพื่อการปองกัน
และปรับปรุงทะเบียนความเสี่ยง แผนการบริหารความเสี่ยง

คําถามทายบท
1. พิจารณาความเสี่ยงที่พบในโครงการเทคโนโลยีสารสนเทศ แลวเสนอแนะการบริหารจัดการ
ความเสีย่ งเหลานัน้ ความเสี่ยงใดทีท่ านคิดวาไมเขากับองคการทานมากที่สุด และทําไม
2. จงเปรียบเทียบความแตกตางของวิธีการระบุความเสี่ยงระหวางการระดมสมองกับเทคนิค
เดลไฟ ขอดีขอเสียของแตละวิธี
3. อธิบายเนื้อหาของทะเบียนความเสีย่ ง

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารความเสี่ยงโครงการ หนา 10-25

4. อธิบายการวิเคราะหความเสี่ยงเชิงคุณภาพดวยการใชผงั ความนาจะเปน/ผลกระทบ ตาราง

ผลกระทบความเสี่ยง และกรอบการจัดแยกความเสี่ยงของทูสเลอร
5. อธิบายการวิเคราะหความเสี่ยงเชิงปริมาณดวยการใชการกระจายความนาจะเปนตอเนื่อง
6. จงอธิบายกลยุทธการตอบสนองความเสีย่ งแตละอยาง

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการจัดซื้อจัดจาง หนา 11-1

11.1 บทนํา
การจัดซื้อจัดจางหรือการสั่งซื้อหมายถึง การไดมาซึ่งสินคาหรือบริการจากแหลงภายนอก
องคการ ซึง่ ชุมชนดานเทคโนโลยีสารสนเทศเรียกวาการจัดซื้อจากแหลงภายนอก (outsourcing)
หลายๆ องคการใชบริการจากแหลงภายนอกเพื่อลดคาใชจายทั้งคาใชจายคงที่และที่เกิดขึ้นใหม มีเวลา
กับธุรกิจหลักขององคการ สามารถเขาถึงเทคโนโลยีและทักษะเฉพาะ และทําใหเกิดความยืดหยุน
องคการหรือทีมงานโครงการสามารถใชบริการจากแหลงภายนอกได 3 วิธีใหญคือ
• เลือกใชบริการเฉพาะสวนทีข่ าด องคการหรือทีมงานขาดคนทีม่ ีทกั ษะเฉพาะ จึงใช
บริการผูเชี่ยวชาญจากแหลงภายนอกโดยใหเขามาเปนสมาชิกในทีม การบริหาร
จัดการยังคงเปนขององคการที่ใชบริการ
• เลือกตัดเฉพาะบางสวนของโครงการใหผูใหบริการรับผิดชอบดําเนินการ เนื่องจาก
โครงการที่องคการหรือทีมงานกําลังดําเนินการมีขนาดใหญ จึงแบงงานบางสวนของ
โครงการใหผูใหบริการรับไปดําเนินการ โดยผูใหบริการรับผิดชอบในงานสวนนั้น
• ใชบริการจากแหลงภายนอกองคการทั้งหมด องคการไมดําเนินโครงการเองแตจางให
บริษัทอื่นรับผิดชอบไปดําเนินทัง้ หมด

ความสําเร็จของโครงการเทคโนโลยีสารสนเทศหลายโครงการที่ใชการจัดซื้อจากแหลงภาย
นอกขึ้นกับการบริหารการจัดซื้อจัดจางทีด่ ี การบริหารการจัดซื้อจัดจางประกอบดวยกระบวนการ 6
กระบวนการคือ
• การวางแผนการซื้อและการไดมา (planning purchases and acquisitions) เปน
การกําหนดวาอะไรที่ตองจัดซื้อ ซื้อเมื่อไร และจะจัดซือ้ อยางไร ในการวางแผนการ
จัดซื้อจัดจาง ผูจัดการโครงการตองตัดสินใจวาอะไรที่ตองใชบริการจากแหลง
ภายนอก กําหนดประเภทของสัญญา และอธิบายงานสําหรับผูขายทีม่ ีศักยภาพ ผล
ที่ไดจากกระบวนการนี้คือ แผนการบริหารการจัดซื้อจัดจาง งานที่กาํ หนดในสัญญา
การตัดสินใจวาจะทําเองหรือไม

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการจัดซื้อจัดจาง หนา 11-2

• การวางแผนการทําสัญญา (planning contracting) เปนกระบวนการที่อธิบายถึง

ความตองการของสินคาหรือบริการจากการจัดซื้อจัดจาง และการระบุผูขายที่มี
ศักยภาพ ผลลัพธจากกระบวนการคือ เอกสารการจัดซื้อจัดจาง เชน คํารองขอ
ขอเสนอโครงการ หลักเกณฑการประเมิน และการปรับปรุงงานในสัญญา
• การขอคําตอบจากผูขาย (requesting seller responses) เปนกระบวนการรับ
ขอมูลขาวสาร ขอเสนอราคา การประมูล ขอเสนอโครงการจากผูขาย ผลจาก
กระบวนการนีค้ ือ รายชื่อผูขายที่มีคุณสมบัติเหมาะสม ชุดเอกสารการจัดซื้อจัดจาง
และขอเสนอโครงการหรือขอเสนอราคา
• การเลือกผูขาย (selecting sellers) เปนการเลือกผูข ายที่มีศกั ยภาพจากรายชื่อ
โดยกระบวนการการประเมิน การตอรองสัญญา ผลที่ไดคือ ผูขายที่ไดรับการคัดเลือก
สัญญา แผนการบริหารสัญญา
• การบริหารสัญญา (administrating the contract) เปนการบริหารความสัมพันธกบั
ผูขายที่ไดรับการคัดเลือก ผลที่ไดคือ เอกสารสัญญา
• การปดสัญญา (closing the contract) เมื่องานไดดําเนินการเสร็จสมบูรณ ประเด็น
ตางๆ ที่ไดมีการกลาวถึงไดรบั การแกไข สัญญาจึงถูกปด

11.2 การวางแผนการซื้อและการไดมา
การวางแผนการซื้อและการไดมาประกอบดวยการระบุวา โครงการตองการอะไร ตองการ
จัดซื้อหรือไม จัดซื้ออยางไร อะไรที่ตองจัดซื้อ จํานวนเทาไร และเมื่อไรจึงจัดซื้อ ผลลัพธสําคัญของ
กระบวนการนีค้ ือ การตัดสินใจวาจะทําเองหรือจะซื้อ การตัดสินใจวาจะจัดซื้อจากแหลงภายนอกขึ้นกับ
ปจจัยหลายประการ ผูจ ัดการโครงการและทีมงานตองพิจารณาปจจัยหลายๆ ปจจัย เชน สินคาและ
บริการมีในตลาดหรือไม คาใชจาย คุณภาพ เงื่อนไข งบประมาณ ทรัพยากร ผูเชี่ยวชาญ ระยะเวลา และ
ขอจํากัดดานเทคโนโลยี จากปจจัยดังกลาว กลุมบุคคลนอกองคการอาจใหบริการทีด่ ีกวา
ขอมูลที่จําเปนของการวางแผนการซื้อและการไดมาคือ ขอบเขตของโครงการ พจนานุกรม
โครงสรางจําแนกงาน แผนการบริหารโครงการ และสารสนเทศที่เกีย่ วของ สวนเทคนิคและเครื่องมือที่จะ
ชวยใหผจู ัดการโครงการและทีมงานในการวางแผนการซือ้ และการไดมาคือ การวิเคราะหวาจะทําเอง
หรือซื้อ ดุลยพินิจของผูเชีย่ วชาญ และประเภทของสัญญา

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการจัดซื้อจัดจาง หนา 11-3

11.2.1 การวิเคราะหวาจะทําเองหรือซื้อ
การวิเคราะหวา จะทําเองหรือซื้อเปนเทคนิคการบริหารทีใ่ ชในการกําหนดวา
องคการควรทําสินคาหรือบริการภายในองคการหรือควรซื้อจากที่อื่น รูปแบบการวิเคราะหประกอบดวย
การประมาณการคาใชจายที่เกิดขึ้นจากการใหแหลงภายในทําสินคาหรือบริการนัน้ และการ
เปรียบเทียบระหวางคาใชจา ยที่แหลงภายใชในการทําสินคาหรือบริการกับคาใชจา ยจากการใชบริการ
จากแหลงภายนอก ถาผูใ หบริการคิดราคานอยกวาคาใชจายที่เกิดขึ้นจากการทีอ่ งคการดําเนินการเอง
องคการควรเลือกใชบริการภายนอก
หลายๆ องคการยังใชวิธกี ารนี้ในการตัดสินใจวาองคการควรซื้อหรือเชาสินคา
เชน ถาโครงการจําเปนตองใชอุปกรณ ซึ่งถาซื้อจะตองใชเงิน 120,000 บาท และมีคาใชจายการ
ปฎิบัติงาน อีกวันละ 2,000 บาท แตถา เชาอุปกรณนี้จะตองจายวันละ 8,000 บาท โดยรวมคาใชจาย
การปฎิบัติงานแลว เราสามารถสรางสมการไดดังนี้

8000d = 120,000 + 2000d

6000d = 120,000
d = 20

ถาโครงการตองการใชอุปกรณนอยกวา 20 วัน องคการควรตัดสินใจเชาอุปกรณ

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

11.2.3 ประเภทของสัญญา
ประเภทของสัญญาเปนสิง่ สําคัญที่ตองพิจารณา ประเภทของสัญญาที่แตกตาง
กันสามารถนํามาใชในสถานการณที่แตกตางกัน สัญญาแบงออกเปน 4 ประเภทคือ สัญญาแบบราคา
คงที่ (fixed-price) หรือเปนเงินกอน (lump sum) สัญญาแบบเบิกตามคาใชจา ย (cost reimbursable)
สัญญาที่จา ยตามเวลาและวัสดุ (time and material) และสัญญาแบบราคาตอหนวย ในสัญญาหนึ่ง

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการจัดซื้อจัดจาง หนา 11-4

อาจประกอบดวยการคิดคาใชจายหลายประเภท เชน ในสัญญาอาจมีการซื้อฮารดแวรเปนแบบราคา

คงที่ มีบางบริการที่เบิกตามคาใชจาย และมีบริการที่คิดคาใชจายตามเวลาและวัสดุ

สัญญาแบบราคาคงที่ หรือเปนเงินกอน
เปนสัญญาที่ใชกับสินคาหรือบริการที่ไดกาํ หนดขอบเขตงานที่ชัดเจน ผูซื้อ
จะมีความเสี่ยงเล็กนอย เนื่องจากราคาไดถูกกําหนดกอน เชน โครงการจําเปนตองใชเครื่องพิมพจํานวน
100 เครื่อง โดยมีคุณสมบัติที่ชัดเจน ผูขายหลายเจาสามารถคํานวณราคาคงที่ได สัญญาแบบราคาคงที่
อาจมีเงินจูงใจใหผูขายดําเนินการไดตรงหรือมากกวาวัตถุประสงคของโครงการ เชน สัญญาอาจมีการ
จายคาธรรมเนียมจูงใจ ถาเครื่องพิมพสามารถสงมอบไดภายใน 1 เดือน ลักษณะของสัญญาแบบนี้
เรียกวาสัญญาแบบราคาคงที่และคาธรรมเนียมจูงใจ (fixed –price incentive contract (FPI))

สัญญาแบบเบิกตามคาใชจาย
เปนสัญญาทีจ่ ายคาใชจา ยจริงทัง้ ทางตรงและทางออมใหกับผูขายหรือผู
ใหบริการ ตัวอยางคาใชจายทางตรง เชน คาจางพนักงานทีท่ ํางานใหกับโครงการโดยตรง คาวัสดุ และ
คาอุปกรณ เปนตน สวนตัวอยางคาใชจา ยทางออม เชน คาจางพนักงานบริหารงานทัว่ ไป คาเชา คา
สาธารณูปโภค และคาประกันภัย เปนตน นอกจากนี้ สัญญาประเภทนีย้ ังรวมคาธรรมเนียม เชน
ผลตอบแทนคิดเปนรอยละของคาใชจายทัง้ หมด หรือเงินจูงใจเพื่อใหผูขายหรือผูใหบริการทํางานใหตรง
กับวัตถุประสงคของโครงการ คาธรรมเนียมอาจเปนคาปรับ ถาทํางานไดไมสอดคลองกับทีก่ ําหนด
สัญญาแบบนี้ ผูซื้อเปนฝายรับความเสี่ยงมากกวาสัญญาแบบราคาคงที่ สัญญาแบบเบิกตามคาใชจาย
ยังมีอีก 3 แบบยอย ดังตอไปนี้โดยเรียงจากแบบทีม่ ีความเสี่ยงต่ําสุดไปสูงสุดจากมุมมองของผูซอื้
• สัญญาแบบเบิกตามคาใชจายรวมกับคาธรรมเนียมจูงใจ (Cost Plus
Incentive Fee Contract (CPIF)) ภายใตสัญญานี้ ผูขายเบิก
คาใชจายตามที่เกิดขึ้นจริงระหวางการปฏิบัติงาน และไดรับ
คาธรรมเนียมตามที่ไดตกลงลวงหนา พรอมโบนัสจูงใจในกรณีที่
คาใชจายจริงนอยกวาคาใชจายที่คาดไว ทัง้ ผูซื้อและผูขายตางได
ประโยชนจากการประหยัดคาใชจาย ตัวอยางเชน ถาคาดวาคาใชจา ย
ทั้งโครงการประมาณ 1,000,000 บาท คาธรรมเนียมของผูขายคือ
100,000 บาท และมีขอตกลงวาผูซื้อรับ 85% ของสวนที่ตางระหวาง
คาใชจายจริงกับคาใชจายทีค่ าดวาจะเกิด สวนผูขายรับอีก 15% ที่
เหลือ ถาคาใชจายจริงคือ 800,000 บาท คาใชจายสวนตางจากที่คาด
คือ 200,000 บาท ผูขายจะไดรับคือ 100,000 + 30,000 (15% ของ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการจัดซื้อจัดจาง หนา 11-5

200,000) ดังนั้นคาใชจายทั้งหมดที่ผซู ื้อตองจายคือ 930,000 บาท ซึ่ง

ประหยัดไป 70,000 บาท สวนผูขายไดรับเพิ่มอีก 30,000 บาท
• สัญญาแบบเบิกตามคาใชจายรวมกับคาธรรมเนียมคงที่ (Cost Plus
Fixed Fee Contract (CPFF)) ในกรณีนี้ ผูซื้อจายเงินใหกับผูขาย
ตามคาใชจายที่เกิดขึ้นทั้งหมดรวมกับคาธรรมเนียมคงที่ โดยกําหนด
เปนรอยละของคาใชจายทัง้ หมด คาธรรมเนียมนี้จะไมเปลี่ยน ยกเวน
กรณีท่ขี อบเขตของงานมีการเปลี่ยนแปลง เชน สมมติวาคาใชจายของ
โครงการคือ 1,000,000 บาท และคาธรรมเนียมอีก 10% เปนเงิน
100,000 บาท ถาคาใชจา ยของโครงการเพิ่มเปน 1,200,000 บาท
โดยขอบเขตงานไมมกี ารเปลี่ยนแปลง ผูข ายยังคงไดรับคาธรรมเนียม
การทํางาน 100,000 บาทเทาเดิม
• สัญญาแบบเบิกคาใชจายรวมกับคาธรรมเนียมที่คิดจากรอยละของ
คาใชจายทั้งหมด (Cost Plus Percentage of Costs Contract
(CPPC)) ผูซื้อจายคาใชจายในการทํางานพรอมกับคาธรรมเนียมที่
คิดจากรอยละของคาใชจายทั้งหมด โดยรอยละนี้จะกําหนดไว
ลวงหนา เชน ถาสัญญากําหนดวาจะจายคาธรรมเนียมรอยละ 15
ของคาใชจายทั้งหมด เมือ่ จบโครงการแลวคาใชจายจริงเปน
1,000,000 บาท ผูซื้อตองจายคาใชจายจริงรวมกับคาธรรมเนียมอีก
150,000 บาท สัญญาแบบนี้จะไมเกิดแรงจูงใจใหผูขายพยายามลด
คาใชจายจริง ผูซึ้อจึงตองรับความเสีย่ งทั้งหมด

สัญญาแบบจายตามเวลาและวัสดุ
เปนสัญญาทีผ่ สมผสานระหวางสัญญาแบบราคาคงทีก่ ับสัญญาแบบเบิก
ตามคาใชจาย ภายใตสัญญานี้ ผูซื้อจายเงินใหกบั ผูขายตามเวลาและวัสดุที่ตองใชในการทําใหงานเสร็จ
สมบูรณ เชน บริษทั แหงหนึ่งมีสัญญากับบริษทั ใหคําปรึกษาทางดานเทคโนโลยีสารสนเทศชัว่ โมงละ
1,000 บาท และคาวัสดุเฉพาะสําหรับโครงการอีก 100,000 บาท การเบิกคาวัสดุตอ งมีใบเสร็จรับเงินที่
ผานการอนุมตั ิ และเบิกไดไมเกิน 100,000 บาท ที่ปรึกษาอาจสงใบแจงหนี้เปนรายอาทิตยหรือรายเดือน
โดยระบุรายการคาวัสดุ จํานวนชัว่ โมงทีใ่ ชในการทํางาน และงานที่ไดทํา สัญญาประเภทนีใ้ ชกับงาน
บริการทีง่ านไมสามารถระบุไดชัดเจน และไมสามารถประมาณการคาใชจายทั้งหมดได

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการจัดซื้อจัดจาง หนา 11-6

สัญญาแบบราคาตอหนวย
เปนสัญญาทีผ่ ูซื้อจายเงินใหผูขายตามราคาตอหนวยของสินคาหรือ
บริการที่ไดกําหนดไวลว งหนา สวนใหญสญ
ั ญาประเภทนี้จะคิดราคาตามปริมาณ เชน ถาซื้อ 10 หนวย
ราคา 900 บาทตอหนวย ถาซื้อมากกวา 50 หนวย ราคาหนวยละ 800 บาท

รูปที่ 10.1 เปรียบเทียบความเสีย่ งตามประเภทสัญญา (Schwalbe, 2007)

รูปที่ 10.1 แสดงภาพสรุปเปรียบเทียบความเสีย่ งสําหรับผูซื้อและผูขาย ตาม

ประเภทของสัญญา ผูซื้อจะรับความเสีย่ งต่ําที่สุดถาสัญญาเปนแบบราคาคงที่ เพราะผูซื้อรูแนชัดวา
ตองการอะไร ผูซื้อจะมีความเสี่ยงสูงที่สดุ ถาใชสัญญาแบบคาใชจายรวมกับคาธรรมเนียมที่คิดจากรอย
ละของคาใชจา ย (CPPC) เพราะผูซื้อไมรูสิ่งที่ตองจาย และไมมีสงิ่ จูงใจใหผูขายลดคาใชจาย ในทาง
ตรงกันขาม ถามองในฐานะผูขาย สัญญาแบบคาใชจายรวมกับคาธรรมเนียมที่คิดจากรอยละของ
คาใชจายจะมีความเสีย่ งต่ําสุด และความเสี่ยงสูงสุดถาใชสัญญาแบบราคาคงที่
องคการทีซ่ ื้อบริการควรประเมินงานที่ผูรับจางทําทุกวันหรือทุกอาทิตย เพื่อ
ตัดสินใจวาควรจะใชที่ปรึกษาเจาเดิมหรือไม ในกรณีนี้ สัญญาควรรวมเงื่อนไขการยุติสัญญาทัง้ ในดาน
ผูซื้อและผูขายดวย ผูซ ื้อควรระบุอัตราคาใชจายตอชัว่ โมงตามระดับการศึกษาและประสบการณของที่
ปรึกษา
จากกระบวนการวางแผนการซื้อและการไดมา ผลที่ไดจากกระบวนการนี้คือ
แผนการบริหารการจัดซื้อจัดจาง และขอกําหนดของงานในสัญญา

11.2.4 แผนการบริหารการจัดซือ้ จัดจาง

แผนการบริหารการจัดซื้อจัดจางคือ เอกสารที่อธิบายวากระบวนการจัดซื้อจัด
จางจะบริหารอยางไร ในแผนนี้จะประกอบดวยหัวขอตอไปนี้
• ประเภทสัญญาทีน่ ํามาใช
• ใครเปนผูเตรียมการประเมินผูขาย

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการจัดซื้อจัดจาง หนา 11-7

• เอกสารการจัดซื้อจัดจางที่เปนมาตรฐาน หรือรูปแบบมาตรฐาน
• กําหนดแนวทางสําหรับสรางโครงสรางงานของสัญญา รายการงาน และ
เอกสารการจัดซื้อจัดจางอืน่ ๆ
• บทบาทหนาทีค่ วามรับผิดชอบของทีมงาน และหนวยงานที่เกี่ยวของ เชน
ฝายจัดซื้อจัดจาง และฝายกฎหมาย เปนตน
• ขอแนะนําในการบริหารผูใหบริการหลายราย
• กระบวนการสําหรับการประสานการตัดสินใจการจัดซื้อจัดจาง (เชน ทํา
เองหรือซื้อ) กับสวนอื่น (เชน การจัดตารางเวลา การรายงานผลการ
ดําเนินงาน)
• ขอจํากัดและสมมุติฐานที่เกี่ยวกับการซื้อและการไดมา
• เวลาที่ตองใชในการซื้อและการไดมา
• กําหนดแบบฟอรม และรูปแบบสําหรับขอกําหนดของงานตามสัญญา
• กลยุทธในการบรรเทาความเสี่ยง เชน เงิน สัญญาประกันความเสี่ยง
• แนวทางในการกําหนดผูขายที่มีคุณสมบัติ
• ตัววัดการจัดซือ้ จัดจาง เพื่อใชในการประเมินผูขาย และบริหารสัญญา

11.2.5 ขอกําหนดของงานในสัญญา
ขอกําหนดของงานคือ คําอธิบายงานที่ตอ งการจัดซื้อจัดจาง คําอธิบายงานควรมี
รายละเอียดเพียงพอที่ผูขายสามารถกําหนดราคาที่เหมาะสมกับสินคาหรือบริการทีอ่ งคการตองการ
ขอกําหนดของงานควรชัดเจน ถูกตอง และสมบูรณเทาที่เปนไปได รวมทัง้ การรายงานการปฏิบัติงาน คํา
ที่ใชในสัญญาตองเหมาะสม เชน “อาจ” กับ “ตอง” คําศัพทที่ใชควรเปนคําศัพทที่คนในวงการใชกัน
รวมทัง้ การอางถึงมาตรฐานอุตสาหกรรม หลายองคการใชตัวอยางหรือแบบสําหรับสรางขอกําหนดของ
งาน ซึ่งประกอบดวยหัวขอตอไปนี้
• ขอบเขตของงาน
• สถานทีท่ ํางาน
• ชวงเวลาปฏิบตั ิงาน
• ตารางการสงงาน
• มาตรฐานที่สามารถนํามาใช
• เงื่อนไขการยอมรับ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการจัดซื้อจัดจาง หนา 11-8

• ความตองการพิเศษ

11.3 การวางแผนการทําสัญญา
การวางแผนการทําสัญญาเกี่ยวของกับการเตรียมเอกสารที่จําเปนสําหรับผูขายที่มีศกั ยภาพ
เพื่อใหผูขายนําไปเตรียมขอเสนอโครงการ ทีมงานนิยมใชแบบฟอรมมาตรฐาน และความคิดเห็นของ
ผูเชี่ยวชาญในการสรางเอกสารการจัดซื้อจัดจางที่เกี่ยวของ รวมทัง้ เงือ่ นไขสําหรับการประเมินขอเสนอ
โครงการ เอกสารที่จัดทําขึน้ คือ คํารองขอขอเสนอโครงการ (request for proposal (RFP)) และคํารอง
ขอขอเสนอราคา (request for quote (RFQ))
ขอเสนอโครงการคือ เอกสารที่เตรียมโดยผูขาย ซึง่ ใชในกรณีที่มวี ิธกี ารหลายวิธีทสี่ อดคลอง
กับความตองการของผูซื้อ เชน ถาองคการหนึง่ ตองการใหการทํางานเปนแบบอัตโนมัติ หรือตองการหา
คําตอบใหกับปญหาทางธุรกิจ องคการสามารถเขียนคํารองขอขอเสนอโครงการ (RFP) ดังนั้น ผูขาย
สามารถตอบสนองขอเสนอโครงการนั้นได ผูขายอาจเสนอฮารดแวรตางๆ ซอฟตแวร และเครือขายที่ตรง
กับความตองการของผูซื้อ การเลือกผูชนะจะใชเงื่อนไขที่หลากหลาย ไมใชเพราะราคาต่ําสุด
สวนคํารองขอขอเสนอราคา (RFQ) คือ เอกสารที่ใหผูขายใชประมาณราคาหรือประมูลราคา
(bid) เพื่อจัดทําเปนขอเสนอราคา ขอเสนอราคาจึงเปนเอกสารที่เสนอราคาสําหรับสินคาหรือบริการที่
เตรียมโดยผูขาย เชน ถาองคการตองการซื้อคอมพิวเตอรสวนบุคคล 100 ตัว โดยมีคุณลักษณะเฉพาะ
องคการอาจออกเอกสารคํารองขอขอเสนอราคาไปยังผูข ายที่มีศกั ยภาพ การเตรียมคํารองขอขอเสนอ
ราคาใชเวลานอยกวาการเตรียมคํารองขอขอเสนอโครงการ สวนการเลือกผูชนะจะเลือกผูเสนอราคา
ต่ําสุด
การเขียนคํารองขอขอเสนอโครงการที่ดีเปนสวนที่สาํ คัญของการบริหารการจัดซื้อจัดจาง
เพื่อใหแนใจวาคํารองขอขอเสนอโครงการมีขอมูลเพียงพอที่จะทําใหไดขอเสนอโครงการที่ดี ผูซื้อควรคิด
วาตัวเองเปนผูขาย แลวถามตัวเองวาขอมูลที่มีในคํารองขอขอเสนอโครงการนั้นทําใหเราสามารถ
ประมาณราคา เวลาที่ใชสาํ หรับงานหรือไม รูปแบบของ คํารองขอขอเสนอโครงการประกอบดวยหัวขอ
ตอไปนี้
• วัตถุประสงคของคําขอขอเสนอโครงการ
• ขอมูลขององคการ
• ความตองการพื้นฐาน
• สภาพแวดลอมดานฮารดแวรและซอฟตแวร
• คําอธิบายกระบวนการขอขอเสนอโครงการ
• รายการของงาน และขอมูลเกี่ยวของ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการจัดซื้อจัดจาง หนา 11-9

• ภาคผนวก
ƒ ภาพรวมของระบบปจจุบัน
ƒ ความตองการของระบบ
ƒ ขนาดขอมูล
ƒ เนื้อหาที่ตองการใหผูขายระบุในขอเสนอโครงการ
ƒ ตัวอยางสัญญา

11.4 การขอคําตอบจากผูขาย
หลังจากการวางแผนสําหรับการทําสัญญาแลว กระบวนการบริหารการจัดซื้อจัดจางตอไปคือ
การตัดสินใจวาควรใหใครทํางาน การสงเอกสารไปยังผูขายที่มีศกั ยภาพ และการไดขอเสนอโครงการ
หรือขอเสนอราคา สําหรับการจัดซื้อจัดจางขนาดใหญนั้น องคการนิยมจัดประชุมเพื่อตอบคําถาม
เกี่ยวกับงาน ผลลัพธที่ไดจากกระบวนการนี้คือ ชุดเอกสาร รายชื่อผูขายทีม่ ีคุณสมบัติตามที่ตองการ
และขอเสนอโครงการหรือขอเสนอราคาทีไ่ ดจากผูขายทีม่ ีศักยภาพ
บางครั้งผูขายเฉพาะรายอาจเปนทางเลือกแรกขององคการ ในกรณีนี้ องคการสามารถสง
ขอมูลการจัดซือ้ จัดจางไปยังผูขายรายนั้นได ถาผูขายทีเ่ ราชื่นชอบตอบสนองความตองการได ทั้งสอง
บริษัทสามารถดําเนินงานไปดวยกันได หลายๆ องคการไดสรางความสัมพันธการทํางานกับผูขาย
จํานวนหนึ่งแลว ดังนัน้ บริษัทจึงตองการที่จะทํางานรวมกันตอไป อยางไรก็ตาม ในหลายๆ กรณี อาจมี
ผูขายมากกวา 1 ราย ที่มคี ุณสมบัติที่จะจัดหาสินคาหรือบริการที่ดี การใหขอมูลและการรับขอเสนอ
ราคาจากหลายแหลงใหประโยชนในแงของการแขงขัน

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

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการจัดซื้อจัดจาง หนา 11-10

ตารางที่ 10.1 ตัวอยางแบบฟอรมการประเมินผูขาย (Schwalbe, 2007)

น้ําหนัก ขอเสนอที่ 1 ขอเสนอที่ 2 ขอเสนอที่ 3
หลักเกณฑ
(%) อัตรา คะแนน อัตรา คะแนน อัตรา คะแนน
วิธีทางเทคนิค 30
วิธีการบริหาร 30
ผลการดําเนินงานที่ผานมา 20
ราคา 20
คะแนนรวม 100

สิ่งที่สาํ คัญอีกประการหนึ่งทีอ่ งคการควรเตรียมการคือ แบบฟอรมการประเมิน และ

หลักเกณฑการประเมิน ซึ่งควรออกกอนทีจ่ ะสงคํารองขอขอเสนอหรือคํารองขอขอเสนอราคา องคการใช
หลักเกณฑที่กาํ หนดในการใหคะแนนขอเสนอโครงการ และโดยปกติหลักเกณฑแตละขอจะใหนา้ํ หนักที่
แตกตางกันตามความสําคัญตอโครงการ เชน ขอเสนอทางเทคนิคให 30% วิธีการบริหารให 30%
ประสบการณให 20% และราคาอีก 20% เปนตน ดังแสดงในตารางที่ 10.1 ระหวางที่กาํ ลังคัดเลือกผู
ชนะ ผูซ ื้อควรมีการตอรองผูข าย รวมทัง้ ใหผูขายเตรียมขอเสนอที่ดที ี่สดุ และเปนขอเสนอสุดทาย

11.6 การบริหารสัญญา
การบริหารสัญญาเปนการดําเนินการเพือ่ ใหแนใจวาการทํางานของผูขายตรงกับความ
ตองการในสัญญา การเขียนและการบริหารสัญญาตองทําใหถกู ตองตามกฎหมาย ดังนั้น จึงตองใชมอื
อาชีพทางกฎหมายมาดําเนินการ
ผูจัดการโครงการหลายๆ คนมีความรูเล็กนอยเกีย่ วกับการบริหารสัญญา เพื่อใหทกุ คนเขาใจ
ความสําคัญของการบริหารการจัดซื้อจัดจางที่ดี ผูจัดการโครงการ สมาชิกทีมงานและผูใชควรเขาไปมี
สวนรวมในการเขียนและบริหารสัญญา ทีมงานควรหาผูเชี่ยวชาญเพือ่ ใหคําปรึกษาเกี่ยวกับประเด็นใน
สัญญา สมาชิกในทีมตองตระหนักถึงปญหาเชิงกฎหมายที่อาจเกิดจากความไมเขาใจสัญญา เชน
โครงการสวนใหญมีการเปลีย่ นแปลง การเปลี่ยนแปลงนี้ตองจัดการใหเหมาะสมภายใตสัญญา ถา
ผูจัดการโครงการไมเขาใจเงื่อนไขของสัญญา ผูจ ัดการโครงการอาจไมรูวาไดมอบหมายใหผูรับงาน
ทํางานเพิม่ โดยมีคาใชจายเพิ่มตามดวย ดังนัน้ การควบคุมการเปลี่ยนแปลงจึงเปนสิง่ สําคัญของ
กระบวนการบริหารสัญญา
ผูจัดการโครงการและทีมงานควรกําหนดใหการเปลีย่ นแปลงตองเปนแบบทางการ ใบสั่งการ
เปลี่ยนแปลงใดๆ ตองไดรับอนุญาตโดยผูที่มีอํานาจ ถาผูมีอาํ นาจสั่งเปลี่ยนรายงานที่ไดรับอนุมัติจาก
ผูจัดการโครงการแลว ผูรับจางสามารถดําเนินการตามที่ผูมีอํานาจมอบหมายและสามารถคิดคาใชจาย

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการจัดซื้อจัดจาง หนา 11-11

ได ตอไปนี้เปนขอแนะนําที่ชวยใหแนใจวามีการควบคุมการเปลี่ยนแปลงเพียงพอ และมีการบริหาร

สัญญาที่ดี
• การเปลี่ยนสวนใดๆ ของโครงการจําเปนตองมีการทบทวน อนุมัติ และบันทึก โดย
คนๆ เดียว และดวยวิธีการเดียวกับที่สวนนั้นเคยไดรับการอนุมัติ
• การประเมินการเปลี่ยนแปลงควรรวมการวิเคราะหผลกระทบ เชน การเปลี่ยนแปลง
จะกระทบขอบเขตโครงการ คาใชจาย เวลา และ คุณภาพของสินคาและบริการ
อยางไร
• การเปลี่ยนแปลงตองมีการบันทึกเปนเอกสาร สมาชิกของทีมควรบันทึกการปรชุม
และการพูดทางโทรศัพทที่สาํ คัญ ทัง้ หมด
• เมื่อมีการซื้อระบบสารสนเทศที่สลับซับซอน ผูจัดการโครงการและทีมงานตองทํางาน
ใกลชิดกับผูรับจาง เพือ่ ใหแนใจวาระบบใหมสามารถตอบสนองความตองการได
และสามารถทํางานไดในสภาวะแวดลอมของผูปฎิบัติงาน
• มีแผนสํารองในกรณีที่ระบบใหมไมสามารถทํางานไดตามแผน
• มีเครื่องมือ และเทคนิคทีส่ ามารถชวยการบริหารสัญญา เชน ระบบควบคุมการ
เปลี่ยนแปลงสัญญาอยางเปนทางการ การตรวจสอบ และการตรวจตราอยาง
ละเอียด การรายงานการปฎิบัติงาน การบริหารเอกสารตางๆ และการใชเทคโนโลยี
สารสนเทศ

11.7 การปดสัญญา
กระบวนการสุดทายของการบริหารการจัดซื้อจัดจางคือ การปดสัญญา ซึง่ จะทําไดก็ตอเมื่อ
งานตามสัญญาเสร็จครบถวนสมบูรณ และปดประเด็นตางๆ ที่ไดมีการเปดไว ทีมงานโครงการควร
พิจารณาวางานที่ตองการสมบูรณ ถูกตอง และเปนที่พอใจ นอกจากนี้ ทีมงานควรปรับปรุงเอกสารตางๆ
ใหทนั สมัย และเก็บไวใชในอนาคต
การปดสัญญาเกิดขึ้นเมื่อผูข ายหรือผูรับจางแจงผูซ ื้อเปนทางการวาไดมีการสงมอบผลงานทัง้
หมดตามสัญญา และผูซอื้ มีหนังสือแจงผูขายเปนทางการวางานทัง้ หมดไดรับ และผลงานเปนทีพ่ อใจ
แตสัญญาอาจยุติ เมื่อฝายใดฝายหนึ่งไมทํางานตามที่ไดตกลงกันในสัญญา ฝายทีเ่ สียหายมีสิทธิที่
เรียกรองคาเสียหาย

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการจัดซื้อจัดจาง หนา 11-12

11.8 สรุป
การจัดซื้อจัดจาง การซื้อ หรือการใชบริการภายนอกคือ การไดมาซึ่งสินคาหรือบริการจาก
แหลงภายนอก การจัดซื้อจากแหลงภายนอกของโครงการเทคโนโลยีสารสนเทศมีจํานวนเพิม่ ขึ้น
องคการใชบริการจากแหลงภายนอก เพื่อลดคาใชจาย เพื่อเนนธุรกิจหลักขององคการ เพื่อเขาถึงทักษะ
และเทคโนโลยีทที่ ันสมัย และเพื่อใหเกิดความยืดหยุน มันเปนสิง่ ที่สาํ คัญที่ผูมอี าชีพดานเทคโนโลยี
สารสนเทศควรเขาใจการบริหารการจัดซื้อจัดจาง
กระบวนการบริหารการจัดซือ้ จัดจางประกอบดวย การวางแผนการซื้อและการไดมา การ
วางแผนสัญญา การรองขอคําตอบจากผูขาย การเลือกผูข าย การบริหารสัญญา และ การปดสัญญา
การวางแผนการซื้อและการไดมาเปนการตัดสินใจวาอะไรที่ตองซื้อ หรือใชบริการจากแหลง
ภายนอก ใชสัญญาประเภทใด ปริมาณงานในสัญญาควรเปนเทาใด ผูจัดการโครงการควรปรึกษา
ผูเชี่ยวชาญทัง้ ภายในและภายนอกใหชวยวางแผนการจัดซื้อจัดจาง เพราะมีประเด็นทางดานกฎหมาย
การเงิน และองคการเขามายุงเกีย่ ว
ประเภทของสัญญาพื้นฐานคือ สัญญาแบบราคาคงที่ สัญญาแบบเบิกคาใชจาย สัญญาแบบ
จายตามเวลาและวัสดุ สัญญาแบบราคาคงที่เปนการกําหนดราคาทัง้ หมดคงที่เหมาะสําหรับสินคาที่
กําหนดคุณลักษณะอยางดี เปนสัญญาที่มีความเสี่ยงนอยที่สุดสําหรับผูซื้อ สัญญาแบบเบิกคาใชจาย
เปนการจายเงินคาใชจายจริงทัง้ ทางตรงและทางออมใหกับผูขาย ผูซื้อตองรับความเสีย่ งบางสวน
สัญญาแบบการจายตามเวลาและวัสดุเปนสัญญาที่ผสมสัญญาแบบกําหนดราคาคงที่และสัญญาแบบ
เบิกคาใชจาย มันเปนสิ่งสําคัญที่ผูจัดการโครงการตองตัดสินใจสัญญาประเภทใดเหมาะกับการจัดซื้อ
จัดจางแบบใด ทุกๆ สัญญาควรมีเงื่อนไขการยุติสัญญาไวดวย
ขอกําหนดของงานคือ การอธิบายงานทีต่ องการจัดซื้อจัดจางที่ละเอียดเพียงพอทีจ่ ะใหผูขาย
สามารถพิจารณาวาสามารถใหบริการสินคาและบริการไดหรือไม ในราคาเทาไร
การวางแผนการทําสัญญาประกอบดวยการเขียนเอกสารการจัดซื้อจัดจาง เชน คําขอขอเสนอ
โครงการหรือคําขอขอเสนอราคา และการพัฒนาหลักเกณฑการประเมินผูเสนอโครงการหรือผูเสนอ
ราคา
การรองขอคําตอบจากผูขายประกอบดวยการจัดทําเอกสารสุดทาย การโฆษณา การจัด
ประชุมชี้แจง และการรับขอเสนอโครงการหรือขอเสนอราคา
การเลือกผูขายคือ กระบวนการที่ใชเพื่อประเมินผูขายและตอรอง องคการควรใชแบบประเมิน
ขอเสนอที่เปนทางการ หลักเกณฑเชิงเทคนิคไมควรใหนา้ํ หนักมากกวาการบริการ หรือคาใชจาย
การบริหารสัญญาเปนการสรุปสุดทายวาจะใหผเู สนอรายใดไดรับการคัดเลือกใหไดงาน การ
ติดตามการปฎิบัติงาน และการปรับปรุงสัญญา ผูจัดการโครงการและสมาชิกหลักควรจะเขารวมในการ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการจัดซื้อจัดจาง หนา 11-13

เขียนและรวมในการบริหารสัญญา ผูจดั การโครงการตองตระหนักถึงปญหาเชิงกฎหมายที่อาจเกิดขึ้น

เมื่อผูจัดการโครงการไมเขาใจสัญญา ผูจัดการโครงการและทีมงานควรใชวิธีการควบคุมการ
เปลี่ยนแปลงเมื่อทํางานกับผูใหบริการภายนอก
การปดสัญญาเปนกระบวนการทีง่ านไดดําเนินการเสร็จสมบูรณ และไดแกไขปญหาที่ไดเปด
ไวระหวางปฏิบัติงาน การตรวจสอบการจัดซื้อจัดจางจะชวยชี้บทเรียนที่ไดระหวางกระบวนการจัดซื้อจัด
จาง

คําถามทายบท
1. ทําไมองคการถึงตองใชบริการจากแหลงภายนอก และทําไมแนวโนมจึงเพิม่ ขึ้น
2. อธิบายกระบวนการตัดสินใจแบบทําเองหรือซื้อ
3. ประเภทของสัญญามีอะไร จงอธิบายสัญญาแตละประเภท
4. จงอธิบายขอดีขอเสียของสัญญาแตละประเภท
5. อธิบายวิธีการคัดเลือกผูขาย
6. ใหเสนอแนะวิธีการควบคุมการเปลี่ยนแปลงโครงการในกรณีที่ใชบริการจากแหลงภายนอก
7. อธิบายวัตถุประสงคของการตรวจสอบกระบวนการจัดซือ้ จัดจาง

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การติดตั้งระบบ การปดและการประเมินโครงการ หนา 12-1

12.1 บทนํา
เมื่อระบบสารสนเทศไดพฒ ั นาเสร็จเรียบรอยแลว ผูจดั การโครงการจําเปนตองติดตั้งระบบ
ใหกับผูใชไดใชงาน การดําเนินการดังกลาวทําใหเกิดการเปลี่ยนแปลงขึ้นในองคการ การเลือกวิธีการ
ติดตั้งระบบที่เหมาะสมจึงเปนการชวยใหการเปลี่ยนแปลงกระทําไดงา ยขึ้น
หลังจากติดตัง้ ระบบสารสนเทศแลว ผูจ ดั การโครงการควรปดโครงการอยางเปนทางการซึ่ง
เปนการถายเทงานกลับคืนไปยังเจาของ ทีมงานตองจัดเตรียมสิ่งตางๆ ใหพรอมที่จะสงมอบ ใน
ขณะเดียวกันผูจัดการตองบริหารใหงานที่เกี่ยวของกับการปดโครงการและบุคลากร เพื่อใหโครงการ
สามารถปดไดจริงตามเวลาที่กําหนด
เมื่อมีการปดโครงการแลว ผูจัดการโครงการควรประเมินสมาชิกทีมงานแตละคน และใหผล
ตอบกลับแกสมาชิกถึงประสิทธิภาพการดําเนินงาน นอกจากนี้ ผูจดั การโครงการและสมาชิกโครงการ
ควรประชุมรวมกันเพื่อทําการทบทวนโครงการ และรายงานใหองคการไดทราบถึงปญหาตางๆ วิธกี าร
แกไข ผลที่เกิดจากการแกไข และเปนองคความรูขององคการตอไป
นอกจากการประเมินโครงการตามที่กลาวขางตนแลว โครงการควรไดรับการทบทวนโดย
บุคคลภายนอก เพราะบุคคลภายนอกจะใหขอมูลทีม่ คี ุณคาวาโครงการไดรับการบริหารดีอยางไร และ
สมาชิกทํางานไดดีเพียงไร ทีมตรวจสอบควรระบุดวยวาผูจัดการโครงการและทีมไดดําเนินงานอยางมือ
อาชีพ และอยางมีจรรยาบรรณหรือไม

12.2 การติดตั้งระบบสารสนเทศ
หลังจากระบบสารสนเทศทีพ่ ฒ ั นาขึน้ ไดรับการทดสอบอยางสมบูรณ ผูจัดการโครงการและ
ทีมงานตองรับผิดชอบในการผองถายระบบจากสภาวะแวดลอมการพัฒนาและการทดสอบ ไปยัง
สภาวะแวดลอมแบบปฏิบัติงานของผูใชใหประสบความสําเร็จ การผองถายตองการวิธีการเชิงกลยุทธ
และตองการเวลาจากผูมีสว นไดเสียทัง้ หมด การเลือกวิธีการติดตั้งระบบสารสนเทศที่ไมเหมาะสม
สามารถมีผลกระทบเชิงลบตอเวลาและงบประมาณทีเ่ หลือของโครงการ ทีมงานสามารถเลือกวิธกี าร
ติดตั้งระบบดวยกลยุทธใหญ 3 วิธี ซึ่งสรุปในตารางที่ 12.1

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การติดตั้งระบบ การปดและการประเมินโครงการ หนา 12-2

• การติดตั้งแบบตัดถายโดยตรง
รูปที่ 12.1 แสดงถึงวิธีการติดตั้งระบบสารสนเทศแบบตัดถายโดยตรง ซึง่ เปน
วิธีการที่ยุตกิ ารใชระบบเดิม และเริ่มใชระบบใหมที่ติดตัง้ ทันที โดยปกติ องคการและโครงการจะรวมกัน
กําหนดวันที่จะเริ่มใชระบบใหม วิธีการนี้มปี ระสิทธิผลในกรณีที่ระบบใหมเปนระบบที่สําคัญ หรือระบบที่
มีอยูเดิมทํางานไดไมดีมากๆ จึงจําเปนตองไดรับการเปลี่ยนใหเร็วที่สดุ เทาที่เปนไปได วิธีการใชระบบ
ใหมทนั ทีอาจเหมาะกับระบบที่ไมสําคัญ เพราะเมื่อระบบลมเหลวจะไมมีผลกระทบมากตอองคการ
ดังนัน้ ระบบใหมตองมีการทดสอบใหทกุ คนเชื่อมั่นวาระบบใหมไมมปี ญหา หรือมีปญหานอย
วันที่เปนเปาหมาย

ระบบเดิม

ระบบใหม

รูปที่ 12.1 วิธีการติดตั้งระบบแบบตัดถายโดยตรง (Marchewka, 2006)

ถึงแมวา การใชวิธีการตัดถายโดยตรงมีขอดี แตความเสีย่ งของวิธีการนี้ก็มี

เชนกัน วิธีการนี้ดําเนินการติดตั้งระบบไดเร็วแตเปนวิธีที่สรางความเจ็บปวด การยอนกลับมาใชระบบ
เดิมทําไมไดเพราะไดปดระบบแลว ผลที่เกิดขึ้นคือ ความลาชา ลูกคาและผูใชหมดหวัง รวมทั้งอาจ
สูญเสียรายได

รูปที่ 12.2 การติดตั้งระบบแบบคูขนาน (Marchewka, 2006)

• การติดตั้งแบบคูขนาน
เปนวิธีการที่ยอมใหระบบเกาและระบบใหมทํางานควบคูกันไประยะเวลาหนึง่
แลวองคการยายการทํางานจากระบบเกามาเปนการทํางานดวยระบบใหมทงั้ หมด ดังแสดงในรูปที่ 12.2
วิธีการแบบคูขนานเหมาะกับสถานการณทปี่ ญหาหรือความลมเหลวของระบบมีผลกระทบสูงตอ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การติดตั้งระบบ การปดและการประเมินโครงการ หนา 12-3

องคการ เชน ระบบบัญชี กอนที่องคการจะเปลี่ยนมาใชระบบบัญชีใหม องคการอาจใหทั้งสองระบบ

ทํางานควบคูก ันไป เพื่อเปรียบเทียบผลลัพธจากทัง้ สองระบบ วิธกี ารนีท้ ําใหองคการมีความเชื่อมั่นวา
ระบบใหมทาํ งานไดถูกตอง
ถึงแมวา วิธีการนี้อาจทําใหทมี งานไมเครียด แตมันสามารถสรางความเครียด
ใหกับผูใชระบบมากกวา เนื่องจากผูใชตองใสขอมูลทั้งสองระบบ และอาจตองรับผิดชอบผลการ
เปรียบเทียบผลลัพธ ถาระบบใหมทาํ งานไดตามที่คาดหวัง ผูใชอาจเต็มใจที่จะตองทํางานเพิ่มจนกระทั่ง
เวลาที่ระบบใหมจะยืนไดดว ยตัวเอง แตถาเกิดปญหาที่ไมคาดคิด วันที่องคการตั้งใจจะเปลีย่ นไปใช
ระบบใหมอาจตองเลื่อนออกไป

• การติดตั้งระบบแบบเปนระยะ
วิธีการนี้เปนการติดตั้งระบบสารสนเทศเปนมอดูล หรือติดตั้งระบบในสวนตางๆ
ขององคการแบบคอยๆ เปนคอยไป ดังแสดงในรูปที่ 12.3 เชน การติดตั้งระบบบัญชี องคการอาจเลือก
ติดตั้งมอดูลบัญชีทั่วไปเปนมอดูลแรก ตามมาคือ มอดูลบัญชีเจาหนี้ บัญชีลูกหนี้ และเงินเดือน เปนตน

รูปที่ 12.3 การติดตั้งระบบแบบเปนระยะ

วิธีติดตั้งระบบแบบเปนระยะเหมาะกับการแนะนําซอฟตแวรใหกับสวนตางๆ
ขององคการ ตัวอยางเชน เมื่อองคการตองการยกระดับระบบปฏิบัติการใหมีความสามารถสูงขึ้น แผนก
เทคโนโลยีสารสนเทศอาจทําการยกระดับทีละแผนกตามตารางเวลาทีป่ ระกาศ วิธกี ารนี้อาจทําให
ทีมงานไดเรียนรูจากประสบการณการติดตั้งระบบระยะแรก ซึ่งจะทําใหการติดตั้งระบบตอมาทําได
ราบรื่น ถึงแมวาวิธีการติดตั้งระบบแบบเปนระยะอาจใชเวลามากกวาการติดตั้งแบบตัดถายโดยตรง แต
มันเปนวิธที ี่มคี วามเสีย่ งนอย และสามารถจัดการไดงาย

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การติดตั้งระบบ การปดและการประเมินโครงการ หนา 12-4

ตารางที่ 12.1 การเปรียบเทียบวิธีการติดตั้งระบบ (Marchewka, 2006)

วิธีแบบตัดถายโดยตรง
• ติดตั้งเร็ว
• มีความเสี่ยงถาระบบไมไดทดสอบ
เต็มที่
• ทีมงานไดรับแรงกดดัน
วิธีแบบคูข นาน
• มีความปลอดภัย หรือมีการสํารอง
ในกรณีที่พบปญหาจากการติดตั้ง
ระบบใหม
• สามารถเพิ่มความเชื่อมั่นในระบบ
ใหม เพราะมีการเปรียบเทียบ
ผลลัพธของระบบใหมกับระบบ
เดิม
• ใชเวลาในการติดตั้งนาน และมี
คาใชจายมากกวาวิธีแบบตัดถาย
โดยตรง
• วางแรงกดดันไวที่ผูใชระบบ
วิธีแบบเปนระยะ
• สามารถจัดการการติดตั้งระบบ
เปนมอดูล หรือติดตั้งระบบ/
ยกระดับระบบในหนวยงาน หรือ
สถานที่ตางๆ
• ประสบการณจากการติดตั้งระบบ
ในครั้งแรกสามารถชี้นําและทําให
การติดตั้งครั้งตอมาราบรื่น
• ใชเวลาในการติดตั้งนาน และมี
คาใชจายมากกวาวิธีแบบตัดถาย
โดยตรง
• ปญหาที่พบระหวางระยะแรก
สามารถกระทบตอตารางเวลา
โดยรวม

12.3 การปดโครงการ
โครงการอาจถูกยุติไดดวยเหตุผลหลายอยาง การสิ้นสุดโครงการมี 5 แบบคือ
• ปกติ โครงการที่จบแบบปกติคือ โครงการที่เสร็จสมบูรณตามแผนทีว่ างไว ขอบเขต
โครงการเปนไปตามทีก่ ําหนดดวยงบประมาณ คุณภาพ และเวลาทีต่ ั้งไว ถึงแมวา
จะมีการปรับปรุงตลอดเวลา โครงการจะถูกสงตอไปยังผูสนับสนุนโครงการ
โครงการสิ้นสุดพรอมกับการฉลอง และใหรางวัล
• กอนกําหนด บางครั้งทีมงานโครงการอาจถูกผลักดันใหจบโครงการเร็วขึ้น ถึงแมวา
ระบบงานอาจไมมีลักษณะ หรือฟงกชนั ครบทั้งหมด เชน ระบบปฏิบัติงานอาจมี
เฉพาะฟงกชนั ที่เปนงานหลักตามความตองการแตแรกเทานั้น
• ชั่วกัลปาวสาน โครงการที่วงิ่ หนี (runaway) หรือโครงการชั่วกัลปาวสานเปน
โครงการที่ดูเหมือนไมมีวนั จบ โครงการชั่วกัลปวาสานอาจมีผลจากความลาชา
หรือขอบเขตโครงการไมเคยไดรับการกําหนดใหชัดเจน หรือตกลงรวมกัน หรือ
ผูสนับสนุนโครงการอาจพยายามเพิม่ ลักษณะตางๆ ของระบบงาน ซึ่งสงผลใหเพิ่ม
เวลาและทรัพยากรใหกับโครงการ โครงการทีว่ งิ่ หนีบางโครงการมีผลจากการที่
องคการไมตัดสินใจทีว่ าจะยุติโครงการหรือไม เนื่องการตัดสินใจยุตโิ ครงการเปน
การตัดสินใจทีย่ าก โดยเฉพาะอยางยิง่ ถายึดมั่นอยูก ับอัตตาหรืองานของตนเอง

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การติดตั้งระบบ การปดและการประเมินโครงการ หนา 12-5

ปรากฎการณนี้อาจเกิดขึ้น เมื่อโครงการใหผลตอบแทนสูงแกองคการ และเมื่อการ

ยอมรับความลมเหลวตรงกันขามกับวัฒนธรรมองคการอยางแรง ไมวาดวยสาเหตุ
อะไรก็ตาม ทรัพยากรโครงการถูกระบายออกจนถึงจุดที่โอกาสที่โครงการประสบ
ความสําเร็จมีนอยมาก การกําหนดและการตกลงในขอบเขตโครงการ รวมทั้งการ
ทบทวนโครงการสามารถลดความเสีย่ งของโครงการที่จะประสบเหตุการณประเภท
นี้
• ลมเหลว โดยปกติทั่วไป โครงการเทคโนโลยีสารสนเทศจะลมเหลว ถาปราศจาก
ความใสใจในประเด็นเรื่องคน กระบวนการ หรือเทคโนโลยี ถึงแมวา วัตถุประสงค
โครงการอาจกําหนดคุณคาของโครงการ คาใชจายและเวลาที่เกินมากไปอาจทําให
คุณคาของโครงการนอยลงจนถึงจุดที่คาใชจายในการทําใหโครงการสําเร็จมี
น้ําหนักมากกวาผลประโยชน
• เปลี่ยนลําดับความสําคัญ ในบางสถานการณ โครงการอาจถูกยุติอันเปนผลมา
จากการเปลี่ยนลําดับความสําคัญ เหตุผลทางดานเศรษฐกิจและการเงินอาจเปน
ตัวชี้วาทรัพยากรตางๆ ทีอ่ งคการมีใหในขณะนี้สมควรจะมีไวใหโครงการนี้ใชอีก
ตอไปหรือไม หรือผูบริหารอาจตัดสินใจใหทรัพยากรกับโครงการอื่นที่กลับกลายมา
เปนโครการทีม่ ีความสําคัญสูงกวา การเปลี่ยนแปลงนี้สามารถเกิดขึ้นได เมื่อ
ความสําคัญ หรือคุณคาแตเดิมของโครงการนั้นเปลี่ยนไปตามเวลาและสภาวะ
แวดลอม

โดยอุดมคติ เมื่อโครงการปดแบบปกติ แสดงวาโครงการบรรลุเปาหมายและวัตถุประสงคที่

ตองการ ผูสนับสนุนโครงการควรยินดีกับผลิตภัณฑของโครงการ และแสดงความยินดีดวยการจายเงิน
ใหกับโครงการตามสัญญา แตวาการปดโครงการไมไดเกิดขึ้นในลักษณะนี้ ผูจัดการโครงการและทีมงาน
ควรเตรียมการเพื่อจัดการกับความจริงตอไปนี้
• สมาชิกทีมงานหวงกังวลกับงานในอนาคต สมาชิกของทีมงานถูกยืมตัวจากแผนก
ตางๆ ขององคการ เมื่อโครงการจบ สมาชิกจะกลับไปทํางานเดิมของพวกเขา
สําหรับบริษทั ที่ปรึกษา สมาชิกทีมงานจะยายไปทําโครงการอื่น ขณะที่โครงการ
ใกลจบ สมาชิกทีมงานอาจเริ่มตนกังวลวาพวกเขาจะทําอะไรตอไป การปด
โครงการสําหรับบางคนอาจหมายถึงการมองหางานใหม หลายคนอาจหมายถึง
การทําลายความสัมพันธกบั สมาชิกคนอื่นในทีม ดังนั้น สมาชิกอาจกลายเปนคน

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การติดตั้งระบบ การปดและการประเมินโครงการ หนา 12-6

ไมวางและโครงการที่กาํ ลังจะปดอาจลดความสําคัญ ผลที่ไดคือ สมาชิกทีมงาน

อาจไมมุงทํางานเพื่อปดโครงการ
• ขอผิดพลาดยังคงมีอยู การทดสอบระบบสารสนเทศคือ กระบวนการที่สําคัญของ
การพัฒนาระบบ อยางไรก็ตาม การทดสอบคุณภาพซอฟตแวรอาจไมพบ
ขอบกพรองทัง้ หมด และทีมงานอาจไมรวู ามีขอผิดพลาดจนกระทัง่ หลังจากระบบ
ไดติดตั้งแลว ปญหานี้สามารถทําใหผูมีสวนไดเสียโครงการทั้งหมดเกิด
ความเครียด ความไมสมหวัง ดังนัน้ โครงการอาจยังปดไมได นอกเสียจาก
ขอบกพรองและขอผิดพลาดไดรับการแกไขทันที
• ขาดแคลนทรัพยากร ในตอนจบโครงการ ทั้งทรัพยากรและเวลาไมมีเหลือ ถามี
ประเด็นที่ไมคาดคิด ปญหา หรือความทาทายเกิดขึ้น ผูจ ัดการโครงการอาจพบวา
ไมมีทรัพยากรเพียงพอสําหรับเหตุการณเหลานี้ ผูจ ัดการโครงการอาจพบวาตัวเอง
อยูในสถานการณถูกทําใหเลวลง โดยเฉพาะ ถาผูบ ริหารตัดสินใจตัดหรือควบคุม
งบประมาณของโครงการ
• ใหความสําคัญสูงสุดกับเอกสาร โครงการเทคโนโลยีสารสนเทศมีความตองการ
เอกสารจํานวนมาก ตัวอยางของเอกสารเหลานี้คือ เอกสารโครงการ เอกสารระบบ
เอกสารการอบรม คูมือผูใช เวลาสําหรับการเขียนเอกสารไดกําหนดในแผน
โครงการ และทําเสร็จในชวงการดําเนินโครงการ อยางไรก็ตาม หลายครั้งเอกสาร
ถูกเลื่อนไปจนกระทัง่ ปดโครงการ ขณะทีโ่ ครงการใกลจบ การทําเอกสารกลายเปน
เรื่องสําคัญ ผลที่ตามมาคือ การทําเอกสารตองใชเวลาและทรัพยากรที่จะทําให
เสร็จ
• วันที่สงมอบตามที่สัญญาอาจทําไมได โครงการสวนใหญมปี ระสบการณกับ
ตารางเวลาทีล่ ื่นไถล ซึง่ อาจเนื่องจากการบริหารโครงการที่ไมดี ตองการการแขงขัน
หรือการประมาณการที่ต่ํากวาเปนจริง โครงการจําเปนตองใชทรัพยากรและเวลา
เพื่อทําใหโครงการเสร็จ การตัดสินใจที่ผิดพลาดวาอะไรที่ตองทํา อะไรที่ตองการใช
เพื่อทํางานใหเสร็จ และเวลาที่ตองใช สิง่ เหลานี้มีผลใหเกิดความแตกตางระหวาง
เวลาและงบประมาณที่ไดวางแผน
• ผูมีสวนไดเสียอาจตื่นตระหนก เมื่อตารางเวลาเริ่มลืน่ ไถล และทรัพยากรหมดไป ผู
มีสวนไดเสียโครงการอาจเริม่ รูสึกถึงการเตือนภัย ผูจัดการอาจกังวลวาโครงการนัน้
จะไมทํากําไร หรือไมสรางความพึงพอใจใหกับลูกคา ผูสนับสนุนหรือลูกคาอาจ
กังวลวาระบบสารสนเทศจะไมถูกสงมอบทันเวลาดวยงบประมาณทีก่ าํ หนด หรือมี

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การติดตั้งระบบ การปดและการประเมินโครงการ หนา 12-7

คุณคาตามที่องคการคาดหวัง นอกจากนี้ ผูจัดการโครงการและทีมงานอาจกังวล

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

12.3.1 การยอมรับจากผูสนับสนุนโครงการ
ภายใตการปดแบบปกติ สิ่งสําคัญที่สุดที่โครงการตองการคือ การไดรับการยอบ
รับโครงการจากผูสนับสนุน การสงมอบ การติดตั้ง และการทําใหระบบสารสนเทศทํางานได ไมได
หมายความวาผูสนับสนุนหรือลูกคาจะรับผลิตภัณฑโครงการ เพราะการยอบรับขึน้ กับโครงการทํางาน
ไดตามขอบเขตที่กําหนด ผูจ ัดการโครงการรับผิดชอบในสิ่งที่สงมอบทั้งหมดของโครงการใหสมบูรณตาม
รายละเอียดทีก่ ําหนด นอกจากนี้ สิ่งประกอบอื่นๆ เชน เอกสาร การอบรม และการสนับสนุน ไมควรคิด
ทําทีหลัง และสิ่งเหลานี้ควรรวมอยูในขอบเขตของโครงการดวย ความพยายามตอรองวาอะไรคือสวน
หนึง่ ของงานโครงการหรือไมใชในชวงระยะสุดทายสามารถสรางความรูสึกที่ไมดี
กระบวนการยอมรับจากผูสนับสนุนโครงการจะราบรื่นหรือไม สวนหนึง่ ขึ้นอยูก ับ
ประเภทของผูส นับสนุนโครงการ ซึง่ มี 2 ประเภทคือ ผูสนับสนุนที่มีมมุ มองแคบจะมองความสัมพันธของ
ผูซื้อผูขายวาเปนความสัมพันธระยะสั้น ซึง่ คิดวาเงื่อนไขที่สําคัญที่สุดสําหรับการยอมรับโครงการคือเงิน
ภาพแบบนีน้ ํามาซึ่งความสัมพันธแบบปรปกษ ถาผูสนับสนุนโครงการพยายามตอรองขอบเขตหรือราคา
อีกครั้งเมื่อปลายโครงการ ผูส นับสนุนโครงการอีกประเภทคือ ผูสนับสนุนที่มีความรู ซึ่งตระหนักวาพวก
เขามีสวนสําคัญในผลลัพธของโครงการ พวกเขาจะมีสวนรวมอยางมากตลอดทั้งโครงการในลักษณะเชิง
สรางสรรค ผูสนับสนุนโครงการประเภทนี้อาจถามคําถามยากๆ ระหวางทบทวนโครงการ แต
วัตถุประสงคไมไดตองการทําใหทีมงานหรือผูจัดการโครงการตองอาย แตเพือ่ ใหแนใจวาโครงการ
ประสบความสําเร็จ แทนที่พยายามใหเกิดสถานการณชนะ-แพ ผูสนับสนุนที่มคี วามรูจะตอรองอยาง
ฉลาดและจริงใจ
โดยไมคํานึงถึงวาผูสนับสนุนโครงการเปนประเภทใด ผูจัดการโครงการและ
ทีมงานสามารถเพิ่มโอกาสใหโครงการยอมรับ ถามี 1) การกําหนดเงือ่ นไขการรับโครงการที่ชัดเจนตั้งแต
ระยะแรกของโครงการ 2) กําหนดความสมบูรณของสิ่งสงมอบและหลักไมลของโครงการทั้งหมด

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การติดตั้งระบบ การปดและการประเมินโครงการ หนา 12-8

12.3.2 รายงานโครงการสุดทาย
โดยทัว่ ไป ผูจัดการและทีมงานควรจัดทํารายงานสุดทายและนําเสนอใหกบั
ผูสนับสนุนและผูมีสวนไดเสียหลักของโครงการ วัตถุประสงคของการรายงานและการนําเสนอคือ เพื่อให
ผูสนับสนุนโครงการมัน่ ใจวาโครงการไดเสร็จสมบูรณตามที่ไดระบุไวในแฟมธุรกิจ เอกสารสิทธิโ์ ครงการ
และแผนโครงการ นอกจากนี้ ความมัน่ ใจทําใหผูสนับสนุนและลูกคาจะยอมรับโครงการไดมากกวา และ
ทําใหโครงการปดอยางราบรืน่
รายงานนี้อาจเวียนใหผูมีสว นไดเสียหลักไดอานกอนการนําเสนอ เพื่อรับ
ขอคิดเห็น รายงานสุดทายประกอบดวยหัวขอตอไปนี้
• สรุปโครงการ
ƒ คําอธิบายโครงการ
ƒ วัตถุประสงคโครงการ
ƒ ขอบเขต เวลา และงบประมาณ
• การเปรียบเทียบแผนกับสิง่ ที่เกิดจริง
ƒ ขอบเขตเดิมและประวัติการเปลี่ยนแปลงที่ไดรับอนุมัติ
ƒ วันสุดทายที่กาํ หนดไวเดิมกับวันที่เสร็จจริง
ƒ งบประมาณเดิมกับคาใชจา ยจริงของโครงการ
ƒ แผนการทดสอบและผลการทดสอบ
• ประเด็นเดน
ƒ หัวขอและความสมบูรณที่คาดหวัง
ƒ การสนับสนุนตอเนื่องที่ตองมีและชวงระยะเวลา
• รายการเอกสารโครงการ
ƒ เอกสารระบบ
ƒ คูมือผูใช
ƒ เอกสารและวัสดุการอบรม
ƒ เอกสารการบํารุงรักษา

12.3.3 การนําเสนอและการประชุมครั้งสุดทาย
การประชุมครัง้ สุดทายมีประโยชนดังนี้
• เปนการสื่อสารวาโครงการยุติแลว โดยการเชิญผูมีสวนไดเสียหลักของ
โครงการเขาประชุม ผูจัดการโครงการประกาศเปนทางการวาโครงการ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การติดตั้งระบบ การปดและการประเมินโครงการ หนา 12-9

กําลังจะสิ้นสุด การกระทํานี้ทาํ ใหผูใกลชิดกับโครงการรวมทัง้ องคการ

ไดรับรูถึงการปดโครงการ
• เปนการถายโอนระบบสารสนเทศจากทีมงานใหกับองคการ ถึงแมวา
ระบบสารสนเทศไดรับการติดตั้งและกําลังใชงานโดยองคการ การ
ประชุมครั้งสุดทายเปนการสงมอบงานทีท่ าํ สําเร็จอยางเปนทางการ
ใหกับองคการ นอกเสียจากวาในสัญญามีขอตกลงเรือ่ งการสนับสนุน
ตอเนื่อง การถายโอนสงสัญญาณวาทีมงานโครงการจะไมอยูกับลูกคา
อีกตอไป
• เปนการประกาศการมีสว นรวม การประชุมเปนการเปดเวทีสาํ หรับ
ผูจัดการโครงการเพื่อประกาศการมีสว นรวมในงานของทีมงานและผูม ี
สวนไดเสียหลัก
• เปนการไดรับลายเซ็นการรับโครงการที่เปนทางการ การประชุมเปนการ
ฉลองที่ผูสนับสนุนและลูกคายอมรับระบบสารสนเทศอยางเปนทางการ
โดยการเซ็นตรับโครงการ

12.3.4 การปดโครงการ
เมื่อโครงการไดรับการยอมรับจากผูสนับสนุนโครงการหรือลูกคาแลว กระบวน
การบริหารการปดโครงการยังคงมีอยู งานสุดทายนี้อาจยากเพราะผูจ ัดการโครงการหรือทีมงานอาจมอง
วางานที่เปนงานเชิงบริหารเหลานี้นา เบื่อ หรือเพราะพวกเขากําลังคิดถึงงานอืน่ ที่ไดรับมอบหมาย แต
งานปดโครงการจําเปนตองมี เพราะเมื่อผูจัดการและทีมงานออกจากโครงการปจจุบันอยางเปนทางการ
แลว การที่จะใหพวกเขาเก็บรายละเอียดสุดทายจะยาก การปดโครงการเชิงบริหารประกอบดวย
• การตรวจสอบวาสิง่ สงมอบและประเด็นที่เปดไวทั้งหมดไดทาํ สมบูรณ
• การตรวจสอบการรับโครงการอยางเปนทางการของผูสนับสนุนโครงการ
หรือลูกคา
• การจัดการและการจัดเก็บเอกสารสําคัญรวมทัง้ สิ่งที่สงมอบทั้งหมด
• การวางแผนสําหรับการปลอยทรัพยากรโครงการทัง้ หมด
• การวางแผนสําหรับการประเมินและการทบทวนสมาชิกทีมงานทัง้ หมด
และโครงการเองดวย
• การปดบัญชีโครงการทัง้ หมด

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การติดตั้งระบบ การปดและการประเมินโครงการ หนา 12-10

12.4 การประเมินโครงการ
คําถามที่อยูในใจของทุกคนคือ โครงการนี้สาํ เร็จหรือไม ผูมีสวนไดเสียมีความเห็นเรื่อง
ความสําเร็จแตกตางกัน สําหรับสมาชิกทีมงาน ความสําเร็จอาจคือ การไดประสบการณที่มีคา และการ
รูสึกวางานของพวกเขาจะมีผลกระทบทางบวกกับองคการ สําหรับผูจ ัดการโครงการ ความสําเร็จอาจ
เปนการดําเนินโครงการที่สามารถทํากําไรใหกับองคการ สวนทางดานลูกคาหรือผูสนับสนุนโครงการ
อาจมองความสําเร็จโครงการในแงของคุณคาเชิงองคการที่ไดรับจากการดําเนินโครงการ
ดังนัน้ องคการควรมีการประเมินโครงการ ซึ่งมี 4 ประเภทคือ 1) การทบทวนประสิทธิภาพ
ของแตละคน 2) การประเมินหลังโครงการจบ โดยผูจัดการโครงการและทีมงานโครงการ 3) การ
ตรวจสอบโครงการ โดยคนหรือหนวยงานภายนอกองคการ และ 4) การประเมินความสําเร็จโครงการวา
ตรงกับเปาหมายทีก่ ําหนดหรือไม

12.4.1 การทบทวนประสิทธิภาพของแตละคน
ผูจัดการโครงการควรดําเนินการทบทวนประสิทธิภาพการทํางานของแตละคน
โดยเนนจุดตอไปนี้
• เริ่มดวยการประเมินผลการทํางานของแตละคน การประเมินผลการ
ทํางานอาจมีอารมณความรูส ึกเขามาเกี่ยวของ ถึงแมวาผูประเมินจะ
ตั้งใจใหดีที่สุดก็ตาม แทนที่จะเริ่มการประเมินดวยการวิจารณผลการ
ทํางานของแตละคน เราควรเริ่มโดยการถามวาคนๆ นัน้ ควร
ประเมินผลงานของเขาอยางไร ซึ่งจะชวยใหขอมูลทีม่ ปี ระโยชนกลับไป
ยังแตละคน
• หลีกเลี่ยง “ทําไมเธอไมเปนเหมือน ,,,,,,,,,” การเปรียบเทียบการทํางาน
ระหวางสมาชิกสามารถสรางปรปกษ เพราะจะทําใหคนทีถ่ ูกตําหนิเกิด
ความอิจฉา และมองหาทางลดความนาเชื่อถือของคนอื่น นอกจากนี้
คนแตละคนมีความแตกตางกัน การประเมินไมควรเหมือนกัน
• เนนทีพ่ ฤติกรรม ไมใชตัวบุคคล เมื่ออภิปรายถึงโอกาสการปรับปรุง
บุคคล การเนนทีพ่ ฤติกรรมจึงเปนสิง่ สําคัญ เชน สมาชิกทีมงานมีนสิ ัย
มาทํางานสายเปนประจําและรบกวนการประชุมของทีม เราไมควรเนน
ที่บคุ คล แตเนนทีพ่ ฤติกรรมการมาสาย
• ยุติธรรมและเทาเทียมกัน คนทีท่ ําการประเมินควรระวังวาการตัดสินใจ
เกี่ยวกับคนหนึ่งอาจกระทบทั้งกลุมอยางไร และระวังวาคนชอบ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การติดตั้งระบบ การปดและการประเมินโครงการ หนา 12-11

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

12.4.2 การประเมินหลังโครงการสิ้นสุด
หลังจากรายงานและนําเสนอโครงการครั้งสุดทายเสร็จแลว ผูจัดการโครงการ
และทีมงานควรดําเนินการทบทวนหลังโครงการสิ้นสุด ซึ่งควรทํากอนที่จะปลอยสมาชิกจากโครงการ
ปจจุบัน เพราะมันเปนการยากที่ไดสมาชิกกลับมารวมประเมินโครงการ เนื่องจากสมาชิกทีมงานอาจยุง
กับโครงการอื่น หรือไมไดทาํ งานใหกับองคการอีกตอไป นอกจากนี้ ความจําของคนจะจางหายไปเมื่อ
เวลาผานไป การประเมินหลังโครงการสิ้นสุดควรมีประเด็นตอไปนี้
• เปาหมายเริ่มแรกของโครงการ
• ขอบเขต เวลา งบประมาณ และคุณภาพของโครงการ
• สิ่งที่สง มอบแตละอยาง
• แผนและองคความรูแตละดาน
• ทีมงานทํางานไดดีเพียงใด

คําแนะนําและสิ่งที่อภิปรายจากการประเมินหลังโครงการสิ้นสุดควรไดรับการ
บันทึก โดยเฉพาะผูจัดการโครงการและทีมควรระบุวาอะไรที่พวกเขาทําถูก และอะไรที่พวกเขาควรทําได
ดีขึ้น บทเรียนที่ไดเรียนรูควรบันทึกเพื่อใหคนอื่นในองคการไดเรียนรูดวย

12.4.3 การตรวจสอบโครงการ
การตรวจสอบโครงการโดยคนหรือหนวยงานภายนอกอาจชวยคนพบปญหา
หรือโอกาสในการปรับปรุง การตรวจสอบจะเนนทีโ่ ครงการ หรือการดําเนินการไดดีเพียงใด ประเด็นที่
ควรจะตรวจสอบคือ แผนโครงการ องคความรูการบริหารโครงการ การบริหารโครงการ และ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การติดตั้งระบบ การปดและการประเมินโครงการ หนา 12-12

กระบวนการพัฒนาระบบสารสนเทศที่ไดกําหนดไวในระเบียบวิธีขององคการ นอกจากนี้ผูตรวจสอบหรือ
ทีมงานตรวจสอบควรประเมินวาผูจัดการโครงการและทีมไดทํางานแบบมืออาชีพและอยางมี
จรรยาบรรณหรือไม สิ่งที่ผูตรวจสอบหรือหนวยงานตรวจสอบคนพบควรไดรับการจดบันทึก ผูตรวจสอบ
หรือหนวยงานตรวจสอบควรมีลักษณะดังนี้
• ไมมีสวนรวมหรือผลประโยชนโดยตรงกับโครงการ
• เปนทีน่ า เชื่อถือและมีความยุติธรรม
• เต็มใจฟง
• ไมกลัวการขมขู
• กระทําในสิง่ ทีอ่ งคการใหความสนใจ
• มีประสบการณอยางกวางขวางในธุรกิจขององคการ

12.4.4 การประเมินความสําเร็จโครงการ
เปาหมายของโครงการที่ไดกําหนดไวแตเริ่มโครงการควรไดรับการประเมิน แต
การประเมินเปาหมายนี้อาจทําไมไดทนั ทีที่จบโครงการ ประโยชนหลายอยางที่ไดจากการทําใหโครงการ
ทํางานไดตองใชเวลาจึงจะสามารถประเมินได ผลการประเมินความสําเร็จของโครงการควรตอบคําถาม
ตอไปนี้
• โครงการบรรลุเปาหมายหรือไม
• ผูสนับสนุนหรือลูกคาพอใจหรือไม
• โครงการไดรับการบริหารดีหรือไม
• ผูจัดการโครงการและทีมงานทํางานแบบมืออาชีพและมีจริยธรรมหรือไม
• อะไรที่ทําถูกตอง
• อะไรที่สามารถทําไดดีในครัง้ ตอไป

กอนทําการประเมินนี้ ผูจ ัดการโครงการตองแนใจวาระบบสารสนเทศทีส่ งมอบ

ไมมีการเปลี่ยนแปลง ระบบสารสนเทศทีไ่ ดสงใหกับผูสนับสนุนโครงการแลว ผูใชหรือพนักงานอาจทํา
การเปลี่ยนแปลง การประเมินตองระวังวาระบบที่กาํ ลังถูกประเมินคือระบบที่โครงการสงมอบ

12.5 สรุป
เมื่อระบบสารสนเทศไดสรางขึ้นมาหรือซื้อมา ระบบนี้ตองไดรับการทดสอบอยางเพียงพอ
เพื่อใหการติดตั้งเปนไปอยางราบรื่น อยางไรก็ตาม การทําใหระบบใชงานไดตองใชกลยุทธ เพื่อใหแนใจ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การติดตั้งระบบ การปดและการประเมินโครงการ หนา 12-13

วาระบบสารสนเทศถูกถายโอนอยางมีประสิทธิภาพและประสิทธิผล จากสภาพแวดลอมเชิงโครงการ
ไปสูการปฏิบัติงานรายวันขององคการ
วิธีการติดตั้งระบบสารสนเทศมี 3 วิธี วิธีแรกเรียกวาวิธีตัดถายโดยตรง เปนวิธีการติดตั้ง
ระบบไดเร็วทีส่ ุด ระบบเดิมถูกปดและเปดระบบใหม วิธีการนี้เปนวิธที ี่เสี่ยง ถาระบบไมมีการทดสอบทั้ง
ระบบ ผลทีเ่ กิดขึ้นคือ มีแรงกดดันอยางมากกับทีมงานที่ตองทําใหระบบถูกตองตั้งแตการติดตั้งครั้งแรก
โดยเฉพาะถาเปนระบบสนับสนุนฟงกชันทีส่ ําคัญตอพันธกิจขององคการ
วิธีติดตั้งแบบคูขนานและแบบระยะเปนทางเลือกที่มีความเสี่ยงนอย ถึงแมวาการติดตั้งอาจ
ใชเวลานานกวา วิธีแบบคูข นานตองใชทงั้ ระบบเดิมและระบบใหมไปพรอมๆ กันไปชวงระยะเวลาหนึ่ง
จนกระทั่งมีความเชื่อมัน่ เพียงพอวาระบบใหมทาํ งานถูกตอง พอถึงเวลาจึงเปลี่ยนมาใชระบบใหมเพียง
ระบบเดียว วิธีแบบคูขนานสรางความเครียดสําหรับผูใชระบบ เพราะผูใชตองใสขอมูลทั้งสองระบบ และ
เปรียบเทียบผลลัพธกนั
วิธีการติดตั้งแบบระยะอาจเหมาะกับการติดตั้งระบบเปนมอดูล หรือยกระดับระบบใหดีขึ้นใน
แผนกตางๆ หรือสถานทีท่ แี่ ตกตางกันตามภูมิศาสตร ภายใตวธิ ีการนี้ ประสบการณที่ไดจากการติดตั้ง
ครั้งแรกสามารถทําใหการติดตั้งครั้งตอมาราบรื่น ในทางกลับกัน ปญหาใดๆ ที่ไมคาดคิดสามารถสราง
ปฏิกริยาตอเนือ่ งที่ผลักตารางเวลาการติดตั้งระบบทัง้ หมดใหเลื่อนออกไป การเลือกวิธีการติดตั้งที่
ถูกตองมีผลกระทบอยางมีนัยสําคัญตองบประมาณและเวลาโครงการ
เมื่อระบบสารสนเทศไดติดตั้ง ผูจัดการโครงการและทีมงานตองวางแผนสําหรับการปด
โครงการอยางมีระเบียบ โครงการสามารถสิ้นสุดดวยหลายเหตุผล แตโครงการตองปดอยางเหมาะสม
ไมวาโครงการจะปดอยางประสบความสําเร็จหรือไมสําเร็จก็ตาม โดยอุดมคติ ถาโครงการถูกปดภายใต
เงื่อนไขปกติ แสดงวาขอบเขตโครงการไดรับการดําเนินการสมบูรณ โดยใชเวลา และงบประมาณตามที่
ไดกําหนด หรือที่ไดแกไขจากเดิมอยางมีเหตุผล การสงหรือการติดตั้งระบบสารสนเทศไมไดหมายความ
วาผูสนับสนุนโครงการและลูกคายอมรับระบบ ดังนั้นการปดโครงการตองเนนที่ใหสองกลุมมั่นใจวา
ทีมงานไดสงทุกอยางตามที่ไดกําหนดในแฟมธุรกิจ เอกสารสิทธิ์โครงการ และแผนโครงการ
วิธีการที่จะไดการยอมรับจากผูสนับสนุนโครงการหรือลูกคาคือ การจัดทํารายงานโครงการ
ขั้นสุดทาย รายงานนี้มีประวัติโครงการ และเคาโครงสิง่ สงมอบแตละชิ้นที่ตรงกับมาตรฐานของลูกคา
หรือผูสนับสนุน รายงานควรกลาวถึงหัวขอหรือประเด็นที่เปดที่องคการควรใหความสนใจ รายงานใช
สําหรับการประชุมและนําเสนอครั้งสุดทายกับผูมีสว นไดเสียหลักของโครงการ การประชุมนี้นอกจาก
เปนการปดโครงการแลวยังเปนเครื่องมือสือ่ สารเพื่อแจงใหผูมีสวนไดเสียทราบวาโครงการไดรับการ
ยอมรับอยางเปนทางการและกําลังจะปด กระบวนการปดโครงการประกอบดวย การปดบัญชีโครงการ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การติดตั้งระบบ การปดและการประเมินโครงการ หนา 12-14

การปลอยหรือการถายโอนทรัพยากรโครงการ การบันทึกบทเรียนที่ไดเรียนรู และการจัดเก็บเอกสาร

สําคัญและสิ่งสงมอบทัง้ หมด
กอนที่โครงการจะปดสมบูรณ การทบทวนหรือการประเมินเปนเรื่องสําคัญที่ตองดําเนินการ
การประเมินนีป้ ระกอบดวยการทบทวนประสิทธิภาพการดําเนินงานระหวางผูจัดการโครงการและ
ทีมงานแตละคน การทบทวนหลังจากโครงการสิ้นสุดกับผูจัดการโครงการและทีมงานทั้งหมดควรรวมถึง
สิ่งสงมอบ แผนโครงการ และองคความรูการบริหารโครงการ บทเรียนที่ไดเรียนรูจากโครงการควรไดรับ
การบันทึก และกําหนดวิธีปฏิบัติที่ดีที่สุด
การทบทวนประสิทธิภาพการดําเนินงานและการทบทวนหลังจากโครงการสิ้นสุดจะเปนการ
เตรียมการสําหรับการตรวจสอบโดยคนหรือหนวยงานภายนอกองคการ ในกรณีนี้ ผูตรวจสอบควร
ทบทวนสิง่ สงมอบของโครงการทัง้ หมด และกระบวนการ เพื่อประเมินวาโครงการไดรับการบริหารดี
เพียงใด พฤติกรรมและจรรยาบรรณของผูจัดการโครงการและทีมงานโครงการควรไดรับการตรวจสอบ
ดวย
การประเมินแบบสุดทายคือ การประเมินความสําเร็จของโครงการ ถึงแมวาผูมสี วนไดเสีย
มองความสําเร็จของโครงการที่แตกตางกัน แตสิ่งหนึง่ ที่ใชในการชีน้ ําวาโครงการประสบความสําเร็จ
หรือไมคือเปาหมายของโครงการ แตนา เสียดายที่คณ ุ คาเชิงองคการที่ไดจากโครงการไมพรอมที่จะให
ประเมินทันทีที่ระบบไดรับการติดตั้ง ถึงแมวา โครงการจะปดไปแลว การประเมินประเภทนีย้ ังตอง
ดําเนินการ การประเมินควรใหผูมีสวนไดเสียเขามามีสวนรวม

คําถามทายบท
1. อธิบายวิธีการติดตั้งระบบสารสนเทศทัง้ 3 วิธี
2. จงเปรียบเทียบขอดี-ขอเสียของวิธีการติดตั้งทัง้ 3 วิธี
3. เพราะเหตุใดองคการจึงยุติโครงการกอนกําหนด
4. เพราะเหตุใดจึงเกิดโครงการแบบชั่วกัลปาวสาน
5. เพราะเหตุใดการไดการยอมรับโครงการจากผูสนับสนุนจึงสําคัญตอการปดโครงการ
6. ผูสนับสนุนแบบมุมมองแคบกับแบบมีความรูมีความแตกตางกันอยางไร และเกี่ยวของกับ
การปดโครงการอยางไร
7. วัตถุประสงคของรายงานขั้นสุดทายของโครงการคืออะไร
8. อธิบายวิธีการประเมินทั้ง 4 ประเภท พรอมกับประโยชน

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการเปลี่ยนแปลง หนา 13-1

13.1 บทนํา
โครงการเทคโนโลยีสารสนเทศไดถูกวางแผนเพื่อการเปลี่ยนแปลงเชิงองคการ โครงการ
เทคโนโลยีสารสนเทศมีผลกระทบตอองคการ ขณะเดียวกันองคการกระทบตอโครงการเทคโนโลยี
สารสนเทศเชนเดียวกัน องคการประกอบดวยคน ดังนัน้ การดําเนินการติดตั้งระบบสารสนเทศสามารถ
เปลี่ยนวิธีการทํางานของคน กระทบตอวิธีการใชขอมูลรวมกัน และเปลี่ยนความสัมพันธของคนใน
องคการ การจัดการกับประเด็นทางดานมนุษยจงึ เปนงานที่คนทางดานเทคนิคสวนใหญไมสนุกดวย มัน
เปนธรรมชาติของมนุษยท่จี ะเนนในสิง่ ทีพ่ วกเขาสามารถทําสําเร็จดวยความขัดแยงนอยที่สุด หรือในสิ่ง
ที่พวกเคาสามารถควบคุมได
การดําเนินการพัฒนาระบบสารสนเทศเปนสิ่งที่ทา ทาย ระบบจะถูกยายจากสภาวะแวดลอม
แบบพัฒนาไปสูสภาวะแวดลอมแบบการใชปฏิบัติงาน และถูกทดสอบกอนนําไปใชงานจริง คนใน
องคการตองไดรับการเตรียมพรอมสําหรับผลกระทบทีร่ ะบบใหมจะมีตอพวกเขา ผูจัดการโครงการและ
คนทางดานเทคนิคเชื่อวาผูใชในองคการจะรับระบบงานใหมดวยความดีใจ ถาระบบนั้นทํางานได
เหมาะสม คนดานเทคนิคและผูจัดการโครงการจึงประมาณการผลกระทบนี้ต่ํา องคการในปจจุบันไม
สามารถรับการบริหารการริเริ่มการเปลี่ยนแปลงที่ผิดพลาดได ความกดดันจากการแขงขันไมเปดโอกาส
ใหองคการทําอะไรผิดพลาดได ดังนั้น ในขณะที่การบริหารการพัฒนาโครงการเปนสิ่งสําคัญ เรายังตอง
ใหแนใจวาการผองถายระบบงานประสบความสําเร็จ และเปนทีย่ อมรับขององคการดวยผลกระทบนอย
ที่สุด ความรูทางดานการบริหารการเปลี่ยนแปลงจะชวยใหการติดตั้งระบบสารสนเทศใหมราบรืน่
การทเนอรกรุป ไดนิยามการบริหารการเปลี่ยนแปลงวาเปนการปรับเปลี่ยนองคการเพื่อให
องคการสอดคลองกับยุทธศาสตรทางธุรกิจที่บริษัทไดเลือก การบริหารการเปลี่ยนแปลงจึงเปนการ
บริหารประเด็นทางดานมนุษย
เนื้อหาในบทนีจ้ ะเนนทีก่ ารเปลี่ยนแปลงอาจมองเปนกระบวนการไดอยางไร ประเด็นทาง
อารมณที่โดยปกติเกี่ยวของกับการเปลีย่ นแปลง กรอบงานสําหรับการพัฒนาแผนการบริหารการ
เปลี่ยนแปลง และเทคนิคหลายอยางสําหรับการจัดการการตอตานและความขัดแยง

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการเปลี่ยนแปลง หนา 13-2

13.2 ธรรมชาติของการเปลี่ยนแปลง
เพื่อใหการบริหารการเปลี่ยนแปลงเชิงองคการมีประสิทธิผล เราจึงจําเปนตองเขาใจ
ผลกระทบของการเปลี่ยนแปลง การเปลี่ยนแปลงถูกมองวาเปนกระบวนการอยางไร และรูปแบบ
พฤติกรรมเชิงอารมณของการเปลี่ยนแปลง

13.2.1 ผลกระทบของการเปลี่ยนแปลง
ผลกระทบของการเปลี่ยนแปลงถูกมองวาเปนผลกระทบทั้งทางบวกและทางลบ
ไมวาผลกระทบของการเปลีย่ นแปลงจะเปนอยางไร ปริมาณของความเครียดที่มากับการเปลีย่ นแปลง
แตละเรื่องมีปริมาณหนึ่งเทานัน้ โดยปกติ คนแตละคนตองจัดการกับความเปลีย่ นแปลงที่หลากหลาย
และตองคอยๆ รับการเปลี่ยนแปลงตามกาลเวลา การรับการเปลี่ยนแปลง (assimilation) คือ
กระบวนการของการปรับตัวเขากับการเปลี่ยนแปลง และกําหนดความสามารถของเราในการจัดการการ
เปลี่ยนแปลงทั้งในปจจุบนั และในอนาคต การเปลี่ยนแปลงทําใหเกิดความเครียดและความกังวลสูงใน
ชวงแรก แตเมือ่ เวลาผานไประดับความเครียดและความกังวลจะไมใชระดับเดิม การเปลี่ยนแปลงตองใช
เวลาในการรับการเปลี่ยนแปลง การเปลี่ยนแปลงที่ใหญไมวาจะเปนการเปลี่ยนแปลงเชิงบวกหรือเชิงลบ
ตองการเวลามากกวาการเปลี่ยนแปลงเล็กนอย แตเมื่อการเปลีย่ นแปลงไดรับการยอมรับ การ
เปลี่ยนแปลงนั้นจะไมสรางความเครียดและความกังวลอีกตอไป

รูปที่ 13.1 การรับการเปลี่ยนแปลง (Marchewka, 2006)

ปญหาเกิดขึ้นก็ตอเมื่อคนในองคการไมสามารถรับการเปลี่ยนแปลงไดเร็ว
เพียงพอเนื่องจากผลกระทบมีการสะสม และความเร็วในการเปลี่ยนแปลงสามารถทําไดระดับหนึง่
เทานัน้ คนแตละคนมีความเร็วในการเปลี่ยนแปลงในระดับที่แตกตางกัน ความสามารถที่แตกตางกันนี้
ทําใหเราตองมีความยืดหยุน ในการจัดการการเปลี่ยนแปลง รูปที่ 13.1 แสดงผลกระทบสะสมของการรับ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการเปลี่ยนแปลง หนา 13-3

การเปลี่ยนแปลงตามเวลา แทงกราฟแตละแทงแสดงปริมาณการรับการเปลีย่ นแปลงที่ตองการตาม

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

รูปที่ 13.2 ตัวแบบพื้นฐานของการเปลี่ยนแปลงของเลวิน (Stair, et.al, 2003)

13.2.2 การเปลี่ยนแปลงเปนกระบวนการ
ตัวแบบที่ใหความเขาใจถึงการเปลี่ยนแปลงคือ ตัวแบบของเคริท เลวิน (Kurt
Lewin) ที่ไดเสนอทฤษฎีการเปลี่ยนแปลงที่เกีย่ วของกับแรง (forces) แรงที่อํานวยความสะดวกกับการ
เปลี่ยนแปลงถูกมองวาเปนแรงขับเคลื่อน (driving forces) ขณะที่แรงที่แสดงตัววาเปนแรงกีดขวางการ
เปลี่ยนแปลงเรียกวาแรงตอตาน (resisting forces) ตัวแบบพืน้ ฐานของเลวินมี 3 ขั้นตอนดังรูปที่ 13.2

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการเปลี่ยนแปลง หนา 13-4

ซึ่งประกอบดวย การละลาย (unfreezing) การเปลี่ยนแปลงหรือการเคลื่อนที่ (changing or moving)

และ การทําใหคงสภาพใหม (refreezing)
• การละลาย เปนการละลายพฤติกรรมปจจุบัน โดยการสรางแรงจูงใจ เพื่อให
พนักงานมีความพรอมในการเปลี่ยนแปลง องคการตองทําใหบุคคลรูสึกมี
ความมัน่ ใจ โดยหลีกเลี่ยงการคุกคามและใชวิธีการกระตุนทางบวก เชน
อธิบายถึงขอดี-ขอเสีย ประโยชนที่จะไดรับจากการเปลี่ยนแปลงทั้งของตนเอง
และขององคการ พาไปดูงานในหนวยงานหรือองคการที่มีโครงการเหมือนกับ
โครงการที่เรากําลังจะดําเนินการ เปนตน
• การเปลี่ยนแปลง เปนขัน้ ตอนการเรียนรูพฤติกรรมใหมตามที่องคการปรารถนา
โดยผานวิธกี ารตางๆ เชน การสอน การฝกอบรม การสาธิต และการวิจัย เปน
ตน
• การทําใหคงสภาพใหม เปนขั้นตอนทีพ่ ฤติกรรมที่เรียนรูใหมอยูตัว องคการจึง
ตองมีการเสริมแรงเพื่อใหพฤติกรรมใหมนนั้ เกิดขึ้นถาวรในองคการ โดยการ
กําหนดมาตรฐานตางๆ และแรงจูงใจใหบุคคลปฏิบัติอยางตอเนื่อง

รูปที่ 13.3 กระบวนการเปลี่ยนแปลง (Marchewka, 2006)

รูปที่ 13.3 แสดงใหเห็นถึงกระบวนการเปลี่ยนแปลง ซึ่งอธิบายไดดังนี้ สถานภาพ

ปจจุบันคือ สถานภาพที่สมดุล เพื่อการเปลี่ยนแปลงจากสถานภาพปจจุบันจึงตองมีแรงขับเคลือ่ นทัง้ ที่
เปนแรงริเริ่มการเปลี่ยนแปลงและแรงชักจูงการเปลีย่ นแปลง ซึง่ เปนแรงที่ตองการสําหรับการละลายหรือ
การสลายนิสยั มุมมองและเสถียรภาพของสภาวะปจจุบัน ในชวงของการเปลีย่ นถายจากสภาวะปจจุบัน
ไปยังสภาวะทีต่ องการบางทีเรียกวาสภาวะที่เปนกลาง (neutral zone) และสําหรับหลายคนแลวสภาวะ
แบบนี้เปนสภาวะที่อยูในนรกทัง้ เปน หรืออารมณโกรธ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการเปลี่ยนแปลง หนา 13-5

องคการทีม่ ีผสู นับสนุนแรงขับเคลื่อนการเปลี่ยนแปลงอาจเรงรีบใหแตละคนผาน

ชวงการเปลี่ยนถายนี้ การเรงรีบนี้มีผลใหเกิดความสับสน และแรงตอตานมีแนวโนมที่จะผลักใหแตละ
คนกลับไปยังสภาวะปจจุบนั คนไมชอบถูกจับใหอยูในสภาวะที่เปนกลาง และจะยอนกลับไปยังสภาพ
เดิม หรือหลบหนี การหลบหนีอาจหมายถึงการละทิ้งองคการหรือการตอตานการริเริ่มเปลี่ยนแปลง
นอกจากนี้ คนทีพ่ บวาตัวเองอยูในสภาวะที่เปนกลางนานเกินไปอาจพยายามสรางความประนีประนอม
ใหมีการเปลี่ยนแปลงเพียงแคบางสวน การประนีประนอมจะมีผลใหพลาดโอกาสในการเปลี่ยนแปลง
ความจริงแลวคนไมไดตองการตอตานการเปลี่ยนแปลง แตคนตอตานความ
สูญเสีย และการสิ้นสุด การละลายหรือการเปลี่ยนแปลงจากสถานภาพปจจุบนั หมายถึงการปลอยบาง
สิ่งบางอยางไป ดังนั้น ตัวแบบของเลวินแนะวาการเริ่มตนการเปลี่ยนแปลงใหเริ่มดวยการสิน้ สุดของ
สภาวะปจจุบนั การเคลื่อนผานสภาวะที่เปนกลางหมายถึงความสูญเสียสภาวะสมดุลจนกระทั่งแตละ
คนหรือองคการเคลื่อนไปยังสภาวะที่ตองการ สิง่ ที่สําคัญ พฤติกรรม มุมมองและความเขาใจตองถูกทํา
ใหคงสภาพใหม ดังนั้น สภาวะที่ตองการกลายเปนสถานภาพใหม

13.2.3 การเปลี่ยนแปลงเปนความรูสึกทางอารมณ
การเปลี่ยนแปลงสามารถนํามาซึ่งการโตตอบเชิงอารมณ ถาการเปลีย่ นแปลง
เปนการสูญเสียที่มีความสําคัญตอคนที่ตองรับการเปลีย่ นแปลง การโตตอบนี้มี 5 ระยะคือ
• การปฏิเสธ (denial) ระยะแรกนี้เปนระยะของการตกใจและปฏิเสธ ซึ่งเปน
การโตตอบเมือ่ คนไดรับแจงการเปลี่ยนแปลงเปนครั้งแรกและมีผลกระทบ
ตอคนนั้นอยางมีนยั สําคัญ ความไมเชื่อในการเปลี่ยนแปลงที่ไดรับอาจ
กลายเปนกลไกปองกันทันที
• ความโกรธ (anger) เมื่อคนตกใจกับการประกาศการเปลี่ยนแปลงแลว คน
ที่ตองเปลี่ยนแปลงจะโกรธผูอ ื่น แมแตคนสงขาว การโตตอบของพวกเขาคือ
การโทษใครก็ไดที่รับผิดชอบในการสรางการเปลี่ยนแปลง ถึงแมวา ความ
โกรธคือการตอบโตเชิงอารมณ แตความโกรธสามารถแสดงออกไดเมื่อไดรับ
อนุญาตใหระบายอารมณ ผูทมี่ ีความรูสึกโกรธจะยอมรับการเปลี่ยนแปลง
แตผูที่แสดงความโกรธจะไมยอมรับ
• การตอรอง (bargaining) ในระยะที่ 3 คนจะไมโกรธอีกตอไป ในความจริง
คนอาจใหความรวมมือและพยายามทําขอตกลงเพื่อหลีกเลี่ยงการ
เปลี่ยนแปลง เชน คนที่เสียงานอาจเริ่มสัญญาวาจะทํางานใหมี
ประสิทธิภาพเพิ่มเปนสองเทา หรือยอมใหลดคาจาง

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการเปลี่ยนแปลง หนา 13-6

• ความเศราหมอง (depression) เมื่อคนยอมรับวาการเปลี่ยนแปลงเปนเรื่อง

ที่หลีกเลี่ยงไมได พวกเขาอาจเขาใจผลกระทบทั้งหมดของการเปลีย่ นแปลง
และอาจเขาสูร ะยะที่ 4 คือ ความเศราหมอง ระยะนี้เกิดขึ้นเมื่อมีความรูสึก
อยางรุนแรงจากการสูญเสียสถานภาพปจจุบัน ถึงแมวา การสูญเสียงานทํา
ใหสูญเสียรายได แตคนสวนใหญรูสกึ เศราหมองเพราะพวกเขาสูญเสีย
ชื่อเสียงที่เกีย่ วกับงาน เนื่องจากถูกเปลี่ยนตําแหนง
• การยอมรับ (acceptance) ระยะนี้เปนการทํางานกับความตัง้ ใจของคนที่
ยอมรับวาการเปลี่ยนแปลงเปนสิ่งที่หลีกเลี่ยงไมไดและตองจัดการกับมัน
การยอมรับเปนสวนที่สาํ คัญของการยุติสภาวะปจจุบัน และเปนการได
สภาวะใหม

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

รูปที่ 13.4 แผนบริหารการเปลี่ยนแปลง (Marchewka, 2006)

13.3 การวางแผนการบริหารการเปลี่ยนแปลง
สิ่งสําคัญของการเปลี่ยนแปลงเชิงองคการใดๆ คือ การวางแผนสําหรับการเปลี่ยนแปลงและ
การบริหารการเปลี่ยนแปลงและการเปลี่ยนถายทีเ่ กี่ยวของอยางมีประสิทธิผล แผนการบริหารการ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการเปลี่ยนแปลง หนา 13-7

เปลี่ยนแปลงที่กลาวถึงดานมนุษยจะสื่อใหคนทั้งองคการทราบวาผูบริหารดูแลคนในองคการ พรอมที่จะ
ฟงและนําเอาความตองการของพวกเขาไปพิจารณาอยางจริงจัง ผูสนับสนุนโครงการและทีมงานควร
กลาวถึงประเด็นที่สาํ คัญและใหชัดเจน ประเด็นสําคัญไดสรุปในรูปที่ 13.4

13.3.1 การประเมินความตั้งใจ ความพรอม และความสามารถในการเปลี่ยนแปลง

ขั้นตอนแรกของการพัฒนาแผนการบริหารการเปลี่ยนแปลงคือ การประเมิน
ความตั้งใจ ความพรอม และความสามารถในการเปลี่ยนแปลงขององคการ การประเมินนีน้ าํ มาซึ่งการ
กําหนดผูมีสว นไดเสียคนใดที่เกีย่ วของกับการเปลี่ยนแปลง บทบาท และปฏิกิริยาทีแ่ สดงตอกัน ผูม ีสวน
ไดเสียที่เกี่ยวของกับการเปลีย่ นแปลงประกอบดวย ผูสนับสนุนโครงการ (sponsor) ผูทําการ
เปลี่ยนแปลง (change agent) และเปาหมายการเปลี่ยนแปลง (target)

ผูสนับสนุนโครงการ
ผูสนับสนุนโครงการสามารถเปนบุคคลหรือกลุมบุคคลที่มีความเต็มใจ
และมีอํานาจบังคับบัญชาและจัดสรรทรัพยากรเพื่อสนับสนุนโครงการ ผูสนับสนุนนี้เปนผูสนับสนุนที่
ริเริ่มโครงการ ซึ่งอาจสงโครงการตอใหผูสนับสนุนที่ยงั่ ยืนของโครงการ (sustaining sponsor) ถา
ปราศจากผูสนับสนุนที่ยั่งยืนของโครงการ ในที่สุดโครงการอาจจะเสียทิศทางได ดังนัน้ ผูสนับสนุนที่
ยั่งยืนตองกลายเปนผูสนับสนุนหลักของโครงการ ความตั้งใจและความสามารถขององคการที่จะ
สนับสนุนการเปลี่ยนแปลงสามารถพิจารณาไดจากคํามั่นของผูสนับสนุนที่ใหตอโครงการ คํามั่นนีเ้ ปน
การสื่อสารระหวางผูสนับสนุนโครงการกับคนในองคการวา ผูสนับสนุนโครงการจะจัดการความทาทาย
และประเด็นตางๆ อยางไร และจะสนับสนุนทรัพยากรที่มีใหใชอยางไร ผูสนับสนุนโครงการตองเปนผูนํา
ที่มีประสิทธิผล เพราะถาโครงการลมเหลวอันเนื่องมาจากองคการไมสามารถปรับเขากับการ
เปลี่ยนแปลง คุณคาของโครงการตอองคการ และความเชื่อถือของผูสนับสนุนจะสูญเสียไป

ผูทําการเปลีย่ นแปลง
ผูทําการเปลี่ยนแปลงคือ ผูจดั การโครงการและทีมงาน อยางไรก็ตาม คน
จากสวนอืน่ ทัง้ ภายในภายนอกองคการอาจเขามามีสวนเกี่ยวของไดดวย ผูท ําการเปลี่ยนแปลงมีหนาที่
ทําใหการเปลีย่ นแปลงเกิดขึ้นเพื่อบรรลุเปาหมายและวัตถุประสงคของโครงการ ผูทําการเปลี่ยนแปลง
รายงานโดยตรงตอผูสนับสนุนโครงการ และตองสามารถวินิจฉัยปญหา วางแผนเพื่อจัดการกับปญหา
และความทาทายไดอยางมีประสิทธิผล นอกจากนี้ยงั ตองทําตัวเปนชองทางของการสื่อสารระหวาง
ผูสนับสนุนกับเปาหมายของการเปลี่ยนแปลง

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการเปลี่ยนแปลง หนา 13-8

เปาหมายของการเปลี่ยนแปลง
เปาหมายของการเปลี่ยนแปลงอาจเปนบุคคลหรือกลุมบุคคลที่ตอง
เปลี่ยนแปลง โดยทัว่ ไปคือ ผูใชของระบบใหม หรือใครที่เกี่ยวของโดยตรงกับผลผลิตสุดทายของ
โครงการ หรือคนที่มีบทบาทสําคัญในความสําเร็จของโครงการ ถึงแมวาผูสนับสนุนโครงการและผูทํา
การเปลี่ยนแปลงมีบทบาททีส่ ําคัญในการสนับสนุนและทําใหเกิดการเปลี่ยนแปลง แตความตั้งใจ ความ
พรอมและความสามารถของเปาหมายของการเปลีย่ นแปลงเปนเรื่องที่สําคัญ สิง่ เหลานีจ้ ะเกิดไดตอง
อาศัย 1) การทําใหผลกระทบของการเปลี่ยนแปลงมีความชัดเจน 2) ความเขาใจการเปลี่ยนแปลงทาง
กวาง 3) การกําหนดวาอะไรที่ยกเลิกอะไรที่ยังคงอยู และ 4) การเปลี่ยนแปลงหลักเกณฑการพิจารณา
ความสําเร็จของงาน
ดังที่ไดกลาวมาแลววา การเปลี่ยนแปลงนํามาซึง่ การสิ้นสุดและการสูญเสีย
ควบคุม ผูจดั การโครงการและทีมงานควรใชเวลาเพื่อคิดวาอะไรคือความสูญเสียของแตละคนหรือของ
แตละกลุม เชน อํานาจ ความสัมพันธกับคนอื่น เสถียรภาพ หรือแมแตการควบคุม จากนัน้ ผูจ ัดการ
โครงการและทีมงานจะไดจดั การเปาหมายการเปลีย่ นแปลงแตละคนไดเหมาะสม

รูปที่ 13.5 ตัวแบบของลีวทิ ท (Marchewka, 2006)

การเปลี่ยนแปลงในองคการสามารถกระทบสิ่งตางๆ ดวยวิธกี ารที่แตกตางกัน

ตัวแบบของลีวิททดังรูปที่ 13.5 แสดงใหเห็นวาการเปลีย่ นแปลงในคน เทคโนโลยี งาน หรือโครงสรางเชิง
องคการ มีอิทธิพลหรือกระทบซึ่งกันและกัน สวนประกอบทัง้ สี่สวนมีความสัมพันธกัน การเปลีย่ นแปลง
ในสวนหนึ่งสามารถมีผลในการเปลี่ยนแปลงสวนอื่น เชน การเปลี่ยนแปลงในเทคโนโลยีขององคการ
(เชน การติดตั้งระบบสารสนเทศใหม) สามารถกระทบคนในองคการ (เชน บทบาทใหม ความ
รับผิดชอบ) พรอมทั้งงานที่แตละคนทํา และสามารถกระทบโครงสรางขององคการ (เชน โครงสรางแบบ
ทางการ หรือแบบไมเปนทางการ)

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการเปลี่ยนแปลง หนา 13-9

เนื่องจากการเปลี่ยนแปลงทีไ่ ดวางแผนทําใหคนมีอารมณหลายรูปแบบ เริ่มแรก

คนจะตกใจ โกรธ และปฏิเสธ ตอมาพวกเขาพยายามตอรองที่จะรักษาสภาวะปจจุบัน ณ เวลานี้ การ
ประนีประนอม หรือการเอาใจอาจดูเหมือนเปนทางเลือกที่ดีสําหรับการหลีกเลี่ยงการตอตานและความ
ขัดแยง แตโชคไมดีที่กลยุทธนี้กลับเปนกลยุทธที่บอนทําลายประสิทธิผลของการริเริ่มการเปลี่ยนแปลง
ดังนัน้ มันจึงเปนสิ่งสําคัญทีผ่ ูจัดการโครงการและทีมงานตองกําหนดขอบเขตที่ยอมใหการเปลี่ยนแปลง
เกิดขึ้นตามที่ไดวางแผน โดยที่ยงั คงยินยอมใหแตละคนไดบางอยางที่เขาคุนเคยยึดถือไป เพื่อใหงา ยแก
การเปลี่ยนแปลง
คนจะสับสนเมื่อหลักเกณฑสําหรับวัดความสําเร็จไมชัดเจน เชน ถาทานทํางาน
ในองคการหนึง่ เปนเวลาหลายป ตลอดเวลาที่ผานมาทานไดเขาใจการบริหารงานขององคการและทาน
ไดกลายเปนสวนหนึง่ ของวัฒนธรรมองคการ จากประสบการณหลายปที่ผา นมา ทานรูวาองคการเลื่อน
ตําแหนงโดยพิจารณาจากอาวุโสของการทํางาน เมื่อองคการตัดสินใจที่จะลดขนาดขององคการ
เนื่องจากการติดตั้งระบบงานใหม องคการใหพนักงานออกจากงานโดยพิจารณาจากความอาวุโสของ
ทํางานของพนักงานแตละคน ถาใครทํางานไมนานจะถูกใหออกจากงานแตผูทํางานระดับสูงองคการ
ยังคงใหทาํ งานอยู หลักเกณฑเชนนี้ยอมทําใหพนักงานไมพอใจ ดังนั้น หลักเกณฑของความสําเร็จควร
เปลี่ยน

13.3.2 การพัฒนาหรือการรับกลยุทธสําหรับการเปลี่ยนแปลง
วิธีการในการบริหารการเปลี่ยนแปลงมี 4 วิธีคือ วิธีเชิงประจักษดวยเหตุผล
(rational-empirical approach) วิธีใหการศึกษา-มาตรฐานใหม (normative-reeducation approach)
วิธีบีบบังคับดวยอํานาจ (power-coercive approach) วิธีปรับตัวตามสภาพแวดลอม (environmental-
adaptive approach) รายละเอียดของแตละวิธีมีดังนี้

วิธีเชิงประจักษดวยเหตุผล
วิธีการนี้ใชในการบริหารการเปลี่ยนแปลงตามความคิดที่วา คนทําตาม
รูปแบบของพฤติกรรมที่สามารถคาดการณได และคนจะทําตามความสนใจของตนเอง ดังนั้น ผูทําการ
เปลี่ยนแปลงตองชักจูง ทําใหเชื่อ อธิบาย และแสดงใหเห็นวาการเปลี่ยนแปลงจะใหประโยชนกับคนหรือ
กลุมคนที่เปนเปาหมายการเปลี่ยนแปลงอยางไร
คนที่ไดรับผลกระทบจากการเปลี่ยนแปลงควรไดรับสารสนเทศที่ทนั สมัย
และสอดคลองกัน สารสนเทศที่สอดคลองกันหมายถึงทีมงานและผูสนับสนุนโครงการสงขอความ
เดียวกันไปยังแตละคนหรือกลุมคนทั้งองคการ ขอความที่มีการผสมหลายๆ เรื่องสามารถนํามาซึ่งความ
สับสน สงสัย ความนาเชื่อถือลดลง และถูกนํามาใชเปนขออางเพื่อถวงเวลา

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการเปลี่ยนแปลง หนา 13-10

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

วิธีใหการศึกษา-มาตรฐานใหม
วิธีการนี้มีมมุ มองพืน้ ฐานวาพฤติกรรมของคนสามารถเปลี่ยนไดโดยการ
เปลี่ยนแปลงบรรทัดฐานทางสังคมของกลุม แทนที่องคการจะพยายามเปลี่ยนแตละคน องคการควรมา
มุงเนนที่คานิยมที่เปนแกน (core value) ความเชื่อ และความสัมพันธทที่ ําใหเกิดวัฒนธรรมกลุม
วิธีการนี้เปนวิธีการที่ยากและใชเวลานานเพราะผูสนับสนุนโครงการและ
ผูทําใหเกิดการเปลี่ยนแปลงตองศึกษาคานิยมที่มีอยู และความเชื่อของกลุม วิธีการนี้ตองใชการละลาย
หรือการสลายบรรทัดฐานปจจุบัน แลวการเปลี่ยนแปลงจึงสามารถเขาไปแทนที่ได และทําใหบรรทัดฐาน
ชุดใหมคงอยู

วิธีบีบบังคับดวยอํานาจ
วิธีการนี้เปนวิธีที่พยายามใหคนในองคการเปลี่ยนแปลงโดยการใช
อํานาจ (power) อํานาจตามกฎหมาย (authority) รางวัล หรือการขู การลงโทษ ผูจ ัดการโครงการหลาย
คนถูกลอใหใชวิธีการนี้ แตเปนวิธกี ารที่มคี วามเสีย่ งถาใชวิธีการนี้ผิดสถานการณ คนอาจยินยอมในตอน
แรกๆ จนกระทั่งพวกเขาสามารถหางานใหมได หรือคนอาจมองวาการเปลี่ยนแปลงเกิดขึ้นเปนการ
เปลี่ยนแปลงชัว่ คราว เพียงแตคอยเวลา จากนัน้ ทุกอยางจะกลับไปสูสถานภาพเดิม

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการเปลี่ยนแปลง หนา 13-11

มีบางสถานการณที่การใชวธิ ีแบบบีบบังคับดวยอํานาจเหมาะสมและมี
ประสิทธิผล เชน ในสถานการณที่องคการตองไดรับความใสใจทันทีทันใด การเสียเวลาทีพ่ ยายามใหทุก
คนยอมรับอาจทําใหองคการประสบความหายนะ การใหรางวัลและการขูอาจเปนวิธีการที่สมเหตุสมผล

วิธีปรับตัวตามสภาพแวดลอม
การใชวิธกี ารนี้เปนการที่ผูทาํ การเปลีย่ นแปลงพยายามทําใหการ
เปลี่ยนแปลงเกิดถาวร โดยการลบลางวิธีการเกาและจัดการใหมีสภาพแวดลอมใหมใหเร็วที่สุดเทาที่จะ
เร็วได เชน การเปลี่ยนซอฟตแวรประมวลผลคําชวงวันหยุดสุดสัปดาห ดังนัน้ เมื่อทุกคนเปดเครื่องในวัน
จันทร พวกเขาไมมที างเลือก ตองใชซอฟตแวรตัวใหม เปาหมายการเปลีย่ นแปลงควรรับการ
เปลี่ยนแปลงใหเร็วที่สดุ เทาที่จะเร็วได

13.3.3 การดําเนินตามแผนการบริหารการเปลี่ยนแปลงและการติดตาม
ความกาวหนา
เมื่อผูจัดการโครงการและทีมงานไดกําหนดผูเกี่ยวของและกลยุทธแลว ขัน้ ตอน
ตอไปคือ การทําใหแผนการบริหารการเปลี่ยนแปลงเกิดขึ้น และติดตามความกาวหนาของแผน หลักไมล
และเหตุการณที่สําคัญควรกําหนดในแผนเพื่อจะไดทราบวาองคการกําลังปรับเขากับการเปลีย่ นแปลง
ไดดีเพียงไร
นอกจากนีย้ ังมีประเด็นที่สําคัญที่สุดอีกประเด็นคือ การสรางเสนทางการสื่อสาร
ที่มีประสิทธิผล เพื่อใหแนใจวาการเปลี่ยนแปลงไดดําเนินการตามแผนทีว่ างไว การเลือกสื่อสําหรับการ
สื่อสารเปนเรื่องที่สาํ คัญอีกเรือ่ งหนึ่ง ดังทีไ่ ดกลาวในบทกอนหนานี้ การสื่อสารควรเปนการสื่อสารสอง
ทาง ทีมงานโครงการและผูส นับสนุนตองสื่อสารอยางมีประสิทธิผลกับกลุมตางๆ ภายในองคการ

13.3.4 การประเมินประสบการณและการพัฒนาบทเรียนที่ไดเรียนรู
ประสบการณของทีมงานในการดําเนินการตามแผนการบริหารการเปลี่ยนแปลง
ควรมีการบันทึกและใหสมาชิกในทีมหรือโครงการอื่นไดใชประโยชน เมื่อจบโครงการ ความสําเร็จของ
แผนการบริหารการเปลี่ยนแปลงควรมีการประเมิน ซึ่งอาจชวยกําหนดประสิทธิผลของผูเกี่ยวของกับการ
ดําเนินการเปลี่ยนแปลงและกลยุทธการบริหารการเปลี่ยนแปลง

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการเปลี่ยนแปลง หนา 13-12

13.4 การจัดการกับความขัดแยงและการตอตาน

13.4.1 การตอตาน
ทีมงานควรคาดการณการตอตานลวงหนา การตอตานมีทั้งเปดเผย (เชน บันทึก
ความจํา การประชุม) หรือปกปด (เชน แกลงทําลาย เทาราน้าํ การเมือง) เมื่อไรก็ตามที่มีการ
ประนีประนอมการเปลี่ยนแปลง ผูจัดการโครงการและทีมงานจะเสียเครดิต การตอตานเกิดขึ้นดวย
เหตุผลหลายอยาง เชน บางคนอาจตอตานระบบสารสนเทศเพราะเวลาตอบกลับชามาก หรือเพราะ
ระบบไมมีลักษณะหรือฟงกชันที่ไดกาํ หนดไวในรายละเอียดความตองการ นอกจากนี้ การตอตานเกิดขึ้น
เนื่องจากเหตุผลเชิงวัฒนธรรมหรือเชิงพฤติกรรม ซึ่งไมมีความเปนเหตุเปนผล คนอาจตอตานการ
เปลี่ยนแปลงถึงแมวา พวกเขาจะเขาใจวาการเปลี่ยนแปลงจะใหประโยชนก็ตาม เหตุผลที่ตอตาน เชน
• การเปลี่ยนแปลงตองใชเวลาและแรงงานมากกวาการลงทุน
• การเปลี่ยนแปลงหมายถึงการยกเลิกบางอยางที่คุนเคย สะดวกสบาย
• การเปลี่ยนแปลงเปนการรบกวนถึงแมวาจะใหประโยชนในระยะยาว
• การเปลี่ยนแปลงเปนการบังคับ และทนไมไดที่จะถูกสัง่ ใหทาํ

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

13.4.2 ความขัดแยง
ความขัดแยงมีความเกี่ยวของกับการตอตาน ความขัดแยงเกิดขึ้นเมื่อคนรูวา
ความสนใจหรือคุณคาของเขาถูกทาทาย การบริหารความขัดแยงเนนที่การปองกัน การจัดการ หรือการ
แกไขความขัดแยง ดังนัน้ การระบุความขัดแยงที่เปนไปไดแตเนิ่นๆ จึงเปนเรื่องสําคัญ ถึงแมความ
ขัดแยงที่เปนบวกชวยสรางความคิดใหมๆ แตความขัดแยงที่เปนลบที่ไมไดแกไขสามารถทําให
ความสัมพันธเสียหาย ความไมเชื่อใจ ความเครียด พฤติกรรมที่ผิดปกติ ประสิทธิภาพการทํางานต่ํา
ทัศนะของความขัดแยงมี 3 ทัศนะคือ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการเปลี่ยนแปลง หนา 13-13

• ทัศนะแบบดัง้ เดิม (traditional view) เปนการมองความขัดแยงเปนสิง่ ไมดี

และควรหลีกเลี่ยง ถาปลอยใหความขัดแยงเพิ่มขึ้นเรื่อยๆ จะทําใหการ
ดําเนินงานแยลง ดังนัน้ ผูจ ัดการโครงการจึงควรจัดการความขัดแยงโดย
การกําจัดมันกอนที่มันจะเกิด หรือขจัดมันใหเร็วที่สุดเทาที่จะเร็วได
• ทัศนะแบบรวมสมัย (contemporary view) เปนการมองวาความขัดแยง
เปนสิ่งทีห่ ลีกเลี่ยงไมได มันเปนธรรมชาติ ความขัดแยงที่เปนบวกสามารถ
กระตุนความคิดสรางสรรค อยางไรก็ตาม ความขัดแยงที่เปนลบสามารถ
สรางความเสียหาย ดังนัน้ ความขัดแยงที่เปนบวกควรไดรับการสงเสริม
และควรตรวจสอบความขัดแยงที่เปนลบ
• ทัศนะดานปฏิกิริยาตอกัน (interactionist view) เปนการมองวาความ
ขัดแยงเปนสิง่ สําคัญและจําเปนสําหรับการทํางาน ทัศนะแบบรวมสมัย
ยอมรับความขัดแยง ทัศนะดานปฏิกิริยาตอกันรับความขัดแยงเขาไว
เพราะถาปรองดองหรือราบรื่นเกินไป ทีมงานจะเฉื่อยชาและใจเย็น
ผูจัดการโครงการควรกระตุน ใหเกิดความขัดแยงในระดับที่เหมาะสม
เพื่อใหคนเขาสูความขัดแยงที่เปนบวก

วิธีการตอไปนี้เปนวิธีการจัดการกับความขัดแยง สมาชิกทีมงานหรือผูจัดการ
โครงการควรเลือกวิธีการที่เหมาะสมสําหรับการบริหารความขัดแยงตามสถานการณ
• การหลีกเลี่ยง (avoidance) เปนการหลบเลี่ยง การถอนหรือการไมเอาใจ
ใสความขัดแยง ซึ่งเหมาะกับสถานการณที่ไมสามารถชนะได ประโยชนที่
จะไดนอย อยางไรก็ตามวิธนี ี้ไมเหมาะกับกรณีที่ตองการแกไขความ
ขัดแยงทันที
• การปรับเขาหากัน (accommodate) เปนวิธีทเี่ อาใจหลายๆ ฝายที่ขัดแยง
กันโดยการลดความแตกตางระหวางบุคคลและมุงที่คลายคลึงกัน วิธกี ารนี้
มีประโยชนเมือ่ ตองการบรรลุเปาหมายโดยรวม เมือ่ เปาหมายมีความ
สําคัญมากกวาความสนใจของแตละคนทีเ่ กี่ยวของ การปรับเขาหากันอาจ
เหมาะสมถาเปนการจัดการกับประเด็นทีม่ ีความเสีย่ งต่าํ และผลตอบแทน
นอย หรือเมื่ออยูในสถานการณที่ไมชนะ เพราะวาการปรับเขาหากันใชได
ในระยะสัน้ ดังนัน้ ความขัดแยงอาจปรากฎใหมในรูปอืน่

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการเปลี่ยนแปลง หนา 13-14

• การบังคับ (forcing) เปนการใชอํานาจตามกฎหมายเพื่อแกความขัดแยง

ซึ่งทําใหฝา ยหนึ่งชนะ อีกฝายแพ วิธีการนีอ้ าจเปนวิธกี ารที่มีประสิทธิผลก็
ตอเมื่อทั้ง 2 ฝายไมมีพนื้ ฐานรวมกัน หรือเมื่อเราแนใจวาเราเปนฝายถูก
หรือเมื่อมีสถานการณฉุกเฉิน หรือเมื่อเวลามีนอย อยางไรก็ตาม วิธีการ
บังคับอาจทําใหเกิดการพัฒนาความขัดแยงขึ้นมาอีกครัง้ เพราะคนไม
ชอบการตัดสินใจที่มาจากความเห็นของผูอื่นและนํามาใชบังคับพวกเขา
• การประนีประนอม (compromise) เปนวิธีการที่รวมทั้งการปรับเขาหากัน
และการบังคับ โดยลดระดับของการบังคับและการปรับเขาหากันลง การ
ประนีประนอมเปนการตอรอง โดยคนหรือกลุมคนกลุมหนึง่ ใหบางอยาง
เพื่อแลกเปลี่ยนกับการไดอยางอืน่ ในกรณีนี้ไมมีใครชนะจริงๆ หรือแพ
จริงๆ ดังนั้นความพอใจจากทั้งสองฝายจึงเกิดขึ้น วิธกี ารนี้อาจมีประโยชน
เมื่อพยายามแกปญหาที่สลับซับซอนที่ตองทําใหเรียบรอยในเวลาอันสั้น
และเมื่อความเสี่ยงหรือรางวัลคอนขางสูง
• การรวมมือกัน (collaboration) เมื่อมีความเสีย่ งและประโยชนสงู การ
รวมมืออาจเปนวิธกี ารจัดการความขัดแยงที่ดีที่สุด วิธกี ารนี้ตองการการ
เผชิญหนาและพยายามทีจ่ ะแกปญหาโดยการรวมความคิด และมุมมองที่
แตกตางเขาดวยกัน จุดเนนของการรวมมือคือ การเรียนจากกันและกัน
และไดรับคํามั่น ความไววางใจ ความเคารพ และความมัน่ ใจจากฝาย
ตางๆ ที่เกี่ยวของ การรวมมือใชเวลาและตองการความจริงใจ นอกจากนี้
การแกไขความขัดแยงดวยวิธีนี้ตองการความเต็มใจ เพื่อเขาสูกระบวนการ
แกปญหา

13.4.3 การบริหารความแตกแยก
ผูจัดการโครงการหรือทีมงานเผชิญกับสถานการณความขัดแยงที่ไมปรากฎ
คําตอบ ฝายหนึง่ อุทิศตนเองใหกับการเปลี่ยนแปลงอยางเต็มที่ ขณะที่อีกฝายพยายามรักษาสถานภาพ
เดิม ปญหาคือ ทั้งสองฝายตกอยูในสถานการณสองขั้วที่แตละขางเห็นเฉพาะขอดีของความคิดของฝาย
ตัวเอง และเห็นขอเสียของความคิดของฝายตรงขาม

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการเปลี่ยนแปลง หนา 13-15

รูปที่ 13.6 ตัวอยางการบริหารความแตกแยก (Marchewka, 2006)

การบริหารความแตกแยกเปนเครื่องมือชวยแกไขความขัดแยง โดยเรียกฝายที่
ตองการเปลี่ยนสภาวะปจจุบัน หรือสนับสนุนการเปลี่ยนแปลงวานักรบเพื่อศาสนา (Crusader) อีกฝาย
ตองการรักษาสิ่งที่ดีของอดีตและปจจุบันเรียกวาผูยึดกับสิ่งที่มมี าแตเดิม (Tradition Bearers) เครื่องมือ
นี้จะชวยเห็นทัง้ ดานบนและดานลางของแตละขั้ว รูปที่ 13.6 เปนตัวอยางการติดตั้งโปรแกรมประมวลผล
คําโปรแกรมใหม การใชผังสองขั้วชวยใหคนหลุดออกจากการเห็นคําตอบเดียวสําหรับปญหา และจาก
การตัดสินใจทีต่ องเลือกขั้วหนึ่งขั้วใด
สิ่งสําคัญของการบริหารความแตกแยกคือ การตระหนักวาทัง้ สองฝายตองถูก
จัดการพรอมๆ กัน เพื่อใหเปาหมายของฝายสนับสนุนการเปลี่ยนแปลงและฝายที่ใหคงสถานภาพเดิมจะ
จบลงที่ขวั้ ดานบน ตามตัวอยางการติดตั้งโปรแกรมประมวลผลคําที่ดูเหมือนฝายตอตานรูส ึกวาการ
เรียนรูระบบใหมอาจทําใหงานชะงัก หรือทําใหวอกแวก ไมมีสมาธิในการทํางาน ทั้งสองกลุมอาจ
พยายามสรางแผนการอบรมที่ยืดหยุน เชน วางแผนการอบรมเปนชวงๆ โดยชวงแรกครอบคลุมเพียง
ลักษณะและฟงกชันพื้นฐาน ดังนัน้ ทั้งสองฝายจะไดสิ่งที่ตองการ

13.5 สรุป
การเขาใจการบริหารการเปลี่ยนแปลงเปนเรื่องที่สําคัญของการบริหารโครงการเทคโนโลยี
สารสนเทศ ผูม ีอาชีพทางดานเทคโนโลยีสารสนเทศอาจเนนเฉพาะทางดานเทคนิค จุดยืนนี้มีผลใหการ
ติดตั้งระบบสารสนเทศประสบความสําเร็จทางดานเทคนิค แตทําใหเกิดความลมเหลวเชิงองคการ ระบบ
ทํางานไดอยางมีประสิทธิภาพ แตคนหรือผูใชไมยอมรับระบบ ดังนัน้ มันจึงเปนสิ่งสําคัญที่ผูสนับสนุน
โครงการ ผูจ ัดการโครงการ และทีมงานชวยกันเตรียมความพรอมใหกับผูใชหรือเปาหมายของการ

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการเปลี่ยนแปลง หนา 13-16

เปลี่ยนแปลง กอนติดตั้งระบบ การเตรียมการเปลี่ยนแปลงตองการความเขาใจธรรมชาติของการ

เปลี่ยนแปลง
การเปลี่ยนแปลงเปนกระบวนการ เลวินไดเสนอตัวแบบการเปลี่ยนแปลงที่มี 3 ระยะ คือ การ
ละลายสถานภาพปจจุบนั หลังจากนัน้ เคลื่อนที่ผา นสภาวะการเปลี่ยนถาย จนกระทัง่ ถึงสภาวะใหมที่
ตองการ พฤติกรรมใหมนตี้ องทําใหคงอยู และกลายเปนสภาวะใหม ผูสนับสนุนโครงการและผูจัดการ
โครงการตองเขาใจสภาวะการเปลี่ยนถายที่บางครั้งเรียกวาสภาวะเปนกลาง สภาวะการเปลี่ยนถายเปน
สภาวะที่คนตกใจ หมดหวัง เปนเวลาทีล่ ําบากซึ่งคนพยายามหลบหนี หรือพยายามยอนกลับมายัง
สภาวะกอนหนานี้ นอกจากนี้ การริเริ่มการเปลี่ยนแปลงจะเริ่มตนดวยการยุติความสมดุลปจจุบนั และ
อาจนํามาซึง่ การตอบโตเชิงอารมณอันเนือ่ งจากการสูญเสีย ทั้งคนและองคการสามารถรับการ
เปลี่ยนแปลงไดระดับหนึ่ง การสะสมผลกระทบของการเปลี่ยนแปลงสงผลใหเกิดความเครียด และ
พฤติกรรมการทํางานที่ผิดปกติ ถาการเปลี่ยนแปลงสะสมเกินระดับทีแ่ ตละคนหรือองคการจะรับได
ความเขาใจผลกระทบของการเปลี่ยนแปลงในองคการทําใหเราพัฒนาแผนการบริหารการ
เปลี่ยนแปลงได แผนนี้เริม่ จากการประเมินความตั้งใจ ความพรอม และความสามารถในการ
เปลี่ยนแปลง การประเมินนีเ้ นนที่คํามั่นของผูสนับสนุนโครงการ ความสามารถของผูทําการเปลี่ยนแปลง
และกําหนดผลกระทบการเปลี่ยนแปลงทีม่ ีตอเปาหมาย การประเมินนี้ประกอบดวย การทําใหผลกระทบ
ของการเปลี่ยนแปลงชัดเจน ความเขาใจภาพกวางของการเปลี่ยนแปลง กําหนดวาอะไรที่ตองเปลี่ยน
อะไรที่ไมตอง และกําหนดวาหลักเกณฑความสําเร็จควรเปลี่ยนหรือไม
ขั้นตอนตอไปของแผนการบริหารการเปลีย่ นแปลงเนนที่การใชกลยุทธสําหรับสนับสนุนการ
เปลี่ยนแปลง ซึ่งมี 4 วิธีคือ วิธีเชิงประจักษดวยเหตุผล วิธีใหการศึกษา-มาตรฐานใหม วิธีบีบบังคับดวย
อํานาจ และวิธีปรับตัวตามสภาพแวดลอม แผนการบริหารการเปลีย่ นแปลงอาจใชวิธีการใดวิธกี ารหนึ่ง
หรือหลายวิธี ขึ้นกับสถานการณ
สวนประกอบที่สามของแผนการบริหารการเปลี่ยนแปลงคือ การทําใหไดตามแผน และการ
ติดตามความกาวหนา ถึงแมวามีเครื่องมือหลายอยางสําหรับการติดตามความกาวหนา แตผูจัดการ
โครงการควรกําหนดหลักไมลและเหตุการณที่สําคัญ เพื่อใชในการติดตามการปรับและการรับการ
เปลี่ยนแปลง แผนการบริหารการเปลี่ยนแปลงควรรวมถึงการประเมินและการบันทึกบทเรียนที่ไดเรียนรู
กลยุทธและประสบการณควรมีการบันทึกเพื่อใหผูอนื่ สามารถนํามาประยุกตใชตอไป
ถึงแมวา แผนการบริหารการเปลี่ยนแปลงอาจสื่อขอความที่สําคัญไปยังองคการวาผูบ ริหารเอา
ใจใสคนขององคการ แตการตอตานและความขัดแยงยังเกิดขึ้น ทั้งการตอตานและความขัดแยงเปน
ธรรมชาติอยางหนึ่งของกระบวนการเปลี่ยนแปลง และควรจะคาดการณไวแตแรก การตอตานเกิดจาก
หลายเหตุผลและหลายรูปแบบ ถึงแมวาทัศนะความขัดแยงแบบดั้งเดิมแนะวาความขัดแยงทัง้ หมดไมดี

ผศ.ดร. วราภรณ จิรชีพพัฒนา

การบริหารการเปลี่ยนแปลง หนา 13-17

และควรหลีกเลี่ยงหรือคลี่คลายใหเร็วที่สดุ เทาที่จะเร็วได แตทัศนะแบบรวมสมัยและทัศนะดานปฏิกิริยา

ตอกันสนับสนุนความคิดที่วา ความขัดแยงทางบวกสามารถกระตุนความคิดใหม และปรับปรุงความคิด
สรางสรรคใหดียิ่งขึ้น
นอกจากนี้ ยังมีวิธีจัดการความขัดแยงหลายวิธีคือ การหลีกเลี่ยง การปรับเขาหากัน การบังคับ
การประนีประนอม และความรวมมือ แตละวิธีมีขอดีและขอเสีย ผูม ีสวนไดเสียโครงการควรเลือกวิธีที่
เหมาะสมกับสถานการณ
การบริหารความแตกแยกเปนเครื่องมือจัดการความขัดแยงแบบความรวมมือ การใชเทคนิคนี้
มีนักรบศาสนาเปนฝายสนับสนุนใหเปลีย่ นแปลง และผูยึดกับสิ่งที่มีมาแตเดิมเปนฝายที่ตองการรักษา
สถานภาพเดิม ผังสองขั้วชวยกําหนดสวนดีและสวนไมดีของแตละขั้วความขัดแยง ชวยใหเห็นภาพรวม
และโตเถียงสิง่ ที่แตละฝายกังวล เพื่อที่ทงั้ สองฝายจะชวยกันพัฒนาคําตอบ

คําถามทายบท
1. ทําไมประเด็นทางดานมนุษยจึงมีความสําคัญตอการเปลี่ยนแปลง
2. จงอธิบายธรรมชาติของการเปลี่ยนแปลง
3. จะเกิดอะไรเกิดขึ้น ถาแตละคนไมสามารถรับการเปลี่ยนแปลงไดเร็วพอ
4. จงอธิบายตัวแบบการเปลี่ยนแปลงของเลวิน
5. อธิบายการตอบโตเชิงอารมณของมนุษย เมื่อไดรับขาววางานที่ทาํ กําลังถูกยกเลิกอันเนื่อง
มาจากการติดตั้งระบบสารสนเทศ
6. ใชตัวแบบของเลวิททอธิบายผลกระทบที่เกิดจากการติดตั้งระบบพาณิชยอิเลคทรอนิกส
7. จงอธิบายกลยุทธสาํ หรับจัดการการเปลีย่ นแปลงทั้ง 4 วิธี
8. ทําไมคนถึงตอตานการเปลีย่ นแปลง ถึงแมการเปลี่ยนแปลงนัน้ ใหประโยชนกับตนเอง
9. จงอธิบายวิธีการจัดการความขัดแยง
10. จงอธิบายการบริหารความแตกแยก

ผศ.ดร. วราภรณ จิรชีพพัฒนา

บรรณานุกรม

Ahern, et.al. 2004. CMMI Distilled. 2th edition. MA.:Addison-Wesley

Albrecht, A. 1983. Software Function, Source Lines of Code, and Development Effort
Prediction: A Software Science Validation. IEEE Transactions on Software Engineering
6: 639-648.
Boehm, B. 1981. Software Engineering Economics. New Jersey: Prentice Hall.
Boehm, B. 1991. Software Risk Management: Principles and Practices. IEEE Software 1: 32-
41.
Boehm, et.al. 2000. Software Cost Estimation with COCOMO II. New Jersey: Prentice Hall.
Brooks, F. 1995. The Mythical Man-month: Essays on Software Engineering Anniversary
edition Reading. MA.: Addison-Wesley.
Dinsmore, C. 1984. Human Factors in Project Management. NewYork: American
Management Associations.
Cadle, J. and Yeates, D. 2004. Project Management for Information Systems. 4th edition. New
Jersey: Prentice Hall.
Chrissis, et.al. 2007. CMMI Guidelines for Process Integration and Production Improvement.
2th edition. MA.: Addison-Wesley.
Fenton and Pfleeger. 1997. Software Metrics: A Rigorous and Practice Approach. MA.: PWS
Publishing Company.
Garmus, D. and Herron, D. 2001. Function Point Analysis- Measurement Practices for
Successful Software Projects. MA: Addison-Wesley.
Gido and Clements. 2003. Successful Project Management. 2nd edition. MA.: Thomson.
Gray, C.F. and Larson, E.W. 2000. Project Management: The Managerial Process. New York:
McGraw-Hill.
Heizer, J. and Render, B. 2004. Operations Management. 7th edition. New Jersey: Prentice
Hall.

ผศ.ดร. วราภรณ จิรชีพพัฒนา

บรรณานุกรม

Herzberg, F. 2003. One More Time: How Do You Motivate Employees? (reprinted). Harvard
Business Review. January.
Humphrey. 1988. Characterizing the Software Process: A Maturity Framework. IEEE
Software. March: 73-79.
Jirachiefpattana, W and Jirachiefpattana, A. (2006). An Investigation of Digital Certificates for
Government Officials: A Thailand Case. Communications of the IIMA , 6 (Number 1):
161-168.
Jirachiefpattana, W. 2005. The Influence of Culture on Executive Information Systems
Development in Thailand. World Multiconference on Systemics, Cybernetics and
Informatics (WMSCI 2005). Orlando, Florida, USA. 10-13 July. 1: 92-97.
Mantei, M. 1981. The Effect of Programming Team Structures on Programming Tasks
Communications of the ACM. 24 (Number 3): 106-113.
Leach, L. 2005. Critical Chain Project Management. 2nd edition. MA.: Artech House
McClelland, D. and Burnham. 2003. Power Is the Great Motivator (reprinted). Harvard
Business Review. January.
Marchewka. 2006. Information Technology Project Management: Providing Measurable
Organizational Value. 2nd edition. MA.: Wiley.
Meredith, J. and Mantel, S. 2000. Project Management: A Managerial Approach. 4th eidition.
MA.: Wiley.
Patrick, F.1999. Critical Chain Scheduling and Buffer Management… Getting Out From
Between Parkinson’s Rock and Murphy’s Hard Place (Online). Available at http://
www.focusedperformance.com/articles/CCPM.htm..
Pfleeger. 2001. Software Engineering: Theory and Practice. 2nd edition. New Jersey: Prentice-
Hall.
Pressman. 2005. Software Engineering: A Practitioner’s Approach. 6th edition. MA.: McGraw-
Hill.
Pritchard, C. 2004. The Project Management Communications Toolkit. MA.: Artech House
Inc.
Project Management Institute. 2002. PMBOK® Guide.

ผศ.ดร. วราภรณ จิรชีพพัฒนา

บรรณานุกรม

Render, B.; Stair, R. and Hanna, M. 2003. Quantitative Analysis for Management. 8th edition.
New Jersey: Prentice Hall.
Sage. 1995. Systems Management for Information Technology and Software Engineering.
MA.: Wiley.
Schulmeyer, and McManus. 1999. Handbook of Software Quality Assurance. 3rd edition. New
Jersey: Prentice Hall.
Schwalbe. K. 2006. Information Technology Project Management. 4th edition. MA.: Thomson.
Schwalbe. K. 2007. Information Technology Project Management. 5th edition. MA.: Thomson.
Sommerville. 2001. Software Engineering. 6th edition. MA.:Addison-Wesley.
Stair, R and Reynolds, G. 2003 Principles of Information Systems. 6th edition. MA.: Thomson.
The Standish Group 1995. The CHAOS Report (Online). Available at
http://www.scs.carleton.ca/~beau/PM/Standish-Report.html.
The Standish Group 2003. Latest Standish Group CHAOS Report Shows Project Success
Rates Have Improved by 50% (Online). Available at
http://www.scs.carleton.ca/~beau/PM/Standish-Report.html.
Tuckman, B. 1965. Developmental sequence in small groups. Psychological Bulletin. 63:
384–399.
Tuckman, B., and Jensen, M. 1977. Stages of small group development revisited. Group and
Organization Studies. 2 (Number 4): 419–427.
Wysocki. 2007. Effective Project Management: Traditional, Adaptive Extreme. 4th edition. MA.:
Wiley.

ผศ.ดร. วราภรณ จิรชีพพัฒนา