项目管理的六大经验教训
传统处理方式可能会令项目目标与业务成果背道而驰。最好的解决方案是让项目管理者与业务线中的实际工作人员进一步接近。 带着以上想法，我阅读了一篇来自InfoWorld的文章，主要讲述一个成功的SAP项目实施案例。文章介绍了一种除一般指标及流程之外，以项目产出为优先考量，且颇具灵活性与智能性的项目管理方式。故事所表达的项目管理理念来自一位名为Daiwa House的SAP客户。
经验教训 No. 1：让工作人员等待工作好过让工作等待相关工作人员。
全部三位受访者都明确表示，由传统项目管理技术向关键环节项目管理方式的转变带来了巨大的积极影响，整体工作中的每个阶段都获得了25%左右的实施周期缩减。
经验教训 No. 2：多任务处理现象比我们想象中的更为普遍、也更加有害。
不理解第一条经验重要性的企业往往会尝试最大限度提高员工利用率。问题在于，越是压榨员工的劳动力，对于最终结果的影响就越是消极。毫无疑问，员工是不可能同时处理多项任务的。所谓多任务处理，实际是指让员工不断从一项工作转移到另一项工作中。
经验教训 No. 3：避免“锦上添花”行为。
Daiwa House的项目领导小组…为每一项任务制定了明确的完成标准。他们互相之间时常交流避免锦上添花式行为出现的必要性，并认为这是工作效率低下的另一种体现。这种交流活动本身同样非常重要，因为如果说起工程师之间所共有的文化氛围，那么此类协同合作、共商良策的`习惯无疑是其中相当重要的组成部分。努力寻求解决方案，进而保证工作流程更加顺畅可谓专业人士的拼搏精神之所在。
经验教训 No. 4：不要对任务过分进行细化。
他们的团队认为，“定义细节其实无助于他人的理解，反而只会造成误解。”他们强调个中存在着一个收益递减点，一旦实际情况低于该点，也就意味着项目管理者在对工作进行事无巨细地全盘掌控，而没有让团队成员利用自身的丰富经验与良好判断力完成工作。
经验教训 No. 5：在业务改进方面持积极态度。
有趣的是，这一点原本其实可以算IT项目的典型标准。其主要目的是为管理(尤其是账目方面)、人力资源以及预定规则提供支持，具体措施是提供一套更为同步的企业信息视角。它所带来的主要业务收益是更快速的账目结算、人力资源管理改善以及对国际性规则的支持。
但是随着时间的推移，项目团队在业务改进的具体定义方面变得更具强制性。新软件所带来的处理流程与实践方式的异化与改善成为工作内容的正式组成部分，由原先的SAP实施及对额外功能优势的把握转向以优化业务流程及实践为核心的功能性诉求。
SAP尽管在名称中有所体现，但这一项目其实与SAP实施没啥关系。这种业务改进理念只是部分依附于SAP实施工作。
经验教训No. 6：为团队中的全体成员提供一套总体视角。
Daiwa House团队中的成员非常了解每个人都拥有大局观念对于组织整体的重要性，当然前提是大家先各自处理好自己的份内职责。
以上经验教训来自一套名为关键链式项目管理(简称CCPM)的解决方案，该方案由已故的Eliyahu M. Goldratt博士所开创。Goldratt提出的约束理论为业务目标、问题以及与企业变革相关的规划提供了可资借鉴的检验办法。
在问起原文作者兼项目管理专家Todd Williams时，他向我详细解释了关键链项目管理方式如何避免许多实际工作中常见的麻烦：
如今管理机制忽略了项目只是庞大系统中的一部分这一事实，这也正是约束理论(简称TOC)的核心内容。失去这样一种更为广阔的视角，项目注定要失败。举例来说，为了减少裁员行为，某家公司创建了一套人力资源政策，规定管理者在着手进行工作外包之前，必须先尝试收集企业内部的资源进行解决;这种思路的必然结果就是令许多不堪委以重任的员工进入到项目的管理队伍中来。那么最终项目未能如期完成，资金消耗速度高于预期而且每位参与者都感到十分沮丧也就在情理之中。如果不对项目的直接需要与机构的广泛业务诉求进行审慎考量，那么即使是上佳的创意也无法带来真正的成功。传统的项目管理方式往往在一味追求时间与预算等细化指标的同时忽视了真正的业务价值所在。
给CIO们的建议。传统项目管理只在支持有针对性的业务产出时较为重要。一个项目的成功不仅体现在如期完成以及预算没有超支上，切实带来预期中的业务产出同样甚至更为关键。大家不妨做做这样一个测试：让自己的项目管理者尝试说明项目将会带来哪些用户所期望的业务产出。如果他们的回答含糊其辞或是唯唯诺诺，那么也许是时候让自己的团队进一步贴近用户了。
【项目管理的六大经验教训】相关文章：
3.项目管理的流程
4.项目管理的要点