1. Project and Change Management ผู้สอน: พนม เพชรจตุพร อาจารย์ประจำภาควิชาวิศวกรรมระบบวัดคุม

2. ITEC 0521 : Project and Change Management • Text Book: • 1) Information Technology Project Management 3nd Ed. by Jack T. Marchewka, Wiley. • 2) A Guide To The Project Management Body Of Knowledge (PMBOK) by PMI Standards Committee., William R. Duncan. • Reference Book: • 1) Information Technology Project Management by Kathy Schwalbe, Thomson. • 2) Project and Program Risk Management; A Guide to Managing Project Risks and Opportunities by R. Max Wideman, Project Management Institute.

3. Score • Homework 20% • Midterm 30% • Examination 50% • Note: • It may be changed if anyone has a good suggestion.

4. Content of Text Book (1) • Chapter 1: ทบทวนเรื่องของการจัดการโครงการ IT • (An Overview of IT Project Management) • Chapter 2: กรณีศึกษาทางธุรกิจ • (Business Case) • Chapter 3: โปรเจค ชาร์เตอร์ • (Project Charter) • Chapter 4: กลุ่มดำเนินโครงการ • (Project Team) • Chapter 5: การวางแผนจัดการขอบเขตโครงการ • (The Scope Management Plan)

5. Content of Text Book (2) • Chapter 6: โครงสร้างของการแยกย่อยงาน • (The Work Breakdown Structure (WBS)) • Chapter 7: งบประมาณและแผนเวลาทำงานของโครงการ • (The Project’s Schedule and Budget) • Chapter 8: การวางแผนจัดการความเสี่ยงของโครงการ • (The RiskManagement Plan) • Chapter 9: การวางแผนสื่อสารภายในโครงการ • (The Project Communication Plan) • Chapter 10: การวางแผนคุณภาพของโครงการเกี่ยวกับ IT • (The IT Project Quality Plan)

6. Content of Text Book (3) • Chapter 11: การจัดการการเปลี่ยนแปลงขององค์กร การต่อต้าน และข้อขัดแย้ง • (Managing Change, Resistance, and Conflict) • Chapter 12: การบริหารการจัดซื้อในโครงการและการเอาต์ซอร์ส • (Managing Project Procurement and Outsourcing) • Chapter 13: ภาวะผู้นำและจรรยาบรรณของโครงการ • (Project Leadership and Ethics) • Chapter 14: การวางแผนการปฏิบัติงาน การปิดโครงการ • (The Implementation Plan and Project Closure) • Appendix: An Introduction to Function Point Analysis.

7. Information Technology Project Management by Jack T. Marchewka

8. Chapter 1: ทบทวนเรื่องของการจัดการโครงการ IT (An Overview of IT Project Management)

9. Chapter 1 Objectives • อธิบายถึงยุคที่เด่นๆของระบบสารสนเทศที่เรียกกันว่า ยุคการประมวลผลข้อมูลแบบอิเล็กทรอนิคส์ (electronic data processing (EDP) ยุคไมโคร ยุคโครงข่าย และยุคโลกาภิวัฒน์ และทำความเข้าใจถึงวิธีการจัดการกับโครงการด้าน IT ในยุคต่าง ๆ ข้างต้นได้อย่างไร • ทำความเข้าใจสภาวการณ์ปัจจุบันเกี่ยวกับการจัดการโครงการด้าน IT และการประสบความสำเร็จในการจัดการโครงการด้าน IT ยังคงมีความท้าทายต่อองค์กรต่าง ๆ อย่างไร • อธิบายถึงการใช้แนวทาง value-driven, socio-technical, project management และ knowledge management ที่สนับสนุน ITPM. • นิยามว่าโครงการ (project) คืออะไรและอธิบายถึงคุณลักษณะของโครงการ • กำหนดวินัยในการทำโครงการที่เรียกว่า การจัดการโครงการ (project management)

10. อธิบายบทบาทและผลกระทบของโครงการ IT ที่มีต่อองค์กร • บ่งชี้ความแตกต่างและความสนใจของผู้มีส่วนเกี่ยวข้องกับโครงการ (project stakeholder) • อธิบายแนวทางที่มักใช้กันในการพัฒนาระบบอย่างเป็นโครงสร้างและการพัฒนาระบบแบบทำซ้ำ ๆ (iterative systems development) • อธิบายวงรอบชีวิตของโครงการ (project life cycle (PLC)) วงรอบชีวิตในการพัฒนาระบบ ( systems development life cycle (SDLC)) และความสัมพันธ์ระหว่างกัน • อธิบายถึงการจัดการโครงการแบบสุดขั้ว (extreme project management) • บ่งชี้ Project Management Body of Knowledge (PMBOK®) ในส่วนที่แกนหลัก

11. Project Management Body of Knowledge (PMBok)

12. IntroductionIT and Modern Day Project Management 1940s 1950s 1960s 1970s 1980s 1990s 2000s 2010s First Electronic Computer EDP Era PC Era Network Era Globalization

13. Introduction • โครงการเกี่ยวกับ IT (Information Technology (IT) projects) ถือเป็นการลงทุนขององค์กรที่ต้องการ • เวลา (Time) • เงิน (Money) • และทรัพยากรอื่น ๆ เช่น ผู้คน เทคโนโลยี ส่วนสนับสนุน และอื่น ๆ • ดังนั้นองค์กรจึงคาดหวังว่ามันต้องมีคุณค่าบางสิ่งบางอย่างกลับคืนมาหลังจากการลงทุน • ดังนั้นการจัดการโครงการเกี่ยวกับ IT จะสัมพันธ์กับวินัยในการทำงานใหม่ ๆ อันนำมาใช้เพื่อทำให้โครงการเกี่ยวกับ IT ประสบความสำเร็จมากขึ้น โดยนำมาใช้ร่วมกับการจัดการกับโครงการแบบทั่ว ๆ ไปซึ่งอาศัย Software Engineering/Management Information Systems

14. An ITPM Approach เนื่องจากทรัพยากรขององค์กรมีจำกัด ดังนั้นองค์กรจึงต้องเลือกเอาระหว่างสิ่งที่องค์กรสนใจเทียบกับเงินทุนที่ต้องใช้ในโครงการต่าง ๆ การตัดสินใจจะตั้งอยู่บนคุณค่าของโครงการต่าง ๆ ที่มีให้กับองค์กร ที่เสนอขึ้นมาให้คัดเลือก สถานการณ์ใดแย่กว่ากัน การประสบความสำเร็จในการสร้างระบบขึ้นมาและนำมาใช้งาน แต่ให้คุณค่าแก่องค์กรเล็กน้อยหรือไม่มีเลย? หรือ… ล้มเหลวในการนำระบบสารสนเทศ(information system) มาใช้งาน ซึ่งระบบนี้ให้คุณค่าแก่องค์กรแต่กำลังพัฒนาอยู่ ยังไม่แล้วเสร็จ หรือ มีการจัดการที่แย่?

15. Advantages of Using Formal Project Management • สามารถควบคุม financial, physical, และ human resources ได้ดีขึ้น • ความสัมพันธ์กับลูกค้า ถูกปรับปรุงให้ดีขึ้น • เวลาที่ใช้พัฒนาลดน้อยลง • ต้นทุนต่ำลง • คุณภาพและความวางใจได้เพิ่มสูงขึ้น • ผลกำไรสูงขึ้น • ผลิตผลถูกปรับปรุงให้ดีขึ้น • การประสานงานภายในดีขึ้น • อารมณ์ร่วมในการ(อยาก)ทำงานสูงขึ้น

16. The State of IT Project Management • โดยการศึกษาของ Standish Group ผ่านทางการสำรวจผู้จัดการ IT 365 คนเมื่อปี 1994 การศึกษานี้เรียกว่า CHAOS แล้วได้ออกรายงานออกมาว่า • มีเพียง 16% ของโครงการพัฒนาโปรแกรมประยุกต์ที่ประสบความสำเร็จในเทอมที่ทันเวลาที่กำหนดและอยู่ในงบประมาณที่กำหนด • 31% ของโครงการถูกยกเลิกก่อนที่โครงการจะแล้วเสร็จ • 53% ของโครงการแล้วเสร็จก็จริง แต่เกินเวลาที่กำหนด เกินงบประมาณ และไม่บรรลุข้อกำหนดตามที่กำหนดไว้แต่แรก • จากการสำรวจยังพบว่าบริษัทขนาดกลางเมื่อทำโครงการแล้ว ได้ใช้งบประมาณเกินไปจากการคาดการณ์ในตอนต้นก่อนเริ่มโครงการ เฉลี่ยแล้วประมาณ 182% และใช้เวลาเกินที่กำหนดไว้เฉลี่ยแล้วประมาณ 202%

17. นั่นหมายความว่า โครงการขนาดกลางกำหนดไว้ก่อนทำโครงการว่าจะใช้เงินประมาณ 1 ล้านเหรียญ ใช้เวลาประมาณ 1 ปี แต่เมื่อโครงการเสร็จสิ้นแล้ว ใช้เงินไปประมาณ 1.8 ล้านเหรียญและใช้เวลาไปถึง 2 ปี • ทำไมโครงการเกี่ยวกับ IT ถึงล้มเหลว? • โครงการขนาดใหญ่มีอัตราการประสบความสำเร็จน้อยกว่าโครงการขนาดกลางและขนาดเล็ก และมีความเสี่ยงมากกว่า • การเปลี่ยนแปลงอย่างรวดเร็วของ เทคโนโลยีตัวแบบทางธุรกิจ (business models) และตลาดทำให้โครงการที่ใช้เวลานานกว่าหนึ่งปีถูกยกเลิกก่อนที่จะแล้วเสร็จ

18. ทำไมโครงงานถึงล้มเหลว? ในภาพกว้าง ๆ • ใช้งบประมาณเกินกำหนด (Cost Overruns) • เกินเวลาที่กำหนด (Schedule Overruns) • เพิ่มสิ่งสำคัญ ๆ เข้าไปหลังจากเริ่มโครงการ (Addition of features) • ลบสิ่งสำคัญ ๆ ออกเนื่องจากเกินงบและเกินเวลา (Deletion of features due to time and cost overruns) • โครงการถูกยกเลิกก่อนเสร็จสิ้นสมบูรณ์ (Project is cancelled before completion) • ผู้ใช้ไม่พึงพอใจและไม่ใช้งาน (User dissatisfaction and non use)

19. Figure 1.1 - Summary of the Chaos Studies from 1994 to 2006

20. Has the Current State of IT Projects Changed Since 1994? • Standish Group ได้ศึกษาโครงการ IT อย่างต่อเนื่องมาหลายปี พบว่า เมื่อกล่าวกว้าง ๆ จะเห็นว่าโครงการเกี่ยวกับ IT มีอัตราความสำเร็จสูงขึ้น อันเนื่องมาจาก • มีกระบวนการและเครื่องมือในการจัดการกับโครงการดีขึ้น • โครงการต่าง ๆ มีขนาดเล็กลง • การสื่อสารระหว่างผู้มีส่วนเกี่ยวข้องทั้งหลาย (stakeholder)ได้รับการปรับปรุง • ผู้จัดการโครงการเกี่ยวกับ IT มีทักษะและความชำนาญมากขึ้น • แต่อย่างไรก็ตาม มันยังมีโอกาสในการปรับปรุงให้ดีขึ้นอีกมาก

21. Table 1.1 Summary of CHAOS Study Factor Rankings for Successful Projects (Sources: Adapted from the Standish Group. CHAOS (West Yarmouth, MA: 1995) &http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS)

22. แล้วปี 2007 เป็นอย่างไร? • จากผลการศึกษาของ Tata Consultancy Services ได้สำรวจ 800 Senior IT Managers จาก U.K., USA, France, India, Japan และ Singapore พบคล้าย ๆ กันว่า • 62% ของโครงการเกี่ยวกับ IT ล้มเหลวเสร็จไม่ทันเวลาตามที่กำหนด • 49% ใช้งบประมาณเกินกำหนด (budget overrun) • 47% ใช้ต้นทุนในการบำรุงรักษาเกินที่กำหนดไว้ • 41% ล้มเหลวในเรื่องที่ต้องส่งมอบคุณค่าทางธุรกิจตามที่คาดหวังเอาไว้และผลตอบแทนในการลงทุน (Return on Investment, ROI) • จากผลการศึกษาของ Machewka ในเรื่อง “Project Performance and Internal/External Customer Satisfaction” เป็นดังตารางในหน้าถัดไป

23. Table 1.2: Project Performance and Internal/External Customer Satisfaction. Source: Marchewka, J.T. (2008). n = 114.

24. Why IT Projects Fail • เหตุผลหนึ่งที่ทำให้โครงการเกี่ยวกับ IT ล้มเหลวในอัตราที่สูง ก็คือ การนิยามการ “ประสบความสำเร็จ(Success)” หรือ “ล้มเหลว (Failure)” ตามนิยามของ CHAOS ได้นิยามว่า โครงการใด ๆ ก็ตาม แม้ว่าจะสร้างคุณค่าให้แก่องค์กรอย่างมากมาย แต่ถ้าเกินงบประมาณหรือเวลาที่กำหนด จะถือว่า “ล้มเหลว”ทั้งสิ้น • จากการศึกษาของ CHAOS ได้ผลออกมาน่าสนใจดังตารางในหน้าถัดไป มันเป็นการบอกถึงปัจจัยที่ท้าทายของโครงการอันก่อให้เกิดปัจจัยแห่งความล้มเหลว เช่น อินพุตจากผู้ใช้ไม่พอเพียง หรือ ขาดการมีส่วนร่วมของผู้ใช้ ทำให้ทีมที่ทำโครงการเสียเวลาในการทำความเข้าใจว่าผู้ใช้ต้องการอะไร เสียเวลาในการกำหนดความต้องการของโครงการ ท้ายที่สุดก็จะเกิดข้อขัดแย้งระหว่างผู้พัฒนาโปรแกรมและผู้ใช้ เป็นต้น

25. Table 1.3: Summary of Factor Rankings for Challenged and Failed (Impaired) Projects Source: Adapted from the Standish Group. CHAOS (West Yarmouth, MA: 1995)

26. จากการทำโพลผ่านทางเวบของ Computing Technology Industry Association (CompTIA) จากจำนวนผู้ตอบประมาณ 1,000 ราย มี • 28% กล่าวว่าการสื่อสารที่แย่เป็นสาเหตุที่ทำให้โครงการล้มเหลว • 18% กล่าวว่าทรัพยากรไม่พอเพียงก่อให้เกิดความล้มเหลว • 13.2% กล่าว่าการกำหนดเส้นตายที่ไม่เป็นไปตามความจริง ทำให้โครงการล้มเหลว • ในแง่ของการสื่อสาร ตารางในหน้าถัดไปได้แสดงปัจจัยที่เกี่ยวข้องกับความท้าทายและความล้มเหลวของโครงการในแง่ของการสื่อสารทั้งทางตรงและทางอ้อม

28. Improving the Likelihood of success • ใช้แนวทางขับเคลื่อนด้วยคุณค่า (A Value-Driven Approach) • Plain & Simple: IT Projects must provide value to the organization • แนวทางผสมผสานด้านเทคนิคและสังคมเข้าด้วยกัน (Socio-technical Approach) • It’s not just about the technology or building a better mouse trap • ใช้แนวทางการบริหารโครงการ (Project Management Approach) ผ่านทาง • กระบวนการต่าง ๆ และโครงสร้าง • ทรัพยากรต่าง ๆ • ความคาดหวัง • การแข่งขัน • ประสิทธิภาพและประสิทธิผล

29. ใช้แนวทางการบริหารองค์ความรู้ (Knowledge Management Approach) • บทเรียนจากอดีต (lesson learned) • การปฏิบัติงานที่เป็นเลิศ (best practices) และ • การแบ่งปันความรู้ (Knowledge Sharing)

30. Top IT Projects

31. The Context of Project Management • คำนิยามของ “โครงการ (Project)” • โครงการ (project) คือ การรวมตัวกันชั่วคราวเพื่อพยายามดำเนินการให้บรรลุเป้าประสงค์เรื่องใดเรื่องหนึ่งที่ชัดเจน • ดังนั้น การบริหารโครงการจึงหมายถึงการประยุกต์ใช้องค์ความรู้ ทักษะ เครื่องมือต่าง ๆ และ เทคนิคต่าง ๆกับการดำเนินโครงการเพื่อให้ได้ผลตาม ความต้องการหรือความคาดหวัง (หรือดีกว่า) จากโครงการหนึ่ง ๆ โดยผู้เกี่ยวข้องทั้งหลาย • ลองนึกซิครับว่า งาน (ที่เราทำกันอยู่ทุก ๆ วัน) จะเรียกว่า โครงการได้หรือไม่ ?!? ถ้าไม่ได้ แล้วโครงการจะต้องมีลักษณะ (attribute) อะไรที่แสดงให้เราเห็น เพื่อใช้แยกแยะความแตกต่างได้ (เราเรียกว่า Project Attribute)

32. การจัดการกับโครงการจะประกอบด้วย:การจัดการกับโครงการจะประกอบด้วย: • การบ่งชี้ถึงความต้องการต่าง ๆ • กำหนดเป้าประสงค์ที่สามารถบรรลุได้และชัดเจน • สมดุลความต้องการในแง่ของคุณภาพ ขอบเขต เวลา และงบประมาณ • ปรับข้อกำหนดเฉพาะ แผนการ และแนวทางต่าง ๆ ให้เข้ากับความต้องการและความคาดหวังที่แตกต่างกันของผู้มีส่วนเกี่ยวข้องกับโครงการที่มีหลากหลาย

33. The Context of Project Management ลักษณะของโครงการ (Project Attributes): • มีกรอบเวลา (Time Frame) • มีวัตถุประสงค์ (Purpose) เพื่อก่อให้เกิดคุณค่าต่อองค์กร • มีความเป็นเจ้าของ (Ownership) • มีทรัพยากร (Resources) (เป็นไปตามข้อจำกัดสามข้อ) • มีหน้าที่รับผิดชอบ (Roles) • ผู้จัดการโครงการ (Project Manager) • สปอนเซอร์ของโครงการ (Project Sponsor) • SME (Domain & Technical)

34. มีความเสี่ยงและสมมุติฐาน (Risks & Assumptions) • มีกิจกรรมที่อิสระจากกัน (Interdependent tasks) • เคลื่อนไปข้างหน้าอย่างรอบคอบ: มีหลายขั้นตอนแต่ก้าวไปที่ละขั้น • มีการวางแผนปรับเปลี่ยนองค์กร (Planned Organizational change) • ทำงานในสภาพแวดล้อมที่ใหญ่กว่าตัวโครงการเองในการทำงาน (Operate in Environments Larger than the Project Itself)

35. คุณลักษณะของโครงการ (Project Characteristics) • มีวัตถุประสงค์ที่เจาะจง ชัดเจน (ซึ่งอาจเป็นเรื่องเดียว (unique) หรือ ประเภทใดประเภทหนึ่ง ก็ได้)สามารถดำเนินการให้เสร็จสิ้นภายในข้อกำหนดที่ชัดเจนแน่นอน • มีการกำหนดวันเริ่มต้นและวันสิ้นสุด • มีการกำหนดวงเงินที่ต้องใช้จ่าย (ถ้าเป็นไปได้) • ใช้ทรัพยากรทั้งที่เป็นคนและไม่ใช่ (เช่น เงิน เครื่องจักร เทคโนโลยี) • เป็นแบบหลายฟังก์ชัน (multifunctional) (cut across several functional lines)

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

37. วัฒนธรรมในการบริหารก็ต่างกันวัฒนธรรมในการบริหารก็ต่างกัน

38. ข้อจำกัดสามข้อ (The Triple Constraint) • ทุก ๆ โครงงานจะถูกข้อจำกัดของตัวมันเข้ามาบีบ ได้แก่: • เป้าหมายเรื่องขอบเขต (Scope goals): อะไรคือสิ่งที่โครงงานต้องบรรลุ • เป้าหมายเรื่องเวลา (Time goals): ใช้เวลานานเท่าใดจึงจะสำเร็จ • เป้าหมายเรื่องงบประมาณ (Cost goals): ใช้ต้นทุนเท่าใด • มันจึงถือเป็นหน้าที่ของผู้บริหารโครงการต้องสมดุลระหว่างสามเรื่องนี้เพื่อให้บรรลุเป้าหมายที่ตั้งไว้

39. Figure 1.2 The Triple Constraint ขอบเขตบาน เวลาเกิน งบเกิน

40. Project Management คืออะไร? • Project management is “the application of knowledge, skills, tools, and techniques to project activities in order to meet project requirements” (PMI*, Project Management Body of Knowledge (PMBOK® Guide), 2000, p. 6) • การบริหารโครงการ คือ การประยุกต์ใช้ องค์ความรู้ ทักษะ เครื่องมือ และ เทคนิคต่าง ๆ กับกิจกรรมต่าง ๆ ในโครงการ เพื่อให้บรรลุถึงข้อกำหนดของโครงการ *The Project Management Institute (PMI) is an international professional society. Their web site is www.pmi.org.

41. แฟกเตอร์ที่เกี่ยวข้องกับวัฒนธรรม (The Culture Factor) • ความสัมพันธ์ที่ดีระหว่างการทำงานรายวัน (daily working) กับผู้บริหารโครงการ (project manager) และผู้บริหารแผนก (line managers) ผู้ซึ่งมีหน้าที่กำหนดทรัพยากรต่าง ๆ ลงไปในโครงงาน • ความสามารถของ functional employees ในการรายงานตามสายบังคับบัญชาไปยัง line manager ของเขา (ถือเป็นแนวตั้ง) และเขายังต้องรายงานไปยังผู้บริหารโครงการหนึ่งคนหรือมากกว่า (ถือเป็นแนวนอน) Functional Manager Project Manager 1 Project Manager 2

42. ทรัพยากรของโครงการ (Project Resources) • เงิน • คนงาน (Manpower) • เครื่องมือ • สิ่งอำนวยความสะดวก • วัตถุดิบ (Materials) • สารสนเทศ/เทคโนโลยี

43. อุปสรรคกีดขวางต่อโครงการ (Project Obstacles) • ความซับซ้อนของโครงการ (Project complexity) • ความต้องการพิเศษของลูกค้า และ การเปลี่ยนขอบเขตของโครงการ • การเปลี่ยนแปลงโครงสร้างขององค์กร • ความเสี่ยงของโครงการ (Project risks) • การเปลี่ยนแปลงของเทคโนโลยี (Changes in technology) • การวางแผนและการคำนวณราคาล่วงหน้า (Forward planning and pricing)

44. ผู้เกี่ยวข้องกับโครงการผู้เกี่ยวข้องกับโครงการ • ผู้เกี่ยวข้อง(มีส่วนได้ส่วนเสีย)กับโครงการ (Project Stakeholders) • ผู้บริหารโครงการ (Project Manager) • ผู้ให้การสนับสนุนหรือสปอนเซอร์ของโครงการ (Project Sponsor) • เรื่องที่เกี่ยวข้องกับผู้ชำนาญการ (Subject Matter Expert(s) (SME)) • ผู้ชำนาญด้านเทคนิค (Technical Expert(s) (TE))

45. ผู้มีส่วนได้ส่วนเสียกับโครงการ (Project Stakeholders) • ผู้มีส่วนได้ส่วนเสีย หรือ Stakeholders คือ ผู้ที่เข้าไปเกี่ยวข้องหรือได้รับผลกระทบจากการดำเนินโครงการ • ผู้มีส่วนได้ส่วนเสีย (Stakeholders) ประกอบด้วย • สปอนเซอร์ของโครงการ (Project sponsor) และทีมที่ทำโครงการ (Project team) • ฝ่ายสนับสนุน (support staff) • ลูกค้าต่าง ๆ (customers) • ผู้ใช้งาน (users) • ซัพพลายเออร์ (suppliers) • ผู้อยู่ตรงข้ามกับโครงการ (opponents to the project)

46. บทบาทของผู้บริหารโครงการ (Project Manager Roles) • จัดให้มีการประชุมครั้งแรก หรือKick off Meeting • จัดตั้งนโยบายของโครงงาน(project policies)และระเบียบปฏิบัติต่าง ๆ (procedures) • ออกแบบแผนในการดำเนินโครงการ(project plan)และผังการไหลของงานที่ต้องทำในโครงงาน (workflow) • ขอเงินทุนสนับสนุน (Obtaining funding) • ดำเนินการตามแผน (Executing the plan) • ทำตัวเหมือนผู้ประสานงานในโครงการ (project facilitator) • แก้ไขปัญหา (Putting out fires)

47. บทบาทของผู้บริหารโครงการ (Project Manager Roles) • จัดหาสมาชิกของกลุ่ม • ผลักดันให้กลุ่มมุ่งเน้นอยู่ที่เส้นตายต่าง (deadlines) • MBWA – Manage by walking around • ทำการประเมินประสิทธิภาพ (Evaluating performance) • พัฒนาแผนที่ใช้จัดการกับสถานการณ์ไม่แน่นอนที่อาจเกิดขึ้นได้ (Developing contingency plans) • การสรุปเรื่องต่าง ๆ ให้ project sponsor, customer และ team ฟัง • การปิดโครงการ

48. การบริหารแบบเดิมที่ต้องใช้ (Classical Management) • การวางแผน (Planning) • การจัด(กลุ่ม)คนทำงาน (Organizing) • การจัดหาบุคลากร (Staffing) • การสั่งการ (Directing) • การควบคุมให้เป็นไปตามแผน (Controlling) • เรามักเขียนย่อ ๆ ว่า POSDC • Which of the above is Usually NOT performed by the project manager?

49. ทักษะเฉพาะตนที่ควรมี

50. สปอนเซอร์ของโครงการ (The Project Sponsor) • เป็นหัวหน้าในการให้สนับสนุนโครงการ • Sponsor อาจอยู่/ไม่อยู่ในกลุ่มผู้บริหารระดับสูงก็ได้ • ฟังก์ชันของสปอนเซอร์คือสนับสนุนในเรื่องต่าง ๆ ที่เกี่ยวข้อง (run interference)