Project Portfolio Management-Increase Your Capacity and Finish More Projects讀書報告

曾有位朋友跟我說他們公司有太多緊急事件要處理, 且每個人都要做很多專案, 排程幾乎只是參考用, 大家也不可能有空來寫issue, 做追蹤, 所以任何專案管理啦, 協同作業工具都很難派上用場. 我很納悶這樣的問題要如何解決....

最近剛好看到這本書Project Portfolio Management-Increase Your Capacity and Finish More Projects, 書中特別指出, 如果沒有做Project Portfolio Management, 將會不斷有Emergency出現, 這樣會降低整個portfolio的管理容易度, 造成不斷搶人的狀況, 將團隊成員完成專案的效率降低, 也降低完成專案的數量. 這跟朋友說的狀況很類似.
這幾天剛把這本書看完, 覺得這本書寫得太好了, 以下簡要整理, 希望對在類似工作環境的人有所幫助.

如果您的公司還沒有開始做公司等級的Project Portfolio Management(PPM)

也許可以跟公司建議試試看吧?

• 對工程師的好處: 當主管不斷壓工作下來時, 很有理由說現在什麼工作最重要, 或請找PPM核心主管討論吧.
• 對專案經理的好處: 不用和其他的專案經理搶人力, 到處求工程師幫你做, 因為先後順序已經排好了
• 對公司上層的好處: 大家全力做對公司獲利與未來遠景最有利的專案, 不會浪費公司資源

實行小建議

• 專案要排序, 且要決定哪些專案要commit, kill, transform, 或暫存待執行
• 如無法準確預估專案獲利與風險, 以Scrum分段deliver 部分user stories(requirements)的方式來試run, 預估velocity, 幫助forecast, 同時觀察可行性
• 越高風險但卻是高獲利的案子越需要小規模試run
• 專案資訊越透明完整, 越好做PPM
• 至少一季做一次Project Portfolio Review
• 以公司整體利益為指導原則做PPM決策
• 需檢查公司的bonus或薪資政策是否配合,如果專案經理的performance是比賽同時間內完成的專案數量, 那.....

Project Portfolio Review是PPM的重頭戲

Project Portfolio Review目的: 決定專案先後順序, 妥善安排資源, 全力完成對公司最有利的專案s.

Review參與者: 高層, 專案經理, 部門經理.

Review時間: 最好不要超過3個月, 當release時間需要修改時,當重要客戶需要新功能或產品時, 當知道競爭對手將有新產品上市時, 當技術更新時, 當產品可以部分完成時, 當資訊足夠到計畫下一版時, 當有錢有人來做新專案時.

Review需要的資料: 每個專案的內容, 相關客戶, brundown chart/velocity chart,階段可demo產品或version完成工作單, 風險與障礙, 人力分配

Review應問的問題:
排序的準則? （要配合公司目標, 策略, 願景, 獲利)
對於每個專案在每次review的時候都要問是否仍與整體策略相符, 值得繼續做下去?
從上次review到這次review之間, 到底完成了哪些? 進度如何? 完成速度怎樣?
專案進行是否有遇到什麼困難?

專案排序的方法

計分: 可考慮的項目如
Qualitative: Alternative有替代方案? Effect完成後的影響? Success Picture專案成功的樣子?
Quantitative:獲利? 市場拓展? 既有客戶再消費? 降低成本? 增加公司競爭力?

比較法: Single-Elimination Tournament單淘汰制, Double-Elimination Tournament雙敗淘汰制
p.s. 作者建議不要用ROI來排序, 因為ROI通常試算不準的

專案排序完後一定要公開讓全公司的人知道, 做為大家工作的先後順序標準

更詳細的資料請買本
Project Portfoilio Management-Increase Your Capacity and FInish More Projects

Tom DeMarco的Software Engineering: An Idea Whose Time Has Come and Gone? 摘要與感想

在Google搜尋時, 剛好在網路上看到Tom Demarco於2009 IEEE 七八月刊的作品: Software Engineering: An Idea Whose Time Has Come and Gone? 很欣賞他連之前的自己都可以否定的勇氣. 我相信越有名, 要說自己以前是錯的越困難.

他在此文對於自己1982年寫的Controlling Software Projects: Management, Measurement, and Estimation(Prentice Hall, Yourdon Press出版),這本啟蒙軟工專案計畫與度量發展的重要作品, 重新評價:
"Do I still believe that metrics are a must for any successful software devleopment effort? My answers are no, no, and no."

還自己說這本書所傳達的message有誤:
"The book's deep message seems to be, metrics are good, more would be better, and most would be best. Today we all understand that software metrics cost money and time and must be used with careful moderation."
"The book's most quoted line is its first sentence: You can't control what you can't measure. This line contains a real truth, but I've become increasingly uncomfortable with my use of it. Implicit in the quote(and indeed in the book's title) is that control is an important aspect, maybe the most important, of any software project. But it isn't. "

他從專案的本質：一個投百萬可賺1.1百萬的案, 和一個投百萬可賺50百萬的案相比, 獲利能力低的案子相對需要較高的control才能成功, 來說明並非每個案子都要一樣的control程度. 那是否獲利低的案子反而要花更多錢跟時間去做measurement, 那利潤不就更低了. 這是做低獲利案的惡性循環. 也回歸到business model的問題, 為什麼要接這樣低利潤的案子?

另一方面, 他也提出人的品質是無法度量的, 你可以度量honor, dignity, discipline, personality, grace under pressure, values, ethics, resourcefulness, loyty, humor, kindness這些嗎? 但事實上這些都深深影響到專案的performance. 所以DeMarco建議要做好專案就回歸人,時間和資源的管理. 在管理的方法上,雖然他很謙虛的說他沒什麼資格來建議軟體開發要用什麼方法, 不過他提倡agile的概念.

雖然他一再說度量, 可預測不是最重要的, 但仍相信軟體開發仍需要工程化, 但不要把on time和on budget當成最高準則. 那什麼是最重要的呢?
"The more important goal is transformation, creating software that changes the world or that transforms a company or how it does business."

我相信這是DeMarco殷切想讓大家不斷去回歸本質想"為什麼我要做這個專案?", "怎樣才能把事情做好?" 而不要因為要達到某專家說的最高境界, 而投入大量資源只為生出很多度量報告, 但忘了去評估做這些報告之於"原始目標" 幫助有多大? 哪些是必要的? 又哪些沒有必要?

如果Google當初是選擇運用搜尋引擎的技術接專案的方式, 今天大概沒有人知道Google是什麼吧. 這應該就是DeMarco在這篇文章一直強調的what is important.

最後, 不相關話題, 但相關Mr. Tom DeMarco
推薦DeMarco "最後期限"的專案管理的小說 有深度又很有趣！