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

Project and Change Management
ผูส้ อน: พนม เพชรจตุพร
อาจารย์ประจาภาควิชาวิศวกรรมระบบวัดคุม
1
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.
Score





Homework 20%
Midterm 30%
Examination 50%
Note:
It may be changed if anyone has a good suggestion.
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)
Content of Text Book (2)










Chapter 6: โครงสร้างของการแยกย่อยงาน
(The Work Breakdown Structure (WBS))
Chapter 7: งบประมาณและแผนเวลาทางานของโครงการ
(The Project’s Schedule and Budget)
Chapter 8: การวางแผนจัดการความเสี่ ยงของโครงการ
(The Risk Management Plan)
Chapter 9: การวางแผนสื่ อสารภายในโครงการ
(The Project Communication Plan)
Chapter 10: การวางแผนคุณภาพของโครงการเกี่ยวกับ IT
(The IT Project Quality Plan)
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.
Information Technology Project Management
by Jack T. Marchewka
7
Chapter 1:
ทบทวนเรื่ องของการจัดการโครงการ IT
(An Overview of IT Project Management)
8
Chapter 1 Objectives
 อธิ บายถึงยุคที่เด่นๆของระบบสารสนเทศที่เรี ยกกันว่า ยุคการประมวลผลข้อมูลแบบ
อิเล็กทรอนิคส์ (electronic data processing (EDP) ยุคไมโคร ยุคโครงข่าย และยุค
โลกาภิวฒั น์ และทาความเข้าใจถึงวิธีการจัดการกับโครงการด้าน IT ในยุคต่าง ๆ
ข้างต้นได้อย่างไร
 ทาความเข้าใจสภาวการณ์ปัจจุบนั เกี่ยวกับการจัดการโครงการด้าน IT และการประสบ
ความสาเร็ จในการจัดการโครงการด้าน IT ยังคงมีความท้าทายต่อองค์กรต่าง ๆ อย่างไร
 อธิบายถึงการใช้แนวทาง value-driven, socio-technical, project management และ
knowledge management ที่สนับสนุน ITPM.
 นิยามว่าโครงการ (project) คืออะไรและอธิบายถึงคุณลักษณะของโครงการ
 กาหนดวินยั ในการทาโครงการที่เรี ยกว่า การจัดการโครงการ (project management)
 อธิบายบทบาทและผลกระทบของโครงการ IT ที่มีต่อองค์กร
 บ่งชี้ความแตกต่างและความสนใจของผูม้ ีส่วนเกี่ยวข้องกับโครงการ (project
stakeholder)
 อธิ บายแนวทางที่มกั ใช้กนั ในการพัฒนาระบบอย่างเป็ นโครงสร้างและการพัฒนา
ระบบแบบทาซ้ า ๆ (iterative systems development)
 อธิบายวงรอบชีวิตของโครงการ (project life cycle (PLC)) วงรอบชีวิตในการ
พัฒนาระบบ ( systems development life cycle (SDLC)) และความสัมพันธ์
ระหว่างกัน
 อธิ บายถึงการจัดการโครงการแบบสุ ดขั้ว (extreme project management)
 บ่งชี้ Project Management Body of Knowledge (PMBOK®) ในส่ วนที่แกนหลัก
Project Management Body of Knowledge (PMBok)
Introduction
IT and Modern Day Project Management
1940s
First
Electronic
Computer
1950s
1960s
EDP
Era
1970s
PC
Era
1980s
1990s
Network
Era
2000s
2010s
Globalization
Introduction
 โครงการเกี่ยวกับ IT (Information Technology (IT) projects) ถือเป็ นการลงทุนของ
องค์กรที่ตอ้ งการ
 เวลา (Time)
 เงิน (Money)
 และทรัพยากรอื่น ๆ เช่น ผูค้ น เทคโนโลยี ส่ วนสนับสนุน และอื่น ๆ
 ดังนั้นองค์กรจึงคาดหวังว่ามันต้องมีคุณค่าบางสิ่ งบางอย่างกลับคืนมาหลังจากการ
ลงทุน
 ดังนั้นการจัดการโครงการเกี่ยวกับ IT จะสัมพันธ์กบั วินยั ในการทางานใหม่ ๆ อัน
นามาใช้เพื่อทาให้โครงการเกี่ยวกับ IT ประสบความสาเร็ จมากขึ้น โดยนามาใช้
ร่ วมกับการจัดการกับโครงการแบบทัว่ ๆ ไปซึ่ งอาศัย Software Engineering/
Management Information Systems
An ITPM Approach
 เนื่องจากทรัพยากรขององค์กรมีจากัด ดังนั้นองค์กรจึงต้องเลือกเอาระหว่างสิ่ งที่
องค์กรสนใจเทียบกับเงินทุนที่ตอ้ งใช้ในโครงการต่าง ๆ
 การตัดสิ นใจจะตั้งอยูบ่ นคุณค่าของโครงการต่าง ๆ ที่มีให้กบั องค์กร ที่เสนอขึ้นมา
ให้คดั เลือก
 สถานการณ์ใดแย่กว่ากัน
 การประสบความสาเร็ จในการสร้างระบบขึ้นมาและนามาใช้งาน แต่ให้คุณค่าแก่องค์กร
เล็กน้อยหรื อไม่มีเลย?
หรื อ…
 ล้มเหลวในการนาระบบสารสนเทศ (information system) มาใช้งาน ซึ่งระบบนี้ให้คุณค่า
แก่องค์กรแต่กาลังพัฒนาอยู่ ยังไม่แล้วเสร็ จ หรื อ มีการจัดการที่แย่?
Advantages of Using Formal Project Management









สามารถควบคุม financial, physical, และ human resources ได้ดีข้ ึน
ความสัมพันธ์กบั ลูกค้า ถูกปรับปรุ งให้ดีข้ ึน
เวลาที่ใช้พฒั นาลดน้อยลง
ต้นทุนต่าลง
คุณภาพและความวางใจได้เพิ่มสู งขึ้น
ผลกาไรสู งขึ้น
ผลิตผลถูกปรับปรุ งให้ดีข้ ึน
การประสานงานภายในดีข้ ึน
อารมณ์ร่วมในการ(อยาก)ทางานสู งขึ้น
The State of IT Project Management
 โดยการศึกษาของ Standish Group ผ่านทางการสารวจผูจ้ ดั การ IT 365 คนเมื่อปี 1994
การศึกษานี้เรี ยกว่า CHAOS แล้วได้ออกรายงานออกมาว่า
 มีเพียง 16% ของโครงการพัฒนาโปรแกรมประยุกต์ที่ประสบความสาเร็ จในเทอมที่
ทันเวลาที่กาหนดและอยูใ่ นงบประมาณที่กาหนด
 31% ของโครงการถูกยกเลิกก่อนที่โครงการจะแล้วเสร็ จ
 53% ของโครงการแล้วเสร็ จก็จริ ง แต่เกินเวลาที่กาหนด เกินงบประมาณ และไม่บรรลุ
ข้อกาหนดตามที่กาหนดไว้แต่แรก
 จากการสารวจยังพบว่าบริ ษทั ขนาดกลางเมื่อทาโครงการแล้ว ได้ใช้งบประมาณเกินไป
จากการคาดการณ์ในตอนต้นก่อนเริ่ มโครงการ เฉลี่ยแล้วประมาณ 182% และใช้เวลา
เกินที่กาหนดไว้เฉลี่ยแล้วประมาณ 202%
 นัน่ หมายความว่า โครงการขนาดกลางกาหนดไว้ก่อนทาโครงการว่าจะใช้เงิน
ประมาณ 1 ล้านเหรี ยญ ใช้เวลาประมาณ 1 ปี แต่เมื่อโครงการเสร็ จสิ้ นแล้ว ใช้เงินไป
ประมาณ 1.8 ล้านเหรี ยญและใช้เวลาไปถึง 2 ปี
 ทาไมโครงการเกี่ยวกับ IT ถึงล้มเหลว?
 โครงการขนาดใหญ่มีอตั ราการประสบความสาเร็ จน้อยกว่าโครงการขนาดกลางและ
ขนาดเล็ก และมีความเสี่ ยงมากกว่า
 การเปลี่ยนแปลงอย่างรวดเร็ วของ เทคโนโลยี ตัวแบบทางธุรกิจ (business
models) และตลาด ทาให้โครงการที่ใช้เวลานานกว่าหนึ่ งปี ถูกยกเลิกก่อนที่จะแล้ว
เสร็ จ
ทาไมโครงงานถึงล้มเหลว? ในภาพกว้าง ๆ
ใช้งบประมาณเกินกาหนด (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)




Figure 1.1 - Summary of the Chaos Studies from 1994 to 2006
Has the Current State of IT Projects Changed Since 1994?
 Standish Group ได้ศึกษาโครงการ IT อย่างต่อเนื่องมาหลายปี พบว่า เมื่อกล่าวกว้าง
ๆ จะเห็นว่าโครงการเกี่ยวกับ IT มีอตั ราความสาเร็ จสู งขึ้น อันเนื่องมาจาก
 มีกระบวนการและเครื่ องมือในการจัดการกับโครงการดีข้ ึน
 โครงการต่าง ๆ มีขนาดเล็กลง
 การสื่ อสารระหว่างผูม้ ีส่วนเกี่ยวข้องทั้งหลาย (stakeholder) ได้รับการปรับปรุ ง
 ผูจ้ ดั การโครงการเกี่ยวกับ IT มีทกั ษะและความชานาญมากขึ้น
 แต่อย่างไรก็ตาม มันยังมีโอกาสในการปรับปรุ งให้ดีข้ ึนอีกมาก
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
Support
User Involvement
Executive Management
Support
3
Clear Statement of
Requirements
Experienced Project
Manager
Clear Business Objectives
4
Proper Planning
Clear Business Objectives
Optimizing Scope
5
Realistic Expectations
Minimized Scope
Agile Process
6
Smaller Project Milestones
Standard Software
Infrastructure
Project Management
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
แล้วปี 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” เป็ นดังตารางในหน้าถัดไป
Table 1.2: Project Performance and Internal/External Customer Satisfaction.
Source: Marchewka, J.T. (2008). n = 114.
IT Project
Performance
Over the Past
3 Years
Much
Worse
Worse
Same
Better
Much
Better
Ability to meet
project
schedules
0.0%
12.3%
40.4%
41.2%
6.1%
Ability to meet
project
budgets
1.8%
10.5%
44.7%
37.7%
5.3%
Ability to
complete
project scope
or system
requirements
2.6%
7.0%
41.2%
41.2%
7.9%
Overall
satisfaction of
the customer
1.8%
13.2%
34.2%
39.5%
11.4%
0.0%
9.6%
39.5%
38.6%
12.3%
0.9%
3.5%
42.1%
38.6%
14.9%
Customer
satisfaction
over the past 3
years
Perceived
(Customers
value of the
can be internal
delivered
– e.g., HR
product to the
department or
customer
external – e.g.,
a particular
client)
Potential for
future work
with the
customer
Why IT Projects Fail
 เหตุผลหนึ่งที่ทาให้โครงการเกี่ยวกับ IT ล้มเหลวในอัตราที่สูง ก็คือ การนิยามการ
“ประสบความสาเร็ จ (Success)” หรื อ “ล้มเหลว (Failure)” ตามนิยามของ CHAOS
ได้นิยามว่า โครงการใด ๆ ก็ตาม แม้วา่ จะสร้างคุณค่าให้แก่องค์กรอย่างมากมาย แต่
ถ้าเกินงบประมาณหรื อเวลาที่กาหนด จะถือว่า “ล้มเหลว”ทั้งสิ้ น
 จากการศึกษาของ CHAOS ได้ผลออกมาน่าสนใจดังตารางในหน้าถัดไป มันเป็ น
การบอกถึงปั จจัยที่ทา้ ทายของโครงการอันก่อให้เกิดปั จจัยแห่ งความล้มเหลว เช่น
อินพุตจากผูใ้ ช้ไม่พอเพียง หรื อ ขาดการมีส่วนร่ วมของผูใ้ ช้ ทาให้ทีมที่ทาโครงการ
เสี ยเวลาในการทาความเข้าใจว่าผูใ้ ช้ตอ้ งการอะไร เสี ยเวลาในการกาหนดความ
ต้องการของโครงการ ท้ายที่สุดก็จะเกิดข้อขัดแย้งระหว่างผูพ้ ฒั นาโปรแกรมและ
ผูใ้ ช้ เป็ นต้น
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
 จากการทาโพลผ่านทางเวบของ Computing Technology Industry Association
(CompTIA) จากจานวนผูต้ อบประมาณ 1,000 ราย มี
 28% กล่าวว่าการสื่ อสารที่แย่เป็ นสาเหตุที่ทาให้โครงการล้มเหลว
 18% กล่าวว่าทรัพยากรไม่พอเพียงก่อให้เกิดความล้มเหลว
 13.2% กล่าว่าการกาหนดเส้นตายที่ไม่เป็ นไปตามความจริ ง ทาให้โครงการ
ล้มเหลว
 ในแง่ของการสื่ อสาร ตารางในหน้าถัดไปได้แสดงปั จจัยที่เกี่ยวข้องกับความท้า
ทายและความล้มเหลวของโครงการในแง่ของการสื่ อสารทั้งทางตรงและทางอ้อม
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
None
Looked for a scapegoat among IT staff
Sought compensation from IT vendors
Reluctant to fund new IT projects
Reduced IT budgets
Tend to accept problems as the norm (i.e., a necessary evil)
Continued to provide support to improve IT
1%
2%
9%
13%
19%
21%
43%
69%
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) ผ่านทาง





กระบวนการต่าง ๆ และโครงสร้าง
ทรัพยากรต่าง ๆ
ความคาดหวัง
การแข่งขัน
ประสิ ทธิภาพและประสิ ทธิผล
 ใช้แนวทางการบริ หารองค์ความรู ้ (Knowledge Management Approach)
 บทเรี ยนจากอดีต (lesson learned)
 การปฏิบตั ิงานที่เป็ นเลิศ (best practices) และ
 การแบ่งปั นความรู ้ (Knowledge Sharing)
Top IT Projects
The Context of Project Management
 คานิยามของ “โครงการ (Project)”
 โครงการ (project) คือ การรวมตัวกันชัว่ คราวเพื่อพยายามดาเนินการให้บรรลุ
เป้าประสงค์เรื่ องใดเรื่ องหนึ่งที่ชดั เจน
 ดังนั้น การบริ หารโครงการจึงหมายถึง การประยุกต์ใช้องค์ความรู ้ ทักษะ เครื่ องมือ
ต่าง ๆ และ เทคนิคต่าง ๆ กับการดาเนินโครงการ เพื่อให้ได้ผลตาม ความต้องการ
หรื อความคาดหวัง (หรื อดีกว่า) จากโครงการหนึ่ง ๆ โดยผูเ้ กี่ยวข้องทั้งหลาย
 ลองนึกซิ ครับว่า งาน (ที่เราทากันอยูท่ ุก ๆ วัน) จะเรี ยกว่า โครงการได้หรื อไม่ ?!?
ถ้าไม่ได้ แล้วโครงการจะต้องมีลกั ษณะ (attribute) อะไรที่แสดงให้เราเห็น เพื่อใช้
แยกแยะความแตกต่างได้ (เราเรี ยกว่า Project Attribute)





การจัดการกับโครงการจะประกอบด้วย:
การบ่งชี้ถึงความต้องการต่าง ๆ
กาหนดเป้าประสงค์ที่สามารถบรรลุได้และชัดเจน
สมดุลความต้องการในแง่ของคุณภาพ ขอบเขต เวลา และงบประมาณ
ปรับข้อกาหนดเฉพาะ แผนการ และแนวทางต่าง ๆ ให้เข้ากับความต้องการและ
ความคาดหวังที่แตกต่างกันของผูม้ ีส่วนเกี่ยวข้องกับโครงการที่มหี ลากหลาย
The Context of Project Management
ลักษณะของโครงการ (Project Attributes):





มีกรอบเวลา (Time Frame)
มีวตั ถุประสงค์ (Purpose) เพื่อก่อให้เกิดคุณค่าต่อองค์กร
มีความเป็ นเจ้าของ (Ownership)
มีทรัพยากร (Resources) (เป็ นไปตามข้อจากัดสามข้อ)
มีหน้าที่รับผิดชอบ (Roles)
 ผูจ้ ดั การโครงการ (Project Manager)
 สปอนเซอร์ของโครงการ (Project Sponsor)
 SME (Domain & Technical)
 มีความเสี่ ยงและสมมุติฐาน (Risks & Assumptions)
 มีกิจกรรมที่อิสระจากกัน (Interdependent tasks)
 เคลื่อนไปข้างหน้าอย่างรอบคอบ: มีหลายขั้นตอนแต่กา้ วไปที่ละขั้น
 มีการวางแผนปรับเปลี่ยนองค์กร (Planned Organizational change)
 ทางานในสภาพแวดล้อมที่ใหญ่กว่าตัวโครงการเองในการทางาน (Operate in
Environments Larger than the Project Itself)
คุณลักษณะของโครงการ (Project Characteristics)
 มีวตั ถุประสงค์ที่เจาะจง ชัดเจน (ซึ่ งอาจเป็ นเรื่ องเดียว (unique) หรื อ ประเภทใด
ประเภทหนึ่ง ก็ได้) สามารถดาเนินการให้เสร็ จสิ้ นภายในข้อกาหนดที่ชดั เจน
แน่นอน
 มีการกาหนดวันเริ่ มต้นและวันสิ้ นสุ ด
 มีการกาหนดวงเงินที่ตอ้ งใช้จ่าย (ถ้าเป็ นไปได้)
 ใช้ทรัพยากรทั้งที่เป็ นคนและไม่ใช่ (เช่น เงิน เครื่ องจักร เทคโนโลยี)
 เป็ นแบบหลายฟังก์ชนั (multifunctional) (cut across several functional lines)
ความแตกต่างระหว่างการบริ หารโครงการกับการบริ หารทัว่ ไป






การบริหารโครงการ
มีลกั ษณะพิเศษ ไม่ซ้ ากับโครงการอื่นใด
มีระยะเวลาที่แน่นอน
เกี่ยวข้องกับการเปลี่ยนแปลงขนาดใหญ่
สภาพการดาเนินงานไม่คงที่สม่าเสมอ
ให้น้ าหนักแก่วตั ถุประสงค์ไม่เท่ากัน เพื่อ
ก่อให้เกิดการเปลี่ยนแปลงไปจากสภาพเดิม
 สร้างกลุ่มทีมงานชัว่ คราวขึ้นมาดาเนินการ






การบริหารทัว่ ไป
มีลกั ษณะซ้ า ๆ กันเป็ นกิจวัตร
มีระยะเวลาไม่สิ้นสุ ด
เกี่ยวข้องกับการเปลี่ยนแปลงแบบค่อย ๆ ไป
สภาพการทางานมีลกั ษณะคงที่ สม่าเสมอ
ให้น้ าหนักแก่วตั ถุประสงค์เท่ากัน เพื่อรักษา
สภาพเดิม
 สร้างกลุ่มทีมงานถาวรขึ้นมาดาเนินการ
วัฒนธรรมในการบริ หารก็ต่างกัน
ข้อจากัดสามข้อ (The Triple Constraint)
 ทุก ๆ โครงงานจะถูกข้อจากัดของตัวมันเข้ามาบีบ ได้แก่:
 เป้าหมายเรื่ องขอบเขต (Scope goals): อะไรคือสิ่ งที่โครงงานต้องบรรลุ
 เป้าหมายเรื่ องเวลา (Time goals): ใช้เวลานานเท่าใดจึงจะสาเร็ จ
 เป้าหมายเรื่ องงบประมาณ (Cost goals): ใช้ตน้ ทุนเท่าใด
 มันจึงถือเป็ นหน้าที่ของผูบ้ ริ หารโครงการต้องสมดุลระหว่างสามเรื่ องนี้เพื่อให้
บรรลุเป้าหมายที่ต้ งั ไว้
The Triple Constraint
ขอบเขตบาน
Figure 1.2
เวลาเกิน
งบเกิน
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.
แฟกเตอร์ ที่เกี่ยวข้องกับวัฒนธรรม (The Culture Factor)
 ความสัมพันธ์ที่ดีระหว่างการทางานรายวัน (daily working) กับ ผูบ้ ริ หารโครงการ
(project manager) และ ผูบ้ ริ หารแผนก (line managers) ผูซ้ ่ ึ งมีหน้าที่กาหนด
ทรัพยากรต่าง ๆ ลงไปในโครงงาน
 ความสามารถของ functional employees ในการรายงานตามสายบังคับบัญชาไปยัง
line manager ของเขา (ถือเป็ นแนวตั้ง) และเขายังต้องรายงานไปยังผูบ้ ริ หารโครงการ
หนึ่งคนหรื อมากกว่า (ถือเป็ นแนวนอน)
Functional Manager
Project Manager 1
Project Manager 2
ทรัพยากรของโครงการ (Project Resources)






เงิน
คนงาน (Manpower)
เครื่ องมือ
สิ่ งอานวยความสะดวก
วัตถุดิบ (Materials)
สารสนเทศ/เทคโนโลยี
อุปสรรคกีดขวางต่อโครงการ (Project Obstacles)






ความซับซ้อนของโครงการ (Project complexity)
ความต้องการพิเศษของลูกค้า และ การเปลี่ยนขอบเขตของโครงการ
การเปลี่ยนแปลงโครงสร้างขององค์กร
ความเสี่ ยงของโครงการ (Project risks)
การเปลี่ยนแปลงของเทคโนโลยี (Changes in technology)
การวางแผนและการคานวณราคาล่วงหน้า (Forward planning and pricing)
ผูเ้ กี่ยวข้องกับโครงการ





ผูเ้ กี่ยวข้อง(มีส่วนได้ส่วนเสี ย)กับโครงการ (Project Stakeholders)
ผูบ้ ริ หารโครงการ (Project Manager)
ผูใ้ ห้การสนับสนุนหรื อสปอนเซอร์ของโครงการ (Project Sponsor)
เรื่ องที่เกี่ยวข้องกับผูช้ านาญการ (Subject Matter Expert(s) (SME))
ผูช้ านาญด้านเทคนิค (Technical Expert(s) (TE))
ผูม้ ีส่วนได้ส่วนเสี ยกับโครงการ (Project Stakeholders)
 ผูม้ ีส่วนได้ส่วนเสี ย หรื อ Stakeholders คือ ผูท้ ี่เข้าไปเกี่ยวข้องหรื อได้รับผลกระทบ
จากการดาเนินโครงการ
 ผูม้ ีส่วนได้ส่วนเสี ย (Stakeholders) ประกอบด้วย
 สปอนเซอร์ของโครงการ (Project sponsor) และ ทีมที่ทาโครงการ (Project
team)
 ฝ่ ายสนับสนุน (support staff)
 ลูกค้าต่าง ๆ (customers)
 ผูใ้ ช้งาน (users)
 ซัพพลายเออร์ (suppliers)
 ผูอ้ ยูต่ รงข้ามกับโครงการ (opponents to the project)
บทบาทของผูบ้ ริ หารโครงการ (Project Manager Roles)
 จัดให้มีการประชุมครั้งแรก หรื อ Kick off Meeting
 จัดตั้งนโยบายของโครงงาน (project policies) และ ระเบียบปฏิบตั ิต่าง ๆ (procedures)
 ออกแบบแผนในการดาเนินโครงการ (project plan) และ ผังการไหลของงานที่ตอ้ งทา
ในโครงงาน (workflow)
 ขอเงินทุนสนับสนุน (Obtaining funding)
 ดาเนินการตามแผน (Executing the plan)
 ทาตัวเหมือนผูป้ ระสานงานในโครงการ (project facilitator)
 แก้ไขปั ญหา (Putting out fires)
บทบาทของผูบ้ ริ หารโครงการ (Project Manager Roles)
จัดหาสมาชิกของกลุ่ม
ผลักดันให้กลุ่มมุ่งเน้นอยูท่ ี่เส้นตายต่าง (deadlines)
MBWA – Manage by walking around
ทาการประเมินประสิ ทธิ ภาพ (Evaluating performance)
พัฒนาแผนที่ใช้จดั การกับสถานการณ์ไม่แน่นอนที่อาจเกิดขึ้นได้ (Developing
contingency plans)
 การสรุ ปเรื่ องต่าง ๆ ให้ project sponsor, customer และ team ฟัง
 การปิ ดโครงการ





การบริ หารแบบเดิมที่ตอ้ งใช้ (Classical Management)







การวางแผน (Planning)
การจัด(กลุ่ม)คนทางาน (Organizing)
การจัดหาบุคลากร (Staffing)
การสั่งการ (Directing)
การควบคุมให้เป็ นไปตามแผน (Controlling)
เรามักเขียนย่อ ๆ ว่า POSDC
Which of the above is Usually NOT performed by the project manager?
ทักษะเฉพาะตนที่ควรมี
สปอนเซอร์ของโครงการ (The Project Sponsor)
 เป็ นหัวหน้าในการให้สนับสนุนโครงการ
 Sponsor อาจอยู/่ ไม่อยูใ่ นกลุ่มผูบ้ ริ หารระดับสู งก็ได้
 ฟังก์ชนั ของสปอนเซอร์ คือสนับสนุนในเรื่ องต่าง ๆ
ที่เกี่ยวข้อง (run interference)
ผูช้ านาญการ (The Experts)
 ผูช้ านาญที่เกี่ยวข้องกับเรื่ องสาคัญ ๆ ที่เกี่ยวข้องกับโครงงาน (Subject Matter Expert(s)
(SME))
 ผูช้ านาญด้านเทคนิค (Technical Expert(s) (TE))
 โดยทัว่ ไปแล้ว ทั้งสองส่ วนนี้อาจได้มาจากแผนกหรื อพื้นที่ต่าง ๆ ในองค์กรซึ่ งทางาน
อยูภ่ ายใต้ functional manager และจะกลายเป็ นสมาชิกของกลุ่มที่รับผิดชอบในการทา
โครงการภายใต้การดูแลของผูบ้ ริ หารโครงการจนกระทัง่ โครงการแล้วเสร็ จ
บทบาทของผูบ้ ริ หารเชิงฟังก์ชนั (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.)
อุปสรรคกีดขวางเชิงฟังก์ชนั (Functional Obstacles)
การร้องขอให้ทางานอย่างไม่มีขีดจากัด (Unlimited work requests)
มีเส้นตาย (deadline) ที่กาหนดไว้ก่อนแล้ว (Predetermined deadlines)
การร้องขอทั้งหมดล้วนแล้วแต่มีลาดับความสาคัญสู ง (high priority) ทั้งสิ้ น
ทรัพยากรต่าง ๆ มีจานวนจากัด (จานวนทรัพยากร)
ทรัพยากรมีให้ใช้อย่างจากัด (ประเภทของทรัพยากร)
มีการเปลี่ยนแปลงโดยไม่ได้กาหนดไว้ในตารางของแผนในการทาโครงการ
(project plan)
 เกิดความล่าช้าโดยไม่ได้คาดหมายล่วงหน้า (Unpredicted lack of progress)
 ไม่ได้วางแผนเอาไว้ในกรณี ที่ขาดแคลนทรัพยากร (เช่น แรงงานหยุดงาน)






อุปสรรคกีดขวางเชิงฟังก์ชนั (Functional Obstacles)
 ไม่ได้วางแผนเอาไว้ในกรณี ที่ทรัพยากรใช้งานไม่ได้ (เช่น เครื่ องจักรชารุ ดเสี ยหาย)
 ไม่ได้วางแผนเอาไว้ในกรณี ที่สูญเสี ยทรัพยากร (เช่น พนักงานลาออกจานวนมาก)
 ไม่ได้วางแผนเอาไว้ในเรื่ องของ turnover พนักงาน (เช่น พนักลาออกไป รับพนักงาน
ใหม่เข้ามา ต้องเสี ยเวลาในการอบรมนานจนกว่าจะเป็ นงาน)
ยาแก้คือ การวางแผนที่ดี (The Antidote: Good Planning)
 ถ้าการวางแผนทาได้ดีแล้ว ผลดีจะเกิดขึ้นหลายเรื่ อง เช่น
 Functional units จะเข้าใจความรับผิดชอบของเขาว่าในการที่จะให้โครงการสาเร็ จ
นั้น จาเป็ นต้องใช้อะไรบ้าง (รู ้วา่ โครงการต้องการอะไร)
 ปั ญหาต่าง ๆ ที่เกิดจากการกาหนดเวลาและการเคลื่อนย้ายทรัพยากรที่วิกฤติจะถูก
รับรู ้ล่วงหน้า (ก่อนที่มนั จะเกิดปั ญหา)
 มีการระบุถึงปั ญหาแต่เนิ่น ๆ ทาให้การกาหนดแนวทางการแก้ปัญหาทาได้อย่างมี
ประสิ ทธิ ภาพ และ ทาปรับแผนเพื่อป้องกันหรื อแก้ไขปั ญหานั้น ๆ ได้อย่างเหมาะสม
ข้อกาหนดของแผนโครงการ (Project Plan Requirements)
 กาหนดงานต่าง ๆ ที่ตอ้ งทาอย่างครบถ้วน
 กาหนดความต้องการของทรัพยากร (และรวมถึงกาหนดระดับของทักษะที่
ต้องการ)
 หมายกาหนดการทางด้านเวลา (timetable milestones) หลัก ๆ
 กาหนดคุณภาพของผลลัพธ์ทา้ ยสุ ดที่ตอ้ งการรวมไปถึงความเชื่อถือ (หรื อ ความ
วางใจได้ของผลลัพธ์ของงานที่ทาออกมา)
 พื้นฐานของการวัดประสิ ทธิ ภาพ (จาไว้วา่ ไม่วดั ก็ไม่ถูกรับรู ้ เมื่อไม่รู้กไ็ ม่มีการ
แก้ไข ปรับปรุ ง)
ความเสี่ ยงและสมมติฐาน (Risks & Assumptions)
 Risk หรื อ ความเสี่ ยงต่าง ๆ มักจะถูกละเลย ความเสี่ ยงจะแยกเป็ น
 ภายใน (Internal)
 ภายนอก (External)
 สมมติฐานต่าง ๆ (Assumptions)
ความเสี่ ยงที่อยูภ่ ายในองค์กร (Internal Risks)







ท่านสัญญาในสิ่ งที่ทาไม่ได้หรื อไม่ ?
ใครคือศัตรู ของโครงการของท่าน ?
ใครคือผูป้ ระเมินสมาชิกของกลุ่ม ?
ใครคือผูค้ วบคุมงบประมาณของโครงการของท่าน ?
ใครคือผูก้ าหนดสมาชิกของกลุ่ม(ว่าเป็ นคนนั้นคนนี้)ของโครงการของท่าน ?
ท่านมีการใส่ (กาหนด) อินพุตเข้าไปในสัญญา (contract) หรื อไม่ ?
มี RFP (Request for Pricing) เป็ นส่ วนหนึ่งของสัญญา (contract) หรื อไม่ ?
ความเสี่ ยงที่อยูภ่ ายนอกองค์กร (External Risks)





เทคโนโลยีจะเปลี่ยนแปลงก่อนที่โครงการของท่านจะเสร็ จสิ้ นหรื อไม่ ?
ผูว้ า่ จ้างจะมีการฟ้องร้องเพื่อบังคับให้ทาตามสัญญาหรื อไม่ ?
มีใครที่อยูใ่ น client staff ต้องการให้โครงการของคุณล้มเหลวหรื อไม่ ?
การเปลี่ยนแปลงที่เกิดขึ้นมีการบริ หารอย่างไร ?
มีผใู ้ ช้งาน(หลังจากโครงงานนี้ เสร็ จสิ้ น)เป็ นปรปั กษ์กบั โครงการนี้ หรื อไม่ ?
สมมติฐาน (Assumptions)
 ท่านมีสมมติฐานต่าง ๆ มากกว่าข้อเท็จจริ งเมื่อพิจารณาของการของท่านหรื อไม่ ?
 สมมติฐานข้างต้นมาจากตัวท่านเองหรื อเจ้านายให้ท่านมา ?
การรายงาน (Reporting)
 ผูบ้ ริ หารโครงการจาเป็ นต้องรายงาน(อย่างเที่ยงตรงและเจาะจง)ไปยังผูบ้ ริ หารระดับสู ง
ขึ้นไปในกรอบเวลาที่กาหนดและใช้เวลาอย่างเหมาะสม
 ลูกค้าย่อมมีความรู ้สึกที่ดีถา้ รายงานของผูบ้ ริ หารโครงการของเขาส่ งถึงมือผูบ้ ริ หาร
ระดับสู งด้วย
 การจัดวางบรรดาผูบ้ ริ หารโครงการมือใหม่ (junior project manager) เอาไว้ในตาแหน่ง
ที่อยูใ่ นระดับสู งขององค์กร จะทาให้เกิดความบาดหมางในระดับ senior functional
executives ซึ่ งต้องให้การสนับสนุน
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
นิยาม (Definitions)




วงรอบชีวิตของโครงการ (Project Life Cycle (PLC))
สิ่ งที่ตอ้ งส่ งมอบ (Deliverable)
Phase exits, stage gates, or kill points
Fast tracking
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)
Lifecycle model
Project management Life Cycle
Manage the project
Systems Development Life cycle
Modify the system
System life cycle
Project start
Project end
Generic Project Life Cycle
Phases/Stages of PLC
 นิยามเป้าหมายของโครงการ (Define project goal)
 วางแผนโครงการ (Plan project)
 การตอบคาถามต่าง ๆ (What, why, how, who, et al)
 การกาหนดเบสไลน์ (Baseline)ของแผน (หมายถึงข้อกาหนดพื้นฐานของแผน)
 จัดทาแผนเพื่อให้บรรลุพ้นื ฐานที่กาหนด (Baseline plan) และ ปฏิบตั ิการให้เป็ นไป
ตามนั้น
 ปิ ดโครงการ (Close project)
 การประเมินโครงการ (Evaluate project)
สมมติวา่ …..
 ที่ทางานของคุณยังทาบัญชีดว้ ยมือ
 1)เป้าหมายของโครงการ: จัดหาซอฟต์แวร์ระบบบัญชีมาใช้
 2)แผนของโครงการ:
 2.1) เขียนโปรแกรมขึ้นมาใช้งานเอง
 3) แผนการดาเนินงาน
 3.1) ลงมือเขียนโปรแกรม
2
 4) ปิ ดโครงการ
1
 5) ประเมินผล
คุณต้องวางแผนและสร้าง
โปรแกรมออกมาหรื อ
ได้ผลิตภัณฑ์ออกมา
3
4
5
Define Project Goal
 การกาหนดเป้ าหมายของโครงการควรมุ่งเน้นไปในการก่อให้เกิดคุณค่าทางธุรกิจ
(business value) ต่อองค์กร
 การกาหนดเป้ าหมายที่ดีจะทาให้ทีมที่ทาโครงการเห็นภาพของโครงการชัดเจน
และขับเคลื่อนไปยังเฟสต่าง ๆ ได้อย่างถูกต้องและรวดเร็ ว
 เป้าหมายหมายของโครงการควรตอบคาถามต่อไปนี้:
 เราจะรู ้ได้อย่างไรว่า โครงการนี้ประสบความสาเร็ จเมื่อเราให้ เวลา เงิน และใส่ ทรัพยากร
เข้าไปแล้ว
 นอกจากนั้นโครงการต่าง ๆ ทั้งหลายมักจะมีคุณลักษณะร่ วมกันดังนี้
 1) ความพยายามในเทอมของระดับของต้นทุนในการดาเนินโครงการและการหา
คนมาทาโครงการ คือมันจะน้อยเมื่อเริ่ มโครงการ และมากขึ้นเมื่อดาเนินโครงการ
และลดลงเมื่อโครงการเกือบเสร็ จสิ้ น
 2) ความไม่แน่นอน (uncertainty) และความเสี่ ยง (risk) จะอยูใ่ นระดับสู งสุ ดเมื่อ
เริ่ มทาโครงการ (โอกาสที่จะประสบความสาเร็ จจะต่า) เมื่อเป้าหมายถูกกาหนดแล้ว
และโครงการเริ่ มคืบหน้า โอกาสที่จะประสบความสาเร็ จจะเพิ่มขึ้น
 3) ความสามารถของผูม้ ีส่วนเกี่ยวข้อกับโครงการทั้งหลายในการเข้ามามีอิทธิ พลต่อ
ขอบเขตและต้นทุนของโครงการจะสู งสุ ดในช่วงเริ่ มต้นโครงการ และต้นทุนของ
การเปลี่ยนขอบเขตของโครงการและแก้ไขข้อผิดพลาดจะมีค่ามากขึ้นตามความ
คืบหน้าของโครงการ
Plan Project
 หลังจากเป้าหมายของโครงการถูกกาหนดแล้ว จะเป็ นการสร้างแผนในการดาเนิน
โครงการ แผนนี้จะเป็ นการตอบคาถามต่อไปนี้










1) เรากาลังจะทาอะไร?
2) ทาไมเราจะต้องทาสิ่ งนั้น?
3) เราจะทาสิ่ งนั้นอย่างไร?
4) ใครจะต้องเข้ามามีส่วนร่ วมบ้าง?
5) การทาสิ่ งนั้นจะใช้เวลานานเท่าใด?
6) การทาสิ่ งนั้นขึ้นมาต้องใช้เงินเท่าใด?
7) มีอะไรบ้างที่อาจเกิดความผิดพลาดได้และเราสามารถทาอะไรกับมันได้บา้ ง?
8) เราจะประมาณเวลาและงบประมาณในการทาสิ่ งนั้นได้อย่างไร?
9) ทาไมเราจึงตัดสิ นใจที่จะทาสิ่ งนั้น?
10) เราจะรู ้ได้อย่างไรว่าเราทาได้สาเร็ จ
 นอกจากนั้น สิ่ งที่ตอ้ งส่ งมอบทั้งหลาย (deliverables) กิจกรรมต่าง ๆ (tasks) และ
เวลาที่แต่ละกิจกรรมใช้ไปต้องถูกกาหนดในแต่ละเฟสของโครงการ
 แผนตั้งต้นจะเรี ยกว่า baseline plan (แผนพื้นฐานที่ตอ้ งบรรลุ) มันจะกาหนด
ขอบเขต ตารางเวลา และงบประมาณที่ได้ตกลงร่ วมกันเอาไว้ ซึ่ งแผนนี้จะถูกใช้
เป็ นเครื่ องมือในการวัดประสิ ทธิภาพของโครงการตลอดวงรอบชีวิต
Execute Project Plan
 หลังจากเป้าหมายของโครงการและแผนของโครงการถูกกาหนดขึ้นมาเรี ยบร้อย
แล้ว ก็จะเป็ นการนาแผนไปดาเนินงาน
 งานที่เกี่ยวข้องกับความก้าวหน้าของโครงการ ขอบเขต ตารางเวลาการทางาน
งบประมาณและผูค้ นที่ทาโครงงานจะต้องถูกจัดการเพื่อมัน่ ใจได้วา่ โครงการจะ
บรรลุเป้าหมายที่วางไว้
 ความก้าวหน้าที่เกิดขึ้นจะต้องบันทึกเป็ นเอกสารและเทียบกับ baseline plan
 ประสิ ทธิ ภาพของการดาเนินโครงการต้องถูกสื่ อสารให้ผมู ้ ีส่วนเกีย่ วข้องทราบ
 ที่จุดสิ้ นสุ ดของเฟสนี้ ทีมต้องส่ งมอบผลิตภัณฑ์ (product) (หรื อ นาผลิตภัณฑ์น้ นั
มาใช้งาน) ให้แก่องค์กร
Close Project
 จากที่ได้กล่าวมาแล้วว่า โครงการต้องชัดเจนในตอนเริ่ มต้นและสิ้ นสุด (end) เฟส
ทาการปิ ดโครงการมีข้ ึนก็เพื่อให้มนั่ ใจได้วา่ งานทุกงานที่กาหนดไว้ในแผน (หรื อ
ตามที่ตกลงกันระหว่างทีมผูท้ าโครงการกับสปอนเซอร์) เสร็ จสิ้ นสมบูรณ์แล้ว
 ดังนั้นจึงควรจะมีการรับรู ้อย่างเป็ นทางการเกิดขึ้นโดยสปอนเซอร์ วา่ เขาจะยอมรับ
ผลิตภัณฑ์ที่ทีมทาโครงการส่ งมอบให้หรื อไม่
 การปิ ดโครงการมักจะทาโดยทาการส่ งรายงานขึ้นสุ ดท้าย (final report) และการ
นาเสนอเอกสารที่แสดงให้เห็นว่าสิ่ งที่ตอ้ งส่ งมอบที่ได้สัญญาไว้ทุก ๆ เรื่ อง
(promised deliverables)ได้ดาเนินการเสร็ จสิ้ นแล้วตามที่ระบุไว้ ให้กบั ผูเ้ กี่ยวข้อง
และเพื่อร่ วมงานทั้งหลาย
Evaluate Project
 บางครั้งคุณค่าของโครงการที่เกี่ยวข้องกับ IT ยังอาจรับรู ้ไม่ชดั เจนเมื่อระบบถูกใช้งาน
ในช่วงแรก เช่น เป้าหมายของโครงการในการสร้าง E-commerce คือการก่อให้เกิด
รายได้เพิ่มขึ้น ไม่ใช่เรื่ องของ H/W, S/W หรื อ Web page ใด ๆ ทั้งสิ้ น สมมติวา่ มีรายได้
เป็ น 250,000 USD ภายใน 6 เดือน ในกรณี เช่นนี้จะเห็นว่า เราจะประเมินโครงการนี้วา่
บรรลุเป้าหมายหรื อไม่ ก็ตอ้ งหลังจากระบบถูกใช้งานไปแล้วประมาณ 6 เดือน
 โครงการอาจจะถูกประเมินในแนวทางอื่นก็ได้ เช่น การบันทึกประสบการณ์การทา
โครงงานในเทอมของบทเรี ยนจากอดีต หรื อ lesson learned เพื่อใช้เป็ นประโยชน์ใน
อนาคต
 นอกจากนั้น ทั้งตัวโครงการและทีมทาโครงการต้องถูกประเมินหลังจากโครงการ
แล้วเสร็ จเสมอ ผูจ้ ดั การโครงการต้องประเมินประสิ ทธิภาพของทีมงานเพื่อ
ป้อนกลับให้เขารู ้ ส่ วนตัวโครงการอาจเชิญบุคคลภายนอกมาทาการประเมิน เพื่อดู
ว่า โครงการมรการจัดการดีหรื อไม่ ให้สิ่งที่ตอ้ งส่ งมอบครบถ้วนหรื อไม่
ดาเนินงานตามกระบวนการที่กาหนดหรื อไม่ ได้คุณภาพตามที่กาหนดหรื อไม่
Product Life Cycles
 ผลิตภัณฑ์ (Products) ก็จะมีวงรอบชีวติ เช่นกัน
 วงรอบชีวิตของการพัฒนาระบบ (Systems Development Life Cycle (SDLC)) คือกรอบ
การทางานที่ใช้อธิบายระยะ(เวลา)ที่ใช้ในการพัฒนาและบารุ งรักษาระบบสารสนเทศ
 โครงการพัฒนาระบบ (Systems development projects) สามารถกล่าวได้วา่ มีรูปแบบ
ดังนี้
 predictive models: ขอบเขตของโครงการสามารถกาหนดได้ชดั แจ้งและตารางเวลา
กับต้นทุนสามารถทานายได้
 adaptive models: โครงการเป็ นแบบถูกสถานการณ์บงั คับ (mission driven) และ อยู่
บนพื้นฐานของส่ วนประกอบ (component based) ซึ่ งใช้วงรอบของเวลามาเป็ น
พื้นฐานเพื่อให้สอดรับกับ target dates
Systems Development Life Cycle (SDLC)
วางแผน
วิเคราะห์
ออกแบบ
นาไปปฏิบตั ิ
บารุ งรักษา
เราจะสร้างระบบอะไรขึ้นมาสักระบบหนึ่ง เช่น ระบบบัญชีที่ใช้คอมพิวเตอร์ เข้าช่วย
วงรอบชีวติ หรื อ วัฏจักรของการพัฒนาระบบนี้ จะเป็ นดังรู ปข้างบน
Systems Development Life Cycle (SDLC)
 ดังนั้นจึงกล่าวได้วา่ SDLC ก็คือ ระยะหรื อเฟส (phase) หรื อ ขั้นตอน (stage) ที่อนุกรม
กันไป(sequential) ของระบบสารสนเทศ ที่ตอ้ งดาเนินการต่อเนื่องกันไปตลอดอายุการ
ใช้งาน
 ระยะ/ขั้นตอน (Phases/Stages)
 การวางแผน (Planning)
 การวิเคราะห์ (Analysis)
 การออกแบบ (Design)
 การนาไปปฏิบตั ิ (Implementation) (สร้างขึ้นมาแล้วนาไปใช้งาน)
 การดูแลรักษาและให้การสนับสนุน (Maintenance and Support)
 การวางแผน (Planning)
 ขั้นตอนการวางแผนประกอบด้วยการบ่งชี้และสนองตอบต่อ ปั ญหาหรื อโอกาส และ
ร่ วมมือกันจัดการโครงการ และกระบวนการพัฒนาระบบและกิจกรรมต่าง ๆ ที่
เกี่ยวข้อง การมีกระบวนการวางแผนอย่างเป็ นทางการย่อมทาให้มนั่ ใจได้วา่ เป้าหมาย
ขอบเขต งบประมาณ ตารางเวลา เทคโนโลยี และเครื่ องมือ กรรมวิธีการ
กระบวนการพัฒนาระบบ มีอย่างถูกต้องและครบถ้วนแล้ว
 การวิเคราะห์ (Analysis)
 ขั้นตอนนี้ เป็ นการพยายามขุดลึกลงไปในปั ญหาหรื อโอกาสอย่างเต็มที่
ตัวอย่างเช่น กลุ่มทาโครงการได้ศึกษาระบบปั จจุบนั เพื่อจัดทาเอกสารขึ้นมาตามที่
มันเป็ น (as is) เพื่อจะได้ทาความเข้าใจ แล้วทาการบ่งชี้และจัดทาเป็ นเอกสาร
เกี่ยวกับปั ญหาใด ๆ หรื อ ขีดจากัดที่มีอยูใ่ นระบบปั จจุบนั เป็ นการวิเคราะห์ความ
ต้องการหรื อ requirement analysis นัน่ เอง จากนั้นจึงทาการบ่งชี้ specific need and
requirement ของระบบใหม่ (to be system) และทาให้เป็ นเอกสาร
 Requirement (ของระบบใหม่) อาจหาได้หลายทาง เช่น การสัมภาษณ์ผใู ้ ช้ การ
พัฒนาโปรแกรมประยุกต์ร่วมกัน (Joint Application Development, JAD) การทา
การสารวจ การสังเกตกระบวนการทางาน การศึกษาจากรายงานขององค์กร
 การออกแบบ (Design)
 ในระหว่างขั้นตอนการออกแบบ กลุ่มทาโครงการจะใช้โมเดลทางตรรกะของของ
“as is” และ requirement เป็ นอินพุตในการออกแบบสถาปั ตยกรรมเพื่อสนับสนุ น
ระบบสารสนเทศระบบใหม่
 สถาปั ตยกรรมใหม่น้ ีประกอบด้วยการออกแบบโครงข่าย Hardware configuration
ฐานข้อมูล การเชื่อมต่อกับผูใ้ ช้ (User interface) และ โปรแกรมประยุกต์ต่าง ๆ
 การนาไปปฏิบตั ิ (Implementation)
 การนาไปใช้งานประกอบด้วย การพัฒนา หรื อ สร้างระบบขึ้นมา การทดสอบ และ
การติดตั้ง ทั้งนี้รวมถึง การฝึ กอบรม การให้การสนับสนุน และการจัดทาเอกสาร
ต่าง ๆ
 การดูแลรักษาและให้การสนับสนุน (Maintenance and Support)
 เมื่อระบบถูกใช้งาน การเปลี่ยนแปลงใด ๆ ที่เกิดกับระบบ เช่น การดูแลรักษาและ
ปรับปรุ งให้ดีข้ ึนมักถูกร้องขอให้ดาเนินการ เช่น การแก้ไขข้อบกพร่ อง เป็ นต้น
หรื อ การเพิ่มเติมลักษณะบางสิ่ งบางอย่างเพิ่มเติมจากเดิม หรื อ เกิดการปรับเปลี่ยน
สภาพแวดล้อมทางธุรกิจ เป็ นต้น
 ส่ วนการสนับสนุนอาจอยูใ่ นรู ปของ Call Center หรื อ Helpdesk เพื่อช่วยผูใ้ ช้งาน
สามารถใช้งานได้ตามที่เขาต้องการ (as need basis)
Implementing SDLC:
Structured Approaches to Systems Development
วิธีการลดหลัน่ แบบน้ าตก (Waterfall Method)
Waterfall model มีการกาหนดๆ ไว้เป็ นอย่างดี มีข้ นั ตอนแบบเชิงเส้นในการพัฒนาระบบ
และการให้การสนับสนุน เรี ยกแนวทางนี้วา่ แนวทางเชิงเส้น (linear approach)
85
Waterfall Method
Define
Requirements
Design
Build
Test
Implement
Maintenance
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
 การพัฒนาระบบแบบคล่องตัว (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 จึง
ประกอบด้วย ผูพ้ ฒั นา ผูบ้ ริ หาร และ ผูใ้ ช้ อยูใ่ นกลุ่มเดียวกัน
V-Shaped SDLC Model
Incremental SDLC Model
Spiral SDLC Model
The PLC vs. the SDLC
ความสัมพันธ์ระหว่าง PLC และ SDLC
 จากรู ปจะเห็นว่า วงรอบชีวติ ของการพัฒนาระบบ (systems development life cycle
(SDLC)) กลายเป็ นส่ วนหนึ่งของวงรอบชีวิตของโครงการ (project life cycle (PLC))
 PLC เน้นที่ เทคนิค เครื่ องมือ กระบวนการ เฟสต่าง ๆ ในการบริ หารโครงงาน
เพื่อให้การบริ หารโครงงานเป็ นไปอย่างมีประสิ ทธิ ผล
 SDLC เน้นที่เทคนิค เครื่ องมือ กระบวนการ เฟสต่าง ๆ ในเชิงวิศวกรรมซอฟต์แวร์
เพื่อสร้าง IT Solution และ/หรื อนาไปปฏิบตั ิ (ใช้งาน)
 ถ้า SDLC คือ คนงานที่ก่อสร้างบ้านแล้ว PLC ก็คือผูค้ ุมงานนัน่ เอง
ผูค้ ุมงาน (บริ หารโครงการ) กับ คนงาน (บริ หารแรงงาน)
Extreme Project Management (XPM)
 ปรัชญาและแนวทางใหม่ของการบริ หารโครงการที่เริ่ มได้รับความนิยมมากขึ้น
 โดยมองในเชิงลักษณะที่มีความหลากหลายของโครงการในปั จจุบนั จะเห็นว่า ต้องการ
ความเร็ วในการทาให้โครงการสาเร็ จเร็ วขึ้น โครงการมีความไม่แน่นอนมากขึ้น มีความ
ต้องการในการเปลี่ยนแปลงมากขึ้น มีความเสี่ ยงมากขึ้น
 การบริ หารโครงการแบบดั้งเดิมใช้แนวทางดาเนินการแบบเรี ยงลาดับกันไป ในขณะที่
XPM ยืนอยูบ่ นพื้นฐานที่วา่ โครงการมักไร้ระเบียบ (chaotic) และ คาดการได้ยาก
(unpredictable) ดังนั้น XPM จึงเน้นที่ความคล่องตัว การปรับตัวและนวัตกรรม
 การใช้ท้ งั แบบดั้งเดิมและแบบใหม่ร่วมกันทาให้เข้าใจโครงงานได้ดีข้ ึน ส่ งผลให้รู้วา่ จะ
ทาอย่างไรโครงการจึงมีโอกาสสาเร็ จมากขึ้น
Why Have Project Phases and Management Reviews?
 โครงงานควรประสบผลสาเร็ จในแต่ละเฟส
เมื่อเฟสแรกสาเร็ จแล้ว จึงลงมือทาในเฟส
ถัดไป
 Management reviews (บางทีเรี ยกว่า “phase
exits” หรื อ “kill points”) อาจเกิดขึ้นหลังจาก
แต่ละเฟสถูกประเมินถึงความคืบหน้าของ
โครงการ (โอกาสที่น่าจะประสบความสาเร็ จ)
และ ยังคงสอดรับกับ organizational goals
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
PMBoK
Project Management Knowledge Areas









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)










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)











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)













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)














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)
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).
Top Information Technology Skills
70%
60%
60%
Percentage of
Respondents
58%
50%
42%
41%
Database
management
Networking
40%
30%
20%
10%
0%
Application
development
Project management
Information Technology (IT) Skill
Cosgrove, Lorraine, “January 2004 IT Staffing Update,” CIO Research Reports (February 3, 2004).
จบหัวข้อ 1
 คาถาม ………..