#8：不現實的期望
可能引起開發者和消費者或管理者 之間沖突的原因之一是不現實的期望。在案例分析3-1中，如果不是公司需要那么多時間，Bill沒有理由相信Giga-Quote項目可能在6個月內開發 完畢。Mike沒有糾正這個不現實的期望是問題的主要來源。在其他情況下，項目管理者或開發者會根據過于樂觀的項目日程估計來申請項目資金。有時候他們會 作出不能保證實現的承諾。雖然不現實的期望并沒有自發地造成項目日程的增長，但它仍會形成開發時間過長的假象，這會使事情變得非常糟糕。Standish Group的一個調查表明，貼近現實的期望是保證商業軟件開發項目成功的五大要素之一（Standish Group 1994）。
#9：缺乏有效的項目贊助
高級別的項目贊助可以在許多方面保證項目的高效開發，包括現實的計劃、權變控制，以及新的開發實現操作。如果沒有這樣一種有效的項目贊助，那么其他更高級別的人事管理會在組織里迫使你去接受不現實的后期限，或被迫接受一些削減項目的變化。澳大利亞咨詢師Rob Thomsett說，缺少有效的項目贊助事實上注定了項目的失敗（Thomsett 1995）。
#10：缺乏利益相關者的入伙
軟件開發中所有的主要成員都要入伙該項目，其中包括執行贊助、團隊領導、團隊成員、市場部、終用戶、消費者以及其他所有利益相關方。密切的合作只在所有的利益相關者入伙時才會發生，從而保證了項目的順利進行。
#11：缺乏用戶的參與
Standish Group的調查表明IS項目獲得成功的主要的原因是其用戶積極參與了項目的開發（Standish Group 1994）。
#12：將權術置于本質之上
Larry Constantine四個團隊進行了報道，并稱他們分別具有四種權術中心（Constantine 1995a）。“政治型”團隊傾向于“向上管理”， 即更關注與其上層領導之間的關系。“研究型”團隊專注于偵察和收集信息。“隔離型”團隊以自我為中心，他們會與非團隊成員劃清界線。而“通用型”團隊則每 件事都做一些：他們和上級搞好關系，進行研究和收集信息的工作，并在工作流程中和其他團隊進行協調。Constantine報道稱，一開始是“政治型”和 “通用型”團隊能夠被上級領導重視，但在一年半以后“政治型”團隊被打入冷宮。所以說將權術置于成果之上對高效開發來說是致命的。
#13：一廂情愿的想法
我很驚訝，為什么在軟件開發中有許多問題后都歸結為一廂情愿的想法。你聽過幾次類似下面的說法：
“團隊中沒有一個成員認為他們可以按期完成任務，但他們卻想如果每個人都努力功能，沒有一件事會出錯，再加上幾次幸運的休假，相信他們能順利完成任務。”
“我們團隊還沒有將產品的幾個部分進行融合，但我們會在其他發面進行有效的溝通，而且這些部分之間的接口是比較簡單的，所以應該只要一兩天的時候來修復其中存在的問題。”
“我們以謊報低價的方式和他們簽訂了數據庫子系統的承包合同，而要完成這些任務需要相當的人力資源，這對他們來說是很困難的，因為他們并沒有這方面的資歷，但也許他們可以用更多的精力來彌補經驗上的不足。也許他們可以按時完成任務。”
“我們不需要想顧客展示程序的終原型，我很確定這是他們想要的。”
“這個團隊稱他們會非常努力地按期完成任務，雖然他們在第一個關鍵時間點上延誤了幾天，但我相信他們可以按時完成的。”
一廂情愿的想法不是樂觀，而是閉上了你的眼睛去期望一些根本沒有理由相信其存在的東西。這種想法會在項目的后階段帶來巨大的麻煩。它不僅削弱了有意義的計劃，而且很有可能這項軟件工程有著更多更復雜的問題。
過程
與過程相關的錯誤會降低項目的開發速度，因為他們會浪費人們的智慧和精力。以下列舉一些影響壞的錯誤。
#14：過于樂觀的項目進度
一個要在三個月內完成項目的 人與一個要在一年內完成項目的人所面臨的壓力和挑戰是不同的。過于樂觀的項目進度會使項目被過分重視，削弱了有效的計劃，并縮減了上層開發活動如需求分析 和設計，這將使項目面臨失敗。這還會對開發者連續施加壓力，使他們的士氣和產能受挫。這也是案例分析3-1中問題的一個主要來源。
#15：風險管理不足
有些錯誤可以被視作經典錯誤，有些則只在特定的項目中發生。在經典錯誤中，如果不注意主動地進行風險管理，會將一個快速開發項目變成慢速的。風險管理失敗是普遍的經典錯誤之一。
#16：承包人失職
公司有時候會因為項目太 緊急不能自己完成把項目的一部分交給承包人來做。但是承包人通常會遲交任務，且質量很差，甚至沒有達到指定的要求（Boehm 1989）。當程序的需求不夠確定，或是程序結果設計得不好，那這其中的風險將會在尋找承包人時得到放大。如果與承包人之間的關系處理得不夠好，會降低 項目的開發速度，而不是加快。
#17：計劃不足
如果你不計劃快速地完成項目，那不可能快速地完成。
