在项目收尾前，项目管理者应该撰写一份正式文档——项目总结报告。现实中，撰写文档是很多人非常不喜欢的工作。需要强调的是，很多个人层面看似没有意义的工作，在组织层面非常有价值。很多文档工作是在为组织积累过程资产，你应学会按照组织的架构流程进行工作。
需要说明的是，不管喜欢还是不喜欢，写文档是一种必须掌握的核心技能。而且，文档也是体现你价值的重要方式和机会。从实践角度，项目总结报告至少应该包含以下部分。
第一部分，描述原项目（招标时）的基本方面，即范围、进度、成本、质量等。
第二部分，说明在范围、进度、成本、质量等方面与原计划的偏差。
第三部分，分析项目生命周期中的客户关系。
第四部分，总结风险管理，提供项目过程中发生的主要威胁和机会的列表，并说明是如何应对的，以及应对的实际结果。
第五部分，经验教训，包含事情的经过和采取的措施，并指出这些经验教训的受益者会有哪些。
一个结构化的项目总结流程如下图所示：
应该以客观、透明的方式跟踪项目的历史记录，你必须营造轻松、合作的氛围，以便消除负面影响。
应该将继续服务和支持视为一种机会，而不仅仅是一种义务。如果这些包括在项目里，员工将与客户一起工作，并且提供继续服务和支持。该过程中，他们会和客户一起通过非正式的机会发掘想法，并且倾听客户所面临的真正问题。这样的接触会为未来的商业机会奠定基础。
如果项目在一个或几个方面不符合要求，应该进行书面记录，并通过以下方式进行处理。
（1）扩展项目，以完成必需的额外工作。（2）重新协商项目范围，使之符合已交付的成果。
（3）获得有条件的接受，并承诺在未来某个日期解决问题。
即使还有尚未解决的缺陷，也要获得对已经完成的成果的书面确认。应该在下一期项目状态报告中概述验收测试的结果，并且把验收测试的结果归档。
在经验主义盛行的当下，在项目这个行当中，如果过度相信经验，效果并不好。还有一个不容忽视又自相矛盾的问题是，我们“做得多而总结得少”。相关数据积累得不多，缺乏分析与总结，以致同一个错误反复发生。一个项目总结表模板参考如下：
为了使总结的经验教训发挥作用，经验教训文档中的描述，必须实实在在、可落实、可度量。每一个问题描述和应对手段，必须是具体的、可以落实的工作项。
许多组织都缺乏必要的知识管理基础设施，这些组织也就无法记住已完成项目的经验教训，从而无法利用过去的经验教训。如果不从根本上建立经验教训总结的制度体系和基础设施，不犯重复错误简直是痴人说梦。
