需求可以變 但專案不能亂(轉)
“我們又有了一個新想法……”
這是所有專案實施方
最怕從客戶那裡聽到的話
曾經與一位做專案的朋友聊天,他說,每當電話響起,他就膽顫心驚,就是害怕客戶打電話來對執行的專案提出一些新的想法和改動。對於客戶在專案執行過程中突然提出的新想法和變動,他頭疼不已。
相信像我這位朋友的感受,肯定許多的專案經理都深有體會。的確,對於專案經理來說,在專案實施過程中客戶需求的臨時變動,是實施專案過程中最頭疼的事。因為這樣極有可能會使整個專案延誤,無法達到理想的效果,甚至導致專案的失敗。
那麼有沒有一個行之有效的解決辦法呢?就這個問題,我們採訪了中國惠普公司IT管理學院授權講師周勤先生,希望他能夠通過自身豐富的專案管理經驗給頭疼著的專案經理們以啟示。
只有“變”是不變的
客戶希望整個專案能夠做到盡善盡美,甚至是超值回報。因此他們總會在專案執行過程中不斷變化執行計劃;而作為專案執行方來說,在專案實施前制定出所有的計劃,然後按部就班地執行是他們最大的願望。客戶希望能夠獲得最大價值,這本身無可厚非;專案執行方希望能夠儘量少地改變已經制定好的實施計劃,也在情理之中。
有統計資料表明,一個專案平均有超過20%的需求要增加或改動,而且這極不穩定的部分,可能分佈在專案實施的各個時期。針對這種改變,甲乙雙方自然是“一個要變,一個不想變,各有各的小九九”。乙方的日子不好過,甲方的苦衷也不少。試想,誰願意投了錢眼見著打水漂兒?雖然明知道變化會帶來諸如週期延長、成本增高等弊端,可不變帶來的後果也許更糟糕,何況還有行政、社會、企業內部等諸多方面的壓力。所以使用者總會覺得自己提出改變是人之常情,乙方如果沒有足夠的理由或者溝通技巧,他們幾乎很難被說服。
“其實,很多時候使用者提出需求改變並非無理取鬧”,周勤先生援引了一位專案經理的親身經歷,由於專案在最開始提需求時缺少對財務差異分攤問題的考慮,導致專案上馬後這一塊業務總在影響其他業務模組的使用,本來可以直線進行的業務現在只能繞著走。這個例子說明,如果當初發現了問題,及時做調整,後來就不會很被動,所以,一些關鍵業務的需求變更的確需要堅持,乙方應該對此給予充分的理解。
引入“三方會談”
周勤先生認為,如果想避免客戶在專案執行中的需求變更,就得積極主動地去溝通,儘量減少專案中的不確定因素。在與客戶確定需求的時候邀請行業專家,作為第三方進行“三方會談”,甚至有合作伙伴參加的“多方會談”,就是惠普的一個成功經驗。 這樣一來,作為行業專家的一方可以從公正的角度去告訴客戶,專案執行方在什麼方面還有潛力可挖,哪些要求是無法實現的。通過這樣的方式,合作雙方可以在和諧的氣氛下從容地溝通,使雙方在專案效果上儘可能地達成一致,減少以後的專案需求變更。如果說“三方會談”是控制專案執行過程中變動的有效方法的話,那麼為客戶量身定製的解決方案就是專案執行成功的關鍵。
這裡有一個反面的例子,國內某著名家電企業曾與國外某著名管理軟體廠商合作。為了進入中國家電市場這樣的長遠考慮,儘管合作條件苛刻,後者還是將燙手的山芋接在手中。專案啟動後,該家電企業因市場和自身業務的調整需求,多次更改需求,後者開始還能承受更改,後來,由於需求變化比例太大,導致初期計劃部署的框架結構面目皆非,最終雙方均感無力繼續支撐,只得無結果而終。試想,如果當時有了第三方的行業專家,在專案開始時就不會有那麼苛刻的條件,同時他也能夠在後面的變化中指出什麼改變是合理的,什麼改變是不合理的。那麼甲乙雙方在變動上就能達成統一,而不至於鬧到最後雙方不歡而散。
針對不同客戶的不同需求,周勤認為,在制定每一個專案執行計劃的時候,針對每個行業使用者特有的要求還是得多問兩句,主動地去了解客戶特殊要求,將其需求變更歸入專案實施計劃之內,當雙方對這一專案有了共同語言,達成共識後,合作才更容易開展。
同時,通過溝通雙方能在很多方面達成一致,其專案成本往往比雙方很難達成共識的專案成本要低得多,因為沒有達成共識的專案中存在著很多風險,必須拿出更多的費用去應付這樣的風險。雙方能夠達成共識不僅有利於以後的專案實施,而且節省了不少的開支。如果雙方都認識到這一點,就都會極力地促進洽談,使風險降到最小,成本降到最低。
溝通的重要性不必多講了,難的是如何做到“有效”的溝通。通過認真觀察那些溝通“高手”,我們總結出一些可行的方法。這些方法正是惠普專案經理必須掌握的。
啟動應變管理流程
積極地溝通能夠促使專案變更降到最小,但是如果萬一市場有了變化,真的需要進行變更時,又應該怎麼辦呢?這時候需要的就是管理。
周勤說,首先專案管理變更的關鍵地方不在於實施階段,而是在計劃階段,這也就是管理的主旨。在整個專案合同簽訂以後,雙方就要在專案實施啟動之前,制定一個嚴格的管理制度,這其中最重要的就是制定一個嚴格可行的應變管理流程,一旦出現變化,嚴格按照這一流程進行相應變更。而啟動這一應變流程,就得分幾個步驟進行:第一個步驟是雙方要認真分析應變可能會給整個專案帶來的後果。第二個步驟是決定變還是不變,尋求一個批准的過程。第三就是基於客觀分析後付之於行動。
與周勤不謀而合的是,許多成功的專案經理都認為,“應變管理流程”是其中至關重要的。為了減少甲乙雙方分歧或者有效解決爭議,需要簽署一份詳盡的“應變管理流程”,這份流程是與合同具有同等法律效力的檔案,通常應針對具體專案的性質和特點就變更的範圍、流程、決策許可權、變更比例、變更評估、爭議解決方式等條款進行詳細的規定,一旦需求變更開始,就可以立即啟動規定好的應變程式,這樣可以有效避免可能的推諉和爭執。“應變管理流程”這種規範做法在合理、有效應變的同時,也有利於促進客戶的成熟,並可規範專案管理市場。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/7942439/viewspace-21250/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 專案經理如何應對專案需求變更?
- 需求變更,敏捷專案應如何做?敏捷
- 收集更有效的專案需求資訊 (轉)
- 如何確定專案的工作需求(轉)
- 軟體專案需求分析總結(轉)
- 專案需求變更得不到有效控制所帶來的後果(轉)
- 專案管理不能紙上談兵 (轉)專案管理
- 專案管理中的需求變更分析和解決之道專案管理
- Web專案經理手冊之需求變更管理Web
- 專案的變革軌跡(轉)
- 【分享貼】需求變更、專案延誤,專案經理應該如何應對?
- 專案中如何更好的控制客戶需求(轉)
- 專案範圍變更管理(轉)
- 專案經理該如何面對頻繁的需求變更?
- 軟體專案需求分析的20條法則(轉)
- 專案需求說明書
- 團隊專案需求分析
- 專案管理過程之變更控制(轉)專案管理
- 專案管理過程之變更控制 (轉)專案管理
- 需求調研分析中的專案干係人概念(轉)
- 軟體專案需求調研過程管理小議(轉)
- 軟體工程_專案需求分析軟體工程
- 其實,專案管理也可以很簡單...(轉載)專案管理
- 專案管理中的變革藝術(轉)專案管理
- 企業業務軟體工程專案和商業軟體產品專案上專案需求管理的不同(轉)軟體工程
- 我在專案管理中關於需求分析的總結(轉)專案管理
- 在新冠時期,業務規則可以放鬆,但網路安全不能
- 研發管理案例-專案管理平臺-需求任務變更歷史分析專案管理
- Node專案之需求收集平臺
- GAT專案新需求:保險管理修改
- 專案需求討論 — 待機介面
- 哪些需求管理工具管理專案需求比較好?
- 需求管理之專案中如何更好的控制客戶需求
- 專案轉變成產品快捷之路在哪裡?
- 專案管理從改變團隊開始 (轉)專案管理
- 將專案經理轉變成企業領導(1)(轉)
- 將專案經理轉變成企業領導(2)(轉)
- vue專案npm run build之後部署伺服器無介面顯示不能正常執行專案,但是npm run dev 可以。...VueNPMUI伺服器dev