當問到為什么要隱瞞項目中存在的問題時。得到的答案大多數(shù)都是基層經(jīng)理們不希望高級管理層看到項目的糟糕狀況。當然，當問題最終浮出水面時，實際上基層經(jīng)理們看起來更糟糕，相比之下.那些成功的軟件項目總是以更加理性的方式處理項目中存在的問題。他們能盡早發(fā)現(xiàn)問題，組建專門任務小組來解決這些問題，且通常在這些問題變得嚴重到無法解決之前就能控制住局面。敏捷方法一個有趣的特色是每天討論項目中存在的問題，團隊軟件過程(TSP)同樣如此。
軟件項目的問題有點兒像嚴重的醫(yī)療問題。它們通常不會白己消失，為消除這些問題，需要許多專業(yè)的“治療“方法， 軟件項目的問題有點兒像嚴重的醫(yī)療問題。它們通常不會自己消失，為消除這些問題，需要許多專業(yè)的“治療“方法。軟件項目一旦啟動，通常沒有固定、可靠的指導性方法來判斷項目實際進展速度。長期以來，民用軟件行業(yè)一直使用特定里程碑的方法來確定項目進度，比如設計完成或編碼完成等。但是，這些里程碑也是出了名的不靠譜。
軟件項目狀態(tài)跟蹤需要涉及以下兩個彼此不相關的問題:：(1)達到具體、確定的里程碑；(2)在明確的預算金額內(nèi)消耗項目資源和資金。由于軟件項目里程碑和成本受需求變更和“范圍鑒延”的影響，當這些變化影響了功能點總數(shù)時，對需求變更的規(guī)模增長進行度最就變得非常重要。然而，正如本章上一節(jié)提到的.某些稱為“需求波動”的需求變更不影響功能點規(guī)模總數(shù)，而需求蔓延和需求波動往往又都隨機出現(xiàn)。需求波動比需求蔓延更加難以度量，往往只能通過程序派代碼語句數(shù)量和功能點指標之間的“逆火分析”或者數(shù)學轉(zhuǎn)換來進行度量。
截至2009年.已有許多可用的自動化工具幫助項目經(jīng)理記錄項目里程碑報告所需要的各種重要信息。這些工具能夠記錄項目進度、資源、規(guī)模變化以及各種項目問題。對于一個具有60年悠久歷史的行業(yè).卻沒有一套通用的或普遍的項目里程碑來標示項目實質(zhì)性進展情況，這多少有些令人吃驚！