一、項目管理方面

1、業主、總集成商、監理單位、承建單位、產品供貨單位的溝通協調問題。首先，在與業主的溝通方面，最初較為混亂，主要原因是沒有形成統一的溝通結構與機制，在最初的近三個月的時間里導致項目推進速度非常緩慢。經與業主單位溝通，制定了工程的溝通方案，建立了溝通組織結構。主要內容是在業主單位方面建立了項目實施辦，項目實施辦對部領導組成的項目辦負責，明確了項目辦與實施辦的責任，由實施辦協調信息中心各處室共同推進項目工作；并且在信息中心內部推行“承諾書”也就是各處室均對工程的建設內容進行承諾并與績效掛鉤。其次，總集成商、總監理商與實施辦溝通，實施辦與相關處室溝通，承建商與產品供貨單位在技術上接受總集成商的指導與約束；在流程的規范性上接受總監理商的指導與約束；在業務上接受信息中心負責處室的約束。由此，通過溝通方案建立與推行，項目的溝通協調方面才進入了正軌，項目的推進速度明顯加快。

2、用戶單位對項目的支持度等方面的問題。某些用戶單位對所建設的項目并沒有強烈的需求，持可有可無或最好沒有的態度，但在工程的初設中這些項目又是必須建設的內容。因此，在項目的實施的過程中，這寫用戶單位對項目的各項工作均持消極態度，使得項目無法正常推進。例如，有些用戶單位不組織本單位人員配合需求調研，不組織下屬各省級單位進行系統試運行，不組織本單位人員進行用戶測試等。對于這些問題往往系統承建商方面已無法推動，需要通過實施辦與項目辦層面與用戶單位溝通協商一致后才能繼續開展工作。

3、部本級項目與省級項目的協調推進問題。由于在工程的可研中包含各省的項目建設，各省建設的進度對整體項目的最終驗收具有制約作用。目前，各省的建設情況各不一致，有的已經完成，有的正在建設過程中，有的資金尚未批復。。。

二、技術架構方面

1、應用系統部署架構問題。在09年底的時候，在應用系統部署架構出現了一個“互聯網區應用系統訪問Oracle RAC數據庫時斷時續問題”，此問題先后持續了4到5個月，制約了項目的建設進度（期間采用了其他方式，盡量減少了損失）。原因1，在進行整體應用系統部署架構設計時，尚未進行相應產品的招標，因此無法明確具體的產品（各產品在具體的實現層面有差別，這些差別可能影響部署架構的實現）。原因2，各廠商均具有專業領域的知識背景，但對各知識領域之間的把握較少，因此很可能在邊緣領域出現問題。原因3，由于本項目為大型的電子政務項目，涉及的專業知識領域和技術手段非常繁雜，在設計與測試過程中非常困難。在實施辦與總集的總體協調下，經過多次的評審與大量的測試，對應用系統部署架構進行了調整，使問題成功解決。此類問題的解決方法是由總集成商牽頭，召集相關的承建單位，如網絡集成商、安全集成商、數據庫提供商。。。共同討論分析，制定問題的排查方案，并按照方案查找問題的原因。待問題的原因查找清楚后，再由總集成商召集相關承建商共同討論提出解決方法，經實施辦審核通過（如重大技術問題可由實施辦召集專家進行評審確定）。

2、部分系統試運行階段性能低下與生產環境問題排查困難等。一方面，工程所用到的技術非常復雜，采用了大量的設備，如 Oralce RAC集群，存儲，IBM小型機、負載均衡集群等，此種環境很難有一個企業（如承建單位或第三方測試單位）復制。因此，無論是承建單位還是第三方測試單位所進行的測試均無法完全反映生產環境下的性能指標。另一方面，此種生產環境也是初次搭建，其技術可行性只停留在理論層面，期間的技術細節無法完全在設計階段考慮到，只能通過一段時間的系統試運行才能夠暴露與完善。當然，如果能夠在系統進行初步設計時，能夠考慮搭建一套與生產環境完全或基本一致的測試環境，此問題將能夠很方便的進行解決，也就是可以在測試環境中進行應用系統的壓力測試與問題排查，待系統穩定后并滿足用戶要求時，再將系統遷移至正式的生產環境中，這種方式可以最大程度的保持生產環境的穩定性。