專案會失敗的常見七大原因。

blog_project_failure 

(圖片來源:http://www.wellingtone.co.uk/blog/?p=61)

根據 ZDNet 在 2011 年的一篇文章指出,專案的失敗機率為 37%,而在許多機構的研究報告指出,全世界專案的成功機率約略為 16%,本文將根據 Alan 工作經驗探討專案會失敗的原因和可改善的方案。

專案會失敗的七大原因:

1需求不明確或錯誤:在專案初期,因某些產品特性的關係常常客戶的需求不明確甚至錯誤,導致最終產出不符合客戶的需求而宣告專案失敗。並不是說需求一點要多明確或正確這專案才能做,但是針對需求變動性高的專案,一開始使用者跟開發商在談開案的時候就要考慮進去而設定一些條件和規則。譬如說在專案範疇或時間內可以做怎樣程度的變更,否則就要進入需求變更的流程而產生額外的費用。這是為了保障開發者和客戶的權益,確保變更可以是在掌控之內。

2. 沒做專案篩選:在此所指的篩選是開發者和客戶端都需要做的。開發者評估此專案是否有能力執行,是否會造成公司虧損。客戶端則是要評估此開發者的開發經驗和技術是否能夠順利執行專案。有點像是面試時面試者和面試官其實是需要彼此瞭解並評估彼此開條件是否適合。譬如說,很多業務常常會靠三寸不爛之舌幫公司接進來很大的案子,很多公司也想說是個大案子可以賺很多錢就接了,假如公司執行能力不足或內部專案資源不足的話那失敗的結果就是可預測的了。很多公司因為這樣失敗後沒想清楚就一昧的怪罪工程師或PM能力不足或不夠努力,身為專案實際的執行者只有辛酸兩個字可形容。

3. 專案無明確預算限制:專案預算很多不是很好嗎?有充足的預算很好,但是沒有定義要花多少預算來做一個案子是一個很大的問題!那就像一個不會理財的人中了樂透,錢往往不會花刀口上。此現象最容易會發生在一下子就賺很多錢的大公司,或者擴張速度太快的公司 (或者是含著金湯匙創立的公司)。到了後期錢花光了公司開始虧損接下來就裁員倒閉也就見怪不怪了。

4. 專案無明確定義最終交付條件:這點跟第一點所提到的需求不明確有異曲同工之妙,一個是一開始沒想或沒講清楚要做的是什麼,一個是沒想或講清楚怎樣才算結案。假如沒有一開始就定義好的話,那專案中期開發者和客戶一定會在這點上面周旋,開發者為了商譽和後續合作機會常常會以妥協收場。妥協贏得客戶的口碑就好了嗎?看看國外電影特效產業如何虧損倒閉就很清楚了。電影特效很好看沒錯,但特效公司因財務上出問題而倒閉的不在少數。開發者和客戶要怎麼談才好?想想看如何才能雙贏吧!只有一方吃虧的生意通常是不會長久的。

5. 資源頻繁調度或缺乏:專案管理裡面有一個名詞叫做稼動率 (可粗略解釋為資源利用率),Alan 曾經經歷過公司為了提高工程師的稼動率而在各專案間頻繁的調度人力資源,表面上的數字看起來很好看,但是背後有很多的隱憂。

A. 工程師對於專案的認同感會降低,在此的認同感可解釋為忠誠度,通常完成的作品品質會較差因為可能也沒有完整足夠的時間顧及品質。

B. 工程師的成就感會降低,原因是會覺得自己是個救火隊員而沒有完整的完成一些引以為傲的作品。

C. 對專案來說是一個很大的風險,假如專案是仰賴幾個程度較好的工程師,這些工程師又因為突發的任務需要調去支援別的專案,專案的品質可能會因此下降。(看看 EA 的幾個大作怎麼搞的)

6. 目標使用者涉入程度過低:很多的案子是需要使用者不斷的確認需求的,譬如軟體專案,遊戲專案,視覺設計的專案。Alan 有個經驗是,每每專案團隊將產品功能都實作完畢,在產品上市前,公司的重要上級才開始稽核而退回。為何不在單一遊戲功能實作完畢後就執行稽核而要等到專案上市的前一刻才說不符合期待和品質的要求?此舉是浪費公司的錢和大家的時間。或者是案子在初期聽了使用者的需求後就少有聯繫,直到產品交付前或後才讓使用者驗證。有個很好的解決方案是執行敏捷式開發並要求使用者在開發期間協助做需求驗證。

7. 上級單位對專案執行做過多的干涉:這,應該不用解釋太多,常常出錢的人或者是公司高層憑著自己的 "經驗" 和 "主觀" 影響專案的進行方向,結果可能是專案成品四不像,或者是只符合高層的需求但不符合目標客群的需求。這時 Alan 想跟高層說:除非你跟賈伯斯一樣眼光獨到,否則請相信專業!合理適度的向下授權和相信自己所僱用的專業人士,比較容易出現好的結果。譬如當初暴風雪跟他早期的出資者就有談好說不要干涉團隊的研發方向,要讓團隊在產品研發上有足夠的自主權。

以上七點是否有點出朋友們的痛處呢?喜歡的話請給個讚並跟 Alan 分享你的經驗吧!

原文連結 : http://elitegrouppm.pixnet.net/blog/post/49036014

-------------------

筆者:Alan Feng

大學由資管系畢業後便投入職場,先後擔任程式設計師,系統設計師,系統分析師,專案管理師等職務。

曾服務於資訊服務業,筆電代工設計公司,和遊戲公司的專案管理師/程式設計師~目前在廣告行銷公關業擔任系統分析師。

持有國際 PMP 證照並持續努力累積社會大學的經驗中。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 212,185评论 6 493
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,445评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,684评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,564评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,681评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,874评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,025评论 3 408
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,761评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,217评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,545评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,694评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,351评论 4 332
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,988评论 3 315
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,778评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,007评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,427评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,580评论 2 349

推荐阅读更多精彩内容