项目工作说明书(SOW)

OW是对项目所要提供的产品或服务的叙述性的描述。任务书/邀标书或合同一部分

SOW内容：

业务需求、产品范围描述（产品的需求以及产品或服务的特征）、战略计划

对内部项目：基于业务需要或产品（服务）的需求。

对外部项目：作为投标文档的一部分从客户那里得到。

需要说明：业务要求、产品范围描述、战略计划

SOW：Statement of Work工作说明书

SOW通常作为合同的一部分，对提供的产品或服务进行表述。SOW在很高层次上说明项目的用途、范围与途径。实际上，SOW是客户与供应商之间的高层共识，将帮助沿着正确的方向安排策划工作，是WBS的基础。

SOW通常包括：对项目技术的目标与宗旨的描述，必须满足的成本和进度方面的约束，实际存在的资源约束，以及客户与供应商在开始时应该理解的有关假定。

1、范围陈述（系统的目的与范围陈述）

2、约束陈述（包括开发和实施知识管理体系的成本预算、完成的时间、具体质量陈述等）

3、责任陈述（包括知识获取和工具选择的责任问题）

4、要求陈述（比如客户要求）

5、交付使用陈述（比如陈列、培训、文件）；签名（包括项目经理、项目发起人、客户）等

SOW的三个特征：

1、SOW是一份简短的文档。它既不是一份设计文档，也不是一份完整的法律合同。它应该是在高层商抓住要点。SOW的作用是奠定工作范围、开始定义最终产品。

2、保证客户与高层管理者能充分评审并批准SOW，然后才有可能切实地着手进行项目的其他活动。

3、一份SOW获得批准、便应对这份文档进行版本控制，并将它作为项目计划的一部分。

==============================================================================================================

工作说明书（SOW）——合同中对提供的产品或服务的表述，有时候被称为需求说明书。工作说明书应足够详细，以使期望中的卖方确定是否有能力提供各事项。SOW应该包括任何所需的间接服务，比如运行情况报告或者项目后续的运作支持等。

    工作说明书(SOW),是一个项目必须提供的工作圣经。SOW是一个关键的管理工具，不管是用来指导卖方或者承包商的工作，或者是用来指导他们的内部工作，SOW必须包括所有所期望工作的描述。这些描述不需要在一个很详细的级别，因为对一个大项目而言，在SOW中要把握住细节是很不切实际的，但是应该是全面的并且包含产生交付成果的工作还有比如项目报告这样的管理工作。

    SOW将会是项目合同的一个关键部分，如果工作是由卖方或者承包商来完成。这项工作是卖方合同中规定的你的义务的一部分。在SOW中包括工作仅仅需要完成哪些，在它上面已经相互认可的，或者通过项目变更请求了的工作。SOW对于内部团队也是很重要的，尽管这没有合法的解释，因为资源是仅仅被用在哪些在SOW中规划了的工作上。写这篇文章的目的是给那些项目管理的初学者一些小的提示和技巧来生成一个有效的SOW。

 

   (1)我需要一个SOW吗?

   SOW一个把握项目工作的一个很有用的组织工具。它的价值在于它获取你项目的所有关键工作要素，并且在两种情况下有用：是和潜在卖方或者顾问的合同的一部分，或者作为一个复杂的大项目中，被规划为内部活动中的一个中间步骤。如果你的项目很小或者对于你来说，它可以简单到能直接描述在你的工作分解结构工具中，你就不需要一个SOW了，比如，MS Project.

   SOW是非常有用的，当项目很大并且复杂的时候，因为它可以允许你故意一个某方面的专家来参与工作，并且他不需要访问MS Project.该工作描述，任何人都能通过书面沟通技能和一个技术的工作指令撰写出来。SOW也可以作为一个沟通工具，传达该项目的范围基准。

    (2)什么时候编写SOW呢？

    SOW应该是在你的范围说明书之后，在你项目的规划阶段编写。你的范围说明书应该被首先编写，并且应该是从一个大范围来把握项目的产品。比如说，你们公司正发起的一个基于系统的软件开发项目，以捕获和跟踪软件订单。你们的范围说明书可能包括该语言。它可能也包括一个用户列表，他们应该是支持这个项目的，比如订单输入员，配置这个订单的工程师。你也可以包括一些你希望在这个系统中有的特性，比如，是否是互联网或者是企业网来访问，它是存储了多少订单，每个订单应该存储什么信息，这个系统将如何收取订单付款等等。范围说明书将提供给你需要建立什么样的项目的信息。现在你知道了，你是正在做什么，你需要把握你将要做什么的细节。现在你需要编写你的SOW了。这个项目工作说明书定义了哪些工作需要完成，因此在你为工作制定计划或在你的WBS分解工作之前，或者你必须把他们写下来。

   (3)SOW里面都有什么

   从你范围说明书中的一些信息来开始编写你的SOW。所有在你的范围说明书中捕获的因素应该出现在你的SOW中。项目范围说明书往往从更高的层面捕获你的项目可交付成果；你的SOW应该包含这些可交付成果，什么时间他们应该被交付，这些可交付成果怎么被建立。SOW也应该包括可交付信息更详细的信息。比如，如果你的范围说明书包括订单获取和管理系统，那么你可以分解这些可交付成果到一个数据库里面，以获取，存储和跟踪这些信息，前置端与用户的接口和一个报告系统以管理报告。维基百科提供给我们一个标准的SOW信息分类列表：

• 工作范围：工作的详细描述，用到的软件和硬件，准确的工作属性。
• 工作场所：在工作场场所完成的工作要比在其他地方好，这可能比较适合在海外执行项目工作的SOW。
• 执行期限：项目的开始和结束日期，每一时段的最高收费，等等。
• 交付进度：对于项目的交付时间，它可能包括开发的全部时间，质量测试，用户认可测试，等等。
• 合适的标准：行业标准和其他的标准都影响着项目的交付成果。可能包含任何标准如：ISO,CMM,CMI,等等。
• 认可度：这里可能包括你必须符合的任何质量标准，比如：0优先1缺陷。他们也可能包括一些其他必须满足的条件，比如一定数量的测试案例，一定数量的执行案例，等等。
• 特殊需求：这将包括任何特殊资质的员工，比如一个PMP认证项目经理。

     工作范围，执行周期，和交付计划是一些必要的信息。其他都是可选的，并且只适用于哪些合适的项目。比如，标注哪些在执行组织办公室内已经被执行的工作为无效，标注该工作空间，而且是谁负责提供，这将关系到咨询公司能否完成项目工作说明书相关的全部工作。

    被执行的工作范围应该包括哪些与项目交付成果相关的行政工作。行政工作也包括项目管理工作。如果你将要为一个内部客户工作，你可能不想包含这些项目管理工作。另一方面，包括它将有助于设定客户/项目发起人的期望。包括一些报告和你想用来保持项目干系人了解本项目进展的一些沟通工作，你也应该包括哪些来自于团队内部的任何消息，比如进度报告。包括行政工作比如记录项目时间到一个时间跟踪工具中，如果使用这个工具对于团队不具有可操作性。不要尝试获取太多关于交付成果的信息或者怎么完成这项工作的信息。记住，当你输入信息到项目说明书中时，你需要设定期望值。它将是很困难的，想要改变任何你已经在项目说明书中描述的信息（你的需求变更需要得到项目发起人或者客户的同意）。你不应当试着描述一些关于项目可交付成果的细节，当这个项目使用了一个迭代的SDLC。描述哪些会用到的方法和哪些主要的可交付成果。使用瀑布方法将使你描述更多的细节关于做这个工作和这些项目的可交付成果。

   (4)接下来的步骤

    你的下一个步骤将是让你的项目发起人或者项目的客户，批准这个项目说明书。那现在这个项目说明书就成了该项目正式的范围界限。里面描述的任何细节必须在最终产品中出现。

    你的项目说明书描述了项目团队将要做的工作，但是对于更多细节，你需要更进一步分解这些条目，以便完成你的工作分解结构(WBS).你可能发现在你的SOW中的每个条目的唯一性将帮助确定，在SOW中所提到的所有的可交付成果都将在你的WBS中有体现。你也应该去核对SOW和范围说明书以确保在范围书中的条目在SOW中都有体现。

    在你SOW中开始和结束日期，应该也在你的WBS中明确记录。如果你是正在用MS Project或者类似的工具软件以支持你的WBS分解工作，这个开始日期将是在这个工具中的第一个输入项，你将使用这个结束日期作为限制条件。一旦你描述完成所有WBS中的信息，工作分解和任务的计划，你需要去SOW中检查实际完成时间和计划完成时间的对比。同样的方式，你需要使用你的SOW中的计划日期和实际的交付成果作对应检查。

    你也可以用你的SOW作为一个交流工具，给项目相关人员说明项目工作。你也可以把这个和其他项目文档发布到一个公共可读网站上供大家阅读。记得当一个工作被批准后更新到SOW。

 

    仔细描述出你项目工作的正确信息。尽量使信息尽可能准确，有效的信息可以使你项目剩下的工作计划缩短时间和减少路径。记住它是一个“实际的”文档，在SOW中任何内容变更都应该反映到该文档中。