同一领域的类似项目，这样才有较强的可比性。由于这些计划安排是预估粗略的，所以还必须在以后的项目各阶段完成后进行合理的变更，反应项目的实际需求。微软的办法是把进度估计的权限交给开发人员，由开发人员根据自己的经验进行估计，由于一般开发人员往往会高估自己的能力，估计的进度也会相应偏短，最后再做适当的延长[2]。这种办法有它合理的地方，在中国还需进行实践摸索。
对于进度的估计，我们有个经验公式，即您最初预估的时间再乘以2.5，可能是最后的完成时间。因为许多人在估计进度的时候，往往忽略了很多非开发时间，如与客户沟通的时间、项目组沟通时间、公司培训时间、假期等，所以我们在估计进度的时候，一定要全方位周全考虑，在尽可能的情况下宁愿把进度估计的长一点，免得在项目后期导致非常被动的局面。后面我们将具体讲到我们采取的阶段性的开发方法，这种方法的运用反映在进度估计时必须在各阶段间预留缓冲时间，以解决那些我们事先没有预料到的活动。如果进度表和要求的出货时间有冲突，宁愿砍掉一些不重要的功能，也不要盲目增加人手，这种做法可能会导致产品质量下降，最终得不偿失，详细说明请参考[4]。
风险管理是项目管理中非常重要的部分，并且要贯穿项目的始终。一些软件企业往往不是很重视风险管理，导致在项目的后期出现了很多预料之外的事情，使项目进度一拖再拖，往往质量也达不到预期要求。因此我们要特别重视风险的管理，具体方法留待后面专门详述。
3.2.4开发过程
在项目的开发过程中，我们采用了阶段式的开发过程，这也是微软公司所推荐的开发过程。在开发过程的初期，首要的活动是概要设计。概要设计的目标是简单、适用、能够覆盖所有的需求并能支持后面的阶段式开发。微软的应用方案解决模型是基于服务的三层(多层)架构，包括用户层，业务层和数据层，各层之间采用标准的接口进行通讯，至于该方法的具体使用，请参看相关书籍，在此就不在赘述了。
阶段开发过程不是传统的根据模块划分来依次完成各模块，最后再进行项目的整合，而是在每个阶段完成后，项目都可以推出产品，只不过该产品的功能比最终产品的功能弱一些。
阶段性完成项目比传统的开发方法最明显的优点是不必到项目的末期才开始整合产品，使产品模块之间协作产生的问题及早产生，也及早修正，从而项目的风险也大大减小。传统的开发总是在项目的后期才开始整合各模块，使产生的问题改正起来极为困难，成本也大大增加;前面累计的所有问题全部都拖到了后面来解决，也使后面剩下的工作量大大增加。项目往往看起来已完成了90%——大部分的功能模块都已完成，但剩下的10%总是完不成，项目进度一拖再拖，很可能还要再花90%的时间来完成剩下的10%。当然采用阶段性开发方法也有相应的代价，最大的代价可能是反复的整合、测试已经完成的模块，但采用相应的一些自动化工具可以减小这个代价。
一般在开始的阶段进行的是系统架构和最重要的功能，后面的阶段是相对不怎么重要的功能。这样的分配有利于最终用户在早期就能看到系统的大致模样，便于他们及早的对产品提出意见，并对相应的错误进行修改;也有利于项目组在项目后期时间很紧的情况下，去掉一些不重要的功能，把它们纳入下一个版本处理，确保产品的推出时间。迭代的顺利进行依赖于良好的架构设计，前面阶段的设计应该给后面要加入的功能预留出各种接口，并能使后面的工作在前面的基础上继续进行下去。
这种在开发阶段的迭代方式不同于整个项目的完全迭代开发，后者是项目的需求、概要设计、开发等全部是迭代进行，一次迭代要进行所有的项目活动。至于谁优谁劣可能在不