(1)有些利益相关方可能对项目要做什么会有不同的看法。

(2)开始时的微小差异可能导致最后的巨大分歧。例如，项目团队或许在项目目标上达成了一致意见，但是如果对于时间、成本或功能的相对重要性存在不同看法，则可能导致非常不同的结果。

项目是相互关联的系统，因此在某一领域内发生的变化会对别的领域产生影响。通常这意味着对项目的每个组成部分分别进行优化并不能使项目得到优化。项目需要作为一个整体得到优化，在这一优化位置上，一些组成部分也许不是最优的。这就是说，不一定每个利益相关方都能取得他们的理想结果，但每个利益相关方都需要把他们的目标与其他人的需要进行平衡，从而取得项目整体上的最佳结果。

所有者向承包商支付金钱，即价格，让承包商来做项目工作。然后所有者有效地购买承包商所做项目交付的资产。承包商花费部分金钱，即成本，来做项目工作，从中获得的差价就是利润，也就是项目提供给他们的价值。在项目完成后，所有者对资产进行运营并获得收入，即收益，其中收益和价格之间的差价就是项目对所有者的价值。现在就非常简单了，如果所有者能够把价格压低，他们就可以增加项目对他们自身的价值，但如果把价格压得太低的话，项目对承包商将没有任何价值，那么项目就不会发生。如果承包商能够把价格抬高，他们就可以增加项目对他们自身的价值，但如果把价格抬得太高的话，项目对所有者将没有任何价值，项目也不会发生。对于项目来说，最好是所有者和承包商双方达成妥协，商定一个价格，可以让双方都获得合理的利润。后面我们还会继续讨论该主题。(注：项目就是要完成的工作。但它并不是为了完成工作本身而完成，而是为了交付设施(facility)。这设施也许是一条新生产线、一个新产品或一项新服务、一个设计、一种新的组织结构或者工作方式。但设施不是为了它本身而产生。之所以产生设施，是因为有人(所有者或发起人)希望使用设施来获得收益。对项目团队或者承包商来说，所有者会购买设施。在任何时候，项目团队都必须记住项目是为什么而做的，项目的目的是什么或者说所有者期望得到的收益是什么。这是项目从本质上不同于日常运作的一个方面。如果你今天完成了工作，明天卖掉了产品，后天就得到了收益，你就可以进行实时的调整从而持续获得利润。但是如果你今天完成了工作，下一年得到设施，再过一年才得到收益，而这时项目团队已经解散了。工作是现在在这里完成的，而收益在多年后才出现，这就意味着很容易偏离工作重心。所有者从他们获得的收益和为设施支付的价格之间的差价中获得利润，而承包商从他们得到的价格和完成工作的成本之间的差价中获得利润。如果所有者可以降低价格，他们就能够增加他们的利润。如果承包商能够提高价格，他们也能够增加他们的利润。不同的项目团队成员有不同的目标。如果所有者和承包商是不同的公司，我们可以理解这一点并且可谈判签订一份合同。而如果他们属于同一家公司，我们仍然需要签署一份合同。你会听到有人说：“但难道我们不是为了同一家公司而工作吗?”——是的，但是有不同的视角。)

有时候，当我向项目经理们阐述这一点时，会有项目经理问我：“罗德尼，我明白你说的意思。但是在我的年度评估中，公司是根据我在规定的成本和时间内完成了多少项目来判断我的。我的年度奖金是由这个来决定的，而不是根据我提供给所有者的价值。我应该关注什么呢?”我的回答是他们应该关注改变他们的绩效评估体系，使之与好的项目管理相融合。项目管理者联盟文章，深入探讨。

还有一个问题是，所有人都关注相同的目标，因此都应该遵循相同的路径。开始时微小的差异很可能会导致最后相当大的差异。我的一个同事曾在一家英国造船公司工作。他们的传统业务是为皇家海军制造潜水艇，但希望进军护卫舰市场。当有一个制造护卫舰的项目来临时，他们在没有利润的情况下竞标并中标得到了这个项目。他们的目标是按时制造出一艘高质量的护卫舰，以证明他们能够做到这一点。这样开始时他们可能会有一点损失，但寄希望于将来赢得更多的订单。他们赢得了这个项目，但不幸的是没有人想到要告诉项目经理这个战略。因此项目经理把精力集中在降低成本来获取利润上，结果项目延期了，并且质量也比较低。

这就引出了项目成功的第二个必要条件。你不仅必须在项目开始前与利益相关方就项目成功标准达成共识，而且还需要在项目整个过程中的配置评估点上继续与之达成一致意见，以确保所有人都专注于相同的目标，并持续遵循相同的路径。

项目经理和项目所有者之间必须有高度的合作关系。所有项目参与方都必须把项目看做一种伙伴关系。项目就是一个临时性组织，为这个临时性组织工作的人们必须在一起很好地合作。这一点是非常明显的，然而不幸的是，项目经常成为项目经理和项目所有者之间可怕的战场。在采用对抗性合同的做法下，项目所有者和承包商之间在这点上尤为明显。我和ralfmuller(2004)提出，所有者和项目经理之间的委托—代理关系可用来解释为什么后者会发生。项目要想取得成功，项目经理和所有者之间、承包商和客户之间就必须以一种伙伴关系一起工作，向着对双方都有利的结果努力。

这就要求所有项目参与方在项目开始前就项目成功标准达成共识，并确保这些标准之间达到平衡(条件1)。

所有者只应该对项目经理施加适中的控制，既不能太多，也不能太少。如果施加了太多的控制，项目经理将没有足够的灵活性来处理项目产生的风险和不确定性。而太少的控制和自由放任的管理方式又将导致混乱占主导地位。所有者应该与项目经理就清晰的目标达成共识(这是高度合作的一部分，条件1和条件3)，然后指导项目经理应该如何最好地实现这些目标，但一定要给项目经理留出一定的空间来操纵，对风险和不确定性进行处理。我认为，这意味着项目经理应该被授权。授权是指在目标上达成共识，设定一个框架，而给项目经理留有一定的灵活性在那个框架内进行决策。不幸的是，委托—代理关系以及随之而来的逆向选择和道德风险问题(turnerandmuller，2003)导致所有者总是试图对项目经理施加非常严格和僵化的工作做法。

所有者应该要求项目经理定期提供项目绩效报告。muller(2003)发现，项目所有者想要得到的项目绩效报告和项目经理想要提供的报告之间存在着不匹配。相对于项目经理提供报告的意愿而言，所有者得到项目绩效报告的愿望更强烈。当所有者要求得到项目绩效报告时，项目就更可能成功，而当他们不要求时，项目通常不会成功。有意思的是，当所有者要求得到项目绩效报告时，他们对项目绩效的期望会低于实际绩效，对项目绩效持比较悲观的看法。当他们不要求得到项目绩效报告时，会对项目绩效抱有非常乐观的看法，所认为的项目绩效比实际绩效要好。muller(2003)也注意到，想要得到绩效报告的客户总是希望比较频繁地得到报告，比如每两周一次，最少也得每月一次。所有者也希望项目经理每周能进行一次面对面的口头汇报。虽然他们喜欢正式的书面报告，但同时也希望能够查问项目经理，通过项目经理的肢体语言来判断他们是否在讲真话。在太多的报告和太少的报告之间也应该有一个平衡。太多的报告花费昂贵，并且消耗了宝贵的资源。而太少的报告则会导致项目失败。

*每两周一次的书面绩效数据;

*每周一次面对面的口头汇报。

这些提示不能保证你的成功，但是它们将帮助你在你的项目上获得一个坚实的把手，并且保证你做了所有你可以做的事来让项目在这个疯狂的世界上成功。

在项目的开始，要保证风险承担者对于他们如何判断项目是否成功有统一的认识。经常，满足一个预定义的进度安排是唯一明显的成功因素，但是肯定还有其他的因素存在，比如：增加市场占有率，获得指定的销售量或销售额，取得特定用户满意程度，淘汰一个高维护需求的遗留系统，取得一个特定的事务处理量并保证正确性。

每个项目都需要平衡它的功能性，人员，预算，进度和质量目标。我们把以上五个项目方面中的每一个方面，要么定义成一个约束，你必须在这个约束中进行操作，要么定义成与项目成功对应的驱动，或者定义成通向成功的自由程度，你可以在一个规定的范围内调整。

在项目早期，要决定用什么标准来确定产品是否准备好发布了。你可以把发布标准基于：还存在有多少个高优先级的缺陷，性能度量，特定功能完全可操作，或其他方面表明项目已经达到了它的目的。不管你选择了什么标准，都应该是可实现的、可测量的、文档化的，并且与你的客户指的“质量”一致。

尽管有承诺不可能事件的压力，从不作一个你知道你不能保证的承诺。和客户和管理人员沟通哪些可以实际取得时，要有好的信誉。你的任何以前项目的数据会帮助你作说服的论据，虽然这对于不讲道理的人来说没有任何真正的防御作用。

有些人认为，花时间写计划还不如花时间写代码，但是我不这么认为。困难的部分不是写计划。困难的部分是作这个计划--思考，沟通，权衡，交流，提问并且倾听。你用来分析解决问题需要花费的时间，会减少项目以后会带给你的意外。

英寸大小的小圆石是缩小了的里程碑。把大任务分解成多个小任务，帮助你更加精确的估计它们，暴露出在其他情况下你可能没有想到的工作活动，并且保证更加精确、细密的状态跟踪。

如果你的组经常承担某种特定的通用任务，如实现一个新的对象类，你需要为这些任务开发一个活动检查列表和计划工作表。每个检查列表应该包括这个大任务可能需要的所有步骤。这些检查列表和工作表将帮助小组成员确定和评估与他/她必须处理的大任务的每个实例相关的工作量。

几乎所有的质量控制活动，如测试和技术评审，都会发现缺陷或其他提高的可能。你的项目进度或工作细分结构，应该把每次质量控制活动后的修改，作为一个单独的任务包括进去。如果你事实上不用作任何的修改，很好，你已经走在了本任务的计划前面。但是不要去指望它。

你的小组成员已经淹没在他们当前的项目中，但是如果你想把你的组提升到一个更高的软件工程能力水平，你就必须投资一些时间在过程改进上。从你的项目进度中留出一些时间，因为软件项目活动应该包括做能够帮助你下一个项目更加成功的过程改进。不要把你项目成员可以利用的时间100%的投入到项目任务中，然后惊讶于为什么他们在主动提高方面没有任何进展。

如果你不去识别和控制风险，那么它们会控制你。在项目计划时花一些时间集体讨论可能的风险因素，评估它们的潜在危害，并且决定你如何减轻或预防它们。

人们通常以日历时间作估计，但是我倾向于估计与任务相关联的工作计划(以人时为单位)的数量，然后把工作计划转换为日历时间的估计。这个转换基于每天我有多少有效的小时花费在项目任务上，我可能碰到的任何打断或突发调整请求，会议，和所有其他会让时间消失的地方。

跟踪你的组员每周实际花费在项目指定工作的平均小时数，实在会让人吃惊。与我们被要求做的许多活动相关的任务切换的开销，显著地降低了我们的.工作效率。不要只是因为有人在一项特定工作上每周花费10小时，就去假设他或她可以马上做4个这种任务，如果他或她能够处理完3个任务，你就很幸运了。

确定你的组员每年在培训上花费多少时间，并把它从组员工作在指定项目任务上的可用时间中减去。你可能在平均值中早已经减去了休假时间、生病时间和其他的时间，对于培训时间也要同样的处理。

当你准备估算你的工作时，把它们记录下来，并且记录你是如何完成每个任务的。理解创建估算所用的假设和方法，能够使它们在必要的时候更容易防护和调整，而且它将帮助你改善你的估算过程。

有很多商业工具可以帮助你估算整个项目。根据它们真实项目经验的巨大数据库，这些工具可以给你一个可能的进度和人员分配安排选择。它们同样能够帮助你避免进入“不可能区域”，即产品大小，小组大小和进度安排组合起来没有已知项目成功的情况。

如果你在项目中第一次尝试新的过程，工具或技术，你必须认可付出短期内生产力降低的代价。不要期望在新软件工程方法的第一次尝试中就获得惊人的效益，在进度安排中考虑不可避免的学习曲线。

事情不会象你项目计划的一样准确的进行，所以你的预算和进度安排应该在主要阶段后面包括一些意外的缓冲，以适应无法预料的事件。不幸的是，你的管理者或客户可能把这些缓冲作为填料，而不是明智的承认事实确实如此。指明一些以前项目不愉快的意外，来说明你的深谋远虑。

如果你不记录花费在每项任务上的实际工作时间，并和你的估算作比较，你将永远不能提高你的估算能力。你的估算将永远是猜测。

使用英寸大小的小圆石的一个好处是，你可以区分每个小任务要么完成了，要么没有完成，这比估计一个大任务在某个时候完成了多少百分比要实在的多。不要让人们只入不舍他们任务的完成状态;使用明确的标准来判断一个步骤是否真正的完成了。

创建一个良好的风气，让项目成员对准确地报告项目的状态感到安全。努力让项目在准确的、基于数据的事实基础上运行，而不是从因为害怕报告坏消息而产生的令人误解的乐观主义。使用项目状态信息在必要的时候进行纠正操作，并且在条件允许时进行表扬。