1.有一些任务的不确定性实在太大,比如遇到政府部门的相关任务,可能一个早上就全部搞定,有可能遇到很多无法预料的风险,就是搞不定.这里不确定性非常大,几乎无法制定任务的工期.因为不知道什么时候可以做完,另外这个无法确定下来的任务是非常关键的任务,几乎是很多任务的前置任务.如果这个任务的时间进度没有办法确定几乎整个计划的时间进度都受到影响.我不知道project里面如何实现这种需要很大弹性的时间进度.我原来提出的解决方案是先定下来一个时间,后面可以通过变更计划来使时间进度和现实进展相适应.但是他们反对说这个老是要修改,而且这样一开始的时间进度都毫无意义了,不如不做,我不知道是不是有一个软件和人员工作互相妥协的解决方案,来实现这种包含非常大不确定性任务的项目计划制定.

2.第二个是人员工作方式的问题.项目人员倾向于这样制定计划,即指定在若干天内完成若干任务,剩下的让自己自由分配工作.我原来想让他们就把这些任务的工期就放长到这个时间段,在单位上作相应的缩减,但是这样在跟踪上是不是会出现问题.另外他们对这个也不是太满意.到底是让工作方式向软件妥协还是另辟蹊径?

总之是人员要求比较弹性的时间进度,但是我的project还没有发现太多这样的方法.大家可以提一些在project上面实现弹性工作进度的方法经验么. 谢谢.

1.比较基准的应用我已经实施了，除了红绿灯和跟踪甘特图对于比较基准的应用还有什么其它的，我了解的只有这么多。关于进度跟踪方法，因为项目经理认为没有办法提供比较有效的任务成本（这点我会再讨论）所以没有采用你以前提出的EVM方法，只能用时间进度来标志。

另外这种高风险的任务进行标识，但是制定计划还是要定一个时间，项目经理对这种高风险任务定下具体工期十分反感，要不就是定下一个很长的工期，在甘特图上拉上很长的一条。并且制定风险应急方案也是他们没有做到的，在项目实施过程中，有很多次就是因为没有制定风险应急方案而严重耽误项目，为此总经理也大发雷霆，但是情况还是照旧，我对于自己能够让他们去重视应付风险信心不是很足。

2.对于你说的用概括性质的任务覆盖剩下的，我没有理解。举个例子吧。公司的业务部门提出他们实际的工作方式是这样的，比如他们计划在三天内进行手机购买，走访客户，业务洽谈三个任务，这三个任务之间没有逻辑关系。他们期望制定的计划应该是在这三天中他们随意安排在某个时间段把这三个业务完成。但是如果把这三个任务的工期都定义成为同样的三天，那么他们的工时就会被错误的过量统计。那么我的建议是减少他们在资源上的投入单位，把100%减少到他们在三天内此任务投入时间的相应比例，这里还是要估算他们任务的工时，但是好像项目人员不愿意估计每一个工作的工时，他们还是习惯笼统地三天作三件事情。不知道这里谁应该妥协去适应谁。另外还有一个问题就是及时把资源投入单位按比例减小，但是这样的含义是每天投入这么多时间和实际操作中是在一个长期时间段中的一个时间集中完成是不同的，这样在跟踪和其它过程中是不是会出一些问题。比如员工在pwa中汇报自己的进度。

一个总的问题就是在项目中因为各种原因不能提供制定一个理想计划的各种信息，甚至缺失很多信息，那么这些信息应该如何处理，应该勉强估计填入完成计划制定以后再来调整，还是有什么其它的方法。我是指这个估计很困难，这种困难可能来自于客观情况，可能来自员工自身的意愿以及项目管理水平，比如我的公司其实各个员工对项目管理都没有什么概念。

我想如果不是很复杂的话也可以考虑合并在一起，也不必细分他们的工时再累加，就这么几天，资源单位100%。但不相关的任务合并在一起总别扭。最后他们的这个要求被部门的头压了下去，我想问题还是没有解决，还会产生反感情绪。

1.例如有三个任务阿A,B,C,前者分别为后者的前置任务，A，B为高风险，C 为比较确定的任务.因为A为高风险,很难确定什么时候能做的好,那么项目经理在估计工期的时候为了避免责任就把这个A任务拉的很长,实际上只是表达A项目在这个时间内的某几天可能作的完,B作为A的后置同样拉的很长的时间跨度.也是表示B可能在这个时间跨度内完成.最后这个项目被制定的工期很长,第二人员的工时也不能正确地计算,比如在这个时间跨度内不预期的某天,政府通知手续通过了,那人员就在此天去办完手续.实际上工作只花了一两天.耗费办事人员工时只有一两天.拉长的剩下的时间也购销掉,后置任务可以提前.

3.继续分解,细化工作结构分解,我觉得可以尽量的估计风险,而且对于风险因素更加的了解也有利于风险方案的制定,但是如果项目经理不要呢?该怎么说服他们呢?总经理说要来硬的,但是说完就扔了,她不是直接监督他们.我总不能来硬的吧,又不是也不能是钦差大臣

有什么更好的进度计划来描述这种特点的项目实施么?
与比较基准的比较出现的偏差项目经理视为一种要负担的责任.我不知道怎么说服他们.

1.“例如有三个任务阿A,B,C。。。”
->这样的任务工期可以拖长，但工时可能很少，所以工时应该不会有不能正确计算的问题？如果政府通知手续一直没有来，该人员会做项目范围内的其他工作吗？

至于第3个问题，这个项目的进度目标有吗？如果进度目标因为政府的原因无法保证的话会怎么办？

最后的一段，项目经理的职责就是在自己可控的范围内保证达成项目目标。如果他们认为比较基准不是目标（视为负担），那么目标如何设定才会合理？

退一步讲，比较基准的确是负担，因为设定比较基准的时候相当于下了一个承诺，一诺千金不是那么容易做到的。如果进度的确是高层关心的事情，那我觉得现在是个好现象也，因为项目经理感到了前所未有的压力，而这个压力是高层希望应有的。

不过这里有个陷阱：在使用MSP提供了更高的可视性以便高层能够提高施压能力的同时，作为高层却不向项目组提供任何帮助（比如针对原因提出建议）或者激励措施，那么MSP及其推行者难免将成为众矢之的。

上面说的是项目经理朝上看高层，换个角度朝下看组员的话，项目经理应该合理地把这个压力转换为对组员的激励，只有组员都深刻理解大目标分解成小目标传递来的压力，在团队的努力下项目目标才能达成阿。

再退一步讲，就算因为政府这种不可控的原因造成延迟，完全不是项目组本身的原因，那么延迟了多少天，对工期和完成期限的影响有多大，这样的原因分析也是项目出问题时候所必需的，起码对高层有个合理的，可以量化的交待吧。

不过这个打包任务应在备注中说明包含哪些工作内容或在任务名称中直接体现。

一般的项目管理中存在40 hour rule，只要打包后工期不超过1周，由1个人完成，没有特殊的前置关系，那就没什么不能合并的。

1.这三天指定的是工期，不是工时，我自己现在发现的project的工时指定和工期有很大的相关性。比如工期指定三天，工时只有一天，那么为了工时信息准确，我能想到的方法就是单位指定为33.3%，但是这表示的是三天中每天抽三分之一的时间来作这件事情，而实际情况是项目人员是在三天中的某一天来作这件事情，两者情况不一定一样，会不会在人员汇报进度的时候有问题出现。anyway我觉得还是把这些任务合并成为一个人物好了，细节问题就转移给平台外的人员掌握，既然他们觉得事先不能确定这些细节。
无可奉告可能是我的玩笑，但是我觉得人员的抵制情绪可能是的计划制定不能得到足够的信息，当然大家都有苦处。

2.项目经理因为这种承诺的问题所以对msp的推广持一种较为抵制的态度，确实如你所说msp成为了众矢之的，因为这在感觉上离他们最近而且不是老总。上层却没有提供有效的相应的推力，一般停止在口头上，现在有了一个总经理秘书的加入，可能情况会好很多了。

3.打包后，任务名称和备注应该尽量包含多个任务的信息，提高计划的可读性。另一个打包应该控制在一个你提出的限度内，我理解的是这样

4.另一问题就是我们的项目经理没有太多的项目管理的思想，前面请过讲师来讲课，也是没有什么效果，我自己也听过，本身的授课质量就不行， 按老总的意思说是在应用中学习，但是这个前提很成问题，所以在遇到困难以后，不顺利，抱怨的矛头很容易集中到msp及其推行人员的头上。