优质项目管理的四大要素是：选择正确的人、为他们分配正确的工作、保持他们的积极性和帮助团队凝聚起来并保持团队的凝聚力。安全和变化的辩证关系在于：除非感到安全，否则人们就不能去迎接变化；在所有成功的工程中，变化都是基本的要素之一；安全感的缺乏会让人们反对变化；人们可能会因为来自客观世界的直接的恐吓而觉得没有安全感，但是如果察觉到管理者可能滥用权力来惩罚自己，他们也会觉得没有安全感。风险控制方面，通过控制风险来管理项目；要为每个项目创建并维护风险统计表；跟踪根源性的风险，而不只是最后那讨厌的结果；建立简单的(可能是匿名的)通道，让坏消息能传递到高层。或者在早期，人员超编会迫使项目跨过关键的设计阶段，如果在设计完成之前，工作先被分给了许多人，那么人与人之间、工作组之间的接口就会很复杂……
如果只是把这些管理箴言一一罗列，另外再举几个诸如微软、宝洁、IBM等大公司的经营事迹，那么这本书顶多就是目前我们常见的管理学畅销书籍及励志图书，能成为畅销但很难成为常销。《最后期限》独辟蹊径，作为一本项目管理小说，它是以主人公被绑架开始的：汤普金斯先生，这位爱打瞌睡的资深项目经理，是公司近期裁员的牺牲品，被绑架到一个完全陌生的国度，委以一项近乎不可能的任务，于是开始了一次奇异的、难以测度的冒险……这听起来完全像一部卡夫卡式的荒诞小说。
这样的开篇，或许您会说，这只是制造悬念、吸引读者的套路而已。可是“悬念”原本只该发生在那些存在风险、需要胆魄和运气的领域：间谍或是反问谍、高空救险、买彩票等，哪里有悬念，哪里就有危险，就有失败甚至丧命的可能。为什么软件开发项目会卷入一场悬念、一次历险之中?“最后期限”，英文原词是“deadline”，直译就是“死线”，据说原本指的是监狱里的最后一道界限，犯人一旦越过就格杀勿论——难道作者是以此象征开发者们头上悬着的剑?难道作者在暗示，软件项目就很可能挣扎在这样的生死界限上，很可能陷入“被劫持”的危险中?
据说，在软件行业之外，“项目”往往意味着规范的运作，甚至是“成功”的同义语。请设想一个建筑项目。不考虑款项拖欠和成本回收，单纯从设计、施工角度来说，“失败”的可能性微乎其微。按此推测，软件项目很少与有形的“物质材料”打交道，成功的概率似乎会较建筑业更高。但是，任何略有经验的开发者都会明白我说的“风险”在软件项目中意味着的比例。让我们援引业界公认的“硬数据”：作为软件项目管理权威，本书作者汤姆·迪马克(Tom Demarco)在他的另一部名著《人件》中谈到，他们“跟踪研究的所有项目中，大约有15％的项目彻底失败。在持续了25个工作年或者更长时间的项目中，足足有25％的项目没能完成”。
由此，我们可以这么认为，软件项目从本质上来讲，首先并且总是处于“危机四伏”的状态中。面对如此高的风险，不少深谋远虑的项目规划者甚至会像书中的汤普金斯一样，让多个项目组同时开发同一模块，取最优的结果。但仍有很多不走运的软件项目，要么对此没有充分意识，要么无法负担大量人力，所以其命运大都前仆后继地被归为失败。回到软件行业，尽管有25％的失败率，但是毕竟多数软件项目确实还算得上走运。那么，成功的秘诀和失败的主因各是什么?
在纯技术领域，确实已有不少论著致力于这样的工作。很多专家发现大家总在重复相同的错误，进而总结出了软件设计中的一些典型错误思路，并把它们称为“反模式”。而在软件项目管理方面，如果也有这样一部记录成功的航线和沉船的位置的书该多好，我们不就也能据此把握航向、避开那些臭名昭著的礁石了吗?笔者最初就是怀着这样的念头开始读《最后期限》。这本书也确实能起到这样的作用。伴随着我们的朋友汤普金斯在虚构的“摩罗维亚国”的历险，我们从一个个机智美妙的故事中学到了不少“作为”与“不作为”——每章之后，都有一段以“汤普金斯日记”形式出现的总结，如果时间实在紧张，单单浏览一遍这些日记，就能在工作划分、人员配备、项目时间计划、测试、发布等问题上收获很多真知灼见。
事实上，读完全书后，笔者感到自己最大的收获并非任何特定的管理秘诀，而恰恰是这样一个认识：没有任何单一的实践或原则能够确保一个软件开发项目的成功，任何单一的缺陷也未必会将项目导向失败。主人公汤普金斯的成功几乎是不可复制的，因为决胜的因素缥缈而暖昧，并不能归结于某一点儿魔术药水式的“方法论”或某位天降神兵式的个人；同样，我们也能看出，即使您身旁总有一位“邪恶的贝洛克部长”似的超级决策者，您的项目也不一定就单单因此而满盘皆输。这似乎是对《人月神话》中“没有银弹”原则的一次简单扩充。这一个原则意味着特定情景下的多种因素处于一种动态、细微而又相互干涉的关系中，其中任何单个因素都不具有优先性。因此，即使某个特定的项目中解决了某个困难，也无法保证从此我们就对它有了免疫力。
软件项目的这种内在的复杂性，也许同样是其“奇异的魅力”之所在。如果软件开发的艺术完全可以通过抽象的原则“线性地”掌握，那么我们甚至可以自问，会不会有一天软件项目只由计算机自行开发，人类开发者完全被取代呢?而依据上面的讨论，我们或许可以相信，软件开发的困难所在，正是机器无法通过形式化的方式克服、而人类开发者最为擅长的部分。这是真正倾心于这项事业的人乐于看到的论证：要感谢这些困难，广大软件开发人员不会在某天早晨醒来发现，自己的职位已被一台能干的计算机顶替了。
但是如果仅满足于指认困难的内在性，本书的建设性意义究竟何在呢?在笔者看来，软件工程学中的“纯技术部分”，尤其是系统构架设计，往往是容易确定，并能够通过教学、培训加以掌握的(当然这里和其他自然科学一样，仍需要悟性、实践和创新意识)；而对于其他的内容，特别是与开发的“商业”和“管理”环节对应的领域，虽然也包含高度的内在严格性，但很难直截了当地说明，更不容易通过简单的教学而传授。这些领域更多地与纯粹技术之外的人类普遍经验相关，对它们的学习、培育，也许只能经过实践，经过教化而缓慢、耐心地进行。于是，《最后期限》的意义在于它用有趣的故事情节、丰富的人物形象，告诉了我们许多深刻的管理智慧，以及能够帮助我们满足最后期限的实用建议。