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

5.4.1 Risk identification

Risk identification သည် risk management၏ ပထမဆုံး stageဖြစ်ပြီး projectတွင် ဖြစ်ပွားနိုင်သော riskများအားလုံးကို ရှာဖွေဖော်ထုတ်ခြင်း ဖြစ်ပါသည်။ ယေဘုယျအားဖြင့် ယခု stageတွင် riskများကို အရွယ်အစားခွဲခြားခြင်း၊ ဦးစား‌ပေးအစီအစဉ်ချခြင်းများ မလုပ်သင့်သေးပါ။ လက်တွေ့တွင် ယခုstage၌ နောက်ဆက်တွဲ ဆိုးကျိုးနည်းသော riskများနှင့် ဖြစ်နိုင်ချေနည်းသော riskများကို ထည့်သွင်းစဉ်းစားလေ့မရှိပါ။

Risk identificationကို အသင်းအဖွဲ့လိုက် brainstormingလုပ်ခြင်း (သို့) မိမိ အတွေ့အကြုံများကို အခြေခံ၍ လုပ်ဆောင်ကြပါသည်။ ယခု processကို လုပ်ဆောင်ရန် မတူညီသော riskအမျိုးအစားများ အသုံးပြုပြီး checklistလုပ်ထားနိုင် ပါသည်။ ဖြစ်ပေါ် လာနိုင်သော riskအမျိုးအစား အနည်းဆုံး ၆မျိုးကို အောက်ပါ အတိုင်း တွေ့နိင်ပါသည်။

1. Technology risks: systemကို developလုပ်ရန် အသုံးပြုသည့် software (သို့) hardware နည်းပညာများမှ ဖြစ်ပေါ်လာ သော riskများဖြစ်ပါသည်။

2. People risks: development teamတွင်ရှိသော လူများနှင့် ဆက်စပ်သည့် risk များဖြစ်ပါသည်။

3. Organizational risks: developလုပ်နေဆဲ software၏ အဖွဲ့အစည်းဆိုင်ရာ ပတ်ဝန်းကျင် (organizational environment) မှ ဖြစ်ပေါ်လာသော riskများ ဖြစ်ပါသည်။

4. Tool risks: systemကို developလုပ်ရန် အသုံးပြုရသော CASE toolများနှင့် အခြားအကူ softwareများမှ ဖြစ်ပေါ်လာသော riskများ ဖြစ်ပါသည်။

5. Requirement risks: customerများ၏လိုအပ်ချက် requirementများအပေါ်ဖြစ် ပေါ်လာသော ပြောင်းလဲမှုများနှင့် ယင်း requirement changeများကို စီမံခန့်ခွဲ သော processများမှ ဖြစ်ပေါ်လာသော riskများဖြစ်ပါသည်။

6. Estimation risks: system characteristicများနှင့် ထို systemကိုတည်ဆောက် ရန်လိုအပ်သော resourceများ၏ စီမံခန့်မှန်းခြေများမှ ဖြစ်ပေါ်လာသော riskများ ဖြစ်ပါသည်။

5.4.2 Risk analysis

Risk analysis processကိုလုပ်ဆောင်နေစဥ် ကျွန်တော်တို့သည် မိမိတို့ရှာဖွေ ဖော်ထုတ်ထားသော riskတစ်ခုချင်းစီကို သုံးသပ်ဆင်ခြင်ပြီး ထိုrisk၏ ဖြစ်ပွားနိုင်ခြေ (probability)နှင့် ထိခိုက်နိုင်စေမှု(seriousness)များကို ဝေဖန်ပိုင်းခြား ရပါမည်။ ထိုကဲ့သို့လုပ်ဆောင်ရာတွင် လွယ်ကူသောနည်းလမ်းများ မရှိပါ။ ကျွန်တော်တို့၏ ပင်ကို ဝေဖန်ပိုင်းခြားနိုင်စွမ်း (judgment) နှင့် အတွေ့အကြုံ (experience) များအပေါ်တွင် ကျွန်တော်တို့၏ သုံးသပ်ဆင်ခြေမှုများသည် မှီခိုနေပါသည်။ ထို့ကြောင့် ယေဘုယျအားဖြင့် အတွေ့အကြုံရှိသော project managerများသည် risk managementကို ကောင်းစွာကိုင်တွယ်နိုင်ကြသူများ ဖြစ်ကြပါသည်။ ဤ ဖြစ်နိုင်ခြေ riskများကို တိကျသော ကိန်းဂဏာန်းများဖြင့် တွက်ချက်ဆုံးဖြတ်ရန် မလိုအပ်သော်လည်း အောက်ပါ ကိန်းအစီအစဉ် ဝန်းကျင်အတွင်း တွက်ချက်ဆုံးဖြတ်ရပါ မည်။

· Risk တစ်ခု၏ ဖြစ်နိုင်ခြေကို

1. ၁၀ ရာခိုင်နှုန်းအောက် (<10%) ဆိုလျှင် very low ၊

2. ၁၀ ရာခိုင်နှုန်းနှင့် ၂၅ ရာခိုင်နှုန်းအကြား (10–25%) ဆိုလျှင် low ၊

3. ၂၅ ရာခိုင်နှုန်း နှင့် ၅၀ ရာခိုင်နှုန်းအကြား (25–50%) ဆိုလျှင် moderate၊

4. ၅၀ ရာခိုင်နှုန်းနှင့် ၇၅ ရာခိုင်နှုန်းအကြား (50–75%) ဆိုလျှင် high ၊

5. ၇၀ ရာခိုင်နှုန်းနှင့် အထက် (>75%) ဆိုလျှင် very high

ဟု ချင့်ချိန်တွက်ချက်နိုင်ပါသည်။

· Risk တစ်ခု၏ သက်ရောက်ထိခိုက်နိုင်မှု(effect)များကို

1. Catastrophic (အလွန်ကြီးမားသော)

2. Serious (ပြင်းထန်သော)

3. Tolerable (သည်းခံနိုင်သော)

4. Insignificant (အသေးအဖွဲဖြစ်သော)

အထက်ပါ အဆင့်များဖြင့် ချင့်ချိန်တွက်ချက်နိုင်ပါသည်။

ကျွန်တော်တို့အနေဖြင့် ယခု analysis processကို table ဇယားများဆွဲကာ riskများ ၏ ပြင်းထန်မှု အဆင့်(rank)များအတိုင်း စီစဉ်သုံးသပ်သင့်ပါသည်။ တကယ့်လက်တွေ့ တွင် ထိုကဲ့သို့ ဇယားဆွဲနိုင်ရန် project၊ process၊ development team နှင့် organization အကြောင်းများကို အသေးစိတ်သိရန် လိုအပ်ပါသည်။ (Table ဥပမာများကို အောက်တွင် ဖော်ပြထားပါသည်။)

အခြား သတိထားသင့်သော အချက်မှာ ကျွန်တော်တို့ရရှိထားသော information များ updateဖြစ်လာသည်နှင့်အမျှ ကျွန်တော်တို့ဆွဲထားသည့် table၏ dataများကို ပြုပြင် ပြောင်းလဲ updateလုပ်သင့်ပါသည်။ riskများ၏ informationများ ရရှိလာသည်နှင့်အမျှ ၊ risk management planများကို လုပ်ဆောင်လာသည်နှင့်အမျှ Riskများ၏ ဖြစ်ပေါ်လာနိုင်ခြေများ (probability) နှင့် ယင်းတို့၏ effectများကို တွက်ချက်ထားမှုများသည် ပြောင်းလဲနေမည်ဖြစ်ပါသည်။

Riskများကို analyzeလုပ်ခြင်းနှင့် rankများခွဲခြင်း လုပ်ဆောင်ပြီးနောက် မည်သည့်riskများသည် အရေးပါဆုံးအရာများ ဖြစ်နိုင်ကြောင်း တွက်ချက်ထား သင့် ပါသည်။ တွက်ချက်မှုပြုလုပ်ရာတွင် riskတစ်ခု၏ ဖြစ်ပေါ်လာနိုင်ခြေ (probability) နှင့် ထိုrisk၏ effect နှစ်ခုစလုံးကို ကြည့်ပြီး တွက်ချက်ရပါမည်။ ယေဘုယျအားဖြင့် အပြင်းထန်ဆုံး (catastrophic)အဆင့်ရှိသည့် riskများကို ဦးစားပေး တွက်ချက် ကြပါသည်။

တွက်ချက်ထားသော riskအရေအတွက်သည် projectပေါ်တွင်မူတည်နေပါ သည်။ Risk အရေအတွက်များလေလေ informationများများ ပိုမိုလိုအပ်လေလေဖြစ်ပါ သည်။

အောက်ပါဇယားများကို ဥပမာအနေဖြင့် လေ့လာကာ riskများကို တွက်ချက်နိုင် ပါသည်။

Table 5.1

အထက်တွင်ဖော်ပြထားသော Table 5.1ဇယားသည် ဖြစ်ပေါ်လာနိုင်သော riskများကို ဖော်ပြထားသော ဇယားဖြစ်ပါသည်။

Table 5.2

ယခုအထက်တွင် ဖော်ပြထားသော Table5.2ဇယားသည် ခန့်မှန်းထားသော riskများကို identify ပြုလုပ်သော ဇယားဖြစ်ပါသည်။

5.4.3 Risk Planning

Risk planning processတွင် အဓိကrisk (key risk) များကို Table 5.2ဇယား အတိုင်း identifyပြုလုပ်ကာ ယင်းriskများကို စီမံခန့်ခွဲမည့် ဗျူဟာstrategyများကို identify ပြုလုပ်ပေးရပါသည်။ Risk management planများကို လုပ်ဆောင်ရန် ရိုးရှင်း သော processဟူ၍ မရှိပါ။ Risk management skillသည် project managerတစ် ယောက်၏ ဝေဖန်ပိုင်းခြားနိုင်စွမ်း နှင့် အတွေ့အကြုံများတွင် မူတည်ပါသည်။ Table 5.3 ဇယားသည် Table 5.2ဇယားတွင် identifyပြုလုပ်ထားသော key riskများကို ဖြေရှင်းနိုင် သည့် ဖြစ်နိုင်ခြေstrategy များကိုပြသပေးပါသည်။

၎င်း strategy များကို categoryသုံးခုဖြင့် တွေ့မြင်နိုင်ပါသည်။

1. Avoidance strategies: ယခု strategyများကို လိုက်နှာခြင်းအားဖြင့် ဖြစ်ပေါ်လာ နိုင်သော risk၏ ဖြစ်နိုင်ခြေကို လျော့ချနိုင်ပါသည်။ ဥပမာအားဖြင့် Table 5.3 ဇယား၏ defective component riskကို ရင်ဆိုင်သွားပုံကိုလေ့လာနိုင်ပါသည်။

2. Minimization strategies: ယခု strategyများကို လိုက်နှာခြင်းအားဖြင့် risk၏ သက်ရောက်မှုကို လျော့ချပေးနိုင်ပါသည်။ ဥပမာအားဖြင့် Table 5.3 ဇယား၏ Staff illness riskကို လေ့လာနိုင်ပါသည်။

3. Contingency plans: ယခု strategyများကို လိုက်နှာခြင်းအားဖြင့် ကျွန်တော်တို့ သည် အဆိုးဆုံးအခြေကို မျှော်မှန်းကာ ပြင်ဆင်ထားကြပြီး riskဖြစ်ပေါ်လာပါက လက်ဦးရယူဖြေရှင်းနိုင်ပါသည်။ ဥပမာအားဖြင့် Table 5.3 ဇယား၏ Organisational financial problemကို လေ့လာနိုင်ပါသည်။

Table 5.3

ကျွန်တော်တို့အနေဖြင့် riskတစ်ခုကို ရှောင်ရှားနိုင်သော strategy ကိုအသုံးပြု နိုင်လျှင် အကောင်းဆုံးဖြစ်ပါသည်။ အနည်းဆုံးတော့ ဖြစ်နိုင်လျှင် risk၏ ဖြစ်နိုင်ခြေကို လျော့ချပေးနိုင်သော strategyများကို အသုံးပြုသင့်ပါသည်။ နောက်ဆုံးအနေဖြင့် project (သို့) productအပေါ်တွင် သက်ရောက်နိုင်သော risk၏ပြင်းထန်မှုကို contingency planများဖြင့် လက်ဦးရယူလျော့ချနိုင်ပါသည်။

5.4.4 Risk monitoring

Risk monitoring processတွင် identifyလုပ်ထားသော riskများ၏ ဖြစ်နိုင်ခြေ များသလား(သို့) နည်းသလားနှင့် ထိုriskများ၏ effect ပြောင်းလဲသွားသလား အခြေအနေများကို ပုံမှန်စီစစ်ကြရပါသည်။ ထိုကဲ့သို့ စီစစ်ရာတွင် ကျွန်တော်တို့သည် တိုက်ရိုက်မသိမြင်နိုင်ပါ။ Risk၏ ဖြစ်နိုင်ခြေနှင့် ယင်း၏ effectကို ခန့်မှန်းဖော်ပြပေးနိုင် သော သဲလွန်စများကို ပေးနိုင်သည့် အခြားသော အကြောင်းအရင်းများကိုလည်း လေ့လာ သင့်ပါသည်။ ၎င်းအကြောင်းအရင်းများသည် riskအမျိုးအစားများပေါ်တွင် သိသိသာသာ မှီခိုနေပါသည်။ အောက်တွင် riskအမျိုးအစားများနှင့် ယင်းတို့ကိုဖြစ်ပေါ်စေနိုင်သော အကြောင်းအရင်း(factor) ဥပမာများကို တွေ့မြင်နိုင်ပါသည်။

1. Technology: hardware (သို့) support software များ deliveryနောက်ကျခြင်း၊ နည်းပညာအခက်အခဲများ ဖြစ်ပေါ်ခြင်း။

2. People: ဝန်ထမ်းများ စိတ်ဓာတ်သေးသိမ်ခြင်း၊ team memberများကြားတွင် ကောင်းမွန်သော relationship မရှိခြင်း၊ အသုံးချ skillနည်းပါးခြင်း။ (Job availability)

3. Organizational: အဖွဲ့အစည်းအတွင်း အတင်းအဖျင်းများရှိခြင်း၊ senior managementမှ လုပ်ဆောင်မှုအားနည်းခြင်း။

4. Tools: အသုံးပြုမည့် toolများနှင့် team memberများ ကိုက်ညီမှုမရှိခြင်း၊ CASE toolများ အားနည်းခြင်း၊ ပိုမိုကောင်းမွန်သော နည်းပညာများအသုံးပြုရန် တောင်း ဆိုခြင်း။

5. Requirements: လိုအပ်ချက်များအပေါ် ပြောင်းလဲမှု များပြားခြင်း၊ customer များမှ စိတ်ကျေနပ်မှုမရှိခြင်း။

6. Estimation: သဘောတူထားသည့် အချိန်ဇယား schedule အတိုင်း မပြီးမြောက် ခြင်း၊ ချို့ယွင်းမှု errorများကို အချိန်မှီ မပြုပြင်နိုင်ခြင်း တို့ဖြစ်ကြပါသည်။