1.项目进度本身不合理

　　本着多从自身找原因的准则，对于进度延迟时候应该首先分析项目进度计划安排本身是否合理？对于项目进度计划安排是否合理影响因素主要应该从以下几个方面进行分析和考虑。
 
　　估算是否准确
　　对于估算是否准确是对项目进度计划安排影响最大的一个因素，估算不准确的原因很多，主要的两个方面是确实有经验的估算专家和项目缺少历史数据的收集，对于这两点只有通过项目多个版本的积累才可能得以改善，而没有捷径。另外估算过程中还需要考虑一些特殊因素的影响，如项目新进了几名新员工可能会降低项目的平均生产率，项目过程中需要采用某种新技术而需要投入额外的预研时间等。
 
　　关键资源和关键路径的安排是否合理

　　在进度计划安排中是否优先保证了项目关键路径上的资源，是否通过人员技能矩阵对项目关键资源进行分析和安排。在我们任务安排过程中是否对关键资源进行了保护(尽量减少关键资源上非关键任务的安排)。另外我们在进度计划安排上应该适当安排10%-15%的余量，这样在项目遇到突发事件，或项目风险转变为实际问题时候才能够有人员和时间进行处理。
 
　　项目中的资源是否充分利用

　　由于存在关键路径和岗位角色矩阵，所以项目中人力资源往往并不能充分利用起来。在中小型项目中为了充分利用相关资源，项目更应该采用敏捷和迭代的开发方法，需求阶段开发人员可以先熟悉需求和进行公有组件的开发，而测试阶段我们的需求人员也可以介入测试。所以对一个软件项目而言，需要保证到项目成员的整体利用程度在70%以上，否则就应该考虑采用新的开发模式和生命周期模型。
 
　　2.团队和人的问题
 
　　软件项目跟其它工程项目最大的不同就是人和团队的因素对项目影响很大，软件项目中的编码人员也是重复的创造性的非简单重复的劳动。软件工厂在短时间内是无法实现的，所以更必须承认项目中各个成员的价值。工程建设中走了一个泥水工可能马上就能找到替代人手，而软件项目中人员流失及时很快找到了新成员，也需要花费不定长的培训和学习时间，新成员才可能真正达到项目要求的生产率。对于这方面影响因素主要分析如下：
 
　　人员技能未达到要求

　　在项目开始之初我们假设项目成员都能够达到组织级的要求，但往往并不是每个成员都能够达到要求。而且项目中每个成员的生产率差异可能很大，也给项目进度安排造成影响。所以在项目开始之初应该对项目成员的技能进行一次总体的评估，对于大家都欠缺的技能应该安排统一的培训，后续还需要对培训的效果进行跟踪；对于个别人员技能欠缺的应该单独预留自我学习时间或通过以师带徒的方式进行培养，使其技能能够尽快达到要求;对于项目新员工的工作和任务应该加强评审和Review,保证输出不出现大的偏差而导致后续大量的返工。
 
　　项目成员责任心不强

　　态度决定一切，细节决定成败。对于项目过程中的各项任务，经常出现由于项目成员责任心不强而敷衍了事，导致产出的工件质量较差，引起大量返工的情况。在这种情况下项目更应该加强项目规范的建设，项目经理应加强同这些成员的单独沟通，加强项目的团队建设和集体荣誉感。让项目成员感觉到做的系统是他们自己的产品，而不是公司的项目，项目经理的项目。
 
　　项目沟通问题

在软件项目中，保证项目各种角色和成员中的高效沟通是很重要的，如何建立起快捷顺畅的沟通渠道，采用最佳的沟通方式来解决问题必须在项目中经常强调。一周的项目任务花在实际做事情上只有2天，而花在沟通上占有了3天，如果出现这种情况必须及时分析和总结原因。沟通最重要的就是要在最短的时间里面，采用可以采用的各种方法或工具使交流双方或多方达成一致。
 
　　项目人员流失

　　项目人员特别是项目关键成员在项目进行过程中的流失对项目影响很大，对于这种情况应该在项目开始之初中就做为专门的风险进行跟踪，并考虑具体的应对措施。 
 
　　3.质量因素的制约
 
　　时间和质量是项目中两个重要因素，在保证项目进度的情况下我们往往会牺牲了项目的质量。而由于软件项目中测试环节的引入，项目的最终产出又需要保证我们的最终产品满足一定的质量规范。所有项目中经常出现项目后期测试问题太多，BUG修改和回归测试等花费了大量的时间而导致项目的延迟。对于项目质量因素的制约主要分析为：
 
　　磨刀误了砍柴工

　　由于项目本身进度紧张，往往在项目进行过程中忽略了对项目各阶段产出物的质量的评审和Review。导致到项目后期测试时候问题全部暴露出来，而这时候如果是需求引起的缺陷则往往会耗费到前期评审的5-20倍的工作量来进行弥补。所以在软件项目中应该注重项目各阶段的评审和Review工作，提早发现问题并解决问题，避免项目后期大量返工。
 
　　4.项目的风险管理工作没有做好
 
　　项目管理就是对项目中各种风险和突发事件的管理，管理住了项目的风险项目就成功了一半。如果项目经理没有风险管理意识，对项目可能发生的问题或潜在的不利因素都不能预测到，也没有提前采取相关的应急措施，则在项目进行过程中风险真正转化为问题后就会导致项目很被动。如前期没有分析出项目核心成员流失的风险，而在项目进行过程中该核心成员要离职，项目短期无法招到合适新成员，项目中也没有合适的技能替代成员，这样对项目的打击将是致命的。
 
　　另外项目还应该形成一套突发事件的应对机制，保证有突发事件时候能够通过积累的各种方法，工具，预备的资源余量进行跟踪和处理。 
  　　5.项目范围出现大变动
 
　　项目范围出现大变动，新增加了大量功能的时候往往会直接导致项目延期，在这个时候特别已经是在项目后期时候增加人员往往会使项目进度变的更糟糕。在这种时候往往没有很好的应对办法，加班赶进度往往成为了最常用的措施。
 
　　需求变更多也往往导致项目范围的变动而影响项目进度，因此在项目管理过程中应该对变更的管理形成一套完善的管理，分析和控制机制，成立变更控制委员会专门对变更进行分析，调查和处理。
 
　　6.项目开发模式和选用工具技术是否有问题
 
　　这个时候做这个分析已经不可能对当前项目有任何作用，而更多的会总结为相关的经验教训避免重犯错误。项目开发模式，生命周期选择，选择的开发语言，开发环境，相关工具和技术都直接或间接的影响到项目成员的生产率，这些我们在项目估算中可能会做相关考虑，但可能并不能从根本上解决问题，当我们预知客户的进度要求的时候，更应该通过进度要求去约束我们工具和技术的选择和使用。
7.系统架构的原因
 
　　对于大中型系统总统设计和架构设计更显重要。架构设计不仅仅要考虑满足业务的功能性需求，而进行子系统，接口，组件等的设计和划分；同时架构设计更需要考虑满足系统的健壮性，可扩展性，性能，安全性，可维护性等非功能性需求。架构人员应该通过架构设计屏蔽整个系统的复杂性，而向模块设计和开发人员提供一套简单，高效的开发规程和模式，这样才能够真正提高后续设计开发的效率和质量。 
 
　　对于一个新项目，更应该对项目的总体设计和架构设计预备充足的时间，架构不稳定和成熟代表根基不稳定，这样的话修再高的楼都会倒塌。要设计一个成熟的架构，架构人员不仅仅要是技术方面的专家，也需要充分理解业务需求，这样才能够做出好的架构来。