投標前,專案調研的準備(轉)
專案投標前,招標方可能會同時安排幾家供應商同時進行專案的預調研。如果有效地在投標中展示自己的研發和專案管理實力,同時給競爭對手一些門檻,專案第一次調研目標和計劃準備工作就顯得有為重要了。
一、專案調研的目的
有人提議將招標方的需求寫得比競爭對手詳細。這樣做來,一是對方也會比你做得更仔細,二是評標方(客戶)不可能仔細你寫的標書。而且要想從幾天的時間中將客戶的需求調研清楚是不現實也是不可能的。原因有這樣幾個:一是每個公司的實力是一個未知數,客戶對你的的信任度沒有建立,不可能很仔細給你講;二是售前階段,使用者不可能投放大量的人力來進行調研工作;三是有的企業流程比較複雜,企業的使用者可能自己不清楚,細節的解釋就更不可能了。所以我們在專案的調研前必須定好這次專案調研的目的。我認為有這樣幾條:一是讓使用者認為我們有足夠的實力去了解現有的企業流程業務;二是儘可能獲取一些資訊,以便進入下一階段的工作;如果能給競爭對手設計一些門檻,瞭解到競爭對手給我們設計的門檻更最好不過。
在此階段我們的最主要目標是讓使用者認同調研者,認可公司的實力,認同我們在這個領域的能力和經驗,而不是努力完全地搞清楚企業的業務流程。要完成這個目標,必須透過規範的業務流程和切實可行的計劃讓使用者來感受我們的工作質量很高,認同感強烈,這樣給競爭對手一些壓力,獲取專案的成功的可能性就越高。
二、專案調研計劃
1)計劃的制定
很多專案調研計劃都寫成這樣:某年某月某日,對某部門進行業務調研。因為計劃者沒有想好調研從什麼地方入手,到現場走一步看一步再說吧;要麼就是依靠自己過去的工作經驗來進行調研。我們可以換個思路想一想,我們的工作計劃是提交給使用者領導看的,是讓使用者領導來進行確定的。那麼我們的計劃必須是可以執行的,可操作的,使用者是可以看得明白的。如果你的計劃展現了這些內容,領導只是將時間的前後調配一下,安排起來越方便,安排相關人員來配合我們的調研的時間也就相對容易一些。
根據我以前的一些經驗,,對於使用者方,我建議將計劃細分到上午下午,調研的部門是哪個,需要什麼樣的人員進行配合,時間有多長,需要了解哪些方面的內容,要準備哪些資料。這樣一來,我相信主管領導安排工作起來就相對簡單很多;
2)計劃的使用者確認
以前曾經去犯過這樣的錯誤,專案調研計劃做好,傳真給使用者,立即按照計劃去執行,結果常常是使用者沒有時間,或者是說根本沒有準備。搞得雙方都不開心。其實我也很鬱悶,我的注意事項中不是寫好有問題給我打電話嗎?沒有打電話就是認可我的專案計劃嗎?其實不然,很多使用者方領導在接到你的傳真後,沒有認真研究過你的專案計劃,更談不上想想你這個計劃有什麼不合理,那更不會去落實你這個專案調研計劃了。
那我們如何辦?傳真完了,過一些時間打電話給負責人確認,請使用者確認是否可以按計劃進行。若可以打電話再和具體的部門業務人員進行商協,計劃內容是否認可,得到肯定後,這份計劃才真正在使用者哪邊切實可行。
當然如果能透過一些企業的人脈關係將一些前期的資料準備清單提交給相關的人員並積極落實,則更讓使用者認同我們的公司的實力。[@more@]
一、專案調研的目的
有人提議將招標方的需求寫得比競爭對手詳細。這樣做來,一是對方也會比你做得更仔細,二是評標方(客戶)不可能仔細你寫的標書。而且要想從幾天的時間中將客戶的需求調研清楚是不現實也是不可能的。原因有這樣幾個:一是每個公司的實力是一個未知數,客戶對你的的信任度沒有建立,不可能很仔細給你講;二是售前階段,使用者不可能投放大量的人力來進行調研工作;三是有的企業流程比較複雜,企業的使用者可能自己不清楚,細節的解釋就更不可能了。所以我們在專案的調研前必須定好這次專案調研的目的。我認為有這樣幾條:一是讓使用者認為我們有足夠的實力去了解現有的企業流程業務;二是儘可能獲取一些資訊,以便進入下一階段的工作;如果能給競爭對手設計一些門檻,瞭解到競爭對手給我們設計的門檻更最好不過。
在此階段我們的最主要目標是讓使用者認同調研者,認可公司的實力,認同我們在這個領域的能力和經驗,而不是努力完全地搞清楚企業的業務流程。要完成這個目標,必須透過規範的業務流程和切實可行的計劃讓使用者來感受我們的工作質量很高,認同感強烈,這樣給競爭對手一些壓力,獲取專案的成功的可能性就越高。
二、專案調研計劃
1)計劃的制定
很多專案調研計劃都寫成這樣:某年某月某日,對某部門進行業務調研。因為計劃者沒有想好調研從什麼地方入手,到現場走一步看一步再說吧;要麼就是依靠自己過去的工作經驗來進行調研。我們可以換個思路想一想,我們的工作計劃是提交給使用者領導看的,是讓使用者領導來進行確定的。那麼我們的計劃必須是可以執行的,可操作的,使用者是可以看得明白的。如果你的計劃展現了這些內容,領導只是將時間的前後調配一下,安排起來越方便,安排相關人員來配合我們的調研的時間也就相對容易一些。
根據我以前的一些經驗,,對於使用者方,我建議將計劃細分到上午下午,調研的部門是哪個,需要什麼樣的人員進行配合,時間有多長,需要了解哪些方面的內容,要準備哪些資料。這樣一來,我相信主管領導安排工作起來就相對簡單很多;
2)計劃的使用者確認
以前曾經去犯過這樣的錯誤,專案調研計劃做好,傳真給使用者,立即按照計劃去執行,結果常常是使用者沒有時間,或者是說根本沒有準備。搞得雙方都不開心。其實我也很鬱悶,我的注意事項中不是寫好有問題給我打電話嗎?沒有打電話就是認可我的專案計劃嗎?其實不然,很多使用者方領導在接到你的傳真後,沒有認真研究過你的專案計劃,更談不上想想你這個計劃有什麼不合理,那更不會去落實你這個專案調研計劃了。
那我們如何辦?傳真完了,過一些時間打電話給負責人確認,請使用者確認是否可以按計劃進行。若可以打電話再和具體的部門業務人員進行商協,計劃內容是否認可,得到肯定後,這份計劃才真正在使用者哪邊切實可行。
當然如果能透過一些企業的人脈關係將一些前期的資料準備清單提交給相關的人員並積極落實,則更讓使用者認同我們的公司的實力。[@more@]
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/7839396/viewspace-946028/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 如何準備專案(轉)
- 專案招投標流程及管理:招標(轉)
- 淺談國外工程專案的投標工作(轉)
- 對SAP專案文件的考核標準(轉)
- 專案前期調研行動小析(轉)
- 專案招投標流程及管理:開標、評標和中標(轉)
- 需求調研分析中的專案干係人概念(轉)
- ERP專案準備三要素(轉)
- 科研專案管理的成功標準和風險分析(轉)專案管理
- 準備專案總結
- (三)專案準備工作
- 轉---十條標準評估創業專案創業
- 從react轉職到vue開發的專案準備ReactVue
- 投標人撤回投標檔案是否退回投標保證金
- Windows 2000安裝前的準備(轉)Windows
- 軟體專案需求調研過程管理小議(轉)
- 專案管理之---競投專案總結(轉)專案管理
- 資訊化專案實施前面的準備工作(轉)
- 軟體專案管理“固化、簡化、標準化”(轉)專案管理
- 實驗專案一準備
- 新專案準備啟動
- 軟體專案開發的文件編寫標準化 (轉)
- 衡量ERP專案成功與否的七個標準(轉)
- Laravel 專案的起始工作與準備Laravel
- 如何定義專案的成功標準?
- 對SAP專案文件的考核標準
- 學前準備工作
- 需求調研在ERP專案選型中的重要作用(轉)
- (原)ERP實施前應該準備的工作——調侃版
- 【手摸手玩轉 OceanBase 174】恢復前準備準備工作有哪些?
- 前端的flutter之路(二):專案前期準備前端Flutter
- CPA二十二--合併前的準備工作(轉載)
- egg商城--專案準備篇
- 研發活動的專案導向(轉)
- QPM 準備優化前的思考優化
- DOSBOX使用前的準備工作
- Laravel 開發前準備Laravel
- ForefrontClientSecurity部署前準備client