项目进度状况通常是通过各工程活动完成程度(百分比)逐层统计汇总计算得到的。进度指标的确定对进度的表达、计算、控制有很大影响。项目进度管理是在项目实施过程中，对各阶段的进展程度和项目最终完成的期限所进行的管理。在实际项目操作中，总有影响项目进度的因素出现。
1、使用敏捷开发
敏捷开发，这是现在非常时兴的一个词，听起来挺牛逼的，敏捷，让我们感觉用了它就会“快”。在被这种开发模式折磨了1年多的我想说，其实它跟其他所有的事情都一样，它有自己适用的领域，假如错误的以为任何项目用敏捷开发都能敏捷，那就是自找苦吃。
为什么?敏捷开发的特点就是根据用户的需求迭代，一个迭代解决一个迭代的问题，对于一个对于架构清晰的项目来说，这样每一个迭代都会有一些成果。而对于有些项目而言，比如说杀毒软件，磁盘分析器等等，对于这种产品类的项目，很多时候它的需求都是一开始需要定义清楚的，客户名义上是广大的PC用户，实际上是PM或是PGM，PM说这个项目里面我们要做3个功能，那我们就需要做3个功能，多一个不行，少一个也不行，如果PGM在你做了3个功能后告诉你，要加一个功能，而且这个功能在旧的架构上是很难实现的，那么这个PGM就是不合格的，为什么?因为他加大了项目的成本。所以，我想说的是，如果需求是由我们自己定义，而且我们很清楚要做一个什么东西的时候了，采用敏捷开发的风险可能会加大，因为它过多的依赖于“迭代”，认为迭代可以解决大多数的问题，可是实际情况远不如此乐观!当你的PM对你我们要加这个新功能，之前的定义的功能不行这个迭代要改的时候，作为一个程序员，我们能做什么呢?去跟PM说，对不起，我们之前的底层架构不支持这种变态的需求，PM会告诉你，我就是代表客户，这个功能就得这么做，我说了算，为什么不支持，我们不是采用的敏捷开发吗，敏捷开发的特点不是迭代来解决问题吗?
老实说，瀑布模型的好处之一，就是你的PM可以少几个变需求的理由，PM一个星期变一次需求，我们程序员就没有幸福可言了，所以，我想劝有些项目经理，别拿需求的变更当做理所应当的，你不是一个娇生惯养的小孩，没有必要变的需求就不要变，如果你把敏捷开发的需求变更当做是你隔三差五变需求的理由，那下个项目，当你的程序员听说你要用敏捷开发，肯定想抱头痛哭。你是产品的设计师，这个产品的外观功能，应该一开始就定义好，不要前一个月说要做个电饭煲，这个月又说要在电饭煲加个微波炉的功能，如果你手下的程序员任劳任怨，把微波炉的功能真的加进了电饭煲，那只能说PM幸运，碰到了技术牛人，并且技术确实是可行的，但是如果功能实现不了，那么PM可能就怪开发者，觉得他们技术不行，心想我用的是敏捷开发，为什么我给了你们时间缺不能解决问题呢?
时间确实是可以解决问题，但是作为开发者更希望把时间多花在需求分析阶段，而不是修改旧的代码上。开发模型只是一种工具，依赖敏捷开发这个工具，并不是解决所有问题的万金油。
作为项目经理，你不光要对客户负责，更需要对产品负责，对你手下的程序员负责。其实，假如做不到后面两点第一点也不好做到，因为项目很可能经常delay，到最后客户不满意，或者产品上线的时候早已经落于市场上其他的产品。
2、角色分配
角色分配的问题在整个软件开发过程也是很重要的，说简单点就是分工要明确，按照博弈论的观点，假如我们每个人的目标都是合理的，那么我们通过相互的制约很好的推进项目的周期，但是如果角色分配的不合理，比如说职责重复，缺少角色等等，那么开发的过程