进度问题是IT项目管理最为关注的问题之一。进度的可保证性和可控制性来源于项目计划的科学性，项目计划对进度预测的准确性又来源于估算的准确性，估算是否准确又涉及到项目规模，根据规模可以得到工作量，根据工作量和人力资源的投入和任务依赖约束可以得到最终的进度。当软件产品的规模增加的时候，复杂度成倍增长，从而导致这些要素之间不是单纯的线性关系，这是人月神话的启示之一；同时由于软件项目本身的生命周期模型和工序任务限制，导致对于一定规模的软件产品研发，无论投入多少的资源，都有一个最短工期的限制，在这个最短工期下投入再多的资源也没有用。
对于估算假设人月可以互换的问题是可以引入CocomoII估算模型来估算工作量和进度的，对于中小型产品和项目的估算更多仍然需要依靠专家的经验，对于大型项目则需要遵循一定的方法和估算模型。因此大型项目仍然强调的是首先要估算出软件产品的规模，规模结合生产率得到工作量，工作量结合进度安排和相关模型得到项目周期。当按照这种思路的时候我们就会有意识的去积累生产率，评审效率，缺陷密度等原始数据。估算的基础是用户需求，但往往我们就是在用户需求不明确的情况下盲目估算。对于企业信息化相关软件系统，对于全新启动和开发的产品估算往往是最不准确的，因为缺乏相关的历史数据，经验积累，估算参与人员也缺乏对业务和需求的深入理解。对于PSP个体软件过程的推广有利于提升估算能力，因为可以让开发人员更加准确的认识到自我的开发生产率。对于技术架构的完善和技术的积累有利于提高估算水平，因为技术越完善后期的技术研究任务越少，而技术研究往往是具有高度不确定性的任务。开发人员对所属业务领域的深入理解有利于提高估算水平，任何一个需求功能点中对规模和工作量影响最大的是业务规则的复杂性，而不是该需求所涉及到的UI界面和基本流程。
乐观主义假设一切都会运转良好，而不会遇到任何的风险和问题。而恰恰实际情况是在实际开发中遇到一个疑难问题耽误几天或一周的时间，虽然我们做了风险识别和分析，但仍然无法避免各种突发疑难问题的产生。通过PERT计划评审技术和三点法估算可以看到，如果我们完全按照对乐观方式来估算，能够按进度正常完成概率往往是0%，如果我们按照最悲观的方式估算也很难真正保证100%能够按期完成。如果我们按照最可能估算，我们期望达到80%的概率能够按期完成，这说明将进度偏差控制在20%的范围内，20%有可能是我们能够容忍的进度控制范围。
创造性活动包括了构思，实现和交流三个阶段。第一个构思本来就需要花时间，在开发活动中开发人员实际想的时间(想本身就是一种分析和设计活动)往往比实际敲代码行的时间多的多；第二构思本身是不完整的，在实现中要不断的验证和修改构思，这种不断的往复是需要花时间的，例如开始假设的某种代码实现方法行不通，不得不全部推倒构思新的算法来实现。还有大型系统会进行多层WBS分解，任务之间存在复杂的关联依赖关系，在路径汇聚点上任何一个任务的延期都将导致后续任务的延期。
