一、影響軟件開發項目進度的因素
要有效地進行進度控制，必須對影響進度的因素進行分析，事先或及時采取必要的措施，盡量縮小計劃進度與實際進度的偏差，實現對項目的主動控制。軟件開發項目中影響進度的因素很多，如人為因素、技術因素、資金因素、環境因素等等。在軟件開項目的實施中，人的因素是重要的因素，技術的因素歸根到底也是人的因素。軟件開發項目進度控制常見問題主要是體現在對一些因素的考慮上。常見的問題有以下幾種情況：
1、80-20原則與過于樂觀的進度控制
80-20原則在軟件開發項目進度控制方面體現在：80％的項目工作可以在20％的時間內完成，而剩余的20％的項目工作需要80％的時間。這個80％的項目工作不一定是在項目的前期，而可能是分布在項目的各個階段，但是剩余的20％左右的項目工作大部分是在后期。所以軟件開發在進入編碼階段后會給人一種“進展快速”的感覺，使得項目經理、項目團隊成員、用戶以及高層領導產生了過于樂觀的估計。有些領導看到軟件交付給用戶了，一塊石頭落地“總算交差了”，同時又可能撤出一些被認為不必要的人力資源。但很多情況下這是為了對付用戶不合理的交付期限要求而采用的不得已的措施。這樣的結果是拖延了后期的工作，同時如果軟件還不成熟的話，會給用戶造成不好的影響。
2、范圍、質量因素對進度的影響
軟件開發項目比其他任何建設項目都會有更經常的變更，大概是因為軟件程序是一種“看不見”又“很容易修改”的東東吧，用戶是想改改，造成需求的蔓延，項目經理有時還不知如何拒絕，加上要說“我能”的心理因素，一般都會答應修改。這樣集少成多，逐漸影響了項目進度。
如果某項工作在進度上表面上達到目標了，但經檢驗其質量沒有達到要求，則必然要通過返工等手段，增加人力資源的投入，增加時間的投入，實際上是拖延了進度。不管是從橫向或縱向來看，部分任務的質量會影響總體項目的進度，前面的一些任務質量中會影響到后面的一些任務質量。
3、資源、預算變更對進度的影響
資源，主要的還是人力資源，有時某方面的人員不夠到位，或者在多個項目的情況下某方面的人員中途被抽到其他項目、或身兼多個項目、或在別的項目不能自拔無法投入本項目。還有一個很重要的資源，是信息資源，如某些標準、行業標準，用戶可能提供不了，而是需要去收集或購買，如果不能按時得到，會影響需求分析、設計或編碼的工作。其他資源，如開發設備或軟件沒有到貨，也會對進度造成影響。
預算其實是一種資源，它的變更會影響某些資源的變更，從而對進度造成影響。
4、低估了軟件開發項目實現的條件
低估軟件開發項目實現的條件表現在低估技術難度、低估協調復雜度、低估環境因素這樣幾個方面。
首先是低估技術難度。軟件開發項目團隊成員，有時甚至是企業的高級項目主管也經常低估項目技術上的困難。低估技術難度實際上也是高估人的能力，認為或希望項目會按照已經制定的樂觀項目計劃順利地實施，而實際則不然。軟件開發項目的高技術特點本身說明其實施中會有很多技術的難度，除了需要高水平的技術人員來實施外，還要考慮為解決某些性能問題而進行科研攻關和項目實驗；
其次，低估了協調復雜度，也低估了多個項目團隊參加項目時工作協調上的困難。軟件開發項目團隊成員比較強調個人的智慧、強調個性，這給項目工作協調帶來更多的復雜度。當一個大項目由很多子項目組成時，不僅會增加相互之間充分溝通交流的困難，更會增加項目協調和進度控制上的困難。
另外，企業高級項目主管和項目經理也經常低估環境因素，這些環境因素包括用戶環境、行業環境、組織環境、社會環境、經濟環境。低估這些條件，既有主觀的原因，也會有客觀的原因。對項目環境的了解程度不夠，造成沒有做好充分的準備。
5、項目狀態信息收集的情況
由于項目經理的經驗或素質原因，對項目狀態信息收集的的掌握不足，及時性準確性完整性比較差。另外其它一些原因也會造成這種現象。某些項目團隊成員報喜不報憂，不希望別人知道自己工作的不好的情況，例如軟件程序的編制，可能會先編制一些表面的東西，現有界面，看起來好像完成任務了，實際上只是一個“原型系統”或演示系統。給領導造成比較樂觀的感覺。
如果項目經理或者管理團隊沒有及時地檢查發現這種情況，將對項目的進度造成嚴重的影響。當然，如果出現這種需要時時刻刻都互相提防的氛圍，管理人員應該從管理的角度，從制度的角度檢討一下，進行改進，讓大家實事求是地進行溝通。溫伯格說:“無論你多么聰明，離開了信息，對項目進行成功的控制是無源之水、無本之木。”
6、執行計劃的嚴格程度
沒有把計劃作為項目過程行動的基礎，而是把計劃放在一邊，比較隨意去做。例如對于項目團隊內部溝通或外部溝通，在計劃中要說明清楚人員、周期、方式、方法，不能遺漏，但在實際項目過程中，可能出現溝通沒有按時或沒有完整地達到所有項目干系人的情況。
若項目計劃本身有錯誤，執行錯誤的計劃肯定會產生錯誤。如，計劃制訂者在計劃系統框架設計考慮上的錯誤、進度安排上的失誤等。實際的項目實施中，除了這種錯誤之外，還可能因為項目執行上的錯誤，造成項目的麻煩。例如，項目的客戶及其他項目干系人沒有及時為項目中出現的情況采取必要的措施或者所采取的措施的不適合具體的情況、沒有效果或者有副作用等。另外，如果在項目中的某項工作（如某個子系統或模塊、組件）被轉包給第三方開發后，不能進行有效的管理，也會造成進度上的延誤。
7、計劃變更調整的及時性
漸近明細是項目的特點，特別是對于軟件開發項目，并不是一個一成不變的過程。開始時的項目計劃可以先制定得比較粗一些，隨著項目的進展，特別是需求明確以后，項目的計劃可以進一步的明確，這時候應該對項目計劃進行調整修訂，通過變更手續取得項目干系人的共識。計劃應該隨著項目的進展而逐漸細化、調整、修正。沒有及時調整的計劃或者是隨意的不負責任的計劃的項目是難以控制的。在高技術行業，日新月異是主要特點，因此計劃的制定需要在一定條件的限制和假設之下采用漸近明細的方式，隨著項目的進展進行不斷細化、調整、修正、完善。對于較為大型的軟件開發項目的工作分解結構可采用二次甚至多次 WBS 方法。即根據總體階段劃分的總體 WBS ，需求調研階段結束、概要設計完成后專門針對詳細設計或編碼階段的二次 WBS 。由于需求的功能點和設計的模塊或組件之間并不是一一對應的關系，所以只有在概要設計完成以后才能準確地得到詳細設計或編碼階段的二次 WBS ，根據代碼模塊或組件的合理劃分而得出的二次 WBS 才能在詳細設計、編碼階段乃至測試階段起到有效把握和控制進度的作用。有些項目的需求或設計做得不夠詳細，無法對工作任務的分解、均衡分配和進度管理起參考作用，因此要隨著需求的細化和設計的明確，對項目的分工和進度進行及時的調整，使項目的計劃符合項目的變化，使項目的進度符合項目的計劃。
