二、需求不斷改變
第二個讓我作為CIO非常頭痛的考驗是：即使大家都盡了最大的努力，還是有很多因素會導致ERP項目需求經常發生變化。例如，新的業務需求被提出;原先的需求調研考慮不周;業務的流程改弦更換等，而且新涌現的軟件技術通常也會帶來更多的需求變化。
需求不斷發生變化，這對任何ERP項目來說都是不可避免的狀況。其背后的動機是為了讓業務流程更順暢和用戶操作更方便。然而，ERP項目周詳的需求計劃是建立在項目調研的基礎之上，且該調研所確立的需求是建立在具體的業務要求之上。項目需求的改變會影響到項目進度及項目成本，因此上線實施計劃也需要更新，而擬定的最終期限可能需要延期。
項目需求出現大變動，新增加了大量功能往往會直接導致項目延期。這個時候，特別是在項目后期增加需求往往會使項目進度變得更糟糕。剛剛面臨這個問題的時候，我也沒有很好的應對辦法，加班趕進度成為了最常用的措施。但這措施讓整個項目組差點處于崩潰狀態，整個項目組成員忙于四處救火。
經過幾次痛苦的經歷后，我們改變了做法。作為CIO一定要搞清楚，是需求發生變化了、被修改了，還是有所補充和完善，抑或是被其他需求所取代，還是說一直保持穩定沒有變過。如果某部門一直在改變需求，那就要懷疑他們是否真的知道自己要的需求是什么。需求不明確這種癥狀是ERP項目出現問題的前期征兆，它預示著在項目預備階段就有可能蘊藏著深層次的矛盾和問題。
在后來的ERP項目實施中，我們明確了變更需求的流程，以及何時需要應用這一流程。這樣的流程可以讓相關方了解，未來的需求變更將要求項目團隊再次發布項目需求。在需求發生改變之初，讓需求變更提出方了解它將對成本、利益和ERP項目本身造成的影響。用戶或利益相關者可以在這些事實的基礎上做出是否更改需求的決策。
需求變更往往會導致項目范圍的變動而影響項目進度，因此在項目管理過程中我們對變更的管理形成一套完善的管理，分析和控制機制，成立需求變更控制小組專門針對變更進行分析，調查和處理。
三、項目進度停滯不前
當我作為CIO第一次聽到ERP項目已經完成了80%，覺得異常興奮和開心。我已經做好了在定期的進度報告和進度會議上予以匯報的準備。然而，這個時候，我碰到了第三個頭痛的考驗，就是進度報告可能會存在若干問題。該數據通常都是建立在對項目的不精確評估之上，或出自于項目經理、項目協調員的直覺。剩下20%有多復雜依然是個未知數，而且這個看起來較小的百分比還有可能讓人掉以輕心。
事實上，許多ERP項目都可能會滯留在這個階段。當項目進度在快要結束前的期間內停滯不前時，我們就需要深挖其中的原因了。另一個預警信號是，項目進度突然驟減。例如，某個項目正以每周完成10%的速度前進，而突然間你發現進度降到了1%或2%。這個時候項目小組也許才剛剛開始認真研究真正的項目需求。
當項目進度走下坡路的時候，可能是由于新的項目需求所導致的，也可能是早期的進度匯報不真實的結果。通常，我們所看到的下降比率可能并不會很低，因為項目團隊出于主觀愿望，會對進度報告進行一些修飾。所以問題可能遠比報告上所顯示的要嚴重得多。
我們的解決方法是必須借助項目救助方案。當ERP項目正處于停滯不前或者下滑狀態時，項目救助方案是一項旨在迅速改變其方向的階段性的應對措施。