990-15产品经理:Project failure--12 mistakes to avoid 项目失败——要避免的12个错误

Introduction

Have you ever been part of a failed IT project? If analyst research over the past 5 years is even close to being accurate, the answer is YES. Lets take a look at the definition of a successful IT project. A successful project is any initiative that satisfies all 5 of these criteria:
• Completed at or under budget.
• Completed on schedule.
• Meets sponsor objectives.
• Meets defined requirements of features and functions.
• Customers score the product as satisfactory or better.
If your projects do not meet all five success criteria, all the time, you need to read further to learn the roadblocks to avoid and the actions to take to make current and future projects successful.
介绍
你曾经参与过失败的IT项目吗？如果分析师在过去5年的研究是准确的，甚至接近，答案是肯定的。让我们来看看一个成功的IT项目的定义。一个成功的项目是满足所有5个标准的任何倡议：
·按预算或在预算之下完成。
·如期完成。
·满足赞助商的目标。
·满足定义的特性和功能要求。
·客户对产品的评分为满意或更好。
如果你的项目不符合所有五个成功标准，所有的时间，你需要进一步阅读，以了解路障，以避免和采取的行动，使当前和未来的项目取得成功。

Numbers Talk

The Standish Group Chaos Report (2003), a study of over 13,000 projects, shows project success rates have increased over the past 10 years, but still shows that 2 out of 3 projects are not successful. The Chaos report shows only 34% of projects meet all the criteria for a successful project. Challenged projects, those that only met a few project successes criteria measurements, contributed to 51% of the projects. Failed projects, those meeting none of the project success criteria, contributed to 15% of the projects. As with other research reports, it is safe to assume that today’s IT project success rate is between 28 to 35%.
The Standish Group Chaos Report (2003) also shows the lost dollar value for US projects is estimated at $38 billion with another $17 billion in cost overruns for a total project waste of $55 billion against $255 billion in project spending.
The bottom line is, 21% of the money your organization spends on IT projects is thrown away. That means, for an organization that budgets $10 million for IT projects this year, they will be receiving no value from $2.1 million of the money spent.
For consulting service organizations who specialize in turn-key projects, the data can be viewed another way. If their organization is financially responsible for the success of $10 million in a project portfolio, they could be performing $10 million of services work while only generating $7.9 million in revenue.
In the article Why Do System Implementations Fail (Sommers, 2003) a survey of 417 IT executives and managers lists 36 items to mitigate during a project to improve project performance.
After years of project successes and roundtable discussions with IT and business executives across the country, I have identified the “TOP 12” IT project mistakes that must be avoided.
数字说话
Standish Group Chaos Report（2003），一份对超过13,000个项目的研究报告显示，在过去的10年中，项目的成功率有所增加，但仍然显示，三分之二的项目是不成功的。Chaos报告显示，只有34%的项目符合成功项目的所有标准。具有挑战性的项目，即那些仅满足少数项目成功标准测量的项目，贡献了51%的项目。失败的项目，那些不符合项目成功标准的，贡献了15%的项目。与其他研究报告一样，可以安全地认为，今天的IT项目成功率在28%到35%之间。
斯坦迪什集团的混乱报告(2003年)还显示，美国项目损失的美元价值估计为380亿美元，另有170亿美元的成本超支，项目浪费总额为550亿美元，而项目支出为2550亿美元。
底线是，您的组织在IT项目上花费的资金中有21%被浪费掉了。这意味着，对于一个今年为IT项目预算1000万美元的组织来说，他们将无法从210万美元中获得任何价值。
于专门从事交钥匙项目的咨询服务机构来说，可以从另一个角度来看待这些数据。如果他们的组织在财务上对1000万美元的项目组合的成功负责，那么他们可以执行1000万美元的服务工作，而只产生790万美元的收入。
在为什么系统实现会失败（Sommers，2003）这篇文章中，对417名IT主管和经理进行了调查，列出了36个在项目期间需要缓解的项目，以提高项目性能。
经过多年的项目成功经验以及与全国各地的IT和业务主管的圆桌讨论，我已经确定了必须避免的“12大”IT项目错误。

1. Project Is Not Part Of The Strategic Plan

A strategic plan identifies your company’s business goals and the solutions needed to support those business goals. If a project does not line up with one of the items on the strategic plan, you should not do the project.
Many organizations are in “re-active” mode. Their focus is on the hottest fire of the day. These organizations usually look at a strategic plan once a year or sometimes never create one. Within these organizations, project failure is more prominent than project success. What is the key? Projects aligned with business goals on the strategic plan will “add value” to the business and your customers.
A large manufacturing organization implemented an expensive application monitoring solution that was implemented on-time and 13% over budget. The justification for the project: Help desk staff would better understand the user application needs and problems when they called in with an issue. The project team considered this a success, plus they had some cool technology to play with.
Unfortunately for the project team, the CFO attended the project de-briefing. The CFO’s only question to the team was: “How does this product help us produce more widgets, reduce inventory, or improve customer service?” After a minute of silence and blank faces, the CFO then stated that this project was a failure and just cost us $300,000 plus, returning no value to the business.
This project team learned a lesson the hard way.

1. 项目不是战略计划的一部分
   战略计划确定了公司的业务目标以及支持这些业务目标所需的解决方案。如果一个项目不符合战略计划中的一项，你就不应该做这个项目。
   许多组织处于“重新活跃”模式。他们的注意力都集中在一天中最火热的火上。这些组织通常每年看一次战略计划，有时甚至从来不制定战略计划。在这些组织中，项目失败比项目成功更为突出。关键是什么？与战略计划上的业务目标相一致的项目将为业务和您的客户“增值”。
   一家大型制造企业实施了一个昂贵的应用程序监控解决方案，该解决方案按时实施，超出预算13%。该项目的理由：当用户打电话来解决问题时，服务台工作人员可以更好地理解用户应用程序的需求和问题。项目团队认为这是一个成功，加上他们有一些很酷的技术玩。
   不幸的是，项目组的CFO参加了项目汇报会。CFO向团队提出的唯一问题是：“这个产品如何帮助我们生产更多的小部件，减少库存，或者改善客户服务？”沉默了一分钟，首席财务官面无表情地说，这个项目失败了，只花了我们300,000多美元，没有给公司带来任何价值。
   这个项目团队得到了惨痛的教训。

Roadblocks
• Non-strategic projects are first to be cancelled.
• Team members and other resources are pulled for high priority “strategic” projects.
• Executive and business unit time commitments are limited.
• Project budget is reduced.
• Executives and business units are slow to respond to critical issues, risks, or project activities.
Action To Take
• Identify which item on the strategic plan your project supports.
• Understand the priority of this strategic plan item.
• Understand the “value” your project brings to the business.
• Decide whether the risks are to high to continue.
路障
·非战略性项目优先取消。
·为高优先级的“战略”项目拉动团队成员和其他资源。
·行政和业务部门的时间承诺是有限的。
·项目预算减少。
·高管和业务部门对关键问题、风险或项目活动的反应迟缓。
要执行的操作
·确定您的项目支持战略计划中的哪一项。
·了解本战略计划项目的优先级。
·了解你的项目给企业带来的“价值”。
·决定是否风险太高而不能继续。

2. No Executive Sponsorship

Executive sponsorship of your project is vital for project success. Active sponsor participation has historically ensured a project will be on-time, within budget, and meet the business goals. Take a look at the projects you have been involved in over the past year. When there is an executive sponsor sitting in status meetings, reviewing plans, meeting with team members, etc. the project team stays focused on the project objectives, roadblocks are removed immediately, and morale is up.
Project teams seem to feed off the executives leadership and focus. Projects that are delegated down to line level managers seem to float along, stop when issues arise, and go in fragmented directions. These projects have a higher risk of failure.
2. 无行政赞助
项目的执行赞助对于项目的成功至关重要。从历史上看，积极的赞助商参与可以确保项目按时、在预算范围内并满足业务目标。看看过去一年你参与的项目。当有一个执行发起人坐在状态会议上，回顾计划，与团队成员开会，等等。项目团队专注于项目目标，障碍被立即移除，士气高涨。
项目团队似乎依赖于高管的领导力和专注力。被授权给直线级经理的项目看起来像是漂浮着，当问题出现时就停止了，并且朝着分散的方向前进。这些项目失败的风险更高。

Roadblocks
• Project does not get the right level of support when needed.
• Project goes in fragmented directions.
• Issue resolutions are slow to arrive, sometimes causing a stoppage of the project.
• Project lacks focus.
• No leadership.
Action To Take
• Identify the technical, business, and financial sponsor.
• Determine the sponsors participation in the project.
• Elicit sponsorship from C-Level executives who will receive the greatest value from the project.
路障
·项目在需要的时候没有得到正确级别的支持。
·项目朝着分散的方向发展。
·问题解决方案到达很慢，有时会导致项目的停止。
·项目缺乏重点。
·没有领导力。
要执行的操作
·确定技术、业务和财务赞助商。
·确定赞助商在项目中的参与。
·获得C级高管的支持，他们将从项目中获得最大的价值。

3. Poor Technology Evaluation

Many project failures start at the beginning. The evaluation team is knowledgeable on some aspects of the technology but they do not spend enough time researching solutions and they believe all the hype from vendors and industry media.
We have found successful project teams perform an intensive due diligence upfront by using tools like RFI’s, RFP’s, client visits, demo’s using live customer data, etc. Asking the tough detail questions in the beginning can save your return on investment at the end.
3. 技术评价不佳
很多项目的失败都是从一开始就开始的。评估团队在技术的某些方面是有知识的，但他们没有花足够的时间研究解决方案，他们相信供应商和行业媒体的所有炒作。
我们发现，成功的项目团队通过使用RFI、RFP、客户访问、使用实时客户数据的演示等工具，预先进行了深入细致的尽职调查。在一开始就问一些棘手的细节问题，可以在最后节省你的投资回报。

Roadblocks
• Products selected do not work.
• Products selected have never been implemented before.
• The correct components were not budgeted or purchased until later in the project.
• Vendor goes out of business before project completion.
Action To Take
• Perform an intensive due diligence upfront.
• Verify reality vs. vaporware.
• See it, tough it, and use it in a comparable environment.
路障
·所选产品不起作用。
·所选产品以前从未实施过。
·正确的组件直到项目后期才被预算或购买。
·供应商在项目完成前倒闭。
要执行的操作
·预先进行深入的尽职调查。
·验证现实与雾件。
·看到它，经历它，并在一个可比的环境中使用它。

4. No Customer Involvement

Successful projects need input from the people who will be affected most by the project. The customers should be consulted on the value they will receive from a product. When implementing an inventory control system, your best feedback will come from the inventory control clerks and supervisors. They better understand the business processes and how to improve efficiencies than anyone else on a project team. These customers can best help with process improvements, features, and functions.
Another key factor on customer involvement is “who” will be included on the team. Successful projects have the best and brightest customers on the team. These individuals make the best decisions in a more timely manner. Also, their time is committed to the project to avoid day to day business priorities that would normally take them away from the project.
4. 无客户参与
成功的项目需要受项目影响最大的人的投入。应该向客户咨询他们将从产品中获得的价值。当实施一个库存控制系统，你最好的反馈将来自库存控制文员和主管。他们比项目团队中的任何人都更了解业务流程以及如何提高效率。这些客户可以在流程改进、特性和功能方面提供最好的帮助。
客户参与的另一个关键因素是“谁”将被包括在团队中。成功的项目拥有团队中最优秀、最聪明的客户。这些人以更及时的方式做出最好的决定。此外，他们的时间都投入到项目中，以避免日常的业务优先事项，这通常会让他们离开项目。

Roadblocks
• Products developed do not meet customer needs.
• New business process reduces productivity.
• Product design takes longer than expected.
• Product is not accepted by the customers.
• Products developed do not provide a return on investment or add value to the business.
Action To Take
• Assign the best and brightest customers to the project.
• Commit customer time to the project to avoid day to day priorities.
路障
·开发的产品不能满足客户的需求。
·新的业务流程降低了生产力。
·产品设计所需的时间比预期的要长。
·产品不被客户接受。
·开发的产品不能提供投资回报，也不能为企业增加价值。
要执行的操作
·为项目指派最优秀、最聪明的客户。
·将客户的时间投入到项目中，以避免日常的优先事项。

5. Scope Creep
   Adding additional scope without testing it against the business case and evaluating the impact on the cost, schedule, and risks is the easiest way to sink a project. Modifying products is risky and the most common form of scope creep. The project best practice is to implement quickly, get the benefit quickly, and modify later. As an example, waiting on software features is better than getting off the vendor upgrade path.
   A large retailer implementing a retail management system decided their operations were so unique that they changed 90% of the programs during a two year, $11 million implementation. During the development phase of this project, the vendor released a new and improved version of the software. Once the modified package was implemented, the retailer looked at upgrading to the new release. First, they found that they were not eligible for software upgrades since they modified the code. Second, analysis determined that they would need one full year of programming effort to input the same modifications into the new release. End result, they will be customizing and running this system until it breaks or they can cost justify the purchase of a new system.
6. 范围蔓延
   增加额外的范围，而不对照业务案例进行测试，也不评估对成本、进度和风险的影响，这是使项目失败的最简单的方法。修改产品是有风险的，也是范围渐变的最常见形式。项目的最佳实践是快速实施，快速获得收益，稍后再进行修改。例如，等待软件特性比脱离供应商升级路径更好。
   一家大型零售商实施了一个零售管理系统，他们决定他们的业务是如此独特，他们在两年的时间里改变了90%的程序，花费了1100万美元。在该项目的开发阶段，供应商发布了该软件的新的改进版本。修改后的软件包实施后，零售商开始考虑升级到新版本。首先，他们发现，他们没有资格获得软件升级，因为他们修改了代码。第二，分析确定，他们将需要整整一年的编程工作，才能将同样的修改输入新版本。最终的结果，他们将定制和运行这个系统，直到它打破或他们可以证明成本购买一个新的系统。

Roadblocks
• Development never ends, product changes frequently.
• Modifications to product during initial development drastically increases your risk of failure.
• Getting off the vendor upgrade path.
• Unexpected increase in cost, effort, and duration.
Action To Take
• Only modify products if business critical.
• Test the change in scope against the business case.
• Evaluate impact on cost, schedule, and risks.
• Implement scope changes in the next release.
• Set up a Change Management Committee.
路障
·开发无止境，产品变化频繁。
·在初始开发期间对产品进行修改会大大增加失败的风险。
·脱离供应商升级之路。
·成本、工作量和工期的意外增加。
要执行的操作
·仅在业务关键时修改产品。
·根据业务案例测试范围变更。
·评估对成本、进度和风险的影响。
·在下一个版本中实现范围变更。
·成立变革管理委员会。

6. Invalid Pilots

Pilot phases of a project can be very enlightening. What a great tool, test the product in a smaller real life environment. Failure occurs when the pilot does not simulate reality.
A mid west distribution company built a brand new lab environment for the new Back Office System project. The pilot was a complete success. Problems started occurring during the rollout of the software to remote locations. Unknowingly, a project lead asked “What is the hardware configuration of the pilot test lab?” What did they find? The lab was built with the latest and greatest server and desktop hardware. The remote facilities were running hardware from five years ago and did not support the new software.
6. 无效飞行员
一个项目的试验阶段可能非常有启发性。真是一个伟大的工具，在一个较小的现实生活环境中测试产品。当飞行员没有模拟现实时，就会发生故障。
一家中西部分销公司为新的后台系统项目构建了全新的实验室环境。试点取得圆满成功。在向远程地点推出软件期间开始出现问题。在不知情的情况下，一个项目负责人问“中试验室的硬件配置是什么？”他们发现了什么？实验室是用最新最棒的服务器和桌面硬件建成的。远程设备运行的硬件是五年前的，不支持新的软件。

Roadblocks
• Pilot lab equipment does not mimic reality.
• Works in the lab, not on the product floor.
• Product can be a complete failure on the first day it is released.
Action To Take
• Before starting, document an accurate inventory of all hardware, software, and other production environment information.
• Validate the pilot tests for all environment configurations.
路障
·中试实验室设备不能模拟现实。
·在实验室工作，而不是在生产现场。
·产品可能在发布的第一天就彻底失败。
要执行的操作
·在开始之前，记录所有硬件、软件和其他生产环境信息的准确清单。
·验证所有环境配置的试点测试。

7. Inadequate Testing

Question: What is the second item cut when a project is low on funding or over budget? Answer: Testing of course.
Limiting your testing of a solution will increase the chance of system failure or unknown bugs that can cripple your business. Do not skimp on testing to save time or money. Eliminate features first.
To limit project failure, the testing phase should consist of system test, customer acceptance testing, volume testing, and stress testing to test scalability.
7. 测试不充分
问题：当一个项目资金不足或超出预算时，第二个被削减的项目是什么？答:当然是测试。
限制解决方案的测试将增加系统故障或未知错误的几率，从而削弱您的业务。不要为了节省时间或金钱而吝啬测试。首先消除特征。
为了限制项目失败，测试阶段应该包括系统测试、客户验收测试、容量测试和压力测试，以测试可伸缩性。

Roadblocks
• Dramatic increase in product bugs.
• Dramatic increase in quality issues.
• Increased risk of product failure.
• Increased costs during deployment and support.
• Low customer satisfaction.
Action To Take
• Eliminate features before cutting back on testing.
• Testing should include system test, customer acceptance test, volume test, and stress testing.
路障
·产品缺陷的急剧增加。
·质量问题急剧增加。
·产品不合格的风险增加。
·部署和支持过程中的成本增加。
·客户满意度低。
要执行的操作
·在减少测试之前消除特性。
·测试应包括系统测试、客户验收测试、容量测试和压力测试。

8. Poor Planning

Rolling out a product to one location is fairly simple. Now, take the same product and try deploying it to hundreds of locations across the country simultaneously. Multiple location deployments are more of a challenge to do quickly and cost effectively. Larger deployments require more planning due to greater chances of conflicts and timing issues. Proper planning of equipment and resources will make or break the project.
8. 计划不周
将产品推广到一个位置是相当简单的。现在，拿着同样的产品，试着把它同时部署到全国数百个地点。多个位置的部署更是一个挑战，要做到快速和成本效益。由于冲突和时间问题的可能性更大，更大的部署需要更多的规划。设备和资源的适当规划将决定项目的成败。

Roadblocks
• Number of outside locations to deploy products increases project complexity and risk exponentially.
• Unknown conflicts and timing issues delay project.
• Unexpected staffing needs.
• Unexpected equipment and supply needs, increasing cost of project.
Action To Take
• Perform a detail plan before the start of the project
• Review and adjust plan on a daily basis
路障
·部署产品的外部位置的数量呈指数级增加了项目的复杂性和风险。
·未知的冲突和时间问题延迟项目。
·意想不到的人员配置需求。
·意外的设备和供应需求，增加项目成本。
要执行的操作
·在项目开始前执行一个详细的计划
·每天回顾和调整计划

9. Rolling Out At The Wrong Time

Proper timing of a project “Go Live” is an important success factor that is often challenged by missed milestone dates. Business sponsors want solutions implemented before peak times where it will provide the greatest benefit. However, pilots and testing cannot be sacrificed. Pressing your luck on the timing of a rollout can be disastrous.
A small specialty retailer was behind schedule on a warehouse system implementation. The original planned completion date of the project was one month prior to the Christmas rush where the facility pushed through 1/3 of the yearly volume. Scope creep added an additional 2 months to the project, but the new date was not acceptable. Limiting the software testing reduced this overage by 1 month. Therefore, the team was behind schedule by 1 month, but could be implemented days before the Christmas rush.
This new software was so important to the business that they made a decision to “Go Live” the weekend before the heaviest volume would arrive. Due to poor testing, the system could not handle the warehouse volume which slowed productivity and delayed shipments to the stores. A project post mortem review estimated a $13 million loss of sales caused by the poorly timed system roll out.
9. 在错误的时间推出
一个项目“上线”的适当时机是一个重要的成功因素，往往是由错过里程碑日期的挑战。业务赞助商希望在高峰时间之前实施解决方案，以提供最大的好处。然而，飞行员和测试是不能牺牲的。在推出的时机上压你的运气可能是灾难性的。
一家小型专业零售商在仓库系统实施方面落后于时间表。该项目原计划的完工日期是圣诞节高峰期前一个月，在圣诞节期间，该设施将完成全年产量的1/3。范围扩大使项目增加了2个月，但新的日期是不可接受的。限制软件测试减少了1个月的这一过剩。因此，该团队比计划落后了1个月，但可以在圣诞节高峰期前几天实施。
这个新软件对业务非常重要，以至于他们决定在最大流量到来之前的周末“上线”。由于测试不佳，该系统无法处理仓库的数量，从而降低了生产力并延迟了向商店的发货。一个项目事后审查估计，由于系统推出时机不佳，导致销售损失1300万美元。

Roadblocks
• Missed milestones and a “Go Live” date that cannot move will sacrifice other key project needs (i.e. testing, pilot, etc.).
• Peak volume season sounds good to the business but adds unnecessary stress and risk.
• Conflicts with other projects and initiatives targeted for the same period of time.
Action To Take
• Once a “Go Live” date is available, evaluate the business cycle, other project dependencies, alternative dates, etc.
• Understand why the business needs a solution by a certain date.
• Allocate enough time between “Go Live” and Peak Season to work out any last minute kinks.
路障
·错过的里程碑和无法移动的“上线”日期将牺牲其他关键项目需求（即测试、试点等）。
·旺季听起来对企业有利，但却增加了不必要的压力和风险。
·与针对同一时间段的其他项目和计划的冲突。
要执行的操作
·一旦“上线”日期可用，评估业务周期、其他项目依赖关系、备选日期等。
·了解为什么企业需要在某个日期前提供解决方案。
·在“上线”和旺季之间分配足够的时间来解决任何最后一分钟的问题。

10. Limited Training

Training is the first thing cut from a project when funding is low or over budget. You get the product released and the sponsors will not spend additional money on training. Without proper training, the new system will not provide the expected return on investment. Additionally, poor or no training will lead to low customer acceptance resulting in a failed project. To receive value, the customer must know how to use the new product.
10. 有限培训
当资金不足或超出预算时，培训是从项目中削减的第一项内容。你得到的产品发布和赞助商不会花额外的钱在培训上。如果没有适当的培训，新系统将无法提供预期的投资回报。此外，培训不足或没有培训将导致客户接受度低，从而导致项目失败。为了获得价值，客户必须知道如何使用新产品。

Roadblocks
• Low customer acceptance.
• Increased costs during deployment and support.
• Low morale and decreased productivity.
• Lost revenue.
Action To Take
• Prepare a low cost training alternative.
• Involve customers more during the product testing.
• Eliminate features before cutting back on training.
• Delay the project if possible.
路障
·客户接受度低。
·部署和支持过程中的成本增加。
·士气低落，工作效率下降。
·损失的收入。
要执行的操作
·准备一个低成本的培训替代方案。
·在产品测试过程中，让客户参与进来。
·在减少培训之前消除特征。
·如果可能的话，推迟项目。

11. Underestimating Change To The Business

Change management involves the business process changes necessary to succeed. When implementing software, failure occurs most of the time when the project sponsors do not understand that they must change the business to work with the software or change the software to work like the business.
Managing change is more difficult in organizations with high turnover, lack of education, or high stress environments. To successfully manage change, a project should have 25 to 35% of the budget allocated to change management. This allocation will lower the project risk and provide a cushion toward project success.
Take, for example, the shoe company that implemented a warehouse management system to increase inventory accuracy and throughput. The project was, from the beginning, focused on software features and functions. Little attention was given to current and future operating practices on the warehouse floor, how they could improve and must change. In the end, the implementation resulted in a 1.2 million square foot facility that was very adept at quickly losing product. If process improvements are identified early, as part of the business case effort, they are much more likely to be carried through to implementation.
11. 低估业务变化
变更管理涉及成功所必需的业务流程变更。实现软件时，失败发生的大部分时间，当项目发起人不明白，他们必须改变业务与软件一起工作，或改变软件，以像业务一样工作。
在人员流动率高、缺乏教育或压力大的环境中，管理变革更加困难。为了成功地管理变更，一个项目应该有25%到35%的预算分配给变更管理。这种分配将降低项目风险，并为项目的成功提供缓冲。
例如，一家鞋业公司实施了仓库管理系统，以提高库存准确性和吞吐量。该项目从一开始就专注于软件特性和功能。很少有人关注仓库车间当前和未来的操作实践，以及如何改进和必须改变这些操作实践。最后，实施导致了一个120万平方英尺的设施，这是非常善于迅速损失的产品。如果在早期识别过程改进，作为业务案例工作的一部分，它们更有可能被贯彻到实现中。

Roadblocks
• Project and business processes are not aligned.
• Business process changes are not considered until the end of the project.
• Drastic process or project changes required at the last minute causing overages and delays.
• Results in reduced or negative ROI.
Action To Take
• Understand the business process impact of the solution at the beginning of the project.
• Allocate a 25 to 35% change management budget (time and cost).
• Set up a Change Management committee with the business.
路障
·项目和业务流程不一致。
·直到项目结束时才考虑业务流程的变更。
·在最后一分钟需要剧烈的流程或项目变更，导致超支和延迟。
·导致投资回报率降低或为负。
要执行的操作
·在项目开始时就了解解决方案对业务流程的影响。
·分配25%到35%的变更管理预算（时间和成本）。
·与企业建立一个变革管理委员会。

12. Avoiding Risk Analysis

No one likes discussing project risks. It is human nature to think positive, that nothing will go wrong. Sometimes success or failure is determined by how well prepared a project team is when disaster occurs. If they project team or organization is not prepared, the project may stop unexpectedly until a new plan can be executed.
During a project milestone review session at one financial services company, the project manager was asked “risk type” questions like, “What are the chances that vacations will slow down the project?” and “What affects will a union strike have on the project?”. The project manager answered with one statement, “We don’t worry about those things, we are her to code, test and install this application”. As you guessed, no one analyzed the risks so no mitigation plan was in place. In the end, consultants were hired to make up for low staff counts, the project was over budget by 43% and implemented 4 months late.
An insurance company that ran a skeleton staff always ran projects by the seat of their pants. Plan were sketched out on scrap pieces of paper and planning for the unexpected was considered a waste of time. During a hardware and software upgrade that was to be implemented before year end processing, there was no contingency plan if the hardware was late. Due to production problems, the new hardware was delayed for 2 months. Two weeks before the “Go Live”, they were scrambling around looking to rent hardware. Unfortunately, the project was not implemented before year end.
12. 避免风险分析
没有人喜欢讨论项目风险。积极思考是人的天性，认为一切都不会出错。有时成功或失败取决于当灾难发生时，项目团队的准备是否充分。如果他们的项目团队或组织是没有准备好，该项目可能会停止意外，直到一个新的计划可以执行。
在一家金融服务公司的项目里程碑评审会议上，项目经理被问到“风险类型”的问题，如“度假会拖慢项目进度的可能性有多大？”和“工会罢工会对项目产生什么影响？”。项目经理只回答了一句话，“我们不担心这些事情，我们是她的编码，测试和安装这个应用程序。”正如您所猜测的，没有人分析风险，因此没有适当的缓解计划。最后，聘请了顾问来弥补员工人数不足的问题，项目超出预算43%，并且推迟了4个月实施。
有一家保险公司，只有一批骨干员工，他们总是凭直觉来经营项目。计划都是在纸片上勾画出来的，为意料之外的事情做计划被认为是浪费时间。在年底前进行的硬件和软件升级期间，如果硬件延迟，则没有应急计划。由于生产问题，新硬件推迟了2个月。在“上线”的两周前，他们四处奔波，寻找租赁硬件的机会。遗憾的是，该项目在年底前未能实施。

Roadblocks
•    Nobody likes discussing “risks”.
•    Project teams are not prepared for disaster.
•    Unrealistic view of the project status.
•    A .01% risk probability can stop a $100 million project dead.
•    Unexpected project delays and cost overruns.
Action To Take
•    Day 1, start a risk management log.
•    Identify risks throughout the project.
•    Continually revise risk mitigation and contingency plans.
路障
·没有人喜欢讨论“风险”。
·项目团队没有做好灾难的准备。
·对项目状态的不切实际的看法。
0.01%的风险概率可以阻止一个1亿美元的项目死亡。
·意外的项目延期和成本超支。
要执行的操作
·第一天，开始写风险管理日志。
·在整个项目过程中识别风险。
·不断修订风险缓解和应急计划。