如何写工作说明书（sow）

      工作说明书，也就是SOW，是项目必须创建的工作圣经。无论是直接指导供应商或者承包商的工作还是指导内部工作，SOW都是关键的管理工具。SOW 必须包含所有预期工作的描述。这个描述不需要非常详细，得确对于大型项目在SOW中捕捉细节是不现实的，但是描述应该广泛，并且也应该包含产生项目交付物的工作以及行政管理工作比如项目报告。

 

      如果工作是由供应商或者承包商完成，SOW将成为合同的关键部分。在这份文档中包含的工作是供应商或者承包商必须承担的合同义务。没有包含在SOW中或者由于需求变更引入的工作只有相互同意才做，不是合同义务。虽然没有法律相关的约定，SOW对内部团队也是重要的，因为要依据SOW中定义的工作来配置资源。这篇文章将帮助实习的项目管理员写出高效的SOW。

我需要写SOW吗？    

      SOW是一种捕捉项目工作的实用组织工具。它的价值在于有能力捕捉项目中所有关键工作要素以及应用于下面两种情形：作为与外部供应商或者承包商签订合同的一部分，或者对于大型复杂的内部项目，作为中间计划步骤。当项目足够小且简单，以至于你能直接把范围说明转换到工作分解结构工具中（比如MS Project），此时不需要SOW。

 

      当项目大且复杂的时候，SOW非常有帮助，因为它允许你雇佣不能访问MS Project的专门领域的专家。任何有写作沟通和工作技巧的人都可以描述将要做的工作。SOW也用作沟通工具，描述项目的范围。

什么时候写SOW?     

       应该在项目计划阶段期间、范围说明之后写SOW。范围说明应该首先写并且应该非常概括地捕获项目产品。假如你的组织正在启动一个项目开发一个基于软件的系统，该系统用来捕获和跟踪软件定购。范围说明应该包括语言。可能也包括支持的用户列表比如订单输入文员、配置订单的软件工程师、产生报表的管理人员和运送订单的运送员。可能也包括在系统中出现的功能，比如它是否内网或者外网可访问，它应该存储多少订单，每个订单应该存储什么信息，系统应该怎样收款等等。范围说明将提供关于什么是你需要建立的信息。

 

     既然你知道什么是你需要建立，你需要捕获你怎样去建立它的细节。现在你需要写作SOW。工作说明书定义将要做的工作，因此它必须在工作被计划或者工作被分解之前写。

 

SOW包含些什么？

      从范围说明开始SOW。在范围说明中捕捉的所有要素都应该出现在SOW中。范围说明倾向于在一个高的层次捕捉项目的可交付物；SOW将包含这些可交付物，什么时候交付，以及可交付物如何构建。SOW也应该包含关于可交付物的更详细一点描述。比如，如果范围说明包含一个顺序保存和管理的系统，你可能把可交付物分解成：用于保存跟踪信息的数据库，和用户交互的前台以及管理报告的报表系统。

 

SOW信息分类的标准检查列表：

• 工作范围 - 工作的详细描述，将被使用的软件、硬件，以及工作的准确的特性
• 工作地点 - 如果完成工作的地点不同于标准地点，有可能是离岸。
• 履约期 - 项目的开始和结束日期，每个时期的最大工作时间等等
• 可交付计划 - 项目可交付物的到期日。这包含开发、QA测试、用户接收测试等等的完工日期。
• 适用标准 - 应用于项目可交付物的工业标准或其他标准。它可能是任何一种标准，比如ISO,CMM,CMMI等等。
• 接收条件 - 这些应该包含任何必须满足的质量标准，比如，0个优先级为1的bug。它们也应该包含其他必需满足的条件，诸如测试用例数量、测试用例执行数量等等。
• 特别说明的需求 - 这些将包含任何关于劳动力的资格限定,比如PMP认证的项目经理

      工作范围，履约期以及可交付计划是强制信息。其它是可选的并且只适用于那些需要它们的项目。比如，工作将在执行机构执行，那么涉及办公空间就没有意义；顾问公司参与工作的SOW将涉及到工作室以及谁负责提供它。

 

     将执行的工作的范围应该包括行政管理工作和针对项目可交付物的工作。行政管理工作也包括项目管理工作。如果你为内部客户工作，可以不包括项目管理工作。另一方面，包括项目管理工作有助于设置客户/发起人期望。包括报告和其他用来向资助人回报项目进度的交流工具。也应该包括任何来自于团队、被需要的信息，比如进度报告。行政管理工作比如把项目时间输入到时间跟踪工具中。

 

      不要试图捕获太多关于交付物或者工作怎么做的信息。记住当把信息放入SOW中，要设定一个期望效果。改变已经在SOW中的任何事都是困难的（你需要一个被发起人或者客户批准的更改申请）。不应该试图捕获关于项目交付物的细节。描述将要使用的方法和主要的交付物就足够了。用瀑布法允许你捕获关于做工作和项目交付物的更多细节。

下一步

     下一步就是让项目发起人或者项目客户批准SOW。SOW就变成正式的项目范围基准。在SOW中的任何事情必须出现在最终的项目中。

SOW捕捉项目团队将要做的工作，但是在一个高的细节层次上。为了完成工作分解结构（WBS），你需要进一步分解这些工作。你可能会发现对在SOW中每个工作的唯一识别将有助于确保在SOW中描述的所有的可交付物和工作包都出现在WBS中。你也应该基于范围说明检查SOW确保在范围说明中的所有工作都出现在SOW。

 

     在SOW中捕获的开始和结束日期都应该在WBS中被捕获。如果你用MS Project或者类似的工具创建WBS，开始日期就是第一个入口。结束日期用作约束条件。一旦完成捕获WBS中的所有信息、工作分解和任务计划，你需要基于SOW中的结束日期检查产生的结束日期。同样方法，把来自SOW的计划日期用于主要的可交付物。

     你应该把SOW作为沟通工具，通过在一个公开的可访问的站点发布SOW和其他项目文档向项目资助人解释项目工作。当更改项目工作的改变被批准后，记得更新SOW。

 

     小心捕捉关于项目工作的正确信息，尽力确保信息是准确的，并且在其他计划活动中好好使用这些信息可以节省计划时间。记住：SOW是一个“活的”文档，改变出现在SOW中任何元素都应该在其中反映出来。