IT项目风险管理案例和应对之道
IT项目管理经典案例
IT项目管理经典案例1、拯救项目团队徐家龙最近被公司任命为项目经理，负责一个重要但不紧急的项目实施。
公司项目管理部为其配备了七位项目成员，这些项目成员来自不同部门，大家都不太熟悉。
徐家龙召集大家开启动会议时，说了很多谦虚的话，也请大家一起为做好项目出主意。
一起来承担责任，会议开得比较沉闷。
项目开始以后，项目成员一有问题就去找项目经理，请徐经理给出意见，徐经理为了树立自己的权威、表现自己的能力，总是身体力行；其实，有些问题项目成员之间就可以互相帮助，但是他们怕自己的弱点被别人发现，作为以后攻击的借口，所以他们一有问题就找项目经理，其实徐经理的做法也不全对，成员发现了也不吭声，因为他们认为我是按你说得作的，有问题你经理负责。
团队成员之间一团和气，“找徐经理去！我们听你的；成为了该项目团队的口头禅，但是随着时间的推移，这个貌似祥和团结的团队，在进度上很快就出了问题。
该项目由重要但不紧急的项目变成了重要还紧急的项目！项目管理部意识到问题的严重性，派高级项目经理张一峰指导该项目的实施。
1.1问题问题出在哪儿? 张一峰怎么做?2、C公司的变更管理C公司是一家主要为交通部门从事系统集成业务的公司。
2007年3月底该公司承接了L市数字指挥系统的建设工作，公司任命王莽为项目经理。
合同金额300万交付日期为7月1日。
王莽组建完团队后，召开了内部的项目启动会议，宣布4月1日正式开工；大家干劲很高；王莽带领项目团队绘制了项目的生命期模板，分解得到了项目的WBS，在此基础上得到了项目计划，然后团队严格按照项目计划执行。
a很遗憾的是：很快项目团队就发现所需的采购设备的项目资金，被公司挪作它用不能及时供给资金。
另外这时交付给客户X模块，虽然用户签收了，但是客户认为项目团队没有领会好他们最急需的需求，希望他们在4月底前尽快完成Y模块的工作。
而项目团队的计划是在5月底完成Y模块，王莽认为这是客户的变更，需要填写客户变更申请书，客户不承认这是变更，于是引起争执也未填写变更申请书。
IT项目的风险来源和应对措施的报告
IT项目的风险来源和应对措施报告存在的问题：世界著名咨询公司斯坦地什集团曾经公布过一项研究报告：所有IT项目的平均成功率只有16.2%。
他们把成功定义为在计划的时间和预算内实现项目目标，研究还发现，有大约31%的IT项目在完工之前就被取消了。
主要原因：为什么有些IT项目成功率如此之低？许多项目往往以激情洋溢开始，却以一声叹息结束。
造成这一现象的一个主要原因是：近50% 的项目都没有指定专人来充分管理项目的风险和运营。
Claus Herbolzheimer 谈道：“在评估危机项目的损害时，多数只考虑直接成本，然而间接成本通常更高。
”这对形象的损害是不言而喻的。
因此，优秀的项目经理会始终如一地将企业传播融入到项目活动中。
例如，在准备阶段便开始针对可能出现的紧急情况拟定语言规范和沟通办法。
虽然这听起来很简单，但实施起来却并非如此。
原因分析：风险就是活动或事件消极的、人们没有预想到的后果发生的潜在可能性。
在特定的客观情况下载特定的期间里，某一时间预期与实际结果的变动程度。
变动程度越大，风险越大；反之，风险越小。
虽说风险事件不一定造成负面影响，但是风险管理在项目管理中确实非常重要。
当风险事件只能造成损失和损害时，应设法消除转化条件和触发条件；当分先事件可以带来机会时，则应努力创造转化条件和触发条件，促使其实现。
风险因数是风险事件发生的潜在原因，有造成损失或损害的内在或外在原因。
如果消除了所有的风险因数则损失或损害就不会发生。
事实上，由于风险的复杂性，风险分类的依据或风发有很多。
按本质来分，分先可分为经营风险和纯风险：■经营风险是指与项目经营活动密切相关的风险，比如市场风险。
但是经营风险如果处理得好的话能够带来利益。
■纯风险是指与项目经营活动无关的偶然事件而引起的风险。
这类风险一旦发生只会造成损失。
按系统开发进程，分先可分为：■分析阶段风险■设计阶段风险■开发阶段风险■实施阶段风险■系统转化阶段风险按风险的产生可分为■项目风险（工期、费用）■技术风险（技术的不确定性、设计、实施、接口、验证风险）■业务风险（市场、战略、管理、预算和销售）问题来源：以下是IT项目风险的具体来源：1、需求风险⑴无足够用户参与系统人员在实践过程中也有些感觉，在实施一个项目时，若无足够的用户参与，系统人员获得的需求是片面且不完整的，这样系统在需求之初就埋下风险。
IT项目管理中的典型问题和解决方案
IT项目管理中的典型问题和解决方案IT项目管理是一个复杂的过程，涉及到许多方面，包括需求分析、设计、测试、上线等。
在这个过程中，IT项目管理者会面临许多技术和管理方面的挑战。
本文将介绍IT项目管理中的典型问题以及解决方案。
一、需求不清晰在IT项目管理中，需求是至关重要的因素。
如果需求不清晰，项目将很难顺利进行。
需求不清晰可能会导致开发团队误解客户的期望，从而产生巨大的成本和时间开销。
解决这个问题的方法是，IT项目管理者应该加强与客户的沟通，并确保所有需求都有明确的文档支持。
此外，IT项目管理者还可以使用原型来展示项目的概念和功能，以确保开发团队和客户在需求方面的理解保持一致。
二、技术困难IT项目管理中的另一个典型问题是技术性的挑战。
由于技术的不断更新和发展，开发团队可能会面临新技术的学习和实施的挑战。
解决这个问题的方法是，IT项目管理者应该在项目初期确定所有技术实现的细节，并分配适当的资源给开发团队。
此外，在开发过程中，IT项目管理者应该确保开发团队有充足的时间来学习和实践新的技术，并且他们应该享有技术支持的资源。
三、预算和时间管理IT项目管理中的第三个典型问题是预算和时间管理。
预算和时间约束通常是IT项目管理中的主要挑战之一。
如果管理不当，它们可能会导致项目推迟，超支或质量不佳。
解决这个问题的方法是，IT项目管理者应该在项目的早期确定预算和时间限制，并在整个项目过程中对它们进行监控和管理。
此外，IT项目管理者还应该与开发团队合作，以确定项目的优先级，确保开发重点放在最重要的功能上。
四、沟通不畅IT项目管理中的第四个典型问题是沟通不畅。
在一个复杂的IT 项目中，存在着许多不同的利益相关者，包括客户、开发人员、测试人员、管理人员、项目管理员等等。
如果沟通不够畅通，这些人员可能会目标不明确，导致项目进展缓慢。
解决这个问题的方法是，IT项目管理者应该在项目初期制定沟通计划，并协调各方面的沟通工作。
此外，他们还可以使用现代技术工具来增强沟通，如在线会议、虚拟白板等等。
IT项目风险评估分析及管控
IT项目风险评估分析及管控XXX项目风险评估分析与应对措施XXX项目建设涉及项目实施规划与设计、数据采集、UI 设计、软件开发与实施、硬件采购与安装、网络与数据中心工程、基建工程、弱电工程、工程施工、商务谈判与合同、资金管理、公共关系维护、供应商管理、项目管理等众多方面的专业性建设与综合性统筹管理。
项目建设存在整体跨度大、专业性强、复杂度高低不同、工作量大等特征。
一、缺乏共识的风险1、与业主方的共识风险。
业主方对项目建设的难度、时间需求、具体解决方案等没有清晰认识，同时片面追求政绩、成果展示等项目驱动，从而对项目提出不现实或多变的要求。
2、项目组内部（包括企业方与供应商方）、企业内部的共识风险。
内部人员对项目定位、具体解决方案有多种理解与认识，而产生对项目建设走向、时间进度、成本等各方面造成至关重要影响。
从建设的角度可以这么概括，在一个解决方案上达成共识比这个解决方案本身的先进性重要得多，但往往形成不了共识。
3、各方的项目驱动力的不同且存在变化，造成共识风险加大。
业主方注重政绩、特定的项目诉求及其它利益点；企业方注重项目正常完结、各方公共关系维护及项目款项收取；供应商注重既定需求的项目快速交赋予项目款项收取，但各方项目驱动力是变化的。
应对：与各方就大的共识点告竣意向，同时注意项目驱动力的不同并对各方不同策略响应；无法告竣共识时，由决策人作决策。
二、组织和办理风险1、项目组织架构是否存在？成员分工是否清晰明确？决策人是否明确？沟通机制？会议制度？2、仅由项目经理制下的相关人员进行的项目决策，会导致权限不够、计划进度迟钝、计划时间耽误；3、公司高层在参与度不够的情况下，审查决策的周期比预期的时间长；4、各种因素影响下的预算削减，将打乱项目计划；5、公司高层作出了打击项目组织积极性的决定；6、项目缺乏必要的规范，导致工作失误与重复工作；7、非手艺的第三方的工作（预算核准、设备采购核准、法令方面的审查、安全保证等）时间比预期的耽误。
风险管理在IT项目中的应用案例分析
风险管理在IT项目中的应用案例分析引言近年来，IT项目在企业中的重要性日益凸显。
IT项目的成功与否关系到企业的发展和竞争力。
然而，IT项目的实施过程中存在着各种潜在的风险。
本文将通过一些实际案例，分析风险管理在IT项目中的应用。
案例一：项目资源不足在某企业的信息系统升级项目过程中，项目团队和技术人员数量不足，无法满足项目需求。
这导致了项目延期和技术质量下降的风险。
针对这种情况，项目团队应该提前进行资源评估，并制定相应的计划。
他们可以与其他部门合作，调动更多的技术人员参与项目。
同时，利用风险管理工具，对项目进度进行监控和跟踪，及时发现问题并采取措施。
案例二：需求变更在另一个企业的软件开发项目中，由于项目启动时需求细化不够充分，导致项目进展过程中需求频繁变更，增加了项目风险。
为了应对这个问题，项目管理团队应该在项目启动前进行充分的需求收集和分析。
他们可以与业务部门积极沟通，确保明确的需求和期望。
同时，项目管理团队还可以采用敏捷开发等方法，适应需求的不断变化。
案例三：技术风险在某公司的大型软件开发项目中，由于新技术的应用和复杂性，项目团队面临着技术风险。
不少技术问题无法及时解决，导致项目进展受阻。
为了应对技术风险，项目团队应该在项目启动前进行技术评估，并制定解决方案。
他们可以组织培训，提升团队成员的技术水平；同时，可以与外部专家合作，寻求技术上的支持和帮助。
案例四：项目沟通不畅在某企业的ERP系统实施项目中，项目团队与业务部门之间缺乏有效的沟通，导致了需求理解不准确和问题解决困难的风险。
为了解决沟通问题，项目管理团队应该加强各方之间的沟通与合作。
他们可以定期组织会议，让项目团队和业务部门一起参与需求讨论和决策。
同时，可以采用一些协同工具和软件，促进信息的共享和交流。
结论风险管理是IT项目成功的关键之一。
通过案例分析可见，在IT项目中，各种类型的风险时刻存在，包括资源不足、需求变更、技术风险和沟通问题等等。
IT项目风险管理如何识别和应对IT项目中的风险和挑战
IT项目风险管理如何识别和应对IT项目中的风险和挑战IT项目的成功与否，往往与风险管理的能力密切相关。
在IT行业中，项目风险和挑战是不可避免的，但通过适当的识别和应对措施，可以降低风险并提高项目的成功率。
本文将探讨如何识别和应对IT项目中的风险和挑战。
一、识别风险在IT项目中，识别风险是项目管理的首要任务。
以下是一些常见的风险因素：1. 技术风险：包括技术难题、系统故障、数据安全等问题。
2. 范围风险：由于需求不明确或变动频繁，项目范围可能不断扩大，导致成本和进度风险。
3. 人员风险：包括不合适的人员配置、团队合作问题、人员离职等。
4. 供应商风险：来自供应商的延迟交付、产品质量问题等不可控因素。
5. 组织风险：包括组织文化、决策机制等问题，可能对项目产生负面影响。
为了有效识别风险，项目管理团队可以采取以下方法：1. 项目风险登记：建立风险登记表，记录可能出现的风险，并评估其概率和影响程度。
2. 专家咨询：请相关专家参与项目评估，从他们的经验中发现潜在的风险。
3. 风险讨论会：邀请项目团队成员共同参与，通过头脑风暴和讨论，识别可能的风险。
二、应对风险识别风险后，项目管理团队需要采取相应的措施来应对风险。
以下是一些常见的应对策略：1. 风险规避：通过采取预防措施，降低风险发生的概率。
例如，对于技术风险，可以提前进行技术评估和验证，选择可靠的技术方案。
2. 风险转移：将风险责任转移给第三方，通过签订合同或购买保险等方式来减轻项目团队的压力。
例如，通过外包来减少人员风险。
3. 风险降低：通过采取措施来降低风险的影响程度。
例如，建立备份系统来应对数据丢失风险。
4. 风险接受：对于一些无法避免或转移的风险，项目管理团队需要接受并制定相应的应急措施。
例如，制定漏洞修复计划来应对安全风险。
三、挑战与解决方案除了风险管理，IT项目中还存在一些挑战，需要项目管理团队积极应对。
以下是一些常见挑战及其解决方案：1. 沟通与合作：在IT项目中，不同部门和团队之间的合作和沟通十分重要。
软件项目风险管理案例
软件项目风险管理案例一、项目背景某大型企业决定开发一款新的客户关系管理系统（CRM），以提高客户满意度和提升企业业绩。
该项目涉及多个部门和大量数据，预算为XXX万元，计划用时12个月。
二、风险识别在项目启动阶段，项目团队识别出以下风险：1. 技术风险：由于项目涉及多个部门和多种数据，技术实现难度较大，可能存在技术难题和技术瓶颈。
2. 人员风险：项目团队成员可能存在技能不足或经验不足的问题，导致项目进度和质量受到影响。
3. 预算风险：项目预算为XXX万元，可能存在超支的风险。
4. 时间风险：项目计划用时12个月，可能存在进度延误的风险。
5. 沟通风险：项目涉及多个部门和多种数据，沟通协调难度较大，可能存在信息传递不畅或沟通效率低下的风险。
三、风险应对措施针对以上风险，项目团队采取了以下应对措施：1. 技术风险：采用先进的技术方案和工具，加强技术培训和交流，提高技术水平和解决问题的能力。
2. 人员风险：加强人员选拔和培训，提高团队成员的技能和经验水平，确保项目进度和质量。
3. 预算风险：制定详细的预算计划，加强成本控制和管理，避免超支情况的发生。
4. 时间风险：制定详细的项目计划和进度安排，加强进度管理和监控，确保项目按时完成。
5. 沟通风险：建立有效的沟通机制和渠道，加强信息传递和协调合作，提高沟通效率和质量。
四、风险监控与评估在项目实施过程中，项目团队定期对项目进展情况进行评估和监控，及时发现和解决潜在的风险问题。
同时，根据项目实际情况调整风险管理策略和措施，确保项目的顺利进行。
最终，该项目在预算范围内按时完成，实现了预期的目标和成果。
五、总结与建议通过以上案例可以看出，软件项目风险管理对于项目的成功实施至关重要。
在项目实施过程中，需要加强风险识别、应对措施制定、风险监控与评估等方面的工作。
同时，建议企业在软件开发过程中建立完善的风险管理体系和流程，提高风险管理能力和水平。
IT项目管理中的风险识别与应对策略
IT项目管理中的风险识别与应对策略风险在IT项目管理中是一项常见但关键的挑战。
正确识别和应对风险可以帮助项目团队在项目执行过程中降低潜在风险对项目目标的影响。
本文将探讨IT项目管理中的风险识别与应对策略。
一、风险识别在IT项目管理中，风险识别是项目团队的首要任务。
通过识别潜在的风险事件和状况，项目团队可以提前预测风险可能对项目造成的影响，制定相应的预防和应对措施。
以下是一些常见的风险识别方法：1. 专家访谈：项目团队可以与相关领域的专家沟通，收集专家意见和建议，从而识别出潜在的风险。
2. SWOT分析：通过分析项目的优势、劣势、机会和威胁，识别项目所面临的风险。
3. 需求分析：对项目需求进行仔细的分析和评估，从中发现可能的风险点。
4. 历史数据分析：通过研究类似项目的历史数据，了解以往项目所遇到的风险，从而在当前项目中加以预防。
二、风险评估与优先级排序识别风险后，项目团队需要对风险进行评估和排序，以确定哪些风险对项目的影响最大，优先处理。
以下是一些常用的风险评估方法：1. 可能性与影响矩阵：将风险的可能性和影响程度作为矩阵的坐标轴，对各个风险进行定量评估，以确定其优先级。
2. 专家评估法：请相关专业人士对各个风险进行评估，结合其专业知识和经验，综合确定风险优先级。
3. 利益相关方参与评估：邀请项目中的利益相关方参与风险评估，包括客户、团队成员和相关部门。
通过多方参与的方式，提高风险评估的准确性和全面性。
三、风险应对策略设计有效的风险应对策略是IT项目管理中的重要任务。
以下是一些常见的风险应对策略：1. 风险规避：通过合理的项目计划和资源管理，尽量避免风险事件的发生。
2. 风险转移：将风险转嫁给外部机构或第三方，通过购买保险或签订合同来降低风险对项目的影响。
3. 风险减轻：采取一系列的措施来减轻风险对项目的影响，如加强项目监控，提高沟通效率，增加资源投入等。
4. 风险接受：对于一些无法避免或减轻的风险，项目团队需要接受并制定应对措施，以最小化其对项目目标的影响。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
IT项目风险管理案例和应对之道
IT项目管理从某个意义上来说，就是风险管理。
从理论上讲风险管理可以分为三个部分：风险识别、风险分析和风险解决。
传统的风险管理系统只能帮我们较正规地统计和管理风险，这些系统本身是不能规避或解决任何风险的。
在实际操作上，由于可能发生风险的种类很多，处理起来所耗费的人力物力也相当可观。
在下列的案例中，我们建议的不是一套昂贵而且全面的风险管理系统，而是一套扼住最关键部位，高效且低成本，适合于千万中小企业的小型解决方案。
一个案例
在2009年某家在北京海淀区的嵌入式产品公司跟我们讨论项目管理时，该公司的王总监跟我们做了以下沟通。
他们项目风险种类可以概略分为四类：
（1）需求风险——对需求理解不够透彻或需求变更频繁；
（2）人员风险——人员生病或离职，一时无法找到替代者；
（3）技术风险——某个关键的技术问题无法快速攻克；
（4）管理风险——管理人员协调能力和执行力能力不足，计划偏差，流程更改和沟通不良等。
这些风险的发生导致的结果就是项目延期和成本大幅攀升。
无法有效处理这些风险的两个最大问题在于：
（1）对风险的反应迟钝——常常是太晚发现问题，以至于无法弥补或是弥补成本太大；
（2）对过程难以掌控——虽已有既定的流程，但由于人员变动、流程变动、系统出错等问题，很难照着走。
为了让我们更理解，王总监很生动的解释了以上两个问题。
对风险反应迟钝的问题，他说，在做项目计划时为求实际，总会多估个20%到40%的时间。
如果项目需求清晰，或是团队做过类似项目，就用20%或多些；如果是新项目，或风险因素多便用30%到40%。
所以，当某些风险（如，需求变更或人员变动）发生了，一般也未必马上就造成项目延期。
可是，如果风险发生量继续增加，或是某一两个风险产生较严重的冲击，在某个时刻就会过了临界点。
难的地方就是项目大人员多，就是连项目经理也是见树不见林。
对过程难以掌控的问题，王总监举了个例子。
公司的研发制度里规定，为保证需求的准确性，一个需求的变更要经过（1）该项目经理，（2）一位资深程序员，和（3）该产品经理，等三个关键人审核后才可以进行更改。
王总监说：需求变更的过程在逻辑上看似简单，但在实际操作时却不断地发生问题。
举例来说，内部沟通主要是以邮件通知的方式进行，需求变更的文档寄来寄去，版本很多，而且邮件总是遗失。
另有一次更严重，产品经理因为休假，没能及时查邮件。
在等了两天后，因怕误了工期，项目经理便越权要求程序员把代码写了。
不巧，产品经理对这需求的更改有他强烈的意见。
当他看到在没得到他的同意下就把代码写了，火冒三丈，直接在会议中就和项目经理吵了起来。
两个控制风险的原则
虽然风险总是发生，但就如同大多数的公司一样，该公司也不愿意花费太多的精力和时间在这风险管控上，所以在寻求一个低成本又高效的管控方法。
王总监和我们在研讨后，使用工具DevSuite基于下列两个原则做了处理。
（为避免篇幅太大，以下我们仅把最精彩的点列出来。
）
（1）提高项目的可视性
不论是哪一种风险，其最后冲击的基本上就是项目本身，延期是最常见的结果。
如果是对可能发生的风险都一一进行管控，成本必然很高，而且还可能有疏漏。
使用燃尽图（Burn Down Chart）可能是针对项目延期最有效的解决办法，因为它很大程度地提高了项目的可视性。
在实际操作时，我们让团队成员每天对其参与的每一任务都键入下列两项数字：1）该任务花费时间，和2）该任务所剩时间。
结果就会生了类似如下的燃尽图。
如图所示，起初这项目被估计是要3480小时完成。
大致上来说，一般的研发团队因着人员请假、会议和其他突发事情，平均每人每天只能有六小时花在实际项目工作上。
现这项目有七个人参与，估算出来大约需要四个月完成。
（也就是从2009年11月29日到2010年3月29日，图中红色直立线为起始线，蓝色直立线为终止线。
）这图里共有三条曲线。
红色号码?/span>表示到现在为止在该项目的总花费时间，红色号码?表示估算的项目剩余时间，红色号码?是到目前为止所花的时间与剩余时间之和的曲线。
到了2010年3月21日就得到了上面的这个图。
到了这一天，我们发现原本估计的3480总小时数是低估了，更可能的是?所示的3740小时。
以纵轴的性质区分，燃尽图可以分为两大类，即纵轴可以是时间或是事件。
以范围区分，燃尽图至少可以分为三类：项目级的、任务级的和需求级的。
透过燃尽图，我们可以看到项目进行的情况，项目需求是否按计划进入开发流程，工作是否有延时，或者工作安排的饱和度是否适合。
如上图所示，我们可以轻易地看到，照着现在的进度，这项目最可能会延期6到7工作天。
当高层看到这图时，就可以在资源上做调动，以避免延期产生的不良后果。
我们刻意使用了这个较理想的图做讲解，为的是让读者更容易理解。
它不是个典型的图。
在大多情况，使用燃尽图会是比较复杂的，因为它可能包含了需求搜集、编程、单元测试、集成测试和缺陷修复，并且还可能有迭代。
所以估算时间会较困难。
这个燃尽图的过程是比较稳定的，结果是比较理想的，其原因至少有
二：（一）项目里单纯地只有编程、单元测试和缺陷修复任务，全都由程序员搞定；它里头没有需求搜集、集成测试或其他任务。
（二）这个项目复杂度低，约一半的编码任务是机械性的，所以估出来的时间较为准确。
（2）固化工作流以管控过程
对于公司里既定的流程，我们在DevSuite里以图形化的工作流将其固化。
下图就是以前面王总监提到的需求变更流程设计出来的。
这工作流指明了，在一个变更事件被创建后，它需要经过一个《评审》状态。
在评审阶段里，有三个人（A，B和C）要全部同意，才能到达《通过》状态。
有任何一人不同意，状态就转到《拒绝》。
当一到达《评审》状态，系统马上促发邮件和手机通知，将信息寄给A，B和C。
系统可以预先设定这三人有两天的时间评审该变更。
假如两天过了，状态仍为《评审》，那就是有人未及时处理该事件。
这时候，系统会自动将事件升级，把状态转换为《升级处理》，系统马上促发邮件，将信息寄给研发部王总监。
王总监可以斟酌情况，做最妥善的处理。
使用固化的工作流至少有四个优点：1）提高通知效率?邮件和手机自动通知提高效率，沟通出错的机会减少了；2）避免流程出错?DevSuite的工作流将流程完全自动化，每个人在收到邮件或短信通知时，照着工作流中既定的步骤操作就行了，省心又省力；3）工作流变动时处理很容易?当流程或人员变动时，系统配置员可以轻易地花几分钟就做完调整，之后所有团队成员就照着流程走便行了；4）避免摩擦?人是有情绪的，固化的工作流使得操作完全对事不对人，避免了人和人之间不必要的摩擦。
以上提到的软件项目风险实例几乎在每个项目中都出现，而且，它们造成的损失也是严重的。
所幸，从实际操作中，我们发现处理它们的成本并不高：1）培训团队成员照工作流中既定的步骤操作，学会填写任务花费时间和任务所剩时间，并理解意图，所花时间不超过1小时，2）系统配置员要了解需求，设计工作流，并设置人员（如例子中的A、B、C和走流程的人）的权限等，所花费时间在1到3天之间，也算合理，3）以往当团队人员或评审流程有变动，管理人员要更改文档并向所有人宣布；现系统配置员只要花几分钟改系统
配置，一切就就绪了。
小结
这并不是一个全方位的风险管控系统；相反的，它是个相当简化，只对关键点作处理的系统。
虽然只是做在关键点上，但效果却十分明显。
就拿需求变更来说，需求变更一直都是项目中让人恨得牙痒痒的瘤。
既然需求变更是不可避免，那我们所能做的就是，尽可能减少变更的次数，降低变更造成的冲击。
以往大多数人审核需求变更时较为草率，导致同一个功能点变了又变。
在一轮又一轮的返工后，程序员和测试人员会产生倦怠感，编码和测试的质量一再下降。
使用了DevSuite后，所有的操作都在系统里留下记录，这统计在年终时可以作为考评的参考材料。
自然而然地，审核人员就很严谨地审核每一个需求变更。
而且，因为系统设置了每人只有两天的时间处理，审核人员处理需求变更时不仅是快，而且较仔细。
单单就这个变化，就使得整个团队的气象焕然一新。
在系统实施后半年，我们做了客户回访，我劈头就问王总监，说的那位产品经理还跟项目经理还吵架吗？瞪了我一眼，停了一下，然后皱了皱眉头说：倒是不吵架了。
他们俩现在成了好朋友，联合起来一起对付我了。
他自己呵呵呵地笑了起来。