「哇! 好棒!」

Dear I:

人生苦短，不值得 (也沒必要) 花費在自己沒有熱情的事物上。有句話是這麼說的: Nothing great was achieved without enthusiasm。「Great」，對原本說出這句話的人來說，也許指的是「偉大」，但我倒比較樂意把它解釋成「好棒」。對，沒錯，就是好棒，就這麼簡單，一點都不偉大。沒有熱情，就做不出「好棒」的事。

好棒，多麼簡單而美麗的感覺，但我們已有多久沒有享受到這種單純的美好? 多久沒有因為一件很棒的小事很雀躍好幾天，讓我們有足夠的熱情與能量再去完成下一件很棒的小事? 好久了是吧? 那似乎是我們小時候的事了，以前以前以前，念故事書的時候好棒阿，可是自從上了小學 (或更早?)，有了考試，念書就變得不那麼棒了。以前以前以前，彈琴好快樂阿，可是突然有一天媽媽說要去YAMAHA考檢定，彈琴這件事就變了。以前以前以前，我好喜歡說話，可是有一天老師要我去參加辯論比賽，結果我發現有人比我還會說話，從此之後，我就再也不想在朋友面前說話了。以前以前以前，我好喜歡畫畫阿，可是有一天我的漂亮畫畫上面怎麼會被好醜的紅筆畫了一個數字? 而且隔壁小美的數字還比我高? 天哪，我再也不要畫畫了。

你知道為什麼嗎? 因為我們都把事情弄得複雜了。我們的心都老到忘記了事情的本質，忘記了要拋卻讓我們不愉快的因素，僅僅保留那事物中最吸引我們、最讓我們想要叫出「好棒」的部分。我們都忘記要去找那件事，忘記要去找那件事裡面最棒的因素，於是我們做了一件我們不愛做的工作，也許只是為了錢。我們也忘了要去想，除了每個月發薪水那一天會讓我們快樂一下下以外，其他30天要靠甚麼來支持度過。但如果，有這麼一天，我們都學會，只選擇看到彈琴好快樂或是畫畫好快樂，那我們就有無限的動力，練成一首美麗而動人的曲子或是畫出一幅令人感動的圖畫，然後，我們就會從心底發出一聲「哇! 好棒!」，然後我們就會很高興地去練下一首曲子或是畫下一幅圖畫，這種往下走一步的動力是甚麼? Dear I，你猜到了，那就是熱情。

人生似乎就是這樣子，一次一小步，一次一小步，走著走著，回頭一看，哇，離起點好遠好遠了，而且好像比別人都走的還遠，原來一個一個的「好棒」可以累積成「最棒」! 但如果沒有這一個一個小小的「好棒」，到最後就可能只是在起點打轉而已。加油，讓我們一起告訴身旁的人，找出那件會讓自己喊出「哇! 好棒!」的那件事，然後把它和旁邊的一切不愉快隔離開，專心的享受那個好棒就好，總有一天，他們也會發現自己是「最棒」的!

Dear I，請你和我一起大聲的念一次，「哇! 好棒」!

有沒有發現你離「最棒」又靠近一點了呢?

團隊熱情的建立與再激發 (P公司篇)

最近幾個還在P公司工作的朋友陸陸續續和我有一些連絡，也談到了現在P公司的狀況，無非就是基層士氣低落到谷底云云。因為前幾天才寫了一篇關於團隊熱情的建立與再激發的文章，只不過是以C公司作為實例，於是有些在P公司看過這篇文章的朋友們，自然就問到，那如果是P公司呢? 該怎麼辦? 是不是也來寫一篇分析?

P公司士氣低落的主要原因，在我的離職感言裡已經提過了，這裡無須再贅述。今天想要討論的只是，這種情形該如何改變? 我個人的離職感言裡的想法比較像是「反求諸己」，基層員工凡事說反求諸己還說得過去，但如果是高階經理人，要求基層員工凡事反求諸己，自己把自己搞得快樂一點就好，聽起來就百分之五千萬的沒說服力。再者老實說，像我這種天塌下來都可以找到開啪踢的理由的人也不多，如果你是高階經理人，就不用肖想下面都是一群腦袋有問題的樂天派神經病了，至少在P公司不是。

以下幾件事或許是P公司的高階經理人可以考慮作的：

1. Ｐ公司一直都有目標，而且目標很明確，只是很多年來都作不到。第一步，開誠佈公，和所有人討論溝通公司的走向，討論溝通該如何走出目前的困境，討論溝通該如何達到那個目標，甚至討論溝通是不是先設立一個短程較容易達成的目標。P公司的人數雖然是Ｃ公司的數倍，但畢竟還是一個很小的公司，和每一個人談，無論是個別地或是小群地，是一定可以做得到的事。
2. 討論溝通的過程中，同時篩選出每個人最願意合作及絶對不願意合作的對象。
3. 藉由坦率且真誠的討論溝通過程中，找出誰還有熱情願意提供自己的意見，甚至貢獻自己的力量，朝任何的可能性前進。這段話的重點有幾個，第一，真誠坦率裝不來，再笨的人都可以看出來你是不是真的要傾聽他的意見。第二，我們是要找出還有熱情的人，而不是要找出最聰明的人，最聰明的人的熱情通常消磨地最快，在這個節骨眼上，通常已經沒有什麼熱情，把公司當笑話看的成分還多一點。第三，找出來的人不只要有熱情，還要能夠願意傾聽其他人的意見，甚至是朝其他人建議的可能性前進。以這些人作為未來前進的keyman。
4. 請大部分人都不願意合作的對象走路，相信我，一定會有這種人存在，而且現階段P公司完全不需要這種關在自己房間不跟別人合作的人，現階段P公司需要的是重建一個有向心力的team。這種人在組織裡面不會有任何貢獻，這種人的存在只會造成組織力量的分散。
5. 請沒有熱情，沒有意願貢獻自己的力量甚至是意見的人也下車，這種人的存在也會變成組織前進的阻力。

也許局內人會問，也許這樣會看到一些在 function 上很重要的人被請下車，這對P公司是一件好事嗎? 好事壞事見仁見智，我比較好奇的是，這些所謂 function 上很重要的人是真的能夠對整體組織有正向的 contribution? 還是只是「function 上很重要」而已?

團隊熱情的建立與再激發 (C公司篇)

先和關心這個部落格的好友們致歉。既已自許為專業部落客，又發生一個月沒有新文章這種事，實在是不應該。



我最近發現C公司內大部分的工程師們士氣有點低落，當務之急自然是和所有工程師都面對面一對一地討論溝通。經過溝通了解之後，我歸納出了幾個原因：

1. 專案時程太長，過程中缺乏激勵。(過去的工程師能力很強，相同規格的專案所需要的時間比較短。現在的工程師都是新手或半熟手，專案時程相對來說會拉長，以前不是問題的問題現在全都顯現出來。)
2. 與客戶討論需求及規格的確認度不夠，客戶需求在開發後期會一再變更，也會導致專案時程拉長。
3. 基礎技術能力不夠，開發過程中會遇到較多的挫折。
4. 專案領域差異太大，專案領域了解不夠，開發過程中也會遇到較多的挫折。
5. 專案領域差異太大，每一個案子都是全新的案子，做完之後無法累積，工程師不了解自己的成長在哪裡。
6. 公司目標沒有讓工程師了解及內化，工程師不知道自己的努力與公司目標的達成有什麼關係。

首先，這些原因該如何分解成獨立的因子? 我認為造成工程師士氣低落的獨立因子有以下幾個：

1. 專案領域差異太大，
2. 基礎技術能力不足，
3. 需求及規格的確認度不足，
4. 人性需要被激勵，無論專案時程長短，
5. 未建立個人與團體之間的目標連結，
6. 人性需要自我成長。

該如何解決?

1. 盡量集中領域，確定公司的重點領域後，業務端就要盡量去挖掘該領域內的專案。某些情況下，其他領域的專案也必須接，但是要明確地知道、而且也要明確地讓工程師們知道，接這些專案的背後原因，比如說，為了達成基本營運目標、為了經營客戶、為了….等等。
2. 提供教育訓練，提升工程師基礎技術能力。軟體部分，請資深的工程師以公司重點領域的產品為例，建立 Development Q&A。安排教育訓練課程，資深開發工程師帶著資淺工程師實際看code，然後再看 Development Q&A (一邊看 Q&A，一邊看 code，從 code 裡面說明答案)。每個月月底定期測驗，為了激勵，於隔月月初的月會上頒發最佳進步獎。
3. 教育客戶需求確立的重要性。另外從制度面著手，強迫業務端在接案之前，必須由工程部的資深工程師與客戶偕同討論規格，並文件化，合約擬定必須以該文件為附件。使客戶明確了解需求及規格與價格之間的重要關聯性。
4. 每月月初的月會時，針對前一個月有重大進展以及正式結案的專案負責人，公開表揚，並頒發實質獎金獎勵。
5. 透過公開徵文比賽，讓每個人 (不只是工程師) 都能參與公司目標制定以及個人對該目標所能提供的貢獻的討論，針對最用心的提案者，於週會上公開表揚，並請其公開發表意見，最後頒發實質獎金獎勵。另外，每個月月底定期測驗也要固定把公司目標以及個人需要提供的貢獻置入題目內，讓每個人都能把個人與團體之間的目標連結並內化。(這個部分可以參考另外一篇文章。)
6. 經過公開討論過後，將公司的目標、策略及 to-do-list 明確化。並盡量讓每個工程師的工作或多或少都能與 to-do-list 連結，將to-do-list列入專案管理機制，藉以每周週會時提醒並鼓勵夥伴，他與公司目標的連結關係，以及他個人的重要性。

偷偷告訴大家，因為最近也剛好在思考公司未來的目標，所以就一併在上週舉辦了公開徵文比賽，第一名也在本週的週會上表揚及頒獎了，說真的，我覺得，初步效果真的很好。看到大部分人都不只是把它當成一個要交的作業，反而是在很認真地思考，還會三不五時來找我討論，感覺就像一個 team 在一起找 solution，這種感覺真棒。

C公司的三年目標 (1)

可以想見的是，這麼大的一個題目，不可能只思考一次，只寫一次。這必定是一個不斷蒐集資訊、不斷反思、不斷調整、不斷溝通、逐步建立共識的過程。會把它寫下來，也只是讓自己所有的思考留下紀錄。

過去的模式：
C公司是一間成立八年的量測系統整合商，過去主要是以專案的方式營利。所謂專案，就是當客戶有特殊量測需求，市場上卻沒有成熟的解決方案時，就會找上與Ｃ公司同類型的公司，以專案的方式委託其開發專用的量測系統。專案模式有幾個缺點：第一、客戶分散，不單單是分散在不同公司，也分散在不同領域。第二、需求分散，因為是不同領域不同公司的不同客戶，所以不太可能有幾乎類似的需求，這個月做的可能是Audio/Video的測試，下個月做的可能是振動噪音的測試，再下個月做影像辨識，這種狀況直接導致第三種缺點，也就是技術實力無法累積。另外需求分散也會帶來第四個缺點，因為業務人員很難把其中一個解決方案再複製給其他潛在客戶，所以當Ｃ公司真的要把解決方案包裝成產品推入市場時，銷售費用會變高。第五，風險過高，每個領域的需求都有其knowhow，每一個專案對於Ｃ公司來說都有許多的不可預測風險在裡面，任憑業務人員再有經驗，也很難在短時間內，把全新領域存在的風險給搞清楚再量化成成本，再者，對C公司是風險的東西對客戶不一定是，客戶能不能接受這樣的成本轉嫁是一個疑問。因此，又間接導致了研發費用升高。最後一個缺點，因為專案的硬體量小，缺乏與供應商議價的能力。

現在的挑戰：
C公司的主要供應商是一間美商公司，主要採購項目是量測系統上需要用到的擷取卡、控制卡、主機及系統開發軟體等等。過去大部分的end user都是向系統整合商購買完整解決方案，也就是由系統整合商設計、向其供應商採購零件、組裝、軟體撰寫、系統測試，最後再交由end user使用。近年來，這家供應商為了拓展銷售量，除了不斷開發簡單好用的系統開發工具以外，也開始對end user開辦教育訓練課程，教育end user如何使用簡單好用的工具開發自己需要的系統，另外，它們也培育自己的應用工程師，幫end user解決開發過程中的各種疑難雜症。簡單的說，這家供應商在告訴end user，你們不再需要花費心思找系統整合商了，我們的產品簡單到你可以自己搞定一切，就算不行，我們也還有應用工程師可以隨時支援你！不論事實是否真是如此，但至少end user會願意選擇一試，真的不成的，才回頭找系統整合商。
於是，Ｃ公司的利潤空間被壓縮了，同時，生存空間也被壓縮了。利潤空間被壓縮的原因是end user會直接向原廠購買硬體，所以C公司賺轉手差價的空間消失了。生存空間被壓縮的原因則是，end user也開始學習如何自己做系統整合，所以未來會需要系統整合商的專案量會下降，難度會上升，風險也會更高！

未來的模式：
C公司不可能回頭要求供應商放棄與end user之間的銷售路徑，這與供應商的根本利益直接衝突。供應商如果可以跟end user直接對話，本來就沒有必要維持系統整合商的生存。C公司能做的，就是要走在end user前面，我們必須比end user技術能力更高，比end user更了解knowhow及風險所在，速度更快，品質更好，成本更低廉，而且能夠讓end user長期信任。這樣才能讓end user覺得讓C公司作為其量測系統開發上的策略合作夥伴是值得的，end user也就不會想要自行開發系統。
要做到以上所說的，最重要的一點就是，C公司必須能夠先找出一至兩個領域 (例如PCB、LCD) 及應用 (例如應變、振動)，並把一部分技術資源自原有專案架構內抽離出來，聚焦在這一或兩個特定領域。資源過於分散，以上所說的事情就沒有一樣可以做得到。領域及應用集中之後，客戶與需求也會跟著集中，然後因為客戶集中，所以銷售費用直接降低。因為需求集中，所以整體研發費用可以降低、技術實力也可以快速累積、單一研發風險也跟著降低 (雖然也許會伴隨著整體經營風險的升高)，品質也會較好，同時，對供應商的議價能力也將大增，就能夠以更低成本提供給end user。再者，由於需求集中而且技術實力累積快速，自然也能夠以較快速度滿足end user的需求。整個模式就會成功。
End user要的是甚麼？無非就是速度、成本、品質與長期合作的信任。請問有哪一家半導體廠會自己開發黃光、蝕刻等生產設備？如果廠商不會自己投入資源開發生產設備，沒道理廠商會想要自己開發量測設備。我相信這是一條有機會的道路，只要我們找對領域跟應用。

向茶米致敬：產品模組化，提高公司獲利的關鍵點

最近不知道怎麼搞的，突然覺得聽HipHop可以帶給自己一種很High的感覺，尤其是在身體疲勞的狀況下，聽到MC HotDog、大支、茶米在用很快很有節奏感的方式唱歌，就會讓大腦亢奮起來，彷彿又可以把最後一滴力氣給榨出來。

英明的老闆，這篇不是在向你訴苦我工作太認真。親愛的老婆，這篇也不是在抱怨帶小璞太辛苦 (小璞大部分時間都是老婆在照顧。) 我想要說的是，請各位去YouTube聽聽這些人Battle，像這裡、這裡、和這裡。啥? 蝦咪是Battle? battle就是兩個HipHop歌手互相用念歌的方式，虧來虧去，你虧一段完換我，我虧完再換你。你會問，我虧你的時候會虧甚麼? 嘿嘿，你永遠不知道我會虧你甚麼，直到你聽我虧完，所以等你要虧我時，你必須很快速地在大腦中串出一堆有意義的歌詞，再用很快的速度唱出來反駁我，如果做不到，就會變成2100全民開講，藍綠沒有交集，然後你就紅不了。

講到這邊，歌也聽了，大家會問，對耶對耶，你講得東西都很好玩，歌裡面的一些髒話也讓我聽到很爽，茶米也的確很厲害很厲害。可是，這跟「產品模組化」有甚麼關係? Ok，關係就在於，我不相信茶米真的有這麼厲害，或者說，我不相信這個世界上有這麼厲害的人。拜託，騙笑耶，連急智歌王張帝我都覺得是唬爛的，還怎麼可能要我相信茶米沒有作弊帶小抄或是套招? 曹操的兒子寫一首詩都要走七步才想得出來 (而且還是作弊先寫好，七步是裝的)，你要我相信這些人比曹植聰明? 可是可是可是，如果這一切都是真的，而且今天我是茶米，你是大支，預計一年後要被丟到上海和大陸同胞 battle，我們要怎麼辦?

難道我們會背個100條完整的5分鐘的Rap去跟人家拼，然後賭自己會運氣好到遇到對手的歌詞和我們背的有關? 而且要整段有關喔! 我想應該沒人會這樣幹。但，反正我們是要背500分鐘嘛，如果我把它拆成1000條30秒的piece呢? 中獎的機會就大多了吧? 每個歌手能想的事情也不會差到多遠，你想得到的我也想得到，1000條理面中8條我就發了，剩下的一分鐘我再真的臨場硬湊吧，真湊不出來就用一堆yoyo、come on man、do that shit硬塞也沒人說不行阿。

茶米因為太厲害了，我猜他大概背了有一萬條吧，所以可能我們一輩子都練不到那種功力，可是不知道大家有沒有發現? 大支看起來似乎就沒那麼聰明了吧? 怎麼聽起來好像就真的有一些重複的地方，那Mc HotDog呢? 耶? 轉來轉去好像就那麼幾招嘛。說到這裡，大家有沒有一種自己也可以背個10句8句去battle一下的感覺?

這就是我要講的重點，如果把聽眾當成客戶，把公司當成歌手，當我們在跟別的公司競爭客戶時，如果只是要賭運氣，贏到少數幾個非常focus的客戶，那當然可以開發一套很大很完整的產品，然後跟客戶說，黑，就用這個吧，保證不用客製化。可是現實上這種客戶應該是不多，當我們要像HipHop歌手一樣在短時間內兜出一個產品，告訴一個客戶說，黑，這個是你要的，然後再變一下，再兜出另外一版，再告訴另外一個客戶說，黑，這也是你要的，要怎麼做? 我想這些HipHop歌手已經說明了很清楚。沒別的技巧，就是，拆解，實現再組合。

整件事的關鍵在於：公司為了降低成本，所以一定會想要開發產品，降低客製化的程度。但開發好幾套大產品，期待各個大產品打中不同客戶需求點的風險太大。反向思考，如果我們能夠把每個客製化的幅度變成30秒的歌詞，而且可以一用再用，要用時就像兜積木一樣簡單，那我們就可以像茶米一樣，把我們的對手，打死。

建立以業務團隊為首的專案型組織結構

C公司是一個量測系統整合公司，大部分的營收是來自專案，你要說它沒有產品嗎? 它其實是有產品的，只是因為每個客戶的需求都多多少少有點差異，所以導致這樣一個量測系統整合公司的營運模式很像一般的軟體公司，它們會有獨特專精的產品，比如說ERP、CRM或MES等等，但都不太可能直接賣到客戶端而不需要一些客製化的動作。因此，變得每一張訂單都幾乎會牽涉到一個動作，就是客製化，尤其是越大越專業的客戶，對自己的需求了解越深入，客製化的程度也許就越高。

客製化是一個複雜的動作，從需求確認、規格定義到執行，每個過程都難免會有變數。相信我，世事難預料，再厲害的客戶，也會遇到需要變更需求的狀況，更不用說那些搞不清楚自己需求，想要且戰且走的客戶了。一旦客製化程度變高，傳統的功能性組織就會不敷需求，彈性大、機動性強的專案型組織才有辦法面對各式各樣，因客製化產生的大量變化。舉個最簡單的例子，如果是在傳統的功能性組織裡，某個專案發生了技術問題，這個問題會在技術部門裡反覆討論，再由技術部門主管和業務部門主管開會討論該怎麼辦，再由業務部門主管交代業務處理，或是由技術部門主管交代工程師處理。另外，某個專案的物料也出問題了，物流主管可能也要和技術部門主管和業務部門主管開會討論該怎麼辦，各部門也要再回頭開會交代處理方式。如果今天一個公司裡只有五個案子，那各個部門主管都還可以應付，但如果今天公司裡有五十個案子呢? 會就開不完了。

所以，比較有效率的模式應該是針對每一個專案，成立專案組織，所有突發的、非結構性的問題都是在這個專案組織裡機動解決。功能性組織則是負責解決結構性的問題。比如說，某個案子的物料進貨特別慢，在專案組織內解決，但如果每個案子都慢，則回到物流部門解決。再者，某個案子的電路技術遇到瓶頸，在專案組織內解決，但大部分案子都遇到電路技術的問題，則由技術部門考慮如何提升技術部門的整體電路技術。

另外一個待釐清的問題是，站在公司的角度，這個專案型組織要由誰當Leader? 商業週刊1059期裡的文章 (將風險量化　回歸財務流程管控) 有明瞭且完整的答案。簡單地回答，這個Leader就是業務。在專案生命週期管理上，業務不只負責接訂單，還是專案的負責人。他的績效評估模式，將會包含專案的獲利率、客戶滿意度、客戶重複購買率與專案達成度等。他也需要協調每個環節。這就很自然的讓業務對風險擁有Ownership，會更重視整體的達成度。這件事的前提是，要讓業務有driving force承擔這樣的責任，也就是將績效與個人的driving force連結，例如把每個案子最後的獲利讓業務抽成，或是把績效值與升遷畫上直接的關係，都會是不錯的方式。

組織決定了之後，就剩下流程的問題，在這樣的一個組織內，流程就會像：由業務與客戶洽談需求、評估可行性及風險、評估成本及交期，評估過程中由物流部門及技術部門提供支援，最後報價。訂單下來之後，業務將需求會轉化成規格文件，交付物流部門及技術部門，由物流部門採購原物料，技術部門負責軟體開發及系統整合，所有非結構性的問題就會在這三個人當中協同解決，當然，過程當中這三個人還是可以向其他人提出支援的要求，如果必須的話。開發時如果遇到客戶要求工程變更，則統一由該負責業務出面與客戶接洽。技術部門將系統完成後，便可以將這個系統交由業務確認，是否滿足當初他與客戶達成的協議，如果業務確認完成，技術人員即可對業務進行教育訓練，之後就由業務向客戶進行驗收工作、教育訓練工作及後續簡單的維護。

最後我想提的是，雖然一個系統整合公司絕對沒辦法避免客製化這個動作，除非它堅持不做這樣的生意 (我懷疑這樣的公司是否能存活)。但如果能夠用越簡單的客製化動作來滿足大部分客戶的需求，那這間公司與其他系統整合公司的差距一定會非常的大，至於要怎麼做到這件事，我認為產品模組化會是一個關鍵，我會在下一期的文章做一個陳述，敬請期待。

ps. 在看下一期文章之前，請各位先去 YouTube 上看看茶米在上海的 Battle，像是這裡、這裡和這裡。

YoYo, Baby, Check it out, man.

資訊完整度與決策有效性

資訊完整度太低，一直是過去在 P 公司不斷發生的問題。由於資訊不足，導致大部分的決策都像是在瞎子摸象的情況下作出來的。剛好有某人說問題的發生原因可能是 A，大家就朝 A 方向解決，過了一陣子發現沒什麼用，就再猜一個原因 B，所有人就再朝 B 方向努力。通常最後的結果是，所有能猜的原因都猜得差不多了，但問題還是沒解決，大家也師老兵疲，連再繼續猜的力氣都沒了。這個現象恐怖的地方在於：解決問題通常不是一個人解決，而是一組人解決，要凝聚一組人的力量本來就不容易，但要破壞一組人的信心卻是簡單的不得了，只要當中一有人信心動搖，就會像病毒擴散一樣，一發不可收拾。所以，不作決策則已，一但作了決策，就要一舉中的。春秋時代曹劌論戰所說，一鼓作氣，再而衰，三而竭，就是這個道理。
在前幾篇文章中 (這一篇和這一篇) 有提到 C 公司現在遇到的最大問題或是最需要解決的問題是技術部門的結案速度大幅下降，我也已把解決這個問題當成是目前最重要的工作項目。但問題是，該如何解決？或者問，造成這個問題的原因是什麼？我們總得先知道問題的本質，才好找解決方法。經過三天的訪談，聽到的原因很多，例如，客戶會要求工程變更、客戶會對工程師作不合理的要求、硬體採購會延遲交貨、外包商的進度延遲、以及工程師的技術能力不足等等，但如果仔細問，那到底哪一種原因發生的頻率最頻繁？或是哪一種影響對交期的衝擊最大？麻煩了，沒人有把握。因為小公司的資源有限，不可能同時對每個可能原因都投入資源，因此，回答上述兩個問題，就變成一個很重要的工作。
為了回答這兩個問題，例行性的資訊蒐集就變得是必要的工作，唯有在資訊被完整蒐集的情況之下，我們才有可能進行統計與分析，找出問題的本質，並加以解決之。那要如何讓技術專案部門的夥伴們能夠做到例行性的資訊蒐集工作呢？答案就是專案日報及定期的專案日報檢討會議。專案負責人填寫日報，再由一專案管理者統一將各式問題通報給各相關負責負責解決的夥伴們知道，另外，專案管理者亦須負責整理並分析數據，找出導致專案結案速度不夠快的原因，並協助技術夥伴們解決。然後，在專案日報檢討會議上，專案管理的負責人可提出各式統計數據，讓專案負責人了解問題所在，並集思廣益共同找出解決方案。
由於最初的發想是為了要找出結案速度不夠快的原因，因此這份日報的設計最好就只要能夠讓夥伴們提出每天遇到的問題即可，其他的資訊蒐集就不用急著作，而且在設計上必須讓夥伴們容易填寫，不會增加太多的工作負擔，等到大家都習慣了填寫日報，再考慮置入其他資訊蒐集項目。
當然，請專案工程師寫日報不單單只為了蒐集資訊、找出問題，還會有一些其他衍伸出來的好處。例如，所有問題的解決者分派都可以在最短的時間內處理完，這個時間就是一天。另外，某些問題或許會造成交期上的延誤，公司有責任在最短時間內告知客戶，這個時間也是一天。另外，如果某些問題不是專案執行者本身可以掌控的，而且有可能會讓後續的專案工作無法執行，專案管理者也可以立即決定是不是要安排其他的專案工作來填補這段空下來的時間。
執行了專案日報是不是就可以保證結案速度可以提升，答案是不確定。但有一點可以確定的是，如果這件事不作，要讓結案速度提升，要嘛很難，要嘛就是要投入大規模資源才有可能做到。