專 案 管 理 輕 鬆 學

只要流程界定清晰，專案經理就能保證專案的發展方向與最終目標相契合。廣義而言，要掌控各種類型專案的發展，首先要關注十個關鍵的流程。

一、生命周期與方法論

專案的生命周期與方法論，是專案的紀律，為專案開展劃出了清晰的界限，以保證專案進程。生命周期主要是協調相關專案，而方法論為專案進程提供了持續穩定的方式方法。

生命周期通常由專案的階段組成(包括：開始、規劃、執行/控制、完成)，或由工作的重複周期構成。專案生命周期的細節一般都會隨具體業務、專案、客戶要求而改變。因此即使在同一個專案中，周期也會有多種可能的變化。對工作細致度、文件管理、專案交付、專案溝通的要求體現在生命周期標準和考核的方方面面。大專案的階段一般更多更長，而小專案的階段少，考核點也少。 與生命周期類似，專案方法也因專案而易，細節關注程度高。產品開發專案的方法經常涉及使用何種工具或系統，以及如何使用。

ERP(Enterprise Resource Planning：企業資源計劃)的普及化是件好事情，但普及化帶來的客觀結果與主觀美好的願望有可能嚴重不符。如何使ERP與企業的資源相匹配？如何加強軟體廠家與企業的精細密切的合作？如何實現ERP與企業的成功嫁接？別無它法，惟有精細化。

企業應用ERP必須從大處規劃，從細處著手。ERP的精細化，不像普及化那樣是站在廠商的角度侃侃而談，而是站在客戶的角度來考慮怎樣才能應用ERP取得具體實效，以及ERP如何與企業的個性化管理實踐等細節層面相結合。

施工管理工作是保證施工管理按質、按時完成，取得較好經濟效益的關鍵性工作，管理的好壞，直接影響施工管理各項指標的落實。本人曾多次參加工程施工，現就施工管理管理技術進行粗淺的探討。

專案的定義是為創造獨特的產品、服務或成果而進行的臨時性工作。請注意定義中的兩點，一是獨特的產品、服務或成果，即專案要有一個成果，這個成果是可控的，不能無限放大;二是臨時性工作，即專案是有時效性的，與專案成果是匹配的，這也印證了專案成果必須是可控的，不能無限放大而失控。專案範疇、時間、成本是專案約束三角形，當一個發生變化時，其他兩個中至少一個會跟隨變化。我認為困擾我們最大的就是範疇管理，客戶對需求本身的不確定性和經常變更，對我們的範疇管理帶來了很大的困擾，從而又引起了進度控制(時間管理)困難，進而增加專案成本。因此，在此我想主要談一談範疇管理。

在很多實踐專案中，專案的第一責任人—專案經理往往沒有非常充足的權力，即使在專案化水平比較高的組織中，專案經理缺乏權力也是常見的情況。這與專案經理的崗位特點分不開：那些有經驗、有能力的骨幹員工，往往是專案經理的優先人選。

專案工作要想順利的執行，最關鍵的環節就是各項工作職責的分配。如果WBS中的每一個工作包都能有明確的責任人，並得到相關責任人的認可和承諾，那麼專案工作的執行就會順利的多。通常，責任分配矩陣是實現這一功能的有效工具。在分配職責的時候，最理想的情況是團隊成員自己主動“認領”工作職責。自己認領，相當於做出承諾，這些工作的執行將得到最大程度的保證。但是一定有些工作活動沒有人主動承攬，這時專案經理就必須搞清楚原因，為什麼沒人對這些工作感興趣。

IT公司有時就像一個妙齡少女，特追求物質的那種，甲方就像貌似“闊少”的帥哥。當少女看到闊少後，急於把自己嫁出去，就以色相勾引。那闊少也是來者不拒，因此很快就兩情相悅，“非法”同居。過些歲月，感情順利，明媒正娶也是一件美事。可天有不測風雲，那貌似闊少的也許一朝露出馬腳，是個窮光蛋;也許移情別戀，與他人圓滿。那少女豈不鬱悶，因此在同居階段少女也很苦啊，不知道怎麼樣才能成全美事。

範疇管理是為了確保專案包含了所有要做的工作而且只包含要求的工作，它主要涉及定義並控制哪些是專案範疇內的，哪些不是。範疇管理的基本內容包括：專案啟動、範疇計畫編制、範疇定義、範疇確認、範疇變更控制這五個要素。

由於專案啟動比較獨立，因此在本文中將不予討論，以下所討論的是在確定專案啟動後的工作，這些工作包括：範疇計畫編制、範疇定義、範疇確認和範疇變更這四個的部分。

1、了解專案管理的背景情況

成為一個成功的專案經理所面臨的大部分困難來自於專案經理對公司內部各種挑戰的理解和認識。專案是組織的一種特殊形式，它們是一種機制，促進了一種產品和服務推向市場的效率。但是，它們還迫使專案經理在傳統型、職能化的權利鏈之外，是在一種臨時性的環境中運作的。從本質上講，它們不是單純地對專案進行管理，而是對專案經理的獨特挑戰，其特殊環境構成了一種附件的困難。專案遊離於組織原有的等級結構之外。

在今天的市場經濟環境下，競爭越來越激烈，為了提高競爭能力，滿足市場要求，需要不同企業或者實體針對不同的需求成立的專案降低成本，明確工作範疇，確立自己的競爭地位，顯得異常關鍵。

專案範疇包括專案的最終產品或者服務，以及實現該產品或者服務所需要執行的全部工作。明確規定專案的範疇，即確定了專案的哪些方面是應該做的，哪些是不應該做的。也可以說是產生專案產品所包括的所有工作及產生這些產品所用的過程。專案利害關係人必須在專案要產生什麼樣的產品方面達成共識，也要在如何生產這些產品方面達成一定的共識。

所有的活動組織者都面對著風險，在本章中我們將審視可行的途徑來確定、分析、歸類、降低並監控各類風險。

首先，我們應確定風險管理定義。風險是事物可能發生向反面轉變的可能性。

活動專案的組織者們常把風險視為對安全和安定的威脅。

範疇確認是客戶等專案利害關係人正式驗收並接受已完成的專案可交付物的過程。也稱範疇確認過程為範疇核實過程。專案範疇確認包括審查專案可交付物以保證每一交付物令人滿意地完成。如果專案在早期被終止，專案範疇確認過程將記錄其完成的情況。　　

專案範疇確認應該貫穿專案的始終。範疇確認與品質控制不同，範疇確認是有關工作結果的接受問題，而品質控制是有關工作結果正確與否，品質控制一般在範疇確認之前完成，當然也可並行進行。

範疇確認又稱移交或驗收。專案或專案階段結束時，專案團隊在將專案最終交付成果交給使用者或接受者之前，接受方要對已經完成的工作成果重新進行審查，查核專案計畫規定範疇內的各項工作或活動是否已經完成，應交付成果是否令人滿意。如果專案提前結束，則應查明有哪些工作已經完成，完成到了什麼程度，並將核查結果記錄在案，形成檔案。　　

對於一名專案經理來說，做出讓客戶滿意地產品是我們的終極目標。但實際情況會是這樣嗎？現實，我們在專案開發過程中會遇到各種問題。

績效對一個公司來說就像神經對於人一樣，神經正常人的身體才能保持健康。

專案績效評價的主要內容包括：回顧專案實施的全過程、分析專案的績效和影響、評價專案的目標實現程度、總結經驗教訓並提出對策建議等。同樣的標準不可能放諸四海皆準。

IT專案與傳統專案的區別

傳統的專案需要經歷的時間長，使用的是有形資源，專案成果是通過對資源的消耗與形態的轉化來逐步實現的。IT專案的實質是“知識轉移”， 專案是以無形的智力產品為專案目標。典型的IT專案是IT系統的建造(如系統集成)和軟體開發專案。

因此說，IT專案的實質是“知識轉移”，而建造專案的實質是“資源消耗”。當然，並非說IT專案中不存在“資源消耗”，也不是說傳統專案中沒有“知識轉移”。這一點應該得到辨證的理解。

積極溝通對任何專案而言，在起始階段就必須定下開發和合作的溝通機制，這一點很重要。在專案啟動後要有效地實行開放溝通。專案出現失敗的跡象時，開放的溝通管道更是不可或缺。專案管理者要跑到利益相關者的辦公室去，解釋該專案為什麽行不通。要告訴別人專案會失敗不是件容易的事，但如果已經有了良好溝通的基礎，至少可以使一件不容易的事變得稍微容易一點。

當危機專案管理到來之時，作為領導者應是臨危不亂、從容應對，要善於駕禦危機，要把危機有效地轉變為工作的轉機。危機對於一個組織和政府來說，可能是災難，也可能是轉機。相對於行政組織的日常工作來說，突發事件實屬意料之外之事。危機的到來，破壞了組織係統的穩定與常態，迫使其重新進行抉擇，挽回損失，樹立新形象。這要求領導者既要敢於負責又要大智大勇，具有多方面危機決策的素質與危機專案管理能力。