第一篇：論信息系統項目范圍管理

論信息項目范圍管理

摘要：

2011年5月，我作為項目經理，帶領團隊實施了XX油田生產運行管理系統建設項目。該項目投資為380萬元，建設周期為一年。該油田擁有各類油水井9萬余口，分別在其下屬的20個采油廠所管轄的153個采油隊管理，因油水井數量大，各基層單位管理模式不同，對數據建設認識程度不高，造成了油水井現場相關數據管理混亂，給生產運行管理、科研數據收集等工作帶來了不便。為此，立項實施生產運行管理系統建設，將油井設備型號、每日運行狀態，日生產動態數據、油田主要作業情況，進行統一建庫管理，進而加強生產動態數據的統計分析，以提高生產運行管理水平。本文結合作者的實踐，以XX油田生產運行管理系統建設為例，討論信息項目的范圍管理，重點論述編制范圍計劃、創建工作分解結構，以及范圍確認、控制等工作，最后總結分析項目范圍管理的成功經驗，以及項目經理管理方面存在的不足以及需要努力的方向。

正文

2011年5月13日，XX油田生產運行管理系統啟動建設，我有幸擔任項目經理，經過為期近一年的努力，2012年5月1日系統正式上線運行，并通過驗收。項目為軟件開發，不涉及硬件采購集成，總投資為380萬元。系統采用JSP語言開發，B/S架構，中間件為weblogic，后臺數據庫為ORACLE。該項目主要分為四個部分：井場設備管理子系統、采油數據管理子系統、鉆井動態管理子系統、井下作業管理子系統。平臺分為三個應用層級，采油隊負責數據錄入，采油廠負責審核數據，公司層面實現數據統計分析，用于生產運行指揮決策支持。通過系統的應用，客戶方實現了9萬口油水井設備型號、配件型號的電子建檔管理，實現了井場設備運行情況動態監測，油井現場鉆井、井下作業動態、油水井采油動態數據的入庫管理，自動統計分析等功能，減少了各層級統計人員工作壓力，實現了無紙化辦公，大大縮短了故障響應周期，為該公司生產數據有序管理，油水井設備調撥、措施井評價等工作提供了有效支撐，提高了生產運行管理能力。

在本項目建設過程中，除了精心抓好其他管理工作外，我重點加強了范圍管理，因“生產運行”概念較大，只有在項目初期，清楚甲方企業環境因素，明確對范圍進行定義，形成基線，并在項目的進行過程中進行嚴格的控制，才能防止蔓延現象的發生，保證項目按照進度、成本和質量的要求順利完成。項目建設過程中，我特別重視項目的范圍計劃編制、分解，以及范圍確認和控制工作。

1、精心組織編制范圍計劃

明確項目范圍是軟件研發工作順利實施的前提。為了更好的組織范圍計劃編制工作，我充分分析了甲方的企業環境因素，得知生產管理部系該公司生產運行管理的責任部門。生產管理部、采油廠生產科、采油隊工作人員是該系統的主要干系人，我通過問卷調查、會議討論等方式捕獲收集業務需求。經分析，系統建設數據采集方面包括：油水井設備、配件型號信息、生產動態數據，應用方面包括：采油隊、采油廠、油田公司三個層次的動態數據日報表、月報表、年報表，2、井損壞狀態信息統計，3、增油措施評價，4、鉆井、井下作業動態等。明確業務需求后，我帶領團隊從技術角度出發，轉變為技術需求，繼而形成軟件規格需求說明書SRS，范圍管理計劃的編制工作就變得有章可循。

我通過參照甲方專家判斷、應用歷史項目的模板、表格工具，制定了范圍計劃，力求穩步推進詳細項目范圍說明書編制到創建WBS，力求使成果交付和變更事宜更加正式和流程清晰。當然，這些工作的前提是明確范圍定義。

2、從全局出發做好范圍定義

定義詳盡的項目范圍說明書對于項目的成功至關重要。從全局出發做好范圍定義，可以有效防止范圍蔓延。就我所管理的項目而言，甲方生產業務鏈條較長，其成產過程包括：鉆井、錄井、測試、井下作業、采油等多個環節。我采用“德爾菲法”，邀請客戶高層領導、科研人員、生產管理人員，現場工作人員經過反復分析論證，確定了油水井現場鉆井、井下作業（修井及措施）、采油三項生產動態監測的范圍，明確了限定條件和可交付物。此工作雖然耗費了一段時間，但所有項目干系人之間形成了項目范圍共識，提供了一個范圍邊界，對判斷變更起到了邊界作用。

宏觀上三個業務范圍已經明確，我要求團隊就各業務體系縱向上加以分析，進一步明確了通過鉆井、采油的監測，實現數據統計分析；通過井下作業監測，實現設備配件調撥、措施增油效果評價等應用，進而實現提高整體生產運行管理水平的總體目標。

通過宏觀和縱向業務范圍的定義，項目團隊明確了項目目標、范圍、需求、項目邊界以及可交付物等信息，形成了較為詳盡的范圍說明書，下一步工作重點就是將其分解為更小、更易管理的工作單元。

3、科學創建工作分解結構

工作分解結構是組織項目管理工作的主要依據。將項目范圍分解開來，能夠使項目的概況和組成明確、清晰、透明、具體。使項目干系人都能把握和了解項目。在該項目中，我首先按照以往工作分解模板，將項目的建設過程按照生命期進行分解為：確定需求、系統設計、研發、測試、安裝5個階段，同時又將每個階段的工作進行劃分，保持項目的完整性。例如需求，我又將其劃分為數據采集平臺建設需求、統計需求、生產運行指揮需求等。并通過WBS字典加以描述。

在創建分解結構的同時，我將人力資源、資金、進度分解到每個單元，同時我要求各分項負責人要進一步將工作分解細化，確立子項目，將質量管理貫穿于各階段，以便于執行和實現目標要求，保證項目建設科學、有序推進。

4、有序組織開展范圍確認

范圍確認是項目干系人所關注的重點，包括工作分解結構、可交付物、階段成果和最終結果等。范圍確認貫穿于項目的始終，因此，有序組織開展范圍確認是必要的。在本項目每個階段任務完成時，我都組織“檢查”，例如：采油動態數據采集模塊開發完成時，我組織開展了階段審查，向客戶展示了采集界面，講解了產液量、含水率、產油量等數據采集項，及數據單位規范，提交了階段總結，征求了需求

滿意度確認信息等。同時要求團隊認真對待每一個變更申請，及時確定糾正措施，并根據工作進度和變更情況，及時更新WBS和WBS字典，保證每個階段工作經得起檢查，力求每個環節都成為經得起檢驗的里程碑。

5、嚴抓范圍控制

眾所周知，項目建設過程中，變更是不可避免的，為防止范圍蔓延，做好范圍控制尤為重要。對于范圍控制我從三方面嚴抓：一是嚴抓范圍定義，確定邊界；二是嚴抓變更流程，所有變更必須經CCB進行審核，三是，嚴謹確定是否執行糾正。接到客戶的變更申請時，我要求參照項目范圍說明書及階段績效信息，認真開展偏差分析，查找原因。例如：甲方要求采油數據應用“方”和“噸”兩種單位進行量化，究其原因是各基層采油廠計量單位不統一造成的。經團隊分析，此變更不會對系統架構、功能穩定性構成影響，但我方認為統一數據標準是精細化管理的重要內容之一，經協商，甲方采納了我們的意見，數據標準通過系統應用，得以控制、統一。

經過為期一年的努力，系統建設按預期完成，并得到有效應用。實現了油水井設備運行監測、單井采油數據規范管理，生產動態實時掌握，措施評價及時、客觀，為生產運行指揮、科研工作提供了及時的數據決策支撐，受到了該公司的高度評價和認可。

本項目的成功經驗在于：范圍定義準確，邊界劃分清晰，工作分解結構設置得當，并實現了有效的范圍控制。不足之處有：我及我的團隊沒有懂石油專業的技術人員，致使范圍定義有些不便，但中期通過交流和自身學習，得以改善，沒有影響后續工作。這就提示我們項目經理，在今后工作中，要加強客戶方企業環境因素及業務領域的學習，提高自身的綜合素質，才能更好的駕馭本職工作。

第二篇：論信息系統項目管理

論信息系統項目的溝通管理

[摘要]2015年3月，我參與了某市規劃局規劃管理信息系統的項目管理。該系統是以B /S模式架構，數據庫采用了Oracle11g,GIS平臺采用了ARCGIS10.0。該系統包括規劃業務審批，行政辦公，GIS圖形分析等功能，是OA、MIS、GIS 的集成應用。項目歷時10個月，最終較為順利地完成了項目建設。該規劃管理信息系統在市局、八個分局、六個直屬單位全面投入運行，獲得一致好評。本文結合作者實踐，以該項目為例，探討了信息系統項目中的溝通管理，包括編制項目溝通管理計劃，信息分發，績效管理，項目干系人管理等幾個方面，論述了溝通管理在本項目實施過程中的實踐經歷和經驗教訓，認為溝通不暢，干系人不能及時準確的了解項目進展是導致項目失敗的一個重要原因。本文在最后總結了在項目溝通管理方面的經驗和不足。[正文]某市規劃管理信息系統是在為市政務部門及民眾提供相關信息化應用服務和輔助決策性支持，增強城市規劃管理部門的管理水平和領導決策準確性的背景下，于2015年3月啟動的，我公司中標該項目，中標金額為680萬元。根據項目章程，任命我為該項目的項目經理，負責項目的全面管理。項目歷時10個月，于2015年12月在市局、八個分局及六個直屬單位全面運行，通過了客戶方驗收。

該項目旨在建立一套集規劃業務審批、行政辦公、GIS圖形分析、CAD 繪圖編輯于一體的系統。其中，“一書兩證”業務審批的圖件、文檔、表格、會議、材料信息，實現了在市局及八個分局之間的方便快捷流轉，隨著審批流程的流轉，達到了全程帶圖作業，實現了圖文雙向查詢，用戶可以任意查詢每個案件的業務數據、辦理情況、辦理過程以及相關的必備材料信息，同時，可以在審批流程的任意一個環節調用疊加與案件相關的各種地形圖、控規圖、詳規圖、專題圖、影像圖以及各種屬性信息進行分析和對比，實現了業務辦理與圖形瀏覽、分析和計算的緊密結合。系統中的內網信息發布模塊，分為通知公告、政策法規、輿情監測、職工工會四個欄目。內網信息發布模塊，自全面運行至今，內網信息發布百余條。系統中的電子報建模塊，實現了遠程報建及報建文件一鍵錄入。一方面，建設單位通過在市規劃局門戶網站免費下載電子報建軟件，填寫申請表單和上傳報建材料，完成報建項目預錄入并保存為磁盤文件。另一方面，窗口人員根據建設單位提交的磁盤報建文件一鍵錄入系統，避免信息的繁瑣輸入，實現高效、透明、規范的審批目標。

由于該項目具有規模大，周期長，涉及干系人眾多等特點，要保證系統按時上線，溝通管理顯得尤為重要。為保證項目的順利進行，公司采用了強矩陣型組織結構，在對公司成功案例經驗總結基礎上，充分運用項目溝通管理知識，結合發起人的業務需求和公司管理規程，有效保證了甲乙雙方溝通順暢，提升了干系人的滿意度，項目順利完成，獲得用戶方和領導的一致好評。

良好的項目溝通管理對項目的成敗起著關鍵作用，不少失敗的項目案例都是因為甲乙雙方溝通不暢，信息不對稱，而導致了項目的失敗。在本項目中，我通過做好干系人分析，編制詳細的溝通管理計劃；及時全面的信息分發；制定項目績效報告；做好項目干系人管理等工作，對項目進行溝通管理，保障項目工作有條不紊地進行。

一、做好干系人分析，編制詳細的溝通管理計劃

要實施有效的干系人管理，就要盡早識別出項目干系人。因此，項目中標后，我就參照項目章程，項目范圍說明書，列出該項目的主要干系人，登記在“干系人花名冊”中，花名冊詳細記錄了干系人的姓名、職位，在項目中充當的角色，對項目的支持程度，可能對項目產生的影響以及建議的應對措施。項目團隊成立之后，我又帶領項目組成員通過召開頭腦風暴會議，更新了項目干系人花名冊。由于項目涉及市局、八個分局還有直屬單位等機構，有規模大、干系人眾多的特點，我和團隊根據干系人關心的不同內容，將干系人分為三組。第一組干系人有公司領導和市局的主管領導，而市局主管領導又是本項目的發起人之一，需要在項目中及時給他遞送項目的進展情況，以獲得他對整個項目的信任；第二組項目干系人包括各項目組負責人和市局信息中心主任，是項目的直接負責人，他們關心的是項目的具體功能是否符合要求，需要定期分發階段評審的結果。第三組項目干系人關心的是項目質量，要確保項目按質按進度正常開展，要定時召開技術評審會議。

通過多次團隊會議，我和團隊利用項目范圍說明書，項目管理計劃等，結合項目干系人分析，制定了項目溝通計劃。

二、按照溝通管理計劃，做好信息分發

信息分發是向項目干系人及時地提供所需的信息，包括實施溝通管理計劃以及對始料不及的信息需求的應對。按照溝通計劃，實施內外有別的溝通策略，對公司外部干系人，我通過工作會議、郵件、電話等方式及時為項目干系人提供項目進展情況，以獲取對項目的信任。對于公司內部的團隊成員，我利用公司內部的RTX即時溝通軟件作為輔助溝通手段，并于每周五召開周例會，總結上周的工作，計劃下周的工作。在向外部干系人進行信息分發時，我充分注重溝通技巧。在與信息中心主任溝通時，我多采用非正式的溝通方式，采取面對面交流的方式，盡量避免使用專業術語，這樣既可以保證將項目進展及時準確地傳遞給干系人，也有利于建立雙方的信任關系，了解干系人對項目的滿意度。

三、定期發布項目的績效報告

定期發布項目的績效報告主要是為了定時進行工作的匯報。我要求項目組成員每周提報工作情況匯報，包括上周工作完成情況和下周工作計劃。一方面是便于周例會進行工作總結與安排；另一方面是便于跟蹤和控制項目進展情況，每兩周對工作完成情況使用掙值分析，形成項目目前的狀態，進展情況和對未來的預測。項目干系人通過績效報告可以獲得項目在特定時間的進展、資源使用情況等信息。制定績效報告的時候，我還使用了公司績效報告的Excel模板，模板的“總覽報表”為管理高層提供了他們希望看到的規管系統每周概況信息。而“成本報表”提供了項目現金流等信息。我通過及時完成和提交績效報告，使項目團隊成員和項目干系人隨時掌握項目情況，保證項目順利實施。

四、做好項目干系人管理，提升干系人滿意度

項目干系人管理就是對項目溝通進行管理，滿足項目干系人的需求并解決項目干系人間的問題，對公司及市局的主管領導，一定要匯報他所關注的點，如進度問題、成本使用情況，及各單位對于項目的意見和反饋，以期望達到項目重要干系人給予我最大的信任，對市局信息中心主任，各業務部門負責人，主要都是實際業務負責人，對實際業務流程方面有一定的權威，需要采用嚴謹的制度，寬松的工作氛圍和適當的獎勵方法，來提升團隊的積極性。

盡管在項目初期制訂了項目溝通管理計劃，以及在實施過程中嚴格對績效進行跟蹤報告、信息分發和項目干系人管理，但由于溝通對象是人，而且項目中涉及人員眾多，難免會出現問題。比如在對外部的溝通上，主要表現在項目組人員尤其是技術人員溝通能力不足，比如在開發過程中，開發人員就部分功能實現與分局信息中心發生沖突，針對這個問題，我利用項目實施過程中的間隙對項目組人員進行了溝通技巧的培訓，讓他盡量避免使用專業術語。在團隊內部的溝通上，由于有2名剛畢業的大學生，初次參與項目，對做項目不熟悉，也沒有經驗，而團隊其他成員也各自忙著自己負責的開發任務，這兩名團隊成員開始消極怠工，針對這樣的情況，我和各業務負責人商議，在兩周的周例會結尾，安排半小時的項目培訓或召開經驗交流會，如果部門的培訓內容豐富或取得一定效果，則給予一定的獎勵，從而提升了團隊的整體能力。經過10個月的努力，該規劃審批系統終于順利完成交付。至今，系統運行正常，受到客戶有關部門的一致好評。項目的圓滿成功離不開項目的溝通管理。綜上所述，項目溝通管理的理論有效地指導了此次項目的實施，保證了甲乙雙方溝通順暢，提升了干系人的滿意度。通過此次實踐，我對項目溝通管理有了更加深入的理解，為以后的工作積累了寶貴的經驗。

第三篇：項目范圍管理

項目范圍管理

編制范圍管理計劃：

輸入：項目章程；初步的范圍說明書；項目管理計劃，組織過程資產，環境和組織因素 輸出：項目范圍管理計劃

工具：專家判斷，模版表格和標準

范圍定義：

輸入：項目章程；初步的范圍說明書；項目管理計劃；組織過程資產；批準的變更請求 輸出：詳細的范圍說明書；變更請求；更新得項目文檔

工具：產品分析；識別多個可選方案；項目干系人分析；專家判斷

創建WBS：

輸入：詳細的范圍說明書；項目范圍管理計劃；批準的變更請求；組織過程資產 輸出：WBS和WBS字典；范為基準；更新的項目管理計劃；更新的項目范圍說明書；變更請求

工具：WBS模版；分解技術；WBS工作包的格式；波式滾動計劃

范圍確認：

輸入：項目管理范圍管理計劃；項目范圍說明書；WBS和WBS字典；可交付物

輸出：可接受得項目可交付物和工作或（已確認的范圍）；變更請求；更新的WBS和WBS字典；推薦的糾正措施

工具：檢查（審查，審計，產品評審，走查）

范圍控制：

輸入：項目范圍管理計劃；項目范圍說明書；WBS和WBS字典；工作績效數據；績效報告；已批準的變更請求

輸出：新的變更請求；建議的糾正措施；更新得（WBS和WBS字典，項目管理計劃，范圍說明書，范圍基準，組織過程資產)；工作績效

工具：偏差分析；重新制定計劃；變更控制系統和變更控制委員會（CCB）；配置管理系統

第四篇：論信息系統項目溝通管理論文(高項)

信息系統項目管理師 http://

論信息系統項目溝通管理論文范文（高項）

【摘要】

2015年2月初我作為項目經理主導實施了某市某汽車股份有限公司MES項目，該項目投資650萬元人民幣，建設工期為13個月，通過該項目的建設解決了該工廠的多車型多批次小批量混線生產、線邊生產消耗拉動物料需求、供應商供貨管理、高位貨架管理、關重件掃描控制、質量問題追溯、一車一檔等問題，同時和企業的SAP、SRM、QNS系統做集成解決了企業的信息孤島問題。該項目于2016年3月份，通過了業主方的驗收，獲得了用戶的好評，并作為重點試點單位，向其他生產基地推廣實施。

本文結合作者的實際項目經驗，以該項目為例，討論了信息系統建設過程中的項目溝通管理，主要從以下幾方面進行闡述：

1、識別項目干系人，并了解這些項目干系人對項目的收益和影響，誰需要什么樣的信息，什么時候需要。

2、針對不同的項目干系人以合適的方式及時提供信息。

3、收集項目的進度情況、狀態信息和預測信息，編制績效報告。

4、對項目溝通進行管理，滿足信息需求者的需求，并解決項目干系人之間的問題。

【正文】

2015年2月初我作為項目經理主導實施了某市某汽車股份有限公司MES項目。系統上線后通過一系列的拉動關聯，重組和優化了公司的業務流程，構建起采購、供應商、物流倉庫、總裝車間、焊裝車 信息系統項目管理師 http://

間、涂裝車間、沖壓車間之間的內部集成的一體化系統，使整車生產的信息化管理程度和按需配送物料的及時響應度得到了明顯的提高。該項目開發語言采用C#.Net、J2EE，數據庫采用oracle 10g，中間件采用weblogic10，系統采用C/S架構，數據庫服務器為RedHat Linux，應用服務器為windows server2003企業版，開發工具使用eclipse3.0 和Vs2008，其中應用服務器和數據庫服務器硬件均采用機架式IBM X3850系列。

眾所周知，在項目實施過程中，溝通管理占用項目經理工作量將近90%。而且由于本項目涉及到的系統多——需要4個系統做集成，人員廣——涉及到的開發團隊有3個，業務部門有7個，因此，在本項目中，溝通管理尤為重要。在本項目管理中，我作為項目經理除了對其余管理領域進行克制恪守的管理外，特別對溝通管理從以下幾個方面進行了管理。（過渡段）

一、識別項目干系人，了解項目干系人的需求，編制溝通計劃

1、識別項目干系人：項目開始后我作為項目經理帶領項目團隊（業務顧問2人，.Net 開發工程師3人，Java開發工程師2人，SAP開發工程師1人，測試工程師1人，項目配置管理員1人）深入甲方現場并協同甲方召開了項目啟動會，根據項目章程中的公司組織架構了解了參與本項目的各個項目干系人，如：總經理、生產副總、采購部部長、四大分廠廠長、物流部部長、以及關鍵操作崗的業務骨干。會后對項目干系人進行了分析和總結，生產副總負責項目所需資源的總協調，采購部長、四大分廠廠長、物流部部長和相關崗位的業務骨 信息系統項目管理師 http://

干負責需求的提出和系統上線后的具體使用，其中采購部長、四大分廠廠長和物流部長會對項目的收尾和驗收起決定作用，因此我們在做需求和范圍定義的時候必須要充分考慮這個幾個部門的要求。

2、了解項目干系人需求：從事多年項目管理經驗的我深知，需求是龍頭，因此帶領項目成員通過訪談、現場觀察、交流會的方式去挖掘各個項目干系人的需求。經過30多天的時間了解了各項目干系人對系統的功能需求、性能需求，編寫了項目需求文檔說明書，然后召集項目干系人進行需求的確認、評審和高層領導的會簽，確定了項目需求基線，為后期的項目管理確定了基礎。

3、通過以上的項目干系人的識別分析和項目干系人需求的了解，我們確定了項目溝通計劃，確定了溝通的內容、方式、頻次、時間、地點和溝通時需要項目組提供的資料等，如：每周五上午8點在總裝廠會議室以現場會議的方式進行溝通，項目組所有人必須全部參加。項目經理以PPT的方式提供項目績效報告和在項目中遇到的問題，會議記錄以電子郵件的形式發送給項目組所有干系人并抄送給主管副總裁。

二、采取合適的溝通方式把項目干系人的所需信息在合適的時間提供給項目干系人

1、溝通方式和分發方式：在項目實施過程中，為了保證項目組有足夠的工作時間同時為了提高工作效率，我們采取了多溝通相結合的方式進行溝通。如：項目組內部的咨詢顧問2人、開發工程師4人、測試工程師、配置管理員出現問題的時候，我們及時的進行口頭溝通，信息系統項目管理師 http://

盡快的解決問題，事后會把項目中遇到的問題和解決辦法以電子郵件的形式分發。和用戶進行溝通時，我們采用正式的會議的溝通方式并結合文檔，所有的涉及到需求變更的、設計的、進度的、測試的、以及形成的相關決議的等信息必須以文檔的形式分發并歸檔。

2、總結經驗教訓：由于本項目涉及的系統比較多，各種接口眾多，集成度要求高，在項目實施過程中總會出現業務設計和技術實現方面的問題，有時候解決一個問題需要查詢大量的資料才能解決，為了以后再遇到這種問題能夠很快的得到解決，我們在把問題解決后都整理成一個解決方案，并將方案分類是技術解決方案的還是經驗教訓的，將方案加入到我們知識庫中。如：我們的知識庫中已經包含了.NET、J2EE、SAP、Webservice等總計超過15000條的經驗分享，這也是我們項目能夠成功實施的一個寶庫。

三、了解項目進度情況、項目范圍、項目狀態、項目預測等信息，并編制項目績效報告

1、收集項目績效信息：在項目管理過程中，我通過微軟的Project2010 進行項目計劃的管理。每天下午臨下班前半個小時，我會挨個了解當天的項目業務顧問設計情況、開發工程師的開發情況、測試工程師的測試情況和已完成任務的百分比，并在project中更新進度比例。定期收集經過項目內部評審過的設計說明書、測試計劃、用戶手冊等。

2、項目狀態評審：在項目實施過程中，我要求項目組內部每周四下午召開項目狀態評審會議，會議評審相關的接口設計說 明、測 信息系統項目管理師 http://

試用例和測試計劃、用戶手冊等，項目組內成員可以把在項目中遇到的問題提出討論解決，如果不能解決的我會協調公司其他的資源來協助解決。每周五上午和用戶部門召開項目例會，匯報項目績效報告和需求變更請求的討論。

四、與項目干系人進行溝通協調，處理好項目干系人之間的關系

明確問題記錄和溝通方法：在每周和客戶之間的項目例會中，我會把系統中已發現的問題清單列出，和業務部門討論哪些問題需要系統提供功能實現的并明確責任人，哪些問題是屬于管理方面需要改善的，要讓項目干系人清楚的了解項目的進度情況和他們需求是否匹配。將在會議中形成的決議通過電子郵件發給項目干系人，避免由于信息溝通不暢引起的不滿。

【結束語】

經過我們團隊的不懈努力，歷時13個月時間，本項目終于與2016年3月，通過了業主方組織的驗收，本項目的順利驗收，解決用戶企業整車生產多品種共線生產的問題，得到了業主方的好評，同時也為向其他生產基地重點推廣該項目奠定了基礎。本項目的成功得益于我成功的溝通管理。當然，在項目中還有一些不足之處，比如 ：在項目的實施過程中，由于采購的條碼打印機無法打印，后來有供應商從廠家派遣技術人員過來才得到了解決，影響了供應商交付模塊的上線，不過，經過我后期的糾偏，并沒有對項目產生什么影響。在后續 信息系統項目管理師 http:// 的學習和工作中，我將不斷的充電學習，同時進行業務交流，提升自己的業務和管理水平，力爭為我國信息化建設做出自己的努力。

第五篇：項目范圍管理題目

項目范圍管理題目 單項選擇題

1.工作分解結構的基礎是()。

A.產品需求 B.項目需求C.干系人的全部需要和期望D.產品需求和項目需求 2.項目范圍說明書中通常包括以下哪些內容?()A.產品范圍、項目可交付成果、項目進度里程碑、項目除外責任

B.產品范圍、產品驗收標準、項目可交付成果、項目組織結構圖、項目除外責任

C.產品范圍、產品驗收標準、項目可交付成果、項目除外責任、項目制約因素 D.產品范圍、產品驗收標準、項目可交付成果、項目假設條件、項目審批要求 3.核實范圍的主要內容是什么?()A.確保項目可交付成果按時完成

B.通過確保客戶對可交付成果的接受，保證項目不偏離軌道 C.確保可交付成果符合技術規范 D.給人們提供一個發表不同意見的機會 4.以下哪個是收集需求的輸入?()A.項目工作說明書 B.項目章程 C.干系人管理策略 D.采購工作說明書 5.以下關于產品范圍和項目范圍的說法，哪個是正確的?()A.項目范圍服務于產品范圍

B.項目范圍的變化必然引起產品范圍的變化 C.產品范圍的變化必然引起項目范圍的變化 D.產品范圍服務于項目范圍

6.控制賬戶是工作分解結構某個層次上的要素，以便()。A.指定工作的責任人或小組 B.進行掙值管理 C.與工作包一一對應 D.匯總項目的成本數據 7.以下哪個不是項目范圍管理的過程?()A.收集需求 B.創建工作分解結構 C.實施工作分解結構 D.核實范圍 8.用來衡量產品范圍完成情況的文件是()。

A.項目管理計劃 B.項目范圍說明 C.項目工作分解結構D.產品需求文件 9.以下哪項是收集需求過程的工具與技術?()A.控制圖 B.魚骨圖 C.流程圖 D.親和圖 10.下列四個選項中，不屬于備選方案識別技術的例子是()。A.價值工程 B.橫向思維 C.配對比較 D.名義小組技術 11.范圍蔓延是指()。

A.項目范圍的合理延伸 B.產品范圍的合理延伸

C.經過批準的項目范圍或產品范圍變更D.未得到控制的項目范圍或產品范圍變璧

12.項目范圍變更()。

A.也叫做范圍潛變 B.是不可避免的

C.會影響進度、成本等，必須被拒絕 D.應該由項目發起人來審批 13.定義范圍過程旨在()。

A.制訂范圍管理計劃 B.制定項目范圍說明書 C.制定項目工作說明書 D.制定工作分解結構 14.核實范圍過程與實施質量控制過程的關系是()。A.經質量檢查合格的可交付成果才能進行范圍核實 B.經范圍核實符合要求的可交付成果才能進行質量檢查 C.應根據具體需要，先做質量檢查或先做范圍核實 D.質量檢查和范圍核實通常可以同時進行 15.應該在什么階段核實范圍，以保證在可交付成果完成時及時進行驗收?()A.項目執行 B.項目監控 C.項目收尾 D.項目變更 16.系統工程、價值工程、價值分析和系統分析經常用于()。A.備選方案識別 B.可交付成果識別 C.項目制約因素分析 D.產品分析 17.核實范圍過程旨在()。

A.審核項目范圍基準的正確性 B.審核工作分解結構和工作分解結構詞典的正確性 C.審核項目范圍說明書的正確性 D.驗收已經完成的可交付成果

18.以下哪個是控制范圍過程的輸出?()A.工作績效信息 B.工作績效測量結果 C.技術績效測量結果 D.績效報告 19.在整個項目生命周期中，用于監督、核實和控制項目范圍的文件不包括()。

A.項目工作說明書 B.項目范圍說明書 C.工作分解結構D.工作分解結構詞典 20.在項目的環境中，“范圍”可以指()。A.產品范圍和工作范圍 B.產品范圍和項目范圍 C.項目范圍和管理范圍 D.項目范圍和需求范圍 21.以下各項都是收集需求過程的輸出，除了()。

A.需求管理計劃 B.需求識別文件 C.需求文件 D.需求跟蹤矩陣 22.工作分解結構的第一層通常可以是()。

A.項目階段 B.高層次的可交付成果 C.準備外包出去的子項目 D.以上都是 23.下列哪一項最恰當地描述了項目范圍說明書?()A.項目范圍說明書是規劃范圍過程的輸出 B.項目范圍說明書識別項目的目標和可交付成果 C.項目范圍說明書一經制定，就不允許更改 D.每個項目只能有一份項目范圍說明書 24.項目范圍管理旨在確保()。

A.做盡可能多的工作，使項目盡可能完美 B.做而且只做為成功完成項目所需要的工作 C.為客戶提供額外的產品功能 D.確定不包括在項目范圍內的工作

25.以下哪個不是創建工作分解結構過程的輸出?()A.項目范圍說明書B.工作分解結構 C.工作分解結構詞典 D.范圍基準 26你正在管理一個新產品研發項目，要研制出一種永不卡住的拉練。“永不卡住”是屬于()。

A.項目需求 B.商業需求 C.交付需求 D.產品需求 27.項目范圍說明書()。

A.用來記錄項目的主要可交付成果及所需開展的項目工作 B.有助于創建WBS C.用來明確怎樣對已完可交付成果進行正式核實與接受 D.用來指導對項目范圍變更請求的審批

28.收集需求的工具與技術中，通常采取“一對一”的形式的是()。A.訪談 B.問卷調查 C.德爾菲技術 D.引導式研討會 29.以下哪個文件會明確說明那些被排除在項目之外的內容?()A.工作分解結構B.項目范圍說明書C.項目范圍管理計 D.工作分解結構詞典 30.工作分解結構底層的要素是()。

A.控制賬戶 B.規劃包 C.規劃要素 D.工作包 31.在以下哪種情況下，應該采用觀察的方法來收集項目干系人的需求?()A.干系人的數量很少時 B.需要用漸進明細的理念來開發需求時 C.干系人不愿或不能說明他們的需求時 D.需要組建焦點小組時 32.項目需求包括下列所有，除了()。

A.產品性能需求 B.商業需求 C.項目管理需求 D.交付需求 33.以下哪個是收集需求過程的輸入?()A.項目工作說明書 B.項目范圍管理計劃C.干系人登記冊D.干系人管理策略 34.以下哪個是控制范圍過程的輸出?()A.工作績效信息B.工作績效測量結果 C.績效報告 D.質量控制測量結果 35.關于WBS的說法，哪項是正確的?()A.WBS的第一層可以是可交付成果、項目階段或子項目 B.WBS的第一層可以是可交付成果、項目部門或子項目 C.WBS的第一層可以是可交付成果、項目階段或項目活動 D.WBS的第一層可以是項目部門、項目階段或項目活動 36.定義范圍的一個輸入是()。

A.項目工作說明B.需求文件 C.工作分解結構(WBS)D.需求跟蹤矩陣 37.收集需求過程是()。

A.定義并記錄干系人的需求 B.主要關注產品需求 C.主要關注項目需求 D.主要關注性能需求 38.以下哪個最好地描述了工作分解結構(WBS)?()A.WBS是對工作成果的層級分解 B.WBS是對工作本身的層級分解 C.WBS是對項目產品的層級分解 D.WBS是對項目活動的層級分解 39.核實范圍過程旨在()。A.正式驗收可交付成果 B.審查項目范圍文件的正確性 C.檢查可交付成果的技術正確性

D.發現項目范圍偏差，管理項目范圍基準變更

40.你的一個合同商給你發了一封電子郵件要求使用更高質量的原材料，這將會導致費用增加和質量得到提高。項目經理應該首先做什么工作？（）A、更改項目基線

B、要求合同商發一份正式的變更請求 C、詢問你的發起人的意見 D、更改WBS

41、客戶通知你對原始范圍做一項小的變更。與整個項目相比，這是一項很小的投入，并且你需要這個大項目的親善關系。你將：（）A、拒絕做這個工作。B、同意免費做這個工作。

C、做這個工作，然后給客戶開賬單。

D、評估這個工作對成本和進度產生的影響，然后告訴他們你將在晚些時候決定這件事。

42、一個項目的啟動階段輸出不包括下列哪項？（）A、項目章程

B、約束條件

C、產品描述

D、項目經理選擇

43、范圍確認的主要內容是什么？（）A、確保項目可交付成果按時完成

B、通過確保客戶對可交付成果的接受保證項目不偏離軌道 C、顯示可交付成果符合技術規范 D、提供一個發現不同意見的機會

44、關于項目可交付成果，下列哪句是正確的？（）A、項目可交付成果是在完全定義了工作之后確定的。

B、在項目計劃編制期間對項目可交付成果進行描述，然后隨著時間的推 移對它們進行細化。

C、在項目開始時用項目干系人的輸人對可交付成果進行定義。D、項目可交付成果由項目發起人來確定。

45、你正在管理一個為期6個月的項目并且每兩周與你的項目發起人開一次會。在工作了五個半月后，這個項目既符合進度又在預算內，但是項目發起人對可交付成果不滿意。這一情況會把項目完工延誤一個月。可以防止這種情況的最重要的過程是：（）

A、風險監控

B、進度控制

C、范圍計劃編制

D、范圍變更控制

46、除了（）下面所有陳述是錯誤的？ A、WBS傳達每個定義項目活動的日歷日期 B、WBS對每個定義活動的商業需求加以說明 C、WBS向項目干系人傳達定義的項目活動

D、WBS對負責每項定義項目活動的職能經理加以說明

47、產品文件是（）的輸人。A、范圍確認

B、績效報告 C 風險分析

D、范圍計劃編制

48、一個項目經理正在對一項可交付成果實施審計時聽到做這項工作的團隊成員對所有人抱怨說，審計他做的工作是挑他的刺兒。你知道這是不對的。對于今后的項目你應該吸取什么教訓？（）

A、在項目開始時就告訴團隊成員，他們的可交付成果將受到審計。B、在范圍管理計劃中制定一項政策。C、降低審計頻率。

D、用簡單檢查代替審計。

49、在已經建立的績效測量基準計劃之后，客戶要求擴大項目范圍。客戶將需要提交哪類文件？（）

A、變更申請

B、工作說明 C、修改的項目進度計劃

D、發票

50、在一個設計項目開始兩個月后，客戶要求對產品作修改。在沒有通知項目經理的前提下就做了這項變更。在最終測試階段，測試結果與當初計劃的不同。這種情況是下列哪項的例子？（）

A、測試計劃定義不完善

B、質量管理計劃的開發不完善 C、使用范圍變更控制的技能差

D、不堅持溝通計劃

51、下列哪項不是范圍計劃編制的部分？（）

A、檢查

B、確定備選方案 C、質量功能展開

D、成本／收益分析

52、一個職能經理與項目經理的上司開會討論對一個主要可交付成果的驗收標準做一項變更。會后，這個上司與項目經理聯系，讓他實施這項變更。對這種情況最佳的做法是什么（）A、盡快做這項變更 B、理解該項變更

C、給管理層一份變更申請表，讓他們填寫后盡快交回 D、把這項變更告訴團隊

53、項目大部分已經完成，客戶要求對工作范圍做重大變更。項目經理應該：（）A、與項目團隊開會，決定是否可以做此變更 B、向客戶要該項變更的描述

C、向客戶解釋，進展到這個程度不能再做此項變更 D、通知管理層

54、項目經理想要使用Delphi技術獲得專家對他所遇到的一些技術難題的意見。他應該謹慎地做什么？（）

A、確信所咨詢的專家對他們的輸人是公認的。B、對任一種意見都進行信息與工作比較。C、咨詢項目干系人。

D、與專家們一起開會，得出一致意見。

55、一個項目發起人給了項目經理一份章程并告訴該項目經理，他不能肯定該章程是否完整。項目章程應包括：（）

A、可交付成果和目標

B、詳細的工作范圍 C、詳細的進度計劃

D、網絡圖

56、一個項目經理從一個團隊成員那里收到一項應提交給客戶的可交付成果。在查看這項可交付成果時，項目經理注意到該文件比預期的要少一些并且沒有他認為應該包括的內容。這個項目經理應該首先：（）A、與該團隊成員討論

B、與該團隊成員的經理聯系，讓那個人接受額外的培訓 C、審計開發過程 D、完成產品確認

57、在實施期間，你發現盡管以前已經批準了工作范圍，但客戶卻對工作范圍進行了變更，對該項變更的成本沒有異議。你應該首先做什么？（）A、遵循變更過程。

B、與客戶討論該項變更并協商新的范圍。C、與團隊開會，計劃選擇方案。

D、對該項變更可能導致的風險進行評估并形成文件。

58、產品確認不同于范圍確認，產品確認；（）A、在實施階段發生

B、確認使用了正確的產品 C、獲得客戶的簽字認可

D、確保所有工作都已完成

59、一個項目經理剛剛被分配到一個新項目中并得到一份完整的項目范圍。這個項目經理必要做的第一件事是什么？（）A、使用WBS建立項目計劃

B、確認所有項目干系人的輸人都包括在工作范圍中 C、組織一個團隊制定采購計劃 D、建立網絡圖 60、在對一項任務的檢查中，你發現一個團隊成員正在用與WBS詞典中的規定不同的方法完成這項工作。你應該如何處理這種情況？（）A、告訴這名團隊成員采取糾正措施。

B、確定這種不同的方法對職能經理是否是可接受的。C、問這名團隊成員，這種變化是否必要。D、確定這種變化是否改變了工作包的范圍。61、一個新項目經理正要編制項目的工作范圍。一個項目干系人要在工作范圍中加入很多事項。另一個項目干系人只是要求描述功能要求就可以了。這個項目對項目經理所在公司很重要，但是工作是由賣方來實施。你建議這個項目經理做下列哪項？（）

A、工作范圍應是概括性的，以便允許賣方做自己的決策 B、工作范圍應是概括性的，以便可以在以后澄清 C、工作范圍應是詳細的，以便可以在以后澄清 D、工作范圍應詳細到該類型項目所需的詳細程度.62、下面哪種文檔是項目經理首先要向項目團隊成員定義的，為了在項目啟動會議上就展示該項目是被官方批準正式成立的項目？（）A、項目章程

B、項目計劃

C、可行性研究

D、費用——收益分析 63、項目經理并不能確定某個特定的工作包中包含了什么。為了能更好地理解一個工作包中包含了什么，項目經理應該首先查看：（）A、進度控制文檔

B、賬戶編碼 C、WBS字典 D、風險管理計劃 64、你的一個合同商給你發了一封電子郵件要求他們只答應進行8次測試，而不是你方要求的10次測試。項目經理應該首先做什么工作？（）A、更改項目基線

B、要求合同商發一份正式的變更請求 C、在合同中找到處罰條款 D、詢問你的發起人的意見

65、你是變更控制委員會中的一員，批準巨大的范圍變更。項目經理首先第一步需要更新的文檔是：（）

A、范圍基線

B、進度 C、WBS

D、預算

66、在你以前的項目實施期間，即使你交付了客戶指定的內容，你也很難得到范圍定義的簽字認可。為了未來項目更好實施，你會更注意哪個過程？（）A、績效報告

B、范圍確認 C、范圍定義

D、管理收尾

67、下列規則除（）以外對于工作分解結構最低層次的工作包都是正確的。A、可以在一個位置不發生中斷地完成 B、可以做出可信的估算 C、必須且只能分配給一個人 D、必須在80小時內完成

68、下列哪項最不真實？（）A、WBS的最低層次也可以叫工作包

B、WBS詞典可以用于保存各種工作要素的說明

C、承包商的WBS和合同工作分解結構（CWBS）基本上是相同的 D、WBS中的工作包還可以進一步細化

69、效益測量和約束條件下的最佳化是（）的例子。A、成本效益比

B、可變成本 C、折舊類型

D、項目選擇方法 70、用于開發的分解過程是什么？（）

A、管理計劃

B、溝通計劃 C、工作分解結構

D、掙值 71、項目的工作分解結構是項目經理和她的團隊一起開發的。但現在項目團隊成員好像正在做工作分解結構以外的工作。工作分解結構的目的是：（）A、指導項目的成本估算，而不是工作怎么做 B、給高級管理層提供高層次項目范圍概觀 C、把制造項目產品所需的工作包括進去

D、把整體項目范圍或完成項目所必須做的全部工作包括進去 72、參與準備范圍基準計劃的是：（）

A、職能經理

B、項目團隊 C、所有干系人

D、項目發起人

73、一個新軟件產品的構建階段即將完工。下一個階段是測試和執行。這個項目比進度計劃提前了兩周。在進人最后階段之前，項目經理最應該關注什么？（）A、范圍確認

B、質量控制 C、績效報告

D、成本控制 74、一個客戶要求你給項目增加工作范圍。現在項目低于預算并比進度計劃提前一些。你應該怎么做？（）A、批準該項變更

B、讓客戶了解該項變更對項目的影響 C、請發起人批準該項變更

D、從配置變更委員會獲得批準 75、下列哪項是范圍確認的一項重要輸入？（）A、工作結果

B、歷史信息 C、正式接受

D、變更申請 76、下列哪項不是范圍確認的輸入？（）

A、工作分解結構

B、項目計劃 C、工作結果

D、變更申請 77、工作分解結構可以用于下列哪項？（）

A、與客戶溝通

B、顯示每項任務的日歷日期 C、對每個團隊成員顯示職能經理

D、顯示對項目的商業需求 78、下列哪項不是范圍確認的工具？（）

A、產品審核

B、審計

C、檢查

D、靈敏度分析 79、在編制WBS時不需要下列哪項？（）

A、歷史信息

B、項目章程 C、假設條件

D、范圍說明 80、在一個新產品的開發中，我們發現競爭對手正在開發一種與我們的項目產品有相似功能的新產品。我們決定建議對產品特性和項目產品做變更。這種變更申請是（）的結果。A、外部事件

B、在定義產品范圍中的錯誤或遺漏 C、在定義項目范圍中的錯誤或遺漏 D、一項增值變更

81、什么時候向一個項目指派項目經理？（）

A、合同簽訂后

B、就在合同時執行之前 C、合同啟動期間

D、合同計劃編制期間 82、在過去的幾周項目團隊已經對活動和任務做了3項范圍變更。項目經理必須非常仔細地：（）A、記錄所有變更

B、向發起人提交所有變更的文件 C、確保變更都反映在項目范圍內 D、防止更多的變更發生 83、一個項目經理發現兩個團隊成員討論要完成一項活動需要什么并且做了很多范圍變更。現在這項可交付成果完成了，那兩個團隊成員準備進行下一項任務。在看了他們所做的之后，項目經理確定他們所做的工作不符合項目要求。該項目經理的最佳行動路徑是什么？（）

A、增加另一項任務，與正確的項目范圍相符合 B、拒絕交付的任務

C、讓團隊重新做這項任務并把這個事故加人到他們的績效審核中 D、請該團隊成員的經理派別的人執行這項任務 84、范圍確認應在何時做？（）

A、項目結束時

B、項目開始時 C、項目的每個階段期間

D、計劃編制期間 85、項目進行到一半時，客戶想取消剩余的工作和合同。最佳的方法是查看下列哪項來確定項目的目的？（）

A、章程中的目的、目標和商業案例 B、WBS詞典，以便驗證范圍是否正確 C、風險管理計劃，以便評估可選方案 D、會計科目表，以便確定完工估算

86、你是一個IT項目的項目經理。你項目團隊的一個信息專家在同與他一起工作的一個低級別客戶代表共進午餐后得知，在顯示中一項簡單的改造會給項目增加巨大的附加功能。你和項目發起人都已經對范圍簽字認可。那位信息專家進行了這項改造，沒有給項目進度帶來負面影響，也沒有增加額外的費用。你應該采取什么管理措施？（）

A、這位信息專家所做的超過了客戶預期，并且既沒有影響項目成本也沒有影響項目進度，因此，這位信息專家應該受到表揚。

B、項目經理應該在項目計劃中增加一項沒有相應時間的任務。

C、應該告訴這位信息專家，他的行為是不可接受的，因為它完全可能給整個項目帶來負面影響。

D、由于這項變更已經做了，因此項目經理應該做一份變更控制表并請客戶在上面簽字。案例分析題

小楊第一次管理一個大型的軟件研發項目，該項目是在以前項目的基礎上研發新的功能。以前項目的版本已經批量安裝到客戶，并達到預先設定的目標穩定程度。該項目在前期各個階段的數據都符合原先設定的目標。但是，在系統測試階段，測試人員卻遞交了大量的缺陷。經過分析，發現這些問題大多數是回歸測試時發現的。而其中大部分是以前項目遺留的問題。這些問題介于優化和問題之間。不會影響基本功能，但是對新用戶來說，也有修改的必要。新的用戶的驗收測試不久就要開始了。小楊該如何處理這些問題呢？ 答案提要：

1、原項目遺留問題是否在項目范圍內，需要查看項目范圍說明書；一般情況下不會包含原系統的問題修改；如果在范圍內，則需進行修改。

2、如果不在范圍內則需要與公司和客戶溝通，估算修改的成本以及風險等因素，如果要修改，則需要做哪些工作，例如追加費用，會可能引發哪些進度方面的變化，存在哪些風險。

3、如果要修改發現的以前項目遺留問題，應該屬于原項目的優化，與本項目無關。但是也需要與客戶和公司溝通，一般而言，對于歷史遺留問題，公司是有責任修改的，但是對于當前項目而言，可能會有很多影響，需要就該修改進行分析，是否要修改與公司和客戶共同協商，尋求解決辦法。

4、作為項目經理，不僅僅是該項目的項目經理，也是公司面向客戶的一個形象，很多時候還需要考慮公司整體的利益，而不僅僅是原定的項目范圍。

所以項目經理任務項目范圍是一定要區分清楚，但是是否進行能修改是需要與公司上層和客戶溝通清楚，明確其中的責任和風險

單項選擇題參考答案

1-5DCBBA 6-10BCDDA 11-15DBBAB 16-20DDBAB 21-25BDBBA 26-30DAABD 31-35CACBA 36-40BAAAB 41-45DCBCC 46-50CABAC 51-55ABBBA 56-60DBDBD 61-65DACBA 66-70BCCDC 71-75DBABA 76-80DADBA