产品质量往往是基本，这是一个默认属性。但是做到哪个度仍然可以谈，所以首先要清楚用户对质量要求的优先级，一般来言可能是可用->易用->性能->安全。这一般叫测试类型，另外就是测试的等级表明测试要达到何种覆盖率或程度。这些都影响到项目周期。

　　除了默认质量要求，项目周期往往是客户最为关注的。这个往往并不是经过详细的估算，排完进度了再确定下来的，而是项目一开始往往就由客户敲定，而项目范围往往也是在合同就会明确下来。所以跟用户敲项目周期就显得很重要了，根据软件工程和经济学得出结论是：对于一个软件项目我们可以考虑投入更多资源来缩短项目周期，但当项目周期缩短到一定度以后，投入再多的资源也没有用。因此项目经理谈判的底线为在不考虑人力资源情况下项目能够达到的最短周期，如果这个最短周期还达不到客户要求，必须缩减项目范围而不是牺牲产品质量。

　　项目计划重点就是通过调整各个要素，保证项目能够有8,9成以上的胜算，对于影响到项目成功的全部列入风险和关键问题进行跟踪。项目经理在计划完成后一大半的时间都应该花费在消除不确定性上。项目失败往往并不是进展过程出现太多异常，而是一开始项目经理就不清楚自己有几层把握，一开始也没有分析清楚有哪些不确定性和关键要素。

　　项目周期敲定了再排进度

　　如果简单的认为项目周期确定了再排进度就只能是倒排进度，那说明还没有真正理解各要素的平衡和进度安排的实际含义。项目经理往往根据项目周期倒排不切实际的进度计划，那导致项目进度延期就是必然的事情了。

　　制定进度前最重要的仍然是根据人力资源情况和项目周期来综合考虑生命周期模型的选择，是瀑布还是增量迭代，这个直接影响到WBS的分解。而WBS中我们又最关心工作包或任务的粒度问题，这个需要和可用的人力资源配合起来，一个功能模块分解细后可以更多的人力资源参与进来，使更多的任务能够并行，但无疑会增加前面接口设计和后期集成的工作量。当接口设计和集成工作所花费时间大于开发任务并行所缩短的时间时候，这个时候就到了分解的最小粒度。在这个粗细粒度间就是可以通过调配人力资源能够获取的最大进度压缩。