1. 在沒有實質的數據和分析的情況下，就接受一個強制的日程安排或完成日期/里程碑日期。 
組織中的某個人公開推測項目將在某一特定日期完成，這樣在無意中整個團隊都會致力于這一期限。也許你的預算周期顯示分配給這一項目的資金需要花費到今年年底或者下一個版本不會得到資金支持。也許項目的利益相干人希望項目能在圣誕節前完成，知道項目已經結束他/她就可以安靜地享受假期?；蛘吒纱嗑褪且驗槔嫦喔扇颂貏e喜歡整數，希望項目能夠在該月一號發布。為什么一個開發團隊會被設定一個主觀的項目完成日期的原因五花八門。過于狂熱的計劃經常導致項目人員配備過度的不幸現實是為什么軟件項目失敗的另一原因。 　　
2. 添加過多的人員以實現不切實際的日程壓縮。 　　
項目經理如何處理過度樂觀的項目計劃?一個常見的反應就是增加項目組成員，增加的成員經常會比完成項目所需的成員更多。這樣不僅會大幅增加項目的成本，還會降低項目質量。讓更多的人參與到項目中會增加錯誤傳達的可能性，也會讓不同部分的代碼整合更具挑戰。此外，Frederick Brooks (1975) 的主張“在延期項目中增加人手只會讓項目更加滯后”是有一些道理的。這些人員通常是從其他項目中調派而來。這會讓其他項目的項目計劃更加滯后并且還要求新的成員能夠趕上資深成員，這樣整體來說生產力是下降的。 　　
3. 未能考慮和調整需求的增長或變化并據此對計劃和預算預期進行必要的調整。 　　
“如果……不是更好么?”這種話有時候是更可怕的，特別是在項目組建的過程中道聽途說而來時。當然，確實需要時間和場所進行頭腦風暴，這些活動應該在第一階段和第二階段開展。實際上，這兩個階段的目的就是要決定一個項目是否可行，以及應用應該具備哪些功能特性。你可以如此考慮這個問題，第二階段幫助你確定所要構建的內容，第三階段則開始構建在第二階段所確定的內容。在這兩個高級階段之間存在一定的重疊，當處于階段三時，對于一個產品發布版本來說，應該已經有了一個清晰的必要功能列表。如果在沒有增加開發時間和預算的前提下就增加功能，需求的增長就會成為問題。實際上，這是在要求在更短的時間內完成更多的工作，這種手段早已被證明無效。取決于其特性和時點，已有需求的變更也有可能成為問題。只要變更發生在某一特定迭代的構建之前，使用敏捷開發方法的項目就可以處理這些明細需求的變更。不過，對于任何會導致代碼返工的軟件架構方面的需求變更幾乎必然會對項目的計劃和預算產生影響。 　　
4. 忽略事實和統計數據的情緒化或”全憑直覺的“利益干系人談判。 　　
或早或晚，我們都會與某個我們參與的具體項目緊密聯系并在該項目的產出之上投入情感。對于許多人來說，該項目可能關乎自己的聲望;項目太大經不起失敗，而這經常會讓我們被我們的情感所控制。當軟件項目的成功或失敗懸而未決導致個人的事業處于危險之中時，任何相關的業務決策很有可能都會受到影響。壓力可以讓人思維混亂，特別是在賭注巨大之時。為了給客戶留下深刻的印象，某個利益相干人可能會要求一個12個月的項目計劃安排，而完全不顧之前類似規模的項目報告均顯示了15個月的生命周期。利益相干人很可能會忽略項目成員的建議，并聲稱他“感覺”項目團隊可以渡過難關。在這種情況下，憑直覺可能是相當不利的并且有可能直接導致項目的失敗。 　　
5. 錯誤，但普遍認為眾所周知的銀彈可以獨自解決項目吞吐量或過程問題。 　　
當其他嘗試都已失敗時，一個常見的方法就是改變策略。這時比較常見的想法就是“我們現在的所作所為一定是錯誤的”以及“我們的競爭對手在做些什么?”也就在這時，“IT銀彈”的思慮可能就會開始在辦公室中蔓延。例如，某人可能會建議組織，需要采用時新的流行開發方法。雖然這可能會將組織引領至一個偉大的方向，但像這樣的決策決不應該草草定論。無論你的組織決定采用哪種開發方法，這也只是實現層面的變化。僅僅是開發方法的轉變并不足以完成開發操作的轉換。 無論做出什么決策，為了能夠成功實施，就需要各方均能接受并支持這一決策，并且需要為項目成員提供培訓，而且所有人都需要為同樣的標準負責。否則，每次啟動新的項目時，你的開發策略就基本相當于等待天空的星辰排列整齊，期盼奇跡發生一樣。如果沒有經過深思熟慮，實現這種策略不僅存在令人難以置信的風險，同時也會減少團隊成員在項目中期提供反饋的機會。