预防拯救和管理项目的20个技巧

Tip #1:Trouble may be defined as deviation from expectations. Don’t forget to carefully define and dimension what will constitute success!
技巧1: 问题可以定义为达不到期望的要求. 因此不要忘记仔细地定义和识别那些通向项目成功的因素!

Organizations do not authorize projects "just for fun"!!! Projects cost real money and consume real resources, so before going too far make sure the project team and the customer concur on how success is defined and will be measured.
组织不会批准一个”项目游戏”, 项目需要真正地花费金钱和其他资源, 因此在项目开始时,应该确保客户和项目团队对项目的成功标准的定义及测量方法达成共识.

 

Tip #2:A project life cycle is an essential communication tool. It is especially important with potentially troubled projects, indicating defined expectations and deviations at each step in the project.

技巧2: 一个项目的生命周期是一个项目的基本沟通工具. 这对于有潜在问题的项目由为重要, 他揭示了在每个项目阶段对期望的定义及实际背离.

A project life cycle has many uses. A key objective is to define the deliverables to be generated in each phase... and how each is to be reviewed, verified, validated; leading to approval to continue the next phase.

项目的生命周期具有很多用途, 一个关键的目标就是定义项目在每个阶段应该产生的交付物…..以及怎样对这些交付物进行评审, 验证,确认和批准进入下一阶段.

 

Tip #3:Often troubled projects come from troubled teams. Don’t forget the Team Charter... and keep it up-to-date!

技巧3:问题项目往往来自问题团队, 不要忘记项目团队章程,要及时更新项目团队章程!
A team charter is a code of conduct developed by the project management team and later adopted or modified by the project team. It defines the mutual expectations of each team member of one another. Project managers must hold themselves and others accountable consistent with this code.

项目团队章程是项目团队制定,更新和采用的项目团队行为规范, 他定义了项目团队中每个成员共同的和相互间的期望, 项目经理和其他项目成员必须持续地遵守该章程.

 

Tip #4:Don’t forget projects are subject to many requirements; users perceive "trouble" only associated with the "functional" ones!
技巧4:不要忘记项目的起决定于一系列的要求的达成; 用户所感知的”问题” 往往是”功能上”的问题!

Functional requirements clearly define what the user will be able to do or do better or more efficiently as a result of the project.
功能上的要求清楚地定义了什么是用户希望从项目中得到的更好的和更加有效的结果.

T

ip #5:Functional requirements may be all the user "cares about", nonetheless, inability to deliver the non-functional ones can cause substantial trouble.

技巧5: 功能上的要求可能是所有用户都关心的, 虽然如此, 但是对应非功能性要求的忽视往往也会使项目陷入困境.
Non-functional requirements include the constraints under which the project must be delivered and the resulting product must perform. Qualities represent those attributes the stakeholders expect but do not necessary give "voice" to, e.g. comfort, beauty, pride ...

非功能性要求包括一些限制性要求,项目必须在这些限制下完成交付和达到希望的结果. 质量概括了这些项目干系人所期望的但隐含的特性,如舒适,漂亮, 精致……

 

Tip #6:The "voice of the customer" establishes what users expect, so don’t forget to ask "what do they want to be able to do?"

技巧6: “客户的心声” 确定了用户的期望, 因此不要忘记询问”客户想要和能为项目做些什么”

Non-functional requirements include the constraints under which the project must be delivered and the resulting product must perform. Qualities represent those attributes the stakeholders expect but do not necessary give "voice" to, e.g. comfort, beauty, pride...

非功能性要求包括一些限制性要求,项目必须在这些限制下完成交付和达到希望的结果. 质量概括了这些项目干系人所期望的但隐含的特性,如舒适,漂亮, 精致……

 

Tip #7:Many teams waste substantial effort attempting to produce an exhaustive list of risk events for consideration, often trouble stems from the risk events that the team failed to identify so why not use a risk checklist?

技巧7: 许多项目团队浪费了大量的工作试图制作一份详细的风险事件清单,但是问题往往就产生于那些被遗漏了的风险事件. 为什么不采用风险检查表呢?

A number of years ago the Software Engineering Institute published a document entitled, ?Taxonomy Based Risk Identification?. The document is free and can be downloaded at SEI.CMU.EDU. Appendix B provides a list of approximately 200 questions that help identify and define key risk events ? many of which may be readily adapted to domains other than software development.

很多年前, 软件工程协会就发布了一份命名为风险识别分类的文件,该文件可以免费从SEI.CMU.EDU上下载. 附录B 提供了一大约200个问题的清单以帮助定义和识别风险事件. 其中很多可以容易地被应用到除了软件开发外的其他领域.

 

Tip #8:Trouble sometimes stems from omissions. It is easy to ?forget? key components of a work package. A checklist reduces the potential of leaving out important considerations.

技巧8: 问题有时来自疏忽. 一些工作包中的关键任务也容易被忽略, 采用检查清单能够减少这些潜在的疏忽.

allPM.com provides a WBS Dictionary Job Aid, download it now and modify I to meet your organization?s specific situation.allPM.com

提供一个工作分解结构(WBS)工作辅助辞典, 现在就下载并根据你的组织的实际情况来进行修改使用吧.

 

Tip #9:Many change control systems are difficult and time-consuming to use. Stakeholders often ?go around the system? causing substantive trouble. Why not make it easy t o accommodate desirable changes.

技巧9: 很多变更控制系统使用起来费时费力. 项目干系人常常在这些系统之间徘徊从而导致很多问题, 为什么不使它变得容易与我们所期望的变更相结合?

The objective of effective change control should be to expedite, enhance, and enable desirable change. Make change control request forms easy to complete and to evaluate. Include sections that address the requestor?s willingness to accept trade-offs as well as expected benefits and pay-off!

有效变更控制系统的目标应该是快速, 增值并能实现期望的变更. 制定一份容易完成和评估的变更控制要求表. 其中应包括从变更中变更要求者接受妥协的意愿和期望的受益!

 

Tip #10:Trouble often stems from a project life cycle with just a design phase. Make sure it contains a design and plan phase!

技巧10: 问题往往来自项目生命周期只有一个设计阶段, 确保项目的生命周期包括了一个设计和计划阶段!

Too often development teams address ?design and construction? phases with little or no emphasis on planning. The design phase must include planning for delivering the functional requirements within the expressed constraints of quality, time, budget, and risk.

非常常见的现象是开发团对在设计和建造阶段很少甚至没有重视计划, 设计阶段应该在期望的质量,时间,预算和风险等限制下对功能性的交付进行计划.

 

Tip #11:Cost effective testing is not something that is done once the software or the building or the new product, etc., has been produced. Trouble is often revealed in the Testing Phase, usually sequenced after construction. Move testing forward in the life cycle for more effective cost savings and customer satisfaction.

技巧11: 经济的测试对于已经完成测试的软件,建筑和新产品等项目不是什么问题, 问题往往在建造后的测试阶段被发现.将测试尽可能地移到项目生命周期的前段能有效地节约测试成本和使客户满意

Plan for testing, evaluation, and modification as part and parcel of the execution or construction phase of the project life cycle. It is far more costly to identify and remove defects from a nearly completed system than from and in-process component.

对测试,试验和变更进行计划是项目生命周期中执行或建造阶段的一部分.在系统即将完成阶段识别和消除缺陷比在过程中成本要高很多.

 

Tip #12:When dealing with team member motivation problems, i.e. "trouble", ask three questions.

技巧12: 当处理项目成员激励问题,也就是”麻烦”时, 问以下三个问题:
Vroom and Yetton in their work of 1974 identified three questions that individuals must be able to ask and answer in the affirmative if they are to be motivated: (1) Do I know what is expected of me? (2) Do I expect I can perform that which is expected of me? (3) Do I expect a reward of value to me personally?

Vroom 和 Yetton 在1974年明确了如果项目成员受到激励,他们能够自问并肯定地回答三个问题:(1) 我知道对我的期望是什么吗? (2) 我期望我能达到对我的期望吗? (3) 我期望对我的个人价值的肯定吗?

 

Tip #13:Many troubles are nothing more than risk events that have unexpectedly manifested themselves, monitor the triggers or symptoms to reduce the potential for surprise!

技巧13: 多数问题都出现在非预期的风险事件的发生, 监控风险的前兆或信号以减少潜在的意外.

Failure mode effects analysis (FMEA) requires assessment of risk detectability. The PM analogy of this is the "trigger". Make sure that those "owning" the risk work packages have identified triggers, where possible, for each risk and that these receive attention as part of each status, progress, and forecast report.

失效模式及影响分析(FMEA)要求对风险的可探测性进行评估. 项目管理称为”触发器”. 确保对那些有风险的工作包的风险触发器进行了识别, 每个风险事件可能发生的地点, 以即在不同情况,进展和预测方面得到足够的关注.

 

Tip #14:When requirements continue to change prior to "baselining", monitor the number of change requests per week to determine potential troubles.

技巧14: 当在确定项目基线之前要求不断改变时,每周监控变更的数量以确定潜在的问题

Requirements may converge or diverge during the planning phases of the project. Monitoring the number of change requests per week should indicate whether the rate of requests is growing or diminishing to some stable number. If certain of the requirements appear to remain stable while others are volatile, perhaps a phased delivery approach is advisable.

要求可能集中或者分散在项目的计划阶段, 每周监控变更的数量应该可以显示出变更率是增长还是在逐渐减小到一个稳定的数量上.如果某些要求稳定而另一些要求不稳定, 则预示着应该采取阶段性的交付方法.

 

Tip #15:When most of the lower weighted or prioritized requirements have been deferred in lieu of extending the schedule or increasing the budget, the project is troubled.

技巧15: 当大多数较低权重和优先级被推迟以替代项目延期或者项目预算增加时, 项目就陷入困境

If all of the deferrable requirements have been deferred and only "must" requirements remain while schedule, cost, and quality pressures build, the project may be said to be desperate. Stakeholders who have been kept well informed may not "like" these results but they definitely should be in a position to act responsively.

如果当项目日程,成本和质量压力来临时,所有可以推迟的要求被推迟并且只有那些必须的要求被保留,项目可能是令人绝望的. 那些对项目信息很了解的干系人可能不希望出现这样的结果,但是他们的确应该对这样的结果承担责任

 

Tip #16:When stakeholders do not respond to information or do not respond in an expected manner, alternative, proactive communication mechanisms may be necessary to avert trouble.

技巧16: 当项目干系人对项目信息没有回应或者不以希望的方式进行回应时, 应该建立积极的,选择性的沟通机制以转移这些问题

Most project managers have been exposed to Meyers Briggs Types. Recall that some (1) perceive by sensing or intuition and some (2) judge by thinking or feeling. Understanding your MBTI and the "type" of key stakeholders, i.e. key decision makers, may explain why some of the "messages" sent by the PM are not perceived and acted upon consistent with expectations.

多数项目经理成天和迈尔斯-布里格斯心理类型(MBTI)的人打交道, 回忆一下有些人(1) 靠感觉和直觉来感知,而有些人(2)靠想当然来感知. 了解你的那些MBTI们和你的那些”典型”的项目胳干系人,也就是那些决策者们,你就会明白为什么项目经理送出的信息不能被感知和按照项目经理的期望得到贯彻执行.

 

Tip #17:When a project is recognized as desperately troubled, first take action to contain the damage then worry about recovery!

技巧17: 当项目陷入困境时,首先要采取措施防止危害的蔓延,然后才来考虑补救措施.

Medics and rescue personnel confronted with truly desperate situations are trained first to "contain the damage" and once stabilized to then consider other options. This same approach must be applied to troubled projects having no remaining flexibility.

医生和拯救人员面临危难情景时进行的训练是首先”限制伤害扩散”,一旦情况得到稳定再考虑其它补救措施. 这种方法也应该毫无保留地被应用到出现问题的项目中.

 

Tip #18:When a project is identified as troubled, don’t wait for it to get better on its own, take action!

技巧18: 当项目确定陷入困境时,不要等待项目自己会好转, 立即采取行动!

There are three or four options for dealing with trouble - it depends

根据具体情况, 采取以下3到4种方法解决问题
1. Reduce the requirements so that execution can be completed within the approved constraints of time and resources
1. 减少要求以便在批准的时间及资源限制下完成项目

2. Increase process productivity by focusing on short-term improvements

2. 通过关注短期的改善措施的实施提高项目执行过程的生产效率

3. Face the fact that the requirements will not be delivered on time; slip the schedule, and proceed with damage control, possibly including canceling the project. or Pursue a combination of all three; drop a few features, increase productivity, and slip the schedule again it depends
3. 面对项目的要求不能按期交付的现实; 调整日程,实施损害控制措施,可能时包括终止项目,或者尝试以下三者措施相结合; 放弃一些项目要求,提高工作效率和根据具体情况再次调整项目日程.

 

Tip #19:When a project is identified as troubled, there are three areas of focus that can yield short term results: people, process, and product.
技巧19: 当确定项目陷入困境时, 可以关注以下三方面以获得短期的效果:人员,过程和产品.

The first focus should be on people
首先应该关注的是人的因素
●Do whatever is needed to restore the group?s morale
●尽可能采取一切措施回复项目团队士气
●Clean-up major personnel problems
●清除主要的人员问题
●Clean-up major leadership problems
●清除主要的领导问题
●Add people carefully, if at all
●增加确实要增加人员也要十分小心
●Focus people?s time
●关注人员的时间
●Allow team members to be different
●承认项目成员的差异
●See that key players pace themselves
●留心项目关键成员的表率作用

 

Tip #20: Delivering the product of the project is the beginning of the end. Mitigating trouble depends upon an effective transition.
技巧20: 项目产品的交付是项目结束的先兆. 减少问题取决于有效的项目交接

 

Successful project conclusion is marked by:
项目成功结束的标志是:
●Achieving user self-supportability
●使得用户能够进行自我维持项目
●Achieving stakeholder concurrence that deployment baselines are complete and consistent with the evaluation criteria
●使得项目干系人认可项目基线以完成并符合评价标准
●Achieving final product baselines as rapidly and cost-effectively as practical
●按实际情况快速而经济地达成项目产品基线
●Achieving implementation with no “catastrophic” incidents
●项目成功实施而没有”灾难性”事故