大型專案管理論文
隨著城市化程序的不斷加快,越來越多的建設工程專案日趨複雜,體量逐漸龐大,投資不斷加大;而且專案與專案間的制約關係越來越突顯。下面是小編為大家整理的，供大家參考。
範文一：淺談系統整合專案的進度管理
【摘要】本文以本人管理的某大型醫院檢驗樣品管理系統的開發、實施為例項，探討了資訊系統專案的進度管理，總結了該專案進度管理中運用的基本原則和相關具體措施。結合專案實際情況指出，做好專案管理要有紮實深厚的專案管理理論基礎，要能結合專案實際情況靈活運用這些理論知識，要站在專案整體的角度去看待和實施專案的進度管理。
文中，從專案各階段總體規劃原則、工作結構分解策略、計劃安排、任務分配與跟蹤、實際進度資料分析以及專案管理其他方面對進度管理的影響與作用等方面，根據自身經驗教訓和專案實際情況進行總結和闡述。
【正文】
2010年，某大型醫院為加強檢驗樣品***病人化驗的血樣、尿樣等檢測樣品***的管理，招標一套檢驗樣品管理系統。我公司中標後指派我為專案經理，負責該專案的開發與實施。
這套系統包含了檢驗樣品射頻標籤匹配、識別與跟蹤，檢驗專案分組與資訊確認，檢驗資料的傳遞與儲存，檢驗報告的編制與審批、列印等主要環節，同時還需要與醫院現有的HIS***醫院資訊管理系統***進行介面連線。由於醫院規模比較大，布點多，從設計開發到現場施工工程量都是比較大的。另外，雖然射頻識別***RFID***技術本身已經比較成熟，但對於我們團隊來說還沒有足夠的相關經驗，而且由於各種原因留給我們總共的時間只有6個多月。任務重、時間緊，在保證質量的前提下，專案進度控制無疑是該專案的重中之重。
面對專案的實際情況，我靈活運用所學的專案管理知識，採取相應措施，在合同要求的工期內比較圓滿的完成了該專案，目前該專案執行穩定，客戶非常滿意。我主要採取了以下的具體措施。
第一，總體上合理規劃各個環節的時間安排和工時投入，適當加大調研、需求、概要設計以及測試階段的工時投入，控制開發實現以及安裝實施階段的工時投入。
對於時間緊急的專案，我們的慣性思維往往要求我們急於開展開發、編碼等所謂的“實質”工作，而不由自主的縮減調研、需求、概要設計以及測試等所謂“虛”的環節。但這樣往往適得其反，也不符合專案管理的客觀規律。如果調研不足，可能導致開發過程中出現意想不到的技術問題;如果需求與客戶沒有足夠的溝通並明確，可能導致重大功能模組的調整;如果概要設計做得不充分，可能導致系統架構級的問題;如果測試不充分，更可能導致施工除錯過程中的巨大反覆。而如果沒有充分的前期投入，所有這些問題在其產生的階段都是隱匿的，在後續階段才會逐步顯露出來，而問題一旦出現，其影響和問題已經嚴重擴散，後續的補救工作至少需要花費幾倍甚至十幾倍的時間和成本來彌補，嚴重時這無疑將導致專案進度的失控。對於像該專案這樣時間要求緊迫的專案來說，是容不得出現較大的反覆的，嚴重時可能將導致專案的徹底失敗。
與之相對的，開發實現階段雖然是專案的實質主體，也是我們經驗最豐富也最擅長的部分，在解決了關鍵的技術障礙之後其實是最容易控制的部分。同時，前面各階段，尤其是測試足夠充分的話安裝實施自然就會比較順利。
從效果看，這個策略很好的保證了專案的整體進度，各階段進展都相對比較順利。 第二，對於影響專案進度的任何不確性因素，務必第一時間、第一優先順序解決處理。 在工作結構分解與安排上，對於此類問題不能按部就班的進行排序安排，務必儘可能向前安排，向高優先順序安排。因為對我們不確定不熟悉的各項因素有可能很容易解決，更有可能稱為棘手的障礙，我們識別發現的越早，我們的主動性就越強，留給我們的反應和處理時間也就越多，從而便於我們調整和控制專案的進度。而這些問題一旦在專案的中後段才得以發現，對專案的影響很可能是顛覆性的。
在該專案中我們對於醫院業務不熟悉，對於RFID技術沒有足夠經驗，不確定在採購成品的基礎上是否需要二次開發等。因此，除了如上面所說的提前和加大需求、調研階段的投入外，在完成對RFID的調研之後立即安排硬體測試工作，排除和確認我們所不熟悉的技術問題和障礙，而不是安排在軟體開發完成之後進行統一測試。而事實也證明，我們調研後預選的方案和供應商雖然從書面的效能引數等方面完全符合要求，但實際測試中漏讀率還是達不到我們的要求。而由於我們提前測試，發現問題時我們總體需求分析階段還沒結束，也因此我們有足夠的時間重新選型採購，從而基本沒有對專案進度造成明顯影響。
第三，計劃安排要有一定的彈性，有一定的調整和控制餘量。
除了首先確定好序列進行的關鍵路徑任務外，要充分靈活安排與其他任務關聯度不強的工作任務***我稱之為“遊離任務”***，計劃中給予此類任務足夠的“遊離”空間，使其能在關鍵任務提前完成，或關鍵人力資源有空餘時可以穿插安排，以充分利用人力資源;而在關鍵任務一旦延期或關鍵人力資源緊張時可以適當調整其時間安排，以釋放部分人力資源，保證關鍵路徑的進度和人力資源的充分利用。
第四，利用相關工具軟體***如PROJECE等***，定期***如一週***關注專案進展相關資料，關注專案進度趨勢，提前預判並決定是否及如何幹預。
比如，專案延期可能不大並完全在可接受範圍內，但連續兩週在擴大，就需要加強關注，分析原因提前採取措施，以免失控。當然，俗話說“計劃不如變化快”，任何計劃在實施過程中都不可能完全依照計劃進行，必然會出現不同程度的偏離。但是否是偏離就一定要干預一定要糾正呢，當然不是。因此要分析對計劃的偏離是否可控，呈現何種趨勢。在可控範圍內就沒有必要過多幹預，以免過度管理降低工作效率和造成時間浪費。因此干預調整的程度需要把握在一個合適的火候，除了經驗之外，很重要的就是多利用工具軟體提供的相關資料，進行分析和判斷，找出趨勢和原因。
第五，對工作結構的分解粒度要適中，不能過大也不能過小，過大不易控制，過小容易產生過渡管理降低效率。
對於該專案我基本掌握在工期在一週左右，以最大不大於兩週，最小不小於3個工作日為原則進行分解。專案組一共6人，在這個規模上，實際的經驗告訴我這個粒度時相對比較合適的，可以保證比較有效的跟蹤管理，同時我還可以有一定的時間負擔一些技術工作。
第六，工作任務按工作結構分解情況以任務單的形式安排跟蹤，任務單下發到具體組員，避免將同一執行人的多個任務打包安排。
我在專案中堅持按上述工作結構分解後的任務進行單任務的分配跟蹤，而不是幾個相關任務打包安排、跟蹤。因為如果將同一執行人的幾個任務打包安排，看似節約時間，但實際經驗告訴我，這樣很容易造成這些任務與其相關聯任務***尤其是與別人關聯的任務***的不同程度的脫節。因為作為同一執行人在執行幾個任務時重點考慮的時保證這一包任務的總體完成情況，會忽視單個任務的時間進度要求。而專案總體控制要求任務之間的關聯關係，儘管這種關聯關係的脫節不會很嚴重，但會比較普遍。而且這些任務有超前有延後，從總體上不容易發現問題。但正是由於任務關聯脫節的比較普遍，經過一定時間的積累很容易產生影響專案整體進度的大問題，而當問題比較明顯時，往往已經很難調整和控制了。
第七，上述任務安排基礎上，除安排需要執行的任務外，還要預先安排下一項工作任務。 這和上面的論述是否矛盾呢?不是的。這裡的預安排只是告知執行人下一個要執行的任務是什麼，而不進行實質安排，這樣做的目的主要有兩個，首先是執行人可以預先在腦子裡構思下一個任務***主要是潛在的，不由自主的***，待實際執行時會提高效率或提前識別發現問題;其次是一旦由於工作衝突或其他原因工作未能及時安排時，執行人完成當前任務就可以執行下一個任務，避免人等任務的情況出現。
第八，專案中採取早會、周例會結合的例行溝通模式，強調及時溝通、快速反應。 我們每天利用早晨10分鐘左右時間，專案組互相通報一下前一天的工作情況和問題。目的是及時掌握專案進展動態和問題，以便及時採取措施提高專案組反應的敏捷度。但早會上主要是溝通和識別問題，不對具體問題做展開討論，如有需要再專題安排。周例會主要分析專案進展的重大問題和進展趨勢，討論和決策相關措施。但要注意引導避免早會、例會形成形式主義，尤其是例會在專案進展順利時可以縮短時間或隔週召開。
第九，專案管理是一個整體，要做好專案的進度管理必須有其他方面的相輔相成。 比如上面提到了的關於溝通管理、人力資源管理等方面的措施。此外，比如質量管理也是有效保證進度的重要一環，尤其是在產品實現方面的質量管理工作，畢竟不出問題不返工才是最節約時間最有效率的。我們專案益於我公司多年貫徹執行ISO9000標準和CMM5級的軟體成熟模型，給予我們強有力的保障。再比如，變更管理也是影響進度的很重要部分，專案執行過程中通常都會有各種各樣的變更，如何在受控的前提下快捷又有效的進行變更是提高效率的必要手段。在該專案中，我根據變更的型別、涉眾等對專案的變更分成不同的級別，採取不同的控制、管理及審批措施和程式，在保證變更合理受控的前提下有效地提高了變更效率降低了變更帶來的負面影響。
在這些措施及專案組成員的團隊配合及共同努力下，我們按時保質保量的完成了專案，贏得了客戶的讚譽，目前該系統執行穩定，反饋良好。
總之，要做好專案的進度管理首先要有紮實的專案管理知識和經驗，在此基礎上要充分從基礎理論出發結合專案的實際情況進行靈活變通的應用，制定和採取具體的措施來控制專案的進度，不能生搬硬套，畢竟專案管理理論是高度總結和抽象化的東西，不是萬能公式。另外，要做好專案的進度管理一定要站在專案整體的角度去考慮問題，專案管理是一個整體的系統工程，各個領域和方面都是相輔相成的，不能獨立存在，需要相互協調與配合。
範文二：軟體專案管理綜述
一.引言
隨著計算機技術的飛速發展，軟體產品的規模越來越龐大，個人單打獨鬥的開發模式已經越來越不能適應實際的需要。因此各軟體企業在軟體開發活動中紛紛引入軟體專案管理相關技術，使得開發過程得到有效的實行與管理。以現今中國的百度，騰訊，阿里巴巴等軟體公司為例，在這些公司中針對大型專案開發時都實行了專案管理制度，並把軟體專案管理作為整個專案管理中的一個重要組成部分。從概念上講，軟體專案管理是為了使軟體專案能夠按照預定的成本、進度、質量順利完成，而對成本、人員、進度、質量、風險等進行分析和管理的活動。實際上，軟體專案管理的意義不僅僅如此，進行軟體專案管理有利於將開發人員的個人開發能力轉化成企業的開發能力，企業的軟體開發能力越高，表明這個企業的軟體生產越趨向於成熟，企業越能夠穩定發展***即減小開發風險***。軟體開發不同於其他產品的製造，軟體的整個過程都是設計過程***沒有製造過程***;另外，軟體開發不需要使用大量的物質資源，而主要是人力資源;並且，軟體開發的產品只是程式程式碼和技術檔案，並沒有其他的物質結果。基於上述特點，軟體專案管理與其他專案管理相比，有很大的特殊性。
二.什麼是軟體專案管理
軟體專案管理是為了使軟體專案能夠按照預定的成本、進度、質量順利完成，而對成本、人員、進度、質量、風險等進行分析和管理的活動。
軟體專案管理的根本目的是為了讓軟體專案尤其是大型專案的整個軟體生命週期***從分析、設計、編碼到測試、維護全過程***都能在管理者的控制之下，以預定成本按期，按質的完成軟體交付使用者使用。而研究軟體專案管理為了從已有的成功或失敗的案例中總結出能夠指導今後開發的通用原則，方法，同時避免前人的失誤。
軟體專案管理的概念是在20世紀70年代中期由美國提出的，當時美國國防部專門研究了軟體開發不能按時提交，預算超支和質量達不到使用者要求的原因，結果發現70%的專案是因為管理不善引起的，而非技術原因。於是軟體開發者開始逐漸重視起軟體開發中的各項管理。到了20世紀90年代中期，軟體研發專案管理不善的問題仍然存在。據美國軟體工程實施現狀的調查，軟體研發的情況仍然很難預測，大約只有10%的專案能夠在預定的費用和進度下交付。
1995年，據統計，美國共取消了810億美元的商業軟體專案，其中31%的專案未做完就被取消，53%的軟體專案進度通常要延長50%的時間，只有9%的軟體專案能夠及時交付並且費用也控制在預算之內。
軟體專案管理和其他的專案管理相比有其自有的特殊性。首先，軟體是純知識型產品，不同於實際工程，其開發進度和質量很難估計和度量，生產效率也難以預測和保證。其次，軟體系統的複雜性也導致了開發過程中各種風險的難以預見和控制。Windows這樣的作業系統有1500萬行以上的程式碼，同時有數千個程式設計師在進行開發，專案經理都有上百個。這樣龐大的系統如果沒有很好的管理，其軟體質量是難以想象的。
軟體專案管理的內容主要包括如下幾個方面：人員的組織與管理，軟體度量，軟體專案計劃，風險管理，軟體質量保證，軟體過程能力評估，軟體配置管理等。這幾個方面都是貫穿、交織於整個軟體開發過程中的，其中人員的組織與管理把注意力集中在專案組人員的構成、優化;軟體度量把關注用量化的方法評測軟體開發中的費用、生產率、進度和產品質量等要素是否符合期望值，包括過程度量和產品度量兩個方面;軟體專案計劃主要包括工作量、成本、開發時間的估計，並根據估計值制定和調整專案組的工作;風險管理預測未來可能出現的各種危害到軟體產品質量的潛在因素並由此採取措施進行預防;質量保證是保證產品和服務充分滿足消費者要求的質量而進行的有計劃，有組織的活動;軟體過程能力評估是對軟體開發能力的高低進行衡量;軟體配置管理針對開發過程中人員、工具的配置、使用提出管理策略。因為大家對人力資源管理和軟體過程能力比較有興趣，下面就詳細的對這兩方面展開討論。
三、軟體專案管理的組織模式
軟體專案可以是一個單獨的開發專案，也可以與產品專案組成一個完整的軟體產品專案。如果是訂單開發，則成立軟體專案組即可;如果是產品開發，需成立軟體專案組和產品專案***負責市場調研和銷售***，組成軟體產品專案組。公司實行專案管理時，首先要成立專案管理委員會，專案管理委員會下設專案管理小組、專案評審小組和軟體產品專案組。 3.1、專案管理委員會專案管理委員會是公司專案管理的最高決策機構，一般由公司總經理、副總經理組成。主要職責如下：***1***依照專案管理相關制度管理專案;***2***監督專案管理相關制度的執行;
***3***對專案立項、專案撤消進行決策;***4***任命專案管理小組組長、專案評審委員會主任、專案組組長. 3.2、專案管理小組專案管理小組對專案管理委員會負責，一般由公司管理人員組成。主要職責如下：***1***草擬專案管理的各項制度;***2***組織專案階段評審;***3***儲存專案過程中的相關檔案和資料;***4***為優化專案管理提出建議。 3.3、專案評審小組專案評審小組對專案管理委員會負責，可下設開發評審小組和產品評審小組，一般由公司技術專家和市場專家組成。主要職責如下：***1***對專案可行性報告進行評審;***2***對市場計劃和階段報告進行評審;***3***對開發計劃和階段報告進行評審;***4***專案結束時，對專案總結報告進行評審。 3.4、軟體產品專案組軟體產品專案組對專案管理委員會負責，可下設軟體專案組和產品專案組。軟體專案組和產品專案組分別設開發經理和產品經理。成員一般由公司技術人員和市場人員構成。主要職責是：根據專案管理委員會的安排具體負責專案的軟體開發和市場調研及銷售工作。
四、軟體專案管理的內容
從軟體工程的角度講，軟體開發主要分為六個階段：需求分析階段、概要設計階段、詳細設計階段、編碼階段、測試階段、安裝及維護階段。不論是作坊式開發，還是團隊協作開發，這六個階段都是不可缺少的。根據公司實際情況，公司在進行軟體專案管理時，重點將軟體配置管理、專案跟蹤和控制管理、軟體風險管理及專案策劃活動管理四方面內容匯入軟體開發的整個階段。在20世紀80年代初，著名軟體工程專家B.W.Boehm總結出了軟體開發時需遵循的七條基本原則，同樣，在進行軟體專案管理時，也應該遵循這七條原則。它們是：
***1***用分階段的生命週期計劃嚴格管理;
***2***堅持進行階段評審;
***3***實行嚴格的產品控制;
***4***採用現代程式設計技術;
***5***結果應能夠清楚地審查;
***6***開發小組地人員應該少而精;
***7***承認不斷改進軟體工程實踐的必要性。
五、編寫《軟體專案計劃書》
專案組成立的第一件事是編寫《軟體專案計劃書》，在計劃書中描述開發日程安排、資源需求、專案管理等各項情況的大體內容。計劃書主要向公司各相關人員發放，使他們大體瞭解該軟體專案的情況。對於計劃書的每個內容，都應有相應具體實施手冊，這些手冊是供專案組相關成員使用的。
六、軟體配置管理
軟體根據規模來決定是否進行配置管理，軟體的規模越大，配置管理就越重要。軟體配置管理簡稱SCM***Software Configuration Management的縮寫***，是在團隊開發中，標識、控制和管理軟體變更的一種管理。配置管理的使用取決於專案規模和複雜性以及風險水平。
6.1、目前軟體開發中面臨的問題:在有限的時間、資金內，要滿足不斷增長的軟體產品質量要求;開發的環境日益複雜，程式碼共享日益困難，需跨越的平臺增多;程式的規模越來越大;軟體的重用性需要提高;軟體的維護越來越困難。
6.2、軟體配置管理應提供的功能:
在ISO9000.3中，對配置管理系統的功能作了如下描述：唯一地標識每個軟體項的版本;標識共同構成一完整產品的特定版本的每一軟體項的版本;控制由兩個或多個獨立工作的人員同時對一給定軟體項的更新;控制由兩個或多個獨立工作的人員同時對一給定軟體項的更新;按要求在一個或多個位置對複雜產品的更新進行協調;標識並跟蹤所有的措施和更改;這些措施和更改是在從開始直到放行期間，由於更改請求或問題引起的。
6.3、版本管理軟體配置管理分為版本管理、問題跟蹤和建立管理三個部分，其中版本管理是基礎。版本管理應完成以下主要任務：
建立專案;
重構任何修訂版的某一項或某一檔案;
利用加鎖技術防止覆蓋;•當增加一個修訂版時要求輸入變更描述; •提供比較任意兩個修訂版的使用工具;
採用增量儲存方式;
提供對修訂版歷史和鎖定狀態的報告功能;
提供歸併功能;
允許在任何時候重構任何版本;
許可權的設定;
晉升模型的建立;
提供各種報告。
七.人員組織與管理
軟體開發人員對軟體來說是最大的資源。軟體整個過程中對人員的配置、排程安排至關重要，人員的組織管理是否得當，將決定軟體專案質量的好壞。 首先在軟體開發的一開始，要合理的配置人員，根據專案的工作量、所需要的專業技能，再參考各個人員的能力、性格、經驗，組織一個高效、和諧的開發小組。一般來說，一個開發小組人數在5到10人之間最為合適，如果專案規模很大，可以採取層級式結構，配置若干個這樣的開發小組。
在選擇人員的問題上，要結合實際情況來決定是否選入一個開發組員。並不是一群高水平的程式設計師在一起就一定可以組成一個成功的小組。作為考察標準，技術水平、與本專案相關的技能和開發經驗、以及團隊工作能力都是很重要的因素。一個一天能寫一萬行程式碼但卻不能與同事溝通融洽的程式設計師，未必適合一個對組員之間通訊要求很高的專案。還應該考慮分工的需要，合理配置各個專項的人員比例。例如一個網站開發專案，小組中有頁面美工、後臺服務程式、資料庫幾個部分，應該合理的組織各項工作的人員配比。對於一箇中型農技110網站，對資料採集量要求較高，一個人員配比方案可以是2個美工、2個後臺服務程式編寫、3個數據採集整理人員。
在決定一個開發組的開發人員數量時，除了考慮候選人素質以外，還要綜合考慮專案規模、工期、預算、開發環境等因素的影響，下面是一個基於規模、工期和開發環境的人員數量計算公式：
L=Ck*K1/3*td4/3
L:開發規模，以程式碼行LOC為度量td:開發時間K：人員數
Ck：技術常數表示開發環境的優劣
取值2000：表示開發環境差，沒有系統的開發方法，缺乏文件規範化設計; 取值8000：表示開發環境較好;
取值11000：表示開發環境優。
在組建開發組時，還應充分估計到開發過程中的人員風險。由於工作環境、待遇、工作強度、公司的整體工作安排和其他無法預知的因素，一個專案尤其是開發週期較長的專案幾乎無可避免的要面臨人員的流入流出。如果不在專案初期對可能出現的人員風險進行充分的估計，作必要的準備，一旦風險轉化為現實，將有可能給整個專案開發造成巨大的損失。以較低的代價進行及早的預防是降低這種人員風險的基本策略。具體來說可以從以下幾個方面對人員風險進行控制： a.保證開發組中全職人員的比例，且專案核心部分的工作應該儘量由全職人員來擔任， 以減少兼職人員對專案組人員不穩定性的影響。
b.建立良好的文件管理機制，包擴專案組進度文件、個人進度文件、版本控制文件、整體技術文件、個人技術文件、原始碼管理等。一旦出現人員的變動，比如某個組員因病退出，替補的組員能夠根據完整的文件儘早接手工作。 c.加強專案組內技術交流，比如定期開技術交流會，或根據組內分工建立專案組內部的開發小組，是開發小組內的成員能夠相互熟悉對方的工作和進度，能夠在必要的時候替對方工作。
d.對於專案經理，可以從一開始就指派一個副經理在專案中協同專案經理管理專案開發工作，如果專案經理退出開發組，副經理可以很快接手。但是隻建議在專案經理這樣的高度重要的崗位採用這種冗餘複製的策略來預防人員風險，否則將大大增加專案成本。
e.為專案開發提供儘可能好的開發環境，包括工作環境、待遇、工作進度安排等等，同 時一個優秀的專案經理應該能夠在專案組內營造一種良好的人際關係和工作氛圍。良好的開發環境對於穩定專案組人員以及提高生產效率都有不可忽視的作用。
八.軟體過程能力評估
軟體過程能力描述了一個開發組織開發軟體開發高質量軟體產品的能力。現行的國際標準主要有兩個：ISO9000.3和CMM。
ISO9000.3是ISO9000質量體系認證中關於計算機軟體質量管理和質量保證標準部分。它從管理職責、質量體系、合同評審、設計控制、檔案和資料控制、採購、顧客提供產品的控制、產品標識和可追溯性、過程控制、檢驗和試驗、檢驗/測量和試驗裝置的控制、檢驗和試驗狀態、不合格品的控制、糾正和預防措施、搬運/貯存/包裝/防護和交付、質量記錄的控制、內部質量稽核、培訓、服務、統計系統等二十個方面對軟體質量進行了要求。
CMM***能力成熟度模型***是美國卡納基梅隆大學軟體工程研究所***CMU/SEI***於1987年提出的評估和指導軟體研發專案管理的一系列方法，用5個不斷進化的層次來描述軟體過程能力。現在CMM是2.0版本。
ISO9000和CMM的共同點是二者都強調了軟體產品的質量。所不同的是，ISO9000強調的是衡量的準則，但沒有告訴軟體開發人員如何達到好的目標，如何避免差錯。CMM則提供了一整套完善的軟體研發專案管理的方法。它可告訴軟體開發組織，如果要在原有的水平上提高一個等級，應該關注哪些問題，而這正是改進軟體過程的工作。
CMM描述了五個級別的軟體過程成熟度***初始級，可重複級，已定義級，已定量管理級，優化級***，成熟度反映了軟體過程能力的大小。
初始級特點是軟體機構缺乏對軟體過程的有效管理，軟體過程是無序的，有時甚至是混亂的，對過程幾乎沒有定義，其軟體專案的成功來源於偶爾的個人英雄主義而非群體行為，因此它不是可重複的;可重複級的特點是軟體機構的專案計劃和跟蹤穩定，專案過程可控，專案的成功是可重複的;已定義級的特點在於軟體過程已被提升成標準化過程，從而更加具有穩定性、可重複性和可控性;已定量管理級的軟體機構中軟體過程和軟體產品都有定量的目標，並被定量地管理，因而其軟體過程能力是可預測的，其生產的軟體產品是高質量的;優化級的特點是過程的量化反饋和先進的新思想、新技術促進過程不斷改進，技術和過程的改進改進被作為常規的業務活動加以計劃和管理。
CMM是科學評價一個軟體企業開發能力的標準，但要達到較高的級別也非常困難，根據1995年美國所做的軟體產業成熟度的調查，在美國的軟體產業中，CMM成熟度等級為初始級的竟佔70%，為可重複級的佔15%，為定義級的所佔比例小於10%，為管理級的所佔比例小於5%，為優化級的所佔比例小於l%。而國內企業的水平就更加堪優，到目前為止，只有東軟一家達到優化級，少數幾家能夠達到可定義級。儘快改變這種局面，科學化、規範化、高效的進行軟體開發活動，從整體提高我國軟體行業的水平，是國內軟體企業的當務之急，也是專業人員應該為自己制定的目標。如果有一天也能指揮一個數千人的龐大開發隊伍，操作Windows這樣巨型規模的軟體專案，並生產出高質量的產品，才有理由宣稱自己的軟體專案管理能力達到了一個“自主自足”的水平。