，向成员提供与项目相关的所有详细资料，并把WBS树分解到二层三层。然后要花上一段时间让成员 进行头脑风暴式（BRAINING STORM）思考，制订工作产出和相应人员的职责，记录每一个工作包的完成标准。
比如我们要结婚了，怎么来分解呢
无非是办酒席，拍结婚照，，等等，这个在论坛上曾有人做了详细的分解，大家都可以找到。
我们说为什么WBS重要，而且大部分项目管理的咨询都是针对WBS的咨询
因为WBS做好了，以后工作就有了参考物，你就知道在不同的阶段你应该干什么，完成到什么进度。
其实WBS的划分是没有规则的，主要的考虑角度是方便你做各类的统计工作，为管理服务。
同样的一个项目其管理的侧重点不同，WBS结构的划分也可能是完全不同的。
衡量划分好坏的标准应该是看其是否满足你管理的需要。
甘特图也叫横道图等，很多名称，我们说它是甘特在第一次世界大战时开始使用，它就是在WBS的基础上将WBS形象化老控制进度
对于基准，我象举个例子。
我们在没有结婚之前，你脚踩几只船？
我们说法律允许但道德不允许，但你可以脚踩N只船：）
但当有一天你和你的朋友进了一个小黑屋子，然后带了两个盖章的本本的时候，你还可以脚踩N只船吗？
我们说此时就不允许了，因为你过了一个基准线（BASELINE）
如果你还想脚踩N只船就需要重新回小黑屋子再盖两个章就可以了。
那我们的项目要越轨怎么办，也就是项目变更？
我们说对这样的项目变更会影响各要素比如时间，成本，质量等
我们应该统一由项目管理办公室来进行控制，如果你要变更基准，必须要进行严格的限制。
在客户提出变更请求时，要建立变更申请登记表和变更申请表，并让客户签字。
有时候一些不是非常关键的模块PM也不至于一点不讲情面，该卖面子的时候还是要卖，尤其是当着对方领导的面，千万要 卖面子，但是也别卖的太干脆，不要让他们得到的太容易。
PM在变更管理中需要做的是分析变更请求，评估变更可能带来的风险和修改基准文件。
如果一个项目进行过程中，比如现在的点心的3G项目，你发现如果再多花一点时间就可以编写出对以后非常有用处的程序，但这个程序不在本项目范围之内，你要不要做？
对，我们说不能做，你可以重新起一个项目来做，但不能在这个项目里做，这样会是我们的项目成本超出，风险增加，而且和其他的项目缺少比对性和参照的价值。
这也是我们说现在有大约80%以上的项目失败的原因，我们说项目失败并不是项目进行不下去了，彻底破产，在PMI有明确的定义，凡是项目的成本超出预算，质量没有得到保证，时间超过预计等等都在失败的范围之内。
这个在华为做的很好，华为有个有名的增量开发的名声。
只用20%的功能先满足你80%的需求，其他的功能我可以开发升级的版本，于是就在小数点后平明的增加数字，于是就是了V1，V1.1，V1.11....等版本
它从来不一下子满足你所有的需求，我们大家想想，谁没有事情拿出自己的手机把所有的PING码都试用一下，我们说没有，我们大部分的需求是在打电话，发消息，打打游戏，对不对？
这点在项目管理中非常重要，请大家结合资料好好研究。
项目干系人是什么东东，谁给我举一个例子？
对，包括项目人员的老婆孩子，正确
我们说有的项目需要的时间很紧张，如果你的项目成功了，但项目的程序员们都成了光棍，那项目还是非常失败，至少不是丧心病狂的PM这么想。
合理解决项目干系人的冲突是个很累的问题，其中还包括你的只能经理们，你的董事长，你的客户，等等，等等，有的说没用？
好，如果你的项目进展不下去，你该怎么办？&nbs