Project Management(အပိုင်း-၇)

5.4 Risk Management

Risk managementသည် project managerများ အဓိကလုပ်ဆောင်ရသော အလုပ်များထဲမှ တစ်ခုအဖြစ် အတော်မြင်တွေ့ကြရပါသည်။ Developလုပ်နေဆဲ software ၏ quality (သို့) project schedule အပေါ်သက်ရောက်နိုင်သော ဘေးဖြစ်နိုင် သည့် အရာ (risk) များကို ကြိုတင်တွက်ချက်ခြင်း နှင့် ယင်းတို့ကို ရှောင်ရှားရန် အလုပ်လုပ်ဆောင်ခြင်းများ သည် risk management ထဲတွင် ပါဝင်ပါသည်။ Project management၏ လုပ်ထုံးအရ လုပ်ဆောင်ချက်များ၏ result များကို စာရွက်စာတမ်း (document) များအဖြစ် မှတ်တမ်းတင်ရပါသည်။ Risk managementတွင်လည်း riskများကို ဆန်းစစ် (analyze) သည့်အခါ resultကို documentထုတ်ပေးရပါသည်။ ၎င်း risk analysis ၏ resultကို documentထုတ်သည့်အခါ ဖြစ်ပွားနိုင်သည့် risk၏ နောက်ဆက်တွဲ အကျိုးဆက်များကိုပါ ထည့်သွင်းဖော်ပြသင့်ပါသည်။ Risk management ကောင်းလျှင် ပြဿနာများကို ဖြေရှင်းရ ပိုမိုလွယ်ကူပြီး ယင်းပြဿနာ များမှ ဖြစ်ပေါ်လာနိုင်သော budget ပိုမိုကုန်ကျခြင်း (unacceptable budget) နှင့် ရည်မှန်းထားသော schedule အတိုင်း မဖြစ်မြောက်ခြင်း (schedule slippage) များကို အတတ်နိုင်ဆုံး ရှောင်ကြည် နိုင်ပါသည်။

ကျွန်တော်တို့အနေနဲ့ riskများကို မိမိတို့မဖြစ်ပွားလိုသော အရာများဟု ရိုးရိုး ရှင်းရှင်း တွေးနိုင်ပါသည်။ Riskများသည် ကျွန်တော်တို့၏ project၊ developလုပ်နေဆဲ software (သို့) အဖွဲ့အစည်းကို ချောက်လန့်နိုင်ပါသည်။ ထို့ကြောင့် riskများနှင့် ဆက်စပ်၍ category သုံးခုရှိပါသည်။

1. Project risks: Project schedule (သို့) project ဆိုင်ရာ အရင်းအမြစ် resource များကိုထိခိုက်စေသော riskဖြစ်သည်။ ဥပမာ- အတွေ့အကြုံရင့်ကျက်သည့် programmerတစ်ဦး အလုပ်ထွက်၍သော်လည်းကောင်း၊ အခြားအကြောင်း များ ကြောင့်လည်းကောင်း အဖွဲ့အစည်းမှ ထိုprogrammer ကို လက်လွတ်လိုက် ရ ခြင်း။

2. Product risks: developလုပ်နေဆဲ software၏ quality နှင့် performanceကို ထိခိုက်စေသော riskဖြစ်သည်။ ဥပမာ- ဝယ်ယူထားသော software တစ်ခုသည် မျှော်လင့်ထားသလောက် ကောင်းစွာ အလုပ်မလုပ်ခြင်း။

3. Business risks: software တစ်ခုကို ထုတ်လုပ်နေသည့် (သို့) ဈေးကွက်သို့ စတင် မိတ်ဆက်နေသည့် အဖွဲ့အစည်းကို ထိခိုက်စေသော riskဖြစ်သည်။ ဥပမာ- ပြိုင်ဘက် အဖွဲ့အစည်းမှ ထုတ်ကုန်အသစ်တစ်ခုကို မိမိ ထုတ်ကုန်နှင့် တစ်ပြိုင် နက် မိတ်ဆက်ခြင်း။

အထက်ပါ risk သုံးမျိုးသည် တစ်ဆက်တည်းဖြစ်ပေါ်လာတတ်ပါသည်။ ဥပမာ-

အတွေ့အကြုံရင့်ကျက်သည့် programmerတစ်ဦး project မှ နုတ်ထွက်လိုက်ပါက developလုပ်နေသည့် systemပြီးမြောက်မည့် အချိန်သည် နှောင့်နှေးသွားမည်၊ နောက်ကျသွားမည်ဖြစ်သဖြင့် project risk တစ်ခု ဖြစ်သွားနိုင်ပါသည်။ ထို project riskသည် product riskလည်း ဖြစ်သွားနိုင်ပါသည်။ အဘယ့်ကြောင့်ဆိုသော် အစားထိုးလိုက်သော programmerအသစ်သည် programmerအဟောင်းလောက် အတွေ့အကြုံရှိချင်မှရှိမည်၊ programmerအဟောင်း တည်ဆောက်သွားသော system ကို နားလည်ရင်းနှီးအောင် အချိန်ပေးရမည်ဖြစ်သည့်အတွက် programming error များကိုလည်း ဖြစ်ကောင်းဖြစ်စေနိုင်ပါသည်။ နောက်ဆုံးအနေဖြင့် business riskလည်း ဖြစ်လာနိုင်ပါသည်။အဘယ့်ကြောင့်ဆိုသော် programmerအသစ်၏ အတွေ့အကြုံသည် အဖွဲ့အစည်းတွင်ရှိသော စီးပွားရေးလုပ်ထုံးလုပ်နည်းများကို လိုက်နှာလုပ်ဆောင်ရန် မလုံလောက်နိုင်သောကြောင့် ဖြစ်ပါသည်။

၎င်း riskများသည် developလုပ်ဆဲ software projectကို မှီခိုနေသော အခြား projectများနှင့် အဖွဲ့အစည်း ဆိုင်ရာ ပတ်ဝန်းကျင်ကိုပါ ထိခိုက်စေနိုင်ပါသည်။ မည်သို့ပင်ဖြစ်စေကာမူ project ရှိလျှင် riskများရှိကြပါသည်။ ၎င်း ဖြစ်လေ့ ဖြစ်ထရှိသော riskများအနက် အဖြစ်တတ်ဆုံး နှင့် အတွေ့ရဆုံး riskများကို အောက်ပါ အတိုင်း တွေ့ရပါသည်။

1. Staff turnover (Project risk): project မပြီးဆုံးမှီ အတွေ့အကြုံရှိသော ဝန်ထမ်း နုတ်ထွက်ခြင်း။

2. Management change (Project risk): အဖွဲ့အစည်း၏ စီမံခန့်ခွဲထားသော ဦးစားပေး လုပ်ငန်းစဥ်များ ပြောင်းလဲသွားဖြင်း။

3. Hardware unavailability (Project risk): project အတွက် မရှိမဖြစ် လိုအပ်သော hardwareဆိုင်ရာ စက်ပစ္စည်းများ သတ်မှတ်ချိန်အတွင်း မရရှိခြင်း။

4. Requirements change (Project risk and Product risk): project အတွက် လိုအပ်သည့်အရာများတွင် ပြောင်းလဲမှုများ ထင်ထားသည်ထက် များပြား နေခြင်း။

5. Specification delays (Project risk and Product risk): projectအတွက် မရှိမဖြစ်လိုအပ်သော အရေးကြီးသောအရာများသည် သတ်မှတ်ချိန်အတွင်း သတ်မှတ်ချက်များအတိုင်း ဖြစ်မလာခြင်း။

6. Size underestimate (Project risk and Product risk): systemတွင် အသုံးပြုမည့် dataများ ၊ functionများ ကဲ့သို့ system အရွယ်အစားကို လျော့တွက်မိခြင်း။

7. CASE tool under-performance (Product risk): project ကို ထောက်ပံ့ပေးသော CASE toolများ မျှော်လင့်ထားသလောက် ကောင်းစွာ အလုပ်မလုပ်ခြင်း။ CASE toolဆိုသည်မှာ software developmentကို ကူညီသော အခြား software ကိရိယာများဖြစ်ပါသည်။

8. Technology change (Business risk): System developလုပ်ရာတွင် အခြေခံအသုံးပြုခဲ့သော နည်းပညာကို နည်းပညာအသစ်တစ်ခုဖြင့် ပြောင်းလဲ တည်ဆောက်ခြင်း။

9. Product competition (Business risk): မိမိတို့၏ system အောင်မြင်စွာမပြီးမြောက်ခင် ပြိုင်ဘက်အဖွဲ့အစည်းတစ်ခုက product တစ်ခုကို ဈေးကွက်သို့ စတင်ရောင်းချလိုက်ခြင်း။ (မိမိ product နှင့် ပြိုင်ဘက် product တို့၏ target customerတူနေလျှင် risk ကြီးနိုင်ပါသည်။)

Software projectများအတွက် risk managementသည် အထူးအရေးကြီးပါသည်။ အဘယ်ကြောင့်ဆိုသော် projectတော်တော်များများသည် မရေရာမသေချာသော အရာများနှင့် တွေ့ကြုံရစမြဲဖြစ်ပါသည်။ မရေရာမသေချာသော requirementများ၊ Software developmentဆိုင်ရာ အချိန်ကာလ (time) နှင့် အရင်းအမြစ်(resource) ခန့်မှန်းတွက်ချက်ရာတွင် ဖြစ်ပေါ်သော အခက်အခဲများ၊ တစ်ဦးချင်းစီတွင်ရှိသော အရည်အချင်းများ အပေါ်မှီခိုနေမှုများနှင့် customerအလိုအရ ပြောင်းလဲနေသော requirementများသည် မရေရာမသေချာမှုများကို ဖြစ်စေသော အဓိကအရာများ ဖြစ်ပါသည်။ ကျွန်တော်တို့အနေနဲ့ ဖြစ်ပေါ်လာနိုင်မည့် riskများကို ကြိုတင်ခန့်မှန်း တွက်ချက်ပြီး ယင်းriskများသည် project၊ product နှင့် business အပေါ် မည်သို့ထိခိုက်စေနိုင်သလဲကို နားလည်ထားရပါမည်။ ထို့နောက် ၎င်းriskများကို ရှောင်ရှားနိုင်အောင် လုပ်ဆောင်ကြရပါမည်။ တွက်ချက်ထားသည့် Riskများပေါ်ပေါက် လာလျှင်လည်း ဖြေရှင်း နိုင်မည့် အရေးပေါ်အစီအစဉ်များကို ဆွဲသင့်လျှင် ဆွဲရပါမည်။ ထိုသို့ planများဆွဲထားနိုင်မှ risk ဖြစ်ပေါ်လာလျှင် ချက်ချင်းဖြေရှင်းနိုင်မည် ဖြစ်သည်။

Risk management

Risk management ၏ process ကို အထက်ပါပုံအတိုင်း တွေ့မြင်နိုင်ပါသည်။ ထို processတွင် အဆင့်(stage)များပါဝင်ပါသည်။

1. Risk identification: ဖြစ်ပေါ်လာနိုင်သော project၊ product နှင့် business riskများကို တွက်ချက်ဖော်ထုတ်ခြင်း။

2. Risk analysis: riskများ၏ နောက်ဆက်တွဲ ဖြစ်ပေါ်လာနိုင်သည့် အရာများကို ဝေဖန်ပိုင်းခြားခြင်း။

3. Risk planning: risk တစ်ခုကို ရှောင်ရှားခြင်း (သို့) ၎င်း၏ project အပေါ်သက်ရောက်မှုကို လျော့ချရန် plan ဆွဲခြင်း။

4. Risk monitoring: riskတစ်ခုကို အစဥ်မပြတ် စောင့်ကြည့်လေ့လာခြင်း (assess) နှင့် riskသက်ရောက်မှု လျော့ပါး (risk mitigation) စေရန် ဆွဲထားသည့် planများကို ထိုriskနှင့်ပက်သက်၍ informationများ ရရှိလာသည်နှင့်အမျှ အမြဲစီစစ် သုံးသပ်နေခြင်း။

Risk management သည် အခြား project planning များကဲ့သို့ projectတစ်လျှောက်လုံး ထပ်ခါထပ်ခါ စီစစ်လုပ်ဆောင်ရသော(iterative) process ဖြစ်ပါသည်။ Planများကို အစပြုလုပ်ဆောင်ပြီဆိုပါက project တွင် ဖြစ်ပေါ်နေသည့် အခြေအနေများ ကို စတင် စောင့်ကြည့်ထိန်းသိမ်း (monitor) ကြရပါမည်။ Riskများနှင့် ပက်သက်၍ informationများရရှိလာသည့်နှင့် အမျှ riskများကို ပြန်လည်စီစစ်(reanalyse) ပြီး ဦးစားပေးသင့်သော အရာများကို ဦးစာပေးစီစဉ်သင့်ပါသည်။ Risk ရှောင်ရှားခြင်း (risk avoidance) နှင့် အရေးပေါ်အစီအစဉ်များကို riskနှင့် ပက်သက်သော informationများ ရရှိလာသည်နှင့် အမျှ အမြဲပြင်ဆင်နေရပါမည်။

ကျွန်တော်တို့သည် Risk management planတစ်ခုတွင် ရှိသော risk management process ၏ ရလဒ်များကို document မှတ်တမ်းတင်သင့်ပါသည်။ ၎င်း documentတွင် project၌ ကြုံတွေ့ရသော riskများကို ဆွေးနွေးတင်ပြချက် တစ်စောင်၊ ယင်း riskများ နှင့် ၎င်းတို့ကို manageလုပ်မည့် planများ ကို ဆန်းစစ်ချက်(analysis) တစ်စောင် ပါဝင်သင့်ပါသည်။ တိကျသေချာသော အရေးပေါ်အစီအစဉ် များကို သင့်တော်သလို documentထဲတွင် ထည့်သွင်းဖော်ပြသင့်ပါသည်။