一、專案管理方面

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

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

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

二、技術架構方面

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

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