要把奖励活动变成团队文化的一部分。另外，尝试“隐形”的奖励，让你的下属明白你是真的知晓他们所做的贡献，并且对此心存感激。
前车之鉴， 后事之师
你负责的项目很可能是半途接手的，而且你的前任做的并不怎么好；或者，虽然是新项目，但从前有类似的项目完成，当然有成功的，也有失败的。不管是哪种情形，你作为项目的负责人，应该花些时间分析以往的成功经验和失败教训。你要了解这些项目曾经出现过什么问题，以此避免自己重蹈覆辙。失败是成功之母，但你没有太多的机会失败，所以你要多从别人的失败中学习。
不要戴着有色眼镜去看以往的项目，或许某个你不喜欢的家伙出色的完成了他的项目，你当然可以把这归结为运气或者侥幸，但如果你客观的分析，或许更有助于你的成功。
你也需要客观的去评价自己完成的一些项目（如果有的话），了解自己的团队究竟强在哪里，弱在何处。事实上，每个完成的项目都要进行项目回顾（Post-project
Review），有时这种总结式的项目回顾也叫做“开棺验尸”（Postmortem）。注意项目回顾不是为了追究谁的责任，发现问题、剖析问题是为了以后做得更好。你可以采取头脑风暴的做法，鼓励项目组成员各抒己见。另外，这种项目回顾也可以扩展到项目进行中，在每个大的阶段结束时都进行回顾。
除此之外，你需要了解被软件业界普遍认可的最佳实践（Best practice）。在SteveMcConnell 的《Rapid Development》（Microsoft Press，1996）中介绍了27 个最佳实践和36 个软件开发的“经典”问题。此书曾获Jolt Award，是一个很好的学习起点。当你想把一些好的方法、工具和流程引入到你的项目中时，其他人可能会排斥、反对，甚至抵制，而这恰恰是你的职责所在，你要让项目成员明白为什么要这样做，并且确保他们不折不扣的执行。在你的团队内部，也会产生一些最佳实践，所以你要采取一些措施，促使在项目成员之间交流和采纳这些实践。
设立改进目标
当你回顾了以往的项目，并且确定了“质量”的含义，你需要设立一些短期的和长期的改进目标。只要可能，这些目标应该是可以量化的，这样你可以通过一些简单的指标来衡量自己是否在朝着这些目标前进。
举个例子，你发现以往的项目由于需求多变而经常延后，于是，你可以设立一个半年的目标，力求将需求的稳定性提高50%。这样的一个目标要求你每周每月做实际的工作：统计需求的改变数，查明需求的来源和改变的原因，采取措施来控制改变。这很可能将改变你与那些需求更改者的交往方式。
你的这些目标和指标构成了软件流程改进的一部分。尽管流程改进常被人指责为“官僚作风”的体现，但事实上，每个团队都能找到一些可以改进的地方。如果你停留在一贯以来的做事方法上，你最好不要指望能获得比以前更好的结果。
改进流程的原因通常有两个：纠正错误和预防错误。你要把精力集中到威胁或者可能威胁项目成功的因素上；带领你的团队一起分析你们目前做法的长处和短处，以及所面临的威胁。
我自己的团队就组织过一次两阶段的头脑风暴练习，以此来确认提高我们的产量和质量的障碍。在第一阶段，参与者将自己想到的障碍写在即时贴上，每张即时贴写一个想法；然后，协调者就把这些即时贴收集起来，并进行分类；于是我们得到了若干大的分类，我们就把这些分类写在一张大的白纸上。
在第二阶段，同样还是这些参与者，针对前面写的障碍，把想到的克服方法写到即时贴上，并且粘贴到相应的分类上。经过进一步的讨论和分析，我们得以把这些障碍细化，并且
获得了一系列可操作的应对方法。
设立可度量的、可争取的目标将集中你为改进流程而付出的努力。你要和你的队员们一起定期检视改进的结果。记住流程改进的目的是为了项目和公司的成功，而不是为了满足书本上的条条框框。把流程改进当成项目来操作，有自己的进度、投入和产出。否则，流程改进总是得不到应有的重视，最终被琐碎的日常工作而淹没。
不要急于求成
本文所建议的一些做法将帮助你这个项目管理的新手和你的团队取得更大的成功，随着你每天面临的工作压力，你或许会沦为又一个“苟延残喘”者，但是，你要始终明白你肩负的一个任务（可能也是你获得成功的机会），那就是形成你的团队文化和一套做事的方法，这是一个长期的任务。你不可能一下子把想做的事都做到，你可以根据自己的处境有所选择，从容上路。
作者：Karl E. Wiegers
翻译改写：吴昊