Fast forward mba
Fast forward MBA
Chapter 1
项目定義
项目被定义为仅进行一次且具有明确开始和结束的工作。此类工作可能与组织的持续运营形成对比，后者涉及重复性工作（例如制造或零售），但没有明确的目标
項目管理的要素
•从项目构想到完成与团队成员和利益相关者进行沟通。
•估算交付项目所需的工作量，成本和时间，并评估项目的收益是否可以证明预测的成本是合理的。
•快速建立具有凝聚力的项目团队，即使团队成员之前从未合作过。
•协调专门为一个项目组建的多样化员工的行动，以在合理的时间范围内以最小的费用实现目标。
•考虑进度和生产率，以准确预测项目完成日期和预算金额。
•管理不断并发运行的多个项目导致的各种人员需求，所有这些项目共享一个共同的人员库。
一个成功项目的最新定义是交付业务价值的项目
五个项目成功因素
1.项目团队，客户和管理层之间就项目目标达成协议。明确目标的重要性似乎显而易见，以至于提出它几乎是令人尴尬的。然而，此时此刻成千上万的项目还没有明确的目标，这种模糊的结果可能是毁灭性的。
2.可以显示总体路径和明确职责的计划，可以用来衡量项目期间的进度。由于每个项目都是唯一的，因此有效理解和执行项目的唯一方法就是制定计划。一个好的计划不仅显示出谁在什么时候什么时候负责，而且还表明了什么是可能的。它包含估计完成工作所需的人员，金钱，设备和材料的详细信息。而且由于计划是衡量进度的基础，因此它还可以作为对延迟或超出预算的任务的预警系统。
3.参与项目的每个人之间进行持续有效的沟通。人员（而不是计划或软件）完成项目。一个成功的项目是人们达成目标并达成目标的结果。从概念到实施，成功取决于达成协议，协调行动，认识和解决问题以及对变化做出反应的能力。
4.控制范围。情人眼中有成功。这就是为什么成功的项目经理从一开始就将确保所涉及的每个人都准确了解在给定的时间范围和预算内可以完成的工作。这被称为管理利益相关者的期望，这是整个项目中一项重要且持续的任务，尤其是在引入变更的情况下。利益相关者不仅必须同意项目的原始范围，而且必须了解范围的任何变化。
5.管理支持。项目经理很少有正式的权力来完成完成项目所需的所有决策。他们依靠具有传统管理角色的人员来提供人员和设备，制定政策决策并消除组织障碍。如果最热情，最有创造力和激励人心的项目负责人，如果不邀请有权力代表他们行事的人，也会跌倒
本书主要涉及以下方面：如何就目标达成共识，如何达成目标，如何招募团队成员和项目发起人，如何协商时间表和预算，以及如何降低风险和增加成功的几率。
checklist
1.项目团队，客户和管理层之间就项目目标达成协议。
•很明显，为什么这个项目值得。 该项目将实现的收益已经与有形和无形成本进行了权衡，我们知道这种紧迫性。 第4章介绍了项目建议书的最低内容。
•我们知道谁需要满足，谁来判断项目的成功。 第5章介绍了谁是我们的涉众以及如何找到他们。
•在宏观和微观层面都描述了交付的内容以及完成项目所需的行动。 第6章介绍了工作说明如何建立共同目标的共识。 第8章介绍了工作分解结构，任务和可交付成果的详细视图。
2.可以显示总体路径和明确职责的计划，可以用来衡量项目期间的进度。
•我们已为意外情况和超出我们控制范围的因素做好了计划。第7章演示了风险管理技术如何揭示潜在的威胁和机会，从而使团队能够主动影响或为这些未来事件做准备。
•通过详细了解要执行的工作以及任务之间的顺序关系来构建时间表。第8章和第9章使用分步方法来分解项目并制定切实可行的时间表。
•时间表基于合理分配的工作，并且负责工作的人员没有负担过重。第9章提供了任务估计准则和资源均衡的解释，它是评估计划表的过程，以发现在任何时间段内不切实际的工作分配。在第14章中查找有关传达清晰任务分配的提示。
•以稳定的节奏衡量计划的进度。第16章包含用于根据成本和进度基准来计算进度的公式。第10章概述了计划和监视项目的Scrum方法。
3.参与项目的每个人之间进行持续有效的沟通。
•我们知道谁将积极参与该项目以完成工作并做出决定。第5章介绍了利益相关者的识别技术，第6章介绍了明确项目角色的RACI矩阵。
•我们的项目团队有相互信任和承诺，可以互相说出真相并共同解决问题。具有凝聚力的项目团队的属性在第13章中进行了描述。
•我们准备为将受到项目变更影响的人提供帮助，以帮助他们实现项目目标。第14章介绍了变更管理的纪律。
•我们的项目基础结构包含风险日志，问题日志，可见的时间表以及团队成员可以轻松访问和更新的其他实用方法。第14章着重于团队沟通，第22章介绍了利用Microsoft Project和SharePoint工具的技巧。
•我们建立了适合于项目规模和进度的项目报告节奏，并将使我们的团队和管理层保持同步。第14章和第16章介绍了以图形方式报告状态的沟通计划和指南。本书中的每种技术都可以促进项目涉众之间更有效的沟通！
4.控制范围。
•已采用一种实用的方法来记录和管理需求，因此我们可以满足实际的业务需求。第19章介绍了需求工程的学科，解释了各种需求以及每种需求如何帮助我们朝目标迈进。
•我们知道谁必须批准对进度和成本的更改，以及团队有权接受规范和范围的更改。批准变更的人员已同意该流程，因此将及时处理变更请求。第15章介绍了在所交付的，所花费的成本以及何时到达之间保持适当平衡的步骤。
•使用从过去类似项目开发的可靠模型来创建成本和进度估算和承诺。在第11章中了解用于进行准确估算的技术。第18章介绍了项目管理办公室在创建可重复的项目管理实践中的作用。
•当我们的假设被证明是错误的时，我们对偏离计划的可能性抱有现实的期望。第12章介绍了追赶，削减成本以及在成本，进度和质量之间取得平衡的各种策略。第17章包含经典的项目问题和合理的答案。
5.管理支持。
•项目发起人对项目成功负责，并计划定期与项目经理会面，以期提供支持和指导。在第5章中了解项目发起人的角色和责任。
•具有适当技能和可用性的人员已分配给该项目。第9章中的计划过程，尤其是任务估计，揭示了必要的技能。职能经理负责分配人员到项目中，这将在第5章中进行讨论。
•我们的赞助商和管理团队已与客户和其他主要利益相关者见面。所有人都致力于定期交流。第14章介绍了项目沟通计划和团队启动。
•设置了上报阈值，以将问题和风险提高到适当的管理水平。我们知道，在高层管理人员介入之前，我们会考虑成本和进度差异。第16章介绍了成本和进度差异边界如何创建升级阈值。
6.战略调整驱动优先级。
•该项目相对于公司中的其他项目具有优先级和顺序，因此已分配有足够的资源来完成该项目。 第18和20章讨论了多项目管理因素，包括项目组合管理。
7.技术能力和成熟的开发实践。
•我们的团队拥有最新技能。 第8、9和11章中有关计划和估算的技术揭示了完成工作所需的技能。
•我们使用行业最佳实践来阐明客户的目标，并设计，构建，测试和交付出色的产品和服务。 在第3章中了解传统的和迭代的开发生命周期以及一致的开发方法的好处。
chapter 2
以下是项目经理面临的一些挑战：
•人员。每个项目都有不同的人员需求。每个项目所需的人数和他们的不同技能有所不同。这些人来自哪里？一旦不再需要它们，它们会去哪里？如果多个项目同时运行，这些人员配置问题可能会更加复杂。如果所有项目同时达到资源高峰，则可能给组织带来不必要的负担。而且，如果所有项目都应在同一时间结束，则公司可能会被迫裁员。
•估计。为了评估潜在项目，组织需要准确的成本和进度估算。但是由于每个项目都不同，所以估算可能包含的假设要多于事实。
•权限。组织结构图定义了企业内部的权限，但是它们通常代表企业的持续运营。当项目跨越组织边界时，将不再清楚谁拥有许多决定的权限。这可能会导致政治动荡和阻碍进展的僵局。
•控制。正常会计惯例每季度或每年将运营预算与运营成本进行匹配。但是这些时间框架不足以使项目保持进度。到季度会计报告显示某个项目超出预算时，它可能已经失控，无法恢复。
设计并制造了第一枚原子弹的曼哈顿项目，通常被认为是使用现代项目管理技术的第一项目
他们的名字-程序评估和审查技术（PERT）和关键路径方法（CPM）-如今仍然广为人知
program evaluation and review technique (PERT) and critical path method (CPM)
项目管理已从不被认可的技能迅速发展为公认的专业，并获得了学位和证书。但是一个关键问题仍然存在：项目管理可以独立于技术专业而理解和应用的一组知识和技术？有效领导项目需要多少技术知识才能？ John Roebling可以设计布鲁克林大桥，然后雇用没有工程技能的项目经理来完成它吗？
项目经理在三个不同领域需要技能：
1.项目管理。 这是本书中描述的纯粹的学科。
2.业务管理。 谈判，财务，客户招募，组织发展，沟通和激励是任何优秀经理人都应具备的技能，无论是管理项目还是运营。
3.技术。 几乎每个为项目经理开发职业道路的公司都从技术能力入手。 无论是会计，广告，计算机芯片还是输油管道，负责这项工作的人员都需要全面了解。 但是，这些职业道路并不要求候选人需要团队中最好的技术人员担任项目负责人。
项目经理更有可能在小型项目上涉及技术决策，但是即使在大型项目上，经理也需要了解正在执行的工作。 如果他们不这样做，他们也许可以充当促进者，推动者，激励者和拉拉队长，但他们将无法理解或参与解决技术问题。 “好，”您可能在想。 “我不想参与详细工作。” 但是不了解所管理技术的项目经理可能会失去团队的信心，尤其是对以其技术能力感到自豪的团队。
成功的定义
启动每个项目是为了对组织进行重要更改。可以通过时间，预算和质量的成功标准来了解该更改是否真正有价值。
准时。该产品按计划交货。如果没有按时完成，某些项目就毫无价值。例如，运行奥运会所需的信息技术（IT）基础设施如果还没有准备好，直到运动会完成，就不好了。
在预算内。该项目符合预期的成本估算。项目是投资，那些超出预算的项目最终会使组织付出更多的成本。
高质量。项目的成果必须满足客户的使用期望。质量通常很难定义，而度量要比按时间或按预算困难得多。 “适合使用”（约瑟夫·朱兰）和“符合要求”（菲利普·克罗斯比）是两个常见的定义。对于项目经理，质量有两个组成部分：
1.产品范围。范围是产品应该执行的操作。飞机要载多少人？医院一侧将有多少间手术室？该网站将具有哪些功能？
2.性能。衡量功能运作情况的指标。例如，比较豪华轿车和经济型汽车中的音频系统。两者都可以无线连接到手机的音乐（一项功能），但听起来可能要好得多。
产品范围和性能可以并且应该在项目早期指定。如何指定它们取决于构建的内容。例如，医院再造项目的过程要求将与商用飞机的新模型的要求记录不同。第19章提供有关就需求达成共识的建议
新的项目经理成功公式：
1.对与项目所有利益相关者的成本—进度—质量平衡制定切合实际的期望，并将这些约束条件与用于证明项目合理性的业务案例联系起来。
2.在整个项目中管理期望。如果平衡发生变化，请确保每个人都知道并接受新的平衡。
3.如果在任何时候似乎都无法达到成本进度计划的质量目标，请重新评估该目标。
4.在预算内按时交付承诺产品。
项目管理功能
设定切合实际的期望，在各方之间达成共识，然后交付产品通常具有挑战性，并且始终需要多种技术（请参见图2.2）。从较高的层次上讲，这些技术可以分为三个项目管理功能：
1.项目定义奠定了项目的基础。此基础工作涉及两项活动。
•项目经理必须确定项目的目的，目标和约束。他或她必须回答诸如“我们为什么要这样做？”之类的问题。和“成功意味着什么？”答案成为制定所有项目决策的基础，因为它们描述了成本计划的质量平衡，并将项目与组织的使命联系在一起。
•经理必须建立基本的项目管理控制。他或她必须就哪些人和组织参与该项目以及他们将扮演的角色达成协议。经理还需要阐明命令链，沟通策略和变更控制过程。记录下来的对这些决策和策略的接受传达了对项目管理方式的期望。它也成为您可以参考的协议，以使每个人对他们在项目中的责任负责。
可以将定义过程中产生的书面文档定义为项目规则，因为像任何游戏规则一样，它们概述了玩法和获胜所需的条件。
2.在有限制的情况下，项目计划汇总了如何实现项目目标的详细信息。常用的估算和调度技术将列出项目需要多少工作，谁来完成工作，何时完成以及花费多少。在此过程中，风险管理活动将确定最大不确定性的领域并制定策略来管理它们。计划中提出的详细策略成为对项目定义期间制定的成本－计划－质量平衡的现实检查。
3.项目控制包括使项目朝着目标前进的所有活动。这些活动包括：
•进度测量。衡量进度经常可以尽早发现问题，使其更容易解决。进度测量也是一种反馈机制，可验证计划中的估算和成本进度质量平衡。
•沟通。沟通对于控制项目至关重要，因为沟通可以使所有参与者保持协调并了解项目的进度和变更。
• 纠正措施。这包括对项目可能遇到的所有障碍和问题的日常响应。
项目生命周期
项目生命周期表示从定义项目到制定计划，执行工作以及结束项目的线性过程（请参见图2.3）。乍一看，这个生命周期似乎与项目管理功能相同。定义，计划和执行似乎直接映射到定义，计划和控制。区别在于生命周期是线性的，而相界代表决策点。让我们更仔细地看一下这四个决策点：
1.定义。该阶段从在项目章程中命名项目和项目经理开始，并在批准项目规则后完成。批准此书面文件意味着所有有关方面都同意项目目标，方法和成本进度质量平衡。
2.计划。规则获得批准后，项目经理将开始制定项目计划。当然，随着如何执行项目的细节得以制定，项目规则中的某些决策可能会发生变化。在计划阶段的最后，所有各方都必须不仅批准计划，而且还必须批准项目规则的任何必要更改。
定义和计划可能是短暂的阶段，尤其是对于短期项目。由于计划通常会更改项目规则，因此在完成定义和计划之前可能会有一些迭代。这吸引了一些公司将这些活动混合到一个阶段。保持阶段分离的最佳论据是，在制定详细计划之前，需要在定义阶段回答许多问题。定义期间制定的基本假设和协议使计划活动更加集中和富有成效。
3.执行。我们现在处于执行计划中批准的实际工作的阶段。这个阶段可能需要该项目90％或更多的工作。当达到项目目标时，执行阶段就完成了。
4.收尾。这是项目的最小阶段，但同其他阶段一样重要。结束活动具有三个重要功能：（1）过渡到下一阶段，无论是运营阶段还是另一个产品开发阶段； （2）在客户眼中确定项目的正式关闭； （3）审查项目的成败，以改进未来的项目。
产品开发生命周期
项目管理技术越来越受欢迎的原因之一是由于它们在新产品开发中的作用。无论是新药，新软件产品，新模型汽车还是新棒球场，这项工作一次完成即可生产出独特的产品。由于产品开发具有与项目相同的特征，因此创建这些新产品为应用项目管理提供了绝佳的机会。创建新产品所需的步骤称为产品开发生命周期。第3章提供了一些示例，说明如何根据所创建的内容来更改产品开发生命周期。为了便于讨论，本书将使用一个简单的，分为四个阶段的过程，重点介绍开发过程中最常见的活动：
1.要求。此步骤定义了产品的功能和性能要求。无论您要盖房子，飞机还是信息系统，需求都描述了产品如何满足客户的需求。
2.设计。设计构思的产品将满足要求，并对其进行详细描述。例如，蓝图是房屋的详细描述。
3.构建。接下来，构建产品，并编写其操作所需的所有文档。如果正在建造建筑物，这里就是工人挖洞并钉子的地方。对于新型飞机，建造过程可能涉及广泛的活动，包括创建新的制造工艺。 （在这种情况下，该产品不完全是一架新飞机，而是建造飞机的新过程。）
4.操作。产品开发完成后，就有其实际使用的寿命。然后，项目变成正在进行的运营：棒球场举行比赛，制造过程生产出新车，或者软件产品公司为用户提供支持。操作阶段可能持续数年，并且可能包含许多项目。
第3章详细阐述了一致的开发过程在创建有用的产品和服务以及适用于创新的新开发方法的演进中所扮演的角色。
即使被简化，产品开发生命周期模型（如图2.4所示）也可以用作概念模型，以显示产品开发生命周期和项目生命周期之间的基本差异。
产品生命周期与项目生命周期
尽管新产品开发（如项目）具有起点和终点并产生独特的产品，但它可能包含多个项目（见图2.5）。 希望将项目管理应用于新产品开发的任何人都必须了解产品生命周期与项目生命周期之间的区别： •产品开发生命周期描述了创建产品所需的工作。 项目生命周期专注于管理工作。 •产品开发生命周期可能包含许多项目，每个项目都必须经历整个项目生命周期。 理解任何开发工作都可以包含多个项目，并且每个项目都需要作为一个完整的项目进行管理，这是项目管理成功的关键之一。
組織結構
==这个好像我们公司，上面是ceo，下面是cto，和evp，分别负责technology和business unit==
==我们公司的职能经理管人，也管项目的推动和执行，也管技术管理==
==产品部门更像是project based？ 他们有自己的财务，工程，生产？==
组织项目
某些公司只执行项目工作；大型建筑公司采用了这种模型。他们的组织大部分致力于特定项目。另一方面，实用程序是面向操作的。但是，大多数公司正在进行正在进行的运营和项目。
创建支持项目的组织结构从未如此简单。毕竟，如果一个项目仅发生一次，需要独特的人员组合，并且具有独特的报告结构，那么任何公司如何创建一个组织结构图，该组织结构图将持续到下一个项目的结束？尽管项目可能会破坏组织结构图，但多年来，组织对项目环境做出了一些经典的反应（见图2.6）。以下一系列组织风格偏向于一方面持续进行业务，另一方面偏向于项目。
功能驱动的公司围绕主要功能组织，例如广告，工程，信息系统，制造和人力资源（见图2.7）。==工人只有一名经理，他既负责分配和监视工作，又处理行政任务，例如薪酬==。职能组内的项目不会造成组织上的问题，但是跨职能组的项目很难管理，因为项目经理没有职能权限，并且必须通过职能经理来分配，监视和协调工作。
当许多项目跨越功能边界时，就需要矩阵组织。这种结构使项目经理和职能经理都向同一主管报告，从而赋予他们权力（见图2.8）。职能经理将参与决定谁将在项目团队中工作，并对长期的管理问题负责。项目经理在项目团队成员之间分配，监视和协调工作。矩阵组织的主要问题在于，每个从事项目工作的人都有两个老板–如果这些人从事多个项目，他们将拥有更多。
面向项目的组织适合从事大型，长期项目的公司。==不是在职能部门内部或内部找到项目，而是在项目内部存在职能部门==（见图2.9）。面向项目的公司（也称为预测性公司）在多个项目中可能会有多余的运作，但是他们愿意忍受这种组织效率低下的情况，以最大程度地提高每个项目的管理效率。例如，在重型建筑行业中，这些公司建立了一个整个组织来管理其庞大项目的每个方面。
面向项目的组织的另一种样式是程序。程序由许多相关项目组成，但是与单个项目不同，它们没有特定的预期完成日期。例如，当波音公司开发一种新型飞机时，该公司建立了一个程序，负责从销售飞机到开发客户服务流程的所有工作，这是一系列单独但相关的项目。该计划的一个变体是面向产品的结构，该结构使用公司的产品作为驱动组织因素。以产品为导向的组织为每个产品组织复制了功能学科，例如市场营销和产品开发。例如，一家软件公司的营销，开发和测试人员被分配给特定的产品组，例如文字处理和电子表格组
==项目：包含各种职能，比如财务，销售，研发，产品，生产==
==职能：比如研发==
==我们R&D更类似于功能驱动==
职能经理VS项目经理[ 编辑]
职能经理和项目经理在组织中具有不同的角色和职责。职能经理负责管理部门或部门内具有特定技能和不同资源的人员，以满足职能目标和公司目标。项目经理必须将具有不同职能和特定技能的人员召集在一起，以在规定的时间内完成专门的任务。[5]有时，职能经理和项目经理必须共同努力，以共享资源和经验。这可能有助于提高效率和整体性能。[6]
工程项目经理[ 编辑]
在工程学中，项目管理涉及在开发和制造阶段中查看产品或设备，与工程和制造不同领域的各种专业人员合作，从概念到最终产品。（可选）这可以包括不同国家/地区要求的不同版本和标准，从而需要了解法律，要求和基础结构。
成功的项目可以按时，按预算交付高质量的产品。但是，项目经理需要意识到，参与项目的每个人（所有利益相关方）都必须就成功的意义达成共识。==管理期望是项目经理的主要工作之一==。成功取决于经理在整个生命周期中指导项目的四个阶段：定义，计划，执行和结束。
产品开发生命周期描述了创建产品所需的工作，而项目生命周期则侧重于管理工作
CHAPTE R 3 Build Great Products: Lessons from Agile, Lean Start-Up, and Stage-Gate
经过投入到项目中的所有努力之后，我们实际上产生了令人满意的东西吗？结果的好处是否超过了开发的成本？我们实现了预期值吗？
在我们创建产品和服务时，实现价值目标始终是一个挑战。项目团队需要准确地确定应该构建的内容，然后正确构建它。无论我们是在进行住宅改建，将新药推向市场还是扩大网上银行服务，这都是事实。我们把从需求发现到构建和更新的整个过程称为产品开发生命周期或产品开发过程。
Why need Development Process？
发过程可降低风险并提高可重复性
明确的开发过程可导致可重复性，并专注于按特定顺序执行的正确工作。每个阶段都可以有一个完成清单，这是一种整合从过去项目中学到的经验教训的方法。可以制定标准的工作准则和可交付的示例，以使每个项目团队至少都像以前的团队一样进行工作。
在第8章中，我们将介绍“工作分解结构（WBS）”一词，它是项目任务的完整列表。开发过程通常在项目的每个阶段都包含一个标准的WBS。这个共同的任务清单可以加快规划速度，并确保每个项目都覆盖所有基础，尤其是那些涉及质量保证的基础。
一致的开发方法是准确估算的基础。当每个项目具有相同的阶段和任务时，按阶段和按任务收集实际的成本和进度绩效信息将变得更加容易和有意义。过去项目的实际绩效数据可以更轻松，更准确地估算未来项目。 （在第9章中了解有关估算的更多信息。）
发过程不是项目管理
开发过程与项目管理之间有着密切的关系，但是我们必须清楚它们是两个不同的互补过程。开发过程说明了什么是工作以及如何正确进行。项目管理强调沟通和协调的大小，以便有效地执行工作。
什么时候最合适增量交付？
当难以确定需求时，增量交付是适当的；当客户似乎在说：“我无法确切地说出我想要什么，但是当我看到它时，我就会知道。”对于创新项目来说，这也是有用的生命周期，其目标是引入没有人要求的东西，但是如果他们看到了，他们可能会真正想要。
The Planning process
I keep six honest serving men (They taught me all I knew);
Their names are What and Why and When And How and Where and Who.
—**Rudyard Kipling
我养了六个诚实的服役人员（他们教会了我我所知道的一切）；
他们的名字是什么，为什么，何时何地，何时何地，谁。
-**吉卜林
Risk Management: Minimize the Threats to Your Project
风险管理是系统地管理不确定性以增加实现项目目标的可能性的方法
图7.1显示了计划的功能，它具有两个主要组成部分：风险管理以及进度和预算制定
FIGURE 7.2 Project risk management.
• 图7.2描述了在整个项目中重复进行的风险管理过程：
• •确定风险。系统地找到威胁项目目标的所有因素。
• •分析并确定优先级。根据可能的损害和发生的可能性评估每种风险。大多数项目具有巨大的潜在风险。量化潜在损害和风险发生的可能性使团队能够确定风险的优先级，将注意力集中在最能发挥作用的地方。
• •做出回应。创建策略以减少可能的损害和/或发生风险的可能性。
• •建立储备金。为该项目预留额外的资金，以在发生特定风险（已知风险）时使用，以及为未知风险提供资金。
• •持续的风险管理。实施策略并监控这些更改对项目的影响。风险策略在生效时可能需要进行微调。在发现新风险，避免已知风险并花费风险准备金时与利益相关者进行沟通。
收集風險：头脑风暴會議：
人員：确保包括客户，赞助商，团队成员，分包商，职能管理人员以及从事过类似项目的人员
| 潜在风险 | 条件 | 后果 | 大小和概率 | 简单的答案 Strategy |
|---|---|---|---|---|
墨菲的风险管理法
识别风险的技巧始于批判的态度。 因为我们正在尽力发现问题，所以首先应该采取“任何可能出错的地方都会出错”的态度
包括所有观点 人们根据项目角色为项目带来不同的观点。 确保包括客户，赞助商，团队成员，分包商，职能管理人员以及从事过类似项目的人员。 他们都参与了该项目，他们将很高兴借此机会帮助确保项目的成功。
Example: Risk Profile Questions
\1. How many people are on the team?
\2. What percentage of the team is fully dedicated to the project?
\3. Which team members will spend 20 percent or less of their time working on this project?
\4. What is the experience level of the team?
\5. Have team members worked together before?
\6. Is the team spread out geographically?
1.团队中有多少人？
2.团队中有多少百分比完全致力于该项目？
3.哪些团队成员将花费20％或更少的时间从事此项目？
4.团队的经验水平如何？
5.团队成员之前曾合作过吗？
6.团队是否在地理上分布？
\1. Will the customer change current processes to use the product? (No) (Minor changes) (Major changes)
\2. Will the project require the customer to reorganize? (No) (Minor changes) (Major changes)
\3. Are the customers in different departments? In different companies?
1.客户是否会更改当前流程以使用该产品？ （否）（较小更改）（重大更改）
2.项目会要求客户进行重组吗？ （否）（较小更改）（重大更改）
3.客户在不同部门吗？ 在不同的公司？
\1. Will there be technology that is new to the development team?
\2. Will there be technology that is new to the users or customers?
\3. Is there any new or leading-edge technology in the project?
\4. Are the product requirements clearly documented and signed by all necessary stakeholders?
\5. Are the product requirements stable?
1.开发团队是否会有新技术？
2.是否会有对用户或客户来说是新技术？
3.项目中是否有任何新技术或领先技术？
4.是否所有必要的利益相关者都清楚地记录了产品要求并签署了产品要求？
5.产品要求是否稳定？
\1. Is there a known project sponsor who is actively involved in the project?
\2. Is there sufficient recognition, support, and involvement from all the senior management required for the success of the project?
\3. Is senior management setting deadlines or budget limitations independent of the project manager’s schedule and budget estimations? If so, are these constraints realistic?
• Develop categories of risk; then list several questions for each category.
• Each question probes at a possible weakness.
• Add new categories and questions over time.
1.是否有一位知名的项目发起人积极参与该项目？
2.项目成功是否需要所有高级管理人员的充分认可，支持和参与？
3.高级管理层是否设置了截止日期或预算限制，而不取决于项目经理的进度和预算估计？ 如果是这样，这些约束是否现实？
•制定风险类别； 然后针对每个类别列出几个问题。
•每个问题都会探讨可能存在的弱点。
•随着时间的推移添加新的类别和问题。
Work Breakdown Structure: Break Your Project into Manageable Units of Work
work breakdown struc ture (WBS)