个人手敲，可能会有错误
未经允许，不可用于商业盈利
每条最后的页数对应《IT项目管理》第八版页数
另有按章节排序的词汇整理：见《IT项目管理 1-3,5-7章词汇整理 按章节排序》
释义来源：
《IT项目管理》 中文版 原书第八版
《Information Technology Project Management》Kathy Schwalbe 9th edition
A
activity attribute（活动属性）：提供了与进度相关的更多信息，如前导活动、后继活动、逻辑关系、提前和滞后、资源需求、约束、强制日期以及与活动相关的假设。（P163）
activity list（活动清单）：是包含在项目进度中的活动列表。这个清单应该包括活动名称、活动标识或者编号以及活动的简短描述。（P163）
actual cost（AC实际成本）：是在给定时间内，完成一项活动所产生的直接成本和间接成本的总和。（P206）
adaptive life cycle（自适应生命周期）：干系人在迭代开始之前定义和批准详细范围，并在每次迭代结束时产生可用的产品。 PMI也将适应性生命周期称为敏捷（agile）或变更驱动（change-driven）。 当高变化、高频交付时，此方法最有效。（第九版新内容）
agile approach（敏捷方法）：意味着使用基于迭代和增量开发的方法，通过合作解决需求和方案。敏捷方法可以用于软件开发或用于任何需求未知或者变化很快的环境中。敏捷方法设置时间和成本，但并没有设置范围目标，从而使其具有灵活性，因此项目发起人或者产品负责人能够对想要做的工作设定或者重新设定优先级。（P51） 回顾前面论述的一些敏捷方法，通常用于这样的项目:项目业务团队在产品生命周期的早期不能清楚表达项目范围，但团队确实想在项目早期而不是后期提供一个潜在的可交付产品。一个敏捷项目团队通常使用若干次迭代来交付软件,而不是等到项目结束后提供一个产品。 （P87） 对于项目约束不严格、有经验且合作良好的团队、风险小、需求模糊和进度灵活的项目将更适合使用敏捷方法。（P87）
analogous estimate（类比估算）：也叫做自上而下估算（top-down estimates），它是使用以前相似项目的实际成本作为当前项目成本估算的根据。它需要非常专业的判断能力，较其他方法更节省，但不精确。当以前的项目与目前的项目不仅是表面上相似，而且在本质上也很相似时，类比估算才最可靠。此外，进行估算的项目团队必须拥有所需要的专门技术，以决定项目的某一部分是否要比类比项目花费更多的成本。例如，估算往往试图找到一个类似的项目，然后自定义或修改已知的差异。然而，如果被估算的项目包括一种新的程序语言,或使用新型硬件或网络,那么类比估算容易导致估算过低。（P199）
analogy approach（类比法）：采用一个相似项目作为出发点。（P145）
B
backward pass（逆推法）：可用来确定最晚开始和最晚完成时间。（P176）
baseline date（基线日期）：活动的计划进度日期。（P173）
baseline（基线）：是最初项目计划加上被批准的变更。实际信息包括WBS项是否完成或工作大约完成了多少？工作什么时候实际开始或结束？已完成的工作实际花费是多少？（P206）
benchmarking（基准测试）：是通过与执行组织的内部或外部的其他项目或者产品进行比较，以获得具体项目时间或产品特征的需求思想。（P137）
best practice（最佳实践）：为产业公认的达到确定目标或目的的最佳方法。（P14）
bottom-up approach（自下而上法）：项目团队成员首先识别尽可能多的与项目有关的具体任务。随后，讲这些具体的任务集中并组织成概要任务或WBS中的较高层次。（P146）
bottom-up estimate（自下而上估算）：是估算单个工作项目或活动的成本，并将它们汇总成整体项目估算的一种方法，有时它也被称为基于活动成本法。单个工作项的大小和估算人员的经验决定估算的精确度。如果一个项目有详细的工作分解结构，项目经理就能够让每个人负责一个工作包,为该工作包建立成本估算，或至少估计所需要的资源量。组织中的财务人员通常提供资源成本率,如人力成本率或每磅的材料成本，可运用项目管理软件计算成本。然后用软件自动计算的信息来创建WBS中每个级别的成本估算，并且最终完成整个项目的估算。（P199）
budget at completion（BAC完工预算）：项目的原始总预算。（P208）
budgetary estimate（预算估算）：用于将资金分配到组织的预算中。许多组织建立至少两年的预算，预算估算在项目完成前一两年做出，其精确度一般是-10%～+25%。（P198）
burndown chart（燃尽图）：显示了按天计算在一个冲刺中累积工作的剩余量。（P88） 是非常重要的工件，在每个冲刺中以图形化的方式来显示进度。（P92）
C
champion（倡导者）：一些项目所具有的高级经理，他扮演着项目的关键支持者。（P39）
closing process（收尾过程）：包括对项目或者项目阶段的正式验收，并有效地终止。管理活动通常出现在这个过程组中，例如，项目文档归档、完成合同、总结经验教训，以及作为阶段或者项目一部分的交付工作收到正式验收确认。（P60） 收尾过程包括获得干系人和客户对于最终产品的服务和验收，同时使项目或者项目阶段实现有序的结束。（P85）
Collecting requirements（收集需求）：定义并记录项目最终产品的特点和功能，以及创造这些产品的过程。收集需求过程的输出是项目团队编制的需求文档和需求跟踪矩阵。（P134）
Conflict tolerance（抗冲突能力）：鼓励员工把意见和批评公开化的程度。对于项目干系人良好的沟通很重要，最好有一个能够让人公开且自由讨论冲突的组织。（P37）
contingency reserve（应急储备金）：是为一些可以部分预计的未来情况（也称已知的不确定事件（known unknowns））做准备的资金，它包含在项目成本基线中。（P196）
Control（控制力）：使用规则、政策和直接监管来监督与控制员工行为的程度。有经验的项目经理知道，最好通过平衡控制的程度来获得好的项目结果。（P37）
Controlling costs（成本控制）：包括控制项目预算的变更。主要输出：工作绩效信息、成本预测、变更请求、更新的项目管理计划、更新的项目文档、更新的组织过程资产（最后一条第九版已删除）。（P193）
Controlling scope（控制范围）：对整个项目生命周期内的范围变化进行控制,这对许多IT项目是一种挑战。范围变更经常影响团队满足项目时间目标和成本目标的能力。因此,项目经理必须仔细权衡范围变更的成本和收益。这一阶段的主要输出包括工作绩效信息、变更请求、项目管理计划、项目文档和组织过程资产的更新。（P134）
Controlling the schedule（控制进度）：控制和管理项目进度的变更。（P162）
cost performance index（CPI成本绩效指数）：是挣值与实际成本的比值，可以用来估算完成项目的预计成本。如果成本绩效指数等于1，则说明预算成本和实际成本相等，或者说成本与预测完全相同。如果该指数小于1，则项目超出预算。如果该指数大于1，则说明项目在预算范围内。（P208）
cost variance,（CV成本偏差）：是挣值减去实际成本。如果成本偏差是一个负数，则意味着执行工作所用的成本高于计划成本，如果成本偏差是一个正数，则意味着执行工作所用的成本低于计划成本。（P207）
crashing（赶工）：是一种为了以最少的成本最大限度的压缩工期，而在成本与进度之间进行的均衡的技术。（P177）
Creating the WBS（创建工作分解结构WBS）：将主要的项目可交付成果分解成更细小和更易管理的部分。它的主要输出包括范围基线(工作分解结构、WBS词典)及项目文档的更新。（P134） 方法：使用指南（using guidelines）、类比法（analogy approach）、自上而下法（top-down approach）、自下而上法（bottom-up approach）、思维导图法（mind-mapping approach）。（P145） 创建WBS或者WBS字典的建议：每个单元的工作应该在WBS中只能出现一次。每个WBS条目中的工作内容是该条目以下所有条目之和。每个WBS条目都只对应一个负责人，虽然很多人可能都在做这项工作。WBS 和工作时间如何执行必须保持一致:首先要服务于项目团队;在实用性的前提下，其次才考虑其他的目的。项目团队成员应该全身心投入WBS的创建中去从而确保连贯性和大宗买进。每一个WBS条目都必须记录在WBS字典中，确保精确理解条款包括或不包括的工作范围。WBS必须对于不可避免的变更能够柔性适应，同时要按照范围说明书的内容保持对于工作内容的控制。（P149）
critical chain scheduling（关键链调度）：是一种进度计划方法，在创建项目进度时考虑有限的资源，并且将缓冲包括进来以保护项目完成期限。（P178）
critical path analysis（关键路径分析）：同关键路径法（critical path method）。（P174）
critical path method（关键路径法）：是一种网络图技术，用来预测整个项目的工期，这种重要的工具将帮助防止项目进度超期。（P174）
critical path（关键路径）：决定了项目最早完成时间的活动序列，是网络图的最常路径，其时差或者浮动时间最少。（P174）
critical path（关键路径）：网络图中最常的路径，它决定着一个项目最早的完成日期，显示了一个项目的哪些任务影响了目标完成日期。（P20）
D
daily scrum（每日例会）：开发团队分享进展、挑战和计划一天工作的简单会议。在理想情况下，团队成员位于同一地点的会议通常不会超过15分钟，这是每天在相同时间和地点举行的。许多团队使用术语“问题”来表示这些不需要在未来24小时内解决的条目，用“阻碍”来表示需要立刻解决的条目。这允许敏捷教练首先保持专注优先级条目（阻碍），然后在接下来的一天左右解决其他问题。（P88）
decomposition（分解）：把项目可交付成果划分为更小的部分。（P141）
Defining activities（定义活动）：识别项目团队成员和干系人必须执行并产生项目可交付成果的特定活动。活动（activity）或任务（task）是工作的组成要素，通常出现在工作分解结构中，有预计的工期、成本和资源要求。（P162）
Defining scope（定义范围）：评审范围管理计划、项目章程、需求文档和组织过程资产来创建一份范围说明书，并且随着需求的扩展和变更请求得到批准而增加更多的信息。定义范围的主要输出有项目范围说明书以及项目文档的更新。（P134）
definitive estimate（确定性估算）：提供一个精确的项目成本估算，常用于许多采购决策的制定，因为这些决策需要精确的预算，同时它也常用于估算最终项目成本。例如，如果一个项目在3个月内需要从外部购买1000台个人计算机，那就需要进行确定性估算，以帮助评估供应商的投标建议书并划拨资金给选中的供应商。确定性估算通常在项目完成前一年或更短时间内进行。它是三种估算类型中最精确的，通常精确度为-5%～+10%。（P198）
deliverable（可交付成果）：是一种产品或者服务，如技术报告、培训课程、硬件模块或者软件代码片段，这些是作为项目的一部分而产生或提供的产品。（P41） 是对项目所涉及面向交付成果的分组。（P141）
dependency（依赖）：与项目活动或者任务的排序相关。包括强制依赖（mandatory dependency）、自由依赖（discretionary dependency）、外部依赖（external dependency）。（P165）
Determining the budget（确定预算）：包括将整体成本估算配置到各项工作，以建立一个衡量绩效的基线。主要输出：成本基线、项目资金需求和更新的项目文档。（P193）
Developing the schedule（制订进度）：通过分析活动序列、资源需求和活动工期估算来创建项目进度。（P162） 最终目标是创建一个可行的项目进度表，该进度从项目的时间维上提供监控项目进展的基础（basis）。（P170）
direct cost（直接成本）：是与项目的产品和服务的生产直接相关的成本。你能够把直接成本归结于某一项目，例如，在项目中全职工作人员的薪金、为项目专门购买硬件和软件的成本都是直接成本。项目经理应该重视直接成本，因为它们是可控的。（P196）
discretionary dependency（自由依赖）：是由项目团队定义的项目活动之间的关系。例如，项目团队可能遵循好的实践，在用户签署同意所有分析工作之前，项目团队不会开始新的信息系统的详细设计。自由依赖有时又称为软逻辑，应该谨慎使用，因为它将可能限制以后的进度安排。（P166）
dummy activity（虚活动）：没有工期而且没有资源，但是有时需要在AOA网络图上用虚活动表示活动之间的逻辑关系，它们是用虚的箭线表示的，工期估算为零。（P168）
duration（工期）：包括活动上花费的实际时间和占用时间。（P169）
E
early finish date（最早完成时间）：是基于项目网络逻辑最早可能完成的时间。
early start date（最早开始时间）：是基于项目网络逻辑可以开始的最早的可能时间。（P175）
earned value management（EVM挣值管理）：是一种综合了项目范围、时间和成本数据的项目绩效测量技术。给定成本执行基线，项目经理和他的团队可以通过输入实际的信息，并将其与基线比较，从而判断项目目前在多大程度上满足了范围、时间和成本目标。（P206）
earned value（EV挣值）：是实际完成工作的估算值。它是基于项目或活动初始计划成本的，是项目组当前实际完成工作的比率。（P206）
effort（人工量）：完成任务所需要的工作天数或者工作小时数。（P169）
enterprise project management software（企业项目管理软件）：能够整合多种项目信息，并能够显示整个企业中正在进行的、已被批准的和规划中的项目的情况。（P15）
estimate at completion（EAC完工估算）：成本性能指标用来计算完工估算，即估算迄今为止基于性能完成一个项目的成本。同样，进度执行指数可以用来计算完成一个项目估计的时间。（P208）
Estimating activity durations（估算活动工期）：估算完成单项活动所需的工作时间。（P162）
Estimating costs（成本估算）：包括完成项目所需资源的近似或估算成本。主要输出：成本估算、估算的基础、更新的目文档。（P193）
ethics（道德）：广义的道德就是基于什么是对的、什么是错的来引导我们做出决定的一系列原则。（P24）
executing process（执行过程）：包括协调人力和其他资源来执行项目的计划，以产生项目或者项目阶段的产品、服务或者结果。执行过程包括组织项目团队、执行质量保证、发布信息和管理项目干系人的期望以及指挥采购。（P60）
external dependency（外部依赖）：涉及项目和非项目活动之间的关系。例如，新的操作系统和其他软件的安装依赖于外部供应商交付的新硬件。尽管新硬件的交付并不在项目的范围内，但是因为交付延误将影响项目的进度，所以应该加上这条外部依赖。（P166）
External project stakeholders（外部项目干系人）：项目的客户（在组织外部）、竞争对手、供应商和别的参与项目或者为项目所影响的外部团体，如政府官员和相关民众。（P38）
F
fast tracking（快速跟进）：包括并行执行那些通常以顺序方式执行的活动。（P177）
feeding buffer（汇入缓冲）：在那些前导是非关键链任务的关键链任务的关键链任务之前增加的附加时间。关键链调度还是用汇入缓冲来保护关键链上被延误的任务。（P179）
Finish-to-finish dependency（完成-完成依赖）：A relationship in which the “from” activity must be finished before the “to” activity can be finished. One task cannot finish before another finishes. 任务A完成之前任务B不能完成。（P168）
Finish-to-start dependency（完成-开始依赖）：A relationship in which the “from” activity or predecessor must finish before the “to” activity or successor can start. AOA network diagrams use only finish-to-start dependencies. 任务A完成之前任务B不能开始。（P167）
float（浮动时间）：同时差（slack）。（P174）
forward pass（正推法）：用来确定一个活动的最早开始和最早完成时间。（P176）
free float（自由浮动时间）：同自由时差（free slack）。（P175）
free slack（自由时差）：是一个活动在不延误紧接活动的最早开始时间情况下可以被拖延的时间。（P175）
functional organizational structure（职能型组织结构）：是一个层次结构，是职能经理或一些特定领域的专职副总裁向CEO报告。职能型结构中项目经理的权威很少或没有。（P35）
G
Gantt chart（甘特图）：是一种标准格式，它通过在日程表上列出各种项目活动以及各自开始和结束的时间来显示项目的进度信息。（P20）
generic life cycle（传统生命周期）：第八版：概念（concept）、开发（development)、实施（implementation）、收尾（close-out）；第九版：开始（starting）、组织（organizing）、实施（carrying）、完成（finishing）。（P42）
Group emphasis（团队专注度）：指员工的工作范围围绕着团队而不是个人的程度。（P37）
H
high-end tools（高端工具）：有的时候叫做企业项目管理软件，具有处理超大型项目和分散的工作组的强大能力，拥有企业和项目组管理功能，并能够归纳和整合单个项目信息，提供企业所有项目整体认识的功能。（P26）
human resources frame（人力资源框架）：聚焦于提供组织和人员需求之间的协调。（P34）
hybrid life cycle（混合生命周期）：根据工作的性质，可以使用多种方法的组合。 例如，某些可交付成果可能具有较低的更改度和较低的交付频率，例如每周进度报告，较高的更改度和较高的交付频率（例如某些软件功能）等等。被很多组织使用，因此将一组预测性步骤用作协调适应性管理的更详细步骤的总体方法。（第九版新内容）
I
incremental build life cycle model（渐增式构建生命周期模型）：提供了对操作软件累进的开发，每个版本都提供了附加的功能。（第九版已删除）** （P44）**
incremental life cycle（增量生命周期）：可交付成果是通过一系列迭代产生的，这些迭代在设定的时间范围内增加了功能。 交付直到最后一次迭代后才完成。 当低变化、高频交付时，此方法最有效。（第九版新内容）
indirect cost（间接成本）：是与项目的产品和服务的生产不直接相关的成本，但是它们间接地与项目的绩效挂钩。例如，在一个大的办公楼里，为许多项目工作的上千员工所使用的电力费用、纸巾和其他必须消费都是间接成本。间接成本是分摊给项目的，因此，项目经理很难控制它们。（P196）
initiating process（启动过程）：包括定义和批准项目或者项目阶段。（P60） 包括识别项目干系人（identifying project stakeholders）、起草项目章程（project chart）、召开启动会议（kick-off meeting）
intangible benefit（无形收益）：是那种很难用货币来衡量的收益。包括：与其他企业建立良好关系，树立商誉、信誉以及其他一些很难用货币来衡量的生产力进步。（P196）
intangible cost（无形成本）：是那种很难用货币来衡量的成本。（P196）
Internal project stakeholders（内部项目干系人）：项目发起人、项目团队、辅助人员和内部用户，其他内部干系人包括高层管理人员、其他职能经理和项目经理。（P38）
iterative life cycle（迭代生命周期）：范围是尽早确定的，但是随着对产品了解的增加，时间和成本估算也将随之修改。 迭代用于通过一系列重复的周期来开发产品，以增加产品的功能。 当高变化、低频交付时，此方法最有效。（第九版新内容）
J
joint application design（JAD联合应用设计）：使用高度组织化和集中式的工作会议将项目干系人，即发起人、用户、商业分析师、程序员等结合在一起来共同定义设计信息系统,这些技术同时也可以帮助用户在定义系统需求时更加活跃。关于这些技术咨询系统分析并设计详细的文本。
K
Kanban（看板）：使用视觉线索来指导工作流程，可以与Scrum配合使用。能使工序中的瓶颈可视化，人们能够进行协作来解决这些瓶颈问题，从而最大可能的减少在制品数量。有助于改进日常工作流程。（P52）
kick-off meeting（启动会议）：是指在项目开始召开的会议，以便项目干系人见面、评论项目目标、讨论未来的计划。通常项目启动会议在商业论证和项目章程完成后举行，也可根据需要提前。（P71）
kill point（检查点）：对于保持项目的进度以及决定是否该就、改变方向或者终止项目是非常重要的。同阶段出口。（P45）
known unknowns（已知的不确定事件）：应急储备金（contingency reserve）中涉及。（P196）
L
late finish date（最晚完成时间）：是一个活动在不延迟项目完成时间的最晚可能完成的时间。（P176）
late start date（最晚开始时间）：是一个活动在不延迟项目完成时间的最晚可能开始的时间。（P176）
learning curve theory（学习曲线理论）：当重复生产许多产品是，那些产品的单位成本随着数量的增多而呈现单位递减。（P196）
life cycle cost（生命周期成本）：是对贯穿于整个生命周期的成本状况的总体认识。这有助于更加精确的编制一份项目财务收益计划。（P194）
low-end tools（低端工具）：提供基本的项目管理功能，具有有限的功能，通常推荐给小项目和单个用户，允许创建甘特图。（P25）
M
management reserve（管理储备金）：是为不能预测的未来情况（也称未知的不确定事件（unknown unknowns））做准备的资金。管理储备金并不会包括在成本基线中。（P197）
mandatory dependency（强制依赖）：是项目工作中内在的一种关系，某些时候被称为硬逻辑。例如，在写代码之前.你不能测试代码。（P166）
matrix organizational structure（矩阵型组织结构）：是职能型和项目型结构的中间形式。个人既要向职能经理也要向一个人或多个项目经理报告。强矩阵型结构中项目经理控制项目预算。弱矩阵型结构中职能经理控制项目预算。（P35）
Means-ends orientation（结果导向度）：管理着眼于产出为不是完成这些结果所需要的技术和过程的程度。（P37）
Member identity（成员认同度）：成员认同度是指员工将组织视为一个整体而不仅仅是工作类型或职位的认同程度。（P37）
midrange tools（中端工具）：比低端项目高级一些为大型项目、多用户和多项目而设计。可制作甘特图、网络图，可关键路径分析、资源配置、项目追踪和编写状态报告。（P26）
milestone（里程碑）：项目中一个通常没有工期的重要事件。（P164）
mind-mapping approach（思维导图法）：是一种从核心思想向外辐射出分支（branch）的技术，将思想和想法结构化。与写任务列表或者直接创建任务结构不同的是，思维导图法可以让人们用非线性的格式写甚至画出自己的想法图。（P146） 思维导图使用自上而下法或者自下而上法。（P147）
monitoring and controlling process（监控过程）：包括有规律地测量和监视项目进展，以保证项目团队能够满足项目目标。项目经理和项目成员监视和测量偏离计划的过程，在需要的时候采取正确的行动。通常的监视和控制方法是执行报告，在这些报告中，项目的干系人能够识别任何需要的变化,从而保证项目没有偏离目标。（P60）
multitasking（多任务）：发生在一个资源在同一时间用于多个任务的时候，这种情形经常发生在项目中。（P178）
Murphy’s law（墨菲定律）：如果某件事情可能出错，那么它就会出错。（P179）
N
network diagram（网络图）：是项目活动之间的逻辑关系或者顺序的示意性表示。网络图的格式使用的是双代号网络图（activity-on-arrow, AOA）的方法或者箭线图法（arrow diagramming method, ADM)，这是一种网络图技术。在该图中活动用箭头表示，并将节点(箭头的交点）连接起来，表示活动的序列。节点（node）可以表示一个活动的开始和结束，第一个节点表示项目的开始，最后一个节点表示项目的结束。（P166）
O
offshoring（海外外包）：有时用来描述安排在另外一个国家的外包。（P49）
Open-systems focus（开放系统聚集度）：组织对外部环境改变的检测和响应程度。（P37）
operation（运营）：是组织为了维持业务而进项的工作。（P3）
outsourcing（外包）：是一个团队从外部寻找来源以获取需要的产品和服务。（P49）
P
parametric estimating（参数估算）：是在一个数学模型中应用项目特征（参数），以估算项目成本。例如，基于软件开发项目中使用的编程语言、编程人员的专业知识水平、程序大小和设计数据的复杂性等，一个参数模型可能会对一个软件开发项目得出每行代码50美元的估算。如果建立模型所用的历史信息是精确的，项目参数容易量化，并且模型就项目大小而言是灵活的，那么这种情况下参数模型是最可靠的。（P199）
Parkinson’s law（帕金森定律）：陈述了工作会拖延并占满所有可用的时间。没有任务缓冲应当以为这帕金森定律出现的概率要小。（P179）
People focus（人员聚集）：指管理决策考虑组织中员工产出效果的程度。好的项目经理应该平衡个人和组织的需求。（P37）
phase exit（阶段出口）：对于保持项目的进度以及决定是否该就、改变方向或者终止项目是非常重要的。同检查点。（P45）
planned value（PA计划值）：也叫预算，是在给定时间内计划花费在某个活动上的已批准总成本估算的部分。（P206）
Planning cost management（成本计划）：包括确定用于计划、执行、监控项目成本的政策程序和文档。主要输出：成本管理计划。（P193）
planning process（计划过程）：包括制订（devising）和维护一个可执行的计划，以保证项目班组组织的要求。（P60） 计划通常是项目管理中最困难和最不受欢迎的过程。项目计划的主要目的是指导项目的执行。（P72）
Planning schedule management（计划进度管理）：确定将用于计划、执行和控制项目进度的政策、过程和文档。（P162）
Planning scope management（制订范围管理计划）：确定如何管理项目的范围和需求。项目团队和合适的项目干系人共同创建一个范围管理计划和需求管理计划。（P134）
political frame（政治框架）：解决组织和个人的问题。组织中的政治表现为团体或者个人对于权力和领导地位的竞争。政治框架假定是由不同的个人和利益集团联合而成的。（P34）
precedence diagramming method（PDM前导图法）：是一种网络图技术，使用方框表示活动，它在显示特定类型的时间关系时特别有用。（P167）
predictive approach（预测方法）：对于具有强大约束、经验不足且分散的团队、风险大、清晰的项目前期需求以及有相当严格的完成日期的项目，最好使用预测型方法。（P87）
predictive life cycle（可预测生命周期）：范围，进度和成本尽早确定，并仔细管理范围的更改，PMI也将预测生命周期称为瀑布。（第九版新内容）
pre-initiation/opening（预启动）：决定项目的范围、时间和成本的制约因素。识别项目发起人。选择项目经理。为项目开发一个商业论证（business case）。与项目经理开会讨论项目管理过程及预期成果。决定项目是否需要被分为两个或更多个子项目。（P66）
process（过程）：针对某一特定活动结果的一系列行动。（P60）
product backlog（产品待办事项）：按照商业价值进行优先级排序的特性列表。最高优先级的条目应该被分解成较多的细节以便于团队估计开发的工作量。一些专家建议每个条目安排10个工作日。当然，工作量的大小和工作的复杂性决定了估计。（P88）
product owner（产品负责人）：负责项目的商业价值，决定做什么工作以及以什么顺序记录在产品待办事项列表中。（P88）
profit margin（利润率）：利润和收入的比值。（P194）
profit（利润）：收入减去支出。（P194）
program evaluation and review technique（PERT计划评审技术）：在单个活动工期估计高度不确定的情况下，用来估计项目工期的技术。使用概率时间估算（probabilistic time estimate）： 。（P180）
program（项目群）：一组相互联系的项目，宜采用协同的方法进行管理来获得收益和进行控制，而这种收益和控制在单独管理这些项目时是不宜获得的。（P12）
project acquisition phase（项目获取阶段）：传统项目的后两个阶段，实施和收尾。（第九版已删除该内容）** （P42）**
project and portfolio management software（项目和组合管理软件）：能够整合多种项目信息，并能够显示整个企业中正在进行的、已被批准的和规划中的项目的情况，同企业项目管理软件。（P15）
project buffer（项目缓冲）：它是在项目完工日期之前增加的附加时间。关键链调度去掉了单个任务的缓冲，但是创建了项目缓冲。（P179）
project charter（项目章程）：最可能包含已经计划了的项目的开始和结束日期，被当作详细进度的起始点。（BB练习题123）项目章程包含项目的一个粗略的进度安排（draft schedule）。（BB练习题100）项目经理应该做的第一个现实性检查是评审进度草案，该草案通常包含在项目章程中。（P182）
project cost management（项目成本管理）：包括用来确保在批准的预算范围内完成项目的必要过程。包括四个过程：成本计划（Planning cost management）、成本估算（Estimating costs）、确定预算（Determining the budget）、成本控制（Controlling costs）。（P193）
project feasibility phase（项目可行性）：传统项目的前两个阶段，概念和开发。（第九版已删除该内容）** （P42）**
project life cycle（项目生命周期）是一系列项目阶段的集合。在项目生命周期的早期阶段，对资源的需求最低，而不确定性的程度最高，项目干系人有机会影响项目的产品、服务和成果的最终特征。在项目声明周期的最后几个阶段中，进行大修改的代价比较高。在项目生命周期的中期，随着项目的推进，完成项目的确定性也随之提高，有关项目需求和目标的信息更加丰富，并且比项目初始或最后阶段需要更多的资源。项目生命周期的最后阶段的关注点在于保证满足项目需求以及项目发起人对项目完成的情况许可。
project management knowledge area（项目管理知识域）：项目经理必须具备的重要知识。（P8）
project management office（项目管理办公室）：是一个有组织的团队，负责协调整个组织中的项目管理功能。（P21）
project management process group（项目管理过程组）：包括启动、计划、执行、监控、收尾。（P60）
project management tool and technique（项目管理工具和技术）：用来帮助项目经理和他们的团队进行十大知识域涉及的项目管理。（P9）
project management（项目管理）：在项目活动中专门运用的知识、技能、工具和技术，以满足项目需求。（P7）
project manager（项目经理）：一个优秀的项目经理是项目成功的关键。（P6）
project organizational structure（项目型组织结构）：同样具有层次结构，但并不是职能经理或者副总裁向CEO负责，而是项目经理直接向CEO负责。项目型结构中项目经理的权威高或者基本全部**（P35）**
project portfolio management（项目组合管理）：在项目组合管理中，组织将项目以及项目群组合并进行管理，使其作为一个投资组合，从而促使整个行业的成功。（P13）
project scope management（项目范围管理）：是指对产品包括什么与不包括什么的界定和控制的过程。他确保项目团队和干系人在项目开发什么产品以及开发产品使用什么过程这两方面达成共识。（P134）
project sponsor（项目发起人）：一般为项目提供方向和资金。（P5）
project tine management（项目时间管理）：确保项目按时完成所需的过程。包括计划进度管理、定义活动、排序活动、估算活动工期、制订进度、控制进度。（估算活动资源第九版已删除）** （P162）**
project（项目）：为创造一个特定的产品、服务或者成果而采取的临时性的努力。（P3）
prototyping life cycle model（原型生命周期模型）：用于开发软件原型来阐明用户操作软件的需求。它需要大量用户参与，开发者使用一个模型来产生功能需求，并同步产生物理设计规范。开发者能够根据项目来抛弃或者保留原型。（P44）
prototyping（原型开发）：是指开发系统或者系统的某些方面的可运行的副本，以帮助定义用户需求。这些工作的副本可以是小册子或者可交付使用系统递增的组件。原型开发是一个获取需求理解、决定需求可行性和解决用户界面不确定性的有效工具。（P152）
R
RAD life cycle model（快速应用开发生命周期模型）：由开发者处理眼花模型。该生命周期模型通常需要用户发量参与，同时在不牺牲质量的前提下快速开发项目。开发者使用RAD工具，例如，CASE（computer-aided software engineering计算机辅助软件工程），JRP（Joint application design联合需求规划），JAD（Joint application design联合应用设计）来帮助快速原型的建立和代码生成。（P44）
rate of performance（RP完成百分比）：是实际完成工作与在项目或活动周期给定时间内已完成计划工作的比率。（P206）
rational unified process framework（RUP 统一软件开发过程框架）：是一个迭代的软件开发过程，他关注团队的生产率以及所有团队成员提供的软件的最佳实践。（P65）
relationship（关系）：同依赖（dependency）。（P165）
requirement management plan（需求管理计划）：记录了如何分析、记录和管理项目需求。包括：如何计划、追踪和报告需求活动?如何执行配置管理活动？如何对需求进行优先次序排序？如何使用产品指标？如何跟踪和捕获需求的属性？（P135）
requirement traceability matrix（RTX需求跟踪矩阵）：是列出各种需求、需求属性和需求状态的一种表格，以确保所有需求被跟踪（addressed）。（P138）
requirement（需求）：项目或项目的当前产品、服务或结果必须满足的条件或能力，其结果是达到合同或其他正式实施范围的要求。需求“包括发起人、客户与其他项目干系人的量化和文档话的需求和期望。一旦项目开始执行，这些需求需要被获取、分析，并被详细记录在范围基线内并且进行度量。”（P135）
reserve（储备金）：是包含在成本估算中的，为了减轻未来难以预测情形所带来的成本风险而准备的资金。（P196）
resource breakdown structure（资源分解结构）：是一种层次结构，可以按照种类和类型确定项目的资源。资源的种类包括分析员、程序员、测试员。（第九版已删除）** （P169）**
Reward criteria（奖励标准）：奖励的分配是按照员工的绩效而不是按照资历、兴趣或者其他非绩效因素的程度。（P37）
Risk tolerance（抗风险能力）：是指员工被鼓励具有进取心、创新性和冒险精神的程度。（P37）
rough order of magnitude estimate（ROM粗粒度估算）：提供了项目成本的一个粗略估算。ROM估算也可称作近似估算、猜算、虚估或泛算，它在项目早期甚至在项目正式开始之前运用。项目经理和高层管理者使用该估算帮助项目选择决策，进行这种类型的估算通常是在项目完成之前的3年或更长时间。粗粒度估算的精确度一般是-50%~+100%。（P197）
S
schedule baseline（进度基线）：整个经过审批的计划进度。（P173）
schedule performance index （SPI进度绩效指数）：是挣值与计划值的比值，可以用来估算完成项目的预计时间。如果与成本绩效指数相类似，进度执行指数为1，则项目进度符合进度计划。如果进度执行指数大于1，则项目超前于进度计划。如果该指数小于1，则项目进度落后于进度计划。（P208）
schedule variance（SV进度偏差）：是挣值减去计划值。负的进度偏差意味着执行工作用时比计划用时长，而正的进度偏差意味着执行工作用时比计划用时短。（P207）
scope baseline（基线范围）：包括批准的项目范围说明书和与至相关的WBS以及WBS字典。（P141）
scope creep（范围蔓延）：项目范围不断扩大的趋势。（P149）
scope statement（范围说明书）：应该罗列并描述所有项目需求的可交付成果。（P144）
scope validation（范围确认）：是指整个项目可交付成果的正式验收。（P150）
scope（范围）：是指开发项目产品所涉及的所有工作和用来开展工作的所有过程。（P134）
Scrum team or development team（Scrum团队或开发团队）：由5~9人自发组织的跨职能团队，其工作是用来产生每个冲刺所需要的结果。一个冲刺（sprint）通常持续2～4周，在这期间必须完成特定的工作并可以进行审查。大型项目可能需要团队之上的团队。（P88）
Scrum：产品负责人创建一个优先级排序愿望列表，称为产品待办事项。在冲刺计划中，团队把产品待办事项愿望列表顶端的一小块提取出来称作一个冲刺待办事项，并决定如何实施。团队用确定的时间冲刺完成他们的工作，通常为2～4周，但每天见面评估其进展（每日例会)。在这个过程中，敏捷教练使团队专注于目标。在冲刺结束时，工作应该是可以交付的，如准备递交给客户，放到货架上或者展示给项目干系人。冲刺结尾有冲刺评审和冲刺回顾。作为下一个冲刺的开始，团队选择另一块产品待办事项列表并开始再次工作。（P52） 产品代办事项（product backlog），冲刺计划会议（sprint planning session），冲刺代办事项（sprint backlog），每日例会冲刺（daily scrum），冲刺评审（sprint review），冲刺回顾（sprint retrospective）。Scrum角色：产品负责人（product owner），敏捷教练（ScrumMaster），Scrum团队或开发团队（Scrum team or development team）。Scrum意味着团队成员作为一个自主组织来工作，接受敏捷教练的指导，所以团队协议（team chart）不是必须的。（P90）
ScrumMaster（敏捷教练）：确保团队的生产力，促进每日例会，使所有角色和职能密切合作，并且移除阻碍团队发挥的障碍。敏捷教练管理的是过程而不是团队的人。他们必须对产品负责人和团队放心地放弃控制权。一些专家认为，传统的项目经理不会成为伟大的敏捷教练。（P88）
Sequencing activities（排序活动）：是指识别和记录项目活动之间的关系（relationship）。（P162）
six sigma methodology（六西格玛方法论）：许多组织采用六西格玛方法论做项目。项目质量专家的工作促进了如今六西格玛原则的发展。六西格玛项目经常采用的两种方法论分别为：DMAIC，即定义、度量、分析、改进、控制，用于改进已有业务流程；DMADV，即定义、度量、分析、设计、验证，用于创造新产品或过程设计，以取得可预测且无缺陷的业绩。（P65）
slack（时差）指的是在不延误后续活动或者项目完成时间的情况下，任务可以推后的时间。（P174）
slipped milestone（偏移的里程碑）：在跟踪甘特图上的白色菱形。意味着里程碑活动的实际完成时间比原来计划的要晚。（P173）
SMART criteria（SMART准则）：明确的（special）、可度量的（measurable）、可分配的（assignable）、现实的（realistic）、有时间限制的（time-framed）。（P172）
spiral life cycle model（螺旋式生命周期模型）：该模型认识到多数软件都是使用迭代或者螺旋方法而不是线性方法开发出来的。项目团队不排除在生命周期后期要变化或修改项目，并返回需求阶段来更仔细的阐明和设计修改的版本。这种方法的应用条件是项目的变化可以与合理的成本增加或可接受时间的延迟相合并。分析、设计、执行、测试。（P44）
sprint backlog（冲刺待办事项）：在产品待办事项中的一个冲刺内完成的优先级最高的条目集合。Scrum团队把最高优先级的条目分解成可以花12～16个小时完成的小任务。冲刺待办事项和产品待办事项的例子会在本节的计划部分提供。（P88）
sprint planning session（冲刺计划会议）：在一个冲刺内团队从产品待办事项中选择一系列工作去交付的会议。这次会议需要4个小时到一整天。（P88）
sprint retrospective（冲刺回顾）：基于对开发团队实际绩效的回顾，帮助团队寻找提高产品和过程方法的会议。（P88）
sprint review（冲刺评审）：团队向产品负责人展示在一个冲刺内已经完成的会议。（P88）
stakeholder（干系人）：是指参与项目或者受项目活动影响的人，包括项目发起人、项目团队、支持人员、客户、使用者、供应商，甚至是项目的反对者。这些干系人对项目通常有着不同的需求和期望。（P8）
Start-to-finish dependency（开始-完成依赖）A relationship in which the “from” activity must start before the “to” activity can be finished. 任务A开始之前任务B不能完成。（P168）
Start-to-start dependency（开始-开始依赖）：A relationship in which the “from” activity cannot start until the “to” activity or successor is started. 任务A开始之前任务B不能开始。（P167）
strategic goal（战略目标）：强调组织的长期目标，组合管理强调战术目标。（P13）
structural frame（结构框架）：涉及组织是如何构建的（通常使用组织图表来说明），关注不同团队的角色和责任，以满足高层管理所设定的目标和政策。（P34）
sunk cost（沉没成本）：是过去已经花掉的钱，它就像沉船一样永远不会回来。当决定投资或继续投资哪个项目时，应该不考虑沉没资本。例如，在开篇案例中，假设在过去的3年里，胡安的办公室为一个地理信息系统开发项目已经花费了100万美元，但是没有做出任何有价值的东西。如果政府正在评估下一年资助哪些项目时，有人建议资助地理信息系统项目时，因为他们已经在该项目上花费了100万美元，这个提建议的人就是错误地把沉没成本作为项目选择决策的一个关键因素考虑了。当考虑一个失败项目花费多少钱时，许多人会继续投入因而掉进陷阱，这个陷阱其实就像赌徒因为已经输了钱而不想停止赌博一样。沉没成本应该被忘记，即使往往很难这样思考。（P196）
symbolic frame（符号框架）：着重于符号及含义。重要的不是实际发生了什么，而是意味着什么。（P34）
system analysis（系统分析）：是解决问题的一种方法，需要定义所研究系统的范围，然后将它分解成各个部分来确认与评估形影的问题、机会、约束和需求。（P32）
system approach（系统方法）：是指采用整体的和分析的方法来解决复杂问题，包括使用系统哲学、系统分析和系统管理等方法。
system development life cycle（系统开发生命周期）：是一个描述开发信息系统不同阶段的框架。包括可预测生命周期、迭代生命周期、增量生命周期、自适应生命周期、混合生命周期。
system management（系统管理）：包括处理与系统的创建、维护和改变相关的业务、技术和组织问题。（P32）
system philosophy（系统哲学）：是一整套系统地思考事物的思维方式。（P32）
system thinking（系统思维）：描述了在组织的北京中执行项目的整体观点。项目经理需要采用整体的观点，理解项目是如何与更大的组织进行关联的。（P32）
system（系统）：为达到某些目的而在一个环境中运行的、由相互作用的要素组成的集合。（P32）
T
tactical goal（战术目标）：比战略目标更具体、时间更短，单个项目强调战术目标。（P13）
tangible benefit（有形收益）：是那种很容易用货币来衡量的收益。（P196）
tangible cost（有形成本）：是那种很容易用货币来衡量的成本。（P196）
theory of constraints（TOC约束理论）：基于的事实是，就想一个有着最弱的链条的链子，任何复杂的系统在任何点上通常有一个方面或者约束限制它达到更多目标的能力。对于要活的任何重要的改进的系统，必须要确定约束，并必须牢记用它来管理整个系统。（P178）
three-point estimate（三点估算）：在PERT估算中用到。（P170）
Three-point estimates（三点估算）：包括估算最有可能的、乐观和悲观的项目成本。其次，项目团队使用在第6章中描述的PERT加权平均值公式，以一个简单平均数，或使用蒙特卡洛模拟，给出其处于乐观估计和最可能估计之间的概率。（P199）
top-down approach（自上而下法）：从项目最大的条目开始，将它们分解成次一级的条目。（P146）
top-down estimates（自上而下估算）：同类比估算（analogous estimate）。（P199）
total float（总浮动时间）：同总时差（total slack）。（P175）
total slack（总时差）：是一个活动从它最早开始时间起，在没有拖延计划项目完成日期的情况下被拖延的时间。（P175）
tracking Gantt chart（跟踪甘特图）：一个比较计划和实际项目进度信息的甘特图。（P173）
triple constraint（三项约束）：每个项目都会在不同程度上收到范围目标、时间目标和成本目标的约束。（P7）
U
Unit integration（单元集成度）：在组织中鼓励单元或者部门相互合作的程度。强单元继承父的组织文化使项目经理的工作更容易。（P37）
unknown unknowns（未知的不确定事件）：管理储备金（management reserve）中涉及。（P197）
use case modeling（用例建模）：是一种对业务事件、启动者及系统响应方式进行识别与建模的过程。这是一个理解信息系统需求的有效工具。
user story（用户故事）：用户简短的描述他们需要系统来为他们做什么。（P91）
V
Validating scope（验证范围）：项目可交付成果的正式接受。关键项目干系人（如项目的客户以及项目发起人）在这一过程中进行审查，然后正式接受项目的可交付成果。如果不接受现有的可交付成果，那么客户或项目发起人通常会请求做些变更。因此，该过程的主要输出有被接受的可交付成果、变更请求、工作绩效信息以及项目文档更新。（P134） 范围确认（scope validation）。
variance（偏差）：是计划的与实际的效果之间的区别。（P151）
virtual team（虚拟团队）：是指运用通信技术实现跨时间和跨地域工作的个人组成的团队。（P49）
W
waterfall life cycle model（瀑布式生命周期模型）：分析、设计、编码、测试、维护，线性，假定需求在定义以后能够保持稳定。应用条件：风险必须被严格控制，同时变更必须限制在需求定义后。（P44）
work breakdown structure（WBS工作分解结构）：为了度量和预测项目的执行情况，WBS同样提供了一个项目进度表和进行挣值管理的基础。（P77） 是对项目所涉工作面向交付成果（deliverable-oriented）的分组，他定义了项目的所有范围。使用的主要工具或技术是分解（decomposition）。（P141）
work package（工作包）：为WBS最底层的一项任务。（P143）