減少IT 專案失敗的風險因子

在人生的任一階段，與失敗有關的2 件事是真實的：失敗很常見，而且沒有人喜歡它。由於各種原因，失敗不可能被完全避免。不是所有失敗都是絕對的，事實上多數失敗都是相對的。成功給我們的啟發，即使有也不會很多，但失敗的教訓，可以讓我們在未來做得更好。因此，在任何時候都不曾失敗或許是一個錯誤的主張，失敗可能啟發組織發生非常微小而正面的改變。諷刺的是，失敗伴隨著成本。在IT 專案中，可能衍生的成本如未符合專案範圍、未能如期完成或超出預算。而在人力方面，失敗可能導致士氣低落，並可能對失敗專案中涉及的所有職能領域的員工生產力產生負面影響。

導致專案失敗的許多風險已經被明確化，列舉2 項與IT 專案最主要的風險面向如下：

1. 投資(未能發揮效益)。
2. 專案權責( 因為問責而失敗)。¹

2004 年一項針對服務於年營收逾5 千萬美元企業的200 位IT 專家所做的全球性調查顯示，分別有 71%及72%的受訪者認為，「投資」及「專案權責」2 個風險因子「非常重要」。² 為數眾多的調查明確反映一個相關的結果：雖然專案管理技術隨著時間已有明顯的改善，但 IT 專案的高失敗率仍令人擔憂.³

專案失敗率即使僅是些微的改善，可能產生很大的進步。在多數的組織中，IT 專案的角色日益重要，IT 不僅推動各項業務 (例如，供應鏈改善)，也是組織創新及成長的關鍵。因此，IT 專案成功完成非常重要。例如，任何專案時程上的延遲，可能耽誤產品投入市場的時間；任何專案範圍的妥協，可能導致一系列的修正改版，這些都會使得開發部門與使用部門感到灰心。

IT 專案的解析

一個IT 專案是由process(專案規劃與交付)、context(被服務的系統)及 content(系統提供的服務)等3 個次系統組合而成，process 的最主要影響者是專案經理(PM) ， 其擁有最高的管理支持；context 的最主要影響者是合作的管理部門與使用者；至於content 則是 IT/IS 專家。首先，致力創建context 與content 間的協力，使2 個次系統能密切合作一起工作；其次是探求變革的原因， 包括文化、領導力及組織的問題；第三則是說明如何變革。

當意向被導入這個三元組合時，結果就會實現。顯然，任何不合標準的產出， 都可能與process 、context 或 content 未能如預期發揮作用有關，而導致產品的缺失（例如，有缺陷、延遲提交或過於昂貴）。成功或失敗的複雜性在於這3 個相對獨立的子系統它們自身的成熟度與效能、文化以及它們之間相互影響的效益。⁴

專案複雜性、溝通問題、目標明確度，以及個人角色的問責（採行正確作為，並且如期及在預算內完成）是專案成敗的關鍵因素。任何這3 個子系統之間缺乏連結，意味著某種退化，可能導致不太理想的結果。這3 個系統中文化、權力結構甚至語言存在很大的差異， 往往使整個專案計畫無法保持平衡。

整個專案失敗的主要原因，可能源於3 個相互交織的子系統中的任何一個。例如，缺乏process 成熟度或專案紀律係源於專案規劃和交付，而業務需求被轉換並執行成為技術規格則植基於 content。負責context 和content 的子系統如果無法有效運作，即使一間具有最高級別CMMI 的公司也可能會失敗。

這種專案管理觀點，在追蹤失敗的早期觸發因素及評估從失敗中復原的最佳方式方面非常有用。如果缺乏有影響力的擁護者及變革的原動力（ 在 context 子系統中），可能會使幾個關鍵因素的產出品質降低。或者，在規劃及交付子系統中流程規劃未臻完善，可能導致專案的風險分析不充分，此外當專案執行階段選用不適用的軟體，content 子系統也可能會出現問題。⁵

最後， 體認專案的多樣性甚為重要。規模、重要性、期間、成本、技術深度、用戶群、策略重要性等，這些是一個組織中驅動專案差異化的眾多因素之一。因此，專案失敗可能會對組織及其對失敗程度的回應產生不同影響。

個案研究

為了探求專案失敗的原因並且提出減少失敗的方法，以下列舉發生在不同組織的3 個失敗專案：

個案A
一個歷經多年，花費數百萬美元的專案未能如期完成。專案的規劃及交付子系統確定須為這項缺失負責，專案管理辦公室（PMO）未能始終如一地報告專案進展情況，甚至在報告專案進度的有限努力中，PMO 描述了14 個專案成功因素，但有些無法量化。此外，追蹤業務目標實現情形的措施清單欠完整，導致對實際進度的控管不佳。

概括而言，如果規劃及交付子系統是失敗的根源，那麼問題就會在許多專案 (即使不是全部)中浮現，因為規劃及交付子系統顯然存在缺乏成熟度和紀律性的弱點。這可能會影響context 子系統中的許多利害關係人，並且使content 子系統中其他有能力的IT 專業人員無法發揮功能。

在context 子系統中發現，雖然功能領域的支持人員是專職的，但是負責關鍵決策的功能經理卻呈現混亂，結果導致未作決策或決策被延遲。此外，除其他因素外，在專案管理方法的各個功能領域存在顯著差異，這也導致了功能領域間的不信任，肇生許多問題。

以下說明建議採行的行動方案：

• 對每一個功能領域，明確定義負責經理的決策權限。
• 確保包括供應商在內的所有利害關係人間，能充分、完整、公開的參與、協調及溝通，以強化共同的期望，相互借鑒，並建立對專案的信心和信任。

個案B
一個執行多年，花費數百萬美元的專案，因延遲執行決策而受到影響，對專 案成本、進度及範圍產生了連鎖效應。關鍵的原因是，專案經理及專案辦公室的權威被破壞了。當專案管理的紀律和權威被邊緣化時，專案就會受到損害。例如，已經完成了主辦決策的文件，並已向組織規定的治理當局簡報,⁶ 但由於與供應商的契約談判及專案審批流程的時間未能同步，專案執行的及時性受到阻礙。潛在因素是資深專案經理和專案辦公室決策的權力有限，許多決策必須推向執行的領導階層。

為解決此一問題，建議採取以下步驟：

• 重新審視專案經理的決策授權，適當調整董事會、指導委員會及執行長的決策權。
• 建立契約變更流程，明確規定處理時限，以便在某些情況下加快審批。
• 確保每個人都了解自己的授權及組織的治理結構，並要求每個人及部門遵循治理結構。

顯然，這個案例指出了process 成熟度及紀律的問題，以及缺乏領導力對規劃及交付子系統的影響。因此，任何(所有)由組織執行的專案，都潛存效能不佳的風險。

個案C
一個執行多年，花費數數百萬美元的專案，面臨專案風險辨識的弱點。經由根本原因分析的一些觀察包括：

• 業務需求的定義缺乏清晰度、共識、完整性及品質，影響專案範圍的定義及理解，並因而影響了績效預期與專案進度，以及工作量和成本估算。
• 利害關係人不了解他們的承諾。
• 需求審核、驗證、確認及批准流程未盡完善。
• 需求可追溯性不一致。
• 忽略關鍵功能及品質屬性，可能導致設計不正確或不完整。

要解決這個問題，公司應該考慮以下步驟：

• 建立正式的需求開發流程，包括需求審核、接受及承諾。
• 建立完善的需求管理流程，以改善可追溯性（例如，功能、技術、界面、硬體及軟體）。
• 確保專案需求的同業覆核過程，能真正增加價值。

IT 專案的稽核

稽核人員在IT 專案的角色，必須對組織的關鍵性專案能被適當管理並成功完成提供確信。⁷ IT 專案本質上決定組織的未來發展；如果能被優先且正確的選擇，IT 專案的成功對於組織未來的成長，是不可或缺的。基此，IT 專案是組織發展方向的前導，稽核人員提供有關 IT 專案的專業意見， 包含新興風險 (Emerging risk) 及未減輕的風險 (Unmitigated risk)，必須能彰顯其對組織的價值。

實務的意涵

專案管理辦公室(PMO) 的鐵三角 ( 人、流程及科技)⁸ 以及資源 ( 舉如 CMMI for Development V1.3)⁹ 中影響專案績效及成功的關鍵因素是人。本文所列舉的個案凸顯一個事實：即使隨著時 間經過，流程已趨完善並且採用企業最佳實務，仍無法解決文化上的問題。

組織重視在流程方面的投資，以建立範例及權威，然而，這些制度化流程可能是脆弱的。高比率的專案失敗顯示，專案流程在各層級的加值並未發揮功能，也未能與組織的文化密切結合。印證隨後的品質保證評估， 執行特定 CMMI 流程範圍改善建議的管理(上述討論的個案中)，明顯逐一改善專案的成功率， 並使有關流程的組織文化獲得改善。

最後，因為組織的記憶有其極限，要從過去失敗的例子中學到教訓是有困難的，除非所有失敗的重要專案，都能被適當地記錄失敗的原因及補救方法。當組織能與其利害關係人分享這個組織特有、真實的病歷，有助減少未來再發生專案失敗。

作者註記

本專欄內容係作者個人意見，與其員工無涉。

Endnotes

¹ The Economist Intelligence Unit, Global Study on Information Risk Management, 2002
² IT Governance Institute, Information Risks: Whose Business Are They?, USA, 2005, p. 9
³ See, for example, The State of Project Management Survey, Wellingtone Project Management, 2016
⁴ Yeo, K. T., “Critical Failure Factors in Information Systems Projects,” International Journal of Project Management, vol. 20, iss. 3, April 2002, p. 241–246
⁵ Op cit, Yeo
⁶ IBM, Global Making Change Work Study, 2008, https://www-07.ibm.com/au/pdf/making_change_work.pdf
⁷ Ibid.
⁸ Project Management That Works, “The Iron Triangle of the PMO: People, Processes, and Technology,” 3 June 2011, www.pmthatworks.com/2011/06/iron-triangle-of-pmo-people-processes.html
⁹ Chrissis, M. B.; M. Konrad; S. Shrum; CMMI for Development: Guidelines for Process Integration and Product Improvement, 3^rd Edition, Addison Wesley, USA, 2011

Quality Statement:
This Work is translated into Chinese Traditional from the English language version of Volume 3 2017 of the ISACA Journal articles by the Taiwan Chapter of the Information Systems Audit and Control Association (ISACA) with the permission of the ISACA. The Taiwan Chapter assumes sole responsibility for the accuracy and faithfulness of the translation.

品質聲明：
ISACA臺灣分會在ISACA總會的授權之下，摘錄ISACA Journal 2017,Volume 3中的文章進行翻譯。譯文的準確度及與原文的差異性則由臺灣分會獨立負責。

Copyright
© 2017 of Information Systems Audit and Control Association (“ISACA”). All rights reserved. No part of this article may be used, copied, reproduced, modified, distributed, displayed, stored in a retrieval system, or transmitted in any form by any means (electronic, mechanical, photocopying, recording or otherwise), without the prior written authorization of ISACA.

版權聲明：
© 2017 of Information Systems Audit and Control Association (“ISACA”). 版權所有，非經ISACA書面授權，不得以任何形式使用、影印、重製、修改、散布、展示、儲存於檢索系統、或以任何方式(電子、機械、影印、或錄影等方式)發送。

Disclaimer:
The ISACA Journal is published by ISACA. Membership in the association, a voluntary organization serving IT governance professionals, entitles one to receive an annual subscription to the ISACA Journal.

Opinions expressed in the ISACA Journal represent the views of the authors and advertisers. They may differ from policies and official statements of ISACA and/or the IT Governance Institute and their committees, and from opinions endorsed by authors’ employers, or the editors of this Journal. ISACA Journal does not attest to the originality of authors’ content.

Instructors are permitted to photocopy isolated articles for noncommercial classroom use without fee. For other copying, reprint or republication, permission must be obtained in writing from the association. Where necessary, permission is granted by the copyright owners for those registered with the Copyright Clearance Center (CCC), 27 Congress St., Salem, MA 01970, to photocopy articles owned by ISACA, for a flat fee of US $2.50 per article plus 25¢ per page. Send payment to the CCC stating the ISSN (1526-7407), date, volume, and first and last page number of each article. Copying for other than personal use or internal reference, or of articles or columns not owned by the association without express permission of the association or the copyright owner is expressly prohibited.

免責聲明：
ISACA Journal係由ISACA出版。ISACA 為一服務資訊科技專業人士的自願性組織，其會員則有權獲得每 ISACA JOURNAL 摘譯文章 15 年出版的ISACA Journal。

ISACA Journal收錄的文章及刊物僅代表作者與廣告商的意見，其意見可能與ISACA以及資訊科技治理機構與相關委員會之政策和官方聲明相左，也可能與作者的雇主或本刊編輯有所不同。ISACA Journal 則無法保證內容的原創性。

若為非商業用途之課堂教學，則允許教師免費複印單篇文章。若為其他用途之複製，重印或再版，則必須獲得ISACA的書面許可。如有需要，欲複印ISACA Journal 者需向Copyright Clearance Center(版權批准中心，地址：27 Congress St., Salem, MA 01970) 付費，每篇文章收取2.50 元美金固定費用，每頁收取 0.25 美金。欲複印文章者則需支付CCC 上述費用，並說明ISACA Journal 之ISSN 編碼(1526-7407)、文章之出版日期、卷號、起訖頁碼。除了個人使用或內部參考之外，其他未經ISACA 或版權所有者許可之複製行為則嚴明禁止。