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

Project and Change
Management
ผูส้ อน: พนม เพชรจตุพร
อาจารย ์ประจาภาควิชาวิศวกรรม
ระบบวัดคุม
1
ITEC 0521 : Project and Change
Management
 Text Book:
 1) Information Technology Project Management 2nd
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.
Score





Homework 20%
Midterm (Close Book) 30%
Examination (Close Book) 50%
Note:
It may be changed if anyone has a good
suggestion.
Content of Text Book (1)
 Chapter 1: The Nature of Information
Technology Projects.
 Chapter 2: Conceptualizing and Initiating the IT
Project.
 Chapter 3: Developing the Project Charter and
Baseline Project Plan.
 Chapter 4: The Human Side of Project
Management.
 Chapter 5: Defining and Managing Project
Scope.
 Chapter 6: The Work Breakdown Structure and
Content of Text Book (1)
 Chapter 10: IT Project Quality Management.
 Chapter 11: Managing Organizational Change,
Resistance, and Conflict.
 Chapter 12: Project Procurement Management
and Outsourcing
 Chapter 13: Leadership and Ethics.
 Chapter 14: Project Implementation, Closure,
and Evaluation.
 Appendix A: An Introduction to Function Point
Analysis.
Information Technology
Project Management
by Jack T. Marchewka
6
Chapter 1:
The Nature of Information
Technology Projects
(ธรรมชาติของโครงงานทางด ้านเทคโนโลยี
สารสนเทศ)
7
Chapter 1 Objectives
 กล่าวถึงวิกฤติการณ์ทางด ้านซอฟต์แวร์และความ
ผิดพลาดทีเ่ กิดขึน
้ บ่อย ๆ ในการติดตามข ้อมูลทีม
่ ก
ี าร
บันทึกไว ้เกีย
่ วกับโครงการต่าง ๆ ทีเ่ กีย
่ วข ้องกับ
เทคโนโลยีสารสนเทศ (information technology (IT)
projects) อันก่อให ้เกิดแรงบันดาลใจอันก่อให ้เกิดการ
เปลีย
่ นแปลงวิธก
ี ารเฝ้ ามองและจัดการกับโครงการที่
เกีย
่ วข ้องกับ IT
 อธิบายถึงเทคโนโลยีทเี่ กีย
่ วข ้องกับสงั คม การบริหาร
้
โครงการ และ การใชแนวทางบริ
หารองค์ความรู ้
(Knowledge Management) เข ้ามาใชกั้ บ ITPM
 นิยามความหมายของ IT project และอธิบายถึงลักษณะ
ต่าง ๆ
Chapter 1 Objectives
 อธิบายถึงวงรอบชวี ต
ิ ของโครงการ (project life cycle)
วงรอบชวี ต
ิ ของการพัฒนาระบบ (systems
ั พันธ์ทเี่ กีย
development life cycle) และ ความสม
่ วข ้อง
 ระบุถงึ Project Management Body of Knowledge
(PMBOK) และ core knowledge areas.
Project Management Statistics
 U.S. ใชจ่้ ายเงินประมาณ $2.3 trillion ไปกับโครงงานต่าง
ี่ องผลิตภัณฑ์มวล
ๆ ในแต่ละปี ซงึ่ เทียบเท่ากับหนึง่ ในสข
รวมของประชาชาติ ( nation’s gross domestic product)
 คนมากกว่า 16 ล ้านคนเข ้าไปเกีย
่ วข ้องกับการบริหาร
โครงการ (project management) ตามความชานาญของ
เขาเหล่านัน
้ โดยเฉลีย
่ แล ้วผู ้บริหารโครงการคนหนึง่
(project manager) คนหนึง่ จะมีรายได ้ประมาณ $82,000
ต่อปี
 มีมากกว่าครึง่ ล ้านโครงการทีเ่ ป็ นการพัฒนาด ้านการนา IT
้
มาประยุกต์ใชงาน
(IT application) ในปี 2001 และ
มากกว่า 300,000 โครงการในปี 2000
Advantages of Using Formal Project
Management
 สามารถควบคุม financial, physical, และ human
resources ได ้ดีขน
ึ้
ั พันธ์กบ
 ความสม
ั ลูกค ้า ถูกปรับปรุงให ้ดีขน
ึ้
้ ฒนาลดน ้อยลง
 เวลาทีใ่ ชพั
 ต ้นทุนตา่ ลง
 คุณภาพและความวางใจได ้เพิม
่ สูงขึน
้
 ผลกาไรสูงขึน
้
 ผลิตผลถูกปรับปรุงให ้ดีขน
ึ้
 การประสานงานภายในดีขน
ึ้
 อารมณ์รว่ มในการ(อยาก)ทางานสูงขึน
้
The Context of Project Management
 คานิยามของ “โครงการ (Project)”
 โครงการ (project) คือ การรวมตัวกันชวั่ คราวเพือ
่
พยายามดาเนินการให ้บรรลุเป้ าประสงค์เรือ
่ งใดเรือ
่ ง
ั เจน
หนึง่ ทีช
่ ด
 ดังนัน
้ การบริหารโครงการจึงหมายถึง การประยุกต์ใช ้
องค์ความรู ้ ทักษะ เครือ
่ งมือต่าง ๆ และ เทคนิคต่าง ๆ
กับการดาเนินโครงการ เพือ
่ ให ้ได ้ผลตาม ความต ้องการ
หรือความคาดหวัง (หรือดีกว่า) จากโครงการหนึง่ ๆ
โดยผู ้เกีย
่ วข ้องทัง้ หลาย
ิ รับว่า งาน (ทีเ่ ราทากันอยูท
 ลองนึกซค
่ ก
ุ ๆ วัน) จะ
เรียกว่า โครงการได ้หรือไม่ ?!? ถ ้าไม่ได ้ แล ้วโครงการ
The Context of Project Management
ลักษณะของโครงการ (Project
Attributes):
 มีกรอบเวลา (Time
Frame)
 มีวัตถุประสงค์
(Purpose)
 มีความเป็ นเจ ้าของ
(Ownership)
 มีทรัพยากร
(Resources)
 มีกจิ กรรมทีอ
่ ส
ิ ระจากกัน
(Interdependent tasks)
 มีการปรับเปลีย
่ นองค์กร
(Organizational change)
 มีสภาพแวดล ้อมในการ
ทางาน (Operating
Environment)
Project Characteristics
ั เจน (ซงึ่ อาจเป็ นเรือ
 มีวัตถุประสงค์ทเี่ จาะจง ชด
่ งเดียว
(unique) หรือ ประเภทใดประเภทหนึง่ ก็ได ้) สามารถ
ิ้ ภายในข ้อกาหนดทีช
ั เจนแน่นอน
ดาเนินการให ้เสร็จสน
่ ด
ิ้ สุด
 มีการกาหนดวันเริม
่ ต ้นและวันสน
 มีการกาหนดวงเงินทีต
่ ้องใชจ่้ าย (ถ ้าเป็ นไปได ้)
้ พยากรทัง้ ทีเ่ ป็ นคนและไม่ใช ่ (เชน
่ เงิน เครือ
 ใชทรั
่ งจักร
เทคโนโลยี)
ั (multifunctional) (cut across
 เป็ นแบบหลายฟั งก์ชน
several functional lines)
What Helps Projects Succeed?
ื เนือ
 สบ
่ งจาก “CHAOS 2001: A Recipe for
Success,” สงิ่ ต่อไปนีจ
้ ะชว่ ยให ้ IT projects ประสบ
ความสาเร็จ โดยเรียงตามลาดับความสาคัญ:
 ได ้รับการสนับสนุนจากผู ้บริหารระดับสูง (Executive
support)
 ผู ้ใชมี้ สว่ นร่วม (User involvement)
 ผู ้บริหารโครงการมีประสบการณ์ (Experienced
project manager)
ั เจน (Clear business
 มีวัตถุประสงค์ทางธุรกิจชด
objectives)
 มีขอบเขตแคบ (Minimized scope) (หมายถึง
ั เจน)
เหมาะสม มีกรอบแคบ ชด
Chaos Study
ปี 1995
Need for Top Management
Commitment
ึ ษาหลาย ๆ แหล่งพบว่า ความมุง่ มั่นจาก
 จากการศก
ผู ้บริหารระดับสูงเป็ นแฟกเตอร์ทส
ี่ าคัญของความสาเร็จ
ของโครงการ
 ผู ้บริหารระดับสูงสามารถชว่ ยให ้ผู ้บริหารโครงการมั่นใจว่า
 มีทรัพยากรพอเพียง
 โครงการได ้รับการอนุมัตภ
ิ ายในระยะเวลาทีเ่ หมาะสม
 ได ้รับความร่วมมือจากบุคคลทีเ่ กีย
่ วข ้องทั่วทัง้ องค์กร
 เรียนรู ้ถึงการเป็ นผู ้นาทีด
่ ข
ี น
ึ้
ความแตกต่างระหว่างการบริหารโครงการกับ
่
การบริหารทัวไป
 การบริหารโครงการ
้ บ
 มีลก
ั ษณะพิเศษ ไม่ซากั
่
โครงการอืนใด
่ นอน
 มีระยะเวลาทีแน่
่
่
 เกียวข
้องกับการเปลียนแปลง
ขนาดใหญ่
 สภาพการดาเนิ นงานไม่คงที่
สม่าเสมอ
 ให ้น้าหนักแก่วต
ั ถุประสงค ์ไม่
่ อให ้เกิดการ
เท่ากัน เพือก่
่
เปลียนแปลงไปจากสภาพเดิ
ม
่
้
 สร ้างกลุม
่ ทีมงานชัวคราวขึ
นมา
่
 การบริหารทัวไป
 มีลก
ั ษณะซา้ ๆ กันเป็ นกิจวัตร
 มีระยะเวลาไม่สนสุ
ิ้ ด
่
่
 เกียวข
้องกับการเปลียนแปลงแบบค่
อย ๆ
ไป
 สภาพการทางานมีลก
ั ษณะคงที่
สม่าเสมอ
้
 ให ้นาหนั
กแก่วต
ั ถุประสงค ์เท่ากัน เพือ่
ร ักษาสภาพเดิม
้
 สร ้างกลุม
่ ทีมงานถาวรขึนมาด
าเนิ นการ
วัฒนธรรมในการบริหารก็ตา่ งกัน
Need for Organizational Commitment
to IT
 ถ ้าองค์กรมีทัศนคติตอ
่ IT ทางด ้านลบ จะเป็ นเรือ
่ งยุง่ ยากที่
จะทาให ้โครงการทีเ่ กีย
่ วข ้องกับ IT ประสบผลสาเร็จ
 การมี Chief Information Officer (CIO) อยูใ่ นฐานะ
ผู ้บริหารระดับสูงขององค์กรจะชว่ ยทางด ้านโครงการที่
เกีย
่ วข ้องกับ IT (ประสบผลสาเร็จ)ได ้มาก
 การกาหนดให ้ผู ้ทีไ่ ม่ได ้เกีย
่ วข ้องกับ IT เข ้ามาดูแล
โครงการทีเ่ กีย
่ วกับ IT นัน
้ เขาผู ้นัน
้ จะต ้องกล ้าทีจ
่ ะให ้
ั ญา (commitment) มากกว่าปกติ
คามั่นสญ
Need for Organizational Standards
 มาตรฐาน (Standard) หรือแนวทางปฏิบต
ั ิ (Guideline)
ต่าง ๆ จะชว่ ยให ้ผู ้บริหารโครงการทางานได ้อย่างมี
ิ ธิภาพมากขึน
ประสท
้
 ผู ้บริหารระดับอาวุโส (Senior management) ควรกล ้าที่
จะ
้
 ใชแบบฟอร์
มและซอฟท์แวร์มาตรฐานในการบริหาร
โครงการ
้
 พัฒนาและใชแนวทางปฏิ
บต
ั ต
ิ า่ ง ๆ ในการเขียนแผน
ของโครงการ (project plans) หรือ ระบุถงึ สารสนเทศ
ทีแ
่ สดงสถานะ (status information) ต่าง ๆ
 สร ้างสานั กงานสาหรับบริหารโครงการ (project
The Software Crisis
 If builders built buildings the way programmers
wrote programs, then the first woodpecker that
came along would destroy civilization.
 -Gerald Weinberg
Why Projects Fail?
้
 ใชงบประมาณเกิ
นกาหนด (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)
Improving the likelihood of success
้
 ใชแนวทางเช
งิ เทคนิคทีส
่ นองตอบต่อสงั คม (Sociotechnical Approach)
้
 ใชแนวทางการบริ
หารโครงการ (Project Management
Approach) ผ่านทาง
 กระบวนการต่าง ๆ และโครงสร ้าง
 ทรัพยากรต่าง ๆ
 ความคาดหวัง
 การแข่งขัน
ิ ธิภาพและประสท
ิ ธิผล
 ประสท
้
 ใชแนวทางการบริ
หารองค์ความรู ้ (Knowledge
Management Approach)
The Triple Constraint
 ทุก ๆ โครงงานจะถูกข ้อจากัดของตัวมันเข ้ามาบีบ
ได ้แก่:
 Scope goals: อะไรคือสงิ่ ทีโ่ ครงงานต ้องบรรลุ
้
 Time goals: ใชเวลานานเท่
าใดจึงจะสาเร็จ
 Cost goals: ใชต้ ้นทุนเท่าใด
 มันจึงถือเป็ นหน ้าทีข
่ องผู ้บริหารโครงการต ้องสมดุล
ระหว่างสามเรือ
่ งนีเ้ พือ
่ ให ้บรรลุ goal ทีต
่ งั ้ ไว ้
The Triple Constraint
ขอบเขตบาน
Figure 1.2
เวลาเกิน
งบเกิน
What is 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® Gui e), 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)
Roles
ี )กับโครงการ (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) ควรทางานนี้
Functional Obstacles
 การร ้องขอให ้ทางานอย่างไม่มข
ี ด
ี จากัด (Unlimited
work requests)
้
 มีเสนตาย
(deadline) ทีก
่ าหนดไว ้ก่อนแล ้ว
(Predetermined deadlines)
 การร ้องขอทัง้ หมดล ้วนแล ้วแต่มล
ี าดับความสาคัญสูง
ิ้
(high priority) ทัง้ สน
 ทรัพยากรต่าง ๆ มีจานวนจากัด (จานวนทรัพยากร)
้ างจากัด (ประเภทของทรัพยากร)
 ทรัพยากรมีให ้ใชอย่
 มีการเปลีย
่ นแปลงโดยไม่ได ้กาหนดไว ้ในตารางของ
แผนในการทาโครงการ (project plan)
้
 เกิดความล่าชาโดยไม่
ได ้คาดหมายล่วงหน ้า
Functional Obstacles
้
 ไม่ได ้วางแผนเอาไว ้ในกรณีทท
ี่ รัพยากรใชงานไม่
ได ้
่ เครือ
ี หาย)
(เชน
่ งจักรชารุดเสย
ี ทรัพยากร (เชน
่
 ไม่ได ้วางแผนเอาไว ้ในกรณีทส
ี่ ญ
ู เสย
พนักงานลาออกจานวนมาก)
 ไม่ได ้วางแผนเอาไว ้ในเรือ
่ งของ turnover พนักงาน
่ พนักลาออกไป รับพนักงานใหม่เข ้ามา ต ้อง
(เชน
ี เวลาในการอบรมนานจนกว่าจะเป็ นงาน)
เสย
The Antidote: Good Planning
 ถ ้าการวางแผนทาได ้ดีแล ้ว ผลดีจะเกิดขึน
้ หลายเรือ
่ ง
่
เชน
 Functional units จะเข ้าใจความรับผิดชอบของเขาว่า
้
ในการทีจ
่ ะให ้โครงการสาเร็จนั น
้ จาเป็ นต ้องใชอะไรบ
้าง
(รู ้ว่า โครงการต ้องการอะไร)
 ปั ญหาต่าง ๆ ทีเ่ กิดจากการกาหนดเวลาและการ
เคลือ
่ นย ้ายทรัพยากรทีว่ ก
ิ ฤติจะถูกรับรู ้ล่วงหน ้า (ก่อนที่
มันจะเกิดปั ญหา)
 มีการระบุถงึ ปั ญหาแต่เนิน
่ ๆ ทาให ้การกาหนดแนว
ิ ธิภาพ และ ทา
ทางการแก ้ปั ญหาทาได ้อย่างมีประสท
ปรับแผนเพือ
่ ป้ องกันหรือแก ้ไขปั ญหานัน
้ ๆ ได ้อย่าง
Project Plan Requirements
 กาหนดงานต่าง ๆ ทีต
่ ้องทาอย่างครบถ ้วน
 กาหนดความต ้องการของทรัพยากร (และรวมถึง
กาหนดระดับของทักษะทีต
่ ้องการ)
 หมายกาหนดการทางด ้านเวลา (timetable
milestones) หลัก ๆ
 กาหนดคุณภาพของผลลัพธ์ท ้ายสุดทีต
่ ้องการรวมไป
ื่ ถือ (หรือ ความวางใจได ้ของผลลัพธ์ของ
ถึงความเชอ
งานทีท
่ าออกมา)
ิ ธิภาพ (จาไว ้ว่า ไม่วัดก็ไม่ถก
 พืน
้ ฐานของการวัดประสท
ู
รับรู ้ เมือ
่ ไม่รู ้ก็ไม่มก
ี ารแก ้ไข ปรับปรุง)
Risks & Assumptions
ี่ งต่าง ๆ มักจะถูกละเลย ความเสย
ี่ ง
 Risk หรือ ความเสย
จะแยกเป็ น
 ภายใน (Internal)
 ภายนอก (External)
 สมมติฐานต่าง ๆ (Assumptions)
Internal Risks
ั ญาในสงิ่ ทีท
ท่านสญ
่ าไม่ได ้หรือไม่ ?
ั รูของโครงการของท่าน ?
ใครคือศต
ิ ของกลุม
ใครคือผู ้ประเมินสมาชก
่ ?
ใครคือผู ้ควบคุมงบประมาณของโครงการของท่าน ?
ิ ของกลุม
ใครคือผู ้กาหนดสมาชก
่ (ว่าเป็ นคนนัน
้ คนนี)้
ของโครงการของท่าน ?
ั ญา
 ท่านมีการใส่ (กาหนด) input เข ้าไปในสญ
(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
The Project Life Cycle and IT
Development
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)
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)
Product Life Cycles
่ กัน
 ผลิตภัณฑ์ (Products) ก็จะมีวงรอบชวี ต
ิ เชน
 วงรอบชวี ต
ิ ของการพัฒนาระบบ (Systems Development
้ บายระยะ
Life Cycle (SDLC)) คือกรอบการทางานทีใ่ ชอธิ
้
(เวลา)ทีใ่ ชในการพั
ฒนาและบารุงรักษาระบบสารสนเทศ
 โครงการพัฒนาระบบ (Systems development projects)
สามารถกล่าวได ้ว่า มีรป
ู แบบดังนี้
 predictive models: ขอบเขตของโครงการสามารถ
ั แจ ้งและตารางเวลากับต ้นทุนสามารถ
กาหนดได ้ชด
ทานายได ้
 adaptive models: โครงการเป็ นแบบถูกสถานการณ์
บังคับ (mission driven) และ อยูบ
่ นพืน
้ ฐานของ
Systems Development Life
Cycle
วางแผน
วิเคราะห์
ออกแบบ นาไปปฏิบต
ั ิ บารุงรักษา
Systems Development Life Cycle
 ดังนัน
้ จึงกล่าวได ้ว่า SDLC ก็คอ
ื ระยะหรือเฟส (phase)
หรือ ขัน
้ ตอน (stage) ทีอ
่ นุกรมกันไป(sequential) ของ
ระบบสารสนเทศ ทีต
่ ้องดาเนินการต่อเนือ
่ งกันไปตลอด
้
อายุการใชงาน
 ระยะ/ขัน
้ ตอน (Phases/Stages)
 การวางแผน (Planning)
 การวิเคราะห์ (Analysis)
 การออกแบบ (Design)
 การนาไปปฏิบต
ั ิ (Implementation) (สร ้างขึน
้ มาแล ้ว
้
นาไปใชงาน)
 การดูแลรักษาและให ้การสนับสนุน (Maintenance
Implementing SDLC:
่ นโครงสร ้าง (Structured
ใช ้แนวทางทีเป็
Approaches):
่
้
วิธก
ี ารลดหลันแบบน
าตก
(Waterfall
Method)
58
Putting the SDLC into Practice
้
 ใชแนวทางที
เ่ ป็ นโครงสร ้างผ่านทางการพัฒนาเชงิ ระบบ
(Systems Development)
 วิธก
ี ารลดหลั่นแบบน้ าตก (Waterfall Method)
้
ั อย่างรวดเร็ว (Rapid
 ใชแนวทางการพั
ฒนาแอพพลิเคชน
Applications Development (RAD))
 การทาต ้นแบบ (Prototyping)
 การพัฒนาหมุนวนแบบใยแมงมุม (Spiral
Development)
 การโปรแกรมแบบทุม
่ เทสุด ๆ (Extreme
Programming)
The PLC vs the SDLC
The Relationship Between the PLC and
the SDLC
 จากรูปจะเห็นว่า วงรอบชวี ต
ิ ของการพัฒนาระบบ
(systems development life cycle (SDLC)) กลายเป็ น
สว่ นหนึง่ ของวงรอบชวี ต
ิ ของโครงการ (project life cycle
(PLC))
 PLC เน ้นที่ เทคนิค เครือ
่ งมือ กระบวนการ เฟสต่าง ๆ
ในการบริหารโครงงานเพือ
่ ให ้การบริหารโครงงาน
ิ ธิผล
เป็ นไปอย่างมีประสท
 SDLC เน ้นทีเ่ ทคนิค เครือ
่ งมือ กระบวนการ เฟสต่าง ๆ
ในเชงิ วิศวกรรมซอฟต์แวร์เพือ
่ สร ้าง IT Solution และ/
้
หรือนาไปปฏิบต
ั ิ (ใชงาน)
 ถ ้า SDLC คือ คนงานทีก
่ อ
่ สร ้างบ ้านแล ้ว PLC ก็คอ
ื ผู ้คุม
ผู ้คุมงาน (บริหารโครงการ) กับ คนงาน
(บริหารแรงงาน)
Predictive Life Cycle Models
 Waterfall model มีการกาหนดๆ ไว ้เป็ นอย่างดี มี
้
ขัน
้ ตอนแบบเชงิ เสนในการพั
ฒนาระบบและการให ้การ
สนับสนุน เรียกแนวทางนีว้ า่ แนวทางเชงิ เสน้ (linear
approach)
้
 Spiral model แสดงว่า ซอฟท์แวร์ถก
ู พัฒนาโดยใชการ
ทาซ้า ๆ (iterative) หรือ แนวทางหมุนวนแบบใยแมงมุม
(spiral approach) แทนทีจ
่ ะเป็ นแบบ linear approach
 Incremental release model ใชส้ าหรับ progressive
development ของ operational software
้
 Prototyping model ถูกนามาใชในการพั
ฒนาต ้นแบบ
้ ้
(prototype) เพือ
่ พิจารณาถึงความต ้องการของผู ้ใชให
ั เจน (clarify user requirements)
ชด
Adaptive Life Cycle Models
 Extreme Programming (XP): โปรแกรมจะถูก
พัฒนาแบบขนานหรือพร ้อม ๆ กันไปในหลาย ๆ สว่ น
และจะต ้องทาการทดสอบโปรแกรมทีเ่ ขียนขึน
้ มาด ้วย
ดังนัน
้ ทีม XP จึงประกอบด ้วย ผู ้พัฒนา ผู ้บริหาร และ
ผู ้ใช ้ อยูใ่ นกลุม
่ เดียวกัน
 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 objectoriented technology projects and requires strong
Extreme Project Management (XPM)
 ปรัชญาและแนวทางใหม่ของการบริหารโครงการทีเ่ ริม
่
ได ้รับความนิยมมากขึน
้
 โดยมองในเชงิ ลักษณะทีห
่ ลากหลายของโครงการใน
ปั จจุบน
ั จะเห็นว่า ต ้องการ ความเร็วในการทาให ้โครงการ
สาเร็จเร็วขึน
้ โครงการมีความไม่แน่นอนมากขึน
้ มีความ
ี่ งมากขึน
ต ้องการในการเปลีย
่ นแปลงมากขึน
้ มีความเสย
้
้
 การบริหารโครงการแบบดัง้ เดิมใชแนวทางด
าเนินการแบบ
เรียงลาดับกันไป ในขณะที่ XPM ยืนอยูบ
่ นพืน
้ ฐานทีว่ า่
โครงการมักไร ้ระเบียบ (chaotic) และ คาดการได ้ยาก
(unpredictable) ดังนัน
้ XPM จึงเน ้นทีค
่ วามคล่องตัว การ
ปรับตัวและนวัตกรรม
Why Have Project Phases and
Management Reviews?
 โครงงานควรประสบผลสาเร็จ
ในแต่ละเฟส เมือ
่ เฟสแรก
สาเร็จแล ้ว จึงลงมือทาในเฟส
ถัดไป
 Management reviews (บาง
ทีเรียกว่า “phase exits” หรือ
“kill points”) อาจเกิดขึน
้
หลังจากแต่ละเฟสถูกประเมิน
ถึงความคืบหน ้าของโครงการ
(โอกาสทีน
่ ่าจะประสบ
ความสาเร็จ) และ ยังคงสอด
The Project Management Body of
Knowle ge (PMBOK®)
 เอกสารแสดงแนวทาง (Guide) ของ Project
Management Bo y of Knowle ge (PMBOK®
Guide) ประกอบด ้วย 9 project management
knowledge areas.
 The PMBOK® Gui e is publishe an maintaine
by the Project Management Institute (PMI).
 http://www.pmi.org
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
 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)
่ ในโครงการ (Project time
 3. การบริหารเวลาทีใช้
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)
 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)
ื่ สาร (Communication Planning)
 7.1 การวางแผนด ้านการสอ
 7.2 การกระจายสารสนเทศ (Information Distribution)
ิ ธิภาพ (Performance Reporting)
 7.3 การรายงานประสท
่
 8. การบริหารความเสียงของโครงการ
(Project risk
management)
ี่ ง (Risk Management
 8.1 การวางแผนบริหารความเสย
Planning)
ี้ วามเสย
ี่ ง (Risk Identification)
 8.2 การบ่งชค
ี่ งเชงิ คุณภาพ (Qualitative Risk
 8.3 การวิเคราะห์ความเสย
Analysis)
ี่ งเชงิ ประมาณ (Quantitative Risk
 8.4 การวิเคราะห์ความเสย
Analysis)
ี่ ง (Risk Response
 8.5 การวางแผนสนองตอบต่อความเสย
Planning)
ี่ ง (Risk Monitoring and
 8.6 การเฝ้ าดูและการควบคุมความเสย
Control)
้
 9. การบริหารการจ ัดซือในโครงการ
(Project procurement
management)
ื้ (Procurement Planning)
 9.1 การวางแผนด ้านการจัดซอ
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
 คาถาม ………..