專案管理要遵守3C原則(轉)
一個專案組要獲得成功必須遵守三個“C”原則: 預定的目標“明確”(Clarity),團隊成員對完成任務有“承諾”(Commitment) ,對成員的工作表現給予相應的“獎懲”(Consequence)。
有一個專案經理負責實施一項顧客服務計劃,其中包括大量的資訊處理工作。為了提高資訊處理人員的工作效率,這位專案經理不厭其煩地向上級強調:為了確保計劃的成功,專案經理們需要更大的權力。
這位專案經理最終獲得了授權,他可以直接管理專案組成員的工作,並有權根據他們的工作表現給予獎勵,那一天成了公司裡所有專案經理的節日。
可是第二天,新鮮勁兒一過,這位經理又為如何使用這些新的權力犯上了愁。到底應該何時評估專案組成員的業績呢?是在每一項任務結束後,還是在整個計劃完成之後?應該如何把握監控的分寸?
深思熟慮之後,這位專案經理決定根據每人編寫的編碼行數來評估資訊處理人員的工作業績。凡是達到標準的成員都能從他那裡得到一定的獎金。
不難預料,資訊處理人員們寫出了數千行的編碼,編制出的程式數量令人咋舌,因而人人都得到了那筆獎金。同樣不難想象,這樣編制出來的系統最終不能對顧客服務起到任何促進作用。結果,那位專案經理被解職了事。更糟的是,自他之後,再也沒有一名專案經理獲得過直接管理專案組成員的權力。
這個故事的寓意之一就是: 軟體編碼工作儘管非常重要,但是卻不能作為評估的標準。真正的標準應該是最佳化顧客服務。那位專案主管本應評估每個成員對促進顧客服務所做的貢獻大小,並據此給予獎勵,而不該只看編碼的數量。這就是“以績定酬”的專案管理方法。
這個故事的另一個寓意是: 無論你使用何種評估標準,都應該注意獎勵的“力度”。只有當你掌握了設定業績目標的藝術之後,才能為完成指標者論功行賞。
遺憾的是,許多專案經理一旦發現自己的評估標準出了差錯,往往會放棄所有評估手段。他們經常在事後根據工作的結果,對有關人員的表現給出一個主觀的評價。這種做法嚴重違反了一個專案組獲得成功所必須遵守的“三個‘C’原則”:預定的目標不夠“明確”(Clarity),團隊成員缺少對完成任務的“承諾”(Commitment),對成員的工作表現不能給予相應的“獎懲”(Consequence)。
這種“無為而治”的方式對專案組的危害尤甚。幹好幹壞一個樣,人們就會喪失努力工作的積極性。而如果人們根本不清楚自己的責任和目標的話,他們就會想:“我先隨便設計一些什麼東西算了,反正專案經理要到進度完成一半的時候才能把目標確定下來。”所以,使用錯誤的評估標準與“無為而治”方式同樣會招致麻煩。只有進行恰如其分的業績評估才能解決這些問題。
在過程與目標之間實際上存在著很大的區別。在前文述及的例子中,編碼只是為了達到預期目標的一個必要過程,而預期目標則可能是:保證這一系統的使用者在30秒之內就能獲得過去6個月的客戶交易記錄。
你若能夠以這樣的工作目標為尺度去管理專案組的成員,就完全不必擔心會使用錯誤的評估標準了。你已經向他們提出了明確的工作目標,這樣一來,你就可以根據預期目標對他們的工作表現給予相應的獎懲。
把一個總體工作目標分解到個人並非易事,但卻非常值得一試,在管理的過程中,始終把既定的工作目標作為核心,就能夠符合“3C”原則的要求:明確提出了預定工作目標,得到了團隊成員的承諾,並根據各人的工作完成情況給予相應的獎懲。
作為一名專案經理所必須做出的第二個決策就是對員工的獎懲力度。你當然不會把所有沒能完成工作業績指標的人員統統解僱,同樣,對於一個可以在一個月內完成的工作計劃,你也不應該開出一筆相當於半年工資的高額獎金。
這就是把握獎懲力度的問題。與成績掛鉤的獎懲力度越大,成員們工作態度的改善也就應該越大。一方面,你要讓你的屬下了解,對他們的獎懲是與他們的工作表現密切相聯的。成績突出的人員應該能夠看到,他們的表現得到了管理層的首肯並獲得了相應的獎勵。而那些表現欠佳的人也應當意識到,管理層對他們的表現心知肚明。
但是,與業績掛鉤的獎懲力度也不應過大。否則,員工們會變得對沒有獎金的工作漠不關心。優秀的專案經理應該制定合適的獎勵結構,做到金錢獎勵與非金錢獎勵相結合。根據不同人員心理承受能力的不同,確定與業績掛鉤的“風險獎金”在其全部獎勵中所佔的比例。
如果你身處一種“福利型”的企業文化之中,人們還不適應這種“以績定酬”的獎勵制度,你就必須循序漸進。一開始,與業績掛鉤的獎金比例應相應較小。隨著人們承受能力的增強和工作表現的進步,再逐漸提高“風險獎金”所佔的比例。 [@more@]
有一個專案經理負責實施一項顧客服務計劃,其中包括大量的資訊處理工作。為了提高資訊處理人員的工作效率,這位專案經理不厭其煩地向上級強調:為了確保計劃的成功,專案經理們需要更大的權力。
這位專案經理最終獲得了授權,他可以直接管理專案組成員的工作,並有權根據他們的工作表現給予獎勵,那一天成了公司裡所有專案經理的節日。
可是第二天,新鮮勁兒一過,這位經理又為如何使用這些新的權力犯上了愁。到底應該何時評估專案組成員的業績呢?是在每一項任務結束後,還是在整個計劃完成之後?應該如何把握監控的分寸?
深思熟慮之後,這位專案經理決定根據每人編寫的編碼行數來評估資訊處理人員的工作業績。凡是達到標準的成員都能從他那裡得到一定的獎金。
不難預料,資訊處理人員們寫出了數千行的編碼,編制出的程式數量令人咋舌,因而人人都得到了那筆獎金。同樣不難想象,這樣編制出來的系統最終不能對顧客服務起到任何促進作用。結果,那位專案經理被解職了事。更糟的是,自他之後,再也沒有一名專案經理獲得過直接管理專案組成員的權力。
這個故事的寓意之一就是: 軟體編碼工作儘管非常重要,但是卻不能作為評估的標準。真正的標準應該是最佳化顧客服務。那位專案主管本應評估每個成員對促進顧客服務所做的貢獻大小,並據此給予獎勵,而不該只看編碼的數量。這就是“以績定酬”的專案管理方法。
這個故事的另一個寓意是: 無論你使用何種評估標準,都應該注意獎勵的“力度”。只有當你掌握了設定業績目標的藝術之後,才能為完成指標者論功行賞。
遺憾的是,許多專案經理一旦發現自己的評估標準出了差錯,往往會放棄所有評估手段。他們經常在事後根據工作的結果,對有關人員的表現給出一個主觀的評價。這種做法嚴重違反了一個專案組獲得成功所必須遵守的“三個‘C’原則”:預定的目標不夠“明確”(Clarity),團隊成員缺少對完成任務的“承諾”(Commitment),對成員的工作表現不能給予相應的“獎懲”(Consequence)。
這種“無為而治”的方式對專案組的危害尤甚。幹好幹壞一個樣,人們就會喪失努力工作的積極性。而如果人們根本不清楚自己的責任和目標的話,他們就會想:“我先隨便設計一些什麼東西算了,反正專案經理要到進度完成一半的時候才能把目標確定下來。”所以,使用錯誤的評估標準與“無為而治”方式同樣會招致麻煩。只有進行恰如其分的業績評估才能解決這些問題。
在過程與目標之間實際上存在著很大的區別。在前文述及的例子中,編碼只是為了達到預期目標的一個必要過程,而預期目標則可能是:保證這一系統的使用者在30秒之內就能獲得過去6個月的客戶交易記錄。
你若能夠以這樣的工作目標為尺度去管理專案組的成員,就完全不必擔心會使用錯誤的評估標準了。你已經向他們提出了明確的工作目標,這樣一來,你就可以根據預期目標對他們的工作表現給予相應的獎懲。
把一個總體工作目標分解到個人並非易事,但卻非常值得一試,在管理的過程中,始終把既定的工作目標作為核心,就能夠符合“3C”原則的要求:明確提出了預定工作目標,得到了團隊成員的承諾,並根據各人的工作完成情況給予相應的獎懲。
作為一名專案經理所必須做出的第二個決策就是對員工的獎懲力度。你當然不會把所有沒能完成工作業績指標的人員統統解僱,同樣,對於一個可以在一個月內完成的工作計劃,你也不應該開出一筆相當於半年工資的高額獎金。
這就是把握獎懲力度的問題。與成績掛鉤的獎懲力度越大,成員們工作態度的改善也就應該越大。一方面,你要讓你的屬下了解,對他們的獎懲是與他們的工作表現密切相聯的。成績突出的人員應該能夠看到,他們的表現得到了管理層的首肯並獲得了相應的獎勵。而那些表現欠佳的人也應當意識到,管理層對他們的表現心知肚明。
但是,與業績掛鉤的獎懲力度也不應過大。否則,員工們會變得對沒有獎金的工作漠不關心。優秀的專案經理應該制定合適的獎勵結構,做到金錢獎勵與非金錢獎勵相結合。根據不同人員心理承受能力的不同,確定與業績掛鉤的“風險獎金”在其全部獎勵中所佔的比例。
如果你身處一種“福利型”的企業文化之中,人們還不適應這種“以績定酬”的獎勵制度,你就必須循序漸進。一開始,與業績掛鉤的獎金比例應相應較小。隨著人們承受能力的增強和工作表現的進步,再逐漸提高“風險獎金”所佔的比例。 [@more@]
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/7839396/viewspace-960235/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 專案管理重要原則(轉)專案管理
- 投資專案管理原則(轉)專案管理
- 軟體專案管理原則談(轉)專案管理
- 施工專案管理的四“精”原則(轉)專案管理
- 專案管理十二原則專案管理
- 選擇檔案擺渡系統要遵守的“三要”和“三不要”原則
- 專案管理要點(轉)專案管理
- 專案管理的七大原則(一)(轉)專案管理
- 專案管理的七大原則(二)(轉)專案管理
- 專案管理應遵循的幾個原則(1)(轉)專案管理
- 專案管理應遵循的幾個原則(2)(轉)專案管理
- 專案管理應遵循的幾個原則(3)(轉)專案管理
- 專案管理應遵循的幾個原則(4)(轉)專案管理
- 資訊化專案管理的原則專案管理
- 專案管理8要點(轉)專案管理
- 專案管理8要點 (轉)專案管理
- 專案管理八要點(轉)專案管理
- 專案管理成功的10個關鍵原則(轉)專案管理
- 專案管理成功的12個關鍵原則(轉)專案管理
- 做好專案管理通則(轉)專案管理
- IT專案管理中的原則問題專案管理
- 系統整合資質–IT專案管理中要遵循的溝通原則薦專案管理
- 工程專案施工管理細則(轉)
- 專案範圍管理的精益原則
- 外包專案管理技術要點(轉)專案管理
- 專案團隊組建的原則(轉)
- 專案組織規劃的原則(轉)
- 專案管理溝通的原則是有哪些?專案管理
- 經典專案管理原則--需深刻理解專案管理
- 專案經理成功管理8要點(轉)
- 專案成功的12個關鍵原則 (轉)
- 專案成功的12個關鍵原則(轉)
- 鮮為人知的軟體專案管理原則專案管理
- 專案管理中,應該注意的5點原則專案管理
- 專案管理成功的12個關鍵原則專案管理
- 14項管理原則(轉載)
- mysql資料庫最佳化需要遵守的原則MySql資料庫
- 專案合同管理中要學習體會(轉)