การบริหารโครงการ

สุชาดา YMBA-13

Chapter 1 การบริหารโครงการ (Project Management) บทนํา •

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

•

การบริหารโครงการเปนคลื่นลูกใหมของอนาคตซึ่งกอกําเนิดผูจัดการสายพันธุใหม

•

การบริหารโครงการแพรหลายในภาคธุรกิจและภาครัฐ

•

การขยายตัวของสถาบันการบริหารโครงการ (Project Management Institute , PMI)

•

การบริหารโครงการเปนสวนสําคัญของการทํางานของทุกคนในองคกร

โครงการ คืออะไร •

โครงการ คือความพยายามในการทํางานชั่วคราวในการจัดหาสินคาหรือบริการที่มีลักษณะเฉพาะ

•

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

•

เปาหมายหลักของโครงการ คือ การตอบสนองความตองการของลูกคา

•

ลักษณะที่สําคัญของโครงการ ¾

วัตถุประสงคเฉพาะ

¾

วงจรชีวิต

¾

ไมเคยเกิดขึ้นมากอน

¾

ขอจํากัดทางดานเวลา คาใชจาย และผลลัพธ

ความแตกตางระหวางการบริหารโครงการและการบริหารทั่วไป การบริหารโครงการ

การบริหารทั่วไป

•

มีลักษณะพิเศษไมซ้ํากับโครงการอื่นใด

•

มีลักษณะซ้ําๆ เปนกิจวัตร

•

มีระยะเวลาที่แนนอน

•

มีระยะเวลาที่ไมสิ้นสุด

•

เกี่ยวของกับการเปลี่ยนแปลงขนาดใหญ

•

เกี่ยวของกับการเปลี่ยนแปลงแบบคอยเปนคอยไป

•

สภาพการดําเนินงานไมคงที่สม่ําเสมอ

•

สภาพการดําเนินงานมีลักษณะคงที่สม่ําเสมอ

•

ใหน้ําหนักแกวัตถุประสงคไมเทากันเพื่อ

•

ใหน้ําหนักแกวัตถุประสงคเทาๆ กันเพื่อรักษาสภาพ

กอใหเกิดการเปลี่ยนแปลงสภาพเดิม •

สรางกลุมทีมงานชั่วคราวขึ้นมาดําเนินงาน

เดิม •

สรางกลุมทีมงานถาวรขึ้นมาดําเนินงาน

ความแตกตางระหวางวัฒนธรรมทางการบริหารของการบริหารโครงการและการบริหารทั่วไป การบริหารโครงการ

การบริหารทั่วไป

•

สภาพแวดลอมของการดําเนินงานยืดหยุน

•

สภาพแวดลอมของการดําเนินงานคงที่

•

การดําเนินงานของโครงการไมเคยกระทํามากอน

•

การดําเนินงานโดยผานกระบวนการปรับปรุงสิ่งที่

เนนประสิทธิผล •

การดําเนินงานเนนจุดมุงหมาย

กระทําเปนประจํา โดยสมาชิกของ

•

กลุมทีมงานตองรับผิดชอบในบทบาทของตนเอง

สมาชิกของกลุมทีมงานดําเนินการโดยเนนบทบาทที่ กําหนดไวลวงหนา

หลายๆ บทบาท •

โครงการดําเนินงานภายใตความเสี่ยงและความ

•

การบริหารงานทั่วไปเปนการดําเนินงานที่เคยมี

ไมแนนอนในการบรรลุความสําเร็จตามเปาหมาย

ประสบการณืทําใหแนใจวาจะสามารถประสบ

เนื่องจากขาดประสบการณและเปนการบริหาร

ความสําเร็จเชนเดิมและเปนการบริหารสภาพเดิม

ความเสี่ยง

1

วงจรชีวิตโครงการ •

วิธีการอธิบายลักษณะเฉพาะของโครงการ

•

ใชในการบริหารโครงการ

•

วงจรชีวิตโครงการจะใหภาพของโครงการ

•

แบบจําลองวงชีวิตโครงการมีหลากหลาย

1.

นิยามโครงการ (Definition) – ทําความเขาใจกับโครงงานที่จะทํา และเตรียมขอมูลที่จะใชใน phase ตอไป

2.

3.

4.

1.1

เปาหมาย

1.2

ขอกําหนด

1.3

งาน (ยอยๆ)

1.4

ผูรับผิดชอบ

การวางแผน (Planning) 2.1

กําหนดการ

2.2

งบประมาณ (ของแตละงาน)

2.3

ทรัพยากร

2.4

ความเสี่ยง

2.5

บุคลากร

ดําเนินการ (Execution) 3.1

รายงานสถานภาพ วาจะเสร็จเร็ว/ชา คาใชจายมาก/นอยกวาที่ตั้ง ผลลัพธเปนตามที่กําหนดหรือไม

3.2

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

3.3

คุณภาพ

3.4

การพยากรณ

การสงมอบ (Delivery) 4.1

การฝกอบรม (ใหลูกคา)

4.2

เอกสารที่เกี่ยวของ – ใบเสร็จ บันทึกการเปลี่ยนแปลง shop drawing การทํา preventive maintenance

4.3

การปลดปลอยทรัพยากร

4.4

การมอบงานใหม

4.5

บทเรียนจากอดีต – ประวัติโครงการ ปญหาตางๆ ที่พบจากการทํางาน ซึ่งสําคัญกับผูจัดการหนาใหม

* แกนY ระดับความพยายาม คือ เวลา งบประมาณ และทรัพยากรที่ทุมเทใหกับการทํางาน , แกน X คือเวลา

2

ผูจัดการโครงการ •

ทําหนาที่เฉกเชนเดียวกับผูจัดการในหนาที่อื่น (ผจก.ตลาด การเงิน ผลิต ,…)

•

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

•

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

•

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

•

ตองกําหนดทิศทางในการดําเนินงานใหกับทีมงาน การประสานงาน และเปนทีมงาน

•

ตองรับผิดชอบตอผลการดําเนินงานโครงการแมวาในทางปฏิบัติแลวจะไมมีอํานาจหนาที่ใดๆ โดยตรง

•

ตองตัดสินใจเลือกทางเลือกที่ดีที่สุดสําหรับโครงการ (trade off) time / cost / performance ชา เชน ชาแตถูก เร็ว แตแพง

•

ตองบริหารโครงการใหบรรลุผลสําเร็จ

ทักษะที่จําเปนสําหรับผูจัดการโครงการ 1.

ผูฟงที่ดี (listener)

2.

นักวิเคราะห (analyst)

3.

นักเจรจาตอรอง (negotiator)

4.

นักจูงใจ (motivator)

5.

นักบริหาร (administrator)

6.

นักตัดสินใจ (decision maker)

7.

นักสื่อสารที่มีความสามารถทั้งการพูดและการเขียน (verbal and written communicator)

ยุคทองของการบริหารโครงการ (สิ่งที่ทําใหการบริหารโครงการเติบโตอยางรวดเร็ว) 1.

การแขงขันที่เนนความตองการของลูกคามากขึ้น

2.

การแขงขันระดับโลก

3.

วงจรชีวิตผลิตภัณฑที่สั้นลง

4.

โครงการขนาดเล็กจํานวนมากในองคกร

5.

การลดขนาดองคกร

6.

การปรากฏของความรูใหม

7.

การพัฒนาอยางรวดเร็วของโลกที่สามและการลมสลายของคอมมิวนิสต ทําใหเกิดการ joint venture ตางๆ

การบริหารโครงการ การบริหารโครงการ คือการจัดการและกํากับทรัพยากร (เวลา วัสดุ บุคลากร และคาใชจาย) เพื่อความสําเร็จของ โครงการเปนไปดวยความเรียบรอย บรรลุตามวัตถุประสงคของโครงการ หนาที่ของการบริหารโครงการ (Project management functions) 1.

managing the scope

2.

managing costs

3.

managing time

4.

managing quality

5.

managing human resources

6.

managing communications (กับลูกคา ลูกทีม suppliers)

7.

managing contract / procurement

8.

managing risk

9.

managing project integration 3

Project management need 1.

size of the undertaking - งานนัน ้ มีขนาดใหญมาก

2.

unfamiliarity - งานที่ไมคุนเคย หรือไมเคยทํามากอน

3.

turbulent market - ตลาดซึ่งลูกคามีพฤติกรรม หรือเปลี่ยนแปลงความตองการตลอดเวลา เชน แฟชัน ่

4.

interdependence - งานที่เกี่ยวของกับหลายๆ หนวยงานในองคกร

5.

scarce resource sharing - ตองการทรัพยากรที่หายาก หรือมีมูลคาสูง เชน คนที่มีความชํานาญเฉพาะดานที่ไม สามารถจางไดมาก

6.

importance of the project - โครงการมีความสําคัญ

7.

organizational reputation - เกี่ยวกับชื่อเสียงขององคกรซึ่งถาเปนงาน routine อาจชาไป

การบริหารโครงการเชิงบูรณาการ •

การบูรณาการกับแผนกลยุทธขององคกร

(ภายนอก)

แผนกลยุทธหมายถึงนโยบายหรือแผนกําหนดทิศทางของ

องคกร •

การบูรณาการภายในโครงการ ¾

การบูรณาการทางดานเทคนิค

¾

การบูรณาการทางดานวัฒนธรรมสังคม (sociocultural) หรือวัฒนธรรมองคกร Project proposal

1. Introduction

Feasibility study

2. Strategy

Integration with organization Integration within project

3. Organization

4. Defining project planning Technical side

Sociocultural side

10. Leadership 11. Team

5. Estimating

6. Project plan 8. Scheduling resources

12. Partnering 7. Managing risk

9. Reducing project team

13. Progress & evaluation controlling 14. Audit and closure

ลําดับกิจกรรมเพื่อเตรียมจัดทําโครงการ การวิเคราะห ความตองการ การศึกษา โครงการไมเปน ที่ตองการ

เบื้องตน การจัดทํา โครงการไมมี ความเปนไปได

ขอเสนอโครงการ การจัดทํา

(ถูกปฏิเสธ) ขอเสนอโครง การไมเปนที่ ยอมรับ

โครงการ

(ถูกปฏิเสธ)

4

การศึกษาความเปนไปได ความเปนไปไดดาน : การตลาด / เทคนิค / การเงิน / เศรษฐกิจ / การบริหาร / สังคม / การเมือง / สิ่งแวดลอม บทที่ 2 การบูรณาการโครงการกับกลยุทธขององคกร •

กระบวนการในการวางกลยุทธองคกร

กลยุทธขององคกรสามารถบรรลุไดโดยการดําเนินงานแบบโครงการ

การ

เชื่อมโยงโครงการเขากับแผนกลยุทธ •

ระบบการคัดเลือกโครงการและเงื่อนไขในการพิจารณาคัดเลือกโครงการ

บทที่ 3 โครงสรางองคกรในการบริหารโครงการและวัฒนธรรมองคกร •

•

รูปแบบโครงสรางองคกรในการบริหารโครงการที่สําคัญ 3 รูปแบบ ¾

Functional team

¾

Dedicated team

¾

Matrix

Functional matrix

Balanced matrix

Project matrix

ลักษณะของโครงสรางแตละรูปแบบ ขอดีและขอเสียของแตละรูปแบบ และการเลือกรูปแบบโครงสรางการบริหาร โครงการที่เหมาะสมในองคกรของทาน

•

วัฒนธรรมองคกรและความสัมพันธระหวางองคกรในการบริหารโครงการกับวัฒนธรรมองคกร

บทที่ 4 การนิยามโครงการ •

การทําความเขาใจโครงการและการเตรียมขอมูลเพื่อการวางแผนโครงการ

•

ขั้นตอนการดําเนินการ ¾

การทําความเขาใจของเขตของโครงการ

ไดแก

วัตถุประสงคของโครงการ ผลลัพธยอยของการดําเนิน

โครงการตามกําหนดระยะเวลาในการดําเนินโครงการ

กําหนดการสําคัญๆ

ความตองการทางดานเทคนิค

เงื่อนไขขอจํากัด สิ่งที่ไมรวมในสัญญา การทบทวนของเขตโครงการกับลูกคา ¾

การกําหนดความสําคัญของตัวแปรสําคัญคือ เวลา งบประมาณและผลลัพธของโครงการ

¾

การสรางโครงสรางจําแนกงาน

¾

การบูรณาการโครงสรางจําแนกงานกับโครงสรางองคกร

¾

การลงรหัสโครงสรางจําแนกงาน

บทที่ 5 การประมาณการเวลาและคาใชจายโครงการ •

ปจจัยที่มีอิทธิพล

•

การประมาณการแบบบนลงลางและจากลางสูบน

•

วิธีการประมาณการ ¾

แบบแม็คโคร ไดแก ratio method , apportion method , function point method , learning curves

¾

แบบไมโคร ไดแก template method , parametric procedures , detail estimating , phase estimating

•

ขอแนะนําบางประการในการประมาณการ

•

งบประมาณสํารองในกรณีฉุกเฉิน

5

บทที่ 6 การวางแผนโครงการ •

การเขียนโครงขาย วิธีการ (AON or AOA) สัญลักษณที่ใชในการคํานวณเวลาในโครงขาย (แบบไปขางหนาและ แบบยอนกลับ)

•

วิถีวิกฤต

•

การใชงานเทคนิคโครงขายในความเปนจริง ¾

สมมติฐานในการเขียนโครงการ : finish-to-start relationship

¾

Laddering : broken down activities

¾

Use of lags (start-to-start , finish-to-finish , start-to-finish relationship)

¾

Hammock activities

บทที่ 7 การจัดการความเสี่ยงในการดําเนินงานโครงการ •

ในการบริหารโครงการไมสามารถหลีกเลี่ยงความเสี่ยงได ความเสีย ่ งในการบริหารโครงการคืออะไร (ความเสี่ยงอาจ ทําให งบบานปลาย เสร็จไมทัน หรือตองเลิกกลางคัน)

•

กระบวนการในการจัดการความเสี่ยง ¾

การระบุความเสี่ยง

¾

การประเมินความเสี่ยง

¾

การตอบโตความเสี่ยง (การลด การถายโอน การแบงปนความเสี่ยง) การวางแผนการตอบโตความเสี่ยง และงบประมาณสํารอง (budget reserve and management reserve)

¾

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

บทที่ 8 การทํากําหนดการภาค 2 •

Time constrained project ¾

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

ผลที่เกิดขึ้น

:

กําหนดการบางสวนเปลี่ยนแปลง

ระยะเวลา

โครงการเทาเดิม •

Resource-constrained project ¾

ทรัพยากรที่จําเปนสําหรับโครงการมีไมเพียงพอ

จําเปนตองวางกําหนดการโครงการใหมใหสอดคลองกับ

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

ทํากําหนดการ

ตรวจสอบ ทรัพยากร

พอ

ปรับ เรียบการใช ทรัพยากร

ไมพอ จัดสรร ทรัพยากร

กําหนดการใหม

6

บทที่ 9 การลดระยะเวลาโครงการ •

คาใชจายทางตรงของโครงการและคาใชจายทางออมของโครงการ

•

การลดเวลาโครงการโดยการลดเวลากิจกรรมโครงการ กิจกรรมที่มีผลตอระยะเวลาโครงการ คือ กิจกรรมที่อยูในวิถี วิกฤต

•

ทางเลือกในการลดเวลากิจกรรมโครงการ

บทที่ 10 ภาวะผูนํา : การเปนผูจัดการโครงการ •

การระบุผูมีสวนเกี่ยวของกับโครงการ (project stakeholder)

•

การสรางความรวมมือและความไววางใจ

บทที่ 11 การจัดการทีมงานโครงการ •

การสรางทีมงาน ปจจัยที่มีผลตอการพัฒนาทีมงาน

บทที่ 12 พันธมิตร •

ความหมาย วิธีการ

บทที่ 13 การประเมินและวัดความกาวหนาการดําเนินโครงการ •

วงจร “วางแผน-ตรวจติดตาม-ควบคุม”

•

การตรวจติดตาม เวลา คาใชจาย ผลการดําเนินงาน

•

แนวคิด even-value

บทที่ 14 การตรวจสอบและยุติโครงการ •

รูปแบบการตรวจสอบโครงการทกระบวนการตรวจสอบโครงการ

•

เหตุแหงการยุติโครงการและกระบวนการในการยุติโครงการ

การเขียนโครงการแบบประเพณีนิยม 1.

ชื่อโครงการ

2.

ชื่อหนวยงานที่รับผิดชอบโครงการ และหรือชื่อผูรับผิดชอบโครงการ

3.

ความสําคัญและที่มาของโครงการ หรือหลักการและเหตุผล

4.

วัตถุประสงคหรือเปาหมายของโครงการ

5.

ขอบเขตของโครงการ

6.

วิธีการดําเนินงานของโครงการ

7.

ระยะเวลาการดําเนินการและขั้นตอนการดําเนินงานโครงการ

8.

ทรัพยากรที่ตองใชในโครงการ

9.

งบประมาณโครงการ

10. การประเมินผลโครงการ 11. ผลที่คาดวาจะไดรับ 12. ภาคผนวก

7

การวิเคราะหและเขียนโครงการแบบเหตุผลสัมพันธ (Logical Framework : LOGFRAME) •

1972 บริษัท Practical Concepts Incorporated

•

เปนการแสดงแผนของโครงการอยางสั้นๆ เขาใจงาย แตครอบคลุมโครงการโดยตลอด

•

แสดงถึงความสัมพันธขององคประกอบพื้นฐานของโครงการดานตางๆ แลวสรุปแสดงออกในรูปตารางเรียกวา “ตาราง เหตุผลสัมพันธ” ขอดี

•

1)

ใหภาพรวมของโครงการ

2)

ใหแนวทางในการปฏิบัติ

3)

ทราบวาโครงการจะถูกประเมินอยางไร

Horizontal logic ทําอยางไรจึงจะชี้วาสิ่งนี้เกิดขึ้น?

คําสรุป

จุดมุงหมาย (goal)

ตัวบงชี้

แหลงวิธีพิสูจ น

เงื่อนไขสําคัญ

(1)

(10)

(11)

วัตถุป ระสงคโครงการ (purpose) (2)

(12)

(13)

(9)

กิจ กรรมการดํ าเนินงาน ผลผลิ ต / ผลงาน (output ) (3)

(14)

(15)

(8)

กิจกรรมการดําเนินงาน (activit y) (4)

(16)

(17)

(7)

ปจ จัย (input)

(18)

(19)

(6)

(5)

ทําไมจะตองใชหรือตองมีสิงนี ่ ้

ทําอยางไรเพือ ่ ใหไดสิงที ่ ต ่ องการนัน ้

Vertical logic

ทําไมสิ่งนี้จ ึงมีผลตอสิ่งนั้น ?

รายละเอียดสวนตางๆ ในตารางเหตุผลสัมพันธ •

สาระสําคัญของการดําเนินงานโดยสรุป (narrative summary) เปนการชี้ใหเห็นวาโครงการจะดําเนินไปไดตองมี รายละเอียด 4 ประการคือ 1.

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

2.

วัตถุประสงคของโครงการ

(project

objective)

หมายถึงวัตถุประสงคเฉพาะของโครงการที่มุงเนนให

เกิดขึ้นและจะตองสอดคบองกันกับความมุงหมายของแผนงานที่ไดกลาวไปแลว

โดยสอดคลองในเชิงที่

เปนเหตุเปนผลซึ่งกันและกัน 3.

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

4.

ปจจัยนําเขา (inputs) หมายถึง ประเภทของทรัพยากรที่ตองนํามาใชเพื่อใหสอดคลองสัมพันธกับผลผลิต หรือผลงานของโครงการ

•

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

•

แหลงตรวจสอบและวัดความสําเร็จ (means of verification) เปนขอความที่ระบุใหเห็นวาตัวบงชี้ความสําเร็จในแตละ ตารางนั้นสามารถตรวจสอบหรือวัดไดจากอะไร จากขอมูลของหนวยงานใด และสอดคลองกันในแตละขั้นตอนการ ดําเนินงานหรือไม

•

เงื่อนไขที่สําคัญ (important assumption) เปนการกลาวถึง “สิ่งที่คาดหมาย” เพือ ่ สนับสนุนวาความสําเร็จที่ระบุใน คําสรุปนั้นจะเกิดขึ้นตรงกับสิ่งที่ตองการถามีสภาพแวดลอมเปนไปตามขอกําหนดพื้นฐานเบื้องตนดังที่ไดกลาวไว 8

ความเปนเหตุเปนผลของตารางเหตุผลตอเนื่อง 1.

ความเปนเหตุเปนผลในแนวตั้ง (vertical logic) 1.1

ความเปนเหตุเปนผลจากบนสูลาง

หมายความวาขอความที่บรรจุลงในแตละตารางจากบนลงสูลางจะตอง

เปนเหตุและผลที่รับกันเปนชวงในลักษณะ “อยางไร” (how) ทําอยางไรเพื่อใหไดสิ่งที่ตองการนั้น หรือ “ถาตองการใหสิ่งหนึ่งสิ่งใดเกิดขึ้นแลว

จะตองทําอยางไรบาง”

เชน

การเพิ่มรายไดของเกษตรกรทํา

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

1.2

1.1.1

ระดับแรก ความสัมพันธของความมุงหมายของแผนงานกับวัตถุประสงคโครงการ

1.1.2

ระดับที่ 2 ความสัมพันธของวัตถุประสงคกับผลงาน

1.1.3

ระดับที่ 2 ความสัมพันธของผลงานกับปจจัยนําเขา

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

2.

ความเปนเหตุเปนผลในแนวนอน (horizontal logic) หมายความวาขอความที่บรรจุในแตละตารางจากซายไปสูขวา จะตองเปนเหตุและผลที่รับกันเปนชวงในลักษณะที่ “ทําอยางไร” (how) สาระสําคัญของการดําเนินงานจะบงชี้ความสําเร็จไดอยางไร

ทําอยางไรจึงจะเกิดสิ่งนี้เกิดขึ้น กลาวคือ

แลวตัวบงชี้ความสําเร็จจะตรวจสอบและวัดความสําเร็จ

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

เปนลักษณะเดนที่สําคัญของการเขียนโครงการแบบตารางเหตุผล

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

และมีวิธีในการดําเนินการอยางไร

ทําใหผูพิจารณา

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

สามารถใชยอเนื้อหาสาระของโครงการทั้งหมดใหสั้นลงภายใน 1-2 หนากระดาษ

2.

การเขียนวัตถุประสงคโครงการเพียงวัตถุประสงคเดียว

ทําใหผูที่เกี่ยวของกับโครงการเกิดความเขาใจวัตถุประสงค

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

สะดวกตอการเปรียบเทียบโครงการหลายๆ โครงการในเวลาเดียวกัน

4.

การพิจารณางบประมาณเนนแตละกิจกรรมที่มีความสัมพันธกันอยางเปนระบบ

5.

ใชเปนกรอบในการวางแผนหลัก การวางแผนรองและแผนระดับปฏิบัติการ

9

ตัวอยางการเขียนโครงการแบบตารางเหตุผลตอเนื่อง How Æ how È

สาระสําคัญการ ดําเนินงานโดยสรุป ความมุง  หมายของ แผนงาน วัตถุประสงคของ โครงการ

ตัวบงชี้ความสําเร็จ ตัวชี้วัดความสําเร็จของ วัตถุประสงคของแผนงาน แสดงเวลา ปริมาณ คุณภาพ สถานที่ เกณฑวัดความสําเร็จตาม วัตถุประสงคโครงการ เวลา ปริมาณ คุณภาพ สถานที่

Ç

ผลผลิต/ผลงาน ของโครงการ

ขนาดของผลงาน แสดง เวลา ปริมาณ คุณภาพ สถานที่ของแตละผลงาน

why

ปจจัยนําเขาของ โครงการ

ขอมูลเกี่ยวกับคาใชจาย ตามกาลเวลา

ขอเสนอโครงการวิจย ั เพื่อศึกษาประสิทธิภาพการสอน คําสรุป ตัวบงชี้ จุดมุงหมาย ผลการเรียนของนักเรียนดีขึ้น ใหโรงเรียนสามารถสอน กวาเดิม 20% วิชาชีพไดตรงตาม จุดมุงหมายของหลักสูตร วัตถุประสงคโครงการ รายงานการวิจัยและขอมูลซึ่ง เพื่อศึกษาประสิทธิภาพ สามารถใชวิเคราะหหาระดับ การสอนวิชาชีพใน ประสิทธิภาพของการสอน โรงเรียนมัธยมในเขต การศึกษา 6 ผลผลิต/ผลงาน รายงานการวิจัยเรื่อง ประสิทธิภาพการสอน วิชาชีพในโรงเรียนในเขต การศึกษา 6 จํานวน 150 รายงาน กิจกรรม • ประชุมกรรมการ ดําเนินการวิจัย • ทําโครงการวิจัย • การประสานงานวิจัย รวมกับโรงเรียน เปาหมายของการวิจัย ปจจัย • คณะกก.วางแผนการ วิจัย • คณะกก.ประสาน งานวิจัย • งบประมาณ 400,000 บาท • เอกสารคูมือการวิจัย 150 เลม

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

แหลงและวิธีพิสูจน รายงานผลการสอนตามการ ใชหลักสูตรการสอนวิชาชีพ ในระดับมัธยมตอนตนของ ศึกษานิเทศน • เอกสารโครงการ • รายงานการวิจัย • บันทึกขอมูล

รายงานการวิจัยจากโรงเรียน ตางๆ จํานวน 150 รายงาน

• ตัวบัญชีรายงานผลการวิจัย • ตัวรายงานการวิจัย

โครงการวิจัย

• โครงการวิจัย • เอกสารติดตอประสานงาน

การวิจัย

• มีคณะกก. ทั้ง 2 คณะ • มีงบประมารตามที่กําหนด

ไว • มีเอกสารสําคัญสําหรับ โครงการ (คูมือการวิจัย และเครื่องมือวัดสถานภาพ การสอนวิชาชีพ)

Å why ขอสมมติฐานเบื้องตนที่ สําคัญ ผลไดของแผนงานที่จะ เกิดขึ้นในระยะยาว

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

• คําสั่งแตงตั้งกรรมการ • รายการงบประมาณที่ไดรับ • ตรวจสอบเอกสารสําคัญ

ของโครงการ

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

เงื่อนไข โรงเรียนมีความรูความเขาใจ หลักสูตรวิชาชีพระดับมัธยม ตอนตนเปนอยางดี • คณะกก.ประสานงานวิจัยมี

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

• ไดรับความรวมมือจากคณะ

กก.เปนอยางดี • ไดรับงบประมาณตามจํานวน

ที่ตองการและตามกําหนดการ

10

การศึกษาความเหมาะสมของโครงการ และหรือ การศึกษาความเปนไปไดของโครงการ Project Feasibility Study (Project feas , Project FS) บรรยายโดย รศ.ดร.ชูชีพ พิพัฒนศิถี , 8 มกราคม 2548 เนื่องจากการพิจารณาเรื่องของอนาคตในวันนี้

ไมสามารถชี้ถูกหรือผิดได

จึงตองทําการศึกษาความเปนไปได

โดยศึกษาอยางนอย 7 ดานตอไปนี้ Aspects

ประเภทของโครงการที่สนใจ

1. Technical analysis

z

2. Market / marketing analysis

z

3. Financial analysis

z

U

4. Economic analysis

U

5. Social analysis

U

6. Institutional analysis

{

U

7. Environmental analysis

{

U

หมายเหตุ :

{ = Private project (เอกชน) ,

z

= Private project และตองเนนเปนพิเศษ

U = Public project (ภาครัฐ) Project Skeleton เนื่องจากการศึกษาความเหมาะสมหรือความเปนไปไดของโครงการ ตองมีฐานขอมูลเพื่อแสดงรายละเอียดของ การเตรียมความพรอมกอน เพื่อนํามาตอบคําถาม โดยรายละเอียดในแตละประเด็นมีดังนี้ (1)

(2)

(3)

Problem and needs

Objectives and outputs

Demand and market

ความสําคัญของปญหาหรือความ

การตั้งวัตถุประสงค (เพื่อใหบรรลุ) แลว

การตรวจสอบความตองการซื้อหรือ

ตองการ (ที่มาวาทําไมจึงตองมี

แปลไปเปนเปาหมาย (goal) หรือ

อุปสงค (ขอมูลตลาดดานความ

โครงการ)

เปาหมาย (target)

ตองการของผูบริโภค จากการทํา market survey) เพื่อกําหนดขนาด ของโครงการ

(8)

(9)

(4)

Costs and benefits

Project summary

Technology

การศึกษาวาโครงการนี้มีการคุมทุน

การสรุปวาโครงการนาสนใจที่จะตอบรับ

ศึกษาวา know how หรือ IT นั้น

หรือไม โดยการเปรียบเทียบระหวาง

[GO] หรือปฏิเสธ [NO GO] โดยปกติ

สามารถทําเอง หรือตอง outsource

ตนทุนกับผลกําไร

ตอบรับแค 20% ปฏิเสธ 80%

ใหผูเชี่ยวชาญดําเนินการให

(7)

(6)

(5)

Project life and schedule

Organization and management

Resource requirements

การทดสอบตารางการปฏิบัติงานและ

ขอมูลที่เกี่ยวของกับองคกรและการ

ความพรอมดานทรัพยากรทั้งดาน

อายุของโครงการ โดยตองทํา time

จัดการ ผูรับผิดชอบโครงการ ระเบียบ

human และ nonhuman

frame , ตารางกิจกรรม , Gantt

การบริหารจัดการ โดยหนวยงานตอง

Chart ที่บอกวาโครงการจะมีกิจกรรม

พรอมและเขมแข็งที่จะนําพาโครงการไป

ใดเมื่อใด ใชงบประมาณเทาไร

ได

1

การวิเคราะหความเหมาะสมของโครงการ และหรือ การศึกษาความเปนไปไดของโครงการ 1.

Technical analysis หมายถึงการวิเคราะหความเหมาะสมหรือความเปนไปไดทางดานวิชาการเฉพาะดาน โดยตองศึกษา •

การออกแบบทางเลือกหลายๆ แบบ (Alternative designs)

•

การเลือกความเหมาะสมทางดานเทคโนโลยี (Appropriate technology)

•

วิธีการกอสราง (Construction method)

•

ความยืดหยุน (Flexibility) โดยการใชเทคโนโลยี ตองมีความยืดหยุน คือสามารถที่จะเปลี่ยนแปลงให สอดคลองกับสถานการณที่เปลี่ยนไป

•

ศึกษาผลกระทบตอสิ่งแวดลอม (Environmental effects) โดยโครงการตองไมมีผลเสียตอสิ่งแวดลอม หรือถามีผลเสียหรือผลกระทบตอสิ่งแวดลอมตองกําหนดวิธีการปองกันและแกไขอยางชัดเจน

•

ความสัมพันธระหวางองคประกอบ (Interrelation of components) ถาสามารถทํางานบนสหสัมพันธของ องคประกอบ

จะสามารถลดตนทุนได

เชน

การทํา

pool

resource

เพื่อสรางประโยชนรวมกันของ

องคประกอบ •

คาใชจายในการดําเนินงานและคาใชจายในการบํารุงรักษา (O & M requirements) ที่ตองต่ํากวาวิธีอื่นๆ

2. Market / Marketing analysis market เปนสวนหนึ่งของวิชา economics ที่พิจารณาที่ demand และ supply โดยการนํา demand มาทํา demand forecasting เพื่อวิเคราะหความเปนไปไดทางดานการตลาด และ Project cash inflow หรือกระแสเงินสด รับของโครงการ โดยตัวเลขตางๆ ที่ไดจะไมเปนจริงเลยถาไมนําเรื่องของการตลาด (marketing) ซึ่งเปนสวนหนึ่ง ของภาควิชาบริหารธุรกิจ มาเสริมดวย ซึ่งก็คือการศึกษาสวนประสมทางการตลาด (4P‘s : Product , Place , Price , Promotion) และการทํา marketing strategy หรือการทํา SWOT analysis เพื่อกําหนดกลยุทธทางการตลาด เพื่อให demand forecasting เปนไปตามที่พยากรณไว 3.

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

การกระจายรายได (income distribution)

•

การมีงานทํา (employment) โดยถาจะดูวาการมีงานทํามีความสําคัญแคไหน ตองดูวาถาวางงานแลวมี ปญหาอยางไร จะทําใหตอบคําถามไดดีกวา

•

โภชนาการ (Nutrition)

•

น้ําสะอาด (water supply)

•

การมีสุขภาพดี ปราศจากโรค (Health)

•

มีเคหสถาน หรือที่อยูอาศัย (Housing) ซึ่งจะสะทอนถึงความมั่งคงปลอดภัยของชีวิต

•

ฯลฯ

ซึ่งทั้งหมดนี้อาจเรียกวา ปจจัยสี่ก็ได 4. Institutional analysis หมายถึง สถาบันหรือหนวยงานที่รับผิดชอบโครงการ ซึ่งจะตองมีการตรวจสอบวามีความพรอมหรือความเขมแข็ง หรือไม โดยกอนที่จะมีการเริ่มโครงการ จะมี checklist เพื่อตรวจสอบวามีสถาบันหรือไม โดย Checklist

Yes, … (ถามีแลว ตรวจสอบดูความพรอมและความเขมแข็งของสถาบัน) No, … “Institutional Building or IB concept” (ยังไมมีสถาบัน ตองจัดตั้งหรือยกฐานะ หนวยงานเพื่อรับผิดชอบ)

2

กรณีที่มีสถาบันแลว ตรวจสอบความพรอมและความเขมแข็งของสถาบันโดยพิจารณา •

การบริหารจัดการที่ไดผล (Effective management) ซึ่งเมื่อบริหารแลวมีกําไรหรือผลการดําเนินงานที่ดี

•

การมีบุคลากรที่เพียงพอทั้งดานปริมาณและคุณภาพ (Adequate staff)

•

มีผังโครงสรางองคกร

(Organizational

structure)

เพื่อแสดงวามีผังการดําเนินงานที่สะทอนถึงการ

เตรียมพรอม •

นโยบายของผูบริหารและระเบียบขั้นตอนการปฏิบัติงานขององคกร

(Policies

and

procedures)

ซึ่ง

นโยบายของผูบริหารมีผลตอความพรอมและความเขมแข็งขององคกร โดยผูบริหารอาจมีนโยบายดังนี้

•

¾

การปฏิวัติ พลิกโฉมหนา (Revolution)

¾

การปฏิรูป ปรับปรุงบางอยางเพื่อความเหมาะสม (Reform)

¾

การจัดแจงใหมใหดียิ่งขึ้น (Rearrange)

¾

การที่ทําทุกอยางเหมือนเดิม ไมเปลี่ยนแปลงอะไรเลย (Status quo)

การฝกอบรมบุคลากร

(Training)

โดยอาจจัดใหมีการฝกอบรมโดยผูสอนเปนบุคคลภายในบริษัท

(in

house training) หรือสงบุคลากรไปอบรมภายนอกบริษัท (external training) เพื่อชวยในการสื่อประสาน เปนอันหนึ่งอันเดียว (understand and use the same language) ปกติการจัดการฝกอบรม จะมีการตั้ง ราคาแบบจิตวิทยา (ของดีตองราคาสูง) •

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

5.

Environmental analysis •

เปนการวิเคราะหวามีการใชทรัพยากรอยางคุมคา (Resource utilization) หรือไม โดยตองมีหลักการใช ทรัพยากรดังนี้ ¾

ทรัพยากรที่ใชแลว สามารถทําใหฟนคืนสภาพกลับมาใชใหมได (Renewable resources) เชน ทรัพยากรที่อยูเหนือผิวดินที่สามารถมองเห็นไดดวยตาเปลา อาทิ น้ํา ดิน ปาไม จะตองใชตาม หลักของความยั่งยืน (sustainable uses) คือใชเฉพาะแตสวนที่เพิ่มพูนขึ้นมาตามเวลาเทานั้น

¾

ทรัพยากรที่ใชแลวหมดสิ้นไป (Nonrenewable resources) เชน ทรัพยากรที่อยูใตดิน อาทิ น้ํามัน แรธาตุ หลักการใชตองรูวาเมื่อใดควรใช เมื่อใดยังไมควรใชก็หลีกเลี่ยงไวกอน (know what to “DO” and “DON’T” ) ซึ่งจะใชเมื่อใดนั้นตองทําการศึกษาขอมูลเพิ่มเติมอีกมาก

•

มลภาวะเปนพิษ (Pollution) การที่มีโครงการเกิดขึ้น จะทําใหเกิดมลภาวะ เราจะตองระบุวิธีแกไว

•

การนําของเสีย

ขยะมูลฝอย

สิ่งปฏิกูลกลับมาใชใหม

(Recycling)

เพื่อลดปริมาณทรัพยากรที่จะตอง

นํามาใช •

การศึกษาเพื่อประเมินผลกระทบตอสิ่งแวดลอม เพื่อหาตนทุนสิ่งแวดลอม (EIA… Environmental costs) โดยการพิจารณาวาเมื่อโครงการเกิดขึ้นแลวจะกระทบกับสิ่งแวดลอมอยางไร เชน โครงการเขื่อนปาสักชล สิทธิ์ ที่เอื้อประโยชนตอกรุงเทพมหานคร ในการลดปญหาน้ําทวม แตจะตองมีตนทุนสิ่งแวดลอมที่จะตอง จายเปนคาชดเชยที่ดินและทรัพยสินใหกับเจาของพื้นที่ หมายเหตุ : EIA – Environmental impact assessment

6. Project appraisal การประเมินมูลคาของโครงการวามีความคุมคาตอการลงทุนหรือไม (measure of project worthiness) ซึ่งจะ วัดทางดานเศรษฐศาสตร

(economically)

และทางการเงิน

(financially)

โดยที่วัดทั้งแบบไมปรับคาตามเวลา

(undiscounted measure) และแบบปรับคาตามเวลา (discounted measure) และมีวิธีวิเคราะหดังนี้

3

•

Cost-Benefit analysis การวัดความคุมคาที่ใชกันมากเปนมาตรฐาน โดยการเปรียบเทียบตนทุนกับผลกําไร ซึ่งประกอบดวย ¾

NPV : Net Present Value

¾

BCR : Benefit – Cost Ratio

¾

IRR : (EIRR – Economic IRR , FIRR – Financial IRR) Internal Rate of Return

โดยที่ Project ที่ไดรับการยอมรับตองมี ¾

NPV > 0

¾

BCR > 1

¾

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

•

Cost-effectiveness analysis เปนวิธีการวัดที่ใชกับโครงการของภาครัฐเปนสวนใหญ ¾

โดยการวัด Least cost alternatives ทําอยางไรใหโครงการมีตนทุนต่ําที่สุด จึงจะถือวาคุมคา เปนการสะทอนการใชงบประมาณแผนดินอยางคุมคา

การวิเคราะหโครงการภายใตความเสี่ยงและความไมแนนอน (Project analysis under risk & uncertainty) อนาคตเปนสิ่งที่ไมแนนอน ซึ่งเกิดจาก •

•

การที่เราไมสามารถลวงรูเหตุการณในอนาคต เนื่องจาก ¾

ปจจัยทางธรรมชาติ (Natural factor)

¾

ปจจัยที่เปนพฤติกรรม (Behavioral factor)

การที่มีขอมูลที่เชื่อถือไดอยางจํากัด

อาจตองใชเทคนิค •

Contingency allowances – รายการเผื่อเหลือเผื่อขาด

•

Risk discounting – การคิดลดความเสี่ยง โดยการรวมความเสี่ยงเขาไวใน discount rate

•

Finite planning horizon – การกําหนดระยะเวลาใหแนนอนตายตัว

•

Expected value – ใชคาที่คาดหมายเปนคาเฉลี่ยในการตัดสินใจ เนื่องจากเปนคาที่เปนตัวแทนของคาที่ กระจายความเสี่ยงแลว

•

Sensitivity analysis – การวิเคราะหความออนไหว

•

Switching value test – การทดสอบคาความแปรเปลี่ยน ซึ่งมักใชคูกับการวิเคราะหความออนไหว

4

Chapter 2 Aligning Projects with Organization Strategy (การประสานโครงการใหเขากับองคกร) โดยการทําแบบบูรณาการ (กับองคกรรวม และกับองคกรของตัวเอง) Introduction ทุก project ตองสอดคลองกับกลยุทธขององคกร เพราะวาในองคกรมีโครงการมากมาย ปญหาคือทําอยางไรจึงจะคัดเลือก

•

ไดอยางเหมาะสม คือไปในทิศทางเดียวกับองคกร เพราะวาตองใชทรัพยากรเดียวกัน Topic 1.

strategic management process - กระบวนการจัดการกลยุทธ

2.

the need for an effective project portfolio management system – เคล็ดลับที่ทําใหโครงการสอดคลองกับกลยุทธ

3.

a project portfolio management system – การคัดเลือกโครงการที่เหมาะสม

Why PM need to understand strategic management process ทําไม PM จึงตองทําความเขาใจกับกระบวนการจัดการกลยุทธ เพราะ Project managers เปนสวนหนึ่งของกระบวนการที่ตอง •

เขาใจภาพรวมและทิศทางขององคกร

•

สามารถจัดหาขอมูล (ความสามารถ จุดแข็ง / จุดออน ขอจํากัดของทรัพยากรขององคกร) ได

•

เขาใจความสัมพันธของแตละ project วาอันไหนสําคัญมาก/นอย กอน/หลัง อยางไร (program = หลายๆ project รวมกัน)

•

การจัดสรรทรัพยากรใหแตละ project

Strategic management process •

เปรียบเหมือนแผนที่ ที่เราตองดูกอนวาเราอยูตรงไหน จะไปไหน (จุดหมายปลายทาง) ไปอยางไร การวางแผนกลยุทธ ก็ ตองมีกรอบหรือทิศทางวาเราทําอะไรอยู อนาคตขางหนาเราจะทําธุรกิจอะไร และจะไปอยางไรจึงจะสําเร็จตามแผน

•

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

4 กิจกรรมของ Strategic management process 1

Review / Revise mission External envi. : O , T

2

3

4

ÊË Ì

New goals and objectives ↓ Portfolio of strategic choices ↓ Strategy formulation ↓ Strategy implementation ↓ Projects

ÉÌ Ë

Internal envi. : S , W

1.

การทบทวนและกําหนดพันธกิจขององคกร (review and define the organizational mission)

2.

การตั้งเปาหมายระยะยาวและวัตถุประสงคขององคกร (set long-range goals and objectives)

3.

วิเคราะหและสรางกลยุทธหลายๆ กลยุทธแลวเลือกอันที่เหมาะสมกับเราเพื่อบรรลุวัตถุประสงค (analyze and formulate strategies to reach objectives)

4.

การดําเนินการตามกลยุทธโดยใชการทํางานแบบโครงการ (implement strategies through projects)

1

1. พันธกิจ (Mission) •

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

•

วัตถุประสงคเพื่อระบุจุดประสงคขององคกรและสื่อสารใหผูเกี่ยวของทั้งมวล (Stakeholders) ทราบ

•

สามารถใชในการประเมินผลการดําเนินงานขององคกรได

สวนประกอบของพันธกิจ •

ผลิตภัณฑและบริการ *สําคัญมาก*

•

ลูกคา และตลาดเปาหมาย

•

ปรัชญา แนวความคิดหรือความเชื่อเกี่ยวกับองคกร

•

เทคโนโลยีพื้นฐานของบริษัท

•

ภาพพจน ภาพพจนตอสาธารณชนของบริษัท

•

การมีสวนรวมรับผิดชอบตอสังคม

ตัวอยาง •

Provide bridge design services

specific ดี : ชัดเจน ไมดี : ขาดความยืดหยุน

•

Provide waste plant design services

เพราะธุรกิจมี cycle อาจดีเปนระยะๆ

•

provide engineering services

broad

•

Increase shareholder value

•

Provide high - value products to our customer

•

Provide shareholder value

ตัวอยางที่ไมดี ไมรูตองเตรียมทรัพยากรอะไรไวบาง

การระบุขอบเขตของธุรกิจ การระบุอยางกวาง

การระบุอยางแคบ

เครื่องดื่ม

น้ําอัดลม

การทองเที่ยว

โรงแรมหรูหรา

การพิมพ

ตําราในมหาวิทยาลัย

เครื่องตกแตง

เครื่องตกแตงสนามหญา

2. เปาหมายและวัตถุประสงค •

การแปลพันธกิจขององคกรใหเปนเปาหมายการดําเนินงานที่เฉพาะเจาะจง จากอะไรบาง

โดยการระบุรายละเอียดวาพันธกิจจะบรรลุได

เปาหมายและวัตถุประสงคจะตองถูกกําหนดขึ้นมาภายในผลสําเร็จที่สําคัญแตละดานที่มีความสําคัญตอการ

บรรลุความสําเร็จขององคกร เชน ตลาด ผลิตภัณฑ นวัตกรรม productivity คุณภาพ profitability ลูกจาง ลูกคา วัตถุประสงคที่ดี (SMART) •

S – specific เฉพาะเจาะจง

•

M – measurable วัดได

•

A – assignable สามารถมอบหมายใหหนวยงานหรือบุคคลไปทําได โดยกําหนดเปาหมายสุดทาย (end result) ไว เปด โอกาสใหทํางานโดยไมตองตีกรอบวิธีการทํางานให

•

R – realistic เปนไปได ใกลเคียงความจริง มิฉะนั้นจะไมจูงใจและไมทาทาย ทาทายแตสามารถบรรลุความสําเร็จได

•

T – time related มีกรอบของเวลา

ตัวอยาง •

วัตถุประสงคของเราคือการทํากําไรสูงสุด – ไมดี ไมรูวาเทาไรสูงสุด

•

วัตถุประสงคของเราคือการทํากําไร 1 ลานบาทภายในป 2545

•

วัตถุประสงคของเราคือการเพิ่มรายไดและปริมาณการขาย 2

•

วัตถุประสงคของเราคือการเพิ่มรายไดการขายจาก 30 ลานบาทเปน 35 ลานบาทในป 2545 เราคาดหมายวานี่จะบรรลุ ความสําเร็จไดดวยการจําหนาย 1 ลานหนวย ราคาหนวยละ 35 บาท

•

วัตถุประสงคของเราคือการเพิ่มคาใชจายโฆษณา 15 % ในป 2545

•

วัตถุประสงคของการเพิ่มสวนครองตลาดจาก 8 %เปน 10 % ภายในป 2545 โดยเราจะตองเพิ่มคาใชจายการโฆษณา 15 %

•

เปาหมายของการเปนผูบุกเบิกการวิจัยและพัฒนาและการเปนผูนําทางเทคโนโลยี่ภายในอุตสาหกรรม

•

เปาหมายของเราคือ

การเปนผูนําทางเทคโนโลยี่และอุปกรณสมัยใหมเพื่อที่จะประหยัดพลังงานไฟฟาแกลูกคาภายในป

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

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

•

การประเมินสภาพแวดลอมทั้งภายในและภายนอก (SWOT) ดึงจุดแข็งมาใชใหมากที่สุด

•

สรางกลยุทธหลายๆ กลยุทธ (portfolio of strategic alternatives are identifies)

•

ตัดสินใจเลือกกลยุทธที่เหมาะสม

•

การเชื่อมโยงสูหนวยงานระดับลาง

•

การดําเนินกลยุทธโดยใชวิธีการทํางานแบบโครงการ

3

4. การดําเนินกลยุทธโดยใชวิธีการทํางานแบบโครงการ (implementation through project) กลยุทธจะเปนจริงได ตองมีการสรางโครงการมารองรับ และสิ่งที่ตองเกี่ยวของคือ •

การจัดสรรทรัพยากร

•

องคกร

•

การวางแผนและระบบควบคุม

•

Motivating project contributors

•

Prioritizing projects ระบบในการจัดการ คัดสรรโครงการที่มีอยูหลายโครงการ มีความจําเปนเพื่อที่จะใหได project portfolio management

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

ชองวางในการปฏิบัติงาน การสื่อสาร ความเขาใจไมตรงกัน เกี่ยวกับการแปลนโยบายบริษัท

2.

การเมืองภายในองคกรกับการคัดเลือกโครงการ

3.

โครงการจํานวนมากกับการชวงชิงทรัพยากร (ซึ่งมีไมเพียงพอ) ตองมีระบบชี้แจง

การสรางสิ่งสนับสนุนสําหรับ central project portfolio management system การสงสัยและการตอตานการเปลี่ยนแปลง – แกไขโดย 1.

การที่ตองไดรับการสนับสนุนจากผูบริหารระดับสูง

2.

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

3.

สํารวจกระบวนการของ project และขอเสนอการยอมรับ project

Project portfolio management system ออกแบบ project portfolio system โดยการ

1.

1.

จัดกลุมประเภทโครงการ

2.

เลือกใชกติกาสําหรับแตละกลุม ที่อาจไมเหมือนกัน แตตองมีความชัดเจนและแนนอน

3.

ดูขอเสนอโครงการ

4.

ประเมินขอเสนอโครงการ

5.

การจัดการกับระบบนี้ทําไดอยางไร

การจัดกลุมประเภทโครงการ (Classification of project) 1)

Compliance projects จําเปนตองทําอยางยิ่ง (must do) ถาไมทําจะมีบทลงโทษ

2)

Strategic projects – มีผลตอศักยภาพการแขงขันขององคกรในระยะยาว ยังไมเห็นผลในตอนนี้ เชน R&D , NPD , การ พัฒนาประสิทธิภาพของกระบวนการผลิต

3)

Operational projects – โครงการที่เกี่ยวของกับฝายปฏิบัติโดยทั่วๆ ไป เชน การปรับปรุงคุณภาพ การลดคาใชจาย การ ทํา 5ส เปนการแกปญหางาน routine ขององคกร

2.

กฎเกณฑ หรือเงื่อนไขที่ใชในการเลือกโครงการ (Selection criteria) •

แตละกลุมอาจใชกฎเกณฑไมเหมือนกัน และการเปรียบเทียบจะทําในกลุมเดียวกันไมขามกลุม

•

กฎเกณฑตองสอดคลองไปในแนวเดียวกับกลยุทธขององคกร

•

กฎเกณฑจะขึ้นอยูกับธรรวมชาติขององคกร เชน อุตสาหกรรม ขนาด ทัศนคติเกี่ยวกับความเสี่ยง เทคโนโลยี การแขงขัน ตลาด รูปแบบการจัดการ

•

แตกอนใชแตเงื่อนไขทางการเงิน (financial criteria) แตปจจุบันควรใชหลายกฎเกณฑรวมกัน (NPV , IRR , B/C ratio : benefit cost ratio , Payback period)

•

ควรใชหลายเงื่อนไข (multiple screening criteria) 4

3. ขอเสนอโครงการ •

แหลงที่มาของขอเสนอโครงการ มาไดจากทั้งแหลงภายนอกองคกร เชน ลูกคา supplier หรือจากแหลงภายในองคกรที่ เห็นคุณคาวาโครงการสามารถสรางคุณคาใหกับองคกรได

•

ขอเสนอโครงการ (major project proposal)

รูป

4. การประเมินขอเสนอโครงการ (Evaluating project) ตองทําการประเมินตัวเองโดยทํา feasibility และทํา structure screening process (Project Screening Process)

เลือกกฎเกณฑที่สะทอนถึงปจจัยแหงความสําเร็จ (critical success factors) ขององคกร แลวใชตารางเพื่อใหคะแนน 5

Project Screening Matrix

Priority Analysis

6

Risk Analysis

ระบบการบริหารจัดการ ติดตาม ปรับปรุงเงื่อนไขของโครงการ (Managing the portfolio system) •

การเปลี่ยนแปลงสภาพแวดลอม

•

ตองมีการตรวจติดตามและปรับกฎเกณฑที่เลือก

•

จัดการกับกลุมเล็กๆ

•

Senior management ตองกําหนดนโยบายเพื่อสรางกฎเกณฑ / เงื่อนไข และการกระจายสัดสวนของโครงการ

•

หลังจากที่เลือกโครงการแลวหนาที่ความรับผิดชอบของ priority team คือ 1)

ยอมรับหรือปฏิเสธขอเสนอโครงการ แลวประกาศผลการตัดสินใจ เพื่อจัดสรรทรัพยากร

2)

สรางความโปรงใสในการพิจารณา วาไมมีอิทธิพลทางการเมือง และสรางความนาเชือ ่ ถือ

3)

ประเมินโครงการที่เราดําเนินอยูแลววามีอะไรบาง แตละอันมีลักษณะอยางไร

4)

ประเมินและติตตามสถานการณดานเปาหมายขององคกรมีการเปลี่ยนแปลงหรือไม

มีการเปลี่ยนแปลงลําดับ

ความสําคัญหรือไม 5)

เมื่อสภาพแวดลอมเปลี่ยน กฎเกณฑบางอยางตองมีการเปลี่ยนแปลงหรือไม

6)

ทําตาม project priority system วาอันไหนสําคัญกวาตองไดกอน และมีผลบังคับใช

7)

Balance Portfolio คือดูวาในองคกรมีโครงการประเภทใดมากแลว ก็ไปเพิ่มที่ประเภทอื่นบาง โดยการ balance จาก ประเภท / ความเสี่ยง / ความตองการทรัพยากร ดังนั้นโครงการที่มีคะแนนสูงๆ อาจไมไดรับการคัดเลือกก็ไดเมื่อดู หลายๆ อยางที่ประกอบกัน

7

*Technical feasibility – ความเปนไปไดทางเทคนิค ขอแนะนํา •

Pearl ดีที่สุด

•

White elephant – ไมอยากได

•

Bread and butter และ oyster ตอง balance อยางใหมากไปหรือนอยไป

8

Chapter 3 Organization : Structure and Culture เชื่อวา สิ่งตอไปนี้มีความสัมพันธกันสูง โครงสรางองคกรของ project mgt. : วัฒนธรรมองคกร : ความสําเร็จของ project mgt. มีคําอุปมาวาวัฒนธรรมเปนเหมือนแมน้ํา project เปนเหมือนเรือ – การพายเรือตามน้ําจะใชความพยายามนอยกวา Organizational culture เปนตัวสะทอนถึง ‘personality’ ขององคการ เหตุที่ตองมีโครงสรางตางไปจากบริษัทแม เพราะ 1.

งาน project เปน unique มีการเริ่มตนและสิ้นสุด ไมใชงาน routine

2.

เพราะเปนการยากที่ธุรกิจจะมีประสิทธิภาพ

ถามีผูรวมงานที่มีความหลากหลายในวิชาชีพมาทํางานอยูดวยกันแบบไมมี

โครงสราง Project management structures •

Organizing projects within the functional organization การจัดองคกรตามหนาที่

ขอดี :

คนที่จะมาดํารงตําแหนงเปนผูเชี่ยวชาญเฉพาะดานรูเรื่องนั้นชัดเจน

โครงการดําเนินงานโดยหนวยงานในบริษัทแม

จึงไมมีขอแตกตางดานการออกแบบและการ

ดําเนินงาน

ขอเสีย :

มีความยืดหยุนสูงในการใชบุคลากร สามารถสับเปลี่ยนผูเชี่ยวชาญไปทํางานในโครงการตางๆ

กรณีโครงการมีขอบเขตแคบ สามารถใชความชํานาญเจาะลึกไดอยางเต็มที่

บุคลากรสามารถเติบโตไปตาม career path เหมือนในโครงสรางปกติ

ยุงยากดวยการประสานงาน

ทุมเทใหกับโครงการไมเต็มที่ เพราะตองใสใจกับงานหลักใน function unit ของตน

ขาดการประสานงานที่ดีระหวาง function ตางๆ เพราะตางก็ใหความสําคัญกับงานของตน

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

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

1

•

Organizing projects as dedicated teams – การแยกโครงการออกมาจากงานหลัก จัดองคกรเฉพาะเรื่อง เฉพาะงาน คนที่มาทํางานในโครงการเชนนี้จะตองอุทิศตน หรือ task force มีระยะเวลาสั้นในการดําเนินโครงการ เปนโครงการ เรงดวน เฉพาะกิจ มุงความสําเร็จ เชน โครงการจัดทําระเบิดปรมาณูเมื่อครั้งอเมริกาพายใน WWII โครงการคิดคนยา รักษาโรคเอดส (โครงสรางเดิมเปน functional แตมีการสรางกลุมใหมเพิ่ม และดึงหัวกะทิของแตละฝายเขามาทํางาน)

ขอดี :

การดําเนินงานโครงการไมทําใหการทํางานของหนวยงานหลักหยุดชะงัก

โครงการมีแนวโนมที่จะทําไดเร็ว เพราะคนในโครงการมุงความสําคัญอยูในงานของโครงการ มีการ ติดตอสื่อสารกันภายในโครงการรวดเร็วกวา

ทีมงานมีขวัญ กําลังใจ มีความผูกพันสามัคคีกัน เพราะมีเปาหมายและภารกิจรวมกันตอความสําเร็จ ของโครงการ

เมื่อมีการจัดสรรทรัพยากรอยางเหมาะสม ทําใหเกิดการประสมประสานระหวางหนวยงานมาก (crossfunctional integration) ผูเชี่ยวชาญจากสายงานตางๆ ไดทํางานกันอยางใกลชิด

ขอเสีย :

คาใชจายสูงในการที่จะจัดใหมีทรัพยากรในโครงการอยางเต็มที่และเพียงพอ เชน ตั้งตําแหนงบริหาร ขึ้นใหม (project manager) ทํางาน full time ทําใหเกิดความซ้ําซอนกับสายงานหลัก

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

โครงการตองใชความเชี่ยวชาญเฉพาะดานหลายสาขา จากสายงานหลัก

ตองมีการปรึกษาหารือหรือขอความคิดเห็น

แตความรูสึกแบงแยกระหวางโครงการกับสายงานหลักจะทําใหเปนอุปสรรคในการ

ปรึกษาหารือได

เมื่อโครงการแลวเสร็จ เกิดปญหาการจัดการกับคนในโครงการที่ถูกสงกลับสายงานหลัก ไมสามารถ กาวหนาเหมือนเพื่อนในสายงานหลัก

2

สมาชิกทีมของ Dedicated team ไดจาก 1)

ระดมจากหนวยงานตางๆ ภายใน ขอดี :

ไมตองจางคนใหม เชี่ยวชาญเฉพาะสาขา

ขอเสีย : อาจถูกเขมนจากผูบังคับบัญชาตนสังกัด มีปญหาเรื่องขอความดีความชอบ อาจเสียขวัญ กําลังใจได 2)

จัดหาจากบุคคลภายนอก

ขอดี :

ไดคนมีประสบการณ

ขอเสีย: ถาไมมีโครงการตอไปอีก ตองเสียคนที่ออกไปพรอมกับ knowhow และประสบการณ ถาไปอยูกับคูแขงจะเปนปญหา 3)

ผสมผสานคนภายในและคนภายนอก

Project organization structure แยกเปน project แตละ project จัดองคกรแบบ functional เชน CP มี project เมื่อ ดําเนินการเสร็จแลวจึงตั้งเปนบริษัทในเครือ (จัดแบบ functional ภายใต functional นั้นตั้ง project manager (α , β) ซึ่งภายใต project จะมี engineer , ผลิต , จัดซื้อจัดหา

•

Organizing projects within a matrix arrangement

Matrix management เปนการไขวกัน โดยในแนวนอนเปน normal functional ปกติมี 2 chain of command โดยเปน functional lines และอีกอันเปน project lines การมอบหมายเปนอิสระตอกัน ผูรวม project รายงานทั้ง functional และ project manager

จัดองคกรแบบ functional มี director of project ดึงคนจาก function มาทํางานในโครงการ บางขณะยืมคน ระหวาง project ดวย

มักเปนโครงการขนาดใหญ (megaproject) เชน โครงการสรางทางดวน เมือ ่ งานเสร็จสงคนกลับ บาง project จางคนใหมหมด เอามาฝกใหเกง แตถาไมมีงานตอเนื่องเขาจะลาออกและอาจไปอยูกับคูแขงได

หลายบริษัทอาจทํา matrix ตางกัน บางบริษัททําเปนถาวร บางบริษัททําเปนชั่วคราว แตแบบทั่วๆ ไปมี ลักษณะดังรูป จากรูปมี project 3 project คือ A, B, C project manager A, B, C รายงานตอ director ของ project management ที่ดูแลทั้ง 3 project แตละ project มี administrative assistant แมวา project C จะเปนแค part time

3

Project A เกี่ยวของกับการออกแบบและขยาย production line ไปทํา metal alloy เพื่อใหบรรลุผล project A ไดมอบหมาย 3.5 คนจากสวนผลิต 6 คนจากวิศวกรรม ทํา full time /part time

Project B เปนการพัฒนา new product ที่ตองการนําเสนอดาน engineering การผลิต และ marketing

Project C เกี่ยวกับการพยากรณการเปลี่ยนแปลงความตองการของลูกคาเดิม

Matrix

structure

ออกแบบมาเพื่อใหการใชประโยชนจากทรัพยากรไดอยางเต็มที่

โดยสามารถใชไดใน

หลาย project ดีพอๆ กับงานแบบ functional ปกติ ในเวลาเดียวกัน วิธี matrix พยายามที่จะไปใหถึงการ ประสมประสานการสรางและอํานาจทางกฎหมายของ project manager

•

Different matrix forms

Matrix system มีหลายชนิดขึ้นกับความสัมพันธของ authority ของ project กับ functional manager วา เปน weak , lightweight หรือ functional matrix โดย balanced หรือ middle weight matrix

ความสัมพันธที่แตกตางกันใน power ระหวาง functional manager กับ project manager จะสะทอนที่ จํานวน related dimension ดังนี้ 1.

ระดับของ reporting relationship : project manager ที่ report โดยตรงกับ CEO จะมีอิทธิพล มากกวา marketing manager ที่รายงานตอ VP of marketing

2.

location ของ project activities : project manager จะมีอิทธิพลตอผูรวม project ถาทํางานใน office ของเขามากกวาที่จะทํา project-related activities ใน functional offices

3.

% of full time staff ที่ถูก assign ใหกับ project

4.

ขอบเขตที่ project manager มีอํานาจโดยตรงตอผูรวมงาน โดยดูที่ความสามารถในการโนมนาว ชักจูงผูจัดการที่เกี่ยวของ และรับรูถึงความสําคัญของ project หรือ prescribed power (อํานาจใน การกําหนด/อางสิทธิ์) ของ project manager

5.

1)

ผูประเมินผลการปฏิบัติงานและตัดสินใจใหผลตอบแทน

Functional matrix ¾

การจัดองคกรเหมือน functional organization

¾

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

4

สถานะของงานเพื่อใหโครงการบรรลุความสําเร็จ

มีอํานาจทางออมในการเรงรัดและติดตาม

โครงการ ¾

Functional manager รับผิดชอบบริการในสวนงานที่ตนรับผิดชอบในโครงการ มีอํานาจสั่งการวา ใครจะตองทําอะไร และเมื่อไร

¾

การพิจารณาความดีความชอบบุคลากรในโครงการ

อยูในความรับผิดชอบของ

functional

manager 2)

Balances matrix ¾

Project manager เปนผูพิจารณาวาจําเปนตองทําอะไรบาง เปนผูกําหนดแผนงานโดยรวมของ โครงการ ประสานงานกิจกรรมตางๆ กําหนดตารางงาน และติดตามความกาวหนาของงาน

¾

Functional manager เปนผูพิจารณาวาจะตองทําอยางไร เปนผูมอบหมายบุคลากร และดําเนินงาน ที่รับผิดชอบตามมาตรฐานและตารางงานที่ project manager กําหนด

¾

เปนการประสมประสานทางดานเทคนิคและการปฏิบัติเขาดวยกัน

¾

การพิจารณาความดีความชอบ

พิจารณาจากผลการประเมินของทั้ง

project

manager

และ

functional manager 3)

Project matrix ¾

Project manager เปนผูควบคุมงานสวนใหญของโครงการ รวมถึงการมอบหมายงานใหกับคนใน สายงานหลัก เปนผูตัดสินใจในโครงการ

¾

Functional manager เปนผูบังคับบัญชาตามสายงาน ใหคําปรึกษาเมื่อจําเปน

¾

บางกรณี functional unit รับเปน subcontractor ของโครงการ ซึ่งตองทําตามขอกําหนดของ โครงการ

¾

การพิจารณาความดีความชอบ ใหน้ําหนักความสําคัญกับผลการประเมินของ project manager

ทั้ง 3 แบบมีขอดีขอเสียแตกตางกัน โดย project matrix จะทําใหการประสมประสานของ project ดีขึ้น ลด ความขัดแยงในอํานาจภายในและสามารถเพิ่มการควบคุมกิจกรรมของ project และ cost ได แตจะไมไดดาน technical quality เพราะมีการควบคุมนอย สวน functional matrix พัฒนา technical quality และมีระบบ จัดการความขัดแยงระหวาง project ไดดี เพราะวา functional manager ไดมอบหมายบุคคลใหแตละ project ปญหาที่พบมักเปนคาใชจายของ poor project integration สวน balance matrix จะไดความสมดุล ระหวาง technical และ project requirement แตจะบอบบางในการสรางและบริหาร และมักจะลมเพราะ ปญหาที่เกิดขึ้นอยางมาก

ขอดีขอเสียของการจัดองคการแบบ matrix ขอดี :

คนที่ยืมมาเปนคนที่มีความรูความสามารถ ตรงกับงานที่ตองการใช

สามารถใชทรัพยากรรวมกันไดหลากหลาย ลดความซ้ําซอนการจัดหาทรัพยากร

มี project manager เปนผูรับผิดชอบงานของโครงการอยางเปนทางการ ไดประโยชนในภาพรวม

โครงการสามารถเขาถึงขอมูล เทคโนโลยี ผูเชี่ยวชาญ ที่อยูในสายงานหลักไดทั้งหมด

ความยืดหยุนในการใชทรัพยากรและความชํานาญในบริษัท

5

ขอเสีย :

การพิจารณาความดีความชอบ

การบังคับบัญชา กอใหเกิดความขัดแยงระหวาง project กับ function

ไมมี unity of command มีเจานายหลายคน

เมื่อ project เสร็จ ตองสงคนที่ยืมมา ซึ่งอาจกลับไปแลวไมมีตําแหนงลง

ทักษะที่ไดจากการทํางาน project ไมมีโอกาสนําไปใชตอ ทําใหสูญเปลา

การใชทรัพยากรรวมกันอาจกอใหเกิดความขัดแยงและแขงขัน

จริงๆ แลวการมี project manager จะเรงให project เสร็จสมบูรณเร็วขึ้น แตในทางปฏิบัติมักจะมีขอ ขัดแยงระหวาง functional group หลายๆ group โดยเฉพาะใน balance matrix

•

Organizing projects within virtual organizations

ความรวมมือกันของหลายๆ องคกร เพื่อจุดประสงคในการสราง product หรือ service ใหกับลูกคา โครงสราง การรวมมือประกอบดวยหลายๆ องคกรอยูลอมรอบ hub หรือ core firm ซึ่งมี core competencies 1-2 ดาน เชน marketing หรือ พัฒนาผลิตภัณฑ ดังตัวอยาง ที่บริษัทหลักเปนตนกําเนิดความคิด แลวติดตอกับบริษัท อื่นๆ ใหทําสวนประกอบอื่น รูป Mountain bicycle virtual project

ขอดีขอเสียของการจัดองคการแบบ virtual ขอดี :

cost reduction รักษา competitive price สําหรับ contracted service ตัด overhead cost

ไดความชํานาญและเทคโนโลยีในระดับสูงจากภายนอก

ไมตอง

keep

up

ความกาวหนาทาง

เทคโนโลยี สามารถไป focus ที่ core competencies แลวจางบริษัทที่ชํานาญดานตางๆ มาทํางาน ให

เพิ่มความยืดหยุน บริษัทจะไมมีขอจํากัดดาน resource สามารถปฏิบัติงานไดในชวงกวาง

โดยการ

combine resources ของบริษัทกับ talent ของบริษัทอื่น ขอเสีย :

การรวมมือกันของหลายบริษัทเปนเรื่องทาทาย ถา project นั้นตองการการรวมมือกันอยางใกลชิด และตองปรับตัวเขาหากันและกัน โครงสรางของ project manager มีแนวโนมที่จะทํางานไดดีเมื่อแต ละ party รับผิดชอบในงานที่ defined ไวอยางดี และ independent deliverable โดยเฉพาะงานดาน กอสราง

6

เสียศักยภาพในการควบคุม project เพราะ core team จะขึ้นอยูกับบริษัทอื่นดวย ซึ่งเขาไมมีอํานาจ ในการควบคุมโดยตรง

สวนบริษัทอื่นที่จะสามารถอยูรอดไดในระยะยาวจะขึ้นอยูกับ

performance

project จะไปไดไมดีถามีบริษัทใดบริษัทหนึ่งมี performance ไมถึง

มีแนวโนมที่จะเกิด interpersonal conflict เพราะผูรวมงานแตละคน ไมได share same value , priorities และ culture ความเชื่อใจเปนสิ่งสําคัญตอการประสบความสําเร็จของ project ซึ่งเปนการ ยากที่จะหลอหลอมเมื่อ interaction มีขอจํากัดและคนมาจากตางบริษัท

หลายๆ virtual project มักทําในบรรยากาศ electronic ที่มีการ link กันดวยคอมพิวเตอร , fax , CAD , video teleconferencing เผชิญหนากันนอย บางอยางก็มีการทํางานใกลชิดกันโดยแบงพื้นที่ทํางานรวมกัน หรือบางแบบใหคนจากบริษัทใหมาใหบริการชั่วคราวไมไดเปนสมาชิกอยางเปนทางการ

เปนแค

technical

expert ที่เปนพันธมิตรชั่วคราว Choosing the appropriate project management structure •

การเลือกโครงสรางแบบใดดีสําหรับ project ไมมีคําตอบที่แนนอน ตองดูทั้ง organization level และ project level 1.

organization level คําถามแรกตองถามวา project management สําคัญตอความสําเร็จขององคการเพียงใด ถาคําตอบบอกวาสําคัญมากกวา 75% แสดงวาตองเปน projectized organization แตถาองคการมีทั้ง standard products และ project ก็ใช matrix จะเหมาะ แตถามี project เปนสวนนอย ก็จัดองคการแบบไม ตองเปนทางการมาก คําถามที่สอง คือ ความสามารถในการหา resource ไดหรือไม (resource availability) แบบ matrix ตอง share resource ขาม project แตยังตองมี functional ในขณะที่เวลาเดียวกันก็สราง legitimate project leadership สําหรับองคกรที่ไมสามารถยึด critical personnel ในแตละ project ได ใช matrix เหมาะสมหรืออาจเปน dedicated team แต outsource project work เมื่อไมสามารถหา resource ได

2.

ในระดับ project level คําถามคือ project ตองการความเปนอิสระเพื่อใหประสบความสําเร็จอยางสมบูรณ Hobbs and Menard ระบุปจจัย 7 อยางที่มีอิทธิพลตอการเลือกโครงสรางของ project ประกอบดวย 2.1

size of project

2.2

strategic importance

2.3

novelty and need for innovation

2.4

need for integration (number of departments involved)

2.5

environmental complexity (number of external interfaces)

2.6

budget and time constraints

2.7

stability of resource requirements

ยิ่งมีระดับของปจจัยตางๆ เหลานี้สูงขึ้นเทาใดก็ตองการความเปนอิสระ (autonomy) และ authority ของ project manager และ project team มาก จะเปนตัวบอกวาจะใช dedicated project team หรือ project matrix structure ถา project ขนาดใหญ มีกลยุทธที่ critical และใหมสําหรับบริษัท และตองการ innovation ตองจัดโครงสรางองคการเปน complex multidisciplinary project ที่ตองการ input จากหลาย แผนก พอๆ กับที่ตองการการติดตออยางสม่ําเสมอกับลูกคาเพื่อที่จะใหไดสิ่งที่ลูกคาคาดหวัง , dedicated project team ใชกับ project ที่เรงดวนที่ตองการใหมีคนทํางานตั้งแตตนจนจบ •

หากไดรับมอบหมายงานใหเปนผูบ  ริหารโครงการพัฒนาผลิตภัณฑใหมหรือโครงการกอสราง ควรจัดองคกรแบบใด – ตอบวาดูวัฒนธรรมองคกรกอน วาเปนแบบใด ดังนั้นควรจัดองคกรแบบใด (ที่สอดคลอง) ซึ่งมีขอดี / ขอเสีย และมีความ เหมาะสมอยางไร

7

•

ผลการวิจัยการจัดองคกรกับประสิทธิภาพงาน - กอสรางทํา project matrix ดีที่สุด

•

ปจจัยในการพิจารณาเลือกรูปแบบการจัดองคการ 1)

ขนาดโครงการ

2)

ระยะเวลาโครงการ

3)

ประสบการณของผูบริหารโครงการ

4)

ปรัชญา วิสัยทัศนของผูบริหารระดับสูง ความสําคัญในเชิงกลยุทธของโครงการ

5)

สถานที่ตั้งของโครงการ

6)

ทรัพยากรที่มีอยู

7)

ลักษณะเฉพาะของโครงการ

8)

ความจําเปนของนวัตกรรม

9)

การประสานงาน (จํานวนหนวยงานที่เกี่ยวของ)

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

การแตงกายของพนักงาน

การจัดวางผังโรงงาน

แตสวนใหญจมอยูใตผิวน้ํา

ซึ่งเปนสวนที่มองไมเห็น

เชน

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

•

What is organizational culture?

1)

Member identity – การรวมกันขององคกรมุงไปที่งานใดงานหนึ่งที่ตนไดรับผิดชอบเฉพาะ หรือมุงไปที่ ความสําเร็จขององคกรโดยรวม

2)

Team emphasis – ทํางานเปนทีมหรือไม ถาไม จะทําใหการทํางานโครงการยาก

3)

Management focus – ผูบริหารมุงเนนงานหรือคน หรือทั้งสองอยาง

4)

Unit

integration

–

การประสมประสานของงานมุงเนนไปที่แผนกของตนโดยเฉพาะหรือมุงเนนการ

ประสานงานกับแผนกตางๆ

8

5)

Control – การควบคุมเปนแบบหลวมหรือเขม เวลาทํางานยืดหยุนหรือมีการตอกบัตรลงเวลาอยางเครงครัด

6)

Risk tolerance - องคกรกลาเสี่ยงมากนอยเพียงใด

7)

Reward criteria – เกณฑในการใหความดีความชอบ ยึดถือผลงานหรือปจจัยอื่นๆ

8)

Conflict tolerance – มีความขัดแยงกันมากนอยเพียงใด มีความอดทนตอความขัดแยงไดมากนอยแคไหน แกไอยางไร

9)

Means versus end orientation – การที่มอบหมายงานไปนั้น จะเนนที่ผลสําเร็จของงานหรือเนนที่วิธีการ (ถูกตอง มีจริยธรรม)

10) Open-system focus – การบริหารงาน กําหนดกลยุทธ วางแผน ศึกษาแตปจจัยภายในหรือศึกษาเปดกวาง เรื่องที่เปนสากล (ปจจัยภายนอก)

วัฒนธรรมที่เอื้อตอการดําเนินโครงการ •

Culture มีหนาที่ที่สําคัญในองคการ โดย 1)

provide a sense of identity ใหสมาชิก

2)

helps legitimize the management system บอกถึงอํานาจความสัมพันธที่ชัดเจน และใหเหตุผลวาทําไม คนจึงอยูในตําแหนง และทําไม authority ควรไดรับการนับถือ มากไปกวานี้ culture through myths, stories และ symbols จะชวยในการ reconcile จุดที่เห็นพองกันระหวาง ideal กับ actual behavior

3)

clarified and reinforces standards of behavior วัฒนธรรมจะชวย define วาพฤติกรรมอะไรที่ยอมรับได หรือพฤติกรรมใดที่ไมเหมาะสม โดยพฤติกรรมครอบคลุมตั้งแตการแตงกาย ชั่วโมงการทํางานที่ ทาทาย judgment ของหัวหนางาน การรวมงานกับแผนกอื่น

4)

ชวยสรางลําดับขั้นทางสังคมในองคการ

วัฒนธรรมองคการใดที่ strong อาจใชแทนเปน core values หรือ customs ที่ใชกวางขวางในองคการไปเลย ใน บางครั้งอาจตองพบกับ subculture (culture ของแตละแผนก)

9

•

การศึกษาวัฒนธรรมองคการ (Identifying cultural characteristics) 1)

ศึกษาลักษณะทางกายภาพขององคการ ไดแก สถาปตยกรรม การสางผังหองทํางาน การตกแตงอาคาร สํานักงาน การแตงกาย

2)

ศึกษาจากเอกสารตางๆ ขององคการ ไดแก รายงานประจําป จดหมายขาวภายใน วิสัยทัศน ภารกิจ เอกสาร เผยแพรขาว

3)

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

4) •

เรื่องราวที่เลาขานตอกันมาในองคกร ไดแก วีรบุรุษ คนเลว

Project manager ตองสามารถ operate ไดในหลายๆ รูปแบบ โดย

ตอง interact กับ culture ของบริษัทแม , subculture ของแผนกตางๆ

ตอง interact กับ culture ของบริษัทลูกคา

ตอง interact กับ culture ขององคการที่บริษัทแมติดตอดวย เชน suppliers , vendors , subcontractor , consulting firms , government and regulatory agencies , ชุมชน

การธํารงรักษาวัฒนธรรมองคการที่เอื้อตอการดําเนินโครงการ (Implications of organizational culture for organizing projects) วิธีในการธํารงรักษาวัฒนธรรมองคการ

Formal statement of principles กําหนดหลักการ แนวคิดที่เปนลายลักษณอักษร

Top management behavior ผูบริหารประพฤติตัวเปนตัวอยาง

Reactions to organizational crisis ฝายบริหารมีบทบาท วิธีการแกไขอยางฉับไว

จัดใหมีระบบพิจารณาความดีความชอบที่ดี เหมาะสม ยุติธรรม

จัดใหมีพิธีการ เรื่องราว ประวัติ สรางสัญลักษณ เพื่อเตือนใจและสรางความเชื่อถือ ↓ ตองดู

คัดเลือกพนักงานที่ เหมาะสมกับ culture ที่ องคกรมีอยู

Organizational culture →

ใหคนที่มีพฤติกรรมที่ไม →

เอื้ออํานวยตอวัฒนธรรม องคกร ออกไป

10

Chapter 4 Defining the Project การจัดทําโครงรางเพื่อเปนฐานขอมูลโครงการ เพื่อใชในการวางแผน ทํากําหนดการ และการควบคุมโครงการ เพื่อใช ในทุก phase ของทุกชวงอายุของโครงการ และเพื่อสนองความตองการของผูที่เกี่ยวของทุกคน และเพื่อวัดผลการดําเนินงาน ใหเปนไปตามแผนกลยุทธของบริษัท - ขอบเขตโครงการ (Scope) – บอกวาอะไรคือสิ่งที่เราคาดหวังวาจะสงมอบใหกับลูกคาเมื่อจบโครงการ - โครงสรางจําแนกงาน (Work breakdown structure : WBS) 5 ขั้นตอน 1)

การระบุของเขตงานโครงการ (Defining the project scope)

2)

การกําหนดความสําคัญของโครงการ (Priority Matrix)

3)

การสรางโครงสรางจําแนกงาน (WBS) แผนภูมิตน  ไมระบุรายละเอียดกิจกรรมที่ทําใหโครงการสําเร็จ

4)

การประสานโครงสรางจําแนกงานใหเขากับองคการ : มอบหมายผูรับผิดชอบ

5)

การลงรหัสโครงสรางจําแนกงานเพื่อระบบสารสนเทศ : เพื่อใหงายในการติดตาม

1. การระบุขอบเขตโครงการ (Defining the project scope) •

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

•

ขอบเขตโครงการตองแสดงในรูปผลลัพธที่เฉพาะเจาะจง จับตองได สามารถวัดได

•

การระบุขอบเขตโครงการที่ชัดเจนเปนปจจัยหนึ่งแหงความสําเร็จในการบริหารโครงการ

ใชวางแผน

ติดตาม

ความกาวหนาของโครงการ •

ผูจัดการโครงการและลูกคารวมกันพิจารณาขอบเขตโครงการ

•

ผูจัดการโครงการมีหนาที่ในการตรวจสอบวามีขอตกลงอะไรบางที่ไดทําสัญญาไวกับเจาของโครงการ

•

ขอบเขตโครงการจะตองทําเปนลายลักษณอักษร เพื่อเขาใจตรงกัน เรียก statements of work (SOW)

ขอบเขตโครงการประกอบดวย (checklist) 1. วัตถุประสงคโครงการ (Project objectives) บาน ฐานราก หลังคา ผนัง

2. ผลลัพธจากโครงการที่ตองสงมอบ

บอก End results บรรลุวัตถุประสงคเบื้องตน เชน program ที่สามารถ เปลี่ยนภาษาอังกฤษไปเปนภาษารัสเซียโดยอัตโนมัติ -

What (Performance)

-

When (Time)

-

How much (Cost)

ในระหวางชวงเวลาของการดําเนินโครงการจะตองสงมอบอะไรบาง (time ,

(Deliverables) เปนผลลัพธยอย หรือ

quantity , cost estimate) เชน ชวงแรก – list of spec., 2-software ,

output อยางหนึ่งแตยังไมสุดทาย

3-test prototype , final – final test , approved software

3. กําหนดการที่สําคัญ (Milestones)

4. เทคนิคที่จําเปน (Technical requirements) 5. ขอจํากัดตางๆ (Limits & exclusions)

-

เปนเหตุการณสําคัญๆ ที่เกิดขึ้นในโครงการ

-

อาจเปนสวนหนึ่งของงานสําคัญๆ ในโครงการก็ได

-

Milestones จะเปนจุดควบคุมที่สําคัญของโครงการ

-

Milestones ควรจดจํางาย

-

ควรบอกสวนประกอบหลักของงาน

-

ระบุ estimate time , cost , resource

-

จะตองระบุเพื่อใหไดผลงานที่เหมาะสม

เชน

การระบุ

speed

,

capacity ของ database system และการตอกับระบบอื่น เชน การดูแลรักษาโดยผูรับเหมาจะถูกกระทํา 1 เดือนหลังการสงมอบงาน โดยผูรับเหมาเปนผูรับผิดชอบคาใชจายทั้งสิ้น

ทั้งนี้

ไมรวมคาใชจายใน

กรณีที่เสียอันเกิดจากการใชงานที่ไมถูกตองของผูวาจาง 6. การทบทวนขอบเขตโครงการกับลูกคา

เพื่อทําความเขาใจและเห็นพองใน 5 ขอขางตนวาเปนไปตามที่คาดหวัง

(Reviews with customer)

1

2.

การกําหนดความสําคัญของโครงการ (Establishing Project Priority) เปนการกําหนดความสําคัญของ Parameter แตละตัวซึ่งมีผลตอคุณภาพของโครงการ ซึ่งอาจตองมีการ trade-offs กัน ไดแก

scope

1)

Performance (Scope)

2)

Time (Schedule)

3)

Cost (Budget)

quality cost

time

การจัดลําดับความสําคัญแบงเปน 3 ระดับ คือ 1)

Constrain : กําหนดแนนอน เปลี่ยนแปลงไมไดทั้งเวลา , spec. , scope , budget

2)

Enhance : ลดได/สงเสริม ถาเปนการเพิ่ม Value ใหโครงการ (Value added)

3)

Accept : ยอมใหคลาดเคลื่อนจากที่กําหนดไว

Parameter ที่ใชในการจัดลําดับความสําคัญมีความสําคัญไมเทากัน จึงตอง trade-off ตัดสินใจเลือก

ตัวอยาง Project Priority Matrix : การพัฒนา new high-speed modem

คงที่ เพิ่มมูลคา ยอมได

•

การพัฒนา new high-speed modem ซึ่งเวลาในการนําสินคาออกสูตลาดเปนเรื่องที่สําคัญสําหรับการขาย จะ ไดเปรียบจากทุกๆ โอกาสที่สามารถลดเวลาเพื่อการแขงขัน และการที่จะยอมใหเปนแบบนี้ได cost หรือ budget ตองยอมใหเปนแบบ accept ได ในขณะที่ performance (specification) ตองเปนแบบ standard ที่เชื่อถือได ไม มีการเปลี่ยนแปลง หรืออีกตัวอยางหนึ่งคือ ถาบริษัทที่มีการดําเนินงานคลายๆ กับ Microsoft จะออก product หนึ่ง เพื่อเปนผูแรกในตลาด ดังนั้น time สําคัญที่สุด (constrain) และถา budget ถูกกําหนดไวแลว ดังนั้นตัว scope ตองยอมมีการประนีประนอมเพื่อให project เสร็จทันเวลา

3.

การสรางโครงสรางจําแนกงาน (Creating the work breakdown structure) •

การแตก project เปนงานยอยๆ ผลลัพธของแตละงานยอยเรียกวา work breakdown structure (WBS)

Hierarchical breakdown of the WBS

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

2

•

จากรูป เริ่มจาก project (ซึ่งเปน final deliverable) จนสุดทายได work package หลายๆ อัน ซึ่งจะถูกจัดกลุม ตามประเภทของงานเพื่อติดตามความคืบหนาของ project ในดานงาน cost และความรับผิดชอบ

•

Work package เปนงานในชวงเวลาสั้นๆ ที่บอกชวงเวลาเริ่มตนและสิ้นสุด ทรัพยากรที่ใช ตนทุน

•

แตละ work package คือ control point

•

Work package manager รับผิดชอบในการดูวา package นั้นจะเสร็จทันเวลาหรือไม อยูในงบประมาณหรือไม

ประโยชนของ WBS -

แสดงรายละเอียดองคประกอบของโครงการตามลําดับชั้นของกรอบการทํางาน

รวมทั้งแสดงความสัมพันธของแต

ละองคประกอบ -

แสดงชองทางการสื่อสารและชวยในการสรางความเขาใจในงานและการประสานงานระหวางหนวยงานในโครงการ

-

ชวยในการประเมินคาใชจาย (cost) เวลา (time) และผลการทํางาน (technical performance) ในทุกระดับชั้นใน องคกรตลอดอายุของโครงการนั้นๆ

ทําใหสามารถวางแผน กําหนดตารางการทํางาน และงบประมาณได

สามารถใชเปนกรอบในการติดตามควบคุมคาใชจายและผลงาน

โดย

รวมทั้งวัดผลการทํางานของแตละหนวยงานได

ดวย เมื่อเกิดปญหาจะสามารถรับรูไดอยางรวดเร็ว -

ใหขอมูลแกผูบริหารในแตละระดับ เชน ผูบริหารระดับสูงจะใหความสนใจในผลลัพธสําคัญๆ ของโครงการ ในขณะ ที่หัวหนางาน (first-line) จะสนใจกับ work package หรือ sub-deliverables เล็กๆ ลงมา

-

ในการสราง

WBS

จะมีการมอบหมายความรับผิดชอบใหกับแตละหนวยงาน

และคนแตละคน

เพื่อให

work

package บรรลุความสําเร็จ ซึ่งเปนการประสานระหวางงานกับองคกร ใหสอดคลองกัน

ตัวอยาง WBS Project

for top manager

deliverable for middle manager subdeliverable subdeliverable

for first line manager

การสราง WSB

4.

1)

What : กําหนดวามีงานอะไรบาง

2)

How long : กําหนดเวลาที่ใชเพื่อใหงาน (work package) แลวเสร็จ

3)

Cost : กําหนดงบประมาณตามชวงเวลาตางๆ เพือ ่ ให work package แลวเสร็จ

4)

How much : กําหนดทรัพยากรตางๆ ที่จําเปนในการทําให work package แลวเสร็จ

5)

Who : กําหนดผูรับผิดชอบแตละหนวยของงาน

6)

กําหนดจุดติดตามวัดความกาวหนาของงาน

การประสานโครงสรางจําแนกงานใหเขากับองคกร (Integrating the WBS with the organization) •

WBS คือการประสานความรับผิดชอบของแตละหนวยงานขององคกรในการทํางาน ผลงานของ process นี้เรียกวา organizational breakdown structure (OBS) ซึ่งจะเปนตัวบอกวาองคกรไดมอบหมายความรับผิดชอบของงาน ออกไปอยางไร 3

•

•

วัตถุประสงคของ OBS ¾

เพื่อจัดหากรอบงานเพื่อสรุปงานของแตละหนวยงานในองคกร

¾

ระบุหนวยงานในองคกรที่รับผิดชอบ work package

¾

ยึดหนวยงานในองคกรกับ cost control accounts

จากรูป จุดตัดของ work package และ organizational unit ทําใหเกิด project control point (cost account) ซึ่งรวบรวมงานและความรับผิดชอบ

•

จุดตัดของ WBS และ OBS เปน set ของ work package ที่จําเปนเพื่อที่จะทําใหเกิด subdeliverable ที่อยู ดานบน และหนวยงานที่รับผิดชอบดานซายมือบรรลุผลอยางสมบูรณ เชน circuit board จะมี work package ของ แผนก design , production , test , software การควบคุมอาจตรวจสอบไดจาก 2 ทางคือ ผลงาน และความ รับผิดชอบ

•

ใน execution phase ของ project ความคืบหนาถูกติดตามแบบแนวตั้งที่ deliverable (client’s interest) และ แนวนอนโดยความรับผิดชอบขององคกร (management’s interest)

5.

การลงรหัสโครงสรางจําแนกงาน เพื่องานสารสนเทศ (Coding the WBS for the information system) การลงรหัสจะเปนประโยชนตอการใช WBS โดยใชในการจัดทํารายงาน สวนใหญจะกําหนดเปนตัวเลข เชน 1.0 Computer project 1.1 Disk storage unit 1.1.1

Floppy

1.1.2

Optical

1.1.3

Hard

…

Project Rollup •

จุดตัดระหวาง WBS กับ OBS แสดงถึงจุดควบคุม (control point) ที่เรียกวา “Cost account” ใชในการติดตาม ควบคุมงานของแตละ work package โดยในแตละ work package จะมีเวลา งบประมาณ ทรัพยากร ความ รับผิดชอบ และ จุดควบคุม

4

Work package estimates

•

จุดตัดของ circuit board และ production แสดง 2 work packages ใน cost account มีมูลคา $140 และ $260 มูลคารวม $400 , rollup to circuit board element (ผลรวมของ cost accounts ใต element) เปน $1,000 ใน hard disk element ซึ่งเปน first-level element มี budget $1,660

•

ตัวอยาง แผนก design รับผิดชอบ work package ที่เปน circuit board และ read / write head โดยมี cost account อยางละ $300 รวมเปน $600 , manufacturing section มี budget $1,250 ดังนั้น total for the organization delivering ของ hard disk element = total budget ของ all elements rolled up to the hard disk element

•

หนวยอาจไมตองเปนตัวเงินก็ได อาจเปน resources , labor hours , materials , time หรืออื่นๆ โดย cost account level ตองมีหนวยเดียวกันทั้งโครงสราง

Direct labor budget rollup (000)

5

Process Breakdown Structure (PBS) •

WBS : เหมาะกับการออกแบบสรางโครงการที่มีผลลัพธของโครงการเปนสิ่งที่จับตองได เชน การผลิตสินคา รถยนตรุนใหม ซึ่ง project จะถูกแตกออกเปน major deliverables , further subdeliverable , … , work package

•

PBS : ใชกับโครงการที่มีลักษณะเปนงานบริการ หรือโครงการที่แบงเปน Phase หรือ ระยะ เชน โครงการ IT

•

จะตองมีการกําหนดรายละเอียดเพื่อสื่อสารใหเห็นวาจําเปนตองทําอะไรใหแลวเสร็จบางจึงจะถือวาแตละ

Phase

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

ผลลัพธที่ตองการสําหรับแตละ Phase กอนที่จะเริ่ม Phase ตอไป

-

จุดตรวจสอบคุณภาพ (Quality checkpoint) เพื่อใหมั่นใจวาผลลัพธน้น ั สมบูรณและถูกตอง

-

มีการรับรองโดยผูมีสวนไดเสียที่รับผิดชอบทั้งหมดเพื่อชี้วาแตละ

Phase

นั้นแลวเสร็จสมบูรณ

และ

สามารถกาวตอไปยัง Phase ตอไปได

ตัวอยาง PBS

Responsibility Matrix (RM) หรื อ Linear responsibility chart •

ใชมอบหมายงาน เหมาะกับโครงการเล็กๆ ที่ไมซับซอนมาก (ไมจําเปนตองใช WBS หรือ OBS)

•

เปนการสรุปงาน (task) ตางๆ ที่ตองทําใหสําเร็จ และผูรับผิดชอบในแตละงานนั้น

ตัวอยาง RM

•

จากรูปเปน RM ของ market research study , R เปน committee member ที่รับผิดชอบในการประสานงานกับ ทีมอื่นๆ ในการมอบหมายงานเพื่อใหมั่นใจวางานนั้นสมบูรณ , S เปนสมาชิกของ five-person team ที่จะ สนับสนุน / ชวยเหลือผูรับผิดชอบแตละคน 6

•

RMs ที่งายๆ ใชสําหรับจัดการ (organizing) และมอบหมายความรับผิดชอบใหกับ project เล็กๆ เทานั้น และ ใชไดสําหรับ subproject ของ project ขนาดใหญ หรือ project ที่ซับซอนมากขึ้นได

•

RMs

ที่ซับซอนใชระบุความรับผิดชอบของแตละคน

และทําให

critical

interface

ระหวางคนหรือระหวาง

หนวยงานมีความชัดเจนมากขึ้น ดังตัวอยางในรูปขางลาง

•

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

7

Chapter 5 The Challenge of Estimating Project Times and Costs กระบวนการ estimate มี 2 วิธี 1.

top-down (macro , parametric) ) – มัก derived จาก analogy หรือ mathematical relationship

2.

bottom-up (micro) – มักขึ้นกับ element ใน WBS ทั้ง 2 วิธีมีความแตกตางกันเล็กนอย เมื่อทํา reconcile บาง สถานการณอาจใชทั้ง 2 วิธี

Factors influencing the quality of estimates

Planning horizon : ความถูกตองของการประมาณการจะมากขึ้นเมื่อ move จาก conceptual phase ไปยังจุดที่แตละ work package ถูก define

Project duration : เวลาที่ผานไป เกิด technology ใหมที่มีการเพิ่มแบบไมเปนเสนตรง

People : ทักษะของคนที่มีผลตอ productivity และ learning time เชน ความคุน  เคยกับคนที่เคยทํางานรวมกันมากอน ซึ่งมีผลกับการทํางานเปนทีม การ turn over ของ staff การที่คนเขางานใหมตองใชเวลาในการสื่อสารมากกวาคนที่อยูมา นานแลว

Project structure and organization : ถาตองการคนที่ทํางานดี อาจตองใชเงินมากเพื่อใหทํา full time แตถาทํา เปน part time ก็ตองใชเวลามาก

Padding estimates : เวลาที่เผื่อไว เชนถาถามวาใชเวลาไปสนามบินเทาไร ถาดูคาเฉลี่ยอาจตอบวา 30 นาที ซึ่งถา ขับรถเร็วกวานั้นก็อาจใชแค 20 นาที แตถาบอกวาไปพบ president ที่สนามบินจะตอบวาใชเวลา 50 นาที เพื่อใหแนใจวา ไม late โครงการก็เชนเดียวกันที่มีการเผื่อเวลาไว เพื่อลดความเสี่ยงที่สงงานไมทน ั แลวตองโดนปรับ

Organization culture : บางองคกรไมตองการการเผื่อเวลาไวหรือแมแตเวลาสวนตัวก็ตองจํากัด บางองคกรมีการให รางวัลถาสามารถประมาณการไดแมนยํากวาคูแขง

Other factors : non-project factors เชน equipment downtime , วันหยุดประจําป , กฎหมาย , ลําดับความสําคัญ ของ project (ซึ่งมีผลตอการจัดสรรทรัพยากร Æ time , cost))

Macro versus micro estimating •

สิ่งตอไปนี้มีอิทธิพลตอการที่จะเลือกใชวิธีการประมาณการแบบ macro (top-down) หรือ micro (bottom-up) 1.

มีความสําคัญเพียงพอหรือไม : การใชเวลาสําหรับการประมาณการทําใหสิ้นเปลืองคาใชจาย

2.

เวลา : บางองคกรคิดวาการอยูรอดตองเปนที่หนึ่ง ดังนั้นเนนการประมาณการเวลา , cost ไมใชประเด็นหลัก

3.

Project ที่เปน internal : ไมตองสนใจ cost

4.

มีความไมแนนอนอยูมาก : การใชเวลาและเงินในการประมาณการจึงเปนการสิ้นเปลือง

5.

Project มีขนาดเล็ก : ทําไดเลยโดยไมตองประมาณการ time , cost

6.

ใชการประมาณการตั้งแตตนสําหรับ “for strategic decision” ดังนัน ้ ก็ตองประมาณการตอไป

7.

เราถูกกดดันใหตองประมาณการในทุกๆ งานจากผูที่รับผิดชอบ ตาราง 5.1 Conditions for preferring top-down or bottom-up time and cost estimates Condition การตัดสินใจเชิงกลยุทธ Cost and time important High certainty Internal , small project Fixed-price contract Customer want details Unstable scope

Macro estimates X

Micro estimates X

X X X X X

1

•

การประมาณการแบบ top-down 1.

มักถูก derived จากคนที่มีประสบการณหรือมีขอมูลเพื่อหา project duration และ total cost

2.

มักทําโดย top manager ซึ่งมีความรูเกี่ยวกับ process ในการดําเนิน project นอยมาก

3.

เปน rough cut และมักเกิดขึ้นใน conceptual stage ของ project

4.

มีประโยชนในชวงเริ่มตนพัฒนาแผนที่สมบูรณ เปนวิธีการคราวๆ

5.

บางทีอาจไมมีนัยสําคัญ เพราะขอมูลที่รวบรวมไดมีนอย

6.

ไมพูดถึงในระดับแตละ work item

7.

บางกรณี การทํา top-down ก็ไมเปนจริง เพราะ top management ทําเพื่อตองการให project นั้นเกิด

8.

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

•

การประมาณการแบบ bottom-up (ทําที่ work package level) 1.

low cost , efficient สูง

2.

เกิดขึ้นหลังจากที่ project ถูก defined ในรายละเอียดแลว

3.

การประมาณการที่ดี

ควรมาจากคนที่รูในเรื่องที่ตองการประมาณการ

โดยเฉพาะจากคนหลายๆ

คนที่มี

ประสบการณเกี่ยวของกับงาน 4.

ชวยในการตรวจสอบ cost element ใน WBS โดยการ rolling up work package และเชื่อมโยง cost account กับ major deliverable โดยสามารถตรวจสอบและควบคุม resource , time

•

5.

ลูกคามีโอกาสเปรียบเทียบ low-cost กับ efficient method กับขอกําหนดดานเวลา หรือ performance

6.

(เสริม) อาจมีขอเสียที่แตละ WP มารเผื่อเวลาไว ทําใหเวลา และคาใชจายรวมมากกวาที่ควรเปน

โดยสรุปแลววิธีทางอุดมคติ คือวิธีที่ยอมให project manager มีเวลาเพียงพอในการทําทั้งการประมาณการแบบ top-down , bottom-up ที่จะวางแผนงานอยางสมบูรณและมีความเชื่อถือเพียงพอสําหรับลูกคา มีความผิดพลาด นอยสําหรับผูที่เกี่ยวของ และลดการตอรองจากลูกคา

Estimating project times and costs

Macro approaches for estimating project times and costs ใชในระดับกลยุทธ เพื่อประเมิน project proposal เพราะชวงเริ่มตน ขอมูลดานเวลาและ cost ยังไมเพียงพอ •

Ratio methods – ใชในชวงที่เปน concept หรือ need phase เชนการใช ft2 ประมาณการ cost , time เพื่อ ประมาณการการสรางบาน โดยบาน 2,700 ft2 มี cost $110/ft2 ผูมีประสบการณอาจบอกไดดวยวาใชเวลา 100 วัน นอกจากนี้อาจใช capacity size หรือการประมาณการพวก software product โดยใช feature และ complexity

•

Apportion method – วิธีการแบงสรร ใชเมื่อ project มีความคลายคลึงกับ project ที่ผานมาในอดีตดาน feature , cost ซึ่งเร็ว ใชความพยายามนอย มีความสมเหตุสมผล มักใชกับ product ที่คอนขางมีลักษณะเปน standard มี variation หรือ customization นอย รูป 5.1 Apportion Method of Allocation Project Costs Using the WBS

2

•

Function point methods for software and system projects – บางทีเรียก weighted macro variable หรือ major parameter วิธีนี้ตองอาศัยความถูกตองของขอมูลในอดีตเปนสําคัญ ตาราง 5.2 Simplifies basis Function Point Count process for a prospective project Element

Number Number Number Number Number

of of of of of

Complexity weighting Average High

Low

inputs outputs inquires files interfaces

____ ____ ____ ____ ____

x x x x x

2 3 2 5 5

+ + + + +

____ ____ ____ ____ ____

x x x x x

3+ 6+ 4+ 8+ 10 +

____ ____ ____ ____ ____

x x x x x

4+ 9+ 6+ 12 + 15 +

Total

= = = = =

_____ _____ _____ _____ _____

ตาราง 5.3 Example : Function Point Count Method Software Project 13 : Patient Admitting and Billing

15 5 10 30 20

Inputs Outputs Inquires Files Interfaces

Element

Inputs Outputs Inquires Files Interfaces

Rate Rate Rate Rate Rate

complexity complexity complexity complexity complexity

as low as average as average as high as average

Application of complexity factor Count Low Average

15 5 10 30 20

(2) (6) (4) (12) (10) High

x2 x6 x4 x 12 x 10 Total

Total

= = = = =

30 30 40 360 200 660

Function point count (660) , regression weight จาก project ในอดีต , cost และ duration (10 month) (in person months (130) and number of people (13) ) total cost of $1.2 million •

Learning curves – บาง project ที่มีงานคลายๆ กัน กลุมของงาน product ที่ตองทําซ้ําๆ จะเกิดการพัฒนาที่เกิด จากการทํางานซ้ําๆ กัน โดยปรากฏการณนี้มักเกิดกับ labor intensive ดังนั้น pattern ของการพัฒนานี้สามารถ นํามาใชทํานายเวลาในการทํางานที่ลดลงได

เรียกการพัฒนาที่เกิดจากการทํางานซ้ําๆ

นี้วา

learning

curve

(improvement , experience curve , industrial progress curve) ขอเสียของวิธีการนี้ คือ การที่ไมทราบถึง time , cost ของ specific task และการ grouping งานหลายๆ อยางไวในกลุมเดียวกัน ทําใหเกิด error ของการละเลย และการกําหนด time , cost

Micro approaches for estimating project times and costs •

Template method – ถา project เหมือนกับ project ในอดีต สามารถนํา cost ของ project เกามาเปนจุดเริ่มตน ของ project ใหมได โดยตองบันทึกความแตกตางของ project เกาและใหมไวดวย เพื่อทําการปรับสะทอนในความ แตกตางนั้น วิธีนส ี้ ามารถประมาณการ time , cost ไดในเวลาสั้น

•

Parametric procedure applied to specific tasks – คลายกับ parametric ของ macro ที่คิด cost จาก ft2 แตของ micro ใชการ applied กับ specific task เชน สวนหนึ่งของ MS Office 2000 conversion project มี 36 different computer work station เมื่อดู conversion project ในอดีต พบวา 1 คน สามารถ convert ไดเฉลี่ย 3 work station / วัน ดังนั้นถามีคน 3 คน จะใชเวลา = (36/3) / 3 = 4 วัน

•

Detailed estimates for the WBS work package – เปนวิธีที่คอนขางเชื่อถือได มีการใช WBS โดยใหผูที่ รับผิดชอบ work package ทําการประมาณการเพราะเขาจะรูจากประสบการณ หรือรูวาตองใชขอมูลจากที่ไหน

3

โดยเฉพาะ labor hour , cost ในกรณีที่มีความไมแนนอนสูงตองกําหนด 3 กรณี คือ low , average , high (PERT) โดย project manager และเจาของโครงการมีโอกาสประเมินความเสี่ยงที่อาจเกิดกับ project ได •

A hybrid : phase estimating ¾

การประมาณการ project แบบ macro แลวแตกยอยการประมาณการสําหรับ phase ของ project ที่ปฏิบัติ บาง project โดยธรรมชาติของมันไมสามารถกําหนดไดอยางถูกตองเพราะความไมแนนอนของ design หรือ final product เชน aerospace project , IT project , new technology project , construction project ซึ่ง design ไมสมบูรณ project เหลานี้มักใชการประมาณการ phase หรือ life cycle ตัวอยางเชน การ integrate ระหวาง wireless กับ computer

¾

Phase estimating

ใชเมื่อมีปริมาณความไมแนนอนที่ผิดปกติรอบๆ project หรือทําการประมาณการ time

และ cost ของ project ทั้งหมดไมได ใช detailed estimating เพื่อประมาณการ immediate phase ดังรูป 5.3 เมื่อ project ดําเนินไปและ specific ถูกกําหนดไว detailed estimate ของ design จะถูกสรางขึ้นและ สวนที่เหลือของ project จะถูกคํานวณ เมื่อ project คืบหนาไปมากเทาไรก็จะมีขอมูลมากขึ้นเทานั้น การ ประมาณการก็ถูกตองมากขึ้น ความนาเชื่อถือของ project ก็จะมีมากขึ้น ¾

ขอดี ลูกคามีโอกาสเปลี่ยน feature , re-evaluate หรือ cancel project ในแตละ phase ได

Level of detail •

Level of detail จะแตกตางกันในแตละระดับของการจัดการ ในแตละระดับควรมี detail ที่ไมมากไปกวาที่จําเปนและ เพียงพอ top management สนใจ total project , major milestones แมกระทั่งสิ่งที่ทําใหบรรลุผลสําเร็จได , middle management สนใจ milestones หรือสวนหนึ่งของ project , first-line manager สนใจสวนหนึ่งหรือ work package หนึ่งๆ

•

Level of detail ใน WBS จะ vary ตามความซับซอนของ project , ความตองการการควบคุม , ขนาดของ project , cost , ระยะเวลาของ project , ปจจัยอื่นๆ

•

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

•

ถา WBS เพิ่มขึ้น จํานวน cost account จะเพิ่มขึ้นแบบเรขาคณิต แตถา level of detail ไมเพียงพอ โครงสรางอาจ ไมเพียงพอที่จะพบกับความตองการของลูกคา โชคดีที่ WBS ที่สรางมามี flexibility เชน การมีสวนรวมของ หนวยงานตางๆ

ในองคกรอาจมีการขยายสัดสวนของโครงสรางเพื่อสนองความตองการเปนพิเศษ

เชน

แผนก

วิศวกรรม อาจแตกงานของเขาออกเปน package ยอยๆ อีก เชน ไฟฟา โยธา เครื่องกล หรือแผนกการตลาดอาจ แตก new product promotion เปน TV , radio , periodical , newspaper

4

Types of costs 1.

Direct costs a.

labor

b.

material

c.

equipment

d.

other

2.

project overhead costs

3.

General and administrative (G&A) overhead costs

Direct costs – ถูก charge ไปยัง specific work package ชัดเจน แสดง real cash outflows และตองจายเมื่อ project มีความคืบหนา , lower-level project rollups มักมีแต direct cost เทานั้น

Direct overhead costs – จะอยูใกลๆ กับจุดที่ resource ถูกใชใน project , direct OH costs สามารถยึดกับ project deliverables หรือ work package ได เชน รวมเอาเงินเดือนของ project manager และการเชาที่วางสําหรับ project team แมวา OH ยังไมตองจายทันที แตมันมีจริงและครอบคลุมในระยะยาว โดยอัตราของมันเปนสัดสวนกับ resource ที่ ใชเชน direct labor , material , equipment

General and administrative (G&A) overhead costs – ไมได link โดยตรงกับ specific project แตเกิดในชวง ที่ทํา project เชน ตนทุนขององคกรที่เกี่ยวกับ product และ project เชน advertising , accounting โดยจัดสรรเปน % ของ total of specific direct cost เชน labor , material , equipment ดังรูป 5.6

Estimating guidelines for times , costs and resources 1.

Responsibility : ที่ work package level การประมาณการควรทําโดยคนที่มีหนาที่รับผิดชอบเกี่ยวกับงานนั้น เพราะมีประสบการณ

2.

Use several people to estimate : คลาย Delphi

3.

Normal conditions : การประมาณการตองตั้งบนสมมติฐานวาอยูในสภาวะปกติ วิธีการมีประสิทธิภาพ ระดับของ resource ปกติ

4.

Time units : ใชหนวยของเวลาที่สม่ําเสมอ เชน ชั่วโมงก็ใชชั่วโมงทั้งหมด

5.

Independence : งานตองเปนงานที่ไมขึ้นกับหนวยงานอื่น

6.

Contingencies : ไมยอมใหใช contingency ตองใช condition ปกติ

7.

Adding risk assessment to the estimate helps to avoid surprises to stakeholders

Refining estimates and contingency funds

Interaction costs are hidden in estimates งานสวนใหญไมได complete ในขั้นตอน อาจตองขึ้นอยูกับงานกอน หนาดวย เชนการทํา prototype ก็ตองมีการ interact กับงาน design การประสานงานกัน - ใชเวลา

Normal conditions do not apply อาจมีปญหา resource shortage คน เครื่องจักร material การใช outsource

Things go wrong on projects เชน accident

Changes in project scope and plans องคกรแกไขโดย 1.

Adjusting estimates ทํางานใหดีที่สุด ทบทวนการประมาณบนพื้นฐานขอมูลที่เกี่ยวของกับ baseline schedule ที่ตั้งขึ้น และ budget

2.

Contingency funds and time buffers สราง contingency fund และ time buffer เพื่อรองรับสิ่งที่ไมแนนอน

3.

Changing baseline schedule and budget มีระบบการจัดการความเปลี่ยนแปลงเพื่อทบทวนการประมาณบนพื้น ฐานขอมูลที่เกี่ยวของกับ baseline schedule ที่ตั้งขึ้น และ budget 5

Creating a database for estimating •

เพื่อการพัฒนาการประมาณการ และการเก็บขอมูลของ project กอนหนาทั้งที่เปน estimate และ จัดหาขอมูลความรู เพื่อพัฒนาเวลาที่ใชในการทํา project และการประมาณการตนทุน จึงตองทําการสราง database เพื่อใหผูใชงาน สามารถปรับเปลี่ยนในสิ่งที่เกี่ยวของ เชน material , labor , equipment และสามารถให feedback กับผูประมาณ การ เปรียบเทียบ benchmark ดานเวลา cost กับ project อื่นๆ การเปรียบเทียบ estimate กับ actual และโอกาสที่ จะเกิดความเสี่ยง

•

คุณภาพของ database estimate ขึ้นอยูกับประสบการของผูทําการประมาณการดวย

•

โครงสรางของ database เปนดังนี้

6

การคํานวณความนาจะเปนที่โครงการจะเสร็จ ตารางแสดงเวลาและสําดับความสัมพันธกอนหลังของงานในโครงการ te

V

-

20

4

20

-

20

0

10

16

-

10

4

2

14

32

a

15

25

e

8

8

20

b,c

10

4

f

8

14

20

b,c

14

4

g

4

4

4

b,c

4

0

h

2

12

16

C

11

5.4

i

6

16

38

g,h

18

28.4

J

2

8

14

d,e

8

4

งาน

เวลาที่มอง

เวลาที่นาจะ

เวลาที่มอง

งานที่อยูกอน

ในแงดี

เปนมากทีสุด

ในแงราย

หนาโดยตรง

a

10

22

22

b

20

20

c

4

d

σ

การคํานวณเวลาของงาน การคํานวณเวลาที่คาดหมายไวของงานและเวลาที่คาดหมายไวสําหรับผังขายงานทั้งหมด เวลาที่คาดหมายไว (expected time : te) = (a + 4m + b) 6 เมื่อ

a

= คาคาดคะเนเวลาที่มองในแงดี (optimistic time estimate)

m

= คาคาดคะเนที่นาจะเกิดขึ้นมากที่สุด (most likely time estimate)

b

= คาคาดคะเนที่มองในแงราย (pessimistic time estimate) คาความแปรปรวน (Variance : V)

=

(b – a)

2

6 คาความเบี่ยงเบนมาตรฐาน (standard deviation : σ ) คือรากที่สองของ V จากตาราง 7.1 เมื่อวาด network ไดดังนี้ d

d a b c

h

e

f

j

e c

i h

f

g

i g

a-d-j b-e-j b-f b-g-i c-h-i

20+15+8 20+10+8 20+14 20+4+18 10+11+18

43 38 34 42 39

วิถีวิกฤต คือ 43

1

•

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

•

ชุดของความแปรปรวนซึ่งเราสนใจจะเปนความแปรปรวนของงานบนวิถีวิกฤต ในที่นี้วิถีวิกฤตคือ a-d-j ซึ่งมีคาความ แปรปรวนรวมของงานบนวิถีวิกฤตเทากับ 4+25+4=33

•

ถาเรามีขอสมมติฐานวาโครงการนี้มีสัญญาวาจะเสร็จภายใน

50

วัน

เราจะหาวาโครงการนี้มีโอกาสที่จะทําเสร็จ

ภายในเสนตายที่กําหนดมากนอยเพียงใด โดยกําหนดจากคา Z ที่หาไดจาก Z = (D – S) (V) 1/2 โดยที่

D = เวลาที่ตองการใหโครงการเสร็จ S = เวลาที่จะเสร็จโครงการตามกําหนดการหรือเวลาวิกฤต V = คาความแปรปรวนของวิถีวิกฤต Z = จํานวนคาความเบี่ยงเบนมาตรฐานของการกระจาย ในกรณีนี้เราหา Z ไดเทากับ 1.22

(Z = (50 – 43) / (33)1/2 )

เปดตาราง Z ที่ 1.22 ไดคาความนาจะเปนที่แสดงในตารางเทากับ 0.8888 ความนาจะเปนที่โครงการจะเสร็จในวันที่ 50 เทากับ 88.88% พื้นที่ = ความนาจะเปน = 0.8888

43 •

50

ถาเราตองการหาวาความนาจะเปนที่จะเสร็จโครงการภายในเวลาเปน 0.95 เวลาที่กําหนดเปนเสนตายซึ่งสอดคลอง กับความนาจะเปนนี้จะเปนเมื่อใด (หาคา D) Æ ดูตาราง Z ตรงที่มีคาความนาจะเปนเทากับ 0.95 วาตรงกับคา Z เทากับเทาไร จากการดูพบวาคา Z มีคาประมาณ 1.645 D = Z (V)

1/2

+ S

D = 1.645(33)1/2 + 43 = 52.45 ดังนั้น มีโอกาส 95% ทีโครงการจะเสร็จภายในวันที่ 52 •

จะสังเกตไดวา เมื่อ D เขาใกล S (เวลาที่ตองการใหโครงการเสร็จ ~ เวลาที่จะเสร็จโครงการตามกําหนดการหรือ เวลาวิกฤต) คา Z จะมีคานอยลงเขาใกลศูนย โอกาสที่เสร็จโครงการจะเปน 50-50

•

ในการกําหนดโครงการ ผูจัดการจะตองกําหนดใหมีความยืดหยุนอยูบาง โดยเผื่อความไมแนนอนไวดวย

•

เมือลองพิจารณาวิธีไมวิกฤตบาง คือ b-g-i มีคาความแปรปรวนเทากับ 0+0+28.4 = 28.4 นอยกวาของวิถีวิกฤต เล็กนอย (33) เมื่อหาคา Z พบวาจะไดคามากกวาบนวิถีวิกฤต และความนาจะเปนที่วิถีนี้จะลาชาแลวทําใหโครงการ ลาชาออกไปจะมีคานอยกวาวิถีวิกฤต

•

วิธีไมวิกฤต คือ c-h-i มีเวลาเทากับ 10+11+18= 39 วัน มีคาความแปรปรวนเทากับ 37.8 จะพบวามีโอกาส 96% ที่ วิถีวิกฤตที่วิถีที่ไมวิกฤตนี้จะทําใหโครงการเสร็จภายในเวลา

(เราพยายามที่จะหาคาความนาจะเปนซึ่งวิถีงานที่มีคา

2

ความแปรปรวนสูงกวา แตมีเวลาการทํางานตามวิถีนั้นสั้นกวาวิถีวิกฤต จะทําใหโครงการของเราลาชาออกไป โดยคา เวลาของวิถีวิกฤตในกรณีนี้ใชเวลา 43 วัน) •

ถาเวลาที่ตองการสําหรับผังขายงานเทากับเวลาวิกฤตพอดี คือ 43 วัน เราจะพบวาวิถีวิกฤตมีโอกาส 50-50 ที่จะทํา ใหเกิดความลาชา โอกาสที่วิถีที่ไมวิกฤต c-h-i จะทําใหโครงการลาชาเปนเทาไร คา D กรณีนี้เปน 43 วัน Z = (43 – 39) / 6.15 = 0.65 คา Z = 0.65 จะใหคาความนาจะเปนที่จะเสร็จโครงการภายในเวลาเทากับ 0.74 หรือความนาจะเปนที่จะทําใหลาชา เทากับ 1-0.74 = 0.26

0.74

0.26

39

43

หลักและเทคนิคการเขียนโครงการ •

โครงการ หมายถึง กลุมกิจกรรมที่จัดใหมีขึ้นเปนครั้งคราว มีระยะเวลากําหนดที่แนนอน

กระบวนการกอนวางโครงการ (คลายการวางแผน) 1.

ปญหาความตองการ

2.

รวบรวมขอมูล

3.

วิเคราะหปญหา

4.

จัดลําดับความสําคัญของปญหา / คัดเลือกปญหา

5.

วิเคราะหสาเหตุ

6.

กําหนดวัตถุประสงคเปาหมาย

7.

กําหนดกิจกรรม / ทรัพยากร

8.

วางโครงการ

ลักษณะของโครงการที่ดี 1.

เปนโครงการที่สามารถแกปญหาได

2.

มีรายละเอียดเนื้อหาสาระครบถวน ชัดเจน และจําเพาะเจาะจงโยสามารถตอบคําถามตอไปนี้ได คือ ¾

โครงการอะไร (ชื่อโครงการ)

¾

ทําไมจึงตองริเริ่มโครงการ (หลักการและเหตุผล)

¾

ทําเพื่ออะไร (วัตถุประสงค)

¾

ปริมาณที่จะทําเทาไร (เปาหมาย)

¾

ทําอยางไร (วิธีดําเนินการ)

¾

ทําเมื่อไร นานเทาใด (ระยะเวลาดําเนินการ)

¾

ใชทรัพยากรเทาไรและไดมาจากไหน (งบประมาณ แหลงที่มา)

¾

ใครทํา (ผูรับผิดชอบโครงการ)

¾

ตองประสานงานกับใคร (หนวยงานที่ใหการสนับสนุน)

3

¾

บรรลุวัตถุประสงคหรือไม (การประเมินผล)

¾

เมื่อเสร็จสิ้นโครงการแลวจะไดอะไร (ผลประโยชนที่คาดวาจะไดรับ)

การวิเคราะหความเปนไปไดของโครงการ (feasibility study) กอนทําโครงการ 1.

การเงิน : IRR , NPV , PB , B/C

2.

การตลาด & เศรษฐศาสตร : ลูกคาพอใจ , ผลกระทบตอสิ่งแวดลอมทั้ง macro , micro

3.

เทคนิค : ทําไดหรือไม

4.

บริหาร : คน ผูรวมหุน

profit & efficiency

ลักษณะของโครงการ โครงการ – กิจการใดๆ ที่ประกอบดวยคุณสมบัติตอไปนี้ 1.

มีวัตถุประสงคที่ชัดเจน อาจถูกกําหนดโดยลูกคา

2.

มีกําหนดเวลาเริ่มและสิ้นสุด

3.

การปฏิบัติโครงการมีเปาหมายที่ชัดเจนในดาน ¾

งบประมาณ มักใหความสําคัญเปนอันดับแรกๆ

¾

กําหนดเวลาของงานตางๆ ในโครงการ

¾

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

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

การที่ทีมบริหารโครงการใหเวลา

และความพยายามกับงานวางแผนโครงการลวงหนากอนดําเนินการใดๆ

ยอมเกิด

ประโยชนอยางคุมคาในดานตางๆ ไดแก การไดรูวางานอะไรบางที่ตองทําในโครงการ โดยทีมบริหารอาจใชเทคนิค โครงสรางรายการงานชวยในการวิเคราะห (การแตกเปน Work breakdown system)

4

Chapter 6 Developing a project plan Developing the project network •

Project network คือเครื่องมือสําหรับการวางแผน , scheduling และติดตามความคืบหนาของ project โดย การพัฒนาจากขอมูลที่ไดจาก WBS และ graphic flow chart ของ project job plan เปนกรอบงานสําหรับ project manager ในการตัดสินใจเกี่ยวกับ time , cost , performance ของ project

•

Network จะอธิบายกิจกรรมของ project ลําดับของกิจกรรม ความเกี่ยวของของแตละกิจกรรม เวลาของแตละ กิจกรรมตั้งแตเริ่มตนจนถึงสิ้นสุด และกิจกรรมใดที่ใชเวลาที่มากที่สุดที่เรียกวา critical path (วิถีวิกฤต)

From work package to network •

Work package จาก WBS นํามาสรางเปนกิจกรรม ในแตละกิจกรรมอาจมีหลาย WP ก็ได รูป 6.1 WBS / Work package to Network

•

จากรูป lowest level deliverable คือ circuit board มี cost account (design , production , test , software) แสดงถึง project work , หนวยงานที่รับผิดชอบ , time-phase budget ของแตละ WP ในแตละ cost account อาจมี WP = 1 หรือมากกวา 1 WP การทํา network ตองจัดลําดับของงานทั้งหมดของ WP จาก รูปยังบอกดวยวา activity A มี WP D-1-1 , D-1-2 สวนรูปดานลางบอกเวลาที่ใชสําหรับ activity นั้นๆ

Constructing a project network

Terminology •

Activity : สวนประกอบของ project ซึ่งตองใชเวลา (ทั้งทํางานและรอ) อาจตองการหรือไมตองการ resource มักมี 1 WP หรือมากกวา 1 WP

•

Merge activity : activity ที่มีมากกวา 1 activity เกิดกอนหนามัน

•

Parallel activity : activities ที่สามารถเกิดไดในเวลาเดียวกัน (ถาตองการ)

•

Path : ลําดับที่ตอเนื่องกัน เปน activity ที่ขึ้นแกกัน

1

•

Critical path : เสนทางที่ยาวที่สุด ถา activity นี้ delay มีผลทําให project delay ดวย

•

Event : จุดเวลาที่กิจกรรมเริ่มตนหรือสมบูรณ (ไมใชระยะเวลา)

•

Burst activity : กิจกรรมที่มีมากกวา 1 กิจกรรมมาตามหลัง

Two approaches 1.

Activity-on-node (AON) – ใช node เปนตัวแสดงกิจกรรม

2.

Activity-on-arrow (AOA) – ใช arrow เปนตัวแสดงกิจกรรม

Basic rules to follow in developing project networks 1.

network เริ่มจากซายไปขวา

2.

กิจกรรมจะยังเริ่มไมไดจนกวากิจกรรมที่อยูติดกันกอนหนานั้นเสร็จสิ้น

3.

ลูกศรใน network หัวลูกศรเปนตัวชี้วามากอน และไหลออกที่ปลาย ลูกศรสามารถตัดกันได

4.

แตละกิจกรรมมีตัวเลขหรือเอกลักษณแสดง

5.

ตัวเลขกิจกรรมตองมีคามากกวากิจกรรมที่มีมากอน

6.

ไมใหมีการวน loop

7.

ไมใหมีการระบุเงื่อนไข (หามมีคําตอไปนี้ : ถาสําเร็จ – ทํา ... , ถาไมสําเร็จ – ไมตองทําอะไร)

8.

ถามีจุดเริ่มตนหลายจุด common start node สามารถใชระบุการเริ่มตน project บน network ไดอยางชัดเจน ในทํานองเดียวกัน single project end node สามารถแสดงถึงการจบไดอยางชัดเจน

Activity-on-node (AON) fundamentals : precedence diagram method รูป 6.2 Activity-on-node Network Fundamentals

2

ความสัมพันธของแตละกิจกรรม 1.

กิจกรรมใดที่ตองเสร็จกอนกิจกรรมนี้ กิจกรรมนั้นๆ เรียกวา predecessor activity

2.

กิจกรรมใดที่ตองทําตามหลังกิจกรรมนี้ กิจกรรมนั้นๆ เรียกวา successor activity

3.

กิจกรรมใดที่สามารถเกิดในขณะที่กิจกรรมนี้เกิด กิจกรรมนั้นๆ เรียกวา concurrent or parallel activity

•

รูป 6.2A – A ตองเสร็จกอน B จึงจะเริ่มได และ B ตองเสร็จกอน C จึงจะเริ่มได

•

รูป 6.2B – Y , Z ยังเริ่มตนไมไดจนกวา X จะเสร็จ , Y ,Z อาจเกิดพรอมหรือไมพรอมกันก็ได โดย Y,Z เปน parallel จํานวนลูกศรเปนตัวบอกวามีกิจกรรมกี่อยางที่ตามหลังมัน

•

รูป 6.2C – J, K , L สามารถเกิดพรอมกันได (เปน parallel activity) ถาตองการ และ M ยังไมเกิดเมื่อ J , K, L ยังไมเสร็จ M เปน merge activity หรือ milestone

•

รูป 6.2D – X , Y เปน parallel ที่สามารถเกิดพรอมกันได โดย Z,AA เปน parallel และจะยังเริ่มไมไดจนกวา X จะเสร็จ ตาราง 6.1 KOLL BUSINESS CENTER County Engineers Design Department Activity

Description

Preceding activity

A

Application approval

None

B

Construction plans

A

C

Traffic study

A

D

Service availability check

A

E

Staff report

B,C

F

Commission approval

B,C,D

G

Wait for construction

F

H

Occupancy

E,G

รูป 6.4 เปน complete network - Koll Business Center—Complete Network ใชขอมูลจากตาราง 6.1

3

Start and finish network computations Network computation process Forward pass – Earliest times 1.

How soon can the activity start ? (early start – ES) กิจกรรมเริ่มไดอยางเร็วเมื่อไร

2.

How soon can the activity finish ? (early finish – EF) กิจกรรมเสร็จไดอยางเร็วเมื่อไร

3.

How soon can the project be finished ? (expected time – TE) project จะเสร็จอยางเร็วเมื่อไร

Backward pass – Latest times

1.

How late can the activity start ? (late start – LS) กิจกรรมเริ่มไดอยางชาเมื่อไร

2.

How late can the activity finish ? (late finish – LF) กิจกรรมเสร็จอยางชาเมื่อไร

3.

activity ใดแสดง critical path (CP) (path ที่ใชเวลานานที่สุด) , activity ใด delay , เมื่อใดจะ delay

4.

activity จะ delay นานเทาใด (slack or float – SL)

Forward pass-earliest times ตาราง 6.2 Network Information KOLL BUSINESS CENTER County Engineers Design Department Activity

Description

Preceding activity

Activity time

None

5

A

Application approval

B

Construction plans

A

15

C

Traffic study

A

10

D

Service availability check

A

5

E

Staff report

B,C

15

F

Commission approval

B,C,D

10

G

Wait for construction

F

170

H

Occupancy

E,G

35

รูป 6.5 เปน Koll Business Center—Complete Network

รูป 6.6 Activity-on-Node Network Forward Pass 4

•

จากรูปอธิบายไดวา early start time ของกิจกรรมแรก (activity A) เปน 0 ดูที่มุมซายดานบนของ activity A node ในรูป 6.6 ตาราง 6.2 แสดง activity times เปนวัน ของ Koll Business

•

Activity A ใชเวลา 5 (ES + Dur = EF , 0+5=5) และพบวา A เกิดกอน B, C , D ซึ่งหลังจากที่ A complete แลว (ซึ่งใชเวลา 5 วัน) ดังนั้น ES ของ B , C, D = 5 EF = 20,15,10 ตามลําดับ (EF = ES+Dur) , ES ของ E ควรเปนอะไรระหวาง 20 กับ 15 ตอบ 20 เพราะวา E จะเกิดก็ตอเมื่อ B , C สมบูรณ ซึ่งจะสมบูรณเมื่อเวลา ผานไป 20

•

ES ของ F ก็ตองเปน 20 (เพราะวาตองรอ B,C,D เสร็จกอน ซึ่งใชเวลา 20,15,10) ทําเชนนี้ไปเรื่อยๆ จนสิ้นสุด ที่ H จนได expected time (TE)

•

สรุปวา forward pass ตองทําดังนี้ 1.

ES + Dur = EF

2.

เอา EF ไปใสที่ ES ของ activity ถัดไป

3.

กรณี merge activity ตองเลือก activity ที่ EF ยาวที่สุดของ predecessor activities

Backward pass-latest times •

เริ่มตนจาก activity สุดทาย หา LS และ LF ของแตละ activity กอนคํานวณ backward pass ตองเลือก LF ของ activities สุดทายของ project กอน มักกําหนดใหเทากับ EF ของ activity สุดทายของ project ถามี หลายๆ activity เลือก activity ที่มี EF มากที่สุด โดยรูป 6.7 EF = LF ของ activity H

•

•

สรุปวา backward pass ตองทําดังนี้ 1.

LF - Dur = LS

2.

เอา LS ไปใสที่ LF ของ activity ถัดไป

3.

กรณี burst activity ตองเลือก activity ที่ LS ต่ําที่สุดไปเปน LF ของ activity กอนหนานั้น

จากรูป 6.7 เริ่มที่ H : LF – Dur = LS (235-35=200) เอา 200 ไปเปน LF ของ E , G หา LS ของ E,G เอา LS ไปเปน LF ของ activity กอนหนา โดย F ไปที่ B 20 , C 20 , D 20 E ไปที่ B 185 ที่ B ตองเลือกระหวาง 20 กับ 185 เลือก D 20 แลวทําตอไปเรื่อยๆ

5

รูป 6.7 Activity-on-Node Network Backward Pass

Determining slack (or float) •

เมื่อทํา forward / backward pass แลว มีโอกาสที่จะหาไดวา activity ใดสามารถ delay ได โดยการคํานวณ slack หรือ float โดย

•

SL = LS – ES หรือ SL = LF – EF

•

จากรูป 6.8 ได LS ของ D = 10 , G = 0 , C = 5

•

Total slack บอกถึงจํานวนเวลาที่กิจกรรมของ project สามารถที่จะ delay ได , ES ของ activities ทั้งหมดที่ ตามมาใน chain จะ delay และ slack จะลดลง

•

การใช total slack จะตองรวมมือกับผูที่เขารวมทั้งหมดของ activity ใน chain

•

หลังจากที่หา slack ของแตละ activity ได ก็จะหา critical path ได ซึ่งจะมี LF=EF หรือ slack =0 (SL = LF-EF = 0 , SL = LS-ES =0)

•

Critical path คือ network path ที่มี slack นอยที่สุด

•

รูป 6.8 critical path จะเปนเสนประ คือ A B F G H ปกติ critical activity มี ~10% ของกิจกรรมของ project รูป 6.8 Activity-on-Node Network Backward Pass

6

Free slack (float) •

กิจกรรมที่ไมมี slack จะมีเอกลักษณเพราะ activities สามารถ delay โดยไมตอง delay ES ของ activities ที่ ตามมา

•

Free slack หมายถึงความแตกตางระหวาง EF ของ activity กับ ES ของ activity ที่ตามมา

•

คา free slack ไมเปนลบ มีเพียง activities ที่เกิดตอนปลายของ chain ของ activity (เมื่อมี merge activities)

•

ถา single chain (path) ของกิจกรรมมี SL 14 , last activity จะมี free slack สวน activity อื่นไมมี

•

บางครั้ง chain ไมยาวมาก อาจเปนเพียง 1 activity เชนใน Koll Business Center Network (รูป 6.8) activity E เปนสวนหนึ่งของ chain มี SL 165 วัน (200-35=165) C,D มี free slack = 5,10

•

ขอดีของ free slack คือการเปลี่ยนแปลงดานเวลาของการเริ่มและสิ้นสุด สําหรับ free slack activity ตองการ การรวมมือจากคนอื่นใน project และให project manager มีความยืดหยุนมากกวา total slack

•

เนื่องจาก activity สุดทายใน chain delay activity ตาม slack demand จะไมมีอิทธิพลใดๆ ตอ activity ตัวอยาง สมมุติใน chain มี 10 activities ที่เหลือ delay ใน 9 activity ที่เหลือใน chain ตองแจงให manager วาจะมีการ late เพื่อที่จะไดปรับตาราง เพราะไมมี slack

Using the forward and backward pass information •

Slack 10 วันของ activity D มีความหมายตอ project manager วา activity D สามารถ delay ได 10 วัน หรือ project ยอมใหมีการยืดหยุนของตาราง อาจเกี่ยวของกับ resource ที่หายาก บุคลากร เครื่องมือที่มีการใช มากกวา 1 activity หรือใชใน project อื่นๆ ดวย

•

เวลาของกิจกรรม ES , LS , EF , LS มีคามากสําหรับการวางแผน จัดตาราง ควบคุม phase ตางๆ ของ project โดย ES , LF บอกชวงเวลาที่ project จะสมบูรณ เชน activity E จะสมบูรณภายใน 20 -200 วัน หรือ activity F จะ start ในวันที่ 20 หรือ project จะ delay

•

เมื่อรู critical path ก็เปนไปไดที่จะจัดการใหเขมงวดกับ resource ของ activity ที่อยูใน critical path เพื่อ ไมใหเกิดความผิดพลาดซึ่งจะทําใหเกิด delay หรือเพื่อกระตุนให project เรงความเร็ว อาจโดยการเลือก activity เหลานั้น หรือรวม activity เหลานั้น ซึ่งอาจเลือก activity ที่ cost นอยที่สุด เพื่อทําให project สั้นลง

•

ถา critical path delay ทําใหเวลานานขึ้น อาจแกโดยอาจทําให activity บน critical path สั้นลงเพื่อทําให slack เปนลบ อาจทําโดยการระบุ activity บน critical path ที่ cost นอยที่สุดแลวทําใหเวลาสั้นลง ถามี เสนทางอื่นที่มี slack นอยมาก อาจจําเปนตองทําให activity บน path นั้นสั้นลงดวยก็ได

•

Critical path 1.

เสนที่มีวิถียาวที่สด ุ คือ A-B-F-G-H ยาว 235 วัน

2.

กิจกรรมที่อยูบนวิถีวิกฤตินั้นตองมี slack เทากับ 0 เลื่อนไมได ตองทําการปฏิบัติในวันนั้น

3.

critical path อาจมีมากกวา 1 ได

Level of detail for activities •

การกําหนด level of detail ควรลดใหสั้นลงทั้ง project ขนาดใหญและเล็ก เพราะถามีมากก็เปลือง OH cost

7

Extended network techniques to come closer to reality

Laddering •

เมื่อกิจกรรมหนึ่งอาจใชเวลานานๆ และอาจมีผลทําใหกิจกรรมอื่นๆ ที่ตามมาเกิดการ delay ได นิยมทําแบบ laddering เชนการวางทอ ที่มีกิจกรรม 3 อยาง คือ ขุด วางทอ กลบ ดังรูป 6.12 6.12 Example of Laddering Using Finish-to-Start Relationship

Use of lags •

เพื่อใหการสราง network มีความยืดหยุนมากขึ้น , lag คือ เวลาที่นอยที่สุดของ activity ที่ขึ้นแกกัน ที่ จําเปนตอง delay ตอนเริ่มตนหรือตอนสิ้นสุด การใช lag เพื่อ 2 เหตุผล คือ 1.

เมื่อ activity ที่มีระยะเวลานานๆ มักทําให successor activity delay ตอนเริ่มตนหรือสิ้นสุด จึงมักนิยม break activity เปน activity ขนาดเล็กๆ เพื่อหลีกเลี่ยงการ delay ในระยะยาวของ successor activity และลด network detail

2.

ใชเพื่อบังคับการเริ่มตนและสิ้นสุดของ activity

แบบที่นิยมคือ start-to-start หรือ finish-to-finish หรือการผสมของ 2 แบบ

•

Finish-to-start relationship ¾

เปนรูปแบบโดยทั่วๆ ไป คือ activity ที่ 1 จบกอนแลวจึงเริ่ม activity ที่ 2 แตมีบางสถานการณที่ activity ที่ 2 จําเปนตอง delay แมวา activity ที่ 1 เสร็จแลว เชน การเอาแบบ concrete ออก ยังไม สามารถทําไดจนกวาการเท concrete จะผานไป 2 time units ดังรูปที่ 6.13 เปน lag relationship ของ AON

¾

Finish-to-start lags มักใชตอนสั่ง material เชน ใชเวลา 1วันในการ order แตใชเวลา 19 วันจึงจะได สินคา (duration 1 day , lag 19 days) วิธีนี้ทําใหเพื่อมั่นใจวา activity cost จะติดไปกับการ order เทานั้น ไมได charge 20 วัน) หรือการขนสง กฎหมาย ติดตอ mail ซึ่งเปน lag

¾

การนํา finish-to-finish ไปใชตองตรวจสอบอยางระมัดระวังถึง validity (การนําไปใชได)

¾

Project manager ที่ conservative หรือผูจัดการที่รับผิดชอบเรื่องความสมบูรณของ activities จะใช lags เปนเครื่องมือในการสราง slush ซึ่งเปน factor ในการลดความเสี่ยงจากการ late ของ program 6.13 Finish-to-Start Relationship

8

•

Start-to-start relationship (รูป 6.14) ¾

รูป 6.14A start-to-start relationship with zero lag , 6.14B start-to-start relationship with lag of five time units (การระบุวามี lag หรือไมมี lag เปนสิ่งที่จําเปน ถามี lag จะระบุบนลูกศร) จากรูปนี้บอก วา activity Q จะยังเริ่มไมได จนกวา P จะเริ่มไปแลว 5 unit

¾

นิยมใชในงานวางทอ ดังรูป 6.15

¾

สามารถลด network detail และ project delay โดยใช lag relationship

¾

อาจพบแรงกดดันที่ตองใหเปลี่ยน finish-to-start เปน start-to-start ได โดยการทํางานแบบขนานกัน ไป เชน finish-to-start คือ การออกแบบบานและสราง foundation , start-to-start เริ่มสราง foundation หลังจากที่ออกแบบไปแลว 5 วัน (lag) โดยมีขอสมมติฐานวา design ของ foundation เปนสวนแรกของกิจกรรมการออกแบบทั้งหมด

¾

พบใน project ที่ concurrent engineering ตองการเรงให project สมบูรณเร็วๆ โดยการแตก activity ออกเปน activity ยอยๆ แลวทําขนานกันไป

¾

ลด network detail 6.14 Start-to-Start Relationship

6.15 Use of Lags to Reduce

6.16 New Product Development Process

9

•

Finish-to-finish relationship ¾

รูป 6.17 การสิ้นสุดของ activity หนึ่งขึ้นอยูกับการเสร็จสิ้นของ activity หนึ่ง เชน testing จะเสร็จ สมบูรณเมื่อ

prototype

สมบูรณไปแลว

4

วัน

(ไมใช

finish-to-start

เพราะการ

testing

subcomponent สามารถเริ่มไดกอนที่ prototype จะสมบูรณ โดย 4 วันของ “system” testing เปน ความตองการหลังจากที่ prototype สําเร็จ) 6.17 Finish-to-Finish Relationship

•

Start-to-finish relationship ¾

สถานการณที่การ finish ของ activity ขึ้นอยูกับการ start ของอีก activity หนึ่ง เชน system documentation จะไมสามารถจบไดจนกวา 3 วันหลังจากเริ่มการตรวจสอบ (รูป 6.18) เพราะขอมูลที่ เกี่ยวของทั้งหมดกับ system documentation จะตองทําหลังจากเริ่มการทดสอบไปได 3 วัน 6.18 Start-to-Finish Relationship

•

Combination of lag relationship ¾

รูป 6.19 อาจมี lag มากกวา 1 ใน activity ตัวอยางเชน การ debug ไมสามารถเริ่มไดจนกวาการ coding เริ่มไปได 2 วัน , coding จําเปนตองเสร็จกอน 4 วัน การ debug จึงจะเริ่มได 6.19 Combination Relationships

10

An example using lag relationships – the forward and backward pass (รูป 6.20) 6.20 Network Using Lags

•

อธิบายไดวา order hardware (B) ตองทําหลังจากเริ่มทํา design the system (A) ไปแลว 3 วัน (start-tostart) และตองใชเวลา 4 วันหลังจาก order (B) เสร็จจึงจะไดรับ hardware เพื่อเริ่ม install (C) ซึ่งใชเวลา 2 วันแลวจึง install software system (activity D) , system testing (E) จะเริ่มไดเมื่อ D เริ่มไปได 2 วัน (startto-start) และจะเสร็จหลังจากที่ software install (D) เสร็จได 2 วัน , การเตรียม system documentation (F) จะเริ่มไดเมื่อการออกแบบสมบูรณ (A) ซึ่งจะเสร็จหลังจากที่การ test system (E) เสร็จได 2 วัน (finish-tofinish lag)

•

Critical finish and/or start : E และ F มี critical finish (slack = 0) แต activity start มี slack 4,12 วัน A มี slack to start เทากับ 0 แตมี slack to finish เทากับ 5 โดยเสนประในรูปที่ 6.20 คือ critical path

•

ถามี lag relationship แตละ activity จะตองถูกตรวจสอบเพื่อดูวาการ start หรือ finish เปนขอจํากัด ตัวอยางเชน ใน forward pass ของ EF ของ activity E (test system) (18) ถูกควบคุมโดยการเสร็จสิ้นของ activity D (install software) และ lag 2 (16+2 lag =18) และ backward pass LS ของ activity A (design system) ถูกควบคุมโดย activity B (order hardware) และ lag relationship ไปยัง activity A (3-3=0)

Hammock activities •

Hammock activity มักใชเพื่อระบุการใช fixed resources หรือ cost ตลอด segment ของ project ตัวอยางเชน inspection , services , consultants , construction management service

•

ตัวอยางเชน การนําเครื่องถายเอกสารสีไปใชในงาน trade show publication project , hammock activity สามารถที่จะใชระบุความตองการใช resource นี้และ apply cost ใหกับ segment ของ project นี้

•

Hammock จะถูก link จากจุด start ของ activity แรก กับ end ของ last activity ที่จะใช resource นี้ hammock duration หาไดจากความแตกตางของ EF ของ last activity กับ ES ของ first activity โดยคํานวณ หลังจาก forward pass ดังนั้นจึงไมมีผลกระทบตอเวลาของ activity อื่น

•

จากรูป 6.21 duration = EF (F) - ES (B) = 13-5 = 8

•

Hammock มีประโยชนในการมอบหมายและควบคุม indirect project cost

•

การใช Hammock activity มักทําการ group activities (การรวมกิจกรรมที่ใกลเคียงกัน หรือใชทรัพยากร คลายกัน) ก็จะชวยทําใหได right level of detail สําหรับ specific sections of a project

11

6.21 Hammock Activity Example

ขอสอบ อ.สําราญ (3 ขอ) 1. โจทย (ภาษาอังกฤษ) เขียน network หา prob.

ทฤษฎี

50%

2. risk management ขั้นตอน 4 ขอ ใหอธิบาย 1 ขอ

ทฤษฎี + apply

25%

3. ภาพรวม (การเขียนโครงการ , การสรุปโครงการ , เรื่องทั่วๆ ไปที่ควรรู)

apply

25%

12

Chapter 7 Managing risk •

Risk คือ โอกาส (chance) ที่เหตุการณที่ไมพึงประสงคจะเกิดขึ้น และอาจมีผลกระทบกับผลลัพธของเรา เชน เหตุการณที่อาจทําให project ตอง delay ออกไปหรืออาจตองหยุด project บางเหตุการณอาจระบุไดกอนที่จะเริ่ม project แตก็อาจมีบางเหตุการณที่เราไมเคยพบมากอน เชนกรณี 11/9

•

การจัดการกับความเสี่ยง

คือ

ความพยายามทีจ ่ ะระลึกและจัดการกับปญหาที่ไมเคยพบมากอนที่อาจจะเกิดขณะที่

กําลังปฏิบัติ project •

•

การจัดการกับความเสี่ยง จะ 1.

ระบุเหตุการณที่อาจเกิดขึ้น

2.

ทําใหเกิดผลกระทบนอยที่สุด

3.

จัดทํา contingency plan

4.

จัดหา contingency fund ที่ครอบคลุม risk event

Risk management process

โอกาสของเหตุการณความเสี่ยงที่เกิด (เชนการประมาณการเวลา งบประมาณ design technology ผิดไป) จะมีผล อยางมากตอ concept , planning และ start-up phased ของ project , ในชวง stage ตนๆ ของ project cost จะ ไดรับผลกระทบจาก risk event นอย และมีโอกาสที่จะลดผลกระทบของความเสี่ยงไดมากกวา stage หลังๆ ซึ่งเมื่อ project ดําเนินไปครึ่งหนึ่ง cost risk จะเพิ่มขึ้นอยางรวดเร็ว ดังนั้นการระบุ project risk events และตัดสินใจกอนที่ project จะเริ่มจะเปนการดีกวาการจัดการกับความเสี่ยง •

Risk management เปน proactive approach เปนการออกแบบกระบวนการปองกันเพื่อใหมั่นใจวาเหตุการณที่ไม ตองการจะลดลงและมีผลกระทบของเหตุการณนั้นนอยที่สุด

และเปนการเตรียมพรอมให project manager ได

จัดการกับ risk เพื่อใหเกิดขอไดเปรียบดานเวลา cost และ technical สามารถที่จะควบคุมอนาคต และพัฒนาโอกาส ของการบรรลุวัตถุประสงคของ

project

ไดตรงเวลา

ภายในงบประมาณและบรรลุ

technical

(functional)

performance •

แหลงของ project risk (หรือ threat : external) เชน inflation การยอมรับของตลาด อัตราแลกเปลี่ยน ขอกําหนด ของรัฐบาล มักมีการพิจารณากอนตัดสินใจวาจะทํา project ตอหรือไม ดังนั้นจึงมักถูกเอาออกกอนจะอภิปรายถึง project risk แตอยางไรก็ตามก็ยังสําคัญและตองคํานึงถึง

•

สวนประกอบของ risk management process แสดงดังรูป

1

การระบุความเสี่ยง

การประเมินความเสี่ยง ดาน • ความรุนแรงของผลกระทบ • โอกาสที่จะเกิด • สามารถควบคุมไดหรือไม

การพัฒนาการรับผิดชอบตอความเสี่ยง • การหากลยุทธที่จะลดความเสียหายที่จะเกิดขึ้น • การจัดทําแผนฉุกเฉิน

การควบคุมการรับผิดชอบตอความเสี่ยง • การนํากลยุทธที่จะลดความเสี่ยงไปปฏิบัติ • ติดตามและปรับแผนสําหรับ new risk โดยเฉพาะเรื่อง ขาวซึ่งเปนเรื่องสําคัญ • การบริหารการเปลี่ยนแปลง

Step 1 : Risk identification •

การระบุรายการที่อาจเปนไปไดวาจะกระทบตอ project , project manager และผูที่เกี่ยวของใน team ชวยกันระดม สมองคิดดวยกันในชวงเริ่มตน อาจระบุ risk ไวมากๆ ตอมาชวง assessment phase อาจมีการกลั่นกรองเอา risk ที่ ไมสมเหตุสมผลออก

•

สิ่งที่ผิดพลาดใน step นี้คือการ focus ที่ผลที่ตามมา ไม focus ที่เหตุการณที่ทําใหเกิดผล

•

การระบุ specific risk คือการทํา WBS ซึ่ง WBS จะลดโอกาสที่จะเกิด risk event ถาเปน project ใหญอาจมีการ แตกเปนหลายๆ specific deliverable ในบาง project อาจตองมีการใช technical breakdown structure เพื่อให มั่นใจวา technical risk ไดถูกตรวจสอบแลว

•

Risk profile เปนเครื่องมือหนึ่งที่ใชชวย management team ในการระบุและวิเคราะห risk โดย risk profile จะเปน รายการคําถามที่ถามหนวยงานตางๆ ถึงสิ่งที่ไมแนนอนใน project ซึ่งถูกสรางและมีการเก็บรักษาไวโดยบุคคลใน project office โดยตองมีการ update , review ในระหวางทํา project ดวย

•

การระบุ risk ไมควรทําแต core team ควรหาขอมูลจาก customer , sponsor , subcontractor , vendor และผูที่ เกี่ยวของที่เราไปสัมภาษณมาดวย

•

สิ่งหนึ่งที่สําคัญในการระบุ risk คือ ทัศนคติ ที่วาจะตองหาปญหากอนที่มันจะเกิด

Step 2 : Risk assessment •

ใน step 1 เราระบุ risk ที่อาจเกิดขึ้นแตเราไมไดสนใจทุกอัน เราสนใจแตอันที่มีผลตอสวัสดิภาพของ project manager ตองหาวิธีกลั่นกรองเพื่อตัดรายการ risk บางอันออกหรือตัด risk ที่ซ้ําซากออก และจัดลําดับความสําคัญ ที่ตอ  งใหความสนใจ

•

Scenario analysis คือเทคนิคที่งายและธรรมดาที่สุดในการวิเคราะห risk โดย team member ประเมิน risk ในรูป ของ

2

•

1.

เหตุการณที่ไมพึงปรารถนา

2.

ผลลัพธของเหตุการณที่เกิดขึ้น

3.

ความสําคัญหรือความรุนแรงของผลกระทบของเหตุการณ

4.

โอกาสหรือความนาจะเปนที่เหตุการณนั้นจะเกิด

5.

เหตุการณนั้นจะเกิดกับ project เมื่อใด

6.

ความสัมพันธตอสวนอื่นๆ ของ project หรือสัมพันธตอ project อื่น

ตัวอยางเชน โอกาสที่ resource ที่เปนทักษะเฉพาะจะขาดแคลน มีผลทําให project delay ได ตารางการทํางานก็ จะคอนขางแนน ไมมีความยืดหยุน  cost เพิ่มขึ้น ถาการขาดแคลนทักษะเกิดที่ design stage ก็อาจจะมีผลตอ stage ถัดไป หรืออาจตองมีการปรับลําดับการทํางาน การที่มีขอมูลที่เพียงพอ จะทําใหชวยประเมิน risk event ไดอยางดี

•

รูปตอไปนี้เปนบางสวนของแบบฟอรมการประเมินความเสี่ยงจากโครงการการ upgrade Window Office 97 ไปเปน Window Office 2000XP

มีการประเมินโอกาสที่จะเกิด risk event (likelihood) , ความรุนแรง (impact)

และเมื่อใดที่เหตุการณจะเกิด

(when) และสามารถ detect เหตุการณไดทันเวลาหรือยากงายเพียงใด (detection difficulty) เพื่อทําใหปญหา ทุเลาลง โดยทีมจะใหคะแนน จากตัวอยางในตาราง ใหคา detection difficulty ของ system freezing สูง (5) เพราะวาระบบ crash โดยไมมีการเตือน ในขณะที่ user backlash ใหคะแนนปานกลาง (3) เพราะการตอบโตหรือ การตอตานของ user สามารถตรวจพบไดกอนที่จะเกิดความเสียหาย •

องคกรอาจมีการจัดหมวดหมูความรุนแรงของ risk ตางๆ จาก risk assessment matrix โดยพิจารณาที่ผลกระทบ และความเปนไปได โดย matrix จะแบงระดับความเสี่ยงตามสีเปน ¾

สีแดง (major) มีศูนยกลางอยูที่มุมขวาบน (high impact / high likelihood)

¾

สีเหลือง (moderate) อยูตรงกลางของ matrix

¾

สีเขียว (minor) มีศูนยกลางอยูที่มุมซายลาง (low impact / low likelihood)

3

•

การประเมินความเสี่ยงอาจมีทั้งแบบ subjective หรือ quantitative เชน expert opinion หรือ gut feeling estimates

แตอาจมีขอผิดพลาดจากการใชวิจารณญาณของผูประเมินได

แตวิธก ี ารเชิงปริมาณจะตองการขอมูลที่

มากกวาเดิม โดยอาจทําในรูป ratio analysis , probability analysis และ sensitivity analysis ซึ่งตองการการเก็บ ขอมูลที่เขมงวด และมักจะมีขอจํากัดที่ scope และระดับการยอมรับของ manager มีนอย , วิธี hybrid expert system เปนวิธีที่ใชกันมากโดยใชวิธีเชิงปริมาณผสมกับ rule of thumb จากประสบการณ อยางไรก็ตาม จะใชวิธีใด ขึ้นอยูกับ แหลงของความเสี่ยง ผลลัพธที่อาจจะเกิดขึ้น ผลกระทบของความเสี่ยง และทัศนคติของฝายจัดการที่มีตอ การประเมินความเสี่ยง ¾

Ratio / range analysis : ใชขอมูลจาก project กอนที่คลายๆ กัน เชน ถา project เดิมใชเวลา 10 นาที project ใหมก็อาจเอา 1.1 ไปคูณ โดยคิดวา project ใหมตองดีกวาเดิม จึงใชเวลามากกวาเดิม 10%

¾

Hybrid analysis approaches : ใชความรูและประสบการณของ manager และ rule of thumb คลายๆ ratio

¾

Failure mode and effects analysis (FMEA) Risk value = Impact x Probability x Detection แตละตัวมี scale 1-5

¾

Probability analysis : มีการใช decision tree โดยดูที่คา expected value หรือ net present value (NPV) และอาจใช PERT simulation เพื่อดูผลลัพธที่ไดจากสถานการณที่ดีที่สุดไปจนถึงสถานการณที่แย ที่สุด

¾

Scenario analysis : Semiqauntitative ใชเวลาเปนสําคัญ

Step 3 : Risk Response Development •

เมื่อสามารถระบุเหตุการณที่ทําใหเกิดความเสี่ยงและทําการประเมินแลว ตอมาเปนวิธีการตัดสินใจ การรับผิดชอบตอ risk ซึ่งแบงไดเปน 1.

Mitigating risk การทําให risk ทุเลาเบาบางลง ใชกลยุทธ 2 อยางคือ 1)

การลดโอกาสที่จะเกิดเหตุการณ เชน การทําการตรวจสอบกอนนําไปปฏิบัติเพื่อใหทราบปญหาที่ คาดวาจะเกิดไดลวงหนา

2)

การลดผลกระทบที่เปนผลรายตอ project เชน การใช cement จาก 2 plant เพื่อลดปญหาการสง วัตถุดิบไมทัน

2.

Transferring risk การยายความเสี่ยงไปยัง party อื่น ซึ่งตองมีการจาย premium เชน การโอนยายความ เสี่ยงไปยัง contractor ซึ่ง contractor ก็ทราบดีจึงมักรวมคาความเสี่ยงไวใน bid price ดวย กอนที่จะ ตัดสินใจโอนยายความเสี่ยง เจาของโครงการตองตัดสินใจวาจะให party ใดเปนผูรับโอนยายความเสี่ยงที่ สามารถควบคุมและดูดซับความเสี่ยงนั้นๆ ไดดี รูปแบบอื่นๆ ของการโอนยาย เชน การทําประกัน (แตอาจ ไมมีประโยชนถาการ define project risk event และ condition ไปยัง insurance ซึ่งไมคุนเคยกับ project ทําไดยากและมักมีราคาสูง) นอกจากนี้อาจทํา bonds , warranties และ guarantees ก็เปน เครื่องมือทางการเงินที่อาจใชในการโอนยายความเสี่ยงได

3.

Sharing risk การแบงปนความเสี่ยงไปยัง parties ตางๆ เชน

AirbusA300B

ที่แบงหนาที่การ

research และ development risk ไปยังกลุมยุโรป เชนอังกฤษ และฝรั่งเศส หรืออุตสาหกรรมบันเทิงที่ สรางกลุมหุนสวนของ Digital Video Disc (DVD) ที่สอดคลองกับ product ที่ทําอยู นอกจากนี้การแบงปน ความเสี่ยงอาจเปนการลด cost ดวย และการเปนหุนสวนระหวางเจาของกับ contractor อาจทําใหเกิดการ พัฒนาอยางตอเนื่องเปนการสนับสนุนให contractor หาและนํานวัตกรรมใหมมาใชใน project ดวย

4

4.

Retaining risk ความเสี่ยงบางอยางก็มีขนาดใหญเกินกวาจะโยกยายหรือลดได เชนการเกิดแผนดินไหว น้ําทวม แตเจาของจะ assume ความเสี่ยงแบบนี้นอย เพราะโอกาสที่จะเกิดขึ้นมีนอย แตอาจมีการสํารอง budget ไวบาง บางทีอาจมีการทํา contingency plan สําหรับความเสียงที่อาจจะเกิด หรือบางกรณีอาจไม สนใจเลยก็ได

•

Contingency plan ¾

เปนแผนทางเลือกใหมที่จะใชเมื่อเกิดเหตุการณที่ไมคาดคิดเกิดขึ้น โดยจะเสนอ preventive action ที่จะ ลดหรือบรรเทาผลกระทบในทางลบของ risk event ซึ่งจะตอบคําถาม what , where , when , how much ของ action

¾

การที่ไมมี contingency plan เมือ ่ เกิด risk event อาจทําให manager ตอง delay หรือเลื่อนการตัดสินใจ ของการนําแผนไปปฏิบัติ เมื่อเกิดการตื่นตระหนก หรือจัดการในภาวะวิกฤต ทําใหตองรีบตัดสินใจภายใต แรงกดดัน ซึ่งอาจเกิดอันตรายตอทรัพยสินได

¾

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

¾

ใน contingency plan ควรมีการทํา cost estimate และระบุแหลงที่มาของเงินทุน ทุกสวนที่เกี่ยวของตอง เห็นดวยกับแผนและมีอํานาจในการทํา commitment และตองมีการสื่อสารใหสมาชิกทุกคนในทีมไดรับรู เพื่อลดการตอตานและความประหลาดใจ

¾

Risk response matrices แสดงดังรูป เปนการสรุปวา project team วางแผนที่จะจัดการกับ risk ที่ระบุไว อยางไร โดยใน step แรก ระบุวาจะ reduce , share , transfer , accept สวนใน step ตอไปจะระบุถึง contingency plan ถา risk ยังคงเกิดอยู , Trigger คือ การกระตุนการนํา contingency plan ไปใช สวน สุดทายเปนการกําหนดผูรับผิดชอบในการติดตาม risk และรับผิดชอบในการเริ่มใช contingency plan

¾

Technical risk หมายถึงปญหาที่ยากในการแกไขหรือยังหาขอสรุปไมได อาจเปนสาเหตุให project ตอง หยุดไป การแกอาจทําโดยการสราง model หรือออกแบบการทดลองแกปญหา risk ใหเร็วที่สุดเทาที่จะ เร็วได

¾

Schedule risk การจัดการกับ schedule risk มักตองมีการ trade-off อาจใชวิธีดังนี้ 1)

การใช slack ชวยลด schedule risk ไดแตทําให activity ตางๆ เขาใกล late start มากขึ้น โอกาสที่ project จะมีความเสี่ยงในการเสร็จชาจะมีมากขึ้น

2)

Imposed duration date การไปบังคับที่ duration date ปกติ project 80% ใชวิธีนี้ เปนการสั่ง หรือตัดสินใจจากผูมีอํานาจ

(top-down)

ที่จะกําหนดวันเสร็จไวเลย

ซึ่งทําใหตองมีการประชุม

กําหนดวันทํา project ที่จะใหเสร็จเร็วกวาปกติและหาวิธีที่ low cost แตวิธีที่จะใหเสร็จเร็วมักมี cost สูง และมีโอกาสที่จะเสร็จชาและลดความยืดหยุนของ scheduling system

5

3)

Compressive of project schedule การพยายามหดใหระยะเวลาของ project สั้นลง โดยลดเวลา ของ activity ที่อยูบน critical path ซึ่งจะมีผลทําให direct cost เพิ่มขึ้น total slack ลดลง และ อาจมี critical path หรือ near-critical path เพิ่มมากขึ้น ทําใหมีโอกาสที่เกิดความเสี่ยงที่ project จะเสร็จชาลง บางทีการใช contingency plan อาจชวยหลีกเลี่ยง cost ได เชน schedule สามารถ เปลี่ยนไดโดยการทํางานแบบขนาน หรือใช start-to-start lag relationship หรือการใชคนที่ดี ที่สุดสําหรับงานที่มีความเสี่ยงสูง

¾

Cost risk สวนใหญมาจากความผิดพลาดหรือการละเลยจาก schedule และ technical estimate ในการ ตัดสินใจดานการจัดการมักรวม cost risk ไวดวย ซึง่ ประกอบดวย 1)

Time / cost dependency link : มีความเกี่ยวของกันระหวาง time , cost , technical problem เชน ถากิจกรรมหนึ่งตองการเวลามากกวาเดิม 50% คาดไดเลยวา cost ตองเพิ่มขึ้น

2)

Cash flow decision ซึ่งทําให schedule risk เพิ่มขึ้น ตัวอยางเชน financial analyst จะทําใหเกิด การเปรียบเทียบระหวาง early-start schedule กับ late-start schedule การที่ activity ลาชา ตาม ทฤษฎีวาเงินวันนีม ้ ีคานอยกวาเงินในอนาคต

3)

Price protection risks : project ที่ใชเวลานานๆ ตองการ contingency เพื่อการเปลี่ยนแปลง ของราคา (ซึ่งมักเพิ่มขึ้น) สิ่งสําคัญที่ตองจําคือ พยายามเลี่ยงการจับการใช one lump sum เพื่อ ครอบคลุม price risk เชน ถาเงินเฟอ 3% ผจก.หลายคนอาจจะ add 3% สําหรับ resource ใน project จริงๆ แลวควรทําแบบ item by item ผูซ  ื้อและ contractor หลายคนจะไมเปลี่ยนแปลง ราคาตลอดชวงอายุของ project การเปลี่ยนแปลงควรจะระบุและประมาณการถึงการเปลี่ยนแปลง อยางมาก

¾

Funding risks การที่มีความเสี่ยงดานการจัดหาเงินทุนทําใหมีผลกระทบตอ project 1)

contingency funding เพื่อครอบคลุมความผิดพลาดในการประมาณการ การละเลย และความไม แนนอนที่อาจมีผลตอการนํา project ไปปฏิบัติ โดยขนาดและจํานวนของ contingency ที่สํารอง ไวขึ้นกับความใหมของ project ความถูกตองของการประมาณการ cost , time , technical problem , minor change in scope , ปญหาที่ไมคาดคิด

2)

budget reserves ทําเพื่อระบุ specific work package หรือสวนของ project ที่พบใน baseline budget หรือ WBS ทําเพื่อระบุ risk ที่มีโอกาสที่จะเกิดขึ้นนอย เชน การเปลี่ยนแปลง design และ การประมาณการ time และ cost ที่ผิดพลาด

3)

management reserve ตองใหครอบคลุมสิ่งที่ไมเคยพบหลักๆ และเปน potential risk ซึ่งทํา หลังจาก budget reserve จะเกี่ยวของกับ budget reserve และถูกควบคุมโดย project manager และเจาของ project ตารางแสดงการทํา contingency fund estimate

Step 4 : Risk Response Control •

Risk control คือ การออกกลยุทธในการรับผิดชอบความเสี่ยงของฝายบริหาร การติดตามการกระตุนใหเกิดเหตุการณ การสราง contingency plan การเฝามอง risk แบบใหม การสรางระบบการบริหารการเปลี่ยนแปลง เพื่อ deal กับ เหตุการณที่ตองการการเปลี่ยนแปลง scope อยางเปนทางการ และ/หรือ schedule ของ project เปนสวนสําคัญ ของ risk control

•

Project manager ตองติดตาม risk เหมือนการติดตามความคืบหนาของ project การประเมินความเสี่ยงและ update จําเปนตองใหเปนสวนหนึ่งของทุกๆ ครั้งที่มีการประชุม และระบบรายงานความคืบหนา

•

Key ในการควบคุมคือ 1.

ทัศนคติในทางบวกของ project manager ที่มีตอ risk

6

2.

การมีเอกสารมอบหมายความรับผิดชอบ

Change Control Management •

Change management เปนสวนสําคัญของ risk control process การเปลี่ยนแปลงอาจมาจากหลายแหลง เชน ลูกคาของโครงการ , เจาของ , project manager , team member และเหตุการณความเสี่ยงตางๆ ที่เกิดขึ้น ซึ่ง แบงไดเปน 3 ประเภท 1.

Scope change ในรูปของ design , การเพิ่มบางสิ่งทําใหเกิดการเปลี่ยนแปลงอยางมาก เชน การที่ลูกคา รองขอลักษณะใหมหรือการออกแบบใหมที่จะพัฒนาผลิตภัณฑ

2.

การนํา contingency plan ไปปฏิบัติเมื่อเกิด risk event ซึ่งทําใหเกิดการเปลี่ยนแปลงใน baseline cost และ schedules

3.

•

การพัฒนาการเปลี่ยนแปลงตามคําแนะนําของ project team member

เพราะวา change เปนเรื่องที่หลีกเลี่ยงไมได การ review change ที่ดี และการควบคุมกระบวนการควรไดทําการ set up ไวแตเนิ่นๆ ใน project planning cycle

•

•

Change control system ประกอบดวย reporting , controlling , recording change เพื่อใหบรรลุ 1.

ระบุ change

2.

list ผลกระทบของ change ที่มีตอ schedule และ budget

3.

review , evaluate และ approve หรือ disapprove change อยางเปนทางการ

4.

ตอรอง แกปญหาความขัดแยงของการเปลี่ยนแปลง , condition , cost

5.

สื่อสารการเปลี่ยนแปลงให party ที่ไดรับผลกระทบทราบ

6.

มอบหมายความรับผิดชอบใหนําการเปลี่ยนแปลงไปปฏิบัติ

ตัวอยางดังรูป Change ถูกรองขอให review และ approve และ disapproved ภายในเวลาอันสั้นและจํากัด ถา project มีขนาดใหญ ทีม review อาจจะตองตรวจตราการเปลี่ยนแปลงของ project , change มักจะไมเพียงแต เพิ่ม cost แตอาจทําให delay และเพิ่มความกดดันใหกับ team member และขัดขวางลําดับของงาน ดังนั้นขอเสนอ การเปลี่ยนแปลงมักถูกตอตานจาก team member

•

ทุกๆ การเปลี่ยนแปลงที่ไดรับการอนุมัติ จําเปนตองถูกระบุและมีผลกระทบใน WBS ใน project และ baseline ถา ระบบควบคุมการเปลี่ยนแปลงไมมีการประสมประสานกับ WBS และ baseline แลว การวางแผนและควบคุม project จะถูกทําลายดวยตัวเอง ดังนั้น key ที่จะประสบความสําเร็จในกระบวนการควบคุมการเปลี่ยนแปลงคือ document

•

ประโยชนที่ไดจาก change control system มีดังนี้ 1.

กระบวนการที่เปนทางการจะตัดการเปลี่ยนแปลงที่ไมสําคัญออก

2.

มีการจํากัด cost ของการเปลี่ยนแปลงไว

3.

จะคงความเปนอันหนึ่งอันเดียวของ WBS และการวัด performance ไว

4.

มีการติดตามการจัดสรรและใช budget และ management reserve fund

5.

มีการแสดงความรับผิดชอบในการนําไปใชอยางชัดเจน

6.

ทุกสวนที่เกี่ยวของสามารถมองเห็นผลกระทบของการเปลี่ยนแปลงได

7.

มีการติดตามการนําการเปลี่ยนแปลงไปปฏิบัติ

8.

scope change จะสะทอนกลับใน baseline และการวัด performance ไดอยางรวดเร็ว

7

Chapter 8 Scheduling Resources (การจัดตารางทรัพยากรใหกบ ั องคกร) Type of project constraints 1.

Technical or logic constraints : การที่ตองรอกิจกรรมที่ 1 ใหเสร็จกอน จึงจะเริ่มกิจกรรมที่ 2 ได

2.

Resources constraints : การที่กิจกรรมสามารถทําขนานกันไปก็ได แตติดขัดที่มีผูทํากิจกรรมเพียงคนเดียว จึงตอง ทําทีละอยาง (แตละอยางทําอะไรกอนก็ได ที่สอดคลองกับเงื่อนไข)

3.

Physical constraints : พบนอย เชน การบูรณะซอมแซมเรือ มีขอจํากัดเรื่อง space ซึ่งตองใหคนทําคนเดียว

การขาดแคลน resource มีผลตอ 1) ความสัมพันธกับกิจกรรมที่ขึ้นแกกัน 2) กําหนดเสร็จ 3) cost ชนิดของ Resource constraints 1.

People : มักเนนเรื่องทักษะของคนหรือบุคลากร เชน programmer , mechanical engineer , … ซึ่งอาจหาคนแทน ได แตไมมี productivity เทา

2.

Materials : RM , WIP , FP

3.

Equipment : ปริมาณ ประเภท ขนาด

4.

Working capital

ปญหาของการทํา scheduling Problem 1. Time-constrained project

Fixed time

Flexible

Method

resources

Resource leveling or smoothing (การเกลี่ย resource ใหสม่ําเสมอ)

2. Resource-constrained project •

resources

time

Resource-constrained scheduling

Resource Leveling or Smoothing ¾

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

¾

Concept : ถา demand มีการแกวงตัวมากจะจะจัดการไดยาก และการใชประโยชนจะทําไดไมเต็มที่

¾

วิธีการ : พยายามที่จะ delay non-critical activities (ทําไดเพราะวามันมี slack) โดยที่ไมใหเกิน slack ที่ มีอยู เพื่อลดความกวัดแกวงของ demand

1

¾

ตัวอยาง การจัดสวนพฤกษชาติที่กําหนดวา เวลาจํากัด ตองเสร็จภายใน 24 สัปดาห , resource คือ รถ Backhoes (Bh) อยางเดียว และแตละคันสามารถทดแทนกันได

Botanic Garden

o

รูปบน แสดงกิจกรรมตามเวลา ในแทงแสดง resource ที่ใช , chart กลาง แสดง resource ที่ใช ตามเวลาโดย period 4-10 ใช 4 คัน

o

เนื่องจาก project ,ขอจํากัดเรื่องเวลา เปาหมายจึงตองลด peak requirement ของ resource จากการพิจารณาพบวา มี 2 กิจกรรมที่มี slack คือ fence & wall กับ irrigation ที่เราอาจโยกมา เติมตรงที่โหวของรูปกลาง พบวา ถาเอา irrigation ยายมา ก็จะยังไดรูปที่เปนเหมือนฟนหลอ (การใชงานไมสม่ําเสมอ) แตถายาย fence & wall มาจะ smooth กวา ไดตามรูปลาง peak demand จะลดจาก 4 เปน 3

¾

¾

ประโยชน 1.

demand peak ลดลง

2.

การใช resource ตลอดชวงอายุ project ลดลง

3.

การกวัดแกวงของความตองการ resource ถูกทําใหนอยที่สุด

ขอเสีย : ขั้นตอมา ถาพบปญหาวา Backhoe ไมสามารถที่จะ move จากที่หนึ่งไปยังอีกที่หนึ่งไดโดยงาย ตองมี cost ดวย หรือ flexibility ลดลงจากการลด slack โอกาสเสี่ยงที่กิจกรรมจะ late มีเพิ่ม มากขึ้นดวย เพราะการลด slack อาจทําใหเกิด critical or near critical activity เพิ่มขึ้นดวย ดังนั้นการปรับ leveling ไกลไปอาจมีความเสี่ยงที่กิจกรรมจะหลายเปน critical ได สรุปวา การ ทํา leveling project resource โดยใชกิจกรรมที่มี slack จะทําให risk ลดลงได แต flexibility ก็ลดลงดวย

¾

อีกตัวอยางหนึ่ง กําหนดงานเปนดังนี้

2

d a,2 (2) c,5 c

f

(4)

(2)

b,3

e 8

a

6

slack

2

a

slack

2

b

คน

0

1

2

c

2

4

c

b

4

0 3

4

5

0

1

2

3

4

5

4

5

หลังเกลี่ย

คน

8

8

6

6

b

4

a

คน

c

2

b c

2

0

0 0

•

a

4

1

2

3

4

5

0

1

2

3

Resource-constrained project ¾

Concept : เวลายืดหยุนได แตเราก็ไมอยากใหมัน late ออกไปมากนัก แตตองใชทรัพยากรอยางจํากัด เวลาทํางานขยายออกไปไดถาจําเปน แตถาไมขยายไดยิ่งดี

¾

วิธี 1.

2.

Heuristic Approach : กฎการ assign ทรัพยากรใหกับกิจกรรมใดกอน ใชกฎดังนี้ 1)

กิจกรรมที่มี slack นอยที่สุดกอน แตถามีกิจกรรมที่มี slack เทากัน ดูที่ขอ 2

2)

กิจกรรมใดใชเวลานอยที่สุด ใหทํากิจกรรมนั้นกอน แตถามีกิจกรรมที่ใชเวลาเทากัน ดู

3)

Number งานที่มากอน

Parallel method : ใชควบคูกับ Heuristic หลักการ ทําซ้ําๆ จาก step แรกดูวา period แรกวาเอา resource ใหใครกอน ถาเทากันใช Heuristic

¾

ตัวอยาง กําหนดแตละ period ใช resources ไดแค 3 unit และมี assumption วางานหรือกิจกรรมไม สามารถแยกได

คือเมื่อทําแลวตองทําใหตอเนื่องจนเสร็จกิจกรรมนั้น

2.

ไมสามารถเปลี่ยนระดับความ

ตองการ resource ในกิจกรรมได (จริงๆ แลวเปนไดยาก)

3

4

o

Network แรกพูดถึงลําดับของกิจกรรม ซึ่งนํามาเขียนลงตารางไดตามตารางรูปแรก ซึ่งจะเห็นวา บาง period ใช resource เกิน 3 ตองทําการปรับแตละ period โดย 1-2

A เทานั้น

3

B,C,D โดย C มี slack นอยที่สุด ลงตอเนื่องจนเสร็จ ดู B,D - B มี slack นอยรองลงมา แตไมสามารถลงได เพราะ resource รวมจะเกิน แต D ลงได ทําให B ตองเลื่อนไปจน C เสร็จแลวจึงเริ่มได คือวันที่ 6

6

เมื่อลง B ที่ใช resource 2 หนวย ไป 6 period แลว พิจารณา E,F – F มี slack นอย กวา และใช resource = 1 ดังนั้นลงไดเลย 4 period สวน E ตองลงเมื่อ F เสร็จแลว คือ period 10

12

o

G

สุดทาย ตองทํา network ใหมที่สะทอนการเปลี่ยนแปลง ES , LF , Slack และมีเวลาของ project เปน 14 วัน (จากเดิม 12 วัน) โดยนําคาจากตารางไปลงเอง ไมตองไล network เหมือนตอนแรก จะเห็นวา slack ของ network ใหมนี้ลดลง , project duration เพิ่มขึ้นจาก 12 เปน 14 จํานวนของ critical activity เพิ่มขึ้นจาก 4 activity เปน 6 activity

ผลกระทบของ Resource-Constrained scheduling

ลด slack , ลด flexibility โดยการใช slack เพื่อใหมั่นใจวาเกิด minimize delay , จํานวน critical / noncritical activity เพิ่มขึ้น

ความซับซอนของ scheduling เพิ่มขึ้นเพราะ resource-constraint และมี technical constraints เพิ่มเขามาดวย ตอนเริ่ม start time

critical path concept of sequential activity แตกออกและออกจาก network ดวยชุดของ disjointed critical activities ในทางกลับกัน parallel activity จะกลายเปน sequential และกิจกรรมที่มี slack บน time-constrained network จะสามารถเปลี่ยนจาก critical เปน noncritical

•

Critical-chain Approach ¾

Goldratt เสนออีกทางเลือกหนึ่งวา แทนที่จะใช slack เขาใช buffer เพื่อเรงเวลาใหงานเสร็จเร็ว เพราะ เขาคิดวาคนงานสวนใหญชอบเผื่อเวลาไว ทําให project เสร็จไมทันกําหนดเวลา โดยเขามีแนวคิดดังนี้ 1.

Parkinson’s Law : จะเรงทํางานเมื่อใกล due date

2.

Self-protection : ไมบอกวางานเสร็จแลว เพราะกลัววาจะมีการปรับ std. หรือการเรงกําหนด เสร็จใหเร็วขึ้น

¾

3.

Dropped baton : การที่งานแรกเสร็จแลว แตหนวยงานที่ 2 ยังไมพรอมที่จะทํา

4.

Excessive multitasking : การที่มีงานมากเกินไป

5.

Resource bottleneck

6.

Student syndrome : จะไมเริ่มทํางานจนกวาจะถึงเวลาที่จําเปน

เขาจึงเสนอแนวทางในการแกปญหา ดังนี้ 1.

ใชกฎ 50/50 ในการประมาณการเวลา โดยลดเวลาทํางานลง ครึ่งหนึ่ง โดยโอกาสที่งานนั้นจะ เสร็จมีแค 50%

¾

2.

ใช project time buffer ในการประมาณการโครงการของเวลา

3.

ใส feeder buffer ตรงชวงตอระหวาง non-critical กับ critical activity

ตัวอยาง

5

o

สวนที่แรเงาสีชมพูของภาพบน และสวนสีเทาของภาพลาง คือ critical path กรณีที่ยังไมไดดู เรื่อง resource

o

แตเมื่อดู resource ซึ่งในที่นี้คือ คน จะเห็นวา Ryan ทําทั้งกิจกรรมที่ 3 และกิจกรรมที่ 6 จะเห็น วาไมสามารถทําได เนื่องจากเวลามีการคาบเกี่ยวกัน ตองเลื่อนกิจกรรมที่ 6 ออกไปใหเริ่มตนที่ วันที่ 20 เวลาของ project ก็เลื่อนออกไป โดยจะเสร็จในวันที่ 50 ดังรูป

6

o

รูปขางลางเปนการใชทฤษฎีของ Goldratt ที่มีการลดเวลาของแตละกิจกรรมลง 50% ทําให โอกาสที่ project จะเสร็จมีแค 50% , มีการเพิ่ม buffer ที่กิจกรรมสุดทายใหครึ่งหนึ่ง , มีการ เติม feeder buffer ระหวาง non-critical กับ critical activity พบวาสุดทายกิจกรรมเสร็จในวันที่ ประมาณ 27 ซึ่งลดลงกวาเดิม แตโอกาสที่จะเสร็จมี 50%

¾

ขอเสีย : ขาดความเปนจริง เพราะเหมือนไมมีความเชื่อใจกันเลย

Splitting / Multitasking

เปนเทคนิคในการจัดกําหนดการเพื่อที่จะใหได project schedule ที่ดีกวาหรือเพื่อเพิ่ม resource utilization โดย ฝายวางแผนจะ split งานที่ตอเนื่องใน activity โดย interrupt work แลวสง resource ไปให activity อื่นใหทันตาม เวลาแลวมี resource resume work บน activity ดั้งเดิม โดยจะเปนเครื่องมือที่เปนประโยชนถาไมมี start-up หรือ shut-down cost ในการยายเครื่องมือจากที่หนึ่งไปยังอีกที่หนึ่ง

Error ที่พบมากคือ การ interrupt “people work” ในขณะที่มี conceptual start-up และ shutdown cost รูป 8.10 แสดงการ split ของ original activity ออกเปน 3 activity ยอยๆ คือแตกเปน A,B,C ซึ่งงานจะมี shut-down และ start-up

7

การทํา multitasking เพื่อแกปญหาขาดแคลน resource นี้ทําให project ไมเสร็จตามกําหนด ฝายวางแผนควรใช เมื่อ splitting cost นอยๆ หรือไมมีวิธีอื่นในการแกปญหา

ประโยชนของ Scheduling resources

การสราง schedule กอนเริ่ม project จะทําใหสามารถเห็นวาถา schedule มีการ delay มากจนยอมรับไมได หรือมี โอกาสเสี่ยงที่จะ late สูง ขอสมมติฐานที่จะเปน resourced-constrained จะถูกประเมินใหม และจะตอง trade-offs ระหวาง cost กับ time ซึ่งบางทีอาจทําให priority เปลี่ยน

Resource schedule จะใหขอมูลที่ใชสําหรับเตรียม time-phased work package budgets with dates อยางหนึ่ง คือจะไดเครื่องมืออยางรวดเร็วที่จะวัดผลกระทบของเหตุการณที่ไมเคยเกิดมากอน เชน turnover , equipment breakdown หรือ transfer of project personnel

Resource schedule ทําให project manager ไดประเมินความยืดหยุนที่มีตอ resource นั้น ซึ่งมีประโยชนเมื่อไดรับ การรองขอจาก manager อื่นที่จะขอยืมหรือ share resource หรือการใชเพื่อขอ IOU ระหวางดําเนินการ

Assign project work

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

นอกจากนี้ยังตองตัดสินใจดวยวาจะใหใครทํางานกับใคร โดยดูจากหลายปจจัยดังนี้ 1.

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

2.

ประสบการณ : ผูที่มีประสบการณมากควรจับกับคนที่มีประสบการณนอย เพื่อแบงปนประสบการณกัน และเปน การชวยผูที่มาใหมใหเปนธรรมเนียมปฏิบัติขององคกร

3.

ควรพิจารณาถึงความตองการในอนาคต เชน คนที่ไมเคยทํางานดวยกันมากอน แตอาจตองพบกันในอนาคต ก็ใหสรางความคุนเคยกันไวกอน

Multiproject resource schedule

ในความเปนจริง resource จะตองถูกจัดสรรใหกับหลายๆ project ซึ่งอาจมี priority , ความตองการใช , จํานวน activity , risk ที่แตกตางกัน ซึ่งทําใหเกิดปญหา

8

1.

Schedule ทั้งหมดตองเลื่อนออกไป เพราะตองมีการ share resource ซึ่งทําใหเกิด delay เปนระลอก

2.

การใชประโยชนจาก resource ไมมีประสิทธิผล เพราะ project ที่มี schedule และความตองการ resource แตกตางกัน จะเกิด peak และ valley ใน resource demand ทั้งหมด

3.

resource bottleneck เกิดการ delay และ schedule ยืดออกเพราะขาด resource ที่ใชในหลาย project

เพื่อแกปญหานี้ หลายบริษัทตั้งหนวยงานเพื่อดูแลการใช resource โดยเฉพาะ วิธีหนึ่งที่ใชกันคือ first come – first served หรือ project queue system แตการใชประโยชนของ resource ก็ยังไมดีเทาที่ควร หลายบริษัทใชวิธี วางแผนโดยละเอียดโดยการ treat แตละ project เหมือนเปนสวนหนึ่งของ project ใหญๆ และนํา scheduling heuristic มาใชกับโครงการเหลานี้ ติดตามการใช resource , update schedule รายงานความคืบหนาของ project และ resource ที่มีของทุก project ปจจุบัน software project management ทําได

Centralized project scheduling ยังชวยทําใหงายในการระบุ resource bottleneck ได เพื่อที่จะหาวิธีแกไข เชน เพิ่ม equipment รับ critical personnel หรือเลื่อน project

หลายบริษัทใชวิธี outsourcing ในการแกปญหา resource allocation โดยลดจํานวน project ที่รับผิดชอบโดยดูแล แต core project สวนที่เปน non-critical ให contractor หรือ consult firms ดูแลแทน หรือการ outsource สวนที่ เปน specific segment of project

การจางพนักงานชั่วคราวเพื่อเรงกิจกรรมที่ชากวา schedule หรือที่เปนชวง peak period ที่ resource ภายในไม เพียงพอ

9

Chapter 9 Reducing Project Time (การลดเวลาของ Project) เหตุผลที่ตองลดเวลาของ project 1.

Imposed project โดยเปนการกําหนดเวลาในชวง concept phase หรือมีเหตุการณบางอยางที่ตองรีบเรงกําหนดวัน ใหเสร็จ

อาจเปนเงื่อนไขทางการตลาดที่ตองกําหนดวันเสร็จของโครงการ

อาจเพื่อเพิ่มความไดเปรียบในทางการ

แขงขัน ที่ตองรีบ launch project ออกมากอนทั้งนี้โดยไมไดดูความเปนไปไดของโครงการ 2.

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

3.

Save high overhead เนื่องจาก OH cost เปน cost ที่ไมได allocate โดยตรงกับ project หลัก เชน การที่ให ผูเชี่ยวชาญมาดูงาน ถาลดจํานวนวันที่มาได ก็จะเปนการลด cost ไดดวย

Cost-time Trade-off Problem •

ตองทําการ trade-off ระหวางตนทุนที่เพิ่มขึ้นวาใหผลตอบแทนคุมคากับเวลาที่ลดลงไปหรือไม

•

หลัก : ตองเรงที่ critical activity ที่กอใหเกิดตนทุนตอหนวยของการเรงเวลานอยที่สุด

Project cost •

Project cost คือผลรวมของ Indirect cost กับ direct cost

•

Indirect cost : หรือ overhead cost เปน cost ที่ไมไดเกี่ยวของโดยตรงกับ project เชน คาน้ํา คาไฟ คาเชา คา บริหาร คาที่ปรึกษา ดอกเบี้ย เปนตน ซึ่ง IC จะแปรผันตรงกับเวลาทํางาน เวลาเพิ่ม cost สูงขึ้น

•

Direct cost : เปน cost ที่เกี่ยวของโดยตรงกับ project เชน คาแรง material equipment เปนตน ซึ่ง DC จะ แปรผกผันกับเวลาทํางาน เวลาเพิม ่ cost ต่ําลง ดังรูป

•

ซึ่งหลักการลดเวลาทํางานตองลดใหมี Total cost หรือ DC + IC ต่ําที่สุดตามรูป คือจุด optimum cost-time point ซึ่งจากรูป คือลดเวลาใหเหลือ 10 วัน จะมี TC ต่ําที่สุด Project cost-time graph

1

Definition •

Crashing : shortening an activity การลดให activity มีเวลาสั้นลง

•

Crash time : เวลาที่นอยที่สุดเทาที่จะเปนไปไดที่จะทํากิจกรรมนั้น และมีความเปนไปไดที่จะทํา Activity graph

•

จากรูปถาทําแบบสมเหตุสมผล จะใชเวลา 10 time unit (normal time) และมี normal cost $400 แตถาตองการเรง ใหกิจกรรมเสร็จเร็วขึ้นโดยลดเวลาเหลือ 5 time unit จะมี cost $800

•

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

•

Assumption

Cost-time relationship is linear

Normal time assume มี low-cost และใช efficient method เพื่อให project complete

Crash time เปน limit คือเวลาที่ลดไดมากที่สุดแลวที่เปนไปได ภายใตสภาวะที่เปนจริง

Slope เปนตัวที่บอกคาตนทุนตอหนวย (cost/unit time) ที่ใชในการ crash activity ถาชันมากแสดงวา cost/unit time สูง

การเรงตองอยูในชวงระหวาง normal time กับ crash time โดยมีสูตรวา Cost slope =

crash cost – normal cost

หรือ CC - NC

normal time – crash time

NT - CT

จากตัวอยางคํานวณได = ($800 - $400) / (10 - 5) = $80 / time unit แสดงวา ถาตองการใหเสร็จ 9 วัน ตองมี cost $400 + $80 , ถาตองการใหเสร็จ 8 วัน จะมี cost $400 + $80 + $80

•

ตัวอยาง cost-time trade-off sample

หา maximum crash time : maximum crash time = normal time – crash time

หา slope : slope = crash cost – normal cost

และพบวา slope ของ G = 0

maximum crash time

ดู network วาเสนทางใดเปน critical path และควรจะลดเวลาของ activity ใด

2

Cost-time trade-off sample

หมายเหตุ : การใส “X” หมายถึงลดเวลาไมไดอีกแลว

รูปแรกเปนเวลาปกติ 25 วัน critical path A-D-F-G cost $450 เมื่อดูจากคา slope ควรลด A กอน เหลือ 24 วัน cost $450 + $20 = $470 และ critical path ยังคงเปนเสนเดิม ดังรูปที่ 2

ดู slope ของ D , F ลด D ไดเวลาเปน 23 วัน cost $470+$25 = $495 และ critical path เพิ่มเปน 2 path ดังรูปที่ 3

จากรูป 3 จะเห็นวามีกิจกรรมที่รวมกันดวยคือ F ตองลด F ไดเวลาเปน 22 วัน cost = $495 + $30 =$525 ตามรูปที่ 4

จากรูปที่ 4 พบวาในขณะนี้ critical path เพิ่มเปน 3 เสนทางแลว การลดตองลดทั้ง 3 path โดย path แรก ลดไดที่ B กับ F ดูคา slope แลวลดที่ F , path ที่สอง ลดที่ C (เทานั้น) path ที่ 3 ลดที่ D (เทานั้น) โดยเวลาเหลือ 21 วัน cost = $525 + $30 + $30 + $25 = $610

เมื่อไดวาลดเวลาเปนเทาใดแลว นํา direct cost มารวมกับ indirect cost ที่กําหนดมาใหจะได total cost plot graph หรือดูคาจากตาราง เลือกจุดต่ําสุด จากตัวอยางนี้เลือกลดเวลา project เหลือ 22 วัน ซึ่งมีคา Total cost ต่ําที่สุด

3

การทาพนัน (I’ll bet you…)

•

เปนวิธีการกระตุนผูรวมงานเพื่อเรงให project ในชวง critical เสร็จเร็วขึ้น

•

Project manager อาจใชเพื่อเปนแรงจูงใจใหผูรวมงาน

•

อาจใหรางวัลเปน ตั๋วดูกีฬา หรือการแสดงตางๆ ของขวัญ บัตรรับประทานอาหาร หรือใหพักตอนบาย

Expectancy theory of motivation •

Can I do it ? ตรวจสอบตัวเองวาคุณทําไดหรือไม ถาทําไดลูกนองก็ทําได

•

Will I get it ? ถามตัวเองวาคุณวามี potential ที่จะทําหรือไม

•

Is it worth it ? คุมคาที่จะทําไหม

•

ถามีขอใดขอหนึ่งที่ลูกนองตอบ “No” แสดงวาเขาไมมีความกระตือรือรนที่จะทํา แตถาเขาตอบ “Yes” ทั้ง 3 ขอ ตอง กระตุน

คําแนะนําเกี่ยวกับการทาผูรวมทีม •

การทําใหงานเสร็จกอนกําหนด ถาผลประโยชนเกี่ยวของกับคนในครอบครัวดวย

•

การทําใหงานเสร็จกอนกําหนด ไมควรใหเกิดเปนประจํา เพื่อไมใหลูกนองเกิดการตอรอง ตองพิจารณาดวยวางานใด ควรทํา / ไมควรทํา

•

ตองมีความยุติธรรม ไมใหเกิดการอิจฉาริษยา และตองใหเขารูสึกวาคุมคาที่จะทํา

ทางเลือกอะไรบางที่จะใชในการลดเวลาทํา project เมื่อมี resources เพียงพอ 1.

Adding resources

Additional worker and equipment ¾

Increase communication requirements - ตองมีการสื่อสาร

¾

Manage larger team – เสียเวลาจัดการทีมงานที่ใหญขึ้น

¾

Training new people - ตองอบรมพนักงานใหม

¾

Brook’s Law : adding manpower to a late software project make it later เพราะเหตุผล ขางตน

2.

Outsourcing project work (บางกิจกรรม หรือทั้ง project) เพราะ subcontractor อาจจะมีเทคโนโลยีหรือความ ชํานาญดีกวา

3.

Scheduling Overtime

Advantage : ไมตองมีการฝกอบรมกันใหม , เปนการหยอนใจจากการที่ไมไดทํางานในเวลาปกติ

Disadvantage : คนจะเหนื่อย (burnout) หรือเมื่อยลา (fatigue) , คาแรงที่ตองจาย วันธรรมดา 1.5 เทา วันหยุด 2 เทา

4.

Do it twice ; Fast and correctly – การรีบทําใหเสร็จไปกอน (quick and dirty) แลวกลับมาทําอีกครั้ง เชน ที่ Oregon ตองสราง stadium ใหทัน NBA ถาไมเสร็จจะเสียหายมาก จึงทําอัฒจรรยที่เปนที่นั่งชั่วคราวไปกอน เมื่องาน เสร็จแลวจึงกลับมาทันใหม

Option ที่เรงในกรณีที่ Resources มีจํากัด 1.

Fast-tracking : โดยการ rearrange network ใหม โดยจัด critical activity จาก sequential ใหเปน parallel หรือ การเปลี่ยนความสัมพันธจาก finish-to-start เปน start-to-start

2.

Critical chain

3.

Brainstorming time saving suggestion

4

4.

Reducing project scope : key ลด scope โดยไมลดคุณคา เชน การลด feature จากแผนเดิม และตองอธิบายให ลูกคาเขาใจดวย

5.

Phase project delivery สงบางสวนที่เสร็จแลวกอน แลวดูวาสวนที่เหลือใหเจาของรับผิดชอบไปทําตอไดหรือไม หรือการที่งานเสร็จบางสวน สงมอบใหเจาของเขาไปอยูบางสวน แลวสวนที่เหลือที่ยังไมเสร็จก็ทําตอไป

6.

Reducing quality ลดคุณภาพลง แตไมคอยดี

Cost reduction , not time 1.

Reducing project scope : ลด scope อาจใช WBS ชวยได

2.

Owner taken more responsibility : โอนความรับผิดชอบบางอยางไปใหเจาของทําเอง ซึ่งมีขอ  ดี คือ cost ลดลง ในขณะที่ scope เทาเดิม

3.

Outsourcing เมือ ่ การประมาณการเกิน budget ไปแลว การตรวจสอบ scope ใหมดูไมคอย make sense แตควรหา วิธีอื่นที่ถูกกวา เชน บริษัท internet แหงหนึ่ง (ไมแนใจวาใช MSN หรือเปลา) ทํา outsource ที่อินเดีย (โทรไป เบอรที่อเมริกา แตสายจะตอไปที่อินเดีย) เพราะคาแรงถูกกวา อยางไรก็ตาม เนือ ่ งจากการทํา outsource จะมีการ ควบคุมนอย ดังนั้นตอง define deliverable ใหชัดเจน

4.

Brainstorming cost saving options

5

Chapter 11 Managing Project Team Project Life Cycle Generic project life cycle Planning

Execution

Delivery

100%

% Complete

Definition

The project life cycle

0% Time

•

วงจรชีวิตโครงการมีลักษณะเปน S-curve

จึงเกิดปญหาวาจะทําอยางไรเมื่อสินคานั้นถึงจุดคงที่

จึงเกิดความ

พยายามที่จะยืดเวลา ทํา S-curve ชวงใหมๆ ตอไปโดยใช Know-how ที่มีอยู หรือการใช IT เขามาชวยใหเกิด S-

Effort

curve ตอเนื่องไปเรื่อยๆ

Project cost

Project cost

Time

t0 ,

Time

t1,

t2

Time

Estimate of project cost : estimate made at project start

Estimate of project cost : estimate made at time t0, t1, t2

Integration of organization strategy with projects •

Implementation gap - the lack of understanding & consensus of organization strategy among top and middle-level managers

•

25% of Fortune 500 executives believe there is a strong linkage, consistency, and/or agreement between the strategies they formulate and implementation

•

Projects & politics invariably mix & the effective project managers recognize that any significant project has political ramifications

•

A single-project priority system that rank projects by their contribution to the strategic plan would make life easier 21st Century problems

Æ

21st Century organizations

1

ยุคของเครือขาย (The Age of Network) •

Virtual teams – แตละคนอยูคนละที่ เชน Honda city , Toyota soluna เปนการทํางานรวมกันของวิศวกรไทยญี่ปุน

•

Network teams – การที่หลายๆ ทีมทํางานรวมกัน

¾

องคกรเครือขายสามารถเพิ่มประสิทธิภาพขึ้นเรื่อยๆ เมื่อเครือขายขยายตัวขึ้น

¾

เครือขายสามารถชวยลดชองวางในการประสานงานและเพิ่มความเขาใจในการทํางานมากยิ่งขึ้น

¾

เครือขายทําใหเกิดการทํางานขามหนวยงานหรือองคกร

รูปแบบของเครือขาย 1.

เครือขายองคกร (Network of organization)

2.

เครือขายบริษัท (Network of companies)

3.

เครือขายระดับชาติ (Network of nations) : APEC , NAFTA

Latest stage in evolution of organization •

Virtual teams

•

Networked organization Agricultural era

Hierarchy

Industrial era

More robust form

Information era

Networked organization

Bureaucracies emerged

A complex networked organization

Hierarchy

involve

แนวโนมในการบริหารจัดการ

Bureaucracy

Small groups

•

ชวงอายุของวงจรชีวิตผลิตภัณฑสั้นลง

•

การแขงขันในระดับโลก (Global competition)

•

การเกิดขึ้นขององคความรูใหมๆ

•

องคกรแบบ Flat organization

Making team effective

Purely functional structure

Independent team organization 2

ลักษณะของทีมที่มีประสิทธิภาพ ซึ่งแสดงถึง Synergy 1.

ทีมมีเปาหมายรวมกัน (common purpose) และสมาชิกแตละคนตั้งใจที่จะทํางานเพื่อบรรลุเปาหมายนั้น

2.

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

3.

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

4.

ทีมทุมเทความพยายามในการแกไขปญหามากกวาจะเพื่อการแขงขันกัน

5.

ความเห็นที่แตกตางไดรับการสงเสริมรับฟงและใหมีการแสดงออกไดอยางเปดเผย

6.

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

7.

สมาชิกมีมาตรฐานการทํางานสวนตัวคอนขางสูง และสงเสริมซึ่งกันและกันเพื่อบรรลุเปาหมายโครงการ

8.

สมาชิกแตละคนไดรับการสงเสริมทั้งในแงวิชาชีพและการเติบโตของแตละคน

ขั้นตอนการพัฒนาทีม 1. Forming

2. Storming 3. Norming 4. Performing 5. Adjourning

ระยะแรกของการตั้งทีม

ตองสรางความคุนเคยระหวางสมาชิก

สรางความเขาใจในขอบเขตโครงการ

กําหนดกฎเกณฑตางๆ พฤติกรรมที่พึงประสงค ความคาดหวังในผลงาน ฯลฯ

มีความขัดแยงภายใน

สมาชิกยอมรับวาเปนสวนหนึ่งของโครงการแตตอตานขอจํากัดตางๆ

สมาชิกมีความสัมพันธใกลชิดกัน มีความเหนียวแนนในทีม

แบงปนความรับผิดชอบ

งานดําเนินไปอยางเต็มที่

รวมมือกันทํางานเพื่อบรรลุเปาหมาย

เสร็จสิ้นโครงการ

ปจจัยที่ทําใหมก ี ารพัฒนาทีมที่มีประสิทธิภาพ •

สมาชิกมีจํานวนไมเกิน 10 คน หรือนอยกวา

•

สมาชิกอาสาทํางาน

•

สมาชิกเริ่มทํางานมาตั้งแตเริ่มจนเสร็จสิ้นโครงการ

•

สมาชิกไดรับมอบหมายงานในโครงการเต็มเวลา

•

สมาชิกเปนสวนหนึ่งขององคกรที่มีวัฒนธรรมสงเสริมความรวมมือและความไววางใจกัน

•

สมาชิกรายงานตอ Project Manager เพียงคนเดียว

•

ในทีมมีตัวแทนจากหนวยงานหลักอื่นๆ ทุกหนวย

•

โครงการมีสวนเกี่ยวของกับเปาหมายหลักขององคกร

•

สมาชิกมีฐานที่ตั้งที่สามารถติดตอพูดจากันได

การสราง Project Team ที่มีประสิทธิภาพ

สรรหาสมาชิกทีม

-

ประชุมทีมงานโครงการ

-

สรางเอกลักษณของทีม (team identity)

-

สรางวิสัยทัศนรวม (shared vision)

-

สรางระบบการใหรางวัล

-

บริหารการตัดสินใจ

-

บริหารความขัดแยง

-

นําการสรางทีม

ผลงานที่มีประสิทธิภาพ

3

การคัดเลือกทีมงาน นอกเหนือจากมีประสบการณ

ความรูความชํานาญทางเทคนิค

ที่จําเปนตอความสําเร็จของโครงการแลว

ยังตอง

พิจารณาเรื่องตอไปนี้ในการคัดเลือกทีมงานดวย คือ •

ความสามารถในการแกไขปญหา

•

อุทิศใหกับโครงการ

•

ความเชี่ยวชาญเฉพาะทาง

•

มีความนาเชื่อถือ

•

มีความสัมพันธทางการเมือง

•

มีความทะเยอทะยาน มีความคิดสรางสรรค มีไฟ

จัดประชุมโครงการ จัดประชุมครั้งแรกในการเริ่มตนโครงการเพื่อ •

กําหนดกฎเกณฑ

•

การวางแผน เชน กําหนดแผนงาน อุปกรณเครื่องมือเครื่องใช ผลลัพธ ฯลฯ

•

กําหนดการติดตามงาน เชน การประเมินความกาวหนาของงาน การรายงาน การประชุม

•

การบริหารการเปลี่ยนแปลง เชน อํานาจการตัดสินใจกรณีมีการเปลี่ยนแปลง แผนรองรับ

•

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

สรางเอกลักษณของทีม •

การประชุมที่มีประสิทธิภาพ

•

มีสถานที่ทํางานรวมกันของสมาชิกในโครงการ

•

ชื่อทีม

•

พิธีการของทีม

สรางวิสัยทัศนรว  ม •

เปนวิสัยทัศนเชิงกลยุทธ

•

สรางแรงบันดาลใจ

•

แสดงความมุงมั่น

•

สื่อสารใหรับรูทั่วถึง ตรงกัน

บริหารระบบการใหรางวัล สามารถทําไดหลายวิธี •

หนังสือชมเชย

•

ประกาศใหสาธารณชนรับรู

•

มอบหมายงานที่มีคุณคา

•

ความยืดหยุนในเรื่องกฎเกณฑบางอยางไดบาง

บริหารความขัดแยง •

Mediate

•

Arbitrate

•

Control

•

Accept

•

Eliminate 4

การบริหารทีมงาน IT (Virtual Team) •

ใหมีการพบปะกัน (face-to-face) เทาที่จะทําได เพื่อแกปญหาการสื่อสาร

•

ใหขอมูลทุกคนในทีมไดรับรูถึงสถานภาพโดยรวมของโครงการอยางสม่ําเสมอ

•

อยาปลอยใหคนในทีมหายหนาหายตาไป

•

กําหนดจรรยาบรรณเปนแนวปฏิบัติเพื่อปองกันความลาชา

•

กําหนด Norm และ Protocol ใหชัดเจน เพื่อปองกันความขัดแยง

ปญหาของทีม •

Groupthink เกิดจากความเหนียวแนนในกลุม จึงเห็นดวยกับเพื่อนรวมทีมไปทุกอยาง

•

Bureaucratic Bypass Syndrome

ทีมงานโครงการเกิดความเคยชินกับการลัดขั้นตอนตามโครงสายงานตามปกติ

ขององคกร •

Entrepreneur’s Disease เกิดความรูสึกเปนเจาของโครงการ อาจตัดสินใจเพื่อเปาหมายโครงการอยางเดียวโดยไม คํานึงถึงองคกรในภาพรวม

•

Team Spirit becomes Team Infatuation

เมื่อโครงการสิ้นสุดลง ทีมอาจเกิดความทอแทเพราะเคยประสบ

ความสําเร็จรวมกันมาโดยตลอด แตตองมาแยกยายกันไป •

Going Native ในการทํางานโครงการตองตอบสนองลูกคาเปนหลัก จึงอาจละเลยวัตถุประสงคขององคกรหลักได

ภาวะผูนํา •

มีเทคนิคในการสรางแรงจูงใจและสอนแนะงาน (coaching)

•

ตรวจสอบตนเอง (self-examination)

•

ศึกษาตอเนื่อง (continuing education)

•

มีความชํานาญในธุรกิจ (business apprentice)

•

บริหารการเปลี่ยนแปลง (change management)

•

สื่อสาร (communication)

•

เปนพี่เลี้ยง (mentoring)

บทบาทสําคัญของ Project Manager ที่มีประสิทธิภาพ •

รับรูถึงวัตถุประสงคโครงการของลูกคาไดอยางถูกตอง

•

ประสานงานทีมงานโครงการ รวมถึงทักษะทางวิชาการตางๆ ที่จําเปน

•

สรางตารางงานของโครงการ พรอมทั้งมีจุดตรวจสอบควบคุม

•

จัดใหมีการประกันคุณภาพ (quality assurance) ตามชวงเวลาที่เหมาะสม

•

จัดสรรงบประมาณอยางเหมาะสม

•

จัดใหมีงบฉุกเฉินและใชเพื่องานฉุกเฉินเทานั้น

•

มอบหมายอํานาจหนาที่ใหกับหัวหนางานแตละระดับ

และจัดใหมีการรายงานความกาวหนาของงานตามความ

รับผิดชอบตามระยะเวลาที่เหมาะสม •

สงเสริมใหมีการสื่อสารในระหวางสมาชิกทีมงานโครงการ และกับลูกคา

•

สรุปภาพรวมของโครงการใหทีมงานรับรูและเขาใจ

•

ระบุปญหาและหาทางแกไขที่เปนที่ยอมรับอยางรวดเร็ว

•

ติดตามความคาดหวังของลูกคาอยางใกลชิดและพยายามสนองตอบใหได

ผลการวิจัย Virtual team จากยุโรป เม็กซิโก และสหรัฐ พบวา Virtual team กําลังเผชิญความทาทายที่สําคัญ 4 ดานคือ 1.

การสื่อสาร

2.

วัฒนธรรม

3.

เทคโนโลยี 5

4.

การบริหารโครงการ

การสราง Project team ที่มีประสิทธิภาพ (Creating effective project teams) •

ลดความเปนไปที่จะเกิดผลลบใหนอยที่สุด (Minimize negative potential)

•

สรางความสมดุลของการแขงขัน (Match competitors)

•

สงเสริมกลยุทธ (Back the strategy)

•

สงเสริมความไดเปรียบที่โดดเดนและยั่งยืน (Pursue a distinctive, sustainable advantage)

รูปแบบของทีม 1)

Functional Team

ผูรวมงานเปนคนในฝายนั้น

มักพบในธุรกิจขนาดใหญที่เติบโตเต็มที่แลว

ทํางานภายใตการควบคุมของผูบริหารที่มีความชํานาญเฉพาะทาง

งานของหนวยงานและภารกิจมีการวางแผนไวลวงหนาโดยมีขอกําหนดอยางละเอียด และ มีการประชุมเปนครั้งคราวเพื่อแกปญหาหรืออุปสรรค

2)

Lightweight Team

แตละภารกิจจะเปนเจาของกระบวนการในการทํางานที่ใชอยู

สมาชิกทีมเปนตัวแทนจาก Function ตางๆ

บังคับบัญชาโดย Project manager

งานและการตัดสินใจทําโดย Function เดิม

ตัวแทนจากฝายตางๆ ยังคงเปนสวนหนึ่งของ Function โดยเพิ่มบทบาทการเปน Liaison ผูประสานงานนอกเหนือจากความรับผิดชอบประจําที่มีอยู

Project manager ขาดอํานาจควบคุมทรัพยากรตางๆ (รวมทั้งคนดวย) โดยจะเปนอํานาจ ของ Function เดิม

3)

Heavyweight Team

Project manager ใชเวลา 25% ในการทํางานในบทบาทนี้

Project leader รับผิดชอบโครงการทั้งหมด ซึ่งรวมถึงความสําเร็จของโครงการดวย

มักเปนผูบริหารอาวุโสหรือคนที่เกงๆ ในองคกร (champion)

งานทําอยูในกลุมของ

Function

แตจะเปนไปตามแนวทางและการสั่งการของ

heavyweight team และผูนําโครงการ

มักเปนงานที่เกี่ยวของกับหลายหนวยงาน

หรือเปนการแกปญหาสําคัญของหนวยงาน

ตองการผลอยางรวดเร็วและกระทบหลายฝาย

Project manager จะดึงคนที่มีศักยภาพจากแตละฝายมารวมงาน และเปนผูตัดสินใจ โดย ทํางานที่ใหม 75% function เดิม 25%

4)

Autonomous Team

(Tiger Team)

Autonomous team เปน heavyweight team ที่สมาชิกทีมถูกดึงออกจาก Function และ ยายมาประจําที่โครงการ

สมาชิกทีมจะมีที่ตั้งสองทาง (co-located) เชนเดียวกับ heavyweight team

ทีมนําโดย

Project

leader

ซึ่งมีอํานาจเต็มในการบริหารจัดการทรัพยากรและการ

ประเมินผลงานของสมาชิกทีม

เหมาะกับงานที่ตองการความรวดเร็ว เชน R&D

เวลาทํางานก็จะประชุมกันอยางจริงจัง

6

จุดแข็งจุดออนของทีมแบบตางๆ จุดแข็ง Functional team

Lightweight team

Heavyweight team

Autonomous team

จุดออน

การใชทรัพยากรและความเชี่ยวชาญ

Bureaucratic

ความประหยัดจากขนาด

ไมใหความสําคัญกับงานโครงการ

การควบคุม

การทํางานชา

ความรับผิดชอบ

ไมรวมมือ ไมประสานงานกัน

การเติบโตตามสายงาน

ใชความชํานาญเปนตัวขับเคลื่อน

การสื่อสารและการประสานงาน

Project leader ไมมีอํานาจ

Idle time ระหวาง tasks ลดลง

เนนแตงานของโครงการ

บุคลากรแตละคนมีความกังวล

สรางความลําบากใหกับเจาหนาที่ที่ตองทําลาย

เนนงานโครงการมาก

ผูกพันกับโครงการ

ความรับผิดชอบ

การแกปญหาที่เปนระบบ

มุงผลลัพธ

มีความเปนอิสระ

เปนเจาของวัตถุประสงคเอง

ไมประสานกับองคกรหลัก

มีนวัตกรรม

ความเปนอิสระเปนคานิยมหลัก

บางทีลานเดิมหายไป เพราะมีคนมาทําแทนแลว

functional barrier

บทบาทใหมของผูบริหารระดับสูง •

กําหนดทิศทาง แนวทาง (Setting direction)

•

คัดเลือกและพัฒนาบุคลากร (Selecting and developing people

•

บริหารจัดการใหงานแลวเสร็จ (Shaping how work gets done)

บทบาทของผูบริหารระดับสูง 1) Team launcher •

กําหนดเปาหมาย Milestones และใหความชวยเหลือแกสมาชิกทีม

•

กําหนดงานหลักและขอบเขตงานของทีม

•

คัดเลือกทีมงานที่เหมาะสม ทั้งตอโครงการและลูกคา

•

บริหารสัญญา สรางความรับผิดชอบรวมกันระหวางทีมกับฝายบริหาร ในแงของแผนงานและผลลัพธ

2) Energy source •

จัดสรรเงิน บริการ การสนับสนุน ฯลฯ เพื่อใหงานบรรลุผลสําเร็จ

3) Commitment manager •

สนับสนุนสงเสริมเปาหมายโครงการใหบรรลุผลสําเร็จ

•

รับผิดชอบในผลลัพธตามแผนงานที่กําหนด

4) Sponsor / Coach •

ชวยเหลือทีมโครงการในการจัดการกับเรื่องฉุกเฉินตางๆ

•

ใหคําแนะนําแกทีม โดยใชประสบการณที่ผานมา

•

บทบาทหลักของ sponsor / coach คือ ชวยเหลือทีมงานหลัก

•

จัดสรรทรัพยากรตามความจําเปน

5) Process improver •

นําผลจากทีมงานไปปรับปรุงการดําเนินงานขององคกร

•

เมื่อโครงการสําเร็จแลว จะตองจัดใหมีกิจกรรมตอไปในองคกร

•

สรางการเรียนรูใหเกิดคุณคาเพิ่มในองคกร 7

Chapter 13 Progress & Performance Measurement & Evaluation The project control process มีเพื่อตอบคําถามถึง

•

สถานภาพในปจจุบันทั้งดานเวลาและคาใชจาย

จะตองใชเงินเทาใดจน project เสร็จ

เมื่อใด project จะเสร็จ

มีปญหาใดที่ตองรีบดําเนินการหรือไม

Cost หรือ schedule ที่เกินจะเกิดกับกิจกรรมใด เมื่อไร

ตองจายเงินเพื่ออะไรบาง

ถามี cost ที่ overrun ในระหวาง project จะพยากรณ overrun เมือ ่ จบ project ไดไหม

ปญหาที่คาดวาจะเกิด แกไขทันหรือไม

ระบบที่เรียกวา Earned value (EV) จะชวยตอบคําถามนี้ ซึ่ง validity ของรระบติดตามขึ้นอยูกับความถูกตองและ ความเชื่อถือไดของขอมูลวามีมากนอยแคไหน ประโยชนของ EV system ขึ้นกับขอมูล WBS , resource , time and cost estimate , time-phased budget ของแตละงาน และการประมาณการ % complete ที่เปนจริงและถูกตอง เทาที่จะทําได

การวัดและประเมิน performance ตองการ control process 4 ขั้นตอนตอไปนี้ 1.

Setting a baseline plan จะให element ที่วัด performance ซึ่ง derived มาจาก cost และ ขอมูลดานเวลาที่ได จาก WBS (งาน เวลา งบประมาณ) ซึ่งแตกงานออกมาเปน WP ซึ่งมาจับกับ deliverable และ organization unit และลําดับงานจาก network และ resource scheduling decision

2.

Measuring progress and performance เชิงปริมาณคือ time และ budget ไมดูคุณภาพ การวัดเวลาทํางาย ดู critical path เสร็จทันเวลา/ชากวา/เร็วกวา แตการวัด performance เทียบกับ budget (เชน เงิน unit in place ชั่วโมงทํางานของคนงาน) วัดยาก EV จึงมีวิธีการประมาณการ performance against a time-phased budget โดย ทําเปน budget cost of work performed (BCWP)

3.

Comparing plan and actual

4.

Taking action ถามีการ deviate จาก plan อยางมีนัยสําคัญตองทํา corrective action เพื่อให project กลับมาตา plan เดิม หรือ plan ที่ revised ใหม บางกรณีอาจถึงตองเปลี่ยน scope ซึ่งมีผลทําให baseline plan เปลี่ยนดวย

Monitoring time performance •

Tool : Gantt Chart ซึ่งเปนที่นิยมใช และเขาใจงาย ทําใหมองเห็นภาพรวมของ project status ณ วันที่รายงาน ผลไดอยางรวดเร็ว

•

รูป Baseline Gantt Chart แทงบน – แสดงถึงแผนที่วางไว แทงลาง – งานที่ทําเสร็จจริง ณ วันนั้น

1

•

Control chart ก็เปนเครื่องมือที่ใชติดตามความคืบหนาของ project โดยมีการ plot ความแตกตางระหวาง schedule line บน critical path ณ วันที่รายงาน กับสิ่งที่เกิดขึ้นจริงบน critical path ดังรูป ซึ่งสามารถใชเตือนไดวาตอนนี้มี แนวโนมเปนอยางไร ควรปรับตัวอยางไร

Monitoring cost system •

Tradition : compare actual against budget

•

Pitfall : ดูแตตัวเงิน ไมไดดูวางานที่สําเร็จสอดคลองกับเงินที่จายไปหรือไม

•

ตัวอยาง : สมมติวาวางแผนวาจะใชเวลา 10 เดือนใหงานเสร็จ และตั้ง budget วาแตละเดือนมีคาใชจาย $200,000/ month ดังนั้น 10 เดือน ควรมีคาใชจาย $ 2.0 million แตเมื่อผานไป 5 เดือน ปรากฏวาใชเงินไปแลว $1.3 million ซึ่งความเปนจริง อาจเปนเพราะ 1) ทํางานไดเร็วกวากําหนด 2) ทํางานชาจริง และใชเงินเกินดวย 3) ทํางานไดตาม เวลา แตใชเงินเกิน

An Integrated Cost / Schedule System •

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

•

Three data elements ¾

BCWS : Budgeted cost of the work schedule ตนทุนที่วางไว

¾

BCWP : Budgeted cost of the work performed หรือ earned value ตนทุนที่วางไวสําหรับงานที่ทํา แลว หรือปริมาณงานที่เกิดขึ้นจริงตามเงินที่จายไป มีคา BCWP = BCWS x percent of work actually completed

¾ •

ACWP : Actual cost of the performed

Variance ¾

Schedule variance : ผลตางระหวาง EV ที่เสร็จกับ baseline schedule SV = BCWP – BCWS

¾

Cost variance : ผลตางระหวาง EV และ actual cost ของวันที่งานเสร็จ CV = BCWP – ACWP

¾

การแปลผล

คา + แสดงวา budget ที่ตั้งไวมากกวาที่ใชจริง เปนผลลัพธที่เราตองการ และตองดูดวยวาเปน เพราะอะไร 2

CV ดูวาตนทุนที่ใชทํางานเสร็จแลว มากกวา หรือนอยกวา ที่วางไว ดูชวงเวลาใดชวงเวลาหนึ่ง

SV วัดปริมาณของงานออกมาเปนจํานวนเงิน ไมใชเวลา โดยจะบอก status ของงานวาชาหรือ เร็วกวากําหนด

Methods of variance analysis •

BAC : Budget cost at completion

•

EAC : Estimated cost at completion

•

VAC : Variance at completion VAC = BAC – EAC

•

เสนกลางคือ baseline เปนการวางแผนไวลวงหนากอนที่เราจะทําโครงการ จากรูปเสร็จในเวลา 45 วัน เงินทั้งหมด ควรใช $400

•

เราอยูวันที่ 25 ตองการดูความคืบหนาของโครงการ

ถาดูแต cost คือเสนบน Æ ตนทุนเกิดขึ้นจริง $340 (85% ของตนทุนทั้งหมดที่เกิดขึ้น) แสดงวาใชมากกวาที่ควรจะ เปน (ควรเปน $300 , 75%) หรือแสดงวาเราทํางานชาไป 5 วัน (เพราะเงินเทานี้ควรทํางานได 30 วัน) CV

SV

=

BCWP – ACWP

=

$200 - $340

=

- $140

=

BCWP – BCWS

=

$200 - $300

=

- $100

Æ over budget

Æ behind schedule

3

Developing a status report Assumption 1.

แตละ cost account มี WP อันเดียว แสดงเปนกิจกรรมบน network

2.

ใช ES เปนตัวเริ่มตนในการคิด

3.

คา baseline value เปน linear

4.

from the moment work on an activity begins , some actual costs will be incurred each period until the activity is completed

4

จากตารางสรุปไดวา CV = +$12 , variance at completion (VAC) = -$17

Indexes to monitor process •

Performance index 1.

CPI : Cost performance index = BCWP / ACWP

2.

SPI : Scheduling performance index = BCWP / BCWS Index

Cost (CPI)

Schedule (SPI)

> 1.00

Under cost

Ahead of schedule

= 1.00

On cost

On schedule

< 1.00

Over cost

Behind schedule

จากขอมูลในรูปดานบน CPI

=

BCWP / ACWP

=

42/30

=

1.4 Æ under cost Æ ทุกๆ $1 ที่จายไปกอใหเกิดงานที่เสร็จแลวมีมูลคา $1.4 Æ ชอบ

SPI

=

BCWP / BCWS

=

42/34

=

1.24 Æ ahead of schedule 5

•

Project percent complete index PCI-B

=

BCWP / BAC

PCI-C

=

ACWP / EAC

จะใชตัวไหนขึ้นอยูกับวาเราตองการแสดงตัวไหนใน project ¾ PCI-B assumes the original budget of work complete is the most reliable information to

measure project percent complete. ¾ PCI-C assumes the actual costs-to-date and expected cost at completion are the most reliable

for measuring project percent complete PCI-B

=

42/139 = 30% Æ

งานที่ทําเสร็จแลว ณ สิ้น period ที่ 4 คิดเปนมูลคา 30% ของงานที่วางไว

PCI-C

=

30/156 = 19%

Other control issues •

Baseline จริงๆ แลวไมควรเปลี่ยน เปลี่ยนไดก็ตอเมื่อจําเปนจริงๆ -ถาไมเปลี่ยนจะ fail หรือ เปลี่ยนแลวใหผลดีขึ้น

•

Control สิ่งที่เกิดจริง กับ plan มักไมตรงกัน ควรทํา contingency fund เผื่อไวใชในยามจําเปนและใชเมื่อเปน formal (ไมใชสุมสี่สุมหา)

•

Scope creep – การที่ลูกคาเรียกรองใหเพิ่มทีละนิดละหนอย แตในที่สุดรวมๆ ดูแลวมาก เปนเหตุการณที่เกิดขึ้นโดย ปกติในชวงเริ่ม project ซึ่งตองควรระวัง

6

Glossary of terms BCWS

Budgeted cost of the work scheduled. A cost estimate of the resources schedule in a timephased cumulative baseline.

BCWP

Budgeted cost of the work performed. The earned value or original budgeted cost for work actually completed.

ACWP

Actual cost of the work performed. The sum of the costs incurred in accomplishing work.

SV

Schedule variance (BCWP – BCWS)

CV

Cost variance (BCWP – ACWP)

BAC

Budgeted cost at completion. The total budgeted cost of the baseline or project cost accounts.

EAC

Estimated costs at completion. Includes costs to-date plus revised estimated costs for the work remaining.

FAC

Computed forecasted costs at completion.

VAC

Variance at completion ( BAC-EAC or BAC-FAC ) . Indicates expected actual over-or underrun at completion.

LOE

Level of effort.

สรุป Chapter 8 Schedule resources •

Smoothing resource

•

Resource-constrained scheduling

Chapter 9 Reducing project times •

Crashing

Chapter 13 Progress & Performance Measurement & Evaluation ดร.ทิพยรัตน fbustrl@ku.ac.th , 09-6689012 , 02-3791595

7

Chapter 14 Project Audit and Closure การตรวจสอบการบริหารโครงการ Project Audit ประกอบดวยงานหลักๆ 3 สวน คือ 1.

ประเมินวาโครงการนั้นไดสงมอบประโยชนตามที่คาดหวังใหแก Stakeholders

หรือไม

มีการบริหารโครงการที่ดี

หรือไม และลูกคามีความพึงพอใจหรือไม สรุปคือ คุมคาหรือไมที่จะทําโครงการนั้นตอไป 2.

ประเมินวาที่โครงการไมสําเร็จนั้น เปนเพราะเหตุใด จุดออน จุดดี และปจจัยสงเสริมอยูตรงไหน เพื่อปรับปรุงโครงการ ตอๆ ไป

3.

ระบุวาควรจะปรับปรุงเปลี่ยนแปลงอะไรสําหรับโครงการตอๆ ไป

กลาวโดยสรุปแลว Project Audit ตองการ “ขอมูล” และเปนเครื่องมือในการปรับปรุงโครงการตอไป และการบริหารคุณภาพ รูปแบบของ Project Audit 1.

In-process Project Audits

เปนการตรวจสอบโครงการเพื่อเปลี่ยนแปลงแกไขสิ่งที่ไมถูกตองตามความจําเปน

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

Postproject Audits

เปนการตรวจสอบเพื่อรวบรวมขอมูลรายละเอียดตางๆ ซึ่งจะเปนเชิงลึกมากกวา In-process

Project Audits เนนในการนําเสนอสิ่งที่จะนําไปปรับปรุงการบริหารโครงการตอไปในอนาคต มักจะมองไปในระยะยาว กวา In-process

Project

Audits เปนการตรวจสอบผลการดําเนินงานของโครงการ แตจะมองในภาพกวางของ

บทบาทของโครงการที่มีตอองคกร เชน

ผลประโยชนในเชิงกลยุทธที่คาดไวนั้น ในความเปนจริงไดบรรลุหรือไม

ผูตรวจสอบ : •

คนในธุรกิจเองที่ไดรับการแตงตั้ง

•

ผูตรวจสอบภายนอกซึ่งเปนกลุมวิชาชีพที่ไดรับการฝกฝนการตรวจสอบการบริหารโครงการมาโดยเฉพาะ

•

ลูกคา

การตรวจสอบโครงการตองใช •

คน

•

เวลา

•

คาใชจาย

เพราะการตรวจสอบมีวัตถุประสงคเพื่อใหไดขอมูลมาปรับปรุงโครงการตอๆ ไป

จึงตองพิจารณาวาการตรวจสอบนั้น •

ทํามากเกินความจําเปนหรือไม

•

รบกวนการทํางานของผูรับผิดชอบในโครงการหรือไม

•

ตองใช เวลา คาใชจาย ไมมากเกินความจําเปน

•

อาจมีผลกระทบตอความรูสึก

•

ตองใชคนที่เปนกลางและไดรับการยอมรับ

•

ตองทําโดยเร็ว ไมยืดเยื้อ เพราะจะมีผลตอขวัญและกําลังใจของคนในโครงการได

•

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

•

ระยะเวลาการตรวจสอบ 1 สัปดาห สําหรับโครงการใหญ และ 1-2 วัน สําหรับโครงการเล็ก 1

•

ตองเปนคนที่มีความเปนอิสระ

•

จุดประสงคหลักไมใชการจับผิด แตตองการไดขอมูล

•

ใหหลีกเลี่ยงการวิพากษวิจารณ ตําหนิ

•

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

•

ทุกครั้งตองแจงใหผูรับผิดชอบทราบวา จะมีใครไปตรวจสอบ และตรวจเมื่อไร

•

ขอมูลตรวจสอบจะตองชี้แจงใหชัดเจนวาไดมาอยางไร เชน มาจาก Subjective, Judgment, Hearsay

•

ตองไดรับการสนับสนุนจากผูบริหารระดับสูง

ปจจัยที่มีผลตอรายละเอียดและความลึกในการตรวจสอบโครงการ 1.

Organization size

2.

Project importance : ความสําคัญของโครงการ ซึ่งวัดจาก จํานวนเงินที่ลงทุน และ ระดับของเทคโนโลยีที่ใช

3.

Project type : ใหญ กลาง เล็ก R&D หรือการนําเทคโนโลยีมาใชเพื่อการลด (อะไรสักอยาง อาจเปน cost)

4.

Project risk : ความเสี่ยงภัยของโครงการ ถาเสี่ยงมากตองมีการตรวจสอบ ทดลองแลวทดลองอีก

5.

Project size

6.

Project problem : ปญหาที่เกิดขึ้นในขณะที่บริหารโครงการ

The project audit process ขั้นตอนในการตรวจสอบมี 3 ขั้นตอน คือ ขั้นที่ 1 : Initiation and Staffing 1.

ลักษณะการตรวจสอบ

โครงการเล็ก ใชวิธีการ Informal เยี่ยมชม สอบถาม จดบันทึก

โครงการขนาดกลาง มีแผนการเขาตรวจสอบชัดเจน ตรวจสอบเปนระยะ (periodic)

โครงการขนาดใหญ มีแผนเชนกัน แตอาจมีการตรวจที่ไมไดวางแผนลวงหนาก็ได

2.

ใชบุคลากรจากภายนอกโครงการเพราะตองการคนที่มีความเปนกลาง และมุมมองจากภายนอก

3.

ลักษณะหัวหนาทีมตรวจสอบ

4.

เปนกลาง

ไมมีสวนไดเสียกับโครงการเพราะอาจมีอคติ

มีภาพลักษณเปนผูยุติธรรม

เปนคนรับฟงขอมูล

มีประสบการณสูง

มีการตัดสินใจที่ดี

กลาตัดสินใจ

องคประกอบของทีมงานตรวจสอบ

มาจากสวนตางๆ ขององคกร

เปน Specialized เฉพาะสาขา เชน นักบัญชี วิศวกร

บางสวนมาจาก Project Team เพื่อ support ขอมูล (อาจมี/ไมมี ก็ได)

ขั้นตอนที่ 2 : Data Collection and Analysis 1.

ขอมูลจากมุมมองขององคกร

วัฒนธรรมองคกร สงเสริม/ไมสงเสริม การทํางานหรือไมอยางไร 2

การสนับสนุนจากผูบริหารระดับสูงมีเพียงพอหรือไม

โครงการบรรลุเปาหมายที่กําหนดไวหรือไม -

มีความเชื่อมโยงกับกลยุทธและวัตถุประสงคขององคกรหรือไม

-

ระบบการจัดลําดับความสําคัญสะทอนถึงความสําคัญที่มีตออนาคตขององคกรหรือไม

-

สภาพแวดลอม (ภายใน/ภายนอก) เปลี่ยนแปลงและมีผลตอความจําเปนที่ตองดําเนินโครงการ ใหแลวเสร็จหรือไม (กรณีที่โครงการยังอยูระหวางดําเนินการ)

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

รุนแรงจากที่คาดการณไวหรือไม

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

เมื่ อโครงการเสร็ จสิ้ นแลว บุ คลากรในโครงการได รับ การมอบหมายงานไปยัง โครงการใหม อย างยุติ ธรรม หรือไม

2.

ผลการประเมินจากผูรับเหมาจากภายนอกเปนอยางไร

โครงการเริ่มตนและสิ้นสุดดวยความสําเร็จหรือไม เพราะเหตุใด และลูกคามีความพึงพอใจหรือไม

ขอมูลจากมุมมองของโครงการ

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

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

การประสานงานกับ Stakeholders ของโครงการมีอยางเพียงพอและมีประสิทธิภาพหรือไม

ที ม งานโครงการสามารถเข า ถึ ง ทรั พ ยากรในองค ก ร เช น คน งบประมาณ กลุ ม ที่ ช ว ยสนั บ สนุ น อุ ป กรณ เครื่ อ งมื อ เครื่อ งใช หรื อ ไม

มี ค วามขัด แย ง ในเรื่ อ งการใช ท รั พ ยากรกั บ โครงการอื่ น ที่ กํ า ลั งดํ า เนิ น การอยู

หรือไม ทีมงานมีการจัดการดีหรือไม

การประเมินผลจากผูรับเหมาจากภายนอกเปนอยางไร

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

ขั้นตอนที่ 3 : Reporting เปนการรายงานบทเรียน/เนื้อหาที่จะใชปรับปรุงโครงการในอนาคต และใชเปนเครื่องมือฝกอบรม Project Manager ตอๆ ไป ถายเทความรู/ประสบการณจากคนรุนเกาไปยังคนรุนตอไป เนื้อหาทั่วไปของรายงานการตรวจสอบประกอบดวย

รายละเอี ย ดโครงการที่ ต รวจสอบ ภาพรวมของโครงการ (classification) เช น เป น โครงการอะไร ขนาด งบประมาณ ทีมงาน ระดับเทคโนโลยี กลยุทธและการสนับสนุน รวมทั้งสวนที่เกี่ยวโยงกับองคกร

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

ขอแนะนําในมุมมองของผูตรวจสอบ (Recommendations) การแกไขสิ่งที่บกพรอง ความสําเร็จและจุดดีที่ ควรจะทําตอไป ให credit กับคนที่ทําดี

บทเรียนตางๆ ที่ไดจากโครงการ (Lessons

learned) เพื่อถายเทประสบการณไปยังโครงการตอๆ ไป เปน

ขอเตือนใจ เปนกรณีศึกษาเพื่อการเรียนรูขององคกรตอไป และใชในการปรับปรุงโครงการตอๆ ไป

3

ภาคผนวก (Appendix) เปนขอมูลรายละเอียดสนับสนุน รายละเอียดการวิเคราะห แนบเฉพาะขอมูลที่จําเปน เทานั้น

สรุปรายงานบทเรียนที่สําคัญๆ (Summary booklet) เพื่อใชเปนเอกสารอางอิงตอไป

Project audits : The bigger pictures •

ในอนาคตจะมีความสําคัญมากขึ้น เพราะนอกจากจะตรวจสอบโครงการในปจจุบัน ไดรูขอบกพรองในปจจุบันแลว ยัง สามารถนําไปแกไขไดในอนาคต

•

ปจจุบันมีสมาคมตั้งขึ้นมาเพื่อกําหนดจรรยาบรรณของ Project manager เนื่องจากการทํา project มีผลกระทบหลาย ดาน เชน สิ่งแวดลอม

ในหนังสืออีกเลมหนึ่ง •

การตรวจสอบโครงการแบงไดเปน 2 กรณี คือ ดูวาเสร็จทันเวลาที่กําหนดหรือไม และการทํา quality audit โดย พิจารณาดานคุณภาพ วามีคุณคาตามที่กําหนดไวหรือไม

ผูตรวจสอบ •

บุคคลภายนอกที่มีความอิสระในการตรวจสอบ และใหขอเสนอแนะ (กลุมวิชาชีพที่ไดรับการฝกฝนมาโดยเฉพาะ๗

•

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

คุณสมบัติของผูตรวจสอบ 1.

มีความเชี่ยวชาญ ความรูดานการตรวจสอบ

2.

ไดรับการยอมรับจากกลุมวิชาชีพ

3.

มีความรูดานเทคนิคเกี่ยวกับการบริหารโครงการ : การเงิน บัญชี ผลกระทบตอสิ่งแวดลอม

4.

มีความสามารถในการวิเคราะห

5.

ตองมีความสามารถในการเขียนรายงาน ตามแบบที่ควรจะเปน

6.

มีความสามารถในการฟง (เนื่องจากตองฟง คุยกับคนใน project)

7.

มีประสบการณทั้งดาน line และ staff

8.

มีความสามารถในการปรับตัว

9.

มีความกระตือรือรนในการตรวจสอบ

เวลาที่ตรวจสอบ : •

ชวงใดชวงหนึ่งกอนที่โครงการยุติ

•

เมื่อปดโครงการ

ขั้นตอนการตรวจสอบ (เหมือนที่กลาวมาแลว) แตมีการแบงเปน 6 ขั้นตอน 1.

เริ่มตน วางแผน มีแนวคิดที่จะทําการตรวจสอบ

2.

กําหนดเปาหมายของการตรวจสอบวาจะทําเพื่ออะไร กําหนดเกณฑขั้นต่ําที่คาดหวังวาจะได

3.

รวบรวมขอมูลจากบัญชี และรายงานตางๆ

4.

วิเคราะหตัวเลขที่ได หาขอสรุป

5.

การเขียนรายงาน ใหขอเสนอแนะ (การรายงาน : ลายลักษณอักษร วาจา ผสมกัน)

6.

การยุติโครงการ (termination) สรุป : การตรวจสอบโครงการคืออะไร – ทําเมื่อไร - ใครทํา - กระบวนการทํา

4

การยุติโครงการ (Project Closure) •

เนื่ อ งจากโครงการมี จุ ด เริ่ ม ต น และสิ้ น สุ ด มั ก ป ด เมื่ อ โครงการประสบความสํ า เร็ จ (closure)

แต ก ารยุ ติ โ ครงการ

(termination) อาจเกิดเมื่อโครงการไมประสบความสําเร็จ เชน โครงการโฮปเวลล ซึ่งยุติดวยเหตุผลทางการเมือง สาเหตุของการยุติโครงการ 1.

Normal สาเหตุปกติ เนื่องจากโครงการสําเร็จลุลวงแลว

2.

Premature ถูกแรงกดดันใหปดกอนกําหนด เชน จากนโยบายการแขงขัน มีความจําเปนตองถูกเรงใหเสร็จเร็วขึ้น

ถูก

ตัดขั้นตอนบางอยางออก 3.

Perpetual เปนโครงการยืดเยื้อ ที่ปดไดเปนระยะ เชน โครงการที่ลูกคาตองการเพิ่มเรื่องนั้นเรื่องนี้ตอๆ ไป ไมรูจบ มาก เกินไปแลว

4.

Failed Project เชน ผลงานไมไดตาม Spec. ใชงบเกินแผนมาก Time, Cost, Performance ไมไดเปนไปตามกําหนด แตก็ไมใชความผิดของ Project Manager

5.

Changed

Priority

เชน เมื่อกอนสําคัญ แตขณะนี้หมดความสําคัญ มี Project

อื่นมาแทนที่

เนื่องจาก

สภาพแวดลอมเปลี่ยน นโยบายเปลี่ยน อุปสรรคขัดขวางความสําเร็จของโครงการ •

Planning (32%) ไดแก คําจํากัดความไมชัดเจน การติดสินใจผิดพลาด ขอมูลไมดี

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

•

Scheduling (12%) ไดแก ตารางเวลาแนนเกินไป ไมเปนไปตามตารางเวลา ไมมีการบริหารตารางเวลา

•

Organizing (11%) ไดแก ขาดความรับผิดชอบ ผูบริหารโครงการออนแอ การแทรกแซงของผูบริหารระดับสูง

•

Staffing

(12%) ไดแ ก บุ คลากรไม เ พีย งพอ ผู บ ริห ารโครงการไม มีค วามสามารถ การเปลี่ ยนผู บริ ห ารโครงการ

กระบวนการจัดสรรบุคลากรไมดี •

Directing (26%) ไดแก การประสานงานไมดี การสื่อสารไมดี ภาวะผูนําไมดี ไมมีความ ผูกพันกับโครงการ

•

Controlling (7%) ไดแก การติดตามไมดี การตรวจสอบไมดี ไมมีระบบควบคุม จะปดโครงการเมื่อใด ขอมูลที่ใชในการตัดสินใจคือ รายงานของ auditor

ไมตระหนักถึงปญหา หรือดูความลมเหลว ความขัดแยง การ

เปลี่ยนแปลงทางการเมืองการออกกฎหมายใหมที่ทําให project ไมสําเร็จ การตัดสินใจยุติโครงการ 1.

ขึ้นอยูกับ การจัดสรรทรัพยากร คาใชจาย สอดคลองกับกลยุทธหรือไม

2.

เนนองคกรเปนหลัก

3.

ไมยึดตัวบุคคล แตยึดกลุม/องคกร

4.

การประกาศยุติโครงการตองทําโดยผูบริหารระดับสูง

Project closure checklist Item number / task description / ตองการหรือไม / วันที่ตองการ / ผูรับผิดชอบ / ลําดับ / บันทึกหรือเอกสารอางอิง กระบวนการในการยุติโครงการ 1.

ตองเอาใจใสเปนพิเศษ เปน Project ซอน Project

2.

อาจมีทีมงานยุติโครงการ โดยเฉพาะสําหรับโครงการขนาดใหญ

3.

ความทาทายเริ่มลดนอยลง การยุติโครงการสวนใหญจะตามดวยงานเอกสารซึ่งคอนขาง นาเบื่อหนาย

5

4.

การยุติโครงการอาจเกิดปญหาโดยเฉพาะโครงการใหญๆ เชน อาจสูญเสีย Facilities ที่เคยได หรือไมมีตําแหนงลงใน องคกรหลัก

5.

ขั้นตอนในการยุติโครงการ

Close-out Plan การยุติโครงการเปนโครงการซอนโครงการ -

ตองมีงานอะไรบางที่ตองทําในการยุติโครงการ

-

ใครรับผิดชอบ

-

เวลา ตองยุติโครงการเมื่อไร

-

การสงมอบใหลูกคา

Staffing -

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

-

กรณีโครงการเล็กที่สําเร็จ อาจเปน Project Manager นั้นได

-

กรณีโครงการใหญ ผูยุติโครงการควรเปนบุคคลอื่น ไมควรเปน Project Manager

สื่อแผนใหบุคลากรรับทราบ -

แจงใหทราบลวงหนาเพื่อเตรียมโยกยายและเตรียมทําใจวาไมมีงานเลี้ยงใดไมเลิกรา

-

จูงใจอยางไรใหลูกทีมทํางานตอไปเพราะชวงยุติโครงการจะลดความทาทายลงแลว

-

Next assignment เตรียมแผนใหลูกทีมดวย

การปฏิบัติตามแผนยุติโครงการ -

แจงลูกคาทราบและยอมรับ

-

สงคืน / แจกจาย ทรัพยากร

-

มอบหมายงานใหมใหทีมโครงการ

-

บัญชีโครงการใหมีเอกสารครบถวน ชําระคาใชจายปดบัญชี

-

ประเมินผลทีมงาน (Team Evaluation) ¾

ประเมินเพื่อปรับปรุงงาน

¾

ตองกําหนด Criteria

¾

จุดออนในการประเมิน ไดแก อาจเปนการประเมินโดย Functional Manager เนน Time, Cost, Performance แตการประเมินกลับประเมินคน การประเมินตองพิจารณามุมมองอื่น ดวย เชน Team Building, Process ฯลฯ

-

¾

มีปจจัยอื่นนอกเหนือจาก Time, Cost, Performance หรือไม

¾

การประเมินใชวิธีการ Survey

¾

ใชคนภายนอก เชน Consultant, HR ฯลฯ

ประเมินผลรายบุคคล (Individual Team Member and Project Manager Evaluation) ¾

ระดับการประเมิน Project Manager ขึ้นอยูกับรูปแบบการจัดองคกร

¾

การประเมินผลแบบ 360 องศา (Multirater appraisal)

ปญหาที่พบตอนปดโครงการ 1.

ปญหาเกี่ยวกับจิตใจ ซึ่งกระทบ 1 ดาน คือ 1)

ตอพนักงานในทีม -

กังวลวาจะไดทํางานตอในทีมหรือไม

-

เกิดความทอถอยเบื่อหนายจากความไมแนนอน

-

เสียขวัญ และกําลังใจ 6

-

การทํางานเปนทีมและความเปนปกแผนลดลง

2) ตอลูกคา

2.

-

ทาทีของลูกคาเปลี่ยน ความสัมพันธอาจลดลงเพราะงานเสร็จแลว

-

ปฏิสัมพันธเปลี่ยน

ปญหาเกี่ยวกับทรัพยสิน 1) ปญหาภายใน -

ตองตัดสินใจวาใครบางที่จะเลิกจาง ใครที่จะจางตอ

-

ตองตัดสินใจวาทรัพยสินหรือสินคาคงคลังที่เหลืออยูจะจัดการอยางไร

2) ปญหาภายนอก -

สัญญา / ความรับผิดชอบ เมื่อเราสงมอบงานกับลูกคาแลว

-

วัสดุที่จัดซื้อ จัดหา ขอตกลงตางๆ มีหรือไม วาถาใชไมหมดคืนได

-

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

Team , Team member and project manager evaluations •

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

ที่ ยืมมาจากบริษัทแม เสร็จงานแลวก็คื น โดยอาจตองประเมิ นการขึ้ น

เงินเดือนใหดวย หรือดูวาใครมีคุณภาพ เมื่อจะเริ่มงานใหมจะไดดึงมาทํางานดวยอีก •

การประเมินแบบ 360o และตองติดประกาศใหทราบ

•

การประเมินจะดูที่ : ผลงาน และการทํางานรวมกับผูอื่น

•

อยากเก็บคนที่เราเคย train ไว เพื่อไมใหไปอยูกับคูแขงแลวหลายมาเปนคูแขงกับเราอีก

7

ประสบการณ “ความสําเร็จ และความลมเหลว ในการบริหารโครงการ” บรรยายโดย ผศ.พึงใจ พึ่งพานิช , 24 กุมภาพันธ 2548 การบริหารโครงการ ความหมาย ความจําเปน

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

ปจจัยที่สงผลใหเกิดความสําเร็จ 1. เปนความตองการเท็จจริงเปนพื้นฐาน • ตามการขยายตัวของประชากร – ของชาติ • การดอยโอกาสที่จะไดรับ ความขาดแคลน • เกิดเปนปญหาของสังคมขึ้นแลว • การแขงขันที่ทําใหเกิดความลาหลัง • เปนนโยบายของชาติ (คิดใหม ทําใหม) • ตามสนธิสัญญาที่มีตอประชากร สังคมโลก • ตัวอยางเชน โครงการ 30 บาทรักษาทุกโรค 2. การบงบอกถึงการที่ถาไมมีจะเกิดความเสียหายในอนาคต เปนการพยากรณที่มีตัวชี้วัดถึงความเสี่ยง อาทิ โครงการ นิวเคลียรในสงคราม โครงการพลังงานทดแทน (น้ํามันหมดโลก) โครงการปองกันไขหวัดนก โครงการขจัดน้ําเสียของชุมชน 3. เปนไปตามแผนยุทธศาสตรของผูบริหาร ที่เนนผูบริหารทุกระดับตั้งแตระดับโลก ระดับประเทศ ระดับกลุม ระดับทองถิ่น จะตองรับรูและหาทางแกไขใหผูอยูภายใตเงื่อนไข จึงจําเปนตองมีวิสัยทัศน มีแผนและยุทธ ศาสตร มีโครงการตาง ๆ เกิดขึ้น ตัวอยางเชน จังหวัดกลุมสนุก (สกลนคร นครพนม มุกดาหาร กาฬสินธุ) มี การกําหนดวาใหจังหวัดสกลนคร เปนศูนยรวมในการพัฒนาบุคลากร เนื่องจากมี มหาวิทยาลัยเกษตรศาสตร และสถาบันราชภัฏ ปจจัยที่สงผลใหเกิดความลมเหลว 1. ขาดการศึกษาความเปนไปไดอยางมีระบบ ความเปลี่ยนแปลงทางเศรษฐกิจและสังคมอยางรุนแรง 2. ขาดปจจัยสําคัญที่เปนหลักๆ เชน คน และเงินทุน ซึ่งโครงการใหญๆ จะตองมีรัฐบาลเปนผูค้ําประกันเงินกู 3. ขัดตอกฎหมาย ขัดตอระเบียบของสังคม เชน กฎหมายสิ่งแวดลอม ระบบมาตรฐาน ISO 4. ผูบริหารโครงการไมมีความสามารถเพียงพอ

7

ผูบริหารโครงการที่สามารถบริหารโครงการไดรับความสําเร็จ 2. ความรอบรู หาคนที่รูมาเปนทีม รูจริง 3. ความรอบคอบ คอยติดตาม เฝาระวัง ปองกัน 4. รูอดีต รูอนาคต โดยเฉพาะคน และเทคโนโลยี 5. รูสิ่งแวดลอม วิวัฒนาการความตองการ 6. รูการเปลี่ยนแปลงของสังคม 7. รูกฎหมาย สนธิสัญญา เงื่อนไข องคประกอบตองแนใจวา 1. ปจจัยที่สําคัญๆ ที่เปนองคประกอบของโครงการมีตามที่กําหนดอยางแนนอน 2. มีปจจัยที่เปนตัวชวยสนับสนุนรอใหการสนับสนุนเมื่อมีการรองขอ 3. มีการบริหารความเสี่ยงอยางมีระบบ 4. มีระยะเวลาการทํางานที่เปนไปได ปจจัยสําคัญๆ ที่เปนองคประกอบพื้นฐาน 1. มีองคกรที่เหมาะสม 2. มีทีมงานที่มีคุณภาพ 3. มีแผนการทํางานที่ประสาน 10 ทิศ 4. มีทรัพยากรที่ปองเขาสูโครงการแนนอน (รวมทั้งทุน) 5. มีผูตรวจสอบที่มีคุณภาพทุกขั้นตอนตั้งแตตนจนจบ

8