项目管理流程中的七要素Word文档格式.docx
《项目管理流程中的七要素Word文档格式.docx》由会员分享，可在线阅读，更多相关《项目管理流程中的七要素Word文档格式.docx（37页珍藏版）》请在冰豆网上搜索。
·
由于高层管理人员不知道应该由谁来作出决策，或者需要什么样的一致意见，所以他无意识的延迟决策或修订决策。
信息不够充分或细节不清楚导致决策质量低劣。
没有及时解答疑问。
未定义决策控制点，以至在适当的重要阶段又出现了评审工作。
需要投入的资源过多，以至无法按期完成任何事情。
授权审批和设定优先顺序的人没有明确批准给予产品开发工程的拨付资金。
决策太迟——经常是在产品已经设计出来之后。
没有用周期指导来证实工程进度。
高层领导没有作出战略决策，却由开发人员在无奈中作出这种决策。
在PACE流程中，新产品决策是通过阶段评审流程进行的，这种阶段评审需要在开发流程中具体定义的点上作出决策。
一个产品开发工程必须在预定时间内到达明确定义的目标，才能获准进入下一阶段。
产品审批委员会〔ProductApprovalCommittee,PAC〕是指在一个部门或一个公司内负责主要新产品决策的高层领导小组。
PAC有权在开发周期内的具体决策点通过给新产品拨付资金或修改新产品的途径来批准或拒绝新产品。
PAC负责通过产品开发活动实施公司的战略，因此，他们具有资源分配权，以推进新产品的开发。
PAC一般通过阶段评审流程来作出决策和进行资源分配。
没有这样一个流程，高层领导就难以有效地引导新产品的开发。
然而，只有一个评审流程〔或类似的一个流程，如把关流程或阶段开发流程〕是不够的。
定义不清、实施不当或与开发流程中的其他必要要素不协调，都可能使评审流程效率低下。
阶段评审流程在产品开发中还扮演着另一个重要角色。
通过它，PAC可以直接明了地授权工程小组分阶段地开发产品。
工程小组为产品制定详细的建议，提交产品开发方案，并申请下一阶段所需的资源。
如果PAC批准工作小组的各项建议，它会赋予工程小组以权力、责任以及实施小组方案的下一阶段所需要的资源。
2、工程小组构成
在评审中我们发现，尽管大多数公司有正规的工程小组，但多数并不成功。
总的来说，由于这些工程小组的构成、角色和责任没有明确的定义，结果使沟通、协调和决策效率低下、纷繁混乱。
有这么一家很典型的公司，不计其数的经理们只在他们有空的时候或是有什么特别原因使会议变得最优先的时候，他们才参加产品开发小组的会议。
由于这种方法产生的效果差，所以公司曾尝试用不同的方法来改变这种状况。
他们建立了专门的工程管理部门，负责监督进度和任务的提交，以明确由谁去做什么以及事情做了没有。
后来，每个部门都给每一个主要工程指定了自己部门的工程经理。
但这些方法效果并不理想，只是增加了毫无价值的劳动，而这种劳动已经太多了。
许多公司建立了工程小组的组织形式，但大多数效果不佳。
针对这些不成功的案例，我们发现以下典型原因：
如果工程小组和职能部门的责权不明确，将造成困惑。
工程小组没有得到明确授权去实现目标，因而效率低下；
在某些情况下，他们只被赋予了责任，却没有相应的权力和资源。
缺乏并行工程，一些职能和技能无法和谐地融入到工程小组中去。
工程领导工作效率低，这源于几个因素：
工程领导人没有经验；
对工程领导人角色不明确；
培训缺乏；
工程领导人更换频繁；
或者工程小组的组织有缺陷。
工程小组缺乏工程实施所需的人手和技能，因而无法实现目标；
各种资源在工程小组间调来调去，缺乏明确的决定。
由于没有明确定义工程小组和职能部门之间的协作方法，两者之间便有冲突和困扰。
小组成员任务分配造成的困扰使整个小组效率低下：
比方说，小组成员把自己看作职能部门的评估者或记录者，而非真正地帮助进行实时决策。
工程小组构成是产品开发流程的一个关键要素。
一个高效的工程小组能极大地增进沟通、协作和决策。
在评审初期，我们就发现许多广为接受的工程小组模式效率低下，而低下的原因与上文所述颇为相似。
我们开发了一个新的模式。
这个模式既能发挥工程小组这种组织形式的最正确方面，又能克服上述缺陷。
我们把它称之为工程小组构成中的核心小组模式〔CoreTeamApproach〕。
核心小组是有权开发特定产品的一个小型跨部门工程小组。
一个典型的核心小组有5—8名成员，有权力也有责任管理所有与开发该特定产品相关的任务。
这些特定任务分配到核心小组的每个成员身上，每个成员都利用相应资源完成这些任务。
小组成员们为指定给他们的工作确定方向，与职能部门打交道，并作为核心小组的一员参与集体决策。
PAC那么在开发工作的每一阶段通过阶段评审流程赋予核心小组责任和权力。
每个核心小组都有一个指导和引导小组工作的领导人。
该小组在执行每一开发阶段时遵守与PAC签定的有关重大工程目标以及可变动的范围的“合同〞。
3、开发活动的结构
开发活动是开发新产品的实质性工作。
在PACE中，结构化的开发流程明确了应做什么开发工作、相应的先后次序、其间的关联性以及用于开发工程的标准术语。
在评审流程中，我们发现，开发活动的结构中往往存在三类普遍的缺陷：
（1）没有任何明确的产品开发结构的公司；
（2）有具体流程手册但并没得到遵循的公司；
（3）有结构化的流程但并不能改进或加快开发进度的公司。
对第一种情况来说，公司必须在产品开发流程中不断地“重新创造车轮〞，即重新定义产品开发流程。
每一个工程小组都定义其要遵循的流程，结果，每个工程小组即使在执行相同的或相似的任务时，开发流程也迥然不同。
这种模式延长了开发周期，且整个公司的工程小组都易犯同样的错误。
对第二种情况来说，流程被文档化了，但是并没有得到执行。
典型的情况是，某个职员在程序手册里定义开发流程，然后把手册散发出去，天真地期待每个人都会遵守它，结果当然是他们并不遵守。
多数情况下，他们不遵守反而好一点。
工程小组又各自将自己的那一套流程搬了出来。
对第三种情况来说，开发流程已得到明确和遵守，可惜这个流程天生就效率低下。
令人吃惊的是，许多公司在标准流程时，只是简单地将他们现有的做法写成文件，哪怕这个流程效率低下，其结果自然是把问题制度化了。
在评审开发流程时，我们发现普遍存在以下缺陷：
无章可循的开发活动导致产品不断更新。
由于对必须完成什么样的开发活动及何时完成有误解，因而造成工程方案不周及准备缺乏。
缺乏通用术语以及由此引起的理解问题，导致开发工作不理想。
产品开发定义过于详细，尤其是缺乏结构化的定义，使得开发效率不高。
每一步都需要多个签字盖章的官僚流程延缓了开发工作。
缺乏并行工程，因为它没有被设计到结构化开发流程里。
缺乏开发活动的周期时间指导，导致工程进度不准确。
由于没有将责任落实下来，导致未能不断地改进产品开发流程。
在PACE方法中，核心小组用结构化开发流程开发产品，这将确保一致性，并防止小组创立各自的流程。
基于一个通用的结构化流程，就可以使用通用的周期时间指南并为持续改进打下根底。
按照PACE的方法，一个结构化开发流程包括几个等级。
在阶段评审流程所提供的框架中，一般有15—20个主要步骤来定义一个公司的产品开发流程；
每一步又分成10—30项任务，规定每一个步骤如何在公司里得以实施。
这些任务又为每一个步骤定义出标准周期时间，因此可以根据这些根本步骤编制进度表、预估资源需求、制定方案及进行管理。
每一项任务还可进一步细分成各种各样的开发活动。
根据任务的性质，每一步骤的开发活动数量从几个到30或40个不等。
总的来说，各步骤与任务永远适用于各种工程，而开发活动那么因工程不同而不同。
4、开发工具与技术
各种设计技术，例如质量功能配置〔qualityfunctiondeployment,QFD〕、装配设计〔designforassembly,DFA〕和可制造性设计〔designformanufacturability,DFM〕，能促进产品成功并到达相应的运行效果。
然而，这些技术中没有哪一个能单独地解决产品开发中的所有问题。
举例来说，一个规模宏大、部门众多的高科技公司选择QFD作为其最终的解决方案。
公司投入巨资来培训全公司人员的设计技术，并培养了内部QFD专家和参谋，进行相应的宣讲介绍。
9个月后，产品开发仍不见起色，工程小组也就解散了。
由此，QFD技术受到不公正的指责，这只是因为人们期望有一项技术能弥补整体综合方案的缺乏。
在过去的5—10年中，许多新型自动设计工具已被开发出来，它们可以极大地辅助产品开发流程。
这些工具包括计算机辅助工程〔CAE〕、面向对象的软件开发工具、产品数据管理系统、模拟工具以及用于工程方案、进度和决策的工具。
同样，没有单独的一种工具能提供一个完整的解决方法。
每种工具都可以更大地提高工作流程的生产率，但所有的工具都需要一个结构化的流程，这是一个先决条件。
至于这些工具和技术的使用，我们发现，许多公司犯着这样或那样的错误：
要么是没有使用正确的方法或工具，要么是使用效率不高，这些都是因为他们缺乏整体产品开发流程。
特别是，以下问题比较普遍：
设计技术效率低下，因为不能很好地融入清晰的产品开发流程。
人们期望某一种设计技术，如QFD，能解决所有产品开发问题。
因为没有使用恰当的设计技术，造成新型产品不可制造或不耐用。
因为没有使用自动化工具，导致产品开发时间比应花的时间要长。
因为产品定义不断变更，导致自动开发工具没有产生预期的效果。
PACE流程没有给新技术或新工具下定义，其关注的焦点是在整体产品开发流程这个环境中，适时地运用适宜的技术或工具。
PACE描述了一系列技术设计和自动开发工具，并说明了它们是怎样适用于该流程的。
5、产品战略流程
产品战略是新产品开发的起点。
通过产品战略，公司定义了要开发的产品的类型、如何区分自己与竞争对手的产品、如何将新技术引入新产品以及开发新产品的优先顺序。
选择开发的产品应与整个产品战略保持一致，但情况往往不是这样。
产品战略常常没有被定义或表述清楚，即使在公司内部组织过非正式的讨论。
如果没有一个清楚的产品战略，开发人员在提议新产品及执行开发工程时就必须进行猜测，他们往往是通过反复试验才得知哪些适宜，哪些不适宜。
有时产品战略与开发工程相离太远，以至于前者仅是一纸厚望，对于实际选择的工程没有任何作用。
有一家公司，压倒一切的战略目标就是去开发多种新产品。
当再无其他指导，或在缺乏产品思想的评估框架和优先顺序的设立框架的情况下，许多工程是根据开发人员个人或经理们的提议下启动的。
尽管有的取得了技术上的成功，但这些工程中的大多数永远不可能完成，或永远不能商品化。
该公司的CEO告诉我们说，“如果我早知道他们都在做些什么，我会尽早制止他们。
他们的大多数工程与我们的战略并不一致。
〞
我们的经验说明，产品战略制定和交流的常见缺乏之处如下：
公司将眼光过分集中于个体产品，而对产品平台的重视不够。
公司里没有人明确负责产品战略。
既然产品战略没有一个正式流程，它往往成为年度预算流程中的一项外表工作。
由于公司不能有效地评估其产品战略机遇，开发出了平庸的产品。
产品战略过时，原因是将眼光集中在当前而非将来顾客的需要和市场潮流上。
由于产品战略是内部驱动而非客户驱动，因而造成产品不具竞争力，竞争性分析浅薄，竞争定位不明确。
由于没有产品战略愿景来指导工程开发工作人员，所以实际产品开发与初衷不符。
与盛行的信念相反，最正确产品战略并非来自于令人眩目的革新念头，也不是从数百张充满图表的市场分析报告中得来。
例如，数字设备公司只用三页纸定义未来VAX平台，这就概述了计算机历史上最成功的产品战略之一。
有效的产品战略来自于一个严格的产品方案定义流程，这些产品方案的制定依据是对市场交替变化、技术进步和竞争态势所带来的机遇的理解。
在PACE内，产品战略提供了一个框架，供PAC在阶段评审流程中决策和设立优先顺序之用，并同时为核心小组确立了指南，供其定义产品时使用。
产品战略包括明确定义了扩展现有产品线和创造新产品线的机遇。
尽管每个公司都有自己的商业战略做法、机构建设、产业及竞争地位等，从而使得具体的产品战略因公司的不同而有所不同，但产品战略仍可作为一个流程来管理。
PACE产品战略要素对这一流程进行了定义。
6、技术管理
技术管理是整个产品开发流程的一个组成局部，技术管理的作用是发现应用新技术的时机，并且启动技术开发工程，从而扩大公司的核心竞争力，并使多种产品受益。
我们已经觉察到，一些技术型公司并没有积极管理他们潜在的技术。
一些公司过于将注意力放在产品开发上，以至于最后他们只把技术开发当作产品开发工作中的一个次要工程。
我们也曾看到一些面临困境的开发工程，跌入技术难题之中，原因在于公司没有意识到他们缺乏开发那些产品所需要的最根本的技术知识。
产品开发依赖于技术，无论这技术是内部开发的，还是别人许可使用的，或是从公司外部获得的。
要想及时地利用那些可用的技术，就必须了解当前和未来的核心技术，因为技术的开发和技术联盟的建立需要时间。
要到达这一点，不应强行要求正在搞产品开发的工程小组去创造或获取这些必要的核心技术。
工程开发的风险大小是由其不可防止的、最具风险的因素决定的。
假设该因素是核心技术开发，那么其不确定性和潜在的延误是不可估量的。
例如，某家公司不懂技术管理，它的研发部门致力于各种技术的开发，其有用期“从现在起持续3—10年〞。
然而，大多数这样的研发工作没有充分利用公司现有的技术根底。
结果，他的核心技术到期后没有其他的核心技术来替代。
研发经费的短缺使得一些关乎产品线的核心技术过时了，面对市场份额的节节丧失，公司不得不大量投资以便迎头赶上。
在评审产品开发的流程中，我们发现了以下常见的技术管理上的缺陷：
由于技术上出现的意外，使产品开发延迟。
如果当初技术准备充分，这些意外本来是可以防止的。
由于公司没有给现在或将来的核心技术进行投资而导致技术效能下降。
由于技术开发没有从产品开发中脱离出来，造成了不必要的开发周期延长。
由于对技术风险控制缺乏而引起工程失败。
PACE内的技术管理要素定义了技术开发流程，以及由技术向产品开发的转换，它澄清了产品开发和技术开发两者之间的区别，并定义了它们与产品战略的联系。
7、管道管理
最后，当公司消除了产品开发中以工程为根底的各个方面的缺乏之处后，很明显，它将进一步需要一个更好的管理模式，来管理所有产品开发工程。
随着各个工程对有限资源的竞争趋于明朗化，管道管理就成为下一个首选对象。
我们发现下面几个问题可由管道管理来解决：
低效的资源调度系统常常导致资源调度过度，从而延迟了开发工程。
作“救火〞决策时未考虑到工程的优先顺序。
职能部门预算与工程资源分配不一致。
工程技能要求与部门资源不一致。
产品开发决策没有考虑到公司的增长、产品组合或长/短期侧重点等目标。
这些问题存在于所有产品开发工程，也应在所有工程中得到很好的处理。
PACE管道管理要素解决这些问题的方法是给工程优先次序确实定和跨工程资源管理提供一种框架，并且将职能部门能力和工程要求协调起来。
工程管理流程
只要流程界定清晰，工程经理就能保证工程的开展方向与最终目标相契合。
广义而言，要掌控各种类型工程的开展，首先要关注十个关键的流程。
一、生命周期与方法论
工程的生命周期与方法论，是工程的纪律，为工程开展划出了清晰的界限，以保证工程进程。
生命周期主要是协调相关工程，而方法论为工程进程提供了持续稳定的方式方法。
生命周期通常由工程的阶段组成〔包括：
开始、规划、执行/控制、完成〕，或由工作的重复周期构成。
工程生命周期的细节一般都会随具体业务、工程、客户要求而改变。
因此即使在同一个工程中，周期也会有多种可能的变化。
对工作细致度、文件管理、工程交付、工程沟通的要求表达在生命周期标准和考核的方方面面。
大工程的阶段一般更多更长，而小工程的阶段少，考核点也少。
与生命周期类似，工程方法也因工程而易，细节关注程度高。
产品开发工程的方法经常涉及使用何种工具或系统，以及如何使用。
信息技术工程的方法包括版本控制标准、技术文档管理、系统开发的各个方面。
工程方法往往不是由工程团队自行确定，而由公司为所有工程设定。
采用与否，其实工程团队没有太多项选择择。
公司管理层设定的方法本身代表权威，也是你作为工程领导获得工程控制权的一个途径。
考虑工程方法某方面的作用时，始终要把握其对工程人员管理的效率，即在可能出现问题的地方争取正面效应。
二、工程定义
清晰的工程描述决定了你的工程控制能力，因为接下来所有工作都在描述范畴之内。
不管你如何并为何要进行描述，你要对你的工程进行书面定义，让工程各方和工程组随时参考。
工程定义的形式和名称各式各样，包括：
工程章程、提案、工程数据表、工作报告书、工程细那么。
这些名称的共同点在于，工程主管方和其他相关各方面从上而下地传达了他们对工程的期待。
清晰的工程定义还包括以下方面：
工程目标陈述〔一小段文字，对工程交付成果、工期、预期本钱或人力进行高层次的描述〕
工程回报〔包括商业案例或投资分析的回报〕
使用中的信息或客户需求
对工程范围进行定义，列出所有预期的工程成果
本钱和时间预算目标
重大困难和假设
描述该工程对其他工程的依赖
高风险、所需的新技术、工程中的重大问题
努力将尽可能多的具体信息，囊括在工程描述或章程中，并使其在工程主管方和相关方面获得认可，进而生效。
三、合同与采购管理
不管你在你的组织内有多大的影响力和权力，你对受雇于其他公司的工程成员的影响会比较小。
虽然不一定普遍适用，但你可以尽量不将工程工作外包，这是提高工程控制力的一个技巧。
建立成功的外包关系需要时间和精力，这些工作要及早着手。
为了不误工程工期，你要及时做到所有细节到位，所有合同及时签订。
你打算外包哪局部工程交付成果，对这局部工作的细化就是你实施工程控制的着手点。
记录这些细化内容、评估和接收标准、所有相关要求、必要时间规划。
工程定义信息一定要包括在合同之内，相关责任及早确定。
和所有你考虑到的供应商讨论这些要求，这样你的工程期望才会在各方之间明晰。
四、工程规划、执行、跟踪
作为工程领导，通过制定有力的规划、跟踪、执行流程，你可以建立工程控制的根底。
争取各方面的支持，进而在工程内全面推广。
让工程组成员参与规划和跟踪活动，这可以争取大家的支持并提高积极性。
睿智的工程领导往往大范围地鼓励参与，并通过流程会聚大家的力量。
当大家看到自己的努力以及对工程的奉献被肯定的时候，工程很快就从“他们的工程〞变成“我们的工程〞。
当工程成员视工程工作为己任的时候，工程控制就会简单得多。
较之于漠不关心的团队，此时的工程管理成功几率更大。
运用工程管理流程也会鼓励工程成员的合作，这也让你的工程控制工作更加轻松。
五、变化管理
技术性工程中问题最集中的方面就是缺少对具体变化的管理控制。
要解决这个问题，需要在工程的各方面启用有效的变化管理流程。
解决方法可以很简单，例如被工程团队、工程主办方、相关方认可的流程图。
这提醒了工程人员，变化在被接受之前会进行细致地考察，并且提高了变化提案的门槛。
审查变化提案的时候，要注意该提案是否对变化有清晰到位的描述。
如果变化提案的动因描述得不清不楚，该提案就要打回去，并且要求对变化所带来的益处进行定量评估。
对于那些仅局限于技术解决方案的变化提案，要多打几个问号，因为提案人也许不能全面地判断问题。
如果变化提案过多地关注问题的解决，而不注重实际问题，打回去并要求关注具体的业务形势。
最后，如果不接受某变化提案，一定要做到有理有据。
而且，对工程时间、本钱、精力等其他相关因素所受的影响，进行合理的估计。
六、风险管理
风险管理的流程能让你制定出全面的规划，找出潜在的麻烦，就风险问题的解决方法达成一致，铲除严重的问题。
风险管理要做到事半功倍，就要与工程规划同时进行。
进行工程工作分解安排时，注意对工程活动的不恰当理解；
分配工程任务和开展评估时，寻找风险；
资源匮乏或工程资源缺乏，或工程工作依赖于某一个人时，要知道风险的存在。
分析工程工作将遇到的困难，鼓励所有参与规划的人在规划过程中，设想最坏的情况和潜在困难。
--------------------
1
工程管理工作流程
专业的工程管理是成功工程和失败工程的最大区别
一个借口无
升级会员 