“计划赶不上变化!”一个项目经理感叹道。
的确，项目中有相当多的不确定因素，项目经理辛辛苦苦做的WBS（工作分解结构），可能因为客户的改变，甚至领导的一句话，就分崩离析了。
一些公司高层没有经过仔细考虑，也没有充分征求各个方面的意见，在制定总体计划时比较随意，修改起来更是“信手拈来”。项目经理也常常借口工作忙等理由，拖延制定详细的WBS，甚至有项目经理认为，不应该制定详细的WBS。
而没有详细WBS的危害也是明显的：造成计划与控制管理脱节，无法进行有效的进度控制管理，最终导致项目延期或成本上升。可以说，没有WBS或者是随意的不负责任的WBS的项目是一种无法控制的项目。面对各种潜在的变化，项目经理应该怎样制定WBS呢？
首先项目经理应该对WBS有正确的认识，制定WBS就是一个对项目逐渐了解掌握的过程，通过这个过程，项目经理可以知道哪些要素是明确的，哪些是要逐渐明确的，通过渐近明细不断完善。渐近明细也是项目的一个特点，因此WBS的制定需要在一定条件的限制和假设之下采用渐近明细的方式进行不断完善。
再者，制定WBS需要有一个现实的方法。一个大型的软件开发项目，通常是采用二次WBS方法。即根据总体WBS，在需求调研阶段结束、概要设计完成后，再专门针对详细设计或编码阶段制定二次WBS 。
一个方面，需求的颗粒度在一开始往往是比较粗的，因此根据功能点对于整体项目规模的估计误差范围也是比较大的，只能据此制定总体的WBS。
另一个方面，需求和编码工作分解不是一一对应的，一个需求的功能点可能对应多个代码模块，而多个需求的功能点也可能只对应一个或少数代码模块。只有在概要设计完成以后才能准确地得到详细设计或编码阶段的二次WBS。
例如，某系统集成公司与银行签订了一个银行前置机的软件系统的项目。合同规定，6月28日之前系统必须投入试运行。项目经理小丁组织大家制定了项目的WBS，并制订了本项目的进度计划，简单描述如下：
1．应用子系统：1月5日～2月5日需求分析，2月6日～3月26日系统设计和软件设计，3月27日～5月10日编码，5月11日～5月30日系统内部测试；
2．综合布线：2月20日～4月20日完成调研和布线；
3．网络子系统：4月21日～5月21日设备安装、联调；
4．系统内部调试、验收：6月1日～6月20日试运行，6月28日系统验收。
2月17日，小丁发现系统设计刚刚开始，由此推测3月26日很可能完不成系统设计。小丁应该如何做，以保证项目整体进度不拖延呢？
小丁编制的这个WBS比较粗糙，不适合作为编织项目计划的基石。只有一个项目的大概框架和子系统各部分的期望完成时间。从该WBS上面可以看出最底层任务的工期至少也在半个月左右。如果任何一个任务出现了问题，就必然会出现小丁现在遇到的问题，即延期和延期发生了较长时间才知道。
在这种情况下，小丁最好是制定二次WBS。最终分解任务的工期最好不要长于一周，否则可能出现失去控制的情况。而且，在不同阶段应该有具体直接的责任人。作为项目经理，小丁需要保持与某阶段的直接责任人沟通，了解进度、发现问题。