# Project Scope Management
“…includes the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully. Managing the project scope is primarily concerned with defining and controlling what is and what is not included in the project.”
“…… 包括为确保项目成功完成，项目所需的所有工作，并且仅包括所需的工作所需的过程。管理项目范围主要涉及定义和控制项目中包含的内容和不包含的内容。”
- Scope
- (p. 722)
“The sum of the products, services, and results to be provided as a project”
“将作为项目提供的产品、服务和结果的总和” - Project Scope
- (p. 717)
“The work performed to deliver a product, service, or result with the specified features and functions”
“为交付具有指定功能的产品，服务或结果而进行的工作” - Product Scope
- (p. 715)
“The features and functions that characterize a product, service, or result.”
“表征产品、服务或结果的特征和功能。” - Baseline (d) (deliverable) 基准（可交付的）
- (p. 699)
“The approved version of a work product that can be changed only through formal change control procedures and is used as a basis for comparison to actual results.”
“工作产品的批准版本只能通过正式的变更控制程序进行更改，并且可以用作与实际结果进行比较的基础。”
# Predictive Project Management 预测性项目管理
- Big up front design (BDUF) 大前期设计
- High level of attention given to controlling if and how the original design is changed (or not)
高度重视控制是否更改原始设计以及如何更改原始设计 - Very similar, if not synonyms with “waterfall.”
非常相似，即使不是 “瀑布” 的同义词。 - ”Predictive” appears to be PMI’s new word for waterfall
“预测性” 似乎是 PMI 瀑布的新词 - This is the opposite of iterative development (e.g. Scrum)
这与迭代开发（例如 Scrum）相反
# How to baseline your project
# What does it mean to “Baseline?”
# What is change control?
# Brian’s definition of scope
- A correct scope statement will identify what the project team is chartered to work on, and what it will not work on.
正确的范围声明将确定要授权项目团队进行哪些工作，以及哪些项目将不进行工作。 - Scope, in a predictive/waterfall environment can only be changed via a formal change process, where all voting stakeholders must agree to a requested change.
在预测 / 瀑布环境中，范围只能通过正式的更改过程来更改，在该过程中，所有有表决权的利益相关方都必须同意所请求的更改。 - Scope, in a Scrum environment, has less meaning:
在 Scrum 环境中，作用域的意义较小：- It is basically what user stories the Product Owner has created for the team, and the team is willing, with the support of leadership, to work on.
基本上，这是产品负责人为团队创建的用户故事，并且团队愿意在领导的支持下继续努力。 - Expect that low value User Stories and Bug Fixes will likely fall out of Scope due to other high priority work drawing resources away from them. When this happens, the Product Owner needs to be kept aware.
期望低价值的用户故事和错误修复可能会由于其他高优先级工作而从资源中撤出，从而可能不在范围之内。发生这种情况时，需要使产品负责人保持警觉。
- It is basically what user stories the Product Owner has created for the team, and the team is willing, with the support of leadership, to work on.
# Requirements
# PMBOK Requirements Definitions…
- Requirement
- A condition or capability that is necessary to be present in a product, service, or result to satisfy a business need (p. 719)
产品、服务或结果中必须存在的满足业务需求的条件或能力 - Requirements documentation
- a description of how individual requirements meet the business need for a project (p. 719)
关于个人需求如何满足项目业务需求的描述 - Collect Requirements
- is defined as “the process of determining, documenting, and managing stakeholder needs and requirements to meet project objectives.” (p. 701)
定义为 “确定、记录和管理利益相关者的需求和要求，以实现项目目标的过程”。
# Requirements document defined (bv)
- A written explanation of the condition or capability that is requested of the performing organization. The request can be for a product, service, or result that addresses a business need.
对执行组织要求的条件或能力的书面说明。该请求可以是针对满足业务需求的产品，服务或结果。 - Based on the SOW, project charter, and/or the business case.
基于 SOW，项目章程和 / 或业务案例。 - These tend to be formally approved by a unanimous vote of carefully selected stakeholders.
这些往往倾向于经过精心选择的利益相关者的一致投票而正式批准。 - When changed, a change control process must be used.
更改后，必须使用更改控制过程。 - All items are to have an entry on a requirements traceability matrix (RTM)
所有项目都应在需求可追溯性矩阵上有一个条目 - These are written by business analysists (“BA”s). BAs and they use “requirements elicitation” to gather up the details necessary to better understand, and explain (on the requirements document) the business need.
这些是由业务分析（“BA” s）编写的。 BAs 和他们使用 “需求启发” 来收集必要的详细信息，以更好地理解和解释（在需求文档上）业务需求。
# Scope
# Scope: Predictive vs. Scrum
p. 131
“In a predictive life cycle, project deliverables are (specifically) identified at the beginning of the project, and any changes to the scope are progressively managed.”
“在可预测的生命周期中，（具体地）在项目开始时就确定了项目可交付成果，并且对范围的任何更改都将得到逐步管理。”
Change from original scope is not appreciated as a scope change requires all documentation relevant to the change to be updated, action needs to be taken to understand the proposed change, and it is very difficult to get stakeholders to look at and approve scope changes
对原始范围的更改不被赞赏，因为范围更改要求与更改相关的所有文档都需要更新，需要采取措施来理解建议的更改，并且很难让利益相关者查看和批准范围变化
# Scope: Predictive vs. Agile - Scrum
p. 131
In an agile (scrum) environment:
在敏捷（scrum）环境中：
- At the start of each iteration, the product owner will identify what work they want to be done, in User Story (US) format. These are placed onto something called the “Product Backlog”
在每次迭代的开始，产品所有者将以用户素材（US）格式标识他们想要完成的工作。这些被放置在称为 “产品待办事项列表” 的东西上。 - The Product Owner will prioritize the user stories in the Product Backlog (bugs are also on the backlog).
产品负责人将优先处理产品待办事项列表中的用户案例（错误也位于待办事项列表中）。 - The scrum team will work with the Product Owner to “refine” the USs
Scrum 团队将与产品负责人一起 “完善” 美国市场 - Scrum team commits to User Stories for the current iteration.
Scrum 团队致力于当前迭代的用户故事。
As the iteration matures, ”the sponsor and customer representatives should be continuously engaged with the project to provide feedback on deliverables as they are created and to ensure that the product backlog reflects their current needs.” The main idea here is that change is expected and welcome in a Scrum environment. This supports improved positive, fast, impact in the marketplace.
随着迭代的成熟，“发起人和客户代表应不断参与项目，以在交付可交付成果时提供反馈，并确保产品积压反映他们当前的需求。” 这里的主要思想是在 Scrum 环境中期望并欢迎变化。这有助于改善在市场上的积极，快速的影响。
Completion of Project Scope is Measured Against the Requirements (p. 131)
根据要求衡量项目范围的完成
# Validate Scope: One key output
- Authorized stakeholders need to “sign off”
授权的利益相关者需要 “退出” - Also known as “baselining”
也称为 “基准” - ”Sign off” means to formally accept the work product as complete and accurate
“签字” 是指正式接受工作产品的完整性和准确性
# Trends 趋势
(p. 132)
“The relationship between a project manager and a business analyst should be a collaborative partnership. A project will have a higher likelihood of being successful if project managers and business analysts fully understand each other’s roles and responsibilities to successfully achieve project objectives.”
“项目经理和业务分析师之间的关系应该是一种合作伙伴关系。如果项目经理和业务分析人员充分了解彼此的角色和职责以成功实现项目目标，那么该项目成功的可能性就更高。”
# Another word on Agile (p. 133)
“… agile methods purposefully build and review prototypes and release versions in order to refine requirements.”
“…… 敏捷方法有目的地构建和审查原型以及发行版本，以完善需求。”
- One interesting difference between waterfall and agile is that in waterfall, the tendency is to put nothing into production until the entire project is complete.
瀑布和敏捷之间的一个有趣的区别是，在瀑布中，趋势是在整个项目完成之前什么都不投入生产。 - In agile, delivery into production can happen anytime the Product Owner and Team agree that it makes sense to deploy code into production.
在敏捷中，只要产品负责人和团队同意将代码部署到生产中是有意义的，就可以将其交付到生产中。 - In a “DevOps” environment, once the work product is accepted by the product owner, it is deployed into production quickly (maybe even instantly). This is called “continuous delivery.” ”Continuous delivery” is one of the key components of DevOps.
在 “DevOps” 环境中，一旦产品所有者接受了工作产品，便可以快速（甚至即时）将其部署到生产中。这称为 “连续交付”。 “持续交付” 是 DevOps 的关键组成部分之一。
# Collect Requirements
“… the process determining, documenting, managing stakeholder needs and requirements to meet (project) objectives…(it provides) the basis for defining product scope and project scope.”
“…… 确定，记录，管理利益相关者的需求和要求的过程，以满足（项目）目标……（它提供）定义产品范围和项目范围的基础。”
# Requirements
(p. 140)
- “…include conditions or capabilities that are required to be present in a product, service, or result to satisfy an agreement or other formally imposed specification.”
“…… 包括满足协议或其他正式规定的产品，服务或结果中必须具备的条件或能力。” - ”…they include the quantified and documented needs & expectations of the sponsor, customer, and other stakeholders.”
“…… 包括发起人，客户和其他利益相关者的量化和记录的需求与期望。” - “Requirements become the foundation of the WBS”
“需求成为工作分解结构的基础” - “Cost, schedule, quality planning, and procurement are all based on those requirements.”
“成本，进度，质量计划和采购均基于这些要求。”
# Some Inputs to Requirements
(p. 141)
- Project charter 项目章程
- Assumptions log 假设记录
- Expert judgement 专家的判断
- Brain storming 头脑风暴
- Interviewing stakeholders 利益相关者访谈
- Focus groups 专门小组
- Surveys 调查
- Benchmarking to best practices 最佳实践基准
# Benchmarking to best practices
From iSixSigma
“A way or method of accomplishing a business function or process that is considered to be superior to all other known methods.”
一种完成业务功能或过程的方法或方法，被认为优于所有其他已知方法。
“A lesson learned from one area of a business that can be passed on to another area of the business”
从业务的一个领域中汲取的经验教训，可以传到业务的另一个领域
# More Inputs to Requirements
(p. 143)
- Business plans 商业计划书
- Current process flows 当前流程
- Request for Proposal (RFP) results 征集投标书（RFP）的结果
- Use cases 用例
# Requirement Approval Types 需求认可类型
(p. 144)
- Voting 投票
- Unanimity (100% agree) 一致同意
- Majority (greater that 50%) 多数
- Plurality (largest group decides) 多元，最大的群体决定
- Autocratic (one person decides) 独裁，单人决定
- Multicriteria decision making analysis (decision matrix- specific requirements vs. ability to meet those required items) 多准则决策分析（特定于决策矩阵的要求与满足那些必需项的能力）
# Nominal Group Technique 标称组技术
(pp. 144 – 145)
- Used to rank brainstorming output
用于对头脑风暴输出进行排名 - A question is proposed
提出一个问题 - Each team member creates ideas
每个团队成员都可以创造想法 - All ideas boarded (without names)
登上所有创意（无名称） - All team members understand all ideas
所有团队成员都了解所有想法 - Each person ranks each idea 1-5
每个人将每个想法排名 1-5 - Highest ideas are selected for moving forward with
选择了最高的想法以继续前进
# Facilitated Workshops 便利的研讨会
(p. 145)
I have had a lot of luck with JAD. The only issue is you have to do a ton of work to set up for an effective JAD session.
我对 JAD 感到很幸运。唯一的问题是您必须做大量工作才能建立有效的 JAD 会话。
# Prototypes
(p. 147)
- Provide a limited model of the perceived end state deliverable so the client can see what they are about to pay for.
提供可感知的最终状态可交付成果的有限模型，以便客户可以看到他们将要支付的费用。 - Supports client learning, expectation setting, and effective communication between client and development team.
支持客户学习，期望设定以及客户与开发团队之间的有效沟通 - Progressive elaboration can be supported by this.
逐步的精加工可以由此得到支持。 - Wireframes fit in here
线框适合这里
# Story Boards in IT
(p. 147)
Shows navigation paths between: 显示导航路径
- Screens
- Web pages
- Interfaces between applications 应用程序之间的接口
Before Baselining Requirements Need To Be…(p. 147)
在确定基准之前，需求需要：
- Unambiguous (measurable and testable)
明确（可测量和可测试） - Traceable 可追踪的
- Complete 完整的
- Consistent 一致的
- Acceptable of key stakeholders 可接受主要利益相关者
# Different Requirements Types
(p. 148)
- Business requirements (organizational needs)
业务需求（组织需求） - Stakeholder requirements (needs of a particular group of stakeholders)
利益相关者要求（特定利益相关者群体的需求） - Solution Requirements (features, functions, characteristics of the product or service)
解决方案要求（产品或服务的功能，特性，特征）- Functional requirements: Behaviors (actions, processes, data and interactions)
功能要求：行为（动作，过程，数据和交互） - Non-Functional:
非功能性：- They support functional requirements
它们支持功能要求 - They describe:
它们描述：- Environmental conditions
环境条件 - Necessary qualities for the product or service to be successful
产品或服务成功所必需的质量
- Environmental conditions
- They are often referred to as the “ilities” in industry
它们通常被称为行业中的 “ilities”- Reliability 可靠的
- Security 保密的
- Safety 安全的
- Supportability 可支持的
- They support functional requirements
- Functional requirements: Behaviors (actions, processes, data and interactions)
Performance
Level of service
Retention periods
# Requirements Tracability Matrix (A.K.A. RTM)
需求可追溯性矩阵
(p.148-149)
Main idea: each line of a requirement links right back to a specific ask in the business case, or another document with the same expectation.
主要思想：需求的每一行都直接链接到业务案例中的特定询问，或者具有相同期望的另一个文档。
# Some RTM uses…
(p. 149)
- Opportunities, goals 机会，目标
- Project objectives 项目目标
- Scope and WBS deliverables 范围和 WBS 交付成果
- Product design 产品设计
- Product development 产品开发
- Test strategies and test scenarios 测试策略和测试场景
- High-level requirements to more detailed requirements
从高级要求到更详细的要求
# Define Scope 定义范围
(p150)
Defined: ”the process of developing a detailed description of the project and product.”
定义为：“开发项目和产品的详细描述的过程。”
Benefit: ”describes the product, service, or result boundaries and acceptance criteria.”
好处：“描述了产品、服务或结果的界限和接受标准。”
7 Sources of Scope Creep: 7 min
During project planning (p 151)
在项目计划期间
“project scope is defined and described with greater specificity as more information is known about the project.”
“随着了解有关该项目的更多信息，将更具体地定义和描述项目范围。”
# Some inputs
(p 152)
- Project charter 项目章程
- Project management plan (how scope will be defined, validated, and controlled.)
项目管理计划（如何定义，验证和控制范围） - Other typical documents as input…
其他典型文件作为输入…- Assumptions log 假设记录
- Requirements documents 需求文件
- Risk register 风险登记册
- Lessons learned 得到教训
# How?
(p 153)
- Expert judgement 专家的判断
- Data analysis 数据分析
- Team input 团队投入
- Product analysis (“asking questions about a product or service and forming answers to describe the use, characteristics, and other relevant aspects of the key deliverable.”)
产品分析（“提出有关产品或服务的问题，并形成答案以描述关键交付物的用途，特征和其他相关方面。”）
# Define Scope Outputs
- Product scope description (often done through progressive elaboration)
产品范围描述（通常通过逐步完善来完成） - Deliverables 可交付的
- Acceptance criteria 验收标准
- Project exclusions (what is not included)
项目排除项（不包括在内）
# Validate Scope 验证范围
(p 163)
Defined: “Formalizing acceptance of the completed project deliverables”
定义：“正式接受已完成的项目可交付成果”
Value: “It brings objectivity to the acceptance process and increases the probability of final product, service, or result acceptance by validating each deliverable.”
价值：“它通过验收每个交付物，使验收过程具有客观性，并增加了最终产品，服务或结果验收的可能性。”
# Verification 核查
(p 164)
“The verified deliverables obtained from the Control Quality process are reviewed with the customer or sponsor to ensure they are completed satisfactorily and receive formal acceptance of the deliverables by the customer or sponsor.”
“从控制质量流程中获得的经过验证的可交付成果，将与客户或赞助商一起审查，以确保它们令人满意地完成，并获得客户或赞助商对交付成果的正式接受。”
# Validate Scope: T&T
(p 166)
- Inspection 检查
- Measure 估量
- Examine 审查
- Validate 验证
“determine whether work and deliverables meet requirements and product acceptance criteria.”
“确定工作和可交付成果是否满足要求和产品验收标准。”
# Acceptance
(p 166)
“Deliverables that meet the acceptance criteria are formally signed off and approved by the customer or sponsor.”
“符合验收标准的交付物已正式签署，并由客户或赞助商批准。”
# Control Scope 控制范围
(p 167)
Defined: ”the process of monitoring the status of the project and product scope and managing changes to scope baseline.”
“监视项目和产品范围的状态以及管理范围基线变更的过程。”
Value: “The scope baseline is throughout the project.” … “Controlling the project scope ensures all requested changes and recommended corrective or preventative actions are processed through the ’perform Integrated Change Control’ process.”
“范围基线贯穿整个项目。” …“控制项目范围可确保通过 “执行综合变更控制” 流程来处理所有请求的变更以及建议的纠正或预防措施。”
Comment:” Change is inevitable” you need a change control process!
“改变是不可避免的”，您需要一个改变控制过程！
Example of Out of Control Scope Change
The Vasa/Wasa War Ship (8 min)
