“項目”，在二千多年之前就已經存在。著名的埃及金字塔、我國的萬里長城都是國際上眾人稱頌的典型項目。項目管理發展到今天，應用相對成功的領域主要是在土木工程上，現已逐步應用于軟件工程、航空、國防、金融、體育等行業。
一般來說，“項目”具有技術復雜，參與的人員還眾多，時間又非常緊迫，因此，人們開始關注如何有效地實行項目管理來實現既定的目標。在這里，主要談談在軟件工程領域中項目管理的運用，也就是項目管理能夠給人們提供一種解決問題的思路和方法。
I. 當前項目管理存在的問題
一項調查表明，大約70%的軟件開發項目超出了估算的時間，大型項目平均超出計劃交付時間20%至50%，90%以上的軟件項目開發費用超出預算，并且項目越大，超出項目計劃的程度越高。國內絕大多數的IT企業正或多或少地承受著“項目黑洞”的痛楚：項目無法按期完成、項目合作方的工作難以協調、用戶需求經常變動、工作質量難以保證。很多企業常常抱怨說，我們的技術實力不比國外差，我們的員工也很努力，但是我們的產品和工作效率為什么總比不上國外？
諸如此類的問題，就是當前軟件開發中，實現項目管理實施時帶來的問題。雖然，項目管理在土木工程中，項目管理在中國已經實施得十分成熟。但是，軟件開發不同于其他產品的制造，軟件的整個過程都是設計過程（沒有制造過程）；另外，軟件開發不需要使用大量的物質資源，而主要是人力資源；并且，軟件開發的產品只是程序代碼和技術文件，并沒有其他的物質結果。基于上述特點，軟件項目管理與其他項目管理相比，有很大的獨特性。其問題的具體表現為：
一、工期失控，計劃失控。項目做多，往往會形成一種錯覺：不按計劃工期完成的項目是正常的；能按計劃工期準時完成的，往往是不正常的。這說明，項目的實際工期和計劃工期不符，是“家常便飯”。大多數工期延期，很少提前的。工期延期、失控，自然而言會導致計劃無法執行；計劃無法執行，成本就失控；產品就會變形．．．．．．
二、項目前期多數出現“沒事做”，后期“沒人做”。在項目啟動后，因為人員的配置，人員的銜接，硬件的配置，客戶需求的確定性，一般會造成很多人“沒事做”。而有些事是必須放在項目前期做的。前期不做，會對中后期有很大的影響。或者放到中后期做，會，要多花幾倍的人力、物力。到了項目后期，會出現“虎頭蛇尾”，大量的事情需要人來做，項目的人員又是固定的，其他人因為不了解整個項目，無法“空降”，則只能刪除一些事情咯。這樣就造成很多事情，沒人做，后果可想而知。
三、開發人員心態失控。延期，趕進度；晚上加班。還是延期，星期六也加班吧。
還是不能按期完成，又到項目后期，只好封閉開發。平時晚上加班，星期六、星期天也加班。這就是很多開發人員開發項目漸進式的流程。不同項目的開發人員，只要問問對方是否加班，就大概可以了解到對方參加的項目的開發階段拉。先拋棄加班對開發人員的效率的影響，對開發人員心態的影響才是最重要的。每個人都有趨利弊害的天性，開發人員也不例外。既然要趕進度，效率沒有提高的情況下，要縮短開發時間，那只有簡化功能，減少處理異常的情況，能把功能完成再說，等以后測試或用戶哪里出問題再說。如果僥幸不出問題，那就沒問題拉。這種情況下，當然希望測試的水平越“水”越好拉。哦，別忘了，測試也是開發人員的一部分。工期延期了，上面要求的進度又越來越緊，測試時間就更短，強度大，那只有有意無意去逃避錯誤，這樣就皆大歡喜拉。
這些共性的問題，就是項目管理所要解決的問題。只有解決了這些問題，項目管理水平就會得到質的飛躍！當然要解決這些問題，不是一兩篇文章，一兩個公司就能解決的，需要所有人的不斷探索才能解決的。這里，主要是個人的一些思考，供大家參考。
II. 定位問題
有人會問，產品或項目的需求不就是包含了定位，何須重復講呢。其實，這是一個誤區。同樣一個需求，在一個中學生中實現和在一個大學生中實現是完全不同的；在一個有經驗的群體中實現和在一個缺乏經驗的群體中實現是完全不同的。有些項目，由于定位未做好，未開始注定是失敗的，無論是需求分析得如何好，編碼、測試控制得十分完美，終究逃不過失敗這一關。
做軟件的都知道，是沒有真正的軟件。即使是通用做的最好的WINDOWS，也不可能是通用到每一類人，每一個國家，每一個民族的人，通用到那些只有幾千人的少數民族。因此，一個項目的定位是十分重要的。
產品和項目的定位是不一樣的。做項目不比賣產品，產品賣出就是成功，項目投產才算成功；產品是靜態的，項目是動態的；產品質量有問題可以包換、保修，項目一旦失敗，時間不能倒流，客戶損失的可能就是市場競爭優勢和機遇。
對于用戶定制的項目，定位相對簡單，只要了解到定制用戶的使用范圍，使用者的知識結構、行業經驗、電腦的基本知識及是否用過相關軟件即可。特別地，如果是用過相關地軟件，一定要了解清楚，哪些操作、功能是必須保留地，哪些操作、功能是可以修改或必須修改的。一段用戶的已習慣了某種辦法、操作方式，是很能更改的，如果定制的項目不遵照用戶的習慣進行開發，在軟件的運行初期，往往會出現很多意想不到的問題。此外，還必須注視用戶方人員流動、機構變化造成的影響。
對于產品的開發，定位則相對復雜些。由于產品的使用者是不確定的，是預測的。因而產品的定位顯得特別重要。國內的產品，是不存在通用產品的。通用，只相對于某些大行業或某個行業而言。有些產品，號稱是通用產品，既不能使通用領域的用戶滿意，更不能使專用領域的用戶滿意，是一個徹底失敗的產品。相反，一些產品，一開始就定位于某個行業，某個細分的行業，反而做的很好，用戶量比所謂的通用的產品的用戶量還要多。
如產品定位于專用，必須考慮，專用的范圍，是否能進一步細分，在細分的基礎上，所屬范圍的特征，有哪些情況是不適用，哪些情況是適用的等等。對范圍的特征分析得越清楚，定位越準確，產品失敗得概率就越少。同理，對于定位于通用的產品，就是將要通用所屬的范圍的同性提取出來。基于國內軟件水平的現實，做通用產品，應該是基于某些專用范圍，再兼顧其他的范圍，即以專用范圍為主。因此，定位的準確，是確保項目成功的底線（Bottom Line）之一。
III. 項目經理及與開發人員的溝通
項目經理類似于電影中的英雄人物，是項目的靈魂，他的一舉一動影響著項目的成敗。在危難時刻，優秀的項目經理甚至可以力挽狂瀾。眾所周知，衡量項目經理一般是以在資質、素質、能力和經驗等作為主要的依據,即統籌能力、領導能力、交往能力、處理壓力、解決問題的能力和技術能力。但是，個人認為，項目經理的心態才是決定一個項目成敗的關鍵因素。當然，能力和經驗也會影響項目經理的心態。
一般出任項目經理，要么是由開發骨干兼任(這在中、小型項目中很普片)，要么是由銷售或其他部門空降，專職項目經理。這兩種方式都有各自的弊端。專職項目經理，專做項目管理而不做任何分析、設計、編碼、測試等具體的技術實施工作，就會感覺“沒事做”，或是在打雜；開發骨干，由于主要或全部精力均忙于具體技術工作，各種項目管理任務（如：項目分析/評估、項目計劃的制定/檢查/調整、上下左右的溝通、專業資源調配、項目組織調整、項目財務控制、風險分析/對策等）不可避免地疏于顧及，項目管理的事情“沒人做”，導致項目控制的問題“積勞成疾”，后悔莫及。
專職項目經理，在項目管理過程中，一般比較注重對外的聯絡合作方面，即比較注重和銷售、用戶，其他部門的協調工作。相反，就會對技術及開發的技術重視不足。在很多情況下，只根據用戶、銷售確定的功能、工期來安排計劃，對相應的技術難點不理解，每項功能所耗費的時間估計出現很大偏差，對每個開發人員的技術、知識水平認識不透徹。因此會造成有些任務需要強制、壓迫才能完成，開發人員不是建立在心服口服的情況下完成的。正所謂，上有政策，下有對策。開發人員都是高智商的動物，騙“外行”就更容易了。一般都是采取虛報工作難度，把本來一天能做完的，拖到一個星期，十天才做完；或者把正常要半個月才能做完的工作，在上面“強制”要求下，壓縮到一個星期做完，當然拉，其中必然要偷工減料，只有極正常的操作才能會滿足要求，對非法操作，特殊情況的處理，項目經理或測試工程師發現一個才處理一個。不能發現的，就等用戶去發現。項目的實施情況就可想而知拉。
在這種情況下，必須做到幾點：
一、 從開發人員的角度出發，結合市場的角度確定項目的功能，動之以情，曉之以理，盡量使開發人員心服口服地開發某個功能。
二、 由項目組討論確定每一項功能的開發耗時，以不是通過拍腦袋的方式確定耗時；
三、 加強測試；
四、 加強對開發人員責任心、成就感的教育。
技術骨干擔任的項目經理，不可避免地存在著“技術崇拜”，盡可能采用新技術。即使是需求明確的功能，由于實現方式有多種路徑，一般都是從技術上采取最優的路徑，而不是從用戶操作方便的角度上選擇操作最方便、快捷的路徑，用戶必須嚴格按開發人員所預設的操作方式進行操作。說句老實話，用戶是不管你用什么技術的，先進或落后的技術都可以，只要能滿足用戶的需求即可。這種類似閉門造車生產出來的產品，自然就是操作不便，功能差強人意的。還有一種情況是，這種情況一般發生在項目后期，開發產品的情況較多，隨著開發的深入，總會發現缺少某些功能，或者某些功能不夠強大。項目經理對功能的增加、刪除、修改，不是通過集體討論確定或通過從市場前線人員中了解確定，而是通過憑空想象，拍腦袋來作出決定。特別是對于某些功能的添加，由于項目經理都無法把握用戶是否需要這個功能，需要這個功能的程度，因此是很難令開發人員把握此功能的目的。當然，既然大家都無法把握用戶是否會用這個功能，那自然是應付式開發。只要過了測試，過了項目經理這一關就OK拉。
初當項目經理的人，經驗不足是必然的，這并不是構成產品、項目失敗的關鍵因素，心態才是主要的。新官上任三把火，而且還是懷著“感謝黨，感謝組織，感謝領導”，有著一顆報恩的心態當上項目經理，自然就事事追求完美，沒有缺陷。但是，理想和現實是永遠都有很大的差距的。學會取舍才是項目、產品成功的因素，也是項目經理走向成熟的關鍵。
成熟的項目經理，應確保項目實施中業務參與的全面性、深度和權威性。
在一、二十年前，也許您會經常聽到某位大俠單獨完成了某種創舉，成了人們崇拜的對象。可今天，這種大俠，已經很難有生存空間了。取而代之的是，某軍團，又攻克了一座什么樣的堡壘。這樣，溝通，可以說已經變得無比的重要。在軟件業，溝通可以說是快速學習和掌握新知識，達到技術上的更高層次的最佳途徑。因此，無論是項目，管理都必須在以人為本的前提下進行，必須重視溝通。
以人為本，指的不只是軟件開發人員這一部分。這里的人主要指的是一些與項目有利害關系的一些人，即項目干系人(stakeholders)，一般包括客戶或者用戶、項目團隊、項公司的管理層等一些主要的利害關系者。 一個項目能否成功，很大程度上取決于能不能分清楚這些項目利害關系者各自對項目的影響，能不能利用好這些人力資源，溝通協調好他們之間的關系。
溝通是掌握各方信息，進行項目決策和項目協調的基礎，也是項目管理的基本內容。項目經理最重要的工作之一就是溝通，通常花在這方面的時間應該占到全部工作的75%～90%。良好的交流才能獲取足夠的信息、發現潛在的問題、控制好項目的各個方面。盡早溝通、主動溝通就是其中的兩個原則。總之溝通是一門很重要的學問，在項目管理中也有專門的溝通管理，因而在本文中我們就不再討論了。
項目經理只有以人為本，重視溝通，才會避免出現以下的情況：客戶在檢查項目階段成果時，指出曾經要求的某個產品特性沒有包含在其中，并且抱怨說早就以口頭的方式反映給了項目組的成員，糟糕的是作為項目經理的你卻一無所知，而那位成員解釋說把這點忘記了；或者，你手下的程序員在設計評審時描述了他所負責的模塊架構，然而軟件開發出來后，你發現這和你所理解的結構大相徑庭．．．．．．

IV. 產品的需求、系統分析、設計
總的而言，軟件開發主要分為六個階段：需求分析階段、概要設計階段、詳細設計階段、編碼階段、測試階段、安裝及維護階段。開發軟件就如八股文一樣：總體規劃、項目立項、需求分析、系統分析、系統設計、編碼實現、項目測試、文檔制作（八股文：破題、承題、起講、入手、起股、中股、后股、束股），一切都按部就班。同理，信息系統集成項目管理一般的過程分為：需求分析、項目調研、方案論證、實施方案、具體實施、測試、驗收、售后服務。同時項目管理按管理的方式可以分為售前、售中和售后。
在國內，做的項目越多，就越容易產生這樣的感覺：項目感覺總是做不完，就像一個“無底洞”。用戶總是有新的需求要項目開發方來做，就像用戶在“漫天要價”，而開發方在“就地還錢”。 實際上，這里涉及到一個“范圍管理”的概念。項目中哪些該做，哪些不該做，做到什么程度，都是由“范圍管理”來決定的。“范圍管理”的相關知識，可以參考項目管理知識體系指南、項目管理九大知識體系的相關內容。這里只說說兩點，核心需求和需求的變更。
一般說來，需求對用戶來說，可以分為核心需求和輔助需求。對于中國貪心的用戶來說，功能從來不嫌多的。核心需求就是用戶使用本軟件是，一定會使用的功能，沒有這些功能，會影響用戶的忠誠度。輔助功能，就是用戶可用可不用的功能。有了這些功能，用戶更喜歡，沒有這些功能，用戶不會太在意，或者是可以容忍。同樣一個軟件，不同的用戶，核心需求和輔助需求是不一樣的。在一個項目產品中我們應該知道對方需要什么，自己要做什么，這是項目成功的基礎所在。
對于產品，因為用戶是不確定的，確定哪些需求是核心需求，哪些是輔助需求，則比較難。但是如果定位合理，對定位的用戶范圍的特征分析得準確，則不是什么太難得事。但無論是產品還是項目，都必須考慮以下三點：1、對于用戶提出的每個需求都要知道“為什么”，并判斷用戶提出的需求是否有充足的理由，并考慮由此而引申出來的問題，觸類旁通，舉一反三；2、對于用戶提出的每個需求都要知道“為什么”，并判斷用戶提出的需求是否有充足的理由；3、分析由用戶需求衍生出的隱含需求，并識別用戶沒有明確提出來的隱含需求（有可能是實現用戶需求的前提條件），這一點往往容易忽略掉，經常因為對隱含需求考慮得不夠充分而引起需求變更。
需求確立后，重要的是規范化，文檔化，可參考常用的需求建模的方法如數據流圖（DFD）、實體關系圖（ERD）和用例圖（Use Case）三種方式。
需求的變更是不可避免的，如何以可控的方式管理軟件的需求，對于項目的順利進行有著重要的意義。現在，重要的不是限制需求的變更，而是讓用戶、銷售、開發都明白，不管是哪種情況下變更，只要是造成變更的一方，都要背負相應的責任。這就需要一個明確的約束機制。在制定制度時，大家都可以參議，提意見。但只要制度確定了，就必須恪守這個制度，是制度管人，而不是領導管人。也只有這樣，才不至于開發處于遙遙無期的狀態，而到最后則草草收兵。
本人認為，需求的確定可以分為三個階段則比較合適，這樣劃分也涉及到計劃、成本的管理，可參考后面的相關內容。
一、 項目初期，用戶、銷售、開發三者，應根據WBS方法確定整個項目的整體需求，即最起碼要確定WBS中最頂層的父作業，如需求一，需求二．．．．．． 并盡可能詳細地確定需求地具體劃分，如需求一.1，需求一.2，需求二.1，需求二.1.（1）．．．．．．對于開發周期比較長的項目，則可以確定每個需求開發開始的大概時間，周期比較段的項目，則只需確定整個項目的開始時間即可。對沒有確定的需求，則要明確在開發前一個相應的時間，必須在確定的時間之前來落實詳細的需求。對已確定的需求則明確在開發前的一個具體時間內可以修改的內容，主要是框架性的需求。
二、 項目開發前，核實項目的所有需求，應當包括詳細的需求，并明確告知用戶以后只能修改細節上需求，主要是操作上的需求。如果在以后要修改框架性的需求，必須受到一定的約束，所產生的成本必須為要變更的一方負責。如是因為開發的原因造成的，則增加成本納入到項目的成本中；如因銷售工程師因銷售壓力而盲目對用戶作承諾的功能，則相應成本必須納入銷售成本中；確定落實需求后，進行項目的開發階段。
三、 項目開發完成后，提交給用戶試用。用戶使用后，用戶明確要修改的內容，主要范圍是操作上，細節的實現是否與需求一致，是否與用戶真正需要的一致。如要對框架性的需要修改，則必須按先前的約束條件進行。確定修改內容后，向用戶明確，以后的修改內容都只能局限于當前提出的修改范圍，當然，程序出錯除外。開發進行修改，用戶使用，將修改范圍進一步縮少。一次或多次迭代后，項目完成。
V. 工作量的估算及評價
項目管理最大的難度，就是每一模塊的工作量、開發時間的確定，這也是項目實施的主要風險，最難預測、控制的風險。
比較常用的估算方法有：估計項目交付日期的方法有很多，如基于經驗的估計、基于模型的估計等。一種簡便易行的估計方法是采用Wideband Delphi估計方法，此方法可以降低不同人員所作估計的偏差。基于模型的估計方法則包括KLOC、FPA以及COCOMOⅡ等模型。在這里主要引用新的估算方法，以供參考。
如果，公司有著類似項目實施的豐富經驗，則工作量、開發時間的確定則會更切實際。
首先，提取公司內部數據，統計出類似模塊的工作量（M公）、開發時間（S公）。如果，公司沒有這方面的經驗，那如何辦呢？不做這一步？！對，沒辦法，沒時間時也可以放棄這一步。有時間，有精力時，可以通過了解社會對類似模塊的工作量、開發時間的平均值再結合本公司的情況進行假設模塊的工作量、開發時間。
其次，項目開發成員對這一模塊的工作量、時間的估算。這一步是最耗時，這是很多公司都沒有去做的，包括國內一些知名的軟件公司。軟件開發，不是工廠中的流水線生產，可以對產品的生產過程中每一個過程，每一個步驟，進行嚴格的控制和限制。在開發過程中，由于開發人員不同的學歷背景、知識水平、經歷、開發經驗、對模塊的理解程度、思維方式、編程習慣等因素，對同樣的模塊，所需求的工作量，開發時間是有很大區別的。因此，需要每個開發成員對相關模塊了解熟悉后，進行估計，再根據不同的系數，通過不同的公式進行轉換后確定每一個模塊的工作量、開發時間。
公式為：M＝M（公）*X1+M(項)*X2;
S＝S（公）*X1+S(項)*X2;
M(項)＝M（開1）*Y1+M(開2)*Y2+…+ M(開n)*Y.n;
S(項)＝S（開1）*Y1+S(開2)*Y2+…+ S(開n)*Y.n;
每一模塊，每項功能完成后，對小于原定工作量或成本的，可以直接以原工作量和成本作為考核的依據。對于超出原定工作量或成本的，必須組織相關人員進行成本、工作量的評估。主要的操作方法為，組織3到5人的評估小組，小組成員盡可能是在開發時對要評估模塊相當熟悉的成員。小組成員利用一定的時間了解評估模塊的代碼，功能特點，模塊實現思路，難點，簡單的單元測試等，然后小組的成員假設是成員本人來開發評估模塊，需要用的成本、工作量并轉換為開發人員相應級別的工作量、成本，最后綜合小組成員的估計的工作量、成本和開發人員開發時所耗費的成本、工作量進行加權平均，得出最后的成本、工作量，并以此作為考核的依據。
VI. 計劃的編排
有人這樣形容計劃的，“計劃，計劃，紙上畫畫，墻上掛掛，計劃不如變化，計劃不頂領導一個電話。！”。根據美國Hackett公司的一項調查發現，只有37%的信息化項目在計劃時間內完成，只有42%的信息化項目在預算內完成。計劃很容易成為空話，特別是在軟件工程中，影響計劃的因素太多，計劃就形同虛設了！但是，項目管理方法的主體就是項目計劃、計劃優化方法,其目的就是綜合各種因素，制定合理的計劃，并通過計劃的實施，使其規范化，從而提高項目的效益，提高人員效率，降低項目的成本。
圍繞著項目計劃方法，可以把項目管理方法分為四個發展階段：Gannt圖階段、確定性網絡計劃技術階段，如關鍵路徑法CPM（Critical Path Method）等、概率型網絡計劃技術階段，如計劃評審技術PERT (Program Evaluation and Review Technique)和多因素隨機網絡計劃技術階段，如考慮資金因素的PERT/COST，考慮活動風險的圖評審技術GERT(Graphics Evaluation and Review Technology)和風險評審技術VERT(Venture Evaluation and Review Technology)，以及多種資源（資金、人力等）約束下的網絡優化等等。無論項目管理發展到哪一階段，本人認為計劃要合理，合乎以后項目實施的實際情況，以下三點是前提：
一、 對計劃的態度問題。如果計劃只是為了讓上面的頭頭看看，放在墻上掛掛。那基本上這些計劃也就是沒什么意義的計劃，不說也罷。這些計劃不是小數。筆者曾經看過這樣的計劃，某位同事出差在外面兩周，但在最新的計劃中，還有本周必須在公司完成的開發任務。這種計劃，一經編排就意味著無法完成，或者要進行變更。還有，筆者親身經歷的，在收到的計劃中（是8月15號制定的），已安排筆者在8月15號前的一個星期完成某一項工作。本人是在8月15號后才知道要完成這項工作的，自然就無法按時完成拉。這樣的例子還有很多，不勝枚舉。
二、 對計劃的編排要做到有粗有細。
傳統的計劃編制是這樣的：首先對項目進行估算，粗算出項目的總體進度。然后進行精化：確定概要設計階段、詳細設計階段、編碼階段、測試階段、安裝及維護階段等階段的具體要求、完成時間、投入人力物力，并確定幾個關鍵階段。這些關鍵階段的要求進度必須在指定日期之前完成。最后充分考慮影響項目計劃的因素，并做出相應的措施，做出項目進度表，列出在每個階段的難點要點，要注意的問題。，并將需要分析階段的內容和項目計劃、進度表整理成文檔，分發到相關人員手上。
這樣的計劃編制，在土木工程等運用項目管理比較成熟的行業時，還算相當成功，但具體運用到軟件開發上，很多時候，就會出現變形，走樣。例如有些計劃，真是很細致，很細致，甚至細分到小時，分鐘。這樣的計劃很難執行，只要外界有變化，或者前面的計劃出現誤差，則這個計劃就完了。有些計劃，很粗，很粗，粗到只有時間點，只有大框架，沒有具體的內容。在實施時，根本無法知道具體怎樣做。這樣的計劃，一般被稱為里程碑式的計劃，比較適合領導對計劃的檢查。
在國內，軟件開發中，計劃的制定，比較常用的方法為WBS方法，即將項目工作分解為更小、更易管理的工作包也叫活動或任務，這些小的活動應該是能夠保障完成交付產品的可實施的詳細任務。首先就是周密地做好范圍計劃編制；然后以項目進度為依據劃分WBS，第一層是大的項目成果框架，每層下面再把工作分解，這種方式的優點是結合進度劃分直觀，時間感強，評審中容易發現遺漏或多出的部分，也更容易被大多數人理解。其中，這部分內容運用專門的項目管理軟件比較適合。Microsoft的項目管理工具Project就可以自動為各個層次的任務編碼，國內的項目管理軟件中，同望EasyPlan不但具有自動編碼功能，還可以在甘特圖，單網圖，雙網圖三種視圖下快速編制計劃圖，并可對計劃、資源、成本費用的優化，進行跟蹤比較，盈余分析等等，是一個不錯的軟件。
但是，WBS方法的前提是，對軟件開發所涉及的業務要比較熟悉，有多年的經驗；要求涉及人員的流動性小，管理模式要穩定。人對事物的認識是有一個過程的，不同的階段有不同的認識。因此，對一個計劃來說，計劃前期盡可能細化每一項工作，越具體越好。對于以往計劃執行得比較好得的公司，項目受到外界干擾比較少的項目，前期計劃可以細化到日，或半天。對執行得一般的項目，可以細化到兩天、三天或一周。對執行得比較差，或者容易受到外界影響的項目，如項目組成員要經常出差，或支援其他項目，或者要中斷進行前面項目的維護工作等等，可以細化到旬、半個月，最好不要超過一個月，否則計劃失去其本來的意義。對計劃后期工作的制定，則可以比較粗些，用以適應前期計劃執行情況造成的變化。
當然，這樣的計劃，也要避免采取每周制定下周工作計劃的逐周項目計劃方式，避免“項目失控合法化”。項目計劃的Breakdown或曰“粒度”，是一個需要小心把握平衡的問題。越細則控制力度越大（筆者曾見過細到0.25小時/人的），但項目管理的成本越高；反之亦然。以國內目前的狀況，個人看法，項目的周期越長，應越粗。項目周期為三到六個月的，可以粗到一周或半個月。周期為一到兩年的，則可以粗到一個月，一個季度。無論多大的項目，應該也不要超過半年。
三、關鍵線路的制定。一般來說，先確定關鍵工作，整個項目的關鍵線路。然后，確定非關鍵工作。最后通過甘特圖（橫道圖），網絡圖（單代號網絡圖，雙代號帶邏輯時標的網絡圖）找出自由時差、總時差，并通過縮短關鍵線路的工期來對項目進一步優化。在這里，最重要的，關鍵線路的資源，即關鍵線路中的關鍵工作是由哪個開發人員負責。現在的項目管理工作中，存在這樣一個誤區，整個項目的關鍵路線通常是由一兩個開發精英、骨干、核心來承擔。這樣存在很大的風險。當開發核心在項目中途離職或者不得不暫停開發工作，如生病，出差等，會造成整個項目延誤，而其他開發人員窩工。同時，一個人長期處于高壓下工作，當前工作延誤了，導致整個項目的延誤；下一個工作延誤了，又導致整個項目的延誤。反正已經連續延誤了，就無所謂了，做到哪里就算哪里好了，整個人崩潰了，對開發計劃確定的時間就放棄了，從而形成一人加班，全員加班。因此，一個好的計劃，出關鍵線路合理外，還必須時關鍵線路有多個人員在不同時段進行承擔，避免一兩個人長期承擔整個關鍵線路，同時，還要預料，還有哪些因素影響，使某些非關鍵工作會上升為關鍵工作，成為關鍵線路，影響整個關鍵線路。
VII. 計劃的執行、變更
影響計劃執行的因素可以分為主觀因素和客觀因素。客觀因素有客戶相關風險，外部環境的影響，停電，機器損壞，不能上網等原因。主觀因素有：人的因素、技術因素，資源因素。如果項目計劃的Breakdown或曰“粒度”不符合實際情況，也是影響計劃執行的因素。
設立里程碑，加強項目進度的檢查（與進度計劃比對）和控制，維護項目計劃的嚴肅性，是規避計劃執行風險的一個有效辦法。但這是不夠的。只有建立合理、實用的計劃，計劃的執行才會有可能。依照前面所提到的計劃編排原則，那計劃的執行應是這樣進行的。在執行計劃A時，應先審查計劃B的內容，利用WBS方法，確定計劃B的內容是不可再細分，需求在現階段是否要作進一步的調整，功能點是否要刪除、修改、添加等等，然后再確定計劃B的具體執行時間，粗略調整由此引發后面的計劃的變更。換句話說，也就是，迭代計劃B，使計劃B更你能滿足現實的情況。計劃B的具體執行時間已經制定，就是“死的”，不允許作調整，必須想盡一切辦法按時、按質完成計劃。因為這時計劃是比較符合實際的，不能按時按質完成，不是態度問題，就是效率問題。完成計劃A，在執行計劃B時，迭代計劃C……通過執行，迭代，完成整個計劃。總之，就是使計劃處于相對動態中，不是靜態，也不是動態的，頻頻變化，要避免“項目失控合法化”。
一個項目的范圍計劃可能制訂的非常好，但是想不出現任何改變幾乎是不可能的。因此對變更的管理是項目經理必備的素質之一。在這里，我們定義在執行計劃A前，對計劃B的修改，稱為調整；執行計劃A后直到完成計劃B中對計劃B的修改，稱為計劃的變更。從常識來說，對計劃的調整，相對而言，成本的變化不大。因此，計劃的調整是約束最少的，只要有合理的理由，對整個系統沒有特別大的影響，都可以進行調整。相反，對計劃變更的約束是最大的，不是哪個人，哪個領導拍個腦袋，想怎么變更就怎么變更的。誰變更，誰就應該負擔變更所引發的成本。在變更之前，應該進行集體討論。這時，千萬要避免項目領導閉著門，想個三天兩夜，然后對眾人來個宣布，決定要怎樣怎樣變更。這時，來個“一言堂”，項目很容易失敗的。談論時，要明確以下目的：一，為什么要變更？二，可不可以通過其他方法來彌補，而不需要變更？三，要變更，是最少的，最優的變更嗎？？四，變更造成的成本差，具體由誰來負擔，這一定要明確，不能模糊。總之，抓住一個宗旨：能不變更就不變更，能少變更就少變更，變更了就應該有具體的人員來負擔相應的責任、成本。一般來說，可以變更的原因有客觀原因和主觀原因。客觀原因，如項目組成員計劃外出差，生病，公司大型活動等等而造成無法按計劃執行，這時的變更所造成的成本，則只能有公司來負責或整個項目組來負責。主觀原因，即使是加班加點，提高工作效率，也無法按計劃時間來執行計劃。這種情況，是制定和調整計劃的人沒有做好，需求的功能比較模糊，細化得不徹底，難點估計不足。這種情況下的變更，則計劃的制定和調整者，應負擔相當大的責任和成本，開發人員所負擔的責任和成本則相應小一些。如果是由于開發人員的責任心不夠而造成的變更，則開發人員要負擔大部分的成本，開發人員的領導也要負擔一小部分的成本。
不管怎么樣，只要變更確定了，就應該嚴格執行，絕對要避免同一內容一而再，再而三地進行變更，使計劃成為擺設。這時，對計劃地對計劃地執行，應該是專制的，“一言堂”式地進行。

VIII. 測試及產品的收尾階段
目前市場競爭的激烈和市場的成熟度不足，可能導致應用開發項目的惡性競爭風險。客戶希望物美價廉而加需求、壓價格、壓進度；廠商惟恐出局而拍胸脯、打包票。這是很多項目經理面臨的類似的情況，特別是在項目后期。

到了項目后期，主要是在進度和軟件質量取得一個平衡點。在實際的項目質量管理中，質量管理總是圍繞著質量保證(Quality Assurance)過程和質量控制(Quality Control)過程兩方面。質量管理就不在這里展開，主要還是說說，編碼等的修改和進度與系統測試的關系。
一般而言，隨著項目的深入，環境各方面的變化，具體實現總是和原先的設計或多或少地出現偏差。這是很正常，不必驚慌。原則上是，能不修改則盡可能不修改。實在要修改，則只要不是原則性的錯誤，盡量不要推倒前面所做的一切，重新做，畢竟以前做的時候也是考慮了方方面面的因素的，現在出現的問題只是在某方面考慮不周而已，一切都作廢，太浪費了。還有，要是數據庫字段已存在，除非萬不得已，千萬不要修改數據庫字段，實在不行就添加字段。因為已經存在的字段，很有可能已被軟件開發小組的其他成員在使用，不要因為你的修改而令其他人也要跟你做相應的修改。最后，軟件界面的修改要慎重，界面的修改很容易使你忽略修改相應的內容，造成軟件大問題沒有，小問題一大堆。要盡量避免出現以下兩種情況：一，不顧進度、成果，盡量修改，務必做到盡可能和預設功能一致；二，為了盡快完成項目，以時間點為準，做些表面修改，也就是不負責任的修改，以求盡快完整，早日解脫這個項目的苦海。這種情況，在管理過程中，出現波折，有大量、頻繁的修改的項目，出現得特別多。

到了項目后期，迫于公司、用戶的壓力、或者項目本身已經延遲了，盡早結束整個項目，就是自然而言的事情了。大多數的做法是，壓縮系統測試時間。系統測試的時間少了，發現的問題也就少了，時間就更加可控了。這樣做，也沒大錯，但必須注意，如在系統測試發現的大部分問題是low的，則壓縮系統測試時間問題都不大；如發現的問題有相當一部分是影響使用的，比較hight的，則不能壓縮系統測試時間，甚至要延長系統測試時間。不要抱著現在先混過驗收測試，等以后有時間再詳細測。從我了解的情況來說，這是不可能的，只要一過了驗收測試，不管是程序員，還是測試員，其心態都已經發生變化了，不可能全身心投入測試、修改中。即使是勉為其難投入，其效率就可想而知拉。不管怎樣，進行系統測試時，
最后的修改，必須預備一定的時間進行較全面的測試，以避免修改而引發的錯誤，特別是簡單的錯誤。經驗告訴我們，很多低級錯誤，都是在最后修改時引入的，因為預料測試時間不足而沒有被發現。
到了項目后期，即使是進度延誤得十分厲害，建議還是不要增加成員。因為，新成員得加入，熟悉業務需要，了解、理解業務需要一定的時間，除本身所消耗的時間外，還會有意無意地損耗其他成員的時間，造成進度的進一步拖延，等完全熟悉時，能上手，可能就是項目結束之日。此外，還會因為不熟悉，而引入新的錯誤，新的不穩定因素。
到了項目后期，除了進度的執行外，也要特別重視和相關人員的溝通及處理相應的關系。主要溝通人員有：用戶方的項目管理人員、用戶方的業務人員、用戶方的決策層、開發方的項目管理人員、開發方的軟件編程人員等。主要的關系有：用戶方與開發方的關系、用戶方項目管理人員與使用人員(業務人員)及決策層的關系、項目管理人員與軟件編程人員的關系、硬件與軟件的關系、性能與靈活的關系。

這樣，整個項目才會取得成功！！