传统处理方式可能会令项目目标与业务成果背道而驰。最好的解决方案是让项目管理者与业务线中的实际工作人员进一步接近。
带着以上想法，我阅读了一篇来自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)的核心内容。失去这样一种更为广阔的视角，项目注定要失败。举例来说，为了减少裁员行为，某家公司创建了一套人力资