An Overview Of I Troject Panagement

3,648 views

Published on

1 Comment
0 Likes
Statistics
Notes
  • Be the first to like this

No Downloads
Views
Total views
3,648
On SlideShare
0
From Embeds
0
Number of Embeds
10
Actions
Shares
0
Downloads
116
Comments
1
Likes
0
Embeds 0
No embeds

No notes for slide

An Overview Of I Troject Panagement

  1. 1. PROJECT AND CHANGE MANAGEMENT 1
  2. 2. INFORMATION TECHNOLOGY PROJECT MANAGEMENT by Jack T. Marchewka 2
  3. 3. CHAPTER 1: ทบทวนเรื่องของการจัดการโครงการ IT (An Overview of IT Project Management) 3
  4. 4. CHAPTER 1 OBJECTIVES  อธิบายถึงยุคที่เด่นๆของระบบสารสนเทศที่เรียกกันว่า ยุคการประมวลผลข้อมูล แบบอิเล็กทรอนิคส์ (electronic data processing (EDP) ยุคไม โคร ยุคโครงข่าย และยุคโลกาภิวัฒน์ และทาความเข้าใจถึงวิธีการจัดการกับ โครงการด้าน IT ในยุคต่าง ๆ ข้างต้นได้อย่างไร  ทาความเข้าใจสภาวการณ์ปัจจุบันเกี่ยวกับการจัดการโครงการด้าน IT และการ ประสบความสาเร็จในการจัดการโครงการด้าน IT ยังคงมีความท้าทายต่อองค์กร ต่าง ๆ อย่างไร  อธิบายถึงการใช้แนวทาง value-driven, socio-technical, project management และ knowledge management ที่สนับสนุน ITPM.  นิยามว่าโครงการ (project) คืออะไรและอธิบายถึงคุณลักษณะของโครงการ  กาหนดวินัยในการทาโครงการที่เรียกว่า การจัดการโครงการ (project management)
  5. 5.  อธิบายบทบาทและผลกระทบของโครงการ IT ที่มีต่อองค์กร  บ่งชี้ความแตกต่างและความสนใจของผู้มีส่วนเกี่ยวข้องกับโครงการ (project stakeholder)  อธิบายแนวทางที่มักใช้กันในการพัฒนาระบบอย่างเป็นโครงสร้างและการ พัฒนาระบบแบบทาซ้า ๆ (iterative systems development)  อธิบายวงรอบชีวิตของโครงการ (project life cycle (PLC)) วงรอบชีวิตในการพัฒนาระบบ ( systems development life cycle (SDLC)) และความสัมพันธ์ระหว่างกัน  อธิบายถึงการจัดการโครงการแบบสุดขั้ว (extreme project management)  บ่งชี้ Project Management Body of Knowledge (PMBOK®) ในส่วนที่แกนหลัก
  6. 6. PROJECT MANAGEMENT BODY OF KNOWLEDGE (PMBOK)
  7. 7. INTRODUCTION IT AND MODERN DAY PROJECT MANAGEMENT 1940s 1950s 1960s 1970s 1980s 1990s 2000s 2010s First EDP PC Network Globalization Electronic Era Era Era Computer
  8. 8. INTRODUCTION  โครงการเกียวกับ IT ่ (Information Technology (IT) projects) ถือเป็นการลงทุนขององค์กรที่ต้องการ  เวลา (Time)  เงิน (Money)  และทรัพยากรอื่น ๆ เช่น ผู้คน เทคโนโลยี ส่วนสนับสนุน และอื่น ๆ  ดังนั้นองค์กรจึงคาดหวังว่ามันต้องมีคุณค่าบางสิ่งบางอย่างกลับคืนมาหลังจาก การลงทุน  ดังนั้นการจัดการโครงการเกี่ยวกับ IT จะสัมพันธ์กับวินยในการทางานใหม่ ๆ ั อันนามาใช้เพื่อทาให้โครงการเกี่ยวกับ IT ประสบความสาเร็จมากขึ้น โดย นามาใช้รวมกับการจัดการกับโครงการแบบทั่ว ๆ ไปซึ่งอาศัย Software ่ Engineering/ Management Information Systems
  9. 9. AN ITPM APPROACH  เนื่องจากทรัพยากรขององค์กรมีจากัด ดังนั้นองค์กรจึงต้องเลือกเอา ระหว่างสิ่งที่องค์กรสนใจเทียบกับเงินทุนที่ต้องใช้ในโครงการต่าง ๆ  การตัดสินใจจะตั้งอยู่บนคุณค่าของโครงการต่าง ๆ ที่มีให้กับองค์กร ที่ เสนอขึ้นมาให้คัดเลือก  สถานการณ์ใดแย่กว่ากัน  การประสบความสาเร็จในการสร้างระบบขึ้นมาและนามาใช้งาน แต่ให้คุณค่าแก่องค์กร เล็กน้อยหรือไม่มีเลย? หรือ…  ล้มเหลวในการนาระบบสารสนเทศ (information system) มาใช้งาน ซึ่งระบบ นี้ให้คุณค่าแก่องค์กรแต่กาลังพัฒนาอยู่ ยังไม่แล้วเสร็จ หรือ มีการจัดการทีแย่? ่
  10. 10. ADVANTAGES OF USING FORMAL PROJECT MANAGEMENT  สามารถควบคุม financial, physical, และ human resources ได้ดีขึ้น  ความสัมพันธ์กับลูกค้า ถูกปรับปรุงให้ดีขึ้น  เวลาที่ใช้พัฒนาลดน้อยลง  ต้นทุนต่าลง  คุณภาพและความวางใจได้เพิมสูงขึ้น ่  ผลกาไรสูงขึ้น  ผลิตผลถูกปรับปรุงให้ดีขึ้น  การประสานงานภายในดีขึ้น  อารมณ์ร่วมในการ(อยาก)ทางานสูงขึ้น
  11. 11. THE STATE OF IT PROJECT MANAGEMENT  โดยการศึกษาของ Standish Group ผ่านทางการสารวจผู้จัดการ IT 365 คนเมื่อปี 1994 การศึกษานี้เรียกว่า CHAOS แล้วได้ออกรายงาน ออกมาว่า  มีเพียง 16% ของโครงการพัฒนาโปรแกรมประยุกต์ที่ประสบความสาเร็จใน เทอมที่ทันเวลาที่กาหนดและอยู่ในงบประมาณที่กาหนด  31% ของโครงการถูกยกเลิกก่อนที่โครงการจะแล้วเสร็จ  53% ของโครงการแล้วเสร็จก็จริง แต่เกินเวลาที่กาหนด เกินงบประมาณ และ ไม่บรรลุข้อกาหนดตามที่กาหนดไว้แต่แรก  จากการสารวจยังพบว่าบริษัทขนาดกลางเมื่อทาโครงการแล้ว ได้ใช้งบประมาณ เกินไปจากการคาดการณ์ในตอนต้นก่อนเริ่มโครงการ เฉลี่ยแล้วประมาณ 182% และใช้เวลาเกินที่กาหนดไว้เฉลี่ยแล้วประมาณ 202%
  12. 12.  นั่นหมายความว่า โครงการขนาดกลางกาหนดไว้ก่อนทาโครงการว่าจะใช้ เงินประมาณ 1 ล้านเหรียญ ใช้เวลาประมาณ 1 ปี แต่เมื่อโครงการเสร็จ สิ้นแล้ว ใช้เงินไปประมาณ 1.8 ล้านเหรียญและใช้เวลาไปถึง 2 ปี  ทาไมโครงการเกี่ยวกับ IT ถึงล้มเหลว?  โครงการขนาดใหญ่มีอัตราการประสบความสาเร็จน้อยกว่าโครงการขนาด กลางและขนาดเล็ก และมีความเสี่ยงมากกว่า  การเปลี่ยนแปลงอย่างรวดเร็วของ เทคโนโลยี ตัวแบบทางธุรกิจ (business models) และตลาด ทาให้โครงการที่ใช้เวลานานกว่าหนึ่งปีถูกยกเลิกก่อนที่ จะแล้วเสร็จ
  13. 13. ทาไมโครงงานถึงล้มเหลว? ในภาพกว้าง ๆ  ใช้งบประมาณเกินกาหนด (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)
  14. 14. FIGURE 1.1 - SUMMARY OF THE CHAOS STUDIES FROM 1994 TO 2006
  15. 15. HAS THE CURRENT STATE OF IT PROJECTS CHANGED SINCE 1994?  Standish Group ได้ศึกษาโครงการ IT อย่างต่อเนื่องมาหลายปี พบว่า เมื่อกล่าวกว้าง ๆ จะเห็นว่าโครงการเกี่ยวกับ IT มีอัตรา ความสาเร็จสูงขึ้น อันเนื่องมาจาก  มีกระบวนการและเครื่องมือในการจัดการกับโครงการดีขึ้น  โครงการต่าง ๆ มีขนาดเล็กลง  การสื่อสารระหว่างผู้มีส่วนเกี่ยวข้องทั้งหลาย (stakeholder) ได้รับการ ปรับปรุง  ผู้จัดการโครงการเกี่ยวกับ IT มีทักษะและความชานาญมากขึ้น  แต่อย่างไรก็ตาม มันยังมีโอกาสในการปรับปรุงให้ดีขึ้นอีกมาก
  16. 16. 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) Rank 1994 2001 2006 1 User Involvement Executive Support User Involvement 2 Executive Management User Involvement Executive Management Support Support 3 Clear Statement of Experienced Project Manager Clear Business Objectives Requirements 4 Proper Planning Clear Business Objectives Optimizing Scope 5 Realistic Expectations Minimized Scope Agile Process 6 Smaller Project Milestones Standard Software Project Management Infrastructure Expertise 7 Competent Staff Firm Basic Requirements Financial Management 8 Ownership Formal Methodology Skilled Resources 9 Clear Vision & Objectives Reliable Estimates Formal Methodology 10 Hard-working, focused team Other Standard Tools and Infrastructure
  17. 17. แล้วปี 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” เป็นดังตารางในหน้าถัดไป
  18. 18. Table 1.2: Project Performance and Internal/External Customer Satisfaction. Source: Marchewka, J.T. (2008). n = 114. Much Much Worse Worse Same Better Better Ability to meet project 0.0% 12.3% 40.4% 41.2% 6.1% schedules Ability to meet IT Project project 1.8% 10.5% 44.7% 37.7% 5.3% Performance budgets Over the Past 3 Years Ability to complete project scope 2.6% 7.0% 41.2% 41.2% 7.9% or system requirements Overall satisfaction of 1.8% 13.2% 34.2% 39.5% 11.4% Customer the customer satisfaction over the past 3 years Perceived (Customers value of the can be internal delivered 0.0% 9.6% 39.5% 38.6% 12.3% – e.g., HR product to the department or customer external – e.g., a particular client) Potential for future work 0.9% 3.5% 42.1% 38.6% 14.9% with the customer
  19. 19. WHY IT PROJECTS FAIL  เหตุผลหนึ่งที่ทาให้โครงการเกียวกับ IT ล้มเหลวในอัตราทีสูง ก็คือ การนิยาม ่ ่ การ “ประสบความสาเร็จ (Success)” หรือ “ล้มเหลว (Failure)” ตามนิยามของ CHAOS ได้นิยามว่า โครงการใด ๆ ก็ตาม แม้ว่าจะสร้าง คุณค่าให้แก่องค์กรอย่างมากมาย แต่ถ้าเกินงบประมาณหรือเวลาที่กาหนด จะ ถือว่า “ล้มเหลว”ทั้งสิ้น  จากการศึกษาของ CHAOS ได้ผลออกมาน่าสนใจดังตารางในหน้าถัดไป มันเป็นการบอกถึงปัจจัยที่ท้าทายของโครงการอันก่อให้เกิดปัจจัยแห่งความ ล้มเหลว เช่น อินพุตจากผู้ใช้ไม่พอเพียง หรือ ขาดการมีส่วนร่วมของผู้ใช้ ทา ให้ทีมที่ทาโครงการเสียเวลาในการทาความเข้าใจว่าผู้ใช้ต้องการอะไร เสียเวลาในการกาหนดความต้องการของโครงการ ท้ายที่สุดก็จะเกิดข้อขัดแย้ง ระหว่างผู้พัฒนาโปรแกรมและผู้ใช้ เป็นต้น
  20. 20. Table 1.3: Summary of Factor Rankings for Challenged and Failed (Impaired) Projects Source: Adapted from the Standish Group. CHAOS (West Yarmouth, MA: 1995) Rank Factors for Challenged Projects Factors for Failed (Impaired) Projects 1 Lack of user input Incomplete requirements 2 Incomplete requirements Lack of user involvement 3 Changing requirements & specifications Lack of resources 4 Lack of executive support Unrealistic expectations 5 Technology incompetence Lack of executive support 6 Lack of resources Changing requirements & specifications 7 Unrealistic expectations Lack of planning 8 Unclear objectives Didn’t need it any longer 9 Unrealistic time frames Lack of IT management 10 New technology Technology illiteracy
  21. 21.  จากการทาโพลผ่านทางเวบของ Computing Technology Industry Association (CompTIA) จากจานวนผู้ตอบ ประมาณ 1,000 ราย มี  28% กล่าวว่าการสื่อสารที่แย่เป็นสาเหตุที่ทาให้โครงการล้มเหลว  18% กล่าวว่าทรัพยากรไม่พอเพียงก่อให้เกิดความล้มเหลว  13.2% กล่าว่าการกาหนดเส้นตายที่ไม่เป็นไปตามความจริง ทาให้ โครงการล้มเหลว  ในแง่ของการสื่อสาร ตารางในหน้าถัดไปได้แสดงปัจจัยที่เกี่ยวข้องกับความ ท้าทายและความล้มเหลวของโครงการในแง่ของการสื่อสารทั้งทางตรงและ ทางอ้อม
  22. 22. Figure 1.2 - When IT projects have gone wrong, what has been the reaction from the business managers and the Board of Directors? Don't know 1% None 2% Looked for a scapegoat among IT staff 9% Sought compensation from IT vendors 13% Reluctant to fund new IT projects 19% Reduced IT budgets 21% Tend to accept problems as the norm (i.e., a 43% necessary evil) Continued to provide support to improve IT 69%
  23. 23. 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) ผ่านทาง  กระบวนการต่าง ๆ และโครงสร้าง  ทรัพยากรต่าง ๆ  ความคาดหวัง  การแข่งขัน  ประสิทธิภาพและประสิทธิผล
  24. 24.  ใช้แนวทางการบริหารองค์ความรู้ (Knowledge Management Approach)  บทเรียนจากอดีต (lesson learned)  การปฏิบัติงานที่เป็นเลิศ (best practices) และ  การแบ่งปันความรู้ (Knowledge Sharing)
  25. 25. TOP IT PROJECTS
  26. 26. THE CONTEXT OF PROJECT MANAGEMENT  คานิยามของ “โครงการ (Project)”  โครงการ (project) คือ การรวมตัวกันชั่วคราวเพื่อพยายามดาเนินการให้บรรลุ เป้าประสงค์เรื่องใดเรื่องหนึ่งที่ชัดเจน  ดังนั้น การบริหารโครงการจึงหมายถึง การประยุกต์ใช้องค์ความรู้ ทักษะ เครื่องมือ ต่าง ๆ และ เทคนิคต่าง ๆ กับการดาเนินโครงการ เพื่อให้ได้ผลตาม ความต้องการ หรือความคาดหวัง (หรือดีกว่า) จากโครงการหนึ่ง ๆ โดยผู้เกี่ยวข้องทั้งหลาย  ลองนึกซิครับว่า งาน (ที่เราทากันอยู่ทุก ๆ วัน) จะเรียกว่า โครงการได้หรือไม่ ?!? ถ้าไม่ได้ แล้วโครงการจะต้องมีลักษณะ (attribute) อะไรที่แสดงให้เราเห็น เพื่อใช้แยกแยะความแตกต่างได้ (เราเรียกว่า Project Attribute)
  27. 27.  การจัดการกับโครงการจะประกอบด้วย:  การบ่งชี้ถึงความต้องการต่าง ๆ  กาหนดเป้าประสงค์ที่สามารถบรรลุได้และชัดเจน  สมดุลความต้องการในแง่ของคุณภาพ ขอบเขต เวลา และงบประมาณ  ปรับข้อกาหนดเฉพาะ แผนการ และแนวทางต่าง ๆ ให้เข้ากับความ ต้องการและความคาดหวังที่แตกต่างกันของผู้มีส่วนเกี่ยวข้องกับ โครงการที่มีหลากหลาย
  28. 28. THE CONTEXT OF PROJECT MANAGEMENT ลักษณะของโครงการ (Project Attributes):  มีกรอบเวลา (Time Frame)  มีวัตถุประสงค์ (Purpose) เพื่อก่อให้เกิดคุณค่าต่อองค์กร  มีความเป็นเจ้าของ (Ownership)  มีทรัพยากร (Resources) (เป็นไปตามข้อจากัดสามข้อ)  มีหน้าที่รับผิดชอบ (Roles)  ผู้จัดการโครงการ (Project Manager)  สปอนเซอร์ของโครงการ (Project Sponsor)  SME (Domain & Technical)
  29. 29.  มีความเสี่ยงและสมมุติฐาน (Risks & Assumptions)  มีกิจกรรมที่อิสระจากกัน (Interdependent tasks)  เคลื่อนไปข้างหน้าอย่างรอบคอบ: มีหลายขั้นตอนแต่ก้าวไปที่ละขั้น  มีการวางแผนปรับเปลี่ยนองค์กร (Planned Organizational change)  ทางานในสภาพแวดล้อมที่ใหญ่กว่าตัวโครงการเองในการทางาน (Operate in Environments Larger than the Project Itself)
  30. 30. คุณลักษณะของโครงการ (PROJECT CHARACTERISTICS)  มีวัตถุประสงค์ที่เจาะจง ชัดเจน (ซึ่งอาจเป็นเรื่องเดียว (unique) หรือ ประเภทใดประเภทหนึ่ง ก็ได้) สามารถดาเนินการให้เสร็จสิ้นภายใน ข้อกาหนดที่ชดเจนแน่นอน ั  มีการกาหนดวันเริ่มต้นและวันสิ้นสุด  มีการกาหนดวงเงินที่ต้องใช้จ่าย (ถ้าเป็นไปได้)  ใช้ทรัพยากรทังที่เป็นคนและไม่ใช่ (เช่น เงิน เครื่องจักร เทคโนโลยี) ้  เป็นแบบหลายฟังก์ชัน (multifunctional) (cut across several functional lines)
  31. 31. ความแตกต่างระหว่างการบริหารโครงการกับการบริหารทั่วไป  การบริหารโครงการ  การบริหารทั่วไป  มีลักษณะพิเศษ ไม่ซ้ากับโครงการอื่นใด  มีลักษณะซ้า ๆ กันเป็นกิจวัตร  มีระยะเวลาที่แน่นอน  มีระยะเวลาไม่สิ้นสุด  เกี่ยวข้องกับการเปลี่ยนแปลงขนาดใหญ่  เกี่ยวข้องกับการเปลี่ยนแปลงแบบค่อย ๆ ไป  สภาพการดาเนินงานไม่คงที่สม่าเสมอ  สภาพการทางานมีลักษณะคงที่ สม่าเสมอ  ให้น้าหนักแก่วัตถุประสงค์ไม่เท่ากัน เพื่อ  ให้น้าหนักแก่วัตถุประสงค์เท่ากัน เพือรักษา ่ ก่อให้เกิดการเปลี่ยนแปลงไปจากสภาพเดิม สภาพเดิม  สร้างกลุ่มทีมงานชั่วคราวขึ้นมาดาเนินการ  สร้างกลุ่มทีมงานถาวรขึ้นมาดาเนินการ
  32. 32. วัฒนธรรมในการบริหารก็ต่างกัน
  33. 33. ข้อจากัดสามข้อ (THE TRIPLE CONSTRAINT)  ทุก ๆ โครงงานจะถูกข้อจากัดของตัวมันเข้ามาบีบ ได้แก่:  เป้าหมายเรื่องขอบเขต (Scope goals): อะไรคือสิ่งที่โครงงานต้อง บรรลุ  เป้าหมายเรื่องเวลา (Time goals): ใช้เวลานานเท่าใดจึงจะสาเร็จ  เป้าหมายเรื่องงบประมาณ (Cost goals): ใช้ต้นทุนเท่าใด  มันจึงถือเป็นหน้าที่ของผู้บริหารโครงการต้องสมดุลระหว่างสามเรื่องนี้ เพื่อให้บรรลุเป้าหมายที่ตั้งไว้
  34. 34. THE TRIPLE CONSTRAINT ขอบเขตบาน เวลาเกิน Figure 1.2 งบเกิน
  35. 35. 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.
  36. 36. แฟกเตอร์ที่เกียวข้องกับวัฒนธรรม (THE CULTURE FACTOR) ่  ความสัมพันธ์ที่ดีระหว่างการทางานรายวัน (daily working) กับ ผู้บริหารโครงการ (project manager) และ ผู้บริหารแผนก (line managers) ผู้ซึ่งมีหน้าที่กาหนดทรัพยากรต่าง ๆ ลงไปใน โครงงาน  ความสามารถของ functional employees ในการรายงานตาม สายบังคับบัญชาไปยัง line manager ของเขา (ถือเป็นแนวตั้ง) และ Functional Manager เขายังต้องรายงานไปยังผู้บริหารโครงการหนึ่งคนหรือมากกว่า (ถือเป็น แนวนอน) Project Manager 1 Project Manager 2
  37. 37. ทรัพยากรของโครงการ (PROJECT RESOURCES)  เงิน  คนงาน (Manpower)  เครื่องมือ  สิ่งอานวยความสะดวก  วัตถุดิบ (Materials)  สารสนเทศ/เทคโนโลยี
  38. 38. อุปสรรคกีดขวางต่อโครงการ (PROJECT OBSTACLES)  ความซับซ้อนของโครงการ (Project complexity)  ความต้องการพิเศษของลูกค้า และ การเปลียนขอบเขตของโครงการ ่  การเปลี่ยนแปลงโครงสร้างขององค์กร  ความเสี่ยงของโครงการ (Project risks)  การเปลี่ยนแปลงของเทคโนโลยี (Changes in technology)  การวางแผนและการคานวณราคาล่วงหน้า (Forward planning and pricing)
  39. 39. ผู้เกี่ยวข้องกับโครงการ  ผู้เกี่ยวข้อง(มีส่วนได้ส่วนเสีย)กับโครงการ (Project Stakeholders)  ผู้บริหารโครงการ (Project Manager)  ผู้ให้การสนับสนุนหรือสปอนเซอร์ของโครงการ (Project Sponsor)  เรื่องที่เกี่ยวข้องกับผู้ชานาญการ (Subject Matter Expert(s) (SME))  ผู้ชานาญด้านเทคนิค (Technical Expert(s) (TE))
  40. 40. ผู้มีส่วนได้ส่วนเสียกับโครงการ (PROJECT STAKEHOLDERS)  ผู้มีส่วนได้ส่วนเสีย หรือ Stakeholders คือ ผู้ที่เข้าไปเกียวข้อง ่ หรือได้รับผลกระทบจากการดาเนินโครงการ  ผู้มีส่วนได้ส่วนเสีย (Stakeholders) ประกอบด้วย  สปอนเซอร์ของโครงการ (Project sponsor) และ ทีมที่ทาโครงการ (Project team)  ฝ่ายสนับสนุน (support staff)  ลูกค้าต่าง ๆ (customers)  ผู้ใช้งาน (users)  ซัพพลายเออร์ (suppliers)  ผู้อยู่ตรงข้ามกับโครงการ (opponents to the project)
  41. 41. บทบาทของผู้บริหารโครงการ (PROJECT MANAGER ROLES)  จัดให้มีการประชุมครั้งแรก หรือ Kick off Meeting  จัดตั้งนโยบายของโครงงาน (project policies) และ ระเบียบปฏิบัติ ต่าง ๆ (procedures)  ออกแบบแผนในการดาเนินโครงการ (project plan) และ ผังการ ไหลของงานที่ต้องทาในโครงงาน (workflow)  ขอเงินทุนสนับสนุน (Obtaining funding)  ดาเนินการตามแผน (Executing the plan)  ทาตัวเหมือนผู้ประสานงานในโครงการ (project facilitator)  แก้ไขปัญหา (Putting out fires)
  42. 42. บทบาทของผู้บริหารโครงการ (PROJECT MANAGER ROLES)  จัดหาสมาชิกของกลุ่ม  ผลักดันให้กลุ่มมุ่งเน้นอยู่ที่เส้นตายต่าง (deadlines)  MBWA – Manage by walking around  ทาการประเมินประสิทธิภาพ (Evaluating performance)  พัฒนาแผนที่ใช้จัดการกับสถานการณ์ไม่แน่นอนที่อาจเกิดขึ้นได้ (Developing contingency plans)  การสรุปเรื่องต่าง ๆ ให้ project sponsor, customer และ team ฟัง  การปิดโครงการ
  43. 43. การบริหารแบบเดิมที่ต้องใช้ (CLASSICAL MANAGEMENT)  การวางแผน (Planning)  การจัด(กลุ่ม)คนทางาน (Organizing)  การจัดหาบุคลากร (Staffing)  การสั่งการ (Directing)  การควบคุมให้เป็นไปตามแผน (Controlling)  เรามักเขียนย่อ ๆ ว่า POSDC  Which of the above is Usually NOT performed by the project manager?
  44. 44. ทักษะเฉพาะตนที่ควรมี
  45. 45. สปอนเซอร์ของโครงการ (THE PROJECT SPONSOR)  เป็นหัวหน้าในการให้สนับสนุนโครงการ  Sponsor อาจอยู่/ไม่อยู่ในกลุ่มผู้บริหาร ระดับสูงก็ได้  ฟังก์ชันของสปอนเซอร์คือสนับสนุนในเรื่อง ต่าง ๆ ที่เกี่ยวข้อง (run interference)
  46. 46. ผู้ชานาญการ (THE EXPERTS)  ผู้ชานาญที่เกี่ยวข้องกับเรื่องสาคัญ ๆ ที่เกี่ยวข้องกับโครงงาน (Subject Matter Expert(s) (SME))  ผู้ชานาญด้านเทคนิค (Technical Expert(s) (TE))  โดยทั่วไปแล้ว ทั้งสองส่วนนี้อาจได้มาจากแผนกหรือพื้นที่ต่าง ๆ ในองค์กร ซึ่งทางานอยู่ภายใต้ functional manager และจะกลายเป็นสมาชิก ของกลุ่มที่รับผิดชอบในการทาโครงการภายใต้การดูแลของผู้บริหาร โครงการจนกระทั่งโครงการแล้วเสร็จ
  47. 47. บทบาทของผู้บริหารเชิงฟังก์ชัน (ROLE OF FUNCTIONAL MANAGERS)  Functional manager มีหน้าที่กาหนดว่างาน (task) จะให้ให้แล้ว เสร็จได้อย่างไร (คือ เป็นการมองในเชิง technical criteria…..How …not What)  Functional manager มีหน้าที่จัดหาทรัพยากรให้พอเพียงเพื่อบรรลุถึง วัตถุประสงค์และภายใต้ข้อจากัดของโครงการ (project’s constraint เช่น เวลา งบประมาณ เป็นต้น) (เช่น ใครควรทางานให้สาเร็จ)  ยกตัวอย่าง เช่น นาย A เป็น Proj. Mgr. เพื่อทาโครงการ supply chain เนื่องจากต้องมี IT เข้าเกี่ยวข้อง จึงร้องขอมาทาง นาย B ซึ่งเป็น IT Mgr. (นาย B จะเป็น Functional Manager) นาย B ต้องพิจารณาก่อนว่า โดยทาง เทคนิคของ IT แล้ว SC จะต้องทาอย่างไร (How) เมื่อเข้าใจแล้ว จึงกาหนดว่า นาย C (ซึ่งอยู่ในแผนก IT) ควรทางานนี้ ต่อไปนาย C ต้องเป็นสมาชิกของกลุ่ม ที่ทาโครงการนี้ และ ต้องรายงานทั้งนาย A (ซึ่งเป็น Proj. Mgr.) และ นาย B (ซึ่งเป็น Functional Mgr.)
  48. 48. อุปสรรคกีดขวางเชิงฟังก์ชัน (FUNCTIONAL OBSTACLES)  การร้องขอให้ทางานอย่างไม่มีขีดจากัด (Unlimited work requests)  มีเส้นตาย (deadline) ที่กาหนดไว้ก่อนแล้ว (Predetermined deadlines)  การร้องขอทั้งหมดล้วนแล้วแต่มีลาดับความสาคัญสูง (high priority) ทั้งสิ้น  ทรัพยากรต่าง ๆ มีจานวนจากัด (จานวนทรัพยากร)  ทรัพยากรมีให้ใช้อย่างจากัด (ประเภทของทรัพยากร)  มีการเปลี่ยนแปลงโดยไม่ได้กาหนดไว้ในตารางของแผนในการทาโครงการ (project plan)  เกิดความล่าช้าโดยไม่ได้คาดหมายล่วงหน้า (Unpredicted lack of progress)  ไม่ได้วางแผนเอาไว้ในกรณีที่ขาดแคลนทรัพยากร (เช่น แรงงานหยุดงาน)
  49. 49. อุปสรรคกีดขวางเชิงฟังก์ชัน (FUNCTIONAL OBSTACLES)  ไม่ได้วางแผนเอาไว้ในกรณีที่ทรัพยากรใช้งานไม่ได้ (เช่น เครื่องจักรชารุด เสียหาย)  ไม่ได้วางแผนเอาไว้ในกรณีที่สูญเสียทรัพยากร (เช่น พนักงานลาออก จานวนมาก)  ไม่ได้วางแผนเอาไว้ในเรื่องของ turnover พนักงาน (เช่น พนักลาออก ไป รับพนักงานใหม่เข้ามา ต้องเสียเวลาในการอบรมนานจนกว่าจะเป็น งาน)
  50. 50. ยาแก้คือ การวางแผนที่ดี (THE ANTIDOTE: GOOD PLANNING)  ถ้าการวางแผนทาได้ดีแล้ว ผลดีจะเกิดขึ้นหลายเรื่อง เช่น  Functional units จะเข้าใจความรับผิดชอบของเขาว่าในการที่จะให้ โครงการสาเร็จนั้น จาเป็นต้องใช้อะไรบ้าง (รู้ว่า โครงการต้องการอะไร)  ปัญหาต่าง ๆ ที่เกิดจากการกาหนดเวลาและการเคลื่อนย้ายทรัพยากรที่วิกฤติจะ ถูกรับรู้ล่วงหน้า (ก่อนที่มันจะเกิดปัญหา)  มีการระบุถึงปัญหาแต่เนิน ๆ ทาให้การกาหนดแนวทางการแก้ปัญหาทาได้ ่ อย่างมีประสิทธิภาพ และ ทาปรับแผนเพื่อป้องกันหรือแก้ไขปัญหานั้น ๆ ได้ อย่างเหมาะสม
  51. 51. ข้อกาหนดของแผนโครงการ (PROJECT PLAN REQUIREMENTS)  กาหนดงานต่าง ๆ ที่ต้องทาอย่างครบถ้วน  กาหนดความต้องการของทรัพยากร (และรวมถึงกาหนดระดับของทักษะที่ ต้องการ)  หมายกาหนดการทางด้านเวลา (timetable milestones) หลัก ๆ  กาหนดคุณภาพของผลลัพธ์ท้ายสุดที่ต้องการรวมไปถึงความเชื่อถือ (หรือ ความวางใจได้ของผลลัพธ์ของงานที่ทาออกมา)  พื้นฐานของการวัดประสิทธิภาพ (จาไว้ว่า ไม่วัดก็ไม่ถูกรับรู้ เมื่อไม่รู้ก็ไม่มี การแก้ไข ปรับปรุง)
  52. 52. ความเสี่ยงและสมมติฐาน (RISKS & ASSUMPTIONS)  Risk หรือ ความเสี่ยงต่าง ๆ มักจะถูกละเลย ความเสี่ยงจะแยกเป็น  ภายใน (Internal)  ภายนอก (External)  สมมติฐานต่าง ๆ (Assumptions)
  53. 53. ความเสี่ยงที่อยู่ภายในองค์กร (INTERNAL RISKS)  ท่านสัญญาในสิ่งที่ทาไม่ได้หรือไม่ ?  ใครคือศัตรูของโครงการของท่าน ?  ใครคือผู้ประเมินสมาชิกของกลุ่ม ?  ใครคือผู้ควบคุมงบประมาณของโครงการของท่าน ?  ใครคือผู้กาหนดสมาชิกของกลุ่ม(ว่าเป็นคนนั้นคนนี)ของโครงการของท่าน ? ้  ท่านมีการใส่ (กาหนด) อินพุตเข้าไปในสัญญา (contract) หรือไม่ ?  มี RFP (Request for Pricing) เป็นส่วนหนึ่งของสัญญา (contract) หรือไม่ ?
  54. 54. ความเสี่ยงที่อยู่ภายนอกองค์กร (EXTERNAL RISKS)  เทคโนโลยีจะเปลี่ยนแปลงก่อนที่โครงการของท่านจะเสร็จสิ้นหรือไม่ ?  ผู้ว่าจ้างจะมีการฟ้องร้องเพื่อบังคับให้ทาตามสัญญาหรือไม่ ?  มีใครที่อยู่ใน client staff ต้องการให้โครงการของคุณล้มเหลวหรือไม่ ?  การเปลี่ยนแปลงที่เกิดขึ้นมีการบริหารอย่างไร ?  มีผู้ใช้งาน(หลังจากโครงงานนี้เสร็จสิ้น)เป็นปรปักษ์กับโครงการนี้หรือไม่ ?
  55. 55. สมมติฐาน (ASSUMPTIONS)  ท่านมีสมมติฐานต่าง ๆ มากกว่าข้อเท็จจริงเมื่อพิจารณาของการของท่าน หรือไม่ ?  สมมติฐานข้างต้นมาจากตัวท่านเองหรือเจ้านายให้ท่านมา ?
  56. 56. การรายงาน (REPORTING)  ผู้บริหารโครงการจาเป็นต้องรายงาน(อย่างเที่ยงตรงและเจาะจง)ไปยัง ผู้บริหารระดับสูงขึ้นไปในกรอบเวลาที่กาหนดและใช้เวลาอย่างเหมาะสม  ลูกค้าย่อมมีความรู้สึกที่ดีถ้ารายงานของผู้บริหารโครงการของเขาส่งถึงมือ ผู้บริหารระดับสูงด้วย  การจัดวางบรรดาผู้บริหารโครงการมือใหม่ (junior project manager) เอาไว้ในตาแหน่งที่อยู่ในระดับสูงขององค์กร จะทาให้เกิด ความบาดหมางในระดับ senior functional executives ซึ่ง ต้องให้การสนับสนุน
  57. 57. THE TIP OF THE ICEBERG SYNDROME DELEGATION OF AUTHORITY TO PROJECT MANAGER ผู้บริหารระดับสูง EXECUTIVE MEDDLING เข้าไปจุ้นจ้าน LACK OF UNDERSTANDING OF HOW PROJECT MANAGEMENT SHOULD WORK LACK OF TRAINING IN COMMUNICATIONS / INTERPERSONAL SKILLS MANY OF THE PROBLEMS ASSOCIATED WITH PROJECT MANAGEMENT WILL SURFACE MUCH LATER IN THE PROJECT AND RESULT IN MUCH HIGHER COSTS
  58. 58. นิยาม (DEFINITIONS)  วงรอบชีวิตของโครงการ (Project Life Cycle (PLC))  สิ่งที่ต้องส่งมอบ (Deliverable)  Phase exits, stage gates, or kill points  Fast tracking
  59. 59. PROJECT PHASES AND THE PROJECT LIFE CYCLE  มนุษย์เราเกิดมาก็จะมีวงรอบชีวิต เช่น เกิด เรียน ทางาน แก่ ตาย เป็นต้น ถ้าเรา มองตามระยะเวลา ก็จะแบ่งได้เป็นช่วง ๆ เช่น เกิด (0-3ขวบ) เรียน (4 (อนุบาล) – 25 (จบ ป.โท)) ทางาน (26-60) แก่ (60-80) แล้วก็ตาย วงรอบชีวิตก็คือนาระยะต่าง ๆ (หรือ เฟส (phase)) มาเรียงกันตามลาดับ นั่นเอง  วงรอบชีวิตของโครงการ (project life cycle, PLC) คือ การรวบรวม ระยะต่าง ๆ ของโครงการ (collection of project phases)  ระยะต่าง ๆ จะผันแปรตามโครงการหรืออุตสาหกรรม แต่ทั่ว ๆ ไป ประกอบด้วย  แนวความคิด (concept)  การพัฒนา (development)  การปฏิบัตการ (implementation) ิ  การสนับสนุน (support)
  60. 60. LIFECYCLE MODEL Project management Life Cycle Manage the project Systems Development Life cycle Modify the system System life cycle Project start Project end
  61. 61. GENERIC PROJECT LIFE CYCLE
  62. 62. PHASES/STAGES OF PLC  นิยามเป้าหมายของโครงการ (Define project goal)  วางแผนโครงการ (Plan project)  การตอบคาถามต่าง ๆ (What,why, how, who, et al)  การกาหนดเบสไลน์ (Baseline)ของแผน (หมายถึงข้อกาหนดพื้นฐานของ แผน)  จัดทาแผนเพื่อให้บรรลุพื้นฐานที่กาหนด (Baseline plan) และ ปฏิบัติการให้เป็นไปตามนั้น  ปิดโครงการ (Close project)  การประเมินโครงการ (Evaluate project)
  63. 63. สมมติว่า …..  ที่ทางานของคุณยังทาบัญชีด้วยมือ  1)เป้าหมายของโครงการ: จัดหาซอฟต์แวร์ระบบบัญชีมาใช้ คุณต้องวางแผนและสร้าง  2)แผนของโครงการ: โปรแกรมออกมาหรือ ได้ผลิตภัณฑ์ออกมา  2.1) เขียนโปรแกรมขึ้นมาใช้งานเอง  3) แผนการดาเนินงาน 3  3.1) ลงมือเขียนโปรแกรม 2 4  4) ปิดโครงการ 1 5  5) ประเมินผล
  64. 64. DEFINE PROJECT GOAL  การกาหนดเป้าหมายของโครงการควรมุ่งเน้นไปในการก่อให้เกิดคุณค่า ทางธุรกิจ (business value) ต่อองค์กร  การกาหนดเป้าหมายที่ดีจะทาให้ทีมที่ทาโครงการเห็นภาพของโครงการ ชัดเจนและขับเคลื่อนไปยังเฟสต่าง ๆ ได้อย่างถูกต้องและรวดเร็ว  เป้าหมายหมายของโครงการควรตอบคาถามต่อไปนี้:  เราจะรู้ได้อย่างไรว่า โครงการนี้ประสบความสาเร็จเมื่อเราให้ เวลา เงิน และ ใส่ทรัพยากรเข้าไปแล้ว  นอกจากนั้นโครงการต่าง ๆ ทั้งหลายมักจะมีคุณลักษณะร่วมกันดังนี้  1) ความพยายามในเทอมของระดับของต้นทุนในการดาเนินโครงการ และการหาคนมาทาโครงการ คือมันจะน้อยเมื่อเริ่มโครงการ และมาก ขึ้นเมื่อดาเนินโครงการ และลดลงเมื่อโครงการเกือบเสร็จสิ้น
  65. 65.  2) ความไม่แน่นอน (uncertainty) และความเสี่ยง (risk) จะอยู่ ในระดับสูงสุดเมื่อเริ่มทาโครงการ (โอกาสที่จะประสบความสาเร็จจะต่า) เมื่อเป้าหมายถูกกาหนดแล้วและโครงการเริ่มคืบหน้า โอกาสที่จะประสบ ความสาเร็จจะเพิ่มขึ้น  3) ความสามารถของผู้มีส่วนเกี่ยวข้อกับโครงการทั้งหลายในการเข้ามา มีอิทธิพลต่อขอบเขตและต้นทุนของโครงการจะสูงสุดในช่วงเริ่มต้น โครงการ และต้นทุนของการเปลี่ยนขอบเขตของโครงการและแก้ไข ข้อผิดพลาดจะมีค่ามากขึ้นตามความคืบหน้าของโครงการ
  66. 66. PLAN PROJECT  หลังจากเป้าหมายของโครงการถูกกาหนดแล้ว จะเป็นการสร้างแผนในการ ดาเนินโครงการ แผนนีจะเป็นการตอบคาถามต่อไปนี้ ้  1) เรากาลังจะทาอะไร?  2) ทาไมเราจะต้องทาสิ่งนั้น?  3) เราจะทาสิ่งนั้นอย่างไร?  4) ใครจะต้องเข้ามามีส่วนร่วมบ้าง?  5) การทาสิ่งนั้นจะใช้เวลานานเท่าใด?  6) การทาสิ่งนั้นขึ้นมาต้องใช้เงินเท่าใด?  7) มีอะไรบ้างที่อาจเกิดความผิดพลาดได้และเราสามารถทาอะไรกับมันได้บาง? ้  8) เราจะประมาณเวลาและงบประมาณในการทาสิงนั้นได้อย่างไร? ่  9) ทาไมเราจึงตัดสินใจที่จะทาสิ่งนั้น?  10) เราจะรู้ได้อย่างไรว่าเราทาได้สาเร็จ
  67. 67.  นอกจากนั้น สิ่งที่ต้องส่งมอบทั้งหลาย (deliverables) กิจกรรม ต่าง ๆ (tasks) และ เวลาที่แต่ละกิจกรรมใช้ไปต้องถูกกาหนดในแต่ ละเฟสของโครงการ  แผนตั้งต้นจะเรียกว่า baseline plan (แผนพื้นฐานที่ต้องบรรลุ) มันจะกาหนดขอบเขต ตารางเวลา และงบประมาณที่ได้ตกลงร่วมกัน เอาไว้ ซึ่งแผนนี้จะถูกใช้เป็นเครื่องมือในการวัดประสิทธิภาพของ โครงการตลอดวงรอบชีวิต
  68. 68. EXECUTE PROJECT PLAN  หลังจากเป้าหมายของโครงการและแผนของโครงการถูกกาหนดขึ้นมาเรียบร้อย แล้ว ก็จะเป็นการนาแผนไปดาเนินงาน  งานที่เกี่ยวข้องกับความก้าวหน้าของโครงการ ขอบเขต ตารางเวลาการทางาน งบประมาณและผู้คนที่ทาโครงงานจะต้องถูกจัดการเพื่อมั่นใจได้ว่าโครงการจะ บรรลุเป้าหมายที่วางไว้  ความก้าวหน้าที่เกิดขึ้นจะต้องบันทึกเป็นเอกสารและเทียบกับ baseline plan  ประสิทธิภาพของการดาเนินโครงการต้องถูกสื่อสารให้ผู้มีส่วนเกียวข้องทราบ ่  ที่จุดสิ้นสุดของเฟสนี้ ทีมต้องส่งมอบผลิตภัณฑ์ (product) (หรือ นา ผลิตภัณฑ์นั้นมาใช้งาน) ให้แก่องค์กร
  69. 69. CLOSE PROJECT  จากที่ได้กล่าวมาแล้วว่า โครงการต้องชัดเจนในตอนเริ่มต้นและสิ้นสุด (end) เฟสทาการปิดโครงการมีขึ้นก็เพื่อให้มั่นใจได้ว่า งานทุกงานที่กาหนดไว้ในแผน (หรือ ตามที่ตกลงกันระหว่างทีมผู้ทาโครงการกับสปอนเซอร์) เสร็จสิ้นสมบูรณ์ แล้ว  ดังนั้นจึงควรจะมีการรับรู้อย่างเป็นทางการเกิดขึ้นโดยสปอนเซอร์ว่าเขาจะยอมรับ ผลิตภัณฑ์ที่ทีมทาโครงการส่งมอบให้หรือไม่  การปิดโครงการมักจะทาโดยทาการส่งรายงานขึ้นสุดท้าย (final report) และการนาเสนอเอกสารที่แสดงให้เห็นว่าสิ่งที่ต้องส่งมอบที่ได้สัญญาไว้ทุก ๆ เรื่อง (promised deliverables)ได้ดาเนินการเสร็จสิ้นแล้วตามที่ระบุ ไว้ ให้กับผู้เกี่ยวข้องและเพื่อร่วมงานทั้งหลาย
  70. 70. EVALUATE PROJECT  บางครั้งคุณค่าของโครงการที่เกี่ยวข้องกับ IT ยังอาจรับรู้ไม่ชัดเจนเมื่อ ระบบถูกใช้งานในช่วงแรก เช่น เป้าหมายของโครงการในการสร้าง E- commerce คือการก่อให้เกิดรายได้เพิ่มขึ้น ไม่ใช่เรื่องของ H/W, S/W หรือ Web page ใด ๆ ทั้งสิ้น สมมติว่ามีรายได้เป็น 250,000 USD ภายใน 6 เดือน ในกรณีเช่นนี้จะเห็นว่า เราจะ ประเมินโครงการนี้ว่าบรรลุเป้าหมายหรือไม่ ก็ต้องหลังจากระบบถูกใช้งาน ไปแล้วประมาณ 6 เดือน  โครงการอาจจะถูกประเมินในแนวทางอื่นก็ได้ เช่น การบันทึก ประสบการณ์การทาโครงงานในเทอมของบทเรียนจากอดีต หรือ lesson learned เพื่อใช้เป็นประโยชน์ในอนาคต
  71. 71.  นอกจากนั้น ทังตัวโครงการและทีมทาโครงการต้องถูกประเมินหลังจาก ้ โครงการแล้วเสร็จเสมอ ผู้จัดการโครงการต้องประเมินประสิทธิภาพของ ทีมงานเพื่อป้อนกลับให้เขารู้ ส่วนตัวโครงการอาจเชิญบุคคลภายนอกมาทา การประเมิน เพื่อดูว่า โครงการมรการจัดการดีหรือไม่ ให้สิ่งที่ต้องส่งมอบ ครบถ้วนหรือไม่ ดาเนินงานตามกระบวนการที่กาหนดหรือไม่ ได้คุณภาพ ตามที่กาหนดหรือไม่
  72. 72. PRODUCT LIFE CYCLES  ผลิตภัณฑ์ (Products) ก็จะมีวงรอบชีวิตเช่นกัน  วงรอบชีวิตของการพัฒนาระบบ (Systems Development Life Cycle (SDLC)) คือกรอบการทางานที่ใช้อธิบายระยะ(เวลา)ที่ใช้ในการ พัฒนาและบารุงรักษาระบบสารสนเทศ  โครงการพัฒนาระบบ (Systems development projects) สามารถกล่าวได้ว่า มีรูปแบบดังนี้  predictive models: ขอบเขตของโครงการสามารถกาหนดได้ชัดแจ้งและ ตารางเวลากับต้นทุนสามารถทานายได้  adaptive models: โครงการเป็นแบบถูกสถานการณ์บังคับ (mission driven) และ อยู่บนพื้นฐานของส่วนประกอบ (component based) ซึ่งใช้ วงรอบของเวลามาเป็นพื้นฐานเพื่อให้สอดรับกับ target dates
  73. 73. SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC) วางแผน วิเคราะห์ ออกแบบ นาไปปฏิบัติ บารุงรักษา เราจะสร้างระบบอะไรขึ้นมาสักระบบหนึ่ง เช่น ระบบบัญชีที่ใช้คอมพิวเตอร์เข้าช่วย วงรอบชีวิต หรือ วัฏจักรของการพัฒนาระบบนี้ จะเป็นดังรูปข้างบน
  74. 74. SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC)  ดังนั้นจึงกล่าวได้ว่า SDLC ก็คือ ระยะหรือเฟส (phase) หรือ ขั้นตอน (stage) ที่อนุกรมกันไป(sequential) ของระบบ สารสนเทศ ที่ต้องดาเนินการต่อเนื่องกันไปตลอดอายุการใช้งาน  ระยะ/ขั้นตอน (Phases/Stages)  การวางแผน (Planning)  การวิเคราะห์ (Analysis)  การออกแบบ (Design)  การนาไปปฏิบัติ (Implementation) (สร้างขึ้นมาแล้วนาไปใช้งาน)  การดูแลรักษาและให้การสนับสนุน (Maintenance and Support)
  75. 75.  การวางแผน (Planning)  ขั้นตอนการวางแผนประกอบด้วยการบ่งชี้และสนองตอบต่อ ปัญหาหรือ โอกาส และร่วมมือกันจัดการโครงการ และกระบวนการพัฒนาระบบและ กิจกรรมต่าง ๆ ที่เกี่ยวข้อง การมีกระบวนการวางแผนอย่างเป็นทางการ ย่อมทาให้มั่นใจได้ว่า เป้าหมาย ขอบเขต งบประมาณ ตารางเวลา เทคโนโลยี และเครื่องมือ กรรมวิธีการ กระบวนการพัฒนาระบบ มีอย่าง ถูกต้องและครบถ้วนแล้ว
  76. 76.  การวิเคราะห์ (Analysis)  ขั้นตอนนี้ เป็นการพยายามขุดลึกลงไปในปัญหาหรือโอกาสอย่างเต็มที่ ตัวอย่างเช่น กลุ่มทาโครงการได้ศึกษาระบบปัจจุบันเพื่อจัดทาเอกสารขึ้นมา ตามที่มันเป็น (as is) เพื่อจะได้ทาความเข้าใจ แล้วทาการบ่งชี้และจัดทา เป็นเอกสารเกี่ยวกับปัญหาใด ๆ หรือ ขีดจากัดที่มีอยู่ในระบบปัจจุบัน เป็น การวิเคราะห์ความต้องการหรือ requirement analysis นั่นเอง จากนันจึงทาการบ่งชี้ specific need and requirement ของ ้ ระบบใหม่ (to be system) และทาให้เป็นเอกสาร  Requirement (ของระบบใหม่) อาจหาได้หลายทาง เช่น การ สัมภาษณ์ผู้ใช้ การพัฒนาโปรแกรมประยุกต์ร่วมกัน (Joint Application Development, JAD) การทาการสารวจ การ สังเกตกระบวนการทางาน การศึกษาจากรายงานขององค์กร
  77. 77.  การออกแบบ (Design)  ในระหว่างขั้นตอนการออกแบบ กลุ่มทาโครงการจะใช้โมเดลทางตรรกะ ของของ “as is” และ requirement เป็นอินพุตในการออกแบบ สถาปัตยกรรมเพื่อสนับสนุนระบบสารสนเทศระบบใหม่  สถาปัตยกรรมใหม่นี้ประกอบด้วยการออกแบบโครงข่าย Hardware configuration ฐานข้อมูล การเชื่อมต่อกับผู้ใช้ (User interface) และ โปรแกรมประยุกต์ต่าง ๆ
  78. 78.  การนาไปปฏิบัติ (Implementation)  การนาไปใช้งานประกอบด้วย การพัฒนา หรือ สร้างระบบขึ้นมา การ ทดสอบ และ การติดตั้ง ทั้งนี้รวมถึง การฝึกอบรม การให้การสนับสนุน และ การจัดทาเอกสารต่าง ๆ
  79. 79.  การดูแลรักษาและให้การสนับสนุน (Maintenance and Support)  เมื่อระบบถูกใช้งาน การเปลี่ยนแปลงใด ๆ ที่เกิดกับระบบ เช่น การดูแล รักษาและปรับปรุงให้ดีขึ้นมักถูกร้องขอให้ดาเนินการ เช่น การแก้ไข ข้อบกพร่อง เป็นต้น หรือ การเพิ่มเติมลักษณะบางสิ่งบางอย่างเพิ่มเติม จากเดิม หรือ เกิดการปรับเปลี่ยนสภาพแวดล้อมทางธุรกิจ เป็นต้น  ส่วนการสนับสนุนอาจอยู่ในรูปของ Call Center หรือ Helpdesk เพื่อช่วยผู้ใช้งานสามารถใช้งานได้ตามที่เขาต้องการ (as need basis)
  80. 80. IMPLEMENTING SDLC: STRUCTURED APPROACHES TO SYSTEMS DEVELOPMENT วิธีการลดหลันแบบน้าตก (Waterfall Method) ่ Waterfall model มีการกาหนดๆ ไว้เป็นอย่างดี มีขั้นตอนแบบเชิงเส้นในการพัฒนาระบบและ การให้การสนับสนุน เรียกแนวทางนีวา แนวทางเชิงเส้น (linear approach) ้่ 80
  81. 81. WATERFALL METHOD Define Requirements Design Build Test Implement Maintenance
  82. 82. ITERATIVE SYSTEMS DEVELOPMENT  ใช้แนวทางการพัฒนาแอพพลิเคชันอย่างรวดเร็ว (Rapid Applications Development (RAD)) ถูกนามาใช้สร้างระบบต่าง ๆ อย่างรวดเร็วโดยไม่ จาเป็นต้องมีลดทอนเรื่องคุณภาพลง (sacrificing quality)  การทาต้นแบบ (Prototyping) ถูกนามาใช้ในการพัฒนาต้นแบบ (prototype) เพื่อพิจารณาถึงความต้องการของผู้ใช้ให้ชัดเจน (clarify user requirements)  การพัฒนาหมุนวนแบบใยแมงมุม (Spiral Development) แสดงว่า ซอฟท์แวร์ ถูกพัฒนาโดยใช้การทาซ้า ๆ (iterative) หรือ แนวทางหมุนวนแบบใยแมงมุม (spiral approach) แทนที่จะเป็นแบบ linear approach  Incremental release model ใช้สาหรับ progressive development ของ operational software
  83. 83.  การพัฒนาระบบแบบคล่องตัว (Agile Systems Development)  SCRUM Repetitions of iterative development are referred to as sprints, which normally last thirty days. Teams often meet every day for a short meeting, called a scrum, to decide what to accomplish that day. Works best for object-oriented technology projects and requires strong leadership to coordinate the work  DSDM (Dynamic systems development method)  ASD (Adaptive software development)  XP (eXtreme programming) โปรแกรมจะถูกพัฒนาแบบขนานหรือพร้อม ๆ กันไปในหลาย ๆ ส่วน และจะต้องทาการทดสอบโปรแกรมที่เขียนขึ้นมาด้วย ดังนั้นทีม XP จึงประกอบด้วย ผู้พัฒนา ผู้บริหาร และ ผู้ใช้ อยู่ในกลุ่มเดียวกัน
  84. 84. V-SHAPED SDLC MODEL
  85. 85. INCREMENTAL SDLC MODEL
  86. 86. SPIRAL SDLC MODEL
  87. 87. THE PLC VS. THE SDLC
  88. 88. ความสัมพันธ์ระหว่าง PLC และ SDLC  จากรูปจะเห็นว่า วงรอบชีวิตของการพัฒนาระบบ (systems development life cycle (SDLC)) กลายเป็นส่วนหนึงของ ่ วงรอบชีวิตของโครงการ (project life cycle (PLC))  PLC เน้นที่ เทคนิค เครื่องมือ กระบวนการ เฟสต่าง ๆ ในการบริหารโครงงาน เพื่อให้การบริหารโครงงานเป็นไปอย่างมีประสิทธิผล  SDLC เน้นที่เทคนิค เครื่องมือ กระบวนการ เฟสต่าง ๆ ในเชิงวิศวกรรม ซอฟต์แวร์เพื่อสร้าง IT Solution และ/หรือนาไปปฏิบัติ (ใช้งาน)  ถ้า SDLC คือ คนงานที่ก่อสร้างบ้านแล้ว PLC ก็คือผู้คุมงานนั่นเอง
  89. 89. ผู้คุมงาน (บริหารโครงการ) กับ คนงาน (บริหารแรงงาน)
  90. 90. EXTREME PROJECT MANAGEMENT (XPM)  ปรัชญาและแนวทางใหม่ของการบริหารโครงการที่เริ่มได้รบความนิยมมากขึ้น ั  โดยมองในเชิงลักษณะที่มีความหลากหลายของโครงการในปัจจุบัน จะเห็นว่า ต้องการ ความเร็วในการทาให้โครงการสาเร็จเร็วขึ้น โครงการมีความไม่แน่นอน มากขึ้น มีความต้องการในการเปลี่ยนแปลงมากขึ้น มีความเสี่ยงมากขึ้น  การบริหารโครงการแบบดั้งเดิมใช้แนวทางดาเนินการแบบเรียงลาดับกันไป ในขณะที่ XPM ยืนอยู่บนพืนฐานที่ว่าโครงการมักไร้ระเบียบ (chaotic) ้ และ คาดการได้ยาก (unpredictable) ดังนั้น XPM จึงเน้นที่ความ คล่องตัว การปรับตัวและนวัตกรรม  การใช้ทั้งแบบดั้งเดิมและแบบใหม่ร่วมกันทาให้เข้าใจโครงงานได้ดีขึ้น ส่งผลให้ รู้ว่าจะทาอย่างไรโครงการจึงมีโอกาสสาเร็จมากขึ้น
  91. 91. WHY HAVE PROJECT PHASES AND MANAGEMENT REVIEWS?  โครงงานควรประสบผลสาเร็จในแต่ละ เฟส เมื่อเฟสแรกสาเร็จแล้ว จึงลงมือทาใน เฟสถัดไป  Management reviews (บางที เรียกว่า “phase exits” หรือ “kill points”) อาจเกิดขึ้นหลังจากแต่ละเฟส ถูกประเมินถึงความคืบหน้าของโครงการ (โอกาสที่น่าจะประสบความสาเร็จ) และ ยังคงสอดรับกับ organizational goals
  92. 92. THE PROJECT MANAGEMENT BODY OF KNOWLEDGE (PMBOK®)  เอกสารแสดงแนวทาง (Guide) ของ Project Management Body of Knowledge (PMBOK® Guide) ประกอบด้วย 9 project management knowledge areas.  The PMBOK® Guide is published and maintained by the Project Management Institute (PMI).  http://www.pmi.org
  93. 93. PMBOK
  94. 94. PROJECT MANAGEMENT KNOWLEDGE AREAS
  95. 95.  1. การบริหารเชิงบูรณาการของโครงการ (Project integration management)  2. การบริหารขอบเขตของโครงการ (Project scope management)  3. การบริหารเวลาที่ใช้ในโครงการ (Project time management)  4. การบริหารงบประมาณของโครงการ (Project cost management)  5. การบริหารคุณภาพของโครงการ (Project quality management)  6. การบริหารทรัพยากรบุคคลของโครงการ (Project human resources management)  7. การบริหารการสื่อสารในโครงการ (Project communications management)  8. การบริหารความเสี่ยงของโครงการ (Project risk management)  9. การบริหารการจัดซื้อในโครงการ (Project procurement management)
  96. 96.  1. การบริหารเชิงบูรณาการของโครงการ (Project integration management) ประกอบด้วย  1.1 การพัฒนาแผนของโครงการ (Project Plan Development)  1.2 การปฏิบัตตามแผนของโครงการ (Project Plan Execution) ิ  1.3 การควบคุมการเปลี่ยนแปลงโดยรวม (Integrated Change Control)  2. การบริหารขอบเขตของโครงการ (Project scope management)  2.1 ขั้นตอนเริ่มต้น (Initiating)  2.2 การวางแผนขอบเขต (Scope Planning)  2.3 การกาหนดขอบเขต (Scope Definition)  2.4 การทวนสอบขอบเขต (Scope Verification)  2.5 การควบคุมการเปลี่ยนขอบเขต (Scope Change Control)
  97. 97.  3. การบริหารเวลาที่ใช้ในโครงการ (Project time management)  3.1 การกาหนดกิจกรรมที่ต้องทา (Activity Definition)  3.2 การกาหนดลาดับกิจกรรมที่ต้องทา (Activity Sequencing)  3.3 การประมาณระยะเวลาของกิจกรรมทีต้องทา (Activity Duration Estimating) ่  3.4 การสร้างตารางเวลาในการดาเนินกิจกรรม (Schedule Development)  3.5 การควบคุมให้เป็นไปตามตารางเวลา (Schedule Control)  4. การบริหารงบประมาณของโครงการ (Project cost management)  4.1 การวางแผนด้านทรัพยากร (Resource Planning)  4.2 การประมาณค่าใช้จ่าย (Cost Estimating)  4.3 การทางบประมาณค่าใช้จ่าย (Cost Budgeting)  4.4 การควบคุมค่าใช้จ่าย (Cost Control)
  98. 98.  5. การบริหารคุณภาพของโครงการ (Project quality management)  5.1 การวางแผนด้านคุณภาพ (Quality Planning)  5.2 การประกันคุณภาพ (Quality Assurance)  5.3 การควบคุมคุณภาพ (Quality Control)  6. การบริหารทรัพยากรบุคคลของโครงการ (Project human resources management)  6.1 การวางแผนองค์กร (Organizational Planning)  6.2 การจัดหาคนเข้าทางาน (Staff Acquisition)  6.3 การสร้างทีม  7. การบริหารการสื่อสารในโครงการ (Project communications management)  7.1 การวางแผนด้านการสื่อสาร (Communication Planning)  7.2 การกระจายสารสนเทศ (Information Distribution)  7.3 การรายงานประสิทธิภาพ (Performance Reporting)  7.4 การจัดการเกี่ยวกับการปิดโครงการ (Administrative Closure)
  99. 99.  8. การบริหารความเสี่ยงของโครงการ (Project risk management)  8.1 การวางแผนบริหารความเสี่ยง (Risk Management Planning)  8.2 การบ่งชี้ความเสี่ยง (Risk Identification)  8.3 การวิเคราะห์ความเสี่ยงเชิงคุณภาพ (Qualitative Risk Analysis)  8.4 การวิเคราะห์ความเสี่ยงเชิงประมาณ (Quantitative Risk Analysis)  8.5 การวางแผนสนองตอบต่อความเสี่ยง (Risk Response Planning)  8.6 การเฝ้าดูและการควบคุมความเสี่ยง (Risk Monitoring and Control)  9. การบริหารการจัดซื้อในโครงการ (Project procurement management)  9.1 การวางแผนด้านการจัดซื้อ (Procurement Planning)  9.2 การวางแผนเพื่อเชื้อเชิญให้เสนอราคา (Solicitation Planning)  9.3 การเสนอราคา (Solicitation)  9.4 การคัดเลือกผู้ขาย (Source Selection)  9.5 การจัดการเกี่ยวกับสัญญา (Contract Administration)  9.6 การปิดสัญญา (Contract Closeout)
  100. 100. TOP TEN MOST IN-DEMAND IT SKILLS Rank IT Skill/Job Average Annual Salary 1 SQL Database Analyst $80,664 2 Oracle Database Analyst $87,144 3 C/C++ Programmer $95,829 4 Visual Basic Programmer $76,903 5 E-commerce/Java Developer $89,163 6 Windows NT/2000 Expert $80,639 7 Windows/Java Developert $93,785 8 Security Architect $86,881 9 Project Manager $95,719 10 Network Engineer $82,906 Paul Ziv, “The Top 10 IT Skills in Demand,” Global Knowledge Webcast (www.globalknowledge.com) (11/20/2002).
  101. 101. TOP INFORMATION TECHNOLOGY SKILLS 70% 60% 58% 60% 50% Percentage of 42% 41% 40% Respondents 30% 20% 10% 0% Application Project management Database Networking development management Information Technology (IT) Skill Cosgrove, Lorraine, “January 2004 IT Staffing Update,” CIO Research Reports (February 3, 2004).
  102. 102. จบหัวข้อ 1

×