1.概述

筆者從2002年起參與過幾個省級、地市級政府電子政務專案，並有幸擔任專案經理職位。在筆者前期的專案經理生涯中，基本上處於“混沌”狀態，客戶招標書上註明“並聯審批系統”，筆者竟然不知道該系統為何物，以至該系統進度拖延一年之久，不甚感慨！當然這也和筆者所在公司的管理制度混亂有關。

國家電子政務標準經過幾年的醞釀，始終沒有掀起她的紅蓋頭。筆者卻在幾年的電子政務實施過程中，總結了不少經驗。今天有時間整理出來，獻給業界各位朋友，希望能夠拋磚引玉，那怕能夠節省國家一分錢的投資，少走一毫的彎路，也就達成心願了。

2.困境之一:人員素質困境

電子政務工程專案的重點不應在“電子”上面，而是在“政務”上。電子政務應該以政務電子化、提高政府工作效能為指導思想，“電子化”只能做為手段來輔助“政務”這一主導思想。

既然“政務電子化”是指導思想，當然其主要干係人就不是“電腦”、“網路”等，而是專案涉及到的各方面人員。包括政府領導、政府部門工作人員、政府資訊化工作人員；辦事企業、老百姓；專案承建公司、公司銷售經理、公司專案經理、公司開發實施人員等。

2.1政府資訊化領導

筆者曾經將政府資訊化領導分為三種型別：

2.1.1 精通政務，對資訊化工作不甚瞭解型

因為資訊化工作在不少地方政府剛剛起步，資訊中心是個新建部門，所以有不少資訊中心的領導是從業務部門平級調過來的。此類領導應該說精通於政府的業務工作，清晰政府各部門的工作流程。

但其欠缺資訊化工作的經驗，主要表現有：

前期調研時不配合，“我花錢了，調研應該不用我動腦筋了吧，你們自己去協調、去收集資料吧”

調研報告不確認：“我不明白調研報告寫得什麼東西”；如果問他怎麼修改，他也說不清楚；最後往往造成專案需求報告不能簽字確認，專案沒有基線

系統實施、使用過程中，不斷得提出新意見，造成專案進度拖延，甚至於重新開發，當然了，專案經理對此也有很大的責任。

對於此類領導來說，專案經理一定要做好充足的心理準備。專案前期採用種種方法給他們講透系統會做成什麼樣子，為什麼做成這種樣子，做成這樣有什麼好處；專案中期採用正規的專案管理方法，跟蹤每一次客戶意見，形成正式文件；專案後期要據理力爭，闡明不能對系統進行大的修改的原因。

2.1.2 精通政務和資訊化工作型

此類領導對電子政務有一套獨特的見解，又能吸收其它電子政務試點城市的經驗，是資訊化建設的主力軍，必將引導電子政務建設的潮流。

遇上此類領導對專案經理即是一個挑戰，因為此類專案是較難透過驗收的，需要花費大量的心血；反過來說專案管理水平和規劃水平肯定會得到較大的提高。

2.1.3 專業人士，但規劃水平欠缺型

某些資訊中心領導本身就有多年的資訊系統建設經驗，學歷水平較高。但是對本部門的電子政務建設沒有一個全面的認識。哪些系統應該在一期中完成，哪些系統應該在二期中完成？哪些系統應該做成什麼樣子？怎麼樣可以提高本部門的工作效率？如何減少專案實施的阻力？等等一系列問題上，沒有一個明確的想法。有可能會造成系統華而不實，無法實施或者使用效果不佳等問題。

如果專案經理遇到此類領導，要將各個問題考慮到他們的前面，將各個問題可能造成的結果解釋清楚，希望能引起他們的共識。當然了，因為他們是領導，處於一個主動的地位，所以這個工作實際開展起來會比較辛苦。但是隻要有理有據，講究方法，應該會有一個完善的結果。

2.2 政府工作人員

應該說，隨著電子政務建設的深入，政府工作人員正從各方面經受著資訊化浪潮的衝擊。不少地方政府把是否配合電子政務建設放在年度考核指標之中，這說明政府各級部門越來越重視資訊化工作。

但畢竟電子政務才剛剛起步，大部分工作人員對電子政務的理解還不是十分的清晰。筆者在幾期電子政務培訓中，發現不少令人驚訝的問題，受培訓的政府工作人員竟然不知道如何開啟與關閉IE？如何開關機？如何輸入使用者名稱和密碼？

專案經理如果不能認識到終端使用者的使用需求，不能從他們的角度出發考慮問題，勢必造成系統實施過程中步入困境。

2.3承建方專案經理

專案經理是專案的靈魂，他的思想決定著專案的成敗，所以有些客戶的招標檔案中明確要求，在專案實施過程中不能更換專案經理。專案簽定合同後，專案經理就是此專案的“總經理”，直接面對各種客戶，協調公司資源，從調研到實施完畢專案。

筆者曾經接觸過許多“優秀”的專案經理，精於專案管理理論，善於與人溝通，能熟練應用各種專案管理工具，但往往其所主管的專案不能成功實施。本人究其原因，排除外界環境外，是其不具有專案經理必須具備的其它幾個主要素質。

我認為專案經理應該具有下列幾種素質，才算是一個稱職的專案經理：

2.3.1 勤奮+忍耐

對IT人士來講，人們也許認為專案經理這個職位不錯的嗎，權利還挺大的，可以經常陪客戶出去玩，又不用開發程式。其實專案經理是確實是一個比較辛苦的職位，薪水不高(比技術骨幹、公司紅人要低得多)、經常出差(老婆肯定有意見，除非遇到一個比你更經常出差的老婆)、遭遇各種客戶的各種要求、在公司內部不太受重視等等。

如果專案經理僅僅看中眼前利益，可以說大部分時候應該是得不償失的，所以很多人沒有堅持到專案的最後，就敗走麥城了，造成了一個又一個爛尾專案。

一個成功的專案經理，應該具有堅強的精神面貌，無論碰到各種挫折，都要對自己負責，對客戶負責。

筆者舉個例子，2003年初，本人在某地市級政府電子政務第一期培訓過程中，系統忽然癱瘓，而且再也啟動不了了，下面的培訓人員包括市委書記、市長、部門一把手等等人員。當時筆者頓時感覺像有一支劍沿著後脊樑骨穿了下去，兩眼發直，心裡想“完蛋了，這個專案就這麼結束吧。”晚上和資訊中心的領導在一起喝酒，他們也感覺自己的從政生涯不會一帆風順了，每個人都是一杯一杯的白酒接著喝，最後爛醉如泥。不過，一個領導這麼說了一句話，令我一輩子也忘不了：“小誰啊，不用擔心，有問題我來承擔，來喝酒”。

事後本人極其鬱悶，幾度想向公司提出辭職。但專案還是照樣進行，沒有出現想象中的各種問題，而且一個多月後，系統問題解決了，進行了幾期更大範圍的電子政務培訓。本人也不再鬱悶了，領會到任何事情只要堅持總能挺過去。這個專案後，筆者將系統的穩定性放在了系統設計的第一位，再好的系統如果壓力測試不能透過，什麼都是白乾。

2.3.2 引導能力

一個專案經理的引導能力關係著專案工作量的大小。筆者曾經接觸過一個合同額6萬的網站專案的專案經理，他在調研過程中，竟然給客戶演示某價值百萬的網站，希望客戶在此基礎上提出欄目結構需求，結果可想而知，這個專案花費了大量的成本。而且客戶竟然不滿意，因為沒有這麼多的工作人員來維護如此多的網站欄目。

所以做專案不是說做得東西越多越好，而是要切實鑽透客戶的業務，抽象出能用計算機解決的最簡單的方法。在和客戶溝透過程中，不能被客戶牽著鼻子走，要處處想在客戶的前面，想到客戶還沒有想到的地方，方能引導客戶按照專案的即定方向發展，使專案成為一個可控的專案。

2.3.3 溝通和表達能力

溝通和表達能力是專案經理最重要的能力，有人說專案經理大部分的時間處於溝透過程中，此言不虛。溝通物件有：客戶方領導、客戶方工作人員、專案組人員、公司領導、公司部門經理等等。無論那一環溝通不力，都可能會造成專案進度的延遲。

3.困境之二:整體規劃困境

電子政務工程涉及到橫向各級人民政府，縱向各部門、廳局，所以很難形成一個統一的電子政務建設標準。比如，前期提出的“三網一庫”和“十二金工程”就只能起到指導作用，在實際建設過程中，各級政府部門從實際出發會提出各自的建設需求。

但是筆者認為電子政務工程的整體規劃卻有原則可循，參考這些原則，也可使工程建設少走不少彎路。筆者在下面整理了幾條，各位專案經理如果認可本人的觀點，可以繼續完善補充。

規劃前，深入瞭解終端使用者的建設需求

大多數電子政務專案由資訊中心統一規劃，而最終使用者是各部門、處室。在規劃過程中，經常出現資訊中心沒有深入瞭解業務部門實際的資訊化需求，而是資訊中心領導參考上級領導的意見，制定總體規劃，指導該專案的實施。可想而知，這種專案的後果往往不容樂觀。

資訊中心領導和工作人員由於本身是政府工作人員，其對政府業務的把握明顯要比開發公司要深入。但是，由於業務工作範圍不同，尤其是對橫向人民政府的資訊中心，不可能全面瞭解各部門實際的資訊化建設需求。如果在專案規劃前不進行深入調研，規劃的內容範圍、質量都可懷疑。

著眼於近期實際業務需求，分階段推進電子政務工程

筆者參與過一個電子政務專案，合同中要求的建設內容有：CA認證系統、外網門戶、內網門戶、辦公自動化系統、網上審批系統、基本資料庫系統、資訊採編系統、財務公開系統、財稅分析系統、經濟分析系統、應急指揮系統十大應用系統。從內容中我們可以分析出，該方案囊括了的電子政務的近期建設熱點(辦公自動化系統、入口網站、網上審批系統)以及將來的建設的熱點(決策分析、應急指揮、CA認證系統等)。如果按照合同的要求，實施完畢此電子政務專案，可以說，五年內不需要再進行類似的電子政務專案建設。

但其中存在的問題是：

1)電子政務建設處於探索階段，各個應用系統基本都是“摸著石頭過河”，調研、開發、實施的工作量都相當大

2)由於沒有統一的、標準的資料資源的積累，電子政務的決策分析系統的建設時機還不成熟(畢竟電信、銀行的決策分析專案才剛剛開始)

3)由於協調工作量大，出現要麼開發不能按時，按質完成，造成比較大的經濟損失；要麼開發完成後，專案實施有難度，使系統束之高閣。

4.困境之三:實施困境

筆者在幾年的電子政務專案實施過程中發現，政府客戶普遍存在“重開發，輕實施”的觀念。下面筆者舉兩個曾經做過的實際專案，請各位專案經理參考：

1.某縱向部門級電子政務專案

該專案調研比較順利，各處室業務人員、處室領導、資訊中心領導都在需求報告上簽字確認，認可此專案基線；

筆者和專案組成員，是平臺、產品軟體的堅決擁護者，深入抽象各處室客戶的業務需求，規劃用三個平臺軟體解決客戶十一個業務系統的建設需求。開發過程比較順利，提前完成系統開發(當然，開發工程師經常加班)；

在公司內部經過幾輪測試後，需要在客戶方進行Beta測試，但這以後的實施過程卻一拖再拖，影響了專案整體進度。

2.某地市級政府電子政務專案

該專案建設內容包括“並聯審批系統”，有下列問題：

專案調研過程中，該政府行政服務中心竟然不配合調研，理由是他們自己已經建設了一個並聯審批系統，會在近期內上線試執行；

筆者將該情況反映給資訊中心領導，領導說：“既然他們不配合，就不用調研這個部門了；這個專案的規劃、建設部門是資訊中心，只要你按照我們的要求建設完成，我們就付款。”於是筆者所在的專案組就按照領導的要求，繼續向下開展專案；

因為沒有終端使用者的需求，此係統的開發過程各位可想而知。一版、二版再版後，資訊中心領導終於認可此係統的功能；(當然，這和筆者當時的專案管理經驗有關，不能跟蹤與控制客戶修改意見)

在實施過程中，由於沒有最終客戶行政審批大廳的配合，造成該系統只能由資訊中心維護少數審批事項的介紹和相關表格，並不能真正的進行網上審批，使專案開發和專案應用嚴重脫節。雖然由於資訊中心的領導能力較強，可以透過市領導強迫要求推廣應用此係統，但是由於沒有調研最終客戶的需求，因此此係統在實際使用過程中，肯定要做大的修改。[@more@]

專案經理在電子政務建設中的困境（轉）

相關文章