從去年以來，我完整地參與了xxx項目的建設與管理工作，到現在項目已經基本收尾，下一期的項目也啟動在即，現在有必要總結下該項目的得與失，從而指導下一期項目的建設工作，犯過的錯誤不要再犯，好的做法需要繼續保持和發揚。
一、項目成功之處
1、項目進度管理相對較好
本項目的進度管理相對比較好，沒有出現嚴重的進度延誤的情況，主要是由於了實施了周例會+月例會+項目考核等制度。項目團隊在每月末召開月例會，主要是總結上個月的工作目標完成情況，並共同制定下個月的工作目標。為了確保月度工作目標的實現，同時將月度工作計畫分解成周工作計畫，並以周例會的形成來跟蹤和監控項目目標的完成情況。除了月例會和周例會之外，同時對項目團隊進行考核，如果月度工作目標沒有完成就實施考核扣分。精細化的進度管理加上監督和考核機制可以基本保證項目的進度。
2、建立起了一些管理制度
在項目實施的過程中，針對日常工作中一些不規範、混亂的地方，制定了相應的管理機制，主要有以下幾個方面：
(1)新業務需求回響機制
新業務需求指的是在項目建設過程中，不包含在項目需求範圍內的，業務部門日常工作過程中提出的一些關於系統的最佳化需求。項目團隊原來對新業務需求的處理流程混亂，新業務需求往往存在項目團隊的頭腦中，過一段時間之後根本不清楚哪個業務部門提了哪個需求，就算需求實現之後也沒有反饋機制，給業務部門的感知交叉。在本項目實施過程中，針對這個問題專門建立了一條新業務需求回響機制，當接收到新業務需求之後，需要專門記錄下需求的相關信息，例如需求描述，需求提出人的;接收到需求之後需要立即與需求提出人確認需求，並反饋需求接收到，告知需求的計畫完成時間;當新業務需求開發上線之後，需要向需求提出人傳送上線反饋單，告知提出人他的需求已經實現了。
從需求的接收到最後上線後的反饋等環節
(2)上線機制
由於歷史原因，我們項目團隊相關工作的規範性不如boss那邊，系統上線這一塊也沒有規範起來，以前項目團隊想上線就上線，從而系統的穩定性和安全性存在很大的隱患。為了規範系統上線流程，並向boss側接軌，制定了上線流程，每月允許上線兩次，上線之前需要提供需求、設計、測試、上線風險評估報告等文檔，並提交上線申請至領導處審批，審批通過之後才允許開放商進行上線，上線完之後需要提交上線跟蹤分析報告。
(3)溝通機制
建立了月例會、周例會制度，每次例會後以會議紀要的形式發出會議上達成的共識，作為後續衡量和評估相關決定有沒有去貫徹和落實的依據。之前項目團隊也會開例會，但是會議達成的需要去解決的問題往往會上說說的好好的，但是會後沒有真正去做，會議成了一種形式。
(4)系統運營報告制度
項目團隊之前非常不重視系統套用的推廣，往往功能上線之後就算完成了，不會去關注這個功能到底有沒有被用起來，也不清楚整個系統的套用情況。在項目期間，我們建立了系統運營情況每月報告制度，將系統重要套用的使用情況以月報的方式傳送給領導及相關人員。
二、項目不足之處
1、對項目契約的把控不足，給後續管理工作帶來隱患
由於公司it系統的契約由其它部門負責管理，我們部門主要負責具體系統的建設，因此在本項目中對項目的契約關注不夠，對項目的契約內容把控不足。主要體現在以下幾個方面：
(1)契約中的項目的建設內容與當初匯報的建設方案中的內容兩者沒有仔細地核對，有一些我方希望納入的建設內容結果在契約中沒有體現，最終導致我方與軟體開放商之間的扯皮，軟體開放商會拿契約來說事，這是很致命的一個問題，說到底關於項目契約是兩個部門之間的銜接出現了問題。
(2)項目團隊成員沒有仔細核實，雖然在看契約時也發現了這個問題，但是由於對方是我公司的長期合作夥伴，這些小問題沒有太多的在意，現在看來這種原則性的問題還是不能忽視。
(3)在簽訂項目契約是，我們公司通常要求包含項目的考核規則文檔，在做本期項目時沒有仔細地考慮好如何進行考核，結果把非常通用的一個考核規則文檔放入了契約中，但這個通用的考核規則很多地方並不適合本項目，導致在後續實際考核工作中，有些問題由於沒有在考核規則中詳細的描述清楚，導致具體執行起來沒有依據，容易出現扯皮。
2、新業務的開發模式
由於本項目的需求相對比較分散，因此在實施項目時採用的是新業務的開發模式，即一個個功能模組依次開發，每個功能模組都要經歷需求分析、設計、開發、上線等階段，有點類似疊代的開發模式。但是這種模式存在一些問題：一是每次疊代劃分的太細，導致幾乎每個月都要經歷需求、設計、上線這些工作;二是這種開發模式導致對系統的整體把控能力不足，可能由於原來相關的一些功能模組，本來應該統一考慮需求和設計的，但是由於人為地把他們分割成多個階段來實現，導致出現顧了當前沒有考慮到將來及對原有功能模組的影響;三是這種開發模式使得項目經理不清楚整個項目的工作重點應該放在哪裡;