在溝通機構(gòu)建立后， 編制了溝通的制度和具體流程， 規(guī)定了各方的責任和權利以及相應的獎懲條例， 并以具體的流程來規(guī)范各方的溝通行為，其中包括一般情況和緊急情況下的溝通方式。
(1)要求各方必須建立相應的溝通機制，列出溝通責任人員的名稱、職務、聯(lián)系方式和負責的范圍，其中包括對內(nèi)和對外溝通范圍。
(2)要求各方人員應進行對等溝通， 即技術層人員與技術層人員溝通，管理層人員與管理層人員溝通，盡量避免2個不同單位之間的跨層溝通， 以防產(chǎn)生不必要的誤會。
(3)在同一單位內(nèi)，各層之間要掌握溝通內(nèi)容和深度，技術人員應清楚向管理層反映什么情況， 什么內(nèi)容，期望管理層解決什么問題;管理層也需要知道應解決什么問題。
(4)溝通的響應時間應明確，什么問題需要多長時間響應， 應記錄每次響應時間，對超時響應的況進行原因分析， 對于無故拖延響應的給予一定的懲罰。
(5)定期召開碰頭會， 碰頭會主要由項目的管理層和相關的技術人員參與，集中各方的工程進度完成情況和在工程中遇到的問題， 提出工程中隱存的風險，探討降低風險的手段。
(6)確定緊急情況下的溝通方式和投訴途徑。
(7)確定項目監(jiān)理方在溝通中的主導地位， 負責組織各方定期開會， 解決有爭議的問題。溝通流程是溝通順利進行的保障， 因此，在項目開始時，就應確定項目的溝通流程，
(1)各角色應明確自己的權責范圍，對超出自己范圍的內(nèi)容，應征求相關人員的意見，在得到確認后才能回復，不要隨口開河，造成不必要的損失。如系統(tǒng)集成商或供應商的項目經(jīng)理對系統(tǒng)具體技術功能的內(nèi)容， 如果沒有把握， 應請有關技術人員確認后才能回復請求方。
(2)技術人員之間應在項目技術協(xié)議書的基礎上進行技術溝通和技術確認， 超出了項目技術協(xié)議書上的內(nèi)容， 應得到管理層的同意才能確認; 這一點技術人員特別是軟件開發(fā)人員往往會忽視， 他們在具體的軟件開發(fā)過程中， 常常會根據(jù)業(yè)主技術人員的意見擅自改變原有功能或增加新的功能， 他們會自認為這樣效果會更好， 但忽視了管理的需要， 會造成管理人員對項目的管理失控。
(3)在項目進行過程中， 如有影響較大的變動， 應及時向決策層匯報， 以作出相應的對策; 項目有大的變動往往會影響到項目的進度、質(zhì)量和成本， 如果沒得到?jīng)Q策層的批準， 項目將無法得到應有的資源支持， 致使項目失敗。
(4)要建立配套的投訴制度， 在溝通流程不能進行正常運作時， 可及時進行糾正。在項目實施過程中，各方因?qū)δ骋粏栴}或某一條款的看法不同而作出不同的反應常有發(fā)生， 這些問題如不能得到及時的解決， 將會影響工程的進一步實施。因此， 配套的投訴制度在大中型項目的建設中可起到保障作用。
(5)流程涉及的任何一方出現(xiàn)人員變動應及時通知其他各方， 同時， 對于某一方面的技術人員的配置應采用雙人以上， 以避免出現(xiàn)人員真空現(xiàn)象的出現(xiàn)。大中型項目實施的時間一般較長，參與各方出現(xiàn)人員變動也屬于正?，F(xiàn)象， 因此，項目參與各方應建立人才儲備制度。