導讀：文中介紹對於項目管理的一些技能改進之處，可以提高管理的效率巧妙之處，並詳細的列舉出管理中的十個過程。
小型項目的管理者並不需要過多的項目管理知識和項目管理技巧的訓練。但是，一旦項目的規模變大了，這些正規的管理過程和技巧就是
項目管理者必備的了。雖然不同的項目管理方法以不同的方式組織並且說明了這些項目管理過程，但是我們還是想強調其中最基本的10個過程：
1. 定義項目範圍
2. 制定工作計劃
3. 管理工作計劃
4. 問題管理
5. 範圍管理
6. 風險管理
7. 溝通管理
8. 文檔管理
9. 質量管理
10. 度量管理
一般來說，如果你能掌握這10個領域的知識，你就能在大部分的項目管理中獲得成功。對於小項目，你可能不需要爲文檔或是度量管理而擔心。但是，你管理的項目越大，你就越需要重視這10個過程的管理。
你可能已經注意到我們列出的10個管理過程中沒有包括分析、設計、測試或者部署。那些有些項目工作經驗的人也許知道一個項目通常會包括分析和測試過程。然而，實際上這些過程有很大的差別。分析和測試過程是實際項目進程（也稱爲項目生命週期）的一部分。隨着項目類型的變化，項目生命週期包含的階段也不同。如果你的項目是一個具有完整的生命週期的項目，你也許就會執行從分析、設計、構建、測試到部署的全過程。而在其它類型的項目中，你可能只會涉及到其中某些階 段。例如，如果你的項目是一個調查研究項目，你就不會涉及到部署的問題。如果你在做一項研究，在做完分析階段的任務後，這個項目可能就會結束了。
我們還遺漏了什麼？
兩個管理過程有時也會做爲基本的項目管理過程的一部分：人員管理、合同和採購管理。對於項目經理來說，人員管理是非常重要的技能，但是對於項目管理來說，它並不是必需的。畢竟，在任何對下級的管理中都需要涉及人員管理。這其中的區別就是，人員管理是一種項目“經理”需要具備的技能，而不是項目“管理”必需 的技能。
在我們這10個項目管理過程列表中也沒有包括合同和採購管理。在大多數組織中，項目經理需要了解對合同和供應商的管理情況，但是他們並不對此負責。法律部門和（或）採購部門通常負責合同和供應商的管理。
時間安排和過程的順序
除第一類和第二類——定義項目範圍和制定工作計劃——之外，這10個主要的項目管理領域並不是一個順序執行的過程。從過程3到過程10，你可以按任意順序來 執行。而且，實際上，它們在整個項目中都是並行的，並且是從項目開始到項目結束一直都在進行的。例如，如果項目出現了一個重要的問題，你就必須忽略掉問題出現之前、出現期間或是出現之後你使用的項目管理的其它過程，而馬上使用問題管理過程。讓我們來仔細看看每一個管理過程吧。
1. 定義項目範圍
做 爲一個項目經理，你必須在項目開始前確定項目的各項工作是容易被大家理解的，並且已經得到了項目發起人以及關鍵的項目利益相關者們的同意。你需要和發起人、項目利益相關人一起討論這些工作，以確保項目團隊和客戶對於項目的交付物、項目完成的時間、項目的成本、項目執行團隊、項目的完成方式以及最終獲得的 利益達成一致的認識。
從項目管理的高層看來，定義項目工作的目的包括：
——理解項目目標、可交付物、範圍、風險、成本、方法並且達成一致。這是定義項目工作中最重要的部分，並且大部分的時間都會花在達成一致上。
——判斷初始的業務案例是否仍然是正確的。例如，一個需要花費1萬工時的項目可能具有商業意義。但是，如果定義工作的過程過於詳細，就會導致超過2萬小時的精確估算時間，這樣這個項目可能就不再可行了。
——確保那些你需要的資源在你需要的時候是可用的。
——制定一個高層次的項目基線。依靠這個基線，項目相關人員可以比較各個過程的執行情況，也可以控制項目的範圍。
——與客戶在這個項目所使用的管理過程上達成一致。
需要花費在定義項目工作上的精力取決於需要讓項目相關人員理解和文檔化的信息量的多少。需要花費在定義項目工作上的時間取決於瞭解和文檔化這些信息所必需的時間長短，也取決於需要花費在獲得客戶的同意和認可上的時間長短。
對於大型複雜的項目來說，準確的定義出最終的可交付物可能是非常困難的；估計出項目總成本和最終的交付日期也是很困難的。如果你管理的是大型複雜的項目，你可以把整個項目分成幾個小型項目。在這些小項目中，需要先做的小項目應該更容易定義出它們的各項工作。那些在未來需要完成的小項目可以在快執行的時候再詳 細定義出各項工作。
在定義項目範圍結束的時候，你應該制定出一份《項目定義》。這份文檔從項目的目標、可交付物、範圍、風險、交付日期和項目人員角色等各方面定義了項目的所有期望。這份文檔應該在項目團隊開始執行項目之前獲得項目發起人和其他關鍵的項目干係人的正式批准。
2. 制定工作計劃
在你定義項目的時候，你要確保和項目發起人在項目應該完成的所有工作內容上達成一致意見。在制定工作計劃這一階段，你將確定完成這些工作的方式。這就需要制定《項目計劃》。根據項目的規模，你要採取不同的方法。例如，制定小型項目的工作計劃可以使用像Microsoft Project這樣的項目管理工具包、電子製表軟件，甚至一張紙。
如果在你開始做計劃的時候，你還沒有可用的工作計劃模板，你可以使用工作分解結構（WBS）。WBS是一種技術，它從項目的高層次將工作分解成越來越小的部分，直到項目管理者獲得項目工作的完整視圖。整個項目團隊在此基礎上一起工作。我建議將工作分解到較低級別，分解到完成每個不再分解的活動所需的時間不多於80小時，並且完成這個活動所需要的資源也是十分清晰的。
一旦你把所有的工作都分解成活動，你就可以將這些活動排個順序並且確定它們之間的依賴關係。這時，WBS就轉變爲網絡圖（Network Diagram）。
然後，你需要給每個活動添加資源（即工作人員）。如果你知道某些資源的確切的名字，你可以以名字添加他們。如果你不知道，你可以使用通用名來佔位。接着，你需要爲每個活動添加工時及開始、結束日期。
現在，你的工作計劃已經準備好了。你可以清楚地瞭解到你要完成的工作內容（《項目定義》）以及你要如何完成這些工作（《項目計劃》）。
項目定義和項目計劃之間的關係
你會發現，如果你不開始安排整個《項目計劃》，你就不能完整的定義出《項目定義》。在許多情況中，你需要同步處理這兩個可交付物。在你收集有關範圍和可交付物的信息時，你需要制定一張時間表以便獲得預估的工時和期限。當你把可交付物、範圍、假設以及方法定義清楚時，你就會獲得足夠的信息以便制定《項目計劃》 來預估預算、工時和期限。然後，你可以用它們來完成《項目定義》。
3. 管理計劃
這時，你已經完成了項目定義和項目計劃。主要的可交付物《項目定義》、《項目計劃》已經準備就緒了。有些項目經理認爲，完成了項目定義和項目計劃意味着項目管理中最艱難的部分就完成了。實際上情況顯然不是這樣。
如果你不能持續更新項目計劃，你永遠也不會成爲一個成功的項目經理。記住，項目計劃只是一個可交付物。項目計劃描述了需要完成的工作、各項工作的順序、需要的工時數以及負責人，但是項目計劃僅僅是你對於如何完成項目的某個特定時點剩餘工作的最佳預測。
你的項目越複雜，隨着時間的流逝，項目計劃需要更新的地方就越多。做爲一個項目經理，你必須要在一個不斷變化的基礎上（也許是每週一次）評估項目計劃，判定項目的當前狀況。
在每週一次的回顧中，你要在項目計劃中更新已經完成以及正在進行的工作的當前狀態。你要評估那些剩餘的工作，看看項目是否可以按照初始計劃中估算的工時、成本以及期限完成。如果評估的結果是，項目可以按照初始計劃完成，那麼你的項目目前狀態良好。反之，你就必須實施糾正措施。
在所有管理項目的技能中，管理工作計劃也許是最基本的一個。根據項目的實際情況，你可能要一直使用你的經驗和創造力才能使得項目按預期完成。這個星期，你的項目可能還在按計劃進行。下個星期，你可能就會遇到任務延期和其它問題。
如果處在關鍵路徑上的某個活動延期了一週，你可不能傻坐着眼看整個項目延期一週。相反，你必須評估可用資源以及可能的選擇，讓項目迴歸正軌。如果你擅長管理工作計劃，那麼它將是項目管理中最具挑戰和回報性的工作之一。如果你不喜歡做這些必需的細緻工作，那麼你會發現想要獲得成功就太難了。
4. 問題管理
當某個麻煩阻礙了項目的執行，“問題”就出現了。沒有外界的幫助，項目經理和項目團隊無法解決“問題”。如果出現的是個嚴重的問題，你除了解決它別無選擇。唯一的問題是你是否能夠積極主動的使用問題管理，戰勝猶豫不決以及無法確定如何解決這個問題的困難。
問題管理由兩個重要的部分組成。首先要經歷一個調查問題、確定問題對項目影響、考慮可選的解決方案以及帶領團隊在這種情況下做出最佳決策的過程。所有這些項目管理步驟都應該提前定義並且獲得一致同意。這些步驟確保問題可以有組織地、儘可能快地被解決。
問題管理的第二個部分是使用特定的問題解決技巧。這包括一些我們熟悉的技巧，比如魚骨圖（Fishbone diagrams）、直方圖（Pareto charts）和根本原因分析。你可能熟悉其中的一個或多個技巧，它們可以讓你和你的團隊理解問題的本質和原因、有哪些可行的解決辦法以及哪一個解決辦法是最佳的選擇。
所有的項目經理都認識到的、一個非常重要的事實就是，解決問題需要有個過程，但這並不意味着你會成功地解決每個問題。有時，解決問題有很多方法，你的工作就是幫助找出哪一個是最好的。有時，一個重大的問題卻沒有好的解決方案，這時，你最好的選擇就是要挑出一個方案，這個方案產生的危害最小或者這個方案在其它更差的方案中是最好的。雖然如此，問題解決過程和問題解決技巧會使你確定哪些選擇是可用的，以便讓你至少瞭解到後果是什麼。
5. 範圍管理
《項目範圍》描述了項目的邊界，定義了項目交付的內容、需要的數據以及受影響的組織。給定一組資源和時間，就可以交付無限的東西。
範圍變化管理開始於範圍變化定義。如果項目經理沒有做好範圍定義，那麼在項目執行期間進行範圍管理將非常困難。範圍變化管理的目的就是要保護當前已獲得批准的《項目定義》的可行性。一旦定義了項目，某種對於項目的期望就被設定了，隨之會產生出相應的成本和時間表。在《項目定義》被提交和批准時，你和項目發起 人就把會這些期望記在心中。
在項目執行期間，可能會出現一些與初始的《項目定義》不同或者未包含在其中的需求。這種情況是能夠預見的。如 果真的發生了，客戶不應該期望這些需求在之前認可的資源和時間限制下也可以交付。如果需要把新需求包含進《項目定義》，那麼項目團隊要分析這些新需求，判斷它們對項目的影響。然後，這些信息要得到項目發起人的批准。
記住，項目發起人是那個批准項目啓動資金的人。因此，他或她應該也是那個批准任何項目定義變更的人。如果變更的商業價值足夠高，那麼發起人應該批准將這些新需求加入項目，同時要增加完成工作所需的預算和時間。然後，每個相關的人都要同意並且重新設定項目期望。
當然，有時情況並不會如此順利。一般會出現下列問題：
超出範圍：大規模的範圍變更是很容易看出來的。然而，當變更很小時，有時你會發現你還沒弄明白這些變更就把它們包含進項目了。“
超出範圍”的意思是你接受了小變更，結果逐漸累積的小變更最後給項目造成了顯著的影響。你和你的整個團隊必須小心地對待項目範圍變更，無論變更是大是小。
最終用戶對範圍的認可： 項目發起人是爲項目付錢的人。然而，一旦項目開始，項目團隊會花費更多的時間在基層客戶和最終用戶上。
有些項目團隊成員認爲，最終用戶批准了範圍變更就可 以了。事實並非如此。除非發起人已經明確地將批准權授予了最終用戶，否則他們無權批准範圍變更。他們可以提出範圍變更的請求，但是隻有具有資金權限的發起人才能批准增加的工作。
團隊成員不明白自己的職責： 導致沒能按期完成項目的一個普遍的原因是項目團隊成員最終做了比實際所需工作更多的工作。例如，某個團隊成員被要求去完成一份報告。在他或她正在撰寫報告時，客戶又要求了新的內容。這個團隊成員試圖滿足客戶，於是工作最終就延期了。這種情況一般發生在團隊成員認爲只有項目經理才需要擔心範圍變更。團隊成員 必須明白控制範圍變更是每個人的責任。
對許多不成功項目之所以不成功的根本原因分析的結果是它們的範圍變更控制都比較糟糕。有效地定義、管理範圍將增加你的項目符合期望的機會。