注：以下論文范文來源于信管網考友(論壇用戶名：llll7753)的分享【查看他的備考經驗】

論信息系統(tǒng)項目的范圍管理

背景段(500字左右)

2019年12月，我司中標某行智能客服的重點項目，該項目投資共488萬元人民幣，建設工期為9個月，該項目的背景是基于我國新基建建設重點項目，優(yōu)化經濟結構、轉換增長動力，助推智能客服加速滲透，以銀行金融業(yè)為代表的新基建產業(yè)對智能客戶服務呼叫中心的述求尤為旺盛，通過該項目的建設，成功實現了從人工客服向智能客服的轉型，實現該行信息化工作的智能化。

客服是鏈接企業(yè)和客戶的重要紐帶，極大影響著企業(yè)的銷售成果、品牌形象。但客服行業(yè)人員流動性大、員工普遍教育水平低、培訓難度大、重復性勞動嚴重、客服效果難以評估等問題一直令客服在企業(yè)綜合對外業(yè)務及it建設中處于相對弱勢地位。為了提高客戶體驗，降低客服成本，根據某行零售管理部的需求建設智能客服呼叫中心系統(tǒng)，通過人工智能ai平臺建設系統(tǒng)與客戶語音對話的服務能力，建設支持智能檢索的全行級別客服以及業(yè)務知識庫，智能化的座席輔助系統(tǒng)，建立自動客服語音質檢系統(tǒng)，升級現有語音識別調優(yōu)。在實現呼叫中心所具備業(yè)務功能的基礎上，通過智能對話、智能催繳、智能報表、視頻服務、智能機器人和智能質檢等功能的應用，提高服務效率，豐富服務渠道，提升客戶體驗。

由于我之前剛負責完成某知名企業(yè)的智能客服項目，因此順理成章的被公司委任作為項目經理負責了該重點項目的建設。雖然項目時間緊，客戶要求高，任務繁重，但通過項目團隊的共同努力，歷時9個多月，在2020年9月底項目按質按量交付給客戶，并運行穩(wěn)定可靠，獲得客戶的好評。

項目整體基于b/s和c/s混合架構，oracle11gr2數據庫，采用微軟.net體系，開發(fā)環(huán)境采用visual studio 2012，硬件采購了hp品牌dl360g10服務器，語音引擎選用了國內最先進的sdk產品;運用雙機熱備技術，保證系統(tǒng)穩(wěn)定性，7x24小時不間斷運行。最后為了避免信息孤島，本系統(tǒng)還需要和行內已有系統(tǒng)實現信息交互，進行數據交換，實現流程貫通、數據共享。

過渡段(150字左右)

該項目的主要特點是關聯業(yè)務系統(tǒng)較多(涵蓋零售部，催收部，信息科技部，電子銀行部等)，涉及的干系人多(內部干系人包括項目組成員，公司領導和相關部門人員，外部干系人不僅包括某行各科室，也包括對應接口的相關人員，軟件供應商等)，接口較為復雜，調試和測試工作繁重。因此在本項目實施中，范圍管理顯得尤為重要，本人按照公司已有組織過程資產，根據項目要求，嚴格按照項目管理規(guī)定管控項目，和項目干系人充分溝通，和團隊成員密切協作，計劃為綱，監(jiān)控執(zhí)行，動態(tài)調整，組建了強矩陣的項目組織結構，通過有效的項目管理，特別是出色的范圍管理，帶領項目團隊全體成員經過奮戰(zhàn)獲得了良好的績效，取得了項目的成功，以下我將圍繞該項目的范圍管理進行重點討論。

正文(1500字左右)

一、規(guī)劃范圍管理

凡事遇則立，不預則廢。進行項目的范圍管理也是如此。項目啟動后不久，在了解項目初步范圍的基礎上，我就組織項目成員制定了一個大致的《項目管理計劃》，然后和項目組一起，在《項目管理計劃》的總體輪廓下，依據該項目的章程和項目的初步范圍，制定了《項目范圍管理計劃》(初稿)，為范圍管理的后續(xù)過程提供指南和依據。我們制定的《范圍管理計劃》的大致內容是：如何進行范圍的定義、確認和控制，以及如何進行wbs的分解。

二、收集需求

在定義范圍方面，我花了相當多的時間和精力，目的就是要把項目需求這一源頭搞清楚;在調研需求和定義范圍過程中，我們主要采用的是訪談、會議和原型展示相結合的需求調研方法。初期我們主要采用訪談和會議，我將分析人員分成幾個小組，每組2-3人，各小組根據區(qū)域劃分深入各科室和一線用戶進行深入交流，了解他們的工作過程、存在的問題，以及他們對未來系統(tǒng)的期望等，每個地方駐點一周，每個地點駐點完成后要提交一份調研報告給我，每周(一般是周一早上)所有系統(tǒng)分析人員要召開一次碰頭會，總結和交流需求調研的情況，會后形成匯總的需求調研報告。第一輪調研工作完成后，我們形成了《項目范圍說明書(初步)》，然后我組織開發(fā)人員根據初步的范圍說明書開發(fā)出系統(tǒng)原型，再由分析人員到各單位向系統(tǒng)未來的使用人員進行演示，進行了第二輪的需求調研?？蛻粼谶@一輪的需求調研中表現出了較高的積極性，提出了很多建設性的意見，我們匯總這些意見后形成了《項目范圍說明書(2.0版)》。

三、定義范圍

根據2.0版的范圍說明書，我再次組織開發(fā)人員進行原型開發(fā)，如此反復了幾次之后客戶對系統(tǒng)的需求基本定下，我找建設方的項目經理和分管領導對《項目范圍說明書》進行了簽字確認，后續(xù)的變更就需要走變更流程才能對其進行修改了。同時我們也編制了一份《系統(tǒng)需求規(guī)格說明書》，作為項目組內部設計及后續(xù)開發(fā)、測試等的依據。在《項目范圍說明書》中我們以客戶能懂的語言描述了系統(tǒng)所要實現的功能、項目過程中需要提交的交付物、項目的驗收標準、約束假設條件和項目的進度里程碑等。另外，我們對系統(tǒng)不實現哪些功能、不提交哪些交付物也進行了明確說明。

四、創(chuàng)建wbs

《項目范圍說明書》得到用戶確認后，我們進行了wbs分解。wbs的分解是一項非常重要的工作，好的wbs結構能使得原來看起來非?；\統(tǒng)、模糊的項目目標一下子清晰起來，使得項目管理有依據，項目團隊的工作目標變清晰。由于wbs分解涉及到將要開展的具體工作，所以將來要做這些工作的項目成員最有發(fā)言權，我讓小組的組長和骨干成員都參與到wbs的分解中。實踐證明這樣做既符合后續(xù)軟硬件設計、編碼、實施人員的實際水平，又能得到他們最大程度的認同。我們進行wbs分解時制定了如下原則：在各層次上都保證項目的完整性;一個工作單元只從屬于一個上層工作單元;相同層次的工作包應有相同性質;工作單元應便于進行進度和成本的控制;工作包一般不大于80小時;采用滾動規(guī)劃，不求一次把所有工作包都分解出來。據此我們的wbs分成四層，第一層是按照子系統(tǒng)劃分的，包括十四個子系統(tǒng)和項目管理;第二層是按定義需求、設計、編碼、測試、驗收等生命周期來劃分的;第三層是對第二層的進一步細化，比如定義需求又分成需求調研、需求分析、需求定義和需求驗證等;第四層是對第三層的進一步細分，比如需求調研又分成客戶現場訪談、會議、建立原型等。對于wbs中工作單元的細節(jié)信息，我們在wbs字典中加以描述。wbs分解是一項很重要的工作，在這一過程中我們發(fā)現《項目范圍說明書》中存在較多不明確的方面，通過wbs分解而得到明確。wbs分解工作完成后，項目范圍基準就確定了。

五、確認范圍

項目可交付成果、子功能被開發(fā)出來之后，我們項目組內部先對其進行評審和測試，通過后，把這些成果交付給用戶，和用戶一道按范圍基準、質量標準等要求進行確認范圍(即驗收)。由于該項目范圍廣、功能點多，我們找客戶進行局部確認范圍的頻次較高，在里程碑點一般舉行較為正式的會議，非里程碑點一般通過當面交流的方式，雖然這樣做增加了不少工作量，但對于最后一次性通過竣工驗收非常有利。在確認范圍時，對于局部確認范圍，我們主要是邀請客戶方、監(jiān)理方參與評審和測試;對于全局確認范圍，主要是由客戶方邀請第三方(按照該市政府的規(guī)定，為市金融行業(yè)專家組)進行評審。

六、控制范圍

控制范圍就是監(jiān)督項目的范圍狀態(tài)，管理范圍變更的過程。該項目用戶范圍廣、功能多的特點決定了該項目在開發(fā)過程中避免不了范圍的變更，在項目一開始我就很清楚，如果不做好范圍的控制，該項目很難在合同規(guī)定的時間內完成，預算也必然超支，所以項目一開始我就高度重視范圍的控制工作。開始時我主要是在與客戶簽訂的合同上下功夫，將經過客戶方確認的《項目范圍說明書》作為合同的附件附上，同時在合同正文上明確范圍變更的審批權限(即ccb由哪些人組成)和變更進行的流程;在項目進行過程中，果然有很多人提出這個那個新需求，要求添加進去，我讓他們提交書面申請，說明經過批準之后才能實施，開始的時候很多人認為我們很難講話，開始不配合工作，我拿出很多時間與他們溝通，說明這樣做是為他們好。經過苦口婆心的說明，部分客戶有所好轉，但有部分客戶很難講話，我的工作一度陷入困境，這個時候我一方面對哪些“刁難的人”采用剛性的合同來“說話”，但更多的還是用“柔性”的溝通來解決存在的問題。功夫不負有心人，到項目結束的時候，大家都理解了我的做法，說我“做事很穩(wěn)，有路數”。

該行智能客戶服務呼叫中心系統(tǒng)項目于2020年9月全部上線并順利通過了用戶的驗收，在合同規(guī)定的日期前圓滿完成了各項任務，至今運行狀況良好，得到用戶的一致好評。在本項目的范圍管理中，我總結了如下幾條經驗：事先要有明確的計劃作為指導;關于范圍控制方面，一定要在項目正式開始前與用戶就變更的審批權限和變更的流程達成一致意見，最好能寫進合同中(或簽訂補充協議作為合同的一部分)，在項目進行過程中一定要嚴格按照變更的規(guī)定流程進行，要死死的扛住，多用溝通來化解客戶的不理解;必須在《項目范圍說明書》上多花一些時間，比如，把范圍確認(驗收)的標準事前就在《項目范圍說明書》中盡量說明清楚，并且經過客戶確認，這樣可以避免客戶當事人(特別是銀行金融部門的人)“不敢輕易簽字”的問題;wbs的分解最好讓執(zhí)行候選工作任務的當事人參與，因為唯有參與，才有認同。

項目雖然取得了不錯的成績，但也存在需要改進的地方，如：對項目邊界之外可能會有哪些工作描述得還是比較粗糙，如果能在《范圍說明書》中對不應該包括在項目范圍之內的工作描述得更細一點，就可以很輕松地排除客戶的一些變更要求，避免一些無謂的爭執(zhí);在范圍確認環(huán)節(jié)，常常因為客戶忙，不能及時參與而耽誤了不少時間，對于這個問題，應該找客戶方的領導，讓領導清楚地知道，客戶方的項目經理是需要投入很多時間在該項目上的，讓客戶方的項目經理專職(基本上很難)或將項目的工作納入其主要(至少也是重要)工作事項和績效考核中，這樣項目經理才有時間和積極性參與到項目中。

牢記不足，吸取教訓，相信通過不斷的積累和不懈的努力，我的信息系統(tǒng)項目管理能力一定可以得到不斷提高。