检查清单。
在项目执行期间，可以由项目管理团队作成检查清单或者模板(checklist/template)，也可以由项目管理室那样的支持项目管理的组织在项目审查和监督的成功案例和失败案例的基础上作成。检查清单或者模板是组织的最佳实践，通过这些经验的积累可以提高项目管理的效率，有助于防止失败。检查清单用于确认作业或工程是否存在遗漏。
模板作为产出物的雏形式样，具有wbs、网络图、需求变更书、进展报告书、合同标准文件等形式。通过雏形的灵活运用，经验较浅的项目管理者可以明白必须做些什么，并能在其他项目中重复利用。
软件开发项目管理检查清单：天气晴雨表。
检查清单用于确认作业或工程是否存在遗漏，是反映项目管理是否存在问题的“天气晴雨表”。下面是软件开发项目管理的一个检查清单，比本章中所言“软件开发项目管理过程中的祸根及其后果”更加详细。通过这个清单，可以发现项目管理存在的问题，并采取措施加以改善。
需求式样晴雨表。
是否存在稳定的、完整的、书面的需求式样？
是否已经就需求事项煞费苦心地与顾客进行了沟通和确认？
是否存在需求式样尚未确定就以“暂定式样”开始作业而事后返工的情况？
是否为了确认顾客的需求而对“需求式样书”进行了审查？
是否根据顾客提供的产品式样书而直接进入了设计作业？
是否在作业途中不断变更或追加需求式样？
是否按照项目编号规则对每项需求赋予了惟一的编号？
是否已经明确顾客方的项目推进体制以及最终决策者？
是否摄于顾客的特权优位性而不经讨论地接受顾客的需求变更？
是否在远远超越自身能力而根本无法完成的情况下不能清楚地说“不”？
是否在作业已经进入测试阶段后还发现需求式样理解有误？
是否以单一窗口接收顾客的需求，确保一窗口输入？
项目组成员的作业是否基于最新需求信息，而不是已经失效的历史信息？
项目计划晴雨表。
是否将估算视为一种特殊的技能，并将估算当作一个小项目？
是否定期对项目计划实施重新估算并根据实际情况加以调整？
是否对作业文档等成果物的“量”进行了估计？
是否以适当的单位进行了作业量的估计？
项目作业是否具有详细的日程表？
日程表确定之后，如果和实际情况出入较大，是否进行了调整？
是否接受了不切实际的开发日程，而其结果是，日程表仅仅成为一种形式？
“工作量”和“难易度”是否会因为担当者的不同而出现巨大变动？
是否因为实际进展超前于计划而没有思考项目计划本身存在的精度问题？
团队管理晴雨表。
是否存在明确的软件开发行动单位：团队？
是否虽然叫作团队，但是并没有认识到协作而是专注于工作任务的分担？
管理者是否仍然承担以前作为技术者所承担的具体开发作业任务？
项目管理者是否仅仅根据自己的经验而将需求式样直接分派给“个人”？
项目管理者是否总是认为项目没有什么值得注意的问题？
团队成员是否知道项目作业内容的相互关系及其优先级？
是否在项目启动之后仍然还有项目组成员感到无所事事？
是否经常有特定的项目组成员总是加班到深夜？
团队成员是否知道并遵守统一的作业规范？
是否从作业流程上、从团队协作上追究过程序缺陷的真正原因？
团队成员是否在相互察看成果物后产生提高自己的作业水平的意识？
当问题难点解决之后，是否向项目组成员介绍解决该问题的思维和方法？
项目组成员的出勤时间是否经常相差很大而不寻找原因？
项目组成员在遇到技术难题时是否与项目组其他成员沟通并寻求支援？
项目组成员在讨论问题时是否出现无条理的、非建设性的讨论？
作业流程晴雨表。
是否存在专注于组织整体的开发作业和项目流程的人或者小组？
是否存在项目开发作业的标准作业流程？
是否存在记述顾客需求式样的文档标准？
是否存在设计书的文档标准？
是否不经过设计阶段而直接进入编码阶段？
设计阶段是否实施了以设计为对象的审查？
编码阶段是否实施了以**为对象的审查？
中途式样变更后，是否未经其影响范围的分析就直接分配给担当者？
是否未经单体测试就直接开始综合测试？
是否时至最后才发现此前隐藏的诸多问题？
是否无视已经发现的问题而继续推进作业？
是否多次重复出现以前相同的错误而没有吸取教训？
是否没有专门的测试人员而在交付之前还是由开发者自己实施测试？
对式样需求是否确立了适当的测试项目？
测试是否几乎没有自动化手段？
过程改善方面是否存在可以商量和咨询的人员？
是否鼓励各开发小组写作事后分析报告，至少能就项目进程开会讨论？
是否组织正式的活动，就软件开发与质量控制流程的相关问题相互切磋？
项目配置晴雨表。
是否在发现潜在的缺陷时难以确定其对现有模型的影响范围？
是否只有担当者知道而没有向所有成员公布缺陷的修正范围和修正方法？
是否因为修改一个程序缺陷而引发多个新的缺陷？
担当者是否能在任何时间对源程序做自由的变更？
开发期间是否定期对制作过程中的文件和程序进行备份？
是否确立了资源备份在非常时期的因应方式？
需求式样书和设计书等正式文件是否存在“确认”手续？
项目文档是否一直保持最初的状态，即使在式样变更后仍然没有变化？
是否在项目后期难以想起中途式样变更的“理由”？
对于程序缺陷和式样变更，是否能追踪其修改点？
对于开发环境目录中的旧**是否难以判断其能否删除？
开发文档是否会出现链接到旧版本的情况？
教育培训晴雨表。
是否描绘出现在的开发组织多年后的“风姿”？
在组织上，是否对现在的人员实施技术性教育和培训？
是否确立了员工教育培训的计划和目标？
是否将技术学习视为个人任务而没有组织上的“方向”？
项目开发人员所持有的软件开发文献的平均数量是否在1册以下？
项目作业休息时间是否毫不涉及崭新技术方面的话题？
项目组成员是否不知道软件工程的意思？
是否不了解“凝聚度”、“结合度”等词汇的意思？
是否难以说出5个以上的软件质量特性及其副特性？
项目审查晴雨表。
参与者是否了解审查的整体流程？
是否带着目的而非盲目地实施审查作业？
是否仅仅局限于**审查而不顾及其他？
审查者是否只关注形式而非实质？
是否明确审查对象物，针对“物”而非“人”？
是否记录审查结果并追踪缺陷修正结果？
是否将审查的反馈结果导入下一项目中？
审查会议是否演化成为问题解决会议？
其他。 是否采取了数据备份以及病毒防范等措施？
对电子邮件的应对是否总是滞后？
是否感到电子邮件的应对很繁琐？
作业检查清单
每次交作业前对照这几项，如果都checked 通过 了，就可以交上去，如果还没有，那就得先加油改进一下。你真的做完了吗？在说 我搞定了 之前，请问问自己 我写上名字了吗？我遵循所有的流程了吗？我有没把所有的东西检查一遍？还有没有什么可以改进的地方？我刚刚能达标还是做得还要更好些？我能很自豪地说，已经...
项目管理方法 甘特图
甘特图 gantt chart 甘特图 gantt chart 也叫横道图等，它是以亨利 l 甘特先生的名字命名的，是在第一次世界大战时开始使用的两维图表。它的横轴表示时间，纵轴表示要执行的任务，线条表示在整个项目周期上各项任务的计划的开始时间和结束时间。甘特图直观地显示了项目的任务划分和进度安排。...
项目管理方法 责任矩阵
责任矩阵。甘特图虽然直观地显示了项目的任务划分和进度安排，但项目需要完成的任务往往千头万绪，参与项目的部门与个人又五花八门，为此需要一种手段将任务落实到相应的人头上，确保每个任务都有相应的人员去负责和完成，这便是人员分工。责任矩阵 responsibility matrix,rm 就是一种将工作任务...