第一篇：信息系統項目的收尾工作

論信息系統項目的收尾工作

軟件項目收尾是軟件項目生命周期的最后階段，是軟件產品準備提交時，軟件項目班子所做的收尾工作。收尾工作常常是零碎、繁瑣、費時、費力的。許多信息系統項目總是無法收尾，甚至在快要驗收時，用戶又提出了新的需求，對已開發的系統不滿意。請圍繞“論信息系統項目的收尾工作”論題，依次對以下三個方面進行論述。

1、概要敘述你參與分析和開發的信息系統項目以及你所擔任的主要工作。

2、概要說明信息系統項目收尾工作的工作內容及工作流程。

3、詳細討論在項目的收尾工作中碰到了什么難題，采取了何種方法和措施，得到了什么經驗教訓。

1、范文寫作思路

[尚大教育軟考學院評注]下面一起來用前文所述的寫作方法來構建寫作思路和寫作提綱。

拿到考卷后，迅速閱讀論文考試試題，以決定寫作哪個論題。

接下來，構思論文要相關聯的項目和寫作提綱。本題準備與論文題目關聯的項目是：“某市政府公文流轉系統項目”。此項目屬于政府辦公用的信息系統項目，主要滿足某市市政府的市領導、政府辦、政府和職能部門的政府內網中的電子公文流轉工作。論文擬從乙方的角度來寫。

[尚大教育軟考學院評注]乙方是指合同中的乙方，常為承包商，甲方常指合同中的外包商；在信息系統項目中乙方指開發公司方；如此處乙方為項目開發公司，甲方為政府方。

考慮好關聯的項目后，開始思索文中的主要論點。項目收尾主要包括兩個方面的內容：管理收尾和合同收尾，工作流程可按公司的項目管理流程來走。收尾工作中常見的問題與對策有：

（1）用戶不斷提需求，在項目進入收尾后還在提出需求變更，在使用了開發的系統后，用戶由于對公文流轉系統認識有了提高又有了新的需求。可采取系統版本控制的辦法，即當前版本定為V1.0，新的需求與用戶協商放至V2.0中完成，先完成V1.0的驗收，部分修改可作變更；和用戶的上級進行溝通，約定一個需求提出的最后時限，以界定需求，減少需求和變更的發生，以早日驗收；和用戶溝通，爭取用戶的理解與支持。（2）用戶不愿意簽字。表現為不愿意在正式的文檔上簽字，希望能讓開發方多呆些時日，以多做一些功能，多發現一些問題，用戶不愿意承擔正式簽字的后果。可給出用戶詳細的維護方案；培養用戶方技術人員達到可維護系統的水平；與用戶上級協商確定可以拍板的人；向自己的上級，公司領導匯報情況，得到公司領導的支持；召開成功的驗收會議。

（3）項目資金遲遲不能到位。政府項目常有這種情況發生。遇到這種情況馬上向公司領導請示，要求出面解決；與公司市場營銷部門協商解決對策；對相關決策人重點攻關。

（4）項目組內部的工作總結。項目收尾了，文檔整理和項目經驗的總結都是十分細致的工作，需要項目經理組織人員細心耐致地去做。可組織一次項目組的正式或非正式會議，暢談項目研發過程中的經驗，會中做記錄，會后做整理；將所有項目的文檔和源程序歸檔。

以上就是論文寫作的基本思路，接下來寫作提綱，即寫段落大意。

[尚大教育軟考學院評注]寫提綱的作用就是要使文章顯得有條有理，表述清晰，論點分明。考生可在草稿紙上來寫，考試時會發草稿紙。“磨刀不誤砍柴工”，寫好提綱后就能對全文有一個整體的把握。考試時，提綱中的論點可以多寫幾點，正文寫作時如果覺得某個論點不好寫可以不寫。

范文的寫作提綱：

（1）項目簡介，以及自己擔任的角色與職責。

（2）項目收尾的工作內容（管理收尾和合同收尾）。

（3）項目收尾的工作流程。

（4）收尾中碰到的問題與對策分析。

問題

1、需求變更的問題；

問題

2、用戶不愿意簽字的問題；

問題

3、項目資金不能到位的問題；

問題

4、如何進行項目組內部的工作總結。

（5）結論。

[尚大教育軟考學院評注]對于問題的討論可以描述問題作為一段，講解采取的對策和實施效果作為一段，或根據需要分段，一般段不宜過長，以不超過10行為。

2、范文全文

[尚大教育軟考學院評注]這里把摘要放在前面以方便讀者閱讀，考試時提倡摘要寫作的時間放在正文寫作之后。

論信息系統項目的收尾工作

[摘要] 本文以我作為開發方公司的項目經理主持的某市政府公文流轉系統項目為實例，探討了信息系統項目收尾工作的主要內容，包括合同收尾和管理收尾；給出了該項目的實施收尾的工作流程；針對在該項目在收尾階段中出現的需求變更、用戶不愿意簽字、項目資金不能到位、如何進行項目組內部的工作總結四個問題，詳細討論了它們的解決辦法。項目最終成功地收尾。

[尚大教育軟考學院評注]“針對在該項目在收尾階段中出現的需求變更、用戶不愿意簽字、項目資金不能到位、如何進行項目組內部的工作總結四個問題，詳細討論了它們的解決辦法。”改為“該項目在收尾過程中也出現了一些問題。對于需求變更的問題，采取了版本控制、與用戶溝通及爭取用戶方領導協商的辦法；對于用戶不愿意簽字的問題，在了解真實原因的基礎上，對癥下藥；項目資金不能到位的問題主要是爭取了公司領導和市場營銷部的支持，共同攻關；并在驗收后在項目組內部進行了認真的總結。”，如此表述全文的論點更為清晰。[正文] 2004年，我作為公司方的項目經理主持了某市政府公文流轉系統項目的研發工作，該項目主要完成某市政府（地級市）的市領導、政府辦公廳、下屬40多個部辦委局的工作機構之間的電子公文流轉和電子簽名工作，項目從啟動到成功收尾歷時10個月，順利地達成了項目的標。這個項目由于是客戶方是政府機關，涉及的方方面面較廣，收尾比較困難，但我們采取了相應的措施，在項目組內部和外部收尾工作都進行得有條不紊。

信息系統項目的收尾是項目生命周期的最后階段，是軟件產品準備提交時，項目班子所做的收尾工作。收尾工作常常是零碎、繁瑣、費時、費力的。

收尾過程是項目干系人和客戶對最終產品進行驗收，使項目或項目階段有序地結束的過程。許多軟件項目在尚未完成之前就被取消了，但項目收尾仍然是重要的，因為通過項目收尾可以總結出經驗教訓，能夠改進未來的項目。項目收尾包括合同收尾和管理收尾兩部分。管理收尾涉及為了使項目干系人對項目產品的驗收正式化而進行的項目成果驗證和歸檔，具體包括收集項目記錄、確保產品滿足商業需求、并將項目信息歸檔，還包括項目審計。

管理收尾對降低信息系統項目失敗率有重大的意義。為什么會失敗？有什么地方可以改進？獲得了什么經驗？對一系列的問題應進行分析，總結得越多，資源就越豐富，能形成適合企業自身的成熟的管理模式，以降低信息系統項目管理風險和管理成本。合同收尾就是了結合同并結清帳目，包括解決所有尚未了結的事項。合同收尾需要對整個采購過程進行系統地審查，找出進行本項目其它產品或本組織內其它項目采購時值得借鑒的成功和失敗之處。

在某市政府公文流轉系統當系統開發完成并經過一個月的上線測試后，系統已基本穩定地運行了，我覺得已經進入可以開始收尾的時機了。于是我先是用《驗收報告》（是我公司寫的文檔模板）給客戶觀看，做到雙方心中有數；然后開始細致地梳理相關的問題，準備移交的文檔資料、軟件程序清單等資料；在收尾過程中與客戶方保持了持續的多次溝通；最后舉行了一場正式的驗收會議，邀請雙方的領導及項目組成員、相關單位的領導參加，完成了驗收工作；在項目組內部也組織了一些正式的會議和非正式的談話，編寫的項目總結報告。

當然，在項目驗收的過程中也碰到了不少的問題。

“用戶需求的變更是不會變的”，項目要收尾了，需求還在變。主要是因為使用了開發的系統后，用戶由于對公文流轉系統認識有了提高又有了新的需求。系統使用的單位本就比較多，每個單位提一點就相當多了，而且有的還提出了與公文流轉無關的業務需求。

對于需求在收尾時還在變更的問題，并不能不允許變更，而應是把變更控制在可接受的范圍內。在本項目中，我從以下幾個方面入手解決：一是運用版本控制的方法，向用戶聲明，當前的軟件是Version1.0的（或者是某一版本的），不可能包羅萬象，哪些功能我們將放在下一個版本中去實現，作為開發方，不能一味的答應下來，否則很有可能會限入變更的反復，被其束縛；二是取得用戶的理解，對不甚合理的地方作出解釋，讓其知道我們做出了多大的犧牲去幫助他們實現愿望，爭取談判和開發上的主動性；三是和用戶方的領導小組進行了協商，統一定了提出需求的最后期限，大大減少了變更的數量。

在項目進行驗收的過程中，我發現用戶并不喜歡在正式的文檔上簽字。經過仔細的調查，找出了原因，原來用戶希望能讓開發方多呆些時日，以讓公司方多做一些功能，自己多發現一些問題，用戶方普遍不愿意承擔正式簽字的后果。對此，為了消除用戶心中的顧慮，我讓項目組花些時間細心地給用戶準備了詳細的維護方案和手冊；特別留意在每個單位培養了至少一名用戶方技術人員達到可維護系統的水平；為了保證簽字的有效性，經與用戶方領導小組協商確定了簽字責任人，有的在領導小組就可以解決簽字的問題；同時我也向公司的領導做了匯報，讓公司領導與用戶方領導小組有橫向的接觸；最后組織召開一次成功的驗收會議，雙方的領導、項目組成員及用戶單位的領導都參加了會議，最終獲得了用戶的一致肯定和高度評價。

項目在驗收會議表示驗收通過會，項目的資金卻遲遲不能到位。資金沒有到位，說明收尾還沒有完成。我馬上向公司領導進行請示，請求支持，并向公司市場營銷部門要求協助，共同重點攻關。本項目標的并不高，只有100萬，但用戶方財務手續審批繁鎖，造成了時間上的延時，經用戶方領導小組組長的拍板，最后在驗收通過的第20拿到了合同規定的款項，并保持了和用戶的良好合作關系。

項目只是更大范圍的組織環境中的一部分，許多對項目的影響因素不是為項目經理所控制的。項目經理對管理事務常不熟悉，因為在國內項目經理大都是由程序員成長起來的，需要公司領導的培養和指導。在收尾工作，象客戶款項的收繳、項目結束時的會談、客戶關系出現危機等許多場合下是需要公司領導的支持和參與的。在一個公司領導很重視的環境下，收尾工作會是更為出色的。

通過驗收了，拿到資金還不能說項目收尾成功了。在項目組內部還要進行認真的總結。，文檔整理和項目經驗的總結都是十分細致的工作，需要項目經理組織人員細心耐致地去做。可組織一次項目組的正式或非正式會議，暢談項目研發過程中的經驗，會中做記錄，會后做整理；將所有項目的文檔和源程序歸檔。

項目總結是項目可持續發展的必要，也是對項目和項目組成員的尊重。當前項目的經驗對其它項目是有很好的借鑒意義的，特別是對類似的軟件項目，在管理上、技術上、開發過程上都是一筆財富。不僅要對項目的程序代碼存儲，所有相關文檔資料（包括合同、開發文檔、總結文檔等）也要歸檔。

我比較傾向于在飯桌上和同事們談經驗來總結，一是大家完成項目了，代表公司要表示慰問，另一方面在這個時侯談感想談經驗是最好的時機，大家話也比較多；在談話后我編寫了項目總結報告，總結了同事們的各種觀點，為今后其它項目的開展提供了知識積累。“不斷地學習改進”，我把它作為自項目團隊的工作信條。

總之，信息系統項目的收尾是一項需要細致、耐心而微妙的工作。項目的收尾包括合同收尾和管理收尾，在本項目中，出現了用戶需求仍在變更、用戶不愿意在正式的文檔上簽字、驗收后資金不能及時到位、內部項目總結如何開展的問題，都較好地得到了解決，成功地收尾。[尚大教育軟考學院評注] 文章寫作思路清晰，主旨明確。對項目收尾的主要內容、流程，以及碰到的問題作出了論述，扣題較緊，提出的問題在信息系統項目收尾中是常見的問題，針對問題采取的措施亦十分得體。但摘要的字數還稍少了點，可將四個問題的基本解決辦法在摘要中點明。

第二篇：如何做好項目收尾工作

如何做好項目收尾工作

1、要提前或者說提早進入收尾狀態

項目竣工驗收前的分項驗收內容多，如消防、電梯、強配電、供水、環保、電梯、綠化等，這些驗收是要由相關政府部門來進行的，因此項目要提前進入收尾狀態，正常情況下要在計劃項目竣工驗收前3至4個月進入收尾階段。如遇上春節可能要更早。

2、收尾工作包括三大項

這三項工作包括實體收尾、資料收尾和工程量確認。通常的說法只包括實體與資料，但考慮到工程量的確認影響施工方的收尾積極性，因此也要作為一個大項加以重視。

3、收尾前要進行工程完成狀態摸底

在確定了收尾階段起始日后，在起始日前一周要對工程完成的狀態進行全面地摸底，查清楚有哪些項目不沒有完成，有哪些小項還沒有開始，有哪些項目做錯了要進行變更或者說是做錯了，有哪些嚴重的施工質量缺陷。

4、收尾工程狀態摸底應包括以下內容：

1）工程分部分項的完成情況，按承包單位甚至班組進行分類歸納。

2）已完成的分部分項工程的成品保護和運行狀態

3）是否存在完全沒開工的分部分項

4）沒完成、沒開工的分部分項的原因。是否材料采購困難、材料不足？是否專業工種工人缺乏、勞動力不足？是否特種設備、配件不足？是否特種施工工具或機械缺乏？當某些原因發生時，要考慮改設計圖紙來進行。

5）不要忽視小項目，如車庫門、門鎖、路牙石、門牌安裝等一些小項。一些小項目由于特種工人不好找，影響后續工序，所以不能忽視。

6）不要小看現場清理，這也是一個重要項目，而且在清理后要設法維持整潔狀態。

7）各種邊角部位的收口。在統計未收口的同時，要弄清楚未收口的原因，如還有項目沒做沒完成收不了口、單純是收口沒做、分包單位做不了如弱電燃氣管穿墻板管洞的封堵、施工合同的空白地帶、交叉地帶或扯皮地帶等。

5、要注意融洽與各承包單位的關系

有些甲方常常與施工方的現場管理人員爭吵，關系搞得緊張，而且還動不動威脅要找其他的施工單位來替代，殊不知這是很難實現的，而且很容易引起合同糾紛，最后兩敗俱傷。在工程管理中，一定要約束現場管理人員的嘴，不要胡說八道。即使是真要換施工方，也要神不知鬼不覺地進行。

6、制訂消項收尾工作計劃

制訂收尾工作計劃要注意在收尾工作與裂縫、滲漏等工作區別開來，即便是同時進行也要以完成工程內容優先。

收尾計劃要采取消項計劃的方式，按單元、按部位、按樓棟一項一項地規定完成時間，完成一項消除一項。

7、備有后備勞動力或施工隊

由于房地產項目的設計變更多，承包單價低，施工方在最后關頭總想用拖的方式與甲方談判從而獲取補償。如果甲方不愿意讓步或者施工方獅子大開口，這時就要有后備施工隊頂上。從而確保工程按期竣工和交樓。

8、通過分項驗收、內部驗收、聯合驗收來促進收尾工程

比妨說通過提前電梯驗收、消防驗收、規范驗收來鞭策施工方，也可以搞幾次驗收才通過專項驗收來促進收尾工作。另組織公司內部、聯合監理、甲方，甚至組織沒有質量監督人員的監督下的四方驗收。每次驗收后要把沒完成的工程內容和檢查發現的問題列出來，并限定完成時間。

9、專人跟蹤

將收尾工作計劃任務進行分工，派專人盯著和督促。

10、即時做好工程資料和工程量確認。

工程資料在交樓前是必須完成的，工程量確認有利于提高和保證工人的工作積極性。

11作為項目監理方要積極做好項目收尾工作。

作為監理工作周期的最后一個重要過程，在完成業主委托的質量、安全、進度、投資等目標，同時建設單位具備組織工程竣工驗收條件時，就正式進入項目收尾過程。項目收尾工作是一項不可或缺的工作，雖然項目收尾是工程竣工驗時的最后部分，但并不意味著項 目收尾的各項活動就要拖延到此過程才開始進行。眾所周知，成立的項目監理機構是臨時性，但承擔項目監理公司及項目管理經驗成果對建設單位和公司榮譽的影響是長期的。作為項目的總監理工程師（以下簡稱總監），對項目收尾工作要引起足夠的重視。

一、將監理服務工作堅持到底

隨著工程主體結構封頂，裝修工程接近尾聲，監理機構需要的人員越來越少，但總監仍然要在人數減少的同時確保高效地完成項目。

公司人事部門應會同總監對項目監理機構進行彈性管理，在項目收尾時提前考慮項目監理機構人員的安置問題。為了監理工作的連續性，公司應盡量確保總監完成項目所有工作，或確保至少一名總監副手至始至終處于項目監理機構中。

二、收集整理項目信息資料

在項目收尾過程，由于監理機構的注意力集中在完成項目任務的喜悅和期待新項目的興奮狀態，對記錄、完善項目信息，進行經驗和教訓的總結很容易被人忽視。

工程項目歷史信息是幫助公司項目管理的重要參考資料。每個公司可能對信息文件存檔的要求不同，國家監理規范和其他相關建筑規范對此也作了相應要求，項目監理機構應收集保留以下，但不僅限于以下的內容：

1）項目日記：包括監理日志和旁站監理記錄； 2）項目計劃：包括監理大綱、監理規劃和監理細則； 3）來住函件； 4）項目會議記錄； 5）項目進度控制文件； 6）項目質量控制文件； 7）項目安全控制文件； 8）項目投資控制文件； 9）合同文檔； 10）其它信息；

項目總監應對以上信息資料輸入和保存于計算機中形成電子文本。公司工程部應建立和維護公司整體的計算機信息系統，為需要時可便捷地檢索查找，也為公司其他新開項目和人員培訓提供依據。

三、合同完成情況的收尾

在項目即將完成階段，總監應組織監理機構人員重溫《監理委托合同》，查找是否有為業主服務的漏項，以免引起業主的不滿。合同完成的效果應達到或超過業主的期望。項目總監應積極收回項目尾款。除非公司有特別要求和說明，收回項目尾款應是總監的責任。

四、項目竣工驗收

根據國家現行監理規范規定，總監應組織建設、監理、設計、勘察、施工等單位時進行工程初驗收，應參與和輔助建設單位項目負責人開展工程竣工驗收工作。項目竣工驗收工作至少包括以下四個方面的內容：

1）安排項目竣工驗收會議的日程。

項目竣工驗收會議是建設單位項目負責人組織，各參建單位項目負責人和政府相關部門負責人成立項目竣工驗收委員會共同參加的會議，與會者一旦確定，就應安排會議的召開日期和時間。務必要為與會者留出充足的準備時間，讓他們能夠審閱相關資料。2）分發會議材料

在會議召開之前，總監應代表監理單位簽發《質量評估報告》，編制《項目竣工驗收方案》，并及早發至相關單位。3）召開項目竣工驗收會議

在驗收會議期間，驗收委員會至少應完成以下工作。（1）審查工程質量控制資料是否完整；（2）審查各分部工程是否均已驗收合格；

（3）審查各分部工程有關安全各功能的檢測資料是否完整；（4）現場進行主要功能項目的抽檢工作，應符合相關專業質量驗收規范的規定；

（5）驗收委員會應共同對工程觀感質量進行評價。

會議結束時，驗收人員應確定驗收結論。項目竣工驗收可能得到以下結果之一：

a.合格。工程質量達到設計和規范要求，建設單位同意接受工程。b.有條件接受。即主要安全和功能方面合格，但必須先完成驗收委員會指定的糾正措施項目。c.拆價接受。即工程達不到預期的使用功能，但返工處理不現實或代價太高，甲乙雙方可協調、降低使用功能拆價處理。

d.不接受。經過返修加固處理仍不能滿足安全使用要求的工程，嚴禁驗收，同時表明項目管理工作完全失敗。4）會議記錄

竣工驗收會議記錄是項目監理機構的職責，總監應指定專人負責。在驗收會議結束時應完成記錄，其中需包括重要的驗收意見或行動建議，以及項目驗收會議的結果，驗收委員會成員如有不同于總體結論的意見應予以保留。對需重新組織驗收的項目，應確定再次驗收的日程安排。會議記錄應發于與會者進行審閱各確定，簽字后即時生效。

五、財務核算

總監應配合公司財務人員對本項目進行財務分析和核算，范圍應僅限于本項目，公司總部的管理費用不應在此之內。分析項目使用成本，項目收款狀況，并與公司其他項目進行對比與分析，找出缺陷和不足，總結項目成本控制經驗。同時也為總監的業績考核提供財務依據，財務核算應形成報告，并至包括以下信息： 1）目前項目財務狀況；

2）財務偏差情況：主要與公司在項目啟動前的財務計劃進行對比； 3）解釋與建議：解釋發生財務偏差的原因，說明其合理程度，并為今后新的項目財務控制提出好的建議，完善公司相關制度； 4）分析項目利潤額：評價項目利潤水平是否達到或超過公司平均利潤水平；

六、總結項目經驗和教訓

《監理工作總結報告》是對項目管理成功或失敗的總結性文件，應向建設單位和監理公司提交。《監理工作總結報告》的基本內容： 1）工程概況；

2）監理組織機構、監理人員和投入的監理設施； 3）監理合同履行情況； 4）監理工作成效：

5）施工過程中出現的問題及其處理情況各建議； 6）工程照片（有必要時）；

第三篇：項目收尾管理

項目收尾管理

19.1項目收尾的內容

項目收尾管理是指對項目的最后一個階段----收尾階段進行妥善的管理，以順利結束項目。項目啟動階段需要正規的文檔和工作，項目收尾階段也需要正式地將完成的成果進行移交并將相關的經驗存檔，收尾階段一旦結束，就標志著整個項目的結束。

項目收尾的具體內容主要是項目驗收、項目總結和項目評估審計。

19.2項目驗收

項目的正式驗收包括：驗收項目產品、文檔以及已經完成的交付結果。項目驗收由驗收小組依據合同、行業標準、合同雙方認可的技術規范進行。

系統集成項目需要正式的驗收測試工作以及正式的驗收報告，通常系統集成項目的驗收工作步驟包括： 1)系統測試 2)系統的試運行

3)系統的文檔驗收。系統集成項目應該提交的文檔如下：

① 系統集成項目報告（包括用戶手冊、竣工圖、配電圖等）。② 信息系統說明手冊 ③ 信息系統維護手冊

④ 軟硬件產品說明書、質量保證書等。4)項目的最終驗收報告。

最終驗收報告是確認項目工作結束的重要標志性工作。對于信息系統而言，最終驗收標志著項目的結束和售后服務的開始。

19.3項目總結

項目總結屬于項目收尾的管理收尾。管理收尾詳細規定了項目團隊成員與參加執行項目收尾的其他項目干系人的所有活動、他們之間的相互配合以及有關的角色和責任。管理收尾過程還包括收集項目記錄、分析項目成敗、收集應吸取的教訓、以及將項目信息存檔以供本組織將來使用等活動。項目總結的具體工作如下： 1)收集整理項目過程文檔和經驗教訓。

2)對所有的文檔進行歸類、形成項目總結會議的討論稿。3)項目總結。

19.4項目后評估和審計

項目結束后進行評估和審計

1、項目評估

項目后評估是對項目和項目的所有工作加以客觀的評價。好的項目評估對未來項目的改進很重要。項目評估的內容如下： 1)盈利要求

2)客戶滿意度要求 3)后續項目指標要求 4)內部滿意度要求

2、項目審計

項目的審計應由項目經理部門與財務部門共同進行，對已經列出的支出和收入進行財務審計，對不合理的收入和支出加以分析，為改進項目的管理服務。

3、項目總結評估

一般的項目總結以會議的形式進行，具體內容如下： 1)項目績效 2)技術績效 3)成本績效 4)進度計劃績效 5)項目的溝通

6)識別問題和解決問題 7)意見和建議

19.5項目后評估和審計

通常情況下，系統集成項目不同于其他項目的特點在于后續工作的比較復雜，而且隨著IT服務業的發展對信息系統不再是簡單的交鑰匙工程。越來越多的業主方要求承包方提供較為完備的后續工作支持和服務，而承包方將逐漸發現其中蘊含的商機，從而為后續的工作開展提供雙贏的機會。一般來講，不同信息系統對后續工作的要求是不同的。軟件項目對后續工作的支持要求程度最高，尤其是客戶化定制的軟件更是如此。通常系統集成項目的后續工作要求是： 1)信息系統缺陷的修改 2)信息系統維護和技術支持

對于系統集成項目來說，經常會把一些合同拆成項目實施和技術服務兩個部分。

承建方對項目的責任到什么時間為止？如何保證第三方的技術支持？如果雙方未能就此問題達成一致，將很可能造成后續工作的矛盾。例如系統的免費維護期有無系統的升級和更新？升級和更新的成本有誰承擔？就此問題承建方的服務部門應與業主事先協商（最好在合同中明確），給出雙方都易于接受的方案。3)信息系統的新需求

收集業主對于信息系統的新的要求和建議，這些新的需求將帶來新的項目機會。

19.6項目團隊人員轉移

項目結束后，項目團隊解散。其人員面臨新的任務，項目經理應事前主動了解項目成員的歸屬并感謝他們對項目的貢獻，以便于將來的合作。

第四篇：信息系統項目管理師項目收尾常考問題及案例實例

首先要知道項目收尾的含義：項目收尾包括合同收尾和管理收尾

1、合同收尾是按照合同約定，項目組和業主一項項的核對，檢查是否完成了合同所有的要求，是否可以把項目結束掉，也就是項目驗收。

2、管理收尾是對于項目內部來說的，把做好的項目文檔等歸檔，對外宣稱項目已經結束，轉入維護期，把相關的產品說明轉到維護組，同時進行經驗、教訓總結。

項目收尾包含的主要工作：

1、核實項目范圍，項目正式驗收

2、梳理項目合同，處理品合同遺留問題，結款

3、進行項目移交，轉移項目責任

4、整理項目記錄，項目檔案歸檔，完成項目文檔收集整理工作，將所有的項目文件存檔并建立索引目錄

5、進行成果分析，總結經驗、教訓

6、釋放項目資源，迎接新的工作

項目驗收的主要工作：

1、承建方自檢

2、系統試運行

3、技術培訓

4、系統竣工

5、初驗合格

6、項目終驗

甘特圖：也叫橫道圖或條形圖，是一種能有效顯示活動時間計劃編制的一種方法，主要用于項目計劃和項目進度安排。

甘特圖的特點是簡單、明了、直觀，能較清楚地反映工作任務的開始和結束時間，能表達工作任務的活動時差和彼此間的邏輯關系。甘特圖可用于WBS 的任何 層次，其時間單位可以從年到月甚至到日。但甘特圖只能表明已有的靜態關系，而且，對于錯綜復雜、相互制約的各項活動間的關系沒有表示出來，同時也沒有指出影響項目生命期的關鍵所在。這一點不利于合理的組織安排和指揮整個系統，更不利于對整個系統進行動態優化管理。

檢查點：指在規定的時間間隔內對項目進行檢查，比較實際與計劃之間的差異，并根據差異進行調整。可將檢查點看成一個固定的采樣時點，而時間間隔根據項目周期長短不同而不同，頻度過小就會失去意義，頻度過大會增加管理成本。常見的間隔是每周一次。里程碑：完成階段性工作的標志，不同類型的項目里程碑不同。

基線：指一個（或一組）配置項在項目生命周期的不同時間點上通過正式評審而進入正式受控的一種狀態。基線其實是一些重要的里程碑，但相關交付物要通過正式評審，并作為后續工作的基準和出發點。基線一旦建立后，其變化需要受控制。

滾動波式計劃：為了分解到底層的工作包，有些項目可交付物只需分解到下一層，而有些項目可交付物需要分解到多層。當工作被分解到更低的、更詳細的層次時，有助于對這些工作的計劃、管理和控制。然而，過度的分解反而有害。

詳細的分解對于遙遠的將來才能完成的交付物或子項目是不需要的，也是不可能的。一般地，項目管理團隊應該等待交付物或子項目足夠清晰時才制定詳細的WBS.這種技術通常

被稱為滾動波式計劃。該方法的實質是將近期的工作計劃得詳細一些，遠期的工作計劃得相對粗一些。

案例實例

閱讀以下說明，請回答問題1至問題3,將解答填入答題紙的對應欄內。

【說明】

在系統集成項目收尾的時候，項目經理小張和他的團隊完成了以下工作：

工作一：系統測試。項目組準備了詳盡的測試用例，會同業主共同進行系統測試。測試過程中為了節約時間，小張指派項目開發人員小李從測試用例中挑選了部分數據進行測試，保證系統正常運行。

工作二：試運行。項目組將業主的數據和設置加載到系統中進行正常操作，完成了試運行工作。

工作三：文檔移交。小張準備了項目最終報告、項目介紹、說明手冊、維護手冊、較硬件說明書、質量保證書等文檔資料發送給業主。

工作四：項目驗收。經過業主驗收后，小張派小李撰寫了項目驗收報告，并提請雙方工作主管認可。

工作五：準備總結會。小張整理了項目過程文檔以及項目組各技術人員的經驗，并列出了項目執行過程中的若干優點。

工作六：召開總結會。小張召集全體參與項目的人員參加了總結會，并就相關內容進行了討論，形成了總結報告。

【問題1】（5分）

請指出案例中的六項工作中那些工作存在問題并具體說明。

【問題2】（6分）

工作六中，項目組召開了總結會，那么總結會討論的內容可以包含（）、（）、（）、（）、（）、（）。

【問題3】（4分）

項目總結會召開之前，核心技術人員小王產生了抵觸心理，他認為更多時間應該放在技術研發上而不是浪費時間召開會議。并簡要闡述項目經理小張應該如何從召開總結會意義的角度說服小王參加項目總結會。

第五篇：IT項目收尾管理經驗談

IT項目收尾管理經驗談

2013年12月20日 09:24 來源：中國項目管理資源網 作者： 字號

打印 糾錯 分享 推薦 瀏覽量 267

所謂驗收就是對整個軟件開發、建設項目的結果的綜合評價，是軟件系統交付使用前對項目進行評估、認定和總結的過程，包括費用、質量、服務等多個方面，包括對整個系統的運行情況、業務流程重組的有效性、生產運作的效率等方面的一個評估，也是對IT項目范圍的再確認。IT項目的實施，一般包括6個階段，即項目的選型、培訓、業務流程重組、基礎數據整理、會議室試點、切換等，在系統切換后，緊接著的還有一項關鍵性的工作，就是項目的驗收。

IT項目驗收主要是通過對項目全面測試性檢驗，找出項目中可能存在的問題和不足，并進行最后的修正、完善，以使項目保質保量最終交付到用戶單位每個使用人員手中。可以說，驗收是IT項目最后關鍵的環節，它是對項目的實施質量和軟件的可交付性起到“一錘定音”的作用，也關系到IT項目能否平滑順利步入運營期、為企業創造效益，軟件開發服務商能否實現收益標志之一。因此CIO必須高度重視，萬莫輕視。

比如ERP項目，由于其軟件的復雜性、規模性，CIO們可能更多地關注它多變的需求定義、選型、個性化解決方案，卻輕視了項目的驗收工作，而驗收需要大量數據測試、自定義擴展、長時間運行等后才能明辨優劣、成效，但是由于供需雙方受種種原因的影響急需“結賬”，從而使項目驗收從時間、內容、范圍、數量、人員等投入均顯不足，而且由于多數信息化項目的驗收評估標準難以具體量化，常使驗收常流于形式，最終使實施結果不佳。

為何不少IT項目成了“雞肋工程”甚至變成“爛尾工程”?一個重要原因就是最后一個關--“驗收”疏忽大意，沒有把關好，前功盡棄，敗走麥城。對此，作為企業信息官的CIO，負有重要責任。還有，一些用戶單位CIO以為項目實施工作做好了，系統跑起來了，文檔移交了，開發商確認了，還有什么必要大動干戈做驗收？這些想法、做法，源于對驗收的目的、流程、方法和意義缺乏認識，造成一個個延期工程、半生不熟項目或爛尾工程。

一、把握項目驗收的重點內容

可以說，驗收事關項目能否善始善終，悠關全局的成敗，那么CIO如何做好項目驗收？從哪里重點把握？結合理論與實際操作，一般而言，IT項目驗收主要應包括驗收準備、數據移植、系統測試、系統評估4個主要過程。

1、著手驗收階段的準備工作

當單位始要進入驗收時，CIO應著手進行相應驗收的準備工作--向軟件開發商收取軟件開發過程中各階段性文檔，包括需求分析說明書、概要設計說明書、詳細設計說明書、數據庫設計說明書、源程序代碼、可供安裝使用的系統安裝程序、系統管理員手冊、用戶使用手冊、測試計劃、測試報告、用戶報告、數據移植計劃及報告、系統上線計劃及報告、用戶意見書、驗收申請等；然后對這些各類約定的技術文檔和合同中的相關內容進行自查，要徹底了解系統目前完成的情況如何，是否已完成了與開發商達成的各項書面約定以及口頭約定，沒有完成的，如果是書面約定，準備采取什么策略去進一步完成等。

當然，此時CIO做一個詳細的驗收計劃是非常必要的，可以用來作為驗收階段的工作指導，并組織管理層領導、業務管理人員和信息技術專家成立項目驗收委員會，負責對IT項目進行正式驗收。

2、數據移植

如今不少企業都上了OA、CRM等系統，或淘汰老系統，在進行新系統(如ERP或PLM)建設并最終上線時，一般需要將舊系統的原始數據移植到新系統或調用企業原有的OA、CRM等系統內的數據時，則常需數據移植，此時CIO正好可籍此機會檢驗新系統的優劣、匹配性如何。這些應完成以下主要工作內容：

1)制訂數據移植：除了要定義數據收集的格式、范圍、進度外，還要考慮系統接口的影響，并建立數據移植完整性和準確性測試方法以及意外事件處理程序;

2)數據收集：項目實施常涉及到數據收集，應由數據收集小組根據數據收集格式，準確對數據進行收集，以確保數據提供人員了解和掌握對數據收集的各項規定和要求;

3)數據導入并核查結果：項目組成員將數據導入系統，并在導入后按照事先制定的數據移植完整性和準確性的測試方法，對系統中的數據做進一步的核查，確保導入數據的質量;

4)數據移植后要進行適當時間的試運行，檢測、確認數據移植的真實性、準確性和完整性。

3、系統測試

系統測試是項目驗收的關鍵環節，也是CIO最需花心思把關之處。以ERP軟件為例，系統測試具體包括以下5大測試內容：安裝測試、功能測試、界面測試、性能測試、文檔測試等。而其中，功能測試是重點，必須高度重視。

下面結合ERP，重點闡述如何有效進行功能測試，其功能測試的用例設計，主要應注意以下幾點：

1)測試項目的輸入域要全面。要有合法數據的輸入，也要有非法數據的輸入，CIO可以此檢驗系統的抗干擾性如何;

2)要適時利用邊界值進行測試。如“訂單預排”中一般要求預排的數量大于0，那么測試數據可以分別為0，-1，1，100000(一個非常大的正數)，查看單據流轉和控制情況，系統在執行MRP分解、工單下達、車間任務調度等操作是否正確;

3)CIO可不按照常規的順序執行功能操作，查看系統計算的準確性，如倉庫歷史庫存、當前庫存、貨位庫存是否準確;

4)驗證實體關系，實體間的關系有三種：一對一，一對多，多對多。如一個MPS對應多個MRP，一個MRP對應多個車間任務，CIO對此檢驗，看能否對應;

5)執行正常操作，觀察輸出結果的異常性。如CIO刪除某條記錄對排序的影響，或執行審批后，單據的狀態是否改變，報表的打印輸出效果如何;

6)劃分等價類，提高測試效率。要劃分等價類，選擇有代表意義的少數用例進行測試，提高測試效率等等。

4、其它系統測試

除上述的系統測試外，CIO還有必要對系統的其他特性和需求加以測試，這些系統測試也很重要，主要有以下幾種：

1)負載壓力測試，主要包括并發性能測試、疲勞強度測試、大數據量測試和速度測試，一般采用自動化技術分別在客戶端、服務器端和網絡上進行測試;

2)恢復測試，通過模擬硬件故障或故意造成軟件出錯，檢測系統對數據的破壞程度和可恢復的程度;

3)安全性測試。通過非法登陸、漏洞掃描、模擬攻擊等方式檢測系統的認證機制、加密機制、防病毒功能等安全防護策略的健壯性;

4)兼容性測試。通過硬件兼容性測試、軟件兼容性測試和數據兼容性

測試來考察軟件的跨平臺、可移植的特性;

5)性能測試，性能測試主要是測試軟件的運行速度和對資源的消耗。

5、評估整個系統運行效益

作為信息部門的一把手，聰明的CIO應在項目合同上寫明系統試運行2-3月后再來驗收、付款的規定，以爭取主動。CIO的做法主要是錄入1-3月的企業相關經營數據進行核查，目的是利用此段時間來判斷系統上線運行后能給企業帶來哪些積極變化和成效--看它有無促使企業在管理思想、管理模式、管理方法、管理機制、管理基礎、業務流程、組織結構、規章制度、全員素質、企業競爭力、企業形象、科學決策和信息的集成與處理等方面發生一些明顯的改進、提高和創新;企業是否運用ERP系統對整個供應鏈管理中的各相關環節和企業資源實行有效的規劃和控制;通過財務模塊分析，企業在客戶關系管理、市場預測分析、加強財務管理、合理組織生產、資源優化配置、壓縮生產周期、降低物料庫存、減少資金占用、降低產品成本、提高產品質量、擴大市場銷售和實行電子商務等方面有無產生相應的經濟效益等。如果在這些方面，用戶感覺良好，表明系統運行成功，那CIO就可放心正式驗收、簽單付款了。

二、項目驗收的幾大注意事項

CIO把握、核檢了項目驗收4個主要過程了，并不表示萬事大吉，尚需對以下幾大事項高度重視，加以解決，以保證項目和驗收全面順利完成。

1、依據行業標準制定驗收規則。驗收是目前或許是一個比較模糊的概念，業內一直都沒有一個統一的標準，隨意性大。而這種“驗收的隨意性”對于用戶單位來說將是一個致命性的錯誤，產生此類問題的根源就在于CIO常不知道或根本就沒有制定合理的驗收標準，從而導致IT項目在驗收過程中，主次顛倒，忽視了對關鍵業務流程的驗收。因此，只有明確了相關系統項目的驗收標準，才會做到有備而來，從而達到驗收的目的。CIO一定要重新明確、制定每個階段驗收標準和項目總體驗收標準，時刻維護驗收的嚴謹性、權威性和準確性，必要時可請第三方咨詢顧問機構來幫忙把脈把關。

2、把握驗收的時間火候。一般而言，要根據軟件模塊的多少、系統涉及部門人員、投入費用的多少，CIO要在驗收時間上進行更多考量、把控，別急于收尾驗收。大型的ERP項目通常是邊實施邊驗收，一步一步地向前推進，以便一邊發現問題一邊解決問題，但中小型的ERP項目最好是成功切換后，錄入了一個月以上的數據，運行一個月時間，再來驗收。畢竟一個月才是一個小的系統周期，如果小的周期都沒有跑順，就更別說一年這樣的大周期了。如ERP系統能做到平穩運行兩個月以上，能夠準確導出各類月度報表的時候，系統應用和各項業務操作基本正常、順暢，通常而言，可認為系統已達到的效果或者是達到了先前預定的目標，系統項目上線成功了，驗收可算通過了。

3、建立有效的解決沖突機制。用戶、開發商在實施、驗收IT項目過程中難免會發生沖突，造成IT建設偏離軌道。關鍵是事先是否有明確的項目目標和項目要求，是否建立起有效的沖突解決機制。CIO主要是要明確今后雙方責權利關系，可對將來可能發生重大事件或不可抗拒事件所引發可能的實施超期、費用超支、產品價格調整以及服務收費超標等事項、行為及其權責做出預測，并有效約定，從而使信息化項目從一開始就按預定的規道行駛，避免再發意外。因此CIO要快速查找以前問題所在，既然上次合約沒有明確細節，也就意味著可以增加驗收內容，明確細節和進度，從合同中挑出對方的問題，與對方補簽合約，保證項目有效進行。建立解決沖突機制，是為了使驗收更好地執行。