当问到为什么要隐瞒项目中存在的问题时。得到的答案大多数都是基层经理们不希望高级管理层看到项目的糟糕状况。当然，当问题最终浮出水面时，实际上基层经理们看起来更糟糕，相比之下.那些成功的软件项目总是以更加理性的方式处理项目中存在的问题。他们能尽早发现问题，组建专门任务小组来解决这些问题，且通常在这些问题变得严重到无法解决之前就能控制住局面。敏捷方法一个有趣的特色是每天讨论项目中存在的问题，团队软件过程(TSP)同样如此。
软件项目的问题有点儿像严重的医疗问题。它们通常不会白己消失，为消除这些问题，需要许多专业的“治疗“方法， 软件项目的问题有点儿像严重的医疗问题。它们通常不会自己消失，为消除这些问题，需要许多专业的“治疗“方法。软件项目一旦启动，通常没有固定、可靠的指导性方法来判断项目实际进展速度。长期以来，民用软件行业一直使用特定里程碑的方法来确定项目进度，比如设计完成或编码完成等。但是，这些里程碑也是出了名的不靠谱。
软件项目状态跟踪需要涉及以下两个彼此不相关的问题:：(1)达到具体、确定的里程碑；(2)在明确的预算金额内消耗项目资源和资金。由于软件项目里程碑和成本受需求变更和“范围鉴延”的影响，当这些变化影响了功能点总数时，对需求变更的规模增长进行度最就变得非常重要。然而，正如本章上一节提到的.某些称为“需求波动”的需求变更不影响功能点规模总数，而需求蔓延和需求波动往往又都随机出现。需求波动比需求蔓延更加难以度量，往往只能通过程序派代码语句数量和功能点指标之间的“逆火分析”或者数学转换来进行度量。
截至2009年.已有许多可用的自动化工具帮助项目经理记录项目里程碑报告所需要的各种重要信息。这些工具能够记录项目进度、资源、规模变化以及各种项目问题。对于一个具有60年悠久历史的行业.却没有一套通用的或普遍的项目里程碑来标示项目实质性进展情况，这多少有些令人吃惊！
