項目管理的總結和反思
項目管理的總結和反思，作為壹個成功的公司，是避免不了總結的，因為在總結過程中，我們是會發現，往前是有什麽優缺點暴露出來，這樣我們就很快的可以完善優化，所以總結反思是必不可少的，下面分享項目管理的總結和反思。
項目管理的總結和反思 篇1
帶項目已經壹年了，在這期間無論從技術上還是管理經驗上感覺自己成長了許多，在整個項目組中，我為項目經理，但同時我也是最辛苦的。但我更享受這種感覺。
現總結下這壹年在項目中是如何進行管理的，希望大家看了能給出好的建議。
首先說明下，因為公司是屬於事業單位，而且裏面的員工大多都是幹了好多年的老員工，所以公司裏平時的工作氛圍並不好，工作非常懶散，遲到現象更是非常嚴重，壹天中有效工作時間能夠保持在5小時就不錯了。當然，我並不屬於這壹類。我曾像領導反映多次這種現象，但領導並沒有給出壹個合理的解決方案。
之前項目組分工的時候，都是給某人分配好任務，然後就不管了，對工期也沒有太多的限制。因為本身員工懶散，公司也習慣了這種懶散的狀態，所以每個項目的工期都會拖得很長。
在我管理項目後，領導和我說需要改變這種狀況，於是我們實行明確的分工制度：
1、項目開始時由我對項目進行拆分，將其拆分為壹個個的小功能點
2、將每壹個小功能。分給項目組每個人，並指定工期。
其實對項目進行拆分並預估工作量是壹個挺困難的工作，當我對項目進行拆分完畢，其大致的實現思路我也基本了解了。
我對項目組成員進行分工，最初公布分工以及工時時，大家都感覺不可思議，因為我分的時間幾乎都很短，大家都認為完不成。但最終，卻是在我估計的時間內完成了。而這個項目，大家對時間的利用率，大家的工作效率有了明顯的提高。
在我管理項目中，我主要做以下工作：
1、和需求對接，進行整體的技術選型與數據庫設計
2、控制項目的進度
3、對項目組成員分工
4、項目創建，核心代碼以及壹些基礎代碼的編寫
到了後面這個項目，公司需求方其實不太負責，基本上整個項目的所有工作都由我們項目組做了，而做好的原型圖也沒有壹個好的反饋。在這推薦壹個畫簡易的原型的工具 Balsamiq Mockups 3，簡潔易用，我壹直在使用。
通過這幾個項目，也發現了些問題：
1、項目組成員之間交流不夠，有的壹個同樣功能的方法，卻寫了不同版本。
2、其中個人覺得最難辦的就是項目組中有個別老員工，工齡都比我長好幾年，有些時候甚至會耍脾氣，開會的時候只會盯著手機。我也沒法去說這種情況，說了只會使關系惡化，當然，像我領導去反映這情況，我也沒幹過這事兒，因為我和領導關系還不如人家。
項目管理的總結和反思 篇2作為公司的高層管理者，總結過去壹年來的工作，妳是不是也有很多話想說？是不是也有過這樣的疑惑？
1、 罰款是沒有用的
對於壹個基層管理者來說，罰款是有用的。對於基層員工，不僅要罰，而且要清清楚楚明明白白的罰。可是如果妳是高層管理者，妳就會知道罰下屬的款是沒有用的。就像小孩子犯錯，父母會滿街追著妳打，當妳成人之後，他們就不會這麽做了。
因為下屬不是機器，尤其是妳管的不是壹些從事實幹的員工，而是下壹級管理者的時候。罰款的效果是很低的。
所有人似乎都認為，罰款是雷霆手段，對方壹定會因為害怕罰款而承擔壹定的責任。其實這是想當然！妳覺得這個手段有用的時候，被罰款者的心態卻是“罰就罰吧，反正罰錢了，妳還想怎麽樣？”根本沒有把教訓放在心上。
2、沒有民主、刻薄之分
民主，其實就是聽從大部分人的意見；刻薄，其實就是聽從小部分人的意見。從表面上看，似乎民主比較安全。其實不然。必須認定壹個事實，大部分人是愚蠢的，聰明的永遠只是少數人。
壹個高級主管如果相信管理要民主，基本上，他幹不了什麽事情。但壹個人如果什麽都刻薄，他也幹不了什麽事情。
所以，壹個高級主管，要有內斂的氣質。要懂得，有些事情，要擺上臺來，搞民主的樣式。有些事情，要放在心裏，暗中進行。
3、人才就是那些不聽話的人
壹個人，如果非常聽話，這個人，基本上是沒有什麽用的。
只有真正有才幹的人，才會跟妳擡扛，這是幾千年不變的定律。真正有才幹的人都是有傲骨的。他根本不怕妳把他炒了，因為他有才幹，隨便出去又可以找到工作。
高級主管對於日常聽話的人，基本上是不用自己來費心的，因為這種事情基層主管可以輕松解決，不過是照法宣科的事情，有什麽困難？高級主管難就難在，要去收服這些真正有才幹的人。這是主要工作。
4、 看問題，要深壹層思想
壹個人，看到蘋果只想到這是蘋果，這個人是壹個基層員工。
壹個人，看到蘋果會想，這是誰的蘋果，這個人是個基層主管。
壹個人，看到蘋果會想，這個蘋果為什麽在這裏？這個人是壹個高級主管。
壹個人，看到蘋果會想，這樣的蘋果值不值錢，這個人是老板。
5、好人難做
壹個人，要做壞人，其實是非常簡單的。沒有什麽能力的人，才會去做壞人。有能力的人，才試著做好人。做壞人，沒有任何顧慮，對任何人都大呼小叫，強迫員工工作，也不過是壹個狠心，壹把嗓門而已。
壹個高級主管，就是善於做好人。好人難做，是因為妳對壹個人好，所有人都想要妳也對他好。壞人就沒有這種顧慮，妳對壹個人壞，所以人都想著，妳不要對我壞。所以壞人很簡單。
6、善於從大局出發
高級主管，永遠都要明白：什麽事情，輪到妳的時候，壹定都是壹些大問題，都是壹些很難解決的問題。雖然它表面上看起來，可能非常簡單。因為在妳下面還有壹些基層主管，而他們都是輕易不把事情向上報告的，因為妳會追問，會責難。
所以壹個高級主管在做任何決定的時候，要多重考慮。為什麽這麽做？有沒有更恰當的方法？公司如果在這方面有規定，為什麽基層主管不照公司規定做，而要向上傳？是不是公司規定不符合實際情況？其它人對於這件事情的看法是怎麽樣？都是要考慮的。不是只有照本宣科。那是愚蠢的主管的辦法。
7、善於學習和發現
這不僅僅是對高級管理者的要求，對基層管理者同樣如此。只不過高管就像看電影時坐在壹排座位中間的人，他如果起來上廁所，壹旁的所有人都要跟著起身，而坐在最邊上的人上廁所去幾乎不會驚動任何人，原因無他，高管所處的位置決定了他做同樣事情所引發的結果。
基層管理者如果學習力不夠，不能及時發現下屬的優點，影響可能不會太大，或許他依然可以帶領團隊縱橫戰場。但作為壹名高級管理者，如果缺乏學習力和及時發現員工或下屬亮點的能力，對團隊帶來的影響將會是致命的。
壹個團隊、企業，要想長足的發展，陽光、積極的心態必不可少。而隨時及時地發現下屬身上的亮點優點恰恰是陽光心態的壹種很好傳遞。可能只是簡單壹句真誠贊美，便會讓下屬感動涕零，劉皇叔當年長臂輕舒將阿鬥往地上壹放，對趙雲說：叫這孺子幾損我壹員大將。便就這壹個動作壹句話，換來的是子龍其後50年的肝腦塗地。何樂而不為。
8、堅韌、堅韌再堅韌
這是所有略有常識的人都清楚的話題，都知道想成功必須堅韌。然而，之所以大多數人還是僅僅看著別人成功就因為他們只知需要堅韌但不知如何才能堅韌。
世界觀正確了，如果方法論錯誤，依然是無法達成目標。任何人都有心理承受底線，只是有些人底線高些有些人低些而已。如何才能使自己具備堅韌的品質呢？
很簡單，不論是表面看起來多麽困難的局面，多麽絕望的困境，壹定要想方設法的尋找出哪怕壹絲絲扭轉的可能性，相信，這個可能性就像海綿裏的水，只要去找，肯定是有的。然後將這可能性通過可操作性的方案進行擴大再擴大，出口便出現了。這所有的壹切，取決於管理者堅韌的品質。
項目管理的總結和反思 篇3從去年以來，我完整地參與了XXX項目的建設與管理工作，到現在項目已經基本收尾，下壹期的項目也啟動在即，現在有必要總結下該項目的得與失，從而指導下壹期項目的建設工作，犯過的錯誤不要再犯，好的做法需要繼續保持和發揚。
壹、項目成功之處
1、項目進度管理相對較好
本項目的進度管理相對比較好，沒有出現嚴重的進度延誤的情況，主要是由於了實施了周例會+月例會+項目考核等制度。項目團隊在每月末召開月例會，主要是總結上個月的工作目標完成情況，並***同制定下個月的工作目標。為了確保月度工作目標的實現，同時將月度工作計劃分解成周工作計劃，並以周例會的形成來跟蹤和監控項目目標的完成情況。除了月例會和周例會之外，同時對項目團隊進行考核，如果月度工作目標沒有完成就實施考核扣分。精細化的進度管理加上監督和考核機制可以基本保證項目的進度。
2、建立起了壹些管理制度
在項目實施的過程中，針對日常工作中壹些不規範、混亂的地方，制定了相應的管理機制，主要有以下幾個方面：
（1）新業務需求響應機制
新業務需求指的是在項目建設過程中，不包含在項目需求範圍內的，業務部門日常工作過程中提出的壹些關於系統的優化需求。項目團隊原來對新業務需求的處理流程混亂，新業務需求往往存在項目團隊的'頭腦中，過壹段時間之後根本不清楚哪個業務部門提了哪個需求，就算需求實現之後也沒有反饋機制，給業務部門的感知交叉。在本項目實施過程中，針對這個問題專門建立了壹條新業務需求響應機制，當接收到新業務需求之後，需要專門記錄下需求的相關信息，例如需求描述，需求提出人的；接收到需求之後需要立即與需求提出人確認需求，並反饋需求接收到，告知需求的計劃完成時間；當新業務需求開發上線之後，需要向需求提出人發送上線反饋單，告知提出人他的需求已經實現了。
從需求的接收到最後上線後的反饋等環節
（2）上線機制
由於歷史原因，我們項目團隊相關工作的規範性不如BOSS那邊，系統上線這壹塊也沒有規範起來，以前項目團隊想上線就上線，從而系統的穩定性和安全性存在很大的隱患。為了規範系統上線流程，並向BOSS側接軌，制定了上線流程，每月允許上線兩次，上線之前需要提供需求、設計、測試、上線風險評估報告等文檔，並提交上線申請至領導處審批，審批通過之後才允許開放商進行上線，上線完之後需要提交上線跟蹤分析報告。
（3）溝通機制
建立了月例會、周例會制度，每次例會後以會議紀要的形式發出會議上達成的***識，作為後續衡量和評估相關決定有沒有去貫徹和落實的依據。之前項目團隊也會開例會，但是會議達成的需要去解決的問題往往會上說說的好好的，但是會後沒有真正去做，會議成了壹種形式。
（4）系統運營報告制度
項目團隊之前非常不重視系統應用的推廣，往往功能上線之後就算完成了，不會去關註這個功能到底有沒有被用起來，也不清楚整個系統的應用情況。在項目期間，我們建立了系統運營情況每月報告制度，將系統重要應用的使用情況以月報的方式發送給領導及相關人員。
二、項目不足之處
1、對項目合同的把控不足，給後續管理工作帶來隱患
由於公司IT系統的合同由其它部門負責管理，我們部門主要負責具體系統的建設，因此在本項目中對項目的合同關註不夠，對項目的合同內容把控不足。主要體現在以下幾個方面：
（1）合同中的項目的建設內容與當初匯報的建設方案中的內容兩者沒有仔細地核對，有壹些我方希望納入的建設內容結果在合同中沒有體現，最終導致我方與軟件開放商之間的扯皮，軟件開放商會拿合同來說事，這是很致命的壹個問題，說到底關於項目合同是兩個部門之間的銜接出現了問題。
（2）項目團隊成員沒有仔細核實，雖然在看合同時也發現了這個問題，但是由於對方是我公司的長期合作夥伴，這些小問題沒有太多的在意，現在看來這種原則性的問題還是不能忽視。
（3）在簽訂項目合同是，我們公司通常要求包含項目的考核規則文檔，在做本期項目時沒有仔細地考慮好如何進行考核，結果把非常通用的壹個考核規則文檔放入了合同中，但這個通用的考核規則很多地方並不適合本項目，導致在後續實際考核工作中，有些問題由於沒有在考核規則中詳細的描述清楚，導致具體執行起來沒有依據，容易出現扯皮。
2、新業務的開發模式
由於本項目的需求相對比較分散，因此在實施項目時采用的是新業務的開發模式，即壹個個功能模塊依次開發，每個功能模塊都要經歷需求分析、設計、開發、上線等階段，有點類似叠代的開發模式。但是這種模式存在壹些問題：壹是每次叠代劃分的太細，導致幾乎每個月都要經歷需求、設計、上線這些工作；二是這種開發模式導致對系統的整體把控能力不足，可能由於原來相關的壹些功能模塊，本來應該統壹考慮需求和設計的，但是由於人為地把他們分割成多個階段來實現，導致出現顧了當前沒有考慮到將來及對原有功能模塊的影響；三是這種開發模式使得項目經理不清楚整個項目的工作重點應該放在哪裏；
這種開發模式在下壹期的項目中需要改進，不能再采用這種方式了。
3、建設方案設計及匯報能力不足
本期項目的建設方案主要由主管來完成的，理想的情況是方案由我來寫，主管提供壹些指導和意見，這樣我這個角色才算是稱職的。方案完成之後，向領導的匯報工作不是很成功，前後匯報的三次才算通過，這算是壹次很深刻的教訓，需要吸取。
4、需求文檔和設計文檔的規範性
需求文檔和設計文檔的規範性這個問題壹直困擾著我，不僅僅是這個項目，其它項目也存在相同的問題，就當前我所參與過的項目來講，需求和設計能夠做的好的很少。需求文檔和設計文檔應該體現哪些內容，這些內容如何以比較好的方式來表達，才能清晰地描述清楚需求和系統的設計？
5、應用推廣重視度不夠
建設壹個系統的目的是什麽？目的是希望系統能夠為公司帶來價值。那麽如何體現價值？系統通過為公司的業務發展提供支撐能力，從而實現公司收入的增長的方式來體現價值。那麽系統只有真正被業務部門使用起來才能夠發揮出價值。而在本項目的建設過程中，雖然意識到了應用推廣的重要性，但是具體的應用推廣工作還是做的非常不夠，感覺是在為建設系統而建系統，感覺最求的是完成建設任務，至於用不用就不關我事了。