1.定義項目成功的標淮
在項目的開始，要保證各方對于判斷項目是否成功有統(tǒng)一的認識。通常，跟緊預定的進度是明顯的成功要素，但是肯定還有其他的因素存在。比如，增加市場占有率，獲得指定的銷售量或銷售額，取得特定用戶滿意度，淘汰一個高維護需求的遺留系統(tǒng)等。
每個項目都需要平衡它的功能、人員、預算、進度和質量目標。我們把以上五個項目中的每一個方面綜合成一個約束條件，必須在這個約束中進行操作，可以在一個規(guī)定的范圍內調整。
在項目早期，要決定用什么標準來確定產品是否準備好發(fā)布了。你可以將發(fā)布標準基于：還存在多少個高優(yōu)先級的缺陷、性能度量、特定功能完全可操作或其他方面表明項目已經達到了目的。不管你選擇什么標準，都應該是可實現的、可測量的、文檔化的，并且與客戶所指的“質量”一致。
盡管可能無意中承諾了不可能的事件，但不要做一個明知不能實現的承諾。坦誠地與客戶、管理人員溝通那些實際成果。任何以前項目的數據都可能成為你說服他們的論據，雖然這對于不講道理的人來說沒有真正的作用。
困難的部分不是寫計劃，而是做計劃——思考、溝通、權衡、交流、提問和傾聽。你用來分析解決問題花費的時間，會減少項目以后會帶給你的意外。
“英寸大小的小圓石”是縮小了的里程碑。把大任務分解成多個小任務，幫助你更加精確地估計它們，暴露出在其他情況下你可能沒有想到的工作活動，并且保持更加精確、細密的狀態(tài)跟蹤。
如果你的團隊經常承擔某種特定的通用任務，你需要為這些任務開發(fā)一個活動檢查列表和工作計劃表。每個檢查列表應該包括這個大任務可能需要的所有步驟。這些檢查列表和工作計劃表將幫助團隊成員確定和評估與他必須處理的大任務相關的工作量。
幾乎所有的質量控制活動，如測試和技術評審，都會發(fā)現缺陷或其他需要提高的可能。你的項目進度或工作細分結構，應該把每次質量控制活動后的修改，作為一個單獨的包括進去。如果不用做任何修改，很好，你已經走在了計劃的前面。
你的團隊成員已經淹沒在他們當前的項目中，如果你想把項目組提升到一個更高的軟件工程能力水平，就必須花一些時間在“過程改進”上。從項目進度中留出一些時間，因為軟件項目活動應該包括幫助下一個項目更加成功的過程改進。不要把項目成員可以利用的時間100%地投入到項目任務中，否則你會驚訝：為什么他們在主動提高方面沒有任何進展。
如果你不去識別和控制風險，那么它們會控制你。在項目計劃時花一些時間集體討論可能的風險因素，評估它們的潛在危害，并且決定你如何減輕或預防它們。
人們通常以日歷時間做估計，但是我傾向于估計與任務相關聯的工作計劃（以“人時”為單位）的數量，然后把工作計劃轉換為日歷時間的估計。這個轉換基于每天我有多少有效的時間花費在項目任務上，我可能碰