增加或删除任务算计划的变更吗？

xixiaojing666

在项目每个阶段开始的时候，我们一般会设置一个阶段详细计划，但是随着项目的进展，这个阶段详细计划有增加任务或是删除任务的情况，遇到这种情况，算计划的变更吗？如果算变更，那需要登记变更履历，还要走变更的流程。
如果不算变更，那怎么处理呢？
各位是怎么处理这种情况的呢？


上一篇：资料分享CMM5的过程改进模板
下一篇：如何提高cmmi学习兴趣

xixiaojing666

补充一下，我们流程规定，有大小变更，如果小变更只要走简易的变更流程就好了。
还有每周的周报中记录了任务数的情况，比如本周预计完成任务数、本周实际完成任务数、本周预计累计、本周实际累计、进度偏差等等
如果算变更，项目成员闲麻烦，觉得动不动就需要变更，变更有些频繁
但是如果不算变更，那本周预计完成任务数、本周实际完成任务数、本周预计累计、本周实际累计、进度偏差等等都和以前的不同了，因为删除或增加了任务。
大家是怎么做的呢？遇到增加和删除任务的时候？

lily_014

楼主说的应该跟PM做WBS时的颗粒度大小也有关系。
如果当初颗粒度就做得很细的话，后面就不用再细化这个需求条目了。
你说的应该是对这个需求条目进行细化，细化成每一个任务项。这个在敏捷开发里面应该应用得比较广泛，如一个任务完成时间原则上不超过16小时。。。。像这样细化到每一具体的任务项。
但是 对于目前很多项目来说，首先需求并不会那么明确，会是在以后逐渐去完善的。所以 如果不是需求条目增加或删除，而是需求下面的某一项任务的变动。通常 我们的做法是没有定义为一个变更（本身我们变更控制的也不会非常严格，因为客户的关系的原因）。但是这个要不要作为一个变更项来控制，还得看公司的定义了。

再说一句，你们跟踪的很细呀。。。:D

fanyuetian

如果遇到这个问题却不知道如何解决的时候，说明您公司的项目变更管理流程没有定义清楚。

根据你所叙述的情况，是不属于变更的。
根据一般流程来定义，如果涉及到计划变更有如下几种状况：
1、项目关键节点无法按期完成；
2、项目整体偏差超过组织级阈值；
3、项目整体进度超过项目启动时制订的偏差范围；
4、项目关键任务需要做大范围的调整；
5、人力资源需要做大的调整；
....

还有一些情况可以根据项目实际情况的不同来设定，仅仅是增加/删除一些子任务，不能算计划的变更。

反正有一点是肯定的，如果里程碑节点受到影响的话，计划是一定需要做变更管理的。

xixiaojing666

原帖由 lily_014 于 2008-9-11 14:02 发表
楼主说的应该跟PM做WBS时的颗粒度大小也有关系。
如果当初颗粒度就做得很细的话，后面就不用再细化这个需求条目了。
你说的应该是对这个需求条目进行细化，细化成每一个任务项。这个在敏捷开发里面应该应用得比较广 ...

谢谢!:kiss:

xixiaojing666

原帖由 fanyuetian 于 2008-9-11 17:05 发表
如果遇到这个问题却不知道如何解决的时候，说明您公司的项目变更管理流程没有定义清楚。

根据你所叙述的情况，是不属于变更的。
根据一般流程来定义，如果涉及到计划变更有如下几种状况：
1、项目关键节点无法按 ...

说的有道理,还是变更定制的不详细!
谢谢:handshake

hanwei

可以算是变更，但是变更影响小的，PM可以做决定的，走简易流程。

tempsir

谢谢lz，辛苦了，非常有用

wei_sa

这个要看具体情况而定了
一般来说如果影响里程碑或者交付点时需要走计划变更流程，如果在变更的阈值范围内，则可项目组内部调整就可以了

xuncc

我们变更的主要目的是为了计划能够可控，为了能让干系人了解更准确的项目情况，从而获得更多的资源进一步提高计划的可控性。根据这一思想。如果删除或增加的任务会影响计划的可控性，或会对资源需求产生较大的变化时，就应该进行变更！以上为个人观点仅供参考哦。

肥皂泡泡134

tjvictor

PMI推荐所有的变更都需要走变更流程。可是实际情况是一些很小的变更如果走流程，就太麻烦了。我个人认为，不影响进度、范围、成本和风险的变更且是企业内部的项目时，PM自己决定就行了。其他一定要走变更流程，省得以后扯皮。尤其是客户以此为理由不付全款，再时麻烦就大了。

mylikes2000_3

向大家学习了！

mylikes2000_2

这个是很纠结的

风清云闲

总是有各种各样的问题，学习着先。