方案管理基础知识1Word格式.docx
- 文档编号:18455339
- 上传时间:2022-12-16
- 格式:DOCX
- 页数:12
- 大小:87.18KB
方案管理基础知识1Word格式.docx
《方案管理基础知识1Word格式.docx》由会员分享,可在线阅读,更多相关《方案管理基础知识1Word格式.docx(12页珍藏版)》请在冰豆网上搜索。
风险处理一般而言,风险处理有三种方法,①风险控制法,即主动采取措施避免风险,消灭风险,中和风险或采用紧急方案降低风险。
②风险自留,当风险量不大时可以余留风险。
③风险转移。
风险监控包括对风险发生的监督和对风险管理的监督,前者是对已识别的风险源进行监视和控制,后者是在项目实施过程中监督人们认真执行风险管理的组织和技术措施。
在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项目界面
项目界面一般分三种:
1、组织界面——不同组织单位之间的通报关系。
2、技术界面——不同技术专业之间的通报关系。
3、人际界面——同一项目上不同个人之间的通报关系。
projectmanagementprocesses项目管理的过程
过程是产生结果的行动序列。
对于项目,有五中基本的管理过程:
发起、规划、实施、控制和结束收尾。
项目的一次性要求加上发起和结束收尾两个过程,这是与经营管理的区别之处。
projectmanagementknowledgeareas项目管理知识领域
一般公认的项目管理做法划分为8个知识领域:
项目范围管理、项目时间管理、项目费用管理、项目质量管理、项目人力资源管理、项目
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 方案 管理 基础知识