在開發過程中，內部管理還要注意的一點是時刻強調以驗收為目的的思想，每個任務的最終可交付成果一定要是可以被檢查的，比如，【界面要求：美觀大方、簡潔明快】，這個要求我就不知道如何檢查。所以，給開發小組布置任務的時候就要考慮如何檢查結果，比如我見過一個計畫，裡面有一個任務【開發人員熟悉ejb編程】，這個任務，除了讓這些人去參加一些專業認證考試，否則，結果很難被檢查。所以，時刻考慮如何檢查結果、如何向客戶交付是項目經理工作一直要注意的事情，我聽說有些老項目經理工作拿到項目是倒排計畫的，即首先看如何驗收和驗收標準，然後決定項目經理工作計畫。很多項目開始了很久，還不知道如何驗收，那么這個項目出問題的可能性就很大了。做項目就是為了驗收，我們的角色不是研究機構，我們的目的就是在付出那么多勞動後得到結果。另外我插一句：我是極其不主張到客戶現場開發的。尤其是一大群技術人員直接和客戶交流，很容易引起衝突和矛盾(技術人員的本性決定的)。我的做法是項目經理工作和項目實施人員到現場，軟體開發人員還是在公司做項目。項目實施人員就是初級項目經理工作，他們了解自己的產品，懂得一些客戶的業務，關鍵是在於他們具有良好的溝通能力，俗稱“皮厚”。他們是客戶和研發人員的橋樑，其職業方向也是很機動靈活，以後可以有很多方向可以轉，比開發人員的路要寬得多。
接著，我們再談談最讓人頭痛的需求變更問題。變更通常分為兩種：一種是部分更改了原先的目標，即需求變更;另一種是沒改變目標，但是客戶不滿意目前的實現方式，大到流程的實現，小到界面的布局，都是屬於這類。碰到這種情況是難以避免的，主要是事先溝通的不夠充分和客戶隨著項目的進展，慢慢想清楚了問題，改變了以前的思路。這時候，如果需要改並且你的戰略是容許這種情況的，那么注意下面幾點：
1、確保以前的文檔，就是記載著以前的結論的東西，客戶是否簽過字，如果沒有，趕緊把你的工作停下來，趕快再和客戶自己確認一下你的方案，然後讓他簽字，避免以後說話沒有憑據;2、和客戶坐下來，自己探討他修改的根本目的是什麼，是不是有同樣能達到相同目的，但是對你來說有代價更小的選擇?3、(項目初期的工作)明確更改流程，一般是客戶指定一人簽字(否則客戶每個領導都有權力來插一槓子，你就廢了)，以正式項目檔案的方式提交給你，然後，你做評估分析，分析對成本、進度的影響，在你的領導同意後，出相應意見書，主要是要說明更改設計的原因和指出由此帶來的不確定後果(這個東西先寫出來，後面如果真的發生了，至少不是你的錯)。然後再讓客戶在上面簽字。見過醫院給病人做手術以前讓家人簽的免責條款嗎?對，就學習那個，讓大家都意識到任何的更改都有成本和代價。