CHAPTER 5

1. CHAPTER 5 Defining and Managing Project Scope

2. Chapter 5 Objectives • ระบุถึง 5 กระบวนการที่สนับสนุนการบริหารขอบข่ายของโครงการ (project scope management) กระบวนการเหล่านี้ได้นิยามไว้ใน Project Management Body of Knowledge (PMBOK) ซึ่งประกอบด้วย initiation, planning, scope definition, scope verification และ scope change control. • อธิบายถึงความแตกต่างระหว่างขอบข่ายของผลิตภัณฑ์ (product scope) (นั่นคือ features และ functions ที่สนับสนุน IT solution) และขอบข่ายของโครงการ ( project scope) ( นั่นคือ deliverables และ activities ที่สนับสนุน IT project methodology).

3. Chapter 5 Objectives • กล่าวถึงกระบวนการนิยามขอบข่าย (scope definition process) และ สร้างโครงสร้างการแตกงาน (work breakdown structure) โดยใช้แนวทางของ analogy, top-down, bottom-up, และ mind mapping • ทำความเข้าใจถึงความสำคัญของการสอบทานขอบข่าย (scope verification) และ การควบคุมการเปลี่ยนขอบข่าย (scope change control) เพื่อหลบเลี่ยงการหลุดลอดออกนอกขอบข่าย (scope creep) ของ information technology projects • อธิบายให้เห็นว่าซอฟต์แวร์สามารถช่วย project scope management ได้อย่างไร

4. จงทำในสิ่งที่ต้องทำ และไม่ทำในสิ่งที่ไม่จำเป็นต้องทำ • ข้อบกพร่องอันเกิดจากการที่ไม่ได้กำหนดว่าส่วนต่าง ๆ ของโครงการนั้นคืออะไร(ทำให้ไม่ได้ทำ) และ ส่วนใดที่ไม่ใช่สิ่งที่ต้องทำในโครงการ (ทำให้ทำในสิ่งที่ไม่จำเป็นต้องทำ) อาจนำมาซึ่งผลลัพธ์อันเกิดจากการทำงานโดยไม่จำเป็นในการสร้างผลผลิตจากโครงการ มันจะนำไปสู่การเกินเวลา และงบประมาณที่ใช้ในโครงการนั้น ๆ Olde Curmudgeon, PM Network Magazine, 1994.

5. What is Project Scope Management? • ขอบข่ายหรือขอบเขต (Scope) หมายถึง งานทั้งหมดที่เกี่ยวข้องกับการสร้างผลิตผลต่าง ๆ ของโครงการ และ กระบวนการต่าง ๆ ที่สร้างผลิตผลเหล่านั้นขึ้นมา มันเป็นการนิยามทั้งสิ่งที่ต้องทำและสิ่งที่ไม่ต้องทำ • ดังนั้นจะเห็นว่า Scope คือ การกำหนดว่างานใดที่ต้องทำ และมีกระบวนการทำอย่างไรเพื่อให้ได้ผลิตผลของโครงการออกมา รวมไปถึง งานที่ไม่ต้องทำด้วย • สิ่งที่ต้องส่งมอบ (Deliverables) คือ ผลิตผลต่าง ๆ ที่สร้างขึ้นมาจากส่วนใดส่วนหนึ่งของโครงการ เช่น hardware หรือ software, planning documents, หรือ meeting minutes • Project team และ stakeholders ต้องมีความเข้าใจที่เหมือนกันว่า ผลิตผลอะไรที่จะถูก สร้างขึ้นมาซึ่งมันก็คือผลลัพธ์ของโครงการนั่นเอง ทั้งนี้รวมไปถึงว่า จะสร้างขึ้นมาได้อย่างไรด้วย

6. Project Scope Management Processes defined in PMBOK • สำหรับ Project Scope Management ใน PMBOK จะนิยามส่วนที่เกี่ยวข้องไว้ดังนี้ • Project scope initiation • Scope Planning • Scope definition • Scope verification • Scope change control

7. PMBOK Scope Management Processes

8. Project Scope Management Processes • ช่วงเริ่มต้น (Initiation):การเริ่มต้นโครงการหนึ่ง ๆ หรือเป็นการต่อเนื่องมาจากเฟสที่แล้ว (เพื่อก้าวสู่เฟสต่อไป) • การวางแผนขอบเขต (Scope planning):การจัดทำเอกสารต่าง ๆ เพื่อจัดเตรียมพื้นฐานสำหรับการตัดสินใจเกี่ยวกับโครงการในอนาคต • การกำหนดขอบเขต (Scope definition):การแบ่งสิ่งที่ต้องส่งมอบหลัก ๆ จากโครงการ (major project deliverables) ออกเป็นส่วนเล็ก ๆ เพื่อเป็นองค์ประกอบย่อย ๆ ซึ่งบริหารได้ง่ายขึ้น • การตรวจสอบขอบเขต (Scope verification):การยอมรับขอบเขตของโครงการอย่างเป็นทางการ • การควบคุมการเปลี่ยนแปลงขอบเขต (Scope change control):การควบคุมการเปลี่ยนแปลงใด ๆ ที่เกี่ยวข้องกับขอบเขตของโครงการ

9. Scope Management Plan

10. Project Initiation: Strategic Planning and Project Selection • เริ่มจาก มองภาพใหญ่ (ภาพรวม) หรือ แผนกลยุทธ์ขององค์กร • แผนกลยุทธ์จะมีสิ่งที่เกี่ยวข้อง (หรือ ชี้ให้เห็นถึง) กับ long-term business objectives • IT projects ควรเป็นไปเพื่อสนับสนุน strategic และ financial business objectives

11. Identifying Potential Projects • หลาย ๆ องค์กรดำเนินตามกระบวนการวางแผนสำหรับคัดเลือก IT projects • เริ่มด้วยการพัฒนา IT strategic plan ขึ้นมาโดยอ้างอิงจากแผนกลยุทธ์โดยรวมขององค์กร (organization’s overall strategic plan) • จากนั้นทำการวิเคราะห์ส่วนที่เกี่ยวข้องกับธุรกิจ (business area analysis) • แล้วทำการกำหนดโครงการที่เป็นไปได้ทั้งหลาย (potential projects) • จากนั้นทำการเลือก IT project และ กำหนดทรัพยากรต่าง ๆ ที่เกี่ยวข้อง

12. Information Technology Planning Process

13. Methods for Selecting Projects • โดยทั่วไปแล้ว จะมีโครงการต่าง ๆ มากมายให้ทำ เมื่อเทียบกับเวลาและทรัพยากรที่มีอยู่อย่างจำกัด ดังนั้นจึงถือเป็นเรื่องสำคัญที่จะต้องมีกระบวนการอย่างเป็นตรรกะ ในการคัดเลือกโครงการการ IT มาทำ • แนวทางเหล่านี้ได้แก่: • มุ่งเน้นไปที่ความต้องการของคนหมู่มาก (broad need) • การแบ่งโครงการออกเป็นหมวดหมู่ (categorizing projects) • การวิเคราะห์ทางด้านการเงิน (performing financial analyses) • การใช้แบบจำลองของค่าคะแนนแบบถ่วงน้ำหนัก (weighted scoring model) • การนำ balanced scorecard มาประยุกต์ใช้

14. Focusing on Broad Organizational Needs • มันเป็นเรื่องยากในการกำหนดแนวทางการตัดสินใจอย่างชัดเจนในโครงการ IT หลาย ๆ โครงการ แต่ส่วนมากแล้วเห็นตรงกันว่า จะต้องมีคุณค่าสูง (high value) • “เป็นเรื่องที่ดีกว่าที่จะใช้แนวทางการวัด goalอย่างคร่าว ๆ แทนที่จะไปคิดเล็กคิดน้อยทุก ๆ เรื่อง” • หลักการสำคัญสามแนวทางของโครงการคือ: • โครงการนั้น ๆ เป็นสิ่งที่ต้องการ • มีเงินทุนสนับสนุนอย่างพอเพียง • มีความมุ่งหวังอย่างแรงกล้าที่จะทำให้โครงการนั้นประสบผลสำเร็จ

15. Categorizing IT Projects • การแบ่งออกเป็นประเภท (categorization) นั้น จะหมายถึงโครงการนั้นบ่งชี้ไปในเรื่องใด (ดูที่ทิศทางของโครงการนั้น ๆ ชี้ไป) • ปัญหาเรื่องหนึ่ง • โอกาสด้านหนึ่ง • มุ่งตรงไปทางใดทางหนึ่ง • การแบ่งอีกแบบหนึ่งก็คือดูว่าโครงการนั้น ๆ ใช้เวลานานเท่าใด และ จะทำ (หมายถึงต้องการใช้ผลจากโครงการนั้น)เมื่อใด (ดูที่ระยะเวลาและวันที่จะลงมือทำ) • อีกแบบหนึ่งก็คือ ใช้ลำดับความสำคัญของโครงการในภาพรวมทั้งหมด(ใช้สิ่งข้างต้นมารวมเข้าด้วยกันเพื่อจัดลำดับความสำคัญ)

16. Financial Analysis of Projects • การพิจารณาทางด้านการเงินมักจะถูกนำมาใช้เป็นหัวข้อหลักในการพิจารณาคัดเลือกโครงการต่าง ๆ • สามวิธีการหลัก ๆ ที่นำมาใช้กำหนดมูลค่าของโครงการได้แก่: • Net present value (NPV) analysis • ผลตอบแทนในการลงทุน (Return on investment (ROI)) • การวิเคราะห์การคืนทุน (Payback analysis) • Payback Analysis • สิ่งที่สำคัญอีกประการหนึ่งที่นำมาใช้พิจารณาก็คือ ระยะเวลาคืนทุน (payback period) ซึ่งก็คือ ใช้เวลานานเท่าใดจึงจะได้เงินที่ลงทุนไปกลับคืนมา • หลาย ๆ องค์กรต้องการ IT projects ที่มีระยะเวลาในการคืนทุนสั้น

17. Weighted Scoring Model • Weighted scoring model คือ เครื่องมือที่มีกระบวนการอย่างเป็นระบบ ( systematic process) ในการเลือกโครงการต่าง ๆ บนพื้นฐานของหลายแนวทาง • เริ่มจาก ระบุสิ่งสำคัญ (criteria important) ให้กับกระบวนการเลือกโครงการ • จากนั้นกำหนดค่าน้ำหนัก (จำนวนเปอร์เซ็นต์)ให้แต่ละ criterion ซึ่งรวมกันแล้วต้องได้เท่ากับ 100% • แล้วกำหนดคะแนนให้กับแต่ละ criterion ในแต่ละโครงการ • คูณค่าคะแนนเข้ากับค่าน้ำหนักแล้วคำนวณผลรวมของคะแนนที่ผ่านการถ่วงน้ำหนักแล้วทั้งหมด • ผลรวมของคะแนนที่ผ่านการถ่วงน้ำหนักแล้ว มีค่ามากจะดีกว่า

18. Weighted Scoring Model for Project Selection คิดแค่ 25% ของ 90 +

19. Implementing a Balanced Scorecard • Dr. Robert Kaplan และ David Norton ได้พัฒนา Balanced scorecard ขึ้นมา สามารถนำมาใช้เป็นแนวทางในการเลือกและบริหารโครงการได้โดยทำการ align เข้ากับ business strategy • Balanced scorecard จะเปลี่ยนตัวขับดันที่มีคุณค่าต่อองค์กร เช่น การบริการลูกค้า นวัตกรรม ประสิทธิภาพในการทำงาน และ ประสิทธิภาพทางการเงินให้อยู่ในรูปของอนุกรมของตัววักต่าง ๆ • See www.balancedscorecard.org for more information

20. Project Charters • หลังจากตัดสินใจว่าจะทำโครงการใดแล้ว สิ่งที่สำคัญต่อมาก็คือทำให้โครงการเกิดขึ้นอย่างเป็นทางการ (formalize projects) ผ่านทาง Project Charter • Project charter คือเอกสารที่ใช้แสดงอย่างเป็นทางการถึงการเกิดขึ้นของโครงการนั้น ๆ พร้อมทั้งบอกถึงทิศทางของวัตถุประสงค์และการบริหารโครงการนั้น ๆ • ผู้เกี่ยวข้องกับโครงการที่มีความสำคัญ (Key project stakeholders) จะต้องลงนามใน Project charter เพื่อแสดงการรับรู้ถึงข้อตกลงในสิ่งที่ต้องการและความคาดหวัง จากโครงการนั้น

21. Scope Planning and the Scope Statement • Scope statement คือเอกสารที่ใช้ในการสร้างและยืนยันถึงความเข้าใจร่วมกันเกี่ยวกับ project scope • ควรประกอบด้วย • การตัดสินใจในโครงการนั้น (project justification) • กล่าวสั้น ๆ เกี่ยวกับผลิตผลที่ได้จากโครงการ (project’s products) • ข้อสรุปของ project deliverable ทั้งหมด • ถ้อยแถลงอันแสดงให้เห็นว่า สิ่งที่แสดงว่าโครงการประสบผลสำเร็จนั้นคืออะไร

22. Scope Planning and the Work Breakdown Structure • หลังจากเสร็จเรื่อง scope planning แล้ว ขั้นตอนต่อไปคือการกำหนดงานที่ต้องทำโดยการแตกออกเป็นส่วนย่อย ๆ ที่สามารถบริการได้ง่าย • การกำหนดขอบเขตที่ดี จะช่วยให้ • ช่วยปรับปรุงในเรื่อง accuracy of time, cost, และ resource estimates • กำหนด baseline ของ performance measurement และ project control • ช่วยในการสื่อสารในเชิง clear work responsibilities

23. Scope Boundary อะไรที่ต้องทำ อะไรที่ไม่ต้องทำ (แต่ควรรู้)

24. Sample Scope Statement – What’s within the scope boundary • พัฒนา proactive electronic commerce strategy ซึ่งบ่งชี้กระบวน ผลิตภัณฑ์ และ การให้บริการต่าง ๆ ซึ่งจะถูกส่งมอบผ่านทาง World Wide Web. • พัฒนา application system เพื่อสนับสนุนกระบวนการ ผลิตภัณฑ์ และการให้บริการต่าง ๆ ทั้งหมดที่ถูกระบุอยู่ใน electronic commerce strategy. • ควบรวม application system เข้ากับ bank’s existing enterprise resource planning system. • Sample Scope Statement – Work outside the scope boundary • การตรวจประเมิน เทคโนโลยีและองค์กรในสภาพแวดล้อมปัจจุบัน • Customer resource management and data mining components

25. Project Scope Definition • Project-Oriented Scope • สิ่งที่ต้องส่งมอบซึ่งสนับสนุน project management และ IT development processes ที่ถูกกำหนดไว้ใน Information Technology Project Methodology (ITPM). ตัวอย่างเช่น • Business case, project charter and project plan, etc. • Product-Oriented Scope • โครงร่าง (Feature) และฟังก์ชัน (Functional) ในระดับสูงของ application system • เป็นการนิยามถึงความต้องการฉบับแรกซึ่งถูกนำมาใช้เพื่อทำรายละเอียดให้มากขึ้นในขั้นตอน systems development life cycle (SDLC) ตัวอย่างเช่น • เพิ่มลูกค้าใหม่ ตรวจสอบลูกค้าเดิมที่เหลืออยู่ พิมพ์รายงานการขายรายวันของแต่ละพื้นที่ ฯลฯ

26. Project Scope Definition • Project-Oriented Scope Definition Tools • Deliverable Definition Table (DDT) • Deliverable Structure Chart (DSC)

27. Deliverable Definition Table

28. Deliverable Structure Chart

29. Project Scope Definition • ขอบเขตอันแสดงถึงรายละเอียดของโครงสาร (Product-Oriented Scope) • เครื่องมือต่าง ๆ ที่ใช้กำหนด Product-Oriented Scope ได้แก่ • ผังแสดงการไหลของข้อมูล (Data Flow Diagrams (DFD)) • Use Case Diagram • Joint Application development (JAD)

30. Context Level Data Flow Diagram

31. Use Case Diagram

32. Project Scope Verification Check List • MOV • Project’s MOV ได้ถูกนิยามไว้ชัดเจนหรือไม่ และทุกคนเห็นด้วยหรือไม่ ? การที่ไม่เป็นดังกล่าวมาข้างต้น จะส่งผลให้มีการเปลี่ยนแปลง scope ในภายหลัง ซึ่งนำไปสู่ การทำงานเพิ่มขึ้นอันส่งผลกระทบต่อ project’s schedule and budget. • Deliverables (สิ่งที่ต้องส่งมอบ) • สิ่งที่ต้องส่งมอบเป็น tangible และ ตรวจได้ใช้หรือไม่? • และสิ่งข้างต้นสนับสนุน project’s MOV หรือไม่ ? • Quality Standards (มาตรฐานที่เกี่ยวข้อกับคุณภาพต่าง ๆ) • มีการควบคุมใด ๆ ในที่นั้น ๆ ที่ทำให้มั่นใจว่า งานที่แล้วเสร็จนั้นตรงตามมาตรฐานที่กำหนด?

33. Scope Verification Check List • Milestones (ตัวชี้วัดระดับขั้นของความสำเร็จ) • มีสิ่งที่สำคัญ (ใช้เป็นเครื่องหมาย)อันแสดงถึงการยอมรับสิ่งที่ส่งมอบ (deliverable) และ ทำให้ project manager และ team ได้รับการอนุมัติเพื่อเริ่มต้นทำงานเพื่อให้ได้next deliverable พูดสั้น ๆ ว่า milestones จะบอกเราว่า deliverable ไม่เพียงแต่เสร็จสิ้นแล้วเท่านั้น แต่ยังผ่านการทวนสอบและยอมรับแล้ว • Review and Acceptance (การทวนสอบและการยอมรับ) • สุดท้าย Project’s scope จะต้องถูกทบทวนและยอมรับโดย project stakeholders ดังนั้น Project sponsor จะต้องยอมรับอย่างเป็นทางการในด้าน boundary, product to be produced และ the project-related deliverables ในทางกลับกัน Project team ต้องยอมรับและเห็นอย่างชัดเจนว่าอะไรที่ต้องส่งมอบ

34. Scope Verification and Scope Change Control • มันเป็นเรื่องยากในการสร้างgood scope statement และ WBS ให้กับโครงการหนึ่ง ๆ • และเป็นเรื่องที่ยากมากกว่าในการตรวจสอบขอบเขตของโครงการ (verify project scope) และ ลดการเปลี่ยนแปลงต่าง ๆของเขตให้ต่ำที่สุด (minimize scope changes) • หลาย ๆ โครงการของ IT เจ็บปวดกับสิ่งที่หลุดลอดออกไปจากการกำหนดเอาไว้ในขอบเขต (scope creep) และ ทำการตรวจสอบขอบเขตได้ไม่ดี ( poor scope verification) • FoxMeyer Drug filed for bankruptcy after scope creep on a robotic warehouse • Engineers at Grumman called a system “Naziware” and refused to use it • 21st Century Insurance Group wasted a lot of time and money on a project that could have used off-the-shelf components

35. Factors Causing IT Project Problems

36. Scope Change Control • ต้องมั่นใจว่า การเปลี่ยนแปลงใด ๆ ที่เกี่ยวกับขอบเขตของโครงการจะต้องเป็นไปเพื่อช่วยให้โครงการบรรลุถึง MOV ที่กำหนดไว้ • จะต้องรักษาให้ “triple constraint” อยู่ในสภาพที่สมดุล • นั่นคือ ทำการเพิ่ม scope อาจจำเป็นต้องเพิ่ม project’s schedule และ budget. Schedule Scope Budget

37. Scope Change Control • การควบคุมการเปลี่ยนแปลงขอบเขตของโครงการ จะเกี่ยวข้องกับ • Scope grope (grope = คลำ, ค้นหา) เช่น การนิยามไม่ชัดเจน • Scope creep (creep = หลุดเล็ดรอด) เช่น เพิ่ม Feature เข้าไปเรื่อย ๆ • Scope leap (leap = กระโดด ปรับ) เช่น การเปลี่ยนทิศทางของโครงการ หรือ เปลี่ยน MOV ของโครงการ

38. Scope Change Control • ความลึกลับของการบริหารขอบเขต (Myths of Scope Management) • การมีส่วนร่วมของผู้ใช้จะให้ผลลัพธ์ที่ได้จาก IS project เป็นจริงตรงตามความต้องการของธุรกิจ • Scope statement จำต้อกำหนดอย่างชัดเจนว่าโครงการจะทำอะไร • หลังจากกำหนดแล้ว ทุกคนที่เกี่ยวข้องต้องถือตามนั้นเพราะว่าความผันแปรใด ๆ ที่เบี่ยงเบนออกไปจากแผนเริ่มต้นคือเครื่องหมายที่แสดงถึงโครงงานเริ่มออกจากการควบคุม • ฟังก์ชันของคณะทำงานเกี่ยวกับการเปลี่ยนแปลงของขอบเขตต้องแสดงถึงความต้องการของผู้ใช้ในการเพิ่ม features หรือ functionality หลักจากเกิด original project charter แล้ว • การประชุมตามกำหนดหรือบ่อย ๆ กับ senior management จะทำให้มั่นใจได้ว่า จะได้รับข้อมูลที่ทันสมัยและจะทำให้ได้รับผลและการสนับสนุนที่ดี

39. Scope Change Control ProceduresScope Change Request Form

40. Scope Change Control ProceduresScope Change Request Log

41. Benefits of Scope Control • ทำให้ project manager ยังสามารถควบคุมโครงการได้ • ทำให้ project manager ควบคุม project’s schedule และ budget ได้ • ทำให้ project team มามุ่งเน้นในเรื่องที่ควรทำและทำเรื่องที่ควรทำ

42. Scope Management Process

43. Suggestions for Improving User Input • พัฒนา good project selection process และช่วย sponsors ให้ได้ข้อมูลมาจากผู้ใช้ในองค์กร • การมีผู้ใช้อยู่ใน project team ถือเป็นเรื่องที่สำคัญและควรทำ • มีการประชุมเป็นประจำ (ตามที่กำหนดเอาไว้) • มีการส่งมอบบางสิ่งบางอย่างให้กับผู้ใช้ต่าง ๆและ sponsors ตามที่กำหนดไว้ • ร่วมมือกับผู้ใช้ในพื้นที่นั้น ๆ เพื่อทำการพัฒนา

44. Suggestions for Reducing Incomplete and Changing Requirements • พัฒนาและติดตามกระบวนการบริหารตามความต้องการ (requirements management process) • ใช้ prototyping, use case modeling, และ JAD เพื่อให้ได้รับความร่วมมือจากผู้ใช้ • Document requirements และ keep them current • จัดทำการทดสอบอย่างพอเพียงและทำการทดสอบตลอด project life cycle • ทวนสอบการเปลี่ยนแปลงจากมุมมองเชิงระบบ (systems perspective) • การเน้นที่ completion dates จะช่วยมุงเน้นว่า อะไรสำคัญที่สุด • การเคลื่อนย้ายทรัพยากร โดยเฉพาะอย่างยิ่งhandling change requests/ enhancements ต้องระมัดระวัง

45. จบหัวข้อ 5 • คำถาม ………..