7、计划变更调整的及时性
渐近明细是项目的特点，特别是对于软件开发项目，并不是一个一成不变的过程。开始时的项目计划可以先制定得比较粗一些，随着项目的进展，特别是需求明确以后，项目的计划就可以进一步的明确，这时候应该对项目计划进行调整修订，通过变更手续取得项目干系人的共识。计划应该随着项目的进展而逐渐细化、调整、修正。没有及时调整的计划或者是随意的不负责任的计划的项目是难以控制的。在高技术行业，日新月异是主要特点，因此计划的制定需要在一定条件的限制和假设之下采用渐近明细的方式，随着项目的进展进行不断细化、调整、修正、完善。对于较为大型的软件开发项目的工作分解结构可采用二次甚至多次 WBS 方法。即根据总体阶段划分的总体 WBS ，需求调研阶段结束、概要设计完成后专门针对详细设计或编码阶段的二次 WBS 。由于需求的功能点和设计的模块或组件之间并不是一一对应的关系，所以只有在概要设计完成以后才能准确地得到详细设计或编码阶段的二次 WBS ，根据代码模块或组件的合理划分而得出的二次 WBS 才能在详细设计、编码阶段乃至测试阶段起到有效把握和控制进度的作用。有些项目的需求或设计做得不够详细，无法对工作任务的分解、均衡分配和进度管理起参考作用，因此要随着需求的细化和设计的明确，对项目的分工和进度进行及时的调整，使项目的计划符合项目的变化，使项目的进度符合项目的计划。
8、未考虑不可预见事件发生造成的影响
假设、约束、风险等考虑“不周”造成项目进度计划中未考虑一些不可预见的事件发生。例如软件开发项目还会因为项目资源特别是人力资源缺乏、人员生病、人员离职、项目团队成员临时有其他更紧急的任务造成人员流动等不可预见的事件对项目的进度控制造成影响（即项目按时完成是基于如下假设：人力资源不会缺乏、人员不会生病、人员不会流动）。企业环境、社会环境、天灾人祸等事件对项目的进度控制造成影响。对项目的假设条件、约束条件、风险及其对策等对于进度的影响在项目计划要进行充分的考虑，在项目进展过程中也要不断地重新考虑有没有新的情况，新的假设条件、约束条件、潜在风险会影响项目的进度。假设是通过努力可以直接解决的问题，而这些问题是一定要解决才能保证项目按计划完成；约束一般是难以解决的问题，但可以通过其他途径回避或弥补、取舍，如牺牲进度、质量等等；假设与约束是针对比较明确会出现的情况，如果问题的出现具有不确定性，则应该在风险分析中列出，分析其出现的可能性、造成的影响、采取的措施。实际上像没有考虑人的疾病、人员流动这些情况本身也不是什么问题，因为任何人都不可能把所有以外的情况都考虑完整，实际上也没有必要。但有些诸如下班或节假日的加班时间都被安排用于项目工作的情况就会造成更多的项目不确定性。在可能的情况下当然要对所有可能情况都做到有备无患，但是有的时候也要冒一定的风险，同时对于风险的防范也需要考虑如果防范的成本大于风险本身造成的损失和影响，则这种防范是没有必要的。
9、程序员方面的因素对进度的影响
程序员方面有两种常见的心态影响了进度的控制：一是技术完美主义、二是自尊心。
技术完美主义的常见现象是，有些程序员由于进度压力、经验等方面的原因，会匆忙先做编码等具体的事情，等做到一定程度后会想到一些更好的构思，或者看到一些更好的技术的介绍，或者是觉得外部构架可以更加美化，或者是觉得内部构架可以更加优化，这样他们会私下或公开对软件进行调整，去尝试一下新的技术。而是否使用这些新的技术对完成项目本身的目标并没有影响，相反可能带来不确定的隐患。这种做法不是以用户的需求为本、或以项目团队的总体目标为本，可能对软件开发进度造成较大的影响。
自尊心的常见想象是，有些程序员在遇到一些自己无法解决的问题时，倾向于靠自己摸索，而不愿去问周围那些经验更为丰富的人。有些人也许会通过聊天室等方式匿名地向别人求教。如果运气好会很快地解决，否则要花很多实践摸索。而如果向周围的人求教，可能摸索几天的问题别人早就解决了。
10、未考虑软件开发过程的循环、迭代特性
对软件开发的各个过程分类过于精细，制定进度计划时各项工作过于紧凑、没有弹性，造成的后果是，定期提交项目进度阶段报告的制度只有在表面上起到效果，按照计划的时间表提交阶段成果也只是在表面上起到效果。因为“上有政策、下有对策”，强行的规定会使人产生一些错误的认识：如在项目计划中“规定”某个时间只能做某某类别的事情，那么严格执行的后果就是编码阶段就不能修改文档；另外错误的“里程碑”概念可能会使大家轻易地相信上一个阶段的工作成果都是“通过评审”最终定稿了，而实际上可能只是因为时间到了该提交的人提交、该评审的人评审了。如果上下阶段是不同的人就根本不会去检查其中是否还有错误；如果上下阶段是同一个人，就可能非正式地修改上一阶段的错误，但占用的时间和精力却是下一阶段的，并且这样的修改时没有记录的。这样关于阶段进度控制的措施实际上只是在表面上有效。最为普遍的情况是，用户在合同中限定了提交软件系统的时间，实际上这个时间对完成项目任务来说是远远不够的，但计划只能按照合同来进行，所以要不用户让步，要不只能按照时间的约定提交实际上还未完成的软件系统，完成系统的安装，但这时候的“完成阶段任务”只是一个表面现象，系统虽然安装了，但可能是没有经过严格彻底测试的，也可能是只完成了部分的功能，省略了某些功能，有些是整块功能省略，有的是省略了某些功能的某个过程，如数据录入里面隐含的数据录入前缺省值设置、数据录入检验等功能，而是实现了比较粗糙的功能。这样，系统交付并不意味着项目的完成，而在项目交付之后还要花更多的时间。
11、其他因素
以上这些因素是影响项目进度的几个主要方面，除此之外还有很多其他的影响因素。其实最主要的因素还是人的因素，这里的人包括所有与项目相关的人。项目经理的素质、管理者的水平、用户的因素、项目成员的因素等等，都会对项目进度造成影响，这是因为由于软件开发的特性。因为篇幅有限无法一一列举，只能在此分析一些常见的因素。
不可否认，软件开发项目进度可控性还是带有一定运气成分的。特别是需要用户配合的那些软件开发项目，其可控性与用户的成熟度、软件应用领域的成熟程度和行业标准规范的完备程度有很大关系。关于可控性方面会涉及到一些与客户打交道经验，虽然我们说，顾客是上帝、以顾客为中心，但并不是说我们要把主导权交给他们，而关键是我们如何去主导、引导、把握。因此，项目控制的好坏与相关人员人际关系方面的经验也有关系。
尽管存在很多不可控的因素，我们的任务是首先分清哪些是可以控制的，哪些是我们不能控制的。项目经理一是要尽量扩大可控的领域，减少不可控的领域，二是不要在“不可控”上花太多时间，而是多花一些时间把可控的工作控制好，做好防范措施，减轻不可控因素对项目进度的影响。
项目进入实施阶段后，项目经理的几乎所有的活动都是围绕进度展开的。进度控制的目标与成本控制的目标和质量控制的目标是对立统一的关系。项目的进度、质量和成本构成一个相互制约的三角关系，需要项目经理去平衡。
