项目管理作业讲解-精品文档
PDCA循环在项目质量管理中的应用[精品资料]
![PDCA循环在项目质量管理中的应用[精品资料]](https://img.taocdn.com/s3/m/89cf8d380166f5335a8102d276a20029bd64637f.png)
PDCA循环在项目质量管理中的应用-精品资料本文档格式为WORD,感谢你的阅读。
最新最全的学术论文期刊文献年终总结年终报告工作总结个人总结述职报告实习报告单位总结摘要：随着市场经济的发展，建筑业也迅速发展，在这过程中，施工项目质量管理显得相当重要。
工程质量不仅关系到工程适用性和项目成本效果，而且关系到人民群众生命财产安全。
作为施工单位，工程质量的好坏，将直接影响着企业的发展。
本文通过对目前施工项目质量管理方面存在问题的分析，论述了PDCA循环、项目质量管理等理论知识，结合实际工程项目案例，采用理论联系实际方法，将PDCA循环理论有效地运用于项目质量管理中，优化项目质量管理，对促进工程项目质量管理水平的提高，具有重要的现实意义和指导性。
关键词：项目质量管理； PDCA循环F037 A1、项目质量管理研究的背景与意义近年来，随着我国国内市场经济的高速增长，建筑业也得到了迅猛的发展，加上参与工程项目实施各方对工程项目质量意识的不断提高，使得建筑施工企业的项目质量管理也越来越凸现其在企业管理中的重要性。
众所周知，靠质量树信誉，靠信誉拓市场，靠市场增效益，靠效益求发展，是企业生存和发展的生命链。
而建筑施工项目质量的优劣，不仅关系到工程的适用性和项目的成本效果，而且还关系到人民群众的生命财产安全和社会的安定。
作为施工单位以质量求生存无疑是铁的定律，质量是企业发展的生命线。
尽管如此，目前，大多数建筑施工企业项目质量管理中仍存在着种种问题，而解决问题的关键在于管理，尤其是施工过程的管理。
戴明博士的PDCA理论为我们提供了基本的理论指导，通过深入探讨和研究，对提高整体管理水平，具有一定的现实意义和指导性。
2、我国施工项目质量管理的现状多年来，我国一直强调必须贯彻“百年大计，质量第一”的方针。
这对建立和发展社会主义市场经济和扩大对外开放发挥了重要作用。
但近几年出现的楼倒、路陷、桥坍等恶性事故，不能不引起高度重视，质量重于泰山。
《项目管理》作业4满分答案
《项目管理》作业4满分答案项目管理作业4满分答案
本次作业中，我们研究了项目范围管理以及工期管理的相关知识，以下为满分答案：
项目范围管理
问题1：请列出项目范围管理计划的主要组成部分。
答：项目范围管理计划主要包括以下组成部分：
- 范围定义
- 工作分解结构(WBS)
- 范围确认
- 范围变更控制
- 范围验收
问题2：工作分解结构是什么？它的作用是什么？
答：工作分解结构(WBS)是将项目划分为不同的阶段和可管理
的组成部分的可视化工具。
它可以帮助项目经理更好地管理项目，
为项目的实施提供指导。
问题3：请解释计划范围管理和控制范围的主要区别。
答：计划范围管理主要是确定如何定义、确认和监控项目范围；而控制范围则是确保范围只能在经过批准的情况下进行变更。
简而
言之，即计划是早期的文档和计划，而控制是项目执行过程中的操作。
工期管理
问题1：请列出工期管理的步骤。
答：工期管理的步骤包括：
- 制定项目时间管理计划
- 定义活动
- 序列活动
- 估算活动资源
- 估算活动持续时间
- 制定进度计划
- 控制进度
问题2：请解释网络图及其作用。
答：网络图是一种可视化工具，用于表示项目活动的关系和依赖关系。
网络图可以帮助项目经理更好地计划时间，并在执行过程中更好地控制进度。
问题3：请列出项目进度管理中使用的工具和技术。
答：项目进度管理中使用的工具和技术包括：
- 网络图
- 决策树分析
- 资源优化技术
- 压缩工期技术
以上是本次作业的满分答案，如有任何疑问，请及时沟通。
EPC工程总承包项目管理方案(工程方案、实施方案)
EPC工程总承包项目管理方案（工程方案、实施方案）总承包管理方案目录第一章总承包管理总体概述 (4)1.1总承包管理概述 (4)1.2 工程概况 (4)第二章总承包管理与服务目标 (4)2.1总承包管理目标 (4)2.2 总承包服务目标 (6)第三章总承包管理原则 (8)3.1 “公正”原则 (8)3.2“科学”原则 (8)3.3“统一”原则 (8)3.4“控制”原则 (9)3.5“协调”原则 (9)第四章总承包管理模式 (10)第五章总承包管理服务架构 (11)5.1 总承包管理服务组织机构 (11)5.2 组织机构岗位设置 (11)第六章总包与业主、监理、设计、政府部门的配合 (24)6.1 协调好与业主的关系 (24)6.2协调好与设计院的关系 (26)6.3协调好与监理单位的关系 (27)6.4与相关政府部门协调配合 (29)第七章总承包管理方案 (30)7.1 总承包管理的方法 (30)7.2 工程总承包质量管理方案 (31)7.3 工程总承包进度管理方案 (51)7.4 工程总承包施工安全生产管理 (60)7.5 文明施工管理 (72)7.6 施工期间的环境保护方案 (77)7.7工程总承包造价管理实施方案 (84)7.8 工程总承包协调管理 (90)7.9 工程总承包总体服务方案 (94)7.10 工程总承包信息化管理 (101)7.11 工程总承包竣工验收管理 (120)第一章总承包管理总体概述1.1总承包管理概述总承包管理是国际上流行的一种项目管理模式，运用总承包管理模式可以有效的加强项目的整体管理，缩短工期，降低总体项目成本，提高投资效益。
施工总承包管理在时间上涵盖了从建设项目开工至竣工交付使用及保修服务的全过程，在范围上涵盖了参与建设项目施工各方及一切有关的管理活动，实施施工总承包管理既是高质高效完成施工项目的有效手段，也是涉及人、财、物等多种生产要素及服务对象的复杂的管理活动。
图解项目管理
团结 信赖 创造 挑战
精品文档
第一章 引论
欢迎下载
欢迎使用
团结信赖
吴永达，PMP
吴永达 团结 信赖 创造 挑战
项目特点
临时性 独特性 渐进明细
吴永达 团结 信赖 创造 挑战
项目和运营
精品文档
欢迎下载
项目
工作性质：独特，创新 工作环境：开放，风险 管理组织：临时，变化 目 的：结束项目
欢迎使用
团结信赖
运营
工作性质：常规，重复 工作环境：封闭，确定 管理组织：稳定，持久 目 的： 维持经营
吴永达 团结 信赖 创造 挑战
项目制约要素
范围 精品文档
欢迎下载
欢迎使用
质量
进度 团结信赖
成本
吴永达 团结 信赖 创造 挑战
项目管理知识领域
项目管理
4.项目集成管理
4.1 制定项目章程
4.精2 制品定文初档步范围说明书欢迎下载职能型Fra bibliotek弱矩阵
矩阵型 平衡矩阵
强矩阵
项目型
项目经理权力 很小或没有 有限
小~中等 中等~高 高到全权
资源可利用率 很小或没有 有限
小~中等 中等~高 高到全权
谁控制 项目预算
项目经理 的头衔
项目管理 资源投入
职能经理 职能经理
混合
项目经理 项目经理
促进者/协调 促进者/协
者
调者
项目经理
项目经理 项目经理
人力资源库 事业环境因素
方针、程序、标准
和原则的制定过程
组织过程资产
历史信息 吸取的教训
客户
组织过程资产（更新） 最终产品、服务、成果
项目管理_精品文档
第32题(2.0) 分理想状态下，项目经理应该在下列哪个过程选定与委派？1．第1题在项目管理中时常会发生各类冲突，以下哪种冲突对项目影响最大？B.进度计划3．第4题高层管理什么时候进行定期项目审查？B.每一个生命周期阶段完成时4．第5题下面哪些是学习曲线的限制？B.成本数据无法及时获取5．第6题承包商已经根据客户的要求执行了项目。
在项目结束时，客户在最后验收前要求较小的范围蔓延。
下面哪种是可以使双方都满意的解决方法？D.让项目组研究变更申请的备选方案6．第7题项目的工作技术工程师决定选用流程图来解决工作流程问题。
她要展示说明导致问题的各种主要原因和次级原因。
她最可能用什么流程图？C.成本利益分析图7．第8题项目团队原来有6个成员，现在新增加6个。
沟通渠道增加了多少？B.4.4倍8．第9题顾客把原定的项目范围扩大了65%，这也使成本估算上升了5倍。
现在你必须更改已经获得批准的项目开始和结束的时间安排。
你第一步要做的应该是C.使用一个新的进度安排表9．第10题估算项目历时，如果采用PERT技术产生的缺点是B.工作量加大10．第11题公开资源通常包括以下哪些？A.财力B.人力C.设备与设施D.以上皆是12．第13题根据项目的（）进行项目风险评价是极实用的C.工作分解结构13．第14题面向任务的活动关系树是（）。
C.工作分解结构14．第15题导致一个组织发生冲突的条件是A.利益冲突B.组织内的区别D.A和B15．第16题下面哪一项能够提高项目成本估计的准确度？A.以工作分解结构中的低水平工作定价B.利用近期的历史数据和档案数据C.和曾经在类似项目中工作过的人交谈D.以上皆是16．第17题大多数项目驱动型的公司会认为下列哪一项是频率最高的冲突？A.时间安排和优先级第19题(2.0) 分CPI值为0.89表示。
D你对项目的每美元投资中只收回89美分第31题(2.0) 分以下哪项提供了基于项目绩效的项目总体预期成本？C.EAC17．第18题非正式沟通在项目组织中时常传播小道消息，对项目目标带来不良的影响。
PDM项目软件需求管理【精品文档】
Writing Good RequirementsAll too often, software requirements are badly written and hard to follow. Clarifying your specifications will benefit everyone involved.by Karl Wiegers. Software Development Magazine, May, 1999It looks like your project is off to a good start. Your team had customers involved in the requirements elicitation stage and you actually wrote a software requirements specification. The specification was big, but the customers signed off on it, so it must have been O.K.Now you’re designing one of the features and you’ve found some problems with the requirements: You can interpret requirement 15 a couple different ways. Requirement 9 states precisely the opposite of requirement 21; which should you believe? Requirement 24 is so vague that you don’t have a clue what it means. You just had an hour-long discussion with two other developers about requirement 30 because all three of you thought it meant something different. And the only customer who can clarify these points won’t return your calls. You’re forced to guess what many of the requirements mean, and you can count on doing a lot of rework if you guess wrong.Many software requirements specifications (SRS) are filled with badly written requirements. Because the quality of any product depends on the quality of its raw materials, poor requirements cannot lead to excellent software. Sadly, few software developers have been educated about how to elicit, analyze, document, and verify requirement q uality. There aren’t many examples of good requirements to learn from, partly because few projects have good ones to share, and partly because few companies are willing to place their product specifications in the public domain.This article describes several characteristics of high-quality software requirement statements and specifications. I will examine someless-than-perfect requirements from these perspectives and take a stab at rewriting them. I’ve also included some general tips on how to write good requirements. Evaluate your project’s requirements against these quality criteria. It may be too late to revise them, but you might learn how to help your team write better requirements next time.Don’t expect to create a SRS in which every requirement e xhibits every desired characteristic. No matter how much you scrub, analyze, review, and refine requirements, they will never be perfect. However, if you keepthese characteristics in mind, you will produce better requirements documents and you will build better products.Characteristics of Quality Requirement StatementsHow can you distinguish good software requirements from problematic ones? Individual requirement statements should exhibit six characteristics. A formal inspection of the SRS by project stakeholders with different perspectives is one way to determine whether or not each requirement has these desired attributes. Another powerful quality technique is writing test cases against the requirements before you cut a single line of code. Test cases crystallize your vision of the product’s behavior as specified in the requirements and can reveal omissions and ambiguities.Characteristic #1: They must be correct. Each requirement must accurately describe the functionality to be delivered. The reference for correctness is the source of the requirement, such as an actual customer or a higher-level system requirements specification. A software requirement that conflicts with a corresponding system requirement is not correct (of course, the system specification could be incorrect, too).Only users can determine whether the user requirements are correct, which is why it’s essential to include actual users, or surrogate users, in requirements inspections. Requirements inspections that do not involve users c an lead to developers saying, “That doesn’t make sense. This is probably what they meant.” This is also known as “guessing.”Characteristic #2: They must be feasible. You must be able to implement each requirement within the known capabilities and limitations of the system and its environment. To avoid infeasible requirements, have a developer work with the requirements analysts or marketing personnel throughout the elicitation process. This developer can provide a reality check on what can and cannot be done technically, and what can be done only at excessive cost or with other trade-offs.Characteristic #3: They must be necessary for the project. Each requirement should document something the customers need or something you need to conform to an external requirement, an external interface, or a standard. You can think of “necessary” as meaning each requirement originated from a source you know has the authority to specify requirements. Trace each requirement back to its origin, such as a use case, system requirement, regulation, or some othervoice-of-the-customer input. If you cannot identify the origin, perhaps the requirement is an example of gold-plating and isn’t really necessary.Characteristic #4: They must be prioritized. Assign an implementation priority to each requirement, feature, or use case to indicate how essential it is to a particular product release. Customers or their surrogates have the lion’s share of the responsibility for establishing priorities. If all the unprioritized requirements are equally important, so is the project manager’s ability to react to new requirements added during development, budget cuts, schedule overruns, or a team member’s departure. You can determine priority by considering the requirement’s value to the customer, the relative implementation cost, and the relative technical risk of implementing it.Many groups use three levels of priority. High priority means you must incorporate the requirement in the next product release. Medium priority means the requirement is necessary but you can defer it to a later release if necessary. Low priority means it would be nice to have, but you might have to drop it because of insufficient time or resources.Characteristic #5: They must be unambiguous.The reader of a requirement statement should draw only one interpretation of it. Also, multiple readers of a requirement should arrive at the same interpretation. Natural language is highly prone to ambiguity. Avoid subjective terms like user-friendly, easy, simple, rapid, efficient, several, state-of-the-art, improved, maximize, and minimize. Write each requirement in succinct, simple, straightforward language of the user domain, not in technical jargon. You can reveal ambiguity through formal requirements specifications inspections, writing test cases from requirements, and creating user scenarios that illustrate the expected behavior of a specific portion of the product.Characteristic #6: They must be verifiable. See whether you can devise tests or use other verification approaches, such as inspection or demonstration, to verify that the product properly implements each requirement. If you can’t verify a requirement, determining whether or not it was correctly implemented is a matter of opinion. Requirements that aren’t consist ent, feasible, or unambiguous are also not verifiable. Any requirement that the product shall “support” something isn’t verifiable.Characteristics of Quality Requirements SpecificationsA complete SRS is more than a long list of functional requirements. It also includes external interface descriptions and nonfunctional requirements, such as quality attributes and performance expectations. Look for the following characteristics of a high-quality SRS.。
建筑工程施工总承包管理中的沟通与协调管理-精品文档资料
建筑工程施工总承包管理中的沟通与协调管理建筑工程项目是依靠大量的人力、物力和财力在一定的环境和约束下进行的多方集团作业的产物。
集团作业的成功依赖于相互关系的和谐，和谐则来自于有效的沟通与协调。
沟通是指信息流在相关各方之间的交流与传递，协调则是项目建设的资源、目标及相关各方之间要求与利益的平衡调整,体现在各方关系的处理上。
总承包商在建筑工程中的沟通与协调在项目建设中具有举足轻重的作用，其沟通可以分为内部沟通与外部沟通，协调则指为避免各关联方相互之间出现相互制约、矛盾与冲突而进行关系处理。
沟通是协调的手段,没有沟通就无法进行协调,协调是沟通的目的，只有充分沟通相互各方相互信任理解，才能实现协调的目的。
总之,总承包商的沟通与协调工作好坏不仅反映总承包商管理能力和水平的高低，也直接关系到建设项目的成败.一、沟通与协调的目的及原则（一）沟通与协调的目的总承包商在项目建设过程中的沟通与协调工作就是在相关各方之间建立有效的沟通渠道与协调机制,使相互之间实现信息无障碍交流,并通过沟通协调使之相互信任、尊重和理解，为项目实施创造良好的合作关系好工作环境,此即为沟通与协调的目的。
（二)沟通与协调的原则1.公平性.总承包商作为沟通与协调主体在进行工作时，不能以保护自己私立或其中某方的利益为出发点，一味考虑自己的利益与要求,而应该从大局出发，始终以公平为原则,设身处地的为他方着想，站在公平合理的立场开展协调工作。
2。
高效性。
由于大多建筑工程具备工期紧、任务重的特点，施工管理尤其是总承包商的管理工作千头万绪，为了能使各方工作不受影响，其沟通与协调工作的效率性尤为重要。
为了能够实现共作的高效性需要总承包商在必要时采取牺牲自己的蝇头小利来换取对方的信任，从而赢得宝贵时间,以利于工作开展。
3。
真实性。
在沟通与协调工作中信息作为沟通的基础和传达的内容应保证其真实可信,准确可靠.虚假错误的信息不仅会导致对方作出错误的决策判断,且会失信于对方。
项目管理-项目管理器 精品
1
本章要点
2.1 项目文件的建立与项目管理器界面 2.2 项目管理器窗口的操作 2.3 项目管理器按钮的介绍
思考题
2
2.1 项目文件的建立与项目管理.0中，项目管理器是按一定的 顺序和逻辑关系对应用系统的文件进行有效组织的工具， 它可以用最简单可视化的方法对数据库和数据表进行管 理。在应用程序开发过程中，可以有效地组织数据库、 数据表、表单、菜单、类、程序和其他文件，并且将它 们编译成可独立运行的.app或.exe文件。项目文件实际 上是数据、程序、文档及Visual FoxPro 6.0对象的集合， 项目文件的扩展名为.pjx，利用项目管理器可以提高软
10
4．将选项卡移出项目管理器
当项目管理器窗口被压缩后，可通过鼠标拖动项目管理器中任 何一个选项卡，使之离开项目管理器，此时在项目管理器上的 相应选项卡就变成灰色（表示不可用） 要恢复一个选项卡并将其放回原来的位置，可单击它上方的关 闭按钮“ ”或在标题上拖动它到原来的位置。单击选项卡上 的图钉图标 ，该选项卡就会一直处于其他窗口的上面，再次 单击它将取消这种状态。
要 点 也可以在命令窗口中建立项目文件，其命令格式为：CREATE PROJECT
[盘符:\路径\项目文件名] 说明：如果缺省选项，则进入“创建”窗口。
6
2.1.2 打开与关闭项目管理器
打开项目管理器的操作步骤如下： (1)选择系统主菜单中的“文件”，然后再选择其中的“打开 ”，进入“打开”对话框窗口。 (2)在“打开”对话框中的“文件类型”栏中点击下拉按钮， 在下拉菜单中点击“项目”，然后在“打开”对话框中的大窗 口里选择你所打开的项目文件（即点击你所选的项目文件名） ，最后单击“确定”按钮，此后进入 “项目管理器”窗口。 也可以在命令窗口中打开项目文件，其命令格式为： MODIFY PROJECT 盘符:\路径\项目文件名 功能：用于打开或修改指定的项目文件。 关闭项目管理器只须单击其窗口右上角的关闭按钮即可。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
不同项目利益相关者对项目有不同的期望和需求，他们会直 接或间接地影响项目的成果。因此，必须分析这些组织或个 人的期望，使其朝着有利于项目顺利进展的方向发展。
第一单元 项目与项目管理
Chaos：软件项目
确定范围 工作分解结构 评分标准：是否符合工作分解结构的划分原则——是否有编码；是否详细、全面；
3）保证决策指挥的统一 ：合理的层次； 4）创造人尽其才的环境 ：能级原则； 5）有利于过程的控制 ：各种报告、汇报的方
式、方法和制度。
事业部制或项目制，能够自圆其说；事业部制通常比较 适合规模较大，产品种类多、跨区域的情况，风险投资 项目往往提供的投资组合产品较多。若是规模较大，涉 及的区域比较广泛，则根据项目与组织本身结构一体化 的原则，采用事业部制是比较合适的。
矩阵制，矩阵制通常适合规模庞大，对资源要求较 多的情况。这一标准软件项目的客户需求较多，可 见其规模是比较大的。矩阵制可以满足其与各职能 部门的协调，交流，其扁平化的特点可以赋予项目 组更柔性的职权。
第三单元
假设经过几年的接触之后，你和你的恋人最终决定 结婚。你的伴侣希望有一个非常隆重的婚礼，你意 识到有许多计划和工作需要做。注意到你的紧张， 你的朋友和家人纷纷安慰你说，一切都会令人满意 的，他们甚至帮助你安排婚礼。作为一个完美主义 者，你想确保一切尽可能顺利进行。烈出你的假设， 并基于此做一个工作分解结构图。
斯坦迪什集团国际公司是一个市场研究和顾问公司， 专门从事关键业务软件和电子商务方面的业务。他们对 软件开发/应用项目的成功进行了大量研究。他们进行 的代号为“Chaos”的研究表明，非常令人惊讶，有 31%的软件项目甚至会在完成之前取消。此外，53% 的项目会花费原始估计成本的189%。以成功来计，平 均而言只有16%的软件项目会按期在预算内完成。在 大公司，成功率更差得多——只有9%。斯坦迪什集团 国际公司估计，在2019年美国公司和政府机构在最终 取消的软件项目上花费了810亿美元。（略）
1.请列出您的公司近些年最成功的一到两个项目 （按照成功程度排列）。
2.请列出您的公司近些年最不成功的一到两个项目， 并指出项目失败最主要的两到三个原因。
3.您的公司中项目管理的现状如何。
成功标准
1．用户参与 2．高层管理人员的支持 3．明确的要求陈述 4．适当的计划 5．现实的预期 6．细分的项目里程碑 7．有才能的参与人员 8．项目团队所有权 9．明确的视野和目标 10．全神贯注、努力工作的人员
组织结构称为组织形式，反映了生产要素相合的结 构形式，即管理活动中各种职能的横向分工和层次 划分。组织结构运行的规则和各种管理职能分工的 规则即是工作规则。组织结构决定了项目的运行效 率及结果。
建立项目组织结构有5项原则：
1）能反映项目的目标和计划：达到的预期目 标；
2）根据需要设计组织结构 ：项目性质、规模、 体制；
2）为了节约项目成本（资源），可以减少项目范 围或延长项目时间；如果需求变化导致增加项目范 围，就需要增加项目成本（资源）或延长项目时间。
第二单元
题目：案例分析问题： 1、公司的项目管理存在那些问题？ 2、大王该怎么办？
①项目的组织建立之初并未明确项目协调员在项 目中的位置及作用，也未明确参与项目的各子项目 经理/项目支持部门的责任；
解析
以项目质量、时间、费用三角形为基础的项目管理 水平
企业高层领导层的重视程度、组织文化对项目成功 的影响作用
项目团队成员和团队合作水平
项目管理三角形，是指项目管理中范围、时间、成 本三个因素之间的互相影响的关系。
1）为了缩短项目时间，就需要增加项目成本（资 源）或减少项书面文档少，流于形式；
④对项目的风险预见不足；
⑤部门之间的协调不足，对多项目管理缺乏统筹安 排、前瞻性差、责任性差。
① 请求直接领导进行部门协调，甚至公司大会协 调；
②和客户沟通，项目建议书的完成时间可能会出现 变更，请客户谅解，同时告诉客户自己的纠正措施；
项目制或职能制，科研项目往往需要召集具有不同专业、 背景、专长的个人共同来完成一项科研任务，并且这样 一个研究项目需要更大程度上的自主决策权，因此需要 弱化职能权力。而且考虑到资源有限的问题，项目制是 比较合适的选择。这个项目一旦结束，项目组即告解散， 或为下一个研究项目提供人员和资源，方便灵活。
③组织小林等加班完成项目建议书；
④请小林对项目组成员进行培训；
⑤对这件事的教训进行总结并在项目组会议上讨论， 主要的、能够进行决策的人要参加会议。
第二单元 项目经理与项目组织
1.什么是项目组织结构？项目组织结构有哪些类型？ 2.对下面的一些项目，你将采用哪种组织结构，简
单说明理由。 （a）某家银行投资部的风险投资项目。 （b）某公司的研发实验室的研究项目。 （c）客户需求较多的一个标准软件项目。
设立咖啡馆是项目，它有明确的目标，需要完成一系列相互 关联的任务，因其独特的需求也是一次性的努力，其结果有 一点的不确定性。当咖啡馆建成之后投入正常运营之时就属 于商业运营了。
（b）项目利益相关者是指积极参与项目，其利益受到项目 影响的所有个人和组织，除当事人外，还有政府部门，当地 的居民、社区、项目业主的用户、新闻媒体、合作伙伴，甚 至包括项目班子成员的家属等。
项目管理作业讲解
第一单元
题目：你打算在某个居民区开一个咖啡厅，请回答 以下问题：
（a）什么是项目？开咖啡馆是项目吗？ （b）什么是项目利益相关人？写出开咖啡厅涉及
的项目利益相关人。为什么要对项目利益相关者进 行分析？
（a）项目是以一套独特而相互联系的任务为前提，有效地 利用资源，为实现一个特定的目标所做的努力。