项目策划管理基础知识Word下载.docx
《项目策划管理基础知识Word下载.docx》由会员分享，可在线阅读，更多相关《项目策划管理基础知识Word下载.docx（16页珍藏版）》请在冰点文库上搜索。
风险处理一般而言，风险处理有三种方法，①风险操纵法，即主动采取措施幸免风险，消灭风险，中和风险或采纳紧急方案降低风险。
②风险自留，当风险量不大时能够余留风险。
③风险转移。
风险监控包括对风险发生的监督和对风险治理的监督，前者是对已识不的风险源进行监视和操纵，后者是在项目实施过程中监督人们认真执行风险治理的组织和技术措施。
在IT软件项目治理中，应该任命一名风险治理者，该治理者的要紧职责是在制订与评估规划时，从风险治理的角度对项目规划或打算进行审核并发表意见，不断查找可能出现的任何意外情况，试着指出各个风险的治理策略及常用的治理方法，以随时处理出现的风险，风险治理者最好是由项目主管以外的人担任。
4风险识不
风险识不确实是企图采纳系统化的方法，识不某特定项目已知的和可预测的风险。
常用方法是建立“风险条目检查表”，利用一组提问来关心项目风险治理者了解在项目和技术方面有些风险。
在“风险条目检查表”中，列出了所有可能的与每一个风险因素有关的提问，使得风险治理者集中来识不常见的、已知的和可预测的风险，如产品规模风险、依靠性风险、需求风险、治理风险及技术风险等。
“风险条目检查表”能够以不同的方式组织，通过判定分析或假设分析，给出这些提问确定的回答，就能够关心治理或打算人员估算风险的阻碍。
软件项目一般有如下五类风险：
4.1产品规模风险
有经验的项目经理都明白：
项目的风险是直接与产品的规模成正比的。
与软件规模相关的常见风险因素有：
估算产品的规模的方法（LOC或代码行，FP或功能点，程序或文件的数目）。
产品规模估算的信任度
产品规模与往常产品规模平均值的偏差
产品的用户数
复用的软件有多少
产品的需求改变多少
4.2需求风险
专门多项目在确定需求时都面临着一些不确定性和混乱。
当在项目早期容忍了这些不确定性，同时在项目进展过程当中得不到解决，这些问题就会对项目的成功造成专门大威胁。
假如不操纵与需求相关的风险因素，那么就专门有可能产生错误的产品或者拙劣地建筑正确的产品。
每一种情况都会导致使人不愉快。
与客户相关的风险因素有：
对产品缺少清晰的认识
对产品需求缺少认同
在做需求中客户参与不够
没有优先需求
由于不确定的需要导致新的市场
不断变化需求
缺少有效的需求变化治理过程
对需求的变化缺少相关分析
4.3相关性风险
许多风险差不多上因为项目的外部环境或因素的相关性产生的。
经常我们不能专门好地操纵外部的相关性，因此缓解策略应该包括可能性打算，以便从第二资源或协同工作资源中取得必要的组成部分，同时觉察潜在的问题。
与外部环境相关的因素有：
客户供应条目或信息
内部或外部转包商的关系
交互成员或交互团体依靠性
经验丰富人员的可得性
项目的复用性
4.4治理风险
尽管治理问题制约了专门多项目的成功，然而不要因为风险治理打算中没有包括所有治理活动而感到惊奇。
在大部分项目里，项目经理经常是写项目风险治理打算的人，同时大部分人都不希望在公共场合暴露自己的弱点。
然而，像这些问题可能会使项目的成功变得更加困难。
假如不正视这些棘手的问题，它们就专门有可能在项目进行的某个时期阻碍项目。
当我们定义了项目追踪过程同时明晰项目角色和责任，就能处理这些风险因素：
打算和任务定义不够充分
实际项目状态
项目所有者和决策者分不清
不切实际的承诺
职员之间的冲突
4.5技术风险
软件技术的飞速进展和经历丰富职员的缺乏，意味着项目团队可能会因为技巧的缘故阻碍项目的成功。
在早期，识不风险从而采取合适的预防措施是解决风险领域问题的关键，比如：
培训、雇佣顾问以及为项目团队招聘合适的人才等。
要紧有下面这些风险因素：
缺乏培训
对方法、工具和技术理解的不够
应用领域的经验不够
新的技术和开发方法
不能正确工作的方法
5风险可能
风险可能，又称风险预测，常采纳两种方法估价每种风险。
一种是可能风险发生的可能性或概率，另一种是可能假如风险发生时所产生的后果。
一般来讲，风险治理者要与项目打算人员、技术人员及其他治理人员一起执行四种风险活动：
（1）建立一个标准（尺度），以反映风险发生的可能性。
（2）描述风险的后果。
（3）可能风险对项目和产品的阻碍。
（4）确定风险的精确度，以免产生误解。
另外，要对每个风险的表现、范围、时刻做出尽量准确的推断。
对不同类型的风险采取不同的分析方法。
1．确定型风险可能
（a）盈亏平衡分析
盈亏平衡分析（Break-EvenAnalysis）通常又称为量本利分析或损益平衡分析。
它是依照软件项目在正常生产年份的产品产量或销售量、成本费用、产品销售单价和销售税金等数据，计算和分析产量、成本和盈利这三者之间的关系，从中找出它们的规律，并确定项目成本和收益相等时的盈亏平衡点的一种分析方法。
在盈亏平衡点上，软件项目既无盈利，也无亏损。
通过盈亏平衡分析能够看出软件项目对市场需求变化的适应能力。
（b）敏感性分析
敏感性分析（SensitivityAnalysis）的目的，是考察与软件项目有关的一个或多个要紧因素发生变化时对该项目投资价值指标的阻碍程度。
通过敏感性分析，使我们能够了解和掌握在软件项目经济分析中由于某些参数估算的错误或是使用的数据不太可靠而可能造成的对投资价值指标的阻碍程度，有助于我们确定在项目投资决策过程中需要重点调查研究和分析测算的因素。
（c）概率分析
它是运用概率论及数理统计方法，来预测和研究各种不确定因素对软件项目投资价值指标阻碍的一种定量分析。
通过概率分析能够对项目的风险情况做出比较准确的推断。
要紧包括解析法和模拟法（蒙特卡罗MonteCarlo技术）两种。
2．不确定型风险可能
要紧有小中取大原则、大中取小原则、遗憾原则、最大数学期望原则、最大可能原则。
3．随机型风险可能
要紧有最大可能原则、最大数学期望原则、最大效用数学期望原则、贝叶斯后验概率法等。
5.1建立风险清单
风险清单是关键的风险预测治理工具，清单上列出了在任何时候碰到的风险名称、类不、概率及该风险所产生的阻碍。
其中整体阻碍值可对四个风险因素（性能、支持、成本及进度）的阻碍类不求平均值（有时也采纳加权平均值）。
一旦完成了风险表的内容，就能够依照概率及阻碍来进行综合考虑，风险阻碍和出现概率从风险治理的角度来看，它们各自起着不同的作用（见图1）。
一个具有高阻碍但低概率的风险因素不应当占用太多的风险治理时刻，而具有中到高概率、高阻碍的风险和具有高概率及低阻碍的风险，就应该进行风险分析。
5.2风险评估
在风险分析过程中，我们对风险进行评估时能够建立一个如下的四元数组：
[ri,li,xi，yi]
其中，ri是风险，li为风险出现的概率，xi则表示风险损失大小，yi则表示期望风险。
一种对风险评估的常用技术是定义风险的参照水准，对绝大多数软件项目来讲，风险因素——成本、性能、支持和进度确实是典型的风险参照系。
也确实是讲对成本超支、性能下降、支持困难、进度延迟都有一个导致项目终止的水平值。
假如风险的组合所产生的问题超出了一个或多个参照水平值时，就终止该项目的工作，在项目分析中，风险水平参考值是由一系列的点构成的，每一个单独的点常称为参照点或临界点。
假如某风险落在临界点上，能够利用性能分析、成本分析、质量分析等来推断该项目是否接着工作。
图2表示了这种情况。
但在实际工作中，参照点专门少能构成一条光滑的曲线，大多数情况下，它是一个区域，而且是个易变的区域。
因而在做风险评估时，尽量按以下步骤执行：
（1）定义项目的水平参照值
（2）找出每组[ri,li,xi，yi]与每个水平参照值间的关系
（3）可能一组临界点以定义项目的终止区域
（4）可能风险组合将如何阻碍风险水平参照值
项目组织治理
一、项目组织差不多理论
项目组织是保证工程项目正常实施的组织保证体系，就项目这种一次性任务而言，项目组织建设包括从组织设计、组织运行、组织更新到组织终结如此一个生命周期。
项目治理要在有限的时刻、空间和预算范围内将大量物资、设备和人力组织在一起，按打算实施项目目标，必须建立合理的项目组织。
1、项目组织特征
（1）组织目标单一，工作内容庞杂
（2）项目组织是一个临时性机构
（3）项目组织应精干高效
（4）项目经理是项目组织的关键
2、项目组织设置原则
（1）有效幅度治理原则
（2）权责对等原则
（3）才职相称原则
（4）命令统一原则
（5）效果与效率原则
（6）适时重组原则
3、项目组织机构的类型
（1）工程指挥部型：
从1964年以来，我国大型工程项目要紧采取这种形式，目前仍然被广泛采纳。
优点是对项目实施过程中所出现的相互间协作配合问题的解决具有决策快、效率高的特点；
缺点是该形式是行政治理的方式，许多方面不能符合市场经济的规律。
现代项目治理中所采纳的工程指挥部型项目组织，不管是形式上依旧内容上都比早期的工程指挥部型有了专门大的改进。
（2）职能组织型：
该结构呈金字塔形，高层治理者位于金字塔的顶部，中层和底层治理者则沿着塔身向下分布。
公司的经营活动按照设计、生产、营销和财务等职能划分成部门；
一个项目能够作为公司中某个职能部门的一部分，那个部门应该是对项目的实施最有关心或最有可能使项目成功的部门，例如开发一个新产品项目能够被安排在技术部门的下面，直接由技术部门经理负责。
（3）项目组织型：
在这种组织形式中，每个项目就如同一个微型公司那样运作，项目组的成员来自不同的部门，完成每个项目所需的资源完全分配给那个项目，专门为该项目服务。
（4）矩阵组织型：
现代大型项目中应用最广泛的新型组织形式，它是职能组织型和项目组织型的结合，
将职能组织型的纵向优势和项目组织型的横向优势有效结合起来。
一个矩阵组织型由垂直的职能部门和水平的不同项目组结合而成一个矩阵，把集权和分权结合起来，从而加强了各职能部门同各项目之间的协作关系。
4、项目组织结构的变化系列
（1）项目组织结构的变化系列
职能组织型、项目组织型和矩阵组织型能够表示为一个变化系列，基于工作人员在自己部门的工作时刻和在项目组中的工作时刻之比，列出上图所示组织结构变化系列图。
（2）常用项目组织特点
5、阻碍项目组织选型的因素
6、项目组的组建
（1）项目组的组成成员
1）项目经理：
包括业主项目经理、设计单位项目经理和实施单位项目经理。
2）项目工程师：
主管产品的设计开发，负责产品的功能分析、规格讲明、图纸、费用估算、质量、工程变更及技术文档。
3）制造工程师：
为项目工程师的设计成果组织有效的生产过程，包括设计和安装相应的生产设备、安排生产进度以及其他的生产活动。
4）现场经理：
负责在产品交付用户使用时的现场支持、包括安装调试等。
5）合同治理员：
负责项目的所有正式书面文件，对用户变更、提问、投诉、法律方面、成本及其他授权给项目的关于合同方面的事务保持跟踪。
6）项目治理员；
负责记录项目的日常收支情况，包括成本变化、劳务费用、日常用品及设备状况等；
还要定期做一些报表，并与项目经理和公司领导保持紧密联系。
7）支持服务经理：
负责产品的服务支持，与分包商的联系、信息处理等。
下图是通常使用中的一个典型组织结构图：
（1）建立项目组沟通打算：
通常能够采纳会议、书面情况报告、电子邮件或其混合形式来加强项目组成员间的信息沟通和相互交流。
（2）项目启动会议：
目的是召集项目有关人员开会，介绍项目目标、实施策略及打算安排，宣布有关项目治理中的有关规程；
出席人员包括项目发起人、客户代表、公司主观领导、有关职能部门经理和全体项目组成员，该会议的结束标志着项目正式启动。
二、ERP项目实施中的项目组织实例
在具体为某航空企业实施ERP的过程中，设计方和实施方都由我们承担，因此上述的设计、实施项目组能够融为一个组，但承担着两个组的责任；
本案例采纳项目型组织结构。
1、设计方/实施方项目组要紧成员及职能描述
（1）项目经理
●与企业用户讨论并确定最终项目范围和实施方法
●负责制订具体的项目打算，包括培训打算
●把握项目各方面的进程
●指导业务流程重组和项目变更
●检查及调控项目实施范围
●向公司汇报项目状况，提出建议及改进措施
●负责项目时期质量
●其它项目经理所应该负责的项目治理工作
（2）技术工程师
●对项目实施按项目实施打算提供技术支持
●协助项目经理定义项目的范围及目标
●参与讨论、制定项目打算
●按项目实施打算提供系统技术培训
●制订指导系统治理策略和方案
●制订数据治理策略和方案
●进行客户化开发的设计、开发和测试
●负责系统安装、提供设备选型参数
●对系统整体性能提出意见
●依照以往的实施经验提供设计及集成方面的建议
●完成数据转换和系统切换工作，保证系统启动运行
●负责单元、系统及整体性测试
●负责汇编用户手册并对最终用户进行培训和指导
●负责其它必要的技术工作
（3）实施工程师
●对项目实施按项目实施打算提供实施支持
●按项目实施打算提供系统功能培训
●制订指导系统详细实施打算和进度方案
●制订数据转换格式和方案
●进行系统的客户化
●协助技术人员进行系统安装及技术维护
●依照以往的实施经验提供实施风险及防范方面的建议
●完成系统时期实施目标，保证系统按期顺利运行
●协助技术人员进行单元、系统及整体性能测试
●协助项目经理进行时期验收和系统验收
●其它必要的实施工作
（4）客户代表
●负责与企业用户方面的关系协调和沟通
●负责资料收集和信息传递
●依照项目的需要，负责其它必要的项目工作
2、企业方的项目组要紧成员及职能描述
（1）项目负责人
●负责与设计方方面联络，保证项目按进度顺利实施
●参与项目打算，辅助治理项目范围，调度资源，监控进度
●提供系统上线后的有关业务支持方法的培训并负责以后的业务支持
●其它项目负责人所应该负责的项目治理工作
（2）项目一般成员
●进行业务流程及功能需求的整理和详细设计
●制订必要的数据安全治理制度
●制订必要的系统内部实施治理制度
●进行数据的收集、整理和预备，为设计方提供必要的数据转换支持
●参与项目详细实施打算、时期打算、培训打算的制订
●负责最终操作用户的培训和使用指导
●参与相关系统的单元及集成测试
●同意咨询顾问的知识转移
●为企业用户提供实施后的技术及相关支持
●提供安装及维护所需的硬件和通讯网络
●协助安装及调试设计方的软件系统
●提供系统的技术、运行环境以支持系统培训、实施、维护等工作的正常运行
●依照项目的需要，在项目负责人的统一调配下，进行其它必要的实施工作。
三、结论
项目的组织结构是实施项目治理的一个差不多手段，也是开展项目治理工作的基础。
针对具体的项目情况和实施要求选择合适的组织结构至关重要，本文仅仅对此作了一些初步的探讨，随着当前项目治理形式的进展，项目组织结构理论可能会更趋丰富，新的适合项目治理需求的结构形式必将出现，这也是大伙儿的期待
项目治理常用语
-英中对比
abandonment
委付
Theinsuredsurrendersownershipofthepropertyconveredbyinsurancetotheinsurer.受保人放弃投保的财产所有权,将其交给承保人
absoluteadvantage
绝对优势
Theadvantateintheproductionofaproductenjoyedbyonecountryoveranotherwhenituseslessresourcetoproducethatproductthantheothercountrydoes.一国因生产某种产品耗费的资源比另一国少而对后者具有的优势
accdlerateddepreciation
加速折旧
Aprovisionoftaxlawthatallowsfirmstowriteoffagainstprofitsthefullcostofapieceofequipmentoranewbuidingaccordingtoacertainformulawithinaperiodthatisshorterthantheactualusefullifeofthatequipmentorbuilding.税法的一条规定,同意公司依照盈利情况在比实际使用寿命短的期间内将设备或建筑物的全部成本按照一定的公式注销
acceptancecdrtificate
验收证书,合格证书
access
获得,取得,接近（或进入）的方法（或权利、机会等）
accesstodate使用资料（的权利），查阅资料（的权利）
accesstomarket进入市场（的机会）
accessibility
接近（或进入）的可能性（条件，状况等）
accommodation通融,和解
accountability尽责能力,责任透明度,述职要求,（工作,公务,账目,责任）能够向（有关方面）交代清晰的一种（情况、状态、性质），对有关方面的要求和希望给以满足的态度和能力，问责性
Accountability/respinsibilitymatrix
责任分派矩阵
accountable有讲明与解答议务的，负责的，应（向有关方面）交代的，能够负责的
projectanalysis项目分析
一种分析方法,该法将成本同效益进行比较,依照给定的各备选方案确定建议的项目是否能充分促进作为分析立足的那个实体目标的实现,以及进行该项目是否有充分的理由
projectboundary项目边界
项目边界是项目讲明中包括的活动范围。
是从项目的实体边界概念引申出来的。
然而能够扩大，将那些没有固定地理边界，也可能把不同处所的参加者组合起来的项目包括在内。
projectcoordinator项目协调人
有独立行动权，对自己的行动负责，但不指导他人工作的治理人员。
项目协调人发挥领导作用是通过按程序做出决策和个人之间的沟通和切磋，而不是利用手中的权力来实现。
projectcharter项目证书
项目证书确实是一份正式承认项目存在的文件。
该文件通常由项目之外的一位治理人员发出，其地位要依照项目的需要而定。
项目证书为项目经理规定了在项目活动中使用组织资源的权限。
projectinterfaces项目界面
项目界面一般分三种：
１、组织界面——不同组织单位之间的通报关系。
２、技术界面——不同技术专业之间的通报关系。
３、人际界面——同一项目上不同个人之间的通报关系。
projectmanagementprocesses项目治理的过程
过程是产生结果的行动序列。
关于项目,有五中差不多的治理过程：
发起、规划、实施、操纵和结束收尾。
项目的一次性要求加上发起和结束收尾两个过程，这是与经营治理的区不之处。
projectmanagementknowledgeareas项目治理知识领域
一般公认的项目治理做法划分为8个知识领域:
项目范围治理、项目时刻治理、
升级会员 