一個研發專案的成敗既有專案外部的因素,也有專案內部的因素。對於專案外部的因素專案組一般是難以扭轉的,例如專案經費的削減,組織的業務方向的變更,客戶對合同的違約等等。幾年前,筆者離開了資訊產業部的研究所,來到一家民營的醫療器械企業,任研發中心的臨床資訊系統專案經理,但萬萬沒想到,筆者所主持的專案失敗了。本文與大家分享一個失敗的案例,從中我們分析失敗的原因以及一些啟示。

 

failure 1

1、上層分歧給專案帶來麻煩

我剛來的時候,這個專案已經立項了,只是一直沒有找到合適的人來實施。所以總覺得我是在受命組建一個新的部門,組織文化是空白的,不會有任何問題,可是上層的一些分歧卻給我的工作帶來了麻煩。公司的總經理和技術副總在工作上有矛盾。作為總經理招來的部門級主管,我在上班前一直沒能與技術副總見面,不知道這算不算總經理犯的一個錯誤,雖然越級的人事安排也許有他自己的考慮。總經理介紹了他的一個同學作為我們的技術合作單位,有過一些初級的技術交流,技術副總後來得知此事,於是我就有了一大罪過:“你們探討的問題都是代表公司的,到底誰是技術副總?”技術副總經理找我談話時,我好半天沒喘過氣來。如果就數據庫內某個字段的定義、用哪個芯片更好點的問題都要請示技術副總,我這個崗位還有存在的價值嗎?

於是我開始反思,認識到自己犯了一個很嚴重的錯誤:初來乍到,別人還沒認清你的特點,信任度還沒建立起來,怎麽就沒注意請示匯報呢!隨後,我向副總承認了自己沒有及時請示匯報的錯誤,並澄清了我們只是進行了一些技術交流,沒有任何的越權行為。我開始注意調查,發現其實質是副總對該專案不是很熱心,並因此與總經理產生了分歧,加上以前的許多事情,矛盾一下爆發了,我又是總經理招來的人,合作方又是總經理的熟人,這個事情就愈發嚴重了。

2、上司有時比董事長管用

無奈之下,我只好把合作方砍掉,並且事事早請示晚匯報。不能在同一個地方跌倒兩次,我總結發現,直屬上司的支持比董事長都好用。高層只能在戰略上支持,戰術上還是直屬上司的配合,正應了一句話“縣官不如現管”。另外就是新到任的職業經理一定要對新的崗位進行認真調查,入職前與未來的上司和下屬進行溝通是非常必要的。這次事件平息了,但有些事我不得不變得無所作為。很多審批權限在副總手里,於是專案一拖再拖。8個月後,在公司上層不斷的施壓下,專案組終於開始組建。

failure 2

3、研發人員指揮生產的惡果

產品開發過程平靜而又順利地結束了。我們決定採取用戶購買後測試的方式。由於用戶測試過於漫長,在進入這個測試之前,產品就歸檔轉生產了。

在我供職的這家民營企業,其高層和80%的中層幹部都來源於一家老牌的國有醫療器械企業。這家公司長期從事手術床設備的相關業務,後來的新人也都是為那兩個專案配的,所以新專案除了我和我的團隊之外,無人過問。我們求教於別人,經常得到友好而又歉意的一笑。

圖紙完成了,生產部只安排了一個小夥子學習生產這個產品,沒有安排專門的工藝人員轉化工藝文件。這時手術床的設備產量已經不小了,並且中了幾個大標,中標的機器都是成熟老機型,生產人員也較熟練,所以生產部就把主力都安排到那邊去了。對生產部來講,中標機器的生產是主要任務,我負責的機器就降到次要而又次要的地步,物流的供貨也是優先別的機型。

我太急了,太需要有一個結果來證明,急功近利的結局就是不懂生產管理流程的專案部開發工程師全力配合生產,犯了瞎指揮的錯誤,導致生產過程檢驗不規範、裝機不符合要求、生產檢驗文檔不全、零件編號混亂,一句話,亂了,一切全亂了。但是,機器還是源源不斷地被發走。我暗自禱告,產量一大,我們開發的產品占主體時,一切會好起來的。

failure 3

4、越俎代庖的代價

剛開始的裝機和培訓,服務部門的工程師沒有人特別熟悉這臺機器。於是服務部的經理找到我求援,希望開發工程師能出差。為了確保機器能順利推廣開,我應承了下來,服務支持文檔、服務工程師的培訓就這樣耽誤了下來。如此周而複始,最後只要有客戶咨詢或投訴,就直接轉到專案部,使專案部的很多具體工作進行不下去。

這還不是最糟糕的,開發工程師並未經過服務培訓,而我們專案部的工程師對那些又不了解,其安裝和用戶培訓卻又要做,可想而知,結果自然是不到位,最後對機器、服務的抱怨都集中到了專案部上。

拆東牆補西牆的救火沒能使流程理順,這時又出現了機器抗干擾差的投訴,這原本通過預研可以提前預防,現在也是尾大難調。只好找了一所大學的教授協助解決,雖有改進,結果也不是很理想。不過我實在沒精力拿用戶進行試驗了,加上這番折騰,這個專案的利潤被服務、退貨、換貨耗掉了一部分,銷售渠道對產品的反應也很不好,抗干擾差、服務差、發錯貨,等等。面對危局,我無奈建議公司決策層停掉該專案。

這個故事結束半年了,每每回想,總是感慨:專案不是在最後才失敗的,也許它一開始就是一個錯誤,也許它的路線方向就是錯的。

failure 4

5、成也老專家,敗也老專家

在我們的團隊中,有一位資深工程師、一位從業不久但業務熟練的軟件工程師,另外還聘請了一位老專家作技術顧問。隨後的階段,那位老專家起到了保駕護航的作用。然而,如果沒有對老專家的“過度信任”,也不會有產品推出後的狼狽局面。因為該設備要用到手術室中,手術室的電磁環境不但頻率複雜,強度還不小,可惜這是產品銷售後才發現的,為時已晚。開發中也曾有人提出這個問題,用不用考慮一下干擾問題,那位老專家一句話:“我們以前做過的都沒什麽問題。”問題是該老先生原來是做非手術室設備的,其電磁環境條件比手術室要好得多。我嘗試著提了點反面意見,被很不屑地化解了。

“阻礙社會進步的不是少年人的無知,而是老年人的固執”,終於有了切實的理解。在技術工作中,作為專案經理,別相信任何不經調查就得出“沒問題”的口頭保證,尤其是所謂資深老專家對新問題的結論。昨天的經驗往往是明天失敗的導火索。在預研階段,要把所有可能的試驗結果都呈現出來再做定奪。即使預研失敗,損失也小得多。

 

文章節錄:中國項目管理資源網

圖片來源:1 2 3 4 

 

ProjectClub 平台聚焦於提昇職場人溝通軟技巧與做事硬實力,提升您的超級競爭力讓您Work Hard 到 Work Smart

comments

登入

會員消息

最新消息 (站長有話跟你說)

線上直播專區

■追蹤PM編『互動圖文』讓你無痛學習

■註冊為新會員可以獲得專案點數10點

■不要用手機下載範本!

■記得每天登入有一點,

■怎麼註冊?怎麼輸入點數序號?

■忘記密碼嗎?快點來信

■找文章請善用『搜尋』功能

■點我闖關搶點數~

■點我去範本軍火庫