ပေရာဂ်က္
ကုန္က်စရိတ္ကို တြက္ခ်က္ရာမွာ ေနာက္ထပ္ ထည္ ့သြင္းစဥ္းစားေလ ့ရွိ တဲ
့အေၾကာင္းအရာတစ္ခုကို ေဖာ္ၿပခ်င္ပါတယ္။ Reserve Analysis လုိ ့ေခၚၾကပါတယ္။
ဆိုလိုရင္းမွာ ခန္ ့မွန္းထားေသာ ဘတ္ဂ်က္ကုန္က်စရိတ္ထဲတြင္ ေငြေၾကး အပို
ပမာဏ မည္မွ်ထည္ ့ကာ စဥ္းသားထားသည္ကို စမ္းစစ္ၿခင္း ၿဖစ္ပါသည္။
(လက္ေတြ
့တြင္ ေငြေၾကး တစ္မ်ိဳးထဲသာ မဟုတ္ဘဲ အခ်ိန္၊ လူအင္အားစသည္ၿဖင္ ့လည္း
အပိုနဲနဲ ထည္ ့ ကာ ေနာင္ၿဖစ္လာႏိုင္သည္ ့အနာဂါတ္ၿပႆနာမ်ားအတြက္ ထည္
့သြင္းစဥ္းစားေလ ့ရွိပါသည္။ )
ဒီလိုစမ္းစစ္ေလ ့လာတဲ ့အခါမွာ သီးသန္
့ဖယ္ထားေသာပမာဏ(Reserves ) ကို ပေရာဂ်က္၏ မေသခ်ာေသာ ကုန္က်စရိတ္ေတြ အတြက္
အပိုေဆာင္း ထည္ ့ထားေသာ (Contingency Reserve) ႏွင္ ့ အနာဂါတ္မွာ
ေမွ်ာ္လင္ ့ မထားဘဲ ၿဖစ္လာႏိုင္တဲ ့ၿပႆနာေတြ အတြက္ သီးသန္ ့ ဖယ္ထားေသာ ပမာဏ
(Management Reserve) ဆိုၿပီး ၂ မ်ိဴး ခြဲၿခား ထားပါတယ္။
Contingency Reserve
ဒီအမ်ိဴးအစားေအာက္မွာဖယ္ထားတဲ ့ေငြေၾကးပမာဏကေတာ ့ပေရာဂ်က္တစ္ခုမွာ
သိထားၿပီးသား ၿဖစ္ႏိုင္ေခ်ရွိတဲ ့ ၿပႆနာ (Identified Risks) ေတြ အတြက္
ဖယ္ထားေလ ့ရွိတာပါ။ ဒီၿပႆနာေတြကို သိလဲသိၿပီးၿပီ၊
ၾကိဳတင္ကာကြယ္မႉေတြလုပ္ဖို ့လည္း ဆံုးၿဖတ္ၿပီးၿပီဆိုရင္ေတာ ့ဒီလို
အေရးေပၚသံုးဖို ့ပမာဏကို ၾကိဳတင္ၿပီး ဘတ္ဂ်က္ထဲမွာ ထည္ ့ထားရပါတယ္။
ပေရာဂ်က္စီမံခန္ ့ခြဲမႉ သီအိုရီ သေဘာတရားအရေတာ ့ “သိၿခင္း - မသိၿခင္း”
(Known-Unknown) ေတြအတြက္ ၿပင္ဆင္ထားၿခင္းလို ့ေခၚပါတယ္။ “သိၿခင္း”
ဆိုသည္မွာ ပေရာဂ်က္တစ္ခုအတြက္ ၿဖစ္လာႏိုင္သည္ ့့ ၿပန္လုပ္ရမည္
့လုပ္ငန္းစဥ္အခ်ိဳ ့(Reworks) ရွိသည္ကို သိၿခင္းၿဖစ္ၿပီး၊ “မသိၿခင္း”
ဆိုသည္မွာ ထိုသို ့ ၿပန္လည္ လုပ္ေပးရမည္ ့လုပ္ငန္းစဥ္မ်ား၏ ပမာဏ (Amount of
reworks) ကို မသိၿခင္းၿဖစ္သည္။
Contingency Reserves မ်ားကို
ဆက္ဆိုင္ရာ လုပ္ငန္းစဥ္တစ္ခုတည္း (A specific activity) အတြက္သာမကဘဲ
ပေရာဂ်က္တစ္ခုလံုး အတြက္ပါ စဥ္းစားၿပင္ဆင္ထားႏိုင္ပါသည္။ အခ်ိဳ
့ကုမၸဏီမ်ားသည္ ပေရာဂ်က္ ဘတ္ဂ်က္တြင္ Contingency Reserves မ်ားကို
ပေရာဂ်က္ကုန္က်စရိတ္တစ္ခုလံုး၏ ရာခိုင္ႏႉန္းတစ္ခုအေနၿဖင္ ့ လည္း သတ္မွတ္ေလ
့ရွိပါသည္။ အမ်ားအားၿဖင္ ့ေတာ ့ ၃% မွ ၅% အထိ သတ္မွတ္ေလ ့ရွိသည္။
အကယ္၍ ပေရာဂ်က္ ကို လုပ္ေဆာင္ေနရင္း ပိုၿပီးတိက်တဲ ့ အခ်က္အလက္ေတြရလာပါက
အဲဒီလို အေရးေပၚသံုးဖို ့ သတ္မွတ္ထားတဲ ့ ပမာဏကို ေလ်ာ ့ၿပစ္လိုက္ သို
့မဟုတ္ လံုးလံုးၿဖဳတ္ၿပစ္လုိက္လို ့ရပါတယ္။ ဂရုၿပဳသင္ ့တာ ကေတာ
့ပေရာဂ်က္တစ္ခုအတြက္ Contingency ဒီေလာက္ပမာဏ လိုအပ္တယ္ဆိုတာကို ပေရာဂ်က္
ကုန္က်စရိတ္တြက္ခ်က္မႉ မွတ္တမ္း (Cost Documentation) မွာ အတိအလင္း
မွတ္တမ္းတင္ၿပီး ခြင္ ့ၿပဳခ်က္ရယူ ထားဖို ့ေတာ ့ လုိပါတယ္။
Management Reserves
ကုန္က်စရိတ္ေတြ တြက္ခ်က္တဲ ့အခါမွာ ဒီ Management Reserve ကို ထည္
့သြင္းစဥ္းစားဖို ့လဲ အေရးၾကီးပါတယ္။ ဒီပမာဏ ကေတာ ့ အခု လက္ရွိအထိ မသိေသးတဲ
့ ပေရာဂ်က္ရဲ ့ အနာဂါတ္ၿပႆနာေတြအတြက္ ၾကိဳတင္ၿပီး သတ္မွတ္ထားတာ
ၿဖစ္ပါတယ္။
အမ်ားအားၿဖင္ ့ေတာ ့ဒီပမာဏကို ကုမၸဏီအထက္ပိုင္း လူၾကီးေတြက၊ ကန္
့ သတ္ထားေလ့ရွိပါတယ္။
အထက္မွာေၿပာခဲ ့သလိုပဲ သီအိုရီသေဘာတရားအေနနဲ
့ေတာ ့ Management Reserve ကို “မသိၿခင္း - မသိၿခင္း” (Unknown-Unknown)
လို ့ေခၚပါတယ္။ ၿပန္လုပ္ေပးရမည္ ့အလုပ္ (Reworks) ရွိမရွိ မသိသလို အဲ ့ဒီ
အလုပ္ပမာဏ (Amount of Reworks) ကိုလည္း မသိႏိုင္ေသးေပ။
ပေရာဂ်က္မန္ေနဂ်ာမ်ားအေနၿဖင္ ့ထို ပမာဏ သည္ ပေရာဂ်က္ ဘတ္ဂ်က္တြင္ ထည္
့သြင္းထားေသာ္လည္း တကယ္တမ္း ထိုပမာဏကို အသံုးၿပဳမည္ဆိုပါက
အထက္အုပ္ခ်ဳပ္ေရးပိုင္းလူၾကီး (Senior Management) ၏ ခြင္ ့ၿပဳခ်က္ကို
ထပ္မံရယူရမည္ၿဖစ္ပါသည္။
ေအာက္မွာေတာ ့ ပေရာဂ်က္စီမံခန္ ့ခြဲမႉ
ဗဟုသုတဆိုင္ရာ အဖြဲ ့အစည္း PMBOK (Project Management Body of Knowledge) ၏
၅ ၾကိမ္ေၿမာက္ထုတ္ေဝတဲ ့မွီၿငမ္းစာအုပ္မွာပါတဲ ့ “ပေရာဂ်က္ဘတ္ဂ်က္ ႏွင္ ့
သက္ဆိုင္ရာ အစိတ္အပိုင္းမ်ား” ၿပထားတဲ ့ပံုကို ဗဟုသုတ အေနၿဖင္ ့
ေဖာ္ၿပေပးလိုက္ပါတယ္။
အပိုင္း-၁ မွာေဖာ္ၿပခဲ
့တဲ ့ top-down နဲ ့bottom-up စဥ္းစားနည္းေတြအၿပင္ အၿခားသံုးေလ့ရွိတဲ ့
ဘတ္ဂ်က္တြက္ခ်က္ နည္းေတြ ကေတာ ့ေအာက္ပါ အတိုင္းၿဖစ္ပါတယ္။
၁။ ကြ်မ္းက်င္သူမ်ားၿဖင္ ့ခန္ ့မွန္းသံုးသပ္ၿခင္း (Expert Judgement)
၂။ ကုန္ပစၥည္းေရာင္းသူ သို ့မဟုတ္ ဝန္ေဆာင္မႉေပးသူမ်ား ၏ ေစ်းၿပိဳင္ေပးမႉ ကို ပိုင္းၿခားေလ့လာၿခင္း (Suppliers’ Bid Analysis)
၃။ ဆင္တူကိုးကား၍ ခန္ ့မွန္းၿခင္း (Analogous Estimating)
၄။ ၿဖစ္ႏိုင္ေခ် ၃ ခု ႏွင့္ ခန္ ့မွန္းနည္း (Three-Point Estimating)
၅။ အခ်က္အလက္ဆက္ႏြယ္မႉၿဖင္ ့ခန္ ့မွန္းၿခင္း (Parametric Estimating)
၁။ ကြ်မ္းက်င္သူမ်ားၿဖင္ ့ခန္ ့မွန္းသံုးသပ္ၿခင္း (Expert Judgement)
ဒီနည္းလမ္းကေတာ ့ဘတ္ဂ်က္ကုိတြက္ခ်က္ရာမွာ၊ လုပ္ငန္းနဲ ့ပတ္သက္ၿပီး အေတြ
့အၾကံဳရွိၿပီး ကြ်မ္းက်င္တဲ ့သူေတြကို ပေရာဂ်က္ ကုန္က်စရိတ္ကို ခန္
့မွန္းသံုးသပ္ ခိုင္းတာၿဖစ္ပါတယ္။
ဒီလိုအသံုးၿပဳၿခင္းရဲ
့အားသာခ်က္ကေတာ ့ ကြ်မ္းက်င္သူမ်ားသည္ အေတြ ့အၾကံဳရွိသူမ်ားၿဖစ္သၿဖင္ ့
ပေရာဂ်က္ႏွင္ ့ ပတ္သက္၍ လုပ္ေဆာင္ရမည္ ့လုပ္ငန္းစဥ္မ်ား (Activities/tasks)
အၿပင္၊ အရင္က ေတြ ့ ၾကံဳခဲ ့ဖူးေသာ အခက္အခဲမ်ားကို ထည္
့သြင္းစဥ္းစားႏိုင္ၿခင္းပင္ၿဖစ္ပါသည္။ ဤကဲ ့သို ့ ၿဖစ္ႏိုင္ေခ်ရွိေသာ
ၿပႆနာမ်ားအား ၾကိဳတင္စဥ္းစားႏိုင္ၿခင္းသည္ ပေရာဂ်က္တစ္ခုလံုး အတြက္ အလြန္
အက်ိဴးေက်းဇူး မ်ားလွေပသည္။
၂။ ကုန္ပစၥည္းေရာင္းသူ သို ့မဟုတ္ ဝန္ေဆာင္မႉေပးသူမ်ား ၏ ေစ်းၿပိဳင္ေပးမႉကို ပိုင္းၿခားေလ့လာၿခင္း (Suppliers’ Bid Analysis)
ဤကဲ ့သို ့ေစ်းၿပိဳင္စနစ္ကုိ အသံုးၿပဳၿခင္းၿဖင္ ့ မိမိ ပေရာဂ်က္အတြက္
လ်ာထားသတ္မွတ္ ထားေသာ ဘတ္ဂ်က္ေစ်းႏႉန္းေရာက္သည္အထိ ထိုသူတို
့၏ေရာင္းေစ်းကို ညိွယူႏိုင္ပါလိမ္ ့မည္။
၃။ ဆင္တူကိုးကား၍ ခန္ ့မွန္းၿခင္း (Analogous Estimating)
ဒီနည္းလမ္းကေတာ ့ ပေရာဂ်က္ဘတ္ဂ်က္ကို အရင္က ဆင္တူလုပ္ဖူးထားေသာ
ပေရာဂ်က္မ်ား မွ မီွၿငမ္း တြက္ခ်က္ၿခင္းၿဖစ္ပါသည္။ မ်ားေသာအားၿဖင္
့မိမိလုပ္ေဆာင္ေတာ ့မည္ ့ပေရာဂ်က္ႏွင္ ့ ပတ္သက္၍ သတင္းအခ်က္အလက္
အနည္းအက်ဥ္းသာရွိပါက သံုးေလ့ရွိသည္။ ဥပမာအားၿဖင္ ့ ၿပီးခဲ ့သည္ ့
လအနည္းငယ္က ဝက္ဘ္ဆိုက္ တစ္ခု ေထာင္ရန္ ေဒၚလာ ၇၀၀၀ ကုန္က်ခဲ ့ သည္ဆိုပါစို
့။ အခု အလားတူ ဝက္ဘ္ဆိုက္ တစ္ခုကို ထပ္ၿပီးေထာင္ရမည္ဆိုပါက ကုန္က်စရိတ္ကို
၇၀၀၀ ဟုသာ ခန္ ့ မွန္းလိုက္ၿခင္းၿဖစ္ပါသည္။
၄။ ၿဖစ္ႏိုင္ေခ် ၃ ခု ႏွင့္ ခန္ ့မွန္းနည္း (Three-Point Estimating)
ဒီနည္းကေတာ ့ေတာ္ေတာ္အသံုမ်ားပါတယ္။ ၿဖစ္ႏိုင္ေခ် ၃ ခု ကို
အရင္စဥ္းစားပါတယ္။ အၿဖစ္ႏုိင္ဆံုးအေၿဖအေန (O = Optimistic) ၊
အလယ္အလတ္အေၿခအေန (M = Most Likely) နဲ ့ ၿဖစ္ႏိုင္ေခ်အနည္းဆံုး (P =
Pessimistic) အေၿခအေနတို ့ပဲၿဖစ္ပါတယ္။ အဲ ့ဒီေနာက္ သက္ဆိုင္ရာတန္ဖိုး ၃
ခုကိုေပါင္းၿပီး ပ်မ္းမွ် တန္ဖိုး ရေစရန္ ၃ ၿဖင္ ့စားၿခင္းၿဖစ္ပါသည္။
ပံုေသနည္း [Expected value = (P+M+O)/3]
အလားတူသံုးႏိုင္တဲ
့ေနာက္ထပ္တစ္နည္းကေတာ ့PERT (Program Evaluation and Review Technique) လို
့ေခၚပါတယ္။ သူကေတာ ့သာမန္ပ်မ္းမွ်တင္မဟုတ္ဘဲ Beta Distribution လို ့ေခၚတဲ
့ သခၤ်ာပံုေသနည္း ကို သံုးပါတယ္။ [Expected value = (P+4M+O)/6]
၂ ခုစလံုးၾကိဳက္ရာကို အသံုးၿပဳႏိုင္ပါတယ္။
၅။ အခ်က္အလက္ဆက္ႏြယ္မႉၿဖင္ ့ခန္ ့မွန္းၿခင္း (Parametric Estimating)
ဒီနည္းကေတာ ့ပေရာဂ်က္ တစ္ခုမွာပါဝင္တဲ ့ အခ်က္အလက္ဆိုင္ရာ
ဆက္ႏြယ္မႉကိန္းဂဏန္း (Variables) ေတြကို အေၿခခံၿပီး ခန္ ့
မွန္းၿခင္းၿဖစ္ပါတယ္။ သူကလဲ အရင္တုန္းက လုပ္ခဲ ့တဲ ့သက္ဆိုင္ရာ
အခ်က္အလက္ေတြကိုေတာ ့(Historical Records) ၿပန္လည္မီွၿငမ္းပါတယ္။
ဤနည္းလမ္းၿဖင္ ့ခန္ ့ မွန္းၿခင္းမွာေတာ ့အဆတိုးကာ စဥ္းစားလို ့ရေသာ
(Scalable) တြက္ခ်က္မႉမ်ိဳးေတြမွာ သံုးေလ ့ရွိပါတယ္။ ဥမမာအေနၿဖင့္
လူတစ္ဦးသည္ ၿမက္တစ္ဧက ရိတ္ရန္ ၂ နာရီၾကာ သည္ဆိုပါစို ့။ ၄ ဧကရိတ္မည္
ဆိုပါက ၈နာရီ ၾကာေပလိမ္ ့မည္။
အခုထိဆိုရင္ၿဖင္ ့ဘတ္ဂ်က္
တြက္ခ်က္နည္းမ်ားေတာ္ေတာ္ စံုစံုလင္လင္ရိွပါၿပီ။ စာဖတ္သူမ်ားအေနၿဖင္ ့လည္း
ရွင္းၿပခဲ ့တဲ ့ ခန္ ့မွန္းတြက္ခ်က္ နည္းေတြထဲက မိမိပေရာဂ်က္ အေၿခအေနၿဖင္
့သင္ ့ေတာ္ရာကို အသံုးၿပဳႏိုင္ၾကပါသည္။
ဘတ္ဂ်က္ႏွင္ ့ပတ္သက္၍ ဆက္ပါဦးမည္။
ပေရာဂ်က္တစ္ခု စတင္သည္
့့အခါတြင္ ဒီပေရာဂ်က္တစ္ခုလံုးသည္ ဘယ္ေလာက္ကုန္က်မလဲဆိုတာ အတိအက်
တြက္ခ်က္ဖို ့အလြန္ ခက္ခဲပါတယ္။ ပေရာဂ်က္မန္ေနဂ်ာမ်ားသည္ ထိုသို
့တြက္ခ်က္ဖို ့ အၿမဲ တာဝန္ယူ ရေလ ့ရွိပါတယ္။ ေသေသခ်ာခ်ာ မသိေသးတဲ
့အခ်က္အလက္ေတြ အမ်ားၾကီး ရွိသည္ ့့အတြက္ ကုန္က်စရိတ္အား ခန္ ့မွန္းရသည္မွာ
အလြန္ ခက္ခဲလွပါသည္။
တိက်မွန္ကန္ေသာ ကုန္က်စရိတ္
တစ္ခုတြက္ခ်က္ႏိုင္ၿခင္းသည္ ပေရာဂ်က္ မန္ေနဂ်ာ တစ္ေယာက္္ အတြက္အလြန္
အေရးပါေသာ အရည္အခ်င္းတစ္ခုပင္ၿဖစ္ပါသည္။
အေၿခခံ အားၿဖင္ ့နည္းလမ္း ၂ ခုရွိပါတယ္။ တိုက္ရိုက္ဘာသာၿပန္လိုက္ပါက
၁။ အေပၚမွ ေအာက္သို ့ခ်ဥ္းကပ္နည္း (Top Down Approach) :
ဒီနည္းလမ္းကေတာ ့ ပေရာဂ်က္တစ္ခုလံုး ဘယ္ေလာက္ကုန္က်မည္ကို သိဖို ့နဲ ့
လုပ္ငန္းစဥ္ အပိုင္းလိုက္ ကုန္က်စရိတ္ကို တြက္ခ်က္တဲ ့ေနရာမွာ သံုးၾကပါတယ္။
၂။ ေအာက္မွ အေပၚသို ့ခ်ဥ္းကပ္နည္း (Bottom Up Approach) :
ဒီနည္းကေတာ ့လုပ္ငန္းအစိတ္အပိုင္း အေသးစိတ္ တစ္ခုခ်င္းစီ ရဲ
့ကုန္က်စရိတ္ကေန စတင္တြက္ခ်က္ၿပီး ပေရာဂ်က္တစ္ခုလံုး အတြက္ ၿပန္ၿပီး
ၿခံဳငံုသံုးသပ္ၿခင္း ၿဖစ္ပါတယ္။
နည္းလမ္း ၂ခု စလံုးကေတာ ့သူ
့အားနည္းခ်က္၊ အားသာခ်က္ေတြ ကိုယ္စီရွိပါတယ္။ ေအာက္မွာ
နည္းလမ္းတစ္ခုခ်င္းစီကို အေသးစိတ္ ေလ ့လာၾကည္ ့ၾကရေအာင္။
Top Down Approach
ဒီနည္းလမ္းကေတာ ့မ်ားေသာအားၿဖင္ ့ကုမၸဏီရဲ ့အထက္ပိုင္း လူၾကီးေတြသံုးေလ
့ရွိတဲ ့နည္းပါ။ သူတို ့က ပေရာဂ်က္တစ္ခု ဘယ္ေလာက္ကုန္က်သင္ ့တယ္ဆိုၿပီး
ဆံုးၿဖတ္ခ်က္ အရင္ခ်ပါတယ္။ ၿပီးေတာ ့မွ လုပ္ငန္း အစိတ္အပိုင္းအလိုက္ မည္ေရြ
့မည္မွ် ကုန္က်လိမ္ ့မည္ကိုၿပန္လည္ခြဲၿခားပါတယ္။
ဥပမာအားၿဖင္
့အထက္လူၾကီး ဒါရိုက္တာအဖြဲ ့ဝင္မ်ားက ပေရာဂ်က္တစ္ခုလံုးရဲ ့ကုန္က်စရိတ္ဟာ
၁၀ သန္း ဟုခန္ ့မွန္း သတ္မွတ္ၾက သည္ ဆိုပါစို ့။ မ်ားေသာအားၿဖင္ ့ေတာ ့
အထက္လူၾကီးေတြဟာ ကုမၸဏီကေနွ အရင့္အရင္ လုပ္ေဆာင္ခဲ ့ ဖူးသည္ ့ ပေရာဂ်က္
မ်ား၏ ကုန္က်စရိတ္ေတြကို ၿပန္ၿပီး ကိုးကားေလ ့ရွိပါတယ္။ အဲ ့ ဒါေတြအေပၚ
မူတည္ၿပီးမွ အရင္က ဒီပေရာဂ်က္ အေနအထားဆိုရင္ ၁၀ သန္းကုန္က်ခဲ ့တယ္။ ဒီေတာ ့
အခုပေရာဂ်က္ဟာ လဲ ပ်မ္းမွ် အဲ ့ ဒီေလာက္ပဲ ကုန္က်လိမ္ ့မယ္ဟု
ဘတ္ဂ်က္ကိုသတ္မွတ္ပါလိမ္ ့မယ္။
အားသာခ်က္ အေနၿဖင္ ့ေတာ ့
ဘတ္ဂ်က္ကို အရင္ သတ္မွတ္ေပးလိုက္တဲ ့အတြက္ ပေရာဂ်က္ဟာ သတ္မွတ္ေပး ထားတဲ
့ကုန္က်စရိတ္အတြင္းမွာပဲ ၊ အေလအလြင္ ့နဲနဲ ႏွင္ ့ ၿပီးေၿမာက္ေအာင္ၿမင္
သြားႏိုင္ပါတယ္။
အားနည္းခ်က္အေနၿဖင္ ့ကေတာ
့ဒီဘတ္ဂ်က္သတ္မွတ္ေပးလိုက္တဲ ့လူဟာ တကယ္ ့ကို လုပ္ငန္း အေတြ ့ အၾကံဳရွိတဲ
့လူၿဖစ္ရပါမယ္။ ဒါမွလဲ လက္ေတြ ့က်တဲ ့ကုန္က်စရိတ္ကို အနီးစပ္ဆံုး
သတ္မွတ္ေပးႏိုင္မွာပါ။ အဲ ့ ဒီလိုသာမဟုတ္ခဲ ့ရင္ေတာ ့ပေရာဂ်က္ကို တကယ္
လုပ္ကိုင္တဲ ့အခါမွာ လက္ေတြ ့မက်တဲ ့ ဘတ္ဂ်က္ေၾကာင္ ့ေရရွည္မွာ ၿပႆနာ
အခက္အခဲေတြ အမ်ားၾကီး ၾကံဳေတြ ့ပါလိမ္ ့မယ္။
Bottom Up Approach
ဒီနည္းလမ္းမွာေတာ ့လုပ္ေဆာင္ရမယ္ ့လုပ္ငန္းတစ္ခုခ်င္းစီ (Activity/Task)
ကို အရင္ဆံုး စၿပီး စဥ္းစားရပါတယ္။ ဥပမာအားၿဖင္ ့ ဒီဇိုင္းတြက္ခ်က္
မႉလုပ္ေဆာင္ရန္ အဆင္ ့ ၁၀ ဆင္ ့ လုိအပ္သည္ဆိုပါစို ့။ ထိုအဆင္
့တစ္ခုကိုၿပဳလုပ္ရန္ ၁ သိန္းကုန္က်မည္ဆိုပါက အဆင္ ့ ၁၀ ဆင္ ့အတြက္ ၁၀
သိန္းကုန္က်ေပလိမ္ ့မည္။ ထိုမွတဖန္ ပစၥည္းဝယ္ယူရန္ မည္မွ်ကုန္မည္ ၊
သယ္ယူပို ့ေဆာင္ရန္ မည္မွ်ကုန္မည္၊ အစရွိ သၿဖင္ ့ပေရာဂ်က္ တစ္ခုလံုးစာအတြက္
ဆက္လက္ တြက္ခ်က္သြားၿခင္းၿဖစ္သည္။
ထိုသို ့ၿပဳလုပ္ၿခင္း၏
အားသာခ်က္မွာ ပေရာဂ်က္တြင္ ပါဝင္ပတ္သက္သူ အသင္းသားမ်ားကပါ
ဘတ္ဂ်က္တြက္ခ်က္ရာတြင္ ပါဝင္ေဆြးေႏြးႏိုင္ ခြင္ ့ရၾကသၿဖင္ ့အသင္းဝင္မ်ားသည္
တြက္ခ်က္ထားသည္ ့ ဘတ္ဂ်က္အေပၚကို ပို၍ ယံုၾကည္မႉၿမင္ ့ မားေစသည္။
လုပ္ငန္းစဥ္စာရင္း (Activity List) အေပၚအေၿခခံ ထားသၿဖင္ ့ လုပ္ရမည္
့လုပ္ငန္းစဥ္ စာရင္းၿပည္ ့စံုပါက အနီးစပ္ဆံုး တိက်ေသာဘတ္ဂ်က္ကို
ရရွိႏိုင္မည္ၿဖစ္သည္။
အားနည္းခ်က္အေနၿဖင္ ့ေတာ ့ဤနည္းတြင္
လုပ္ေဆာင္မည္ ့လုပ္ငန္းစဥ္မ်ား စာရင္း (Activity List) ကို ၿပဳစုရန္
အခ်ိန္ေပးရၿခင္း၊ လုပ္ငန္းစဥ္စာရင္းတြင္ လုပ္ေဆာင္ရမည္ ့လုပ္ငန္းတခ်ိဳ
့က်န္ေနခဲ ့သၿဖင္ ့ ရုတ္တရက္ေပၚလာမွ ဘတ္ဂ်က္ကို လိုသလို
အသံုးၿပဳလိုက္ရၿခင္း စသည္ ့ အေၿခအေနမ်ား ေတြ ့ၾကံဳလာ ႏိုင္ပါသည္။
ေရွ ့ဆက္ၿပီး ကုန္က်စရိတ္အမိ်ဴးအစားမ်ားကို ေၿပာၿပသြားပါမယ္။ အေၿခခံအားၿဖင္ ့ကုန္က်စရိတ္မ်ားကို
တိုက္ရိုက္ကုန္က်စရိတ္ (Direct Cost) : ဤကုန္က်စရိတ္သည္ သက္ဆိုင္ရာ
ပေရာဂ်က္တစ္ခုတည္းအတြက္ၿဖစ္ၿပီး လုပ္ငန္းေဆာင္တာ တစ္ခုခ်င္းစီအတြက္
ကုန္က်စရိတ္ၿဖစ္သည္။ ဥပမာအားၿဖင္ ့လူအင္အား (Labor)၊ ကုန္ပစၥည္း (Raw
Materials)၊ ေဆာ ့ဖ္ဝဲလ္ လိုင္စင္ (Software Licenses)၊
အတိုင္ပင္ခံကြ်မ္းက်င္သူမ်ားအတြက္ ကုန္က်စရိတ္ (Consultant Fees)၊
ခရီးသြားစရိတ္ (Travel) အစရွိသည္တို ့ၿဖစ္သည္။
တိုက္ရိုက္မဟုတ္ေသာ
ကုန္က်စရိတ္ (Indirect Cost) : ဒီကုန္က်စရိတ္ေတြကေတာ ့ပေရာဂ်က္ တစ္ခုတည္း
အတြက္ကုန္က်တာမဟုတ္ပဲ၊ ကုမၸဏီတစ္ခု လံုးအေနၿဖင္ ့ ကုန္က်ၿခင္းၿဖစ္ပါတယ္။
ပံုမွန္အားၿဖင္ ့ေတာ ့ကုန္က်စရိတ္ေတြရဲ ့ တစိတ္တပိုင္းကိုသာ ပေရာဂ်က္ကေန
ေပးေဆာင္ရပါတယ္။ ဥပမာ တယ္လီဖုန္းေဘမ်ား (Telephone charges) ၊
ရုံးခန္းငွားရန္းခ (Office space (rent))၊ ကုမၸဏီအာမခံမ်ား (Company
insurance) ႏွင္ ့အေထြေထြ စီမံခန္ ့ခြဲမႉ (General administration) စသၿဖင္
့ၿဖစ္ပါတယ္။
ဘတ္ဂ်က္နဲ ့ပတ္သက္ၿပီးဆက္လက္ ေဖာ္ၿပပါဦးမည္။
ဒီတစ္ခါေတာ ့ပေရာဂ်က္အသင္းေတြကို ထိမ္းေက်ာင္းကိုင္တြယ္တဲ ့ေနရာမွာ
အသံုးၿပဳေလ ့ရွိတဲ ့ သီအိုရီတစ္ခုနဲ ့ မိတ္ဆက္ေပးခ်င္ပါတယ္။
ဒီသီအိုရီကိုေတာ ့ဘရုစ္ဝိန္းတပ္ခ္မန္ (Bruce Wayne Tuckman) ဆိုတဲ ့
စိတ္ပညာရွင္တစ္ဦးက ၁၉၆၅ ခုႏွစ္မွာ ေရးသား ထုတ္ၿပန္ခဲ ့တာၿဖစ္ပါတယ္။
တပ္ခ္မန္၏ အဆင္ ့မ်ား (Tuckman's Stages) လို ့ ေခၚၾကပါတယ္။
သူရဲ
့ေလ ့လာမႉအဆိုအရ၊ ပေရာဂ်က္အသင္း သို ့မဟုတ္ အသင္းအဖြဲ ့တစ္ခုသည္ အတူတကြ
ပူးေပါင္းၿပီး အရည္အေသြးၿမင္ ့ေသာ ရလာဒ္မ်ားကို ယူေဆာင္ေပးႏိုင္ရန္ အတြက္
ထိုအဆင္ ့မ်ားကို မလြဲမေသြ ၿဖတ္သန္းၾကရမည္ဟုဆိုပါသည္။ မူလက အဆင္ ့၄ဆင္
့ရွိေနရာမွ ၁၉၇၇ ခုႏွစ္တြင္ ေနာက္ထပ္တစ္ဆင္ ့ကိုထပ္ၿပီး ထည္ ့သြင္းခဲ
့ၿပီးစုစုေပါင္း အဆင္ ့ ၅ ဆင္ ့ၿဖစ္လာခဲ ့သည္။ ေအာက္မွာေတာ ့အဲ ့ဒီအဆင္
့ေတြကိုေဖာ္ၿပေပးထားပါတယ္။
၁။ ဖြဲ ့စည္းၿခင္းအဆင္ ့(Forming)
၂။ ၿပင္းထန္လႉပ္ရွားေသာအဆင္ ့(Storming)
၃။ ပံုမွန္ၿဖစ္ၿခင္းအဆင္ ့(Norming)
၄။ ၿပဳလုပ္ေဆာင္ရြက္ႏိုင္ၿခင္း အဆင္ ့(Performing)
၅။ ၿပီးဆံုးရပ္နားၿခင္းအဆင္ ့(Adjourning)
၁။ ဖြဲ ့စည္းၿခင္းအဆင္ ့(Forming)
ဒီအဆင္ ့ကေတာ ့ယဥ္ယဥ္ေက်းေက်း စူးစမ္းတဲ ့အဆင္ ့ပါ။ ပေရာဂ်က္အသင္းမွာ ပါတဲ
့သူေတြဟာ တစ္ေယာက္နဲ ့ တစ္ေယာက္ မသိေသးတဲ ့အတြက္ နဲနဲစိမ္းေနၿပီး
သတိထားဆက္ဆံၾကပါလိမ္ ့မယ္။ အမ်ားစုကေတာ ့" ငါ ့ဆီကေန ဘာေတြမ်ားေမွ်ာ္လင္
့ေနလဲ?" "အသင္းထဲက က်န္တဲ ့လူေတြကေရာ ဘယ္လိုလူမ်ိဴးေတြလဲ?" ဆိုတာေတြကို
ေတြးေနၾကတဲ ့အဆင္ ့ပါ။ အနဲဆံုးေတာ ့ဒီအဆင္ ့မွာ ပေရာဂ်က္ မန္ေနဂ်ာကေန
တစ္ေယာက္နဲ ့တစ္ေယာက္ ကို မိတ္ဆက္ေပး၊ ကိုယ္ ့အေၾကာင္းကိုယ္နဲနဲ
ေၿပာၿပေစၿခင္းနဲ ့၊ ရင္းႏွီးမႉ အနည္းငယ္ရေအာင္လုပ္ရပါမယ္။
၂။ ၿပင္းထန္လႉပ္ရွားေသာအဆင္ ့(Storming)
ဒီအဆင္ ့ကေတာ ့နဲနဲၿပႆနာ ရွိတဲ ့ဆင္ ့ပါ။ အခုေလာက္ဆိုရင္ေတာ ့
အသင္းသားေတြဟာ တစ္ေယာက္နဲ ့ တစ္ေယာက္ ေကာင္းေကာင္းသိေနၾကၿပီၿဖစ္တဲ ့အတြက္
လုပ္ငန္းဆိုင္ရာ အေတြးအေခၚ ေတြ၊ ဆံုးၿဖတ္ခ်က္ေတြကို သေဘာတူတယ္
မတူတယ္ဆိုတာကို ပြင္ ့ပြင္ ့လင္းလင္း ၿငင္းခံုၾကပါလိမ္ ့မယ္။
ပေရာဂ်က္
မန္ေနဂ်ာေတြ အေနနဲ ့ဒီအဆင္ ့ကို ပါးနပ္စြာသတိထားကိုင္တြယ္သင္ ့ပါတယ္။
အသင္းသားေတြဟာ သေဘာထားကြဲလြဲမႉေတြ နဲ ့အၿမစ္တြယ္ မေနပဲ၊
လုပ္ငန္းတာဝန္ေတြကို ေရွ ့ဆက္ႏိုင္ေအာင္ လမ္းၿပဦးေဆာင္ရပါတယ္။
Tuckman
ရဲ ့အဆိုအရေတာ ့အသင္းတစ္သင္းဟာ Storming အဆင္ ့ကိုမၿဖစ္မေနၿဖတ္သန္းေတြ
့ၾကံဳဖို ့ လုိပါတယ္။ဒါမွလည္း တစ္ဦးနဲ ့တစ္ဦးဆီကေန သီးခံႏိုင္ၿခင္း၊
နားလည္ၿခင္း၊ စတဲ ့အဖိုးတန္တဲ ့အေတြ ့အၾကံဳေတြကို
သင္ခန္းစာယူႏိုင္ၾကပါလိမ္ ့မယ္။
၃။ ပံုမွန္ၿဖစ္ၿခင္းအဆင္ ့(Norming)
ဒီအဆင္ ့မွာကေတာ ့တစ္ဦးနဲ ့တစ္ဦး လိုက္ေလ်ာကူညီတဲ ့အဆင္ ့ပါ။
တစ္ေယာက္အေၾကာင္းတစ္ေယာက္ ေကာင္းေကာင္းသိသြားၾကၿပီၿဖစ္တဲ ့အတြက္
တတ္ႏိုင္သမွ် သေဘာထားကြဲလြဲမႉၿပႆနာေတြမၿဖစ္ေအာင္ ေရွာင္ၾကၿပီး
အလုပ္တာဝန္ေတြၿပီးဖို ့အတြက္ကိုသာ ပိုၿပီးၾကိဳးစားပါလိမ္ ့မယ္။
သေဘာထားကြဲလြဲမႉေတြ ရွိႏိုင္ေသးေပမယ္ ့အမ်ားစုရဲ ့ ဆႏၵအတိုင္း
လိုက္နာေဆာင္ရြက္ပါလိမ္ ့မယ္။
၄။ ၿပဳလုပ္ေဆာင္ရြက္ႏိုင္ၿခင္း အဆင္ ့(Performing)
ဒီအဆင္ ့ကေတာ ့အေကာင္းဆံုးအဆင္ ့ပါ။ အသင္းသား အားလံုး ဟာမိမိတို ့ရဲ
့အလုပ္တာဝန္ေတြကို ေအာင္ေအာင္ၿမင္ၿမင္ လုပ္ႏိုင္ေနၾကၿပီး၊ တစ္သင္းလံုး
အေနနဲ ့ေဆာင္ရြက္ခ်က္ဟာ အထြတ္အထိပ္ကိုေရာက္ေနပါၿပီ။ တစ္ဦးနဲ ့
တစ္ဦးဆက္ဆံေရးကလည္း အသားက်ေနၿပီး အၿပန္အလွန္ ထိမ္းေက်ာင္းကာ
ညိႉႏႉိင္းေဆာင္ရြက္ေနၾကၿပီ။
၅။ ၿပီးဆံုးရပ္နားၿခင္းအဆင္ ့(Adjourning)
ဒီအဆင္ ့ကိုေတာ ့၁၉၇၇ ခုႏွစ္က်မွ Tuckman ကထပ္ထည္ ့လုိက္တာပါ။ ၿပီးဆံုးရပ္နားၿခင္း အဆင္ ့လို ့ေခၚပါတယ္။
လုပ္ငန္း တာဝန္ေတြ ၿပီးဆံုးတဲ ့့အတြက္ အသင္းသားေတြ အားလံုး ခြဲခြာရမယ္
့အေၿခအေနပါ။ ဒီအခ်ိန္မွာေတာ ့ ပေရာဂ်က္ မန္ေနဂ်ာေတြဟာ
လုပ္ငန္းတာဝန္ေတြၿပီးဆံုးမႉ ေအာင္ပြဲကို အသင္းသားေတြနဲ ့အတူ
က်င္းပဆင္ႏႊဲသင္ ့ ပါတယ္။ ဒါ ့ အၿပင္ မိမိတုိ ့အတူအကြ လုပ္ခဲ ့တဲ ့ အေတြ
့အၾကံဳ ေတြကိုလည္း ၿပန္လည္ေဝဖန္ သံုးသပ္ႏိုင္ပါတယ္။ ေနာက္ဆံုးအေနနဲ ့
အသင္းသား အခ်င္းခ်င္း တစ္ဦးနဲ ့တစ္ဦး ႏုတ္ဆက္ၾကၿပီး၊ စိတ္မေကာင္းစြာနဲ
့ခြဲခြာၾကရတဲ ့အဆင္ ့ပါ။
ဒီပို ့စ္ေလးမွာေတာ ့ပေရာဂ်က္ စီမံခန္ ့ခြဲမႉ နယ္ပယ္မွာ အသံုးမ်ားၿပီး
ထိေရာက္မႉရွိတဲ ့ RACI (ရာဆီ) Matrix လို ့ေခၚတဲ ့ ဇယားကြက္ေလးတစ္ခု ကို
မွ်ေဝခ်င္ပါတယ္။ ပေရာဂ်က္တစ္ခု စတင္ၿပီဆိုပါက ပထမဆံုးအေနနဲ ့ ပါဝင္မယ္ ့
အသင္းသားေတြကို ေရြးခ်ယ္ ဖဲြ ့စည္းရပါတယ္။ အဲ ့ဒီ အသင္းသားေတြမွာ ဘယ္သူက
ဘယ္တာဝန္ကိုယူရမယ္္၊ ဘယ္အလုပ္တာဝန္အတြက္ သူသာ သီးသန္ ့ ေဆာင္ရြက္မယ္၊
ဘယ္လို အခန္းကဏၰေတြက ပါဝင္လုပ္ကိုင္ရမည္၊ စသၿဖင္ ့
တိတိက်က် သတ္မွတ္ထားရန္ လိုပါသည္။
ထိုသို ့တာဝန္ခြဲေဝမႉေတြကို တိတိက်က် နဲ
့လြယ္လြယ္ကူကူ လုပ္ေဆာင္ႏိုင္ဖို ့ ဒီ RACI Matrix ကို အသံုးၿပဳၾကပါတယ္။
RACI ရဲ ့အဓိပါၸယ္ကို ေအာက္မွာၾကည္ ့ၾကရေအာင္၊
R - Responsible (လုပ္ေဆာင္ရန္ တာဝန္ယူမႉ)
ဘယ္သူက ဒီလုပ္ငန္း တာဝန္ကို လုပ္ေဆာင္ရန္ အတြက္ တာဝန္ယူရမည္။
A - Accountable (ဦးေဆာင္ေၿဖရွင္းရန္ တာဝန္ယူမႉ)
ဘယ္သူက ဒီလုပ္ငန္းတာဝန္ အဆင္မေၿပၿဖစ္ခဲ ့ပါက ေၿဖရွင္းေဆာင္ရန္ အတြက္ တာဝန္ယူရမည္။
C - Consulted (ေဆြးေႏြးတုိင္ပင္မႉ)
ဒီလုပ္ငန္းတာဝန္ နဲ ့ပတ္သက္ၿပီး ေဆြးေႏြး အတိုင္ပင္ခံ အၿဖစ္ေဆာင္ရြက္ရမည္။
I - Informed (သတင္းပို ့အေၾကာင္းၾကားမႉ)
ဘယ္သူေတြဆီကို အလုပ္တာဝန္ရဲ ့ၿပီးေၿမာက္မႉ ေတြကို သတင္းပို ့အေၾကာင္းၾကားရမည္။
ေဆြးေႏြးတိုင္ပင္မႉ (Consulted) နဲ ့သတင္းပို ့အေၾကာင္းၾကားမႉ (Informed)
တို ့ရဲ ့ၿခားနားခ်က္ ကေတာ ့ ေဆြးေႏြးတိုင္ပင္မႉသည္ အၿပန္အလွန္
ႏွစ္ဦးႏွစ္ဖက္ ေၿပာဆိုၿခင္းၿဖစ္ၿပီး သတင္းပို ့ အေၾကာင္းၾကားၿခင္းကေတာ ့
အသိေပးရုံသက္သက္ တလမ္းသြားဆက္သြယ္မႉမ်ိဴး ပဲၿဖစ္ပါတယ္။
ဘယ္လိုအသံုးဝင္သလဲ?
၁။ ဒီဇယားကြက္ ကို ၾကည္ ့ၿခင္းၿဖင္ ့ ပေရာဂ်က္မွာ ဘယ္သူေတြဟာၿဖင္ ့
အလုပ္တာဝန္ေတြ အရမ္းမ်ား ေနၿပီး ဘယ္သူေတြဟာေတာ ့အလုပ္တာဝန္ နဲနဲ ပဲ
ရွိေနတယ္ဆိုတာ အလြယ္တကူ သိႏိုင္ပါတယ္။
၂။ ပေရာဂ်က္မွာ ပါဝင္္သူအားလံုးဟာ ဘယ္သူက ဘယ္အလုပ္အတြက္ ဦးေဆာင္ရမလဲ ဆိုတာလည္း တေၿပးတည္း ရွင္းရွင္းလင္းလင္း သိႏိုင္ပါတယ္။
၃။ သိသင္ ့သိထုိက္တဲ ့လူေတြအားလံုး ကို ဆက္ဆံေရး ပတ္လမ္းထဲမွာ ထည္ ့ထားတဲ
့အတြက္ နားလည္မႉလြဲေစတဲ ့ ၿပႆနာေတြကိုလည္း ေလ်ာ ့ခ်ေပးပါတယ္။
၄။
ဒီဇယားကြက္ေလးကို အေၿခခံၿပီး ပေရာဂ်က္အတြင္း ဆက္ဆံေရးကို အလြယ္တကူ စီမံခန္
့ခြဲႏိုင္ပါတယ္။ ဘယ္သူေတြကေတာ ့အေၾကာင္းၾကားဖို ့ပဲလုိၿပီး၊ ဘယ္သူေတြကေတာ
့ေဆြးေႏြးတိုင္ပင္ဖို ့အစည္းအေဝးေတြမွာ ပါဝင္ဖို ့ လုိတယ္ စသၿဖင္ ့အဆင္
့ခဲြၿခားကာ မလုိလားအပ္တဲ ့အီးေမးလ္ အေရအတြက္ကိုလည္း ေလ်ာ ့ ခ်ႏိုင္ပါတယ္။
ဒီလုိလုပ္ၿခင္းၿဖင္ ့အားလံုးကို အခ်ိန္ကုန္သက္သာေစပါတယ္။
RACI ကို ဘယ္လိုပိုၿပီးေကာင္းေအာင္လုပ္မလဲ?
၁။ လုပ္ရမဲ ့လုပ္ငန္းတာဝန္ တစ္ခုစီမွာ တာဝန္ယူလုပ္ေဆာင္မဲ ့(R) နဲ ့
ဦးေဆာင္ေၿဖရွင္းမဲ ့(A) တာဝန္အတြက္ စုစုေပါင္း ႏွစ္ေယာက္ တာဝန္ေပးသင္
့ပါတယ္။ အကယ္၍ လုပ္ရမဲ ့အလုပ္ဟာ ရွင္းလင္းလြယ္ကူၿပီး အေရးၾကီးတာဝန္
မဟုတ္မွသာ (R) နဲ ့(A) ႏွစ္ေနရာစလံုးအတြက္ တစ္ေယာက္သာ တာဝန္ယူပါေစ။
၂။ ေနာက္တစ္ခ်က္ကေတာ ့တာဝန္တိုင္းမွာ ဦးေဆာင္ေၿဖရွင္းမဲ ့(A) ေနရာအတြက္
တစ္ဦးကိုတာဝန္သတ္မွတ္ေပးပါ။ လုပ္ေဆာင္ရန္တာဝန္ကို ခြဲေဝႏိုင္ေသာ္လည္း
ဦးေဆာင္ေၿဖရွင္းရန္တာဝန္ကိုေတာ ့သီးသန္ ့တစ္ေယာက္ကိုသာ တာဝန္ေပးပါ။
၃။ အကယ္၍ တစ္ခ်ိဳ ့တာဝန္မ်ားတြင္ အတိုင္ပင္ခံ (C) အမ်ားအၿပားပါေနက
တစ္ခ်ိဳ ့ကို သတင္းပို ့ရန္ လိုအပ္သူ (I) အဆင္ ့သို ့ေၿပာင္းသင္ ့ပါတယ္။
ဒါေပမယ္ ့(I) ေတြကို လည္း ပေရာဂ်က္အတြင္း မလိုအပ္တဲ ့ဆက္ဆံေရး အေႏွာက္အယွက္
အသံမ်ား နဲေစရန္ ၿဖစ္ႏုိင္သမွ် ကန္ ့သတ္ထားသင္ ့ ပါသည္။
အခုေလာက္ဆို ဒီ RACI ဇယားကြက္ဟာ ပေရာဂ်က္စီမံခန္ ့ခြဲမႉ
လုပ္ငန္းေဆာင္ရြက္မႉ ေတြမွာ အမ်ားၾကီးအေထာက္အကူ ၿဖစ္တယ္ဆိုတာ သိေလာက္ပါၿပီ။
ဒါေၾကာင္ ့မိမိတို ့ပေရာဂ်က္ေတြမွာ RACI ကို စတင္အသံုးၿပဳ ၿပီး
အလုပ္တာဝန္ေတြကို ၿမန္ၿမန္ဆန္ဆန္နဲ ့ေအာင္ၿမင္စြာ ၿပီးဆံုးေအာင္
ေဆာင္ရြက္ႏိုင္ၾကပါေစ။
ကုမၸဏီအမ်ားစုတို ့တြင္ ပေရာဂ်က္မန္ေနဂ်ာတို ့သည္ မိမိတာဝန္ယူ
လုပ္ကိုင္ေနေသာ ပေရာဂ်က္မ်ား၏ အေၿခအေနကို သက္ဆိုင္ရာ အေရးပါသူမ်ားထံ
ပေရာဂ်က္ အစီရင္ခံစာမ်ား (Project Reports) ၿဖင္ ့ အပတ္စဥ္၊ ၂ ပါတ္တစ္ခါ၊
လစဥ္ စသည္ၿဖင္ ့ မွတ္တမ္းတင္ကာ သတင္းပို ့ၾကရသည္။ ထိုသို ့Reports မ်ား
ၿပင္ဆင္ရၿခင္း သည္ လြယ္ကူေသာ အလုပ္တစ္ခု မဟုတ္ေပ။ ပေရာဂ်က္
အခ်က္အလက္စုစည္းရၿခင္း၊ ရရွိလာေသာ အခ်က္မ်ားကို သက္ဆိုင္ရာအေရးပါသူမ်ားထံ
မပို ့ခင္ မွန္မမွန္ စီစစ္ရၿခင္း၊ အေရးတၾကီး လုပ္စရာမ်ားအတြက္
ၾကိဳတင္စီစဥ္ရၿခင္း၊ စသည္ ့ၿဖင္ ့မ်ားစြာ အခ်ိန္ေပးရပါသည္။
ထုိမွ်မက
ပေရာဂ်က္ႏွင္ ့ပတ္သက္၍ သက္ဆိုင္ရာ အေရးပါသူမ်ား သိခ်င္ေသာ၊ သိသင္
့သိထိုက္ေသာ အခ်က္အလက္မ်ား၊ စနစ္တက်ပါဝင္မႉကိုလည္း အထူးဂရုၿပဳရပါသည္။
ပေရာဂ်က္မန္ေနဂ်ာမ်ား အေနၿဖင့္ ထိုကဲ ့သို ့ အေရးပါသည္ ့အခ်က္မ်ား
အားလံုးပါဝင္ၿပီး ၊ နည္းစနစ္တက်ၿဖင္ ့ ၿပီးစီးႏိုင္ေစရန္ ေအာက္ပါ
အစီရင္ခံစာ (Report) အမ်ိဴးအစားမ်ားကို အသံုးၿပဳရန္ အၾကံၿပဳ လိုပါသည္။
ပေရာဂ်က္ အေၿခအေနၿပ အစီရင္ခံစာ (Project Status Report)
ေပးထားတဲ ့နာမည္အတိုင္း ပေရာဂ်က္ရဲ ့အေၿခအေနကိုသိရွိရန္အတြက္
အသံုးၿပဳႏုိင္ပါတယ္။ အလယ္အလတ္အဆင္ ့အေသးစိတ္တင္ၿပခ်က္မ်ားပါဝင္ပါတယ္။
ဆိုလိုသည္မွာ ယခုလက္ရွိ ပေရာဂ်က္ရဲ ့ အေနအထားနဲ ့ပတ္သက္တဲ ့ေအာက္က
ေမးခြန္းမ်ိဴးေတြ အတြက္ ရွင္းလင္းတဲ ့တင္ၿပခ်က္ေတြ ပါသင္ ့ပါတယ္။
၁။ အခုလက္ရွိ ပေရာဂ်က္ရဲ ့၊ တိုးတက္မႉဟာ ၾကိဳတင္စီစဥ္ထားတဲ ့အတုိင္း လမ္းေၾကာင္းေပၚမွာပဲလား?
၂။ ေနာက္ထပ္ ဘယ္လို အစီအစဥ္ေတြ နဲ ့ဘယ္လုိလုပ္ေဆာင္ခ်က္ေတြ ၿပင္ဆင္ထားသလဲ?
၃။ ပေရာဂ်က္ ေအာင္ေအာင္ၿမင္ၿမင္ၿပီးဖို ့ဘယ္လို အခက္အခဲေတြ ရွိေနလဲ၊ သို ့မဟုတ္ ရွိလာႏုိင္သလဲ?
၄။ သတ္မွတ္ထားတဲ ့အခ်ိန္အလုိက္ တိုးတက္မႉ စံႏႉန္းစံထား ကိန္းဂဏန္းေတြအတိုင္း၊ ၿပီးစီးမႉ ရွိရဲ ့လား?
ၿဖစ္ေပၚၾကံဳေတြ ့လာႏိုင္ေသာ ပေရာဂ်က္ ၿပႆနာမ်ား စုစည္းမႉ မွတ္တမ္း (Project Risk Register)
ထိုမွတ္တမ္းသည္လည္း အလြန္ေရးပါေသာ အစီရင္ခံစာ တစ္မ်ိဴးၿဖစ္သည္။
ၿဖစ္ႏိုင္ေခ်ရွိေသာ အခက္အခဲ ၿပႆနာမ်ားသည္ ပေရာဂ်က္မ်ားကို ေနာက္ကြယ္မွေန၍
ေအာင္ၿမင္မႉလမ္းေၾကာင္းေပၚမွ တြန္းခ်ရန္ အၿမဲေစာင္ ့
ဆိုင္းေနေလ့ရွိသည္။ေဖာ္ၿပပါ မွတ္တမ္းသည္ ထိုအႏၱရာယ္မ်ား၏ ၿဖစ္ႏိုင္ေခ်ကို
မွတ္တမ္းတင္ထားၿခင္းၿဖစ္သည္။ ဒုကၡေပးႏိုင္သည္ ့ဆိုးက်ိဴးအဆင္ ့ေပၚမူတည္ၿပီး
အမ်ိဴးအစားခြဲၿခားကာ ၿဖစ္လာပါကေၿဖရွင္းရန္ နည္းလမ္းအေၿဖမ်ားကိုလည္း
စဥ္းစားမွတ္တမ္းတင္ထားၿခင္းၿဖစ္သည္။ ထုိမွတ္တမ္းကို အေၿခအေနၿပအစီရင္ခံစာ
(Status Report) တြင္ ေနာက္ဆက္ တြဲအေနၿဖင္ ့ အတူေဖာ္ၿပႏိုင္ပါသည္။
ဥပမာအားၿဖင္ ့ၾကံဳေတြ ့ႏိုင္ေသာ ၿပႆနာ အေရအတြက္ လက္ရွိအခ်ိန္တြင္
မည္မွ်ရွိသည္။ ဘယ္ႏွစ္ခု ရွင္းလင္းၿပီးၿပီ၊ ဘယ္ႏွစ္ခု ရွင္းလင္းရန္က်န္
စသၿဖင္ ့ အေရးပါသူမ်ား သိရွိ္ရန္ တင္ၿပႏိုင္ေပသည္။
လက္ရွိၾကံဳေတြ ့ေနရေသာ အခက္အခဲ စုစည္းမႉ မွတ္တမ္း (Issue Log)
ၾကိဳတင္ခန္ ့မွန္းထားတဲ့အတိုင္း တကယ္ၿဖစ္လာတဲ ့ၿပႆနာေတြ သို ့မဟုတ္
မေမွ်ာ္လင္ ့ ပဲ ၿဖစ္လာတဲ ့ၿပႆနာ အခက္အခဲေတြကို စုစည္းထားတာၿဖစ္ပါတယ္။
ဒီမွတ္တမ္းမွာ ၿပႆနာေတြရဲ ့ အေရးေပၚေၿဖရွင္းရန္ လိုအပ္မႉအေပၚ မူတည္ၿပီး
အဆင္ ့သတ္မွတ္ပါတယ္။ ၿပႆနာအဆင္ ့အလိုက္ လုပ္ငန္းေတြလံုးဝ ရပ္ဆိုင္းရမဲ
့အဆင္ ့မွစ၍ လိုအပ္ခ်က္ နဲနဲၿဖင္ ့ေၿဖရွင္းလို ့ရ ႏိုင္တဲ ့ အဆင္
့ထိအမ်ိဴးစံု ပါဝင္ပါတယ္။ ဒါ ့အၿပင္ ဘယ္အခ်ိန္မွာ ဘယ္ၿပႆနာကို အၿပီးသတ္
ေၿဖရွင္းရမယ္ စသည္ ့ စီစဥ္ ထားမႉေတြ ပါဝင္ပါတယ္။ ဒါေၾကာင္ ့ ဒီမွတ္တမ္းကို
ပေရာဂ်က္ အသင္းတစ္ခု လံုးရဲ ့ ဦးတည္ခ်က္ အၿဖစ္အသံုးၿပဳၿပီး ပေရာဂ်က္ကို
ဒုကၡတြင္းထဲမွ လမ္းေၾကာင္းေပၚၿပန္ေရာက္လာေအာင္ စြမ္းေဆာင္ႏိုင္ပါတယ္။
အလုပ္အမႉေဆာင္ အစီရင္ခံစာ အက်ဥ္းခ်ုဳပ္ (Executive Summary)
ဒီအစီရင္ခံစာကေတာ ့အထက္ကေၿပာခဲ ့တဲ ့ပာာေတြနဲ ့ နဲနဲကြဲၿပားပါတယ္။
အစီရင္ခံစာကို အရမ္းအလုပ္မ်ားၿပီး အခ်ိန္နဲနဲပဲရတဲ ့ ဒါရိုက္တာ အဆင္
့ထိပ္တန္း အေရးပါသူေတြ ဖတ္မွာၿဖစ္တဲ ့အတြက္ ေရးနည္းေရးဟန္
လိုတိုရွင္းၿဖစ္ဖို ့လုိၿပီး ပေရာဂ်က္ အေၿခအေနကို တိတိက်က် ၿခံဳငံုၿပီး
သံုးသပ္တင္ၿပႏိုင္ရပါမယ္။ အစီရင္ခံစာကို ဖတ္လိုက္တာနဲ ့ ပေရာဂ်က္ဟာ ကုမၸဏီက
ေမွ်ာ္လင္ ့ထားတဲ ့အတိုင္းၿဖစ္လာရဲ ့လား။ ပေရာဂ်က္ရဲ ့ တိုးတက္ေနမႉရလာဒ္
ပာာ ကုမၸဏီရဲ ့အနာဂါတ္ စီးပြားေရး မဟာဗ်ဴဟာကိုေရာ အေထာက္အပံ ့ၿဖစ္ရဲ
့လား၊ စတဲ ့ အခ်က္ေတြကို ထင္သာၿမင္သာရွိေစရပါမယ္။ တင္ၿပတဲ
့အခ်က္အလက္အားလံုးဟာ မွန္ကန္တိက်ၿပီး ဦးတည္ခ်က္ရွင္းလင္းရပါမယ္။
ထိပ္တန္းအရာရွိတို ့သည္ အေတြ ့အၾကံဳရွိသူမ်ားပီပီ ပေရာဂ်က္မ်ားသည္
အစီအစဥ္အတိုင္း ၿဖစ္မလာႏိုင္သည္ကုိ သေဘာေပါက္ၾကသည္။
ထို ့ေၾကာင္
့အၿဖစ္မွန္အတိုင္း ေဖာ္ၿပဖို ့လုိသည္။ သူတို ့ ပို၍ စိတ္ဝင္စားသည္မွာ
ထုိအခက္အခဲ အေနအထားမွ ေကာင္းမြန္သည္ ့အေနအထား သို ့ ၿပန္လည္ေရာက္ရွိေအာင္
မည္သို ့ အစီအစဥ္ရွိသည္ကိုသာၿဖစ္ပါသည္။
အခ်ုဳပ္အားၿဖင္ ့ဆိုလွ်င္
အထက္တြင္ ေဖာ္ၿပခဲ ့ေသာ အစီရင္ခံစာ မ်ားသည္ အေၿခခံအားၿဖင့္ ထိေရာက္မႉ
ရွိလွေပသည္။ မည္သည္ ့ အစီရင္ခံစာ သည္ ပေရာဂ်က္ အတြက္ သင္ ့ေတာ္သည္္ကိုေတာ ့
ပေရာဂ်က္မန္ေနဂ်ာမ်ား အေနၿဖင္ ့ မိမိ ပေရာဂ်က္၏ လိုအပ္မႉ၊ အေပၚမူတည္၍
ခ်င့္ ခ်ိန္ဆံုးၿဖတ္ရေပမည္။ အေရးအၾကီးဆံုး အေနၿဖင္ ့မိမိတို ့ တင္ၿပေသာ
ပေရာဂ်က္ အစီရင္ခံစာမ်ား သည္ ၿပင္ဆင္ရန္ လြယ္ကူၿပီး အခ်ိန္တိုတိုၿဖင္ ့
ၿပီးစီးႏိုင္ရေပမည္။ သို ့မွသာ ပေရာဂ်က္ မန္ေနဂ်ာမ်ားသည္ မလိုလားအပ္ဘဲ
အခ်ိန္ကုန္ၿခင္းမ်ားကိုေလ်ာ ့ခ်ႏိုင္မည္ၿဖစ္ေပသည္။
ပေရာဂ်က္မန္ေနဂ်ာမ်ားသည္ မိမိတာဝန္ယူလုပ္ေဆာင္ေနေသာ ပေရာဂ်က္မ်ား၏
အခ်ိန္ဇယားမ်ားကို အပတ္စဥ္တိုင္း ၿပန္လည္သံုးသပ္သင့္ေပသည္။ သို ့မွသာ
ပေရာဂ်က္သည္ သတ္မွတ္ထားသည္ ့အတိုင္း တိုးတက္မႉ ရွိသည္ မရွိသည္ကို
ရွင္းရွင္းလင္းလင္း သိရွိႏိုင္လိမ္ ့မည္။ အကယ္၍ ပေရာဂ်က္သည္ ေနာက္က်ေနပါက
ၿပန္လည္၍ အခိ်န္မွီၿပီးစီးလာေစရန္ လုပ္ေဆာင္ႏိုင္မည္ ့စီမံခန္ ့ခဲြမႉ
လုပ္ထုံးလုပ္နည္း အခ်ိဳ ့ကို အသံုးခ်ရလိမ္ ့မည္။
ဥပမာအားၿဖင္ ့၊
ပေရာဂ်က္ တစ္ခုသည္ ေတာ္ေတာ္ဆိုးဆိုးရြားရြား ေနာက္က်လာသည္ဟု
စဥ္းစားၾကည့္္ရေအာင္။ ပေရာဂ်က္ကိုၿပန္လည္ အခ်ိန္မွီလာေအာင္လုပ္ႏိုင္မည့္
ရိုးရွင္းလြယ္ကူေသာ အေၿခခံ အခ်ိန္ဇယားလုပ္ထံုးလုပ္နည္းမ်ား (Simple
Scheduling Techniques) လည္း အသံုးခ်၍ မၿဖစ္ႏိုင္္။ ဒါ ့အၿပင္
ပေရာဂ်က္ၿပီးစီးရမည္ ့ အခိ်န္(Project Deadline) သည္ေၿပာင္းလဲခြင္ ့ မရွိသည္
့အေၿခအေနဟုလည္း ယူဆၾကည့္ရေအာင္။
ထုိအေၿခအေနတြင္ ေနာက္ဆံုးပိတ္အေနၿဖင္
့အသံုးခ်သင္ ့ေသာ နည္းစနစ္ ၂ မ်ိဴးရွိပါသည္။ ၄င္းတို ့ကို
လုပ္ငန္းတာဝန္အလုပ္မ်ားကို ယွဥ္တြဲလုပ္ေဆာင္ၿခင္း (Fast Tracking) ႏွင့္
လူအင္အားၿဖည္ ့တင္းေဆာင္ရြက္ၿခင္း (Crashing) ဟုေခၚတြင္ၾကပါသည္။
(ေအာက္တြင္ဆက္လက္ေဆြးေႏြးသည္ ့အခါ လြယ္ကူေစရန္မူရင္း English
စကားလုံးမ်ားကိုသာ အသံုးၿပဳၾကရေအာင္။)
Fast Tracking တြင္
လုပ္ငန္းတာဝန္အလုပ္မ်ားကို ယခင္က လုပ္ရုိးလုပ္စဥ္ အတိုင္း
တစ္ခုၿပီးမွတစ္ခု လုပ္ရန္ အစီအစဥ္မွ ယွဥ္တြဲလုပ္ကိုင္ရန္ အေနအထားသို
့ေၿပာင္းလဲလုပ္ေဆာင္ၿခင္းၿဖစ္သည္။ ဥပမာတစ္ခုၿဖင္ ့သံုးသပ္ၾကည္ ့ ရေအာင္။
ေဆာက္လုပ္ေရး ပေရာဂ်က္တစ္ခုတြင္ လုပ္ရိုးလုပ္စဥ္ အားၿဖင္ ့
ေဆာက္လုပ္မႉစတင္ၿခင္း (Construction Commecement) သည္ ဒီဇုိင္းတြက္ခ်က္မႉ
(Design Calculation) ၿပီးစီးမွသာ စတင္ေလ ့ရွိေသာ္လည္း၊ Fast Tracking
နည္းစနစ္တြင္ ဒီဇိုင္းတြက္ခ်က္မႉ အလံုးစံု ၁၀၀% ၿပီးစီးသည္အထိ မေစာင္ ့ဘဲ
ဒီဇိုင္းတြက္ခ်က္မႉ ၈၀% ၿပီးစီးရုံမွ်ၿဖင္ ့ ေဆာက္လုပ္မႉ
ကုိစတင္ၿခင္းၿဖစ္သည္။ ထုိကဲ ့သို ့ေသာ ယွဥ္တြဲလုပ္ေဆာင္ၿခင္း သေဘာသဘာဝ မ်ား
ပါဝင္မႉေၾကာင္ ့ Fast Tracking သည္ အရဲစြန္ ့ရမႉ (Risk) မ်ားၿဖင္ ့ေတြ
့ၾကံဳရႏိုင္ၿပီး လုပ္ၿပီးသားအလုပ္မ်ားကို ၿပန္လည္လုပ္ေဆာင္ရၿခင္း (Rework)
အေၿခအေနမ်ားလည္း ၿဖစ္ေပၚလာႏိုင္သည္။ ဆိုလိုသည္မွာ အထက္ေဖာ္ၿပပါဒီဇိုင္းႏွင္ ့ေဆာက္လုပ္ၿခင္းယွဥ္တြဲလုပ္ေဆာင္ ေနစဥ္အတြင္း ေနာက္ဆံုးအဆင္
့ဒီဇိုင္းေၿပာင္းလဲမႉ အခ်ိဳ ့ၿဖစ္လာပါက ေဆာက္လုပ္ၿပီးသားအခ်ိဳ ့
အလုပ္မ်ားကို ၿပန္ၿပင္ရႏိုင္ေပသည္။
ေလ့လာမႉမ်ားအရ ပေရာဂ်က္
အခ်ိန္ဇယားတစ္ခုတြင္ တစ္ခုၿပီးမွတစ္ခုလုပ္ရန္ လုပ္ငန္းတာဝန္မ်ား
(Sequential Activities) ကို ၊ ယွဥ္တြဲလုပ္ေဆာင္ႏိုင္ေသာ လုပ္ငန္းတာဝန္မ်ား
(Fast Tracked Activities) အၿဖစ္ ၃၃% အထိေၿပာင္းလဲ
လုပ္ကိုင္ႏိုင္္ၾကပါသည္။ တစ္နည္းအားၿဖင္ ့ ဆုိရေသာ္ ပထမအလုပ္တာဝန္ (First
Activity) သည္ ၆၆% ၿပီးစီးပါက ဒုတိယအလုပ္တာဝန္ (Second Activity)
ကိုစတင္ၿခင္းမ်ိဴး ၿဖင္ ့ ပေရာဂ်က္ လုပ္ငန္းမ်ားလုပ္ေဆာင္ရန္ ၾကာခ်ိန္ကို
ေလွ်ာ့ခ်၍ စီစဥ္လုပ္ေဆာင္ႏိုင္ပါသည္။ အ႐ဲစြန္ ့ ရမႉအႏၱရာယ္ ရွိေသာ္လည္း
ဆိုးရြားေသာ ပေရာဂ်က္ က်ဆံုးမႉ အေၿခအေနမ်ိဴးေလာက္ မရွိႏုိင္သၿဖင္ ့
အမ်ားအားၿဖင္ ့ပေရာဂ်က္စီမံခန္ ့ ခြဲမႉ နယ္ပယ္တြင္ Fast Tracking
နည္းစနစ္ကို က်ယ္ၿပန္ ့စြာ အသံုးၿပဳၾကပါသည္။
Crashing နည္းစနစ္သည္
ပေရာဂ်က္၏ အေရးၾကီးၿပီး၊ မၿဖစ္မေနၿပီးရမည္ ့အလုပ္တာဝန္မ်ား (Critical
activities) ကိုလုပ္ေဆာင္ရန္အတြက္ လူအင္အားထပ္တိုးထည္ ့ကာ
လုပ္ေဆာင္ၿခင္းၿဖစ္သည္။ သို ့ေသာ္ လူအင္အားထပ္ထည္ ့ လိုက္တိုင္း
လုပ္ငန္းၿပီးေၿမာက္ႏိုင္စြမ္း တိုးလာသည္ေတာ ့ မဟုတ္ေပ။ဥမမာအားၿဖင္
့လုပ္သားတစ္ေယာက္သည္ ၁၀ ရက္ၾကာလုုပ္ရမည္ ့ မၿဖစ္မေနၿပီးရမည္ ့
အလုပ္တာဝန္တစ္ခုကို လုပ္ေဆာင္ေနသည္ဆိုပါစို ့။ ကုမၸဏီမွ ထိုအလုပ္တာဝန္ကို ၅
ရက္အတြင္းၿပီးေစခ်င္သၿဖင္ ့ေနာက္ထပ္ လုပ္သားတစ္ေယာက္ကို ထပ္ထည္ ့လိုက္သည္။
သို ့ ေသာ္ ထပ္ထည္ ့လုိက္ေသာ လုပ္သားသည္ ရွိသင္ ့ေသာ
ကြ်မ္းက်င္မႉမရွိသၿဖင္ ့တကယ္တမ္း ၅ရက္ၿပည္ ့ေသာအခါ ထိုအလုပ္တာဝန္သည္
မၿပီးဘဲ ၈ ရက္ေၿမာက္မွသာၿပီး သည္ ဆိုပါစို ့။ ထိုအေၿခအေနတြင္ ရရွိလာေသာ
အက်ိဴးေက်းဇူးသည္ ၂ ရက္ေစာ၍ၿပီးၿခင္းသာၿဖစ္သည္။ ထိုကဲ ့သို ့ေသာရလာဒ္ သည္
လက္ေတြ ့တြင္ ပေရာဂ်က္အတြက္ သိသိသာသာ အက်ိဴးမ်ားၿခင္းေတာ ့မဟုတ္ေပ။
ထို
့ေၾကာင္ ့Crashing လုပ္မည္ဆိုလွ်င္ လူအင္အား ထပ္ထည္ ့၍ ေအာင္ၿမင္ ၿပီးစီး
ႏိုင္မည္ ့လုပ္ငန္းတာဝန္ပမာဏ ႏွင္ ့ေနာက္တိုးလူအင္အားအတြက္ ကုန္က်စရိတ္တို
့ကို စနစ္တက် ခ်င္ ့ခ်ိန္သင္ ့ ေပသည္။ အမ်ားအားၿဖင္ ့ပေရာဂ်က္၏
မၿဖစ္မေနၿပီးေၿမာက္ရမည္ ့ အလုပ္တာဝန္မ်ား (Critical Activities) အား
သတ္မွတ္ ခ်ိန္ထက္ေစာ၍ ၿပီးေစရန္ ေငြေၾကးထပ္မံ ၿဖည္ ့တင္းေဆာင္ ရြက္ႏိုင္ပါက
Crashing နည္းစနစ္သည္ သင္ ့ ေတာ္ေသာ နည္းလမ္းတစ္ခုပင္ ၿဖစ္ပါသည္။
