技巧1: 问题可以定义为达不到期望的要求. 因此不要忘记仔细地定义和识别那些通向项目成功的因素!
组织不会批准一个”项目游戏”, 项目需要真正地花费金钱和其他资源, 因此在项目开始时,应该确保客户和项目团队对项目的成功标准的定义及测量方法达成共识.
技巧2: 一个项目的生命周期是一个项目的基本沟通工具. 这对于有潜在问题的项目由为重要, 他揭示了在每个项目阶段对期望的定义及实际背离.
项目的生命周期具有很多用途, 一个关键的目标就是定义项目在每个阶段应该产生的交付物…..以及怎样对这些交付物进行评审, 验证,确认和批准进入下一阶段.
技巧3:问题项目往往来自问题团队, 不要忘记项目团队章程,要及时更新项目团队章程!
项目团队章程是项目团队制定,更新和采用的项目团队行为规范, 他定义了项目团队中每个成员共同的和相互间的期望, 项目经理和其他项目成员必须持续地遵守该章程.
技巧4:不要忘记项目的起决定于一系列的要求的达成; 用户所感知的”问题” 往往是”功能上”的问题!
功能上的要求清楚地定义了什么是用户希望从项目中得到的更好的和更加有效的结果.
技巧5: 功能上的要求可能是所有用户都关心的, 虽然如此, 但是对应非功能性要求的忽视往往也会使项目陷入困境.
非功能性要求包括一些限制性要求,项目必须在这些限制下完成交付和达到希望的结果. 质量概括了这些项目干系人所期望的但隐含的特性,如舒适,漂亮, 精致……
技巧6: “客户的心声” 确定了用户的期望, 因此不要忘记询问”客户想要和能为项目做些什么”
非功能性要求包括一些限制性要求,项目必须在这些限制下完成交付和达到希望的结果. 质量概括了这些项目干系人所期望的但隐含的特性,如舒适,漂亮, 精致……
技巧7: 许多项目团队浪费了大量的工作试图制作一份详细的风险事件清单,但是问题往往就产生于那些被遗漏了的风险事件. 为什么不采用风险检查表呢?
很多年前, 软件工程协会就发布了一份命名为风险识别分类的文件,该文件可以免费从SEI.CMU.EDU上下载. 附录B 提供了一大约200个问题的清单以帮助定义和识别风险事件. 其中很多可以容易地被应用到除了软件开发外的其他领域.
技巧8: 问题有时来自疏忽. 一些工作包中的关键任务也容易被忽略, 采用检查清单能够减少这些潜在的疏忽.
提供一个工作分解结构(WBS)工作辅助辞典, 现在就下载并根据你的组织的实际情况来进行修改使用吧.
技巧9: 很多变更控制系统使用起来费时费力. 项目干系人常常在这些系统之间徘徊从而导致很多问题, 为什么不使它变得容易与我们所期望的变更相结合?
有效变更控制系统的目标应该是快速, 增值并能实现期望的变更. 制定一份容易完成和评估的变更控制要求表. 其中应包括从变更中变更要求者接受妥协的意愿和期望的受益!
技巧10: 问题往往来自项目生命周期只有一个设计阶段, 确保项目的生命周期包括了一个设计和计划阶段!
非常常见的现象是开发团对在设计和建造阶段很少甚至没有重视计划, 设计阶段应该在期望的质量,时间,预算和风险等限制下对功能性的交付进行计划.
技巧11: 经济的测试对于已经完成测试的软件,建筑和新产品等项目不是什么问题, 问题往往在建造后的测试阶段被发现.将测试尽可能地移到项目生命周期的前段能有效地节约测试成本和使客户满意。
对测试,试验和变更进行计划是项目生命周期中执行或建造阶段的一部分.在系统即将完成阶段识别和消除缺陷比在过程中成本要高很多.
技巧12: 当处理项目成员激励问题,也就是”麻烦”时, 问以下三个问题:
Vroom 和 Yetton 在1974年明确了如果项目成员受到激励,他们能够自问并肯定地回答三个问题:(1) 我知道对我的期望是什么吗? (2) 我期望我能达到对我的期望吗? (3) 我期望对我的个人价值的肯定吗?
技巧13: 多数问题都出现在非预期的风险事件的发生, 监控风险的前兆或信号以减少潜在的意外.
失效模式及影响分析(FMEA)要求对风险的可探测性进行评估. 项目管理称为”触发器”. 确保对那些有风险的工作包的风险触发器进行了识别, 每个风险事件可能发生的地点, 以即在不同情况,进展和预测方面得到足够的关注.
技巧14: 当在确定项目基线之前要求不断改变时,每周监控变更的数量以确定潜在的问题
要求可能集中或者分散在项目的计划阶段, 每周监控变更的数量应该可以显示出变更率是增长还是在逐渐减小到一个稳定的数量上.如果某些要求稳定而另一些要求不稳定, 则预示着应该采取阶段性的交付方法.
技巧15: 当大多数较低权重和优先级被推迟以替代项目延期或者项目预算增加时, 项目就陷入困境。
如果当项目日程,成本和质量压力来临时,所有可以推迟的要求被推迟并且只有那些必须的要求被保留,项目可能是令人绝望的. 那些对项目信息很了解的干系人可能不希望出现这样的结果,但是他们的确应该对这样的结果承担责任。
技巧16: 当项目干系人对项目信息没有回应或者不以希望的方式进行回应时, 应该建立积极的,选择性的沟通机制以转移这些问题
多数项目经理成天和迈尔斯-布里格斯心理类型(MBTI)的人打交道, 回忆一下有些人(1) 靠感觉和直觉来感知,而有些人(2)靠想当然来感知. 了解你的那些MBTI们和你的那些”典型”的项目胳干系人,也就是那些决策者们,你就会明白为什么项目经理送出的信息不能被感知和按照项目经理的期望得到贯彻执行.
技巧17: 当项目陷入困境时,首先要采取措施防止危害的蔓延,然后才来考虑补救措施.
医生和拯救人员面临危难情景时进行的训练是首先”限制伤害扩散”,一旦情况得到稳定再考虑其它补救措施. 这种方法也应该毫无保留地被应用到出现问题的项目中.
技巧18: 当项目确定陷入困境时,不要等待项目自己会好转, 立即采取行动!
根据具体情况, 采取以下3到4种方法解决问题
1. 减少要求以便在批准的时间及资源限制下完成项目。
2. 通过关注短期的改善措施的实施提高项目执行过程的生产效率。
3. 面对项目的要求不能按期交付的现实; 调整日程,实施损害控制措施,可能时包括终止项目,或者尝试以下三者措施相结合; 放弃一些项目要求,提高工作效率和根据具体情况再次调整项目日程.
技巧19: 当确定项目陷入困境时, 可以关注以下三方面以获得短期的效果:人员,过程和产品.
首先应该关注的是人的因素：
●尽可能采取一切措施回复项目团队士气。
●清除主要的人员问题。
●清除主要的领导问题。
●增加确实要增加人员也要十分小心。
●关注人员的时间。
●承认项目成员的差异。
●留心项目关键成员的表率作用。
技巧20: 项目产品的交付是项目结束的先兆. 减少问题取决于有效的项目交接
项目成功结束的标志是:
●使得用户能够进行自我维持项目。
●使得项目干系人认可项目基线以完成并符合评价标准。
●按实际情况快速而经济地达成项目产品基线。
●项目成功实施而没有”灾难性”事故。
