<del draggable='dthx2y'></del>

              1. 首頁 關于我們新聞資訊行業資訊

                爲什麽你的項目範圍總在蔓延

                • 2019-06-28

                • 捷爲科技

                項目範圍蔓延好比618你本來隻想買一個藍牙音箱,結果逛着逛着,這裏點點,那裏看看,不小心種草了一大波數碼産品,下個月的花呗還款額直逼萬元大關!

                項目範圍蔓延有什麽壞處?繼續上面這個例子,購物預算嚴重超支,不僅會嚴重影響接下來的生活質量,如果運氣不好再生個小病,相當于一個小型财務困境了。

                反映在項目中,項目蔓延會無情地消耗項目資源,影響範圍内的工作的有效完成,激化團隊矛盾,導緻諸如團隊加班、PM背鍋等情況出現,嚴重影響團隊士氣和項目的交付。

                沒有項目經理喜歡範圍蔓延(除非加money),但爲啥項目蔓延現象還是難以避免呢?造成項目蔓延的原因,主要是因爲:

                1、 項目範圍描述不清楚

                項目範圍描述是管理項目範圍的第一步,如果這一步沒定義清楚,就相當于給項目範圍管理埋下了一顆定時炸彈。

                舉個例子, PM小張在爲客戶做一個項目管理系統,便于項目管理。這時客戶提出,可以增加一個功能用起來更方便,且實現難度也不大,小張就同意了這個請求。客戶使用該功能的時候,非常滿意!可是好景不長,過一段時間客戶又提出了一個新的需求,小張想拒絕,客戶馬上就有點不開心了,上次不是說加就加了麽,這次怎麽就加不了呢?小王隻能硬着頭皮做,後來項目組隻能根據用戶的新需求不斷去開發新的功能。變成了一個無底洞,結果項目不僅沒有及時交付,項目成員還累得筋疲力盡,客戶還不買賬,滿盤皆輸。

                顯然,這位項目經理犯了最嚴重的錯誤。一開始就沒有很明确地界定整個項目的範圍,又沒有一套完善的變更控制管理流程,在範圍沒有明确界定的情況下,任由客戶怎麽說就怎麽做,一開始遊戲規則沒有定好,從而導緻整個項目成了一個爛攤子。

                2、客戶和項目組對寫成紙面文件的需求理解不一緻

                在項目中,這種項目蔓延現象更爲隐蔽。即由于客戶和項目組對需求的理解不一緻,在做項目的過程中,需要時不時地做調整、改需求,項目經理被動接受而造成的範圍蔓延。

                例如,你可能會碰到這樣的客戶,功能做到一半,結果客戶表示“什麽?這個功能是這樣的麽?我們當初說的不是這樣的啊!不行,可能需要重新改一下。”

                碰到這種情況就十分崩潰了,這說明前期的工作做得大都是無用功。這其實也是一種範圍蔓延和資源的浪費。别看這隻是對原計劃的功能進行一些修改,但是這種範圍蔓延會耗費大量的時間和資源。要知道在項目中,随意增加哪怕是一小件工作,也會消耗項目資源,給整個項目帶來不小的幹擾。

                那麽,在項目執行過程中,如何做好項目範圍内的工作,防止範圍蔓延呢?

                一、項目啓動階段的變更預防

                基準文件定義的範圍越詳細清晰越好。如果需求做得好,文檔清晰且又有客戶簽字,那麽後期客戶提出的變更就超出了合同範圍,需要另外收費。不能讓客戶養成經常變更的習慣。

                在iMIS-PM項目管理系統,可将立項溝通過程的文檔:合同、協議、項目說明書文件、對外會議紀要等,上傳到系統進行統一管理,作爲未來項目決策的文檔基準。

                二、範圍分解

                計劃明确了,必須采取分解手段把主要可交付成果分成更容易管理的單元,恰當的範圍定義對項目成功十分關鍵,當範圍定義不明确時,變更就不可避免地出現,很可能造成返工、延長工期、降低團隊士氣等一系列不利的後果。

                比較常用的方式是以項目進度爲依據劃分WBS, iMIS-PM項目管理系統中:

                (1)可以無限級拆分WBS任務計劃,根據項目規模來逐級細分項目的管理顆粒度

                (2)項目計劃的任何一個任務時間變更,整體計劃會自動進行重新計算和更新

                (3)通過任務樹和甘特圖進行管理項目階段計劃:項目任務樹可直觀顯示任務之間的父子關系;甘特圖可直觀顯示任務的先後時間關系

                (4) 可以設置項目任務的前後置關系以及項目任務與流程(文檔)的進度完成關聯關系

                既有大的項目成果框架,也能看到每層下面再把工作分解,方便執行過程中發現遺漏或多出的部分,防止項目蔓延。

                三、項目實施階段的需求變更

                成功項目和失敗項目的區别在于項目的整個過程是否是可控的。項目經理應該樹立一個理念——“需求變更是必然的、可控的、有益的”。認真分析每一個變更請求,評估變更可能帶來的風險和修改基準文件。設定嚴格的變更标準。同時必須有一套規範的處理流程。對于需求變更的處理流程應該分以下步驟:提出變更-變更評估-實施變更-需求變更處理流程。

                這個流程最大的益處在哪裏?變更流程作爲一個緩沖,允許真實的變更被注意、記錄、追蹤,同時現有的工作又不會因此而被擾亂。項目組可以周期性地暫停來吸收最新的需求變更進行更新,同時又不打亂現有的工作節奏。

                iMIS-PM項目管理系統,對于需求變更等,也可以通過項目流程進行控制,具體步驟如下:

                (1)發起變更申請:根據項目實際情況提出項目計劃變更申請表(包含變更事由、時間計劃變更、人員計劃變更、項目交付物變更等)

                (2) 項目變更審批:簡單的變更由項目經理審批,複雜的變更需提交預設的變更流程(如财務預算的增加、設計需求變更等)。項目文檔可以提交變更。系統将自動生成新的文檔版本(文檔升級)

                (3)支持由責任人錄入配置管理表(可自定義),根據企業實際情況,自定義項目變更流程,在項目中發起變更申請流程

                (4) 變更曆史: 系統可以在項目變更列表中集中顯示所有新發起的和審批通過的項目變更請求。

                喬布斯曾說過,最重要的決定不是你要做什麽,而是你決定不做什麽。一個優秀的項目經理從善于掌握主動權,避免項目蔓延開始!