投资项目风险

投资项目风险

【篇一：投资项目风险】

任何问题，如果找到了真正原因，其实已经向解决问题迈进了一大步。针对以上风险发生的原因，我们可以采取以下一些策略来降低风险带来的损失甚至规避大多数风险。

在项目计划中重视风险的评估

很多项目主管在项目启动的时候认为既然团队已经建立好了，项目计划已经制定好了，就可以憧憬着项目成功了。其实没有任何两个项目是一模一样的，任何项目都会有风险的。在项目初期认真做好风险的评估，并且能让你的项目干系人（尤其是项目主管的掌控项目资源的负责人）清楚这些风险，那么一旦风险发生，也可以更加从容不迫的应对，并且有理由更好的协调资源，不至于让大家不知所措。

要重视需求工作

一个好的需求是连接层面和层面两类人，让他们达成一致的目标的关键，对于大型的复杂的项目尤其重要。好的需求可以很好的控制客户需求变更给项目带来的负面影响，（很多项目都是这样，不断的需求变更导致不断的修改，如此反复，最后陷入无法自拔的泥潭），因为客户一旦签字确认以后，这份需求就应该与商业合同一起具备法律效力而对客户进行必要的约束；另外一份清晰的没有二义性的需求可以让开发人员非常清晰自己应该完成什么工作，测试人员很好的编写测试用例，就是这份需求，可以大大降低项目组以后在沟通、修改方面的成本，提高效率和产品质量。

其实大部分人都知道“需求”的重要性，有些人肯定会说：“项目时间和资源有限，怎么可能化那么多精力专门做需求呢？”。这是一种误区，需求并不一定要长篇累犊、事无具悉，但是一定要有需求。具体需求怎么写，应该对整个项目做评估以后制定一个策略。比如因为公司长期从事某方面业务，那么这些就可以写简单点；或者项目时间太紧，那么需求文档的模版可以根据实际情况做一些必要的简化。

不合格的需求，往往会因为当初一时的懒惰而让项目最终付出几倍的惨重代价。需求是项目的一份纲领性文件，是以后项目路线的指挥棒，好的需求一定能清晰的描述出整个项目：包括都要做什么以及这些事情的优先级。比如知道优先级以后，项目的管理者就可以

根据重要性、难以程度而因人制宜的分派工作，尤其遇到时间特别

紧张的情况下，可以说服客户先上最重要的系统模块而把一些不重

要的放在以后逐渐实施，这样把好钢都用在刀刃上，在资源等方面

受到很多限制的前提下，尽量做到大家的满意，这也为降低日后的

风险打下了坚实的基础。

重视项目文档的管理

让项目主管最痛苦的事情莫过于：当一个重要成员半途离开项目组时，才发现他根本就没有留下任何可用的文档。尤其在it项目中，

人员流动性强，文档就是成员之间交接的重要工具。但是很多主管

很容易陷入“重技术实现，轻文档”的误区，他们总是认为项目实施

时间紧迫，为了节省时间，可以在项目收尾阶段突击写文档。要是

项目周期稍长一点，到了最后，谁还会清清楚楚记得每个实现细节呢？如果下一个项目与此类似，以前的劳动成果还有谁能继承得下

来呢？

当然，现在越来越多的公司已经注意到了管理好文档的重要性，一

般可以借助vss、cvs、等工具来很好的对文档进行版本控制，但是

有一点要特别引起注意：单单关注文档本身远远不够，还要重视文

档的质量！即使是在现在很多管理很规范（比如已经通过了cmm3、iso9000等认证）的公司，“重过程、轻质量”也是一个突出问题。一般在每一份文档入基线以前，都要通过评审、同行评审等方式来对

文档进行专门的“轰击”以保证文档的有效性，这些评审小组中如果

能包括一些行业、技术方面的专家将经常能达到更好的效果，这些

专家完全可以从公司外面聘请。

有了完善和有效的文档做基础，能降低很多项目过程中的风险。

重视质量过程控制

作为一个项目管理者，明确这种研发和质控的关系，除了更好的保

证项目质量以外，还能客观的反映项目实际情况，通过这些文档来

表明每个基线、每个成员的工作量和完成质量，对识别、预测项目

风险意义重大，当然，这些措施也大大降低了项目过程中可能的风

险发生的概率。

重视架构和概要设计

在it项目中，编码实施固然重要，但是对于一个比较复杂项目中的

项目组来讲，如何让不同角色的研发人员高效协作，将是更加要紧

的问题。

设计，尤其是架构设计就是能够让这些研发资源更加高效协作，降

低返工的有效手段。有了这些设计作为指引，研发人员就可以同步

工作，共享公用的资源（比如，经过设计分析以后，发现客户业务

方面有a、b、c三个业务模块，但是其实这三个模块中有几乎50%

在技术实现上是公用的）。在实际设计的操作过程中，可能有时候

项目组内部成员几乎没有一个有经验，那么最好还是聘请一些外部

的专家来帮忙，我在实际的项目中，发现这个效果会比较好。

有了这些有效的纲领性的技术文件，会在实际开发过程中大大降低

各种潜在的风险。

采用积极的应对风险的措施

让人遗憾的是，即便我们做了很多的事情来防止风险的发生，通常

还会有风险发生。一旦突如其来的风险发生了，例如：项目组核心

成员突然病倒，客户组织结构发生调整或者虽然当初签订了合同确

认了需求，但是客户业务调整了，那么我们总不能一意孤行的还是

移交给客户一套其实已经无法运转的系统吧。这些风险一旦发生，

躲避不是办法，作为一个项目主管来说，更加行之有效的办法是带

领整个团队，用积极的心态、科学合理的方法来以最小的代价克服它。当然，这也需要项目组的经验以及项目主管的综合素质来支撑。通常处理风险的过程分为三步走：识别量化应对。通过风险识别确

定哪些风险可能影响项目，并把风险归档作为以后过程财富的很好

的积累，把产品、历史信息、其它相关信息作为输入，利用检查表、流程图、面谈等手段，得出风险的来源、征兆等结论；风险量化是

指评价风险和它们之间的相互作用，从而评估项目可能结果的大围。如果你想启动风险量化过程，那么你需要首先知道这些风险的来源，量化是一项比较复杂的活动，除了采取货币、时间等来衡量以外，

最好借助专家的判断。有了比较量化的结果以后，项目主管就能清

晰的意识到风险的严重性，从而做出更加贴切的应对措施；有了以

上的结果以后，就可以制定风险应对措施来制定应对措施了。

处理/项目风险

【篇二：投资项目风险】

①卸载可比企业财务杠杆：

②加载目标企业财务杠杆

④计算目标企业的加权平均资本成本

2.扩展