避免問題依舊的新專案 （轉）
現在有很多的公司部門負責人在抱怨各種各樣的IT問題，認為很多技術起不到作用，各種各樣的系統都需要改進，但是，在這些抱怨者中卻幾乎沒有人能夠提出改進的建議。公司的行政管理層所看到的只是IT出現的種種問題。他們可能會提供一小筆預算，要求IT部門去解決問題，找到理想的系統和軟體。或者，他們可能會決定花大價錢來請諮詢顧問，讓他們幫助解決問題。不管是哪種情況，專案都很少能夠取得進展，新系統往往會和老系統一樣充滿問題。
其實，CIO們可以避免上述情況的出現。他們只需要確定需要改進的地方、確定能夠帶來改進的最佳工具，確定如何有效的控制改進所不可避免的風險就可以了。
在這篇文章裡，我將向大家介紹我所在的公司（一家大型工業服務和供應公司）尋找新的商業軟體的經歷。我所在的公司想要尋找一種新的商業軟體來替代原來的Platinum軟體，在終端進行普通的計算和報告工作。在應用舊的軟體時，由於資料最終要被輸入到資料程式中，所有的交易都要透過人工來完成，不僅要花費大量的時間，還經常要耗費多餘的人力。舊的系統已經使用了五年的時間了。
公司希望新的軟體能夠具有前端自動化功能、更為有效的管理報告功能，系統穩定效能夠得到提高，能夠即時完成交易和處理。為了滿足公司的要求，我們開始對市場上的各種產品進行調查，以尋找最佳的工具。
第一步是建立一支由中層管理人員、CEO和/或一名經驗豐富的商業管理顧問（注意不是IT顧問）組成的強有力的多面小組。
我認為如果能讓CEO加入到這個小組當中是最好的，因為他所處的地位需要他比任何人都更好的瞭解公司的業務。但是，由於我所在公司的CEO實在無法抽出時間，我們就僱傭了一名商業管理顧問來代替他的位置。這名顧問是CEO負責挑選的。最低限度的要求是要有碩士學位，在業內有15年的工作經驗，並且至少已經從事了10年的諮詢顧問工作。
核心小組由諮詢顧問、一名會計、原料主管、HR經理、我和IT經理組成。核心小組成員同CEO以及董事會的一些成員一起召開了最初的會議。在會議上，諮詢顧問提出了他的建議方案。
諮詢顧問向大家介紹了他所計劃的專案每一個階段的時間框架：調查階段、建議制定階段、選擇銷售商並制定計劃、執行與培訓階段以及磨合與定製階段。
在會議上，大家只是討論了大致的想法，把重點放在了對一份建議預算和投資回報的看法上。諮詢顧問和CEO在會議的轉天對預算進行了審查，然後就開始尋求董事會成員的批准了。
在接下來的董事會會議之後，我們得到了訊息，董事會已經最終批准了專案及其預算。我們同諮詢顧問進行了聯絡，專案就這樣開始了。
第一次核心小組會議
在第一次核心小組會議上，我們確定了專案標準並且商討了執行計劃。每個小組成員都各司其職：
我負責提供技術性建議並確定會議時間。會計暫時沒有明確的職責分工，但將要負責帳目表以及辦公程式表的製作。原料主管負責瞭解現有的業務程式並記錄任何新的業務程式需求。HR經理同樣也暫時沒有任務，她可以利用這段時間正確深入的瞭解專案，並開始起草培訓計劃。在新專案的執行過程中，人員培訓不足是專案失敗的最主要原因之一。諮詢顧問則向大家提供幫助和諮詢。
專案的第一階段包括從各個職能業務部門蒐集資料。原料主管、諮詢顧問和我承擔了這個任務。
諮詢顧問設計了一份調查問卷，以對系統分析的一些基本方法進行評論和解釋。我們打算把問卷分發到每一個部門經理的手中，並且召集核心人員和他們的負責人開會。在這些會議上，我們收集到了很多有用的資料。
問卷上的主要問題有：
你在公司擔任什麼工作？你擔任的工作的目的是什麼？哪些問題會影響你的工作效率？為了正確的完成工作，你需要得到哪些資訊？你以什麼方式獲得這些資訊？這些資訊是否按時傳送？你如何處理獲得的資訊？獲得這些資訊是否是你實現工作目標的一個組成部分？你製作什麼樣的報告，提供給哪些人？你覺得你提供的報告能夠讓看到的人覺得滿意嗎？他們是否經常向你詢問額外資訊？你使用什麼硬體/軟體？你是否對硬體/軟體改進你工作效率的方式感到滿意？
資訊收集過程
原料主管把問卷調查表和臨時專案時間表分發到了各個部門的經理手中，並召集他們最終確定了見面時間，填寫了調查表。大約一百名員工當中有四十人在這一過程中接受了訪問。
每一次見面開始時，諮詢顧問都要看員工遞交的調查問卷。然後，他會以不同的方式來提出問題，這樣所有的方面就都照顧到了。
我們的諮詢顧問所展示的是一種獨到的方法。他會問：你使用什麼報告？這些報告的使用者都是誰？然後他會畫出一個圖表（如圖A所示），然後讓員工在上面寫上經常向他們詢問資訊的部門/商業實體的名稱。同樣，員工還要在決策型別的表格中註明他們為了獲得資訊而經常走訪的部門的名稱。
接下來，員工們要在每一個部門的格子內註明他們需要從這一部門得到的資訊。諮詢顧問會問他們能夠按時收到這些資訊，會不會有資訊遲到、遲到很長時間甚至根本就得不到資訊的情況出現。員工們還可以告訴諮詢顧問他們想要從各個部門得到而又得不到的資訊是什麼，表達自己的願望。
透過同樣的方式，諮詢顧問還可以從員工那裡瞭解他們向其他部門提供的資訊。
整個過程比預計時間提前兩週完成。說實話，我們自己都沒有想到這一過程能夠完成的這麼快。
第一塊里程碑
在收集到了全部資訊之後，原料主管在配套掛圖上寫下了所有的需求。
星期六，專案的全體人員在一起召開了一天的會議。除了星期日之外，這是我們唯一能把工作繁忙的商業實體負責人和銷售人員召集到一起的時間了。
我們把配套掛圖釘在了牆上，各個小組用程式碼填寫了原因和結果。
用蘭色顯示的是每一欄裡的典型答案。各個小組依次填寫，一個小組寫原因，一個小組寫結果。
會議結束之後，每個人都感到了成就感。員工們可以有機會來指出他們使用了多年的系統所存在的問題了。透過這種方式，他們指出了問題所在。由於他們瞭解新專案的應用能夠帶來的好處，所以就能夠更好的接受和適應這種變化。很多公司都經常犯同一個錯誤，那就是在變化的準備階段沒有讓使用者直接參與。[@more@]
其實，CIO們可以避免上述情況的出現。他們只需要確定需要改進的地方、確定能夠帶來改進的最佳工具，確定如何有效的控制改進所不可避免的風險就可以了。
在這篇文章裡，我將向大家介紹我所在的公司（一家大型工業服務和供應公司）尋找新的商業軟體的經歷。我所在的公司想要尋找一種新的商業軟體來替代原來的Platinum軟體，在終端進行普通的計算和報告工作。在應用舊的軟體時，由於資料最終要被輸入到資料程式中，所有的交易都要透過人工來完成，不僅要花費大量的時間，還經常要耗費多餘的人力。舊的系統已經使用了五年的時間了。
公司希望新的軟體能夠具有前端自動化功能、更為有效的管理報告功能，系統穩定效能夠得到提高，能夠即時完成交易和處理。為了滿足公司的要求，我們開始對市場上的各種產品進行調查，以尋找最佳的工具。
第一步是建立一支由中層管理人員、CEO和/或一名經驗豐富的商業管理顧問（注意不是IT顧問）組成的強有力的多面小組。
我認為如果能讓CEO加入到這個小組當中是最好的，因為他所處的地位需要他比任何人都更好的瞭解公司的業務。但是，由於我所在公司的CEO實在無法抽出時間，我們就僱傭了一名商業管理顧問來代替他的位置。這名顧問是CEO負責挑選的。最低限度的要求是要有碩士學位，在業內有15年的工作經驗，並且至少已經從事了10年的諮詢顧問工作。
核心小組由諮詢顧問、一名會計、原料主管、HR經理、我和IT經理組成。核心小組成員同CEO以及董事會的一些成員一起召開了最初的會議。在會議上，諮詢顧問提出了他的建議方案。
諮詢顧問向大家介紹了他所計劃的專案每一個階段的時間框架：調查階段、建議制定階段、選擇銷售商並制定計劃、執行與培訓階段以及磨合與定製階段。
在會議上，大家只是討論了大致的想法，把重點放在了對一份建議預算和投資回報的看法上。諮詢顧問和CEO在會議的轉天對預算進行了審查，然後就開始尋求董事會成員的批准了。
在接下來的董事會會議之後，我們得到了訊息，董事會已經最終批准了專案及其預算。我們同諮詢顧問進行了聯絡，專案就這樣開始了。
第一次核心小組會議
在第一次核心小組會議上，我們確定了專案標準並且商討了執行計劃。每個小組成員都各司其職：
我負責提供技術性建議並確定會議時間。會計暫時沒有明確的職責分工，但將要負責帳目表以及辦公程式表的製作。原料主管負責瞭解現有的業務程式並記錄任何新的業務程式需求。HR經理同樣也暫時沒有任務，她可以利用這段時間正確深入的瞭解專案，並開始起草培訓計劃。在新專案的執行過程中，人員培訓不足是專案失敗的最主要原因之一。諮詢顧問則向大家提供幫助和諮詢。
專案的第一階段包括從各個職能業務部門蒐集資料。原料主管、諮詢顧問和我承擔了這個任務。
諮詢顧問設計了一份調查問卷，以對系統分析的一些基本方法進行評論和解釋。我們打算把問卷分發到每一個部門經理的手中，並且召集核心人員和他們的負責人開會。在這些會議上，我們收集到了很多有用的資料。
問卷上的主要問題有：
你在公司擔任什麼工作？你擔任的工作的目的是什麼？哪些問題會影響你的工作效率？為了正確的完成工作，你需要得到哪些資訊？你以什麼方式獲得這些資訊？這些資訊是否按時傳送？你如何處理獲得的資訊？獲得這些資訊是否是你實現工作目標的一個組成部分？你製作什麼樣的報告，提供給哪些人？你覺得你提供的報告能夠讓看到的人覺得滿意嗎？他們是否經常向你詢問額外資訊？你使用什麼硬體/軟體？你是否對硬體/軟體改進你工作效率的方式感到滿意？
資訊收集過程
原料主管把問卷調查表和臨時專案時間表分發到了各個部門的經理手中，並召集他們最終確定了見面時間，填寫了調查表。大約一百名員工當中有四十人在這一過程中接受了訪問。
每一次見面開始時，諮詢顧問都要看員工遞交的調查問卷。然後，他會以不同的方式來提出問題，這樣所有的方面就都照顧到了。
我們的諮詢顧問所展示的是一種獨到的方法。他會問：你使用什麼報告？這些報告的使用者都是誰？然後他會畫出一個圖表（如圖A所示），然後讓員工在上面寫上經常向他們詢問資訊的部門/商業實體的名稱。同樣，員工還要在決策型別的表格中註明他們為了獲得資訊而經常走訪的部門的名稱。
接下來，員工們要在每一個部門的格子內註明他們需要從這一部門得到的資訊。諮詢顧問會問他們能夠按時收到這些資訊，會不會有資訊遲到、遲到很長時間甚至根本就得不到資訊的情況出現。員工們還可以告訴諮詢顧問他們想要從各個部門得到而又得不到的資訊是什麼，表達自己的願望。
透過同樣的方式，諮詢顧問還可以從員工那裡瞭解他們向其他部門提供的資訊。
整個過程比預計時間提前兩週完成。說實話，我們自己都沒有想到這一過程能夠完成的這麼快。
第一塊里程碑
在收集到了全部資訊之後，原料主管在配套掛圖上寫下了所有的需求。
星期六，專案的全體人員在一起召開了一天的會議。除了星期日之外，這是我們唯一能把工作繁忙的商業實體負責人和銷售人員召集到一起的時間了。
我們把配套掛圖釘在了牆上，各個小組用程式碼填寫了原因和結果。
用蘭色顯示的是每一欄裡的典型答案。各個小組依次填寫，一個小組寫原因，一個小組寫結果。
會議結束之後，每個人都感到了成就感。員工們可以有機會來指出他們使用了多年的系統所存在的問題了。透過這種方式，他們指出了問題所在。由於他們瞭解新專案的應用能夠帶來的好處，所以就能夠更好的接受和適應這種變化。很多公司都經常犯同一個錯誤，那就是在變化的準備階段沒有讓使用者直接參與。[@more@]
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7839396/viewspace-937776/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- 避免問題依舊的新專案（轉）
- 舊專案 TypeScript 改造問題與解決方案記TypeScript
- SQL依據舊錶生成新表SQL
- vue專案路由不跳轉的問題Vue路由
- 敏捷專案管理：問題、挑戰以及如何避免失敗敏捷專案管理
- 致勝策略——淺談新產品開發的專案管理問題（轉）專案管理
- 避免專案管理中的溝通失靈 （轉）專案管理
- 避免專案管理中的溝通失靈(轉)專案管理
- 新舊手機怎樣轉換上面的檔案？新舊手機便籤怎麼轉換
- 軟體專案管理如何避免“黑洞”(轉)專案管理
- 記錄一個新專案遇到的 MySQL 問題MySql
- 由spring專案轉為springboot專案的問題Spring Boot
- 專案中常問的問題
- maven打包jar無法打入依賴專案問題解決MavenJAR
- 專案團隊的信任問題探討（轉）
- 推行專案管理中存在的主要問題(轉)專案管理
- 解決安裝Tuxera NTFS For Mac後依舊無法寫入的問題UXMac
- 專案管理常見問題解答（轉）專案管理
- IT專案管理：問題、體系、方法（轉）專案管理
- 關於使用 Laravel new 新專案 報錯的問題Laravel
- 新舊系統更替產生的資料遷移問題
- 專案管理的魅力--舊有網路架構改造(轉)專案管理架構
- 專案問題
- 專案工作分解的步驟和注意問題（轉）
- 專案管理過程中的問題分析方法（轉）專案管理
- 使用H5新標籤重構舊專案時的思考H5
- 新舊系統轉化策略
- 轉 xx_adam 的專案總結，主要是專案管理存在的問題專案管理
- 問問大家,怎樣瞭解自己沒有參與過的舊專案
- 專案管理過程中的問題分析方法1（轉）專案管理
- 專案管理過程中的問題分析方法2（轉）專案管理
- 專案管理過程中的問題分析方法3（轉）專案管理
- 專案管理中需要處理好的四個問題(轉)專案管理
- 實施專案問題管理的七步走（轉）
- 教你將新舊專案接入已建立好的 Laravel Sail 容器(MySQL、Redis)LaravelAIMySqlRedis
- Java專案問題Java
- 軟體專案管理常見問題分析（轉）專案管理
- 新基建賦能新舊動能轉換