專案管理軟體三要素：時間、質量、成本

工期緊，活兒只能湊合了；超支，趕緊砍內容，別弄那麼多；資源有限，人手奇缺，往後拖吧。這就是我們身邊專案運作時常發生的狀況。

    所有的專案經理都會做預算，都會設定檢查點，都知道又要無休止的協調。但真正執行起來，千變萬化的現實讓他們經常無所適從。這個時候一款簡單好用的專案管理軟體就會起到至關重要的作用。

    一般來說，管理者都希望專案完成的時間要快，完成的成本要低，完成後的質量要好。可是這三個要素是彼此互斥的。能夠完美做到以上三個要素的專案，少之又少。上世紀60年代初，肯尼迪總統下令要十年內把人送上月球，並安全帶回來。這個龐大的計劃，要快，必須趕在前蘇聯之前完成；要好，絕不能出現任何差錯；並且在預算上有限制。

    結果，在各方為這個專案大開綠燈之後，美國果真搶先把人類送上月球，並平安帶了回來。當然，我們平常的專案不可能集所有人力、物力、財力等所有資源，並且得到至高無上的尚方寶劍。

    因此，在一般的專案上，這三個要素，彼此之間是魚與熊掌的關係。要兼顧的難度，會按照幾何級數上升。這樣一個三角難題，我們怎麼去解呢？可以試著從兩方面著手。

    第一，先弄清楚什麼是“好”，什麼是“快”，什麼是“便宜”。

    什麼是好專案？一般來說，專案的結果使企業的收入增加、支出減少、服務加強，就是好專案。

    那麼，什麼是“快”？在專案管理上，時間是絕對的。專案經理最容易犯的錯誤，就是在完工日期的預測上，為了討好上司而儘量樂觀。同時，他們總用歷史資料或別人的經驗影響自己的預測，也使得專案工期的變化比較大。

    要達到預期完工的要求，專案經理要把一個規模大、時間長的專案，分成不同的階段完成。在每個階段，又要根據每階段不同的重點分別來做完工預測。工程分得越細，預測的準確性就越高。這道理很普通，但需要很周詳的計劃和分析。

    三個要素互相制約，找準一個平衡點，才能讓三者平衡。很多時候，由於外在和內在的壓力，取捨是免不了的。要做好取捨分析，專案經理要懂得六件事：

    第一，要很清楚地瞭解專案衝突的基本原因；第二，重新確認專案的目的；第三，瞭解專案現處的環境及目前狀況；第四，尋求可行的其它方法；第五，選擇最佳的其他方法；第六，重新策劃專案計劃。

工作分解咋控制？

    “計劃趕不上變化!”一個專案經理感嘆道。

    的確，專案中有相當多的不確定因素，專案經理辛辛苦苦做的WBS（工作分解結構），可能因為客戶的改變，甚至領導的一句話，就分崩離析了。一些公司高層沒有經過仔細考慮，也沒有充分徵求各個方面的意見，在制定總體計劃時比較隨意，修改起來更是“信手拈來”。專案經理也常常藉口工作忙等理由，拖延制定詳細的WBS，甚至有專案經理認為，不應該制定詳細的WBS。

    而沒有詳細WBS的危害也是明顯的：造成計劃與控制管理脫節，無法進行有效的進度控制管理，最終導致專案延期或成本上升。可以說，沒有WBS或者是隨意的不負責任的WBS的專案是一種無法控制的專案。面對各種潛在的變化，專案經理應該怎樣制定WBS呢？

    首先專案經理應該對WBS有正確的認識，制定WBS就是一個對專案逐漸瞭解掌握的過程，透過這個過程，專案經理可以知道哪些要素是明確的，哪些是要逐漸明確的，透過漸近明細不斷完善。漸近明細也是專案的一個特點，因此WBS的制定需要在一定條件的限制和假設之下采用漸近明細的方式進行不斷完善。

    再者，制定WBS需要有一個現實的方法。一個大型的軟體開發專案，通常是採用二次WBS方法。即根據總體WBS，在需求調研階段結束、概要設計完成後，再專門針對詳細設計或編碼階段制定二次WBS。

    一個方面，需求的顆粒度在一開始往往是比較粗的，因此根據功能點對於整體專案規模的估計誤差範圍也是比較大的，只能據此制定總體的WBS。另一個方面，需求和編碼工作分解不是一一對應的，一個需求的功能點可能對應多個程式碼模組，而多個需求的功能點也可能只對應一個或少數程式碼模組。只有在概要設計完成以後才能準確地得到詳細設計或編碼階段的二次WBS。

    例如，某系統整合公司與銀行簽訂了一個銀行前置機的軟體系統的專案。合同規定，6月28日之前系統必須投入試執行。專案經理小丁組織大家制定了專案的WBS，並制訂了本專案的進度計劃，簡單描述如下：

    1.應用子系統：1月5日～2月5日需求分析，2月6日～3月26日系統設計和軟體設計，3月27日～5月10日編碼，5月11日～5月30日系統內部測試；

    2.綜合佈線：2月20日～4月20日完成調研和佈線；

    3.網路子系統：4月21日～5月21日裝置安裝、聯調；

    4.系統內部除錯、驗收：6月1日～6月20日試執行，6月28日系統驗收。

    2月17日，小丁發現系統設計剛剛開始，由此推測3月26日很可能完不成系統設計。小丁應該如何做，以保證專案整體進度不拖延呢？

    小丁編制的這個WBS比較粗糙，不適合作為編織專案計劃的基石。只有一個專案的大概框架和子系統各部分的期望完成時間。從該WBS上面可以看出最底層任務的工期至少也在半個月左右。如果任何一個任務出現了問題，就必然會出現小丁現在遇到的問題，即延期和延期發生了較長時間才知道。

    在這種情況下，小丁最好是制定二次WBS。最終分解任務的工期最好不要長於一週，否則可能出現失去控制的情況。而且，在不同階段應該有具體直接的責任人。作為專案經理，小丁需要保持與某階段的直接責任人溝通，瞭解進度、發現問題。

稀缺資源怎麼搶？

    小閻剛被任命為公司某橋樑設計專案的專案經理時，內心喜悅之情難以言表。可是才過了不到半個月，面對“溝通複雜化”、“資源爭奪戰”，他已愁容滿面，這是怎麼回事？

    原來，公司為這個專案組建專案組時，人力上，核心組員一共才5人，其中還有兩位由於來自公司其他部門，時常被其所在部門領導臨時派活；經費上，公司沒有下放任何許可權，所有專案開支仍然要經過公司研發主管、財務部門、公司總裁一系列的審批程式；物質上，專案開發過程中，需要的實驗場所、器材等還需要不停地和其他部門與專案組協調使用。這一系列問題讓原本是公司技術尖刀的小閻，在具體實施專案建設時，可利用的資源常常捉襟見肘。

    是小閻自己能力有限，還是公司管理混亂？小閻曾一度十分懷疑自己的管理能力，為了給自己充電，考試/大專門報了一期專案管理培訓班。培訓結束後，小閻發覺不是自己能力出了問題，而是公司在專案管理機制上出現了問題。

    小閻的公司將各項資源調配的權力，牢牢地把握在公司各個部門手中，公司所有專案在實施過程中，專案經理的實際權力相當有限，有時連自己專案組內成員的工作分配都常常遭遇困難。來自其他部門的臨時組員，由於各項管轄關係仍然隸屬於其部門主管，常常對小閻分配的工作不以為然。而在資金與物質調配上，面對公司的後勤、行政、財務等諸多主管部門，小閻更是無可奈何。

    其實，小閻的遭遇與國內許多公司的專案經理遭遇非常相似。在國內的許多國有、民營企業內，專案經理在企業中的地位往往比較弱勢，企業中的各項資源仍主要控制在職能部門手中，專案經理雖然直接對專案的成敗負責，但卻缺乏相應的權力。

    許多企業的管理層對專案管理的價值相當模糊。傳統模式中，資源大都為職能部門所控制，面對資源調配時，專案經理的權力處處受限。傳統的管理模式導致了許多專案上馬後，或是長期無法完成，或是成為“半吊子”工程，乃至最後以失敗告終。企業要想其各個專案快速併成功實施，就必須對企業各項業務實施專案化管理，儘可能將企業的資源實現最最佳化分配。

    要實現資源最佳化，企業就要面對多專案協調、部門協調等問題。如果實行各專案的獨立管理模式，往往會出現各專案之間無法很好協調，極容易造成相互推拖和扯皮。而缺乏職能部門間的協調，往往會導致管理錯位、資源配置滯後，嚴重阻礙專案實施和管理。

    面對多專案管理，企業要透過建立專案管理軟體，透過優先順序評價體系等方式，按專案組合管理的理論，使專案的組合和資源劃分更加反映企業的整體戰略目標。對於相互間有關聯的專案，還應當注重協調與溝通機制的建立，以使宏觀的規劃與協調更加合理與最佳化。

    而對於部門間的溝通，企業須逐步建立起有效的溝通機制，使得專案團隊與職能部門之間、部門與部門之間、專案與管理層之間的溝通與協調製度化和流程化。這是整個專案管理軟體的一個重要組成部分。資源的協調、風險的監控以及團隊的建設都要依靠這一機制得以實現。