改進項目管理技能的過程

1、.：.；改良工程管理技藝過程導讀：文中引見對于工程管理的一些技藝改良之處，可以提高管理的效率巧妙之處，并詳細的列舉出管理中的十個過程。小型工程的管理者并不需求過多的工程管理知識和工程管理技巧的訓練。但是，一旦工程的規(guī)模變大了，這些正規(guī)的管理過程和技巧就是工程管理者必備的了。雖然不同的工程管理方法以不同的方式組織并且闡明了這些工程管理過程，但是我們還是想強調(diào)其中最根本的10個過程：1. 定義工程范圍2. 制定任務方案3. 管理任務方案4. 問題管理5. 范圍管理6. 風險管理7. 溝通管理8. 文檔管理9. 質(zhì)量管理10. 度量管理普通來說，假設他能掌握這10個領域的知識，他就能在大部分的工程管

2、理中獲得勝利。對于小工程，他能夠不需求為文檔或是度量管理而擔憂。但是，他管理的工程越大，他就越需求注重這10個過程的管理。他能夠曾經(jīng)留意到我們列出的10個管理過程中沒有包括分析、設計、測試或者部署。那些有些工程任務閱歷的人也許知道一個工程通常會包括分析和測試過程。然而，實踐上這些過程有很大的差別。分析和測試過程是實踐工程進程也稱為工程生命周期的一部分。隨著工程類型的變化，工程生命周期包含的階段也不同。假設他的工程是一個具有完好的生命周期的工程，他也許就會執(zhí)行從分析、設計、構建、測試到部署的全過程。而在其它類型的工程中，他能夠只會涉及到其中某些階 段。例如，假設他的工程是一個調(diào)查研討工程，他就不

3、會涉及到部署的問題。假設他在做一項研討，在做完分析階段的義務后，這個工程能夠就會終了了。我們還脫漏了什么？兩個管理過程有時也會做為根本的工程管理過程的一部分：人員管理、合同和采購管理。對于工程經(jīng)理來說，人員管理是非常重要的技藝，但是對于工程管理來說，它并不是必需的。畢竟，在任何對下級的管理中都需求涉及人員管理。這其中的區(qū)別就是，人員管理是一種工程“經(jīng)理需求具備的技藝，而不是工程“管理必需 的技藝。在我們這10個工程管理過程列表中也沒有包括合同和采購管理。在大多數(shù)組織中，工程經(jīng)理需求了解對合同和供應商的管理情況，但是他們并不對此擔任。法律部門和或采購部門通常擔任合同和供應商的管理。時間安排和過程

4、的順序除第一類和第二類定義工程范圍和制定任務方案之外，這10個主要的工程管理領域并不是一個順序執(zhí)行的過程。從過程3到過程10，他可以按恣意順序來 執(zhí)行。而且，實踐上，它們在整個工程中都是并行的，并且是從工程開場到工程終了不斷都在進展的。例如，假設工程出現(xiàn)了一個重要的問題，他就必需忽略掉問題出現(xiàn)之前、出現(xiàn)期間或是出現(xiàn)之后他運用的工程管理的其它過程，而馬上運用問題管理過程。讓我們來仔細看看每一個管理過程吧。1. 定義工程范圍做 為一個工程經(jīng)理，他必需在工程開場前確定工程的各項任務是容易被大家了解的，并且曾經(jīng)得到了工程發(fā)起人以及關鍵的工程利益相關者們的贊同。他需求和發(fā)起人、工程利益相關人一同討論這些

5、任務，以確保工程團隊和客戶對于工程的交付物、工程完成的時間、工程的本錢、工程執(zhí)行團隊、工程的完成方式以及最終獲得的 利益達成一致的認識。從工程管理的高層看來，定義工程任務的目的包括：了解工程目的、可交付物、范圍、風險、本錢、方法并且達成一致。這是定義工程任務中最重要的部分，并且大部分的時間都會花在達成一致上。判別初始的業(yè)務案例能否依然是正確的。例如，一個需求破費1萬工時的工程能夠具有商業(yè)意義。但是，假設定義任務的過程過于詳細，就會導致超越2萬小時的準確估算時間，這樣這個工程能夠就不再可行了。確保那些他需求的資源在他需求的時候是可用的。制定一個高層次的工程基線。依托這個基線，工程相關人員可以比較

6、各個過程的執(zhí)行情況，也可以控制工程的范圍。與客戶在這個工程所運用的管理過程上達成一致。需求破費在定義工程任務上的精神取決于需求讓工程相關人員了解和文檔化的信息量的多少。需求破費在定義工程任務上的時間取決于了解和文檔化這些信息所必需的時間長短，也取決于需求破費在獲得客戶的贊同和認可上的時間長短。對于大型復雜的工程來說，準確的定義出最終的可交付物能夠是非常困難的；估計出工程總本錢和最終的交付日期也是很困難的。假設他管理的是大型復雜的工程，他可以把整個工程分成幾個小型工程。在這些小工程中，需求先做的小工程應該更容易定義出它們的各項任務。那些在未來需求完成的小工程可以在快執(zhí)行的時候再詳 細定義出各項任

7、務。在定義工程范圍終了的時候，他應該制定出一份。這份文檔從工程的目的、可交付物、范圍、風險、交付日期和工程人員角色等各方面定義了工程的一切期望。這份文檔應該在工程團隊開場執(zhí)行工程之前獲得工程發(fā)起人和其他關鍵的工程干系人的正式同意。2. 制定任務方案在他定義工程的時候，他要確保和工程發(fā)起人在工程應該完成的一切任務內(nèi)容上達成一致意見。在制定任務方案這一階段，他將確定完成這些任務的方式。這就需求制定。根據(jù)工程的規(guī)模，他要采取不同的方法。例如，制定小型工程的任務方案可以運用像Microsoft Project這樣的工程管理工具包、電子制表軟件，甚至一張紙。假設在他開場做方案的時候，他還沒有可用的任務方

8、案模板，他可以運用任務分解構造WBS。WBS是一種技術，它從工程的高層次將任務分解成越來越小的部分，直到工程管理者獲得工程任務的完好視圖。整個工程團隊在此根底上一同任務。我建議將任務分解到較低級別，分解到完成每個不再分解的活動所需的時間不多于80小時，并且完成這個活動所需求的資源也是非常明晰的。一旦他把一切的任務都分解成活動，他就可以將這些活動排個順序并且確定它們之間的依賴關系。這時，WBS就轉(zhuǎn)變?yōu)榫W(wǎng)絡圖Network Diagram。然后，他需求給每個活動添加資源即任務人員。假設他知道某些資源確實切的名字，他可以以名字添加他們。假設他不知道，他可以運用通用名來占位。接著，他需求為每個活動添加

9、工時及開場、終了日期。如今，他的任務方案曾經(jīng)預備好了。他可以清楚地了解到他要完成的任務內(nèi)容以及他要如何完成這些任務。工程定義和工程方案之間的關系他會發(fā)現(xiàn)，假設他不開場安排整個，他就不能完好的定義出。在許多情況中，他需求同步處置這兩個可交付物。在他搜集有關范圍和可交付物的信息時，他需求制定一張時間表以便獲得預估的工時和期限。當他把可交付物、范圍、假設以及方法定義清楚時，他就會獲得足夠的信息以便制定 來預估預算、工時和期限。然后，他可以用它們來完成。3. 管理方案這時，他曾經(jīng)完成了工程定義和工程方案。主要的可交付物、曾經(jīng)預備就緒了。有些工程經(jīng)理以為，完成了工程定義和工程方案意味著工程管理中最困難的

10、部分就完成了。實踐上情況顯然不是這樣。假設他不能繼續(xù)更新工程方案，他永遠也不會成為一個勝利的工程經(jīng)理。記住，工程方案只是一個可交付物。工程方案描畫了需求完成的任務、各項任務的順序、需求的工時數(shù)以及擔任人，但是工程方案僅僅是他對于如何完成工程的某個特定時點剩余任務的最正確預測。他的工程越復雜，隨著時間的流逝，工程方案需求更新的地方就越多。做為一個工程經(jīng)理，他必需求在一個不斷變化的根底上也許是每周一次評價工程方案，斷定工程的當前情況。在每周一次的回想中，他要在工程方案中更新曾經(jīng)完成以及正在進展的任務的當前形狀。他要評價那些剩余的任務，看看工程能否可以按照初始方案中估算的工時、本錢以及期限完成。假設

11、評價的結果是，工程可以按照初始方案完成，那么他的工程目前形狀良好。反之，他就必需實施糾正措施。在一切管理工程的技藝中，管理任務方案也許是最根本的一個。根據(jù)工程的實踐情況，他能夠要不斷運用他的閱歷和發(fā)明力才干使得工程按預期完成。這個星期，他的工程能夠還在按方案進展。下個星期，他能夠就會遇到義務延期和其它問題。假設處在關鍵途徑上的某個活動延期了一周，他可不能傻坐著眼看整個工程延期一周。相反，他必需評價可用資源以及能夠的選擇，讓工程回歸正軌。假設他擅長管理任務方案，那么它將是工程管理中最具挑戰(zhàn)和報答性的任務之一。假設他不喜歡做這些必需的細致任務，那么他會發(fā)現(xiàn)想要獲得勝利就太難了。4. 問題管理當某個

12、費事妨礙了工程的執(zhí)行，“問題就出現(xiàn)了。沒有外界的協(xié)助 ，工程經(jīng)理和工程團隊無法處理“問題。假設出現(xiàn)的是個嚴重的問題，他除理處理它別無選擇。獨一的問題是他能否可以積極自動的運用問題管理，戰(zhàn)勝猶疑不決以及無法確定如何處理這個問題的困難。問題管理由兩個重要的部分組成。首先要閱歷一個調(diào)查詢題、確定問題對工程影響、思索可選的處理方案以及帶著團隊在這種情況下做出最正確決策的過程。一切這些工程管理步驟都應該提早定義并且獲得一致贊同。這些步驟確保問題可以有組織地、盡能夠快地被處理。問題管理的第二個部分是運用特定的問題處理技巧。這包括一些我們熟習的技巧，比如魚骨圖Fishbone diagrams、直方圖Par

13、eto charts和根本緣由分析。他能夠熟習其中的一個或多個技巧，它們可以讓他和他的團隊了解問題的本質(zhì)和緣由、有哪些可行的處理方法以及哪一個處理方法是最正確的選擇。一切的工程經(jīng)理都認識到的、一個非常重要的現(xiàn)實就是，處理問題需求有個過程，但這并不意味著他會勝利地處理每個問題。有時，處理問題有很多方法，他的任務就是協(xié)助 找出哪一個是最好的。有時，一個艱苦的問題卻沒有好的處理方案，這時，他最好的選擇就是要挑出一個方案，這個方案產(chǎn)生的危害最小或者這個方案在其它更差的方案中是最好的。雖然如此，問題處理過程和問題處理技巧會使他確定哪些選擇是可用的，以便讓他至少了解到后果是什么。5. 范圍管理描畫了工程的

14、邊境，定義了工程交付的內(nèi)容、需求的數(shù)據(jù)以及受影響的組織。給定一組資源和時間，就可以交付無限的東西。范圍變化管理開場于范圍變化定義。假設工程經(jīng)理沒有做好范圍定義，那么在工程執(zhí)行期間進展范圍管理將非常困難。范圍變化管理的目的就是要維護當前已獲得同意的的可行性。一旦定義了工程，某種對于工程的期望就被設定了，隨之會產(chǎn)生出相應的本錢和時間表。在被提交和同意時，他和工程發(fā)起 人就把會這些期望記在心中。在工程執(zhí)行期間，能夠會出現(xiàn)一些與初始的不同或者未包含在其中的需求。這種情況是可以預見的。如 果真的發(fā)生了，客戶不應該期望這些需求在之前認可的資源和時間限制下也可以交付。假設需求把新需求包含進，那么工程團隊要分

15、析這些新需求，判別它們對工程的影響。然后，這些信息要得到工程發(fā)起人的同意。記住，工程發(fā)起人是那個同意工程啟動資金的人。因此，他或她應該也是那個同意任何工程定義變卦的人。假設變卦的商業(yè)價值足夠高，那么發(fā)起人應該同意將這些新需求參與工程，同時要添加完成任務所需的預算和時間。然后，每個相關的人都要贊同并且重新設定工程期望。當然，有時情況并不會如此順利。普通會出現(xiàn)以下問題：超出范圍：大規(guī)模的范圍變卦是很容易看出來的。然而，當變卦很小時，有時他會發(fā)現(xiàn)他還沒弄明白這些變卦就把它們包含進工程了?！俺龇秶囊馑际撬邮芰诵∽冐裕Y果逐漸累積的小變卦最后給工程呵斥了顯著的影響。他和他的整個團隊必需小心地對待工

16、程范圍變卦，無論變卦是大是小。最終用戶對范圍的認可： 工程發(fā)起人是為工程付錢的人。然而，一旦工程開場，工程團隊會破費更多的時間在基層客戶和最終用戶上。有些工程團隊成員以為，最終用戶同意了范圍變卦就可 以了?，F(xiàn)實并非如此。除非發(fā)起人曾經(jīng)明確地將同意權授予了最終用戶，否那么他們無權同意范圍變卦。他們可以提出范圍變卦的懇求，但是只需具有資金權限的發(fā)起人才干同意添加的任務。團隊成員不明白本人的職責： 導致沒能按期完成工程的一個普遍的緣由是工程團隊成員最終做了比實踐所需任務更多的任務。例如，某個團隊成員被要求去完成一份報告。在他或她正在撰寫報告時，客戶又要求了新的內(nèi)容。這個團隊成員試圖滿足客戶，于是任務

17、最終就延期了。這種情況普通發(fā)生在團隊成員以為只需工程經(jīng)理才需求擔憂范圍變卦。團隊成員 必需明白控制范圍變卦是每個人的責任。對許多不勝利工程之所以不勝利的根本緣由分析的結果是它們的范圍變卦控制都比較糟糕。有效地定義、管理范圍將添加他的工程符合期望的時機。6. 風險管理風險是指那些不在工程團隊控制之下或是假設它們出現(xiàn)會給工程帶來不利影響的未來的情況或環(huán)境。換句話說，問題是當前必需處置的費事，而風險一種潛在的費事。被動的工程經(jīng)理在問題出現(xiàn)時處理問題。自動地工程經(jīng)理在問題出現(xiàn)前，努力識別、處理潛在的問題。風險管理既是科學，也是藝術。由于小型工程通常周期較短，出現(xiàn)問題的能夠性就比較少。大型工程通常有隱藏

18、的風險。風險管理包括識別出一切工程潛在的風險、確定它們發(fā)生的能夠性，并且清楚地了解假設它們出現(xiàn)的話，對工程呵斥的影響。根據(jù)這些信息，工程團隊可以確定需求自動管理哪些風險。例如，一定要自動管理那些出現(xiàn)概率高且對工程影響大的風險，而可以忽略那些出現(xiàn)概率高但對工程影響小的風險。一旦他識別出了需求自動管理的風險，他就可以運用下面這五個通常的做法：別管它。 假設他以為某種風險即使出現(xiàn)對他的工程影響也不大，或者沒什么方法可以消除某種風險，再或者他情愿冒險賭某種風險不會出現(xiàn)，那么他就別管它了。監(jiān)控風險。 在這種情況下，他無需自動降低風險，但是他要監(jiān)控它，看隨著時間的推移它發(fā)生的能夠性添加還是減少。假設后來某

19、種風險出現(xiàn)的能夠性添加了，那么這時候團隊就必需求想方法消除它了。防止風險。 防止風險意味著消除那些會引發(fā)費事的條件。例如，與某個特定供應商相關的風險能夠在選擇了其它供應商后，就可以防止了。轉(zhuǎn)移風險。 在某些情況下，管理風險的責任能夠會從工程組轉(zhuǎn)移給其它實體或第三方機構。降低風險。 在大多數(shù)情況下，都應該這么做。假設曾經(jīng)識別出某個風險或是正擔憂某個風險，那么他應該制定一個自動處置的方案以確保它不會發(fā)生。正如范圍變卦一樣，一個工程不能夠沒有風險。客戶也不會期望一個工程沒有風險。問題是工程管理對風險的反響。假設進展了風險識別并且自動管理風險，工程就更能夠會獲得勝利。假設忽略能夠出現(xiàn)的風險，在風險轉(zhuǎn)變

20、成問題時，工程只能被動的遭到影響。這時，能夠只需很少的處理方法能防止工程遭到影響了。7. 溝通管理在工程中，適當?shù)臏贤▽τ诠芾砜蛻艉屠嫦嚓P人是至關重要的。假設客戶和利益相關人們沒能及時了解到工程的進展情況，那么由于他們對工程具有的不同期望值，能夠會添加工程出現(xiàn)問題和困難的能夠。實踐上，在許多情況中，出現(xiàn)沖突并不是由于實踐的問題，而是由于客戶和管理者事先不知情。工程中的溝通有兩個層次。第一，一切的工程都應該溝通。第二，假設他的工程更大更復雜、或者與政治有關，那么他所要進展的溝統(tǒng)統(tǒng)常更加高級和復雜，因此他需求制定一個。工程形狀會議和工程形狀報告一切的工程都需求有效地溝通，無論是從工程團隊到工程經(jīng)

21、理，還是從工程經(jīng)理到其他的利益相關人。工程形狀報告和工程形狀會議不僅僅是用來報告工程正常進展的，還有其他的事情要做。從工程形狀報告和工程形狀會議他可以了解到一切他需求知道的和工程有關的一切。他要溝通堅守工程預算及時間表的理念，要溝通在最 近一次報告期內(nèi)完成的任務，要溝通下一個報告期內(nèi)方案完成的任務、新風險、當前的問題，以及當前的范圍變卦懇求。傳送信息和講話都必需思索到他的觀眾。因此，他最好和他的工程團隊每周召開一次工程形狀會議，會議上應該包括一些非常細節(jié)的討論。他發(fā)送給發(fā)起人和管理類利益相關人的形狀報告一定要簡短且高度概括。溝通方案艱苦決議，尤其是那種要求組織變革的決議必需包含一個全面的溝通方

22、案，這份溝通方案將采取多種溝通方式。制定溝通方案的過程包括確認一切的利益相關人、確定他們需求獲得的工程信息、集思廣益分發(fā)信息的方式以及在充分利用資源的情況下與盡能夠多的工程利益相關者進展溝通。根據(jù)聽眾的情況，交流普通采取下面三種方式中的一種：強迫性的：包括工程形狀報告、工程預算報告以及已同意的需求。參考性的：給相關人員提供進一步的信息。比如，文檔庫、常見問題列表以及包含相關工程信息的工程站點。營銷性的：這種類型的交流是為了加強大家對工程的熱情。比如，出版工程勝利閱歷、樹立正面籠統(tǒng)、分發(fā)管理引薦信以及運用工程標識。工程經(jīng)理必需自動掌控交流活動，必需有認識的方案并且執(zhí)行交流活動。假設他的交流行為既

23、有效又自動，那么他會發(fā)現(xiàn)整個工程運作將更平穩(wěn)，并且遇到的沖突及妨礙會更少一些。8. 文檔管理許多工程經(jīng)理以為只需當工程中有幾百份文檔時才需求進展文檔管理。實踐上，更好的方法是預先估計一下他以為工程本身以及工程管理能夠產(chǎn)生的文檔資料的數(shù)量，建立一套適當?shù)倪^程和規(guī)那么來組織文檔，并且在工程進展期間進展文檔管理以確保文檔不會失去控制。小型工程的工程經(jīng)理不需求太多思索文檔管理的問題。隨著工程的規(guī)模逐漸變大，工程經(jīng)理就必需求自動管理工程中的文檔資料了。管理文檔時能夠遇到的最普遍的問題就是文檔喪失了或難以找到，以致于在工程終了時要重新書寫。最壞的一種情況是文檔的版本失去了控制，文檔的更新日期過期了、喪失了

24、、混亂了或是無法確定了。文檔管理是工程管理的一個方面，可以運用像文檔庫這樣的工具。然而，假設存儲文檔時沒有運用適當?shù)募夹g，以致于不能方便地存取文檔，那么運用工具只能讓問題更復雜。文檔管理既簡單又復雜。簡單的義務比如說文檔命名商定。假設他的團隊中有10個人，每個人每周提交一份形狀報告，那么很快他就會有成百份的文檔資料了。假設每個人都運用通用的命名規(guī)范，就很容易組織文檔。那么，文檔的稱號應該以每個人的名字開頭嗎？假設這么做，每個人的歷史形狀報告會排在一同，很容易找到。能夠他想找到某個特定時點的形狀報告。這時，形狀報告就應該以時間開頭。這樣一切的形狀報告就按報告周期排在一同。文檔管理的另一個方面是規(guī)

25、定工程運用的文檔管理工具。比如，他能夠?qū)icrosoft Word作為規(guī)范的文檔編輯器。假設他的工程團隊是跨職能的，包括客戶、廠商、供應商，那么文檔管理規(guī)那么就更重要了。要想使文檔管理獲得勝利，有些其它的要素也必需思索。比如，文檔存儲的位置、文檔的組織方法、訪問及平安規(guī)那么、關鍵詞或索引、命名規(guī)范、版本控制、完成形狀、保管或銷毀形狀、備份以及規(guī)范模板。9. 質(zhì)量管理工程及可交付物符合客戶需求和期望的程度表達了質(zhì)量的好壞。換句話說，質(zhì)量的好壞最終要由客戶來評判。工程組應該努力滿足甚至超越客戶的需求和期望。有時候，大家能夠會以為高質(zhì)量就意味著最好的資料和設備，并且零缺陷。然而，大多數(shù)情況下，客戶

26、不會期望而且也負擔不起這樣的完美處理方案。假設工程只是有一些缺陷的話，客戶還是會以為交付的工程是具有高質(zhì)量的。換句話說，一個處理方案設計完美、毫無缺陷，但是并不符合客戶的需求，那么這個方案也不是高質(zhì)量的方案。從質(zhì)量的觀念看來，質(zhì)量管理的目的首先是了解客戶的期望。然后，制定方案及管理過程用以滿足甚至超出客戶的期望。由于質(zhì)量的高低是由客戶來斷定的，因此斷定的規(guī)范看起來是相當?shù)目陀^的。然而，對質(zhì)量的評判也可以很客觀。我們首先需求把“質(zhì)量這個普通術語分解成一些可定義質(zhì)量特征。比如，他能夠以為計算機軟件的質(zhì)量應該按照呼應時間、用戶體驗、易用性、協(xié)助 文檔以及缺陷的多少來衡量。他一旦定義了可以量化的質(zhì)量特

27、征，他就可以判別它們能否可以客觀的衡量質(zhì)量。質(zhì)量管理不是一個單一事件：它是一個過程，一種思想方式。一向高質(zhì)量的產(chǎn)品不能夠出自有缺陷的過程。他需求建立一個先衡量質(zhì)量，而后改良過程的可反復的循環(huán)。想要使質(zhì)量管理過程正常任務，搜集度量非常重要。因此，工程管理第九和第十個方面，也就是質(zhì)量管理和度量管理聯(lián)絡非常嚴密。假設他想做好質(zhì)量管理任務，他就必需度量。一旦工程完成了最初的定義，工程團隊必需求按質(zhì)量要求了解客戶的期望，并且制定相應的來滿足這些期望。要包含完好和正確的關鍵域，以便讓工程團隊了解客戶對質(zhì)量的期望。也會包含兩種通常的質(zhì)量管理過程：質(zhì)量控制和質(zhì)量保證。質(zhì)量控制活動確保工程提交的可交付物符合客戶的期望。例如，檢查那些用于完成最終可交付物的每個組件。質(zhì)量保證活動確保用來創(chuàng)建可交付物的過程是高質(zhì)量的。例如，在最終提交可交付物前，