糟糕的範圍管理導致專案失敗(轉)
定義並計劃一個專案只是成功管理一個專案的第一步。在你做完工作計劃之後,你就要按照這個計劃工作。你必須保證你同意完成的工作要在規定的時間和預算專案範圍內完成。計劃工作的一部分是針對一種不可避免的事實:一旦專案開始進行了,客戶就會不停地要求你完成超出原來商定範圍的工作,或者和原來商定範圍不同的工作。這就是你必須要使用範圍變化管理的時候了。如果你不使用它,你就會因為要完成比原先同意的預算所包括的工作量多得多的工作而疲於奔命。換句話說,你將會遭到很大的麻煩。
什麼是導致專案失敗的主要原因
我們都經歷過不太成功的專案。我在這個系列裡討論了五個最為常見的專案管理的錯誤。在這裡閱讀第一部分,“糟糕的計劃是專案管理第一大失誤”。
範圍管理從範圍定義開始
定義專案範圍可能是定義一個專案過程中最重要的部分。事實上,如果你不確定你在進行的是什麼,以及你所進行的專案的邊界在哪裡,你就根本不可能成功。管理專案範圍是專案管理裡最重要的一部分。但是,如果你沒有很好地定義專案範圍,那麼管理專案範圍幾乎就是不可能的了。
定義專案範圍的目的是把你的專案的邏輯範圍清楚地描述出來,並獲得認可。範圍陳述被用來定義哪些工作是包括在該專案的邊界之內的,而哪些工作又是在該專案範圍之外的。你能夠把專案範圍定義得越清楚,你的專案就會越明確。下面這些型別的資訊可能會有幫助。
範圍內和範圍以外的可交付使用的型別(商業需求,目前狀況評估)
範圍內和範圍以外的主要的生命週期流程(分析,設計,測試)
範圍內和範圍以外的資料型別(財務,銷售,僱員情況等)
範圍內和範圍之外的資料來源(或者資料庫)(帳單,總帳,薪水冊等。)
範圍內和範圍之外的組織(人力資源,製造商,供應商等)
範圍內和範圍以外的主要功能(決策支援,資料輸入,管理報告)
有一個可行的範圍變化流程
專案經理和專案小組必須意識到範圍變化本身並沒有什麼不對。也就是說在專案進行過程中修改範圍並不是什麼壞主意。事實上,很多時候,這是一件好事。首先,客戶通常都不能確定最終解決方案所需要的所有的需求和功能。其次,就算他們可以,商業是隨著時間不斷變化的,因此專案的需求也會發生變化。
如果你不能夠容納變化,最終的解決方案就會達不到應有的價值,或者它甚至有可能是無用的。因此,你希望客戶具有在需要的時候改變專案的能力。如果專案經理對於專案變化沒有準備,問題就產生了。每一個專案都應該有一個流程來有效地管理變化。這個流程應該包括確定變化,評估變化的商業價值,評估對於專案的影響,然後把這些資訊提交給專案發起人進行評估。發起人然後可以決定是否同意該變化。如果同意,發起人還應該理解它對於專案的影響,然後為它追加費用,延長專案時間。
範圍變化管理的共同問題
當專案小組處理範圍變化管理時,通常會遇到下面一些共同的問題:
範圍蔓延:很多專案經理能夠意識到大的範圍改變,但是對於小的改變卻沒有那麼敏感了。現在有一種趨勢,就是隻不斷地進行專案,不斷新增額外的工作而並不經過仔細的考慮。範圍蔓延指的是當專案接受了太多小的變化之後所出現的情況。當所有這些小的變化結合在一起,專案小組才意識到需要做的額外工作太多,以至於要超出預算,延誤工期。
沒有發起人的同意:很多時候,專案經理會從終端使用者,股票持有人,或者客戶經理那裡收到變更請求。由於這些人都是客戶公司內部的,有趨勢認為這些請求都應該被接受。這種想法是錯誤的。終端使用者經常會提出範圍修改的請求,但是他們無權批准這樣做。甚至一個客戶經理也不能夠批准範圍變更請求。唯一有權這樣做的人是發起人(除非發起人把這項權利授權給別的什麼人)。很多專案陷入麻煩是因為他們認為他們獲得了進行範圍修改的批准,但是後來卻發現有權決定這種變更的人--發起人,並沒有同意這樣做。
專案小組的責任:由於專案小組成員和客戶有很多聯絡,他們是最經常會遇到範圍更改請求的人。因此,整個專案小組必須理解範圍變化管理的重要性。他們必須在範圍變化發生的時候立即發現它,並且即使把它反饋給專案經理。如果他們自己答應進行一些額外的工作,他們的這種行為就很有可能導致他們不能夠按時完成自己的工作,從而危及整個專案的進行。
開始永遠不會太遲
如果你發現你的專案開始超出預算並落後於計劃進度,試著去找出原因。在很多情況,你將會發現這只是因為你所做的工作比你最初同意得要多得多。定義範圍變化管理流程最好的時機是在專案開始之前(作為專案管理程式的一部分)。但是,如果你確實建立沒有一個好的流程,任何時候開始都不算太遲。專案管理必須安排一個暫停的時間,然後和客戶一起檢定並滿足範圍變更的請求。然後每個人都要學習新的流程。
如果說這種情況有好的一面,就是專案小組和客戶可以第一時間看到不控制範圍的影響,因為專案已經陷入麻煩中了。這樣他們就能夠更好地理解範圍變化管理的目的,並且更願意在將來採用更嚴格的流程。
[@more@]
什麼是導致專案失敗的主要原因
我們都經歷過不太成功的專案。我在這個系列裡討論了五個最為常見的專案管理的錯誤。在這裡閱讀第一部分,“糟糕的計劃是專案管理第一大失誤”。
範圍管理從範圍定義開始
定義專案範圍可能是定義一個專案過程中最重要的部分。事實上,如果你不確定你在進行的是什麼,以及你所進行的專案的邊界在哪裡,你就根本不可能成功。管理專案範圍是專案管理裡最重要的一部分。但是,如果你沒有很好地定義專案範圍,那麼管理專案範圍幾乎就是不可能的了。
定義專案範圍的目的是把你的專案的邏輯範圍清楚地描述出來,並獲得認可。範圍陳述被用來定義哪些工作是包括在該專案的邊界之內的,而哪些工作又是在該專案範圍之外的。你能夠把專案範圍定義得越清楚,你的專案就會越明確。下面這些型別的資訊可能會有幫助。
範圍內和範圍以外的可交付使用的型別(商業需求,目前狀況評估)
範圍內和範圍以外的主要的生命週期流程(分析,設計,測試)
範圍內和範圍以外的資料型別(財務,銷售,僱員情況等)
範圍內和範圍之外的資料來源(或者資料庫)(帳單,總帳,薪水冊等。)
範圍內和範圍之外的組織(人力資源,製造商,供應商等)
範圍內和範圍以外的主要功能(決策支援,資料輸入,管理報告)
有一個可行的範圍變化流程
專案經理和專案小組必須意識到範圍變化本身並沒有什麼不對。也就是說在專案進行過程中修改範圍並不是什麼壞主意。事實上,很多時候,這是一件好事。首先,客戶通常都不能確定最終解決方案所需要的所有的需求和功能。其次,就算他們可以,商業是隨著時間不斷變化的,因此專案的需求也會發生變化。
如果你不能夠容納變化,最終的解決方案就會達不到應有的價值,或者它甚至有可能是無用的。因此,你希望客戶具有在需要的時候改變專案的能力。如果專案經理對於專案變化沒有準備,問題就產生了。每一個專案都應該有一個流程來有效地管理變化。這個流程應該包括確定變化,評估變化的商業價值,評估對於專案的影響,然後把這些資訊提交給專案發起人進行評估。發起人然後可以決定是否同意該變化。如果同意,發起人還應該理解它對於專案的影響,然後為它追加費用,延長專案時間。
範圍變化管理的共同問題
當專案小組處理範圍變化管理時,通常會遇到下面一些共同的問題:
範圍蔓延:很多專案經理能夠意識到大的範圍改變,但是對於小的改變卻沒有那麼敏感了。現在有一種趨勢,就是隻不斷地進行專案,不斷新增額外的工作而並不經過仔細的考慮。範圍蔓延指的是當專案接受了太多小的變化之後所出現的情況。當所有這些小的變化結合在一起,專案小組才意識到需要做的額外工作太多,以至於要超出預算,延誤工期。
沒有發起人的同意:很多時候,專案經理會從終端使用者,股票持有人,或者客戶經理那裡收到變更請求。由於這些人都是客戶公司內部的,有趨勢認為這些請求都應該被接受。這種想法是錯誤的。終端使用者經常會提出範圍修改的請求,但是他們無權批准這樣做。甚至一個客戶經理也不能夠批准範圍變更請求。唯一有權這樣做的人是發起人(除非發起人把這項權利授權給別的什麼人)。很多專案陷入麻煩是因為他們認為他們獲得了進行範圍修改的批准,但是後來卻發現有權決定這種變更的人--發起人,並沒有同意這樣做。
專案小組的責任:由於專案小組成員和客戶有很多聯絡,他們是最經常會遇到範圍更改請求的人。因此,整個專案小組必須理解範圍變化管理的重要性。他們必須在範圍變化發生的時候立即發現它,並且即使把它反饋給專案經理。如果他們自己答應進行一些額外的工作,他們的這種行為就很有可能導致他們不能夠按時完成自己的工作,從而危及整個專案的進行。
開始永遠不會太遲
如果你發現你的專案開始超出預算並落後於計劃進度,試著去找出原因。在很多情況,你將會發現這只是因為你所做的工作比你最初同意得要多得多。定義範圍變化管理流程最好的時機是在專案開始之前(作為專案管理程式的一部分)。但是,如果你確實建立沒有一個好的流程,任何時候開始都不算太遲。專案管理必須安排一個暫停的時間,然後和客戶一起檢定並滿足範圍變更的請求。然後每個人都要學習新的流程。
如果說這種情況有好的一面,就是專案小組和客戶可以第一時間看到不控制範圍的影響,因為專案已經陷入麻煩中了。這樣他們就能夠更好地理解範圍變化管理的目的,並且更願意在將來採用更嚴格的流程。
[@more@]
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/7839396/viewspace-938053/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 專案管理軟體之範圍管理專案管理
- sock鎖檔案導致的MySQL啟動失敗MySql
- 資訊系統專案管理系列之六:專案範圍管理專案管理
- dotnet 9 WPF 專案禁用 IncludePackageReferencesDuringMarkupCompilation 導致原始碼包 XAML 構建失敗Package原始碼
- springboot衝突導致的發版失敗Spring Boot
- 專案範圍管理的最佳實踐:避免軟體專案膨脹
- 故障分析 | DDL 導致的 Xtrabackup 備份失敗
- 使用CDN導致301跳轉失敗(主域名、泛解析)的解決方案
- 10-專案範圍管理(2/10 十大管理)
- Qualtrics:糟糕的客戶體驗導致企業平均損失3%的收入
- 迴圈引用導致的json序列化失敗JSON
- SpringBoot專案Autowired失敗Spring Boot
- rman備份的時候讀取v$session_longops失敗導致備份失敗SessionGo
- Docker 導致阿里雲 ECS 內網互通失敗Docker阿里內網
- 企業使用ERP系統導致失敗的因素所在
- 專案範圍管理不受控,需求不斷蔓延,怎麼辦?
- 敏捷專案管理:問題、挑戰以及如何避免失敗敏捷專案管理
- ORACLE 分割槽索引UNUSABLE導致的DML操作失敗引起的血案Oracle索引
- 儲存互斥失敗導致資料丟失的資料恢復成功案例資料恢復
- Nginx轉發導致請求頭丟失Nginx
- 那些騰訊投資失敗的專案
- MongoDB例項重啟失敗探究(大事務Redo導致)MongoDB
- 一個SaaS專案失敗的原因 從個人角度覆盤專案失敗的5個重要原因
- 專案範圍說明書如何編寫?
- selenium-java被檢測導致滑塊驗證失敗Java
- 專案中的 Git 使用規範 [轉]Git
- [工作札記]03: 微軟Winform窗體中ListView、DataGridView等控制元件的Bug,會導致程式編譯失敗,影響範圍:到最新的.net4.7.2都有微軟ORMView控制元件編譯
- 如何避免“範圍蠕變”讓專案脫軌?
- Drone構建失敗,一次drone依賴下載超時導致構建失敗的爬坑記錄
- 關於 iconv 轉碼導致資料丟失的問題
- 邦芒面試:導致面試失敗最關鍵的3種原因面試
- 匿名內部類方式構建物件導致序列化失敗物件
- 開啟 Keep-Alive 可能會導致http 請求偶發失敗Keep-AliveHTTP
- wait_type SOS_WORKER導致資料庫連線失敗AI資料庫
- FORTRAN動態陣列分配失敗導致執行時Access Violation陣列
- 一次失敗的專案經歷以及反省
- 避免專案失敗的六個基本關注點
- 自動化專案失敗的七宗罪
- 為什麼RPA專案失敗了呢?