成功專案經理的經驗教訓——鼓勵靈活的體制和行為(轉)
保證苛刻的專案進度但不使用複雜的網路進度表
這個專案的進度非常緊,我真的覺得很緊。我們知道,我們無法承受太多的驚奇,因此決定將按時完成專案定為主要目標。為了實現這個目標,我們達成共識,拋開所有個人和職業興趣,通力合作,成為一個密切配合的團隊。另外,我們還決定,如需要,儘量少用正式的程式和一成不變的計劃,我們需要非常靈活的機制,這樣才能迅速解決所出現的問題。但是,考慮到這個專案的限制,我知道需要承包商提供一份詳細的進度表,從而實現有效的時間管理。合同規定,承包商必須提交一份關鍵路徑法(CPM)網路進度表,我們所需的CPM應該是經過仔細分析制定出來的,它用圖形的方式表示成功完成專案所必需的各專案事件的順序。關鍵路徑管理失敗將給專案的及時完成帶來災難性的後果。
按照常規程式,如果專案進度表未獲得批准,承包商不允許動工。但是,由於我們良好的合作氛圍和啟動工作的緊迫性,我摒棄了常規程式,允許承包商一邊開發他的進度表,一邊開展現場工作。而且,承包商承諾他將提交CPM。
在現場工作執行過程中,我們的團隊——由我的工程和建築人員、客戶、承包商組成——解決了許多問題。為了滿足新的規範要求,我們重新設計了灑水器系統,用先進的法國排水裝置,解決了主要的現場排水問題;並重新處理了控制室下的混凝土板,來解決土壤問題。在專案的最終驗收之前,我們團隊總共解決了200多個問題。但是,有一項從未得到滿意的解決,那就是CPM進度表。
對於所有專案來說,成功的主要特徵是工作按時完成、質量符合要求、成本控制在預算之內。這種沒有網路式專案進度表的專案的成功違反了傳統專案管理的成果。一直以來,嚴格按照進度表開展工作是按時完成專案的必要保證。精心準備的CPM網路進度表通常是用來保證專案進度的,但自始自終,我們從未收到過這樣一份高質量的進度表。承包商曾多次嘗試著制定完整的CPM,但是,由於現場施工節奏很快,每一份CPM都是在尚未來提交時即已過時。假如精明的進度管理是成功的關鍵,那麼我們如何能在沒有CPM的情況下按時完成這個專案的呢?
在專案完成許久之後,我開始反思這個問題。我記得我們也曾強硬地向承包商索要過CPM,我也記得承包商和團隊的其餘人員合作得非常好,在沒有CPM的情況下良好地安排了主要專案事件。承包商曾承諾儘快遞交一份完善、最新的CPM,但好幾個星期過去了,我也沒有向他們索要CPM。對於這個專案的所有參與人員來說,幸運的是,我們一個接一個地解決了其他問題,沒有讓缺乏CPM成為主要的爭論問題。
這個專案獲得成功的真正原因是,我們及時地解決了那200多個主要問題。如果有一個問題未能得到及時解決,都會使進度產生不確定性,可能使這個專案失敗。在質量控制週會(實際上是計劃和審查會議)上,我們都會盡力找出不確定區域,並在接下來的一週內解決它們,以使專案一直處於正軌狀態。有些項,如放火系統,可能知道專案的最後階段才會出現在關鍵路徑上,如果我們一直等到該項成為關鍵項才開始重新設計,那麼灑水器系統的重新設計工作將為時已晚,專案也永遠不可能準時完成。專案固有的特徵和速度會導致許多問題和不確定性,這就使得我們不可能提交全面、詳細和有用的計劃。專案團隊只有進行全面合作,找出不確定區域,然後及時解決這些問題,才能使專案獲得成功。
即使如此,我們也沒有完全將進度表丟擲窗外。我們原有的甘特圖起了非常大的作用,而且我們先後收到過多份承包商盡最大努力提交上來的CPM,儘管這些網路圖有缺陷,可能已過時,但是對於計劃和時間分析來說,它們已包含了足夠的進度資訊。另外,我們每週的審查發現了許多問題,而這些問題揭示了專案不確定性的其他區域。經過最終分析,我們認為,問題清單、不完善的進度表、週會和靈活機制,對於這個專案的非常成功的時間管理和及時解決問題,起了重大作用。
經驗教訓
——在快節奏、充滿不確定性的專案中,靈活性是關鍵。應最低程度地利用正規程式。
——如果今天不集中精力管理不確定性任務,明天,它們就將建立新的關鍵路徑。因此,成功的專案領導者首先集中精力、密切地關注不確定性任務,並及時採取措施來降低其不確定性。
——不確定性越高,所需的規劃過程及其輸出(計劃)的正式化程度越低。當不確定性非常高時,大量的規劃是透過頻繁的面對面會議來完成的。
——假定用於安排專案進度的完美網路模型能快速容納變化,那麼它可以得到極致的發揮。即,如果採用了這樣的模型,一旦建立了計劃,計劃的更新就會相對較容易,當然,這還必須假定計劃的大多數變化能夠解決專案活動的工時問題。但是,在多數專案中,尤其是那些充滿不確定性的專案中,網路邏輯本身就不斷地發生巨大而不可預期的變化,也就是說,活動間的順序和關係必須頻繁修改,而且活動的範圍常常大幅度擴大或縮小,甚至會新增新的活動。這就使得更新難以簡單而快速地進行,況且在多數實際情形中,頻繁的大幅度修改更接近於制定計劃,而不是日常更新。
[@more@]
這個專案的進度非常緊,我真的覺得很緊。我們知道,我們無法承受太多的驚奇,因此決定將按時完成專案定為主要目標。為了實現這個目標,我們達成共識,拋開所有個人和職業興趣,通力合作,成為一個密切配合的團隊。另外,我們還決定,如需要,儘量少用正式的程式和一成不變的計劃,我們需要非常靈活的機制,這樣才能迅速解決所出現的問題。但是,考慮到這個專案的限制,我知道需要承包商提供一份詳細的進度表,從而實現有效的時間管理。合同規定,承包商必須提交一份關鍵路徑法(CPM)網路進度表,我們所需的CPM應該是經過仔細分析制定出來的,它用圖形的方式表示成功完成專案所必需的各專案事件的順序。關鍵路徑管理失敗將給專案的及時完成帶來災難性的後果。
按照常規程式,如果專案進度表未獲得批准,承包商不允許動工。但是,由於我們良好的合作氛圍和啟動工作的緊迫性,我摒棄了常規程式,允許承包商一邊開發他的進度表,一邊開展現場工作。而且,承包商承諾他將提交CPM。
在現場工作執行過程中,我們的團隊——由我的工程和建築人員、客戶、承包商組成——解決了許多問題。為了滿足新的規範要求,我們重新設計了灑水器系統,用先進的法國排水裝置,解決了主要的現場排水問題;並重新處理了控制室下的混凝土板,來解決土壤問題。在專案的最終驗收之前,我們團隊總共解決了200多個問題。但是,有一項從未得到滿意的解決,那就是CPM進度表。
對於所有專案來說,成功的主要特徵是工作按時完成、質量符合要求、成本控制在預算之內。這種沒有網路式專案進度表的專案的成功違反了傳統專案管理的成果。一直以來,嚴格按照進度表開展工作是按時完成專案的必要保證。精心準備的CPM網路進度表通常是用來保證專案進度的,但自始自終,我們從未收到過這樣一份高質量的進度表。承包商曾多次嘗試著制定完整的CPM,但是,由於現場施工節奏很快,每一份CPM都是在尚未來提交時即已過時。假如精明的進度管理是成功的關鍵,那麼我們如何能在沒有CPM的情況下按時完成這個專案的呢?
在專案完成許久之後,我開始反思這個問題。我記得我們也曾強硬地向承包商索要過CPM,我也記得承包商和團隊的其餘人員合作得非常好,在沒有CPM的情況下良好地安排了主要專案事件。承包商曾承諾儘快遞交一份完善、最新的CPM,但好幾個星期過去了,我也沒有向他們索要CPM。對於這個專案的所有參與人員來說,幸運的是,我們一個接一個地解決了其他問題,沒有讓缺乏CPM成為主要的爭論問題。
這個專案獲得成功的真正原因是,我們及時地解決了那200多個主要問題。如果有一個問題未能得到及時解決,都會使進度產生不確定性,可能使這個專案失敗。在質量控制週會(實際上是計劃和審查會議)上,我們都會盡力找出不確定區域,並在接下來的一週內解決它們,以使專案一直處於正軌狀態。有些項,如放火系統,可能知道專案的最後階段才會出現在關鍵路徑上,如果我們一直等到該項成為關鍵項才開始重新設計,那麼灑水器系統的重新設計工作將為時已晚,專案也永遠不可能準時完成。專案固有的特徵和速度會導致許多問題和不確定性,這就使得我們不可能提交全面、詳細和有用的計劃。專案團隊只有進行全面合作,找出不確定區域,然後及時解決這些問題,才能使專案獲得成功。
即使如此,我們也沒有完全將進度表丟擲窗外。我們原有的甘特圖起了非常大的作用,而且我們先後收到過多份承包商盡最大努力提交上來的CPM,儘管這些網路圖有缺陷,可能已過時,但是對於計劃和時間分析來說,它們已包含了足夠的進度資訊。另外,我們每週的審查發現了許多問題,而這些問題揭示了專案不確定性的其他區域。經過最終分析,我們認為,問題清單、不完善的進度表、週會和靈活機制,對於這個專案的非常成功的時間管理和及時解決問題,起了重大作用。
經驗教訓
——在快節奏、充滿不確定性的專案中,靈活性是關鍵。應最低程度地利用正規程式。
——如果今天不集中精力管理不確定性任務,明天,它們就將建立新的關鍵路徑。因此,成功的專案領導者首先集中精力、密切地關注不確定性任務,並及時採取措施來降低其不確定性。
——不確定性越高,所需的規劃過程及其輸出(計劃)的正式化程度越低。當不確定性非常高時,大量的規劃是透過頻繁的面對面會議來完成的。
——假定用於安排專案進度的完美網路模型能快速容納變化,那麼它可以得到極致的發揮。即,如果採用了這樣的模型,一旦建立了計劃,計劃的更新就會相對較容易,當然,這還必須假定計劃的大多數變化能夠解決專案活動的工時問題。但是,在多數專案中,尤其是那些充滿不確定性的專案中,網路邏輯本身就不斷地發生巨大而不可預期的變化,也就是說,活動間的順序和關係必須頻繁修改,而且活動的範圍常常大幅度擴大或縮小,甚至會新增新的活動。這就使得更新難以簡單而快速地進行,況且在多數實際情形中,頻繁的大幅度修改更接近於制定計劃,而不是日常更新。
[@more@]
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/7839396/viewspace-945347/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- [轉貼]:軟體過程改進:經驗和教訓
- 我的軟體開發中經驗教訓
- 來說說成功的雲遷移的10個經驗教訓
- 經驗分享:HelloFresh在生產中執行Istio的經驗教訓 - Craig HuberAI
- 經驗&教訓分享:我的第一個機器學習專案機器學習
- 20+條軟體開發的經驗教訓
- 大規模執行 Apache Airflow 的經驗教訓 - shopifyApacheAI
- 【經理人領導力突破訓練營】經理人必修課,如何成為成功的經理人?
- Supercell成立10週年的10條經驗和教訓
- [譯] Data Binding 庫使用的經驗教訓
- Heap使用Postgres SQL後的經驗教訓SQL
- 安裝pytorch-gpu的經驗與教訓PyTorchGPU
- 成功實現邊緣編碼需要了解的六大經驗教訓
- 產品經理和專案經理誰是專案管理工具的大神?專案管理
- Salesforce使用Spring Data Redis記憶體洩漏的經驗教訓SalesforceSpringRedis記憶體
- 來自10位 IT 大牛的23條經驗教訓
- 「譯文」Google SRE 二十年的經驗教訓Go
- Go 併發程式設計中的經驗教訓Go程式設計
- 專案經理值得一試的思維方式:專案成功方程式
- 不會玩魔獸的專案經理不是好專案經理
- 【經驗帖】專案經理的核心價值:以目標為導向做正確的事
- 初入軟體「江湖」的萌新需要了解的五個經驗教訓
- 《神鬼寓言》的開發中有些什麼經驗教訓?
- 《軟體專案經驗總結》
- 單人專案管理的心得和教訓專案管理
- 在K8s上運維Java和GC的經驗教訓 - CoufalK8S運維JavaGC
- 產品經理和專案經理有什麼區別
- 產品經理和專案經理區別與聯絡
- 經驗教訓:Instacart 的實時機器學習之旅 - shu機器學習
- 火爆全網的ChatGPT 和AI 可以為專案經理做什麼?ChatGPTAI
- 【原創】09.11.17老谷專案管理msn群的主題,職能經理和專案經理如何配合?專案管理
- 企業在機器學習應用中需要吸取的經驗和教訓機器學習
- 企業專案經理用的專案管理軟體怎麼選專案管理
- Avionos報告:網路品牌和傳統零售商的經驗和教訓
- 【專案經驗】--環保專案
- 波音公司架構師分享MDM專案成功經驗FJ架構
- 從1100多個專案中吸取的教訓:為什麼軟體專案需要英雄?
- 阿里巴巴的 Kubernetes 應用管理實踐經驗與教訓阿里
- 使用Go兩年學到的五大經驗教訓 - hashnodeGo