进度计划主要是对进度安排的合理性做出评价，目的在于为评价实际进度提供一个可靠的尺度。任何过紧或过松的进度都不足以反映开发方的工作情况。进度太紧会导致项目为了赶工而损害质量，提高成本；进度太松对于开发方没有压力，也会影响质量。合理的进度计划及要给各方一定的压力，要使其通过努力达到既定的目标。

（1）进度计划书的规范性

项目管理人员在审查进度计划时，要检查计划书是否按照标准格式编写，这种格式应尽量依照国家标准和国际标准。如果在某项业务上没有相应的标准，开发方应该预先制定本项目的进度计划编写规范，这个规范应该是经过项目管理人员评审并同意的进度计划的规范，能够全面反映项目过程，并为各种需要阅读计划书的人提供良好的可读性。

（2）计划书内容的完备性

计划中是否反映出时间、人物、结果等形式，在项目计划的早期可以首先建立一个宏观的进度安排表，该进度表应反映出任务的大致时间段，每个阶段的结果形式，如下表所示。

项目阶段	总体进度计划						交付品	负责人
	时间	时间	时间	时间		时间
需求分析
概要设计
详细设计
编码
系统测试

 

随着项目的进展，再将宏观进度表中的每一项内容细化成详细的进度表。详细进度表应该细化到每周，包括每个人的职责和任务分派情况。正确的任务分派要控制好三个关键点：时间点、交付品、责任人。时间点是指任务明确的开始/结束时间，最后同时交代清楚工作上下游关系；交付物是指任务的结果，交付品应明确指明具体要求；责任人应该对具体问题负主要责任，尤其在几人协作完成任务情况下，更要明确负责人，防止责任推诿。任务委派最好有文字记录，如果任务比较简单，可以用责任矩阵描述，而复杂的任务可以给每个人任务书。无论采用那种方式，委派时最好要当面沟通和确认，并得到责任人的承诺。为了检查方便，在制定计划时要注意任务的颗粒度要适中，即应该尽量让任务的工期小于检查周期，这样项目例会上可以比较确切地判断任务的完成情况。

（3）进度安排的合理性

项目管理人员可以从以下几个角度来度量进度安排的合理性：

（1）总的开发周期。总开发周期的制定有两种情况：第一种是首先规定了系统的最终发布日期，并且不能更改，信息系统开发方要在这一约束条件下将工作量分布在预先确定的时间框架中。第二种情况是，大致的时间界限由委托方给定，但需求尚未给定，所以总的开发周期是一个模糊的期限，这种情况下，在开发方对系统进行了解之后，会在总开发周期的基础上做出详细的开发计划，将最好地利用资源的方式对工作量加以分布，这个计划应当由开发方与委托方和监理方共同商量、讨论最后制定新的开发期限。

（2）在制订进度计划时，要根据项目规模分成几个里程碑，两个里程碑之间留大约30%的缓冲时间。

（3）工作量安排。在工作量分布上，可以考虑开发的顺序而统筹规划，有些任务必须顺序执行，而有些可以并发执行，有些只有等其他活动结束时才能开始，有些则可以独立进行。在工作量分配上，项目管理人员应重点考查人员数量与其工作量之间是否平衡，要保证在任一时间段内分配给任务的人员数量不能超过项目人员的数量。例如，一个项目由五人参加，每人每天工作量是1，如果在某一天中需要完成12项并发任务，每个任务需要的工作量是0.5，则这种情况下所分配的工作量就大于可用于分配的工作量，因而是不可行的。

（4）开发人员的可靠性。要充分考虑人员完成任务的能力，避免人员的频繁更换，尤其是主力人员。开发方往往有一种错误认识，即使进度拖延，也可以通过增加更多程序员在后期赶上进度。实际上，项目后期增加人员通常会产生一种破坏性影响，其结果会使进度进一步拖延。主要因为新手必须首先学习这一系统，而培训者正是过去一直工作的人，从而耽误他们的工作，此外，新加入人员会增加人员之间的通信路径数量和整个项目中通信的复杂度，从而需要更多时间。

（5）开发能力与资源的限制。在制定计划时，开发方的能力也是项目管理人员重点考核的因素之一。只有在能力允许下制定的进度计划才是可信的。有时开发方因为某种原因，会出现脱离实际的进度安排。如果开发方是新组建的团队，队伍里缺少富有经验的管理者，再将系统设计时间缩得很短，计划往往会难以修改而容易导致失败。对于新的开发者，在制定计划时不能将计划进度排得太满，要对系统的开发过程留有一定的余地，作为备用和应急准备。

（6）系统开发方法与过程。开发方法不同，各阶段的内容也有不同，每个阶段递交的成果也不同，要考虑计划与开发方法是否对应。

（7）工作量分布。项目各阶段的工作量分配上，有一种推荐性的指导原则，即，“40-20-40”原则，即40%工作量分配给前端的分析与设计，类似比例的工作量用于后端测试，编码的比例大约是20%的工作量。这个原则也要跟具体情况进行调解，如果是大型复杂的软件开发，分析设计任务的工作量多于40%；如软件系统是人命关天的，则要考虑分配更高比例的测试工作量。

 

IT治理框架

信息化/电子政务运维管理

G3研究课题