當業務接到需求,我們也針對雙方的研擬出方案,這時我們會進行專案立案審查。立案審查基本上提出一個項目章程(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或管理部,可以用公司的名義,租借器材及場地,讓所有人都有機會體驗,當作團建的一部份,這樣有產出也好申請經費。我相信會比起以競爭的方式,各顯神通去弄到設備完成任務,來得更有成效。