项目团队如何拥有高的协调性
案例正文：
徐家龙最近被公司任命为项目经理，负责一个重要但不紧急的项目实施。公司项目管理部为其配备了7位项目成员。这些项目成员来自不同部门，大家都不太熟悉。徐家龙召集大家开启动会时，说了很多谦虚的话，也请大家一起为做好项目出主意，一起来承担责任。会议开的比较沉闷。项目开始以后，项目成员一有问题就去找项目经理，请徐家龙给出意见。徐家龙为了树立自己的权威，表现自己的能力，总是身体力行。其实有些问题项目成员之间就可以相互帮助，但是他们怕自己的弱点被别人发现，作为以后攻击的借口。所以他们一有问题就找经理，其实徐家龙的做法也不全对，成员发现了也不吭声，因为他们认为我是按你说的做的，有问题你经理负责。 团队成员之间一团和气，“找徐经理去”、“我们听你的”成为了该项目团队的口头禅。但随着时间的推移，这个貌似祥和和团结的团队在进度上很快出现了问题。该项目由“重要但不紧急的项目”变成了“重要而且紧急的项目”。项目管理部意识到问题的严重性，派高级项目经理张凤指导该项目的实施。
请问： 该项目问题出在哪里？ 徐家龙应该怎么做？
分析：
1.项目经理的定位我们先澄清一个概念：什么是项目经理。项目经理就是项目中的总经理，总经理的职责是决策，领导。而不是关注所有的事情。本案例中的项目经理犯的错误在我们身边屡见不鲜，其根源最主要在于：1)项目经理定位不准2）团队无明确的沟通计划
2.只竖向沟通不横向沟通显然不行作为项目经理,你应该要引导成员相互横向沟通后，无法解决的再竖向沟通或开会协商；这就好比民主集中制，要民主，也要有人说了算，案例中项目经理都是自己拿主意，但他不可能在每方面都是长处，长此以往，团队形成一种风气，压力全转移到项目经理处，项目风险也会越来越大。
3.职责、团队、方法论. 一个成功的团队是指由不同技能,才华,工作风格和知识的成员组成的士气高涨的团队.项目经理的职责就是将这些人组成团队并激励他们. 项目经理的技能应包括技术技能和管理技能,坚实的技术基础能够在技术方面对团队起指导作用,管理技能有助于沟通和解决问题.管理技能不仅限于技术方面,还包括解决问题的能力,估算能力,编制计划的能力,人际和沟通能力.所以本案例出现的问题本质是项目经理对自己的职责没有很好的认识，因此在管理团队的方法上也就走了偏路。问题从项目组成员形成了一个习惯（有事找徐...)，失去了团队的协做意义，使团队的实际能力得不到体现；到最后使得项目进度出现严重延迟。
项目管理案例：项目的开发周期
案例正文：
一个项目经理在开发一个为期10个月的项目的三个星期后得到客户通知，项目要在不增加成本，不影响范围和质量的情况下，需要在8个月内完成。
请问：项目经理应该怎么做？
分析：
一、了解客户计划改变的真实原因 在做项目的很多时候，客户方会要求项目在不增加成本，不影响范围和质量的情况下，提前完成，但是一定有他的理由，也许是你的竞争对手采取的措施，也许是我们在做项目的时候有哪些不对的地方，或者是客户遇到新的其他情况不等，但是在客户提出之后，不能明确的答应也不能以强势的态度拒绝，等了解真正的原因后再做打算。
二、向客户沟通 假如必须提前完成任务，要向客户说明其困难，假如公司真的有实力，那就答应他，并适当的拿出合同进行说明，是否在其他方面给予公司补偿。如果公司的把握不是很大，那就站在客户的立场为他考虑，本来十天完成的任务现在8天完成，困难时什么，结果会怎么样，是否采取，按照客户的要求完成部分功能，比如为了迎接上级领导检查，那就把系统的表面工作都做好，要是真正的使用的话，那就把不影响工作进行的部分往后推迟等等，一个项目实施后，所有功能在一定的时间都能使用上的几率不是很大，另外也可以采用在主要功能方面做好，次要方面稍往后放等等方法。
三、从公司本身出发 在不影响范围和质量的情况下，提前完成，我们只有在加班或加人中选择，但是一定要谨慎，因为加人是存在一定的风险的，毕竟项目已经进行了3个月。假如公司实在没有办法的话，那就把部分较独立的功能模块外包出去，当然这是下下策了。 四、团队的管理 在这个时候，一定要在团队的管理方面做好工作，无论从人员的到位，还是人员的情绪，或者其他方面等等做到恰到好处
项目管理中的创新智慧
自从中国改革开放、走向世界，她就登上了全球化的互相依存和竞争的舞台。这个舞台催醒了东方巨龙的创新意识。只有从中国制造走向中国创造，才可能有中华的复兴，才会有自立于世界民族之林的能力。
但是创新不能停留在口号上。如果说中国人缺乏创造性，你一定不会同意。然而说在中国成功地走到了„智慧型组织'阶段的企业还凤毛麟角，你大概不会反对。肖知兴在他的《中国人为什麽组织不起来》一书中分析其原因，强调了价值观、信念和文化的力量。确实创新需要有群体智慧和组织文化。本文把这个大问题收缩到项目管理领域，看看情况又是怎么样呢？
项目经理们喜欢这样的赞誉"你驾驭的„列车'总是准点到达并且不超过能耗指标"。他们通常都是一些做事非常专注，习惯严格按预定框架和程序办事的人。很少从他们嘴里冒出创新这样的词。很不幸，其实这是一种认识上的疏漏。许多企业忽略了组织文化这个因素，不知道如何在项目管理的框架里培育创造性。 项目管理中的创造性并不是与规范化、标准化相矛盾的，它确实存在并有助于时间和金钱的节省。我过去也写过文章，认为项目管理应当是标准化和个性化的融合。
创新的赛场有边界约束 许多人有一种误解，认为有创造性的人必须是不受任何拘束的。然而，项目管理结构就像一个创造能力的比赛场地，它确实是有边界的。 尽管灌输这样一种充分评价创新价值的理念是重要的，然而领导者仍然需要对创新设置必要的界限。如果没有适当的边界和领导，无序的创新性必然会将项目引向一片混乱。 在整个投资组合的范围中保持工作流程的连贯、一致非常重要。这将有助于在全企业内为创新建立一个坚实的„巨人的肩膀'，否则创新只会是胡闹的游戏。这包括维持稳定的规章制度和行为准则，像制订计划进度和预算等都要有一定的程序，不要随意变更。在项目一
开始就应建立好一个总的章程，并且在整个项目过程中维护好这个章程，使其能够得到有效的遵循。这可以避免许许多多问题和麻烦的产生。其实真正的„创新狂躁'来自高层头脑发热的、糟糕的领导。 无疑，公司高管应找到一种办法来培育创造能力，以提高项目成功的概率。项目本身是一类独特的过程，所以对于具有突破性的创造存在着许多机会，特别是在立项和寻求缩短工期、节省费用、提高质量的努力中。
过度控制抑制创造性 要使项目能具有创造性，公司高管需有慧眼识别和启用能评价、鼓励创新精神的项目经理。不要因为有些创新的意见被认为„说起来容易、做起来难'，就对其嗤之以鼻。为了使工作团队有最佳的发挥，一个项目经理需要具备指导、支持、教育和委任的技巧。控制性的领导往往一切自己决定并监视部下的每一个工作细节，这样必然抑制创造精神。
有时候简便的技巧比高超的技术还更管用。美国新泽西州的一位创新和领导力咨询顾问Wayne Morris认为，一个有创新能力的领导人的主要作用是设计和维护好一个支持创新精神的、安全的心理环境。为此，他提出领导者应具有：接受风险的承受力 对智者失误（非愚蠢的失误）的经验价值的理解 相互交流、沟通的平易 鼓励创造激情的能力 授予部下一定自主权的民主意识 给部下个人事宜留下适当时间的宽容 乐观的态度 鼓励意外发现的能力 对悖于常理的言论的宽容
全面培育创新意识 创新的项目管理贯穿项目的全过程，从建立一个创新的框架开始，让大家去思考如何找到一种与众不同的好方法来节省时间和金钱。美国西雅图的一位创新管理顾问Donna Shirley说，以她的经验创新的机会无处不在，不要仅仅满足于技术性的创造，还需要管理的创新以及用人机制的创新。
创新仅仅依靠个别人的天才也是不够的。个别人单枪匹马的创新能力不可能真正把事情做好。整个团队必须具有集体的创新智慧和创新文化。
工作流程中设定创新空间。 组织应在工作流程中给予创新一定的空间。你可以也应当把创新列入计划之内，但务必将其放在需要的地方。 创新这类工作方式的特征就是随心所欲地放纵思维，并为关闭狂想闸门的最后时刻设置好底线。对大多数人而言，在给出限定条件的情况下会工作得更好。项目管理的责任就在于设定合理的边界，给创新留出空间，并让你的团队成员都知道。这将有助于他们最好地发挥创造性，而且不会无端地浪费资源。 要让人们知道遵守工作流程的好处，你必须尊重有创新精神的人，告诉他们在什麽情况下可以做新的尝试并允许犯错误。然而，同样重要的是，也要让他们尊重项目管理的工作流程。一个好的领导者要鼓励创新，但不允许随意破坏工作流程。
软件外包项目中的进度管理
案例正文：
A公司是一家美资软件公司在华办事机构，其主要的目标是开拓中国市场、服务中国客户，做一些本地化和客户化的工作。它的主要软件产品是由总部在硅谷的软件开发基地完成，然后由世界各地的分公司或办事机构进行客户化定制、二次开发和系统维护。这些工作除了日常销售和系统核心维护之外，都是外包给本地的软件公司来做。东方公司是A公司在中国的合作伙伴，主要负责软件的本地化和测试工作。 Bob先生是A公司中国地区的负责人，Henry则是刚刚加入A公司的负责此外包项目的项目经理。东方公司是由William负责开发和管理工作，William本身是技术人员，并没有项目管理的经验。当Henry接手这项工作后，发现东方公司的项目开发成本非常高，每人每天130美金，但客户的满意度较差，并
且每次开发进度都要拖后，交付使用的版本也不尽如人意。而且，东方公司和A公司硅谷开发总部缺乏必要的沟通，只能把问题反馈给Henry，由Henry再反馈给总部。但由于Henry本身并不熟悉这个软件的开发工作，也造成了很多不必要的麻烦。
为此，Bob希望Henry和William用项目管理的方法对该项目进行管理和改进。随后，Henry和William召开了一系列的会议，提出了新的做法。 首先，他们制定了详细的项目计划和进度计划；其次，成立了单独的测试小组，将软件的开发和测试分开；并且，在硅谷和东方公司之间建立了一个新的沟通渠道，一些软件问题可以与总部直接沟通；同时，还采用了里程碑管理。六个月后，软件交付使用。但是客户对这个版本还是不满意，认为还有很多问题。为什么运用了项目管理的方法，这个项目还是没有得到改善？
Henry和William又进行了反复探讨，发现主要有三个方面问题：1、软件本地化产生的问题并不多，但A公司提供的底层软件本身存在一些问题；2、软件的界面也存在一些问题，这是由于测试的项目不够详细引起的；3、开发的周期还是太短，没有时间完成一些项目的调试，所以新版本还是有许多的问题。
此时，Henry向Bob提出是否采用公开招标的方式，选择新的、实力更强的合作伙伴。但Bob认为，与东方公司合作时间已经很长了，如果选择新的伙伴又需要较长的适应期，而且成本可能会更高。于是，Henry向东方公司提出一些新的管理建议。首先，他们采用大量的历史数据进行分析，制定出更详细的进度计划；其次，要求东方公司提供详细的开发文档和测试文档（之前William的团队做的工作没有任何文档，给其他工作带来了很多困难）；第三，重新审核开发周期，对里程碑进行细化。
又过了六个月，新的版本完成了。这一次，客户对它的评价比前两个版本高得多，基本上达到项目运行的要求。但客户还是对项目进度提出了疑问，认为实时推出换代产品不需要那么长的时间。
分析：
软件外包是现在软件工程中较常见的做法。在软件外包工程中，保证质量的进度是很难控制的。对于项目经理来说需要一整套复杂的能力，比如制定计划、确定优先顺序、干系人的沟通、评价等，每一种能力都与项目的最终结果有直接或者间接的关系。 然而，国内的项目经理大多没有接受过正规训练，缺乏项目管理方面的专业知识的技巧，往往只是凭借以前的少量经验盲目去做，容易出现各种问题。尤其是在管理外包项目时，缺乏足够的经验和技巧，往往造成进度不断推迟，而质量无法保证的情况。 前文是一个比较典型的软件外包项目的案例。在这个案例中，我们可以看到现在IT业内许多外包项目的影子。 在该案例中，东方公司没有专门的项目经理，是由技术人员William兼做管理。这是国内软件公司经常会出现的问题。最初，出现进度落后的问题时，A公司的Henry与东方公司的William讨论后决定采用项目管理中计划管理等手段，其中包括里程碑管理。这是控制进度的较常见做法。
里程碑管理的引入 一般来说，在项目开始时，项目组成员都会对项目制定一个详细的计划。通常情况下，在明确的工作说明书（SOW）和WBS的基础上制定具体的进度计划时，需要采用一些具体的技术。像这种软件外包项目，最成熟的技术是里程碑管理。 里程碑一般是项目中完成阶段性工作的标志。不同类型的项目，里程碑也不同。比如，在开发项目中，可以将需求的最终确认、产品移交等关键任务作为项目的里程碑。本案例中，Henry在接手项目后采用里程碑进行管理是很恰当的不过，要注意的是，每到一个里程碑处，应及时对前段工作进行小结，并对后续工作进行计划调整。对于一些管理效果明显的领域，可以不必投入较多精力。而对于下一步管理过程中可能会出现问题的领域，应给予较
多的关注。当然，在软件项目里，进度的变化是较常见的事情。
在本案例中，采用里程碑管理后仍没有达到客户的要求，进度依然拖后。在这里，就需要考虑另一个因素—质量与进度的关系。
质量与进度关系 通常，项目管理的前提是保证在预算内、满足质量的前提下，按进度完成项目。因此，可以看到，保证质量是前提。那么，如何在满足质量的前提下管理进度呢？单纯从项目管理理论知识中并没有一种有效的方式。笔者通过实践，推荐一种较实用的方法。具体步骤为： 首先，尽量利用历史数据。在本案例中，Henry应该调查之前的项目情况，将会发现可以类比的情况，事先就可以知道需要管理质量和进度的关系。 其次，由于此项目是软件外包项目，Henry不能完全掌握项目的资源调度情况，因此缺乏对质量的控制。这也是大多数外包工程中最令人难以掌握的地方。在这里，可以采用对进度管理计划添加质量参数的方法，也就是通过参数调整进度和质量的关系。 这一做法的前提是要有一定的历史数据。比如，从历史数据中得知，完成子项目的时间是5天，测试后有15个问题；完成同样子项目的时间是7天，测试后有10个问题；完成同样子项目的时间是8天，测试后有5个问题，……以此类推。随着数据的不断增多的，采用两维坐标图，就会得到一些离散的点（不考虑资源的差异），并形成一条曲线，见图1。考虑项目允许的质量范围，对照图中的数据，找出相应的参数。根据得到的参数，确定一个合适的进度计划。
进度与成本的关系 在本案例中，Henry发现东方公司进度一直拖后，成本却居高不下。这里就需要了解软件外包项目中进度与成本的关系。很多时候，此类工程大多采用固定总价合同。但由于软件项目的修改比较多，实际上此类合同很像是固定总价加奖励费用，其中奖励费用一般会采用单价合同，即若干元/人天的合同，也就是说，承包商的成本是建立在人力成本估算上的。这样，一些承包商会倾向于拖延进度（或者减少实际投入，造成质量下降）。因此，项目经理需要了解整个合同的情况，最好参与合同的制定。在此案例中，Henry试图通过引入竞争来提高整个项目的效率，满足项目目标，也是出于同样的原因。尤其值得注意的是，有时候，出于竞争的需要，承包商会提供低廉的价格，此时对于进度管理更应该谨慎和完善。
还要指出的一点是，要对学习曲线有深刻地认识。在软件开发工程中，学习曲线（learning curve）有很大的用途。通常情况，承包商在接到同样类型的软件项目后，第二次会比第一次节省15%-20%的时间。项目经理最好要了解一下以前类似项目的情况。
综合管理:如何成为一个受欢迎的项目经理
程序员的一个重要的职业发展方向就是项目经理，然而，做一个项目经理和做一个程序员是有很大区别的。项目经理需要面对的人和事更多而且更复杂，需要具备更多的知识和技能才能够胜任。
正文 项目经理是整个项目的负责人，对项目成败负有直接责任。项目经理需要打交道的各方面的人很多，需要处理的事情也很多，要做一个受欢迎的项目经理更加的不容易。那么，怎样才能做一个受欢迎的项目经理呢，我们从Who-What-How这三点出发，来共同探讨这一问题。
Who—受谁的欢迎：
项目经理同时要面对来自内部和外部两方面的对象。外部对象——项目的所有干系人都是项目经理要面对的，内部对象——项目经理的上级领导和项目组成员，也是需要关注的。
What—受欢迎的标准： 项目干系人在不同类型的项目中有所不同，比较普遍和主要的包括：项目发起人、出资人、相关业务部门负责人、最终用户等。对于项目发起人来说，能够保证项目按时完成、满足
功能要求同时又能保证质量的项目经理最受欢迎；对于出资人来说，能够保证项目的费用不超出预算的项目经理最受欢迎；对于业务部门负责人来说，分两种情况，一种是项目的推进对其有利，他们对项目经理的要求与发起人基本一致，另一种情况是项目的推进对其有不利影响（比如改变现有流程、权力回收等），想得到他们的欢迎可能很困难，这个时候项目经理只能尽力减少他们对项目的抵触心理和对项目经理的敌对情绪，以可以接受的代价为其考虑的更加周全，尽量提高受欢迎的程度；对于最终用户来说，能够提供方便易用的软件和全面及时的培训的项目经理最受欢迎。
对于项目经理的上级领导来说，能够保证项目按照进度、成本、质量的要求顺利完成的项目经理最受欢迎；对于项目组成员来说，能够明确给出项目目标，合理安排分工和分配任务，具有亲合力和容易沟通的项目经理最受欢迎。 How—怎样做到： 计划制定能力。一个项目涉及到的事情总是千头万绪，如果没有很强的计划能力将很难成为合格的项目经理，要善于制定各方面的计划，并按照计划执行各项工作。随着项目的开展，还要不断的调整和更新相关计划，保证计划的合理性和可执行性。 项目控制能力。包括对项目的范围、进度、成本、质量各方面的监督和控制。善于利用各种分析工具来全面了解项目的进展情况，及时发现项目存在的问题和风险，并采取适当的应对措施，在需要的时候向上级领导汇报并寻求支持。 时间管理能力。把握项目进展的节奏，合理安排各项任务的重要性和优先级，保证项目组可以定期地交付一些可见的工作产品，以避免项目干系人因长时间看不到项目的进展而给项目组施加不必要的压力。 成本控制能力。项目的费用成本也是各方关注的焦点，项目经理要能够利用费用管理工具及时掌握费用花费情况，尽量减少不必要的开销，对于无法避免的用户额外的要求，则要善于争取费用的追加。 沟通交流能力。项目经理需要面对方方面面的人，并同他们讨论林林总总的事，因此，顺畅的沟通和交流是必不可少的。项目经理必须要善于根据不同的沟通对象来选择合适的沟通渠道、沟通方式和沟通频率，并在沟通过程中采用适当的技巧获得对方的支持和认可，使得项目可以顺利进行。
团队建设能力。项目不是靠PM一个人来完成的，需要所有的项目组成员共同努力。作为团队的领导者，项目经理要善于通过各种培训、团队活动、奖励和表彰等手段，加强成员间的互相了解，使得每个成员的力量逐渐整合为一股合力，从而达到1+1>2的效果。 后记
项目经理需要考虑的问题与程序员完全不同，对项目的成败负有完全的责任，必须具备更多的管理技能。项目经理除了要保证项目按照要求顺利完成之外，还需要面对项目组内外的形形色色的人和事，处理不断发生的各种风险和冲突，因此，项目经理只有具备了更多的知识和技能，才有可能成为一个受欢迎的项目经理。
外包仍需要项目管理
案例正文：
公司外包的网站出了问题，身为公司信息部门主管的何经理最近有点烦。
何经理所在的公司是一家制造行业的民营企业，主要生产管件、轴承等产品，由于地处东南沿海，何经理的老板对于信息化很重视，眼看着一个个行业类网站如雨后春笋般建立起来，何经理的老板也想通过电子商务给企业带来一些新的销售渠道。
虽然何经理所在的公司总体规模不大，但具体到轴承和管件等产品，这家公司在行业内排名还是很靠前的，因此，在何经理建议做一个企业门户网站时，老板觉得，那样还不如直接做一个行业网站，只针对轴承行业。这样一来，不仅可以帮助自己的企业拓展业务，还能帮助同类企业。何经理的老板甚至还在想，行业网站做得好，说不定会给自己的企业带来新的赢利点。
不过，何经理所在的信息部仅有三个人，除了维护企业内部的IT系统和硬件之外，他们已经没有精力再做一个行业网站，做网站对于何经理来说，也是一个新的领域，他在技术上并不是很强。
做专业的事就要找专业的人，在网站建设上，何经理和老板经过多次沟通，决定把网站建设、运营、管理等全部外包，交其他公司或个人处理。
但关于域名、空间等的选用，以及关于网站内容、版面的策划，再到对于市场的分析、目标群体的分析等方面，何经理他们并没有太多的想法，他们觉得，既然花了那么多钱，自己就不用投入太多的人力物力了。
另外， 何经理所在的公司有60%的产品都销往海外，公司主要针对海外客户。于是，何经理考虑到，一个好的网站就成了一个窗口，向海外客户展示企业产品、宣传企业理念、维护企业形象。而且国外不再通过文本的方式进行贸易，都是利用电子邮件的方式。 这样，网站成了与国外客户交流、贸易的最好方式。所以何经理在策划网站建设的时候，决定在做中文网站的同时推出一个英文版。公司开始策划企业网站，并和国内一家提供网站服务的公司签订了合同，约定该公司为他们建设一个中英文双语版网站，并支付了40多万元的服务费。这家网站服务公司承诺赠送网易、SOHU、TOM等网站的推广一年，并提供.com的域名一个，期限为三年。可是，由于这家网络服务公司未按照约定及时进行网站的注册，就在双方签订合同没几天，原来这家公司承诺给何经理的.com的域名已经被别人抢注。在这种情况下，这家网络公司并没有与何经理商议变更合同的问题，就擅自为他们注册了.net的域名，并在该域名下制作网站。不仅如此，网站制作的进度也大大超出了他们最初的承诺，内容同样存在多处不完善的地方，英文版的超链接更是拖了半年多才完成。
分析：
何经理原本想通过一个行业网站推广自己的企业，进而为同行们服务，可是，外包的网站建设一波三折，让何经理有些灰心。他开始怀疑当初是不是该建议老板做这样一个双语的行业网站？即使要做，他又该如何做，是不是完全外包给网络服务公司？
本案例所描述的网站外包事项具有良好的出发点、可取的方法和准确的目标，项目实施之所以出现令人不满意的地方，根本原因在于双方存在认识上的差距，表象就是缺乏沟通，没有开展有效的项目管理。 作为一个直接面向市场销售产品的制造型企业，规模不大，而且60%的产品销到海外，有一个高效的企业网站是十分必要的，出发点很正确，目标可以清楚预见。
至于是否建立一个行业网站，要看在轴承生产行业是否有很专业的网站。当然，以排名靠前企业的身份建立一个具有特色的行业网站也不失为好的想法。在信息部只有3名员工的情况下，服务外包是极其正确的一种策略。即便是本企业有很强大的信息化建设力量，外围建设及维护服务往往也是较好的选择。专业化的成果只有通过专业化的服务来获得。
换句话说，在网站建设立项初期，目标和方法都很明确，即服务于全球客户，从项目管理的角度分析，可能出现的风险应该较低，也许会出现个别难题，但只要有缜密的实施计划和严格的项目管理，潜在的风险都可规避。其实，单就网站本身建设与维护而言，在企业信息化项目中其难度相对较低，投资也不大。那么，为什么在企业网站建设中还是出现了一系列的问题呢？
网站建设之所以一波三折，问题主要就出在项目管理方面。项目虽简单，但并不意味着建设和运营管理一帆风顺，从而甲方可以撒手不管。正相反，同样也需要按照一个标准的信息化项目来进行管理。虽说行业网站的内容复杂度会高于企业网站，但建设过程大同小异。如果对症下药，在建立行业网站过程中完全可以避免类似情况的出现。具体说来，主要改进如下几点。
甲方零工作量的误区 网站外包不等同于甲方零工作量。任何项目都需要理清合作各方的工作内容，甲方必须主导项目的进展，以满足各利益相关方的要求。每一个阶段都不可能离开甲乙双方的配合，启动阶段尤其如此。至于域名的注册与管理，是一件非常简单的工作。无需耗费太多的人工，不一定外包。 如果企业期望注册的域名已经被抢注，可以买回或者更换成类似的名称来解决，这不应该成为制约网站开发的一个重要因素。
拒绝松散管理 每一个信息化项目都不容松散管理。信息化项目通常会有需求调研、设计、开发、测试、试运行、上线和维护几个阶段。各阶段均应按照项目管理金三角设置专人实时跟踪、参与、审查和评价其质量、进度，控制资金投入。
在关键阶段，为避免方向性的错误和工期严重耽误，现场及时监督、指导、讨论和纠正不可或缺。何经理所在团队缺乏人力和技术力量，可以考虑委托具有经验的第三方代行其职能。
确立正确的方法论 该企业制定的外包策略虽然很正确，但乏于具体实现方法，从而导致大量问题出现。网站建设是一个典型的需求驱动项目，花大力气摸清需求是成功实施的根本。技术实现、版面设计是专业网站建设队伍的强项，但网站的主题、基调、展示思路和内容重点只能由企业自己说了算。
何经理及其团队不熟知网站内容布局和版面设计在情理之中，但这并不说明他们可以不去协调、组织整个项目。网站是企业的信息窗口，良好的需求分析等于成功了一半。如果何经理有信心自行组织，在网站设计开发之前就应在开发单位的配合下做好。如果没有自行组织的可能，可以寻找一些专业的咨询顾问来代为实施，提出多种可靠方案，最后由何经理及其老板选定。
把握关键控制点 有了正确项目实施策略、方法与计划，余下的工作重点就是把握住关键控制点。这实际也是项目管理重要的一部分。例如，前文提及的需求分析确认和版面设计审查等都直接关系网站建设的成败。 另外，英文版的网站对于该企业来讲甚至比中文版意义更加重大，网站开发队伍未必在语言翻译和英文网站布局方面很强，尤其是专业性很强的领域。因此，英文材料的提交、版式的确定和开发效果的审核都应该是何经理关注的关键点。
选择合格的实施队伍 实施队伍的诚信和服务质量直接影响甲方的参与工作量和项目的成功率。从擅自修改域名这一事实来看，案例中的网站开发商不值得信赖。工期拖延和内容不完善显示出该开发商在项目管理和服务品质保障方面很不力。由于缺乏精力和经验，何经理的部门无法起到很好的主导作用。 良好的开发商在洞察这些情况以后，应该占据主动，积极采取措施，及时引导并与何经理的团队沟通，共同寻求每个问题的解决方法以实现合同规定的目标，而不是消极被动地迂回或放任自流。如果继续做行业网站，可以考虑选择更好的队伍。
正确评判网站建设成果 网站的制作仁者见仁，不能期望短期内面面俱到。应以满足最初定位和持续攀升的点击率来评价其优劣。在页面基本框架和展示风格确定的情况下，作为一个制造型企业应以方便客户为宗旨，让网站访问者最简单快捷地寻找到想要阅读的信息或完成网上操作。至于次要的内容，可以分步完善和上载。
完善配套的管理制度 制度是项目良性运作的保障。众所周知，任何信息化项目不可能由信息部门独立完成。信息上载、版式调整和内容更新等是长期的工作，每个部门必须各司其职、相互配合，才能确保网站的时效性和生命力。内容不齐全，责任主要在于甲方。网站栏目设计与调整技术上不困难，只要有需求就可以实现。如果有了栏目，缺少内容，何经理应该通过制度和老板这两个利器调动大家的积极性，及时准确提交或者上载有关的信息。如果建设行业网站，该企业是领头羊，更应该在产品信息、行业文化方面及时更新内容，起到风向标的作用，而不能一味的认为是网站建设方的问题。
如何走出项目规划陷阱？
案例正文：
2005年12月，宁波开云公司与宏研公司签署合作协议，实施SCM（在线供应链管理系统）。但是，直到今年6月份，双方也没有确定出一个认可的方案，项目的进展几乎陷入困境，用宏研公司项目经理李凯的话说：“我现在已经害怕接到开云公司CIO张励的电话。”这是为什么呢？ 何以反复修改解决方案？ 开云公司是宁波市的一家小型零售连锁企业，总部设在宁波，目前已在宁波下属一些县区设有分部。业务扩张后，企业内却出现了一系列的问题：各门店之间、门店与总部之间、与供应商之间的信息管理系统是不相联接的，各店也是分别向供货商采购，这样一来，开云公司实际上就成了单店经营，一个个店其实就是一个个“信息孤岛”，规模优势和集团优势难以发挥。面对这些问题，开云公司急于借信息技术来提升整体管控能力。
最初，李凯为开云公司量身打造了一个以门店为中心的B2B电子商务平台，包括基于Intranet内网的报表统计系统，基于Extranet外网的e-SCM供应链管理系统等。系统功能包括在线结算、信息分享（销售、库存、补货、结算）以及品类管理及分析。方案实现了开云公司多家门店与供货商之间的电子订单、对账、经营数据分析、查询等协同商务工作。 没过多久，张励就发现，上游供货商出于各自业务统计和分析的需要，会对自己所经营的商品采取一定的分类标准和编码规则，即使同一连锁集团内，各门店所
经营的商品种类、商品编码、价格等属性也可能各不相同。所以，方案必须解决一定标准下信息转换的问题，否则B2B电子商务平台就是一句空谈。针对张励提出的问题，李凯把方案做了调整，开发出了异构系统之间的“翻译”模块。 不久，张励又提出了新的要求：在总部建设数据中心系统，包括基于数据仓库的CRM顾客关系管理系统。当然，李凯对项目方案也做了再次调整。 每一次方案的调整，对李凯都意味着繁重的工作量，要对开云公司的工作流程仔细调研，制订方案，甚至要与其上游厂商进行沟通，确保方案的可行性。满以为经过几次的调整，这回应该让张励满意了。然而事情又出现了新的变化，张励需要一套BI商业智能系统为企业的决策提供支持。 到底怎么做 客户才满意？ 这一回，李凯再也坐不住了。第一，项目方案又要调整，这会是一个较长的时间，而且不知道以后还会怎样变化；第二，李凯认为，对于开云公司来说，BI商业智能系统的考虑太长远，目前的数据量太少，项目实施后数据量的增加也会是一个长期过程，没必要现在就做全部规划。 作为企业CIO，张励有不同的意见：现在的零售连锁竞争相当激烈，企业要考虑长远的规划。系统上线后，随着供货商和各门店的数据共享，信息量不断扩大，需要一套BI商业智能系统为企业领导的决策提供帮助。这样才会在竞争中保持不败。
项目初期就遇到了如此多的问题，张励认为“用户更喜欢一个能提出个性化解决方案、碰到问题都能够解决的供应商，能根据企业的发展提供符合要求的差别化服务。”而李凯却有自己的苦恼，客户不断要求改变方案，经常把做好的方案推倒重来，解决方案的供应商根本没有办法控制成本且无所适从。更何况，有些方面的规划并非客户所急需。 双方各执一词，为我们带出了两个问题：在项目规划上，解决方案供应商与客户之间如何才能更好地沟通和协调？项目究竟应该满足现有的应用需求，还是也要满足未来的应用需求？
分析：
发现信息化规划中的陷阱 开云公司的项目规划案例是一个普遍现象，折射出当前许多企业在软件选型过程中所遇到的问题，而“软件项目规划应该如何做”正是该问题的核心。 众所周知，不管做什么事情都需要有一个总体目标和规划，在总体规划下进行目标分解，不断细化阶段性目标和规划，才能保证把事情作对，不脱离正常的轨道，从而让投资得到最大的回报。软件作为一种信息化管理的工具和手段，是为管理服务的，因此它的规划必须能够适应企业的发展，满足企业某一时间段的需要。 综观这个案例，当事双方存在如下几个问题值得思考。
①项目的目标和范围定义不够明确。不难看出，两家公司在目标上是有些不一致的。开云公司认为他们只要是碰到的问题，包括以后可能遇到的问题以及对未来的一些想法就应该在此次项目中实现。而宏研公司则认为他们的目标只是解决目前已经存在的问题，过于长远的问题不是他们此次项目需要考虑的。这样就因为目标、范围不够明确，导致双方各自站在自己的角度和立场去想问题，从而产生了一些分歧。 ②没有进行业务框架梳理，缺少咨询环节。此次项目一开始就很仓促，开云公司没做好需求整理及规划就找来软件厂商进行选型，可以说，开云公司只是大概知道他们需要什么，但还不能清晰定义出这次项目的具体范围及未来IT架构整合的问题，这是一个主要原因，也是起因。
而宏研公司在作为合作伙伴进行调研时，也只是对现存的问题进行了规划，没有帮助开云公司对整体的业务框架进行梳理，同时也没有从软件公司的专业角度提供一些建设性参考意见，而只是单纯从目前业务需要给出方案，没有从更为长远的角度帮助客户去考虑问题。
浅谈房地产项目风险管理
一、引言 20世纪90年代，我国房地产行业过度膨胀引致整个行业一度萧条的余痛在某些地区尚未消失，今天该行业又再度展现了如日中天的投资气氛。在乐观的投资气氛背后有很多投资者因为无法抵挡风险的袭击而投资失败，因此，对房地产项目实施风险管理就显得至关重要。
二、房地产项目风险产生的原因
房地产是一个特殊的行业，它具有以下特点：投资额大、建设周期长、资金周转慢、变现能力差，涉及到的社会、经济和环境因素多，其投资过程是一种预测未知将来需求而进行产品生产的过程。这些特点决定了房地产业是一种典型的高风险投机行业。其次，由于房地产的地区差异、项目差异，涉及的内容不单单是技术问题，还有很多其它方面的问题，因此，国家很难像针对建筑工程那样去制定房地产项目风险管理的统一规范和规程。这一切都决定了房地产行业的高风险性。
三、房地产项目主要风险
在房地产开发的不同阶段存在不同风险
1、投资决策阶段的风险
投资决策阶段的风险主要有开发区域风险，开发物业类型风险，开发时机风险和开发项目的定位风险。
2、土地获取阶段的风险
土地风险主要来自于土地自然属性、社会属性和土地规划部门对土地使用性质和规划设计指示的不确定性。购买了土地使用权后，还有大量的征地、拆迁、安置和补偿工作。
3、项目建设阶段的风险
项目建设阶段的风险主要来自设计理念的落后、建筑物实用性差、甚至由于承包商建筑技术落后、施工方案与方法不同、偷工减料以及项目监管不负责任等导致建筑物存在质量安全隐患。
4、售管理阶段的风险
这个阶段的主要风险有销售时机的风险、租售合同的风险、自然灾害的风险和意外事故的风险。
五、房地产项目风险管理与控制
1、风险分析
风险分析一般要经过三个步骤。一是风险辨识阶段找出风险因素，研究风险因素会造成的后果；二是风险估计阶段，根据已有资料和经验对各风险因素可能发生的概率及对项目的影响程度做出估计；三是风险的评价阶段，采用适当的方法对各种风险因素的影响进行评价，即确定风险的概率分布。 项目管理者联盟，项目管理问题。
2、风险预防
在风险发生前，为了消除或减少可能导致损失的各种风险因素，而采取的各种措施称之为风险预防。风险预防贯穿于房地产开发经营的各个阶段。
在投资决策的阶段，房地产开发企业风险预防的主要任务包括：
（1）建立高水平、多学科的开发人员队伍。
（2）建立健全风险预警系统。
（3）贯彻执行风险管理责任制度。
在土地获取阶段，开发商应该重视以下几个问题：履行开发商的社会责任，积极主动的与各地方政府管理部门和土地所有者搞好关系， 妥善处理征地、拆迁和安置补偿工作中遇到的棘手问题。增强合同意识，
认真签订各种相关合同，尽量避免合同歧义。
项目建设阶段风险预防的主要措施有：高度重视项目建设中的安全问题，在现场控制中，减少风险源，防止风险扩散， 特别是强化现场质量监控，防止出现质量缺陷和建筑工程质量。及时协调、妥善处理建设过程中的设计、施工、监理、材料设备供应之间的矛盾，使项目的建设顺利的进行
在房地产开发租售管理阶段，为了预防风险，应当特别重视租售合同条款的明确、详尽,并聘请律师或法律工作者审核。
3、风险转移
可以采取工程保险或工程担保的方式来转移风险。
4、风险管理
合理界定项目覆盖的范围，在企业发展规划和战略的总体要求下，用科学的方法和态度进行项目决策，确定项目目标，避免出现决策失误风险; 编制《项目管理规划》，用《项目管理规划》指导项目的建设和管理; 理顺组织结构，明确岗位职责，建立项目的反馈沟通职能，为风险管理提供组织保障。
5、风险抑制
风险抑制是在风险发生时或风险发生后采取的各种降低损失程度或缩小损失发生范围的措施，目的是使风险发生时损失最小，风险发生后有挽救措施。
房地产是一种投资大、周期长、内部结构复杂、涉及因素众多的复杂开发系统，影响该系统的风险因素众多，影响关系错综复杂。同时，不同风险因素引起后果的严重程度迥异，项目能否取得预期结果具有很大的不确定性，因此，在项目风险管理中，应进行科学的、系统的风险分析，风险预防，风险转移，风险管理，风险抑制，将风险损失降低到最低程度，确保建设项目取得良好的社会和经济效益
③项目方案没有一个总体构架。方案多次修改虽然同用户的项目目标、范围不明确有关，但宏研公司没有帮助一起进行总体构架也逃不了干系。如果宏研公司能够多花一些时间同开云公司讨论总体构架，那么后面所碰到的编码转换、商务智能等问题可以提早被挖掘出来，不至于最后被动应付方案的不断调整。 要避免类似案例所产生的问题，重点在于如何科学有效地进行企业信息化的规划。
解决问题：信息化规划四步走
针对企业信息化规划，我们应如何进行，在每个步骤中又应注意什么要点呢？
首先，需要按照企业运营模式和业务特点进行总体规划。从企业的运营模式和业务特点入手，明确了解企业的发展方向、业务模式及其核心竞争力，定义出核心业务与辅助业务，则整个信息化的核心目标就能够体现出来。
需要强调的是，除了需要考虑到现有状况之外，还需要能够兼顾未来，也就是说在做这样的规划时，需要为未来的10到20年打下一个基本框架。后期可以随业务做一定的调整和扩充，但整体的框架是不能够随意更动的。当然，这样的工作企业自身未必能够独立完成，可以找软件咨询公司协助规划，提供业内的最佳实践案例作参考，以保证规划的合理性。
其次，将信息化目标进行分解和排序。建立企业的整体信息化框架，这只是一个框架性的目标，是无序的。我们应该把这些目标细化、分解，根据企业的发展阶段按重要性排序，以确定什么时候需要完成什么样的信息化目标。
再次，进行IT系统规划。当我们把阶段性的信息化目标都定义清楚之后，就能够进行IT系统的规划，对一些业务边界进行细分，以明确定义出有哪些IT系统，分别负责什么样的业务，IT系统之间有什么样的联系，需要什么样的建制关系等等。
最后，分步实施。通过前面的三步，这时，每个软件应该大致负责的业务范围都已明确，同其他系统的整合要求及未来的功能预留也有了定义，软件选型也会更有目的性，更容易操作，容易通过软件实现管理效益和避免软件投资风险。
所以概括来说，这个案例所碰到的客户同软件厂商之间的项目沟通和协调问题，以及到底是满足目前业务还是未来业务的问题，都可以通过总体规划、分步实施来从根本上解决。
实践出真知之透过案例看实施
项目的实施工作，何以谓之成功？由于软件产品的特殊性，决定了这种项目的成功标准是很难被量化的，验收缺少清晰的数字指标。对于客户而言，在一个合同里面获得最大的管理价值，包含最广泛的业务应用，是他们对成功的看法；而在供应商眼里，项目就是项目，早日验收早日回款，是他们追求的目标。双方立场的差异，导致项目在进行中会出现各种情况影响到项目的验收。如何减少分歧，按期完成项目，就成为了项目组最大的挑战。 一般来说，我认为项目的实施需要遵照以下方针：加强沟通，精细计划，全力推行，利用资源，随机应变。 怎么解释呢？“加强沟通”，沟通是应该占据项目组成员最多时间的工作。他们不光要跟客户沟通，还要跟后方的销售人员、开发人员、测试人员多交流，以及包括了项目组内部的信息交换。实施人员应该是信息的中转和汇总的枢纽，获得的信息量越大，项目现状就越透明，对后续工作的把握就越大。PMBOK中提到，一个项目经理有90％的时间都是在沟通上，可见这项工作的重要性。 “精细计划”，这个需要考验PM的功力。一个合理的计划，是项目能够成功的先决条件。PM要最大化了解项目的相关信息，包括资源、风险、客户特点等等，然后制定出一个适合项目特征，甲乙双方都有能力去实施的计划，并界定出项目边界和里程碑。从这一刻起，就要为项目的最终验收开始努力。 “全力推行”，指的是项目小组成员要明确以验收为中心，计划是准绳的目标，想方设法去按照计划推动项目的开展。这个过程中肯定会出现各种各样的状况，也是项目最复杂，头绪最乱的时候。运用各种手段，来全力保障计划的按期执行甚至提前进行，是项目组所有成员的职责。 “利用资源”，资源是什么？只要一切有利于项目推进，有利于最终验收的人、财、物，甚至气候、政治动态等等，都是资源。例如说甲乙双方的高层领导是资源，一台大内存的测试PC是资源，哪怕即将来临的雨季也是资源。项目经理要善于考虑可以利用的资源，敢于申请资源，然后把它用在项目所需要的地方，来解决一切干扰项目进度的问题。 “随机应变”，没有到来的时间里总是充满了未知的因素，有不少是风险管理中无法预料的事情。这个时候该怎么处理，处理的后果会产生什么影响，还有没有更合适的办法都在考验PM。这就需要PM运用其综合能力，包括经验、技术能力、个人性格等，临时来找到有效的解决意见。以上谈到了项目实施的主要方针，我们再来看几个真实的案例，从中进一步理解。
案例一：
某PM所做的一个局级OA项目，经过前期的工作以后已经进入了试运行阶段，情况良好，正准备验收。这时机关上调来了一个常务副局长，他提出OA中缺少劳资管理的功能，需要补上。PM并没有马上允诺或拒绝，而是找甲方关系较好的人员作了了解，原来此领导原来是主管人事出身，只对这块比较有发言权。PM就找到了这位副局长，提出要为他专门做两张报表，能够从既有数据中进行人事相关信息的分析。领导很高兴，也不再强求需要专门的劳资管理模块。项目进度因而几乎没有受到影响，最终顺利验收。 分析： OA和HRM有关系么？显然差别很大。但是客户是不能随便得罪的，尤其是一个刚上任有实权的二把手。这个时候要思考领导提出此需求的原因。新官上任，一般要烧几把火，一个正在进行中的项目当然要留下他的个人烙印。所以说，其实他真正的需求不在于搞劳资管理，毕竟这一块业务以后也不归他主管，其主要目的还是为了树立威信。了解了这一点就好办了，给他两张“量身定做”的报表，既能体现他的个人意志，又表达了对他的尊重，最关键的是开发工作量很小。这个事件中，PM的及时沟通和思考决策，起到了决定性的作用。
案例二： 某CRM项目，已经到了试运行阶段，原计划下周二验收。这时PM得知对方主管领导下周三要出国考察，想到对方可能没有心思准备验收的工作，便与对方沟通后把验收时间改到领导回国以后。
却不料领导考察了国外的先进管理思想以后，回来决定大幅修改自己的业务管理模式，原有的CRM内容因此有大半失去作用。项目几乎等于要重头再来一次。
分析：重视计划永远是正确的，甚至要想办法让条件成熟的后续工作提前开始。这个案例中的PM就犯了错误。领导要出国，没心思召开验收会是正常的。但是PM应该有很多办法来促成项目的及时验收。例如说找各业务主管对各模块分别书面签字验收，然后只需要领导最后签字确认即可。或者找公司领导汇报，争取一笔资金，找个名目通过SALES交给领导（通常情况下项目都有回扣点数），同时谈谈马上验收的事宜。反正是在计划安排的时间内，这种顺水人情领导当然乐意。而且，对于领导去做业务考察这件事，PM居然没有联想到跟自己项目业务的关联，敏感度太低。
案例三： 一个PDM项目，需求调研已经完毕，正处于开发阶段。这时客户提出想把PDM和常用的三维设计软件PRO/E进行集成，实现两套软件的数据交互。根据PM的经验和技术人员的反馈来看，这个集成的难度相当大。但PM却一口答应下来，然后向客户提出需要对方配合的工作：请客户方找PRO/E公司，以大客户的身份要求PRO/E提供所需的数据接口。但是进行这种洽谈的话，用户需要提供正版序列号。实际上这家公司所用的PRO/E全是盗版，领导为此犹豫不决。PM更进一步地提出让他们干脆采买几套正版，不过即使是一套正版，价格也在80万以上。权衡再三，最终客户还是主动放弃了这个需求。
分析： 出现超出开发能力但又符合项目边界的需求是项目中最让人头疼的问题。这种事情一旦解决不好，很容易让客户对供应商的水平产生怀疑，双方合作产生裂痕，进而影响验收。这个案例中的PM相当懂得随机应变，他答应客户去做这个需求其实是张空头支票。但是通过巧妙的处理方式，最终的结果却是需求被主动放弃，而且客户对PM的好感增加。不过采用这样的办法是有风险的，只有事先作好调查，心里有较大把握，才能付诸实施。
案例四： 某企业即将上马一个ERP项目。由于以前该企业曾经有一次实施ERP失败的经历，所以这次的新项目让企业相关部门感到紧张，谁也不想碰这个摊子，一致主张低调启动项目。但是供应商的PM却力主召开一个隆重的启动大会，在得到企业方主要领导的支持后，又找公司高层出面，请到了对方企业的上级主管到会，还在会上宣读了以各个业务部门骨干为成员，某领导为组长的项目实施小组名单。在害怕项目失败的压力下，小组的各成员和责任领导战战兢兢，尽力配合好实施的每一处工作，还团结一致消除企业内部的杂音，争取早日验收早日完事。这个项目果然进行得异常顺利，在规定时间内达到了各项功能指标，通过验收。
分析： 信息系统对于很多企业而言，都不是离开它就干不了事的东西。所以客户中出现散漫或者抵触对待项目的情况比比皆是。这个时候最好的办法就是把客户跟自己捆在一条船上。在这个案例中PM很强势，他首先说服了对方领导调配各个主要骨干来参加项目组，然后又让对方的上级主管知晓此事来暗地施加压力。这种情况下的项目干系人，唯一的想法恐怕就是安全过关，能用就行。既然抓住了企业中最能说上话的业务骨干，又降低了他们的心理期望值。这样的项目，不验收都难。
案例五： 某PM主导一个工厂的技术改造项目。天天和项目组成员一起泡在对方的车间里，和对方技术人员面对面交流。经过几个月的埋头苦干，逐步完善了系统，最终达到了可以验收的地步。这时PM去找对方的总工提出召开验收会。总工大吃一惊：“你们事情做完了？做到什么程度了？我怎么不知道？”于是总工又找来主要的几个负责人，开会了解情况。虽然系统已经可以满足对方的需求，但是既然领导专门开会，当属下的自然要憋出几个新想法来。再加上总工的个人意见，这个项目又出现了较大的需求变化，进度被迫延迟了。
分析： 做项目切忌“埋头苦干”。当PM很需要会做表面工作。日请示月汇报，这样才能让领导重视。不管客户上级主管有没有时间或者兴趣了解项目状况，该做的日报、周报、月报、阶段性报告，一定要按期递交到领导的案头，就算对方不看，也混个脸熟。而且做了些什么事情，都是有记录可查的。如果领导不清楚情况，哪怕下面的具体办事人员再认可，对项目也没有太大的作用。
信息化项目管理案例先，S集团明显缺乏IT战略规划，移动商务项目准备时间达到2年之久，而项目的上马启动会议竟然是在项目经理不在场的情况下召开的，由此可见，该项目的整体生命周期是有其随意性的，反应了S集团IT规划的缺失。项目启动会议对于项目是非常重要的，其核心在于对项目经理的授权，明确
项目高层次目标和项目可动用资源等。钟剑经理在项目运作当中多次推迟项目上线时间，数据提交的反反复复、项目经理身体力行进行项目加班加点等细节，从侧面反应项目经理对资源的掌控还是不够的，这也是启动会议没有到位的结果之一。 其次，S集团移动商务项目的项目计划制定不合理。从案例看来，项目上线的日期出现多次调整，分别是8月16日、9月1日、10月9日和10月16日，按照项目结果，显然项目进度是拖延了，但从根本原因分析看来，S集团移动商务项目总体计划是非常主观的，如项目启动会议定下来的“要求在8月16日30个分公司的各个办事处上线”目标，显然是值得推敲的。从项目管理角度看来，没有看到项目管理计划及其分计划（如范围管理计划、进度管理计划、成本管理计划、人力资源管理计划、沟通管理计划、风险管理计划和采购管理计划）。作为项目经理面对不可实现目标，虽然提出了项目进度方面的意见，但在郑总的一番“训斥”下，“钟剑没有再做任何辩解”，这种“委曲求全”以保项目上马的案例国内比比皆是，实际上反应了项目经理钟剑本身对项目计划方面经验的缺失。作为项目经理是为实现项目目标负责的，既然明知不可行的目标，为何要勉强为之呢？从整个案例看来，项目缺乏一个数据管理计划，数据管理计划包括数据在项目周期内是如何被管理的，也包括静态数据、动态数据的格式、收集要求、职责分工、进度要求、数据质量等方面。笔者实施的SAP ERP同样面临着数据的难题，除了总部的基础数据（大小物料、BOM、供应商主数据、客户主数据，物料数据因为行业特性，初始化达到上亿条记录，可见工作量的巨大），还有全国600家门店的静态数据和动态数据，特别是动态数据，涉及到数据的一致性，需要同老管理系统核对比较，困难可想而知。笔者在项目的中期，也就是“系统实现”阶段，在SAP后台配置的同时就召开数据整理启动会议，安排各项工作任务，且采取了有效的策略，如静态数据提前收集、核对进入系统，动态数据多层次、多岗位的核查等。在整个过程中，值得一提的是IT要发挥主导作用，因为数据处理是一件很细致、很烦琐、工作量很大的事情。我们采取的措施是IT有效的利用EXCEL等函数功能，进行批量数据的比对，也取得了比较好的效果。在项目运作当中，我们更多的做法是IT的高度参与，难题由IT解，薄弱环节由IT帮扶，混乱操作甚至由IT托管等，这是数据管理方面引申开来的，对于项目的成功值得借鉴。
再次，S集团移动商务项目风险管理做得很不到位。从案例看，项目的进度风险是很大的，项目实施过程也证明了这一点。本身作为高层强制性的规定项目进度要求是项目的风险，这是建立在“假设”基础上的，假设是项目的风险来源之一，需要在项目运作过程中不断去分析和跟踪。9月15日反映的统计报表与日常手工报表发生严重不符，实际上也是没有做好风险识别、风险分析和风险应对措施等方面工作。其原因分析是“上线前销售渠道分类没有按照标准统一的严格规定执行”，这就是风险啊。
再次，S集团移动商务项目的沟通管理也需要总结。8月11日，数据采集只有一半的办事处回复了，而且数据不是按照标准要求提供的，反应了沟通的不到位。对于项目不同的工作要有因地制宜的沟通方法和沟通技能，从数据采集角度看，完全可以通过正式的、书面的、模板化的要求终端进行数据收集。当项目出现了两次进度拖延后，9月22日，高层让钟剑就数据整理的困难在全国销售会议上汇报，间接说明项目经理在沟通管理上及其被动。作为项目经理的钟剑要建立不同级别的项目会议，如项目例会、项目评审会议、项目进展会议、项目风险分析会议、项目决策会议等等，通过及时、有效的专题会议形式完全可以把项目沟通工作做好。另外一个侧面细节值得关注，在确定最后项目上线日期10月16日时，项目总监欧阳雪对许建国、王新水的一段话可以看出，项目的历史沟通频次还是不够的。 然后，项目变更控制缺失。有个细节，10月8日，项目经理钟剑为了调整项目上线日期，以辞去项目经理作“危险”，可见项目变更管理在S集团移动商务项目还是没有做到位的。对于变更需求，完全可以按照正式的变更管理流程进行。本案例也反映了项目变更管理委员会等变更决策结构还是没有在项目中建立。作为项目经理是“集成者”、“综合者”，需要坚定的信念和项目流程管理经验。从案例看来，项目经理这方面意识是比较薄弱的。 最后，S集团移动商务项目也存在很多亮点，如项目经理钟剑的项目收尾工作还是可圈可点的，在项目成功上线两周内，他总结了近三个月的项目问题，整理了一套更完善的项目实施方案，体现了项目经理的综合能力，也反映了项目管理重视历史信息和经验教训的特点。又如团队建设方面，项目经理的最终项目上线日期变更邮件，其中反映的国庆长假的集体加班，也包括个大区的项目人员的表现可圈可点，可见项目整体士气不错，项目经理功不可没！
浅谈新疆高等级公路建设中的工程变更管理工程变更是公路工程合同管理的重要内容之一，因为施工过程中的工程变更，将对施工进度和工程造价产生很大的影响，因此应尽量减少工程变更，如果必须进行工程变更，则要严格按照国家的规定和合同规定的程序进行。新疆吐一乌一大高等级公路及乌一奎高速公路是按FIDIC条款，采用三级监理管理机构进行合同管理，现就建设中的工程变更管理谈谈自己的认识。 1. 工程变更的定义及提出 凡对合同文件、设计图纸（含已批准的施工图）涉及的各种工程的形式、位置、尺寸、数量、质量及标准进行修改和改变，均称为工程变更。 工程变更产生的主要原因有其主观原因和客观原因。主观原因，如勘察设计工作粗糙，以致在施工中发现许多招标文件没有考虑或估算不准确的工程量，因而不得不改变施工项目或增减工程量；客观原因，如发生不可预见的事故，自然或社会原因引起的停工或工期拖延等，至使工程变更不可避免。 工程变更的提出形式有：业主对原设计进行变更；设计单位提出变更；监理工程师提出的设计变更；承包人提出的工程变更。 构成工程变更的主要事项： （1）更改工程任何部分的标高、线型、位置和尺寸；（2）增减合同中给定的工作量、质量、工程的性质；（3）改变有关工程的施工时间和顺序；（4）其他有关工程变更需要的附加工作。 2. 工程变更的确认及处理程序 2.1 工程变更的确认 由于工程变更会带来工程造价和工期的变化，无论任何一方提出工程变更，均需由监理工程师确认并签发工程变更指令。工程变更发生时，监理工程师要及时处理并确认工程变更的合理性。 2.2 工程变更的处理程序 认真处理好工程变更具有重要意义，一旦处理不好常会引起纠纷，损害业主和承包人的利益，首先容易使投资失控，为了适应竞争激烈的建设市场，承包人通常在投标或谈判时让步，而在工程实施过程中通过工程量的变化、索赔获取补偿，都有可能最终超出原来的投资；其次，工程变更容易引起停工、返工现象，对进度不利；第三，频繁的变更还会增加监理工程师的协调工作量；另外对合同管理和质量控制也不利。因此对有效控制和管理非常重要。 这两条公路为了加强对工程变更的管理，制定了工程变更的分类、审批权限和审批程序。 （1）根据工程变更的内容和金额，将工程变更分为：小变更、一般变更、重要变更、重大变更。并根据分类确定监理组、驻地监理处、总监代表处、业主的审批权限。
（2）变更的审批程序。为了更好地控制工程变更，所有变更应由申请的部门提出变更原因、图纸和增减金额的报告，且均需监理工程师审查，并建立了完整的变更审批程序。详见下面的框图。 监理工程师审查变更时，无论哪一方提出的工程变更，都应与业主与承包人进行适当的协商，尤其是一些费用增加较多的工程变更项目，要与业主进行充分协商，征得业主的同意才能批准。
由于某些特殊情况如按程序审批，有可能造成对工程的不利影响，乌一奎高速公路合同管理中规定：特殊情况可由有批准权限的监理部门口头批准，7天内由审批变更的部门书面确认并补齐变更手续。同时还规定业主书面批准的变更，由总监代表处签发变更令。 3. 工程变更的估价与方法 3.1 工程变更的估价 3.1.2 估价的步骤 （1）监理工程师应得到业主批准的关于对规范或合同工程量所要进行的变更及费用估算和变更的依据和理由的授权，在FIDIC条款中已明确规定了监理工程师的权利。 （2）监理工程师在与承包人及业主协商后，由监理工程师商定一个合适的单价或价格，如协商不成，监理工程师决定一个其认为合适的单价或价格，并通知承包人及抄报业主。如果上述单价或价格未取得一致意见或决定之前，监理工程师可决定一个暂定单价或价格。 （3）监理工程师有确定单价的权力，但是工程量清单（包括计日工费率表）中的任何项目的单价或价格也不得作任何变更，除非该类变更单独计算其价值已超过合同价的20%，以及该项下实际施工的工程量超过或少于原合同价已报价的合同工程量的25%。 3.1.2 超过15%的变更 如果监理工程师在签发整个工程的移交证书时，发现由于工程变更和工程量清单上实际工程量的增加或减少（不包括暂定金额、计日工和价格调整），使合同价的增加或减
少合计超过有效合同（指不包括暂定金额、计日工的合同价格）的15%，在监理工程师与业主和承包人协商后，应在合同价格中加上或减去承包人与监理工程师议定的一笔款额。若不能达成一致意见时，则由监理工程师考虑承包人的工地费用及总管理费开支，确定此数额（此数额仅以增加或减少有效合同的15%为基础）。例如吐一乌一大高等级公路由于变更多，决算金额已超过合同价的15%，根据合同条款，监理工程师与业主、承包人协商后，调整了原合同价。 如当承包人接到变更指令后14天内不向监理工程师提出适当的变更单价和价格意向，将视为该变更不涉及合同价款的变更，不进行估价。因承包人自身原因（过失等）导致的工程变更，承包人无权追加工程款。 3.2 工程变更的估价方法
（1）合同中已有适用于变更工程的费率及价格，按合同已有的费率及价格计算、变更合同价款。
（2）合同只有类型似于变更工程的费率及价格，可参照此费率及价格确定变更单价，变更合同价款。
（3）合同中没有适用或类似于变更工程的费率及价格，由承包人、监理工程师与业主适当商定后，由监理工程师和承包人商定一个合适的费率及价格作为结算的依据，如商定不成，监理工程师有权确定其认为合适的费率及价格。费率及价格确定的合适与否是导致承包人索赔的关键。
（4）监理工程师如认为必要或适宜时，可以指令任何变更工程按日工方法进行工程估价变更。对这类工作应按合同中包括的计日工作表中规定的项目及承包人在其投标书中对此所定的单价和价格支付承包人费用。 （5）监理工程师将确定的单价或价格意向通知承包人或承包人将单价或价格意向向监理工程师提出后，14天之内如监理工程师无不正当理由不确认或承包人无提出异议，均视为所提出的单价或价格意向自行生效。 4. 工程变更的支付 吐一乌一大高等级与乌一奎高速公路为了加强对工程变更的支付管理，规定无变更令的工程变更不予支付。当接到变更令，变更工程实施完毕后，经监理工程师确认后，在当月的中间计量中支付。 但在实际工作中，由于某些工程变更涉及金额大、施工期长等原因，为了加快施工进度，减少承包人的资金垫付，可以先根据监理工程师暂定的单价或价格，根据工程的进度先行予以支付。例如：上述例子中乌一奎高速公路新增的排水工程，实际支付中可暂按合同中的单价或类似的工程单价，以千米为单位，按实际施工进度先支付，再根据工程变更的批复进行修正。这样就保证了承包人有资金投入后续工作，加快施工进度。但这样同时增加了工程变更管理的难度，这就需要建立完善的工程变更台帐，根据批复的部门，按变更令的顺序排列，做好变更支付的统计工作，避免漏计、重复计量。可利用计算机采用适当的软件来进行这项工作，笔者使用Execl软件进行变更统计工作，即清楚，又不会出错，提高了工作效率。
5. 结束语 吐一乌一大高等级公路及乌一奎高速公路由于在工程变更管理中，方法得当，措施有利，执行严格，有效地控制了工程造价，取得了较好的效果。但有时由于工程变更审批过程中文件传递速度慢、部门间协调不及时等原因，造成时间上的延误，建议在变更文件下发同时送达承包人及监理工程师，并定时召开由各部门参加的工程变更协调会，加快变更的审批速度
风险管理与管理信息系统建设
关于工程建设项目管理系统建设风险的讨论越来越多了，风险以及风险管理这两个概念，大家可能都有自己的理解，但是这种理解是否能够成为一种共识，不得而知。因此，本文希望就这个问题进行一些有关的探讨，旨在强化理解和增加它们在实际工作中的应用。
什么是风险? 尽管风险管理的理论已经有了几十年的历史，但由于风险的普遍存在以及风险管理在各个行业中的专门化，风险管理人员会根据自己特定的活动范围，对风险给出不同的定义。对风险进行定义是必要的，它在一定程度上指出风险的对象和目标。下面给出有关风险的两个定义。 风险管理的经典著作《Risk Management and Insurance》将风险定义为：给定情况下那些可能发生的结果的差异性。
保险理论中有关风险的定义为：风险是对被保险人的权益产生不利影响的意外事故发生的可能性。 根据风险理论的研究，风险的一般性定义为人们对未来行为的不确定性而可能引起后果与预定目标发生的负偏差，这种负偏差是指在特定的客观条件下，在特定的期间内，某一实际结果与预期结果可能发生差异的程度，差异程度越大，风险就越大，反之则风险越小。这种偏离可由两个参数来描述：一个是偏离的可能性，即事件发生的概率；一个是发生偏离的方向和大小。因此，又可以将风险定义为：风险是某种不利事件或损失发生的概率及其后果的函数，可以用下列公式表示：R = f(P,C)(其中：R表示风险的大小；P表示不利事件或损失发生的概率；C表示该事件发生的后果，即偏离的方向或大小。)
因此，综上所述，我们可以将管理信息系统建设的风险定义为：在特定的条件及时间之内，管理信息系统建设的实际结果与系统建设预期的目标之间可能发生差异的程度。
风险因素、风险事件和风险损失
1、风险因素 风险因素是指能增加或产生损失频率和损失程度的因素，是对象风险产生的内在的、间接的原因。
2、风险事件 风险事件是指损失的直接原因或外在原因。风险之所以会导致损失，主要是因为风险事件的发生造成的；如果风险事件没有发生，则不会导致风险损失。
3、风险损失 是指某一结果可能发生的与预期结果的负偏离或差异程度，所谓损失，在风险管理中是指对风险主体的非故意的，非计划性的和非预期的某种价值的减少。这个定义中包括两个重要要素：一是非故意的、非计划性的和非预期的；二是价值的概念，这种价值不一定表现为经济价值。缺少其中的任何一个要素，均不构成风险损失。
管理信息系统建设风险的特征.
风险的特征是指风险的本质及其发生规律的表现。正确认识风险的特征对于企业管理信息系统建立风险机制、加强风险管理、减少风险损失具有重要的意义。
一、客观性
风险是一种普遍的客观存在，人们既不能拒绝也不能否认它的存在。风险存在于客观事件发展变化的整个过程中，无时不有无处不在。我们必须承认和正视风险的客观存在，并且采取积极的态度，认真对待风险；
二、可预测性
风险是可以预测的。我们可以根据以往发生的类似事件的统计资料或者别人的经验，通过分析和研究，对某种风险发生的可能及可能造成的危害进行预测和评价，在此基础上进行风险控制和管理。管理信息系统建设的风险完全可以通过借鉴其它的系统建设的情况进行预测和判断，对突出的风险因素进行控制。
三、损失性
风险的发生必然会导致损失。对于管理信息系统建设而言，风险造成损失是肯定的，而且这种损失有时侯很难估计它的大小，有的风险造成的损失对系统来说甚至可能是致命的，使系统建设完全归于失败，最后无法产生任何效益。
四、结果的双重性
虽然管理信息系统建设的风险必然造成损失，但是如果能够对这些风险进行有效的控制，可以变不利为有利，对系统质量带来巨大的回报，甚至风险越大，克服风险后带来的正面价值也越大。这就是所谓的“风险越高，利润越丰”的道理。因此，对于管理信息系统来说，只要能够对系统的主要风险因素进行有效的控制，一定可以收到意想不到的效果。
从国内外发生的大量的事实可以看出，管理信息系统建设的风险管理能力在一定程度上决定了系统建设的成败，其中的风险不仅表现在技术和基础设施这些硬件方面的驾御能力，更加突出表现出来的是关于人、组织和制度方面的因素，对这些因素加强管理，找到问题发生的根本原因和有效的解决方法是成功的关键。
新产品开发中的风险评估
新产品开发是一个复杂的、动态的、连续的过程，其中涉及到大量的信息收集、分析、筛选及传递，各种模式方案的选择与确定，各种要素资源的投入与配置，新产品生产
及营销战略制定等一系列的工作.这些工作都不同程度地存在不确定性，从而导致企业新产品开发风险的发生。因此，要成功进行新产品开发，就必须加强对新产品开发中的风险分析与评估。
风险辩识。对企业新产品开发风险评估，首先必须找出可能影响新产品开发成功的风险因素，研究各种风险因素会对新产品开发造成什么样的后果，该阶段一般被称为风险辩识，是进行任何风险评估的前提和基础。企业新产品开发中的风险评估主要包括以下风险因素：
技术风险。指企业在新产品开发过程中，因技术因素导致新产品开发失败的可能性。技术风险大小由下列因素决定：技术成功的不确定性；技术前景的不确定性；技术效果的不确定性；技术寿命的不确定性。 市场风险。指新产品的相对竞争优势的不确定性，市场接受的时间、市场寿命及市场开发所需资源投入强度等难以确定，而导致新产品开发失败的可能性。新产品开发出来以后，价格往往较贵，同时人们对新产品的质量、性能及其稳定性往往要观望一段时间，或等别人使用后再购买，这就阻碍了新产品快速渗透并占领市场。若新产品不能在短时间内占领市场，则很可能失败夭折。因为若这项技术也被竞争对手看中，他们很可能模仿并加以改进，在短时间内追赶上来，且其产品更具优势。这时，刚刚被引导出来的市场，很可能被竞争对手占领。
资金风险。指因资金不能适时供应而导致新产品开发失败的可能性。若不能及时供应资金，会使新产品开发活动停顿，其技术价值随着时间的推移不断贬值，甚至被后来的竞争对手超越，初始投入也就付之东流。此外通货膨胀也会引起资金风险。
环境风险。指新产品开发由于所处的社会环境、政策环境、法律环境等变化或由于自然灾害而造成新产品开发失败的可能性。因此，新产品开发，必须重视环境风险的分析和预测，采取有效的对策和措施，把环境风险减少到最小限度。
生产风险。指在新产品开发过程中，由于生产系统中的有关因素及其变化的不确定性而导致新产品开发失败的可能性。如难以实现大批量生产、生产周期过长、工艺不合理、设备和仪器损坏、检测手段落后、产品质量难以保证、可靠性差、供应系统无法满足批量生产的要求等。
管理风险。指在新产品开发过程中，由于管理失误而导致新产品开发失败的可能性。如组织协调不力、其他部门配合不好、高层领导关注不够、调研不充分、市场信息失真、市场定位不准、营销组合失误、风险决策机制不健全、研发过程不协调等。
工程风险转移措施
风险管理是人们对潜在的意外损失进行辩识、评估、预防和控制的过程。建筑工程由于其规模大、周期长、生产的单件性和复杂性等特点，在实施过程中存在着施工不确定的因素，比一般产品生产具有更大的风险，进行风险管理尤为重要。 风险管理是对项目目标的主动控制。首先对项目的风险进行识别，然后将这些风险定量化，对风险进行控制。国际上把风险管理看作是项目管理的组成部分。风险管理和目标控制是项目管理的两大基础。在工业发达国家和地区，风险转移是工程风险管理对策中采用最多的措施，工程保险和工程担保是风险转移的两种常用方法。（一）工程保险 工程保险是指业主和承包商为了工程项目的顺利实施，向保险人（公司）支付保险费，保险人根据合同约定对在工程建设中可能产生的财产和人身伤害承担赔偿保险金责任。工程保险一般分为强制性保险和自愿保险两类。在工业发达国家和地区，强制性的工程保险主要有以下几种：建筑工程一切险 （附加第三者责任险）、安装工程一切险（附加第三者责任险）、社会保险 （如人身意外险、雇主责任险和其他国家法令规定的强制保险）、机动车辆险、10年责任险和5年责任险、专业责任险等等。其中，建筑工程一切险和安装工程一切险是对工程项目在实施期间的所有风险提供全面的保险，即对施工期间工程本身、工程设备和施工机具以及其他物质所遭受的损失予以赔偿，也对因施工而给第三者造的人身伤亡和物质损失承担赔偿责任。过去，一切险的投保人多数为承包商；现在，国际上普遍推行由业主投保工程一切险。在工业发达国家和地区，建筑师、结构工程师等设计、咨询专业人均要购买专业责任险，对由于他们的设计失误或工作疏忽给业主或承包商造成的损失，将由保险公司赔偿。国际上工程涉及的自愿保险有以下几种：国际货物运输险、境内货物运输险、财产险、责任险、政治风险保险、汇率保险等等。国际上工程保险的通行做法和特点是：保险经纪人在保险
业务中充当重要角色、健全的法律体系为工程保险发展提供了保障，投保人与保险商通力合作是控制意外损失的有效途径，保险公司返赔率高且利润率低。 （二）工程担保 工程担保是指担保人（一般为银行、担保公司、保险公司、其他金融机构、商业团体或个人）应工程合同一方（申请人）的要求向另一方（债权人）作出的书面承诺。工程担保是工程风险转移措施的又一重要手段，它能有效地保障工程建设的顺利进行。许多国家政府都在法规中规定要求进行工程担保，在标准合同中也含有关于工程担保的条款。 在工业发达国家和地区，常见的工程担保种类如下：第一，投标担保：指投标人在投标报价之前或同时，向业主提交投标保证金（俗称抵押金）或投标保函，保证一旦中标，则履行受标签约承包工程。一般投标保证金额为标价的0.5~5%；第二，履约担保：是为保障承包商履行承包合同所作的一种承诺。一旦承包商没能履行合同义务，担保人给予赔付，或者接收工程实施义务，而另觅经业主同意的其他承包商负责继续履行承包合同义务。这是工程担保中最重要的，也是担保金额最大的一种工程担保；第三，预付款担保：要求承包商提供的，为保证工程预付款用于该工程项目，不准承包商挪作他用及卷款潜逃；第四，维修担保：是为保障维修期内出现质量缺陷时，承包商负责维修而提供的担保，维修担保可以单列，也可以包含在履约担保内，有些工程采取扣留合同价款的5%作为维修保证金。
以上四种担保是在工业发达国家和地区常见的工程担保种类，除此这外还以以下几种：反担保、付款担保、业主无能为力担保、分包担保、临时进口物资税收担保、完工担保、差额担保、施工执照担保等。 由于建筑工程在建设过程中存在着越来越多的不确定性因素，风险管理正成为工程项目管理日益重要的一个组成部分。
如何控制信息技术外包的风险？
失控与风险控制
风险失控还表现在：服务不能及时到位以及质量无法保证；灵活性减弱，需求的变化及其满足必须与外包商协调后才能得到解决；成本攀升，外包商常常会要求支付一些附加费用；企业秘密和机密信息可能会泄露给外包商；企业内部的智力资产可能会受到侵犯等；
外包商的选择及其风险
如果签署一个长期的外包合同，企业可能无法分享技术进步带来的经济利益；对于创业初期的企业而言，如果不能够准确地预见业务需求及其变化并与外包商及时沟通，那么外包就会制约企业的发展；外包商本能地趋向于控制成本以提高自身的利润；外包商提供的是过时的设备和服务；外包商提供的往往不是一流的人员，有时甚至是外包商支付薪金的本企业以前的雇员。
技术变迁的风险
信息技术仍在以不可预见的方式在变化，企业业务环境的变化也带有不可预知性，这两者的结合加剧了信息系统的不确定性：当技术和业务环境同时处于不确定状态时，外包的信息系统如何支持未来的业务需求？信息技术的学习及其在企业中的最佳的应用更多的是一个经验过程，如果外包出去，外包商是否有足够的积极性去学习企业所需要的信息技术？
测度和管理的风险
外包后的系统成本一般不会减少，减少的主要是可变成本，所以要计算所有的成本包括管理外包活动的时间、努力和人力的成本；在外包过程中，企业要依赖一个外包商但又无法控制其行为如外包商利润最大化、外包商的转包等，事实上，合同对于企业而言是一种束缚而对外包商而言则是一种可利用的手段；外包可能会阻止企业内部信息技术人员对新技术及其应用的学习，而鼓励学习意味着成本的增加；外包会丧失一些灵活性。
怎样做好软件项目风险计划
风险评价是识别并分析潜在风险区域的过程。可以通过列举通常的软件项目风险因素以使风险识别更加明析。制作风险评估表是识别风险的好办法，在风险评估表中我们统计特定风险对项目可能造成的潜在后果，风险计划的要素有： 风险描述对于风险情况的介绍。
可能性风险发生的可能性。风险不是必然要发生的，如果一个对项目存在危害的事件是必然要发生的，
那这个事件就不能作为风险。对于风险可能性的标识有助于对那些高可能性的风险投入更大的关注。 严重性风险如果发生对于项目的危害程度。 危害值一个综合考虑可能性和严重型后对风险的一个评估，这个评估反应了风险应该被关注的程度。 对策 对策分为两个部分：一是对于采取预防措施以阻止风险的发生，另一方面也要考虑如果风险发生后需要采取什么措施。这两方面的计划构成了完整的风险对策。 触发标志风险是一种可能性，并且制定风险主要的出发点是预防它，但也要考虑到风险发生后情况。对于风险发生后的应对策略，需要争取一定的提前时间以启动必要的各项工作，设立触发标志是为设立一个判别标识，在该触发标志所标明的条件具备时，说明风险已经越来越可能成为现实了。
风险责任人风险预防和跟踪需要有人的参与，在风险计划中责任明确是一个重要的原则，对每一个列入了视线的风险都要指定对风险预防和跟踪负责的人员。 风险计划不是一个静止的文件，它应该随着项目状况的变化而变化。所以在任何项目中，风险管理都必须被作为一个日常的正式活动列入项目工作计划，成为项目管理人员的一个重要工作。在下一节风险跟踪中将对风险的动态变化作出更详细的阐述。 在标定风险可能性和危害时，重要的是清楚地标明风险之间重要性的相对比较，所以采取一个简明的标注标准十分重要
信息化项目中的风险管理
实施任何项目都有风险，即在企业投入相应资源后没有如期实现项目目标。出现项目风险的根源在于，在项目实施过程中会发生很多意想不到的某些事件，这些事件导致实际结果偏离预期目标。和工程项目相比，信息化项目的实施风险更大，因为信息化项目是看不见、摸不着的项目。如何规避信息化项目的风险呢？ 项目风险管理，就是在项目实施过程中对项目可能出现的问题进行主动而系统的识别、评估并及时采取相应的应对措施和行动，减少风险带来的损失。风险管理由风险识别、风险评估和风险应对三个部分组成。 风险识别
风险识别就是确定风险事件及其来源。由于风险的不确定性，风险识别实际上只能算是一种预测分析，是对可能会给项目目标实现带来负面影响的环节和因素所进行的假想。目的是做到有备无患，当实际风险发生时能有效应对。
需要注意的是，风险识别将贯穿于项目实施的全过程，而不仅仅是项目的开始阶段。风险因素可能来自需求、技术、资金、实施方等各个方面，但项目实施最根本的目标是实现项目的期望，因此风险识别也应重点关注影响项目期望的因素。同时在风险识别过程中，也需要辩证地分析风险因素的负面效应（即风险带来的威胁）和正面效应（即潜在的机会）。
具体的项目风险识别方法，主要有：
① 头脑风暴法，就是由项目小组成员在一起，反复假设“如果……，那就会……”，充分预测信息化项目中出现的各种情况，从而尽可能多的找出影响项目成功实施的因素。
② 专家判断法，即请教擅长信息化项目实施的专家、学者、教授，经验丰富的项目经理、实施顾问等，从理论与实践多方面来判断项目风险因素的正面效应和负面效应。
③ 调查问卷法，即事先设计相应的表格、问卷，然后选取特定的调查对象，然后总结出项目的风险；另外，询问项目组成员也非常有帮助，问问他们以前做过的项目里曾发生过哪些意料不到的问题。也许管理部门又提出了新的优先项目，也许最好的成员突然不能参加进来了，也许预算减少了，也许其中的一项任务完成拖期了，也许另一个小组超出了预算，或者也许出现了未预见到的技术问题……要把进度（包括可能延误项目的因素）、人员（包括威胁到位的因素）、财务（包括威胁预算的因素）以及范围（包括导致最终产品的难以完成的因素）等各方面的风险一一区分开来。
④ 经验总结法，就是借助以往企业信息化项目实施的经验教训，来类推、联想这个信息化项目中的风险因素。
转贴于：中国项目管理资源网⑤ 理论分析法，即通过建立数学模型等方法从理论上来分析信息化项目的风险，比如决策树、敏感性分析、蒙特卡罗模拟等。
风险评估
风险评估又称作风险量化，就是比较风险的大小，从而决定是否需要采取相应的应对措施。风险评估的方法很多，归纳起来主要包括以下几种：用风险发生的概率来评估风险发生的可能性；用风险带来的损失来评估风险发生的严重性；用现有的手段能否控制风险的发生来评估风险发生的可控性；用风险影响的地域大小、对象多少等来评估风险影响的范围；用风险发生在项目生命周期的阶段来评估风险发生的时间。 实际项目风险管理过程中，常常用逐项评分的方法来量化风险的大小，即事先确定评分的标准，然后由项目小组一起，对预先识别的项目风险一一打分，然后得出不同风险的大小。风险应对针对风险评估的结果，制定相应的应对措施去响应风险，就是风险应对，其目的是创造机会，回避威胁。风险应对中，需要对风险的正面效应（即潜在的机会）制定增强措施，对风险的负面效应（即可能的威胁）制定应付方法。对于不同的风险，需要根据其重要性、影响大小以及已经确定的处理优先次序，采取相应的措施加以控制，对负面风险的反应可以是尽量避免、努力减小或设法接收。另外，在处理风险时需要注意应对的“及时性”和“反复性”，即在第一时间对各种突发的风险作出判断并采取措施；对已经发生或已经得到控制的风险经常进行回顾，确保风险能够得到稳定长期的控制。
项目风险应对的措施主要有：
① 修正项目目标或范围。尽管有深入的项目调研和详尽的项目规划，但信息化项目过程中的需求改变常常难以避免，因此为保证项目的实施效果，对项目的目标或范围加以必要修正，能够有效应对项目偏离需求的风险。
② 加强培训。加强项目培训能够提高参与项目的IT人员和业务人员甚至管理人员、决策者对信息化项目的认知，对规避项目的实施风险有良好的效果。转贴于：中国项目管理资源网
③ 准备风险保证金，适当预留项目计划时间。信息化实施往往周期较长，在项目预算中预留一定数量的风险保证金，时间计划中预留一定的时间，能够有效应对由于项目需求改变或者范围增加而造成的时间和成本风险。
④ 始终贯彻项目管理的标准流程。严格执行项目管理中的时间、成本、质量控制等标准流程，能够有助于控制项目风险。
⑤ 引入第三方咨询和监理。信息化项目初期尤其是刚刚开展信息化项目的企业，在信息化项目实施中引入第三方咨询和监理，能够利用第三方的专家优势和对项目实施的经验来应对项目风险。
⑥ 加长模拟阶段的周期。信息化项目中最重要的是信息系统与企业业务流程的结合，因此加长系统模拟业务流程的周期，使之充分适应企业业务流程，能够保证项目对企业的适应性，从而降低项目的实施风险。⑦ 行政强制手段。项目实施应以培训和沟通为主，但并不排除采用行政手段强制实施，对于项目中的某些难点，采用行政强制手段能够起到很好的效果。
⑧ 终止项目。这是一种极端的做法，往往由于项目目标没有明确所致，采用这种做法虽然会导致项目的彻底失败，但也是万不得已，能够避免企业更大的损失。
项目团队如何拥有高的协调性
案例正文：
徐家龙最近被公司任命为项目经理，负责一个重要但不紧急的项目实施。公司项目管理部为其配备了7位项目成员。这些项目成员来自不同部门，大家都不太熟悉。徐家龙召集大家开启动会时，说了很多谦虚的话，也请大家一起为做好项目出主意，一起来承担责任。会议开的比较沉闷。项目开始以后，项目成员一有问题就去找项目经理，请徐家龙给出意见。徐家龙为了树立自己的权威，表现自己的能力，总是身体力行。其实有些问题项目成员之间就可以相互帮助，但是他们怕自己的弱点被别人发现，作为以后攻击的借口。所以他们一有问题就找经理，其实徐家龙的做法也不全对，成员发现了也不吭声，因为他们认为我是按你说的做的，有问题你经理负责。 团队成员之间一团和气，“找徐经理去”、“我们听你的”成为了该项目团队的口头禅。但随着时间的推移，这个貌似祥和和团结的团队在进度上很快出现了问题。该项目由“重要但不紧急的项目”变成了“重要而且紧急的项目”。项目管理部意识到问题的严重性，派高级项目经理张凤指导该项目的实施。
请问： 该项目问题出在哪里？ 徐家龙应该怎么做？
分析：
1.项目经理的定位我们先澄清一个概念：什么是项目经理。项目经理就是项目中的总经理，总经理的职责是决策，领导。而不是关注所有的事情。本案例中的项目经理犯的错误在我们身边屡见不鲜，其根源最主要在于：1)项目经理定位不准2）团队无明确的沟通计划
2.只竖向沟通不横向沟通显然不行作为项目经理,你应该要引导成员相互横向沟通后，无法解决的再竖向沟通或开会协商；这就好比民主集中制，要民主，也要有人说了算，案例中项目经理都是自己拿主意，但他不可能在每方面都是长处，长此以往，团队形成一种风气，压力全转移到项目经理处，项目风险也会越来越大。
3.职责、团队、方法论. 一个成功的团队是指由不同技能,才华,工作风格和知识的成员组成的士气高涨的团队.项目经理的职责就是将这些人组成团队并激励他们. 项目经理的技能应包括技术技能和管理技能,坚实的技术基础能够在技术方面对团队起指导作用,管理技能有助于沟通和解决问题.管理技能不仅限于技术方面,还包括解决问题的能力,估算能力,编制计划的能力,人际和沟通能力.所以本案例出现的问题本质是项目经理对自己的职责没有很好的认识，因此在管理团队的方法上也就走了偏路。问题从项目组成员形成了一个习惯（有事找徐...)，失去了团队的协做意义，使团队的实际能力得不到体现；到最后使得项目进度出现严重延迟。
项目管理案例：项目的开发周期
案例正文：
一个项目经理在开发一个为期10个月的项目的三个星期后得到客户通知，项目要在不增加成本，不影响范围和质量的情况下，需要在8个月内完成。
请问：项目经理应该怎么做？
分析：
一、了解客户计划改变的真实原因 在做项目的很多时候，客户方会要求项目在不增加成本，不影响范围和质量的情况下，提前完成，但是一定有他的理由，也许是你的竞争对手采取的措施，也许是我们在做项目的时候有哪些不对的地方，或者是客户遇到新的其他情况不等，但是在客户提出之后，不能明确的答应也不能以强势的态度拒绝，等了解真正的原因后再做打算。
二、向客户沟通 假如必须提前完成任务，要向客户说明其困难，假如公司真的有实力，那就答应他，并适当的拿出合同进行说明，是否在其他方面给予公司补偿。如果公司的把握不是很大，那就站在客户的立场为他考虑，本来十天完成的任务现在8天完成，困难时什么，结果会怎么样，是否采取，按照客户的要求完成部分功能，比如为了迎接上级领导检查，那就把系统的表面工作都做好，要是真正的使用的话，那就把不影响工作进行的部分往后推迟等等，一个项目实施后，所有功能在一定的时间都能使用上的几率不是很大，另外也可以采用在主要功能方面做好，次要方面稍往后放等等方法。
三、从公司本身出发 在不影响范围和质量的情况下，提前完成，我们只有在加班或加人中选择，但是一定要谨慎，因为加人是存在一定的风险的，毕竟项目已经进行了3个月。假如公司实在没有办法的话，那就把部分较独立的功能模块外包出去，当然这是下下策了。 四、团队的管理 在这个时候，一定要在团队的管理方面做好工作，无论从人员的到位，还是人员的情绪，或者其他方面等等做到恰到好处
项目管理中的创新智慧
自从中国改革开放、走向世界，她就登上了全球化的互相依存和竞争的舞台。这个舞台催醒了东方巨龙的创新意识。只有从中国制造走向中国创造，才可能有中华的复兴，才会有自立于世界民族之林的能力。
但是创新不能停留在口号上。如果说中国人缺乏创造性，你一定不会同意。然而说在中国成功地走到了„智慧型组织'阶段的企业还凤毛麟角，你大概不会反对。肖知兴在他的《中国人为什麽组织不起来》一书中分析其原因，强调了价值观、信念和文化的力量。确实创新需要有群体智慧和组织文化。本文把这个大问题收缩到项目管理领域，看看情况又是怎么样呢？
项目经理们喜欢这样的赞誉"你驾驭的„列车'总是准点到达并且不超过能耗指标"。他们通常都是一些做事非常专注，习惯严格按预定框架和程序办事的人。很少从他们嘴里冒出创新这样的词。很不幸，其实这是一种认识上的疏漏。许多企业忽略了组织文化这个因素，不知道如何在项目管理的框架里培育创造性。 项目管理中的创造性并不是与规范化、标准化相矛盾的，它确实存在并有助于时间和金钱的节省。我过去也写过文章，认为项目管理应当是标准化和个性化的融合。
创新的赛场有边界约束 许多人有一种误解，认为有创造性的人必须是不受任何拘束的。然而，项目管理结构就像一个创造能力的比赛场地，它确实是有边界的。 尽管灌输这样一种充分评价创新价值的理念是重要的，然而领导者仍然需要对创新设置必要的界限。如果没有适当的边界和领导，无序的创新性必然会将项目引向一片混乱。 在整个投资组合的范围中保持工作流程的连贯、一致非常重要。这将有助于在全企业内为创新建立一个坚实的„巨人的肩膀'，否则创新只会是胡闹的游戏。这包括维持稳定的规章制度和行为准则，像制订计划进度和预算等都要有一定的程序，不要随意变更。在项目一
开始就应建立好一个总的章程，并且在整个项目过程中维护好这个章程，使其能够得到有效的遵循。这可以避免许许多多问题和麻烦的产生。其实真正的„创新狂躁'来自高层头脑发热的、糟糕的领导。 无疑，公司高管应找到一种办法来培育创造能力，以提高项目成功的概率。项目本身是一类独特的过程，所以对于具有突破性的创造存在着许多机会，特别是在立项和寻求缩短工期、节省费用、提高质量的努力中。
过度控制抑制创造性 要使项目能具有创造性，公司高管需有慧眼识别和启用能评价、鼓励创新精神的项目经理。不要因为有些创新的意见被认为„说起来容易、做起来难'，就对其嗤之以鼻。为了使工作团队有最佳的发挥，一个项目经理需要具备指导、支持、教育和委任的技巧。控制性的领导往往一切自己决定并监视部下的每一个工作细节，这样必然抑制创造精神。
有时候简便的技巧比高超的技术还更管用。美国新泽西州的一位创新和领导力咨询顾问Wayne Morris认为，一个有创新能力的领导人的主要作用是设计和维护好一个支持创新精神的、安全的心理环境。为此，他提出领导者应具有：接受风险的承受力 对智者失误（非愚蠢的失误）的经验价值的理解 相互交流、沟通的平易 鼓励创造激情的能力 授予部下一定自主权的民主意识 给部下个人事宜留下适当时间的宽容 乐观的态度 鼓励意外发现的能力 对悖于常理的言论的宽容
全面培育创新意识 创新的项目管理贯穿项目的全过程，从建立一个创新的框架开始，让大家去思考如何找到一种与众不同的好方法来节省时间和金钱。美国西雅图的一位创新管理顾问Donna Shirley说，以她的经验创新的机会无处不在，不要仅仅满足于技术性的创造，还需要管理的创新以及用人机制的创新。
创新仅仅依靠个别人的天才也是不够的。个别人单枪匹马的创新能力不可能真正把事情做好。整个团队必须具有集体的创新智慧和创新文化。
工作流程中设定创新空间。 组织应在工作流程中给予创新一定的空间。你可以也应当把创新列入计划之内，但务必将其放在需要的地方。 创新这类工作方式的特征就是随心所欲地放纵思维，并为关闭狂想闸门的最后时刻设置好底线。对大多数人而言，在给出限定条件的情况下会工作得更好。项目管理的责任就在于设定合理的边界，给创新留出空间，并让你的团队成员都知道。这将有助于他们最好地发挥创造性，而且不会无端地浪费资源。 要让人们知道遵守工作流程的好处，你必须尊重有创新精神的人，告诉他们在什麽情况下可以做新的尝试并允许犯错误。然而，同样重要的是，也要让他们尊重项目管理的工作流程。一个好的领导者要鼓励创新，但不允许随意破坏工作流程。
软件外包项目中的进度管理
案例正文：
A公司是一家美资软件公司在华办事机构，其主要的目标是开拓中国市场、服务中国客户，做一些本地化和客户化的工作。它的主要软件产品是由总部在硅谷的软件开发基地完成，然后由世界各地的分公司或办事机构进行客户化定制、二次开发和系统维护。这些工作除了日常销售和系统核心维护之外，都是外包给本地的软件公司来做。东方公司是A公司在中国的合作伙伴，主要负责软件的本地化和测试工作。 Bob先生是A公司中国地区的负责人，Henry则是刚刚加入A公司的负责此外包项目的项目经理。东方公司是由William负责开发和管理工作，William本身是技术人员，并没有项目管理的经验。当Henry接手这项工作后，发现东方公司的项目开发成本非常高，每人每天130美金，但客户的满意度较差，并
且每次开发进度都要拖后，交付使用的版本也不尽如人意。而且，东方公司和A公司硅谷开发总部缺乏必要的沟通，只能把问题反馈给Henry，由Henry再反馈给总部。但由于Henry本身并不熟悉这个软件的开发工作，也造成了很多不必要的麻烦。
为此，Bob希望Henry和William用项目管理的方法对该项目进行管理和改进。随后，Henry和William召开了一系列的会议，提出了新的做法。 首先，他们制定了详细的项目计划和进度计划；其次，成立了单独的测试小组，将软件的开发和测试分开；并且，在硅谷和东方公司之间建立了一个新的沟通渠道，一些软件问题可以与总部直接沟通；同时，还采用了里程碑管理。六个月后，软件交付使用。但是客户对这个版本还是不满意，认为还有很多问题。为什么运用了项目管理的方法，这个项目还是没有得到改善？
Henry和William又进行了反复探讨，发现主要有三个方面问题：1、软件本地化产生的问题并不多，但A公司提供的底层软件本身存在一些问题；2、软件的界面也存在一些问题，这是由于测试的项目不够详细引起的；3、开发的周期还是太短，没有时间完成一些项目的调试，所以新版本还是有许多的问题。
此时，Henry向Bob提出是否采用公开招标的方式，选择新的、实力更强的合作伙伴。但Bob认为，与东方公司合作时间已经很长了，如果选择新的伙伴又需要较长的适应期，而且成本可能会更高。于是，Henry向东方公司提出一些新的管理建议。首先，他们采用大量的历史数据进行分析，制定出更详细的进度计划；其次，要求东方公司提供详细的开发文档和测试文档（之前William的团队做的工作没有任何文档，给其他工作带来了很多困难）；第三，重新审核开发周期，对里程碑进行细化。
又过了六个月，新的版本完成了。这一次，客户对它的评价比前两个版本高得多，基本上达到项目运行的要求。但客户还是对项目进度提出了疑问，认为实时推出换代产品不需要那么长的时间。
分析：
软件外包是现在软件工程中较常见的做法。在软件外包工程中，保证质量的进度是很难控制的。对于项目经理来说需要一整套复杂的能力，比如制定计划、确定优先顺序、干系人的沟通、评价等，每一种能力都与项目的最终结果有直接或者间接的关系。 然而，国内的项目经理大多没有接受过正规训练，缺乏项目管理方面的专业知识的技巧，往往只是凭借以前的少量经验盲目去做，容易出现各种问题。尤其是在管理外包项目时，缺乏足够的经验和技巧，往往造成进度不断推迟，而质量无法保证的情况。 前文是一个比较典型的软件外包项目的案例。在这个案例中，我们可以看到现在IT业内许多外包项目的影子。 在该案例中，东方公司没有专门的项目经理，是由技术人员William兼做管理。这是国内软件公司经常会出现的问题。最初，出现进度落后的问题时，A公司的Henry与东方公司的William讨论后决定采用项目管理中计划管理等手段，其中包括里程碑管理。这是控制进度的较常见做法。
里程碑管理的引入 一般来说，在项目开始时，项目组成员都会对项目制定一个详细的计划。通常情况下，在明确的工作说明书（SOW）和WBS的基础上制定具体的进度计划时，需要采用一些具体的技术。像这种软件外包项目，最成熟的技术是里程碑管理。 里程碑一般是项目中完成阶段性工作的标志。不同类型的项目，里程碑也不同。比如，在开发项目中，可以将需求的最终确认、产品移交等关键任务作为项目的里程碑。本案例中，Henry在接手项目后采用里程碑进行管理是很恰当的不过，要注意的是，每到一个里程碑处，应及时对前段工作进行小结，并对后续工作进行计划调整。对于一些管理效果明显的领域，可以不必投入较多精力。而对于下一步管理过程中可能会出现问题的领域，应给予较
多的关注。当然，在软件项目里，进度的变化是较常见的事情。
在本案例中，采用里程碑管理后仍没有达到客户的要求，进度依然拖后。在这里，就需要考虑另一个因素—质量与进度的关系。
质量与进度关系 通常，项目管理的前提是保证在预算内、满足质量的前提下，按进度完成项目。因此，可以看到，保证质量是前提。那么，如何在满足质量的前提下管理进度呢？单纯从项目管理理论知识中并没有一种有效的方式。笔者通过实践，推荐一种较实用的方法。具体步骤为： 首先，尽量利用历史数据。在本案例中，Henry应该调查之前的项目情况，将会发现可以类比的情况，事先就可以知道需要管理质量和进度的关系。 其次，由于此项目是软件外包项目，Henry不能完全掌握项目的资源调度情况，因此缺乏对质量的控制。这也是大多数外包工程中最令人难以掌握的地方。在这里，可以采用对进度管理计划添加质量参数的方法，也就是通过参数调整进度和质量的关系。 这一做法的前提是要有一定的历史数据。比如，从历史数据中得知，完成子项目的时间是5天，测试后有15个问题；完成同样子项目的时间是7天，测试后有10个问题；完成同样子项目的时间是8天，测试后有5个问题，……以此类推。随着数据的不断增多的，采用两维坐标图，就会得到一些离散的点（不考虑资源的差异），并形成一条曲线，见图1。考虑项目允许的质量范围，对照图中的数据，找出相应的参数。根据得到的参数，确定一个合适的进度计划。
进度与成本的关系 在本案例中，Henry发现东方公司进度一直拖后，成本却居高不下。这里就需要了解软件外包项目中进度与成本的关系。很多时候，此类工程大多采用固定总价合同。但由于软件项目的修改比较多，实际上此类合同很像是固定总价加奖励费用，其中奖励费用一般会采用单价合同，即若干元/人天的合同，也就是说，承包商的成本是建立在人力成本估算上的。这样，一些承包商会倾向于拖延进度（或者减少实际投入，造成质量下降）。因此，项目经理需要了解整个合同的情况，最好参与合同的制定。在此案例中，Henry试图通过引入竞争来提高整个项目的效率，满足项目目标，也是出于同样的原因。尤其值得注意的是，有时候，出于竞争的需要，承包商会提供低廉的价格，此时对于进度管理更应该谨慎和完善。
还要指出的一点是，要对学习曲线有深刻地认识。在软件开发工程中，学习曲线（learning curve）有很大的用途。通常情况，承包商在接到同样类型的软件项目后，第二次会比第一次节省15%-20%的时间。项目经理最好要了解一下以前类似项目的情况。
综合管理:如何成为一个受欢迎的项目经理
程序员的一个重要的职业发展方向就是项目经理，然而，做一个项目经理和做一个程序员是有很大区别的。项目经理需要面对的人和事更多而且更复杂，需要具备更多的知识和技能才能够胜任。
正文 项目经理是整个项目的负责人，对项目成败负有直接责任。项目经理需要打交道的各方面的人很多，需要处理的事情也很多，要做一个受欢迎的项目经理更加的不容易。那么，怎样才能做一个受欢迎的项目经理呢，我们从Who-What-How这三点出发，来共同探讨这一问题。
Who—受谁的欢迎：
项目经理同时要面对来自内部和外部两方面的对象。外部对象——项目的所有干系人都是项目经理要面对的，内部对象——项目经理的上级领导和项目组成员，也是需要关注的。
What—受欢迎的标准： 项目干系人在不同类型的项目中有所不同，比较普遍和主要的包括：项目发起人、出资人、相关业务部门负责人、最终用户等。对于项目发起人来说，能够保证项目按时完成、满足
功能要求同时又能保证质量的项目经理最受欢迎；对于出资人来说，能够保证项目的费用不超出预算的项目经理最受欢迎；对于业务部门负责人来说，分两种情况，一种是项目的推进对其有利，他们对项目经理的要求与发起人基本一致，另一种情况是项目的推进对其有不利影响（比如改变现有流程、权力回收等），想得到他们的欢迎可能很困难，这个时候项目经理只能尽力减少他们对项目的抵触心理和对项目经理的敌对情绪，以可以接受的代价为其考虑的更加周全，尽量提高受欢迎的程度；对于最终用户来说，能够提供方便易用的软件和全面及时的培训的项目经理最受欢迎。
对于项目经理的上级领导来说，能够保证项目按照进度、成本、质量的要求顺利完成的项目经理最受欢迎；对于项目组成员来说，能够明确给出项目目标，合理安排分工和分配任务，具有亲合力和容易沟通的项目经理最受欢迎。 How—怎样做到： 计划制定能力。一个项目涉及到的事情总是千头万绪，如果没有很强的计划能力将很难成为合格的项目经理，要善于制定各方面的计划，并按照计划执行各项工作。随着项目的开展，还要不断的调整和更新相关计划，保证计划的合理性和可执行性。 项目控制能力。包括对项目的范围、进度、成本、质量各方面的监督和控制。善于利用各种分析工具来全面了解项目的进展情况，及时发现项目存在的问题和风险，并采取适当的应对措施，在需要的时候向上级领导汇报并寻求支持。 时间管理能力。把握项目进展的节奏，合理安排各项任务的重要性和优先级，保证项目组可以定期地交付一些可见的工作产品，以避免项目干系人因长时间看不到项目的进展而给项目组施加不必要的压力。 成本控制能力。项目的费用成本也是各方关注的焦点，项目经理要能够利用费用管理工具及时掌握费用花费情况，尽量减少不必要的开销，对于无法避免的用户额外的要求，则要善于争取费用的追加。 沟通交流能力。项目经理需要面对方方面面的人，并同他们讨论林林总总的事，因此，顺畅的沟通和交流是必不可少的。项目经理必须要善于根据不同的沟通对象来选择合适的沟通渠道、沟通方式和沟通频率，并在沟通过程中采用适当的技巧获得对方的支持和认可，使得项目可以顺利进行。
团队建设能力。项目不是靠PM一个人来完成的，需要所有的项目组成员共同努力。作为团队的领导者，项目经理要善于通过各种培训、团队活动、奖励和表彰等手段，加强成员间的互相了解，使得每个成员的力量逐渐整合为一股合力，从而达到1+1>2的效果。 后记
项目经理需要考虑的问题与程序员完全不同，对项目的成败负有完全的责任，必须具备更多的管理技能。项目经理除了要保证项目按照要求顺利完成之外，还需要面对项目组内外的形形色色的人和事，处理不断发生的各种风险和冲突，因此，项目经理只有具备了更多的知识和技能，才有可能成为一个受欢迎的项目经理。
外包仍需要项目管理
案例正文：
公司外包的网站出了问题，身为公司信息部门主管的何经理最近有点烦。
何经理所在的公司是一家制造行业的民营企业，主要生产管件、轴承等产品，由于地处东南沿海，何经理的老板对于信息化很重视，眼看着一个个行业类网站如雨后春笋般建立起来，何经理的老板也想通过电子商务给企业带来一些新的销售渠道。
虽然何经理所在的公司总体规模不大，但具体到轴承和管件等产品，这家公司在行业内排名还是很靠前的，因此，在何经理建议做一个企业门户网站时，老板觉得，那样还不如直接做一个行业网站，只针对轴承行业。这样一来，不仅可以帮助自己的企业拓展业务，还能帮助同类企业。何经理的老板甚至还在想，行业网站做得好，说不定会给自己的企业带来新的赢利点。
不过，何经理所在的信息部仅有三个人，除了维护企业内部的IT系统和硬件之外，他们已经没有精力再做一个行业网站，做网站对于何经理来说，也是一个新的领域，他在技术上并不是很强。
做专业的事就要找专业的人，在网站建设上，何经理和老板经过多次沟通，决定把网站建设、运营、管理等全部外包，交其他公司或个人处理。
但关于域名、空间等的选用，以及关于网站内容、版面的策划，再到对于市场的分析、目标群体的分析等方面，何经理他们并没有太多的想法，他们觉得，既然花了那么多钱，自己就不用投入太多的人力物力了。
另外， 何经理所在的公司有60%的产品都销往海外，公司主要针对海外客户。于是，何经理考虑到，一个好的网站就成了一个窗口，向海外客户展示企业产品、宣传企业理念、维护企业形象。而且国外不再通过文本的方式进行贸易，都是利用电子邮件的方式。 这样，网站成了与国外客户交流、贸易的最好方式。所以何经理在策划网站建设的时候，决定在做中文网站的同时推出一个英文版。公司开始策划企业网站，并和国内一家提供网站服务的公司签订了合同，约定该公司为他们建设一个中英文双语版网站，并支付了40多万元的服务费。这家网站服务公司承诺赠送网易、SOHU、TOM等网站的推广一年，并提供.com的域名一个，期限为三年。可是，由于这家网络服务公司未按照约定及时进行网站的注册，就在双方签订合同没几天，原来这家公司承诺给何经理的.com的域名已经被别人抢注。在这种情况下，这家网络公司并没有与何经理商议变更合同的问题，就擅自为他们注册了.net的域名，并在该域名下制作网站。不仅如此，网站制作的进度也大大超出了他们最初的承诺，内容同样存在多处不完善的地方，英文版的超链接更是拖了半年多才完成。
分析：
何经理原本想通过一个行业网站推广自己的企业，进而为同行们服务，可是，外包的网站建设一波三折，让何经理有些灰心。他开始怀疑当初是不是该建议老板做这样一个双语的行业网站？即使要做，他又该如何做，是不是完全外包给网络服务公司？
本案例所描述的网站外包事项具有良好的出发点、可取的方法和准确的目标，项目实施之所以出现令人不满意的地方，根本原因在于双方存在认识上的差距，表象就是缺乏沟通，没有开展有效的项目管理。 作为一个直接面向市场销售产品的制造型企业，规模不大，而且60%的产品销到海外，有一个高效的企业网站是十分必要的，出发点很正确，目标可以清楚预见。
至于是否建立一个行业网站，要看在轴承生产行业是否有很专业的网站。当然，以排名靠前企业的身份建立一个具有特色的行业网站也不失为好的想法。在信息部只有3名员工的情况下，服务外包是极其正确的一种策略。即便是本企业有很强大的信息化建设力量，外围建设及维护服务往往也是较好的选择。专业化的成果只有通过专业化的服务来获得。
换句话说，在网站建设立项初期，目标和方法都很明确，即服务于全球客户，从项目管理的角度分析，可能出现的风险应该较低，也许会出现个别难题，但只要有缜密的实施计划和严格的项目管理，潜在的风险都可规避。其实，单就网站本身建设与维护而言，在企业信息化项目中其难度相对较低，投资也不大。那么，为什么在企业网站建设中还是出现了一系列的问题呢？
网站建设之所以一波三折，问题主要就出在项目管理方面。项目虽简单，但并不意味着建设和运营管理一帆风顺，从而甲方可以撒手不管。正相反，同样也需要按照一个标准的信息化项目来进行管理。虽说行业网站的内容复杂度会高于企业网站，但建设过程大同小异。如果对症下药，在建立行业网站过程中完全可以避免类似情况的出现。具体说来，主要改进如下几点。
甲方零工作量的误区 网站外包不等同于甲方零工作量。任何项目都需要理清合作各方的工作内容，甲方必须主导项目的进展，以满足各利益相关方的要求。每一个阶段都不可能离开甲乙双方的配合，启动阶段尤其如此。至于域名的注册与管理，是一件非常简单的工作。无需耗费太多的人工，不一定外包。 如果企业期望注册的域名已经被抢注，可以买回或者更换成类似的名称来解决，这不应该成为制约网站开发的一个重要因素。
拒绝松散管理 每一个信息化项目都不容松散管理。信息化项目通常会有需求调研、设计、开发、测试、试运行、上线和维护几个阶段。各阶段均应按照项目管理金三角设置专人实时跟踪、参与、审查和评价其质量、进度，控制资金投入。
在关键阶段，为避免方向性的错误和工期严重耽误，现场及时监督、指导、讨论和纠正不可或缺。何经理所在团队缺乏人力和技术力量，可以考虑委托具有经验的第三方代行其职能。
确立正确的方法论 该企业制定的外包策略虽然很正确，但乏于具体实现方法，从而导致大量问题出现。网站建设是一个典型的需求驱动项目，花大力气摸清需求是成功实施的根本。技术实现、版面设计是专业网站建设队伍的强项，但网站的主题、基调、展示思路和内容重点只能由企业自己说了算。
何经理及其团队不熟知网站内容布局和版面设计在情理之中，但这并不说明他们可以不去协调、组织整个项目。网站是企业的信息窗口，良好的需求分析等于成功了一半。如果何经理有信心自行组织，在网站设计开发之前就应在开发单位的配合下做好。如果没有自行组织的可能，可以寻找一些专业的咨询顾问来代为实施，提出多种可靠方案，最后由何经理及其老板选定。
把握关键控制点 有了正确项目实施策略、方法与计划，余下的工作重点就是把握住关键控制点。这实际也是项目管理重要的一部分。例如，前文提及的需求分析确认和版面设计审查等都直接关系网站建设的成败。 另外，英文版的网站对于该企业来讲甚至比中文版意义更加重大，网站开发队伍未必在语言翻译和英文网站布局方面很强，尤其是专业性很强的领域。因此，英文材料的提交、版式的确定和开发效果的审核都应该是何经理关注的关键点。
选择合格的实施队伍 实施队伍的诚信和服务质量直接影响甲方的参与工作量和项目的成功率。从擅自修改域名这一事实来看，案例中的网站开发商不值得信赖。工期拖延和内容不完善显示出该开发商在项目管理和服务品质保障方面很不力。由于缺乏精力和经验，何经理的部门无法起到很好的主导作用。 良好的开发商在洞察这些情况以后，应该占据主动，积极采取措施，及时引导并与何经理的团队沟通，共同寻求每个问题的解决方法以实现合同规定的目标，而不是消极被动地迂回或放任自流。如果继续做行业网站，可以考虑选择更好的队伍。
正确评判网站建设成果 网站的制作仁者见仁，不能期望短期内面面俱到。应以满足最初定位和持续攀升的点击率来评价其优劣。在页面基本框架和展示风格确定的情况下，作为一个制造型企业应以方便客户为宗旨，让网站访问者最简单快捷地寻找到想要阅读的信息或完成网上操作。至于次要的内容，可以分步完善和上载。
完善配套的管理制度 制度是项目良性运作的保障。众所周知，任何信息化项目不可能由信息部门独立完成。信息上载、版式调整和内容更新等是长期的工作，每个部门必须各司其职、相互配合，才能确保网站的时效性和生命力。内容不齐全，责任主要在于甲方。网站栏目设计与调整技术上不困难，只要有需求就可以实现。如果有了栏目，缺少内容，何经理应该通过制度和老板这两个利器调动大家的积极性，及时准确提交或者上载有关的信息。如果建设行业网站，该企业是领头羊，更应该在产品信息、行业文化方面及时更新内容，起到风向标的作用，而不能一味的认为是网站建设方的问题。
如何走出项目规划陷阱？
案例正文：
2005年12月，宁波开云公司与宏研公司签署合作协议，实施SCM（在线供应链管理系统）。但是，直到今年6月份，双方也没有确定出一个认可的方案，项目的进展几乎陷入困境，用宏研公司项目经理李凯的话说：“我现在已经害怕接到开云公司CIO张励的电话。”这是为什么呢？ 何以反复修改解决方案？ 开云公司是宁波市的一家小型零售连锁企业，总部设在宁波，目前已在宁波下属一些县区设有分部。业务扩张后，企业内却出现了一系列的问题：各门店之间、门店与总部之间、与供应商之间的信息管理系统是不相联接的，各店也是分别向供货商采购，这样一来，开云公司实际上就成了单店经营，一个个店其实就是一个个“信息孤岛”，规模优势和集团优势难以发挥。面对这些问题，开云公司急于借信息技术来提升整体管控能力。
最初，李凯为开云公司量身打造了一个以门店为中心的B2B电子商务平台，包括基于Intranet内网的报表统计系统，基于Extranet外网的e-SCM供应链管理系统等。系统功能包括在线结算、信息分享（销售、库存、补货、结算）以及品类管理及分析。方案实现了开云公司多家门店与供货商之间的电子订单、对账、经营数据分析、查询等协同商务工作。 没过多久，张励就发现，上游供货商出于各自业务统计和分析的需要，会对自己所经营的商品采取一定的分类标准和编码规则，即使同一连锁集团内，各门店所
经营的商品种类、商品编码、价格等属性也可能各不相同。所以，方案必须解决一定标准下信息转换的问题，否则B2B电子商务平台就是一句空谈。针对张励提出的问题，李凯把方案做了调整，开发出了异构系统之间的“翻译”模块。 不久，张励又提出了新的要求：在总部建设数据中心系统，包括基于数据仓库的CRM顾客关系管理系统。当然，李凯对项目方案也做了再次调整。 每一次方案的调整，对李凯都意味着繁重的工作量，要对开云公司的工作流程仔细调研，制订方案，甚至要与其上游厂商进行沟通，确保方案的可行性。满以为经过几次的调整，这回应该让张励满意了。然而事情又出现了新的变化，张励需要一套BI商业智能系统为企业的决策提供支持。 到底怎么做 客户才满意？ 这一回，李凯再也坐不住了。第一，项目方案又要调整，这会是一个较长的时间，而且不知道以后还会怎样变化；第二，李凯认为，对于开云公司来说，BI商业智能系统的考虑太长远，目前的数据量太少，项目实施后数据量的增加也会是一个长期过程，没必要现在就做全部规划。 作为企业CIO，张励有不同的意见：现在的零售连锁竞争相当激烈，企业要考虑长远的规划。系统上线后，随着供货商和各门店的数据共享，信息量不断扩大，需要一套BI商业智能系统为企业领导的决策提供帮助。这样才会在竞争中保持不败。
项目初期就遇到了如此多的问题，张励认为“用户更喜欢一个能提出个性化解决方案、碰到问题都能够解决的供应商，能根据企业的发展提供符合要求的差别化服务。”而李凯却有自己的苦恼，客户不断要求改变方案，经常把做好的方案推倒重来，解决方案的供应商根本没有办法控制成本且无所适从。更何况，有些方面的规划并非客户所急需。 双方各执一词，为我们带出了两个问题：在项目规划上，解决方案供应商与客户之间如何才能更好地沟通和协调？项目究竟应该满足现有的应用需求，还是也要满足未来的应用需求？
分析：
发现信息化规划中的陷阱 开云公司的项目规划案例是一个普遍现象，折射出当前许多企业在软件选型过程中所遇到的问题，而“软件项目规划应该如何做”正是该问题的核心。 众所周知，不管做什么事情都需要有一个总体目标和规划，在总体规划下进行目标分解，不断细化阶段性目标和规划，才能保证把事情作对，不脱离正常的轨道，从而让投资得到最大的回报。软件作为一种信息化管理的工具和手段，是为管理服务的，因此它的规划必须能够适应企业的发展，满足企业某一时间段的需要。 综观这个案例，当事双方存在如下几个问题值得思考。
①项目的目标和范围定义不够明确。不难看出，两家公司在目标上是有些不一致的。开云公司认为他们只要是碰到的问题，包括以后可能遇到的问题以及对未来的一些想法就应该在此次项目中实现。而宏研公司则认为他们的目标只是解决目前已经存在的问题，过于长远的问题不是他们此次项目需要考虑的。这样就因为目标、范围不够明确，导致双方各自站在自己的角度和立场去想问题，从而产生了一些分歧。 ②没有进行业务框架梳理，缺少咨询环节。此次项目一开始就很仓促，开云公司没做好需求整理及规划就找来软件厂商进行选型，可以说，开云公司只是大概知道他们需要什么，但还不能清晰定义出这次项目的具体范围及未来IT架构整合的问题，这是一个主要原因，也是起因。
而宏研公司在作为合作伙伴进行调研时，也只是对现存的问题进行了规划，没有帮助开云公司对整体的业务框架进行梳理，同时也没有从软件公司的专业角度提供一些建设性参考意见，而只是单纯从目前业务需要给出方案，没有从更为长远的角度帮助客户去考虑问题。
浅谈房地产项目风险管理
一、引言 20世纪90年代，我国房地产行业过度膨胀引致整个行业一度萧条的余痛在某些地区尚未消失，今天该行业又再度展现了如日中天的投资气氛。在乐观的投资气氛背后有很多投资者因为无法抵挡风险的袭击而投资失败，因此，对房地产项目实施风险管理就显得至关重要。
二、房地产项目风险产生的原因
房地产是一个特殊的行业，它具有以下特点：投资额大、建设周期长、资金周转慢、变现能力差，涉及到的社会、经济和环境因素多，其投资过程是一种预测未知将来需求而进行产品生产的过程。这些特点决定了房地产业是一种典型的高风险投机行业。其次，由于房地产的地区差异、项目差异，涉及的内容不单单是技术问题，还有很多其它方面的问题，因此，国家很难像针对建筑工程那样去制定房地产项目风险管理的统一规范和规程。这一切都决定了房地产行业的高风险性。
三、房地产项目主要风险
在房地产开发的不同阶段存在不同风险
1、投资决策阶段的风险
投资决策阶段的风险主要有开发区域风险，开发物业类型风险，开发时机风险和开发项目的定位风险。
2、土地获取阶段的风险
土地风险主要来自于土地自然属性、社会属性和土地规划部门对土地使用性质和规划设计指示的不确定性。购买了土地使用权后，还有大量的征地、拆迁、安置和补偿工作。
3、项目建设阶段的风险
项目建设阶段的风险主要来自设计理念的落后、建筑物实用性差、甚至由于承包商建筑技术落后、施工方案与方法不同、偷工减料以及项目监管不负责任等导致建筑物存在质量安全隐患。
4、售管理阶段的风险
这个阶段的主要风险有销售时机的风险、租售合同的风险、自然灾害的风险和意外事故的风险。
五、房地产项目风险管理与控制
1、风险分析
风险分析一般要经过三个步骤。一是风险辨识阶段找出风险因素，研究风险因素会造成的后果；二是风险估计阶段，根据已有资料和经验对各风险因素可能发生的概率及对项目的影响程度做出估计；三是风险的评价阶段，采用适当的方法对各种风险因素的影响进行评价，即确定风险的概率分布。 项目管理者联盟，项目管理问题。
2、风险预防
在风险发生前，为了消除或减少可能导致损失的各种风险因素，而采取的各种措施称之为风险预防。风险预防贯穿于房地产开发经营的各个阶段。
在投资决策的阶段，房地产开发企业风险预防的主要任务包括：
（1）建立高水平、多学科的开发人员队伍。
（2）建立健全风险预警系统。
（3）贯彻执行风险管理责任制度。
在土地获取阶段，开发商应该重视以下几个问题：履行开发商的社会责任，积极主动的与各地方政府管理部门和土地所有者搞好关系， 妥善处理征地、拆迁和安置补偿工作中遇到的棘手问题。增强合同意识，
认真签订各种相关合同，尽量避免合同歧义。
项目建设阶段风险预防的主要措施有：高度重视项目建设中的安全问题，在现场控制中，减少风险源，防止风险扩散， 特别是强化现场质量监控，防止出现质量缺陷和建筑工程质量。及时协调、妥善处理建设过程中的设计、施工、监理、材料设备供应之间的矛盾，使项目的建设顺利的进行
在房地产开发租售管理阶段，为了预防风险，应当特别重视租售合同条款的明确、详尽,并聘请律师或法律工作者审核。
3、风险转移
可以采取工程保险或工程担保的方式来转移风险。
4、风险管理
合理界定项目覆盖的范围，在企业发展规划和战略的总体要求下，用科学的方法和态度进行项目决策，确定项目目标，避免出现决策失误风险; 编制《项目管理规划》，用《项目管理规划》指导项目的建设和管理; 理顺组织结构，明确岗位职责，建立项目的反馈沟通职能，为风险管理提供组织保障。
5、风险抑制
风险抑制是在风险发生时或风险发生后采取的各种降低损失程度或缩小损失发生范围的措施，目的是使风险发生时损失最小，风险发生后有挽救措施。
房地产是一种投资大、周期长、内部结构复杂、涉及因素众多的复杂开发系统，影响该系统的风险因素众多，影响关系错综复杂。同时，不同风险因素引起后果的严重程度迥异，项目能否取得预期结果具有很大的不确定性，因此，在项目风险管理中，应进行科学的、系统的风险分析，风险预防，风险转移，风险管理，风险抑制，将风险损失降低到最低程度，确保建设项目取得良好的社会和经济效益
③项目方案没有一个总体构架。方案多次修改虽然同用户的项目目标、范围不明确有关，但宏研公司没有帮助一起进行总体构架也逃不了干系。如果宏研公司能够多花一些时间同开云公司讨论总体构架，那么后面所碰到的编码转换、商务智能等问题可以提早被挖掘出来，不至于最后被动应付方案的不断调整。 要避免类似案例所产生的问题，重点在于如何科学有效地进行企业信息化的规划。
解决问题：信息化规划四步走
针对企业信息化规划，我们应如何进行，在每个步骤中又应注意什么要点呢？
首先，需要按照企业运营模式和业务特点进行总体规划。从企业的运营模式和业务特点入手，明确了解企业的发展方向、业务模式及其核心竞争力，定义出核心业务与辅助业务，则整个信息化的核心目标就能够体现出来。
需要强调的是，除了需要考虑到现有状况之外，还需要能够兼顾未来，也就是说在做这样的规划时，需要为未来的10到20年打下一个基本框架。后期可以随业务做一定的调整和扩充，但整体的框架是不能够随意更动的。当然，这样的工作企业自身未必能够独立完成，可以找软件咨询公司协助规划，提供业内的最佳实践案例作参考，以保证规划的合理性。
其次，将信息化目标进行分解和排序。建立企业的整体信息化框架，这只是一个框架性的目标，是无序的。我们应该把这些目标细化、分解，根据企业的发展阶段按重要性排序，以确定什么时候需要完成什么样的信息化目标。
再次，进行IT系统规划。当我们把阶段性的信息化目标都定义清楚之后，就能够进行IT系统的规划，对一些业务边界进行细分，以明确定义出有哪些IT系统，分别负责什么样的业务，IT系统之间有什么样的联系，需要什么样的建制关系等等。
最后，分步实施。通过前面的三步，这时，每个软件应该大致负责的业务范围都已明确，同其他系统的整合要求及未来的功能预留也有了定义，软件选型也会更有目的性，更容易操作，容易通过软件实现管理效益和避免软件投资风险。
所以概括来说，这个案例所碰到的客户同软件厂商之间的项目沟通和协调问题，以及到底是满足目前业务还是未来业务的问题，都可以通过总体规划、分步实施来从根本上解决。
实践出真知之透过案例看实施
项目的实施工作，何以谓之成功？由于软件产品的特殊性，决定了这种项目的成功标准是很难被量化的，验收缺少清晰的数字指标。对于客户而言，在一个合同里面获得最大的管理价值，包含最广泛的业务应用，是他们对成功的看法；而在供应商眼里，项目就是项目，早日验收早日回款，是他们追求的目标。双方立场的差异，导致项目在进行中会出现各种情况影响到项目的验收。如何减少分歧，按期完成项目，就成为了项目组最大的挑战。 一般来说，我认为项目的实施需要遵照以下方针：加强沟通，精细计划，全力推行，利用资源，随机应变。 怎么解释呢？“加强沟通”，沟通是应该占据项目组成员最多时间的工作。他们不光要跟客户沟通，还要跟后方的销售人员、开发人员、测试人员多交流，以及包括了项目组内部的信息交换。实施人员应该是信息的中转和汇总的枢纽，获得的信息量越大，项目现状就越透明，对后续工作的把握就越大。PMBOK中提到，一个项目经理有90％的时间都是在沟通上，可见这项工作的重要性。 “精细计划”，这个需要考验PM的功力。一个合理的计划，是项目能够成功的先决条件。PM要最大化了解项目的相关信息，包括资源、风险、客户特点等等，然后制定出一个适合项目特征，甲乙双方都有能力去实施的计划，并界定出项目边界和里程碑。从这一刻起，就要为项目的最终验收开始努力。 “全力推行”，指的是项目小组成员要明确以验收为中心，计划是准绳的目标，想方设法去按照计划推动项目的开展。这个过程中肯定会出现各种各样的状况，也是项目最复杂，头绪最乱的时候。运用各种手段，来全力保障计划的按期执行甚至提前进行，是项目组所有成员的职责。 “利用资源”，资源是什么？只要一切有利于项目推进，有利于最终验收的人、财、物，甚至气候、政治动态等等，都是资源。例如说甲乙双方的高层领导是资源，一台大内存的测试PC是资源，哪怕即将来临的雨季也是资源。项目经理要善于考虑可以利用的资源，敢于申请资源，然后把它用在项目所需要的地方，来解决一切干扰项目进度的问题。 “随机应变”，没有到来的时间里总是充满了未知的因素，有不少是风险管理中无法预料的事情。这个时候该怎么处理，处理的后果会产生什么影响，还有没有更合适的办法都在考验PM。这就需要PM运用其综合能力，包括经验、技术能力、个人性格等，临时来找到有效的解决意见。以上谈到了项目实施的主要方针，我们再来看几个真实的案例，从中进一步理解。
案例一：
某PM所做的一个局级OA项目，经过前期的工作以后已经进入了试运行阶段，情况良好，正准备验收。这时机关上调来了一个常务副局长，他提出OA中缺少劳资管理的功能，需要补上。PM并没有马上允诺或拒绝，而是找甲方关系较好的人员作了了解，原来此领导原来是主管人事出身，只对这块比较有发言权。PM就找到了这位副局长，提出要为他专门做两张报表，能够从既有数据中进行人事相关信息的分析。领导很高兴，也不再强求需要专门的劳资管理模块。项目进度因而几乎没有受到影响，最终顺利验收。 分析： OA和HRM有关系么？显然差别很大。但是客户是不能随便得罪的，尤其是一个刚上任有实权的二把手。这个时候要思考领导提出此需求的原因。新官上任，一般要烧几把火，一个正在进行中的项目当然要留下他的个人烙印。所以说，其实他真正的需求不在于搞劳资管理，毕竟这一块业务以后也不归他主管，其主要目的还是为了树立威信。了解了这一点就好办了，给他两张“量身定做”的报表，既能体现他的个人意志，又表达了对他的尊重，最关键的是开发工作量很小。这个事件中，PM的及时沟通和思考决策，起到了决定性的作用。
案例二： 某CRM项目，已经到了试运行阶段，原计划下周二验收。这时PM得知对方主管领导下周三要出国考察，想到对方可能没有心思准备验收的工作，便与对方沟通后把验收时间改到领导回国以后。
却不料领导考察了国外的先进管理思想以后，回来决定大幅修改自己的业务管理模式，原有的CRM内容因此有大半失去作用。项目几乎等于要重头再来一次。
分析：重视计划永远是正确的，甚至要想办法让条件成熟的后续工作提前开始。这个案例中的PM就犯了错误。领导要出国，没心思召开验收会是正常的。但是PM应该有很多办法来促成项目的及时验收。例如说找各业务主管对各模块分别书面签字验收，然后只需要领导最后签字确认即可。或者找公司领导汇报，争取一笔资金，找个名目通过SALES交给领导（通常情况下项目都有回扣点数），同时谈谈马上验收的事宜。反正是在计划安排的时间内，这种顺水人情领导当然乐意。而且，对于领导去做业务考察这件事，PM居然没有联想到跟自己项目业务的关联，敏感度太低。
案例三： 一个PDM项目，需求调研已经完毕，正处于开发阶段。这时客户提出想把PDM和常用的三维设计软件PRO/E进行集成，实现两套软件的数据交互。根据PM的经验和技术人员的反馈来看，这个集成的难度相当大。但PM却一口答应下来，然后向客户提出需要对方配合的工作：请客户方找PRO/E公司，以大客户的身份要求PRO/E提供所需的数据接口。但是进行这种洽谈的话，用户需要提供正版序列号。实际上这家公司所用的PRO/E全是盗版，领导为此犹豫不决。PM更进一步地提出让他们干脆采买几套正版，不过即使是一套正版，价格也在80万以上。权衡再三，最终客户还是主动放弃了这个需求。
分析： 出现超出开发能力但又符合项目边界的需求是项目中最让人头疼的问题。这种事情一旦解决不好，很容易让客户对供应商的水平产生怀疑，双方合作产生裂痕，进而影响验收。这个案例中的PM相当懂得随机应变，他答应客户去做这个需求其实是张空头支票。但是通过巧妙的处理方式，最终的结果却是需求被主动放弃，而且客户对PM的好感增加。不过采用这样的办法是有风险的，只有事先作好调查，心里有较大把握，才能付诸实施。
案例四： 某企业即将上马一个ERP项目。由于以前该企业曾经有一次实施ERP失败的经历，所以这次的新项目让企业相关部门感到紧张，谁也不想碰这个摊子，一致主张低调启动项目。但是供应商的PM却力主召开一个隆重的启动大会，在得到企业方主要领导的支持后，又找公司高层出面，请到了对方企业的上级主管到会，还在会上宣读了以各个业务部门骨干为成员，某领导为组长的项目实施小组名单。在害怕项目失败的压力下，小组的各成员和责任领导战战兢兢，尽力配合好实施的每一处工作，还团结一致消除企业内部的杂音，争取早日验收早日完事。这个项目果然进行得异常顺利，在规定时间内达到了各项功能指标，通过验收。
分析： 信息系统对于很多企业而言，都不是离开它就干不了事的东西。所以客户中出现散漫或者抵触对待项目的情况比比皆是。这个时候最好的办法就是把客户跟自己捆在一条船上。在这个案例中PM很强势，他首先说服了对方领导调配各个主要骨干来参加项目组，然后又让对方的上级主管知晓此事来暗地施加压力。这种情况下的项目干系人，唯一的想法恐怕就是安全过关，能用就行。既然抓住了企业中最能说上话的业务骨干，又降低了他们的心理期望值。这样的项目，不验收都难。
案例五： 某PM主导一个工厂的技术改造项目。天天和项目组成员一起泡在对方的车间里，和对方技术人员面对面交流。经过几个月的埋头苦干，逐步完善了系统，最终达到了可以验收的地步。这时PM去找对方的总工提出召开验收会。总工大吃一惊：“你们事情做完了？做到什么程度了？我怎么不知道？”于是总工又找来主要的几个负责人，开会了解情况。虽然系统已经可以满足对方的需求，但是既然领导专门开会，当属下的自然要憋出几个新想法来。再加上总工的个人意见，这个项目又出现了较大的需求变化，进度被迫延迟了。
分析： 做项目切忌“埋头苦干”。当PM很需要会做表面工作。日请示月汇报，这样才能让领导重视。不管客户上级主管有没有时间或者兴趣了解项目状况，该做的日报、周报、月报、阶段性报告，一定要按期递交到领导的案头，就算对方不看，也混个脸熟。而且做了些什么事情，都是有记录可查的。如果领导不清楚情况，哪怕下面的具体办事人员再认可，对项目也没有太大的作用。
信息化项目管理案例先，S集团明显缺乏IT战略规划，移动商务项目准备时间达到2年之久，而项目的上马启动会议竟然是在项目经理不在场的情况下召开的，由此可见，该项目的整体生命周期是有其随意性的，反应了S集团IT规划的缺失。项目启动会议对于项目是非常重要的，其核心在于对项目经理的授权，明确
项目高层次目标和项目可动用资源等。钟剑经理在项目运作当中多次推迟项目上线时间，数据提交的反反复复、项目经理身体力行进行项目加班加点等细节，从侧面反应项目经理对资源的掌控还是不够的，这也是启动会议没有到位的结果之一。 其次，S集团移动商务项目的项目计划制定不合理。从案例看来，项目上线的日期出现多次调整，分别是8月16日、9月1日、10月9日和10月16日，按照项目结果，显然项目进度是拖延了，但从根本原因分析看来，S集团移动商务项目总体计划是非常主观的，如项目启动会议定下来的“要求在8月16日30个分公司的各个办事处上线”目标，显然是值得推敲的。从项目管理角度看来，没有看到项目管理计划及其分计划（如范围管理计划、进度管理计划、成本管理计划、人力资源管理计划、沟通管理计划、风险管理计划和采购管理计划）。作为项目经理面对不可实现目标，虽然提出了项目进度方面的意见，但在郑总的一番“训斥”下，“钟剑没有再做任何辩解”，这种“委曲求全”以保项目上马的案例国内比比皆是，实际上反应了项目经理钟剑本身对项目计划方面经验的缺失。作为项目经理是为实现项目目标负责的，既然明知不可行的目标，为何要勉强为之呢？从整个案例看来，项目缺乏一个数据管理计划，数据管理计划包括数据在项目周期内是如何被管理的，也包括静态数据、动态数据的格式、收集要求、职责分工、进度要求、数据质量等方面。笔者实施的SAP ERP同样面临着数据的难题，除了总部的基础数据（大小物料、BOM、供应商主数据、客户主数据，物料数据因为行业特性，初始化达到上亿条记录，可见工作量的巨大），还有全国600家门店的静态数据和动态数据，特别是动态数据，涉及到数据的一致性，需要同老管理系统核对比较，困难可想而知。笔者在项目的中期，也就是“系统实现”阶段，在SAP后台配置的同时就召开数据整理启动会议，安排各项工作任务，且采取了有效的策略，如静态数据提前收集、核对进入系统，动态数据多层次、多岗位的核查等。在整个过程中，值得一提的是IT要发挥主导作用，因为数据处理是一件很细致、很烦琐、工作量很大的事情。我们采取的措施是IT有效的利用EXCEL等函数功能，进行批量数据的比对，也取得了比较好的效果。在项目运作当中，我们更多的做法是IT的高度参与，难题由IT解，薄弱环节由IT帮扶，混乱操作甚至由IT托管等，这是数据管理方面引申开来的，对于项目的成功值得借鉴。
再次，S集团移动商务项目风险管理做得很不到位。从案例看，项目的进度风险是很大的，项目实施过程也证明了这一点。本身作为高层强制性的规定项目进度要求是项目的风险，这是建立在“假设”基础上的，假设是项目的风险来源之一，需要在项目运作过程中不断去分析和跟踪。9月15日反映的统计报表与日常手工报表发生严重不符，实际上也是没有做好风险识别、风险分析和风险应对措施等方面工作。其原因分析是“上线前销售渠道分类没有按照标准统一的严格规定执行”，这就是风险啊。
再次，S集团移动商务项目的沟通管理也需要总结。8月11日，数据采集只有一半的办事处回复了，而且数据不是按照标准要求提供的，反应了沟通的不到位。对于项目不同的工作要有因地制宜的沟通方法和沟通技能，从数据采集角度看，完全可以通过正式的、书面的、模板化的要求终端进行数据收集。当项目出现了两次进度拖延后，9月22日，高层让钟剑就数据整理的困难在全国销售会议上汇报，间接说明项目经理在沟通管理上及其被动。作为项目经理的钟剑要建立不同级别的项目会议，如项目例会、项目评审会议、项目进展会议、项目风险分析会议、项目决策会议等等，通过及时、有效的专题会议形式完全可以把项目沟通工作做好。另外一个侧面细节值得关注，在确定最后项目上线日期10月16日时，项目总监欧阳雪对许建国、王新水的一段话可以看出，项目的历史沟通频次还是不够的。 然后，项目变更控制缺失。有个细节，10月8日，项目经理钟剑为了调整项目上线日期，以辞去项目经理作“危险”，可见项目变更管理在S集团移动商务项目还是没有做到位的。对于变更需求，完全可以按照正式的变更管理流程进行。本案例也反映了项目变更管理委员会等变更决策结构还是没有在项目中建立。作为项目经理是“集成者”、“综合者”，需要坚定的信念和项目流程管理经验。从案例看来，项目经理这方面意识是比较薄弱的。 最后，S集团移动商务项目也存在很多亮点，如项目经理钟剑的项目收尾工作还是可圈可点的，在项目成功上线两周内，他总结了近三个月的项目问题，整理了一套更完善的项目实施方案，体现了项目经理的综合能力，也反映了项目管理重视历史信息和经验教训的特点。又如团队建设方面，项目经理的最终项目上线日期变更邮件，其中反映的国庆长假的集体加班，也包括个大区的项目人员的表现可圈可点，可见项目整体士气不错，项目经理功不可没！
浅谈新疆高等级公路建设中的工程变更管理工程变更是公路工程合同管理的重要内容之一，因为施工过程中的工程变更，将对施工进度和工程造价产生很大的影响，因此应尽量减少工程变更，如果必须进行工程变更，则要严格按照国家的规定和合同规定的程序进行。新疆吐一乌一大高等级公路及乌一奎高速公路是按FIDIC条款，采用三级监理管理机构进行合同管理，现就建设中的工程变更管理谈谈自己的认识。 1. 工程变更的定义及提出 凡对合同文件、设计图纸（含已批准的施工图）涉及的各种工程的形式、位置、尺寸、数量、质量及标准进行修改和改变，均称为工程变更。 工程变更产生的主要原因有其主观原因和客观原因。主观原因，如勘察设计工作粗糙，以致在施工中发现许多招标文件没有考虑或估算不准确的工程量，因而不得不改变施工项目或增减工程量；客观原因，如发生不可预见的事故，自然或社会原因引起的停工或工期拖延等，至使工程变更不可避免。 工程变更的提出形式有：业主对原设计进行变更；设计单位提出变更；监理工程师提出的设计变更；承包人提出的工程变更。 构成工程变更的主要事项： （1）更改工程任何部分的标高、线型、位置和尺寸；（2）增减合同中给定的工作量、质量、工程的性质；（3）改变有关工程的施工时间和顺序；（4）其他有关工程变更需要的附加工作。 2. 工程变更的确认及处理程序 2.1 工程变更的确认 由于工程变更会带来工程造价和工期的变化，无论任何一方提出工程变更，均需由监理工程师确认并签发工程变更指令。工程变更发生时，监理工程师要及时处理并确认工程变更的合理性。 2.2 工程变更的处理程序 认真处理好工程变更具有重要意义，一旦处理不好常会引起纠纷，损害业主和承包人的利益，首先容易使投资失控，为了适应竞争激烈的建设市场，承包人通常在投标或谈判时让步，而在工程实施过程中通过工程量的变化、索赔获取补偿，都有可能最终超出原来的投资；其次，工程变更容易引起停工、返工现象，对进度不利；第三，频繁的变更还会增加监理工程师的协调工作量；另外对合同管理和质量控制也不利。因此对有效控制和管理非常重要。 这两条公路为了加强对工程变更的管理，制定了工程变更的分类、审批权限和审批程序。 （1）根据工程变更的内容和金额，将工程变更分为：小变更、一般变更、重要变更、重大变更。并根据分类确定监理组、驻地监理处、总监代表处、业主的审批权限。
（2）变更的审批程序。为了更好地控制工程变更，所有变更应由申请的部门提出变更原因、图纸和增减金额的报告，且均需监理工程师审查，并建立了完整的变更审批程序。详见下面的框图。 监理工程师审查变更时，无论哪一方提出的工程变更，都应与业主与承包人进行适当的协商，尤其是一些费用增加较多的工程变更项目，要与业主进行充分协商，征得业主的同意才能批准。
由于某些特殊情况如按程序审批，有可能造成对工程的不利影响，乌一奎高速公路合同管理中规定：特殊情况可由有批准权限的监理部门口头批准，7天内由审批变更的部门书面确认并补齐变更手续。同时还规定业主书面批准的变更，由总监代表处签发变更令。 3. 工程变更的估价与方法 3.1 工程变更的估价 3.1.2 估价的步骤 （1）监理工程师应得到业主批准的关于对规范或合同工程量所要进行的变更及费用估算和变更的依据和理由的授权，在FIDIC条款中已明确规定了监理工程师的权利。 （2）监理工程师在与承包人及业主协商后，由监理工程师商定一个合适的单价或价格，如协商不成，监理工程师决定一个其认为合适的单价或价格，并通知承包人及抄报业主。如果上述单价或价格未取得一致意见或决定之前，监理工程师可决定一个暂定单价或价格。 （3）监理工程师有确定单价的权力，但是工程量清单（包括计日工费率表）中的任何项目的单价或价格也不得作任何变更，除非该类变更单独计算其价值已超过合同价的20%，以及该项下实际施工的工程量超过或少于原合同价已报价的合同工程量的25%。 3.1.2 超过15%的变更 如果监理工程师在签发整个工程的移交证书时，发现由于工程变更和工程量清单上实际工程量的增加或减少（不包括暂定金额、计日工和价格调整），使合同价的增加或减
少合计超过有效合同（指不包括暂定金额、计日工的合同价格）的15%，在监理工程师与业主和承包人协商后，应在合同价格中加上或减去承包人与监理工程师议定的一笔款额。若不能达成一致意见时，则由监理工程师考虑承包人的工地费用及总管理费开支，确定此数额（此数额仅以增加或减少有效合同的15%为基础）。例如吐一乌一大高等级公路由于变更多，决算金额已超过合同价的15%，根据合同条款，监理工程师与业主、承包人协商后，调整了原合同价。 如当承包人接到变更指令后14天内不向监理工程师提出适当的变更单价和价格意向，将视为该变更不涉及合同价款的变更，不进行估价。因承包人自身原因（过失等）导致的工程变更，承包人无权追加工程款。 3.2 工程变更的估价方法
（1）合同中已有适用于变更工程的费率及价格，按合同已有的费率及价格计算、变更合同价款。
（2）合同只有类型似于变更工程的费率及价格，可参照此费率及价格确定变更单价，变更合同价款。
（3）合同中没有适用或类似于变更工程的费率及价格，由承包人、监理工程师与业主适当商定后，由监理工程师和承包人商定一个合适的费率及价格作为结算的依据，如商定不成，监理工程师有权确定其认为合适的费率及价格。费率及价格确定的合适与否是导致承包人索赔的关键。
（4）监理工程师如认为必要或适宜时，可以指令任何变更工程按日工方法进行工程估价变更。对这类工作应按合同中包括的计日工作表中规定的项目及承包人在其投标书中对此所定的单价和价格支付承包人费用。 （5）监理工程师将确定的单价或价格意向通知承包人或承包人将单价或价格意向向监理工程师提出后，14天之内如监理工程师无不正当理由不确认或承包人无提出异议，均视为所提出的单价或价格意向自行生效。 4. 工程变更的支付 吐一乌一大高等级与乌一奎高速公路为了加强对工程变更的支付管理，规定无变更令的工程变更不予支付。当接到变更令，变更工程实施完毕后，经监理工程师确认后，在当月的中间计量中支付。 但在实际工作中，由于某些工程变更涉及金额大、施工期长等原因，为了加快施工进度，减少承包人的资金垫付，可以先根据监理工程师暂定的单价或价格，根据工程的进度先行予以支付。例如：上述例子中乌一奎高速公路新增的排水工程，实际支付中可暂按合同中的单价或类似的工程单价，以千米为单位，按实际施工进度先支付，再根据工程变更的批复进行修正。这样就保证了承包人有资金投入后续工作，加快施工进度。但这样同时增加了工程变更管理的难度，这就需要建立完善的工程变更台帐，根据批复的部门，按变更令的顺序排列，做好变更支付的统计工作，避免漏计、重复计量。可利用计算机采用适当的软件来进行这项工作，笔者使用Execl软件进行变更统计工作，即清楚，又不会出错，提高了工作效率。
5. 结束语 吐一乌一大高等级公路及乌一奎高速公路由于在工程变更管理中，方法得当，措施有利，执行严格，有效地控制了工程造价，取得了较好的效果。但有时由于工程变更审批过程中文件传递速度慢、部门间协调不及时等原因，造成时间上的延误，建议在变更文件下发同时送达承包人及监理工程师，并定时召开由各部门参加的工程变更协调会，加快变更的审批速度
风险管理与管理信息系统建设
关于工程建设项目管理系统建设风险的讨论越来越多了，风险以及风险管理这两个概念，大家可能都有自己的理解，但是这种理解是否能够成为一种共识，不得而知。因此，本文希望就这个问题进行一些有关的探讨，旨在强化理解和增加它们在实际工作中的应用。
什么是风险? 尽管风险管理的理论已经有了几十年的历史，但由于风险的普遍存在以及风险管理在各个行业中的专门化，风险管理人员会根据自己特定的活动范围，对风险给出不同的定义。对风险进行定义是必要的，它在一定程度上指出风险的对象和目标。下面给出有关风险的两个定义。 风险管理的经典著作《Risk Management and Insurance》将风险定义为：给定情况下那些可能发生的结果的差异性。
保险理论中有关风险的定义为：风险是对被保险人的权益产生不利影响的意外事故发生的可能性。 根据风险理论的研究，风险的一般性定义为人们对未来行为的不确定性而可能引起后果与预定目标发生的负偏差，这种负偏差是指在特定的客观条件下，在特定的期间内，某一实际结果与预期结果可能发生差异的程度，差异程度越大，风险就越大，反之则风险越小。这种偏离可由两个参数来描述：一个是偏离的可能性，即事件发生的概率；一个是发生偏离的方向和大小。因此，又可以将风险定义为：风险是某种不利事件或损失发生的概率及其后果的函数，可以用下列公式表示：R = f(P,C)(其中：R表示风险的大小；P表示不利事件或损失发生的概率；C表示该事件发生的后果，即偏离的方向或大小。)
因此，综上所述，我们可以将管理信息系统建设的风险定义为：在特定的条件及时间之内，管理信息系统建设的实际结果与系统建设预期的目标之间可能发生差异的程度。
风险因素、风险事件和风险损失
1、风险因素 风险因素是指能增加或产生损失频率和损失程度的因素，是对象风险产生的内在的、间接的原因。
2、风险事件 风险事件是指损失的直接原因或外在原因。风险之所以会导致损失，主要是因为风险事件的发生造成的；如果风险事件没有发生，则不会导致风险损失。
3、风险损失 是指某一结果可能发生的与预期结果的负偏离或差异程度，所谓损失，在风险管理中是指对风险主体的非故意的，非计划性的和非预期的某种价值的减少。这个定义中包括两个重要要素：一是非故意的、非计划性的和非预期的；二是价值的概念，这种价值不一定表现为经济价值。缺少其中的任何一个要素，均不构成风险损失。
管理信息系统建设风险的特征.
风险的特征是指风险的本质及其发生规律的表现。正确认识风险的特征对于企业管理信息系统建立风险机制、加强风险管理、减少风险损失具有重要的意义。
一、客观性
风险是一种普遍的客观存在，人们既不能拒绝也不能否认它的存在。风险存在于客观事件发展变化的整个过程中，无时不有无处不在。我们必须承认和正视风险的客观存在，并且采取积极的态度，认真对待风险；
二、可预测性
风险是可以预测的。我们可以根据以往发生的类似事件的统计资料或者别人的经验，通过分析和研究，对某种风险发生的可能及可能造成的危害进行预测和评价，在此基础上进行风险控制和管理。管理信息系统建设的风险完全可以通过借鉴其它的系统建设的情况进行预测和判断，对突出的风险因素进行控制。
三、损失性
风险的发生必然会导致损失。对于管理信息系统建设而言，风险造成损失是肯定的，而且这种损失有时侯很难估计它的大小，有的风险造成的损失对系统来说甚至可能是致命的，使系统建设完全归于失败，最后无法产生任何效益。
四、结果的双重性
虽然管理信息系统建设的风险必然造成损失，但是如果能够对这些风险进行有效的控制，可以变不利为有利，对系统质量带来巨大的回报，甚至风险越大，克服风险后带来的正面价值也越大。这就是所谓的“风险越高，利润越丰”的道理。因此，对于管理信息系统来说，只要能够对系统的主要风险因素进行有效的控制，一定可以收到意想不到的效果。
从国内外发生的大量的事实可以看出，管理信息系统建设的风险管理能力在一定程度上决定了系统建设的成败，其中的风险不仅表现在技术和基础设施这些硬件方面的驾御能力，更加突出表现出来的是关于人、组织和制度方面的因素，对这些因素加强管理，找到问题发生的根本原因和有效的解决方法是成功的关键。
新产品开发中的风险评估
新产品开发是一个复杂的、动态的、连续的过程，其中涉及到大量的信息收集、分析、筛选及传递，各种模式方案的选择与确定，各种要素资源的投入与配置，新产品生产
及营销战略制定等一系列的工作.这些工作都不同程度地存在不确定性，从而导致企业新产品开发风险的发生。因此，要成功进行新产品开发，就必须加强对新产品开发中的风险分析与评估。
风险辩识。对企业新产品开发风险评估，首先必须找出可能影响新产品开发成功的风险因素，研究各种风险因素会对新产品开发造成什么样的后果，该阶段一般被称为风险辩识，是进行任何风险评估的前提和基础。企业新产品开发中的风险评估主要包括以下风险因素：
技术风险。指企业在新产品开发过程中，因技术因素导致新产品开发失败的可能性。技术风险大小由下列因素决定：技术成功的不确定性；技术前景的不确定性；技术效果的不确定性；技术寿命的不确定性。 市场风险。指新产品的相对竞争优势的不确定性，市场接受的时间、市场寿命及市场开发所需资源投入强度等难以确定，而导致新产品开发失败的可能性。新产品开发出来以后，价格往往较贵，同时人们对新产品的质量、性能及其稳定性往往要观望一段时间，或等别人使用后再购买，这就阻碍了新产品快速渗透并占领市场。若新产品不能在短时间内占领市场，则很可能失败夭折。因为若这项技术也被竞争对手看中，他们很可能模仿并加以改进，在短时间内追赶上来，且其产品更具优势。这时，刚刚被引导出来的市场，很可能被竞争对手占领。
资金风险。指因资金不能适时供应而导致新产品开发失败的可能性。若不能及时供应资金，会使新产品开发活动停顿，其技术价值随着时间的推移不断贬值，甚至被后来的竞争对手超越，初始投入也就付之东流。此外通货膨胀也会引起资金风险。
环境风险。指新产品开发由于所处的社会环境、政策环境、法律环境等变化或由于自然灾害而造成新产品开发失败的可能性。因此，新产品开发，必须重视环境风险的分析和预测，采取有效的对策和措施，把环境风险减少到最小限度。
生产风险。指在新产品开发过程中，由于生产系统中的有关因素及其变化的不确定性而导致新产品开发失败的可能性。如难以实现大批量生产、生产周期过长、工艺不合理、设备和仪器损坏、检测手段落后、产品质量难以保证、可靠性差、供应系统无法满足批量生产的要求等。
管理风险。指在新产品开发过程中，由于管理失误而导致新产品开发失败的可能性。如组织协调不力、其他部门配合不好、高层领导关注不够、调研不充分、市场信息失真、市场定位不准、营销组合失误、风险决策机制不健全、研发过程不协调等。
工程风险转移措施
风险管理是人们对潜在的意外损失进行辩识、评估、预防和控制的过程。建筑工程由于其规模大、周期长、生产的单件性和复杂性等特点，在实施过程中存在着施工不确定的因素，比一般产品生产具有更大的风险，进行风险管理尤为重要。 风险管理是对项目目标的主动控制。首先对项目的风险进行识别，然后将这些风险定量化，对风险进行控制。国际上把风险管理看作是项目管理的组成部分。风险管理和目标控制是项目管理的两大基础。在工业发达国家和地区，风险转移是工程风险管理对策中采用最多的措施，工程保险和工程担保是风险转移的两种常用方法。（一）工程保险 工程保险是指业主和承包商为了工程项目的顺利实施，向保险人（公司）支付保险费，保险人根据合同约定对在工程建设中可能产生的财产和人身伤害承担赔偿保险金责任。工程保险一般分为强制性保险和自愿保险两类。在工业发达国家和地区，强制性的工程保险主要有以下几种：建筑工程一切险 （附加第三者责任险）、安装工程一切险（附加第三者责任险）、社会保险 （如人身意外险、雇主责任险和其他国家法令规定的强制保险）、机动车辆险、10年责任险和5年责任险、专业责任险等等。其中，建筑工程一切险和安装工程一切险是对工程项目在实施期间的所有风险提供全面的保险，即对施工期间工程本身、工程设备和施工机具以及其他物质所遭受的损失予以赔偿，也对因施工而给第三者造的人身伤亡和物质损失承担赔偿责任。过去，一切险的投保人多数为承包商；现在，国际上普遍推行由业主投保工程一切险。在工业发达国家和地区，建筑师、结构工程师等设计、咨询专业人均要购买专业责任险，对由于他们的设计失误或工作疏忽给业主或承包商造成的损失，将由保险公司赔偿。国际上工程涉及的自愿保险有以下几种：国际货物运输险、境内货物运输险、财产险、责任险、政治风险保险、汇率保险等等。国际上工程保险的通行做法和特点是：保险经纪人在保险
业务中充当重要角色、健全的法律体系为工程保险发展提供了保障，投保人与保险商通力合作是控制意外损失的有效途径，保险公司返赔率高且利润率低。 （二）工程担保 工程担保是指担保人（一般为银行、担保公司、保险公司、其他金融机构、商业团体或个人）应工程合同一方（申请人）的要求向另一方（债权人）作出的书面承诺。工程担保是工程风险转移措施的又一重要手段，它能有效地保障工程建设的顺利进行。许多国家政府都在法规中规定要求进行工程担保，在标准合同中也含有关于工程担保的条款。 在工业发达国家和地区，常见的工程担保种类如下：第一，投标担保：指投标人在投标报价之前或同时，向业主提交投标保证金（俗称抵押金）或投标保函，保证一旦中标，则履行受标签约承包工程。一般投标保证金额为标价的0.5~5%；第二，履约担保：是为保障承包商履行承包合同所作的一种承诺。一旦承包商没能履行合同义务，担保人给予赔付，或者接收工程实施义务，而另觅经业主同意的其他承包商负责继续履行承包合同义务。这是工程担保中最重要的，也是担保金额最大的一种工程担保；第三，预付款担保：要求承包商提供的，为保证工程预付款用于该工程项目，不准承包商挪作他用及卷款潜逃；第四，维修担保：是为保障维修期内出现质量缺陷时，承包商负责维修而提供的担保，维修担保可以单列，也可以包含在履约担保内，有些工程采取扣留合同价款的5%作为维修保证金。
以上四种担保是在工业发达国家和地区常见的工程担保种类，除此这外还以以下几种：反担保、付款担保、业主无能为力担保、分包担保、临时进口物资税收担保、完工担保、差额担保、施工执照担保等。 由于建筑工程在建设过程中存在着越来越多的不确定性因素，风险管理正成为工程项目管理日益重要的一个组成部分。
如何控制信息技术外包的风险？
失控与风险控制
风险失控还表现在：服务不能及时到位以及质量无法保证；灵活性减弱，需求的变化及其满足必须与外包商协调后才能得到解决；成本攀升，外包商常常会要求支付一些附加费用；企业秘密和机密信息可能会泄露给外包商；企业内部的智力资产可能会受到侵犯等；
外包商的选择及其风险
如果签署一个长期的外包合同，企业可能无法分享技术进步带来的经济利益；对于创业初期的企业而言，如果不能够准确地预见业务需求及其变化并与外包商及时沟通，那么外包就会制约企业的发展；外包商本能地趋向于控制成本以提高自身的利润；外包商提供的是过时的设备和服务；外包商提供的往往不是一流的人员，有时甚至是外包商支付薪金的本企业以前的雇员。
技术变迁的风险
信息技术仍在以不可预见的方式在变化，企业业务环境的变化也带有不可预知性，这两者的结合加剧了信息系统的不确定性：当技术和业务环境同时处于不确定状态时，外包的信息系统如何支持未来的业务需求？信息技术的学习及其在企业中的最佳的应用更多的是一个经验过程，如果外包出去，外包商是否有足够的积极性去学习企业所需要的信息技术？
测度和管理的风险
外包后的系统成本一般不会减少，减少的主要是可变成本，所以要计算所有的成本包括管理外包活动的时间、努力和人力的成本；在外包过程中，企业要依赖一个外包商但又无法控制其行为如外包商利润最大化、外包商的转包等，事实上，合同对于企业而言是一种束缚而对外包商而言则是一种可利用的手段；外包可能会阻止企业内部信息技术人员对新技术及其应用的学习，而鼓励学习意味着成本的增加；外包会丧失一些灵活性。
怎样做好软件项目风险计划
风险评价是识别并分析潜在风险区域的过程。可以通过列举通常的软件项目风险因素以使风险识别更加明析。制作风险评估表是识别风险的好办法，在风险评估表中我们统计特定风险对项目可能造成的潜在后果，风险计划的要素有： 风险描述对于风险情况的介绍。
可能性风险发生的可能性。风险不是必然要发生的，如果一个对项目存在危害的事件是必然要发生的，
那这个事件就不能作为风险。对于风险可能性的标识有助于对那些高可能性的风险投入更大的关注。 严重性风险如果发生对于项目的危害程度。 危害值一个综合考虑可能性和严重型后对风险的一个评估，这个评估反应了风险应该被关注的程度。 对策 对策分为两个部分：一是对于采取预防措施以阻止风险的发生，另一方面也要考虑如果风险发生后需要采取什么措施。这两方面的计划构成了完整的风险对策。 触发标志风险是一种可能性，并且制定风险主要的出发点是预防它，但也要考虑到风险发生后情况。对于风险发生后的应对策略，需要争取一定的提前时间以启动必要的各项工作，设立触发标志是为设立一个判别标识，在该触发标志所标明的条件具备时，说明风险已经越来越可能成为现实了。
风险责任人风险预防和跟踪需要有人的参与，在风险计划中责任明确是一个重要的原则，对每一个列入了视线的风险都要指定对风险预防和跟踪负责的人员。 风险计划不是一个静止的文件，它应该随着项目状况的变化而变化。所以在任何项目中，风险管理都必须被作为一个日常的正式活动列入项目工作计划，成为项目管理人员的一个重要工作。在下一节风险跟踪中将对风险的动态变化作出更详细的阐述。 在标定风险可能性和危害时，重要的是清楚地标明风险之间重要性的相对比较，所以采取一个简明的标注标准十分重要
信息化项目中的风险管理
实施任何项目都有风险，即在企业投入相应资源后没有如期实现项目目标。出现项目风险的根源在于，在项目实施过程中会发生很多意想不到的某些事件，这些事件导致实际结果偏离预期目标。和工程项目相比，信息化项目的实施风险更大，因为信息化项目是看不见、摸不着的项目。如何规避信息化项目的风险呢？ 项目风险管理，就是在项目实施过程中对项目可能出现的问题进行主动而系统的识别、评估并及时采取相应的应对措施和行动，减少风险带来的损失。风险管理由风险识别、风险评估和风险应对三个部分组成。 风险识别
风险识别就是确定风险事件及其来源。由于风险的不确定性，风险识别实际上只能算是一种预测分析，是对可能会给项目目标实现带来负面影响的环节和因素所进行的假想。目的是做到有备无患，当实际风险发生时能有效应对。
需要注意的是，风险识别将贯穿于项目实施的全过程，而不仅仅是项目的开始阶段。风险因素可能来自需求、技术、资金、实施方等各个方面，但项目实施最根本的目标是实现项目的期望，因此风险识别也应重点关注影响项目期望的因素。同时在风险识别过程中，也需要辩证地分析风险因素的负面效应（即风险带来的威胁）和正面效应（即潜在的机会）。
具体的项目风险识别方法，主要有：
① 头脑风暴法，就是由项目小组成员在一起，反复假设“如果……，那就会……”，充分预测信息化项目中出现的各种情况，从而尽可能多的找出影响项目成功实施的因素。
② 专家判断法，即请教擅长信息化项目实施的专家、学者、教授，经验丰富的项目经理、实施顾问等，从理论与实践多方面来判断项目风险因素的正面效应和负面效应。
③ 调查问卷法，即事先设计相应的表格、问卷，然后选取特定的调查对象，然后总结出项目的风险；另外，询问项目组成员也非常有帮助，问问他们以前做过的项目里曾发生过哪些意料不到的问题。也许管理部门又提出了新的优先项目，也许最好的成员突然不能参加进来了，也许预算减少了，也许其中的一项任务完成拖期了，也许另一个小组超出了预算，或者也许出现了未预见到的技术问题……要把进度（包括可能延误项目的因素）、人员（包括威胁到位的因素）、财务（包括威胁预算的因素）以及范围（包括导致最终产品的难以完成的因素）等各方面的风险一一区分开来。
④ 经验总结法，就是借助以往企业信息化项目实施的经验教训，来类推、联想这个信息化项目中的风险因素。
转贴于：中国项目管理资源网⑤ 理论分析法，即通过建立数学模型等方法从理论上来分析信息化项目的风险，比如决策树、敏感性分析、蒙特卡罗模拟等。
风险评估
风险评估又称作风险量化，就是比较风险的大小，从而决定是否需要采取相应的应对措施。风险评估的方法很多，归纳起来主要包括以下几种：用风险发生的概率来评估风险发生的可能性；用风险带来的损失来评估风险发生的严重性；用现有的手段能否控制风险的发生来评估风险发生的可控性；用风险影响的地域大小、对象多少等来评估风险影响的范围；用风险发生在项目生命周期的阶段来评估风险发生的时间。 实际项目风险管理过程中，常常用逐项评分的方法来量化风险的大小，即事先确定评分的标准，然后由项目小组一起，对预先识别的项目风险一一打分，然后得出不同风险的大小。风险应对针对风险评估的结果，制定相应的应对措施去响应风险，就是风险应对，其目的是创造机会，回避威胁。风险应对中，需要对风险的正面效应（即潜在的机会）制定增强措施，对风险的负面效应（即可能的威胁）制定应付方法。对于不同的风险，需要根据其重要性、影响大小以及已经确定的处理优先次序，采取相应的措施加以控制，对负面风险的反应可以是尽量避免、努力减小或设法接收。另外，在处理风险时需要注意应对的“及时性”和“反复性”，即在第一时间对各种突发的风险作出判断并采取措施；对已经发生或已经得到控制的风险经常进行回顾，确保风险能够得到稳定长期的控制。
项目风险应对的措施主要有：
① 修正项目目标或范围。尽管有深入的项目调研和详尽的项目规划，但信息化项目过程中的需求改变常常难以避免，因此为保证项目的实施效果，对项目的目标或范围加以必要修正，能够有效应对项目偏离需求的风险。
② 加强培训。加强项目培训能够提高参与项目的IT人员和业务人员甚至管理人员、决策者对信息化项目的认知，对规避项目的实施风险有良好的效果。转贴于：中国项目管理资源网
③ 准备风险保证金，适当预留项目计划时间。信息化实施往往周期较长，在项目预算中预留一定数量的风险保证金，时间计划中预留一定的时间，能够有效应对由于项目需求改变或者范围增加而造成的时间和成本风险。
④ 始终贯彻项目管理的标准流程。严格执行项目管理中的时间、成本、质量控制等标准流程，能够有助于控制项目风险。
⑤ 引入第三方咨询和监理。信息化项目初期尤其是刚刚开展信息化项目的企业，在信息化项目实施中引入第三方咨询和监理，能够利用第三方的专家优势和对项目实施的经验来应对项目风险。
⑥ 加长模拟阶段的周期。信息化项目中最重要的是信息系统与企业业务流程的结合，因此加长系统模拟业务流程的周期，使之充分适应企业业务流程，能够保证项目对企业的适应性，从而降低项目的实施风险。⑦ 行政强制手段。项目实施应以培训和沟通为主，但并不排除采用行政手段强制实施，对于项目中的某些难点，采用行政强制手段能够起到很好的效果。
⑧ 终止项目。这是一种极端的做法，往往由于项目目标没有明确所致，采用这种做法虽然会导致项目的彻底失败，但也是万不得已，能够避免企业更大的损失。