小型項目的管理者并不需要過多的項目管理知識和項目管理技巧的訓練。但是，一旦項目的規模變大了，這些正規的管理過程和技巧就是項目管理者必備的了。雖然不同的項目管理方法以不同的方式組織并且說明了這些項目管理過程，但是我們還是想強調其中最基本的10個過程：
1. 定義項目范圍
2. 制定工作計劃
3. 管理工作計劃
4. 問題管理
5. 范圍管理
6. 風險管理
7. 溝通管理
8. 文檔管理
9. 質量管理
10. 度量管理
一般來說，如果你能掌握這10個領域的知識，你就能在大部分的項目管理中獲得成功。對于小項目，你可能不需要為文檔或是度量管理而擔心。但是，你管理的項目越大，你就越需要重視這10個過程的管理。
你可能已經注意到我們列出的10個管理過程中沒有包括分析、設計、測試或者部署。那些有些項目工作經驗的人也許知道一個項目通常會包括分析和測試過程。然而，實際上這些過程有很大的差別。分析和測試過程是實際項目進程（也稱為項目生命周期）的一部分。隨著項目類型的變化，項目生命周期包含的階段也不同。如果你的項目是一個具有完整的生命周期的項目，你也許就會執行從分析、設計、構建、測試到部署的全過程。而在其它類型的項目中，你可能只會涉及到其中某些階段。例如，如果你的項目是一個調查研究項目，你就不會涉及到部署的問題。如果你在做一項研究，在做完分析階段的任務后，這個項目可能就會結束了。
我們還遺漏了什么？
兩個管理過程有時也會做為基本的項目管理過程的一部分：人員管理、合同和采購管理。對于項目經理來說，人員管理是非常重要的技能，但是對于項目管理來說，它并不是必需的。畢竟，在任何對下級的管理中都需要涉及人員管理。這其中的區別就是，人員管理是一種項目“經理”需要具備的技能，而不是項目“管理”必需的技能。
在我們這10個項目管理過程列表中也沒有包括合同和采購管理。在大多數組織中，項目經理需要了解對合同和供應商的管理情況，但是他們并不對此負責。法律部門和（或）采購部門通常負責合同和供應商的管理。
時間安排和過程的順序
除第一類和第二類——定義項目范圍和制定工作計劃——之外，這10個主要的項目管理領域并不是一個順序執行的過程。從過程3到過程10，你可以按任意順序來執行。而且，實際上，它們在整個項目中都是并行的，并且是從項目開始到項目結束一直都在進行的。例如，如果項目出現了一個重要的問題，你就必須忽略掉問題出現之前、出現期間或是出現之后你使用的項目管理的其它過程，而馬上使用問題管理過程。讓我們來仔細看看每一個管理過程吧。
1. 定義項目范圍
做為一個項目經理，你必須在項目開始前確定項目的各項工作是容易被大家理解的，并且已經得到了項目發起人以及關鍵的項目利益相關者們的同意。你需要和發起人、項目利益相關人一起討論這些工作，以確保項目團隊和客戶對于項目的交付物、項目完成的時間、項目的成本、項目執行團隊、項目的完成方式以及最終獲得的利益達成一致的認識。
從項目管理的高層看來，定義項目工作的目的包括：
--理解項目目標、可交付物、范圍、風險、成本、方法并且達成一致。這是定義項目工作中最重要的部分，并且大部分的時間都會花在達成一致上。
--判斷初始的業務案例是否仍然是正確的。例如，一個需要花費1萬工時的項目可能具有商業意義。但是，如果定義工作的過程過于詳細，就會導致超過2萬小時的精確估算時間，這樣這個項目可能就不再可行了。
--確保那些你需要的資源在你需要的時候是可用的。
--制定一個高層次的項目基線。依靠這個基線，項目相關人員可以比較各個過程的執行情況，也可以控制項目的范圍。
--與客戶在這個項目所使用的管理過程上達成一致。
需要花費在定義項目工作上的精力取決于需要讓項目相關人員理解和文檔化的信息量的多少。需要花費在定義項目工作上的時間取決于了解和文檔化這些信息所必需的時間長短，也取決于需要花費在獲得客戶的同意和認可上的時間長短。
對于大型復雜的項目來說，準確的定義出最終的可交付物可能是非常困難的；估計出項目總成本和最終的交付日期也是很困難的。如果你管理的是大型復雜的項目，你可以把整個項目分成幾個小型項目。在這些小項目中，需要先做的小項目應該更容易定義出它們的各項工作。那些在未來需要完成的小項目可以在快執行的時候再詳細定義出各項工作。
在定義項目范圍結束的時候，你應該制定出一份《項目定義》。這份文檔從項目的目標、可交付物、范圍、風險、交付日期和項目人員角色等各方面定義了項目的所有期望。這份文檔應該在項目團隊開始執行項目之前獲得項目發起人和其他關鍵的項目干系人的正式批準。
2. 制定工作計劃
在你定義項目的時候，你要確保和項目發起人在項目應該完成的所有工作內容上達成一致意見。在制定工作計劃這一階段，你將確定完成這些工作的方式。這就需要制 定《項目計劃》。根據項目的規模，你要采取不同的方法。例如，制定小型項目的工作計劃可以使用像MicrosoftProject這樣的項目管理工具包、電子制表軟件，甚至一張紙。
如果在你開始做計劃的時候，你還沒有可用的工作計劃模板，你可以使用工作分解結構（WBS）。WBS是一種技術，它從項目的高層次將工作分解成越來越小的部分，直到項目管理者獲得項目工作的完整視圖。整個項目團隊在此基礎上一起工作。我建議將工作分解到較低級別，分解到完成每個不再分解的活動所需的時間不多于80小時，并且完成這個活動所需要的資源也是十分清晰的。
一旦你把所有的工作都分解成活動，你就可以將這些活動排個順序并且確定它們之間的依賴關系。這時，WBS就轉變為網絡圖（Network Diagram）。
然后，你需要給每個活動添加資源（即工作人員）。如果你知道某些資源的確切的名字，你可以以名字添加他們。如果你不知道，你可以使用通用名來占位。接著，你需要為每個活動添加工時及開始、結束日期。
現在，你的工作計劃已經準備好了。你可以清楚地了解到你要完成的工作內容（《項目定義》）以及你要如何完成這些工作（《項目計劃》）。
項目定義和項目計劃之間的關系
你會發現，如果你不開始安排整個《項目計劃》，你就不能完整的定義出《項目定義》。在許多情況中，你需要同步處理這兩個可交付物。在你收集有關范圍和可交付物的信息時，你需要制定一張時間表以便獲得預估的工時和期限。當你把可交付物、范圍、假設以及方法定義清楚時，你就會獲得足夠的信息以便制定《項目計劃》來預估預算、工時和期限。然后，你可以用它們來完成《項目定義》。
3. 管理計劃
這時，你已經完成了項目定義和項目計劃。主要的可交付物《項目定義》、《項目計劃》已經準備就緒了。有些項目經理認為，完成了項目定義和項目計劃意味著項目管理中最艱難的部分就完成了。實際上情況顯然不是這樣。
如果你不能持續更新項目計劃，你永遠也不會成為一個成功的項目經理。記住，項目計劃只是一個可交付物。項目計劃描述了需要完成的工作、各項工作的順序、需要的工時數以及負責人，但是項目計劃僅僅是你對于如何完成項目的某個特定時點剩余工作的最佳預測。
你的項目越復雜，隨著時間的流逝，項目計劃需要更新的地方就越多。做為一個項目經理，你必須要在一個不斷變化的基礎上（也許是每周一次）評估項目計劃，判定項目的當前狀況。
在每周一次的回顧中，你要在項目計劃中更新已經完成以及正在進行的工作的當前狀態。你要評估那些剩余的工作，看看項目是否可以按照初始計劃中估算的工時、成本以及期限完成。如果評估的結果是，項目可以按照初始計劃完成，那么你的項目目前狀態良好。反之，你就必須實施糾正措施。
在所有管理項目的技能中，管理工作計劃也許是最基本的一個。根據項目的實際情況，你可能要一直使用你的經驗和創造力才能使得項目按預期完成。這個星期，你的項目可能還在按計劃進行。下個星期，你可能就會遇到任務延期和其它問題。
如果處在關鍵路徑上的某個活動延期了一周，你可不能傻坐著眼看整個項目延期一周。相反，你必須評估可用資源以及可能的選擇，讓項目回歸正軌。如果你擅長管理工作計劃，那么它將是項目管理中最具挑戰和回報性的工作之一。如果你不喜歡做這些必需的細致工作，那么你會發現想要獲得成功就太難了。
4. 問題管理
當某個麻煩阻礙了項目的執行，“問題”就出現了。沒有外界的幫助，項目經理和項目團隊無法解決“問題”。如果出現的是個嚴重的問題，你除了解決它別無選擇。唯一的問題是你是否能夠積極主動的使用問題管理，戰勝猶豫不決以及無法確定如何解決這個問題的困難。
問題管理由兩個重要的部分組成。首先要經歷一個調查問題、確定問題對項目影響、考慮可選的解決方案以及帶領團隊在這種情況下做出最佳決策的過程。所有這些項目管理步驟都應該提前定義并且獲得一致同意。這些步驟確保問題可以有組織地、盡可能快地被解決。
問題管理的第二個部分是使用特定的問題解決技巧。這包括一些我們熟悉的技巧，比如魚骨圖（Fishbone diagrams）、直方圖（Paretocharts）和根本原因分析。你可能熟悉其中的一個或多個技巧，它們可以讓你和你的團隊理解問題的本質和原因、有哪些可行的解決辦法以及哪一個解決辦法是最佳的選擇。
所有的項目經理都認識到的、一個非常重要的事實就是，解決問題需要有個過程，但這并不意味著你會成功地解決每個問題。有時，解決問題有很多方法，你的工作就是幫助找出哪一個是最好的。有時，一個重大的問題卻沒有好的解決方案，這時，你最好的選擇就是要挑出一個方案，這個方案產生的危害最小或者這個方案在其它更差的方案中是最好的。雖然如此，問題解決過程和問題解決技巧會使你確定哪些選擇是可用的，以便讓你至少了解到后果是什么。
5. 范圍管理
《項目范圍》描述了項目的邊界，定義了項目交付的內容、需要的數據以及受影響的組織。給定一組資源和時間，就可以交付無限的東西。
范圍變化管理開始于范圍變化定義。如果項目經理沒有做好范圍定義，那么在項目執行期間進行范圍管理將非常困難。范圍變化管理的目的就是要保護當前已獲得批準的《項目定義》的可行性。一旦定義了項目，某種對于項目的期望就被設定了，隨之會產生出相應的成本和時間表。在《項目定義》被提交和批準時，你和項目發起人就把會這些期望記在心中。
在項目執行期間，可能會出現一些與初始的《項目定義》不同或者未包含在其中的需求。這種情況是能夠預見的。如果真的發生了，客戶不應該期望這些需求在之前認可的資源和時間限制下也可以交付。如果需要把新需求包含進《項目定義》，那么項目團隊要分析這些新需求，判斷它們對項目的影響。然后，這些信息要得到項目發起人的批準。
記住，項目發起人是那個批準項目啟動資金的人。因此，他或她應該也是那個批準任何項目定義變更的人。如果變更的商業價值足夠高，那么發起人應該批準將這些新需求加入項目，同時要增加完成工作所需的預算和時間。然后，每個相關的人都要同意并且重新設定項目期望。
當然，有時情況并不會如此順利。一般會出現下列問題：
超出范圍：大規模的范圍變更是很容易看出來的。然而，當變更很小時，有時你會發現你還沒弄明白這些變更就把它們包含進項目了。“超出范圍”的意思是你接受了小變更，結果逐漸累積的小變更最后給項目造成了顯著的影響。你和你的整個團隊必須小心地對待項目范圍變更，無論變更是大是小。
最終用戶對范圍的認可:項目發起人是為項目付錢的人。然而，一旦項目開始，項目團隊會花費更多的時間在基層客戶和最終用戶上。有些項目團隊成員認為，最終用戶批準了范圍變更就可以了。事實并非如此。除非發起人已經明確地將批準權授予了最終用戶，否則他們無權批準范圍變更。他們可以提出范圍變更的請求，但是只有具有資金權限的發起人才能批準增加的工作。
團隊成員不明白自己的職責:導致沒能按期完成項目的一個普遍的原因是項目團隊成員最終做了比實際所需工作更多的工作。例如，某個團隊成員被要求去完成一份報告。在他或她正在撰寫報告時，客戶又要求了新的內容。這個團隊成員試圖滿足客戶，于是工作最終就延期了。這種情況一般發生在團隊成員認為只有項目經理才需要擔心范圍變更。團隊成員必須明白控制范圍變更是每個人的責任。
對許多不成功項目之所以不成功的根本原因分析的結果是它們的范圍變更控制都比較糟糕。有效地定義、管理范圍將增加你的項目符合期望的機會。
6. 風險管理
風險是指那些不在項目團隊控制之下或是如果它們出現會給項目帶來不利影響的未來的情況或環境。換句話說，問題是當前必須處理的麻煩，而風險一種潛在的麻煩。 被動的項目經理在問題出現時解決問題。主動地項目經理在問題出現前，努力識別、解決潛在的問題。風險管理既是科學，也是藝術。
由于小型項目通常周期較短，出現問題的可能性就比較少。大型項目通常有隱藏的風險。風險管理包括識別出所有項目潛在的風險、確定它們發生的可能性，并且清楚地了解如果它們出現的話，對項目造成的影響。
依據這些信息，項目團隊能夠確定需要主動管理哪些風險。例如，一定要主動管理那些出現概率高且對項目影響大的風險，而可以忽略那些出現概率高但對項目影響小的風險。
一旦你識別出了需要主動管理的風險，你就可以使用下面這五個通常的做法：
別管它。 如果你認為某種風險即使出現對你的項目影響也不大，或者沒什么辦法可以消除某種風險，再或者你愿意冒險賭某種風險不會出現，那么你就別管它了。
監控風險。 在這種情況下，你無需主動降低風險，但是你要監控它，看隨著時間的推移它發生的可能性增加還是減少。如果后來某種風險出現的可能性增加了，那么這時候團隊就必須要想辦法消除它了。
避免風險。 避免風險意味著消除那些會引發麻煩的條件。例如，與某個特定供應商相關的風險可能在選擇了其它供應商后，就可以避免了。
轉移風險。 在某些情況下，管理風險的責任可能會從項目組轉移給其它實體或第三方機構。
--降低風險。 在大多數情況下，都應該這么做。如果已經識別出某個風險或是正擔心某個風險，那么你應該制定一個主動處理的計劃以確保它不會發生。
正如范圍變更一樣，一個項目不可能沒有風險。客戶也不會期望一個項目沒有風險。問題是項目管理對風險的反應。如果進行了風險識別并且主動管理風險，項目就更可能會獲得成功。如果忽略可能出現的風險，在風險轉變成問題時，項目只能被動的受到影響。這時，可能只有很少的解決方法能避免項目受到影響了。
7. 溝通管理
在項目中，適當的溝通對于管理客戶和利益相關人是至關重要的。如果客戶和利益相關人們沒能及時了解到項目的進展情況，那么由于他們對項目具有的不同期望值，可能會增加項目出現問題和困難的可能。實際上，在許多情況中，出現沖突并不是因為實際的問題，而是因為客戶和管理者事先不知情。
項目中的溝通有兩個層次。第一，所有的項目都應該溝通。第二，如果你的項目更大更復雜、或者與政治有關，那么你所要進行的溝通通常更加高級和復雜，因此你需要制定一個《溝通計劃》。
項目狀態會議和項目狀態報告
所有的項目都需要有效地溝通，無論是從項目團隊到項目經理，還是從項目經理到其他的利益相關人。項目狀態報告和項目狀態會議不僅僅是用來報告項目正常進展的，還有其他的事情要做。從項目狀態報告和項目狀態會議你可以了解到所有你需要知道的和項目有關的一切。你要溝通堅守項目預算及時間表的理念，要溝通在最近一次報告期內完成的工作，要溝通下一個報告期內計劃完成的工作、新風險、當前的問題，以及當前的范圍變更請求。
傳遞信息和講話都必須考慮到你的觀眾。因此，你最好和你的項目團隊每周召開一次項目狀態會議，會議上應該包括一些非常細節的討論。你發送給發起人和管理類利益相關人的狀態報告一定要簡短且高度概括。
溝通計劃
重大決定，尤其是那種要求組織變革的決定必須包含一個全面的溝通計劃，這份溝通計劃將采取多種溝通方式。制定溝通計劃的過程包括確認所有的利益相關人、確定他們需要獲得的項目信息、集思廣益分發信息的方式以及在充分利用資源的情況下與盡可能多的項目利益相關者進行溝通。
根據聽眾的情況，交流一般采取下面三種方式中的一種：
強制性的：包括項目狀態報告、項目預算報告以及已批準的需求。
參考性的：給相關人員提供進一步的信息。比如，文檔庫、常見問題列表以及包含相關項目信息的項目站點。
營銷性的：這種類型的交流是為了增強大家對項目的熱情。比如，出版項目成功經驗、樹立正面形象、分發管理推薦信以及使用項目標識。
項目經理必須主動掌控交流活動，必須有意識的計劃并且執行交流活動。如果你的交流行為既有效又主動，那么你會發現整個項目運作將更平穩，并且遇到的沖突及障礙會更少一些。
8. 文檔管理
許多項目經理認為只有當項目中有幾百份文檔時才需要進行文檔管理。實際上，更好的方法是預先估計一下你認為項目本身以及項目管理可能產生的文檔資料的數量，建立一套適當的過程和規則來組織文檔，并且在項目進行期間進行文檔管理以確保文檔不會失去控制。
小型項目的項目經理不需要太多考慮文檔管理的問題。隨著項目的規模逐漸變大，項目經理就必須要主動管理項目中的文檔資料了。管理文檔時可能遇到的最普遍的問題就是文檔丟失了或難以找到，以至于在項目結束時要重新書寫。最壞的一種情況是文檔的版本失去了控制，文檔的更新日期過期了、丟失了、混亂了或是無法確定了。
文檔管理是項目管理的一個方面，可以使用像文檔庫這樣的工具。然而，如果存儲文檔時沒有使用適當的技術，以至于不能方便地存取文檔，那么使用工具只能讓問題更復雜。
文檔管理既簡單又復雜。簡單的任務比如說文檔命名約定。如果你的團隊中有10個人，每個人每周提交一份狀態報告，那么很快你就會有成百份的文檔資料了。如果每個人都使用通用的命名規范，就很容易組織文檔。那么，文檔的名稱應該以每個人的名字開頭嗎？如果這么做，每個人的歷史狀態報告會排在一起，很容易找到。
可能你想找到某個特定時點的狀態報告。這時，狀態報告就應該以時間開頭。這樣所有的狀態報告就按報告周期排在一起。
文檔管理的另一個方面是規定項目使用的文檔管理工具。比如，你可能將Microsoft Word作為標準的文檔編輯器。如果你的項目團隊是跨職能的，包括客戶、廠商、供應商，那么文檔管理規則就更重要了。
要想使文檔管理取得成功，有些其它的因素也必須考慮。比如，文檔存儲的位置、文檔的組織方法、訪問及安全規則、關鍵詞或索引、命名標準、版本控制、完成狀態、保留或銷毀狀態、備份以及標準模板。
9. 質量管理
項目及可交付物符合客戶需求和期望的程度體現了質量的好壞。換句話說，質量的好壞最終要由客戶來評判。
項目組應該努力滿足甚至超過客戶的需求和期望。有時候，大家可能會認為高質量就意味著最好的材料和設備，并且零缺陷。然而，大多數情況下，客戶不會期望而且也負擔不起這樣的完美解決方案。如果項目只是有一些缺陷的話，客戶還是會認為交付的項目是具有高質量的。
換句話說，一個解決方案設計完美、毫無缺陷，但是并不符合客戶的需要，那么這個方案也不是高質量的方案。從質量的觀點看來，質量管理的目的首先是理解客戶的期望。然后，制定計劃及管理過程用以滿足甚至超出客戶的期望。
由于質量的高低是由客戶來判定的，因此判定的標準看起來是相當的主觀的。然而，對質量的評判也可以很客觀。我們首先需要把“質量”這個一般術語分解成一些可定義質量特征。
比如，你可能認為計算機軟件的質量應該按照響應時間、用戶體驗、易用性、幫助文檔以及缺陷的多少來衡量。你一旦定義了可以量化的質量特征，你就可以判斷它們是否可以客觀的衡量質量。
質量管理不是一個單一事件：它是一個過程，一種思維模式。一貫高質量的產品不可能出自有缺陷的過程。你需要建立一個先衡量質量，而后改進過程的可重復的循環。
想要使質量管理過程正常工作，收集度量非常重要。因此，項目管理第九和第十個方面，也就是質量管理和度量管理聯系非常緊密。如果你想做好質量管理工作，你就必須度量。
一旦項目完成了最初的定義，項目團隊必須要按質量要求理解客戶的期望，并且制定相應的《質量計劃》來滿足這些期望。《質量計劃》要包含完整和正確的關鍵域，以便讓項目團隊了解客戶對質量的期望。
《質量計劃》也會包含兩種通常的質量管理過程：質量控制和質量保證。質量控制活動確保項目提交的可交付物符合客戶的期望。例如，檢查那些用于完成最終可交付物的每個組件。質量保證活動確保用來創建可交付物的過程是高質量的。例如，在最終提交可交付物前，使用檢查表檢查必須完成的每個步驟是否都完成了。
質量管理的目的之一是可以盡早發現項目中的錯誤或缺陷。因此，好的質量管理過程最終會使得項目花費更多的工時和成本。然而，在項目早期就關注質量的話，會給項目帶來巨大的回報。例如，在項目的分析階段發現與業務需求有關的問題比在項目測試時發現遺漏了需求而返工效率高得多。再比如，在制造電腦芯片時發現芯片的問題比客戶購買后帶著電腦來更換芯片，制造商的成本要少得多。
10. 度量管理
收集度量是最復雜的項目管理過程，可能也是最艱難的。因為度量既難定義也難收集，所以通常被人們忽略或處理得很拙略。所有的項目都應該收集一些基本的度量信息，比如成本、工時以及周期。然而，你也必須收集那些可以判斷可交付物是否滿足了客戶的期望的度量，以及那些可以判斷項目內部運作過程是否正常運轉的度量。一旦決定了你需要哪種度量，你就可以開始相應的行動或過程改進行為了，這樣可以使收集的過程更加高效。
度量管理和質量管理是有關聯的。如果不收集這些度量，那么你很難提高交付物或執行過程的質量。度量通常被用來標示質量開始的狀態以及質量是提高了還是下降了。
許多度量能夠在項目中收集。項目團隊應該定義并且組織一個能夠提供最大價值的平衡集合。為了決定哪些度量適合你的項目，你可以：
依據項目的可交付物和項目執行的情況識別出那些評判項目是否成功的標準。也就是說，確定出項目成功完成時，你的可交付物應該看起來像什么樣。你還要確定出項目成功必須要考慮的一些東西，比如預算和交付日期。
組織團隊進行頭腦風暴來收集每一個能表示項目成功的度量。
尋找一個能夠按照成本、交付情況、質量和客戶滿意度評判項目成功的度量集合。
將那些以最經濟的方式提供最大價值的潛在度量排在優先位置。
設定能夠使你成功的目標。度量很少單獨產生價值。它的價值在于它能夠衡量你是否偏離了目標。
在工作計劃中增加收集活動以確保有人負責度量的收集和分析。
一般說來，度量管理對于小型項目的價值不大，原因在于小型項目通常沒有足夠的時間來捕捉這些數據、分析結果以及做出適當的改進。持續時間較長的項目給了你使用反饋環的時間。如果將度量用于改進提升一個組織，那么使用度量就獲得了最大的價值。
本站僅提供存儲服務，所有內容均由用戶發布，如發現有害或侵權內容，請
點擊舉報。
