在好的情況下，管理軟件項目也是很困難的。不幸的是，許多新項目經(jīng)理實質(zhì)上沒有受到任何就職培訓。這里有20條成功的管理經(jīng)驗供項目經(jīng)理參考。
1 定義項目成功的標準
在項目的開始，要保證風險承擔者對于他們?nèi)绾闻袛囗椖渴欠癯晒τ薪y(tǒng)一的認識。通常，滿足一個預定義的進度安排是明顯的成功因素，但是肯定還有其它的因素存在，比如：增加市場占有率、獲得指定的銷售量或銷售額、取得特定用戶滿意程度、淘汰一個高維護需求的遺留系統(tǒng)、取得一個特定的事務處理量并保證正確性。
2 識別項目的驅(qū)動、約束和自由程度
每個項目都需要平衡它的功能性、人員、預算、進度和質(zhì)量同標。我們把以上五個方面中的每一個方面，要么定義成一個約束，你必須在這個約束中進行操作，要么定義成與項目成功對應的驅(qū)動，要么定義成通向成功的自由程度，你可以在一個規(guī)定的范圍內(nèi)調(diào)整。相關的詳細信息，請參照《創(chuàng)建一種軟件工程文化》（Creating a software Engineering Culture）（Dorset House，1996）中的第一章。
3 定義產(chǎn)品發(fā)布標準
在項目早期，要決定用什么標準來確定產(chǎn)品是否準備好發(fā)布了。你可以把發(fā)布標準基于以下因素：還存在有多少個高優(yōu)先級的缺陷、性能度量、特定功能完全可操作、或其他方面表明項目已經(jīng)達到了它的目的。不管你選擇了什么標準，都應該是可實現(xiàn)的、可測量的、文檔化的，并且與你的客戶指的“質(zhì)量”一致。
4 溝通
盡管有不可能事件的壓力，從不做一個你知道不能保證的。和客戶和管理人員溝通哪些可以實際取得時，要有好的信譽。你的任何以前項目的數(shù)據(jù)會作為說服的論據(jù)幫助你，雖然這對于不講道理的人來說沒有任何可真正的防御作用。
5 寫一個計劃
有些人認為，花時間寫計劃還不如花時間寫代碼，但是我不這么認為。困難的部分不是寫計劃，困難的部分是對這個計劃——思考、溝通、權(quán)衡、交流、提問并且傾聽。你用來分析解決問題需要花費的時間，會減少項目以后會帶給你的意外。
6 把任務分解成英寸大小的小圓石
英寸大小的小圓石是縮小了的里程碑。把大任務分解成多個小任務，幫助你更加精確地估計它們，暴露出在它他情況下你可能沒有想到的工作活動，并且保證更加精確、細密的狀態(tài)跟蹤。
7 為通用的大任務開發(fā)計劃工作表
如果你的組經(jīng)常承擔某種特定的通用任務，如實現(xiàn)一個新的對象類，你需要為這些任務開發(fā)一個活動檢查列表和計劃工作表。每個檢查列表應該包括這個大任務可能需要的所有步驟。這些檢查列表和工作表將幫助小組成員確定和評估與他／她必須處理的大任務的每個實例相關的工作量。
8 在質(zhì)量控制活動后應整改本次工作
幾乎所有的質(zhì)量控制活動，如測試和技術評審，都會發(fā)現(xiàn)缺陷或其他提高的可能。你的項目進度或工作細分結(jié)構(gòu)，應該把每次質(zhì)量控制活動后的修改，作為一個單獨的任務包括進去。如果你事實上不用做任何的修改，很好，你已經(jīng)走在了本任務的計劃前面。但是不要去指望它。
9 為過程改進安排時間
你的小組成員已經(jīng)淹沒在他們當前的項目中，但是如果你想把你的組提升到一個更高的軟件工程能力水平，你就必須投資一些時間在過程改進上。從你的項目進度中留出一些時間，因為軟件項目活動應該包括做能夠幫助你下一個項日更加成功的過程改進。不要把你項目成員可以利用的時間100％的投入到項目任務中，然后驚訝于為什么他們在主動提高方面沒有任何進展。
10 管理項目的風險
如果你不去識別和控制風險，那么它們會控制你。在項目計劃時花一些時間集體討論可能的風險因素，評估它們的潛在危害，并且決定如何減輕或預防它們。要一個軟件風險管理的簡要的指南，請參見文章“Know Your Enemy：Software Risk Management”（Oct.1998）。
1 定義項目成功的標準
在項目的開始，要保證風險承擔者對于他們?nèi)绾闻袛囗椖渴欠癯晒τ薪y(tǒng)一的認識。通常，滿足一個預定義的進度安排是明顯的成功因素，但是肯定還有其它的因素存在，比如：增加市場占有率、獲得指定的銷售量或銷售額、取得特定用戶滿意程度、淘汰一個高維護需求的遺留系統(tǒng)、取得一個特定的事務處理量并保證正確性。
2 識別項目的驅(qū)動、約束和自由程度
每個項目都需要平衡它的功能性、人員、預算、進度和質(zhì)量同標。我們把以上五個方面中的每一個方面，要么定義成一個約束，你必須在這個約束中進行操作，要么定義成與項目成功對應的驅(qū)動，要么定義成通向成功的自由程度，你可以在一個規(guī)定的范圍內(nèi)調(diào)整。相關的詳細信息，請參照《創(chuàng)建一種軟件工程文化》（Creating a software Engineering Culture）（Dorset House，1996）中的第一章。
3 定義產(chǎn)品發(fā)布標準
在項目早期，要決定用什么標準來確定產(chǎn)品是否準備好發(fā)布了。你可以把發(fā)布標準基于以下因素：還存在有多少個高優(yōu)先級的缺陷、性能度量、特定功能完全可操作、或其他方面表明項目已經(jīng)達到了它的目的。不管你選擇了什么標準，都應該是可實現(xiàn)的、可測量的、文檔化的，并且與你的客戶指的“質(zhì)量”一致。
4 溝通
盡管有不可能事件的壓力，從不做一個你知道不能保證的。和客戶和管理人員溝通哪些可以實際取得時，要有好的信譽。你的任何以前項目的數(shù)據(jù)會作為說服的論據(jù)幫助你，雖然這對于不講道理的人來說沒有任何可真正的防御作用。
5 寫一個計劃
有些人認為，花時間寫計劃還不如花時間寫代碼，但是我不這么認為。困難的部分不是寫計劃，困難的部分是對這個計劃——思考、溝通、權(quán)衡、交流、提問并且傾聽。你用來分析解決問題需要花費的時間，會減少項目以后會帶給你的意外。
6 把任務分解成英寸大小的小圓石
英寸大小的小圓石是縮小了的里程碑。把大任務分解成多個小任務，幫助你更加精確地估計它們，暴露出在它他情況下你可能沒有想到的工作活動，并且保證更加精確、細密的狀態(tài)跟蹤。
7 為通用的大任務開發(fā)計劃工作表
如果你的組經(jīng)常承擔某種特定的通用任務，如實現(xiàn)一個新的對象類，你需要為這些任務開發(fā)一個活動檢查列表和計劃工作表。每個檢查列表應該包括這個大任務可能需要的所有步驟。這些檢查列表和工作表將幫助小組成員確定和評估與他／她必須處理的大任務的每個實例相關的工作量。
8 在質(zhì)量控制活動后應整改本次工作
幾乎所有的質(zhì)量控制活動，如測試和技術評審，都會發(fā)現(xiàn)缺陷或其他提高的可能。你的項目進度或工作細分結(jié)構(gòu)，應該把每次質(zhì)量控制活動后的修改，作為一個單獨的任務包括進去。如果你事實上不用做任何的修改，很好，你已經(jīng)走在了本任務的計劃前面。但是不要去指望它。
9 為過程改進安排時間
你的小組成員已經(jīng)淹沒在他們當前的項目中，但是如果你想把你的組提升到一個更高的軟件工程能力水平，你就必須投資一些時間在過程改進上。從你的項目進度中留出一些時間，因為軟件項目活動應該包括做能夠幫助你下一個項日更加成功的過程改進。不要把你項目成員可以利用的時間100％的投入到項目任務中，然后驚訝于為什么他們在主動提高方面沒有任何進展。
10 管理項目的風險
如果你不去識別和控制風險，那么它們會控制你。在項目計劃時花一些時間集體討論可能的風險因素，評估它們的潛在危害，并且決定如何減輕或預防它們。要一個軟件風險管理的簡要的指南，請參見文章“Know Your Enemy：Software Risk Management”（Oct.1998）。