要有效地進行進度控制，必須對影響進度的因素進行分析，事先或及時採取必要的措施，盡量縮小計劃進度與實際進度的偏差，實現對專案的主動控制。軟體開發專案中影響進度的因素很多，如人為因素、技術因素、資金因素、環境因素等等。在軟體開專案的實施中，人為因素是最重要的因素，技術的因素歸根到底也是人為因素。軟體開發專案進度控制常見問題主要是體現在對一些因素的考慮上。
常見的問題有以下幾種情況：
1、80-20原則與過於樂觀的進度控制
80-20原則在軟體開發專案進度控制方面體現在：80%的專案工作可以在20%的時間內完成，而剩餘的20%的專案工作需要80%的時間。這個80%的專案工作不一定是在專案的前期，而可能是分佈在專案的各個階段，但是剩餘的20%左右的專案工作大部分是在後期。所以軟體開發在進入編碼階段後會給人一種“進展快速”的感覺，使得專案經理、專案團隊成員、客戶以及高層領導產生了過於樂觀的估計。有些領導看到軟體交付給客戶了，就一塊石頭落地“總算交差了”，同時又可能撤出一些被認為不必要的人力資源。但很多情況下這是為了對付客戶不合理的交付期限要求而採用的不得已的措施。這樣的結果是拖延了後期的工作，同時如果軟體還不成熟的話，會給客戶造成不好的影響。
2、範圍、質量因素對進度的影響
軟體開發專案比其他任何建設專案都會有更經常的變更，大概是因為軟體程式是一種“看不見”又“很容易修改”的東西，客戶想改就改，造成需求的蔓延，專案經理有時還不知如何拒絕，加上要說“我能”的心理因素，一般都會答應修改。這樣積少成多，逐漸影響了專案進度。
如果某項工作在進度上表面上達到目標了，但經檢驗其質量沒有達到要求，則必然要通過加班等手段，增加人力資源的投入，增加時間的投入，實際上是拖延了進度。不管是從橫向或縱向來看，部分任務的質量會影響總體專案的進度，前面的一些任務質量中會影響到後面的一些任務質量。
3、資源、預算變更對進度的影響
資源，最主要的還是人力資源，有時某方面的人員不夠到位，或者在多個專案的情況下某方面的人員中途被抽到其他專案、或身兼多個專案、或在別的專案不能自拔無法投入本專案。還有一個很重要的資源，就是資訊資源，如某些國家標準、行業標準，客戶可能提供不了，而是需要去收集或購買，如果不能按時得到，就會影響需求分析、設計或編碼的工作。其他資源，如開發設備或軟體沒有到貨，也會對進度造成影響。
預算其實就是一種資源，它的變更會影響某些資源的變更，從而對進度造成影響。
4、低估了軟體開發專案實現的條件
低估軟體開發專案實現的條件表現在低估技術難度、低估協調複雜度、低估環境因素這樣幾個方面。
首先是低估技術難度。不僅軟體開發專案團隊成員，有時甚至是企業的高級專案主管也經常低估專案技術上的困難。低估技術難度實際上也就是高估人的能力，認為或希望專案會按照已經制定的樂觀專案計劃順利地實施，而實際則不然。軟體開發專案的高技術特點本身說明其實施中會有很多技術的難度，除了需要高水準的技術人員來實施外，還要考慮為解決某些性能問題而進行科研攻關和專案實驗。
其次，低估了協調複雜度，也低估了多個專案團隊參加專案時工作協調上的困難。軟體開發專案團隊成員比較強調個人的智慧、強調個性，這給專案工作協調帶來更多的複雜度。當一個大專案由很多子專案組成時，不僅會增加相互之間充分溝通交流的困難，更會增加專案協調和進度控制上的困難。
另外，企業高級專案主管和專案經理也經常低估環境因素，這些環境因素包括客戶環境、行業環境、組織環境、社會環境、經濟環境。低估這些條件，既有主觀的原因，也會有客觀的原因。對專案環境的瞭解程度不夠，造成沒有做好充分的準備。
5、專案狀態資訊收集的情況
由於專案經理的經驗或素質原因，對專案狀態、資訊收集掌握的不足，及時性、準確性、完整性比較差。另外其它一些原因也會造成這種現象。某些專案團隊成員報喜不報憂，不希望別人知道自己工作的不好的情況，例如軟體程式的編制，可能會先編制一些表面的東西，現有介面，看起來好像完成任務了，實際上只是一個“原型系統”或演示系統，給領導造成比較樂觀的感覺。
如果專案經理或者管理團隊沒有及時地檢查發現這種情況，將對專案的進度造成嚴重的影響。當然，如果出現這種需要時時刻刻都互相提防的氛圍，管理人員就應該從管理的角度、從制度的角度檢討一下，進行改進，讓大家實事求是地進行溝通。溫伯格說:“無論你多麽聰明，離開了資訊，對專案進行成功的控制就是無源之水、無本之木。”
6、執行計劃的嚴格程度
沒有把計劃作為專案過程行動的基礎，而是把計劃放在一邊，比較隨意去做。例如對於專案團隊內部溝通或外部溝通，在計劃中要說明清楚人員、週期、方式、方法，不能遺漏，但在實際專案過程中，可能出現溝通沒有按時或沒有完整地達到所有專案關係人的情況。
若專案計劃本身有錯誤，執行錯誤的計劃肯定會產生錯誤。如，計劃制訂者在計劃系統框架設計考慮上的錯誤、進度安排上的失誤等。實際的專案實施中，除了這種錯誤之外，還可能因為專案執行上的錯誤，造成專案的麻煩。例如，專案的客戶及其他專案關係人沒有及時為專案中出現的情況採取必要的措施或者所採取的措施的不適合具體的情況、沒有效果或者有副作用等。另外，如果在專案中的某項工作(如某個子系統或模塊、組件)被轉包給第三方開發後，不能進行有效的管理，也會造成進度上的延誤。
7、計劃變更調整的及時性
漸近明細是專案的特點，特別是對於軟體開發專案，並不是一個一成不變的過程。開始時的專案計劃可以先制定得比較粗一些，隨著專案的進展，特別是需求明確以後，專案的計劃就可以進一步的明確，這時候應該對專案計劃進行調整修訂，通過變更手續取得專案關係人的共識。計劃應該隨著專案的進展而逐漸細化、調整、修正。
沒有及時調整的計劃或者是隨意的不負責任的計劃的專案是難以控制的。在高技術行業，日新月異是主要特點，因此計劃的制定需要在一定條件的限制和假設之下採用漸近明細的方式，隨著專案的進展進行不斷細化、調整、修正、完善。對於較為大型的軟體開發專案的工作分解結構可採用二次甚至多次 WBS 方法。即根據總體階段劃分的總體 WBS ，需求調研階段結束、概要設計完成後專門針對詳細設計或編碼階段的二次 WBS 。由於需求的功能點和設計的模塊或組件之間並不是一一對應的關係，所以只有在概要設計完成以後才能準確地得到詳細設計或編碼階段的二次 WBS ，根據代碼模塊或組件的合理劃分而得出的二次 WBS 才能在詳細設計、編碼階段乃至測試階段起到有效把握和控制進度的作用。有些專案的需求或設計做得不夠詳細，無法對工作任務的分解、均衡分配和進度管理起參考作用，因此要隨著需求的細化和設計的明確，對專案的分工和進度進行及時的調整，使專案的計劃符合專案的變化，使專案的進度符合專案的計劃。
8、未考慮不可預見事件發生造成的影響
假設、約束、風險等考慮“不周”造成專案進度計劃中未考慮一些不可預見的事件發生。例如軟體開發專案還會因為專案資源特別是人力資源缺乏、人員生病、人員離職、專案團隊成員臨時有其他更緊急的任務造成人員流動等不可預見的事件對專案的進度控制造成影響(即專案按時完成是基於如下假設：人力資源不會缺乏、人員不會生病、人員不會流動)。
企業環境、社會環境、天災人禍等事件對專案的進度控制造成影響。對專案的假設條件、約束條件、風險及其對策等對於進度的影響在專案計劃要進行充分的考慮，在專案進展過程中也要不斷地重新考慮有沒有新的情況，新的假設條件、約束條件、潛在風險會影響專案的進度。假設是通過努力可以直接解決的問題，而這些問題是一定要解決才能保證專案按計劃完成；約束一般是難以解決的問題，但可以通過其他途徑回避或彌補、取捨，如犧牲進度、質量等等；假設與約束是針對比較明確會出現的情況，如果問題的出現具有不確定性，則應該在風險分析中列出，分析其出現的可能性、造成的影響、採取的措施。
實際上像沒有考慮人的疾病、人員流動這些情況本身也不是什麽問題，因為任何人都不可能把所有以外的情況都考慮完整，實際上也沒有必要。但有些諸如下班或節假日的加班時間都被安排用於專案工作的情況就會造成更多的專案不確定性。在可能的情況下當然要對所有可能情況都做到有備無患，但是有的時候也要冒一定的風險，同時對於風險的防範也需要考慮如果防範的成本大於風險本身造成的損失和影響，則這種防範是沒有必要的。
9、程式設計師方面的因素對進度的影響
程式設計師方面有兩種常見的心態影響了進度的控制：一是技術完美主義、二是自尊心。
技術完美主義的常見現象是，有些程式設計師由於進度壓力、經驗等方面的原因，會匆忙先做編碼等具體的事情，等做到一定程度後會想到一些更好的構思，或者看到一些更好的技術的介紹，或者是覺得外部構架可以更加美化，或者是覺得內部構架可以更加優化，這樣他們會私下或公開對軟體進行調整，去嘗試一下新的技術。而是否使用這些新的技術對完成專案本身的目標並沒有影響，相反可能帶來不確定的隱患。這種做法不是以客戶的需求為本、或以專案團隊的總體目標為本，可能對軟體開發進度造成較大的影響。
自尊心的常見想像是，有些程式設計師在遇到一些自己無法解決的問題時，傾向靠自己摸索，而不願去問周圍那些經驗更為豐富的人。有些人也許會通過聊天室等方式匿名地向別人求教。如果運氣好會很快地解決，否則要花很多實踐摸索。而如果向周圍的人求教，可能摸索幾天的問題別人早就解決了。
10、未考慮軟體開發過程的循環、疊代特性
對軟體開發的各個過程分類過於精細，制定進度計劃時各項工作過於緊湊、沒有彈性，造成的後果是，定期提交專案進度階段報告的制度只有在表面上起到效果，按照計劃的時間表提交階段成果也只是在表面上起到效果。因為“上有政策、下有對策”，強行的規定會使人產生一些錯誤的認識。
如在專案計劃中“規定”某個時間只能做某類別的事情，那麽嚴格執行的後果就是編碼階段就不能修改文檔；另外錯誤的“里程碑”概念可能會使大家輕易地相信上一個階段的工作成果都是“通過評審”最終定稿了，而實際上可能只是因為時間到了該提交的人提交、該評審的人評審了。如果上下階段是不同的人就根本不會去檢查其中是否還有錯誤；如果上下階段是同一個人，就可能非正式地修改上一階段的錯誤，但佔用的時間和精力卻是下一階段的，並且這樣的修改時沒有記錄的。這樣關於階段進度控制的措施實際上只是在表面上有效。
最為普遍的情況是，客戶在合約中限定了提交軟體系統的時間，實際上這個時間對完成專案任務來說是遠遠不夠的，但計劃只能按照合約來進行，所以要不客戶讓步，要不只能按照時間的約定提交實際上還未完成的軟體系統，完成系統的安裝，但這時候的“完成階段任務”只是一個表面現象，系統雖然安裝了，但可能是沒有經過嚴格徹底測試的，也可能是只完成了部分的功能，省略了某些功能，有些是整塊功能省略，有的是省略了某些功能的某個過程，如資料錄裡面隱含的初始設定值設置、資料錄檢驗等功能，而是實現了比較粗糙的功能。這樣，系統交付並不意味著專案的完成，而在專案交付之後還要花更多的時間。
11、其他因素
以上這些因素是影響專案進度的幾個主要方面，除此之外還有很多其他的影響因素。其實最主要的因素還是人的因素，這裡的人包括所有與專案相關的人。專案經理的素質、管理者的水準、客戶的因素、專案成員的因素等等，都會對專案進度造成影響，這是因為由於軟體開發的特性。因為篇幅有限無法一一列舉，只能在此分析一些常見的因素。
不可否認，軟體開發專案進度可控性還是帶有一定運氣成分的。特別是需要客戶配合的那些軟體開發專案，其可控性與客戶的成熟度、軟體應用領域的成熟程度和行業標準規範的完備程度有很大關係。關於可控性方面會涉及到一些與客戶打交道經驗，雖然我們說，顧客是上帝、以顧客為中心，但並不是說我們要把主導權交給他們，而關鍵是我們如何去主導、引導、把握。因此，專案控制的好壞與相關人員人際關係方面的經驗也有關係。
儘管存在很多不可控的因素，我們的任務是首先分清哪些是可以控制的，哪些是我們不能控制的。專案經理一是要盡量擴大可控的領域，減少不可控的領域，二是不要在“不可控”上花太多時間，而是多花一些時間把可控的工作控制好，做好防範措施，減輕不可控因素對專案進度的影響。
專案進入實施階段後，專案經理的幾乎所有的活動都是圍繞進度展開的。進度控制的目標與成本控制的目標和質量控制的目標是對立統一的關係。專案的進度、質量和成本構成一個相互制約的三角關係，需要專案經理去平衡。
文章節錄：中國專案管理者聯盟
ProjectClub 專案俱樂部為一群專案經理人組成的平台，網站分享專案運作的各種專案管理手法與實用專案工具，並分享如何提昇職場人的軟技巧與硬實力。
