1.項目進度本身不合理
本著多從自身找原因的準則，對于進度延遲時候應該首先分析項目進度計劃安排本身是否合理？對于項目進度計劃安排是否合理影響因素主要應該從以下幾個方面進行分析和考慮。
估算是否準確
對于估算是否準確是對項目進度計劃安排影響大的一個因素，估算不準確的原因很多，主要的兩個方面是確實有經驗的估算專家和項目缺少歷史數據的收集，對于這兩點只有通過項目多個版本的積累才可能得以改善，而沒有捷徑。另外估算過程中還需要考慮一些特殊因素的影響，如項目新進了幾名新員工可能會降低項目的平均生產率，項目過程中需要采用某種新技術而需要投入額外的預研時間等。
關鍵資源和關鍵路徑的安排是否合理
在進度計劃安排中是否優先保證了項目關鍵路徑上的資源，是否通過人員技能矩陣對項目關鍵資源進行分析和安排。在我們任務安排過程中是否對關鍵資源進行了保護(盡量減少關鍵資源上非關鍵任務的安排)。另外我們在進度計劃安排上應該適當安排10%-15%的余量，這樣在項目遇到突發事件，或項目風險轉變為實際問題時候才能夠有人員和時間進行處理。
項目中的資源是否充分利用
由于存在關鍵路徑和崗位角色矩陣，所以項目中人力資源往往并不能充分利用起來。在中小型項目中為了充分利用相關資源，項目更應該采用敏捷和迭代的開發方法，需求階段開發人員可以先熟悉需求和進行公有組件的開發，而測試階段我們的需求人員也可以介入測試。所以對一個軟件項目而言，需要保證到項目成員的整體利用程度在70%以上，否則應該考慮采用新的開發模式和生命周期模型。
2.團隊和人的問題
軟件項目跟其它工程項目大的不同是人和團隊的因素對項目影響很大，軟件項目中的編碼人員也是重復的創造性的非簡單重復的勞動。軟件工廠在短時間內是無法實現的，所以更必須承認項目中各個成員的價值。工程建設中走了一個泥水工可能馬上能找到替代人手，而軟件項目中人員流失及時很快找到了新成員，也需要花費不定長的培訓和學習時間，新成員才可能真正達到項目要求的生產率。對于這方面影響因素主要分析如下：
人員技能未達到要求
在項目開始之初我們假設項目成員都能夠達到組織級的要求，但往往并不是每個成員都能夠達到要求。而且項目中每個成員的生產率差異可能很大，也給項目進度安排造成影響。所以在項目開始之初應該對項目成員的技能進行一次總體的評估，對于大家都欠缺的技能應該安排統一的培訓，后續還需要對培訓的效果進行跟蹤；對于個別人員技能欠缺的應該單獨預留自我學習時間或通過以師帶徒的方式進行培養，使其技能能夠盡快達到要求;對于項目新員工的工作和任務應該加強評審和Review，保證輸出不出現大的偏差而導致后續大量的返工。
項目成員責任心不強
態度決定一切，細節決定成敗。對于項目過程中的各項任務，經常出現由于項目成員責任心不強而敷衍了事，導致產出的工件質量較差，引起大量返工的情況。在這種情況下項目更應該加強項目規范的建設，項目經理應加強同這些成員的單獨溝通，加強項目的團隊建設和集體榮譽感。讓項目成員感覺到做的系統是他們自己的產品，而不是公司的項目，項目經理的項目。
項目溝通問題
在軟件項目中，保證項目各種角色和成員中的高效溝通是很重要的，如何建立起快捷順暢的溝通渠道，采用佳的溝通方式來解決問題必須在項目中經常強調。一周的項目任務花在實際做事情上只有2天，而花在溝通上占有了3天，如果出現這種情況必須及時分析和總結原因。溝通重要的是要在短的時間里面，采用可以采用的各種方法或工具使交流雙方或多方達成一致。
項目人員流失
項目人員特別是項目關鍵成員在項目進行過程中的流失對項目影響很大，對于這種情況應該在項目開始之初中做為專門的風險進行跟蹤，并考慮具體的應對措施。
3.質量因素的制約
時間和質量是項目中兩個重要因素，在保證項目進度的情況下我們往往會犧牲了項目的質量。而由于軟件項目中測試環節的引入，項目的終產出又需要保證我們的終產品滿足一定的質量規范。所有項目中經常出現項目后期測試問題太多，BUG修改和回歸測試等花費了大量的時間而導致項目的延遲。對于項目質量因素的制約主要分析為：
磨刀誤了砍柴工
由于項目本身進度緊張，往往在項目進行過程中忽略了對項目各階段產出物的質量的評審和Review。導致到項目后期測試時候問題全部暴露出來，而這時候如果是需求引起的缺陷則往往會耗費到前期評審的5-20倍的工作量來進行彌補。所以在軟件項目中應該注重項目各階段的評審和Review工作，提早發現問題并解決問題，避免項目后期大量返工。
4.項目的風險管理工作沒有做好
項目管理是對項目中各種風險和突發事件的管理，管理住了項目的風險項目成功了一半。如果項目經理沒有風險管理意識，對項目可能發生的問題或潛在的不利因素都不能預測到，也沒有提前采取相關的應急措施，則在項目進行過程中風險真正轉化為問題后會導致項目很被動。如前期沒有分析出項目核心成員流失的風險，而在項目進行過程中該核心成員要離職，項目短期無法招到合適新成員，項目中也沒有合適的技能替代成員，這樣對項目的打擊將是致命的。
另外項目還應該形成一套突發事件的應對機制，保證有突發事件時候能夠通過積累的各種方法，工具，預備的資源余量進行跟蹤和處理。
5.項目范圍出現大變動
項目范圍出現大變動，新增加了大量功能的時候往往會直接導致項目延期，在這個時候特別已經是在項目后期時候增加人員往往會使項目進度變的更糟糕。在這種時候往往沒有很好的應對辦法，加班趕進度往往成為了常用的措施。
需求變更多也往往導致項目范圍的變動而影響項目進度，因此在項目管理過程中應該對變更的管理形成一套完善的管理，分析和控制機制，成立變更控制委員會專門對變更進行分析，調查和處理。
6.項目開發模式和選用工具技術是否有問題
這個時候做這個分析已經不可能對當前項目有任何作用，而更多的會總結為相關的經驗教訓避免重犯錯誤。項目開發模式，生命周期選擇，選擇的開發語言，開發環境，相關工具和技術都直接或間接的影響到項目成員的生產率，這些我們在項目估算中可能會做相關考慮，但可能并不能從根本上解決問題，當我們預知客戶的進度要求的時候，更應該通過進度要求去約束我們工具和技術的選擇和使用。
7.系統架構的原因
對于大中型系統總統設計和架構設計更顯重要。架構設計不僅僅要考慮滿足業務的功能性需求，而進行子系統，接口，組件等的設計和劃分；同時架構設計更需要考慮滿足系統的健壯性，可擴展性，性能，安全性，可維護性等非功能性需求。架構人員應該通過架構設計屏蔽整個系統的復雜性，而向模塊設計和開發人員提供一套簡單，高效的開發規程和模式，這樣才能夠真正提高后續設計開發的效率和質量。
對于一個新項目，更應該對項目的總體設計和架構設計預備充足的時間，架構不穩定和成熟代表根基不穩定，這樣的話修再高的樓都會倒塌。要設計一個成熟的架構，架構人員不僅僅要是技術方面的專家，也需要充分理解業務需求，這樣才能夠做出好的架構來。
