與ERP、SCM等一樣，CRM項目中也有不少棘手的技術問題，尤其是當這個項目遇上與其他客戶或者內部系統進行整合時。在面臨標準化、系統清理和數據轉換時，這些項目就成了勞動密集型。但在大多CRM項目中，那還不是延誤工期的最大的問題。
事實上，CRM項目越大，來自IT技術之外的耽擱工期的影響因素也就越多。因為CRM項目的關鍵問題就是取得準入權。CRM團隊期待得到客戶的反饋、政策決策或者管理層的支持。在上述這些方面，CRM項目比大多數企業的其他項目更加容易受到影響，例如，相比于財務或是人力資源系統，CRM項目所需的必要條件和商業計劃更具可變性。一旦與商業政策和銷售，以及市場部經理的個人表現保持緊密一致 ，CRM系統則能夠表現出大部分商業優勢，為此最重要的是組織策略。然而，伴隨著頻繁發生的銷售、市場方面的重組，難免會有一些重要項目發生變化。因此，迅速、明確和廣泛的溝通等這些因素結合起來才是CRM項目贏得成功的關鍵 。
一、用戶反饋
衡量CRM系統的關鍵尺度是用戶是否采用該系統。不要相信提前掌握用戶資源并且收集他們的反饋信息是常規情況下避免浪費和返工的最好辦法。在我們的CRM項目中，我們總是每星期讓用戶了解項目的進度。為什么這么頻繁?因為用戶也很忙，他們可能會忘記曾經訴過你什么。進一步而言，由于他們的個人目標和工作目標會隨著時間的推移而變化，因此，很難使他們把注意力集中在你想要他集中注意力的話題上。逐漸收集反饋信息，并且將這些信息在網絡日志上公布將會改進輸入數據的質量和相關性。
同樣地，從正確的用戶手中收集反饋信息也非常重要。有時，有時間對于功能的可用性進行討論的人并不是對整件事情有重大影響的人。但也有些時候，愛挑剔的人并不一定是真正制定標準的人。所以，選擇適當的使用者從某種意義上講是一種藝術，不過，這種藝術并非是項目領導必須學習的。盡管反饋用戶的特點根據他們所屬組織的不同而有所不同，但我們仍可以總結出如下一些經驗，例如：負責反饋信息的團隊應該是在項目組建之初就經過挑選的，并且由團隊經理正式授權每周(或者是在你所需要的任何時間周期)進行反饋，這么做的前提是搞清楚所做的項目在多長時間內需要反饋信息。應該至少試著讓團隊在一個自然的周期內保持穩定。
一般而言，團隊有三個領域應該平衡發展：一個是熟練掌握計算機技能的人；另一個是熟練工人；最后一個是深入其他系統工作同時參加CRM項目的人。
一方面， 團隊應該適當集中權利。許多總結工作應該通過網絡進行(在某些情況下必須保持完全地切合實際)，如此的話，在團隊偏離軌道或就不同問題產生分歧時就會更容易進行協調和安排。
另一方面，項目團隊應該由善于聽取不同意見的人組成。如果項目的管理者充分信任他的代表者，最后的決定和被認可的周期計劃可以很快被實施;如果這些代表者在小事上能夠在項目團隊面前進行決策，那就更加事半功倍。而對于傀儡代表者則要多加小心，這種代表者的領導往往過多地控制權力，有時甚至與他的代表產生分歧。
在個人會議上收集用戶反饋信息效率要高得多。當然，組織周期對于工程時間是重要的參考，但是如果根據某一次會議制訂項目進度表將會更加糟糕?；ㄒ粋€星期的時間試著召開一次多方協調會議，在會上解決交通擁堵的辦法會阻礙部分項目的進展，甚至讓項目工程師無所事事。
二、管理層決定
CRM項目取得成功的關鍵是企業管理層做出的4P(項目重點，政策指示，人員因素，項目進程) 。決定越是重要，召開會議占用的時間越長，對于項目進度的改變產生的影響當然也就越大。
另外，有一點是十分重要的，就是項目領導者應該能夠像很好地聽取IT領導者的意見一樣很好地聽取CRM項目主管經理的意見 。項目的具體問題取決于組織文化。一般地，最好是召開短小、迅速決策的會議，避免突發奇想地召開高層會議。雖然CRM項目有時候也需要一個大型的會議，但沒有必要召開得太過頻繁，因為這樣容易使會議的主題偏離真正需要討論并作出決定的具體問題。我們都經歷過這樣的會議：在會議上，前一次會議作出的決策被徹底推翻，以前制定的項目進度表完全作廢。
總而言之，不管高層作出如何決策，為了減少誤會和巧言令色的推托責任，最好在會議上準備好簽字表，再將會議作出的決策在網絡日志上公布出來 。
