工程項目管理工作總結(jié)
總結(jié)是在某一時期、某一項目或某些工作告一段落或者全部完成后進(jìn)行回顧檢查、分析評價,從而得出教訓(xùn)和一些規(guī)律性認(rèn)識的一種書面材料,它是增長才干的一種好辦法,因此我們需要回頭歸納,寫一份總結(jié)了。你想知道總結(jié)怎么寫嗎?下面是小編收集整理的工程項目管理工作總結(jié),供大家參考借鑒,希望可以幫助到有需要的朋友。
從去年以來,我完整地參與了XXX項目的建設(shè)與管理工作,到現(xiàn)在項目已經(jīng)基本收尾,下一期的項目也啟動在即,現(xiàn)在有必要總結(jié)下該項目的得與失,從而指導(dǎo)下一期項目的建設(shè)工作,犯過的錯誤不要再犯,好的做法需要繼續(xù)保持和發(fā)揚。
一、項目成功之處
1、項目進(jìn)度管理相對較好
本項目的進(jìn)度管理相對比較好,沒有出現(xiàn)嚴(yán)重的進(jìn)度延誤的情況,主要是由于了實施了周例會+月例會+項目考核等制度。項目團(tuán)隊在每月末召開月例會,主要是總結(jié)上個月的工作目標(biāo)完成情況,并共同制定下個月的工作目標(biāo)。為了確保月度工作目標(biāo)的實現(xiàn),同時將月度工作計劃分解成周工作計劃,并以周例會的形成來跟蹤和監(jiān)控項目目標(biāo)的完成情況。除了月例會和周例會之外,同時對項目團(tuán)隊進(jìn)行考核,如果月度工作目標(biāo)沒有完成就實施考核扣分。精細(xì)化的進(jìn)度管理加上監(jiān)督和考核機制可以基本保證項目的進(jìn)度。
2、建立起了一些管理制度
在項目實施的過程中,針對日常工作中一些不規(guī)范、混亂的地方,制定了相應(yīng)的'管理機制,主要有以下幾個方面:
(1)新業(yè)務(wù)需求響應(yīng)機制
新業(yè)務(wù)需求指的是在項目建設(shè)過程中,不包含在項目需求范圍內(nèi)的,業(yè)務(wù)部門日常工作過程中提出的一些關(guān)于系統(tǒng)的優(yōu)化需求。項目團(tuán)隊原來對新業(yè)務(wù)需求的處理流程混亂,新業(yè)務(wù)需求往往存在項目團(tuán)隊的頭腦中,過一段時間之后根本不清楚哪個業(yè)務(wù)部門提了哪個需求,就算需求實現(xiàn)之后也沒有反饋機制,給業(yè)務(wù)部門的感知交叉。在本項目實施過程中,針對這個問題專門建立了一條新業(yè)務(wù)需求響應(yīng)機制,當(dāng)接收到新業(yè)務(wù)需求之后,需要專門記錄下需求的相關(guān)信息,例如需求描述,需求提出人的;接收到需求之后需要立即與需求提出人確認(rèn)需求,并反饋需求接收到,告知需求的計劃完成時間;當(dāng)新業(yè)務(wù)需求開發(fā)上線之后,需要向需求提出人發(fā)送上線反饋單,告知提出人他的需求已經(jīng)實現(xiàn)了。
從需求的接收到最后上線后的反饋等環(huán)節(jié)
(2)上線機制
由于歷史原因,我們項目團(tuán)隊相關(guān)工作的規(guī)范性不如BOSS那邊,系統(tǒng)上線這一塊也沒有規(guī)范起來,以前項目團(tuán)隊想上線就上線,從而系統(tǒng)的穩(wěn)定性和安全性存在很大的隱患。為了規(guī)范系統(tǒng)上線流程,并向BOSS側(cè)接軌,制定了上線流程,每月允許上線兩次,上線之前需要提供需求、設(shè)計、測試、上線風(fēng)險評估報告等文檔,并提交上線申請至領(lǐng)導(dǎo)處審批,審批通過之后才允許開放商進(jìn)行上線,上線完之后需要提交上線跟蹤分析報告。
。3)溝通機制
建立了月例會、周例會制度,每次例會后以會議紀(jì)要的形式發(fā)出會議上達(dá)成的共識,作為后續(xù)衡量和評估相關(guān)決定有沒有去貫徹和落實的依據(jù)。之前項目團(tuán)隊也會開例會,但是會議達(dá)成的需要去解決的問題往往會上說說的好好的,但是會后沒有真正去做,會議成了一種形式。
(4)系統(tǒng)運營報告制度
項目團(tuán)隊之前非常不重視系統(tǒng)應(yīng)用的推廣,往往功能上線之后就算完成了,不會去關(guān)注這個功能到底有沒有被用起來,也不清楚整個系統(tǒng)的應(yīng)用情況。在項目期間,我們建立了系統(tǒng)運營情況每月報告制度,將系統(tǒng)重要應(yīng)用的使用情況以月報的方式發(fā)送給領(lǐng)導(dǎo)及相關(guān)人員。
二、項目不足之處
1、對項目合同的把控不足,給后續(xù)管理工作帶來隱患
由于公司IT系統(tǒng)的合同由其它部門負(fù)責(zé)管理,我們部門主要負(fù)責(zé)具體系統(tǒng)的建設(shè),因此在本項目中對項目的合同關(guān)注不夠,對項目的合同內(nèi)容把控不足。主要體現(xiàn)在以下幾個方面:
(1)合同中的項目的建設(shè)內(nèi)容與當(dāng)初匯報的建設(shè)方案中的內(nèi)容兩者沒有仔細(xì)地核對,有一些我方希望納入的建設(shè)內(nèi)容結(jié)果在合同中沒有體現(xiàn),最終導(dǎo)致我方與軟件開放商之間的扯皮,軟件開放商會拿合同來說事,這是很致命的一個問題,說到底關(guān)于項目合同是兩個部門之間的銜接出現(xiàn)了問題。
。2)項目團(tuán)隊成員沒有仔細(xì)核實,雖然在看合同時也發(fā)現(xiàn)了這個問題,但是由于對方是我公司的長期合作伙伴,這些小問題沒有太多的在意,現(xiàn)在看來這種原則性的問題還是不能忽視。
。3)在簽訂項目合同是,我們公司通常要求包含項目的考核規(guī)則文檔,在做本期項目時沒有仔細(xì)地考慮好如何進(jìn)行考核,結(jié)果把非常通用的一個考核規(guī)則文檔放入了合同中,但這個通用的考核規(guī)則很多地方并不適合本項目,導(dǎo)致在后續(xù)實際考核工作中,有些問題由于沒有在考核規(guī)則中詳細(xì)的描述清楚,導(dǎo)致具體執(zhí)行起來沒有依據(jù),容易出現(xiàn)扯皮。
2、新業(yè)務(wù)的開發(fā)模式
由于本項目的需求相對比較分散,因此在實施項目時采用的是新業(yè)務(wù)的開發(fā)模式,即一個個功能模塊依次開發(fā),每個功能模塊都要經(jīng)歷需求分析、設(shè)計、開發(fā)、上線等階段,有點類似迭代的開發(fā)模式。但是這種模式存在一些問題:一是每次迭代劃分的太細(xì),導(dǎo)致幾乎每個月都要經(jīng)歷需求、設(shè)計、上線這些工作;二是這種開發(fā)模式導(dǎo)致對系統(tǒng)的整體把控能力不足,可能由于原來相關(guān)的一些功能模塊,本來應(yīng)該統(tǒng)一考慮需求和設(shè)計的,但是由于人為地把他們分割成多個階段來實現(xiàn),導(dǎo)致出現(xiàn)顧了當(dāng)前沒有考慮到將來及對原有功能模塊的影響;三是這種開發(fā)模式使得項目經(jīng)理不清楚整個項目的工作重點應(yīng)該放在哪里;
這種開發(fā)模式在下一期的項目中需要改進(jìn),不能再采用這種方式了。
3、建設(shè)方案設(shè)計及匯報能力不足
本期項目的建設(shè)方案主要由主管來完成的,理想的情況是方案由我來寫,主管提供一些指導(dǎo)和意見,這樣我這個角色才算是稱職的。方案完成之后,向領(lǐng)導(dǎo)的匯報工作不是很成功,前后匯報的三次才算通過,這算是一次很深刻的教訓(xùn),需要吸取。
4、需求文檔和設(shè)計文檔的規(guī)范性
需求文檔和設(shè)計文檔的規(guī)范性這個問題一直困擾著我,不僅僅是這個項目,其它項目也存在相同的問題,就當(dāng)前我所參與過的項目來講,需求和設(shè)計能夠做的好的很少。需求文檔和設(shè)計文檔應(yīng)該體現(xiàn)哪些內(nèi)容,這些內(nèi)容如何以比較好的方式來表達(dá),才能清晰地描述清楚需求和系統(tǒng)的設(shè)計?
5、應(yīng)用推廣重視度不夠
建設(shè)一個系統(tǒng)的目的是什么?目的是希望系統(tǒng)能夠為公司帶來價值。那么如何體現(xiàn)價值?系統(tǒng)通過為公司的業(yè)務(wù)發(fā)展提供支撐能力,從而實現(xiàn)公司收入的增長的方式來體現(xiàn)價值。那么系統(tǒng)只有真正被業(yè)務(wù)部門使用起來才能夠發(fā)揮出價值。而在本項目的建設(shè)過程中,雖然意識到了應(yīng)用推廣的重要性,但是具體的應(yīng)用推廣工作還是做的非常不夠,感覺是在為建設(shè)系統(tǒng)而建系統(tǒng),感覺最求的是完成建設(shè)任務(wù),至于用不用就不關(guān)我事了。
【工程項目管理工作總結(jié)】相關(guān)文章:
工程項目管理工作總結(jié)12-10
工程項目管理年終工作總結(jié)04-28
工程項目管理工作總結(jié)11-22
工程項目管理注釋05-27
工程項目管理工作總結(jié)范文08-27
工程項目管理工作總結(jié)模板01-08
工程項目管理下半年工作總結(jié)11-18
工程項目管理個人工作總結(jié)01-27
工程項目管理求職簡歷12-05