会员登录
会员注册
为解决这个和问题，国际上已于上世纪80年代末期开始采用“工作陈述”(Statements of Work或简称SOW)来固定范围，同时放弃范围定义(Scope Definition)的应用。因为IT项目有别于其他基建项目的地方在于基建项目有其他附属文档来支持范围定义，比如在基建项目的项目范围中，一般都有诸如项目的有关设计图则、用料标准等等明文规定，让范围能够非常明确地涵盖基本的工作需求。而IT项目的项目范围中往往没有这样的定义。
在上一节“如何建立项目范围”的讲座中，我们谈到以商业效益来确认功能需求，再利用功能需求来建立项目范围。而在范围确认后，我们紧跟着必需建立详细的工作需求和项目计划，否则项目的工作便像橄榄球内的充气量一般，可以按照客户的要求随意变动。
工作需求和项目计划基本上是利用工作架构分解法(Work Breakdown Structure)建立。明确的工作陈述(SOW)让渠道商或服务商了解本身的服务承诺，有效地建立项目的成本，降低项目过程中所产生的变动。这些工作陈述应该在销售过程中建立，成为服务合约的内容一部分。万一合约中只有项目范围定义，那么交付小组必须在交付初期建立有关的项目工作陈述，避免交付期间所产生的争议。
利用WBS技巧建立工作需求
IT业内人士多未能把握WBS的实际应用技巧。而有如工作量估算，错误的工作细节将对项目计划不利。利用“图二”加以简单说明：每一个项目都有不同的交付物，而每一件交付物需要经过不同的里程碑才能够产生，同时每一个里程碑也需要经过不同的阶段才能够达到里程的目标。每一个阶段需要经过不同的步骤去完成，而每一个步骤需要进行不同的工作。
每一个步骤需要完成一系列工作才能进行第二步骤，直至同一阶段的步骤完成才开始第二阶段，而直至全部阶段完成后才能到达一个里程碑。有些里程碑内的工作可以同期进行，但有些里程碑内的工作得等另一个里程碑完成后才能够开始。到最终完成全部的里程碑内的工作后才能够交付项目中的某一件交付物。
利用WBS技巧来建立交付组合架构，为每一件交付物建立本身的工作需求，可以让我们很明确地说明每一件交付物所包含的工作。这个交付组合架构更可以让我们在同一时间为项目建立有关的工作计划。