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

Project planning

အထက်ပါပုံတွင် ပြထားသော pseudo-codeသည် software development အတွက် ရည်ရွယ်သော project planning process တစ်ခုဖြစ်ပါသည်။ ၎င်းpseudo-code အရ planningဆိုသည်မှာ ထပ်တလဲလဲလုပ်ဆောင်ရသော process(iterative process)တစ်ခုဖြစ်ပြီး project ပြီးမြောက်သည့်အချိန်မှသာ ပြီးစီးသော process ဖြစ်ပါသည်။ Projectလုပ်ဆောင်နေချိန်အတွင်း project informationများ ရရှိလာသည့် အလျောက် စီစဉ်ထားသော planကိုလည်း ပုံမှန် စီစစ်ပေးရပါမည်။ အထူးသဖြင့် စီးပွားရေးဆိုင်ရာ ရည်မှန်းထားသော ပန်းတိုင်များသည် အရေးကြီးသောအပိုင်းဖြစ်ပြီး project plan ဖန်တီးသည့်အခါ မဖြစ်မနေ သုံးသပ်ဆင်ခြေသင့်သော အရာတစ်ခု ဖြစ်ပါသည်။ ပြောင်းလဲမှုများဖြစ်ပေါ်လာတတ်သည့်အတိုင်း project၏ ရည်မှန်းချက် ပန်းတိုင်သည်လည်း ပြောင်းလဲလာပါသည်။ ထိုအခါ project planလည်း ပြောင်းလဲမှုများ လိုအပ်လာပါတော့သည်။

Pseudo-code အရ planning process ၏အစပိုင်းတွင် ကျွန်တော်တို့သည် project အပေါ်သက်ရောက်မှုရှိသည့် ကန့်သတ်ချက်(constraint)များ ဖြစ်သော (required delivery date, staff available, overall budget, etc) များကို ချင့်ချိန် တွက်ချက်ရပါမည်။ တစ်ဆက်တည်းမှာဘဲ project၏ ဖွဲ့စည်းမှု (structure)၊ အရွယ်အစား(size)နှင့် ဖြန့်ဖြူးရောင်းချ မည့် (distribution) functionများ ကဲ့သို့ project၏ သတ်မှတ်ချက်ဘောင် များ (parameters)ကို ခန့်မှန်းသင့်ပါသည်။ နောက် တစ်ဆင့်တွင် အခြေအနေ တိုးတက်မှု milestone များနှင့် deliverableများကို သတ်မှတ်ပေးရပါမည်။ အထက်ပါ လုပ်ဆောင်ချက် များပြီးမြောက်လျှင် processသည် loopပတ်ခြင်းကို စတင်လုပ်ဆောင်ပါသည်။

Project Planning (repeat)

Loopအစတွင် projectအတွက် လုပ်ငန်းစဉ်အချိန်ဇယားကို ခန့်မှန်းရေးဆွဲ ရပါမည်။ ထို့နောက် scheduleတွင် စတင်လုပ်ဆောင်မည့် activityများနှင့် ခွင့်ပြု ချက်ပေးမှ ဆက်လက်လုပ်ဆောင်နိုင်မည့် activity များကို ခန့်မှန်းပေး ရပါမည်။ Project လုပ်ဆောင်မှုကာလ ကြာလာသည် နှင့်အမျှ ကျွန်တော်တို့သည် project၏ တိုးတက်မှု အခြေအနေများကို ဆန်းစစ် (review)ရမည်ဖြစ်ပြီး မူလက စီစဉ် သတ်မှတ် ထားသော scheduleနှင့် ကွဲပြားနေသည်များကို ဂရုစိုက်သင့်ပါသည်။ ဆိုလိုသည်မှာ project လုပ်ဆောင်မှုများ ပြုလုပ်လာသည်နှင့်အမျှ မိမိ ခန့်မှန်းထားသော planအတိုင်း ဖြစ်ချင်မှဖြစ်လာပါမည်။ Planning processအစတွင် ကျွန်တော်တို့ခန့်မှန်းထားသော project parameterများသည် အစမ်းသဘောများသာ ဖြစ်သည့်အတွက် အမှန်တကယ် ပြုလုပ်သည့်အခါ ကျွန်တော်တို့ ခန့်မှန်းထားသည့် planကို ပြင်ဆင် ဖြည့်စွက် ကာ projectလုပ်ဆောင်ရပါသည်။

Project လုပ်ဆောင်လာသည်နှင့်အမျှ မိမိ projectအကြောင်းကိုသိလာပါသည်။ ထိုအခါ ကျွန်တော်တို့အနေဖြင့် projectတွင် မိမိတာဝန်ယူထားသော အပိုင်းနှင့် project scheduleကို စီစစ်ရပါမည်။ အကယ်၍ projectသည် ကြန့်ကြာ(delay)နေပါက project constraintများနှင့် deliverableများကို customerနှင့် ပြန်လည် စေ့စပ်ညှိနှိုင်း (renegotiation) နိုင် ပါသည်။ ပြန်လည်စေ့စပ်ညှိနှိုင်းမှု အဆင်မပြေဖြစ်ပြီး ရေးဆွဲ ထား သည့် scheduleနှင့် မကိုက်ညီမှုများ ဖြစ်လာပါက project၏ လုပ်ထုံးလုပ်နည်းကို ဆန်းစစ်ရပါတော့မည်။ ထိုကဲ့သို့ ပြန်လည်ဆန်းစစ်ရခြင်းမှာ သတ်မှတ်ထားသော project constraintများနှင့် scheduleအတွင်း အဆင်ပြေသော အခြား နည်းလမ်း တစ်ခုကို ရှာဖွေရန် ဖြစ်ပါသည်။

Project အတွင်း လုပ်ဆောင်မှုများ အားလုံးသည် ကောင်းကောင်းမွန်မွန် ဖြစ်လာ လိမ့်မည်ဟု မယူဆသင့်ပါ။ မိမိ တာဝန်ယူမှု အပိုင်းနှင့် အချိန်ဇယား scheduleကို လိုလိုပိုပိုထင်မြင်ထားသည်ထက် လျော့တွက်ထားသင့်ပါသည်။ ထို့အပြင် ဖြစ်ပေါ်လာ နိုင်သော အရေးပေါ်အခြေအနေများကိုလည်း planထဲတွင် ထည့်ဆွဲထားသင့်ပါသည်။ ထို့ကဲ့သို့ ဖြစ်ပေါ်လာမည့် အခြေအနေများကို ရေးဆွဲထားခြင်း ဖြင့် project constraints များနှင့် milestoneများကို ထပ်မံပြောင်းလဲ ရခြင်းမှ ရှောင်ရှား နိုင်ပါသည်။

5.2.1 The project plan

Project planတစ်ခုသည် projectအတွက် အသုံးဝင်ရယူနိုင်သော အရင်း အမြစ် (resources)များ၊ work breakdown နှင့် အလုပ်များ ဆောင်ရွက်ရန် schedule တို့ကို အစပျိုးစီစဉ်ပေးပါသည်။ အဖွဲ့အစည်းအချို့အတွက် project planဆိုသည်မှာ မတူညီ သော plan အမျိုးအစားများပါဝင်သော စာရွက်စာတမ်းတစ်ခုဖြစ်ပါသည်။ မတူညီသော planအမျိုးအစား (Types of plan) များကို အရင်topicတစ်ခုတွင် ဖော်ပြခဲ့ပြီး ဖြစ်ပါသည်။ အချို့ကိစ္စရပ်များတွင်မူ project planသည် development process ကိုသာ ဂရုပြု လုပ်ဆောင်ပါသည်။

ယခုဖော်ပြသွားမည့် plan structure သည် နောက်ပိုင်းအသုံးပြုရေးဆွဲလာသည့် planအမျိုးအစားများ အတွက်ဖြစ်ပါသည်။ Project planတစ်ခု၏ အသေးစိတ် အချက် အလက်များသည် project အမျိုးအစားနှင့် အဖွဲ့အစည်း ပေါ်တွင် ကွဲပြားပါသည်။ မည်သို့ပင်ဖြစ်စေကာမူ plan အများစုတွင် အောက်ပါ sectionများပါဝင်ပါသည်။

1. Introduction: project objectiveများကို ဖော်ပြခြင်း နှင့် project managementကို အကျိုးသက်ရောက်သည့် ကန့်သတ်ချက် constraint (budget, time, etc.) များကို အစပျိုးစီစဉ် သည့်အပိုင်း ဖြစ်သည်။

2. Project organization: development teamကို စနစ်တကျ ဖွဲ့စည်းသည့် နည်းလမ်း၊ ပါဝင်သည့် လူများ နှင့် တာဝန် ကဏ္ဍများကို ဖော်ပြသည့် အပိုင်း ဖြစ်သည်။

3. Risk analysis: ဖြစ်လာနိုင်သည့် project riskများ၊ ဖြစ်နိုင်ချေရှိသော risk တိုးပွားမှုများနှင့် ရည်ရွယ်ကြံဆထားသော risk လျော့ချမှု ဗျူဟာ (risk reduction strategies) များ ကို ဖော်ပြသည့် အပိုင်းဖြစ်ပါသည်။

4. Hardware and software resource requirements: development လုပ်ဆောင်ရန် လိုအပ်သော hardware နှင့် support softwareများကို သတ်မှတ်သည့် အပိုင်းဖြစ်ပါသည်။ အကယ်၍ hardware ပိုင်းဆိုင်ရာ ပစ္စည်းများ ဝယ်ယူရလျှင် ခန့်မှန်းချေ ဈေးနှုန်းနှင့် ရရှိနိုင်မည့် အချိန်ကိုပါ ထည်သွင်း ဖော်ပြနိုင်ပါသည်။

5. Work breakdown: project မှ activityများသို့ ခွဲခြမ်းစိတ်ဖြာမှုကို ဆောင်ရွက် ခြင်း၊ ယင်း activityများနှင့် ဆက်စပ်နေသော milestone နှင့် deliverableများ ကို ခွဲခြားခြင်း တို့ ဆောင်ရွက်သည့် အပိုင်းဖြစ်ပါသည်။

6. Project schedule: activityများကြားတွင်ရှိသော မှီခိုမှု(dependency)များ၊ milestone များ အောင်မြင်ရန် လိုအပ်သည့် အချိန် ခန့်မှန်းမှုများ နှင့် activityများတွင် လူများကို ခွဲဝေနေရာချခြင်း များကို ပြသော အပိုင်းဖြစ်ပါသည်။

7. Monitoring and reporting mechanisms: ဖော်ပြသင့်သည့် management အစီရင်ခံစာများ၊ မည်သည့်အချိန်တွင် ယင်းအစီရင်ခံစာများကို ဖော်ပြသင့်သည်၊ မည်သည့်အချိန်တွင် project စစ်ဆေးရေး လုပ်ထုံး (project monitoring mechanism) များကို အသုံးပြုသင့်သည် များကို ဖော်ပြသည့် အပိုင်းဖြစ်ပါသည်။

ကျွန်တော်တို့အနေဖြင့် project လုပ်ဆောင်နေစဉ်အတွင်း project planကို ပုံမှန် စီစစ်သင့်ပါသည်။ Project schedule ကဲ့သို့ အချို့အပိုင်းများသည် မကြာခဏ ပြောင်းလဲ နေတတ်ပြီး အခြားသော အပိုင်းများသည် တည်ငြိမ်သော အခြေအနေတွင် ရှိတတ်ကြ ပါသည်။ ပြန်လည်စီစစ်မှုများကို အလွယ်တကူ ပြုလုပ်နိုင်ရန် ကျွန်တော်တို့ သည် စာရွက်စာတမ်းများကို သီးခြားအပိုင်းများဖြင့် ဖွဲ့စည်းထားသင့် ပါသည်။ ဒါမှ planများ ပြောင်းလဲလာသည့်အခါ ရှင်းရှင်းလင်းလင်း တစ်ခုချင်းစီ ပြင်ဆင်အစားထိုး နိုင်မည် ဖြစ်ပါသည်။