方面要求在8-10個月完成上線使用，維護期大致兩個月，也就是說整個專案週期必須控
制在一年內完成。
我所在的a公司，基於專案預算和利潤率的限制，調撥了20名員工供我差遣，希冀我
能用在保證專案質量的基礎上，用最快的速度完成這一資訊化工程專案。
接下來，我與公司較為資深的兩位業務專家對本專案進行了剖析，首先要保證專案進
度，就必須做到專案能夠並行實施，因而非常有必要將專案分為幾個專案組；其次，為了
節約成本，某些專案組在完成自己的任務後暫時將被公司**，直至進行子專案整合時方
再次組建（例如後面所提的採購專案組）。再則，考慮到對專案的控制和溝通成本，實施
分組有利於專案的進度監控和溝通成本的降低。此外，客戶方的需求分為五個較大的領域：
網路構建、辦公管理、進銷存、生產管理、財務管理，其中進銷存與生產管理聯絡緊密。
而財務管理系統，由於國家有相關規定，我建議m公司利用市面上現成的產品，而我方負
責介面開發，這個提議得到了m公司的同意。在此基礎上，我權衡了成本和管理的方便性，
遂將專案分為五個小組：軟硬體採購小組（1人），網路佈線施工專案組（2人），辦公0a
開發專案組（5人），業務系統（包括生產管理和進銷存管理）組（9人），架構設計小組
（3人）。其中網路佈線施工採用外包的方式，專案組的2人負責施工監督，架構設計小組
負責整個資訊環境前期的需求分析和架構設計，後期則分配到業務系統和0a系統開發組
因為在我所負責的這個專案內，成本和進度是重中之重的關注點。而專案的範圍決定
了專案的成本，對專案進度有著致命的影響。我們於是給予了專案範圍管理極大的關注，
即明確我們要做什麼？不做什麼？包括什麼？不包括什麼？
俗話說，「一之計在於晨「要做好多專案的範圍管理，首先就是要層層分解、周密
地做好範圍計畫編制和分解。
在專案範圍計畫的編制和分解上，我們採取了如下的措施來保證專案範圍計畫和范
為解的現實性和可行性。
（1）關注「專案三約束條件」：範圍、時間、成本；
由於範圍影響了時間和成本。因此對於我們來說，哪些事情該做，哪些事情不該
做，做到什麼樣的度上，尤其有必要。例如硬體的採購，我們考慮到了未來的擴充和
成本的實際，佈線採用了六類雙絞線而沒有採用光纖。當然，其他硬體也限於主流配
置而非高階配置，因為這早已超過使用者的需求標準了。
（2）講求專案範圍計畫的層次性和漸進性；
因為我和專案組中的每乙個人不可能全盤了解整個專案範圍，因此將專案範圍進
行分解尤為必要。我們按照專案組負責的子專案進行了專案大範圍的分解，接著按各
個子專案的專案階段以及子專案的專案階段的任務進行層層分解。最終，乙個完整、
明晰的計畫顯現在眼前，有關每個專案成員，在具體時間做什麼事情，要得出什麼成
果物一覽無遺。
（3）明確階段產物，明確驗收標準；
以往造成範圍界定不清的原因，就是沒有界定標準。在m公司這個專案中，我)《
對各個子專案，各個階段應該輸出什麼成果物，由誰來負責，以及如何驗收進行了詳
細定義。有了驗收尺碼，專案成員就可以參照這個尺碼，有所為有所不為，從而保證
質量和成本的均衡。
（4）關注專案範圍變更的評估；
在制定的專案範圍計畫中，我們對變化範圍怎樣確定，變化應歸為哪一類（當業
務系統和0a系統的特徵仍在被詳細描述的時候，做到這點特別困難，但絕對有必要）
等問題進行了清楚地描述。因為一旦發生變更特別是後期發生範圍變更，對專案的進
度、質量以及成本都大有影響，故而我們和公司在變更方面進行了討論和協商，給
出了變更的分類以及可接受的範圍變更的標準。
（5）專案範圍資訊共享、子專案介面問題共議；
對於乙個成員為21人，包含5個子專案的專案團隊，最大的難題就在於如何將
範圍資訊準確無礙的傳送到每個相關成員的手中並得到理解無礙的確認。為此，我在
專案中引入了資訊發布系統，用以實施範圍資訊的共享，並切實做好監督每個成員對
專案範圍的理解確認工作。對於涉及到多個子專案協作的事項，我採取了相關人員共
同商議、結果決定後全團隊發布的措施。通過以上兩個措施，專案範圍資訊共享取了
較好的溝通效果。
（6）積極使用專案管理工具提公升範圍管理的管理效率；
古語云， 「公欲善其事，必先利其器」。我在這個專案裡架設了msproject
server伺服器，並在每個專案成員機器上安裝了客戶端。有關專案範圍的資訊，完成
況，人力使用情況、資源占用情況一目了然，並且在專案範圍發生變更時，進行相
調整時也顯得非常便捷。
接下來，範圍變更的管理工作也尤為重要。在專案範圍變更實施方面，我們也做了大
量的工作、並採取了兩條措施來保證專案範圍變更的可追溯性和可控性；
首先，我們制定了範圍變更的流程及變更文件式樣。當客戶方面提出變更時，必須按
照流程規定提交變更請求（我方**也可，但客戶必須簽字）。接著，我們採用了關聯度
矩陣分析技術對專案範圍變更進行評估，分析客戶方的變更請求是否影響到各個子專案、
影響度有多大，對成本和進度有多少影響，在不在可接受的範圍內，如果不在，則根據與
m公司達成的協定和變更認定標準，拒絕變更或追加費用，如果在，則實施變更。
其次，我們構建了配置管理系統實施範圍管理的版本控制，以保證範圍變更得到有效
的追蹤，特別是面臨客戶「原地轉」的情況，還可以直接回溯到先前的版本來對應這種情
在實施過程中，我們不可避免地碰到了一些問題，但主要是範圍界定不清的問題。為
此，我和專案組成員進行了調查，發現在我們的範圍定義中，存在定義不夠明確，做不到
可量化、可驗證程度。例如，給使用者的業務系統需求說明中有「介面友好，易用性強，提
使用者滿意度」等文字。我們及時做出了調整並找來相關的業務原型和設計樣式，提供給
戶進行選擇，最終，客戶較為滿意地接受了我們推薦的介面式樣。對於需求不明確，我
們亦採用了同樣的措施，通過原型化方法和業務諮詢模式解決了實際需求問題。該措施同
也成為了我們實施範圍管理的乙個寶貴經驗。
最終，我們專案組經過自身的不懈努力，在2023年8月底||| 利地完成整個專案的開發，
10月份||| 利完成專案維護完善工作並交付於m公司維護。專案實施成本遠遠小於我所在公
司的預期，另外，m公司也對實施結果表示滿意。總結本次專案實施，我們認識到要做好
專案的範圍管理，就必須：
（1）針對專案目標，切合專案環境，做好範圍計畫的編制；
（2）基於層次性和專案成果物進行專案範圍的分解；
（3）依照流程和協定，嚴格執行專案範圍變更的流程。
論大型專案的風險管理
風險有其成因，同時，如果風險發生，也導致某種後果。當事件 活動或專案有損失或收益與之相聯絡，涉及到某種或然性或不確定性和涉及到某種選擇時，才稱為有風險。專案風險管理貫穿於專案的整個過程，成功的風險管理會大大增加專案成功的概率。筆者帶領組成員主要是從制定切實可行風險管理計畫 有效認別風險因素 分析風險...
論資訊系統大型專案的整體管理
2 制定專案管理計畫 凡事預則立 不預則廢。資訊系統專案尤其如此。只有站在統領全域性的高度，對專案進行科學 全面 周密的計畫，預先制定乙個用來協調所有其他計畫 以指導專案實施和控制的檔案，才能使專案得以順利實施並最終取得成功。專案計畫記錄了計畫的假設條件和方案選擇，可以為各利益相關者之間的溝通提供個...
使用甘特圖真正實現大型專案管理應用
真正完整的專案管理將從計畫 指揮 協調 控制和評價這5個方面貫穿乙個實際的專案。而甘特圖主要是在計畫 指揮 協調 控制這4個方面作用於專案管理系統。大多數甘特 決方案，只單單著眼於國內需求較多的計畫編制這一初級方面，要實現真正意義上的專案管理，計畫甘特圖的編制展示肯定是不夠的。在任何實際專案中，都擁...