ความคิดเห็นที่เป็นรูปธรรมที่สุดที่ผมได้รับจากการใช้หลักการ PERT ในการคำนวณหาความคืบหน้าของโปรเจกต์คือตัวเลขที่ได้มันออกจะ Subjective นะ … ไม่รู้จะใช้ภาษาไทยว่าอะไรครับ คงประมาณว่าเป็นตัวเลขที่มาจากตัวเองคนเดียว ไม่มีที่มาที่ไป อธิบายด้วยวิทยาศาสตร์หรือตัวเลขได้ยาก … ขออะไรที่มันน่าเชื่อถือกว่านี้ได้มั้ย ฮ่าๆๆ ก็เป็นโจทย์ให้มานั่งแก้ครับ?เหตุผลหลักๆที่ก่อให้เกิดข้อสงสัยในประเด็นนี้ขึ้นมาผมคิดว่ามีอยู่ซักสองสามข้อนะครับ

I want a detailed plan that describes project tasks.

จาก Template เก่า ผมไม่ได้ระบุรายละเอียดของงานที่ต้องทำในโปรเจกต์เลยนะครับ ถึงตรงนี้ต้องทำแล้วหละครับเพราะในการทำงานจริงคงเป็นเรื่องยากที่จะประเมินความคืบหน้าของโปรเจกต์ในอากาศ และมันก็ยากที่ใครจะเข้าใจและเข้าถึงสิ่งที่เราประเมินไป Template ใหม่นี้จะมี Sheet ใหม่ให้เพื่อนๆใส่ Project Task เข้าไปได้ครับ

The complexity of the tasks is not equally distributed.

การมี Project Task เป็นแค่จุดเริ่มต้นในการสร้างความโปร่งใสในการประเมินความคืบหน้าของโปรเจกต์ครับ หลักการง่ายๆที่สำคัญคือ

การที่ทำงานเสร็จ 5 จาก 10 งาน ไม่ได้แปลว่าเราทำงานเสร็จแล้ว 50%

เพราะเวลาที่ใช้หรือความยากง่ายในแต่ละงานไม่ได้เท่ากันนั่นเอง ดังนั้นก็เป็นเรื่องสำคัญที่เราต้องเอาเรื่องนี้มาคิดด้วยครับ ในการ Estimation คำถามที่เจอบ่อยคือ หนึ่งคุณคิดว่าจะใช้เวลาทำงานนี้กี่วัน หรือ สองคุณคิดว่างานนี้ยากแค่ไหน ส่วนตัวแล้วไม่ค่อยชอบ Estimate ด้วยระยะเวลานะครับเพราะดูเหมือนความคลาดเคลื่อนจะสูงและเอาข้อมูลมาประยุกต์ใช้ภายหลังยาก (ไว้ขยายความในบทความถัดๆไปครับ) งั้นตอนนี้ผมขอเลือกเป็นข้อสองนะ … คุณคิดว่างานนี้ยากแค่ไหน แล้วยังไงต่อหละ มันจะมาช่วยเราให้หาตัวเลขความคืบหน้าของโปรเจกต์ได้ตรงขึ้นยังไง?


จากรูปครับ ตัวแปรที่สำคัญคือ (1) Complexity และ (2) % Progress … ผมเลือกใช้ตัวเลข 0-5 ในการอธิบายความยากง่ายของงาน คล้ายๆการหา Story Point ใน Agile Development โดย 1 ง่ายสุด 5 ยากสุด ส่วน 0 คือไม่แน่ใจ (เดี๋ยวกลับมา Estimate ทีหลัง) ขั้นตอนนี้ควรทำตอนต้นๆของโปรเจกต์นะครับ มันคือการทำ Estimation นั่นเอง

ขั้นต่อมาคือการทำ Project Tracking ที่เราจะดูว่างานแต่ละงานมีความคืบหน้าไปถึงไหนแล้ว เลือกตัวเลขที่คิดว่าใกล้เคียงที่สุดในช่อง % Progress ครับ จากนั้นการคำนวณจะเกิดขึ้น ตัวเลขที่จะได้คือค่า Normalized % Progress ของแต่ละงานซึ่งเป็นค่าที่เทียบน้ำหนักกับงานอื่นๆในโปรเจกต์ทั้งหมดแล้ว ง่ายๆนะครับ

1. ผลรวมของค่า Complexity ของทุกงานจะเป็นตัวตั้ง จากในรูปค่านี้คือ 22 ซึ่งคิดเป็น 100% ของงานที่ต้องทำ
2. คำนวณ Complexity ของแต่ละงานเทียบกับค่า 22 เพื่อหาว่างานนั้นมีความยากเป็นร้อยละเท่าไรของงานทั้งหมด เช่น งานที่หนึ่งมีความยาก 2 จาก 22 แสดงว่ามันคิดเป็น 0.0909% ครับ
3. สุดท้ายค่า % Progress ของแต่ละงานจะถูกถ่วงน้ำหนักด้วยค่า % ความยากของมันเอง เช่น ถ้างานที่หนึ่งเสร็จแล้ว % Progress = 100 แต่เมื่อเทียบกับความยากรวมแล้ว การทำงานนี้เสร็จจะคิดเป็นแค่ 0.09% x 100% = 9.09% (% Normalized Progress) ของความคืบหน้าทั้งหมดของโปรเจกต์เท่านั้นเองครับ

เมื่อใช้หลักการเดียวกันกับทุกงานที่มีแล้ว เราจะได้ค่าความคืบหน้าโดยรวมของโปรเจกต์ที่ละเอียดขึ้นมาใช้แทนการคำนวณด้วย PERT

I have no or little experience about this type of project.

เนื่องจากการคำนวณแบบเก่ามีพื้นฐานมาจากตัวบุคคลเป็นหลักนะครับ ด้วยประสบการณ์ในงานจะช่วยให้เราคาดคะเนความคืบหน้าของโปรเจกต์ได้ง่ายขึ้นใกล้เคียงความจริงมากขึ้น … แต่สำหรับคนที่เพิ่งเข้ามาทำงานนี้หละจะทำยังไง มึนแน่นอน การมี Detailed Project Plan จะช่วยท่านได้ด้วยประการฉะนี้แล

เลือกได้นะครับว่าอยากจะใช้ PERT หรือ Complexity เพื่อคำนวณหาความคืบหน้าของโปรเจกต์ ไม่มีข้อจำกัดอันใด ขึ้นอยู่กับสถานการณ์ของแต่ละคนครับ ลอง Download Template ใหม่ (Project_Dashboard_20130203.xlsx) ไปใช้ดู … ป.ล. อันใหม่นี้ใช้วันหยุดราชการในการคำนวณหา Forecast Date และ Schedule Variance แล้วด้วยครับ

ยังไม่จบนะ มีอีกเรื่อยๆ

วันนี้ตั้งใจจะขยายความหลักการที่ใช้ในบทความที่แล้วและสูตรคำนวณที่ผมใช้ใน Template นิดนึงครับ หลักการที่สำคัญที่สุดเลยก็คือ “การใช้ข้อมูลในอดีตเพื่อคาดคะเนอนาคต”

Historical Data and Personal View

การใช้ข้อมูลในอดีตเพื่อคาดคะเนอนาคตเป็นเรื่องสามัญมาก เท่าที่เข้าใจเราใช้หลักการนี้ในทุกๆวงการ … การพยากรณ์อากาศ, คาดคะเนการเติบโตทางเศรษฐกิจ, วิเคราะห์ตลาดหุ้น, หรือแม้แต่โหราศาสตร์ ในมุมมอง Project Management ก็เช่นกันครับ ตัวอย่างเช่น Software Estimation หรือ Risk Management แน่นอนคนมีประสบการณ์จะให้ตัวเลขหรือข้อมูลที่ใกล้เคียงความจริงมากกว่าคนที่ไม่มีประสบการณ์ ที่เป็นเช่นนี้ (ผมเทียบกับตัวเองนะ) เพราะเราใช้ความรู้และข้อมูลหรือเหตุการณ์ในอดีตมาเป็นข้อมูลในการวิเคราะห์ เช่น การ Implement ตรงนี้ต้องมีการสร้าง Class ใหม่, UI ใหม่, Database ใหม่ งานเยอะมาก แถมยังต้องดูเรื่อง Response time ของ Web Page ด้วย … แบบนี้ต้องใช้เวลาอย่างน้อยๆ 2 สัปดาห์แน่ๆเลย หรือว่าการกำหนดวันปิดโปรเจกต์ไว้ช่วงครึ่งหลังของเดือนธันวาคมต้องมีปัญหาแน่เพราะมีคนเตรียมลาพักร้อนเยอะเลย แบบนี้เราต้องเตรียมการไว้แต่เนิ่นๆซะแล้ว เป็นต้น

เมื่อมองย้อนไปในบทความที่แล้ว ผมใช้หลักการวิเคราะห์อดีตเพื่อคาดคะเนอนาคตในตอนที่คำนวณหา Project Forecast Date นั่นเอง … เราทำงาน 40% เสร็จใน 20 วัน … อดีต นั่นน่าจะแปลว่าเราคงทำงานที่เหลืออีก 60% เสร็จใน 30 วันนะ … อนาคต ง่ายๆไม่ซับซ้อนครับ

ในอีกมุมหนึ่ง “มนุษย์ไม่ใช่เครื่องจักร ต้องการความรักและความเข้าใจ” … คนเรามีความคิดและมุมมองเป็นของตัวเองทุกคนครับ ใน Project Management ก็เช่นกัน มันเป็นทั้งศาสตร์ (Historical Data) และศิลป์ (Personal View) เพราะเราไม่สามารถจะยึดติดอยู่กับตัวเลขแล้วมองข้ามมุมมองของมนุษย์ไปได้ ผมกำลังชี้ให้เห็นว่าเราในฐานะคนดูแลโปรเจกต์มักจะมีความรู้สึกหรือลางสังหรณ์ว่าจะมีเรื่องไม่ดีเกิดขึ้นกับงานของเราอยู่ตลอดเวลา ไม่ว่าจะคนลาออก, เครื่อง Server เจ๊ง, Vendor เบี้ยวงาน, ลูกค้าขอเปลี่ยน Requirement, เจอบั๊กวันสุดท้าย, และอื่นๆอีกมากตาม Murphy’s Law ผมเลยคิดว่าควรต้องหาทางที่จะนำความกังวลใจเหล่านี้เข้ามาเป็นหนึ่งใน Input ของการคำนวณหา Project Forecast Date ด้วย และสิ่งที่ช่วยผมได้ตรงนี้คือการประยุกต์ใช้ PERT Technique ซึ่งเราสามารถระบุค่า Best, Most Likely และ Worst ของ Project Progress ได้

หลักการง่ายๆที่ผมใช้ก็คือ ถ้าผมมองแล้วว่าความกังวลใจหรือความเสี่ยงที่มีอยู่นั้นมีโอกาสเกิดขึ้นสูง ผมก็จะพยายามกดให้ Project Progress ต่ำไว้หน่อยเพื่อเป็นการรองรับปัญหาที่อาจจะเกิดขึ้นและการคำนวณ Project Forecast Date จะได้ออกมาเชื่อถือได้มากขึ้น เช่น จริงๆแล้วผมว่างานผมเสร็จแล้วนะ 50% เพราะ Implementation Phase จบหมดแล้ว แต่ผมกังวลว่าจะต้องมีปัญหาเรื่อง Performance ของระบบแน่ๆเลย ผมจึงระบุ Project Progress ของผมเป็นแบบนี้ครับ

• Best = 50% (ไม่มีปัญหา Performance เกิดขึ้นในอนาคต)
• Most Likely = 40% (คิดว่าน่าจะมีปัญหาให้ต้องแก้ซักหน่อยแหละ แต่คงไม่เยอะมากนะ)
• Worst = 35% (อันนี้ชีวิตบัดซบเลย ต้องรื้อโค๊ดส่วนนี้กันใหม่เพราะ Performance ห่วยจัด)

เมื่อกำหนดตัวเลขไว้แบบนี้ สิ่งที่ได้ตามมาคือปริมาณงานที่เหลือนั่นเองครับ จะเป็น 50%, 60% และ 65% ตามลำดับ เข้าสูตร PERT แล้วจะได้ค่าเฉลี่ย Project Progress ออกมาเป็น 40.83% ซึ่งนั่นจะทำให้ Project Forecast Date ของเราสะท้อนให้เห็นค่าเฉลี่ยที่เหมาะสมของงานที่เหลืออยู่ (100-40.83 = 59.17%) ครับ

Input

เนื่องจากผมใช้ทั้ง Historical Data และ Personal View ในการสร้าง Template นี้ขึ้นมาครับ ข้อมูลที่ Template นี้ต้องการเพื่อใช้ในการคำนวณก็จะมีอยู่สี่ค่าดังนี้

1. วันเริ่มโปรเจกต์ – Project Start Date: ควรเป็นค่าคงที่ ใส่ครั้งแรกครั้งเดียว
2. วันจบโปรเจกต์ – Project End Date: ควรเป็นค่าที่ไม่เปลี่ยนแปลง แต่ก็เป็นไปได้ที่จะเลื่อนเข้าหรือเลื่อนออกแล้วแต่สถานการณ์ครับ
3. วันทำรายงานฉบับนี้ – Project Reporting Date: คือวันที่ปัจจุบันที่เราต้องการใช้เป็นหมุดในการคำนวณ
4. ความก้าวหน้าของโปรเจกต์ – Project Progress: ทั้งสามค่าเลยครับ Best, Most Likely, และ Worst

ผลลัพธ์จากการคำนวณคือ

1. ความก้าวหน้าของโปรเจกต์โดยเฉลี่ย – Average Project Progress: ตัวเลขนี้ได้มาจากการคำนวณด้วย PERT technique
2. วันที่คาดว่าโปรเจกต์จะเสร็จ – Project Forecast Date: มาจากการคำนวณด้วยหลักการ “”การใช้ข้อมูลในอดีตเพื่อคาดคะเนอนาคต” ลองดูได้จากรูปในบทความที่แล้วครับ
3. ความคลาดเคลื่อนของวันที่โปรเจกต์เสร็จ – Schedule Variance: ตัวเลขที่แสดงผลว่าตอนนี้งานของเราเสร็จก่อนกำหนด (ค่าลบ), ตามกำหนด (เท่ากับศูนย์) หรือช้ากว่ากำหนด (ค่าบวก) กี่เปอร์เซ็นต์

ลองดูตัวอย่างจากรูปนะครับ

Forecast Date Calculation

การคำนวณ Forecast Date นั้น ผมใช้สูตร NETWORKDAYS() ใน Microsoft Excel ซึ่งจะตัดวันเสาร์-อาทิตย์ทิ้งไปในช่วงเวลาระหว่าง Start Date ถึง Reporting Date ครับ เช่น ถ้า Start Date คือ 1 มกราคม และ Reporting Date คือ 13 มกราคม เราจะนับจำนวนวันทั้งหมดได้ 13 วัน แต่ NETWORKDAYS() จะคำนวณได้ค่าออกมาแค่ 9 วันครับ ตรงนี้สังเกตเห็นความผิดปกติอะไรมั้ยครับ? … ใช่ครับ วันที่ 1 มกราคมมันเป็นวันหยุดนะ ควรจะถูกตัดออกด้วยเช่นกัน ผมกำลังจะบอกว่า Template นี้ยังไม่ได้พิจารณาถึงวันหยุดราชการเลย ไว้จะแก้ให้ใน Template version ถัดไปครับ

สงสัยมั้ยครับว่าผลต่างของจำนวนวันไม่กี่วันมันมีผลกับผลลัพธ์มากขนาดนั้นเลยหรอ? … สำหรับผมก็มีบ้างนะครับ ยิ่งโปรเจกต์สั้นๆจะยิ่งเห็นผลครับ ลองดูจากรูป?และถ้าเป็นไปได้ก็อยากให้ผลออกมาตรงที่สุดเลยต้องคิดถึง NETWORKDAYS() และ Holidays ด้วยครับ


ถ้าถามว่า Forecast Date ตรงแค่ไหน ก็ขึ้นอยู่กับคุณภาพของ Input ครับ ถ้าเราประเมิน Project Progress ได้ดี ผลลัพธ์ก็น่าจะออกมาเชื่อถือได้พอสมควร แต่มันก็จะไม่เป๊ะๆ 100% หรอกครับว่างานเราจะเสร็จวันที่ 8 กุมภาพันธ์ หรือ 18 มีนาคม แนวคิดความสำคัญของ Forecast Date คือสิ่งที่จะช่วยบอกเราได้ว่า “ถ้ามัน Delay … มันไปไกลขนาดไหนแล้ว”

Schedule Variance Ranges

Template นี้สามารถแสดงผลเป็นสีที่ต่างกันได้ใน Schedule Variance ครับ ผมตั้งใจให้เป็นแบบนั้นเพื่อกระตุ้นความสนใจของคนอ่านโดยเฉพาะอย่างยิ่งถ้ามันเป็นสีแดง ฮ่าๆ เงื่อนไขที่ผมใช้ดูได้จากรูปครับ

อาจจะมีข้อสงสัยกันว่าทำไมผมถึงกำหนดให้โปรเจกต์ยังเป็นสีเขียวถึงแม้ว่าจะมี Schedule Variance มากกว่าศูนย์ (แต่ไม่เกิน 10) … มากกว่าศูนย์มันคือ Delay แล้วนี่หน่า ก็จริงครับ Delay แล้วแต่ผมมองว่าโดยทั่วไปเป็นการยากที่จะควบคุมให้งานในโปรเจกต์เดินไปตามที่วางแผนไว้เป๊ะๆครับ มันต้องมีแน่ๆซักช่วงเวลาหนึ่งที่โปรเจกต์เรา Delay หรือเสี่ยงที่จะ Delay ผมเลยเผื่อตัวเลข 10% ไว้เพื่อรองรับสถานการณ์แบบนั้น เราในฐานะคนดูแลโปรเจกต์ก็ควรจะเข้าใจในความหมายของมันว่าถึงแม้จะเขียวแต่สถานการณ์ก็ไม่ดีเท่าไรแล้วนะ ต้องลองดูว่ามันเกิดอะไรขึ้นและจะแก้ไขปัญหาพวกนั้นอย่างไรเพื่อดึงให้โปรเจกต์กลับมาดูดีเหมือนเดิม

ผมพูดเผื่อไปสำหรับบทความหลังๆด้วยเลยครับว่า การจะตัดสินว่าโปรเจกต์ของเราก้าวหน้าไปตามแผนหรือไม่จะดูแค่ Schedule Variance ไม่ได้ครับ มันมีปัจจัยอื่นๆอีกมากมายที่ผมยังไม่ได้กล่าวถึง เช่น Scope … เราทำงานครบทุก Requirement ตามที่ระบุไว้หรือไม่? (ถ้าจะทำให้ Schedule Variance กลับมาเขียว ง่ายๆเลยก็ตัดงานที่ยังไม่ได้ทำทิ้งไปครับ … เขียวชัวร์ แต่มันก็ไม่ใช่การจัดการที่ดีหรอก) หรือ Quality เป็นอย่างไร? … ถ้าเราเจอ Bugs มากมายแบบนี้เราคงพูดได้ไม่เต็มปากว่าโปรเจกต์เรายังดูดีอยู่ … แล้วเรื่อง Risk หละ ได้พิจารณาถึงมันอย่างรอบคอบหรือยัง … เรารู้ทั้งรู้ว่าเดือนหน้าจะมีน้องในทีมลาออกพร้อมกัน 2 คน ต่อให้เดือนนี้โปรเจกต์เรายังสีเขียวอยู่ แต่เดือนหน้าหละ? คงไม่เขียวแล้วมั้ง … ประมาณนี้ครับ

ไว้ผมจะกลับมาเล่าให้ฟังอีกทีเรื่องตัวเลขที่ช่วยให้เราเห็นภาพรวมของโปรเจกต์ได้ชัดเจนขึ้นครับ

เคยสงสัยมั้ยครับว่า “โปรเจกต์นี้จะเสร็จวันไหน?” บางคนตอบได้ทันทีแบบไม่ต้องคิดมากว่า “ก็วันนั้นแหละ วันที่บอกไว้ว่าจะเสร็จ, วันสุดท้ายที่อยู่ใน Project Plan, วันที่อยู่ในสัญญา, อื่นๆ” ถามว่าผิดมั้ย ก็ไม่ผิดนะครับเพราะถึงแม้จะมีอุปสรรคแค่ไหนเราก็มีหน้าที่ต้องเข็นโปรเจกต์ของเราให้เสร็จตามที่ให้คำมั่นสัญญาไว้อยู่แล้ว

ขอเปลี่ยนคำถามใหม่ “คุณมั่นใจแค่ไหนว่าโปรเจกต์ของคุณจะเสร็จตรงเวลา?” อ้าาา … ตอบยากขึ้นมานิดนึงแล้วหละซิ ก็เพราะระหว่างทำงานมันมีเรื่องราวมากมายที่เป็นปัจจัยที่จะทำให้งานเราเสร็จหรือไม่เสร็จตามเป้าหมาย ถ้ามันมีแนวโน้มว่าจะเสร็จไม่ทันจริงๆผมอยากรู้ครับว่า “มันร้ายแรงขนาดไหน” ว่าแล้วก็ลองคิดหาวิธีคำนวณความคลาดเคลื่อนนี้ออกมาเป็นตัวเลขดูครับ

ปล.1 Earned Value Management (EVM) เป็นหนึ่งในทฤษฎีที่ตอบโจทย์เราได้ แต่ผมคิดว่ามันวุ่นวายไปมากและมีปัจจัยอื่นๆหลายอย่างที่อาจจะทำให้ค่ามันคลาดเคลื่อนไปอยู่ดี ขอตัดออกด้วยความขี้เกียจ

ปล.2 Velocity and Burndown Chart ของ Agile ก็เป็นอีกทฤษฎีที่ใช้ได้เลย แต่ว่ากับบางคน บางทีมก็ไม่พร้อมจะปรับตัวให้มาใช้การทำ Project Plan แบบนี้ (ตัวผมเองก็ด้วย ) ว่าแล้วก็ขอตัดออกอีกเช่นกัน

Forecast Date

เริ่มต้นจากศูนย์ รู้อย่างเดียวคือเป้าหมายของผมมีอยู่ว่า ถ้ามันจะช้าผมอยากรู้ว่ามันไปไกลแค่ไหนแล้ว … “ไปไกลแค่ไหนแล้ว” มันคือวันที่เราคาดคะเนว่าโปรเจกต์จะเสร็จ หรือ Forecast Date นั่นเองครับ แล้วผมจะหาวันที่นี้มาได้ยังไง? หลักการที่ผมคิดได้แบบง่ายๆตอนนี้ประกอบด้วยสองขั้นตอน

1. เรารู้วันเริ่มต้นของโปรเจกต์ … อันนี้ชัวร์แหละ ต้องรู้อยู่แล้ว
2. เรารู้ว่าโปรเจกต์เราก้าวหน้าไปถึงไหนแล้ว ผมกำลังพูดถึง Project Progress

เมื่อมีสองค่านี้ ผมจะคำนวณหา “จำนวนวันที่ต้องใช้ในอนาคต” ได้ตามรูป

แปลรูปครับ เราทำงานเสร็จ x % ภายในเวลา y วัน นับจากวันเริ่มต้น (Start Date) จนถึงวันนี้ (Reporting Date) ดังนั้นด้วยการเทียบบัญญัติไตรยางค์ง่ายๆ?เราจะทำงานที่เหลือ (100 – x%) เสร็จภายในเวลา z วัน พอได้ค่า z มาแล้วก็เอาไปนับต่อจากวันนี้ เราก็จะได้วันที่โปรเจกต์นี้จะเสร็จครับ ง่ายมั้ยครับสูตรนี้ … การคำนวณก็ดูง่ายแหละ แต่ความมันส์มันอยู่ตรงที่เราจะรู้ค่า x ได้ยังไง? สมมติในสถานการณ์ที่ง่ายสุดๆ เลยนะครับ Project Plan ของเราบอกว่าต้องทำงานทั้งหมด 10 งาน เราทำเสร็จแล้ว 5 งาน แปลว่า Progress ของเราคือ 50% ไง … โอ้ววว ไม่ง่ายปานนั้นเพราะ

1. ถ้า 5 งานที่เหลือมันยากกว่า 5 งานแรกหละ?
2. เรามั่นใจขนาดนั้นเลยหรอว่าระยะเวลาที่เหลือของโปรเจกต์จะไม่มีเหตุการณ์ไม่คาดฝันเกิดขึ้น (Risk Management นั่นเอง)

ด้วยความเชื่อว่าสมองมนุษย์เราเป็นอะไรที่สุดยอดมากในการประมวลผล นึกถึงเหตุการณ์ที่ผ่านมา มองไปข้างหน้ากับสิ่งที่อาจจะเกิดขึ้น บวกกับความเชื่อในสัญชาตญาณของตัวเองครับ ผมเลยคิดว่าค่า x สามารถกลั่นออกมาได้จากสมองเราเองนี่แหละ ไม่อยากจะพูดว่าเดามั่วนะ ถึงแม้มันจะเป็นการเดา แต่ก็เป็นการเดาอย่างมีการศึกษา (Educated Guess) นะครับ 55

Program Evaluation and Review Technique (PERT)

ยังไม่มั่นใจใช่มั้ยครับว่าเราจะเดาได้ใกล้เคียงความจริงแค่ไหน อย่างว่านะครับการจะประเมิน Progress มาเป็นตัวเลขกลมๆตัวเดียวดูว่าจะยากไปหน่อย ไม่เป็นไร ผมคิดว่ามีสิ่งที่ช่วยเราได้อยู่นะ … Program Evaluation and Review Technique (PERT) นั่นเอง คุ้นๆกันมั้ย? PERT เป็นทฤษฎีทางสถิติที่ใช้อย่างแพร่หลายใน Project Management ครับ โดยเฉพาะอย่างยิ่งกับการทำ Task Estimation เวลาใช้งานก็ไม่ยากเลยครับ PERT ขอแค่ตัวเลขสามตัวครับ

1. Best case: ถ้าพูดถึง Estimation เราจะตอบคำถามที่ว่า “คุณคิดว่าคุณจะใช้เวลาน้อยที่สุดเท่าไรในการทำงานนี้ให้เสร็จ?” ให้เข้าข้างตัวเองเต็มที่เลย
2. Worst case: กลับกันครับ “อย่างแย่ที่สุด คุณต้องการเวลาเท่าไร?”
3. Most likely case: ทางสายกลางครับ “เอาแบบแมนๆ คุณคิดว่าจริงๆแล้วคุณต้องการเวลาเท่าไรในการทำงานให้เสร็จ?”

เมื่อใช้กับ Progress เราก็ลองถามตัวเองว่า Best Progress, Most Likely Progress และ Worst Progress เป็นเท่าไรกันบ้าง ตัวเลขทั้งสามตัวนี้จะถูกเอามาเข้าสมการข้างล่างเพื่อให้ได้ออกมาเป็น Average Progress ซึ่งเป็นตัวเลขที่เชื่อถือได้มากขึ้นครับ … ไม่ยากๆ


ถึงตรงนี้เราได้แล้วนะครับว่า “โปรเจกต์นี้จะเสร็จวันไหน?” ขอให้ On Plan กันทุกท่าน ทุกโปรเจกต์ครับ โปรดสนับสนุนบทความนี้ด้วยการดาวน์โหลด Template ของผมไปลองใช้ครับ ยินดีมากถ้าจะมีความคิดเห็นและข้อเสนอแนะเข้ามา

ป.ล. ยังไม่จบนะ … บทความหน้าผมจะเล่าให้ฟังว่าเราจะมีแนวทางปรับปรุงกระบวนการคิดเรื่องนี้ของเราได้ยังไงครับ

ป.ล. ผมกำลังพัฒนาและใช้วิธีการเหล่านี้ในงานจริงนะครับ ข้อดีก็มีข้อเสียก็มาก แล้วจะเล่าให้ฟังเรื่อยๆครับว่าผมเจออะไรบ้างและมีแนวทางแก้ไขอย่างไร

จากบทความนี้ครับ ขั้นตอนที่สำคัญของ Risk Management ก็คือ Risk Assessment ซึ่งจะบอกเราได้ว่า Risk ตัวไหนสำคัญกว่ากัน คำว่า “สำคัญ” นี้มีจุดกำเนิดจากปัจจัยสองอย่างครับ (1) ความน่าจะเป็นที่ Risk นี้จะเกิดขึ้น — Likelihood และ (2) ความรุนแรงถ้า Risk นี้เกิดขึ้น มีสองวิธิเช่นกันที่จะได้มาซึ่งค่าเหล่านี้ครับ

Qualitative Assessment

วิธีแรกคือเราวัด Likelihood และ Severity ในเชิงคุณภาพครับ ทำได้โดยการแบ่งระดับความน่าจะเป็นและความรุนแรงออกเป็นสามระดับ “Low (ต่ำ), Medium (ปานกลาง) และ High (สูง)” ถ้าเราอยากรู้ว่า Risk นี้สำคัญขนาดไหน เราก็พิจารณาดูครับว่าเราควรใส่ค่าอะไรให้มัน เช่น

หลักการง่ายๆก็คือ Risk ที่มีค่าความน่าจะเป็นและความรุนแรงเป็น High – High จะสำคัญกว่า High – Medium หรือ Low – Low วิธีนี้ง่าย รวดเร็ว ไม่ซับซ้อน แต่กับงานที่ผมทำอยู่ วิธีนี้ตอบคำถามเหล่านี้ไม่ได้ครับ “Project นี้มีความเสี่ยงแค่ไหน?” หรือ “Project นี้มีความเสี่ยงมากขึ้นหรือลดลงเมื่อเทียบกับเดือนที่แล้ว?” ดูเหมือนว่าผมต้องการวิเคราะห์เชิงปริมาณนะเนี่ยะ

Quantitative Assessment

การวิเคราะห์เชิงปริมาณจะแตกต่างจากข้อแรกตรงที่เราจะแบ่งระดับความน่าจะเป็นและความรุนแรงออกเป็นตัวเลขจาก 0 ถึง 1 ครับ โดยทั่วไปแล้วจะแบ่งระดับเป็น 0, 0.1, 0.2 …, 0.8, 0.9 และ 1.0 เราก็มีหน้าที่เหมือนเดิมคือหาตัวเลขให้เจ้าสองค่านั้นโดยตัวเลขน้อยคือความน่าจะเป็นหรือความรุนแรงน้อย ตัวเลขมากก็กลับกันครับ ปกติแล้ว

• 0.1 – 0.3 คือตัวแทนของ Low
• 0.4 – 0.6 คือตัวแทนของ Medium
• 0.7 – 0.9 คือตัวแทนของ High

ความน่าสนใจอยู่ตรงที่ว่า เมื่อมีตัวเลขทั้งสองตัวแล้ว เราจะสามารถคำนวณความสำคัญของ Risk แต่ละตัวออกมาเป็นตัวเลขได้ ตัวเลขนี้เรียกว่า Risk Exposure ซึ่งได้มาจาก

Risk Exposure = Likelihood x Severity

ตามหลักคณิตศาสตร์ ถ้ามีค่าใดค่าหนึ่งเป็น 0 ก็ไม่มี Risk นั้นครับ เพราะคูณกันแล้วได้ผลลัพธ์เป็น 0 จากตัวอย่างเดิมเราจะสามารถบอกได้อย่างชัดเจนขึ้นว่า Risk ตัวไหนสำคัญกว่ากัน


ดูดีๆ … แต่การที่แบ่งระดับไว้เยอะ มันก็ไม่ใช่เรื่องง่ายที่จะตัดสินใจได้ว่า เอ๊ะ ความน่าจะเป็นมัน 0.3 หรือ 0.4 แล้วความรุนแรงหละ 0.5 หรือ 0.6 เมื่อตัดสินใจยากการทำ Risk Assessment ก็จะใช้เวลาเยอะขึ้นอย่างหลีกเลี่ยงไม่ได้

ถึงแม้จะตอบคำถามสองข้อนั้นของผมได้ แต่ดูว่าใช้เวลาและความทุ่มเทมากไปหน่อย ผมเลยคิดวิธีใหม่มากะว่าจะลองใช้กับงานตัวเองดูครับ

Hybrid Assessment and Project Risk Factor

ผมเลือกที่ผสมผสานทั้งสองวิธีการเข้าด้วยกันด้วยการกำหนดระดับที่เป็นตัวเลขให้กับ Low, Medium และ High เพื่อให้ง่ายขึ้นในการวิเคราะห์ดังนี้?Low = 1 คะแนน,?Medium = 2 คะแนน และ?High = 3 คะแนน?พอมีตัวเลขขึ้นมา ผมก็ใช้สูตร Risk Exposure สร้างตารางคะแนน (Risk Matrix) ซึ่งเกิดจากผลคูณของความน่าจะเป็นและความรุนแรงของ Risk นั้นๆขึ้นมาได้ดังนี้

ค่า Risk Exposure ที่เป็นไปได้ของ Risk แต่ละตัวคือ 1, 2, 3, 4, 6, และ 9 เมื่อเทียบกับตัวอย่างเดิมแล้วจะเป็นอย่างรูปข้างล่างครับ มาถึงคำถามสำคัญว่า “Project นี้มีความเสี่ยงแค่ไหน?” ผมตอบคำถามนี้ด้วยการหาค่าเฉลี่ย Risk Exposure แล้วนำมาใช้เป็น Project Risk Factor สูตรการคำนวณก็ง่ายๆเลย

Project Risk Factor = Average Risk Exposures

ผมสามารถใช้ Project Risk Factor เป็นตัวแทนของความเสี่ยงโดยรวมของ Project ได้และยังสามารถตอบคำถามที่ว่า “Project นี้มีความเสี่ยงมากขึ้นหรือลดลงเมื่อเทียบกับเดือนที่แล้ว?” ได้ด้วยการเก็บสถิติของแต่ละสัปดาห์หรือแต่ละเดือนแล้วแต่ความเหมาะสม


ประเด็นสำคัญคือเราต้องกลับมาวิเคราะห์เจ้า Risk ของ Project เราอย่างสม่ำเสมอเพราะความน่าจะเป็นและความรุนแรงของ Risk แต่ละตัวเปลี่ยนแปลงได้ตลอดเวลา แถมไม่แน่เราอาจจะมี Risk ใหม่ๆเกิดขึ้นมาให้เราปวดหัวเล่นอีกต่างหาก ซึ่งทั้งหมดนี้มีผลต่อค่า Project Risk Factor ครับ

ลองดาวน์โหลด Template นี้ไปใช้กันดูครับผม

ขอบคุณครับ

ย้อนไปเมื่อเดือนสิงหาคม 2552 ผมเขียนโพสต์บทความแรกของตัวเองที่นี่ kannique.wordpress.com … จะว่าไปก็ไม่ได้เขียนเองแบบ 100% หรอกเพราะผมแปลเนื้อหาใจความหลักมาจากบทความของ Robert E. Bone กลับไปอ่านดูแล้วก็แปลกๆเหมือนกัน ฮ่าๆๆ สำนวน เนื้อหา รูปแบบการเขียนดูไม่เหมือนตอนนี้ซักเท่าไร ก็อย่างว่าแหละครับ ตอนนั้นมือใหม่หัดเขียน

 

ทำไมผมถึงเขียนบล็อก?

พยายามนึกถึงจุดนั้น เหตุการณ์ค่อนข้างเลือนราง แต่เหตุผลยังชัดเจนเหมือนเดิมคือ อยากเผยแพร่ความรู้ ความถนัด ความเข้าใจ ความสนใจ แรงบันดาลใจ ความปรารถนาที่จะหาความรู้ในเรื่อง Project Management และ Software Development ให้กับคนไทย (ย้ำว่าคนไทย) ที่สนใจ ด้วยสังเกตว่าบทความดีๆเรื่องนี้มีแต่ภาษาอังกฤษ อีกอย่างคือคนไทยไม่ค่อยชอบอ่านบทความภาษาอังกฤษกัน (ถ้าผมเข้าใจผิดช่วยบอกด้วยนะ ฮ่าๆ) ผมเองก็ไม่อยากให้เรื่องนี้เป็นอุปสรรคในการหาความรู้ของพวกเรา ว่าแล้วก็เลยลงมือเขียนบล็อกภาษาไทยซะเลย

 

ถึงวันนี้ผมเขียนมาแล้ว 143 บทความ มีเพื่อน Subscribe บล็อกผม 200 กว่าคน มีเพื่อนใน Facebook Group & Page อีก 265 & 521 คนตามลำดับ สิ่งที่ผมตั้งใจไว้ก็ดูเหมือนจะผลิดอกออกผลเหมือนกัน … นี่คือสาเหตุที่ผมทำสิ่งเหล่านี้

ทำไมผมถึงเขียน Ebook?

ด้วยเหตุผลและความตั้งใจเดิมคือ อยากแบ่งปันความรู้ประสบการณ์ที่มีให้เพื่อนๆที่สนใจในเรื่องเดียวกัน ช่วงนั้นเห็นว่าบทความเรื่องที่เกี่ยวกับ Project Planning มีคนอ่านเยอะมาก เลยเป็นที่มาของ Project Planning Ebook ที่รวบรวมหลักการพื้นฐานของการวางแผนโครงการแบบตามทฤษฎีสุดขีด จากนั้นมีน้องคนนึงอยากรู้เรื่องกระบวนการพัฒนาซอฟต์แวร์แบบละเอียด ผมก็ได้แรงบันดาลใจให้เขียนบทความต่อเนื่อง 6 ตอนพูดถึงเรื่องนี้เรื่องเดียว (เหนื่อยมากตอนเขียน ฮ่าๆ) สุดท้ายก็เป็นที่มาของ How to Build Software Ebook?นี่ก็ตามทฤษฎีสุดๆเหมือนกัน

 

 

ก่อนเขียน Ebook เล่มแรกเคยคิดเหมือนกันว่าจะขาย แต่มันเหมือนมีอะไรบางอย่างที่ไม่ถูกต้องเท่าไรในความคิดผมเอง นั่นคือ … ความรู้สึกส่วนตัวที่ว่า ทำไมความรู้ต้องมีราคา ทำไมต้องตีค่าเป็นเงิน? ถามว่าถ้าจะขายจะขายออกมั้ย? ก็คงพอได้มั้งครับ ตอนนั้นเข้าข้างตัวเองเล็กน้อยว่าคงมีคนสนใจอยู่ประมาณหนึ่ง แต่พอคิดอีกรอบก็สรุปง่ายๆได้ว่าผมทำไม่ได้อะ ฮ่าๆๆ เงินที่กำลังจะได้กับความเป็นตัวเองที่กำลังจะเสียไป มันไม่คุ้มกัน

 

นับถึงตอนนี้มีเพื่อนๆดาวน์โหลดหนังสือ 2 เล่มนี้ไปแล้วโดยประมาณเกือบ 800 คน ไม่แน่ใจว่าไปส่งต่อให้เพื่อนคนอื่นๆอีกรึเปล่านะ … ทำได้ๆ เอาเลยครับ ไม่ได้ห้าม มันเป็นความรู้สึกดีๆที่ผมได้กลับมา ผมรู้ว่าหนังสือทั้ง 2 เล่มมีประโยชน์กับใครอีกหลายคน ไม่ว่าจะในชีวิตการเรียน ชีวิตการงาน หรืออื่นๆ …?นี่คือสาเหตุที่ผมทำสิ่งเหล่านี้

ทำไมผมถึงจัดกิจกรรมกลุ่ม?

เขียนบล็อกนี้มาได้ซักพักเริ่มมีความรู้สึกว่า มันขาดความเป็นมนุษย์ไปนะ มนุษย์คือสัตว์สังคมที่ต้องมีปฏิสัมพันธ์กับมนุษย์ด้วยกันบ้าง ฮ่าๆ มันเป็นการเติมเต็มความรู้สึกส่วนตัวของผมเอง ว่าแล้วก็จัดเลย Chapterpiece.Meeting.1: Agile Development — First Chapter น่าปลื้มใจมากมีเพื่อนๆมาร่วมพบปะพูดคุยกันตั้ง 10 คนแหนะ ผมยังจำได้หมดนะ พี่ตี๋ พี่ป๊อบ พี่เอ๋ โดม โบ๊ต เต้ ติ เอ นุ่น และตั๋ง วันนั้นนัดกันที่ Bug and Bee สีลม จำได้ชัดเจนมากว่า พี่ป๊อบเลี้ยงกาแฟน้องๆทุกคน พี่ตี๋เมื่อยมือถือ iPhone ถ่ายวีดิโอให้ (ขอบคุณมากครับ) และติก็กลายมาเป็นผู้สนับสนุนด้านสถานที่ของกิจกรรมกลุ่มเราจากนั้นเป็นต้นมา ขอบคุณ The Art Element อย่างสูง

 

ครั้งที่สอง สาม สี่ ห้า ห้า.ห้า ก็ตามมาเรื่อยๆ ถี่บ้าง ห่างบ้าง แล้วแต่สถานการณ์ ด้วยความรู้สึกดีมากๆที่เพื่อนบางคนมาไม่เคยขาดเลยซักครั้ง บางคนมาจากต่างจังหวัดเพื่อการนี้ (กอล์ฟ) บางคนลุยน้ำท่วมมาเจอกัน (พี่เอ๋) ตอนพวกเรามีกิจกรรม Chapterpiece.Meeting.4: Risk Management for IT Projects นับคร่าวๆน่าจะมีซัก 30 คนหละมั้งครับที่เคยเข้าร่วมกิจกรรมทั้งหมดที่ผ่านมา รูปข้างล่างนี้ถ่ายตอน Chapterpiece.Meeting.2: Project Planning — How To?ครับ

 

 

ถามว่าจริงๆแล้ว ผมโคตรชอบเรื่อง Project Management เลยหรอ? ผมโคตรชอบเขียนบล็อกหรือจัดกิจกรรมขนาดนั้นเลยหรอ? … จะว่าไปก็พูดยากนะ ชอบอะแน่ๆแหละ แต่ว่ามันเหนื่อยนะครับการเตรียมตัว ทุกครั้งต้องอ่านหนังสือหรือบทความเยอะอยู่เพื่อจะได้มีข้อมูลมากเพียงพอที่จะมาเขียนบล็อกหรือว่าจัดกิจกรรมซักครั้งนึง ต้องเตรียม Slides ต้องทำกรณีศึกษาบ้าง ต้องเตรียมการสำหรับทำ Workshop อะไรอีกเยอะแยะ … ทำคนเดียวครับไม่มีผู้ช่วย นี่ไม่ได้ทวงบุญคุณหรือว่าตัดพ้ออะไรนะ กำลังจะบอกว่า Project Management ไม่ใช่แรงบันดาลใจของผมหรอก แต่มันคือความรู้สึกเติมเต็มต่างหาก ความรู้สึกที่ผมได้รับเมื่อผมรู้ว่าสิ่งที่ทำไปเป็นประโยชน์กับเพื่อนๆ ไม่ว่าจะเป็นผู้อ่าน หรือผู้เข้าร่วมกิจกรรม …?นี่คือสาเหตุที่ผมทำสิ่งเหล่านี้

 

เคยมีเพื่อนถามผมว่า “เฮ้ย เสาร์นี้ไปไหนป่าววะ?” ผมตอบว่า “อ๋อ พอดีมีสัมมนาหวะ เค้าเชิญไปเป็นวิทยากร” เพื่อนผมถามต่อว่า “หรอ ดีหวะ ได้ตังค์เท่าไร” ผมตอบว่า “ไม่ได้หวะ” เพื่อนผม “อ่าว อะไรวะ แล้วไปทำไมอะงั้น” (กรุณาอย่าไปว่าอะไรเพื่อนผมเลยนะ ฮ่าๆ) ผมก็ตอบไปว่า “ไม่เป็นไรหรอก เค้าเชิญมาก็ช่วยๆเค้าไป” ในใจคิดว่า “นอกจากไม่ได้ตังค์แล้วยังเข้าเนื้ออีกนะ ค่ารถ ค่ากิน ฮ่าๆๆ” คิดจริงนะ แต่เพราะผมมองว่านี่คืออีกโอกาสที่จะได้แบ่งปันความรู้และประสบการณ์ที่มีให้กับคนอื่นๆที่สนใจในเรื่องเดียวกันได้ฟัง มันก็คุ้มอยู่ …?นี่คือสาเหตุที่ผมทำสิ่งเหล่านี้

แล้วยังไงต่อไป?

ถามว่าแล้วจะยังไงต่อไป … ก็แบบนี้แหละครับ ผมเล่าให้ฟังแล้วว่า “ทำไม” ผมถึงเขียนบล็อก เขียน Ebook (จะพยายามนะ) จัดกิจกรรม และเป็นวิทยากรในบางโอกาสต่อไปครับ ผมไม่คิดว่าบล็อกผมดีที่สุด อัพเดทบ่อยที่สุด คนอ่านมากที่สุด หรือมีคนไลค์ในเฟสบุ๊กเพจมากที่สุด แต่ผมมั่นใจว่าคนที่ติดตามอ่านบล็อกผมเป็นประจำคือคนที่ (1) สนใจเรื่อง Project Management และ Software Development (2) พร้อมแบ่งปันความรู้ที่มีให้กับสังคม (ดูยิ่งใหญ่มาก) แบบไม่หวังผลตอบแทน (3) มีแนวทาง มีความคิด มีจุดยืนเป็นของตัวเอง … เหมือนผม

 

Simon Sinek ผู้ซึ่งเป็นแรงบันดาลใจสำหรับการเขียนบทความนี้กล่าวไว้ว่า

 

“People don’t buy what you do, but why you do it.“

 

เมื่อผมหันกลับมามองตัวเองก็รู้สึกว่าจริงนะ คำถามสำคัญคือ “Why am I doing this?” และคำถามแรกของ Chapterpiece.Meeting.6: If You Were to Start a Software Company คือ “Why do you want to do this?”.

 

 

ปล. ยังมีที่ว่างเหลืออยู่สำหรับคนที่สนใจนะครับ ลงทะเบียนได้เลยครับ