Project Risk Management — [A Short Story] By Coach Num

เกริ่นว่าเริ่มต้นจาก PMI (Certification Body ให้ Certified สำหรับคนที่ Qualified → take exam → รับ Certificate) ซึ่ง PMI นี้ก็มี Certificate ที่ชื่อว่า PMI-RMP (Risk Management Professional)

การบริหารจัดการความเสี่ยง เป็น 1/10 Knowledge Area (PM = 40+ Process) ซึ่งใน Risk Management มีประมาณ 6 Process ที่อยู่ใต้องค์ความรู้นี้

การบริหารจัดการความเสี่ยง

1. เริ่มจากการ Plan
2. ในมุมของ Risk ควรมีเป็น 100 items ไม่ใช่แค่ 5 items ตอนต้น Project ไม่ควรมี issue แต่ควรจะมี Risk และมีจำนวนเยอะมากๆๆ ด้วย
3. หลังจากที่ List แล้วก็มา create short-list ของ Risk ตามความน่าจะเป็น และ Impact
4. Risk บางตัวสามารถเอาไปทำออกมาเป็นตัวเลขได้
5. แล้วทำการวางแผนว่าเราจะ response มันยังไง ด้วยการ “ลดโอกาสการเกิด หรือลดความรุนแรงที่จะเกิด” แต่ถ้า Risk เป็นเชิงบวก ก็มาดูว่า “ทำยังไงถึงจะเพิ่มโอกาสนั้น”
6. Monitor และ Control ด้วยการ implement risk response plan

1. Plan Risk Management

ผู้เกี่ยวข้อง

ถ้า Project เราไม่มี Risk Team (ทีมที่ทำหน้าที่จัดการความเสี่ยง) — PM จะต้องเป็นคนแพลน แล้วจากนั้นให้คนมาช่วย Identify

• Project ที่มี Financial ใหญ่ๆ ควรจะมี Risk Team
• Plan = ไปดูว่าใครต้อง Involved แล้วเอาเข้ามาใน Project ***อย่าทำคนเดียว***

Overview

1. Business Risk = Gain / Loss เช่น Product เวลาขายออกไป เราได้เงิน หรือสูญเงิน
2. Pure (insurable) Risk = loss อย่างเดียว เช่น ไฟไหม้ตึก ทำอะไรไม่ได้ นอกจากทำประกันไว้
3. Probability = likelihood โอกาสในการเกิดขึ้นของ Risk นี้
4. Impact (consequence) = effect ของ Risk ที่เกิดขึ้น
5. Risks include what can go Right (โอกาส) and go Wrong (Negative)

2. Identify Risks

• “cause-risk-effect” format to naming the risk
• risk คือความไม่แน่นอนที่ยังไม่เกิดขึ้น เป็นความเสี่ยงที่อาจจะเกิด ไม่มีใครรู้ว่าจะเป็น positive or negative เราแค่ identify ว่า ถ้ามันเกิด มันอาจจะมีความเสี่ยงประมาณนี้
• As a result of a (definitive cause), an uncertain event (risk) may occur, which would/could/may lead to (effect)
• As a result of ‘lack of clear direction for scope XYZ component’, there could be ‘rework and wasted efforts’, which could ‘delay the project completion from 2–4 weeks.’
• As a result of the amount of work, the customer is trying to accomplish on many projects during this project’s completion, a delay in the customer’s response to our requests for approvals may occur, which could result in a two-week delay in project completion.

เทคนิคในการ Identify Risk

• Brainstorming
• Conduct a ‘premortem’ (ชันสูตร) คิดในแง่โหดร้ายไว้ก่อนว่าจะเฟลแน่ๆ เช่น ลูกค้าไม่ค่อยตอบเรา, เราสร้างโปรเจ็ค X จากศูนย์เดี๋ยวก็มีคนมาโจมตีเราได้
• ในขณะเดียวกันก็คิด Risk ในแง่บวกได้ว่าทีมจะ success ได้ยังไง เช่น ชวนพี่ Senior UX มาอยู่กับเรา 100% (ได้ไหมนะ?)
• Identify ให้ได้เยอะๆๆ เพื่อให้เรามี Issue น้อยๆ ระหว่างการ Implement

“ถ้าเราเห็น ลูกน้ำเยอะ เราก็คว่ำมันทิ้งก่อน จะได้ไม่ต้องมี ยุงมากัดเรา”

• เราสามารถถาม PM จาก Project อื่นได้ว่าเคยเจออะไรมา จะได้เอามารวมด้วย

• หรือจะถาม Expert ว่าเค้ามีความเห็นอย่างไร ถ้าเราคิดว่าเราจะทำ Project แบบนี้ ด้วย open question และต่อด้วย follow up question

และยังมีเทคนิคอีกมากมาย ให้ไป Search (เพื่อทำความเข้าใจต่อได้) เช่น

Risk Register

เอาของที่เก็บมาได้ 100 items มาเก็บไว้ในนี้ เรียกมันว่า overall project list

จากนั้นเอามาเก็บใน Activity เช่น

• การเก็บ Requirement — ลูกค้าทำหลาย Project ไม่มีเวลารับนัดให้เราเก็บ Requirement ของ Project นี้เลย
• Development — เทคโนโลยีนี้ไม่เคยใช้มาก่อน อาจจะทำไม่ถูก และเสียเวลา rework

3. Qualitative Risk Analysis

การทำ Probability (Likelihood) กับ Impact โอกาสที่มันควรเกิดขึ้น ไม่ควรมากกว่า 8 ถ้ามันเกิน แสดงว่ามันเป็น Fact ไม่ใช่ Risk ต้อง Handle ในรูปแบบอื่น

• Low Risk = Likelihood, Impact น้อย แค่ Record ไว้
• ถ้า Med, High = เอาไปทำ Quantitative แล้วหา Response Plan ต่อไป เพราะ Time/Resource เรามีจำกัด
• ตัวที่เป็น Low มันอาจจะไม่ Impact ตอนนี้ แต่อนาคตมันอาจจะกลายเป็น High ก็ได้

4. Quantitative Risk Analysis

“ในโลกความจริง ไม่ใช่ทุก Risk ที่อาจจะเกิดขึ้น จะเกิดขึ้น”

โจทย์

• Monetary = เมื่อ Impact เริ่มกลายเป็นตัวเงินที่สามารถวัดได้
• Likelihood = ยังไม่เกิด แค่มันมีโอกาสเกิด ทั้ง 5 ข้อในโจทย์ ถือว่าเป็น Risk
• โดยข้อ B., D. = Opportunity นอกนั้นเป็น Threats

ด้วยความเสี่ยงทั้งหมดที่ได้มา เอามาเข้าสูตร EMV จากนั้นเอาตัวเลขมาบวกรวมกัน

เมื่อทำ Risk Assessment เสร็จแล้ว ก็จะมองเห็นว่า เราควรของบเพิ่มเท่าไหร่ในการทำงานนี้ (ที่ตั้งต้น 600k อาจจะไม่ได้เท่านั้น ถ้าเจอ EMV กับ Worst case เข้าไป)

5. Risk Response

Threats

• ไม่เคยใช้เทคโนโลยีนี้ก็ไม่ต้องใช้มัน (ได้ไหมน้า)
• ใช้ Supplier มากกว่าหนึ่ง เผื่อว่าอีกเจ้าเกิดน้ำท่วม/ไฟไหม้โกดัง
• หรือเอาไปให้คนอื่นทำ (โยนให้ลูกค้าเป็นคนสั่งของไปเลย) แล้วเราค่อยมาประกอบ
• ทำใจว่า “ถ้ามันจะเกิด มันจะเกิด” โดยการทำแพลน และแผนรองรับทั้ง + และ —

Management Reserve = ขอเวลา / ขอเงินเพิ่มมาก่อน โดยการ มั่ว 10%, เดามั่วกว่าเดิม, ใช้หลักการการคิดเงินข้อที่ผ่านมา

6. Monitor and Control Risk

• อย่าแพลนแล้วเก็บไว้ พยายามกลับมา Define มัน ระหว่างทางก็ต้องทำพวกนี้เพิ่มเติมขึ้นไป
• อย่าแพลนแล้วทิ้ง เมื่อแพลนแล้วรู้ Risk ก็ควร Re-estimate ใหม่ ว่า Project Cost/timeline เพิ่มเท่าไหร่
• แล้วก็ communicate เพื่อให้ทุกคนเข้าใจตรงกันในเรื่อง Risk เหล่านี้

เป็น Session ที่ผู้พูดของเราเป็น the rapper ไฟแล่บมาก ทางนี้ก็รัวนิ้ว สมองหมุนเร็วจี๋เหมือนกัน แต่ก็ได้ประโยชน์มากขั้นสุด ขอขอบคุณโค้ชพี่หนุ่มไว้ตรงนี้อีกครั้งค่ะ ❤