有時候我們會突然發現自己的項目正在走向注定的死亡。下面這些迹象可以讓你提早發現項目失敗的趨勢。
在數月内三次更改項目名稱。
項目經理決定，與其寫一個國際化的單一版本還不如針對某個國家寫一個完全獨立的版本。
需求定義釋出于開發工作開展 4 個月後。
新聘請的r&d主管紙上談兵地表示，該項目将比計劃提前 6 個月完成，并且自吹自擂地保證無需經過版本測試就可以直接釋出給客戶。
如果你是 web 開發人員，你用 html 文檔打開客戶發過來的壓縮檔案，其網站腳本是需要內建到 web
應用程式中去的。但是你打開 html 文檔，得到的竟然是 microsoft word 檔案，以 html 格式儲存的 microsoft
word 檔案。
你發現公司之是以聘請你做顧問，是為了當兩個競争部門在關于使用哪種技術平台的問題上發生争執時，讓你去做調解工作的。
備忘錄上面說，你需要在一個 16 位的平台上開發一個 64 位的應用程式。
開發人員不了解 spec 文檔，反正在做開發工作了就行；qa 團隊不知道如何測試，反正亂搞一通就算測試過了。
關于項目預算，如果你發現超過一半的費用是花在網頁設計師建立首頁的 ps 模型上——而不去考慮這種設計方案是否可行。或者你注意到成千上萬行内容将放在首頁上。
使用者或者客戶要求添加新的功能，而不是集中注意力解決 bug 修複和性能增強的問題。
有一個軟體開發最佳實踐的清單，然而你一條都沒有使用。
項目平台由 windows 變為 ms-dos。
項目經理要求你寫一個關于使用者要求的比較，但是卻沒有咨詢任何潛在使用者。
将筆記存到檔案中而不是互相發送，這些筆記成了即将到來的失敗的借口。
狀态報告被視為是在違抗指令。
新的 cio 用他老東家那裡的外行人替換了這裡所有了解組織架構知識的人。
這是一個很大的項目，代号冰山。或者為了能順利成功，經過再三研究，項目命名為了鳳凰。不過真的很難說服自己這項目真的能夠鳳凰涅槃——浴火重生。
即使是免費版本，客戶也深表不滿。
關鍵任務項目（掌握了 80％ 的公司收入）的 pm 需要經過三個月的接觸才能确定技術首選，同時還要一次性教育訓練四個全新的開發人員。而此項目的最後期限則隻給了三個月。
你認識到在管理上必須堅持：在第一次代碼當機後必須審查接口定義，然後放入版本控制。
更換了 pm 并将項目從這個城市挪到了另一個城市。
qa 團隊被告知，“我們隻配置設定到三個星期的測試時間”，或者，“日期已經定死了，我們必須在截止時間之前完成所有功能”。
項目經理決定嘗試靈活方法“以節省時間”。
手機和網際網路的影響：如果你在 new york 聘請了一位新的 pm，然後去參加了為期三天的 frankfurt 地區的封閉式
cio 會議，那麼你回來她絕對會直接變成咆哮帝：因為她發過去的 email 你通通沒有回複（實際上你并不知道），也不知道她新的項目規劃。
管理層決定花一百萬美元去建設兩萬元的項目。
首席開發人員告訴你，儲存所有資料庫更新的完整曆史記錄是應用程式的要求，但是他還沒有來得及（其實是：不知道如何）去設計一個資料模型。于是他決定等以後再說。
業務上司/項目投資人假惺惺地說，“隻要有創意什麼支援都有。”再看前面：剛剛裁掉了 20％ 的員工，以及将已經回收的硬體又拿出來使用，然後告訴你這是項目新的托管環境。
來源：51cto