對於專案內部的因素造成專案的成敗卻是與專案經理的素質和管理是密不可分的，大多數專案經理在專案管理中存在以下四個失誤：
1、 需求把握不好：沒有控制好需求，使需求陷於反覆變更之中，既浪費了專案的時間，有容易使開發工作失去重心。有這麼一個例子：我做的車輛年費徵收系統的專案裡，有一個收費折免功能，稽查隊、車管所、路橋處都會用到，只是折免許可權不同，最開始專案組在車管所調研，車管所提出折免介面應該輸入免去多少金額，等這項功能做好以後，拿到稽查隊去，而他們提出折免介面應該輸入折後實收多少金額，後來到了路橋處就要輸入打幾折，專案組為這項功能反覆變更了三次。正確的做法應該是，在確定某項需求時，要把與這項功能相關聯的所有客戶的需求都收集起來，提出一種合適的解決方法，然後得到與這項功能相關聯的所有客戶的確定，有時候需要讓客戶自己先到達一致，然後再與客戶確定需求。
2、 做事欠條理：條理清晰是做管理的基本要求，條理不清晰容易使工作迷失方向，抓不到重點，做事沒有條理大多是沒有認真作計劃造成的。有這麼一為專案經理，有一天，本來要稽核測試報告的，可是客戶一個電話要變更一個需求，他馬上匆匆忙忙到客戶那裡討論需求，回來後馬上要做這項需求的開發人員根據變更的需求更改程式，而這項需求剛好做了測試，測試報告還沒有來得及稽核。這樣既浪費測試人員的時間，又使做這項需求的開發人員沒有根據測試報告及時修正程式。正確的做法應該是：自己繼續稽核測試報告，派做這項需求的開發人員與客戶交流，開發人員回來後，與開發人員、測試人員一起討論需求的變更，同時根據測試報告形成一個修正方案，開發人員再進行修改程式。
3、 專注做專案中的某項工作而沒有看到專案全域性：專案經理如果沒有全域性觀念，就不能及時覺察到專案中出現的種種跡象，從而發現可能出現的問題。其實有很多事情，如果在剛有苗頭時及時採取措施，是完全可以避免的。一個專案的成功是專案整體的成功，如果嚴重影響專案的風險沒有避免，哪怕專案經理做的模組做得再好也於事無補。原來自己負責一個教育資源管理系統得開發，由於自己也是技術骨幹，負責系統的核心模組教育資源存取的開發，自己整天沉浸於自己負責的模組的開發中，沒有覺察到做系統管理的開發人員由於情感問題情緒低落，還一味根據自己的進度對他進行加壓，在他做了70%時，他主動提出離開專案組，而且由於我的不懂人情對我產生了怨恨而帶走所有原始碼，這件事對專案產生很大影響。
4、 配置管理混亂：大凡在專案開始時，大家還比較清楚各自所做的工作產品的版本和更改情況，但時間一長，東西一多就會混亂。有許多開發人員認為嚴格的配置管理太麻煩，有時偷點懶覺得沒關係，其實到了出現問題時，就後悔莫及。我就在做教育資源管理系統時由於開始都是個人自己管理自己做的模組的文件與程式碼，等一個模組全部做完了再提交給測試人員進行測試。由於做系統管理的開發人員帶走了所有原始碼，我這裡什麼都沒有，我真的後悔死了。
另外，一個成功的`專案有以下四個特點：
1、 依著一個目標前進：一個專案必須有一個統一的目標，要使得整個專案組向這個目標前進。其實在一個專案組中，每個專案成員可能有自己的小算盤，有的想通過做專案學習新的技術，有的更注重獲得經濟效益，也有的想積累專案經驗，這樣需要專案經理把大家的精力集中到專案的方向上來。我做過一個多媒體教室的專案，其中專案組有兩個小夥子很有上進心，喜歡鑽研技術，不喜歡作細緻完備的工作，於是我把系統所用到的技術分為幾個主題，每一週召開一個主題的研討會，在研討會我就給他們講任何先進的技術並不在於其本身的先進，而在於其應用的先進性和完備性。一個程式設計師的技術水平的高低並不只是由於他掌握了先進的技術，正如《賣油翁》所說的高手其實就是唯手熟而。後來在開發中這兩個小夥子積極性很高，而且做事也越來越認真細緻。
2、 讓規章說話：專案組在容易出現爭執或難以控制的地方制定合理的規章制度，按規章辦事雖然不能保證樣樣是好的，一般可以保證70%是正確的，同時可以避免專案組有些矛盾的激化。尤其在與客戶確定需求時，必須制定一套確定客戶需求的規章，不能哪個客戶說什麼就作什麼，在專案組和客戶之間按照一定的規章來確定需求，這樣做，就不存在專案組的某個人得罪了某個客戶。我在做一個進銷存系統時，由於在現場開發，如果沒有一套確定客戶需求的規章，一個客戶跑過來講一個自己的想法，不一會兒另一個客戶跑過來講一個自己的想法，會使整個專案開發工作都難以進展，於是我們在第一次與客戶交流時就與客戶制定了確定需求的規章，並且打印出來人手一份，規章裡規定客戶有一個確定需求的負責人員，每一個需求及需求更改必須以書面形式，並且有負責人員簽字，專案組才予以承認，到專案組後，必須有專案經理的簽字或授權認可，這項需求才成為正式需求，開發人員才進行程式更改。這樣雖然不能保證100%按照規章執行，但可以杜絕大多數的因為需求變更而出現的問題。
3、 按照計劃行事：凡事預則立，不預則廢。制定合理的專案計劃，就是讓專案組的每一個成員在專案中的任何時間都知道自己應該作什麼，如果一天不知道自己該幹什麼，就浪費了一天，一個小時不知道該幹什麼，就浪費了一個小時。其實有很多專案的延遲，都是平時一天一天的浪費，一個小時一個小時的浪費造成的。我做專案，一般三個月以上的，專案計劃精確到周;另外每一個專案組成員都要制定個人工作計劃，不要詳細，心裡明白就行，個人計劃必須到天，至少可以保證不會浪費一天。
4、 按照條例檢查：對於工作產品的質量檢查和軟體測試，必須先制定需要檢查的和測試的條例，然後按照條例進行檢查和測試。這樣可以做到有的放矢，事半功倍。我接觸到有這麼一個專案組，該專案組開發的系統已經開始運行了，但存在很多bug，於是專案組招進了三個測試人員，這三個測試人員沒有多少測試經驗，對系統也不瞭解，業務也不熟悉，專案經理給每個人分配一臺電腦，裡面裝有一套專案開發的系統，對他們說：這個星期，你們對這套系統進行測試。一個星期到了，專案經理來檢查，發現他們除了發現幾個介面上的錯誤外，沒有發現什麼bug，專案經理埋怨他們工作不盡力。其實他這種做法好比拿一個古董給一個外行人去鑑別真偽，不知道從何下手，既浪費時間，又沒有什麼效果。我做專案的一般做法是：對於質量檢查，質量保證人員根據專案的質量標準和公司的相關規範列出一個質量檢查表，質量保證員根據質量檢查表逐個檢查就行。對於軟體測試，在測試前必須撰寫測試案例，一般測試案例的撰寫都是要根據前一個工作產品為基準，對於介面測試，我們對每種控制元件都規定若干測試條例，例如下拉列表框，我們需要測試以下幾個方面：回車鍵、tab鍵的選定及焦點的變化，下拉選項的長度和寬度，滑鼠的單擊的選定，無選擇項的選定，滑鼠的滾輪的選擇，關聯快捷鍵的操作，是否可以編輯(編輯的測試條例另外給出)等。測試人員只要拿著測試案例和條例逐個測試，然後把測試結果記錄下來就行了。
專案管理有著很好的理論和實踐，例如iso9000的質量控制體系，cmm的軟體過程改進，美國專案管理委員會提出的專案管理知識體系，我覺得對於一個專案管理人員來說，如何把這些管理理論化為自己做專案中的具體的操作方法和步驟是最為關鍵的。影響專案成敗的因素還有很多，我在自己做專案過程對上述幾點體味最為深刻，希望對大家有所幫助。
