工作说明书（SOW）是必须为项目创建的工作圣经。 无论是指导供应商工作还是指导内部工作，SOW 都是一个关键的管理工具。
SOW 必须包含所有预期工作的描述。 该描述不需要非常详细，因为在大型项目的 SOW 中捕获详细信息是不切实际的，但描述应该广泛，还应该包括产生项目可交付成果的工作以及项目等管理工作报告。
SOW的三大特点：
1. SOW是一个简短的文件。 它既不是设计文件，也不是完整的法律合同。 它应该是在高层次上传达观点。 SOW 的作用是确定工作范围并开始定义最终产品。
2. 确保客户和高级管理层能够在实际开始项目的其他活动之前充分审查和批准 SOW。
3. SOW 获得批准后，应对该文档进行版本控制并将其用作项目计划的一部分。
01
我需要写 SOW 吗？
SOW 是管理项目工作的有用组织工具。
它的价值在于它捕获了项目的所有关键工作要素，并且在两种情况下很有用：作为与潜在卖方或顾问签订的合同的一部分，或者作为计划作为内部项目的更大、复杂项目的一部分。活动 中间步骤。
如果您的项目很小或足够简单，可以直接在工作分解结构工具（例如 MS Project）中进行描述，则不需要 SOW。
当项目庞大且复杂时，SOW 非常有用，因为它允许您聘请专家来完成该工作，而无需访问工作描述； 任何人都可以以书面形式交流技能，并编写技术工作说明。 SOW 还可以作为传达项目范围基线的沟通工具。
02
什么时候写SOW？
SOW 应在项目规划阶段的范围说明书之后编写。
应首先编写您的范围说明书，并应涵盖项目产品的广泛范围。 例如，您的公司正在启动一个基于系统的软件开发项目来捕获和跟踪软件订单。 您的范围说明书可能包括这种语言。 它还可能包括应该支持该项目的用户列表，例如订单输入职员、配置该订单的工程师。 您还可以在该系统中添加一些您希望拥有的功能，例如是否从互联网或公司网络访问、它存储了多少订单、每个订单应存储哪些信息、该系统将如何收取订单付款等等等等。
范围说明书将为您提供有关您需要构建哪种项目的信息。 既然您知道自己在做什么，那么您需要掌握要做什么的细节。 现在您需要编写 SOW。 该项目工作说明书定义了需要完成哪些工作，因此在您可以计划工作或在 WBS 中分解工作之前，您必须将其写下来。
03
SOW 包括什么？
使用范围说明书中的一些信息开始编写 SOW。 范围说明书中捕获的所有因素都应出现在 SOW 中。
项目范围说明书通常从更高的层面捕获您的项目可交付成果； 您的 SOW 应包含这些可交付成果、应何时交付以及如何建立这些可交付成果。
SOW 还应包含有关可交付成果的更多详细信息。 例如，如果您的范围说明书包括订单获取和管理系统，那么您可以将这些可交付成果分解为用于捕获、存储和跟踪信息的数据库、用户的前端界面以及用于管理报告的报告系统。
SOW通常包括：
描述项目的技术目标、必须满足的成本和进度限制、实际存在的资源限制以及客户和供应商一开始就应了解的相关假设。
1.范围声明（系统的目的和范围的声明）；
2、约束说明（包括开发和实施知识管理系统的成本预算、完成时间、具体质量说明等）；
3、责任声明（包括知识获取和工具选择的责任问题）；
4、需求说明（如客户要求）；
5、交付声明（如展示、培训、文件）； 签字（包括项目经理、项目发起人、客户）等；
SOW 信息分类的标准清单：
工作范围、执行期限和交付计划是一些必要的信息。 其他是可选的，仅适用于少数合适的项目。 例如，将执行组织办公室中已完成的工作标记为无效、标记工作空间以及由谁负责提供这些工作都会影响咨询公司是否能够完成与项目工作说明书相关的所有工作。
要执行的工作范围应包括与项目可交付成果相关的管理任务。 行政工作还包括项目管理工作。 如果您要为内部客户工作，您可能不想包含这些项目管理任务。
另一方面，包括它将有助于设定客户/项目发起人的期望。 包括您想要用来让利益相关者了解项目进展的任何报告和通信。 您还应该包含来自团队内部的任何消息，例如进度报告。 如果团队无法使用该工具，则包括管理任务，例如将项目时间记录到时间跟踪工具中。 不要试图获取太多有关可交付成果或如何完成工作的信息。
请记住，当您将信息输入项目规范时，您需要设定期望。 更改您在项目规范中描述的任何信息都将很困难（您的需求更改需要得到项目发起人或客户的批准）。 当项目使用迭代 SDLC 时，您不应该尝试描述有关项目可交付成果的一些细节。 描述将使用的方法和关键交付成果。 使用瀑布方法将允许您描述有关这些项目的工作和可交付成果的更多细节。
04
SOW完成后，你应该做什么？
您的下一步将是让您的项目发起人或项目客户批准项目规范。 项目描述现在成为项目的正式范围边界。 里面描述的任何细节都必须出现在最终产品中。
您的项目描述描述了项目团队将要做的工作，但为了获得更多详细信息，您需要进一步分解这些项目，以完成您的工作分解结构 (WBS)。 您可能会发现 SOW 唯一性中的每一项都将有助于确保 SOW 中提到的所有可交付成果都将反映在您的 WBS 中。 您还应该检查 SOW 和范围声明，以确保范围声明中的项目反映在 SOW 中。
SOW 中的开始和结束日期也应明确记录在 WBS 中。 如果您使用 MS Project 或类似工具来支持 WBS 分解工作，则此开始日期将是该工具中的第一个条目，并且您将使用此结束日期作为约束。 一旦您在 WBS 中描述了完成所有信息、工作分解和任务的计划，您需要转到 SOW 并检查实际完成时间与计划完成时间的比较。 同样，您需要根据实际可交付成果检查 SOW 中的计划日期。
您还可以使用 SOW 作为沟通工具，向项目利益相关者解释项目工作。 您还可以将此文档和其他项目文档发布到公开可读的网站，以供所有人阅读。 请记住在工作获得批准后更新 SOW。
仔细描述有关您的项目工作的正确信息。 尝试使信息尽可能准确。 有效的信息可以缩短您项目剩余工作计划的时间并减少路径。
请记住：SOW 是一个“动态”文档，对 SOW 中任何元素的更改都应反映在其中。
评论列表