對有PLM實施經驗的用戶，很容易理解上述圍繞項目組織/范圍與預算/資源/技術與產品等方面在項目計劃階段制訂風險管理計劃的重要性。只有針對上述方面可能發生的問題建立起必要的應對計劃和策略，才有可能做到事前風險管理，而不是事后問題管理。做到未雨綢繆，而不是亡羊補牢。盡管亡羊補牢也是風險管理的策略之一，但PLM項目管理強調的更多的是在未雨綢繆的基礎上，再做亡羊補牢抑或其它更積極主動的決策。
PLM項目執行與控制階段-“非知之艱，行之惟艱”
在項目啟動階段，對項目風險進行了識別分析;以此為基礎，項目規劃階段制訂了項目風險管理計劃，從理論上講，項目在執行與控制階段，只要嚴格按照項目風險管理計劃來開展工作應該取得令人滿意的結果。但在項目實際運作過程中，這恰恰是容易出問題的階段。究其原因可以總結如下：
1) 項目執行是一個動態的過程，一些原本存在的風險可能會隨著其存在基礎的消失而湮滅;一些原本低優先級別的風險會因其發生的可能性或帶來影響的變化而變成高優先級別的風險;一些原本不存在的風險也會隨之而產生。這無疑加大了風險管理的難度;
2) 項目管理組在項目執行過程中通常會陷入到項目日常管理的瑣碎工作中。項目執行過程已經把項目經理折磨得苦不堪言，項目經理縱有控制未來風險的強烈愿望，無奈項目執行自身的壓力導致其必須先著手眼前的項目布局，至于未來項目中潛在的風險，權且不聞/不問才好。當然項目經理還是會經常想想未來潛在的風險的，但應對策略是且等風險變成問題找上門再說;
3) 在風險處置過程中，由于原來風險管理計劃中具體風險應對策略的欠缺，導致風險處置不力。而此時如果項目組得不到有力的支持與協助，則給項目管理層帶來風險管理的嚴重挫折感。故此項目管理層難以再投時間和精力在項目風險的管理上。
凡此種種，無不是執行層面風險管理“知易行難”的具體體現，其造成的結果自然是項目管理計劃束之高閣。事前風險管理又變化為事后亡羊補牢式的管理。而這又導致客戶和實施顧問團隊雙方都不得不投入更多的時間、人力、物力和財力去化解危機，終導致事倍功半的消極結果。
解決“知易行難”問題的好辦法其實也是簡單的辦法，其實是采用RISK LOG的方式(也叫RISK REGISTER)對所有已確認的風險進行記錄，并定期給出分析從而確定各風險的優先級別，然后對每個風險條目給出建議的處置計劃、負責人員、希望解決的完成時間。同時對識別出的新的風險及時記錄在案，而對可以關閉的風險，則標記其為“已關閉”、同時給出關閉的確切時間和風險關閉的確認人。
需要指出的是：任何項目成員包括項目經理，在多項任務纏身，必須在任務之間進行取舍時，往往主要精力會關注已經火燒眉毛需要迫切解決的問題，而對于未來才可能發生的風險，會傾向于采用繞過去走捷徑的做法。而這勢必造成未來有更多緊迫的問題需要解決。
其實這種關注眼前任務的做法是人們在壓力面前采取的非常自然的一種應對策略。盡管不是項目風險管理中期待看到的做法，但卻是大多數人的天性。這性盡管無可后非，但在項目風險管理過程中，項目管理層應該予以充分的認識，并在此基礎上對其進行有效的規避。為此，從項目組織的角度建立日常規范的項目風險管理機制(定期會議/溝通/通報等方式)成了極為重要的工作了。這樣可以通過組織的行為去避免個人行為中的薄弱環節，實現組織優勢與個人優勢的恰當結合，并以組織行為去督促項目管理層能持續不斷地對項目各種風險進行有效的管理。
PLM項目結案-“行百里者半九十”
項目結案通常會帶來一種錯覺，似乎只要能把結案會一開，客戶方和項目實施顧問方一切都萬事大吉了。但真正做過項目的項目經理都知道，項目結案其實是項目危險的階段：此時所有的系統內容都已經展示給終用戶，而此階段產生的問題更需要以盡可能快的速度予以響應或解決。但此時無論在時間上還是經費上留給項目組的空間已經非常有限。
圍繞項目結案的工作需要考慮結案前系統上線過程的風險，還需要考慮項目結案后系統運行維護期間可能遇到的風險。但無論是結案前還是結案后的風險都必須事先做好風險識別、分析、制訂風險管理計劃和對風險加以處置等工作。而如果向前追溯的話，許多應對與規劃工作必須在項目啟動與計劃階段加以完成。
1. 項目結案前：
項目結案前的系統上線工作是項目能否成功的重點：處置不當，會導致項目發生嚴重的拖期乃至于項目的失敗。此時需要重點考慮：
1) 對應既定方案的系統是否與企業的實際業務過程關聯在一起，如果沒有，項目組應對的策略是什么;
2) 相關的歷史數據準備工作是否完成以及所準備數據的正確性是否通過恰當的評估;
3) 正式生產服務器是否已經準備緒，并經過必要的性能調優;
4) 是否建立起系統切換的領導機構和問題處理處理機制并經過項目高層管理機構的批準;
5) 如何安排對終用戶進行必要的培訓，如何對培訓效果進行必要的考核;
6) 如何對用戶驗證測試過程中發現的問題制訂必須的處置策略;
7) 正式系統上線是否經過反復的預演，并根據預演的結果擬訂終確認無誤、切實可行的上線切換計劃;
8) 預留的系統切換時間是否足夠(對涉及需向ERP系統發數據的情況，此條尤為重要);
9) 在發生不可預見的問題時，項目組的備份方案是什么
2. 項目結案后：
以往項目執行過程中，一個常見的誤區在于：項目結案會一開，所有的事情萬事大吉了。其實項目的結案只能標記著項目執行的結束，而不能說PLM項目一定能平穩地投入到后續運行中了。系統的維護和技術支持工作是一個持續不斷的過程。對一些成熟的客戶，自己的隊伍在項目結束時，已經可以承擔起系統正常運維的工作了，而在項目結束后，通過正常渠道延展客戶方與顧問方的支持服務關系也不失為一種可行的做法。此時需要重點考慮如下問題：
1) 客戶是否具備獨立支持系統正常運作的能力和做系統改進調整的能力，如果沒有(倘如此，一定是在前期的風險管理中已經出現問題了)，如何在短期具備這樣的能力;
2) 基于已有的運行維護與支持能力，是否建立了一套行之有效的運行維護的管理過程，避免因系統未及時備份而帶來的嚴重損失(知易行難，很多企業在這方面都有過慘痛的教訓);
3) 如何保證在客戶遇到涉及產品本身問題，而不是開發訂制問題時，能夠從原廠商處得到必要的技術支持(一個典型案例：系統在正常運行1年半后，基于成本的考慮客戶沒有再購買必要的技術支持服務，當他們遇到系統問題時，所需的花費要比及早購買技術支持的花費大了許多，因為它包括了系統宕機帶來的實際損失)
這里有一條重要的現象需要指出：系統維護的早期正常投入，其代價通常會遠比問題發生后再加以解決所帶來的成本低得多。因此在項目結案后，客戶的系統運維支持部門需要時刻提醒自己：未來有當系統發生問題時，我們的對策是什么以及如何才能把對終用戶的影響降到低?這其實仍然是風險管理手段在項目結束后的繼續應用。
結語
回到本文開頭那句英文“We don’t go mountain climbing with a rope because we plan to fall， but we’d be all too grateful for the rope if we did.”。這里嘗試翻譯如下“我們不是因為我們打算墜入深淵而在登山時準備繩索，但在我們有過墜入深淵的體驗時，會感念登山繩索對我們的莫大救助”。其實PLM項目的風險管理何嘗不是我們登頂企業信息化時的救命繩索呢?
