Servo 創立T軟時，初始鎖定半導體業當目標客戶，除了因為他之前在該行業當過MIS幾年有點關係外，主要是看到該行業的資本支出都相當龐大，估計要分一杯羹是相對容易的。因緣際會，那個行業流行導所謂的 Agile Manufacturing。SM這家公司，現在也是T軟最大客戶，為了提高客戶服務滿意度，規劃了【虛擬製造現場及時看板系統】。幾乎是一個完全客製化的委外開發案。Servo完全無視競爭對手大多是千倍規模的大型公司，為了擴張決定試試看。

在與客戶簡報的前一週大老闆Servo 突然提議：必須特別強調我們專案管理手法採敏捷框架 Unified Process，但當時全公司除了少數有了解一些UML相關文件或資料中提到Objectory Process外，基本上沒人算得了是專家。當時似乎業界也還沒有人用Unified Process這樣的名詞，大老闆說的 Unified Process 其實是大家都習慣他的口誤： 他總是將 UML (Unified Modeling Language) 與 Objectory Process 攪和成 Unified Process。也許是巧合，幾年後 Rational這家公司的 Unified Process RUP廣為IT人知道。大老闆至今似乎還蠻介意全世界居然沒人或文件記下是他第一個提出甚且創造出Unified Process這個名詞的。

儘管沒人是專家，隨著物件導向的口號蔓延在T軟裡已經有相當多分析師嘗試用UML的 Use Case來製作物件導向分析文件。要理解 Unified Process 似乎並沒多大問題。但要在短短一週內如何讓客戶相信我們是Unified Process專家? 更令人覺得恐怖的大老闆提出要求後的頭幾天，就只有指示要大家讀一下UML與Objectory Process相關文件，而且要讀到這種程度：可以分享自己看到與傳統 Waterfall 作法的差異；要能夠根據過往參與專案經驗，說明如果改採用Unified Process可以減少什麼的痛苦、客戶可以少抱怨什麼。這樣的任務相比要說服SM這客戶這又是小菜一碟了，也許Servo 已經預測到結局了。

距簡報日只剩四天，終於大老闆召開會議，揭示報告要做變更的幾個重點，要大家腦力激盪協助：

• T軟雖是小公司，主業是軟體代工，囿於品牌知名度，人力工時的報價偏低。但因專案管控得宜，成立五年來營收已經好幾番的成長，同時年年獲利亮眼。這得益於我們骨子裡就有風險管理的基因。
• Unified Process是我們本來就打算要推動的。不可捏造我們有實際Unified Process經驗，只要提一兩個實際專案為案例：我們深深體會如果改採Unified Process，那麼我們會減少什麼樣的痛苦。
• 為何我們要在此專案強行引進Unified Process：這個專案全世界沒人有經驗，儘管已經看到上千頁的客戶需求規格書，可預期於實施過程中需求會有天翻地覆的變更。
• 這個專案不該被簡化成機台整合或是企業應用整合成看板管理系統。在實施過程中能有效地挖掘出SM公司的客戶需要什麼，同時專案管理模式能因應後續的需求變更才是重點。
• 採Unfied Process客戶需要做什麼改變。如果客戶無法配合我們改變專案實施流程，我們必須立即退出競標。

往後快二十年漫漫職涯裡，Gavin 與佳麗最常消遣彼此，那倒數三天大老闆Servo ，RJ還有連他們共七位拼老命的修改百頁的提案書與簡報。最後定稿時修改文件的貢獻與打呼聲大小成反比。多數的人超過70小時，除了上廁所順帶簡單擦洗清潔，偶有人出去買些食品、飲料、日用品。全部幾乎都在辦公室討論、邊查文件、苦讀後邊趕修改提案書與簡報，累了只要能就地找個位置睡一下，沒人講舒不舒適或形象問題。