一個方面,需求的顆粒度在一開始往往是比較粗的,因此根據功能點對于整體項目規模的估計誤差范圍也是比較大的,只能據此制定總體的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人,其中還有兩位由于來自公司其他部門,時常被其所在部門領導臨時派活;經費上,公司沒有下放任何權限,所有項目開支仍然要經過公司研發主管、財務部門、公司總裁一系列的審批程序;物質上,項目開發過程中,需要的實驗場所、器材等還需要不停地和其他部門與項目組協調使用。這一系列問題讓原本是公司技術尖刀的小閻,在具體實施項目建設時,可利用的資源常常捉襟見肘。
是小閻自己能力有限,還是公司管理混亂?小閻曾一度十分懷疑自己的管理能力,為了給自己充電,專門報了一期項目管理培訓班。培訓結束后,小閻發覺不是自己能力出了問題,而是公司在項目管理機制上出現了問題。
小閻的公司將各項資源調配的權力,牢牢地把握在公司各個部門手中,公司所有項目在實施過程中,項目經理的實際權力相當有限,有時連自己項目組內成員的工作分配都常常遭遇困難。來自其他部門的臨時組員,由于各項管轄關系仍然隸屬于其部門主管,常常對小閻分配的工作不以為然。而在資金與物質調配上,面對公司的后勤、行政、財務等諸多主管部門,小閻更是無可奈何。
其實,小閻的遭遇與國內許多公司的項目經理遭遇非常相似。在國內的許多國有、民營企業內,項目經理在企業中的地位往往比較弱勢,企業中的各項資源仍主要控制在職能部門手中,項目經理雖然直接對項目的成敗負責,但卻缺/ 許多企業的管理層對項目管理的價值相當模糊。傳統模式中,資源大都為職能部門所控制,面對資源調配時,項目經理的權力處處受限。傳統的管理模式導致了許多項目上馬后,或是長期無法完成,或是成為“半吊子”工程,乃至最后以失敗告終。企業要想其各個項目快速并成功實施,就必須對企業各項業務實施項目化管理,盡可能將企業的資源實現最優化分配。
要實現資源優化,企業就要面對多項目協調、部門協調等問題。如果實行各項目的獨立管理模式,往往會出現各項目之間無法很好協調,極容易造成相互推拖和扯皮。而缺乏職能部門間的協調,往往會導致管理錯位、資源配置滯后,嚴重阻礙項目實施和管理。
面對多項目管理,企業要通過建立項目管理知識庫,通過優先級評價體系等方式,按項目組合管理的理論,使項目的組合和資源劃分更加反映企業的整體戰略目標。對于相互間有關聯的項目,還應當注重協調與溝通機制的建立,以使宏觀的規劃與協調更加合理與優化。
而對于部門間的溝通,企業須逐步建立起有效的溝通機制,使得項目團隊與職能部門之間、部門與部門之間、項目與管理層之間的溝通與協調制度化和流程化。這是整個項目管理機制的一個重要組成部分。資源的協調、風險的監控以及團隊的建設都要依靠這一機制得以實現。
中國空間技術研究院在項目管理上經驗獨到。2001年,研究院開始在全院推行項目化管理。隨著研發任務的增多,大量的協調工作也隨之而來。各項目都希望占用盡可能多的資源,這也給研究院的調配工作帶來很大麻煩。為此,研究院專門設立了項目管理辦公室(PMO)負責項目的管理、協調工作。