面是SOW有下面四种常见形式：
功能：客户通常知道他们想要什么，但不知道怎么达到他们想要的目标。功能SOW确定客户在最后交付产品时想要什么。
性能：这是SOW最常见的形式。它详细说明协约的所有交付的产品，确定流程、范围和可接受的努力等级。这集中在整个协约。
设计：在设计SOW中，客户已经很详细地描述服务或交付产品怎样获得、建立、实现等等，主要集中在流程和设计上。
增加：一个企业组织一般需要资源支持开发。这样就需要完成一个人员增加SOW，用以详细说明由承包人完成的工作范围、客户对承包人技能、资格认证和工作质量的期望。
典型的SOW包含以下的内容：
封面：包含项目标题、合同信息、修订号和作者
目录：在大型SOW中证明非常有用
简介：包含项目的总览和背景
定义或者术语表：定义关键词或者不明确的术语
项目范围：确定项目范围以及与其它项目的关系
目标和目的：说明根据SOW你想得到什么
参考文献：包含一个附属的或者所参考的文档的一个概要
工作描述：详细说明工作范围，要完成的工作等等。细分来看通常包括：需求、技术规范说明、质量标准、方法、开发标准、交付产品、性能测量、报告需求、安全性、例子、插图、数据处理约束等等
工作地点：描述在什么地方完成工作，还有怎么到达工作地点、讨论室、开会地点、电话、桌子、PC、软件等等
安全：列出对要工作的资源的安全限制
出差或者住房：详细说明出差和食宿预算限制
交付产品：列出期望的产品或者切实的结果
计划或者产品进度表：有关项目计划更加详细的特性，包括WBS、资源、时限、交付进度和里程碑。
风险：陈述风险和公差补贴
改变管理流程：根据要求做什么改变、已经处理了什么改变和批准通过了什么改变来描述流程
项目管理：涉及项目领导、授权、进程汇报指南、角色和责任
客户责任：记录客户允诺承担的责任范围
供应商/承包人责任：记录供应商/承包人允诺承担的责任范围
成本估计：详细列举期望的成本估计
补偿和支付日程：详细说明供应商/承包人将怎样拿到付款（比如说谈妥的价格、时间和材料和调整处理）
接受标准和正式批准：确实他们将怎样被判断与/或认可工作。
文档：包括用户指南、技术指南等等
需求可追溯矩阵：追溯从请求到交付之间的需求
其它：明确的项目类型可能需要更多其它因素来清楚地定义要做的工作
另外一个导致混乱的地方是用于创建文档的语言。在编写SOW的时候要清楚简练。避免使用行话、缩写词、无关的话以及无关的参考文献。要确保包含足够详细的信息能清楚地确定工作，但不要超过SOW的负荷。最后，在正式提交前记得校对你的SOW。
Scott Withrow已经有20多年的IT工作经验，其中包括IT管理、Web开发管理和内部顾问应用分析。
近年工程管理专业前景如何?
工程管理尤其是建筑施工项目管理，作为就业方向，是一个要有勇气的选择。作为项目管理的范畴，这个方向前景无限。只是，必须经过时间的磨练。应该说，将来优秀的建筑工程管理人员，将大多数是从施工一线出来、而且经过各类专业技术工作的磨练（从内业到外业）的人员。没有技术方面的专长、对建筑技术的全面了解，不可能做好项目管理。而众多的技术专才并非都能成为真正意义的项目管理人员。
目前的注册项目经理应该算工程项目管理的代表人物。但我国目前真正意义的项目经理不多，很多挂名的项目经理是公司的领导或部门的领导，或者是仅持有证书、并不真正参与项目的技术人员。对项目的管理太趋于宏观、甚至徒有虚名。根本问题是工程承发包管理体制的不成熟。我们目前无法回避在承接工程业务上很多是私人（或个人）唱主角的问题，相应的工程承包公司变成了私人（或个人）的依附，因此公司在项目管理上往往要被承接业务的个人的意愿所左右，造成目前项目经理普遍责、权、利无法统一。暂且抛开“利”不谈，试问没有相应的“权力”，如何实现“责任”！？这是目前工程项目管理的最关键问题所在！不是技术、不是管理能力、也不是管理制度的问题，而是外部体制的问题！
当然，我们不必因噎废食。相信我们的政府、市场能解决好此问题。即使在西方发达国家，也不能回避私人承接业务上的作用，关键在于其市场制度明确各方面的责权利。行业、市场制度完善，促使项目管理按照规范程序来走，而背后的利益通过市场成文、不成文的规定得到很好的划分，使得项目管理走上专业化轨道、远离个人意志对管理工作本身的影响。
作为我们有志从事此行业的人，必须要做的事是打好基础，经过各项具体工作的艰苦磨练从技术工作开始。然后将进行更有挑战性的管理技能的磨练。（施工技术无法涵盖人员、造价、市场、合同等诸多方面）。管理技能无法从一般大专院校或是什么X BA、XMP之类研修课程直接学到（那些课程是实践的总结和升华，没有实践基础不要参与），只有从实实在在的项目一步步着手。
建筑工程管理包罗万象，可学到的东西跨越建筑本身、外延无限，其所需技能可实施于诸多领域。因此这个就业方向前景无限。