24h購物| | PChome| 登入
2010-10-18 18:02:19| 人氣2,199| 回應0 | 上一篇 | 下一篇

軟體專案管理第四週課程心得

推薦 1 收藏 0 轉貼0 訂閱站台

Proposal Evaluation Techniques

由於肥蝦常常自以為自己對PMBOK有一定的瞭解，加上自己這十年多的實務經驗，因此有時不免會自我陶醉一番，自我感覺良好。肥蝦昨日聆聽李坤清老師於課堂上的教導後，不禁有了「聽師一席話，勝讀十年PMBOK！」的感嘆！

話說昨晚，軟體專案管理課程，肥蝦一組報告【軟體專案管理】課本(林信惠、黃明祥、王文良合著的)第三章軟體開發模式，其中肥蝦負責第一節導論、第二節瀑布模式與第三節快速雛型法，以及自己所選擇的一篇期刊論文：" On exceptions and the software development life cycle"。當肥蝦於課前準備，閱讀課本第二節之際，發現書中對瀑布模式的圖形表示與肥蝦以往認知不一，就去找了那Royce於1970年發表的名作"Managing the Development of Large Software Systems: Concepts and Techniques"一看究竟，並將原版的圖形列示於簡報之中。當初Royce所提出的五大步驟─STEP 1: PROGRAM DESIGN COMES FIRST；STEP 2: DOCUMENT THE DESIGN；STEP 3: DO IT TWICE；STEP 4: PLAN, CONTROL AND MONITOR TESTING；STEP 5: INVOLVE THE CUSTOMER─雖說內容上因電腦科技的進步與時代環境的變異有所出入，但其核心精神仍是現今軟體開發專案所要繼續努力的方向。

本組中的錦崇同學報告了一篇1997年發表的" Methodologies for Information Systems Investment Evaluation at the Proposal Stage"，該文對歷來評選建議書的方法作了一個整理、彙整與比較，並且提出了所謂的一般觀察(general observations)與建議(Recommendations)。針對1997年的這篇文章，令肥蝦最感興趣的是其對於評選中對於風險衡量的述說。該文中將風險視為特定投資的不確定結果的衡量數值，在一些評選方法中或將之列為獨立的評選項目，或是將不確定性改以支出的提高，或是預期收入的減少，或者可如敏感性分析中的最佳(best)或最差(worst)的情況進行分析。其中，多重標準方法(multi-criteria methods)中的SIESTA(Strategic Investment Evaluation and Selection Tool Amsterdam)的模型中，對於風險倒是有較全面的描述。該文對照於現行的實務作法，大都能涵概，但就如文中所說，目前尚無文獻或研究，提出評選方式與專案成功間的因果關係。

對照於PMBOK對於Proposal Evaluation Techniques的說明，該篇文章所述當然是更為深入與有條理。原在PMBOK 2000版中的12.4 SOURCE SELECTION中Input有建議書(Proposals)、評選標準(Evaluation criteria)、組織政策(Organizational policies)，經由使用契約協商、加權系統、篩選系統或獨立估算等工具與技巧後，即產生了合約(Contract)，全無Proposal Evaluation Techniques此一字眼；到PMBOK 2004 12.4 Select Sellers方出現此一名詞；2008版因將第十二章採購管理併為四節，因此Proposal Evaluation Techniques對應出現在12.2 Conduct Procurements。

鑑於專案之中確實存在了諸多的不確定性，那如何在評選建議書之時經由評選的機制，進而洞燭機先？這一直是肥蝦個人的主觀以為。不意李大師於報告後的指導中，一語驚醒夢中人：「目前實務中的評選機制，都是假設該建議案經採納之後是確實能實現的！」也許專案延遲，也許專案超出成本，但這個終能完成的假設，確實是肥蝦所經歷過專案評選中的前提。這假設本身就存在了多大的風險與盲點，肥蝦以往就如1997年該文所說的一般，將風險視為支出的增加或是預期收入的減少。李師的這一提醒，那肥蝦頓時冷汗直冒，對於自己的無知更多了一份警醒！接著李師提出了一個方式，作為評量風險對於整體資訊專案的影響。其法為在以成本效益分析中，將所估算成本再以【專案完成機率】與【完成百分比】兩個緯度，進行專案效益分析。這就像把「12.2.2.2 Proposal Evaluation Techniques」引入「11.4.2.2 中Expected monetary value analysis」的概念！把每個方案以不同的完成機率與不等完成百分比，進行效益與成本分析。這觀念可以如下圖表示：



當然要計算出所有專案其成功機率與完成百分比率下的效益成本比，誠為困難，並且需要耗費不少資源；但如具有此等觀念，比較與選評專案之際，就能更加審慎的；而且就算概估出50%與100%，也比單純以100%視之，更加妥適。

李師雖常自稱離開業界、隱於杏林，沉浸佛學、疏於專業已久，但這實是老師自謙之辭，光這一句：「假設該建議案經採納之後是確實能實現的！」讓這自以為凡事能先審視假設前提的肥蝦，受益斐淺，對自我所習以為常的【執見】，更是多了一分認識與破除。

我要檢舉
#軟體專案管理
台長： IT肥蝦

您可能對以下文章有興趣

人氣(2,199) | 回應(0)| 推薦 (1)| 收藏 (0)| 轉寄
全站分類: 教育學習(進修、留學、學術研究、教育概況) | 個人分類: 世新課程心得 |
此分類下一篇:軟體專案管理第五週課程心得-PP vs. PMP
此分類上一篇:研究方法期末學習心得分享

我要回應
否 是 (若未登入"個人新聞台帳號"則看不到回覆唷!)
* 請輸入識別碼：
請輸入圖片中算式的結果(可能為0) 
(有*為必填)
TOP
詳全文