改良項目管理技術(shù)過程導(dǎo)讀：文中介紹關(guān)于項目管理的一些技術(shù)改良之處，能夠提高管理的效率奇妙之處，并詳盡的列舉出管理中的十個過程。小型項目的管理者其實不需要過多的項目管理知識和項目管理技巧的訓(xùn)練?？墒?，一旦項目的規(guī)模變大了，這些正規(guī)的管理過程和技巧就是項目管理者必備的了。固然不一樣的項目管理方法以不一樣的方式組織并且說了然這些項目管理過程，可是我們?nèi)允窍胫厣甏酥凶罨镜?0個過程：1.定義項目范圍2.擬訂工作計劃3.管理工作計劃4.問題管理5.范圍管理6.風險管理7.交流管理8.文檔管理9.質(zhì)量管理10.胸懷管理一般來說，假如你能掌握這10個領(lǐng)域的知識，你就能在大多半的項目管理中獲取成功。關(guān)于小項目，你可能不需要為文檔或是胸懷管理而擔憂?？墒牵愎芾淼捻椖吭酱?，你就越需要重視這10個過程的管理。你可能已經(jīng)注意到我們列出的10個管理過程中沒有包含剖析、設(shè)計、測試或許部署。那些有些項目工作經(jīng)驗的人或許知道一個項目往常會包含剖析和測試過程。但是，實質(zhì)上這些過程有很大的差異。剖析和測試過程是實質(zhì)項目進度（也稱為項目生命周期）的一部分。跟著項目種類的變化，項目生命周期包含的階段也不一樣。假如你的項目是一個擁有完好的生命周期的項目，你或許就會履行從剖析、設(shè)計、建立、測試到部署的全過程。而在其余種類的項目中，你可能只會波及到此中某些階段。比如，假如你的項目是一個檢查研究項目，你就不會波及到部署的問題。假如你在做一項研究，在做完剖析階段的任務(wù)后，這個項目可能就會結(jié)束了。我們還遺漏了什么？兩個管理過程有時也會做為基本的項目管理過程的一部分：人員管理、合同和采買管理。關(guān)于項目經(jīng)理來說，人員管理是特別重要的技術(shù)，可是關(guān)于項目管理來說，它其實不是必要的。畢竟，在任何對下級的管理中都需要波及人員管理。這此中的差異就是，人員管理是一種項目“經(jīng)理”需要具備的技術(shù)，而不是項目“管理”必要的技術(shù)。在我們這10個項目管理過程列表中也沒有包含合同和采買管理。在大多半組織中，項目經(jīng)理需要了解對合同和供給商的管理狀況，可是他們其實不對此負責。法律部門和（或）采買部門往常負責合同和供給商的管理。時間安排和過程的次序除第一類和第二類——定義項目范圍和擬訂工作計劃——以外，這10個主要的項目管理領(lǐng)域其實不是一個次序履行的過程。從過程3到過程10，你能夠按隨意次序來履行。并且，實質(zhì)上，它們在整個項目中都是并行的，并且是從項目開始到項目結(jié)束向來都在進行的。比如，假如項目出現(xiàn)了一個重要的問題，你就一定忽視掉問題出現(xiàn)以前、出現(xiàn)時期或是出現(xiàn)以后你使用的項目管理的其余過程，而立刻使用問題管理過程。讓我們來認真看看每一個管理過程吧。定義項目范圍做為一個項目經(jīng)理，你一定在項目開始前確立項目的各項工作是簡單被大家理解的，并且已經(jīng)獲取了項目倡始人以及重點的項目利益有關(guān)者們的贊同。你需要和倡始人、項目利益有關(guān)人一同議論這些工作，以保證項目團隊和客戶關(guān)于項目的交托物、項目達成的時間、項目的成本、項目履行團隊、項目的達成方式以及最后獲取的利益達成一致的認識。從項目管理的高層看來，定義項目工作的目的包含：——理解項目目標、可交托物、范圍、風險、成本、方法并且達成一致。這是定義項目工作中最重要的部分，并且大多半的時間都會花在達成一致上?！袛喑跏嫉臉I(yè)務(wù)事例能否仍舊是正確的。比如，一個需要花銷1萬工時的項目可能擁有商業(yè)意義。可是，假如定義工作的過程過于詳盡，就會致使超出2萬小時的精準估量時間，這樣這個項目可能就不再可行了。——保證那些你需要的資源在你需要的時候是可用的?！獢M訂一個高層次的項目基線。依靠這個基線，項目有關(guān)人員能夠比較各個過程的履行狀況，也能夠控制項目的范圍?！c客戶在這個項目所使用的管理過程上達成一致。需要花銷在定義項目工作上的精力取決于需要讓項目有關(guān)人員理解和文檔化的信息量的多少。需要花銷在定義項目工作上的時間取決于認識和文檔化這些信息所必要的時間長短，也取決于需要花銷在獲取客戶的贊同和認同上的時間長短。關(guān)于大型復(fù)雜的項目來說，正確的定義出最后的可交托物可能是特別困難的；預(yù)計出項目總成本和最后的交托日期也是很困難的。假如你管理的是大型復(fù)雜的項目，你能夠把整個項目分紅幾個小型項目。在這些小項目中，需要先做的小項目應(yīng)當更簡單定義出它們的各項工作。那些在將來需要達成的小項目能夠在快履行的時候再詳盡定義出各項工作。在定義項目范圍結(jié)束的時候，你應(yīng)當擬訂出一份《項目定義》。這份文檔從項目的目標、可交托物、范圍、風險、交托日期和項目人員角色等各方面定義了項目的全部希望。這份文檔應(yīng)當在項目團隊開始履行項目以前獲取項目倡始人和其余重點的項目關(guān)連人的正式贊同。擬訂工作計劃在你定義項目的時候，你要保證和項目倡始人在項目應(yīng)當達成的全部工作內(nèi)容上達成一致建議。在擬訂工作計劃這一階段，你將確立達成這些工作的方式。這就需要擬訂《項目計劃》。依據(jù)項目的規(guī)模，你要采納不一樣的方法。比如，擬訂小型項目的工作計劃能夠使用像MicrosoftProject這樣的項目管理工具包、電子制表軟件，甚至一張紙。假如在你開始做計劃的時候，你還沒有可用的工作計劃模板，你能夠使用工作分解構(gòu)造（是一種技術(shù)，它從項目的高層次將工作分解成愈來愈小的部分，直到項目管理者獲取項目工作的完好視圖。整個項目團隊在此基礎(chǔ)上一同工作。我建議將工作分解到較初級別，分解到達成每個不再分解的活動所需的時間不多于80小時，并且達成這個活動所需要的資源也是十分清楚的。

WBS）。WBS一旦你把全部的工作都分解成活動，你就能夠?qū)⑦@些活動排個次序并且確立它們之間的依靠關(guān)系。這時，WBS就轉(zhuǎn)變?yōu)榫W(wǎng)絡(luò)圖（NetworkDiagram）。而后，你需要給每個活動增添資源（即工作人員）。假如你知道某些資源確實切的名字，你能夠以名字增添他們。假如你不知道，你能夠使用通用名來占位。接著，你需要為每個活動增添工時及開始、結(jié)束日期。此刻，你的工作計劃已經(jīng)準備好了。你能夠清楚地認識到你要達成的工作內(nèi)容（《項目定義》）以及你要怎樣達成這些工作（《項目計劃》）。項目定義和項目計劃之間的關(guān)系你會發(fā)現(xiàn)，假如你不開始安排整個《項目計劃》，你就不可以完好的定義出《項目定義》。在很多狀況中，你需要同步辦理這兩個可交托物。在你采集有關(guān)范圍和可交托物的信息時，你需要擬訂一張時間表以便獲取預(yù)估的工時和限期。當你把可交托物、范圍、假定以及方法定義清楚時，你就會獲取足夠的信息以便擬訂《項目計劃》來預(yù)估估量、工時和限期。而后，你能夠用它們來達成《項目定義》。管理計劃這時，你已經(jīng)達成了項目定義和項目計劃。主要的可交托物《項目定義》、《項目計劃》已經(jīng)準備就緒了。有些項目經(jīng)理以為，達成了項目定義和項目計劃意味著項目管理中最困難的部分就達成了。實質(zhì)上狀況明顯不是這樣。假如你不可以連續(xù)更新項目計劃，你永久也不會成為一個成功的項目經(jīng)理。記著，項目計劃不過一個可交托物。項目計劃描繪了需要達成的工作、各項工作的次序、需要的工時數(shù)以及負責人，可是項目計劃不過是你關(guān)于怎樣達成項目的某個特準時點節(jié)余工作的最正確展望。你的項目越復(fù)雜，跟著時間的流逝，項目計劃需要更新的地方就越多。做為一個項目經(jīng)理，你一定要在一個不停變化的基礎(chǔ)上（或許是每周一次）評估項目計劃，判斷項目的目前狀況。在每周一次的回首中，你要在項目計劃中更新已經(jīng)達成以及正在進行的工作的目前狀態(tài)。你要評估那些節(jié)余的工作，看看項目能否能夠依照初始計劃中估量的工時、成本以及限期達成。假如評估的結(jié)果是，項目能夠依照初始計劃達成，那么你的項目目前狀態(tài)優(yōu)秀。反之，你就一定實行糾正舉措。在全部管理項目的技術(shù)中，管理工作計劃或許是最基本的一個。依據(jù)項目的實質(zhì)狀況，你可能要向來使用你的經(jīng)驗和創(chuàng)立力才能使得項目按預(yù)期達成。這個禮拜，你的項目可能還在按計劃進行。下個禮拜，你可能就會碰就任務(wù)緩期和其余問題。假如處在重點路徑上的某個活動緩期了一周，你可不可以傻坐著眼看整個項目緩期一周。相反，你一定評估可用資源以及可能的選擇，讓項目回歸正軌。假如你善于管理工作計劃，那么它將是項目管理中最具挑戰(zhàn)和回報性的工作之一。假如你不喜愛做這些必要的仔細工作，那么你會發(fā)現(xiàn)想要獲取成功就太難了。問題管理當某個麻煩阻擋了項目的履行，“問題”就出現(xiàn)了。沒有外界的幫助，項目經(jīng)理和項目團隊沒法解決“問題”。假如出現(xiàn)的是個嚴重的問題，你除認識決它別無選擇。獨一的問題是你能否能夠踴躍主動的使用問題管理，戰(zhàn)勝舉棋不定以及沒法確立怎樣解決這個問題的困難。問題管原由兩個重要的部分構(gòu)成。第一要經(jīng)歷一個檢盤問題、確立問題對項目影響、考慮可選的解決方案以及率領(lǐng)團隊在這類狀況下做出最正確決議的過程。全部這些項目管理步驟都應(yīng)當提早定義并且獲取一致贊同。這些步驟保證問題能夠有組織地、盡可能快地被解決。問題管理的第二個部分是使用特定的問題解決技巧。這包含一些我們熟習的技巧，比方魚骨圖（Fishbonediagrams）、直方圖（Paretocharts）和根來源因剖析。你可能熟習此中的一個或多個技巧，它們能夠讓你和你的團隊理解問題的實質(zhì)和原由、有哪些可行的解決方法以及哪一個解決方法是最正確的選擇。全部的項目經(jīng)理都認識到的、一個特別重要的事實就是，解決問題需要有個過程，但這其實不意味著你會成功地解決每個問題。有時，解決問題有好多方法，你的工作就是幫助找出哪一個是最好的。有時，一個重要的問題卻沒有好的解決方案，這時，你最好的選擇就是要挑出一個方案，這個方案產(chǎn)生的危害最小或許這個方案在其余更差的方案中是最好的。固然這樣，問題解決過程和問題解決技巧會使你確立哪些選擇是可用的，以便讓你起碼認識到結(jié)果是什么。范圍管理《項目范圍》描繪了項目的界限，定義了項目交托的內(nèi)容、需要的數(shù)據(jù)以及受影響的組織。給定一組資源和時間，就能夠交托無窮的東西。范圍變化管理開始于范圍變化定義。假如項目經(jīng)理沒有做好范圍定義，那么在項目履行時期進行范圍管理將特別困難。范圍變化管理的目的就是要保護目前已獲取贊同的《項目定義》的可行性。一旦定義了項目，某種關(guān)于項目的希望就被設(shè)定了，隨之會產(chǎn)生出相應(yīng)的成本和時間表。在《項目定義》被提交和贊同時，你和項目倡始人就把會這些希望記在心中。在項目履行時期，可能會出現(xiàn)一些與初始的《項目定義》不一樣或許未包含在此中的需求。這類狀況是能夠預(yù)示的。假如真的發(fā)生了，客戶不該當希望這些需求在以前認同的資源和時間限制下也能夠交托。假如需要把新需求包含進《項目定義》，那么項目團隊要剖析這些新需求，判斷它們對項目的影響。而后，這些信息要獲取項目倡始人的贊同。記著，項目倡始人是那個贊同項目啟動資本的人。所以，他或她應(yīng)當也是那個贊同任何項目定義更改的人。假如更改的商業(yè)價值足夠高，那么倡始人應(yīng)當贊同將這些新需求加入項目，同時要增添達成工作所需的估量和時間。而后，每個有關(guān)的人都要贊同并且從頭設(shè)定項目希望。自然，有時狀況其實不會這樣順利。一般會出現(xiàn)以下問題：高出范圍：大規(guī)模的范圍更改是很簡單看出來的。但是，當更改很小時，有時你會發(fā)現(xiàn)你還沒弄理解這些更改就把它們包含進項目了?！案叱龇秶钡囊馑际悄憬邮芰诵「?，結(jié)果漸漸積累的小更改最后給項目造成了顯著的影響。你和你的整個團隊一定當心地對待項目范圍更改，不論更改是大是小。最后用戶對范圍的認同：項目倡始人是為項目付錢的人。但是，一旦項目開始，項目團隊會花銷更多的時間在基層客戶和最后用戶上。有些項目團隊成員以為，最后用戶贊同了范圍更改就能夠了。事實并不是這樣。除非倡始人已經(jīng)明確地將贊同權(quán)授與了最后用戶，不然他們無權(quán)贊同范圍更改。他們能夠提出范圍更改的懇求，可是只有擁有資本權(quán)限的倡始人材能贊同增添的工作。團隊成員不理解自己的職責：致使沒能如期達成項目的一個廣泛的原由是項目團隊成員最后做了比實質(zhì)所需工作更多的工作。比如，某個團隊成員被要求去達成一份報告。在他或她正在撰寫報告時，客戶又要求了新的內(nèi)容。這個團隊成員試圖知足客戶，于是工作最后就緩期了。這類狀況一般發(fā)生在團隊成員以為只有項目經(jīng)理才需要擔憂范圍更改。團隊成員一定理解控制范圍更改是每一個人的責任。對很多不行功項目之所以不行功的根來源因剖析的結(jié)果是它們的范圍更改控制都比較糟糕。有效地定義、管理范圍將增添你的項目切合希望的時機。風險管理風險是指那些不在項目團隊控制之下或是假如它們出現(xiàn)會給項目帶來不利影響的將來的狀況或環(huán)境。換句話說，問題是目前一定辦理的麻煩，而風險一種潛伏的麻煩。被動的項目經(jīng)理在問題出現(xiàn)時解決問題。主動地項目經(jīng)理在問題出現(xiàn)前，努力辨別、解決潛伏的問題。風險管理既是科學(xué)，也是藝術(shù)。因為小型項目往常周期較短，出現(xiàn)問題的可能性就比較少。大型項目往常有隱蔽的風險。風險管理包含辨別出全部項目潛伏的風險、確立它們發(fā)生的可能性，并且清楚地認識假如它們出現(xiàn)的話，對項目造成的影響。依照這些信息，項目團隊能夠確立需要主動管理哪些風險。比如，必定要主動管理那些出現(xiàn)概率高且對項目影響大的風險，而能夠忽視那些出現(xiàn)概率高但對項目影響小的風險。一旦你辨別出了需要主動管理的風險，你就能夠使用下邊這五個往常的做法：別管它。假如你以為某種風險即便出現(xiàn)對你的項目影響也不大，再或許你愿意冒險賭某種風險不會出現(xiàn)，那么你就別管它了。

或許沒什么方法能夠除去某種風險，監(jiān)控風險。在這類狀況下，你無需主動降低風險，可是你要監(jiān)控它，看跟著時間的推移它發(fā)生的可能性增添仍是減少。假如以后某種風險出現(xiàn)的可能性增添了，那么這時候團隊就一定要想方法除去它了。防止風險。防止風險意味著除去那些會引起麻煩的條件。比如，與某個特定供給商有關(guān)的風險可能在選擇了其余供給商后，就能夠防止了。轉(zhuǎn)移風險。在某些狀況下，管理風險的責任可能會從項目組轉(zhuǎn)移給其余實體或第三方機構(gòu)。降低風險。在大多半狀況下，都應(yīng)當這么做。假如已經(jīng)辨別出某個風險或是正擔憂某個風險，那么你應(yīng)當擬訂一個主動辦理的計劃以保證它不會發(fā)生。正如范圍更改同樣，一個項目不行能沒有風險。客戶也不會希望一個項目沒有風險。問題是項目管理對風險的反響。假如進行了風險辨別并且主動管理風險，項目就更可能會獲取成功。假如忽視可能出現(xiàn)的風險，在風險轉(zhuǎn)變?yōu)閱栴}時，項目只好被動的遇到影響。這時，可能只有極少的解決方法能防止項目遇到影響了。交流管理在項目中，合適的交流關(guān)于管理客戶和利益有關(guān)人是至關(guān)重要的。假如客戶和利益有關(guān)人們沒能實時認識到項目的進展狀況，那么因為他們對項目擁有的不一樣希望值，可能會增添項目出現(xiàn)問題和困難的可能。實質(zhì)上，在很多狀況中，出現(xiàn)矛盾其實不是因為實質(zhì)的問題，而是因為客戶和管理者早先不知情。項目中的交流有兩個層次。第一，全部的項目都應(yīng)當交流。第二，假如你的項目更大更復(fù)雜、或許與政治有關(guān)，那么你所要進行的交流通常更為高級和復(fù)雜，所以你需要擬訂一個《交流計劃》。項目狀態(tài)會講和項目狀態(tài)報告全部的項目都需要有效地交流，不論是從項目團隊到項目經(jīng)理，仍是從項目經(jīng)理到其余的利益有關(guān)人。項目狀態(tài)報告和項目狀態(tài)會議不不過是用來報告項目正常進展的，還有其余的事情要做。從項目狀態(tài)報告和項目狀態(tài)會議你能夠認識到全部你需要知道的和項目有關(guān)的全部。你要交流固守項目估量實時間表的理念，要交流在近來一次報告期內(nèi)達成的工作，要交流下一個報告期內(nèi)計劃達成的工作、新風險、目前的問題，以及目前的范圍更改懇求。傳達信息和發(fā)言都一定考慮到你的觀眾。所以，你最好和你的項目團隊每周召開一次項目狀態(tài)會議，會議上應(yīng)當包含一些特別細節(jié)的議論。你發(fā)送給倡始人和管理類利益有關(guān)人的狀態(tài)報告必定要簡潔且高度歸納。交流計劃重要決定，特別是那種要求組織改革的決定一定包含一個全面的交流計劃，這份交流計劃將采納多種交流方式。擬訂交流計劃的過程包含確認全部的利益有關(guān)人、確立他們需要獲取的項目信息、集思廣益散發(fā)信息的方式以及在充分利用資源的狀況下與盡可能多的項目利益有關(guān)者進行交流。依據(jù)聽眾的狀況，交流一般采納下邊三種方式中的一種：強迫性的：包含項目狀態(tài)報告、項目估量報告以及已贊同的需求。參照性的：給有關(guān)人員供給進一步的信息。比方，文檔庫、常有問題列表以及包含有關(guān)項目信息的項目站點。營銷性的：這類種類的交流是為了加強盛家對項目的熱忱。比方，第一版項目成功經(jīng)驗、建立正面形象、散發(fā)管理介紹信以及使用項目表記。項目經(jīng)理一定主動掌控交流活動，一定存心識的計劃并且履行交流活動。假如你的交流行為既有效又主動，那么你會發(fā)現(xiàn)整個項目運作將更安穩(wěn)，并且碰到的矛盾及阻礙會更少一些。文檔管理很多項目經(jīng)理以為只有當項目中有幾百份文檔時才需要進行文檔管理。實質(zhì)上，更好的方法是早先預(yù)計一下你以為項目自己以及項目管理可能產(chǎn)生的文檔資料的數(shù)目，成立一套合適的過程和規(guī)則來組織文檔，并且在項目進行時期進行文檔管理以保證文檔不會失掉控制。小型項目的項目經(jīng)理不需要太多考慮文檔管理的問題。跟著項目的規(guī)模漸漸變大，項目經(jīng)理就一定要主動管理項目中的文檔資料了。管理文檔時可能碰到的最廣泛的問題就是文檔丟掉了或難以找到，以致于在項目結(jié)束時要從頭書寫。最壞的一種狀況是文檔的版本失掉了控制，文檔的更新日期過期了、丟掉了、雜亂了或是沒法確立了。文檔管理是項目管理的一個方面，能夠使用像文檔庫這樣的工具。但是，假如儲存文檔時沒有使用合適的技術(shù)，以致于不可以方便地存取文檔，那么使用工具只好讓問題更復(fù)雜。文檔管理既簡單又復(fù)雜。簡單的任務(wù)比方說文檔命名商定。假如你的團隊中有10個人，每一個人每周提交一份狀態(tài)報告，那么很快你就會有成百份的文檔資料了。假如每一個人都使用通用的命名規(guī)范，就很簡單組織文檔。那么，文檔的名稱應(yīng)當以每一個人的名字開頭嗎？假如這么做，每一個人的歷史狀態(tài)報告會排在一同，很簡單找到?？赡苣阆胝业侥硞€特準時點的狀態(tài)報告。這時，狀態(tài)報告就應(yīng)當以時間開頭。這樣全部的狀態(tài)報告就按報告周期排在一同。文檔管理的另一個方面是規(guī)定項目使用的文檔管理工具。比方，你可能將MicrosoftWord作為標準的文檔編寫器。假如你的項目團隊是跨職能的，包含客戶、廠商、供給商，那么文檔管理規(guī)則就更重要了。要想使文檔管理獲得成功，有些其余的要素也一定考慮。比方，文檔儲存的地點、文檔的組織方法、接見及安全規(guī)則、重點詞或索引、命名標準、版本控制、達成狀態(tài)、保存或銷毀狀態(tài)、備份以及標準模板。質(zhì)量管理項目及可交托物切合客戶需乞降希望的程度表現(xiàn)了質(zhì)量的利害。換句話說，質(zhì)量的利害最后要由客戶來評判。項目組應(yīng)當努力知足甚至超出客戶的需乞降希望。有時，大家可能會以為高質(zhì)量就意味著最好的資料和設(shè)施，并且零缺點。但是，大多半狀況下，客戶不會希望并且也負擔不起這樣的完滿解決方案。假如項目不過有一些缺點的話，客戶仍是會以為交托的項目是擁有高質(zhì)量的。換句話說，一個解決方案設(shè)計完滿、毫無缺點，可是其實不切合客戶的需要，那么這個方案也不是高質(zhì)量的方案。從質(zhì)量的看法看來，質(zhì)量管理的目的第一是理解客戶的希望。而后，擬訂計劃及管理過程用以知足甚至高出客戶的希望。因為質(zhì)量的高低是由客戶來判斷的，所以判斷的標準看起來是相當?shù)闹饔^的。但是，對證量的評判也能夠很客觀。我們第一需要把“質(zhì)量”這個一般術(shù)語分解成一些可定義質(zhì)量特點。比方，你可能以為計算機軟件的質(zhì)量應(yīng)當依照響應(yīng)時間、用戶體驗、易用性、幫助文檔以及缺點的多少來權(quán)衡。你一旦定義了能夠量化的質(zhì)量特點，你就能夠判斷它們能否能夠客觀的權(quán)衡質(zhì)量。質(zhì)量管理不是一個單調(diào)事件：它是一個過程，一種思想模式。一向高質(zhì)量的產(chǎn)品不行能出自出缺點的過程。你需要成立一個先權(quán)衡質(zhì)量，爾后改良過程的可重復(fù)的循環(huán)。想要使質(zhì)量管理過程正常工作，采集胸懷特別重要。所以，項目管理第九和第十個方面，也就是質(zhì)量管理和胸懷管理聯(lián)系特別密切。假如你想做好質(zhì)量管理工作，你就一定胸懷。一旦項目達成了最先的定義，項目團隊一定要按質(zhì)量要求理解客戶的希望，并且擬訂相應(yīng)的《質(zhì)量計劃》來知足這些希望?！顿|(zhì)量計劃》要包含完好和正確的重點域，以便讓項目團隊認識客戶對證量的希望?！顿|(zhì)量計劃》也會包含兩種往常的質(zhì)量管理過程：質(zhì)量控制和質(zhì)量保證。質(zhì)量控制活動保證項目提交的可交托物切合客戶的希望。比如，檢查那些用于達成最后可交托物的每個組件。質(zhì)量保證活動保證用來創(chuàng)立可交托物的過程是高質(zhì)量的。