1. PROJECT AND CHANGE
MANAGEMENT
1

2. INFORMATION TECHNOLOGY
PROJECT MANAGEMENT
by Jack T. Marchewka
2

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

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

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. PROJECT MANAGEMENT BODY OF KNOWLEDGE
(PMBOK)

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

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

10. ADVANTAGES OF USING FORMAL PROJECT
MANAGEMENT
 สามารถควบคุม financial, physical, และ human
resources ได้ดีขึ้น
 ความสัมพันธ์กับลูกค้า ถูกปรับปรุงให้ดีขึ้น
 เวลาที่ใช้พัฒนาลดน้อยลง
 ต้นทุนต่าลง
 คุณภาพและความวางใจได้เพิมสูงขึ้น
่
 ผลกาไรสูงขึ้น
 ผลิตผลถูกปรับปรุงให้ดีขึ้น
 การประสานงานภายในดีขึ้น
 อารมณ์ร่วมในการ(อยาก)ทางานสูงขึ้น

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

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

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. FIGURE 1.1 - SUMMARY OF THE CHAOS
STUDIES FROM 1994 TO 2006

15. HAS THE CURRENT STATE OF IT PROJECTS
CHANGED SINCE 1994?
 Standish Group ได้ศึกษาโครงการ IT อย่างต่อเนื่องมาหลายปี
พบว่า เมื่อกล่าวกว้าง ๆ จะเห็นว่าโครงการเกี่ยวกับ IT มีอัตรา
ความสาเร็จสูงขึ้น อันเนื่องมาจาก
 มีกระบวนการและเครื่องมือในการจัดการกับโครงการดีขึ้น
 โครงการต่าง ๆ มีขนาดเล็กลง
 การสื่อสารระหว่างผู้มีส่วนเกี่ยวข้องทั้งหลาย (stakeholder) ได้รับการ
ปรับปรุง
 ผู้จัดการโครงการเกี่ยวกับ IT มีทักษะและความชานาญมากขึ้น
 แต่อย่างไรก็ตาม มันยังมีโอกาสในการปรับปรุงให้ดีขึ้นอีกมาก

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. แล้วปี 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. 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. WHY IT PROJECTS FAIL
 เหตุผลหนึ่งที่ทาให้โครงการเกียวกับ IT ล้มเหลวในอัตราทีสูง ก็คือ การนิยาม
่ ่
การ “ประสบความสาเร็จ (Success)” หรือ “ล้มเหลว (Failure)”
ตามนิยามของ CHAOS ได้นิยามว่า โครงการใด ๆ ก็ตาม แม้ว่าจะสร้าง
คุณค่าให้แก่องค์กรอย่างมากมาย แต่ถ้าเกินงบประมาณหรือเวลาที่กาหนด จะ
ถือว่า “ล้มเหลว”ทั้งสิ้น
 จากการศึกษาของ CHAOS ได้ผลออกมาน่าสนใจดังตารางในหน้าถัดไป
มันเป็นการบอกถึงปัจจัยที่ท้าทายของโครงการอันก่อให้เกิดปัจจัยแห่งความ
ล้มเหลว เช่น อินพุตจากผู้ใช้ไม่พอเพียง หรือ ขาดการมีส่วนร่วมของผู้ใช้ ทา
ให้ทีมที่ทาโครงการเสียเวลาในการทาความเข้าใจว่าผู้ใช้ต้องการอะไร
เสียเวลาในการกาหนดความต้องการของโครงการ ท้ายที่สุดก็จะเกิดข้อขัดแย้ง
ระหว่างผู้พัฒนาโปรแกรมและผู้ใช้ เป็นต้น

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

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. 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.  ใช้แนวทางการบริหารองค์ความรู้ (Knowledge
Management Approach)
 บทเรียนจากอดีต (lesson learned)
 การปฏิบัติงานที่เป็นเลิศ (best practices) และ
 การแบ่งปันความรู้ (Knowledge Sharing)

25. TOP IT PROJECTS

26. THE CONTEXT OF PROJECT MANAGEMENT
 คานิยามของ “โครงการ (Project)”
 โครงการ (project) คือ การรวมตัวกันชั่วคราวเพื่อพยายามดาเนินการให้บรรลุ
เป้าประสงค์เรื่องใดเรื่องหนึ่งที่ชัดเจน
 ดังนั้น การบริหารโครงการจึงหมายถึง การประยุกต์ใช้องค์ความรู้ ทักษะ เครื่องมือ
ต่าง ๆ และ เทคนิคต่าง ๆ กับการดาเนินโครงการ เพื่อให้ได้ผลตาม ความต้องการ
หรือความคาดหวัง (หรือดีกว่า) จากโครงการหนึ่ง ๆ โดยผู้เกี่ยวข้องทั้งหลาย
 ลองนึกซิครับว่า งาน (ที่เราทากันอยู่ทุก ๆ วัน) จะเรียกว่า โครงการได้หรือไม่ ?!?
ถ้าไม่ได้ แล้วโครงการจะต้องมีลักษณะ (attribute) อะไรที่แสดงให้เราเห็น
เพื่อใช้แยกแยะความแตกต่างได้ (เราเรียกว่า Project Attribute)

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

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

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

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

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

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

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

34. THE TRIPLE CONSTRAINT
ขอบเขตบาน เวลาเกิน
Figure 1.2
งบเกิน

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. แฟกเตอร์ที่เกียวข้องกับวัฒนธรรม (THE CULTURE FACTOR)
่
 ความสัมพันธ์ที่ดีระหว่างการทางานรายวัน (daily working) กับ
ผู้บริหารโครงการ (project manager) และ ผู้บริหารแผนก
(line managers) ผู้ซึ่งมีหน้าที่กาหนดทรัพยากรต่าง ๆ ลงไปใน
โครงงาน
 ความสามารถของ functional employees ในการรายงานตาม
สายบังคับบัญชาไปยัง line manager ของเขา (ถือเป็นแนวตั้ง) และ
Functional Manager
เขายังต้องรายงานไปยังผู้บริหารโครงการหนึ่งคนหรือมากกว่า (ถือเป็น
แนวนอน) Project Manager 1
Project Manager 2

37. ทรัพยากรของโครงการ (PROJECT RESOURCES)
 เงิน
 คนงาน (Manpower)
 เครื่องมือ
 สิ่งอานวยความสะดวก
 วัตถุดิบ (Materials)
 สารสนเทศ/เทคโนโลยี

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

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

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

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

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

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

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

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

46. ผู้ชานาญการ (THE EXPERTS)
 ผู้ชานาญที่เกี่ยวข้องกับเรื่องสาคัญ ๆ ที่เกี่ยวข้องกับโครงงาน (Subject
Matter Expert(s) (SME))
 ผู้ชานาญด้านเทคนิค (Technical Expert(s) (TE))
 โดยทั่วไปแล้ว ทั้งสองส่วนนี้อาจได้มาจากแผนกหรือพื้นที่ต่าง ๆ ในองค์กร
ซึ่งทางานอยู่ภายใต้ functional manager และจะกลายเป็นสมาชิก
ของกลุ่มที่รับผิดชอบในการทาโครงการภายใต้การดูแลของผู้บริหาร
โครงการจนกระทั่งโครงการแล้วเสร็จ

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. อุปสรรคกีดขวางเชิงฟังก์ชัน (FUNCTIONAL OBSTACLES)
 การร้องขอให้ทางานอย่างไม่มีขีดจากัด (Unlimited work requests)
 มีเส้นตาย (deadline) ที่กาหนดไว้ก่อนแล้ว (Predetermined
deadlines)
 การร้องขอทั้งหมดล้วนแล้วแต่มีลาดับความสาคัญสูง (high priority) ทั้งสิ้น
 ทรัพยากรต่าง ๆ มีจานวนจากัด (จานวนทรัพยากร)
 ทรัพยากรมีให้ใช้อย่างจากัด (ประเภทของทรัพยากร)
 มีการเปลี่ยนแปลงโดยไม่ได้กาหนดไว้ในตารางของแผนในการทาโครงการ
(project plan)
 เกิดความล่าช้าโดยไม่ได้คาดหมายล่วงหน้า (Unpredicted lack of
progress)
 ไม่ได้วางแผนเอาไว้ในกรณีที่ขาดแคลนทรัพยากร (เช่น แรงงานหยุดงาน)

49. อุปสรรคกีดขวางเชิงฟังก์ชัน (FUNCTIONAL OBSTACLES)
 ไม่ได้วางแผนเอาไว้ในกรณีที่ทรัพยากรใช้งานไม่ได้ (เช่น เครื่องจักรชารุด
เสียหาย)
 ไม่ได้วางแผนเอาไว้ในกรณีที่สูญเสียทรัพยากร (เช่น พนักงานลาออก
จานวนมาก)
 ไม่ได้วางแผนเอาไว้ในเรื่องของ turnover พนักงาน (เช่น พนักลาออก
ไป รับพนักงานใหม่เข้ามา ต้องเสียเวลาในการอบรมนานจนกว่าจะเป็น
งาน)

50. ยาแก้คือ การวางแผนที่ดี (THE ANTIDOTE: GOOD
PLANNING)
 ถ้าการวางแผนทาได้ดีแล้ว ผลดีจะเกิดขึ้นหลายเรื่อง เช่น
 Functional units จะเข้าใจความรับผิดชอบของเขาว่าในการที่จะให้
โครงการสาเร็จนั้น จาเป็นต้องใช้อะไรบ้าง (รู้ว่า โครงการต้องการอะไร)
 ปัญหาต่าง ๆ ที่เกิดจากการกาหนดเวลาและการเคลื่อนย้ายทรัพยากรที่วิกฤติจะ
ถูกรับรู้ล่วงหน้า (ก่อนที่มันจะเกิดปัญหา)
 มีการระบุถึงปัญหาแต่เนิน ๆ ทาให้การกาหนดแนวทางการแก้ปัญหาทาได้
่
อย่างมีประสิทธิภาพ และ ทาปรับแผนเพื่อป้องกันหรือแก้ไขปัญหานั้น ๆ ได้
อย่างเหมาะสม

51. ข้อกาหนดของแผนโครงการ (PROJECT PLAN
REQUIREMENTS)
 กาหนดงานต่าง ๆ ที่ต้องทาอย่างครบถ้วน
 กาหนดความต้องการของทรัพยากร (และรวมถึงกาหนดระดับของทักษะที่
ต้องการ)
 หมายกาหนดการทางด้านเวลา (timetable milestones) หลัก ๆ
 กาหนดคุณภาพของผลลัพธ์ท้ายสุดที่ต้องการรวมไปถึงความเชื่อถือ (หรือ
ความวางใจได้ของผลลัพธ์ของงานที่ทาออกมา)
 พื้นฐานของการวัดประสิทธิภาพ (จาไว้ว่า ไม่วัดก็ไม่ถูกรับรู้ เมื่อไม่รู้ก็ไม่มี
การแก้ไข ปรับปรุง)

52. ความเสี่ยงและสมมติฐาน (RISKS & ASSUMPTIONS)
 Risk หรือ ความเสี่ยงต่าง ๆ มักจะถูกละเลย ความเสี่ยงจะแยกเป็น
 ภายใน (Internal)
 ภายนอก (External)
 สมมติฐานต่าง ๆ (Assumptions)

53. ความเสี่ยงที่อยู่ภายในองค์กร (INTERNAL RISKS)
 ท่านสัญญาในสิ่งที่ทาไม่ได้หรือไม่ ?
 ใครคือศัตรูของโครงการของท่าน ?
 ใครคือผู้ประเมินสมาชิกของกลุ่ม ?
 ใครคือผู้ควบคุมงบประมาณของโครงการของท่าน ?
 ใครคือผู้กาหนดสมาชิกของกลุ่ม(ว่าเป็นคนนั้นคนนี)ของโครงการของท่าน ?
้
 ท่านมีการใส่ (กาหนด) อินพุตเข้าไปในสัญญา (contract) หรือไม่ ?
 มี RFP (Request for Pricing) เป็นส่วนหนึ่งของสัญญา
(contract) หรือไม่ ?

54. ความเสี่ยงที่อยู่ภายนอกองค์กร (EXTERNAL RISKS)
 เทคโนโลยีจะเปลี่ยนแปลงก่อนที่โครงการของท่านจะเสร็จสิ้นหรือไม่ ?
 ผู้ว่าจ้างจะมีการฟ้องร้องเพื่อบังคับให้ทาตามสัญญาหรือไม่ ?
 มีใครที่อยู่ใน client staff ต้องการให้โครงการของคุณล้มเหลวหรือไม่
?
 การเปลี่ยนแปลงที่เกิดขึ้นมีการบริหารอย่างไร ?
 มีผู้ใช้งาน(หลังจากโครงงานนี้เสร็จสิ้น)เป็นปรปักษ์กับโครงการนี้หรือไม่ ?

55. สมมติฐาน (ASSUMPTIONS)
 ท่านมีสมมติฐานต่าง ๆ มากกว่าข้อเท็จจริงเมื่อพิจารณาของการของท่าน
หรือไม่ ?
 สมมติฐานข้างต้นมาจากตัวท่านเองหรือเจ้านายให้ท่านมา ?

56. การรายงาน (REPORTING)
 ผู้บริหารโครงการจาเป็นต้องรายงาน(อย่างเที่ยงตรงและเจาะจง)ไปยัง
ผู้บริหารระดับสูงขึ้นไปในกรอบเวลาที่กาหนดและใช้เวลาอย่างเหมาะสม
 ลูกค้าย่อมมีความรู้สึกที่ดีถ้ารายงานของผู้บริหารโครงการของเขาส่งถึงมือ
ผู้บริหารระดับสูงด้วย
 การจัดวางบรรดาผู้บริหารโครงการมือใหม่ (junior project
manager) เอาไว้ในตาแหน่งที่อยู่ในระดับสูงขององค์กร จะทาให้เกิด
ความบาดหมางในระดับ senior functional executives ซึ่ง
ต้องให้การสนับสนุน

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. นิยาม (DEFINITIONS)
 วงรอบชีวิตของโครงการ (Project Life Cycle (PLC))
 สิ่งที่ต้องส่งมอบ (Deliverable)
 Phase exits, stage gates, or kill points
 Fast tracking

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. LIFECYCLE MODEL
Project management Life Cycle Manage the project
Systems Development Life cycle Modify the system
System life cycle
Project start Project end

61. GENERIC PROJECT LIFE CYCLE

62. PHASES/STAGES OF PLC
 นิยามเป้าหมายของโครงการ (Define project goal)
 วางแผนโครงการ (Plan project)
 การตอบคาถามต่าง ๆ (What,why, how, who, et al)
 การกาหนดเบสไลน์ (Baseline)ของแผน (หมายถึงข้อกาหนดพื้นฐานของ
แผน)
 จัดทาแผนเพื่อให้บรรลุพื้นฐานที่กาหนด (Baseline plan) และ
ปฏิบัติการให้เป็นไปตามนั้น
 ปิดโครงการ (Close project)
 การประเมินโครงการ (Evaluate project)

63. สมมติว่า …..
 ที่ทางานของคุณยังทาบัญชีด้วยมือ
 1)เป้าหมายของโครงการ: จัดหาซอฟต์แวร์ระบบบัญชีมาใช้
คุณต้องวางแผนและสร้าง
 2)แผนของโครงการ: โปรแกรมออกมาหรือ
ได้ผลิตภัณฑ์ออกมา
 2.1) เขียนโปรแกรมขึ้นมาใช้งานเอง
 3) แผนการดาเนินงาน 3
 3.1) ลงมือเขียนโปรแกรม 2 4
 4) ปิดโครงการ 1 5
 5) ประเมินผล

64. DEFINE PROJECT GOAL
 การกาหนดเป้าหมายของโครงการควรมุ่งเน้นไปในการก่อให้เกิดคุณค่า
ทางธุรกิจ (business value) ต่อองค์กร
 การกาหนดเป้าหมายที่ดีจะทาให้ทีมที่ทาโครงการเห็นภาพของโครงการ
ชัดเจนและขับเคลื่อนไปยังเฟสต่าง ๆ ได้อย่างถูกต้องและรวดเร็ว
 เป้าหมายหมายของโครงการควรตอบคาถามต่อไปนี้:
 เราจะรู้ได้อย่างไรว่า โครงการนี้ประสบความสาเร็จเมื่อเราให้ เวลา เงิน และ
ใส่ทรัพยากรเข้าไปแล้ว
 นอกจากนั้นโครงการต่าง ๆ ทั้งหลายมักจะมีคุณลักษณะร่วมกันดังนี้
 1) ความพยายามในเทอมของระดับของต้นทุนในการดาเนินโครงการ
และการหาคนมาทาโครงการ คือมันจะน้อยเมื่อเริ่มโครงการ และมาก
ขึ้นเมื่อดาเนินโครงการ และลดลงเมื่อโครงการเกือบเสร็จสิ้น

65.  2) ความไม่แน่นอน (uncertainty) และความเสี่ยง (risk) จะอยู่
ในระดับสูงสุดเมื่อเริ่มทาโครงการ (โอกาสที่จะประสบความสาเร็จจะต่า)
เมื่อเป้าหมายถูกกาหนดแล้วและโครงการเริ่มคืบหน้า โอกาสที่จะประสบ
ความสาเร็จจะเพิ่มขึ้น
 3) ความสามารถของผู้มีส่วนเกี่ยวข้อกับโครงการทั้งหลายในการเข้ามา
มีอิทธิพลต่อขอบเขตและต้นทุนของโครงการจะสูงสุดในช่วงเริ่มต้น
โครงการ และต้นทุนของการเปลี่ยนขอบเขตของโครงการและแก้ไข
ข้อผิดพลาดจะมีค่ามากขึ้นตามความคืบหน้าของโครงการ

66. PLAN PROJECT
 หลังจากเป้าหมายของโครงการถูกกาหนดแล้ว จะเป็นการสร้างแผนในการ
ดาเนินโครงการ แผนนีจะเป็นการตอบคาถามต่อไปนี้
้
 1) เรากาลังจะทาอะไร?
 2) ทาไมเราจะต้องทาสิ่งนั้น?
 3) เราจะทาสิ่งนั้นอย่างไร?
 4) ใครจะต้องเข้ามามีส่วนร่วมบ้าง?
 5) การทาสิ่งนั้นจะใช้เวลานานเท่าใด?
 6) การทาสิ่งนั้นขึ้นมาต้องใช้เงินเท่าใด?
 7) มีอะไรบ้างที่อาจเกิดความผิดพลาดได้และเราสามารถทาอะไรกับมันได้บาง?
้
 8) เราจะประมาณเวลาและงบประมาณในการทาสิงนั้นได้อย่างไร?
่
 9) ทาไมเราจึงตัดสินใจที่จะทาสิ่งนั้น?
 10) เราจะรู้ได้อย่างไรว่าเราทาได้สาเร็จ

67.  นอกจากนั้น สิ่งที่ต้องส่งมอบทั้งหลาย (deliverables) กิจกรรม
ต่าง ๆ (tasks) และ เวลาที่แต่ละกิจกรรมใช้ไปต้องถูกกาหนดในแต่
ละเฟสของโครงการ
 แผนตั้งต้นจะเรียกว่า baseline plan (แผนพื้นฐานที่ต้องบรรลุ)
มันจะกาหนดขอบเขต ตารางเวลา และงบประมาณที่ได้ตกลงร่วมกัน
เอาไว้ ซึ่งแผนนี้จะถูกใช้เป็นเครื่องมือในการวัดประสิทธิภาพของ
โครงการตลอดวงรอบชีวิต

68. EXECUTE PROJECT PLAN
 หลังจากเป้าหมายของโครงการและแผนของโครงการถูกกาหนดขึ้นมาเรียบร้อย
แล้ว ก็จะเป็นการนาแผนไปดาเนินงาน
 งานที่เกี่ยวข้องกับความก้าวหน้าของโครงการ ขอบเขต ตารางเวลาการทางาน
งบประมาณและผู้คนที่ทาโครงงานจะต้องถูกจัดการเพื่อมั่นใจได้ว่าโครงการจะ
บรรลุเป้าหมายที่วางไว้
 ความก้าวหน้าที่เกิดขึ้นจะต้องบันทึกเป็นเอกสารและเทียบกับ baseline
plan
 ประสิทธิภาพของการดาเนินโครงการต้องถูกสื่อสารให้ผู้มีส่วนเกียวข้องทราบ
่
 ที่จุดสิ้นสุดของเฟสนี้ ทีมต้องส่งมอบผลิตภัณฑ์ (product) (หรือ นา
ผลิตภัณฑ์นั้นมาใช้งาน) ให้แก่องค์กร

69. CLOSE PROJECT
 จากที่ได้กล่าวมาแล้วว่า โครงการต้องชัดเจนในตอนเริ่มต้นและสิ้นสุด (end)
เฟสทาการปิดโครงการมีขึ้นก็เพื่อให้มั่นใจได้ว่า งานทุกงานที่กาหนดไว้ในแผน
(หรือ ตามที่ตกลงกันระหว่างทีมผู้ทาโครงการกับสปอนเซอร์) เสร็จสิ้นสมบูรณ์
แล้ว
 ดังนั้นจึงควรจะมีการรับรู้อย่างเป็นทางการเกิดขึ้นโดยสปอนเซอร์ว่าเขาจะยอมรับ
ผลิตภัณฑ์ที่ทีมทาโครงการส่งมอบให้หรือไม่
 การปิดโครงการมักจะทาโดยทาการส่งรายงานขึ้นสุดท้าย (final report)
และการนาเสนอเอกสารที่แสดงให้เห็นว่าสิ่งที่ต้องส่งมอบที่ได้สัญญาไว้ทุก ๆ
เรื่อง (promised deliverables)ได้ดาเนินการเสร็จสิ้นแล้วตามที่ระบุ
ไว้ ให้กับผู้เกี่ยวข้องและเพื่อร่วมงานทั้งหลาย

70. EVALUATE PROJECT
 บางครั้งคุณค่าของโครงการที่เกี่ยวข้องกับ IT ยังอาจรับรู้ไม่ชัดเจนเมื่อ
ระบบถูกใช้งานในช่วงแรก เช่น เป้าหมายของโครงการในการสร้าง E-
commerce คือการก่อให้เกิดรายได้เพิ่มขึ้น ไม่ใช่เรื่องของ H/W,
S/W หรือ Web page ใด ๆ ทั้งสิ้น สมมติว่ามีรายได้เป็น
250,000 USD ภายใน 6 เดือน ในกรณีเช่นนี้จะเห็นว่า เราจะ
ประเมินโครงการนี้ว่าบรรลุเป้าหมายหรือไม่ ก็ต้องหลังจากระบบถูกใช้งาน
ไปแล้วประมาณ 6 เดือน
 โครงการอาจจะถูกประเมินในแนวทางอื่นก็ได้ เช่น การบันทึก
ประสบการณ์การทาโครงงานในเทอมของบทเรียนจากอดีต หรือ lesson
learned เพื่อใช้เป็นประโยชน์ในอนาคต

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

72. PRODUCT LIFE CYCLES
 ผลิตภัณฑ์ (Products) ก็จะมีวงรอบชีวิตเช่นกัน
 วงรอบชีวิตของการพัฒนาระบบ (Systems Development Life
Cycle (SDLC)) คือกรอบการทางานที่ใช้อธิบายระยะ(เวลา)ที่ใช้ในการ
พัฒนาและบารุงรักษาระบบสารสนเทศ
 โครงการพัฒนาระบบ (Systems development projects)
สามารถกล่าวได้ว่า มีรูปแบบดังนี้
 predictive models: ขอบเขตของโครงการสามารถกาหนดได้ชัดแจ้งและ
ตารางเวลากับต้นทุนสามารถทานายได้
 adaptive models: โครงการเป็นแบบถูกสถานการณ์บังคับ (mission
driven) และ อยู่บนพื้นฐานของส่วนประกอบ (component based) ซึ่งใช้
วงรอบของเวลามาเป็นพื้นฐานเพื่อให้สอดรับกับ target dates

73. SYSTEMS DEVELOPMENT LIFE
CYCLE (SDLC)
วางแผน วิเคราะห์ ออกแบบ นาไปปฏิบัติ บารุงรักษา
เราจะสร้างระบบอะไรขึ้นมาสักระบบหนึ่ง เช่น ระบบบัญชีที่ใช้คอมพิวเตอร์เข้าช่วย
วงรอบชีวิต หรือ วัฏจักรของการพัฒนาระบบนี้ จะเป็นดังรูปข้างบน

74. SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC)
 ดังนั้นจึงกล่าวได้ว่า SDLC ก็คือ ระยะหรือเฟส (phase) หรือ
ขั้นตอน (stage) ที่อนุกรมกันไป(sequential) ของระบบ
สารสนเทศ ที่ต้องดาเนินการต่อเนื่องกันไปตลอดอายุการใช้งาน
 ระยะ/ขั้นตอน (Phases/Stages)
 การวางแผน (Planning)
 การวิเคราะห์ (Analysis)
 การออกแบบ (Design)
 การนาไปปฏิบัติ (Implementation) (สร้างขึ้นมาแล้วนาไปใช้งาน)
 การดูแลรักษาและให้การสนับสนุน (Maintenance and Support)

75.  การวางแผน (Planning)
 ขั้นตอนการวางแผนประกอบด้วยการบ่งชี้และสนองตอบต่อ ปัญหาหรือ
โอกาส และร่วมมือกันจัดการโครงการ และกระบวนการพัฒนาระบบและ
กิจกรรมต่าง ๆ ที่เกี่ยวข้อง การมีกระบวนการวางแผนอย่างเป็นทางการ
ย่อมทาให้มั่นใจได้ว่า เป้าหมาย ขอบเขต งบประมาณ ตารางเวลา
เทคโนโลยี และเครื่องมือ กรรมวิธีการ กระบวนการพัฒนาระบบ มีอย่าง
ถูกต้องและครบถ้วนแล้ว

76.  การวิเคราะห์ (Analysis)
 ขั้นตอนนี้ เป็นการพยายามขุดลึกลงไปในปัญหาหรือโอกาสอย่างเต็มที่
ตัวอย่างเช่น กลุ่มทาโครงการได้ศึกษาระบบปัจจุบันเพื่อจัดทาเอกสารขึ้นมา
ตามที่มันเป็น (as is) เพื่อจะได้ทาความเข้าใจ แล้วทาการบ่งชี้และจัดทา
เป็นเอกสารเกี่ยวกับปัญหาใด ๆ หรือ ขีดจากัดที่มีอยู่ในระบบปัจจุบัน เป็น
การวิเคราะห์ความต้องการหรือ requirement analysis นั่นเอง
จากนันจึงทาการบ่งชี้ specific need and requirement ของ
้
ระบบใหม่ (to be system) และทาให้เป็นเอกสาร
 Requirement (ของระบบใหม่) อาจหาได้หลายทาง เช่น การ
สัมภาษณ์ผู้ใช้ การพัฒนาโปรแกรมประยุกต์ร่วมกัน (Joint
Application Development, JAD) การทาการสารวจ การ
สังเกตกระบวนการทางาน การศึกษาจากรายงานขององค์กร

77.  การออกแบบ (Design)
 ในระหว่างขั้นตอนการออกแบบ กลุ่มทาโครงการจะใช้โมเดลทางตรรกะ
ของของ “as is” และ requirement เป็นอินพุตในการออกแบบ
สถาปัตยกรรมเพื่อสนับสนุนระบบสารสนเทศระบบใหม่
 สถาปัตยกรรมใหม่นี้ประกอบด้วยการออกแบบโครงข่าย Hardware
configuration ฐานข้อมูล การเชื่อมต่อกับผู้ใช้ (User
interface) และ โปรแกรมประยุกต์ต่าง ๆ

78.  การนาไปปฏิบัติ (Implementation)
 การนาไปใช้งานประกอบด้วย การพัฒนา หรือ สร้างระบบขึ้นมา การ
ทดสอบ และ การติดตั้ง ทั้งนี้รวมถึง การฝึกอบรม การให้การสนับสนุน และ
การจัดทาเอกสารต่าง ๆ

79.  การดูแลรักษาและให้การสนับสนุน (Maintenance and
Support)
 เมื่อระบบถูกใช้งาน การเปลี่ยนแปลงใด ๆ ที่เกิดกับระบบ เช่น การดูแล
รักษาและปรับปรุงให้ดีขึ้นมักถูกร้องขอให้ดาเนินการ เช่น การแก้ไข
ข้อบกพร่อง เป็นต้น หรือ การเพิ่มเติมลักษณะบางสิ่งบางอย่างเพิ่มเติม
จากเดิม หรือ เกิดการปรับเปลี่ยนสภาพแวดล้อมทางธุรกิจ เป็นต้น
 ส่วนการสนับสนุนอาจอยู่ในรูปของ Call Center หรือ
Helpdesk เพื่อช่วยผู้ใช้งานสามารถใช้งานได้ตามที่เขาต้องการ
(as need basis)

80. IMPLEMENTING SDLC:
STRUCTURED APPROACHES TO SYSTEMS
DEVELOPMENT
วิธีการลดหลันแบบน้าตก (Waterfall Method)
่
Waterfall model มีการกาหนดๆ ไว้เป็นอย่างดี มีขั้นตอนแบบเชิงเส้นในการพัฒนาระบบและ
การให้การสนับสนุน เรียกแนวทางนีวา แนวทางเชิงเส้น (linear approach)
้่
80

81. WATERFALL METHOD
Define
Requirements
Design
Build
Test
Implement
Maintenance

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.  การพัฒนาระบบแบบคล่องตัว (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. V-SHAPED SDLC MODEL

85. INCREMENTAL SDLC MODEL

86. SPIRAL SDLC MODEL

87. THE PLC VS. THE SDLC

88. ความสัมพันธ์ระหว่าง PLC และ SDLC
 จากรูปจะเห็นว่า วงรอบชีวิตของการพัฒนาระบบ (systems
development life cycle (SDLC)) กลายเป็นส่วนหนึงของ ่
วงรอบชีวิตของโครงการ (project life cycle (PLC))
 PLC เน้นที่ เทคนิค เครื่องมือ กระบวนการ เฟสต่าง ๆ ในการบริหารโครงงาน
เพื่อให้การบริหารโครงงานเป็นไปอย่างมีประสิทธิผล
 SDLC เน้นที่เทคนิค เครื่องมือ กระบวนการ เฟสต่าง ๆ ในเชิงวิศวกรรม
ซอฟต์แวร์เพื่อสร้าง IT Solution และ/หรือนาไปปฏิบัติ (ใช้งาน)
 ถ้า SDLC คือ คนงานที่ก่อสร้างบ้านแล้ว PLC ก็คือผู้คุมงานนั่นเอง

89. ผู้คุมงาน (บริหารโครงการ) กับ คนงาน (บริหารแรงงาน)

90. EXTREME PROJECT MANAGEMENT (XPM)
 ปรัชญาและแนวทางใหม่ของการบริหารโครงการที่เริ่มได้รบความนิยมมากขึ้น
ั
 โดยมองในเชิงลักษณะที่มีความหลากหลายของโครงการในปัจจุบัน จะเห็นว่า
ต้องการ ความเร็วในการทาให้โครงการสาเร็จเร็วขึ้น โครงการมีความไม่แน่นอน
มากขึ้น มีความต้องการในการเปลี่ยนแปลงมากขึ้น มีความเสี่ยงมากขึ้น
 การบริหารโครงการแบบดั้งเดิมใช้แนวทางดาเนินการแบบเรียงลาดับกันไป
ในขณะที่ XPM ยืนอยู่บนพืนฐานที่ว่าโครงการมักไร้ระเบียบ (chaotic)
้
และ คาดการได้ยาก (unpredictable) ดังนั้น XPM จึงเน้นที่ความ
คล่องตัว การปรับตัวและนวัตกรรม
 การใช้ทั้งแบบดั้งเดิมและแบบใหม่ร่วมกันทาให้เข้าใจโครงงานได้ดีขึ้น ส่งผลให้
รู้ว่าจะทาอย่างไรโครงการจึงมีโอกาสสาเร็จมากขึ้น

91. WHY HAVE PROJECT PHASES AND
MANAGEMENT REVIEWS?
 โครงงานควรประสบผลสาเร็จในแต่ละ
เฟส เมื่อเฟสแรกสาเร็จแล้ว จึงลงมือทาใน
เฟสถัดไป
 Management reviews (บางที
เรียกว่า “phase exits” หรือ “kill
points”) อาจเกิดขึ้นหลังจากแต่ละเฟส
ถูกประเมินถึงความคืบหน้าของโครงการ
(โอกาสที่น่าจะประสบความสาเร็จ) และ
ยังคงสอดรับกับ organizational
goals

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. PMBOK

94. PROJECT MANAGEMENT KNOWLEDGE AREAS

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)

98.  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)

99.  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)

100.  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)

101.  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)

102. 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).

103. 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).

104. จบหัวข้อ 1