下面是网上流传甚广的一个软件项目的WBS。我相信很多人都使用过自己创建过类似的WBS。

正是由于我们的先辈，先辈的先辈用类似的方法来创建WBS，耳濡目染之下，我们也养成了同样的习惯。

这是一个典型的有问题的WBS。

首先从客户的角度来说，从第一层分解要素来看我们无法看到我们到底要交付给客户什么？你告诉客户，我要交付给你一个系统设计，客户还不得跳楼。因为客户要的是OA系统、财务系统、邮件系统，机房、设备、系统软件。

从实施的角度来看，我们大有可能购买现成的邮件系统，或者将邮件系统外包给一家公司，先在我们简单看看，如果我们外包邮件系统，这个WBS是不是就很不方便了。

第三个，我们是可交付成果导向，请问项目启动会交付什么呢？

这个典型，或者与此类似的WBS还得我们好惨，也导致我们只能管理比较小的项目，对于大项目就束手无策，因为WBS一开始就有错，后面岂不越管越乱。我来对这个WBS做个调整，看是不是好一点。

这不是一个完美的WBS，因为我所获得信息只有上面那个WBS那么多，但这是一个非常好的开始，有利于项目管理团队不断的去讨论，包括与客户讨论，从而不断调整。

从该WBS我们能够很清楚的看到，我们需要交付的产品与服务。

我这里假设财务系统将采购，邮件系统将采购后进行二次开发，OA系统全部二次开发。其中有些环节我已经分到了活动级别，有的还在WBS的工作包级别。如果我们的项目以此为基础进行，那么我们就可以进行后续的进度、职责分配等工作。