在项目过程中，通过监视成本差异和进度差异以及成本效率指数、进度效率指数的变动，预测超过成本和进度滞后的情况后采取对策。在分析计划与实绩差异的原因及对策时，可以使用图表化、头脑风暴法+KJ法。如果计划与实绩差异过大，应该考虑缩小项目范围等对策。

头脑风暴＋KJ法

头脑风暴(brain storming)和KJ法都是发现问题和解决问题行动中实施创造性开发的方式。

头脑风暴法又叫作集思广益法，它通过创造一个无批评的自由的会议环境，使与会者畅所欲言、充分交流、互相启迪，产生大量创造性的意见，其目的是利用组合脑力刺激创造性，想出更多更好的主意。其作用在于：打破思维定势，鼓励开放性的思考；发挥集体智慧，在他人的看法上建立自己的意见；打破沟通障碍，形成团队精神；防止少数人控制会议。其实施步骤如下：(1)将头脑风暴的中心议题写在白板、胶片或挂图上，确保每个人都充分理解中心议题的含义。(2)项目组成员轮流发言，任何意见都会得到肯定。轮流的过程鼓励大家参与，但任何人如果没想好则发言可以随时跳过。(3)将每一条意见用大号字写在胶片或挂图上。用原话记录每条意见，不作任何解释。(4)继续轮流发言，直到每个人都没有意见为止。(5)复查意见记录，去除完全重复的条目。小心识别并保留在用词上有极细微差别的意见。头脑风暴法对于认识现状、整理问题、讨论问题过程中挖掘参与人员的意见非常有效。在PMBOK所谓范围、成本、质量、沟通、风险等知识领域的管理中比较有效。

在问题并不明朗的情况下通过KJ法可以使问题逐渐清晰起来。所以，在软件开发过程中，多用于需求分析、业务分析等。在项目计划阶段，对于PMBOK所谓风险管理知识领域中的风险识别、对策立案等方面比较有效。但是，如果理解KJ法的成员比较少，其使用会比较困难。特地集中起来的创意和意见如果仅仅简单加以分类，难以引出问题点和创意点。

检查清单/模板

在项目执行期间，可以由项目管理团队作成检查清单或者模板(checklist/template)，也可以由项目管理室那样的支持项目管理的组织在项目审查和监督的成功案例和失败案例的基础上作成。检查清单或者模板是组织的佳实践，通过这些经验的积累可以提高项目管理的效率，有助于防止失败。检查清单用于确认作业或工程是否存在遗漏。模板作为产出物的雏形式样，具有WBS、网络图、需求变更书、进展报告书、合同标准文件等形式。通过雏形的灵活运用，经验较浅的项目管理者可以明白必须做些什么，并能在其他项目中重复利用。

软件开发项目管理检查清单：天气晴雨表

检查清单用于确认作业或工程是否存在遗漏，是反映项目管理是否存在问题的“天气晴雨表”。下面是软件开发项目管理的一个检查清单，比本章中所言“软件开发项目管理过程中的祸根及其后果”更加详细。通过这个清单，可以发现项目管理存在的问题，并采取措施加以改善。

需求式样晴雨表

    是否存在稳定的、完整的、书面的需求式样？
    是否已经需求事项煞费苦心地与顾客进行了沟通和确认？
    是否存在需求式样尚未确定以“暂定式样”开始作业而事后返工的情况？
    是否为了确认顾客的需求而对“需求式样书”进行了审查？
    是否根据顾客提供的产品式样书而直接进入了设计作业？
    是否在作业途中不断变更或追加需求式样？
    是否按照项目编号规则对每项需求赋予了惟一的编号？
    是否已经明确顾客方的项目推进体制以及终决策者？
    是否摄于顾客的特权优位性而不经讨论地接受顾客的需求变更？
    是否在远远超越自身能力而根本无法完成的情况下不能清楚地说“不”？
    是否在作业已经进入测试阶段后还发现需求式样理解有误？
    是否以单一窗口接收顾客的需求，确保一窗口输入？
    项目组成员的作业是否基于新需求信息，而不是已经失效的历史信息？

项目计划晴雨表

    是否将估算视为一种特殊的技能，并将估算当作一个小项目？
    是否定期对项目计划实施重新估算并根据实际情况加以调整？
    是否对作业文档等成果物的“量”进行了估计？
    是否以适当的单位进行了作业量的估计？
    项目作业是否具有详细的日程表？
    日程表确定之后，如果和实际情况出入较大，是否进行了调整？
    是否接受了不切实际的开发日程，而其结果是，日程表仅仅成为一种形式？
    “工作量”和“难易度”是否会因为担当者的不同而出现巨大变动？
    是否因为实际进展超前于计划而没有思考项目计划本身存在的精度问题？

团队管理晴雨表

    是否存在明确的软件开发行动单位：团队？
    是否虽然叫作团队，但是并没有认识到协作而是专注于工作任务的分担？
    管理者是否仍然承担以前作为技术者所承担的具体开发作业任务？
    项目管理者是否仅仅根据自己的经验而将需求式样直接分派给“个人”？
    项目管理者是否总是认为项目没有什么值得注意的问题？
    团队成员是否知道项目作业内容的相互关系及其优先级？
    是否在项目启动之后仍然还有项目组成员感到无所事事？
    是否经常有特定的项目组成员总是加班到深夜？
    团队成员是否知道并遵守统一的作业规范？
    是否从作业流程上、从团队协作上追究过程序缺陷的真正原因？
    团队成员是否在相互察看成果物后产生提高自己的作业水平的意识？
    当问题难点解决之后，是否向项目组成员介绍解决该问题的思维和方法？
    项目组成员的出勤时间是否经常相差很大而不寻找原因？
    项目组成员在遇到技术难题时是否与项目组其他成员沟通并寻求支援？
    项目组成员在讨论问题时是否出现无条理的、非建设性的讨论？