當業務接到需求，我們也針對雙方的研擬出方案，這時我們會進行專案立案審查。立案審查基本上提出一個項目章程(project charter)，這個詞我很少碰到，大多是用評估表(assessment form)，當你提交並通過專案審查，表示獲得初步同意，可以繼續研擬細節的時程表，編列預算書、財務部也會針對專案開支，在系統上有個虛擬的專案專有帳戶，在專案結案後，這個帳戶就會清算並關閉。這樣有點問題，如果客戶發現不良或是錯誤使用造成損壞，需要維修的話，是要重新開啟同樣的帳戶，這樣比較快，不用重新審查，但是超過原定的範疇，不審查好像也不應該。總之，這種成本會計的問題，會一直困擾著你，我已經數不清開過多少次會討論帳的歸屬，對我們來說就是財務部可以接受就好啦，訂出規則然後我們照辦，這種會議各個部門都要參加，耗時又長，而且經常沒有結論。
立案審查的誤區
經常在審查時，會直接看準備花多少錢，以及時間。如果是訂單金額能夠支應開銷，一般都不會太多刁難，反正有生意做總比沒有強。至於風險方面，因為缺乏數據支撐，所以類似廠商唬爛規格，測試起來根本達不到宣稱的性能，或是你買到得也是原型機，沒有完整的驗證過，這當然可以寫，但是不會有人真正當一回事，發生了也只能算你倒楣。
我認為立案審查時，「背景資訊」以及「假設」，這二點是最重要的。背景資訊提供了黃金圈法則中最重要的"Why".
Always start with why.
這項資訊，必須委由業務部或市場部提供報告，合理化為什麼選擇「產品開發」，為什麼不是做「產品設計優化」或是「供應鏈優化」，請供應夥伴提供降本建議，或是改用甚麼材質，或是更深度的協作降低庫存等等，或甚至轉型從製造商變成供應平台，來對抗高度整合的零售端。所以專案與專案之間產生關聯，市場部主導的調研專案，所輸出的文件，將成為產品開發專案的輸入文件。
如果結論是，增加某樣產品，或是增闢一個產品線，那產品部就要著手規劃，請專案部或產品部自己，看是一個大專案下轄幾個小專案，或是以個別專案進行。用大專案方式，整個產品線會比較有有整體感，但是考量到時間也比較長，有時可能為了方便年度結案，拆成數個小專案進行。但是有可能發生大專案的主事者遭替換，新上任者不再挹注資源，導致已經完成的產品，推了又感覺太單薄，沒幾樣產品，不推的話開發費無法回收，答應工廠的也不好反悔，產品部將會面臨裡外不是人的窘境。
專案範疇及變更管控
專案內容變更，我想是所有專案經理的惡夢，而更可惡的是「潛變」，可能來自於客戶或主管，想偷偷塞一些東西進來。如果你曾經承接政府標案，很有經歷過主辦單位提出一些與專案無關的要求，為了再此拿下專案，也只能默默接受。當你發覺時，經常為時已晚。
在工廠裡，要調度資源，必須要開立派工單，有時候業務部會先用電話或郵件去凹工廠先進行，相關文件之後再補，有些工廠被婊過幾次，沒有看到派工單前，絕對不進行任何協議以外的事項。其實專案有變更相當正常，主要是變更盡量要按正常的流程審理，變更也要重新審視，增加的是否符合立案的目標，如果是，那增加的時程、資源、預算，當然也會增加交付物。不過，經常發生加麵加湯又不加錢，這種吃豆腐的行為。不過有時候如果專案初期規劃失誤，反而期待變更，一次把先前未考慮周詳進來的部分，或是時程延誤的部分，一起打包進來，就不用特別呈交報告。(這是錯誤示範，不要教壞小朋友)。
因為工作任務因為高層要求，已經被拆解得很細，而且設定了任務之間的相依性，突然接到指示，需要增加工作，這種情況大家肯定過，我的經驗可以分成以下四種情況：
- 由PM了解情況後，與負責工程師討論後，增加在專案管控表中。(我最喜歡)
- 工程師接到指令，發郵件給PM，請PM放進專案管控表。(這是一種可能，但沒有發生過，而且這有部分重工，會降低營運效率)
- 工程師自行上系統增加任務，但是一般工程師不會去花時間了解整個計畫背後的邏輯，就找個地方插入，然後填好起始日跟結束日。但是整個專案較為龐雜，這種方式的插入，對工程師來說事情就這麼結束了，但是有很大機會，他沒有注意到後面的排程，或是其他專案產生衝突。所以有的專案管控軟體，可以設定只要有變更，就會傳送通知給我，或是突顯過去24小時內的變更，這一點非常好用。
- 工程師接到指令直接先做，之後可能在專案週會上檢討進度時才會拿出來講，而且有些片段只能勉強靠記憶拼湊出來，工程師可能覺得事情都已經做完，現在還去討論有意義嗎，不過落後的部分，我也必須跟上層交代，無法掌握清楚我也有責任。這往往來自於研發高層，想偷渡自己side project，所以直接找工程師不找PM，工程師面對考核自己的主管，似乎也沒有拒絕的權利，就先做再說。
最後一點是我認為最不好的，此風不可長。我都再三強調不過要增加什麼，變動什麼，甚至只是要問資訊，千萬不要因為方便，直接找上我的組員，他可能在毫無準備下要馬上給你數字或日期，而且不同部門都跑去問(誰叫場地在會議室門口)，讓他煩不勝煩。所有部門若想知道任何專案相關資訊，都必須透過專案經理，我們也會針對經常被問到的事項，修訂項目溝通計畫。
如何面對風險
我覺得風險是最難寫的，而且往往跟假設是並列在一起。但千萬不要被風險嚇倒，凡是越創新的專案，不確定性就越高，當然可以利用腦力激盪，發想各種可能發生的事件，不過還是有可能發生很多令人傻眼的低級錯誤，例如：正負極接反導致零組件損壞。但是如果真的發生也是給我們一個機會思考，設計上有沒有防呆，或是工作量是否已經超過負荷，導致無法專心。對於風險，我的態度一向是如果有評估到，即便不巧發生了，那責任是可以輕一點；但是如果連想都沒有想到，或是甚至放馬後炮，說有想到卻沒提，這個問責上就會嚴重得多。因為我認為面對風險，態度是最重要的。
同時也要讀者體認，一件事情會有高度的不確定性，正是因為你正在做一件，從來沒有人做過的事，所以如果能成功克服，就能產生相對應價值。風險越巨大，成果也越甜美。模仿是不確定性最小的，但是同樣帶來的價值也小。我們無法完全避免不確定性，但是我們可以用各種手法讓風險逐步收斂。
當然一些突發狀況在所難免，所以就像建築設立防火巷一樣，會在合適的部份，留下緩衝(buffer)。緩衝這件事會有牛鞭效應，如果彼此不熟悉對方行事風格，那麼每個人都會留下緩衝，那每個人都根據自己收到的資訊再加上一定緩衝，就會變得到處有緩衝。採購部分也是一樣，為了有貨可以賣，很多經銷點在檔期先壓存貨，每個地方都放一點，累積起來就相當可觀。
我的做法是buffer通通交給我來加，不要你加20%，我又疊20%的情況，老實說技術性高的系統，不可能樣樣都懂，所以加了一堆buffer，容易被質疑時程合理性，後來就會採取極端的微管理(micro-management)，把每一天上下午要做的事都列出來，但是這種做法，導致計畫工作項目龐雜，很多時間反而浪費在登錄項目上。
如何贏得高層的支持
在說明了背景脈絡、專案目的及目標、專案範疇，也估算了潛在收益及風險，接下來，高層差不多就會互相交換意見，看是要增加補充資料，或是有條件通過。
一般專案的三大重點，是品質、成本、交期，但是對於高層來說，這個專案能夠為公司創造什麼，才是真正關切的，而這時候簡報中，可以試著以專案對公司的【重要性】->【差異性】->【急迫性】，這樣的邏輯展開，也就是在整份PPT看完，要能回答 1)為什麼要做這件事；2)為什麼我們來做；3)為什麼要現在做，只要能完整回答這幾個問題，等於你已經充分掌握了市場趨勢(重要性)，競爭對手(差異性)，以及增長路徑(急迫性)，相信高層會對這份提案更有信心，你也更有機會通過立項初審。
在很多次的審查中，對於為什麼瞄準這個市場區隔，規模多大，預期成長性多強，目標顧客的描述，還有如何接觸及服務這群客戶，這些資料都相當缺乏。尤其像是農林礦機具相關，先撇開資金跟許可證的問題，你要市場行銷人員，在塵土飛揚，又濕又熱，或又冷又高海拔的環境中，保持細心耐心的觀察都很有難度，一般都會採用最便捷的方式－電子問卷，或是用谷哥大神拼拼湊湊出可能的需求，但是這些永遠都比不上實際的體驗。
曾經遇過有公司意識到這個問題，所以拿出一筆獎金，給真正體驗過並且拍攝影片為證，且完成上傳資料庫的第一人。但是最後沒有人完成，難度有點高，獎金又不夠吸引。其實公司HR或管理部，可以用公司的名義，租借器材及場地，讓所有人都有機會體驗，當作團建的一部份，這樣有產出也好申請經費。我相信會比起以競爭的方式，各顯神通去弄到設備完成任務，來得更有成效。
