專案為何總是做不完?範圍管理要界定(轉)

ger8發表於2007-08-10
做過專案的人可能都會有這樣的經歷:一個專案做了很久,感覺總是做不完,就像一個“無底洞”。使用者總是有新的需求要專案開發方來做,就像使用者在“漫天要價”,而開發方在“就地還錢”。實際上,這裡涉及到一個“範圍管理”的概念。專案中哪些該做,哪些不該做,做到什麼程度,都是由“範圍管理”來決定的。那麼,到底什麼是“範圍管理”,請跟我們一塊來揭開謎底。

  幾年前,我和一位同事在外地共同參與一個軟體專案的開發。專案本身並不算很大,開始的需求調研進行了很長時間,期間不但幾乎拜訪了所有部門,還與使用者反覆討論,徵求意見,需求文件幾易其稿。即便這樣仍然有許多不確定因素,搞得人心煩意亂。當時我牢騷很多,總覺得又花時間似乎還沒真正做事。

  我的同事經驗比較豐富,他給我說了一個他自己的親身經歷。那時候他在深圳參與一個證券專案,當時軟體開發管理非常不規範,基本上是瞭解需求後就程式設計序,根本沒有太多的交流,需求文件就更沒有了。系統開發出以後,使用者不斷提出新需求。每天追著開發人員解決問題,專案實際是一個無底洞,沒完沒了地往下做,按他的說法是專案成員“肥的拖瘦,瘦的拖死”,實在做不下去只能跑了。

  這個故事剛聽起來感覺非常可笑,當我自己真正做專案負責人時才體會到這其實是一個專案範圍管理的問題。上面提到我所參與的專案中花費大量時間用於需求調研也是為了確定專案範圍。作為一個合格的專案經理,切記要準確控制好專案範圍。孫子兵法中提到“知己知彼,百戰不殆”,在一個專案中我們應該知道對方需要什麼,自己要做什麼,這是專案成功的基礎所在。那麼,首先要明確的是專案範圍管理中的範圍是如何定義的?

  什麼是範圍?

  我們知道專案是為完成產品或服務所做的一次性努力。因此在這裡,範圍的概念包含兩方面,一個是產品範圍,即產品或服務所包含的特徵或功能,另一個是專案範圍,即為交付具有規定特徵和功能的產品或服務所必須完成的工作。在確定範圍時首先要確定最終產生的是什麼,它具有哪些可清晰界定的特性。要注意的是特性必須要清晰,以認可的形式表達出來,比如文字、圖表或某種標準,能被專案參與人理解,絕不能含含糊糊、模稜兩可,在此基礎之上才能進一步明確需要做什麼工作才能產生所需要的產品。也就是說產品範圍決定專案範圍。

  舉例說明可能會更好理解一些。假設你在一家培訓公司做培訓專員,負責組織一次PMP(美國專案管理專業人員認證)考前培訓。那麼我們完全可以把這項工作當成一個專案來管理,如何確定產品範圍和專案範圍呢?培訓產生的不是有形的產品,而是無形的服務。組織PMP考前培訓的目的是講授專案管理體系基礎知識,提高學員的專案管理理論水平,為參加PMP考試做準備,這就是產品範圍。如果學員突然提出想獲得如何提高企業核心競爭力的知識,很明顯此內容不在本專案的產品範圍之內。有了明確的產品範圍,接下來就可以確定為達到這個目的需要做哪些工作,即專案範圍。首先要聘請知名的專案管理權威專家,擬訂授課內容,根據授課內容準備學員教材,聯絡舒適的培訓地點,安排好學員食宿。開始培訓也並非萬事大吉,每天都要與學員交流,聽取他們的意見並反饋給老師,甚至學員的日常起居都要過問。由於PMP考試是英文試題,而模擬習題都是中文,假設某些學員希望講解一些英文題以避免翻譯帶來的理解偏差,這時老師就要多講一些內容,產品範圍有所擴大,但從總的培訓目標看是合理的。

  如何做好範圍管理?

  範圍管理保證專案包含了所有要做的工作而且只包含要求的工作,它主要涉及定義並控制哪些是專案範疇內的,哪些不是。範圍管理的基本內容包括:專案啟動、範圍計劃編制、範圍核實、範圍變更控制等等。以下所討論的是其中比較重要的部分。

  1.編制範圍計劃

  “公欲善其事,必先利其器”。一個專案經理要想真正管理好專案範圍,沒有必要的技術和方法是肯定不行的。國外曾經有人對專案失敗原因進行調查,其中計劃被放到了首位,可見它在專案管理中的重要性。

  我們這裡首先強調的就是周密地做好範圍計劃編制。範圍計劃編制是將產生專案產品所需進行的專案工作(專案範圍)漸進明細和歸檔的過程。做範圍計劃編制工作是需要參考很多資訊的,比如產品描述,首先要清楚最終產品的定義才能規劃要做的工作,專案章程(典型的例子是合同)也是非常主要的依據,通常它對專案範圍已經有了粗線條的約定,範圍計劃在此基礎上進一步深入和細化。

  範圍計劃中究竟應該包含哪些內容呢?不同的計劃詳盡程度自然不一樣,其中範圍說明和範圍管理計劃必須包含在內。

  範圍說明在專案參與人之間確認或建立了一個專案範圍的共識,作為未來專案決策的文件基準。範圍說明中至少要說明專案論證、專案產品、專案可交付成果和專案目標。專案論證是商家的既定目標,要為估算未來的得失提供基礎;專案產品是產品說明的簡要概況;專案可交付成果一般要列一個子產品級別概括表,如:為一個軟體開發專案設定的主要可交付成果可能包括程式程式碼、工作手冊、人機互動學習程式等。任何沒有明確要求的結果,都意味著它在專案可交付成果之外;專案目標是要考慮到專案的成功性,至少要包括成本、進度表和質量檢測。專案目標應該有標誌(如:成本、單位)和絕對的或相對的價值(如:少於150萬美元等)。不可量化的目標(如:“客戶的滿意程度”)要承擔很高的風險。

  範圍管理計劃是描述專案範圍如何進行管理,專案範圍怎樣變化才能與專案要求相一致等問題的。它也應該包括一個對專案範圍預期的穩定而進行的評估(比如:怎樣變化、變化頻率如何及變化了多少)。範圍管理計劃也應該包括對變化範圍怎樣確定,變化應歸為哪一類(當產品特徵仍在被詳細描述的時候,做到這點特別困難,但絕對必要)等問題的清楚描述。

  2.範圍分解

  計劃明確了,然而該做哪些事情似乎還是一把抓,因為完成專案本身是一個複雜的過程,必須採取分解的手段把主要的可交付成果分成更容易管理的單元才能一目瞭然,最終得出專案的工作分解結構(WBS)。恰當的範圍定義對專案成功十分關鍵,當範圍定義不明確時,變更就不可避免地出現,很可能造成返工、延長工期、降低團隊士氣等一系列不利的後果。

  比較常用的方式是以專案進度為依據劃分WBS,第一層是大的專案成果框架,每層下面再把工作分解,這種方式的優點是結合進度劃分直觀,時間感強,評審中容易發現遺漏或多出的部分,也更容易被大多數人理解。Microsoft的專案管理工具Project就可以自動為各個層次的任務編碼。

  3.範圍變更

  一個專案的範圍計劃可能制訂的非常好,但是想不出現任何改變幾乎是不可能的。因此對變更的管理是專案經理必備的素質之一。變並不糟糕,糟糕的是缺乏規範的變更管理過程。範圍變更的原因是多方面的,比如使用者要求增加產品功能、環保問題導致設計方案修改而增加施工內容。專案經理在管理過程中必須透過監督績效報告、當前進展情況等來分析和預測可能出現的範圍變更,在發生變更時遵循規範的變更程式來管理變更。我們強烈建議企業的專案管理體系中包含一套嚴格、高效、實用的變更程式,它對管好專案至關重要。[@more@]

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/7839396/viewspace-941319/,如需轉載,請註明出處,否則將追究法律責任。

相關文章