統計資訊
  • 文章數 - 679
  • 回應數 - 2465
  • 引用數 - 0

 

[專案管理]談談專案變更控制與管理(Change Control & Management)

「要殺一個程式設計師不需要刀,改三次規格就好。」

「你帶領過沒做過任何變更的專案嗎?」,當我詢問這個問題時,台下大概只有5%的人舉手,我再問「若專案的時間不短於3個月的話呢?」,舉手的人紛紛放下了,專案的變更其實時常在發生,只要具有一定規模的專案,一定會發生各種大大小小的變更,小的變更可能只要做些工作項目的順序調整,大的變更可能會影響到範疇的放大(或所小)、交付的時間提前(或延後)與專案成本的增加(或減少)。

有人說專案若發生變更,意味著專案沒有規劃好,這個觀念不能說完全錯誤,但其實這對於變更是個誤解,因為他將「變更」這件事情想得非常嚴重,其實我要在畫面上多一個hint,這也是變更,只是這個變更極小,幾乎不太影響本來的工作量,但它確實是變更;修改關鍵程式的演算法,這也是變更,而且可能是很大的變更,可能因此衍生一堆程式都要跟著調整,增加了50小時的工作時數,這種變更就算是大變更了,而大多數人家認為沒有規劃好而造成專案必須要變更,大多是指此類型的變更。

專案經理在開始規劃專案時,可能很難將全部的狀況都搞清楚,一個人大概也很難兼具多種專業能力,因此變更會發生,幾乎是很正常的一件事,而我們應該以健康的態度看待變更,既然變更很難避免,那如何因應就很重要,所以變更的控制與管理對專案經理來說就非常的重要,以下我們來描述一下對於變更控制的一些心態與做法。

變更何時會發生?
變更發生的原因可能是因為利害關係人對專案的需求有所改變,例如本來想辦一場中式的婚禮,但因新郎的母親比較喜歡西式的婚禮,因此變更了他的需求,這時候負責規劃這個婚禮的PM就該重新審視這個專案;也可能是因為某些沒考慮到的因素使然,例如大理石的磁磚,計畫在鋪設時兩塊間的間距為0.3mm,結果卻沒考慮到因溫度與濕度不同,大理石會有不同的膨脹係數,在熱帶地區間距應該再大一些才對,這時候你就要變更你的鋪磚工作,調整間距為5mm;又或者是因為不可抗力而必須做的變更,例如在大陸開發的一套系統,因為政府法令的公布,導致系統的內容必須有所改變;變更也有可能是因為專案本身已經發生延遲了,不得不進行主動性的變更,這些都是變更發生的原因,並沒有特別的變更來源,但要謹記,當規劃的內容與現實有差異時,變更就會發生。

變更發生時怎麼辦?
如果變更有99%的機率會發生,那專案經理該如何因應呢?請依以下步驟:
1.首先你必須了解這項變更的原因
2.接著是評估影響的範圍(包含範疇、時間、成本、品質等)
3.再來則是識別此變更是否必要
4.核准、拒絕、暫緩變更
5.對核准過且影響不大的變更,專案經理自行決定是否執行即可;若影響的範圍較大(影響到範疇、時間、成本),則必須經過專案經理、Sponsor等共同決定是否執行變更
6.將專案的變更記錄下來,不管這項變更最後有沒有執行(用來做紀錄與稽核)

變更控制&管理的困難
《困難點一:追蹤並預防變更不容易》
變更潛藏在專案的四周,專案經理必須要時時的關注專案的況狀,這個狀況不只有專案的工作項目本身,更要留意外在環境與利害關係人,因為這些常常是潛在的變更原因,專案經理如果可以把專案工作如期、如值、如預算的進行,已經算很厲害了,但更厲害的專案經理則是早已經對於變更有了因應的規劃,要追蹤變更,只有專案經理本身對專案的現況有更完整的了解才能早期發現早期治療。

TIPs:定期檢視專案裝況,及早發現並預防,若變更是必要的,就提早因應

《困難點二:變更通常只有往上加,而不會往下砍》
常有人說因為變更是專案經理沒有規劃好才會發生,應該由專案經理想辦法處理掉,所以專案發生變更而衍生的工作量,常被要求專案經理要想辦法消化掉,所以如果因變更而衍生了100小時的工作量,導致專案要面臨變更範疇(增加功能)、時程(延期)、成本(加班、加人)來處理這個變更,身為專案經理,必須要正視變更所造成的影響,並就其原因向Sponsor說明,與Sponsor確認是否要變動基準,並且要讓Sponsor了解此變更的影響性,看是要將部分功能延後執行,還是允許延期,在不然就是要加人加班了,總之沒有不變動就能無痛的處理完此變更的方法。

TIPs:必須與Sponsor培養良好的默契與關係,整個專案的狀況專案經理應該是最了解的,站在理法情的立場上向Sponsor反應真實的狀況,並提供2-3個解決方案。

《困難點三:評估影響範圍不易》
評估影響範圍通常會交由負責該項工作的成員來進行,通常專案經理不見得是團隊中對每一項工作最了解的人,因此也不容易保證成員所評估出來的結果是完全正確的,這時候又埋了一個變更的可能性在裡頭,當外行人(PM)領導內行人(專案成員)時,時常會發生類似的狀況,只能被動的接受成員回報上來的結果,但很難去評斷對錯,因此專案經理的Domain know-how就變得非常重要,除非成員非常值得信賴,否則專案經理本身必須要具備足夠的專業能力才能有效的應付每個變更。

TIPs:除了持續累積足夠的know-how外,建議也做定期的產出交付予V&V動作,確保目前的產出如預期,再來要評估影響性就會相對單純許多,另外,找到可信賴的夥伴也非常重要。

以健康的心態看待變更的發生是比較好的,變更永遠會發生,但如何有效的預防與控制變更,將是專案經理能否順利完成專案的關鍵。

分享  

 




回應

# re: [專案管理]談談專案變更控制與管理(Change Control & Management)

通常都要殺開發人員好幾次 XD

有需求變更是正常的,有臨時插單更是常態!

這是不管那個行業一定會有的,所以需求管理、架構規劃就一定要做。

不做通常都會死的很難看 ~~ 

 

2011/12/10 下午 02:19 | franma 回覆

# re: [專案管理]談談專案變更控制與管理(Change Control & Management)

to franma :
變更的多寡或者是否有偏掉主線,這就是PM的功力了,而變更後是否有良好的變更管理,那就要看日常的軟工程序是否有落實了。

2011/12/12 下午 10:40 | gipi 回覆

# re: [專案管理]談談專案變更控制與管理(Change Control & Management)

我曾經做過一個案子,該案的所有關係人都不希望案子做完,不論是客戶還是PM,所以最可憐的就是PG...因為那些關係人為了不讓你做完,所以就想盡辦法刁難你讓你永遠做不完,當你很拼的連六日都搞到半夜做完50個項目,客戶那邊馬上會再生個60個而PM也會馬上答應,這就是現實的PG人生,金錢遊戲下的犧牲品 2011/12/17 下午 01:03 | 亞斯狼 回覆

# re: [專案管理]談談專案變更控制與管理(Change Control & Management)

to 亞斯狼 :
這種狀況畢竟是很少數,不過我不確定這種案子發展成這樣的原因是甚麼?是因為有油水可以撈還是要維繫兩方的關係?

2011/12/18 上午 11:40 | gipi 回覆

# re: [專案管理]談談專案變更控制與管理(Change Control & Management)

to 亞斯狼 :
可以問一下這個專案是甚麼樣的狀況嗎?

2011/12/18 上午 11:41 | gipi 回覆

# re: [專案管理]談談專案變更控制與管理(Change Control & Management)

該專案的狀況其實很複雜,在客戶(operator)方面是抗拒新系統,畢竟他們Paper Work了30年,突然叫他們要採用電子化這會讓他們感到很不適應,再者就是我們的PM是業務兼著做,為了要有繼續的維護案,所以對於客戶的要求是立即答應,也由於這個案子十分龐大動輒7000萬到一億元(不斷加碼ing...),所以PM是打死也要討好客戶(計劃提出者),而客戶(Operator)也一直不斷抗拒新系統,但是客戶(計劃提出者)的主要工作就是提計劃生案子,所以就形成這種畸形的生態,反正這些錢都是老百姓買單,PM和客戶(計劃提出者)也樂得開心

(p.s. 這個系統第一代PG迄今已全數離職了,因為這真的不是適合人類生存的地方) 2011/12/20 上午 12:45 | 亞斯狼 回覆

# re: [專案管理]談談專案變更控制與管理(Change Control & Management)

to 亞斯狼 :
這類的問題或許在政府或公家機關的專案比較容易發生,沒辦法,有錢誰不想賺,有經費一定要花掉,但這就苦到開發人員,因為永遠無法看到自己的系統上線,一點成就感都沒有阿...

2011/12/21 下午 02:11 | gipi 回覆

# re: [專案管理]談談專案變更控制與管理(Change Control & Management)

 學長, 請問  V&V是什麼意思阿 ? THanks!= ^^!

2012/5/1 下午 05:57 | 國倫 回覆

# re: [專案管理]談談專案變更控制與管理(Change Control & Management)

to 國倫 :
Verification & Validation 
驗證(Verification): "我們是否正確的開發了產品?" 意即軟體應該與規格相符; 確認(Validation): "我們是否開發了對的產品?" 就是說軟體應該執行使用者真實的需求。

2012/5/1 下午 06:29 | gipi 回覆

回應




 


登入後使用進階評論

Please add 6 and 5 and type the answer here:

 

 

Copyright © gipi