國內某巨大型國企源能公司與著名的軟體公司簽訂了管理軟體合同。
軟體公司實施隊伍進入源能企業後開展了調研。調研階段中，能源公司的採購部對管理軟體中的物資管理功能非常感興趣，多次與軟體專案經理討論、溝通。按道理來說，作為軟體實施方來說應該很高興甲方如此的積極，但是隨著溝通的深入，專案經理開始發現情況不妙，以下就是溝通的情景：
採購部專工：你們的物資編碼採取什麼標準？能介紹一下嗎？
專案經理：不同的企業理解不一樣。對於我們軟體**商來說，你們提供物資編碼，我們可以協助做物資系統的初始化工作。
採購部專工：怎麼你們不提供物資編碼嗎？其他專案用的是什麼物資編碼？
專案經理：其他專案的物資編碼我可以給你們作為借鑑。但是您的部門以及使用人員不一定熟悉這套體系，這會為將來的物資管理和統計工作帶來隱患。
採購部專工：對了，我們的物資編碼要有兩個單價體系。比如：
管道。竣工決算是按照噸來執行的。所以出庫領料是按照噸。
但是需求計畫是從設計圖紙分解出來的，設計的時候是按照公尺來的，所以提需求計畫的時候得按照公尺來。你們得建立公尺和噸的轉換。
採購部的領導也參與進來了：
採購部領導：你們能否給我們提供乙份成熟的採購管理方案嗎？
專案經理：我們可以提供其他的專案作參考。介於本行業的每個專案的差異很大，能複製的地方不多。
採購部領導：那你們就沒有成熟的解決方案嗎？
專案經理：我們是軟體實施商，不是管理諮詢公司。應該是你們擬定解決方案然後我們來實現。
採購部領導：我們現在非常需要***的解決方案，你們幫我們找找案例。
專案經理：這個得你們提出管理目標，以及管理細緻程度。根據我們了解的情況，以往採購部可能存在多個管理目標並且有可能衝突，您需要排出優先順序。
然後你們一步一步落實具體的管理方法，我們可以根據調研情況形成軟體需求報告以及軟體應用規劃。
採購部領導：你們實施了這麼多專案，應該有很豐富的經驗，就不能跟我們說說採購管理過程中有哪些風險？他們是什麼樣的管理思路和方法？
專案經理：每個企業的管理目標不一樣，展開工作所具備的條件、環境、資源都不一樣，這些解決方案並不一定適用你們企業。我們建議你們先明確管理目標，制定相應的基本流程、標準規範。
在這些內容形成後，依然有一些特例或者異常超出我們管控的範圍的，這個時候，我們可以介紹其他企業的具體解決思路和方法供您參考。
……(討論沒有結果)
隨著時間的推移，關於採購部管理制度和流程的討論提公升到公司層面。公司領導、各業務部門主管以及專工聚集在一起對採購部的流程以及管理思路進行討論，會議情況大致如下：
財務部關注物資的竣工決算後的轉資以及合理避稅。
技術部關注系統的執行效率以及具體的技術標準。
控制部關注物資的進度計畫編制及完成情況。
設計院希望採購部根據**商以及物資專業劃分整理出相關說明，配合設計。
內容越來越多，採購部明白了很多，也有更多的不明白了：這也要做那也要做，到底該怎麼形成一套體系。最後某採購部業務專工冒出來了：
不怕，我們有***x專案管理軟體，它都可以搞定。有它在就沒有問題了。（言下之意出了問題就是軟體的問題，這個帽子可扣大了）
這回軟體實施團隊徹底鬱悶了：應該是你們將業務問題進行分析，明確了解決方案之後再給我們指示而不是我們來幫你們分析問題理清業務邏輯。
採購部的問題還沒解決，公司領導、資訊部門也「添磚加瓦」了：
公司領導：軟體設計方面要盡量靈活。你們的流程管理能不能做成自定義的，當前步驟操作人員可以自己選擇下一步驟操作人員。就像發郵件一樣，自己想選誰就選誰。
專案經理說：流程怎麼能想發給誰就發給誰呢？流程是科學的，每個環節都是有價值的，是根據流程服務物件以及物件所要求的目標所確定的。
公司領導：建設期有太多的不確定因素，現有的流程一定要靈活、快速響應。
專案經理：……
資訊部門把話題接了過來：另外，有些不走流程的就讓各業務部門上傳掃瞄件。對了，輸入掃瞄件中的文字內容能查詢出這個工程掃瞄件嗎？據我所知漢王公司是可以做到的。
（專案經理徹底沉默了）
資訊主管繼續說道：你們在考慮問題的時候要面面俱到。我過去碰到一件事，某軟體**商設計a方案，但是不適用。
我們根據實際情況擬定b方案。於是軟體**商開始根據b方案進行了很多定製化改動。最後我們使用過程中發現流程走不通了，想退回a方案，又退不回了。
所以你們要在設計的時候考慮功能靈活性。
通過這次會議，大家看到很多問題，不過這一切好像都是軟體技術問題，是可以解決的。於是就這麼定了，甲方當場宣布了後期應用規劃：各業務部門以及參建單位以後都要將本部門的業務資料錄入管理系統中。
但是在推動過程中，軟體實施人員頻繁遭到了業務部門以及參建單位抱怨和質疑：
業務部門：
1．你們能不能將所有的操作都集中在乙個介面，操作太麻煩了。
2．你們能不能提供excel匯入，自定義表單，自定義報表功能，減輕我們的負擔。
參建單位：
1．我們本身就有一套管理軟體，如果使用你們的管理軟體，會存在重複性勞動。
2．雖然可以做介面自動匯入業務資料，但是我們的軟體**商未必肯給你們開放介面。
3．x位置得修改，xx介面也得修改，業務與系統的磨合程度還不夠。
以上場景只是專案實施過程中的乙個片斷。這裡我不想做需求分析，而是對問題的本質做乙個分析，同時如何實施做乙個拋磚引玉：
資訊負責人：
表面上，資訊負責人既懂業務又懂技術還了解企業現狀，對軟體**商與企業方起著良好的推動作用。但是實際過程中，由於業務部門的專業程度，資訊部門很難提出建設性的意見。在業務解決方案這條路走不通的時候，往往就只剩下技術解決這條路了。
同時，資訊部門也喜歡在企業裡面顯示自己的技術見解，主動用技術方案去承擔管理問題（國企性質還存在屁股決定腦袋的問題），這就為日後的重複開發，模糊焦點埋下了巨大隱患。最後出了問題就指責軟體實施團隊技術水平不夠，要求增加人力。
業務部門及操作人員：
業務部門及操作人員喜歡鑽研各種操作並盡可能的找出漏洞，以達到破壞管理系統，使自己脫離領導管控的目的。通常，他們喜歡從業務、技術、操作等多個角度將問題不斷丟擲，並且盡可能的將需求以及描述複雜化。最後被追責的時候一本正經的說道：
業務說了幾次也不懂，他們的軟體問題太多，無法使用。
公司領導：
公司領導將管理問題歸結於技術問題，因為你不了解他的價值觀。最後他可以作為領導通過大家的質疑來使你在這一塊無法推動最後停滯。
那麼專案經理該怎麼做呢？
首先，我們要了解領導的價值觀。比如，領導說：在一切管理目標發生衝突的時候，以進度為第一。
這句話就表明了管理目標的優先級別。了解了領導價值觀之後，我們就會介紹：可以按標準分類以上傳的方式完成各類文件維護，並給予相應業務部門的許可權方便查閱。
反過來，如果領導說：我們要對管理的一些盲區進行挖掘，不留一處死角。那麼就表明要將所有過程全部體現在系統中，這個時候如果你說附件上傳，領導顯然會不滿意，因為達不到他的管理目標。
對於資訊部門，由於他們往往是「採集流程對it的需求」，軟體實施商可以盡量不去「打擾」他們。既然問題的源頭是業務，那麼一切中心就圍繞著業務部門。
最後，對於業務部門，我們可以與業務部門的領導溝通，明確管理目標。在目標不明確的情況下討論任何管理方法和實現細節都是毫無意義的。注意，所有的事件中專案經理只做引導，業務的執行由領導來推動，這就是借力打力。
而不是軟體實施團隊衝在前面承受暴風雨的洗禮。
專案管理經典技術
6 關鍵因素分析技術 關鍵因素分析是質量管理中使用的技術，也稱為帕累託法則。它是把質量的缺陷進行歸類統計，分析每種引起質量原因所造成不良質量成本，然後找到影響最大的幾個予以解決，即 解決20 的因素，得到80 的效益 有名的 二 八理論，80 20原則。7 用 行 功能點 人工量進行時間等估算的技術...
中國普天專案管理實施案例
普天資訊科技研究院 簡稱研究院 是中國普天資訊產業股份 簡稱中國普天 所屬的從事高新技術和產品研發的研究機構。主要職能和任務是為中國普天承擔新技術發展規劃和新產品研究開發，為中國普天企業提供具有市場前景和產業規模能力得新技術與新產品。作為中國普天新產品的提供基地，以技術創新方式培育產業和支撐產業的發...
教師工程專案管理經典案例
首先介紹兩個經典案例 案例l 宋皇宮修復工程 宋真宗祥符年間，皇城開封失火，宮殿被全部燒毀，皇帝派大臣丁胃，主持皇宮修復工程，計畫工期14年。丁渭經通盤籌畫，提出了一套完整的施工方案，該方案體現了系統工程中的全域性性與最優性觀點。首先，把皇宮前的大街挖成溝渠，用挖出的土燒磚，從而就地解決了部分建築材...