Ocean PMP BLOG

For Example, you're handling a big outdoor activity. Customer only tell you assume how many viewers will come in. this is requirement. But these viewers will generate how much traffic you need to manage, how many parking lot you need to prepare, it depends on many aspects like location, age of viewers.... that is your scope of work. how to turn requirements into scope of work that backend supprt familiar with project needs someone playing this role. Thererfore we need someone to dig out customer requirement, mapping to product and turn into scope of work.

customer, scope, project, requirement

I think the most critical thing to project success is to dig out customer expectation. Customer needs and wants which are often related to product or service is easy to find out.  Customer is hard to tell you clearly what they want. Just like McDonald clerk often double check what you want. 

http://www.facebook.com/home.php?sk=group_28543375847&ap=1#!/home.php?sk=group_102252159866745&ap=1

價值工程簡單的說就是要找出能用最少的成本創造最高價值的方案

Games people play,

成本與品質與時間與範疇總是在不斷的拉扯到底那個重要，一般來說Matrix組織垂直式分工，各部門各司其職，規劃部門與產品部門當然以成本為第一考量，他們的KPI往往是 cost down多少， profit 增加多少，品質時間是其他部門的事，製造維修單位總是高舉品質大旗，quality is plan in要求規劃部門優質設計，多編列預算買好的設備，最好是全自動零故障，若日後運作有問題那是規劃部門問題，業務部門不管你用甚麼設備多少錢品質如何只要時間與範疇能做到可以驗收請款就好，那個部門可以全面的來看那就是PM, PM通常比較客觀站在比較接近公司整體利益來看(當然要看那一層的PM)

用風險分數來做決策(Decision Making)

剛過完中秋辦公室桌上多少擺著一兩顆還不知道什麼時候才要吃的柚子, 隨著日子一天一天過, 柚子漸漸的由綠變黃再變成紅, 就像專案風險管控一般, 如果不做 專案風險燈號就一樣會由綠燈變黃燈再變成紅燈

嘿！想想我們上班走的路徑已經多久沒有變動了，那天順道載了同事下班談起來才驚覺我花了許多冤枉時間，原來還有其他的捷徑或是可走新的快速道路，想想我們上班的工作流程已經多久沒調整了，習慣成自然有時就是需要一個外面的人來提醒我們，流程改善指的是一點一滴的調整，是不要花費大量資本支出(CAPEX)的才對，有人說花一筆錢買新設備品質不就可以馬上改善，我說那叫投資不是流程改善，大量資本支出會造成成本上昇，這與我們做流程改善來降低成本的目的剛好背道而馳。

今天同事談到他小孩參加夏令營回來，說活動的名稱是”互助合作”，不是”分工合作”，我們來比較一下這兩者間有何不同，談互助合作我們想到比較接近的是”團隊合作”，看看棒球比賽一壘有跑者，打擊者擊出滾地球，二壘手出來接，游擊手會過來二壘補位好封殺跑向二壘的跑者，這個大家都同意也認為是理所當然，可是把場景拉回我們目前的工作環境，如果你是那個二壘手你認為游擊手會過來補位嗎? 游擊手會告訴你我的JD(job description)裡面沒有我當二壘手的要求，最後還是要你自己跑回二壘不是嗎?

上星期日David打來說Rita過逝, 我想對於絕大部份的 PMP在考試前一定都看過她這本參考書, 前年見她時其實本人已經比書本上照片清瘦許多, 如果沒特別介紹是認不出來的, 不過接待我們那晚她精神是非常好, 思緒非常清楚也很健談, 她說她每天在湖邊打太極養身(住家在明尼蘇打拿玻里市一處湖邊), 想說應該是在康復中沒再問病情, David說在過逝前幾天她還在錄製課程, 可見她對於project management 非常有熱情, 昨晚把她送的Risk Management這本書拿出看, 第一頁還有她的簽名, 睹物思人, 在我研習專案管理這門課題時, 在我讀這本書不禁贊歎作者清楚邏輯時, 也同時知道作者的部份故事會更有感觸~

我們在做大量建制(roll out)時，如同部隊作戰打的是補給(logistics)，即是預算是否編列，物料合約是否簽定，採購單(PR/PO)是否已發出，然後是物料是否到位，有了穩定的補給線，大軍才能無後顧之憂的照計畫攻城掠地。

 Ask yourself can you figure out what's differences between these 3 terms.

絕大多數上課學員都沒想過管理者把公司組織架構設定成何種模式會深深影響專案經理的表現或者說專案的成功與否:

 When we run project, especially in execution stage there is always Eng raises their hand saying oh, I can not accept this feature due to …what if …….

專案開始之初在Planning 階段之前我們先要做Stakeholder analysis，目的是要瞭解會影響專案成敗的有那些人，這些人當中除了負責專案實際執行的專案人員外，主要的Sponsor(ex: 各部門主管)針對這個專案它們的看法是甚麼，講白一點他們的需求是甚麼，如果沒有先談好加以收斂，注意這些需求是會不斷的出現變成Activity加入Scope裡，憑專案有限的時間、資源是沒有辦法滿足這些重量級Sponsor的需求，缺了先做 balance stakeholder needs 就進入planning階段就會漏掉這些non-business needs，日後就會有人不斷舉手告訴專案經理，他們老闆要求還要加入一些activity，專案是要拒絕還是接受(專案有專案的kpi 時間成本…,各部門有各部門的kpi),  balance stakeholder needs講白一點就是在滿足專案這個goal的前提之下，大家共體時艱來完成專案，balance stakeholder needs就是要大家先各退一步，以此為基準線來作為專案的Scope，不然Scope creeping或 change request 會不斷的出現。

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

Check it up~,http://www.powerpointist.com/servlet/StoreFront

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):

用一題PMP考題來舉例:

專案結不了案:

Are you smiling as you see this equation.

How to define success  of a project ? or what is Project KPI? or what is project purpose? Actually, these 3 questions are pointing to same thing which is “what is project deliverable?”.

大家都知道古埃及建造了許多的金字塔，可是其中保存最完善的是胡夫王金字塔，為什麼至今仍保存的非常完善?是因為當時建造這個金字塔的不是一般的奴工而是胡夫王的子民，他們要榮耀他們的君王，以讓後世永遠知道他的偉大貢獻及成就，因為這樣當時的設計施工都加入要榮耀他們君王的心，這些參與建造者不會說我祇是來切割大石頭、我是來運送石塊，他們會說我們是來建立一座可以揚名萬世不朽的金字塔，這是Vision所產生有著美好遠景的共同認知所帶來的結果。同樣的我聽到的另一個偉大Vision在現代發生的故事與大家分享，它就呈現在我們眼前:

Hertzberg’s Motivation Theory

同樣地賣方寫的建議書買方不見得完全瞭解，單憑書面資料也未必能證明賣方的能力，所以買方在收到建議書後就會請各賣方前來說明(Presentation)。召開說明會後，買方即可運用先前制定的評選標準評定賣方建議書，最後選擇一個或多個合格的賣方(Short list)開始進行磋商(Negotiation)，磋商的範圍包括建議書中技術(Specification)、商業(Price)、合約條件(Contract Term&Condition) 及專案管理部分。最後專案團隊及採購部門會將磋商的結論呈報管理階層召開經營會議(Executive Committee)做最後決定，將該合約給那一家賣方(Contract Award)，最後完成簽約。

通常在英文合約條約裡是用 Clause #：Security Deposits (擔保保證金)來表示，賣方得標後一定期間內需質押總價款一定比例的金額給甲方，做為履行合約(交付產品或服務)的保證金，這對買方是一種保障，也是賣方對甲方的承諾(Commitment)，賣方可以以定存單設定質押、銀行開立之保證金保證書(買方需注意有效期限，到期專案如尚未結束，需要求賣方重新開立展延)或其他型式來作為履約保證金，合約執行期完成如無爭議甲方需解除設定抵押退還乙方，屆時乙方即可以動用開筆資金。

當買方寄出RFP給賣方後接下來該做什麼，等賣方的建議書(Proposal)嗎？這樣來看你(買方)認為你寫的採購文件(RFP)裡面的需求、專案範疇、合約條款、特訂條款、投標需知、答標方式、及各種附件，這些收到RFP的潛在賣方都充分瞭解嗎？如果答案是否定的，就會影響賣方的投標意願、解決方案及價格，為了要縮小買賣雙方對於專案範疇內容的認知差距，所以買方都會發起一個會議邀請賣方到場針對RFP不清楚部分發問，這個會議叫做投標商會議(Bidder conference)，即是讓潛在賣方準備建議書前的會議，會議進行時買方應公平的讓賣方逐一提問及回覆(不一定當場回覆)，最後回覆澄清的內容需作為採購文件(RFP)的修改文件

在完成了外購的範疇(Statement of work), 我們也選擇了最適合的合約類型後, 接下來就是準備要讓潛在的供應商(系統整合商)提出解決方案(Proposal)來滿足你專案外購的需求, 因為我們要Proposal所以我們要提出一個RFP(Request For Proposal)告訴潛在的供應商(系統整合商)提出解決方案(Proposal), 所以在RFP裡除了外購的範疇(Statement of work)外我們還要加上各種合約條文來限制甲乙雙方的權力及義務, 例如交期, 付款條件, 罰則, 合約爭議處理, 合約中止, 違約, 不可抗力...這些合約條文一般在大公司的法律部門都有標準版本的中英文合約(Standard provisions), 我們稱這些合約條文為 clause, 總稱為 Term&Condition, 除了這標準版本的條文外每個專案都有其差異性, 這些差異需要供應商(系統整合商)或甲方(buyer)特別遵守的稱為特訂條款(Special provisions), 例如系統或產品規格, 專案特別需求(標準條款沒有), 這些條文會影響供應商的投標意願及報價, 專案經理也要確認透過合約條文將風險轉移給供應商, 所以專案經理要參考自己的主約條文然後back to back 將風險(例如交期,罰則,品質...)透過合約條文轉移出去, 所以專案經理必須要參與採購流程

採購流程大部人都是部分參與難得窺得全貌，一來說需求人員通常會先準備三家報價，然後上個採購單(Purchase Order), 複雜的系統就加些系統規格要求，然後就看採購了，有進一步消息或活動採購會通知，大概時間快來不及時才會摧一下進度，事實上PMBOK講得採購與一般實際運作基本上幾乎一致，下面就讓我們來順一便，採購是流程導向的(process driven)，每個流程間是有清楚邏輯關係，少了一步驟就不完整。

許多老闆都知道風險管理很重要, 可是說到要如何做, 大家確都是嘴巴說說沒人知道該怎麼做, 另外一種就是把問題point out出來然後沒有任何solution, 問題我點出來了發生不要說我沒提醒, 其實我們要的不祇是發現潛在問題, 怎麼解決及是否有效才更重要, 下面列出方法步驟照著做即可

Scope verification 會發生在專案每個 Phase 結束時, 要將 deliverable 交到客戶手上, 並得到客戶的簽收(acceptance, sign-off)所以是與客戶相關, 當然交給客戶時也會確認交付的數量及品質是否經過QC(Quality Control) 檢驗完成可出廠.

Path Convergency(路徑匯集)

當我們將WBS，最下層我們稱為 Work Package就是工作包，代表同類型活動(Activity)的集合，例如控制箱體(100只)這是某專案WBS的底層(Work Package)，然而這100只控制箱體不是一天內可以完成，所以又要在Activity Definition細分成許多的步驟(備鋼材、..成型、..塗裝)，這些步驟就是Activity，如果你是一個PM你應該會想知道這100只控制箱(含控制器)，整個需要編列多少預算，實際花費多少錢，這裡的100只控制箱就會是 Control Account，你需要與Finance溝通將他列為Control Account，Finance會給專案及專案下每個Control Account編號，所有與100只控制箱相關的 manpower, overtime, invoice, business trip… cost，在填報費用申請時，都會灌進這個Control Account 編號下，而所有的Control Account相加即是你專案的總預算及實際花費，所以專案經理可以經由財務報表得知專案目前的花費是多少。在 Projectized的組織都是利用這樣的方式做專案的成本控管，Matrix 組織也要將專案部分列入財務的項目(WBS)裡這樣才能有效控管專案的預算及支出，不然是無法區分Routine 工作及專案的成本。

RFP 工作中我們常聽到這個英文縮寫, 其實有很多人有聽沒有懂, 它的全名是 Request For Proposal(提案邀請書), 意思就是買方想要買東西, 要請賣方提出建議書(proposal), 所以就寫一個Request For Proposal 邀請賣方提供解決方案。所以買方必須先很有禮貌的提出這項請求，在RFP裡就會有一封類似信函的文件，非常大略說明買方需求並邀請賣方提出解決方案，這個信函的文件我們稱為 Invitation For Tender (IFT) or Invitation For Bid (IFB)。要請賣方提出解決方案，買方自己就必須先把的需求說清楚，這邊的需求不僅包括系統設備規格、數量、交貨時間、地點，還包括一旦取得合約後雙方面的責任與義務(Contract Term&Conditional)必須先說清楚(例如付款條件、罰則、中止…)，這些都會影響賣方的意願及報價，另外賣方的專案執行的能力也可以請賣方提供專案執行計畫書，列出專案組織及施工能量( 配合廠商、設備、機具…)，為了公平起見不讓賣方認為只是陪標白忙一場，我們會附上評選標準(Evaluation Criteria)，最後也是最重要的是因為商業上機密考量，買方會要求賣方簽署保密條款/規定NDA(Non-disclosure agreement)，不得將RFP的內容對外揭露.

–

我們在Planning階段最後會把專案管理計劃做出來，換句話說我們就有Scope baseline(基準線): WBS、Time baseline: Project schedule、Cost baseline: PV(or S-curve)及Quality baseline: Quality objective/standard，這些都是計畫的，在五大流程中Planning階段完成，接下來是真正開始我們稱為Execution執行階段，所以真實的工作範疇是否完全被執行，時間上是否跟得上，支出是否在預算內，品質是否符合要求，把這些實際發生的與基準值作比較就會出現偏差(deviation)，所以要採取行動，這些行動是要讓實際狀況能夠重回基準線(baseline)按照原計畫執行才能達到專案目標(Project Objectives: scope, completion day, Budget at completion)，所以我們稱這些行動叫 corrective actions(矯正行動)，如果是時間進度落後我們會用趕工計畫來把進度追上 project schedule，如果是費用超出預期我們想辦法cost down，範疇不完整或品質不佳同樣我們也會採取矯正行動來修正，為了不讓類似的事件(Event)在未來重覆發生我們會採取 preventative actions(預防行動)，這些矯正行動、預防行動會不會有新的Work package(or activity)、品質標準，需不需要額外的資源、費用、時間，如果答是”是”的話就會要更改專案計劃書，所以就要走Change流程，獲得change control boar的核准才能變更專案計劃書，產生新的baseline 再據以執行。

Try to answer the following question with your own understandng. you'll realize what are these 3 aspects fast.

Took more than 2 nights I read "How starbucks save my life, a son of previlige learns to live like everyone else", We've known more employees will be laid off after new year. How sad it is, assume one day when we encounter this situation, how would you gonna do. Including me, may be one day it would finally comes to me sooner or later, right.

Conformance to Requirements符合要求: 提供符合設計規格的產品或服務

預防成本：針對品質所做的宣導、教育訓練(Ex： TQM)

平均值(X)：

專案資金調度必須參考專案工程活動進度及配合組織現金流來準備，專案工程活動進度指的就是預算Cost Baseline or PV(Planned Valve)，組織現金流指的就是組織可以調度的資金，這兩個都是隨時間變化而改變(Time Phase)的曲線，將這兩條曲線予以比較，其中的差異就是專案資金需求(Funding Requirements) (考)，如附圖，附圖可以看出專案資金需求(虛線)是如階梯般分段提供，即是一種步級函數(Step Function)(考)。

當我們將WBS分解後(如下附圖)，最下層我們稱為 Work Package就是工作包，代表同類型活動(Activity)的集合，例如控制箱體(100只)這是某專案WBS的底層(Work Package)，然而這100只控制箱體不是一天內可以完成，所以又要在Activity Definition細分成許多的步驟(備鋼材、..成型、..塗裝)，這些步驟就是Activity，如果你是一個PM你應該會想知道這100只控制箱(含控制器)，整個需要編列多少預算，實際花費多少錢，這裡的100只控制箱就會是 Control Account，你需要與Finance溝通將他列為Control Account，Finance會給專案及專案下每個Control Account編號，所有與100只控制箱相關的 manpower, overtime, invoice, business trip… cost，在填報費用申請時，都會灌進這個Control Account 編號下，而所有的Control Account相加即是你專案的總預算及實際花費，所以專案經理可以經由財務報表得知專案目前的花費是多少。在 Projectized的組織都是利用這樣的方式做專案的成本控管，Matrix 組織也要將專案部分列入財務的項目(WBS)裡這樣才能有效控管專案的預算及支出，不然是無法區分Routine 工作及專案的成本。

To Dear Viewers,

在談Life Cycle Costing 生命週期成本之前，我們要先比較一下下列3個與專案相關的生命週期

將預算科目分成這兩個大項的主要目的是要定訂KPI，評量主管預算控制的績效(performance)。

大家應該聽過這句話就是”我已經投入那麼多(愛情、資金、心力…)叫我怎麼能放棄半途而費”，這裡的"投入那麼多"即是Sunk Cost (Expended cost已花費的成本)，我不甘心我已投入那麼多了，我要堅持下去(這是非理性思考), 以財務的角度在處理問題專案時，要將Sunk cost分析出來予以排除，才能理性面對問題評估專案是否繼續或中止(termination)，避免損失持續擴大。

許多人都認為cost budgeting就是要把專案預計要花多少錢那個數字(Budget At Completion)找出來而已，問你一個問題如果你的project夠大，財務問你明年上半年應該預留多少預算給你，你要怎麼回答，根據什麼回答，其實財務是在做 funding plan，需要參考你的 budget plan，從專案計劃那裡可以看出來？做過預算控管( budget administration)都知道，預算是每月編列的，根據事情(專案活動量)多寡來決定每月的預算， 所以 cost budget是 time phase的 budget(考)。 S-curve (PV那條線)是cost budgeting的output，從 S-curve 我們就可瞭解PV(Planned Value)在各月的值，依照此即可提供財務要的數字。

All newly formed teams go through following 4 stages of development:(first proposed by Bruce Tuckman in 1965)

專案經理可運用那些權力? 這個問題大概多年前我也跟我老闆討論過，有些主管”喊水會結凍”，有些”喊水未叮動”實在差很多，到底差在那裡，我們來看看專案經理可運用那些權力。

Team Performance Assessment是發展專案團隊(Develop Project Team)的 output，經過運用下列發展專案團隊的工具後，專案團隊是否能展現預期的成效(team effectiveness)是需要進一步做評量，而這個評量的結果才是發展專案團隊(Develop Project Team)的 output(考)。

是一種Project performance appraisals 專案績效評核方法。

其實月亮沒有那麼大(周圍的光暈讓月亮看起來特別大)，也就是其實他(它)沒有那麼好或差，僅針對一個例子或者少數例子的正、負面印象，就對整件事作出結論，即是以偏概全，有了這種印象就會影響判斷，有可能造成誤導作用。

在PMBOK你可以看到這兩個 term，許多人把這兩個名詞視為相同，舉個例子你就會瞭解我的明白。

Project management team專案管理團隊：最核心的一群人，負責專案管理流程運作、專案控制

先問個問題，一個專案它的工期10個月，總預算1,000,000，包括五項活動(依施工順序為 A、B、C、D、E)，每個活動工期是兩個月，其中第三項C活動的預算為 800,000，其餘四項活動的預算同為50,000。今天是第六個月底， A、B、C活動完成，請問目前進度應該是 6 months/10 months= 60%，還是 (50,000*2+800,000)/1,000,000=90%，95%的學員會依習慣答：當然用工期計算60%才對，其實這沒有一定的標準答案。

這是一般學員比較陌生的，這是因為台灣中、小企業很多，大部分人接觸到的是小 project， 幾個人、幾十個 activity就搞定，進度回報可以down到相當detail，譬如說68%、73%，小project可以用這樣估法ok，可是一般中、大型project 的activity數量用百、用千來計是平常的，所以為了減少不必要的資源浪費在各項活動進度的資料收集上，所以就必需採用下列方式來計算專案各項活動的進度。

Time的 baseline 是？，不能用忘了、不記得來掩飾，這是非常基本的觀念，如果這類基本題目答錯，你認為PMI會讓你拿PMP credential嗎？他會想辦法把你 spec out，接下來的考題…。答案是專案完成日，對嗎？還是Project Schedule？專案完成日是專案的Objective、同時也是專案的 constraint，亦是 risk，不是 baseline。Time的Baseline是Project Schedule，亦就是各活動的預定開始結束時間，什麼時間該做什麼事，畫成 Bar Chart(Gantt Chart) 如下圖黑色文字及黑色Bar，藍色指的是實際開始執行的進度，所以為什麼一定要先 plan，目的就是要把 baseline(基準線定出來)，如果專案控制的好，可以照著基準線走，就會提早或準時完成專案。下面的範例提供大家參考，每個活動的負責人，可以很清楚看到目前自己負責的活動是落後還是超前，別人進度(包括前置predecessor、後續successor工程)如何，都可以一目了然，所以也是很好的溝通工具。再提醒一定要有 baseline然後 actual 才有意義，才知道差異(variance)在那裡，才可以 take corrective actions 及 preventative actions。

專案時程 (project schedule)裡有每一個活動的預定起始時間及預定結束時間，有了這兩個時間後，我們就可以將每個活動放在時間軸上，以橫式長條圖(Bar Chart)型式來表示，所以每一個活動預計的起、迄時間可以一目了然。專案時程以這種型式表示稱為甘特圖樣(Gantt Chart)，有了Gantt Chart代表我們知道在每個月裡面，我們有多少活動要進行，把這些活動的估算成本，按在本月份有多少工作天做為換算比例(有的活動跨月份)，來換算在本月執行的活動量總計有多少錢，將每月加總並累計的值稱為PV(Plan Value) 計劃值，將每月的PV畫成曲線就稱為 S-curve(橫軸為時間，縱軸為錢)(考)，這個曲線上最終值稱為 BAC(Budget At Completion)。這個S曲線是三大 baseline的其中之一，Cost Baseline。稱為S curve是取Spending的 S之意，因為PV是活動費用的累積，代表花費。另一層意義是S curve曲線的樣子，就如同 S一樣，在起始(Inintiation)及結束(Closing)活動量較少，花費較少所以曲線較平滑，中間因進入執行階段，會有大量的資源投入，支出多所以曲線會陡峭。

“這個工作大概7天可以做完，今天是星期一，所以下星期一交…？”怪怪的對吧！問題出在那裡？

我們用的 CPM(Critical Path Method)是 Time Critical ，意思是指我們在排schedule時都是以滿足客戶的時程需求(completion date)為主，因為變數很多所以先將時間擺在第一順位，其餘變數(ex:資源限制問題)假設都先 Fixed(可完全配合專案活動需求)，才來發展專案時程。

PMI Certification:

 The Most Jr. PMs' behavior

我們用的 CPM(Critical Path Method)是 Time Critical ，意思是指我們在排schedule時都是以滿足客戶的時程需求(competition date)為主，因為變數很多所以先將時間擺在第一順位，其餘變數(ex:資源限制問題)假設都先 Fixed(可完全配合專案活動需求)，才來發展專案時程，當考慮完時間之後，接下來要開始再檢核其餘變數，資源是否足夠因應就是其中一個主要項目，考慮在有限資源條件下，進行資源撫平，方法如下:

 一般的投資報酬率大家都知道，計算方式如下，如果是短期投資，可以忽略貼現率或折現率問題(不考慮金錢的時間價值)亦就是，不考慮轉換現值問題(PV、NPV)。

之前講完Hidden Agenda後就把這個 Term先寫下，免得漏掉。當我們在網路上收尋網站或買商品看型錄時，常常可以看到這個縮寫字WIIFM，製造商目的就是要讓你與產品直接產生連結，因為我們要不要買，通常不在於商品他有多好，而在於這個商品對我有多好。所以我們在看待一件事情時，心理先想到的是我與這件事有何關係，我的角色是什麼，我可以從這件事情得到什麼或損失什麼，這是每一個管理者都應該要知道自我為中心的人性面，這是人同此心心同此理的道理。所以我們在與stakeholders談論問題時先要去聽聽，瞭解對方會想到什麼，他要什麼，讓專案與他產生連結，他們才會有意願投入，一直強調專案要什麼，會帶給他們什麼，常常不是他們要的。

原來我们是這樣長大的，你我大概都走過這6階段:

 http://www.wretch.cc/blog/lcdr131coma

http://www.tutorialspoint.com/pmp-exams/index.htm

100 Q: http://www.tutorialspoint.com/pmp-exams/pmp_mock_exams.htm

PMP 名詞解釋 Glossary 網站:

在專案計畫訂定前，模擬各種情境來分析專案的結果，最常使用的假設分析就是利用專案管理軟體，試著模擬變動某個活動的工期、順序(dependency)，看看要徑、完工日、強制日期(imposed date, 某活動一定要在特定日期)是否變動，該活動是否還在要徑上，資源長條圖resource histogram) 、S curve的變化，所以叫 What if (假使…) Analysis。

縮短時程的方法有許多種例如流程優化，但是這裡要特別談的是”壓縮”， 壓縮有下幾種:

當我們把網路圖排出後，在每個活動上標示上時間，現在再問專案何時可以完成，看得出來了嗎？我們會發現網路圖有好幾條路徑，算一算把最長的路徑找出，這條路徑稱為要徑( Critical Path)。要徑上所有活動的工期相加即是初步的專案工期(還需要檢核調整)。

我們現在知道要做那些事(活動)，每個活動要用那些資源，需要花多少時間，好，現在你能告訴我專案需要多少天才能夠做完？有人會很直覺回答「把所有時間相加就是」，那有些活動是可以並行的怎麼辦，要是有提前(leads)FS-3、延遲(Lags)FF+4的關係出現怎麼辦。所以我們應該先把活動的順序先找出來亦即把彼此關係先找出來，畫成流程圖，這個工作流程圖我們稱為 Network Diagram(網路圖)。

各位學員還記不記得專案定義的三個要件

兩活動之間的關係除了上述四種關係(FS,FF,SS,SF)之外，我們還可以加入一些變化來因應專案真實情況，例如

我們在Microsoft project 裡輸入每個活動的工期，你認為你的 team member會給你下列三個值的那個值

 考題只要有給 unit rate 就選Parametric estimaing, Ex: 1 day/m², 2 wks/unit

類似工作分解結構(WBS)，將專案活動所需資源(人員、設備、材料)進行分解，以及將每種資源的需要量畫成如OBS,WBS 階層圖(考)，方便我們了解資源間的關係，做了此種彙整分類後，好處如下: