哈米尼斯的天空

最近剛好在忙著寫一份企劃書，所以比較沒有時間顧到Blog，先跟大家致歉，也跟大家分享一下我這次寫企劃書的心得。
在分享心得前，我們先討論一下「專案企劃書」的定位和用途
定位大概蠻清楚的，就是用來表達整個專案的輪廓，大致上的規劃及成本，可以把它想做是PMBOK中所提的SOW(Statement Of Work)。
但是在用途上，這裡意見可能大家的看法就會有所不同了，我所認知的「專案企劃書」，它必須要涵蓋了「規劃」的內容、「執行」的準則、「控制」的方法、「結案」的內涵。

規劃的內容很明確的指出為什麼要做這一個專案、它的目的、目標、預期產出、還有「專案的假設」條件為何，甚至還需要提供分析和證據來證明這一個專案的可行性和價值；如果是公司內部的專案，更應該附上「Project Charter」。

執行的準則，這裡大家應該都不會有問題，需要明確指出Scope，指出需要做那些工作(利用WBS或甘特圖)，明確講出時程、執行方法(例如切幾個Phase，每個Phase要做啥，進入/結束這一個Phase的條件)，同時也要講明執行專案的組織架構：由誰來做、做什麼、管什麼，簡單講就是RAM，定義出角色、責任、權力等等(如果只有定義到角色和責任執行起來還是會有問題的喔，要注意)
甚至有些案子的人力或部份內容是要做外包的，那也要定義出如何建立這一個專案團隊或是找下包廠商(如何招標、領標、決標等等)
而成本是如何預估的，計算的原則、方法、還有假設條件及限制條件等等(這一塊是我很弱的地方，不過我正努力學習中)

控制的方法，這裡主要講的是關於品質、風險、溝通以及如何面對「專案變更」
品質的部份，必需要講出你的品質標準為何，如何做QA、QC、測試的guildline、問題等級的分類及處理原則等等(說真的這個以前我也不太寫的，不過就是因為沒有被定義出來，所以品質就很容易出問題)
風險的部份，其實我以前也不寫的，所以常常出包，真得建議大家「有寫有保庇，沒寫容易出代誌」，風險要寫啥？第一個是可能會影響專案的風險(不過不是找100項就寫100項，而是寫出非你或你的團隊可以解決的部份；有些也許可以被解決，但是它實在太關鍵了，也請你標註出來)，分優先順序、進入或產生風險條件，處置方法，以及每多久Review風險(風險和進度一樣，都要Review，而且要請客戶參加，這樣責任才說得清楚)
再來就是溝通的部份，這個我以前也不太著墨的，頂多就寫個定期舉辦專案的Review，這樣夠嗎？當然不夠，要定義出來專案執行的過程中，會開那幾種會，會議記錄由誰撰寫、由誰管理、時間為何、使用的文件為何等等，教育訓練的實行方式(教育訓練也算是一種溝通吧？)、實行方法、需要客戶Support的部份；而對於內部的專案還要多寫出是不是使用文件控管的工具、誰有權限、如何取得等等。
只要是做專案，就一定會有「變化」，所以與其變化時才來手忙腳亂，不如預先規劃好，大家也有共識，這裡要定義什麼是變化、變化的流程、表單，如何記錄變化等等。

終於到了結案的部份，結案的部份需要寫出來驗收條件、驗收方法、移交項目、移交方法、保固條款、保固範圍及做法以及這一個專案需要記錄的Lesson Learn是什麼，其中移交的項目可能會包含系統本身、操作手冊、technical的手冊、support的手冊等等(這裡我是用軟體的專案當例子)，而大家最容易輕忽的，就是Lesson Learn的部份，我也不太重視這件事，不過我就嚐到了苦果，Lesson Learn當然不是要交給客戶，可是只要累積下來，這是一個非常可貴的資產，未來，在進行類似的專案時，你就會有很好的資料可以用來預估、判斷，只要看一家公司有沒有累積Lesson Learn就可以知道這公司賺不賺錢，你相信嗎？

您可以仔細對一下，幾乎就是5大流程+9大知識領域的範圍
以上大概是我簡單分享一下我的心得，如果不嫌棄的話，歡迎大家提出問題討論