最佳實踐:不要盲目的將最佳實踐作為必須遵守的戒律，但可以作為生成自己最佳方法的起點。
1.正式的風險管理
2.對接口達成一致的意見。包括硬件接口，軟件接口已經你的系統同外部系統之間的接
3.同行評審。包括檢查，走查，評審等等。雖然這些概念眾所周知，但團隊由于這些活動將減慢項目的速度，因此它們在死亡之旅項目中常常被忽略。雖然大多數人在理智上都同意同行評審非常有用，但在死亡之旅項目的那種沉重壓力下，每個人都會考慮盡快的完成自己的工作，而壓根想不起需要其它團隊成員來評審自己的工作產品。
4.基于度量的進度和管理。這就是我們應該依據以往項目的度量結果來安排進度和進行估算。但當我們沒有出現死亡之旅項目的時候，很少有人去注意和記錄這些有用的度量歷史數據。沒有這些歷史數據的記錄，我們就很難在新的項目中做出準確和客觀的估算。
5.多設置短周期的檢查點和里程碑。與其每隔兩三個月設置一個里程碑，還不如按星期或天來設置短期的里程碑或檢查點。迭代開發或Daily Build可以幫助我們達到此目的。
6.項目計劃和項目的實際進度在整個項目范圍內保持透明。
7.針對質量目標進行錯誤跟蹤。這種觀點重點在于盡早的在開發過程中發現，跟蹤和記錄問題。不僅能夠預測最終系統的缺陷水平，還可以用最小的花費來解決問題，而不用一直等到項目的系統測試階段。
8.配置管理。不管是被稱為版本控制或源代碼管理，配置管理在大多數壓力巨大的項目中都是必須的。
9.以人為本。必須要對項目和團隊成員給予足夠的重視。
?
最差實踐:相對最佳實踐而言，往往慘痛的教訓更讓我們記憶猶新。避免災難往往比追求完美更加重要
1.如果采用相似項目的統計結果來作為比較標準，不要期望進度的壓縮程度大于10%。
2.不要為了壓縮進度而接受新技術。(新技術引入的學習成本和使用風險往往大于其對生產率提高所做的貢獻)
3.不要強迫大家在項目中使用那些與具體用戶相關的解決方案。
4.不要鼓吹萬能方法。(在管理層建議采用某中新工具或方法來拯救項目時必須注意)
5.項目的關鍵路徑上存在著依賴于外部因素決定的活動
6.參與項目評審的一大堆人在評審開始前都不做任何相關的準備(因此也不要期望有很好的評審效果)
7.如果軟件功能的縮減量小于10%，就不要期望能從超過10%的進度滯后中恢復過來。