(4)缺乏溝通計劃保障，需求目標容易走樣
需求的真實性固然重要，但我們應該明白需求調研不僅僅只是一種獲得信息真實性的溝通，而且是一種有計劃、有目標和有方向性的溝通。因此，要想獲得有效的溝通效果必須有計劃和有方向來保證。因此，單純的鼓勵溝通的真實性是不夠的，因為等級和權力的差別肯定會形成溝通阻礙。所以，當項目缺乏一套有效的溝通計劃時，調研需求的方向性容易得不到保證。因為對于單一需求的開發項目來說，需求的方向性是簡單、直接、明確的;而對于需求復雜的開發項目來說，由于每個獨特的項目都有其不同的目標和不同的需求方向，也決定了項目需求容易走樣。而也正因為目標需求容易走樣，不但容易導致后期需求頻繁的變更，也會導致需求確認的難度和復雜度都將大大增加。
二.避免陷入溝通管理不良泥潭的策略
所謂溝通，是人與人之間的思想和信息的交換，是將信息由一個人傳達給另一個人的過程。溝通看似簡單，但溝通管理不良幾乎是每個軟件開發項目都存在的老毛病。項目需求越是復雜，其溝通越是困難。往往基層的許多需求還未反饋至調研人員手中便已被層層扼殺，或是需求經過層層的傳達后常常無法以原貌展現在需求調研人員面前。因此，如何避免需求溝通不良是軟件開發項目管理的重中之重。
(1)成立一個需求決策小組
溝通的目的是為了調研和確認需求，因此在溝通管理上不應該本末倒置。在此項目失敗經過反思后，我認為應該要在項目需求調研之前，要召集一個雙方高層的會議。讓客戶方和開發方高層都參加，在會議中重申項目需求的重要性，并要求成立一個需求決策小組。這樣當遇到多頭溝通懸而不決的問題時，提交給項目需求決策小組討論并決策。這樣單一清楚的項目決策人或決策小組不但可以實現項目需求的溝通本質，也是成功項目運作的基礎。需求決策小組好由開發組高層和客戶方領導層組成。這不但是避免需求頻繁變更的關鍵一步，也是我在總結溝通管理時認為重要的事情之一。
(2)明確客戶方需求溝通接口人員
如果在項目開發合同簽訂時未明確客戶方對本項目的具體溝通負責人，那么迫切的是要先向客戶方領導強調客戶方要馬上組織一個團隊并指定一個負責人來管理，這個問題關系到整個項目的成敗與否。對這個團隊的要求是要有將來真正使用系統的業務專家，要有將來真正對這個系統實施管理的人，要有將來真正對這個系統實施維護的人(技術專家)。還要有一個溝通接口負責人，這個人要可以幫助協調客戶方相關人員并可以代表客戶方確認和簽署該項目的相關文檔。否則，當缺乏明確的溝通接口人員時會埋下很大的風險，陷入溝通管理不良問題也不可避免了。
(3)制定明確的溝通計劃，提升溝通效率和責任
一般來說，項目需求階段的工作一般都是自上而下、然后再自下而上的。怎么理解這個說法呢?這是因為開發項目一般會涉及到企業內部管理流程，這需要有客戶高層領導牽頭，而且領導對于上這種軟件項目都會有個期望，比如提高部門協作效率、減少流程對接中的失誤等等。因此，需求調研首先要制定明確的溝通計劃，方便與客戶方領導建立聯系，深入領會客戶方領導的意圖，然后按照領導的意圖去與各個部門溝通;后把各個部門的需求再整理、再加工，反饋給客戶方領導。這么做的好處是：第一是借客戶領導的要求和關注可以讓客戶下屬部門很好的配合，提升溝通的效率;第二是避免客戶方部門間責任的相互推諉，從而造成項目需求重復、邏輯沖突和相互矛盾。
(4)溝通應該是雙向的，且必須保證被正確理解
需求調研的本質在于信息傳遞，因此要進行有效的溝通管理，必須要在信息傳遞上下功夫。溝通必須是雙向的，這要求溝通方式必須要有反饋機制，而且在信息收到后還必須保證理解是正確的。在許多失敗的開發項目中，我們經常看到的是信息是傳達到了，但卻被錯誤的理解了，產生了大量的扯皮問題。總結這次的項目需求溝通失敗，我認為在需求調研后接收方需要確認自己理解了的同時還要再去細化或轉敘需求，但不是復述需求。說得直白些，是要求需求調研人員說明具體明白了哪些，并讓信息發送者進行確認。
(5)雙方簽署需求確認文件
后，在需求調研后，調研人員應對客戶的需求進行整理和確認，列出詳細的需求清單。并請求客戶方正式的簽字蓋章確認，可將該清單作為合同附件留存。這樣可避免雙方在項目需求上扯皮，不但是避免需求頻繁變更的依據，也是保證軟件開發項目能順利完成的關鍵一步。
