Ocean PMP BLOG

未來的事無法預知, 所以我們必須先要將某些變數先給予假設(assumption)將其固定下來, 才能基於這些假設開始進行計畫, 例如某產品的銷售量, 原料價格, 匯率, 產量, 辦活動要預估來客數, 氣候, 其他如預估時間,運費成本, 需求, 可靠度, 行為模式(pattern), 競爭者狀況, 法規變動,  etc.

Just completed a round of in-house project management training last week. In the course of trainnig I encouraged trainees to see things from the aspect of Project base. In other words, keep in mind PDCA cycle. Plan, Do, Check, Action. It's very easy to realize and memorize. You got used to adapt WBS and network diagram rather than To-Do list. Major task is often involved with stakeholders who you have to deal with and to find out their requirement then plan in. Anything happen against baselines(scope/time/cost/quality)what you feel is "problem" or treat it as a "change request".

其實賣方規劃單位在開規格時常會考慮未來年幾年的需求，而這些需求有的已有標準，有的還在構想階段，為了能夠在未來競爭環境中能夠繼續生存下來，所以就把一些先進地需求規格列入RFP中(request for proposal)，事實上買賣雙方都知道不一定在結案前能夠將功能做出來(有些標準都還在制定中怎麼會有產品)，這時專案要執行最後階段範疇驗證時就會出問題，但是總不能因為幾個功能就讓整個專案持續延遲下去，下列是各項可能解決方案，這些由賣方提出的 change request都需要走 Integration change control process，先厘清變更的範疇(clarification)、變更的原因(root cause)、對專案範疇、時程、成本、品質、風險的影響(evaluation)，經評估後可能有下列選項可執行，不要讓專案持續的延持無法結案(lose,lose):

Preliminary Project Scope Statement初步專案範疇聲明這在上一版沒有，有可能在下一版會消失，所以大致上能夠了解即可，通常來說專案team本身是專家或者說賣方是專家，相對的Management或買方(customers)描述的，都是以他們熟悉的語言簡要的來描述他們的需求(requirements, needs, wants)、關切，這些需求、關切包括產品描述、專案目標、風險提醒、會議頻率、報告格式、是否要 prototype….這些描述就是專案經理與客戶之間對於專案共同的理解(客戶的語言)，稱之為Preliminary Project Scope Statement初步專案範疇聲明, 專案經理事後要透過 Core team在 Scope definition 這個流程裡，將這初步專案範疇聲明經由產品分析(Product Analysis)及尋找不同方案(Identify Alternatives)轉成專業的描述, 來達到初步專案範疇聲明裡的範疇，讓Project team, vendors, supplierss能夠明確瞭解, 我們稱為 Scope statement.

很多人在現實職場中的經驗是老板把我叫去，就assign這個project 給我，要我開始follow up，也沒在開會時當眾宣佈讓大家知道，俗話說: 名不正則言不順，言不順則事不成，所以沒人理我，官小還要到處阿伯阿母(伯父伯母)拜託，這樣專案怎麼能順利，明明是公司的事，確需要用自己的Credit請人幫忙，這樣PM能撐多久。